Autogenerated HTML docs for v2.48.1-356-g03944
diff --git a/BreakingChanges.adoc b/BreakingChanges.adoc
new file mode 100644
index 0000000..7c388e5
--- /dev/null
+++ b/BreakingChanges.adoc
@@ -0,0 +1,199 @@
+= Upcoming breaking changes
+
+The Git project aims to ensure backwards compatibility to the best extent
+possible. Minor releases will not break backwards compatibility unless there is
+a very strong reason to do so, like for example a security vulnerability.
+
+Regardless of that, due to the age of the Git project, it is only natural to
+accumulate a backlog of backwards-incompatible changes that will eventually be
+required to keep the project aligned with a changing world. These changes fall
+into several categories:
+
+* Changes to long established defaults.
+* Concepts that have been replaced with a superior design.
+* Concepts, commands, configuration or options that have been lacking in major
+ ways and that cannot be fixed and which will thus be removed without any
+ replacement.
+
+Explicitly not included in this list are fixes to minor bugs that may cause a
+change in user-visible behavior.
+
+The Git project irregularly releases breaking versions that deliberately break
+backwards compatibility with older versions. This is done to ensure that Git
+remains relevant, safe and maintainable going forward. The release cadence of
+breaking versions is typically measured in multiple years. We had the following
+major breaking releases in the past:
+
+* Git 1.6.0, released in August 2008.
+* Git 2.0, released in May 2014.
+
+We use <major>.<minor> release numbers these days, starting from Git 2.0. For
+future releases, our plan is to increment <major> in the release number when we
+make the next breaking release. Before Git 2.0, the release numbers were
+1.<major>.<minor> with the intention to increment <major> for "usual" breaking
+releases, reserving the jump to Git 2.0 for really large backward-compatibility
+breaking changes.
+
+The intent of this document is to track upcoming deprecations for future
+breaking releases. Furthermore, this document also tracks what will _not_ be
+deprecated. This is done such that the outcome of discussions document both
+when the discussion favors deprecation, but also when it rejects a deprecation.
+
+Items should have a clear summary of the reasons why we do or do not want to
+make the described change that can be easily understood without having to read
+the mailing list discussions. If there are alternatives to the changed feature,
+those alternatives should be pointed out to our users.
+
+All items should be accompanied by references to relevant mailing list threads
+where the deprecation was discussed. These references use message-IDs, which
+can visited via
+
+ https://lore.kernel.org/git/$message_id/
+
+to see the message and its surrounding discussion. Such a reference is there to
+make it easier for you to find how the project reached consensus on the
+described item back then.
+
+This is a living document as the environment surrounding the project changes
+over time. If circumstances change, an earlier decision to deprecate or change
+something may need to be revisited from time to time. So do not take items on
+this list to mean "it is settled, do not waste our time bringing it up again".
+
+== Procedure
+
+Discussing the desire to make breaking changes, declaring that breaking
+changes are made at a certain version boundary, and recording these
+decisions in this document, are necessary but not sufficient.
+Because such changes are expected to be numerous, and the design and
+implementation of them are expected to span over time, they have to
+be deployable trivially at such a version boundary.
+
+The breaking changes MUST be guarded with the a compile-time switch,
+WITH_BREAKING_CHANGES, to help this process. When built with it,
+the resulting Git binary together with its documentation would
+behave as if these breaking changes slated for the next big version
+boundary are already in effect. We may also want to have a CI job
+or two to exercise the work-in-progress version of Git with these
+breaking changes.
+
+
+== Git 3.0
+
+The following subsections document upcoming breaking changes for Git 3.0. There
+is no planned release date for this breaking version yet. The early
+adopter configuration used for changes for this release is `feature.git3`.
+
+Proposed changes and removals only include items which are "ready" to be done.
+In other words, this is not supposed to be a wishlist of features that should
+be changed to or replaced in case the alternative was implemented already.
+
+=== Changes
+
+* The default hash function for new repositories will be changed from "sha1"
+ to "sha256". SHA-1 has been deprecated by NIST in 2011 and is nowadays
+ recommended against in FIPS 140-2 and similar certifications. Furthermore,
+ there are practical attacks on SHA-1 that weaken its cryptographic properties:
++
+ ** The SHAppening (2015). The first demonstration of a practical attack
+ against SHA-1 with 2^57 operations.
+ ** SHAttered (2017). Generation of two valid PDF files with 2^63 operations.
+ ** Birthday-Near-Collision (2019). This attack allows for chosen prefix
+ attacks with 2^68 operations.
+ ** Shambles (2020). This attack allows for chosen prefix attacks with 2^63
+ operations.
++
+While we have protections in place against known attacks, it is expected
+that more attacks against SHA-1 will be found by future research. Paired
+with the ever-growing capability of hardware, it is only a matter of time
+before SHA-1 will be considered broken completely. We want to be prepared
+and will thus change the default hash algorithm to "sha256" for newly
+initialized repositories.
++
+An important requirement for this change is that the ecosystem is ready to
+support the "sha256" object format. This includes popular Git libraries,
+applications and forges.
++
+There is no plan to deprecate the "sha1" object format at this point in time.
++
+Cf. <2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com>,
+<20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain>,
+<CA+EOSBncr=4a4d8n9xS4FNehyebpmX8JiUwCsXD47EQDE+DiUQ@mail.gmail.com>.
+
+=== Removals
+
+* Support for grafting commits has long been superseded by git-replace(1).
+ Grafts are inferior to replacement refs:
++
+ ** Grafts are a local-only mechanism and cannot be shared across
+ repositories.
+ ** Grafts can lead to hard-to-diagnose problems when transferring objects
+ between repositories.
++
+The grafting mechanism has been marked as outdated since e650d0643b (docs: mark
+info/grafts as outdated, 2014-03-05) and will be removed.
++
+Cf. <20140304174806.GA11561@sigill.intra.peff.net>.
+
+* The git-pack-redundant(1) command can be used to remove redundant pack files.
+ The subcommand is unusably slow and the reason why nobody reports it as a
+ performance bug is suspected to be the absence of users. We have nominated
+ the command for removal and have started to emit a user-visible warning in
+ c3b58472be (pack-redundant: gauge the usage before proposing its removal,
+ 2020-08-25) whenever the command is executed.
++
+So far there was a single complaint about somebody still using the command, but
+that complaint did not cause us to reverse course. On the contrary, we have
+doubled down on the deprecation and starting with 4406522b76 (pack-redundant:
+escalate deprecation warning to an error, 2023-03-23), the command dies unless
+the user passes the `--i-still-use-this` option.
++
+There have not been any subsequent complaints, so this command will finally be
+removed.
++
+Cf. <xmqq1rjuz6n3.fsf_-_@gitster.c.googlers.com>,
+ <CAKvOHKAFXQwt4D8yUCCkf_TQL79mYaJ=KAKhtpDNTvHJFuX1NA@mail.gmail.com>,
+ <20230323204047.GA9290@coredump.intra.peff.net>,
+
+* Support for storing shorthands for remote URLs in "$GIT_COMMON_DIR/branches/"
+ and "$GIT_COMMON_DIR/remotes/" has been long superseded by storing remotes in
+ the repository configuration.
++
+The mechanism has originally been introduced in f170e4b39d ([PATCH] fetch/pull:
+short-hand notation for remote repositories., 2005-07-16) and was superseded by
+6687f8fea2 ([PATCH] Use .git/remote/origin, not .git/branches/origin.,
+2005-08-20), where we switched from ".git/branches/" to ".git/remotes/". That
+commit already mentions an upcoming deprecation of the ".git/branches/"
+directory, and starting with a1d4aa7424 (Add repository-layout document.,
+2005-09-01) we have also marked this layout as deprecated. Eventually we also
+started to migrate away from ".git/remotes/" in favor of config-based remotes,
+and we have marked the directory as legacy in 3d3d282146 (Documentation:
+Grammar correction, wording fixes and cleanup, 2011-08-23)
++
+As our documentation mentions, these directories are not to be found in modern
+repositories at all and most users aren't even aware of these mechanisms. They
+have been deprecated for almost 20 years and 14 years respectively, and we are
+not aware of any active users that have complained about this deprecation.
+Furthermore, the ".git/branches/" directory is nowadays misleadingly named and
+may cause confusion as "branches" are almost exclusively used in the context of
+references.
++
+These features will be removed.
+
+== Superseded features that will not be deprecated
+
+Some features have gained newer replacements that aim to improve the design in
+certain ways. The fact that there is a replacement does not automatically mean
+that the old way of doing things will eventually be removed. This section tracks
+those features with newer alternatives.
+
+* The features git-checkout(1) offers are covered by the pair of commands
+ git-restore(1) and git-switch(1). Because the use of git-checkout(1) is still
+ widespread, and it is not expected that this will change anytime soon, all
+ three commands will stay.
++
+This decision may get revisited in case we ever figure out that there are
+almost no users of any of the commands anymore.
++
+Cf. <xmqqttjazwwa.fsf@gitster.g>,
+<xmqqleeubork.fsf@gitster.g>,
+<112b6568912a6de6672bf5592c3a718e@manjaro.org>.
diff --git a/DecisionMaking.adoc b/DecisionMaking.adoc
new file mode 100644
index 0000000..b43c472
--- /dev/null
+++ b/DecisionMaking.adoc
@@ -0,0 +1,74 @@
+Decision-Making Process in the Git Project
+==========================================
+
+Introduction
+------------
+This document describes the current decision-making process in the Git
+project. It is a descriptive rather than prescriptive doc; that is, we want to
+describe how things work in practice rather than explicitly recommending any
+particular process or changes to the current process.
+
+Here we document how the project makes decisions for discussions
+(with or without patches), in scale larger than an individual patch
+series (which is fully covered by the SubmittingPatches document).
+
+
+Larger Discussions (with patches)
+---------------------------------
+As with discussions on an individual patch series, starting a larger-scale
+discussion often begins by sending a patch or series to the list. This might
+take the form of an initial design doc, with implementation following in later
+iterations of the series (for example,
+link:https://lore.kernel.org/git/0169ce6fb9ccafc089b74ae406db0d1a8ff8ac65.1688165272.git.steadmon@google.com/[adding unit tests] or
+link:https://lore.kernel.org/git/20200420235310.94493-1-emilyshaffer@google.com/[config-based hooks]),
+or it might include a full implementation from the beginning.
+In either case, discussion progresses the same way for an individual patch series,
+until consensus is reached or the topic is dropped.
+
+
+Larger Discussions (without patches)
+------------------------------------
+Occasionally, larger discussions might occur without an associated patch series.
+These may be very large-scale technical decisions that are beyond the scope of
+even a single large patch series, or they may be more open-ended,
+policy-oriented discussions (examples:
+link:https://lore.kernel.org/git/ZZ77NQkSuiRxRDwt@nand.local/[introducing Rust]
+or link:https://lore.kernel.org/git/YHofmWcIAidkvJiD@google.com/[improving submodule UX]).
+In either case, discussion progresses as described above for general patch series.
+
+For larger discussions without a patch series or other concrete implementation,
+it may be hard to judge when consensus has been reached, as there are not any
+official guidelines. If discussion stalls at this point, it may be helpful to
+restart discussion with an RFC patch series (such as a partial, unfinished
+implementation or proof of concept) that can be more easily debated.
+
+When consensus is reached that it is a good idea, the original
+proposer is expected to coordinate the effort to make it happen,
+with help from others who were involved in the discussion, as
+needed.
+
+For decisions that require code changes, it is often the case that the original
+proposer will follow up with a patch series, although it is also common for
+other interested parties to provide an implementation (or parts of the
+implementation, for very large changes).
+
+For non-technical decisions such as community norms or processes, it is up to
+the community as a whole to implement and sustain agreed-upon changes.
+The project leadership committee (PLC) may help the implementation of
+policy decisions.
+
+
+Other Discussion Venues
+-----------------------
+Occasionally decision proposals are presented off-list, e.g. at the semi-regular
+Contributors' Summit. While higher-bandwidth face-to-face discussion is often
+useful for quickly reaching consensus among attendees, generally we expect to
+summarize the discussion in notes that can later be presented on-list. For an
+example, see the thread
+link:https://lore.kernel.org/git/AC2EB721-2979-43FD-922D-C5076A57F24B@jramsay.com.au/[Notes
+from Git Contributor Summit, Los Angeles (April 5, 2020)] by James Ramsay.
+
+We prefer that "official" discussion happens on the list so that the full
+community has opportunity to engage in discussion. This also means that the
+mailing list archives contain a more-or-less complete history of project
+discussions and decisions.
diff --git a/MyFirstContribution.adoc b/MyFirstContribution.adoc
new file mode 100644
index 0000000..e41654c
--- /dev/null
+++ b/MyFirstContribution.adoc
@@ -0,0 +1,1395 @@
+My First Contribution to the Git Project
+========================================
+:sectanchors:
+
+[[summary]]
+== Summary
+
+This is a tutorial demonstrating the end-to-end workflow of creating a change to
+the Git tree, sending it for review, and making changes based on comments.
+
+[[prerequisites]]
+=== Prerequisites
+
+This tutorial assumes you're already fairly familiar with using Git to manage
+source code. The Git workflow steps will largely remain unexplained.
+
+[[related-reading]]
+=== Related Reading
+
+This tutorial aims to summarize the following documents, but the reader may find
+useful additional context:
+
+- `Documentation/SubmittingPatches`
+- `Documentation/howto/new-command.txt`
+
+[[getting-help]]
+=== Getting Help
+
+If you get stuck, you can seek help in the following places.
+
+==== git@vger.kernel.org
+
+This is the main Git project mailing list where code reviews, version
+announcements, design discussions, and more take place. Those interested in
+contributing are welcome to post questions here. The Git list requires
+plain-text-only emails and prefers inline and bottom-posting when replying to
+mail; you will be CC'd in all replies to you. Optionally, you can subscribe to
+the list by sending an email to <git+subscribe@vger.kernel.org>
+(see https://subspace.kernel.org/subscribing.html for details).
+The https://lore.kernel.org/git[archive] of this mailing list is
+available to view in a browser.
+
+==== https://groups.google.com/forum/#!forum/git-mentoring[git-mentoring@googlegroups.com]
+
+This mailing list is targeted to new contributors and was created as a place to
+post questions and receive answers outside of the public eye of the main list.
+Veteran contributors who are especially interested in helping mentor newcomers
+are present on the list. In order to avoid search indexers, group membership is
+required to view messages; anyone can join and no approval is required.
+
+==== https://web.libera.chat/#git-devel[#git-devel] on Libera Chat
+
+This IRC channel is for conversations between Git contributors. If someone is
+currently online and knows the answer to your question, you can receive help
+in real time. Otherwise, you can read the
+https://colabti.org/irclogger/irclogger_logs/git-devel[scrollback] to see
+whether someone answered you. IRC does not allow offline private messaging, so
+if you try to private message someone and then log out of IRC, they cannot
+respond to you. It's better to ask your questions in the channel so that you
+can be answered if you disconnect and so that others can learn from the
+conversation.
+
+[[getting-started]]
+== Getting Started
+
+[[cloning]]
+=== Clone the Git Repository
+
+Git is mirrored in a number of locations. Clone the repository from one of them;
+https://git-scm.com/downloads suggests one of the best places to clone from is
+the mirror on GitHub.
+
+----
+$ git clone https://github.com/git/git git
+$ cd git
+----
+
+[[dependencies]]
+=== Installing Dependencies
+
+To build Git from source, you need to have a handful of dependencies installed
+on your system. For a hint of what's needed, you can take a look at
+`INSTALL`, paying close attention to the section about Git's dependencies on
+external programs and libraries. That document mentions a way to "test-drive"
+our freshly built Git without installing; that's the method we'll be using in
+this tutorial.
+
+Make sure that your environment has everything you need by building your brand
+new clone of Git from the above step:
+
+----
+$ make
+----
+
+NOTE: The Git build is parallelizable. `-j#` is not included above but you can
+use it as you prefer, here and elsewhere.
+
+[[identify-problem]]
+=== Identify Problem to Solve
+
+////
+Use + to indicate fixed-width here; couldn't get ` to work nicely with the
+quotes around "Pony Saying 'Um, Hello'".
+////
+In this tutorial, we will add a new command, +git psuh+, short for ``Pony Saying
+`Um, Hello''' - a feature which has gone unimplemented despite a high frequency
+of invocation during users' typical daily workflow.
+
+(We've seen some other effort in this space with the implementation of popular
+commands such as `sl`.)
+
+[[setup-workspace]]
+=== Set Up Your Workspace
+
+Let's start by making a development branch to work on our changes. Per
+`Documentation/SubmittingPatches`, since a brand new command is a new feature,
+it's fine to base your work on `master`. However, in the future for bugfixes,
+etc., you should check that document and base it on the appropriate branch.
+
+For the purposes of this document, we will base all our work on the `master`
+branch of the upstream project. Create the `psuh` branch you will use for
+development like so:
+
+----
+$ git checkout -b psuh origin/master
+----
+
+We'll make a number of commits here in order to demonstrate how to send a topic
+with multiple patches up for review simultaneously.
+
+[[code-it-up]]
+== Code It Up!
+
+NOTE: A reference implementation can be found at
+https://github.com/nasamuffin/git/tree/psuh.
+
+[[add-new-command]]
+=== Adding a New Command
+
+Lots of the subcommands are written as builtins, which means they are
+implemented in C and compiled into the main `git` executable. Implementing the
+very simple `psuh` command as a built-in will demonstrate the structure of the
+codebase, the internal API, and the process of working together as a contributor
+with the reviewers and maintainer to integrate this change into the system.
+
+Built-in subcommands are typically implemented in a function named "cmd_"
+followed by the name of the subcommand, in a source file named after the
+subcommand and contained within `builtin/`. So it makes sense to implement your
+command in `builtin/psuh.c`. Create that file, and within it, write the entry
+point for your command in a function matching the style and signature:
+
+----
+int cmd_psuh(int argc, const char **argv, const char *prefix)
+----
+
+We'll also need to add the declaration of psuh; open up `builtin.h`, find the
+declaration for `cmd_pull`, and add a new line for `psuh` immediately before it,
+in order to keep the declarations alphabetically sorted:
+
+----
+int cmd_psuh(int argc, const char **argv, const char *prefix);
+----
+
+Be sure to `#include "builtin.h"` in your `psuh.c`. You'll also need to
+`#include "gettext.h"` to use functions related to printing output text.
+
+Go ahead and add some throwaway printf to the `cmd_psuh` function. This is a
+decent starting point as we can now add build rules and register the command.
+
+NOTE: Your throwaway text, as well as much of the text you will be adding over
+the course of this tutorial, is user-facing. That means it needs to be
+localizable. Take a look at `po/README` under "Marking strings for translation".
+Throughout the tutorial, we will mark strings for translation as necessary; you
+should also do so when writing your user-facing commands in the future.
+
+----
+int cmd_psuh(int argc, const char **argv, const char *prefix)
+{
+ printf(_("Pony saying hello goes here.\n"));
+ return 0;
+}
+----
+
+Let's try to build it. Open `Makefile`, find where `builtin/pull.o` is added
+to `BUILTIN_OBJS`, and add `builtin/psuh.o` in the same way next to it in
+alphabetical order. Once you've done so, move to the top-level directory and
+build simply with `make`. Also add the `DEVELOPER=1` variable to turn on
+some additional warnings:
+
+----
+$ echo DEVELOPER=1 >config.mak
+$ make
+----
+
+NOTE: When you are developing the Git project, it's preferred that you use the
+`DEVELOPER` flag; if there's some reason it doesn't work for you, you can turn
+it off, but it's a good idea to mention the problem to the mailing list.
+
+Great, now your new command builds happily on its own. But nobody invokes it.
+Let's change that.
+
+The list of commands lives in `git.c`. We can register a new command by adding
+a `cmd_struct` to the `commands[]` array. `struct cmd_struct` takes a string
+with the command name, a function pointer to the command implementation, and a
+setup option flag. For now, let's keep mimicking `push`. Find the line where
+`cmd_push` is registered, copy it, and modify it for `cmd_psuh`, placing the new
+line in alphabetical order (immediately before `cmd_pull`).
+
+The options are documented in `builtin.h` under "Adding a new built-in." Since
+we hope to print some data about the user's current workspace context later,
+we need a Git directory, so choose `RUN_SETUP` as your only option.
+
+Go ahead and build again. You should see a clean build, so let's kick the tires
+and see if it works. There's a binary you can use to test with in the
+`bin-wrappers` directory.
+
+----
+$ ./bin-wrappers/git psuh
+----
+
+Check it out! You've got a command! Nice work! Let's commit this.
+
+`git status` reveals modified `Makefile`, `builtin.h`, and `git.c` as well as
+untracked `builtin/psuh.c` and `git-psuh`. First, let's take care of the binary,
+which should be ignored. Open `.gitignore` in your editor, find `/git-pull`, and
+add an entry for your new command in alphabetical order:
+
+----
+...
+/git-prune-packed
+/git-psuh
+/git-pull
+/git-push
+/git-quiltimport
+/git-range-diff
+...
+----
+
+Checking `git status` again should show that `git-psuh` has been removed from
+the untracked list and `.gitignore` has been added to the modified list. Now we
+can stage and commit:
+
+----
+$ git add Makefile builtin.h builtin/psuh.c git.c .gitignore
+$ git commit -s
+----
+
+You will be presented with your editor in order to write a commit message. Start
+the commit with a 50-column or less subject line, including the name of the
+component you're working on, followed by a blank line (always required) and then
+the body of your commit message, which should provide the bulk of the context.
+Remember to be explicit and provide the "Why" of your change, especially if it
+couldn't easily be understood from your diff. When editing your commit message,
+don't remove the `Signed-off-by` trailer which was added by `-s` above.
+
+----
+psuh: add a built-in by popular demand
+
+Internal metrics indicate this is a command many users expect to be
+present. So here's an implementation to help drive customer
+satisfaction and engagement: a pony which doubtfully greets the user,
+or, a Pony Saying "Um, Hello" (PSUH).
+
+This commit message is intentionally formatted to 72 columns per line,
+starts with a single line as "commit message subject" that is written as
+if to command the codebase to do something (add this, teach a command
+that). The body of the message is designed to add information about the
+commit that is not readily deduced from reading the associated diff,
+such as answering the question "why?".
+
+Signed-off-by: A U Thor <author@example.com>
+----
+
+Go ahead and inspect your new commit with `git show`. "psuh:" indicates you
+have modified mainly the `psuh` command. The subject line gives readers an idea
+of what you've changed. The sign-off line (`-s`) indicates that you agree to
+the Developer's Certificate of Origin 1.1 (see the
+`Documentation/SubmittingPatches` +++[[dco]]+++ header).
+
+For the remainder of the tutorial, the subject line only will be listed for the
+sake of brevity. However, fully-fleshed example commit messages are available
+on the reference implementation linked at the top of this document.
+
+[[implementation]]
+=== Implementation
+
+It's probably useful to do at least something besides printing out a string.
+Let's start by having a look at everything we get.
+
+Modify your `cmd_psuh` implementation to dump the args you're passed, keeping
+existing `printf()` calls in place:
+
+----
+ int i;
+
+ ...
+
+ printf(Q_("Your args (there is %d):\n",
+ "Your args (there are %d):\n",
+ argc),
+ argc);
+ for (i = 0; i < argc; i++)
+ printf("%d: %s\n", i, argv[i]);
+
+ printf(_("Your current working directory:\n<top-level>%s%s\n"),
+ prefix ? "/" : "", prefix ? prefix : "");
+
+----
+
+Build and try it. As you may expect, there's pretty much just whatever we give
+on the command line, including the name of our command. (If `prefix` is empty
+for you, try `cd Documentation/ && ../bin-wrappers/git psuh`). That's not so
+helpful. So what other context can we get?
+
+Add a line to `#include "config.h"`. Then, add the following bits to the
+function body:
+
+----
+ const char *cfg_name;
+
+...
+
+ git_config(git_default_config, NULL);
+ if (git_config_get_string_tmp("user.name", &cfg_name) > 0)
+ printf(_("No name is found in config\n"));
+ else
+ printf(_("Your name: %s\n"), cfg_name);
+----
+
+`git_config()` will grab the configuration from config files known to Git and
+apply standard precedence rules. `git_config_get_string_tmp()` will look up
+a specific key ("user.name") and give you the value. There are a number of
+single-key lookup functions like this one; you can see them all (and more info
+about how to use `git_config()`) in `Documentation/technical/api-config.txt`.
+
+You should see that the name printed matches the one you see when you run:
+
+----
+$ git config --get user.name
+----
+
+Great! Now we know how to check for values in the Git config. Let's commit this
+too, so we don't lose our progress.
+
+----
+$ git add builtin/psuh.c
+$ git commit -sm "psuh: show parameters & config opts"
+----
+
+NOTE: Again, the above is for sake of brevity in this tutorial. In a real change
+you should not use `-m` but instead use the editor to write a meaningful
+message.
+
+Still, it'd be nice to know what the user's working context is like. Let's see
+if we can print the name of the user's current branch. We can mimic the
+`git status` implementation; the printer is located in `wt-status.c` and we can
+see that the branch is held in a `struct wt_status`.
+
+`wt_status_print()` gets invoked by `cmd_status()` in `builtin/commit.c`.
+Looking at that implementation we see the status config being populated like so:
+
+----
+status_init_config(&s, git_status_config);
+----
+
+But as we drill down, we can find that `status_init_config()` wraps a call
+to `git_config()`. Let's modify the code we wrote in the previous commit.
+
+Be sure to include the header to allow you to use `struct wt_status`:
+----
+#include "wt-status.h"
+----
+
+Then modify your `cmd_psuh` implementation to declare your `struct wt_status`,
+prepare it, and print its contents:
+
+----
+ struct wt_status status;
+
+...
+
+ wt_status_prepare(the_repository, &status);
+ git_config(git_default_config, &status);
+
+...
+
+ printf(_("Your current branch: %s\n"), status.branch);
+----
+
+Run it again. Check it out - here's the (verbose) name of your current branch!
+
+Let's commit this as well.
+
+----
+$ git add builtin/psuh.c
+$ git commit -sm "psuh: print the current branch"
+----
+
+Now let's see if we can get some info about a specific commit.
+
+Luckily, there are some helpers for us here. `commit.h` has a function called
+`lookup_commit_reference_by_name` to which we can simply provide a hardcoded
+string; `pretty.h` has an extremely handy `pp_commit_easy()` call which doesn't
+require a full format object to be passed.
+
+Add the following includes:
+
+----
+#include "commit.h"
+#include "pretty.h"
+----
+
+Then, add the following lines within your implementation of `cmd_psuh()` near
+the declarations and the logic, respectively.
+
+----
+ struct commit *c = NULL;
+ struct strbuf commitline = STRBUF_INIT;
+
+...
+
+ c = lookup_commit_reference_by_name("origin/master");
+
+ if (c != NULL) {
+ pp_commit_easy(CMIT_FMT_ONELINE, c, &commitline);
+ printf(_("Current commit: %s\n"), commitline.buf);
+ }
+----
+
+The `struct strbuf` provides some safety belts to your basic `char*`, one of
+which is a length member to prevent buffer overruns. It needs to be initialized
+nicely with `STRBUF_INIT`. Keep it in mind when you need to pass around `char*`.
+
+`lookup_commit_reference_by_name` resolves the name you pass it, so you can play
+with the value there and see what kind of things you can come up with.
+
+`pp_commit_easy` is a convenience wrapper in `pretty.h` that takes a single
+format enum shorthand, rather than an entire format struct. It then
+pretty-prints the commit according to that shorthand. These are similar to the
+formats available with `--pretty=FOO` in many Git commands.
+
+Build it and run, and if you're using the same name in the example, you should
+see the subject line of the most recent commit in `origin/master` that you know
+about. Neat! Let's commit that as well.
+
+----
+$ git add builtin/psuh.c
+$ git commit -sm "psuh: display the top of origin/master"
+----
+
+[[add-documentation]]
+=== Adding Documentation
+
+Awesome! You've got a fantastic new command that you're ready to share with the
+community. But hang on just a minute - this isn't very user-friendly. Run the
+following:
+
+----
+$ ./bin-wrappers/git help psuh
+----
+
+Your new command is undocumented! Let's fix that.
+
+Take a look at `Documentation/git-*.txt`. These are the manpages for the
+subcommands that Git knows about. You can open these up and take a look to get
+acquainted with the format, but then go ahead and make a new file
+`Documentation/git-psuh.txt`. Like with most of the documentation in the Git
+project, help pages are written with AsciiDoc (see CodingGuidelines, "Writing
+Documentation" section). Use the following template to fill out your own
+manpage:
+
+// Surprisingly difficult to embed AsciiDoc source within AsciiDoc.
+[listing]
+....
+git-psuh(1)
+===========
+
+NAME
+----
+git-psuh - Delight users' typo with a shy horse
+
+
+SYNOPSIS
+--------
+[verse]
+'git-psuh [<arg>...]'
+
+DESCRIPTION
+-----------
+...
+
+OPTIONS[[OPTIONS]]
+------------------
+...
+
+OUTPUT
+------
+...
+
+GIT
+---
+Part of the linkgit:git[1] suite
+....
+
+The most important pieces of this to note are the file header, underlined by =,
+the NAME section, and the SYNOPSIS, which would normally contain the grammar if
+your command took arguments. Try to use well-established manpage headers so your
+documentation is consistent with other Git and UNIX manpages; this makes life
+easier for your user, who can skip to the section they know contains the
+information they need.
+
+NOTE: Before trying to build the docs, make sure you have the package `asciidoc`
+installed.
+
+Now that you've written your manpage, you'll need to build it explicitly. We
+convert your AsciiDoc to troff which is man-readable like so:
+
+----
+$ make all doc
+$ man Documentation/git-psuh.1
+----
+
+or
+
+----
+$ make -C Documentation/ git-psuh.1
+$ man Documentation/git-psuh.1
+----
+
+While this isn't as satisfying as running through `git help`, you can at least
+check that your help page looks right.
+
+You can also check that the documentation coverage is good (that is, the project
+sees that your command has been implemented as well as documented) by running
+`make check-docs` from the top-level.
+
+Go ahead and commit your new documentation change.
+
+[[add-usage]]
+=== Adding Usage Text
+
+Try and run `./bin-wrappers/git psuh -h`. Your command should crash at the end.
+That's because `-h` is a special case which your command should handle by
+printing usage.
+
+Take a look at `Documentation/technical/api-parse-options.txt`. This is a handy
+tool for pulling out options you need to be able to handle, and it takes a
+usage string.
+
+In order to use it, we'll need to prepare a NULL-terminated array of usage
+strings and a `builtin_psuh_options` array.
+
+Add a line to `#include "parse-options.h"`.
+
+At global scope, add your array of usage strings:
+
+----
+static const char * const psuh_usage[] = {
+ N_("git psuh [<arg>...]"),
+ NULL,
+};
+----
+
+Then, within your `cmd_psuh()` implementation, we can declare and populate our
+`option` struct. Ours is pretty boring but you can add more to it if you want to
+explore `parse_options()` in more detail:
+
+----
+ struct option options[] = {
+ OPT_END()
+ };
+----
+
+Finally, before you print your args and prefix, add the call to
+`parse-options()`:
+
+----
+ argc = parse_options(argc, argv, prefix, options, psuh_usage, 0);
+----
+
+This call will modify your `argv` parameter. It will strip the options you
+specified in `options` from `argv` and the locations pointed to from `options`
+entries will be updated. Be sure to replace your `argc` with the result from
+`parse_options()`, or you will be confused if you try to parse `argv` later.
+
+It's worth noting the special argument `--`. As you may be aware, many Unix
+commands use `--` to indicate "end of named parameters" - all parameters after
+the `--` are interpreted merely as positional arguments. (This can be handy if
+you want to pass as a parameter something which would usually be interpreted as
+a flag.) `parse_options()` will terminate parsing when it reaches `--` and give
+you the rest of the options afterwards, untouched.
+
+Now that you have a usage hint, you can teach Git how to show it in the general
+command list shown by `git help git` or `git help -a`, which is generated from
+`command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'
+line above it in alphabetical order. Now, we can add some attributes about the
+command which impacts where it shows up in the aforementioned help commands. The
+top of `command-list.txt` shares some information about what each attribute
+means; in those help pages, the commands are sorted according to these
+attributes. `git psuh` is user-facing, or porcelain - so we will mark it as
+"mainporcelain". For "mainporcelain" commands, the comments at the top of
+`command-list.txt` indicate we can also optionally add an attribute from another
+list; since `git psuh` shows some information about the user's workspace but
+doesn't modify anything, let's mark it as "info". Make sure to keep your
+attributes in the same style as the rest of `command-list.txt` using spaces to
+align and delineate them:
+
+----
+git-prune-packed plumbingmanipulators
+git-psuh mainporcelain info
+git-pull mainporcelain remote
+git-push mainporcelain remote
+----
+
+Build again. Now, when you run with `-h`, you should see your usage printed and
+your command terminated before anything else interesting happens. Great!
+
+Go ahead and commit this one, too.
+
+[[testing]]
+== Testing
+
+It's important to test your code - even for a little toy command like this one.
+Moreover, your patch won't be accepted into the Git tree without tests. Your
+tests should:
+
+* Illustrate the current behavior of the feature
+* Prove the current behavior matches the expected behavior
+* Ensure the externally-visible behavior isn't broken in later changes
+
+So let's write some tests.
+
+Related reading: `t/README`
+
+[[overview-test-structure]]
+=== Overview of Testing Structure
+
+The tests in Git live in `t/` and are named with a 4-digit decimal number using
+the schema shown in the Naming Tests section of `t/README`.
+
+[[write-new-test]]
+=== Writing Your Test
+
+Since this a toy command, let's go ahead and name the test with t9999. However,
+as many of the family/subcmd combinations are full, best practice seems to be
+to find a command close enough to the one you've added and share its naming
+space.
+
+Create a new file `t/t9999-psuh-tutorial.sh`. Begin with the header as so (see
+"Writing Tests" and "Source 'test-lib.sh'" in `t/README`):
+
+----
+#!/bin/sh
+
+test_description='git-psuh test
+
+This test runs git-psuh and makes sure it does not crash.'
+
+. ./test-lib.sh
+----
+
+Tests are framed inside of a `test_expect_success` in order to output TAP
+formatted results. Let's make sure that `git psuh` doesn't exit poorly and does
+mention the right animal somewhere:
+
+----
+test_expect_success 'runs correctly with no args and good output' '
+ git psuh >actual &&
+ grep Pony actual
+'
+----
+
+Indicate that you've run everything you wanted by adding the following at the
+bottom of your script:
+
+----
+test_done
+----
+
+Make sure you mark your test script executable:
+
+----
+$ chmod +x t/t9999-psuh-tutorial.sh
+----
+
+You can get an idea of whether you created your new test script successfully
+by running `make -C t test-lint`, which will check for things like test number
+uniqueness, executable bit, and so on.
+
+[[local-test]]
+=== Running Locally
+
+Let's try and run locally:
+
+----
+$ make
+$ cd t/ && prove t9999-psuh-tutorial.sh
+----
+
+You can run the full test suite and ensure `git-psuh` didn't break anything:
+
+----
+$ cd t/
+$ prove -j$(nproc) --shuffle t[0-9]*.sh
+----
+
+NOTE: You can also do this with `make test` or use any testing harness which can
+speak TAP. `prove` can run concurrently. `shuffle` randomizes the order the
+tests are run in, which makes them resilient against unwanted inter-test
+dependencies. `prove` also makes the output nicer.
+
+Go ahead and commit this change, as well.
+
+[[ready-to-share]]
+== Getting Ready to Share: Anatomy of a Patch Series
+
+You may have noticed already that the Git project performs its code reviews via
+emailed patches, which are then applied by the maintainer when they are ready
+and approved by the community. The Git project does not accept contributions from
+pull requests, and the patches emailed for review need to be formatted a
+specific way.
+
+:patch-series: https://lore.kernel.org/git/pull.1218.git.git.1645209647.gitgitgadget@gmail.com/
+:lore: https://lore.kernel.org/git/
+
+Before taking a look at how to convert your commits into emailed patches,
+let's analyze what the end result, a "patch series", looks like. Here is an
+{patch-series}[example] of the summary view for a patch series on the web interface of
+the {lore}[Git mailing list archive]:
+
+----
+2022-02-18 18:40 [PATCH 0/3] libify reflog John Cai via GitGitGadget
+2022-02-18 18:40 ` [PATCH 1/3] reflog: libify delete reflog function and helpers John Cai via GitGitGadget
+2022-02-18 19:10 ` Ævar Arnfjörð Bjarmason [this message]
+2022-02-18 19:39 ` Taylor Blau
+2022-02-18 19:48 ` Ævar Arnfjörð Bjarmason
+2022-02-18 19:35 ` Taylor Blau
+2022-02-21 1:43 ` John Cai
+2022-02-21 1:50 ` Taylor Blau
+2022-02-23 19:50 ` John Cai
+2022-02-18 20:00 ` // other replies elided
+2022-02-18 18:40 ` [PATCH 2/3] reflog: call reflog_delete from reflog.c John Cai via GitGitGadget
+2022-02-18 19:15 ` Ævar Arnfjörð Bjarmason
+2022-02-18 20:26 ` Junio C Hamano
+2022-02-18 18:40 ` [PATCH 3/3] stash: call reflog_delete from reflog.c John Cai via GitGitGadget
+2022-02-18 19:20 ` Ævar Arnfjörð Bjarmason
+2022-02-19 0:21 ` Taylor Blau
+2022-02-22 2:36 ` John Cai
+2022-02-22 10:51 ` Ævar Arnfjörð Bjarmason
+2022-02-18 19:29 ` [PATCH 0/3] libify reflog Ævar Arnfjörð Bjarmason
+2022-02-22 18:30 ` [PATCH v2 0/3] libify reflog John Cai via GitGitGadget
+2022-02-22 18:30 ` [PATCH v2 1/3] stash: add test to ensure reflog --rewrite --updatref behavior John Cai via GitGitGadget
+2022-02-23 8:54 ` Ævar Arnfjörð Bjarmason
+2022-02-23 21:27 ` Junio C Hamano
+// continued
+----
+
+We can note a few things:
+
+- Each commit is sent as a separate email, with the commit message title as
+ subject, prefixed with "[PATCH _i_/_n_]" for the _i_-th commit of an
+ _n_-commit series.
+- Each patch is sent as a reply to an introductory email called the _cover
+ letter_ of the series, prefixed "[PATCH 0/_n_]".
+- Subsequent iterations of the patch series are labelled "PATCH v2", "PATCH
+ v3", etc. in place of "PATCH". For example, "[PATCH v2 1/3]" would be the first of
+ three patches in the second iteration. Each iteration is sent with a new cover
+ letter (like "[PATCH v2 0/3]" above), itself a reply to the cover letter of the
+ previous iteration (more on that below).
+
+NOTE: A single-patch topic is sent with "[PATCH]", "[PATCH v2]", etc. without
+_i_/_n_ numbering (in the above thread overview, no single-patch topic appears,
+though).
+
+[[cover-letter]]
+=== The cover letter
+
+In addition to an email per patch, the Git community also expects your patches
+to come with a cover letter. This is an important component of change
+submission as it explains to the community from a high level what you're trying
+to do, and why, in a way that's more apparent than just looking at your
+patches.
+
+The title of your cover letter should be something which succinctly covers the
+purpose of your entire topic branch. It's often in the imperative mood, just
+like our commit message titles. Here is how we'll title our series:
+
+---
+Add the 'psuh' command
+---
+
+The body of the cover letter is used to give additional context to reviewers.
+Be sure to explain anything your patches don't make clear on their own, but
+remember that since the cover letter is not recorded in the commit history,
+anything that might be useful to future readers of the repository's history
+should also be in your commit messages.
+
+Here's an example body for `psuh`:
+
+----
+Our internal metrics indicate widespread interest in the command
+git-psuh - that is, many users are trying to use it, but finding it is
+unavailable, using some unknown workaround instead.
+
+The following handful of patches add the psuh command and implement some
+handy features on top of it.
+
+This patchset is part of the MyFirstContribution tutorial and should not
+be merged.
+----
+
+At this point the tutorial diverges, in order to demonstrate two
+different methods of formatting your patchset and getting it reviewed.
+
+The first method to be covered is GitGitGadget, which is useful for those
+already familiar with GitHub's common pull request workflow. This method
+requires a GitHub account.
+
+The second method to be covered is `git send-email`, which can give slightly
+more fine-grained control over the emails to be sent. This method requires some
+setup which can change depending on your system and will not be covered in this
+tutorial.
+
+Regardless of which method you choose, your engagement with reviewers will be
+the same; the review process will be covered after the sections on GitGitGadget
+and `git send-email`.
+
+[[howto-ggg]]
+== Sending Patches via GitGitGadget
+
+One option for sending patches is to follow a typical pull request workflow and
+send your patches out via GitGitGadget. GitGitGadget is a tool created by
+Johannes Schindelin to make life as a Git contributor easier for those used to
+the GitHub PR workflow. It allows contributors to open pull requests against its
+mirror of the Git project, and does some magic to turn the PR into a set of
+emails and send them out for you. It also runs the Git continuous integration
+suite for you. It's documented at https://gitgitgadget.github.io/.
+
+[[create-fork]]
+=== Forking `git/git` on GitHub
+
+Before you can send your patch off to be reviewed using GitGitGadget, you will
+need to fork the Git project and upload your changes. First thing - make sure
+you have a GitHub account.
+
+Head to the https://github.com/git/git[GitHub mirror] and look for the Fork
+button. Place your fork wherever you deem appropriate and create it.
+
+[[upload-to-fork]]
+=== Uploading to Your Own Fork
+
+To upload your branch to your own fork, you'll need to add the new fork as a
+remote. You can use `git remote -v` to show the remotes you have added already.
+From your new fork's page on GitHub, you can press "Clone or download" to get
+the URL; then you need to run the following to add, replacing your own URL and
+remote name for the examples provided:
+
+----
+$ git remote add remotename git@github.com:remotename/git.git
+----
+
+or to use the HTTPS URL:
+
+----
+$ git remote add remotename https://github.com/remotename/git/.git
+----
+
+Run `git remote -v` again and you should see the new remote showing up.
+`git fetch remotename` (with the real name of your remote replaced) in order to
+get ready to push.
+
+Next, double-check that you've been doing all your development in a new branch
+by running `git branch`. If you didn't, now is a good time to move your new
+commits to their own branch.
+
+As mentioned briefly at the beginning of this document, we are basing our work
+on `master`, so go ahead and update as shown below, or using your preferred
+workflow.
+
+----
+$ git checkout master
+$ git pull -r
+$ git rebase master psuh
+----
+
+Finally, you're ready to push your new topic branch! (Due to our branch and
+command name choices, be careful when you type the command below.)
+
+----
+$ git push remotename psuh
+----
+
+Now you should be able to go and check out your newly created branch on GitHub.
+
+[[send-pr-ggg]]
+=== Sending a PR to GitGitGadget
+
+In order to have your code tested and formatted for review, you need to start by
+opening a Pull Request against `gitgitgadget/git`. Head to
+https://github.com/gitgitgadget/git and open a PR either with the "New pull
+request" button or the convenient "Compare & pull request" button that may
+appear with the name of your newly pushed branch.
+
+Review the PR's title and description, as they're used by GitGitGadget
+respectively as the subject and body of the cover letter for your change. Refer
+to <<cover-letter,"The cover letter">> above for advice on how to title your
+submission and what content to include in the description.
+
+NOTE: For single-patch contributions, your commit message should already be
+meaningful and explain at a high level the purpose (what is happening and why)
+of your patch, so you usually do not need any additional context. In that case,
+remove the PR description that GitHub automatically generates from your commit
+message (your PR description should be empty). If you do need to supply even
+more context, you can do so in that space and it will be appended to the email
+that GitGitGadget will send, between the three-dash line and the diffstat
+(see <<single-patch,Bonus Chapter: One-Patch Changes>> for how this looks once
+submitted).
+
+When you're happy, submit your pull request.
+
+[[run-ci-ggg]]
+=== Running CI and Getting Ready to Send
+
+If it's your first time using GitGitGadget (which is likely, as you're using
+this tutorial) then someone will need to give you permission to use the tool.
+As mentioned in the GitGitGadget documentation, you just need someone who
+already uses it to comment on your PR with `/allow <username>`. GitGitGadget
+will automatically run your PRs through the CI even without the permission given
+but you will not be able to `/submit` your changes until someone allows you to
+use the tool.
+
+NOTE: You can typically find someone who can `/allow` you on GitGitGadget by
+either examining recent pull requests where someone has been granted `/allow`
+(https://github.com/gitgitgadget/git/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+%22%2Fallow%22[Search:
+is:pr is:open "/allow"]), in which case both the author and the person who
+granted the `/allow` can now `/allow` you, or by inquiring on the
+https://web.libera.chat/#git-devel[#git-devel] IRC channel on Libera Chat
+linking your pull request and asking for someone to `/allow` you.
+
+If the CI fails, you can update your changes with `git rebase -i` and push your
+branch again:
+
+----
+$ git push -f remotename psuh
+----
+
+In fact, you should continue to make changes this way up until the point when
+your patch is accepted into `next`.
+
+////
+TODO https://github.com/gitgitgadget/gitgitgadget/issues/83
+It'd be nice to be able to verify that the patch looks good before sending it
+to everyone on Git mailing list.
+[[check-work-ggg]]
+=== Check Your Work
+////
+
+[[send-mail-ggg]]
+=== Sending Your Patches
+
+Now that your CI is passing and someone has granted you permission to use
+GitGitGadget with the `/allow` command, sending out for review is as simple as
+commenting on your PR with `/submit`.
+
+[[responding-ggg]]
+=== Updating With Comments
+
+Skip ahead to <<reviewing,Responding to Reviews>> for information on how to
+reply to review comments you will receive on the mailing list.
+
+Once you have your branch again in the shape you want following all review
+comments, you can submit again:
+
+----
+$ git push -f remotename psuh
+----
+
+Next, go look at your pull request against GitGitGadget; you should see the CI
+has been kicked off again. Now while the CI is running is a good time for you
+to modify your description at the top of the pull request thread; it will be
+used again as the cover letter. You should use this space to describe what
+has changed since your previous version, so that your reviewers have some idea
+of what they're looking at. When the CI is done running, you can comment once
+more with `/submit` - GitGitGadget will automatically add a v2 mark to your
+changes.
+
+[[howto-git-send-email]]
+== Sending Patches with `git send-email`
+
+If you don't want to use GitGitGadget, you can also use Git itself to mail your
+patches. Some benefits of using Git this way include finer grained control of
+subject line (for example, being able to use the tag [RFC PATCH] in the subject)
+and being able to send a ``dry run'' mail to yourself to ensure it all looks
+good before going out to the list.
+
+[[setup-git-send-email]]
+=== Prerequisite: Setting Up `git send-email`
+
+Configuration for `send-email` can vary based on your operating system and email
+provider, and so will not be covered in this tutorial, beyond stating that in
+many distributions of Linux, `git-send-email` is not packaged alongside the
+typical `git` install. You may need to install this additional package; there
+are a number of resources online to help you do so. You will also need to
+determine the right way to configure it to use your SMTP server; again, as this
+configuration can change significantly based on your system and email setup, it
+is out of scope for the context of this tutorial.
+
+[[format-patch]]
+=== Preparing Initial Patchset
+
+Sending emails with Git is a two-part process; before you can prepare the emails
+themselves, you'll need to prepare the patches. Luckily, this is pretty simple:
+
+----
+$ git format-patch --cover-letter -o psuh/ --base=auto psuh@{u}..psuh
+----
+
+ . The `--cover-letter` option tells `format-patch` to create a
+ cover letter template for you. You will need to fill in the
+ template before you're ready to send - but for now, the template
+ will be next to your other patches.
+
+ . The `-o psuh/` option tells `format-patch` to place the patch
+ files into a directory. This is useful because `git send-email`
+ can take a directory and send out all the patches from there.
+
+ . The `--base=auto` option tells the command to record the "base
+ commit", on which the recipient is expected to apply the patch
+ series. The `auto` value will cause `format-patch` to compute
+ the base commit automatically, which is the merge base of tip
+ commit of the remote-tracking branch and the specified revision
+ range.
+
+ . The `psuh@{u}..psuh` option tells `format-patch` to generate
+ patches for the commits you created on the `psuh` branch since it
+ forked from its upstream (which is `origin/master` if you
+ followed the example in the "Set up your workspace" section). If
+ you are already on the `psuh` branch, you can just say `@{u}`,
+ which means "commits on the current branch since it forked from
+ its upstream", which is the same thing.
+
+The command will make one patch file per commit. After you
+run, you can go have a look at each of the patches with your favorite text
+editor and make sure everything looks alright; however, it's not recommended to
+make code fixups via the patch file. It's a better idea to make the change the
+normal way using `git rebase -i` or by adding a new commit than by modifying a
+patch.
+
+NOTE: Optionally, you can also use the `--rfc` flag to prefix your patch subject
+with ``[RFC PATCH]'' instead of ``[PATCH]''. RFC stands for ``request for
+comments'' and indicates that while your code isn't quite ready for submission,
+you'd like to begin the code review process. This can also be used when your
+patch is a proposal, but you aren't sure whether the community wants to solve
+the problem with that approach or not - to conduct a sort of design review. You
+may also see on the list patches marked ``WIP'' - this means they are incomplete
+but want reviewers to look at what they have so far. You can add this flag with
+`--subject-prefix=WIP`.
+
+Check and make sure that your patches and cover letter template exist in the
+directory you specified - you're nearly ready to send out your review!
+
+[[preparing-cover-letter]]
+=== Preparing Email
+
+Since you invoked `format-patch` with `--cover-letter`, you've already got a
+cover letter template ready. Open it up in your favorite editor.
+
+You should see a number of headers present already. Check that your `From:`
+header is correct. Then modify your `Subject:` (see <<cover-letter,above>> for
+how to choose good title for your patch series):
+
+----
+Subject: [PATCH 0/7] Add the 'psuh' command
+----
+
+Make sure you retain the ``[PATCH 0/X]'' part; that's what indicates to the Git
+community that this email is the beginning of a patch series, and many
+reviewers filter their email for this type of flag.
+
+You'll need to add some extra parameters when you invoke `git send-email` to add
+the cover letter.
+
+Next you'll have to fill out the body of your cover letter. Again, see
+<<cover-letter,above>> for what content to include.
+
+The template created by `git format-patch --cover-letter` includes a diffstat.
+This gives reviewers a summary of what they're in for when reviewing your topic.
+The one generated for `psuh` from the sample implementation looks like this:
+
+----
+ Documentation/git-psuh.txt | 40 +++++++++++++++++++++
+ Makefile | 1 +
+ builtin.h | 1 +
+ builtin/psuh.c | 73 ++++++++++++++++++++++++++++++++++++++
+ git.c | 1 +
+ t/t9999-psuh-tutorial.sh | 12 +++++++
+ 6 files changed, 128 insertions(+)
+ create mode 100644 Documentation/git-psuh.txt
+ create mode 100644 builtin/psuh.c
+ create mode 100755 t/t9999-psuh-tutorial.sh
+----
+
+Finally, the letter will include the version of Git used to generate the
+patches. You can leave that string alone.
+
+[[sending-git-send-email]]
+=== Sending Email
+
+At this point you should have a directory `psuh/` which is filled with your
+patches and a cover letter. Time to mail it out! You can send it like this:
+
+----
+$ git send-email --to=target@example.com psuh/*.patch
+----
+
+NOTE: Check `git help send-email` for some other options which you may find
+valuable, such as changing the Reply-to address or adding more CC and BCC lines.
+
+:contrib-scripts: footnoteref:[contrib-scripts,Scripts under `contrib/` are +
+not part of the core `git` binary and must be called directly. Clone the Git +
+codebase and run `perl contrib/contacts/git-contacts`.]
+
+NOTE: If you're not sure whom to CC, running `contrib/contacts/git-contacts` can
+list potential reviewers. In addition, you can do `git send-email
+--cc-cmd='perl contrib/contacts/git-contacts' feature/*.patch`{contrib-scripts} to
+automatically pass this list of emails to `send-email`.
+
+NOTE: When you are sending a real patch, it will go to git@vger.kernel.org - but
+please don't send your patchset from the tutorial to the real mailing list! For
+now, you can send it to yourself, to make sure you understand how it will look.
+
+After you run the command above, you will be presented with an interactive
+prompt for each patch that's about to go out. This gives you one last chance to
+edit or quit sending something (but again, don't edit code this way). Once you
+press `y` or `a` at these prompts your emails will be sent! Congratulations!
+
+Awesome, now the community will drop everything and review your changes. (Just
+kidding - be patient!)
+
+[[v2-git-send-email]]
+=== Sending v2
+
+This section will focus on how to send a v2 of your patchset. To learn what
+should go into v2, skip ahead to <<reviewing,Responding to Reviews>> for
+information on how to handle comments from reviewers.
+
+We'll reuse our `psuh` topic branch for v2. Before we make any changes, we'll
+mark the tip of our v1 branch for easy reference:
+
+----
+$ git checkout psuh
+$ git branch psuh-v1
+----
+
+Refine your patch series by using `git rebase -i` to adjust commits based upon
+reviewer comments. Once the patch series is ready for submission, generate your
+patches again, but with some new flags:
+
+----
+$ git format-patch -v2 --cover-letter -o psuh/ --range-diff master..psuh-v1 master..
+----
+
+The `--range-diff master..psuh-v1` parameter tells `format-patch` to include a
+range-diff between `psuh-v1` and `psuh` in the cover letter (see
+linkgit:git-range-diff[1]). This helps tell reviewers about the differences
+between your v1 and v2 patches.
+
+The `-v2` parameter tells `format-patch` to output your patches
+as version "2". For instance, you may notice that your v2 patches are
+all named like `v2-000n-my-commit-subject.patch`. `-v2` will also format
+your patches by prefixing them with "[PATCH v2]" instead of "[PATCH]",
+and your range-diff will be prefaced with "Range-diff against v1".
+
+After you run this command, `format-patch` will output the patches to the `psuh/`
+directory, alongside the v1 patches. Using a single directory makes it easy to
+refer to the old v1 patches while proofreading the v2 patches, but you will need
+to be careful to send out only the v2 patches. We will use a pattern like
+`psuh/v2-*.patch` (not `psuh/*.patch`, which would match v1 and v2 patches).
+
+Edit your cover letter again. Now is a good time to mention what's different
+between your last version and now, if it's something significant. You do not
+need the exact same body in your second cover letter; focus on explaining to
+reviewers the changes you've made that may not be as visible.
+
+You will also need to go and find the Message-ID of your previous cover letter.
+You can either note it when you send the first series, from the output of `git
+send-email`, or you can look it up on the
+https://lore.kernel.org/git[mailing list]. Find your cover letter in the
+archives, click on it, then click "permalink" or "raw" to reveal the Message-ID
+header. It should match:
+
+----
+Message-ID: <foo.12345.author@example.com>
+----
+
+Your Message-ID is `<foo.12345.author@example.com>`. This example will be used
+below as well; make sure to replace it with the correct Message-ID for your
+**previous cover letter** - that is, if you're sending v2, use the Message-ID
+from v1; if you're sending v3, use the Message-ID from v2.
+
+While you're looking at the email, you should also note who is CC'd, as it's
+common practice in the mailing list to keep all CCs on a thread. You can add
+these CC lines directly to your cover letter with a line like so in the header
+(before the Subject line):
+
+----
+CC: author@example.com, Othe R <other@example.com>
+----
+
+Now send the emails again, paying close attention to which messages you pass in
+to the command:
+
+----
+$ git send-email --to=target@example.com
+ --in-reply-to="<foo.12345.author@example.com>"
+ psuh/v2-*.patch
+----
+
+[[single-patch]]
+=== Bonus Chapter: One-Patch Changes
+
+In some cases, your very small change may consist of only one patch. When that
+happens, you only need to send one email. Your commit message should already be
+meaningful and explain at a high level the purpose (what is happening and why)
+of your patch, but if you need to supply even more context, you can do so below
+the `---` in your patch. Take the example below, which was generated with `git
+format-patch` on a single commit, and then edited to add the content between
+the `---` and the diffstat.
+
+----
+From 1345bbb3f7ac74abde040c12e737204689a72723 Mon Sep 17 00:00:00 2001
+From: A U Thor <author@example.com>
+Date: Thu, 18 Apr 2019 15:11:02 -0700
+Subject: [PATCH] README: change the grammar
+
+I think it looks better this way. This part of the commit message will
+end up in the commit-log.
+
+Signed-off-by: A U Thor <author@example.com>
+---
+Let's have a wild discussion about grammar on the mailing list. This
+part of my email will never end up in the commit log. Here is where I
+can add additional context to the mailing list about my intent, outside
+of the context of the commit log. This section was added after `git
+format-patch` was run, by editing the patch file in a text editor.
+
+ README.md | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/README.md b/README.md
+index 88f126184c..38da593a60 100644
+--- a/README.md
++++ b/README.md
+@@ -3,7 +3,7 @@
+ Git - fast, scalable, distributed revision control system
+ =========================================================
+
+-Git is a fast, scalable, distributed revision control system with an
++Git is a fast, scalable, and distributed revision control system with an
+ unusually rich command set that provides both high-level operations
+ and full access to internals.
+
+--
+2.21.0.392.gf8f6787159e-goog
+----
+
+[[now-what]]
+== My Patch Got Emailed - Now What?
+
+Please give reviewers enough time to process your initial patch before
+sending an updated version. That is, resist the temptation to send a new
+version immediately, because others may have already started reviewing
+your initial version.
+
+While waiting for review comments, you may find mistakes in your initial
+patch, or perhaps realize a different and better way to achieve the goal
+of the patch. In this case you may communicate your findings to other
+reviewers as follows:
+
+ - If the mistakes you found are minor, send a reply to your patch as if
+ you were a reviewer and mention that you will fix them in an
+ updated version.
+
+ - On the other hand, if you think you want to change the course so
+ drastically that reviews on the initial patch would be a waste of
+ time (for everyone involved), retract the patch immediately with
+ a reply like "I am working on a much better approach, so please
+ ignore this patch and wait for the updated version."
+
+Now, the above is a good practice if you sent your initial patch
+prematurely without polish. But a better approach of course is to avoid
+sending your patch prematurely in the first place.
+
+Please be considerate of the time needed by reviewers to examine each
+new version of your patch. Rather than seeing the initial version right
+now (followed by several "oops, I like this version better than the
+previous one" patches over 2 days), reviewers would strongly prefer if a
+single polished version came 2 days later instead, and that version with
+fewer mistakes were the only one they would need to review.
+
+
+[[reviewing]]
+=== Responding to Reviews
+
+After a few days, you will hopefully receive a reply to your patchset with some
+comments. Woohoo! Now you can get back to work.
+
+It's good manners to reply to each comment, notifying the reviewer that you have
+made the change suggested, feel the original is better, or that the comment
+inspired you to do something a new way which is superior to both the original
+and the suggested change. This way reviewers don't need to inspect your v2 to
+figure out whether you implemented their comment or not.
+
+Reviewers may ask you about what you wrote in the patchset, either in
+the proposed commit log message or in the changes themselves. You
+should answer these questions in your response messages, but often the
+reason why reviewers asked these questions to understand what you meant
+to write is because your patchset needed clarification to be understood.
+
+Do not be satisfied by just answering their questions in your response
+and hear them say that they now understand what you wanted to say.
+Update your patches to clarify the points reviewers had trouble with,
+and prepare your v2; the words you used to explain your v1 to answer
+reviewers' questions may be useful thing to use. Your goal is to make
+your v2 clear enough so that it becomes unnecessary for you to give the
+same explanation to the next person who reads it.
+
+If you are going to push back on a comment, be polite and explain why you feel
+your original is better; be prepared that the reviewer may still disagree with
+you, and the rest of the community may weigh in on one side or the other. As
+with all code reviews, it's important to keep an open mind to doing something a
+different way than you originally planned; other reviewers have a different
+perspective on the project than you do, and may be thinking of a valid side
+effect which had not occurred to you. It is always okay to ask for clarification
+if you aren't sure why a change was suggested, or what the reviewer is asking
+you to do.
+
+Make sure your email client has a plaintext email mode and it is turned on; the
+Git list rejects HTML email. Please also follow the mailing list etiquette
+outlined in the
+https://kernel.googlesource.com/pub/scm/git/git/+/todo/MaintNotes[Maintainer's
+Note], which are similar to etiquette rules in most open source communities
+surrounding bottom-posting and inline replies.
+
+When you're making changes to your code, it is cleanest - that is, the resulting
+commits are easiest to look at - if you use `git rebase -i` (interactive
+rebase). Take a look at this
+https://www.oreilly.com/library/view/git-pocket-guide/9781449327507/ch10.html[overview]
+from O'Reilly. The general idea is to modify each commit which requires changes;
+this way, instead of having a patch A with a mistake, a patch B which was fine
+and required no upstream reviews in v1, and a patch C which fixes patch A for
+v2, you can just ship a v2 with a correct patch A and correct patch B. This is
+changing history, but since it's local history which you haven't shared with
+anyone, that is okay for now! (Later, it may not make sense to do this; take a
+look at the section below this one for some context.)
+
+[[after-approval]]
+=== After Review Approval
+
+The Git project has four integration branches: `seen`, `next`, `master`, and
+`maint`. Your change will be placed into `seen` fairly early on by the maintainer
+while it is still in the review process; from there, when it is ready for wider
+testing, it will be merged into `next`. Plenty of early testers use `next` and
+may report issues. Eventually, changes in `next` will make it to `master`,
+which is typically considered stable. Finally, when a new release is cut,
+`maint` is used to base bugfixes onto. As mentioned at the beginning of this
+document, you can read `Documents/SubmittingPatches` for some more info about
+the use of the various integration branches.
+
+Back to now: your code has been lauded by the upstream reviewers. It is perfect.
+It is ready to be accepted. You don't need to do anything else; the maintainer
+will merge your topic branch to `next` and life is good.
+
+However, if you discover it isn't so perfect after this point, you may need to
+take some special steps depending on where you are in the process.
+
+If the maintainer has announced in the "What's cooking in git.git" email that
+your topic is marked for `next` - that is, that they plan to merge it to `next`
+but have not yet done so - you should send an email asking the maintainer to
+wait a little longer: "I've sent v4 of my series and you marked it for `next`,
+but I need to change this and that - please wait for v5 before you merge it."
+
+If the topic has already been merged to `next`, rather than modifying your
+patches with `git rebase -i`, you should make further changes incrementally -
+that is, with another commit, based on top of the maintainer's topic branch as
+detailed in https://github.com/gitster/git. Your work is still in the same topic
+but is now incremental, rather than a wholesale rewrite of the topic branch.
+
+The topic branches in the maintainer's GitHub are mirrored in GitGitGadget, so
+if you're sending your reviews out that way, you should be sure to open your PR
+against the appropriate GitGitGadget/Git branch.
+
+If you're using `git send-email`, you can use it the same way as before, but you
+should generate your diffs from `<topic>..<mybranch>` and base your work on
+`<topic>` instead of `master`.
diff --git a/MyFirstObjectWalk.adoc b/MyFirstObjectWalk.adoc
new file mode 100644
index 0000000..dec8afe
--- /dev/null
+++ b/MyFirstObjectWalk.adoc
@@ -0,0 +1,898 @@
+= My First Object Walk
+
+== What's an Object Walk?
+
+The object walk is a key concept in Git - this is the process that underpins
+operations like object transfer and fsck. Beginning from a given commit, the
+list of objects is found by walking parent relationships between commits (commit
+X based on commit W) and containment relationships between objects (tree Y is
+contained within commit X, and blob Z is located within tree Y, giving our
+working tree for commit X something like `y/z.txt`).
+
+A related concept is the revision walk, which is focused on commit objects and
+their parent relationships and does not delve into other object types. The
+revision walk is used for operations like `git log`.
+
+=== Related Reading
+
+- `Documentation/user-manual.txt` under "Hacking Git" contains some coverage of
+ the revision walker in its various incarnations.
+- `revision.h`
+- https://eagain.net/articles/git-for-computer-scientists/[Git for Computer Scientists]
+ gives a good overview of the types of objects in Git and what your object
+ walk is really describing.
+
+== Setting Up
+
+Create a new branch from `master`.
+
+----
+git checkout -b revwalk origin/master
+----
+
+We'll put our fiddling into a new command. For fun, let's name it `git walken`.
+Open up a new file `builtin/walken.c` and set up the command handler:
+
+----
+/*
+ * "git walken"
+ *
+ * Part of the "My First Object Walk" tutorial.
+ */
+
+#include "builtin.h"
+#include "trace.h"
+
+int cmd_walken(int argc, const char **argv, const char *prefix)
+{
+ trace_printf(_("cmd_walken incoming...\n"));
+ return 0;
+}
+----
+
+NOTE: `trace_printf()`, defined in `trace.h`, differs from `printf()` in
+that it can be turned on or off at runtime. For the purposes of this
+tutorial, we will write `walken` as though it is intended for use as
+a "plumbing" command: that is, a command which is used primarily in
+scripts, rather than interactively by humans (a "porcelain" command).
+So we will send our debug output to `trace_printf()` instead.
+When running, enable trace output by setting the environment variable `GIT_TRACE`.
+
+Add usage text and `-h` handling, like all subcommands should consistently do
+(our test suite will notice and complain if you fail to do so).
+We'll need to include the `parse-options.h` header.
+
+----
+#include "parse-options.h"
+
+...
+
+int cmd_walken(int argc, const char **argv, const char *prefix)
+{
+ const char * const walken_usage[] = {
+ N_("git walken"),
+ NULL,
+ };
+ struct option options[] = {
+ OPT_END()
+ };
+
+ argc = parse_options(argc, argv, prefix, options, walken_usage, 0);
+
+ ...
+}
+----
+
+Also add the relevant line in `builtin.h` near `cmd_whatchanged()`:
+
+----
+int cmd_walken(int argc, const char **argv, const char *prefix);
+----
+
+Include the command in `git.c` in `commands[]` near the entry for `whatchanged`,
+maintaining alphabetical ordering:
+
+----
+{ "walken", cmd_walken, RUN_SETUP },
+----
+
+Add it to the `Makefile` near the line for `builtin/worktree.o`:
+
+----
+BUILTIN_OBJS += builtin/walken.o
+----
+
+Build and test out your command, without forgetting to ensure the `DEVELOPER`
+flag is set, and with `GIT_TRACE` enabled so the debug output can be seen:
+
+----
+$ echo DEVELOPER=1 >>config.mak
+$ make
+$ GIT_TRACE=1 ./bin-wrappers/git walken
+----
+
+NOTE: For a more exhaustive overview of the new command process, take a look at
+`Documentation/MyFirstContribution.txt`.
+
+NOTE: A reference implementation can be found at
+https://github.com/nasamuffin/git/tree/revwalk.
+
+=== `struct rev_cmdline_info`
+
+The definition of `struct rev_cmdline_info` can be found in `revision.h`.
+
+This struct is contained within the `rev_info` struct and is used to reflect
+parameters provided by the user over the CLI.
+
+`nr` represents the number of `rev_cmdline_entry` present in the array.
+
+`alloc` is used by the `ALLOC_GROW` macro. Check `alloc.h` - this variable is
+used to track the allocated size of the list.
+
+Per entry, we find:
+
+`item` is the object provided upon which to base the object walk. Items in Git
+can be blobs, trees, commits, or tags. (See `Documentation/gittutorial-2.txt`.)
+
+`name` is the object ID (OID) of the object - a hex string you may be familiar
+with from using Git to organize your source in the past. Check the tutorial
+mentioned above towards the top for a discussion of where the OID can come
+from.
+
+`whence` indicates some information about what to do with the parents of the
+specified object. We'll explore this flag more later on; take a look at
+`Documentation/revisions.txt` to get an idea of what could set the `whence`
+value.
+
+`flags` are used to hint the beginning of the revision walk and are the first
+block under the `#include`s in `revision.h`. The most likely ones to be set in
+the `rev_cmdline_info` are `UNINTERESTING` and `BOTTOM`, but these same flags
+can be used during the walk, as well.
+
+=== `struct rev_info`
+
+This one is quite a bit longer, and many fields are only used during the walk
+by `revision.c` - not configuration options. Most of the configurable flags in
+`struct rev_info` have a mirror in `Documentation/rev-list-options.txt`. It's a
+good idea to take some time and read through that document.
+
+== Basic Commit Walk
+
+First, let's see if we can replicate the output of `git log --oneline`. We'll
+refer back to the implementation frequently to discover norms when performing
+an object walk of our own.
+
+To do so, we'll first find all the commits, in order, which preceded the current
+commit. We'll extract the name and subject of the commit from each.
+
+Ideally, we will also be able to find out which ones are currently at the tip of
+various branches.
+
+=== Setting Up
+
+Preparing for your object walk has some distinct stages.
+
+1. Perform default setup for this mode, and others which may be invoked.
+2. Check configuration files for relevant settings.
+3. Set up the `rev_info` struct.
+4. Tweak the initialized `rev_info` to suit the current walk.
+5. Prepare the `rev_info` for the walk.
+6. Iterate over the objects, processing each one.
+
+==== Default Setups
+
+Before examining configuration files which may modify command behavior, set up
+default state for switches or options your command may have. If your command
+utilizes other Git components, ask them to set up their default states as well.
+For instance, `git log` takes advantage of `grep` and `diff` functionality, so
+its `init_log_defaults()` sets its own state (`decoration_style`) and asks
+`grep` and `diff` to initialize themselves by calling each of their
+initialization functions.
+
+==== Configuring From `.gitconfig`
+
+Next, we should have a look at any relevant configuration settings (i.e.,
+settings readable and settable from `git config`). This is done by providing a
+callback to `git_config()`; within that callback, you can also invoke methods
+from other components you may need that need to intercept these options. Your
+callback will be invoked once per each configuration value which Git knows about
+(global, local, worktree, etc.).
+
+Similarly to the default values, we don't have anything to do here yet
+ourselves; however, we should call `git_default_config()` if we aren't calling
+any other existing config callbacks.
+
+Add a new function to `builtin/walken.c`.
+We'll also need to include the `config.h` header:
+
+----
+#include "config.h"
+
+...
+
+static int git_walken_config(const char *var, const char *value,
+ const struct config_context *ctx, void *cb)
+{
+ /*
+ * For now, we don't have any custom configuration, so fall back to
+ * the default config.
+ */
+ return git_default_config(var, value, ctx, cb);
+}
+----
+
+Make sure to invoke `git_config()` with it in your `cmd_walken()`:
+
+----
+int cmd_walken(int argc, const char **argv, const char *prefix)
+{
+ ...
+
+ git_config(git_walken_config, NULL);
+
+ ...
+}
+----
+
+==== Setting Up `rev_info`
+
+Now that we've gathered external configuration and options, it's time to
+initialize the `rev_info` object which we will use to perform the walk. This is
+typically done by calling `repo_init_revisions()` with the repository you intend
+to target, as well as the `prefix` argument of `cmd_walken` and your `rev_info`
+struct.
+
+Add the `struct rev_info` and the `repo_init_revisions()` call.
+We'll also need to include the `revision.h` header:
+
+----
+#include "revision.h"
+
+...
+
+int cmd_walken(int argc, const char **argv, const char *prefix)
+{
+ /* This can go wherever you like in your declarations.*/
+ struct rev_info rev;
+ ...
+
+ /* This should go after the git_config() call. */
+ repo_init_revisions(the_repository, &rev, prefix);
+
+ ...
+}
+----
+
+==== Tweaking `rev_info` For the Walk
+
+We're getting close, but we're still not quite ready to go. Now that `rev` is
+initialized, we can modify it to fit our needs. This is usually done within a
+helper for clarity, so let's add one:
+
+----
+static void final_rev_info_setup(struct rev_info *rev)
+{
+ /*
+ * We want to mimic the appearance of `git log --oneline`, so let's
+ * force oneline format.
+ */
+ get_commit_format("oneline", rev);
+
+ /* Start our object walk at HEAD. */
+ add_head_to_pending(rev);
+}
+----
+
+[NOTE]
+====
+Instead of using the shorthand `add_head_to_pending()`, you could do
+something like this:
+----
+ struct setup_revision_opt opt;
+
+ memset(&opt, 0, sizeof(opt));
+ opt.def = "HEAD";
+ opt.revarg_opt = REVARG_COMMITTISH;
+ setup_revisions(argc, argv, rev, &opt);
+----
+Using a `setup_revision_opt` gives you finer control over your walk's starting
+point.
+====
+
+Then let's invoke `final_rev_info_setup()` after the call to
+`repo_init_revisions()`:
+
+----
+int cmd_walken(int argc, const char **argv, const char *prefix)
+{
+ ...
+
+ final_rev_info_setup(&rev);
+
+ ...
+}
+----
+
+Later, we may wish to add more arguments to `final_rev_info_setup()`. But for
+now, this is all we need.
+
+==== Preparing `rev_info` For the Walk
+
+Now that `rev` is all initialized and configured, we've got one more setup step
+before we get rolling. We can do this in a helper, which will both prepare the
+`rev_info` for the walk, and perform the walk itself. Let's start the helper
+with the call to `prepare_revision_walk()`, which can return an error without
+dying on its own:
+
+----
+static void walken_commit_walk(struct rev_info *rev)
+{
+ if (prepare_revision_walk(rev))
+ die(_("revision walk setup failed"));
+}
+----
+
+NOTE: `die()` prints to `stderr` and exits the program. Since it will print to
+`stderr` it's likely to be seen by a human, so we will localize it.
+
+==== Performing the Walk!
+
+Finally! We are ready to begin the walk itself. Now we can see that `rev_info`
+can also be used as an iterator; we move to the next item in the walk by using
+`get_revision()` repeatedly. Add the listed variable declarations at the top and
+the walk loop below the `prepare_revision_walk()` call within your
+`walken_commit_walk()`:
+
+----
+#include "pretty.h"
+
+...
+
+static void walken_commit_walk(struct rev_info *rev)
+{
+ struct commit *commit;
+ struct strbuf prettybuf = STRBUF_INIT;
+
+ ...
+
+ while ((commit = get_revision(rev))) {
+ strbuf_reset(&prettybuf);
+ pp_commit_easy(CMIT_FMT_ONELINE, commit, &prettybuf);
+ puts(prettybuf.buf);
+ }
+ strbuf_release(&prettybuf);
+}
+----
+
+NOTE: `puts()` prints a `char*` to `stdout`. Since this is the part of the
+command we expect to be machine-parsed, we're sending it directly to stdout.
+
+Give it a shot.
+
+----
+$ make
+$ ./bin-wrappers/git walken
+----
+
+You should see all of the subject lines of all the commits in
+your tree's history, in order, ending with the initial commit, "Initial revision
+of "git", the information manager from hell". Congratulations! You've written
+your first revision walk. You can play with printing some additional fields
+from each commit if you're curious; have a look at the functions available in
+`commit.h`.
+
+=== Adding a Filter
+
+Next, let's try to filter the commits we see based on their author. This is
+equivalent to running `git log --author=<pattern>`. We can add a filter by
+modifying `rev_info.grep_filter`, which is a `struct grep_opt`.
+
+First some setup. Add `grep_config()` to `git_walken_config()`:
+
+----
+static int git_walken_config(const char *var, const char *value,
+ const struct config_context *ctx, void *cb)
+{
+ grep_config(var, value, ctx, cb);
+ return git_default_config(var, value, ctx, cb);
+}
+----
+
+Next, we can modify the `grep_filter`. This is done with convenience functions
+found in `grep.h`. For fun, we're filtering to only commits from folks using a
+`gmail.com` email address - a not-very-precise guess at who may be working on
+Git as a hobby. Since we're checking the author, which is a specific line in the
+header, we'll use the `append_header_grep_pattern()` helper. We can use
+the `enum grep_header_field` to indicate which part of the commit header we want
+to search.
+
+In `final_rev_info_setup()`, add your filter line:
+
+----
+static void final_rev_info_setup(int argc, const char **argv,
+ const char *prefix, struct rev_info *rev)
+{
+ ...
+
+ append_header_grep_pattern(&rev->grep_filter, GREP_HEADER_AUTHOR,
+ "gmail");
+ compile_grep_patterns(&rev->grep_filter);
+
+ ...
+}
+----
+
+`append_header_grep_pattern()` adds your new "gmail" pattern to `rev_info`, but
+it won't work unless we compile it with `compile_grep_patterns()`.
+
+NOTE: If you are using `setup_revisions()` (for example, if you are passing a
+`setup_revision_opt` instead of using `add_head_to_pending()`), you don't need
+to call `compile_grep_patterns()` because `setup_revisions()` calls it for you.
+
+NOTE: We could add the same filter via the `append_grep_pattern()` helper if we
+wanted to, but `append_header_grep_pattern()` adds the `enum grep_context` and
+`enum grep_pat_token` for us.
+
+=== Changing the Order
+
+There are a few ways that we can change the order of the commits during a
+revision walk. Firstly, we can use the `enum rev_sort_order` to choose from some
+typical orderings.
+
+`topo_order` is the same as `git log --topo-order`: we avoid showing a parent
+before all of its children have been shown, and we avoid mixing commits which
+are in different lines of history. (`git help log`'s section on `--topo-order`
+has a very nice diagram to illustrate this.)
+
+Let's see what happens when we run with `REV_SORT_BY_COMMIT_DATE` as opposed to
+`REV_SORT_BY_AUTHOR_DATE`. Add the following:
+
+----
+static void final_rev_info_setup(int argc, const char **argv,
+ const char *prefix, struct rev_info *rev)
+{
+ ...
+
+ rev->topo_order = 1;
+ rev->sort_order = REV_SORT_BY_COMMIT_DATE;
+
+ ...
+}
+----
+
+Let's output this into a file so we can easily diff it with the walk sorted by
+author date.
+
+----
+$ make
+$ ./bin-wrappers/git walken > commit-date.txt
+----
+
+Then, let's sort by author date and run it again.
+
+----
+static void final_rev_info_setup(int argc, const char **argv,
+ const char *prefix, struct rev_info *rev)
+{
+ ...
+
+ rev->topo_order = 1;
+ rev->sort_order = REV_SORT_BY_AUTHOR_DATE;
+
+ ...
+}
+----
+
+----
+$ make
+$ ./bin-wrappers/git walken > author-date.txt
+----
+
+Finally, compare the two. This is a little less helpful without object names or
+dates, but hopefully we get the idea.
+
+----
+$ diff -u commit-date.txt author-date.txt
+----
+
+This display indicates that commits can be reordered after they're written, for
+example with `git rebase`.
+
+Let's try one more reordering of commits. `rev_info` exposes a `reverse` flag.
+Set that flag somewhere inside of `final_rev_info_setup()`:
+
+----
+static void final_rev_info_setup(int argc, const char **argv, const char *prefix,
+ struct rev_info *rev)
+{
+ ...
+
+ rev->reverse = 1;
+
+ ...
+}
+----
+
+Run your walk again and note the difference in order. (If you remove the grep
+pattern, you should see the last commit this call gives you as your current
+HEAD.)
+
+== Basic Object Walk
+
+So far we've been walking only commits. But Git has more types of objects than
+that! Let's see if we can walk _all_ objects, and find out some information
+about each one.
+
+We can base our work on an example. `git pack-objects` prepares all kinds of
+objects for packing into a bitmap or packfile. The work we are interested in
+resides in `builtin/pack-objects.c:get_object_list()`; examination of that
+function shows that the all-object walk is being performed by
+`traverse_commit_list()` or `traverse_commit_list_filtered()`. Those two
+functions reside in `list-objects.c`; examining the source shows that, despite
+the name, these functions traverse all kinds of objects. Let's have a look at
+the arguments to `traverse_commit_list()`.
+
+- `struct rev_info *revs`: This is the `rev_info` used for the walk. If
+ its `filter` member is not `NULL`, then `filter` contains information for
+ how to filter the object list.
+- `show_commit_fn show_commit`: A callback which will be used to handle each
+ individual commit object.
+- `show_object_fn show_object`: A callback which will be used to handle each
+ non-commit object (so each blob, tree, or tag).
+- `void *show_data`: A context buffer which is passed in turn to `show_commit`
+ and `show_object`.
+
+In addition, `traverse_commit_list_filtered()` has an additional parameter:
+
+- `struct oidset *omitted`: A linked-list of object IDs which the provided
+ filter caused to be omitted.
+
+It looks like these methods use callbacks we provide instead of needing us
+to call it repeatedly ourselves. Cool! Let's add the callbacks first.
+
+For the sake of this tutorial, we'll simply keep track of how many of each kind
+of object we find. At file scope in `builtin/walken.c` add the following
+tracking variables:
+
+----
+static int commit_count;
+static int tag_count;
+static int blob_count;
+static int tree_count;
+----
+
+Commits are handled by a different callback than other objects; let's do that
+one first:
+
+----
+static void walken_show_commit(struct commit *cmt, void *buf)
+{
+ commit_count++;
+}
+----
+
+The `cmt` argument is fairly self-explanatory. But it's worth mentioning that
+the `buf` argument is actually the context buffer that we can provide to the
+traversal calls - `show_data`, which we mentioned a moment ago.
+
+Since we have the `struct commit` object, we can look at all the same parts that
+we looked at in our earlier commit-only walk. For the sake of this tutorial,
+though, we'll just increment the commit counter and move on.
+
+The callback for non-commits is a little different, as we'll need to check
+which kind of object we're dealing with:
+
+----
+static void walken_show_object(struct object *obj, const char *str, void *buf)
+{
+ switch (obj->type) {
+ case OBJ_TREE:
+ tree_count++;
+ break;
+ case OBJ_BLOB:
+ blob_count++;
+ break;
+ case OBJ_TAG:
+ tag_count++;
+ break;
+ case OBJ_COMMIT:
+ BUG("unexpected commit object in walken_show_object\n");
+ default:
+ BUG("unexpected object type %s in walken_show_object\n",
+ type_name(obj->type));
+ }
+}
+----
+
+Again, `obj` is fairly self-explanatory, and we can guess that `buf` is the same
+context pointer that `walken_show_commit()` receives: the `show_data` argument
+to `traverse_commit_list()` and `traverse_commit_list_filtered()`. Finally,
+`str` contains the name of the object, which ends up being something like
+`foo.txt` (blob), `bar/baz` (tree), or `v1.2.3` (tag).
+
+To help assure us that we aren't double-counting commits, we'll include some
+complaining if a commit object is routed through our non-commit callback; we'll
+also complain if we see an invalid object type. Since those two cases should be
+unreachable, and would only change in the event of a semantic change to the Git
+codebase, we complain by using `BUG()` - which is a signal to a developer that
+the change they made caused unintended consequences, and the rest of the
+codebase needs to be updated to understand that change. `BUG()` is not intended
+to be seen by the public, so it is not localized.
+
+Our main object walk implementation is substantially different from our commit
+walk implementation, so let's make a new function to perform the object walk. We
+can perform setup which is applicable to all objects here, too, to keep separate
+from setup which is applicable to commit-only walks.
+
+We'll start by enabling all types of objects in the `struct rev_info`. We'll
+also turn on `tree_blobs_in_commit_order`, which means that we will walk a
+commit's tree and everything it points to immediately after we find each commit,
+as opposed to waiting for the end and walking through all trees after the commit
+history has been discovered. With the appropriate settings configured, we are
+ready to call `prepare_revision_walk()`.
+
+----
+static void walken_object_walk(struct rev_info *rev)
+{
+ rev->tree_objects = 1;
+ rev->blob_objects = 1;
+ rev->tag_objects = 1;
+ rev->tree_blobs_in_commit_order = 1;
+
+ if (prepare_revision_walk(rev))
+ die(_("revision walk setup failed"));
+
+ commit_count = 0;
+ tag_count = 0;
+ blob_count = 0;
+ tree_count = 0;
+----
+
+Let's start by calling just the unfiltered walk and reporting our counts.
+Complete your implementation of `walken_object_walk()`.
+We'll also need to include the `list-objects.h` header.
+
+----
+#include "list-objects.h"
+
+...
+
+ traverse_commit_list(rev, walken_show_commit, walken_show_object, NULL);
+
+ printf("commits %d\nblobs %d\ntags %d\ntrees %d\n", commit_count,
+ blob_count, tag_count, tree_count);
+}
+----
+
+NOTE: This output is intended to be machine-parsed. Therefore, we are not
+sending it to `trace_printf()`, and we are not localizing it - we need scripts
+to be able to count on the formatting to be exactly the way it is shown here.
+If we were intending this output to be read by humans, we would need to localize
+it with `_()`.
+
+Finally, we'll ask `cmd_walken()` to use the object walk instead. Discussing
+command line options is out of scope for this tutorial, so we'll just hardcode
+a branch we can change at compile time. Where you call `final_rev_info_setup()`
+and `walken_commit_walk()`, instead branch like so:
+
+----
+ if (1) {
+ add_head_to_pending(&rev);
+ walken_object_walk(&rev);
+ } else {
+ final_rev_info_setup(argc, argv, prefix, &rev);
+ walken_commit_walk(&rev);
+ }
+----
+
+NOTE: For simplicity, we've avoided all the filters and sorts we applied in
+`final_rev_info_setup()` and simply added `HEAD` to our pending queue. If you
+want, you can certainly use the filters we added before by moving
+`final_rev_info_setup()` out of the conditional and removing the call to
+`add_head_to_pending()`.
+
+Now we can try to run our command! It should take noticeably longer than the
+commit walk, but an examination of the output will give you an idea why. Your
+output should look similar to this example, but with different counts:
+
+----
+Object walk completed. Found 55733 commits, 100274 blobs, 0 tags, and 104210 trees.
+----
+
+This makes sense. We have more trees than commits because the Git project has
+lots of subdirectories which can change, plus at least one tree per commit. We
+have no tags because we started on a commit (`HEAD`) and while tags can point to
+commits, commits can't point to tags.
+
+NOTE: You will have different counts when you run this yourself! The number of
+objects grows along with the Git project.
+
+=== Adding a Filter
+
+There are a handful of filters that we can apply to the object walk laid out in
+`Documentation/rev-list-options.txt`. These filters are typically useful for
+operations such as creating packfiles or performing a partial clone. They are
+defined in `list-objects-filter-options.h`. For the purposes of this tutorial we
+will use the "tree:1" filter, which causes the walk to omit all trees and blobs
+which are not directly referenced by commits reachable from the commit in
+`pending` when the walk begins. (`pending` is the list of objects which need to
+be traversed during a walk; you can imagine a breadth-first tree traversal to
+help understand. In our case, that means we omit trees and blobs not directly
+referenced by `HEAD` or `HEAD`'s history, because we begin the walk with only
+`HEAD` in the `pending` list.)
+
+For now, we are not going to track the omitted objects, so we'll replace those
+parameters with `NULL`. For the sake of simplicity, we'll add a simple
+build-time branch to use our filter or not. Preface the line calling
+`traverse_commit_list()` with the following, which will remind us which kind of
+walk we've just performed:
+
+----
+ if (0) {
+ /* Unfiltered: */
+ trace_printf(_("Unfiltered object walk.\n"));
+ } else {
+ trace_printf(
+ _("Filtered object walk with filterspec 'tree:1'.\n"));
+
+ parse_list_objects_filter(&rev->filter, "tree:1");
+ }
+ traverse_commit_list(rev, walken_show_commit,
+ walken_show_object, NULL);
+----
+
+The `rev->filter` member is usually built directly from a command
+line argument, so the module provides an easy way to build one from a string.
+Even though we aren't taking user input right now, we can still build one with
+a hardcoded string using `parse_list_objects_filter()`.
+
+With the filter spec "tree:1", we are expecting to see _only_ the root tree for
+each commit; therefore, the tree object count should be less than or equal to
+the number of commits. (For an example of why that's true: `git commit --revert`
+points to the same tree object as its grandparent.)
+
+=== Counting Omitted Objects
+
+We also have the capability to enumerate all objects which were omitted by a
+filter, like with `git log --filter=<spec> --filter-print-omitted`. To do this,
+change `traverse_commit_list()` to `traverse_commit_list_filtered()`, which is
+able to populate an `omitted` list. Asking for this list of filtered objects
+may cause performance degradations, however, because in this case, despite
+filtering objects, the possibly much larger set of all reachable objects must
+be processed in order to populate that list.
+
+First, add the `struct oidset` and related items we will use to iterate it:
+
+----
+#include "oidset.h"
+
+...
+
+static void walken_object_walk(
+ ...
+
+ struct oidset omitted;
+ struct oidset_iter oit;
+ struct object_id *oid = NULL;
+ int omitted_count = 0;
+ oidset_init(&omitted, 0);
+
+ ...
+----
+
+Replace the call to `traverse_commit_list()` with
+`traverse_commit_list_filtered()` and pass a pointer to the `omitted` oidset
+defined and initialized above:
+
+----
+ ...
+
+ traverse_commit_list_filtered(rev,
+ walken_show_commit, walken_show_object, NULL, &omitted);
+
+ ...
+----
+
+Then, after your traversal, the `oidset` traversal is pretty straightforward.
+Count all the objects within and modify the print statement:
+
+----
+ /* Count the omitted objects. */
+ oidset_iter_init(&omitted, &oit);
+
+ while ((oid = oidset_iter_next(&oit)))
+ omitted_count++;
+
+ printf("commits %d\nblobs %d\ntags %d\ntrees %d\nomitted %d\n",
+ commit_count, blob_count, tag_count, tree_count, omitted_count);
+----
+
+By running your walk with and without the filter, you should find that the total
+object count in each case is identical. You can also time each invocation of
+the `walken` subcommand, with and without `omitted` being passed in, to confirm
+to yourself the runtime impact of tracking all omitted objects.
+
+=== Changing the Order
+
+Finally, let's demonstrate that you can also reorder walks of all objects, not
+just walks of commits. First, we'll make our handlers chattier - modify
+`walken_show_commit()` and `walken_show_object()` to print the object as they
+go:
+
+----
+#include "hex.h"
+
+...
+
+static void walken_show_commit(struct commit *cmt, void *buf)
+{
+ trace_printf("commit: %s\n", oid_to_hex(&cmt->object.oid));
+ commit_count++;
+}
+
+static void walken_show_object(struct object *obj, const char *str, void *buf)
+{
+ trace_printf("%s: %s\n", type_name(obj->type), oid_to_hex(&obj->oid));
+
+ ...
+}
+----
+
+NOTE: Since we will be examining this output directly as humans, we'll use
+`trace_printf()` here. Additionally, since this change introduces a significant
+number of printed lines, using `trace_printf()` will allow us to easily silence
+those lines without having to recompile.
+
+(Leave the counter increment logic in place.)
+
+With only that change, run again (but save yourself some scrollback):
+
+----
+$ GIT_TRACE=1 ./bin-wrappers/git walken 2>&1 | head -n 10
+----
+
+Take a look at the top commit with `git show` and the object ID you printed; it
+should be the same as the output of `git show HEAD`.
+
+Next, let's change a setting on our `struct rev_info` within
+`walken_object_walk()`. Find where you're changing the other settings on `rev`,
+such as `rev->tree_objects` and `rev->tree_blobs_in_commit_order`, and add the
+`reverse` setting at the bottom:
+
+----
+ ...
+
+ rev->tree_objects = 1;
+ rev->blob_objects = 1;
+ rev->tag_objects = 1;
+ rev->tree_blobs_in_commit_order = 1;
+ rev->reverse = 1;
+
+ ...
+----
+
+Now, run again, but this time, let's grab the last handful of objects instead
+of the first handful:
+
+----
+$ make
+$ GIT_TRACE=1 ./bin-wrappers/git walken 2>&1 | tail -n 10
+----
+
+The last commit object given should have the same OID as the one we saw at the
+top before, and running `git show <oid>` with that OID should give you again
+the same results as `git show HEAD`. Furthermore, if you run and examine the
+first ten lines again (with `head` instead of `tail` like we did before applying
+the `reverse` setting), you should see that now the first commit printed is the
+initial commit, `e83c5163`.
+
+== Wrapping Up
+
+Let's review. In this tutorial, we:
+
+- Built a commit walk from the ground up
+- Enabled a grep filter for that commit walk
+- Changed the sort order of that filtered commit walk
+- Built an object walk (tags, commits, trees, and blobs) from the ground up
+- Learned how to add a filter-spec to an object walk
+- Changed the display order of the filtered object walk
diff --git a/RelNotes/1.5.0.1.adoc b/RelNotes/1.5.0.1.adoc
new file mode 100644
index 0000000..fea3f99
--- /dev/null
+++ b/RelNotes/1.5.0.1.adoc
@@ -0,0 +1,42 @@
+GIT v1.5.0.1 Release Notes
+==========================
+
+Fixes since v1.5.0
+------------------
+
+* Documentation updates
+
+ - Clarifications and corrections to 1.5.0 release notes.
+
+ - The main documentation did not link to git-remote documentation.
+
+ - Clarified introductory text of git-rebase documentation.
+
+ - Converted remaining mentions of update-index on Porcelain
+ documents to git-add/git-rm.
+
+ - Some i18n.* configuration variables were incorrectly
+ described as core.*; fixed.
+
+* Bugfixes
+
+ - git-add and git-update-index on a filesystem on which
+ executable bits are unreliable incorrectly reused st_mode
+ bits even when the path changed between symlink and regular
+ file.
+
+ - git-daemon marks the listening sockets with FD_CLOEXEC so
+ that it won't be leaked into the children.
+
+ - segfault from git-blame when the mandatory pathname
+ parameter was missing was fixed; usage() message is given
+ instead.
+
+ - git-rev-list did not read $GIT_DIR/config file, which means
+ that did not honor i18n.logoutputencoding correctly.
+
+* Tweaks
+
+ - sliding mmap() inefficiently mmaped the same region of a
+ packfile with an access pattern that used objects in the
+ reverse order. This has been made more efficient.
diff --git a/RelNotes/1.5.0.2.adoc b/RelNotes/1.5.0.2.adoc
new file mode 100644
index 0000000..b061e50
--- /dev/null
+++ b/RelNotes/1.5.0.2.adoc
@@ -0,0 +1,65 @@
+GIT v1.5.0.2 Release Notes
+==========================
+
+Fixes since v1.5.0.1
+--------------------
+
+* Bugfixes
+
+ - Automated merge conflict handling when changes to symbolic
+ links conflicted were completely broken. The merge-resolve
+ strategy created a regular file with conflict markers in it
+ in place of the symbolic link. The default strategy,
+ merge-recursive was even more broken. It removed the path
+ that was pointed at by the symbolic link. Both of these
+ problems have been fixed.
+
+ - 'git diff maint master next' did not correctly give combined
+ diff across three trees.
+
+ - 'git fast-import' portability fix for Solaris.
+
+ - 'git show-ref --verify' without arguments did not error out
+ but segfaulted.
+
+ - 'git diff :tracked-file `pwd`/an-untracked-file' gave an extra
+ slashes after a/ and b/.
+
+ - 'git format-patch' produced too long filenames if the commit
+ message had too long line at the beginning.
+
+ - Running 'make all' and then without changing anything
+ running 'make install' still rebuilt some files. This
+ was inconvenient when building as yourself and then
+ installing as root (especially problematic when the source
+ directory is on NFS and root is mapped to nobody).
+
+ - 'git-rerere' failed to deal with two unconflicted paths that
+ sorted next to each other.
+
+ - 'git-rerere' attempted to open(2) a symlink and failed if
+ there was a conflict. Since a conflicting change to a
+ symlink would not benefit from rerere anyway, the command
+ now ignores conflicting changes to symlinks.
+
+ - 'git-repack' did not like to pass more than 64 arguments
+ internally to underlying 'rev-list' logic, which made it
+ impossible to repack after accumulating many (small) packs
+ in the repository.
+
+ - 'git-diff' to review the combined diff during a conflicted
+ merge were not reading the working tree version correctly
+ when changes to a symbolic link conflicted. It should have
+ read the data using readlink(2) but read from the regular
+ file the symbolic link pointed at.
+
+ - 'git-remote' did not like period in a remote's name.
+
+* Documentation updates
+
+ - added and clarified core.bare, core.legacyheaders configurations.
+
+ - updated "git-clone --depth" documentation.
+
+
+* Assorted git-gui fixes.
diff --git a/RelNotes/1.5.0.3.adoc b/RelNotes/1.5.0.3.adoc
new file mode 100644
index 0000000..cd500f9
--- /dev/null
+++ b/RelNotes/1.5.0.3.adoc
@@ -0,0 +1,58 @@
+GIT v1.5.0.3 Release Notes
+==========================
+
+Fixes since v1.5.0.2
+--------------------
+
+* Bugfixes
+
+ - 'git.el' honors the commit coding system from the configuration.
+
+ - 'blameview' in contrib/ correctly digs deeper when a line is
+ clicked.
+
+ - 'http-push' correctly makes sure the remote side has leading
+ path. Earlier it started in the middle of the path, and
+ incorrectly.
+
+ - 'git-merge' did not exit with non-zero status when the
+ working tree was dirty and cannot fast forward. It does
+ now.
+
+ - 'cvsexportcommit' does not lose yet-to-be-used message file.
+
+ - int-vs-size_t typefix when running combined diff on files
+ over 2GB long.
+
+ - 'git apply --whitespace=strip' should not touch unmodified
+ lines.
+
+ - 'git-mailinfo' choke when a logical header line was too long.
+
+ - 'git show A..B' did not error out. Negative ref ("not A" in
+ this example) does not make sense for the purpose of the
+ command, so now it errors out.
+
+ - 'git fmt-merge-msg --file' without file parameter did not
+ correctly error out.
+
+ - 'git archimport' barfed upon encountering a commit without
+ summary.
+
+ - 'git index-pack' did not protect itself from getting a short
+ read out of pread(2).
+
+ - 'git http-push' had a few buffer overruns.
+
+ - Build dependency fixes to rebuild fetch.o when other headers
+ change.
+
+* Documentation updates
+
+ - user-manual updates.
+
+ - Options to 'git remote add' were described insufficiently.
+
+ - Configuration format.suffix was not documented.
+
+ - Other formatting and spelling fixes.
diff --git a/RelNotes/1.5.0.4.adoc b/RelNotes/1.5.0.4.adoc
new file mode 100644
index 0000000..feefa5d
--- /dev/null
+++ b/RelNotes/1.5.0.4.adoc
@@ -0,0 +1,22 @@
+GIT v1.5.0.4 Release Notes
+==========================
+
+Fixes since v1.5.0.3
+--------------------
+
+* Bugfixes
+
+ - git.el does not add duplicate sign-off lines.
+
+ - git-commit shows the full stat of the resulting commit, not
+ just about the files in the current directory, when run from
+ a subdirectory.
+
+ - "git-checkout -m '@{8 hours ago}'" had a funny failure from
+ eval; fixed.
+
+ - git-gui updates.
+
+* Documentation updates
+
+* User manual updates
diff --git a/RelNotes/1.5.0.5.adoc b/RelNotes/1.5.0.5.adoc
new file mode 100644
index 0000000..eeec3d7
--- /dev/null
+++ b/RelNotes/1.5.0.5.adoc
@@ -0,0 +1,26 @@
+GIT v1.5.0.5 Release Notes
+==========================
+
+Fixes since v1.5.0.3
+--------------------
+
+* Bugfixes
+
+ - git-merge (hence git-pull) did not refuse fast-forwarding
+ when the working tree had local changes that would have
+ conflicted with it.
+
+ - git.el does not add duplicate sign-off lines.
+
+ - git-commit shows the full stat of the resulting commit, not
+ just about the files in the current directory, when run from
+ a subdirectory.
+
+ - "git-checkout -m '@{8 hours ago}'" had a funny failure from
+ eval; fixed.
+
+ - git-gui updates.
+
+* Documentation updates
+
+* User manual updates
diff --git a/RelNotes/1.5.0.6.adoc b/RelNotes/1.5.0.6.adoc
new file mode 100644
index 0000000..c02015a
--- /dev/null
+++ b/RelNotes/1.5.0.6.adoc
@@ -0,0 +1,21 @@
+GIT v1.5.0.6 Release Notes
+==========================
+
+Fixes since v1.5.0.5
+--------------------
+
+* Bugfixes
+
+ - a handful small fixes to gitweb.
+
+ - build procedure for user-manual is fixed not to require locally
+ installed stylesheets.
+
+ - "git commit $paths" on paths whose earlier contents were
+ already updated in the index were failing out.
+
+* Documentation
+
+ - user-manual has better cross references.
+
+ - gitweb installation/deployment procedure is now documented.
diff --git a/RelNotes/1.5.0.7.adoc b/RelNotes/1.5.0.7.adoc
new file mode 100644
index 0000000..670ad32
--- /dev/null
+++ b/RelNotes/1.5.0.7.adoc
@@ -0,0 +1,18 @@
+GIT v1.5.0.7 Release Notes
+==========================
+
+Fixes since v1.5.0.6
+--------------------
+
+* Bugfixes
+
+ - git-upload-pack failed to close unused pipe ends, resulting
+ in many zombies to hang around.
+
+ - git-rerere was recording the contents of earlier hunks
+ duplicated in later hunks. This prevented resolving the same
+ conflict when performing the same merge the other way around.
+
+* Documentation
+
+ - a few documentation fixes from Debian package maintainer.
diff --git a/RelNotes/1.5.0.adoc b/RelNotes/1.5.0.adoc
new file mode 100644
index 0000000..d6d42f3
--- /dev/null
+++ b/RelNotes/1.5.0.adoc
@@ -0,0 +1,469 @@
+GIT v1.5.0 Release Notes
+========================
+
+Old news
+--------
+
+This section is for people who are upgrading from ancient
+versions of git. Although all of the changes in this section
+happened before the current v1.4.4 release, they are summarized
+here in the v1.5.0 release notes for people who skipped earlier
+versions.
+
+As of git v1.5.0 there are some optional features that changes
+the repository to allow data to be stored and transferred more
+efficiently. These features are not enabled by default, as they
+will make the repository unusable with older versions of git.
+Specifically, the available options are:
+
+ - There is a configuration variable core.legacyheaders that
+ changes the format of loose objects so that they are more
+ efficient to pack and to send out of the repository over git
+ native protocol, since v1.4.2. However, loose objects
+ written in the new format cannot be read by git older than
+ that version; people fetching from your repository using
+ older clients over dumb transports (e.g. http) using older
+ versions of git will also be affected.
+
+ To let git use the new loose object format, you have to
+ set core.legacyheaders to false.
+
+ - Since v1.4.3, configuration repack.usedeltabaseoffset allows
+ packfile to be created in more space efficient format, which
+ cannot be read by git older than that version.
+
+ To let git use the new format for packfiles, you have to
+ set repack.usedeltabaseoffset to true.
+
+The above two new features are not enabled by default and you
+have to explicitly ask for them, because they make repositories
+unreadable by older versions of git, and in v1.5.0 we still do
+not enable them by default for the same reason. We will change
+this default probably 1 year after 1.4.2's release, when it is
+reasonable to expect everybody to have new enough version of
+git.
+
+ - 'git pack-refs' appeared in v1.4.4; this command allows tags
+ to be accessed much more efficiently than the traditional
+ 'one-file-per-tag' format. Older git-native clients can
+ still fetch from a repository that packed and pruned refs
+ (the server side needs to run the up-to-date version of git),
+ but older dumb transports cannot. Packing of refs is done by
+ an explicit user action, either by use of "git pack-refs
+ --prune" command or by use of "git gc" command.
+
+ - 'git -p' to paginate anything -- many commands do pagination
+ by default on a tty. Introduced between v1.4.1 and v1.4.2;
+ this may surprise old timers.
+
+ - 'git archive' superseded 'git tar-tree' in v1.4.3;
+
+ - 'git cvsserver' was new invention in v1.3.0;
+
+ - 'git repo-config', 'git grep', 'git rebase' and 'gitk' were
+ seriously enhanced during v1.4.0 timeperiod.
+
+ - 'gitweb' became part of git.git during v1.4.0 timeperiod and
+ seriously modified since then.
+
+ - reflog is an v1.4.0 invention. This allows you to name a
+ revision that a branch used to be at (e.g. "git diff
+ master@{yesterday} master" allows you to see changes since
+ yesterday's tip of the branch).
+
+
+Updates in v1.5.0 since v1.4.4 series
+-------------------------------------
+
+* Index manipulation
+
+ - git-add is to add contents to the index (aka "staging area"
+ for the next commit), whether the file the contents happen to
+ be is an existing one or a newly created one.
+
+ - git-add without any argument does not add everything
+ anymore. Use 'git-add .' instead. Also you can add
+ otherwise ignored files with an -f option.
+
+ - git-add tries to be more friendly to users by offering an
+ interactive mode ("git-add -i").
+
+ - git-commit <path> used to refuse to commit if <path> was
+ different between HEAD and the index (i.e. update-index was
+ used on it earlier). This check was removed.
+
+ - git-rm is much saner and safer. It is used to remove paths
+ from both the index file and the working tree, and makes sure
+ you are not losing any local modification before doing so.
+
+ - git-reset <tree> <paths>... can be used to revert index
+ entries for selected paths.
+
+ - git-update-index is much less visible. Many suggestions to
+ use the command in git output and documentation have now been
+ replaced by simpler commands such as "git add" or "git rm".
+
+
+* Repository layout and objects transfer
+
+ - The data for origin repository is stored in the configuration
+ file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly
+ created clones. The latter is still supported and there is
+ no need to convert your existing repository if you are
+ already comfortable with your workflow with the layout.
+
+ - git-clone always uses what is known as "separate remote"
+ layout for a newly created repository with a working tree.
+
+ A repository with the separate remote layout starts with only
+ one default branch, 'master', to be used for your own
+ development. Unlike the traditional layout that copied all
+ the upstream branches into your branch namespace (while
+ renaming their 'master' to your 'origin'), the new layout
+ puts upstream branches into local "remote-tracking branches"
+ with their own namespace. These can be referenced with names
+ such as "origin/$upstream_branch_name" and are stored in
+ .git/refs/remotes rather than .git/refs/heads where normal
+ branches are stored.
+
+ This layout keeps your own branch namespace less cluttered,
+ avoids name collision with your upstream, makes it possible
+ to automatically track new branches created at the remote
+ after you clone from it, and makes it easier to interact with
+ more than one remote repository (you can use "git remote" to
+ add other repositories to track). There might be some
+ surprises:
+
+ * 'git branch' does not show the remote tracking branches.
+ It only lists your own branches. Use '-r' option to view
+ the tracking branches.
+
+ * If you are forking off of a branch obtained from the
+ upstream, you would have done something like 'git branch
+ my-next next', because traditional layout dropped the
+ tracking branch 'next' into your own branch namespace.
+ With the separate remote layout, you say 'git branch next
+ origin/next', which allows you to use the matching name
+ 'next' for your own branch. It also allows you to track a
+ remote other than 'origin' (i.e. where you initially cloned
+ from) and fork off of a branch from there the same way
+ (e.g. "git branch mingw j6t/master").
+
+ Repositories initialized with the traditional layout continue
+ to work.
+
+ - New branches that appear on the origin side after a clone is
+ made are also tracked automatically. This is done with an
+ wildcard refspec "refs/heads/*:refs/remotes/origin/*", which
+ older git does not understand, so if you clone with 1.5.0,
+ you would need to downgrade remote.*.fetch in the
+ configuration file to specify each branch you are interested
+ in individually if you plan to fetch into the repository with
+ older versions of git (but why would you?).
+
+ - Similarly, wildcard refspec "refs/heads/*:refs/remotes/me/*"
+ can be given to "git-push" command to update the tracking
+ branches that is used to track the repository you are pushing
+ from on the remote side.
+
+ - git-branch and git-show-branch know remote tracking branches
+ (use the command line switch "-r" to list only tracked branches).
+
+ - git-push can now be used to delete a remote branch or a tag.
+ This requires the updated git on the remote side (use "git
+ push <remote> :refs/heads/<branch>" to delete "branch").
+
+ - git-push more aggressively keeps the transferred objects
+ packed. Earlier we recommended to monitor amount of loose
+ objects and repack regularly, but you should repack when you
+ accumulated too many small packs this way as well. Updated
+ git-count-objects helps you with this.
+
+ - git-fetch also more aggressively keeps the transferred objects
+ packed. This behavior of git-push and git-fetch can be
+ tweaked with a single configuration transfer.unpacklimit (but
+ usually there should not be any need for a user to tweak it).
+
+ - A new command, git-remote, can help you manage your remote
+ tracking branch definitions.
+
+ - You may need to specify explicit paths for upload-pack and/or
+ receive-pack due to your ssh daemon configuration on the
+ other end. This can now be done via remote.*.uploadpack and
+ remote.*.receivepack configuration.
+
+
+* Bare repositories
+
+ - Certain commands change their behavior in a bare repository
+ (i.e. a repository without associated working tree). We use
+ a fairly conservative heuristic (if $GIT_DIR is ".git", or
+ ends with "/.git", the repository is not bare) to decide if a
+ repository is bare, but "core.bare" configuration variable
+ can be used to override the heuristic when it misidentifies
+ your repository.
+
+ - git-fetch used to complain updating the current branch but
+ this is now allowed for a bare repository. So is the use of
+ 'git-branch -f' to update the current branch.
+
+ - Porcelain-ish commands that require a working tree refuses to
+ work in a bare repository.
+
+
+* Reflog
+
+ - Reflog records the history from the view point of the local
+ repository. In other words, regardless of the real history,
+ the reflog shows the history as seen by one particular
+ repository (this enables you to ask "what was the current
+ revision in _this_ repository, yesterday at 1pm?"). This
+ facility is enabled by default for repositories with working
+ trees, and can be accessed with the "branch@{time}" and
+ "branch@{Nth}" notation.
+
+ - "git show-branch" learned showing the reflog data with the
+ new -g option. "git log" has -g option to view reflog
+ entries in a more verbose manner.
+
+ - git-branch knows how to rename branches and moves existing
+ reflog data from the old branch to the new one.
+
+ - In addition to the reflog support in v1.4.4 series, HEAD
+ reference maintains its own log. "HEAD@{5.minutes.ago}"
+ means the commit you were at 5 minutes ago, which takes
+ branch switching into account. If you want to know where the
+ tip of your current branch was at 5 minutes ago, you need to
+ explicitly say its name (e.g. "master@{5.minutes.ago}") or
+ omit the refname altogether i.e. "@{5.minutes.ago}".
+
+ - The commits referred to by reflog entries are now protected
+ against pruning. The new command "git reflog expire" can be
+ used to truncate older reflog entries and entries that refer
+ to commits that have been pruned away previously with older
+ versions of git.
+
+ Existing repositories that have been using reflog may get
+ complaints from fsck-objects and may not be able to run
+ git-repack, if you had run git-prune from older git; please
+ run "git reflog expire --stale-fix --all" first to remove
+ reflog entries that refer to commits that are no longer in
+ the repository when that happens.
+
+
+* Cruft removal
+
+ - We used to say "old commits are retrievable using reflog and
+ 'master@{yesterday}' syntax as long as you haven't run
+ git-prune". We no longer have to say the latter half of the
+ above sentence, as git-prune does not remove things reachable
+ from reflog entries.
+
+ - There is a toplevel garbage collector script, 'git-gc', that
+ runs periodic cleanup functions, including 'git-repack -a -d',
+ 'git-reflog expire', 'git-pack-refs --prune', and 'git-rerere
+ gc'.
+
+ - The output from fsck ("fsck-objects" is called just "fsck"
+ now, but the old name continues to work) was needlessly
+ alarming in that it warned missing objects that are reachable
+ only from dangling objects. This has been corrected and the
+ output is much more useful.
+
+
+* Detached HEAD
+
+ - You can use 'git-checkout' to check out an arbitrary revision
+ or a tag as well, instead of named branches. This will
+ dissociate your HEAD from the branch you are currently on.
+
+ A typical use of this feature is to "look around". E.g.
+
+ $ git checkout v2.6.16
+ ... compile, test, etc.
+ $ git checkout v2.6.17
+ ... compile, test, etc.
+
+ - After detaching your HEAD, you can go back to an existing
+ branch with usual "git checkout $branch". Also you can
+ start a new branch using "git checkout -b $newbranch" to
+ start a new branch at that commit.
+
+ - You can even pull from other repositories, make merges and
+ commits while your HEAD is detached. Also you can use "git
+ reset" to jump to arbitrary commit, while still keeping your
+ HEAD detached.
+
+ Remember that a detached state is volatile, i.e. it will be forgotten
+ as soon as you move away from it with the checkout or reset command,
+ unless a branch is created from it as mentioned above. It is also
+ possible to rescue a lost detached state from the HEAD reflog.
+
+
+* Packed refs
+
+ - Repositories with hundreds of tags have been paying large
+ overhead, both in storage and in runtime, due to the
+ traditional one-ref-per-file format. A new command,
+ git-pack-refs, can be used to "pack" them in more efficient
+ representation (you can let git-gc do this for you).
+
+ - Clones and fetches over dumb transports are now aware of
+ packed refs and can download from repositories that use
+ them.
+
+
+* Configuration
+
+ - configuration related to color setting are consolidated under
+ color.* namespace (older diff.color.*, status.color.* are
+ still supported).
+
+ - 'git-repo-config' command is accessible as 'git-config' now.
+
+
+* Updated features
+
+ - git-describe uses better criteria to pick a base ref. It
+ used to pick the one with the newest timestamp, but now it
+ picks the one that is topologically the closest (that is,
+ among ancestors of commit C, the ref T that has the shortest
+ output from "git-rev-list T..C" is chosen).
+
+ - git-describe gives the number of commits since the base ref
+ between the refname and the hash suffix. E.g. the commit one
+ before v2.6.20-rc6 in the kernel repository is:
+
+ v2.6.20-rc5-306-ga21b069
+
+ which tells you that its object name begins with a21b069,
+ v2.6.20-rc5 is an ancestor of it (meaning, the commit
+ contains everything -rc5 has), and there are 306 commits
+ since v2.6.20-rc5.
+
+ - git-describe with --abbrev=0 can be used to show only the
+ name of the base ref.
+
+ - git-blame learned a new option, --incremental, that tells it
+ to output the blames as they are assigned. A sample script
+ to use it is also included as contrib/blameview.
+
+ - git-blame starts annotating from the working tree by default.
+
+
+* Less external dependency
+
+ - We no longer require the "merge" program from the RCS suite.
+ All 3-way file-level merges are now done internally.
+
+ - The original implementation of git-merge-recursive which was
+ in Python has been removed; we have a C implementation of it
+ now.
+
+ - git-shortlog is no longer a Perl script. It no longer
+ requires output piped from git-log; it can accept revision
+ parameters directly on the command line.
+
+
+* I18n
+
+ - We have always encouraged the commit message to be encoded in
+ UTF-8, but the users are allowed to use legacy encoding as
+ appropriate for their projects. This will continue to be the
+ case. However, a non UTF-8 commit encoding _must_ be
+ explicitly set with i18n.commitencoding in the repository
+ where a commit is made; otherwise git-commit-tree will
+ complain if the log message does not look like a valid UTF-8
+ string.
+
+ - The value of i18n.commitencoding in the originating
+ repository is recorded in the commit object on the "encoding"
+ header, if it is not UTF-8. git-log and friends notice this,
+ and re-encodes the message to the log output encoding when
+ displaying, if they are different. The log output encoding
+ is determined by "git log --encoding=<encoding>",
+ i18n.logoutputencoding configuration, or i18n.commitencoding
+ configuration, in the decreasing order of preference, and
+ defaults to UTF-8.
+
+ - Tools for e-mailed patch application now default to -u
+ behavior; i.e. it always re-codes from the e-mailed encoding
+ to the encoding specified with i18n.commitencoding. This
+ unfortunately forces projects that have happily been using a
+ legacy encoding without setting i18n.commitencoding to set
+ the configuration, but taken with other improvement, please
+ excuse us for this very minor one-time inconvenience.
+
+
+* e-mailed patches
+
+ - See the above I18n section.
+
+ - git-format-patch now enables --binary without being asked.
+ git-am does _not_ default to it, as sending binary patch via
+ e-mail is unusual and is harder to review than textual
+ patches and it is prudent to require the person who is
+ applying the patch to explicitly ask for it.
+
+ - The default suffix for git-format-patch output is now ".patch",
+ not ".txt". This can be changed with --suffix=.txt option,
+ or setting the config variable "format.suffix" to ".txt".
+
+
+* Foreign SCM interfaces
+
+ - git-svn now requires the Perl SVN:: libraries, the
+ command-line backend was too slow and limited.
+
+ - the 'commit' subcommand of git-svn has been renamed to
+ 'set-tree', and 'dcommit' is the recommended replacement for
+ day-to-day work.
+
+ - git fast-import backend.
+
+
+* User support
+
+ - Quite a lot of documentation updates.
+
+ - Bash completion scripts have been updated heavily.
+
+ - Better error messages for often used Porcelainish commands.
+
+ - Git GUI. This is a simple Tk based graphical interface for
+ common Git operations.
+
+
+* Sliding mmap
+
+ - We used to assume that we can mmap the whole packfile while
+ in use, but with a large project this consumes huge virtual
+ memory space and truly huge ones would not fit in the
+ userland address space on 32-bit platforms. We now mmap huge
+ packfile in pieces to avoid this problem.
+
+
+* Shallow clones
+
+ - There is a partial support for 'shallow' repositories that
+ keeps only recent history. A 'shallow clone' is created by
+ specifying how deep that truncated history should be
+ (e.g. "git clone --depth 5 git://some.where/repo.git").
+
+ Currently a shallow repository has number of limitations:
+
+ - Cloning and fetching _from_ a shallow clone are not
+ supported (nor tested -- so they might work by accident but
+ they are not expected to).
+
+ - Pushing from nor into a shallow clone are not expected to
+ work.
+
+ - Merging inside a shallow repository would work as long as a
+ merge base is found in the recent history, but otherwise it
+ will be like merging unrelated histories and may result in
+ huge conflicts.
+
+ but this would be more than adequate for people who want to
+ look at near the tip of a big project with a deep history and
+ send patches in e-mail format.
diff --git a/RelNotes/1.5.1.1.adoc b/RelNotes/1.5.1.1.adoc
new file mode 100644
index 0000000..9147121
--- /dev/null
+++ b/RelNotes/1.5.1.1.adoc
@@ -0,0 +1,65 @@
+GIT v1.5.1.1 Release Notes
+==========================
+
+Fixes since v1.5.1
+------------------
+
+* Documentation updates
+
+ - The --left-right option of rev-list and friends is documented.
+
+ - The documentation for cvsimport has been majorly improved.
+
+ - "git-show-ref --exclude-existing" was documented.
+
+* Bugfixes
+
+ - The implementation of -p option in "git cvsexportcommit" had
+ the meaning of -C (context reduction) option wrong, and
+ loosened the context requirements when it was told to be
+ strict.
+
+ - "git cvsserver" did not behave like the real cvsserver when
+ client side removed a file from the working tree without
+ doing anything else on the path. In such a case, it should
+ restore it from the checked out revision.
+
+ - "git fsck" issued an alarming error message on detached
+ HEAD. It is not an error since at least 1.5.0.
+
+ - "git send-email" produced of References header of unbounded length;
+ fixed this with line-folding.
+
+ - "git archive" to download from remote site should not
+ require you to be in a git repository, but it incorrectly
+ did.
+
+ - "git apply" ignored -p<n> for "diff --git" formatted
+ patches.
+
+ - "git rerere" recorded a conflict that had one side empty
+ (the other side adds) incorrectly; this made merging in the
+ other direction fail to use previously recorded resolution.
+
+ - t4200 test was broken where "wc -l" pads its output with
+ spaces.
+
+ - "git branch -m old new" to rename branch did not work
+ without a configuration file in ".git/config".
+
+ - The sample hook for notification e-mail was misnamed.
+
+ - gitweb did not show type-changing patch correctly in the
+ blobdiff view.
+
+ - git-svn did not error out with incorrect command line options.
+
+ - git-svn fell into an infinite loop when insanely long commit
+ message was found.
+
+ - git-svn dcommit and rebase was confused by patches that were
+ merged from another branch that is managed by git-svn.
+
+ - git-svn used to get confused when globbing remote branch/tag
+ spec (e.g. "branches = proj/branches/*:refs/remotes/origin/*")
+ is used and there was a plain file that matched the glob.
diff --git a/RelNotes/1.5.1.2.adoc b/RelNotes/1.5.1.2.adoc
new file mode 100644
index 0000000..d884563
--- /dev/null
+++ b/RelNotes/1.5.1.2.adoc
@@ -0,0 +1,50 @@
+GIT v1.5.1.2 Release Notes
+==========================
+
+Fixes since v1.5.1.1
+--------------------
+
+* Bugfixes
+
+ - "git clone" over http from a repository that has lost the
+ loose refs by running "git pack-refs" were broken (a code to
+ deal with this was added to "git fetch" in v1.5.0, but it
+ was missing from "git clone").
+
+ - "git diff a/ b/" incorrectly fell in "diff between two
+ filesystem objects" codepath, when the user most likely
+ wanted to limit the extent of output to two tracked
+ directories.
+
+ - git-quiltimport had the same bug as we fixed for
+ git-applymbox in v1.5.1.1 -- it gave an alarming "did not
+ have any patch" message (but did not actually fail and was
+ harmless).
+
+ - various git-svn fixes.
+
+ - Sample update hook incorrectly always refused requests to
+ delete branches through push.
+
+ - git-blame on a very long working tree path had buffer
+ overrun problem.
+
+ - git-apply did not like to be fed two patches in a row that created
+ and then modified the same file.
+
+ - git-svn was confused when a non-project was stored directly under
+ trunk/, branches/ and tags/.
+
+ - git-svn wants the Error.pm module that was at least as new
+ as what we ship as part of git; install ours in our private
+ installation location if the one on the system is older.
+
+ - An earlier update to command line integer parameter parser was
+ botched and made 'update-index --cacheinfo' completely useless.
+
+
+* Documentation updates
+
+ - Various documentation updates from J. Bruce Fields, Frank
+ Lichtenheld, Alex Riesen and others. Andrew Ruder started a
+ war on undocumented options.
diff --git a/RelNotes/1.5.1.3.adoc b/RelNotes/1.5.1.3.adoc
new file mode 100644
index 0000000..876408b
--- /dev/null
+++ b/RelNotes/1.5.1.3.adoc
@@ -0,0 +1,45 @@
+GIT v1.5.1.3 Release Notes
+==========================
+
+Fixes since v1.5.1.2
+--------------------
+
+* Bugfixes
+
+ - git-add tried to optimize by finding common leading
+ directories across its arguments but botched, causing very
+ confused behaviour.
+
+ - unofficial rpm.spec file shipped with git was letting
+ ETC_GITCONFIG set to /usr/etc/gitconfig. Tweak the official
+ Makefile to make it harder for distro people to make the
+ same mistake, by setting the variable to /etc/gitconfig if
+ prefix is set to /usr.
+
+ - git-svn inconsistently stripped away username from the URL
+ only when svnsync_props was in use.
+
+ - git-svn got confused when handling symlinks on Mac OS.
+
+ - git-send-email was not quoting recipient names that have
+ period '.' in them. Also it did not allow overriding
+ envelope sender, which made it impossible to send patches to
+ certain subscriber-only lists.
+
+ - built-in write_tree() routine had a sequence that renamed a
+ file that is still open, which some systems did not like.
+
+ - when memory is very tight, sliding mmap code to read
+ packfiles incorrectly closed the fd that was still being
+ used to read the pack.
+
+ - import-tars contributed front-end for fastimport was passing
+ wrong directory modes without checking.
+
+ - git-fastimport trusted its input too much and allowed to
+ create corrupt tree objects with entries without a name.
+
+ - git-fetch needlessly barfed when too long reflog action
+ description was given by the caller.
+
+Also contains various documentation updates.
diff --git a/RelNotes/1.5.1.4.adoc b/RelNotes/1.5.1.4.adoc
new file mode 100644
index 0000000..df2f66c
--- /dev/null
+++ b/RelNotes/1.5.1.4.adoc
@@ -0,0 +1,30 @@
+GIT v1.5.1.4 Release Notes
+==========================
+
+Fixes since v1.5.1.3
+--------------------
+
+* Bugfixes
+
+ - "git-http-fetch" did not work around a bug in libcurl
+ earlier than 7.16 (curl_multi_remove_handle() was broken).
+
+ - "git cvsserver" handles a file that was once removed and
+ then added again correctly.
+
+ - import-tars script (in contrib/) handles GNU tar archives
+ that contain pathnames longer than 100 bytes (long-link
+ extension) correctly.
+
+ - xdelta test program did not build correctly.
+
+ - gitweb sometimes tried incorrectly to apply function to
+ decode utf8 twice, resulting in corrupt output.
+
+ - "git blame -C" mishandled text at the end of a group of
+ lines.
+
+ - "git log/rev-list --boundary" did not produce output
+ correctly without --left-right option.
+
+ - Many documentation updates.
diff --git a/RelNotes/1.5.1.5.adoc b/RelNotes/1.5.1.5.adoc
new file mode 100644
index 0000000..b0ab8eb
--- /dev/null
+++ b/RelNotes/1.5.1.5.adoc
@@ -0,0 +1,42 @@
+GIT v1.5.1.5 Release Notes
+==========================
+
+Fixes since v1.5.1.4
+--------------------
+
+* Bugfixes
+
+ - git-send-email did not understand aliases file for mutt, which
+ allows leading whitespaces.
+
+ - git-format-patch emitted Content-Type and Content-Transfer-Encoding
+ headers for non ASCII contents, but failed to add MIME-Version.
+
+ - git-name-rev had a buffer overrun with a deep history.
+
+ - contributed script import-tars did not get the directory in
+ tar archives interpreted correctly.
+
+ - git-svn was reported to segfault for many people on list and
+ #git; hopefully this has been fixed.
+
+ - "git-svn clone" does not try to minimize the URL
+ (i.e. connect to higher level hierarchy) by default, as this
+ can prevent clone to fail if only part of the repository
+ (e.g. 'trunk') is open to public.
+
+ - "git checkout branch^0" did not detach the head when you are
+ already on 'branch'; backported the fix from the 'master'.
+
+ - "git-config section.var" did not correctly work when
+ existing configuration file had both [section] and [section "name"]
+ next to each other.
+
+ - "git clone ../other-directory" was fooled if the current
+ directory $PWD points at is a symbolic link.
+
+ - (build) tree_entry_extract() function was both static inline
+ and extern, which caused trouble compiling with Forte12
+ compilers on Sun.
+
+ - Many many documentation fixes and updates.
diff --git a/RelNotes/1.5.1.6.adoc b/RelNotes/1.5.1.6.adoc
new file mode 100644
index 0000000..55f3ac1
--- /dev/null
+++ b/RelNotes/1.5.1.6.adoc
@@ -0,0 +1,45 @@
+GIT v1.5.1.6 Release Notes
+==========================
+
+Fixes since v1.5.1.4
+--------------------
+
+* Bugfixes
+
+ - git-send-email did not understand aliases file for mutt, which
+ allows leading whitespaces.
+
+ - git-format-patch emitted Content-Type and Content-Transfer-Encoding
+ headers for non ASCII contents, but failed to add MIME-Version.
+
+ - git-name-rev had a buffer overrun with a deep history.
+
+ - contributed script import-tars did not get the directory in
+ tar archives interpreted correctly.
+
+ - git-svn was reported to segfault for many people on list and
+ #git; hopefully this has been fixed.
+
+ - git-svn also had a bug to crash svnserve by sending a bad
+ sequence of requests.
+
+ - "git-svn clone" does not try to minimize the URL
+ (i.e. connect to higher level hierarchy) by default, as this
+ can prevent clone to fail if only part of the repository
+ (e.g. 'trunk') is open to public.
+
+ - "git checkout branch^0" did not detach the head when you are
+ already on 'branch'; backported the fix from the 'master'.
+
+ - "git-config section.var" did not correctly work when
+ existing configuration file had both [section] and [section "name"]
+ next to each other.
+
+ - "git clone ../other-directory" was fooled if the current
+ directory $PWD points at is a symbolic link.
+
+ - (build) tree_entry_extract() function was both static inline
+ and extern, which caused trouble compiling with Forte12
+ compilers on Sun.
+
+ - Many many documentation fixes and updates.
diff --git a/RelNotes/1.5.1.adoc b/RelNotes/1.5.1.adoc
new file mode 100644
index 0000000..daed367
--- /dev/null
+++ b/RelNotes/1.5.1.adoc
@@ -0,0 +1,371 @@
+GIT v1.5.1 Release Notes
+========================
+
+Updates since v1.5.0
+--------------------
+
+* Deprecated commands and options.
+
+ - git-diff-stages and git-resolve have been removed.
+
+* New commands and options.
+
+ - "git log" and friends take --reverse, which instructs them
+ to give their output in the order opposite from their usual.
+ They typically output from new to old, but with this option
+ their output would read from old to new. "git shortlog"
+ usually lists older commits first, but with this option,
+ they are shown from new to old.
+
+ - "git log --pretty=format:<string>" to allow more flexible
+ custom log output.
+
+ - "git diff" learned --ignore-space-at-eol. This is a weaker
+ form of --ignore-space-change.
+
+ - "git diff --no-index pathA pathB" can be used as diff
+ replacement with git specific enhancements.
+
+ - "git diff --no-index" can read from '-' (standard input).
+
+ - "git diff" also learned --exit-code to exit with non-zero
+ status when it found differences. In the future we might
+ want to make this the default but that would be a rather big
+ backward incompatible change; it will stay as an option for
+ now.
+
+ - "git diff --quiet" is --exit-code with output turned off,
+ meant for scripted use to quickly determine if there is any
+ tree-level difference.
+
+ - Textual patch generation with "git diff" without -w/-b
+ option has been significantly optimized. "git blame" got
+ faster because of the same change.
+
+ - "git log" and "git rev-list" has been optimized
+ significantly when they are used with pathspecs.
+
+ - "git branch --track" can be used to set up configuration
+ variables to help it easier to base your work on branches
+ you track from a remote site.
+
+ - "git format-patch --attach" now emits attachments. Use
+ --inline to get an inlined multipart/mixed.
+
+ - "git name-rev" learned --refs=<pattern>, to limit the tags
+ used for naming the given revisions only to the ones
+ matching the given pattern.
+
+ - "git remote update" is to run "git fetch" for defined remotes
+ to update tracking branches.
+
+ - "git cvsimport" can now take '-d' to talk with a CVS
+ repository different from what are recorded in CVS/Root
+ (overriding it with environment CVSROOT does not work).
+
+ - "git bundle" can help sneaker-netting your changes between
+ repositories.
+
+ - "git mergetool" can help 3-way file-level conflict
+ resolution with your favorite graphical merge tools.
+
+ - A new configuration "core.symlinks" can be used to disable
+ symlinks on filesystems that do not support them; they are
+ checked out as regular files instead.
+
+ - You can name a commit object with its first line of the
+ message. The syntax to use is ':/message text'. E.g.
+
+ $ git show ":/object name: introduce ':/<oneline prefix>' notation"
+
+ means the same thing as:
+
+ $ git show 28a4d940443806412effa246ecc7768a21553ec7
+
+ - "git bisect" learned a new command "run" that takes a script
+ to run after each revision is checked out to determine if it
+ is good or bad, to automate the bisection process.
+
+ - "git log" family learned a new traversal option --first-parent,
+ which does what the name suggests.
+
+
+* Updated behavior of existing commands.
+
+ - "git-merge-recursive" used to barf when there are more than
+ one common ancestors for the merge, and merging them had a
+ rename/rename conflict. This has been fixed.
+
+ - "git fsck" does not barf on corrupt loose objects.
+
+ - "git rm" does not remove newly added files without -f.
+
+ - "git archimport" allows remapping when coming up with git
+ branch names from arch names.
+
+ - git-svn got almost a rewrite.
+
+ - core.autocrlf configuration, when set to 'true', makes git
+ to convert CRLF at the end of lines in text files to LF when
+ reading from the filesystem, and convert in reverse when
+ writing to the filesystem. The variable can be set to
+ 'input', in which case the conversion happens only while
+ reading from the filesystem but files are written out with
+ LF at the end of lines. Currently, which paths to consider
+ 'text' (i.e. be subjected to the autocrlf mechanism) is
+ decided purely based on the contents, but the plan is to
+ allow users to explicitly override this heuristic based on
+ paths.
+
+ - The behavior of 'git-apply', when run in a subdirectory,
+ without --index nor --cached were inconsistent with that of
+ the command with these options. This was fixed to match the
+ behavior with --index. A patch that is meant to be applied
+ with -p1 from the toplevel of the project tree can be
+ applied with any custom -p<n> option. A patch that is not
+ relative to the toplevel needs to be applied with -p<n>
+ option with or without --index (or --cached).
+
+ - "git diff" outputs a trailing HT when pathnames have embedded
+ SP on +++/--- header lines, in order to help "GNU patch" to
+ parse its output. "git apply" was already updated to accept
+ this modified output format since ce74618d (Sep 22, 2006).
+
+ - "git cvsserver" runs hooks/update and honors its exit status.
+
+ - "git cvsserver" can be told to send everything with -kb.
+
+ - "git diff --check" also honors the --color output option.
+
+ - "git name-rev" used to stress the fact that a ref is a tag too
+ much, by saying something like "v1.2.3^0~22". It now says
+ "v1.2.3~22" in such a case (it still says "v1.2.3^0" if it does
+ not talk about an ancestor of the commit that is tagged, which
+ makes sense).
+
+ - "git rev-list --boundary" now shows boundary markers for the
+ commits omitted by --max-age and --max-count condition.
+
+ - The configuration mechanism now reads $(prefix)/etc/gitconfig.
+
+ - "git apply --verbose" shows what preimage lines were wanted
+ when it couldn't find them.
+
+ - "git status" in a read-only repository got a bit saner.
+
+ - "git fetch" (hence "git clone" and "git pull") are less
+ noisy when the output does not go to tty.
+
+ - "git fetch" between repositories with many refs were slow
+ even when there are not many changes that needed
+ transferring. This has been sped up by partially rewriting
+ the heaviest parts in C.
+
+ - "git mailinfo" which splits an e-mail into a patch and the
+ meta-information was rewritten, thanks to Don Zickus. It
+ handles nested multipart better. The command was broken for
+ a brief period on 'master' branch since 1.5.0 but the
+ breakage is fixed now.
+
+ - send-email learned configurable bcc and chain-reply-to.
+
+ - "git remote show $remote" also talks about branches that
+ would be pushed if you run "git push remote".
+
+ - Using objects from packs is now seriously optimized by clever
+ use of a cache. This should be most noticeable in git-log
+ family of commands that involve reading many tree objects.
+ In addition, traversing revisions while filtering changes
+ with pathspecs is made faster by terminating the comparison
+ between the trees as early as possible.
+
+
+* Hooks
+
+ - The part to send out notification e-mails was removed from
+ the sample update hook, as it was not an appropriate place
+ to do so. The proper place to do this is the new post-receive
+ hook. An example hook has been added to contrib/hooks/.
+
+
+* Others
+
+ - git-revert, git-gc and git-cherry-pick are now built-ins.
+
+Fixes since v1.5.0
+------------------
+
+These are all in v1.5.0.x series.
+
+* Documentation updates
+
+ - Clarifications and corrections to 1.5.0 release notes.
+
+ - The main documentation did not link to git-remote documentation.
+
+ - Clarified introductory text of git-rebase documentation.
+
+ - Converted remaining mentions of update-index on Porcelain
+ documents to git-add/git-rm.
+
+ - Some i18n.* configuration variables were incorrectly
+ described as core.*; fixed.
+
+ - added and clarified core.bare, core.legacyheaders configurations.
+
+ - updated "git-clone --depth" documentation.
+
+ - user-manual updates.
+
+ - Options to 'git remote add' were described insufficiently.
+
+ - Configuration format.suffix was not documented.
+
+ - Other formatting and spelling fixes.
+
+ - user-manual has better cross references.
+
+ - gitweb installation/deployment procedure is now documented.
+
+
+* Bugfixes
+
+ - git-upload-pack closes unused pipe ends; earlier this caused
+ many zombies to hang around.
+
+ - git-rerere was recording the contents of earlier hunks
+ duplicated in later hunks. This prevented resolving the same
+ conflict when performing the same merge the other way around.
+
+ - git-add and git-update-index on a filesystem on which
+ executable bits are unreliable incorrectly reused st_mode
+ bits even when the path changed between symlink and regular
+ file.
+
+ - git-daemon marks the listening sockets with FD_CLOEXEC so
+ that it won't be leaked into the children.
+
+ - segfault from git-blame when the mandatory pathname
+ parameter was missing was fixed; usage() message is given
+ instead.
+
+ - git-rev-list did not read $GIT_DIR/config file, which means
+ that did not honor i18n.logoutputencoding correctly.
+
+ - Automated merge conflict handling when changes to symbolic
+ links conflicted were completely broken. The merge-resolve
+ strategy created a regular file with conflict markers in it
+ in place of the symbolic link. The default strategy,
+ merge-recursive was even more broken. It removed the path
+ that was pointed at by the symbolic link. Both of these
+ problems have been fixed.
+
+ - 'git diff maint master next' did not correctly give combined
+ diff across three trees.
+
+ - 'git fast-import' portability fix for Solaris.
+
+ - 'git show-ref --verify' without arguments did not error out
+ but segfaulted.
+
+ - 'git diff :tracked-file `pwd`/an-untracked-file' gave an extra
+ slashes after a/ and b/.
+
+ - 'git format-patch' produced too long filenames if the commit
+ message had too long line at the beginning.
+
+ - Running 'make all' and then without changing anything
+ running 'make install' still rebuilt some files. This
+ was inconvenient when building as yourself and then
+ installing as root (especially problematic when the source
+ directory is on NFS and root is mapped to nobody).
+
+ - 'git-rerere' failed to deal with two unconflicted paths that
+ sorted next to each other.
+
+ - 'git-rerere' attempted to open(2) a symlink and failed if
+ there was a conflict. Since a conflicting change to a
+ symlink would not benefit from rerere anyway, the command
+ now ignores conflicting changes to symlinks.
+
+ - 'git-repack' did not like to pass more than 64 arguments
+ internally to underlying 'rev-list' logic, which made it
+ impossible to repack after accumulating many (small) packs
+ in the repository.
+
+ - 'git-diff' to review the combined diff during a conflicted
+ merge were not reading the working tree version correctly
+ when changes to a symbolic link conflicted. It should have
+ read the data using readlink(2) but read from the regular
+ file the symbolic link pointed at.
+
+ - 'git-remote' did not like period in a remote's name.
+
+ - 'git.el' honors the commit coding system from the configuration.
+
+ - 'blameview' in contrib/ correctly digs deeper when a line is
+ clicked.
+
+ - 'http-push' correctly makes sure the remote side has leading
+ path. Earlier it started in the middle of the path, and
+ incorrectly.
+
+ - 'git-merge' did not exit with non-zero status when the
+ working tree was dirty and cannot fast forward. It does
+ now.
+
+ - 'cvsexportcommit' does not lose yet-to-be-used message file.
+
+ - int-vs-size_t typefix when running combined diff on files
+ over 2GB long.
+
+ - 'git apply --whitespace=strip' should not touch unmodified
+ lines.
+
+ - 'git-mailinfo' choke when a logical header line was too long.
+
+ - 'git show A..B' did not error out. Negative ref ("not A" in
+ this example) does not make sense for the purpose of the
+ command, so now it errors out.
+
+ - 'git fmt-merge-msg --file' without file parameter did not
+ correctly error out.
+
+ - 'git archimport' barfed upon encountering a commit without
+ summary.
+
+ - 'git index-pack' did not protect itself from getting a short
+ read out of pread(2).
+
+ - 'git http-push' had a few buffer overruns.
+
+ - Build dependency fixes to rebuild fetch.o when other headers
+ change.
+
+ - git.el does not add duplicate sign-off lines.
+
+ - git-commit shows the full stat of the resulting commit, not
+ just about the files in the current directory, when run from
+ a subdirectory.
+
+ - "git-checkout -m '@{8 hours ago}'" had a funny failure from
+ eval; fixed.
+
+ - git-merge (hence git-pull) did not refuse fast-forwarding
+ when the working tree had local changes that would have
+ conflicted with it.
+
+ - a handful small fixes to gitweb.
+
+ - build procedure for user-manual is fixed not to require locally
+ installed stylesheets.
+
+ - "git commit $paths" on paths whose earlier contents were
+ already updated in the index were failing out.
+
+
+* Tweaks
+
+ - sliding mmap() inefficiently mmaped the same region of a
+ packfile with an access pattern that used objects in the
+ reverse order. This has been made more efficient.
diff --git a/RelNotes/1.5.2.1.adoc b/RelNotes/1.5.2.1.adoc
new file mode 100644
index 0000000..d41984d
--- /dev/null
+++ b/RelNotes/1.5.2.1.adoc
@@ -0,0 +1,47 @@
+GIT v1.5.2.1 Release Notes
+==========================
+
+Fixes since v1.5.2
+------------------
+
+* Bugfixes
+
+ - Temporary files that are used when invoking external diff
+ programs did not tolerate a long TMPDIR.
+
+ - git-daemon did not notice when it could not write into its
+ pid file.
+
+ - git-status did not honor core.excludesFile configuration like
+ git-add did.
+
+ - git-annotate did not work from a subdirectory while
+ git-blame did.
+
+ - git-cvsserver should have disabled access to a repository
+ with "gitcvs.pserver.enabled = false" set even when
+ "gitcvs.enabled = true" was set at the same time. It
+ didn't.
+
+ - git-cvsimport did not work correctly in a repository with
+ its branch heads were packed with pack-refs.
+
+ - ident unexpansion to squash "$Id: xxx $" that is in the
+ repository copy removed incorrect number of bytes.
+
+ - git-svn misbehaved when the subversion repository did not
+ provide MD5 checksums for files.
+
+ - git rebase (and git am) misbehaved on commits that have '\n'
+ (literally backslash and en, not a linefeed) in the title.
+
+ - code to decode base85 used in binary patches had one error
+ return codepath wrong.
+
+ - RFC2047 Q encoding output by git-format-patch used '_' for a
+ space, which is not understood by some programs. It uses =20
+ which is safer.
+
+ - git-fastimport --import-marks was broken; fixed.
+
+ - A lot of documentation updates, clarifications and fixes.
diff --git a/RelNotes/1.5.2.2.adoc b/RelNotes/1.5.2.2.adoc
new file mode 100644
index 0000000..7bfa341
--- /dev/null
+++ b/RelNotes/1.5.2.2.adoc
@@ -0,0 +1,61 @@
+GIT v1.5.2.2 Release Notes
+==========================
+
+Fixes since v1.5.2.1
+--------------------
+
+* Usability fix
+
+ - git-gui is shipped with its updated blame interface. It is
+ rumored that the older one was not just unusable but was
+ active health hazard, but this one is actually pretty.
+ Please see for yourself.
+
+* Bugfixes
+
+ - "git checkout fubar" was utterly confused when there is a
+ branch fubar and a tag fubar at the same time. It correctly
+ checks out the branch fubar now.
+
+ - "git clone /path/foo" to clone a local /path/foo.git
+ repository left an incorrect configuration.
+
+ - "git send-email" correctly unquotes RFC 2047 quoted names in
+ the patch-email before using their values.
+
+ - We did not accept number of seconds since epoch older than
+ year 2000 as a valid timestamp. We now interpret positive
+ integers more than 8 digits as such, which allows us to
+ express timestamps more recent than March 1973.
+
+ - git-cvsimport did not work when you have GIT_DIR to point
+ your repository at a nonstandard location.
+
+ - Some systems (notably, Solaris) lack hstrerror() to make
+ h_errno human readable; prepare a replacement
+ implementation.
+
+ - .gitignore file listed git-core.spec but what we generate is
+ git.spec, and nobody noticed for a long time.
+
+ - "git-merge-recursive" does not try to run file level merge
+ on binary files.
+
+ - "git-branch --track" did not create tracking configuration
+ correctly when the branch name had slash in it.
+
+ - The email address of the user specified with user.email
+ configuration was overridden by EMAIL environment variable.
+
+ - The tree parser did not warn about tree entries with
+ nonsense file modes, and assumed they must be blobs.
+
+ - "git log -z" without any other request to generate diff still
+ invoked the diff machinery, wasting cycles.
+
+* Documentation
+
+ - Many updates to fix stale or missing documentation.
+
+ - Although our documentation was primarily meant to be formatted
+ with AsciiDoc7, formatting with AsciiDoc8 is supported better.
diff --git a/RelNotes/1.5.2.3.adoc b/RelNotes/1.5.2.3.adoc
new file mode 100644
index 0000000..addb229
--- /dev/null
+++ b/RelNotes/1.5.2.3.adoc
@@ -0,0 +1,27 @@
+GIT v1.5.2.3 Release Notes
+==========================
+
+Fixes since v1.5.2.2
+--------------------
+
+ * Bugfixes
+
+ - Version 2 pack index format was introduced in version 1.5.2
+ to support pack files that has offset that cannot be
+ represented in 32-bit. The runtime code to validate such
+ an index mishandled such an index for an empty pack.
+
+ - Commit walkers (most notably, fetch over http protocol)
+ tried to traverse commit objects contained in trees (aka
+ subproject); they shouldn't.
+
+ - A build option NO_R_TO_GCC_LINKER was not explained in Makefile
+ comment correctly.
+
+ * Documentation Fixes and Updates
+
+ - git-config --regexp was not documented properly.
+
+ - git-repack -a was not documented properly.
+
+ - git-remote -n was not documented properly.
diff --git a/RelNotes/1.5.2.4.adoc b/RelNotes/1.5.2.4.adoc
new file mode 100644
index 0000000..75cff47
--- /dev/null
+++ b/RelNotes/1.5.2.4.adoc
@@ -0,0 +1,28 @@
+GIT v1.5.2.4 Release Notes
+==========================
+
+Fixes since v1.5.2.3
+--------------------
+
+ * Bugfixes
+
+ - "git-gui" bugfixes, including a handful fixes to run it
+ better on Cygwin/MSYS.
+
+ - "git checkout" failed to switch back and forth between
+ branches, one of which has "frotz -> xyzzy" symlink and
+ file "xyzzy/filfre", while the other one has a file
+ "frotz/filfre".
+
+ - "git prune" used to segfault upon seeing a commit that is
+ referred to by a tree object (aka "subproject").
+
+ - "git diff --name-status --no-index" mishandled an added file.
+
+ - "git apply --reverse --whitespace=warn" still complained
+ about whitespaces that a forward application would have
+ introduced.
+
+ * Documentation Fixes and Updates
+
+ - A handful documentation updates.
diff --git a/RelNotes/1.5.2.5.adoc b/RelNotes/1.5.2.5.adoc
new file mode 100644
index 0000000..e8281c7
--- /dev/null
+++ b/RelNotes/1.5.2.5.adoc
@@ -0,0 +1,30 @@
+GIT v1.5.2.5 Release Notes
+==========================
+
+Fixes since v1.5.2.4
+--------------------
+
+ * Bugfixes
+
+ - "git add -u" had a serious data corruption problem in one
+ special case (when the changes to a subdirectory's files
+ consist only deletion of files).
+
+ - "git add -u <path>" did not work from a subdirectory.
+
+ - "git apply" left an empty directory after all its files are
+ renamed away.
+
+ - "git $anycmd foo/bar", when there is a file 'foo' in the
+ working tree, complained that "git $anycmd foo/bar --" form
+ should be used to disambiguate between revs and files,
+ which was completely bogus.
+
+ - "git checkout-index" and other commands that checks out
+ files to the work tree tried unlink(2) on directories,
+ which is a sane thing to do on sane systems, but not on
+ Solaris when you are root.
+
+ * Documentation Fixes and Updates
+
+ - A handful documentation fixes.
diff --git a/RelNotes/1.5.2.adoc b/RelNotes/1.5.2.adoc
new file mode 100644
index 0000000..e8328d0
--- /dev/null
+++ b/RelNotes/1.5.2.adoc
@@ -0,0 +1,197 @@
+GIT v1.5.2 Release Notes
+========================
+
+Updates since v1.5.1
+--------------------
+
+* Plumbing level superproject support.
+
+ You can include a subdirectory that has an independent git
+ repository in your index and tree objects of your project
+ ("superproject"). This plumbing (i.e. "core") level
+ superproject support explicitly excludes recursive behaviour.
+
+ The "subproject" entries in the index and trees of a superproject
+ are incompatible with older versions of git. Experimenting with
+ the plumbing level support is encouraged, but be warned that
+ unless everybody in your project updates to this release or
+ later, using this feature would make your project
+ inaccessible by people with older versions of git.
+
+* Plumbing level gitattributes support.
+
+ The gitattributes mechanism allows you to add 'attributes' to
+ paths in your project, and affect the way certain git
+ operations work. Currently you can influence if a path is
+ considered a binary or text (the former would be treated by
+ 'git diff' not to produce textual output; the latter can go
+ through the line endings conversion process in repositories
+ with core.autocrlf set), expand and unexpand '$Id$' keyword
+ with blob object name, specify a custom 3-way merge driver,
+ and specify a custom diff driver. You can also apply
+ arbitrary filter to contents on check-in/check-out codepath
+ but this feature is an extremely sharp-edged razor and needs
+ to be handled with caution (do not use it unless you
+ understand the earlier mailing list discussion on keyword
+ expansion). These conversions apply when checking files in
+ or out, and exporting via git-archive.
+
+* The packfile format now optionally supports 64-bit index.
+
+ This release supports the "version 2" format of the .idx
+ file. This is automatically enabled when a huge packfile
+ needs more than 32-bit to express offsets of objects in the
+ pack.
+
+* Comes with an updated git-gui 0.7.1
+
+* Updated gitweb:
+
+ - can show combined diff for merges;
+ - uses font size of user's preference, not hardcoded in pixels;
+ - can now 'grep';
+
+* New commands and options.
+
+ - "git bisect start" can optionally take a single bad commit and
+ zero or more good commits on the command line.
+
+ - "git shortlog" can optionally be told to wrap its output.
+
+ - "subtree" merge strategy allows another project to be merged in as
+ your subdirectory.
+
+ - "git format-patch" learned a new --subject-prefix=<string>
+ option, to override the built-in "[PATCH]".
+
+ - "git add -u" is a quick way to do the first stage of "git
+ commit -a" (i.e. update the index to match the working
+ tree); it obviously does not make a commit.
+
+ - "git clean" honors a new configuration, "clean.requireforce". When
+ set to true, this makes "git clean" a no-op, preventing you
+ from losing files by typing "git clean" when you meant to
+ say "make clean". You can still say "git clean -f" to
+ override this.
+
+ - "git log" family of commands learned --date={local,relative,default}
+ option. --date=relative is synonym to the --relative-date.
+ --date=local gives the timestamp in local timezone.
+
+* Updated behavior of existing commands.
+
+ - When $GIT_COMMITTER_EMAIL or $GIT_AUTHOR_EMAIL is not set
+ but $EMAIL is set, the latter is used as a substitute.
+
+ - "git diff --stat" shows size of preimage and postimage blobs
+ for binary contents. Earlier it only said "Bin".
+
+ - "git lost-found" shows stuff that are unreachable except
+ from reflogs.
+
+ - "git checkout branch^0" now detaches HEAD at the tip commit
+ on the named branch, instead of just switching to the
+ branch (use "git checkout branch" to switch to the branch,
+ as before).
+
+ - "git bisect next" can be used after giving only a bad commit
+ without giving a good one (this starts bisection half-way to
+ the root commit). We used to refuse to operate without a
+ good and a bad commit.
+
+ - "git push", when pushing into more than one repository, does
+ not stop at the first error.
+
+ - "git archive" does not insist you to give --format parameter
+ anymore; it defaults to "tar".
+
+ - "git cvsserver" can use backends other than sqlite.
+
+ - "gitview" (in contrib/ section) learned to better support
+ "git-annotate".
+
+ - "git diff $commit1:$path2 $commit2:$path2" can now report
+ mode changes between the two blobs.
+
+ - Local "git fetch" from a repository whose object store is
+ one of the alternates (e.g. fetching from the origin in a
+ repository created with "git clone -l -s") avoids
+ downloading objects unnecessarily.
+
+ - "git blame" uses .mailmap to canonicalize the author name
+ just like "git shortlog" does.
+
+ - "git pack-objects" pays attention to pack.depth
+ configuration variable.
+
+ - "git cherry-pick" and "git revert" does not use .msg file in
+ the working tree to prepare commit message; instead it uses
+ $GIT_DIR/MERGE_MSG as other commands do.
+
+* Builds
+
+ - git-p4import has never been installed; now there is an
+ installation option to do so.
+
+ - gitk and git-gui can be configured out.
+
+ - Generated documentation pages automatically get version
+ information from GIT_VERSION.
+
+ - Parallel build with "make -j" descending into subdirectory
+ was fixed.
+
+* Performance Tweaks
+
+ - Optimized "git-rev-list --bisect" (hence "git-bisect").
+
+ - Optimized "git-add $path" in a large directory, most of
+ whose contents are ignored.
+
+ - Optimized "git-diff-tree" for reduced memory footprint.
+
+ - The recursive merge strategy updated a worktree file that
+ was changed identically in two branches, when one of them
+ renamed it. We do not do that when there is no rename, so
+ match that behaviour. This avoids excessive rebuilds.
+
+ - The default pack depth has been increased to 50, as the
+ recent addition of delta_base_cache makes deeper delta chains
+ much less expensive to access. Depending on the project, it was
+ reported that this reduces the resulting pack file by 10%
+ or so.
+
+
+Fixes since v1.5.1
+------------------
+
+All of the fixes in v1.5.1 maintenance series are included in
+this release, unless otherwise noted.
+
+* Bugfixes
+
+ - Switching branches with "git checkout" refused to work when
+ a path changes from a file to a directory between the
+ current branch and the new branch, in order not to lose
+ possible local changes in the directory that is being turned
+ into a file with the switch. We now allow such a branch
+ switch after making sure that there is no locally modified
+ file nor un-ignored file in the directory. This has not
+ been backported to 1.5.1.x series, as it is rather an
+ intrusive change.
+
+ - Merging branches that have a file in one and a directory in
+ another at the same path used to get quite confused. We
+ handle such a case a bit more carefully, even though that is
+ still left as a conflict for the user to sort out. This
+ will not be backported to 1.5.1.x series, as it is rather an
+ intrusive change.
+
+ - git-fetch had trouble with a remote with insanely large number
+ of refs.
+
+ - "git clean -d -X" now does not remove non-excluded directories.
+
+ - rebasing (without -m) a series that changes a symlink to a directory
+ in the middle of a path confused git-apply greatly and refused to
+ operate.
diff --git a/RelNotes/1.5.3.1.adoc b/RelNotes/1.5.3.1.adoc
new file mode 100644
index 0000000..7ff546c
--- /dev/null
+++ b/RelNotes/1.5.3.1.adoc
@@ -0,0 +1,10 @@
+GIT v1.5.3.1 Release Notes
+==========================
+
+Fixes since v1.5.3
+------------------
+
+This is solely to fix the generated RPM's dependencies. We used
+to have git-p4 package but we do not anymore. As suggested on
+the mailing list, this release makes git-core "Obsolete" git-p4,
+so that yum update would not complain.
diff --git a/RelNotes/1.5.3.2.adoc b/RelNotes/1.5.3.2.adoc
new file mode 100644
index 0000000..4bbde3c
--- /dev/null
+++ b/RelNotes/1.5.3.2.adoc
@@ -0,0 +1,58 @@
+GIT v1.5.3.2 Release Notes
+==========================
+
+Fixes since v1.5.3.1
+--------------------
+
+ * git-push sent thin packs by default, which was not good for
+ the public distribution server (no point in saving transfer
+ while pushing; no point in making the resulting pack less
+ optimum).
+
+ * git-svn sometimes terminated with "Malformed network data" when
+ talking over svn:// protocol.
+
+ * git-send-email re-issued the same message-id about 10% of the
+ time if you fired off 30 messages within a single second.
+
+ * git-stash was not terminating the log message of commits it
+ internally creates with LF.
+
+ * git-apply failed to check the size of the patch hunk when its
+ beginning part matched the remainder of the preimage exactly,
+ even though the preimage recorded in the hunk was much larger
+ (therefore the patch should not have applied), leading to a
+ segfault.
+
+ * "git rm foo && git commit foo" complained that 'foo' needs to
+ be added first, instead of committing the removal, which was a
+ nonsense.
+
+ * git grep -c said "/dev/null: 0".
+
+ * git-add -u failed to recognize a blob whose type changed
+ between the index and the work tree.
+
+ * The limit to rename detection has been tightened a lot to
+ reduce performance problems with a huge change.
+
+ * cvsimport and svnimport barfed when the input tried to move
+ a tag.
+
+ * "git apply -pN" did not chop the right number of directories.
+
+ * "git svnimport" did not like SVN tags with funny characters in them.
+
+ * git-gui 0.8.3, with assorted fixes, including:
+
+ - font-chooser on X11 was unusable with large number of fonts;
+ - a diff that contained a deleted symlink made it barf;
+ - an untracked symbolic link to a directory made it fart;
+ - a file with % in its name made it vomit;
+
+
+Documentation updates
+---------------------
+
+User manual has been somewhat restructured. I think the new
+organization is much easier to read.
diff --git a/RelNotes/1.5.3.3.adoc b/RelNotes/1.5.3.3.adoc
new file mode 100644
index 0000000..d213846
--- /dev/null
+++ b/RelNotes/1.5.3.3.adoc
@@ -0,0 +1,31 @@
+GIT v1.5.3.3 Release Notes
+==========================
+
+Fixes since v1.5.3.2
+--------------------
+
+ * git-quiltimport did not like it when a patch described in the
+ series file does not exist.
+
+ * p4 importer missed executable bit in some cases.
+
+ * The default shell on some FreeBSD did not execute the
+ argument parsing code correctly and made git unusable.
+
+ * git-svn incorrectly spawned pager even when the user
+ explicitly asked not to.
+
+ * sample post-receive hook overquoted the envelope sender
+ value.
+
+ * git-am got confused when the patch contained a change that is
+ only about type and not contents.
+
+ * git-mergetool did not show our and their version of the
+ conflicted file when started from a subdirectory of the
+ project.
+
+ * git-mergetool did not pass correct options when invoking diff3.
+
+ * git-log sometimes invoked underlying "diff" machinery
+ unnecessarily.
diff --git a/RelNotes/1.5.3.4.adoc b/RelNotes/1.5.3.4.adoc
new file mode 100644
index 0000000..b04b3a4
--- /dev/null
+++ b/RelNotes/1.5.3.4.adoc
@@ -0,0 +1,35 @@
+GIT v1.5.3.4 Release Notes
+==========================
+
+Fixes since v1.5.3.3
+--------------------
+
+ * Change to "git-ls-files" in v1.5.3.3 that was introduced to support
+ partial commit of removal better had a segfaulting bug, which was
+ diagnosed and fixed by Keith and Carl.
+
+ * Performance improvements for rename detection has been backported
+ from the 'master' branch.
+
+ * "git-for-each-ref --format='%(numparent)'" was not working
+ correctly at all, and --format='%(parent)' was not working for
+ merge commits.
+
+ * Sample "post-receive-hook" incorrectly sent out push
+ notification e-mails marked as "From: " the committer of the
+ commit that happened to be at the tip of the branch that was
+ pushed, not from the person who pushed.
+
+ * "git-remote" did not exit non-zero status upon error.
+
+ * "git-add -i" did not respond very well to EOF from tty nor
+ bogus input.
+
+ * "git-rebase -i" squash subcommand incorrectly made the
+ author of later commit the author of resulting commit,
+ instead of taking from the first one in the squashed series.
+
+ * "git-stash apply --index" was not documented.
+
+ * autoconfiguration learned that "ar" command is found as "gas" on
+ some systems.
diff --git a/RelNotes/1.5.3.5.adoc b/RelNotes/1.5.3.5.adoc
new file mode 100644
index 0000000..7ff1d5d
--- /dev/null
+++ b/RelNotes/1.5.3.5.adoc
@@ -0,0 +1,94 @@
+GIT v1.5.3.5 Release Notes
+==========================
+
+Fixes since v1.5.3.4
+--------------------
+
+ * Comes with git-gui 0.8.4.
+
+ * "git-config" silently ignored options after --list; now it will
+ error out with a usage message.
+
+ * "git-config --file" failed if the argument used a relative path
+ as it changed directories before opening the file.
+
+ * "git-config --file" now displays a proper error message if it
+ cannot read the file specified on the command line.
+
+ * "git-config", "git-diff", "git-apply" failed if run from a
+ subdirectory with relative GIT_DIR and GIT_WORK_TREE set.
+
+ * "git-blame" crashed if run during a merge conflict.
+
+ * "git-add -i" did not handle single line hunks correctly.
+
+ * "git-rebase -i" and "git-stash apply" failed if external diff
+ drivers were used for one or more files in a commit. They now
+ avoid calling the external diff drivers.
+
+ * "git-log --follow" did not work unless diff generation (e.g. -p)
+ was also requested.
+
+ * "git-log --follow -B" did not work at all. Fixed.
+
+ * "git-log -M -B" did not correctly handle cases of very large files
+ being renamed and replaced by very small files in the same commit.
+
+ * "git-log" printed extra newlines between commits when a diff
+ was generated internally (e.g. -S or --follow) but not displayed.
+
+ * "git-push" error message is more helpful when pushing to a
+ repository with no matching refs and none specified.
+
+ * "git-push" now respects + (force push) on wildcard refspecs,
+ matching the behavior of git-fetch.
+
+ * "git-filter-branch" now updates the working directory when it
+ has finished filtering the current branch.
+
+ * "git-instaweb" no longer fails on Mac OS X.
+
+ * "git-cvsexportcommit" didn't always create new parent directories
+ before trying to create new child directories. Fixed.
+
+ * "git-fetch" printed a scary (but bogus) error message while
+ fetching a tag that pointed to a tree or blob. The error did
+ not impact correctness, only user perception. The bogus error
+ is no longer printed.
+
+ * "git-ls-files --ignored" did not properly descend into non-ignored
+ directories that themselves contained ignored files if d_type
+ was not supported by the filesystem. This bug impacted systems
+ such as AFS. Fixed.
+
+ * Git segfaulted when reading an invalid .gitattributes file. Fixed.
+
+ * post-receive-email example hook was fixed for non-fast-forward
+ updates.
+
+ * Documentation updates for supported (but previously undocumented)
+ options of "git-archive" and "git-reflog".
+
+ * "make clean" no longer deletes the configure script that ships
+ with the git tarball, making multiple architecture builds easier.
+
+ * "git-remote show origin" spewed a warning message from Perl
+ when no remote is defined for the current branch via
+ branch.<name>.remote configuration settings.
+
+ * Building with NO_PERL_MAKEMAKER excessively rebuilt contents
+ of perl/ subdirectory by rewriting perl.mak.
+
+ * http.sslVerify configuration settings were not used in scripted
+ Porcelains.
+
+ * "git-add" leaked a bit of memory while scanning for files to add.
+
+ * A few workarounds to squelch false warnings from recent gcc have
+ been added.
+
+ * "git-send-pack $remote frotz" segfaulted when there is nothing
+ named 'frotz' on the local end.
+
+ * "git-rebase --interactive" did not handle its "--strategy" option
+ properly.
diff --git a/RelNotes/1.5.3.6.adoc b/RelNotes/1.5.3.6.adoc
new file mode 100644
index 0000000..069a2b2
--- /dev/null
+++ b/RelNotes/1.5.3.6.adoc
@@ -0,0 +1,48 @@
+GIT v1.5.3.6 Release Notes
+==========================
+
+Fixes since v1.5.3.5
+--------------------
+
+ * git-cvsexportcommit handles root commits better.
+
+ * git-svn dcommit used to clobber when sending a series of
+ patches.
+
+ * git-svn dcommit failed after attempting to rebase when
+ started with a dirty index; now it stops upfront.
+
+ * git-grep sometimes refused to work when your index was
+ unmerged.
+
+ * "git-grep -A1 -B2" acted as if it was told to run "git -A1 -B21".
+
+ * git-hash-object did not honor configuration variables, such as
+ core.compression.
+
+ * git-index-pack choked on a huge pack on 32-bit machines, even when
+ large file offsets are supported.
+
+ * atom feeds from git-web said "10" for the month of November.
+
+ * a memory leak in commit walker was plugged.
+
+ * When git-send-email inserted the original author's From:
+ address in body, it did not mark the message with
+ Content-type: as needed.
+
+ * git-revert and git-cherry-pick incorrectly refused to start
+ when the work tree was dirty.
+
+ * git-clean did not honor core.excludesfile configuration.
+
+ * git-add mishandled ".gitignore" files when applying them to
+ subdirectories.
+
+ * While importing a too branchy history, git-fastimport did not
+ honor delta depth limit properly.
+
+ * Support for zlib implementations that lack ZLIB_VERNUM and definition
+ of deflateBound() has been added.
+
+ * Quite a lot of documentation clarifications.
diff --git a/RelNotes/1.5.3.7.adoc b/RelNotes/1.5.3.7.adoc
new file mode 100644
index 0000000..2f69061
--- /dev/null
+++ b/RelNotes/1.5.3.7.adoc
@@ -0,0 +1,45 @@
+GIT v1.5.3.7 Release Notes
+==========================
+
+Fixes since v1.5.3.6
+--------------------
+
+ * git-send-email added 8-bit contents to the payload without
+ marking it as 8-bit in a CTE header.
+
+ * "git-bundle create a.bndl HEAD" dereferenced the symref and
+ did not record the ref as 'HEAD'; this prevented a bundle
+ from being used as a normal source of git-clone.
+
+ * The code to reject nonsense command line of the form
+ "git-commit -a paths..." and "git-commit --interactive
+ paths..." were broken.
+
+ * Adding a signature that is not ASCII-only to an original
+ commit that is ASCII-only would make the result non-ASCII.
+ "git-format-patch -s" did not mark such a message correctly
+ with MIME encoding header.
+
+ * git-add sometimes did not mark the resulting index entry
+ stat-clean. This affected only cases when adding the
+ contents with the same length as the previously staged
+ contents, and the previous staging made the index entry
+ "racily clean".
+
+ * git-commit did not honor GIT_INDEX_FILE the user had in the
+ environment.
+
+ * When checking out a revision, git-checkout did not report where the
+ updated HEAD is if you happened to have a file called HEAD in the
+ work tree.
+
+ * "git-rev-list --objects" mishandled a tree that points at a
+ submodule.
+
+ * "git cvsimport" was not ready for packed refs that "git gc" can
+ produce and gave incorrect results.
+
+ * Many scripted Porcelains were confused when you happened to have a
+ file called "HEAD" in your work tree.
+
+Also it contains updates to the user manual and documentation.
diff --git a/RelNotes/1.5.3.8.adoc b/RelNotes/1.5.3.8.adoc
new file mode 100644
index 0000000..0e3ff58
--- /dev/null
+++ b/RelNotes/1.5.3.8.adoc
@@ -0,0 +1,25 @@
+GIT v1.5.3.8 Release Notes
+==========================
+
+Fixes since v1.5.3.7
+--------------------
+
+ * Some documentation used "email.com" as an example domain.
+
+ * git-svn fix to handle funky branch and project names going over
+ http/https correctly.
+
+ * git-svn fix to tone down a needlessly alarming warning message.
+
+ * git-clone did not correctly report errors while fetching over http.
+
+ * git-send-email added redundant Message-Id: header to the outgoing
+ e-mail when the patch text already had one.
+
+ * a read-beyond-end-of-buffer bug in configuration file updater was fixed.
+
+ * git-grep used to show the same hit repeatedly for unmerged paths.
+
+ * After amending the patch title in "git-am -i", the command did not
+ report the patch it applied with the updated title.
+
diff --git a/RelNotes/1.5.3.adoc b/RelNotes/1.5.3.adoc
new file mode 100644
index 0000000..0668d3c
--- /dev/null
+++ b/RelNotes/1.5.3.adoc
@@ -0,0 +1,366 @@
+GIT v1.5.3 Release Notes
+========================
+
+Updates since v1.5.2
+--------------------
+
+* The commit walkers other than http are officially deprecated,
+ but still supported for now.
+
+* The submodule support has Porcelain layer.
+
+ Note that the current submodule support is minimal and this is
+ deliberately so. A design decision we made is that operations
+ at the supermodule level do not recurse into submodules by
+ default. The expectation is that later we would add a
+ mechanism to tell git which submodules the user is interested
+ in, and this information might be used to determine the
+ recursive behaviour of certain commands (e.g. "git checkout"
+ and "git diff"), but currently we haven't agreed on what that
+ mechanism should look like. Therefore, if you use submodules,
+ you would probably need "git submodule update" on the
+ submodules you care about after running a "git checkout" at
+ the supermodule level.
+
+* There are a handful pack-objects changes to help you cope better
+ with repositories with pathologically large blobs in them.
+
+* For people who need to import from Perforce, a front-end for
+ fast-import is in contrib/fast-import/.
+
+* Comes with git-gui 0.8.2.
+
+* Comes with updated gitk.
+
+* New commands and options.
+
+ - "git log --date=<format>" can use more formats: iso8601, rfc2822.
+
+ - The hunk header output from "git diff" family can be customized
+ with the attributes mechanism. See gitattributes(5) for details.
+
+ - "git stash" allows you to quickly save away your work in
+ progress and replay it later on an updated state.
+
+ - "git rebase" learned an "interactive" mode that let you
+ pick and reorder which commits to rebuild.
+
+ - "git fsck" can save its findings in $GIT_DIR/lost-found, without a
+ separate invocation of "git lost-found" command. The blobs stored by
+ lost-found are stored in plain format to allow you to grep in them.
+
+ - $GIT_WORK_TREE environment variable can be used together with
+ $GIT_DIR to work in a subdirectory of a working tree that is
+ not located at "$GIT_DIR/..".
+
+ - Giving "--file=<file>" option to "git config" is the same as
+ running the command with GIT_CONFIG=<file> environment.
+
+ - "git log" learned a new option "--follow", to follow
+ renaming history of a single file.
+
+ - "git filter-branch" lets you rewrite the revision history of
+ specified branches. You can specify a number of filters to
+ modify the commits, files and trees.
+
+ - "git cvsserver" learned new options (--base-path, --export-all,
+ --strict-paths) inspired by "git daemon".
+
+ - "git daemon --base-path-relaxed" can help migrating a repository URL
+ that did not use to use --base-path to use --base-path.
+
+ - "git commit" can use "-t templatefile" option and commit.template
+ configuration variable to prime the commit message given to you in the
+ editor.
+
+ - "git submodule" command helps you manage the projects from
+ the superproject that contain them.
+
+ - In addition to core.compression configuration option,
+ core.loosecompression and pack.compression options can
+ independently tweak zlib compression levels used for loose
+ and packed objects.
+
+ - "git ls-tree -l" shows size of blobs pointed at by the
+ tree entries, similar to "/bin/ls -l".
+
+ - "git rev-list" learned --regexp-ignore-case and
+ --extended-regexp options to tweak its matching logic used
+ for --grep filtering.
+
+ - "git describe --contains" is a handier way to call more
+ obscure command "git name-rev --tags".
+
+ - "git gc --aggressive" tells the command to spend more cycles
+ to optimize the repository harder.
+
+ - "git repack" learned a "window-memory" limit which
+ dynamically reduces the window size to stay within the
+ specified memory usage.
+
+ - "git repack" can be told to split resulting packs to avoid
+ exceeding limit specified with "--max-pack-size".
+
+ - "git fsck" gained --verbose option. This is really really
+ verbose but it might help you identify exact commit that is
+ corrupt in your repository.
+
+ - "git format-patch" learned --numbered-files option. This
+ may be useful for MH users.
+
+ - "git format-patch" learned format.subjectprefix configuration
+ variable, which serves the same purpose as "--subject-prefix"
+ option.
+
+ - "git tag -n -l" shows tag annotations while listing tags.
+
+ - "git cvsimport" can optionally use the separate-remote layout.
+
+ - "git blame" can be told to see through commits that change
+ whitespaces and indentation levels with "-w" option.
+
+ - "git send-email" can be told not to thread the messages when
+ sending out more than one patches.
+
+ - "git send-email" can also be told how to find whom to cc the
+ message to for each message via --cc-cmd.
+
+ - "git config" learned NUL terminated output format via -z to
+ help scripts.
+
+ - "git add" learned "--refresh <paths>..." option to selectively refresh
+ the cached stat information.
+
+ - "git init -q" makes the command quieter.
+
+ - "git -p command" now has a cousin of opposite sex, "git --no-pager
+ command".
+
+* Updated behavior of existing commands.
+
+ - "gitweb" can offer multiple snapshot formats.
+
+ ***NOTE*** Unfortunately, this changes the format of the
+ $feature{snapshot}{default} entry in the per-site
+ configuration file 'gitweb_config.perl'. It used to be a
+ three-element tuple that describe a single format; with the
+ new configuration item format, you only have to say the name
+ of the format ('tgz', 'tbz2' or 'zip'). Please update the
+ your configuration file accordingly.
+
+ - "git clone" uses -l (hardlink files under .git) by default when
+ cloning locally.
+
+ - URL used for "git clone" and friends can specify nonstandard SSH port
+ by using ssh://host:port/path/to/repo syntax.
+
+ - "git bundle create" can now create a bundle without negative refs,
+ i.e. "everything since the beginning up to certain points".
+
+ - "git diff" (but not the plumbing level "git diff-tree") now
+ recursively descends into trees by default.
+
+ - "git diff" does not show differences that come only from
+ stat-dirtiness in the form of "diff --git" header anymore.
+ It runs "update-index --refresh" silently as needed.
+
+ - "git tag -l" used to match tags by globbing its parameter as if it
+ has wildcard '*' on both ends, which made "git tag -l gui" to match
+ tag 'gitgui-0.7.0'; this was very annoying. You now have to add
+ asterisk on the sides you want to wildcard yourself.
+
+ - The editor to use with many interactive commands can be
+ overridden with GIT_EDITOR environment variable, or if it
+ does not exist, with core.editor configuration variable. As
+ before, if you have neither, environment variables VISUAL
+ and EDITOR are consulted in this order, and then finally we
+ fall back on "vi".
+
+ - "git rm --cached" does not complain when removing a newly
+ added file from the index anymore.
+
+ - Options to "git log" to affect how --grep/--author options look for
+ given strings now have shorter abbreviations. -i is for ignore case,
+ and -E is for extended regexp.
+
+ - "git log" learned --log-size to show the number of bytes in
+ the log message part of the output to help qgit.
+
+ - "git log --name-status" does not require you to give "-r" anymore.
+ As a general rule, Porcelain commands should recurse when showing
+ diff.
+
+ - "git format-patch --root A" can be used to format everything
+ since the beginning up to A. This was supported with
+ "git format-patch --root A A" for a long time, but was not
+ properly documented.
+
+ - "git svn dcommit" retains local merge information.
+
+ - "git svnimport" allows an empty string to be specified as the
+ trunk/ directory. This is necessary to suck data from a SVN
+ repository that doe not have trunk/ branches/ and tags/ organization
+ at all.
+
+ - "git config" to set values also honors type flags like --bool
+ and --int.
+
+ - core.quotepath configuration can be used to make textual git
+ output to emit most of the characters in the path literally.
+
+ - "git mergetool" chooses its backend more wisely, taking
+ notice of its environment such as use of X, Gnome/KDE, etc.
+
+ - "gitweb" shows merge commits a lot nicer than before. The
+ default view uses more compact --cc format, while the UI
+ allows to choose normal diff with any parent.
+
+ - snapshot files "gitweb" creates from a repository at
+ $path/$project/.git are more useful. We use $project part
+ in the filename, which we used to discard.
+
+ - "git cvsimport" creates lightweight tags; there is no
+ interesting information we can record in an annotated tag,
+ and the handcrafted ones the old code created was not
+ properly formed anyway.
+
+ - "git push" pretends that you immediately fetched back from
+ the remote by updating corresponding remote tracking
+ branches if you have any.
+
+ - The diffstat given after a merge (or a pull) honors the
+ color.diff configuration.
+
+ - "git commit --amend" is now compatible with various message source
+ options such as -m/-C/-c/-F.
+
+ - "git apply --whitespace=strip" removes blank lines added at
+ the end of the file.
+
+ - "git fetch" over git native protocols with "-v" option shows
+ connection status, and the IP address of the other end, to
+ help diagnosing problems.
+
+ - We used to have core.legacyheaders configuration, when
+ set to false, allowed git to write loose objects in a format
+ that mimics the format used by objects stored in packs. It
+ turns out that this was not so useful. Although we will
+ continue to read objects written in that format, we do not
+ honor that configuration anymore and create loose objects in
+ the legacy/traditional format.
+
+ - "--find-copies-harder" option to diff family can now be
+ spelled as "-C -C" for brevity.
+
+ - "git mailsplit" (hence "git am") can read from Maildir
+ formatted mailboxes.
+
+ - "git cvsserver" does not barf upon seeing "cvs login"
+ request.
+
+ - "pack-objects" honors "delta" attribute set in
+ .gitattributes. It does not attempt to deltify blobs that
+ come from paths with delta attribute set to false.
+
+ - "new-workdir" script (in contrib) can now be used with a
+ bare repository.
+
+ - "git mergetool" learned to use gvimdiff.
+
+ - "gitview" (in contrib) has a better blame interface.
+
+ - "git log" and friends did not handle a commit log message
+ that is larger than 16kB; they do now.
+
+ - "--pretty=oneline" output format for "git log" and friends
+ deals with "malformed" commit log messages that have more
+ than one lines in the first paragraph better. We used to
+ show the first line, cutting the title at mid-sentence; we
+ concatenate them into a single line and treat the result as
+ "oneline".
+
+ - "git p4import" has been demoted to contrib status. For
+ a superior option, checkout the "git p4" front end to
+ "git fast-import" (also in contrib). The man page and p4
+ rpm have been removed as well.
+
+ - "git mailinfo" (hence "am") now tries to see if the message
+ is in utf-8 first, instead of assuming iso-8859-1, if
+ incoming e-mail does not say what encoding it is in.
+
+* Builds
+
+ - old-style function definitions (most notably, a function
+ without parameter defined with "func()", not "func(void)")
+ have been eradicated.
+
+ - "git tag" and "git verify-tag" have been rewritten in C.
+
+* Performance Tweaks
+
+ - "git pack-objects" avoids re-deltification cost by caching
+ small enough delta results it creates while looking for the
+ best delta candidates.
+
+ - "git pack-objects" learned a new heuristic to prefer delta
+ that is shallower in depth over the smallest delta
+ possible. This improves both overall packfile access
+ performance and packfile density.
+
+ - diff-delta code that is used for packing has been improved
+ to work better on big files.
+
+ - when there are more than one pack files in the repository,
+ the runtime used to try finding an object always from the
+ newest packfile; it now tries the same packfile as we found
+ the object requested the last time, which exploits the
+ locality of references.
+
+ - verifying pack contents done by "git fsck --full" got boost
+ by carefully choosing the order to verify objects in them.
+
+ - "git read-tree -m" to read into an already populated index
+ has been optimized vastly. The effect of this can be seen
+ when switching branches that have differences in only a
+ handful paths.
+
+ - "git add paths..." and "git commit paths..." has also been
+ heavily optimized.
+
+Fixes since v1.5.2
+------------------
+
+All of the fixes in v1.5.2 maintenance series are included in
+this release, unless otherwise noted.
+
+* Bugfixes
+
+ - "gitweb" had trouble handling non UTF-8 text with older
+ Encode.pm Perl module.
+
+ - "git svn" misparsed the data from the commits in the repository when
+ the user had "color.diff = true" in the configuration. This has been
+ fixed.
+
+ - There was a case where "git svn dcommit" clobbered changes made on the
+ SVN side while committing multiple changes.
+
+ - "git-write-tree" had a bad interaction with racy-git avoidance and
+ gitattributes mechanisms.
+
+ - "git --bare command" overrode existing GIT_DIR setting and always
+ made it treat the current working directory as GIT_DIR.
+
+ - "git ls-files --error-unmatch" does not complain if you give the
+ same path pattern twice by mistake.
+
+ - "git init" autodetected core.filemode but not core.symlinks, which
+ made a new directory created automatically by "git clone" cumbersome
+ to use on filesystems that require these configurations to be set.
+
+ - "git log" family of commands behaved differently when run as "git
+ log" (no pathspec) and as "git log --" (again, no pathspec). This
+ inconsistency was introduced somewhere in v1.3.0 series but now has
+ been corrected.
+
+ - "git rebase -m" incorrectly displayed commits that were skipped.
diff --git a/RelNotes/1.5.4.1.adoc b/RelNotes/1.5.4.1.adoc
new file mode 100644
index 0000000..d4e44b8
--- /dev/null
+++ b/RelNotes/1.5.4.1.adoc
@@ -0,0 +1,17 @@
+GIT v1.5.4.1 Release Notes
+==========================
+
+Fixes since v1.5.4
+------------------
+
+ * "git-commit -C $tag" used to work but rewrite in C done in
+ 1.5.4 broke it.
+
+ * An entry in the .gitattributes file that names a pattern in a
+ subdirectory of the directory it is in did not match
+ correctly (e.g. pattern "b/*.c" in "a/.gitattributes" should
+ match "a/b/foo.c" but it didn't).
+
+ * Customized color specification was parsed incorrectly when
+ numeric color values are used. This was fixed in 1.5.4.1.
+
diff --git a/RelNotes/1.5.4.2.adoc b/RelNotes/1.5.4.2.adoc
new file mode 100644
index 0000000..21d0df5
--- /dev/null
+++ b/RelNotes/1.5.4.2.adoc
@@ -0,0 +1,43 @@
+GIT v1.5.4.2 Release Notes
+==========================
+
+Fixes since v1.5.4
+------------------
+
+ * The configuration parser was not prepared to see string
+ valued variables misspelled as boolean and segfaulted.
+
+ * Temporary files left behind due to interrupted object
+ transfers were not cleaned up with "git prune".
+
+ * "git config --unset" was confused when the unset variables
+ were spelled with continuation lines in the config file.
+
+ * The merge message detection in "git cvsimport" did not catch
+ a message that began with "Merge...".
+
+ * "git status" suggests "git rm --cached" for unstaging the
+ earlier "git add" before the initial commit.
+
+ * "git status" output was incorrect during a partial commit.
+
+ * "git bisect" refused to start when the HEAD was detached.
+
+ * "git bisect" allowed a wildcard character in the commit
+ message expanded while writing its log file.
+
+ * Manual pages were not formatted correctly with docbook xsl
+ 1.72; added a workaround.
+
+ * "git-commit -C $tag" used to work but rewrite in C done in
+ 1.5.4 broke it. This was fixed in 1.5.4.1.
+
+ * An entry in the .gitattributes file that names a pattern in a
+ subdirectory of the directory it is in did not match
+ correctly (e.g. pattern "b/*.c" in "a/.gitattributes" should
+ match "a/b/foo.c" but it didn't). This was fixed in 1.5.4.1.
+
+ * Customized color specification was parsed incorrectly when
+ numeric color values are used. This was fixed in 1.5.4.1.
+
+ * http transport misbehaved when linked with curl-gnutls.
diff --git a/RelNotes/1.5.4.3.adoc b/RelNotes/1.5.4.3.adoc
new file mode 100644
index 0000000..b0fc67f
--- /dev/null
+++ b/RelNotes/1.5.4.3.adoc
@@ -0,0 +1,27 @@
+GIT v1.5.4.3 Release Notes
+==========================
+
+Fixes since v1.5.4.2
+--------------------
+
+ * RPM spec used to pull in everything with 'git'. This has been
+ changed so that 'git' package contains just the core parts,
+ and we now supply 'git-all' metapackage to slurp in everything.
+ This should match end user's expectation better.
+
+ * When some refs failed to update, git-push reported "failure"
+ which was unclear if some other refs were updated or all of
+ them failed atomically (the answer is the former). Reworded
+ the message to clarify this.
+
+ * "git clone" from a repository whose HEAD was misconfigured
+ did not set up the remote properly. Now it tries to do
+ better.
+
+ * Updated git-push documentation to clarify what "matching"
+ means, in order to reduce user confusion.
+
+ * Updated git-add documentation to clarify "add -u" operates in
+ the current subdirectory you are in, just like other commands.
+
+ * git-gui updates to work on OSX and Windows better.
diff --git a/RelNotes/1.5.4.4.adoc b/RelNotes/1.5.4.4.adoc
new file mode 100644
index 0000000..323c1a8
--- /dev/null
+++ b/RelNotes/1.5.4.4.adoc
@@ -0,0 +1,66 @@
+GIT v1.5.4.4 Release Notes
+==========================
+
+Fixes since v1.5.4.3
+--------------------
+
+ * Building and installing with an overtight umask such as 077 made
+ installed templates unreadable by others, while the rest of the install
+ are done in a way that is friendly to umask 022.
+
+ * "git cvsexportcommit -w $cvsdir" misbehaved when GIT_DIR is set to a
+ relative directory.
+
+ * "git http-push" had an invalid memory access that could lead it to
+ segfault.
+
+ * When "git rebase -i" gave control back to the user for a commit that is
+ marked to be edited, it just said "modify it with commit --amend",
+ without saying what to do to continue after modifying it. Give an
+ explicit instruction to run "rebase --continue" to be more helpful.
+
+ * "git send-email" in 1.5.4.3 issued a bogus empty In-Reply-To: header.
+
+ * "git bisect" showed mysterious "won't bisect on seeked tree" error message.
+ This was leftover from Cogito days to prevent "bisect" starting from a
+ cg-seeked state. We still keep the Cogito safety, but running "git bisect
+ start" when another bisect was in effect will clean up and start over.
+
+ * "git push" with an explicit PATH to receive-pack did not quite work if
+ receive-pack was not on usual PATH. We earlier fixed the same issue
+ with "git fetch" and upload-pack, but somehow forgot to do so in the
+ other direction.
+
+ * git-gui's info dialog was not displayed correctly when the user tries
+ to commit nothing (i.e. without staging anything).
+
+ * "git revert" did not properly fail when attempting to run with a
+ dirty index.
+
+ * "git merge --no-commit --no-ff <other>" incorrectly made commits.
+
+ * "git merge --squash --no-ff <other>", which is a nonsense combination
+ of options, was not rejected.
+
+ * "git ls-remote" and "git remote show" against an empty repository
+ failed, instead of just giving an empty result (regression).
+
+ * "git fast-import" did not handle a renamed path whose name needs to be
+ quoted, due to a bug in unquote_c_style() function.
+
+ * "git cvsexportcommit" was confused when multiple files with the same
+ basename needed to be pushed out in the same commit.
+
+ * "git daemon" did not send early errors to syslog.
+
+ * "git log --merge" did not work well with --left-right option.
+
+ * "git svn" prompted for client cert password every time it accessed the
+ server.
+
+ * The reset command in "git fast-import" data stream was documented to
+ end with an optional LF, but it actually required one.
+
+ * "git svn dcommit/rebase" did not honor --rewrite-root option.
+
+Also included are a handful documentation updates.
diff --git a/RelNotes/1.5.4.5.adoc b/RelNotes/1.5.4.5.adoc
new file mode 100644
index 0000000..bbd130e
--- /dev/null
+++ b/RelNotes/1.5.4.5.adoc
@@ -0,0 +1,56 @@
+GIT v1.5.4.5 Release Notes
+==========================
+
+Fixes since v1.5.4.4
+--------------------
+
+ * "git fetch there" when the URL information came from the Cogito style
+ branches/there file did not update refs/heads/there (regression in
+ 1.5.4).
+
+ * Bogus refspec configuration such as "remote.there.fetch = =" were not
+ detected as errors (regression in 1.5.4).
+
+ * You couldn't specify a custom editor whose path contains a whitespace
+ via GIT_EDITOR (and core.editor).
+
+ * The subdirectory filter to "git filter-branch" mishandled a history
+ where the subdirectory becomes empty and then later becomes non-empty.
+
+ * "git shortlog" gave an empty line if the original commit message was
+ malformed (e.g. a botched import from foreign SCM). Now it finds the
+ first non-empty line and uses it for better information.
+
+ * When the user fails to give a revision parameter to "git svn", an error
+ from the Perl interpreter was issued because the script lacked proper
+ error checking.
+
+ * After "git rebase" stopped due to conflicts, if the user played with
+ "git reset" and friends, "git rebase --abort" failed to go back to the
+ correct commit.
+
+ * Additional work trees prepared with git-new-workdir (in contrib/) did
+ not share git-svn metadata directory .git/svn with the original.
+
+ * "git-merge-recursive" did not mark addition of the same path with
+ different filemodes correctly as a conflict.
+
+ * "gitweb" gave malformed URL when pathinfo stype paths are in use.
+
+ * "-n" stands for "--no-tags" again for "git fetch".
+
+ * "git format-patch" did not detect the need to add 8-bit MIME header
+ when the user used format.header configuration.
+
+ * "rev~" revision specifier used to mean "rev", which was inconsistent
+ with how "rev^" worked. Now "rev~" is the same as "rev~1" (hence it
+ also is the same as "rev^1"), and "rev~0" is the same as "rev^0"
+ (i.e. it has to be a commit).
+
+ * "git quiltimport" did not grok empty lines, lines in "file -pNNN"
+ format to specify the prefix levels and lines with trailing comments.
+
+ * "git rebase -m" triggered pre-commit verification, which made
+ "rebase --continue" impossible.
+
+As usual, it also comes with many documentation fixes and clarifications.
diff --git a/RelNotes/1.5.4.6.adoc b/RelNotes/1.5.4.6.adoc
new file mode 100644
index 0000000..3e3c3e5
--- /dev/null
+++ b/RelNotes/1.5.4.6.adoc
@@ -0,0 +1,43 @@
+GIT v1.5.4.6 Release Notes
+==========================
+
+I personally do not think there is any reason anybody should want to
+run v1.5.4.X series these days, because 'master' version is always
+more stable than any tagged released version of git.
+
+This is primarily to futureproof "git-shell" to accept requests
+without a dash between "git" and subcommand name (e.g. "git
+upload-pack") which the newer client will start to make sometime in
+the future.
+
+Fixes since v1.5.4.5
+--------------------
+
+ * Command line option "-n" to "git-repack" was not correctly parsed.
+
+ * Error messages from "git-apply" when the patchfile cannot be opened
+ have been improved.
+
+ * Error messages from "git-bisect" when given nonsense revisions have
+ been improved.
+
+ * reflog syntax that uses time e.g. "HEAD@{10 seconds ago}:path" did not
+ stop parsing at the closing "}".
+
+ * "git rev-parse --symbolic-full-name ^master^2" printed solitary "^",
+ but it should print nothing.
+
+ * "git apply" did not enforce "match at the beginning" correctly.
+
+ * a path specification "a/b" in .gitattributes file should not match
+ "sub/a/b", but it did.
+
+ * "git log --date-order --topo-order" did not override the earlier
+ date-order with topo-order as expected.
+
+ * "git fast-export" did not export octopus merges correctly.
+
+ * "git archive --prefix=$path/" mishandled gitattributes.
+
+As usual, it also comes with many documentation fixes and clarifications.
+
diff --git a/RelNotes/1.5.4.7.adoc b/RelNotes/1.5.4.7.adoc
new file mode 100644
index 0000000..9065a0e
--- /dev/null
+++ b/RelNotes/1.5.4.7.adoc
@@ -0,0 +1,10 @@
+GIT v1.5.4.7 Release Notes
+==========================
+
+Fixes since 1.5.4.7
+-------------------
+
+ * Removed support for an obsolete gitweb request URI, whose
+ implementation ran "git diff" Porcelain, instead of using plumbing,
+ which would have run an external diff command specified in the
+ repository configuration as the gitweb user.
diff --git a/RelNotes/1.5.4.adoc b/RelNotes/1.5.4.adoc
new file mode 100644
index 0000000..f1323b6
--- /dev/null
+++ b/RelNotes/1.5.4.adoc
@@ -0,0 +1,377 @@
+GIT v1.5.4 Release Notes
+========================
+
+Removal
+-------
+
+ * "git svnimport" was removed in favor of "git svn". It is still there
+ in the source tree (contrib/examples) but unsupported.
+
+ * As git-commit and git-status have been rewritten, "git runstatus"
+ helper script lost all its users and has been removed.
+
+
+Temporarily disabled
+--------------------
+
+ * "git http-push" is known not to work well with cURL library older
+ than 7.16, and we had reports of repository corruption. It is
+ disabled on such platforms for now. Unfortunately, 1.5.3.8 shares
+ the same issue. In other words, this does not mean you will be
+ fine if you stick to an older git release. For now, please do not
+ use http-push from older git with cURL older than 7.16 if you
+ value your data. A proper fix will hopefully materialize in
+ later versions.
+
+
+Deprecation notices
+-------------------
+
+ * From v1.6.0, git will by default install dashed form of commands
+ (e.g. "git-commit") outside of users' normal $PATH, and will install
+ only selected commands ("git" itself, and "gitk") in $PATH. This
+ implies:
+
+ - Using dashed forms of git commands (e.g. "git-commit") from the
+ command line has been informally deprecated since early 2006, but
+ now it officially is, and will be removed in the future. Use
+ dash-less forms (e.g. "git commit") instead.
+
+ - Using dashed forms from your scripts, without first prepending the
+ return value from "git --exec-path" to the scripts' PATH, has been
+ informally deprecated since early 2006, but now it officially is.
+
+ - Use of dashed forms with "PATH=$(git --exec-path):$PATH; export
+ PATH" early in your script is not deprecated with this change.
+
+ Users are strongly encouraged to adjust their habits and scripts now
+ to prepare for this change.
+
+ * The post-receive hook was introduced in March 2007 to supersede
+ the post-update hook, primarily to overcome the command line length
+ limitation of the latter. Use of post-update hook will be deprecated
+ in future versions of git, starting from v1.6.0.
+
+ * "git lost-found" was deprecated in favor of "git fsck"'s --lost-found
+ option, and will be removed in the future.
+
+ * "git peek-remote" is deprecated, as "git ls-remote" was written in C
+ and works for all transports; "git peek-remote" will be removed in
+ the future.
+
+ * "git repo-config" which was an old name for "git config" command
+ has been supported without being advertised for a long time. The
+ next feature release will remove it.
+
+ * From v1.6.0, the repack.usedeltabaseoffset config option will default
+ to true, which will give denser packfiles (i.e. more efficient storage).
+ The downside is that git older than version 1.4.4 will not be able
+ to directly use a repository packed using this setting.
+
+ * From v1.6.0, the pack.indexversion config option will default to 2,
+ which is slightly more efficient, and makes repacking more immune to
+ data corruptions. Git older than version 1.5.2 may revert to version 1
+ of the pack index with a manual "git index-pack" to be able to directly
+ access corresponding pack files.
+
+
+Updates since v1.5.3
+--------------------
+
+ * Comes with much improved gitk, with i18n.
+
+ * Comes with git-gui 0.9.2 with i18n.
+
+ * gitk is now merged as a subdirectory of git.git project, in
+ preparation for its i18n.
+
+ * progress displays from many commands are a lot nicer to the eye.
+ Transfer commands show throughput data.
+
+ * many commands that pay attention to per-directory .gitignore now do
+ so lazily, which makes the usual case go much faster.
+
+ * Output processing for '--pretty=format:<user format>' has been
+ optimized.
+
+ * Rename detection of diff family while detecting exact matches has
+ been greatly optimized.
+
+ * Rename detection of diff family tries to make more natural looking
+ pairing. Earlier, if multiple identical rename sources were
+ found in the preimage, the source used was picked pretty much at random.
+
+ * Value "true" for color.diff and color.status configuration used to
+ mean "always" (even when the output is not going to a terminal).
+ This has been corrected to mean the same thing as "auto".
+
+ * "git diff" Porcelain now respects diff.external configuration, which
+ is another way to specify GIT_EXTERNAL_DIFF.
+
+ * "git diff" can be told to use different prefixes other than
+ "a/" and "b/" e.g. "git diff --src-prefix=l/ --dst-prefix=k/".
+
+ * "git diff" sometimes did not quote paths with funny
+ characters properly.
+
+ * "git log" (and any revision traversal commands) misbehaved
+ when --diff-filter is given but was not asked to actually
+ produce diff.
+
+ * HTTP proxy can be specified per remote repository using
+ remote.*.httpproxy configuration, or global http.proxy configuration
+ variable.
+
+ * Various Perforce importer updates.
+
+ * Example update and post-receive hooks have been improved.
+
+ * Any command that wants to take a commit object name can now use
+ ":/string" syntax to name a commit.
+
+ * "git reset" is now built-in and its output can be squelched with -q.
+
+ * "git reset --hard" does not make any sense in a bare
+ repository, but did not error out; fixed.
+
+ * "git send-email" can optionally talk over ssmtp and use SMTP-AUTH.
+
+ * "git rebase" learned --whitespace option.
+
+ * In "git rebase", when you decide not to replay a particular change
+ after the command stopped with a conflict, you can say "git rebase
+ --skip" without first running "git reset --hard", as the command now
+ runs it for you.
+
+ * "git rebase --interactive" mode can now work on detached HEAD.
+
+ * Other minor to serious bugs in "git rebase -i" have been fixed.
+
+ * "git rebase" now detaches head during its operation, so after a
+ successful "git rebase" operation, the reflog entry branch@{1} for
+ the current branch points at the commit before the rebase was
+ started.
+
+ * "git rebase -i" also triggers rerere to help your repeated merges.
+
+ * "git merge" can call the "post-merge" hook.
+
+ * "git pack-objects" can optionally run deltification with multiple
+ threads.
+
+ * "git archive" can optionally substitute keywords in files marked with
+ export-subst attribute.
+
+ * "git cherry-pick" made a misguided attempt to repeat the original
+ command line in the generated log message, when told to cherry-pick a
+ commit by naming a tag that points at it. It does not anymore.
+
+ * "git for-each-ref" learned %(xxxdate:<date-format>) syntax to show the
+ various date fields in different formats.
+
+ * "git gc --auto" is a low-impact way to automatically run a variant of
+ "git repack" that does not lose unreferenced objects (read: safer
+ than the usual one) after the user accumulates too many loose
+ objects.
+
+ * "git clean" has been rewritten in C.
+
+ * You need to explicitly set clean.requireForce to "false" to allow
+ "git clean" without -f to do any damage (lack of the configuration
+ variable used to mean "do not require -f option to lose untracked
+ files", but we now use the safer default).
+
+ * The kinds of whitespace errors "git diff" and "git apply" notice (and
+ fix) can be controlled via 'core.whitespace' configuration variable
+ and 'whitespace' attribute in .gitattributes file.
+
+ * "git push" learned --dry-run option to show what would happen if a
+ push is run.
+
+ * "git push" does not update a tracking ref on the local side when the
+ remote refused to update the corresponding ref.
+
+ * "git push" learned --mirror option. This is to push the local refs
+ one-to-one to the remote, and deletes refs from the remote that do
+ not exist anymore in the repository on the pushing side.
+
+ * "git push" can remove a corrupt ref at the remote site with the usual
+ ":ref" refspec.
+
+ * "git remote" knows --mirror mode. This is to set up configuration to
+ push into a remote repository to store local branch heads to the same
+ branch on the remote side, and remove branch heads locally removed
+ from local repository at the same time. Suitable for pushing into a
+ back-up repository.
+
+ * "git remote" learned "rm" subcommand.
+
+ * "git cvsserver" can be run via "git shell". Also, "cvs" is
+ recognized as a synonym for "git cvsserver", so that CVS users
+ can be switched to git just by changing their login shell.
+
+ * "git cvsserver" acts more like receive-pack by running post-receive
+ and post-update hooks.
+
+ * "git am" and "git rebase" are far less verbose.
+
+ * "git pull" learned to pass --[no-]ff option to underlying "git
+ merge".
+
+ * "git pull --rebase" is a different way to integrate what you fetched
+ into your current branch.
+
+ * "git fast-export" produces data-stream that can be fed to fast-import
+ to reproduce the history recorded in a git repository.
+
+ * "git add -i" takes pathspecs to limit the set of files to work on.
+
+ * "git add -p" is a short-hand to go directly to the selective patch
+ subcommand in the interactive command loop and to exit when done.
+
+ * "git add -i" UI has been colorized. The interactive prompt
+ and menu can be colored by setting color.interactive
+ configuration. The diff output (including the hunk picker)
+ are colored with color.diff configuration.
+
+ * "git commit --allow-empty" allows you to create a single-parent
+ commit that records the same tree as its parent, overriding the usual
+ safety valve.
+
+ * "git commit --amend" can amend a merge that does not change the tree
+ from its first parent.
+
+ * "git commit" used to unconditionally strip comment lines that
+ began with '#' and removed excess blank lines. This behavior has
+ been made configurable.
+
+ * "git commit" has been rewritten in C.
+
+ * "git stash random-text" does not create a new stash anymore. It was
+ a UI mistake. Use "git stash save random-text", or "git stash"
+ (without extra args) for that.
+
+ * "git stash clear extra-text" does not clear the whole stash
+ anymore. It is tempting to expect "git stash clear stash@{2}"
+ to drop only a single named stash entry, and it is rude to
+ discard everything when that is asked (but not provided).
+
+ * "git prune --expire <time>" can exempt young loose objects from
+ getting pruned.
+
+ * "git branch --contains <commit>" can list branches that are
+ descendants of a given commit.
+
+ * "git log" learned --early-output option to help interactive GUI
+ implementations.
+
+ * "git bisect" learned "skip" action to mark untestable commits.
+
+ * "git bisect visualize" learned a shorter synonym "git bisect view".
+
+ * "git bisect visualize" runs "git log" in a non-windowed
+ environments. It also can be told what command to run (e.g. "git
+ bisect visualize tig").
+
+ * "git format-patch" learned "format.numbered" configuration variable
+ to automatically turn --numbered option on when more than one commits
+ are formatted.
+
+ * "git ls-files" learned "--exclude-standard" to use the canned set of
+ exclude files.
+
+ * "git tag -a -f existing" begins the editor session using the existing
+ annotation message.
+
+ * "git tag -m one -m bar" (multiple -m options) behaves similarly to
+ "git commit"; the parameters to -m options are formatted as separate
+ paragraphs.
+
+ * The format "git show" outputs an annotated tag has been updated to
+ include "Tagger: " and "Date: " lines from the tag itself. Strictly
+ speaking this is a backward incompatible change, but this is a
+ reasonable usability fix and people's scripts shouldn't have been
+ relying on the exact output from "git show" Porcelain anyway.
+
+ * "git cvsimport" did not notice errors from underlying "cvsps"
+ and produced a corrupt import silently.
+
+ * "git cvsexportcommit" learned -w option to specify and switch to the
+ CVS working directory.
+
+ * "git checkout" from a subdirectory learned to use "../path" to allow
+ checking out a path outside the current directory without cd'ing up.
+
+ * "git checkout" from and to detached HEAD leaves a bit more
+ information in the reflog.
+
+ * "git send-email --dry-run" shows full headers for easier diagnosis.
+
+ * "git merge-ours" is now built-in.
+
+ * "git svn" learned "info" and "show-externals" subcommands.
+
+ * "git svn" run from a subdirectory failed to read settings from the
+ .git/config.
+
+ * "git svn" learned --use-log-author option, which picks up more
+ descriptive name from From: and Signed-off-by: lines in the commit
+ message.
+
+ * "git svn" wasted way too much disk to record revision mappings
+ between svn and git; a new representation that is much more compact
+ for this information has been introduced to correct this.
+
+ * "git svn" left temporary index files it used without cleaning them
+ up; this was corrected.
+
+ * "git status" from a subdirectory now shows relative paths, which
+ makes copy-and-pasting for git-checkout/git-add/git-rm easier. The
+ traditional behavior to show the full path relative to the top of
+ the work tree can be had by setting status.relativepaths
+ configuration variable to false.
+
+ * "git blame" kept text for each annotated revision in core needlessly;
+ this has been corrected.
+
+ * "git shortlog" learned to default to HEAD when the standard input is
+ a terminal and the user did not give any revision parameter.
+
+ * "git shortlog" learned "-e" option to show e-mail addresses as well as
+ authors' names.
+
+ * "git help" learned "-w" option to show documentation in browsers.
+
+ * In addition there are quite a few internal clean-ups. Notably:
+
+ - many fork/exec have been replaced with run-command API,
+ brought from the msysgit effort.
+
+ - introduction and more use of the option parser API.
+
+ - enhancement and more use of the strbuf API.
+
+ * Makefile tweaks to support HP-UX is in.
+
+Fixes since v1.5.3
+------------------
+
+All of the fixes in v1.5.3 maintenance series are included in
+this release, unless otherwise noted.
+
+These fixes are only in v1.5.4 and not backported to v1.5.3 maintenance
+series.
+
+ * The way "git diff --check" behaves is much more consistent with the way
+ "git apply --whitespace=warn" works.
+
+ * "git svn" talking with the SVN over HTTP will correctly quote branch
+ and project names.
+
+ * "git config" did not work correctly on platforms that define
+ REG_NOMATCH to an even number.
+
+ * Recent versions of AsciiDoc 8 has a change to break our
+ documentation; a workaround has been implemented.
+
+ * "git diff --color-words" colored context lines in a wrong color.
diff --git a/RelNotes/1.5.5.1.adoc b/RelNotes/1.5.5.1.adoc
new file mode 100644
index 0000000..7de4197
--- /dev/null
+++ b/RelNotes/1.5.5.1.adoc
@@ -0,0 +1,44 @@
+GIT v1.5.5.1 Release Notes
+==========================
+
+Fixes since v1.5.5
+------------------
+
+ * "git archive --prefix=$path/" mishandled gitattributes.
+
+ * "git fetch -v" that fetches into FETCH_HEAD did not report the summary
+ the same way as done for updating the tracking refs.
+
+ * "git svn" misbehaved when the configuration file customized the "git
+ log" output format using format.pretty.
+
+ * "git submodule status" leaked an unnecessary error message.
+
+ * "git log --date-order --topo-order" did not override the earlier
+ date-order with topo-order as expected.
+
+ * "git bisect good $this" did not check the validity of the revision
+ given properly.
+
+ * "url.<there>.insteadOf" did not work correctly.
+
+ * "git clean" ran inside subdirectory behaved as if the directory was
+ explicitly specified for removal by the end user from the top level.
+
+ * "git bisect" from a detached head leaked an unnecessary error message.
+
+ * "git bisect good $a $b" when $a is Ok but $b is bogus should have
+ atomically failed before marking $a as good.
+
+ * "git fmt-merge-msg" did not clean up leading empty lines from commit
+ log messages like "git log" family does.
+
+ * "git am" recorded a commit with empty Subject: line without
+ complaining.
+
+ * when given a commit log message whose first paragraph consists of
+ multiple lines, "git rebase" squashed it into a single line.
+
+ * "git remote add $bogus_name $url" did not complain properly.
+
+Also comes with various documentation updates.
diff --git a/RelNotes/1.5.5.2.adoc b/RelNotes/1.5.5.2.adoc
new file mode 100644
index 0000000..391a7b0
--- /dev/null
+++ b/RelNotes/1.5.5.2.adoc
@@ -0,0 +1,27 @@
+GIT v1.5.5.2 Release Notes
+==========================
+
+Fixes since v1.5.5.1
+--------------------
+
+ * "git repack -n" was mistakenly made no-op earlier.
+
+ * "git imap-send" wanted to always have imap.host even when use of
+ imap.tunnel made it unnecessary.
+
+ * reflog syntax that uses time e.g. "HEAD@{10 seconds ago}:path" did not
+ stop parsing at the closing "}".
+
+ * "git rev-parse --symbolic-full-name ^master^2" printed solitary "^",
+ but it should print nothing.
+
+ * "git commit" did not detect when it failed to write tree objects.
+
+ * "git fetch" sometimes transferred too many objects unnecessarily.
+
+ * a path specification "a/b" in .gitattributes file should not match
+ "sub/a/b".
+
+ * various gitweb fixes.
+
+Also comes with various documentation updates.
diff --git a/RelNotes/1.5.5.3.adoc b/RelNotes/1.5.5.3.adoc
new file mode 100644
index 0000000..f22f98b
--- /dev/null
+++ b/RelNotes/1.5.5.3.adoc
@@ -0,0 +1,12 @@
+GIT v1.5.5.3 Release Notes
+==========================
+
+Fixes since v1.5.5.2
+--------------------
+
+ * "git send-email --compose" did not notice that non-ascii contents
+ needed some MIME magic.
+
+ * "git fast-export" did not export octopus merges correctly.
+
+Also comes with various documentation updates.
diff --git a/RelNotes/1.5.5.4.adoc b/RelNotes/1.5.5.4.adoc
new file mode 100644
index 0000000..2d0279e
--- /dev/null
+++ b/RelNotes/1.5.5.4.adoc
@@ -0,0 +1,7 @@
+GIT v1.5.5.4 Release Notes
+==========================
+
+Fixes since v1.5.5.4
+--------------------
+
+ * "git name-rev --all" used to segfault.
diff --git a/RelNotes/1.5.5.5.adoc b/RelNotes/1.5.5.5.adoc
new file mode 100644
index 0000000..30fa361
--- /dev/null
+++ b/RelNotes/1.5.5.5.adoc
@@ -0,0 +1,11 @@
+GIT v1.5.5.5 Release Notes
+==========================
+
+I personally do not think there is any reason anybody should want to
+run v1.5.5.X series these days, because 'master' version is always
+more stable than any tagged released version of git.
+
+This is primarily to futureproof "git-shell" to accept requests
+without a dash between "git" and subcommand name (e.g. "git
+upload-pack") which the newer client will start to make sometime in
+the future.
diff --git a/RelNotes/1.5.5.6.adoc b/RelNotes/1.5.5.6.adoc
new file mode 100644
index 0000000..d5e85cb
--- /dev/null
+++ b/RelNotes/1.5.5.6.adoc
@@ -0,0 +1,10 @@
+GIT v1.5.5.6 Release Notes
+==========================
+
+Fixes since 1.5.5.5
+-------------------
+
+ * Removed support for an obsolete gitweb request URI, whose
+ implementation ran "git diff" Porcelain, instead of using plumbing,
+ which would have run an external diff command specified in the
+ repository configuration as the gitweb user.
diff --git a/RelNotes/1.5.5.adoc b/RelNotes/1.5.5.adoc
new file mode 100644
index 0000000..2932212
--- /dev/null
+++ b/RelNotes/1.5.5.adoc
@@ -0,0 +1,207 @@
+GIT v1.5.5 Release Notes
+========================
+
+Updates since v1.5.4
+--------------------
+
+(subsystems)
+
+ * Comes with git-gui 0.10.1
+
+(portability)
+
+ * We shouldn't ask for BSD group ownership semantics by setting g+s bit
+ on directories on older BSD systems that refuses chmod() by non root
+ users. BSD semantics is the default there anyway.
+
+ * Bunch of portability improvement patches coming from an effort to port
+ to Solaris has been applied.
+
+(performance)
+
+ * On platforms with suboptimal qsort(3) implementation, there
+ is an option to use more reasonable substitute we ship with
+ our software.
+
+ * New configuration variable "pack.packsizelimit" can be used
+ in place of command line option --max-pack-size.
+
+ * "git fetch" over the native git protocol used to make a
+ connection to find out the set of current remote refs and
+ another to actually download the pack data. We now use only
+ one connection for these tasks.
+
+ * "git commit" does not run lstat(2) more than necessary
+ anymore.
+
+(usability, bells and whistles)
+
+ * Bash completion script (in contrib) are aware of more commands and
+ options.
+
+ * You can be warned when core.autocrlf conversion is applied in
+ such a way that results in an irreversible conversion.
+
+ * A catch-all "color.ui" configuration variable can be used to
+ enable coloring of all color-capable commands, instead of
+ individual ones such as "color.status" and "color.branch".
+
+ * The commands refused to take absolute pathnames where they
+ require pathnames relative to the work tree or the current
+ subdirectory. They now can take absolute pathnames in such a
+ case as long as the pathnames do not refer outside of the
+ work tree. E.g. "git add $(pwd)/foo" now works.
+
+ * Error messages used to be sent to stderr, only to get hidden,
+ when $PAGER was in use. They now are sent to stdout along
+ with the command output to be shown in the $PAGER.
+
+ * A pattern "foo/" in .gitignore file now matches a directory
+ "foo". Pattern "foo" also matches as before.
+
+ * bash completion's prompt helper function can talk about
+ operation in-progress (e.g. merge, rebase, etc.).
+
+ * Configuration variables "url.<usethis>.insteadof = <otherurl>" can be
+ used to tell "git-fetch" and "git-push" to use different URL than what
+ is given from the command line.
+
+ * "git add -i" behaves better even before you make an initial commit.
+
+ * "git am" refused to run from a subdirectory without a good reason.
+
+ * After "git apply --whitespace=fix" fixes whitespace errors in a patch,
+ a line before the fix can appear as a context or preimage line in a
+ later patch, causing the patch not to apply. The command now knows to
+ see through whitespace fixes done to context lines to successfully
+ apply such a patch series.
+
+ * "git branch" (and "git checkout -b") to branch from a local branch can
+ optionally set "branch.<name>.merge" to mark the new branch to build on
+ the other local branch, when "branch.autosetupmerge" is set to
+ "always", or when passing the command line option "--track" (this option
+ was ignored when branching from local branches). By default, this does
+ not happen when branching from a local branch.
+
+ * "git checkout" to switch to a branch that has "branch.<name>.merge" set
+ (i.e. marked to build on another branch) reports how much the branch
+ and the other branch diverged.
+
+ * When "git checkout" has to update a lot of paths, it used to be silent
+ for 4 seconds before it showed any progress report. It is now a bit
+ more impatient and starts showing progress report early.
+
+ * "git commit" learned a new hook "prepare-commit-msg" that can
+ inspect what is going to be committed and prepare the commit
+ log message template to be edited.
+
+ * "git cvsimport" can now take more than one -M options.
+
+ * "git describe" learned to limit the tags to be used for
+ naming with --match option.
+
+ * "git describe --contains" now barfs when the named commit
+ cannot be described.
+
+ * "git describe --exact-match" describes only commits that are tagged.
+
+ * "git describe --long" describes a tagged commit as $tag-0-$sha1,
+ instead of just showing the exact tagname.
+
+ * "git describe" warns when using a tag whose name and path contradict
+ with each other.
+
+ * "git diff" learned "--relative" option to limit and output paths
+ relative to the current directory when working in a subdirectory.
+
+ * "git diff" learned "--dirstat" option to show birds-eye-summary of
+ changes more concisely than "--diffstat".
+
+ * "git format-patch" learned --cover-letter option to generate a cover
+ letter template.
+
+ * "git gc" learned --quiet option.
+
+ * "git gc" now automatically prunes unreachable objects that are two
+ weeks old or older.
+
+ * "git gc --auto" can be disabled more easily by just setting gc.auto
+ to zero. It also tolerates more packfiles by default.
+
+ * "git grep" now knows "--name-only" is a synonym for the "-l" option.
+
+ * "git help <alias>" now reports "'git <alias>' is alias to <what>",
+ instead of saying "No manual entry for git-<alias>".
+
+ * "git help" can use different backends to show manual pages and this can
+ be configured using "man.viewer" configuration.
+
+ * "gitk" does not restore window position from $HOME/.gitk anymore (it
+ still restores the size).
+
+ * "git log --grep=<what>" learned "--fixed-strings" option to look for
+ <what> without treating it as a regular expression.
+
+ * "git gui" learned an auto-spell checking.
+
+ * "git push <somewhere> HEAD" and "git push <somewhere> +HEAD" works as
+ expected; they push the current branch (and only the current branch).
+ In addition, HEAD can be written as the value of "remote.<there>.push"
+ configuration variable.
+
+ * When the configuration variable "pack.threads" is set to 0, "git
+ repack" auto detects the number of CPUs and uses that many threads.
+
+ * "git send-email" learned to prompt for passwords
+ interactively.
+
+ * "git send-email" learned an easier way to suppress CC
+ recipients.
+
+ * "git stash" learned "pop" command, that applies the latest stash and
+ removes it from the stash, and "drop" command to discard the named
+ stash entry.
+
+ * "git submodule" learned a new subcommand "summary" to show the
+ symmetric difference between the HEAD version and the work tree version
+ of the submodule commits.
+
+ * Various "git cvsimport", "git cvsexportcommit", "git cvsserver",
+ "git svn" and "git p4" improvements.
+
+(internal)
+
+ * Duplicated code between git-help and git-instaweb that
+ launches user's preferred browser has been refactored.
+
+ * It is now easier to write test scripts that records known
+ breakages.
+
+ * "git checkout" is rewritten in C.
+
+ * "git remote" is rewritten in C.
+
+ * Two conflict hunks that are separated by a very short span of common
+ lines are now coalesced into one larger hunk, to make the result easier
+ to read.
+
+ * Run-command API's use of file descriptors is documented clearer and
+ is more consistent now.
+
+ * diff output can be sent to FILE * that is different from stdout. This
+ will help reimplementing more things in C.
+
+Fixes since v1.5.4
+------------------
+
+All of the fixes in v1.5.4 maintenance series are included in
+this release, unless otherwise noted.
+
+ * "git-http-push" did not allow deletion of remote ref with the usual
+ "push <remote> :<branch>" syntax.
+
+ * "git-rebase --abort" did not go back to the right location if
+ "git-reset" was run during the "git-rebase" session.
+
+ * "git imap-send" without setting imap.host did not error out but
+ segfaulted.
diff --git a/RelNotes/1.5.6.1.adoc b/RelNotes/1.5.6.1.adoc
new file mode 100644
index 0000000..4864b16
--- /dev/null
+++ b/RelNotes/1.5.6.1.adoc
@@ -0,0 +1,28 @@
+GIT v1.5.6.1 Release Notes
+==========================
+
+Fixes since v1.5.6
+------------------
+
+* Last minute change broke loose object creation on AIX.
+
+* (performance fix) We used to make $GIT_DIR absolute path early in the
+ programs but keeping it relative to the current directory internally
+ gives 1-3 per-cent performance boost.
+
+* bash completion knows the new --graph option to git-log family.
+
+
+* git-diff -c/--cc showed unnecessary "deletion" lines at the context
+ boundary.
+
+* git-for-each-ref ignored %(object) and %(type) requests for tag
+ objects.
+
+* git-merge usage had a typo.
+
+* Rebuilding of git-svn metainfo database did not take rewriteRoot
+ option into account.
+
+* Running "git-rebase --continue/--skip/--abort" before starting a
+ rebase gave nonsense error messages.
diff --git a/RelNotes/1.5.6.2.adoc b/RelNotes/1.5.6.2.adoc
new file mode 100644
index 0000000..5902a85
--- /dev/null
+++ b/RelNotes/1.5.6.2.adoc
@@ -0,0 +1,40 @@
+GIT v1.5.6.2 Release Notes
+==========================
+
+Futureproof
+-----------
+
+ * "git-shell" accepts requests without a dash between "git" and
+ subcommand name (e.g. "git upload-pack") which the newer client will
+ start to make sometime in the future.
+
+Fixes since v1.5.6.1
+--------------------
+
+* "git clone" from a remote that is named with url.insteadOf setting in
+ $HOME/.gitconfig did not work well.
+
+* "git describe --long --tags" segfaulted when the described revision was
+ tagged with a lightweight tag.
+
+* "git diff --check" did not report the result via its exit status
+ reliably.
+
+* When remote side used to have branch 'foo' and git-fetch finds that now
+ it has branch 'foo/bar', it refuses to lose the existing remote tracking
+ branch and its reflog. The error message has been improved to suggest
+ pruning the remote if the user wants to proceed and get the latest set
+ of branches from the remote, including such 'foo/bar'.
+
+* "git reset file" should mean the same thing as "git reset HEAD file",
+ but we required disambiguating -- even when "file" is not ambiguous.
+
+* "git show" segfaulted when an annotated tag that points at another
+ annotated tag was given to it.
+
+* Optimization for a large import via "git-svn" introduced in v1.5.6 had a
+ serious memory and temporary file leak, which made it unusable for
+ moderately large import.
+
+* "git-svn" mangled remote nickname used in the configuration file
+ unnecessarily.
diff --git a/RelNotes/1.5.6.3.adoc b/RelNotes/1.5.6.3.adoc
new file mode 100644
index 0000000..f61dd35
--- /dev/null
+++ b/RelNotes/1.5.6.3.adoc
@@ -0,0 +1,52 @@
+GIT v1.5.6.3 Release Notes
+==========================
+
+Fixes since v1.5.6.2
+--------------------
+
+* Setting core.sharedrepository to traditional "true" value was supposed to make
+ the repository group writable but should not affect permission for others.
+ However, since 1.5.6, it was broken to drop permission for others when umask is
+ 022, making the repository unreadable by others.
+
+* Setting GIT_TRACE will report spawning of external process via run_command().
+
+* Using an object with very deep delta chain pinned memory needed for extracting
+ intermediate base objects unnecessarily long, leading to excess memory usage.
+
+* Bash completion script did not notice '--' marker on the command
+ line and tried the relatively slow "ref completion" even when
+ completing arguments after one.
+
+* Registering a non-empty blob racily and then truncating the working
+ tree file for it confused "racy-git avoidance" logic into thinking
+ that the path is now unchanged.
+
+* The section that describes attributes related to git-archive were placed
+ in a wrong place in the gitattributes(5) manual page.
+
+* "git am" was not helpful to the users when it detected that the committer
+ information is not set up properly yet.
+
+* "git clone" had a leftover debugging fprintf().
+
+* "git clone -q" was not quiet enough as it used to and gave object count
+ and progress reports.
+
+* "git clone" marked downloaded packfile with .keep; this could be a
+ good thing if the remote side is well packed but otherwise not,
+ especially for a project that is not really big.
+
+* "git daemon" used to call syslog() from a signal handler, which
+ could raise signals of its own but generally is not reentrant. This
+ was fixed by restructuring the code to report syslog() after the handler
+ returns.
+
+* When "git push" tries to remove a remote ref, and corresponding
+ tracking ref is missing, we used to report error (i.e. failure to
+ remove something that does not exist).
+
+* "git mailinfo" (hence "git am") did not handle commit log messages in a
+ MIME multipart mail correctly.
+
+Contains other various documentation fixes.
diff --git a/RelNotes/1.5.6.4.adoc b/RelNotes/1.5.6.4.adoc
new file mode 100644
index 0000000..d8968f1
--- /dev/null
+++ b/RelNotes/1.5.6.4.adoc
@@ -0,0 +1,47 @@
+GIT v1.5.6.4 Release Notes
+==========================
+
+Fixes since v1.5.6.3
+--------------------
+
+* Various commands could overflow its internal buffer on a platform
+ with small PATH_MAX value in a repository that has contents with
+ long pathnames.
+
+* There wasn't a way to make --pretty=format:%<> specifiers to honor
+ .mailmap name rewriting for authors and committers. Now you can with
+ %aN and %cN.
+
+* Bash completion wasted too many cycles; this has been optimized to be
+ usable again.
+
+* Bash completion lost ref part when completing something like "git show
+ pu:Makefile".
+
+* "git-cvsserver" did not clean up its temporary working area after annotate
+ request.
+
+* "git-daemon" called syslog() from its signal handler, which was a
+ no-no.
+
+* "git-fetch" into an empty repository used to remind that the fetch will
+ be huge by saying "no common commits", but this was an unnecessary
+ noise; it is already known by the user anyway.
+
+* "git-http-fetch" would have segfaulted when pack idx file retrieved
+ from the other side was corrupt.
+
+* "git-index-pack" used too much memory when dealing with a deep delta chain.
+
+* "git-mailinfo" (hence "git-am") did not correctly handle in-body [PATCH]
+ line to override the commit title taken from the mail Subject header.
+
+* "git-rebase -i -p" lost parents that are not involved in the history
+ being rewritten.
+
+* "git-rm" lost track of where the index file was when GIT_DIR was
+ specified as a relative path.
+
+* "git-rev-list --quiet" was not quiet as advertised.
+
+Contains other various documentation fixes.
diff --git a/RelNotes/1.5.6.5.adoc b/RelNotes/1.5.6.5.adoc
new file mode 100644
index 0000000..47ca172
--- /dev/null
+++ b/RelNotes/1.5.6.5.adoc
@@ -0,0 +1,29 @@
+GIT v1.5.6.5 Release Notes
+==========================
+
+Fixes since v1.5.6.4
+--------------------
+
+* "git cvsimport" used to spit out "UNKNOWN LINE..." diagnostics to stdout.
+
+* "git commit -F filename" and "git tag -F filename" run from subdirectories
+ did not read the right file.
+
+* "git init --template=" with blank "template" parameter linked files
+ under root directories to .git, which was a total nonsense. Instead, it
+ means "I do not want to use anything from the template directory".
+
+* "git diff-tree" and other diff plumbing ignored diff.renamelimit configuration
+ variable when the user explicitly asked for rename detection.
+
+* "git name-rev --name-only" did not work when "--stdin" option was in effect.
+
+* "git show-branch" mishandled its 8th branch.
+
+* Addition of "git update-index --ignore-submodules" that happened during
+ 1.5.6 cycle broke "git update-index --ignore-missing".
+
+* "git send-email" did not parse charset from an existing Content-type:
+ header properly.
+
+Contains other various documentation fixes.
diff --git a/RelNotes/1.5.6.6.adoc b/RelNotes/1.5.6.6.adoc
new file mode 100644
index 0000000..79da23d
--- /dev/null
+++ b/RelNotes/1.5.6.6.adoc
@@ -0,0 +1,10 @@
+GIT v1.5.6.6 Release Notes
+==========================
+
+Fixes since 1.5.6.5
+-------------------
+
+ * Removed support for an obsolete gitweb request URI, whose
+ implementation ran "git diff" Porcelain, instead of using plumbing,
+ which would have run an external diff command specified in the
+ repository configuration as the gitweb user.
diff --git a/RelNotes/1.5.6.adoc b/RelNotes/1.5.6.adoc
new file mode 100644
index 0000000..e143d8d
--- /dev/null
+++ b/RelNotes/1.5.6.adoc
@@ -0,0 +1,115 @@
+GIT v1.5.6 Release Notes
+========================
+
+Updates since v1.5.5
+--------------------
+
+(subsystems)
+
+* Comes with updated gitk and git-gui.
+
+(portability)
+
+* git will build on AIX better than before now.
+
+* core.ignorecase configuration variable can be used to work better on
+ filesystems that are not case sensitive.
+
+* "git init" now autodetects the case sensitivity of the filesystem and
+ sets core.ignorecase accordingly.
+
+* cpio is no longer used; neither "curl" binary (libcurl is still used).
+
+(documentation)
+
+* Many freestanding documentation pages have been converted and made
+ available to "git help" (aka "man git<something>") as section 7 of
+ the manual pages. This means bookmarks to some HTML documentation
+ files may need to be updated (eg "tutorial.html" became
+ "gittutorial.html").
+
+(performance)
+
+* "git clone" was rewritten in C. This will hopefully help cloning a
+ repository with insane number of refs.
+
+* "git rebase --onto $there $from $branch" used to switch to the tip of
+ $branch only to immediately reset back to $from, smudging work tree
+ files unnecessarily. This has been optimized.
+
+* Object creation codepath in "git-svn" has been optimized by enhancing
+ plumbing commands git-cat-file and git-hash-object.
+
+(usability, bells and whistles)
+
+* "git add -p" (and the "patch" subcommand of "git add -i") can choose to
+ apply (or not apply) mode changes independently from contents changes.
+
+* "git bisect help" gives longer and more helpful usage information.
+
+* "git bisect" does not use a special branch "bisect" anymore; instead, it
+ does its work on a detached HEAD.
+
+* "git branch" (and "git checkout -b") can be told to set up
+ branch.<name>.rebase automatically, so that later you can say "git pull"
+ and magically cause "git pull --rebase" to happen.
+
+* "git branch --merged" and "git branch --no-merged" can be used to list
+ branches that have already been merged (or not yet merged) to the
+ current branch.
+
+* "git cherry-pick" and "git revert" can add a sign-off.
+
+* "git commit" mentions the author identity when you are committing
+ somebody else's changes.
+
+* "git diff/log --dirstat" output is consistent between binary and textual
+ changes.
+
+* "git filter-branch" rewrites signed tags by demoting them to annotated.
+
+* "git format-patch --no-binary" can produce a patch that lack binary
+ changes (i.e. cannot be used to propagate the whole changes) meant only
+ for reviewing.
+
+* "git init --bare" is a synonym for "git --bare init" now.
+
+* "git gc --auto" honors a new pre-auto-gc hook to temporarily disable it.
+
+* "git log --pretty=tformat:<custom format>" gives a LF after each entry,
+ instead of giving a LF between each pair of entries which is how
+ "git log --pretty=format:<custom format>" works.
+
+* "git log" and friends learned the "--graph" option to show the ancestry
+ graph at the left margin of the output.
+
+* "git log" and friends can be told to use date format that is different
+ from the default via 'log.date' configuration variable.
+
+* "git send-email" now can send out messages outside a git repository.
+
+* "git send-email --compose" was made aware of rfc2047 quoting.
+
+* "git status" can optionally include output from "git submodule
+ summary".
+
+* "git svn" learned --add-author-from option to propagate the authorship
+ by munging the commit log message.
+
+* new object creation and looking up in "git svn" has been optimized.
+
+* "gitweb" can read from a system-wide configuration file.
+
+(internal)
+
+* "git unpack-objects" and "git receive-pack" is now more strict about
+ detecting breakage in the objects they receive over the wire.
+
+
+Fixes since v1.5.5
+------------------
+
+All of the fixes in v1.5.5 maintenance series are included in
+this release, unless otherwise noted.
+
+And there are too numerous small fixes to otherwise note here ;-)
diff --git a/RelNotes/1.6.0.1.adoc b/RelNotes/1.6.0.1.adoc
new file mode 100644
index 0000000..49d7a1c
--- /dev/null
+++ b/RelNotes/1.6.0.1.adoc
@@ -0,0 +1,36 @@
+GIT v1.6.0.1 Release Notes
+==========================
+
+Fixes since v1.6.0
+------------------
+
+* "git diff --cc" did not honor content mangling specified by
+ gitattributes and core.autocrlf when reading from the work tree.
+
+* "git diff --check" incorrectly detected new trailing blank lines when
+ whitespace check was in effect.
+
+* "git for-each-ref" tried to dereference NULL when asked for '%(body)" on
+ a tag with a single incomplete line as its payload.
+
+* "git format-patch" peeked before the beginning of a string when
+ "format.headers" variable is empty (a misconfiguration).
+
+* "git help help" did not work correctly.
+
+* "git mailinfo" (hence "git am") was unhappy when MIME multipart message
+ contained garbage after the finishing boundary.
+
+* "git mailinfo" also was unhappy when the "From: " line only had a bare
+ e-mail address.
+
+* "git merge" did not refresh the index correctly when a merge resulted in
+ a fast-forward.
+
+* "git merge" did not resolve a truly trivial merges that can be done
+ without content level merges.
+
+* "git svn dcommit" to a repository with URL that has embedded usernames
+ did not work correctly.
+
+Contains other various documentation fixes.
diff --git a/RelNotes/1.6.0.2.adoc b/RelNotes/1.6.0.2.adoc
new file mode 100644
index 0000000..7d8fb85
--- /dev/null
+++ b/RelNotes/1.6.0.2.adoc
@@ -0,0 +1,81 @@
+GIT v1.6.0.2 Release Notes
+==========================
+
+Fixes since v1.6.0.1
+--------------------
+
+* Installation on platforms that needs .exe suffix to git-* programs were
+ broken in 1.6.0.1.
+
+* Installation on filesystems without symbolic links support did not
+ work well.
+
+* In-tree documentations and test scripts now use "git foo" form to set a
+ better example, instead of the "git-foo" form (which is an acceptable
+ form if you have "PATH=$(git --exec-path):$PATH" in your script)
+
+* Many commands did not use the correct working tree location when used
+ with GIT_WORK_TREE environment settings.
+
+* Some systems need to use compatibility fnmatch and regex libraries
+ independent from each other; the compat/ area has been reorganized to
+ allow this.
+
+
+* "git apply --unidiff-zero" incorrectly applied a -U0 patch that inserts
+ a new line before the second line.
+
+* "git blame -c" did not exactly work like "git annotate" when range
+ boundaries are involved.
+
+* "git checkout file" when file is still unmerged checked out contents from
+ a random high order stage, which was confusing.
+
+* "git clone $there $here/" with extra trailing slashes after explicit
+ local directory name $here did not work as expected.
+
+* "git diff" on tracked contents with CRLF line endings did not drive "less"
+ intelligently when showing added or removed lines.
+
+* "git diff --dirstat -M" did not add changes in subdirectories up
+ correctly for renamed paths.
+
+* "git diff --cumulative" did not imply "--dirstat".
+
+* "git for-each-ref refs/heads/" did not work as expected.
+
+* "git gui" allowed users to feed patch without any context to be applied.
+
+* "git gui" botched parsing "diff" output when a line that begins with two
+ dashes and a space gets removed or a line that begins with two pluses
+ and a space gets added.
+
+* "git gui" translation updates and i18n fixes.
+
+* "git index-pack" is more careful against disk corruption while completing
+ a thin pack.
+
+* "git log -i --grep=pattern" did not ignore case; neither "git log -E
+ --grep=pattern" triggered extended regexp.
+
+* "git log --pretty="%ad" --date=short" did not use short format when
+ showing the timestamp.
+
+* "git log --author=author" match incorrectly matched with the
+ timestamp part of "author " line in commit objects.
+
+* "git log -F --author=author" did not work at all.
+
+* Build procedure for "git shell" that used stub versions of some
+ functions and globals was not understood by linkers on some platforms.
+
+* "git stash" was fooled by a stat-dirty but otherwise unmodified paths
+ and refused to work until the user refreshed the index.
+
+* "git svn" was broken on Perl before 5.8 with recent fixes to reduce
+ use of temporary files.
+
+* "git verify-pack -v" did not work correctly when given more than one
+ packfile.
+
+Also contains many documentation updates.
diff --git a/RelNotes/1.6.0.3.adoc b/RelNotes/1.6.0.3.adoc
new file mode 100644
index 0000000..ad36c0f
--- /dev/null
+++ b/RelNotes/1.6.0.3.adoc
@@ -0,0 +1,117 @@
+GIT v1.6.0.3 Release Notes
+==========================
+
+Fixes since v1.6.0.2
+--------------------
+
+* "git archive --format=zip" did not honor core.autocrlf while
+ --format=tar did.
+
+* Continuing "git rebase -i" was very confused when the user left modified
+ files in the working tree while resolving conflicts.
+
+* Continuing "git rebase -i" was also very confused when the user left
+ some staged changes in the index after "edit".
+
+* "git rebase -i" now honors the pre-rebase hook, just like the
+ other rebase implementations "git rebase" and "git rebase -m".
+
+* "git rebase -i" incorrectly aborted when there is no commit to replay.
+
+* Behaviour of "git diff --quiet" was inconsistent with "diff --exit-code"
+ with the output redirected to /dev/null.
+
+* "git diff --no-index" on binary files no longer outputs a bogus
+ "diff --git" header line.
+
+* "git diff" hunk header patterns with multiple elements separated by LF
+ were not used correctly.
+
+* Hunk headers in "git diff" default to using extended regular
+ expressions, fixing some of the internal patterns on non-GNU
+ platforms.
+
+* New config "diff.*.xfuncname" exposes extended regular expressions
+ for user specified hunk header patterns.
+
+* "git gc" when ejecting otherwise unreachable objects from packfiles into
+ loose form leaked memory.
+
+* "git index-pack" was recently broken and mishandled objects added by
+ thin-pack completion processing under memory pressure.
+
+* "git index-pack" was recently broken and misbehaved when run from inside
+ .git/objects/pack/ directory.
+
+* "git stash apply sash@{1}" was fixed to error out. Prior versions
+ would have applied stash@{0} incorrectly.
+
+* "git stash apply" now offers a better suggestion on how to continue
+ if the working tree is currently dirty.
+
+* "git for-each-ref --format=%(subject)" fixed for commits with no
+ newline in the message body.
+
+* "git remote" fixed to protect printf from user input.
+
+* "git remote show -v" now displays all URLs of a remote.
+
+* "git checkout -b branch" was confused when branch already existed.
+
+* "git checkout -q" once again suppresses the locally modified file list.
+
+* "git clone -q", "git fetch -q" asks remote side to not send
+ progress messages, actually making their output quiet.
+
+* Cross-directory renames are no longer used when creating packs. This
+ allows more graceful behavior on filesystems like sshfs.
+
+* Stale temporary files under $GIT_DIR/objects/pack are now cleaned up
+ automatically by "git prune".
+
+* "git merge" once again removes directories after the last file has
+ been removed from it during the merge.
+
+* "git merge" did not allocate enough memory for the structure itself when
+ enumerating the parents of the resulting commit.
+
+* "git blame -C -C" no longer segfaults while trying to pass blame if
+ it encounters a submodule reference.
+
+* "git rm" incorrectly claimed that you have local modifications when a
+ path was merely stat-dirty.
+
+* "git svn" fixed to display an error message when 'set-tree' failed,
+ instead of a Perl compile error.
+
+* "git submodule" fixed to handle checking out a different commit
+ than HEAD after initializing the submodule.
+
+* The "git commit" error message when there are still unmerged
+ files present was clarified to match "git write-tree".
+
+* "git init" was confused when core.bare or core.sharedRepository are set
+ in system or user global configuration file by mistake. When --bare or
+ --shared is given from the command line, these now override such
+ settings made outside the repositories.
+
+* Some segfaults due to uncaught NULL pointers were fixed in multiple
+ tools such as apply, reset, update-index.
+
+* Solaris builds now default to OLD_ICONV=1 to avoid compile warnings;
+ Solaris 8 does not define NEEDS_LIBICONV by default.
+
+* "Git.pm" tests relied on unnecessarily more recent version of Perl.
+
+* "gitweb" triggered undef warning on commits without log messages.
+
+* "gitweb" triggered undef warnings on missing trees.
+
+* "gitweb" now removes PATH_INFO from its URLs so users don't have
+ to manually set the URL in the gitweb configuration.
+
+* Bash completion removed support for legacy "git-fetch", "git-push"
+ and "git-pull" as these are no longer installed. Dashless form
+ ("git fetch") is still however supported.
+
+Many other documentation updates.
diff --git a/RelNotes/1.6.0.4.adoc b/RelNotes/1.6.0.4.adoc
new file mode 100644
index 0000000..d522661
--- /dev/null
+++ b/RelNotes/1.6.0.4.adoc
@@ -0,0 +1,39 @@
+GIT v1.6.0.4 Release Notes
+==========================
+
+Fixes since v1.6.0.3
+--------------------
+
+* 'git add -p' said "No changes" when only binary files were changed.
+
+* 'git archive' did not work correctly in bare repositories.
+
+* 'git checkout -t -b newbranch' when you are on detached HEAD was broken.
+
+* when we refuse to detect renames because there are too many new or
+ deleted files, 'git diff' did not say how many there are.
+
+* 'git push --mirror' tried and failed to push the stash; there is no
+ point in sending it to begin with.
+
+* 'git push' did not update the remote tracking reference if the corresponding
+ ref on the remote end happened to be already up to date.
+
+* 'git pull $there $branch:$current_branch' did not work when you were on
+ a branch yet to be born.
+
+* when giving up resolving a conflicted merge, 'git reset --hard' failed
+ to remove new paths from the working tree.
+
+* 'git send-email' had a small fd leak while scanning directory.
+
+* 'git status' incorrectly reported a submodule directory as an untracked
+ directory.
+
+* 'git svn' used deprecated 'git-foo' form of subcommand invocation.
+
+* 'git update-ref -d' to remove a reference did not honor --no-deref option.
+
+* Plugged small memleaks here and there.
+
+* Also contains many documentation updates.
diff --git a/RelNotes/1.6.0.5.adoc b/RelNotes/1.6.0.5.adoc
new file mode 100644
index 0000000..a08bb96
--- /dev/null
+++ b/RelNotes/1.6.0.5.adoc
@@ -0,0 +1,56 @@
+GIT v1.6.0.5 Release Notes
+==========================
+
+Fixes since v1.6.0.4
+--------------------
+
+* "git checkout" used to crash when your HEAD was pointing at a deleted
+ branch.
+
+* "git checkout" from an un-checked-out state did not allow switching out
+ of the current branch.
+
+* "git diff" always allowed GIT_EXTERNAL_DIFF and --no-ext-diff was no-op for
+ the command.
+
+* Giving 3 or more tree-ish to "git diff" is supposed to show the combined
+ diff from second and subsequent trees to the first one, but the order was
+ screwed up.
+
+* "git fast-export" did not export all tags.
+
+* "git ls-files --with-tree=<tree>" did not work with options other
+ than -c, most notably with -m.
+
+* "git pack-objects" did not make its best effort to honor --max-pack-size
+ option when a single first object already busted the given limit and
+ placed many objects in a single pack.
+
+* "git-p4" fast import frontend was too eager to trigger its keyword expansion
+ logic, even on a keyword-looking string that does not have closing '$' on the
+ same line.
+
+* "git push $there" when the remote $there is defined in $GIT_DIR/branches/$there
+ behaves more like what cg-push from Cogito used to work.
+
+* when giving up resolving a conflicted merge, "git reset --hard" failed
+ to remove new paths from the working tree.
+
+* "git tag" did not complain when given mutually incompatible set of options.
+
+* The message constructed in the internal editor was discarded when "git
+ tag -s" failed to sign the message, which was often caused by the user
+ not configuring GPG correctly.
+
+* "make check" cannot be run without sparse; people may have meant to say
+ "make test" instead, so suggest that.
+
+* Internal diff machinery had a corner case performance bug that choked on
+ a large file with many repeated contents.
+
+* "git repack" used to grab objects out of packs marked with .keep
+ into a new pack.
+
+* Many unsafe call to sprintf() style varargs functions are corrected.
+
+* Also contains quite a few documentation updates.
diff --git a/RelNotes/1.6.0.6.adoc b/RelNotes/1.6.0.6.adoc
new file mode 100644
index 0000000..64ece1f
--- /dev/null
+++ b/RelNotes/1.6.0.6.adoc
@@ -0,0 +1,33 @@
+GIT v1.6.0.6 Release Notes
+==========================
+
+Fixes since 1.6.0.5
+-------------------
+
+ * "git fsck" had a deep recursion that wasted stack space.
+
+ * "git fast-export" and "git fast-import" choked on an old style
+ annotated tag that lack the tagger information.
+
+ * "git mergetool -- file" did not correctly skip "--" marker that
+ signals the end of options list.
+
+ * "git show $tag" segfaulted when an annotated $tag pointed at a
+ nonexistent object.
+
+ * "git show 2>error" when the standard output is automatically redirected
+ to the pager redirected the standard error to the pager as well; there
+ was no need to.
+
+ * "git send-email" did not correctly handle list of addresses when
+ they had quoted comma (e.g. "Lastname, Givenname" <mail@addre.ss>).
+
+ * Logic to discover branch ancestry in "git svn" was unreliable when
+ the process to fetch history was interrupted.
+
+ * Removed support for an obsolete gitweb request URI, whose
+ implementation ran "git diff" Porcelain, instead of using plumbing,
+ which would have run an external diff command specified in the
+ repository configuration as the gitweb user.
+
+Also contains numerous documentation typofixes.
diff --git a/RelNotes/1.6.0.adoc b/RelNotes/1.6.0.adoc
new file mode 100644
index 0000000..de7ef16
--- /dev/null
+++ b/RelNotes/1.6.0.adoc
@@ -0,0 +1,258 @@
+GIT v1.6.0 Release Notes
+========================
+
+User visible changes
+--------------------
+
+With the default Makefile settings, most of the programs are now
+installed outside your $PATH, except for "git", "gitk" and
+some server side programs that need to be accessible for technical
+reasons. Invoking a git subcommand as "git-xyzzy" from the command
+line has been deprecated since early 2006 (and officially announced in
+1.5.4 release notes); use of them from your scripts after adding
+output from "git --exec-path" to the $PATH is still supported in this
+release, but users are again strongly encouraged to adjust their
+scripts to use "git xyzzy" form, as we will stop installing
+"git-xyzzy" hardlinks for built-in commands in later releases.
+
+An earlier change to page "git status" output was overwhelmingly unpopular
+and has been reverted.
+
+Source changes needed for porting to MinGW environment are now all in the
+main git.git codebase.
+
+By default, packfiles created with this version uses delta-base-offset
+encoding introduced in v1.4.4. Pack idx files are using version 2 that
+allows larger packs and added robustness thanks to its CRC checking,
+introduced in v1.5.2 and v1.4.4.5. If you want to keep your repositories
+backwards compatible past these versions, set repack.useDeltaBaseOffset
+to false or pack.indexVersion to 1, respectively.
+
+We used to prevent sample hook scripts shipped in templates/ from
+triggering by default by relying on the fact that we install them as
+unexecutable, but on some filesystems, this approach does not work.
+They are now shipped with ".sample" suffix. If you want to activate
+any of these samples as-is, rename them to drop the ".sample" suffix,
+instead of running "chmod +x" on them. For example, you can rename
+hooks/post-update.sample to hooks/post-update to enable the sample
+hook that runs update-server-info, in order to make repositories
+friendly to dumb protocols (i.e. HTTP).
+
+GIT_CONFIG, which was only documented as affecting "git config", but
+actually affected all git commands, now only affects "git config".
+GIT_LOCAL_CONFIG, also only documented as affecting "git config" and
+not different from GIT_CONFIG in a useful way, is removed.
+
+The ".dotest" temporary area "git am" and "git rebase" use is now moved
+inside the $GIT_DIR, to avoid mistakes of adding it to the project by
+accident.
+
+An ancient merge strategy "stupid" has been removed.
+
+
+Updates since v1.5.6
+--------------------
+
+(subsystems)
+
+* git-p4 in contrib learned "allowSubmit" configuration to control on
+ which branch to allow "submit" subcommand.
+
+* git-gui learned to stage changes per-line.
+
+(portability)
+
+* Changes for MinGW port have been merged, thanks to Johannes Sixt and
+ gangs.
+
+* Sample hook scripts shipped in templates/ are now suffixed with
+ *.sample.
+
+* perl's in-place edit (-i) does not work well without backup files on Windows;
+ some tests are rewritten to cope with this.
+
+(documentation)
+
+* Updated howto/update-hook-example
+
+* Got rid of usage of "git-foo" from the tutorial and made typography
+ more consistent.
+
+* Disambiguating "--" between revs and paths is finally documented.
+
+(performance, robustness, sanity etc.)
+
+* index-pack used too much memory when dealing with a deep delta chain.
+ This has been optimized.
+
+* reduced excessive inlining to shrink size of the "git" binary.
+
+* verify-pack checks the object CRC when using version 2 idx files.
+
+* When an object is corrupt in a pack, the object became unusable even
+ when the same object is available in a loose form, We now try harder to
+ fall back to these redundant objects when able. In particular, "git
+ repack -a -f" can be used to fix such a corruption as long as necessary
+ objects are available.
+
+* Performance of "git-blame -C -C" operation is vastly improved.
+
+* git-clone does not create refs in loose form anymore (it behaves as
+ if you immediately ran git-pack-refs after cloning). This will help
+ repositories with insanely large number of refs.
+
+* core.fsyncobjectfiles configuration can be used to ensure that the loose
+ objects created will be fsync'ed (this is only useful on filesystems
+ that does not order data writes properly).
+
+* "git commit-tree" plumbing can make Octopus with more than 16 parents.
+ "git commit" has been capable of this for quite some time.
+
+(usability, bells and whistles)
+
+* even more documentation pages are now accessible via "man" and "git help".
+
+* A new environment variable GIT_CEILING_DIRECTORIES can be used to stop
+ the discovery process of the toplevel of working tree; this may be useful
+ when you are working in a slow network disk and are outside any working tree,
+ as bash-completion and "git help" may still need to run in these places.
+
+* By default, stash entries never expire. Set reflogexpire in [gc
+ "refs/stash"] to a reasonable value to get traditional auto-expiration
+ behaviour back
+
+* Longstanding latency issue with bash completion script has been
+ addressed. This will need to be backmerged to 'maint' later.
+
+* pager.<cmd> configuration variable can be used to enable/disable the
+ default paging behaviour per command.
+
+* "git-add -i" has a new action 'e/dit' to allow you edit the patch hunk
+ manually.
+
+* git-am records the original tip of the branch in ORIG_HEAD before it
+ starts applying patches.
+
+* git-apply can handle a patch that touches the same path more than once
+ much better than before.
+
+* git-apply can be told not to trust the line counts recorded in the input
+ patch but recount, with the new --recount option.
+
+* git-apply can be told to apply a patch to a path deeper than what the
+ patch records with --directory option.
+
+* git-archive can be told to omit certain paths from its output using
+ export-ignore attributes.
+
+* git-archive uses the zlib default compression level when creating
+ zip archive.
+
+* git-archive's command line options --exec and --remote can take their
+ parameters as separate command line arguments, similar to other commands.
+ IOW, both "--exec=path" and "--exec path" are now supported.
+
+* With -v option, git-branch describes the remote tracking statistics
+ similar to the way git-checkout reports by how many commits your branch
+ is ahead/behind.
+
+* git-branch's --contains option used to always require a commit parameter
+ to limit the branches with; it now defaults to list branches that
+ contains HEAD if this parameter is omitted.
+
+* git-branch's --merged and --no-merged option used to always limit the
+ branches relative to the HEAD, but they can now take an optional commit
+ argument that is used in place of HEAD.
+
+* git-bundle can read the revision arguments from the standard input.
+
+* git-cherry-pick can replay a root commit now.
+
+* git-clone can clone from a remote whose URL would be rewritten by
+ configuration stored in $HOME/.gitconfig now.
+
+* "git-clone --mirror" is a handy way to set up a bare mirror repository.
+
+* git-cvsserver learned to respond to "cvs co -c".
+
+* git-diff --check now checks leftover merge conflict markers.
+
+* "git-diff -p" learned to grab a better hunk header lines in
+ BibTex, Pascal/Delphi, and Ruby files and also pays attention to
+ chapter and part boundary in TeX documents.
+
+* When remote side used to have branch 'foo' and git-fetch finds that now
+ it has branch 'foo/bar', it refuses to lose the existing remote tracking
+ branch and its reflog. The error message has been improved to suggest
+ pruning the remote if the user wants to proceed and get the latest set
+ of branches from the remote, including such 'foo/bar'.
+
+* fast-export learned to export and import marks file; this can be used to
+ interface with fast-import incrementally.
+
+* fast-import and fast-export learned to export and import gitlinks.
+
+* "gitk" left background process behind after being asked to dig very deep
+ history and the user killed the UI; the process is killed when the UI goes
+ away now.
+
+* git-rebase records the original tip of branch in ORIG_HEAD before it is
+ rewound.
+
+* "git rerere" can be told to update the index with auto-reused resolution
+ with rerere.autoupdate configuration variable.
+
+* git-rev-parse learned $commit^! and $commit^@ notations used in "log"
+ family. These notations are available in gitk as well, because the gitk
+ command internally uses rev-parse to interpret its arguments.
+
+* git-rev-list learned --children option to show child commits it
+ encountered during the traversal, instead of showing parent commits.
+
+* git-send-mail can talk not just over SSL but over TLS now.
+
+* git-shortlog honors custom output format specified with "--pretty=format:".
+
+* "git-stash save" learned --keep-index option. This lets you stash away the
+ local changes and bring the changes staged in the index to your working
+ tree for examination and testing.
+
+* git-stash also learned branch subcommand to create a new branch out of
+ stashed changes.
+
+* git-status gives the remote tracking statistics similar to the way
+ git-checkout reports by how many commits your branch is ahead/behind.
+
+* "git-svn dcommit" is now aware of auto-props setting the subversion user
+ has.
+
+* You can tell "git status -u" to even more aggressively omit checking
+ untracked files with --untracked-files=no.
+
+* Original SHA-1 value for "update-ref -d" is optional now.
+
+* Error codes from gitweb are made more descriptive where possible, rather
+ than "403 forbidden" as we used to issue everywhere.
+
+(internal)
+
+* git-merge has been reimplemented in C.
+
+
+Fixes since v1.5.6
+------------------
+
+All of the fixes in v1.5.6 maintenance series are included in
+this release, unless otherwise noted.
+
+ * git-clone ignored its -u option; the fix needs to be backported to
+ 'maint';
+
+ * git-mv used to lose the distinction between changes that are staged
+ and that are only in the working tree, by staging both in the index
+ after moving such a path.
+
+ * "git-rebase -i -p" rewrote the parents to wrong ones when amending
+ (either edit or squash) was involved, and did not work correctly
+ when fast forwarding.
+
diff --git a/RelNotes/1.6.1.1.adoc b/RelNotes/1.6.1.1.adoc
new file mode 100644
index 0000000..8c594ba
--- /dev/null
+++ b/RelNotes/1.6.1.1.adoc
@@ -0,0 +1,59 @@
+GIT v1.6.1.1 Release Notes
+==========================
+
+Fixes since v1.6.1
+------------------
+
+* "git add frotz/nitfol" when "frotz" is a submodule should have errored
+ out, but it didn't.
+
+* "git apply" took file modes from the patch text and updated the mode
+ bits of the target tree even when the patch was not about mode changes.
+
+* "git bisect view" on Cygwin did not launch gitk
+
+* "git checkout $tree" did not trigger an error.
+
+* "git commit" tried to remove COMMIT_EDITMSG from the work tree by mistake.
+
+* "git describe --all" complained when a commit is described with a tag,
+ which was nonsense.
+
+* "git diff --no-index --" did not trigger no-index (aka "use git-diff as
+ a replacement of diff on untracked files") behaviour.
+
+* "git format-patch -1 HEAD" on a root commit failed to produce patch
+ text.
+
+* "git fsck branch" did not work as advertised; instead it behaved the same
+ way as "git fsck".
+
+* "git log --pretty=format:%s" did not handle a multi-line subject the
+ same way as built-in log listers (i.e. shortlog, --pretty=oneline, etc.)
+
+* "git daemon", and "git merge-file" are more careful when freopen fails
+ and barf, instead of going on and writing to unopened filehandle.
+
+* "git http-push" did not like some RFC 4918 compliant DAV server
+ responses.
+
+* "git merge -s recursive" mistakenly overwritten an untracked file in the
+ work tree upon delete/modify conflict.
+
+* "git merge -s recursive" didn't leave the index unmerged for entries with
+ rename/delete conflicts.
+
+* "git merge -s recursive" clobbered untracked files in the work tree.
+
+* "git mv -k" with more than one erroneous paths misbehaved.
+
+* "git read-tree -m -u" hence branch switching incorrectly lost a
+ subdirectory in rare cases.
+
+* "git rebase -i" issued an unnecessary error message upon a user error of
+ marking the first commit to be "squash"ed.
+
+* "git shortlog" did not format a commit message with multi-line
+ subject correctly.
+
+Many documentation updates.
diff --git a/RelNotes/1.6.1.2.adoc b/RelNotes/1.6.1.2.adoc
new file mode 100644
index 0000000..be37cbb
--- /dev/null
+++ b/RelNotes/1.6.1.2.adoc
@@ -0,0 +1,39 @@
+GIT v1.6.1.2 Release Notes
+==========================
+
+Fixes since v1.6.1.1
+--------------------
+
+* The logic for rename detection in internal diff used by commands like
+ "git diff" and "git blame" has been optimized to avoid loading the same
+ blob repeatedly.
+
+* We did not allow writing out a blob that is larger than 2GB for no good
+ reason.
+
+* "git format-patch -o $dir", when $dir is a relative directory, used it
+ as relative to the root of the work tree, not relative to the current
+ directory.
+
+* v1.6.1 introduced an optimization for "git push" into a repository (A)
+ that borrows its objects from another repository (B) to avoid sending
+ objects that are available in repository B, when they are not yet used
+ by repository A. However the code on the "git push" sender side was
+ buggy and did not work when repository B had new objects that are not
+ known by the sender. This caused pushing into a "forked" repository
+ served by v1.6.1 software using "git push" from v1.6.1 sometimes did not
+ work. The bug was purely on the "git push" sender side, and has been
+ corrected.
+
+* "git status -v" did not paint its diff output in colour even when
+ color.ui configuration was set.
+
+* "git ls-tree" learned --full-tree option to help Porcelain scripts that
+ want to always see the full path regardless of the current working
+ directory.
+
+* "git grep" incorrectly searched in work tree paths even when they are
+ marked as assume-unchanged. It now searches in the index entries.
+
+* "git gc" with no grace period needlessly ejected packed but unreachable
+ objects in their loose form, only to delete them right away.
diff --git a/RelNotes/1.6.1.3.adoc b/RelNotes/1.6.1.3.adoc
new file mode 100644
index 0000000..cd08d81
--- /dev/null
+++ b/RelNotes/1.6.1.3.adoc
@@ -0,0 +1,28 @@
+GIT v1.6.1.3 Release Notes
+==========================
+
+Fixes since v1.6.1.2
+--------------------
+
+* "git diff --binary | git apply" pipeline did not work well when
+ a binary blob is changed to a symbolic link.
+
+* Some combinations of -b/-w/--ignore-space-at-eol to "git diff" did
+ not work as expected.
+
+* "git grep" did not pass the -I (ignore binary) option when
+ calling out an external grep program.
+
+* "git log" and friends include HEAD to the set of starting points
+ when --all is given. This makes a difference when you are not
+ on any branch.
+
+* "git mv" to move an untracked file to overwrite a tracked
+ contents misbehaved.
+
+* "git merge -s octopus" with many potential merge bases did not
+ work correctly.
+
+* RPM binary package installed the html manpages in a wrong place.
+
+Also includes minor documentation fixes and updates.
diff --git a/RelNotes/1.6.1.4.adoc b/RelNotes/1.6.1.4.adoc
new file mode 100644
index 0000000..ccbad79
--- /dev/null
+++ b/RelNotes/1.6.1.4.adoc
@@ -0,0 +1,41 @@
+GIT v1.6.1.4 Release Notes
+==========================
+
+Fixes since v1.6.1.3
+--------------------
+
+* .gitignore learned to handle backslash as a quoting mechanism for
+ comment introduction character "#".
+ This fix was first merged to 1.6.2.1.
+
+* "git fast-export" produced wrong output with some parents missing from
+ commits, when the history is clock-skewed.
+
+* "git fast-import" sometimes failed to read back objects it just wrote
+ out and aborted, because it failed to flush stale cached data.
+
+* "git-ls-tree" and "git-diff-tree" used a pathspec correctly when
+ deciding to descend into a subdirectory but they did not match the
+ individual paths correctly. This caused pathspecs "abc/d ab" to match
+ "abc/0" ("abc/d" made them decide to descend into the directory "abc/",
+ and then "ab" incorrectly matched "abc/0" when it shouldn't).
+ This fix was first merged to 1.6.2.3.
+
+* import-zips script (in contrib) did not compute the common directory
+ prefix correctly.
+ This fix was first merged to 1.6.2.2.
+
+* "git init" segfaulted when given an overlong template location via
+ the --template= option.
+ This fix was first merged to 1.6.2.4.
+
+* "git repack" did not error out when necessary object was missing in the
+ repository.
+
+* git-repack (invoked from git-gc) did not work as nicely as it should in
+ a repository that borrows objects from neighbours via alternates
+ mechanism especially when some packs are marked with the ".keep" flag
+ to prevent them from being repacked.
+ This fix was first merged to 1.6.2.3.
+
+Also includes minor documentation fixes and updates.
diff --git a/RelNotes/1.6.1.adoc b/RelNotes/1.6.1.adoc
new file mode 100644
index 0000000..7b152a6
--- /dev/null
+++ b/RelNotes/1.6.1.adoc
@@ -0,0 +1,280 @@
+GIT v1.6.1 Release Notes
+========================
+
+Updates since v1.6.0
+--------------------
+
+When some commands (e.g. "git log", "git diff") spawn pager internally, we
+used to make the pager the parent process of the git command that produces
+output. This meant that the exit status of the whole thing comes from the
+pager, not the underlying git command. We swapped the order of the
+processes around and you will see the exit code from the command from now
+on.
+
+(subsystems)
+
+* gitk can call out to git-gui to view "git blame" output; git-gui in turn
+ can run gitk from its blame view.
+
+* Various git-gui updates including updated translations.
+
+* Various gitweb updates from repo.or.cz installation.
+
+* Updates to emacs bindings.
+
+(portability)
+
+* A few test scripts used nonportable "grep" that did not work well on
+ some platforms, e.g. Solaris.
+
+* Sample pre-auto-gc script has OS X support.
+
+* Makefile has support for (ancient) FreeBSD 4.9.
+
+(performance)
+
+* Many operations that are lstat(3) heavy can be told to pre-execute
+ necessary lstat(3) in parallel before their main operations, which
+ potentially gives much improved performance for cold-cache cases or in
+ environments with weak metadata caching (e.g. NFS).
+
+* The underlying diff machinery to produce textual output has been
+ optimized, which would result in faster "git blame" processing.
+
+* Most of the test scripts (but not the ones that try to run servers)
+ can be run in parallel.
+
+* Bash completion of refnames in a repository with massive number of
+ refs has been optimized.
+
+* Cygwin port uses native stat/lstat implementations when applicable,
+ which leads to improved performance.
+
+* "git push" pays attention to alternate repositories to avoid sending
+ unnecessary objects.
+
+* "git svn" can rebuild an out-of-date rev_map file.
+
+(usability, bells and whistles)
+
+* When you mistype a command name, git helpfully suggests what it guesses
+ you might have meant to say. help.autocorrect configuration can be set
+ to a non-zero value to accept the suggestion when git can uniquely
+ guess.
+
+* The packfile machinery hopefully is more robust when dealing with
+ corrupt packs if redundant objects involved in the corruption are
+ available elsewhere.
+
+* "git add -N path..." adds the named paths as an empty blob, so that
+ subsequent "git diff" will show a diff as if they are creation events.
+
+* "git add" gained a built-in synonym for people who want to say "stage
+ changes" instead of "add contents to the staging area" which amounts
+ to the same thing.
+
+* "git apply" learned --include=paths option, similar to the existing
+ --exclude=paths option.
+
+* "git bisect" is careful about a user mistake and suggests testing of
+ merge base first when good is not a strict ancestor of bad.
+
+* "git bisect skip" can take a range of commits.
+
+* "git blame" re-encodes the commit metainfo to UTF-8 from i18n.commitEncoding
+ by default.
+
+* "git check-attr --stdin" can check attributes for multiple paths.
+
+* "git checkout --track origin/hack" used to be a syntax error. It now
+ DWIMs to create a corresponding local branch "hack", i.e. acts as if you
+ said "git checkout --track -b hack origin/hack".
+
+* "git checkout --ours/--theirs" can be used to check out one side of a
+ conflicting merge during conflict resolution.
+
+* "git checkout -m" can be used to recreate the initial conflicted state
+ during conflict resolution.
+
+* "git cherry-pick" can also utilize rerere for conflict resolution.
+
+* "git clone" learned to be verbose with -v
+
+* "git commit --author=$name" can look up author name from existing
+ commits.
+
+* output from "git commit" has been reworded in a more concise and yet
+ more informative way.
+
+* "git count-objects" reports the on-disk footprint for packfiles and
+ their corresponding idx files.
+
+* "git daemon" learned --max-connections=<count> option.
+
+* "git daemon" exports REMOTE_ADDR to record client address, so that
+ spawned programs can act differently on it.
+
+* "git describe --tags" favours closer lightweight tags than farther
+ annotated tags now.
+
+* "git diff" learned to mimic --suppress-blank-empty from GNU diff via a
+ configuration option.
+
+* "git diff" learned to put more sensible hunk headers for Python,
+ HTML and ObjC contents.
+
+* "git diff" learned to vary the a/ vs b/ prefix depending on what are
+ being compared, controlled by diff.mnemonicprefix configuration.
+
+* "git diff" learned --dirstat-by-file to count changed files, not number
+ of lines, when summarizing the global picture.
+
+* "git diff" learned "textconv" filters --- a binary or hard-to-read
+ contents can be munged into human readable form and the difference
+ between the results of the conversion can be viewed (obviously this
+ cannot produce a patch that can be applied, so this is disabled in
+ format-patch among other things).
+
+* "--cached" option to "git diff has an easier to remember synonym "--staged",
+ to ask "what is the difference between the given commit and the
+ contents staged in the index?"
+
+* "git for-each-ref" learned "refname:short" token that gives an
+ unambiguously abbreviated refname.
+
+* Auto-numbering of the subject lines is the default for "git
+ format-patch" now.
+
+* "git grep" learned to accept -z similar to GNU grep.
+
+* "git help" learned to use GIT_MAN_VIEWER environment variable before
+ using "man" program.
+
+* "git imap-send" can optionally talk SSL.
+
+* "git index-pack" is more careful against disk corruption while
+ completing a thin pack.
+
+* "git log --check" and "git log --exit-code" passes their underlying diff
+ status with their exit status code.
+
+* "git log" learned --simplify-merges, a milder variant of --full-history;
+ "gitk --simplify-merges" is easier to view than with --full-history.
+
+* "git log" learned "--source" to show what ref each commit was reached
+ from.
+
+* "git log" also learned "--simplify-by-decoration" to show the
+ birds-eye-view of the topology of the history.
+
+* "git log --pretty=format:" learned "%d" format element that inserts
+ names of tags that point at the commit.
+
+* "git merge --squash" and "git merge --no-ff" into an unborn branch are
+ noticed as user errors.
+
+* "git merge -s $strategy" can use a custom built strategy if you have a
+ command "git-merge-$strategy" on your $PATH.
+
+* "git pull" (and "git fetch") can be told to operate "-v"erbosely or
+ "-q"uietly.
+
+* "git push" can be told to reject deletion of refs with receive.denyDeletes
+ configuration.
+
+* "git rebase" honours pre-rebase hook; use --no-verify to bypass it.
+
+* "git rebase -p" uses interactive rebase machinery now to preserve the merges.
+
+* "git reflog expire branch" can be used in place of "git reflog expire
+ refs/heads/branch".
+
+* "git remote show $remote" lists remote branches one-per-line now.
+
+* "git send-email" can be given revision range instead of files and
+ maildirs on the command line, and automatically runs format-patch to
+ generate patches for the given revision range.
+
+* "git submodule foreach" subcommand allows you to iterate over checked
+ out submodules.
+
+* "git submodule sync" subcommands allows you to update the origin URL
+ recorded in submodule directories from the toplevel .gitmodules file.
+
+* "git svn branch" can create new branches on the other end.
+
+* "gitweb" can use more saner PATH_INFO based URL.
+
+(internal)
+
+* "git hash-object" learned to lie about the path being hashed, so that
+ correct gitattributes processing can be done while hashing contents
+ stored in a temporary file.
+
+* various callers of git-merge-recursive avoid forking it as an external
+ process.
+
+* Git class defined in "Git.pm" can be subclasses a bit more easily.
+
+* We used to link GNU regex library as a compatibility layer for some
+ platforms, but it turns out it is not necessary on most of them.
+
+* Some path handling routines used fixed number of buffers used alternately
+ but depending on the call depth, this arrangement led to hard to track
+ bugs. This issue is being addressed.
+
+
+Fixes since v1.6.0
+------------------
+
+All of the fixes in v1.6.0.X maintenance series are included in this
+release, unless otherwise noted.
+
+* Porcelains implemented as shell scripts were utterly confused when you
+ entered to a subdirectory of a work tree from sideways, following a
+ symbolic link (this may need to be backported to older releases later).
+
+* Tracking symbolic links would work better on filesystems whose lstat()
+ returns incorrect st_size value for them.
+
+* "git add" and "git update-index" incorrectly allowed adding S/F when S
+ is a tracked symlink that points at a directory D that has a path F in
+ it (we still need to fix a similar nonsense when S is a submodule and F
+ is a path in it).
+
+* "git am" after stopping at a broken patch lost --whitespace, -C, -p and
+ --3way options given from the command line initially.
+
+* "git diff --stdin" used to take two trees on a line and compared them,
+ but we dropped support for such a use case long time ago. This has
+ been resurrected.
+
+* "git filter-branch" failed to rewrite a tag name with slashes in it.
+
+* "git http-push" did not understand URI scheme other than opaquelocktoken
+ when acquiring a lock from the server (this may need to be backported to
+ older releases later).
+
+* After "git rebase -p" stopped with conflicts while replaying a merge,
+ "git rebase --continue" did not work (may need to be backported to older
+ releases).
+
+* "git revert" records relative to which parent a revert was made when
+ reverting a merge. Together with new documentation that explains issues
+ around reverting a merge and merging from the updated branch later, this
+ hopefully will reduce user confusion (this may need to be backported to
+ older releases later).
+
+* "git rm --cached" used to allow an empty blob that was added earlier to
+ be removed without --force, even when the file in the work tree has
+ since been modified.
+
+* "git push --tags --all $there" failed with generic usage message without
+ telling saying these two options are incompatible.
+
+* "git log --author/--committer" match used to potentially match the
+ timestamp part, exposing internal implementation detail. Also these did
+ not work with --fixed-strings match at all.
+
+* "gitweb" did not mark non-ASCII characters imported from external HTML fragments
+ correctly.
diff --git a/RelNotes/1.6.2.1.adoc b/RelNotes/1.6.2.1.adoc
new file mode 100644
index 0000000..dfa3641
--- /dev/null
+++ b/RelNotes/1.6.2.1.adoc
@@ -0,0 +1,19 @@
+GIT v1.6.2.1 Release Notes
+==========================
+
+Fixes since v1.6.2
+------------------
+
+* .gitignore learned to handle backslash as a quoting mechanism for
+ comment introduction character "#".
+
+* timestamp output in --date=relative mode used to display timestamps that
+ are long time ago in the default mode; it now uses "N years M months
+ ago", and "N years ago".
+
+* git-add -i/-p now works with non-ASCII pathnames.
+
+* "git hash-object -w" did not read from the configuration file from the
+ correct .git directory.
+
+* git-send-email learned to correctly handle multiple Cc: addresses.
diff --git a/RelNotes/1.6.2.2.adoc b/RelNotes/1.6.2.2.adoc
new file mode 100644
index 0000000..fafa998
--- /dev/null
+++ b/RelNotes/1.6.2.2.adoc
@@ -0,0 +1,45 @@
+GIT v1.6.2.2 Release Notes
+==========================
+
+Fixes since v1.6.2.1
+--------------------
+
+* A longstanding confusing description of what --pickaxe option of
+ git-diff does has been clarified in the documentation.
+
+* "git-blame -S" did not quite work near the commits that were given
+ on the command line correctly.
+
+* "git diff --pickaxe-regexp" did not count overlapping matches
+ correctly.
+
+* "git diff" did not feed files in work-tree representation to external
+ diff and textconv.
+
+* "git-fetch" in a repository that was not cloned from anywhere said
+ it cannot find 'origin', which was hard to understand for new people.
+
+* "git-format-patch --numbered-files --stdout" did not have to die of
+ incompatible options; it now simply ignores --numbered-files as no files
+ are produced anyway.
+
+* "git-ls-files --deleted" did not work well with GIT_DIR&GIT_WORK_TREE.
+
+* "git-read-tree A B C..." without -m option has been broken for a long
+ time.
+
+* git-send-email ignored --in-reply-to when --no-thread was given.
+
+* 'git-submodule add' did not tolerate extra slashes and ./ in the path it
+ accepted from the command line; it now is more lenient.
+
+* git-svn misbehaved when the project contained a path that began with
+ two dashes.
+
+* import-zips script (in contrib) did not compute the common directory
+ prefix correctly.
+
+* miscompilation of negated enum constants by old gcc (2.9) affected the
+ codepaths to spawn subprocesses.
+
+Many small documentation updates are included as well.
diff --git a/RelNotes/1.6.2.3.adoc b/RelNotes/1.6.2.3.adoc
new file mode 100644
index 0000000..4d3c1ac
--- /dev/null
+++ b/RelNotes/1.6.2.3.adoc
@@ -0,0 +1,22 @@
+GIT v1.6.2.3 Release Notes
+==========================
+
+Fixes since v1.6.2.2
+--------------------
+
+* Setting an octal mode value to core.sharedrepository configuration to
+ restrict access to the repository to group members did not work as
+ advertised.
+
+* A fairly large and trivial memory leak while rev-list shows list of
+ reachable objects has been identified and plugged.
+
+* "git-commit --interactive" did not abort when underlying "git-add -i"
+ signaled a failure.
+
+* git-repack (invoked from git-gc) did not work as nicely as it should in
+ a repository that borrows objects from neighbours via alternates
+ mechanism especially when some packs are marked with the ".keep" flag
+ to prevent them from being repacked.
+
+Many small documentation updates are included as well.
diff --git a/RelNotes/1.6.2.4.adoc b/RelNotes/1.6.2.4.adoc
new file mode 100644
index 0000000..f4bf1d0
--- /dev/null
+++ b/RelNotes/1.6.2.4.adoc
@@ -0,0 +1,39 @@
+GIT v1.6.2.4 Release Notes
+==========================
+
+Fixes since v1.6.2.3
+--------------------
+
+* The configuration parser had a buffer overflow while parsing an overlong
+ value.
+
+* pruning reflog entries that are unreachable from the tip of the ref
+ during "git reflog prune" (hence "git gc") was very inefficient.
+
+* "git-add -p" lacked a way to say "q"uit to refuse staging any hunks for
+ the remaining paths. You had to say "d" and then ^C.
+
+* "git-checkout <tree-ish> <submodule>" did not update the index entry at
+ the named path; it now does.
+
+* "git-fast-export" choked when seeing a tag that does not point at commit.
+
+* "git init" segfaulted when given an overlong template location via
+ the --template= option.
+
+* "git-ls-tree" and "git-diff-tree" used a pathspec correctly when
+ deciding to descend into a subdirectory but they did not match the
+ individual paths correctly. This caused pathspecs "abc/d ab" to match
+ "abc/0" ("abc/d" made them decide to descend into the directory "abc/",
+ and then "ab" incorrectly matched "abc/0" when it shouldn't).
+
+* "git-merge-recursive" was broken when a submodule entry was involved in
+ a criss-cross merge situation.
+
+Many small documentation updates are included as well.
+
+---
+exec >/var/tmp/1
+echo O=$(git describe maint)
+O=v1.6.2.3-38-g318b847
+git shortlog --no-merges $O..maint
diff --git a/RelNotes/1.6.2.5.adoc b/RelNotes/1.6.2.5.adoc
new file mode 100644
index 0000000..b23f9e9
--- /dev/null
+++ b/RelNotes/1.6.2.5.adoc
@@ -0,0 +1,21 @@
+GIT v1.6.2.5 Release Notes
+==========================
+
+Fixes since v1.6.2.4
+--------------------
+
+* "git apply" mishandled if you fed a git generated patch that renames
+ file A to B and file B to A at the same time.
+
+* "git diff -c -p" (and "diff --cc") did not expect to see submodule
+ differences and instead refused to work.
+
+* "git grep -e '('" segfaulted, instead of diagnosing a mismatched
+ parentheses error.
+
+* "git fetch" generated packs with offset-delta encoding when both ends of
+ the connection are capable of producing one; this cannot be read by
+ ancient git and the user should be able to disable this by setting
+ repack.usedeltabaseoffset configuration to false.
+
+
diff --git a/RelNotes/1.6.2.adoc b/RelNotes/1.6.2.adoc
new file mode 100644
index 0000000..166d73c
--- /dev/null
+++ b/RelNotes/1.6.2.adoc
@@ -0,0 +1,164 @@
+GIT v1.6.2 Release Notes
+========================
+
+With the next major release, "git push" into a branch that is
+currently checked out will be refused by default. You can choose
+what should happen upon such a push by setting the configuration
+variable receive.denyCurrentBranch in the receiving repository.
+
+To ease the transition plan, the receiving repository of such a
+push running this release will issue a big warning when the
+configuration variable is missing. Please refer to:
+
+ https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/GitFaq.html#non-bare
+ https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/
+
+for more details on the reason why this change is needed and the
+transition plan.
+
+For a similar reason, "git push $there :$killed" to delete the branch
+$killed in a remote repository $there, if $killed branch is the current
+branch pointed at by its HEAD, gets a large warning. You can choose what
+should happen upon such a push by setting the configuration variable
+receive.denyDeleteCurrent in the receiving repository.
+
+
+Updates since v1.6.1
+--------------------
+
+(subsystems)
+
+* git-svn updates.
+
+* gitweb updates, including a new patch view and RSS/Atom feed
+ improvements.
+
+* (contrib/emacs) git.el now has commands for checking out a branch,
+ creating a branch, cherry-picking and reverting commits; vc-git.el
+ is not shipped with git anymore (it is part of official Emacs).
+
+(performance)
+
+* pack-objects autodetects the number of CPUs available and uses threaded
+ version.
+
+(usability, bells and whistles)
+
+* automatic typo correction works on aliases as well
+
+* @{-1} is a way to refer to the last branch you were on. This is
+ accepted not only where an object name is expected, but anywhere
+ a branch name is expected and acts as if you typed the branch name.
+ E.g. "git branch --track mybranch @{-1}", "git merge @{-1}", and
+ "git rev-parse --symbolic-full-name @{-1}" would work as expected.
+
+* When refs/remotes/origin/HEAD points at a remote tracking branch that
+ has been pruned away, many git operations issued warning when they
+ internally enumerated the refs. We now warn only when you say "origin"
+ to refer to that pruned branch.
+
+* The location of .mailmap file can be configured, and its file format was
+ enhanced to allow mapping an incorrect e-mail field as well.
+
+* "git add -p" learned 'g'oto action to jump directly to a hunk.
+
+* "git add -p" learned to find a hunk with given text with '/'.
+
+* "git add -p" optionally can be told to work with just the command letter
+ without Enter.
+
+* when "git am" stops upon a patch that does not apply, it shows the
+ title of the offending patch.
+
+* "git am --directory=<dir>" and "git am --reject" passes these options
+ to underlying "git apply".
+
+* "git am" learned --ignore-date option.
+
+* "git blame" aligns author names better when they are spelled in
+ non US-ASCII encoding.
+
+* "git clone" now makes its best effort when cloning from an empty
+ repository to set up configuration variables to refer to the remote
+ repository.
+
+* "git checkout -" is a shorthand for "git checkout @{-1}".
+
+* "git cherry" defaults to whatever the current branch is tracking (if
+ exists) when the <upstream> argument is not given.
+
+* "git cvsserver" can be told not to add extra "via git-CVS emulator" to
+ the commit log message it serves via gitcvs.commitmsgannotation
+ configuration.
+
+* "git cvsserver" learned to handle 'noop' command some CVS clients seem
+ to expect to work.
+
+* "git diff" learned a new option --inter-hunk-context to coalesce close
+ hunks together and show context between them.
+
+* The definition of what constitutes a word for "git diff --color-words"
+ can be customized via gitattributes, command line or a configuration.
+
+* "git diff" learned --patience to run "patience diff" algorithm.
+
+* "git filter-branch" learned --prune-empty option that discards commits
+ that do not change the contents.
+
+* "git fsck" now checks loose objects in alternate object stores, instead
+ of misreporting them as missing.
+
+* "git gc --prune" was resurrected to allow "git gc --no-prune" and
+ giving non-default expiration period e.g. "git gc --prune=now".
+
+* "git grep -w" and "git grep" for fixed strings have been optimized.
+
+* "git mergetool" learned -y(--no-prompt) option to disable prompting.
+
+* "git rebase -i" can transplant a history down to root to elsewhere
+ with --root option.
+
+* "git reset --merge" is a new mode that works similar to the way
+ "git checkout" switches branches, taking the local changes while
+ switching to another commit.
+
+* "git submodule update" learned --no-fetch option.
+
+* "git tag" learned --contains that works the same way as the same option
+ from "git branch".
+
+
+Fixes since v1.6.1
+------------------
+
+All of the fixes in v1.6.1.X maintenance series are included in this
+release, unless otherwise noted.
+
+Here are fixes that this release has, but have not been backported to
+v1.6.1.X series.
+
+* "git-add sub/file" when sub is a submodule incorrectly added the path to
+ the superproject.
+
+* "git bundle" did not exclude annotated tags even when a range given
+ from the command line wanted to.
+
+* "git filter-branch" unnecessarily refused to work when you had
+ checked out a different commit from what is recorded in the superproject
+ index in a submodule.
+
+* "git filter-branch" incorrectly tried to update a nonexistent work tree
+ at the end when it is run in a bare repository.
+
+* "git gc" did not work if your repository was created with an ancient git
+ and never had any pack files in it before.
+
+* "git mergetool" used to ignore autocrlf and other attributes
+ based content rewriting.
+
+* branch switching and merges had a silly bug that did not validate
+ the correct directory when making sure an existing subdirectory is
+ clean.
+
+* "git -p cmd" when cmd is not a built-in one left the display in funny state
+ when killed in the middle.
diff --git a/RelNotes/1.6.3.1.adoc b/RelNotes/1.6.3.1.adoc
new file mode 100644
index 0000000..2400b72
--- /dev/null
+++ b/RelNotes/1.6.3.1.adoc
@@ -0,0 +1,10 @@
+GIT v1.6.3.1 Release Notes
+==========================
+
+Fixes since v1.6.3
+------------------
+
+* "git checkout -b new-branch" with a staged change in the index
+ incorrectly primed the in-index cache-tree, resulting a wrong tree
+ object to be written out of the index. This is a grave regression
+ since the last 1.6.2.X maintenance release.
diff --git a/RelNotes/1.6.3.2.adoc b/RelNotes/1.6.3.2.adoc
new file mode 100644
index 0000000..b2f3f02
--- /dev/null
+++ b/RelNotes/1.6.3.2.adoc
@@ -0,0 +1,61 @@
+GIT v1.6.3.2 Release Notes
+==========================
+
+Fixes since v1.6.3.1
+--------------------
+
+ * A few codepaths picked up the first few bytes from an sha1[] by
+ casting the (char *) pointer to (int *); GCC 4.4 did not like this,
+ and aborted compilation.
+
+ * Some unlink(2) failures went undiagnosed.
+
+ * The "recursive" merge strategy misbehaved when faced rename/delete
+ conflicts while coming up with an intermediate merge base.
+
+ * The low-level merge algorithm did not handle a degenerate case of
+ merging a file with itself using itself as the common ancestor
+ gracefully. It should produce the file itself, but instead
+ produced an empty result.
+
+ * GIT_TRACE mechanism segfaulted when tracing a shell-quoted aliases.
+
+ * OpenBSD also uses st_ctimspec in "struct stat", instead of "st_ctim".
+
+ * With NO_CROSS_DIRECTORY_HARDLINKS, "make install" can be told not to
+ create hardlinks between $(gitexecdir)/git-$builtin_commands and
+ $(bindir)/git.
+
+ * command completion code in bash did not reliably detect that we are
+ in a bare repository.
+
+ * "git add ." in an empty directory complained that pathspec "." did not
+ match anything, which may be technically correct, but not useful. We
+ silently make it a no-op now.
+
+ * "git add -p" (and "patch" action in "git add -i") was broken when
+ the first hunk that adds a line at the top was split into two and
+ both halves are marked to be used.
+
+ * "git blame path" misbehaved at the commit where path became file
+ from a directory with some files in it.
+
+ * "git for-each-ref" had a segfaulting bug when dealing with a tag object
+ created by an ancient git.
+
+ * "git format-patch -k" still added patch numbers if format.numbered
+ configuration was set.
+
+ * "git grep --color ''" did not terminate. The command also had
+ subtle bugs with its -w option.
+
+ * http-push had a small use-after-free bug.
+
+ * "git push" was converting OFS_DELTA pack representation into less
+ efficient REF_DELTA representation unconditionally upon transfer,
+ making the transferred data unnecessarily larger.
+
+ * "git remote show origin" segfaulted when origin was still empty.
+
+Many other general usability updates around help text, diagnostic messages
+and documentation are included as well.
diff --git a/RelNotes/1.6.3.3.adoc b/RelNotes/1.6.3.3.adoc
new file mode 100644
index 0000000..1c28398
--- /dev/null
+++ b/RelNotes/1.6.3.3.adoc
@@ -0,0 +1,38 @@
+GIT v1.6.3.3 Release Notes
+==========================
+
+Fixes since v1.6.3.2
+--------------------
+
+ * "git archive" running on Cygwin can get stuck in an infinite loop.
+
+ * "git daemon" did not correctly parse the initial line that carries
+ virtual host request information.
+
+ * "git diff --textconv" leaked memory badly when the textconv filter
+ errored out.
+
+ * The built-in regular expressions to pick function names to put on
+ hunk header lines for java and objc were very inefficiently written.
+
+ * in certain error situations git-fetch (and git-clone) on Windows didn't
+ detect connection abort and ended up waiting indefinitely.
+
+ * import-tars script (in contrib) did not import symbolic links correctly.
+
+ * http.c used CURLOPT_SSLKEY even on libcURL version 7.9.2, even though
+ it was only available starting 7.9.3.
+
+ * low-level filelevel merge driver used return value from strdup()
+ without checking if we ran out of memory.
+
+ * "git rebase -i" left stray closing parenthesis in its reflog message.
+
+ * "git remote show" did not show all the URLs associated with the named
+ remote, even though "git remote -v" did. Made them consistent by
+ making the former show all URLs.
+
+ * "whitespace" attribute that is set was meant to detect all errors known
+ to git, but it told git to ignore trailing carriage-returns.
+
+Includes other documentation fixes.
diff --git a/RelNotes/1.6.3.4.adoc b/RelNotes/1.6.3.4.adoc
new file mode 100644
index 0000000..cad461b
--- /dev/null
+++ b/RelNotes/1.6.3.4.adoc
@@ -0,0 +1,36 @@
+GIT v1.6.3.4 Release Notes
+==========================
+
+Fixes since v1.6.3.3
+--------------------
+
+ * "git add --no-ignore-errors" did not override configured
+ add.ignore-errors configuration.
+
+ * "git apply --whitespace=fix" did not fix trailing whitespace on an
+ incomplete line.
+
+ * "git branch" opened too many commit objects unnecessarily.
+
+ * "git checkout -f $commit" with a path that is a file (or a symlink) in
+ the work tree to a commit that has a directory at the path issued an
+ unnecessary error message.
+
+ * "git diff -c/--cc" was very inefficient in coalescing the removed lines
+ shared between parents.
+
+ * "git diff -c/--cc" showed removed lines at the beginning of a file
+ incorrectly.
+
+ * "git remote show nickname" did not honor configured
+ remote.nickname.uploadpack when inspecting the branches at the remote.
+
+ * "git request-pull" when talking to the terminal for a preview
+ showed some of the output in the pager.
+
+ * "git request-pull start nickname [end]" did not honor configured
+ remote.nickname.uploadpack when it ran git-ls-remote against the remote
+ repository to learn the current tip of branches.
+
+Includes other documentation updates and minor fixes.
+
diff --git a/RelNotes/1.6.3.adoc b/RelNotes/1.6.3.adoc
new file mode 100644
index 0000000..bbf177f
--- /dev/null
+++ b/RelNotes/1.6.3.adoc
@@ -0,0 +1,182 @@
+GIT v1.6.3 Release Notes
+========================
+
+With the next major release, "git push" into a branch that is
+currently checked out will be refused by default. You can choose
+what should happen upon such a push by setting the configuration
+variable receive.denyCurrentBranch in the receiving repository.
+
+To ease the transition plan, the receiving repository of such a
+push running this release will issue a big warning when the
+configuration variable is missing. Please refer to:
+
+ https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/GitFaq.html#non-bare
+ https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/
+
+for more details on the reason why this change is needed and the
+transition plan.
+
+For a similar reason, "git push $there :$killed" to delete the branch
+$killed in a remote repository $there, if $killed branch is the current
+branch pointed at by its HEAD, gets a large warning. You can choose what
+should happen upon such a push by setting the configuration variable
+receive.denyDeleteCurrent in the receiving repository.
+
+When the user does not tell "git push" what to push, it has always
+pushed matching refs. For some people it is unexpected, and a new
+configuration variable push.default has been introduced to allow
+changing a different default behaviour. To advertise the new feature,
+a big warning is issued if this is not configured and a git push without
+arguments is attempted.
+
+
+Updates since v1.6.2
+--------------------
+
+(subsystems)
+
+* various git-svn updates.
+
+* git-gui updates, including an update to Russian translation, and a
+ fix to an infinite loop when showing an empty diff.
+
+* gitk updates, including an update to Russian translation and improved Windows
+ support.
+
+(performance)
+
+* many uses of lstat(2) in the codepath for "git checkout" have been
+ optimized out.
+
+(usability, bells and whistles)
+
+* Boolean configuration variable yes/no can be written as on/off.
+
+* rsync:/path/to/repo can be used to run git over rsync for local
+ repositories. It may not be useful in practice; meant primarily for
+ testing.
+
+* http transport learned to prompt and use password when fetching from or
+ pushing to http://user@host.xz/ URL.
+
+* (msysgit) progress output that is sent over the sideband protocol can
+ be handled appropriately in Windows console.
+
+* "--pretty=<style>" option to the log family of commands can now be
+ spelled as "--format=<style>". In addition, --format=%formatstring
+ is a short-hand for --pretty=tformat:%formatstring.
+
+* "--oneline" is a synonym for "--pretty=oneline --abbrev-commit".
+
+* "--graph" to the "git log" family can draw the commit ancestry graph
+ in colors.
+
+* If you realize that you botched the patch when you are editing hunks
+ with the 'edit' action in git-add -i/-p, you can abort the editor to
+ tell git not to apply it.
+
+* @{-1} is a new way to refer to the last branch you were on introduced in
+ 1.6.2, but the initial implementation did not teach this to a few
+ commands. Now the syntax works with "branch -m @{-1} newname".
+
+* git-archive learned --output=<file> option.
+
+* git-archive takes attributes from the tree being archived; strictly
+ speaking, this is an incompatible behaviour change, but is a good one.
+ Use --worktree-attributes option to allow it to read attributes from
+ the work tree as before (deprecated git-tar tree command always reads
+ attributes from the work tree).
+
+* git-bisect shows not just the number of remaining commits whose goodness
+ is unknown, but also shows the estimated number of remaining rounds.
+
+* You can give --date=<format> option to git-blame.
+
+* "git-branch -r" shows HEAD symref that points at a remote branch in
+ interest of each tracked remote repository.
+
+* "git-branch -v -v" is a new way to get list of names for branches and the
+ "upstream" branch for them.
+
+* git-config learned -e option to open an editor to edit the config file
+ directly.
+
+* git-clone runs post-checkout hook when run without --no-checkout.
+
+* git-difftool is now part of the officially supported command, primarily
+ maintained by David Aguilar.
+
+* git-for-each-ref learned a new "upstream" token.
+
+* git-format-patch can be told to use attachment with a new configuration,
+ format.attach.
+
+* git-format-patch can be told to produce deep or shallow message threads.
+
+* git-format-patch can be told to always add sign-off with a configuration
+ variable.
+
+* git-format-patch learned format.headers configuration to add extra
+ header fields to the output. This behaviour is similar to the existing
+ --add-header=<header> option of the command.
+
+* git-format-patch gives human readable names to the attached files, when
+ told to send patches as attachments.
+
+* git-grep learned to highlight the found substrings in color.
+
+* git-imap-send learned to work around Thunderbird's inability to easily
+ disable format=flowed with a new configuration, imap.preformattedHTML.
+
+* git-rebase can be told to rebase the series even if your branch is a
+ descendant of the commit you are rebasing onto with --force-rebase
+ option.
+
+* git-rebase can be told to report diffstat with the --stat option.
+
+* Output from git-remote command has been vastly improved.
+
+* "git remote update --prune $remote" updates from the named remote and
+ then prunes stale tracking branches.
+
+* git-send-email learned --confirm option to review the Cc: list before
+ sending the messages out.
+
+(developers)
+
+* Test scripts can be run under valgrind.
+
+* Test scripts can be run with installed git.
+
+* Makefile learned 'coverage' option to run the test suites with
+ coverage tracking enabled.
+
+* Building the manpages with docbook-xsl between 1.69.1 and 1.71.1 now
+ requires setting DOCBOOK_SUPPRESS_SP to work around a docbook-xsl bug.
+ This workaround used to be enabled by default, but causes problems
+ with newer versions of docbook-xsl. In addition, there are a few more
+ knobs you can tweak to work around issues with various versions of the
+ docbook-xsl package. See comments in Documentation/Makefile for details.
+
+* Support for building and testing a subset of git on a system without a
+ working perl has been improved.
+
+
+Fixes since v1.6.2
+------------------
+
+All of the fixes in v1.6.2.X maintenance series are included in this
+release, unless otherwise noted.
+
+Here are fixes that this release has, but have not been backported to
+v1.6.2.X series.
+
+* "git-apply" rejected a patch that swaps two files (i.e. renames A to B
+ and B to A at the same time). May need to be backported by cherry
+ picking d8c81df and then 7fac0ee).
+
+* The initial checkout did not read the attributes from the .gitattribute
+ file that is being checked out.
+
+* git-gc spent excessive amount of time to decide if an object appears
+ in a locally existing pack (if needed, backport by merging 69e020a).
diff --git a/RelNotes/1.6.4.1.adoc b/RelNotes/1.6.4.1.adoc
new file mode 100644
index 0000000..e439e45
--- /dev/null
+++ b/RelNotes/1.6.4.1.adoc
@@ -0,0 +1,46 @@
+GIT v1.6.4.1 Release Notes
+==========================
+
+Fixes since v1.6.4
+------------------
+
+ * An unquoted value in the configuration file, when it contains more than
+ one whitespaces in a row, got them replaced with a single space.
+
+ * "git am" used to accept a single piece of e-mail per file (not a mbox)
+ as its input, but multiple input format support in v1.6.4 broke it.
+ Apparently many people have been depending on this feature.
+
+ * The short help text for "git filter-branch" command was a single long
+ line, wrapped by terminals, and was hard to read.
+
+ * The "recursive" strategy of "git merge" segfaulted when a merge has
+ more than one merge-bases, and merging of these merge-bases involves
+ a rename/rename or a rename/add conflict.
+
+ * "git pull --rebase" did not use the right fork point when the
+ repository has already fetched from the upstream that rewinds the
+ branch it is based on in an earlier fetch.
+
+ * Explain the concept of fast-forward more fully in "git push"
+ documentation, and hint to refer to it from an error message when the
+ command refuses an update to protect the user.
+
+ * The default value for pack.deltacachesize, used by "git repack", is now
+ 256M, instead of unbounded. Otherwise a repack of a moderately sized
+ repository would needlessly eat into swap.
+
+ * Document how "git repack" (hence "git gc") interacts with a repository
+ that borrows its objects from other repositories (e.g. ones created by
+ "git clone -s").
+
+ * "git show" on an annotated tag lacked a delimiting blank line between
+ the tag itself and the contents of the object it tags.
+
+ * "git verify-pack -v" erroneously reported number of objects with too
+ deep delta depths as "chain length 0" objects.
+
+ * Long names of authors and committers outside US-ASCII were sometimes
+ incorrectly shown in "gitweb".
+
+Other minor documentation updates are included.
diff --git a/RelNotes/1.6.4.2.adoc b/RelNotes/1.6.4.2.adoc
new file mode 100644
index 0000000..c11ec01
--- /dev/null
+++ b/RelNotes/1.6.4.2.adoc
@@ -0,0 +1,32 @@
+GIT v1.6.4.2 Release Notes
+==========================
+
+Fixes since v1.6.4.1
+--------------------
+
+* --date=relative output between 1 and 5 years ago rounded the number of
+ years when saying X years Y months ago, instead of rounding it down.
+
+* "git add -p" did not handle changes in executable bits correctly
+ (a regression around 1.6.3).
+
+* "git apply" did not honor GNU diff's convention to mark the creation/deletion
+ event with UNIX epoch timestamp on missing side.
+
+* "git checkout" incorrectly removed files in a directory pointed by a
+ symbolic link during a branch switch that replaces a directory with
+ a symbolic link.
+
+* "git clean -d -f" happily descended into a subdirectory that is managed by a
+ separate git repository. It now requires two -f options for safety.
+
+* "git fetch/push" over http transports had two rather grave bugs.
+
+* "git format-patch --cover-letter" did not prepare the cover letter file
+ for use with non-ASCII strings when there are the series contributors with
+ non-ASCII names.
+
+* "git pull origin branch" and "git fetch origin && git merge origin/branch"
+ left different merge messages in the resulting commit.
+
+Other minor documentation updates are included.
diff --git a/RelNotes/1.6.4.3.adoc b/RelNotes/1.6.4.3.adoc
new file mode 100644
index 0000000..5643e65
--- /dev/null
+++ b/RelNotes/1.6.4.3.adoc
@@ -0,0 +1,29 @@
+GIT v1.6.4.3 Release Notes
+==========================
+
+Fixes since v1.6.4.2
+--------------------
+
+* "git clone" from an empty repository gave unnecessary error message,
+ even though it did everything else correctly.
+
+* "git cvsserver" invoked git commands via "git-foo" style, which has long
+ been deprecated.
+
+* "git fetch" and "git clone" had an extra sanity check to verify the
+ presence of the corresponding *.pack file before downloading *.idx
+ file by issuing a HEAD request. Github server however sometimes
+ gave 500 (Internal server error) response to HEAD even if a GET
+ request for *.pack file to the same URL would have succeeded, and broke
+ clone over HTTP from some of their repositories. As a workaround, this
+ verification has been removed (as it is not absolutely necessary).
+
+* "git grep" did not like relative pathname to refer outside the current
+ directory when run from a subdirectory.
+
+* an error message from "git push" was formatted in a very ugly way.
+
+* "git svn" did not quote the subversion user name correctly when
+ running its author-prog helper program.
+
+Other minor documentation updates are included.
diff --git a/RelNotes/1.6.4.4.adoc b/RelNotes/1.6.4.4.adoc
new file mode 100644
index 0000000..0ead45f
--- /dev/null
+++ b/RelNotes/1.6.4.4.adoc
@@ -0,0 +1,26 @@
+GIT v1.6.4.4 Release Notes
+==========================
+
+Fixes since v1.6.4.4
+--------------------
+
+* The workaround for Github server that sometimes gave 500 (Internal server
+ error) response to HEAD requests in 1.6.4.3 introduced a regression that
+ caused re-fetching projects over http to segfault in certain cases due
+ to uninitialized pointer being freed.
+
+* "git pull" on an unborn branch used to consider anything in the work
+ tree and the index discardable.
+
+* "git diff -b/w" did not work well on the incomplete line at the end of
+ the file, due to an incorrect hashing of lines in the low-level xdiff
+ routines.
+
+* "git checkout-index --prefix=$somewhere" used to work when $somewhere is
+ a symbolic link to a directory elsewhere, but v1.6.4.2 broke it.
+
+* "git unpack-objects --strict", invoked when receive.fsckobjects
+ configuration is set in the receiving repository of "git push", did not
+ properly check the objects, especially the submodule links, it received.
+
+Other minor documentation updates are included.
diff --git a/RelNotes/1.6.4.5.adoc b/RelNotes/1.6.4.5.adoc
new file mode 100644
index 0000000..eb6307d
--- /dev/null
+++ b/RelNotes/1.6.4.5.adoc
@@ -0,0 +1,20 @@
+Git v1.6.4.5 Release Notes
+==========================
+
+Fixes since v1.6.4.4
+--------------------
+
+ * Simplified base85 implementation.
+
+ * An overlong line after ".gitdir: " in a git file caused out of bounds
+ access to an array on the stack.
+
+ * "git count-objects" did not handle packs larger than 4G.
+
+ * "git rev-parse --parseopt --stop-at-non-option" did not stop at non option
+ when --keep-dashdash was in effect.
+
+ * "gitweb" can sometimes be tricked into parrotting a filename argument
+ given in a request without properly quoting.
+
+Other minor fixes and documentation updates are included.
diff --git a/RelNotes/1.6.4.adoc b/RelNotes/1.6.4.adoc
new file mode 100644
index 0000000..0fccfb0
--- /dev/null
+++ b/RelNotes/1.6.4.adoc
@@ -0,0 +1,147 @@
+GIT v1.6.4 Release Notes
+========================
+
+With the next major release, "git push" into a branch that is
+currently checked out will be refused by default. You can choose
+what should happen upon such a push by setting the configuration
+variable receive.denyCurrentBranch in the receiving repository.
+
+To ease the transition plan, the receiving repository of such a
+push running this release will issue a big warning when the
+configuration variable is missing. Please refer to:
+
+ https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/GitFaq.html#non-bare
+ https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/
+
+for more details on the reason why this change is needed and the
+transition plan.
+
+For a similar reason, "git push $there :$killed" to delete the branch
+$killed in a remote repository $there, if $killed branch is the current
+branch pointed at by its HEAD, gets a large warning. You can choose what
+should happen upon such a push by setting the configuration variable
+receive.denyDeleteCurrent in the receiving repository.
+
+
+Updates since v1.6.3
+--------------------
+
+(subsystems)
+
+ * gitweb Perl style clean-up.
+
+ * git-svn updates, including a new --authors-prog option to map author
+ names by invoking an external program, 'git svn reset' to unwind
+ 'git svn fetch', support for more than one branches, documenting
+ of the useful --minimize-url feature, new "git svn gc" command, etc.
+
+(portability)
+
+ * We feed iconv with "UTF-8" instead of "utf8"; the former is
+ understood more widely. Similarly updated test scripts to use
+ encoding names more widely understood (e.g. use "ISO8859-1" instead
+ of "ISO-8859-1").
+
+ * Various portability fixes/workarounds for different vintages of
+ SunOS, IRIX, and Windows.
+
+ * Git-over-ssh transport on Windows supports PuTTY plink and TortoisePlink.
+
+(performance)
+
+ * Many repeated use of lstat() are optimized out in "checkout" codepath.
+
+ * git-status (and underlying git-diff-index --cached) are optimized
+ to take advantage of cache-tree information in the index.
+
+(usability, bells and whistles)
+
+ * "git add --edit" lets users edit the whole patch text to fine-tune what
+ is added to the index.
+
+ * "git am" accepts StGIT series file as its input.
+
+ * "git bisect skip" skips to a more randomly chosen place in the hope
+ to avoid testing a commit that is too close to a commit that is
+ already known to be untestable.
+
+ * "git cvsexportcommit" learned -k option to stop CVS keywords expansion
+
+ * "git fast-export" learned to handle history simplification more
+ gracefully.
+
+ * "git fast-export" learned an option --tag-of-filtered-object to handle
+ dangling tags resulting from history simplification more usefully.
+
+ * "git grep" learned -p option to show the location of the match using the
+ same context hunk marker "git diff" uses.
+
+ * https transport can optionally be told that the used client
+ certificate is password protected, in which case it asks the
+ password only once.
+
+ * "git imap-send" is IPv6 aware.
+
+ * "git log --graph" draws graphs more compactly by using horizontal lines
+ when able.
+
+ * "git log --decorate" shows shorter refnames by stripping well-known
+ refs/* prefix.
+
+ * "git push $name" honors remote.$name.pushurl if present before
+ using remote.$name.url. In other words, the URL used for fetching
+ and pushing can be different.
+
+ * "git send-email" understands quoted aliases in .mailrc files (might
+ have to be backported to 1.6.3.X).
+
+ * "git send-email" can fetch the sender address from the configuration
+ variable "sendmail.from" (and "sendmail.<identity>.from").
+
+ * "git show-branch" can color its output.
+
+ * "add" and "update" subcommands to "git submodule" learned --reference
+ option to use local clone with references.
+
+ * "git submodule update" learned --rebase option to update checked
+ out submodules by rebasing the local changes.
+
+ * "gitweb" can optionally use gravatar to adorn author/committer names.
+
+(developers)
+
+ * A major part of the "git bisect" wrapper has moved to C.
+
+ * Formatting with the new version of AsciiDoc 8.4.1 is now supported.
+
+Fixes since v1.6.3
+------------------
+
+All of the fixes in v1.6.3.X maintenance series are included in this
+release, unless otherwise noted.
+
+Here are fixes that this release has, but have not been backported to
+v1.6.3.X series.
+
+ * "git diff-tree -r -t" used to omit new or removed directories from
+ the output. df533f3 (diff-tree -r -t: include added/removed
+ directories in the output, 2009-06-13) may need to be cherry-picked
+ to backport this fix.
+
+ * The way Git.pm sets up a Repository object was not friendly to callers
+ that chdir around. It now internally records the repository location
+ as an absolute path when autodetected.
+
+ * Removing a section with "git config --remove-section", when its
+ section header has a variable definition on the same line, lost
+ that variable definition.
+
+ * "git rebase -p --onto" used to always leave side branches of a merge
+ intact, even when both branches are subject to rewriting.
+
+ * "git repack" used to faithfully follow grafts and considered true
+ parents recorded in the commit object unreachable from the commit.
+ After such a repacking, you cannot remove grafts without corrupting
+ the repository.
+
+ * "git send-email" did not detect erroneous loops in alias expansion.
diff --git a/RelNotes/1.6.5.1.adoc b/RelNotes/1.6.5.1.adoc
new file mode 100644
index 0000000..309ba18
--- /dev/null
+++ b/RelNotes/1.6.5.1.adoc
@@ -0,0 +1,20 @@
+GIT v1.6.5.1 Release Notes
+==========================
+
+Fixes since v1.6.5
+------------------
+
+ * An corrupt pack could make codepath to read objects into an
+ infinite loop.
+
+ * Download throughput display was always shown in KiB/s but on fast links
+ it is more appropriate to show it in MiB/s.
+
+ * "git grep -f filename" used uninitialized variable and segfaulted.
+
+ * "git clone -b branch" gave a wrong commit object name to post-checkout
+ hook.
+
+ * "git pull" over http did not work on msys.
+
+Other minor documentation updates are included.
diff --git a/RelNotes/1.6.5.2.adoc b/RelNotes/1.6.5.2.adoc
new file mode 100644
index 0000000..aa7ccce
--- /dev/null
+++ b/RelNotes/1.6.5.2.adoc
@@ -0,0 +1,19 @@
+GIT v1.6.5.2 Release Notes
+==========================
+
+Fixes since v1.6.5.1
+--------------------
+
+ * Installation of templates triggered a bug in busybox when using tar
+ implementation from it.
+
+ * "git add -i" incorrectly ignored paths that are already in the index
+ if they matched .gitignore patterns.
+
+ * "git describe --always" should have produced some output even there
+ were no tags in the repository, but it didn't.
+
+ * "git ls-files" when showing tracked files incorrectly paid attention
+ to the exclude patterns.
+
+Other minor documentation updates are included.
diff --git a/RelNotes/1.6.5.3.adoc b/RelNotes/1.6.5.3.adoc
new file mode 100644
index 0000000..b2fad1b
--- /dev/null
+++ b/RelNotes/1.6.5.3.adoc
@@ -0,0 +1,63 @@
+Git v1.6.5.3 Release Notes
+==========================
+
+Fixes since v1.6.5.2
+--------------------
+
+ * info/grafts file didn't ignore trailing CR at the end of lines.
+
+ * Packages generated on newer FC were unreadable by older versions of
+ RPM as the new default is to use stronger hash.
+
+ * output from "git blame" was unreadable when the file ended in an
+ incomplete line.
+
+ * "git add -i/-p" didn't handle deletion of empty files correctly.
+
+ * "git clone" takes up to two parameters, but did not complain when
+ given more arguments than necessary and silently ignored them.
+
+ * "git cvsimport" did not read files given as command line arguments
+ correctly when it is run from a subdirectory.
+
+ * "git diff --color-words -U0" didn't work correctly.
+
+ * The handling of blank lines at the end of file by "git diff/apply
+ --whitespace" was inconsistent with the other kinds of errors.
+ They are now colored, warned against, and fixed the same way as others.
+
+ * There was no way to allow blank lines at the end of file without
+ allowing extra blanks at the end of lines. You can use blank-at-eof
+ and blank-at-eol whitespace error class to specify them separately.
+ The old trailing-space error class is now a short-hand to set both.
+
+ * "-p" option to "git format-patch" was supposed to suppress diffstat
+ generation, but it was broken since 1.6.1.
+
+ * "git imap-send" did not compile cleanly with newer OpenSSL.
+
+ * "git help -a" outside of a git repository was broken.
+
+ * "git ls-files -i" was supposed to be inverse of "git ls-files" without -i
+ with respect to exclude patterns, but it was broken since 1.6.5.2.
+
+ * "git ls-remote" outside of a git repository over http was broken.
+
+ * "git rebase -i" gave bogus error message when the command word was
+ misspelled.
+
+ * "git receive-pack" that is run in response to "git push" did not run
+ garbage collection nor update-server-info, but in larger hosting sites,
+ these almost always need to be run. To help site administrators, the
+ command now runs "gc --auto" and "u-s-i" by setting receive.autogc
+ and receive.updateserverinfo configuration variables, respectively.
+
+ * Release notes spelled the package name with incorrect capitalization.
+
+ * "gitweb" did not escape non-ascii characters correctly in the URL.
+
+ * "gitweb" showed "patch" link even for merge commits.
+
+ * "gitweb" showed incorrect links for blob line numbers in pathinfo mode.
+
+Other minor documentation updates are included.
diff --git a/RelNotes/1.6.5.4.adoc b/RelNotes/1.6.5.4.adoc
new file mode 100644
index 0000000..344333d
--- /dev/null
+++ b/RelNotes/1.6.5.4.adoc
@@ -0,0 +1,32 @@
+Git v1.6.5.4 Release Notes
+==========================
+
+Fixes since v1.6.5.3
+--------------------
+
+ * "git help" (without argument) used to check if you are in a directory
+ under git control. There was no breakage in behaviour per-se, but this
+ was unnecessary.
+
+ * "git prune-packed" gave progress output even when its standard error is
+ not connected to a terminal; this caused cron jobs that run it to
+ produce cruft.
+
+ * "git pack-objects --all-progress" is an option to ask progress output
+ from write-object phase _if_ progress output were to be produced, and
+ shouldn't have forced the progress output.
+
+ * "git apply -p<n> --directory=<elsewhere>" did not work well for a
+ non-default value of n.
+
+ * "git merge foo HEAD" was misparsed as an old-style invocation of the
+ command and produced a confusing error message. As it does not specify
+ any other branch to merge, it shouldn't be mistaken as such. We will
+ remove the old style "git merge <message> HEAD <commit>..." syntax in
+ future versions, but not in this release,
+
+ * "git merge -m <message> <branch>..." added the standard merge message
+ on its own after user-supplied message, which should have overridden the
+ standard one.
+
+Other minor documentation updates are included.
diff --git a/RelNotes/1.6.5.5.adoc b/RelNotes/1.6.5.5.adoc
new file mode 100644
index 0000000..ecfc57d
--- /dev/null
+++ b/RelNotes/1.6.5.5.adoc
@@ -0,0 +1,49 @@
+Git v1.6.5.5 Release Notes
+==========================
+
+Fixes since v1.6.5.4
+--------------------
+
+ * Manual pages can be formatted with older xmlto again.
+
+ * GREP_OPTIONS exported from user's environment could have broken
+ our scripted commands.
+
+ * In configuration files, a few variables that name paths can begin with
+ ~/ and ~username/ and they are expanded as expected. This is not a
+ bugfix but 1.6.6 will have this and without backporting users cannot
+ easily use the same ~/.gitconfig across versions.
+
+ * "git diff -B -M" did the same computation to hash lines of contents
+ twice, and held onto memory after it has used the data in it
+ unnecessarily before it freed.
+
+ * "git diff -B" and "git diff --dirstat" was not counting newly added
+ contents correctly.
+
+ * "git format-patch revisions... -- path" issued an incorrect error
+ message that suggested to use "--" on the command line when path
+ does not exist in the current work tree (it is a separate matter if
+ it makes sense to limit format-patch with pathspecs like that
+ without using the --full-diff option).
+
+ * "git grep -F -i StRiNg" did not work as expected.
+
+ * Enumeration of available merge strategies iterated over the list of
+ commands in a wrong way, sometimes producing an incorrect result.
+
+ * "git shortlog" did not honor the "encoding" header embedded in the
+ commit object like "git log" did.
+
+ * Reading progress messages that come from the remote side while running
+ "git pull" is given precedence over reading the actual pack data to
+ prevent garbled progress message on the user's terminal.
+
+ * "git rebase" got confused when the log message began with certain
+ strings that looked like Subject:, Date: or From: header.
+
+ * "git reset" accidentally run in .git/ directory checked out the
+ work tree contents in there.
+
+
+Other minor documentation updates are included.
diff --git a/RelNotes/1.6.5.6.adoc b/RelNotes/1.6.5.6.adoc
new file mode 100644
index 0000000..a9eaf76
--- /dev/null
+++ b/RelNotes/1.6.5.6.adoc
@@ -0,0 +1,23 @@
+Git v1.6.5.6 Release Notes
+==========================
+
+Fixes since v1.6.5.5
+--------------------
+
+ * "git add -p" had a regression since v1.6.5.3 that broke deletion of
+ non-empty files.
+
+ * "git archive -o o.zip -- Makefile" produced an archive in o.zip
+ but in POSIX tar format.
+
+ * Error message given to "git pull --rebase" when the user didn't give
+ enough clue as to what branch to integrate with still talked about
+ "merging with" the branch.
+
+ * Error messages given by "git merge" when the merge resulted in a
+ fast-forward still were in plumbing lingo, even though in v1.6.5
+ we reworded messages in other cases.
+
+ * The post-upload-hook run by upload-pack in response to "git fetch" has
+ been removed, due to security concerns (the hook first appeared in
+ 1.6.5).
diff --git a/RelNotes/1.6.5.7.adoc b/RelNotes/1.6.5.7.adoc
new file mode 100644
index 0000000..dc5302c
--- /dev/null
+++ b/RelNotes/1.6.5.7.adoc
@@ -0,0 +1,19 @@
+Git v1.6.5.7 Release Notes
+==========================
+
+Fixes since v1.6.5.6
+--------------------
+
+* If a user specifies a color for a <slot> (i.e. a class of things to show
+ in a particular color) that is known only by newer versions of git
+ (e.g. "color.diff.func" was recently added for upcoming 1.6.6 release),
+ an older version of git should just ignore them. Instead we diagnosed
+ it as an error.
+
+* With help.autocorrect set to non-zero value, the logic to guess typos
+ in the subcommand name misfired and ran a random nonsense command.
+
+* If a command is run with an absolute path as a pathspec inside a bare
+ repository, e.g. "rev-list HEAD -- /home", the code tried to run
+ strlen() on NULL, which is the result of get_git_work_tree(), and
+ segfaulted.
diff --git a/RelNotes/1.6.5.8.adoc b/RelNotes/1.6.5.8.adoc
new file mode 100644
index 0000000..8b24beb
--- /dev/null
+++ b/RelNotes/1.6.5.8.adoc
@@ -0,0 +1,28 @@
+Git v1.6.5.8 Release Notes
+==========================
+
+Fixes since v1.6.5.7
+--------------------
+
+* "git count-objects" did not handle packfiles that are bigger than 4G on
+ platforms with 32-bit off_t.
+
+* "git rebase -i" did not abort cleanly if it failed to launch the editor.
+
+* "git blame" did not work well when commit lacked the author name.
+
+* "git fast-import" choked when handling a tag that points at an object
+ that is not a commit.
+
+* "git reset --hard" did not work correctly when GIT_WORK_TREE environment
+ variable is used to point at the root of the true work tree.
+
+* "git grep" fed a buffer that is not NUL-terminated to underlying
+ regexec().
+
+* "git checkout -m other" while on a branch that does not have any commit
+ segfaulted, instead of failing.
+
+* "git branch -a other" should have diagnosed the command as an error.
+
+Other minor documentation updates are also included.
diff --git a/RelNotes/1.6.5.9.adoc b/RelNotes/1.6.5.9.adoc
new file mode 100644
index 0000000..bb469dd
--- /dev/null
+++ b/RelNotes/1.6.5.9.adoc
@@ -0,0 +1,18 @@
+Git v1.6.5.9 Release Notes
+==========================
+
+Fixes since v1.6.5.8
+--------------------
+
+ * An overlong line after ".gitdir: " in a git file caused out of bounds
+ access to an array on the stack.
+
+ * "git blame -L $start,$end" segfaulted when too large $start was given.
+
+ * "git rev-parse --parseopt --stop-at-non-option" did not stop at non option
+ when --keep-dashdash was in effect.
+
+ * "gitweb" can sometimes be tricked into parrotting a filename argument
+ given in a request without properly quoting.
+
+Other minor fixes and documentation updates are included.
diff --git a/RelNotes/1.6.5.adoc b/RelNotes/1.6.5.adoc
new file mode 100644
index 0000000..79cb1b2
--- /dev/null
+++ b/RelNotes/1.6.5.adoc
@@ -0,0 +1,169 @@
+GIT v1.6.5 Release Notes
+========================
+
+In git 1.7.0, which was planned to be the release after 1.6.5, "git
+push" into a branch that is currently checked out will be refused by
+default.
+
+You can choose what should happen upon such a push by setting the
+configuration variable receive.denyCurrentBranch in the receiving
+repository.
+
+Also, "git push $there :$killed" to delete the branch $killed in a remote
+repository $there, when $killed branch is the current branch pointed at by
+its HEAD, will be refused by default.
+
+You can choose what should happen upon such a push by setting the
+configuration variable receive.denyDeleteCurrent in the receiving
+repository.
+
+To ease the transition plan, the receiving repository of such a
+push running this release will issue a big warning when the
+configuration variable is missing. Please refer to:
+
+ https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/GitFaq.html#non-bare
+ https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/
+
+for more details on the reason why this change is needed and the
+transition plan.
+
+Updates since v1.6.4
+--------------------
+
+(subsystems)
+
+ * various updates to gitk, git-svn and gitweb.
+
+(portability)
+
+ * more improvements on mingw port.
+
+ * mingw will also give FRSX as the default value for the LESS
+ environment variable when the user does not have one.
+
+ * initial support to compile git on Windows with MSVC.
+
+(performance)
+
+ * On major platforms, the system can be compiled to use with Linus's
+ block-sha1 implementation of the SHA-1 hash algorithm, which
+ outperforms the default fallback implementation we borrowed from
+ Mozilla.
+
+ * Unnecessary inefficiency in deepening of a shallow repository has
+ been removed.
+
+ * "git clone" does not grab objects that it does not need (i.e.
+ referenced only from refs outside refs/heads and refs/tags
+ hierarchy) anymore.
+
+ * The "git" main binary used to link with libcurl, which then dragged
+ in a large number of external libraries. When using basic plumbing
+ commands in scripts, this unnecessarily slowed things down. We now
+ implement http/https/ftp transfer as a separate executable as we
+ used to.
+
+ * "git clone" run locally hardlinks or copies the files in .git/ to
+ newly created repository. It used to give new mtime to copied files,
+ but this delayed garbage collection to trigger unnecessarily in the
+ cloned repository. We now preserve mtime for these files to avoid
+ this issue.
+
+(usability, bells and whistles)
+
+ * Human writable date format to various options, e.g. --since=yesterday,
+ master@{2000.09.17}, are taught to infer some omitted input properly.
+
+ * A few programs gave verbose "advice" messages to help uninitiated
+ people when issuing error messages. An infrastructure to allow
+ users to squelch them has been introduced, and a few such messages
+ can be silenced now.
+
+ * refs/replace/ hierarchy is designed to be usable as a replacement
+ of the "grafts" mechanism, with the added advantage that it can be
+ transferred across repositories.
+
+ * "git am" learned to optionally ignore whitespace differences.
+
+ * "git am" handles input e-mail files that has CRLF line endings sensibly.
+
+ * "git am" learned "--scissors" option to allow you to discard early part
+ of an incoming e-mail.
+
+ * "git archive -o output.zip" works without being told what format to
+ use with an explicit "--format=zip".option.
+
+ * "git checkout", "git reset" and "git stash" learned to pick and
+ choose to use selected changes you made, similar to "git add -p".
+
+ * "git clone" learned a "-b" option to pick a HEAD to check out
+ different from the remote's default branch.
+
+ * "git clone" learned --recursive option.
+
+ * "git clone" from a local repository on a different filesystem used to
+ copy individual object files without preserving the old timestamp, giving
+ them extra lifetime in the new repository until they gc'ed.
+
+ * "git commit --dry-run $args" is a new recommended way to ask "what would
+ happen if I try to commit with these arguments."
+
+ * "git commit --dry-run" and "git status" shows conflicted paths in a
+ separate section to make them easier to spot during a merge.
+
+ * "git cvsimport" now supports password-protected pserver access even
+ when the password is not taken from ~/.cvspass file.
+
+ * "git fast-export" learned --no-data option that can be useful when
+ reordering commits and trees without touching the contents of
+ blobs.
+
+ * "git fast-import" has a pair of new front-end in contrib/ area.
+
+ * "git init" learned to mkdir/chdir into a directory when given an
+ extra argument (i.e. "git init this").
+
+ * "git instaweb" optionally can use mongoose as the web server.
+
+ * "git log --decorate" can optionally be told with --decorate=full to
+ give the reference name in full.
+
+ * "git merge" issued an unnecessarily scary message when it detected
+ that the merge may have to touch the path that the user has local
+ uncommitted changes to. The message has been reworded to make it
+ clear that the command aborted, without doing any harm.
+
+ * "git push" can be told to be --quiet.
+
+ * "git push" pays attention to url.$base.pushInsteadOf and uses a URL
+ that is derived from the URL used for fetching.
+
+ * informational output from "git reset" that lists the locally modified
+ paths is made consistent with that of "git checkout $another_branch".
+
+ * "git submodule" learned to give submodule name to scripts run with
+ "foreach" subcommand.
+
+ * various subcommands to "git submodule" learned --recursive option.
+
+ * "git submodule summary" learned --files option to compare the work
+ tree vs the commit bound at submodule path, instead of comparing
+ the index.
+
+ * "git upload-pack", which is the server side support for "git clone" and
+ "git fetch", can call a new post-upload-pack hook for statistics purposes.
+
+(developers)
+
+ * With GIT_TEST_OPTS="--root=/p/a/t/h", tests can be run outside the
+ source directory; using tmpfs may give faster turnaround.
+
+ * With NO_PERL_MAKEMAKER set, DESTDIR= is now honoured, so you can
+ build for one location, and install into another location to tar it
+ up.
+
+Fixes since v1.6.4
+------------------
+
+All of the fixes in v1.6.4.X maintenance series are included in this
+release, unless otherwise noted.
diff --git a/RelNotes/1.6.6.1.adoc b/RelNotes/1.6.6.1.adoc
new file mode 100644
index 0000000..f1d0a4a
--- /dev/null
+++ b/RelNotes/1.6.6.1.adoc
@@ -0,0 +1,37 @@
+Git v1.6.6.1 Release Notes
+==========================
+
+Fixes since v1.6.6
+------------------
+
+ * "git blame" did not work well when commit lacked the author name.
+
+ * "git branch -a name" wasn't diagnosed as an error.
+
+ * "git count-objects" did not handle packfiles that are bigger than 4G on
+ platforms with 32-bit off_t.
+
+ * "git checkout -m other" while on a branch that does not have any commit
+ segfaulted, instead of failing.
+
+ * "git fast-import" choked when fed a tag that do not point at a
+ commit.
+
+ * "git grep" finding from work tree files could have fed garbage to
+ the underlying regexec(3).
+
+ * "git grep -L" didn't show empty files (they should never match, and
+ they should always appear in -L output as unmatching).
+
+ * "git rebase -i" did not abort cleanly if it failed to launch the editor.
+
+ * "git reset --hard" did not work correctly when GIT_WORK_TREE environment
+ variable is used to point at the root of the true work tree.
+
+ * http-backend was not listed in the command list in the documentation.
+
+ * Building on FreeBSD (both 7 and 8) needs OLD_ICONV set in the Makefile
+
+ * "git checkout -m some-branch" while on an unborn branch crashed.
+
+Other minor documentation updates are included.
diff --git a/RelNotes/1.6.6.2.adoc b/RelNotes/1.6.6.2.adoc
new file mode 100644
index 0000000..4eaddc0
--- /dev/null
+++ b/RelNotes/1.6.6.2.adoc
@@ -0,0 +1,46 @@
+Git v1.6.6.2 Release Notes
+==========================
+
+Fixes since v1.6.6.1
+--------------------
+
+ * recursive merge didn't correctly diagnose its own programming errors,
+ and instead caused the caller to segfault.
+
+ * The new "smart http" aware clients probed the web servers to see if
+ they support smart http, but did not fall back to dumb http transport
+ correctly with some servers.
+
+ * Time based reflog syntax e.g. "@{yesterday}" didn't diagnose a misspelled
+ time specification and instead assumed "@{now}".
+
+ * "git archive HEAD -- no-such-directory" produced an empty archive
+ without complaining.
+
+ * "git blame -L start,end -- file" misbehaved when given a start that is
+ larger than the number of lines in the file.
+
+ * "git checkout -m" didn't correctly call custom merge backend supplied
+ by the end user.
+
+ * "git config -f <file>" misbehaved when run from a subdirectory.
+
+ * "git cvsserver" didn't like having regex metacharacters (e.g. '+') in
+ CVSROOT environment.
+
+ * "git fast-import" did not correctly handle large blobs that may
+ bust the pack size limit.
+
+ * "git gui" is supposed to work even when launched from inside a .git
+ directory.
+
+ * "git gui" misbehaved when applying a hunk that ends with deletion.
+
+ * "git imap-send" did not honor imap.preformattedHTML as documented.
+
+ * "git log" family incorrectly showed the commit notes unconditionally by
+ mistake, which was especially irritating when running "git log --oneline".
+
+ * "git status" shouldn't require an write access to the repository.
+
+Other minor documentation updates are included.
diff --git a/RelNotes/1.6.6.3.adoc b/RelNotes/1.6.6.3.adoc
new file mode 100644
index 0000000..11483ac
--- /dev/null
+++ b/RelNotes/1.6.6.3.adoc
@@ -0,0 +1,23 @@
+Git v1.6.6.3 Release Notes
+==========================
+
+Fixes since v1.6.6.2
+--------------------
+
+ * An overlong line after ".gitdir: " in a git file caused out of bounds
+ access to an array on the stack.
+
+ * "git bisect $path" did not correctly diagnose an error when given a
+ non-existent path.
+
+ * "git blame -L $start,$end" segfaulted when too large $start was given.
+
+ * "git imap-send" did not write draft box with CRLF line endings per RFC.
+
+ * "git rev-parse --parseopt --stop-at-non-option" did not stop at non option
+ when --keep-dashdash was in effect.
+
+ * "gitweb" can sometimes be tricked into parrotting a filename argument
+ given in a request without properly quoting.
+
+Other minor fixes and documentation updates are included.
diff --git a/RelNotes/1.6.6.adoc b/RelNotes/1.6.6.adoc
new file mode 100644
index 0000000..88b86a8
--- /dev/null
+++ b/RelNotes/1.6.6.adoc
@@ -0,0 +1,224 @@
+Git v1.6.6 Release Notes
+========================
+
+Notes on behaviour change
+-------------------------
+
+ * In this release, "git fsck" defaults to "git fsck --full" and
+ checks packfiles, and because of this it will take much longer to
+ complete than before. If you prefer a quicker check only on loose
+ objects (the old default), you can say "git fsck --no-full". This
+ has been supported by 1.5.4 and newer versions of git, so it is
+ safe to write it in your script even if you use slightly older git
+ on some of your machines.
+
+Preparing yourselves for compatibility issues in 1.7.0
+------------------------------------------------------
+
+In git 1.7.0, which is planned to be the release after 1.6.6, there will
+be a handful of behaviour changes that will break backward compatibility.
+
+These changes were discussed long time ago and existing behaviours have
+been identified as more problematic to the userbase than keeping them for
+the sake of backward compatibility.
+
+When necessary, a transition strategy for existing users has been designed
+not to force them running around setting configuration variables and
+updating their scripts in order to either keep the traditional behaviour
+or adjust to the new behaviour, on the day their sysadmin decides to install
+the new version of git. When we switched from "git-foo" to "git foo" in
+1.6.0, even though the change had been advertised and the transition
+guide had been provided for a very long time, the users procrastinated
+during the entire transition period, and ended up panicking on the day
+their sysadmins updated their git installation. We are trying to avoid
+repeating that unpleasantness in the 1.7.0 release.
+
+For changes decided to be in 1.7.0, commands that will be affected
+have been much louder to strongly discourage such procrastination, and
+they continue to be in this release. If you have been using recent
+versions of git, you would have seen warnings issued when you used
+features whose behaviour will change, with a clear instruction on how
+to keep the existing behaviour if you want to. You hopefully are
+already well prepared.
+
+Of course, we have also been giving "this and that will change in
+1.7.0; prepare yourselves" warnings in the release notes and
+announcement messages for the past few releases. Let's see how well
+users will fare this time.
+
+ * "git push" into a branch that is currently checked out (i.e. pointed by
+ HEAD in a repository that is not bare) will be refused by default.
+
+ Similarly, "git push $there :$killed" to delete the branch $killed
+ in a remote repository $there, when $killed branch is the current
+ branch pointed at by its HEAD, will be refused by default.
+
+ Setting the configuration variables receive.denyCurrentBranch and
+ receive.denyDeleteCurrent to 'ignore' in the receiving repository
+ can be used to override these safety features. Versions of git
+ since 1.6.2 have issued a loud warning when you tried to do these
+ operations without setting the configuration, so repositories of
+ people who still need to be able to perform such a push should
+ already have been future proofed.
+
+ Please refer to:
+
+ https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/GitFaq.html#non-bare
+ https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/
+
+ for more details on the reason why this change is needed and the
+ transition process that already took place so far.
+
+ * "git send-email" will not make deep threads by default when sending a
+ patch series with more than two messages. All messages will be sent
+ as a reply to the first message, i.e. cover letter. Git 1.6.6 (this
+ release) will issue a warning about the upcoming default change, when
+ it uses the traditional "deep threading" behaviour as the built-in
+ default. To squelch the warning but still use the "deep threading"
+ behaviour, give --chain-reply-to option or set sendemail.chainreplyto
+ to true.
+
+ It has been possible to configure send-email to send "shallow thread"
+ by setting sendemail.chainreplyto configuration variable to false.
+ The only thing 1.7.0 release will do is to change the default when
+ you haven't configured that variable.
+
+ * "git status" will not be "git commit --dry-run". This change does not
+ affect you if you run the command without pathspec.
+
+ Nobody sane found the current behaviour of "git status Makefile" useful
+ nor meaningful, and it confused users. "git commit --dry-run" has been
+ provided as a way to get the current behaviour of this command since
+ 1.6.5.
+
+ * "git diff" traditionally treated various "ignore whitespace" options
+ only as a way to filter the patch output. "git diff --exit-code -b"
+ exited with non-zero status even if all changes were about changing the
+ amount of whitespace and nothing else. and "git diff -b" showed the
+ "diff --git" header line for such a change without patch text.
+
+ In 1.7.0, the "ignore whitespaces" will affect the semantics of the
+ diff operation itself. A change that does not affect anything but
+ whitespaces will be reported with zero exit status when run with
+ --exit-code, and there will not be "diff --git" header for such a
+ change.
+
+
+Updates since v1.6.5
+--------------------
+
+(subsystems)
+
+ * various gitk updates including use of themed widgets under Tk 8.5,
+ Japanese translation, a fix to a bug when running "gui blame" from
+ a subdirectory, etc.
+
+ * various git-gui updates including new translations, wm states fixes,
+ Tk bug workaround after quitting, improved heuristics to trigger gc,
+ etc.
+
+ * various git-svn updates.
+
+ * "git fetch" over http learned a new mode that is different from the
+ traditional "dumb commit walker".
+
+(portability)
+
+ * imap-send can be built on mingw port.
+
+(performance)
+
+ * "git diff -B" has smaller memory footprint.
+
+(usability, bells and whistles)
+
+ * The object replace mechanism can be bypassed with --no-replace-objects
+ global option given to the "git" program.
+
+ * In configuration files, a few variables that name paths can begin with ~/
+ and ~username/ and they are expanded as expected.
+
+ * "git subcmd -h" now shows short usage help for many more subcommands.
+
+ * "git bisect reset" can reset to an arbitrary commit.
+
+ * "git checkout frotz" when there is no local branch "frotz" but there
+ is only one remote tracking branch "frotz" is taken as a request to
+ start the named branch at the corresponding remote tracking branch.
+
+ * "git commit -c/-C/--amend" can be told with a new "--reset-author" option
+ to ignore authorship information in the commit it is taking the message
+ from.
+
+ * "git describe" can be told to add "-dirty" suffix with "--dirty" option.
+
+ * "git diff" learned --submodule option to show a list of one-line logs
+ instead of differences between the commit object names.
+
+ * "git diff" learned to honor diff.color.func configuration to paint
+ function name hint printed on the hunk header "@@ -j,k +l,m @@" line
+ in the specified color.
+
+ * "git fetch" learned --all and --multiple options, to run fetch from
+ many repositories, and --prune option to remove remote tracking
+ branches that went stale. These make "git remote update" and "git
+ remote prune" less necessary (there is no plan to remove "remote
+ update" nor "remote prune", though).
+
+ * "git fsck" by default checks the packfiles (i.e. "--full" is the
+ default); you can turn it off with "git fsck --no-full".
+
+ * "git grep" can use -F (fixed strings) and -i (ignore case) together.
+
+ * import-tars contributed fast-import frontend learned more types of
+ compressed tarballs.
+
+ * "git instaweb" knows how to talk with mod_cgid to apache2.
+
+ * "git log --decorate" shows the location of HEAD as well.
+
+ * "git log" and "git rev-list" learned to take revs and pathspecs from
+ the standard input with the new "--stdin" option.
+
+ * "--pretty=format" option to "log" family of commands learned:
+
+ . to wrap text with the "%w()" specifier.
+ . to show reflog information with "%g[sdD]" specifier.
+
+ * "git notes" command to annotate existing commits.
+
+ * "git merge" (and "git pull") learned --ff-only option to make it fail
+ if the merge does not result in a fast-forward.
+
+ * "git mergetool" learned to use p4merge.
+
+ * "git rebase -i" learned "reword" that acts like "edit" but immediately
+ starts an editor to tweak the log message without returning control to
+ the shell, which is done by "edit" to give an opportunity to tweak the
+ contents.
+
+ * "git send-email" can be told with "--envelope-sender=auto" to use the
+ same address as "From:" address as the envelope sender address.
+
+ * "git send-email" will issue a warning when it defaults to the
+ --chain-reply-to behaviour without being told by the user and
+ instructs to prepare for the change of the default in 1.7.0 release.
+
+ * In "git submodule add <repository> <path>", <path> is now optional and
+ inferred from <repository> the same way "git clone <repository>" does.
+
+ * "git svn" learned to read SVN 1.5+ and SVK merge tickets.
+
+ * "git svn" learned to recreate empty directories tracked only by SVN.
+
+ * "gitweb" can optionally render its "blame" output incrementally (this
+ requires JavaScript on the client side).
+
+ * Author names shown in gitweb output are links to search commits by the
+ author.
+
+Fixes since v1.6.5
+------------------
+
+All of the fixes in v1.6.5.X maintenance series are included in this
+release, unless otherwise noted.
diff --git a/RelNotes/1.7.0.1.adoc b/RelNotes/1.7.0.1.adoc
new file mode 100644
index 0000000..8ff5bca
--- /dev/null
+++ b/RelNotes/1.7.0.1.adoc
@@ -0,0 +1,35 @@
+Git v1.7.0.1 Release Notes
+==========================
+
+Fixes since v1.7.0
+------------------
+
+ * In a freshly created repository "rev-parse HEAD^0" complained that
+ it is dangling symref, even though "rev-parse HEAD" didn't.
+
+ * "git show :no-such-name" tried to access the index without bounds
+ check, leading to a potential segfault.
+
+ * Message from "git cherry-pick" was harder to read and use than necessary
+ when it stopped due to conflicting changes.
+
+ * We referred to ".git/refs/" throughout the documentation when we
+ meant to talk about abstract notion of "ref namespace". Because
+ people's repositories often have packed refs these days, this was
+ confusing.
+
+ * "git diff --output=/path/that/cannot/be/written" did not correctly
+ error out.
+
+ * "git grep -e -pattern-that-begin-with-dash paths..." could not be
+ spelled as "git grep -- -pattern-that-begin-with-dash paths..." which
+ would be a GNU way to use "--" as "end of options".
+
+ * "git grep" compiled with threading support tried to access an
+ uninitialized mutex on boxes with a single CPU.
+
+ * "git stash pop -q --index" failed because the unnecessary --index
+ option was propagated to "git stash drop" that is internally run at the
+ end.
+
+And other minor fixes and documentation updates.
diff --git a/RelNotes/1.7.0.2.adoc b/RelNotes/1.7.0.2.adoc
new file mode 100644
index 0000000..73ed2b5
--- /dev/null
+++ b/RelNotes/1.7.0.2.adoc
@@ -0,0 +1,40 @@
+Git v1.7.0.2 Release Notes
+==========================
+
+Fixes since v1.7.0.1
+--------------------
+
+ * GIT_PAGER was not honored consistently by some scripted Porcelains, most
+ notably "git am".
+
+ * updating working tree files after telling git to add them to the
+ index and while it is still working created garbage object files in
+ the repository without diagnosing it as an error.
+
+ * "git bisect -- pathspec..." did not diagnose an error condition properly when
+ the simplification with given pathspec made the history empty.
+
+ * "git rev-list --cherry-pick A...B" now has an obvious optimization when the
+ histories haven't diverged (i.e. when one end is an ancestor of the other).
+
+ * "git diff --quiet -w" did not work as expected.
+
+ * "git fast-import" didn't work with a large input, as it lacked support
+ for producing the pack index in v2 format.
+
+ * "git imap-send" didn't use CRLF line endings over the imap protocol
+ when storing its payload to the draft box, violating RFC 3501.
+
+ * "git log --format='%w(x,y,z)%b'" and friends that rewrap message
+ has been optimized for utf-8 payload.
+
+ * Error messages generated on the receiving end did not come back to "git
+ push".
+
+ * "git status" in 1.7.0 lacked the optimization we used to have in 1.6.X series
+ to speed up scanning of large working tree.
+
+ * "gitweb" did not diagnose parsing errors properly while reading its configuration
+ file.
+
+And other minor fixes and documentation updates.
diff --git a/RelNotes/1.7.0.3.adoc b/RelNotes/1.7.0.3.adoc
new file mode 100644
index 0000000..3b35573
--- /dev/null
+++ b/RelNotes/1.7.0.3.adoc
@@ -0,0 +1,34 @@
+Git v1.7.0.3 Release Notes
+==========================
+
+Fixes since v1.7.0.2
+--------------------
+
+ * Object files are created in a more ACL friendly way in repositories
+ where group permission is ACL controlled.
+
+ * "git add -i" didn't handle a deleted path very well.
+
+ * "git blame" padded line numbers with one extra SP when the total number
+ of lines was one less than multiple of ten due to an off-by-one error.
+
+ * "git fetch --all/--multi" used to discard information for remotes that
+ are fetched earlier.
+
+ * "git log --author=me --grep=it" tried to find commits that have "it"
+ or are written by "me", instead of the ones that have "it" _and_ are
+ written by "me".
+
+ * "git log -g branch" misbehaved when there was no entries in the reflog
+ for the named branch.
+
+ * "git mailinfo" (hence "git am") incorrectly removed initial indent from
+ paragraphs.
+
+ * "git prune" and "git reflog" (hence "git gc" as well) didn't honor
+ an instruction never to expire by setting gc.reflogexpire to never.
+
+ * "git push" misbehaved when branch.<name>.merge was configured without
+ matching branch.<name>.remote.
+
+And other minor fixes and documentation updates.
diff --git a/RelNotes/1.7.0.4.adoc b/RelNotes/1.7.0.4.adoc
new file mode 100644
index 0000000..cf7f60e
--- /dev/null
+++ b/RelNotes/1.7.0.4.adoc
@@ -0,0 +1,27 @@
+Git v1.7.0.4 Release Notes
+==========================
+
+Fixes since v1.7.0.3
+--------------------
+
+ * Optimized ntohl/htonl on big-endian machines were broken.
+
+ * Color values given to "color.<cmd>.<slot>" configuration can now have
+ more than one attributes (e.g. "bold ul").
+
+ * "git add -u nonexistent-path" did not complain.
+
+ * "git apply --whitespace=fix" didn't work well when an early patch in
+ a patch series adds trailing blank lines and a later one depended on
+ such a block of blank lines at the end.
+
+ * "git fast-export" didn't check error status and stop when marks file
+ cannot be opened.
+
+ * "git format-patch --ignore-if-in-upstream" gave unwarranted errors
+ when the range was empty, instead of silently finishing.
+
+ * "git remote prune" did not detect remote tracking refs that became
+ dangling correctly.
+
+And other minor fixes and documentation updates.
diff --git a/RelNotes/1.7.0.5.adoc b/RelNotes/1.7.0.5.adoc
new file mode 100644
index 0000000..3149c91
--- /dev/null
+++ b/RelNotes/1.7.0.5.adoc
@@ -0,0 +1,26 @@
+Git v1.7.0.5 Release Notes
+==========================
+
+Fixes since v1.7.0.4
+--------------------
+
+ * "git daemon" failed to compile on platforms without sockaddr_storage type.
+
+ * Output from "git rev-list --pretty=oneline" was unparsable when a
+ commit did not have any message, which is abnormal but possible in a
+ repository converted from foreign scm.
+
+ * "git stash show <commit-that-is-not-a-stash>" gave an error message
+ that was not so useful. Reworded the message to "<it> is not a
+ stash".
+
+ * Python scripts in contrib/ area now start with "#!/usr/bin/env python"
+ to honor user's PATH.
+
+ * "git imap-send" used to mistake any line that begins with "From " as a
+ message separator in format-patch output.
+
+ * Smart http server backend failed to report an internal server error and
+ infinitely looped instead after output pipe was closed.
+
+And other minor fixes and documentation updates.
diff --git a/RelNotes/1.7.0.6.adoc b/RelNotes/1.7.0.6.adoc
new file mode 100644
index 0000000..b2852b6
--- /dev/null
+++ b/RelNotes/1.7.0.6.adoc
@@ -0,0 +1,13 @@
+Git v1.7.0.6 Release Notes
+==========================
+
+Fixes since v1.7.0.5
+--------------------
+
+ * "git diff --stat" used "int" to count the size of differences,
+ which could result in overflowing.
+
+ * "git rev-list --abbrev-commit" defaulted to 40-byte abbreviations, unlike
+ newer tools in the git toolset.
+
+And other minor fixes and documentation updates.
diff --git a/RelNotes/1.7.0.7.adoc b/RelNotes/1.7.0.7.adoc
new file mode 100644
index 0000000..d0cb7ca
--- /dev/null
+++ b/RelNotes/1.7.0.7.adoc
@@ -0,0 +1,16 @@
+Git v1.7.0.7 Release Notes
+==========================
+
+Fixes since v1.7.0.6
+--------------------
+
+ * "make NO_CURL=NoThanks install" was broken.
+
+ * An overlong line after ".gitdir: " in a git file caused out of bounds
+ access to an array on the stack.
+
+ * "git config --path conf.var" to attempt to expand a variable conf.var
+ that uses "~/" short-hand segfaulted when $HOME environment variable
+ was not set.
+
+And other minor fixes and documentation updates.
diff --git a/RelNotes/1.7.0.8.adoc b/RelNotes/1.7.0.8.adoc
new file mode 100644
index 0000000..7f05b48
--- /dev/null
+++ b/RelNotes/1.7.0.8.adoc
@@ -0,0 +1,10 @@
+Git v1.7.0.8 Release Notes
+==========================
+
+This is primarily to backport support for the new "add.ignoreErrors"
+name given to the existing "add.ignore-errors" configuration variable.
+
+The next version, Git 1.7.4, and future versions, will support both
+old and incorrect name and the new corrected name, but without this
+backport, users who want to use the new name "add.ignoreErrors" in
+their repositories cannot use older versions of Git.
diff --git a/RelNotes/1.7.0.9.adoc b/RelNotes/1.7.0.9.adoc
new file mode 100644
index 0000000..bfb3166
--- /dev/null
+++ b/RelNotes/1.7.0.9.adoc
@@ -0,0 +1,8 @@
+Git v1.7.0.9 Release Notes
+==========================
+
+Fixes since v1.7.0.8
+--------------------
+
+ * "gitweb" can sometimes be tricked into parrotting a filename argument
+ given in a request without properly quoting.
diff --git a/RelNotes/1.7.0.adoc b/RelNotes/1.7.0.adoc
new file mode 100644
index 0000000..0bb8c0b
--- /dev/null
+++ b/RelNotes/1.7.0.adoc
@@ -0,0 +1,214 @@
+Git v1.7.0 Release Notes
+========================
+
+Notes on behaviour change
+-------------------------
+
+ * "git push" into a branch that is currently checked out (i.e. pointed at by
+ HEAD in a repository that is not bare) is refused by default.
+
+ Similarly, "git push $there :$killed" to delete the branch $killed
+ in a remote repository $there, when $killed branch is the current
+ branch pointed at by its HEAD, will be refused by default.
+
+ Setting the configuration variables receive.denyCurrentBranch and
+ receive.denyDeleteCurrent to 'ignore' in the receiving repository
+ can be used to override these safety features.
+
+ * "git send-email" does not make deep threads by default when sending a
+ patch series with more than two messages. All messages will be sent
+ as a reply to the first message, i.e. cover letter.
+
+ It has been possible already to configure send-email to send "shallow thread"
+ by setting sendemail.chainreplyto configuration variable to false. The
+ only thing this release does is to change the default when you haven't
+ configured that variable.
+
+ * "git status" is not "git commit --dry-run" anymore. This change does
+ not affect you if you run the command without argument.
+
+ * "git diff" traditionally treated various "ignore whitespace" options
+ only as a way to filter the patch output. "git diff --exit-code -b"
+ exited with non-zero status even if all changes were about changing the
+ amount of whitespace and nothing else; and "git diff -b" showed the
+ "diff --git" header line for such a change without patch text.
+
+ In this release, the "ignore whitespaces" options affect the semantics
+ of the diff operation. A change that does not affect anything but
+ whitespaces is reported with zero exit status when run with
+ --exit-code, and there is no "diff --git" header for such a change.
+
+ * External diff and textconv helpers are now executed using the shell.
+ This makes them consistent with other programs executed by git, and
+ allows you to pass command-line parameters to the helpers. Any helper
+ paths containing spaces or other metacharacters now need to be
+ shell-quoted. The affected helpers are GIT_EXTERNAL_DIFF in the
+ environment, and diff.*.command and diff.*.textconv in the config
+ file.
+
+ * The --max-pack-size argument to 'git repack', 'git pack-objects', and
+ 'git fast-import' was assuming the provided size to be expressed in MiB,
+ unlike the corresponding config variable and other similar options accepting
+ a size value. It is now expecting a size expressed in bytes, with a possible
+ unit suffix of 'k', 'm', or 'g'.
+
+Updates since v1.6.6
+--------------------
+
+(subsystems)
+
+ * "git fast-import" updates; adds "option" and "feature" to detect the
+ mismatch between fast-import and the frontends that produce the input
+ stream.
+
+ * "git svn" support of subversion "merge tickets" and miscellaneous fixes.
+
+ * "gitk" and "git gui" translation updates.
+
+ * "gitweb" updates (code clean-up, load checking etc.)
+
+(portability)
+
+ * Some more MSVC portability patches for msysgit port.
+
+ * Minimum Pthreads emulation for msysgit port.
+
+(performance)
+
+ * More performance improvement patches for msysgit port.
+
+(usability, bells and whistles)
+
+ * More commands learned "--quiet" and "--[no-]progress" options.
+
+ * Various commands given by the end user (e.g. diff.type.textconv,
+ and GIT_EDITOR) can be specified with command line arguments. E.g. it
+ is now possible to say "[diff "utf8doc"] textconv = nkf -w".
+
+ * "sparse checkout" feature allows only part of the work tree to be
+ checked out.
+
+ * HTTP transfer can use authentication scheme other than basic
+ (i.e./e.g. digest).
+
+ * Switching from a version of superproject that used to have a submodule
+ to another version of superproject that no longer has it did not remove
+ the submodule directory when it should (namely, when you are not
+ interested in the submodule at all and didn't clone/checkout).
+
+ * A new attribute conflict-marker-size can be used to change the size of
+ the conflict markers from the default 7; this is useful when tracked
+ contents (e.g. git-merge documentation) have strings that resemble the
+ conflict markers.
+
+ * A new syntax "<branch>@{upstream}" can be used on the command line to
+ substitute the name of the "upstream" of the branch. Missing branch
+ defaults to the current branch, so "git fetch && git merge @{upstream}"
+ will be equivalent to "git pull".
+
+ * "git am --resolved" has a synonym "git am --continue".
+
+ * "git branch --set-upstream" can be used to update the (surprise!) upstream,
+ i.e. where the branch is supposed to pull and merge from (or rebase onto).
+
+ * "git checkout A...B" is a way to detach HEAD at the merge base between
+ A and B.
+
+ * "git checkout -m path" to reset the work tree file back into the
+ conflicted state works even when you already ran "git add path" and
+ resolved the conflicts.
+
+ * "git commit --date='<date>'" can be used to override the author date
+ just like "git commit --author='<name> <email>'" can be used to
+ override the author identity.
+
+ * "git commit --no-status" can be used to omit the listing of the index
+ and the work tree status in the editor used to prepare the log message.
+
+ * "git commit" warns a bit more aggressively until you configure user.email,
+ whose default value almost always is not (and fundamentally cannot be)
+ what you want.
+
+ * "git difftool" has been extended to make it easier to integrate it
+ with gitk.
+
+ * "git fetch --all" can now be used in place of "git remote update".
+
+ * "git grep" does not rely on external grep anymore. It can use more than
+ one thread to accelerate the operation.
+
+ * "git grep" learned "--quiet" option.
+
+ * "git log" and friends learned "--glob=heads/*" syntax that is a more
+ flexible way to complement "--branches/--tags/--remotes".
+
+ * "git merge" learned to pass options specific to strategy-backends. E.g.
+
+ - "git merge -Xsubtree=path/to/directory" can be used to tell the subtree
+ strategy how much to shift the trees explicitly.
+
+ - "git merge -Xtheirs" can be used to auto-merge as much as possible,
+ while discarding your own changes and taking merged version in
+ conflicted regions.
+
+ * "git push" learned "git push origin --delete branch", a syntactic sugar
+ for "git push origin :branch".
+
+ * "git push" learned "git push --set-upstream origin forker:forkee" that
+ lets you configure your "forker" branch to later pull from "forkee"
+ branch at "origin".
+
+ * "git rebase --onto A...B" means the history is replayed on top of the
+ merge base between A and B.
+
+ * "git rebase -i" learned new action "fixup" that squashes the change
+ but does not affect existing log message.
+
+ * "git rebase -i" also learned --autosquash option that is useful
+ together with the new "fixup" action.
+
+ * "git remote" learned set-url subcommand that updates (surprise!) url
+ for an existing remote nickname.
+
+ * "git rerere" learned "forget path" subcommand. Together with "git
+ checkout -m path" it will be useful when you recorded a wrong
+ resolution.
+
+ * Use of "git reset --merge" has become easier when resetting away a
+ conflicted mess left in the work tree.
+
+ * "git rerere" had rerere.autoupdate configuration but there was no way
+ to countermand it from the command line; --no-rerere-autoupdate option
+ given to "merge", "revert", etc. fixes this.
+
+ * "git status" learned "-s(hort)" output format.
+
+(developers)
+
+ * The infrastructure to build foreign SCM interface has been updated.
+
+ * Many more commands are now built-in.
+
+ * THREADED_DELTA_SEARCH is no more. If you build with threads, delta
+ compression will always take advantage of it.
+
+Fixes since v1.6.6
+------------------
+
+All of the fixes in v1.6.6.X maintenance series are included in this
+release, unless otherwise noted.
+
+ * "git branch -d branch" used to refuse deleting the branch even when
+ the branch is fully merged to its upstream branch if it is not merged
+ to the current branch. It now deletes it in such a case.
+
+ * "filter-branch" command incorrectly said --prune-empty and --filter-commit
+ were incompatible; the latter should be read as --commit-filter.
+
+ * When using "git status" or asking "git diff" to compare the work tree
+ with something, they used to consider that a checked-out submodule with
+ uncommitted changes is not modified; this could cause people to forget
+ committing these changes in the submodule before committing in the
+ superproject. They now consider such a change as a modification and
+ "git diff" will append a "-dirty" to the work tree side when generating
+ patch output or when used with the --submodule option.
diff --git a/RelNotes/1.7.1.1.adoc b/RelNotes/1.7.1.1.adoc
new file mode 100644
index 0000000..3f6b314
--- /dev/null
+++ b/RelNotes/1.7.1.1.adoc
@@ -0,0 +1,96 @@
+Git v1.7.1.1 Release Notes
+==========================
+
+Fixes since v1.7.1
+------------------
+
+ * Authentication over http transport can now be made lazily, in that the
+ request can first go to a URL without username, get a 401 response and
+ then the client will ask for the username to use.
+
+ * We used to mistakenly think "../work" is a subdirectory of the current
+ directory when we are in "../work-xyz".
+
+ * The attribute mechanism now allows an entry that uses an attribute
+ macro that set/unset one attribute, immediately followed by an
+ overriding setting; this makes attribute macros much easier to use.
+
+ * We didn't recognize timezone "Z" as a synonym for "UTC" (75b37e70).
+
+ * In 1.7.0, read-tree and user commands that use the mechanism such as
+ checkout and merge were fixed to handle switching between branches one
+ of which has a file while the other has a directory at the same path
+ correctly even when there are some "confusing" pathnames in them. But
+ the algorithm used for this fix was suboptimal and had a terrible
+ performance degradation especially in larger trees.
+
+ * "git am -3" did not show diagnosis when the patch in the message was corrupt.
+
+ * After "git apply --whitespace=fix" removed trailing blank lines in an
+ patch in a patch series, it failed to apply later patches that depend
+ on the presence of such blank lines.
+
+ * "git bundle --stdin" segfaulted.
+
+ * "git checkout" and "git rebase" overwrote paths that are marked "assume
+ unchanged".
+
+ * "git commit --amend" on a commit with an invalid author-name line that
+ lacks the display name didn't work.
+
+ * "git describe" did not tie-break tags that point at the same commit
+ correctly; newer ones are preferred by paying attention to the
+ tagger date now.
+
+ * "git diff" used to tell underlying xdiff machinery to work very hard to
+ minimize the output, but this often was spending too many extra cycles
+ for very little gain.
+
+ * "git diff --color" did not paint extended diff headers per line
+ (i.e. the coloring escape sequence didn't end at the end of line),
+ which confused "less -R".
+
+ * "git fetch" over HTTP verifies the downloaded packfiles more robustly.
+
+ * The memory usage by "git index-pack" (run during "git fetch" and "git
+ push") got leaner.
+
+ * "GIT_DIR=foo.git git init --bare bar.git" created foo.git instead of bar.git.
+
+ * "git log --abbrev=$num --format='%h' ignored --abbrev=$num.
+
+ * "git ls-files ../out/side/cwd" refused to work.
+
+ * "git merge --log" used to replace the custom message given by "-m" with
+ the shortlog, instead of appending to it.
+
+ * "git notes copy" without any other argument segfaulted.
+
+ * "git pull" accepted "--dry-run", gave it to underlying "git fetch" but
+ ignored the option itself, resulting in a bogus attempt to merge
+ unrelated commit.
+
+ * "git rebase" did not faithfully reproduce a malformed author ident, that
+ is often seen in a repository converted from foreign SCMs.
+
+ * "git reset --hard" started from a wrong directory and a working tree in
+ a nonstandard location is in use got confused.
+
+ * "git send-email" lacked a way to specify the domainname used in the
+ EHLO/HELO exchange, causing rejected connection from picky servers.
+ It learned --smtp-domain option to solve this issue.
+
+ * "git send-email" did not declare a content-transfer-encoding and
+ content-type even when its payload needs to be sent in 8-bit.
+
+ * "git show -C -C" and other corner cases lost diff metainfo output
+ in 1.7.0.
+
+ * "git stash" incorrectly lost paths in the working tree that were
+ previously removed from the index.
+
+ * "git status" stopped refreshing the index by mistake in 1.7.1.
+
+ * "git status" showed excess "hints" even when advice.statusHints is set to false.
+
+And other minor fixes and documentation updates.
diff --git a/RelNotes/1.7.1.2.adoc b/RelNotes/1.7.1.2.adoc
new file mode 100644
index 0000000..61ba14e
--- /dev/null
+++ b/RelNotes/1.7.1.2.adoc
@@ -0,0 +1,28 @@
+Git v1.7.1.2 Release Notes
+==========================
+
+Fixes since v1.7.1.1
+--------------------
+
+ * "git commit" did not honor GIT_REFLOG_ACTION environment variable, resulting
+ reflog messages for cherry-pick and revert actions to be recorded as "commit".
+
+ * "git clone/fetch/pull" issued an incorrect error message when a ref and
+ a symref that points to the ref were updated at the same time. This
+ obviously would update them to the same value, and should not result in
+ an error condition.
+
+ * "git diff" inside a tree with many pathnames that have certain
+ characters has become very slow in 1.7.0 by mistake.
+
+ * "git rev-parse --parseopt --stop-at-non-option" did not stop at non option
+ when --keep-dashdash was in effect.
+
+ * An overlong line after ".gitdir: " in a git file caused out of bounds
+ access to an array on the stack.
+
+ * "git config --path conf.var" to attempt to expand a variable conf.var
+ that uses "~/" short-hand segfaulted when $HOME environment variable
+ was not set.
+
+And other minor fixes and documentation updates.
diff --git a/RelNotes/1.7.1.3.adoc b/RelNotes/1.7.1.3.adoc
new file mode 100644
index 0000000..5b18518
--- /dev/null
+++ b/RelNotes/1.7.1.3.adoc
@@ -0,0 +1,10 @@
+Git v1.7.1.3 Release Notes
+==========================
+
+This is primarily to backport support for the new "add.ignoreErrors"
+name given to the existing "add.ignore-errors" configuration variable.
+
+The next version, Git 1.7.4, and future versions, will support both
+old and incorrect name and the new corrected name, but without this
+backport, users who want to use the new name "add.ignoreErrors" in
+their repositories cannot use older versions of Git.
diff --git a/RelNotes/1.7.1.4.adoc b/RelNotes/1.7.1.4.adoc
new file mode 100644
index 0000000..7c734b4
--- /dev/null
+++ b/RelNotes/1.7.1.4.adoc
@@ -0,0 +1,8 @@
+Git v1.7.1.4 Release Notes
+==========================
+
+Fixes since v1.7.1.3
+--------------------
+
+ * "gitweb" can sometimes be tricked into parrotting a filename argument
+ given in a request without properly quoting.
diff --git a/RelNotes/1.7.1.adoc b/RelNotes/1.7.1.adoc
new file mode 100644
index 0000000..9d89fed
--- /dev/null
+++ b/RelNotes/1.7.1.adoc
@@ -0,0 +1,89 @@
+Git v1.7.1 Release Notes
+========================
+
+Updates since v1.7.0
+--------------------
+
+ * Eric Raymond is the maintainer of updated CIAbot scripts, in contrib/.
+
+ * gitk updates.
+
+ * Some commands (e.g. svn and http interfaces) that interactively ask
+ for a password can be told to use an external program given via
+ GIT_ASKPASS.
+
+ * Conflict markers that lead the common ancestor in diff3-style output
+ now have a label, which hopefully would help third-party tools that
+ expect one.
+
+ * Comes with an updated bash-completion script.
+
+ * "git am" learned "--keep-cr" option to handle inputs that are
+ a mixture of changes to files with and without CRLF line endings.
+
+ * "git cvsimport" learned -R option to leave revision mapping between
+ CVS revisions and resulting git commits.
+
+ * "git diff --submodule" notices and describes dirty submodules.
+
+ * "git for-each-ref" learned %(symref), %(symref:short) and %(flag)
+ tokens.
+
+ * "git hash-object --stdin-paths" can take "--no-filters" option now.
+
+ * "git init" can be told to look at init.templatedir configuration
+ variable (obviously that has to come from either /etc/gitconfig or
+ $HOME/.gitconfig).
+
+ * "git grep" learned "--no-index" option, to search inside contents that
+ are not managed by git.
+
+ * "git grep" learned --color=auto/always/never.
+
+ * "git grep" learned to paint filename and line-number in colors.
+
+ * "git log -p --first-parent -m" shows one-parent diff for merge
+ commits, instead of showing combined diff.
+
+ * "git merge-file" learned to use custom conflict marker size and also
+ to use the "union merge" behaviour.
+
+ * "git notes" command has been rewritten in C and learned many commands
+ and features to help you carry notes forward across rebases and amends.
+
+ * "git request-pull" identifies the commit the request is relative to in
+ a more readable way.
+
+ * "git reset" learned "--keep" option that lets you discard commits
+ near the tip while preserving your local changes in a way similar
+ to how "git checkout branch" does.
+
+ * "git status" notices and describes dirty submodules.
+
+ * "git svn" should work better when interacting with repositories
+ with CRLF line endings.
+
+ * "git imap-send" learned to support CRAM-MD5 authentication.
+
+ * "gitweb" installation procedure can use "minified" js/css files
+ better.
+
+ * Various documentation updates.
+
+Fixes since v1.7.0
+------------------
+
+All of the fixes in v1.7.0.X maintenance series are included in this
+release, unless otherwise noted.
+
+ * "git add frotz/nitfol" did not complain when the entire frotz/ directory
+ was ignored.
+
+ * "git diff --stat" used "int" to count the size of differences,
+ which could result in overflowing.
+
+ * "git rev-list --pretty=oneline" didn't terminate a record with LF for
+ commits without any message.
+
+ * "git rev-list --abbrev-commit" defaulted to 40-byte abbreviations, unlike
+ newer tools in the git toolset.
diff --git a/RelNotes/1.7.10.1.adoc b/RelNotes/1.7.10.1.adoc
new file mode 100644
index 0000000..71a86cb
--- /dev/null
+++ b/RelNotes/1.7.10.1.adoc
@@ -0,0 +1,78 @@
+Git v1.7.10.1 Release Notes
+===========================
+
+Additions since v1.7.10
+-----------------------
+
+Localization message files for Danish and German have been added.
+
+
+Fixes since v1.7.10
+-------------------
+
+ * "git add -p" is not designed to deal with unmerged paths but did
+ not exclude them and tried to apply funny patches only to fail.
+
+ * "git blame" started missing quite a few changes from the origin
+ since we stopped using the diff minimization by default in v1.7.2
+ era.
+
+ * When PATH contains an unreadable directory, alias expansion code
+ did not kick in, and failed with an error that said "git-subcmd"
+ was not found.
+
+ * "git clean -d -f" (not "-d -f -f") is supposed to protect nested
+ working trees of independent git repositories that exist in the
+ current project working tree from getting removed, but the
+ protection applied only to such working trees that are at the
+ top-level of the current project by mistake.
+
+ * "git commit --author=$name" did not tell the name that was being
+ recorded in the resulting commit to hooks, even though it does do
+ so when the end user overrode the authorship via the
+ "GIT_AUTHOR_NAME" environment variable.
+
+ * When "git commit --template F" errors out because the user did not
+ touch the message, it claimed that it aborts due to "empty
+ message", which was utterly wrong.
+
+ * The regexp configured with diff.wordregex was incorrectly reused
+ across files.
+
+ * An age-old corner case bug in combine diff (only triggered with -U0
+ and the hunk at the beginning of the file needs to be shown) has
+ been fixed.
+
+ * Rename detection logic used to match two empty files as renames
+ during merge-recursive, leading to unnatural mismerges.
+
+ * The parser in "fast-import" did not diagnose ":9" style references
+ that is not followed by required SP/LF as an error.
+
+ * When "git fetch" encounters repositories with too many references,
+ the command line of "fetch-pack" that is run by a helper
+ e.g. remote-curl, may fail to hold all of them. Now such an
+ internal invocation can feed the references through the standard
+ input of "fetch-pack".
+
+ * "git fetch" that recurses into submodules on demand did not check
+ if it needs to go into submodules when non branches (most notably,
+ tags) are fetched.
+
+ * "log -p --graph" used with "--stat" had a few formatting error.
+
+ * Running "notes merge --commit" failed to perform correctly when run
+ from any directory inside $GIT_DIR/. When "notes merge" stops with
+ conflicts, $GIT_DIR/NOTES_MERGE_WORKTREE is the place a user edits
+ to resolve it.
+
+ * The 'push to upstream' implementation was broken in some corner
+ cases. "git push $there" without refspec, when the current branch
+ is set to push to a remote different from $there, used to push to
+ $there using the upstream information to a remote unrelated to
+ $there.
+
+ * Giving "--continue" to a conflicted "rebase -i" session skipped a
+ commit that only results in changes to submodules.
+
+Also contains minor fixes and documentation updates.
diff --git a/RelNotes/1.7.10.2.adoc b/RelNotes/1.7.10.2.adoc
new file mode 100644
index 0000000..7a7e9d6
--- /dev/null
+++ b/RelNotes/1.7.10.2.adoc
@@ -0,0 +1,85 @@
+Git v1.7.10.2 Release Notes
+===========================
+
+Fixes since v1.7.10.1
+---------------------
+
+ * The test scaffolding for git-daemon was flaky.
+
+ * The test scaffolding for fast-import was flaky.
+
+ * The filesystem boundary was not correctly reported when .git directory
+ discovery stopped at a mount point.
+
+ * HTTP transport that requires authentication did not work correctly when
+ multiple connections are used simultaneously.
+
+ * Minor memory leak during unpack_trees (hence "merge" and "checkout"
+ to check out another branch) has been plugged.
+
+ * In the older days, the header "Conflicts:" in "cherry-pick" and "merge"
+ was separated by a blank line from the list of paths that follow for
+ readability, but when "merge" was rewritten in C, we lost it by
+ mistake. Remove the newline from "cherry-pick" to make them match
+ again.
+
+ * The command line parser choked "git cherry-pick $name" when $name can
+ be both revision name and a pathname, even though $name can never be a
+ path in the context of the command.
+
+ * The "include.path" facility in the configuration mechanism added in
+ 1.7.10 forgot to interpret "~/path" and "~user/path" as it should.
+
+ * "git config --rename-section" to rename an existing section into a
+ bogus one did not check the new name.
+
+ * The "diff --no-index" codepath used limited-length buffers, risking
+ pathnames getting truncated. Update it to use the strbuf API.
+
+ * The report from "git fetch" said "new branch" even for a non branch
+ ref.
+
+ * The http-backend (the server side of the smart http transfer) used
+ to overwrite GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL with the
+ value obtained from REMOTE_USER unconditionally, making it
+ impossible for the server side site-specific customization to use
+ different identity sources to affect the names logged. It now uses
+ REMOTE_USER only as a fallback value.
+
+ * "log --graph" was not very friendly with "--stat" option and its
+ output had line breaks at wrong places.
+
+ * Octopus merge strategy did not reduce heads that are recorded in the
+ final commit correctly.
+
+ * "git push" over smart-http lost progress output a few releases ago;
+ this release resurrects it.
+
+ * The error and advice messages given by "git push" when it fails due
+ to non-ff were not very helpful to new users; it has been broken
+ into three cases, and each is given a separate advice message.
+
+ * The insn sheet given by "rebase -i" did not make it clear that the
+ insn lines can be re-ordered to affect the order of the commits in
+ the resulting history.
+
+ * "git repack" used to write out unreachable objects as loose objects
+ when repacking, even if such loose objects will immediately pruned
+ due to its age.
+
+ * A contrib script "rerere-train" did not work out of the box unless
+ user futzed with her $PATH.
+
+ * "git rev-parse --show-prefix" used to emit nothing when run at the
+ top-level of the working tree, but now it gives a blank line.
+
+ * The i18n of error message "git stash save" was not properly done.
+
+ * "git submodule" used a sed script that some platforms mishandled.
+
+ * When using a Perl script on a system where "perl" found on user's
+ $PATH could be ancient or otherwise broken, we allow builders to
+ specify the path to a good copy of Perl with $PERL_PATH. The
+ gitweb test forgot to use that Perl when running its test.
+
+Also contains minor fixes and documentation updates.
diff --git a/RelNotes/1.7.10.3.adoc b/RelNotes/1.7.10.3.adoc
new file mode 100644
index 0000000..703fbf1
--- /dev/null
+++ b/RelNotes/1.7.10.3.adoc
@@ -0,0 +1,43 @@
+Git v1.7.10.3 Release Notes
+===========================
+
+Fixes since v1.7.10.2
+---------------------
+
+ * The message file for German translation has been updated a bit.
+
+ * Running "git checkout" on an unborn branch used to corrupt HEAD.
+
+ * When checking out another commit from an already detached state, we
+ used to report all commits that are not reachable from any of the
+ refs as lossage, but some of them might be reachable from the new
+ HEAD, and there is no need to warn about them.
+
+ * Some time ago, "git clone" lost the progress output for its
+ "checkout" phase; when run without any "--quiet" option, it should
+ give progress to the lengthy operation.
+
+ * The directory path used in "git diff --no-index", when it recurses
+ down, was broken with a recent update after v1.7.10.1 release.
+
+ * "log -z --pretty=tformat:..." did not terminate each record with
+ NUL. The fix is not entirely correct when the output also asks for
+ --patch and/or --stat, though.
+
+ * The DWIM behaviour for "log --pretty=format:%gd -g" was somewhat
+ broken and gave undue precedence to configured log.date, causing
+ "git stash list" to show "stash@{time stamp string}".
+
+ * "git status --porcelain" ignored "--branch" option by mistake. The
+ output for "git status --branch -z" was also incorrect and did not
+ terminate the record for the current branch name with NUL as asked.
+
+ * When a submodule repository uses alternate object store mechanism,
+ some commands that were started from the superproject did not
+ notice it and failed with "No such object" errors. The subcommands
+ of "git submodule" command that recursed into the submodule in a
+ separate process were OK; only the ones that cheated and peeked
+ directly into the submodule's repository from the primary process
+ were affected.
+
+Also contains minor fixes and documentation updates.
diff --git a/RelNotes/1.7.10.4.adoc b/RelNotes/1.7.10.4.adoc
new file mode 100644
index 0000000..57597f2
--- /dev/null
+++ b/RelNotes/1.7.10.4.adoc
@@ -0,0 +1,29 @@
+Git v1.7.10.4 Release Notes
+===========================
+
+Fixes since v1.7.10.3
+---------------------
+
+ * The message file for Swedish translation has been updated a bit.
+
+ * A name taken from mailmap was copied into an internal buffer
+ incorrectly and could overrun the buffer if it is too long.
+
+ * A malformed commit object that has a header line chomped in the
+ middle could kill git with a NULL pointer dereference.
+
+ * An author/committer name that is a single character was mishandled
+ as an invalid name by mistake.
+
+ * The progress indicator for a large "git checkout" was sent to
+ stderr even if it is not a terminal.
+
+ * "git grep -e '$pattern'", unlike the case where the patterns are
+ read from a file, did not treat individual lines in the given
+ pattern argument as separate regular expressions as it should.
+
+ * When "git rebase" was given a bad commit to replay the history on,
+ its error message did not correctly give the command line argument
+ it had trouble parsing.
+
+Also contains minor fixes and documentation updates.
diff --git a/RelNotes/1.7.10.5.adoc b/RelNotes/1.7.10.5.adoc
new file mode 100644
index 0000000..4db1770
--- /dev/null
+++ b/RelNotes/1.7.10.5.adoc
@@ -0,0 +1,12 @@
+Git v1.7.10.5 Release Notes
+===========================
+
+Fixes since v1.7.10.4
+---------------------
+
+ * "git fast-export" did not give a readable error message when the
+ same mark erroneously appeared twice in the --import-marks input.
+
+ * "git rebase -p" used to pay attention to rebase.autosquash which
+ was wrong. "git rebase -p -i" should, but "git rebase -p" by
+ itself should not.
diff --git a/RelNotes/1.7.10.adoc b/RelNotes/1.7.10.adoc
new file mode 100644
index 0000000..58100bf
--- /dev/null
+++ b/RelNotes/1.7.10.adoc
@@ -0,0 +1,219 @@
+Git v1.7.10 Release Notes
+=========================
+
+Compatibility Notes
+-------------------
+
+ * From this release on, the "git merge" command in an interactive
+ session will start an editor when it automatically resolves the
+ merge for the user to explain the resulting commit, just like the
+ "git commit" command does when it wasn't given a commit message.
+
+ If you have a script that runs "git merge" and keeps its standard
+ input and output attached to the user's terminal, and if you do not
+ want the user to explain the resulting merge commits, you can
+ export GIT_MERGE_AUTOEDIT environment variable set to "no", like
+ this:
+
+ #!/bin/sh
+ GIT_MERGE_AUTOEDIT=no
+ export GIT_MERGE_AUTOEDIT
+
+ to disable this behavior (if you want your users to explain their
+ merge commits, you do not have to do anything). Alternatively, you
+ can give the "--no-edit" option to individual invocations of the
+ "git merge" command if you know everybody who uses your script has
+ Git v1.7.8 or newer.
+
+ * The "--binary/-b" options to "git am" have been a no-op for quite a
+ while and were deprecated in mid 2008 (v1.6.0). When you give these
+ options to "git am", it will now warn and ask you not to use them.
+
+ * When you do not tell which branches and tags to push to the "git
+ push" command in any way, the command used "matching refs" rule to
+ update remote branches and tags with branches and tags with the
+ same name you locally have. In future versions of Git, this will
+ change to push out only your current branch according to either the
+ "upstream" or the "current" rule. Although "upstream" may be more
+ powerful once the user understands Git better, the semantics
+ "current" gives is simpler and easier to understand for beginners
+ and may be a safer and better default option. We haven't decided
+ yet which one to switch to.
+
+
+Updates since v1.7.9
+--------------------
+
+UI, Workflows & Features
+
+ * various "gitk" updates.
+ - show the path to the top level directory in the window title
+ - update preference edit dialog
+ - display file list correctly when directories are given on command line
+ - make "git-describe" output in the log message into a clickable link
+ - avoid matching the UNIX timestamp part when searching all fields
+ - give preference to symbolic font names like sans & monospace
+ - allow comparing two commits using a mark
+ - "gitk" honors log.showroot configuration.
+
+ * Teams for localizing the messages from the Porcelain layer of
+ commands are starting to form, thanks to Jiang Xin who volunteered
+ to be the localization coordinator. Translated messages for
+ simplified Chinese, Swedish and Portuguese are available.
+
+ * The configuration mechanism learned an "include" facility; an
+ assignment to the include.path pseudo-variable causes the named
+ file to be included in-place when Git looks up configuration
+ variables.
+
+ * A content filter (clean/smudge) used to be just a way to make the
+ recorded contents "more useful", and allowed to fail; a filter can
+ now optionally be marked as "required".
+
+ * Options whose names begin with "--no-" (e.g. the "--no-verify"
+ option of the "git commit" command) can be negated by omitting
+ "no-" from its name, e.g. "git commit --verify".
+
+ * "git am" learned to pass "-b" option to underlying "git mailinfo", so
+ that a bracketed string other than "PATCH" at the beginning can be kept.
+
+ * "git clone" learned "--single-branch" option to limit cloning to a
+ single branch (surprise!); tags that do not point into the history
+ of the branch are not fetched.
+
+ * "git clone" learned to detach the HEAD in the resulting repository
+ when the user specifies a tag with "--branch" (e.g., "--branch=v1.0").
+ Clone also learned to print the usual "detached HEAD" advice in such
+ a case, similar to "git checkout v1.0".
+
+ * When showing a patch while ignoring whitespace changes, the context
+ lines are taken from the postimage, in order to make it easier to
+ view the output.
+
+ * "git diff --stat" learned to adjust the width of the output on
+ wider terminals, and give more columns to pathnames as needed.
+
+ * "diff-highlight" filter (in contrib/) was updated to produce more
+ aesthetically pleasing output.
+
+ * "fsck" learned "--no-dangling" option to omit dangling object
+ information.
+
+ * "git log -G" and "git log -S" learned to pay attention to the "-i"
+ option. With "-i", "log -G" ignores the case when finding patch
+ hunks that introduce or remove a string that matches the given
+ pattern. Similarly with "-i", "log -S" ignores the case when
+ finding the commit the given block of text appears or disappears
+ from the file.
+
+ * "git merge" in an interactive session learned to spawn the editor
+ by default to let the user edit the auto-generated merge message,
+ to encourage people to explain their merges better. Legacy scripts
+ can export GIT_MERGE_AUTOEDIT=no to retain the historical behavior.
+ Both "git merge" and "git pull" can be given --no-edit from the
+ command line to accept the auto-generated merge message.
+
+ * The advice message given when the user didn't give enough clue on
+ what to merge to "git pull" and "git merge" has been updated to
+ be more concise and easier to understand.
+
+ * "git push" learned the "--prune" option, similar to "git fetch".
+
+ * The whole directory that houses a top-level superproject managed by
+ "git submodule" can be moved to another place.
+
+ * "git symbolic-ref" learned the "--short" option to abbreviate the
+ refname it shows unambiguously.
+
+ * "git tag --list" can be given "--points-at <object>" to limit its
+ output to those that point at the given object.
+
+ * "gitweb" allows intermediate entries in the directory hierarchy
+ that leads to a project to be clicked, which in turn shows the
+ list of projects inside that directory.
+
+ * "gitweb" learned to read various pieces of information for the
+ repositories lazily, instead of reading everything that could be
+ needed (including the ones that are not necessary for a specific
+ task).
+
+ * Project search in "gitweb" shows the substring that matched in the
+ project name and description highlighted.
+
+ * HTTP transport learned to authenticate with a proxy if needed.
+
+ * A new script "diffall" is added to contrib/; it drives an
+ external tool to perform a directory diff of two Git revisions
+ in one go, unlike "difftool" that compares one file at a time.
+
+Foreign Interface
+
+ * Improved handling of views, labels and branches in "git-p4" (in contrib).
+
+ * "git-p4" (in contrib) suffered from unnecessary merge conflicts when
+ p4 expanded the embedded $RCS$-like keywords; it can be now told to
+ unexpand them.
+
+ * Some "git-svn" updates.
+
+ * "vcs-svn"/"svn-fe" learned to read dumps with svn-deltas and
+ support incremental imports.
+
+ * "git difftool/mergetool" learned to drive DeltaWalker.
+
+Performance
+
+ * Unnecessary calls to parse_object() "git upload-pack" makes in
+ response to "git fetch", have been eliminated, to help performance
+ in repositories with excessive number of refs.
+
+Internal Implementation (please report possible regressions)
+
+ * Recursive call chains in "git index-pack" to deal with long delta
+ chains have been flattened, to reduce the stack footprint.
+
+ * Use of add_extra_ref() API is now gone, to make it possible to
+ cleanly restructure the overall refs API.
+
+ * The command line parser of "git pack-objects" now uses parse-options
+ API.
+
+ * The test suite supports the new "test_pause" helper function.
+
+ * Parallel to the test suite, there is a beginning of performance
+ benchmarking framework.
+
+ * t/Makefile is adjusted to prevent newer versions of GNU make from
+ running tests in seemingly random order.
+
+ * The code to check if a path points at a file beyond a symbolic link
+ has been restructured to be thread-safe.
+
+ * When pruning directories that has become empty during "git prune"
+ and "git prune-packed", call closedir() that iterates over a
+ directory before rmdir() it.
+
+Also contains minor documentation updates and code clean-ups.
+
+
+Fixes since v1.7.9
+------------------
+
+Unless otherwise noted, all the fixes since v1.7.9 in the maintenance
+releases are contained in this release (see release notes to them for
+details).
+
+ * Build with NO_PERL_MAKEMAKER was broken and Git::I18N did not work
+ with versions of Perl older than 5.8.3.
+ (merge 5eb660e ab/perl-i18n later to maint).
+
+ * "git tag -s" honored "gpg.program" configuration variable since
+ 1.7.9, but "git tag -v" and "git verify-tag" didn't.
+ (merge a2c2506 az/verify-tag-use-gpg-config later to maint).
+
+ * "configure" script learned to take "--with-sane-tool-path" from the
+ command line to record SANE_TOOL_PATH (used to avoid broken platform
+ tools in /usr/bin) in config.mak.autogen. This may be useful for
+ people on Solaris who have saner tools outside /usr/xpg[46]/bin.
+
+ * zsh port of bash completion script needed another workaround.
diff --git a/RelNotes/1.7.11.1.adoc b/RelNotes/1.7.11.1.adoc
new file mode 100644
index 0000000..577ecca
--- /dev/null
+++ b/RelNotes/1.7.11.1.adoc
@@ -0,0 +1,9 @@
+Git v1.7.11.1 Release Notes
+===========================
+
+Fixes since v1.7.11
+-------------------
+
+ * The cross links in the HTML version of manual pages were broken.
+
+Also contains minor typofixes and documentation updates.
diff --git a/RelNotes/1.7.11.2.adoc b/RelNotes/1.7.11.2.adoc
new file mode 100644
index 0000000..f0cfd02
--- /dev/null
+++ b/RelNotes/1.7.11.2.adoc
@@ -0,0 +1,53 @@
+Git v1.7.11.2 Release Notes
+===========================
+
+Fixes since v1.7.11.1
+---------------------
+
+ * On Cygwin, the platform pread(2) is not thread safe, just like our
+ own compat/ emulation, and cannot be used in the index-pack
+ program. Makefile variable NO_THREAD_SAFE_PREAD can be defined to
+ avoid use of this function in a threaded program.
+
+ * "git add" allows adding a regular file to the path where a
+ submodule used to exist, but "git update-index" does not allow an
+ equivalent operation to Porcelain writers.
+
+ * "git archive" incorrectly computed the header checksum; the symptom
+ was observed only when using pathnames with hi-bit set.
+
+ * "git blame" did not try to make sure that the abbreviated commit
+ object names in its output are unique.
+
+ * Running "git bundle verify" on a bundle that records a complete
+ history said "it requires these 0 commits".
+
+ * "git clone --single-branch" to clone a single branch did not limit
+ the cloning to the specified branch.
+
+ * "git diff --no-index" did not correctly handle relative paths and
+ did not correctly give exit codes when run under "--quiet" option.
+
+ * "git diff --no-index" did not work with pagers correctly.
+
+ * "git diff COPYING HEAD:COPYING" gave a nonsense error message that
+ claimed that the tree-ish HEAD did not have COPYING in it.
+
+ * When "git log" gets "--simplify-merges/by-decoration" together with
+ "--first-parent", the combination of these options makes the
+ simplification logic to use in-core commit objects that haven't
+ been examined for relevance, either producing incorrect result or
+ taking too long to produce any output. Teach the simplification
+ logic to ignore commits that the first-parent traversal logic
+ ignored when both are in effect to work around the issue.
+
+ * "git ls-files --exclude=t -i" did not consider anything under t/ as
+ excluded, as it did not pay attention to exclusion of leading paths
+ while walking the index. Other two users of excluded() are also
+ updated.
+
+ * "git request-pull $url dev" when the tip of "dev" branch was tagged
+ with "ext4-for-linus" used the contents from the tag in the output
+ but still asked the "dev" branch to be pulled, not the tag.
+
+Also contains minor typofixes and documentation updates.
diff --git a/RelNotes/1.7.11.3.adoc b/RelNotes/1.7.11.3.adoc
new file mode 100644
index 0000000..64494f8
--- /dev/null
+++ b/RelNotes/1.7.11.3.adoc
@@ -0,0 +1,53 @@
+Git v1.7.11.3 Release Notes
+===========================
+
+Fixes since v1.7.11.3
+---------------------
+
+ * The error message from "git push $there :bogo" (and its equivalent
+ "git push $there --delete bogo") mentioned that we tried and failed
+ to guess what ref is being deleted based on the LHS of the refspec,
+ which we don't.
+
+ * A handful of files and directories we create had tighter than
+ necessary permission bits when the user wanted to have group
+ writability (e.g. by setting "umask 002").
+
+ * "commit --amend" used to refuse amending a commit with an empty log
+ message, with or without "--allow-empty-message".
+
+ * "git commit --amend --only --" was meant to allow "Clever" people to
+ rewrite the commit message without making any change even when they
+ have already changes for the next commit added to their index, but
+ it never worked as advertised since it was introduced in 1.3.0 era.
+
+ * Even though the index can record pathnames longer than 1<<12 bytes,
+ in some places we were not comparing them in full, potentially
+ replacing index entries instead of adding.
+
+ * "git show"'s auto-walking behaviour was an unreliable and
+ unpredictable hack; it now behaves just like "git log" does when it
+ walks.
+
+ * "git diff", "git status" and anything that internally uses the
+ comparison machinery was utterly broken when the difference
+ involved a file with "-" as its name. This was due to the way "git
+ diff --no-index" was incorrectly bolted on to the system, making
+ any comparison that involves a file "-" at the root level
+ incorrectly read from the standard input.
+
+ * We did not have test to make sure "git rebase" without extra options
+ filters out an empty commit in the original history.
+
+ * "git fast-export" produced an input stream for fast-import without
+ properly quoting pathnames when they contain SPs in them.
+
+ * "git checkout --detach", when you are still on an unborn branch,
+ should be forbidden, but it wasn't.
+
+ * Some implementations of Perl terminates "lines" with CRLF even when
+ the script is operating on just a sequence of bytes. Make sure to
+ use "$PERL_PATH", the version of Perl the user told Git to use, in
+ our tests to avoid unnecessary breakages in tests.
+
+Also contains minor typofixes and documentation updates.
diff --git a/RelNotes/1.7.11.4.adoc b/RelNotes/1.7.11.4.adoc
new file mode 100644
index 0000000..3a640c2
--- /dev/null
+++ b/RelNotes/1.7.11.4.adoc
@@ -0,0 +1,31 @@
+Git v1.7.11.4 Release Notes
+===========================
+
+Fixes since v1.7.11.3
+---------------------
+
+ * "$GIT_DIR/COMMIT_EDITMSG" file that is used to hold the commit log
+ message user edits was not documented.
+
+ * The advise() function did not use varargs correctly to format
+ its message.
+
+ * When "git am" failed, old timers knew to check .git/rebase-apply/patch
+ to see what went wrong, but we never told the users about it.
+
+ * "git commit-tree" learned a more natural "-p <parent> <tree>" order
+ of arguments long time ago, but recently forgot it by mistake.
+
+ * "git diff --no-ext-diff" did not output anything for a typechange
+ filepair when GIT_EXTERNAL_DIFF is in effect.
+
+ * In 1.7.9 era, we taught "git rebase" about the raw timestamp format
+ but we did not teach the same trick to "filter-branch", which rolled
+ a similar logic on its own.
+
+ * When "git submodule add" clones a submodule repository, it can get
+ confused where to store the resulting submodule repository in the
+ superproject's .git/ directory when there is a symbolic link in the
+ path to the current directory.
+
+Also contains minor typofixes and documentation updates.
diff --git a/RelNotes/1.7.11.5.adoc b/RelNotes/1.7.11.5.adoc
new file mode 100644
index 0000000..0a2ed85
--- /dev/null
+++ b/RelNotes/1.7.11.5.adoc
@@ -0,0 +1,36 @@
+Git v1.7.11.5 Release Notes
+===========================
+
+Fixes since v1.7.11.4
+---------------------
+
+ * The Makefile rule to create assembly output (primarily for
+ debugging purposes) did not create it next to the source.
+
+ * The code to avoid mistaken attempt to add the object directory
+ itself as its own alternate could read beyond end of a string while
+ comparison.
+
+ * On some architectures, "block-sha1" did not compile correctly
+ when compilers inferred alignment guarantees from our source we
+ did not intend to make.
+
+ * When talking to a remote running ssh on IPv6 enabled host, whose
+ address is spelled as "[HOST]:PORT", we did not parse the address
+ correctly and failed to connect.
+
+ * git-blame.el (in compat/) have been updated to use Elisp more
+ correctly.
+
+ * "git checkout <branchname>" to come back from a detached HEAD state
+ incorrectly computed reachability of the detached HEAD, resulting
+ in unnecessary warnings.
+
+ * "git mergetool" did not support --tool-help option to give the list
+ of supported backends, like "git difftool" does.
+
+ * "git grep" stopped spawning an external "grep" long time ago, but a
+ duplicated test to check internal and external "grep" was left
+ behind.
+
+Also contains minor typofixes and documentation updates.
diff --git a/RelNotes/1.7.11.6.adoc b/RelNotes/1.7.11.6.adoc
new file mode 100644
index 0000000..ba7d3c3
--- /dev/null
+++ b/RelNotes/1.7.11.6.adoc
@@ -0,0 +1,84 @@
+Git v1.7.11.6 Release Notes
+===========================
+
+Fixes since v1.7.11.5
+---------------------
+
+ * "ciabot" script (in contrib/) has been updated with extensive
+ documentation.
+
+ * "git foo" errored out with "Not a directory" when the user had a
+ non-directory on $PATH, and worse yet it masked an alias "foo" from
+ running.
+
+ * When the user exports a non-default IFS without HT, scripts that
+ rely on being able to parse "ls-files -s | while read a b c..."
+ started to fail. Protect them from such a misconfiguration.
+
+ * When the user gives an argument that can be taken as both a
+ revision name and a pathname without disambiguating with "--", we
+ used to give a help message "Use '--' to separate". The message
+ has been clarified to show where that '--' goes on the command
+ line.
+
+ * Documentation for the configuration file format had a confusing
+ example.
+
+ * Older parts of the documentation described as if having a regular
+ file in .git/refs/ hierarchy were the only way to have branches and
+ tags, which is not true for quite some time.
+
+ * It was generally understood that "--long-option"s to many of our
+ subcommands can be abbreviated to the unique prefix, but it was not
+ easy to find it described for new readers of the documentation set.
+
+ * The "--topo-order", "--date-order" (and the lack of either means
+ the default order) options to "rev-list" and "log" family of
+ commands were poorly described in the documentation.
+
+ * "git commit --amend" let the user edit the log message and then
+ died when the human-readable committer name was given
+ insufficiently by getpwent(3).
+
+ * The exit status code from "git config" was way overspecified while
+ being incorrect. The implementation has been updated to give the
+ documented status for a case that was documented, and introduce a
+ new code for "all other errors".
+
+ * The output from "git diff -B" for a file that ends with an
+ incomplete line did not put "\ No newline..." on a line of its own.
+
+ * "git diff" had a confusion between taking data from a path in the
+ working tree and taking data from an object that happens to have
+ name 0{40} recorded in a tree.
+
+ * The "--rebase" option to "git pull" can be abbreviated to "-r",
+ but we didn't document it.
+
+ * When "git push" triggered the automatic gc on the receiving end, a
+ message from "git prune" that said it was removing cruft leaked to
+ the standard output, breaking the communication protocol.
+
+ * The reflog entries left by "git rebase" and "git rebase -i" were
+ inconsistent (the interactive one gave an abbreviated object name).
+
+ * "git send-email" did not unquote encoded words that appear on the
+ header correctly, and lost "_" from strings.
+
+ * "git stash apply/pop" did not trigger "rerere" upon conflicts
+ unlike other mergy operations.
+
+ * "git submodule <cmd> path" did not error out when the path to the
+ submodule was misspelt.
+
+ * "git submodule update -f" did not update paths in the working tree
+ that has local changes.
+ (merge 01d4721 sz/submodule-force-update later to maint).
+
+ * "gitweb" when used with PATH_INFO failed to notice directories with
+ SP (and other characters that need URL-style quoting) in them.
+
+ * Fallback 'getpass' implementation made unportable use of stdio API.
+
+ * A utility shell function test_seq has been added as a replacement
+ for the 'seq' utility found on some platforms.
diff --git a/RelNotes/1.7.11.7.adoc b/RelNotes/1.7.11.7.adoc
new file mode 100644
index 0000000..e743a2a
--- /dev/null
+++ b/RelNotes/1.7.11.7.adoc
@@ -0,0 +1,46 @@
+Git v1.7.11.7 Release Notes
+===========================
+
+Fixes since v1.7.11.6
+---------------------
+
+ * The synopsis said "checkout [-B branch]" to make it clear the
+ branch name is a parameter to the option, but the heading for the
+ option description was "-B::", not "-B branch::", making the
+ documentation misleading.
+
+ * Git ships with a fall-back regexp implementation for platforms with
+ buggy regexp library, but it was easy for people to keep using their
+ platform regexp. A new test has been added to check this.
+
+ * "git apply -p0" did not parse pathnames on "diff --git" line
+ correctly. This caused patches that had pathnames in no other
+ places to be mistakenly rejected (most notably, binary patch that
+ does not rename nor change mode). Textual patches, renames or mode
+ changes have preimage and postimage pathnames in different places
+ in a form that can be parsed unambiguously and did not suffer from
+ this problem.
+
+ * After "gitk" showed the contents of a tag, neither "Reread
+ references" nor "Reload" did not update what is shown as the
+ contents of it, when the user overwrote the tag with "git tag -f".
+
+ * "git for-each-ref" did not correctly support more than one --sort
+ option.
+
+ * "git log .." errored out saying it is both rev range and a path
+ when there is no disambiguating "--" is on the command line.
+ Update the command line parser to interpret ".." as a path in such
+ a case.
+
+ * Pushing to smart HTTP server with recent Git fails without having
+ the username in the URL to force authentication, if the server is
+ configured to allow GET anonymously, while requiring authentication
+ for POST.
+
+ * "git show --format='%ci'" did not give timestamp correctly for
+ commits created without human readable name on "committer" line.
+ (merge e27ddb6 jc/maint-ident-missing-human-name later to maint).
+
+ * "git show --quiet" ought to be a synonym for "git show -s", but
+ wasn't.
diff --git a/RelNotes/1.7.11.adoc b/RelNotes/1.7.11.adoc
new file mode 100644
index 0000000..15b954c
--- /dev/null
+++ b/RelNotes/1.7.11.adoc
@@ -0,0 +1,139 @@
+Git v1.7.11 Release Notes
+=========================
+
+Updates since v1.7.10
+---------------------
+
+UI, Workflows & Features
+
+ * A new mode for push, "simple", which is a cross between "current"
+ and "upstream", has been introduced. "git push" without any refspec
+ will push the current branch out to the same name at the remote
+ repository only when it is set to track the branch with the same
+ name over there. The plan is to make this mode the new default
+ value when push.default is not configured.
+
+ * A couple of commands learned the "--column" option to produce
+ columnar output.
+
+ * A third-party tool "git subtree" is distributed in contrib/
+
+ * A remote helper that acts as a proxy and caches ssl session for the
+ https:// transport is added to the contrib/ area.
+
+ * Error messages given when @{u} is used for a branch without its
+ upstream configured have been clarified.
+
+ * Even with the "-q"uiet option, "checkout" used to report setting up
+ tracking. Also "branch" learned the "-q"uiet option to squelch
+ informational message.
+
+ * Your build platform may support hardlinks but you may prefer not to
+ use them, e.g. when installing to DESTDIR to make a tarball and
+ untarring on a filesystem that has poor support for hardlinks.
+ There is a Makefile option NO_INSTALL_HARDLINKS for you.
+
+ * The smart-http backend used to always override GIT_COMMITTER_*
+ variables with REMOTE_USER and REMOTE_ADDR, but these variables are
+ now preserved when set.
+
+ * "git am" learned the "--include" option, which is an opposite of
+ existing the "--exclude" option.
+
+ * When "git am -3" needs to fall back to an application of the patch
+ to a synthesized preimage followed by a 3-way merge, the paths that
+ needed such treatment are now reported to the end user, so that the
+ result in them can be eyeballed with extra care.
+
+ * The output from "diff/log --stat" used to always allocate 4 columns
+ to show the number of modified lines, but not anymore.
+
+ * "git difftool" learned the "--dir-diff" option to spawn external
+ diff tools that can compare two directory hierarchies at a time
+ after populating two temporary directories, instead of running an
+ instance of the external tool once per a file pair.
+
+ * The "fmt-merge-msg" command learned to list the primary contributors
+ involved in the side topic you are merging in a comment in the merge
+ commit template.
+
+ * "git rebase" learned to optionally keep commits that do not
+ introduce any change in the original history.
+
+ * "git push --recurse-submodules" learned to optionally look into the
+ histories of submodules bound to the superproject and push them
+ out.
+
+ * A 'snapshot' request to "gitweb" honors If-Modified-Since: header,
+ based on the commit date.
+
+ * "gitweb" learned to highlight the patch it outputs even more.
+
+Foreign Interface
+
+ * "git svn" used to die with unwanted SIGPIPE when talking with an HTTP
+ server that uses keep-alive.
+
+ * "git svn" learned to use platform specific authentication
+ providers, e.g. gnome-keyring, kwallet, etc.
+
+ * "git p4" has been moved out of the contrib/ area and has seen more
+ work on importing labels as tags from (and exporting tags as labels
+ to) p4.
+
+Performance and Internal Implementation (please report possible regressions)
+
+ * Bash completion script (in contrib/) have been cleaned up to make
+ future work on it simpler.
+
+ * An experimental "version 4" format of the index file has been
+ introduced to reduce on-disk footprint and I/O overhead.
+
+ * "git archive" learned to produce its output without reading the
+ blob object it writes out in memory in its entirety.
+
+ * "git index-pack" that runs when fetching or pushing objects to
+ complete the packfile on the receiving end learned to use multiple
+ threads to do its job when available.
+
+ * The code to compute hash values for lines used by the internal diff
+ engine was optimized on little-endian machines, using the same
+ trick the kernel folks came up with.
+
+ * "git apply" had some memory leaks plugged.
+
+ * Setting up a revision traversal with many starting points was
+ inefficient as these were placed in a date-order priority queue
+ one-by-one. Now they are collected in the queue unordered first,
+ and sorted immediately before getting used.
+
+ * More lower-level commands learned to use the streaming API to read
+ from the object store without keeping everything in core.
+
+ * The weighting parameters to suggestion command name typo have been
+ tweaked, so that "git tags" will suggest "tag?" and not "stage?".
+
+ * Because "sh" on the user's PATH may be utterly broken on some
+ systems, run-command API now uses SHELL_PATH, not /bin/sh, when
+ spawning an external command (not applicable to Windows port).
+
+ * The API to iterate over the refs/ hierarchy has been tweaked to
+ allow walking only a subset of it more efficiently.
+
+Also contains minor documentation updates and code clean-ups.
+
+
+Fixes since v1.7.10
+-------------------
+
+Unless otherwise noted, all the fixes since v1.7.10 in the maintenance
+releases are contained in this release (see release notes to them for
+details).
+
+ * "git submodule init" used to report "registered for path ..."
+ even for submodules that were registered earlier.
+ (cherry-pick c1c259e jl/submodule-report-new-path-once later to maint).
+
+ * "git diff --stat" used to fully count a binary file with modified
+ execution bits whose contents is unmodified, which was not quite
+ right.
diff --git a/RelNotes/1.7.12.1.adoc b/RelNotes/1.7.12.1.adoc
new file mode 100644
index 0000000..b8f04af
--- /dev/null
+++ b/RelNotes/1.7.12.1.adoc
@@ -0,0 +1,134 @@
+Git 1.7.12.1 Release Notes
+==========================
+
+Fixes since v1.7.12
+-------------------
+
+ * "git apply -p0" did not parse pathnames on "diff --git" line
+ correctly. This caused patches that had pathnames in no other
+ places to be mistakenly rejected (most notably, binary patch that
+ does not rename nor change mode). Textual patches, renames or mode
+ changes have preimage and postimage pathnames in different places
+ in a form that can be parsed unambiguously and did not suffer from
+ this problem.
+
+ * "git cherry-pick A C B" used to replay changes in A and then B and
+ then C if these three commits had committer timestamps in that
+ order, which is not what the user who said "A C B" naturally
+ expects.
+
+ * "git commit --amend" let the user edit the log message and then
+ died when the human-readable committer name was given
+ insufficiently by getpwent(3).
+
+ * Some capabilities were asked by fetch-pack even when upload-pack
+ did not advertise that they are available. fetch-pack has been
+ fixed not to do so.
+
+ * "git diff" had a confusion between taking data from a path in the
+ working tree and taking data from an object that happens to have
+ name 0{40} recorded in a tree.
+
+ * "git for-each-ref" did not correctly support more than one --sort
+ option.
+
+ * "git log .." errored out saying it is both rev range and a path
+ when there is no disambiguating "--" is on the command line.
+ Update the command line parser to interpret ".." as a path in such
+ a case.
+
+ * The "--topo-order", "--date-order" (and the lack of either means
+ the default order) options to "rev-list" and "log" family of
+ commands were poorly described in the documentation.
+
+ * "git prune" without "-v" used to warn about leftover temporary
+ files (which is an indication of an earlier aborted operation).
+
+ * Pushing to smart HTTP server with recent Git fails without having
+ the username in the URL to force authentication, if the server is
+ configured to allow GET anonymously, while requiring authentication
+ for POST.
+
+ * The reflog entries left by "git rebase" and "git rebase -i" were
+ inconsistent (the interactive one gave an abbreviated object name).
+
+ * When "git push" triggered the automatic gc on the receiving end, a
+ message from "git prune" that said it was removing cruft leaked to
+ the standard output, breaking the communication protocol.
+
+ * "git show --quiet" ought to be a synonym for "git show -s", but
+ wasn't.
+
+ * "git show --format='%ci'" did not give timestamp correctly for
+ commits created without human readable name on "committer" line.
+
+ * "git send-email" did not unquote encoded words that appear on the
+ header correctly, and lost "_" from strings.
+
+ * The interactive prompt "git send-email" gives was error prone. It
+ asked "What e-mail address do you want to use?" with the address it
+ guessed (correctly) the user would want to use in its prompt,
+ tempting the user to say "y". But the response was taken as "No,
+ please use 'y' as the e-mail address instead", which is most
+ certainly not what the user meant.
+
+ * "gitweb" when used with PATH_INFO failed to notice directories with
+ SP (and other characters that need URL-style quoting) in them.
+
+ * When the user gives an argument that can be taken as both a
+ revision name and a pathname without disambiguating with "--", we
+ used to give a help message "Use '--' to separate". The message
+ has been clarified to show where that '--' goes on the command
+ line.
+
+ * When the user exports a non-default IFS without HT, scripts that
+ rely on being able to parse "ls-files -s | while read a b c..."
+ started to fail. Protect them from such a misconfiguration.
+
+ * The attribute system may be asked for a path that itself or its
+ leading directories no longer exists in the working tree, and it is
+ fine if we cannot open .gitattribute file in such a case. Failure
+ to open per-directory .gitattributes with error status other than
+ ENOENT and ENOTDIR should be diagnosed, but it wasn't.
+
+ * After "gitk" showed the contents of a tag, neither "Reread
+ references" nor "Reload" did not update what is shown as the
+ contents of it, when the user overwrote the tag with "git tag -f".
+
+ * "ciabot" script (in contrib/) has been updated with extensive
+ documentation.
+
+ * "git-jump" script (in contrib/) did not work well when
+ diff.noprefix or diff.mnemonicprefix is in effect.
+
+ * Older parts of the documentation described as if having a regular
+ file in .git/refs/ hierarchy were the only way to have branches and
+ tags, which is not true for quite some time.
+
+ * A utility shell function test_seq has been added as a replacement
+ for the 'seq' utility found on some platforms.
+
+ * Compatibility wrapper to learn the maximum number of file
+ descriptors we can open around sysconf(_SC_OPEN_MAX) and
+ getrlimit(RLIMIT_NO_FILE) has been introduced for portability.
+
+ * We used curl_easy_strerror() without checking version of cURL,
+ breaking the build for versions before curl 7.12.0.
+
+ * Code to work around MacOS X UTF-8 gotcha has been cleaned up.
+
+ * Fallback 'getpass' implementation made unportable use of stdio API.
+
+ * The "--rebase" option to "git pull" can be abbreviated to "-r",
+ but we didn't document it.
+
+ * It was generally understood that "--long-option"s to many of our
+ subcommands can be abbreviated to the unique prefix, but it was not
+ easy to find it described for new readers of the documentation set.
+
+ * The synopsis said "checkout [-B branch]" to make it clear the
+ branch name is a parameter to the option, but the heading for the
+ option description was "-B::", not "-B branch::", making the
+ documentation misleading.
+
+Also contains numerous documentation updates.
diff --git a/RelNotes/1.7.12.2.adoc b/RelNotes/1.7.12.2.adoc
new file mode 100644
index 0000000..6925574
--- /dev/null
+++ b/RelNotes/1.7.12.2.adoc
@@ -0,0 +1,40 @@
+Git 1.7.12.2 Release Notes
+==========================
+
+Fixes since v1.7.12.1
+---------------------
+
+ * When "git am" is fed an input that has multiple "Content-type: ..."
+ header, it did not grok charset= attribute correctly.
+
+ * Even during a conflicted merge, "git blame $path" always meant to
+ blame uncommitted changes to the "working tree" version; make it
+ more useful by showing cleanly merged parts as coming from the other
+ branch that is being merged.
+
+ * "git blame MAKEFILE" run in a history that has "Makefile" but not
+ "MAKEFILE" should say "No such file MAKEFILE in HEAD", but got
+ confused on a case insensitive filesystem and failed to do so.
+
+ * "git fetch --all", when passed "--no-tags", did not honor the
+ "--no-tags" option while fetching from individual remotes (the same
+ issue existed with "--tags", but combination "--all --tags" makes
+ much less sense than "--all --no-tags").
+
+ * "git log/diff/format-patch --stat" showed the "N line(s) added"
+ comment in user's locale and caused careless submitters to send
+ patches with such a line in them to projects whose project language
+ is not their language, mildly irritating others. Localization to
+ the line has been disabled for now.
+
+ * "git log --all-match --grep=A --grep=B" ought to show commits that
+ mention both A and B, but when these three options are used with
+ --author or --committer, it showed commits that mention either A or
+ B (or both) instead.
+
+ * The subcommand to remove the definition of a remote in "git remote"
+ was named "rm" even though all other subcommands were spelled out.
+ Introduce "git remote remove" to remove confusion, and keep "rm" as
+ a backward compatible synonym.
+
+Also contains a handful of documentation updates.
diff --git a/RelNotes/1.7.12.3.adoc b/RelNotes/1.7.12.3.adoc
new file mode 100644
index 0000000..4b82297
--- /dev/null
+++ b/RelNotes/1.7.12.3.adoc
@@ -0,0 +1,34 @@
+Git 1.7.12.3 Release Notes
+==========================
+
+Fixes since v1.7.12.2
+---------------------
+
+ * "git am" mishandled a patch attached as application/octet-stream
+ (e.g. not text/*); Content-Transfer-Encoding (e.g. base64) was not
+ honored correctly.
+
+ * It was unclear in the documentation for "git blame" that it is
+ unnecessary for users to use the "--follow" option.
+
+ * A repository created with "git clone --single" had its fetch
+ refspecs set up just like a clone without "--single", leading the
+ subsequent "git fetch" to slurp all the other branches, defeating
+ the whole point of specifying "only this branch".
+
+ * "git fetch" over http had an old workaround for an unlikely server
+ misconfiguration; it turns out that this hurts debuggability of the
+ configuration in general, and has been reverted.
+
+ * "git fetch" over http advertised that it supports "deflate", which
+ is much less common, and did not advertise the more common "gzip" on
+ its Accept-Encoding header.
+
+ * "git receive-pack" (the counterpart to "git push") did not give
+ progress output while processing objects it received to the user
+ when run over the smart-http protocol.
+
+ * "git status" honored the ignore=dirty settings in .gitmodules but
+ "git commit" didn't.
+
+Also contains a handful of documentation updates.
diff --git a/RelNotes/1.7.12.4.adoc b/RelNotes/1.7.12.4.adoc
new file mode 100644
index 0000000..c6da3cc
--- /dev/null
+++ b/RelNotes/1.7.12.4.adoc
@@ -0,0 +1,23 @@
+Git 1.7.12.4 Release Notes
+==========================
+
+Fixes since v1.7.12.3
+---------------------
+
+ * "git fetch" over the dumb-http revision walker could segfault when
+ curl's multi interface was used.
+
+ * It was possible to give specific paths for "asciidoc" and other
+ tools in the documentation toolchain, but not for "xmlto".
+
+ * "gitweb" did not give the correct committer timezone in its feed
+ output due to a typo.
+
+ * The "-Xours" (and similarly -Xtheirs) backend option to "git
+ merge -s recursive" was ignored for binary files. Now it is
+ honored.
+
+ * The "binary" synthetic attribute made "diff" to treat the path as
+ binary, but not "merge".
+
+Also contains many documentation updates.
diff --git a/RelNotes/1.7.12.adoc b/RelNotes/1.7.12.adoc
new file mode 100644
index 0000000..010d8c7
--- /dev/null
+++ b/RelNotes/1.7.12.adoc
@@ -0,0 +1,136 @@
+Git v1.7.12 Release Notes
+=========================
+
+Updates since v1.7.11
+---------------------
+
+UI, Workflows & Features
+
+ * Git can be told to normalize pathnames it read from readdir(3) and
+ all arguments it got from the command line into precomposed UTF-8
+ (assuming that they come as decomposed UTF-8), in order to work
+ around issues on Mac OS.
+
+ I think there still are other places that need conversion
+ (e.g. paths that are read from stdin for some commands), but this
+ should be a good first step in the right direction.
+
+ * Per-user $HOME/.gitconfig file can optionally be stored in
+ $HOME/.config/git/config instead, which is in line with XDG.
+
+ * The value of core.attributesfile and core.excludesfile default to
+ $HOME/.config/git/attributes and $HOME/.config/git/ignore respectively
+ when these files exist.
+
+ * Logic to disambiguate abbreviated object names have been taught to
+ take advantage of object types that are expected in the context,
+ e.g. XXXXXX in the "git describe" output v1.2.3-gXXXXXX must be a
+ commit object, not a blob nor a tree. This will help us prolong
+ the lifetime of abbreviated object names.
+
+ * "git apply" learned to wiggle the base version and perform three-way
+ merge when a patch does not exactly apply to the version you have.
+
+ * Scripted Porcelain writers now have access to the credential API via
+ the "git credential" plumbing command.
+
+ * "git help" used to always default to "man" format even on platforms
+ where "man" viewer is not widely available.
+
+ * "git clone --local $path" started its life as an experiment to
+ optionally use link/copy when cloning a repository on the disk, but
+ we didn't deprecate it after we made the option a no-op to always
+ use the optimization. The command learned "--no-local" option to
+ turn this off, as a more explicit alternative over use of file://
+ URL.
+
+ * "git fetch" and friends used to say "remote side hung up
+ unexpectedly" when they failed to get response they expect from the
+ other side, but one common reason why they don't get expected
+ response is that the remote repository does not exist or cannot be
+ read. The error message in this case was updated to give better
+ hints to the user.
+
+ * "git help -w $cmd" can show HTML version of documentation for
+ "git-$cmd" by setting help.htmlpath to somewhere other than the
+ default location where the build procedure installs them locally;
+ the variable can even point at a http:// URL.
+
+ * "git rebase [-i] --root $tip" can now be used to rewrite all the
+ history leading to "$tip" down to the root commit.
+
+ * "git rebase -i" learned "-x <cmd>" to insert "exec <cmd>" after
+ each commit in the resulting history.
+
+ * "git status" gives finer classification to various states of paths
+ in conflicted state and offer advice messages in its output.
+
+ * "git submodule" learned to deal with nested submodule structure
+ where a module is contained within a module whose origin is
+ specified as a relative URL to its superproject's origin.
+
+ * A rather heavy-ish "git completion" script has been split to create
+ a separate "git prompting" script, to help lazy-autoloading of the
+ completion part while making prompting part always available.
+
+ * "gitweb" pays attention to various forms of credits that are
+ similar to "Signed-off-by:" lines in the commit objects and
+ highlights them accordingly.
+
+
+Foreign Interface
+
+ * "mediawiki" remote helper (in contrib/) learned to handle file
+ attachments.
+
+ * "git p4" now uses "Jobs:" and "p4 move" when appropriate.
+
+ * vcs-svn has been updated to clean-up compilation, lift 32-bit
+ limitations, etc.
+
+
+Performance, Internal Implementation, etc. (please report possible regressions)
+
+ * Some tests showed false failures caused by a bug in ecryptofs.
+
+ * We no longer use AsciiDoc7 syntax in our documentation and favor a
+ more modern style.
+
+ * "git am --rebasing" codepath was taught to grab authorship, log
+ message and the patch text directly out of existing commits. This
+ will help rebasing commits that have confusing "diff" output in
+ their log messages.
+
+ * "git index-pack" and "git pack-objects" use streaming API to read
+ from the object store to avoid having to hold a large blob object
+ in-core while they are doing their thing.
+
+ * Code to match paths with exclude patterns learned to avoid calling
+ fnmatch() by comparing fixed leading substring literally when
+ possible.
+
+ * "git log -n 1 -- rarely-touched-path" was spending unnecessary
+ cycles after showing the first change to find the next one, only to
+ discard it.
+
+ * "git svn" got a large-looking code reorganization at the last
+ minute before the code freeze.
+
+
+Also contains minor documentation updates and code clean-ups.
+
+
+Fixes since v1.7.11
+-------------------
+
+Unless otherwise noted, all the fixes since v1.7.11 in the maintenance
+releases are contained in this release (see release notes to them for
+details).
+
+ * "git submodule add" was confused when the superproject did not have
+ its repository in its usual place in the working tree and GIT_DIR
+ and GIT_WORK_TREE was used to access it.
+
+ * "git commit --amend" let the user edit the log message and then died
+ when the human-readable committer name was given insufficiently by
+ getpwent(3).
diff --git a/RelNotes/1.7.2.1.adoc b/RelNotes/1.7.2.1.adoc
new file mode 100644
index 0000000..1103c47
--- /dev/null
+++ b/RelNotes/1.7.2.1.adoc
@@ -0,0 +1,25 @@
+Git v1.7.2.1 Release Notes
+==========================
+
+Fixes since v1.7.2
+------------------
+
+ * "git instaweb" wasn't useful when your Apache was installed under a
+ name other than apache2 (e.g. "httpd").
+
+ * Similarly, "git web--browse" (invoked by "git help -w") learned that
+ chrome browser is sometimes called google-chrome.
+
+ * An overlong line after ".gitdir: " in a git file caused out of bounds
+ access to an array on the stack.
+
+ * "git config --path conf.var" to attempt to expand a variable conf.var
+ that uses "~/" short-hand segfaulted when $HOME environment variable
+ was not set.
+
+ * Documentation on Cygwin failed to build.
+
+ * The error message from "git pull blarg" when 'blarg' is an unknown
+ remote name has been improved.
+
+And other minor fixes and documentation updates.
diff --git a/RelNotes/1.7.2.2.adoc b/RelNotes/1.7.2.2.adoc
new file mode 100644
index 0000000..71eb6a8
--- /dev/null
+++ b/RelNotes/1.7.2.2.adoc
@@ -0,0 +1,22 @@
+Git v1.7.2.2 Release Notes
+==========================
+
+Fixes since v1.7.2.1
+--------------------
+
+ * Object transfer over smart http transport deadlocked the client when
+ the remote HTTP server returned a failure, instead of erroring it out.
+
+ * git-gui honors custom textconv filters when showing diff and blame;
+
+ * git diff --relative=subdir (without the necessary trailing /) did not
+ work well;
+
+ * "git diff-files -p --submodule" was recently broken;
+
+ * "git checkout -b n ':/token'" did not work;
+
+ * "git index-pack" (hence "git fetch/clone/pull/push") enabled the object
+ replacement machinery by mistake (it never should have);
+
+And other minor fixes and documentation updates.
diff --git a/RelNotes/1.7.2.3.adoc b/RelNotes/1.7.2.3.adoc
new file mode 100644
index 0000000..610960c
--- /dev/null
+++ b/RelNotes/1.7.2.3.adoc
@@ -0,0 +1,39 @@
+Git v1.7.2.3 Release Notes
+==========================
+
+Fixes since v1.7.2.2
+--------------------
+
+ * When people try insane things such as delta-compressing 4GiB files, we
+ threw an assertion failure.
+
+ * "git archive" gave the full commit ID for "$Format:%h$".
+
+ * "git fetch --tags" did not fetch tags when remote.<nick>.tagopt was set
+ to --no-tags. The command line option now overrides the configuration
+ setting.
+
+ * "git for-each-ref --format='%(objectname:short)'" has been completely
+ broken for a long time.
+
+ * "git gc" incorrectly pruned a rerere record that was created long
+ time ago but still is actively and repeatedly used.
+
+ * "git log --follow -M -p" was seriously broken in 1.7.2, reporting
+ assertion failure.
+
+ * Running "git log" with an incorrect option started pager nevertheless,
+ forcing the user to dismiss it.
+
+ * "git rebase" did not work well when the user has diff.renames
+ configuration variable set.
+
+ * An earlier (and rather old) fix to "git rebase" against a rebased
+ upstream broke a more normal, non rebased upstream case rather badly,
+ attempting to re-apply patches that are already accepted upstream.
+
+ * "git submodule sync" forgot to update the superproject's config file
+ when submodule URL changed.
+
+ * "git pack-refs --all --prune" did not remove a directory that has
+ become empty.
diff --git a/RelNotes/1.7.2.4.adoc b/RelNotes/1.7.2.4.adoc
new file mode 100644
index 0000000..f7950a4
--- /dev/null
+++ b/RelNotes/1.7.2.4.adoc
@@ -0,0 +1,10 @@
+Git v1.7.2.4 Release Notes
+==========================
+
+This is primarily to backport support for the new "add.ignoreErrors"
+name given to the existing "add.ignore-errors" configuration variable.
+
+The next version, Git 1.7.4, and future versions, will support both
+old and incorrect name and the new corrected name, but without this
+backport, users who want to use the new name "add.ignoreErrors" in
+their repositories cannot use older versions of Git.
diff --git a/RelNotes/1.7.2.5.adoc b/RelNotes/1.7.2.5.adoc
new file mode 100644
index 0000000..bf976c4
--- /dev/null
+++ b/RelNotes/1.7.2.5.adoc
@@ -0,0 +1,8 @@
+Git v1.7.2.5 Release Notes
+==========================
+
+Fixes since v1.7.2.4
+--------------------
+
+ * "gitweb" can sometimes be tricked into parrotting a filename argument
+ given in a request without properly quoting.
diff --git a/RelNotes/1.7.2.adoc b/RelNotes/1.7.2.adoc
new file mode 100644
index 0000000..15cf011
--- /dev/null
+++ b/RelNotes/1.7.2.adoc
@@ -0,0 +1,151 @@
+Git v1.7.2 Release Notes
+========================
+
+Updates since v1.7.1
+--------------------
+
+ * core.eol configuration and text/eol attributes are the new way to control
+ the end of line conventions for files in the working tree.
+
+ * core.autocrlf has been made safer - it will now only handle line
+ endings for new files and files that are LF-only in the
+ repository. To normalize content that has been checked in with
+ CRLF, use the new eol/text attributes.
+
+ * The whitespace rules used in "git apply --whitespace" and "git diff"
+ gained a new member in the family (tab-in-indent) to help projects with
+ policy to indent only with spaces.
+
+ * When working from a subdirectory, by default, git does not look for its
+ metadirectory ".git" across filesystems, primarily to help people who
+ have invocations of git in their custom PS1 prompts, as being outside
+ of a git repository would look for ".git" all the way up to the root
+ directory, and NFS mounts are often slow. DISCOVERY_ACROSS_FILESYSTEM
+ environment variable can be used to tell git not to stop at a
+ filesystem boundary.
+
+ * Usage help messages generated by parse-options library (i.e. most
+ of the Porcelain commands) are sent to the standard output now.
+
+ * ':/<string>' notation to look for a commit now takes regular expression
+ and it is not anchored at the beginning of the commit log message
+ anymore (this is a backward incompatible change).
+
+ * "git" wrapper learned "-c name=value" option to override configuration
+ variable from the command line.
+
+ * Improved portability for various platforms including older SunOS,
+ HP-UX 10/11, AIX, Tru64, etc. and platforms with Python 2.4.
+
+ * The message from "git am -3" has been improved when conflict
+ resolution ended up making the patch a no-op.
+
+ * "git blame" applies the textconv filter to the contents it works
+ on, when available.
+
+ * "git checkout --orphan newbranch" is similar to "-b newbranch" but
+ prepares to create a root commit that is not connected to any existing
+ commit.
+
+ * "git cherry-pick" learned to pick a range of commits
+ (e.g. "cherry-pick A..B" and "cherry-pick --stdin"), so did "git
+ revert"; these do not support the nicer sequencing control "rebase
+ [-i]" has, though.
+
+ * "git cherry-pick" and "git revert" learned --strategy option to specify
+ the merge strategy to be used when performing three-way merges.
+
+ * "git cvsserver" can be told to use pserver; its password file can be
+ stored outside the repository.
+
+ * The output from the textconv filter used by "git diff" can be cached to
+ speed up their reuse.
+
+ * "git diff --word-diff=<mode>" extends the existing "--color-words"
+ option, making it more useful in color-challenged environments.
+
+ * The regexp to detect function headers used by "git diff" for PHP has
+ been enhanced for visibility modifiers (public, protected, etc.) to
+ better support PHP5.
+
+ * "diff.noprefix" configuration variable can be used to implicitly
+ ask for "diff --no-prefix" behaviour.
+
+ * "git for-each-ref" learned "%(objectname:short)" that gives the object
+ name abbreviated.
+
+ * "git format-patch" learned --signature option and format.signature
+ configuration variable to customize the e-mail signature used in the
+ output.
+
+ * Various options to "git grep" (e.g. --count, --name-only) work better
+ with binary files.
+
+ * "git grep" learned "-Ovi" to open the files with hits in your editor.
+
+ * "git help -w" learned "chrome" and "chromium" browsers.
+
+ * "git log --decorate" shows commit decorations in various colours.
+
+ * "git log --follow <path>" follows across copies (it used to only follow
+ renames). This may make the processing more expensive.
+
+ * "git log --pretty=format:<template>" specifier learned "% <something>"
+ magic that inserts a space only when %<something> expands to a
+ non-empty string; this is similar to "%+<something>" magic, but is
+ useful in a context to generate a single line output.
+
+ * "git notes prune" learned "-n" (dry-run) and "-v" options, similar to
+ what "git prune" has.
+
+ * "git patch-id" can be fed a mbox without getting confused by the
+ signature line in the format-patch output.
+
+ * "git remote" learned "set-branches" subcommand.
+
+ * "git rev-list A..B" learned --ancestry-path option to further limit
+ the result to the commits that are on the ancestry chain between A and
+ B (i.e. commits that are not descendants of A are excluded).
+
+ * "git show -5" is equivalent to "git show --do-walk 5"; this is similar
+ to the update to make "git show master..next" walk the history,
+ introduced in 1.6.4.
+
+ * "git status [-s] --ignored" can be used to list ignored paths.
+
+ * "git status -s -b" shows the current branch in the output.
+
+ * "git status" learned "--ignore-submodules" option.
+
+ * Various "gitweb" enhancements and clean-ups, including syntax
+ highlighting, "plackup" support for instaweb, .fcgi suffix to run
+ it as FastCGI script, etc.
+
+ * The test harness has been updated to produce TAP-friendly output.
+
+ * Many documentation improvement patches are also included.
+
+
+Fixes since v1.7.1
+------------------
+
+All of the fixes in v1.7.1.X maintenance series are included in this
+release, unless otherwise noted.
+
+ * We didn't URL decode "file:///path/to/repo" correctly when path/to/repo
+ had percent-encoded characters (638794c, 9d2e942, ce83eda, 3c73a1d).
+
+ * "git clone" did not configure remote.origin.url correctly for bare
+ clones (df61c889).
+
+ * "git diff --graph" works better with "--color-words" and other options
+ (81fa024..4297c0a).
+
+ * "git diff" could show ambiguous abbreviation of blob object names on
+ its "index" line (3e5a188).
+
+ * "git reset --hard" started from a wrong directory and a working tree in
+ a nonstandard location is in use got confused (560fb6a1).
+
+ * "git read-tree -m A B" used to switch to branch B while retaining
+ local changes added an incorrect cache-tree information (b1f47514).
diff --git a/RelNotes/1.7.3.1.adoc b/RelNotes/1.7.3.1.adoc
new file mode 100644
index 0000000..002c93b
--- /dev/null
+++ b/RelNotes/1.7.3.1.adoc
@@ -0,0 +1,14 @@
+Git v1.7.3.1 Release Notes
+==========================
+
+Fixes since v1.7.3
+------------------
+
+ * "git stash show stash@{$n}" was accidentally broken in 1.7.3 ("git
+ stash show" without any argument still worked, though).
+
+ * "git stash branch $branch stash@{$n}" was accidentally broken in
+ 1.7.3 and started dropping the named stash even when branch creation
+ failed.
+
+And other minor fixes and documentation updates.
diff --git a/RelNotes/1.7.3.2.adoc b/RelNotes/1.7.3.2.adoc
new file mode 100644
index 0000000..5c93b85
--- /dev/null
+++ b/RelNotes/1.7.3.2.adoc
@@ -0,0 +1,5 @@
+Git v1.7.3.2 Release Notes
+==========================
+
+This is primarily to push out many documentation fixes accumulated since
+the 1.7.3.1 release.
diff --git a/RelNotes/1.7.3.3.adoc b/RelNotes/1.7.3.3.adoc
new file mode 100644
index 0000000..9b2b244
--- /dev/null
+++ b/RelNotes/1.7.3.3.adoc
@@ -0,0 +1,54 @@
+Git v1.7.3.3 Release Notes
+==========================
+
+In addition to the usual fixes, this release also includes support for
+the new "add.ignoreErrors" name given to the existing "add.ignore-errors"
+configuration variable.
+
+The next version, Git 1.7.4, and future versions, will support both
+old and incorrect name and the new corrected name, but without this
+backport, users who want to use the new name "add.ignoreErrors" in
+their repositories cannot use older versions of Git.
+
+Fixes since v1.7.3.2
+--------------------
+
+ * "git apply" segfaulted when a bogus input is fed to it.
+
+ * Running "git cherry-pick --ff" on a root commit segfaulted.
+
+ * "diff", "blame" and friends incorrectly applied textconv filters to
+ symlinks.
+
+ * Highlighting of whitespace breakage in "diff" output was showing
+ incorrect amount of whitespaces when blank-at-eol is set and the line
+ consisted only of whitespaces and a TAB.
+
+ * "diff" was overly inefficient when trying to find the line to use for
+ the function header (i.e. equivalent to --show-c-function of GNU diff).
+
+ * "git imap-send" depends on libcrypto but our build rule relied on the
+ linker to implicitly link it via libssl, which was wrong.
+
+ * "git merge-file" can be called from within a subdirectory now.
+
+ * "git repack -f" expanded and recompressed non-delta objects in the
+ existing pack, which was wasteful. Use new "-F" option if you really
+ want to (e.g. when changing the pack.compression level).
+
+ * "git rev-list --format="...%x00..." incorrectly chopped its output
+ at NUL.
+
+ * "git send-email" did not correctly remove duplicate mail addresses from
+ the Cc: header that appear on the To: header.
+
+ * The completion script (in contrib/completion) ignored lightweight tags
+ in __git_ps1().
+
+ * "git-blame" mode (in contrib/emacs) didn't say (require 'format-spec)
+ even though it depends on it; it didn't work with Emacs 22 or older
+ unless Gnus is used.
+
+ * "git-p4" (in contrib/) did not correctly handle deleted files.
+
+Other minor fixes and documentation updates are also included.
diff --git a/RelNotes/1.7.3.4.adoc b/RelNotes/1.7.3.4.adoc
new file mode 100644
index 0000000..e57f7c1
--- /dev/null
+++ b/RelNotes/1.7.3.4.adoc
@@ -0,0 +1,45 @@
+Git v1.7.3.4 Release Notes
+==========================
+
+Fixes since v1.7.3.3
+--------------------
+
+ * Smart HTTP transport used to incorrectly retry redirected POST
+ request with GET request.
+
+ * "git apply" did not correctly handle patches that only change modes
+ if told to apply while stripping leading paths with -p option.
+
+ * "git apply" can deal with patches with timezone formatted with a
+ colon between the hours and minutes part (e.g. "-08:00" instead of
+ "-0800").
+
+ * "git checkout" removed an untracked file "foo" from the working
+ tree when switching to a branch that contains a tracked path
+ "foo/bar". Prevent this, just like the case where the conflicting
+ path were "foo" (c752e7f..7980872d).
+
+ * "git cherry-pick" or "git revert" refused to work when a path that
+ would be modified by the operation was stat-dirty without a real
+ difference in the contents of the file.
+
+ * "git diff --check" reported an incorrect line number for added
+ blank lines at the end of file.
+
+ * "git imap-send" failed to build under NO_OPENSSL.
+
+ * Setting log.decorate configuration variable to "0" or "1" to mean
+ "false" or "true" did not work.
+
+ * "git push" over dumb HTTP protocol did not work against WebDAV
+ servers that did not terminate a collection name with a slash.
+
+ * "git tag -v" did not work with GPG signatures in rfc1991 mode.
+
+ * The post-receive-email sample hook was accidentally broken in 1.7.3.3
+ update.
+
+ * "gitweb" can sometimes be tricked into parrotting a filename argument
+ given in a request without properly quoting.
+
+Other minor fixes and documentation updates are also included.
diff --git a/RelNotes/1.7.3.5.adoc b/RelNotes/1.7.3.5.adoc
new file mode 100644
index 0000000..40f3ba5
--- /dev/null
+++ b/RelNotes/1.7.3.5.adoc
@@ -0,0 +1,34 @@
+Git 1.7.3.5 Release Notes
+=========================
+
+ * The xfuncname pattern used by "git diff" and "git grep" to show the
+ last notable line in context were broken for python and ruby for a long
+ time.
+
+ * "git merge" into an unborn branch removed an untracked file "foo" from
+ the working tree when merged branch had "foo" (this fix was already in
+ 1.7.3.3 but was omitted from the release notes by mistake).
+
+ * "git status -s" did not quote unprintable characters in paths as
+ documented.
+
+ * "git am --abort" used to always reset to the commit at the beginning of
+ the last "am" invocation that has stopped, losing any unrelated commits
+ that may have been made since then. Now it refrains from doing so and
+ instead issues a warning.
+
+ * "git blame" incorrectly reused bogusly cached result of textconv
+ filter for files from the working tree.
+
+ * "git commit" used to abort after the user edited the log message
+ when the committer information was not correctly set up. It now
+ aborts before starting the editor.
+
+ * "git commit --date=invalid" used to silently ignore the incorrectly
+ specified date; it is now diagnosed as an error.
+
+ * "git rebase --skip" to skip the last commit in a series used to fail
+ to run post-rewrite hook and to copy notes from old commits that have
+ successfully been rebased so far. Now it do (backmerge ef88ad2).
+
+ * "gitweb" tried to show a wrong feed logo when none was specified.
diff --git a/RelNotes/1.7.3.adoc b/RelNotes/1.7.3.adoc
new file mode 100644
index 0000000..309c331
--- /dev/null
+++ b/RelNotes/1.7.3.adoc
@@ -0,0 +1,76 @@
+Git v1.7.3 Release Notes
+========================
+
+Updates since v1.7.2
+--------------------
+
+ * git-gui, now at version 0.13.0, got various updates and a new
+ maintainer, Pat Thoyts.
+
+ * Gitweb allows its configuration to change per each request; it used to
+ read the configuration once upon startup.
+
+ * When git finds a corrupt object, it now reports the file that contains
+ it.
+
+ * "git checkout -B <it>" is a shorter way to say "git branch -f <it>"
+ followed by "git checkout <it>".
+
+ * When "git checkout" or "git merge" refuse to proceed in order to
+ protect local modification to your working tree, they used to stop
+ after showing just one path that might be lost. They now show all,
+ in a format that is easier to read.
+
+ * "git clean" learned "-e" ("--exclude") option.
+
+ * Hunk headers produced for C# files by "git diff" and friends show more
+ relevant context than before.
+
+ * diff.ignoresubmodules configuration variable can be used to squelch the
+ differences in submodules reported when running commands (e.g. "diff",
+ "status", etc.) at the superproject level.
+
+ * http.useragent configuration can be used to lie who you are to your
+ restrictive firewall.
+
+ * "git rebase --strategy <s>" learned "-X" option to pass extra options
+ that are understood by the chosen merge strategy.
+
+ * "git rebase -i" learned "exec" that you can insert into the insn sheet
+ to run a command between its steps.
+
+ * "git rebase" between branches that have many binary changes that do
+ not conflict should be faster.
+
+ * "git rebase -i" peeks into rebase.autosquash configuration and acts as
+ if you gave --autosquash from the command line.
+
+
+Also contains various documentation updates.
+
+
+Fixes since v1.7.2
+------------------
+
+All of the fixes in v1.7.2.X maintenance series are included in this
+release, unless otherwise noted.
+
+ * "git merge -s recursive" (which is the default) did not handle cases
+ where a directory becomes a file (or vice versa) very well.
+
+ * "git fetch" and friends were accidentally broken for url with "+" in
+ its path, e.g. "git://git.gnome.org/gtk+".
+
+ * "git fetch $url" (i.e. without refspecs) was broken for quite some
+ time, if the current branch happen to be tracking some remote.
+
+ * "git ls-tree dir dirgarbage", when "dir" was a directory,
+ incorrectly recursed into "dir".
+
+ * "git note remove" created unnecessary extra commit when named object
+ did not have any note to begin with.
+
+ * "git rebase" did not work well if you had diff.noprefix configured.
+
+ * "git -c foo=bar subcmd" did not work well for subcmd that is not
+ implemented as a built-in command.
diff --git a/RelNotes/1.7.4.1.adoc b/RelNotes/1.7.4.1.adoc
new file mode 100644
index 0000000..79923a6
--- /dev/null
+++ b/RelNotes/1.7.4.1.adoc
@@ -0,0 +1,27 @@
+Git v1.7.4.1 Release Notes
+==========================
+
+Fixes since v1.7.4
+------------------
+
+ * On Windows platform, the codepath to spawn a new child process forgot
+ to first flush the output buffer.
+
+ * "git bundle" did not use OFS_DELTA encoding, making its output a few
+ per-cent larger than necessarily.
+
+ * The option to tell "git clone" to recurse into the submodules was
+ misspelled with an underscore "--recurse_submodules".
+
+ * "git diff --cached HEAD" before the first commit does what an end user
+ would expect (namely, show what would be committed without further "git
+ add").
+
+ * "git fast-import" didn't accept the command to ask for "notes" feature
+ to be present in its input stream, even though it was capable of the
+ feature.
+
+ * "git fsck" gave up scanning loose object files in directories with
+ garbage files.
+
+And other minor fixes and documentation updates.
diff --git a/RelNotes/1.7.4.2.adoc b/RelNotes/1.7.4.2.adoc
new file mode 100644
index 0000000..ef4ce1f
--- /dev/null
+++ b/RelNotes/1.7.4.2.adoc
@@ -0,0 +1,58 @@
+Git v1.7.4.2 Release Notes
+==========================
+
+Fixes since v1.7.4.1
+--------------------
+
+ * Many documentation updates to match "git cmd -h" output and the
+ git-cmd manual page.
+
+ * We used to keep one file descriptor open for each and every packfile
+ that we have a mmap window on it (read: "in use"), even when for very
+ tiny packfiles. We now close the file descriptor early when the entire
+ packfile fits inside one mmap window.
+
+ * "git bisect visualize" tried to run "gitk" in windowing
+ environments even when "gitk" is not installed, resulting in a
+ strange error message.
+
+ * "git clone /no/such/path" did not fail correctly.
+
+ * "git commit" did not correctly error out when the user asked to use a
+ non existent file as the commit message template.
+
+ * "git diff --stat -B" ran on binary files counted the changes in lines,
+ which was nonsensical.
+
+ * "git diff -M" opportunistically detected copies, which was not
+ necessarily a good thing, especially when it is internally run by
+ recursive merge.
+
+ * "git difftool" didn't tell (g)vimdiff that the files it is reading are
+ to be opened read-only.
+
+ * "git merge" didn't pay attention to prepare-commit-msg hook, even
+ though if a merge is conflicted and manually resolved, the subsequent
+ "git commit" would have triggered the hook, which was inconsistent.
+
+ * "git patch-id" (and commands like "format-patch --ignore-in-upstream"
+ that use it as their internal logic) handled changes to files that end
+ with incomplete lines incorrectly.
+
+ * The official value to tell "git push" to push the current branch back
+ to update the upstream branch it forked from is now called "upstream".
+ The old name "tracking" is and will be supported.
+
+ * "git submodule update" used to honor the --merge/--rebase option (or
+ corresponding configuration variables) even for a newly cloned
+ subproject, which made no sense (so/submodule-no-update-first-time).
+
+ * gitweb's "highlight" interface mishandled tabs.
+
+ * gitweb didn't understand timezones with GMT offset that is not
+ multiple of a whole hour.
+
+ * gitweb had a few forward-incompatible syntactic constructs and
+ also used incorrect variable when showing the file mode in a diff.
+
+And other minor fixes and documentation updates.
diff --git a/RelNotes/1.7.4.3.adoc b/RelNotes/1.7.4.3.adoc
new file mode 100644
index 0000000..02a3d5b
--- /dev/null
+++ b/RelNotes/1.7.4.3.adoc
@@ -0,0 +1,32 @@
+Git v1.7.4.3 Release Notes
+==========================
+
+Fixes since v1.7.4.2
+--------------------
+
+ * "git apply" used to confuse lines updated by previous hunks as lines
+ that existed before when applying a hunk, contributing misapplication
+ of patches with offsets.
+
+ * "git branch --track" (and "git checkout --track --branch") used to
+ allow setting up a random non-branch that does not make sense to follow
+ as the "upstream". The command correctly diagnoses it as an error.
+
+ * "git checkout $other_branch" silently removed untracked symbolic links
+ in the working tree that are in the way in order to check out paths
+ under it from the named branch.
+
+ * "git cvsimport" did not bail out immediately when the cvs server cannot
+ be reached, spewing unnecessary error messages that complain about the
+ server response that it never got.
+
+ * "git diff --quiet" did not work very well with the "--diff-filter"
+ option.
+
+ * "git grep -n" lacked a long-hand synonym --line-number.
+
+ * "git stash apply" reported the result of its operation by running
+ "git status" from the top-level of the working tree; it should (and
+ now does) run it from the user's working directory.
+
+And other minor fixes and documentation updates.
diff --git a/RelNotes/1.7.4.4.adoc b/RelNotes/1.7.4.4.adoc
new file mode 100644
index 0000000..ff06e04
--- /dev/null
+++ b/RelNotes/1.7.4.4.adoc
@@ -0,0 +1,35 @@
+Git v1.7.4.4 Release Notes
+==========================
+
+Fixes since v1.7.4.3
+--------------------
+
+ * Compilation of sha1_file.c on BSD platforms were broken due to our
+ recent use of getrlimit() without including <sys/resource.h>.
+
+ * "git config" did not diagnose incorrect configuration variable names.
+
+ * "git format-patch" did not wrap a long subject line that resulted from
+ rfc2047 encoding.
+
+ * "git instaweb" should work better again with plackup.
+
+ * "git log --max-count=4 -Sfoobar" now shows 4 commits that changes the
+ number of occurrences of string "foobar"; it used to scan only for 4
+ commits and then emitted only matching ones.
+
+ * "git log --first-parent --boundary $c^..$c" segfaulted on a merge.
+
+ * "git pull" into an empty branch should have behaved as if
+ fast-forwarding from emptiness to the version being pulled, with
+ the usual protection against overwriting untracked files.
+
+ * "git submodule" that is run while a merge in the superproject is in
+ conflicted state tried to process each conflicted submodule up to
+ three times.
+
+ * "git status" spent all the effort to notice racily-clean index entries
+ but didn't update the index file to help later operations go faster in
+ some cases.
+
+And other minor fixes and documentation updates.
diff --git a/RelNotes/1.7.4.5.adoc b/RelNotes/1.7.4.5.adoc
new file mode 100644
index 0000000..b7a0eeb
--- /dev/null
+++ b/RelNotes/1.7.4.5.adoc
@@ -0,0 +1,4 @@
+Git v1.7.4.5 Release Notes
+==========================
+
+This contains only minor documentation fixes accumulated since 1.7.4.4.
diff --git a/RelNotes/1.7.4.adoc b/RelNotes/1.7.4.adoc
new file mode 100644
index 0000000..d5bca73
--- /dev/null
+++ b/RelNotes/1.7.4.adoc
@@ -0,0 +1,156 @@
+Git v1.7.4 Release Notes
+========================
+
+Updates since v1.7.3
+--------------------
+
+ * The documentation Makefile now assumes by default asciidoc 8 and
+ docbook-xsl >= 1.73. If you have older versions, you can set
+ ASCIIDOC7 and ASCIIDOC_ROFF, respectively.
+
+ * The option parsers of various commands that create new branches (or
+ rename existing ones to a new name) were too loose and users were
+ allowed to give a branch a name that begins with a dash by creative
+ abuse of their command line options, which only led to burning
+ themselves. The name of a branch cannot begin with a dash now.
+
+ * System-wide fallback default attributes can be stored in
+ /etc/gitattributes; the core.attributesfile configuration variable can
+ be used to customize the path to this file.
+
+ * The thread structure generated by "git send-email" has changed
+ slightly. Setting the cover letter of the latest series as a reply
+ to the cover letter of the previous series with --in-reply-to used
+ to make the new cover letter and all the patches replies to the
+ cover letter of the previous series; this has been changed to make
+ the patches in the new series replies to the new cover letter.
+
+ * The Bash completion script in contrib/ has been adjusted to be usable with
+ Bash 4 (options with '=value' didn't complete). It has been also made
+ usable with zsh.
+
+ * Different pagers can be chosen depending on which subcommand is
+ being run under the pager, using the "pager.<subcommand>" variable.
+
+ * The hardcoded tab-width of 8 that is used in whitespace breakage checks is now
+ configurable via the attributes mechanism.
+
+ * Support of case insensitive filesystems (i.e. "core.ignorecase") has
+ been improved. For example, the gitignore mechanism didn't pay attention
+ to case insensitivity.
+
+ * The <tree>:<path> syntax for naming a blob in a tree, and the :<path>
+ syntax for naming a blob in the index (e.g. "master:Makefile",
+ ":hello.c") have been extended. You can start <path> with "./" to
+ implicitly have the (sub)directory you are in prefixed to the
+ lookup. Similarly, ":../Makefile" from a subdirectory would mean
+ "the Makefile of the parent directory in the index".
+
+ * "git blame" learned the --show-email option to display the e-mail
+ addresses instead of the names of authors.
+
+ * "git commit" learned the --fixup and --squash options to help later invocation
+ of interactive rebase.
+
+ * Command line options to "git cvsimport" whose names are in capital
+ letters (-A, -M, -R and -S) can now be specified as the default in
+ the .git/config file by their longer names (cvsimport.authorsFile,
+ cvsimport.mergeRegex, cvsimport.trackRevisions, cvsimport.ignorePaths).
+
+ * "git daemon" can be built in the MinGW environment.
+
+ * "git daemon" can take more than one --listen option to listen to
+ multiple addresses.
+
+ * "git describe --exact-match" was optimized not to read commit
+ objects unnecessarily.
+
+ * "git diff" and "git grep" learned what functions and subroutines
+ in Fortran, Pascal and Perl look like.
+
+ * "git fetch" learned the "--recurse-submodules" option.
+
+ * "git mergetool" tells vim/gvim to show a three-way diff by default
+ (use vimdiff2/gvimdiff2 as the tool name for old behavior).
+
+ * "git log -G<pattern>" limits the output to commits whose change has
+ added or deleted lines that match the given pattern.
+
+ * "git read-tree" with no argument as a way to empty the index is
+ deprecated; we might want to remove it in the future. Users can
+ use the new --empty option to be more explicit instead.
+
+ * "git repack -f" does not spend cycles to recompress objects in the
+ non-delta representation anymore (use -F if you really mean it
+ e.g. after you changed the core.compression variable setting).
+
+ * "git merge --log" used to limit the resulting merge log to 20
+ entries; this is now customizable by giving e.g. "--log=47".
+
+ * "git merge" may work better when all files were moved out of a
+ directory in one branch while a new file is created in place of that
+ directory in the other branch.
+
+ * "git merge" learned the "--abort" option, synonymous to
+ "git reset --merge" when a merge is in progress.
+
+ * "git notes" learned the "merge" subcommand to merge notes refs.
+ In addition to the default manual conflict resolution, there are
+ also several notes merge strategies for automatically resolving
+ notes merge conflicts.
+
+ * "git rebase --autosquash" can use SHA-1 object names to name the
+ commit which is to be fixed up (e.g. "fixup! e83c5163").
+
+ * The default "recursive" merge strategy learned the --rename-threshold
+ option to influence the rename detection, similar to the -M option
+ of "git diff". From the "git merge" frontend, the "-X<strategy option>"
+ interface, e.g. "git merge -Xrename-threshold=50% ...", can be used
+ to trigger this.
+
+ * The "recursive" strategy also learned to ignore various whitespace
+ changes; the most notable is -Xignore-space-at-eol.
+
+ * "git send-email" learned "--to-cmd", similar to "--cc-cmd", to read
+ the recipient list from a command output.
+
+ * "git send-email" learned to read and use "To:" from its input files.
+
+ * you can extend "git shell", which is often used on boxes that allow
+ git-only login over ssh as login shell, with a custom set of
+ commands.
+
+ * The current branch name in "git status" output can be colored differently
+ from the generic header color by setting the "color.status.branch" variable.
+
+ * "git submodule sync" updates metainformation for all submodules,
+ not just the ones that have been checked out.
+
+ * gitweb can use a custom 'highlight' command with its configuration file.
+
+ * other gitweb updates.
+
+
+Also contains various documentation updates.
+
+
+Fixes since v1.7.3
+------------------
+
+All of the fixes in the v1.7.3.X maintenance series are included in this
+release, unless otherwise noted.
+
+ * "git log --author=me --author=her" did not find commits written by
+ me or by her; instead it looked for commits written by me and by
+ her, which is impossible.
+
+ * "git push --progress" shows progress indicators now.
+
+ * "git rebase -i" showed a confusing error message when given a
+ branch name that does not exist.
+
+ * "git repack" places its temporary packs under $GIT_OBJECT_DIRECTORY/pack
+ instead of $GIT_OBJECT_DIRECTORY/ to avoid cross directory renames.
+
+ * "git submodule update --recursive --other-flags" passes flags down
+ to its subinvocations.
diff --git a/RelNotes/1.7.5.1.adoc b/RelNotes/1.7.5.1.adoc
new file mode 100644
index 0000000..c6ebd76
--- /dev/null
+++ b/RelNotes/1.7.5.1.adoc
@@ -0,0 +1,47 @@
+Git v1.7.5.1 Release Notes
+==========================
+
+Fixes since v1.7.5
+------------------
+
+ * When an object "$tree:$path" does not exist, if $path does exist in the
+ subtree of $tree that corresponds to the subdirectory the user is in,
+ git now suggests using "$tree:./$path" in addition to the advice to use
+ the full path from the root of the working tree.
+
+ * The "--date=relative" output format used to say "X years, 12 months"
+ when it should have said "X+1 years".
+
+ * The smart-HTTP transfer was broken in 1.7.5 when the client needs
+ to issue a small POST (which uses content-length) and then a large
+ POST (which uses chunked) back to back.
+
+ * "git clean" used to fail on an empty directory that is not readable,
+ even though rmdir(2) could remove such a directory. Now we attempt it
+ as the last resort.
+
+ * The "--dirstat" option of "diff" family of commands used to totally
+ ignore a change that only rearranged lines within a file. Such a
+ change now counts as at least a minimum but non zero change.
+
+ * The "--dirstat" option of "diff" family of commands used to use the
+ pathname in the original, instead of the pathname in the result,
+ when renames are involved.
+
+ * "git pack-object" did not take core.bigfilethreashold into account
+ (unlike fast-import); now it does.
+
+ * "git reflog" ignored options like "--format=.." on the command line.
+
+ * "git stash apply" used to refuse to work if there was any change in
+ the working tree, even when the change did not overlap with the change
+ the stash recorded.
+
+ * "git stash apply @{99999}" was not diagnosed as an error, even when you
+ did not have that many stash entries.
+
+ * An error message from "git send-email" to diagnose a broken SMTP
+ connection configuration lacked a space between "hello=<smtp-domain>"
+ and "port=<smtp-server-port>".
+
+And other minor fixes and documentation updates.
diff --git a/RelNotes/1.7.5.2.adoc b/RelNotes/1.7.5.2.adoc
new file mode 100644
index 0000000..951eb7c
--- /dev/null
+++ b/RelNotes/1.7.5.2.adoc
@@ -0,0 +1,57 @@
+Git v1.7.5.2 Release Notes
+==========================
+
+The release notes to 1.7.5.1 forgot to mention:
+
+ * "git stash -p --no-keep-index" and "git stash --no-keep-index -p" now
+ mean the same thing.
+
+ * "git upload-pack" (hence "git push" over git native protocol) had a
+ subtle race condition that could lead to a deadlock.
+
+Fixes since v1.7.5.1
+--------------------
+
+ * "git add -p" did not work correctly when a hunk is split and then
+ one of them was given to the editor.
+
+ * "git add -u" did not resolve a conflict where our history deleted and
+ their history modified the same file, and the working tree resolved to
+ keep a file.
+
+ * "git cvsimport" did not know that CVSNT stores its password file in a
+ location different from the traditional CVS.
+
+ * "git diff-files" did not show the mode information from the working
+ tree side of an unmerged path correctly.
+
+ * "git diff -M --cached" used to use unmerged path as a possible rename
+ source candidate, which made no sense.
+
+ * The option name parser in "git fast-import" used prefix matches for
+ some options where it shouldn't, and accepted non-existent options,
+ e.g. "--relative-marksmith" or "--forceps".
+
+ * "git format-patch" did not quote RFC822 special characters in the
+ email address (e.g From: Junio C. Hamano <jch@example.com>, not
+ From: "Junio C. Hamano" <jch@example.com>).
+
+ * "git format-patch" when run with "--quiet" option used to produce a
+ nonsense result that consists of alternating empty output.
+
+ * In "git merge", per-branch branch.<name>.mergeoptions configuration
+ variables did not override the fallback default merge.<option>
+ configuration variables such as merge.ff, merge.log, etc.
+
+ * "git merge-one-file" did not honor GIT_WORK_TREE settings when
+ handling a "both sides added, differently" conflict.
+
+ * "git mergetool" did not handle conflicted submoudules gracefully.
+
+ * "git-p4" (in contrib) used a wrong base image while merge a file that
+ was added on both branches differently.
+
+ * "git rebase -i -p" failed to preserve the history when there is a
+ redundant merge created with the --no-ff option.
+
+And other minor fixes and documentation updates.
diff --git a/RelNotes/1.7.5.3.adoc b/RelNotes/1.7.5.3.adoc
new file mode 100644
index 0000000..1d24edc
--- /dev/null
+++ b/RelNotes/1.7.5.3.adoc
@@ -0,0 +1,32 @@
+Git v1.7.5.3 Release Notes
+==========================
+
+Fixes since v1.7.5.2
+--------------------
+
+ * The bash completion scripts should correctly work using zsh's bash
+ completion emulation layer now.
+
+ * Setting $(prefix) in config.mak did not affect where etc/gitconfig
+ file is read from, even though passing it from the command line of
+ $(MAKE) did.
+
+ * The logic to handle "&" (expand to UNIX username) in GECOS field
+ miscounted the length of the name it formatted.
+
+ * "git cherry-pick -s resolve" failed to cherry-pick a root commit.
+
+ * "git diff --word-diff" misbehaved when diff.suppress-blank-empty was
+ in effect.
+
+ * "git log --stdin path" with an input that has additional pathspec
+ used to corrupt memory.
+
+ * "git send-pack" (hence "git push") over smart-HTTP protocol could
+ deadlock when the client side pack-object died early.
+
+ * Compressed tarball gitweb generates used to be made with the timestamp
+ of the tarball generation; this was bad because snapshot from the same
+ tree should result in a same tarball.
+
+And other minor fixes and documentation updates.
diff --git a/RelNotes/1.7.5.4.adoc b/RelNotes/1.7.5.4.adoc
new file mode 100644
index 0000000..7796df3
--- /dev/null
+++ b/RelNotes/1.7.5.4.adoc
@@ -0,0 +1,21 @@
+Git v1.7.5.4 Release Notes
+==========================
+
+Fixes since v1.7.5.3
+--------------------
+
+ * The single-key mode of "git add -p" was easily fooled into thinking
+ that it was told to add everything ('a') when up-arrow was pressed by
+ mistake.
+
+ * Setting a git command that uses custom configuration via "-c var=val"
+ as an alias caused a crash due to a realloc(3) failure.
+
+ * "git diff -C -C" used to disable the rename detection entirely when
+ there are too many copy candidate paths in the tree; now it falls
+ back to "-C" when doing so would keep the copy candidate paths
+ under the rename detection limit.
+
+ * "git rerere" did not diagnose a corrupt MERGE_RR file in some cases.
+
+And other minor fixes and documentation updates.
diff --git a/RelNotes/1.7.5.adoc b/RelNotes/1.7.5.adoc
new file mode 100644
index 0000000..987919c
--- /dev/null
+++ b/RelNotes/1.7.5.adoc
@@ -0,0 +1,132 @@
+Git v1.7.5 Release Notes
+========================
+
+Updates since v1.7.4
+--------------------
+
+ * Various MinGW portability fixes.
+
+ * Various git-p4 enhancements (in contrib).
+
+ * Various vcs-svn, git-svn and gitk enhancements and fixes.
+
+ * Various git-gui updates (0.14.0).
+
+ * Update to more modern HP-UX port.
+
+ * The codebase is getting prepared for i18n/l10n; no translated
+ strings nor translation mechanism in the code yet, but the strings
+ are being marked for l10n.
+
+ * The bash completion script can now complete symmetric difference
+ for "git diff" command, e.g. "git diff ...bra<TAB>".
+
+ * The default minimum length of abbreviated and unique object names
+ can now be configured by setting the core.abbrev configuration
+ variable.
+
+ * "git apply -v" reports offset lines when the patch does not apply at
+ the exact location recorded in the diff output.
+
+ * "git config" used to be also known as "git repo-config", but the old
+ name is now officially deprecated.
+
+ * "git checkout --detach <commit>" is a more user friendly synonym for
+ "git checkout <commit>^0".
+
+ * "git checkout" performed on detached HEAD gives a warning and
+ advice when the commit being left behind will become unreachable from
+ any branch or tag.
+
+ * "git cherry-pick" and "git revert" can be told to use a custom merge
+ strategy, similar to "git rebase".
+
+ * "git cherry-pick" remembers which commit failed to apply when it is
+ stopped by conflicts, making it unnecessary to use "commit -c $commit"
+ to conclude it.
+
+ * "git cvsimport" bails out immediately when the cvs server cannot be
+ reached, without spewing unnecessary error messages that complain about
+ the server response it never got.
+
+ * "git fetch" vs "git upload-pack" transfer learned 'no-done'
+ protocol extension to save one round-trip after the content
+ negotiation is done. This saves one HTTP RPC, reducing the overall
+ latency for a trivial fetch.
+
+ * "git fetch" can be told to recursively fetch submodules on-demand.
+
+ * "git grep -f <filename>" learned to treat "-" as "read from the
+ standard input stream".
+
+ * "git grep --no-index" did not honor pathspecs correctly, returning
+ paths outside the specified area.
+
+ * "git init" learned the --separate-git-dir option to allow the git
+ directory for a new repository created elsewhere and linked via the
+ gitdir mechanism. This is primarily to help submodule support later
+ to switch between a branch of superproject that has the submodule
+ and another that does not.
+
+ * "git log" type commands now understand globbing pathspecs. You
+ can say "git log -- '*.txt'" for example.
+
+ * "git log" family of commands learned --cherry and --cherry-mark
+ options that can be used to view two diverged branches while omitting
+ or highlighting equivalent changes that appear on both sides of a
+ symmetric difference (e.g. "log --cherry A...B").
+
+ * A lazy "git merge" that didn't say what to merge used to be an error.
+ When run on a branch that has an upstream defined, however, the command
+ now merges from the configured upstream.
+
+ * "git mergetool" learned how to drive "beyond compare 3" as well.
+
+ * "git rerere forget" without pathspec used to forget all the saved
+ conflicts that relate to the current merge; it now requires you to
+ give it pathspecs.
+
+ * "git rev-list --objects $revs -- $pathspec" now limits the objects listed
+ in its output properly with the pathspec, in preparation for narrow
+ clones.
+
+ * "git push" with no parameters gives better advice messages when
+ "tracking" is used as the push.default semantics or there is no remote
+ configured yet.
+
+ * A possible value to the "push.default" configuration variable,
+ 'tracking', gained a synonym that more naturally describes what it
+ does, 'upstream'.
+
+ * "git rerere" learned a new subcommand "remaining" that is similar to
+ "status" and lists the paths that had conflicts which are known to
+ rerere, but excludes the paths that have already been marked as
+ resolved in the index from its output. "git mergetool" has been
+ updated to use this facility.
+
+Also contains various documentation updates.
+
+
+Fixes since v1.7.4
+------------------
+
+All of the fixes in the v1.7.4.X maintenance series are included in this
+release, unless otherwise noted.
+
+ * "git fetch" from a client that is mostly following the remote
+ needlessly told all of its refs to the server for both sides to
+ compute the set of objects that need to be transferred efficiently,
+ instead of stopping when the server heard enough. In a project with
+ many tags, this turns out to be extremely wasteful, especially over
+ the smart HTTP transport (sp/maint-{upload,fetch}-pack-stop-early~1).
+
+ * "git fetch" run from a repository that uses the same repository as
+ its alternate object store as the repository it is fetching from
+ did not tell the server that it already has access to objects
+ reachable from the refs in their common alternate object store,
+ causing it to fetch unnecessary objects (jc/maint-fetch-alt).
+
+ * "git remote add --mirror" created a configuration that is suitable for
+ doing both a mirror fetch and a mirror push at the same time, which
+ made little sense. We now warn and require the command line to specify
+ either --mirror=fetch or --mirror=push.
diff --git a/RelNotes/1.7.6.1.adoc b/RelNotes/1.7.6.1.adoc
new file mode 100644
index 0000000..42e46ab
--- /dev/null
+++ b/RelNotes/1.7.6.1.adoc
@@ -0,0 +1,63 @@
+Git v1.7.6.1 Release Notes
+==========================
+
+Fixes since v1.7.6
+------------------
+
+ * Various codepaths that invoked zlib deflate/inflate assumed that these
+ functions can compress or uncompress more than 4GB data in one call on
+ platforms with 64-bit long, which has been corrected.
+
+ * "git unexecutable" reported that "unexecutable" was not found, even
+ though the actual error was that "unexecutable" was found but did
+ not have a proper she-bang line to be executed.
+
+ * Error exits from $PAGER were silently ignored.
+
+ * "git checkout -b <branch>" was confused when attempting to create a
+ branch whose name ends with "-g" followed by hexadecimal digits,
+ and refused to work.
+
+ * "git checkout -b <branch>" sometimes wrote a bogus reflog entry,
+ causing later "git checkout -" to fail.
+
+ * "git diff --cc" learned to correctly ignore binary files.
+
+ * "git diff -c/--cc" mishandled a deletion that resolves a conflict, and
+ looked in the working tree instead.
+
+ * "git fast-export" forgot to quote pathnames with unsafe characters
+ in its output.
+
+ * "git fetch" over smart-http transport used to abort when the
+ repository was updated between the initial connection and the
+ subsequent object transfer.
+
+ * "git fetch" did not recurse into submodules in subdirectories.
+
+ * "git ls-tree" did not error out when asked to show a corrupt tree.
+
+ * "git pull" without any argument left an extra whitespace after the
+ command name in its reflog.
+
+ * "git push --quiet" was not really quiet.
+
+ * "git rebase -i -p" incorrectly dropped commits from side branches.
+
+ * "git reset [<commit>] paths..." did not reset the index entry correctly
+ for unmerged paths.
+
+ * "git submodule add" did not allow a relative repository path when
+ the superproject did not have any default remote url.
+
+ * "git submodule foreach" failed to correctly give the standard input to
+ the user-supplied command it invoked.
+
+ * submodules that the user has never showed interest in by running
+ "git submodule init" was incorrectly marked as interesting by "git
+ submodule sync".
+
+ * "git submodule update --quiet" was not really quiet.
+
+ * "git tag -l <glob>..." did not take multiple glob patterns from the
+ command line.
diff --git a/RelNotes/1.7.6.2.adoc b/RelNotes/1.7.6.2.adoc
new file mode 100644
index 0000000..67ae414
--- /dev/null
+++ b/RelNotes/1.7.6.2.adoc
@@ -0,0 +1,8 @@
+Git v1.7.6.2 Release Notes
+==========================
+
+Fixes since v1.7.6.1
+--------------------
+
+ * v1.7.6.1 broke "git push --quiet"; it used to be a no-op against an old
+ version of Git running on the other end, but v1.7.6.1 made it abort.
diff --git a/RelNotes/1.7.6.3.adoc b/RelNotes/1.7.6.3.adoc
new file mode 100644
index 0000000..9597183
--- /dev/null
+++ b/RelNotes/1.7.6.3.adoc
@@ -0,0 +1,24 @@
+Git v1.7.6.3 Release Notes
+==========================
+
+Fixes since v1.7.6.2
+--------------------
+
+ * "git -c var=value subcmd" misparsed the custom configuration when
+ value contained an equal sign.
+
+ * "git fetch" had a major performance regression, wasting many
+ needless cycles in a repository where there is no submodules
+ present. This was especially bad, when there were many refs.
+
+ * "git reflog $refname" did not default to the "show" subcommand as
+ the documentation advertised the command to do.
+
+ * "git reset" did not leave meaningful log message in the reflog.
+
+ * "git status --ignored" did not show ignored items when there is no
+ untracked items.
+
+ * "git tag --contains $commit" was unnecessarily inefficient.
+
+Also contains minor fixes and documentation updates.
diff --git a/RelNotes/1.7.6.4.adoc b/RelNotes/1.7.6.4.adoc
new file mode 100644
index 0000000..e19acac
--- /dev/null
+++ b/RelNotes/1.7.6.4.adoc
@@ -0,0 +1,32 @@
+Git v1.7.6.4 Release Notes
+==========================
+
+Fixes since v1.7.6.3
+--------------------
+
+ * The error reporting logic of "git am" when the command is fed a file
+ whose mail-storage format is unknown was fixed.
+
+ * "git branch --set-upstream @{-1} foo" did not expand @{-1} correctly.
+
+ * "git check-ref-format --print" used to parrot a candidate string that
+ began with a slash (e.g. /refs/heads/master) without stripping it, to make
+ the result a suitably normalized string the caller can append to "$GIT_DIR/".
+
+ * "git clone" failed to clone locally from a ".git" file that itself
+ is not a directory but is a pointer to one.
+
+ * "git clone" from a local repository that borrows from another
+ object store using a relative path in its objects/info/alternates
+ file did not adjust the alternates in the resulting repository.
+
+ * "git describe --dirty" did not refresh the index before checking the
+ state of the working tree files.
+
+ * "git ls-files ../$path" that is run from a subdirectory reported errors
+ incorrectly when there is no such path that matches the given pathspec.
+
+ * "git mergetool" could loop forever prompting when nothing can be read
+ from the standard input.
+
+Also contains minor fixes and documentation updates.
diff --git a/RelNotes/1.7.6.5.adoc b/RelNotes/1.7.6.5.adoc
new file mode 100644
index 0000000..6713132
--- /dev/null
+++ b/RelNotes/1.7.6.5.adoc
@@ -0,0 +1,26 @@
+Git v1.7.6.5 Release Notes
+==========================
+
+Fixes since v1.7.6.4
+--------------------
+
+ * The date parser did not accept timezone designators that lack minutes
+ part and also has a colon between "hh:mm".
+
+ * After fetching from a remote that has very long refname, the reporting
+ output could have corrupted by overrunning a static buffer.
+
+ * "git mergetool" did not use its arguments as pathspec, but as a path to
+ the file that may not even have any conflict.
+
+ * "git name-rev --all" tried to name all _objects_, naturally failing to
+ describe many blobs and trees, instead of showing only commits as
+ advertised in its documentation.
+
+ * "git remote rename $a $b" were not careful to match the remote name
+ against $a (i.e. source side of the remote nickname).
+
+ * "gitweb" used to produce a non-working link while showing the contents
+ of a blob, when JavaScript actions are enabled.
+
+Also contains minor fixes and documentation updates.
diff --git a/RelNotes/1.7.6.6.adoc b/RelNotes/1.7.6.6.adoc
new file mode 100644
index 0000000..5343e00
--- /dev/null
+++ b/RelNotes/1.7.6.6.adoc
@@ -0,0 +1,16 @@
+Git v1.7.6.6 Release Notes
+==========================
+
+Fixes since v1.7.6.5
+--------------------
+
+ * The code to look up attributes for paths reused entries from a wrong
+ directory when two paths in question are in adjacent directories and
+ the name of the one directory is a prefix of the other.
+
+ * When producing a "thin pack" (primarily used in bundles and smart
+ HTTP transfers) out of a fully packed repository, we unnecessarily
+ avoided sending recent objects as a delta against objects we know
+ the other side has.
+
+Also contains minor fixes and documentation updates.
diff --git a/RelNotes/1.7.6.adoc b/RelNotes/1.7.6.adoc
new file mode 100644
index 0000000..9ec498e
--- /dev/null
+++ b/RelNotes/1.7.6.adoc
@@ -0,0 +1,136 @@
+Git v1.7.6 Release Notes
+========================
+
+Updates since v1.7.5
+--------------------
+
+ * Various git-svn updates.
+
+ * Updates the way content tags are handled in gitweb. Also adds
+ a UI to choose common timezone for displaying the dates.
+
+ * Similar to branch names, tagnames that begin with "-" are now
+ disallowed.
+
+ * Clean-up of the C part of i18n (but not l10n---please wait)
+ continues.
+
+ * The scripting part of the codebase is getting prepared for i18n/l10n.
+
+ * Pushing and pulling from a repository with large number of refs that
+ point to identical commits are optimized by not listing the same commit
+ during the common ancestor negotiation exchange with the other side.
+
+ * Adding a file larger than core.bigfilethreshold (defaults to 1/2 Gig)
+ using "git add" will send the contents straight to a packfile without
+ having to hold it and its compressed representation both at the same
+ time in memory.
+
+ * Processes spawned by "[alias] <name> = !process" in the configuration
+ can inspect GIT_PREFIX environment variable to learn where in the
+ working tree the original command was invoked.
+
+ * A magic pathspec ":/" tells a command that limits its operation to
+ the current directory when ran from a subdirectory to work on the
+ entire working tree. In general, ":/path/to/file" would be relative
+ to the root of the working tree hierarchy.
+
+ After "git reset --hard; edit Makefile; cd t/", "git add -u" would
+ be a no-op, but "git add -u :/" would add the updated contents of
+ the Makefile at the top level. If you want to name a path in the
+ current subdirectory whose unusual name begins with ":/", you can
+ name it by "./:/that/path" or by "\:/that/path".
+
+ * "git blame" learned "--abbrev[=<n>]" option to control the minimum
+ number of hexdigits shown for commit object names.
+
+ * "git blame" learned "--line-porcelain" that is less efficient but is
+ easier to parse.
+
+ * Aborting "git commit --interactive" discards updates to the index
+ made during the interactive session.
+
+ * "git commit" learned a "--patch" option to directly jump to the
+ per-hunk selection UI of the interactive mode.
+
+ * "git diff" and its family of commands learned --dirstat=0 to show
+ directories that contribute less than 0.1% of changes.
+
+ * "git diff" and its family of commands learned --dirstat=lines mode to
+ assess damage to the directory based on number of lines in the patch
+ output, not based on the similarity numbers.
+
+ * "git format-patch" learned "--quiet" option to suppress the output of
+ the names of generated files.
+
+ * "git format-patch" quotes people's names when it has RFC822 special
+ characters in it, e.g. "Junio C. Hamano" <jch@example.com>. Earlier
+ it was up to the user to do this when using its output.
+
+ * "git format-patch" can take an empty --subject-prefix now.
+
+ * "git grep" learned the "-P" option to take pcre regular expressions.
+
+ * "git log" and friends learned a new "--notes" option to replace the
+ "--show-notes" option. Unlike "--show-notes", "--notes=<ref>" does
+ not imply showing the default notes.
+
+ * They also learned a log.abbrevCommit configuration variable to augment
+ the --abbrev-commit command line option.
+
+ * "git ls-remote" learned "--exit-code" option to consider it a
+ different kind of error when no remote ref to be shown.
+
+ * "git merge" learned "-" as a short-hand for "the previous branch", just
+ like the way "git checkout -" works.
+
+ * "git merge" uses "merge.ff" configuration variable to decide to always
+ create a merge commit (i.e. --no-ff, aka merge.ff=no), refuse to create
+ a merge commit (i.e. --ff-only, aka merge.ff=only). Setting merge.ff=yes
+ (or not setting it at all) restores the default behaviour of allowing
+ fast-forward to happen when possible.
+
+ * p4-import (from contrib) learned a new option --preserve-user.
+
+ * "git read-tree -m" learned "--dry-run" option that reports if a merge
+ would fail without touching the index nor the working tree.
+
+ * "git rebase" that does not specify on top of which branch to rebase
+ the current branch now uses @{upstream} of the current branch.
+
+ * "git rebase" finished either normally or with --abort did not
+ update the reflog for HEAD to record the event to come back to
+ where it started from.
+
+ * "git remote add -t only-this-branch --mirror=fetch" is now allowed. Earlier
+ a fetch-mode mirror meant mirror everything, but now it only means refs are
+ not renamed.
+
+ * "git rev-list --count" used with "--cherry-mark" counts the cherry-picked
+ commits separately, producing more a useful output.
+
+ * "git submodule update" learned "--force" option to get rid of local
+ changes in submodules and replace them with the up-to-date version.
+
+ * "git status" and friends ignore .gitmodules file while the file is
+ still in a conflicted state during a merge, to avoid using information
+ that is not final and possibly corrupt with conflict markers.
+
+Also contains various documentation updates and minor miscellaneous
+changes.
+
+
+Fixes since v1.7.5
+------------------
+
+Unless otherwise noted, all the fixes in 1.7.5.X maintenance track are
+included in this release.
+
+ * "git config" used to choke with an insanely long line.
+ (merge ef/maint-strbuf-init later)
+
+ * "git diff --quiet" did not work well with --diff-filter.
+ (merge jk/diff-not-so-quick later)
+
+ * "git status -z" did not default to --porcelain output format.
+ (merge bc/maint-status-z-to-use-porcelain later)
diff --git a/RelNotes/1.7.7.1.adoc b/RelNotes/1.7.7.1.adoc
new file mode 100644
index 0000000..ac9b838
--- /dev/null
+++ b/RelNotes/1.7.7.1.adoc
@@ -0,0 +1,60 @@
+Git v1.7.7.1 Release Notes
+==========================
+
+Fixes since v1.7.7
+------------------
+
+ * On some BSD systems, adding +s bit on directories is detrimental
+ (it is not necessary on BSD to begin with). "git init --shared"
+ has been updated to take this into account without extra makefile
+ settings on platforms the Makefile knows about.
+
+ * After incorrectly written third-party tools store a tag object in
+ HEAD, git diagnosed it as a repository corruption and refused to
+ proceed in order to avoid spreading the damage. We now gracefully
+ recover from such a situation by pretending as if the commit that
+ is pointed at by the tag were in HEAD.
+
+ * "git apply --whitespace=error" did not bother to report the exact
+ line number in the patch that introduced new blank lines at the end
+ of the file.
+
+ * "git apply --index" did not check corrupted patch.
+
+ * "git checkout $tree $directory/" resurrected paths locally removed or
+ modified only in the working tree in $directory/ that did not appear
+ in $directory of the given $tree. They should have been kept intact.
+
+ * "git diff $tree $path" used to apply the pathspec at the output stage,
+ reading the whole tree, wasting resources.
+
+ * The code to check for updated submodules during a "git fetch" of the
+ superproject had an unnecessary quadratic loop.
+
+ * "git fetch" from a large bundle did not enable the progress output.
+
+ * When "git fsck --lost-and-found" found that an empty blob object in the
+ object store is unreachable, it incorrectly reported an error after
+ writing the lost blob out successfully.
+
+ * "git filter-branch" did not refresh the index before checking that the
+ working tree was clean.
+
+ * "git grep $tree" when run with multiple threads had an unsafe access to
+ the object database that should have been protected with mutex.
+
+ * The "--ancestry-path" option to "git log" and friends misbehaved in a
+ history with complex criss-cross merges and showed an uninteresting
+ side history as well.
+
+ * Test t1304 assumed LOGNAME is always set, which may not be true on
+ some systems.
+
+ * Tests with --valgrind failed to find "mergetool" scriptlets.
+
+ * "git patch-id" miscomputed the patch-id in a patch that has a line longer
+ than 1kB.
+
+ * When an "exec" insn failed after modifying the index and/or the working
+ tree during "rebase -i", we now check and warn that the changes need to
+ be cleaned up.
diff --git a/RelNotes/1.7.7.2.adoc b/RelNotes/1.7.7.2.adoc
new file mode 100644
index 0000000..e6bbef2
--- /dev/null
+++ b/RelNotes/1.7.7.2.adoc
@@ -0,0 +1,44 @@
+Git v1.7.7.2 Release Notes
+==========================
+
+Fixes since v1.7.7.1
+--------------------
+
+ * We used to drop error messages from libcurl on certain kinds of
+ errors.
+
+ * Error report from smart HTTP transport, when the connection was
+ broken in the middle of a transfer, showed a useless message on
+ a corrupt packet.
+
+ * "git fetch --prune" was unsafe when used with refspecs from the
+ command line.
+
+ * The attribute mechanism did not use case insensitive match when
+ core.ignorecase was set.
+
+ * "git bisect" did not notice when it failed to update the working tree
+ to the next commit to be tested.
+
+ * "git config --bool --get-regexp" failed to separate the variable name
+ and its value "true" when the variable is defined without "= true".
+
+ * "git remote rename $a $b" were not careful to match the remote name
+ against $a (i.e. source side of the remote nickname).
+
+ * "git mergetool" did not use its arguments as pathspec, but as a path to
+ the file that may not even have any conflict.
+
+ * "git diff --[num]stat" used to use the number of lines of context
+ different from the default, potentially giving different results from
+ "git diff | diffstat" and confusing the users.
+
+ * "git pull" and "git rebase" did not work well even when GIT_WORK_TREE is
+ set correctly with GIT_DIR if the current directory is outside the working
+ tree.
+
+ * "git send-email" did not honor the configured hostname when restarting
+ the HELO/EHLO exchange after switching TLS on.
+
+ * "gitweb" used to produce a non-working link while showing the contents
+ of a blob, when JavaScript actions are enabled.
diff --git a/RelNotes/1.7.7.3.adoc b/RelNotes/1.7.7.3.adoc
new file mode 100644
index 0000000..09301f0
--- /dev/null
+++ b/RelNotes/1.7.7.3.adoc
@@ -0,0 +1,19 @@
+Git v1.7.7.3 Release Notes
+==========================
+
+Fixes since v1.7.7.2
+--------------------
+
+ * Adjust the "quick-install-doc" procedures as preformatted
+ html/manpage are no longer in the source repository.
+
+ * The logic to optimize the locality of the data in a pack introduced in
+ 1.7.7 was grossly inefficient.
+
+ * The logic to filter out forked projects in the project list in
+ "gitweb" was broken for some time.
+
+ * "git branch -m/-M" advertised to update RENAME_REF ref in the
+ commit log message that introduced the feature but not anywhere in
+ the documentation, and never did update such a ref anyway. This
+ undocumented misfeature that did not exist has been excised.
diff --git a/RelNotes/1.7.7.4.adoc b/RelNotes/1.7.7.4.adoc
new file mode 100644
index 0000000..e523448
--- /dev/null
+++ b/RelNotes/1.7.7.4.adoc
@@ -0,0 +1,14 @@
+Git v1.7.7.4 Release Notes
+==========================
+
+Fixes since v1.7.7.3
+--------------------
+
+ * A few header dependencies were missing from the Makefile.
+
+ * Some newer parts of the code used C99 __VA_ARGS__ while we still
+ try to cater to older compilers.
+
+ * "git name-rev --all" tried to name all _objects_, naturally failing to
+ describe many blobs and trees, instead of showing only commits as
+ advertised in its documentation.
diff --git a/RelNotes/1.7.7.5.adoc b/RelNotes/1.7.7.5.adoc
new file mode 100644
index 0000000..7b09319
--- /dev/null
+++ b/RelNotes/1.7.7.5.adoc
@@ -0,0 +1,14 @@
+Git v1.7.7.5 Release Notes
+==========================
+
+Fixes since v1.7.7.4
+--------------------
+
+ * After fetching from a remote that has very long refname, the reporting
+ output could have corrupted by overrunning a static buffer.
+
+ * "git checkout" and "git merge" treated in-tree .gitignore and exclude
+ file in $GIT_DIR/info/ directory inconsistently when deciding which
+ untracked files are ignored and expendable.
+
+Also contains minor fixes and documentation updates.
diff --git a/RelNotes/1.7.7.6.adoc b/RelNotes/1.7.7.6.adoc
new file mode 100644
index 0000000..8df606d
--- /dev/null
+++ b/RelNotes/1.7.7.6.adoc
@@ -0,0 +1,20 @@
+Git v1.7.7.6 Release Notes
+==========================
+
+Fixes since v1.7.7.5
+--------------------
+
+ * The code to look up attributes for paths reused entries from a wrong
+ directory when two paths in question are in adjacent directories and
+ the name of the one directory is a prefix of the other.
+
+ * A wildcard that matches deeper hierarchy given to the "diff-index" command,
+ e.g. "git diff-index HEAD -- '*.txt'", incorrectly reported additions of
+ matching files even when there is no change.
+
+ * When producing a "thin pack" (primarily used in bundles and smart
+ HTTP transfers) out of a fully packed repository, we unnecessarily
+ avoided sending recent objects as a delta against objects we know
+ the other side has.
+
+Also contains minor fixes and documentation updates.
diff --git a/RelNotes/1.7.7.7.adoc b/RelNotes/1.7.7.7.adoc
new file mode 100644
index 0000000..e79118d
--- /dev/null
+++ b/RelNotes/1.7.7.7.adoc
@@ -0,0 +1,13 @@
+Git v1.7.7.7 Release Notes
+==========================
+
+Fixes since v1.7.7.6
+--------------------
+
+ * An error message from 'git bundle' had an unmatched single quote pair in it.
+
+ * 'git diff --histogram' option was not described.
+
+ * 'git imap-send' carried an unused dead code.
+
+Also contains minor fixes and documentation updates.
diff --git a/RelNotes/1.7.7.adoc b/RelNotes/1.7.7.adoc
new file mode 100644
index 0000000..6eff128
--- /dev/null
+++ b/RelNotes/1.7.7.adoc
@@ -0,0 +1,134 @@
+Git v1.7.7 Release Notes
+========================
+
+Updates since v1.7.6
+--------------------
+
+ * The scripting part of the codebase is getting prepared for i18n/l10n.
+
+ * Interix, Cygwin and Minix ports got updated.
+
+ * Various updates to git-p4 (in contrib/), fast-import, and git-svn.
+
+ * Gitweb learned to read from /etc/gitweb-common.conf when it exists,
+ before reading from gitweb_config.perl or from /etc/gitweb.conf
+ (this last one is read only when per-repository gitweb_config.perl
+ does not exist).
+
+ * Various codepaths that invoked zlib deflate/inflate assumed that these
+ functions can compress or uncompress more than 4GB data in one call on
+ platforms with 64-bit long, which has been corrected.
+
+ * Git now recognizes loose objects written by other implementations that
+ use a non-standard window size for zlib deflation (e.g. Agit running on
+ Android with 4kb window). We used to reject anything that was not
+ deflated with 32kb window.
+
+ * Interaction between the use of pager and coloring of the output has
+ been improved, especially when a command that is not built-in was
+ involved.
+
+ * "git am" learned to pass the "--exclude=<path>" option through to underlying
+ "git apply".
+
+ * You can now feed many empty lines before feeding an mbox file to
+ "git am".
+
+ * "git archive" can be told to pass the output to gzip compression and
+ produce "archive.tar.gz".
+
+ * "git bisect" can be used in a bare repository (provided that the test
+ you perform per each iteration does not need a working tree, of
+ course).
+
+ * The length of abbreviated object names in "git branch -v" output
+ now honors the core.abbrev configuration variable.
+
+ * "git check-attr" can take relative paths from the command line.
+
+ * "git check-attr" learned an "--all" option to list the attributes for a
+ given path.
+
+ * "git checkout" (both the code to update the files upon checking out a
+ different branch and the code to checkout a specific set of files) learned
+ to stream the data from object store when possible, without having to
+ read the entire contents of a file into memory first. An earlier round
+ of this code that is not in any released version had a large leak but
+ now it has been plugged.
+
+ * "git clone" can now take a "--config key=value" option to set the
+ repository configuration options that affect the initial checkout.
+
+ * "git commit <paths>..." now lets you feed relative pathspecs that
+ refer to outside your current subdirectory.
+
+ * "git diff --stat" learned a --stat-count option to limit the output of
+ a diffstat report.
+
+ * "git diff" learned a "--histogram" option to use a different diff
+ generation machinery stolen from jgit, which might give better
+ performance.
+
+ * "git diff" had a weird worst case behaviour that can be triggered
+ when comparing files with potentially many places that could match.
+
+ * "git fetch", "git push" and friends no longer show connection
+ errors for addresses that couldn't be connected to when at least one
+ address succeeds (this is arguably a regression but a deliberate
+ one).
+
+ * "git grep" learned "--break" and "--heading" options, to let users mimic
+ the output format of "ack".
+
+ * "git grep" learned a "-W" option that shows wider context using the same
+ logic used by "git diff" to determine the hunk header.
+
+ * Invoking the low-level "git http-fetch" without "-a" option (which
+ git itself never did--normal users should not have to worry about
+ this) is now deprecated.
+
+ * The "--decorate" option to "git log" and its family learned to
+ highlight grafted and replaced commits.
+
+ * "git rebase master topci" no longer spews usage hints after giving
+ the "fatal: no such branch: topci" error message.
+
+ * The recursive merge strategy implementation got a fairly large
+ fix for many corner cases that may rarely happen in real world
+ projects (it has been verified that none of the 16000+ merges in
+ the Linux kernel history back to v2.6.12 is affected with the
+ corner case bugs this update fixes).
+
+ * "git stash" learned an "--include-untracked option".
+
+ * "git submodule update" used to stop at the first error updating a
+ submodule; it now goes on to update other submodules that can be
+ updated, and reports the ones with errors at the end.
+
+ * "git push" can be told with the "--recurse-submodules=check" option to
+ refuse pushing of the supermodule, if any of its submodules'
+ commits hasn't been pushed out to their remotes.
+
+ * "git upload-pack" and "git receive-pack" learned to pretend that only a
+ subset of the refs exist in a repository. This may help a site to
+ put many tiny repositories into one repository (this would not be
+ useful for larger repositories as repacking would be problematic).
+
+ * "git verify-pack" has been rewritten to use the "index-pack" machinery
+ that is more efficient in reading objects in packfiles.
+
+ * test scripts for gitweb tried to run even when CGI-related perl modules
+ are not installed; they now exit early when the latter are unavailable.
+
+Also contains various documentation updates and minor miscellaneous
+changes.
+
+
+Fixes since v1.7.6
+------------------
+
+Unless otherwise noted, all fixes in the 1.7.6.X maintenance track are
+included in this release.
+
+ * "git branch -m" and "git checkout -b" incorrectly allowed the tip
+ of the branch that is currently checked out updated.
diff --git a/RelNotes/1.7.8.1.adoc b/RelNotes/1.7.8.1.adoc
new file mode 100644
index 0000000..33dc948
--- /dev/null
+++ b/RelNotes/1.7.8.1.adoc
@@ -0,0 +1,38 @@
+Git v1.7.8.1 Release Notes
+==========================
+
+Fixes since v1.7.8
+------------------
+
+ * In some codepaths (notably, checkout and merge), the ignore patterns
+ recorded in $GIT_DIR/info/exclude were not honored. They now are.
+
+ * "git apply --check" did not error out when given an empty input
+ without any patch.
+
+ * "git archive" mistakenly allowed remote clients to ask for commits
+ that are not at the tip of any ref.
+
+ * "git checkout" and "git merge" treated in-tree .gitignore and exclude
+ file in $GIT_DIR/info/ directory inconsistently when deciding which
+ untracked files are ignored and expendable.
+
+ * LF-to-CRLF streaming filter used when checking out a large-ish blob
+ fell into an infinite loop with a rare input.
+
+ * The function header pattern for files with "diff=cpp" attribute did
+ not consider "type *funcname(type param1,..." as the beginning of a
+ function.
+
+ * The error message from "git diff" and "git status" when they fail
+ to inspect changes in submodules did not report which submodule they
+ had trouble with.
+
+ * After fetching from a remote that has very long refname, the reporting
+ output could have corrupted by overrunning a static buffer.
+
+ * "git pack-objects" avoids creating cyclic dependencies among deltas
+ when seeing a broken packfile that records the same object in both
+ the deflated form and as a delta.
+
+Also contains minor fixes and documentation updates.
diff --git a/RelNotes/1.7.8.2.adoc b/RelNotes/1.7.8.2.adoc
new file mode 100644
index 0000000..b9c66aa
--- /dev/null
+++ b/RelNotes/1.7.8.2.adoc
@@ -0,0 +1,71 @@
+Git v1.7.8.2 Release Notes
+==========================
+
+Fixes since v1.7.8.1
+--------------------
+
+ * Porcelain commands like "git reset" did not distinguish deletions
+ and type-changes from ordinary modification, and reported them with
+ the same 'M' moniker. They now use 'D' (for deletion) and 'T' (for
+ type-change) to match "git status -s" and "git diff --name-status".
+
+ * The configuration file parser used for sizes (e.g. bigFileThreshold)
+ did not correctly interpret 'g' suffix.
+
+ * The replacement implementation for snprintf used on platforms with
+ native snprintf that is broken did not use va_copy correctly.
+
+ * LF-to-CRLF streaming filter replaced all LF with CRLF, which might
+ be technically correct but not friendly to people who are trying
+ to recover from earlier mistakes of using CRLF in the repository
+ data in the first place. It now refrains from doing so for LF that
+ follows a CR.
+
+ * git native connection going over TCP (not over SSH) did not set
+ SO_KEEPALIVE option which failed to receive link layer errors.
+
+ * "git branch -m <current branch> HEAD" is an obvious no-op but was not
+ allowed.
+
+ * "git checkout -m" did not recreate the conflicted state in a "both
+ sides added, without any common ancestor version" conflict
+ situation.
+
+ * "git cherry-pick $commit" (not a range) created an unnecessary
+ sequencer state and interfered with valid workflow to use the
+ command during a session to cherry-pick multiple commits.
+
+ * You could make "git commit" segfault by giving the "--no-message"
+ option.
+
+ * "fast-import" did not correctly update an existing notes tree,
+ possibly corrupting the fan-out.
+
+ * "git fetch-pack" accepted unqualified refs that do not begin with
+ refs/ by mistake and compensated it by matching the refspec with
+ tail-match, which was doubly wrong. This broke fetching from a
+ repository with a funny named ref "refs/foo/refs/heads/master" and a
+ 'master' branch with "git fetch-pack refs/heads/master", as the
+ command incorrectly considered the former a "match".
+
+ * "git log --follow" did not honor the rename threshold score given
+ with the -M option (e.g. "-M50%").
+
+ * "git mv" gave suboptimal error/warning messages when it overwrites
+ target files. It also did not pay attention to "-v" option.
+
+ * Authenticated "git push" over dumb HTTP were broken with a recent
+ change and failed without asking for password when username is
+ given.
+
+ * "git push" to an empty repository over HTTP were broken with a
+ recent change to the ref handling.
+
+ * "git push -v" forgot how to be verbose by mistake. It now properly
+ becomes verbose when asked to.
+
+ * When a "reword" action in "git rebase -i" failed to run "commit --amend",
+ we did not give the control back to the user to resolve the situation, and
+ instead kept the original commit log message.
+
+Also contains minor fixes and documentation updates.
diff --git a/RelNotes/1.7.8.3.adoc b/RelNotes/1.7.8.3.adoc
new file mode 100644
index 0000000..a92714c
--- /dev/null
+++ b/RelNotes/1.7.8.3.adoc
@@ -0,0 +1,16 @@
+Git v1.7.8.3 Release Notes
+==========================
+
+Fixes since v1.7.8.2
+--------------------
+
+ * Attempt to fetch from an empty file pretending it to be a bundle did
+ not error out correctly.
+
+ * gitweb did not correctly fall back to configured $fallback_encoding
+ that is not 'latin1'.
+
+ * "git clone --depth $n" did not catch a non-number given as $n as an
+ error.
+
+Also contains minor fixes and documentation updates.
diff --git a/RelNotes/1.7.8.4.adoc b/RelNotes/1.7.8.4.adoc
new file mode 100644
index 0000000..9bebdbf
--- /dev/null
+++ b/RelNotes/1.7.8.4.adoc
@@ -0,0 +1,23 @@
+Git v1.7.8.4 Release Notes
+==========================
+
+Fixes since v1.7.8.3
+--------------------
+
+ * The code to look up attributes for paths reused entries from a wrong
+ directory when two paths in question are in adjacent directories and
+ the name of the one directory is a prefix of the other.
+
+ * A wildcard that matches deeper hierarchy given to the "diff-index" command,
+ e.g. "git diff-index HEAD -- '*.txt'", incorrectly reported additions of
+ matching files even when there is no change.
+
+ * When producing a "thin pack" (primarily used in bundles and smart
+ HTTP transfers) out of a fully packed repository, we unnecessarily
+ avoided sending recent objects as a delta against objects we know
+ the other side has.
+
+ * "git send-email" did not properly treat sendemail.multiedit as a
+ boolean (e.g. setting it to "false" did not turn it off).
+
+Also contains minor fixes and documentation updates.
diff --git a/RelNotes/1.7.8.5.adoc b/RelNotes/1.7.8.5.adoc
new file mode 100644
index 0000000..011fd2a
--- /dev/null
+++ b/RelNotes/1.7.8.5.adoc
@@ -0,0 +1,19 @@
+Git v1.7.8.5 Release Notes
+==========================
+
+Fixes since v1.7.8.4
+--------------------
+
+ * Dependency on our thread-utils.h header file was missing for
+ objects that depend on it in the Makefile.
+
+ * "git am" when fed an empty file did not correctly finish reading it
+ when it attempts to guess the input format.
+
+ * "git grep -P" (when PCRE is enabled in the build) did not match the
+ beginning and the end of the line correctly with ^ and $.
+
+ * "git rebase -m" tried to run "git notes copy" needlessly when
+ nothing was rewritten.
+
+Also contains minor fixes and documentation updates.
diff --git a/RelNotes/1.7.8.6.adoc b/RelNotes/1.7.8.6.adoc
new file mode 100644
index 0000000..d9bf2b7
--- /dev/null
+++ b/RelNotes/1.7.8.6.adoc
@@ -0,0 +1,22 @@
+Git v1.7.8.6 Release Notes
+==========================
+
+Fixes since v1.7.8.5
+--------------------
+
+ * An error message from 'git bundle' had an unmatched single quote pair in it.
+
+ * 'git diff --histogram' option was not described.
+
+ * Documentation for 'git rev-list' had minor formatting errors.
+
+ * 'git imap-send' carried an unused dead code.
+
+ * The way 'git fetch' implemented its connectivity check over
+ received objects was overly pessimistic, and wasted a lot of
+ cycles.
+
+ * Various minor backports of fixes from the 'master' and the 'maint'
+ branch.
+
+Also contains minor fixes and documentation updates.
diff --git a/RelNotes/1.7.8.adoc b/RelNotes/1.7.8.adoc
new file mode 100644
index 0000000..2493113
--- /dev/null
+++ b/RelNotes/1.7.8.adoc
@@ -0,0 +1,161 @@
+Git v1.7.8 Release Notes
+========================
+
+Updates since v1.7.7
+--------------------
+
+ * Some git-svn, git-gui, git-p4 (in contrib) and msysgit updates.
+
+ * Updates to bash completion scripts.
+
+ * The build procedure has been taught to take advantage of computed
+ dependency automatically when the compiler supports it.
+
+ * The date parser now accepts timezone designators that lack minutes
+ part and also has a colon between "hh:mm".
+
+ * The contents of the /etc/mailname file, if exists, is used as the
+ default value of the hostname part of the committer/author e-mail.
+
+ * "git am" learned how to read from patches generated by Hg.
+
+ * "git archive" talking with a remote repository can report errors
+ from the remote side in a more informative way.
+
+ * "git branch" learned an explicit --list option to ask for branches
+ listed, optionally with a glob matching pattern to limit its output.
+
+ * "git check-attr" learned "--cached" option to look at .gitattributes
+ files from the index, not from the working tree.
+
+ * Variants of "git cherry-pick" and "git revert" that take multiple
+ commits learned to "--continue" and "--abort".
+
+ * "git daemon" gives more human readable error messages to clients
+ using ERR packets when appropriate.
+
+ * Errors at the network layer is logged by "git daemon".
+
+ * "git diff" learned "--minimal" option to spend extra cycles to come
+ up with a minimal patch output.
+
+ * "git diff" learned "--function-context" option to show the whole
+ function as context that was affected by a change.
+
+ * "git difftool" can be told to skip launching the tool for a path by
+ answering 'n' to its prompt.
+
+ * "git fetch" learned to honor transfer.fsckobjects configuration to
+ validate the objects that were received from the other end, just like
+ "git receive-pack" (the receiving end of "git push") does.
+
+ * "git fetch" makes sure that the set of objects it received from the
+ other end actually completes the history before updating the refs.
+ "git receive-pack" (the receiving end of "git push") learned to do the
+ same.
+
+ * "git fetch" learned that fetching/cloning from a regular file on the
+ filesystem is not necessarily a request to unpack a bundle file; the
+ file could be ".git" with "gitdir: <path>" in it.
+
+ * "git for-each-ref" learned "%(contents:subject)", "%(contents:body)"
+ and "%(contents:signature)". The last one is useful for signed tags.
+
+ * "git grep" used to incorrectly pay attention to .gitignore files
+ scattered in the directory it was working in even when "--no-index"
+ option was used. It no longer does this. The "--exclude-standard"
+ option needs to be given to explicitly activate the ignore
+ mechanism.
+
+ * "git grep" learned "--untracked" option, where given patterns are
+ searched in untracked (but not ignored) files as well as tracked
+ files in the working tree, so that matches in new but not yet
+ added files do not get missed.
+
+ * The recursive merge backend no longer looks for meaningless
+ existing merges in submodules unless in the outermost merge.
+
+ * "git log" and friends learned "--children" option.
+
+ * "git ls-remote" learned to respond to "-h"(elp) requests.
+
+ * "mediawiki" remote helper can interact with (surprise!) MediaWiki
+ with "git fetch" & "git push".
+
+ * "git merge" learned the "--edit" option to allow users to edit the
+ merge commit log message.
+
+ * "git rebase -i" can be told to use special purpose editor suitable
+ only for its insn sheet via sequence.editor configuration variable.
+
+ * "git send-email" learned to respond to "-h"(elp) requests.
+
+ * "git send-email" allows the value given to sendemail.aliasfile to begin
+ with "~/" to refer to the $HOME directory.
+
+ * "git send-email" forces use of Authen::SASL::Perl to work around
+ issues between Authen::SASL::Cyrus and AUTH PLAIN/LOGIN.
+
+ * "git stash" learned "--include-untracked" option to stash away
+ untracked/ignored cruft from the working tree.
+
+ * "git submodule clone" does not leak an error message to the UI
+ level unnecessarily anymore.
+
+ * "git submodule update" learned to honor "none" as the value for
+ submodule.<name>.update to specify that the named submodule should
+ not be checked out by default.
+
+ * When populating a new submodule directory with "git submodule init",
+ the $GIT_DIR metainformation directory for submodules is created inside
+ $GIT_DIR/modules/<name>/ directory of the superproject and referenced
+ via the gitfile mechanism. This is to make it possible to switch
+ between commits in the superproject that has and does not have the
+ submodule in the tree without re-cloning.
+
+ * "gitweb" leaked unescaped control characters from syntax hiliter
+ outputs.
+
+ * "gitweb" can be told to give custom string at the end of the HTML
+ HEAD element.
+
+ * "gitweb" now has its own manual pages.
+
+
+Also contains other documentation updates and minor code cleanups.
+
+
+Fixes since v1.7.7
+------------------
+
+Unless otherwise noted, all fixes in the 1.7.7.X maintenance track are
+included in this release.
+
+ * HTTP transport did not use pushurl correctly, and also did not tell
+ what host it is trying to authenticate with when asking for
+ credentials.
+ (merge deba493 jk/http-auth later to maint).
+
+ * "git blame" was aborted if started from an uncommitted content and
+ the path had the textconv filter in effect.
+ (merge 8518088 ss/blame-textconv-fake-working-tree later to maint).
+
+ * Adding many refs to the local repository in one go (e.g. "git fetch"
+ that fetches many tags) and looking up a ref by name in a repository
+ with too many refs were unnecessarily slow.
+ (merge 17d68a54d jp/get-ref-dir-unsorted later to maint).
+
+ * Report from "git commit" on untracked files was confused under
+ core.ignorecase option.
+ (merge 395c7356 jk/name-hash-dirent later to maint).
+
+ * "git merge" did not understand ":/<pattern>" as a way to name a commit.
+
+ " "git push" on the receiving end used to call post-receive and post-update
+ hooks for attempted removal of non-existing refs.
+ (merge 160b81ed ph/push-to-delete-nothing later to maint).
+
+ * Help text for "git remote set-url" and "git remote set-branches"
+ were misspelled.
+ (merge c49904e fc/remote-seturl-usage-fix later to maint).
+ (merge 656cdf0 jc/remote-setbranches-usage-fix later to maint).
diff --git a/RelNotes/1.7.9.1.adoc b/RelNotes/1.7.9.1.adoc
new file mode 100644
index 0000000..6957183
--- /dev/null
+++ b/RelNotes/1.7.9.1.adoc
@@ -0,0 +1,63 @@
+Git v1.7.9.1 Release Notes
+==========================
+
+Fixes since v1.7.9
+------------------
+
+ * The makefile allowed environment variable X seep into it result in
+ command names suffixed with unnecessary strings.
+
+ * The set of included header files in compat/inet-{ntop,pton}
+ wrappers was updated for Windows some time ago, but in a way that
+ broke Solaris build.
+
+ * rpmbuild noticed an unpackaged but installed *.mo file and failed.
+
+ * Subprocesses spawned from various git programs were often left running
+ to completion even when the top-level process was killed.
+
+ * "git add -e" learned not to show a diff for an otherwise unmodified
+ submodule that only has uncommitted local changes in the patch
+ prepared by for the user to edit.
+
+ * Typo in "git branch --edit-description my-tpoic" was not diagnosed.
+
+ * Using "git grep -l/-L" together with options -W or --break may not
+ make much sense as the output is to only count the number of hits
+ and there is no place for file breaks, but the latter options made
+ "-l/-L" to miscount the hits.
+
+ * "git log --first-parent $pathspec" did not stay on the first parent
+ chain and veered into side branch from which the whole change to the
+ specified paths came.
+
+ * "git merge --no-edit $tag" failed to honor the --no-edit option.
+
+ * "git merge --ff-only $tag" failed because it cannot record the
+ required mergetag without creating a merge, but this is so common
+ operation for branch that is used _only_ to follow the upstream, so
+ it was changed to allow fast-forwarding without recording the mergetag.
+
+ * "git mergetool" now gives an empty file as the common base version
+ to the backend when dealing with the "both sides added, differently"
+ case.
+
+ * "git push -q" was not sufficiently quiet.
+
+ * When "git push" fails to update any refs, the client side did not
+ report an error correctly to the end user.
+
+ * "rebase" and "commit --amend" failed to work on commits with ancient
+ timestamps near year 1970.
+
+ * When asking for a tag to be pulled, "request-pull" did not show the
+ name of the tag prefixed with "tags/", which would have helped older
+ clients.
+
+ * "git submodule add $path" forgot to recompute the name to be stored
+ in .gitmodules when the submodule at $path was once added to the
+ superproject and already initialized.
+
+ * Many small corner case bugs on "git tag -n" was corrected.
+
+Also contains minor fixes and documentation updates.
diff --git a/RelNotes/1.7.9.2.adoc b/RelNotes/1.7.9.2.adoc
new file mode 100644
index 0000000..e500da7
--- /dev/null
+++ b/RelNotes/1.7.9.2.adoc
@@ -0,0 +1,69 @@
+Git v1.7.9.2 Release Notes
+==========================
+
+Fixes since v1.7.9.1
+--------------------
+
+ * Bash completion script (in contrib/) did not like a pattern that
+ begins with a dash to be passed to __git_ps1 helper function.
+
+ * Adaptation of the bash completion script (in contrib/) for zsh
+ incorrectly listed all subcommands when "git <TAB><TAB>" was given
+ to ask for list of porcelain subcommands.
+
+ * The build procedure for profile-directed optimized binary was not
+ working very well.
+
+ * Some systems need to explicitly link -lcharset to get locale_charset().
+
+ * t5541 ignored user-supplied port number used for HTTP server testing.
+
+ * The error message emitted when we see an empty loose object was
+ not phrased correctly.
+
+ * The code to ask for password did not fall back to the terminal
+ input when GIT_ASKPASS is set but does not work (e.g. lack of X
+ with GUI askpass helper).
+
+ * We failed to give the true terminal width to any subcommand when
+ they are invoked with the pager, i.e. "git -p cmd".
+
+ * map_user() was not rewriting its output correctly, which resulted
+ in the user visible symptom that "git blame -e" sometimes showed
+ excess '>' at the end of email addresses.
+
+ * "git checkout -b" did not allow switching out of an unborn branch.
+
+ * When you have both .../foo and .../foo.git, "git clone .../foo" did not
+ favor the former but the latter.
+
+ * "git commit" refused to create a commit when entries added with
+ "add -N" remained in the index, without telling Git what their content
+ in the next commit should be. We should have created the commit without
+ these paths.
+
+ * "git diff --stat" said "files", "insertions", and "deletions" even
+ when it is showing one "file", one "insertion" or one "deletion".
+
+ * The output from "git diff --stat" for two paths that have the same
+ amount of changes showed graph bars of different length due to the
+ way we handled rounding errors.
+
+ * "git grep" did not pay attention to -diff (hence -binary) attribute.
+
+ * The transport programs (fetch, push, clone)ignored --no-progress
+ and showed progress when sending their output to a terminal.
+
+ * Sometimes error status detected by a check in an earlier phase of
+ "git receive-pack" (the other end of "git push") was lost by later
+ checks, resulting in false indication of success.
+
+ * "git rev-list --verify" sometimes skipped verification depending on
+ the phase of the moon, which dates back to 1.7.8.x series.
+
+ * Search box in "gitweb" did not accept non-ASCII characters correctly.
+
+ * Search interface of "gitweb" did not show multiple matches in the same file
+ correctly.
+
+Also contains minor fixes and documentation updates.
diff --git a/RelNotes/1.7.9.3.adoc b/RelNotes/1.7.9.3.adoc
new file mode 100644
index 0000000..91c6501
--- /dev/null
+++ b/RelNotes/1.7.9.3.adoc
@@ -0,0 +1,51 @@
+Git v1.7.9.3 Release Notes
+==========================
+
+Fixes since v1.7.9.2
+--------------------
+
+ * "git p4" (in contrib/) submit the changes to a wrong place when the
+ "--use-client-spec" option is set.
+
+ * The config.mak.autogen generated by optional autoconf support tried
+ to link the binary with -lintl even when libintl.h is missing from
+ the system.
+
+ * When the filter driver exits before reading the content before the
+ main git process writes the contents to be filtered to the pipe to
+ it, the latter could be killed with SIGPIPE instead of ignoring
+ such an event as an error.
+
+ * "git add --refresh <pathspec>" used to warn about unmerged paths
+ outside the given pathspec.
+
+ * The bulk check-in codepath in "git add" streamed contents that
+ needs smudge/clean filters without running them, instead of punting
+ and delegating to the codepath to run filters after slurping
+ everything to core.
+
+ * "git branch --with $that" assumed incorrectly that the user will never
+ ask the question with nonsense value in $that.
+
+ * "git bundle create" produced a corrupt bundle file upon seeing
+ commits with excessively long subject line.
+
+ * When a remote helper exits before reading the blank line from the
+ main git process to signal the end of commands, the latter could be
+ killed with SIGPIPE. Instead we should ignore such event as a
+ non-error.
+
+ * The commit log template given with "git merge --edit" did not have
+ a short instructive text like what "git commit" gives.
+
+ * "git rev-list --verify-objects -q" omitted the extra verification
+ it needs to do over "git rev-list --objects -q" by mistake.
+
+ * "gitweb" used to drop warnings in the log file when "heads" view is
+ accessed in a repository whose HEAD does not point at a valid
+ branch.
+
+ * An invalid regular expression pattern given by an end user made
+ "gitweb" to return garbled response.
+
+Also contains minor fixes and documentation updates.
diff --git a/RelNotes/1.7.9.4.adoc b/RelNotes/1.7.9.4.adoc
new file mode 100644
index 0000000..e5217a1
--- /dev/null
+++ b/RelNotes/1.7.9.4.adoc
@@ -0,0 +1,24 @@
+Git v1.7.9.4 Release Notes
+==========================
+
+Fixes since v1.7.9.3
+--------------------
+
+ * The code to synthesize the fake ancestor tree used by 3-way merge
+ fallback in "git am" was not prepared to read a patch created with
+ a non-standard -p<num> value.
+
+ * "git bundle" did not record boundary commits correctly when there
+ are many of them.
+
+ * "git diff-index" and its friends at the plumbing level showed the
+ "diff --git" header and nothing else for a path whose cached stat
+ info is dirty without actual difference when asked to produce a
+ patch. This was a longstanding bug that we could have fixed long
+ time ago.
+
+ * "gitweb" did use quotemeta() to prepare search string when asked to
+ do a fixed-string project search, but did not use it by mistake and
+ used the user-supplied string instead.
+
+Also contains minor fixes and documentation updates.
diff --git a/RelNotes/1.7.9.5.adoc b/RelNotes/1.7.9.5.adoc
new file mode 100644
index 0000000..95cc2bb
--- /dev/null
+++ b/RelNotes/1.7.9.5.adoc
@@ -0,0 +1,23 @@
+Git v1.7.9.5 Release Notes
+==========================
+
+Fixes since v1.7.9.4
+--------------------
+
+ * When "git config" diagnoses an error in a configuration file and
+ shows the line number for the offending line, it miscounted if the
+ error was at the end of line.
+
+ * "git fast-import" accepted "ls" command with an empty path by
+ mistake.
+
+ * Various new-ish output decoration modes of "git grep" were not
+ documented in the manual's synopsis section.
+
+ * The "remaining" subcommand to "git rerere" was not documented.
+
+ * "gitweb" used to drop warnings in the log file when "heads" view is
+ accessed in a repository whose HEAD does not point at a valid
+ branch.
+
+Also contains minor fixes and documentation updates.
diff --git a/RelNotes/1.7.9.6.adoc b/RelNotes/1.7.9.6.adoc
new file mode 100644
index 0000000..74bf882
--- /dev/null
+++ b/RelNotes/1.7.9.6.adoc
@@ -0,0 +1,12 @@
+Git v1.7.9.6 Release Notes
+==========================
+
+Fixes since v1.7.9.5
+--------------------
+
+ * "git merge $tag" to merge an annotated tag always opens the editor
+ during an interactive edit session. v1.7.10 series introduced an
+ environment variable GIT_MERGE_AUTOEDIT to help older scripts decline
+ this behaviour, but the maintenance track should also support it.
+
+Also contains minor fixes and documentation updates.
diff --git a/RelNotes/1.7.9.7.adoc b/RelNotes/1.7.9.7.adoc
new file mode 100644
index 0000000..59667d0
--- /dev/null
+++ b/RelNotes/1.7.9.7.adoc
@@ -0,0 +1,13 @@
+Git v1.7.9.7 Release Notes
+==========================
+
+Fixes since v1.7.9.6
+--------------------
+
+ * An error message from 'git bundle' had an unmatched single quote pair in it.
+
+ * The way 'git fetch' implemented its connectivity check over
+ received objects was overly pessimistic, and wasted a lot of
+ cycles.
+
+Also contains minor fixes and documentation updates.
diff --git a/RelNotes/1.7.9.adoc b/RelNotes/1.7.9.adoc
new file mode 100644
index 0000000..95320aa
--- /dev/null
+++ b/RelNotes/1.7.9.adoc
@@ -0,0 +1,112 @@
+Git v1.7.9 Release Notes
+========================
+
+Updates since v1.7.8
+--------------------
+
+ * gitk updates accumulated since early 2011.
+
+ * git-gui updated to 0.16.0.
+
+ * git-p4 (in contrib/) updates.
+
+ * Git uses gettext to translate its most common interface messages
+ into the user's language if translations are available and the
+ locale is appropriately set. Distributors can drop new PO files
+ in po/ to add new translations.
+
+ * The code to handle username/password for HTTP transactions used in
+ "git push" & "git fetch" learned to talk "credential API" to
+ external programs to cache or store them, to allow integration with
+ platform native keychain mechanisms.
+
+ * The input prompts in the terminal use our own getpass() replacement
+ when possible. HTTP transactions used to ask for the username without
+ echoing back what was typed, but with this change you will see it as
+ you type.
+
+ * The internals of "revert/cherry-pick" have been tweaked to prepare
+ building more generic "sequencer" on top of the implementation that
+ drives them.
+
+ * "git rev-parse FETCH_HEAD" after "git fetch" without specifying
+ what to fetch from the command line will now show the commit that
+ would be merged if the command were "git pull".
+
+ * "git add" learned to stream large files directly into a packfile
+ instead of writing them into individual loose object files.
+
+ * "git checkout -B <current branch> <elsewhere>" is a more intuitive
+ way to spell "git reset --keep <elsewhere>".
+
+ * "git checkout" and "git merge" learned "--no-overwrite-ignore" option
+ to tell Git that untracked and ignored files are not expendable.
+
+ * "git commit --amend" learned "--no-edit" option to say that the
+ user is amending the tree being recorded, without updating the
+ commit log message.
+
+ * "git commit" and "git reset" re-learned the optimization to prime
+ the cache-tree information in the index, which makes it faster to
+ write a tree object out after the index entries are updated.
+
+ * "git commit" detects and rejects an attempt to stuff NUL byte in
+ the commit log message.
+
+ * "git commit" learned "-S" to GPG-sign the commit; this can be shown
+ with the "--show-signature" option to "git log".
+
+ * fsck and prune are relatively lengthy operations that still go
+ silent while making the end-user wait. They learned to give progress
+ output like other slow operations.
+
+ * The set of built-in function-header patterns for various languages
+ knows MATLAB.
+
+ * "git log --format='<format>'" learned new %g[nNeE] specifiers to
+ show information from the reflog entries when walking the reflog
+ (i.e. with "-g").
+
+ * "git pull" can be used to fetch and merge an annotated/signed tag,
+ instead of the tip of a topic branch. The GPG signature from the
+ signed tag is recorded in the resulting merge commit for later
+ auditing.
+
+ * "git log" learned "--show-signature" option to show the signed tag
+ that was merged that is embedded in the merge commit. It also can
+ show the signature made on the commit with "git commit -S".
+
+ * "git branch --edit-description" can be used to add descriptive text
+ to explain what a topic branch is about.
+
+ * "git fmt-merge-msg" learned to take the branch description into
+ account when preparing a merge summary that "git merge" records
+ when merging a local branch.
+
+ * "git request-pull" has been updated to convey more information
+ useful for integrators to decide if a topic is worth merging and
+ what is pulled is indeed what the requestor asked to pull,
+ including:
+
+ - the tip of the branch being requested to be merged;
+ - the branch description describing what the topic is about;
+ - the contents of the annotated tag, when requesting to pull a tag.
+
+ * "git pull" learned to notice 'pull.rebase' configuration variable,
+ which serves as a global fallback for setting 'branch.<name>.rebase'
+ configuration variable per branch.
+
+ * "git tag" learned "--cleanup" option to control how the whitespaces
+ and empty lines in tag message are cleaned up.
+
+ * "gitweb" learned to show side-by-side diff.
+
+Also contains minor documentation updates and code clean-ups.
+
+
+Fixes since v1.7.8
+------------------
+
+Unless otherwise noted, all the fixes since v1.7.8 in the maintenance
+releases are contained in this release (see release notes to them for
+details).
diff --git a/RelNotes/1.8.0.1.adoc b/RelNotes/1.8.0.1.adoc
new file mode 100644
index 0000000..1f372fa
--- /dev/null
+++ b/RelNotes/1.8.0.1.adoc
@@ -0,0 +1,64 @@
+Git v1.8.0.1 Release Notes
+==========================
+
+Fixes since v1.8.0
+------------------
+
+ * The configuration parser had an unnecessary hardcoded limit on
+ variable names that was not checked consistently.
+
+ * The "say" function in the test scaffolding incorrectly allowed
+ "echo" to interpret "\a" as if it were a C-string asking for a
+ BEL output.
+
+ * "git mergetool" feeds /dev/null as a common ancestor when dealing
+ with an add/add conflict, but p4merge backend cannot handle
+ it. Work it around by passing a temporary empty file.
+
+ * "git log -F -E --grep='<ere>'" failed to use the given <ere>
+ pattern as extended regular expression, and instead looked for the
+ string literally.
+
+ * "git grep -e pattern <tree>" asked the attribute system to read
+ "<tree>:.gitattributes" file in the working tree, which was
+ nonsense.
+
+ * A symbolic ref refs/heads/SYM was not correctly removed with "git
+ branch -d SYM"; the command removed the ref pointed by SYM
+ instead.
+
+ * Earlier we fixed documentation to hyphenate "remote-tracking branch"
+ to clarify that these are not a remote entity, but unhyphenated
+ spelling snuck in to a few places since then.
+
+ * "git pull --rebase" run while the HEAD is detached tried to find
+ the upstream branch of the detached HEAD (which by definition
+ does not exist) and emitted unnecessary error messages.
+
+ * The refs/replace hierarchy was not mentioned in the
+ repository-layout docs.
+
+ * Sometimes curl_multi_timeout() function suggested a wrong timeout
+ value when there is no file descriptors to wait on and the http
+ transport ended up sleeping for minutes in select(2) system call.
+ A workaround has been added for this.
+
+ * Various rfc2047 quoting issues around a non-ASCII name on the
+ From: line in the output from format-patch have been corrected.
+
+ * "git diff -G<pattern>" did not honor textconv filter when looking
+ for changes.
+
+ * Bash completion script (in contrib/) did not correctly complete a
+ lazy "git checkout $name_of_remote_tracking_branch_that_is_unique"
+ command line.
+
+ * RSS feed from "gitweb" had a xss hole in its title output.
+
+ * "git config --path $key" segfaulted on "[section] key" (a boolean
+ "true" spelled without "=", not "[section] key = true").
+
+ * "git checkout -b foo" while on an unborn branch did not say
+ "Switched to a new branch 'foo'" like other cases.
+
+Also contains other minor fixes and documentation updates.
diff --git a/RelNotes/1.8.0.2.adoc b/RelNotes/1.8.0.2.adoc
new file mode 100644
index 0000000..8497e05
--- /dev/null
+++ b/RelNotes/1.8.0.2.adoc
@@ -0,0 +1,34 @@
+Git v1.8.0.2 Release Notes
+==========================
+
+Fixes since v1.8.0.1
+--------------------
+
+ * Various codepaths have workaround for a common misconfiguration to
+ spell "UTF-8" as "utf8", but it was not used uniformly. Most
+ notably, mailinfo (which is used by "git am") lacked this support.
+
+ * We failed to mention a file without any content change but whose
+ permission bit was modified, or (worse yet) a new file without any
+ content in the "git diff --stat" output.
+
+ * When "--stat-count" hides a diffstat for binary contents, the total
+ number of added and removed lines at the bottom was computed
+ incorrectly.
+
+ * When "--stat-count" hides a diffstat for unmerged paths, the total
+ number of affected files at the bottom of the "diff --stat" output
+ was computed incorrectly.
+
+ * "diff --shortstat" miscounted the total number of affected files
+ when there were unmerged paths.
+
+ * "git p4" used to try expanding malformed "$keyword$" that spans
+ across multiple lines.
+
+ * "git update-ref -d --deref SYM" to delete a ref through a symbolic
+ ref that points to it did not remove it correctly.
+
+ * Syntax highlighting in "gitweb" was not quite working.
+
+Also contains other minor fixes and documentation updates.
diff --git a/RelNotes/1.8.0.3.adoc b/RelNotes/1.8.0.3.adoc
new file mode 100644
index 0000000..92b1e4b
--- /dev/null
+++ b/RelNotes/1.8.0.3.adoc
@@ -0,0 +1,14 @@
+Git v1.8.0.3 Release Notes
+==========================
+
+Fixes since v1.8.0.2
+--------------------
+
+ * "git log -p -S<string>" did not apply the textconv filter while
+ looking for the <string>.
+
+ * In the documentation, some invalid example e-mail addresses were
+ formatted into mailto: links.
+
+Also contains many documentation updates backported from the 'master'
+branch that is preparing for the upcoming 1.8.1 release.
diff --git a/RelNotes/1.8.0.adoc b/RelNotes/1.8.0.adoc
new file mode 100644
index 0000000..63d6e4a
--- /dev/null
+++ b/RelNotes/1.8.0.adoc
@@ -0,0 +1,267 @@
+Git v1.8.0 Release Notes
+========================
+
+Backward compatibility notes
+----------------------------
+
+In the next major release (not *this* one), we will change the
+behavior of the "git push" command.
+
+When "git push [$there]" does not say what to push, we have used the
+traditional "matching" semantics so far (all your branches were sent
+to the remote as long as there already are branches of the same name
+over there). We will use the "simple" semantics that pushes the
+current branch to the branch with the same name, only when the current
+branch is set to integrate with that remote branch. There is a user
+preference configuration variable "push.default" to change this, and
+"git push" will warn about the upcoming change until you set this
+variable in this release.
+
+"git branch --set-upstream" is deprecated and may be removed in a
+relatively distant future. "git branch [-u|--set-upstream-to]" has
+been introduced with a saner order of arguments.
+
+
+Updates since v1.7.12
+---------------------
+
+UI, Workflows & Features
+
+ * A credential helper for Win32 to allow access to the keychain of
+ the logged-in user has been added.
+
+ * An initial port to HP NonStop.
+
+ * A credential helper to allow access to the Gnome keyring has been
+ added.
+
+ * When "git am" sanitizes the "Subject:" line, we strip the prefix from
+ "Re: subject" and also from a less common "re: subject", but left
+ the even less common "RE: subject" intact. Now we strip that too.
+
+ * It was tempting to say "git branch --set-upstream origin/master",
+ but that tells Git to arrange the local branch "origin/master" to
+ integrate with the currently checked out branch, which is highly
+ unlikely what the user meant. The option is deprecated; use the
+ new "--set-upstream-to" (with a short-and-sweet "-u") option
+ instead.
+
+ * "git cherry-pick" learned the "--allow-empty-message" option to
+ allow it to replay a commit without any log message.
+
+ * After "git cherry-pick -s" gave control back to the user asking
+ help to resolve conflicts, concluding "git commit" used to need to
+ be run with "-s" if the user wants to sign it off; now the command
+ leaves the sign-off line in the log template.
+
+ * "git daemon" learned the "--access-hook" option to allow an
+ external command to decline service based on the client address,
+ repository path, etc.
+
+ * "git difftool --dir-diff" learned to use symbolic links to prepare
+ a temporary copy of the working tree when available.
+
+ * "git grep" learned to use a non-standard pattern type by default if
+ a configuration variable tells it to.
+
+ * Accumulated updates to "git gui" has been merged.
+
+ * "git log -g" learned the "--grep-reflog=<pattern>" option to limit
+ its output to commits with a reflog message that matches the given
+ pattern.
+
+ * "git merge-base" learned the "--is-ancestor A B" option to tell if A is
+ an ancestor of B. The result is indicated by its exit status code.
+
+ * "git mergetool" now allows users to override the actual command used
+ with the mergetool.$name.cmd configuration variable even for built-in
+ mergetool backends.
+
+ * "git rebase -i" learned the "--edit-todo" option to open an editor
+ to edit the instruction sheet.
+
+
+Foreign Interface
+
+ * "git svn" has been updated to work with SVN 1.7.
+
+ * "git p4" learned the "--conflicts" option to specify what to do when
+ encountering a conflict during "p4 submit".
+
+
+Performance, Internal Implementation, etc.
+
+ * Git ships with a fall-back regexp implementation for platforms with
+ buggy regexp library, but it was easy for people to keep using their
+ platform regexp by mistake. A new test has been added to check this.
+
+ * The "check-docs" build target has been updated and greatly
+ simplified.
+
+ * The test suite is run under MALLOC_CHECK_ when running with a glibc
+ that supports the feature.
+
+ * The documentation in the TeXinfo format was using indented output
+ for materials meant to be examples that are better typeset in
+ monospace.
+
+ * Compatibility wrapper around some mkdir(2) implementations that
+ reject parameters with trailing slash has been introduced.
+
+ * Compatibility wrapper for systems that lack usable setitimer() has
+ been added.
+
+ * The option parsing of "git checkout" had error checking, dwim and
+ defaulting missing options, all mixed in the code, and issuing an
+ appropriate error message with useful context was getting harder.
+ The code has been reorganized to allow giving a proper diagnosis
+ when the user says "git checkout -b -t foo bar" (e.g. "-t" is not a
+ good name for a branch).
+
+ * Many internal uses of a "git merge-base" equivalent were only to see
+ if one commit fast-forwards to the other, which did not need the
+ full set of merge bases to be computed. They have been updated to
+ use less expensive checks.
+
+ * The heuristics to detect and silently convert latin1 to utf8 when
+ we were told to use utf-8 in the log message has been transplanted
+ from "mailinfo" to "commit" and "commit-tree".
+
+ * Messages given by "git <subcommand> -h" from many subcommands have
+ been marked for translation.
+
+
+Also contains minor documentation updates and code clean-ups.
+
+
+Fixes since v1.7.12
+-------------------
+
+Unless otherwise noted, all the fixes since v1.7.12 in the
+maintenance track are contained in this release (see release notes
+to them for details).
+
+ * The attribute system may be asked for a path that itself or its
+ leading directories no longer exists in the working tree, and it is
+ fine if we cannot open .gitattribute file in such a case. Failure
+ to open per-directory .gitattributes with error status other than
+ ENOENT and ENOTDIR should be diagnosed, but it wasn't.
+
+ * When looking for $HOME/.gitconfig etc., it is OK if we cannot read
+ them because they do not exist, but we did not diagnose existing
+ files that we cannot read.
+
+ * When "git am" is fed an input that has multiple "Content-type: ..."
+ header, it did not grok charset= attribute correctly.
+
+ * "git am" mishandled a patch attached as application/octet-stream
+ (e.g. not text/*); Content-Transfer-Encoding (e.g. base64) was not
+ honored correctly.
+
+ * "git blame MAKEFILE" run in a history that has "Makefile" but not
+ "MAKEFILE" should say "No such file MAKEFILE in HEAD", but got
+ confused on a case insensitive filesystem and failed to do so.
+
+ * Even during a conflicted merge, "git blame $path" always meant to
+ blame uncommitted changes to the "working tree" version; make it
+ more useful by showing cleanly merged parts as coming from the other
+ branch that is being merged.
+
+ * It was unclear in the documentation for "git blame" that it is
+ unnecessary for users to use the "--follow" option.
+
+ * Output from "git branch -v" contains "(no branch)" that could be
+ localized, but the code to align it along with the names of
+ branches was counting in bytes, not in display columns.
+
+ * "git cherry-pick A C B" used to replay changes in A and then B and
+ then C if these three commits had committer timestamps in that
+ order, which is not what the user who said "A C B" naturally
+ expects.
+
+ * A repository created with "git clone --single" had its fetch
+ refspecs set up just like a clone without "--single", leading the
+ subsequent "git fetch" to slurp all the other branches, defeating
+ the whole point of specifying "only this branch".
+
+ * Documentation talked about "first line of commit log" when it meant
+ the title of the commit. The description was clarified by defining
+ how the title is decided and rewording the casual mention of "first
+ line" to "title".
+
+ * "git cvsimport" did not thoroughly cleanse tag names that it
+ inferred from the names of the tags it obtained from CVS, which
+ caused "git tag" to barf and stop the import in the middle.
+
+ * Earlier we made the diffstat summary line that shows the number of
+ lines added/deleted localizable, but it was found irritating having
+ to see them in various languages on a list whose discussion language
+ is English, and this change has been reverted.
+
+ * "git fetch --all", when passed "--no-tags", did not honor the
+ "--no-tags" option while fetching from individual remotes (the same
+ issue existed with "--tags", but the combination "--all --tags" makes
+ much less sense than "--all --no-tags").
+
+ * "git fetch" over http had an old workaround for an unlikely server
+ misconfiguration; it turns out that this hurts debuggability of the
+ configuration in general, and has been reverted.
+
+ * "git fetch" over http advertised that it supports "deflate", which
+ is much less common, and did not advertise the more common "gzip" on
+ its Accept-Encoding header.
+
+ * "git fetch" over the dumb-http revision walker could segfault when
+ curl's multi interface was used.
+
+ * "git gc --auto" notified the user that auto-packing has triggered
+ even under the "--quiet" option.
+
+ * After "gitk" showed the contents of a tag, neither "Reread
+ references" nor "Reload" updated what is shown as the
+ contents of it when the user overwrote the tag with "git tag -f".
+
+ * "git log --all-match --grep=A --grep=B" ought to show commits that
+ mention both A and B, but when these three options are used with
+ --author or --committer, it showed commits that mention either A or
+ B (or both) instead.
+
+ * The "-Xours" backend option to "git merge -s recursive" was ignored
+ for binary files.
+
+ * "git p4", when "--use-client-spec" and "--detect-branches" are used
+ together, misdetected branches.
+
+ * "git receive-pack" (the counterpart to "git push") did not give
+ progress output while processing objects it received to the user
+ when run over the smart-http protocol.
+
+ * When you misspell the command name you give to the "exec" action in
+ the "git rebase -i" instruction sheet you were told that 'rebase' is not a
+ git subcommand from "git rebase --continue".
+
+ * The subcommand in "git remote" to remove a defined remote was
+ "rm" and the command did not take a fully-spelled "remove".
+
+ * The interactive prompt that "git send-email" gives was error prone. It
+ asked "What e-mail address do you want to use?" with the address it
+ guessed (correctly) the user would want to use in its prompt,
+ tempting the user to say "y". But the response was taken as "No,
+ please use 'y' as the e-mail address instead", which is most
+ certainly not what the user meant.
+
+ * "git show --format='%ci'" did not give the timestamp correctly for
+ commits created without human readable name on the "committer" line.
+
+ * "git show --quiet" ought to be a synonym for "git show -s", but
+ wasn't.
+
+ * "git submodule frotz" was not diagnosed as "frotz" being an unknown
+ subcommand to "git submodule"; the user instead got a complaint
+ that "git submodule status" was run with an unknown path "frotz".
+
+ * "git status" honored the ignore=dirty settings in .gitmodules but
+ "git commit" didn't.
+
+ * "gitweb" did not give the correct committer timezone in its feed
+ output due to a typo.
diff --git a/RelNotes/1.8.1.1.adoc b/RelNotes/1.8.1.1.adoc
new file mode 100644
index 0000000..6cde07b
--- /dev/null
+++ b/RelNotes/1.8.1.1.adoc
@@ -0,0 +1,87 @@
+Git 1.8.1.1 Release Notes
+=========================
+
+Fixes since v1.8.1
+------------------
+
+ * The attribute mechanism didn't allow limiting attributes to be
+ applied to only a single directory itself with "path/" like the
+ exclude mechanism does.
+
+ * When attempting to read the XDG-style $HOME/.config/git/config and
+ finding that $HOME/.config/git is a file, we gave a wrong error
+ message, instead of treating the case as "a custom config file does
+ not exist there" and moving on.
+
+ * After failing to create a temporary file using mkstemp(), failing
+ pathname was not reported correctly on some platforms.
+
+ * http transport was wrong to ask for the username when the
+ authentication is done by certificate identity.
+
+ * The behaviour visible to the end users was confusing, when they
+ attempt to kill a process spawned in the editor that was in turn
+ launched by Git with SIGINT (or SIGQUIT), as Git would catch that
+ signal and die. We ignore these signals now.
+
+ * A child process that was killed by a signal (e.g. SIGINT) was
+ reported in an inconsistent way depending on how the process was
+ spawned by us, with or without a shell in between.
+
+ * After "git add -N" and then writing a tree object out of the
+ index, the cache-tree data structure got corrupted.
+
+ * "git apply" misbehaved when fixing whitespace breakages by removing
+ excess trailing blank lines in some corner cases.
+
+ * A tar archive created by "git archive" recorded a directory in a
+ way that made NetBSD's implementation of "tar" sometimes unhappy.
+
+ * When "git clone --separate-git-dir=$over_there" is interrupted, it
+ failed to remove the real location of the $GIT_DIR it created.
+ This was most visible when interrupting a submodule update.
+
+ * "git fetch --mirror" and fetch that uses other forms of refspec
+ with wildcard used to attempt to update a symbolic ref that match
+ the wildcard on the receiving end, which made little sense (the
+ real ref that is pointed at by the symbolic ref would be updated
+ anyway). Symbolic refs no longer are affected by such a fetch.
+
+ * The "log --graph" codepath fell into infinite loop in some
+ corner cases.
+
+ * "git merge" started calling prepare-commit-msg hook like "git
+ commit" does some time ago, but forgot to pay attention to the exit
+ status of the hook.
+
+ * "git pack-refs" that ran in parallel to another process that
+ created new refs had a race that can lose new ones.
+
+ * When a line to be wrapped has a solid run of non space characters
+ whose length exactly is the wrap width, "git shortlog -w" failed
+ to add a newline after such a line.
+
+ * The way "git svn" asked for password using SSH_ASKPASS and
+ GIT_ASKPASS was not in line with the rest of the system.
+
+ * "gitweb", when sorting by age to show repositories with new
+ activities first, used to sort repositories with absolutely
+ nothing in it early, which was not very useful.
+
+ * "gitweb", when sorting by age to show repositories with new
+ activities first, used to sort repositories with absolutely
+ nothing in it early, which was not very useful.
+
+ * When autoconf is used, any build on a different commit always ran
+ "config.status --recheck" even when unnecessary.
+
+ * Some scripted programs written in Python did not get updated when
+ PYTHON_PATH changed.
+
+ * We have been carrying a translated and long-unmaintained copy of an
+ old version of the tutorial; removed.
+
+ * Portability issues in many self-test scripts have been addressed.
+
+
+Also contains other minor fixes and documentation updates.
diff --git a/RelNotes/1.8.1.2.adoc b/RelNotes/1.8.1.2.adoc
new file mode 100644
index 0000000..5ab7b18
--- /dev/null
+++ b/RelNotes/1.8.1.2.adoc
@@ -0,0 +1,25 @@
+Git 1.8.1.2 Release Notes
+=========================
+
+Fixes since v1.8.1.1
+--------------------
+
+ * An element on GIT_CEILING_DIRECTORIES list that does not name the
+ real path to a directory (i.e. a symbolic link) could have caused
+ the GIT_DIR discovery logic to escape the ceiling.
+
+ * Command line completion for "tcsh" emitted an unwanted space
+ after completing a single directory name.
+
+ * Command line completion leaked an unnecessary error message while
+ looking for possible matches with paths in <tree-ish>.
+
+ * "git archive" did not record uncompressed size in the header when
+ streaming a zip archive, which confused some implementations of unzip.
+
+ * When users spelled "cc:" in lowercase in the fake "header" in the
+ trailer part, "git send-email" failed to pick up the addresses from
+ there. As e-mail headers field names are case insensitive, this
+ script should follow suit and treat "cc:" and "Cc:" the same way.
+
+Also contains various documentation fixes.
diff --git a/RelNotes/1.8.1.3.adoc b/RelNotes/1.8.1.3.adoc
new file mode 100644
index 0000000..681cb35
--- /dev/null
+++ b/RelNotes/1.8.1.3.adoc
@@ -0,0 +1,47 @@
+Git 1.8.1.3 Release Notes
+=========================
+
+Fixes since v1.8.1.2
+--------------------
+
+ * The attribute mechanism didn't allow limiting attributes to be
+ applied to only a single directory itself with "path/" like the
+ exclude mechanism does. The fix for this in 1.8.1.2 had
+ performance degradations.
+
+ * Command line completion code was inadvertently made incompatible with
+ older versions of bash by using a newer array notation.
+
+ * Scripts to test bash completion was inherently flaky as it was
+ affected by whatever random things the user may have on $PATH.
+
+ * A fix was added to the build procedure to work around buggy
+ versions of ccache broke the auto-generation of dependencies, which
+ unfortunately is still relevant because some people use ancient
+ distros.
+
+ * We used to stuff "user@" and then append what we read from
+ /etc/mailname to come up with a default e-mail ident, but a bug
+ lost the "user@" part.
+
+ * "git am" did not parse datestamp correctly from Hg generated patch,
+ when it is run in a locale outside C (or en).
+
+ * Attempt to "branch --edit-description" an existing branch, while
+ being on a detached HEAD, errored out.
+
+ * "git cherry-pick" did not replay a root commit to an unborn branch.
+
+ * We forgot to close the file descriptor reading from "gpg" output,
+ killing "git log --show-signature" on a long history.
+
+ * "git rebase --preserve-merges" lost empty merges in recent versions
+ of Git.
+
+ * Rebasing the history of superproject with change in the submodule
+ has been broken since v1.7.12.
+
+ * A failure to push due to non-ff while on an unborn branch
+ dereferenced a NULL pointer when showing an error message.
+
+Also contains various documentation fixes.
diff --git a/RelNotes/1.8.1.4.adoc b/RelNotes/1.8.1.4.adoc
new file mode 100644
index 0000000..22af1d1
--- /dev/null
+++ b/RelNotes/1.8.1.4.adoc
@@ -0,0 +1,11 @@
+Git 1.8.1.4 Release Notes
+=========================
+
+Fixes since v1.8.1.3
+--------------------
+
+ * "git imap-send" talking over imaps:// did make sure it received a
+ valid certificate from the other end, but did not check if the
+ certificate matched the host it thought it was talking to.
+
+Also contains various documentation fixes.
diff --git a/RelNotes/1.8.1.5.adoc b/RelNotes/1.8.1.5.adoc
new file mode 100644
index 0000000..efa68ae
--- /dev/null
+++ b/RelNotes/1.8.1.5.adoc
@@ -0,0 +1,47 @@
+Git 1.8.1.5 Release Notes
+=========================
+
+Fixes since v1.8.1.4
+--------------------
+
+ * Given a string with a multi-byte character that begins with '-' on
+ the command line where an option is expected, the option parser
+ used just one byte of the unknown letter when reporting an error.
+
+ * In v1.8.1, the attribute parser was tightened too restrictive to
+ error out upon seeing an entry that begins with an ! (exclamation),
+ which may confuse users to expect a "negative match", which does
+ not exist. This has been demoted to a warning; such an entry is
+ still ignored.
+
+ * "git apply --summary" has been taught to make sure the similarity
+ value shown in its output is sensible, even when the input had a
+ bogus value.
+
+ * "git clean" showed what it was going to do, but sometimes ended
+ up finding that it was not allowed to do so, which resulted in a
+ confusing output (e.g. after saying that it will remove an
+ untracked directory, it found an embedded git repository there
+ which it is not allowed to remove). It now performs the actions
+ and then reports the outcome more faithfully.
+
+ * "git clone" used to allow --bare and --separate-git-dir=$there
+ options at the same time, which was nonsensical.
+
+ * "git cvsimport" mishandled timestamps at DST boundary.
+
+ * We used to have an arbitrary 32 limit for combined diff input,
+ resulting in incorrect number of leading colons shown when showing
+ the "--raw --cc" output.
+
+ * The smart HTTP clients forgot to verify the content-type that comes
+ back from the server side to make sure that the request is being
+ handled properly.
+
+ * "git help remote-helpers" failed to find the documentation.
+
+ * "gitweb" pages served over HTTPS, when configured to show picon or
+ gravatar, referred to these external resources to be fetched via
+ HTTP, resulting in mixed contents warning in browsers.
+
+Also contains various documentation fixes.
diff --git a/RelNotes/1.8.1.6.adoc b/RelNotes/1.8.1.6.adoc
new file mode 100644
index 0000000..c15cf2e
--- /dev/null
+++ b/RelNotes/1.8.1.6.adoc
@@ -0,0 +1,39 @@
+Git 1.8.1.6 Release Notes
+=========================
+
+Fixes since v1.8.1.5
+--------------------
+
+ * An earlier change to the attribute system introduced at v1.8.1.2 by
+ mistake stopped a pattern "dir" (without trailing slash) from
+ matching a directory "dir" (it only wanted to allow pattern "dir/"
+ to also match).
+
+ * The code to keep track of what directory names are known to Git on
+ platforms with case insensitive filesystems can get confused upon a
+ hash collision between these pathnames and looped forever.
+
+ * When the "--prefix" option is used to "checkout-index", the code
+ did not pick the correct output filter based on the attribute
+ setting.
+
+ * Annotated tags outside refs/tags/ hierarchy were not advertised
+ correctly to the ls-remote and fetch with recent version of Git.
+
+ * The logic used by "git diff -M --stat" to shorten the names of
+ files before and after a rename did not work correctly when the
+ common prefix and suffix between the two filenames overlapped.
+
+ * "git update-index -h" did not do the usual "-h(elp)" thing.
+
+ * perl/Git.pm::cat_blob slurped everything in core only to write it
+ out to a file descriptor, which was not a very smart thing to do.
+
+ * The SSL peer verification done by "git imap-send" did not ask for
+ Server Name Indication (RFC 4366), failing to connect SSL/TLS
+ sites that serve multiple hostnames on a single IP.
+
+ * "git bundle verify" did not say "records a complete history" for a
+ bundle that does not have any prerequisites.
+
+Also contains various documentation fixes.
diff --git a/RelNotes/1.8.1.adoc b/RelNotes/1.8.1.adoc
new file mode 100644
index 0000000..d6f9555
--- /dev/null
+++ b/RelNotes/1.8.1.adoc
@@ -0,0 +1,241 @@
+Git v1.8.1 Release Notes
+========================
+
+Backward compatibility notes
+----------------------------
+
+In the next major release (not *this* one), we will change the
+behavior of the "git push" command.
+
+When "git push [$there]" does not say what to push, we have used the
+traditional "matching" semantics so far (all your branches were sent
+to the remote as long as there already are branches of the same name
+over there). We will use the "simple" semantics that pushes the
+current branch to the branch with the same name, only when the current
+branch is set to integrate with that remote branch. There is a user
+preference configuration variable "push.default" to change this, and
+"git push" will warn about the upcoming change until you set this
+variable in this release.
+
+"git branch --set-upstream" is deprecated and may be removed in a
+relatively distant future. "git branch [-u|--set-upstream-to]" has
+been introduced with a saner order of arguments to replace it.
+
+
+Updates since v1.8.0
+--------------------
+
+UI, Workflows & Features
+
+ * Command-line completion scripts for tcsh and zsh have been added.
+
+ * "git-prompt" scriptlet (in contrib/completion) can be told to paint
+ pieces of the hints in the prompt string in colors.
+
+ * Some documentation pages that used to ship only in the plain text
+ format are now formatted in HTML as well.
+
+ * We used to have a workaround for a bug in ancient "less" that
+ causes it to exit without any output when the terminal is resized.
+ The bug has been fixed in "less" version 406 (June 2007), and the
+ workaround has been removed in this release.
+
+ * When "git checkout" checks out a branch, it tells the user how far
+ behind (or ahead) the new branch is relative to the remote tracking
+ branch it builds upon. The message now also advises how to sync
+ them up by pushing or pulling. This can be disabled with the
+ advice.statusHints configuration variable.
+
+ * "git config --get" used to diagnose presence of multiple
+ definitions of the same variable in the same configuration file as
+ an error, but it now applies the "last one wins" rule used by the
+ internal configuration logic. Strictly speaking, this may be an
+ API regression but it is expected that nobody will notice it in
+ practice.
+
+ * A new configuration variable "diff.context" can be used to
+ give the default number of context lines in the patch output, to
+ override the hardcoded default of 3 lines.
+
+ * "git format-patch" learned the "--notes=<ref>" option to give
+ notes for the commit after the three-dash lines in its output.
+
+ * "git log -p -S<string>" now looks for the <string> after applying
+ the textconv filter (if defined); earlier it inspected the contents
+ of the blobs without filtering.
+
+ * "git log --grep=<pcre>" learned to honor the "grep.patterntype"
+ configuration set to "perl".
+
+ * "git replace -d <object>" now interprets <object> as an extended
+ SHA-1 (e.g. HEAD~4 is allowed), instead of only accepting full hex
+ object name.
+
+ * "git rm $submodule" used to punt on removing a submodule working
+ tree to avoid losing the repository embedded in it. Because
+ recent git uses a mechanism to separate the submodule repository
+ from the submodule working tree, "git rm" learned to detect this
+ case and removes the submodule working tree when it is safe to do so.
+
+ * "git send-email" used to prompt for the sender address, even when
+ the committer identity is well specified (e.g. via user.name and
+ user.email configuration variables). The command no longer gives
+ this prompt when not necessary.
+
+ * "git send-email" did not allow non-address garbage strings to
+ appear after addresses on Cc: lines in the patch files (and when
+ told to pick them up to find more recipients), e.g.
+
+ Cc: Stable Kernel <stable@k.org> # for v3.2 and up
+
+ The command now strips " # for v3.2 and up" part before adding the
+ remainder of this line to the list of recipients.
+
+ * "git submodule add" learned to add a new submodule at the same
+ path as the path where an unrelated submodule was bound to in an
+ existing revision via the "--name" option.
+
+ * "git submodule sync" learned the "--recursive" option.
+
+ * "diff.submodule" configuration variable can be used to give custom
+ default value to the "git diff --submodule" option.
+
+ * "git symbolic-ref" learned the "-d $symref" option to delete the
+ named symbolic ref, which is more intuitive way to spell it than
+ "update-ref -d --no-deref $symref".
+
+
+Foreign Interface
+
+ * "git cvsimport" can be told to record timezones (other than GMT)
+ per-author via its author info file.
+
+ * The remote helper interface to interact with subversion
+ repositories (one of the GSoC 2012 projects) has been merged.
+
+ * A new remote-helper interface for Mercurial has been added to
+ contrib/remote-helpers.
+
+ * The documentation for git(1) was pointing at a page at an external
+ site for the list of authors that no longer existed. The link has
+ been updated to point at an alternative site.
+
+
+Performance, Internal Implementation, etc.
+
+ * Compilation on Cygwin with newer header files are supported now.
+
+ * A couple of low-level implementation updates on MinGW.
+
+ * The logic to generate the initial advertisement from "upload-pack"
+ (i.e. what is invoked by "git fetch" on the other side of the
+ connection) to list what refs are available in the repository has
+ been optimized.
+
+ * The logic to find set of attributes that match a given path has
+ been optimized.
+
+ * Use preloadindex in "git diff-index" and "git update-index", which
+ has a nice speedup on systems with slow stat calls (and even on
+ Linux).
+
+
+Also contains minor documentation updates and code clean-ups.
+
+
+Fixes since v1.8.0
+------------------
+
+Unless otherwise noted, all the fixes since v1.8.0 in the maintenance
+track are contained in this release (see release notes to them for
+details).
+
+ * The configuration parser had an unnecessary hardcoded limit on
+ variable names that was not checked consistently.
+
+ * The "say" function in the test scaffolding incorrectly allowed
+ "echo" to interpret "\a" as if it were a C-string asking for a
+ BEL output.
+
+ * "git mergetool" feeds /dev/null as a common ancestor when dealing
+ with an add/add conflict, but p4merge backend cannot handle
+ it. Work it around by passing a temporary empty file.
+
+ * "git log -F -E --grep='<ere>'" failed to use the given <ere>
+ pattern as extended regular expression, and instead looked for the
+ string literally.
+
+ * "git grep -e pattern <tree>" asked the attribute system to read
+ "<tree>:.gitattributes" file in the working tree, which was
+ nonsense.
+
+ * A symbolic ref refs/heads/SYM was not correctly removed with "git
+ branch -d SYM"; the command removed the ref pointed by SYM
+ instead.
+
+ * Update "remote tracking branch" in the documentation to
+ "remote-tracking branch".
+
+ * "git pull --rebase" run while the HEAD is detached tried to find
+ the upstream branch of the detached HEAD (which by definition
+ does not exist) and emitted unnecessary error messages.
+
+ * The refs/replace hierarchy was not mentioned in the
+ repository-layout docs.
+
+ * Various rfc2047 quoting issues around a non-ASCII name on the
+ From: line in the output from format-patch have been corrected.
+
+ * Sometimes curl_multi_timeout() function suggested a wrong timeout
+ value when there is no file descriptor to wait on and the http
+ transport ended up sleeping for minutes in select(2) system call.
+ A workaround has been added for this.
+
+ * For a fetch refspec (or the result of applying wildcard on one),
+ we always want the RHS to map to something inside "refs/"
+ hierarchy, but the logic to check it was not exactly right.
+ (merge 5c08c1f jc/maint-fetch-tighten-refname-check later to maint).
+
+ * "git diff -G<pattern>" did not honor textconv filter when looking
+ for changes.
+
+ * Some HTTP servers ask for auth only during the actual packing phase
+ (not in ls-remote phase); this is not really a recommended
+ configuration, but the clients used to fail to authenticate with
+ such servers.
+ (merge 2e736fd jk/maint-http-half-auth-fetch later to maint).
+
+ * "git p4" used to try expanding malformed "$keyword$" that spans
+ across multiple lines.
+
+ * Syntax highlighting in "gitweb" was not quite working.
+
+ * RSS feed from "gitweb" had a xss hole in its title output.
+
+ * "git config --path $key" segfaulted on "[section] key" (a boolean
+ "true" spelled without "=", not "[section] key = true").
+
+ * "git checkout -b foo" while on an unborn branch did not say
+ "Switched to a new branch 'foo'" like other cases.
+
+ * Various codepaths have workaround for a common misconfiguration to
+ spell "UTF-8" as "utf8", but it was not used uniformly. Most
+ notably, mailinfo (which is used by "git am") lacked this support.
+
+ * We failed to mention a file without any content change but whose
+ permission bit was modified, or (worse yet) a new file without any
+ content in the "git diff --stat" output.
+
+ * When "--stat-count" hides a diffstat for binary contents, the total
+ number of added and removed lines at the bottom was computed
+ incorrectly.
+
+ * When "--stat-count" hides a diffstat for unmerged paths, the total
+ number of affected files at the bottom of the "diff --stat" output
+ was computed incorrectly.
+
+ * "diff --shortstat" miscounted the total number of affected files
+ when there were unmerged paths.
+
+ * "update-ref -d --deref SYM" to delete a ref through a symbolic ref
+ that points to it did not remove it correctly.
diff --git a/RelNotes/1.8.2.1.adoc b/RelNotes/1.8.2.1.adoc
new file mode 100644
index 0000000..769a6fc
--- /dev/null
+++ b/RelNotes/1.8.2.1.adoc
@@ -0,0 +1,115 @@
+Git v1.8.2.1 Release Notes
+==========================
+
+Fixes since v1.8.2
+------------------
+
+ * An earlier change to the attribute system introduced at v1.8.1.2 by
+ mistake stopped a pattern "dir" (without trailing slash) from
+ matching a directory "dir" (it only wanted to allow pattern "dir/"
+ to also match).
+
+ * Verification of signed tags were not done correctly when not in C
+ or en/US locale.
+
+ * 'git commit -m "$msg"' used to add an extra newline even when
+ $msg already ended with one.
+
+ * The "--match=<pattern>" option of "git describe", when used with
+ "--all" to allow refs that are not annotated tags to be used as a
+ base of description, did not restrict the output from the command
+ to those that match the given pattern.
+
+ * An aliased command spawned from a bare repository that does not say
+ it is bare with "core.bare = yes" is treated as non-bare by mistake.
+
+ * When "format-patch" quoted a non-ascii strings on the header files,
+ it incorrectly applied rfc2047 and chopped a single character in
+ the middle of it.
+
+ * "git archive" reports a failure when asked to create an archive out
+ of an empty tree. It would be more intuitive to give an empty
+ archive back in such a case.
+
+ * "git tag -f <tag>" always said "Updated tag '<tag>'" even when
+ creating a new tag (i.e. not overwriting nor updating).
+
+ * "git cmd -- ':(top'" was not diagnosed as an invalid syntax, and
+ instead the parser kept reading beyond the end of the string.
+
+ * Annotated tags outside refs/tags/ hierarchy were not advertised
+ correctly to the ls-remote and fetch with recent version of Git.
+
+ * The code to keep track of what directory names are known to Git on
+ platforms with case insensitive filesystems can get confused upon a
+ hash collision between these pathnames and looped forever.
+
+ * The logic used by "git diff -M --stat" to shorten the names of
+ files before and after a rename did not work correctly when the
+ common prefix and suffix between the two filenames overlapped.
+
+ * "git submodule update", when recursed into sub-submodules, did not
+ accumulate the prefix paths.
+
+ * "git am $maildir/" applied messages in an unexpected order; sort
+ filenames read from the maildir/ in a way that is more likely to
+ sort messages in the order the writing MUA meant to, by sorting
+ numeric segment in numeric order and non-numeric segment in
+ alphabetical order.
+
+ * When export-subst is used, "zip" output recorded incorrect
+ size of the file.
+
+ * Some platforms and users spell UTF-8 differently; retry with the
+ most official "UTF-8" when the system does not understand the
+ user-supplied encoding name that are the common alternative
+ spellings of UTF-8.
+
+ * "git branch" did not bother to check nonsense command line
+ parameters and issue errors in many cases.
+
+ * "git update-index -h" did not do the usual "-h(elp)" thing.
+
+ * perl/Git.pm::cat_blob slurped everything in core only to write it
+ out to a file descriptor, which was not a very smart thing to do.
+
+ * The SSL peer verification done by "git imap-send" did not ask for
+ Server Name Indication (RFC 4366), failing to connect SSL/TLS
+ sites that serve multiple hostnames on a single IP.
+
+ * "git index-pack" had a buffer-overflow while preparing an
+ informational message when the translated version of it was too
+ long.
+
+ * Clarify in the documentation "what" gets pushed to "where" when the
+ command line to "git push" does not say these explicitly.
+
+ * In "git reflog expire", REACHABLE bit was not cleared from the
+ correct objects.
+
+ * The "--color=<when>" argument to the commands in the diff family
+ was described poorly.
+
+ * The arguments given to pre-rebase hook were not documented.
+
+ * The v4 index format was not documented.
+
+ * The "--match=<pattern>" argument "git describe" takes uses glob
+ pattern but it wasn't obvious from the documentation.
+
+ * Some sources failed to compile on systems that lack NI_MAXHOST in
+ their system header (e.g. z/OS).
+
+ * Add an example use of "--env-filter" in "filter-branch"
+ documentation.
+
+ * "git bundle verify" did not say "records a complete history" for a
+ bundle that does not have any prerequisites.
+
+ * In the v1.8.0 era, we changed symbols that do not have to be global
+ to file scope static, but a few functions in graph.c were used by
+ CGit from sideways bypassing the entry points of the API the
+ in-tree users use.
+
+ * "git merge-tree" had a typo in the logic to detect d/f conflicts,
+ which caused it to segfault in some cases.
diff --git a/RelNotes/1.8.2.2.adoc b/RelNotes/1.8.2.2.adoc
new file mode 100644
index 0000000..708df1a
--- /dev/null
+++ b/RelNotes/1.8.2.2.adoc
@@ -0,0 +1,61 @@
+Git v1.8.2.2 Release Notes
+==========================
+
+Fixes since v1.8.2.1
+--------------------
+
+ * Zsh completion forgot that '%' character used to signal untracked
+ files needs to be escaped with another '%'.
+
+ * A commit object whose author or committer ident are malformed
+ crashed some code that trusted that a name, an email and an
+ timestamp can always be found in it.
+
+ * The new core.commentchar configuration was not applied to a few
+ places.
+
+ * "git pull --rebase" did not pass "-v/-q" options to underlying
+ "git rebase".
+
+ * When receive-pack detects error in the pack header it received in
+ order to decide which of unpack-objects or index-pack to run, it
+ returned without closing the error stream, which led to a hang
+ sideband thread.
+
+ * "git diff --diff-algorithm=algo" was understood by the command line
+ parser, but "git diff --diff-algorithm algo" was not.
+
+ * "git log -S/-G" started paying attention to textconv filter, but
+ there was no way to disable this. Make it honor --no-textconv
+ option.
+
+ * "git merge $(git rev-parse v1.8.2)" behaved quite differently from
+ "git merge v1.8.2", as if v1.8.2 were written as v1.8.2^0 and did
+ not pay much attention to the annotated tag payload. Make the code
+ notice the type of the tag object, in addition to the dwim_ref()
+ based classification the current code uses (i.e. the name appears
+ in refs/tags/) to decide when to special case merging of tags.
+
+ * "git cherry-pick" and "git revert" can take more than one commit
+ on the command line these days, but it was not mentioned on the usage
+ text.
+
+ * Perl scripts like "git-svn" closed (not redirecting to /dev/null)
+ the standard error stream, which is not a very smart thing to do.
+ Later open may return file descriptor #2 for unrelated purpose, and
+ error reporting code may write into them.
+
+ * "git apply --whitespace=fix" was not prepared to see a line getting
+ longer after fixing whitespaces (e.g. tab-in-indent aka Python).
+
+ * "git diff/log --cc" did not work well with options that ignore
+ whitespace changes.
+
+ * Documentation on setting up a http server that requires
+ authentication only on the push but not fetch has been clarified.
+
+ * A few bugfixes to "git rerere" working on corner case merge
+ conflicts have been applied.
+
+ * "git bundle" did not like a bundle created using a commit without
+ any message as its one of the prerequisites.
diff --git a/RelNotes/1.8.2.3.adoc b/RelNotes/1.8.2.3.adoc
new file mode 100644
index 0000000..6139482
--- /dev/null
+++ b/RelNotes/1.8.2.3.adoc
@@ -0,0 +1,19 @@
+Git v1.8.2.3 Release Notes
+==========================
+
+Fixes since v1.8.2.2
+--------------------
+
+ * "rev-list --stdin" and friends kept bogus pointers into the input
+ buffer around as human readable object names. This was not a
+ huge problem but was exposed by a new change that uses these
+ names in error output.
+
+ * When "git difftool" drove "kdiff3", it mistakenly passed --auto
+ option that was meant while resolving merge conflicts.
+
+ * "git remote add" command did not diagnose extra command line
+ arguments as an error and silently ignored them.
+
+Also contains a handful of trivial code clean-ups, documentation
+updates, updates to the test suite, etc.
diff --git a/RelNotes/1.8.2.adoc b/RelNotes/1.8.2.adoc
new file mode 100644
index 0000000..fc606ae
--- /dev/null
+++ b/RelNotes/1.8.2.adoc
@@ -0,0 +1,495 @@
+Git v1.8.2 Release Notes
+========================
+
+Backward compatibility notes (this release)
+-------------------------------------------
+
+"git push $there tag v1.2.3" used to allow replacing a tag v1.2.3
+that already exists in the repository $there, if the rewritten tag
+you are pushing points at a commit that is a descendant of a commit
+that the old tag v1.2.3 points at. This was found to be error prone
+and starting with this release, any attempt to update an existing
+ref under refs/tags/ hierarchy will fail, without "--force".
+
+When "git add -u" and "git add -A" that does not specify what paths
+to add on the command line is run from inside a subdirectory, the
+scope of the operation has always been limited to the subdirectory.
+Many users found this counter-intuitive, given that "git commit -a"
+and other commands operate on the entire tree regardless of where you
+are. In this release, these commands give a warning message that
+suggests the users to use "git add -u/-A ." when they want to limit
+the scope to the current directory; doing so will squelch the message,
+while training their fingers.
+
+
+Backward compatibility notes (for Git 2.0)
+------------------------------------------
+
+When "git push [$there]" does not say what to push, we have used the
+traditional "matching" semantics so far (all your branches were sent
+to the remote as long as there already are branches of the same name
+over there). In Git 2.0, the default will change to the "simple"
+semantics that pushes the current branch to the branch with the same
+name, only when the current branch is set to integrate with that
+remote branch. There is a user preference configuration variable
+"push.default" to change this. If you are an old-timer who is used
+to the "matching" semantics, you can set it to "matching" to keep the
+traditional behaviour. If you want to live in the future early,
+you can set it to "simple" today without waiting for Git 2.0.
+
+When "git add -u" and "git add -A", that does not specify what paths
+to add on the command line is run from inside a subdirectory, these
+commands will operate on the entire tree in Git 2.0 for consistency
+with "git commit -a" and other commands. Because there will be no
+mechanism to make "git add -u" behave as if "git add -u .", it is
+important for those who are used to "git add -u" (without pathspec)
+updating the index only for paths in the current subdirectory to start
+training their fingers to explicitly say "git add -u ." when they mean
+it before Git 2.0 comes.
+
+
+Updates since v1.8.1
+--------------------
+
+UI, Workflows & Features
+
+ * Initial ports to QNX and z/OS UNIX System Services have started.
+
+ * Output from the tests is coloured using "green is okay, yellow is
+ questionable, red is bad and blue is informative" scheme.
+
+ * Mention of "GIT/Git/git" in the documentation have been updated to
+ be more uniform and consistent. The name of the system and the
+ concept it embodies is "Git"; the command the users type is "git".
+ All-caps "GIT" was merely a way to imitate "Git" typeset in small
+ caps in our ASCII text only documentation and to be avoided.
+
+ * The completion script (in contrib/completion) used to let the
+ default completer to suggest pathnames, which gave too many
+ irrelevant choices (e.g. "git add" would not want to add an
+ unmodified path). It learnt to use a more git-aware logic to
+ enumerate only relevant ones.
+
+ * In bare repositories, "git shortlog" and other commands now read
+ mailmap files from the tip of the history, to help running these
+ tools in server settings.
+
+ * Color specifiers, e.g. "%C(blue)Hello%C(reset)", used in the
+ "--format=" option of "git log" and friends can be disabled when
+ the output is not sent to a terminal by prefixing them with
+ "auto,", e.g. "%C(auto,blue)Hello%C(auto,reset)".
+
+ * Scripts can ask Git that wildcard patterns in pathspecs they give do
+ not have any significance, i.e. take them as literal strings.
+
+ * The patterns in .gitignore and .gitattributes files can have **/,
+ as a pattern that matches 0 or more levels of subdirectory.
+ E.g. "foo/**/bar" matches "bar" in "foo" itself or in a
+ subdirectory of "foo".
+
+ * When giving arguments without "--" disambiguation, object names
+ that come earlier on the command line must not be interpretable as
+ pathspecs and pathspecs that come later on the command line must
+ not be interpretable as object names. This disambiguation rule has
+ been tweaked so that ":/" (no other string before or after) is
+ always interpreted as a pathspec; "git cmd -- :/" is no longer
+ needed, you can just say "git cmd :/".
+
+ * Various "hint" lines Git gives when it asks the user to edit
+ messages in the editor are commented out with '#' by default. The
+ core.commentchar configuration variable can be used to customize
+ this '#' to a different character.
+
+ * "git add -u" and "git add -A" without pathspec issues warning to
+ make users aware that they are only operating on paths inside the
+ subdirectory they are in. Use ":/" (everything from the top) or
+ "." (everything from the $cwd) to disambiguate.
+
+ * "git blame" (and "git diff") learned the "--no-follow" option.
+
+ * "git branch" now rejects some nonsense combinations of command line
+ arguments (e.g. giving more than one branch name to rename) with
+ more case-specific error messages.
+
+ * "git check-ignore" command to help debugging .gitignore files has
+ been added.
+
+ * "git cherry-pick" can be used to replay a root commit to an unborn
+ branch.
+
+ * "git commit" can be told to use --cleanup=whitespace by setting the
+ configuration variable commit.cleanup to 'whitespace'.
+
+ * "git diff" and other Porcelain commands can be told to use a
+ non-standard algorithm by setting diff.algorithm configuration
+ variable.
+
+ * "git fetch --mirror" and fetch that uses other forms of refspec
+ with wildcard used to attempt to update a symbolic ref that match
+ the wildcard on the receiving end, which made little sense (the
+ real ref that is pointed at by the symbolic ref would be updated
+ anyway). Symbolic refs no longer are affected by such a fetch.
+
+ * "git format-patch" now detects more cases in which a whole branch
+ is being exported, and uses the description for the branch, when
+ asked to write a cover letter for the series.
+
+ * "git format-patch" learned "-v $count" option, and prepends a
+ string "v$count-" to the names of its output files, and also
+ automatically sets the subject prefix to "PATCH v$count". This
+ allows patches from rerolled series to be stored under different
+ names and makes it easier to reuse cover letter messages.
+
+ * "git log" and friends can be told with --use-mailmap option to
+ rewrite the names and email addresses of people using the mailmap
+ mechanism.
+
+ * "git log --cc --graph" now shows the combined diff output with the
+ ancestry graph.
+
+ * "git log --grep=<pattern>" honors i18n.logoutputencoding to look
+ for the pattern after fixing the log message to the specified
+ encoding.
+
+ * "git mergetool" and "git difftool" learned to list the available
+ tool backends in a more consistent manner.
+
+ * "git mergetool" is aware of TortoiseGitMerge now and uses it over
+ TortoiseMerge when available.
+
+ * "git push" now requires "-f" to update a tag, even if it is a
+ fast-forward, as tags are meant to be fixed points.
+
+ * Error messages from "git push" when it stops to prevent remote refs
+ from getting overwritten by mistake have been improved to explain
+ various situations separately.
+
+ * "git push" will stop without doing anything if the new "pre-push"
+ hook exists and exits with a failure.
+
+ * When "git rebase" fails to generate patches to be applied (e.g. due
+ to oom), it failed to detect the failure and instead behaved as if
+ there were nothing to do. A workaround to use a temporary file has
+ been applied, but we probably would want to revisit this later, as
+ it hurts the common case of not failing at all.
+
+ * Input and preconditions to "git reset" has been loosened where
+ appropriate. "git reset $fromtree Makefile" requires $fromtree to
+ be any tree (it used to require it to be a commit), for example.
+ "git reset" (without options or parameters) used to error out when
+ you do not have any commits in your history, but it now gives you
+ an empty index (to match non-existent commit you are not even on).
+
+ * "git status" says what branch is being bisected or rebased when
+ able, not just "bisecting" or "rebasing".
+
+ * "git submodule" started learning a new mode to integrate with the
+ tip of the remote branch (as opposed to integrating with the commit
+ recorded in the superproject's gitlink).
+
+ * "git upload-pack" which implements the service "ls-remote" and
+ "fetch" talk to can be told to hide ref hierarchies the server
+ side internally uses (and that clients have no business learning
+ about) with transfer.hiderefs configuration.
+
+
+Foreign Interface
+
+ * "git fast-export" has been updated for its use in the context of
+ the remote helper interface.
+
+ * A new remote helper to interact with bzr has been added to contrib/.
+
+ * "git p4" got various bugfixes around its branch handling. It is
+ also made usable with Python 2.4/2.5. In addition, its various
+ portability issues for Cygwin have been addressed.
+
+ * The remote helper to interact with Hg in contrib/ has seen a few
+ fixes.
+
+
+Performance, Internal Implementation, etc.
+
+ * "git fsck" has been taught to be pickier about entries in tree
+ objects that should not be there, e.g. ".", ".git", and "..".
+
+ * Matching paths with common forms of pathspecs that contain wildcard
+ characters has been optimized further.
+
+ * We stopped paying attention to $GIT_CONFIG environment that points
+ at a single configuration file from any command other than "git config"
+ quite a while ago, but "git clone" internally set, exported, and
+ then unexported the variable during its operation unnecessarily.
+
+ * "git reset" internals has been reworked and should be faster in
+ general. We tried to be careful not to break any behaviour but
+ there could be corner cases, especially when running the command
+ from a conflicted state, that we may have missed.
+
+ * The implementation of "imap-send" has been updated to reuse xml
+ quoting code from http-push codepath, and lost a lot of unused
+ code.
+
+ * There is a simple-minded checker for the test scripts in t/
+ directory to catch most common mistakes (it is not enabled by
+ default).
+
+ * You can build with USE_WILDMATCH=YesPlease to use a replacement
+ implementation of pattern matching logic used for pathname-like
+ things, e.g. refnames and paths in the repository. This new
+ implementation is not expected change the existing behaviour of Git
+ in this release, except for "git for-each-ref" where you can now
+ say "refs/**/master" and match with both refs/heads/master and
+ refs/remotes/origin/master. We plan to use this new implementation
+ in wider places (e.g. "git ls-files '**/Makefile' may find Makefile
+ at the top-level, and "git log '**/t*.sh'" may find commits that
+ touch a shell script whose name begins with "t" at any level) in
+ future versions of Git, but we are not there yet. By building with
+ USE_WILDMATCH, using the resulting Git daily and reporting when you
+ find breakages, you can help us get closer to that goal.
+
+ * Some reimplementations of Git do not write all the stat info back
+ to the index due to their implementation limitations (e.g. jgit).
+ A configuration option can tell Git to ignore changes to most of
+ the stat fields and only pay attention to mtime and size, which
+ these implementations can reliably update. This can be used to
+ avoid excessive revalidation of contents.
+
+ * Some platforms ship with old version of expat where xmlparse.h
+ needs to be included instead of expat.h; the build procedure has
+ been taught about this.
+
+ * "make clean" on platforms that cannot compute header dependencies
+ on the fly did not work with implementations of "rm" that do not
+ like an empty argument list.
+
+Also contains minor documentation updates and code clean-ups.
+
+
+Fixes since v1.8.1
+------------------
+
+Unless otherwise noted, all the fixes since v1.8.1 in the maintenance
+track are contained in this release (see release notes to them for
+details).
+
+ * An element on GIT_CEILING_DIRECTORIES list that does not name the
+ real path to a directory (i.e. a symbolic link) could have caused
+ the GIT_DIR discovery logic to escape the ceiling.
+
+ * When attempting to read the XDG-style $HOME/.config/git/config and
+ finding that $HOME/.config/git is a file, we gave a wrong error
+ message, instead of treating the case as "a custom config file does
+ not exist there" and moving on.
+
+ * The behaviour visible to the end users was confusing, when they
+ attempt to kill a process spawned in the editor that was in turn
+ launched by Git with SIGINT (or SIGQUIT), as Git would catch that
+ signal and die. We ignore these signals now.
+ (merge 0398fc34 pf/editor-ignore-sigint later to maint).
+
+ * A child process that was killed by a signal (e.g. SIGINT) was
+ reported in an inconsistent way depending on how the process was
+ spawned by us, with or without a shell in between.
+
+ * After failing to create a temporary file using mkstemp(), failing
+ pathname was not reported correctly on some platforms.
+
+ * We used to stuff "user@" and then append what we read from
+ /etc/mailname to come up with a default e-mail ident, but a bug
+ lost the "user@" part.
+
+ * The attribute mechanism didn't allow limiting attributes to be
+ applied to only a single directory itself with "path/" like the
+ exclude mechanism does. The initial implementation of this that
+ was merged to 'maint' and 1.8.1.2 was with a severe performance
+ degradations and needs to merge a fix-up topic.
+
+ * The smart HTTP clients forgot to verify the content-type that comes
+ back from the server side to make sure that the request is being
+ handled properly.
+
+ * "git am" did not parse datestamp correctly from Hg generated patch,
+ when it is run in a locale outside C (or en).
+
+ * "git apply" misbehaved when fixing whitespace breakages by removing
+ excess trailing blank lines.
+
+ * "git apply --summary" has been taught to make sure the similarity
+ value shown in its output is sensible, even when the input had a
+ bogus value.
+
+ * A tar archive created by "git archive" recorded a directory in a
+ way that made NetBSD's implementation of "tar" sometimes unhappy.
+
+ * "git archive" did not record uncompressed size in the header when
+ streaming a zip archive, which confused some implementations of unzip.
+
+ * "git archive" did not parse configuration values in tar.* namespace
+ correctly.
+ (merge b3873c3 jk/config-parsing-cleanup later to maint).
+
+ * Attempt to "branch --edit-description" an existing branch, while
+ being on a detached HEAD, errored out.
+
+ * "git clean" showed what it was going to do, but sometimes end up
+ finding that it was not allowed to do so, which resulted in a
+ confusing output (e.g. after saying that it will remove an
+ untracked directory, it found an embedded git repository there
+ which it is not allowed to remove). It now performs the actions
+ and then reports the outcome more faithfully.
+
+ * When "git clone --separate-git-dir=$over_there" is interrupted, it
+ failed to remove the real location of the $GIT_DIR it created.
+ This was most visible when interrupting a submodule update.
+
+ * "git cvsimport" mishandled timestamps at DST boundary.
+
+ * We used to have an arbitrary 32 limit for combined diff input,
+ resulting in incorrect number of leading colons shown when showing
+ the "--raw --cc" output.
+
+ * "git fetch --depth" was broken in at least three ways. The
+ resulting history was deeper than specified by one commit, it was
+ unclear how to wipe the shallowness of the repository with the
+ command, and documentation was misleading.
+ (merge cfb70e1 nd/fetch-depth-is-broken later to maint).
+
+ * "git log --all -p" that walked refs/notes/textconv/ ref can later
+ try to use the textconv data incorrectly after it gets freed.
+
+ * We forgot to close the file descriptor reading from "gpg" output,
+ killing "git log --show-signature" on a long history.
+
+ * The way "git svn" asked for password using SSH_ASKPASS and
+ GIT_ASKPASS was not in line with the rest of the system.
+
+ * The --graph code fell into infinite loop when asked to do what the
+ code did not expect.
+
+ * http transport was wrong to ask for the username when the
+ authentication is done by certificate identity.
+
+ * "git pack-refs" that ran in parallel to another process that
+ created new refs had a nasty race.
+
+ * Rebasing the history of superproject with change in the submodule
+ has been broken since v1.7.12.
+
+ * After "git add -N" and then writing a tree object out of the
+ index, the cache-tree data structure got corrupted.
+
+ * "git clone" used to allow --bare and --separate-git-dir=$there
+ options at the same time, which was nonsensical.
+
+ * "git rebase --preserve-merges" lost empty merges in recent versions
+ of Git.
+
+ * "git merge --no-edit" computed who were involved in the work done
+ on the side branch, even though that information is to be discarded
+ without getting seen in the editor.
+
+ * "git merge" started calling prepare-commit-msg hook like "git
+ commit" does some time ago, but forgot to pay attention to the exit
+ status of the hook.
+
+ * A failure to push due to non-ff while on an unborn branch
+ dereferenced a NULL pointer when showing an error message.
+
+ * When users spell "cc:" in lowercase in the fake "header" in the
+ trailer part, "git send-email" failed to pick up the addresses from
+ there. As e-mail headers field names are case insensitive, this
+ script should follow suit and treat "cc:" and "Cc:" the same way.
+
+ * Output from "git status --ignored" showed an unexpected interaction
+ with "--untracked".
+
+ * "gitweb", when sorting by age to show repositories with new
+ activities first, used to sort repositories with absolutely
+ nothing in it early, which was not very useful.
+
+ * "gitweb"'s code to sanitize control characters before passing it to
+ "highlight" filter lost known-to-be-safe control characters by
+ mistake.
+
+ * "gitweb" pages served over HTTPS, when configured to show picon or
+ gravatar, referred to these external resources to be fetched via
+ HTTP, resulting in mixed contents warning in browsers.
+
+ * When a line to be wrapped has a solid run of non space characters
+ whose length exactly is the wrap width, "git shortlog -w" failed
+ to add a newline after such a line.
+
+ * Command line completion leaked an unnecessary error message while
+ looking for possible matches with paths in <tree-ish>.
+
+ * Command line completion for "tcsh" emitted an unwanted space
+ after completing a single directory name.
+
+ * Command line completion code was inadvertently made incompatible with
+ older versions of bash by using a newer array notation.
+
+ * "git push" was taught to refuse updating the branch that is
+ currently checked out long time ago, but the user manual was left
+ stale.
+ (merge 50995ed wk/man-deny-current-branch-is-default-these-days later to maint).
+
+ * Some shells do not behave correctly when IFS is unset; work it
+ around by explicitly setting it to the default value.
+
+ * Some scripted programs written in Python did not get updated when
+ PYTHON_PATH changed.
+ (cherry-pick 96a4647fca54031974cd6ad1 later to maint).
+
+ * When autoconf is used, any build on a different commit always ran
+ "config.status --recheck" even when unnecessary.
+
+ * A fix was added to the build procedure to work around buggy
+ versions of ccache broke the auto-generation of dependencies, which
+ unfortunately is still relevant because some people use ancient
+ distros.
+
+ * The autoconf subsystem passed --mandir down to generated
+ config.mak.autogen but forgot to do the same for --htmldir.
+ (merge 55d9bf0 ct/autoconf-htmldir later to maint).
+
+ * A change made on v1.8.1.x maintenance track had a nasty regression
+ to break the build when autoconf is used.
+ (merge 7f1b697 jn/less-reconfigure later to maint).
+
+ * We have been carrying a translated and long-unmaintained copy of an
+ old version of the tutorial; removed.
+
+ * t0050 had tests expecting failures from a bug that was fixed some
+ time ago.
+
+ * t4014, t9502 and t0200 tests had various portability issues that
+ broke on OpenBSD.
+
+ * t9020 and t3600 tests had various portability issues.
+
+ * t9200 runs "cvs init" on a directory that already exists, but a
+ platform can configure this fail for the current user (e.g. you
+ need to be in the cvsadmin group on NetBSD 6.0).
+
+ * t9020 and t9810 had a few non-portable shell script construct.
+
+ * Scripts to test bash completion was inherently flaky as it was
+ affected by whatever random things the user may have on $PATH.
+
+ * An element on GIT_CEILING_DIRECTORIES could be a "logical" pathname
+ that uses a symbolic link to point at somewhere else (e.g. /home/me
+ that points at /net/host/export/home/me, and the latter directory
+ is automounted). Earlier when Git saw such a pathname e.g. /home/me
+ on this environment variable, the "ceiling" mechanism did not take
+ effect. With this release (the fix has also been merged to the
+ v1.8.1.x maintenance series), elements on GIT_CEILING_DIRECTORIES
+ are by default checked for such aliasing coming from symbolic
+ links. As this needs to actually resolve symbolic links for each
+ element on the GIT_CEILING_DIRECTORIES, you can disable this
+ mechanism for some elements by listing them after an empty element
+ on the GIT_CEILING_DIRECTORIES. e.g. Setting /home/me::/home/him to
+ GIT_CEILING_DIRECTORIES makes Git resolve symbolic links in
+ /home/me when checking if the current directory is under /home/me,
+ but does not do so for /home/him.
+ (merge 7ec30aa mh/maint-ceil-absolute later to maint).
diff --git a/RelNotes/1.8.3.1.adoc b/RelNotes/1.8.3.1.adoc
new file mode 100644
index 0000000..986637b
--- /dev/null
+++ b/RelNotes/1.8.3.1.adoc
@@ -0,0 +1,14 @@
+Git v1.8.3.1 Release Notes
+==========================
+
+Fixes since v1.8.3
+------------------
+
+ * When $HOME is misconfigured to point at an unreadable directory, we
+ used to complain and die. The check has been loosened.
+
+ * Handling of negative exclude pattern for directories "!dir" was
+ broken in the update to v1.8.3.
+
+Also contains a handful of trivial code clean-ups, documentation
+updates, updates to the test suite, etc.
diff --git a/RelNotes/1.8.3.2.adoc b/RelNotes/1.8.3.2.adoc
new file mode 100644
index 0000000..26ae142
--- /dev/null
+++ b/RelNotes/1.8.3.2.adoc
@@ -0,0 +1,59 @@
+Git v1.8.3.2 Release Notes
+==========================
+
+Fixes since v1.8.3.1
+--------------------
+
+ * Cloning with "git clone --depth N" while fetch.fsckobjects (or
+ transfer.fsckobjects) is set to true did not tell the cut-off
+ points of the shallow history to the process that validates the
+ objects and the history received, causing the validation to fail.
+
+ * "git checkout foo" DWIMs the intended "upstream" and turns it into
+ "git checkout -t -b foo remotes/origin/foo". This codepath has been
+ updated to correctly take existing remote definitions into account.
+
+ * "git fetch" into a shallow repository from a repository that does
+ not know about the shallow boundary commits (e.g. a different fork
+ from the repository the current shallow repository was cloned from)
+ did not work correctly.
+
+ * "git subtree" (in contrib/) had one codepath with loose error
+ checks to lose data at the remote side.
+
+ * "git log --ancestry-path A...B" did not work as expected, as it did
+ not pay attention to the fact that the merge base between A and B
+ was the bottom of the range being specified.
+
+ * "git diff -c -p" was not showing a deleted line from a hunk when
+ another hunk immediately begins where the earlier one ends.
+
+ * "git merge @{-1}~22" was rewritten to "git merge frotz@{1}~22"
+ incorrectly when your previous branch was "frotz" (it should be
+ rewritten to "git merge frotz~22" instead).
+
+ * "git commit --allow-empty-message -m ''" should not start an
+ editor.
+
+ * "git push --[no-]verify" was not documented.
+
+ * An entry for "file://" scheme in the enumeration of URL types Git
+ can take in the HTML documentation was made into a clickable link
+ by mistake.
+
+ * zsh prompt script that borrowed from bash prompt script did not
+ work due to slight differences in array variable notation between
+ these two shells.
+
+ * The bash prompt code (in contrib/) displayed the name of the branch
+ being rebased when "rebase -i/-m/-p" modes are in use, but not the
+ plain vanilla "rebase".
+
+ * "git push $there HEAD:branch" did not resolve HEAD early enough, so
+ it was easy to flip it around while push is still going on and push
+ out a branch that the user did not originally intended when the
+ command was started.
+
+ * "difftool --dir-diff" did not copy back changes made by the
+ end-user in the diff tool backend to the working tree in some
+ cases.
diff --git a/RelNotes/1.8.3.3.adoc b/RelNotes/1.8.3.3.adoc
new file mode 100644
index 0000000..9ba4f4d
--- /dev/null
+++ b/RelNotes/1.8.3.3.adoc
@@ -0,0 +1,47 @@
+Git v1.8.3.3 Release Notes
+==========================
+
+Fixes since v1.8.3.2
+--------------------
+
+ * "git apply" parsed patches that add new files, generated by programs
+ other than Git, incorrectly. This is an old breakage in v1.7.11.
+
+ * Older cURL wanted piece of memory we call it with to be stable, but
+ we updated the auth material after handing it to a call.
+
+ * "git pull" into nothing trashed "local changes" that were in the
+ index.
+
+ * Many "git submodule" operations did not work on a submodule at a
+ path whose name is not in ASCII.
+
+ * "cherry-pick" had a small leak in its error codepath.
+
+ * Logic used by git-send-email to suppress cc mishandled names like
+ "A U. Thor" <author@example.xz>, where the human readable part
+ needs to be quoted (the user input may not have the double quotes
+ around the name, and comparison was done between quoted and
+ unquoted strings). It also mishandled names that need RFC2047
+ quoting.
+
+ * "gitweb" forgot to clear a global variable $search_regexp upon each
+ request, mistakenly carrying over the previous search to a new one
+ when used as a persistent CGI.
+
+ * The wildmatch engine did not honor WM_CASEFOLD option correctly.
+
+ * "git log -c --follow $path" segfaulted upon hitting the commit that
+ renamed the $path being followed.
+
+ * When a reflog notation is used for implicit "current branch",
+ e.g. "git log @{u}", we did not say which branch and worse said
+ "branch ''" in the error messages.
+
+ * Mac OS X does not like to write(2) more than INT_MAX number of
+ bytes; work it around by chopping write(2) into smaller pieces.
+
+ * Newer MacOS X encourages the programs to compile and link with
+ their CommonCrypto, not with OpenSSL.
+
+Also contains various minor documentation updates.
diff --git a/RelNotes/1.8.3.4.adoc b/RelNotes/1.8.3.4.adoc
new file mode 100644
index 0000000..56f106e
--- /dev/null
+++ b/RelNotes/1.8.3.4.adoc
@@ -0,0 +1,20 @@
+Git v1.8.3.4 Release Notes
+==========================
+
+This update is mostly to propagate documentation fixes and test
+updates from the master front back to the maintenance track.
+
+Fixes since v1.8.3.3
+--------------------
+
+ * The bisect log listed incorrect commits when bisection ends with
+ only skipped ones.
+
+ * The test coverage framework was left broken for some time.
+
+ * The test suite for HTTP transport did not run with Apache 2.4.
+
+ * "git diff" used to fail when core.safecrlf is set and the working
+ tree contents had mixed CRLF/LF line endings. Committing such a
+ content must be prohibited, but "git diff" should help the user to
+ locate and fix such problems without failing.
diff --git a/RelNotes/1.8.3.adoc b/RelNotes/1.8.3.adoc
new file mode 100644
index 0000000..ead568e
--- /dev/null
+++ b/RelNotes/1.8.3.adoc
@@ -0,0 +1,436 @@
+Git v1.8.3 Release Notes
+========================
+
+Backward compatibility notes (for Git 2.0)
+------------------------------------------
+
+When "git push [$there]" does not say what to push, we have used the
+traditional "matching" semantics so far (all your branches were sent
+to the remote as long as there already are branches of the same name
+over there). In Git 2.0, the default will change to the "simple"
+semantics that pushes only the current branch to the branch with the same
+name, and only when the current branch is set to integrate with that
+remote branch. Use the user preference configuration variable
+"push.default" to change this. If you are an old-timer who is used
+to the "matching" semantics, you can set the variable to "matching"
+to keep the traditional behaviour. If you want to live in the future
+early, you can set it to "simple" today without waiting for Git 2.0.
+
+When "git add -u" (and "git add -A") is run inside a subdirectory and
+does not specify which paths to add on the command line, it
+will operate on the entire tree in Git 2.0 for consistency
+with "git commit -a" and other commands. There will be no
+mechanism to make plain "git add -u" behave like "git add -u .".
+Current users of "git add -u" (without a pathspec) should start
+training their fingers to explicitly say "git add -u ."
+before Git 2.0 comes. A warning is issued when these commands are
+run without a pathspec and when you have local changes outside the
+current directory, because the behaviour in Git 2.0 will be different
+from today's version in such a situation.
+
+In Git 2.0, "git add <path>" will behave as "git add -A <path>", so
+that "git add dir/" will notice paths you removed from the directory
+and record the removal. Versions before Git 2.0, including this
+release, will keep ignoring removals, but the users who rely on this
+behaviour are encouraged to start using "git add --ignore-removal <path>"
+now before 2.0 is released.
+
+
+Updates since v1.8.2
+--------------------
+
+Foreign interface
+
+ * remote-hg and remote-bzr helpers (in contrib/ since v1.8.2) have
+ been updated; especially, the latter has been done in an
+ accelerated schedule (read: we may not have merged to this release
+ if we were following the usual "cook sufficiently in next before
+ unleashing it to the world" workflow) in order to help Emacs folks,
+ whose primary SCM seems to be stagnating.
+
+
+UI, Workflows & Features
+
+ * A handful of updates applied to gitk, including an addition of
+ "revert" action, showing dates in tags in a nicer way, making
+ colors configurable, and support for -G'pickaxe' search.
+
+ * The prompt string generator (in contrib/completion/) learned to
+ show how many changes there are in total and how many have been
+ replayed during a "git rebase" session.
+
+ * "git branch --vv" learned to paint the name of the branch it
+ integrates with in a different color (color.branch.upstream,
+ which defaults to blue).
+
+ * In a sparsely populated working tree, "git checkout <pathspec>" no
+ longer unmarks paths that match the given pathspec that were
+ originally ignored with "--sparse" (use --ignore-skip-worktree-bits
+ option to resurrect these paths out of the index if you really want
+ to).
+
+ * "git log --format" specifier learned %C(auto) token that tells Git
+ to use color when interpolating %d (decoration), %h (short commit
+ object name), etc. for terminal output.
+
+ * "git bisect" leaves the final outcome as a comment in its bisect
+ log file.
+
+ * "git clone --reference" can now refer to a gitfile "textual symlink"
+ that points at the real location of the repository.
+
+ * "git count-objects" learned "--human-readable" aka "-H" option to
+ show various large numbers in Ki/Mi/GiB scaled as necessary.
+
+ * "git cherry-pick $blob" and "git cherry-pick $tree" are nonsense,
+ and a more readable error message e.g. "can't cherry-pick a tree"
+ is given (we used to say "expected exactly one commit").
+
+ * The "--annotate" option to "git send-email" can be turned on (or
+ off) by default with sendemail.annotate configuration variable (you
+ can use --no-annotate from the command line to override it).
+
+ * The "--cover-letter" option to "git format-patch" can be turned on
+ (or off) by default with format.coverLetter configuration
+ variable. By setting it to 'auto', you can turn it on only for a
+ series with two or more patches.
+
+ * The bash completion support (in contrib/) learned that cherry-pick
+ takes a few more options than it already knew about.
+
+ * "git help" learned "-g" option to show the list of guides just like
+ list of commands are given with "-a".
+
+ * A triangular "pull from one place, push to another place" workflow
+ is supported better by new remote.pushdefault (overrides the
+ "origin" thing) and branch.*.pushremote (overrides the
+ branch.*.remote) configuration variables.
+
+ * "git status" learned to report that you are in the middle of a
+ revert session, just like it does for a cherry-pick and a bisect
+ session.
+
+ * The handling by "git branch --set-upstream-to" against various forms
+ of erroneous inputs was suboptimal and has been improved.
+
+ * When the interactive access to git-shell is not enabled, it issues
+ a message meant to help the system administrator to enable it. An
+ explicit way has been added to issue custom messages to refuse an
+ access over the network to help the end users who connect to the
+ service expecting an interactive shell.
+
+ * In addition to the case where the user edits the log message with
+ the "e)dit" option of "am -i", replace the "Applying: this patch"
+ message with the final log message contents after applymsg hook
+ munges it.
+
+ * "git status" suggests users to look into using --untracked=no option
+ when it takes too long.
+
+ * "git status" shows a bit more information during a rebase/bisect
+ session.
+
+ * "git fetch" learned to fetch a commit at the tip of an unadvertised
+ ref by specifying a raw object name from the command line when the
+ server side supports this feature.
+
+ * Output from "git log --graph" works better with submodule log
+ output now.
+
+ * "git count-objects -v" learned to report leftover temporary
+ packfiles and other garbage in the object store.
+
+ * A new read-only credential helper (in contrib/) to interact with
+ the .netrc/.authinfo files has been added.
+
+ * "git send-email" can be used with the credential helper system.
+
+ * There was no Porcelain way to say "I no longer am interested in
+ this submodule", once you express your interest in a submodule with
+ "submodule init". "submodule deinit" is the way to do so.
+
+ * "git pull --rebase" learned to pass "-v/-q" options to underlying
+ "git rebase".
+
+ * The new "--follow-tags" option tells "git push" to push relevant
+ annotated tags when pushing branches out.
+
+ * "git merge" and "git pull" can optionally be told to inspect and
+ reject when merging a commit that does not carry a trusted GPG
+ signature.
+
+ * "git mergetool" now feeds files to the "p4merge" backend in the
+ order that matches the p4 convention, where "theirs" is usually
+ shown on the left side, which is the opposite from what other backends
+ expect.
+
+ * "show/log" now honors gpg.program configuration just like other
+ parts of the code that use GnuPG.
+
+ * "git log" that shows the difference between the parent and the
+ child has been optimized somewhat.
+
+ * "git difftool" allows the user to write into the temporary files
+ being shown; if the user makes changes to the working tree at the
+ same time, it now refrains from overwriting the copy in the working
+ tree and leaves the temporary file so that changes can be merged
+ manually.
+
+ * There was no good way to ask "I have a random string that came from
+ outside world. I want to turn it into a 40-hex object name while
+ making sure such an object exists". A new peeling suffix ^{object}
+ can be used for that purpose, together with "rev-parse --verify".
+
+
+Performance, Internal Implementation, etc.
+
+ * Updates for building under msvc.
+
+ * A handful of issues in the code that traverses the working tree to find
+ untracked and/or ignored files have been fixed, and the general
+ codepath involved in "status -u" and "clean" have been cleaned up
+ and optimized.
+
+ * The stack footprint of some codepaths that access an object from a
+ pack has been shrunk.
+
+ * The logic to coalesce the same lines removed from the parents in
+ the output from "diff -c/--cc" has been updated, but with O(n^2)
+ complexity, so this might turn out to be undesirable.
+
+ * The code to enforce permission bits on files in $GIT_DIR/ for
+ shared repositories has been simplified.
+
+ * A few codepaths know how much data they need to put in the
+ hashtables they use when they start, but still began with small tables
+ and repeatedly grew and rehashed them.
+
+ * The API to walk reflog entries from the latest to older, which was
+ necessary for operations such as "git checkout -", was cumbersome
+ to use correctly and also inefficient.
+
+ * Codepaths that inspect log-message-to-be and decide when to add a
+ new Signed-off-by line in various commands have been consolidated.
+
+ * The pkt-line API, implementation and its callers have been cleaned
+ up to make them more robust.
+
+ * The Cygwin port has a faster-but-lying lstat(2) emulation whose
+ incorrectness does not matter in practice except for a few
+ codepaths, and setting permission bits on directories is a codepath
+ that needs to use a more correct one.
+
+ * "git checkout" had repeated pathspec matches on the same paths,
+ which have been consolidated. Also a bug in "git checkout dir/"
+ that is started from an unmerged index has been fixed.
+
+ * A few bugfixes to "git rerere" working on corner case merge
+ conflicts have been applied.
+
+
+Also contains various documentation updates and code clean-ups.
+
+
+Fixes since v1.8.2
+------------------
+
+Unless otherwise noted, all the fixes since v1.8.2 in the maintenance
+track are contained in this release (see release notes to them for
+details).
+
+ * Recent versions of File::Temp (used by "git svn") started blowing
+ up when its tempfile sub is called as a class method; updated the
+ callsite to call it as a plain vanilla function to fix it.
+ (merge eafc2dd hb/git-pm-tempfile later to maint).
+
+ * Various subcommands of "git remote" simply ignored extraneous
+ command line arguments instead of diagnosing them as errors.
+
+ * When receive-pack detects an error in the pack header it received in
+ order to decide which of unpack-objects or index-pack to run, it
+ returned without closing the error stream, which led to a hung
+ sideband thread.
+
+ * Zsh completion forgot that the '%' character used to signal untracked
+ files needs to be escaped with another '%'.
+
+ * A commit object whose author or committer ident are malformed
+ crashed some code that trusted that a name, an email and a
+ timestamp can always be found in it.
+
+ * When "upload-pack" fails while generating a pack in response to
+ "git fetch" (or "git clone"), the receiving side had
+ a programming error that triggered the die handler
+ recursively.
+
+ * "rev-list --stdin" and friends kept bogus pointers into the input
+ buffer around as human readable object names. This was not a huge
+ problem but was exposed by a new change that uses these names in
+ error output.
+
+ * Smart-capable HTTP servers were not restricted via the
+ GIT_NAMESPACE mechanism when talking with commit-walking clients,
+ like they are when talking with smart HTTP clients.
+ (merge 6130f86 jk/http-dumb-namespaces later to maint).
+
+ * "git merge-tree" did not omit a merge result that is identical to
+ the "our" side in certain cases.
+ (merge aacecc3 jk/merge-tree-added-identically later to maint).
+
+ * Perl scripts like "git-svn" closed (instead of redirecting to /dev/null)
+ the standard error stream, which is not a very smart thing to do.
+ A later open may return file descriptor #2 for an unrelated purpose, and
+ error reporting code may write into it.
+
+ * "git show-branch" was not prepared to show a very long run of
+ ancestor operators e.g. foobar^2~2^2^2^2...^2~4 correctly.
+
+ * "git diff --diff-algorithm algo" is also understood as "git diff
+ --diff-algorithm=algo".
+
+ * The new core.commentchar configuration was not applied in a few
+ places.
+
+ * "git bundle" erroneously bailed out when parsing a valid bundle
+ containing a prerequisite commit without a commit message.
+
+ * "git log -S/-G" started paying attention to textconv filter, but
+ there was no way to disable this. Make it honor the --no-textconv
+ option.
+
+ * When used with the "-d temporary-directory" option, "git filter-branch"
+ failed to come back to the original working tree to perform the
+ final clean-up procedure.
+
+ * "git merge $(git rev-parse v1.8.2)" behaved quite differently from
+ "git merge v1.8.2", as if v1.8.2 were written as v1.8.2^0 and did
+ not pay much attention to the annotated tag payload. Make the code
+ notice the type of the tag object, in addition to the dwim_ref()
+ based classification the current code uses (i.e. the name appears
+ in refs/tags/) to decide when to special-case tag merging.
+
+ * Fix a 1.8.1.x regression that stopped matching "dir" (without a
+ trailing slash) to a directory "dir".
+
+ * "git apply --whitespace=fix" was not prepared to see a line getting
+ longer after fixing whitespaces (e.g. tab-in-indent aka Python).
+
+ * The prompt string generator (in contrib/completion/) did not notice
+ when we are in a middle of a "git revert" session.
+
+ * "submodule summary --summary-limit" option did not support the
+ "--option=value" form.
+
+ * "index-pack --fix-thin" used an uninitialized value to compute
+ the delta depths of objects it appends to the resulting pack.
+
+ * "index-pack --verify-stat" used a few counters outside the protection
+ of a mutex, possibly showing incorrect numbers.
+
+ * The code to keep track of what directory names are known to Git on
+ platforms with case insensitive filesystems could get confused upon a
+ hash collision between these pathnames and would loop forever.
+
+ * Annotated tags outside the refs/tags/ hierarchy were not advertised
+ correctly to ls-remote and fetch with recent versions of Git.
+
+ * Recent optimizations broke shallow clones.
+
+ * "git cmd -- ':(top'" was not diagnosed as an invalid syntax, and
+ instead the parser kept reading beyond the end of the string.
+
+ * "git tag -f <tag>" always said "Updated tag '<tag>'" even when
+ creating a new tag (i.e. neither overwriting nor updating).
+
+ * "git p4" did not behave well when the path to the root of the P4
+ client was not its real path.
+ (merge bbd8486 pw/p4-symlinked-root later to maint).
+
+ * "git archive" reported a failure when asked to create an archive out
+ of an empty tree. It is more intuitive to give an empty
+ archive back in such a case.
+
+ * When "format-patch" quoted a non-ascii string in header files,
+ it incorrectly applied rfc2047 and chopped a single character in
+ the middle of the string.
+
+ * An aliased command spawned from a bare repository that does not say
+ it is bare with "core.bare = yes" was treated as non-bare by mistake.
+
+ * In "git reflog expire", the REACHABLE bit was not cleared from the
+ correct objects.
+
+ * The logic used by "git diff -M --stat" to shorten the names of
+ files before and after a rename did not work correctly when the
+ common prefix and suffix between the two filenames overlapped.
+
+ * The "--match=<pattern>" option of "git describe", when used with
+ "--all" to allow refs that are not annotated tags to be a
+ base of description, did not restrict the output from the command
+ to those refs that match the given pattern.
+
+ * Clarify in the documentation "what" gets pushed to "where" when the
+ command line to "git push" does not say these explicitly.
+
+ * The "--color=<when>" argument to the commands in the diff family
+ was described poorly.
+
+ * The arguments given to the pre-rebase hook were not documented.
+
+ * The v4 index format was not documented.
+
+ * The "--match=<pattern>" argument "git describe" takes uses glob
+ pattern but it wasn't obvious from the documentation.
+
+ * Some sources failed to compile on systems that lack NI_MAXHOST in
+ their system header (e.g. z/OS).
+
+ * Add an example use of "--env-filter" in "filter-branch"
+ documentation.
+
+ * "git bundle verify" did not say "records a complete history" for a
+ bundle that does not have any prerequisites.
+
+ * In the v1.8.0 era, we changed symbols that do not have to be global
+ to file scope static, but a few functions in graph.c were used by
+ CGit sideways, bypassing the entry points of the API the
+ in-tree users use.
+
+ * "git update-index -h" did not do the usual "-h(elp)" thing.
+
+ * "git index-pack" had a buffer-overflow while preparing an
+ informational message when the translated version of it was too
+ long.
+
+ * 'git commit -m "$msg"' used to add an extra newline even when
+ $msg already ended with one.
+
+ * The SSL peer verification done by "git imap-send" did not ask for
+ Server Name Indication (RFC 4366), failing to connect to SSL/TLS
+ sites that serve multiple hostnames on a single IP.
+
+ * perl/Git.pm::cat_blob slurped everything in core only to write it
+ out to a file descriptor, which was not a very smart thing to do.
+
+ * "git branch" did not bother to check nonsense command line
+ parameters. It now issues errors in many cases.
+
+ * Verification of signed tags was not done correctly when not in C
+ or en/US locale.
+
+ * Some platforms and users spell UTF-8 differently; retry with the
+ most official "UTF-8" when the system does not understand the
+ user-supplied encoding name that is a common alternative
+ spelling of UTF-8.
+
+ * When export-subst is used, "zip" output recorded an incorrect
+ size of the file.
+
+ * "git am $maildir/" applied messages in an unexpected order; sort
+ filenames read from the maildir/ in a way that is more likely to
+ sort the messages in the order the writing MUA meant to, by sorting
+ numeric segments in numeric order and non-numeric segments in
+ alphabetical order.
+
+ * "git submodule update", when recursed into sub-submodules, did not
+ accumulate the prefix paths.
diff --git a/RelNotes/1.8.4.1.adoc b/RelNotes/1.8.4.1.adoc
new file mode 100644
index 0000000..c257beb
--- /dev/null
+++ b/RelNotes/1.8.4.1.adoc
@@ -0,0 +1,71 @@
+Git v1.8.4.1 Release Notes
+==========================
+
+Fixes since v1.8.4
+------------------
+
+ * Some old versions of bash do not grok some constructs like
+ 'printf -v varname' which the prompt and completion code started
+ to use recently. The completion and prompt scripts have been
+ adjusted to work better with these old versions of bash.
+
+ * In FreeBSD's and NetBSD's "sh", a return in a dot script in a
+ function returns from the function, not only in the dot script,
+ breaking "git rebase" on these platforms (regression introduced
+ in 1.8.4-rc1).
+
+ * "git rebase -i" and other scripted commands were feeding a
+ random, data dependent error message to 'echo' and expecting it
+ to come out literally.
+
+ * Setting the "submodule.<name>.path" variable to the empty
+ "true" caused the configuration parser to segfault.
+
+ * Output from "git log --full-diff -- <pathspec>" looked strange
+ because comparison was done with the previous ancestor that
+ touched the specified <pathspec>, causing the patches for paths
+ outside the pathspec to show more than the single commit has
+ changed.
+
+ * The auto-tag-following code in "git fetch" tries to reuse the
+ same transport twice when the serving end does not cooperate and
+ does not give tags that point to commits that are asked for as
+ part of the primary transfer. Unfortunately, Git-aware transport
+ helper interface is not designed to be used more than once, hence
+ this did not work over smart-http transfer. Fixed.
+
+ * Send a large request to read(2)/write(2) as a smaller but still
+ reasonably large chunks, which would improve the latency when the
+ operation needs to be killed and incidentally works around broken
+ 64-bit systems that cannot take a 2GB write or read in one go.
+
+ * A ".mailmap" file that ends with an incomplete line, when read
+ from a blob, was not handled properly.
+
+ * The recent "short-cut clone connectivity check" topic broke a
+ shallow repository when a fetch operation tries to auto-follow
+ tags.
+
+ * When send-email comes up with an error message to die with upon
+ failure to start an SSL session, it tried to read the error
+ string from a wrong place.
+
+ * A call to xread() was used without a loop to cope with short
+ read in the codepath to stream large blobs to a pack.
+
+ * On platforms with fgetc() and friends defined as macros, the
+ configuration parser did not compile.
+
+ * New versions of MediaWiki introduced a new API for returning
+ more than 500 results in response to a query, which would cause
+ the MediaWiki remote helper to go into an infinite loop.
+
+ * Subversion's serf access method (the only one available in
+ Subversion 1.8) for http and https URLs in skelta mode tells its
+ caller to open multiple files at a time, which made "git svn
+ fetch" complain that "Temp file with moniker 'svn_delta' already
+ in use" instead of fetching.
+
+
+Also contains a handful of trivial code clean-ups, documentation
+updates, updates to the test suite, etc.
diff --git a/RelNotes/1.8.4.2.adoc b/RelNotes/1.8.4.2.adoc
new file mode 100644
index 0000000..bf6fb1a0
--- /dev/null
+++ b/RelNotes/1.8.4.2.adoc
@@ -0,0 +1,77 @@
+Git v1.8.4.2 Release Notes
+==========================
+
+Fixes since v1.8.4.1
+--------------------
+
+ * "git clone" gave some progress messages to the standard output, not
+ to the standard error, and did not allow suppressing them with the
+ "--no-progress" option.
+
+ * "format-patch --from=<whom>" forgot to omit unnecessary in-body
+ from line, i.e. when <whom> is the same as the real author.
+
+ * "git shortlog" used to choke and die when there is a malformed
+ commit (e.g. missing authors); it now simply ignore such a commit
+ and keeps going.
+
+ * "git merge-recursive" did not parse its "--diff-algorithm=" command
+ line option correctly.
+
+ * "git branch --track" had a minor regression in v1.8.3.2 and later
+ that made it impossible to base your local work on anything but a
+ local branch of the upstream repository you are tracking from.
+
+ * "git ls-files -k" needs to crawl only the part of the working tree
+ that may overlap the paths in the index to find killed files, but
+ shared code with the logic to find all the untracked files, which
+ made it unnecessarily inefficient.
+
+ * When there is no sufficient overlap between old and new history
+ during a "git fetch" into a shallow repository, objects that the
+ sending side knows the receiving end has were unnecessarily sent.
+
+ * When running "fetch -q", a long silence while the sender side
+ computes the set of objects to send can be mistaken by proxies as
+ dropped connection. The server side has been taught to send a
+ small empty messages to keep the connection alive.
+
+ * When the webserver responds with "405 Method Not Allowed", "git
+ http-backend" should tell the client what methods are allowed with
+ the "Allow" header.
+
+ * "git cvsserver" computed the permission mode bits incorrectly for
+ executable files.
+
+ * The implementation of "add -i" has a crippling code to work around
+ ActiveState Perl limitation but it by mistake also triggered on Git
+ for Windows where MSYS perl is used.
+
+ * We made sure that we notice the user-supplied GIT_DIR is actually a
+ gitfile, but did not do the same when the default ".git" is a
+ gitfile.
+
+ * When an object is not found after checking the packfiles and then
+ loose object directory, read_sha1_file() re-checks the packfiles to
+ prevent racing with a concurrent repacker; teach the same logic to
+ has_sha1_file().
+
+ * "git commit --author=$name", when $name is not in the canonical
+ "A. U. Thor <au.thor@example.xz>" format, looks for a matching name
+ from existing history, but did not consult mailmap to grab the
+ preferred author name.
+
+ * The commit object names in the insn sheet that was prepared at the
+ beginning of "rebase -i" session can become ambiguous as the
+ rebasing progresses and the repository gains more commits. Make
+ sure the internal record is kept with full 40-hex object names.
+
+ * "git rebase --preserve-merges" internally used the merge machinery
+ and as a side effect, left merge summary message in the log, but
+ when rebasing, there should not be a need for merge summary.
+
+ * "git rebase -i" forgot that the comment character can be
+ configurable while reading its insn sheet.
+
+Also contains a handful of trivial code clean-ups, documentation
+updates, updates to the test suite, etc.
diff --git a/RelNotes/1.8.4.3.adoc b/RelNotes/1.8.4.3.adoc
new file mode 100644
index 0000000..267a1b3
--- /dev/null
+++ b/RelNotes/1.8.4.3.adoc
@@ -0,0 +1,54 @@
+Git v1.8.4.3 Release Notes
+==========================
+
+Fixes since v1.8.4.2
+--------------------
+
+ * The interaction between use of Perl in our test suite and NO_PERL
+ has been clarified a bit.
+
+ * A fast-import stream expresses a pathname with funny characters by
+ quoting them in C style; remote-hg remote helper (in contrib/)
+ forgot to unquote such a path.
+
+ * One long-standing flaw in the pack transfer protocol used by "git
+ clone" was that there was no way to tell the other end which branch
+ "HEAD" points at, and the receiving end needed to guess. A new
+ capability has been defined in the pack protocol to convey this
+ information so that cloning from a repository with more than one
+ branches pointing at the same commit where the HEAD is at now
+ reliably sets the initial branch in the resulting repository.
+
+ * We did not handle cases where http transport gets redirected during
+ the authorization request (e.g. from http:// to https://).
+
+ * "git rev-list --objects ^v1.0^ v1.0" gave v1.0 tag itself in the
+ output, but "git rev-list --objects v1.0^..v1.0" did not.
+
+ * The fall-back parsing of commit objects with broken author or
+ committer lines were less robust than ideal in picking up the
+ timestamps.
+
+ * Bash prompting code to deal with an SVN remote as an upstream
+ were coded in a way not supported by older Bash versions (3.x).
+
+ * "git checkout topic", when there is not yet a local "topic" branch
+ but there is a unique remote-tracking branch for a remote "topic"
+ branch, pretended as if "git checkout -t -b topic remote/$r/topic"
+ (for that unique remote $r) was run. This hack however was not
+ implemented for "git checkout topic --".
+
+ * Coloring around octopus merges in "log --graph" output was screwy.
+
+ * We did not generate HTML version of documentation to "git subtree"
+ in contrib/.
+
+ * The synopsis section of "git unpack-objects" documentation has been
+ clarified a bit.
+
+ * An ancient How-To on serving Git repositories on an HTTP server
+ lacked a warning that it has been mostly superseded with more
+ modern way.
+
+Also contains a handful of trivial code clean-ups, documentation
+updates, updates to the test suite, etc.
diff --git a/RelNotes/1.8.4.4.adoc b/RelNotes/1.8.4.4.adoc
new file mode 100644
index 0000000..a7c1ce1
--- /dev/null
+++ b/RelNotes/1.8.4.4.adoc
@@ -0,0 +1,10 @@
+Git v1.8.4.4 Release Notes
+==========================
+
+Fixes since v1.8.4.3
+--------------------
+
+ * The fix in v1.8.4.3 to the pack transfer protocol to propagate
+ the target of symbolic refs broke "git clone/git fetch" from a
+ repository with too many symbolic refs. As a hotfix/workaround,
+ we transfer only the information on HEAD.
diff --git a/RelNotes/1.8.4.5.adoc b/RelNotes/1.8.4.5.adoc
new file mode 100644
index 0000000..215bd1a
--- /dev/null
+++ b/RelNotes/1.8.4.5.adoc
@@ -0,0 +1,13 @@
+Git v1.8.4.5 Release Notes
+==========================
+
+Fixes since v1.8.4.4
+--------------------
+
+ * Recent update to remote-hg that attempted to make it work better
+ with non ASCII pathnames fed Unicode strings to the underlying Hg
+ API, which was wrong.
+
+ * "git submodule init" copied "submodule.$name.update" settings from
+ .gitmodules to .git/config without making sure if the suggested
+ value was sensible.
diff --git a/RelNotes/1.8.4.adoc b/RelNotes/1.8.4.adoc
new file mode 100644
index 0000000..2e75299
--- /dev/null
+++ b/RelNotes/1.8.4.adoc
@@ -0,0 +1,486 @@
+Git v1.8.4 Release Notes
+========================
+
+Backward compatibility notes (for Git 2.0)
+------------------------------------------
+
+When "git push [$there]" does not say what to push, we have used the
+traditional "matching" semantics so far (all your branches were sent
+to the remote as long as there already are branches of the same name
+over there). In Git 2.0, the default will change to the "simple"
+semantics that pushes:
+
+ - only the current branch to the branch with the same name, and only
+ when the current branch is set to integrate with that remote
+ branch, if you are pushing to the same remote as you fetch from; or
+
+ - only the current branch to the branch with the same name, if you
+ are pushing to a remote that is not where you usually fetch from.
+
+Use the user preference configuration variable "push.default" to
+change this. If you are an old-timer who is used to the "matching"
+semantics, you can set the variable to "matching" to keep the
+traditional behaviour. If you want to live in the future early, you
+can set it to "simple" today without waiting for Git 2.0.
+
+When "git add -u" (and "git add -A") is run inside a subdirectory and
+does not specify which paths to add on the command line, it
+will operate on the entire tree in Git 2.0 for consistency
+with "git commit -a" and other commands. There will be no
+mechanism to make plain "git add -u" behave like "git add -u .".
+Current users of "git add -u" (without a pathspec) should start
+training their fingers to explicitly say "git add -u ."
+before Git 2.0 comes. A warning is issued when these commands are
+run without a pathspec and when you have local changes outside the
+current directory, because the behaviour in Git 2.0 will be different
+from today's version in such a situation.
+
+In Git 2.0, "git add <path>" will behave as "git add -A <path>", so
+that "git add dir/" will notice paths you removed from the directory
+and record the removal. Versions before Git 2.0, including this
+release, will keep ignoring removals, but the users who rely on this
+behaviour are encouraged to start using "git add --ignore-removal <path>"
+now before 2.0 is released.
+
+
+Updates since v1.8.3
+--------------------
+
+Foreign interfaces, subsystems and ports.
+
+ * Cygwin port has been updated for more recent Cygwin 1.7.
+
+ * "git rebase -i" now honors --strategy and -X options.
+
+ * Git-gui has been updated to its 0.18.0 version.
+
+ * MediaWiki remote helper (in contrib/) has been updated to use the
+ credential helper interface from Git.pm.
+
+ * Update build for Cygwin 1.[57]. Torsten Bögershausen reports that
+ this is fine with Cygwin 1.7 (cf. <51A606A0.5060101@web.de>) so let's try moving it
+ ahead.
+
+ * The credential helper to talk to keychain on OS X (in contrib/) has
+ been updated to kick in not just when talking http/https but also
+ imap(s) and smtp.
+
+ * Remote transport helper has been updated to report errors and
+ maintain ref hierarchy used to keep track of its own state better.
+
+ * With "export" remote-helper protocol, (1) a push that tries to
+ update a remote ref whose name is different from the pushing side
+ does not work yet, and (2) the helper may not know how to do
+ --dry-run; these problematic cases are disabled for now.
+
+ * git-remote-hg/bzr (in contrib/) updates.
+
+ * git-remote-mw (in contrib/) hints users to check the certificate,
+ when https:// connection failed.
+
+ * git-remote-mw (in contrib/) adds a command to allow previewing the
+ contents locally before pushing it out, when working with a
+ MediaWiki remote.
+
+
+UI, Workflows & Features
+
+ * Sample "post-receive-email" hook script got an enhanced replacement
+ "multimail" (in contrib/).
+
+ * Also in contrib/ is a new "contacts" script that runs "git blame"
+ to find out the people who may be interested in a set of changes.
+
+ * "git clean" command learned an interactive mode.
+
+ * The "--head" option to "git show-ref" was only to add "HEAD" to the
+ list of candidate refs to be filtered by the usual rules
+ (e.g. "--heads" that only show refs under refs/heads). The meaning
+ of the option has been changed to always show "HEAD" regardless of
+ what filtering will be applied to any other ref.
+
+ This is a backward incompatible change and might cause breakages to
+ people's existing scripts.
+
+ * "git show -s" was less discoverable than it should have been. It
+ now has a natural synonym "git show --no-patch".
+
+ * "git check-mailmap" is a new command that lets you map usernames
+ and e-mail addresses through the mailmap mechanism, just like many
+ built-in commands do.
+
+ * "git name-rev" learned to name an annotated tag object back to its
+ tagname; "git name-rev $(git rev-parse v1.0.0)" gives "tags/v1.0.0",
+ for example.
+
+ * "git cat-file --batch-check=<format>" is added, primarily to allow
+ on-disk footprint of objects in packfiles (often they are a lot
+ smaller than their true size, when expressed as deltas) to be
+ reported.
+
+ * "git rebase [-i]" used to leave just "rebase" as its reflog messages
+ for some operations. They have been reworded to be more informative.
+
+ * In addition to the choice from "rebase, merge, or checkout-detach",
+ "submodule update" can allow a custom command to be used in to
+ update the working tree of submodules via the "submodule.*.update"
+ configuration variable.
+
+ * "git submodule update" can optionally clone the submodule
+ repositories shallowly.
+
+ * "git format-patch" learned "--from[=whom]" option, which sets the
+ "From: " header to the specified person (or the person who runs the
+ command, if "=whom" part is missing) and move the original author
+ information to an in-body From: header as necessary.
+
+ * The configuration variable "merge.ff" was cleary a tri-state to
+ choose one from "favor fast-forward when possible", "always create
+ a merge even when the history could fast-forward" and "do not
+ create any merge, only update when the history fast-forwards", but
+ the command line parser did not implement the usual convention of
+ "last one wins, and command line overrides the configuration"
+ correctly.
+
+ * "gitweb" learned to optionally place extra links that point at the
+ levels higher than the Gitweb pages themselves in the breadcrumbs,
+ so that it can be used as part of a larger installation.
+
+ * "git log --format=" now honors i18n.logoutputencoding configuration
+ variable.
+
+ * The "push.default=simple" mode of "git push" has been updated to
+ behave like "current" without requiring a remote tracking
+ information, when you push to a remote that is different from where
+ you fetch from (i.e. a triangular workflow).
+
+ * Having multiple "fixup!" on a line in the rebase instruction sheet
+ did not work very well with "git rebase -i --autosquash".
+
+ * "git log" learned the "--author-date-order" option, with which the
+ output is topologically sorted and commits in parallel histories
+ are shown intermixed together based on the author timestamp.
+
+ * Various subcommands of "git submodule" refused to run from anywhere
+ other than the top of the working tree of the superproject, but
+ they have been taught to let you run from a subdirectory.
+
+ * "git diff" learned a mode that ignores hunks whose change consists
+ only of additions and removals of blank lines, which is the same as
+ "diff -B" (ignore blank lines) of GNU diff.
+
+ * "git rm" gives a single message followed by list of paths to report
+ multiple paths that cannot be removed.
+
+ * "git rebase" can be told with ":/look for this string" syntax commits
+ to replay the changes onto and where the work to be replayed begins.
+
+ * Many tutorials teach users to set "color.ui" to "auto" as the first
+ thing after you set "user.name/email" to introduce yourselves to
+ Git. Now the variable defaults to "auto".
+
+ * On Cygwin, "cygstart" is now recognised as a possible way to start
+ a web browser (used in "help -w" and "instaweb" among others).
+
+ * "git status" learned status.branch and status.short configuration
+ variables to use --branch and --short options by default (override
+ with --no-branch and --no-short options from the command line).
+
+ * "git cmd <name>", when <name> happens to be a 40-hex string,
+ directly uses the 40-hex string as an object name, even if a ref
+ "refs/<some hierarchy>/<name>" exists. This disambiguation order
+ is unlikely to change, but we should warn about the ambiguity just
+ like we warn when more than one refs/ hierarchies share the same
+ name.
+
+ * "git rebase" learned "--[no-]autostash" option to save local
+ changes instead of refusing to run (to which people's normal
+ response was to stash them and re-run). This introduced a corner
+ case breakage to "git am --abort" but it has been fixed.
+
+ * "check-ignore" (new feature since 1.8.2) has been updated to work
+ more like "check-attr" over bidi-pipes.
+
+ * "git describe" learned "--first-parent" option to limit its closest
+ tagged commit search to the first-parent chain.
+
+ * "git merge foo" that might have meant "git merge origin/foo" is
+ diagnosed with a more informative error message.
+
+ * "git log -L<line>,<range>:<filename>" has been added. This may
+ still have leaks and rough edges, though.
+
+ * We used the approxidate() parser for "--expire=<timestamp>" options
+ of various commands, but it is better to treat --expire=all and
+ --expire=now a bit more specially than using the current timestamp.
+ "git gc" and "git reflog" have been updated with a new parsing
+ function for expiry dates.
+
+ * Updates to completion (both bash and zsh) helpers.
+
+ * The behaviour of the "--chain-reply-to" option of "git send-email"
+ have changed at 1.7.0, and we added a warning/advice message to
+ help users adjust to the new behaviour back then, but we kept it
+ around for too long. The message has finally been removed.
+
+ * "git fetch origin master" unlike "git fetch origin" or "git fetch"
+ did not update "refs/remotes/origin/master"; this was an early
+ design decision to keep the update of remote tracking branches
+ predictable, but in practice it turns out that people find it more
+ convenient to opportunistically update them whenever we have a
+ chance, and we have been updating them when we run "git push" which
+ already breaks the original "predictability" anyway.
+
+ * The configuration variable core.checkstat was advertised in the
+ documentation but the code expected core.statinfo instead.
+ For now, we accept both core.checkstat and core.statinfo, but the
+ latter will be removed in the longer term.
+
+
+Performance, Internal Implementation, etc.
+
+ * On Cygwin, we used to use our own lstat(2) emulation that is
+ allegedly faster than the platform one in codepaths where some of
+ the information it returns did not matter, but it started to bite
+ us in a few codepaths where the trick it uses to cheat does show
+ breakages. This emulation has been removed and we use the native
+ lstat(2) emulation supplied by Cygwin now.
+
+ * The function attributes extensions are used to catch mistakes in
+ use of our own variadic functions that use NULL sentinel at the end
+ (i.e. like execl(3)) and format strings (i.e. like printf(3)).
+
+ * The code to allow configuration data to be read from in-tree blob
+ objects is in. This may help working in a bare repository and
+ submodule updates.
+
+ * Fetching between repositories with many refs employed O(n^2)
+ algorithm to match up the common objects, which has been corrected.
+
+ * The original way to specify remote repository using .git/branches/
+ used to have a nifty feature. The code to support the feature was
+ still in a function but the caller was changed not to call it 5
+ years ago, breaking that feature and leaving the supporting code
+ unreachable. The dead code has been removed.
+
+ * "git pack-refs" that races with new ref creation or deletion have
+ been susceptible to lossage of refs under right conditions, which
+ has been tightened up.
+
+ * We read loose and packed references in two steps, but after
+ deciding to read a loose ref but before actually opening it to read
+ it, another process racing with us can unlink it, which would cause
+ us to barf. The codepath has been updated to retry when such a
+ race is detected, instead of outright failing.
+
+ * Uses of the platform fnmatch(3) function (many places in the code,
+ matching pathspec, .gitignore and .gitattributes to name a few)
+ have been replaced with wildmatch, allowing "foo/**/bar" that would
+ match foo/bar, foo/a/bar, foo/a/b/bar, etc.
+
+ * Memory ownership and lifetime rules for what for-each-ref feeds to
+ its callbacks have been clarified (in short, "you do not own it, so
+ make a copy if you want to keep it").
+
+ * The revision traversal logic to improve culling of irrelevant
+ parents while traversing a mergy history has been updated.
+
+ * Some leaks in unpack-trees (used in merge, cherry-pick and other
+ codepaths) have been plugged.
+
+ * The codepath to read from marks files in fast-import/export did not
+ have to accept anything but 40-hex representation of the object
+ name. Further, fast-export did not need full in-core object
+ representation to have parsed wen reading from them. These
+ codepaths have been optimized by taking advantage of these access
+ patterns.
+
+ * Object lookup logic, when the object hashtable starts to become
+ crowded, has been optimized.
+
+ * When TEST_OUTPUT_DIRECTORY setting is used, it was handled somewhat
+ inconsistently between the test framework and t/Makefile, and logic
+ to summarize the results looked at a wrong place.
+
+ * "git clone" uses a lighter-weight implementation when making sure
+ that the history behind refs are complete.
+
+ * Many warnings from sparse source checker in compat/ area has been
+ squelched.
+
+ * The code to reading and updating packed-refs file has been updated,
+ correcting corner case bugs.
+
+
+Also contains various documentation updates and code clean-ups.
+
+
+Fixes since v1.8.3
+------------------
+
+Unless otherwise noted, all the fixes since v1.8.3 in the maintenance
+track are contained in this release (see release notes to them for
+details).
+
+ * Newer Net::SMTP::SSL module does not want the user programs to use
+ the default behaviour to let server certificate go without
+ verification, so by default enable the verification with a
+ mechanism to turn it off if needed.
+ (merge 35035bb rr/send-email-ssl-verify later to maint).
+
+ * When "git" is spawned in such a way that any of the low 3 file
+ descriptors is closed, our first open() may yield file descriptor 2,
+ and writing error message to it would screw things up in a big way.
+ (merge a11c396 tr/protect-low-3-fds later to maint).
+
+ * The mailmap mechanism unnecessarily downcased the e-mail addresses
+ in the output, and also ignored the human name when it is a single
+ character name.
+ (merge bd23794 jc/mailmap-case-insensitivity later to maint).
+
+ * In two places we did not check return value (expected to be a file
+ descriptor) correctly.
+ (merge a77f106 tr/fd-gotcha-fixes later to maint).
+
+ * Logic to auto-detect character encodings in the commit log message
+ did not reject overlong and invalid UTF-8 characters.
+ (merge 81050ac bc/commit-invalid-utf8 later to maint).
+
+ * Pass port number as a separate argument when "send-email" initializes
+ Net::SMTP, instead of as a part of the hostname, i.e. host:port.
+ This allows GSSAPI codepath to match with the hostname given.
+ (merge 1a741bf bc/send-email-use-port-as-separate-param later to maint).
+
+ * "git diff" refused to even show difference when core.safecrlf is
+ set to true (i.e. error out) and there are offending lines in the
+ working tree files.
+ (merge 5430bb2 jc/maint-diff-core-safecrlf later to maint).
+
+ * A test that should have failed but didn't revealed a bug that needs
+ to be corrected.
+ (merge 94d75d1 jc/t1512-fix later to maint).
+
+ * An overlong path to a .git directory may have overflown the
+ temporary path buffer used to create a name for lockfiles.
+ (merge 2fbd4f9 mh/maint-lockfile-overflow later to maint).
+
+ * Invocations of "git checkout" used internally by "git rebase" were
+ counted as "checkout", and affected later "git checkout -", which took
+ the user to an unexpected place.
+ (merge 3bed291 rr/rebase-checkout-reflog later to maint).
+
+ * The configuration variable column.ui was poorly documented.
+ (merge 5e62cc1 rr/column-doc later to maint).
+
+ * "git name-rev --refs=tags/v*" were forbidden, which was a bit
+ inconvenient (you had to give a pattern to match refs fully, like
+ --refs=refs/tags/v*).
+ (merge 98c5c4a nk/name-rev-abbreviated-refs later to maint).
+
+ * "git apply" parsed patches that add new files, generated by
+ programs other than Git, incorrectly. This is an old breakage in
+ v1.7.11 and will need to be merged down to the maintenance tracks.
+
+ * Older cURL wanted piece of memory we call it with to be stable, but
+ we updated the auth material after handing it to a call.
+
+ * "git pull" into nothing trashed "local changes" that were in the
+ index, and this avoids it.
+
+ * Many "git submodule" operations do not work on a submodule at a
+ path whose name is not in ASCII.
+
+ * "cherry-pick" had a small leak in an error codepath.
+
+ * Logic used by git-send-email to suppress cc mishandled names like
+ "A U. Thor" <author@example.xz>, where the human readable part
+ needs to be quoted (the user input may not have the double quotes
+ around the name, and comparison was done between quoted and
+ unquoted strings). It also mishandled names that need RFC2047
+ quoting.
+
+ * Call to discard_cache/discard_index (used when we use different
+ contents of the index in-core, in many operations like commit,
+ apply, and merge) used to leak memory that held the array of index
+ entries, which has been plugged.
+ (merge a0fc4db rs/discard-index-discard-array later to maint).
+
+ * "gitweb" forgot to clear a global variable $search_regexp upon each
+ request, mistakenly carrying over the previous search to a new one
+ when used as a persistent CGI.
+
+ * The wildmatch engine did not honor WM_CASEFOLD option correctly.
+
+ * "git log -c --follow $path" segfaulted upon hitting the commit that
+ renamed the $path being followed.
+
+ * When a reflog notation is used for implicit "current branch", we
+ did not say which branch and worse said "branch ''".
+
+ * "difftool --dir-diff" did not copy back changes made by the
+ end-user in the diff tool backend to the working tree in some
+ cases.
+
+ * "git push $there HEAD:branch" did not resolve HEAD early enough, so
+ it was easy to flip it around while push is still going on and push
+ out a branch that the user did not originally intended when the
+ command was started.
+
+ * The bash prompt code (in contrib/) displayed the name of the branch
+ being rebased when "rebase -i/-m/-p" modes are in use, but not the
+ plain vanilla "rebase".
+
+ * Handling of negative exclude pattern for directories "!dir" was
+ broken in the update to v1.8.3.
+
+ * zsh prompt script that borrowed from bash prompt script did not
+ work due to slight differences in array variable notation between
+ these two shells.
+
+ * An entry for "file://" scheme in the enumeration of URL types Git
+ can take in the HTML documentation was made into a clickable link
+ by mistake.
+
+ * "git push --[no-]verify" was not documented.
+
+ * Stop installing the git-remote-testpy script that is only used for
+ testing.
+
+ * "git commit --allow-empty-message -m ''" should not start an
+ editor.
+
+ * "git merge @{-1}~22" was rewritten to "git merge frotz@{1}~22"
+ incorrectly when your previous branch was "frotz" (it should be
+ rewritten to "git merge frotz~22" instead).
+
+ * "git diff -c -p" was not showing a deleted line from a hunk when
+ another hunk immediately begins where the earlier one ends.
+
+ * "git log --ancestry-path A...B" did not work as expected, as it did
+ not pay attention to the fact that the merge base between A and B
+ was the bottom of the range being specified.
+
+ * Mac OS X does not like to write(2) more than INT_MAX number of
+ bytes; work it around by chopping write(2) into smaller pieces.
+
+ * Newer MacOS X encourages the programs to compile and link with
+ their CommonCrypto, not with OpenSSL.
+
+ * "git clone foo/bar:baz" cannot be a request to clone from a remote
+ over git-over-ssh specified in the scp style. This case is now
+ detected and clones from a local repository at "foo/bar:baz".
+
+ * When $HOME is misconfigured to point at an unreadable directory, we
+ used to complain and die. Loosen the check.
+
+ * "git subtree" (in contrib/) had one codepath with loose error
+ checks to lose data at the remote side.
+
+ * "git fetch" into a shallow repository from a repository that does
+ not know about the shallow boundary commits (e.g. a different fork
+ from the repository the current shallow repository was cloned from)
+ did not work correctly.
+
+ * "git checkout foo" DWIMs the intended "upstream" and turns it into
+ "git checkout -t -b foo remotes/origin/foo". This codepath has been
+ updated to correctly take existing remote definitions into account.
diff --git a/RelNotes/1.8.5.1.adoc b/RelNotes/1.8.5.1.adoc
new file mode 100644
index 0000000..7236aaf
--- /dev/null
+++ b/RelNotes/1.8.5.1.adoc
@@ -0,0 +1,9 @@
+Git v1.8.5.1 Release Notes
+==========================
+
+Fixes since v1.8.5
+------------------
+
+ * "git submodule init" copied "submodule.$name.update" settings from
+ .gitmodules to .git/config without making sure if the suggested
+ value was sensible.
diff --git a/RelNotes/1.8.5.2.adoc b/RelNotes/1.8.5.2.adoc
new file mode 100644
index 0000000..3ac4984
--- /dev/null
+++ b/RelNotes/1.8.5.2.adoc
@@ -0,0 +1,20 @@
+Git v1.8.5.2 Release Notes
+==========================
+
+Fixes since v1.8.5.1
+--------------------
+
+ * "git diff -- ':(icase)makefile'" was unnecessarily rejected at the
+ command line parser.
+
+ * "git cat-file --batch-check=ok" did not check the existence of
+ the named object.
+
+ * "git am --abort" sometimes complained about not being able to write
+ a tree with an 0{40} object in it.
+
+ * Two processes creating loose objects at the same time could have
+ failed unnecessarily when the name of their new objects started
+ with the same byte value, due to a race condition.
+
+Also contains typofixes, documentation updates and trivial code clean-ups.
diff --git a/RelNotes/1.8.5.3.adoc b/RelNotes/1.8.5.3.adoc
new file mode 100644
index 0000000..3de2dd0
--- /dev/null
+++ b/RelNotes/1.8.5.3.adoc
@@ -0,0 +1,27 @@
+Git v1.8.5.3 Release Notes
+==========================
+
+Fixes since v1.8.5.2
+--------------------
+
+ * The "--[no-]informative-errors" options to "git daemon" were parsed
+ a bit too loosely, allowing any other string after these option
+ names.
+
+ * A "gc" process running as a different user should be able to stop a
+ new "gc" process from starting.
+
+ * An earlier "clean-up" introduced an unnecessary memory leak to the
+ credential subsystem.
+
+ * "git mv A B/", when B does not exist as a directory, should error
+ out, but it didn't.
+
+ * "git rev-parse <revs> -- <paths>" did not implement the usual
+ disambiguation rules the commands in the "git log" family used in
+ the same way.
+
+ * "git cat-file --batch=", an admittedly useless command, did not
+ behave very well.
+
+Also contains typofixes, documentation updates and trivial code clean-ups.
diff --git a/RelNotes/1.8.5.4.adoc b/RelNotes/1.8.5.4.adoc
new file mode 100644
index 0000000..d18c403
--- /dev/null
+++ b/RelNotes/1.8.5.4.adoc
@@ -0,0 +1,48 @@
+Git v1.8.5.4 Release Notes
+==========================
+
+Fixes since v1.8.5.3
+--------------------
+
+ * "git fetch --depth=0" was a no-op, and was silently ignored.
+ Diagnose it as an error.
+
+ * Remote repository URL expressed in scp-style host:path notation are
+ parsed more carefully (e.g. "foo/bar:baz" is local, "[::1]:/~user" asks
+ to connect to user's home directory on host at address ::1.
+
+ * SSL-related options were not passed correctly to underlying socket
+ layer in "git send-email".
+
+ * "git commit -v" appends the patch to the log message before
+ editing, and then removes the patch when the editor returned
+ control. However, the patch was not stripped correctly when the
+ first modified path was a submodule.
+
+ * "git mv A B/", when B does not exist as a directory, should error
+ out, but it didn't.
+
+ * When we figure out how many file descriptors to allocate for
+ keeping packfiles open, a system with non-working getrlimit() could
+ cause us to die(), but because we make this call only to get a
+ rough estimate of how many is available and we do not even attempt
+ to use up all file descriptors available ourselves, it is nicer to
+ fall back to a reasonable low value rather than dying.
+
+ * "git log --decorate" did not handle a tag pointed by another tag
+ nicely.
+
+ * "git add -A" (no other arguments) in a totally empty working tree
+ used to emit an error.
+
+ * There is no reason to have a hardcoded upper limit of the number of
+ parents for an octopus merge, created via the graft mechanism, but
+ there was.
+
+ * The implementation of 'git stash $cmd "stash@{...}"' did not quote
+ the stash argument properly and left it split at IFS whitespace.
+
+ * The documentation to "git pull" hinted there is an "-m" option
+ because it incorrectly shared the documentation with "git merge".
+
+Also contains typofixes, documentation updates and trivial code clean-ups.
diff --git a/RelNotes/1.8.5.5.adoc b/RelNotes/1.8.5.5.adoc
new file mode 100644
index 0000000..9191ce9
--- /dev/null
+++ b/RelNotes/1.8.5.5.adoc
@@ -0,0 +1,37 @@
+Git v1.8.5.5 Release Notes
+==========================
+
+Fixes since v1.8.5.4
+--------------------
+
+ * The pathspec matching code, while comparing two trees (e.g. "git
+ diff A B -- path1 path2") was too aggressive and failed to match
+ some paths when multiple pathspecs were involved.
+
+ * "git repack --max-pack-size=8g" stopped being parsed correctly when
+ the command was reimplemented in C.
+
+ * A recent update to "git send-email" broke platforms where
+ /etc/ssl/certs/ directory exists but cannot be used as SSL_ca_path
+ (e.g. Fedora rawhide).
+
+ * A handful of bugs around interpreting $branch@{upstream} notation
+ and its lookalike, when $branch part has interesting characters,
+ e.g. "@", and ":", have been fixed.
+
+ * "git clone" would fail to clone from a repository that has a ref
+ directly under "refs/", e.g. "refs/stash", because different
+ validation paths do different things on such a refname. Loosen the
+ client side's validation to allow such a ref.
+
+ * "git log --left-right A...B" lost the "leftness" of commits
+ reachable from A when A is a tag as a side effect of a recent
+ bugfix. This is a regression in 1.8.4.x series.
+
+ * "git merge-base --octopus" used to leave cleaning up suboptimal
+ result to the caller, but now it does the clean-up itself.
+
+ * "git mv A B/", when B does not exist as a directory, should error
+ out, but it didn't.
+
+Also contains typofixes, documentation updates and trivial code clean-ups.
diff --git a/RelNotes/1.8.5.6.adoc b/RelNotes/1.8.5.6.adoc
new file mode 100644
index 0000000..92ff92b
--- /dev/null
+++ b/RelNotes/1.8.5.6.adoc
@@ -0,0 +1,34 @@
+Git v1.8.5.6 Release Notes
+==========================
+
+Fixes since v1.8.5.5
+--------------------
+
+ * We used to allow committing a path ".Git/config" with Git that is
+ running on a case sensitive filesystem, but an attempt to check out
+ such a path with Git that runs on a case insensitive filesystem
+ would have clobbered ".git/config", which is definitely not what
+ the user would have expected. Git now prevents you from tracking
+ a path with ".Git" (in any case combination) as a path component.
+
+ * On Windows, certain path components that are different from ".git"
+ are mapped to ".git", e.g. "git~1/config" is treated as if it were
+ ".git/config". HFS+ has a similar issue, where certain unicode
+ codepoints are ignored, e.g. ".g\u200cit/config" is treated as if
+ it were ".git/config". Pathnames with these potential issues are
+ rejected on the affected systems. Git on systems that are not
+ affected by this issue (e.g. Linux) can also be configured to
+ reject them to ensure cross platform interoperability of the hosted
+ projects.
+
+ * "git fsck" notices a tree object that records such a path that can
+ be confused with ".git", and with receive.fsckObjects configuration
+ set to true, an attempt to "git push" such a tree object will be
+ rejected. Such a path may not be a problem on a well behaving
+ filesystem but in order to protect those on HFS+ and on case
+ insensitive filesystems, this check is enabled on all platforms.
+
+A big "thanks!" for bringing this issue to us goes to our friends in
+the Mercurial land, namely, Matt Mackall and Augie Fackler.
+
+Also contains typofixes, documentation updates and trivial code clean-ups.
diff --git a/RelNotes/1.8.5.adoc b/RelNotes/1.8.5.adoc
new file mode 100644
index 0000000..602df0c
--- /dev/null
+++ b/RelNotes/1.8.5.adoc
@@ -0,0 +1,456 @@
+Git v1.8.5 Release Notes
+========================
+
+Backward compatibility notes (for Git 2.0)
+------------------------------------------
+
+When "git push [$there]" does not say what to push, we have used the
+traditional "matching" semantics so far (all your branches were sent
+to the remote as long as there already are branches of the same name
+over there). In Git 2.0, the default will change to the "simple"
+semantics, which pushes:
+
+ - only the current branch to the branch with the same name, and only
+ when the current branch is set to integrate with that remote
+ branch, if you are pushing to the same remote as you fetch from; or
+
+ - only the current branch to the branch with the same name, if you
+ are pushing to a remote that is not where you usually fetch from.
+
+Use the user preference configuration variable "push.default" to
+change this. If you are an old-timer who is used to the "matching"
+semantics, you can set the variable to "matching" to keep the
+traditional behaviour. If you want to live in the future early, you
+can set it to "simple" today without waiting for Git 2.0.
+
+When "git add -u" (and "git add -A") is run inside a subdirectory and
+does not specify which paths to add on the command line, it
+will operate on the entire tree in Git 2.0 for consistency
+with "git commit -a" and other commands. There will be no
+mechanism to make plain "git add -u" behave like "git add -u .".
+Current users of "git add -u" (without a pathspec) should start
+training their fingers to explicitly say "git add -u ."
+before Git 2.0 comes. A warning is issued when these commands are
+run without a pathspec and when you have local changes outside the
+current directory, because the behaviour in Git 2.0 will be different
+from today's version in such a situation.
+
+In Git 2.0, "git add <path>" will behave as "git add -A <path>", so
+that "git add dir/" will notice paths you removed from the directory
+and record the removal. Versions before Git 2.0, including this
+release, will keep ignoring removals, but the users who rely on this
+behaviour are encouraged to start using "git add --ignore-removal <path>"
+now before 2.0 is released.
+
+The default prefix for "git svn" will change in Git 2.0. For a long
+time, "git svn" created its remote-tracking branches directly under
+refs/remotes, but it will place them under refs/remotes/origin/ unless
+it is told otherwise with its --prefix option.
+
+
+Updates since v1.8.4
+--------------------
+
+Foreign interfaces, subsystems and ports.
+
+ * "git-svn" has been taught to use the serf library, which is the
+ only option SVN 1.8.0 offers us when talking the HTTP protocol.
+
+ * "git-svn" talking over an https:// connection using the serf library
+ dumped core due to a bug in the serf library that SVN uses. Work
+ around it on our side, even though the SVN side is being fixed.
+
+ * On MacOS X, we detected if the filesystem needs the "pre-composed
+ unicode strings" workaround, but did not automatically enable it.
+ Now we do.
+
+ * remote-hg remote helper misbehaved when interacting with a local Hg
+ repository relative to the home directory, e.g. "clone hg::~/there".
+
+ * imap-send ported to OS X uses Apple's security framework instead of
+ OpenSSL's.
+
+ * "git fast-import" treats an empty path given to "ls" as the root of
+ the tree.
+
+
+UI, Workflows & Features
+
+ * xdg-open can be used as a browser backend for "git web-browse"
+ (hence to show "git help -w" output), when available.
+
+ * "git grep" and "git show" pay attention to the "--textconv" option
+ when these commands are told to operate on blob objects (e.g. "git
+ grep -e pattern --textconv HEAD:Makefile").
+
+ * "git replace" helper no longer allows an object to be replaced with
+ another object of a different type to avoid confusion (you can
+ still manually craft such a replacement using "git update-ref", as an
+ escape hatch).
+
+ * "git status" no longer prints the dirty status information of
+ submodules for which submodule.$name.ignore is set to "all".
+
+ * "git rebase -i" honours core.abbrev when preparing the insn sheet
+ for editing.
+
+ * "git status" during a cherry-pick shows which original commit is
+ being picked.
+
+ * Instead of typing four capital letters "HEAD", you can say "@" now,
+ e.g. "git log @".
+
+ * "git check-ignore" follows the same rule as "git add" and "git
+ status" in that the ignore/exclude mechanism does not take effect
+ on paths that are already tracked. With the "--no-index" option, it
+ can be used to diagnose which paths that should have been ignored
+ have been mistakenly added to the index.
+
+ * Some irrelevant "advice" messages that are shared with "git status"
+ output have been removed from the commit log template.
+
+ * "update-refs" learned a "--stdin" option to read multiple update
+ requests and perform them in an all-or-none fashion.
+
+ * Just like "make -C <directory>", "git -C <directory> ..." tells Git
+ to go there before doing anything else.
+
+ * Just like "git checkout -" knows to check out, and "git merge -"
+ knows to merge, the branch you were previously on, "git cherry-pick"
+ now understands "git cherry-pick -" to pick from the previous
+ branch.
+
+ * "git status" now omits the prefix to make its output a comment in a
+ commit log editor, which is not necessary for human consumption.
+ Scripts that parse the output of "git status" are advised to use
+ "git status --porcelain" instead, as its format is stable and easier
+ to parse.
+
+ * The ref syntax "foo^{tag}" (with the literal string "{tag}") peels a
+ tag ref to itself, i.e. it's a no-op., and fails if
+ "foo" is not a tag. "git rev-parse --verify v1.0^{tag}" is
+ a more convenient way than "test $(git cat-file -t v1.0) = tag" to
+ check if v1.0 is a tag.
+
+ * "git branch -v -v" (and "git status") did not distinguish among a
+ branch that is not based on any other branch, a branch that is in
+ sync with its upstream branch, and a branch that is configured with an
+ upstream branch that no longer exists.
+
+ * Earlier we started rejecting any attempt to add the 0{40} object name to
+ the index and to tree objects, but it sometimes is necessary to
+ allow this to be able to use tools like filter-branch to correct such
+ broken tree objects. "filter-branch" can again be used to do this.
+
+ * "git config" did not provide a way to set or access numbers larger
+ than a native "int" on the platform; it now provides 64-bit signed
+ integers on all platforms.
+
+ * "git pull --rebase" always chose to do the bog-standard flattening
+ rebase. You can tell it to run "rebase --preserve-merges" with
+ "git pull --rebase=preserve" or by
+ setting "pull.rebase" configuration to "preserve".
+
+ * "git push --no-thin" actually disables the "thin pack transfer"
+ optimization.
+
+ * Magic pathspecs like ":(icase)makefile" (matches both Makefile
+ and makefile) and ":(glob)foo/**/bar" (matches "bar" in "foo"
+ and any subdirectory of "foo") can be used in more places.
+
+ * The "http.*" variables can now be specified for individual URLs.
+ For example,
+
+ [http]
+ sslVerify = true
+ [http "https://weak.example.com/"]
+ sslVerify = false
+
+ would flip http.sslVerify off only when talking to that specific
+ site.
+
+ * "git mv A B" when moving a submodule has been taught to
+ relocate the submodule's working tree and to adjust the paths in the
+ .gitmodules file.
+
+ * "git blame" can now take more than one -L option to discover the
+ origin of multiple blocks of lines.
+
+ * The http transport clients can optionally ask to save cookies
+ with the http.savecookies configuration variable.
+
+ * "git push" learned a more fine grained control over a blunt
+ "--force" when requesting a non-fast-forward update with the
+ "--force-with-lease=<refname>:<expected object name>" option.
+
+ * "git diff --diff-filter=<classes of changes>" can now take
+ lowercase letters (e.g. "--diff-filter=d") to mean "show
+ everything but these classes". "git diff-files -q" is now a
+ deprecated synonym for "git diff-files --diff-filter=d".
+
+ * "git fetch" (hence "git pull" as well) learned to check
+ "fetch.prune" and "remote.*.prune" configuration variables and
+ to behave as if the "--prune" command line option was given.
+
+ * "git check-ignore -z" applied the NUL termination to both its input
+ (with --stdin) and its output, but "git check-attr -z" ignored the
+ option on the output side. Make both honor -z on the input and
+ output side the same way.
+
+ * "git whatchanged" may still be used by old timers, but mention of
+ it in documents meant for new users will only waste readers' time
+ wondering what the difference is between it and "git log". Make it
+ less prominent in the general part of the documentation and explain
+ that it is merely a "git log" with different default behaviour in
+ its own document.
+
+
+Performance, Internal Implementation, etc.
+
+ * "git for-each-ref" when asking for merely the object name does not
+ have to parse the object pointed at by the refs; the codepath has
+ been optimized.
+
+ * The HTTP transport will try to use TCP keepalive when able.
+
+ * "git repack" is now written in C.
+
+ * Build procedure for MSVC has been updated.
+
+ * If a build-time fallback is set to "cat" instead of "less", we
+ should apply the same "no subprocess or pipe" optimization as we
+ apply to user-supplied GIT_PAGER=cat.
+
+ * Many commands use a --dashed-option as an operation mode selector
+ (e.g. "git tag --delete") that excludes other operation modes
+ (e.g. "git tag --delete --verify" is nonsense) and that cannot be
+ negated (e.g. "git tag --no-delete" is nonsense). The parse-options
+ API learned a new OPT_CMDMODE macro to make it easier to implement
+ such a set of options.
+
+ * OPT_BOOLEAN() in the parse-options API was misdesigned to be "counting
+ up" but many subcommands expect it to behave as "on/off". Update
+ them to use OPT_BOOL() which is a proper boolean.
+
+ * "git gc" exits early without doing any work when it detects
+ that another instance of itself is already running.
+
+ * Under memory pressure and/or file descriptor pressure, we used to
+ close pack windows that are not used and also closed filehandles to
+ open but unused packfiles. These are now controlled separately
+ to better cope with the load.
+
+Also contains various documentation updates and code clean-ups.
+
+
+Fixes since v1.8.4
+------------------
+
+Unless otherwise noted, all the fixes since v1.8.4 in the maintenance
+track are contained in this release (see the maintenance releases' notes for
+details).
+
+ * An ancient How-To on serving Git repositories on an HTTP server
+ lacked a warning that it has been mostly superseded with a more
+ modern way.
+ (merge 6d52bc3 sc/doc-howto-dumb-http later to maint).
+
+ * The interaction between the use of Perl in our test suite and NO_PERL
+ has been clarified a bit.
+ (merge f8fc0ee jn/test-prereq-perl-doc later to maint).
+
+ * The synopsis section of the "git unpack-objects" documentation has been
+ clarified a bit.
+ (merge 61e2e22 vd/doc-unpack-objects later to maint).
+
+ * We did not generate the HTML version of the documentation to "git subtree"
+ in contrib/.
+ (merge 95c62fb jk/subtree-install-fix later to maint).
+
+ * A fast-import stream expresses a pathname with funny characters by
+ quoting them in C style; the remote-hg remote helper forgot to unquote
+ such a path.
+ (merge 1136265 ap/remote-hg-unquote-cquote later to maint).
+
+ * "git reset -p HEAD" has a codepath to special-case it to behave
+ differently from resetting to contents of other commits, but a
+ recent change broke it.
+
+ * Coloring around octopus merges in "log --graph" output was screwy.
+ (merge 339c17b hn/log-graph-color-octopus later to maint).
+
+ * "git checkout topic", when there is not yet a local "topic" branch
+ but there is a unique remote-tracking branch for a remote "topic"
+ branch, pretended as if "git checkout -t -b topic remote/$r/topic"
+ (for that unique remote $r) was run. This hack however was not
+ implemented for "git checkout topic --".
+ (merge bca3969 mm/checkout-auto-track-fix later to maint).
+
+ * One long-standing flaw in the pack transfer protocol used by "git
+ clone" was that there was no way to tell the other end which branch
+ "HEAD" points at, and the receiving end needed to guess. A new
+ capability has been defined in the pack protocol to convey this
+ information so that cloning from a repository with more than one
+ branch pointing at the same commit where the HEAD is at now
+ reliably sets the initial branch in the resulting repository.
+ (merge 360a326 jc/upload-pack-send-symref later to maint).
+
+ * We did not handle cases where the http transport gets redirected during
+ the authorization request (e.g. from http:// to https://).
+ (merge 70900ed jk/http-auth-redirects later to maint).
+
+ * Bash prompting code to deal with an SVN remote as an upstream
+ was coded in a way unsupported by older Bash versions (3.x).
+ (merge 52ec889 sg/prompt-svn-remote-fix later to maint).
+
+ * The fall-back parsing of commit objects with broken author or
+ committer lines was less robust than ideal in picking up the
+ timestamps.
+ (merge 03818a4 jk/split-broken-ident later to maint).
+
+ * "git rev-list --objects ^v1.0^ v1.0" gave the v1.0 tag itself in the
+ output, but "git rev-list --objects v1.0^..v1.0" did not.
+ (merge 895c5ba jc/revision-range-unpeel later to maint).
+
+ * "git clone" wrote some progress messages to standard output, not
+ to standard error, and did not suppress them with the
+ --no-progress option.
+ (merge 643f918 jk/clone-progress-to-stderr later to maint).
+
+ * "format-patch --from=<whom>" forgot to omit an unnecessary in-body
+ from line, i.e. when <whom> is the same as the real author.
+ (merge 662cc30 jk/format-patch-from later to maint).
+
+ * "git shortlog" used to choke and die when there is a malformed
+ commit (e.g. missing authors); it now simply ignores such a commit
+ and keeps going.
+ (merge cd4f09e jk/shortlog-tolerate-broken-commit later to maint).
+
+ * "git merge-recursive" did not parse its "--diff-algorithm=" command
+ line option correctly.
+ (merge 6562928 jk/diff-algo later to maint).
+
+ * When running "fetch -q", a long silence while the sender side
+ computes the set of objects to send can be mistaken by proxies as
+ dropped connection. The server side has been taught to send a
+ small empty messages to keep the connection alive.
+ (merge 115dedd jk/upload-pack-keepalive later to maint).
+
+ * "git rebase" had a portability regression in v1.8.4 that triggered a
+ bug in some BSD shell implementations.
+ (merge 99855dd mm/rebase-continue-freebsd-WB later to maint).
+
+ * "git branch --track" had a minor regression in v1.8.3.2 and later
+ that made it impossible to base your local work on anything but a
+ local branch of the upstream repository you are tracking.
+ (merge b0f49ff jh/checkout-auto-tracking later to maint).
+
+ * When the web server responds with "405 Method Not Allowed", "git
+ http-backend" should tell the client what methods are allowed with
+ the "Allow" header.
+ (merge 9247be0 bc/http-backend-allow-405 later to maint).
+
+ * When there is no sufficient overlap between old and new history
+ during a "git fetch" into a shallow repository, objects that the
+ sending side knows the receiving end has were unnecessarily sent.
+ (merge f21d2a7 nd/fetch-into-shallow later to maint).
+
+ * "git cvsserver" computed the permission mode bits incorrectly for
+ executable files.
+ (merge 1b48d56 jc/cvsserver-perm-bit-fix later to maint).
+
+ * When send-email obtains an error message to die with upon
+ failure to start an SSL session, it tried to read the error string
+ from a wrong place.
+ (merge 6cb0c88 bc/send-email-ssl-die-message-fix later to maint).
+
+ * The implementation of "add -i" has some crippling code to work around an
+ ActiveState Perl limitation but it by mistake also triggered on Git
+ for Windows where MSYS perl is used.
+ (merge df17e77 js/add-i-mingw later to maint).
+
+ * We made sure that we notice when the user-supplied GIT_DIR is actually a
+ gitfile, but did not do the same when the default ".git" is a
+ gitfile.
+ (merge 487a2b7 nd/git-dir-pointing-at-gitfile later to maint).
+
+ * When an object is not found after checking the packfiles and the
+ loose object directory, read_sha1_file() re-checks the packfiles to
+ prevent racing with a concurrent repacker; teach the same logic to
+ has_sha1_file().
+ (merge 45e8a74 jk/has-sha1-file-retry-packed later to maint).
+
+ * "git commit --author=$name", when $name is not in the canonical
+ "A. U. Thor <au.thor@example.xz>" format, looks for a matching name
+ from existing history, but did not consult mailmap to grab the
+ preferred author name.
+ (merge ea16794 ap/commit-author-mailmap later to maint).
+
+ * "git ls-files -k" needs to crawl only the part of the working tree
+ that may overlap the paths in the index to find killed files, but
+ shared code with the logic to find all the untracked files, which
+ made it unnecessarily inefficient.
+ (merge 680be04 jc/ls-files-killed-optim later to maint).
+
+ * The shortened commit object names in the insn sheet that is prepared at the
+ beginning of a "rebase -i" session can become ambiguous as the
+ rebasing progresses and the repository gains more commits. Make
+ sure the internal record is kept with full 40-hex object names.
+ (merge 75c6976 es/rebase-i-no-abbrev later to maint).
+
+ * "git rebase --preserve-merges" internally used the merge machinery
+ and as a side effect left the merge summary message in the log, but
+ when rebasing there is no need for the merge summary.
+ (merge a9f739c rt/rebase-p-no-merge-summary later to maint).
+
+ * A call to xread() was used without a loop around it to cope with short
+ reads in the codepath to stream new contents to a pack.
+ (merge e92527c js/xread-in-full later to maint).
+
+ * "git rebase -i" forgot that the comment character is
+ configurable while reading its insn sheet.
+ (merge 7bca7af es/rebase-i-respect-core-commentchar later to maint).
+
+ * The mailmap support code read past the allocated buffer when the
+ mailmap file ended with an incomplete line.
+ (merge f972a16 jk/mailmap-incomplete-line later to maint).
+
+ * We used to send a large request to read(2)/write(2) as a single
+ system call, which was bad from the latency point of view when
+ the operation needs to be killed, and also triggered an error on
+ broken 64-bit systems that refuse to read or write more than 2GB
+ in one go.
+ (merge a487916 sp/clip-read-write-to-8mb later to maint).
+
+ * "git fetch" that auto-followed tags incorrectly reused the
+ connection with Git-aware transport helper (like the sample "ext::"
+ helper shipped with Git).
+ (merge 0f73f8b jc/transport-do-not-use-connect-twice-in-fetch later to maint).
+
+ * "git log --full-diff -- <pathspec>" showed a huge diff for paths
+ outside the given <pathspec> for each commit, instead of showing
+ the change relative to the parent of the commit. "git reflog -p"
+ had a similar problem.
+ (merge 838f9a1 tr/log-full-diff-keep-true-parents later to maint).
+
+ * Setting a submodule.*.path configuration variable to true (without
+ giving "= value") caused Git to segfault.
+ (merge 4b05440 jl/some-submodule-config-are-not-boolean later to maint).
+
+ * "git rebase -i" (there could be others, as the root cause is pretty
+ generic) fed a random, data dependent string to 'echo' and
+ expected it to come out literally, corrupting its error message.
+ (merge 89b0230 mm/no-shell-escape-in-die-message later to maint).
+
+ * Some people still use rather old versions of bash, which cannot
+ grok some constructs like 'printf -v varname' which the prompt and
+ completion code started to use recently.
+ (merge a44aa69 bc/completion-for-bash-3.0 later to maint).
+
+ * Code to read configuration from a blob object did not compile on
+ platforms with fgetc() etc. implemented as macros.
+ (merge 49d6cfa hv/config-from-blob later to maint-1.8.3).
+
+ * The recent "short-cut clone connectivity check" topic broke a
+ shallow repository when a fetch operation tries to auto-follow tags.
+ (merge 6da8bdc nd/fetch-pack-shallow-fix later to maint-1.8.3).
diff --git a/RelNotes/1.9.0.adoc b/RelNotes/1.9.0.adoc
new file mode 100644
index 0000000..4e4b88a
--- /dev/null
+++ b/RelNotes/1.9.0.adoc
@@ -0,0 +1,345 @@
+Git v1.9.0 Release Notes
+========================
+
+Backward compatibility notes
+----------------------------
+
+"git submodule foreach $cmd $args" used to treat "$cmd $args" the same
+way "ssh" did, concatenating them into a single string and letting the
+shell unquote. Careless users who forget to sufficiently quote $args
+get their argument split at $IFS whitespaces by the shell, and got
+unexpected results due to this. Starting from this release, the
+command line is passed directly to the shell, if it has an argument.
+
+Read-only support for experimental loose-object format, in which users
+could optionally choose to write their loose objects for a short
+while between v1.4.3 and v1.5.3 era, has been dropped.
+
+The meanings of the "--tags" option to "git fetch" has changed; the
+command fetches tags _in addition to_ what is fetched by the same
+command line without the option.
+
+The way "git push $there $what" interprets the $what part given on the
+command line, when it does not have a colon that explicitly tells us
+what ref at the $there repository is to be updated, has been enhanced.
+
+A handful of ancient commands that have long been deprecated are
+finally gone (repo-config, tar-tree, lost-found, and peek-remote).
+
+
+Backward compatibility notes (for Git 2.0.0)
+--------------------------------------------
+
+When "git push [$there]" does not say what to push, we have used the
+traditional "matching" semantics so far (all your branches were sent
+to the remote as long as there already are branches of the same name
+over there). In Git 2.0, the default will change to the "simple"
+semantics, which pushes:
+
+ - only the current branch to the branch with the same name, and only
+ when the current branch is set to integrate with that remote
+ branch, if you are pushing to the same remote as you fetch from; or
+
+ - only the current branch to the branch with the same name, if you
+ are pushing to a remote that is not where you usually fetch from.
+
+Use the user preference configuration variable "push.default" to
+change this. If you are an old-timer who is used to the "matching"
+semantics, you can set the variable to "matching" to keep the
+traditional behaviour. If you want to live in the future early, you
+can set it to "simple" today without waiting for Git 2.0.
+
+When "git add -u" (and "git add -A") is run inside a subdirectory and
+does not specify which paths to add on the command line, it
+will operate on the entire tree in Git 2.0 for consistency
+with "git commit -a" and other commands. There will be no
+mechanism to make plain "git add -u" behave like "git add -u .".
+Current users of "git add -u" (without a pathspec) should start
+training their fingers to explicitly say "git add -u ."
+before Git 2.0 comes. A warning is issued when these commands are
+run without a pathspec and when you have local changes outside the
+current directory, because the behaviour in Git 2.0 will be different
+from today's version in such a situation.
+
+In Git 2.0, "git add <path>" will behave as "git add -A <path>", so
+that "git add dir/" will notice paths you removed from the directory
+and record the removal. Versions before Git 2.0, including this
+release, will keep ignoring removals, but the users who rely on this
+behaviour are encouraged to start using "git add --ignore-removal <path>"
+now before 2.0 is released.
+
+The default prefix for "git svn" will change in Git 2.0. For a long
+time, "git svn" created its remote-tracking branches directly under
+refs/remotes, but it will place them under refs/remotes/origin/ unless
+it is told otherwise with its --prefix option.
+
+
+Updates since v1.8.5
+--------------------
+
+Foreign interfaces, subsystems and ports.
+
+ * The HTTP transport, when talking GSS-Negotiate, uses "100
+ Continue" response to avoid having to rewind and resend a large
+ payload, which may not be always doable.
+
+ * Various bugfixes to remote-bzr and remote-hg (in contrib/).
+
+ * The build procedure is aware of MirBSD now.
+
+ * Various "git p4", "git svn" and "gitk" updates.
+
+
+UI, Workflows & Features
+
+ * Fetching from a shallowly-cloned repository used to be forbidden,
+ primarily because the codepaths involved were not carefully vetted
+ and we did not bother supporting such usage. This release attempts
+ to allow object transfer out of a shallowly-cloned repository in a
+ more controlled way (i.e. the receiver becomes a shallow repository
+ with a truncated history).
+
+ * Just like we give a reasonable default for "less" via the LESS
+ environment variable, we now specify a reasonable default for "lv"
+ via the "LV" environment variable when spawning the pager.
+
+ * Two-level configuration variable names in "branch.*" and "remote.*"
+ hierarchies, whose variables are predominantly three-level, were
+ not completed by hitting a <TAB> in bash and zsh completions.
+
+ * Fetching a 'frotz' branch with "git fetch", while a 'frotz/nitfol'
+ remote-tracking branch from an earlier fetch was still there, would
+ error out, primarily because the command was not told that it is
+ allowed to lose any information on our side. "git fetch --prune"
+ now can be used to remove 'frotz/nitfol' to make room for fetching and
+ storing the 'frotz' remote-tracking branch.
+
+ * "diff.orderfile=<file>" configuration variable can be used to
+ pretend as if the "-O<file>" option were given from the command
+ line of "git diff", etc.
+
+ * The negative pathspec syntax allows "git log -- . ':!dir'" to tell
+ us "I am interested in everything but 'dir' directory".
+
+ * "git difftool" shows how many different paths there are in total,
+ and how many of them have been shown so far, to indicate progress.
+
+ * "git push origin master" used to push our 'master' branch to update
+ the 'master' branch at the 'origin' repository. This has been
+ enhanced to use the same ref mapping "git push origin" would use to
+ determine what ref at the 'origin' to be updated with our 'master'.
+ For example, with this configuration
+
+ [remote "origin"]
+ push = refs/heads/*:refs/review/*
+
+ that would cause "git push origin" to push out our local branches
+ to corresponding refs under refs/review/ hierarchy at 'origin',
+ "git push origin master" would update 'refs/review/master' over
+ there. Alternatively, if push.default is set to 'upstream' and our
+ 'master' is set to integrate with 'topic' from the 'origin' branch,
+ running "git push origin" while on our 'master' would update their
+ 'topic' branch, and running "git push origin master" while on any
+ of our branches does the same.
+
+ * "gitweb" learned to treat ref hierarchies other than refs/heads as
+ if they are additional branch namespaces (e.g. refs/changes/ in
+ Gerrit).
+
+ * "git for-each-ref --format=..." learned a few formatting directives;
+ e.g. "%(color:red)%(HEAD)%(color:reset) %(refname:short) %(subject)".
+
+ * The command string given to "git submodule foreach" is passed
+ directly to the shell, without being eval'ed. This is a backward
+ incompatible change that may break existing users.
+
+ * "git log" and friends learned the "--exclude=<glob>" option, to
+ allow people to say "list history of all branches except those that
+ match this pattern" with "git log --exclude='*/*' --branches".
+
+ * "git rev-parse --parseopt" learned a new "--stuck-long" option to
+ help scripts parse options with an optional parameter.
+
+ * The "--tags" option to "git fetch" no longer tells the command to
+ fetch _only_ the tags. It instead fetches tags _in addition to_
+ what are fetched by the same command line without the option.
+
+
+Performance, Internal Implementation, etc.
+
+ * When parsing a 40-hex string into the object name, the string is
+ checked to see if it can be interpreted as a ref so that a warning
+ can be given for ambiguity. The code kicked in even when the
+ core.warnambiguousrefs is set to false to squelch this warning, in
+ which case the cycles spent to look at the ref namespace were an
+ expensive no-op, as the result was discarded without being used.
+
+ * The naming convention of the packfiles has been updated; it used to
+ be based on the enumeration of names of the objects that are
+ contained in the pack, but now it also depends on how the packed
+ result is represented--packing the same set of objects using
+ different settings (or delta order) would produce a pack with
+ different name.
+
+ * "git diff --no-index" mode used to unnecessarily attempt to read
+ the index when there is one.
+
+ * The deprecated parse-options macro OPT_BOOLEAN has been removed;
+ use OPT_BOOL or OPT_COUNTUP in new code.
+
+ * A few duplicate implementations of prefix/suffix string comparison
+ functions have been unified to starts_with() and ends_with().
+
+ * The new PERLLIB_EXTRA makefile variable can be used to specify
+ additional directories Perl modules (e.g. the ones necessary to run
+ git-svn) are installed on the platform when building.
+
+ * "git merge-base" learned the "--fork-point" mode, that implements
+ the same logic used in "git pull --rebase" to find a suitable fork
+ point out of the reflog entries for the remote-tracking branch the
+ work has been based on. "git rebase" has the same logic that can be
+ triggered with the "--fork-point" option.
+
+ * A third-party "receive-pack" (the responder to "git push") can
+ advertise the "no-thin" capability to tell "git push" not to use
+ the thin-pack optimization. Our receive-pack has always been
+ capable of accepting and fattening a thin-pack, and will continue
+ not to ask "git push" to use a non-thin pack.
+
+
+Also contains various documentation updates and code clean-ups.
+
+
+Fixes since v1.8.5
+------------------
+
+Unless otherwise noted, all the fixes since v1.8.5 in the maintenance
+track are contained in this release (see the maintenance releases' notes
+for details).
+
+ * The pathspec matching code, while comparing two trees (e.g. "git
+ diff A B -- path1 path2") was too aggressive and failed to match
+ some paths when multiple pathspecs were involved.
+
+ * "git repack --max-pack-size=8g" stopped being parsed correctly when
+ the command was reimplemented in C.
+
+ * An earlier update in v1.8.4.x to "git rev-list --objects" with
+ negative ref had a performance regression.
+ (merge 200abe7 jk/mark-edges-uninteresting later to maint).
+
+ * A recent update to "git send-email" broke platforms where
+ /etc/ssl/certs/ directory exists but cannot be used as SSL_ca_path
+ (e.g. Fedora rawhide).
+
+ * A handful of bugs around interpreting $branch@{upstream} notation
+ and its lookalike, when $branch part has interesting characters,
+ e.g. "@", and ":", have been fixed.
+
+ * "git clone" would fail to clone from a repository that has a ref
+ directly under "refs/", e.g. "refs/stash", because different
+ validation paths do different things on such a refname. Loosen the
+ client side's validation to allow such a ref.
+
+ * "git log --left-right A...B" lost the "leftness" of commits
+ reachable from A when A is a tag as a side effect of a recent
+ bugfix. This is a regression in 1.8.4.x series.
+
+ * documentations to "git pull" hinted there is an "-m" option because
+ it incorrectly shared the documentation with "git merge".
+
+ * "git diff A B submod" and "git diff A B submod/" ought to have done
+ the same for a submodule "submod", but didn't.
+
+ * "git clone $origin foo\bar\baz" on Windows failed to create the
+ leading directories (i.e. a moral-equivalent of "mkdir -p").
+
+ * "submodule.*.update=checkout", when propagated from .gitmodules to
+ .git/config, turned into a "submodule.*.update=none", which did not
+ make much sense.
+ (merge efa8fd7 fp/submodule-checkout-mode later to maint).
+
+ * The implementation of 'git stash $cmd "stash@{...}"' did not quote
+ the stash argument properly and left it split at IFS whitespace.
+
+ * The "--[no-]informative-errors" options to "git daemon" were parsed
+ a bit too loosely, allowing any other string after these option
+ names.
+
+ * There is no reason to have a hardcoded upper limit for the number of
+ parents of an octopus merge, created via the graft mechanism, but
+ there was.
+
+ * The basic test used to leave unnecessary trash directories in the
+ t/ directory.
+ (merge 738a8be jk/test-framework-updates later to maint).
+
+ * "git merge-base --octopus" used to leave cleaning up suboptimal
+ result to the caller, but now it does the clean-up itself.
+
+ * A "gc" process running as a different user should be able to stop a
+ new "gc" process from starting, but it didn't.
+
+ * An earlier "clean-up" introduced an unnecessary memory leak.
+
+ * "git add -A" (no other arguments) in a totally empty working tree
+ used to emit an error.
+
+ * "git log --decorate" did not handle a tag pointed by another tag
+ nicely.
+
+ * When we figure out how many file descriptors to allocate for
+ keeping packfiles open, a system with non-working getrlimit() could
+ cause us to die(), but because we make this call only to get a
+ rough estimate of how many are available and we do not even attempt
+ to use up all available file descriptors ourselves, it is nicer to
+ fall back to a reasonable low value rather than dying.
+
+ * read_sha1_file(), that is the workhorse to read the contents given
+ an object name, honoured object replacements, but there was no
+ corresponding mechanism to sha1_object_info() that was used to
+ obtain the metainfo (e.g. type & size) about the object. This led
+ callers to weird inconsistencies.
+ (merge 663a856 cc/replace-object-info later to maint).
+
+ * "git cat-file --batch=", an admittedly useless command, did not
+ behave very well.
+
+ * "git rev-parse <revs> -- <paths>" did not implement the usual
+ disambiguation rules the commands in the "git log" family used in
+ the same way.
+
+ * "git mv A B/", when B does not exist as a directory, should error
+ out, but it didn't.
+
+ * A workaround to an old bug in glibc prior to glibc 2.17 has been
+ retired; this would remove a side effect of the workaround that
+ corrupts system error messages in non-C locales.
+
+ * SSL-related options were not passed correctly to underlying socket
+ layer in "git send-email".
+
+ * "git commit -v" appends the patch to the log message before
+ editing, and then removes the patch when the editor returned
+ control. However, the patch was not stripped correctly when the
+ first modified path was a submodule.
+
+ * "git fetch --depth=0" was a no-op, and was silently ignored.
+ Diagnose it as an error.
+
+ * Remote repository URLs expressed in scp-style host:path notation are
+ parsed more carefully (e.g. "foo/bar:baz" is local, "[::1]:/~user" asks
+ to connect to user's home directory on host at address ::1.
+
+ * "git diff -- ':(icase)makefile'" was unnecessarily rejected at the
+ command line parser.
+
+ * "git cat-file --batch-check=ok" did not check the existence of
+ the named object.
+
+ * "git am --abort" sometimes complained about not being able to write
+ a tree with an 0{40} object in it.
+
+ * Two processes creating loose objects at the same time could have
+ failed unnecessarily when the name of their new objects started
+ with the same byte value, due to a race condition.
diff --git a/RelNotes/1.9.1.adoc b/RelNotes/1.9.1.adoc
new file mode 100644
index 0000000..5b06020
--- /dev/null
+++ b/RelNotes/1.9.1.adoc
@@ -0,0 +1,59 @@
+Git v1.9.1 Release Notes
+========================
+
+Fixes since v1.9.0
+------------------
+
+ * "git clean -d pathspec" did not use the given pathspec correctly
+ and ended up cleaning too much.
+
+ * "git difftool" misbehaved when the repository is bound to the
+ working tree with the ".git file" mechanism, where a textual file
+ ".git" tells us where it is.
+
+ * "git push" did not pay attention to branch.*.pushremote if it is
+ defined earlier than remote.pushdefault; the order of these two
+ variables in the configuration file should not matter, but it did
+ by mistake.
+
+ * Codepaths that parse timestamps in commit objects have been
+ tightened.
+
+ * "git diff --external-diff" incorrectly fed the submodule directory
+ in the working tree to the external diff driver when it knew it is
+ the same as one of the versions being compared.
+
+ * "git reset" needs to refresh the index when working in a working
+ tree (it can also be used to match the index to the HEAD in an
+ otherwise bare repository), but it failed to set up the working
+ tree properly, causing GIT_WORK_TREE to be ignored.
+
+ * "git check-attr" when working on a repository with a working tree
+ did not work well when the working tree was specified via the
+ --work-tree (and obviously with --git-dir) option.
+
+ * "merge-recursive" was broken in 1.7.7 era and stopped working in
+ an empty (temporary) working tree, when there are renames
+ involved. This has been corrected.
+
+ * "git rev-parse" was loose in rejecting command line arguments
+ that do not make sense, e.g. "--default" without the required
+ value for that option.
+
+ * include.path variable (or any variable that expects a path that
+ can use ~username expansion) in the configuration file is not a
+ boolean, but the code failed to check it.
+
+ * "git diff --quiet -- pathspec1 pathspec2" sometimes did not return
+ correct status value.
+
+ * Attempting to deepen a shallow repository by fetching over smart
+ HTTP transport failed in the protocol exchange, when no-done
+ extension was used. The fetching side waited for the list of
+ shallow boundary commits after the sending end stopped talking to
+ it.
+
+ * Allow "git cmd path/", when the 'path' is where a submodule is
+ bound to the top-level working tree, to match 'path', despite the
+ extra and unnecessary trailing slash (such a slash is often
+ given by command line completion).
diff --git a/RelNotes/1.9.2.adoc b/RelNotes/1.9.2.adoc
new file mode 100644
index 0000000..47a34ca
--- /dev/null
+++ b/RelNotes/1.9.2.adoc
@@ -0,0 +1,67 @@
+Git v1.9.2 Release Notes
+========================
+
+Fixes since v1.9.1
+------------------
+
+ * Documentation and in-code comments had many instances of mistaken
+ use of "nor", which have been corrected.
+
+ * "git fetch --prune", when the right-hand-side of multiple fetch
+ refspecs overlap (e.g. storing "refs/heads/*" to
+ "refs/remotes/origin/*", while storing "refs/frotz/*" to
+ "refs/remotes/origin/fr/*"), aggressively thought that lack of
+ "refs/heads/fr/otz" on the origin site meant we should remove
+ "refs/remotes/origin/fr/otz" from us, without checking their
+ "refs/frotz/otz" first.
+
+ Note that such a configuration is inherently unsafe (think what
+ should happen when "refs/heads/fr/otz" does appear on the origin
+ site), but that is not a reason not to be extra careful.
+
+ * "git update-ref --stdin" did not fail a request to create a ref
+ when the ref already existed.
+
+ * "git diff --no-index -Mq a b" fell into an infinite loop.
+
+ * When it is not necessary to edit a commit log message (e.g. "git
+ commit -m" is given a message without specifying "-e"), we used to
+ disable the spawning of the editor by overriding GIT_EDITOR, but
+ this means all the uses of the editor, other than to edit the
+ commit log message, are also affected.
+
+ * "git status --porcelain --branch" showed its output with labels
+ "ahead/behind/gone" translated to the user's locale.
+
+ * "git mv" that moves a submodule forgot to adjust the array that
+ uses to keep track of which submodules were to be moved to update
+ its configuration.
+
+ * Length limit for the pathname used when removing a path in a deep
+ subdirectory has been removed to avoid buffer overflows.
+
+ * The test helper lib-terminal always run an actual test_expect_*
+ when included, which screwed up with the use of skil-all that may
+ have to be done later.
+
+ * "git index-pack" used a wrong variable to name the keep-file in an
+ error message when the file cannot be written or closed.
+
+ * "rebase -i" produced a broken insn sheet when the title of a commit
+ happened to contain '\n' (or ended with '\c') due to a careless use
+ of 'echo'.
+
+ * There were a few instances of 'git-foo' remaining in the
+ documentation that should have been spelled 'git foo'.
+
+ * Serving objects from a shallow repository needs to write a
+ new file to hold the temporary shallow boundaries but it was not
+ cleaned when we exit due to die() or a signal.
+
+ * When "git stash pop" stops after failing to apply the stash
+ (e.g. due to conflicting changes), the stash is not dropped. State
+ that explicitly in the output to let the users know.
+
+ * The labels in "git status" output that describe the nature of
+ conflicts (e.g. "both deleted") were limited to 20 bytes, which was
+ too short for some l10n (e.g. fr).
diff --git a/RelNotes/1.9.3.adoc b/RelNotes/1.9.3.adoc
new file mode 100644
index 0000000..17b05ca
--- /dev/null
+++ b/RelNotes/1.9.3.adoc
@@ -0,0 +1,21 @@
+Git v1.9.3 Release Notes
+========================
+
+Fixes since v1.9.2
+------------------
+
+ * "git p4" dealing with changes in binary files were broken by a
+ change in 1.9 release.
+
+ * The shell prompt script (in contrib/), when using the PROMPT_COMMAND
+ interface, used an unsafe construct when showing the branch name in
+ $PS1.
+
+ * "git rebase" used a POSIX shell construct FreeBSD /bin/sh does not
+ work well with.
+
+ * Some more Unicode codepoints defined in Unicode 6.3 as having
+ zero width have been taught to our display column counting logic.
+
+ * Some tests used shell constructs that did not work well on
+ FreeBSD.
diff --git a/RelNotes/1.9.4.adoc b/RelNotes/1.9.4.adoc
new file mode 100644
index 0000000..e1d1835
--- /dev/null
+++ b/RelNotes/1.9.4.adoc
@@ -0,0 +1,16 @@
+Git v1.9.4 Release Notes
+========================
+
+Fixes since v1.9.3
+------------------
+
+ * Commands that take pathspecs on the command line misbehaved when
+ the pathspec is given as an absolute pathname (which is a
+ practice not particularly encouraged) that points at a symbolic
+ link in the working tree.
+
+ * An earlier fix to the shell prompt script (in contrib/) for using
+ the PROMPT_COMMAND interface did not correctly check if the extra
+ code path needs to trigger, causing the branch name not to appear
+ when 'promptvars' option is disabled in bash or PROMPT_SUBST is
+ unset in zsh.
diff --git a/RelNotes/1.9.5.adoc b/RelNotes/1.9.5.adoc
new file mode 100644
index 0000000..8d6ac0c
--- /dev/null
+++ b/RelNotes/1.9.5.adoc
@@ -0,0 +1,34 @@
+Git v1.9.5 Release Notes
+========================
+
+Fixes since v1.9.4
+------------------
+
+ * We used to allow committing a path ".Git/config" with Git that is
+ running on a case sensitive filesystem, but an attempt to check out
+ such a path with Git that runs on a case insensitive filesystem
+ would have clobbered ".git/config", which is definitely not what
+ the user would have expected. Git now prevents you from tracking
+ a path with ".Git" (in any case combination) as a path component.
+
+ * On Windows, certain path components that are different from ".git"
+ are mapped to ".git", e.g. "git~1/config" is treated as if it were
+ ".git/config". HFS+ has a similar issue, where certain unicode
+ codepoints are ignored, e.g. ".g\u200cit/config" is treated as if
+ it were ".git/config". Pathnames with these potential issues are
+ rejected on the affected systems. Git on systems that are not
+ affected by this issue (e.g. Linux) can also be configured to
+ reject them to ensure cross platform interoperability of the hosted
+ projects.
+
+ * "git fsck" notices a tree object that records such a path that can
+ be confused with ".git", and with receive.fsckObjects configuration
+ set to true, an attempt to "git push" such a tree object will be
+ rejected. Such a path may not be a problem on a well behaving
+ filesystem but in order to protect those on HFS+ and on case
+ insensitive filesystems, this check is enabled on all platforms.
+
+A big "thanks!" for bringing this issue to us goes to our friends in
+the Mercurial land, namely, Matt Mackall and Augie Fackler.
+
+Also contains typofixes, documentation updates and trivial code clean-ups.
diff --git a/RelNotes/2.0.0.adoc b/RelNotes/2.0.0.adoc
new file mode 100644
index 0000000..2617372
--- /dev/null
+++ b/RelNotes/2.0.0.adoc
@@ -0,0 +1,364 @@
+Git v2.0 Release Notes
+======================
+
+Backward compatibility notes
+----------------------------
+
+When "git push [$there]" does not say what to push, we have used the
+traditional "matching" semantics so far (all your branches were sent
+to the remote as long as there already are branches of the same name
+over there). In Git 2.0, the default is now the "simple" semantics,
+which pushes:
+
+ - only the current branch to the branch with the same name, and only
+ when the current branch is set to integrate with that remote
+ branch, if you are pushing to the same remote as you fetch from; or
+
+ - only the current branch to the branch with the same name, if you
+ are pushing to a remote that is not where you usually fetch from.
+
+You can use the configuration variable "push.default" to change
+this. If you are an old-timer who wants to keep using the
+"matching" semantics, you can set the variable to "matching", for
+example. Read the documentation for other possibilities.
+
+When "git add -u" and "git add -A" are run inside a subdirectory
+without specifying which paths to add on the command line, they
+operate on the entire tree for consistency with "git commit -a" and
+other commands (these commands used to operate only on the current
+subdirectory). Say "git add -u ." or "git add -A ." if you want to
+limit the operation to the current directory.
+
+"git add <path>" is the same as "git add -A <path>" now, so that
+"git add dir/" will notice paths you removed from the directory and
+record the removal. In older versions of Git, "git add <path>" used
+to ignore removals. You can say "git add --ignore-removal <path>" to
+add only added or modified paths in <path>, if you really want to.
+
+The "-q" option to "git diff-files", which does *NOT* mean "quiet",
+has been removed (it told Git to ignore deletion, which you can do
+with "git diff-files --diff-filter=d").
+
+"git request-pull" lost a few "heuristics" that often led to mistakes.
+
+The default prefix for "git svn" has changed in Git 2.0. For a long
+time, "git svn" created its remote-tracking branches directly under
+refs/remotes, but it now places them under refs/remotes/origin/ unless
+it is told otherwise with its "--prefix" option.
+
+
+Updates since v1.9 series
+-------------------------
+
+UI, Workflows & Features
+
+ * The "multi-mail" post-receive hook (in contrib/) has been updated
+ to a more recent version from upstream.
+
+ * The "remote-hg/bzr" remote-helper interfaces (used to be in
+ contrib/) are no more. They are now maintained separately as
+ third-party plug-ins in their own repositories.
+
+ * "git gc --aggressive" learned "--depth" option and
+ "gc.aggressiveDepth" configuration variable to allow use of a less
+ insane depth than the built-in default value of 250.
+
+ * "git log" learned the "--show-linear-break" option to show where a
+ single strand-of-pearls is broken in its output.
+
+ * The "rev-parse --parseopt" mechanism used by scripted Porcelains to
+ parse command-line options and to give help text learned to take
+ the argv-help (the placeholder string for an option parameter,
+ e.g. "key-id" in "--gpg-sign=<key-id>").
+
+ * The pattern to find where the function begins in C/C++ used in
+ "diff" and "grep -p" has been updated to improve viewing C++
+ sources.
+
+ * "git rebase" learned to interpret a lone "-" as "@{-1}", the
+ branch that we were previously on.
+
+ * "git commit --cleanup=<mode>" learned a new mode, scissors.
+
+ * "git tag --list" output can be sorted using "version sort" with
+ "--sort=version:refname".
+
+ * Discard the accumulated "heuristics" to guess from which branch the
+ result wants to be pulled from and make sure that what the end user
+ specified is not second-guessed by "git request-pull", to avoid
+ mistakes. When you pushed out your 'master' branch to your public
+ repository as 'for-linus', use the new "master:for-linus" syntax to
+ denote the branch to be pulled.
+
+ * "git grep" learned to behave in a way similar to native grep when
+ "-h" (no header) and "-c" (count) options are given.
+
+ * "git push" via transport-helper interface has been updated to
+ allow forced ref updates in a way similar to the natively
+ supported transports.
+
+ * The "simple" mode is the default for "git push".
+
+ * "git add -u" and "git add -A", when run without any pathspec, is a
+ tree-wide operation even when run inside a subdirectory of a
+ working tree.
+
+ * "git add <path>" is the same as "git add -A <path>" now.
+
+ * "core.statinfo" configuration variable, which is a
+ never-advertised synonym to "core.checkstat", has been removed.
+
+ * The "-q" option to "git diff-files", which does *NOT* mean
+ "quiet", has been removed (it told Git to ignore deletion, which
+ you can do with "git diff-files --diff-filter=d").
+
+ * Server operators can loosen the "tips of refs only" restriction for
+ the remote archive service with the uploadarchive.allowUnreachable
+ configuration option.
+
+ * The progress indicators from various time-consuming commands have
+ been marked for i18n/l10n.
+
+ * "git notes -C <blob>" diagnoses as an error an attempt to use an
+ object that is not a blob.
+
+ * "git config" learned to read from the standard input when "-" is
+ given as the value to its "--file" parameter (attempting an
+ operation to update the configuration in the standard input is
+ rejected, of course).
+
+ * Trailing whitespaces in .gitignore files, unless they are quoted
+ for fnmatch(3), e.g. "path\ ", are warned and ignored. Strictly
+ speaking, this is a backward-incompatible change, but very unlikely
+ to bite any sane user and adjusting should be obvious and easy.
+
+ * Many commands that create commits, e.g. "pull" and "rebase",
+ learned to take the "--gpg-sign" option on the command line.
+
+ * "git commit" can be told to always GPG sign the resulting commit
+ by setting the "commit.gpgsign" configuration variable to "true"
+ (the command-line option "--no-gpg-sign" should override it).
+
+ * "git pull" can be told to only accept fast-forward by setting the
+ new "pull.ff" configuration variable.
+
+ * "git reset" learned the "-N" option, which does not reset the index
+ fully for paths the index knows about but the tree-ish the command
+ resets to does not (these paths are kept as intend-to-add entries).
+
+
+Performance, Internal Implementation, etc.
+
+ * The compilation options to port to AIX and to MSVC have been
+ updated.
+
+ * We started using wildmatch() in place of fnmatch(3) a few releases
+ ago; complete the process and stop using fnmatch(3).
+
+ * Uses of curl's "multi" interface and "easy" interface do not mix
+ well when we attempt to reuse outgoing connections. Teach the RPC
+ over HTTP code, used in the smart HTTP transport, not to use the
+ "easy" interface.
+
+ * The bitmap-index feature from JGit has been ported, which should
+ significantly improve performance when serving objects from a
+ repository that uses it.
+
+ * The way "git log --cc" shows a combined diff against multiple
+ parents has been optimized.
+
+ * The prefixcmp() and suffixcmp() functions are gone. Use
+ starts_with() and ends_with(), and also consider if skip_prefix()
+ suits your needs better when using the former.
+
+
+Also contains various documentation updates and code clean-ups. Many
+of them came from flurry of activities as GSoC candidate microproject
+exercises.
+
+
+Fixes since v1.9 series
+-----------------------
+
+Unless otherwise noted, all the fixes since v1.9 in the maintenance
+track are contained in this release (see the maintenance releases'
+notes for details).
+
+ * "git p4" was broken in 1.9 release to deal with changes in binary
+ files.
+ (merge 749b668 cl/p4-use-diff-tree later to maint).
+
+ * The shell prompt script (in contrib/), when using the PROMPT_COMMAND
+ interface, used an unsafe construct when showing the branch name in
+ $PS1.
+ (merge 1e4119c8 rh/prompt-pcmode-avoid-eval-on-refname later to maint).
+
+ * "git rebase" used a POSIX shell construct FreeBSD's /bin/sh does not
+ work well with.
+ (merge 8cd6596 km/avoid-non-function-return-in-rebase later to maint).
+
+ * zsh prompt (in contrib/) leaked unnecessary error messages.
+
+ * Bash completion (in contrib/) did not complete the refs and remotes
+ correctly given "git pu<TAB>" when "pu" is aliased to "push".
+
+ * Some more Unicode code points, defined in Unicode 6.3 as having zero
+ width, have been taught to our display column counting logic.
+ (merge d813ab9 tb/unicode-6.3-zero-width later to maint).
+
+ * Some tests used shell constructs that did not work well on FreeBSD
+ (merge ff7a1c6 km/avoid-bs-in-shell-glob later to maint).
+ (merge 00764ca km/avoid-cp-a later to maint).
+
+ * "git update-ref --stdin" did not fail a request to create a ref
+ when the ref already existed.
+ (merge b9d56b5 mh/update-ref-batch-create-fix later to maint).
+
+ * "git diff --no-index -Mq a b" fell into an infinite loop.
+ (merge ad1c3fb jc/fix-diff-no-index-diff-opt-parse later to maint).
+
+ * "git fetch --prune", when the right-hand side of multiple fetch
+ refspecs overlap (e.g. storing "refs/heads/*" to
+ "refs/remotes/origin/*", while storing "refs/frotz/*" to
+ "refs/remotes/origin/fr/*"), aggressively thought that lack of
+ "refs/heads/fr/otz" on the origin site meant we should remove
+ "refs/remotes/origin/fr/otz" from us, without checking their
+ "refs/frotz/otz" first.
+
+ Note that such a configuration is inherently unsafe (think what
+ should happen when "refs/heads/fr/otz" does appear on the origin
+ site), but that is not a reason not to be extra careful.
+ (merge e6f6371 cn/fetch-prune-overlapping-destination later to maint).
+
+ * "git status --porcelain --branch" showed its output with labels
+ "ahead/behind/gone" translated to the user's locale.
+ (merge 7a76c28 mm/status-porcelain-format-i18n-fix later to maint).
+
+ * A stray environment variable $prefix could have leaked into and
+ affected the behaviour of the "subtree" script (in contrib/).
+
+ * When it is not necessary to edit a commit log message (e.g. "git
+ commit -m" is given a message without specifying "-e"), we used to
+ disable the spawning of the editor by overriding GIT_EDITOR, but
+ this means all the uses of the editor, other than to edit the
+ commit log message, are also affected.
+ (merge b549be0 bp/commit-p-editor later to maint).
+
+ * "git mv" that moves a submodule forgot to adjust the array that
+ uses to keep track of which submodules were to be moved to update
+ its configuration.
+ (merge fb8a4e8 jk/mv-submodules-fix later to maint).
+
+ * Length limit for the pathname used when removing a path in a deep
+ subdirectory has been removed to avoid buffer overflows.
+ (merge 2f29e0c mh/remove-subtree-long-pathname-fix later to maint).
+
+ * The test helper lib-terminal always run an actual test_expect_*
+ when included, which screwed up with the use of skil-all that may
+ have to be done later.
+ (merge 7e27173 jk/lib-terminal-lazy later to maint).
+
+ * "git index-pack" used a wrong variable to name the keep-file in an
+ error message when the file cannot be written or closed.
+ (merge de983a0 nd/index-pack-error-message later to maint).
+
+ * "rebase -i" produced a broken insn sheet when the title of a commit
+ happened to contain '\n' (or ended with '\c') due to a careless use
+ of 'echo'.
+ (merge cb1aefd us/printf-not-echo later to maint).
+
+ * There were a few instances of 'git-foo' remaining in the
+ documentation that should have been spelled 'git foo'.
+ (merge 3c3e6f5 rr/doc-merge-strategies later to maint).
+
+ * Serving objects from a shallow repository needs to write a
+ new file to hold the temporary shallow boundaries, but it was not
+ cleaned when we exit due to die() or a signal.
+ (merge 7839632 jk/shallow-update-fix later to maint).
+
+ * When "git stash pop" stops after failing to apply the stash
+ (e.g. due to conflicting changes), the stash is not dropped. State
+ that explicitly in the output to let the users know.
+ (merge 2d4c993 jc/stash-pop-not-popped later to maint).
+
+ * The labels in "git status" output that describe the nature of
+ conflicts (e.g. "both deleted") were limited to 20 bytes, which was
+ too short for some l10n (e.g. fr).
+ (merge c7cb333 jn/wt-status later to maint).
+
+ * "git clean -d pathspec" did not use the given pathspec correctly
+ and ended up cleaning too much.
+ (merge 1f2e108 jk/clean-d-pathspec later to maint).
+
+ * "git difftool" misbehaved when the repository is bound to the
+ working tree with the ".git file" mechanism, where a textual file
+ ".git" tells us where it is.
+ (merge fcfec8b da/difftool-git-files later to maint).
+
+ * "git push" did not pay attention to "branch.*.pushremote" if it is
+ defined earlier than "remote.pushdefault"; the order of these two
+ variables in the configuration file should not matter, but it did
+ by mistake.
+ (merge 98b406f jk/remote-pushremote-config-reading later to maint).
+
+ * Code paths that parse timestamps in commit objects have been
+ tightened.
+ (merge f80d1f9 jk/commit-dates-parsing-fix later to maint).
+
+ * "git diff --external-diff" incorrectly fed the submodule directory
+ in the working tree to the external diff driver when it knew that it
+ is the same as one of the versions being compared.
+ (merge aba4727 tr/diff-submodule-no-reuse-worktree later to maint).
+
+ * "git reset" needs to refresh the index when working in a working
+ tree (it can also be used to match the index to the HEAD in an
+ otherwise bare repository), but it failed to set up the working
+ tree properly, causing GIT_WORK_TREE to be ignored.
+ (merge b7756d4 nd/reset-setup-worktree later to maint).
+
+ * "git check-attr" when working on a repository with a working tree
+ did not work well when the working tree was specified via the
+ "--work-tree" (and obviously with "--git-dir") option.
+ (merge cdbf623 jc/check-attr-honor-working-tree later to maint).
+
+ * "merge-recursive" was broken in 1.7.7 era and stopped working in
+ an empty (temporary) working tree, when there are renames
+ involved. This has been corrected.
+ (merge 6e2068a bk/refresh-missing-ok-in-merge-recursive later to maint.)
+
+ * "git rev-parse" was loose in rejecting command-line arguments
+ that do not make sense, e.g. "--default" without the required
+ value for that option.
+ (merge a43219f ds/rev-parse-required-args later to maint.)
+
+ * "include.path" variable (or any variable that expects a path that
+ can use ~username expansion) in the configuration file is not a
+ boolean, but the code failed to check it.
+ (merge 67beb60 jk/config-path-include-fix later to maint.)
+
+ * Commands that take pathspecs on the command line misbehaved when
+ the pathspec is given as an absolute pathname (which is a
+ practice not particularly encouraged) that points at a symbolic
+ link in the working tree.
+ (merge 6127ff6 mw/symlinks later to maint.)
+
+ * "git diff --quiet -- pathspec1 pathspec2" sometimes did not return
+ the correct status value.
+ (merge f34b205 nd/diff-quiet-stat-dirty later to maint.)
+
+ * Attempting to deepen a shallow repository by fetching over smart
+ HTTP transport failed in the protocol exchange, when the no-done
+ extension was used. The fetching side waited for the list of
+ shallow boundary commits after the sending side stopped talking to
+ it.
+ (merge 0232852 nd/http-fetch-shallow-fix later to maint.)
+
+ * Allow "git cmd path/", when the 'path' is where a submodule is
+ bound to the top-level working tree, to match 'path', despite the
+ extra and unnecessary trailing slash (such a slash is often
+ given by command-line completion).
+ (merge 2e70c01 nd/submodule-pathspec-ending-with-slash later to maint.)
+
+ * Documentation and in-code comments had many instances of mistaken
+ use of "nor", which have been corrected.
+ (merge 235e8d5 jl/nor-or-nand-and later to maint).
diff --git a/RelNotes/2.0.1.adoc b/RelNotes/2.0.1.adoc
new file mode 100644
index 0000000..ce5579d
--- /dev/null
+++ b/RelNotes/2.0.1.adoc
@@ -0,0 +1,115 @@
+Git v2.0.1 Release Notes
+========================
+
+ * We used to unconditionally disable the pager in the pager process
+ we spawn to feed out output, but that prevented people who want to
+ run "less" within "less" from doing so.
+
+ * Tools that read diagnostic output in our standard error stream do
+ not want to see terminal control sequence (e.g. erase-to-eol).
+ Detect them by checking if the standard error stream is connected
+ to a tty.
+ * Reworded the error message given upon a failure to open an existing
+ loose object file due to e.g. permission issues; it was reported as
+ the object being corrupt, but that is not quite true.
+
+ * "git log -2master" is a common typo that shows two commits starting
+ from whichever random branch that is not 'master' that happens to
+ be checked out currently.
+
+ * The "%<(10,trunc)%s" pretty format specifier in the log family of
+ commands is used to truncate the string to a given length (e.g. 10
+ in the example) with padding to column-align the output, but did
+ not take into account that number of bytes and number of display
+ columns are different.
+
+ * The "mailmap.file" configuration option did not support the tilde
+ expansion (i.e. ~user/path and ~/path).
+
+ * The completion scripts (in contrib/) did not know about quite a few
+ options that are common between "git merge" and "git pull", and a
+ couple of options unique to "git merge".
+
+ * "--ignore-space-change" option of "git apply" ignored the spaces
+ at the beginning of line too aggressively, which is inconsistent
+ with the option of the same name "diff" and "git diff" have.
+
+ * "git blame" miscounted number of columns needed to show localized
+ timestamps, resulting in jaggy left-side-edge of the source code
+ lines in its output.
+
+ * "git blame" assigned the blame to the copy in the working-tree if
+ the repository is set to core.autocrlf=input and the file used CRLF
+ line endings.
+
+ * "git commit --allow-empty-message -C $commit" did not work when the
+ commit did not have any log message.
+
+ * "git diff --find-copies-harder" sometimes pretended as if the mode
+ bits have changed for paths that are marked with assume-unchanged
+ bit.
+
+ * "git format-patch" did not enforce the rule that the "--follow"
+ option from the log/diff family of commands must be used with
+ exactly one pathspec.
+
+ * "git gc --auto" was recently changed to run in the background to
+ give control back early to the end-user sitting in front of the
+ terminal, but it forgot that housekeeping involving reflogs should
+ be done without other processes competing for accesses to the refs.
+
+ * "git grep -O" to show the lines that hit in the pager did not work
+ well with case insensitive search. We now spawn "less" with its
+ "-I" option when it is used as the pager (which is the default).
+
+ * We used to disable threaded "git index-pack" on platforms without
+ thread-safe pread(); use a different workaround for such
+ platforms to allow threaded "git index-pack".
+
+ * The error reporting from "git index-pack" has been improved to
+ distinguish missing objects from type errors.
+
+ * "git mailinfo" used to read beyond the end of header string while
+ parsing an incoming e-mail message to extract the patch.
+
+ * On a case insensitive filesystem, merge-recursive incorrectly
+ deleted the file that is to be renamed to a name that is the same
+ except for case differences.
+
+ * "git pack-objects" unnecessarily copied the previous contents when
+ extending the hashtable, even though it will populate the table
+ from scratch anyway.
+
+ * "git rerere forget" did not work well when merge.conflictstyle
+ was set to a non-default value.
+
+ * "git remote rm" and "git remote prune" can involve removing many
+ refs at once, which is not a very efficient thing to do when very
+ many refs exist in the packed-refs file.
+
+ * "git log --exclude=<glob> --all | git shortlog" worked as expected,
+ but "git shortlog --exclude=<glob> --all", which is supposed to be
+ identical to the above pipeline, was not accepted at the command
+ line argument parser level.
+
+ * The autostash mode of "git rebase -i" did not restore the dirty
+ working tree state if the user aborted the interactive rebase by
+ emptying the insn sheet.
+
+ * "git show -s" (i.e. show log message only) used to incorrectly emit
+ an extra blank line after a merge commit.
+
+ * "git status", even though it is a read-only operation, tries to
+ update the index with refreshed lstat(2) info to optimize future
+ accesses to the working tree opportunistically, but this could
+ race with a "read-write" operation that modify the index while it
+ is running. Detect such a race and avoid overwriting the index.
+
+ * "git status" (and "git commit") behaved as if changes in a modified
+ submodule are not there if submodule.*.ignore configuration is set,
+ which was misleading. The configuration is only to unclutter diff
+ output during the course of development, and should not to hide
+ changes in the "status" output to cause the users forget to commit
+ them.
+
+ * The mode to run tests with HTTP server tests disabled was broken.
diff --git a/RelNotes/2.0.2.adoc b/RelNotes/2.0.2.adoc
new file mode 100644
index 0000000..8e8321b
--- /dev/null
+++ b/RelNotes/2.0.2.adoc
@@ -0,0 +1,32 @@
+Git v2.0.2 Release Notes
+========================
+
+ * Documentation for "git submodule sync" forgot to say that the subcommand
+ can take the "--recursive" option.
+
+ * Mishandling of patterns in .gitignore that has trailing SPs quoted
+ with backslashes (e.g. ones that end with "\ ") have been
+ corrected.
+
+ * Recent updates to "git repack" started to duplicate objects that
+ are in packfiles marked with .keep flag into the new packfile by
+ mistake.
+
+ * "git clone -b brefs/tags/bar" would have mistakenly thought we were
+ following a single tag, even though it was a name of the branch,
+ because it incorrectly used strstr().
+
+ * "%G" (nothing after G) is an invalid pretty format specifier, but
+ the parser did not notice it as garbage.
+
+ * Code to avoid adding the same alternate object store twice was
+ subtly broken for a long time, but nobody seems to have noticed.
+
+ * A handful of code paths had to read the commit object more than
+ once when showing header fields that are usually not parsed. The
+ internal data structure to keep track of the contents of the commit
+ object has been updated to reduce the need for this double-reading,
+ and to allow the caller find the length of the object.
+
+ * During "git rebase --merge", a conflicted patch could not be
+ skipped with "--skip" if the next one also conflicted.
diff --git a/RelNotes/2.0.3.adoc b/RelNotes/2.0.3.adoc
new file mode 100644
index 0000000..4047b46
--- /dev/null
+++ b/RelNotes/2.0.3.adoc
@@ -0,0 +1,17 @@
+Git v2.0.3 Release Notes
+========================
+
+ * An ancient rewrite passed a wrong pointer to a curl library
+ function in a rarely used code path.
+
+ * "filter-branch" left an empty single-parent commit that results when
+ all parents of a merge commit gets mapped to the same commit, even
+ under "--prune-empty".
+
+ * "log --show-signature" incorrectly decided the color to paint a
+ mergetag that was and was not correctly validated.
+
+ * "log --show-signature" did not pay attention to "--graph" option.
+
+Also a lot of fixes to the tests and some updates to the docs are
+included.
diff --git a/RelNotes/2.0.4.adoc b/RelNotes/2.0.4.adoc
new file mode 100644
index 0000000..7e34092
--- /dev/null
+++ b/RelNotes/2.0.4.adoc
@@ -0,0 +1,5 @@
+Git v2.0.4 Release Notes
+========================
+
+ * An earlier update to v2.0.2 broken output from "git diff-tree",
+ which is fixed in this release.
diff --git a/RelNotes/2.0.5.adoc b/RelNotes/2.0.5.adoc
new file mode 100644
index 0000000..3a16f69
--- /dev/null
+++ b/RelNotes/2.0.5.adoc
@@ -0,0 +1,34 @@
+Git v2.0.5 Release Notes
+========================
+
+Fixes since v2.0.4
+------------------
+
+ * We used to allow committing a path ".Git/config" with Git that is
+ running on a case sensitive filesystem, but an attempt to check out
+ such a path with Git that runs on a case insensitive filesystem
+ would have clobbered ".git/config", which is definitely not what
+ the user would have expected. Git now prevents you from tracking
+ a path with ".Git" (in any case combination) as a path component.
+
+ * On Windows, certain path components that are different from ".git"
+ are mapped to ".git", e.g. "git~1/config" is treated as if it were
+ ".git/config". HFS+ has a similar issue, where certain unicode
+ codepoints are ignored, e.g. ".g\u200cit/config" is treated as if
+ it were ".git/config". Pathnames with these potential issues are
+ rejected on the affected systems. Git on systems that are not
+ affected by this issue (e.g. Linux) can also be configured to
+ reject them to ensure cross platform interoperability of the hosted
+ projects.
+
+ * "git fsck" notices a tree object that records such a path that can
+ be confused with ".git", and with receive.fsckObjects configuration
+ set to true, an attempt to "git push" such a tree object will be
+ rejected. Such a path may not be a problem on a well behaving
+ filesystem but in order to protect those on HFS+ and on case
+ insensitive filesystems, this check is enabled on all platforms.
+
+A big "thanks!" for bringing this issue to us goes to our friends in
+the Mercurial land, namely, Matt Mackall and Augie Fackler.
+
+Also contains typofixes, documentation updates and trivial code clean-ups.
diff --git a/RelNotes/2.1.0.adoc b/RelNotes/2.1.0.adoc
new file mode 100644
index 0000000..ae47537
--- /dev/null
+++ b/RelNotes/2.1.0.adoc
@@ -0,0 +1,391 @@
+Git v2.1 Release Notes
+======================
+
+Backward compatibility notes
+----------------------------
+
+ * The default value we give to the environment variable LESS has been
+ changed from "FRSX" to "FRX", losing "S" (chop long lines instead
+ of wrapping). Existing users who prefer not to see line-wrapped
+ output may want to set
+
+ $ git config core.pager "less -S"
+
+ to restore the traditional behaviour. It is expected that people
+ find output from most subcommands easier to read with the new
+ default, except for "blame" which tends to produce really long
+ lines. To override the new default only for "git blame", you can
+ do this:
+
+ $ git config pager.blame "less -S"
+
+ * A few disused directories in contrib/ have been retired.
+
+
+Updates since v2.0
+------------------
+
+UI, Workflows & Features
+
+ * Since the very beginning of Git, we gave the LESS environment a
+ default value "FRSX" when we spawn "less" as the pager. "S" (chop
+ long lines instead of wrapping) has been removed from this default
+ set of options, because it is more or less a personal taste thing,
+ as opposed to the others that have good justifications (i.e. "R" is
+ very much justified because many kinds of output we produce are
+ colored and "FX" is justified because output we produce is often
+ shorter than a page).
+
+ * The logic and data used to compute the display width needed for
+ UTF-8 strings have been updated to match Unicode 7.0 better.
+
+ * HTTP-based transports learned to better propagate the error messages from
+ the webserver to the client coming over the HTTP transport.
+
+ * The completion script for bash (in contrib/) has been updated to
+ better handle aliases that define a complex sequence of commands.
+
+ * The "core.preloadindex" configuration variable is enabled by default,
+ allowing modern platforms to take advantage of their
+ multiple cores.
+
+ * "git clone" applies the "if cloning from a local disk, physically
+ copy the repository using hardlinks, unless otherwise told not to with
+ --no-local" optimization when the url.*.insteadOf mechanism rewrites a
+ remote-repository "git clone $URL" into a
+ clone from a local disk.
+
+ * "git commit --date=<date>" option learned more
+ timestamp formats, including "--date=now".
+
+ * The `core.commentChar` configuration variable is used to specify a
+ custom comment character (other than the default "#") for
+ the commit message editor. This can be set to `auto` to attempt to
+ choose a different character that does not conflict with any that
+ already starts a line in the message being edited, for cases like
+ "git commit --amend".
+
+ * "git format-patch" learned --signature-file=<file> to add the contents
+ of a file as a signature to the mail message it produces.
+
+ * "git grep" learned the grep.fullname configuration variable to force
+ "--full-name" to be the default. This may cause regressions for
+ scripted users who do not expect this new behaviour.
+
+ * "git imap-send" learned to ask the credential helper for auth
+ material.
+
+ * "git log" and friends now understand the value "auto" for the
+ "log.decorate" configuration variable to enable the "--decorate"
+ option automatically when the output is sent to tty.
+
+ * "git merge" without an argument, even when there is an upstream
+ defined for the current branch, refused to run until
+ merge.defaultToUpstream is set to true. Flip the default of that
+ configuration variable to true.
+
+ * "git mergetool" learned to drive the vimdiff3 backend.
+
+ * mergetool.prompt used to default to 'true', always asking "do you
+ really want to run the tool on this path?". The default has been
+ changed to 'false'. However, the prompt will still appear if
+ mergetool used its autodetection system to guess which tool to use.
+ Users who explicitly specify or configure a tool will no longer see
+ the prompt by default.
+
+ Strictly speaking, this is a backward incompatible change and
+ users need to explicitly set the variable to 'true' if they want
+ to be prompted to confirm running the tool on each path.
+
+ * "git replace" learned the "--edit" subcommand to create a
+ replacement by editing an existing object.
+
+ * "git replace" learned a "--graft" option to rewrite the parents of a
+ commit.
+
+ * "git send-email" learned "--to-cover" and "--cc-cover" options, to
+ tell it to copy To: and Cc: headers found in the first input file
+ when emitting later input files.
+
+ * "git svn" learned to cope with malformed timestamps with only one
+ digit in the hour part, e.g. 2014-01-07T5:01:02.048176Z, emitted
+ by some broken subversion server implementations.
+
+ * "git tag" when editing the tag message shows the name of the tag
+ being edited as a comment in the editor.
+
+ * "git tag" learned to pay attention to "tag.sort" configuration, to
+ be used as the default sort order when no --sort=<value> option
+ is given.
+
+ * A new "git verify-commit" command, to check GPG signatures in signed
+ commits, in a way similar to "git verify-tag" is used to check
+ signed tags, was added.
+
+
+Performance, Internal Implementation, etc.
+
+ * Build procedure for 'subtree' (in contrib/) has been cleaned up.
+
+ * Support for the profile-feedback build, which has
+ bit-rotted for quite a while, has been updated.
+
+ * An experimental format to use two files (the base file and
+ incremental changes relative to it) to represent the index has been
+ introduced; this may reduce I/O cost of rewriting a large index
+ when only small part of the working tree changes.
+
+ * Effort to shrink the size of patches Windows folks maintain on top
+ by upstreaming them continues. More tests that are not applicable
+ to the Windows environment are identified and either skipped or
+ made more portable.
+
+ * Eradication of "test $condition -a $condition" from our scripts
+ continues.
+
+ * The `core.deltabasecachelimit` used to default to 16 MiB , but this
+ proved to be too small, and has been bumped to 96 MiB.
+
+ * "git blame" has been optimized greatly by reorganising the data
+ structure that is used to keep track of the work to be done.
+
+ * "git diff" that compares 3-or-more trees (e.g. parents and the
+ result of a merge) has been optimized.
+
+ * The API to update/delete references are being converted to handle
+ updates to multiple references in a transactional way. As an
+ example, "update-ref --stdin [-z]" has been updated to use this
+ API.
+
+ * skip_prefix() and strip_suffix() API functions are used a lot more
+ widely throughout the codebase now.
+
+ * Parts of the test scripts can be skipped by using a range notation,
+ e.g. "sh t1234-test.sh --run='1-4 6 8-'" to omit test piece 5 and 7
+ and run everything else.
+
+
+Also contains various documentation updates and code clean-ups.
+
+
+Fixes since v2.0
+----------------
+
+Unless otherwise noted, all the fixes since v2.0 in the maintenance
+track are contained in this release (see the maintenance releases'
+notes for details).
+
+ * We used to unconditionally disable the pager in the pager process
+ we spawn to feed out output, but that prevented people who want to
+ run "less" within "less" from doing so.
+ (merge c0459ca je/pager-do-not-recurse later to maint).
+
+ * Tools that read diagnostic output in our standard error stream do
+ not want to see terminal control sequence (e.g. erase-to-eol).
+ Detect them by checking if the standard error stream is connected
+ to a tty.
+ (merge 38de156 mn/sideband-no-ansi later to maint).
+
+ * Mishandling of patterns in .gitignore that have trailing SPs quoted
+ with backslashes (e.g. ones that end with "\ ") has been
+ corrected.
+ (merge 97c1364be6b pb/trim-trailing-spaces later to maint).
+
+ * Reworded the error message given upon a failure to open an existing
+ loose object file due to e.g. permission issues; it was reported as
+ the object being corrupt, but that is not quite true.
+ (merge d6c8a05 jk/report-fail-to-read-objects-better later to maint).
+
+ * "git log -2master" is a common typo that shows two commits starting
+ from whichever random branch that is not 'master' that happens to
+ be checked out currently.
+ (merge e3fa568 jc/revision-dash-count-parsing later to maint).
+
+ * Code to avoid adding the same alternate object store twice was
+ subtly broken for a long time, but nobody seems to have noticed.
+ (merge 80b4785 rs/fix-alt-odb-path-comparison later to maint).
+ (merge 539e750 ek/alt-odb-entry-fix later to maint).
+
+ * The "%<(10,trunc)%s" pretty format specifier in the log family of
+ commands is used to truncate the string to a given length (e.g. 10
+ in the example) with padding to column-align the output, but did
+ not take into account that number of bytes and number of display
+ columns are different.
+ (merge 7d50987 as/pretty-truncate later to maint).
+
+ * "%G" (nothing after G) is an invalid pretty format specifier, but
+ the parser did not notice it as garbage.
+ (merge 958b2eb jk/pretty-G-format-fixes later to maint).
+
+ * A handful of code paths had to read the commit object more than
+ once when showing header fields that are usually not parsed. The
+ internal data structure to keep track of the contents of the commit
+ object has been updated to reduce the need for this double-reading,
+ and to allow the caller find the length of the object.
+ (merge 218aa3a jk/commit-buffer-length later to maint).
+
+ * The "mailmap.file" configuration option did not support tilde
+ expansion (i.e. ~user/path and ~/path).
+ (merge 9352fd5 ow/config-mailmap-pathname later to maint).
+
+ * The completion scripts (in contrib/) did not know about quite a few
+ options that are common between "git merge" and "git pull", and a
+ couple of options unique to "git merge".
+ (merge 8fee872 jk/complete-merge-pull later to maint).
+
+ * The unix-domain socket used by the sample credential cache daemon
+ tried to unlink an existing stale one at a wrong path, if the path
+ to the socket was given as an overlong path that does not fit in
+ the sun_path member of the sockaddr_un structure.
+ (merge 2869b3e rs/fix-unlink-unix-socket later to maint).
+
+ * An ancient rewrite passed a wrong pointer to a curl library
+ function in a rarely used code path.
+ (merge 479eaa8 ah/fix-http-push later to maint).
+
+ * "--ignore-space-change" option of "git apply" ignored the spaces
+ at the beginning of lines too aggressively, which is inconsistent
+ with the option of the same name that "diff" and "git diff" have.
+ (merge 14d3bb4 jc/apply-ignore-whitespace later to maint).
+
+ * "git blame" miscounted the number of columns needed to show localized
+ timestamps, resulting in a jaggy left-side-edge for the source code
+ lines in its output.
+ (merge dd75553 jx/blame-align-relative-time later to maint).
+
+ * "git blame" assigned the blame to the copy in the working-tree if
+ the repository is set to core.autocrlf=input and the file used CRLF
+ line endings.
+ (merge 4d4813a bc/blame-crlf-test later to maint).
+
+ * "git clone -b brefs/tags/bar" would have mistakenly thought we were
+ following a single tag, even though it was a name of the branch,
+ because it incorrectly used strstr().
+ (merge 60a5f5f jc/fix-clone-single-starting-at-a-tag later to maint).
+
+ * "git commit --allow-empty-message -C $commit" did not work when the
+ commit did not have any log message.
+ (merge 076cbd6 jk/commit-C-pick-empty later to maint).
+
+ * "git diff --find-copies-harder" sometimes pretended as if the mode
+ bits have changed for paths that are marked with the assume-unchanged
+ bit.
+ (merge 5304810 jk/diff-files-assume-unchanged later to maint).
+
+ * "filter-branch" left an empty single-parent commit that results when
+ all parents of a merge commit get mapped to the same commit, even
+ under "--prune-empty".
+ (merge 79bc4ef cb/filter-branch-prune-empty-degenerate-merges later to maint).
+
+ * "git format-patch" did not enforce the rule that the "--follow"
+ option from the log/diff family of commands must be used with
+ exactly one pathspec.
+ (merge dd63f16 jk/diff-follow-must-take-one-pathspec later to maint).
+
+ * "git gc --auto" was recently changed to run in the background to
+ give control back early to the end-user sitting in front of the
+ terminal, but it forgot that housekeeping involving reflogs should
+ be done without other processes competing for accesses to the refs.
+ (merge 62aad18 nd/daemonize-gc later to maint).
+
+ * "git grep -O" to show the lines that hit in the pager did not work
+ well with case insensitive search. We now spawn "less" with its
+ "-I" option when it is used as the pager (which is the default).
+ (merge f7febbe sk/spawn-less-case-insensitively-from-grep-O-i later to maint).
+
+ * We used to disable threaded "git index-pack" on platforms without
+ thread-safe pread(); use a different workaround for such
+ platforms to allow threaded "git index-pack".
+ (merge 3953949 nd/index-pack-one-fd-per-thread later to maint).
+
+ * The error reporting from "git index-pack" has been improved to
+ distinguish missing objects from type errors.
+ (merge 77583e7 jk/index-pack-report-missing later to maint).
+
+ * "log --show-signature" incorrectly decided the color to paint a
+ mergetag that was and was not correctly validated.
+ (merge 42c55ce mg/fix-log-mergetag-color later to maint).
+
+ * "log --show-signature" did not pay attention to the "--graph" option.
+ (merge cf3983d zk/log-graph-showsig later to maint).
+
+ * "git mailinfo" used to read beyond the ends of header strings while
+ parsing an incoming e-mail message to extract the patch.
+ (merge b1a013d rs/mailinfo-header-cmp later to maint).
+
+ * On a case insensitive filesystem, merge-recursive incorrectly
+ deleted the file that is to be renamed to a name that is the same
+ except for case differences.
+ (merge baa37bf dt/merge-recursive-case-insensitive later to maint).
+
+ * Merging changes into a file that ends in an incomplete line made the
+ last line into a complete one, even when the other branch did not
+ change anything around the end of file.
+ (merge ba31180 mk/merge-incomplete-files later to maint).
+
+ * "git pack-objects" unnecessarily copied the previous contents when
+ extending the hashtable, even though it will populate the table
+ from scratch anyway.
+ (merge fb79947 rs/pack-objects-no-unnecessary-realloc later to maint).
+
+ * Recent updates to "git repack" started to duplicate objects that
+ are in packfiles marked with the .keep flag into the new packfile by
+ mistake.
+ (merge d078d85 jk/repack-pack-keep-objects later to maint).
+
+ * "git rerere forget" did not work well when merge.conflictstyle
+ was set to a non-default value.
+ (merge de3d8bb fc/rerere-conflict-style later to maint).
+
+ * "git remote rm" and "git remote prune" can involve removing many
+ refs at once, which is not a very efficient thing to do when very
+ many refs exist in the packed-refs file.
+ (merge e6bea66 jl/remote-rm-prune later to maint).
+
+ * "git log --exclude=<glob> --all | git shortlog" worked as expected,
+ but "git shortlog --exclude=<glob> --all", which is supposed to be
+ identical to the above pipeline, was not accepted at the command
+ line argument parser level.
+ (merge eb07774 jc/shortlog-ref-exclude later to maint).
+
+ * The autostash mode of "git rebase -i" did not restore the dirty
+ working tree state if the user aborted the interactive rebase by
+ emptying the insn sheet.
+ (merge ddb5432 rr/rebase-autostash-fix later to maint).
+
+ * "git rebase --fork-point" did not filter out patch-identical
+ commits correctly.
+
+ * During "git rebase --merge", a conflicted patch could not be
+ skipped with "--skip" if the next one also conflicted.
+ (merge 95104c7 bc/fix-rebase-merge-skip later to maint).
+
+ * "git show -s" (i.e. show log message only) used to incorrectly emit
+ an extra blank line after a merge commit.
+ (merge ad2f725 mk/show-s-no-extra-blank-line-for-merges later to maint).
+
+ * "git status", even though it is a read-only operation, tries to
+ update the index with refreshed lstat(2) info to optimize future
+ accesses to the working tree opportunistically, but this could
+ race with a "read-write" operation that modifies the index while it
+ is running. Detect such a race and avoid overwriting the index.
+ (merge 426ddee ym/fix-opportunistic-index-update-race later to maint).
+
+ * "git status" (and "git commit") behaved as if changes in a modified
+ submodule are not there if submodule.*.ignore configuration is set,
+ which was misleading. The configuration is only to unclutter diff
+ output during the course of development, and not to hide
+ changes in the "status" output to cause the users forget to commit
+ them.
+ (merge c215d3d jl/status-added-submodule-is-never-ignored later to maint).
+
+ * Documentation for "git submodule sync" forgot to say that the subcommand
+ can take the "--recursive" option.
+ (merge 9393ae7 mc/doc-submodule-sync-recurse later to maint).
+
+ * "git update-index --cacheinfo" in 2.0 release crashed on a
+ malformed command line.
+ (merge c8e1ee4 jc/rev-parse-argh-dashed-multi-words later to maint).
+
+ * The mode to run tests with HTTP server tests disabled was broken.
+ (merge afa53fe na/no-http-test-in-the-middle later to maint).
diff --git a/RelNotes/2.1.1.adoc b/RelNotes/2.1.1.adoc
new file mode 100644
index 0000000..830fc3c
--- /dev/null
+++ b/RelNotes/2.1.1.adoc
@@ -0,0 +1,44 @@
+Git v2.1.1 Release Notes
+========================
+
+ * Git 2.0 had a regression where "git fetch" into a shallowly
+ cloned repository from a repository with bitmap object index
+ enabled did not work correctly. This has been corrected.
+
+ * Git 2.0 had a regression which broke (rarely used) "git diff-tree
+ -t". This has been corrected.
+
+ * "git log --pretty/format=" with an empty format string did not
+ mean the more obvious "No output whatsoever" but "Use default
+ format", which was counterintuitive. Now it means "nothing shown
+ for the log message part".
+
+ * "git -c section.var command" and "git -c section.var= command"
+ should pass the configuration differently (the former should be a
+ boolean true, the latter should be an empty string), but they
+ didn't work that way. Now it does.
+
+ * Applying a patch not generated by Git in a subdirectory used to
+ check the whitespace breakage using the attributes for incorrect
+ paths. Also whitespace checks were performed even for paths
+ excluded via "git apply --exclude=<path>" mechanism.
+
+ * "git bundle create" with date-range specification were meant to
+ exclude tags outside the range, but it did not work correctly.
+
+ * "git add x" where x that used to be a directory has become a
+ symbolic link to a directory misbehaved.
+
+ * The prompt script checked $GIT_DIR/ref/stash file to see if there
+ is a stash, which was a no-no.
+
+ * "git checkout -m" did not switch to another branch while carrying
+ the local changes forward when a path was deleted from the index.
+
+ * With sufficiently long refnames, fast-import could have overflown
+ an on-stack buffer.
+
+ * After "pack-refs --prune" packed refs at the top-level, it failed
+ to prune them.
+
+ * "git gc --auto" triggered from "git fetch --quiet" was not quiet.
diff --git a/RelNotes/2.1.2.adoc b/RelNotes/2.1.2.adoc
new file mode 100644
index 0000000..abc3b89
--- /dev/null
+++ b/RelNotes/2.1.2.adoc
@@ -0,0 +1,20 @@
+Git v2.1.2 Release Notes
+========================
+
+ * "git push" over HTTP transport had an artificial limit on number of
+ refs that can be pushed imposed by the command line length.
+
+ * When receiving an invalid pack stream that records the same object
+ twice, multiple threads got confused due to a race.
+
+ * An attempt to remove the entire tree in the "git fast-import" input
+ stream caused it to misbehave.
+
+ * Reachability check (used in "git prune" and friends) did not add a
+ detached HEAD as a starting point to traverse objects still in use.
+
+ * "git config --add section.var val" used to lose existing
+ section.var whose value was an empty string.
+
+ * "git fsck" failed to report that it found corrupt objects via its
+ exit status in some cases.
diff --git a/RelNotes/2.1.3.adoc b/RelNotes/2.1.3.adoc
new file mode 100644
index 0000000..0dfb17c
--- /dev/null
+++ b/RelNotes/2.1.3.adoc
@@ -0,0 +1,26 @@
+Git v2.1.3 Release Notes
+========================
+
+ * Some MUAs mangled a line in a message that begins with "From " to
+ ">From " when writing to a mailbox file and feeding such an input to
+ "git am" used to lose such a line.
+
+ * "git daemon" (with NO_IPV6 build configuration) used to incorrectly
+ use the hostname even when gethostbyname() reported that the given
+ hostname is not found.
+
+ * Newer versions of 'meld' breaks the auto-detection we use to see if
+ they are new enough to support the `--output` option.
+
+ * "git pack-objects" forgot to disable the codepath to generate
+ object reachability bitmap when it needs to split the resulting
+ pack.
+
+ * "gitweb" used deprecated CGI::startfrom, which was removed from
+ CGI.pm as of 4.04; use CGI::start_from instead.
+
+ * "git log" documentation had an example section marked up not
+ quite correctly, which passed AsciiDoc but failed with
+ AsciiDoctor.
+
+Also contains some documentation updates.
diff --git a/RelNotes/2.1.4.adoc b/RelNotes/2.1.4.adoc
new file mode 100644
index 0000000..d16e5f0
--- /dev/null
+++ b/RelNotes/2.1.4.adoc
@@ -0,0 +1,34 @@
+Git v2.1.4 Release Notes
+========================
+
+Fixes since v2.1.3
+------------------
+
+ * We used to allow committing a path ".Git/config" with Git that is
+ running on a case sensitive filesystem, but an attempt to check out
+ such a path with Git that runs on a case insensitive filesystem
+ would have clobbered ".git/config", which is definitely not what
+ the user would have expected. Git now prevents you from tracking
+ a path with ".Git" (in any case combination) as a path component.
+
+ * On Windows, certain path components that are different from ".git"
+ are mapped to ".git", e.g. "git~1/config" is treated as if it were
+ ".git/config". HFS+ has a similar issue, where certain unicode
+ codepoints are ignored, e.g. ".g\u200cit/config" is treated as if
+ it were ".git/config". Pathnames with these potential issues are
+ rejected on the affected systems. Git on systems that are not
+ affected by this issue (e.g. Linux) can also be configured to
+ reject them to ensure cross platform interoperability of the hosted
+ projects.
+
+ * "git fsck" notices a tree object that records such a path that can
+ be confused with ".git", and with receive.fsckObjects configuration
+ set to true, an attempt to "git push" such a tree object will be
+ rejected. Such a path may not be a problem on a well behaving
+ filesystem but in order to protect those on HFS+ and on case
+ insensitive filesystems, this check is enabled on all platforms.
+
+A big "thanks!" for bringing this issue to us goes to our friends in
+the Mercurial land, namely, Matt Mackall and Augie Fackler.
+
+Also contains typofixes, documentation updates and trivial code clean-ups.
diff --git a/RelNotes/2.10.0.adoc b/RelNotes/2.10.0.adoc
new file mode 100644
index 0000000..3792b7d
--- /dev/null
+++ b/RelNotes/2.10.0.adoc
@@ -0,0 +1,675 @@
+Git 2.10 Release Notes
+======================
+
+Backward compatibility notes
+----------------------------
+
+Updates since v2.9
+------------------
+
+UI, Workflows & Features
+
+ * "git pull --rebase --verify-signature" learned to warn the user
+ that "--verify-signature" is a no-op when rebasing.
+
+ * An upstream project can make a recommendation to shallowly clone
+ some submodules in the .gitmodules file it ships.
+
+ * "git worktree add" learned that '-' can be used as a short-hand for
+ "@{-1}", the previous branch.
+
+ * Update the funcname definition to support css files.
+
+ * The completion script (in contrib/) learned to complete "git
+ status" options.
+
+ * Messages that are generated by auto gc during "git push" on the
+ receiving end are now passed back to the sending end in such a way
+ that they are shown with "remote: " prefix to avoid confusing the
+ users.
+
+ * "git add -i/-p" learned to honor diff.compactionHeuristic
+ experimental knob, so that the user can work on the same hunk split
+ as "git diff" output.
+
+ * "upload-pack" allows a custom "git pack-objects" replacement when
+ responding to "fetch/clone" via the uploadpack.packObjectsHook.
+ (merge b738396 jk/upload-pack-hook later to maint).
+
+ * Teach format-patch and mailsplit (hence "am") how a line that
+ happens to begin with "From " in the e-mail message is quoted with
+ ">", so that these lines can be restored to their original shape.
+ (merge d9925d1 ew/mboxrd-format-am later to maint).
+
+ * "git repack" learned the "--keep-unreachable" option, which sends
+ loose unreachable objects to a pack instead of leaving them loose.
+ This helps heuristics based on the number of loose objects
+ (e.g. "gc --auto").
+ (merge e26a8c4 jk/repack-keep-unreachable later to maint).
+
+ * "log --graph --format=" learned that "%>|(N)" specifies the width
+ relative to the terminal's left edge, not relative to the area to
+ draw text that is to the right of the ancestry-graph section. It
+ also now accepts negative N that means the column limit is relative
+ to the right border.
+
+ * A careless invocation of "git send-email directory/" after editing
+ 0001-change.patch with an editor often ends up sending both
+ 0001-change.patch and its backup file, 0001-change.patch~, causing
+ embarrassment and a minor confusion. Detect such an input and
+ offer to skip the backup files when sending the patches out.
+ (merge 531220b jc/send-email-skip-backup later to maint).
+
+ * "git submodule update" that drives many "git clone" could
+ eventually hit flaky servers/network conditions on one of the
+ submodules; the command learned to retry the attempt.
+
+ * The output coloring scheme learned two new attributes, italic and
+ strike, in addition to existing bold, reverse, etc.
+
+ * "git log" learns log.showSignature configuration variable, and a
+ command line option "--no-show-signature" to countermand it.
+ (merge fce04c3 mj/log-show-signature-conf later to maint).
+
+ * More markings of messages for i18n, with updates to various tests
+ to pass GETTEXT_POISON tests.
+
+ * "git archive" learned to handle files that are larger than 8GB and
+ commits far in the future than expressible by the traditional US-TAR
+ format.
+ (merge 560b0e8 jk/big-and-future-archive-tar later to maint).
+
+
+ * A new configuration variable core.sshCommand has been added to
+ specify what value for GIT_SSH_COMMAND to use per repository.
+
+ * "git worktree prune" protected worktrees that are marked as
+ "locked" by creating a file in a known location. "git worktree"
+ command learned a dedicated command pair to create and remove such
+ a file, so that the users do not have to do this with editor.
+
+ * A handful of "git svn" updates.
+
+ * "git push" learned to accept and pass extra options to the
+ receiving end so that hooks can read and react to them.
+
+ * "git status" learned to suggest "merge --abort" during a conflicted
+ merge, just like it already suggests "rebase --abort" during a
+ conflicted rebase.
+
+ * "git jump" script (in contrib/) has been updated a bit.
+ (merge a91e692 jk/git-jump later to maint).
+
+ * "git push" and "git clone" learned to give better progress meters
+ to the end user who is waiting on the terminal.
+
+ * An entry "git log --decorate" for the tip of the current branch is
+ shown as "HEAD -> name" (where "name" is the name of the branch);
+ the arrow is now painted in the same color as "HEAD", not in the
+ color for commits.
+
+ * "git format-patch" learned format.from configuration variable to
+ specify the default settings for its "--from" option.
+
+ * "git am -3" calls "git merge-recursive" when it needs to fall back
+ to a three-way merge; this call has been turned into an internal
+ subroutine call instead of spawning a separate subprocess.
+
+ * The command line completion scripts (in contrib/) now knows about
+ "git branch --delete/--move [--remote]".
+ (merge 2703c22 vs/completion-branch-fully-spelled-d-m-r later to maint).
+
+ * "git rev-parse --git-path hooks/<hook>" learned to take
+ core.hooksPath configuration variable (introduced during 2.9 cycle)
+ into account.
+ (merge 9445b49 ab/hooks later to maint).
+
+ * "git log --show-signature" and other commands that display the
+ verification status of PGP signature now shows the longer key-id,
+ as 32-bit key-id is so last century.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * "git fast-import" learned the same performance trick to avoid
+ creating too small a packfile as "git fetch" and "git push" have,
+ using *.unpackLimit configuration.
+
+ * When "git daemon" is run without --[init-]timeout specified, a
+ connection from a client that silently goes offline can hang around
+ for a long time, wasting resources. The socket-level KEEPALIVE has
+ been enabled to allow the OS to notice such failed connections.
+
+ * "git upload-pack" command has been updated to use the parse-options
+ API.
+
+ * The "git apply" standalone program is being libified; the first
+ step to move many state variables into a structure that can be
+ explicitly (re)initialized to make the machinery callable more
+ than once has been merged.
+
+ * HTTP transport gained an option to produce more detailed debugging
+ trace.
+ (merge 73e57aa ep/http-curl-trace later to maint).
+
+ * Instead of taking advantage of the fact that a struct string_list
+ that is allocated with all NULs happens to be the INIT_NODUP kind,
+ the users of string_list structures are taught to initialize them
+ explicitly as such, to document their behaviour better.
+ (merge 2721ce2 jk/string-list-static-init later to maint).
+
+ * HTTPd tests learned to show the server error log to help diagnosing
+ a failing tests.
+ (merge 44f243d nd/test-lib-httpd-show-error-log-in-verbose later to maint).
+
+ * The ownership rule for the piece of memory that hold references to
+ be fetched in "git fetch" was screwy, which has been cleaned up.
+
+ * "git bisect" makes an internal call to "git diff-tree" when
+ bisection finds the culprit, but this call did not initialize the
+ data structure to pass to the diff-tree API correctly.
+
+ * Further preparatory clean-up for "worktree" feature continues.
+ (merge 0409e0b nd/worktree-cleanup-post-head-protection later to maint).
+
+ * Formats of the various data (and how to validate them) where we use
+ GPG signature have been documented.
+
+ * A new run-command API function pipe_command() is introduced to
+ sanely feed data to the standard input while capturing data from
+ the standard output and the standard error of an external process,
+ which is cumbersome to hand-roll correctly without deadlocking.
+
+ * The codepath to sign data in a prepared buffer with GPG has been
+ updated to use this API to read from the status-fd to check for
+ errors (instead of relying on GPG's exit status).
+ (merge efee955 jk/gpg-interface-cleanup later to maint).
+
+ * Allow t/perf framework to use the features from the most recent
+ version of Git even when testing an older installed version.
+
+ * The commands in the "log/diff" family have had an FILE* pointer in the
+ data structure they pass around for a long time, but some codepaths
+ used to always write to the standard output. As a preparatory step
+ to make "git format-patch" available to the internal callers, these
+ codepaths have been updated to consistently write into that FILE*
+ instead.
+
+ * Conversion from unsigned char sha1[20] to struct object_id
+ continues.
+
+ * Improve the look of the way "git fetch" reports what happened to
+ each ref that was fetched.
+
+ * The .c/.h sources are marked as such in our .gitattributes file so
+ that "git diff -W" and friends would work better.
+
+ * Code clean-up to avoid using a variable string that compilers may
+ feel untrustable as printf-style format given to write_file()
+ helper function.
+
+ * "git p4" used a location outside $GIT_DIR/refs/ to place its
+ temporary branches, which has been moved to refs/git-p4-tmp/.
+
+ * Existing autoconf generated test for the need to link with pthread
+ library did not check all the functions from pthread libraries;
+ recent FreeBSD has some functions in libc but not others, and we
+ mistakenly thought linking with libc is enough when it is not.
+
+ * When "git fsck" reports a broken link (e.g. a tree object contains
+ a blob that does not exist), both containing object and the object
+ that is referred to were reported with their 40-hex object names.
+ The command learned the "--name-objects" option to show the path to
+ the containing object from existing refs (e.g. "HEAD~24^2:file.txt").
+
+ * Allow http daemon tests in Travis CI tests.
+
+ * Makefile assumed that -lrt is always available on platforms that
+ want to use clock_gettime() and CLOCK_MONOTONIC, which is not a
+ case for recent Mac OS X. The necessary symbols are often found in
+ libc on many modern systems and having -lrt on the command line, as
+ long as the library exists, had no effect, but when the platform
+ removes librt.a that is a different matter--having -lrt will break
+ the linkage.
+
+ This change could be seen as a regression for those who do need to
+ specify -lrt, as they now specifically ask for NEEDS_LIBRT when
+ building. Hopefully they are in the minority these days.
+
+ * Further preparatory work on the refs API before the pluggable
+ backend series can land.
+
+ * Error handling in the codepaths that updates refs has been
+ improved.
+
+ * The API to iterate over all the refs (i.e. for_each_ref(), etc.)
+ has been revamped.
+
+ * The handling of the "text=auto" attribute has been corrected.
+ $ echo "* text=auto eol=crlf" >.gitattributes
+ used to have the same effect as
+ $ echo "* text eol=crlf" >.gitattributes
+ i.e. declaring all files are text (ignoring "auto"). The
+ combination has been fixed to be equivalent to doing
+ $ git config core.autocrlf true
+
+ * Documentation has been updated to show better example usage
+ of the updated "text=auto" attribute.
+
+ * A few tests that specifically target "git rebase -i" have been
+ added.
+
+ * Dumb http transport on the client side has been optimized.
+ (merge ecba195 ew/http-walker later to maint).
+
+ * Users of the parse_options_concat() API function need to allocate
+ extra slots in advance and fill them with OPT_END() when they want
+ to decide the set of supported options dynamically, which makes the
+ code error-prone and hard to read. This has been corrected by tweaking
+ the API to allocate and return a new copy of "struct option" array.
+
+ * "git fetch" exchanges batched have/ack messages between the sender
+ and the receiver, initially doubling every time and then falling
+ back to enlarge the window size linearly. The "smart http"
+ transport, being an half-duplex protocol, outgrows the preset limit
+ too quickly and becomes inefficient when interacting with a large
+ repository. The internal mechanism learned to grow the window size
+ more aggressively when working with the "smart http" transport.
+
+ * Tests for "git svn" have been taught to reuse the lib-httpd test
+ infrastructure when testing the subversion integration that
+ interacts with subversion repositories served over the http://
+ protocol.
+ (merge a8a5d25 ew/git-svn-http-tests later to maint).
+
+ * "git pack-objects" has a few options that tell it not to pack
+ objects found in certain packfiles, which require it to scan .idx
+ files of all available packs. The codepaths involved in these
+ operations have been optimized for a common case of not having any
+ non-local pack and/or any .kept pack.
+
+ * The t3700 test about "add --chmod=-x" have been made a bit more
+ robust and generally cleaned up.
+ (merge 766cdc4 ib/t3700-add-chmod-x-updates later to maint).
+
+ * The build procedure learned PAGER_ENV knob that lists what default
+ environment variable settings to export for popular pagers. This
+ mechanism is used to tweak the default settings to MORE on FreeBSD.
+ (merge 995bc22 ew/build-time-pager-tweaks later to maint).
+
+ * The http-backend (the server-side component of smart-http
+ transport) used to trickle the HTTP header one at a time. Now
+ these write(2)s are batched.
+ (merge b36045c ew/http-backend-batch-headers later to maint).
+
+ * When "git rebase" tries to compare set of changes on the updated
+ upstream and our own branch, it computes patch-id for all of these
+ changes and attempts to find matches. This has been optimized by
+ lazily computing the full patch-id (which is expensive) to be
+ compared only for changes that touch the same set of paths.
+ (merge ba67504 kw/patch-ids-optim later to maint).
+
+ * A handful of tests that were broken under gettext-poison build have
+ been fixed.
+
+ * The recent i18n patch we added during this cycle did a bit too much
+ refactoring of the messages to avoid word-legos; the repetition has
+ been reduced to help translators.
+
+
+Also contains various documentation updates and code clean-ups.
+
+
+Fixes since v2.9
+----------------
+
+Unless otherwise noted, all the fixes since v2.8 in the maintenance
+track are contained in this release (see the maintenance releases'
+notes for details).
+
+ * The commands in `git log` family take %C(auto) in a custom format
+ string. This unconditionally turned the color on, ignoring
+ --no-color or with --color=auto when the output is not connected to
+ a tty; this was corrected to make the format truly behave as
+ "auto".
+
+ * "git rev-list --count" whose walk-length is limited with "-n"
+ option did not work well with the counting optimized to look at the
+ bitmap index.
+
+ * "git show -W" (extend hunks to cover the entire function, delimited
+ by lines that match the "funcname" pattern) used to show the entire
+ file when a change added an entire function at the end of the file,
+ which has been fixed.
+
+ * The documentation set has been updated so that literal commands,
+ configuration variables and environment variables are consistently
+ typeset in fixed-width font and bold in manpages.
+
+ * "git svn propset" subcommand that was added in 2.3 days is
+ documented now.
+
+ * The documentation tries to consistently spell "GPG"; when
+ referring to the specific program name, "gpg" is used.
+
+ * "git reflog" stopped upon seeing an entry that denotes a branch
+ creation event (aka "unborn"), which made it appear as if the
+ reflog was truncated.
+
+ * The git-prompt scriptlet (in contrib/) was not friendly with those
+ who uses "set -u", which has been fixed.
+
+ * compat/regex code did not cleanly compile.
+
+ * A codepath that used alloca(3) to place an unbounded amount of data
+ on the stack has been updated to avoid doing so.
+
+ * "git update-index --add --chmod=+x file" may be usable as an escape
+ hatch, but not a friendly thing to force for people who do need to
+ use it regularly. "git add --chmod=+x file" can be used instead.
+
+ * Build improvements for gnome-keyring (in contrib/)
+
+ * "git status" used to say "working directory" when it meant "working
+ tree".
+
+ * Comments about misbehaving FreeBSD shells have been clarified with
+ the version number (9.x and before are broken, newer ones are OK).
+
+ * "git cherry-pick A" worked on an unborn branch, but "git
+ cherry-pick A..B" didn't.
+
+ * Fix an unintended regression in v2.9 that breaks "clone --depth"
+ that recurses down to submodules by forcing the submodules to also
+ be cloned shallowly, which many server instances that host upstream
+ of the submodules are not prepared for.
+
+ * Fix unnecessarily waste in the idiomatic use of ': ${VAR=default}'
+ to set the default value, without enclosing it in double quotes.
+
+ * Some platform-specific code had non-ANSI strict declarations of C
+ functions that do not take any parameters, which has been
+ corrected.
+
+ * The internal code used to show local timezone offset is not
+ prepared to handle timestamps beyond year 2100, and gave a
+ bogus offset value to the caller. Use a more benign looking
+ +0000 instead and let "git log" going in such a case, instead
+ of aborting.
+
+ * One among four invocations of readlink(1) in our test suite has
+ been rewritten so that the test can run on systems without the
+ command (others are in valgrind test framework and t9802).
+
+ * t/perf needs /usr/bin/time with GNU extension; the invocation of it
+ is updated to "gtime" on Darwin.
+
+ * A bug, which caused "git p4" while running under verbose mode to
+ report paths that are omitted due to branch prefix incorrectly, has
+ been fixed; the command said "Ignoring file outside of prefix" for
+ paths that are _inside_.
+
+ * The top level documentation "git help git" still pointed at the
+ documentation set hosted at now-defunct google-code repository.
+ Update it to point to https://git.github.io/htmldocs/git.html
+ instead.
+
+ * A helper function that takes the contents of a commit object and
+ finds its subject line did not ignore leading blank lines, as is
+ commonly done by other codepaths. Make it ignore leading blank
+ lines to match.
+
+ * For a long time, we carried an in-code comment that said our
+ colored output would work only when we use fprintf/fputs on
+ Windows, which no longer is the case for the past few years.
+
+ * "gc.autoPackLimit" when set to 1 should not trigger a repacking
+ when there is only one pack, but the code counted poorly and did
+ so.
+
+ * Add a test to specify the desired behaviour that currently is not
+ available in "git rebase -Xsubtree=...".
+
+ * More mark-up updates to typeset strings that are expected to
+ literally typed by the end user in fixed-width font.
+
+ * "git commit --amend --allow-empty-message -S" for a commit without
+ any message body could have misidentified where the header of the
+ commit object ends.
+
+ * "git rebase -i --autostash" did not restore the auto-stashed change
+ when the operation was aborted.
+
+ * Git does not know what the contents in the index should be for a
+ path added with "git add -N" yet, so "git grep --cached" should not
+ show hits (or show lack of hits, with -L) in such a path, but that
+ logic does not apply to "git grep", i.e. searching in the working
+ tree files. But we did so by mistake, which has been corrected.
+
+ * "git blame -M" missed a single line that was moved within the file.
+
+ * Fix recently introduced codepaths that are involved in parallel
+ submodule operations, which gave up on reading too early, and
+ could have wasted CPU while attempting to write under a corner
+ case condition.
+
+ * "git grep -i" has been taught to fold case in non-ascii locales
+ correctly.
+
+ * A test that unconditionally used "mktemp" learned that the command
+ is not necessarily available everywhere.
+
+ * There are certain house-keeping tasks that need to be performed at
+ the very beginning of any Git program, and programs that are not
+ built-in commands had to do them exactly the same way as "git"
+ potty does. It was easy to make mistakes in one-off standalone
+ programs (like test helpers). A common "main()" function that
+ calls cmd_main() of individual program has been introduced to
+ make it harder to make mistakes.
+ (merge de61ceb jk/common-main later to maint).
+
+ * The test framework learned a new helper test_match_signal to
+ check an exit code from getting killed by an expected signal.
+
+ * General code clean-up around a helper function to write a
+ single-liner to a file.
+ (merge 7eb6e10 jk/write-file later to maint).
+
+ * One part of "git am" had an oddball helper function that called
+ stuff from outside "his" as opposed to calling what we have "ours",
+ which was not gender-neutral and also inconsistent with the rest of
+ the system where outside stuff is usually called "theirs" in
+ contrast to "ours".
+
+ * "git blame file" allowed the lineage of lines in the uncommitted,
+ unadded contents of "file" to be inspected, but it refused when
+ "file" did not appear in the current commit. When "file" was
+ created by renaming an existing file (but the change has not been
+ committed), this restriction was unnecessarily tight.
+
+ * "git add -N dir/file && git write-tree" produced an incorrect tree
+ when there are other paths in the same directory that sorts after
+ "file".
+
+ * "git fetch http://user:pass@host/repo..." scrubbed the userinfo
+ part, but "git push" didn't.
+
+ * "git merge" with renormalization did not work well with
+ merge-recursive, due to "safer crlf" conversion kicking in when it
+ shouldn't.
+ (merge 1335d76 jc/renormalize-merge-kill-safer-crlf later to maint).
+
+ * The use of strbuf in "git rm" to build filename to remove was a bit
+ suboptimal, which has been fixed.
+
+ * An age old bug that caused "git diff --ignore-space-at-eol"
+ misbehave has been fixed.
+
+ * "git notes merge" had a code to see if a path exists (and fails if
+ it does) and then open the path for writing (when it doesn't).
+ Replace it with open with O_EXCL.
+
+ * "git pack-objects" and "git index-pack" mostly operate with off_t
+ when talking about the offset of objects in a packfile, but there
+ were a handful of places that used "unsigned long" to hold that
+ value, leading to an unintended truncation.
+
+ * Recent update to "git daemon" tries to enable the socket-level
+ KEEPALIVE, but when it is spawned via inetd, the standard input
+ file descriptor may not necessarily be connected to a socket.
+ Suppress an ENOTSOCK error from setsockopt().
+
+ * Recent FreeBSD stopped making perl available at /usr/bin/perl;
+ switch the default the built-in path to /usr/local/bin/perl on not
+ too ancient FreeBSD releases.
+
+ * "git commit --help" said "--no-verify" is only about skipping the
+ pre-commit hook, and failed to say that it also skipped the
+ commit-msg hook.
+
+ * "git merge" in Git v2.9 was taught to forbid merging an unrelated
+ lines of history by default, but that is exactly the kind of thing
+ the "--rejoin" mode of "git subtree" (in contrib/) wants to do.
+ "git subtree" has been taught to use the "--allow-unrelated-histories"
+ option to override the default.
+
+ * The build procedure for "git persistent-https" helper (in contrib/)
+ has been updated so that it can be built with more recent versions
+ of Go.
+
+ * There is an optimization used in "git diff $treeA $treeB" to borrow
+ an already checked-out copy in the working tree when it is known to
+ be the same as the blob being compared, expecting that open/mmap of
+ such a file is faster than reading it from the object store, which
+ involves inflating and applying delta. This however kicked in even
+ when the checked-out copy needs to go through the convert-to-git
+ conversion (including the clean filter), which defeats the whole
+ point of the optimization. The optimization has been disabled when
+ the conversion is necessary.
+
+ * "git -c grep.patternType=extended log --basic-regexp" misbehaved
+ because the internal API to access the grep machinery was not
+ designed well.
+
+ * Windows port was failing some tests in t4130, due to the lack of
+ inum in the returned values by its lstat(2) emulation.
+
+ * The reflog output format is documented better, and a new format
+ --date=unix to report the seconds-since-epoch (without timezone)
+ has been added.
+ (merge 442f6fd jk/reflog-date later to maint).
+
+ * "git difftool <paths>..." started in a subdirectory failed to
+ interpret the paths relative to that directory, which has been
+ fixed.
+
+ * The characters in the label shown for tags/refs for commits in
+ "gitweb" output are now properly escaped for proper HTML output.
+
+ * FreeBSD can lie when asked mtime of a directory, which made the
+ untracked cache code to fall back to a slow-path, which in turn
+ caused tests in t7063 to fail because it wanted to verify the
+ behaviour of the fast-path.
+
+ * Squelch compiler warnings for nedmalloc (in compat/) library.
+
+ * A small memory leak in the command line parsing of "git blame"
+ has been plugged.
+
+ * The API documentation for hashmap was unclear if hashmap_entry
+ can be safely discarded without any other consideration. State
+ that it is safe to do so.
+
+ * Not-so-recent rewrite of "git am" that started making internal
+ calls into the commit machinery had an unintended regression, in
+ that no matter how many seconds it took to apply many patches, the
+ resulting committer timestamp for the resulting commits were all
+ the same.
+
+ * "git push --force-with-lease" already had enough logic to allow
+ ensuring that such a push results in creation of a ref (i.e. the
+ receiving end did not have another push from sideways that would be
+ discarded by our force-pushing), but didn't expose this possibility
+ to the users. It does so now.
+ (merge 9eed4f3 jk/push-force-with-lease-creation later to maint).
+
+ * The mechanism to limit the pack window memory size, when packing is
+ done using multiple threads (which is the default), is per-thread,
+ but this was not documented clearly.
+ (merge 954176c ms/document-pack-window-memory-is-per-thread later to maint).
+
+ * "import-tars" fast-import script (in contrib/) used to ignore a
+ hardlink target and replaced it with an empty file, which has been
+ corrected to record the same blob as the other file the hardlink is
+ shared with.
+ (merge 04e0869 js/import-tars-hardlinks later to maint).
+
+ * "git mv dir non-existing-dir/" did not work in some environments
+ the same way as existing mainstream platforms. The code now moves
+ "dir" to "non-existing-dir", without relying on rename("A", "B/")
+ that strips the trailing slash of '/'.
+ (merge 189d035 js/mv-dir-to-new-directory later to maint).
+
+ * The "t/" hierarchy is prone to get an unusual pathname; "make test"
+ has been taught to make sure they do not contain paths that cannot
+ be checked out on Windows (and the mechanism can be reusable to
+ catch pathnames that are not portable to other platforms as need
+ arises).
+ (merge c2cafd3 js/test-lint-pathname later to maint).
+
+ * When "git merge-recursive" works on history with many criss-cross
+ merges in "verbose" mode, the names the command assigns to the
+ virtual merge bases could have overwritten each other by unintended
+ reuse of the same piece of memory.
+ (merge 5447a76 rs/pull-signed-tag later to maint).
+
+ * "git checkout --detach <branch>" used to give the same advice
+ message as that is issued when "git checkout <tag>" (or anything
+ that is not a branch name) is given, but asking with "--detach" is
+ an explicit enough sign that the user knows what is going on. The
+ advice message has been squelched in this case.
+ (merge 779b88a sb/checkout-explit-detach-no-advice later to maint).
+
+ * "git difftool" by default ignores the error exit from the backend
+ commands it spawns, because often they signal that they found
+ differences by exiting with a non-zero status code just like "diff"
+ does; the exit status codes 126 and above however are special in
+ that they are used to signal that the command is not executable,
+ does not exist, or killed by a signal. "git difftool" has been
+ taught to notice these exit status codes.
+ (merge 45a4f5d jk/difftool-command-not-found later to maint).
+
+ * On Windows, help.browser configuration variable used to be ignored,
+ which has been corrected.
+ (merge 6db5967 js/no-html-bypass-on-windows later to maint).
+
+ * The "git -c var[=val] cmd" facility to append a configuration
+ variable definition at the end of the search order was described in
+ git(1) manual page, but not in git-config(1), which was more likely
+ place for people to look for when they ask "can I make a one-shot
+ override, and if so how?"
+ (merge ae1f709 dg/document-git-c-in-git-config-doc later to maint).
+
+ * The tempfile (hence its user lockfile) API lets the caller to open
+ a file descriptor to a temporary file, write into it and then
+ finalize it by first closing the filehandle and then either
+ removing or renaming the temporary file. When the process spawns a
+ subprocess after obtaining the file descriptor, and if the
+ subprocess has not exited when the attempt to remove or rename is
+ made, the last step fails on Windows, because the subprocess has
+ the file descriptor still open. Open tempfile with O_CLOEXEC flag
+ to avoid this (on Windows, this is mapped to O_NOINHERIT).
+ (merge 05d1ed6 bw/mingw-avoid-inheriting-fd-to-lockfile later to maint).
+
+ * Correct an age-old calco (is that a typo-like word for calc)
+ in the documentation.
+ (merge 7841c48 ls/packet-line-protocol-doc-fix later to maint).
+
+ * Other minor clean-ups and documentation updates
+ (merge 02a8cfa rs/merge-add-strategies-simplification later to maint).
+ (merge af4941d rs/merge-recursive-string-list-init later to maint).
+ (merge 1eb47f1 rs/use-strbuf-add-unique-abbrev later to maint).
+ (merge ddd0bfa jk/tighten-alloc later to maint).
+ (merge ecf30b2 rs/mailinfo-lib later to maint).
+ (merge 0eb75ce sg/reflog-past-root later to maint).
+ (merge 4369523 hv/doc-commit-reference-style later to maint).
diff --git a/RelNotes/2.10.1.adoc b/RelNotes/2.10.1.adoc
new file mode 100644
index 0000000..70462f7
--- /dev/null
+++ b/RelNotes/2.10.1.adoc
@@ -0,0 +1,131 @@
+Git v2.10.1 Release Notes
+=========================
+
+Fixes since v2.10
+-----------------
+
+ * Clarify various ways to specify the "revision ranges" in the
+ documentation.
+
+ * "diff-highlight" script (in contrib/) learned to work better with
+ "git log -p --graph" output.
+
+ * The test framework left the number of tests and success/failure
+ count in the t/test-results directory, keyed by the name of the
+ test script plus the process ID. The latter however turned out not
+ to serve any useful purpose. The process ID part of the filename
+ has been removed.
+
+ * Having a submodule whose ".git" repository is somehow corrupt
+ caused a few commands that recurse into submodules loop forever.
+
+ * "git symbolic-ref -d HEAD" happily removes the symbolic ref, but
+ the resulting repository becomes an invalid one. Teach the command
+ to forbid removal of HEAD.
+
+ * A test spawned a short-lived background process, which sometimes
+ prevented the test directory from getting removed at the end of the
+ script on some platforms.
+
+ * Update a few tests that used to use GIT_CURL_VERBOSE to use the
+ newer GIT_TRACE_CURL.
+
+ * Update Japanese translation for "git-gui".
+
+ * "git fetch http::/site/path" did not die correctly and segfaulted
+ instead.
+
+ * "git commit-tree" stopped reading commit.gpgsign configuration
+ variable that was meant for Porcelain "git commit" in Git 2.9; we
+ forgot to update "git gui" to look at the configuration to match
+ this change.
+
+ * "git log --cherry-pick" used to include merge commits as candidates
+ to be matched up with other commits, resulting a lot of wasted time.
+ The patch-id generation logic has been updated to ignore merges to
+ avoid the wastage.
+
+ * The http transport (with curl-multi option, which is the default
+ these days) failed to remove curl-easy handle from a curlm session,
+ which led to unnecessary API failures.
+
+ * "git diff -W" output needs to extend the context backward to
+ include the header line of the current function and also forward to
+ include the body of the entire current function up to the header
+ line of the next one. This process may have to merge to adjacent
+ hunks, but the code forgot to do so in some cases.
+
+ * Performance tests done via "t/perf" did not use the same set of
+ build configuration if the user relied on autoconf generated
+ configuration.
+
+ * "git format-patch --base=..." feature that was recently added
+ showed the base commit information after "-- " e-mail signature
+ line, which turned out to be inconvenient. The base information
+ has been moved above the signature line.
+
+ * Even when "git pull --rebase=preserve" (and the underlying "git
+ rebase --preserve") can complete without creating any new commit
+ (i.e. fast-forwards), it still insisted on having a usable ident
+ information (read: user.email is set correctly), which was less
+ than nice. As the underlying commands used inside "git rebase"
+ would fail with a more meaningful error message and advice text
+ when the bogus ident matters, this extra check was removed.
+
+ * "git gc --aggressive" used to limit the delta-chain length to 250,
+ which is way too deep for gaining additional space savings and is
+ detrimental for runtime performance. The limit has been reduced to
+ 50.
+
+ * Documentation for individual configuration variables to control use
+ of color (like `color.grep`) said that their default value is
+ 'false', instead of saying their default is taken from `color.ui`.
+ When we updated the default value for color.ui from 'false' to
+ 'auto' quite a while ago, all of them broke. This has been
+ corrected.
+
+ * A shell script example in check-ref-format documentation has been
+ fixed.
+
+ * "git checkout <word>" does not follow the usual disambiguation
+ rules when the <word> can be both a rev and a path, to allow
+ checking out a branch 'foo' in a project that happens to have a
+ file 'foo' in the working tree without having to disambiguate.
+ This was poorly documented and the check was incorrect when the
+ command was run from a subdirectory.
+
+ * Some codepaths in "git diff" used regexec(3) on a buffer that was
+ mmap(2)ed, which may not have a terminating NUL, leading to a read
+ beyond the end of the mapped region. This was fixed by introducing
+ a regexec_buf() helper that takes a <ptr,len> pair with REG_STARTEND
+ extension.
+
+ * The procedure to build Git on Mac OS X for Travis CI hardcoded the
+ internal directory structure we assumed HomeBrew uses, which was a
+ no-no. The procedure has been updated to ask HomeBrew things we
+ need to know to fix this.
+
+ * When "git rebase -i" is given a broken instruction, it told the
+ user to fix it with "--edit-todo", but didn't say what the step
+ after that was (i.e. "--continue").
+
+ * "git add --chmod=+x" added recently lacked documentation, which has
+ been corrected.
+
+ * "git add --chmod=+x <pathspec>" added recently only toggled the
+ executable bit for paths that are either new or modified. This has
+ been corrected to flip the executable bit for all paths that match
+ the given pathspec.
+
+ * "git pack-objects --include-tag" was taught that when we know that
+ we are sending an object C, we want a tag B that directly points at
+ C but also a tag A that points at the tag B. We used to miss the
+ intermediate tag B in some cases.
+
+ * Documentation around tools to import from CVS was fairly outdated.
+
+ * In the codepath that comes up with the hostname to be used in an
+ e-mail when the user didn't tell us, we looked at ai_canonname
+ field in struct addrinfo without making sure it is not NULL first.
+
+Also contains minor documentation updates and code clean-ups.
diff --git a/RelNotes/2.10.2.adoc b/RelNotes/2.10.2.adoc
new file mode 100644
index 0000000..abbd331
--- /dev/null
+++ b/RelNotes/2.10.2.adoc
@@ -0,0 +1,111 @@
+Git v2.10.2 Release Notes
+=========================
+
+Fixes since v2.10.1
+-------------------
+
+ * The code that parses the format parameter of for-each-ref command
+ has seen a micro-optimization.
+
+ * The "graph" API used in "git log --graph" miscounted the number of
+ output columns consumed so far when drawing a padding line, which
+ has been fixed; this did not affect any existing code as nobody
+ tried to write anything after the padding on such a line, though.
+
+ * Almost everybody uses DEFAULT_ABBREV to refer to the default
+ setting for the abbreviation, but "git blame" peeked into
+ underlying variable bypassing the macro for no good reason.
+
+ * Doc update to clarify what "log -3 --reverse" does.
+
+ * An author name, that spelled a backslash-quoted double quote in the
+ human readable part "My \"double quoted\" name", was not unquoted
+ correctly while applying a patch from a piece of e-mail.
+
+ * The original command line syntax for "git merge", which was "git
+ merge <msg> HEAD <parent>...", has been deprecated for quite some
+ time, and "git gui" was the last in-tree user of the syntax. This
+ is finally fixed, so that we can move forward with the deprecation.
+
+ * Codepaths that read from an on-disk loose object were too loose in
+ validating what they are reading is a proper object file and
+ sometimes read past the data they read from the disk, which has
+ been corrected. H/t to Gustavo Grieco for reporting.
+
+ * "git worktree", even though it used the default_abbrev setting that
+ ought to be affected by core.abbrev configuration variable, ignored
+ the variable setting. The command has been taught to read the
+ default set of configuration variables to correct this.
+
+ * A low-level function verify_packfile() was meant to show errors
+ that were detected without dying itself, but under some conditions
+ it didn't and died instead, which has been fixed.
+
+ * When "git fetch" tries to find where the history of the repository
+ it runs in has diverged from what the other side has, it has a
+ mechanism to avoid digging too deep into irrelevant side branches.
+ This however did not work well over the "smart-http" transport due
+ to a design bug, which has been fixed.
+
+ * When we started cURL to talk to imap server when a new enough
+ version of cURL library is available, we forgot to explicitly add
+ imap(s):// before the destination. To some folks, that didn't work
+ and the library tried to make HTTP(s) requests instead.
+
+ * The ./configure script generated from configure.ac was taught how
+ to detect support of SSL by libcurl better.
+
+ * http.emptyauth configuration is a way to allow an empty username to
+ pass when attempting to authenticate using mechanisms like
+ Kerberos. We took an unspecified (NULL) username and sent ":"
+ (i.e. no username, no password) to CURLOPT_USERPWD, but did not do
+ the same when the username is explicitly set to an empty string.
+
+ * "git clone" of a local repository can be done at the filesystem
+ level, but the codepath did not check errors while copying and
+ adjusting the file that lists alternate object stores.
+
+ * Documentation for "git commit" was updated to clarify that "commit
+ -p <paths>" adds to the current contents of the index to come up
+ with what to commit.
+
+ * A stray symbolic link in $GIT_DIR/refs/ directory could make name
+ resolution loop forever, which has been corrected.
+
+ * The "submodule.<name>.path" stored in .gitmodules is never copied
+ to .git/config and such a key in .git/config has no meaning, but
+ the documentation described it and submodule.<name>.url next to
+ each other as if both belong to .git/config. This has been fixed.
+
+ * Recent git allows submodule.<name>.branch to use a special token
+ "." instead of the branch name; the documentation has been updated
+ to describe it.
+
+ * In a worktree connected to a repository elsewhere, created via "git
+ worktree", "git checkout" attempts to protect users from confusion
+ by refusing to check out a branch that is already checked out in
+ another worktree. However, this also prevented checking out a
+ branch, which is designated as the primary branch of a bare
+ repository, in a worktree that is connected to the bare
+ repository. The check has been corrected to allow it.
+
+ * "git rebase" immediately after "git clone" failed to find the fork
+ point from the upstream.
+
+ * When fetching from a remote that has many tags that are irrelevant
+ to branches we are following, we used to waste way too many cycles
+ when checking if the object pointed at by a tag (that we are not
+ going to fetch!) exists in our repository too carefully.
+
+ * The Travis CI configuration we ship ran the tests with --verbose
+ option but this risks non-TAP output that happens to be "ok" to be
+ misinterpreted as TAP signalling a test that passed. This resulted
+ in unnecessary failure. This has been corrected by introducing a
+ new mode to run our tests in the test harness to send the verbose
+ output separately to the log file.
+
+ * Some AsciiDoc formatter mishandles a displayed illustration with
+ tabs in it. Adjust a few of them in merge-base documentation to
+ work around them.
+
+Also contains minor documentation updates and code clean-ups.
diff --git a/RelNotes/2.10.3.adoc b/RelNotes/2.10.3.adoc
new file mode 100644
index 0000000..ad6a01b
--- /dev/null
+++ b/RelNotes/2.10.3.adoc
@@ -0,0 +1,55 @@
+Git v2.10.3 Release Notes
+=========================
+
+Fixes since v2.10.2
+-------------------
+
+ * Extract a small helper out of the function that reads the authors
+ script file "git am" internally uses.
+ This by itself is not useful until a second caller appears in the
+ future for "rebase -i" helper.
+
+ * The command-line completion script (in contrib/) learned to
+ complete "git cmd ^mas<HT>" to complete the negative end of
+ reference to "git cmd ^master".
+
+ * "git send-email" attempts to pick up valid e-mails from the
+ trailers, but people in real world write non-addresses there, like
+ "Cc: Stable <add@re.ss> # 4.8+", which broke the output depending
+ on the availability and vintage of Mail::Address perl module.
+
+ * The code that we have used for the past 10+ years to cycle
+ 4-element ring buffers turns out to be not quite portable in
+ theoretical world.
+
+ * "git daemon" used fixed-length buffers to turn URL to the
+ repository the client asked for into the server side directory
+ path, using snprintf() to avoid overflowing these buffers, but
+ allowed possibly truncated paths to the directory. This has been
+ tightened to reject such a request that causes overlong path to be
+ required to serve.
+
+ * Recent update to git-sh-setup (a library of shell functions that
+ are used by our in-tree scripted Porcelain commands) included
+ another shell library git-sh-i18n without specifying where it is,
+ relying on the $PATH. This has been fixed to be more explicit by
+ prefixing $(git --exec-path) output in front.
+
+ * Fix for a racy false-positive test failure.
+
+ * Portability update and workaround for builds on recent Mac OS X.
+
+ * Update to the test framework made in 2.9 timeframe broke running
+ the tests under valgrind, which has been fixed.
+
+ * Improve the rule to convert "unsigned char [20]" into "struct
+ object_id *" in contrib/coccinelle/
+
+ * "git-shell" rejects a request to serve a repository whose name
+ begins with a dash, which makes it no longer possible to get it
+ confused into spawning service programs like "git-upload-pack" with
+ an option like "--help", which in turn would spawn an interactive
+ pager, instead of working with the repository user asked to access
+ (i.e. the one whose name is "--help").
+
+Also contains minor documentation updates and code clean-ups.
diff --git a/RelNotes/2.10.4.adoc b/RelNotes/2.10.4.adoc
new file mode 100644
index 0000000..ee8142a
--- /dev/null
+++ b/RelNotes/2.10.4.adoc
@@ -0,0 +1,4 @@
+Git v2.10.4 Release Notes
+=========================
+
+This release forward-ports the fix for "ssh://..." URL from Git v2.7.6
diff --git a/RelNotes/2.10.5.adoc b/RelNotes/2.10.5.adoc
new file mode 100644
index 0000000..a498fd6
--- /dev/null
+++ b/RelNotes/2.10.5.adoc
@@ -0,0 +1,17 @@
+Git v2.10.5 Release Notes
+=========================
+
+Fixes since v2.10.4
+-------------------
+
+ * "git cvsserver" no longer is invoked by "git daemon" by default,
+ as it is old and largely unmaintained.
+
+ * Various Perl scripts did not use safe_pipe_capture() instead of
+ backticks, leaving them susceptible to end-user input. They have
+ been corrected.
+
+Credits go to joernchen <joernchen@phenoelit.de> for finding the
+unsafe constructs in "git cvsserver", and to Jeff King at GitHub for
+finding and fixing instances of the same issue in other scripts.
+
diff --git a/RelNotes/2.11.0.adoc b/RelNotes/2.11.0.adoc
new file mode 100644
index 0000000..b7b7dd3
--- /dev/null
+++ b/RelNotes/2.11.0.adoc
@@ -0,0 +1,593 @@
+Git 2.11 Release Notes
+======================
+
+Backward compatibility notes.
+
+ * An empty string used as a pathspec element has always meant
+ 'everything matches', but it is too easy to write a script that
+ finds a path to remove in $path and run 'git rm "$paht"' by
+ mistake (when the user meant to give "$path"), which ends up
+ removing everything. This release starts warning about the
+ use of an empty string that is used for 'everything matches' and
+ asks users to use a more explicit '.' for that instead.
+
+ The hope is that existing users will not mind this change, and
+ eventually the warning can be turned into a hard error, upgrading
+ the deprecation into removal of this (mis)feature.
+
+ * The historical argument order "git merge <msg> HEAD <commit>..."
+ has been deprecated for quite some time, and will be removed in the
+ next release (not this one).
+
+ * The default abbreviation length, which has historically been 7, now
+ scales as the repository grows, using the approximate number of
+ objects in the repository and a bit of math around the birthday
+ paradox. The logic suggests to use 12 hexdigits for the Linux
+ kernel, and 9 to 10 for Git itself.
+
+
+Updates since v2.10
+-------------------
+
+UI, Workflows & Features
+
+ * Comes with new version of git-gui, now at its 0.21.0 tag.
+
+ * "git format-patch --cover-letter HEAD^" to format a single patch
+ with a separate cover letter now numbers the output as [PATCH 0/1]
+ and [PATCH 1/1] by default.
+
+ * An incoming "git push" that attempts to push too many bytes can now
+ be rejected by setting a new configuration variable at the receiving
+ end.
+
+ * "git nosuchcommand --help" said "No manual entry for gitnosuchcommand",
+ which was not intuitive, given that "git nosuchcommand" said "git:
+ 'nosuchcommand' is not a git command".
+
+ * "git clone --recurse-submodules --reference $path $URL" is a way to
+ reduce network transfer cost by borrowing objects in an existing
+ $path repository when cloning the superproject from $URL; it
+ learned to also peek into $path for presence of corresponding
+ repositories of submodules and borrow objects from there when able.
+
+ * The "git diff --submodule={short,log}" mechanism has been enhanced
+ to allow "--submodule=diff" to show the patch between the submodule
+ commits bound to the superproject.
+
+ * Even though "git hash-objects", which is a tool to take an
+ on-filesystem data stream and put it into the Git object store,
+ can perform "outside-world-to-Git" conversions (e.g.
+ end-of-line conversions and application of the clean-filter), and
+ it has had this feature on by default from very early days, its reverse
+ operation "git cat-file", which takes an object from the Git object
+ store and externalizes it for consumption by the outside world,
+ lacked an equivalent mechanism to run the "Git-to-outside-world"
+ conversion. The command learned the "--filters" option to do so.
+
+ * Output from "git diff" can be made easier to read by intelligently selecting
+ which lines are common and which lines are added/deleted
+ when the lines before and after the changed section
+ are the same. A command line option (--indent-heuristic) and a
+ configuration variable (diff.indentHeuristic) are added to help with the
+ experiment to find good heuristics.
+
+ * In some projects, it is common to use "[RFC PATCH]" as the subject
+ prefix for a patch meant for discussion rather than application. A
+ new format-patch option "--rfc" is a short-hand for "--subject-prefix=RFC PATCH"
+ to help the participants of such projects.
+
+ * "git add --chmod={+,-}x <pathspec>" only changed the
+ executable bit for paths that are either new or modified. This has
+ been corrected to change the executable bit for all paths that match
+ the given pathspec.
+
+ * When "git format-patch --stdout" output is placed as an in-body
+ header and it uses RFC2822 header folding, "git am" fails to
+ put the header line back into a single logical line. The
+ underlying "git mailinfo" was taught to handle this properly.
+
+ * "gitweb" can spawn "highlight" to show blob contents with
+ (programming) language-specific syntax highlighting, but only
+ when the language is known. "highlight" can however be told
+ to guess the language itself by giving it "--force" option, which
+ has been enabled.
+
+ * "git gui" l10n to Portuguese.
+
+ * When given an abbreviated object name that is not (or more
+ realistically, "no longer") unique, we gave a fatal error
+ "ambiguous argument". This error is now accompanied by a hint that
+ lists the objects beginning with the given prefix. During the
+ course of development of this new feature, numerous minor bugs were
+ uncovered and corrected, the most notable one of which is that we
+ gave "short SHA1 xxxx is ambiguous." twice without good reason.
+
+ * "git log rev^..rev" is an often-used revision range specification
+ to show what was done on a side branch merged at rev. This has
+ gained a short-hand "rev^-1". In general "rev^-$n" is the same as
+ "^rev^$n rev", i.e. what has happened on other branches while the
+ history leading to nth parent was looking the other way.
+
+ * In recent versions of cURL, GSSAPI credential delegation is
+ disabled by default due to CVE-2011-2192; introduce a http.delegation
+ configuration variable to selectively allow enabling this.
+ (merge 26a7b23429 ps/http-gssapi-cred-delegation later to maint).
+
+ * "git mergetool" learned to honor "-O<orderfile>" to control the
+ order of paths to present to the end user.
+
+ * "git diff/log --ws-error-highlight=<kind>" lacked the corresponding
+ configuration variable (diff.wsErrorHighlight) to set it by default.
+
+ * "git ls-files" learned the "--recurse-submodules" option
+ to get a listing of tracked files across submodules (i.e. this
+ only works with the "--cached" option, not for listing untracked or
+ ignored files). This would be a useful tool to sit on the upstream
+ side of a pipe that is read with xargs to work on all working tree
+ files from the top-level superproject.
+
+ * A new credential helper that talks via "libsecret" with
+ implementations of XDG Secret Service API has been added to
+ contrib/credential/.
+
+ * The GPG verification status shown by the "%G?" pretty format specifier
+ was not rich enough to differentiate a signature made by an expired
+ key, a signature made by a revoked key, etc. New output letters
+ have been assigned to express them.
+
+ * In addition to purely abbreviated commit object names, "gitweb"
+ learned to turn "git describe" output (e.g. v2.9.3-599-g2376d31787)
+ into clickable links in its output.
+
+ * "git commit" created an empty commit when invoked with an index
+ consisting solely of intend-to-add paths (added with "git add -N").
+ It now requires the "--allow-empty" option to create such a commit.
+ The same logic prevented "git status" from showing such paths as "new files" in the
+ "Changes not staged for commit" section.
+
+ * The smudge/clean filter API spawns an external process
+ to filter the contents of each path that has a filter defined. A
+ new type of "process" filter API has been added to allow the first
+ request to run the filter for a path to spawn a single process, and
+ all filtering is served by this single process for multiple
+ paths, reducing the process creation overhead.
+
+ * The user always has to say "stash@{$N}" when naming a single
+ element in the default location of the stash, i.e. reflogs in
+ refs/stash. The "git stash" command learned to accept "git stash
+ apply 4" as a short-hand for "git stash apply stash@{4}".
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * The delta-base-cache mechanism has been a key to the performance in
+ a repository with a tightly packed packfile, but it did not scale
+ well even with a larger value of core.deltaBaseCacheLimit.
+
+ * Enhance "git status --porcelain" output by collecting more data on
+ the state of the index and the working tree files, which may
+ further be used to teach git-prompt (in contrib/) to make fewer
+ calls to git.
+
+ * Extract a small helper out of the function that reads the authors
+ script file "git am" internally uses.
+ (merge a77598e jc/am-read-author-file later to maint).
+
+ * Lift calls to exit(2) and die() higher in the callchain in
+ sequencer.c files so that more helper functions in it can be used
+ by callers that want to handle error conditions themselves.
+
+ * "git am" has been taught to make an internal call to "git apply"'s
+ innards without spawning the latter as a separate process.
+
+ * The ref-store abstraction was introduced to the refs API so that we
+ can plug in different backends to store references.
+
+ * The "unsigned char sha1[20]" to "struct object_id" conversion
+ continues. Notable changes in this round includes that ce->sha1,
+ i.e. the object name recorded in the cache_entry, turns into an
+ object_id.
+
+ * JGit can show a fake ref "capabilities^{}" to "git fetch" when it
+ does not advertise any refs, but "git fetch" was not prepared to
+ see such an advertisement. When the other side disconnects without
+ giving any ref advertisement, we used to say "there may not be a
+ repository at that URL", but we may have seen other advertisements
+ like "shallow" and ".have" in which case we definitely know that a
+ repository is there. The code to detect this case has also been
+ updated.
+
+ * Some codepaths in "git pack-objects" were not ready to use an
+ existing pack bitmap; now they are and as a result they have
+ become faster.
+
+ * The codepath in "git fsck" to detect malformed tree objects has
+ been updated not to die but keep going after detecting them.
+
+ * We call "qsort(array, nelem, sizeof(array[0]), fn)", and most of
+ the time third parameter is redundant. A new QSORT() macro lets us
+ omit it.
+
+ * "git pack-objects" in a repository with many packfiles used to
+ spend a lot of time looking for/at objects in them; the accesses to
+ the packfiles are now optimized by checking the most-recently-used
+ packfile first.
+ (merge c9af708b1a jk/pack-objects-optim-mru later to maint).
+
+ * Codepaths involved in interacting alternate object stores have
+ been cleaned up.
+
+ * In order for the receiving end of "git push" to inspect the
+ received history and decide to reject the push, the objects sent
+ from the sending end need to be made available to the hook and
+ the mechanism for the connectivity check, and this was done
+ traditionally by storing the objects in the receiving repository
+ and letting "git gc" expire them. Instead, store the newly
+ received objects in a temporary area, and make them available by
+ reusing the alternate object store mechanism to them only while we
+ decide if we accept the check, and once we decide, either migrate
+ them to the repository or purge them immediately.
+
+ * The require_clean_work_tree() helper was recreated in C when "git
+ pull" was rewritten from shell; the helper is now made available to
+ other callers in preparation for upcoming "rebase -i" work.
+
+ * "git upload-pack" had its code cleaned-up and performance improved
+ by reducing use of timestamp-ordered commit-list, which was
+ replaced with a priority queue.
+
+ * "git diff --no-index" codepath has been updated not to try to peek
+ into a .git/ directory that happens to be under the current
+ directory, when we know we are operating outside any repository.
+
+ * Update of the sequencer codebase to make it reusable to reimplement
+ "rebase -i" continues.
+
+ * Git generally does not explicitly close file descriptors that were
+ open in the parent process when spawning a child process, but most
+ of the time the child does not want to access them. As Windows does
+ not allow removing or renaming a file that has a file descriptor
+ open, a slow-to-exit child can even break the parent process by
+ holding onto them. Use O_CLOEXEC flag to open files in various
+ codepaths.
+
+ * Update "interpret-trailers" machinery and teach it that people in
+ the real world write all sorts of cruft in the "trailer" that was
+ originally designed to have the neat-o "Mail-Header: like thing"
+ and nothing else.
+
+
+Also contains various documentation updates and code clean-ups.
+
+
+Fixes since v2.10
+-----------------
+
+Unless otherwise noted, all the fixes since v2.9 in the maintenance
+track are contained in this release (see the maintenance releases'
+notes for details).
+
+ * Clarify various ways to specify the "revision ranges" in the
+ documentation.
+
+ * "diff-highlight" script (in contrib/) learned to work better with
+ "git log -p --graph" output.
+
+ * The test framework left the number of tests and success/failure
+ count in the t/test-results directory, keyed by the name of the
+ test script plus the process ID. The latter however turned out not
+ to serve any useful purpose. The process ID part of the filename
+ has been removed.
+
+ * Having a submodule whose ".git" repository is somehow corrupt
+ caused a few commands that recurse into submodules to loop forever.
+
+ * "git symbolic-ref -d HEAD" happily removes the symbolic ref, but
+ the resulting repository becomes an invalid one. Teach the command
+ to forbid removal of HEAD.
+
+ * A test spawned a short-lived background process, which sometimes
+ prevented the test directory from getting removed at the end of the
+ script on some platforms.
+
+ * Update a few tests that used to use GIT_CURL_VERBOSE to use the
+ newer GIT_TRACE_CURL.
+
+ * "git pack-objects --include-tag" was taught that when we know that
+ we are sending an object C, we want a tag B that directly points at
+ C but also a tag A that points at the tag B. We used to miss the
+ intermediate tag B in some cases.
+
+ * Update Japanese translation for "git-gui".
+
+ * "git fetch http::/site/path" did not die correctly and segfaulted
+ instead.
+
+ * "git commit-tree" stopped reading commit.gpgsign configuration
+ variable that was meant for Porcelain "git commit" in Git 2.9; we
+ forgot to update "git gui" to look at the configuration to match
+ this change.
+
+ * "git add --chmod={+,-}x" added recently lacked documentation, which has
+ been corrected.
+
+ * "git log --cherry-pick" used to include merge commits as candidates
+ to be matched up with other commits, resulting a lot of wasted time.
+ The patch-id generation logic has been updated to ignore merges and
+ avoid the wastage.
+
+ * The http transport (with curl-multi option, which is the default
+ these days) failed to remove curl-easy handle from a curlm session,
+ which led to unnecessary API failures.
+
+ * There were numerous corner cases in which the configuration files
+ are read and used or not read at all depending on the directory a
+ Git command was run, leading to inconsistent behaviour. The code
+ to set-up repository access at the beginning of a Git process has
+ been updated to fix them.
+ (merge 4d0efa1 jk/setup-sequence-update later to maint).
+
+ * "git diff -W" output needs to extend the context backward to
+ include the header line of the current function and also forward to
+ include the body of the entire current function up to the header
+ line of the next one. This process may have to merge two adjacent
+ hunks, but the code forgot to do so in some cases.
+
+ * Performance tests done via "t/perf" did not use the right
+ build configuration if the user relied on autoconf generated
+ configuration.
+
+ * "git format-patch --base=..." feature that was recently added
+ showed the base commit information after the "-- " e-mail signature
+ line, which turned out to be inconvenient. The base information
+ has been moved above the signature line.
+
+ * More i18n.
+
+ * Even when "git pull --rebase=preserve" (and the underlying "git
+ rebase --preserve") can complete without creating any new commits
+ (i.e. fast-forwards), it still insisted on having usable ident
+ information (read: user.email is set correctly), which was less
+ than nice. As the underlying commands used inside "git rebase"
+ would fail with a more meaningful error message and advice text
+ when the bogus ident matters, this extra check was removed.
+
+ * "git gc --aggressive" used to limit the delta-chain length to 250,
+ which is way too deep for gaining additional space savings and is
+ detrimental for runtime performance. The limit has been reduced to
+ 50.
+
+ * Documentation for individual configuration variables to control use
+ of color (like `color.grep`) said that their default value is
+ 'false', instead of saying their default is taken from `color.ui`.
+ When we updated the default value for color.ui from 'false' to
+ 'auto' quite a while ago, all of them broke. This has been
+ corrected.
+
+ * The pretty-format specifier "%C(auto)" used by the "log" family of
+ commands to enable coloring of the output is taught to also issue a
+ color-reset sequence to the output.
+
+ * A shell script example in check-ref-format documentation has been
+ fixed.
+
+ * "git checkout <word>" does not follow the usual disambiguation
+ rules when the <word> can be both a rev and a path, to allow
+ checking out a branch 'foo' in a project that happens to have a
+ file 'foo' in the working tree without having to disambiguate.
+ This was poorly documented and the check was incorrect when the
+ command was run from a subdirectory.
+
+ * Some codepaths in "git diff" used regexec(3) on a buffer that was
+ mmap(2)ed, which may not have a terminating NUL, leading to a read
+ beyond the end of the mapped region. This was fixed by introducing
+ a regexec_buf() helper that takes a <ptr,len> pair with REG_STARTEND
+ extension.
+
+ * The procedure to build Git on Mac OS X for Travis CI hardcoded the
+ internal directory structure we assumed HomeBrew uses, which was a
+ no-no. The procedure has been updated to ask HomeBrew things we
+ need to know to fix this.
+
+ * When "git rebase -i" is given a broken instruction, it told the
+ user to fix it with "--edit-todo", but didn't say what the step
+ after that was (i.e. "--continue").
+
+ * Documentation around tools to import from CVS was fairly outdated.
+
+ * "git clone --recurse-submodules" lost the progress eye-candy in
+ a recent update, which has been corrected.
+
+ * A low-level function verify_packfile() was meant to show errors
+ that were detected without dying itself, but under some conditions
+ it didn't and died instead, which has been fixed.
+
+ * When "git fetch" tries to find where the history of the repository
+ it runs in has diverged from what the other side has, it has a
+ mechanism to avoid digging too deep into irrelevant side branches.
+ This however did not work well over the "smart-http" transport due
+ to a design bug, which has been fixed.
+
+ * In the codepath that comes up with the hostname to be used in an
+ e-mail when the user didn't tell us, we looked at the ai_canonname
+ field in struct addrinfo without making sure it is not NULL first.
+
+ * "git worktree", even though it used the default_abbrev setting that
+ ought to be affected by the core.abbrev configuration variable, ignored
+ the variable setting. The command has been taught to read the
+ default set of configuration variables to correct this.
+
+ * "git init" tried to record core.worktree in the repository's
+ 'config' file when the GIT_WORK_TREE environment variable was set and
+ it was different from where GIT_DIR appears as ".git" at its top,
+ but the logic was faulty when .git is a "gitdir:" file that points
+ at the real place, causing trouble in working trees that are
+ managed by "git worktree". This has been corrected.
+
+ * Codepaths that read from an on-disk loose object were too loose in
+ validating that they are reading a proper object file and
+ sometimes read past the data they read from the disk, which has
+ been corrected. H/t to Gustavo Grieco for reporting.
+
+ * The original command line syntax for "git merge", which was "git
+ merge <msg> HEAD <parent>...", has been deprecated for quite some
+ time, and "git gui" was the last in-tree user of the syntax. This
+ is finally fixed, so that we can move forward with the deprecation.
+
+ * An author name that has a backslash-quoted double quote in the
+ human readable part ("My \"double quoted\" name"), was not unquoted
+ correctly while applying a patch from a piece of e-mail.
+
+ * Doc update to clarify what "log -3 --reverse" does.
+
+ * Almost everybody uses DEFAULT_ABBREV to refer to the default
+ setting for the abbreviation, but "git blame" peeked into
+ underlying variable bypassing the macro for no good reason.
+
+ * The "graph" API used in "git log --graph" miscounted the number of
+ output columns consumed so far when drawing a padding line, which
+ has been fixed; this did not affect any existing code as nobody
+ tried to write anything after the padding on such a line, though.
+
+ * The code that parses the format parameter of the for-each-ref command
+ has seen a micro-optimization.
+
+ * When we started to use cURL to talk to an imap server, we forgot to explicitly add
+ imap(s):// before the destination. To some folks, that didn't work
+ and the library tried to make HTTP(s) requests instead.
+
+ * The ./configure script generated from configure.ac was taught how
+ to detect support of SSL by libcurl better.
+
+ * The command-line completion script (in contrib/) learned to
+ complete "git cmd ^mas<HT>" to complete the negative end of
+ reference to "git cmd ^master".
+ (merge 49416ad22a cp/completion-negative-refs later to maint).
+
+ * The existing "git fetch --depth=<n>" option was hard to use
+ correctly when making the history of an existing shallow clone
+ deeper. A new option, "--deepen=<n>", has been added to make this
+ easier to use. "git clone" also learned "--shallow-since=<date>"
+ and "--shallow-exclude=<tag>" options to make it easier to specify
+ "I am interested only in the recent N months worth of history" and
+ "Give me only the history since that version".
+ (merge cccf74e2da nd/shallow-deepen later to maint).
+
+ * "git blame --reverse OLD path" is now DWIMmed to show how lines
+ in path in an old revision OLD have survived up to the current
+ commit.
+ (merge e1d09701a4 jc/blame-reverse later to maint).
+
+ * The http.emptyauth configuration variable is a way to allow an empty username to
+ pass when attempting to authenticate using mechanisms like
+ Kerberos. We took an unspecified (NULL) username and sent ":"
+ (i.e. no username, no password) to CURLOPT_USERPWD, but did not do
+ the same when the username is explicitly set to an empty string.
+
+ * "git clone" of a local repository can be done at the filesystem
+ level, but the codepath did not check errors while copying and
+ adjusting the file that lists alternate object stores.
+
+ * Documentation for "git commit" was updated to clarify that "commit
+ -p <paths>" adds to the current contents of the index to come up
+ with what to commit.
+
+ * A stray symbolic link in the $GIT_DIR/refs/ directory could make name
+ resolution loop forever, which has been corrected.
+
+ * The "submodule.<name>.path" stored in .gitmodules is never copied
+ to .git/config and such a key in .git/config has no meaning, but
+ the documentation described it next to submodule.<name>.url
+ as if both belong to .git/config. This has been fixed.
+
+ * In a worktree created via "git
+ worktree", "git checkout" attempts to protect users from confusion
+ by refusing to check out a branch that is already checked out in
+ another worktree. However, this also prevented checking out a
+ branch which is designated as the primary branch of a bare
+ repository, in a worktree that is connected to the bare
+ repository. The check has been corrected to allow it.
+
+ * "git rebase" immediately after "git clone" failed to find the fork
+ point from the upstream.
+
+ * When fetching from a remote that has many tags that are irrelevant
+ to branches we are following, we used to waste way too many cycles
+ checking if the object pointed at by a tag (that we are not
+ going to fetch!) exists in our repository too carefully.
+
+ * Protect our code from over-eager compilers.
+
+ * Recent git allows submodule.<name>.branch to use a special token
+ "." instead of the branch name; the documentation has been updated
+ to describe it.
+
+ * "git send-email" attempts to pick up valid e-mails from the
+ trailers, but people in the real world write non-addresses there, like
+ "Cc: Stable <add@re.ss> # 4.8+", which broke the output depending
+ on the availability and vintage of the Mail::Address perl module.
+ (merge dcfafc5214 mm/send-email-cc-cruft-after-address later to maint).
+
+ * The Travis CI configuration we ship ran the tests with the --verbose
+ option but this risks non-TAP output that happens to be "ok" to be
+ misinterpreted as TAP signalling a test that passed. This resulted
+ in unnecessary failures. This has been corrected by introducing a
+ new mode to run our tests in the test harness to send the verbose
+ output separately to the log file.
+
+ * Some AsciiDoc formatters mishandle a displayed illustration with
+ tabs in it. Adjust a few of them in merge-base documentation to
+ work around them.
+
+ * Fixed a minor regression in "git submodule" that was introduced
+ when more helper functions were reimplemented in C.
+ (merge 77b63ac31e sb/submodule-ignore-trailing-slash later to maint).
+
+ * The code that we have used for the past 10+ years to cycle
+ 4-element ring buffers turns out to be not quite portable in
+ theoretical world.
+ (merge bb84735c80 rs/ring-buffer-wraparound later to maint).
+
+ * "git daemon" used fixed-length buffers to turn URLs to the
+ repository the client asked for into the server side directory
+ paths, using snprintf() to avoid overflowing these buffers, but
+ allowed possibly truncated paths to the directory. This has been
+ tightened to reject such a request that causes an overlong path to be
+ served.
+ (merge 6bdb0083be jk/daemon-path-ok-check-truncation later to maint).
+
+ * Recent update to git-sh-setup (a library of shell functions that
+ are used by our in-tree scripted Porcelain commands) included
+ another shell library git-sh-i18n without specifying where it is,
+ relying on the $PATH. This has been fixed to be more explicit by
+ prefixing with $(git --exec-path) output.
+ (merge 1073094f30 ak/sh-setup-dot-source-i18n-fix later to maint).
+
+ * Fix for a racy false-positive test failure.
+ (merge fdf4f6c79b as/merge-attr-sleep later to maint).
+
+ * Portability update and workaround for builds on recent Mac OS X.
+ (merge a296bc0132 ls/macos-update later to maint).
+
+ * Using a %(HEAD) placeholder in "for-each-ref --format=" option
+ caused the command to segfault when on an unborn branch.
+ (merge 84679d470d jc/for-each-ref-head-segfault-fix later to maint).
+
+ * "git rebase -i" did not work well with the core.commentchar
+ configuration variable for two reasons, both of which have been
+ fixed.
+ (merge 882cd23777 js/rebase-i-commentchar-fix later to maint).
+
+ * Other minor doc, test and build updates and code cleanups.
+ (merge 5c238e29a8 jk/common-main later to maint).
+ (merge 5a5749e45b ak/pre-receive-hook-template-modefix later to maint).
+ (merge 6d834ac8f1 jk/rebase-config-insn-fmt-docfix later to maint).
+ (merge de9f7fa3b0 rs/commit-pptr-simplify later to maint).
+ (merge 4259d693fc sc/fmt-merge-msg-doc-markup-fix later to maint).
+ (merge 28fab7b23d nd/test-helpers later to maint).
+ (merge c2bb0c1d1e rs/cocci later to maint).
+ (merge 3285b7badb ps/common-info-doc later to maint).
+ (merge 2b090822e8 nd/worktree-lock later to maint).
+ (merge 4bd488ea7c jk/create-branch-remove-unused-param later to maint).
+ (merge 974e0044d6 tk/diffcore-delta-remove-unused later to maint).
diff --git a/RelNotes/2.11.1.adoc b/RelNotes/2.11.1.adoc
new file mode 100644
index 0000000..7d35cf1
--- /dev/null
+++ b/RelNotes/2.11.1.adoc
@@ -0,0 +1,168 @@
+Git v2.11.1 Release Notes
+=========================
+
+Fixes since v2.11
+-----------------
+
+ * The default Travis-CI configuration specifies newer P4 and GitLFS.
+
+ * The character width table has been updated to match Unicode 9.0
+
+ * Update the isatty() emulation for Windows by updating the previous
+ hack that depended on internals of (older) MSVC runtime.
+
+ * "git rev-parse --symbolic" failed with a more recent notation like
+ "HEAD^-1" and "HEAD^!".
+
+ * An empty directory in a working tree that can simply be nuked used
+ to interfere while merging or cherry-picking a change to create a
+ submodule directory there, which has been fixed..
+
+ * The code in "git push" to compute if any commit being pushed in the
+ superproject binds a commit in a submodule that hasn't been pushed
+ out was overly inefficient, making it unusable even for a small
+ project that does not have any submodule but have a reasonable
+ number of refs.
+
+ * "git push --dry-run --recurse-submodule=on-demand" wasn't
+ "--dry-run" in the submodules.
+
+ * The output from "git worktree list" was made in readdir() order,
+ and was unstable.
+
+ * mergetool.<tool>.trustExitCode configuration variable did not apply
+ to built-in tools, but now it does.
+
+ * "git p4" LFS support was broken when LFS stores an empty blob.
+
+ * Fix a corner case in merge-recursive regression that crept in
+ during 2.10 development cycle.
+
+ * Update the error messages from the dumb-http client when it fails
+ to obtain loose objects; we used to give sensible error message
+ only upon 404 but we now forbid unexpected redirects that needs to
+ be reported with something sensible.
+
+ * When diff.renames configuration is on (and with Git 2.9 and later,
+ it is enabled by default, which made it worse), "git stash"
+ misbehaved if a file is removed and another file with a very
+ similar content is added.
+
+ * "git diff --no-index" did not take "--no-abbrev" option.
+
+ * "git difftool --dir-diff" had a minor regression when started from
+ a subdirectory, which has been fixed.
+
+ * "git commit --allow-empty --only" (no pathspec) with dirty index
+ ought to be an acceptable way to create a new commit that does not
+ change any paths, but it was forbidden, perhaps because nobody
+ needed it so far.
+
+ * A pathname that begins with "//" or "\\" on Windows is special but
+ path normalization logic was unaware of it.
+
+ * "git pull --rebase", when there is no new commits on our side since
+ we forked from the upstream, should be able to fast-forward without
+ invoking "git rebase", but it didn't.
+
+ * The way to specify hotkeys to "xxdiff" that is used by "git
+ mergetool" has been modernized to match recent versions of xxdiff.
+
+ * Unlike "git am --abort", "git cherry-pick --abort" moved HEAD back
+ to where cherry-pick started while picking multiple changes, when
+ the cherry-pick stopped to ask for help from the user, and the user
+ did "git reset --hard" to a different commit in order to re-attempt
+ the operation.
+
+ * Code cleanup in shallow boundary computation.
+
+ * A recent update to receive-pack to make it easier to drop garbage
+ objects made it clear that GIT_ALTERNATE_OBJECT_DIRECTORIES cannot
+ have a pathname with a colon in it (no surprise!), and this in turn
+ made it impossible to push into a repository at such a path. This
+ has been fixed by introducing a quoting mechanism used when
+ appending such a path to the colon-separated list.
+
+ * The function usage_msg_opt() has been updated to say "fatal:"
+ before the custom message programs give, when they want to die
+ with a message about wrong command line options followed by the
+ standard usage string.
+
+ * "git index-pack --stdin" needs an access to an existing repository,
+ but "git index-pack file.pack" to generate an .idx file that
+ corresponds to a packfile does not.
+
+ * Fix for NDEBUG builds.
+
+ * A lazy "git push" without refspec did not internally use a fully
+ specified refspec to perform 'current', 'simple', or 'upstream'
+ push, causing unnecessary "ambiguous ref" errors.
+
+ * "git p4" misbehaved when swapping a directory and a symbolic link.
+
+ * Even though an fix was attempted in Git 2.9.3 days, but running
+ "git difftool --dir-diff" from a subdirectory never worked. This
+ has been fixed.
+
+ * "git p4" that tracks multiple p4 paths imported a single changelist
+ that touches files in these multiple paths as one commit, followed
+ by many empty commits. This has been fixed.
+
+ * A potential but unlikely buffer overflow in Windows port has been
+ fixed.
+
+ * When the http server gives an incomplete response to a smart-http
+ rpc call, it could lead to client waiting for a full response that
+ will never come. Teach the client side to notice this condition
+ and abort the transfer.
+
+ * Some platforms no longer understand "latin-1" that is still seen in
+ the wild in e-mail headers; replace them with "iso-8859-1" that is
+ more widely known when conversion fails from/to it.
+
+ * Update the procedure to generate "tags" for developer support.
+
+ * Update the definition of the MacOSX test environment used by
+ TravisCI.
+
+ * A few git-svn updates.
+
+ * Compression setting for producing packfiles were spread across
+ three codepaths, one of which did not honor any configuration.
+ Unify these so that all of them honor core.compression and
+ pack.compression variables the same way.
+
+ * "git fast-import" sometimes mishandled while rebalancing notes
+ tree, which has been fixed.
+
+ * Recent update to the default abbreviation length that auto-scales
+ lacked documentation update, which has been corrected.
+
+ * Leakage of lockfiles in the config subsystem has been fixed.
+
+ * It is natural that "git gc --auto" may not attempt to pack
+ everything into a single pack, and there is no point in warning
+ when the user has configured the system to use the pack bitmap,
+ leading to disabling further "gc".
+
+ * "git archive" did not read the standard configuration files, and
+ failed to notice a file that is marked as binary via the userdiff
+ driver configuration.
+
+ * "git blame --porcelain" misidentified the "previous" <commit, path>
+ pair (aka "source") when contents came from two or more files.
+
+ * "git rebase -i" with a recent update started showing an incorrect
+ count when squashing more than 10 commits.
+
+ * "git <cmd> @{push}" on a detached HEAD used to segfault; it has
+ been corrected to error out with a message.
+
+ * Tighten a test to avoid mistaking an extended ERE regexp engine as
+ a PRE regexp engine.
+
+ * Typing ^C to pager, which usually does not kill it, killed Git and
+ took the pager down as a collateral damage in certain process-tree
+ structure. This has been fixed.
+
+Also contains various documentation updates and code clean-ups.
diff --git a/RelNotes/2.11.2.adoc b/RelNotes/2.11.2.adoc
new file mode 100644
index 0000000..7428851
--- /dev/null
+++ b/RelNotes/2.11.2.adoc
@@ -0,0 +1,12 @@
+Git v2.11.2 Release Notes
+=========================
+
+Fixes since v2.11.1
+-------------------
+
+ * "git-shell" rejects a request to serve a repository whose name
+ begins with a dash, which makes it no longer possible to get it
+ confused into spawning service programs like "git-upload-pack" with
+ an option like "--help", which in turn would spawn an interactive
+ pager, instead of working with the repository user asked to access
+ (i.e. the one whose name is "--help").
diff --git a/RelNotes/2.11.3.adoc b/RelNotes/2.11.3.adoc
new file mode 100644
index 0000000..4e3b78d
--- /dev/null
+++ b/RelNotes/2.11.3.adoc
@@ -0,0 +1,4 @@
+Git v2.11.3 Release Notes
+=========================
+
+This release forward-ports the fix for "ssh://..." URL from Git v2.7.6
diff --git a/RelNotes/2.11.4.adoc b/RelNotes/2.11.4.adoc
new file mode 100644
index 0000000..ad4da8e
--- /dev/null
+++ b/RelNotes/2.11.4.adoc
@@ -0,0 +1,17 @@
+Git v2.11.4 Release Notes
+=========================
+
+Fixes since v2.11.3
+-------------------
+
+ * "git cvsserver" no longer is invoked by "git daemon" by default,
+ as it is old and largely unmaintained.
+
+ * Various Perl scripts did not use safe_pipe_capture() instead of
+ backticks, leaving them susceptible to end-user input. They have
+ been corrected.
+
+Credits go to joernchen <joernchen@phenoelit.de> for finding the
+unsafe constructs in "git cvsserver", and to Jeff King at GitHub for
+finding and fixing instances of the same issue in other scripts.
+
diff --git a/RelNotes/2.12.0.adoc b/RelNotes/2.12.0.adoc
new file mode 100644
index 0000000..d2f6a83
--- /dev/null
+++ b/RelNotes/2.12.0.adoc
@@ -0,0 +1,500 @@
+Git 2.12 Release Notes
+======================
+
+Backward compatibility notes.
+
+ * Use of an empty string that is used for 'everything matches' is
+ still warned and Git asks users to use a more explicit '.' for that
+ instead. The hope is that existing users will not mind this
+ change, and eventually the warning can be turned into a hard error,
+ upgrading the deprecation into removal of this (mis)feature. That
+ is not scheduled to happen in the upcoming release (yet).
+
+ * The historical argument order "git merge <msg> HEAD <commit>..."
+ has been deprecated for quite some time, and will be removed in a
+ future release.
+
+ * An ancient script "git relink" has been removed.
+
+
+Updates since v2.11
+-------------------
+
+UI, Workflows & Features
+
+ * Various updates to "git p4".
+
+ * "git p4" didn't interact with the internal of .git directory
+ correctly in the modern "git-worktree"-enabled world.
+
+ * "git branch --list" and friends learned "--ignore-case" option to
+ optionally sort branches and tags case insensitively.
+
+ * In addition to %(subject), %(body), "log --pretty=format:..."
+ learned a new placeholder %(trailers).
+
+ * "git rebase" learned "--quit" option, which allows a user to
+ remove the metadata left by an earlier "git rebase" that was
+ manually aborted without using "git rebase --abort".
+
+ * "git clone --reference $there --recurse-submodules $super" has been
+ taught to guess repositories usable as references for submodules of
+ $super that are embedded in $there while making a clone of the
+ superproject borrow objects from $there; extend the mechanism to
+ also allow submodules of these submodules to borrow repositories
+ embedded in these clones of the submodules embedded in the clone of
+ the superproject.
+
+ * Porcelain scripts written in Perl are getting internationalized.
+
+ * "git merge --continue" has been added as a synonym to "git commit"
+ to conclude a merge that has stopped due to conflicts.
+
+ * Finer-grained control of what protocols are allowed for transports
+ during clone/fetch/push have been enabled via a new configuration
+ mechanism.
+
+ * "git shortlog" learned "--committer" option to group commits by
+ committer, instead of author.
+
+ * GitLFS integration with "git p4" has been updated.
+
+ * The isatty() emulation for Windows has been updated to eradicate
+ the previous hack that depended on internals of (older) MSVC
+ runtime.
+
+ * Some platforms no longer understand "latin-1" that is still seen in
+ the wild in e-mail headers; replace them with "iso-8859-1" that is
+ more widely known when conversion fails from/to it.
+
+ * "git grep" has been taught to optionally recurse into submodules.
+
+ * "git rm" used to refuse to remove a submodule when it has its own
+ git repository embedded in its working tree. It learned to move
+ the repository away to $GIT_DIR/modules/ of the superproject
+ instead, and allow the submodule to be deleted (as long as there
+ will be no loss of local modifications, that is).
+
+ * A recent updates to "git p4" was not usable for older p4 but it
+ could be made to work with minimum changes. Do so.
+
+ * "git diff" learned diff.interHunkContext configuration variable
+ that gives the default value for its --inter-hunk-context option.
+
+ * The prereleaseSuffix feature of version comparison that is used in
+ "git tag -l" did not correctly when two or more prereleases for the
+ same release were present (e.g. when 2.0, 2.0-beta1, and 2.0-beta2
+ are there and the code needs to compare 2.0-beta1 and 2.0-beta2).
+
+ * "git submodule push" learned "--recurse-submodules=only option to
+ push submodules out without pushing the top-level superproject.
+
+ * "git tag" and "git verify-tag" learned to put GPG verification
+ status in their "--format=<placeholders>" output format.
+
+ * An ancient repository conversion tool left in contrib/ has been
+ removed.
+
+ * "git show-ref HEAD" used with "--verify" because the user is not
+ interested in seeing refs/remotes/origin/HEAD, and used with
+ "--head" because the user does not want HEAD to be filtered out,
+ i.e. "git show-ref --head --verify HEAD", did not work as expected.
+
+ * "git submodule add" used to be confused and refused to add a
+ locally created repository; users can now use "--force" option
+ to add them.
+ (merge 619acfc78c sb/submodule-add-force later to maint).
+
+ * Some people feel the default set of colors used by "git log --graph"
+ rather limiting. A mechanism to customize the set of colors has
+ been introduced.
+
+ * "git read-tree" and its underlying unpack_trees() machinery learned
+ to report problematic paths prefixed with the --super-prefix option.
+
+ * When a submodule "A", which has another submodule "B" nested within
+ it, is "absorbed" into the top-level superproject, the inner
+ submodule "B" used to be left in a strange state. The logic to
+ adjust the .git pointers in these submodules has been corrected.
+
+ * The user can specify a custom update method that is run when
+ "submodule update" updates an already checked out submodule. This
+ was ignored when checking the submodule out for the first time and
+ we instead always just checked out the commit that is bound to the
+ path in the superproject's index.
+
+ * The command line completion (in contrib/) learned that
+ "git diff --submodule=" can take "diff" as a recently added option.
+
+ * The "core.logAllRefUpdates" that used to be boolean has been
+ enhanced to take 'always' as well, to record ref updates to refs
+ other than the ones that are expected to be updated (i.e. branches,
+ remote-tracking branches and notes).
+
+ * Comes with more command line completion (in contrib/) for recently
+ introduced options.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * Commands that operate on a log message and add lines to the trailer
+ blocks, such as "format-patch -s", "cherry-pick (-x|-s)", and
+ "commit -s", have been taught to use the logic of and share the
+ code with "git interpret-trailer".
+
+ * The default Travis-CI configuration specifies newer P4 and GitLFS.
+
+ * The "fast hash" that had disastrous performance issues in some
+ corner cases has been retired from the internal diff.
+
+ * The character width table has been updated to match Unicode 9.0
+
+ * Update the procedure to generate "tags" for developer support.
+
+ * The codeflow of setting NOATIME and CLOEXEC on file descriptors Git
+ opens has been simplified.
+
+ * "git diff" and its family had two experimental heuristics to shift
+ the contents of a hunk to make the patch easier to read. One of
+ them turns out to be better than the other, so leave only the
+ "--indent-heuristic" option and remove the other one.
+
+ * A new submodule helper "git submodule embedgitdirs" to make it
+ easier to move embedded .git/ directory for submodules in a
+ superproject to .git/modules/ (and point the latter with the former
+ that is turned into a "gitdir:" file) has been added.
+
+ * "git push \\server\share\dir" has recently regressed and then
+ fixed. A test has retroactively been added for this breakage.
+
+ * Build updates for Cygwin.
+
+ * The implementation of "real_path()" was to go there with chdir(2)
+ and call getcwd(3), but this obviously wouldn't be usable in a
+ threaded environment. Rewrite it to manually resolve relative
+ paths including symbolic links in path components.
+
+ * Adjust documentation to help AsciiDoctor render better while not
+ breaking the rendering done by AsciiDoc.
+
+ * The sequencer machinery has been further enhanced so that a later
+ set of patches can start using it to reimplement "rebase -i".
+
+ * Update the definition of the MacOSX test environment used by
+ TravisCI.
+
+ * Rewrite a scripted porcelain "git difftool" in C.
+
+ * "make -C t failed" will now run only the tests that failed in the
+ previous run. This is usable only when prove is not use, and gives
+ a useless error message when run after "make clean", but otherwise
+ is serviceable.
+
+ * "uchar [40]" to "struct object_id" conversion continues.
+
+
+Also contains various documentation updates and code clean-ups.
+
+Fixes since v2.10
+-----------------
+
+Unless otherwise noted, all the fixes since v2.9 in the maintenance
+track are contained in this release (see the maintenance releases'
+notes for details).
+
+ * We often decide if a session is interactive by checking if the
+ standard I/O streams are connected to a TTY, but isatty() that
+ comes with Windows incorrectly returned true if it is used on NUL
+ (i.e. an equivalent to /dev/null). This has been fixed.
+
+ * "git svn" did not work well with path components that are "0", and
+ some configuration variable it uses were not documented.
+
+ * "git rev-parse --symbolic" failed with a more recent notation like
+ "HEAD^-1" and "HEAD^!".
+
+ * An empty directory in a working tree that can simply be nuked used
+ to interfere while merging or cherry-picking a change to create a
+ submodule directory there, which has been fixed..
+
+ * The code in "git push" to compute if any commit being pushed in the
+ superproject binds a commit in a submodule that hasn't been pushed
+ out was overly inefficient, making it unusable even for a small
+ project that does not have any submodule but have a reasonable
+ number of refs.
+
+ * "git push --dry-run --recurse-submodule=on-demand" wasn't
+ "--dry-run" in the submodules.
+
+ * The output from "git worktree list" was made in readdir() order,
+ and was unstable.
+
+ * mergetool.<tool>.trustExitCode configuration variable did not apply
+ to built-in tools, but now it does.
+
+ * "git p4" LFS support was broken when LFS stores an empty blob.
+
+ * A corner case in merge-recursive regression that crept in
+ during 2.10 development cycle has been fixed.
+
+ * Transport with dumb http can be fooled into following foreign URLs
+ that the end user does not intend to, especially with the server
+ side redirects and http-alternates mechanism, which can lead to
+ security issues. Tighten the redirection and make it more obvious
+ to the end user when it happens.
+
+ * Update the error messages from the dumb-http client when it fails
+ to obtain loose objects; we used to give sensible error message
+ only upon 404 but we now forbid unexpected redirects that needs to
+ be reported with something sensible.
+
+ * When diff.renames configuration is on (and with Git 2.9 and later,
+ it is enabled by default, which made it worse), "git stash"
+ misbehaved if a file is removed and another file with a very
+ similar content is added.
+
+ * "git diff --no-index" did not take "--no-abbrev" option.
+
+ * "git difftool --dir-diff" had a minor regression when started from
+ a subdirectory, which has been fixed.
+
+ * "git commit --allow-empty --only" (no pathspec) with dirty index
+ ought to be an acceptable way to create a new commit that does not
+ change any paths, but it was forbidden, perhaps because nobody
+ needed it so far.
+
+ * Git 2.11 had a minor regression in "merge --ff-only" that competed
+ with another process that simultaneously attempted to update the
+ index. We used to explain what went wrong with an error message,
+ but the new code silently failed. The error message has been
+ resurrected.
+
+ * A pathname that begins with "//" or "\\" on Windows is special but
+ path normalization logic was unaware of it.
+
+ * "git pull --rebase", when there is no new commits on our side since
+ we forked from the upstream, should be able to fast-forward without
+ invoking "git rebase", but it didn't.
+
+ * The way to specify hotkeys to "xxdiff" that is used by "git
+ mergetool" has been modernized to match recent versions of xxdiff.
+
+ * Unlike "git am --abort", "git cherry-pick --abort" moved HEAD back
+ to where cherry-pick started while picking multiple changes, when
+ the cherry-pick stopped to ask for help from the user, and the user
+ did "git reset --hard" to a different commit in order to re-attempt
+ the operation.
+
+ * Code cleanup in shallow boundary computation.
+
+ * A recent update to receive-pack to make it easier to drop garbage
+ objects made it clear that GIT_ALTERNATE_OBJECT_DIRECTORIES cannot
+ have a pathname with a colon in it (no surprise!), and this in turn
+ made it impossible to push into a repository at such a path. This
+ has been fixed by introducing a quoting mechanism used when
+ appending such a path to the colon-separated list.
+
+ * The function usage_msg_opt() has been updated to say "fatal:"
+ before the custom message programs give, when they want to die
+ with a message about wrong command line options followed by the
+ standard usage string.
+
+ * "git index-pack --stdin" needs an access to an existing repository,
+ but "git index-pack file.pack" to generate an .idx file that
+ corresponds to a packfile does not.
+
+ * Fix for NDEBUG builds.
+
+ * A lazy "git push" without refspec did not internally use a fully
+ specified refspec to perform 'current', 'simple', or 'upstream'
+ push, causing unnecessary "ambiguous ref" errors.
+
+ * "git p4" misbehaved when swapping a directory and a symbolic link.
+
+ * Even though an fix was attempted in Git 2.9.3 days, but running
+ "git difftool --dir-diff" from a subdirectory never worked. This
+ has been fixed.
+
+ * "git p4" that tracks multiple p4 paths imported a single changelist
+ that touches files in these multiple paths as one commit, followed
+ by many empty commits. This has been fixed.
+
+ * A potential but unlikely buffer overflow in Windows port has been
+ fixed.
+
+ * When the http server gives an incomplete response to a smart-http
+ rpc call, it could lead to client waiting for a full response that
+ will never come. Teach the client side to notice this condition
+ and abort the transfer.
+
+ * Compression setting for producing packfiles were spread across
+ three codepaths, one of which did not honor any configuration.
+ Unify these so that all of them honor core.compression and
+ pack.compression variables the same way.
+
+ * "git fast-import" sometimes mishandled while rebalancing notes
+ tree, which has been fixed.
+
+ * Recent update to the default abbreviation length that auto-scales
+ lacked documentation update, which has been corrected.
+
+ * Leakage of lockfiles in the config subsystem has been fixed.
+
+ * It is natural that "git gc --auto" may not attempt to pack
+ everything into a single pack, and there is no point in warning
+ when the user has configured the system to use the pack bitmap,
+ leading to disabling further "gc".
+
+ * "git archive" did not read the standard configuration files, and
+ failed to notice a file that is marked as binary via the userdiff
+ driver configuration.
+
+ * "git blame --porcelain" misidentified the "previous" <commit, path>
+ pair (aka "source") when contents came from two or more files.
+
+ * "git rebase -i" with a recent update started showing an incorrect
+ count when squashing more than 10 commits.
+
+ * "git <cmd> @{push}" on a detached HEAD used to segfault; it has
+ been corrected to error out with a message.
+
+ * Running "git add a/b" when "a" is a submodule correctly errored
+ out, but without a meaningful error message.
+ (merge 2d81c48fa7 sb/pathspec-errors later to maint).
+
+ * Typing ^C to pager, which usually does not kill it, killed Git and
+ took the pager down as a collateral damage in certain process-tree
+ structure. This has been fixed.
+
+ * "git mergetool" without any pathspec on the command line that is
+ run from a subdirectory became no-op in Git v2.11 by mistake, which
+ has been fixed.
+
+ * Retire long unused/unmaintained gitview from the contrib/ area.
+ (merge 3120925c25 sb/remove-gitview later to maint).
+
+ * Tighten a test to avoid mistaking an extended ERE regexp engine as
+ a PRE regexp engine.
+
+ * An error message with an ASCII control character like '\r' in it
+ can alter the message to hide its early part, which is problematic
+ when a remote side gives such an error message that the local side
+ will relay with a "remote: " prefix.
+ (merge f290089879 jk/vreport-sanitize later to maint).
+
+ * "git fsck" inspects loose objects more carefully now.
+ (merge cce044df7f jk/loose-object-fsck later to maint).
+
+ * A crashing bug introduced in v2.11 timeframe has been found (it is
+ triggerable only in fast-import) and fixed.
+ (merge abd5a00268 jk/clear-delta-base-cache-fix later to maint).
+
+ * With an anticipatory tweak for remotes defined in ~/.gitconfig
+ (e.g. "remote.origin.prune" set to true, even though there may or
+ may not actually be "origin" remote defined in a particular Git
+ repository), "git remote rename" and other commands misinterpreted
+ and behaved as if such a non-existing remote actually existed.
+ (merge e459b073fb js/remote-rename-with-half-configured-remote later to maint).
+
+ * A few codepaths had to rely on a global variable when sorting
+ elements of an array because sort(3) API does not allow extra data
+ to be passed to the comparison function. Use qsort_s() when
+ natively available, and a fallback implementation of it when not,
+ to eliminate the need, which is a prerequisite for making the
+ codepath reentrant.
+
+ * "git fsck --connectivity-check" was not working at all.
+ (merge a2b22854bd jk/fsck-connectivity-check-fix later to maint).
+
+ * After starting "git rebase -i", which first opens the user's editor
+ to edit the series of patches to apply, but before saving the
+ contents of that file, "git status" failed to show the current
+ state (i.e. you are in an interactive rebase session, but you have
+ applied no steps yet) correctly.
+ (merge df9ded4984 js/status-pre-rebase-i later to maint).
+
+ * Test tweak for FreeBSD where /usr/bin/unzip is unsuitable to run
+ our tests but /usr/local/bin/unzip is usable.
+ (merge d98b2c5fce js/unzip-in-usr-bin-workaround later to maint).
+
+ * "git p4" did not work well with multiple git-p4.mapUser entries on
+ Windows.
+ (merge c3c2b05776 gv/mingw-p4-mapuser later to maint).
+
+ * "git help" enumerates executable files in $PATH; the implementation
+ of "is this file executable?" on Windows has been optimized.
+ (merge c755015f79 hv/mingw-help-is-executable later to maint).
+
+ * Test tweaks for those who have default ACL in their git source tree
+ that interfere with the umask test.
+ (merge d549d21307 mm/reset-facl-before-umask-test later to maint).
+
+ * Names of the various hook scripts must be spelled exactly, but on
+ Windows, an .exe binary must be named with .exe suffix; notice
+ $GIT_DIR/hooks/<hookname>.exe as a valid <hookname> hook.
+ (merge 235be51fbe js/mingw-hooks-with-exe-suffix later to maint).
+
+ * Asciidoctor, an alternative reimplementation of AsciiDoc, still
+ needs some changes to work with documents meant to be formatted
+ with AsciiDoc. "make USE_ASCIIDOCTOR=YesPlease" to use it out of
+ the box to document our pages is getting closer to reality.
+
+ * Correct command line completion (in contrib/) on "git svn"
+ (merge 2cbad17642 ew/complete-svn-authorship-options later to maint).
+
+ * Incorrect usage help message for "git worktree prune" has been fixed.
+ (merge 2488dcab22 ps/worktree-prune-help-fix later to maint).
+
+ * Adjust a perf test to new world order where commands that do
+ require a repository are really strict about having a repository.
+ (merge c86000c1a7 rs/p5302-create-repositories-before-tests later to maint).
+
+ * "git log --graph" did not work well with "--name-only", even though
+ other forms of "diff" output were handled correctly.
+ (merge f5022b5fed jk/log-graph-name-only later to maint).
+
+ * The push-options given via the "--push-options" option were not
+ passed through to external remote helpers such as "smart HTTP" that
+ are invoked via the transport helper.
+
+ * The documentation explained what "git stash" does to the working
+ tree (after stashing away the local changes) in terms of "reset
+ --hard", which was exposing an unnecessary implementation detail.
+ (merge 20a7e06172 tg/stash-doc-cleanup later to maint).
+
+ * When "git p4" imports changelist that removes paths, it failed to
+ convert pathnames when the p4 used encoding different from the one
+ used on the Git side. This has been corrected.
+ (merge a8b05162e8 ls/p4-path-encoding later to maint).
+
+ * A new coccinelle rule that catches a check of !pointer before the
+ pointer is free(3)d, which most likely is a bug.
+ (merge ec6cd14c7a rs/cocci-check-free-only-null later to maint).
+
+ * "ls-files" run with pathspec has been micro-optimized to avoid
+ having to memmove(3) unnecessary bytes.
+ (merge 96f6d3f61a rs/ls-files-partial-optim later to maint).
+
+ * A hotfix for a topic already in 'master'.
+ (merge a4d92d579f js/mingw-isatty later to maint).
+
+ * Other minor doc, test and build updates and code cleanups.
+ (merge f2627d9b19 sb/submodule-config-cleanup later to maint).
+ (merge 384f1a167b sb/unpack-trees-cleanup later to maint).
+ (merge 874444b704 rh/diff-orderfile-doc later to maint).
+ (merge eafd5d9483 cw/doc-sign-off later to maint).
+ (merge 0aaad415bc rs/absolute-pathdup later to maint).
+ (merge 4432dd6b5b rs/receive-pack-cleanup later to maint).
+ (merge 540a398e9c sg/mailmap-self later to maint).
+ (merge 209df269a6 nd/rev-list-all-includes-HEAD-doc later to maint).
+ (merge 941b9c5270 sb/doc-unify-bottom later to maint).
+ (merge 2aaf37b62c jk/doc-remote-helpers-markup-fix later to maint).
+ (merge e91461b332 jk/doc-submodule-markup-fix later to maint).
+ (merge 8ab9740d9f dp/submodule-doc-markup-fix later to maint).
+ (merge 0838cbc22f jk/tempfile-ferror-fclose-confusion later to maint).
+ (merge 115a40add6 dr/doc-check-ref-format-normalize later to maint).
+ (merge 133f0a299d gp/document-dotfiles-in-templates-are-not-copied later to maint).
+ (merge 2b35a9f4c7 bc/blame-doc-fix later to maint).
+ (merge 7e82388024 ps/doc-gc-aggressive-depth-update later to maint).
+ (merge 9993a7c5f1 bc/worktree-doc-fix-detached later to maint).
+ (merge e519eccdf4 rt/align-add-i-help-text later to maint).
diff --git a/RelNotes/2.12.1.adoc b/RelNotes/2.12.1.adoc
new file mode 100644
index 0000000..a74f7db
--- /dev/null
+++ b/RelNotes/2.12.1.adoc
@@ -0,0 +1,41 @@
+Git v2.12.1 Release Notes
+=========================
+
+Fixes since v2.12
+-----------------
+
+ * Reduce authentication round-trip over HTTP when the server supports
+ just a single authentication method. This also improves the
+ behaviour when Git is misconfigured to enable http.emptyAuth
+ against a server that does not authenticate without a username
+ (i.e. not using Kerberos etc., which makes http.emptyAuth
+ pointless).
+
+ * Windows port wants to use OpenSSL's implementation of SHA-1
+ routines, so let them.
+
+ * Add 32-bit Linux variant to the set of platforms to be tested with
+ Travis CI.
+
+ * When a redirected http transport gets an error during the
+ redirected request, we ignored the error we got from the server,
+ and ended up giving a not-so-useful error message.
+
+ * The patch subcommand of "git add -i" was meant to have paths
+ selection prompt just like other subcommand, unlike "git add -p"
+ directly jumps to hunk selection. Recently, this was broken and
+ "add -i" lost the paths selection dialog, but it now has been
+ fixed.
+
+ * Git v2.12 was shipped with an embarrassing breakage where various
+ operations that verify paths given from the user stopped dying when
+ seeing an issue, and instead later triggering segfault.
+
+ * The code to parse "git log -L..." command line was buggy when there
+ are many ranges specified with -L; overrun of the allocated buffer
+ has been fixed.
+
+ * The command-line parsing of "git log -L" copied internal data
+ structures using incorrect size on ILP32 systems.
+
+Also contains various documentation updates and code clean-ups.
diff --git a/RelNotes/2.12.2.adoc b/RelNotes/2.12.2.adoc
new file mode 100644
index 0000000..4419397
--- /dev/null
+++ b/RelNotes/2.12.2.adoc
@@ -0,0 +1,83 @@
+Git v2.12.2 Release Notes
+=========================
+
+Fixes since v2.12.1
+-------------------
+
+ * "git status --porcelain" is supposed to give a stable output, but a
+ few strings were left as translatable by mistake.
+
+ * "Dumb http" transport used to misparse a nonsense http-alternates
+ response, which has been fixed.
+
+ * "git diff --quiet" relies on the size field in diff_filespec to be
+ correctly populated, but diff_populate_filespec() helper function
+ made an incorrect short-cut when asked only to populate the size
+ field for paths that need to go through convert_to_git() (e.g. CRLF
+ conversion).
+
+ * There is no need for Python only to give a few messages to the
+ standard error stream, but we somehow did.
+
+ * A leak in a codepath to read from a packed object in (rare) cases
+ has been plugged.
+
+ * "git upload-pack", which is a counter-part of "git fetch", did not
+ report a request for a ref that was not advertised as invalid.
+ This is generally not a problem (because "git fetch" will stop
+ before making such a request), but is the right thing to do.
+
+ * A "gc.log" file left by a backgrounded "gc --auto" disables further
+ automatic gc; it has been taught to run at least once a day (by
+ default) by ignoring a stale "gc.log" file that is too old.
+
+ * "git remote rm X", when a branch has remote X configured as the
+ value of its branch.*.remote, tried to remove branch.*.remote and
+ branch.*.merge and failed if either is unset.
+
+ * A caller of tempfile API that uses stdio interface to write to
+ files may ignore errors while writing, which is detected when
+ tempfile is closed (with a call to ferror()). By that time, the
+ original errno that may have told us what went wrong is likely to
+ be long gone and was overwritten by an irrelevant value.
+ close_tempfile() now resets errno to EIO to make errno at least
+ predictable.
+
+ * "git show-branch" expected there were only very short branch names
+ in the repository and used a fixed-length buffer to hold them
+ without checking for overflow.
+
+ * The code that parses header fields in the commit object has been
+ updated for (micro)performance and code hygiene.
+
+ * A test that creates a confusing branch whose name is HEAD has been
+ corrected not to do so.
+
+ * "Cc:" on the trailer part does not have to conform to RFC strictly,
+ unlike in the e-mail header. "git send-email" has been updated to
+ ignore anything after '>' when picking addresses, to allow non-address
+ cruft like " # stable 4.4" after the address.
+
+ * "git push" had a handful of codepaths that could lead to a deadlock
+ when unexpected error happened, which has been fixed.
+
+ * Code to read submodule.<name>.ignore config did not state the
+ variable name correctly when giving an error message diagnosing
+ misconfiguration.
+
+ * "git ls-remote" and "git archive --remote" are designed to work
+ without being in a directory under Git's control. However, recent
+ updates revealed that we randomly look into a directory called
+ .git/ without actually doing necessary set-up when working in a
+ repository. Stop doing so.
+
+ * The code to parse the command line "git grep <patterns>... <rev>
+ [[--] <pathspec>...]" has been cleaned up, and a handful of bugs
+ have been fixed (e.g. we used to check "--" if it is a rev).
+
+ * The code to parse "git -c VAR=VAL cmd" and set configuration
+ variable for the duration of cmd had two small bugs, which have
+ been fixed.
+ This supersedes jc/config-case-cmdline topic that has been discarded.
+
+Also contains various documentation updates and code clean-ups.
diff --git a/RelNotes/2.12.3.adoc b/RelNotes/2.12.3.adoc
new file mode 100644
index 0000000..ebca846
--- /dev/null
+++ b/RelNotes/2.12.3.adoc
@@ -0,0 +1,64 @@
+Git v2.12.3 Release Notes
+=========================
+
+Fixes since v2.12.2
+-------------------
+
+ * The "parse_config_key()" API function has been cleaned up.
+
+ * An helper function to make it easier to append the result from
+ real_path() to a strbuf has been added.
+
+ * The t/perf performance test suite was not prepared to test not so
+ old versions of Git, but now it covers versions of Git that are not
+ so ancient.
+
+ * Picking two versions of Git and running tests to make sure the
+ older one and the newer one interoperate happily has now become
+ possible.
+
+ * Teach the "debug" helper used in the test framework that allows a
+ command to run under "gdb" to make the session interactive.
+
+ * "git repack --depth=<n>" for a long time busted the specified depth
+ when reusing delta from existing packs. This has been corrected.
+
+ * user.email that consists of only cruft chars should consistently
+ error out, but didn't.
+
+ * A few tests were run conditionally under (rare) conditions where
+ they cannot be run (like running cvs tests under 'root' account).
+
+ * "git branch @" created refs/heads/@ as a branch, and in general the
+ code that handled @{-1} and @{upstream} was a bit too loose in
+ disambiguating.
+
+ * "git fetch" that requests a commit by object name, when the other
+ side does not allow such an request, failed without much
+ explanation.
+
+ * "git filter-branch --prune-empty" drops a single-parent commit that
+ becomes a no-op, but did not drop a root commit whose tree is empty.
+
+ * Recent versions of Git treats http alternates (used in dumb http
+ transport) just like HTTP redirects and requires the client to
+ enable following it, due to security concerns. But we forgot to
+ give a warning when we decide not to honor the alternates.
+
+ * NO_PTHREADS build has been broken for some time; now fixed.
+
+ * Fix for potential segv introduced in v2.11.0 and later (also
+ v2.10.2).
+
+ * A few unterminated here documents in tests were fixed, which in
+ turn revealed incorrect expectations the tests make. These tests
+ have been updated.
+
+ * "git-shell" rejects a request to serve a repository whose name
+ begins with a dash, which makes it no longer possible to get it
+ confused into spawning service programs like "git-upload-pack" with
+ an option like "--help", which in turn would spawn an interactive
+ pager, instead of working with the repository user asked to access
+ (i.e. the one whose name is "--help").
+
+Also contains various documentation updates and code clean-ups.
diff --git a/RelNotes/2.12.4.adoc b/RelNotes/2.12.4.adoc
new file mode 100644
index 0000000..3f56938
--- /dev/null
+++ b/RelNotes/2.12.4.adoc
@@ -0,0 +1,4 @@
+Git v2.12.4 Release Notes
+=========================
+
+This release forward-ports the fix for "ssh://..." URL from Git v2.7.6
diff --git a/RelNotes/2.12.5.adoc b/RelNotes/2.12.5.adoc
new file mode 100644
index 0000000..8fa73cf
--- /dev/null
+++ b/RelNotes/2.12.5.adoc
@@ -0,0 +1,17 @@
+Git v2.12.5 Release Notes
+=========================
+
+Fixes since v2.12.4
+-------------------
+
+ * "git cvsserver" no longer is invoked by "git daemon" by default,
+ as it is old and largely unmaintained.
+
+ * Various Perl scripts did not use safe_pipe_capture() instead of
+ backticks, leaving them susceptible to end-user input. They have
+ been corrected.
+
+Credits go to joernchen <joernchen@phenoelit.de> for finding the
+unsafe constructs in "git cvsserver", and to Jeff King at GitHub for
+finding and fixing instances of the same issue in other scripts.
+
diff --git a/RelNotes/2.13.0.adoc b/RelNotes/2.13.0.adoc
new file mode 100644
index 0000000..2a47b4c
--- /dev/null
+++ b/RelNotes/2.13.0.adoc
@@ -0,0 +1,618 @@
+Git 2.13 Release Notes
+======================
+
+Backward compatibility notes.
+
+ * Use of an empty string as a pathspec element that is used for
+ 'everything matches' is still warned and Git asks users to use a
+ more explicit '.' for that instead. The hope is that existing
+ users will not mind this change, and eventually the warning can be
+ turned into a hard error, upgrading the deprecation into removal of
+ this (mis)feature. That is not scheduled to happen in the upcoming
+ release (yet).
+
+ * The historical argument order "git merge <msg> HEAD <commit>..."
+ has been deprecated for quite some time, and is now removed.
+
+ * The default location "~/.git-credential-cache/socket" for the
+ socket used to communicate with the credential-cache daemon has
+ been moved to "~/.cache/git/credential/socket".
+
+ * Git now avoids blindly falling back to ".git" when the setup
+ sequence said we are _not_ in Git repository. A corner case that
+ happens to work right now may be broken by a call to die("BUG").
+ We've tried hard to locate such cases and fixed them, but there
+ might still be cases that need to be addressed--bug reports are
+ greatly appreciated.
+
+
+Updates since v2.12
+-------------------
+
+UI, Workflows & Features
+
+ * "git describe" and "git name-rev" have been taught to take more
+ than one refname patterns to restrict the set of refs to base their
+ naming output on, and also learned to take negative patterns to
+ name refs not to be used for naming via their "--exclude" option.
+
+ * Deletion of a branch "foo/bar" could remove .git/refs/heads/foo
+ once there no longer is any other branch whose name begins with
+ "foo/", but we didn't do so so far. Now we do.
+
+ * When "git merge" detects a path that is renamed in one history
+ while the other history deleted (or modified) it, it now reports
+ both paths to help the user understand what is going on in the two
+ histories being merged.
+
+ * The <url> part in "http.<url>.<variable>" configuration variable
+ can now be spelled with '*' that serves as wildcard.
+ E.g. "http.https://*.example.com.proxy" can be used to specify the
+ proxy used for https://a.example.com, https://b.example.com, etc.,
+ i.e. any host in the example.com domain.
+
+ * "git tag" did not leave useful message when adding a new entry to
+ reflog; this was left unnoticed for a long time because refs/tags/*
+ doesn't keep reflog by default.
+
+ * The "negative" pathspec feature was somewhat more cumbersome to use
+ than necessary in that its short-hand used "!" which needed to be
+ escaped from shells, and it required "exclude from what?" specified.
+
+ * The command line options for ssh invocation needs to be tweaked for
+ some implementations of SSH (e.g. PuTTY plink wants "-P <port>"
+ while OpenSSH wants "-p <port>" to specify port to connect to), and
+ the variant was guessed when GIT_SSH environment variable is used
+ to specify it. The logic to guess now applies to the command
+ specified by the newer GIT_SSH_COMMAND and also core.sshcommand
+ configuration variable, and comes with an escape hatch for users to
+ deal with misdetected cases.
+
+ * The "--git-path", "--git-common-dir", and "--shared-index-path"
+ options of "git rev-parse" did not produce usable output. They are
+ now updated to show the path to the correct file, relative to where
+ the caller is.
+
+ * "git diff -W" has been taught to handle the case where a new
+ function is added at the end of the file better.
+
+ * "git update-ref -d" and other operations to delete references did
+ not leave any entry in HEAD's reflog when the reference being
+ deleted was the current branch. This is not a problem in practice
+ because you do not want to delete the branch you are currently on,
+ but caused renaming of the current branch to something else not to
+ be logged in a useful way.
+
+ * "Cc:" on the trailer part does not have to conform to RFC strictly,
+ unlike in the e-mail header. "git send-email" has been updated to
+ ignore anything after '>' when picking addresses, to allow non-address
+ cruft like " # stable 4.4" after the address.
+
+ * When "git submodule init" decides that the submodule in the working
+ tree is its upstream, it now gives a warning as it is not a very
+ common setup.
+
+ * "git stash push" takes a pathspec so that the local changes can be
+ stashed away only partially.
+
+ * Documentation for "git ls-files" did not refer to core.quotePath.
+
+ * The experimental "split index" feature has gained a few
+ configuration variables to make it easier to use.
+
+ * From a working tree of a repository, a new option of "rev-parse"
+ lets you ask if the repository is used as a submodule of another
+ project, and where the root level of the working tree of that
+ project (i.e. your superproject) is.
+
+ * The pathspec mechanism learned to further limit the paths that
+ match the pattern to those that have specified attributes attached
+ via the gitattributes mechanism.
+
+ * Our source code has used the SHA1_HEADER cpp macro after "#include"
+ in the C code to switch among the SHA-1 implementations. Instead,
+ list the exact header file names and switch among implementations
+ using "#ifdef BLK_SHA1/#include "block-sha1/sha1.h"/.../#endif";
+ this helps some IDE tools.
+
+ * The start-up sequence of "git" needs to figure out some configured
+ settings before it finds and set itself up in the location of the
+ repository and was quite messy due to its "chicken-and-egg" nature.
+ The code has been restructured.
+
+ * The command line prompt (in contrib/) learned a new 'tag' style
+ that can be specified with GIT_PS1_DESCRIBE_STYLE, to describe a
+ detached HEAD with "git describe --tags".
+
+ * The configuration file learned a new "includeIf.<condition>.path"
+ that includes the contents of the given path only when the
+ condition holds. This allows you to say "include this work-related
+ bit only in the repositories under my ~/work/ directory".
+
+ * Recent update to "rebase -i" started showing a message that is not
+ a warning with "warning:" prefix by mistake. This has been fixed.
+
+ * Recently we started passing the "--push-options" through the
+ external remote helper interface; now the "smart HTTP" remote
+ helper understands what to do with the passed information.
+
+ * "git describe --dirty" dies when it cannot be determined if the
+ state in the working tree matches that of HEAD (e.g. broken
+ repository or broken submodule). The command learned a new option
+ "git describe --broken" to give "$name-broken" (where $name is the
+ description of HEAD) in such a case.
+
+ * "git checkout" is taught the "--recurse-submodules" option.
+
+ * Recent enhancement to "git stash push" command to support pathspec
+ to allow only a subset of working tree changes to be stashed away
+ was found to be too chatty and exposed the internal implementation
+ detail (e.g. when it uses reset to match the index to HEAD before
+ doing other things, output from reset seeped out). These, and
+ other chattyness has been fixed.
+
+ * "git merge <message> HEAD <commit>" syntax that has been deprecated
+ since October 2007 has been removed.
+
+ * The refs completion for large number of refs has been sped up,
+ partly by giving up disambiguating ambiguous refs and partly by
+ eliminating most of the shell processing between 'git for-each-ref'
+ and 'ls-remote' and Bash's completion facility.
+
+ * On many keyboards, typing "@{" involves holding down SHIFT key and
+ one can easily end up with "@{Up..." when typing "@{upstream}". As
+ the upstream/push keywords do not appear anywhere else in the syntax,
+ we can safely accept them case insensitively without introducing
+ ambiguity or confusion to solve this.
+
+ * "git tag/branch/for-each-ref" family of commands long allowed to
+ filter the refs by "--contains X" (show only the refs that are
+ descendants of X), "--merged X" (show only the refs that are
+ ancestors of X), "--no-merged X" (show only the refs that are not
+ ancestors of X). One curious omission, "--no-contains X" (show
+ only the refs that are not descendants of X) has been added to
+ them.
+
+ * The default behaviour of "git log" in an interactive session has
+ been changed to enable "--decorate".
+
+ * The output from "git status --short" has been extended to show
+ various kinds of dirtiness in submodules differently; instead of to
+ "M" for modified, 'm' and '?' can be shown to signal changes only
+ to the working tree of the submodule but not the commit that is
+ checked out.
+
+ * Allow the http.postbuffer configuration variable to be set to a
+ size that can be expressed in size_t, which can be larger than
+ ulong on some platforms.
+
+ * "git rebase" learns "--signoff" option.
+
+ * The completion script (in contrib/) learned to complete "git push
+ --delete b<TAB>" to complete branch name to be deleted.
+
+ * "git worktree add --lock" allows to lock a worktree immediately
+ after it's created. This helps prevent a race between "git worktree
+ add; git worktree lock" and "git worktree prune".
+
+ * Completion for "git checkout <branch>" that auto-creates the branch
+ out of a remote tracking branch can now be disabled, as this
+ completion often gets in the way when completing to checkout an
+ existing local branch that happens to share the same prefix with
+ bunch of remote tracking branches.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * The code to list branches in "git branch" has been consolidated
+ with the more generic ref-filter API.
+
+ * Resource usage while enumerating refs from alternate object store
+ has been optimized to help receiving end of "push" that hosts a
+ repository with many "forks".
+
+ * The gitattributes machinery is being taught to work better in a
+ multi-threaded environment.
+
+ * "git rebase -i" starts using the recently updated "sequencer" code.
+
+ * Code and design clean-up for the refs API.
+
+ * The preload-index code has been taught not to bother with the index
+ entries that are paths that are not checked out by "sparse checkout".
+
+ * Some warning() messages from "git clean" were updated to show the
+ errno from failed system calls.
+
+ * The "parse_config_key()" API function has been cleaned up.
+
+ * A test that creates a confusing branch whose name is HEAD has been
+ corrected not to do so.
+
+ * The code that parses header fields in the commit object has been
+ updated for (micro)performance and code hygiene.
+
+ * An helper function to make it easier to append the result from
+ real_path() to a strbuf has been added.
+
+ * Reduce authentication round-trip over HTTP when the server supports
+ just a single authentication method. This also improves the
+ behaviour when Git is misconfigured to enable http.emptyAuth
+ against a server that does not authenticate without a username
+ (i.e. not using Kerberos etc., which makes http.emptyAuth
+ pointless).
+
+ * Windows port wants to use OpenSSL's implementation of SHA-1
+ routines, so let them.
+
+ * The t/perf performance test suite was not prepared to test not so
+ old versions of Git, but now it covers versions of Git that are not
+ so ancient.
+
+ * Add 32-bit Linux variant to the set of platforms to be tested with
+ Travis CI.
+
+ * "git branch --list" takes the "--abbrev" and "--no-abbrev" options
+ to control the output of the object name in its "-v"(erbose)
+ output, but a recent update started ignoring them; fix it before
+ the breakage reaches to any released version.
+
+ * Picking two versions of Git and running tests to make sure the
+ older one and the newer one interoperate happily has now become
+ possible.
+
+ * "git tag --contains" used to (ab)use the object bits to keep track
+ of the state of object reachability without clearing them after
+ use; this has been cleaned up and made to use the newer commit-slab
+ facility.
+
+ * The "debug" helper used in the test framework learned to run
+ a command under "gdb" interactively.
+
+ * The "detect attempt to create collisions" variant of SHA-1
+ implementation by Marc Stevens (CWI) and Dan Shumow (Microsoft)
+ has been integrated and made the default.
+
+ * The test framework learned to detect unterminated here documents.
+
+ * The name-hash used for detecting paths that are different only in
+ cases (which matter on case insensitive filesystems) has been
+ optimized to take advantage of multi-threading when it makes sense.
+
+ * An earlier version of sha1dc/sha1.c that was merged to 'master'
+ compiled incorrectly on Windows, which has been fixed.
+
+ * "what URL do we want to update this submodule?" and "are we
+ interested in this submodule?" are split into two distinct
+ concepts, and then the way used to express the latter got extended,
+ paving a way to make it easier to manage a project with many
+ submodules and make it possible to later extend use of multiple
+ worktrees for a project with submodules.
+
+ * Some debugging output from "git describe" were marked for l10n,
+ but some weren't. Mark missing ones for l10n.
+
+ * Define a new task in .travis.yml that triggers a test session on
+ Windows run elsewhere.
+
+ * Conversion from uchar[20] to struct object_id continues.
+
+ * The "submodule" specific field in the ref_store structure is
+ replaced with a more generic "gitdir" that can later be used also
+ when dealing with ref_store that represents the set of refs visible
+ from the other worktrees.
+
+ * The string-list API used a custom reallocation strategy that was
+ very inefficient, instead of using the usual ALLOC_GROW() macro,
+ which has been fixed.
+ (merge 950a234cbd jh/string-list-micro-optim later to maint).
+
+ * In a 2- and 3-way merge of trees, more than one source trees often
+ end up sharing an identical subtree; optimize by not reading the
+ same tree multiple times in such a case.
+ (merge d12a8cf0af jh/unpack-trees-micro-optim later to maint).
+
+ * The index file has a trailing SHA-1 checksum to detect file
+ corruption, and historically we checked it every time the index
+ file is used. Omit the validation during normal use, and instead
+ verify only in "git fsck".
+
+ * Having a git command on the upstream side of a pipe in a test
+ script will hide the exit status from the command, which may cause
+ us to fail to notice a breakage; rewrite tests in a script to avoid
+ this issue.
+
+ * Travis CI learns to run coccicheck.
+
+ * "git checkout" that handles a lot of paths has been optimized by
+ reducing the number of unnecessary checks of paths in the
+ has_dir_name() function.
+
+ * The internals of the refs API around the cached refs has been
+ streamlined.
+
+ * Output from perf tests have been updated to align their titles.
+
+Also contains various documentation updates and code clean-ups.
+
+
+Fixes since v2.12
+-----------------
+
+Unless otherwise noted, all the fixes since v2.12 in the maintenance
+track are contained in this release (see the maintenance releases'
+notes for details).
+
+ * "git repack --depth=<n>" for a long time busted the specified depth
+ when reusing delta from existing packs. This has been corrected.
+
+ * The code to parse the command line "git grep <patterns>... <rev>
+ [[--] <pathspec>...]" has been cleaned up, and a handful of bugs
+ have been fixed (e.g. we used to check "--" if it is a rev).
+
+ * "git ls-remote" and "git archive --remote" are designed to work
+ without being in a directory under Git's control. However, recent
+ updates revealed that we randomly look into a directory called
+ .git/ without actually doing necessary set-up when working in a
+ repository. Stop doing so.
+
+ * "git show-branch" expected there were only very short branch names
+ in the repository and used a fixed-length buffer to hold them
+ without checking for overflow.
+
+ * A caller of tempfile API that uses stdio interface to write to
+ files may ignore errors while writing, which is detected when
+ tempfile is closed (with a call to ferror()). By that time, the
+ original errno that may have told us what went wrong is likely to
+ be long gone and was overwritten by an irrelevant value.
+ close_tempfile() now resets errno to EIO to make errno at least
+ predictable.
+
+ * "git remote rm X", when a branch has remote X configured as the
+ value of its branch.*.remote, tried to remove branch.*.remote and
+ branch.*.merge and failed if either is unset.
+
+ * A "gc.log" file left by a backgrounded "gc --auto" disables further
+ automatic gc; it has been taught to run at least once a day (by
+ default) by ignoring a stale "gc.log" file that is too old.
+
+ * The code to parse "git -c VAR=VAL cmd" and set configuration
+ variable for the duration of cmd had two small bugs, which have
+ been fixed.
+
+ * user.email that consists of only cruft chars should consistently
+ error out, but didn't.
+
+ * "git upload-pack", which is a counter-part of "git fetch", did not
+ report a request for a ref that was not advertised as invalid.
+ This is generally not a problem (because "git fetch" will stop
+ before making such a request), but is the right thing to do.
+
+ * A leak in a codepath to read from a packed object in (rare) cases
+ has been plugged.
+
+ * When a redirected http transport gets an error during the
+ redirected request, we ignored the error we got from the server,
+ and ended up giving a not-so-useful error message.
+
+ * The patch subcommand of "git add -i" was meant to have paths
+ selection prompt just like other subcommand, unlike "git add -p"
+ directly jumps to hunk selection. Recently, this was broken and
+ "add -i" lost the paths selection dialog, but it now has been
+ fixed.
+
+ * Git v2.12 was shipped with an embarrassing breakage where various
+ operations that verify paths given from the user stopped dying when
+ seeing an issue, and instead later triggering segfault.
+
+ * There is no need for Python only to give a few messages to the
+ standard error stream, but we somehow did.
+
+ * The code to parse "git log -L..." command line was buggy when there
+ are many ranges specified with -L; overrun of the allocated buffer
+ has been fixed.
+
+ * The command-line parsing of "git log -L" copied internal data
+ structures using incorrect size on ILP32 systems.
+
+ * "git diff --quiet" relies on the size field in diff_filespec to be
+ correctly populated, but diff_populate_filespec() helper function
+ made an incorrect short-cut when asked only to populate the size
+ field for paths that need to go through convert_to_git() (e.g. CRLF
+ conversion).
+
+ * A few tests were run conditionally under (rare) conditions where
+ they cannot be run (like running cvs tests under 'root' account).
+
+ * "git branch @" created refs/heads/@ as a branch, and in general the
+ code that handled @{-1} and @{upstream} was a bit too loose in
+ disambiguating.
+
+ * "git fetch" that requests a commit by object name, when the other
+ side does not allow such an request, failed without much
+ explanation.
+
+ * "git filter-branch --prune-empty" drops a single-parent commit that
+ becomes a no-op, but did not drop a root commit whose tree is empty.
+
+ * Recent versions of Git treats http alternates (used in dumb http
+ transport) just like HTTP redirects and requires the client to
+ enable following it, due to security concerns. But we forgot to
+ give a warning when we decide not to honor the alternates.
+
+ * "git push" had a handful of codepaths that could lead to a deadlock
+ when unexpected error happened, which has been fixed.
+
+ * "Dumb http" transport used to misparse a nonsense http-alternates
+ response, which has been fixed.
+
+ * "git add -p <pathspec>" unnecessarily expanded the pathspec to a
+ list of individual files that matches the pathspec by running "git
+ ls-files <pathspec>", before feeding it to "git diff-index" to see
+ which paths have changes, because historically the pathspec
+ language supported by "diff-index" was weaker. These days they are
+ equivalent and there is no reason to internally expand it. This
+ helps both performance and avoids command line argument limit on
+ some platforms.
+ (merge 7288e12cce jk/add-i-use-pathspecs later to maint).
+
+ * "git status --porcelain" is supposed to give a stable output, but a
+ few strings were left as translatable by mistake.
+
+ * "git revert -m 0 $merge_commit" complained that reverting a merge
+ needs to say relative to which parent the reversion needs to
+ happen, as if "-m 0" weren't given. The correct diagnosis is that
+ "-m 0" does not refer to the first parent ("-m 1" does). This has
+ been fixed.
+
+ * Code to read submodule.<name>.ignore config did not state the
+ variable name correctly when giving an error message diagnosing
+ misconfiguration.
+
+ * Fix for NO_PTHREADS build.
+
+ * Fix for potential segv introduced in v2.11.0 and later (also
+ v2.10.2) to "git log --pickaxe-regex -S".
+
+ * A few unterminated here documents in tests were fixed, which in
+ turn revealed incorrect expectations the tests make. These tests
+ have been updated.
+
+ * Fix for NO_PTHREADS option.
+ (merge 2225e1ea20 bw/grep-recurse-submodules later to maint).
+
+ * Git now avoids blindly falling back to ".git" when the setup
+ sequence said we are _not_ in Git repository. A corner case that
+ happens to work right now may be broken by a call to die("BUG").
+ (merge b1ef400eec jk/no-looking-at-dotgit-outside-repo-final later to maint).
+
+ * A few commands that recently learned the "--recurse-submodule"
+ option misbehaved when started from a subdirectory of the
+ superproject.
+ (merge b2dfeb7c00 bw/recurse-submodules-relative-fix later to maint).
+
+ * FreeBSD implementation of getcwd(3) behaved differently when an
+ intermediate directory is unreadable/unsearchable depending on the
+ length of the buffer provided, which our strbuf_getcwd() was not
+ aware of. strbuf_getcwd() has been taught to cope with it better.
+ (merge a54e938e5b rs/freebsd-getcwd-workaround later to maint).
+
+ * A recent update to "rebase -i" stopped running hooks for the "git
+ commit" command during "reword" action, which has been fixed.
+
+ * Removing an entry from a notes tree and then looking another note
+ entry from the resulting tree using the internal notes API
+ functions did not work as expected. No in-tree users of the API
+ has such access pattern, but it still is worth fixing.
+
+ * "git receive-pack" could have been forced to die by attempting
+ allocate an unreasonably large amount of memory with a crafted push
+ certificate; this has been fixed.
+ (merge f2214dede9 bc/push-cert-receive-fix later to maint).
+
+ * Update error handling for codepath that deals with corrupt loose
+ objects.
+ (merge 51054177b3 jk/loose-object-info-report-error later to maint).
+
+ * "git diff --submodule=diff" learned to work better in a project
+ with a submodule that in turn has its own submodules.
+ (merge 17b254cda6 sb/show-diff-for-submodule-in-diff-fix later to maint).
+
+ * Update the build dependency so that an update to /usr/bin/perl
+ etc. result in recomputation of perl.mak file.
+ (merge c59c4939c2 ab/regen-perl-mak-with-different-perl later to maint).
+
+ * "git push --recurse-submodules --push-option=<string>" learned to
+ propagate the push option recursively down to pushes in submodules.
+
+ * If a patch e-mail had its first paragraph after an in-body header
+ indented (even after a blank line after the in-body header line),
+ the indented line was mistook as a continuation of the in-body
+ header. This has been fixed.
+ (merge fd1062e52e lt/mailinfo-in-body-header-continuation later to maint).
+
+ * Clean up fallouts from recent tightening of the set-up sequence,
+ where Git barfs when repository information is accessed without
+ first ensuring that it was started in a repository.
+ (merge bccb22cbb1 jk/no-looking-at-dotgit-outside-repo later to maint).
+
+ * "git p4" used "name-rev HEAD" when it wants to learn what branch is
+ checked out; it should use "symbolic-ref HEAD".
+ (merge eff451101d ld/p4-current-branch-fix later to maint).
+
+ * "http.proxy" set to an empty string is used to disable the usage of
+ proxy. We broke this early last year.
+ (merge ae51d91105 sr/http-proxy-configuration-fix later to maint).
+
+ * $GIT_DIR may in some cases be normalized with all symlinks resolved
+ while "gitdir" path expansion in the pattern does not receive the
+ same treatment, leading to incorrect mismatch. This has been fixed.
+
+ * "git submodule" script does not work well with strange pathnames.
+ Protect it from a path with slashes in them, at least.
+
+ * "git fetch-pack" was not prepared to accept ERR packet that the
+ upload-pack can send with a human-readable error message. It
+ showed the packet contents with ERR prefix, so there was no data
+ loss, but it was redundant to say "ERR" in an error message.
+ (merge 8e2c7bef03 jt/fetch-pack-error-reporting later to maint).
+
+ * "ls-files --recurse-submodules" did not quite work well in a
+ project with nested submodules.
+
+ * gethostname(2) may not NUL terminate the buffer if hostname does
+ not fit; unfortunately there is no easy way to see if our buffer
+ was too small, but at least this will make sure we will not end up
+ using garbage past the end of the buffer.
+ (merge 5781a9a270 dt/xgethostname-nul-termination later to maint).
+
+ * A recent update broke "git add -p ../foo" from a subdirectory.
+
+ * While handy, "git_path()" is a dangerous function to use as a
+ callsite that uses it safely one day can be broken by changes
+ to other code that calls it. Reduction of its use continues.
+ (merge 16d2676c9e jk/war-on-git-path later to maint).
+
+ * The split-index code configuration code used an unsafe git_path()
+ function without copying its result out.
+
+ * Many stale HTTP(s) links have been updated in our documentation.
+ (merge 613416f0be jk/update-links-in-docs later to maint).
+
+ * "git-shell" rejects a request to serve a repository whose name
+ begins with a dash, which makes it no longer possible to get it
+ confused into spawning service programs like "git-upload-pack" with
+ an option like "--help", which in turn would spawn an interactive
+ pager, instead of working with the repository user asked to access
+ (i.e. the one whose name is "--help").
+
+ * Other minor doc, test and build updates and code cleanups.
+ (merge df2a6e38b7 jk/pager-in-use later to maint).
+ (merge 75ec4a6cb0 ab/branch-list-doc later to maint).
+ (merge 3e5b36c637 sg/skip-prefix-in-prettify-refname later to maint).
+ (merge 2c5e2865cc jk/fast-import-cleanup later to maint).
+ (merge 4473060bc2 ab/test-readme-updates later to maint).
+ (merge 48a96972fd ab/doc-submitting later to maint).
+ (merge f5c2bc2b96 jk/make-coccicheck-detect-errors later to maint).
+ (merge c105f563d1 cc/untracked later to maint).
+ (merge 8668976b53 jc/unused-symbols later to maint).
+ (merge fba275dc93 jc/bs-t-is-not-a-tab-for-sed later to maint).
+ (merge be6ed145de mm/ls-files-s-doc later to maint).
+ (merge 60b091c679 qp/bisect-docfix later to maint).
+ (merge 47242cd103 ah/diff-files-ours-theirs-doc later to maint).
+ (merge 35ad44cbd8 sb/submodule-rm-absorb later to maint).
+ (merge 0301f1fd92 va/i18n-perl-scripts later to maint).
+ (merge 733e064d98 vn/revision-shorthand-for-side-branch-log later to maint).
+ (merge 85999743e7 tb/doc-eol-normalization later to maint).
+ (merge 0747fb49fd jk/loose-object-fsck later to maint).
+ (merge d8f4481c4f jk/quarantine-received-objects later to maint).
+ (merge 7ba1ceef95 xy/format-patch-base later to maint).
+ (merge fa1912c89a rs/misc-cppcheck-fixes later to maint).
+ (merge f17d642d3b ab/push-cas-doc-n-test later to maint).
+ (merge 61e282425a ss/gitmodules-ignore-doc later to maint).
+ (merge 8d3047cd5b ss/submodule-shallow-doc later to maint).
+ (merge 1f9e18b772 jk/prio-queue-avoid-swap-with-self later to maint).
+ (merge 627fde1025 jk/submodule-init-segv-fix later to maint).
+ (merge d395745d81 rg/doc-pull-typofix later to maint).
+ (merge 01e60a9a22 rg/doc-submittingpatches-wordfix later to maint).
+ (merge 501d3cd7b8 sr/hooks-cwd-doc later to maint).
diff --git a/RelNotes/2.13.1.adoc b/RelNotes/2.13.1.adoc
new file mode 100644
index 0000000..ed7cd97
--- /dev/null
+++ b/RelNotes/2.13.1.adoc
@@ -0,0 +1,114 @@
+Git v2.13.1 Release Notes
+=========================
+
+Fixes since v2.13
+-----------------
+
+ * The Web interface to gmane news archive is long gone, even though
+ the articles are still accessible via NTTP. Replace the links with
+ ones to public-inbox.org. Because their message identification is
+ based on the actual message-id, it is likely that it will be easier
+ to migrate away from it if/when necessary.
+
+ * Update tests to pass under GETTEXT_POISON (a mechanism to ensure
+ that output strings that should not be translated are not
+ translated by mistake), and tell TravisCI to run them.
+
+ * Setting "log.decorate=false" in the configuration file did not take
+ effect in v2.13, which has been corrected.
+
+ * An earlier update to test 7400 needed to be skipped on CYGWIN.
+
+ * Git sometimes gives an advice in a rhetorical question that does
+ not require an answer, which can confuse new users and non native
+ speakers. Attempt to rephrase them.
+
+ * "git read-tree -m" (no tree-ish) gave a nonsense suggestion "use
+ --empty if you want to clear the index". With "-m", such a request
+ will still fail anyway, as you'd need to name at least one tree-ish
+ to be merged.
+
+ * The codepath in "git am" that is used when running "git rebase"
+ leaked memory held for the log message of the commits being rebased.
+
+ * "pack-objects" can stream a slice of an existing packfile out when
+ the pack bitmap can tell that the reachable objects are all needed
+ in the output, without inspecting individual objects. This
+ strategy however would not work well when "--local" and other
+ options are in use, and need to be disabled.
+
+ * Clarify documentation for include.path and includeIf.<condition>.path
+ configuration variables.
+
+ * Tag objects, which are not reachable from any ref, that point at
+ missing objects were mishandled by "git gc" and friends (they
+ should silently be ignored instead)
+
+ * A few http:// links that are redirected to https:// in the
+ documentation have been updated to https:// links.
+
+ * Make sure our tests would pass when the sources are checked out
+ with "platform native" line ending convention by default on
+ Windows. Some "text" files out tests use and the test scripts
+ themselves that are meant to be run with /bin/sh, ought to be
+ checked out with eol=LF even on Windows.
+
+ * Fix memory leaks pointed out by Coverity (and people).
+
+ * The receive-pack program now makes sure that the push certificate
+ records the same set of push options used for pushing.
+
+ * "git cherry-pick" and other uses of the sequencer machinery
+ mishandled a trailer block whose last line is an incomplete line.
+ This has been fixed so that an additional sign-off etc. are added
+ after completing the existing incomplete line.
+
+ * The shell completion script (in contrib/) learned "git stash" has
+ a new "push" subcommand.
+
+ * Travis CI gained a task to format the documentation with both
+ AsciiDoc and AsciiDoctor.
+
+ * Update the C style recommendation for notes for translators, as
+ recent versions of gettext tools can work with our style of
+ multi-line comments.
+
+ * "git clone --config var=val" is a way to populate the
+ per-repository configuration file of the new repository, but it did
+ not work well when val is an empty string. This has been fixed.
+
+ * A few codepaths in "checkout" and "am" working on an unborn branch
+ tried to access an uninitialized piece of memory.
+
+ * "git for-each-ref --format=..." with %(HEAD) in the format used to
+ resolve the HEAD symref as many times as it had processed refs,
+ which was wasteful, and "git branch" shared the same problem.
+
+ * "git interpret-trailers", when used as GIT_EDITOR for "git commit
+ -v", looked for and appended to a trailer block at the very end,
+ i.e. at the end of the "diff" output. The command has been
+ corrected to pay attention to the cut-mark line "commit -v" adds to
+ the buffer---the real trailer block should appear just before it.
+
+ * A test allowed both "git push" and "git receive-pack" on the other
+ end write their traces into the same file. This is OK on platforms
+ that allows atomically appending to a file opened with O_APPEND,
+ but on other platforms led to a mangled output, causing
+ intermittent test failures. This has been fixed by disabling
+ traces from "receive-pack" in the test.
+
+ * "foo\bar\baz" in "git fetch foo\bar\baz", even though there is no
+ slashes in it, cannot be a nickname for a remote on Windows, as
+ that is likely to be a pathname on a local filesystem.
+
+ * The "collision detecting" SHA-1 implementation shipped with 2.13
+ was quite broken on some big-endian platforms and/or platforms that
+ do not like unaligned fetches. Update to the upstream code which
+ has already fixed these issues.
+
+ * "git am -h" triggered a BUG().
+
+ * The interaction of "url.*.insteadOf" and custom URL scheme's
+ whitelisting is now documented better.
+
+Also contains various documentation updates and code clean-ups.
diff --git a/RelNotes/2.13.2.adoc b/RelNotes/2.13.2.adoc
new file mode 100644
index 0000000..8c2b200
--- /dev/null
+++ b/RelNotes/2.13.2.adoc
@@ -0,0 +1,54 @@
+Git v2.13.2 Release Notes
+=========================
+
+Fixes since v2.13.1
+-------------------
+
+ * The "collision detecting" SHA-1 implementation shipped with 2.13.1
+ was still broken on some platforms. Update to the upstream code
+ again to take their fix.
+
+ * "git checkout --recurse-submodules" did not quite work with a
+ submodule that itself has submodules.
+
+ * Introduce the BUG() macro to improve die("BUG: ...").
+
+ * The "run-command" API implementation has been made more robust
+ against dead-locking in a threaded environment.
+
+ * A recent update to t5545-push-options.sh started skipping all the
+ tests in the script when a web server testing is disabled or
+ unavailable, not just the ones that require a web server. Non HTTP
+ tests have been salvaged to always run in this script.
+
+ * "git clean -d" used to clean directories that has ignored files,
+ even though the command should not lose ignored ones without "-x".
+ "git status --ignored" did not list ignored and untracked files
+ without "-uall". These have been corrected.
+
+ * The timestamp of the index file is now taken after the file is
+ closed, to help Windows, on which a stale timestamp is reported by
+ fstat() on a file that is opened for writing and data was written
+ but not yet closed.
+
+ * "git pull --rebase --autostash" didn't auto-stash when the local history
+ fast-forwards to the upstream.
+
+ * "git describe --contains" penalized light-weight tags so much that
+ they were almost never considered. Instead, give them about the
+ same chance to be considered as an annotated tag that is the same
+ age as the underlying commit would.
+
+ * The result from "git diff" that compares two blobs, e.g. "git diff
+ $commit1:$path $commit2:$path", used to be shown with the full
+ object name as given on the command line, but it is more natural to
+ use the $path in the output and use it to look up .gitattributes.
+
+ * A flaky test has been corrected.
+
+ * Help contributors that visit us at GitHub.
+
+ * "git stash push <pathspec>" did not work from a subdirectory at all.
+ Bugfix for a topic in v2.13
+
+Also contains various documentation updates and code clean-ups.
diff --git a/RelNotes/2.13.3.adoc b/RelNotes/2.13.3.adoc
new file mode 100644
index 0000000..384e4de
--- /dev/null
+++ b/RelNotes/2.13.3.adoc
@@ -0,0 +1,62 @@
+Git v2.13.3 Release Notes
+=========================
+
+Fixes since v2.13.2
+-------------------
+
+ * The "collision detecting" SHA-1 implementation shipped with 2.13.2
+ was still broken on some platforms. Update to the upstream code
+ again to take their fix.
+
+ * The 'diff-highlight' program (in contrib/) has been restructured
+ for easier reuse by an external project 'diff-so-fancy'.
+
+ * "git mergetool" learned to work around a wrapper MacOS X adds
+ around underlying meld.
+
+ * An example in documentation that does not work in multi worktree
+ configuration has been corrected.
+
+ * The pretty-format specifiers like '%h', '%t', etc. had an
+ optimization that no longer works correctly. In preparation/hope
+ of getting it correctly implemented, first discard the optimization
+ that is broken.
+
+ * The code to pick up and execute command alias definition from the
+ configuration used to switch to the top of the working tree and
+ then come back when the expanded alias was executed, which was
+ unnecessarily complex. Attempt to simplify the logic by using the
+ early-config mechanism that does not chdir around.
+
+ * "git add -p" were updated in 2.12 timeframe to cope with custom
+ core.commentchar but the implementation was buggy and a
+ metacharacter like $ and * did not work.
+
+ * Fix a recent regression to "git rebase -i" and add tests that would
+ have caught it and others.
+
+ * An unaligned 32-bit access in pack-bitmap code has been corrected.
+
+ * Tighten error checks for invalid "git apply" input.
+
+ * The split index code did not honor core.sharedrepository setting
+ correctly.
+
+ * The Makefile rule in contrib/subtree for building documentation
+ learned to honour USE_ASCIIDOCTOR just like the main documentation
+ set does.
+
+ * A few tests that tried to verify the contents of push certificates
+ did not use 'git rev-parse' to formulate the line to look for in
+ the certificate correctly.
+
+ * After "git branch --move" of the currently checked out branch, the
+ code to walk the reflog of HEAD via "log -g" and friends
+ incorrectly stopped at the reflog entry that records the renaming
+ of the branch.
+
+ * The rewrite of "git branch --list" using for-each-ref's internals
+ that happened in v2.13 regressed its handling of color.branch.local;
+ this has been fixed.
+
+Also contains various documentation updates and code clean-ups.
diff --git a/RelNotes/2.13.4.adoc b/RelNotes/2.13.4.adoc
new file mode 100644
index 0000000..9a9f8f9
--- /dev/null
+++ b/RelNotes/2.13.4.adoc
@@ -0,0 +1,28 @@
+Git v2.13.4 Release Notes
+=========================
+
+Fixes since v2.13.3
+-------------------
+
+ * Update the character width tables.
+
+ * A recent update broke an alias that contained an uppercase letter,
+ which has been fixed.
+
+ * On Cygwin, similar to Windows, "git push //server/share/repository"
+ ought to mean a repository on a network share that can be accessed
+ locally, but this did not work correctly due to stripping the double
+ slashes at the beginning.
+
+ * The progress meter did not give a useful output when we haven't had
+ 0.5 seconds to measure the throughput during the interval. Instead
+ show the overall throughput rate at the end, which is a much more
+ useful number.
+
+ * We run an early part of "git gc" that deals with refs before
+ daemonising (and not under lock) even when running a background
+ auto-gc, which caused multiple gc processes attempting to run the
+ early part at the same time. This is now prevented by running the
+ early part also under the GC lock.
+
+Also contains a handful of small code and documentation clean-ups.
diff --git a/RelNotes/2.13.5.adoc b/RelNotes/2.13.5.adoc
new file mode 100644
index 0000000..6949fcd
--- /dev/null
+++ b/RelNotes/2.13.5.adoc
@@ -0,0 +1,4 @@
+Git v2.13.5 Release Notes
+=========================
+
+This release forward-ports the fix for "ssh://..." URL from Git v2.7.6
diff --git a/RelNotes/2.13.6.adoc b/RelNotes/2.13.6.adoc
new file mode 100644
index 0000000..afcae9c
--- /dev/null
+++ b/RelNotes/2.13.6.adoc
@@ -0,0 +1,17 @@
+Git v2.13.6 Release Notes
+=========================
+
+Fixes since v2.13.5
+-------------------
+
+ * "git cvsserver" no longer is invoked by "git daemon" by default,
+ as it is old and largely unmaintained.
+
+ * Various Perl scripts did not use safe_pipe_capture() instead of
+ backticks, leaving them susceptible to end-user input. They have
+ been corrected.
+
+Credits go to joernchen <joernchen@phenoelit.de> for finding the
+unsafe constructs in "git cvsserver", and to Jeff King at GitHub for
+finding and fixing instances of the same issue in other scripts.
+
diff --git a/RelNotes/2.13.7.adoc b/RelNotes/2.13.7.adoc
new file mode 100644
index 0000000..09fc014
--- /dev/null
+++ b/RelNotes/2.13.7.adoc
@@ -0,0 +1,20 @@
+Git v2.13.7 Release Notes
+=========================
+
+Fixes since v2.13.6
+-------------------
+
+ * Submodule "names" come from the untrusted .gitmodules file, but we
+ blindly append them to $GIT_DIR/modules to create our on-disk repo
+ paths. This means you can do bad things by putting "../" into the
+ name. We now enforce some rules for submodule names which will cause
+ Git to ignore these malicious names (CVE-2018-11235).
+
+ Credit for finding this vulnerability and the proof of concept from
+ which the test script was adapted goes to Etienne Stalmans.
+
+ * It was possible to trick the code that sanity-checks paths on NTFS
+ into reading random piece of memory (CVE-2018-11233).
+
+Credit for fixing for these bugs goes to Jeff King, Johannes
+Schindelin and others.
diff --git a/RelNotes/2.14.0.adoc b/RelNotes/2.14.0.adoc
new file mode 100644
index 0000000..2711a25
--- /dev/null
+++ b/RelNotes/2.14.0.adoc
@@ -0,0 +1,517 @@
+Git 2.14 Release Notes
+======================
+
+Backward compatibility notes and other notable changes.
+
+ * Use of an empty string as a pathspec element that is used for
+ 'everything matches' is still warned and Git asks users to use a
+ more explicit '.' for that instead. The hope is that existing
+ users will not mind this change, and eventually the warning can be
+ turned into a hard error, upgrading the deprecation into removal of
+ this (mis)feature. That is not scheduled to happen in the upcoming
+ release (yet).
+
+ * Git now avoids blindly falling back to ".git" when the setup
+ sequence said we are _not_ in Git repository. A corner case that
+ happens to work right now may be broken by a call to die("BUG").
+ We've tried hard to locate such cases and fixed them, but there
+ might still be cases that need to be addressed--bug reports are
+ greatly appreciated.
+
+ * The experiment to improve the hunk-boundary selection of textual
+ diff output has finished, and the "indent heuristics" has now
+ become the default.
+
+ * Git can now be built with PCRE v2 instead of v1 of the PCRE
+ library. Replace USE_LIBPCRE=YesPlease with USE_LIBPCRE2=YesPlease
+ in existing build scripts to build against the new version. As the
+ upstream PCRE maintainer has abandoned v1 maintenance for all but
+ the most critical bug fixes, use of v2 is recommended.
+
+
+Updates since v2.13
+-------------------
+
+UI, Workflows & Features
+
+ * The colors in which "git status --short --branch" showed the names
+ of the current branch and its remote-tracking branch are now
+ configurable.
+
+ * "git clone" learned the "--no-tags" option not to fetch all tags
+ initially, and also set up the tagopt not to follow any tags in
+ subsequent fetches.
+
+ * "git archive --format=zip" learned to use zip64 extension when
+ necessary to go beyond the 4GB limit.
+
+ * "git reset" learned "--recurse-submodules" option.
+
+ * "git diff --submodule=diff" now recurses into nested submodules.
+
+ * "git repack" learned to accept the --threads=<n> option and pass it
+ to pack-objects.
+
+ * "git send-email" learned to run sendemail-validate hook to inspect
+ and reject a message before sending it out.
+
+ * There is no good reason why "git fetch $there $sha1" should fail
+ when the $sha1 names an object at the tip of an advertised ref,
+ even when the other side hasn't enabled allowTipSHA1InWant.
+
+ * The "[includeIf "gitdir:$dir"] path=..." mechanism introduced in
+ 2.13.0 would canonicalize the path of the gitdir being matched,
+ and did not match e.g. "gitdir:~/work/*" against a repo in
+ "~/work/main" if "~/work" was a symlink to "/mnt/storage/work".
+ Now we match both the resolved canonical path and what "pwd" would
+ show. The include will happen if either one matches.
+
+ * The "indent" heuristics is now the default in "diff". The
+ diff.indentHeuristic configuration variable can be set to "false"
+ for those who do not want it.
+
+ * Many commands learned to pay attention to submodule.recurse
+ configuration.
+
+ * The convention for a command line is to follow "git cmdname
+ --options" with revisions followed by an optional "--"
+ disambiguator and then finally pathspecs. When "--" is not there,
+ we make sure early ones are all interpretable as revs (and do not
+ look like paths) and later ones are the other way around. A
+ pathspec with "magic" (e.g. ":/p/a/t/h" that matches p/a/t/h from
+ the top-level of the working tree, no matter what subdirectory you
+ are working from) are conservatively judged as "not a path", which
+ required disambiguation more often. The command line parser
+ learned to say "it's a pathspec" a bit more often when the syntax
+ looks like so.
+
+ * Update "perl-compatible regular expression" support to enable JIT
+ and also allow linking with the newer PCRE v2 library.
+
+ * "filter-branch" learned a pseudo filter "--setup" that can be used
+ to define common functions/variables that can be used by other
+ filters.
+
+ * Using "git add d/i/r" when d/i/r is the top of the working tree of
+ a separate repository would create a gitlink in the index, which
+ would appear as a not-quite-initialized submodule to others. We
+ learned to give warnings when this happens.
+
+ * "git status" learned to optionally give how many stash entries there
+ are in its output.
+
+ * "git status" has long shown essentially the same message as "git
+ commit"; the message it gives while preparing for the root commit,
+ i.e. "Initial commit", was hard to understand for some new users.
+ Now it says "No commits yet" to stress more on the current status
+ (rather than the commit the user is preparing for, which is more in
+ line with the focus of "git commit").
+
+ * "git send-email" now has --batch-size and --relogin-delay options
+ which can be used to overcome limitations on SMTP servers that
+ restrict on how many of e-mails can be sent in a single session.
+
+ * An old message shown in the commit log template was removed, as it
+ has outlived its usefulness.
+
+ * "git pull --rebase --recurse-submodules" learns to rebase the
+ branch in the submodules to an updated base.
+
+ * "git log" learned -P as a synonym for --perl-regexp, "git grep"
+ already had such a synonym.
+
+ * "git log" didn't understand --regexp-ignore-case when combined with
+ --perl-regexp. This has been fixed.
+
+Performance, Internal Implementation, Development Support etc.
+
+ * The default packed-git limit value has been raised on larger
+ platforms to save "git fetch" from a (recoverable) failure while
+ "gc" is running in parallel.
+
+ * Code to update the cache-tree has been tightened so that we won't
+ accidentally write out any 0{40} entry in the tree object.
+
+ * Attempt to allow us notice "fishy" situation where we fail to
+ remove the temporary directory used during the test.
+
+ * Travis CI gained a task to format the documentation with both
+ AsciiDoc and AsciiDoctor.
+
+ * Some platforms have ulong that is smaller than time_t, and our
+ historical use of ulong for timestamp would mean they cannot
+ represent some timestamp that the platform allows. Invent a
+ separate and dedicated timestamp_t (so that we can distinguish
+ timestamps and a vanilla ulongs, which along is already a good
+ move), and then declare uintmax_t is the type to be used as the
+ timestamp_t.
+
+ * We can trigger Windows auto-build tester (credits: Dscho &
+ Microsoft) from our existing Travis CI tester now.
+
+ * Conversion from uchar[20] to struct object_id continues.
+
+ * Simplify parse_pathspec() codepath and stop it from looking at the
+ default in-core index.
+
+ * Add perf-test for wildmatch.
+
+ * Code from "conversion using external process" codepath has been
+ extracted to a separate sub-process.[ch] module.
+
+ * When "git checkout", "git merge", etc. manipulates the in-core
+ index, various pieces of information in the index extensions are
+ discarded from the original state, as it is usually not the case
+ that they are kept up-to-date and in-sync with the operation on the
+ main index. The untracked cache extension is copied across these
+ operations now, which would speed up "git status" (as long as the
+ cache is properly invalidated).
+
+ * The internal implementation of "git grep" has seen some clean-up.
+
+ * Update the C style recommendation for notes for translators, as
+ recent versions of gettext tools can work with our style of
+ multi-line comments.
+
+ * The implementation of "ref" API around the "packed refs" have been
+ cleaned up, in preparation for further changes.
+
+ * The internal logic used in "git blame" has been libified to make it
+ easier to use by cgit.
+
+ * Our code often opens a path to an optional file, to work on its
+ contents when we can successfully open it. We can ignore a failure
+ to open if such an optional file does not exist, but we do want to
+ report a failure in opening for other reasons (e.g. we got an I/O
+ error, or the file is there, but we lack the permission to open).
+
+ The exact errors we need to ignore are ENOENT (obviously) and
+ ENOTDIR (less obvious). Instead of repeating comparison of errno
+ with these two constants, introduce a helper function to do so.
+
+ * We often try to open a file for reading whose existence is
+ optional, and silently ignore errors from open/fopen; report such
+ errors if they are not due to missing files.
+
+ * When an existing repository is used for t/perf testing, we first
+ create bit-for-bit copy of it, which may grab a transient state of
+ the repository and freeze it into the repository used for testing,
+ which then may cause Git operations to fail. Single out "the index
+ being locked" case and forcibly drop the lock from the copy.
+
+ * Three instances of the same helper function have been consolidated
+ to one.
+
+ * "fast-import" uses a default pack chain depth that is consistent
+ with other parts of the system.
+
+ * A new test to show the interaction between the pattern [^a-z]
+ (which matches '/') and a slash in a path has been added. The
+ pattern should not match the slash with "pathmatch", but should
+ with "wildmatch".
+
+ * The 'diff-highlight' program (in contrib/) has been restructured
+ for easier reuse by an external project 'diff-so-fancy'.
+
+ * A common pattern to free a piece of memory and assign NULL to the
+ pointer that used to point at it has been replaced with a new
+ FREE_AND_NULL() macro.
+
+ * Traditionally, the default die() routine had a code to prevent it
+ from getting called multiple times, which interacted badly when a
+ threaded program used it (one downside is that the real error may
+ be hidden and instead the only error message given to the user may
+ end up being "die recursion detected", which is not very useful).
+
+ * Introduce a "repository" object to eventually make it easier to
+ work in multiple repositories (the primary focus is to work with
+ the superproject and its submodules) in a single process.
+
+ * Optimize "what are the object names already taken in an alternate
+ object database?" query that is used to derive the length of prefix
+ an object name is uniquely abbreviated to.
+
+ * The hashmap API has been updated so that data to customize the
+ behaviour of the comparison function can be specified at the time a
+ hashmap is initialized.
+
+ * The "collision detecting" SHA-1 implementation shipped with 2.13 is
+ now integrated into git.git as a submodule (the first submodule to
+ ship with git.git). Clone git.git with --recurse-submodules to get
+ it. For now a non-submodule copy of the same code is also shipped
+ as part of the tree.
+
+ * A recent update made it easier to use "-fsanitize=" option while
+ compiling but supported only one sanitize option. Allow more than
+ one to be combined, joined with a comma, like "make SANITIZE=foo,bar".
+
+ * Use "p4 -G" to make "p4 changes" output more Python-friendly
+ to parse.
+
+ * We started using "%" PRItime, imitating "%" PRIuMAX and friends, as
+ a way to format the internal timestamp value, but this does not
+ play well with gettext(1) i18n framework, and causes "make pot"
+ that is run by the l10n coordinator to create a broken po/git.pot
+ file. This is a possible workaround for that problem.
+
+ * It turns out that Cygwin also needs the fopen() wrapper that
+ returns failure when a directory is opened for reading.
+
+Also contains various documentation updates and code clean-ups.
+
+
+Fixes since v2.13
+-----------------
+
+Unless otherwise noted, all the fixes since v2.13 in the maintenance
+track are contained in this release (see the maintenance releases'
+notes for details).
+
+ * "git gc" did not interact well with "git worktree"-managed
+ per-worktree refs.
+
+ * "git cherry-pick" and other uses of the sequencer machinery
+ mishandled a trailer block whose last line is an incomplete line.
+ This has been fixed so that an additional sign-off etc. are added
+ after completing the existing incomplete line.
+
+ * The codepath in "git am" that is used when running "git rebase"
+ leaked memory held for the log message of the commits being rebased.
+
+ * "git clone --config var=val" is a way to populate the
+ per-repository configuration file of the new repository, but it did
+ not work well when val is an empty string. This has been fixed.
+
+ * Setting "log.decorate=false" in the configuration file did not take
+ effect in v2.13, which has been corrected.
+
+ * A few codepaths in "checkout" and "am" working on an unborn branch
+ tried to access an uninitialized piece of memory.
+
+ * The Web interface to gmane news archive is long gone, even though
+ the articles are still accessible via NTTP. Replace the links with
+ ones to public-inbox.org. Because their message identification is
+ based on the actual message-id, it is likely that it will be easier
+ to migrate away from it if/when necessary.
+
+ * The receive-pack program now makes sure that the push certificate
+ records the same set of push options used for pushing.
+
+ * Tests have been updated to pass under GETTEXT_POISON (a mechanism
+ to ensure that output strings that should not be translated are
+ not translated by mistake), and TravisCI is told to run them.
+
+ * "git checkout --recurse-submodules" did not quite work with a
+ submodule that itself has submodules.
+
+ * "pack-objects" can stream a slice of an existing packfile out when
+ the pack bitmap can tell that the reachable objects are all needed
+ in the output, without inspecting individual objects. This
+ strategy however would not work well when "--local" and other
+ options are in use, and need to be disabled.
+
+ * Fix memory leaks pointed out by Coverity (and people).
+
+ * "git read-tree -m" (no tree-ish) gave a nonsense suggestion "use
+ --empty if you want to clear the index". With "-m", such a request
+ will still fail anyway, as you'd need to name at least one tree-ish
+ to be merged.
+
+ * Make sure our tests would pass when the sources are checked out
+ with "platform native" line ending convention by default on
+ Windows. Some "text" files out tests use and the test scripts
+ themselves that are meant to be run with /bin/sh, ought to be
+ checked out with eol=LF even on Windows.
+
+ * Introduce the BUG() macro to improve die("BUG: ...").
+
+ * Clarify documentation for include.path and includeIf.<condition>.path
+ configuration variables.
+
+ * Git sometimes gives an advice in a rhetorical question that does
+ not require an answer, which can confuse new users and non native
+ speakers. Attempt to rephrase them.
+
+ * A few http:// links that are redirected to https:// in the
+ documentation have been updated to https:// links.
+
+ * "git for-each-ref --format=..." with %(HEAD) in the format used to
+ resolve the HEAD symref as many times as it had processed refs,
+ which was wasteful, and "git branch" shared the same problem.
+
+ * Regression fix to topic recently merged to 'master'.
+
+ * The shell completion script (in contrib/) learned "git stash" has
+ a new "push" subcommand.
+
+ * "git interpret-trailers", when used as GIT_EDITOR for "git commit
+ -v", looked for and appended to a trailer block at the very end,
+ i.e. at the end of the "diff" output. The command has been
+ corrected to pay attention to the cut-mark line "commit -v" adds to
+ the buffer---the real trailer block should appear just before it.
+
+ * A test allowed both "git push" and "git receive-pack" on the other
+ end write their traces into the same file. This is OK on platforms
+ that allows atomically appending to a file opened with O_APPEND,
+ but on other platforms led to a mangled output, causing
+ intermittent test failures. This has been fixed by disabling
+ traces from "receive-pack" in the test.
+
+ * Tag objects, which are not reachable from any ref, that point at
+ missing objects were mishandled by "git gc" and friends (they
+ should silently be ignored instead)
+
+ * "git describe --contains" penalized light-weight tags so much that
+ they were almost never considered. Instead, give them about the
+ same chance to be considered as an annotated tag that is the same
+ age as the underlying commit would.
+
+ * The "run-command" API implementation has been made more robust
+ against dead-locking in a threaded environment.
+
+ * A recent update to t5545-push-options.sh started skipping all the
+ tests in the script when a web server testing is disabled or
+ unavailable, not just the ones that require a web server. Non HTTP
+ tests have been salvaged to always run in this script.
+
+ * "git send-email" now uses Net::SMTP::SSL, which is obsolete, only
+ when needed. Recent versions of Net::SMTP can do TLS natively.
+
+ * "foo\bar\baz" in "git fetch foo\bar\baz", even though there is no
+ slashes in it, cannot be a nickname for a remote on Windows, as
+ that is likely to be a pathname on a local filesystem.
+
+ * "git clean -d" used to clean directories that has ignored files,
+ even though the command should not lose ignored ones without "-x".
+ "git status --ignored" did not list ignored and untracked files
+ without "-uall". These have been corrected.
+
+ * The result from "git diff" that compares two blobs, e.g. "git diff
+ $commit1:$path $commit2:$path", used to be shown with the full
+ object name as given on the command line, but it is more natural to
+ use the $path in the output and use it to look up .gitattributes.
+
+ * The "collision detecting" SHA-1 implementation shipped with 2.13
+ was quite broken on some big-endian platforms and/or platforms that
+ do not like unaligned fetches. Update to the upstream code which
+ has already fixed these issues.
+
+ * "git am -h" triggered a BUG().
+
+ * The interaction of "url.*.insteadOf" and custom URL scheme's
+ whitelisting is now documented better.
+
+ * The timestamp of the index file is now taken after the file is
+ closed, to help Windows, on which a stale timestamp is reported by
+ fstat() on a file that is opened for writing and data was written
+ but not yet closed.
+
+ * "git pull --rebase --autostash" didn't auto-stash when the local history
+ fast-forwards to the upstream.
+
+ * A flaky test has been corrected.
+
+ * "git $cmd -h" for builtin commands calls the implementation of the
+ command (i.e. cmd_$cmd() function) without doing any repository
+ set-up, and the commands that expect RUN_SETUP is done by the Git
+ potty needs to be prepared to show the help text without barfing.
+ (merge d691551192 jk/consistent-h later to maint).
+
+ * Help contributors that visit us at GitHub.
+
+ * "git stash push <pathspec>" did not work from a subdirectory at all.
+ Bugfix for a topic in v2.13
+
+ * As there is no portable way to pass timezone information to
+ strftime, some output format from "git log" and friends are
+ impossible to produce. Teach our own strbuf_addftime to replace %z
+ and %Z with caller-supplied values to help working around this.
+ (merge 6eced3ec5e rs/strbuf-addftime-zZ later to maint).
+
+ * "git mergetool" learned to work around a wrapper MacOS X adds
+ around underlying meld.
+
+ * An example in documentation that does not work in multi worktree
+ configuration has been corrected.
+
+ * The pretty-format specifiers like '%h', '%t', etc. had an
+ optimization that no longer works correctly. In preparation/hope
+ of getting it correctly implemented, first discard the optimization
+ that is broken.
+
+ * The code to pick up and execute command alias definition from the
+ configuration used to switch to the top of the working tree and
+ then come back when the expanded alias was executed, which was
+ unnecessarily complex. Attempt to simplify the logic by using the
+ early-config mechanism that does not chdir around.
+
+ * Fix configuration codepath to pay proper attention to commondir
+ that is used in multi-worktree situation, and isolate config API
+ into its own header file.
+ (merge dc8441fdb4 bw/config-h later to maint).
+
+ * "git add -p" were updated in 2.12 timeframe to cope with custom
+ core.commentchar but the implementation was buggy and a
+ metacharacter like $ and * did not work.
+
+ * A recent regression in "git rebase -i" has been fixed and tests
+ that would have caught it and others have been added.
+
+ * An unaligned 32-bit access in pack-bitmap code has been corrected.
+
+ * Tighten error checks for invalid "git apply" input.
+
+ * The split index code did not honor core.sharedRepository setting
+ correctly.
+
+ * The Makefile rule in contrib/subtree for building documentation
+ learned to honour USE_ASCIIDOCTOR just like the main documentation
+ set does.
+
+ * Code clean-up to fix possible buffer over-reading.
+
+ * A few tests that tried to verify the contents of push certificates
+ did not use 'git rev-parse' to formulate the line to look for in
+ the certificate correctly.
+
+ * Update the character width tables.
+
+ * After "git branch --move" of the currently checked out branch, the
+ code to walk the reflog of HEAD via "log -g" and friends
+ incorrectly stopped at the reflog entry that records the renaming
+ of the branch.
+
+ * The rewrite of "git branch --list" using for-each-ref's internals
+ that happened in v2.13 regressed its handling of color.branch.local;
+ this has been fixed.
+
+ * The build procedure has been improved to allow building and testing
+ Git with address sanitizer more easily.
+ (merge 425ca6710b jk/build-with-asan later to maint).
+
+ * On Cygwin, similar to Windows, "git push //server/share/repository"
+ ought to mean a repository on a network share that can be accessed
+ locally, but this did not work correctly due to stripping the double
+ slashes at the beginning.
+
+ * The progress meter did not give a useful output when we haven't had
+ 0.5 seconds to measure the throughput during the interval. Instead
+ show the overall throughput rate at the end, which is a much more
+ useful number.
+
+ * Code clean-up, that makes us in sync with Debian by one patch.
+
+ * We run an early part of "git gc" that deals with refs before
+ daemonising (and not under lock) even when running a background
+ auto-gc, which caused multiple gc processes attempting to run the
+ early part at the same time. This is now prevented by running the
+ early part also under the GC lock.
+
+ * A recent update broke an alias that contained an uppercase letter.
+
+ * Other minor doc, test and build updates and code cleanups.
+ (merge 5053313562 rs/urlmatch-cleanup later to maint).
+ (merge 42c78a216e rs/use-div-round-up later to maint).
+ (merge 5e8d2729ae rs/wt-status-cleanup later to maint).
+ (merge bc9b7e207f as/diff-options-grammofix later to maint).
+ (merge ac05222b31 ah/patch-id-doc later to maint).
diff --git a/RelNotes/2.14.1.adoc b/RelNotes/2.14.1.adoc
new file mode 100644
index 0000000..9403340
--- /dev/null
+++ b/RelNotes/2.14.1.adoc
@@ -0,0 +1,4 @@
+Git v2.14.1 Release Notes
+=========================
+
+This release forward-ports the fix for "ssh://..." URL from Git v2.7.6
diff --git a/RelNotes/2.14.2.adoc b/RelNotes/2.14.2.adoc
new file mode 100644
index 0000000..bec9186
--- /dev/null
+++ b/RelNotes/2.14.2.adoc
@@ -0,0 +1,105 @@
+Git v2.14.2 Release Notes
+=========================
+
+Fixes since v2.14.1
+-------------------
+
+ * Because recent Git for Windows do come with a real msgfmt, the
+ build procedure for git-gui has been updated to use it instead of a
+ hand-rolled substitute.
+
+ * "%C(color name)" in the pretty print format always produced ANSI
+ color escape codes, which was an early design mistake. They now
+ honor the configuration (e.g. "color.ui = never") and also tty-ness
+ of the output medium.
+
+ * The http.{sslkey,sslCert} configuration variables are to be
+ interpreted as a pathname that honors "~[username]/" prefix, but
+ weren't, which has been fixed.
+
+ * Numerous bugs in walking of reflogs via "log -g" and friends have
+ been fixed.
+
+ * "git commit" when seeing an totally empty message said "you did not
+ edit the message", which is clearly wrong. The message has been
+ corrected.
+
+ * When a directory is not readable, "gitweb" fails to build the
+ project list. Work this around by skipping such a directory.
+
+ * A recently added test for the "credential-cache" helper revealed
+ that EOF detection done around the time the connection to the cache
+ daemon is torn down were flaky. This was fixed by reacting to
+ ECONNRESET and behaving as if we got an EOF.
+
+ * Some versions of GnuPG fail to kill gpg-agent it auto-spawned
+ and such a left-over agent can interfere with a test. Work it
+ around by attempting to kill one before starting a new test.
+
+ * "git log --tag=no-such-tag" showed log starting from HEAD, which
+ has been fixed---it now shows nothing.
+
+ * The "tag.pager" configuration variable was useless for those who
+ actually create tag objects, as it interfered with the use of an
+ editor. A new mechanism has been introduced for commands to enable
+ pager depending on what operation is being carried out to fix this,
+ and then "git tag -l" is made to run pager by default.
+
+ * "git push --recurse-submodules $there HEAD:$target" was not
+ propagated down to the submodules, but now it is.
+
+ * Commands like "git rebase" accepted the --rerere-autoupdate option
+ from the command line, but did not always use it. This has been
+ fixed.
+
+ * "git clone --recurse-submodules --quiet" did not pass the quiet
+ option down to submodules.
+
+ * "git am -s" has been taught that some input may end with a trailer
+ block that is not Signed-off-by: and it should refrain from adding
+ an extra blank line before adding a new sign-off in such a case.
+
+ * "git svn" used with "--localtime" option did not compute the tz
+ offset for the timestamp in question and instead always used the
+ current time, which has been corrected.
+
+ * Memory leaks in a few error codepaths have been plugged.
+
+ * bash 4.4 or newer gave a warning on NUL byte in command
+ substitution done in "git stash"; this has been squelched.
+
+ * "git grep -L" and "git grep --quiet -L" reported different exit
+ codes; this has been corrected.
+
+ * When handshake with a subprocess filter notices that the process
+ asked for an unknown capability, Git did not report what program
+ the offending subprocess was running. This has been corrected.
+
+ * "git apply" that is used as a better "patch -p1" failed to apply a
+ taken from a file with CRLF line endings to a file with CRLF line
+ endings. The root cause was because it misused convert_to_git()
+ that tried to do "safe-crlf" processing by looking at the index
+ entry at the same path, which is a nonsense---in that mode, "apply"
+ is not working on the data in (or derived from) the index at all.
+ This has been fixed.
+
+ * Killing "git merge --edit" before the editor returns control left
+ the repository in a state with MERGE_MSG but without MERGE_HEAD,
+ which incorrectly tells the subsequent "git commit" that there was
+ a squash merge in progress. This has been fixed.
+
+ * "git archive" did not work well with pathspecs and the
+ export-ignore attribute.
+
+ * "git cvsserver" no longer is invoked by "git daemon" by default,
+ as it is old and largely unmaintained.
+
+ * Various Perl scripts did not use safe_pipe_capture() instead of
+ backticks, leaving them susceptible to end-user input. They have
+ been corrected.
+
+Also contains various documentation updates and code clean-ups.
+
+Credits go to joernchen <joernchen@phenoelit.de> for finding the
+unsafe constructs in "git cvsserver", and to Jeff King at GitHub for
+finding and fixing instances of the same issue in other scripts.
diff --git a/RelNotes/2.14.3.adoc b/RelNotes/2.14.3.adoc
new file mode 100644
index 0000000..977c9e8
--- /dev/null
+++ b/RelNotes/2.14.3.adoc
@@ -0,0 +1,99 @@
+Git v2.14.3 Release Notes
+=========================
+
+Fixes since v2.14.2
+-------------------
+
+ * A helper function to read a single whole line into strbuf
+ mistakenly triggered OOM error at EOF under certain conditions,
+ which has been fixed.
+
+ * In addition to "cc: <a@dd.re.ss> # cruft", "cc: a@dd.re.ss # cruft"
+ was taught to "git send-email" as a valid way to tell it that it
+ needs to also send a carbon copy to <a@dd.re.ss> in the trailer
+ section.
+
+ * Fix regression to "gitk --bisect" by a recent update.
+
+ * Unlike "git commit-tree < file", "git commit-tree -F file" did not
+ pass the contents of the file verbatim and instead completed an
+ incomplete line at the end, if exists. The latter has been updated
+ to match the behaviour of the former.
+
+ * "git archive", especially when used with pathspec, stored an empty
+ directory in its output, even though Git itself never does so.
+ This has been fixed.
+
+ * API error-proofing which happens to also squelch warnings from GCC.
+
+ * "git gc" tries to avoid running two instances at the same time by
+ reading and writing pid/host from and to a lock file; it used to
+ use an incorrect fscanf() format when reading, which has been
+ corrected.
+
+ * The test linter has been taught that we do not like "echo -e".
+
+ * Code cmp.std.c nitpick.
+
+ * "git describe --match" learned to take multiple patterns in v2.13
+ series, but the feature ignored the patterns after the first one
+ and did not work at all. This has been fixed.
+
+ * "git cat-file --textconv" started segfaulting recently, which
+ has been corrected.
+
+ * The built-in pattern to detect the "function header" for HTML did
+ not match <H1>..<H6> elements without any attributes, which has
+ been fixed.
+
+ * "git mailinfo" was loose in decoding quoted printable and produced
+ garbage when the two letters after the equal sign are not
+ hexadecimal. This has been fixed.
+
+ * The documentation for '-X<option>' for merges was misleadingly
+ written to suggest that "-s theirs" exists, which is not the case.
+
+ * Spell the name of our system as "Git" in the output from
+ request-pull script.
+
+ * Fixes for a handful memory access issues identified by valgrind.
+
+ * Backports a moral equivalent of 2015 fix to the poll emulation from
+ the upstream gnulib to fix occasional breakages on HPE NonStop.
+
+ * In the "--format=..." option of the "git for-each-ref" command (and
+ its friends, i.e. the listing mode of "git branch/tag"), "%(atom:)"
+ (e.g. "%(refname:)", "%(body:)" used to error out. Instead, treat
+ them as if the colon and an empty string that follows it were not
+ there.
+
+ * Users with "color.ui = always" in their configuration were broken
+ by a recent change that made plumbing commands to pay attention to
+ them as the patch created internally by "git add -p" were colored
+ (heh) and made unusable. This has been fixed.
+
+ * "git branch -M a b" while on a branch that is completely unrelated
+ to either branch a or branch b misbehaved when multiple worktree
+ was in use. This has been fixed.
+
+ * "git fast-export" with -M/-C option issued "copy" instruction on a
+ path that is simultaneously modified, which was incorrect.
+
+ * The checkpoint command "git fast-import" did not flush updates to
+ refs and marks unless at least one object was created since the
+ last checkpoint, which has been corrected, as these things can
+ happen without any new object getting created.
+
+ * The scripts to drive TravisCI has been reorganized and then an
+ optimization to avoid spending cycles on a branch whose tip is
+ tagged has been implemented.
+
+ * "git fetch <there> <src>:<dst>" allows an object name on the <src>
+ side when the other side accepts such a request since Git v2.5, but
+ the documentation was left stale.
+
+ * A regression in 2.11 that made the code to read the list of
+ alternate object stores overrun the end of the string has been
+ fixed.
+
+Also contains various documentation updates and code clean-ups.
diff --git a/RelNotes/2.14.4.adoc b/RelNotes/2.14.4.adoc
new file mode 100644
index 0000000..97755a8
--- /dev/null
+++ b/RelNotes/2.14.4.adoc
@@ -0,0 +1,5 @@
+Git v2.14.4 Release Notes
+=========================
+
+This release is to forward-port the fixes made in the v2.13.7 version
+of Git. See its release notes for details.
diff --git a/RelNotes/2.14.5.adoc b/RelNotes/2.14.5.adoc
new file mode 100644
index 0000000..130645f
--- /dev/null
+++ b/RelNotes/2.14.5.adoc
@@ -0,0 +1,16 @@
+Git v2.14.5 Release Notes
+=========================
+
+This release is to address the recently reported CVE-2018-17456.
+
+Fixes since v2.14.4
+-------------------
+
+ * Submodules' "URL"s come from the untrusted .gitmodules file, but
+ we blindly gave it to "git clone" to clone submodules when "git
+ clone --recurse-submodules" was used to clone a project that has
+ such a submodule. The code has been hardened to reject such
+ malformed URLs (e.g. one that begins with a dash).
+
+Credit for finding and fixing this vulnerability goes to joernchen
+and Jeff King, respectively.
diff --git a/RelNotes/2.14.6.adoc b/RelNotes/2.14.6.adoc
new file mode 100644
index 0000000..72b7af6
--- /dev/null
+++ b/RelNotes/2.14.6.adoc
@@ -0,0 +1,54 @@
+Git v2.14.6 Release Notes
+=========================
+
+This release addresses the security issues CVE-2019-1348,
+CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, CVE-2019-1352,
+CVE-2019-1353, CVE-2019-1354, and CVE-2019-1387.
+
+Fixes since v2.14.5
+-------------------
+
+ * CVE-2019-1348:
+ The --export-marks option of git fast-import is exposed also via
+ the in-stream command feature export-marks=... and it allows
+ overwriting arbitrary paths.
+
+ * CVE-2019-1349:
+ When submodules are cloned recursively, under certain circumstances
+ Git could be fooled into using the same Git directory twice. We now
+ require the directory to be empty.
+
+ * CVE-2019-1350:
+ Incorrect quoting of command-line arguments allowed remote code
+ execution during a recursive clone in conjunction with SSH URLs.
+
+ * CVE-2019-1351:
+ While the only permitted drive letters for physical drives on
+ Windows are letters of the US-English alphabet, this restriction
+ does not apply to virtual drives assigned via subst <letter>:
+ <path>. Git mistook such paths for relative paths, allowing writing
+ outside of the worktree while cloning.
+
+ * CVE-2019-1352:
+ Git was unaware of NTFS Alternate Data Streams, allowing files
+ inside the .git/ directory to be overwritten during a clone.
+
+ * CVE-2019-1353:
+ When running Git in the Windows Subsystem for Linux (also known as
+ "WSL") while accessing a working directory on a regular Windows
+ drive, none of the NTFS protections were active.
+
+ * CVE-2019-1354:
+ Filenames on Linux/Unix can contain backslashes. On Windows,
+ backslashes are directory separators. Git did not use to refuse to
+ write out tracked files with such filenames.
+
+ * CVE-2019-1387:
+ Recursive clones are currently affected by a vulnerability that is
+ caused by too-lax validation of submodule names, allowing very
+ targeted attacks via remote code execution in recursive clones.
+
+Credit for finding these vulnerabilities goes to Microsoft Security
+Response Center, in particular to Nicolas Joly. The `fast-import`
+fixes were provided by Jeff King, the other fixes by Johannes
+Schindelin with help from Garima Singh.
diff --git a/RelNotes/2.15.0.adoc b/RelNotes/2.15.0.adoc
new file mode 100644
index 0000000..cdd761b
--- /dev/null
+++ b/RelNotes/2.15.0.adoc
@@ -0,0 +1,508 @@
+Git 2.15 Release Notes
+======================
+
+Backward compatibility notes and other notable changes.
+
+ * Use of an empty string as a pathspec element that is used for
+ 'everything matches' is still warned and Git asks users to use a
+ more explicit '.' for that instead. The hope is that existing
+ users will not mind this change, and eventually the warning can be
+ turned into a hard error, upgrading the deprecation into removal of
+ this (mis)feature. That is now scheduled to happen in Git v2.16,
+ the next major release after this one.
+
+ * Git now avoids blindly falling back to ".git" when the setup
+ sequence said we are _not_ in Git repository. A corner case that
+ happens to work right now may be broken by a call to BUG().
+ We've tried hard to locate such cases and fixed them, but there
+ might still be cases that need to be addressed--bug reports are
+ greatly appreciated.
+
+ * "branch --set-upstream" that has been deprecated in Git 1.8 has
+ finally been retired.
+
+
+Updates since v2.14
+-------------------
+
+UI, Workflows & Features
+
+ * An example that is now obsolete has been removed from a sample hook,
+ and an old example in it that added a sign-off manually has been
+ improved to use the interpret-trailers command.
+
+ * The advice message given when "git rebase" stops for conflicting
+ changes has been improved.
+
+ * The "rerere-train" script (in contrib/) learned the "--overwrite"
+ option to allow overwriting existing recorded resolutions.
+
+ * "git contacts" (in contrib/) now lists the address on the
+ "Reported-by:" trailer to its output, in addition to those on
+ S-o-b: and other trailers, to make it easier to notify (and thank)
+ the original bug reporter.
+
+ * "git rebase", especially when it is run by mistake and ends up
+ trying to replay many changes, spent long time in silence. The
+ command has been taught to show progress report when it spends
+ long time preparing these many changes to replay (which would give
+ the user a chance to abort with ^C).
+
+ * "git merge" learned a "--signoff" option to add the Signed-off-by:
+ trailer with the committer's name.
+
+ * "git diff" learned to optionally paint new lines that are the same
+ as deleted lines elsewhere differently from genuinely new lines.
+
+ * "git interpret-trailers" learned to take the trailer specifications
+ from the command line that overrides the configured values.
+
+ * "git interpret-trailers" has been taught a "--parse" and a few
+ other options to make it easier for scripts to grab existing
+ trailer lines from a commit log message.
+
+ * The "--format=%(trailers)" option "git log" and its friends take
+ learned to take the 'unfold' and 'only' modifiers to normalize its
+ output, e.g. "git log --format=%(trailers:only,unfold)".
+
+ * "gitweb" shows a link to visit the 'raw' contents of blobs in the
+ history overview page.
+
+ * "[gc] rerereResolved = 5.days" used to be invalid, as the variable
+ is defined to take an integer counting the number of days. It now
+ is allowed.
+
+ * The code to acquire a lock on a reference (e.g. while accepting a
+ push from a client) used to immediately fail when the reference is
+ already locked---now it waits for a very short while and retries,
+ which can make it succeed if the lock holder was holding it during
+ a read-only operation.
+
+ * "branch --set-upstream" that has been deprecated in Git 1.8 has
+ finally been retired.
+
+ * The codepath to call external process filter for smudge/clean
+ operation learned to show the progress meter.
+
+ * "git rev-parse" learned "--is-shallow-repository", that is to be
+ used in a way similar to existing "--is-bare-repository" and
+ friends.
+
+ * "git describe --match <pattern>" has been taught to play well with
+ the "--all" option.
+
+ * "git branch" learned "-c/-C" to create a new branch by copying an
+ existing one.
+
+ * Some commands (most notably "git status") makes an opportunistic
+ update when performing a read-only operation to help optimize later
+ operations in the same repository. The new "--no-optional-locks"
+ option can be passed to Git to disable them.
+
+ * "git for-each-ref --format=..." learned a new format element,
+ %(trailers), to show only the commit log trailer part of the log
+ message.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * Conversion from uchar[20] to struct object_id continues.
+
+ * Start using selected c99 constructs in small, stable and
+ essential part of the system to catch people who care about
+ older compilers that do not grok them.
+
+ * The filter-process interface learned to allow a process with long
+ latency give a "delayed" response.
+
+ * Many uses of comparison callback function the hashmap API uses
+ cast the callback function type when registering it to
+ hashmap_init(), which defeats the compile time type checking when
+ the callback interface changes (e.g. gaining more parameters).
+ The callback implementations have been updated to take "void *"
+ pointers and cast them to the type they expect instead.
+
+ * Because recent Git for Windows do come with a real msgfmt, the
+ build procedure for git-gui has been updated to use it instead of a
+ hand-rolled substitute.
+
+ * "git grep --recurse-submodules" has been reworked to give a more
+ consistent output across submodule boundary (and do its thing
+ without having to fork a separate process).
+
+ * A helper function to read a single whole line into strbuf
+ mistakenly triggered OOM error at EOF under certain conditions,
+ which has been fixed.
+
+ * The "ref-store" code reorganization continues.
+
+ * "git commit" used to discard the index and re-read from the filesystem
+ just in case the pre-commit hook has updated it in the middle; this
+ has been optimized out when we know we do not run the pre-commit hook.
+ (merge 680ee550d7 kw/commit-keep-index-when-pre-commit-is-not-run later to maint).
+
+ * Updates to the HTTP layer we made recently unconditionally used
+ features of libCurl without checking the existence of them, causing
+ compilation errors, which has been fixed. Also migrate the code to
+ check feature macros, not version numbers, to cope better with
+ libCurl that vendor ships with backported features.
+
+ * The API to start showing progress meter after a short delay has
+ been simplified.
+ (merge 8aade107dd jc/simplify-progress later to maint).
+
+ * Code clean-up to avoid mixing values read from the .gitmodules file
+ and values read from the .git/config file.
+
+ * We used to spend more than necessary cycles allocating and freeing
+ piece of memory while writing each index entry out. This has been
+ optimized.
+
+ * Platforms that ship with a separate sha1 with collision detection
+ library can link to it instead of using the copy we ship as part of
+ our source tree.
+
+ * Code around "notes" have been cleaned up.
+ (merge 3964281524 mh/notes-cleanup later to maint).
+
+ * The long-standing rule that an in-core lockfile instance, once it
+ is used, must not be freed, has been lifted and the lockfile and
+ tempfile APIs have been updated to reduce the chance of programming
+ errors.
+
+ * Our hashmap implementation in hashmap.[ch] is not thread-safe when
+ adding a new item needs to expand the hashtable by rehashing; add
+ an API to disable the automatic rehashing to work it around.
+
+ * Many of our programs consider that it is OK to release dynamic
+ storage that is used throughout the life of the program by simply
+ exiting, but this makes it harder to leak detection tools to avoid
+ reporting false positives. Plug many existing leaks and introduce
+ a mechanism for developers to mark that the region of memory
+ pointed by a pointer is not lost/leaking to help these tools.
+
+ * As "git commit" to conclude a conflicted "git merge" honors the
+ commit-msg hook, "git merge" that records a merge commit that
+ cleanly auto-merges should, but it didn't.
+
+ * The codepath for "git merge-recursive" has been cleaned up.
+
+ * Many leaks of strbuf have been fixed.
+
+ * "git imap-send" has our own implementation of the protocol and also
+ can use more recent libCurl with the imap protocol support. Update
+ the latter so that it can use the credential subsystem, and then
+ make it the default option to use, so that we can eventually
+ deprecate and remove the former.
+
+ * "make style" runs git-clang-format to help developers by pointing
+ out coding style issues.
+
+ * A test to demonstrate "git mv" failing to adjust nested submodules
+ has been added.
+ (merge c514167df2 hv/mv-nested-submodules-test later to maint).
+
+ * On Cygwin, "ulimit -s" does not report failure but it does not work
+ at all, which causes an unexpected success of some tests that
+ expect failures under a limited stack situation. This has been
+ fixed.
+
+ * Many codepaths have been updated to squelch -Wimplicit-fallthrough
+ warnings from Gcc 7 (which is a good code hygiene).
+
+ * Add a helper for DLL loading in anticipation for its need in a
+ future topic RSN.
+
+ * "git status --ignored", when noticing that a directory without any
+ tracked path is ignored, still enumerated all the ignored paths in
+ the directory, which is unnecessary. The codepath has been
+ optimized to avoid this overhead.
+
+ * The final batch to "git rebase -i" updates to move more code from
+ the shell script to C has been merged.
+
+ * Operations that do not touch (majority of) packed refs have been
+ optimized by making accesses to packed-refs file lazy; we no longer
+ pre-parse everything, and an access to a single ref in the
+ packed-refs does not touch majority of irrelevant refs, either.
+
+ * Add comment to clarify that the style file is meant to be used with
+ clang-5 and the rules are still work in progress.
+
+ * Many variables that points at a region of memory that will live
+ throughout the life of the program have been marked with UNLEAK
+ marker to help the leak checkers concentrate on real leaks..
+
+ * Plans for weaning us off of SHA-1 has been documented.
+
+ * A new "oidmap" API has been introduced and oidset API has been
+ rewritten to use it.
+
+
+Also contains various documentation updates and code clean-ups.
+
+
+Fixes since v2.14
+-----------------
+
+ * "%C(color name)" in the pretty print format always produced ANSI
+ color escape codes, which was an early design mistake. They now
+ honor the configuration (e.g. "color.ui = never") and also tty-ness
+ of the output medium.
+
+ * The http.{sslkey,sslCert} configuration variables are to be
+ interpreted as a pathname that honors "~[username]/" prefix, but
+ weren't, which has been fixed.
+
+ * Numerous bugs in walking of reflogs via "log -g" and friends have
+ been fixed.
+
+ * "git commit" when seeing an totally empty message said "you did not
+ edit the message", which is clearly wrong. The message has been
+ corrected.
+
+ * When a directory is not readable, "gitweb" fails to build the
+ project list. Work this around by skipping such a directory.
+
+ * Some versions of GnuPG fails to kill gpg-agent it auto-spawned
+ and such a left-over agent can interfere with a test. Work it
+ around by attempting to kill one before starting a new test.
+
+ * A recently added test for the "credential-cache" helper revealed
+ that EOF detection done around the time the connection to the cache
+ daemon is torn down were flaky. This was fixed by reacting to
+ ECONNRESET and behaving as if we got an EOF.
+
+ * "git log --tag=no-such-tag" showed log starting from HEAD, which
+ has been fixed---it now shows nothing.
+
+ * The "tag.pager" configuration variable was useless for those who
+ actually create tag objects, as it interfered with the use of an
+ editor. A new mechanism has been introduced for commands to enable
+ pager depending on what operation is being carried out to fix this,
+ and then "git tag -l" is made to run pager by default.
+
+ * "git push --recurse-submodules $there HEAD:$target" was not
+ propagated down to the submodules, but now it is.
+
+ * Commands like "git rebase" accepted the --rerere-autoupdate option
+ from the command line, but did not always use it. This has been
+ fixed.
+
+ * "git clone --recurse-submodules --quiet" did not pass the quiet
+ option down to submodules.
+
+ * Test portability fix for OBSD.
+
+ * Portability fix for OBSD.
+
+ * "git am -s" has been taught that some input may end with a trailer
+ block that is not Signed-off-by: and it should refrain from adding
+ an extra blank line before adding a new sign-off in such a case.
+
+ * "git svn" used with "--localtime" option did not compute the tz
+ offset for the timestamp in question and instead always used the
+ current time, which has been corrected.
+
+ * Memory leak in an error codepath has been plugged.
+
+ * "git stash -u" used the contents of the committed version of the
+ ".gitignore" file to decide which paths are ignored, even when the
+ file has local changes. The command has been taught to instead use
+ the locally modified contents.
+
+ * bash 4.4 or newer gave a warning on NUL byte in command
+ substitution done in "git stash"; this has been squelched.
+
+ * "git grep -L" and "git grep --quiet -L" reported different exit
+ codes; this has been corrected.
+
+ * When handshake with a subprocess filter notices that the process
+ asked for an unknown capability, Git did not report what program
+ the offending subprocess was running. This has been corrected.
+
+ * "git apply" that is used as a better "patch -p1" failed to apply a
+ taken from a file with CRLF line endings to a file with CRLF line
+ endings. The root cause was because it misused convert_to_git()
+ that tried to do "safe-crlf" processing by looking at the index
+ entry at the same path, which is a nonsense---in that mode, "apply"
+ is not working on the data in (or derived from) the index at all.
+ This has been fixed.
+
+ * Killing "git merge --edit" before the editor returns control left
+ the repository in a state with MERGE_MSG but without MERGE_HEAD,
+ which incorrectly tells the subsequent "git commit" that there was
+ a squash merge in progress. This has been fixed.
+
+ * "git archive" did not work well with pathspecs and the
+ export-ignore attribute.
+
+ * In addition to "cc: <a@dd.re.ss> # cruft", "cc: a@dd.re.ss # cruft"
+ was taught to "git send-email" as a valid way to tell it that it
+ needs to also send a carbon copy to <a@dd.re.ss> in the trailer
+ section.
+
+ * "git branch -M a b" while on a branch that is completely unrelated
+ to either branch a or branch b misbehaved when multiple worktree
+ was in use. This has been fixed.
+ (merge 31824d180d nd/worktree-kill-parse-ref later to maint).
+
+ * "git gc" and friends when multiple worktrees are used off of a
+ single repository did not consider the index and per-worktree refs
+ of other worktrees as the root for reachability traversal, making
+ objects that are in use only in other worktrees to be subject to
+ garbage collection.
+
+ * A regression to "gitk --bisect" by a recent update has been fixed.
+
+ * "git -c submodule.recurse=yes pull" did not work as if the
+ "--recurse-submodules" option was given from the command line.
+ This has been corrected.
+
+ * Unlike "git commit-tree < file", "git commit-tree -F file" did not
+ pass the contents of the file verbatim and instead completed an
+ incomplete line at the end, if exists. The latter has been updated
+ to match the behaviour of the former.
+
+ * Many codepaths did not diagnose write failures correctly when disks
+ go full, due to their misuse of write_in_full() helper function,
+ which have been corrected.
+ (merge f48ecd38cb jk/write-in-full-fix later to maint).
+
+ * "git help co" now says "co is aliased to ...", not "git co is".
+ (merge b3a8076e0d ks/help-alias-label later to maint).
+
+ * "git archive", especially when used with pathspec, stored an empty
+ directory in its output, even though Git itself never does so.
+ This has been fixed.
+
+ * API error-proofing which happens to also squelch warnings from GCC.
+
+ * The explanation of the cut-line in the commit log editor has been
+ slightly tweaked.
+ (merge 8c4b1a3593 ks/commit-do-not-touch-cut-line later to maint).
+
+ * "git gc" tries to avoid running two instances at the same time by
+ reading and writing pid/host from and to a lock file; it used to
+ use an incorrect fscanf() format when reading, which has been
+ corrected.
+
+ * The scripts to drive TravisCI has been reorganized and then an
+ optimization to avoid spending cycles on a branch whose tip is
+ tagged has been implemented.
+ (merge 8376eb4a8f ls/travis-scriptify later to maint).
+
+ * The test linter has been taught that we do not like "echo -e".
+
+ * Code cmp.std.c nitpick.
+
+ * A regression fix for 2.11 that made the code to read the list of
+ alternate object stores overrun the end of the string.
+ (merge f0f7bebef7 jk/info-alternates-fix later to maint).
+
+ * "git describe --match" learned to take multiple patterns in v2.13
+ series, but the feature ignored the patterns after the first one
+ and did not work at all. This has been fixed.
+
+ * "git filter-branch" cannot reproduce a history with a tag without
+ the tagger field, which only ancient versions of Git allowed to be
+ created. This has been corrected.
+ (merge b2c1ca6b4b ic/fix-filter-branch-to-handle-tag-without-tagger later to maint).
+
+ * "git cat-file --textconv" started segfaulting recently, which
+ has been corrected.
+
+ * The built-in pattern to detect the "function header" for HTML did
+ not match <H1>..<H6> elements without any attributes, which has
+ been fixed.
+
+ * "git mailinfo" was loose in decoding quoted printable and produced
+ garbage when the two letters after the equal sign are not
+ hexadecimal. This has been fixed.
+
+ * The machinery to create xdelta used in pack files received the
+ sizes of the data in size_t, but lost the higher bits of them by
+ storing them in "unsigned int" during the computation, which is
+ fixed.
+
+ * The delta format used in the packfile cannot reference data at
+ offset larger than what can be expressed in 4-byte, but the
+ generator for the data failed to make sure the offset does not
+ overflow. This has been corrected.
+
+ * The documentation for '-X<option>' for merges was misleadingly
+ written to suggest that "-s theirs" exists, which is not the case.
+
+ * "git fast-export" with -M/-C option issued "copy" instruction on a
+ path that is simultaneously modified, which was incorrect.
+ (merge b3e8ca89cf jt/fast-export-copy-modify-fix later to maint).
+
+ * Many codepaths have been updated to squelch -Wsign-compare
+ warnings.
+ (merge 071bcaab64 rj/no-sign-compare later to maint).
+
+ * Memory leaks in various codepaths have been plugged.
+ (merge 4d01a7fa65 ma/leakplugs later to maint).
+
+ * Recent versions of "git rev-parse --parseopt" did not parse the
+ option specification that does not have the optional flags (*=?!)
+ correctly, which has been corrected.
+ (merge a6304fa4c2 bc/rev-parse-parseopt-fix later to maint).
+
+ * The checkpoint command "git fast-import" did not flush updates to
+ refs and marks unless at least one object was created since the
+ last checkpoint, which has been corrected, as these things can
+ happen without any new object getting created.
+ (merge 30e215a65c er/fast-import-dump-refs-on-checkpoint later to maint).
+
+ * Spell the name of our system as "Git" in the output from
+ request-pull script.
+
+ * Fixes for a handful memory access issues identified by valgrind.
+
+ * Backports a moral equivalent of 2015 fix to the poll() emulation
+ from the upstream gnulib to fix occasional breakages on HPE NonStop.
+
+ * Users with "color.ui = always" in their configuration were broken
+ by a recent change that made plumbing commands to pay attention to
+ them as the patch created internally by "git add -p" were colored
+ (heh) and made unusable. This has been fixed by reverting the
+ offending change.
+
+ * In the "--format=..." option of the "git for-each-ref" command (and
+ its friends, i.e. the listing mode of "git branch/tag"), "%(atom:)"
+ (e.g. "%(refname:)", "%(body:)" used to error out. Instead, treat
+ them as if the colon and an empty string that follows it were not
+ there.
+
+ * An ancient bug that made Git misbehave with creation/renaming of
+ refs has been fixed.
+
+ * "git fetch <there> <src>:<dst>" allows an object name on the <src>
+ side when the other side accepts such a request since Git v2.5, but
+ the documentation was left stale.
+ (merge 83558a412a jc/fetch-refspec-doc-update later to maint).
+
+ * Update the documentation for "git filter-branch" so that the filter
+ options are listed in the same order as they are applied, as
+ described in an earlier part of the doc.
+ (merge 07c4984508 dg/filter-branch-filter-order-doc later to maint).
+
+ * A possible oom error is now caught as a fatal error, instead of
+ continuing and dereferencing NULL.
+ (merge 55d7d15847 ao/path-use-xmalloc later to maint).
+
+ * Other minor doc, test and build updates and code cleanups.
+ (merge f094b89a4d ma/parse-maybe-bool later to maint).
+ (merge 6cdf8a7929 ma/ts-cleanups later to maint).
+ (merge 7560f547e6 ma/up-to-date later to maint).
+ (merge 0db3dc75f3 rs/apply-epoch later to maint).
+ (merge 276d0e35c0 ma/split-symref-update-fix later to maint).
+ (merge f777623514 ks/branch-tweak-error-message-for-extra-args later to maint).
+ (merge 33f3c683ec ks/verify-filename-non-option-error-message-tweak later to maint).
+ (merge 7cbbf9d6a2 ls/filter-process-delayed later to maint).
+ (merge 488aa65c8f wk/merge-options-gpg-sign-doc later to maint).
+ (merge e61cb19a27 jc/branch-force-doc-readability-fix later to maint).
+ (merge 32fceba3fd np/config-path-doc later to maint).
+ (merge e38c681fb7 sb/rev-parse-show-superproject-root later to maint).
+ (merge 4f851dc883 sg/rev-list-doc-reorder-fix later to maint).
diff --git a/RelNotes/2.15.1.adoc b/RelNotes/2.15.1.adoc
new file mode 100644
index 0000000..ec06704
--- /dev/null
+++ b/RelNotes/2.15.1.adoc
@@ -0,0 +1,88 @@
+Git v2.15.1 Release Notes
+=========================
+
+Fixes since v2.15
+-----------------
+
+ * TravisCI build updates.
+
+ * "auto" as a value for the columnar output configuration ought to
+ judge "is the output consumed by humans?" with the same criteria as
+ "auto" for coloured output configuration, i.e. either the standard
+ output stream is going to tty, or a pager is in use. We forgot the
+ latter, which has been fixed.
+
+ * The experimental "color moved lines differently in diff output"
+ feature was buggy around "ignore whitespace changes" edges, which
+ has been corrected.
+
+ * Instead of using custom line comparison and hashing functions to
+ implement "moved lines" coloring in the diff output, use the pair
+ of these functions from lower-layer xdiff/ code.
+
+ * Some codepaths did not check for errors when asking what branch the
+ HEAD points at, which have been fixed.
+
+ * "git commit", after making a commit, did not check for errors when
+ asking on what branch it made the commit, which has been corrected.
+
+ * "git status --ignored -u" did not stop at a working tree of a
+ separate project that is embedded in an ignored directory and
+ listed files in that other project, instead of just showing the
+ directory itself as ignored.
+
+ * A broken access to object databases in recent update to "git grep
+ --recurse-submodules" has been fixed.
+
+ * A recent regression in "git rebase -i" that broke execution of git
+ commands from subdirectories via "exec" instruction has been fixed.
+
+ * "git check-ref-format --branch @{-1}" bit a "BUG()" when run
+ outside a repository for obvious reasons; clarify the documentation
+ and make sure we do not even try to expand the at-mark magic in
+ such a case, but still call the validation logic for branch names.
+
+ * Command line completion (in contrib/) update.
+
+ * Description of blame.{showroot,blankboundary,showemail,date}
+ configuration variables have been added to "git config --help".
+
+ * After an error from lstat(), diff_populate_filespec() function
+ sometimes still went ahead and used invalid data in struct stat,
+ which has been fixed.
+
+ * UNC paths are also relevant in Cygwin builds and they are now
+ tested just like Mingw builds.
+
+ * Correct start-up sequence so that a repository could be placed
+ immediately under the root directory again (which was broken at
+ around Git 2.13).
+
+ * The credential helper for libsecret (in contrib/) has been improved
+ to allow possibly prompting the end user to unlock secrets that are
+ currently locked (otherwise the secrets may not be loaded).
+
+ * Updates from GfW project.
+
+ * "git rebase -i" recently started misbehaving when a submodule that
+ is configured with 'submodule.<name>.ignore' is dirty; this has
+ been corrected.
+
+ * Some error messages did not quote filenames shown in it, which have
+ been fixed.
+
+ * Building with NO_LIBPCRE1_JIT did not disable it, which has been fixed.
+
+ * We used to add an empty alternate object database to the system
+ that does not help anything; it has been corrected.
+
+ * Error checking in "git imap-send" for empty response has been
+ improved.
+
+ * An ancient bug in "git apply --ignore-space-change" codepath has
+ been fixed.
+
+ * There was a recent semantic mismerge in the codepath to write out a
+ section of a configuration section, which has been corrected.
+
+Also contains various documentation updates and code clean-ups.
diff --git a/RelNotes/2.15.2.adoc b/RelNotes/2.15.2.adoc
new file mode 100644
index 0000000..b480e56
--- /dev/null
+++ b/RelNotes/2.15.2.adoc
@@ -0,0 +1,50 @@
+Git v2.15.2 Release Notes
+=========================
+
+Fixes since v2.15.1
+-------------------
+
+ * Recent update to the refs infrastructure implementation started
+ rewriting packed-refs file more often than before; this has been
+ optimized again for most trivial cases.
+
+ * The SubmittingPatches document has been converted to produce an
+ HTML version via AsciiDoc/Asciidoctor.
+
+ * Contrary to the documentation, "git pull -4/-6 other-args" did not
+ ask the underlying "git fetch" to go over IPv4/IPv6, which has been
+ corrected.
+
+ * When "git rebase" prepared an mailbox of changes and fed it to "git
+ am" to replay them, it was confused when a stray "From " happened
+ to be in the log message of one of the replayed changes. This has
+ been corrected.
+
+ * Command line completion (in contrib/) has been taught about the
+ "--copy" option of "git branch".
+
+ * "git apply --inaccurate-eof" when used with "--ignore-space-change"
+ triggered an internal sanity check, which has been fixed.
+
+ * The sequencer machinery (used by "git cherry-pick A..B", and "git
+ rebase -i", among other things) would have lost a commit if stopped
+ due to an unlockable index file, which has been fixed.
+
+ * The three-way merge performed by "git cherry-pick" was confused
+ when a new submodule was added in the meantime, which has been
+ fixed (or "papered over").
+
+ * "git notes" sent its error message to its standard output stream,
+ which was corrected.
+
+ * A few scripts (both in production and tests) incorrectly redirected
+ their error output. These have been corrected.
+
+ * Clarify and enhance documentation for "merge-base --fork-point", as
+ it was clear what it computed but not why/what for.
+
+ * This release also contains the fixes made in the v2.13.7 version of
+ Git. See its release notes for details.
+
+
+Also contains various documentation updates and code clean-ups.
diff --git a/RelNotes/2.15.3.adoc b/RelNotes/2.15.3.adoc
new file mode 100644
index 0000000..fd2e6f8
--- /dev/null
+++ b/RelNotes/2.15.3.adoc
@@ -0,0 +1,6 @@
+Git v2.15.3 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.14.5 to address
+the recently reported CVE-2018-17456; see the release notes for that
+version for details.
diff --git a/RelNotes/2.15.4.adoc b/RelNotes/2.15.4.adoc
new file mode 100644
index 0000000..dc241cb
--- /dev/null
+++ b/RelNotes/2.15.4.adoc
@@ -0,0 +1,11 @@
+Git v2.15.4 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.14.6 to address
+the security issues CVE-2019-1348, CVE-2019-1349, CVE-2019-1350,
+CVE-2019-1351, CVE-2019-1352, CVE-2019-1353, CVE-2019-1354, and
+CVE-2019-1387; see the release notes for that version for details.
+
+In conjunction with a vulnerability that was fixed in v2.20.2,
+`.gitmodules` is no longer allowed to contain entries of the form
+`submodule.<name>.update=!command`.
diff --git a/RelNotes/2.16.0.adoc b/RelNotes/2.16.0.adoc
new file mode 100644
index 0000000..b474781
--- /dev/null
+++ b/RelNotes/2.16.0.adoc
@@ -0,0 +1,482 @@
+Git 2.16 Release Notes
+======================
+
+Backward compatibility notes and other notable changes.
+
+ * Use of an empty string as a pathspec element that is used for
+ 'everything matches' is now an error.
+
+
+Updates since v2.15
+-------------------
+
+UI, Workflows & Features
+
+ * An empty string as a pathspec element that means "everything"
+ i.e. 'git add ""', is now illegal. We started this by first
+ deprecating and warning a pathspec that has such an element in
+ 2.11 (Nov 2016).
+
+ * A hook script that is set unexecutable is simply ignored. Git
+ notifies when such a file is ignored, unless the message is
+ squelched via advice.ignoredHook configuration.
+
+ * "git pull" has been taught to accept "--[no-]signoff" option and
+ pass it down to "git merge".
+
+ * The "--push-option=<string>" option to "git push" now defaults to a
+ list of strings configured via push.pushOption variable.
+
+ * "gitweb" checks if a directory is searchable with Perl's "-x"
+ operator, which can be enhanced by using "filetest 'access'"
+ pragma, which now we do.
+
+ * "git stash save" has been deprecated in favour of "git stash push".
+
+ * The set of paths output from "git status --ignored" was tied
+ closely with its "--untracked=<mode>" option, but now it can be
+ controlled more flexibly. Most notably, a directory that is
+ ignored because it is listed to be ignored in the ignore/exclude
+ mechanism can be handled differently from a directory that ends up
+ to be ignored only because all files in it are ignored.
+
+ * The remote-helper for talking to MediaWiki has been updated to
+ truncate an overlong pagename so that ".mw" suffix can still be
+ added.
+
+ * The remote-helper for talking to MediaWiki has been updated to
+ work with mediawiki namespaces.
+
+ * The "--format=..." option "git for-each-ref" takes learned to show
+ the name of the 'remote' repository and the ref at the remote side
+ that is affected for 'upstream' and 'push' via "%(push:remotename)"
+ and friends.
+
+ * Doc and message updates to teach users "bisect view" is a synonym
+ for "bisect visualize".
+
+ * "git bisect run" that did not specify any command to run used to go
+ ahead and treated all commits to be tested as 'good'. This has
+ been corrected by making the command error out.
+
+ * The SubmittingPatches document has been converted to produce an
+ HTML version via AsciiDoc/Asciidoctor.
+
+ * We learned to optionally talk to a file system monitor via new
+ fsmonitor extension to speed up "git status" and other operations
+ that need to see which paths have been modified. Currently we only
+ support "watchman". See File System Monitor section of
+ git-update-index(1) for more detail.
+
+ * The "diff" family of commands learned to ignore differences in
+ carriage return at the end of line.
+
+ * Places that know about "sendemail.to", like documentation and shell
+ completion (in contrib/) have been taught about "sendemail.tocmd",
+ too.
+
+ * "git add --renormalize ." is a new and safer way to record the fact
+ that you are correcting the end-of-line convention and other
+ "convert_to_git()" glitches in the in-repository data.
+
+ * "git branch" and "git checkout -b" are now forbidden from creating
+ a branch whose name is "HEAD".
+
+ * "git branch --list" learned to show its output through the pager by
+ default when the output is going to a terminal, which is controlled
+ by the pager.branch configuration variable. This is similar to a
+ recent change to "git tag --list".
+
+ * "git grep -W", "git diff -W" and their friends learned a heuristic
+ to extend a pre-context beyond the line that matches the "function
+ pattern" (aka "diff.*.xfuncname") to include a comment block, if
+ exists, that immediately precedes it.
+
+ * "git config --expiry-date gc.reflogexpire" can read "2.weeks" from
+ the configuration and report it as a timestamp, just like "--int"
+ would read "1k" and report 1024, to help consumption by scripts.
+
+ * The shell completion (in contrib/) learned that "git pull" can take
+ the "--autostash" option.
+
+ * The tagnames "git log --decorate" uses to annotate the commits can
+ now be limited to subset of available refs with the two additional
+ options, --decorate-refs[-exclude]=<pattern>.
+
+ * "git grep" compiled with libpcre2 sometimes triggered a segfault,
+ which is being fixed.
+
+ * "git send-email" tries to see if the sendmail program is available
+ in /usr/lib and /usr/sbin; extend the list of locations to be
+ checked to also include directories on $PATH.
+
+ * "git diff" learned, "--anchored", a variant of the "--patience"
+ algorithm, to which the user can specify which 'unique' line to be
+ used as anchoring points.
+
+ * The way "git worktree add" determines what branch to create from
+ where and checkout in the new worktree has been updated a bit.
+
+ * Ancient part of codebase still shows dots after an abbreviated
+ object name just to show that it is not a full object name, but
+ these ellipses are confusing to people who newly discovered Git
+ who are used to seeing abbreviated object names and find them
+ confusing with the range syntax.
+
+ * With a configuration variable rebase.abbreviateCommands set,
+ "git rebase -i" produces the todo list with a single-letter
+ command names.
+
+ * "git worktree add" learned to run the post-checkout hook, just like
+ "git checkout" does, after the initial checkout.
+
+ * "git svn" has been updated to strip CRs in the commit messages, as
+ recent versions of Subversion rejects them.
+
+ * "git imap-send" did not correctly quote the folder name when
+ making a request to the server, which has been corrected.
+
+ * Error messages from "git rebase" have been somewhat cleaned up.
+
+ * Git has been taught to support an https:// URL used for http.proxy
+ when using recent versions of libcurl.
+
+ * "git merge" learned to pay attention to merge.verifySignatures
+ configuration variable and pretend as if '--verify-signatures'
+ option was given from the command line.
+
+ * "git describe" was taught to dig trees deeper to find a
+ <commit-ish>:<path> that refers to a given blob object.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * An earlier update made it possible to use an on-stack in-core
+ lockfile structure (as opposed to having to deliberately leak an
+ on-heap one). Many codepaths have been updated to take advantage
+ of this new facility.
+
+ * Calling cmd_foo() as if it is a general purpose helper function is
+ a no-no. Correct two instances of such to set an example.
+
+ * We try to see if somebody runs our test suite with a shell that
+ does not support "local" like bash/dash does.
+
+ * An early part of piece-by-piece rewrite of "git bisect" in C.
+
+ * GSoC to piece-by-piece rewrite "git submodule" in C.
+
+ * Optimize the code to find shortest unique prefix of object names.
+
+ * Pathspec-limited revision traversal was taught not to keep finding
+ unneeded differences once it knows two trees are different inside
+ given pathspec.
+
+ * Conversion from uchar[20] to struct object_id continues.
+
+ * Code cleanup.
+
+ * A single-word "unsigned flags" in the diff options is being split
+ into a structure with many bitfields.
+
+ * TravisCI build updates.
+
+ * Parts of a test to drive the long-running content filter interface
+ has been split into its own module, hopefully to eventually become
+ reusable.
+
+ * Drop (perhaps overly cautious) sanity check before using the index
+ read from the filesystem at runtime.
+
+ * The build procedure has been taught to avoid some unnecessary
+ instability in the build products.
+
+ * A new mechanism to upgrade the wire protocol in place is proposed
+ and demonstrated that it works with the older versions of Git
+ without harming them.
+
+ * An infrastructure to define what hash function is used in Git is
+ introduced, and an effort to plumb that throughout various
+ codepaths has been started.
+
+ * The code to iterate over loose object files got optimized.
+
+ * An internal function that was left for backward compatibility has
+ been removed, as there is no remaining callers.
+
+ * Historically, the diff machinery for rename detection had a
+ hardcoded limit of 32k paths; this is being lifted to allow users
+ trade cycles with a (possibly) easier to read result.
+
+ * The tracing infrastructure has been optimized for cases where no
+ tracing is requested.
+
+ * In preparation for implementing narrow/partial clone, the object
+ walking machinery has been taught a way to tell it to "filter" some
+ objects from enumeration.
+
+ * A few structures and variables that are implementation details of
+ the decorate API have been renamed and then the API got documented
+ better.
+
+ * Assorted updates for TravisCI integration.
+ (merge 4f26366679 sg/travis-fixes later to maint).
+
+ * Introduce a helper to simplify code to parse a common pattern that
+ expects either "--key" or "--key=<something>".
+
+ * "git version --build-options" learned to report the host CPU and
+ the exact commit object name the binary was built from.
+
+Also contains various documentation updates and code clean-ups.
+
+
+Fixes since v2.15
+-----------------
+
+ * "auto" as a value for the columnar output configuration ought to
+ judge "is the output consumed by humans?" with the same criteria as
+ "auto" for coloured output configuration, i.e. either the standard
+ output stream is going to tty, or a pager is in use. We forgot the
+ latter, which has been fixed.
+
+ * The experimental "color moved lines differently in diff output"
+ feature was buggy around "ignore whitespace changes" edges, which
+ has been corrected.
+
+ * Instead of using custom line comparison and hashing functions to
+ implement "moved lines" coloring in the diff output, use the pair
+ of these functions from lower-layer xdiff/ code.
+
+ * Some codepaths did not check for errors when asking what branch the
+ HEAD points at, which have been fixed.
+
+ * "git commit", after making a commit, did not check for errors when
+ asking on what branch it made the commit, which has been corrected.
+
+ * "git status --ignored -u" did not stop at a working tree of a
+ separate project that is embedded in an ignored directory and
+ listed files in that other project, instead of just showing the
+ directory itself as ignored.
+
+ * A broken access to object databases in recent update to "git grep
+ --recurse-submodules" has been fixed.
+
+ * A recent regression in "git rebase -i" that broke execution of git
+ commands from subdirectories via "exec" instruction has been fixed.
+
+ * A (possibly flakey) test fix.
+
+ * "git check-ref-format --branch @{-1}" bit a "BUG()" when run
+ outside a repository for obvious reasons; clarify the documentation
+ and make sure we do not even try to expand the at-mark magic in
+ such a case, but still call the validation logic for branch names.
+
+ * "git fetch --recurse-submodules" now knows that submodules can be
+ moved around in the superproject in addition to getting updated,
+ and finds the ones that need to be fetched accordingly.
+
+ * Command line completion (in contrib/) update.
+
+ * Description of blame.{showroot,blankboundary,showemail,date}
+ configuration variables have been added to "git config --help".
+
+ * After an error from lstat(), diff_populate_filespec() function
+ sometimes still went ahead and used invalid data in struct stat,
+ which has been fixed.
+
+ * UNC paths are also relevant in Cygwin builds and they are now
+ tested just like Mingw builds.
+
+ * Correct start-up sequence so that a repository could be placed
+ immediately under the root directory again (which was broken at
+ around Git 2.13).
+
+ * The credential helper for libsecret (in contrib/) has been improved
+ to allow possibly prompting the end user to unlock secrets that are
+ currently locked (otherwise the secrets may not be loaded).
+
+ * MinGW updates.
+
+ * Error checking in "git imap-send" for empty response has been
+ improved.
+
+ * Recent update to the refs infrastructure implementation started
+ rewriting packed-refs file more often than before; this has been
+ optimized again for most trivial cases.
+
+ * Some error messages did not quote filenames shown in it, which have
+ been fixed.
+
+ * "git rebase -i" recently started misbehaving when a submodule that
+ is configured with 'submodule.<name>.ignore' is dirty; this has
+ been corrected.
+
+ * Building with NO_LIBPCRE1_JIT did not disable it, which has been fixed.
+
+ * We used to add an empty alternate object database to the system
+ that does not help anything; it has been corrected.
+
+ * Doc update around use of "format-patch --subject-prefix" etc.
+
+ * A fix for an ancient bug in "git apply --ignore-space-change" codepath.
+
+ * Clarify and enhance documentation for "merge-base --fork-point", as
+ it was clear what it computed but not why/what for.
+
+ * A few scripts (both in production and tests) incorrectly redirected
+ their error output. These have been corrected.
+
+ * "git notes" sent its error message to its standard output stream,
+ which was corrected.
+
+ * The three-way merge performed by "git cherry-pick" was confused
+ when a new submodule was added in the meantime, which has been
+ fixed (or "papered over").
+
+ * The sequencer machinery (used by "git cherry-pick A..B", and "git
+ rebase -i", among other things) would have lost a commit if stopped
+ due to an unlockable index file, which has been fixed.
+
+ * "git apply --inaccurate-eof" when used with "--ignore-space-change"
+ triggered an internal sanity check, which has been fixed.
+
+ * Command line completion (in contrib/) has been taught about the
+ "--copy" option of "git branch".
+
+ * When "git rebase" prepared a mailbox of changes and fed it to "git
+ am" to replay them, it was confused when a stray "From " happened
+ to be in the log message of one of the replayed changes. This has
+ been corrected.
+
+ * There was a recent semantic mismerge in the codepath to write out a
+ section of a configuration section, which has been corrected.
+
+ * Mentions of "git-rebase" and "git-am" (dashed form) still remained
+ in end-user visible strings emitted by the "git rebase" command;
+ they have been corrected.
+
+ * Contrary to the documentation, "git pull -4/-6 other-args" did not
+ ask the underlying "git fetch" to go over IPv4/IPv6, which has been
+ corrected.
+
+ * "git checkout --recursive" may overwrite and rewind the history of
+ the branch that happens to be checked out in submodule
+ repositories, which might not be desirable. Detach the HEAD but
+ still allow the recursive checkout to succeed in such a case.
+ (merge 57f22bf997 sb/submodule-recursive-checkout-detach-head later to maint).
+
+ * "git branch --set-upstream" has been deprecated and (sort of)
+ removed, as "--set-upstream-to" is the preferred one these days.
+ The documentation still had "--set-upstream" listed on its
+ synopsis section, which has been corrected.
+ (merge a060f3d3d8 tz/branch-doc-remove-set-upstream later to maint).
+
+ * Internally we use 0{40} as a placeholder object name to signal the
+ codepath that there is no such object (e.g. the fast-forward check
+ while "git fetch" stores a new remote-tracking ref says "we know
+ there is no 'old' thing pointed at by the ref, as we are creating
+ it anew" by passing 0{40} for the 'old' side), and expect that a
+ codepath to locate an in-core object to return NULL as a sign that
+ the object does not exist. A look-up for an object that does not
+ exist however is quite costly with a repository with large number
+ of packfiles. This access pattern has been optimized.
+ (merge 87b5e236a1 jk/fewer-pack-rescan later to maint).
+
+ * In addition to "git stash -m message", the command learned to
+ accept "git stash -mmessage" form.
+ (merge 5675473fcb ph/stash-save-m-option-fix later to maint).
+
+ * @{-N} in "git checkout @{-N}" may refer to a detached HEAD state,
+ but the documentation was not clear about it, which has been fixed.
+ (merge 75ce149575 ks/doc-checkout-previous later to maint).
+
+ * A regression in the progress eye-candy was fixed.
+ (merge 9c5951cacf jk/progress-delay-fix later to maint).
+
+ * The code internal to the recursive merge strategy was not fully
+ prepared to see a path that is renamed to try overwriting another
+ path that is only different in case on case insensitive systems.
+ This does not matter in the current code, but will start to matter
+ once the rename detection logic starts taking hints from nearby
+ paths moving to some directory and moves a new path along with them.
+ (merge 4cba2b0108 en/merge-recursive-icase-removal later to maint).
+
+ * An v2.12-era regression in pathspec match logic, which made it look
+ into submodule tree even when it is not desired, has been fixed.
+ (merge eef3df5a93 bw/pathspec-match-submodule-boundary later to maint).
+
+ * Amending commits in git-gui broke the author name that is non-ascii
+ due to incorrect encoding conversion.
+
+ * Recent update to the submodule configuration code broke "diff-tree"
+ by accidentally stopping to read from the index upfront.
+ (merge fd66bcc31f bw/submodule-config-cleanup later to maint).
+
+ * Git shows a message to tell the user that it is waiting for the
+ user to finish editing when spawning an editor, in case the editor
+ opens to a hidden window or somewhere obscure and the user gets
+ lost.
+ (merge abfb04d0c7 ls/editor-waiting-message later to maint).
+
+ * The "safe crlf" check incorrectly triggered for contents that does
+ not use CRLF as line endings, which has been corrected.
+ (merge 649f1f0948 tb/check-crlf-for-safe-crlf later to maint).
+
+ * "git clone --shared" to borrow from a (secondary) worktree did not
+ work, even though "git clone --local" did. Both are now accepted.
+ (merge b3b05971c1 es/clone-shared-worktree later to maint).
+
+ * The build procedure now allows not just the repositories but also
+ the refs to be used to take pre-formatted manpages and html
+ documents to install.
+ (merge 65289e9dcd rb/quick-install-doc later to maint).
+
+ * Update the shell prompt script (in contrib/) to strip trailing CR
+ from strings read from various "state" files.
+ (merge 041fe8fc83 ra/prompt-eread-fix later to maint).
+
+ * "git merge -s recursive" did not correctly abort when the index is
+ dirty, if the merged tree happened to be the same as the current
+ HEAD, which has been fixed.
+
+ * Bytes with high-bit set were encoded incorrectly and made
+ credential helper fail.
+ (merge 4c267f2ae3 jd/fix-strbuf-add-urlencode-bytes later to maint).
+
+ * "git rebase -p -X<option>" did not propagate the option properly
+ down to underlying merge strategy backend.
+ (merge dd6fb0053c js/fix-merge-arg-quoting-in-rebase-p later to maint).
+
+ * "git merge -s recursive" did not correctly abort when the index is
+ dirty, if the merged tree happened to be the same as the current
+ HEAD, which has been fixed.
+ (merge f309e8e768 ew/empty-merge-with-dirty-index-maint later to maint).
+
+ * Other minor doc, test and build updates and code cleanups.
+ (merge 1a1fc2d5b5 rd/man-prune-progress later to maint).
+ (merge 0ba014035a rd/man-reflog-add-n later to maint).
+ (merge e54b63359f rd/doc-notes-prune-fix later to maint).
+ (merge ff4c9b413a sp/doc-info-attributes later to maint).
+ (merge 7db2cbf4f1 jc/receive-pack-hook-doc later to maint).
+ (merge 5a0526264b tg/t-readme-updates later to maint).
+ (merge 5e83cca0b8 jk/no-optional-locks later to maint).
+ (merge 826c778f7c js/hashmap-update-sample later to maint).
+ (merge 176b2d328c sg/setup-doc-update later to maint).
+ (merge 1b09073514 rs/am-builtin-leakfix later to maint).
+ (merge addcf6cfde rs/fmt-merge-msg-string-leak-fix later to maint).
+ (merge c3ff8f6c14 rs/strbuf-read-once-reset-length later to maint).
+ (merge 6b0eb884f9 db/doc-workflows-neuter-the-maintainer later to maint).
+ (merge 8c87bdfb21 jk/cvsimport-quoting later to maint).
+ (merge 176cb979fe rs/fmt-merge-msg-leakfix later to maint).
+ (merge 5a03360e73 tb/delimit-pretty-trailers-args-with-comma later to maint).
+ (merge d0e6326026 ot/pretty later to maint).
+ (merge 44103f4197 sb/test-helper-excludes later to maint).
+ (merge 170078693f jt/transport-no-more-rsync later to maint).
+ (merge c07b3adff1 bw/path-doc later to maint).
+ (merge bf9d7df950 tz/lib-git-svn-svnserve-tests later to maint).
+ (merge dec366c9a8 sr/http-sslverify-config-doc later to maint).
+ (merge 3f824e91c8 jk/test-suite-tracing later to maint).
+ (merge 1feb061701 db/doc-config-section-names-with-bs later to maint).
+ (merge 74dea0e13c jh/memihash-opt later to maint).
+ (merge 2e9fdc795c ma/bisect-leakfix later to maint).
diff --git a/RelNotes/2.16.1.adoc b/RelNotes/2.16.1.adoc
new file mode 100644
index 0000000..66e6436
--- /dev/null
+++ b/RelNotes/2.16.1.adoc
@@ -0,0 +1,11 @@
+Git v2.16.1 Release Notes
+=========================
+
+Fixes since v2.16
+-----------------
+
+ * "git clone" segfaulted when cloning a project that happens to
+ track two paths that differ only in case on a case insensitive
+ filesystem.
+
+Does not contain any other documentation updates or code clean-ups.
diff --git a/RelNotes/2.16.2.adoc b/RelNotes/2.16.2.adoc
new file mode 100644
index 0000000..a216466
--- /dev/null
+++ b/RelNotes/2.16.2.adoc
@@ -0,0 +1,30 @@
+Git v2.16.2 Release Notes
+=========================
+
+Fixes since v2.16.1
+-------------------
+
+ * An old regression in "git describe --all $annotated_tag^0" has been
+ fixed.
+
+ * "git svn dcommit" did not take into account the fact that a
+ svn+ssh:// URL with a username@ (typically used for pushing) refers
+ to the same SVN repository without the username@ and failed when
+ svn.pushmergeinfo option is set.
+
+ * "git merge -Xours/-Xtheirs" learned to use our/their version when
+ resolving a conflicting updates to a symbolic link.
+
+ * "git clone $there $here" is allowed even when here directory exists
+ as long as it is an empty directory, but the command incorrectly
+ removed it upon a failure of the operation.
+
+ * "git stash -- <pathspec>" incorrectly blew away untracked files in
+ the directory that matched the pathspec, which has been corrected.
+
+ * "git add -p" was taught to ignore local changes to submodules as
+ they do not interfere with the partial addition of regular changes
+ anyway.
+
+
+Also contains various documentation updates and code clean-ups.
diff --git a/RelNotes/2.16.3.adoc b/RelNotes/2.16.3.adoc
new file mode 100644
index 0000000..f0121a8
--- /dev/null
+++ b/RelNotes/2.16.3.adoc
@@ -0,0 +1,49 @@
+Git v2.16.3 Release Notes
+=========================
+
+Fixes since v2.16.2
+-------------------
+
+ * "git status" after moving a path in the working tree (hence making
+ it appear "removed") and then adding with the -N option (hence
+ making that appear "added") detected it as a rename, but did not
+ report the old and new pathnames correctly.
+
+ * "git commit --fixup" did not allow "-m<message>" option to be used
+ at the same time; allow it to annotate resulting commit with more
+ text.
+
+ * When resetting the working tree files recursively, the working tree
+ of submodules are now also reset to match.
+
+ * Fix for a commented-out code to adjust it to a rather old API change
+ around object ID.
+
+ * When there are too many changed paths, "git diff" showed a warning
+ message but in the middle of a line.
+
+ * The http tracing code, often used to debug connection issues,
+ learned to redact potentially sensitive information from its output
+ so that it can be more safely shareable.
+
+ * Crash fix for a corner case where an error codepath tried to unlock
+ what it did not acquire lock on.
+
+ * The split-index mode had a few corner case bugs fixed.
+
+ * Assorted fixes to "git daemon".
+
+ * Completion of "git merge -s<strategy>" (in contrib/) did not work
+ well in non-C locale.
+
+ * Workaround for segfault with more recent versions of SVN.
+
+ * Recently introduced leaks in fsck have been plugged.
+
+ * Travis CI integration now builds the executable in 'script' phase
+ to follow the established practice, rather than during
+ 'before_script' phase. This allows the CI categorize the failures
+ better ('failed' is project's fault, 'errored' is build
+ environment's).
+
+Also contains various documentation updates and code clean-ups.
diff --git a/RelNotes/2.16.4.adoc b/RelNotes/2.16.4.adoc
new file mode 100644
index 0000000..6be538b
--- /dev/null
+++ b/RelNotes/2.16.4.adoc
@@ -0,0 +1,5 @@
+Git v2.16.4 Release Notes
+=========================
+
+This release is to forward-port the fixes made in the v2.13.7 version
+of Git. See its release notes for details.
diff --git a/RelNotes/2.16.5.adoc b/RelNotes/2.16.5.adoc
new file mode 100644
index 0000000..cb8ee02
--- /dev/null
+++ b/RelNotes/2.16.5.adoc
@@ -0,0 +1,6 @@
+Git v2.16.5 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.14.5 to address
+the recently reported CVE-2018-17456; see the release notes for that
+version for details.
diff --git a/RelNotes/2.16.6.adoc b/RelNotes/2.16.6.adoc
new file mode 100644
index 0000000..438306e
--- /dev/null
+++ b/RelNotes/2.16.6.adoc
@@ -0,0 +1,8 @@
+Git v2.16.6 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.14.6 and in
+v2.15.4 addressing the security issues CVE-2019-1348, CVE-2019-1349,
+CVE-2019-1350, CVE-2019-1351, CVE-2019-1352, CVE-2019-1353,
+CVE-2019-1354, and CVE-2019-1387; see the release notes for those
+versions for details.
diff --git a/RelNotes/2.17.0.adoc b/RelNotes/2.17.0.adoc
new file mode 100644
index 0000000..8b17c26
--- /dev/null
+++ b/RelNotes/2.17.0.adoc
@@ -0,0 +1,398 @@
+Git 2.17 Release Notes
+======================
+
+Updates since v2.16
+-------------------
+
+UI, Workflows & Features
+
+ * "diff" family of commands learned "--find-object=<object-id>" option
+ to limit the findings to changes that involve the named object.
+
+ * "git format-patch" learned to give 72-cols to diffstat, which is
+ consistent with other line length limits the subcommand uses for
+ its output meant for e-mails.
+
+ * The log from "git daemon" can be redirected with a new option; one
+ relevant use case is to send the log to standard error (instead of
+ syslog) when running it from inetd.
+
+ * "git rebase" learned to take "--allow-empty-message" option.
+
+ * "git am" has learned the "--quit" option, in addition to the
+ existing "--abort" option; having the pair mirrors a few other
+ commands like "rebase" and "cherry-pick".
+
+ * "git worktree add" learned to run the post-checkout hook, just like
+ "git clone" runs it upon the initial checkout.
+
+ * "git tag" learned an explicit "--edit" option that allows the
+ message given via "-m" and "-F" to be further edited.
+
+ * "git fetch --prune-tags" may be used as a handy short-hand for
+ getting rid of stale tags that are locally held.
+
+ * The new "--show-current-patch" option gives an end-user facing way
+ to get the diff being applied when "git rebase" (and "git am")
+ stops with a conflict.
+
+ * "git add -p" used to offer "/" (look for a matching hunk) as a
+ choice, even there was only one hunk, which has been corrected.
+ Also the single-key help is now given only for keys that are
+ enabled (e.g. help for '/' won't be shown when there is only one
+ hunk).
+
+ * Since Git 1.7.9, "git merge" defaulted to --no-ff (i.e. even when
+ the side branch being merged is a descendant of the current commit,
+ create a merge commit instead of fast-forwarding) when merging a
+ tag object. This was appropriate default for integrators who pull
+ signed tags from their downstream contributors, but caused an
+ unnecessary merges when used by downstream contributors who
+ habitually "catch up" their topic branches with tagged releases
+ from the upstream. Update "git merge" to default to --no-ff only
+ when merging a tag object that does *not* sit at its usual place in
+ refs/tags/ hierarchy, and allow fast-forwarding otherwise, to
+ mitigate the problem.
+
+ * "git status" can spend a lot of cycles to compute the relation
+ between the current branch and its upstream, which can now be
+ disabled with "--no-ahead-behind" option.
+
+ * "git diff" and friends learned funcname patterns for Go language
+ source files.
+
+ * "git send-email" learned "--reply-to=<address>" option.
+
+ * Funcname pattern used for C# now recognizes "async" keyword.
+
+ * In a way similar to how "git tag" learned to honor the pager
+ setting only in the list mode, "git config" learned to ignore the
+ pager setting when it is used for setting values (i.e. when the
+ purpose of the operation is not to "show").
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * More perf tests for threaded grep
+
+ * "perf" test output can be sent to codespeed server.
+
+ * The build procedure for perl/ part has been greatly simplified by
+ weaning ourselves off of MakeMaker.
+
+ * Perl 5.8 or greater has been required since Git 1.7.4 released in
+ 2010, but we continued to assume some core modules may not exist and
+ used a conditional "eval { require <<module>> }"; we no longer do
+ this. Some platforms (Fedora/RedHat/CentOS, for example) ship Perl
+ without all core modules by default (e.g. Digest::MD5, File::Temp,
+ File::Spec, Net::Domain, Net::SMTP). Users on such platforms may
+ need to install these additional modules.
+
+ * As a convenience, we install copies of Perl modules we require which
+ are not part of the core Perl distribution (e.g. Error and
+ Mail::Address). Users and packagers whose operating system provides
+ these modules can set NO_PERL_CPAN_FALLBACKS to avoid installing the
+ bundled modules.
+
+ * In preparation for implementing narrow/partial clone, the machinery
+ for checking object connectivity used by gc and fsck has been
+ taught that a missing object is OK when it is referenced by a
+ packfile specially marked as coming from trusted repository that
+ promises to make them available on-demand and lazily.
+
+ * The machinery to clone & fetch, which in turn involves packing and
+ unpacking objects, has been told how to omit certain objects using
+ the filtering mechanism introduced by another topic. It now knows
+ to mark the resulting pack as a promisor pack to tolerate missing
+ objects, laying foundation for "narrow" clones.
+
+ * The first step to getting rid of mru API and using the
+ doubly-linked list API directly instead.
+
+ * Retire mru API as it does not give enough abstraction over
+ underlying list API to be worth it.
+
+ * Rewrite two more "git submodule" subcommands in C.
+
+ * The tracing machinery learned to report tweaking of environment
+ variables as well.
+
+ * Update Coccinelle rules to catch and optimize strbuf_addf(&buf, "%s", str)
+
+ * Prevent "clang-format" from breaking line after function return type.
+
+ * The sequencer infrastructure is shared across "git cherry-pick",
+ "git rebase -i", etc., and has always spawned "git commit" when it
+ needs to create a commit. It has been taught to do so internally,
+ when able, by reusing the codepath "git commit" itself uses, which
+ gives performance boost for a few tens of percents in some sample
+ scenarios.
+
+ * Push the submodule version of collision-detecting SHA-1 hash
+ implementation a bit harder on builders.
+
+ * Avoid mmapping small files while using packed refs (especially ones
+ with zero size, which would cause later munmap() to fail).
+
+ * Conversion from uchar[20] to struct object_id continues.
+
+ * More tests for wildmatch functions.
+
+ * The code to binary search starting from a fan-out table (which is
+ how the packfile is indexed with object names) has been refactored
+ into a reusable helper.
+
+ * We now avoid using identifiers that clash with C++ keywords. Even
+ though it is not a goal to compile Git with C++ compilers, changes
+ like this help use of code analysis tools that targets C++ on our
+ codebase.
+
+ * The executable is now built in 'script' phase in Travis CI integration,
+ to follow the established practice, rather than during 'before_script'
+ phase. This allows the CI categorize the failures better ('failed'
+ is project's fault, 'errored' is build environment's).
+ (merge 3c93b82920 sg/travis-build-during-script-phase later to maint).
+
+ * Writing out the index file when the only thing that changed in it
+ is the untracked cache information is often wasteful, and this has
+ been optimized out.
+
+ * Various pieces of Perl code we have have been cleaned up.
+
+ * Internal API clean-up to allow write_locked_index() optionally skip
+ writing the in-core index when it is not modified.
+
+
+Also contains various documentation updates and code clean-ups.
+
+
+Fixes since v2.16
+-----------------
+
+ * An old regression in "git describe --all $annotated_tag^0" has been
+ fixed.
+
+ * "git status" after moving a path in the working tree (hence making
+ it appear "removed") and then adding with the -N option (hence
+ making that appear "added") detected it as a rename, but did not
+ report the old and new pathnames correctly.
+
+ * "git svn dcommit" did not take into account the fact that a
+ svn+ssh:// URL with a username@ (typically used for pushing) refers
+ to the same SVN repository without the username@ and failed when
+ svn.pushmergeinfo option is set.
+
+ * API clean-up around revision traversal.
+
+ * "git merge -Xours/-Xtheirs" learned to use our/their version when
+ resolving a conflicting updates to a symbolic link.
+
+ * "git clone $there $here" is allowed even when here directory exists
+ as long as it is an empty directory, but the command incorrectly
+ removed it upon a failure of the operation.
+
+ * "git commit --fixup" did not allow "-m<message>" option to be used
+ at the same time; allow it to annotate resulting commit with more
+ text.
+
+ * When resetting the working tree files recursively, the working tree
+ of submodules are now also reset to match.
+
+ * "git stash -- <pathspec>" incorrectly blew away untracked files in
+ the directory that matched the pathspec, which has been corrected.
+
+ * Instead of maintaining home-grown email address parsing code, ship
+ a copy of reasonably recent Mail::Address to be used as a fallback
+ in 'git send-email' when the platform lacks it.
+ (merge d60be8acab mm/send-email-fallback-to-local-mail-address later to maint).
+
+ * "git add -p" was taught to ignore local changes to submodules as
+ they do not interfere with the partial addition of regular changes
+ anyway.
+
+ * Avoid showing a warning message in the middle of a line of "git
+ diff" output.
+ (merge 4e056c989f nd/diff-flush-before-warning later to maint).
+
+ * The http tracing code, often used to debug connection issues,
+ learned to redact potentially sensitive information from its output
+ so that it can be more safely shareable.
+ (merge 8ba18e6fa4 jt/http-redact-cookies later to maint).
+
+ * Crash fix for a corner case where an error codepath tried to unlock
+ what it did not acquire lock on.
+ (merge 81fcb698e0 mr/packed-ref-store-fix later to maint).
+
+ * The split-index mode had a few corner case bugs fixed.
+ (merge ae59a4e44f tg/split-index-fixes later to maint).
+
+ * Assorted fixes to "git daemon".
+ (merge ed15e58efe jk/daemon-fixes later to maint).
+
+ * Completion of "git merge -s<strategy>" (in contrib/) did not work
+ well in non-C locale.
+ (merge 7cc763aaa3 nd/list-merge-strategy later to maint).
+
+ * Workaround for segfault with more recent versions of SVN.
+ (merge 7f6f75e97a ew/svn-branch-segfault-fix later to maint).
+
+ * Plug recently introduced leaks in fsck.
+ (merge ba3a08ca0e jt/fsck-code-cleanup later to maint).
+
+ * "git pull --rebase" did not pass verbosity setting down when
+ recursing into a submodule.
+ (merge a56771a668 sb/pull-rebase-submodule later to maint).
+
+ * The way "git reset --hard" reports the commit the updated HEAD
+ points at is made consistent with the way how the commit title is
+ generated by the other parts of the system. This matters when the
+ title is spread across physically multiple lines.
+ (merge 1cf823fb68 tg/reset-hard-show-head-with-pretty later to maint).
+
+ * Test fixes.
+ (merge 63b1a175ee sg/test-i18ngrep later to maint).
+
+ * Some bugs around "untracked cache" feature have been fixed. This
+ will notice corrupt data in the untracked cache left by old and
+ buggy code and issue a warning---the index can be fixed by clearing
+ the untracked cache from it.
+ (merge 0cacebf099 nd/fix-untracked-cache-invalidation later to maint).
+ (merge 7bf0be7501 ab/untracked-cache-invalidation-docs later to maint).
+
+ * "git blame HEAD COPYING" in a bare repository failed to run, while
+ "git blame HEAD -- COPYING" run just fine. This has been corrected.
+
+ * "git add" files in the same directory, but spelling the directory
+ path in different cases on case insensitive filesystem, corrupted
+ the name hash data structure and led to unexpected results. This
+ has been corrected.
+ (merge c95525e90d bp/name-hash-dirname-fix later to maint).
+
+ * "git rebase -p" mangled log messages of a merge commit, which is
+ now fixed.
+ (merge ed5144d7eb js/fix-merge-arg-quoting-in-rebase-p later to maint).
+
+ * Some low level protocol codepath could crash when they get an
+ unexpected flush packet, which is now fixed.
+ (merge bb1356dc64 js/packet-read-line-check-null later to maint).
+
+ * "git check-ignore" with multiple paths got confused when one is a
+ file and the other is a directory, which has been fixed.
+ (merge d60771e930 rs/check-ignore-multi later to maint).
+
+ * "git describe $garbage" stopped giving any errors when the garbage
+ happens to be a string with 40 hexadecimal letters.
+ (merge a8e7a2bf0f sb/describe-blob later to maint).
+
+ * Code to unquote single-quoted string (used in the parser for
+ configuration files, etc.) did not diagnose bogus input correctly
+ and produced bogus results instead.
+ (merge ddbbf8eb25 jk/sq-dequote-on-bogus-input later to maint).
+
+ * Many places in "git apply" knew that "/dev/null" that signals
+ "there is no such file on this side of the diff" can be followed by
+ whitespace and garbage when parsing a patch, except for one, which
+ made an otherwise valid patch (e.g. ones from subversion) rejected.
+ (merge e454ad4bec tk/apply-dev-null-verify-name-fix later to maint).
+
+ * We no longer create any *.spec file, so "make clean" should not
+ remove it.
+ (merge 4321bdcabb tz/do-not-clean-spec-file later to maint).
+
+ * "git push" over http transport did not unquote the push-options
+ correctly.
+ (merge 90dce21eb0 jk/push-options-via-transport-fix later to maint).
+
+ * "git send-email" learned to complain when the batch-size option is
+ not defined when the relogin-delay option is, since these two are
+ mutually required.
+ (merge 9caa70697b xz/send-email-batch-size later to maint).
+
+ * Y2k20 fix ;-) for our perl scripts.
+ (merge a40e06ee33 bw/perl-timegm-timelocal-fix later to maint).
+
+ * Threaded "git grep" has been optimized to avoid allocation in code
+ section that is covered under a mutex.
+ (merge 38ef24dccf rv/grep-cleanup later to maint).
+
+ * "git subtree" script (in contrib/) scripted around "git log", whose
+ output got affected by end-user configuration like log.showsignature
+ (merge 8841b5222c sg/subtree-signed-commits later to maint).
+
+ * While finding unique object name abbreviation, the code may
+ accidentally have read beyond the end of the array of object names
+ in a pack.
+ (merge 21abed500c ds/find-unique-abbrev-optim later to maint).
+
+ * Micro optimization in revision traversal code.
+ (merge ebbed3ba04 ds/mark-parents-uninteresting-optim later to maint).
+
+ * "git commit" used to run "gc --auto" near the end, which was lost
+ when the command was reimplemented in C by mistake.
+ (merge 095c741edd ab/gc-auto-in-commit later to maint).
+
+ * Allow running a couple of tests with "sh -x".
+ (merge c20bf94abc sg/cvs-tests-with-x later to maint).
+
+ * The codepath to replace an existing entry in the index had a bug in
+ updating the name hash structure, which has been fixed.
+ (merge 0e267b7a24 bp/refresh-cache-ent-rehash-fix later to maint).
+
+ * The transfer.fsckobjects configuration tells "git fetch" to
+ validate the data and connected-ness of objects in the received
+ pack; the code to perform this check has been taught about the
+ narrow clone's convention that missing objects that are reachable
+ from objects in a pack that came from a promisor remote is OK.
+
+ * There was an unused file-scope static variable left in http.c when
+ building for versions of libCURL that is older than 7.19.4, which
+ has been fixed.
+ (merge b8fd6008ec rj/http-code-cleanup later to maint).
+
+ * Shell script portability fix.
+ (merge 206a6ae013 ml/filter-branch-portability-fix later to maint).
+
+ * Other minor doc, test and build updates and code cleanups.
+ (merge e2a5a028c7 bw/oidmap-autoinit later to maint).
+ (merge ec3b4b06f8 cl/t9001-cleanup later to maint).
+ (merge e1b3f3dd38 ks/submodule-doc-updates later to maint).
+ (merge fbac558a9b rs/describe-unique-abbrev later to maint).
+ (merge 8462ff43e4 tb/crlf-conv-flags later to maint).
+ (merge 7d68bb0766 rb/hashmap-h-compilation-fix later to maint).
+ (merge 3449847168 cc/sha1-file-name later to maint).
+ (merge ad622a256f ds/use-get-be64 later to maint).
+ (merge f919ffebed sg/cocci-move-array later to maint).
+ (merge 4e801463c7 jc/mailinfo-cleanup-fix later to maint).
+ (merge ef5b3a6c5e nd/shared-index-fix later to maint).
+ (merge 9f5258cbb8 tz/doc-show-defaults-to-head later to maint).
+ (merge b780e4407d jc/worktree-add-short-help later to maint).
+ (merge ae239fc8e5 rs/cocci-strbuf-addf-to-addstr later to maint).
+ (merge 2e22a85e5c nd/ignore-glob-doc-update later to maint).
+ (merge 3738031581 jk/gettext-poison later to maint).
+ (merge 54360a1956 rj/sparse-updates later to maint).
+ (merge 12e31a6b12 sg/doc-test-must-fail-args later to maint).
+ (merge 760f1ad101 bc/doc-interpret-trailers-grammofix later to maint).
+ (merge 4ccf461f56 bp/fsmonitor later to maint).
+ (merge a6119f82b1 jk/test-hashmap-updates later to maint).
+ (merge 5aea9fe6cc rd/typofix later to maint).
+ (merge e4e5da2796 sb/status-doc-fix later to maint).
+ (merge 7976e901c8 gs/test-unset-xdg-cache-home later to maint).
+ (merge d023df1ee6 tg/worktree-create-tracking later to maint).
+ (merge 4cbe92fd41 sm/mv-dry-run-update later to maint).
+ (merge 75e5e9c3f7 sb/color-h-cleanup later to maint).
+ (merge 2708ef4af6 sg/t6300-modernize later to maint).
+ (merge d88e92d4e0 bw/doc-submodule-recurse-config-with-clone later to maint).
+ (merge f74bbc8dd2 jk/cached-commit-buffer later to maint).
+ (merge 1316416903 ms/non-ascii-ticks later to maint).
+ (merge 878056005e rs/strbuf-read-file-or-whine later to maint).
+ (merge 79f0ba1547 jk/strbuf-read-file-close-error later to maint).
+ (merge edfb8ba068 ot/ref-filter-cleanup later to maint).
+ (merge 11395a3b4b jc/test-must-be-empty later to maint).
+ (merge 768b9d6db7 mk/doc-pretty-fill later to maint).
+ (merge 2caa7b8d27 ab/man-sec-list later to maint).
+ (merge 40c17eb184 ks/t3200-typofix later to maint).
+ (merge bd9958c358 dp/merge-strategy-doc-fix later to maint).
+ (merge 9ee0540a40 js/ming-strftime later to maint).
+ (merge 1775e990f7 tz/complete-tag-delete-tagname later to maint).
+ (merge 00a4b03501 rj/warning-uninitialized-fix later to maint).
+ (merge b635ed97a0 jk/attributes-path-doc later to maint).
diff --git a/RelNotes/2.17.1.adoc b/RelNotes/2.17.1.adoc
new file mode 100644
index 0000000..e01384f
--- /dev/null
+++ b/RelNotes/2.17.1.adoc
@@ -0,0 +1,16 @@
+Git v2.17.1 Release Notes
+=========================
+
+Fixes since v2.17
+-----------------
+
+ * This release contains the same fixes made in the v2.13.7 version of
+ Git, covering CVE-2018-11233 and 11235, and forward-ported to
+ v2.14.4, v2.15.2 and v2.16.4 releases. See release notes to
+ v2.13.7 for details.
+
+ * In addition to the above fixes, this release has support on the
+ server side to reject pushes to repositories that attempt to create
+ such problematic .gitmodules file etc. as tracked contents, to help
+ hosting sites protect their customers by preventing malicious
+ contents from spreading.
diff --git a/RelNotes/2.17.2.adoc b/RelNotes/2.17.2.adoc
new file mode 100644
index 0000000..ef021be
--- /dev/null
+++ b/RelNotes/2.17.2.adoc
@@ -0,0 +1,12 @@
+Git v2.17.2 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.14.5 to address
+the recently reported CVE-2018-17456; see the release notes for that
+version for details.
+
+In addition, this release also teaches "fsck" and the server side
+logic to reject pushes to repositories that attempt to create such a
+problematic ".gitmodules" file as tracked contents, to help hosting
+sites protect their customers by preventing malicious contents from
+spreading.
diff --git a/RelNotes/2.17.3.adoc b/RelNotes/2.17.3.adoc
new file mode 100644
index 0000000..5a46c94
--- /dev/null
+++ b/RelNotes/2.17.3.adoc
@@ -0,0 +1,12 @@
+Git v2.17.3 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.14.6 and in
+v2.15.4 addressing the security issues CVE-2019-1348, CVE-2019-1349,
+CVE-2019-1350, CVE-2019-1351, CVE-2019-1352, CVE-2019-1353,
+CVE-2019-1354, and CVE-2019-1387; see the release notes for those
+versions for details.
+
+In addition, `git fsck` was taught to identify `.gitmodules` entries
+of the form `submodule.<name>.update=!command`, which have been
+disallowed in v2.15.4.
diff --git a/RelNotes/2.17.4.adoc b/RelNotes/2.17.4.adoc
new file mode 100644
index 0000000..7d794ca
--- /dev/null
+++ b/RelNotes/2.17.4.adoc
@@ -0,0 +1,16 @@
+Git v2.17.4 Release Notes
+=========================
+
+This release is to address the security issue: CVE-2020-5260
+
+Fixes since v2.17.3
+-------------------
+
+ * With a crafted URL that contains a newline in it, the credential
+ helper machinery can be fooled to give credential information for
+ a wrong host. The attack has been made impossible by forbidding
+ a newline character in any value passed via the credential
+ protocol.
+
+Credit for finding the vulnerability goes to Felix Wilhelm of Google
+Project Zero.
diff --git a/RelNotes/2.17.5.adoc b/RelNotes/2.17.5.adoc
new file mode 100644
index 0000000..2abb821
--- /dev/null
+++ b/RelNotes/2.17.5.adoc
@@ -0,0 +1,22 @@
+Git v2.17.5 Release Notes
+=========================
+
+This release is to address a security issue: CVE-2020-11008
+
+Fixes since v2.17.4
+-------------------
+
+ * With a crafted URL that contains a newline or empty host, or lacks
+ a scheme, the credential helper machinery can be fooled into
+ providing credential information that is not appropriate for the
+ protocol in use and host being contacted.
+
+ Unlike the vulnerability CVE-2020-5260 fixed in v2.17.4, the
+ credentials are not for a host of the attacker's choosing; instead,
+ they are for some unspecified host (based on how the configured
+ credential helper handles an absent "host" parameter).
+
+ The attack has been made impossible by refusing to work with
+ under-specified credential patterns.
+
+Credit for finding the vulnerability goes to Carlo Arenas.
diff --git a/RelNotes/2.17.6.adoc b/RelNotes/2.17.6.adoc
new file mode 100644
index 0000000..2f181e8
--- /dev/null
+++ b/RelNotes/2.17.6.adoc
@@ -0,0 +1,16 @@
+Git v2.17.6 Release Notes
+=========================
+
+This release addresses the security issues CVE-2021-21300.
+
+Fixes since v2.17.5
+-------------------
+
+ * CVE-2021-21300:
+ On case-insensitive file systems with support for symbolic links,
+ if Git is configured globally to apply delay-capable clean/smudge
+ filters (such as Git LFS), Git could be fooled into running
+ remote code during a clone.
+
+Credit for finding and fixing this vulnerability goes to Matheus
+Tavares, helped by Johannes Schindelin.
diff --git a/RelNotes/2.18.0.adoc b/RelNotes/2.18.0.adoc
new file mode 100644
index 0000000..6c8a0e9
--- /dev/null
+++ b/RelNotes/2.18.0.adoc
@@ -0,0 +1,583 @@
+Git 2.18 Release Notes
+======================
+
+Updates since v2.17
+-------------------
+
+UI, Workflows & Features
+
+ * Rename detection logic that is used in "merge" and "cherry-pick" has
+ learned to guess when all of x/a, x/b and x/c have moved to z/a,
+ z/b and z/c, it is likely that x/d added in the meantime would also
+ want to move to z/d by taking the hint that the entire directory
+ 'x' moved to 'z'. A bug causing dirty files involved in a rename
+ to be overwritten during merge has also been fixed as part of this
+ work. Incidentally, this also avoids updating a file in the
+ working tree after a (non-trivial) merge whose result matches what
+ our side originally had.
+
+ * "git filter-branch" learned to use a different exit code to allow
+ the callers to tell the case where there was no new commits to
+ rewrite from other error cases.
+
+ * When built with more recent cURL, GIT_SSL_VERSION can now specify
+ "tlsv1.3" as its value.
+
+ * "git gui" learned that "~/.ssh/id_ecdsa.pub" and
+ "~/.ssh/id_ed25519.pub" are also possible SSH key files.
+ (merge 2e2f0288ef bb/git-gui-ssh-key-files later to maint).
+
+ * "git gui" performs commit upon CTRL/CMD+ENTER but the
+ CTRL/CMD+KP_ENTER (i.e. enter key on the numpad) did not have the
+ same key binding. It now does.
+ (merge 28a1d94a06 bp/git-gui-bind-kp-enter later to maint).
+
+ * "git gui" has been taught to work with old versions of tk (like
+ 8.5.7) that do not support "ttk::style theme use" as a way to query
+ the current theme.
+ (merge 4891961105 cb/git-gui-ttk-style later to maint).
+
+ * "git rebase" has learned to honor "--signoff" option when using
+ backends other than "am" (but not "--preserve-merges").
+
+ * "git branch --list" during an interrupted "rebase -i" now lets
+ users distinguish the case where a detached HEAD is being rebased
+ and a normal branch is being rebased.
+
+ * "git mergetools" learned talking to guiffy.
+
+ * The scripts in contrib/emacs/ have outlived their usefulness and
+ have been replaced with a stub that errors out and tells the user
+ there are replacements.
+
+ * The new "working-tree-encoding" attribute can ask Git to convert the
+ contents to the specified encoding when checking out to the working
+ tree (and the other way around when checking in).
+
+ * The "git config" command uses separate options e.g. "--int",
+ "--bool", etc. to specify what type the caller wants the value to
+ be interpreted as. A new "--type=<typename>" option has been
+ introduced, which would make it cleaner to define new types.
+
+ * "git config --get" learned the "--default" option, to help the
+ calling script. Building on top of the above changes, the
+ "git config" learns "--type=color" type. Taken together, you can
+ do things like "git config --get foo.color --default blue" and get
+ the ANSI color sequence for the color given to foo.color variable,
+ or "blue" if the variable does not exist.
+
+ * "git ls-remote" learned an option to allow sorting its output based
+ on the refnames being shown.
+
+ * The command line completion (in contrib/) has been taught that "git
+ stash save" has been deprecated ("git stash push" is the preferred
+ spelling in the new world) and does not offer it as a possible
+ completion candidate when "git stash push" can be.
+
+ * "git gc --prune=nonsense" spent long time repacking and then
+ silently failed when underlying "git prune --expire=nonsense"
+ failed to parse its command line. This has been corrected.
+
+ * Error messages from "git push" can be painted for more visibility.
+
+ * "git http-fetch" (deprecated) had an optional and experimental
+ "feature" to fetch only commits and/or trees, which nobody used.
+ This has been removed.
+
+ * The functionality of "$GIT_DIR/info/grafts" has been superseded by
+ the "refs/replace/" mechanism for some time now, but the internal
+ code had support for it in many places, which has been cleaned up
+ in order to drop support of the "grafts" mechanism.
+
+ * "git worktree add" learned to check out an existing branch.
+
+ * "git --no-pager cmd" did not have short-and-sweet single letter
+ option. Now it does as "-P".
+ (merge 7213c28818 js/no-pager-shorthand later to maint).
+
+ * "git rebase" learned "--rebase-merges" to transplant the whole
+ topology of commit graph elsewhere.
+
+ * "git status" learned to pay attention to UI related diff
+ configuration variables such as diff.renames.
+
+ * The command line completion mechanism (in contrib/) learned to load
+ custom completion file for "git $command" where $command is a
+ custom "git-$command" that the end user has on the $PATH when using
+ newer version of bash-completion.
+
+ * "git send-email" can sometimes offer confirmation dialog "Send this
+ email?" with choices 'Yes', 'No', 'Quit', and 'All'. A new action
+ 'Edit' has been added to this dialog's choice.
+
+ * With merge.renames configuration set to false, the recursive merge
+ strategy can be told not to spend cycles trying to find renamed
+ paths and merge them accordingly.
+
+ * "git status" learned to honor a new status.renames configuration to
+ skip rename detection, which could be useful for those who want to
+ do so without disabling the default rename detection done by the
+ "git diff" command.
+
+ * Command line completion (in contrib/) learned to complete pathnames
+ for various commands better.
+
+ * "git blame" learns to unhighlight uninteresting metadata from the
+ originating commit on lines that are the same as the previous one,
+ and also paint lines in different colors depending on the age of
+ the commit.
+
+ * Transfer protocol v2 learned to support the partial clone.
+
+ * When a short hexadecimal string is used to name an object but there
+ are multiple objects that share the string as the prefix of their
+ names, the code lists these ambiguous candidates in a help message.
+ These object names are now sorted according to their types for
+ easier eyeballing.
+
+ * "git fetch $there $refspec" that talks over protocol v2 can take
+ advantage of server-side ref filtering; the code has been extended
+ so that this mechanism triggers also when fetching with configured
+ refspec.
+
+ * Our HTTP client code used to advertise that we accept gzip encoding
+ from the other side; instead, just let cURL library to advertise
+ and negotiate the best one.
+
+ * "git p4" learned to "unshelve" shelved commit from P4.
+ (merge 123f631761 ld/p4-unshelve later to maint).
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * A "git fetch" from a repository with insane number of refs into a
+ repository that is already up-to-date still wasted too many cycles
+ making many lstat(2) calls to see if these objects at the tips
+ exist as loose objects locally. These lstat(2) calls are optimized
+ away by enumerating all loose objects beforehand.
+ It is unknown if the new strategy negatively affects existing use
+ cases, fetching into a repository with many loose objects from a
+ repository with small number of refs.
+
+ * Git can be built to use either v1 or v2 of the PCRE library, and so
+ far, the build-time configuration USE_LIBPCRE=YesPlease instructed
+ the build procedure to use v1, but now it means v2. USE_LIBPCRE1
+ and USE_LIBPCRE2 can be used to explicitly choose which version to
+ use, as before.
+
+ * The build procedure learned to optionally use symbolic links
+ (instead of hardlinks and copies) to install "git-foo" for built-in
+ commands, whose binaries are all identical.
+
+ * Conversion from uchar[20] to struct object_id continues.
+
+ * The way "git worktree prune" worked internally has been simplified,
+ by assuming how "git worktree move" moves an existing worktree to a
+ different place.
+
+ * Code clean-up for the "repository" abstraction.
+ (merge 00a3da2a13 nd/remove-ignore-env-field later to maint).
+
+ * Code to find the length to uniquely abbreviate object names based
+ on packfile content, which is a relatively recent addition, has been
+ optimized to use the same fan-out table.
+
+ * The mechanism to use parse-options API to automate the command line
+ completion continues to get extended and polished.
+
+ * Copies of old scripted Porcelain commands in contrib/examples/ have
+ been removed.
+
+ * Some tests that rely on the exact hardcoded values of object names
+ have been updated in preparation for hash function migration.
+
+ * Perf-test update.
+
+ * Test helper update.
+
+ * The effort continues to refactor the internal global data structure
+ to make it possible to open multiple repositories, work with and
+ then close them,
+
+ * Small test-helper programs have been consolidated into a single
+ binary.
+
+ * API clean-up around ref-filter code.
+
+ * Shell completion (in contrib) that gives list of paths have been
+ optimized somewhat.
+
+ * The index file is updated to record the fsmonitor section after a
+ full scan was made, to avoid wasting the effort that has already
+ spent.
+
+ * Performance measuring framework in t/perf learned to help bisecting
+ performance regressions.
+
+ * Some multi-word source filenames are being renamed to separate
+ words with dashes instead of underscores.
+
+ * An reusable "memory pool" implementation has been extracted from
+ fast-import.c, which in turn has become the first user of the
+ mem-pool API.
+
+ * A build-time option has been added to allow Git to be told to refer
+ to its associated files relative to the main binary, in the same
+ way that has been possible on Windows for quite some time, for
+ Linux, BSDs and Darwin.
+
+ * Precompute and store information necessary for ancestry traversal
+ in a separate file to optimize graph walking.
+
+ * The effort to pass the repository in-core structure throughout the
+ API continues. This round deals with the code that implements the
+ refs/replace/ mechanism.
+
+ * The build procedure "make DEVELOPER=YesPlease" learned to enable a
+ bit more warning options depending on the compiler used to help
+ developers more. There also is "make DEVOPTS=tokens" knob
+ available now, for those who want to help fixing warnings we
+ usually ignore, for example.
+
+ * A new version of the transport protocol is being worked on.
+
+ * The code to interface to GPG has been restructured somewhat to make
+ it cleaner to integrate with other types of signature systems later.
+
+ * The code has been taught to use the duplicated information stored
+ in the commit-graph file to learn the tree object name for a commit
+ to avoid opening and parsing the commit object when it makes sense
+ to do so.
+
+ * "git gc" in a large repository takes a lot of time as it considers
+ to repack all objects into one pack by default. The command has
+ been taught to pretend as if the largest existing packfile is
+ marked with ".keep" so that it is left untouched while objects in
+ other packs and loose ones are repacked.
+
+ * The transport protocol v2 is getting updated further.
+
+ * The codepath around object-info API has been taught to take the
+ repository object (which in turn tells the API which object store
+ the objects are to be located).
+
+ * "git pack-objects" needs to allocate tons of "struct object_entry"
+ while doing its work, and shrinking its size helps the performance
+ quite a bit.
+
+ * The implementation of "git rebase -i --root" has been updated to use
+ the sequencer machinery more.
+
+ * Developer support update, by using BUG() macro instead of die() to
+ mark codepaths that should not happen more clearly.
+
+ * Developer support. Use newer GCC on one of the builds done at
+ TravisCI.org to get more warnings and errors diagnosed.
+
+ * Conversion from uchar[20] to struct object_id continues.
+
+ * By code restructuring of submodule merge in merge-recursive,
+ informational messages from the codepath are now given using the
+ same mechanism as other output, and honor the merge.verbosity
+ configuration. The code also learned to give a few new messages
+ when a submodule three-way merge resolves cleanly when one side
+ records a descendant of the commit chosen by the other side.
+
+ * Avoid unchecked snprintf() to make future code auditing easier.
+ (merge ac4896f007 jk/snprintf-truncation later to maint).
+
+ * Many tests hardcode the raw object names, which would change once
+ we migrate away from SHA-1. While some of them must test against
+ exact object names, most of them do not have to use hardcoded
+ constants in the test. The latter kind of tests have been updated
+ to test the moral equivalent of the original without hardcoding the
+ actual object names.
+
+ * The list of commands with their various attributes were spread
+ across a few places in the build procedure, but it now is getting a
+ bit more consolidated to allow more automation.
+
+ * Quite a many tests assumed that newly created refs are made as
+ loose refs using the files backend, which have been updated to use
+ proper plumbing like rev-parse and update-ref, to avoid breakage
+ once we start using different ref backends.
+
+
+Also contains various documentation updates and code clean-ups.
+
+
+Fixes since v2.17
+-----------------
+
+ * "git shortlog cruft" aborted with a BUG message when run outside a
+ Git repository. The command has been taught to complain about
+ extra and unwanted arguments on its command line instead in such a
+ case.
+ (merge 4aa0161e83 ma/shortlog-revparse later to maint).
+
+ * "git stash push -u -- <pathspec>" gave an unnecessary and confusing
+ error message when there was no tracked files that match the
+ <pathspec>, which has been fixed.
+ (merge 353278687e tg/stash-untracked-with-pathspec-fix later to maint).
+
+ * "git tag --contains no-such-commit" gave a full list of options
+ after giving an error message.
+ (merge 3bb0923f06 ps/contains-id-error-message later to maint).
+
+ * "diff-highlight" filter (in contrib/) learned to understand "git log
+ --graph" output better.
+ (merge 4551fbba14 jk/diff-highlight-graph-fix later to maint).
+
+ * when refs that do not point at committish are given, "git
+ filter-branch" gave a misleading error messages. This has been
+ corrected.
+ (merge f78ab355e7 yk/filter-branch-non-committish-refs later to maint).
+
+ * "git submodule status" misbehaved on a submodule that has been
+ removed from the working tree.
+ (merge 74b6bda32f rs/status-with-removed-submodule later to maint).
+
+ * When credential helper exits very quickly without reading its
+ input, it used to cause Git to die with SIGPIPE, which has been
+ fixed.
+ (merge a0d51e8d0e eb/cred-helper-ignore-sigpipe later to maint).
+
+ * "git rebase --keep-empty" still removed an empty commit if the
+ other side contained an empty commit (due to the "does an
+ equivalent patch exist already?" check), which has been corrected.
+ (merge 3d946165e1 pw/rebase-keep-empty-fixes later to maint).
+
+ * Some codepaths, including the refs API, get and keep relative
+ paths, that go out of sync when the process does chdir(2). The
+ chdir-notify API is introduced to let these codepaths adjust these
+ cached paths to the new current directory.
+ (merge fb9c2d2703 jk/relative-directory-fix later to maint).
+
+ * "cd sub/dir && git commit ../path" ought to record the changes to
+ the file "sub/path", but this regressed long time ago.
+ (merge 86238e07ef bw/commit-partial-from-subdirectory-fix later to maint).
+
+ * Recent introduction of "--log-destination" option to "git daemon"
+ did not work well when the daemon was run under "--inetd" mode.
+ (merge e67d906d73 lw/daemon-log-destination later to maint).
+
+ * Small fix to the autoconf build procedure.
+ (merge 249482daf0 es/fread-reads-dir-autoconf-fix later to maint).
+
+ * Fix an unexploitable (because the oversized contents are not under
+ attacker's control) buffer overflow.
+ (merge d8579accfa bp/fsmonitor-bufsize-fix later to maint).
+
+ * Recent simplification of build procedure forgot a bit of tweak to
+ the build procedure of contrib/mw-to-git/
+ (merge d8698987f3 ab/simplify-perl-makefile later to maint).
+
+ * Moving a submodule that itself has submodule in it with "git mv"
+ forgot to make necessary adjustment to the nested sub-submodules;
+ now the codepath learned to recurse into the submodules.
+
+ * "git config --unset a.b", when "a.b" is the last variable in an
+ otherwise empty section "a", left an empty section "a" behind, and
+ worse yet, a subsequent "git config a.c value" did not reuse that
+ empty shell and instead created a new one. These have been
+ (partially) corrected.
+ (merge c71d8bb38a js/empty-config-section-fix later to maint).
+
+ * "git worktree remove" learned that "-f" is a shorthand for
+ "--force" option, just like for "git worktree add".
+ (merge d228eea514 sb/worktree-remove-opt-force later to maint).
+
+ * The completion script (in contrib/) learned to clear cached list of
+ command line options upon dot-sourcing it again in a more efficient
+ way.
+ (merge 94408dc71c sg/completion-clear-cached later to maint).
+
+ * "git svn" had a minor thinko/typo which has been fixed.
+ (merge 51db271587 ab/git-svn-get-record-typofix later to maint).
+
+ * During a "rebase -i" session, the code could give older timestamp
+ to commits created by later "pick" than an earlier "reword", which
+ has been corrected.
+ (merge 12f7babd6b js/ident-date-fix later to maint).
+
+ * "git submodule status" did not check the symbolic revision name it
+ computed for the submodule HEAD is not the NULL, and threw it at
+ printf routines, which has been corrected.
+ (merge 0b5e2ea7cf nd/submodule-status-fix later to maint).
+
+ * When fed input that already has In-Reply-To: and/or References:
+ headers and told to add the same information, "git send-email"
+ added these headers separately, instead of appending to an existing
+ one, which is a violation of the RFC. This has been corrected.
+ (merge 256be1d3f0 sa/send-email-dedup-some-headers later to maint).
+
+ * "git fast-export" had a regression in v2.15.0 era where it skipped
+ some merge commits in certain cases, which has been corrected.
+ (merge be011bbe00 ma/fast-export-skip-merge-fix later to maint).
+
+ * The code did not propagate the terminal width to subprocesses via
+ COLUMNS environment variable, which it now does. This caused
+ trouble to "git column" helper subprocess when "git tag --column=row"
+ tried to list the existing tags on a display with non-default width.
+ (merge b5d5a567fb nd/term-columns later to maint).
+
+ * We learned that our source files with ".pl" and ".py" extensions
+ are Perl and Python files respectively and changes to them are
+ better viewed as such with appropriate diff drivers.
+ (merge 7818b619e2 ab/perl-python-attrs later to maint).
+
+ * "git rebase -i" sometimes left intermediate "# This is a
+ combination of N commits" message meant for the human consumption
+ inside an editor in the final result in certain corner cases, which
+ has been fixed.
+ (merge 15ef69314d js/rebase-i-clean-msg-after-fixup-continue later to maint).
+
+ * A test to see if the filesystem normalizes UTF-8 filename has been
+ updated to check what we need to know in a more direct way, i.e. a
+ path created in NFC form can be accessed with NFD form (or vice
+ versa) to cope with APFS as well as HFS.
+ (merge 742ae10e35 tb/test-apfs-utf8-normalization later to maint).
+
+ * "git format-patch --cover --attach" created a broken MIME multipart
+ message for the cover letter, which has been fixed by keeping the
+ cover letter as plain text file.
+ (merge 50cd54ef4e bc/format-patch-cover-no-attach later to maint).
+
+ * The split-index feature had a long-standing and dormant bug in
+ certain use of the in-core merge machinery, which has been fixed.
+ (merge 7db118303a en/unpack-trees-split-index-fix later to maint).
+
+ * Asciidoctor gives a reasonable imitation for AsciiDoc, but does not
+ render illustration in a literal block correctly when indented with
+ HT by default. The problem is fixed by forcing 8-space tabs.
+ (merge 379805051d bc/asciidoctor-tab-width later to maint).
+
+ * Code clean-up to adjust to a more recent lockfile API convention that
+ allows lockfile instances kept on the stack.
+ (merge 0fa5a2ed8d ma/lockfile-cleanup later to maint).
+
+ * the_repository->index is not a allocated piece of memory but
+ repo_clear() indiscriminately attempted to free(3) it, which has
+ been corrected.
+ (merge 74373b5f10 nd/repo-clear-keep-the-index later to maint).
+
+ * Code clean-up to avoid non-standard-conformant pointer arithmetic.
+ (merge c112084af9 rs/no-null-ptr-arith-in-fast-export later to maint).
+
+ * Code clean-up to turn history traversal more robust in a
+ semi-corrupt repository.
+ (merge 8702b30fd7 jk/unavailable-can-be-missing later to maint).
+
+ * "git update-ref A B" is supposed to ensure that ref A does not yet
+ exist when B is a NULL OID, but this check was not done correctly
+ for pseudo-refs outside refs/ hierarchy, e.g. MERGE_HEAD.
+
+ * "git submodule update" and "git submodule add" supported the
+ "--reference" option to borrow objects from a neighbouring local
+ repository like "git clone" does, but lacked the more recent
+ invention "--dissociate". Also "git submodule add" has been taught
+ to take the "--progress" option.
+ (merge a0ef29341a cf/submodule-progress-dissociate later to maint).
+
+ * Update credential-netrc helper (in contrib/) to allow customizing
+ the GPG used to decrypt the encrypted .netrc file.
+ (merge 786ef50a23 lm/credential-netrc later to maint).
+
+ * "git submodule update" attempts two different kinds of "git fetch"
+ against the upstream repository to grab a commit bound at the
+ submodule's path, but it incorrectly gave up if the first kind
+ (i.e. a normal fetch) failed, making the second "last resort" one
+ (i.e. fetching an exact commit object by object name) ineffective.
+ This has been corrected.
+ (merge e30d833671 sb/submodule-update-try-harder later to maint).
+
+ * Error behaviour of "git grep" when it cannot read the index was
+ inconsistent with other commands that uses the index, which has
+ been corrected to error out early.
+ (merge b2aa84c789 sb/grep-die-on-unreadable-index later to maint).
+
+ * We used to call regfree() after regcomp() failed in some codepaths,
+ which have been corrected.
+ (merge 17154b1576 ma/regex-no-regfree-after-comp-fail later to maint).
+
+ * The import-tars script (in contrib/) has been taught to handle
+ tarballs with overly long paths that use PAX extended headers.
+ (merge 12ecea46e3 pa/import-tars-long-names later to maint).
+
+ * "git rev-parse Y..." etc. misbehaved when given endpoints were
+ not committishes.
+ (merge 0ed556d38f en/rev-parse-invalid-range later to maint).
+
+ * "git pull --recurse-submodules --rebase", when the submodule
+ repository's history did not have anything common between ours and
+ the upstream's, failed to execute. We need to fetch from them to
+ continue even in such a case.
+ (merge 4d36f88be7 jt/submodule-pull-recurse-rebase later to maint).
+
+ * "git remote update" can take both a single remote nickname and a
+ nickname for remote groups, but only one of them was documented.
+ (merge a97447a42a nd/remote-update-doc later to maint).
+
+ * "index-pack --strict" has been taught to make sure that it runs the
+ final object integrity checks after making the freshly indexed
+ packfile available to itself.
+ (merge 3737746120 jk/index-pack-maint later to maint).
+
+ * Make zlib inflate codepath more robust against versions of zlib
+ that clobber unused portion of outbuf.
+ (merge b611396e97 jl/zlib-restore-nul-termination later to maint).
+
+ * Fix old merge glitch in Documentation during v2.13-rc0 era.
+ (merge 28cb06020b mw/doc-merge-enumfix later to maint).
+
+ * The code to read compressed bitmap was not careful to avoid reading
+ past the end of the file, which has been corrected.
+ (merge 1140bf01ec jk/ewah-bounds-check later to maint).
+
+ * "make NO_ICONV=NoThanks" did not override NEEDS_LIBICONV
+ (i.e. linkage of -lintl, -liconv, etc. that are platform-specific
+ tweaks), which has been corrected.
+ (merge fdb1fbbc7d es/make-no-iconv later to maint).
+
+ * Other minor doc, test and build updates and code cleanups.
+ (merge 248f66ed8e nd/trace-with-env later to maint).
+ (merge 14ced5562c ys/bisect-object-id-missing-conversion-fix later to maint).
+ (merge 5988eb631a ab/doc-hash-brokenness later to maint).
+ (merge a4d4e32a70 pk/test-avoid-pipe-hiding-exit-status later to maint).
+ (merge 05e293c1ac jk/flockfile-stdio later to maint).
+ (merge e9184b0789 jk/t5561-missing-curl later to maint).
+ (merge b1801b85a3 nd/worktree-move later to maint).
+ (merge bbd374dd20 ak/bisect-doc-typofix later to maint).
+ (merge 4855f06fb3 mn/send-email-credential-doc later to maint).
+ (merge 8523b1e355 en/doc-typoes later to maint).
+ (merge 43b44ccfe7 js/t5404-path-fix later to maint).
+ (merge decf711fc1 ps/test-chmtime-get later to maint).
+ (merge 22d11a6e8e es/worktree-docs later to maint).
+ (merge 92a5dbbc22 tg/use-git-contacts later to maint).
+ (merge adc887221f tq/t1510 later to maint).
+ (merge bed21a8ad6 sg/doc-gc-quote-mismatch-fix later to maint).
+ (merge 73364e4f10 tz/doc-git-urls-reference later to maint).
+ (merge cd1e606bad bc/mailmap-self later to maint).
+ (merge f7997e3682 ao/config-api-doc later to maint).
+ (merge ee930754d8 jk/apply-p-doc later to maint).
+ (merge 011b648646 nd/pack-format-doc later to maint).
+ (merge 87a6bb701a sg/t5310-jgit-bitmap-test later to maint).
+ (merge f6b82970aa sg/t5516-fixes later to maint).
+ (merge 4362da078e sg/t7005-spaces-in-filenames-cleanup later to maint).
+ (merge 7d0ee47c11 js/test-unset-prereq later to maint).
+ (merge 5356a3c354 ah/misc-doc-updates later to maint).
+ (merge 92c4a7a129 nd/completion-aliasfiletype-typofix later to maint).
+ (merge 58bd77b66a nd/pack-unreachable-objects-doc later to maint).
+ (merge 4ed79d5203 sg/t6500-no-redirect-of-stdin later to maint).
+ (merge 17b8a2d6cd jk/config-blob-sans-repo later to maint).
+ (merge 590551ca2c rd/tag-doc-lightweight later to maint).
+ (merge 44f560fc16 rd/init-typo later to maint).
+ (merge f156a0934a rd/p4-doc-markup-env later to maint).
+ (merge 2a00502b14 tg/doc-sec-list later to maint).
+ (merge 47cc91310a jk/submodule-fsck-loose-fixup later to maint).
+ (merge efde7b725c rd/comment-typofix-in-sha1-file later to maint).
+ (merge 7eedad15df rd/diff-options-typofix later to maint).
+ (merge 58ebd936cc km/doc-workflows-typofix later to maint).
+ (merge 30aa96cdf8 rd/doc-remote-tracking-with-hyphen later to maint).
+ (merge cf317877e3 ks/branch-set-upstream later to maint).
+ (merge 8de19d6be8 sg/t7406-chain-fix later to maint).
diff --git a/RelNotes/2.18.1.adoc b/RelNotes/2.18.1.adoc
new file mode 100644
index 0000000..2098cdd
--- /dev/null
+++ b/RelNotes/2.18.1.adoc
@@ -0,0 +1,6 @@
+Git v2.18.1 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.14.5 and in
+v2.17.2 to address the recently reported CVE-2018-17456; see the
+release notes for those versions for details.
diff --git a/RelNotes/2.18.2.adoc b/RelNotes/2.18.2.adoc
new file mode 100644
index 0000000..98b168a
--- /dev/null
+++ b/RelNotes/2.18.2.adoc
@@ -0,0 +1,8 @@
+Git v2.18.2 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.14.6, v2.15.4
+and in v2.17.3, addressing the security issues CVE-2019-1348,
+CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, CVE-2019-1352,
+CVE-2019-1353, CVE-2019-1354, and CVE-2019-1387; see the release notes
+for those versions for details.
diff --git a/RelNotes/2.18.3.adoc b/RelNotes/2.18.3.adoc
new file mode 100644
index 0000000..25143f0
--- /dev/null
+++ b/RelNotes/2.18.3.adoc
@@ -0,0 +1,5 @@
+Git v2.18.3 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.17.4; see
+the release notes for that version for details.
diff --git a/RelNotes/2.18.4.adoc b/RelNotes/2.18.4.adoc
new file mode 100644
index 0000000..e8ef858
--- /dev/null
+++ b/RelNotes/2.18.4.adoc
@@ -0,0 +1,5 @@
+Git v2.18.4 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.17.5; see
+the release notes for that version for details.
diff --git a/RelNotes/2.18.5.adoc b/RelNotes/2.18.5.adoc
new file mode 100644
index 0000000..dfb1de4
--- /dev/null
+++ b/RelNotes/2.18.5.adoc
@@ -0,0 +1,6 @@
+Git v2.18.5 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.17.6 to address
+the security issue CVE-2021-21300; see the release notes for that
+version for details.
diff --git a/RelNotes/2.19.0.adoc b/RelNotes/2.19.0.adoc
new file mode 100644
index 0000000..891c79b
--- /dev/null
+++ b/RelNotes/2.19.0.adoc
@@ -0,0 +1,615 @@
+Git 2.19 Release Notes
+======================
+
+Updates since v2.18
+-------------------
+
+UI, Workflows & Features
+
+ * "git diff" compares the index and the working tree. For paths
+ added with intent-to-add bit, the command shows the full contents
+ of them as added, but the paths themselves were not marked as new
+ files. They are now shown as new by default.
+
+ "git apply" learned the "--intent-to-add" option so that an
+ otherwise working-tree-only application of a patch will add new
+ paths to the index marked with the "intent-to-add" bit.
+
+ * "git grep" learned the "--column" option that gives not just the
+ line number but the column number of the hit.
+
+ * The "-l" option in "git branch -l" is an unfortunate short-hand for
+ "--create-reflog", but many users, both old and new, somehow expect
+ it to be something else, perhaps "--list". This step warns when "-l"
+ is used as a short-hand for "--create-reflog" and warns about the
+ future repurposing of the it when it is used.
+
+ * The userdiff pattern for .php has been updated.
+
+ * The content-transfer-encoding of the message "git send-email" sends
+ out by default was 8bit, which can cause trouble when there is an
+ overlong line to bust RFC 5322/2822 limit. A new option 'auto' to
+ automatically switch to quoted-printable when there is such a line
+ in the payload has been introduced and is made the default.
+
+ * "git checkout" and "git worktree add" learned to honor
+ checkout.defaultRemote when auto-vivifying a local branch out of a
+ remote tracking branch in a repository with multiple remotes that
+ have tracking branches that share the same names.
+ (merge 8d7b558bae ab/checkout-default-remote later to maint).
+
+ * "git grep" learned the "--only-matching" option.
+
+ * "git rebase --rebase-merges" mode now handles octopus merges as
+ well.
+
+ * Add a server-side knob to skip commits in exponential/fibbonacci
+ stride in an attempt to cover wider swath of history with a smaller
+ number of iterations, potentially accepting a larger packfile
+ transfer, instead of going back one commit a time during common
+ ancestor discovery during the "git fetch" transaction.
+ (merge 42cc7485a2 jt/fetch-negotiator-skipping later to maint).
+
+ * A new configuration variable core.usereplacerefs has been added,
+ primarily to help server installations that want to ignore the
+ replace mechanism altogether.
+
+ * Teach "git tag -s" etc. a few configuration variables (gpg.format
+ that can be set to "openpgp" or "x509", and gpg.<format>.program
+ that is used to specify what program to use to deal with the format)
+ to allow x.509 certs with CMS via "gpgsm" to be used instead of
+ openpgp via "gnupg".
+
+ * Many more strings are prepared for l10n.
+
+ * "git p4 submit" learns to ask its own pre-submit hook if it should
+ continue with submitting.
+
+ * The test performed at the receiving end of "git push" to prevent
+ bad objects from entering repository can be customized via
+ receive.fsck.* configuration variables; we now have gained a
+ counterpart to do the same on the "git fetch" side, with
+ fetch.fsck.* configuration variables.
+
+ * "git pull --rebase=interactive" learned "i" as a short-hand for
+ "interactive".
+
+ * "git instaweb" has been adjusted to run better with newer Apache on
+ RedHat based distros.
+
+ * "git range-diff" is a reimplementation of "git tbdiff" that lets us
+ compare individual patches in two iterations of a topic.
+
+ * The sideband code learned to optionally paint selected keywords at
+ the beginning of incoming lines on the receiving end.
+
+ * "git branch --list" learned to take the default sort order from the
+ 'branch.sort' configuration variable, just like "git tag --list"
+ pays attention to 'tag.sort'.
+
+ * "git worktree" command learned "--quiet" option to make it less
+ verbose.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * The bulk of "git submodule foreach" has been rewritten in C.
+
+ * The in-core "commit" object had an all-purpose "void *util" field,
+ which was tricky to use especially in library-ish part of the
+ code. All of the existing uses of the field has been migrated to a
+ more dedicated "commit-slab" mechanism and the field is eliminated.
+
+ * A less often used command "git show-index" has been modernized.
+ (merge fb3010c31f jk/show-index later to maint).
+
+ * The conversion to pass "the_repository" and then "a_repository"
+ throughout the object access API continues.
+
+ * Continuing with the idea to programmatically enumerate various
+ pieces of data required for command line completion, teach the
+ codebase to report the list of configuration variables
+ subcommands care about to help complete them.
+
+ * Separate "rebase -p" codepath out of "rebase -i" implementation to
+ slim down the latter and make it easier to manage.
+
+ * Make refspec parsing codepath more robust.
+
+ * Some flaky tests have been fixed.
+
+ * Continuing with the idea to programmatically enumerate various
+ pieces of data required for command line completion, the codebase
+ has been taught to enumerate options prefixed with "--no-" to
+ negate them.
+
+ * Build and test procedure for netrc credential helper (in contrib/)
+ has been updated.
+
+ * Remove unused function definitions and declarations from ewah
+ bitmap subsystem.
+
+ * Code preparation to make "git p4" closer to be usable with Python 3.
+
+ * Tighten the API to make it harder to misuse in-tree .gitmodules
+ file, even though it shares the same syntax with configuration
+ files, to read random configuration items from it.
+
+ * "git fast-import" has been updated to avoid attempting to create
+ delta against a zero-byte-long string, which is pointless.
+
+ * The codebase has been updated to compile cleanly with -pedantic
+ option.
+ (merge 2b647a05d7 bb/pedantic later to maint).
+
+ * The character display width table has been updated to match the
+ latest Unicode standard.
+ (merge 570951eea2 bb/unicode-11-width later to maint).
+
+ * test-lint now looks for broken use of "VAR=VAL shell_func" in test
+ scripts.
+
+ * Conversion from uchar[40] to struct object_id continues.
+
+ * Recent "security fix" to pay attention to contents of ".gitmodules"
+ while accepting "git push" was a bit overly strict than necessary,
+ which has been adjusted.
+
+ * "git fsck" learns to make sure the optional commit-graph file is in
+ a sane state.
+
+ * "git diff --color-moved" feature has further been tweaked.
+
+ * Code restructuring and a small fix to transport protocol v2 during
+ fetching.
+
+ * Parsing of -L[<N>][,[<M>]] parameters "git blame" and "git log"
+ take has been tweaked.
+
+ * lookup_commit_reference() and friends have been updated to find
+ in-core object for a specific in-core repository instance.
+
+ * Various glitches in the heuristics of merge-recursive strategy have
+ been documented in new tests.
+
+ * "git fetch" learned a new option "--negotiation-tip" to limit the
+ set of commits it tells the other end as "have", to reduce wasted
+ bandwidth and cycles, which would be helpful when the receiving
+ repository has a lot of refs that have little to do with the
+ history at the remote it is fetching from.
+
+ * For a large tree, the index needs to hold many cache entries
+ allocated on heap. These cache entries are now allocated out of a
+ dedicated memory pool to amortize malloc(3) overhead.
+
+ * Tests to cover various conflicting cases have been added for
+ merge-recursive.
+
+ * Tests to cover conflict cases that involve submodules have been
+ added for merge-recursive.
+
+ * Look for broken "&&" chains that are hidden in subshell, many of
+ which have been found and corrected.
+
+ * The singleton commit-graph in-core instance is made per in-core
+ repository instance.
+
+ * "make DEVELOPER=1 DEVOPTS=pedantic" allows developers to compile
+ with -pedantic option, which may catch more problematic program
+ constructs and potential bugs.
+
+ * Preparatory code to later add json output for telemetry data has
+ been added.
+
+ * Update the way we use Coccinelle to find out-of-style code that
+ need to be modernised.
+
+ * It is too easy to misuse system API functions such as strcat();
+ these selected functions are now forbidden in this codebase and
+ will cause a compilation failure.
+
+ * Add a script (in contrib/) to help users of VSCode work better with
+ our codebase.
+
+ * The Travis CI scripts were taught to ship back the test data from
+ failed tests.
+ (merge aea8879a6a sg/travis-retrieve-trash-upon-failure later to maint).
+
+ * The parse-options machinery learned to refrain from enclosing
+ placeholder string inside a "<bra" and "ket>" pair automatically
+ without PARSE_OPT_LITERAL_ARGHELP. Existing help text for option
+ arguments that are not formatted correctly have been identified and
+ fixed.
+ (merge 5f0df44cd7 rs/parse-opt-lithelp later to maint).
+
+ * Noiseword "extern" has been removed from function decls in the
+ header files.
+
+ * A few atoms like %(objecttype) and %(objectsize) in the format
+ specifier of "for-each-ref --format=<format>" can be filled without
+ getting the full contents of the object, but just with the object
+ header. These cases have been optimized by calling
+ oid_object_info() API (instead of reading and inspecting the data).
+
+ * The end result of documentation update has been made to be
+ inspected more easily to help developers.
+
+ * The API to iterate over all objects learned to optionally list
+ objects in the order they appear in packfiles, which helps locality
+ of access if the caller accesses these objects while as objects are
+ enumerated.
+
+ * Improve built-in facility to catch broken &&-chain in the tests.
+
+ * The more library-ish parts of the codebase learned to work on the
+ in-core index-state instance that is passed in by their callers,
+ instead of always working on the singleton "the_index" instance.
+
+ * A test prerequisite defined by various test scripts with slightly
+ different semantics has been consolidated into a single copy and
+ made into a lazily defined one.
+ (merge 6ec633059a wc/make-funnynames-shared-lazy-prereq later to maint).
+
+ * After a partial clone, repeated fetches from promisor remote would
+ have accumulated many packfiles marked with .promisor bit without
+ getting them coalesced into fewer packfiles, hurting performance.
+ "git repack" now learned to repack them.
+
+ * Partially revert the support for multiple hash functions to regain
+ hash comparison performance; we'd think of a way to do this better
+ in the next cycle.
+
+ * "git help --config" (which is used in command line completion)
+ missed the configuration variables not described in the main
+ config.txt file but are described in another file that is included
+ by it, which has been corrected.
+
+ * The test linter code has learned that the end of here-doc mark
+ "EOF" can be quoted in a double-quote pair, not just in a
+ single-quote pair.
+
+
+Fixes since v2.18
+-----------------
+
+ * "git remote update" can take both a single remote nickname and a
+ nickname for remote groups, and the completion script (in contrib/)
+ has been taught about it.
+ (merge 9cd4382ad5 ls/complete-remote-update-names later to maint).
+
+ * "git fetch --shallow-since=<cutoff>" that specifies the cut-off
+ point that is newer than the existing history used to end up
+ grabbing the entire history. Such a request now errors out.
+ (merge e34de73c56 nd/reject-empty-shallow-request later to maint).
+
+ * Fix for 2.17-era regression around `core.safecrlf`.
+ (merge 6cb09125be as/safecrlf-quiet-fix later to maint).
+
+ * The recent addition of "partial clone" experimental feature kicked
+ in when it shouldn't, namely, when there is no partial-clone filter
+ defined even if extensions.partialclone is set.
+ (merge cac1137dc4 jh/partial-clone later to maint).
+
+ * "git send-pack --signed" (hence "git push --signed" over the http
+ transport) did not read user ident from the config mechanism to
+ determine whom to sign the push certificate as, which has been
+ corrected.
+ (merge d067d98887 ms/send-pack-honor-config later to maint).
+
+ * "git fetch-pack --all" used to unnecessarily fail upon seeing an
+ annotated tag that points at an object other than a commit.
+ (merge c12c9df527 jk/fetch-all-peeled-fix later to maint).
+
+ * When user edits the patch in "git add -p" and the user's editor is
+ set to strip trailing whitespaces indiscriminately, an empty line
+ that is unchanged in the patch would become completely empty
+ (instead of a line with a sole SP on it). The code introduced in
+ Git 2.17 timeframe failed to parse such a patch, but now it learned
+ to notice the situation and cope with it.
+ (merge f4d35a6b49 pw/add-p-recount later to maint).
+
+ * The code to try seeing if a fetch is necessary in a submodule
+ during a fetch with --recurse-submodules got confused when the path
+ to the submodule was changed in the range of commits in the
+ superproject, sometimes showing "(null)". This has been corrected.
+
+ * Bugfix for "rebase -i" corner case regression.
+ (merge a9279c6785 pw/rebase-i-keep-reword-after-conflict later to maint).
+
+ * Recently added "--base" option to "git format-patch" command did
+ not correctly generate prereq patch ids.
+ (merge 15b76c1fb3 xy/format-patch-prereq-patch-id-fix later to maint).
+
+ * POSIX portability fix in Makefile to fix a glitch introduced a few
+ releases ago.
+ (merge 6600054e9b dj/runtime-prefix later to maint).
+
+ * "git filter-branch" when used with the "--state-branch" option
+ still attempted to rewrite the commits whose filtered result is
+ known from the previous attempt (which is recorded on the state
+ branch); the command has been corrected not to waste cycles doing
+ so.
+ (merge 709cfe848a mb/filter-branch-optim later to maint).
+
+ * Clarify that setting core.ignoreCase to deviate from reality would
+ not turn a case-incapable filesystem into a case-capable one.
+ (merge 48294b512a ms/core-icase-doc later to maint).
+
+ * "fsck.skipList" did not prevent a blob object listed there from
+ being inspected for is contents (e.g. we recently started to
+ inspect the contents of ".gitmodules" for certain malicious
+ patterns), which has been corrected.
+ (merge fb16287719 rj/submodule-fsck-skip later to maint).
+
+ * "git checkout --recurse-submodules another-branch" did not report
+ in which submodule it failed to update the working tree, which
+ resulted in an unhelpful error message.
+ (merge ba95d4e4bd sb/submodule-move-head-error-msg later to maint).
+
+ * "git rebase" behaved slightly differently depending on which one of
+ the three backends gets used; this has been documented and an
+ effort to make them more uniform has begun.
+ (merge b00bf1c9a8 en/rebase-consistency later to maint).
+
+ * The "--ignore-case" option of "git for-each-ref" (and its friends)
+ did not work correctly, which has been fixed.
+ (merge e674eb2528 jk/for-each-ref-icase later to maint).
+
+ * "git fetch" failed to correctly validate the set of objects it
+ received when making a shallow history deeper, which has been
+ corrected.
+ (merge cf1e7c0770 jt/connectivity-check-after-unshallow later to maint).
+
+ * Partial clone support of "git clone" has been updated to correctly
+ validate the objects it receives from the other side. The server
+ side has been corrected to send objects that are directly
+ requested, even if they may match the filtering criteria (e.g. when
+ doing a "lazy blob" partial clone).
+ (merge a7e67c11b8 jt/partial-clone-fsck-connectivity later to maint).
+
+ * Handling of an empty range by "git cherry-pick" was inconsistent
+ depending on how the range ended up to be empty, which has been
+ corrected.
+ (merge c5e358d073 jk/empty-pick-fix later to maint).
+
+ * "git reset --merge" (hence "git merge ---abort") and "git reset --hard"
+ had trouble working correctly in a sparsely checked out working
+ tree after a conflict, which has been corrected.
+ (merge b33fdfc34c mk/merge-in-sparse-checkout later to maint).
+
+ * Correct a broken use of "VAR=VAL shell_func" in a test.
+ (merge 650161a277 jc/t3404-one-shot-export-fix later to maint).
+
+ * "git rev-parse ':/substring'" did not consider the history leading
+ only to HEAD when looking for a commit with the given substring,
+ when the HEAD is detached. This has been fixed.
+ (merge 6b3351e799 wc/find-commit-with-pattern-on-detached-head later to maint).
+
+ * Build doc update for Windows.
+ (merge ede8d89bb1 nd/command-list later to maint).
+
+ * core.commentchar is now honored when preparing the list of commits
+ to replay in "rebase -i".
+
+ * "git pull --rebase" on a corrupt HEAD caused a segfault. In
+ general we substitute an empty tree object when running the in-core
+ equivalent of the diff-index command, and the codepath has been
+ corrected to do so as well to fix this issue.
+ (merge 3506dc9445 jk/has-uncommitted-changes-fix later to maint).
+
+ * httpd tests saw occasional breakage due to the way its access log
+ gets inspected by the tests, which has been updated to make them
+ less flaky.
+ (merge e8b3b2e275 sg/httpd-test-unflake later to maint).
+
+ * Tests to cover more D/F conflict cases have been added for
+ merge-recursive.
+
+ * "git gc --auto" opens file descriptors for the packfiles before
+ spawning "git repack/prune", which would upset Windows that does
+ not want a process to work on a file that is open by another
+ process. The issue has been worked around.
+ (merge 12e73a3ce4 kg/gc-auto-windows-workaround later to maint).
+
+ * The recursive merge strategy did not properly ensure there was no
+ change between HEAD and the index before performing its operation,
+ which has been corrected.
+ (merge 55f39cf755 en/dirty-merge-fixes later to maint).
+
+ * "git rebase" started exporting GIT_DIR environment variable and
+ exposing it to hook scripts when part of it got rewritten in C.
+ Instead of matching the old scripted Porcelains' behaviour,
+ compensate by also exporting GIT_WORK_TREE environment as well to
+ lessen the damage. This can harm existing hooks that want to
+ operate on different repository, but the current behaviour is
+ already broken for them anyway.
+ (merge ab5e67d751 bc/sequencer-export-work-tree-as-well later to maint).
+
+ * "git send-email" when using in a batched mode that limits the
+ number of messages sent in a single SMTP session lost the contents
+ of the variable used to choose between tls/ssl, unable to send the
+ second and later batches, which has been fixed.
+ (merge 636f3d7ac5 jm/send-email-tls-auth-on-batch later to maint).
+
+ * The lazy clone support had a few places where missing but promised
+ objects were not correctly tolerated, which have been fixed.
+
+ * One of the "diff --color-moved" mode "dimmed_zebra" that was named
+ in an unusual way has been deprecated and replaced by
+ "dimmed-zebra".
+ (merge e3f2f5f9cd es/diff-color-moved-fix later to maint).
+
+ * The wire-protocol v2 relies on the client to send "ref prefixes" to
+ limit the bandwidth spent on the initial ref advertisement. "git
+ clone" when learned to speak v2 forgot to do so, which has been
+ corrected.
+ (merge 402c47d939 bw/clone-ref-prefixes later to maint).
+
+ * "git diff --histogram" had a bad memory usage pattern, which has
+ been rearranged to reduce the peak usage.
+ (merge 79cb2ebb92 sb/histogram-less-memory later to maint).
+
+ * Code clean-up to use size_t/ssize_t when they are the right type.
+ (merge 7726d360b5 jk/size-t later to maint).
+
+ * The wire-protocol v2 relies on the client to send "ref prefixes" to
+ limit the bandwidth spent on the initial ref advertisement. "git
+ fetch $remote branch:branch" that asks tags that point into the
+ history leading to the "branch" automatically followed sent to
+ narrow prefix and broke the tag following, which has been fixed.
+ (merge 2b554353a5 jt/tag-following-with-proto-v2-fix later to maint).
+
+ * When the sparse checkout feature is in use, "git cherry-pick" and
+ other mergy operations lost the skip_worktree bit when a path that
+ is excluded from checkout requires content level merge, which is
+ resolved as the same as the HEAD version, without materializing the
+ merge result in the working tree, which made the path appear as
+ deleted. This has been corrected by preserving the skip_worktree
+ bit (and not materializing the file in the working tree).
+ (merge 2b75fb601c en/merge-recursive-skip-fix later to maint).
+
+ * The "author-script" file "git rebase -i" creates got broken when
+ we started to move the command away from shell script, which is
+ getting fixed now.
+ (merge 5522bbac20 es/rebase-i-author-script-fix later to maint).
+
+ * The automatic tree-matching in "git merge -s subtree" was broken 5
+ years ago and nobody has noticed since then, which is now fixed.
+ (merge 2ec4150713 jk/merge-subtree-heuristics later to maint).
+
+ * "git fetch $there refs/heads/s" ought to fetch the tip of the
+ branch 's', but when "refs/heads/refs/heads/s", i.e. a branch whose
+ name is "refs/heads/s" exists at the same time, fetched that one
+ instead by mistake. This has been corrected to honor the usual
+ disambiguation rules for abbreviated refnames.
+ (merge 60650a48c0 jt/refspec-dwim-precedence-fix later to maint).
+
+ * Futureproofing a helper function that can easily be misused.
+ (merge 65bb21e77e es/want-color-fd-defensive later to maint).
+
+ * The http-backend (used for smart-http transport) used to slurp the
+ whole input until EOF, without paying attention to CONTENT_LENGTH
+ that is supplied in the environment and instead expecting the Web
+ server to close the input stream. This has been fixed.
+ (merge eebfe40962 mk/http-backend-content-length later to maint).
+
+ * "git merge --abort" etc. did not clean things up properly when
+ there were conflicted entries in the index in certain order that
+ are involved in D/F conflicts. This has been corrected.
+ (merge ad3762042a en/abort-df-conflict-fixes later to maint).
+
+ * "git diff --indent-heuristic" had a bad corner case performance.
+ (merge 301ef85401 sb/indent-heuristic-optim later to maint).
+
+ * The "--exec" option to "git rebase --rebase-merges" placed the exec
+ commands at wrong places, which has been corrected.
+
+ * "git verify-tag" and "git verify-commit" have been taught to use
+ the exit status of underlying "gpg --verify" to signal bad or
+ untrusted signature they found.
+ (merge 4e5dc9ca17 jc/gpg-status later to maint).
+
+ * "git mergetool" stopped and gave an extra prompt to continue after
+ the last path has been handled, which did not make much sense.
+ (merge d651a54b8a ng/mergetool-lose-final-prompt later to maint).
+
+ * Among the three codepaths we use O_APPEND to open a file for
+ appending, one used for writing GIT_TRACE output requires O_APPEND
+ implementation that behaves sensibly when multiple processes are
+ writing to the same file. POSIX emulation used in the Windows port
+ has been updated to improve in this area.
+ (merge d641097589 js/mingw-o-append later to maint).
+
+ * "git pull --rebase -v" in a repository with a submodule barfed as
+ an intermediate process did not understand what "-v(erbose)" flag
+ meant, which has been fixed.
+ (merge e84c3cf3dc sb/pull-rebase-submodule later to maint).
+
+ * Recent update to "git config" broke updating variable in a
+ subsection, which has been corrected.
+ (merge bff7df7a87 sb/config-write-fix later to maint).
+
+ * When "git rebase -i" is told to squash two or more commits into
+ one, it labeled the log message for each commit with its number.
+ It correctly called the first one "1st commit", but the next one
+ was "commit #1", which was off-by-one. This has been corrected.
+ (merge dd2e36ebac pw/rebase-i-squash-number-fix later to maint).
+
+ * "git rebase -i", when a 'merge <branch>' insn in its todo list
+ fails, segfaulted, which has been (minimally) corrected.
+ (merge bc9238bb09 pw/rebase-i-merge-segv-fix later to maint).
+
+ * "git cherry-pick --quit" failed to remove CHERRY_PICK_HEAD even
+ though we won't be in a cherry-pick session after it returns, which
+ has been corrected.
+ (merge 3e7dd99208 nd/cherry-pick-quit-fix later to maint).
+
+ * In a recent update in 2.18 era, "git pack-objects" started
+ producing a larger than necessary packfiles by missing
+ opportunities to use large deltas. This has been corrected.
+
+ * The meaning of the possible values the "core.checkStat"
+ configuration variable can take were not adequately documented,
+ which has been fixed.
+ (merge 9bf5d4c4e2 nd/config-core-checkstat-doc later to maint).
+
+ * Recent "git rebase -i" update started to write bogusly formatted
+ author-script, with a matching broken reading code. These are
+ fixed.
+
+ * Recent addition of "directory rename" heuristics to the
+ merge-recursive backend makes the command susceptible to false
+ positives and false negatives. In the context of "git am -3",
+ which does not know about surrounding unmodified paths and thus
+ cannot inform the merge machinery about the full trees involved,
+ this risk is particularly severe. As such, the heuristic is
+ disabled for "git am -3" to keep the machinery "more stupid but
+ predictable".
+
+ * "git merge-base" in 2.19-rc1 has performance regression when the
+ (experimental) commit-graph feature is in use, which has been
+ mitigated.
+
+ * Code cleanup, docfix, build fix, etc.
+ (merge aee9be2ebe sg/update-ref-stdin-cleanup later to maint).
+ (merge 037714252f jc/clean-after-sanity-tests later to maint).
+ (merge 5b26c3c941 en/merge-recursive-cleanup later to maint).
+ (merge 0dcbc0392e bw/config-refer-to-gitsubmodules-doc later to maint).
+ (merge bb4d000e87 bw/protocol-v2 later to maint).
+ (merge 928f0ab4ba vs/typofixes later to maint).
+ (merge d7f590be84 en/rebase-i-microfixes later to maint).
+ (merge 81d395cc85 js/rebase-recreate-merge later to maint).
+ (merge 51d1863168 tz/exclude-doc-smallfixes later to maint).
+ (merge a9aa3c0927 ds/commit-graph later to maint).
+ (merge 5cf8e06474 js/enhanced-version-info later to maint).
+ (merge 6aaded5509 tb/config-default later to maint).
+ (merge 022d2ac1f3 sb/blame-color later to maint).
+ (merge 5a06a20e0c bp/test-drop-caches-for-windows later to maint).
+ (merge dd61cc1c2e jk/ui-color-always-to-auto later to maint).
+ (merge 1e83b9bfdd sb/trailers-docfix later to maint).
+ (merge ab29f1b329 sg/fast-import-dump-refs-on-checkpoint-fix later to maint).
+ (merge 6a8ad880f0 jn/subtree-test-fixes later to maint).
+ (merge ffbd51cc60 nd/pack-objects-threading-doc later to maint).
+ (merge e9dac7be60 es/mw-to-git-chain-fix later to maint).
+ (merge fe583c6c7a rs/remote-mv-leakfix later to maint).
+ (merge 69885ab015 en/t3031-title-fix later to maint).
+ (merge 8578037bed nd/config-blame-sort later to maint).
+ (merge 8ad169c4ba hn/config-in-code-comment later to maint).
+ (merge b7446fcfdf ar/t4150-am-scissors-test-fix later to maint).
+ (merge a8132410ee js/typofixes later to maint).
+ (merge 388d0ff6e5 en/update-index-doc later to maint).
+ (merge e05aa688dd jc/update-index-doc later to maint).
+ (merge 10c600172c sg/t5310-empty-input-fix later to maint).
+ (merge 5641eb9465 jh/partial-clone-doc later to maint).
+ (merge 2711b1ad5e ab/submodule-relative-url-tests later to maint).
+ (merge ce528de023 ab/unconditional-free-and-null later to maint).
+ (merge bbc072f5d8 rs/opt-updates later to maint).
+ (merge 69d846f053 jk/use-compat-util-in-test-tool later to maint).
+ (merge 1820703045 js/larger-timestamps later to maint).
+ (merge c8b35b95e1 sg/t4051-fix later to maint).
+ (merge 30612cb670 sg/t0020-conversion-fix later to maint).
+ (merge 15da753709 sg/t7501-thinkofix later to maint).
+ (merge 79b04f9b60 sg/t3903-missing-fix later to maint).
+ (merge 2745817028 sg/t3420-autostash-fix later to maint).
+ (merge 7afb0d6777 sg/test-rebase-editor-fix later to maint).
+ (merge 6c6ce21baa es/freebsd-iconv-portability later to maint).
diff --git a/RelNotes/2.19.1.adoc b/RelNotes/2.19.1.adoc
new file mode 100644
index 0000000..da76726
--- /dev/null
+++ b/RelNotes/2.19.1.adoc
@@ -0,0 +1,6 @@
+Git v2.19.1 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.14.5 and in
+v2.17.2 to address the recently reported CVE-2018-17456; see the
+release notes for those versions for details.
diff --git a/RelNotes/2.19.2.adoc b/RelNotes/2.19.2.adoc
new file mode 100644
index 0000000..759e6ca
--- /dev/null
+++ b/RelNotes/2.19.2.adoc
@@ -0,0 +1,108 @@
+Git v2.19.2 Release Notes
+=========================
+
+Fixes since v2.19.1
+-------------------
+
+ * "git interpret-trailers" and its underlying machinery had a buggy
+ code that attempted to ignore patch text after commit log message,
+ which triggered in various codepaths that will always get the log
+ message alone and never get such an input.
+
+ * "git rebase -i" did not clear the state files correctly when a run
+ of "squash/fixup" is aborted and then the user manually amended the
+ commit instead, which has been corrected.
+
+ * When fsmonitor is in use, after operation on submodules updates
+ .gitmodules, we lost track of the fact that we did so and relied on
+ stale fsmonitor data.
+
+ * Fix for a long-standing bug that leaves the index file corrupt when
+ it shrinks during a partial commit.
+
+ * Further fix for O_APPEND emulation on Windows
+
+ * A corner case bugfix in "git rerere" code.
+
+ * "git add ':(attr:foo)'" is not supported and is supposed to be
+ rejected while the command line arguments are parsed, but we fail
+ to reject such a command line upfront.
+
+ * "git rebase" etc. in Git 2.19 fails to abort when given an empty
+ commit log message as result of editing, which has been corrected.
+
+ * The code to backfill objects in lazily cloned repository did not
+ work correctly, which has been corrected.
+
+ * Update error messages given by "git remote" and make them consistent.
+
+ * "git update-ref" learned to make both "--no-deref" and "--stdin"
+ work at the same time.
+
+ * Recently added "range-diff" had a corner-case bug to cause it
+ segfault, which has been corrected.
+
+ * The recently introduced commit-graph auxiliary data is incompatible
+ with mechanisms such as replace & grafts that "breaks" immutable
+ nature of the object reference relationship. Disable optimizations
+ based on its use (and updating existing commit-graph) when these
+ incompatible features are in use in the repository.
+
+ * The mailmap file update.
+
+ * The code in "git status" sometimes hit an assertion failure. This
+ was caused by a structure that was reused without cleaning the data
+ used for the first run, which has been corrected.
+
+ * A corner-case bugfix.
+
+ * A partial clone that is configured to lazily fetch missing objects
+ will on-demand issue a "git fetch" request to the originating
+ repository to fill not-yet-obtained objects. The request has been
+ optimized for requesting a tree object (and not the leaf blob
+ objects contained in it) by telling the originating repository that
+ no blobs are needed.
+
+ * The codepath to support the experimental split-index mode had
+ remaining "racily clean" issues fixed.
+
+ * "git log --graph" showing an octopus merge sometimes miscounted the
+ number of display columns it is consuming to show the merge and its
+ parent commits, which has been corrected.
+
+ * The implementation of run_command() API on the UNIX platforms had a
+ bug that caused a command not on $PATH to be found in the current
+ directory.
+
+ * A mutex used in "git pack-objects" were not correctly initialized
+ and this caused "git repack" to dump core on Windows.
+
+ * Under certain circumstances, "git diff D:/a/b/c D:/a/b/d" on
+ Windows would strip initial parts from the paths because they
+ were not recognized as absolute, which has been corrected.
+
+ * The receive.denyCurrentBranch=updateInstead codepath kicked in even
+ when the push should have been rejected due to other reasons, such
+ as it does not fast-forward or the update-hook rejects it, which
+ has been corrected.
+
+ * "git repack" in a shallow clone did not correctly update the
+ shallow points in the repository, leading to a repository that
+ does not pass fsck.
+
+ * Operations on promisor objects make sense in the context of only a
+ small subset of the commands that internally use the revisions
+ machinery, but the "--exclude-promisor-objects" option were taken
+ and led to nonsense results by commands like "log", to which it
+ didn't make much sense. This has been corrected.
+
+ * The "container" mode of TravisCI is going away. Our .travis.yml
+ file is getting prepared for the transition.
+
+ * Our test scripts can now take the '-V' option as a synonym for the
+ '--verbose-log' option.
+
+ * A regression in Git 2.12 era made "git fsck" fall into an infinite
+ loop while processing truncated loose objects.
+
+Also contains various documentation updates and code clean-ups.
diff --git a/RelNotes/2.19.3.adoc b/RelNotes/2.19.3.adoc
new file mode 100644
index 0000000..92d7f89
--- /dev/null
+++ b/RelNotes/2.19.3.adoc
@@ -0,0 +1,8 @@
+Git v2.19.3 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.14.6, v2.15.4
+and in v2.17.3, addressing the security issues CVE-2019-1348,
+CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, CVE-2019-1352,
+CVE-2019-1353, CVE-2019-1354, and CVE-2019-1387; see the release notes
+for those versions for details.
diff --git a/RelNotes/2.19.4.adoc b/RelNotes/2.19.4.adoc
new file mode 100644
index 0000000..35d0ae5
--- /dev/null
+++ b/RelNotes/2.19.4.adoc
@@ -0,0 +1,5 @@
+Git v2.19.4 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.17.4; see
+the release notes for that version for details.
diff --git a/RelNotes/2.19.5.adoc b/RelNotes/2.19.5.adoc
new file mode 100644
index 0000000..18a4dcb
--- /dev/null
+++ b/RelNotes/2.19.5.adoc
@@ -0,0 +1,5 @@
+Git v2.19.5 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.17.5; see
+the release notes for that version for details.
diff --git a/RelNotes/2.19.6.adoc b/RelNotes/2.19.6.adoc
new file mode 100644
index 0000000..bcca6cd
--- /dev/null
+++ b/RelNotes/2.19.6.adoc
@@ -0,0 +1,6 @@
+Git v2.19.6 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.17.6 and
+v2.18.5 to address the security issue CVE-2021-21300; see the
+release notes for these versions for details.
diff --git a/RelNotes/2.2.0.adoc b/RelNotes/2.2.0.adoc
new file mode 100644
index 0000000..e98ecbc
--- /dev/null
+++ b/RelNotes/2.2.0.adoc
@@ -0,0 +1,313 @@
+Git v2.2 Release Notes
+======================
+
+Updates since v2.1
+------------------
+
+Ports
+
+ * Building on older MacOS X systems automatically sets
+ the necessary NO_APPLE_COMMON_CRYPTO build-time option.
+
+ * Building with NO_PTHREADS has been resurrected.
+
+ * Compilation options have been updated a bit to better support the
+ z/OS port.
+
+
+UI, Workflows & Features
+
+ * "git archive" learned to filter what gets archived with a pathspec.
+
+ * "git config --edit --global" starts from a skeletal per-user
+ configuration file contents, instead of a total blank, when the
+ user does not already have any global config. This immediately
+ reduces the need to later ask "Have you forgotten to set
+ core.user?", and we can add more to the template as we gain
+ more experience.
+
+ * "git stash list -p" used to be almost always a no-op because each
+ stash entry is represented as a merge commit. It learned to show
+ the difference between the base commit version and the working tree
+ version, which is in line with what "git stash show" gives.
+
+ * Sometimes users want to report a bug they experience on their
+ repository, but they are not at liberty to share the contents of
+ the repository. "fast-export" was taught an "--anonymize" option
+ to replace blob contents, names of people, paths and log
+ messages with bland and simple strings to help them.
+
+ * "git difftool" learned an option to stop feeding paths to the
+ diff backend when it exits with a non-zero status.
+
+ * "git grep" learned to paint (or not paint) partial matches on
+ context lines when showing "grep -C<num>" output in color.
+
+ * "log --date=iso" uses a slight variant of the ISO 8601 format that is
+ more human readable. A new "--date=iso-strict" option gives
+ datetime output that conforms more strictly.
+
+ * The logic "git prune" uses is more resilient against various corner
+ cases.
+
+ * A broken reimplementation of Git could write an invalid index that
+ records both stage #0 and higher-stage entries for the same path.
+ We now notice and reject such an index, as there is no sensible
+ fallback (we do not know if the broken tool wanted to resolve and
+ forgot to remove the higher-stage entries, or if it wanted to unresolve
+ and forgot to remove the stage #0 entry).
+
+ * The temporary files "git mergetool" uses are renamed to avoid too
+ many dots in them (e.g. a temporary file for "hello.c" used to be
+ named e.g. "hello.BASE.4321.c" but now uses underscore instead,
+ e.g. "hello_BASE_4321.c", to allow us to have multiple variants).
+
+ * The temporary files "git mergetool" uses can be placed in a newly
+ created temporary directory, instead of the current directory, by
+ setting the mergetool.writeToTemp configuration variable.
+
+ * "git mergetool" understands "--tool bc" now, as version 4 of
+ BeyondCompare can be driven the same way as its version 3 and it
+ feels awkward to say "--tool bc3" to run version 4.
+
+ * The "pre-receive" and "post-receive" hooks are no longer required
+ to consume their input fully (not following this requirement used
+ to result in intermittent errors in "git push").
+
+ * The pretty-format specifier "%d", which expands to " (tagname)"
+ for a tagged commit, gained a cousin "%D" that just gives the
+ "tagname" without frills.
+
+ * "git push" learned "--signed" push, that allows a push (i.e.
+ request to update the refs on the other side to point at a new
+ history, together with the transmission of necessary objects) to be
+ signed, so that it can be verified and audited, using the GPG
+ signature of the person who pushed, that the tips of branches at a
+ public repository really point the commits the pusher wanted to,
+ without having to "trust" the server.
+
+ * "git interpret-trailers" is a new filter to programmatically edit
+ the tail end of the commit log messages, e.g. "Signed-off-by:".
+
+ * "git help everyday" shows the "Everyday Git in 20 commands or so"
+ document, whose contents have been updated to match more modern
+ Git practice.
+
+ * On the "git svn" front, work progresses to reduce memory consumption and
+ to improve handling of mergeinfo.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * The API to manipulate the "refs" has been restructured to make it
+ more transactional, with the eventual goal to allow all-or-none
+ atomic updates and migrating the storage to something other than
+ the traditional filesystem based one (e.g. databases).
+
+ * The lockfile API and its users have been cleaned up.
+
+ * We no longer attempt to keep track of individual dependencies to
+ the header files in the build procedure, relying instead on automated
+ dependency generation support from modern compilers.
+
+ * In tests, we have been using NOT_{MINGW,CYGWIN} test prerequisites
+ long before negated prerequisites e.g. !MINGW were invented.
+ The former has been converted to the latter to avoid confusion.
+
+ * Optimized looking up a remote's configuration in a repository with very many
+ remotes defined.
+
+ * There are cases where you lock and open to write a file, close it
+ to show the updated contents to an external processes, and then have
+ to update the file again while still holding the lock; now the
+ lockfile API has support for such an access pattern.
+
+ * The API to allocate the structure to keep track of commit
+ decoration has been updated to make it less cumbersome to use.
+
+ * An in-core caching layer to let us avoid reading the same
+ configuration files several times has been added. A few commands
+ have been converted to use this subsystem.
+
+ * Various code paths have been cleaned up and simplified by using
+ the "strbuf", "starts_with()", and "skip_prefix()" APIs more.
+
+ * A few codepaths that died when large blobs that would not fit in
+ core are involved in their operation have been taught to punt
+ instead, by e.g. marking a too-large blob as not to be diffed.
+
+ * A few more code paths in "commit" and "checkout" have been taught
+ to repopulate the cache-tree in the index, to help speed up later
+ "write-tree" (used in "commit") and "diff-index --cached" (used in
+ "status").
+
+ * A common programming mistake to assign the same short option name
+ to two separate options is detected by the parse_options() API to help
+ developers.
+
+ * The code path to write out the packed-refs file has been optimized,
+ which especially matters in a repository with a large number of
+ refs.
+
+ * The check to see if a ref $F can be created by making sure no
+ existing ref has $F/ as its prefix has been optimized, which
+ especially matters in a repository with a large number of existing
+ refs.
+
+ * "git fsck" was taught to check the contents of tag objects a bit more.
+
+ * "git hash-object" was taught a "--literally" option to help
+ debugging.
+
+ * When running a required clean filter, we do not have to mmap the
+ original before feeding the filter. Instead, stream the file
+ contents directly to the filter and process its output.
+
+ * The scripts in the test suite can be run with the "-x" option to show
+ a shell-trace of each command they run.
+
+ * The "run-command" API learned to manage the argv and environment
+ arrays for child process, alleviating the need for the callers to
+ allocate and deallocate them.
+
+ * Some people use AsciiDoctor, instead of AsciiDoc, to format our
+ documentation set; the documentation has been adjusted to be usable
+ by both, as AsciiDoctor is pickier than AsciiDoc about its input
+ mark-up.
+
+
+Also contains various documentation updates and code clean-ups.
+
+
+Fixes since v2.1
+----------------
+
+Unless otherwise noted, all the fixes since v2.1 in the maintenance
+track are contained in this release (see the maintenance releases'
+notes for details).
+
+ * "git log --pretty/format=" with an empty format string did not
+ mean the more obvious "No output whatsoever" but "Use default
+ format", which was counterintuitive.
+
+ * "git -c section.var command" and "git -c section.var= command"
+ should pass the configuration value differently (the former should be a
+ boolean true, the latter should be an empty string).
+
+ * Applying a patch not generated by Git in a subdirectory used to
+ check for whitespace breakage using the attributes of incorrect
+ paths. Also whitespace checks were performed even for paths
+ excluded via the "git apply --exclude=<path>" mechanism.
+
+ * "git bundle create" with a date-range specification was meant to
+ exclude tags outside the range, but it didn't.
+
+ * "git add x" where x used to be a directory and is now a
+ symbolic link to a directory misbehaved.
+
+ * The prompt script checked the $GIT_DIR/ref/stash file to see if there
+ is a stash, which was a no-no.
+
+ * Pack-protocol documentation had a minor typo.
+
+ * "git checkout -m" did not switch to another branch while carrying
+ the local changes forward when a path was deleted from the index.
+
+ * "git daemon" (with NO_IPV6 build configuration) used to incorrectly
+ use the hostname even when gethostbyname() reported that the given
+ hostname is not found.
+ (merge 107efbe rs/daemon-fixes later to maint).
+
+ * With sufficiently long refnames, "git fast-import" could have
+ overflowed an on-stack buffer.
+
+ * After "pack-refs --prune" packed refs at the top-level, it failed
+ to prune them.
+
+ * Progress output from "git gc --auto" was visible in "git fetch -q".
+
+ * We used to pass -1000 to poll(2), expecting it to also mean "no
+ timeout", which should be spelled as -1.
+
+ * "git rebase" documentation was unclear that it is required to
+ specify on what <upstream> the rebase is to be done when telling it
+ to first check out <branch>.
+ (merge 95c6826 so/rebase-doc later to maint).
+
+ * "git push" over HTTP transport had an artificial limit on the number of
+ refs that can be pushed, imposed by the command line length.
+ (merge 26be19b jk/send-pack-many-refspecs later to maint).
+
+ * When receiving an invalid pack stream that records the same object
+ twice, multiple threads got confused due to a race.
+ (merge ab791dd jk/index-pack-threading-races later to maint).
+
+ * An attempt to remove the entire tree in the "git fast-import" input
+ stream caused it to misbehave.
+ (merge 2668d69 mb/fast-import-delete-root later to maint).
+
+ * Reachability check (used in "git prune" and friends) did not add a
+ detached HEAD as a starting point to traverse objects still in use.
+ (merge c40fdd0 mk/reachable-protect-detached-head later to maint).
+
+ * "git config --add section.var val" when section.var already has an
+ empty-string value used to lose the empty-string value.
+ (merge c1063be ta/config-add-to-empty-or-true-fix later to maint).
+
+ * "git fsck" failed to report that it found corrupt objects via its
+ exit status in some cases.
+ (merge 30d1038 jk/fsck-exit-code-fix later to maint).
+
+ * Use of the "--verbose" option used to break "git branch --merged".
+ (merge 12994dd jk/maint-branch-verbose-merged later to maint).
+
+ * Some MUAs mangle a line in a message that begins with "From " to
+ ">From " when writing to a mailbox file, and feeding such an input
+ to "git am" used to lose such a line.
+ (merge 85de86a jk/mbox-from-line later to maint).
+
+ * "rev-parse --verify --quiet $name" is meant to quietly exit with a
+ non-zero status when $name is not a valid object name, but still
+ gave error messages in some cases.
+
+ * A handful of C source files have been updated to include
+ "git-compat-util.h" as the first thing, to conform better to our
+ coding guidelines.
+ (merge 1c4b660 da/include-compat-util-first-in-c later to maint).
+
+ * The t7004 test, which tried to run Git with small stack space, has been
+ updated to use a bit larger stack to avoid false breakage on some
+ platforms.
+ (merge b9a1907 sk/tag-contains-wo-recursion later to maint).
+
+ * A few documentation pages had example sections marked up not quite
+ correctly, which passed AsciiDoc but failed with AsciiDoctor.
+ (merge c30c43c bc/asciidoc-pretty-formats-fix later to maint).
+ (merge f8a48af bc/asciidoc later to maint).
+
+ * "gitweb" used deprecated CGI::startfrom, which was removed from
+ CGI.pm as of 4.04; use CGI::start_from instead.
+ (merge 4750f4b rm/gitweb-start-form later to maint).
+
+ * Newer versions of 'meld' break the auto-detection we use to see if
+ they are new enough to support the `--output` option.
+ (merge b12d045 da/mergetool-meld later to maint).
+
+ * "git pack-objects" forgot to disable the codepath to generate the
+ object reachability bitmap when it needs to split the resulting
+ pack.
+ (merge 2113471 jk/pack-objects-no-bitmap-when-splitting later to maint).
+
+ * The code to use cache-tree trusted the on-disk data too much and
+ fell into an infinite loop upon seeing an incorrectly recorded
+ index file.
+ (merge 729dbbd jk/cache-tree-protect-from-broken-libgit2 later to maint).
+
+ * "git fetch" into a repository where branch B was deleted earlier,
+ back when it had reflog enabled, and then branch B/C is fetched
+ into it without reflog enabled, which is arguably an unlikely
+ corner case, unnecessarily failed.
+ (merge aae828b jk/fetch-reflog-df-conflict later to maint).
+
+ * "git log --first-parent -L..." used to crash.
+ (merge a8787c5 tm/line-log-first-parent later to maint).
diff --git a/RelNotes/2.2.1.adoc b/RelNotes/2.2.1.adoc
new file mode 100644
index 0000000..d5a3cd9
--- /dev/null
+++ b/RelNotes/2.2.1.adoc
@@ -0,0 +1,34 @@
+Git v2.2.1 Release Notes
+========================
+
+Fixes since v2.2
+----------------
+
+ * We used to allow committing a path ".Git/config" with Git that is
+ running on a case sensitive filesystem, but an attempt to check out
+ such a path with Git that runs on a case insensitive filesystem
+ would have clobbered ".git/config", which is definitely not what
+ the user would have expected. Git now prevents you from tracking
+ a path with ".Git" (in any case combination) as a path component.
+
+ * On Windows, certain path components that are different from ".git"
+ are mapped to ".git", e.g. "git~1/config" is treated as if it were
+ ".git/config". HFS+ has a similar issue, where certain unicode
+ codepoints are ignored, e.g. ".g\u200cit/config" is treated as if
+ it were ".git/config". Pathnames with these potential issues are
+ rejected on the affected systems. Git on systems that are not
+ affected by this issue (e.g. Linux) can also be configured to
+ reject them to ensure cross platform interoperability of the hosted
+ projects.
+
+ * "git fsck" notices a tree object that records such a path that can
+ be confused with ".git", and with receive.fsckObjects configuration
+ set to true, an attempt to "git push" such a tree object will be
+ rejected. Such a path may not be a problem on a well behaving
+ filesystem but in order to protect those on HFS+ and on case
+ insensitive filesystems, this check is enabled on all platforms.
+
+A big "thanks!" for bringing this issue to us goes to our friends in
+the Mercurial land, namely, Matt Mackall and Augie Fackler.
+
+Also contains typofixes, documentation updates and trivial code clean-ups.
diff --git a/RelNotes/2.2.2.adoc b/RelNotes/2.2.2.adoc
new file mode 100644
index 0000000..b19a35d
--- /dev/null
+++ b/RelNotes/2.2.2.adoc
@@ -0,0 +1,63 @@
+Git v2.2.2 Release Notes
+========================
+
+Fixes since v2.2.1
+------------------
+
+ * "git checkout $treeish $path", when $path in the index and the
+ working tree already matched what is in $treeish at the $path,
+ still overwrote the $path unnecessarily.
+
+ * "git config --get-color" did not parse its command line arguments
+ carefully.
+
+ * open() emulated on Windows platforms did not give EISDIR upon
+ an attempt to open a directory for writing.
+
+ * A few code paths used abs() when they should have used labs() on
+ long integers.
+
+ * "gitweb" used to depend on a behaviour recent CGI.pm deprecated.
+
+ * "git init" (hence "git clone") initialized the per-repository
+ configuration file .git/config with x-bit by mistake.
+
+ * Git 2.0 was supposed to make the "simple" mode for the default of
+ "git push", but it didn't.
+
+ * "Everyday" document had a broken link.
+
+ * The build procedure did not bother fixing perl and python scripts
+ when NO_PERL and NO_PYTHON build-time configuration changed.
+
+ * The code that reads the reflog from the newer to the older entries
+ did not handle an entry that crosses a boundary of block it uses to
+ read them correctly.
+
+ * "git apply" was described in the documentation to take --ignore-date
+ option, which it does not.
+
+ * Traditionally we tried to avoid interpreting date strings given by
+ the user as future dates, e.g. GIT_COMMITTER_DATE=2014-12-10 when
+ used early November 2014 was taken as "October 12, 2014" because it
+ is likely that a date in the future, December 10, is a mistake.
+ This heuristics has been loosened to allow people to express future
+ dates (most notably, --until=<date> may want to be far in the
+ future) and we no longer tiebreak by future-ness of the date when
+
+ (1) ISO-like format is used, and
+ (2) the string can make sense interpreted as both y-m-d and y-d-m.
+
+ Git may still have to use the heuristics to tiebreak between dd/mm/yy
+ and mm/dd/yy, though.
+
+ * The code to abbreviate an object name to its short unique prefix
+ has been optimized when no abbreviation was requested.
+
+ * "git add --ignore-errors ..." did not ignore an error to
+ give a file that did not exist.
+
+ * Git did not correctly read an overlong refname from a packed refs
+ file.
+
+Also contains typofixes, documentation updates and trivial code clean-ups.
diff --git a/RelNotes/2.2.3.adoc b/RelNotes/2.2.3.adoc
new file mode 100644
index 0000000..5bfffa4
--- /dev/null
+++ b/RelNotes/2.2.3.adoc
@@ -0,0 +1,9 @@
+Git v2.2.3 Release Notes
+========================
+
+Fixes since v2.2.2
+------------------
+
+ * A handful of codepaths that used to use fixed-sized arrays to hold
+ pathnames have been corrected to use strbuf and other mechanisms to
+ allow longer pathnames without fearing overflows.
diff --git a/RelNotes/2.20.0.adoc b/RelNotes/2.20.0.adoc
new file mode 100644
index 0000000..3dd7e6e
--- /dev/null
+++ b/RelNotes/2.20.0.adoc
@@ -0,0 +1,700 @@
+Git 2.20 Release Notes
+======================
+
+Backward Compatibility Notes
+----------------------------
+
+ * "git branch -l <foo>" used to be a way to ask a reflog to be
+ created while creating a new branch, but that is no longer the
+ case. It is a short-hand for "git branch --list <foo>" now.
+
+ * "git push" into refs/tags/* hierarchy is rejected without getting
+ forced, but "git fetch" (misguidedly) used the "fast forwarding"
+ rule used for the refs/heads/* hierarchy; this has been corrected,
+ which means some fetches of tags that did not fail with older
+ version of Git will fail without "--force" with this version.
+
+ * "git help -a" now gives verbose output (same as "git help -av").
+ Those who want the old output may say "git help --no-verbose -a"..
+
+ * "git cpn --help", when "cpn" is an alias to, say, "cherry-pick -n",
+ reported only the alias expansion of "cpn" in earlier versions of
+ Git. It now runs "git cherry-pick --help" to show the manual page
+ of the command, while sending the alias expansion to the standard
+ error stream.
+
+ * "git send-email" learned to grab address-looking string on any
+ trailer whose name ends with "-by". This is a backward-incompatible
+ change. Adding "--suppress-cc=misc-by" on the command line, or
+ setting sendemail.suppresscc configuration variable to "misc-by",
+ can be used to disable this behaviour.
+
+
+Updates since v2.19
+-------------------
+
+UI, Workflows & Features
+
+ * Running "git clone" against a project that contain two files with
+ pathnames that differ only in cases on a case insensitive
+ filesystem would result in one of the files lost because the
+ underlying filesystem is incapable of holding both at the same
+ time. An attempt is made to detect such a case and warn.
+
+ * "git checkout -b newbranch [HEAD]" should not have to do as much as
+ checking out a commit different from HEAD. An attempt is made to
+ optimize this special case.
+
+ * "git rev-list --stdin </dev/null" used to be an error; it now shows
+ no output without an error. "git rev-list --stdin --default HEAD"
+ still falls back to the given default when nothing is given on the
+ standard input.
+
+ * Lift code from GitHub to restrict delta computation so that an
+ object that exists in one fork is not made into a delta against
+ another object that does not appear in the same forked repository.
+
+ * "git format-patch" learned new "--interdiff" and "--range-diff"
+ options to explain the difference between this version and the
+ previous attempt in the cover letter (or after the three-dashes as
+ a comment).
+
+ * "git mailinfo" used in "git am" learned to make a best-effort
+ recovery of a patch corrupted by MUA that sends text/plain with
+ format=flawed option.
+ (merge 3aa4d81f88 rs/mailinfo-format-flowed later to maint).
+
+ * The rules used by "git push" and "git fetch" to determine if a ref
+ can or cannot be updated were inconsistent; specifically, fetching
+ to update existing tags were allowed even though tags are supposed
+ to be unmoving anchoring points. "git fetch" was taught to forbid
+ updates to existing tags without the "--force" option.
+
+ * "git multi-pack-index" learned to detect corruption in the .midx
+ file it uses, and this feature has been integrated into "git fsck".
+
+ * Generation of (experimental) commit-graph files have so far been
+ fairly silent, even though it takes noticeable amount of time in a
+ meaningfully large repository. The users will now see progress
+ output.
+
+ * The minimum version of Windows supported by Windows port of Git is
+ now set to Vista.
+
+ * The completion script (in contrib/) learned to complete a handful of
+ options "git stash list" command takes.
+
+ * The completion script (in contrib/) learned that "git fetch
+ --multiple" only takes remote names as arguments and no refspecs.
+
+ * "git status" learns to show progress bar when refreshing the index
+ takes a long time.
+ (merge ae9af12287 nd/status-refresh-progress later to maint).
+
+ * "git help -a" and "git help -av" give different pieces of
+ information, and generally the "verbose" version is more friendly
+ to the new users. "git help -a" by default now uses the more
+ verbose output (with "--no-verbose", you can go back to the
+ original). Also "git help -av" now lists aliases and external
+ commands, which it did not used to.
+
+ * Unlike "grep", "git grep" by default recurses to the whole tree.
+ The command learned "git grep --recursive" option, so that "git
+ grep --no-recursive" can serve as a synonym to setting the
+ max-depth to 0.
+
+ * When pushing into a repository that borrows its objects from an
+ alternate object store, "git receive-pack" that responds to the
+ push request on the other side lists the tips of refs in the
+ alternate to reduce the amount of objects transferred. This
+ sometimes is detrimental when the number of refs in the alternate
+ is absurdly large, in which case the bandwidth saved in potentially
+ fewer objects transferred is wasted in excessively large ref
+ advertisement. The alternate refs that are advertised are now
+ configurable with a pair of configuration variables.
+
+ * "git cmd --help" when "cmd" is aliased used to only say "cmd is
+ aliased to ...". Now it shows that to the standard error stream
+ and runs "git $cmd --help" where $cmd is the first word of the
+ alias expansion.
+
+ * The documentation of "git gc" has been updated to mention that it
+ is no longer limited to "pruning away cruft" but also updates
+ ancillary files like commit-graph as a part of repository
+ optimization.
+
+ * "git p4 unshelve" improvements.
+
+ * The logic to select the default user name and e-mail on Windows has
+ been improved.
+ (merge 501afcb8b0 js/mingw-default-ident later to maint).
+
+ * The "rev-list --filter" feature learned to exclude all trees via
+ "tree:0" filter.
+
+ * "git send-email" learned to grab address-looking string on any
+ trailer whose name ends with "-by"; --suppress-cc=misc-by on the
+ command line, or setting sendemail.suppresscc configuration
+ variable to "misc-by", can be used to disable this behaviour.
+
+ * "git mergetool" learned to take the "--[no-]gui" option, just like
+ "git difftool" does.
+
+ * "git rebase -i" learned a new insn, 'break', that the user can
+ insert in the to-do list. Upon hitting it, the command returns
+ control back to the user.
+
+ * New "--pretty=format:" placeholders %GF and %GP that show the GPG
+ key fingerprints have been invented.
+
+ * On platforms with recent cURL library, http.sslBackend configuration
+ variable can be used to choose a different SSL backend at runtime.
+ The Windows port uses this mechanism to switch between OpenSSL and
+ Secure Channel while talking over the HTTPS protocol.
+
+ * "git send-email" learned to disable SMTP authentication via the
+ "--smtp-auth=none" option, even when the smtp username is given
+ (which turns the authentication on by default).
+
+ * A fourth class of configuration files (in addition to the
+ traditional "system wide", "per user in the $HOME directory" and
+ "per repository in the $GIT_DIR/config") has been introduced so
+ that different worktrees that share the same repository (hence the
+ same $GIT_DIR/config file) can use different customization.
+
+ * A pattern with '**' that does not have a slash on either side used
+ to be an invalid one, but the code now treats such double-asterisks
+ the same way as two normal asterisks that happen to be adjacent to
+ each other.
+ (merge e5bbe09e88 nd/wildmatch-double-asterisk later to maint).
+
+ * The "--no-patch" option, which can be used to get a high-level
+ overview without the actual line-by-line patch difference shown, of
+ the "range-diff" command was earlier broken, which has been
+ corrected.
+
+ * The recently merged "rebase in C" has an escape hatch to use the
+ scripted version when necessary, but it hasn't been documented,
+ which has been corrected.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * Developer builds now use -Wunused-function compilation option.
+
+ * One of our CI tests to run with "unusual/experimental/random"
+ settings now also uses commit-graph and midx.
+
+ * When there are too many packfiles in a repository (which is not
+ recommended), looking up an object in these would require
+ consulting many pack .idx files; a new mechanism to have a single
+ file that consolidates all of these .idx files is introduced.
+
+ * "git submodule update" is getting rewritten piece-by-piece into C.
+
+ * The code for computing history reachability has been shuffled,
+ obtained a bunch of new tests to cover them, and then being
+ improved.
+
+ * The unpack_trees() API used in checking out a branch and merging
+ walks one or more trees along with the index. When the cache-tree
+ in the index tells us that we are walking a tree whose flattened
+ contents is known (i.e. matches a span in the index), as linearly
+ scanning a span in the index is much more efficient than having to
+ open tree objects recursively and listing their entries, the walk
+ can be optimized, which has been done.
+
+ * When creating a thin pack, which allows objects to be made into a
+ delta against another object that is not in the resulting pack but
+ is known to be present on the receiving end, the code learned to
+ take advantage of the reachability bitmap; this allows the server
+ to send a delta against a base beyond the "boundary" commit.
+
+ * spatch transformation to replace boolean uses of !hashcmp() to
+ newly introduced oideq() is added, and applied, to regain
+ performance lost due to support of multiple hash algorithms.
+
+ * Fix a bug in which the same path could be registered under multiple
+ worktree entries if the path was missing (for instance, was removed
+ manually). Also, as a convenience, expand the number of cases in
+ which --force is applicable.
+
+ * Split Documentation/config.txt for easier maintenance.
+ (merge 6014363f0b nd/config-split later to maint).
+
+ * Test helper binaries clean-up.
+ (merge c9a1f4161f nd/test-tool later to maint).
+
+ * Various tests have been updated to make it easier to swap the
+ hash function used for object identification.
+ (merge ae0c89d41b bc/hash-independent-tests later to maint).
+
+ * Update fsck.skipList implementation and documentation.
+ (merge 371a655074 ab/fsck-skiplist later to maint).
+
+ * An alias that expands to another alias has so far been forbidden,
+ but now it is allowed to create such an alias.
+
+ * Various test scripts have been updated for style and also correct
+ handling of exit status of various commands.
+
+ * "gc --auto" ended up calling exit(-1) upon error, which has been
+ corrected to use exit(1). Also the error reporting behaviour when
+ daemonized has been updated to exit with zero status when stopping
+ due to a previously discovered error (which implies there is no
+ point running gc to improve the situation); we used to exit with
+ failure in such a case.
+
+ * Various codepaths in the core-ish part learned to work on an
+ arbitrary in-core index structure, not necessarily the default
+ instance "the_index".
+ (merge b3c7eef9b0 nd/the-index later to maint).
+
+ * Code clean-up in the internal machinery used by "git status" and
+ "git commit --dry-run".
+ (merge 73ba5d78b4 ss/wt-status-committable later to maint).
+
+ * Some environment variables that control the runtime options of Git
+ used during tests are getting renamed for consistency.
+ (merge 4231d1ba99 bp/rename-test-env-var later to maint).
+
+ * A pair of new extensions to the index file have been introduced.
+ They allow the index file to be read in parallel for performance.
+
+ * The oidset API was built on top of the oidmap API which in turn is
+ on the hashmap API. Replace the implementation to build on top of
+ the khash API and gain performance.
+
+ * Over some transports, fetching objects with an exact commit object
+ name can be done without first seeing the ref advertisements. The
+ code has been optimized to exploit this.
+
+ * In a partial clone that will lazily be hydrated from the
+ originating repository, we generally want to avoid "does this
+ object exist (locally)?" on objects that we deliberately omitted
+ when we created the clone. The cache-tree codepath (which is used
+ to write a tree object out of the index) however insisted that the
+ object exists, even for paths that are outside of the partial
+ checkout area. The code has been updated to avoid such a check.
+
+ * To help developers, an EditorConfig file that attempts to follow
+ the project convention has been added.
+ (merge b548d698a0 bc/editorconfig later to maint).
+
+ * The result of coverage test can be combined with "git blame" to
+ check the test coverage of code introduced recently with a new
+ 'coverage-diff' tool (in contrib/).
+ (merge 783faedd65 ds/coverage-diff later to maint).
+
+ * An experiment to fuzz test a few areas, hopefully we can gain more
+ coverage to various areas.
+
+ * More codepaths are moving away from hardcoded hash sizes.
+
+ * The way the Windows port figures out the current directory has been
+ improved.
+
+ * The way DLLs are loaded on the Windows port has been improved.
+
+ * Some tests have been reorganized and renamed; "ls t/" now gives a
+ better overview of what is tested for these scripts than before.
+
+ * "git rebase" and "git rebase -i" have been reimplemented in C.
+
+ * Windows port learned to use nano-second resolution file timestamps.
+
+ * The overly large Documentation/config.txt file have been split into
+ million little pieces. This potentially allows each individual piece
+ to be included into the manual page of the command it affects more easily.
+
+ * Replace three string-list instances used as look-up tables in "git
+ fetch" with hashmaps.
+
+ * Unify code to read the author-script used in "git am" and the
+ commands that use the sequencer machinery, e.g. "git rebase -i".
+
+ * In preparation to the day when we can deprecate and remove the
+ "rebase -p", make sure we can skip and later remove tests for
+ it.
+
+ * The history traversal used to implement the tag-following has been
+ optimized by introducing a new helper.
+
+ * The helper function to refresh the cached stat information in the
+ in-core index has learned to perform the lstat() part of the
+ operation in parallel on multi-core platforms.
+
+ * The code to traverse objects for reachability, used to decide what
+ objects are unreferenced and expendable, have been taught to also
+ consider per-worktree refs of other worktrees as starting points to
+ prevent data loss.
+
+ * "git add" needs to internally run "diff-files" equivalent, and the
+ codepath learned the same optimization as "diff-files" has to run
+ lstat(2) in parallel to find which paths have been updated in the
+ working tree.
+
+ * The procedure to install dependencies before testing at Travis CI
+ is getting revamped for both simplicity and flexibility, taking
+ advantage of the recent move to the vm-based environment.
+
+ * The support for format-patch (and send-email) by the command-line
+ completion script (in contrib/) has been simplified a bit.
+
+ * The revision walker machinery learned to take advantage of the
+ commit generation numbers stored in the commit-graph file.
+
+ * The codebase has been cleaned up to reduce "#ifndef NO_PTHREADS".
+
+ * The way -lcurl library gets linked has been simplified by taking
+ advantage of the fact that we can just ask curl-config command how.
+
+ * Various functions have been audited for "-Wunused-parameter" warnings
+ and bugs in them got fixed.
+
+ * A sanity check for start-up sequence has been added in the config
+ API codepath.
+
+ * The build procedure to link for fuzzing test has been made
+ customizable with a new Makefile variable.
+
+ * The way "git rebase" parses and forwards the command line options
+ meant for underlying "git am" has been revamped, which fixed for
+ options with parameters that were not passed correctly.
+
+ * Our testing framework uses a special i18n "poisoned localization"
+ feature to find messages that ought to stay constant but are
+ incorrectly marked to be translated. This feature has been made
+ into a runtime option (it used to be a compile-time option).
+
+ * "git push" used to check ambiguities between object-names and
+ refnames while processing the list of refs' old and new values,
+ which was unnecessary (as it knew that it is feeding raw object
+ names). This has been optimized out.
+
+ * The xcurl_off_t() helper function is used to cast size_t to
+ curl_off_t, but some compilers gave warnings against the code to
+ ensure the casting is done without wraparound, when size_t is
+ narrower than curl_off_t. This warning has been squelched.
+
+ * Code preparation to replace ulong vars with size_t vars where
+ appropriate continues.
+
+ * The "test installed Git" mode of our test suite has been updated to
+ work better.
+
+ * A coding convention around the Coccinelle semantic patches to have
+ two classes to ease code migration process has been proposed and
+ its support has been added to the Makefile.
+
+ * The "container" mode of TravisCI is going away. Our .travis.yml
+ file is getting prepared for the transition.
+ (merge 32ee384be8 ss/travis-ci-force-vm-mode later to maint).
+
+ * Our test scripts can now take the '-V' option as a synonym for the
+ '--verbose-log' option.
+ (merge a5f52c6dab sg/test-verbose-log later to maint).
+
+
+Fixes since v2.19
+-----------------
+
+ * "git interpret-trailers" and its underlying machinery had a buggy
+ code that attempted to ignore patch text after commit log message,
+ which triggered in various codepaths that will always get the log
+ message alone and never get such an input.
+ (merge 66e83d9b41 jk/trailer-fixes later to maint).
+
+ * Malformed or crafted data in packstream can make our code attempt
+ to read or write past the allocated buffer and abort, instead of
+ reporting an error, which has been fixed.
+
+ * "git rebase -i" did not clear the state files correctly when a run
+ of "squash/fixup" is aborted and then the user manually amended the
+ commit instead, which has been corrected.
+ (merge 10d2f35436 js/rebase-i-autosquash-fix later to maint).
+
+ * When fsmonitor is in use, after operation on submodules updates
+ .gitmodules, we lost track of the fact that we did so and relied on
+ stale fsmonitor data.
+ (merge 43f1180814 bp/mv-submodules-with-fsmonitor later to maint).
+
+ * Fix for a long-standing bug that leaves the index file corrupt when
+ it shrinks during a partial commit.
+ (merge 6c003d6ffb jk/reopen-tempfile-truncate later to maint).
+
+ * Further fix for O_APPEND emulation on Windows
+ (merge eeaf7ddac7 js/mingw-o-append later to maint).
+
+ * A corner case bugfix in "git rerere" code.
+ (merge ad2bf0d9b4 en/rerere-multi-stage-1-fix later to maint).
+
+ * "git add ':(attr:foo)'" is not supported and is supposed to be
+ rejected while the command line arguments are parsed, but we fail
+ to reject such a command line upfront.
+ (merge 84d938b732 nd/attr-pathspec-fix later to maint).
+
+ * Recent update broke the reachability algorithm when refs (e.g.
+ tags) that point at objects that are not commit were involved,
+ which has been fixed.
+
+ * "git rebase" etc. in Git 2.19 fails to abort when given an empty
+ commit log message as result of editing, which has been corrected.
+ (merge a3ec9eaf38 en/sequencer-empty-edit-result-aborts later to maint).
+
+ * The code to backfill objects in lazily cloned repository did not
+ work correctly, which has been corrected.
+ (merge e68302011c jt/lazy-object-fetch-fix later to maint).
+
+ * Update error messages given by "git remote" and make them consistent.
+ (merge 5025425dff ms/remote-error-message-update later to maint).
+
+ * "git update-ref" learned to make both "--no-deref" and "--stdin"
+ work at the same time.
+ (merge d345e9fbe7 en/update-ref-no-deref-stdin later to maint).
+
+ * Recently added "range-diff" had a corner-case bug to cause it
+ segfault, which has been corrected.
+ (merge e467a90c7a tg/range-diff-corner-case-fix later to maint).
+
+ * The recently introduced commit-graph auxiliary data is incompatible
+ with mechanisms such as replace & grafts that "breaks" immutable
+ nature of the object reference relationship. Disable optimizations
+ based on its use (and updating existing commit-graph) when these
+ incompatible features are in use in the repository.
+ (merge 829a321569 ds/commit-graph-with-grafts later to maint).
+
+ * The mailmap file update.
+ (merge 255eb03edf jn/mailmap-update later to maint).
+
+ * The code in "git status" sometimes hit an assertion failure. This
+ was caused by a structure that was reused without cleaning the data
+ used for the first run, which has been corrected.
+ (merge 3e73cc62c0 en/status-multiple-renames-to-the-same-target-fix later to maint).
+
+ * "git fetch $repo $object" in a partial clone did not correctly
+ fetch the asked-for object that is referenced by an object in
+ promisor packfile, which has been fixed.
+
+ * A corner-case bugfix.
+ (merge c5cbb27cb5 sm/show-superproject-while-conflicted later to maint).
+
+ * Various fixes to "diff --color-moved-ws".
+
+ * A partial clone that is configured to lazily fetch missing objects
+ will on-demand issue a "git fetch" request to the originating
+ repository to fill not-yet-obtained objects. The request has been
+ optimized for requesting a tree object (and not the leaf blob
+ objects contained in it) by telling the originating repository that
+ no blobs are needed.
+ (merge 4c7f9567ea jt/non-blob-lazy-fetch later to maint).
+
+ * The codepath to support the experimental split-index mode had
+ remaining "racily clean" issues fixed.
+ (merge 4c490f3d32 sg/split-index-racefix later to maint).
+
+ * "git log --graph" showing an octopus merge sometimes miscounted the
+ number of display columns it is consuming to show the merge and its
+ parent commits, which has been corrected.
+ (merge 04005834ed np/log-graph-octopus-fix later to maint).
+
+ * "git range-diff" did not work well when the compared ranges had
+ changes in submodules and the "--submodule=log" was used.
+
+ * The implementation of run_command() API on the UNIX platforms had a
+ bug that caused a command not on $PATH to be found in the current
+ directory.
+ (merge f67b980771 jk/run-command-notdot later to maint).
+
+ * A mutex used in "git pack-objects" were not correctly initialized
+ and this caused "git repack" to dump core on Windows.
+ (merge 34204c8166 js/pack-objects-mutex-init-fix later to maint).
+
+ * Under certain circumstances, "git diff D:/a/b/c D:/a/b/d" on
+ Windows would strip initial parts from the paths because they
+ were not recognized as absolute, which has been corrected.
+ (merge ffd04e92e2 js/diff-notice-has-drive-prefix later to maint).
+
+ * The receive.denyCurrentBranch=updateInstead codepath kicked in even
+ when the push should have been rejected due to other reasons, such
+ as it does not fast-forward or the update-hook rejects it, which
+ has been corrected.
+ (merge b072a25fad jc/receive-deny-current-branch-fix later to maint).
+
+ * The logic to determine the archive type "git archive" uses did not
+ correctly kick in for "git archive --remote", which has been
+ corrected.
+
+ * "git repack" in a shallow clone did not correctly update the
+ shallow points in the repository, leading to a repository that
+ does not pass fsck.
+ (merge 5dcfbf564c js/shallow-and-fetch-prune later to maint).
+
+ * Some codepaths failed to form a proper URL when .gitmodules record
+ the URL to a submodule repository as relative to the repository of
+ superproject, which has been corrected.
+ (merge e0a862fdaf sb/submodule-url-to-absolute later to maint).
+
+ * "git fetch" over protocol v2 into a shallow repository failed to
+ fetch full history behind a new tip of history that was diverged
+ before the cut-off point of the history that was previously fetched
+ shallowly.
+
+ * The command line completion machinery (in contrib/) has been
+ updated to allow the completion script to tweak the list of options
+ that are reported by the parse-options machinery correctly.
+ (merge 276b49ff34 nd/completion-negation later to maint).
+
+ * Operations on promisor objects make sense in the context of only a
+ small subset of the commands that internally use the revisions
+ machinery, but the "--exclude-promisor-objects" option were taken
+ and led to nonsense results by commands like "log", to which it
+ didn't make much sense. This has been corrected.
+ (merge 669b1d2aae md/exclude-promisor-objects-fix later to maint).
+
+ * A regression in Git 2.12 era made "git fsck" fall into an infinite
+ loop while processing truncated loose objects.
+ (merge 18ad13e5b2 jk/detect-truncated-zlib-input later to maint).
+
+ * "git ls-remote $there foo" was broken by recent update for the
+ protocol v2 and stopped showing refs that match 'foo' that are not
+ refs/{heads,tags}/foo, which has been fixed.
+ (merge 6a139cdd74 jk/proto-v2-ref-prefix-fix later to maint).
+
+ * Additional comment on a tricky piece of code to help developers.
+ (merge 0afbe3e806 jk/stream-pack-non-delta-clarification later to maint).
+
+ * A couple of tests used to leave the repository in a state that is
+ deliberately corrupt, which have been corrected.
+ (merge aa984dbe5e ab/pack-tests-cleanup later to maint).
+
+ * The submodule support has been updated to read from the blob at
+ HEAD:.gitmodules when the .gitmodules file is missing from the
+ working tree.
+ (merge 2b1257e463 ao/submodule-wo-gitmodules-checked-out later to maint).
+
+ * "git fetch" was a bit loose in parsing responses from the other side
+ when talking over the protocol v2.
+
+ * "git rev-parse --exclude=* --branches --branches" (i.e. first
+ saying "add only things that do not match '*' out of all branches"
+ and then adding all branches, without any exclusion this time)
+ worked as expected, but "--exclude=* --all --all" did not work the
+ same way, which has been fixed.
+ (merge 5221048092 ag/rev-parse-all-exclude-fix later to maint).
+
+ * "git send-email --transfer-encoding=..." in recent versions of Git
+ sometimes produced an empty "Content-Transfer-Encoding:" header,
+ which has been corrected.
+ (merge 3c88e46f1a al/send-email-auto-cte-fixup later to maint).
+
+ * The interface into "xdiff" library used to discover the offset and
+ size of a generated patch hunk by first formatting it into the
+ textual hunk header "@@ -n,m +k,l @@" and then parsing the numbers
+ out. A new interface has been introduced to allow callers a more
+ direct access to them.
+ (merge 5eade0746e jk/xdiff-interface later to maint).
+
+ * Pathspec matching against a tree object were buggy when negative
+ pathspec elements were involved, which has been fixed.
+ (merge b7845cebc0 nd/tree-walk-path-exclusion later to maint).
+
+ * "git merge" and "git pull" that merges into an unborn branch used
+ to completely ignore "--verify-signatures", which has been
+ corrected.
+ (merge 01a31f3bca jk/verify-sig-merge-into-void later to maint).
+
+ * "git rebase --autostash" did not correctly re-attach the HEAD at times.
+
+ * "rev-parse --exclude=<pattern> --branches=<pattern>" etc. did not
+ quite work, which has been corrected.
+ (merge 9ab9b5df0e ra/rev-parse-exclude-glob later to maint).
+
+ * When editing a patch in a "git add -i" session, a hunk could be
+ made to no-op. The "git apply" program used to reject a patch with
+ such a no-op hunk to catch user mistakes, but it is now updated to
+ explicitly allow a no-op hunk in an edited patch.
+ (merge 22cb3835b9 js/apply-recount-allow-noop later to maint).
+
+ * The URL to an MSDN page in a comment has been updated.
+ (merge 2ef2ae2917 js/mingw-msdn-url later to maint).
+
+ * "git ls-remote --sort=<thing>" can feed an object that is not yet
+ available into the comparison machinery and segfault, which has
+ been corrected to check such a request upfront and reject it.
+
+ * When "git bundle" aborts due to an empty commit ranges
+ (i.e. resulting in an empty pack), it left a file descriptor to an
+ lockfile open, which resulted in leftover lockfile on Windows where
+ you cannot remove a file with an open file descriptor. This has
+ been corrected.
+ (merge 2c8ee1f53c jk/close-duped-fd-before-unlock-for-bundle later to maint).
+
+ * "git format-patch --stat=<width>" can be used to specify the width
+ used by the diffstat (shown in the cover letter).
+ (merge 284aeb7e60 nd/format-patch-cover-letter-stat-width later to maint).
+
+ * The way .git/index and .git/sharedindex* files were initially
+ created gave these files different perm bits until they were
+ adjusted for shared repository settings. This was made consistent.
+ (merge c9d6c78870 cc/shared-index-permbits later to maint).
+
+ * "git rebase --stat" to transplant a piece of history onto a totally
+ unrelated history were not working before and silently showed wrong
+ result. With the recent reimplementation in C, it started to instead
+ die with an error message, as the original logic was not prepared
+ to cope with this case. This has now been fixed.
+
+ * The advice message to tell the user to migrate an existing graft
+ file to the replace system when a graft file was read was shown
+ even when "git replace --convert-graft-file" command, which is the
+ way the message suggests to use, was running, which made little
+ sense.
+ (merge 8821e90a09 ab/replace-graft-with-replace-advice later to maint).
+
+ * "git diff --raw" lost ellipses to adjust the output columns for
+ some time now, but the documentation still showed them.
+
+ * Code cleanup, docfix, build fix, etc.
+ (merge 96a7501aad ts/doc-build-manpage-xsl-quietly later to maint).
+ (merge b9b07efdb2 tg/conflict-marker-size later to maint).
+ (merge fa0aeea770 sg/doc-trace-appends later to maint).
+ (merge d64324cb60 tb/void-check-attr later to maint).
+ (merge c3b9bc94b9 en/double-semicolon-fix later to maint).
+ (merge 79336116f5 sg/t3701-tighten-trace later to maint).
+ (merge 801fa63a90 jk/dev-build-format-security later to maint).
+ (merge 0597dd62ba sb/string-list-remove-unused later to maint).
+ (merge db2d36fad8 bw/protocol-v2 later to maint).
+ (merge 456d7cd3a9 sg/split-index-test later to maint).
+ (merge 7b6057c852 tq/refs-internal-comment-fix later to maint).
+ (merge 29e8dc50ad tg/t5551-with-curl-7.61.1 later to maint).
+ (merge 55f6bce2c9 fe/doc-updates later to maint).
+ (merge 7987d2232d jk/check-everything-connected-is-long-gone later to maint).
+ (merge 4ba3c9be47 dz/credential-doc-url-matching-rules later to maint).
+ (merge 4c399442f7 ma/commit-graph-docs later to maint).
+ (merge fc0503b04e ma/t1400-undebug-test later to maint).
+ (merge e56b53553a nd/packobjectshook-doc-fix later to maint).
+ (merge c56170a0c4 ma/mailing-list-address-in-git-help later to maint).
+ (merge 6e8fc70fce rs/sequencer-oidset-insert-avoids-dups later to maint).
+ (merge ad0b8f9575 mw/doc-typofixes later to maint).
+ (merge d9f079ad1a jc/how-to-document-api later to maint).
+ (merge b1492bf315 ma/t7005-bash-workaround later to maint).
+ (merge ac1f98a0df du/rev-parse-is-plumbing later to maint).
+ (merge ca8ed443a5 mm/doc-no-dashed-git later to maint).
+ (merge ce366a8144 du/get-tar-commit-id-is-plumbing later to maint).
+ (merge 61018fe9e0 du/cherry-is-plumbing later to maint).
+ (merge c7e5fe79b9 sb/strbuf-h-update later to maint).
+ (merge 8d2008196b tq/branch-create-wo-branch-get later to maint).
+ (merge 2e3c894f4b tq/branch-style-fix later to maint).
+ (merge c5d844af9c sg/doc-show-branch-typofix later to maint).
+ (merge 081d91618b ah/doc-updates later to maint).
+ (merge b84c783882 jc/cocci-preincr later to maint).
+ (merge 5e495f8122 uk/merge-subtree-doc-update later to maint).
+ (merge aaaa881822 jk/uploadpack-packobjectshook-fix later to maint).
+ (merge 3063477445 tb/char-may-be-unsigned later to maint).
+ (merge 8c64bc9420 sg/test-rebase-editor-fix later to maint).
+ (merge 71571cd7d6 ma/sequencer-do-reset-saner-loop-termination later to maint).
+ (merge 9a4cb8781e cb/notes-freeing-always-null-fix later to maint).
+ (merge 3006f5ee16 ma/reset-doc-rendering-fix later to maint).
+ (merge 4c2eb06419 sg/daemon-test-signal-fix later to maint).
+ (merge d27525e519 ss/msvc-strcasecmp later to maint).
diff --git a/RelNotes/2.20.1.adoc b/RelNotes/2.20.1.adoc
new file mode 100644
index 0000000..dcba888
--- /dev/null
+++ b/RelNotes/2.20.1.adoc
@@ -0,0 +1,20 @@
+Git v2.20.1 Release Notes
+=========================
+
+This release is primarily to fix brown-paper-bag breakages in the
+2.20.0 release.
+
+Fixes since v2.20
+-----------------
+
+ * A few newly added tests were not portable and caused minority
+ platforms to report false breakages, which have been fixed.
+
+ * Portability fix for a recent update to parse-options API.
+
+ * "git help -a" did not work well when an overly long alias is
+ defined, which has been corrected.
+
+ * A recent update accidentally squelched an error message when the
+ run_command API failed to run a missing command, which has been
+ corrected.
diff --git a/RelNotes/2.20.2.adoc b/RelNotes/2.20.2.adoc
new file mode 100644
index 0000000..8e680cb
--- /dev/null
+++ b/RelNotes/2.20.2.adoc
@@ -0,0 +1,18 @@
+Git v2.20.2 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.14.6, v2.15.4
+and in v2.17.3, addressing the security issues CVE-2019-1348,
+CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, CVE-2019-1352,
+CVE-2019-1353, CVE-2019-1354, and CVE-2019-1387; see the release notes
+for those versions for details.
+
+The change to disallow `submodule.<name>.update=!command` entries in
+`.gitmodules` which was introduced v2.15.4 (and for which v2.17.3
+added explicit fsck checks) fixes the vulnerability in v2.20.x where a
+recursive clone followed by a submodule update could execute code
+contained within the repository without the user explicitly having
+asked for that (CVE-2019-19604).
+
+Credit for finding this vulnerability goes to Joern Schneeweisz,
+credit for the fixes goes to Jonathan Nieder.
diff --git a/RelNotes/2.20.3.adoc b/RelNotes/2.20.3.adoc
new file mode 100644
index 0000000..f6eccd1
--- /dev/null
+++ b/RelNotes/2.20.3.adoc
@@ -0,0 +1,5 @@
+Git v2.20.3 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.17.4; see
+the release notes for that version for details.
diff --git a/RelNotes/2.20.4.adoc b/RelNotes/2.20.4.adoc
new file mode 100644
index 0000000..5a9e24e
--- /dev/null
+++ b/RelNotes/2.20.4.adoc
@@ -0,0 +1,5 @@
+Git v2.20.4 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.17.5; see
+the release notes for that version for details.
diff --git a/RelNotes/2.20.5.adoc b/RelNotes/2.20.5.adoc
new file mode 100644
index 0000000..1dfb784
--- /dev/null
+++ b/RelNotes/2.20.5.adoc
@@ -0,0 +1,6 @@
+Git v2.20.5 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.17.6, v2.18.5
+and v2.19.6 to address the security issue CVE-2021-21300; see
+the release notes for these versions for details.
diff --git a/RelNotes/2.21.0.adoc b/RelNotes/2.21.0.adoc
new file mode 100644
index 0000000..7a49ded
--- /dev/null
+++ b/RelNotes/2.21.0.adoc
@@ -0,0 +1,451 @@
+Git 2.21 Release Notes
+======================
+
+Backward Compatibility Notes
+----------------------------
+
+ * Historically, the "-m" (mainline) option can only be used for "git
+ cherry-pick" and "git revert" when working with a merge commit.
+ This version of Git no longer warns or errors out when working with
+ a single-parent commit, as long as the argument to the "-m" option
+ is 1 (i.e. it has only one parent, and the request is to pick or
+ revert relative to that first parent). Scripts that relied on the
+ behaviour may get broken with this change.
+
+
+Updates since v2.20
+-------------------
+
+UI, Workflows & Features
+
+ * The "http.version" configuration variable can be used with recent
+ enough versions of cURL library to force the version of HTTP used
+ to talk when fetching and pushing.
+
+ * Small fixes and features for fast-export and fast-import, mostly on
+ the fast-export side has been made.
+
+ * "git push $there $src:$dst" rejects when $dst is not a fully
+ qualified refname and it is not clear what the end user meant. The
+ codepath has been taught to give a clearer error message, and also
+ guess where the push should go by taking the type of the pushed
+ object into account (e.g. a tag object would want to go under
+ refs/tags/).
+
+ * "git checkout [<tree-ish>] path..." learned to report the number of
+ paths that have been checked out of the index or the tree-ish,
+ which gives it the same degree of noisy-ness as the case in which
+ the command checks out a branch. "git checkout -m <pathspec>" to
+ undo conflict resolution gives a similar message.
+
+ * "git quiltimport" learned "--keep-non-patch" option.
+
+ * "git worktree remove" and "git worktree move" refused to work when
+ there is a submodule involved. This has been loosened to ignore
+ uninitialized submodules.
+
+ * "git cherry-pick -m1" was forbidden when picking a non-merge
+ commit, even though there _is_ parent number 1 for such a commit.
+ This was done to avoid mistakes back when "cherry-pick" was about
+ picking a single commit, but is no longer useful with "cherry-pick"
+ that can pick a range of commits. Now the "-m$num" option is
+ allowed when picking any commit, as long as $num names an existing
+ parent of the commit.
+
+ * Update "git multimail" from the upstream.
+
+ * "git p4" update.
+
+ * The "--format=<placeholder>" option of for-each-ref, branch and tag
+ learned to show a few more traits of objects that can be learned by
+ the object_info API.
+
+ * "git rebase -i" learned to re-execute a command given with 'exec'
+ to run after it failed the last time.
+
+ * "git diff --color-moved-ws" updates.
+
+ * Custom userformat "log --format" learned %S atom that stands for
+ the tip the traversal reached the commit from, i.e. --source.
+
+ * "git instaweb" learned to drive http.server that comes with
+ "batteries included" Python installation (both Python2 & 3).
+
+ * A new encoding UTF-16LE-BOM has been invented to force encoding to
+ UTF-16 with BOM in little endian byte order, which cannot be directly
+ generated by using iconv.
+
+ * A new date format "--date=human" that morphs its output depending
+ on how far the time is from the current time has been introduced.
+ "--date=auto:human" can be used to use this new format (or any
+ existing format) when the output is going to the pager or to the
+ terminal, and otherwise the default format.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * Code clean-up with optimization for the codepath that checks
+ (non-)existence of loose objects.
+
+ * More codepaths have become aware of working with in-core repository
+ instances other than the default "the_repository".
+
+ * The "strncat()" function is now among the banned functions.
+
+ * Portability updates for the HPE NonStop platform.
+
+ * Earlier we added "-Wformat-security" to developer builds, assuming
+ that "-Wall" (which includes "-Wformat" which in turn is required
+ to use "-Wformat-security") is always in effect. This is not true
+ when config.mak.autogen is in use, unfortunately. This has been
+ fixed by unconditionally adding "-Wall" to developer builds.
+
+ * The loose object cache used to optimize existence look-up has been
+ updated.
+
+ * Flaky tests can now be repeatedly run under load with the
+ "--stress" option.
+
+ * Documentation/Makefile is getting prepared for manpage
+ localization.
+
+ * "git fetch-pack" now can talk the version 2 protocol.
+
+ * sha-256 hash has been added and plumbed through the code to allow
+ building Git with the "NewHash".
+
+ * Debugging help for http transport.
+
+ * "git fetch --deepen=<more>" has been corrected to work over v2
+ protocol.
+
+ * The code to walk tree objects has been taught that we may be
+ working with object names that are not computed with SHA-1.
+
+ * The in-core repository instances are passed through more codepaths.
+
+ * Update the protocol message specification to allow only the limited
+ use of scaled quantities. This is to ensure potential compatibility
+ issues will not get out of hand.
+
+ * Micro-optimize the code that prepares commit objects to be walked
+ by "git rev-list" when the commit-graph is available.
+
+ * "git fetch" and "git upload-pack" learned to send all exchanges over
+ the sideband channel while talking the v2 protocol.
+
+ * The codepath to write out commit-graph has been optimized by
+ following the usual pattern of visiting objects in in-pack order.
+
+ * The codepath to show progress meter while writing out commit-graph
+ file has been improved.
+
+ * Cocci rules have been updated to encourage use of strbuf_addbuf().
+
+ * "git rebase --merge" has been reimplemented by reusing the internal
+ machinery used for "git rebase -i".
+
+ * More code in "git bisect" has been rewritten in C.
+
+ * Instead of going through "git-rebase--am" scriptlet to use the "am"
+ backend, the built-in version of "git rebase" learned to drive the
+ "am" backend directly.
+
+ * The assumption to work on the single "in-core index" instance has
+ been reduced from the library-ish part of the codebase.
+
+ * The test lint learned to catch non-portable "sed" options.
+
+ * "git pack-objects" learned another algorithm to compute the set of
+ objects to send, that trades the resulting packfile off to save
+ traversal cost to favor small pushes.
+
+ * The travis CI scripts have been corrected to build Git with the
+ compiler(s) of our choice.
+
+ * "git submodule update" learned to abort early when core.worktree
+ for the submodule is not set correctly to prevent spreading damage.
+
+ * Test suite has been adjusted to run on Azure Pipeline.
+
+ * Running "Documentation/doc-diff x" from anywhere other than the
+ top-level of the working tree did not show the usage string
+ correctly, which has been fixed.
+
+ * Use of the sparse tool got easier to customize from the command
+ line to help developers.
+
+ * A new target "coverage-prove" to run the coverage test under
+ "prove" has been added.
+
+ * A flakey "p4" test has been removed.
+
+ * The code and tests assume that the system supplied iconv() would
+ always use BOM in its output when asked to encode to UTF-16 (or
+ UTF-32), but apparently some implementations output big-endian
+ without BOM. A compile-time knob has been added to help such
+ systems (e.g. NonStop) to add BOM to the output to increase
+ portability.
+
+
+Fixes since v2.20
+-----------------
+
+ * Updates for corner cases in merge-recursive.
+ (merge cc4cb0902c en/merge-path-collision later to maint).
+
+ * "git checkout frotz" (without any double-dash) avoids ambiguity by
+ making sure 'frotz' cannot be interpreted as a revision and as a
+ path at the same time. This safety has been updated to check also
+ a unique remote-tracking branch 'frotz' in a remote, when dwimming
+ to create a local branch 'frotz' out of a remote-tracking branch
+ 'frotz' from a remote.
+ (merge be4908f103 nd/checkout-dwim-fix later to maint).
+
+ * Refspecs configured with "git -c var=val clone" did not propagate
+ to the resulting repository, which has been corrected.
+ (merge 7eae4a3ac4 sg/clone-initial-fetch-configuration later to maint).
+
+ * A properly configured username/email is required under
+ user.useConfigOnly in order to create commits; now "git stash"
+ (even though it creates commit objects to represent stash entries)
+ command is exempt from the requirement.
+ (merge 3bc2111fc2 sd/stash-wo-user-name later to maint).
+
+ * The http-backend CGI process did not correctly clean up the child
+ processes it spawns to run upload-pack etc. when it dies itself,
+ which has been corrected.
+ (merge 02818a98d7 mk/http-backend-kill-children-before-exit later to maint).
+
+ * "git rev-list --exclude-promisor-objects" had to take an object
+ that does not exist locally (and is lazily available) from the
+ command line without barfing, but the code dereferenced NULL.
+ (merge 4cf67869b2 md/list-lazy-objects-fix later to maint).
+
+ * The traversal over tree objects has learned to honor
+ ":(attr:label)" pathspec match, which has been implemented only for
+ enumerating paths on the filesystem.
+ (merge 5a0b97b34c nd/attr-pathspec-in-tree-walk later to maint).
+
+ * BSD port updates.
+ (merge 4e3ecbd439 cb/openbsd-allows-reading-directory later to maint).
+ (merge b6bdc2a0f5 cb/t5004-empty-tar-archive-fix later to maint).
+ (merge 82cbc8cde2 cb/test-lint-cp-a later to maint).
+
+ * Lines that begin with a certain keyword that come over the wire, as
+ well as lines that consist only of one of these keywords, ought to
+ be painted in color for easier eyeballing, but the latter was
+ broken ever since the feature was introduced in 2.19, which has
+ been corrected.
+ (merge 1f67290450 hn/highlight-sideband-keywords later to maint).
+
+ * "git log -G<regex>" looked for a hunk in the "git log -p" patch
+ output that contained a string that matches the given pattern.
+ Optimize this code to ignore binary files, which by default will
+ not show any hunk that would match any pattern (unless textconv or
+ the --text option is in effect, that is).
+ (merge e0e7cb8080 tb/log-G-binary later to maint).
+
+ * "git submodule update" ought to use a single job unless asked, but
+ by mistake used multiple jobs, which has been fixed.
+ (merge e3a9d1aca9 sb/submodule-fetchjobs-default-to-one later to maint).
+
+ * "git stripspace" should be usable outside a git repository, but
+ under the "-s" or "-c" mode, it didn't.
+ (merge 957da75802 jn/stripspace-wo-repository later to maint).
+
+ * Some of the documentation pages formatted incorrectly with
+ Asciidoctor, which have been fixed.
+ (merge b62eb1d2f4 ma/asciidoctor later to maint).
+
+ * The core.worktree setting in a submodule repository should not be
+ pointing at a directory when the submodule loses its working tree
+ (e.g. getting deinit'ed), but the code did not properly maintain
+ this invariant.
+
+ * With zsh, "git cmd path<TAB>" was completed to "git cmd path name"
+ when the completed path has a special character like SP in it,
+ without any attempt to keep "path name" a single filename. This
+ has been fixed to complete it to "git cmd path\ name" just like
+ Bash completion does.
+
+ * The test suite tried to see if it is run under bash, but the check
+ itself failed under some other implementations of shell (notably
+ under NetBSD). This has been corrected.
+ (merge 54ea72f09c sg/test-bash-version-fix later to maint).
+
+ * "git gc" and "git repack" did not close the open packfiles that
+ they found unneeded before removing them, which didn't work on a
+ platform incapable of removing an open file. This has been
+ corrected.
+ (merge 5bdece0d70 js/gc-repack-close-before-remove later to maint).
+
+ * The code to drive GIT_EXTERNAL_DIFF command relied on the string
+ returned from getenv() to be non-volatile, which is not true, that
+ has been corrected.
+ (merge 6776a84dae kg/external-diff-save-env later to maint).
+
+ * There were many places the code relied on the string returned from
+ getenv() to be non-volatile, which is not true, that have been
+ corrected.
+ (merge 0da0e9268b jk/save-getenv-result later to maint).
+
+ * The v2 upload-pack protocol implementation failed to honor
+ hidden-ref configuration, which has been corrected.
+ (merge e20b4192a3 jk/proto-v2-hidden-refs-fix later to maint).
+
+ * "git fetch --recurse-submodules" may not fetch the necessary commit
+ that is bound to the superproject, which is getting corrected.
+ (merge be76c21282 sb/submodule-recursive-fetch-gets-the-tip later to maint).
+
+ * "git rebase" internally runs "checkout" to switch between branches,
+ and the command used to call the post-checkout hook, but the
+ reimplementation stopped doing so, which is getting fixed.
+
+ * "git add -e" got confused when the change it wants to let the user
+ edit is smaller than the previous change that was left over in a
+ temporary file.
+ (merge fa6f225e01 js/add-e-clear-patch-before-stating later to maint).
+
+ * "git p4" failed to update a shelved change when there were moved
+ files, which has been corrected.
+ (merge 7a10946ab9 ld/git-p4-shelve-update-fix later to maint).
+
+ * The codepath to read from the commit-graph file attempted to read
+ past the end of it when the file's table-of-contents was corrupt.
+
+ * The compat/obstack code had casts that -Wcast-function-type
+ compilation option found questionable.
+ (merge 764473d257 sg/obstack-cast-function-type-fix later to maint).
+
+ * An obvious typo in an assertion error message has been fixed.
+ (merge 3c27e2e059 cc/test-ref-store-typofix later to maint).
+
+ * In Git for Windows, "git clone \\server\share\path" etc. that uses
+ UNC paths from command line had bad interaction with its shell
+ emulation.
+
+ * "git add --ignore-errors" did not work as advertised and instead
+ worked as an unintended synonym for "git add --renormalize", which
+ has been fixed.
+ (merge e2c2a37545 jk/add-ignore-errors-bit-assignment-fix later to maint).
+
+ * On a case-insensitive filesystem, we failed to compare the part of
+ the path that is above the worktree directory in an absolute
+ pathname, which has been corrected.
+
+ * Asking "git check-attr" about a macro (e.g. "binary") on a specific
+ path did not work correctly, even though "git check-attr -a" listed
+ such a macro correctly. This has been corrected.
+ (merge 7b95849be4 jk/attr-macro-fix later to maint).
+
+ * "git pack-objects" incorrectly used uninitialized mutex, which has
+ been corrected.
+ (merge edb673cf10 ph/pack-objects-mutex-fix later to maint).
+
+ * "git checkout -b <new> [HEAD]" to create a new branch from the
+ current commit and check it out ought to be a no-op in the index
+ and the working tree in normal cases, but there are corner cases
+ that do require updates to the index and the working tree. Running
+ it immediately after "git clone --no-checkout" is one of these
+ cases that an earlier optimization kicked in incorrectly, which has
+ been fixed.
+ (merge 8424bfd45b bp/checkout-new-branch-optim later to maint).
+
+ * "git diff --color-moved --cc --stat -p" did not work well due to
+ funny interaction between a bug in color-moved and the rest, which
+ has been fixed.
+ (merge dac03b5518 jk/diff-cc-stat-fixes later to maint).
+
+ * When GIT_SEQUENCE_EDITOR is set, the command was incorrectly
+ started when modes of "git rebase" that implicitly uses the
+ machinery for the interactive rebase are run, which has been
+ corrected.
+ (merge 891d4a0313 pw/no-editor-in-rebase-i-implicit later to maint).
+
+ * The commit-graph facility did not work when in-core objects that
+ are promoted from unknown type to commit (e.g. a commit that is
+ accessed via a tag that refers to it) were involved, which has been
+ corrected.
+ (merge 4468d4435c sg/object-as-type-commit-graph-fix later to maint).
+
+ * "git fetch" output cleanup.
+ (merge dc40b24df4 nd/fetch-compact-update later to maint).
+
+ * "git cat-file --batch" reported a dangling symbolic link by
+ mistake, when it wanted to report that a given name is ambiguous.
+
+ * Documentation around core.crlf has been updated.
+ (merge c9446f0504 jk/autocrlf-overrides-eol-doc later to maint).
+
+ * The documentation of "git commit-tree" said that the command
+ understands "--gpg-sign" in addition to "-S", but the command line
+ parser did not know about the longhand, which has been corrected.
+
+ * "git rebase -x $cmd" did not reject multi-line command, even though
+ the command is incapable of handling such a command. It now is
+ rejected upfront.
+ (merge c762aada1a pw/rebase-x-sanity-check later to maint).
+
+ * Output from "git help" was not correctly aligned, which has been
+ fixed.
+ (merge 6195a76da4 nd/help-align-command-desc later to maint).
+
+ * The "git submodule summary" subcommand showed shortened commit
+ object names by mechanically truncating them at 7-hexdigit, which
+ has been improved to let "rev-parse --short" scale the length of
+ the abbreviation with the size of the repository.
+ (merge 0586a438f6 sh/submodule-summary-abbrev-fix later to maint).
+
+ * The way the OSX build jobs updates its build environment used the
+ "--quiet" option to "brew update" command, but it wasn't all that
+ quiet to be useful. The use of the option has been replaced with
+ an explicit redirection to the /dev/null (which incidentally would
+ have worked around a breakage by recent updates to homebrew, which
+ has fixed itself already).
+ (merge a1ccaedd62 sg/travis-osx-brew-breakage-workaround later to maint).
+
+ * "git --work-tree=$there --git-dir=$here describe --dirty" did not
+ work correctly as it did not pay attention to the location of the
+ worktree specified by the user by mistake, which has been
+ corrected.
+ (merge c801170b0c ss/describe-dirty-in-the-right-directory later to maint).
+
+ * "git fetch" over protocol v2 that needs to make a second connection
+ to backfill tags did not clear a variable that holds shallow
+ repository information correctly, leading to an access of freed
+ piece of memory.
+
+ * Some errors from the other side coming over smart HTTP transport
+ were not noticed, which has been corrected.
+
+ * Code cleanup, docfix, build fix, etc.
+ (merge 89ba9a79ae hb/t0061-dot-in-path-fix later to maint).
+ (merge d173e799ea sb/diff-color-moved-config-option-fixup later to maint).
+ (merge a8f5a59067 en/directory-renames-nothanks-doc-update later to maint).
+ (merge ec36c42a63 nd/indentation-fix later to maint).
+ (merge f116ee21cd do/gitweb-strict-export-conf-doc later to maint).
+ (merge 112ea42663 fd/gitweb-snapshot-conf-doc-fix later to maint).
+ (merge 1cadad6f65 tb/use-common-win32-pathfuncs-on-cygwin later to maint).
+ (merge 57e9dcaa65 km/rebase-doc-typofix later to maint).
+ (merge b8b4cb27e6 ds/gc-doc-typofix later to maint).
+ (merge 3b3357626e nd/style-opening-brace later to maint).
+ (merge b4583d5595 es/doc-worktree-guessremote-config later to maint).
+ (merge cce99cd8c6 ds/commit-graph-assert-missing-parents later to maint).
+ (merge 0650614982 cy/completion-typofix later to maint).
+ (merge 6881925ef5 rs/sha1-file-close-mapped-file-on-error later to maint).
+ (merge bd8d6f0def en/show-ref-doc-fix later to maint).
+ (merge 1747125e2c cc/partial-clone-doc-typofix later to maint).
+ (merge e01378753d cc/fetch-error-message-fix later to maint).
+ (merge 54e8c11215 jk/remote-insteadof-cleanup later to maint).
+ (merge d609615f48 js/test-git-installed later to maint).
+ (merge ba170517be ja/doc-style-fix later to maint).
+ (merge 86fb1c4e77 km/init-doc-typofix later to maint).
+ (merge 5cfd4a9d10 nd/commit-doc later to maint).
+ (merge 9fce19a431 ab/diff-tree-doc-fix later to maint).
+ (merge 2e285e7803 tz/gpg-test-fix later to maint).
+ (merge 5427de960b kl/pretty-doc-markup-fix later to maint).
+ (merge 3815f64b0d js/mingw-host-cpu later to maint).
+ (merge 5fe81438b5 rj/sequencer-sign-off-header-static later to maint).
+ (merge 18a4f6be6b nd/fileno-may-be-macro later to maint).
+ (merge 99e9ab54ab kd/t0028-octal-del-is-377-not-777 later to maint).
diff --git a/RelNotes/2.21.1.adoc b/RelNotes/2.21.1.adoc
new file mode 100644
index 0000000..b759415
--- /dev/null
+++ b/RelNotes/2.21.1.adoc
@@ -0,0 +1,12 @@
+Git v2.21.1 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.14.6, v2.15.4,
+v2.17.3 and in v2.20.2, addressing the security issues CVE-2019-1348,
+CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, CVE-2019-1352,
+CVE-2019-1353, CVE-2019-1354, CVE-2019-1387, and CVE-2019-19604;
+see the release notes for those versions for details.
+
+Additionally, this version also includes a couple of fixes for the
+Windows-specific quoting of command-line arguments when Git executes
+a Unix shell on Windows.
diff --git a/RelNotes/2.21.2.adoc b/RelNotes/2.21.2.adoc
new file mode 100644
index 0000000..a0fb83b
--- /dev/null
+++ b/RelNotes/2.21.2.adoc
@@ -0,0 +1,5 @@
+Git v2.21.2 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.17.4; see
+the release notes for that version for details.
diff --git a/RelNotes/2.21.3.adoc b/RelNotes/2.21.3.adoc
new file mode 100644
index 0000000..2ca0aa5
--- /dev/null
+++ b/RelNotes/2.21.3.adoc
@@ -0,0 +1,5 @@
+Git v2.21.3 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.17.5; see
+the release notes for that version for details.
diff --git a/RelNotes/2.21.4.adoc b/RelNotes/2.21.4.adoc
new file mode 100644
index 0000000..0089dd6
--- /dev/null
+++ b/RelNotes/2.21.4.adoc
@@ -0,0 +1,6 @@
+Git v2.21.4 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.17.6, v2.18.5,
+v2.19.6 and v2.20.5 to address the security issue CVE-2021-21300;
+see the release notes for these versions for details.
diff --git a/RelNotes/2.22.0.adoc b/RelNotes/2.22.0.adoc
new file mode 100644
index 0000000..91e6ae9
--- /dev/null
+++ b/RelNotes/2.22.0.adoc
@@ -0,0 +1,597 @@
+Git 2.22 Release Notes
+======================
+
+Updates since v2.21
+-------------------
+
+Backward compatibility note
+
+ * The filter specification "--filter=sparse:path=<path>" used to
+ create a lazy/partial clone has been removed. Using a blob that is
+ part of the project as sparse specification is still supported with
+ the "--filter=sparse:oid=<blob>" option.
+
+UI, Workflows & Features
+
+ * "git checkout --no-overlay" can be used to trigger a new mode of
+ checking out paths out of the tree-ish, that allows paths that
+ match the pathspec that are in the current index and working tree
+ and are not in the tree-ish.
+
+ * The %(trailers) formatter in "git log --format=..." now allows to
+ optionally pick trailers selectively by keyword, show only values,
+ etc.
+
+ * Four new configuration variables {author,committer}.{name,email}
+ have been introduced to override user.{name,email} in more specific
+ cases.
+
+ * Command-line completion (in contrib/) learned to tab-complete the
+ "git submodule absorbgitdirs" subcommand.
+
+ * "git branch" learned a new subcommand "--show-current".
+
+ * Output from "diff --cc" did not show the original paths when the
+ merge involved renames. A new option adds the paths in the
+ original trees to the output.
+
+ * The command line completion (in contrib/) has been taught to
+ complete more subcommand parameters.
+
+ * The final report from "git bisect" used to show the suspected
+ culprit using a raw "diff-tree", with which there is no output for
+ a merge commit. This has been updated to use a more modern and
+ human readable output that still is concise enough.
+
+ * "git rebase --rebase-merges" replaces its old "--preserve-merges"
+ option; the latter is now marked as deprecated.
+
+ * Error message given while cloning with --recurse-submodules has
+ been updated.
+
+ * The completion helper code now pays attention to repository-local
+ configuration (when available), which allows --list-cmds to honour
+ a repository specific setting of completion.commands, for example.
+
+ * "git mergetool" learned to offer Sublime Merge (smerge) as one of
+ its backends.
+
+ * A new hook "post-index-change" is called when the on-disk index
+ file changes, which can help e.g. a virtualized working tree
+ implementation.
+
+ * "git difftool" can now run outside a repository.
+
+ * "git checkout -m <other>" was about carrying the differences
+ between HEAD and the working-tree files forward while checking out
+ another branch, and ignored the differences between HEAD and the
+ index. The command has been taught to abort when the index and the
+ HEAD are different.
+
+ * A progress indicator has been added to the "index-pack" step, which
+ often makes users wait for completion during "git clone".
+
+ * "git submodule" learns "set-branch" subcommand that allows the
+ submodule.*.branch settings to be modified.
+
+ * "git merge-recursive" backend recently learned a new heuristics to
+ infer file movement based on how other files in the same directory
+ moved. As this is inherently less robust heuristics than the one
+ based on the content similarity of the file itself (rather than
+ based on what its neighbours are doing), it sometimes gives an
+ outcome unexpected by the end users. This has been toned down to
+ leave the renamed paths in higher/conflicted stages in the index so
+ that the user can examine and confirm the result.
+
+ * "git tag" learned to give an advice suggesting it might be a
+ mistake when creating an annotated or signed tag that points at
+ another tag.
+
+ * The "git pack-objects" command learned to report the number of
+ objects it packed via the trace2 mechanism.
+
+ * The list of conflicted paths shown in the editor while concluding a
+ conflicted merge was shown above the scissors line when the
+ clean-up mode is set to "scissors", even though it was commented
+ out just like the list of updated paths and other information to
+ help the user explain the merge better.
+
+ * The trace2 tracing facility learned to auto-generate a filename
+ when told to log to a directory.
+
+ * "git clone" learned a new --server-option option when talking over
+ the protocol version 2.
+
+ * The connectivity bitmaps are created by default in bare
+ repositories now; also the pathname hash-cache is created by
+ default to avoid making crappy deltas when repacking.
+
+ * "git branch new A...B" and "git checkout -b new A...B" have been
+ taught that in their contexts, the notation A...B means "the merge
+ base between these two commits", just like "git checkout A...B"
+ detaches HEAD at that commit.
+
+ * Update "git difftool" and "git mergetool" so that the combinations
+ of {diff,merge}.{tool,guitool} configuration variables serve as
+ fallback settings of each other in a sensible order.
+
+ * The "--dir-diff" mode of "git difftool" is not useful in "--no-index"
+ mode; they are now explicitly marked as mutually incompatible.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * The diff machinery, one of the oldest parts of the system, which
+ long predates the parse-options API, uses fairly long and complex
+ handcrafted option parser. This is being rewritten to use the
+ parse-options API.
+
+ * The implementation of pack-redundant has been updated for
+ performance in a repository with many packfiles.
+
+ * A more structured way to obtain execution trace has been added.
+
+ * "git prune" has been taught to take advantage of reachability
+ bitmap when able.
+
+ * The command line parser of "git commit-tree" has been rewritten to
+ use the parse-options API.
+
+ * Suggest GitGitGadget instead of submitGit as a way to submit
+ patches based on GitHub PR to us.
+
+ * The test framework has been updated to help developers by making it
+ easier to run most of the tests under different versions of
+ over-the-wire protocols.
+
+ * Dev support update to make it easier to compare two formatted
+ results from our documentation.
+
+ * The scripted "git rebase" implementation has been retired.
+
+ * "git multi-pack-index verify" did not scale well with the number of
+ packfiles, which is being improved.
+
+ * "git stash" has been rewritten in C.
+
+ * The "check-docs" Makefile target to support developers has been
+ updated.
+
+ * The tests have been updated not to rely on the abbreviated option
+ names the parse-options API offers, to protect us from an
+ abbreviated form of an option that used to be unique within the
+ command getting non-unique when a new option that share the same
+ prefix is added.
+
+ * The scripted version of "git rebase -i" wrote and rewrote the todo
+ list many times during a single step of its operation, and the
+ recent C-rewrite made a faithful conversion of the logic to C. The
+ implementation has been updated to carry necessary information
+ around in-core to avoid rewriting the same file over and over
+ unnecessarily.
+
+ * Test framework update to more robustly clean up leftover files and
+ processes after tests are done.
+
+ * Conversion from unsigned char[20] to struct object_id continues.
+
+ * While running "git diff" in a lazy clone, we can upfront know which
+ missing blobs we will need, instead of waiting for the on-demand
+ machinery to discover them one by one. The code learned to aim to
+ achieve better performance by batching the request for these
+ promised blobs.
+
+ * During an initial "git clone --depth=..." partial clone, it is
+ pointless to spend cycles for a large portion of the connectivity
+ check that enumerates and skips promisor objects (which by
+ definition is all objects fetched from the other side). This has
+ been optimized out.
+
+ * Mechanically and systematically drop "extern" from function
+ declaration.
+
+ * The script to aggregate perf result unconditionally depended on
+ libjson-perl even though it did not have to, which has been
+ corrected.
+
+ * The internal implementation of "git rebase -i" has been updated to
+ avoid forking a separate "rebase--interactive" process.
+
+ * Allow DEP and ASLR for Windows build to for security hardening.
+
+ * Performance test framework has been broken and measured the version
+ of Git that happens to be on $PATH, not the specified one to
+ measure, for a while, which has been corrected.
+
+ * Optionally "make coccicheck" can feed multiple source files to
+ spatch, gaining performance while spending more memory.
+
+ * Attempt to use an abbreviated option in "git clone --recurs" is
+ responded by a request to disambiguate between --recursive and
+ --recurse-submodules, which is bad because these two are synonyms.
+ The parse-options API has been extended to define such synonyms
+ more easily and not produce an unnecessary failure.
+
+ * A pair of private functions in http.c that had names similar to
+ fread/fwrite did not return the number of elements, which was found
+ to be confusing.
+
+ * Update collision-detecting SHA-1 code to build properly on HP-UX.
+
+
+Fixes since v2.21
+-----------------
+
+ * "git prune-packed" did not notice and complain against excess
+ arguments given from the command line, which now it does.
+ (merge 9b0bd87ed2 rj/prune-packed-excess-args later to maint).
+
+ * Split-index fix.
+ (merge 6e37c8ed3c nd/split-index-null-base-fix later to maint).
+
+ * "git diff --no-index" may still want to access Git goodies like
+ --ext-diff and --textconv, but so far these have been ignored,
+ which has been corrected.
+ (merge 287ab28bfa jk/diff-no-index-initialize later to maint).
+
+ * Unify RPC code for smart http in protocol v0/v1 and v2, which fixes
+ a bug in the latter (lack of authentication retry) and generally
+ improves the code base.
+ (merge a97d00799a jt/http-auth-proto-v2-fix later to maint).
+
+ * The include file compat/bswap.h has been updated so that it is safe
+ to (accidentally) include it more than once.
+ (merge 33aa579a55 jk/guard-bswap-header later to maint).
+
+ * The set of header files used by "make hdr-check" unconditionally
+ included sha256/gcrypt.h, even when it is not used, causing the
+ make target to fail. We now skip it when GCRYPT_SHA256 is not in
+ use.
+ (merge f23aa18e7f rj/hdr-check-gcrypt-fix later to maint).
+
+ * The Makefile uses 'find' utility to enumerate all the *.h header
+ files, which is expensive on platforms with slow filesystems; it
+ now optionally uses "ls-files" if working within a repository,
+ which is a trick similar to how all sources are enumerated to run
+ ETAGS on.
+ (merge 92b88eba9f js/find-lib-h-with-ls-files-when-possible later to maint).
+
+ * "git rebase" that was reimplemented in C did not set ORIG_HEAD
+ correctly, which has been corrected.
+ (merge cbd29ead92 js/rebase-orig-head-fix later to maint).
+
+ * Dev support.
+ (merge f545737144 js/stress-test-ui-tweak later to maint).
+
+ * CFLAGS now can be tweaked when invoking Make while using
+ DEVELOPER=YesPlease; this did not work well before.
+ (merge 6d5d4b4e93 ab/makefile-help-devs-more later to maint).
+
+ * "git fsck --connectivity-only" omits computation necessary to sift
+ the objects that are not reachable from any of the refs into
+ unreachable and dangling. This is now enabled when dangling
+ objects are requested (which is done by default, but can be
+ overridden with the "--no-dangling" option).
+ (merge 8d8c2a5aef jk/fsck-doc later to maint).
+
+ * On platforms where "git fetch" is killed with SIGPIPE (e.g. OSX),
+ the upload-pack that runs on the other end that hangs up after
+ detecting an error could cause "git fetch" to die with a signal,
+ which led to a flaky test. "git fetch" now ignores SIGPIPE during
+ the network portion of its operation (this is not a problem as we
+ check the return status from our write(2)s).
+ (merge 143588949c jk/no-sigpipe-during-network-transport later to maint).
+
+ * A recent update broke "is this object available to us?" check for
+ well-known objects like an empty tree (which should yield "yes",
+ even when there is no on-disk object for an empty tree), which has
+ been corrected.
+ (merge f06ab027ef jk/virtual-objects-do-exist later to maint).
+
+ * The setup code has been cleaned up to avoid leaks around the
+ repository_format structure.
+ (merge e8805af1c3 ma/clear-repository-format later to maint).
+
+ * "git config --type=color ..." is meant to replace "git config --get-color"
+ but there is a slight difference that wasn't documented, which is
+ now fixed.
+ (merge cd8e7593b9 jk/config-type-color-ends-with-lf later to maint).
+
+ * When the "clean" filter can reduce the size of a huge file in the
+ working tree down to a small "token" (a la Git LFS), there is no
+ point in allocating a huge scratch area upfront, but the buffer is
+ sized based on the original file size. The convert mechanism now
+ allocates very minimum and reallocates as it receives the output
+ from the clean filter process.
+ (merge 02156ab031 jh/resize-convert-scratch-buffer later to maint).
+
+ * "git rebase" uses the refs/rewritten/ hierarchy to store its
+ intermediate states, which inherently makes the hierarchy per
+ worktree, but it didn't quite work well.
+ (merge b9317d55a3 nd/rewritten-ref-is-per-worktree later to maint).
+
+ * "git log -L<from>,<to>:<path>" with "-s" did not suppress the patch
+ output as it should. This has been corrected.
+ (merge 05314efaea jk/line-log-with-patch later to maint).
+
+ * "git worktree add" used to do a "find an available name with stat
+ and then mkdir", which is race-prone. This has been fixed by using
+ mkdir and reacting to EEXIST in a loop.
+ (merge 7af01f2367 ms/worktree-add-atomic-mkdir later to maint).
+
+ * Build update for SHA-1 with collision detection.
+ (merge 07a20f569b jk/sha1dc later to maint).
+
+ * Build procedure has been fixed around use of asciidoctor instead of
+ asciidoc.
+ (merge 185f9a0ea0 ma/asciidoctor-fixes later to maint).
+
+ * remote-http transport did not anonymize URLs reported in its error
+ messages at places.
+ (merge c1284b21f2 js/anonymize-remote-curl-diag later to maint).
+
+ * Error messages given from the http transport have been updated so
+ that they can be localized.
+ (merge ed8b4132c8 js/remote-curl-i18n later to maint).
+
+ * "git init" forgot to read platform-specific repository
+ configuration, which made Windows port to ignore settings of
+ core.hidedotfiles, for example.
+
+ * A corner-case object name ambiguity while the sequencer machinery
+ is working (e.g. "rebase -i -x") has been fixed.
+
+ * "git format-patch" did not diagnose an error while opening the
+ output file for the cover-letter, which has been corrected.
+ (merge 2fe95f494c jc/format-patch-error-check later to maint).
+
+ * "git checkout -f <branch>" while the index has an unmerged path
+ incorrectly left some paths in an unmerged state, which has been
+ corrected.
+
+ * A corner case bug in the refs API has been corrected.
+ (merge d3322eb28b jk/refs-double-abort later to maint).
+
+ * Unicode update.
+ (merge 584b62c37b bb/unicode-12 later to maint).
+
+ * dumb-http walker has been updated to share more error recovery
+ strategy with the normal codepath.
+
+ * A buglet in configuration parser has been fixed.
+ (merge 19e7fdaa58 nd/include-if-wildmatch later to maint).
+
+ * The documentation for "git read-tree --reset -u" has been updated.
+ (merge b5a0bd694c nd/read-tree-reset-doc later to maint).
+
+ * Code clean-up around a much-less-important-than-it-used-to-be
+ update_server_info() function.
+ (merge b3223761c8 jk/server-info-rabbit-hole later to maint).
+
+ * The message given when "git commit -a <paths>" errors out has been
+ updated.
+ (merge 5a1dbd48bc nd/commit-a-with-paths-msg-update later to maint).
+
+ * "git cherry-pick --options A..B", after giving control back to the
+ user to ask help resolving a conflicted step, did not honor the
+ options it originally received, which has been corrected.
+
+ * Various glitches in "git gc" around reflog handling have been fixed.
+
+ * The code to read from commit-graph file has been cleanup with more
+ careful error checking before using data read from it.
+
+ * Performance fix around "git fetch" that grabs many refs.
+ (merge b764300912 jt/fetch-pack-wanted-refs-optim later to maint).
+
+ * Protocol v2 support in "git fetch-pack" of shallow clones has been
+ corrected.
+
+ * Performance fix around "git blame", especially in a linear history
+ (which is the norm we should optimize for).
+ (merge f892014943 dk/blame-keep-origin-blob later to maint).
+
+ * Performance fix for "rev-list --parents -- pathspec".
+ (merge 8320b1dbe7 jk/revision-rewritten-parents-in-prio-queue later to maint).
+
+ * Updating the display with progress message has been cleaned up to
+ deal better with overlong messages.
+ (merge 545dc345eb sg/overlong-progress-fix later to maint).
+
+ * "git blame -- path" in a non-bare repository starts blaming from
+ the working tree, and the same command in a bare repository errors
+ out because there is no working tree by definition. The command
+ has been taught to instead start blaming from the commit at HEAD,
+ which is more useful.
+ (merge a544fb08f8 sg/blame-in-bare-start-at-head later to maint).
+
+ * An underallocation in the code to read the untracked cache
+ extension has been corrected.
+ (merge 3a7b45a623 js/untracked-cache-allocfix later to maint).
+
+ * The code is updated to check the result of memory allocation before
+ it is used in more places, by using xmalloc and/or xcalloc calls.
+ (merge 999b951b28 jk/xmalloc later to maint).
+
+ * The GETTEXT_POISON test option has been quite broken ever since it
+ was made runtime-tunable, which has been fixed.
+ (merge f88b9cb603 jc/gettext-test-fix later to maint).
+
+ * Test fix on APFS that is incapable of store paths in Latin-1.
+ (merge 3889149619 js/iso8895-test-on-apfs later to maint).
+
+ * "git submodule foreach <command> --quiet" did not pass the option
+ down correctly, which has been corrected.
+ (merge a282f5a906 nd/submodule-foreach-quiet later to maint).
+
+ * "git send-email" has been taught to use quoted-printable when the
+ payload contains carriage-return. The use of the mechanism is in
+ line with the design originally added the codepath that chooses QP
+ when the payload has overly long lines.
+ (merge 74d76a1701 bc/send-email-qp-cr later to maint).
+
+ * The recently added feature to add addresses that are on
+ anything-by: trailers in 'git send-email' was found to be way too
+ eager and considered nonsense strings as if they can be legitimate
+ beginning of *-by: trailer. This has been tightened.
+
+ * Builds with gettext broke on recent macOS w/ Homebrew, which
+ seems to have stopped including from /usr/local/include; this
+ has been corrected.
+ (merge 92a1377a2a js/macos-gettext-build later to maint).
+
+ * Running "git add" on a repository created inside the current
+ repository is an explicit indication that the user wants to add it
+ as a submodule, but when the HEAD of the inner repository is on an
+ unborn branch, it cannot be added as a submodule. Worse, the files
+ in its working tree can be added as if they are a part of the outer
+ repository, which is not what the user wants. These problems are
+ being addressed.
+ (merge f937bc2f86 km/empty-repo-is-still-a-repo later to maint).
+
+ * "git cherry-pick" run with the "-x" or the "--signoff" option used
+ to (and more importantly, ought to) clean up the commit log message
+ with the --cleanup=space option by default, but this has been
+ broken since late 2017. This has been fixed.
+
+ * When given a tag that points at a commit-ish, "git replace --graft"
+ failed to peel the tag before writing a replace ref, which did not
+ make sense because the old graft mechanism the feature wants to
+ mimic only allowed to replace one commit object with another.
+ This has been fixed.
+ (merge ee521ec4cb cc/replace-graft-peel-tags later to maint).
+
+ * Code tightening against a "wrong" object appearing where an object
+ of a different type is expected, instead of blindly assuming that
+ the connection between objects are correctly made.
+ (merge 97dd512af7 tb/unexpected later to maint).
+
+ * An earlier update for MinGW and Cygwin accidentally broke MSVC build,
+ which has been fixed.
+ (merge 22c3634c0f ss/msvc-path-utils-fix later to maint).
+
+ * %(push:track) token used in the --format option to "git
+ for-each-ref" and friends was not showing the right branch, which
+ has been fixed.
+ (merge c646d0934e dr/ref-filter-push-track-fix later to maint).
+
+ * "make check-docs", "git help -a", etc. did not account for cases
+ where a particular build may deliberately omit some subcommands,
+ which has been corrected.
+
+ * The logic to tell if a Git repository has a working tree protects
+ "git branch -D" from removing the branch that is currently checked
+ out by mistake. The implementation of this logic was broken for
+ repositories with unusual name, which unfortunately is the norm for
+ submodules these days. This has been fixed.
+ (merge f3534c98e4 jt/submodule-repo-is-with-worktree later to maint).
+
+ * AIX shared the same build issues with other BSDs around fileno(fp),
+ which has been corrected.
+ (merge ee662bf5c6 cc/aix-has-fileno-as-a-macro later to maint).
+
+ * The autoconf generated configure script failed to use the right
+ gettext() implementations from -libintl by ignoring useless stub
+ implementations shipped in some C library, which has been
+ corrected.
+ (merge b71e56a683 vk/autoconf-gettext later to maint).
+
+ * Fix index-pack perf test so that the repeated invocations always
+ run in an empty repository, which emulates the initial clone
+ situation better.
+ (merge 775c71e16d jk/p5302-avoid-collision-check-cost later to maint).
+
+ * A "ls-files" that emulates "find" to enumerate files in the working
+ tree resulted in duplicated Makefile rules that caused the build to
+ issue an unnecessary warning during a trial build after merge
+ conflicts are resolved in working tree *.h files but before the
+ resolved results are added to the index. This has been corrected.
+
+ * "git cherry-pick" (and "revert" that shares the same runtime engine)
+ that deals with multiple commits got confused when the final step
+ gets stopped with a conflict and the user concluded the sequence
+ with "git commit". Attempt to fix it by cleaning up the state
+ files used by these commands in such a situation.
+ (merge 4a72486de9 pw/clean-sequencer-state-upon-final-commit later to maint).
+
+ * On a filesystem like HFS+, the names of the refs stored as filesystem
+ entities may become different from what the end-user expects, just
+ like files in the working tree get "renamed". Work around the
+ mismatch by paying attention to the core.precomposeUnicode
+ configuration.
+ (merge 8e712ef6fc en/unicode-in-refnames later to maint).
+
+ * The code to generate the multi-pack idx file was not prepared to
+ see too many packfiles and ran out of open file descriptor, which
+ has been corrected.
+
+ * To run tests for Git SVN, our scripts for CI used to install the
+ git-svn package (in the hope that it would bring in the right
+ dependencies). This has been updated to install the more direct
+ dependency, namely, libsvn-perl.
+ (merge db864306cf sg/ci-libsvn-perl later to maint).
+
+ * "git cvsexportcommit" running on msys did not expect cvsnt showed
+ "cvs status" output with CRLF line endings.
+
+ * The fsmonitor interface got out of sync after the in-core index
+ file gets discarded, which has been corrected.
+ (merge 398a3b0899 js/fsmonitor-refresh-after-discarding-index later to maint).
+
+ * "git status" did not know that the "label" instruction in the
+ todo-list "rebase -i -r" uses should not be shown as a hex object
+ name.
+
+ * A prerequisite check in the test suite to see if a working jgit is
+ available was made more robust.
+ (merge abd0f28983 tz/test-lib-check-working-jgit later to maint).
+
+ * The codepath to parse :<path> that obtains the object name for an
+ indexed object has been made more robust.
+
+ * Code cleanup, docfix, build fix, etc.
+ (merge 11f470aee7 jc/test-yes-doc later to maint).
+ (merge 90503a240b js/doc-symref-in-proto-v1 later to maint).
+ (merge 5c326d1252 jk/unused-params later to maint).
+ (merge 68cabbfda3 dl/doc-submodule-wo-subcommand later to maint).
+ (merge 9903623761 ab/receive-pack-use-after-free-fix later to maint).
+ (merge 1ede45e44b en/merge-options-doc later to maint).
+ (merge 3e14dd2c8e rd/doc-hook-used-in-sample later to maint).
+ (merge c271dc28fd nd/no-more-check-racy later to maint).
+ (merge e6e15194a8 yb/utf-16le-bom-spellfix later to maint).
+ (merge bb101aaf0c rd/attr.c-comment-typofix later to maint).
+ (merge 716a5af812 rd/gc-prune-doc-fix later to maint).
+ (merge 50b206371d js/untravis-windows later to maint).
+ (merge dbf47215e3 js/rebase-recreate-merge later to maint).
+ (merge 56cb2d30f8 dl/reset-doc-no-wrt-abbrev later to maint).
+ (merge 64eca306a2 ja/dir-rename-doc-markup-fix later to maint).
+ (merge af91b0230c dl/ignore-docs later to maint).
+ (merge 59a06e947b ra/t3600-test-path-funcs later to maint).
+ (merge e041d0781b ar/t4150-remove-cruft later to maint).
+ (merge 8d75a1d183 ma/asciidoctor-fixes-more later to maint).
+ (merge 74cc547b0f mh/pack-protocol-doc-fix later to maint).
+ (merge ed31851fa6 ab/doc-misc-typofixes later to maint).
+ (merge a7256debd4 nd/checkout-m-doc-update later to maint).
+ (merge 3a9e1ad78d jt/t5551-protocol-v2-does-not-have-half-auth later to maint).
+ (merge 0b918b75af sg/t5318-cleanup later to maint).
+ (merge 68ed71b53c cb/doco-mono later to maint).
+ (merge a34dca2451 nd/interpret-trailers-docfix later to maint).
+ (merge cf7b857a77 en/fast-import-parsing-fix later to maint).
+ (merge fe61ccbc35 po/rerere-doc-fmt later to maint).
+ (merge ffea0248bf po/describe-not-necessarily-7 later to maint).
+ (merge 7cb7283adb tg/ls-files-debug-format-fix later to maint).
+ (merge f64a21bd82 tz/doc-apostrophe-no-longer-needed later to maint).
+ (merge dbe7b41019 js/t3301-unbreak-notes-test later to maint).
+ (merge d8083e4180 km/t3000-retitle later to maint).
+ (merge 9e4cbccbd7 tz/git-svn-doc-markup-fix later to maint).
+ (merge da9ca955a7 jk/ls-files-doc-markup-fix later to maint).
+ (merge 6804ba3a58 cw/diff-highlight later to maint).
+ (merge 1a8787144d nd/submodule-helper-incomplete-line-fix later to maint).
+ (merge d9ef573837 jk/apache-lsan later to maint).
+ (merge c871fbee2b js/t6500-use-windows-pid-on-mingw later to maint).
+ (merge ce4c7bfc90 bl/t4253-exit-code-from-format-patch later to maint).
+ (merge 397a46db78 js/t5580-unc-alternate-test later to maint).
+ (merge d4907720a2 cm/notes-comment-fix later to maint).
+ (merge 9dde06de13 cb/http-push-null-in-message-fix later to maint).
+ (merge 4c785c0edc js/rebase-config-bitfix later to maint).
+ (merge 8e9fe16c87 es/doc-gitsubmodules-markup later to maint).
diff --git a/RelNotes/2.22.1.adoc b/RelNotes/2.22.1.adoc
new file mode 100644
index 0000000..432762f
--- /dev/null
+++ b/RelNotes/2.22.1.adoc
@@ -0,0 +1,150 @@
+Git 2.22.1 Release Notes
+========================
+
+Fixes since v2.22
+-----------------
+
+ * A relative pathname given to "git init --template=<path> <repo>"
+ ought to be relative to the directory "git init" gets invoked in,
+ but it instead was made relative to the repository, which has been
+ corrected.
+
+ * "git worktree add" used to fail when another worktree connected to
+ the same repository was corrupt, which has been corrected.
+
+ * The ownership rule for the file descriptor to fast-import remote
+ backend was mixed up, leading to unrelated file descriptor getting
+ closed, which has been fixed.
+
+ * "git update-server-info" used to leave stale packfiles in its
+ output, which has been corrected.
+
+ * The server side support for "git fetch" used to show incorrect
+ value for the HEAD symbolic ref when the namespace feature is in
+ use, which has been corrected.
+
+ * "git am -i --resolved" segfaulted after trying to see a commit as
+ if it were a tree, which has been corrected.
+
+ * "git bundle verify" needs to see if prerequisite objects exist in
+ the receiving repository, but the command did not check if we are
+ in a repository upfront, which has been corrected.
+
+ * "git merge --squash" is designed to update the working tree and the
+ index without creating the commit, and this cannot be countermanded
+ by adding the "--commit" option; the command now refuses to work
+ when both options are given.
+
+ * The data collected by fsmonitor was not properly written back to
+ the on-disk index file, breaking t7519 tests occasionally, which
+ has been corrected.
+
+ * Update to Unicode 12.1 width table.
+
+ * The command line to invoke a "git cat-file" command from inside
+ "git p4" was not properly quoted to protect a caret and running a
+ broken command on Windows, which has been corrected.
+
+ * "git request-pull" learned to warn when the ref we ask them to pull
+ from in the local repository and in the published repository are
+ different.
+
+ * When creating a partial clone, the object filtering criteria is
+ recorded for the origin of the clone, but this incorrectly used a
+ hardcoded name "origin" to name that remote; it has been corrected
+ to honor the "--origin <name>" option.
+
+ * "git fetch" into a lazy clone forgot to fetch base objects that are
+ necessary to complete delta in a thin packfile, which has been
+ corrected.
+
+ * The filter_data used in the list-objects-filter (which manages a
+ lazily sparse clone repository) did not use the dynamic array API
+ correctly---'nr' is supposed to point at one past the last element
+ of the array in use. This has been corrected.
+
+ * The description about slashes in gitignore patterns (used to
+ indicate things like "anchored to this level only" and "only
+ matches directories") has been revamped.
+
+ * The URL decoding code has been updated to avoid going past the end
+ of the string while parsing %-<hex>-<hex> sequence.
+
+ * The list of for-each like macros used by clang-format has been
+ updated.
+
+ * "git push --atomic" that goes over the transport-helper (namely,
+ the smart http transport) failed to prevent refs to be pushed when
+ it can locally tell that one of the ref update will fail without
+ having to consult the other end, which has been corrected.
+
+ * "git clean" silently skipped a path when it cannot lstat() it; now
+ it gives a warning.
+
+ * A codepath that reads from GPG for signed object verification read
+ past the end of allocated buffer, which has been fixed.
+
+ * "git rm" to resolve a conflicted path leaked an internal message
+ "needs merge" before actually removing the path, which was
+ confusing. This has been corrected.
+
+ * The "git clone" documentation refers to command line options in its
+ description in the short form; they have been replaced with long
+ forms to make them more recognisable.
+
+ * The configuration variable rebase.rescheduleFailedExec should be
+ effective only while running an interactive rebase and should not
+ affect anything when running a non-interactive one, which was not
+ the case. This has been corrected.
+
+ * "git submodule foreach" did not protect command line options passed
+ to the command to be run in each submodule correctly, when the
+ "--recursive" option was in use.
+
+ * Use "Erase in Line" CSI sequence that is already used in the editor
+ support to clear cruft in the progress output.
+
+ * The codepath to compute delta islands used to spew progress output
+ without giving the callers any way to squelch it, which has been
+ fixed.
+
+ * The code to parse scaled numbers out of configuration files has
+ been made more robust and also easier to follow.
+
+ * An incorrect list of options was cached after command line
+ completion failed (e.g. trying to complete a command that requires
+ a repository outside one), which has been corrected.
+
+ * "git rebase --abort" used to leave refs/rewritten/ when concluding
+ "git rebase -r", which has been corrected.
+
+ * "git stash show 23" used to work, but no more after getting
+ rewritten in C; this regression has been corrected.
+
+ * "git interpret-trailers" always treated '#' as the comment
+ character, regardless of core.commentChar setting, which has been
+ corrected.
+
+ * Code clean-up to avoid signed integer overlaps during binary search.
+
+ * "git checkout -p" needs to selectively apply a patch in reverse,
+ which did not work well.
+
+ * The commit-graph file is now part of the "files that the runtime
+ may keep open file descriptors on, all of which would need to be
+ closed when done with the object store", and the file descriptor to
+ an existing commit-graph file now is closed before "gc" finalizes a
+ new instance to replace it.
+
+ * Code restructuring during 2.20 period broke fetching tags via
+ "import" based transports.
+
+ * We have been trying out a few language features outside c89; the
+ coding guidelines document did not talk about them and instead had
+ a blanket ban against them.
+
+ * The internal diff machinery can be made to read out of bounds while
+ looking for --funcion-context line in a corner case, which has been
+ corrected.
+
+Also contains various documentation updates, code clean-ups and minor fixups.
diff --git a/RelNotes/2.22.2.adoc b/RelNotes/2.22.2.adoc
new file mode 100644
index 0000000..940a23f
--- /dev/null
+++ b/RelNotes/2.22.2.adoc
@@ -0,0 +1,8 @@
+Git v2.22.2 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.14.6, v2.15.4,
+v2.17.3, v2.20.2 and in v2.21.1, addressing the security issues
+CVE-2019-1348, CVE-2019-1349, CVE-2019-1350, CVE-2019-1351,
+CVE-2019-1352, CVE-2019-1353, CVE-2019-1354, CVE-2019-1387, and
+CVE-2019-19604; see the release notes for those versions for details.
diff --git a/RelNotes/2.22.3.adoc b/RelNotes/2.22.3.adoc
new file mode 100644
index 0000000..57296f6
--- /dev/null
+++ b/RelNotes/2.22.3.adoc
@@ -0,0 +1,5 @@
+Git v2.22.3 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.17.4; see
+the release notes for that version for details.
diff --git a/RelNotes/2.22.4.adoc b/RelNotes/2.22.4.adoc
new file mode 100644
index 0000000..8b5f3e3
--- /dev/null
+++ b/RelNotes/2.22.4.adoc
@@ -0,0 +1,5 @@
+Git v2.22.4 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.17.5; see
+the release notes for that version for details.
diff --git a/RelNotes/2.22.5.adoc b/RelNotes/2.22.5.adoc
new file mode 100644
index 0000000..6b280d9
--- /dev/null
+++ b/RelNotes/2.22.5.adoc
@@ -0,0 +1,7 @@
+Git v2.22.5 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.17.6,
+v2.18.5, v2.19.6, v2.20.5 and v2.21.4 to address the security
+issue CVE-2021-21300; see the release notes for these versions
+for details.
diff --git a/RelNotes/2.23.0.adoc b/RelNotes/2.23.0.adoc
new file mode 100644
index 0000000..e3c4e78
--- /dev/null
+++ b/RelNotes/2.23.0.adoc
@@ -0,0 +1,348 @@
+Git 2.23 Release Notes
+======================
+
+Updates since v2.22
+-------------------
+
+Backward compatibility note
+
+ * The "--base" option of "format-patch" computed the patch-ids for
+ prerequisite patches in an unstable way, which has been updated to
+ compute in a way that is compatible with "git patch-id --stable".
+
+ * The "git log" command by default behaves as if the --mailmap option
+ was given.
+
+
+UI, Workflows & Features
+
+ * The "git fast-export/import" pair has been taught to handle commits
+ with log messages in encoding other than UTF-8 better.
+
+ * In recent versions of Git, per-worktree refs are exposed in
+ refs/worktrees/<wtname>/ hierarchy, which means that worktree names
+ must be a valid refname component. The code now sanitizes the names
+ given to worktrees, to make sure these refs are well-formed.
+
+ * "git merge" learned "--quit" option that cleans up the in-progress
+ merge while leaving the working tree and the index still in a mess.
+
+ * "git format-patch" learns a configuration to set the default for
+ its --notes=<ref> option.
+
+ * The code to show args with potential typo that cannot be
+ interpreted as a commit-ish has been improved.
+
+ * "git clone --recurse-submodules" learned to set up the submodules
+ to ignore commit object names recorded in the superproject gitlink
+ and instead use the commits that happen to be at the tip of the
+ remote-tracking branches from the get-go, by passing the new
+ "--remote-submodules" option.
+
+ * The pattern "git diff/grep" use to extract funcname and words
+ boundary for Matlab has been extend to cover Octave, which is more
+ or less equivalent.
+
+ * "git help git" was hard to discover (well, at least for some
+ people).
+
+ * The pattern "git diff/grep" use to extract funcname and words
+ boundary for Rust has been added.
+
+ * "git status" can be told a non-standard default value for the
+ "--[no-]ahead-behind" option with a new configuration variable
+ status.aheadBehind.
+
+ * "git fetch" and "git pull" reports when a fetch results in
+ non-fast-forward updates to let the user notice unusual situation.
+ The commands learned "--no-show-forced-updates" option to disable
+ this safety feature.
+
+ * Two new commands "git switch" and "git restore" are introduced to
+ split "checking out a branch to work on advancing its history" and
+ "checking out paths out of the index and/or a tree-ish to work on
+ advancing the current history" out of the single "git checkout"
+ command.
+
+ * "git branch --list" learned to always output the detached HEAD as
+ the first item (when the HEAD is detached, of course), regardless
+ of the locale.
+
+ * The conditional inclusion mechanism learned to base the choice on
+ the branch the HEAD currently is on.
+
+ * "git rev-list --objects" learned the "--no-object-names" option to
+ squelch the path to the object that is used as a grouping hint for
+ pack-objects.
+
+ * A new tag.gpgSign configuration variable turns "git tag -a" into
+ "git tag -s".
+
+ * "git multi-pack-index" learned expire and repack subcommands.
+
+ * "git blame" learned to "ignore" commits in the history, whose
+ effects (as well as their presence) get ignored.
+
+ * "git cherry-pick/revert" learned a new "--skip" action.
+
+ * The tips of refs from the alternate object store can be used as
+ starting point for reachability computation now.
+
+ * Extra blank lines in "git status" output have been reduced.
+
+ * The commits in a repository can be described by multiple
+ commit-graph files now, which allows the commit-graph files to be
+ updated incrementally.
+
+ * "git range-diff" output has been tweaked for easier identification
+ of which part of what file the patch shown is about.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * Update supporting parts of "git rebase" to remove code that should
+ no longer be used.
+
+ * Developer support to emulate unsatisfied prerequisites in tests to
+ ensure that the remainder of the tests still succeeds when tests
+ with prerequisites are skipped.
+
+ * "git update-server-info" learned not to rewrite the file with the
+ same contents.
+
+ * The way of specifying the path to find dynamic libraries at runtime
+ has been simplified. The old default to pass -R/path/to/dir has been
+ replaced with the new default to pass -Wl,-rpath,/path/to/dir,
+ which is the more recent GCC uses. Those who need to build with an
+ old GCC can still use "CC_LD_DYNPATH=-R"
+
+ * Prepare use of reachability index in topological walker that works
+ on a range (A..B).
+
+ * A new tutorial targeting specifically aspiring git-core
+ developers has been added.
+
+ * Auto-detect how to tell HP-UX aCC where to use dynamically linked
+ libraries from at runtime.
+
+ * "git mergetool" and its tests now spawn fewer subprocesses.
+
+ * Dev support update to help tracing out tests.
+
+ * Support to build with MSVC has been updated.
+
+ * "git fetch" that grabs from a group of remotes learned to run the
+ auto-gc only once at the very end.
+
+ * A handful of Windows build patches have been upstreamed.
+
+ * The code to read state files used by the sequencer machinery for
+ "git status" has been made more robust against a corrupt or stale
+ state files.
+
+ * "git for-each-ref" with multiple patterns have been optimized.
+
+ * The tree-walk API learned to pass an in-core repository
+ instance throughout more codepaths.
+
+ * When one step in multi step cherry-pick or revert is reset or
+ committed, the command line prompt script failed to notice the
+ current status, which has been improved.
+
+ * Many GIT_TEST_* environment variables control various aspects of
+ how our tests are run, but a few followed "non-empty is true, empty
+ or unset is false" while others followed the usual "there are a few
+ ways to spell true, like yes, on, etc., and also ways to spell
+ false, like no, off, etc." convention.
+
+ * Adjust the dir-iterator API and apply it to the local clone
+ optimization codepath.
+
+ * We have been trying out a few language features outside c89; the
+ coding guidelines document did not talk about them and instead had
+ a blanket ban against them.
+
+ * A test helper has been introduced to optimize preparation of test
+ repositories with many simple commits, and a handful of test
+ scripts have been updated to use it.
+
+
+Fixes since v2.22
+-----------------
+
+ * A relative pathname given to "git init --template=<path> <repo>"
+ ought to be relative to the directory "git init" gets invoked in,
+ but it instead was made relative to the repository, which has been
+ corrected.
+
+ * "git worktree add" used to fail when another worktree connected to
+ the same repository was corrupt, which has been corrected.
+
+ * The ownership rule for the file descriptor to fast-import remote
+ backend was mixed up, leading to an unrelated file descriptor getting
+ closed, which has been fixed.
+
+ * A "merge -c" instruction during "git rebase --rebase-merges" should
+ give the user a chance to edit the log message, even when there is
+ otherwise no need to create a new merge and replace the existing
+ one (i.e. fast-forward instead), but did not. Which has been
+ corrected.
+
+ * Code cleanup and futureproof.
+
+ * More parameter validation.
+
+ * "git update-server-info" used to leave stale packfiles in its
+ output, which has been corrected.
+
+ * The server side support for "git fetch" used to show incorrect
+ value for the HEAD symbolic ref when the namespace feature is in
+ use, which has been corrected.
+
+ * "git am -i --resolved" segfaulted after trying to see a commit as
+ if it were a tree, which has been corrected.
+
+ * "git bundle verify" needs to see if prerequisite objects exist in
+ the receiving repository, but the command did not check if we are
+ in a repository upfront, which has been corrected.
+
+ * "git merge --squash" is designed to update the working tree and the
+ index without creating the commit, and this cannot be countermanded
+ by adding the "--commit" option; the command now refuses to work
+ when both options are given.
+
+ * The data collected by fsmonitor was not properly written back to
+ the on-disk index file, breaking t7519 tests occasionally, which
+ has been corrected.
+
+ * Update to Unicode 12.1 width table.
+
+ * The command line to invoke a "git cat-file" command from inside
+ "git p4" was not properly quoted to protect a caret and running a
+ broken command on Windows, which has been corrected.
+
+ * "git request-pull" learned to warn when the ref we ask them to pull
+ from in the local repository and in the published repository are
+ different.
+
+ * When creating a partial clone, the object filtering criteria is
+ recorded for the origin of the clone, but this incorrectly used a
+ hardcoded name "origin" to name that remote; it has been corrected
+ to honor the "--origin <name>" option.
+
+ * "git fetch" into a lazy clone forgot to fetch base objects that are
+ necessary to complete delta in a thin packfile, which has been
+ corrected.
+
+ * The filter_data used in the list-objects-filter (which manages a
+ lazily sparse clone repository) did not use the dynamic array API
+ correctly---'nr' is supposed to point at one past the last element
+ of the array in use. This has been corrected.
+
+ * The description about slashes in gitignore patterns (used to
+ indicate things like "anchored to this level only" and "only
+ matches directories") has been revamped.
+
+ * The URL decoding code has been updated to avoid going past the end
+ of the string while parsing %-<hex>-<hex> sequence.
+
+ * The list of for-each like macros used by clang-format has been
+ updated.
+
+ * "git branch --list" learned to show branches that are checked out
+ in other worktrees connected to the same repository prefixed with
+ '+', similar to the way the currently checked out branch is shown
+ with '*' in front.
+ (merge 6e9381469e nb/branch-show-other-worktrees-head later to maint).
+
+ * Code restructuring during 2.20 period broke fetching tags via
+ "import" based transports.
+
+ * The commit-graph file is now part of the "files that the runtime
+ may keep open file descriptors on, all of which would need to be
+ closed when done with the object store", and the file descriptor to
+ an existing commit-graph file now is closed before "gc" finalizes a
+ new instance to replace it.
+
+ * "git checkout -p" needs to selectively apply a patch in reverse,
+ which did not work well.
+
+ * Code clean-up to avoid signed integer wraparounds during binary search.
+
+ * "git interpret-trailers" always treated '#' as the comment
+ character, regardless of core.commentChar setting, which has been
+ corrected.
+
+ * "git stash show 23" used to work, but no more after getting
+ rewritten in C; this regression has been corrected.
+
+ * "git rebase --abort" used to leave refs/rewritten/ when concluding
+ "git rebase -r", which has been corrected.
+
+ * An incorrect list of options was cached after command line
+ completion failed (e.g. trying to complete a command that requires
+ a repository outside one), which has been corrected.
+
+ * The code to parse scaled numbers out of configuration files has
+ been made more robust and also easier to follow.
+
+ * The codepath to compute delta islands used to spew progress output
+ without giving the callers any way to squelch it, which has been
+ fixed.
+
+ * Protocol capabilities that go over wire should never be translated,
+ but it was incorrectly marked for translation, which has been
+ corrected. The output of protocol capabilities for debugging has
+ been tweaked a bit.
+
+ * Use "Erase in Line" CSI sequence that is already used in the editor
+ support to clear cruft in the progress output.
+
+ * "git submodule foreach" did not protect command line options passed
+ to the command to be run in each submodule correctly, when the
+ "--recursive" option was in use.
+
+ * The configuration variable rebase.rescheduleFailedExec should be
+ effective only while running an interactive rebase and should not
+ affect anything when running a non-interactive one, which was not
+ the case. This has been corrected.
+
+ * The "git clone" documentation refers to command line options in its
+ description in the short form; they have been replaced with long
+ forms to make them more recognisable.
+
+ * Generation of pack bitmaps are now disabled when .keep files exist,
+ as these are mutually exclusive features.
+ (merge 7328482253 ew/repack-with-bitmaps-by-default later to maint).
+
+ * "git rm" to resolve a conflicted path leaked an internal message
+ "needs merge" before actually removing the path, which was
+ confusing. This has been corrected.
+
+ * "git stash --keep-index" did not work correctly on paths that have
+ been removed, which has been fixed.
+ (merge b932f6a5e8 tg/stash-keep-index-with-removed-paths later to maint).
+
+ * Window 7 update ;-)
+
+ * A codepath that reads from GPG for signed object verification read
+ past the end of allocated buffer, which has been fixed.
+
+ * "git clean" silently skipped a path when it cannot lstat() it; now
+ it gives a warning.
+
+ * "git push --atomic" that goes over the transport-helper (namely,
+ the smart http transport) failed to prevent refs to be pushed when
+ it can locally tell that one of the ref update will fail without
+ having to consult the other end, which has been corrected.
+
+ * The internal diff machinery can be made to read out of bounds while
+ looking for --function-context line in a corner case, which has been
+ corrected.
+ (merge b777f3fd61 jk/xdiff-clamp-funcname-context-index later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge fbec05c210 cc/test-oidmap later to maint).
+ (merge 7a06fb038c jk/no-system-includes-in-dot-c later to maint).
+ (merge 81ed2b405c cb/xdiff-no-system-includes-in-dot-c later to maint).
+ (merge d61e6ce1dd sg/fsck-config-in-doc later to maint).
diff --git a/RelNotes/2.23.1.adoc b/RelNotes/2.23.1.adoc
new file mode 100644
index 0000000..2083b49
--- /dev/null
+++ b/RelNotes/2.23.1.adoc
@@ -0,0 +1,8 @@
+Git v2.23.1 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.14.6, v2.15.4,
+v2.17.3, v2.20.2 and in v2.21.1, addressing the security issues
+CVE-2019-1348, CVE-2019-1349, CVE-2019-1350, CVE-2019-1351,
+CVE-2019-1352, CVE-2019-1353, CVE-2019-1354, CVE-2019-1387, and
+CVE-2019-19604; see the release notes for those versions for details.
diff --git a/RelNotes/2.23.2.adoc b/RelNotes/2.23.2.adoc
new file mode 100644
index 0000000..b697cbe
--- /dev/null
+++ b/RelNotes/2.23.2.adoc
@@ -0,0 +1,5 @@
+Git v2.23.2 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.17.4; see
+the release notes for that version for details.
diff --git a/RelNotes/2.23.3.adoc b/RelNotes/2.23.3.adoc
new file mode 100644
index 0000000..2e35490
--- /dev/null
+++ b/RelNotes/2.23.3.adoc
@@ -0,0 +1,5 @@
+Git v2.23.3 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.17.5; see
+the release notes for that version for details.
diff --git a/RelNotes/2.23.4.adoc b/RelNotes/2.23.4.adoc
new file mode 100644
index 0000000..6e5424d
--- /dev/null
+++ b/RelNotes/2.23.4.adoc
@@ -0,0 +1,7 @@
+Git v2.23.4 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.17.6, v2.18.5,
+v2.19.6, v2.20.5, v2.21.4 and v2.22.5 to address the security
+issue CVE-2021-21300; see the release notes for these versions
+for details.
diff --git a/RelNotes/2.24.0.adoc b/RelNotes/2.24.0.adoc
new file mode 100644
index 0000000..bde1541
--- /dev/null
+++ b/RelNotes/2.24.0.adoc
@@ -0,0 +1,398 @@
+Git 2.24 Release Notes
+======================
+
+Updates since v2.23
+-------------------
+
+Backward compatibility note
+
+ * "filter-branch" is showing its age and alternatives are available.
+ From this release, we started to discourage its use and hint
+ people about filter-repo.
+
+UI, Workflows & Features
+
+ * We now have an active interim maintainer for the Git-Gui part of
+ the system. Praise and thank Pratyush Yadav for volunteering.
+
+ * The command line parser learned "--end-of-options" notation; the
+ standard convention for scripters to have hardcoded set of options
+ first on the command line, and force the command to treat end-user
+ input as non-options, has been to use "--" as the delimiter, but
+ that would not work for commands that use "--" as a delimiter
+ between revs and pathspec.
+
+ * A mechanism to affect the default setting for a (related) group of
+ configuration variables is introduced.
+
+ * "git fetch" learned "--set-upstream" option to help those who first
+ clone from their private fork they intend to push to, add the true
+ upstream via "git remote add" and then "git fetch" from it.
+
+ * Device-tree files learned their own userdiff patterns.
+ (merge 3c81760bc6 sb/userdiff-dts later to maint).
+
+ * "git rebase --rebase-merges" learned to drive different merge
+ strategies and pass strategy specific options to them.
+
+ * A new "pre-merge-commit" hook has been introduced.
+
+ * Command line completion updates for "git -c var.name=val" have been
+ added.
+
+ * The lazy clone machinery has been taught that there can be more
+ than one promisor remote and consult them in order when downloading
+ missing objects on demand.
+
+ * The list-objects-filter API (used to create a sparse/lazy clone)
+ learned to take a combined filter specification.
+
+ * The documentation and tests for "git format-patch" have been
+ cleaned up.
+
+ * On Windows, the root level of UNC share is now allowed to be used
+ just like any other directory.
+
+ * The command line completion support (in contrib/) learned about the
+ "--skip" option of "git revert" and "git cherry-pick".
+
+ * "git rebase --keep-base <upstream>" tries to find the original base
+ of the topic being rebased and rebase on top of that same base,
+ which is useful when running the "git rebase -i" (and its limited
+ variant "git rebase -x").
+
+ The command also has learned to fast-forward in more cases where it
+ can instead of replaying to recreate identical commits.
+
+ * A configuration variable tells "git fetch" to write the commit
+ graph after finishing.
+
+ * "git add -i" has been taught to show the total number of hunks and
+ the hunks that has been processed so far when showing prompts.
+
+ * "git fetch --jobs=<n>" allowed <n> parallel jobs when fetching
+ submodules, but this did not apply to "git fetch --multiple" that
+ fetches from multiple remote repositories. It now does.
+
+ * The installation instruction for zsh completion script (in
+ contrib/) has been a bit improved.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * The code to write commit-graph over given commit object names has
+ been made a bit more robust.
+
+ * The first line of verbose output from each test piece now carries
+ the test name and number to help scanning with eyeballs.
+
+ * Further clean-up of the initialization code.
+
+ * xmalloc() used to have a mechanism to ditch memory and address
+ space resources as the last resort upon seeing an allocation
+ failure from the underlying malloc(), which made the code complex
+ and thread-unsafe with dubious benefit, as major memory resource
+ users already do limit their uses with various other mechanisms.
+ It has been simplified away.
+
+ * Unnecessary full-tree diff in "git log -L" machinery has been
+ optimized away.
+
+ * The http transport lacked some optimization the native transports
+ learned to avoid unnecessary ref advertisement, which has been
+ corrected.
+
+ * Preparation for SHA-256 upgrade continues in the test department.
+ (merge 0c37c41d13 bc/hash-independent-tests-part-5 later to maint).
+
+ * The memory ownership model of the "git fast-import" got
+ straightened out.
+
+ * Output from trace2 subsystem is formatted more prettily now.
+
+ * The internal code originally invented for ".gitignore" processing
+ got reshuffled and renamed to make it less tied to "excluding" and
+ stress more that it is about "matching", as it has been reused for
+ things like sparse checkout specification that want to check if a
+ path is "included".
+
+ * "git stash" learned to write refreshed index back to disk.
+
+ * Coccinelle checks are done on more source files than before now.
+
+ * The cache-tree code has been taught to be less aggressive in
+ attempting to see if a tree object it computed already exists in
+ the repository.
+
+ * The code to parse and use the commit-graph file has been made more
+ robust against corrupted input.
+
+ * The hg-to-git script (in contrib/) has been updated to work with
+ Python 3.
+
+ * Update the way build artifacts in t/helper/ directory are ignored.
+
+ * Preparation for SHA-256 upgrade continues.
+
+ * "git log --graph" for an octopus merge is sometimes colored
+ incorrectly, which is demonstrated and documented but not yet
+ fixed.
+
+ * The trace2 output, when sending them to files in a designated
+ directory, can populate the directory with too many files; a
+ mechanism is introduced to set the maximum number of files and
+ discard further logs when the maximum is reached.
+
+ * We have adopted a Code-of-conduct document.
+ (merge 3f9ef874a7 jk/coc later to maint).
+
+
+Fixes since v2.23
+-----------------
+
+ * "git grep --recurse-submodules" that looks at the working tree
+ files looked at the contents in the index in submodules, instead of
+ files in the working tree.
+ (merge 6a289d45c0 mt/grep-submodules-working-tree later to maint).
+
+ * Codepaths to walk tree objects have been audited for integer
+ overflows and hardened.
+ (merge 5aa02f9868 jk/tree-walk-overflow later to maint).
+
+ * "git pack-refs" can lose refs that are created while running, which
+ is getting corrected.
+ (merge a613d4f817 sc/pack-refs-deletion-racefix later to maint).
+
+ * "git checkout" and "git restore" to re-populate the index from a
+ tree-ish (typically HEAD) did not work correctly for a path that
+ was removed and then added again with the intent-to-add bit, when
+ the corresponding working tree file was empty. This has been
+ corrected.
+
+ * Compilation fix.
+ (merge 70597e8386 rs/nedalloc-fixlets later to maint).
+
+ * "git gui" learned to call the clean-up procedure before exiting.
+ (merge 0d88f3d2c5 py/git-gui-do-quit later to maint).
+
+ * We promoted the "indent heuristics" that decides where to split
+ diff hunks from experimental to the default a few years ago, but
+ some stale documentation still marked it as experimental, which has
+ been corrected.
+ (merge 64e5e1fba1 sg/diff-indent-heuristic-non-experimental later to maint).
+
+ * Fix a mismerge that happened in 2.22 timeframe.
+ (merge acb7da05ac en/checkout-mismerge-fix later to maint).
+
+ * "git archive" recorded incorrect length in extended pax header in
+ some corner cases, which has been corrected.
+ (merge 71d41ff651 rs/pax-extended-header-length-fix later to maint).
+
+ * On-demand object fetching in lazy clone incorrectly tried to fetch
+ commits from submodule projects, while still working in the
+ superproject, which has been corrected.
+ (merge a63694f523 jt/diff-lazy-fetch-submodule-fix later to maint).
+
+ * Prepare get_short_oid() codepath to be thread-safe.
+ (merge 7cfcb16b0e rs/sort-oid-array-thread-safe later to maint).
+
+ * "for-each-ref" and friends that show refs did not protect themselves
+ against ancient tags that did not record tagger names when asked to
+ show "%(taggername)", which have been corrected.
+ (merge 8b3f33ef11 mp/for-each-ref-missing-name-or-email later to maint).
+
+ * The "git am" based backend of "git rebase" ignored the result of
+ updating ".gitattributes" done in one step when replaying
+ subsequent steps.
+ (merge 2c65d90f75 bc/reread-attributes-during-rebase later to maint).
+
+ * Tell cURL library to use the same malloc() implementation, with the
+ xmalloc() wrapper, as the rest of the system, for consistency.
+ (merge 93b980e58f cb/curl-use-xmalloc later to maint).
+
+ * Build fix to adjust .gitignore to unignore a path that we started to track.
+ (merge aac6ff7b5b js/visual-studio later to maint).
+
+ * A few implementation fixes in the notes API.
+ (merge 60fe477a0b mh/notes-duplicate-entries later to maint).
+
+ * Fix an earlier regression to "git push --all" which should have
+ been forbidden when the target remote repository is set to be a
+ mirror.
+ (merge 8e4c8af058 tg/push-all-in-mirror-forbidden later to maint).
+
+ * Fix an earlier regression in the test suite, which mistakenly
+ stopped running HTTPD tests.
+ (merge 3960290675 sg/git-test-boolean later to maint).
+
+ * "git rebase --autostash <upstream> <branch>", when <branch> is
+ different from the current branch, incorrectly moved the tip of the
+ current branch, which has been corrected.
+ (merge bf1e28e0ad bw/rebase-autostash-keep-current-branch later to maint).
+
+ * Update support for Asciidoctor documentation toolchain.
+ (merge 83b0b8953e ma/asciidoctor-refmiscinfo later to maint).
+
+ * Start using DocBook 5 (instead of DocBook 4.5) as Asciidoctor 2.0
+ no longer works with the older one.
+ (merge f6461b82b9 bc/doc-use-docbook-5 later to maint).
+
+ * The markup used in user-manual has been updated to work better with
+ asciidoctor.
+ (merge c4d2f6143a ma/user-manual-markup-update later to maint).
+
+ * Make sure the grep machinery does not abort when seeing a payload
+ that is not UTF-8 even when JIT is not in use with PCRE1.
+ (merge ad7c543e3b cb/skip-utf8-check-with-pcre1 later to maint).
+
+ * The name of the blob object that stores the filter specification
+ for sparse cloning/fetching was interpreted in a wrong place in the
+ code, causing Git to abort.
+
+ * "git log --decorate-refs-exclude=<pattern>" was incorrectly
+ overruled when the "--simplify-by-decoration" option is used, which
+ has been corrected.
+ (merge 0cc7380d88 rs/simplify-by-deco-with-deco-refs-exclude later to maint).
+
+ * The "upload-pack" (the counterpart of "git fetch") needs to disable
+ commit-graph when responding to a shallow clone/fetch request, but
+ the way this was done made Git panic, which has been corrected.
+
+ * The object traversal machinery has been optimized not to load tree
+ objects when we are only interested in commit history.
+ (merge 72ed80c784 jk/list-objects-optim-wo-trees later to maint).
+
+ * The object name parser for "Nth parent" syntax has been made more
+ robust against integer overflows.
+ (merge 59fa5f5a25 rs/nth-parent-parse later to maint).
+
+ * The code used in following tags in "git fetch" has been optimized.
+ (merge b7e2d8bca5 ms/fetch-follow-tag-optim later to maint).
+
+ * Regression fix for progress output.
+ (merge 2bb74b53a4 sg/progress-fix later to maint).
+
+ * A bug in merge-recursive code that triggers when a branch with a
+ symbolic link is merged with a branch that replaces it with a
+ directory has been fixed.
+ (merge 83e3ad3b12 jt/merge-recursive-symlink-is-not-a-dir-in-way later to maint).
+
+ * The rename detection logic sorts a list of rename source candidates
+ by similarity to pick the best candidate, which means that a tie
+ between sources with the same similarity is broken by the original
+ location in the original candidate list (which is sorted by path).
+ Force the sorting by similarity done with a stable sort, which is
+ not promised by system supplied qsort(3), to ensure consistent
+ results across platforms.
+ (merge 2049b8dc65 js/diff-rename-force-stable-sort later to maint).
+
+ * The code to skip "UTF" and "UTF-" prefix, when computing an advice
+ message, did not work correctly when the prefix was "UTF", which
+ has been fixed.
+ (merge b181676ce9 rs/convert-fix-utf-without-dash later to maint).
+
+ * The author names taken from SVN repositories may have extra leading
+ or trailing whitespaces, which are now munged away.
+ (merge 4ddd4bddb1 tk/git-svn-trim-author-name later to maint).
+
+ * "git rebase -i" showed a wrong HEAD while "reword" open the editor.
+ (merge b0a3186140 pw/rebase-i-show-HEAD-to-reword later to maint).
+
+ * A few simplification and bugfixes to PCRE interface.
+ (merge c581e4a749 ab/pcre-jit-fixes later to maint).
+
+ * PCRE fixes.
+ (merge ff61681b46 cb/pcre1-cleanup later to maint).
+
+ * "git range-diff" segfaulted when diff.noprefix configuration was
+ used, as it blindly expected the patch it internally generates to
+ have the standard a/ and b/ prefixes. The command now forces the
+ internal patch to be built without any prefix, not to be affected
+ by any end-user configuration.
+ (merge 937b76ed49 js/range-diff-noprefix later to maint).
+
+ * "git stash apply" in a subdirectory of a secondary worktree failed
+ to access the worktree correctly, which has been corrected.
+ (merge dfd557c978 js/stash-apply-in-secondary-worktree later to maint).
+
+ * The merge-recursive machinery is one of the most complex parts of
+ the system that accumulated cruft over time. This large series
+ cleans up the implementation quite a bit.
+ (merge b657047719 en/merge-recursive-cleanup later to maint).
+
+ * Pretty-printed command line formatter (used in e.g. reporting the
+ command being run by the tracing API) had a bug that lost an
+ argument that is an empty string, which has been corrected.
+ (merge ce2d7ed2fd gs/sq-quote-buf-pretty later to maint).
+
+ * "git range-diff" failed to handle mode-only change, which has been
+ corrected.
+ (merge 2b6a9b13ca tg/range-diff-output-update later to maint).
+
+ * Dev support update.
+ (merge 4f3c1dc5d6 dl/allow-running-cocci-verbosely later to maint).
+
+ * "git format-patch -o <outdir>" did an equivalent of "mkdir <outdir>"
+ not "mkdir -p <outdir>", which was corrected.
+
+ * "git stash save" lost local changes to submodules, which has been
+ corrected.
+ (merge 556895d0c8 jj/stash-reset-only-toplevel later to maint).
+
+ * The atomic push over smart HTTP transport did not work, which has
+ been corrected.
+ (merge 6f1194246a bc/smart-http-atomic-push later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge d1387d3895 en/fast-import-merge-doc later to maint).
+ (merge 1c24a54ea4 bm/repository-layout-typofix later to maint).
+ (merge 415b770b88 ds/midx-expire-repack later to maint).
+ (merge 19800bdc3f nd/diff-parseopt later to maint).
+ (merge 58166c2e9d tg/t0021-racefix later to maint).
+ (merge 7027f508c7 dl/compat-cleanup later to maint).
+ (merge e770fbfeff jc/test-cleanup later to maint).
+ (merge 1fd881d404 rs/trace2-dst-warning later to maint).
+ (merge 7e92756751 mh/http-urlmatch-cleanup later to maint).
+ (merge 9784f97321 mh/release-commit-memory-fix later to maint).
+ (merge 60d198d022 tb/banned-vsprintf-namefix later to maint).
+ (merge 80e3658647 rs/help-unknown-ref-does-not-return later to maint).
+ (merge 0a8bc7068f dt/remote-helper-doc-re-lock-option later to maint).
+ (merge 27fd1e4ea7 en/merge-options-ff-and-friends later to maint).
+ (merge 502c386ff9 sg/clean-nested-repo-with-ignored later to maint).
+ (merge 26e3d1cbea am/mailmap-andrey-mazo later to maint).
+ (merge 47b27c96fa ss/get-time-cleanup later to maint).
+ (merge dd2e50a84e jk/commit-graph-cleanup later to maint).
+ (merge 4fd39c76e6 cs/pretty-formats-doc-typofix later to maint).
+ (merge 40e747e89d dl/submodule-set-branch later to maint).
+ (merge 689a146c91 rs/commit-graph-use-list-count later to maint).
+ (merge 0eb7c37a8a js/doc-patch-text later to maint).
+ (merge 4b3aa170d1 rs/nth-switch-code-simplification later to maint).
+ (merge 0d4304c124 ah/doc-submodule-ignore-submodules later to maint).
+ (merge af78249463 cc/svn-fe-py-shebang later to maint).
+ (merge 7bd97d6dff rs/alias-use-copy-array later to maint).
+ (merge c46ebc2496 sg/travis-help-debug later to maint).
+ (merge 24c681794f ps/my-first-contribution-alphasort later to maint).
+ (merge 75b2c15435 cb/do-not-use-test-cmp-with-a later to maint).
+ (merge cda0d497e3 bw/submodule-helper-usage-fix later to maint).
+ (merge fe0ed5d5e9 am/visual-studio-config-fix later to maint).
+ (merge 2e09c01232 sg/name-rev-cutoff-underflow-fix later to maint).
+ (merge ddb3c856f3 as/shallow-slab-use-fix later to maint).
+ (merge 71f4960b91 js/mingw-spawn-with-spaces-in-path later to maint).
+ (merge 53d687bf5f ah/cleanups later to maint).
+ (merge f537485fa5 rs/test-remove-useless-debugging-cat later to maint).
+ (merge 11a3d3aadd dl/rev-list-doc-cleanup later to maint).
+ (merge d928a8388a am/t0028-utf16-tests later to maint).
+ (merge b05b40930e dl/t0000-skip-test-test later to maint).
+ (merge 03d3b1297c js/xdiffi-comment-updates later to maint).
+ (merge 57d8f4b4c7 js/doc-stash-save later to maint).
+ (merge 8c1cfd58e3 ta/t1308-typofix later to maint).
+ (merge fa364ad790 bb/utf8-wcwidth-cleanup later to maint).
+ (merge 68b69211b2 bb/compat-util-comment-fix later to maint).
+ (merge 5cc6a4be11 rs/http-push-simplify later to maint).
+ (merge a81e42d235 rs/column-use-utf8-strnwidth later to maint).
+ (merge 062a309d36 rs/remote-curl-use-argv-array later to maint).
+ (merge 3b3c79f6c9 nr/diff-highlight-indent-fix later to maint).
+ (merge 3444ec2eb2 wb/fsmonitor-bitmap-fix later to maint).
+ (merge 10da030ab7 cb/pcre2-chartables-leakfix later to maint).
+ (merge 60e6569a12 js/mingw-needs-hiding-fix later to maint).
+ (merge 52bd3e4657 rl/gitweb-blame-prev-fix later to maint).
diff --git a/RelNotes/2.24.1.adoc b/RelNotes/2.24.1.adoc
new file mode 100644
index 0000000..1810485
--- /dev/null
+++ b/RelNotes/2.24.1.adoc
@@ -0,0 +1,8 @@
+Git v2.24.1 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.14.6, v2.15.4,
+v2.17.3, v2.20.2 and in v2.21.1, addressing the security issues
+CVE-2019-1348, CVE-2019-1349, CVE-2019-1350, CVE-2019-1351,
+CVE-2019-1352, CVE-2019-1353, CVE-2019-1354, CVE-2019-1387, and
+CVE-2019-19604; see the release notes for those versions for details.
diff --git a/RelNotes/2.24.2.adoc b/RelNotes/2.24.2.adoc
new file mode 100644
index 0000000..0049f65
--- /dev/null
+++ b/RelNotes/2.24.2.adoc
@@ -0,0 +1,5 @@
+Git v2.24.2 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.17.4; see
+the release notes for that version for details.
diff --git a/RelNotes/2.24.3.adoc b/RelNotes/2.24.3.adoc
new file mode 100644
index 0000000..5302e0f
--- /dev/null
+++ b/RelNotes/2.24.3.adoc
@@ -0,0 +1,5 @@
+Git v2.24.3 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.17.5; see
+the release notes for that version for details.
diff --git a/RelNotes/2.24.4.adoc b/RelNotes/2.24.4.adoc
new file mode 100644
index 0000000..4e216ee
--- /dev/null
+++ b/RelNotes/2.24.4.adoc
@@ -0,0 +1,7 @@
+Git v2.24.4 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.17.6, v2.18.5,
+v2.19.6, v2.20.5, v2.21.4, v2.22.5 and v2.23.4 to address the
+security issue CVE-2021-21300; see the release notes for these
+versions for details.
diff --git a/RelNotes/2.25.0.adoc b/RelNotes/2.25.0.adoc
new file mode 100644
index 0000000..91ceb34
--- /dev/null
+++ b/RelNotes/2.25.0.adoc
@@ -0,0 +1,370 @@
+Git 2.25 Release Notes
+======================
+
+Updates since v2.24
+-------------------
+
+Backward compatibility notes
+
+
+UI, Workflows & Features
+
+ * A tutorial on object enumeration has been added.
+
+ * The branch description ("git branch --edit-description") has been
+ used to fill the body of the cover letters by the format-patch
+ command; this has been enhanced so that the subject can also be
+ filled.
+
+ * "git rebase --preserve-merges" has been marked as deprecated; this
+ release stops advertising it in the "git rebase -h" output.
+
+ * The code to generate multi-pack index learned to show (or not to
+ show) progress indicators.
+
+ * "git apply --3way" learned to honor merge.conflictStyle
+ configuration variable, like merges would.
+
+ * The custom format for "git log --format=<format>" learned the l/L
+ placeholder that is similar to e/E that fills in the e-mail
+ address, but only the local part on the left side of '@'.
+
+ * Documentation pages for "git shortlog" now list commit limiting
+ options explicitly.
+
+ * The patterns to detect function boundary for Elixir language has
+ been added.
+
+ * The completion script (in contrib/) learned that the "--onto"
+ option of "git rebase" can take its argument as the value of the
+ option.
+
+ * The userdiff machinery has been taught that "async def" is another
+ way to begin a "function" in Python.
+
+ * "git range-diff" learned to take the "--notes=<ref>" and the
+ "--no-notes" options to control the commit notes included in the
+ log message that gets compared.
+
+ * "git rev-parse --show-toplevel" run outside of any working tree did
+ not error out, which has been corrected.
+
+ * A few commands learned to take the pathspec from the standard input
+ or a named file, instead of taking it as the command line
+ arguments, with the "--pathspec-from-file" option.
+
+ * "git submodule" learned a subcommand "set-url".
+
+ * "git log" family learned "--pretty=reference" that gives the name
+ of a commit in the format that is often used to refer to it in log
+ messages.
+
+ * The interaction between "git clone --recurse-submodules" and
+ alternate object store was ill-designed. The documentation and
+ code have been taught to make more clear recommendations when the
+ users see failures.
+
+ * Management of sparsely checked-out working tree has gained a
+ dedicated "sparse-checkout" command.
+
+ * Miscellaneous small UX improvements on "git-p4".
+
+ * "git sparse-checkout list" subcommand learned to give its output in
+ a more concise form when the "cone" mode is in effect.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * Debugging support for lazy cloning has been a bit improved.
+
+ * Move the definition of a set of bitmask constants from 0ctal
+ literal to (1U<<count) notation.
+
+ * Test updates to prepare for SHA-2 transition continues.
+
+ * Crufty code and logic accumulated over time around the object
+ parsing and low-level object access used in "git fsck" have been
+ cleaned up.
+
+ * The implementation of "git log --graph" got refactored and then its
+ output got simplified.
+
+ * Follow recent push to move API docs from Documentation/ to header
+ files and update config.h
+
+ * "git bundle" has been taught to use the parse options API. "git
+ bundle verify" learned "--quiet" and "git bundle create" learned
+ options to control the progress output.
+
+ * Handling of commit objects that use non UTF-8 encoding during
+ "rebase -i" has been improved.
+
+ * The beginning of rewriting "git add -i" in C.
+
+ * A label used in the todo list that are generated by "git rebase
+ --rebase-merges" is used as a part of a refname; the logic to come
+ up with the label has been tightened to avoid names that cannot be
+ used as such.
+
+ * The logic to avoid duplicate label names generated by "git rebase
+ --rebase-merges" forgot that the machinery itself uses "onto" as a
+ label name, which must be avoided by auto-generated labels, which
+ has been corrected.
+
+ * We have had compatibility fallback macro definitions for "PRIuMAX",
+ "PRIu32", etc. but did not for "PRIdMAX", while the code used the
+ last one apparently without any hiccup reported recently. The
+ fallback macro definitions for these <inttypes.h> macros that must
+ appear in C99 systems have been removed.
+
+ * Recently we have declared that GIT_TEST_* variables take the
+ usual boolean values (it used to be that some used "non-empty
+ means true" and taking GIT_TEST_VAR=YesPlease as true); make
+ sure we notice and fail when non-bool strings are given to
+ these variables.
+
+ * Users of oneway_merge() (like "reset --hard") learned to take
+ advantage of fsmonitor to avoid unnecessary lstat(2) calls.
+
+ * Performance tweak on "git push" into a repository with many refs
+ that point at objects we have never heard of.
+
+ * PerfTest fix to avoid stale result mixed up with the latest round
+ of test results.
+
+ * Hide lower-level verify_signed-buffer() API as a pure helper to
+ implement the public check_signature() function, in order to
+ encourage new callers to use the correct and more strict
+ validation.
+
+ * Unnecessary reading of state variables back from the disk during
+ sequencer operation has been reduced.
+
+ * The code has been made to avoid gmtime() and localtime() and prefer
+ their reentrant counterparts.
+
+ * In a repository with many packfiles, the cost of the procedure that
+ avoids registering the same packfile twice was unnecessarily high
+ by using an inefficient search algorithm, which has been corrected.
+
+ * Redo "git name-rev" to avoid recursive calls.
+
+ * FreeBSD CI support via Cirrus-CI has been added.
+
+
+Fixes since v2.24
+-----------------
+
+ * "rebase -i" ceased to run post-commit hook by mistake in an earlier
+ update, which has been corrected.
+
+ * "git notes copy $original" ought to copy the notes attached to the
+ original object to HEAD, but a mistaken tightening to command line
+ parameter validation made earlier disabled that feature by mistake.
+
+ * When all files from some subdirectory were renamed to the root
+ directory, the directory rename heuristics would fail to detect that
+ as a rename/merge of the subdirectory to the root directory, which has
+ been corrected.
+
+ * Code clean-up and a bugfix in the logic used to tell worktree local
+ and repository global refs apart.
+ (merge f45f88b2e4 sg/dir-trie-fixes later to maint).
+
+ * "git stash save" in a working tree that is sparsely checked out
+ mistakenly removed paths that are outside the area of interest.
+ (merge 4a58c3d7f7 js/update-index-ignore-removal-for-skip-worktree later to maint).
+
+ * "git rev-parse --git-path HEAD.lock" did not give the right path
+ when run in a secondary worktree.
+ (merge 76a53d640f js/git-path-head-dot-lock-fix later to maint).
+
+ * "git merge --no-commit" needs "--no-ff" if you do not want to move
+ HEAD, which has been corrected in the manual page for "git bisect".
+ (merge 8dd327b246 ma/bisect-doc-sample-update later to maint).
+
+ * "git worktree add" internally calls "reset --hard" that should not
+ descend into submodules, even when submodule.recurse configuration
+ is set, but it was affected. This has been corrected.
+ (merge 4782cf2ab6 pb/no-recursive-reset-hard-in-worktree-add later to maint).
+
+ * Messages from die() etc. can be mixed up from multiple processes
+ without even line buffering on Windows, which has been worked
+ around.
+ (merge 116d1fa6c6 js/vreportf-wo-buffering later to maint).
+
+ * HTTP transport had possible allocator/deallocator mismatch, which
+ has been corrected.
+
+ * The watchman integration for fsmonitor was racy, which has been
+ corrected to be more conservative.
+ (merge dd0b61f577 kw/fsmonitor-watchman-fix later to maint).
+
+ * Fetching from multiple remotes into the same repository in parallel
+ had a bad interaction with the recent change to (optionally) update
+ the commit-graph after a fetch job finishes, as these parallel
+ fetches compete with each other. Which has been corrected.
+
+ * Recent update to "git stash pop" made the command empty the index
+ when run with the "--quiet" option, which has been corrected.
+
+ * "git fetch" codepath had a big "do not lazily fetch missing objects
+ when I ask if something exists" switch. This has been corrected by
+ marking the "does this thing exist?" calls with "if not please do not
+ lazily fetch it" flag.
+
+ * Test update to avoid wasted cycles.
+ (merge e0316695ec sg/skip-skipped-prereq later to maint).
+
+ * Error handling after "git push" finishes sending the packdata and
+ waits for the response to the remote side has been improved.
+ (merge ad7a403268 jk/send-pack-remote-failure later to maint).
+
+ * Some codepaths in "gitweb" that forgot to escape URLs generated
+ based on end-user input have been corrected.
+ (merge a376e37b2c jk/gitweb-anti-xss later to maint).
+
+ * CI jobs for macOS has been made less chatty when updating perforce
+ package used during testing.
+ (merge 0dbc4a0edf jc/azure-ci-osx-fix-fix later to maint).
+
+ * "git unpack-objects" used to show progress based only on the number
+ of received and unpacked objects, which stalled when it has to
+ handle an unusually large object. It now shows the throughput as
+ well.
+ (merge bae60ba7e9 sg/unpack-progress-throughput later to maint).
+
+ * The sequencer machinery compared the HEAD and the state it is
+ attempting to commit to decide if the result would be a no-op
+ commit, even when amending a commit, which was incorrect, and
+ has been corrected.
+
+ * The code to parse GPG output used to assume incorrectly that the
+ finterprint for the primary key would always be present for a valid
+ signature, which has been corrected.
+ (merge 67a6ea6300 hi/gpg-optional-pkfp-fix later to maint).
+
+ * "git submodule status" and "git submodule status --cached" show
+ different things, but the documentation did not cover them
+ correctly, which has been corrected.
+ (merge 8d483c8408 mg/doc-submodule-status-cached later to maint).
+
+ * "git reset --patch $object" without any pathspec should allow a
+ tree object to be given, but incorrectly required a committish,
+ which has been corrected.
+
+ * "git submodule status" that is run from a subdirectory of the
+ superproject did not work well, which has been corrected.
+ (merge 1f3aea22c7 mg/submodule-status-from-a-subdirectory later to maint).
+
+ * The revision walking machinery uses resources like per-object flag
+ bits that need to be reset before a new iteration of walking
+ begins, but the resources related to topological walk were not
+ cleared correctly, which has been corrected.
+ (merge 0aa0c2b2ec mh/clear-topo-walk-upon-reset later to maint).
+
+ * TravisCI update.
+ (merge 176441bfb5 sg/osx-force-gcc-9 later to maint).
+
+ * While running "revert" or "cherry-pick --edit" for multiple
+ commits, a recent regression incorrectly detected "nothing to
+ commit, working tree clean", instead of replaying the commits,
+ which has been corrected.
+ (merge befd4f6a81 sg/assume-no-todo-update-in-cherry-pick later to maint).
+
+ * Work around a issue where a FD that is left open when spawning a
+ child process and is kept open in the child can interfere with the
+ operation in the parent process on Windows.
+
+ * One kind of progress messages were always given during commit-graph
+ generation, instead of following the "if it takes more than two
+ seconds, show progress" pattern, which has been corrected.
+
+ * "git rebase" did not work well when format.useAutoBase
+ configuration variable is set, which has been corrected.
+
+ * The "diff" machinery learned not to lose added/removed blank lines
+ in the context when --ignore-blank-lines and --function-context are
+ used at the same time.
+ (merge 0bb313a552 rs/xdiff-ignore-ws-w-func-context later to maint).
+
+ * The test on "fast-import" used to get stuck when "fast-import" died
+ in the middle.
+ (merge 0d9b0d7885 sg/t9300-robustify later to maint).
+
+ * "git format-patch" can take a set of configured format.notes values
+ to specify which notes refs to use in the log message part of the
+ output. The behaviour of this was not consistent with multiple
+ --notes command line options, which has been corrected.
+ (merge e0f9095aaa dl/format-patch-notes-config-fixup later to maint).
+
+ * "git p4" used to ignore lfs.storage configuration variable, which
+ has been corrected.
+ (merge ea94b16fb8 rb/p4-lfs later to maint).
+
+ * Assorted fixes to the directory traversal API.
+ (merge 6836d2fe06 en/fill-directory-fixes later to maint).
+
+ * Forbid pathnames that the platform's filesystem cannot represent on
+ MinGW.
+ (merge 4dc42c6c18 js/mingw-reserved-filenames later to maint).
+
+ * "git rebase --signoff" stopped working when the command was written
+ in C, which has been corrected.
+ (merge 4fe7e43c53 en/rebase-signoff-fix later to maint).
+
+ * An earlier update to Git for Windows declared that a tree object is
+ invalid if it has a path component with backslash in it, which was
+ overly strict, which has been corrected. The only protection the
+ Windows users need is to prevent such path (or any path that their
+ filesystem cannot check out) from entering the index.
+ (merge 224c7d70fa js/mingw-loosen-overstrict-tree-entry-checks later to maint).
+
+ * The code to write split commit-graph file(s) upon fetching computed
+ bogus value for the parameter used in splitting the resulting
+ files, which has been corrected.
+ (merge 63020f175f ds/commit-graph-set-size-mult later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge 80736d7c5e jc/am-show-current-patch-docfix later to maint).
+ (merge 8b656572ca sg/commit-graph-usage-fix later to maint).
+ (merge 6c02042139 mr/clone-dir-exists-to-path-exists later to maint).
+ (merge 44ae131e38 sg/blame-indent-heuristics-is-now-the-default later to maint).
+ (merge 0115e5d929 dl/doc-diff-no-index-implies-exit-code later to maint).
+ (merge 270de6acbe en/t6024-style later to maint).
+ (merge 14c4776d75 ns/test-desc-typofix later to maint).
+ (merge 68d40f30c4 dj/typofix-merge-strat later to maint).
+ (merge f66e0401ab jk/optim-in-pack-idx-conversion later to maint).
+ (merge 169bed7421 rs/parse-options-dup-null-fix later to maint).
+ (merge 51bd6be32d rs/use-copy-array-in-mingw-shell-command-preparation later to maint).
+ (merge b018719927 ma/t7004 later to maint).
+ (merge 932757b0cc ar/install-doc-update-cmds-needing-the-shell later to maint).
+ (merge 46efd28be1 ep/guard-kset-tar-headers later to maint).
+ (merge 9e5afdf997 ec/fetch-mark-common-refs-trace2 later to maint).
+ (merge f0e58b3fe8 pb/submodule-update-fetches later to maint).
+ (merge 2a02262078 dl/t5520-cleanup later to maint).
+ (merge a4fb016ba1 js/pkt-line-h-typofix later to maint).
+ (merge 54a7a64613 rs/simplify-prepare-cmd later to maint).
+ (merge 3eae30e464 jk/lore-is-the-archive later to maint).
+ (merge 14b7664df8 dl/lore-is-the-archive later to maint).
+ (merge 0e40a73a4c po/bundle-doc-clonable later to maint).
+ (merge e714b898c6 as/t7812-missing-redirects-fix later to maint).
+ (merge 528d9e6d01 jk/perf-wo-git-dot-pm later to maint).
+ (merge fc42f20e24 sg/test-squelch-noise-in-commit-bulk later to maint).
+ (merge c64368e3a2 bc/t9001-zsh-in-posix-emulation-mode later to maint).
+ (merge 11de8dd7ef dr/branch-usage-casefix later to maint).
+ (merge e05e8cf074 rs/archive-zip-code-cleanup later to maint).
+ (merge 147ee35558 rs/commit-export-env-simplify later to maint).
+ (merge 4507ecc771 rs/patch-id-use-oid-to-hex later to maint).
+ (merge 51a0a4ed95 mr/bisect-use-after-free later to maint).
+ (merge cc2bd5c45d pb/submodule-doc-xref later to maint).
+ (merge df5be01669 ja/doc-markup-cleanup later to maint).
+ (merge 7c5cea7242 mr/bisect-save-pointer-to-const-string later to maint).
+ (merge 20a67e8ce9 js/use-test-tool-on-path later to maint).
+ (merge 4e61b2214d ew/packfile-syscall-optim later to maint).
+ (merge ace0f86c7f pb/clarify-line-log-doc later to maint).
+ (merge 763a59e71c en/merge-recursive-oid-eq-simplify later to maint).
+ (merge 4e2c4c0d4f do/gitweb-typofix-in-comments later to maint).
+ (merge 421c0ffb02 jb/doc-multi-pack-idx-fix later to maint).
+ (merge f8740c586b pm/am-in-body-header-doc-update later to maint).
+ (merge 5814d44d9b tm/doc-submodule-absorb-fix later to maint).
diff --git a/RelNotes/2.25.1.adoc b/RelNotes/2.25.1.adoc
new file mode 100644
index 0000000..cd869b0
--- /dev/null
+++ b/RelNotes/2.25.1.adoc
@@ -0,0 +1,55 @@
+Git 2.25.1 Release Notes
+========================
+
+Fixes since v2.25
+-----------------
+
+ * "git commit" gives output similar to "git status" when there is
+ nothing to commit, but without honoring the advise.statusHints
+ configuration variable, which has been corrected.
+
+ * has_object_file() said "no" given an object registered to the
+ system via pretend_object_file(), making it inconsistent with
+ read_object_file(), causing lazy fetch to attempt fetching an
+ empty tree from promisor remotes.
+
+ * The code that tries to skip over the entries for the paths in a
+ single directory using the cache-tree was not careful enough
+ against corrupt index file.
+
+ * Complete an update to tutorial that encourages "git switch" over
+ "git checkout" that was done only half-way.
+
+ * Reduce unnecessary round-trip when running "ls-remote" over the
+ stateless RPC mechanism.
+
+ * "git restore --staged" did not correctly update the cache-tree
+ structure, resulting in bogus trees to be written afterwards, which
+ has been corrected.
+
+ * The code recently added to move to the entry beyond the ones in the
+ same directory in the index in the sparse-cone mode did not count
+ the number of entries to skip over incorrectly, which has been
+ corrected.
+
+ * Work around test breakages caused by custom regex engine used in
+ libasan, when address sanitizer is used with more recent versions
+ of gcc and clang.
+
+ * "git fetch --refmap=" option has got a better documentation.
+
+ * Corner case bugs in "git clean" that stems from a (necessarily for
+ performance reasons) awkward calling convention in the directory
+ enumeration API has been corrected.
+
+ * "git grep --no-index" should not get affected by the contents of
+ the .gitmodules file but when "--recurse-submodules" is given or
+ the "submodule.recurse" variable is set, it did. Now these
+ settings are ignored in the "--no-index" mode.
+
+ * Technical details of the bundle format has been documented.
+
+ * Unhelpful warning messages during documentation build have been
+ squelched.
+
+Also contains various documentation updates, code clean-ups and minor fixups.
diff --git a/RelNotes/2.25.2.adoc b/RelNotes/2.25.2.adoc
new file mode 100644
index 0000000..303c53a
--- /dev/null
+++ b/RelNotes/2.25.2.adoc
@@ -0,0 +1,60 @@
+Git 2.25.2 Release Notes
+========================
+
+Fixes since v2.25.1
+-------------------
+
+ * Minor bugfixes to "git add -i" that has recently been rewritten in C.
+
+ * An earlier update to show the location of working tree in the error
+ message did not consider the possibility that a git command may be
+ run in a bare repository, which has been corrected.
+
+ * The "--recurse-submodules" option of various subcommands did not
+ work well when run in an alternate worktree, which has been
+ corrected.
+
+ * Running "git rm" on a submodule failed unnecessarily when
+ .gitmodules is only cache-dirty, which has been corrected.
+
+ * "git rebase -i" identifies existing commits in its todo file with
+ their abbreviated object name, which could become ambigous as it
+ goes to create new commits, and has a mechanism to avoid ambiguity
+ in the main part of its execution. A few other cases however were
+ not covered by the protection against ambiguity, which has been
+ corrected.
+
+ * The index-pack code now diagnoses a bad input packstream that
+ records the same object twice when it is used as delta base; the
+ code used to declare a software bug when encountering such an
+ input, but it is an input error.
+
+ * The code to automatically shrink the fan-out in the notes tree had
+ an off-by-one bug, which has been killed.
+
+ * "git check-ignore" did not work when the given path is explicitly
+ marked as not ignored with a negative entry in the .gitignore file.
+
+ * The merge-recursive machinery failed to refresh the cache entry for
+ a merge result in a couple of places, resulting in an unnecessary
+ merge failure, which has been fixed.
+
+ * Fix for a bug revealed by a recent change to make the protocol v2
+ the default.
+
+ * "git merge signed-tag" while lacking the public key started to say
+ "No signature", which was utterly wrong. This regression has been
+ reverted.
+
+ * MinGW's poll() emulation has been improved.
+
+ * "git show" and others gave an object name in raw format in its
+ error output, which has been corrected to give it in hex.
+
+ * Both "git ls-remote -h" and "git grep -h" give short usage help,
+ like any other Git subcommand, but it is not unreasonable to expect
+ that the former would behave the same as "git ls-remote --head"
+ (there is no other sensible behaviour for the latter). The
+ documentation has been updated in an attempt to clarify this.
+
+Also contains various documentation updates, code clean-ups and minor fixups.
diff --git a/RelNotes/2.25.3.adoc b/RelNotes/2.25.3.adoc
new file mode 100644
index 0000000..15f7f21
--- /dev/null
+++ b/RelNotes/2.25.3.adoc
@@ -0,0 +1,5 @@
+Git v2.25.3 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.17.4; see
+the release notes for that version for details.
diff --git a/RelNotes/2.25.4.adoc b/RelNotes/2.25.4.adoc
new file mode 100644
index 0000000..0dbb5da
--- /dev/null
+++ b/RelNotes/2.25.4.adoc
@@ -0,0 +1,5 @@
+Git v2.25.4 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.17.5; see
+the release notes for that version for details.
diff --git a/RelNotes/2.25.5.adoc b/RelNotes/2.25.5.adoc
new file mode 100644
index 0000000..fcb9566
--- /dev/null
+++ b/RelNotes/2.25.5.adoc
@@ -0,0 +1,7 @@
+Git v2.25.5 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.17.6, v2.18.5,
+v2.19.6, v2.20.5, v2.21.4, v2.22.5, v2.23.4 and v2.24.4 to address
+the security issue CVE-2021-21300; see the release notes for
+these versions for details.
diff --git a/RelNotes/2.26.0.adoc b/RelNotes/2.26.0.adoc
new file mode 100644
index 0000000..3a7a734
--- /dev/null
+++ b/RelNotes/2.26.0.adoc
@@ -0,0 +1,341 @@
+Git 2.26 Release Notes
+======================
+
+Updates since v2.25
+-------------------
+
+Backward compatibility notes
+
+ * "git rebase" uses a different backend that is based on the 'merge'
+ machinery by default. There are a few known differences in the
+ behaviour from the traditional machinery based on patch+apply.
+
+ If your workflow is negatively affected by this change, please
+ report it to git@vger.kernel.org so that we can take a look into
+ it. After doing so, you can set the 'rebase.backend' configuration
+ variable to 'apply', in order to use the old default behaviour in
+ the meantime.
+
+
+UI, Workflows & Features
+
+ * Sample credential helper for using .netrc has been updated to work
+ out of the box.
+
+ * gpg.minTrustLevel configuration variable has been introduced to
+ tell various signature verification codepaths the required minimum
+ trust level.
+
+ * The command line completion (in contrib/) learned to complete
+ subcommands and arguments to "git worktree".
+
+ * Disambiguation logic to tell revisions and pathspec apart has been
+ tweaked so that backslash-escaped glob special characters do not
+ count in the "wildcards are pathspec" rule.
+
+ * One effect of specifying where the GIT_DIR is (either with the
+ environment variable, or with the "git --git-dir=<where> cmd"
+ option) is to disable the repository discovery. This has been
+ placed a bit more stress in the documentation, as new users often
+ get confused.
+
+ * Two help messages given when "git add" notices the user gave it
+ nothing to add have been updated to use advise() API.
+
+ * A new version of fsmonitor-watchman hook has been introduced, to
+ avoid races.
+
+ * "git config" learned to show in which "scope", in addition to in
+ which file, each config setting comes from.
+
+ * The basic 7 colors learned the brighter counterparts
+ (e.g. "brightred").
+
+ * "git sparse-checkout" learned a new "add" subcommand.
+
+ * A configuration element used for credential subsystem can now use
+ wildcard pattern to specify for which set of URLs the entry
+ applies.
+
+ * "git clone --recurse-submodules --single-branch" now uses the same
+ single-branch option when cloning the submodules.
+
+ * "git rm" and "git stash" learns the new "--pathspec-from-file"
+ option.
+
+ * "git am --show-current-patch" is a way to show the piece of e-mail
+ for the stopped step, which is not suitable to directly feed "git
+ apply" (it is designed to be a good "git am" input). It learned a
+ new option to show only the patch part.
+
+ * Handling of conflicting renames in merge-recursive have further
+ been made consistent with how existing codepaths try to mimic what
+ is done to add/add conflicts.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * Tell .editorconfig that in this project, *.txt files are indented
+ with tabs.
+
+ * The test-lint machinery knew to check "VAR=VAL shell_function"
+ construct, but did not check "VAR= shell_function", which has been
+ corrected.
+
+ * Replace "git config --bool" calls with "git config --type=bool" in
+ sample templates.
+
+ * The effort to move "git-add--interactive" to C continues.
+
+ * Improve error message generation for "git submodule add".
+
+ * Preparation of test scripts for the day when the object names will
+ use SHA-256 continues.
+
+ * Warn programmers about pretend_object_file() that allows the code
+ to tentatively use in-core objects.
+
+ * The way "git pack-objects" reuses objects stored in existing pack
+ to generate its result has been improved.
+
+ * The transport protocol version 2 becomes the default one.
+
+ * Traditionally, we avoided threaded grep while searching in objects
+ (as opposed to files in the working tree) as accesses to the object
+ layer is not thread-safe. This limitation is getting lifted.
+
+ * "git rebase -i" (and friends) used to unnecessarily check out the
+ tip of the branch to be rebased, which has been corrected.
+
+ * A low-level API function get_oid(), that accepts various ways to
+ name an object, used to issue end-user facing error messages
+ without l10n, which has been updated to be translatable.
+
+ * Unneeded connectivity check is now disabled in a partial clone when
+ fetching into it.
+
+ * Some rough edges in the sparse-checkout feature, especially around
+ the cone mode, have been cleaned up.
+
+ * The diff-* plumbing family of subcommands now pay attention to the
+ diff.wsErrorHighlight configuration, which has been ignored before;
+ this allows "git add -p" to also show the whitespace problems to
+ the end user.
+
+ * Some codepaths were given a repository instance as a parameter to
+ work in the repository, but passed the_repository instance to its
+ callees, which has been cleaned up (somewhat).
+
+ * Memory footprint and performance of "git name-rev" has been
+ improved.
+
+ * The object reachability bitmap machinery and the partial cloning
+ machinery were not prepared to work well together, because some
+ object-filtering criteria that partial clones use inherently rely
+ on object traversal, but the bitmap machinery is an optimization
+ to bypass that object traversal. There however are some cases
+ where they can work together, and they were taught about them.
+
+ * "git rebase" has learned to use the merge backend (i.e. the
+ machinery that drives "rebase -i") by default, while allowing
+ "--apply" option to use the "apply" backend (e.g. the moral
+ equivalent of "format-patch piped to am"). The rebase.backend
+ configuration variable can be set to customize.
+
+ * Underlying machinery of "git bisect--helper" is being refactored
+ into pieces that are more easily reused.
+
+
+Fixes since v2.25
+-----------------
+
+ * "git commit" gives output similar to "git status" when there is
+ nothing to commit, but without honoring the advise.statusHints
+ configuration variable, which has been corrected.
+
+ * has_object_file() said "no" given an object registered to the
+ system via pretend_object_file(), making it inconsistent with
+ read_object_file(), causing lazy fetch to attempt fetching an
+ empty tree from promisor remotes.
+
+ * Complete an update to tutorial that encourages "git switch" over
+ "git checkout" that was done only half-way.
+
+ * C pedantry ;-) fix.
+
+ * The code that tries to skip over the entries for the paths in a
+ single directory using the cache-tree was not careful enough
+ against corrupt index file.
+
+ * Reduce unnecessary round-trip when running "ls-remote" over the
+ stateless RPC mechanism.
+
+ * "git restore --staged" did not correctly update the cache-tree
+ structure, resulting in bogus trees to be written afterwards, which
+ has been corrected.
+
+ * The code recently added to move to the entry beyond the ones in the
+ same directory in the index in the sparse-cone mode did not count
+ the number of entries to skip over incorrectly, which has been
+ corrected.
+
+ * Rendering by "git log --graph" of ancestry lines leading to a merge
+ commit were made suboptimal to waste vertical space a bit with a
+ recent update, which has been corrected.
+
+ * Work around test breakages caused by custom regex engine used in
+ libasan, when address sanitizer is used with more recent versions
+ of gcc and clang.
+
+ * Minor bugfixes to "git add -i" that has recently been rewritten in C.
+
+ * "git fetch --refmap=" option has got a better documentation.
+
+ * "git checkout X" did not correctly fail when X is not a local
+ branch but could name more than one remote-tracking branches
+ (i.e. to be dwimmed as the starting point to create a corresponding
+ local branch), which has been corrected.
+ (merge fa74180d08 am/checkout-file-and-ref-ref-ambiguity later to maint).
+
+ * Corner case bugs in "git clean" that stems from a (necessarily for
+ performance reasons) awkward calling convention in the directory
+ enumeration API has been corrected.
+
+ * A fetch that is told to recursively fetch updates in submodules
+ inevitably produces reams of output, and it becomes hard to spot
+ error messages. The command has been taught to enumerate
+ submodules that had errors at the end of the operation.
+ (merge 0222540827 es/fetch-show-failed-submodules-atend later to maint).
+
+ * The "--recurse-submodules" option of various subcommands did not
+ work well when run in an alternate worktree, which has been
+ corrected.
+
+ * Futureproofing a test not to depend on the current implementation
+ detail.
+
+ * Running "git rm" on a submodule failed unnecessarily when
+ .gitmodules is only cache-dirty, which has been corrected.
+
+ * C pedantry ;-) fix.
+
+ * "git grep --no-index" should not get affected by the contents of
+ the .gitmodules file but when "--recurse-submodules" is given or
+ the "submodule.recurse" variable is set, it did. Now these
+ settings are ignored in the "--no-index" mode.
+
+ * Technical details of the bundle format has been documented.
+
+ * Unhelpful warning messages during documentation build have been squelched.
+
+ * "git rebase -i" identifies existing commits in its todo file with
+ their abbreviated object name, which could become ambiguous as it
+ goes to create new commits, and has a mechanism to avoid ambiguity
+ in the main part of its execution. A few other cases however were
+ not covered by the protection against ambiguity, which has been
+ corrected.
+
+ * Allow the rebase.missingCommitsCheck configuration to kick in when
+ "rebase --edit-todo" and "rebase --continue" restarts the procedure.
+ (merge 5a5445d878 ag/edit-todo-drop-check later to maint).
+
+ * The way "git submodule status" reports an initialized but not yet
+ populated submodule has not been reimplemented correctly when a
+ part of the "git submodule" command was rewritten in C, which has
+ been corrected.
+ (merge f38c92452d pk/status-of-uncloned-submodule later to maint).
+
+ * The code to automatically shrink the fan-out in the notes tree had
+ an off-by-one bug, which has been killed.
+
+ * The index-pack code now diagnoses a bad input packstream that
+ records the same object twice when it is used as delta base; the
+ code used to declare a software bug when encountering such an
+ input, but it is an input error.
+
+
+ * The code to compute the commit-graph has been taught to use a more
+ robust way to tell if two object directories refer to the same
+ thing.
+ (merge a7df60cac8 tb/commit-graph-object-dir later to maint).
+
+ * "git remote rename X Y" needs to adjust configuration variables
+ (e.g. branch.<name>.remote) whose value used to be X to Y.
+ branch.<name>.pushRemote is now also updated.
+
+ * Update to doc-diff.
+
+ * Doc markup fix.
+
+ * "git check-ignore" did not work when the given path is explicitly
+ marked as not ignored with a negative entry in the .gitignore file.
+
+ * The merge-recursive machinery failed to refresh the cache entry for
+ a merge result in a couple of places, resulting in an unnecessary
+ merge failure, which has been fixed.
+
+ * Fix for a bug revealed by a recent change to make the protocol v2
+ the default.
+
+ * In rare cases "git worktree add <path>" could think that <path>
+ was already a registered worktree even when it wasn't and refuse
+ to add the new worktree. This has been corrected.
+ (merge bb69b3b009 es/worktree-avoid-duplication-fix later to maint).
+
+ * "git push" should stop from updating a branch that is checked out
+ when receive.denyCurrentBranch configuration is set, but it failed
+ to pay attention to checkouts in secondary worktrees. This has
+ been corrected.
+ (merge 4d864895a2 hv/receive-denycurrent-everywhere later to maint).
+
+ * "git rebase BASE BRANCH" rebased/updated the tip of BRANCH and
+ checked it out, even when the BRANCH is checked out in a different
+ worktree. This has been corrected.
+ (merge b5cabb4a96 es/do-not-let-rebase-switch-to-protected-branch later to maint).
+
+ * "git describe" in a repository with multiple root commits sometimes
+ gave up looking for the best tag to describe a given commit with
+ too early, which has been adjusted.
+
+ * "git merge signed-tag" while lacking the public key started to say
+ "No signature", which was utterly wrong. This regression has been
+ reverted.
+
+ * MinGW's poll() emulation has been improved.
+
+ * "git show" and others gave an object name in raw format in its
+ error output, which has been corrected to give it in hex.
+
+ * "git fetch" over HTTP walker protocol did not show any progress
+ output. We inherently do not know how much work remains, but still
+ we can show something not to bore users.
+ (merge 7655b4119d rs/show-progress-in-dumb-http-fetch later to maint).
+
+ * Both "git ls-remote -h" and "git grep -h" give short usage help,
+ like any other Git subcommand, but it is not unreasonable to expect
+ that the former would behave the same as "git ls-remote --head"
+ (there is no other sensible behaviour for the latter). The
+ documentation has been updated in an attempt to clarify this.
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge d0d0a357a1 am/update-pathspec-f-f-tests later to maint).
+ (merge f94f7bd00d am/test-pathspec-f-f-error-cases later to maint).
+ (merge c513a958b6 ss/t6025-modernize later to maint).
+ (merge b441717256 dl/test-must-fail-fixes later to maint).
+ (merge d031049da3 mt/sparse-checkout-doc-update later to maint).
+ (merge 145136a95a jc/skip-prefix later to maint).
+ (merge 5290d45134 jk/alloc-cleanups later to maint).
+ (merge 7a9f8ca805 rs/parse-options-concat-dup later to maint).
+ (merge 517b60564e rs/strbuf-insertstr later to maint).
+ (merge f696a2b1c8 jk/mailinfo-cleanup later to maint).
+ (merge de26f02db1 js/test-avoid-pipe later to maint).
+ (merge a2dc43414c es/doc-mentoring later to maint).
+ (merge 02bbbe9df9 es/worktree-cleanup later to maint).
+ (merge 2ce6d075fa rs/micro-cleanups later to maint).
+ (merge 27f182b3fc rs/blame-typefix-for-fingerprint later to maint).
+ (merge 3c29e21eb0 ma/test-cleanup later to maint).
+ (merge 240fc04f81 ag/rebase-remove-redundant-code later to maint).
+ (merge d68ce906c7 rs/commit-graph-code-simplification later to maint).
+ (merge a51d9e8f07 rj/t1050-use-test-path-is-file later to maint).
+ (merge fd0bc17557 kk/complete-diff-color-moved later to maint).
+ (merge 65bf820d0e en/test-cleanup later to maint).
diff --git a/RelNotes/2.26.1.adoc b/RelNotes/2.26.1.adoc
new file mode 100644
index 0000000..1b4ecb3
--- /dev/null
+++ b/RelNotes/2.26.1.adoc
@@ -0,0 +1,5 @@
+Git v2.26.1 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.17.4; see
+the release notes for that version for details.
diff --git a/RelNotes/2.26.2.adoc b/RelNotes/2.26.2.adoc
new file mode 100644
index 0000000..d434d0c
--- /dev/null
+++ b/RelNotes/2.26.2.adoc
@@ -0,0 +1,5 @@
+Git v2.26.2 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.17.5; see
+the release notes for that version for details.
diff --git a/RelNotes/2.26.3.adoc b/RelNotes/2.26.3.adoc
new file mode 100644
index 0000000..4111c38
--- /dev/null
+++ b/RelNotes/2.26.3.adoc
@@ -0,0 +1,7 @@
+Git v2.26.3 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.17.6, v2.18.5,
+v2.19.6, v2.20.5, v2.21.4, v2.22.5, v2.23.4, v2.24.4 and v2.25.5
+to address the security issue CVE-2021-21300; see the release
+notes for these versions for details.
diff --git a/RelNotes/2.27.0.adoc b/RelNotes/2.27.0.adoc
new file mode 100644
index 0000000..15518d0
--- /dev/null
+++ b/RelNotes/2.27.0.adoc
@@ -0,0 +1,525 @@
+Git 2.27 Release Notes
+======================
+
+Updates since v2.26
+-------------------
+
+Backward compatibility notes
+
+ * When "git describe C" finds that commit C is pointed by a signed or
+ annotated tag, which records T as its tagname in the object, the
+ command gives T as its answer. Even if the user renames or moves
+ such a tag from its natural location in the "refs/tags/" hierarchy,
+ "git describe C" would still give T as the answer, but in such a
+ case "git show T^0" would no longer work as expected. There may be
+ nothing at "refs/tags/T" or even worse there may be a different tag
+ instead.
+
+ Starting from this version, "git describe" will always use the
+ "long" version, as if the "--long" option were given, when giving
+ its output based on such a misplaced tag to work around the problem.
+
+ * "git pull" issues a warning message until the pull.rebase
+ configuration variable is explicitly given, which some existing
+ users may find annoying---those who prefer not to rebase need to
+ set the variable to false to squelch the warning.
+
+ * The transport protocol version 2, which was promoted to the default
+ in Git 2.26 release, turned out to have some remaining rough edges,
+ so it has been demoted from the default.
+
+
+UI, Workflows & Features
+
+ * A handful of options to configure SSL when talking to proxies have
+ been added.
+
+ * Smudge/clean conversion filters are now given more information
+ (e.g. the object of the tree-ish in which the blob being converted
+ appears, in addition to its path, which has already been given).
+
+ * When "git describe C" finds an annotated tag with tagname A to be
+ the best name to explain commit C, and the tag is stored in a
+ "wrong" place in the refs/tags hierarchy, e.g. refs/tags/B, the
+ command gave a warning message but used A (not B) to describe C.
+ If C is exactly at the tag, the describe output would be "A", but
+ "git rev-parse A^0" would not be equal as "git rev-parse C^0". The
+ behavior of the command has been changed to use the "long" form
+ i.e. A-0-gOBJECTNAME, which is correctly interpreted by rev-parse.
+
+ * "git pull" learned to warn when no pull.rebase configuration
+ exists, and neither --[no-]rebase nor --ff-only is given (which
+ would result a merge).
+
+ * "git p4" learned four new hooks and also "--no-verify" option to
+ bypass them (and the existing "p4-pre-submit" hook).
+
+ * "git pull" shares many options with underlying "git fetch", but
+ some of them were not documented and some of those that would make
+ sense to pass down were not passed down.
+
+ * "git rebase" learned the "--no-gpg-sign" option to countermand
+ commit.gpgSign the user may have.
+
+ * The output from "git format-patch" uses RFC 2047 encoding for
+ non-ASCII letters on From: and Subject: headers, so that it can
+ directly be fed to e-mail programs. A new option has been added
+ to produce these headers in raw.
+
+ * "git log" learned "--show-pulls" that helps pathspec limited
+ history views; a merge commit that takes the whole change from a
+ side branch, which is normally omitted from the output, is shown
+ in addition to the commits that introduce real changes.
+
+ * The interactive input from various codepaths are consolidated and
+ any prompt possibly issued earlier are fflush()ed before we read.
+
+ * Allow "git rebase" to reapply all local commits, even if the may be
+ already in the upstream, without checking first.
+
+ * The 'pack.useSparse' configuration variable now defaults to 'true',
+ enabling an optimization that has been experimental since Git 2.21.
+
+ * "git rebase" happens to call some hooks meant for "checkout" and
+ "commit" by this was not a designed behaviour than historical
+ accident. This has been documented.
+
+ * "git merge" learns the "--autostash" option.
+
+ * "sparse-checkout" UI improvements.
+
+ * "git update-ref --stdin" learned a handful of new verbs to let the
+ user control ref update transactions more explicitly, which helps
+ as an ingredient to implement two-phase commit-style atomic
+ ref-updates across multiple repositories.
+
+ * "git commit-graph write" learned different ways to write out split
+ files.
+
+ * Introduce an extension to the commit-graph to make it efficient to
+ check for the paths that were modified at each commit using Bloom
+ filters.
+
+ * The approxidate parser learns to parse seconds with fraction and
+ ignore fractional part.
+
+ * The userdiff patterns for Markdown documents have been added.
+
+ * The sparse-checkout patterns have been forbidden from excluding all
+ paths, leaving an empty working tree, for a long time. This
+ limitation has been lifted.
+
+ * "git restore --staged --worktree" now defaults to take the contents
+ out of "HEAD", instead of erring out.
+
+ * "git p4" learned to recover from a (broken) state where a directory
+ and a file are recorded at the same path in the Perforce repository
+ the same way as their clients do.
+
+ * "git multi-pack-index repack" has been taught to honor some
+ repack.* configuration variables.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * The advise API has been revamped to allow more systematic enumeration of
+ advice knobs in the future.
+
+ * SHA-256 transition continues.
+
+ * The code to interface with GnuPG has been refactored.
+
+ * "git stash" has kept an escape hatch to use the scripted version
+ for a few releases, which got stale. It has been removed.
+
+ * Enable tests that require GnuPG on Windows.
+
+ * Minor test usability improvement.
+
+ * Trace2 enhancement to allow logging of the environment variables.
+
+ * Test clean-up continues.
+
+ * Perf-test update.
+
+ * A Windows-specific test element has been made more robust against
+ misuse from both user's environment and programmer's errors.
+
+ * Various tests have been updated to work around issues found with
+ shell utilities that come with busybox etc.
+
+ * The config API made mixed uses of int and size_t types to represent
+ length of various pieces of text it parsed, which has been updated
+ to use the correct type (i.e. size_t) throughout.
+
+ * The "--decorate-refs" and "--decorate-refs-exclude" options "git
+ log" takes have learned a companion configuration variable
+ log.excludeDecoration that sits at the lowest priority in the
+ family.
+
+ * A new CI job to build and run test suite on linux with musl libc
+ has been added.
+
+ * Update the CI configuration to use GitHub Actions, retiring the one
+ based on Azure Pipelines.
+
+ * The directory traversal code had redundant recursive calls which
+ made its performance characteristics exponential with respect to
+ the depth of the tree, which was corrected.
+
+ * "git blame" learns to take advantage of the "changed-paths" Bloom
+ filter stored in the commit-graph file.
+
+ * The "bugreport" tool has been added.
+
+ * The object walk with object filter "--filter=tree:0" can now take
+ advantage of the pack bitmap when available.
+
+ * Instead of always building all branches at GitHub via Actions,
+ users can specify which branches to build.
+
+ * Codepaths that show progress meter have been taught to also use the
+ start_progress() and the stop_progress() calls as a "region" to be
+ traced.
+
+ * Instead of downloading Windows SDK for CI jobs for windows builds
+ from an external site (wingit.blob.core.windows.net), use the one
+ created in the windows-build job, to work around quota issues at
+ the external site.
+
+
+Fixes since v2.26
+-----------------
+
+ * The real_path() convenience function can easily be misused; with a
+ bit of code refactoring in the callers' side, its use has been
+ eliminated.
+ (merge 49d3c4b481 am/real-path-fix later to maint).
+
+ * Update "git p4" to work with Python 3.
+ (merge 6bb40ed20a yz/p4-py3 later to maint).
+
+ * The mechanism to prevent "git commit" from making an empty commit
+ or amending during an interrupted cherry-pick was broken during the
+ rewrite of "git rebase" in C, which has been corrected.
+ (merge 430b75f720 pw/advise-rebase-skip later to maint).
+
+ * Fix "git checkout --recurse-submodules" of a nested submodule
+ hierarchy.
+ (merge 846f34d351 pb/recurse-submodules-fix later to maint).
+
+ * The "--fork-point" mode of "git rebase" regressed when the command
+ was rewritten in C back in 2.20 era, which has been corrected.
+ (merge f08132f889 at/rebase-fork-point-regression-fix later to maint).
+
+ * The import-tars importer (in contrib/fast-import/) used to create
+ phony files at the top-level of the repository when the archive
+ contains global PAX headers, which made its own logic to detect and
+ omit the common leading directory ineffective, which has been
+ corrected.
+ (merge c839fcff65 js/import-tars-do-not-make-phony-files-from-pax-headers later to maint).
+
+ * Simplify the commit ancestry connectedness check in a partial clone
+ repository in which "promised" objects are assumed to be obtainable
+ lazily on-demand from promisor remote repositories.
+ (merge 2b98478c6f jt/connectivity-check-optim-in-partial-clone later to maint).
+
+ * The server-end of the v2 protocol to serve "git clone" and "git
+ fetch" was not prepared to see a delim packets at unexpected
+ places, which led to a crash.
+ (merge cacae4329f jk/harden-protocol-v2-delim-handling later to maint).
+
+ * When fed a midx that records no objects, some codepaths tried to
+ loop from 0 through (num_objects-1), which, due to integer
+ arithmetic wrapping around, made it nonsense operation with out of
+ bounds array accesses. The code has been corrected to reject such
+ an midx file.
+ (merge 796d61cdc0 dr/midx-avoid-int-underflow later to maint).
+
+ * Utitiles run via the run_command() API were not spawned correctly
+ on Cygwin, when the paths to them are given as a full path with
+ backslashes.
+ (merge 05ac8582bc ak/run-command-on-cygwin-fix later to maint).
+
+ * "git pull --rebase" tried to run a rebase even after noticing that
+ the pull results in a fast-forward and no rebase is needed nor
+ sensible, for the past few years due to a mistake nobody noticed.
+ (merge fbae70ddc6 en/pull-do-not-rebase-after-fast-forwarding later to maint).
+
+ * "git rebase" with the merge backend did not work well when the
+ rebase.abbreviateCommands configuration was set.
+ (merge de9f1d3ef4 ag/rebase-merge-allow-ff-under-abbrev-command later to maint).
+
+ * The logic to auto-follow tags by "git clone --single-branch" was
+ not careful to avoid lazy-fetching unnecessary tags, which has been
+ corrected.
+ (merge 167a575e2d jk/use-quick-lookup-in-clone-for-tag-following later to maint).
+
+ * "git rebase -i" did not leave the reflog entries correctly.
+ (merge 1f6965f994 en/sequencer-reflog-action later to maint).
+
+ * The more aggressive updates to remote-tracking branches we had for
+ the past 7 years or so were not reflected in the documentation,
+ which has been corrected.
+ (merge a44088435c pb/pull-fetch-doc later to maint).
+
+ * We've left the command line parsing of "git log :/a/b/" broken for
+ about a full year without anybody noticing, which has been
+ corrected.
+ (merge 0220461071 jc/missing-ref-store-fix later to maint).
+
+ * Misc fixes for Windows.
+ (merge 3efc128cd5 js/mingw-fixes later to maint).
+
+ * "git rebase" (again) learns to honor "--no-keep-empty", which lets
+ the user to discard commits that are empty from the beginning (as
+ opposed to the ones that become empty because of rebasing). The
+ interactive rebase also marks commits that are empty in the todo.
+ (merge 50ed76148a en/rebase-no-keep-empty later to maint).
+
+ * Parsing the host part out of URL for the credential helper has been corrected.
+ (merge 4c5971e18a jk/credential-parsing-end-of-host-in-URL later to maint).
+
+ * Document the recommended way to abort a failing test early (e.g. by
+ exiting a loop), which is to say "return 1".
+ (merge 7cc112dc95 jc/doc-test-leaving-early later to maint).
+
+ * The code that refreshes the last access and modified time of
+ on-disk packfiles and loose object files have been updated.
+ (merge 312cd76130 lr/freshen-file-fix later to maint).
+
+ * Validation of push certificate has been made more robust against
+ timing attacks.
+ (merge 719483e547 bc/constant-memequal later to maint).
+
+ * The custom hash function used by "git fast-import" has been
+ replaced with the one from hashmap.c, which gave us a nice
+ performance boost.
+ (merge d8410a816b jk/fast-import-use-hashmap later to maint).
+
+ * The "git submodule" command did not initialize a few variables it
+ internally uses and was affected by variable settings leaked from
+ the environment.
+ (merge 65d100c4dd lx/submodule-clear-variables later to maint).
+
+ * Raise the minimum required version of docbook-xsl package to 1.74,
+ as 1.74.0 was from late 2008, which is more than 10 years old, and
+ drop compatibility cruft from our documentation suite.
+ (merge 3c255ad660 ma/doc-discard-docbook-xsl-1.73 later to maint).
+
+ * "git log" learns "--[no-]mailmap" as a synonym to "--[no-]use-mailmap"
+ (merge 88acccda38 jc/log-no-mailmap later to maint).
+
+ * "git commit-graph write --expire-time=<timestamp>" did not use the
+ given timestamp correctly, which has been corrected.
+ (merge b09b785c78 ds/commit-graph-expiry-fix later to maint).
+
+ * Tests update to use "test-chmtime" instead of "touch -t".
+ (merge e892a56845 ds/t5319-touch-fix later to maint).
+
+ * "git diff" in a partial clone learned to avoid lazy loading blob
+ objects in more casese when they are not needed.
+ (merge 95acf11a3d jt/avoid-prefetch-when-able-in-diff later to maint).
+
+ * "git push --atomic" used to show failures for refs that weren't
+ even pushed, which has been corrected.
+ (merge dfe1b7f19c jx/atomic-push later to maint).
+
+ * Code in builtin/*, i.e. those can only be called from within
+ built-in subcommands, that implements bulk of a couple of
+ subcommands have been moved to libgit.a so that they could be used
+ by others.
+ (merge 9460fd48b5 dl/libify-a-few later to maint).
+
+ * Allowing the user to split a patch hunk while "git stash -p" does
+ not work well; a band-aid has been added to make this (partially)
+ work better.
+
+ * "git diff-tree --pretty --notes" used to hit an assertion failure,
+ as it forgot to initialize the notes subsystem.
+ (merge 5778b22b3d tb/diff-tree-with-notes later to maint).
+
+ * "git range-diff" fixes.
+ (merge 8d1675eb7f vd/range-diff-with-custom-pretty-format-fix later to maint).
+
+ * "git grep" did not quote a path with unusual character like other
+ commands (like "git diff", "git status") do, but did quote when run
+ from a subdirectory, both of which has been corrected.
+ (merge 45115d8490 mt/grep-cquote-path later to maint).
+
+ * GNU/Hurd is also among the ones that need the fopen() wrapper.
+ (merge 274a1328fb jc/gnu-hurd-lets-fread-read-dirs later to maint).
+
+ * Those fetching over protocol v2 from linux-next and other kernel
+ repositories are reporting that v2 often fetches way too much than
+ needed.
+ (merge 11c7f2a30b jn/demote-proto2-from-default later to maint).
+
+ * The upload-pack protocol v2 gave up too early before finding a
+ common ancestor, resulting in a wasteful fetch from a fork of a
+ project. This has been corrected to match the behaviour of v0
+ protocol.
+ (merge 2f0a093dd6 jt/v2-fetch-nego-fix later to maint).
+
+ * The build procedure did not use the libcurl library and its include
+ files correctly for a custom-built installation.
+ (merge 0573831950 jk/build-with-right-curl later to maint).
+
+ * Tighten "git mailinfo" to notice and error out when decoded result
+ contains NUL in it.
+ (merge 3919997447 dd/mailinfo-with-nul later to maint).
+
+ * Fix in-core inconsistency after fetching into a shallow repository
+ that broke the code to write out commit-graph.
+ (merge 37b9dcabfc tb/reset-shallow later to maint).
+
+ * The commit-graph code exhausted file descriptors easily when it
+ does not have to.
+ (merge c8828530b7 tb/commit-graph-fd-exhaustion-fix later to maint).
+
+ * The multi-pack-index left mmapped file descriptors open when it
+ does not have to.
+ (merge 6c7ff7cf7f ds/multi-pack-index later to maint).
+
+ * Recent update to Homebrew used by macOS folks breaks build by
+ moving gettext library and necessary headers.
+ (merge a0b3108618 ds/build-homebrew-gettext-fix later to maint).
+
+ * Incompatible options "--root" and "--fork-point" of "git rebase"
+ have been marked and documented as being incompatible.
+ (merge a35413c378 en/rebase-root-and-fork-point-are-incompatible later to maint).
+
+ * Error and verbose trace messages from "git push" did not redact
+ credential material embedded in URLs.
+ (merge d192fa5006 js/anonymise-push-url-in-errors later to maint).
+
+ * Update the parser used for credential.<URL>.<variable>
+ configuration, to handle <URL>s with '/' in them correctly.
+ (merge b44d0118ac bc/wildcard-credential later to maint).
+
+ * Recent updates broke parsing of "credential.<url>.<key>" where
+ <url> is not a full URL (e.g. [credential "https://"] helper = ...)
+ stopped working, which has been corrected.
+ (merge 9a121b0d22 js/partial-urlmatch-2.17 later to maint).
+ (merge cd93e6c029 js/partial-urlmatch later to maint).
+
+ * Some of the files commit-graph subsystem keeps on disk did not
+ correctly honor the core.sharedRepository settings and some were
+ left read-write.
+
+ * In error messages that "git switch" mentions its option to create a
+ new branch, "-b/-B" options were shown, where "-c/-C" options
+ should be, which has been corrected.
+ (merge 7c16ef7577 dl/switch-c-option-in-error-message later to maint).
+
+ * With the recent tightening of the code that is used to parse
+ various parts of a URL for use in the credential subsystem, a
+ hand-edited credential-store file causes the credential helper to
+ die, which is a bit too harsh to the users. Demote the error
+ behaviour to just ignore and keep using well-formed lines instead.
+ (merge c03859a665 cb/credential-store-ignore-bogus-lines later to maint).
+
+ * The samples in the credential documentation has been updated to
+ make it clear that we depict what would appear in the .git/config
+ file, by adding appropriate quotes as needed..
+ (merge 177681a07e jk/credential-sample-update later to maint).
+
+ * "git branch" and other "for-each-ref" variants accepted multiple
+ --sort=<key> options in the increasing order of precedence, but it
+ had a few breakages around "--ignore-case" handling, and tie-breaking
+ with the refname, which have been fixed.
+ (merge 7c5045fc18 jk/for-each-ref-multi-key-sort-fix later to maint).
+
+ * The coding guideline for shell scripts instructed to refer to a
+ variable with dollar-sign inside arithmetic expansion to work
+ around a bug in old versions of dash, which is a thing of the past.
+ Now we are not forbidden from writing $((var+1)).
+ (merge 32b5fe7f0e jk/arith-expansion-coding-guidelines later to maint).
+
+ * The <stdlib.h> header on NetBSD brings in its own definition of
+ hmac() function (eek), which conflicts with our own and unrelated
+ function with the same name. Our function has been renamed to work
+ around the issue.
+ (merge 3013118eb8 cb/avoid-colliding-with-netbsd-hmac later to maint).
+
+ * The basic test did not honor $TEST_SHELL_PATH setting, which has
+ been corrected.
+ (merge 0555e4af58 cb/t0000-use-the-configured-shell later to maint).
+
+ * Minor in-code comments and documentation updates around credential
+ API.
+ (merge 1aed817f99 cb/credential-doc-fixes later to maint).
+
+ * Teach "am", "commit", "merge" and "rebase", when they are run with
+ the "--quiet" option, to pass "--quiet" down to "gc --auto".
+ (merge 7c3e9e8cfb jc/auto-gc-quiet later to maint).
+
+ * The code to skip unmerged paths in the index when sparse checkout
+ is in use would have made out-of-bound access of the in-core index
+ when the last path was unmerged, which has been corrected.
+
+ * Serving a "git fetch" client over "git://" and "ssh://" protocols
+ using the on-wire protocol version 2 was buggy on the server end
+ when the client needs to make a follow-up request to
+ e.g. auto-follow tags.
+ (merge 08450ef791 cc/upload-pack-v2-fetch-fix later to maint).
+
+ * "git bisect replay" had trouble with input files when they used
+ CRLF line ending, which has been corrected.
+ (merge 6c722cbe5a cw/bisect-replay-with-dos later to maint).
+
+ * "rebase -i" segfaulted when rearranging a sequence that has a
+ fix-up that applies another fix-up (which may or may not be a
+ fix-up of yet another step).
+ (merge 02471e7e20 js/rebase-autosquash-double-fixup-fix later to maint).
+
+ * "git fsck" ensures that the paths recorded in tree objects are
+ sorted and without duplicates, but it failed to notice a case where
+ a blob is followed by entries that sort before a tree with the same
+ name. This has been corrected.
+ (merge 9068cfb20f rs/fsck-duplicate-names-in-trees later to maint).
+
+ * Code clean-up by removing a compatibility implementation of a
+ function we no longer use.
+ (merge 84b0115f0d cb/no-more-gmtime later to maint).
+
+ * When a binary file gets modified and renamed on both sides of history
+ to different locations, both files would be written to the working
+ tree but both would have the contents from "ours". This has been
+ corrected so that the path from each side gets their original content.
+
+ * Fix for a copy-and-paste error introduced during 2.20 era.
+ (merge e68a5272b1 ds/multi-pack-verify later to maint).
+
+ * Update an unconditional use of "grep -a" with a perl script in a test.
+ (merge 1eb7371236 dd/t5703-grep-a-fix later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge 564956f358 jc/maintain-doc later to maint).
+ (merge 7422b2a0a1 sg/commit-slab-clarify-peek later to maint).
+ (merge 9c688735f6 rs/doc-passthru-fetch-options later to maint).
+ (merge 757c2ba3e2 en/oidset-uninclude-hashmap later to maint).
+ (merge 8312aa7d74 jc/config-tar later to maint).
+ (merge d00a5bdd50 ss/submodule-foreach-cb later to maint).
+ (merge 64d1022e14 ar/test-style-fixes later to maint).
+ (merge 4a465443a6 ds/doc-clone-filter later to maint).
+ (merge bb2dbe301b jk/t3419-drop-expensive-tests later to maint).
+ (merge d3507cc712 js/test-junit-finalization-fix later to maint).
+ (merge 2149b6748f bc/faq later to maint).
+ (merge 12dc0879f1 jk/test-cleanup later to maint).
+ (merge 344420bf0f pb/rebase-doc-typofix later to maint).
+ (merge 7cd54d37dc dl/wrapper-fix-indentation later to maint).
+ (merge 78725ebda9 jc/allow-strlen-substitution-in-shell-scripts later to maint).
+ (merge 2ecfcdecc6 jm/gitweb-fastcgi-utf8 later to maint).
+ (merge 0740d0a5d3 jk/oid-array-cleanups later to maint).
+ (merge a1aba0c95c js/t0007-typofix later to maint).
+ (merge 76ba7fa225 ma/config-doc-fix later to maint).
+ (merge 826f0c0df2 js/subtree-doc-update-to-asciidoctor-2 later to maint).
+ (merge 88eaf361e0 eb/mboxrd-doc later to maint).
+ (merge 051cc54941 tm/zsh-complete-switch-restore later to maint).
+ (merge 39102cf4fe ms/doc-revision-illustration-fix later to maint).
+ (merge 4d9378bfad eb/gitweb-more-trailers later to maint).
+ (merge bdccbf7047 mt/doc-worktree-ref later to maint).
+ (merge ce9baf234f dl/push-recurse-submodules-fix later to maint).
+ (merge 4153274052 bc/doc-credential-helper-value later to maint).
+ (merge 5c7bb0146e jc/codingstyle-compare-with-null later to maint).
diff --git a/RelNotes/2.27.1.adoc b/RelNotes/2.27.1.adoc
new file mode 100644
index 0000000..a1e08a9
--- /dev/null
+++ b/RelNotes/2.27.1.adoc
@@ -0,0 +1,7 @@
+Git v2.27.1 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.17.6, v2.18.5,
+v2.19.6, v2.20.5, v2.21.4, v2.22.5, v2.23.4, v2.24.4, v2.25.5
+and v2.26.3 to address the security issue CVE-2021-21300; see
+the release notes for these versions for details.
diff --git a/RelNotes/2.28.0.adoc b/RelNotes/2.28.0.adoc
new file mode 100644
index 0000000..6baf781
--- /dev/null
+++ b/RelNotes/2.28.0.adoc
@@ -0,0 +1,236 @@
+Git 2.28 Release Notes
+======================
+
+Updates since v2.27
+-------------------
+
+Backward compatibility notes
+
+ * "fetch.writeCommitGraph" is deemed to be still a bit too risky and
+ is no longer part of the "feature.experimental" set.
+
+
+UI, Workflows & Features
+
+ * The commands in the "diff" family learned to honor "diff.relative"
+ configuration variable.
+
+ * The check in "git fsck" to ensure that the tree objects are sorted
+ still had corner cases it missed unsorted entries.
+
+ * The interface to redact sensitive information in the trace output
+ has been simplified.
+
+ * The command line completion (in contrib/) learned to complete
+ options that the "git switch" command takes.
+
+ * "git diff" used to take arguments in random and nonsense range
+ notation, e.g. "git diff A..B C", "git diff A..B C...D", etc.,
+ which has been cleaned up.
+
+ * "git diff-files" has been taught to say paths that are marked as
+ intent-to-add are new files, not modified from an empty blob.
+
+ * "git status" learned to report the status of sparse checkout.
+
+ * "git difftool" has trouble dealing with paths added to the index
+ with the intent-to-add bit.
+
+ * "git fast-export --anonymize" learned to take customized mapping to
+ allow its users to tweak its output more usable for debugging.
+
+ * The command line completion support (in contrib/) used to be
+ prepared to work with "set -u" but recent changes got a bit more
+ sloppy. This has been corrected.
+
+ * "git gui" now allows opening work trees from the start-up dialog.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * Code optimization for a common case.
+ (merge 8777616e4d an/merge-single-strategy-optim later to maint).
+
+ * We've adopted a convention that any on-stack structure can be
+ initialized to have zero values in all fields with "= { 0 }",
+ even when the first field happens to be a pointer, but sparse
+ complained that a null pointer should be spelled NULL for a long
+ time. Start using -Wno-universal-initializer option to squelch
+ it (the latest sparse has it on by default).
+
+ * "git log -L..." now takes advantage of the "which paths are touched
+ by this commit?" info stored in the commit-graph system.
+
+ * As FreeBSD is not the only platform whose regexp library reports
+ a REG_ILLSEQ error when fed invalid UTF-8, add logic to detect that
+ automatically and skip the affected tests.
+
+ * "git bugreport" learns to report what shell is in use.
+
+ * Support for GIT_CURL_VERBOSE has been rewritten in terms of
+ GIT_TRACE_CURL.
+
+ * Preliminary clean-ups around refs API, plus file format
+ specification documentation for the reftable backend.
+
+ * Workaround breakage in MSVC build, where "curl-config --cflags"
+ gives settings appropriate for GCC build.
+
+ * Code clean-up of "git clean" resulted in a fix of recent
+ performance regression.
+
+ * Code clean-up in the codepath that serves "git fetch" continues.
+
+ * "git merge-base --is-ancestor" is taught to take advantage of the
+ commit graph.
+
+ * Rewrite of parts of the scripted "git submodule" Porcelain command
+ continues; this time it is "git submodule set-branch" subcommand's
+ turn.
+
+ * The "fetch/clone" protocol has been updated to allow the server to
+ instruct the clients to grab pre-packaged packfile(s) in addition
+ to the packed object data coming over the wire.
+
+ * A misdesigned strbuf_write_fd() function has been retired.
+
+ * SHA-256 migration work continues, including CVS/SVN interface.
+
+ * A few fields in "struct commit" that do not have to always be
+ present have been moved to commit slabs.
+
+ * API cleanup for get_worktrees()
+
+ * By renumbering object flag bits, "struct object" managed to lose
+ bloated inter-field padding.
+
+ * The name of the primary branch in existing repositories, and the
+ default name used for the first branch in newly created
+ repositories, is made configurable, so that we can eventually wean
+ ourselves off of the hardcoded 'master'.
+
+ * The effort to avoid using test_must_fail on non-git command continues.
+
+ * In 2.28-rc0, we corrected a bug that some repository extensions are
+ honored by mistake even in a version 0 repositories (these
+ configuration variables in extensions.* namespace were supposed to
+ have special meaning in repositories whose version numbers are 1 or
+ higher), but this was a bit too big a change. The behaviour in
+ recent versions of Git where certain extensions.* were honored by
+ mistake even in version 0 repositories has been restored.
+
+
+Fixes since v2.27
+-----------------
+
+ * The "--prepare-p4-only" option of "git p4" is supposed to stop
+ after replaying one changeset, but kept going (by mistake?)
+
+ * The error message from "git checkout -b foo -t bar baz" was
+ confusing.
+
+ * Some repositories in the wild have commits that record nonsense
+ committer timezone (e.g. rails.git); "git fast-import" learned an
+ option to pass these nonsense timestamps intact to allow recreating
+ existing repositories as-is.
+ (merge d42a2fb72f en/fast-import-looser-date later to maint).
+
+ * The command line completion script (in contrib/) tried to complete
+ "git stash -p" as if it were "git stash push -p", but it was too
+ aggressive and also affected "git stash show -p", which has been
+ corrected.
+ (merge fffd0cf520 vs/complete-stash-show-p-fix later to maint).
+
+ * On-the-wire protocol v2 easily falls into a deadlock between the
+ remote-curl helper and the fetch-pack process when the server side
+ prematurely throws an error and disconnects. The communication has
+ been updated to make it more robust.
+
+ * "git checkout -p" did not handle a newly added path at all.
+ (merge 2c8bd8471a js/checkout-p-new-file later to maint).
+
+ * The code to parse "git bisect start" command line was lax in
+ validating the arguments.
+ (merge 4d9005ff5d cb/bisect-helper-parser-fix later to maint).
+
+ * Reduce memory usage during "diff --quiet" in a worktree with too
+ many stat-unmatched paths.
+ (merge d2d7fbe129 jk/diff-memuse-optim-with-stat-unmatch later to maint).
+
+ * The reflog entries for "git clone" and "git fetch" did not
+ anonymize the URL they operated on.
+ (merge 46da295a77 js/reflog-anonymize-for-clone-and-fetch later to maint).
+
+ * The behaviour of "sparse-checkout" in the state "git clone
+ --no-checkout" left was changed accidentally in 2.27, which has
+ been corrected.
+
+ * Use of negative pathspec, while collecting paths including
+ untracked ones in the working tree, was broken.
+
+ * The same worktree directory must be registered only once, but
+ "git worktree move" allowed this invariant to be violated, which
+ has been corrected.
+ (merge 810382ed37 es/worktree-duplicate-paths later to maint).
+
+ * The effect of sparse checkout settings on submodules is documented.
+ (merge e7d7c73249 en/sparse-with-submodule-doc later to maint).
+
+ * Code clean-up around "git branch" with a minor bugfix.
+ (merge dc44639904 dl/branch-cleanup later to maint).
+
+ * A branch name used in a test has been clarified to match what is
+ going on.
+ (merge 08dc26061f pb/t4014-unslave later to maint).
+
+ * An in-code comment in "git diff" has been updated.
+ (merge c592fd4c83 dl/diff-usage-comment-update later to maint).
+
+ * The documentation and some tests have been adjusted for the recent
+ renaming of "pu" branch to "seen".
+ (merge 6dca5dbf93 js/pu-to-seen later to maint).
+
+ * The code to push changes over "dumb" HTTP had a bad interaction
+ with the commit reachability code due to incorrect allocation of
+ object flag bits, which has been corrected.
+ (merge 64472d15e9 bc/http-push-flagsfix later to maint).
+
+ * "git send-email --in-reply-to=<msg>" did not use the In-Reply-To:
+ header with the value given from the command line, and let it be
+ overridden by the value on In-Reply-To: header in the messages
+ being sent out (if exists).
+ (merge f9f60d7066 ra/send-email-in-reply-to-from-command-line-wins later to maint).
+
+ * "git log -Lx,y:path --before=date" lost track of where the range
+ should be because it didn't take the changes made by the youngest
+ commits that are omitted from the output into account.
+
+ * When "fetch.writeCommitGraph" configuration is set in a shallow
+ repository and a fetch moves the shallow boundary, we wrote out
+ broken commit-graph files that do not match the reality, which has
+ been corrected.
+
+ * "git checkout" failed to catch an error from fstat() after updating
+ a path in the working tree.
+ (merge 35e6e212fd mt/entry-fstat-fallback-fix later to maint).
+
+ * When an aliased command, whose output is piped to a pager by git,
+ gets killed by a signal, the pager got into a funny state, which
+ has been corrected (again).
+ (merge c0d73a59c9 ta/wait-on-aliased-commands-upon-signal later to maint).
+
+ * The code to produce progress output from "git commit-graph --write"
+ had a few breakages, which have been fixed.
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge 2c31a7aa44 jx/pkt-line-doc-count-fix later to maint).
+ (merge d63ae31962 cb/t5608-cleanup later to maint).
+ (merge 788db145c7 dl/t-readme-spell-git-correctly later to maint).
+ (merge 45a87a83bb dl/python-2.7-is-the-floor-version later to maint).
+ (merge b75a219904 es/advertise-contribution-doc later to maint).
+ (merge 0c9a4f638a rs/pull-leakfix later to maint).
+ (merge d546fe2874 rs/commit-reach-leakfix later to maint).
+ (merge 087bf5409c mk/pb-pretty-email-without-domain-part-fix later to maint).
+ (merge 5f4ee57ad9 es/worktree-code-cleanup later to maint).
+ (merge 0172f7834a cc/cat-file-usage-update later to maint).
+ (merge 81de0c01cf ma/rebase-doc-typofix later to maint).
diff --git a/RelNotes/2.28.1.adoc b/RelNotes/2.28.1.adoc
new file mode 100644
index 0000000..8484c82
--- /dev/null
+++ b/RelNotes/2.28.1.adoc
@@ -0,0 +1,7 @@
+Git v2.28.1 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.17.6, v2.18.5,
+v2.19.6, v2.20.5, v2.21.4, v2.22.5, v2.23.4, v2.24.4, v2.25.5,
+v2.26.3 and v2.27.1 to address the security issue CVE-2021-21300;
+see the release notes for these versions for details.
diff --git a/RelNotes/2.29.0.adoc b/RelNotes/2.29.0.adoc
new file mode 100644
index 0000000..1f41302
--- /dev/null
+++ b/RelNotes/2.29.0.adoc
@@ -0,0 +1,514 @@
+Git 2.29 Release Notes
+======================
+
+Updates since v2.28
+-------------------
+
+UI, Workflows & Features
+
+ * "git help log" has been enhanced by sharing more material from the
+ documentation for the underlying "git rev-list" command.
+
+ * "git for-each-ref --format=<>" learned %(contents:size).
+
+ * "git merge" learned to selectively omit " into <branch>" at the end
+ of the title of default merge message with merge.suppressDest
+ configuration.
+
+ * The component to respond to "git fetch" request is made more
+ configurable to selectively allow or reject object filtering
+ specification used for partial cloning.
+
+ * Stop when "sendmail.*" configuration variables are defined, which
+ could be a mistaken attempt to define "sendemail.*" variables.
+
+ * The existing backends for "git mergetool" based on variants of vim
+ have been refactored and then support for "nvim" has been added.
+
+ * "git bisect" learns the "--first-parent" option to find the first
+ breakage along the first-parent chain.
+
+ * "git log --first-parent -p" showed patches only for single-parent
+ commits on the first-parent chain; the "--first-parent" option has
+ been made to imply "-m". Use "--no-diff-merges" to restore the
+ previous behaviour to omit patches for merge commits.
+
+ * The commit labels used to explain each side of conflicted hunks
+ placed by the sequencer machinery have been made more readable by
+ humans.
+
+ * The "--batch-size" option of "git multi-pack-index repack" command
+ is now used to specify that very small packfiles are collected into
+ one until the total size roughly exceeds it.
+
+ * The recent addition of SHA-256 support is marked as experimental in
+ the documentation.
+
+ * "git fetch" learned --no-write-fetch-head option to avoid writing
+ the FETCH_HEAD file.
+
+ * Command line completion (in contrib/) usually omits redundant,
+ deprecated and/or dangerous options from its output; it learned to
+ optionally include all of them.
+
+ * The output from the "diff" family of the commands had abbreviated
+ object names of blobs involved in the patch, but its length was not
+ affected by the --abbrev option. Now it is.
+
+ * "git worktree" gained a "repair" subcommand to help users recover
+ after moving the worktrees or repository manually without telling
+ Git. Also, "git init --separate-git-dir" no longer corrupts
+ administrative data related to linked worktrees.
+
+ * The "--format=" option to the "for-each-ref" command and friends
+ learned a few more tricks, e.g. the ":short" suffix that applies to
+ "objectname" now also can be used for "parent", "tree", etc.
+
+ * "git worktree add" learns that the "-d" is a synonym to "--detach"
+ option to create a new worktree without being on a branch.
+
+ * "format-patch --range-diff=<prev> <origin>..HEAD" has been taught
+ not to ignore <origin> when <prev> is a single version.
+
+ * "add -p" now allows editing paths that were only added in intent.
+
+ * The 'meld' backend of the "git mergetool" learned to give the
+ underlying 'meld' the '--auto-merge' option, which would help
+ reduce the amount of text that requires manual merging.
+
+ * "git for-each-ref" and friends that list refs used to allow only
+ one --merged or --no-merged to filter them; they learned to take
+ combination of both kind of filtering.
+
+ * "git maintenance", a "git gc"'s big brother, has been introduced to
+ take care of more repository maintenance tasks, not limited to the
+ object database cleaning.
+
+ * "git receive-pack" that accepts requests by "git push" learned to
+ outsource most of the ref updates to the new "proc-receive" hook.
+
+ * "git push" that wants to be atomic and wants to send push
+ certificate learned not to prepare and sign the push certificate
+ when it fails the local check (hence due to atomicity it is known
+ that no certificate is needed).
+
+ * "git commit-graph write" learned to limit the number of bloom
+ filters that are computed from scratch with the --max-new-filters
+ option.
+
+ * The transport protocol v2 has become the default again.
+
+ * The installation procedure learned to optionally omit "git-foo"
+ executable files for each 'foo' built-in subcommand, which are only
+ required by old timers that still rely on the age old promise that
+ prepending "git --exec-path" output to PATH early in their script
+ will keep the "git-foo" calls they wrote working.
+
+ * The command line completion (in contrib/) learned that "git restore
+ -s <TAB>" is often followed by a refname.
+
+ * "git shortlog" has been taught to group commits by the contents of
+ the trailer lines, like "Reviewed-by:", "Coauthored-by:", etc.
+
+ * "git archive" learns the "--add-file" option to include untracked
+ files into a snapshot from a tree-ish.
+
+ * "git fetch" and "git push" support negative refspecs.
+
+ * "git format-patch" learns to take "whenAble" as a possible value
+ for the format.useAutoBase configuration variable to become no-op
+ when the automatically computed base does not make sense.
+
+ * Credential helpers are now allowed to terminate lines with CRLF
+ line ending, as well as LF line ending.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * The changed-path Bloom filter is improved using ideas from an
+ independent implementation.
+
+ * Updates to the changed-paths bloom filter.
+
+ * The test framework has been updated so that most tests will run
+ with predictable (artificial) timestamps.
+
+ * Preliminary clean-up of the refs API in preparation for adding a
+ new refs backend "reftable".
+
+ * Dev support to limit the use of test_must_fail to only git commands.
+
+ * While packing many objects in a repository with a promissor remote,
+ lazily fetching missing objects from the promissor remote one by
+ one may be inefficient---the code now attempts to fetch all the
+ missing objects in batch (obviously this won't work for a lazy
+ clone that lazily fetches tree objects as you cannot even enumerate
+ what blobs are missing until you learn which trees are missing).
+
+ * The pretend-object mechanism checks if the given object already
+ exists in the object store before deciding to keep the data
+ in-core, but the check would have triggered lazy fetching of such
+ an object from a promissor remote.
+
+ * The argv_array API is useful for not just managing argv but any
+ "vector" (NULL-terminated array) of strings, and has seen adoption
+ to a certain degree. It has been renamed to "strvec" to reduce the
+ barrier to adoption.
+
+ * The final leg of SHA-256 transition plus doc updates. Note that
+ there is no interoperability between SHA-1 and SHA-256
+ repositories yet.
+
+ * CMake support to build with MSVC for Windows bypassing the Makefile.
+
+ * A new helper function has_object() has been introduced to make it
+ easier to mark object existence checks that do and don't want to
+ trigger lazy fetches, and a few such checks are converted using it.
+
+ * A no-op replacement function implemented as a C preprocessor macro
+ does not perform as good a job as one implemented as a "static
+ inline" function in catching errors in parameters; replace the
+ former with the latter in <git-compat-util.h> header.
+
+ * Test framework update.
+ (merge d572f52a64 es/test-cmp-typocatcher later to maint).
+
+ * Updates to "git merge" tests, in preparation for a new merge
+ strategy backend.
+
+ * midx and commit-graph files now use the byte defined in their file
+ format specification for identifying the hash function used for
+ object names.
+
+ * The FETCH_HEAD is now always read from the filesystem regardless of
+ the ref backend in use, as its format is much richer than the
+ normal refs, and written directly by "git fetch" as a plain file..
+
+ * An unused binary has been discarded, and a bunch of commands
+ have been turned into built-in.
+
+ * A handful of places in in-tree code still relied on being able to
+ execute the git subcommands, especially built-ins, in "git-foo"
+ form, which have been corrected.
+
+ * When a packfile is removed by "git repack", multi-pack-index gets
+ cleared; the code was taught to do so less aggressively by first
+ checking if the midx actually refers to a pack that no longer
+ exists.
+
+ * Internal API clean-up to handle two options "diff-index" and "log"
+ have, which happen to share the same short form, more sensibly.
+
+ * The "add -i/-p" machinery has been written in C but it is not used
+ by default yet. It is made default to those who are participating
+ in feature.experimental experiment.
+
+ * Allow maintainers to tweak $(TAR) invocations done while making
+ distribution tarballs.
+
+ * "git index-pack" learned to resolve deltified objects with greater
+ parallelism.
+
+ * "diff-highlight" (in contrib/) had a logic to flush its output upon
+ seeing a blank line but the way it detected a blank line was broken.
+
+ * The logic to skip testing on the tagged commit and the tag itself
+ was not quite consistent which led to failure of Windows test
+ tasks. It has been revamped to consistently skip revisions that
+ have already been tested, based on the tree object of the revision.
+
+
+Fixes since v2.28
+-----------------
+
+ * The "mediawiki" remote backend which lives in contrib/mw-to-git/
+ and is not built with git by default, had an RCE bug allowing a
+ malicious MediaWiki server operator to inject arbitrary commands
+ for execution by a cloning client. This has been fixed.
+
+ The bug was discovered and reported by Joern Schneeweisz of GitLab
+ to the git-security mailing list. Its practical impact due to the
+ obscurity of git-remote-mediawiki was deemed small enough to forgo
+ a dedicated security release.
+
+ * "git clone --separate-git-dir=$elsewhere" used to stomp on the
+ contents of the existing directory $elsewhere, which has been
+ taught to fail when $elsewhere is not an empty directory.
+ (merge dfaa209a79 bw/fail-cloning-into-non-empty later to maint).
+
+ * With the base fix to 2.27 regresion, any new extensions in a v0
+ repository would still be silently honored, which is not quite
+ right. Instead, complain and die loudly.
+ (merge ec91ffca04 jk/reject-newer-extensions-in-v0 later to maint).
+
+ * Fetching from a lazily cloned repository resulted at the server
+ side in attempts to lazy fetch objects that the client side has,
+ many of which will not be available from the third-party anyway.
+ (merge 77aa0941ce jt/avoid-lazy-fetching-upon-have-check later to maint).
+
+ * Fix to an ancient bug caused by an over-eager attempt for
+ optimization.
+ (merge a98f7fb366 rs/add-index-entry-optim-fix later to maint).
+
+ * Pushing a ref whose name contains non-ASCII character with the
+ "--force-with-lease" option did not work over smart HTTP protocol,
+ which has been corrected.
+ (merge cd85b447bf bc/push-cas-cquoted-refname later to maint).
+
+ * "git mv src dst", when src is an unmerged path, errored out
+ correctly but with an incorrect error message to claim that src is
+ not tracked, which has been clarified.
+ (merge 9b906af657 ct/mv-unmerged-path-error later to maint).
+
+ * Fix to a regression introduced during 2.27 cycle.
+ (merge cada7308ad en/fill-directory-exponential later to maint).
+
+ * Command line completion (in contrib/) update.
+ (merge 688b87c81b mp/complete-show-color-moved later to maint).
+
+ * All "mergy" operations that internally use the merge-recursive
+ machinery should honor the merge.renormalize configuration, but
+ many of them didn't.
+
+ * Doc cleanup around "worktree".
+ (merge dc9c144be5 es/worktree-doc-cleanups later to maint).
+
+ * The "git blame --first-parent" option was not documented, but now
+ it is.
+ (merge 11bc12ae1e rp/blame-first-parent-doc later to maint).
+
+ * The logic to find the ref transaction hook script attempted to
+ cache the path to the found hook without realizing that it needed
+ to keep a copied value, as the API it used returned a transitory
+ buffer space. This has been corrected.
+ (merge 09b2aa30c9 ps/ref-transaction-hook later to maint).
+
+ * Recent versions of "git diff-files" shows a diff between the index
+ and the working tree for "intent-to-add" paths as a "new file"
+ patch; "git apply --cached" should be able to take "git diff-files"
+ and should act as an equivalent to "git add" for the path, but the
+ command failed to do so for such a path.
+ (merge 4c025c667e rp/apply-cached-with-i-t-a later to maint).
+
+ * "git diff [<tree-ish>] $path" for a $path that is marked with i-t-a
+ bit was not showing the mode bits from the working tree.
+ (merge cb0dd22b82 rp/ita-diff-modefix later to maint).
+
+ * Ring buffer with size 4 used for bin-hex translation resulted in a
+ wrong object name in the sequencer's todo output, which has been
+ corrected.
+ (merge 5da69c0dac ak/sequencer-fix-find-uniq-abbrev later to maint).
+
+ * When given more than one target line ranges, "git blame -La,b
+ -Lc,d" was over-eager to coalesce groups of original lines and
+ showed incorrect results, which has been corrected.
+ (merge c2ebaa27d6 jk/blame-coalesce-fix later to maint).
+
+ * The regexp to identify the function boundary for FORTRAN programs
+ has been updated.
+ (merge 75c3b6b2e8 pb/userdiff-fortran-update later to maint).
+
+ * A few end-user facing messages have been updated to be
+ hash-algorithm agnostic.
+ (merge 4279000d3e jc/object-names-are-not-sha-1 later to maint).
+
+ * "unlink" emulation on MinGW has been optimized.
+ (merge 680e0b4524 jh/mingw-unlink later to maint).
+
+ * The purpose of "git init --separate-git-dir" is to initialize a
+ new project with the repository separate from the working tree,
+ or, in the case of an existing project, to move the repository
+ (the .git/ directory) out of the working tree. It does not make
+ sense to use --separate-git-dir with a bare repository for which
+ there is no working tree, so disallow its use with bare
+ repositories.
+ (merge ccf236a23a es/init-no-separate-git-dir-in-bare later to maint).
+
+ * "ls-files -o" mishandled the top-level directory of another git
+ working tree that hangs in the current git working tree.
+ (merge ab282aa548 en/dir-nonbare-embedded later to maint).
+
+ * Fix some incorrect UNLEAK() annotations.
+ (merge 3e19816dc0 jk/unleak-fixes later to maint).
+
+ * Use more buffered I/O where we used to call many small write(2)s.
+ (merge a698d67b08 rs/more-buffered-io later to maint).
+
+ * The patch-id computation did not ignore the "incomplete last line"
+ marker like whitespaces.
+ (merge 82a62015a7 rs/patch-id-with-incomplete-line later to maint).
+
+ * Updates into a lazy/partial clone with a submodule did not work
+ well with transfer.fsckobjects set.
+
+ * The parser for "git for-each-ref --format=..." was too loose when
+ parsing the "%(trailers...)" atom, and forgot that "trailers" and
+ "trailers:<modifiers>" are the only two allowed forms, which has
+ been corrected.
+ (merge 2c22e102f8 hv/ref-filter-trailers-atom-parsing-fix later to maint).
+
+ * Long ago, we decided to use 3 threads by default when running the
+ index-pack task in parallel, which has been adjusted a bit upwards.
+ (merge fbff95b67f jk/index-pack-w-more-threads later to maint).
+
+ * "git restore/checkout --no-overlay" with wildcarded pathspec
+ mistakenly removed matching paths in subdirectories, which has been
+ corrected.
+ (merge bfda204ade rs/checkout-no-overlay-pathspec-fix later to maint).
+
+ * The description of --cached/--index options in "git apply --help"
+ has been updated.
+ (merge d064702be3 rp/apply-cached-doc later to maint).
+
+ * Feeding "$ZERO_OID" to "git log --ignore-missing --stdin", and
+ running "git log --ignore-missing $ZERO_OID" fell back to start
+ digging from HEAD; it has been corrected to become a no-op, like
+ "git log --tags=no-tag-matches-this-pattern" does.
+ (merge 04a0e98515 jk/rev-input-given-fix later to maint).
+
+ * Various callers of run_command API have been modernized.
+ (merge afbdba391e jc/run-command-use-embedded-args later to maint).
+
+ * List of options offered and accepted by "git add -i/-p" were
+ inconsistent, which have been corrected.
+ (merge ce910287e7 pw/add-p-allowed-options-fix later to maint).
+
+ * "git diff --stat -w" showed 0-line changes for paths whose changes
+ were only whitespaces, which was not intuitive. We now omit such
+ paths from the stat output.
+ (merge 1cf3d5db9b mr/diff-hide-stat-wo-textual-change later to maint).
+
+ * It was possible for xrealloc() to send a non-NULL pointer that has
+ been freed, which has been fixed.
+ (merge 6479ea4a8a jk/xrealloc-avoid-use-after-free later to maint).
+
+ * "git status" has trouble showing where it came from by interpreting
+ reflog entries that record certain events, e.g. "checkout @{u}", and
+ gives a hard/fatal error. Even though it inherently is impossible
+ to give a correct answer because the reflog entries lose some
+ information (e.g. "@{u}" does not record what branch the user was
+ on hence which branch 'the upstream' needs to be computed, and even
+ if the record were available, the relationship between branches may
+ have changed), at least hide the error and allow "status" to show its
+ output.
+
+ * "git status --short" quoted a path with SP in it when tracked, but
+ not those that are untracked, ignored or unmerged. They are all
+ shown quoted consistently.
+
+ * "git diff/show" on a change that involves a submodule used to read
+ the information on commits in the submodule from a wrong repository
+ and gave a wrong information when the commit-graph is involved.
+ (merge 85a1ec2c32 mf/submodule-summary-with-correct-repository later to maint).
+
+ * Unlike "git config --local", "git config --worktree" did not fail
+ early and cleanly when started outside a git repository.
+ (merge 378fe5fc3d mt/config-fail-nongit-early later to maint).
+
+ * There is a logic to estimate how many objects are in the
+ repository, which is meant to run once per process invocation, but
+ it ran every time the estimated value was requested.
+ (merge 67bb65de5d jk/dont-count-existing-objects-twice later to maint).
+
+ * "git remote set-head" that failed still said something that hints
+ the operation went through, which was misleading.
+ (merge 5a07c6c3c2 cs/don-t-pretend-a-failed-remote-set-head-succeeded later to maint).
+
+ * "git fetch --all --ipv4/--ipv6" forgot to pass the protocol options
+ to instances of the "git fetch" that talk to individual remotes,
+ which has been corrected.
+ (merge 4e735c1326 ar/fetch-ipversion-in-all later to maint).
+
+ * The "unshelve" subcommand of "git p4" incorrectly used commit^N
+ where it meant to say commit~N to name the Nth generation
+ ancestor, which has been corrected.
+ (merge 0acbf5997f ld/p4-unshelve-fix later to maint).
+
+ * "git clone" that clones from SHA-1 repository, while
+ GIT_DEFAULT_HASH set to use SHA-256 already, resulted in an
+ unusable repository that half-claims to be SHA-256 repository
+ with SHA-1 objects and refs. This has been corrected.
+
+ * Adjust sample hooks for hash algorithm other than SHA-1.
+ (merge d8d3d632f4 dl/zero-oid-in-hooks later to maint).
+
+ * "git range-diff" showed incorrect diffstat, which has been
+ corrected.
+
+ * Earlier we taught "git pull" to warn when the user does not say the
+ histories need to be merged, rebased or accepts only fast-
+ forwarding, but the warning triggered for those who have set the
+ pull.ff configuration variable.
+ (merge 54200cef86 ah/pull later to maint).
+
+ * Compilation fix around type punning.
+ (merge 176380fd11 jk/drop-unaligned-loads later to maint).
+
+ * "git blame --ignore-rev/--ignore-revs-file" failed to validate
+ their input are valid revision, and failed to take into account
+ that the user may want to give an annotated tag instead of a
+ commit, which has been corrected.
+ (merge 610e2b9240 jc/blame-ignore-fix later to maint).
+
+ * "git bisect start X Y", when X and Y are not valid committish
+ object names, should take X and Y as pathspec, but didn't.
+ (merge 73c6de06af cc/bisect-start-fix later to maint).
+
+ * The explanation of the "scissors line" has been clarified.
+ (merge 287416dba6 eg/mailinfo-doc-scissors later to maint).
+
+ * A race that leads to an access to a free'd data was corrected in
+ the codepath that reads pack files.
+ (merge bda959c476 mt/delta-base-cache-races later to maint).
+
+ * in_merge_bases_many(), a way to see if a commit is reachable from
+ any commit in a set of commits, was totally broken when the
+ commit-graph feature was in use, which has been corrected.
+ (merge 8791bf1841 ds/in-merge-bases-many-optim-bug later to maint).
+
+ * "git submodule update --quiet" did not squelch underlying "rebase"
+ and "pull" commands.
+ (merge 3ad0401e9e td/submodule-update-quiet later to maint).
+
+ * The lazy fetching done internally to make missing objects available
+ in a partial clone incorrectly made permanent damage to the partial
+ clone filter in the repository, which has been corrected.
+
+ * "log -c --find-object=X" did not work well to find a merge that
+ involves a change to an object X from only one parent.
+ (merge 957876f17d jk/diff-cc-oidfind-fix later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge 84544f2ea3 sk/typofixes later to maint).
+ (merge b17f411ab5 ar/help-guides-doc later to maint).
+ (merge 98c6871fad rs/grep-simpler-parse-object-or-die-call later to maint).
+ (merge 861c4ce141 en/typofixes later to maint).
+ (merge 60e47f6773 sg/ci-git-path-fix-with-pyenv later to maint).
+ (merge e2bfa50ac3 jb/doc-packfile-name later to maint).
+ (merge 918d8ff780 es/worktree-cleanup later to maint).
+ (merge dc156bc31f ma/t1450-quotefix later to maint).
+ (merge 56e743426b en/merge-recursive-comment-fixes later to maint).
+ (merge 7d23ff818f rs/bisect-oid-to-hex-fix later to maint).
+ (merge de20baf2c9 ny/notes-doc-sample-update later to maint).
+ (merge f649aaaf82 so/rev-parser-errormessage-fix later to maint).
+ (merge 6103d58b7f bc/sha-256-cvs-svn-updates later to maint).
+ (merge ac900fddb7 ma/stop-progress-null-fix later to maint).
+ (merge e767963ab6 rs/upload-pack-sigchain-fix later to maint).
+ (merge a831908599 rs/preserve-merges-unused-code-removal later to maint).
+ (merge 6dfefe70a9 jb/commit-graph-doc-fix later to maint).
+ (merge 847b37271e pb/set-url-docfix later to maint).
+ (merge 748f733d54 mt/checkout-entry-dead-code-removal later to maint).
+ (merge ce820cbd58 dl/subtree-docs later to maint).
+ (merge 55fe225dde jk/leakfix later to maint).
+ (merge ee22a29215 so/pretty-abbrev-doc later to maint).
+ (merge 3100fd5588 jc/post-checkout-doc later to maint).
+ (merge 17bae89476 pb/doc-external-diff-env later to maint).
+ (merge 27ed6ccc12 jk/worktree-check-clean-leakfix later to maint).
+ (merge 1302badd16 ea/blame-use-oideq later to maint).
+ (merge e6d5a11fed al/t3200-back-on-a-branch later to maint).
+ (merge 324efcf6b6 pw/add-p-leakfix later to maint).
+ (merge 1c6ffb546b jk/add-i-fixes later to maint).
+ (merge e40e936551 cd/commit-graph-doc later to maint).
+ (merge 0512eabd91 jc/sequencer-stopped-sha-simplify later to maint).
+ (merge d01141de5a so/combine-diff-simplify later to maint).
+ (merge 3be01e5ab1 sn/fast-import-doc later to maint).
diff --git a/RelNotes/2.29.1.adoc b/RelNotes/2.29.1.adoc
new file mode 100644
index 0000000..295ee21
--- /dev/null
+++ b/RelNotes/2.29.1.adoc
@@ -0,0 +1,11 @@
+Git v2.29.1 Release Notes
+=========================
+
+This is to fix the build procedure change in 2.28 where we failed to
+install a few programs that should be installed in /usr/bin (namely,
+receive-pack, upload-archive and upload-pack) when the non-default
+SKIP_DASHED_BUILT_INS installation option is in effect.
+
+A minor glitch in a non-default installation may usually not deserve
+a hotfix, but I know Git for Windows ship binaries built with this
+option, so let's make an exception.
diff --git a/RelNotes/2.29.2.adoc b/RelNotes/2.29.2.adoc
new file mode 100644
index 0000000..632b5b5
--- /dev/null
+++ b/RelNotes/2.29.2.adoc
@@ -0,0 +1,12 @@
+Git v2.29.2 Release Notes
+=========================
+
+This release is primarily to fix brown-paper-bag breakages in the
+2.29.0 release.
+
+Fixes since v2.29.1
+-------------------
+
+ * In 2.29, "--committer-date-is-author-date" option of "rebase" and
+ "am" subcommands lost the e-mail address by mistake, which has been
+ corrected.
diff --git a/RelNotes/2.29.3.adoc b/RelNotes/2.29.3.adoc
new file mode 100644
index 0000000..e10eedb
--- /dev/null
+++ b/RelNotes/2.29.3.adoc
@@ -0,0 +1,8 @@
+Git v2.29.3 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.17.6,
+v2.18.5, v2.19.6, v2.20.5, v2.21.4, v2.22.5, v2.23.4, v2.24.4,
+v2.25.5, v2.26.3, v2.27.1 and v2.28.1 to address the security
+issue CVE-2021-21300; see the release notes for these versions
+for details.
diff --git a/RelNotes/2.3.0.adoc b/RelNotes/2.3.0.adoc
new file mode 100644
index 0000000..e3c639c
--- /dev/null
+++ b/RelNotes/2.3.0.adoc
@@ -0,0 +1,300 @@
+Git v2.3 Release Notes
+======================
+
+This one ended up to be a release with lots of small corrections and
+improvements without big uncomfortably exciting features. The recent
+security fix that went to 2.2.1 and older maintenance tracks is also
+contained in this update.
+
+
+Updates since v2.2
+------------------
+
+Ports
+
+ * Recent gcc toolchain on Cygwin started throwing compilation warning,
+ which has been squelched.
+
+ * A few updates to build on platforms that lack tv_nsec,
+ clock_gettime, CLOCK_MONOTONIC and HMAC_CTX_cleanup (e.g. older
+ RHEL) have been added.
+
+
+UI, Workflows & Features
+
+ * It was cumbersome to use "GIT_SSH" mechanism when the user wanted
+ to pass an extra set of arguments to the underlying ssh. A new
+ environment variable GIT_SSH_COMMAND can be used for this.
+
+ * A request to store an empty note via "git notes" meant to remove
+ note from the object but with --allow-empty we will store a
+ (surprise!) note that is empty.
+
+ * "git interpret-trailers" learned to properly handle the
+ "Conflicts:" block at the end.
+
+ * "git am" learned "--message-id" option to copy the message ID of
+ the incoming e-mail to the log message of resulting commit.
+
+ * "git clone --reference=<over there>" learned the "--dissociate"
+ option to go with it; it borrows objects from the reference object
+ store while cloning only to reduce network traffic and then
+ dissociates the resulting clone from the reference by performing
+ local copies of borrowed objects.
+
+ * "git send-email" learned "--transfer-encoding" option to force a
+ non-fault Content-Transfer-Encoding header (e.g. base64).
+
+ * "git send-email" normally identifies itself via X-Mailer: header in
+ the message it sends out. A new command line flag --no-xmailer
+ allows the user to squelch the header.
+
+ * "git push" into a repository with a working tree normally refuses
+ to modify the branch that is checked out. The command learned to
+ optionally do an equivalent of "git reset --hard" only when there
+ is no change to the working tree and the index instead, which would
+ be useful to "deploy" by pushing into a repository.
+
+ * "git new-workdir" (in contrib/) can be used to populate an empty
+ and existing directory now.
+
+ * Credential helpers are asked in turn until one of them give
+ positive response, which is cumbersome to turn off when you need to
+ run Git in an automated setting. The credential helper interface
+ learned to allow a helper to say "stop, don't ask other helpers."
+ Also GIT_TERMINAL_PROMPT environment can be set to false to disable
+ our built-in prompt mechanism for passwords.
+
+ * "git branch -d" (delete) and "git branch -m" (move) learned to
+ honor "-f" (force) flag; unlike many other subcommands, the way to
+ force these have been with separate "-D/-M" options, which was
+ inconsistent.
+
+ * "diff-highlight" filter (in contrib/) allows its color output to be
+ customized via configuration variables.
+
+ * "git imap-send" learned to take "-v" (verbose) and "-q" (quiet)
+ command line options.
+
+ * "git remote add $name $URL" is now allowed when "url.$URL.insteadOf"
+ is already defined.
+
+ * "git imap-send" now can be built to use cURL library to talk to
+ IMAP servers (if the library is recent enough, of course).
+ This allows you to use authenticate method other than CRAM-MD5,
+ among other things.
+
+ * "git imap-send" now allows GIT_CURL_VERBOSE environment variable to
+ control the verbosity when talking via the cURL library.
+
+ * The prompt script (in contrib/) learned to optionally hide prompt
+ when in an ignored directory by setting GIT_PS1_HIDE_IF_PWD_IGNORED
+ shell variable.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * Earlier we made "rev-list --object-edge" more aggressively list the
+ objects at the edge commits, in order to reduce number of objects　
+ fetched into a shallow repository, but the change affected cases
+ other than "fetching into a shallow repository" and made it
+ unusably slow (e.g. fetching into a normal repository should not
+ have to suffer the overhead from extra processing). Limit it to a
+ more specific case by introducing --objects-edge-aggressive, a new
+ option to rev-list.
+
+ * Squelched useless compiler warnings on Mac OS X regarding the
+ crypto API.
+
+ * The procedure to generate unicode table has been simplified.
+
+ * Some filesystems assign filemodes in a strange way, fooling then
+ automatic "filemode trustability" check done during a new
+ repository creation. The initialization codepath has been hardened
+ against this issue.
+
+ * The codepath in "git remote update --prune" to drop many refs has
+ been optimized.
+
+ * The API into get_merge_bases*() family of functions was easy to
+ misuse, which has been corrected to make it harder to do so.
+
+ * Long overdue departure from the assumption that S_IFMT is shared by
+ everybody made in 2005, which was necessary to port to z/OS.
+
+ * "git push" and "git fetch" did not communicate an overlong refname
+ correctly. Now it uses 64kB sideband to accommodate longer ones.
+
+ * Recent GPG changes the keyring format and drops support for RFC1991
+ formatted signatures, breaking our existing tests.
+
+ * "git-prompt" (in contrib/) used a variable from the global scope,
+ possibly contaminating end-user's namespace.
+
+
+Also contains various documentation updates and code clean-ups.
+
+
+Fixes since v2.2
+----------------
+
+Unless otherwise noted, all the fixes since v2.2 in the maintenance
+track are contained in this release (see the maintenance releases'
+notes for details).
+
+ * "git http-push" over WebDAV (aka dumb http-push) was broken in
+ v2.2.2 when parsing a symbolic ref, resulting in a bogus request
+ that gets rejected by recent versions of cURL library.
+ (merge f6786c8 jk/http-push-symref-fix later to maint).
+
+ * The logic in "git bisect bad HEAD" etc. to avoid forcing the test
+ of the common ancestor of bad and good commits was broken.
+ (merge 07913d5 cc/bisect-rev-parsing later to maint).
+
+ * "git checkout-index --temp=$target $path" did not work correctly
+ for paths outside the current subdirectory in the project.
+ (merge 74c4de5 es/checkout-index-temp later to maint).
+
+ * The report from "git checkout" on a branch that builds on another
+ local branch by setting its branch.*.merge to branch name (not a
+ full refname) incorrectly said that the upstream is gone.
+ (merge 05e7368 jc/checkout-local-track-report later to maint).
+
+ * With The git-prompt support (in contrib/), using the exit status of
+ the last command in the prompt, e.g. PS1='$(__git_ps1) $? ', did
+ not work well, because the helper function stomped on the exit
+ status.
+ (merge 6babe76 tf/prompt-preserve-exit-status later to maint).
+
+ * Recent update to "git commit" broke amending an existing commit
+ with bogus author/committer lines without a valid e-mail address.
+ (merge c83a509 jk/commit-date-approxidate later to maint).
+
+ * The lockfile API used to get confused which file to clean up when
+ the process moved the $cwd after creating a lockfile.
+ (merge fa137f6 nd/lockfile-absolute later to maint).
+
+ * Traditionally we tried to avoid interpreting date strings given by
+ the user as future dates, e.g. GIT_COMMITTER_DATE=2014-12-10 when
+ used early November 2014 was taken as "October 12, 2014" because it
+ is likely that a date in the future, December 10, is a mistake.
+ This heuristics has been loosened to allow people to express future
+ dates (most notably, --until=<date> may want to be far in the
+ future) and we no longer tiebreak by future-ness of the date when
+
+ (1) ISO-like format is used, and
+ (2) the string can make sense interpreted as both y-m-d and y-d-m.
+
+ Git may still have to use the heuristics to tiebreak between dd/mm/yy
+ and mm/dd/yy, though.
+ (merge d372395 jk/approxidate-avoid-y-d-m-over-future-dates later to maint).
+
+ * Git did not correctly read an overlong refname from a packed refs
+ file.
+ (merge ea41783 jk/read-packed-refs-without-path-max later to maint).
+
+ * "git apply" was described in the documentation to take --ignore-date
+ option, which it does not.
+ (merge 0cef4e7 rw/apply-does-not-take-ignore-date later to maint).
+
+ * "git add -i" did not notice when the interactive command input
+ stream went away and kept asking the same question.
+ (merge a8bec7a jk/add-i-read-error later to maint).
+
+ * "git send-email" did not handle RFC 2047 encoded headers quite
+ right.
+ (merge ab47e2a rd/send-email-2047-fix later to maint).
+
+ * New tag object format validation added in 2.2 showed garbage after
+ a tagname it reported in its error message.
+ (merge a1e920a js/fsck-tag-validation later to maint).
+
+ * The code that reads the reflog from the newer to the older entries
+ did not handle an entry that crosses a boundary of block it uses to
+ read them correctly.
+ (merge 69216bf jk/for-each-reflog-ent-reverse later to maint).
+
+ * "git diff -B -M" after making a new copy B out of an existing file
+ A and then editing A extensively ought to report that B was created
+ by copying A and A was modified, which is what "git diff -C"
+ reports, but it instead said A was renamed to B and A was edited
+ heavily in place. This was not just incoherent but also failed to
+ apply with "git apply". The report has been corrected to match what
+ "git diff -C" produces for this case.
+ (merge 6936b58 jc/diff-b-m later to maint).
+
+ * In files we pre-populate for the user to edit with commented hints,
+ a line of hint that is indented with a tab used to show as '#' (or
+ any comment char), ' ' (space), and then the hint text that began
+ with the tab, which some editors flag as an indentation error (tab
+ following space). We now omit the space after the comment char in
+ such a case.
+ (merge d55aeb7 jc/strbuf-add-lines-avoid-sp-ht-sequence later to maint).
+
+ * "git ls-tree" does not support path selection based on negative
+ pathspecs, but did not error out when negative pathspecs are given.
+ (merge f1f6224 nd/ls-tree-pathspec later to maint).
+
+ * The function sometimes returned a non-freeable memory and some
+ other times returned a piece of memory that must be freed, leading
+ to inevitable leaks.
+ (merge 59362e5 jc/exec-cmd-system-path-leak-fix later to maint).
+
+ * The code to abbreviate an object name to its short unique prefix
+ has been optimized when no abbreviation was requested.
+ (merge 61e704e mh/find-uniq-abbrev later to maint).
+
+ * "git add --ignore-errors ..." did not ignore an error to
+ give a file that did not exist.
+ (merge 1d31e5a mg/add-ignore-errors later to maint).
+
+ * "git checkout $treeish $path", when $path in the index and the
+ working tree already matched what is in $treeish at the $path,
+ still overwrote the $path unnecessarily.
+ (merge c5326bd jk/checkout-from-tree later to maint).
+
+ * "git config --get-color" did not parse its command line arguments
+ carefully.
+ (merge cb35722 jk/colors-fix later to maint).
+
+ * open() emulated on Windows platforms did not give EISDIR upon
+ an attempt to open a directory for writing.
+ (merge ba6fad0 js/windows-open-eisdir-error later to maint).
+
+ * A few code paths used abs() when they should have used labs() on
+ long integers.
+ (merge 83915ba rs/maint-config-use-labs later to maint).
+ (merge 31a8aa1 rs/receive-pack-use-labs later to maint).
+
+ * "gitweb" used to depend on a behaviour recent CGI.pm deprecated.
+ (merge 13dbf46 jk/gitweb-with-newer-cgi-multi-param later to maint).
+
+ * "git init" (hence "git clone") initialized the per-repository
+ configuration file .git/config with x-bit by mistake.
+ (merge 1f32ecf mh/config-flip-xbit-back-after-checking later to maint).
+
+ * Recent update in Git 2.2 started creating objects/info/packs and
+ info/refs files with permission bits tighter than user's umask.
+ (merge d91175b jk/prune-packed-server-info later to maint).
+
+ * Git 2.0 was supposed to make the "simple" mode for the default of
+ "git push", but it didn't.
+ (merge 00a6fa0 jk/push-simple later to maint).
+
+ * "Everyday" document had a broken link.
+ (merge 366c8d4 po/everyday-doc later to maint).
+
+ * A few test fixes.
+ (merge 880ef58 jk/no-perl-tests later to maint).
+
+ * The build procedure did not bother fixing perl and python scripts
+ when NO_PERL and NO_PYTHON build-time configuration changed.
+ (merge ca2051d jk/rebuild-perl-scripts-with-no-perl-seting-change later to maint).
+
+ * The usage string of "git log" command was marked incorrectly for
+ l10n.
+ (merge e66dc0c km/log-usage-string-i18n later to maint).
+
+ * "git for-each-ref" mishandled --format="%(upstream:track)" when a
+ branch is marked to have forked from a non-existing branch.
+ (merge b6160d9 rc/for-each-ref-tracking later to maint).
diff --git a/RelNotes/2.3.1.adoc b/RelNotes/2.3.1.adoc
new file mode 100644
index 0000000..cf96186
--- /dev/null
+++ b/RelNotes/2.3.1.adoc
@@ -0,0 +1,52 @@
+Git v2.3.1 Release Notes
+========================
+
+Fixes since v2.3
+----------------
+
+ * The interactive "show a list and let the user choose from it"
+ interface "add -i" used showed and prompted to the user even when
+ the candidate list was empty, against which the only "choice" the
+ user could have made was to choose nothing.
+
+ * "git apply --whitespace=fix" used to under-allocate the memory
+ when the fix resulted in a longer text than the original patch.
+
+ * "git log --help" used to show rev-list options that are irrelevant
+ to the "log" command.
+
+ * The error message from "git commit", when a non-existing author
+ name was given as value to the "--author=" parameter, has been
+ reworded to avoid misunderstanding.
+
+ * A broken pack .idx file in the receiving repository prevented the
+ dumb http transport from fetching a good copy of it from the other
+ side.
+
+ * The documentation incorrectly said that C(opy) and R(ename) are the
+ only ones that can be followed by the score number in the output in
+ the --raw format.
+
+ * Fix a misspelled conditional that is always true.
+
+ * Code to read branch name from various files in .git/ directory
+ would have misbehaved if the code to write them left an empty file.
+
+ * The "git push" documentation made the "--repo=<there>" option
+ easily misunderstood.
+
+ * After attempting and failing a password-less authentication
+ (e.g. kerberos), libcURL refuses to fall back to password based
+ Basic authentication without a bit of help/encouragement.
+
+ * Setting diff.submodule to 'log' made "git format-patch" produce
+ broken patches.
+
+ * "git rerere" (invoked internally from many mergy operations) did
+ not correctly signal errors when told to update the working tree
+ files and failed to do so for whatever reason.
+
+ * "git blame HEAD -- missing" failed to correctly say "HEAD" when it
+ tried to say "No such path 'missing' in HEAD".
+
+Also contains typofixes, documentation updates and trivial code clean-ups.
diff --git a/RelNotes/2.3.10.adoc b/RelNotes/2.3.10.adoc
new file mode 100644
index 0000000..20c2d2c
--- /dev/null
+++ b/RelNotes/2.3.10.adoc
@@ -0,0 +1,18 @@
+Git v2.3.10 Release Notes
+=========================
+
+Fixes since v2.3.9
+------------------
+
+ * xdiff code we use to generate diffs is not prepared to handle
+ extremely large files. It uses "int" in many places, which can
+ overflow if we have a very large number of lines or even bytes in
+ our input files, for example. Cap the input size to somewhere
+ around 1GB for now.
+
+ * Some protocols (like git-remote-ext) can execute arbitrary code
+ found in the URL. The URLs that submodules use may come from
+ arbitrary sources (e.g., .gitmodules files in a remote
+ repository), and can hurt those who blindly enable recursive
+ fetch. Restrict the allowed protocols to well known and safe
+ ones.
diff --git a/RelNotes/2.3.2.adoc b/RelNotes/2.3.2.adoc
new file mode 100644
index 0000000..93462e4
--- /dev/null
+++ b/RelNotes/2.3.2.adoc
@@ -0,0 +1,79 @@
+Git v2.3.2 Release Notes
+========================
+
+Fixes since v2.3.1
+------------------
+
+ * "update-index --refresh" used to leak when an entry cannot be
+ refreshed for whatever reason.
+
+ * "git fast-import" used to crash when it could not close and
+ conclude the resulting packfile cleanly.
+
+ * "git blame" died, trying to free an uninitialized piece of memory.
+
+ * "git merge-file" did not work correctly in a subdirectory.
+
+ * "git submodule add" failed to squash "path/to/././submodule" to
+ "path/to/submodule".
+
+ * In v2.2.0, we broke "git prune" that runs in a repository that
+ borrows from an alternate object store.
+
+ * Certain older vintages of cURL give irregular output from
+ "curl-config --vernum", which confused our build system.
+
+ * An earlier workaround to squelch unhelpful deprecation warnings
+ from the compiler on Mac OSX unnecessarily set minimum required
+ version of the OS, which the user might want to raise (or lower)
+ for other reasons.
+
+ * Longstanding configuration variable naming rules has been added to
+ the documentation.
+
+ * The credential helper for Windows (in contrib/) used to mishandle
+ a user name with an at-sign in it.
+
+ * Older GnuPG implementations may not correctly import the keyring
+ material we prepare for the tests to use.
+
+ * Clarify in the documentation that "remote.<nick>.pushURL" and
+ "remote.<nick>.URL" are there to name the same repository accessed
+ via different transports, not two separate repositories.
+
+ * The pack bitmap support did not build with older versions of GCC.
+
+ * Reading configuration from a blob object, when it ends with a lone
+ CR, use to confuse the configuration parser.
+
+ * We didn't format an integer that wouldn't fit in "int" but in
+ "uintmax_t" correctly.
+
+ * "git push --signed" gave an incorrectly worded error message when
+ the other side did not support the capability.
+
+ * "git fetch" over a remote-helper that cannot respond to "list"
+ command could not fetch from a symbolic reference e.g. HEAD.
+
+ * The insn sheet "git rebase -i" creates did not fully honor
+ core.abbrev settings.
+
+ * The tests that wanted to see that file becomes unreadable after
+ running "chmod a-r file", and the tests that wanted to make sure it
+ is not run as root, we used "can we write into the / directory?" as
+ a cheap substitute, but on some platforms that is not a good
+ heuristics. The tests and their prerequisites have been updated to
+ check what they really require.
+
+ * The configuration variable 'mailinfo.scissors' was hard to
+ discover in the documentation.
+
+ * Correct a breakage to git-svn around v2.2 era that triggers
+ premature closing of FileHandle.
+
+ * Even though we officially haven't dropped Perl 5.8 support, the
+ Getopt::Long package that came with it does not support "--no-"
+ prefix to negate a boolean option; manually add support to help
+ people with older Getopt::Long package.
+
+Also contains typofixes, documentation updates and trivial code clean-ups.
diff --git a/RelNotes/2.3.3.adoc b/RelNotes/2.3.3.adoc
new file mode 100644
index 0000000..850dc68
--- /dev/null
+++ b/RelNotes/2.3.3.adoc
@@ -0,0 +1,39 @@
+Git v2.3.3 Release Notes
+========================
+
+Fixes since v2.3.2
+------------------
+
+ * A corrupt input to "git diff -M" used cause us to segfault.
+
+ * The borrowed code in kwset API did not follow our usual convention
+ to use "unsigned char" to store values that range from 0-255.
+
+ * Description given by "grep -h" for its --exclude-standard option
+ was phrased poorly.
+
+ * Documentation for "git remote add" mentioned "--tags" and
+ "--no-tags" and it was not clear that fetch from the remote in
+ the future will use the default behaviour when neither is given
+ to override it.
+
+ * "git diff --shortstat --dirstat=changes" showed a dirstat based on
+ lines that was never asked by the end user in addition to the
+ dirstat that the user asked for.
+
+ * The interaction between "git submodule update" and the
+ submodule.*.update configuration was not clearly documented.
+
+ * "git apply" was not very careful about reading from, removing,
+ updating and creating paths outside the working tree (under
+ --index/--cached) or the current directory (when used as a
+ replacement for GNU patch).
+
+ * "git daemon" looked up the hostname even when "%CH" and "%IP"
+ interpolations are not requested, which was unnecessary.
+
+ * The "interpolated-path" option of "git daemon" inserted any string
+ client declared on the "host=" capability request without checking.
+ Sanitize and limit %H and %CH to a saner and a valid DNS name.
+
+Also contains typofixes, documentation updates and trivial code clean-ups.
diff --git a/RelNotes/2.3.4.adoc b/RelNotes/2.3.4.adoc
new file mode 100644
index 0000000..094c7b8
--- /dev/null
+++ b/RelNotes/2.3.4.adoc
@@ -0,0 +1,32 @@
+Git v2.3.4 Release Notes
+========================
+
+Fixes since v2.3.3
+------------------
+
+ * The 'color.status.unmerged' configuration was not described.
+
+ * "git log --decorate" did not reset colors correctly around the
+ branch names.
+
+ * "git -C '' subcmd" refused to work in the current directory, unlike
+ "cd ''" which silently behaves as a no-op.
+
+ * "git imap-send" learned to optionally talk with an IMAP server via
+ libcURL; because there is no other option when Git is built with
+ NO_OPENSSL option, use that codepath by default under such
+ configuration.
+
+ * A workaround for certain build of GPG that triggered false breakage
+ in a test has been added.
+
+ * "git rebase -i" recently started to include the number of
+ commits in the insn sheet to be processed, but on a platform
+ that prepends leading whitespaces to "wc -l" output, the numbers
+ are shown with extra whitespaces that aren't necessary.
+
+ * We did not parse username followed by literal IPv6 address in SSH
+ transport URLs, e.g. ssh://user@[2001:db8::1]:22/repo.git
+ correctly.
+
+Also contains typofixes, documentation updates and trivial code clean-ups.
diff --git a/RelNotes/2.3.5.adoc b/RelNotes/2.3.5.adoc
new file mode 100644
index 0000000..5b309db
--- /dev/null
+++ b/RelNotes/2.3.5.adoc
@@ -0,0 +1,44 @@
+Git v2.3.5 Release Notes
+========================
+
+Fixes since v2.3.4
+------------------
+
+ * The prompt script (in contrib/) did not show the untracked sign
+ when working in a subdirectory without any untracked files.
+
+ * Even though "git grep --quiet" is run merely to ask for the exit
+ status, we spawned the pager regardless. Stop doing that.
+
+ * Recommend format-patch and send-email for those who want to submit
+ patches to this project.
+
+ * An failure early in the "git clone" that started creating the
+ working tree and repository could have resulted in some directories
+ and files left without getting cleaned up.
+
+ * "git fetch" that fetches a commit using the allow-tip-sha1-in-want
+ extension could have failed to fetch all the requested refs.
+
+ * The split-index mode introduced at v2.3.0-rc0~41 was broken in the
+ codepath to protect us against a broken reimplementation of Git
+ that writes an invalid index with duplicated index entries, etc.
+
+ * "git prune" used to largely ignore broken refs when deciding which
+ objects are still being used, which could spread an existing small
+ damage and make it a larger one.
+
+ * "git tag -h" used to show the "--column" and "--sort" options
+ that are about listing in a wrong section.
+
+ * The transfer.hiderefs support did not quite work for smart-http
+ transport.
+
+ * The code that reads from the ctags file in the completion script
+ (in contrib/) did not spell ${param/pattern/string} substitution
+ correctly, which happened to work with bash but not with zsh.
+
+ * The explanation on "rebase --preserve-merges", "pull --rebase=preserve",
+ and "push --force-with-lease" in the documentation was unclear.
+
+Also contains typofixes, documentation updates and trivial code clean-ups.
diff --git a/RelNotes/2.3.6.adoc b/RelNotes/2.3.6.adoc
new file mode 100644
index 0000000..432f770
--- /dev/null
+++ b/RelNotes/2.3.6.adoc
@@ -0,0 +1,13 @@
+Git v2.3.6 Release Notes
+========================
+
+Fixes since v2.3.5
+------------------
+
+ * "diff-highlight" (in contrib/) used to show byte-by-byte
+ differences, which meant that multi-byte characters can be chopped
+ in the middle. It learned to pay attention to character boundaries
+ (assuming the UTF-8 payload).
+
+Also contains typofixes, documentation updates and trivial code
+clean-ups.
diff --git a/RelNotes/2.3.7.adoc b/RelNotes/2.3.7.adoc
new file mode 100644
index 0000000..5769184
--- /dev/null
+++ b/RelNotes/2.3.7.adoc
@@ -0,0 +1,21 @@
+Git v2.3.7 Release Notes
+========================
+
+Fixes since v2.3.6
+------------------
+
+ * An earlier update to the parser that dissects a URL broke an
+ address, followed by a colon, followed by an empty string (instead
+ of the port number), e.g. ssh://example.com:/path/to/repo.
+
+ * The completion script (in contrib/) contaminated global namespace
+ and clobbered on a shell variable $x.
+
+ * The "git push --signed" protocol extension did not limit what the
+ "nonce" that is a server-chosen string can contain or how long it
+ can be, which was unnecessarily lax. Limit both the length and the
+ alphabet to a reasonably small space that can still have enough
+ entropy.
+
+Also contains typofixes, documentation updates and trivial code
+clean-ups.
diff --git a/RelNotes/2.3.8.adoc b/RelNotes/2.3.8.adoc
new file mode 100644
index 0000000..0b67268
--- /dev/null
+++ b/RelNotes/2.3.8.adoc
@@ -0,0 +1,22 @@
+Git v2.3.8 Release Notes
+========================
+
+Fixes since v2.3.7
+------------------
+
+ * The usual "git diff" when seeing a file turning into a directory
+ showed a patchset to remove the file and create all files in the
+ directory, but "git diff --no-index" simply refused to work. Also,
+ when asked to compare a file and a directory, imitate POSIX "diff"
+ and compare the file with the file with the same name in the
+ directory, instead of refusing to run.
+
+ * The default $HOME/.gitconfig file created upon "git config --global"
+ that edits it had incorrectly spelled user.name and user.email
+ entries in it.
+
+ * "git commit --date=now" or anything that relies on approxidate lost
+ the daylight-saving-time offset.
+
+Also contains typofixes, documentation updates and trivial code
+clean-ups.
diff --git a/RelNotes/2.3.9.adoc b/RelNotes/2.3.9.adoc
new file mode 100644
index 0000000..1a2ad32
--- /dev/null
+++ b/RelNotes/2.3.9.adoc
@@ -0,0 +1,9 @@
+Git v2.3.9 Release Notes
+========================
+
+Fixes since v2.3.8
+------------------
+
+ * A handful of codepaths that used to use fixed-sized arrays to hold
+ pathnames have been corrected to use strbuf and other mechanisms to
+ allow longer pathnames without fearing overflows.
diff --git a/RelNotes/2.30.0.adoc b/RelNotes/2.30.0.adoc
new file mode 100644
index 0000000..c2f1dc7
--- /dev/null
+++ b/RelNotes/2.30.0.adoc
@@ -0,0 +1,401 @@
+Git 2.30 Release Notes
+======================
+
+Updates since v2.29
+-------------------
+
+UI, Workflows & Features
+
+ * Userdiff for PHP update.
+
+ * Userdiff for Rust update.
+
+ * Userdiff for CSS update.
+
+ * The command line completion script (in contrib/) learned that "git
+ stash show" takes the options "git diff" takes.
+
+ * "git worktree list" now shows if each worktree is locked. This
+ possibly may open us to show other kinds of states in the future.
+
+ * "git maintenance", an extended big brother of "git gc", continues
+ to evolve.
+
+ * "git push --force-with-lease[=<ref>]" can easily be misused to lose
+ commits unless the user takes good care of their own "git fetch".
+ A new option "--force-if-includes" attempts to ensure that what is
+ being force-pushed was created after examining the commit at the
+ tip of the remote ref that is about to be force-replaced.
+
+ * "git clone" learned clone.defaultremotename configuration variable
+ to customize what nickname to use to call the remote the repository
+ was cloned from.
+
+ * "git checkout" learned to use checkout.guess configuration variable
+ and enable/disable its "--[no-]guess" option accordingly.
+
+ * "git resurrect" script (in contrib/) learned that the object names
+ may be longer than 40-hex depending on the hash function in use.
+
+ * "git diff A...B" learned "git diff --merge-base A B", which is a
+ longer short-hand to say the same thing.
+
+ * A sample 'push-to-checkout' hook, that performs the same as
+ what the built-in default action does, has been added.
+
+ * "git diff" family of commands learned the "-I<regex>" option to
+ ignore hunks whose changed lines all match the given pattern.
+
+ * The userdiff pattern learned to identify the function definition in
+ POSIX shells and bash.
+
+ * "git checkout-index" did not consistently signal an error with its
+ exit status, but now it does.
+
+ * A commit and tag object may have CR at the end of each and
+ every line (you can create such an object with hash-object or
+ using --cleanup=verbatim to decline the default clean-up
+ action), but it would make it impossible to have a blank line
+ to separate the title from the body of the message. We are now
+ more lenient and accept a line with lone CR on it as a blank line,
+ too.
+
+ * Exit codes from "git remote add" etc. were not usable by scripted
+ callers, but now they are.
+
+ * "git archive" now allows compression level higher than "-9"
+ when generating tar.gz output.
+
+ * Zsh autocompletion (in contrib/) update.
+
+ * The maximum length of output filenames "git format-patch" creates
+ has become configurable (used to be capped at 64).
+
+ * "git rev-parse" learned the "--end-of-options" to help scripts to
+ safely take a parameter that is supposed to be a revision, e.g.
+ "git rev-parse --verify -q --end-of-options $rev".
+
+ * The command line completion script (in contrib/) learned to expand
+ commands that are alias of alias.
+
+ * "git update-ref --stdin" learns to take multiple transactions in a
+ single session.
+
+ * Various subcommands of "git config" that take value_regex
+ learned the "--literal-value" option to take the value_regex option
+ as a literal string.
+
+ * The transport layer was taught to optionally exchange the session
+ ID assigned by the trace2 subsystem during fetch/push transactions.
+
+ * "git imap-send" used to ignore configuration variables like
+ core.askpass; this has been corrected.
+
+ * "git $cmd $args", when $cmd is not a recognised subcommand, by
+ default tries to see if $cmd is a typo of an existing subcommand
+ and optionally executes the corrected command if there is only one
+ possibility, depending on the setting of help.autocorrect; the
+ users can now disable the whole thing, including the cycles spent
+ to find a likely typo, by setting the configuration variable to
+ 'never'.
+
+ * "@" sometimes worked (e.g. "git push origin @:there") as a part of
+ a refspec element, but "git push origin @" did not work, which has
+ been corrected.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * Use "git archive" more to produce the release tarball.
+
+ * GitHub Actions automated test improvement to skip tests on a tree
+ identical to what has already been tested.
+
+ * Test-coverage for running commit-graph task "git maintenance" has
+ been extended.
+
+ * Our test scripts can be told to run only individual pieces while
+ skipping others with the "--run=..." option; they were taught to
+ take a substring of test title, in addition to numbers, to name the
+ test pieces to run.
+
+ * Adjust tests so that they won't scream when the default initial
+ branch name is different from 'master'.
+
+ * Rewriting "git bisect" in C continues.
+
+ * More preliminary tests have been added to document desired outcomes
+ of various "directory rename" situations.
+
+ * Micro clean-up of a couple of test scripts.
+
+ * "git diff" and other commands that share the same machinery to
+ compare with working tree files have been taught to take advantage
+ of the fsmonitor data when available.
+
+ * The code to detect premature EOF in the sideband demultiplexer has
+ been cleaned up.
+
+ * "git fetch --depth=<n>" over the stateless RPC / smart HTTP
+ transport handled EOF from the client poorly at the server end.
+
+ * A specialization of hashmap that uses a string as key has been
+ introduced. Hopefully it will see wider use over time.
+
+ * "git bisect start/next" in a large span of history spends a lot of
+ time trying to come up with exactly the half-way point; this can be
+ optimized by stopping when we see a commit that is close enough to
+ the half-way point.
+
+ * A lazily defined test prerequisite can now be defined in terms of
+ another lazily defined test prerequisite.
+
+ * Expectation for the original contributor after responding to a
+ review comment to use the explanation in a patch update has been
+ described.
+
+ * Multiple "credential-store" backends can race to lock the same
+ file, causing everybody else but one to fail---reattempt locking
+ with some timeout to reduce the rate of the failure.
+
+ * "git-parse-remote" shell script library outlived its usefulness.
+
+ * Like die() and error(), a call to warning() will also trigger a
+ trace2 event.
+
+ * Use of non-reentrant localtime() has been removed.
+
+ * Non-reentrant time-related library functions and ctime/asctime with
+ awkward calling interfaces are banned from the codebase.
+
+
+Fixes since v2.29
+-----------------
+
+ * In 2.29, "--committer-date-is-author-date" option of "rebase" and
+ "am" subcommands lost the e-mail address by mistake, which has been
+ corrected.
+ (merge 5f35edd9d7 jk/committer-date-is-author-date-fix later to maint).
+
+ * "git checkout -p A...B [-- <path>]" did not work, even though the
+ same command without "-p" correctly used the merge-base between
+ commits A and B.
+ (merge 35166b1fb5 dl/checkout-p-merge-base later to maint).
+
+ * The side-band status report can be sent at the same time as the
+ primary payload multiplexed, but the demultiplexer on the receiving
+ end incorrectly split a single status report into two, which has
+ been corrected.
+ (merge 712b0377db js/avoid-split-sideband-message later to maint).
+
+ * "git fast-import" wasted a lot of memory when many marks were in use.
+ (merge 3f018ec716 jk/fast-import-marks-alloc-fix later to maint).
+
+ * A test helper "test_cmp A B" was taught to diagnose missing files A
+ or B as a bug in test, but some tests legitimately wanted to notice
+ a failure to even create file B as an error, in addition to leaving
+ the expected result in it, and were misdiagnosed as a bug. This
+ has been corrected.
+ (merge 262d5ad5a5 es/test-cmp-typocatcher later to maint).
+
+ * When "git commit-graph" detects the same commit recorded more than
+ once while it is merging the layers, it used to die. The code now
+ ignores all but one of them and continues.
+ (merge 85102ac71b ds/commit-graph-merging-fix later to maint).
+
+ * The meaning of a Signed-off-by trailer can vary from project to
+ project; this and also what it means to this project has been
+ clarified in the documentation.
+ (merge 3abd4a67d9 bk/sob-dco later to maint).
+
+ * "git credential' didn't honor the core.askPass configuration
+ variable (among other things), which has been corrected.
+ (merge 567ad2c0f9 tk/credential-config later to maint).
+
+ * Dev support to catch a tentative definition of a variable in our C
+ code as an error.
+ (merge 5539183622 jk/no-common later to maint).
+
+ * "git rebase --rebase-merges" did not correctly pass --gpg-sign
+ command line option to underlying "git merge" when replaying a merge
+ using non-default merge strategy or when replaying an octopus merge
+ (because replaying a two-head merge with the default strategy was
+ done in a separate codepath, the problem did not trigger for most
+ users), which has been corrected.
+ (merge 43ad4f2eca sc/sequencer-gpg-octopus later to maint).
+
+ * "git apply -R" did not handle patches that touch the same path
+ twice correctly, which has been corrected. This is most relevant
+ in a patch that changes a path from a regular file to a symbolic
+ link (and vice versa).
+ (merge b0f266de11 jt/apply-reverse-twice later to maint).
+
+ * A recent oid->hash conversion missed one spot, breaking "git svn".
+ (merge 03bb366de4 bc/svn-hash-oid-fix later to maint).
+
+ * The documentation on the "--abbrev=<n>" option did not say the
+ output may be longer than "<n>" hexdigits, which has been
+ clarified.
+ (merge cda34e0d0c jc/abbrev-doc later to maint).
+
+ * "git p4" now honors init.defaultBranch configuration.
+ (merge 1b09d1917f js/p4-default-branch later to maint).
+
+ * Recently the format of an internal state file "rebase -i" uses has
+ been tightened up for consistency, which would hurt those who start
+ "rebase -i" with old git and then continue with new git. Loosen
+ the reader side a bit (which we may want to tighten again in a year
+ or so).
+ (merge c779386182 jc/sequencer-stopped-sha-simplify later to maint).
+
+ * The code to see if "git stash drop" can safely remove refs/stash
+ has been made more careful.
+ (merge 4f44c5659b rs/empty-reflog-check-fix later to maint).
+
+ * "git log -L<range>:<path>" is documented to take no pathspec, but
+ this was not enforced by the command line option parser, which has
+ been corrected.
+ (merge 39664cb0ac jc/line-log-takes-no-pathspec later to maint).
+
+ * "git format-patch --output=there" did not work as expected and
+ instead crashed. The option is now supported.
+ (merge dc1672dd10 jk/format-patch-output later to maint).
+
+ * Define ARM64 compiled with MSVC to be little-endian.
+ (merge 0c038fc65a dg/bswap-msvc later to maint).
+
+ * "git rebase -i" did not store ORIG_HEAD correctly.
+ (merge 8843302307 pw/rebase-i-orig-head later to maint).
+
+ * "git blame -L :funcname -- path" did not work well for a path for
+ which a userdiff driver is defined.
+
+ * "make DEVELOPER=1 sparse" used to run sparse and let it emit
+ warnings; now such warnings will cause an error.
+ (merge 521dc56270 jc/sparse-error-for-developer-build later to maint).
+
+ * "git blame --ignore-revs-file=<file>" learned to ignore a
+ non-existent object name in the input, instead of complaining.
+ (merge c714d05875 jc/blame-ignore-fix later to maint).
+
+ * Running "git diff" while allowing external diff in a state with
+ unmerged paths used to segfault, which has been corrected.
+ (merge d66851806f jk/diff-release-filespec-fix later to maint).
+
+ * Build configuration cleanup.
+ (merge b990f02fd8 ab/config-mak-uname-simplify later to maint).
+
+ * Fix regression introduced when nvimdiff support in mergetool was added.
+ (merge 12026f46e7 pd/mergetool-nvimdiff later to maint).
+
+ * The exchange between receive-pack and proc-receive hook did not
+ carefully check for errors.
+
+ * The code was not prepared to deal with pack .idx file that is
+ larger than 4GB.
+ (merge 81c4c5cf2e jk/4gb-idx later to maint).
+
+ * Since jgit does not yet work with SHA-256 repositories, mark the
+ tests that use it not to run unless we are testing with ShA-1
+ repositories.
+ (merge ea699b4adc sg/t5310-jgit-wants-sha1 later to maint).
+
+ * Config parser fix for "git notes".
+ (merge 45fef1599a na/notes-displayref-is-not-boolean later to maint).
+
+ * Move a definition of compatibility wrapper from cache.h to
+ git-compat-util.h
+ (merge a76b138daa hn/sleep-millisec-decl later to maint).
+
+ * Error message fix.
+ (merge eaf5341538 km/stash-error-message-fix later to maint).
+
+ * "git pull --rebase --recurse-submodules" checked for local changes
+ in a wrong range and failed to run correctly when it should.
+ (merge 5176f20ffe pb/pull-rebase-recurse-submodules later to maint).
+
+ * "git push" that is killed may leave a pack-objects process behind,
+ still computing to find a good compression, wasting cycles. This
+ has been corrected.
+ (merge 8b59935114 jk/stop-pack-objects-when-push-is-killed later to maint).
+
+ * "git fetch" that is killed may leave a pack-objects process behind,
+ still computing to find a good compression, wasting cycles. This
+ has been corrected.
+ (merge 309a4028e7 jk/stop-pack-objects-when-fetch-is-killed later to maint).
+
+ * "git add -i" failed to honor custom colors configured to show
+ patches, which has been corrected.
+ (merge 96386faa03 js/add-i-color-fix later to maint).
+
+ * Processes that access packdata while the .idx file gets removed
+ (e.g. while repacking) did not fail or fall back gracefully as they
+ could.
+ (merge 506ec2fbda tb/idx-midx-race-fix later to maint).
+
+ * "git apply" adjusted the permission bits of working-tree files and
+ directories according to core.sharedRepository setting by mistake and
+ for a long time, which has been corrected.
+ (merge eb3c027e17 mt/do-not-use-scld-in-working-tree later to maint).
+
+ * "fetch-pack" could pass NULL pointer to unlink(2) when it sees an
+ invalid filename; the error checking has been tightened to make
+ this impossible.
+ (merge 6031af387e rs/fetch-pack-invalid-lockfile later to maint).
+
+ * "git maintenance run/start/stop" needed to be run in a repository
+ to hold the lockfile they use, but didn't make sure they are
+ actually in a repository, which has been corrected.
+
+ * The glossary described a branch as an "active" line of development,
+ which is misleading---a stale and non-moving branch is still a
+ branch.
+ (merge eef1ceabd8 so/glossary-branch-is-not-necessarily-active later to maint).
+
+ * Newer versions of xsltproc can assign IDs in HTML documents it
+ generates in a consistent manner. Use the feature to help format
+ HTML version of the user manual reproducibly.
+ (merge 3569e11d69 ae/doc-reproducible-html later to maint).
+
+ * Tighten error checking in the codepath that responds to "git fetch".
+ (merge d43a21bdbb jk/check-config-parsing-error-in-upload-pack later to maint).
+
+ * "git pack-redundant" when there is only one packfile used to crash,
+ which has been corrected.
+ (merge 0696232390 jx/pack-redundant-on-single-pack later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge 3e0a5dc9af cc/doc-filter-branch-typofix later to maint).
+ (merge 32c83afc2c cw/ci-ghwf-check-ws-errors later to maint).
+ (merge 5eb2ed691b rs/tighten-callers-of-deref-tag later to maint).
+ (merge 6db29ab213 jk/fast-import-marks-cleanup later to maint).
+ (merge e5cf6d3df4 nk/dir-c-comment-update later to maint).
+ (merge 5710dcce74 jk/report-fn-typedef later to maint).
+ (merge 9a82db1056 en/sequencer-rollback-lock-cleanup later to maint).
+ (merge 4e1bee9a99 js/t7006-cleanup later to maint).
+ (merge f5bcde6c58 es/tutorial-mention-asciidoc-early later to maint).
+ (merge 714d491af0 so/format-patch-doc-on-default-diff-format later to maint).
+ (merge 0795df4b9b rs/clear-commit-marks-in-repo later to maint).
+ (merge 9542d56379 sd/prompt-local-variable later to maint).
+ (merge 06d43fad18 rs/pack-write-hashwrite-simplify later to maint).
+ (merge b7e20b4373 mc/typofix later to maint).
+ (merge f6bcd9a8a4 js/test-whitespace-fixes later to maint).
+ (merge 53b67a801b js/test-file-size later to maint).
+ (merge 970909c2a7 rs/hashwrite-be64 later to maint).
+ (merge 5a923bb1f0 ma/list-object-filter-opt-msgfix later to maint).
+ (merge 1c3e412916 rs/archive-plug-leak-refname later to maint).
+ (merge d44e5267ea rs/plug-diff-cache-leak later to maint).
+ (merge 793c1464d3 ab/gc-keep-base-option later to maint).
+ (merge b86339b12b mt/worktree-error-message-fix later to maint).
+ (merge e01ae2a4a7 js/pull-rebase-use-advise later to maint).
+ (merge e63d774242 sn/config-doc-typofix later to maint).
+ (merge 08e9df2395 jk/multi-line-indent-style-fix later to maint).
+ (merge e66590348a da/vs-build-iconv-fix later to maint).
+ (merge 7fe07275be js/cmake-extra-built-ins-fix later to maint).
+ (merge 633eebe142 jb/midx-doc-update later to maint).
+ (merge 5885367e8f jh/index-v2-doc-on-fsmn later to maint).
+ (merge 14639a4779 jc/compat-util-setitimer-fix later to maint).
+ (merge 56f56ac50b ab/unreachable-break later to maint).
+ (merge 731d578b4f rb/nonstop-config-mak-uname-update later to maint).
+ (merge f4698738f9 es/perf-export-fix later to maint).
+ (merge 773c694142 nk/refspecs-negative-fix later to maint).
diff --git a/RelNotes/2.30.1.adoc b/RelNotes/2.30.1.adoc
new file mode 100644
index 0000000..249ef14
--- /dev/null
+++ b/RelNotes/2.30.1.adoc
@@ -0,0 +1,55 @@
+Git v2.30.1 Release Notes
+=========================
+
+This release is primarily to merge fixes accumulated on the 'master'
+front to prepare for 2.31 release that are still relevant to 2.30.x
+maintenance track.
+
+Fixes since v2.30
+-----------------
+
+ * "git fetch --recurse-submodules" failed to update a submodule
+ when it has an uninitialized (hence of no interest to the user)
+ sub-submodule, which has been corrected.
+
+ * Command line error of "git rebase" are diagnosed earlier.
+
+ * "git stash" did not work well in a sparsely checked out working
+ tree.
+
+ * Some tests expect that "ls -l" output has either '-' or 'x' for
+ group executable bit, but setgid bit can be inherited from parent
+ directory and make these fields 'S' or 's' instead, causing test
+ failures.
+
+ * "git for-each-repo --config=<var> <cmd>" should not run <cmd> for
+ any repository when the configuration variable <var> is not defined
+ even once.
+
+ * "git mergetool --tool-help" was broken in 2.29 and failed to list
+ all the available tools.
+
+ * Fix for procedure to building CI test environment for mac.
+
+ * Newline characters in the host and path part of git:// URL are
+ now forbidden.
+
+ * When more than one commit with the same patch ID appears on one
+ side, "git log --cherry-pick A...B" did not exclude them all when a
+ commit with the same patch ID appears on the other side. Now it
+ does.
+
+ * Documentation for "git fsck" lost stale bits that has become
+ incorrect.
+
+ * Doc for packfile URI feature has been clarified.
+
+ * The implementation of "git branch --sort" wrt the detached HEAD
+ display has always been hacky, which has been cleaned up.
+
+ * Our setting of GitHub CI test jobs were a bit too eager to give up
+ once there is even one failure found. Tweak the knob to allow
+ other jobs keep running even when we see a failure, so that we can
+ find more failures in a single run.
+
+Also contains minor documentation updates and code clean-ups.
diff --git a/RelNotes/2.30.2.adoc b/RelNotes/2.30.2.adoc
new file mode 100644
index 0000000..bada398
--- /dev/null
+++ b/RelNotes/2.30.2.adoc
@@ -0,0 +1,8 @@
+Git v2.30.2 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.17.6, v2.18.5,
+v2.19.6, v2.20.5, v2.21.4, v2.22.5, v2.23.4, v2.24.4, v2.25.5,
+v2.26.3, v2.27.1, v2.28.1 and v2.29.3 to address the security
+issue CVE-2021-21300; see the release notes for these versions
+for details.
diff --git a/RelNotes/2.30.3.adoc b/RelNotes/2.30.3.adoc
new file mode 100644
index 0000000..31b2a4d
--- /dev/null
+++ b/RelNotes/2.30.3.adoc
@@ -0,0 +1,24 @@
+Git v2.30.2 Release Notes
+=========================
+
+This release addresses the security issue CVE-2022-24765.
+
+Fixes since v2.30.2
+-------------------
+
+ * Build fix on Windows.
+
+ * Fix `GIT_CEILING_DIRECTORIES` with Windows-style root directories.
+
+ * CVE-2022-24765:
+ On multi-user machines, Git users might find themselves
+ unexpectedly in a Git worktree, e.g. when another user created a
+ repository in `C:\.git`, in a mounted network drive or in a
+ scratch space. Merely having a Git-aware prompt that runs `git
+ status` (or `git diff`) and navigating to a directory which is
+ supposedly not a Git worktree, or opening such a directory in an
+ editor or IDE such as VS Code or Atom, will potentially run
+ commands defined by that other user.
+
+Credit for finding this vulnerability goes to 俞晨东; The fix was
+authored by Johannes Schindelin.
diff --git a/RelNotes/2.30.4.adoc b/RelNotes/2.30.4.adoc
new file mode 100644
index 0000000..4eedb74
--- /dev/null
+++ b/RelNotes/2.30.4.adoc
@@ -0,0 +1,21 @@
+Git v2.30.4 Release Notes
+=========================
+
+This release contains minor fix-ups for the changes that went into
+Git 2.30.3, which was made to address CVE-2022-24765.
+
+ * The code that was meant to parse the new `safe.directory`
+ configuration variable was not checking what configuration
+ variable was being fed to it, which has been corrected.
+
+ * '*' can be used as the value for the `safe.directory` variable to
+ signal that the user considers that any directory is safe.
+
+
+
+Derrick Stolee (2):
+ t0033: add tests for safe.directory
+ setup: opt-out of check with safe.directory=*
+
+Matheus Valadares (1):
+ setup: fix safe.directory key not being checked
diff --git a/RelNotes/2.30.5.adoc b/RelNotes/2.30.5.adoc
new file mode 100644
index 0000000..5191cab
--- /dev/null
+++ b/RelNotes/2.30.5.adoc
@@ -0,0 +1,12 @@
+Git v2.30.5 Release Notes
+=========================
+
+This release contains minor fix-ups for the changes that went into
+Git 2.30.3 and 2.30.4, addressing CVE-2022-29187.
+
+ * The safety check that verifies a safe ownership of the Git
+ worktree is now extended to also cover the ownership of the Git
+ directory (and the `.git` file, if there is any).
+
+Carlo Marcelo Arenas Belón (1):
+ setup: tighten ownership checks post CVE-2022-24765
diff --git a/RelNotes/2.30.6.adoc b/RelNotes/2.30.6.adoc
new file mode 100644
index 0000000..d649071
--- /dev/null
+++ b/RelNotes/2.30.6.adoc
@@ -0,0 +1,60 @@
+Git v2.30.6 Release Notes
+=========================
+
+This release addresses the security issues CVE-2022-39253 and
+CVE-2022-39260.
+
+Fixes since v2.30.5
+-------------------
+
+ * CVE-2022-39253:
+ When relying on the `--local` clone optimization, Git dereferences
+ symbolic links in the source repository before creating hardlinks
+ (or copies) of the dereferenced link in the destination repository.
+ This can lead to surprising behavior where arbitrary files are
+ present in a repository's `$GIT_DIR` when cloning from a malicious
+ repository.
+
+ Git will no longer dereference symbolic links via the `--local`
+ clone mechanism, and will instead refuse to clone repositories that
+ have symbolic links present in the `$GIT_DIR/objects` directory.
+
+ Additionally, the value of `protocol.file.allow` is changed to be
+ "user" by default.
+
+ * CVE-2022-39260:
+ An overly-long command string given to `git shell` can result in
+ overflow in `split_cmdline()`, leading to arbitrary heap writes and
+ remote code execution when `git shell` is exposed and the directory
+ `$HOME/git-shell-commands` exists.
+
+ `git shell` is taught to refuse interactive commands that are
+ longer than 4MiB in size. `split_cmdline()` is hardened to reject
+ inputs larger than 2GiB.
+
+Credit for finding CVE-2022-39253 goes to Cory Snider of Mirantis. The
+fix was authored by Taylor Blau, with help from Johannes Schindelin.
+
+Credit for finding CVE-2022-39260 goes to Kevin Backhouse of GitHub.
+The fix was authored by Kevin Backhouse, Jeff King, and Taylor Blau.
+
+
+Jeff King (2):
+ shell: add basic tests
+ shell: limit size of interactive commands
+
+Kevin Backhouse (1):
+ alias.c: reject too-long cmdline strings in split_cmdline()
+
+Taylor Blau (11):
+ builtin/clone.c: disallow `--local` clones with symlinks
+ t/lib-submodule-update.sh: allow local submodules
+ t/t1NNN: allow local submodules
+ t/2NNNN: allow local submodules
+ t/t3NNN: allow local submodules
+ t/t4NNN: allow local submodules
+ t/t5NNN: allow local submodules
+ t/t6NNN: allow local submodules
+ t/t7NNN: allow local submodules
+ t/t9NNN: allow local submodules
+ transport: make `protocol.file.allow` be "user" by default
diff --git a/RelNotes/2.30.7.adoc b/RelNotes/2.30.7.adoc
new file mode 100644
index 0000000..285beed
--- /dev/null
+++ b/RelNotes/2.30.7.adoc
@@ -0,0 +1,86 @@
+Git v2.30.7 Release Notes
+=========================
+
+This release addresses the security issues CVE-2022-41903 and
+CVE-2022-23521.
+
+
+Fixes since v2.30.6
+-------------------
+
+ * CVE-2022-41903:
+
+ git log has the ability to display commits using an arbitrary
+ format with its --format specifiers. This functionality is also
+ exposed to git archive via the export-subst gitattribute.
+
+ When processing the padding operators (e.g., %<(, %<|(, %>(,
+ %>>(, or %><( ), an integer overflow can occur in
+ pretty.c::format_and_pad_commit() where a size_t is improperly
+ stored as an int, and then added as an offset to a subsequent
+ memcpy() call.
+
+ This overflow can be triggered directly by a user running a
+ command which invokes the commit formatting machinery (e.g., git
+ log --format=...). It may also be triggered indirectly through
+ git archive via the export-subst mechanism, which expands format
+ specifiers inside of files within the repository during a git
+ archive.
+
+ This integer overflow can result in arbitrary heap writes, which
+ may result in remote code execution.
+
+* CVE-2022-23521:
+
+ gitattributes are a mechanism to allow defining attributes for
+ paths. These attributes can be defined by adding a `.gitattributes`
+ file to the repository, which contains a set of file patterns and
+ the attributes that should be set for paths matching this pattern.
+
+ When parsing gitattributes, multiple integer overflows can occur
+ when there is a huge number of path patterns, a huge number of
+ attributes for a single pattern, or when the declared attribute
+ names are huge.
+
+ These overflows can be triggered via a crafted `.gitattributes` file
+ that may be part of the commit history. Git silently splits lines
+ longer than 2KB when parsing gitattributes from a file, but not when
+ parsing them from the index. Consequentially, the failure mode
+ depends on whether the file exists in the working tree, the index or
+ both.
+
+ This integer overflow can result in arbitrary heap reads and writes,
+ which may result in remote code execution.
+
+Credit for finding CVE-2022-41903 goes to Joern Schneeweisz of GitLab.
+An initial fix was authored by Markus Vervier of X41 D-Sec. Credit for
+finding CVE-2022-23521 goes to Markus Vervier and Eric Sesterhenn of X41
+D-Sec. This work was sponsored by OSTIF.
+
+The proposed fixes have been polished and extended to cover additional
+findings by Patrick Steinhardt of GitLab, with help from others on the
+Git security mailing list.
+
+Patrick Steinhardt (21):
+ attr: fix overflow when upserting attribute with overly long name
+ attr: fix out-of-bounds read with huge attribute names
+ attr: fix integer overflow when parsing huge attribute names
+ attr: fix out-of-bounds write when parsing huge number of attributes
+ attr: fix out-of-bounds read with unreasonable amount of patterns
+ attr: fix integer overflow with more than INT_MAX macros
+ attr: harden allocation against integer overflows
+ attr: fix silently splitting up lines longer than 2048 bytes
+ attr: ignore attribute lines exceeding 2048 bytes
+ attr: ignore overly large gitattributes files
+ pretty: fix out-of-bounds write caused by integer overflow
+ pretty: fix out-of-bounds read when left-flushing with stealing
+ pretty: fix out-of-bounds read when parsing invalid padding format
+ pretty: fix adding linefeed when placeholder is not expanded
+ pretty: fix integer overflow in wrapping format
+ utf8: fix truncated string lengths in `utf8_strnwidth()`
+ utf8: fix returning negative string width
+ utf8: fix overflow when returning string width
+ utf8: fix checking for glyph width in `strbuf_utf8_replace()`
+ utf8: refactor `strbuf_utf8_replace` to not rely on preallocated buffer
+ pretty: restrict input lengths for padding and wrapping formats
+
diff --git a/RelNotes/2.30.8.adoc b/RelNotes/2.30.8.adoc
new file mode 100644
index 0000000..5ed3efb
--- /dev/null
+++ b/RelNotes/2.30.8.adoc
@@ -0,0 +1,51 @@
+Git v2.30.8 Release Notes
+=========================
+
+This release addresses the security issues CVE-2023-22490 and
+CVE-2023-23946.
+
+
+Fixes since v2.30.7
+-------------------
+
+ * CVE-2023-22490:
+
+ Using a specially-crafted repository, Git can be tricked into using
+ its local clone optimization even when using a non-local transport.
+ Though Git will abort local clones whose source $GIT_DIR/objects
+ directory contains symbolic links (c.f., CVE-2022-39253), the objects
+ directory itself may still be a symbolic link.
+
+ These two may be combined to include arbitrary files based on known
+ paths on the victim's filesystem within the malicious repository's
+ working copy, allowing for data exfiltration in a similar manner as
+ CVE-2022-39253.
+
+ * CVE-2023-23946:
+
+ By feeding a crafted input to "git apply", a path outside the
+ working tree can be overwritten as the user who is running "git
+ apply".
+
+ * A mismatched type in `attr.c::read_attr_from_index()` which could
+ cause Git to errantly reject attributes on Windows and 32-bit Linux
+ has been corrected.
+
+Credit for finding CVE-2023-22490 goes to yvvdwf, and the fix was
+developed by Taylor Blau, with additional help from others on the
+Git security mailing list.
+
+Credit for finding CVE-2023-23946 goes to Joern Schneeweisz, and the
+fix was developed by Patrick Steinhardt.
+
+
+Johannes Schindelin (1):
+ attr: adjust a mismatched data type
+
+Patrick Steinhardt (1):
+ apply: fix writing behind newly created symbolic links
+
+Taylor Blau (3):
+ t5619: demonstrate clone_local() with ambiguous transport
+ clone: delay picking a transport until after get_repo_path()
+ dir-iterator: prevent top-level symlinks without FOLLOW_SYMLINKS
diff --git a/RelNotes/2.30.9.adoc b/RelNotes/2.30.9.adoc
new file mode 100644
index 0000000..708d626
--- /dev/null
+++ b/RelNotes/2.30.9.adoc
@@ -0,0 +1,43 @@
+Git v2.30.9 Release Notes
+=========================
+
+This release addresses the security issues CVE-2023-25652,
+CVE-2023-25815, and CVE-2023-29007.
+
+
+Fixes since v2.30.8
+-------------------
+
+ * CVE-2023-25652:
+
+ By feeding specially crafted input to `git apply --reject`, a
+ path outside the working tree can be overwritten with partially
+ controlled contents (corresponding to the rejected hunk(s) from
+ the given patch).
+
+ * CVE-2023-25815:
+
+ When Git is compiled with runtime prefix support and runs without
+ translated messages, it still used the gettext machinery to
+ display messages, which subsequently potentially looked for
+ translated messages in unexpected places. This allowed for
+ malicious placement of crafted messages.
+
+ * CVE-2023-29007:
+
+ When renaming or deleting a section from a configuration file,
+ certain malicious configuration values may be misinterpreted as
+ the beginning of a new configuration section, leading to arbitrary
+ configuration injection.
+
+Credit for finding CVE-2023-25652 goes to Ry0taK, and the fix was
+developed by Taylor Blau, Junio C Hamano and Johannes Schindelin,
+with the help of Linus Torvalds.
+
+Credit for finding CVE-2023-25815 goes to Maxime Escourbiac and
+Yassine BENGANA of Michelin, and the fix was developed by Johannes
+Schindelin.
+
+Credit for finding CVE-2023-29007 goes to André Baptista and Vítor Pinho
+of Ethiack, and the fix was developed by Taylor Blau, and Johannes
+Schindelin, with help from Jeff King, and Patrick Steinhardt.
diff --git a/RelNotes/2.31.0.adoc b/RelNotes/2.31.0.adoc
new file mode 100644
index 0000000..cf0c7d8
--- /dev/null
+++ b/RelNotes/2.31.0.adoc
@@ -0,0 +1,365 @@
+Git 2.31 Release Notes
+======================
+
+Updates since v2.30
+-------------------
+
+Backward incompatible and other important changes
+
+ * The "pack-redundant" command, which has been left stale with almost
+ unusable performance issues, now warns loudly when it gets used, as
+ we no longer want to recommend its use (instead just "repack -d"
+ instead).
+
+ * The development community has adopted Contributor Covenant v2.0 to
+ update from v1.4 that we have been using.
+
+ * The support for deprecated PCRE1 library has been dropped.
+
+ * Fixes for CVE-2021-21300 in Git 2.30.2 (and earlier) is included.
+
+
+UI, Workflows & Features
+
+ * The "--format=%(trailers)" mechanism gets enhanced to make it
+ easier to design output for machine consumption.
+
+ * When a user does not tell "git pull" to use rebase or merge, the
+ command gives a loud message telling a user to choose between
+ rebase or merge but creates a merge anyway, forcing users who would
+ want to rebase to redo the operation. Fix an early part of this
+ problem by tightening the condition to give the message---there is
+ no reason to stop or force the user to choose between rebase or
+ merge if the history fast-forwards.
+
+ * The configuration variable 'core.abbrev' can be set to 'no' to
+ force no abbreviation regardless of the hash algorithm.
+
+ * "git rev-parse" can be explicitly told to give output as absolute
+ or relative path with the `--path-format=(absolute|relative)` option.
+
+ * Bash completion (in contrib/) update to make it easier for
+ end-users to add completion for their custom "git" subcommands.
+
+ * "git maintenance" learned to drive scheduled maintenance on
+ platforms whose native scheduling methods are not 'cron'.
+
+ * After expiring a reflog and making a single commit, the reflog for
+ the branch would record a single entry that knows both @{0} and
+ @{1}, but we failed to answer "what commit were we on?", i.e. @{1}
+
+ * "git bundle" learns "--stdin" option to read its refs from the
+ standard input. Also, it now does not lose refs whey they point
+ at the same object.
+
+ * "git log" learned a new "--diff-merges=<how>" option.
+
+ * "git ls-files" can and does show multiple entries when the index is
+ unmerged, which is a source for confusion unless -s/-u option is in
+ use. A new option --deduplicate has been introduced.
+
+ * `git worktree list` now annotates worktrees as prunable, shows
+ locked and prunable attributes in --porcelain mode, and gained
+ a --verbose option.
+
+ * "git clone" tries to locally check out the branch pointed at by
+ HEAD of the remote repository after it is done, but the protocol
+ did not convey the information necessary to do so when copying an
+ empty repository. The protocol v2 learned how to do so.
+
+ * There are other ways than ".." for a single token to denote a
+ "commit range", namely "<rev>^!" and "<rev>^-<n>", but "git
+ range-diff" did not understand them.
+
+ * The "git range-diff" command learned "--(left|right)-only" option
+ to show only one side of the compared range.
+
+ * "git mergetool" feeds three versions (base, local and remote) of
+ a conflicted path unmodified. The command learned to optionally
+ prepare these files with unconflicted parts already resolved.
+
+ * The .mailmap is documented to be read only from the root level of a
+ working tree, but a stray file in a bare repository also was read
+ by accident, which has been corrected.
+
+ * "git maintenance" tool learned a new "pack-refs" maintenance task.
+
+ * The error message given when a configuration variable that is
+ expected to have a boolean value has been improved.
+
+ * Signed commits and tags now allow verification of objects, whose
+ two object names (one in SHA-1, the other in SHA-256) are both
+ signed.
+
+ * "git rev-list" command learned "--disk-usage" option.
+
+ * "git {diff,log} --{skip,rotate}-to=<path>" allows the user to
+ discard diff output for early paths or move them to the end of the
+ output.
+
+ * "git difftool" learned "--skip-to=<path>" option to restart an
+ interrupted session from an arbitrary path.
+
+ * "git grep" has been tweaked to be limited to the sparse checkout
+ paths.
+
+ * "git rebase --[no-]fork-point" gained a configuration variable
+ rebase.forkPoint so that users do not have to keep specifying a
+ non-default setting.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * A 3-year old test that was not testing anything useful has been
+ corrected.
+
+ * Retire more names with "sha1" in it.
+
+ * The topological walk codepath is covered by new trace2 stats.
+
+ * Update the Code-of-conduct to version 2.0 from the upstream (we've
+ been using version 1.4).
+
+ * "git mktag" validates its input using its own rules before writing
+ a tag object---it has been updated to share the logic with "git
+ fsck".
+
+ * Two new ways to feed configuration variable-value pairs via
+ environment variables have been introduced, and the way
+ GIT_CONFIG_PARAMETERS encodes variable/value pairs has been tweaked
+ to make it more robust.
+
+ * Tests have been updated so that they do not to get affected by the
+ name of the default branch "git init" creates.
+
+ * "git fetch" learns to treat ref updates atomically in all-or-none
+ fashion, just like "git push" does, with the new "--atomic" option.
+
+ * The peel_ref() API has been replaced with peel_iterated_oid().
+
+ * The .use_shell flag in struct child_process that is passed to
+ run_command() API has been clarified with a bit more documentation.
+
+ * Document, clean-up and optimize the code around the cache-tree
+ extension in the index.
+
+ * The ls-refs protocol operation has been optimized to narrow the
+ sub-hierarchy of refs/ it walks to produce response.
+
+ * When removing many branches and tags, the code used to do so one
+ ref at a time. There is another API it can use to delete multiple
+ refs, and it makes quite a lot of performance difference when the
+ refs are packed.
+
+ * The "pack-objects" command needs to iterate over all the tags when
+ automatic tag following is enabled, but it actually iterated over
+ all refs and then discarded everything outside "refs/tags/"
+ hierarchy, which was quite wasteful.
+
+ * A perf script was made more portable.
+
+ * Our setting of GitHub CI test jobs were a bit too eager to give up
+ once there is even one failure found. Tweak the knob to allow
+ other jobs keep running even when we see a failure, so that we can
+ find more failures in a single run.
+
+ * We've carried compatibility codepaths for compilers without
+ variadic macros for quite some time, but the world may be ready for
+ them to be removed. Force compilation failure on exotic platforms
+ where variadic macros are not available to find out who screams in
+ such a way that we can easily revert if it turns out that the world
+ is not yet ready.
+
+ * Code clean-up to ensure our use of hashtables using object names as
+ keys use the "struct object_id" objects, not the raw hash values.
+
+ * Lose the debugging aid that may have been useful in the past, but
+ no longer is, in the "grep" codepaths.
+
+ * Some pretty-format specifiers do not need the data in commit object
+ (e.g. "%H"), but we were over-eager to load and parse it, which has
+ been made even lazier.
+
+ * Get rid of "GETTEXT_POISON" support altogether, which may or may
+ not be controversial.
+
+ * Introduce an on-disk file to record revindex for packdata, which
+ traditionally was always created on the fly and only in-core.
+
+ * The commit-graph learned to use corrected commit dates instead of
+ the generation number to help topological revision traversal.
+
+ * Piecemeal of rewrite of "git bisect" in C continues.
+
+ * When a pager spawned by us exited, the trace log did not record its
+ exit status correctly, which has been corrected.
+
+ * Removal of GIT_TEST_GETTEXT_POISON continues.
+
+ * The code to implement "git merge-base --independent" was poorly
+ done and was kept from the very beginning of the feature.
+
+ * Preliminary changes to fsmonitor integration.
+
+ * Performance improvements for rename detection.
+
+ * The common code to deal with "chunked file format" that is shared
+ by the multi-pack-index and commit-graph files have been factored
+ out, to help codepaths for both filetypes to become more robust.
+
+ * The approach to "fsck" the incoming objects in "index-pack" is
+ attractive for performance reasons (we have them already in core,
+ inflated and ready to be inspected), but fundamentally cannot be
+ applied fully when we receive more than one pack stream, as a tree
+ object in one pack may refer to a blob object in another pack as
+ ".gitmodules", when we want to inspect blobs that are used as
+ ".gitmodules" file, for example. Teach "index-pack" to emit
+ objects that must be inspected later and check them in the calling
+ "fetch-pack" process.
+
+ * The logic to handle "trailer" related placeholders in the
+ "--format=" mechanisms in the "log" family and "for-each-ref"
+ family is getting unified.
+
+ * Raise the buffer size used when writing the index file out from
+ (obviously too small) 8kB to (clearly sufficiently large) 128kB.
+
+ * It is reported that open() on some platforms (e.g. macOS Big Sur)
+ can return EINTR even though our timers are set up with SA_RESTART.
+ A workaround has been implemented and enabled for macOS to rerun
+ open() transparently from the caller when this happens.
+
+
+Fixes since v2.30
+-----------------
+
+ * Diagnose command line error of "git rebase" early.
+
+ * Clean up option descriptions in "git cmd --help".
+
+ * "git stash" did not work well in a sparsely checked out working
+ tree.
+
+ * Some tests expect that "ls -l" output has either '-' or 'x' for
+ group executable bit, but setgid bit can be inherited from parent
+ directory and make these fields 'S' or 's' instead, causing test
+ failures.
+
+ * "git for-each-repo --config=<var> <cmd>" should not run <cmd> for
+ any repository when the configuration variable <var> is not defined
+ even once.
+
+ * Fix 2.29 regression where "git mergetool --tool-help" fails to list
+ all the available tools.
+
+ * Fix for procedure to building CI test environment for mac.
+
+ * The implementation of "git branch --sort" wrt the detached HEAD
+ display has always been hacky, which has been cleaned up.
+
+ * Newline characters in the host and path part of git:// URL are
+ now forbidden.
+
+ * "git diff" showed a submodule working tree with untracked cruft as
+ "Submodule commit <objectname>-dirty", but a natural expectation is
+ that the "-dirty" indicator would align with "git describe --dirty",
+ which does not consider having untracked files in the working tree
+ as source of dirtiness. The inconsistency has been fixed.
+
+ * When more than one commit with the same patch ID appears on one
+ side, "git log --cherry-pick A...B" did not exclude them all when a
+ commit with the same patch ID appears on the other side. Now it
+ does.
+
+ * Documentation for "git fsck" lost stale bits that has become
+ incorrect.
+
+ * Doc fix for packfile URI feature.
+
+ * When "git rebase -i" processes "fixup" insn, there is no reason to
+ clean up the commit log message, but we did the usual stripspace
+ processing. This has been corrected.
+ (merge f7d42ceec5 js/rebase-i-commit-cleanup-fix later to maint).
+
+ * Fix in passing custom args from "git clone" to "upload-pack" on the
+ other side.
+ (merge ad6b5fefbd jv/upload-pack-filter-spec-quotefix later to maint).
+
+ * The command line completion (in contrib/) completed "git branch -d"
+ with branch names, but "git branch -D" offered tagnames in addition,
+ which has been corrected. "git branch -M" had the same problem.
+ (merge 27dc071b9a jk/complete-branch-force-delete later to maint).
+
+ * When commands are started from a subdirectory, they may have to
+ compare the path to the subdirectory (called prefix and found out
+ from $(pwd)) with the tracked paths. On macOS, $(pwd) and
+ readdir() yield decomposed path, while the tracked paths are
+ usually normalized to the precomposed form, causing mismatch. This
+ has been fixed by taking the same approach used to normalize the
+ command line arguments.
+ (merge 5c327502db tb/precompose-prefix-too later to maint).
+
+ * Even though invocations of "die()" were logged to the trace2
+ system, "BUG()"s were not, which has been corrected.
+ (merge 0a9dde4a04 jt/trace2-BUG later to maint).
+
+ * "git grep --untracked" is meant to be "let's ALSO find in these
+ files on the filesystem" when looking for matches in the working
+ tree files, and does not make any sense if the primary search is
+ done against the index, or the tree objects. The "--cached" and
+ "--untracked" options have been marked as mutually incompatible.
+ (merge 0c5d83b248 mt/grep-cached-untracked later to maint).
+
+ * Fix "git fsck --name-objects" which apparently has not been used by
+ anybody who is motivated enough to report breakage.
+ (merge e89f89361c js/fsck-name-objects-fix later to maint).
+
+ * Avoid individual tests in t5411 from getting affected by each other
+ by forcing them to use separate output files during the test.
+ (merge 822ee894f6 jx/t5411-unique-filenames later to maint).
+
+ * Test to make sure "git rev-parse one-thing one-thing" gives
+ the same thing twice (when one-thing is --since=X).
+ (merge a5cdca4520 ew/rev-parse-since-test later to maint).
+
+ * When certain features (e.g. grafts) used in the repository are
+ incompatible with the use of the commit-graph, we used to silently
+ turned commit-graph off; we now tell the user what we are doing.
+ (merge c85eec7fc3 js/commit-graph-warning later to maint).
+
+ * Objects that lost references can be pruned away, even when they
+ have notes attached to it (and these notes will become dangling,
+ which in turn can be pruned with "git notes prune"). This has been
+ clarified in the documentation.
+ (merge fa9ab027ba mz/doc-notes-are-not-anchors later to maint).
+
+ * The error codepath around the "--temp/--prefix" feature of "git
+ checkout-index" has been improved.
+ (merge 3f7ba60350 mt/checkout-index-corner-cases later to maint).
+
+ * The "git maintenance register" command had trouble registering bare
+ repositories, which had been corrected.
+
+ * A handful of multi-word configuration variable names in
+ documentation that are spelled in all lowercase have been corrected
+ to use the more canonical camelCase.
+ (merge 7dd0eaa39c dl/doc-config-camelcase later to maint).
+
+ * "git push $there --delete ''" should have been diagnosed as an
+ error, but instead turned into a matching push, which has been
+ corrected.
+ (merge 20e416409f jc/push-delete-nothing later to maint).
+
+ * Test script modernization.
+ (merge 488acf15df sv/t7001-modernize later to maint).
+
+ * An under-allocation for the untracked cache data has been corrected.
+ (merge 6347d649bc jh/untracked-cache-fix later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge e3f5da7e60 sg/t7800-difftool-robustify later to maint).
+ (merge 9d336655ba js/doc-proto-v2-response-end later to maint).
+ (merge 1b5b8cf072 jc/maint-column-doc-typofix later to maint).
+ (merge 3a837b58e3 cw/pack-config-doc later to maint).
+ (merge 01168a9d89 ug/doc-commit-approxidate later to maint).
+ (merge b865734760 js/params-vs-args later to maint).
diff --git a/RelNotes/2.31.1.adoc b/RelNotes/2.31.1.adoc
new file mode 100644
index 0000000..f9b06b8
--- /dev/null
+++ b/RelNotes/2.31.1.adoc
@@ -0,0 +1,27 @@
+Git 2.31.1 Release Notes
+========================
+
+Fixes since v2.31
+-----------------
+
+ * The fsmonitor interface read from its input without making sure
+ there is something to read from. This bug is new in 2.31
+ timeframe.
+
+ * The data structure used by fsmonitor interface was not properly
+ duplicated during an in-core merge, leading to use-after-free etc.
+
+ * "git bisect" reimplemented more in C during 2.30 timeframe did not
+ take an annotated tag as a good/bad endpoint well. This regression
+ has been corrected.
+
+ * Fix macros that can silently inject unintended null-statements.
+
+ * CALLOC_ARRAY() macro replaces many uses of xcalloc().
+
+ * Update insn in Makefile comments to run fuzz-all target.
+
+ * Fix a corner case bug in "git mv" on case insensitive systems,
+ which was introduced in 2.29 timeframe.
+
+Also contains various documentation updates and code clean-ups.
diff --git a/RelNotes/2.31.2.adoc b/RelNotes/2.31.2.adoc
new file mode 100644
index 0000000..aa13a5b
--- /dev/null
+++ b/RelNotes/2.31.2.adoc
@@ -0,0 +1,6 @@
+Git v2.31.2 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.30.3 to address
+the security issue CVE-2022-24765; see the release notes for that
+version for details.
diff --git a/RelNotes/2.31.3.adoc b/RelNotes/2.31.3.adoc
new file mode 100644
index 0000000..ca143ab
--- /dev/null
+++ b/RelNotes/2.31.3.adoc
@@ -0,0 +1,4 @@
+Git Documentation/RelNotes/2.31.3.txt Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.31.3.
diff --git a/RelNotes/2.31.4.adoc b/RelNotes/2.31.4.adoc
new file mode 100644
index 0000000..97a91fd
--- /dev/null
+++ b/RelNotes/2.31.4.adoc
@@ -0,0 +1,6 @@
+Git v2.31.4 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.30.5 to address
+the security issue CVE-2022-29187; see the release notes for that
+version for details.
diff --git a/RelNotes/2.31.5.adoc b/RelNotes/2.31.5.adoc
new file mode 100644
index 0000000..0d87e6e
--- /dev/null
+++ b/RelNotes/2.31.5.adoc
@@ -0,0 +1,5 @@
+Git v2.31.5 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.30.6; see
+the release notes for that version for details.
diff --git a/RelNotes/2.31.6.adoc b/RelNotes/2.31.6.adoc
new file mode 100644
index 0000000..425a518
--- /dev/null
+++ b/RelNotes/2.31.6.adoc
@@ -0,0 +1,5 @@
+Git v2.31.6 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.30.7; see
+the release notes for that version for details.
diff --git a/RelNotes/2.31.7.adoc b/RelNotes/2.31.7.adoc
new file mode 100644
index 0000000..dd44d5b
--- /dev/null
+++ b/RelNotes/2.31.7.adoc
@@ -0,0 +1,6 @@
+Git v2.31.7 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.30.8 to
+address the security issues CVE-2023-22490 and CVE-2023-23946;
+see the release notes for that version for details.
diff --git a/RelNotes/2.31.8.adoc b/RelNotes/2.31.8.adoc
new file mode 100644
index 0000000..0aa3080
--- /dev/null
+++ b/RelNotes/2.31.8.adoc
@@ -0,0 +1,6 @@
+Git v2.31.8 Release Notes
+=========================
+
+This release merges the fixes that appear in v2.30.9 to address the
+security issues CVE-2023-25652, CVE-2023-25815, and CVE-2023-29007;
+see the release notes for that version for details.
diff --git a/RelNotes/2.32.0.adoc b/RelNotes/2.32.0.adoc
new file mode 100644
index 0000000..87d56fa
--- /dev/null
+++ b/RelNotes/2.32.0.adoc
@@ -0,0 +1,416 @@
+Git 2.32 Release Notes
+======================
+
+Backward compatibility notes
+----------------------------
+
+ * ".gitattributes", ".gitignore", and ".mailmap" files that are
+ symbolic links are ignored.
+
+ * "git apply --3way" used to first attempt a straight application,
+ and only fell back to the 3-way merge algorithm when the stright
+ application failed. Starting with this version, the command will
+ first try the 3-way merge algorithm and only when it fails (either
+ resulting with conflict or the base versions of blobs are missing),
+ falls back to the usual patch application.
+
+
+Updates since v2.31
+-------------------
+
+UI, Workflows & Features
+
+ * It does not make sense to make ".gitattributes", ".gitignore" and
+ ".mailmap" symlinks, as they are supposed to be usable from the
+ object store (think: bare repositories where HEAD:.mailmap etc. are
+ used). When these files are symbolic links, we used to read the
+ contents of the files pointed by them by mistake, which has been
+ corrected.
+
+ * "git stash show" learned to optionally show untracked part of the
+ stash.
+
+ * "git log --format='...'" learned "%(describe)" placeholder.
+
+ * "git repack" so far has been only capable of repacking everything
+ under the sun into a single pack (or split by size). A cleverer
+ strategy to reduce the cost of repacking a repository has been
+ introduced.
+
+ * The http codepath learned to let the credential layer to cache the
+ password used to unlock a certificate that has successfully been
+ used.
+
+ * "git commit --fixup=<commit>", which was to tweak the changes made
+ to the contents while keeping the original log message intact,
+ learned "--fixup=(amend|reword):<commit>", that can be used to
+ tweak both the message and the contents, and only the message,
+ respectively.
+
+ * "git send-email" learned to honor the core.hooksPath configuration.
+
+ * "git format-patch -v<n>" learned to allow a reroll count that is
+ not an integer.
+
+ * "git commit" learned "--trailer <key>[=<value>]" option; together
+ with the interpret-trailers command, this will make it easier to
+ support custom trailers.
+
+ * "git clone --reject-shallow" option fails the clone as soon as we
+ notice that we are cloning from a shallow repository.
+
+ * A configuration variable has been added to force tips of certain
+ refs to be given a reachability bitmap.
+
+ * "gitweb" learned "e-mail privacy" feature to redact strings that
+ look like e-mail addresses on various pages.
+
+ * "git apply --3way" has always been "to fall back to 3-way merge
+ only when straight application fails". Swap the order of falling
+ back so that 3-way is always attempted first (only when the option
+ is given, of course) and then straight patch application is used as
+ a fallback when it fails.
+
+ * "git apply" now takes "--3way" and "--cached" at the same time, and
+ work and record results only in the index.
+
+ * The command line completion (in contrib/) has learned that
+ CHERRY_PICK_HEAD is a possible pseudo-ref.
+
+ * Userdiff patterns for "Scheme" has been added.
+
+ * "git log" learned "--diff-merges=<style>" option, with an
+ associated configuration variable log.diffMerges.
+
+ * "git log --format=..." placeholders learned %ah/%ch placeholders to
+ request the --date=human output.
+
+ * Replace GIT_CONFIG_NOSYSTEM mechanism to decline from reading the
+ system-wide configuration file with GIT_CONFIG_SYSTEM that lets
+ users specify from which file to read the system-wide configuration
+ (setting it to an empty file would essentially be the same as
+ setting NOSYSTEM), and introduce GIT_CONFIG_GLOBAL to override the
+ per-user configuration in $HOME/.gitconfig.
+
+ * "git add" and "git rm" learned not to touch those paths that are
+ outside of sparse checkout.
+
+ * "git rev-list" learns the "--filter=object:type=<type>" option,
+ which can be used to exclude objects of the given kind from the
+ packfile generated by pack-objects.
+
+ * The command line completion (in contrib/) for "git stash" has been
+ updated.
+
+ * "git subtree" updates.
+
+ * It is now documented that "format-patch" skips merges.
+
+ * Options to "git pack-objects" that take numeric values like
+ --window and --depth should not accept negative values; the input
+ validation has been tightened.
+
+ * The way the command line specified by the trailer.<token>.command
+ configuration variable receives the end-user supplied value was
+ both error prone and misleading. An alternative to achieve the
+ same goal in a safer and more intuitive way has been added, as
+ the trailer.<token>.cmd configuration variable, to replace it.
+
+ * "git add -i --dry-run" does not dry-run, which was surprising. The
+ combination of options has taught to error out.
+
+ * "git push" learns to discover common ancestor with the receiving
+ end over protocol v2. This will hopefully make "git push" as
+ efficient as "git fetch" in avoiding objects from getting
+ transferred unnecessarily.
+
+ * "git mailinfo" (hence "git am") learned the "--quoted-cr" option to
+ control how lines ending with CRLF wrapped in base64 or qp are
+ handled.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * Rename detection rework continues.
+
+ * GIT_TEST_FAIL_PREREQS is a mechanism to skip test pieces with
+ prerequisites to catch broken tests that depend on the side effects
+ of optional pieces, but did not work at all when negative
+ prerequisites were involved.
+ (merge 27d578d904 jk/fail-prereq-testfix later to maint).
+
+ * "git diff-index" codepath has been taught to trust fsmonitor status
+ to reduce number of lstat() calls.
+ (merge 7e5aa13d2c nk/diff-index-fsmonitor later to maint).
+
+ * Reorganize Makefile to allow building git.o and other essential
+ objects without extra stuff needed only for testing.
+
+ * Preparatory API changes for parallel checkout.
+
+ * A simple IPC interface gets introduced to build services like
+ fsmonitor on top.
+
+ * Fsck API clean-up.
+
+ * SECURITY.md that is facing individual contributors and end users
+ has been introduced. Also a procedure to follow when preparing
+ embargoed releases has been spelled out.
+ (merge 09420b7648 js/security-md later to maint).
+
+ * Optimize "rev-list --use-bitmap-index --objects" corner case that
+ uses negative tags as the stopping points.
+
+ * CMake update for vsbuild.
+
+ * An on-disk reverse-index to map the in-pack location of an object
+ back to its object name across multiple packfiles is introduced.
+
+ * Generate [ec]tags under $(QUIET_GEN).
+
+ * Clean-up codepaths that implements "git send-email --validate"
+ option and improves the message from it.
+
+ * The last remnant of gettext-poison has been removed.
+
+ * The test framework has been taught to optionally turn the default
+ merge strategy to "ort" throughout the system where we use
+ three-way merges internally, like cherry-pick, rebase etc.,
+ primarily to enhance its test coverage (the strategy has been
+ available as an explicit "-s ort" choice).
+
+ * A bit of code clean-up and a lot of test clean-up around userdiff
+ area.
+
+ * Handling of "promisor packs" that allows certain objects to be
+ missing and lazily retrievable has been optimized (a bit).
+
+ * When packet_write() fails, we gave an extra error message
+ unnecessarily, which has been corrected.
+
+ * The checkout machinery has been taught to perform the actual
+ write-out of the files in parallel when able.
+
+ * Show errno in the trace output in the error codepath that calls
+ read_raw_ref method.
+
+ * Effort to make the command line completion (in contrib/) safe with
+ "set -u" continues.
+
+ * Tweak a few tests for "log --format=..." that show timestamps in
+ various formats.
+
+ * The reflog expiry machinery has been taught to emit trace events.
+
+ * Over-the-wire protocol learns a new request type to ask for object
+ sizes given a list of object names.
+
+
+Fixes since v2.31
+-----------------
+
+ * The fsmonitor interface read from its input without making sure
+ there is something to read from. This bug is new in 2.31
+ timeframe.
+
+ * The data structure used by fsmonitor interface was not properly
+ duplicated during an in-core merge, leading to use-after-free etc.
+
+ * "git bisect" reimplemented more in C during 2.30 timeframe did not
+ take an annotated tag as a good/bad endpoint well. This regression
+ has been corrected.
+
+ * Fix macros that can silently inject unintended null-statements.
+
+ * CALLOC_ARRAY() macro replaces many uses of xcalloc().
+
+ * Update insn in Makefile comments to run fuzz-all target.
+
+ * Fix a corner case bug in "git mv" on case insensitive systems,
+ which was introduced in 2.29 timeframe.
+
+ * We had a code to diagnose and die cleanly when a required
+ clean/smudge filter is missing, but an assert before that
+ unnecessarily fired, hiding the end-user facing die() message.
+ (merge 6fab35f748 mt/cleanly-die-upon-missing-required-filter later to maint).
+
+ * Update C code that sets a few configuration variables when a remote
+ is configured so that it spells configuration variable names in the
+ canonical camelCase.
+ (merge 0f1da600e6 ab/remote-write-config-in-camel-case later to maint).
+
+ * A new configuration variable has been introduced to allow choosing
+ which version of the generation number gets used in the
+ commit-graph file.
+ (merge 702110aac6 ds/commit-graph-generation-config later to maint).
+
+ * Perf test update to work better in secondary worktrees.
+ (merge 36e834abc1 jk/perf-in-worktrees later to maint).
+
+ * Updates to memory allocation code around the use of pcre2 library.
+ (merge c1760352e0 ab/grep-pcre2-allocfix later to maint).
+
+ * "git -c core.bare=false clone --bare ..." would have segfaulted,
+ which has been corrected.
+ (merge 75555676ad bc/clone-bare-with-conflicting-config later to maint).
+
+ * When "git checkout" removes a path that does not exist in the
+ commit it is checking out, it wasn't careful enough not to follow
+ symbolic links, which has been corrected.
+ (merge fab78a0c3d mt/checkout-remove-nofollow later to maint).
+
+ * A few option description strings started with capital letters,
+ which were corrected.
+ (merge 5ee90326dc cc/downcase-opt-help later to maint).
+
+ * Plug or annotate remaining leaks that trigger while running the
+ very basic set of tests.
+ (merge 68ffe095a2 ah/plugleaks later to maint).
+
+ * The hashwrite() API uses a buffering mechanism to avoid calling
+ write(2) too frequently. This logic has been refactored to be
+ easier to understand.
+ (merge ddaf1f62e3 ds/clarify-hashwrite later to maint).
+
+ * "git cherry-pick/revert" with or without "--[no-]edit" did not spawn
+ the editor as expected (e.g. "revert --no-edit" after a conflict
+ still asked to edit the message), which has been corrected.
+ (merge 39edfd5cbc en/sequencer-edit-upon-conflict-fix later to maint).
+
+ * "git daemon" has been tightened against systems that take backslash
+ as directory separator.
+ (merge 9a7f1ce8b7 rs/daemon-sanitize-dir-sep later to maint).
+
+ * A NULL-dereference bug has been corrected in an error codepath in
+ "git for-each-ref", "git branch --list" etc.
+ (merge c685450880 jk/ref-filter-segfault-fix later to maint).
+
+ * Streamline the codepath to fix the UTF-8 encoding issues in the
+ argv[] and the prefix on macOS.
+ (merge c7d0e61016 tb/precompose-prefix-simplify later to maint).
+
+ * The command-line completion script (in contrib/) had a couple of
+ references that would have given a warning under the "-u" (nounset)
+ option.
+ (merge c5c0548d79 vs/completion-with-set-u later to maint).
+
+ * When "git pack-objects" makes a literal copy of a part of existing
+ packfile using the reachability bitmaps, its update to the progress
+ meter was broken.
+ (merge 8e118e8490 jk/pack-objects-bitmap-progress-fix later to maint).
+
+ * The dependencies for config-list.h and command-list.h were broken
+ when the former was split out of the latter, which has been
+ corrected.
+ (merge 56550ea718 sg/bugreport-fixes later to maint).
+
+ * "git push --quiet --set-upstream" was not quiet when setting the
+ upstream branch configuration, which has been corrected.
+ (merge f3cce896a8 ow/push-quiet-set-upstream later to maint).
+
+ * The prefetch task in "git maintenance" assumed that "git fetch"
+ from any remote would fetch all its local branches, which would
+ fetch too much if the user is interested in only a subset of
+ branches there.
+ (merge 32f67888d8 ds/maintenance-prefetch-fix later to maint).
+
+ * Clarify that pathnames recorded in Git trees are most often (but
+ not necessarily) encoded in UTF-8.
+ (merge 9364bf465d ab/pathname-encoding-doc later to maint).
+
+ * "git --config-env var=val cmd" weren't accepted (only
+ --config-env=var=val was).
+ (merge c331551ccf ps/config-env-option-with-separate-value later to maint).
+
+ * When the reachability bitmap is in effect, the "do not lose
+ recently created objects and those that are reachable from them"
+ safety to protect us from races were disabled by mistake, which has
+ been corrected.
+ (merge 2ba582ba4c jk/prune-with-bitmap-fix later to maint).
+
+ * Cygwin pathname handling fix.
+ (merge bccc37fdc7 ad/cygwin-no-backslashes-in-paths later to maint).
+
+ * "git rebase --[no-]reschedule-failed-exec" did not work well with
+ its configuration variable, which has been corrected.
+ (merge e5b32bffd1 ab/rebase-no-reschedule-failed-exec later to maint).
+
+ * Portability fix for command line completion script (in contrib/).
+ (merge f2acf763e2 si/zsh-complete-comment-fix later to maint).
+
+ * "git repack -A -d" in a partial clone unnecessarily loosened
+ objects in promisor pack.
+
+ * "git bisect skip" when custom words are used for new/old did not
+ work, which has been corrected.
+
+ * A few variants of informational message "Already up-to-date" has
+ been rephrased.
+ (merge ad9322da03 js/merge-already-up-to-date-message-reword later to maint).
+
+ * "git submodule update --quiet" did not propagate the quiet option
+ down to underlying "git fetch", which has been corrected.
+ (merge 62af4bdd42 nc/submodule-update-quiet later to maint).
+
+ * Document that our test can use "local" keyword.
+ (merge a84fd3bcc6 jc/test-allows-local later to maint).
+
+ * The word-diff mode has been taught to work better with a word
+ regexp that can match an empty string.
+ (merge 0324e8fc6b pw/word-diff-zero-width-matches later to maint).
+
+ * "git p4" learned to find branch points more efficiently.
+ (merge 6b79818bfb jk/p4-locate-branch-point-optim later to maint).
+
+ * When "git update-ref -d" removes a ref that is packed, it left
+ empty directories under $GIT_DIR/refs/ for
+ (merge 5f03e5126d wc/packed-ref-removal-cleanup later to maint).
+
+ * "git clean" and "git ls-files -i" had confusion around working on
+ or showing ignored paths inside an ignored directory, which has
+ been corrected.
+ (merge b548f0f156 en/dir-traversal later to maint).
+
+ * The handling of "%(push)" formatting element of "for-each-ref" and
+ friends was broken when the same codepath started handling
+ "%(push:<what>)", which has been corrected.
+ (merge 1e1c4c5eac zh/ref-filter-push-remote-fix later to maint).
+
+ * The bash prompt script (in contrib/) did not work under "set -u".
+ (merge 5c0cbdb107 en/prompt-under-set-u later to maint).
+
+ * The "chainlint" feature in the test framework is a handy way to
+ catch common mistakes in writing new tests, but tends to get
+ expensive. An knob to selectively disable it has been introduced
+ to help running tests that the developer has not modified.
+ (merge 2d86a96220 jk/test-chainlint-softer later to maint).
+
+ * The "rev-parse" command did not diagnose the lack of argument to
+ "--path-format" option, which was introduced in v2.31 era, which
+ has been corrected.
+ (merge 99fc555188 wm/rev-parse-path-format-wo-arg later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge f451960708 dl/cat-file-doc-cleanup later to maint).
+ (merge 12604a8d0c sv/t9801-test-path-is-file-cleanup later to maint).
+ (merge ea7e63921c jr/doc-ignore-typofix later to maint).
+ (merge 23c781f173 ps/update-ref-trans-hook-doc later to maint).
+ (merge 42efa1231a jk/filter-branch-sha256 later to maint).
+ (merge 4c8e3dca6e tb/push-simple-uses-branch-merge-config later to maint).
+ (merge 6534d436a2 bs/asciidoctor-installation-hints later to maint).
+ (merge 47957485b3 ab/read-tree later to maint).
+ (merge 2be927f3d1 ab/diff-no-index-tests later to maint).
+ (merge 76593c09bb ab/detox-gettext-tests later to maint).
+ (merge 28e29ee38b jc/doc-format-patch-clarify later to maint).
+ (merge fc12b6fdde fm/user-manual-use-preface later to maint).
+ (merge dba94e3a85 cc/test-helper-bloom-usage-fix later to maint).
+ (merge 61a7660516 hn/reftable-tables-doc-update later to maint).
+ (merge 81ed96a9b2 jt/fetch-pack-request-fix later to maint).
+ (merge 151b6c2dd7 jc/doc-do-not-capitalize-clarification later to maint).
+ (merge 9160068ac6 js/access-nul-emulation-on-windows later to maint).
+ (merge 7a14acdbe6 po/diff-patch-doc later to maint).
+ (merge f91371b948 pw/patience-diff-clean-up later to maint).
+ (merge 3a7f0908b6 mt/clean-clean later to maint).
+ (merge d4e2d15a8b ab/streaming-simplify later to maint).
+ (merge 0e59f7ad67 ah/merge-ort-i18n later to maint).
+ (merge e6f68f62e0 ls/typofix later to maint).
diff --git a/RelNotes/2.32.1.adoc b/RelNotes/2.32.1.adoc
new file mode 100644
index 0000000..7dcca13
--- /dev/null
+++ b/RelNotes/2.32.1.adoc
@@ -0,0 +1,6 @@
+Git v2.32.1 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.30.3 and
+v2.31.2 to address the security issue CVE-2022-24765; see the
+release notes for these versions for details.
diff --git a/RelNotes/2.32.2.adoc b/RelNotes/2.32.2.adoc
new file mode 100644
index 0000000..cf49695
--- /dev/null
+++ b/RelNotes/2.32.2.adoc
@@ -0,0 +1,4 @@
+Git Documentation/RelNotes/2.32.2.txt Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.32.2.
diff --git a/RelNotes/2.32.3.adoc b/RelNotes/2.32.3.adoc
new file mode 100644
index 0000000..583fabe
--- /dev/null
+++ b/RelNotes/2.32.3.adoc
@@ -0,0 +1,6 @@
+Git v2.32.3 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.30.5 and
+v2.31.4 to address the security issue CVE-2022-29187; see the
+release notes for these versions for details.
diff --git a/RelNotes/2.32.4.adoc b/RelNotes/2.32.4.adoc
new file mode 100644
index 0000000..76c67b2
--- /dev/null
+++ b/RelNotes/2.32.4.adoc
@@ -0,0 +1,5 @@
+Git v2.32.4 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.30.6; see
+the release notes for that version for details.
diff --git a/RelNotes/2.32.5.adoc b/RelNotes/2.32.5.adoc
new file mode 100644
index 0000000..a8cad1a
--- /dev/null
+++ b/RelNotes/2.32.5.adoc
@@ -0,0 +1,8 @@
+Git v2.32.5 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.30.7; see
+the release notes for that version for details.
+
+In addition, included are additional code for "git fsck" to check
+for questionable .gitattributes files.
diff --git a/RelNotes/2.32.6.adoc b/RelNotes/2.32.6.adoc
new file mode 100644
index 0000000..fd65961
--- /dev/null
+++ b/RelNotes/2.32.6.adoc
@@ -0,0 +1,6 @@
+Git v2.32.6 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.30.8 and v2.31.7
+to address the security issues CVE-2023-22490 and CVE-2023-23946;
+see the release notes for these versions for details.
diff --git a/RelNotes/2.32.7.adoc b/RelNotes/2.32.7.adoc
new file mode 100644
index 0000000..7bb3538
--- /dev/null
+++ b/RelNotes/2.32.7.adoc
@@ -0,0 +1,7 @@
+Git v2.32.7 Release Notes
+=========================
+
+This release merges the fixes that appear in v2.30.9 and v2.31.8 to
+address the security issues CVE-2023-25652, CVE-2023-25815, and
+CVE-2023-29007; see the release notes for these versions for
+details.
diff --git a/RelNotes/2.33.0.adoc b/RelNotes/2.33.0.adoc
new file mode 100644
index 0000000..893c18b
--- /dev/null
+++ b/RelNotes/2.33.0.adoc
@@ -0,0 +1,279 @@
+Git 2.33 Release Notes
+======================
+
+Updates since Git 2.32
+----------------------
+
+UI, Workflows & Features
+
+ * "git send-email" learned the "--sendmail-cmd" command line option
+ and the "sendemail.sendmailCmd" configuration variable, which is a
+ more sensible approach than the current way of repurposing the
+ "smtp-server" that is meant to name the server to instead name the
+ command to talk to the server.
+
+ * The userdiff pattern for C# learned the token "record".
+
+ * "git rev-list" learns to omit the "commit <object-name>" header
+ lines from the output with the `--no-commit-header` option.
+
+ * "git worktree add --lock" learned to record why the worktree is
+ locked with a custom message.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * The code to handle the "--format" option in "for-each-ref" and
+ friends made too many string comparisons on %(atom)s used in the
+ format string, which has been corrected by converting them into
+ enum when the format string is parsed.
+
+ * Use the hashfile API in the codepath that writes the index file to
+ reduce code duplication.
+
+ * Repeated rename detections in a sequence of mergy operations have
+ been optimized out for the 'ort' merge strategy.
+
+ * Preliminary clean-up of tests before the main reftable changes
+ hits the codebase.
+
+ * The backend for "diff -G/-S" has been updated to use pcre2 engine
+ when available.
+
+ * Use ".DELETE_ON_ERROR" pseudo target to simplify our Makefile.
+
+ * Code cleanup around struct_type_init() functions.
+
+ * "git send-email" optimization.
+
+ * GitHub Actions / CI update.
+ (merge 0dc787a9f2 js/ci-windows-update later to maint).
+
+ * Object accesses in repositories with many alternate object store
+ have been optimized.
+
+ * "git log" has been optimized not to waste cycles to load ref
+ decoration data that may not be needed.
+
+ * Many "printf"-like helper functions we have have been annotated
+ with __attribute__() to catch placeholder/parameter mismatches.
+
+ * Tests that cover protocol bits have been updated and helpers
+ used there have been consolidated.
+
+ * The CI gained a new job to run "make sparse" check.
+
+ * "git status" codepath learned to work with sparsely populated index
+ without hydrating it fully.
+
+ * A guideline for gender neutral documentation has been added.
+
+ * Documentation on "git diff -l<n>" and diff.renameLimit have been
+ updated, and the defaults for these limits have been raised.
+
+ * The completion support used to offer alternate spelling of options
+ that exist only for compatibility, which has been corrected.
+
+ * "TEST_OUTPUT_DIRECTORY=there make test" failed to work, which has
+ been corrected.
+
+ * "git bundle" gained more test coverage.
+
+ * "git read-tree" had a codepath where blobs are fetched one-by-one
+ from the promisor remote, which has been corrected to fetch in bulk.
+
+ * Rewrite of "git submodule" in C continues.
+
+ * "git checkout" and "git commit" learn to work without unnecessarily
+ expanding sparse indexes.
+
+
+Fixes since v2.32
+-----------------
+
+ * We historically rejected a very short string as an author name
+ while accepting a patch e-mail, which has been loosened.
+ (merge 72ee47ceeb ef/mailinfo-short-name later to maint).
+
+ * The parallel checkout codepath did not initialize object ID field
+ used to talk to the worker processes in a futureproof way.
+
+ * Rewrite code that triggers undefined behaviour warning.
+ (merge aafa5df0df jn/size-t-casted-to-off-t-fix later to maint).
+
+ * The description of "fast-forward" in the glossary has been updated.
+ (merge e22f2daed0 ry/clarify-fast-forward-in-glossary later to maint).
+
+ * Recent "git clone" left a temporary directory behind when the
+ transport layer returned an failure.
+ (merge 6aacb7d861 jk/clone-clean-upon-transport-error later to maint).
+
+ * "git fetch" over protocol v2 left its side of the socket open after
+ it finished speaking, which unnecessarily wasted the resource on
+ the other side.
+ (merge ae1a7eefff jk/fetch-pack-v2-half-close-early later to maint).
+
+ * The command line completion (in contrib/) learned that "git diff"
+ takes the "--anchored" option.
+ (merge d1e7c2cac9 tb/complete-diff-anchored later to maint).
+
+ * "git-svn" tests assumed that "locale -a", which is used to pick an
+ available UTF-8 locale, is available everywhere. A knob has been
+ introduced to allow testers to specify a suitable locale to use.
+ (merge 482c962de4 dd/svn-test-wo-locale-a later to maint).
+
+ * Update "git subtree" to work better on Windows.
+ (merge 77f37de39f js/subtree-on-windows-fix later to maint).
+
+ * Remove multimail from contrib/
+ (merge f74d11471f js/no-more-multimail later to maint).
+
+ * Make the codebase MSAN clean.
+ (merge 4dbc55e87d ah/uninitialized-reads-fix later to maint).
+
+ * Work around inefficient glob substitution in older versions of bash
+ by rewriting parts of a test.
+ (merge eb87c6f559 jx/t6020-with-older-bash later to maint).
+
+ * Avoid duplicated work while building reachability bitmaps.
+ (merge aa9ad6fee5 jk/bitmap-tree-optim later to maint).
+
+ * We broke "GIT_SKIP_TESTS=t?000" to skip certain tests in recent
+ update, which got fixed.
+
+ * The side-band demultiplexer that is used to display progress output
+ from the remote end did not clear the line properly when the end of
+ line hits at a packet boundary, which has been corrected.
+
+ * Some test scripts assumed that readlink(1) was universally
+ installed and available, which is not the case.
+ (merge 7c0afdf23c jk/test-without-readlink-1 later to maint).
+
+ * Recent update to completion script (in contrib/) broke those who
+ use the __git_complete helper to define completion to their custom
+ command.
+ (merge cea232194d fw/complete-cmd-idx-fix later to maint).
+
+ * Output from some of our tests were affected by the width of the
+ terminal that they were run in, which has been corrected by
+ exporting a fixed value in the COLUMNS environment.
+ (merge c49a177bec ab/fix-columns-to-80-during-tests later to maint).
+
+ * On Windows, mergetool has been taught to find kdiff3.exe just like
+ it finds winmerge.exe.
+ (merge 47eb4c6890 ms/mergetools-kdiff3-on-windows later to maint).
+
+ * When we cannot figure out how wide the terminal is, we use a
+ fallback value of 80 ourselves (which cannot be avoided), but when
+ we run the pager, we export it in COLUMNS, which forces the pager
+ to use the hardcoded value, even when the pager is perfectly
+ capable to figure it out itself. Stop exporting COLUMNS when we
+ fall back on the hardcoded default value for our own use.
+ (merge 9b6e2c8b98 js/stop-exporting-bogus-columns later to maint).
+
+ * "git cat-file --batch-all-objects"" misbehaved when "--batch" is in
+ use and did not ask for certain object traits.
+ (merge ee02ac6164 zh/cat-file-batch-fix later to maint).
+
+ * Some code and doc clarification around "git push".
+
+ * The "union" conflict resultion variant misbehaved when used with
+ binary merge driver.
+ (merge 382b601acd jk/union-merge-binary later to maint).
+
+ * Prevent "git p4" from failing to submit changes to binary file.
+ (merge 54662d5958 dc/p4-binary-submit-fix later to maint).
+
+ * "git grep --and -e foo" ought to have been diagnosed as an error
+ but instead segfaulted, which has been corrected.
+ (merge fe7fe62d8d rs/grep-parser-fix later to maint).
+
+ * The merge code had funny interactions between content based rename
+ detection and directory rename detection.
+ (merge 3585d0ea23 en/merge-dir-rename-corner-case-fix later to maint).
+
+ * When rebuilding the multi-pack index file reusing an existing one,
+ we used to blindly trust the existing file and ended up carrying
+ corrupted data into the updated file, which has been corrected.
+ (merge f89ecf7988 tb/midx-use-checksum later to maint).
+
+ * Update the location of system-side configuration file on Windows.
+ (merge e355307692 js/gfw-system-config-loc-fix later to maint).
+
+ * Code recently added to support common ancestry negotiation during
+ "git push" did not sanity check its arguments carefully enough.
+ (merge eff40457a4 ab/fetch-negotiate-segv-fix later to maint).
+
+ * Update the documentation not to assume users are of certain gender
+ and adds to guidelines to do so.
+ (merge 46a237f42f ds/gender-neutral-doc later to maint).
+
+ * "git commit --allow-empty-message" won't abort the operation upon
+ an empty message, but the hint shown in the editor said otherwise.
+ (merge 6f70f00b4f hj/commit-allow-empty-message later to maint).
+
+ * The code that gives an error message in "git multi-pack-index" when
+ no subcommand is given tried to print a NULL pointer as a strong,
+ which has been corrected.
+ (merge 88617d11f9 tb/reverse-midx later to maint).
+
+ * CI update.
+ (merge a066a90db6 js/ci-check-whitespace-updates later to maint).
+
+ * Documentation fix for "git pull --rebase=no".
+ (merge d3236becec fc/pull-no-rebase-merges-theirs-into-ours later to maint).
+
+ * A race between repacking and using pack bitmaps has been corrected.
+ (merge dc1daacdcc jk/check-pack-valid-before-opening-bitmap later to maint).
+
+ * The local changes stashed by "git merge --autostash" were lost when
+ the merge failed in certain ways, which has been corrected.
+
+ * Windows rmdir() equivalent behaves differently from POSIX ones in
+ that when used on a symbolic link that points at a directory, the
+ target directory gets removed, which has been corrected.
+ (merge 3e7d4888e5 tb/mingw-rmdir-symlink-to-directory later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge bfe35a6165 ah/doc-describe later to maint).
+ (merge f302c1e4aa jc/clarify-revision-range later to maint).
+ (merge 3127ff90ea tl/fix-packfile-uri-doc later to maint).
+ (merge a84216c684 jk/doc-color-pager later to maint).
+ (merge 4e0a64a713 ab/trace2-squelch-gcc-warning later to maint).
+ (merge 225f7fa847 ps/rev-list-object-type-filter later to maint).
+ (merge 5317dfeaed dd/honor-users-tar-in-tests later to maint).
+ (merge ace6d8e3d6 tk/partial-clone-repack-doc later to maint).
+ (merge 7ba68e0cf1 js/trace2-discard-event-docfix later to maint).
+ (merge 8603c419d3 fc/doc-default-to-upstream-config later to maint).
+ (merge 1d72b604ef jk/revision-squelch-gcc-warning later to maint).
+ (merge abcb66c614 ar/typofix later to maint).
+ (merge 9853830787 ah/graph-typofix later to maint).
+ (merge aac578492d ab/config-hooks-path-testfix later to maint).
+ (merge 98c7656a18 ar/more-typofix later to maint).
+ (merge 6fb9195f6c jk/doc-max-pack-size later to maint).
+ (merge 4184cbd635 ar/mailinfo-memcmp-to-skip-prefix later to maint).
+ (merge 91d2347033 ar/doc-libera-chat-in-my-first-contrib later to maint).
+ (merge 338abb0f04 ab/cmd-foo-should-return later to maint).
+ (merge 546096a5cb ab/xdiff-bug-cleanup later to maint).
+ (merge b7b793d1e7 ab/progress-cleanup later to maint).
+ (merge d94f9b8e90 ba/object-info later to maint).
+ (merge 52ff891c03 ar/test-code-cleanup later to maint).
+ (merge a0538e5c8b dd/document-log-decorate-default later to maint).
+ (merge ce24797d38 mr/cmake later to maint).
+ (merge 9eb542f2ee ab/pre-auto-gc-hook-test later to maint).
+ (merge 9fffc38583 bk/doc-commit-typofix later to maint).
+ (merge 1cf823d8f0 ks/submodule-cleanup later to maint).
+ (merge ebbf5d2b70 js/config-mak-windows-pcre-fix later to maint).
+ (merge 617480d75b hn/refs-iterator-peel-returns-boolean later to maint).
+ (merge 6a24cc71ed ar/submodule-helper-include-cleanup later to maint).
+ (merge 5632e838f8 rs/khash-alloc-cleanup later to maint).
+ (merge b1d87fbaf1 jk/typofix later to maint).
+ (merge e04170697a ab/gitignore-discovery-doc later to maint).
+ (merge 8232a0ff48 dl/packet-read-response-end-fix later to maint).
+ (merge eb448631fb dl/diff-merge-base later to maint).
+ (merge c510928a25 hn/refs-debug-empty-prefix later to maint).
+ (merge ddcb189d9d tb/bitmap-type-filter-comment-fix later to maint).
+ (merge 878b399734 pb/submodule-recurse-doc later to maint).
+ (merge 734283855f jk/config-env-doc later to maint).
+ (merge 482e1488a9 ab/getcwd-test later to maint).
+ (merge f0b922473e ar/doc-markup-fix later to maint).
diff --git a/RelNotes/2.33.1.adoc b/RelNotes/2.33.1.adoc
new file mode 100644
index 0000000..b71738e
--- /dev/null
+++ b/RelNotes/2.33.1.adoc
@@ -0,0 +1,138 @@
+Git 2.33.1 Release Notes
+========================
+
+This primarily is to backport various fixes accumulated during the
+development towards Git 2.34, the next feature release.
+
+
+Fixes since v2.33
+-----------------
+
+ * The unicode character width table (used for output alignment) has
+ been updated.
+
+ * Input validation of "git pack-objects --stdin-packs" has been
+ corrected.
+
+ * Bugfix for common ancestor negotiation recently introduced in "git
+ push" codepath.
+
+ * "git pull" had various corner cases that were not well thought out
+ around its --rebase backend, e.g. "git pull --ff-only" did not stop
+ but went ahead and rebased when the history on other side is not a
+ descendant of our history. The series tries to fix them up.
+
+ * "git apply" miscounted the bytes and failed to read to the end of
+ binary hunks.
+
+ * "git range-diff" code clean-up.
+
+ * "git commit --fixup" now works with "--edit" again, after it was
+ broken in v2.32.
+
+ * Use upload-artifacts v1 (instead of v2) for 32-bit linux, as the
+ new version has a blocker bug for that architecture.
+
+ * Checking out all the paths from HEAD during the last conflicted
+ step in "git rebase" and continuing would cause the step to be
+ skipped (which is expected), but leaves MERGE_MSG file behind in
+ $GIT_DIR and confuses the next "git commit", which has been
+ corrected.
+
+ * Various bugs in "git rebase -r" have been fixed.
+
+ * mmap() imitation used to call xmalloc() that dies upon malloc()
+ failure, which has been corrected to just return an error to the
+ caller to be handled.
+
+ * "git diff --relative" segfaulted and/or produced incorrect result
+ when there are unmerged paths.
+
+ * The delayed checkout code path in "git checkout" etc. were chatty
+ even when --quiet and/or --no-progress options were given.
+
+ * "git branch -D <branch>" used to refuse to remove a broken branch
+ ref that points at a missing commit, which has been corrected.
+
+ * Build update for Apple clang.
+
+ * The parser for the "--nl" option of "git column" has been
+ corrected.
+
+ * "git upload-pack" which runs on the other side of "git fetch"
+ forgot to take the ref namespaces into account when handling
+ want-ref requests.
+
+ * The sparse-index support can corrupt the index structure by storing
+ a stale and/or uninitialized data, which has been corrected.
+
+ * Buggy tests could damage repositories outside the throw-away test
+ area we created. We now by default export GIT_CEILING_DIRECTORIES
+ to limit the damage from such a stray test.
+
+ * Even when running "git send-email" without its own threaded
+ discussion support, a threading related header in one message is
+ carried over to the subsequent message to result in an unwanted
+ threading, which has been corrected.
+
+ * The output from "git fast-export", when its anonymization feature
+ is in use, showed an annotated tag incorrectly.
+
+ * Recent "diff -m" changes broke "gitk", which has been corrected.
+
+ * "git maintenance" scheduler fix for macOS.
+
+ * A pathname in an advice message has been made cut-and-paste ready.
+
+ * The "git apply -3" code path learned not to bother the lower level
+ merge machinery when the three-way merge can be trivially resolved
+ without the content level merge.
+
+ * The code that optionally creates the *.rev reverse index file has
+ been optimized to avoid needless computation when it is not writing
+ the file out.
+
+ * "git range-diff -I... <range> <range>" segfaulted, which has been
+ corrected.
+
+ * The order in which various files that make up a single (conceptual)
+ packfile has been reevaluated and straightened up. This matters in
+ correctness, as an incomplete set of files must not be shown to a
+ running Git.
+
+ * The "mode" word is useless in a call to open(2) that does not
+ create a new file. Such a call in the files backend of the ref
+ subsystem has been cleaned up.
+
+ * "git update-ref --stdin" failed to flush its output as needed,
+ which potentially led the conversation to a deadlock.
+
+ * When "git am --abort" fails to abort correctly, it still exited
+ with exit status of 0, which has been corrected.
+
+ * Correct nr and alloc members of strvec struct to be of type size_t.
+
+ * "git stash", where the tentative change involves changing a
+ directory to a file (or vice versa), was confused, which has been
+ corrected.
+
+ * "git clone" from a repository whose HEAD is unborn into a bare
+ repository didn't follow the branch name the other side used, which
+ is corrected.
+
+ * "git cvsserver" had a long-standing bug in its authentication code,
+ which has finally been corrected (it is unclear and is a separate
+ question if anybody is seriously using it, though).
+
+ * "git difftool --dir-diff" mishandled symbolic links.
+
+ * Sensitive data in the HTTP trace were supposed to be redacted, but
+ we failed to do so in HTTP/2 requests.
+
+ * "make clean" has been updated to remove leftover .depend/
+ directories, even when it is not told to use them to compute header
+ dependencies.
+
+ * Protocol v0 clients can get stuck parsing a malformed feature line.
+
+Also contains various documentation updates and code clean-ups.
diff --git a/RelNotes/2.33.2.adoc b/RelNotes/2.33.2.adoc
new file mode 100644
index 0000000..e504489
--- /dev/null
+++ b/RelNotes/2.33.2.adoc
@@ -0,0 +1,15 @@
+Git v2.33.2 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.30.3, v2.31.2
+and v2.32.1 to address the security issue CVE-2022-24765; see
+the release notes for these versions for details.
+
+In addition, it contains the following fixes:
+
+ * Squelch over-eager warning message added during this cycle.
+
+ * A bug in "git rebase -r" has been fixed.
+
+ * One CI task based on Fedora image noticed a not-quite-kosher
+ construct recently, which has been corrected.
diff --git a/RelNotes/2.33.3.adoc b/RelNotes/2.33.3.adoc
new file mode 100644
index 0000000..e2bada1
--- /dev/null
+++ b/RelNotes/2.33.3.adoc
@@ -0,0 +1,4 @@
+Git Documentation/RelNotes/2.33.3.txt Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.33.3.
diff --git a/RelNotes/2.33.4.adoc b/RelNotes/2.33.4.adoc
new file mode 100644
index 0000000..a145cc2
--- /dev/null
+++ b/RelNotes/2.33.4.adoc
@@ -0,0 +1,6 @@
+Git v2.33.4 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.30.5, v2.31.4
+and v2.32.3 to address the security issue CVE-2022-29187; see
+the release notes for these versions for details.
diff --git a/RelNotes/2.33.5.adoc b/RelNotes/2.33.5.adoc
new file mode 100644
index 0000000..a636526
--- /dev/null
+++ b/RelNotes/2.33.5.adoc
@@ -0,0 +1,5 @@
+Git v2.33.5 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.30.6; see
+the release notes for that version for details.
diff --git a/RelNotes/2.33.6.adoc b/RelNotes/2.33.6.adoc
new file mode 100644
index 0000000..b63e4e6
--- /dev/null
+++ b/RelNotes/2.33.6.adoc
@@ -0,0 +1,5 @@
+Git v2.33.6 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.30.7; see
+the release notes for that version for details.
diff --git a/RelNotes/2.33.7.adoc b/RelNotes/2.33.7.adoc
new file mode 100644
index 0000000..078a837
--- /dev/null
+++ b/RelNotes/2.33.7.adoc
@@ -0,0 +1,7 @@
+Git v2.33.7 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.30.8, v2.31.7
+and v2.32.6 to address the security issues CVE-2023-22490 and
+CVE-2023-23946; see the release notes for these versions for
+details.
diff --git a/RelNotes/2.33.8.adoc b/RelNotes/2.33.8.adoc
new file mode 100644
index 0000000..d8cf4c7
--- /dev/null
+++ b/RelNotes/2.33.8.adoc
@@ -0,0 +1,7 @@
+Git v2.33.8 Release Notes
+=========================
+
+This release merges the fixes that appear in v2.30.9, v2.31.8 and
+v2.32.7 to address the security issues CVE-2023-25652,
+CVE-2023-25815, and CVE-2023-29007; see the release notes for these
+versions for details.
diff --git a/RelNotes/2.34.0.adoc b/RelNotes/2.34.0.adoc
new file mode 100644
index 0000000..75d4fdf
--- /dev/null
+++ b/RelNotes/2.34.0.adoc
@@ -0,0 +1,438 @@
+Git 2.34 Release Notes
+======================
+
+Updates since Git 2.33
+----------------------
+
+Backward compatibility notes
+
+ * The "--preserve-merges" option of "git rebase" has been removed.
+
+
+UI, Workflows & Features
+
+ * Pathname expansion (like "~username/") learned a way to specify a
+ location relative to Git installation (e.g. its $sharedir which is
+ $(prefix)/share), with "%(prefix)".
+
+ * The `ort` strategy is used instead of `recursive` as the default
+ merge strategy.
+
+ * The userdiff pattern for "java" language has been updated.
+
+ * "git rebase" by default skips changes that are equivalent to
+ commits that are already in the history the branch is rebased onto;
+ give messages when this happens to let the users be aware of
+ skipped commits, and also teach them how to tell "rebase" to keep
+ duplicated changes.
+
+ * The advice message that "git cherry-pick" gives when it asks
+ conflicted replay of a commit to be resolved by the end user has
+ been updated.
+
+ * After "git clone --recurse-submodules", all submodules are cloned
+ but they are not by default recursed into by other commands. With
+ submodule.stickyRecursiveClone configuration set, submodule.recurse
+ configuration is set to true in a repository created by "clone"
+ with "--recurse-submodules" option.
+
+ * The logic for auto-correction of misspelt subcommands learned to go
+ interactive when the help.autocorrect configuration variable is set
+ to 'prompt'.
+
+ * "git maintenance" scheduler learned to use systemd timers as a
+ possible backend.
+
+ * "git diff --submodule=diff" showed failure from run_command() when
+ trying to run diff inside a submodule, when the user manually
+ removes the submodule directory.
+
+ * "git bundle unbundle" learned to show progress display.
+
+ * In cone mode, the sparse-index code path learned to remove ignored
+ files (like build artifacts) outside the sparse cone, allowing the
+ entire directory outside the sparse cone to be removed, which is
+ especially useful when the sparse patterns change.
+
+ * Taking advantage of the CGI interface, http-backend has been
+ updated to enable protocol v2 automatically when the other side
+ asks for it.
+
+ * The credential-cache helper has been adjusted to Windows.
+
+ * The error in "git help no-such-git-command" is handled better.
+
+ * The unicode character width table (used for output alignment) has
+ been updated.
+
+ * The ref iteration code used to optionally allow dangling refs to be
+ shown, which has been tightened up.
+
+ * "git add", "git mv", and "git rm" have been adjusted to avoid
+ updating paths outside of the sparse-checkout definition unless
+ the user specifies a "--sparse" option.
+
+ * "git repack" has been taught to generate multi-pack reachability
+ bitmaps.
+
+ * "git fsck" has been taught to report mismatch between expected and
+ actual types of an object better.
+
+ * In addition to GnuPG, ssh public crypto can be used for object and
+ push-cert signing. Note that this feature cannot be used with
+ ssh-keygen from OpenSSH 8.7, whose support for it is broken. Avoid
+ using it unless you update to OpenSSH 8.8.
+
+ * "git log --grep=string --author=name" learns to highlight hits just
+ like "git grep string" does.
+
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * "git bisect" spawned "git show-branch" only to pretty-print the
+ title of the commit after checking out the next version to be
+ tested; this has been rewritten in C.
+
+ * "git add" can work better with the sparse index.
+
+ * Support for ancient versions of cURL library (pre 7.19.4) has been
+ dropped.
+
+ * A handful of tests that assumed implementation details of files
+ backend for refs have been cleaned up.
+
+ * trace2 logs learned to show parent process name to see in what
+ context Git was invoked.
+
+ * Loading of ref tips to prepare for common ancestry negotiation in
+ "git fetch-pack" has been optimized by taking advantage of the
+ commit graph when available.
+
+ * Remind developers that the userdiff patterns should be kept simple
+ and permissive, assuming that the contents they apply are always
+ syntactically correct.
+
+ * The current implementation of GIT_TEST_FAIL_PREREQS is broken in
+ that checking for the lack of a prerequisite would not work. Avoid
+ the use of "if ! test_have_prereq X" in a test script.
+
+ * The revision traversal API has been optimized by taking advantage
+ of the commit-graph, when available, to determine if a commit is
+ reachable from any of the existing refs.
+
+ * "git fetch --quiet" optimization to avoid useless computation of
+ info that will never be displayed.
+
+ * Callers from older advice_config[] based API has been updated to
+ use the newer advice_if_enabled() and advice_enabled() API.
+
+ * Teach "test_pause" and "debug" helpers to allow using the HOME and
+ TERM environment variables the user usually uses.
+
+ * "make INSTALL_STRIP=-s install" allows the installation step to use
+ "install -s" to strip the binaries as they get installed.
+
+ * Code that handles large number of refs in the "git fetch" code
+ path has been optimized.
+
+ * The reachability bitmap file used to be generated only for a single
+ pack, but now we've learned to generate bitmaps for history that
+ span across multiple packfiles.
+
+ * The code to make "git grep" recurse into submodules has been
+ updated to migrate away from the "add submodule's object store as
+ an alternate object store" mechanism (which is suboptimal).
+
+ * The tracing of process ancestry information has been enhanced.
+
+ * Reduce number of write(2) system calls while sending the
+ ref advertisement.
+
+ * Update the build procedure to use the "-pedantic" build when
+ DEVELOPER makefile macro is in effect.
+
+ * Large part of "git submodule add" gets rewritten in C.
+
+ * The run-command API has been updated so that the callers can easily
+ ask the file descriptors open for packfiles to be closed immediately
+ before spawning commands that may trigger auto-gc.
+
+ * An oddball OPTION_ARGUMENT feature has been removed from the
+ parse-options API.
+
+ * The mergesort implementation used to sort linked list has been
+ optimized.
+
+ * Remove external declaration of functions that no longer exist.
+
+ * "git multi-pack-index write --bitmap" learns to propagate the
+ hashcache from original bitmap to resulting bitmap.
+
+ * CI learns to run the leak sanitizer builds.
+
+ * "git grep --recurse-submodules" takes trees and blobs from the
+ submodule repository, but the textconv settings when processing a
+ blob from the submodule is not taken from the submodule repository.
+ A test is added to demonstrate the issue, without fixing it.
+
+ * Teach "git help -c" into helping the command line completion of
+ configuration variables.
+
+ * When "git cmd -h" shows more than one line of usage text (e.g.
+ the cmd subcommand may take sub-sub-command), parse-options API
+ learned to align these lines, even across i18n/l10n.
+
+ * Prevent "make sparse" from running for the source files that
+ haven't been modified.
+
+ * The code path to write a new version of .midx multi-pack index files
+ has learned to release the mmaped memory holding the current
+ version of .midx before removing them from the disk, as some
+ platforms do not allow removal of a file that still has mapping.
+
+ * A new feature has been added to abort early in the test framework.
+
+
+Fixes since v2.33
+-----------------
+
+ * Input validation of "git pack-objects --stdin-packs" has been
+ corrected.
+
+ * Bugfix for common ancestor negotiation recently introduced in "git
+ push" code path.
+
+ * "git pull" had various corner cases that were not well thought out
+ around its --rebase backend, e.g. "git pull --ff-only" did not stop
+ but went ahead and rebased when the history on other side is not a
+ descendant of our history. The series tries to fix them up.
+
+ * "git apply" miscounted the bytes and failed to read to the end of
+ binary hunks.
+
+ * "git range-diff" code clean-up.
+
+ * "git commit --fixup" now works with "--edit" again, after it was
+ broken in v2.32.
+
+ * Use upload-artifacts v1 (instead of v2) for 32-bit linux, as the
+ new version has a blocker bug for that architecture.
+
+ * Checking out all the paths from HEAD during the last conflicted
+ step in "git rebase" and continuing would cause the step to be
+ skipped (which is expected), but leaves MERGE_MSG file behind in
+ $GIT_DIR and confuses the next "git commit", which has been
+ corrected.
+
+ * Various bugs in "git rebase -r" have been fixed.
+
+ * mmap() imitation used to call xmalloc() that dies upon malloc()
+ failure, which has been corrected to just return an error to the
+ caller to be handled.
+
+ * "git diff --relative" segfaulted and/or produced incorrect result
+ when there are unmerged paths.
+
+ * The delayed checkout code path in "git checkout" etc. were chatty
+ even when --quiet and/or --no-progress options were given.
+
+ * "git branch -D <branch>" used to refuse to remove a broken branch
+ ref that points at a missing commit, which has been corrected.
+
+ * Build update for Apple clang.
+
+ * The parser for the "--nl" option of "git column" has been
+ corrected.
+
+ * "git upload-pack" which runs on the other side of "git fetch"
+ forgot to take the ref namespaces into account when handling
+ want-ref requests.
+
+ * The sparse-index support can corrupt the index structure by storing
+ a stale and/or uninitialized data, which has been corrected.
+
+ * Buggy tests could damage repositories outside the throw-away test
+ area we created. We now by default export GIT_CEILING_DIRECTORIES
+ to limit the damage from such a stray test.
+
+ * Even when running "git send-email" without its own threaded
+ discussion support, a threading related header in one message is
+ carried over to the subsequent message to result in an unwanted
+ threading, which has been corrected.
+
+ * The output from "git fast-export", when its anonymization feature
+ is in use, showed an annotated tag incorrectly.
+
+ * Recent "diff -m" changes broke "gitk", which has been corrected.
+
+ * The "git apply -3" code path learned not to bother the lower level
+ merge machinery when the three-way merge can be trivially resolved
+ without the content level merge. This fixes a regression caused by
+ recent "-3way first and fall back to direct application" change.
+
+ * The code that optionally creates the *.rev reverse index file has
+ been optimized to avoid needless computation when it is not writing
+ the file out.
+
+ * "git range-diff -I... <range> <range>" segfaulted, which has been
+ corrected.
+
+ * The order in which various files that make up a single (conceptual)
+ packfile has been reevaluated and straightened up. This matters in
+ correctness, as an incomplete set of files must not be shown to a
+ running Git.
+
+ * The "mode" word is useless in a call to open(2) that does not
+ create a new file. Such a call in the files backend of the ref
+ subsystem has been cleaned up.
+
+ * "git update-ref --stdin" failed to flush its output as needed,
+ which potentially led the conversation to a deadlock.
+
+ * When "git am --abort" fails to abort correctly, it still exited
+ with exit status of 0, which has been corrected.
+
+ * Correct nr and alloc members of strvec struct to be of type size_t.
+
+ * "git stash", where the tentative change involves changing a
+ directory to a file (or vice versa), was confused, which has been
+ corrected.
+
+ * "git clone" from a repository whose HEAD is unborn into a bare
+ repository didn't follow the branch name the other side used, which
+ is corrected.
+
+ * "git cvsserver" had a long-standing bug in its authentication code,
+ which has finally been corrected (it is unclear and is a separate
+ question if anybody is seriously using it, though).
+
+ * "git difftool --dir-diff" mishandled symbolic links.
+
+ * Sensitive data in the HTTP trace were supposed to be redacted, but
+ we failed to do so in HTTP/2 requests.
+
+ * "make clean" has been updated to remove leftover .depend/
+ directories, even when it is not told to use them to compute header
+ dependencies.
+
+ * Protocol v0 clients can get stuck parsing a malformed feature line.
+
+ * A few kinds of changes "git status" can show were not documented.
+ (merge d2a534c515 ja/doc-status-types-and-copies later to maint).
+
+ * The mergesort implementation used to sort linked list has been
+ optimized.
+ (merge c90cfc225b rs/mergesort later to maint).
+
+ * An editor session launched during a Git operation (e.g. during 'git
+ commit') can leave the terminal in a funny state. The code path
+ has updated to save the terminal state before, and restore it
+ after, it spawns an editor.
+ (merge 3d411afabc cm/save-restore-terminal later to maint).
+
+ * "git cat-file --batch" with the "--batch-all-objects" option is
+ supposed to iterate over all the objects found in a repository, but
+ it used to translate these object names using the replace mechanism,
+ which defeats the point of enumerating all objects in the repository.
+ This has been corrected.
+ (merge bf972896d7 jk/cat-file-batch-all-wo-replace later to maint).
+
+ * Recent sparse-index work broke safety against attempts to add paths
+ with trailing slashes to the index, which has been corrected.
+ (merge c8ad9d04c6 rs/make-verify-path-really-verify-again later to maint).
+
+ * The "--color-lines" and "--color-by-age" options of "git blame"
+ have been missing, which are now documented.
+ (merge 8c32856133 bs/doc-blame-color-lines later to maint).
+
+ * The PATH used in CI job may be too wide and let incompatible dlls
+ to be grabbed, which can cause the build&test to fail. Tighten it.
+ (merge 7491ef6198 js/windows-ci-path-fix later to maint).
+
+ * Avoid performance measurements from getting ruined by gc and other
+ housekeeping pauses interfering in the middle.
+ (merge be79131a53 rs/disable-gc-during-perf-tests later to maint).
+
+ * Stop "git add --dry-run" from creating new blob and tree objects.
+ (merge e578d0311d rs/add-dry-run-without-objects later to maint).
+
+ * "git commit" gave duplicated error message when the object store
+ was unwritable, which has been corrected.
+ (merge 4ef91a2d79 ab/fix-commit-error-message-upon-unwritable-object-store later to maint).
+
+ * Recent sparse-index addition, namely any use of index_name_pos(),
+ can expand sparse index entries and breaks any code that walks
+ cache-tree or existing index entries. One such instance of such a
+ breakage has been corrected.
+
+ * The xxdiff difftool backend can exit with status 128, which the
+ difftool-helper that launches the backend takes as a significant
+ failure, when it is not significant at all. Work it around.
+ (merge 571f4348dd da/mergetools-special-case-xxdiff-exit-128 later to maint).
+
+ * Improve test framework around unwritable directories.
+ (merge 5d22e18965 ab/test-cleanly-recreate-trash-directory later to maint).
+
+ * "git push" client talking to an HTTP server did not diagnose the
+ lack of the final status report from the other side correctly,
+ which has been corrected.
+ (merge c5c3486f38 jk/http-push-status-fix later to maint).
+
+ * Update "git archive" documentation and give explicit mention on the
+ compression level for both zip and tar.gz format.
+ (merge c4b208c309 bs/archive-doc-compression-level later to maint).
+
+ * Drop "git sparse-checkout" from the list of common commands.
+ (merge 6a9a50a8af sg/sparse-index-not-that-common-a-command later to maint).
+
+ * "git branch -c/-m new old" was not described to copy config, which
+ has been corrected.
+ (merge 8252ec300e jc/branch-copy-doc later to maint).
+
+ * Squelch over-eager warning message added during this cycle.
+
+ * Fix long-standing shell syntax error in the completion script.
+ (merge 46b0585286 re/completion-fix-test-equality later to maint).
+
+ * Teach "git commit-graph" command not to allow using replace objects
+ at all, as we do not use the commit-graph at runtime when we see
+ object replacement.
+ (merge 095d112f8c ab/ignore-replace-while-working-on-commit-graph later to maint).
+
+ * "git pull --no-verify" did not affect the underlying "git merge".
+ (merge 47bfdfb3fd ar/fix-git-pull-no-verify later to maint).
+
+ * One CI task based on Fedora image noticed a not-quite-kosher
+ construct recently, which has been corrected.
+
+ * "git pull --ff-only" and "git pull --rebase --ff-only" should make
+ it a no-op to attempt pulling from a remote that is behind us, but
+ instead the command errored out by saying it was impossible to
+ fast-forward, which may technically be true, but not a useful thing
+ to diagnose as an error. This has been corrected.
+ (merge 361cb52383 jc/fix-pull-ff-only-when-already-up-to-date later to maint).
+
+ * The way Cygwin emulates a unix-domain socket, on top of which the
+ simple-ipc mechanism is implemented, can race with the program on
+ the other side that wants to use the socket, and briefly make it
+ appear as a regular file before lstat(2) starts reporting it as a
+ socket. We now have a workaround on the side that connects to a
+ unix domain socket.
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge f188160be9 ab/bundle-remove-verbose-option later to maint).
+ (merge 8c6b4332b4 rs/close-pack-leakfix later to maint).
+ (merge 51b04c05b7 bs/difftool-msg-tweak later to maint).
+ (merge dd20e4a6db ab/make-compdb-fix later to maint).
+ (merge 6ffb990dc4 os/status-docfix later to maint).
+ (merge 100c2da2d3 rs/p3400-lose-tac later to maint).
+ (merge 76f3b69896 tb/aggregate-ignore-leading-whitespaces later to maint).
+ (merge 6e4fd8bfcd tz/doc-link-to-bundle-format-fix later to maint).
+ (merge f6c013dfa1 jc/doc-commit-header-continuation-line later to maint).
+ (merge ec9a37d69b ab/pkt-line-cleanup later to maint).
+ (merge 8650c6298c ab/fix-make-lint-docs later to maint).
+ (merge 1c720357ce ab/test-lib-diff-cleanup later to maint).
+ (merge 6b615dbece ks/submodule-add-message-fix later to maint).
+ (merge 203eb8381a jc/doc-format-patch-clarify-auto-base later to maint).
+ (merge 559664c792 ab/test-lib later to maint).
diff --git a/RelNotes/2.34.1.adoc b/RelNotes/2.34.1.adoc
new file mode 100644
index 0000000..ad404e9
--- /dev/null
+++ b/RelNotes/2.34.1.adoc
@@ -0,0 +1,23 @@
+Git v2.34.1 Release Notes
+=========================
+
+This release is primarily to fix a handful of regressions in Git 2.34.
+
+Fixes since v2.34
+-----------------
+
+ * "git grep" looking in a blob that has non-UTF8 payload was
+ completely broken when linked with certain versions of PCREv2
+ library in the latest release.
+
+ * "git pull" with any strategy when the other side is behind us
+ should succeed as it is a no-op, but doesn't.
+
+ * An earlier change in 2.34.0 caused JGit application (that abused
+ GIT_EDITOR mechanism when invoking "git config") to get stuck with
+ a SIGTTOU signal; it has been reverted.
+
+ * An earlier change that broke .gitignore matching has been reverted.
+
+ * SubmittingPatches document gained a syntactically incorrect mark-up,
+ which has been corrected.
diff --git a/RelNotes/2.34.2.adoc b/RelNotes/2.34.2.adoc
new file mode 100644
index 0000000..0c32cd8
--- /dev/null
+++ b/RelNotes/2.34.2.adoc
@@ -0,0 +1,6 @@
+Git v2.34.2 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.30.3, v2.31.2,
+v2.32.1 and v2.33.2 to address the security issue CVE-2022-24765;
+see the release notes for these versions for details.
diff --git a/RelNotes/2.34.3.adoc b/RelNotes/2.34.3.adoc
new file mode 100644
index 0000000..10f6171
--- /dev/null
+++ b/RelNotes/2.34.3.adoc
@@ -0,0 +1,4 @@
+Git Documentation/RelNotes/2.34.3.txt Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.34.3.
diff --git a/RelNotes/2.34.4.adoc b/RelNotes/2.34.4.adoc
new file mode 100644
index 0000000..2a6b223
--- /dev/null
+++ b/RelNotes/2.34.4.adoc
@@ -0,0 +1,6 @@
+Git v2.34.4 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.30.5, v2.31.4,
+v2.32.3 and v2.33.4 to address the security issue CVE-2022-29187;
+see the release notes for these versions for details.
diff --git a/RelNotes/2.34.5.adoc b/RelNotes/2.34.5.adoc
new file mode 100644
index 0000000..0e89992
--- /dev/null
+++ b/RelNotes/2.34.5.adoc
@@ -0,0 +1,5 @@
+Git v2.34.5 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.30.6; see
+the release notes for that version for details.
diff --git a/RelNotes/2.34.6.adoc b/RelNotes/2.34.6.adoc
new file mode 100644
index 0000000..b32080d
--- /dev/null
+++ b/RelNotes/2.34.6.adoc
@@ -0,0 +1,5 @@
+Git v2.34.6 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.30.7; see
+the release notes for that version for details.
diff --git a/RelNotes/2.34.7.adoc b/RelNotes/2.34.7.adoc
new file mode 100644
index 0000000..88898ad
--- /dev/null
+++ b/RelNotes/2.34.7.adoc
@@ -0,0 +1,7 @@
+Git v2.34.7 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.30.8, v2.31.7,
+v2.32.6 and v2.33.7 to address the security issues CVE-2023-22490
+and CVE-2023-23946; see the release notes for these versions
+for details.
diff --git a/RelNotes/2.34.8.adoc b/RelNotes/2.34.8.adoc
new file mode 100644
index 0000000..2b5bd7d
--- /dev/null
+++ b/RelNotes/2.34.8.adoc
@@ -0,0 +1,7 @@
+Git v2.34.8 Release Notes
+=========================
+
+This release merges the fixes that appear in v2.30.9, v2.31.8,
+v2.32.7 and v2.33.8 to address the security issues CVE-2023-25652,
+CVE-2023-25815, and CVE-2023-29007; see the release notes for these
+versions for details.
diff --git a/RelNotes/2.35.0.adoc b/RelNotes/2.35.0.adoc
new file mode 100644
index 0000000..d69b50d
--- /dev/null
+++ b/RelNotes/2.35.0.adoc
@@ -0,0 +1,412 @@
+Git 2.35 Release Notes
+======================
+
+Updates since Git 2.34
+----------------------
+
+Backward compatibility warts
+
+ * "_" is now treated as any other URL-valid characters in an URL when
+ matching the per-URL configuration variable names.
+
+ * The color palette used by "git grep" has been updated to match that
+ of GNU grep.
+
+
+Note to those who build from the source
+
+ * You may need to define NO_UNCOMPRESS2 Makefile macro if you build
+ with zlib older than 1.2.9.
+
+ * If your compiler cannot grok C99, the build will fail. See the
+ instruction at the beginning of git-compat-util.h if this happens
+ to you.
+
+
+UI, Workflows & Features
+
+ * "git status --porcelain=v2" now show the number of stash entries
+ with --show-stash like the normal output does.
+
+ * "git stash" learned the "--staged" option to stash away what has
+ been added to the index (and nothing else).
+
+ * "git var GIT_DEFAULT_BRANCH" is a way to see what name is used for
+ the newly created branch if "git init" is run.
+
+ * Various operating modes of "git reset" have been made to work
+ better with the sparse index.
+
+ * "git submodule deinit" for a submodule whose .git metadata
+ directory is embedded in its working tree refused to work, until
+ the submodule gets converted to use the "absorbed" form where the
+ metadata directory is stored in superproject, and a gitfile at the
+ top-level of the working tree of the submodule points at it. The
+ command is taught to convert such submodules to the absorbed form
+ as needed.
+
+ * The completion script (in contrib/) learns that the "--date"
+ option of commands from the "git log" family takes "human" and
+ "auto" as valid values.
+
+ * "Zealous diff3" style of merge conflict presentation has been added.
+
+ * The "git log --format=%(describe)" placeholder has been extended to
+ allow passing selected command-line options to the underlying "git
+ describe" command.
+
+ * "default" and "reset" have been added to our color palette.
+
+ * The cryptographic signing using ssh keys can specify literal keys
+ for keytypes whose name do not begin with the "ssh-" prefix by
+ using the "key::" prefix mechanism (e.g. "key::ecdsa-sha2-nistp256").
+
+ * "git fetch" without the "--update-head-ok" option ought to protect
+ a checked out branch from getting updated, to prevent the working
+ tree that checks it out to go out of sync. The code was written
+ before the use of "git worktree" got widespread, and only checked
+ the branch that was checked out in the current worktree, which has
+ been updated.
+
+ * "git name-rev" has been tweaked to give output that is shorter and
+ easier to understand.
+
+ * "git apply" has been taught to ignore a message without a patch
+ with the "--allow-empty" option. It also learned to honor the
+ "--quiet" option given from the command line.
+
+ * The "init" and "set" subcommands in "git sparse-checkout" have been
+ unified for a better user experience and performance.
+
+ * Many git commands that deal with working tree files try to remove a
+ directory that becomes empty (i.e. "git switch" from a branch that
+ has the directory to another branch that does not would attempt
+ remove all files in the directory and the directory itself). This
+ drops users into an unfamiliar situation if the command was run in
+ a subdirectory that becomes subject to removal due to the command.
+ The commands have been taught to keep an empty directory if it is
+ the directory they were started in to avoid surprising users.
+
+ * "git am" learns "--empty=(stop|drop|keep)" option to tweak what is
+ done to a piece of e-mail without a patch in it.
+
+ * The default merge message prepared by "git merge" records the name
+ of the current branch; the name can be overridden with a new option
+ to allow users to pretend a merge is made on a different branch.
+
+ * The way "git p4" shows file sizes in its output has been updated to
+ use human-readable units.
+
+ * "git -c branch.autosetupmerge=inherit branch new old" makes "new"
+ to have the same upstream as the "old" branch, instead of marking
+ "old" itself as its upstream.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * The use of errno as a means to carry the nature of error in the ref
+ API implementation has been reworked and reduced.
+
+ * Teach and encourage first-time contributors to this project to
+ state the base commit when they submit their topic.
+
+ * The command line completion for "git send-email" options have been
+ tweaked to make it easier to keep it in sync with the command itself.
+
+ * Ensure that the sparseness of the in-core index matches the
+ index.sparse configuration specified by the repository immediately
+ after the on-disk index file is read.
+
+ * Code clean-up to eventually allow information on remotes defined
+ for an arbitrary repository to be read.
+
+ * Build optimization.
+
+ * Tighten code for testing pack-bitmap.
+
+ * Weather balloon to break people with compilers that do not support
+ C99.
+
+ * The "reftable" backend for the refs API, without integrating into
+ the refs subsystem, has been added.
+
+ * More tests are marked as leak-free.
+
+ * The test framework learns to list unsatisfied test prerequisites,
+ and optionally error out when prerequisites that are expected to be
+ satisfied are not.
+
+ * The default setting for trace2 event nesting was too low to cause
+ test failures, which is worked around by bumping it up in the test
+ framework.
+
+ * Drop support for TravisCI and update test workflows at GitHub.
+
+ * Many tests that used to need GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
+ mechanism to force "git" to use 'master' as the default name for
+ the initial branch no longer need it; the use of the mechanism from
+ them have been removed.
+
+ * Allow running our tests while disabling fsync.
+
+ * Document the parameters given to the reflog entry iterator callback
+ functions.
+ (merge e6e94f34b2 jc/reflog-iterator-callback-doc later to maint).
+
+ * The test helper for refs subsystem learned to write bogus and/or
+ nonexistent object name to refs to simulate error situations we
+ want to test Git in.
+
+ * "diff --histogram" optimization.
+
+ * Weather balloon to find compilers that do not grok variable
+ declaration in the for() loop.
+
+ * diff and blame commands have been taught to work better with sparse
+ index.
+
+ * The chainlint test script linter in the test suite has been updated.
+
+ * The DEVELOPER=yes build uses -std=gnu99 now.
+
+ * "git format-patch" uses a single rev_info instance and then exits.
+ Mark the structure with UNLEAK() macro to squelch leak sanitizer.
+
+ * New interface into the tmp-objdir API to help in-core use of the
+ quarantine feature.
+
+ * Broken &&-chains in the test scripts have been corrected.
+
+ * The RCS keyword substitution in "git p4" used to be done assuming
+ that the contents are UTF-8 text, which can trigger decoding
+ errors. We now treat the contents as a bytestring for robustness
+ and correctness.
+
+ * The conditions to choose different definitions of the FLEX_ARRAY
+ macro for vendor compilers has been simplified to make it easier to
+ maintain.
+
+ * Correctness and performance update to "diff --color-moved" feature.
+
+ * "git upload-pack" (the other side of "git fetch") used a 8kB buffer
+ but most of its payload came on 64kB "packets". The buffer size
+ has been enlarged so that such a packet fits.
+
+ * "git fetch" and "git pull" are now declared sparse-index clean.
+ Also "git ls-files" learns the "--sparse" option to help debugging.
+
+ * Similar message templates have been consolidated so that
+ translators need to work on fewer number of messages.
+
+
+Fixes since v2.34
+-----------------
+
+ * "git grep" looking in a blob that has non-UTF8 payload was
+ completely broken when linked with certain versions of PCREv2
+ library in the latest release.
+
+ * Other code cleanup, docfix, build fix, etc.
+
+ * "git pull" with any strategy when the other side is behind us
+ should succeed as it is a no-op, but doesn't.
+
+ * An earlier change in 2.34.0 caused JGit application (that abused
+ GIT_EDITOR mechanism when invoking "git config") to get stuck with
+ a SIGTTOU signal; it has been reverted.
+
+ * An earlier change that broke .gitignore matching has been reverted.
+
+ * Things like "git -c branch.sort=bogus branch new HEAD", i.e. the
+ operation modes of the "git branch" command that do not need the
+ sort key information, no longer errors out by seeing a bogus sort
+ key.
+ (merge 98e7ab6d42 jc/fix-ref-sorting-parse later to maint).
+
+ * The compatibility implementation for unsetenv(3) were written to
+ mimic ancient, non-POSIX, variant seen in an old glibc; it has been
+ changed to return an integer to match the more modern era.
+ (merge a38989bd5b jc/unsetenv-returns-an-int later to maint).
+
+ * The clean/smudge conversion code path has been prepared to better
+ work on platforms where ulong is narrower than size_t.
+ (merge 596b5e77c9 mc/clean-smudge-with-llp64 later to maint).
+
+ * Redact the path part of packfile URI that appears in the trace output.
+ (merge 0ba558ffb1 if/redact-packfile-uri later to maint).
+
+ * CI has been taught to catch some Unicode directional formatting
+ sequence that can be used in certain mischief.
+ (merge 0e7696c64d js/ci-no-directional-formatting later to maint).
+
+ * The "--date=format:<strftime>" gained a workaround for the lack of
+ system support for a non-local timezone to handle "%s" placeholder.
+ (merge 9b591b9403 jk/strbuf-addftime-seconds-since-epoch later to maint).
+
+ * The "merge" subcommand of "git jump" (in contrib/) silently ignored
+ pathspec and other parameters.
+ (merge 67ba13e5a4 jk/jump-merge-with-pathspec later to maint).
+
+ * The code to decode the length of packed object size has been
+ corrected.
+ (merge 34de5b8eac jt/pack-header-lshift-overflow later to maint).
+
+ * The advice message given by "git pull" when the user hasn't made a
+ choice between merge and rebase still said that the merge is the
+ default, which no longer is the case. This has been corrected.
+ (merge 71076d0edd ah/advice-pull-has-no-preference-between-rebase-and-merge later to maint).
+
+ * "git fetch", when received a bad packfile, can fail with SIGPIPE.
+ This wasn't wrong per-se, but we now detect the situation and fail
+ in a more predictable way.
+ (merge 2a4aed42ec jk/fetch-pack-avoid-sigpipe-to-index-pack later to maint).
+
+ * The function to cull a child process and determine the exit status
+ had two separate code paths for normal callers and callers in a
+ signal handler, and the latter did not yield correct value when the
+ child has caught a signal. The handling of the exit status has
+ been unified for these two code paths. An existing test with
+ flakiness has also been corrected.
+ (merge 5263e22cba jk/t7006-sigpipe-tests-fix later to maint).
+
+ * When a non-existent program is given as the pager, we tried to
+ reuse an uninitialized child_process structure and crashed, which
+ has been fixed.
+ (merge f917f57f40 em/missing-pager later to maint).
+
+ * The single-key-input mode in "git add -p" had some code to handle
+ keys that generate a sequence of input via ReadKey(), which did not
+ handle end-of-file correctly, which has been fixed.
+ (merge fc8a8126df cb/add-p-single-key-fix later to maint).
+
+ * "git rebase -x" added an unnecessary 'exec' instructions before
+ 'noop', which has been corrected.
+ (merge cc9dcdee61 en/rebase-x-fix later to maint).
+
+ * When the "git push" command is killed while the receiving end is
+ trying to report what happened to the ref update proposals, the
+ latter used to die, due to SIGPIPE. The code now ignores SIGPIPE
+ to increase our chances to run the post-receive hook after it
+ happens.
+ (merge d34182b9e3 rj/receive-pack-avoid-sigpipe-during-status-reporting later to maint).
+
+ * "git worktree add" showed "Preparing worktree" message to the
+ standard output stream, but when it failed, the message from die()
+ went to the standard error stream. Depending on the order the
+ stdio streams are flushed at the program end, this resulted in
+ confusing output. It has been corrected by sending all the chatty
+ messages to the standard error stream.
+ (merge b50252484f es/worktree-chatty-to-stderr later to maint).
+
+ * Coding guideline document has been updated to clarify what goes to
+ standard error in our system.
+ (merge e258eb4800 es/doc-stdout-vs-stderr later to maint).
+
+ * The sparse-index/sparse-checkout feature had a bug in its use of
+ the matching code to determine which path is in or outside the
+ sparse checkout patterns.
+ (merge 8c5de0d265 ds/sparse-deep-pattern-checkout-fix later to maint).
+
+ * "git rebase -x" by mistake started exporting the GIT_DIR and
+ GIT_WORK_TREE environment variables when the command was rewritten
+ in C, which has been corrected.
+ (merge 434e0636db en/rebase-x-wo-git-dir-env later to maint).
+
+ * When "git log" implicitly enabled the "decoration" processing
+ without being explicitly asked with "--decorate" option, it failed
+ to read and honor the settings given by the "--decorate-refs"
+ option.
+
+ * "git fetch --set-upstream" did not check if there is a current
+ branch, leading to a segfault when it is run on a detached HEAD,
+ which has been corrected.
+ (merge 17baeaf82d ab/fetch-set-upstream-while-detached later to maint).
+
+ * Among some code paths that ask an yes/no question, only one place
+ gave a prompt that looked different from the others, which has been
+ updated to match what the others create.
+ (merge 0fc8ed154c km/help-prompt-fix later to maint).
+
+ * "git log --invert-grep --author=<name>" used to exclude commits
+ written by the given author, but now "--invert-grep" only affects
+ the matches made by the "--grep=<pattern>" option.
+ (merge 794c000267 rs/log-invert-grep-with-headers later to maint).
+
+ * "git grep --perl-regexp" failed to match UTF-8 characters with
+ wildcard when the pattern consists only of ASCII letters, which has
+ been corrected.
+ (merge 32e3e8bc55 rs/pcre2-utf later to maint).
+
+ * Certain sparse-checkout patterns that are valid in non-cone mode
+ led to segfault in cone mode, which has been corrected.
+
+ * Use of certain "git rev-list" options with "git fast-export"
+ created nonsense results (the worst two of which being "--reverse"
+ and "--invert-grep --grep=<foo>"). The use of "--first-parent" is
+ made to behave a bit more sensible than before.
+ (merge 726a228dfb ws/fast-export-with-revision-options later to maint).
+
+ * Perf tests were run with end-user's shell, but it has been
+ corrected to use the shell specified by $TEST_SHELL_PATH.
+ (merge 9ccab75608 ja/perf-use-specified-shell later to maint).
+
+ * Fix dependency rules to generate hook-list.h header file.
+ (merge d3fd1a6667 ab/makefile-hook-list-dependency-fix later to maint).
+
+ * "git stash" by default triggers its "push" action, but its
+ implementation also made "git stash -h" to show short help only for
+ "git stash push", which has been corrected.
+ (merge ca7990cea5 ab/do-not-limit-stash-help-to-push later to maint).
+
+ * "git apply --3way" bypasses the attempt to do a three-way
+ application in more cases to address the regression caused by the
+ recent change to use direct application as a fallback.
+ (merge 34d607032c jz/apply-3-corner-cases later to maint).
+
+ * Fix performance-releated bug in "git subtree" (in contrib/).
+ (merge 3ce8888fb4 jl/subtree-check-parents-argument-passing-fix later to maint).
+
+ * Extend the guidance to choose the base commit to build your work
+ on, and hint/nudge contributors to read others' changes.
+ (merge fdfae830f8 jc/doc-submitting-patches-choice-of-base later to maint).
+
+ * A corner case bug in the ort merge strategy has been corrected.
+ (merge d30126c20d en/merge-ort-renorm-with-rename-delete-conflict-fix later to maint).
+
+ * "git stash apply" forgot to attempt restoring untracked files when
+ it failed to restore changes to tracked ones.
+ (merge 71cade5a0b en/stash-df-fix later to maint).
+
+ * Calling dynamically loaded functions on Windows has been corrected.
+ (merge 4a9b204920 ma/windows-dynload-fix later to maint).
+
+ * Some lockfile code called free() in signal-death code path, which
+ has been corrected.
+ (merge 58d4d7f1c5 ps/lockfile-cleanup-fix later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge 74db416c9c cw/protocol-v2-doc-fix later to maint).
+ (merge f9b2b6684d ja/doc-cleanup later to maint).
+ (merge 7d1b866778 jc/fix-first-object-walk later to maint).
+ (merge 538ac74604 js/trace2-avoid-recursive-errors later to maint).
+ (merge 152923b132 jk/t5319-midx-corruption-test-deflake later to maint).
+ (merge 9081a421a6 ab/checkout-branch-info-leakfix later to maint).
+ (merge 42c456ff81 rs/mergesort later to maint).
+ (merge ad506e6780 tl/midx-docfix later to maint).
+ (merge bf5b83fd8a hk/ci-checkwhitespace-commentfix later to maint).
+ (merge 49f1eb3b34 jk/refs-g11-workaround later to maint).
+ (merge 7d3fc7df70 jt/midx-doc-fix later to maint).
+ (merge 7b089120d9 hn/create-reflog-simplify later to maint).
+ (merge 9e12400da8 cb/mingw-gmtime-r later to maint).
+ (merge 0bf0de6cc7 tb/pack-revindex-on-disk-cleanup later to maint).
+ (merge 2c68f577fc ew/cbtree-remove-unused-and-broken-cb-unlink later to maint).
+ (merge eafd6e7e55 ab/die-with-bug later to maint).
+ (merge 91028f7659 jc/grep-patterntype-default-doc later to maint).
+ (merge 47ca93d071 ds/repack-fixlets later to maint).
+ (merge e6a9bc0c60 rs/t4202-invert-grep-test-fix later to maint).
+ (merge deb5407a42 gh/gpg-doc-markup-fix later to maint).
+ (merge 999bba3e0b rs/daemon-plug-leak later to maint).
+ (merge 786eb1ba39 js/l10n-mention-ngettext-early-in-readme later to maint).
+ (merge 2f12b31b74 ab/makefile-msgfmt-wo-stats later to maint).
+ (merge 0517f591ca fs/gpg-unknown-key-test-fix later to maint).
+ (merge 97d6fb5a1f ma/header-dup-cleanup later to maint).
diff --git a/RelNotes/2.35.1.adoc b/RelNotes/2.35.1.adoc
new file mode 100644
index 0000000..726ba25
--- /dev/null
+++ b/RelNotes/2.35.1.adoc
@@ -0,0 +1,6 @@
+Git v2.35.1 Release Notes
+=========================
+
+Git 2.35 shipped with a regression that broke use of "rebase" and
+"stash" in a secondary worktree. This maintenance release ought to
+fix it.
diff --git a/RelNotes/2.35.2.adoc b/RelNotes/2.35.2.adoc
new file mode 100644
index 0000000..290bfa9
--- /dev/null
+++ b/RelNotes/2.35.2.adoc
@@ -0,0 +1,7 @@
+Git v2.35.2 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.30.3,
+v2.31.2, v2.32.1, v2.33.2 and v2.34.2 to address the security
+issue CVE-2022-24765; see the release notes for these versions
+for details.
diff --git a/RelNotes/2.35.3.adoc b/RelNotes/2.35.3.adoc
new file mode 100644
index 0000000..5458ba3
--- /dev/null
+++ b/RelNotes/2.35.3.adoc
@@ -0,0 +1,4 @@
+Git Documentation/RelNotes/2.35.3.txt Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.35.3.
diff --git a/RelNotes/2.35.4.adoc b/RelNotes/2.35.4.adoc
new file mode 100644
index 0000000..47abd5a
--- /dev/null
+++ b/RelNotes/2.35.4.adoc
@@ -0,0 +1,7 @@
+Git v2.35.4 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.30.5,
+v2.31.4, v2.32.3, v2.33.4 and v2.34.4 to address the security
+issue CVE-2022-29187; see the release notes for these versions
+for details.
diff --git a/RelNotes/2.35.5.adoc b/RelNotes/2.35.5.adoc
new file mode 100644
index 0000000..e19cc48
--- /dev/null
+++ b/RelNotes/2.35.5.adoc
@@ -0,0 +1,5 @@
+Git v2.35.5 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.30.6; see
+the release notes for that version for details.
diff --git a/RelNotes/2.35.6.adoc b/RelNotes/2.35.6.adoc
new file mode 100644
index 0000000..e7ca57b
--- /dev/null
+++ b/RelNotes/2.35.6.adoc
@@ -0,0 +1,5 @@
+Git v2.35.6 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.30.7; see
+the release notes for that version for details.
diff --git a/RelNotes/2.35.7.adoc b/RelNotes/2.35.7.adoc
new file mode 100644
index 0000000..42baabf
--- /dev/null
+++ b/RelNotes/2.35.7.adoc
@@ -0,0 +1,7 @@
+Git v2.35.7 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.30.8, v2.31.7,
+v2.32.6, v2.33.7 and v2.34.7 to address the security issues
+CVE-2023-22490 and CVE-2023-23946; see the release notes for
+these versions for details.
diff --git a/RelNotes/2.35.8.adoc b/RelNotes/2.35.8.adoc
new file mode 100644
index 0000000..3c9c094
--- /dev/null
+++ b/RelNotes/2.35.8.adoc
@@ -0,0 +1,7 @@
+Git v2.35.8 Release Notes
+=========================
+
+This release merges the fixes that appear in v2.30.9, v2.31.8,
+v2.32.7, v2.33.8 and v2.34.8 to address the security issues
+CVE-2023-25652, CVE-2023-25815, and CVE-2023-29007; see the release
+notes for these versions for details.
diff --git a/RelNotes/2.36.0.adoc b/RelNotes/2.36.0.adoc
new file mode 100644
index 0000000..e477fba
--- /dev/null
+++ b/RelNotes/2.36.0.adoc
@@ -0,0 +1,429 @@
+Git 2.36 Release Notes
+======================
+
+Updates since Git 2.35
+----------------------
+
+Backward compatibility warts
+
+ * "git name-rev --stdin" has been deprecated and issues a warning
+ when used; use "git name-rev --annotate-stdin" instead.
+
+ * "git clone --filter=... --recurse-submodules" only makes the
+ top-level a partial clone, while submodules are fully cloned. This
+ behaviour is changed to pass the same filter down to the submodules.
+
+ * With the fixes for CVE-2022-24765 that are common with versions of
+ Git 2.30.4, 2.31.3, 2.32.2, 2.33.3, 2.34.3, and 2.35.3, Git has
+ been taught not to recognise repositories owned by other users, in
+ order to avoid getting affected by their config files and hooks.
+ You can list the path to the safe/trusted repositories that may be
+ owned by others on a multi-valued configuration variable
+ `safe.directory` to override this behaviour, or use '*' to declare
+ that you trust anything.
+
+
+Note to those who build from the source
+
+ * Since Git 2.31, our source assumed that the compiler you use to
+ build Git supports variadic macros, with an easy-to-use escape
+ hatch to allow compilation without variadic macros with an request
+ to report that you had to use the escape hatch to the list.
+ Because we haven't heard from anybody who actually needed to use
+ the escape hatch, it has been removed, making support of variadic
+ macros a hard requirement.
+
+
+UI, Workflows & Features
+
+ * Assorted updates to "git cat-file", especially "-h".
+
+ * The command line completion (in contrib/) learns to complete
+ arguments to give to "git sparse-checkout" command.
+
+ * "git log --remerge-diff" shows the difference from mechanical merge
+ result and the result that is actually recorded in a merge commit.
+
+ * "git log" and friends learned an option --exclude-first-parent-only
+ to propagate UNINTERESTING bit down only along the first-parent
+ chain, just like --first-parent option shows commits that lack the
+ UNINTERESTING bit only along the first-parent chain.
+
+ * The command line completion script (in contrib/) learned to
+ complete all Git subcommands, including the ones that are normally
+ hidden, when GIT_COMPLETION_SHOW_ALL_COMMANDS is used.
+
+ * "git branch" learned the "--recurse-submodules" option.
+
+ * A user can forget to make a script file executable before giving
+ it to "git bisect run". In such a case, all tests will exit with
+ 126 or 127 error codes, even on revisions that are marked as good.
+ Try to recognize this situation and stop iteration early.
+
+ * When "index-pack" dies due to incoming data exceeding the maximum
+ allowed input size, include the value of the limit in the error
+ message.
+
+ * The error message given by "git switch HEAD~4" has been clarified
+ to suggest the "--detach" option that is required.
+
+ * In sparse-checkouts, files mis-marked as missing from the working tree
+ could lead to later problems. Such files were hard to discover, and
+ harder to correct. Automatically detecting and correcting the marking
+ of such files has been added to avoid these problems.
+
+ * "git cat-file" learns "--batch-command" mode, which is a more
+ flexible interface than the existing "--batch" or "--batch-check"
+ modes, to allow different kinds of inquiries made.
+
+ * The level of verbose output from the ort backend during inner merge
+ has been aligned to that of the recursive backend.
+
+ * "git remote rename A B", depending on the number of remote-tracking
+ refs involved, takes long time renaming them. The command has been
+ taught to show progress bar while making the user wait.
+
+ * Bundle file format gets extended to allow a partial bundle,
+ filtered by similar criteria you would give when making a
+ partial/lazy clone.
+
+ * A new built-in userdiff driver for kotlin has been added.
+
+ * "git repack" learned a new configuration to disable triggering of
+ age-old "update-server-info" command, which is rarely useful these
+ days.
+
+ * "git stash" does not allow subcommands it internally runs as its
+ implementation detail, except for "git reset", to emit messages;
+ now "git reset" part has also been squelched.
+
+ * "git ls-tree" learns "--oid-only" option, similar to "--name-only",
+ and more generalized "--format" option.
+
+ * "git fetch --refetch" learned to fetch everything without telling
+ the other side what we already have, which is useful when you
+ cannot trust what you have in the local object store.
+
+ * "git branch" gives hint when branch tracking cannot be established
+ because fetch refspecs from multiple remote repositories overlap.
+
+ * "git worktree list --porcelain" did not c-quote pathnames and lock
+ reasons with unsafe bytes correctly, which is worked around by
+ introducing NUL terminated output format with "-z".
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * "git apply" (ab)used the util pointer of the string-list to keep
+ track of how each symbolic link needs to be handled, which has been
+ simplified by using strset.
+
+ * Fix a hand-rolled alloca() imitation that may have violated
+ alignment requirement of data being sorted in compatibility
+ implementation of qsort_s() and stable qsort().
+
+ * Use the parse-options API in "git reflog" command.
+
+ * The conditional inclusion mechanism of configuration files using
+ "[includeIf <condition>]" learns to base its decision on the
+ URL of the remote repository the repository interacts with.
+ (merge 399b198489 jt/conditional-config-on-remote-url later to maint).
+
+ * "git name-rev --stdin" does not behave like usual "--stdin" at
+ all. Start the process of renaming it to "--annotate-stdin".
+ (merge a2585719b3 jc/name-rev-stdin later to maint).
+
+ * "git update-index", "git checkout-index", and "git clean" are
+ taught to work better with the sparse checkout feature.
+
+ * Use an internal call to reset_head() helper function instead of
+ spawning "git checkout" in "rebase", and update code paths that are
+ involved in the change.
+
+ * Messages "ort" merge backend prepares while dealing with conflicted
+ paths were unnecessarily confusing since it did not differentiate
+ inner merges and outer merges.
+
+ * Small modernization of the rerere-train script (in contrib/).
+
+ * Use designated initializers we started using in mid 2017 in more
+ parts of the codebase that are relatively quiescent.
+
+ * Improve failure case behaviour of xdiff library when memory
+ allocation fails.
+
+ * General clean-up in reftable implementation, including
+ clarification of the API documentation, tightening the code to
+ honor documented length limit, etc.
+
+ * Remove the escape hatch we added when we introduced the weather
+ balloon to use variadic macros unconditionally, to make it official
+ that we now have a hard dependency on the feature.
+
+ * Makefile refactoring with a bit of suffixes rule stripping to
+ optimize the runtime overhead.
+
+ * "git stash drop" is reimplemented as an internal call to
+ reflog_delete() function, instead of invoking "git reflog delete"
+ via run_command() API.
+
+ * Count string_list items in size_t, not "unsigned int".
+
+ * The single-key interactive operation used by "git add -p" has been
+ made more robust.
+
+ * Remove unneeded <meta http-equiv=content-type...> from gitweb
+ output.
+
+ * "git name-rev" learned to use the generation numbers when setting
+ the lower bound of searching commits used to explain the revision,
+ when available, instead of committer time.
+
+ * Replace core.fsyncObjectFiles with two new configuration variables,
+ core.fsync and core.fsyncMethod.
+
+ * Updates to refs traditionally weren't fsync'ed, but we can
+ configure using core.fsync variable to do so.
+
+ * "git reflog" command now uses parse-options API to parse its
+ command line options.
+
+
+Fixes since v2.35
+-----------------
+
+ * "rebase" and "stash" in secondary worktrees are broken in
+ Git 2.35.0, which has been corrected.
+
+ * "git pull --rebase" ignored the rebase.autostash configuration
+ variable when the remote history is a descendant of our history,
+ which has been corrected.
+ (merge 3013d98d7a pb/pull-rebase-autostash-fix later to maint).
+
+ * "git update-index --refresh" has been taught to deal better with
+ racy timestamps (just like "git status" already does).
+ (merge 2ede073fd2 ms/update-index-racy later to maint).
+
+ * Avoid tests that are run under GIT_TRACE2 set from failing
+ unnecessarily.
+ (merge 944d808e42 js/test-unset-trace2-parents later to maint).
+
+ * The merge-ort misbehaved when merge.renameLimit configuration is
+ set too low and failed to find all renames.
+ (merge 9ae39fef7f en/merge-ort-restart-optim-fix later to maint).
+
+ * We explain that revs come first before the pathspec among command
+ line arguments, but did not spell out that dashed options come
+ before other args, which has been corrected.
+ (merge c11f95010c tl/doc-cli-options-first later to maint).
+
+ * "git add -p" rewritten in C regressed hunk splitting in some cases,
+ which has been corrected.
+ (merge 7008ddc645 pw/add-p-hunk-split-fix later to maint).
+
+ * "git fetch --negotiate-only" is an internal command used by "git
+ push" to figure out which part of our history is missing from the
+ other side. It should never recurse into submodules even when
+ fetch.recursesubmodules configuration variable is set, nor it
+ should trigger "gc". The code has been tightened up to ensure it
+ only does common ancestry discovery and nothing else.
+ (merge de4eaae63a gc/fetch-negotiate-only-early-return later to maint).
+
+ * The code path that verifies signatures made with ssh were made to
+ work better on a system with CRLF line endings.
+ (merge caeef01ea7 fs/ssh-signing-crlf later to maint).
+
+ * "git sparse-checkout init" failed to write into $GIT_DIR/info
+ directory when the repository was created without one, which has
+ been corrected to auto-create it.
+ (merge 7f44842ac1 jt/sparse-checkout-leading-dir-fix later to maint).
+
+ * Cloning from a repository that does not yet have any branches or
+ tags but has other refs resulted in a "remote transport reported
+ error", which has been corrected.
+ (merge dccea605b6 jt/clone-not-quite-empty later to maint).
+
+ * Mark in various places in the code that the sparse index and the
+ split index features are mutually incompatible.
+ (merge 451b66c533 js/sparse-vs-split-index later to maint).
+
+ * Update the logic to compute alignment requirement for our mem-pool.
+ (merge e38bcc66d8 jc/mem-pool-alignment later to maint).
+
+ * Pick a better random number generator and use it when we prepare
+ temporary filenames.
+ (merge 47efda967c bc/csprng-mktemps later to maint).
+
+ * Update the contributor-facing documents on proposed log messages.
+ (merge cdba0295b0 jc/doc-log-messages later to maint).
+
+ * When "git fetch --prune" failed to prune the refs it wanted to
+ prune, the command issued error messages but exited with exit
+ status 0, which has been corrected.
+ (merge c9e04d905e tg/fetch-prune-exit-code-fix later to maint).
+
+ * Problems identified by Coverity in the reftable code have been
+ corrected.
+ (merge 01033de49f hn/reftable-coverity-fixes later to maint).
+
+ * A bug that made multi-pack bitmap and the object order out-of-sync,
+ making the .midx data corrupt, has been fixed.
+ (merge f8b60cf99b tb/midx-bitmap-corruption-fix later to maint).
+
+ * The build procedure has been taught to notice older version of zlib
+ and enable our replacement uncompress2() automatically.
+ (merge 07564773c2 ab/auto-detect-zlib-compress2 later to maint).
+
+ * Interaction between fetch.negotiationAlgorithm and
+ feature.experimental configuration variables has been corrected.
+ (merge 714edc620c en/fetch-negotiation-default-fix later to maint).
+
+ * "git diff --diff-filter=aR" is now parsed correctly.
+ (merge 75408ca949 js/diff-filter-negation-fix later to maint).
+
+ * When "git subtree" wants to create a merge, it used "git merge" and
+ let it be affected by end-user's "merge.ff" configuration, which
+ has been corrected.
+ (merge 9158a3564a tk/subtree-merge-not-ff-only later to maint).
+
+ * Unlike "git apply", "git patch-id" did not handle patches with
+ hunks that has only 1 line in either preimage or postimage, which
+ has been corrected.
+ (merge 757e75c81e jz/patch-id-hunk-header-parsing-fix later to maint).
+
+ * "receive-pack" checks if it will do any ref updates (various
+ conditions could reject a push) before received objects are taken
+ out of the temporary directory used for quarantine purposes, so
+ that a push that is known-to-fail will not leave crufts that a
+ future "gc" needs to clean up.
+ (merge 5407764069 cb/clear-quarantine-early-on-all-ref-update-errors later to maint).
+
+ * When there is no object to write .bitmap file for, "git
+ multi-pack-index" triggered an error, instead of just skipping,
+ which has been corrected.
+ (merge eb57277ba3 tb/midx-no-bitmap-for-no-objects later to maint).
+
+ * "git cmd -h" outside a repository should error out cleanly for many
+ commands, but instead it hit a BUG(), which has been corrected.
+ (merge 87ad07d735 js/short-help-outside-repo-fix later to maint).
+
+ * "working tree" and "per-worktree ref" were in glossary, but
+ "worktree" itself wasn't, which has been corrected.
+ (merge 2df5387ed0 jc/glossary-worktree later to maint).
+
+ * L10n support for a few error messages.
+ (merge 3d3c23b3a7 bs/forbid-i18n-of-protocol-token-in-fetch-pack later to maint).
+
+ * Test modernization.
+ (merge d4fe066e4b sy/t0001-use-path-is-helper later to maint).
+
+ * "git log --graph --graph" used to leak a graph structure, and there
+ was no way to countermand "--graph" that appear earlier on the
+ command line. A "--no-graph" option has been added and resource
+ leakage has been plugged.
+
+ * Error output given in response to an ambiguous object name has been
+ improved.
+ (merge 3a73c1dfaf ab/ambiguous-object-name later to maint).
+
+ * "git sparse-checkout" wants to work with per-worktree configuration,
+ but did not work well in a worktree attached to a bare repository.
+ (merge 3ce1138272 ds/sparse-checkout-requires-per-worktree-config later to maint).
+
+ * Setting core.untrackedCache to true failed to add the untracked
+ cache extension to the index.
+
+ * Workaround we have for versions of PCRE2 before their version 10.36
+ were in effect only for their versions newer than 10.36 by mistake,
+ which has been corrected.
+ (merge 97169fc361 rs/pcre-invalid-utf8-fix-fix later to maint).
+
+ * Document Taylor as a new member of Git PLC at SFC. Welcome.
+ (merge e8d56ca863 tb/coc-plc-update later to maint).
+
+ * "git checkout -b branch/with/multi/level/name && git stash" only
+ recorded the last level component of the branch name, which has
+ been corrected.
+
+ * Check the return value from parse_tree_indirect() to turn segfaults
+ into calls to die().
+ (merge 8d2eaf649a gc/parse-tree-indirect-errors later to maint).
+
+ * Newer version of GPGSM changed its output in a backward
+ incompatible way to break our code that parses its output. It also
+ added more processes our tests need to kill when cleaning up.
+ Adjustments have been made to accommodate these changes.
+ (merge b0b70d54c4 fs/gpgsm-update later to maint).
+
+ * The untracked cache newly computed weren't written back to the
+ on-disk index file when there is no other change to the index,
+ which has been corrected.
+
+ * "git config -h" did not describe the "--type" option correctly.
+ (merge 5445124fad mf/fix-type-in-config-h later to maint).
+
+ * The way generation number v2 in the commit-graph files are
+ (not) handled has been corrected.
+ (merge 6dbf4b8172 ds/commit-graph-gen-v2-fixes later to maint).
+
+ * The method to trigger malloc check used in our tests no longer work
+ with newer versions of glibc.
+ (merge baedc59543 ep/test-malloc-check-with-glibc-2.34 later to maint).
+
+ * When "git fetch --recurse-submodules" grabbed submodule commits
+ that would be needed to recursively check out newly fetched commits
+ in the superproject, it only paid attention to submodules that are
+ in the current checkout of the superproject. We now do so for all
+ submodules that have been run "git submodule init" on.
+
+ * "git rebase $base $non_branch_commit", when $base is an ancestor or
+ the $non_branch_commit, modified the current branch, which has been
+ corrected.
+
+ * When "shallow" information is updated, we forgot to update the
+ in-core equivalent, which has been corrected.
+
+ * When creating a loose object file, we didn't report the exact
+ filename of the file we failed to fsync, even though the
+ information was readily available, which has been corrected.
+
+ * "git am" can read from the standard input when no mailbox is given
+ on the command line, but the end-user gets no indication when it
+ happens, making Git appear stuck.
+ (merge 7b20af6a06 jc/mailsplit-warn-on-tty later to maint).
+
+ * "git mv" failed to refresh the cached stat information for the
+ entry it moved.
+ (merge b7f9130a06 vd/mv-refresh-stat later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge cfc5cf428b jc/find-header later to maint).
+ (merge 40e7cfdd46 jh/p4-fix-use-of-process-error-exception later to maint).
+ (merge 727e6ea350 jh/p4-spawning-external-commands-cleanup later to maint).
+ (merge 0a6adc26e2 rs/grep-expr-cleanup later to maint).
+ (merge 4ed7dfa713 po/readme-mention-contributor-hints later to maint).
+ (merge 6046f7a91c en/plug-leaks-in-merge later to maint).
+ (merge 8c591dbfce bc/clarify-eol-attr later to maint).
+ (merge 518e15db74 rs/parse-options-lithelp-help later to maint).
+ (merge cbac0076ef gh/doc-typos later to maint).
+ (merge ce14de03db ab/no-errno-from-resolve-ref-unsafe later to maint).
+ (merge 2826ffad8c rc/negotiate-only-typofix later to maint).
+ (merge 0f03f04c5c en/sparse-checkout-leakfix later to maint).
+ (merge 74f3390dde sy/diff-usage-typofix later to maint).
+ (merge 45d0212a71 ll/doc-mktree-typofix later to maint).
+ (merge e9b272e4c1 js/no-more-legacy-stash later to maint).
+ (merge 6798b08e84 ab/do-not-hide-failures-in-git-dot-pm later to maint).
+ (merge 9325285df4 po/doc-check-ignore-markup-fix later to maint).
+ (merge cd26cd6c7c sy/modernize-t-lib-read-tree-m-3way later to maint).
+ (merge d17294a05e ab/hash-object-leakfix later to maint).
+ (merge b8403129d3 jd/t0015-modernize later to maint).
+ (merge 332acc248d ds/mailmap later to maint).
+ (merge 04bf052eef ab/grep-patterntype later to maint).
+ (merge 6ee36364eb ab/diff-free-more later to maint).
+ (merge 63a36017fe nj/read-tree-doc-reffix later to maint).
+ (merge eed36fce38 sm/no-git-in-upstream-of-pipe-in-tests later to maint).
+ (merge c614beb933 ep/t6423-modernize later to maint).
+ (merge 57be9c6dee ab/reflog-prep-fix later to maint).
+ (merge 5327d8982a js/in-place-reverse-in-sequencer later to maint).
+ (merge 2e2c0be51e dp/worktree-repair-in-usage later to maint).
+ (merge 6563706568 jc/coding-guidelines-decl-in-for-loop later to maint).
diff --git a/RelNotes/2.36.1.adoc b/RelNotes/2.36.1.adoc
new file mode 100644
index 0000000..a961709
--- /dev/null
+++ b/RelNotes/2.36.1.adoc
@@ -0,0 +1,33 @@
+Git v2.36.1 Release Notes
+=========================
+
+Fixes since v2.36
+-----------------
+
+ * "git submodule update" without pathspec should silently skip an
+ uninitialized submodule, but it started to become noisy by mistake.
+
+ * "diff-tree --stdin" has been broken for about a year, but 2.36
+ release broke it even worse by breaking running the command with
+ <pathspec>, which in turn broke "gitk" and got noticed. This has
+ been corrected by aligning its behaviour to that of "log".
+
+ * Regression fix for 2.36 where "git name-rev" started to sometimes
+ reference strings after they are freed.
+
+ * "git show <commit1> <commit2>... -- <pathspec>" lost the pathspec
+ when showing the second and subsequent commits, which has been
+ corrected.
+
+ * "git fast-export -- <pathspec>" lost the pathspec when showing the
+ second and subsequent commits, which has been corrected.
+
+ * "git format-patch <args> -- <pathspec>" lost the pathspec when
+ showing the second and subsequent commits, which has been
+ corrected.
+
+ * Get rid of a bogus and over-eager coccinelle rule.
+
+ * Correct choices of C compilers used in various CI jobs.
+
+Also contains minor documentation updates and code clean-ups.
diff --git a/RelNotes/2.36.2.adoc b/RelNotes/2.36.2.adoc
new file mode 100644
index 0000000..958f5b4
--- /dev/null
+++ b/RelNotes/2.36.2.adoc
@@ -0,0 +1,56 @@
+Git v2.36.2 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.30.5, v2.31.4,
+v2.32.3, v2.33.4, v2.34.4 and v2.35.4 to address the security
+issue CVE-2022-29187; see the release notes for these versions
+for details.
+
+Apart from that, this maintenance release is primarily to merge down
+updates to the build and CI procedures from the 'master' front, in
+order to ensure that we can cut healthy maintenance releases in the
+future. It also contains a handful of small and trivially-correct
+bugfixes.
+
+Fixes since v2.36.1
+-------------------
+
+ * Fixes real problems noticed by gcc 12 and works around false
+ positives.
+
+ * Update URL to the gitk repository.
+
+ * The "--current" option of "git show-branch" should have been made
+ incompatible with the "--reflog" mode, but this was not enforced,
+ which has been corrected.
+
+ * "git archive --add-file=<path>" picked up the raw permission bits
+ from the path and propagated to zip output in some cases, without
+ normalization, which has been corrected (tar output did not have
+ this issue).
+
+ * A bit of test framework fixes with a few fixes to issues found by
+ valgrind.
+
+ * macOS CI jobs have been occasionally flaky due to tentative version
+ skew between perforce and the homebrew packager. Instead of
+ failing the whole CI job, just let it skip the p4 tests when this
+ happens.
+
+ * The commit summary shown after making a commit is matched to what
+ is given in "git status" not to use the break-rewrite heuristics.
+
+ * Avoid problems from interaction between malloc_check and address
+ sanitizer.
+
+ * "git rebase --keep-base <upstream> <branch-to-rebase>" computed the
+ commit to rebase onto incorrectly, which has been corrected.
+
+ * The path taken by "git multi-pack-index" command from the end user
+ was compared with path internally prepared by the tool withut first
+ normalizing, which lead to duplicated paths not being noticed,
+ which has been corrected.
+
+ * "git clone --origin X" leaked piece of memory that held value read
+ from the clone.defaultRemoteName configuration variable, which has
+ been plugged.
diff --git a/RelNotes/2.36.3.adoc b/RelNotes/2.36.3.adoc
new file mode 100644
index 0000000..56db77b
--- /dev/null
+++ b/RelNotes/2.36.3.adoc
@@ -0,0 +1,5 @@
+Git v2.36.3 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.30.6; see
+the release notes for that version for details.
diff --git a/RelNotes/2.36.4.adoc b/RelNotes/2.36.4.adoc
new file mode 100644
index 0000000..58fb93a
--- /dev/null
+++ b/RelNotes/2.36.4.adoc
@@ -0,0 +1,5 @@
+Git v2.36.4 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.30.7; see
+the release notes for that version for details.
diff --git a/RelNotes/2.36.5.adoc b/RelNotes/2.36.5.adoc
new file mode 100644
index 0000000..8a098c7
--- /dev/null
+++ b/RelNotes/2.36.5.adoc
@@ -0,0 +1,7 @@
+Git v2.36.5 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.30.8, v2.31.7,
+v2.32.6, v2.33.7, v2.34.7 and v2.35.7 to address the security
+issues CVE-2023-22490 and CVE-2023-23946; see the release notes
+for these versions for details.
diff --git a/RelNotes/2.36.6.adoc b/RelNotes/2.36.6.adoc
new file mode 100644
index 0000000..e1edebc
--- /dev/null
+++ b/RelNotes/2.36.6.adoc
@@ -0,0 +1,7 @@
+Git v2.36.6 Release Notes
+=========================
+
+This release merges the fixes that appear in v2.30.9, v2.31.8,
+v2.32.7, v2.33.8, v2.34.8 and v2.35.8 to address the security issues
+CVE-2023-25652, CVS-2023-25815, and CVE-2023-29007; see the release
+notes for these versions for details.
diff --git a/RelNotes/2.37.0.adoc b/RelNotes/2.37.0.adoc
new file mode 100644
index 0000000..99dc7e3
--- /dev/null
+++ b/RelNotes/2.37.0.adoc
@@ -0,0 +1,337 @@
+Git v2.37 Release Notes
+=======================
+
+UI, Workflows & Features
+
+ * "vimdiff[123]" mergetool drivers have been reimplemented with a
+ more generic layout mechanism.
+
+ * "git -v" and "git -h" are now understood as "git --version" and
+ "git --help".
+
+ * The temporary files fed to external diff command are now generated
+ inside a new temporary directory under the same basename.
+
+ * "git log --since=X" will stop traversal upon seeing a commit that
+ is older than X, but there may be commits behind it that is younger
+ than X when the commit was created with a faulty clock. A new
+ option is added to keep digging without stopping, and instead
+ filter out commits with timestamp older than X.
+
+ * "git -c branch.autosetupmerge=simple branch $A $B" will set the $B
+ as $A's upstream only when $A and $B shares the same name, and "git
+ -c push.default=simple" on branch $A would push to update the
+ branch $A at the remote $B came from. Also more places use the
+ sole remote, if exists, before defaulting to 'origin'.
+
+ * A new doc has been added that lists tips for tools to work with
+ Git's codebase.
+
+ * "git remote -v" now shows the list-objects-filter used during
+ fetching from the remote, if available.
+
+ * With the new http.curloptResolve configuration, the CURLOPT_RESOLVE
+ mechanism that allows cURL based applications to use pre-resolved
+ IP addresses for the requests is exposed to the scripts.
+
+ * "git add -i" was rewritten in C some time ago and has been in
+ testing; the reimplementation is now exposed to general public by
+ default.
+
+ * Deprecate non-cone mode of the sparse-checkout feature.
+
+ * Introduce a filesystem-dependent mechanism to optimize the way the
+ bits for many loose object files are ensured to hit the disk
+ platter.
+
+ * The "do not remove the directory the user started Git in" logic,
+ when Git cannot tell where that directory is, is disabled. Earlier
+ we refused to run in such a case.
+
+ * A mechanism to pack unreachable objects into a "cruft pack",
+ instead of ejecting them into loose form to be reclaimed later, has
+ been introduced.
+
+ * Update the doctype written in gitweb output to xhtml5.
+
+ * The "transfer.credentialsInURL" configuration variable controls what
+ happens when a URL with embedded login credential is used on either
+ "fetch" or "push". Credentials are currently only detected in
+ `remote.<name>.url` config, not `remote.<name>.pushurl`.
+
+ * "git revert" learns "--reference" option to use more human-readable
+ reference to the commit it reverts in the message template it
+ prepares for the user.
+
+ * Various error messages that talk about the removal of
+ "--preserve-merges" in "rebase" have been strengthened, and "rebase
+ --abort" learned to get out of a state that was left by an earlier
+ use of the option.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * The performance of the "untracked cache" feature has been improved
+ when "--untracked-files=<mode>" and "status.showUntrackedFiles"
+ are combined.
+
+ * "git stash" works better with sparse index entries.
+
+ * "git show :<path>" learned to work better with the sparse-index
+ feature.
+
+ * Introduce and apply coccinelle rule to discourage an explicit
+ comparison between a pointer and NULL, and applies the clean-up to
+ the maintenance track.
+
+ * Preliminary code refactoring around transport and bundle code.
+
+ * "sparse-checkout" learns to work better with the sparse-index
+ feature.
+
+ * A workflow change for translators are being proposed. git.pot is
+ no longer version controlled and it is local responsibility of
+ translators to generate it.
+
+ * Plug the memory leaks from the trickiest API of all, the revision
+ walker.
+
+ * Rename .env_array member to .env in the child_process structure.
+
+ * The fsmonitor--daemon handles even more corner cases when
+ watching filesystem events.
+
+ * A new bug() and BUG_if_bug() API is introduced to make it easier to
+ uniformly log "detect multiple bugs and abort in the end" pattern.
+
+
+Fixes since v2.36
+-----------------
+
+ * "git submodule update" without pathspec should silently skip an
+ uninitialized submodule, but it started to become noisy by mistake.
+ (merge 4f1ccef87c gc/submodule-update-part2 later to maint).
+
+ * "diff-tree --stdin" has been broken for about a year, but 2.36
+ release broke it even worse by breaking running the command with
+ <pathspec>, which in turn broke "gitk" and got noticed. This has
+ been corrected by aligning its behaviour to that of "log".
+ (merge f8781bfda3 jc/diff-tree-stdin-fix later to maint).
+
+ * Regression fix for 2.36 where "git name-rev" started to sometimes
+ reference strings after they are freed.
+ (merge 45a14f578e rs/name-rev-fix-free-after-use later to maint).
+
+ * "git show <commit1> <commit2>... -- <pathspec>" lost the pathspec
+ when showing the second and subsequent commits, which has been
+ corrected.
+ (merge 5cdb38458e jc/show-pathspec-fix later to maint).
+
+ * "git fast-export -- <pathspec>" lost the pathspec when showing the
+ second and subsequent commits, which has been corrected.
+ (merge d1c25272f5 rs/fast-export-pathspec-fix later to maint).
+
+ * "git format-patch <args> -- <pathspec>" lost the pathspec when
+ showing the second and subsequent commits, which has been
+ corrected.
+ (merge 91f8f7e46f rs/format-patch-pathspec-fix later to maint).
+
+ * "git clone --origin X" leaked piece of memory that held value read
+ from the clone.defaultRemoteName configuration variable, which has
+ been plugged.
+ (merge 6dfadc8981 jc/clone-remote-name-leak-fix later to maint).
+
+ * Get rid of a bogus and over-eager coccinelle rule.
+ (merge 08bdd3a185 jc/cocci-xstrdup-or-null-fix later to maint).
+
+ * The path taken by "git multi-pack-index" command from the end user
+ was compared with path internally prepared by the tool without first
+ normalizing, which lead to duplicated paths not being noticed,
+ which has been corrected.
+ (merge 11f9e8de3d ds/midx-normalize-pathname-before-comparison later to maint).
+
+ * Correct choices of C compilers used in various CI jobs.
+ (merge 3506cae04f ab/cc-package-fixes later to maint).
+
+ * Various cleanups to "git p4".
+ (merge 4ff0108d9e jh/p4-various-fixups later to maint).
+
+ * The progress meter of "git blame" was showing incorrect numbers
+ when processing only parts of the file.
+ (merge e5f5d7d42e ea/progress-partial-blame later to maint).
+
+ * "git rebase --keep-base <upstream> <branch-to-rebase>" computed the
+ commit to rebase onto incorrectly, which has been corrected.
+ (merge 9e5ebe9668 ah/rebase-keep-base-fix later to maint).
+
+ * Fix a leak of FILE * in an error codepath.
+ (merge c0befa0c03 kt/commit-graph-plug-fp-leak-on-error later to maint).
+
+ * Avoid problems from interaction between malloc_check and address
+ sanitizer.
+ (merge 067109a5e7 pw/test-malloc-with-sanitize-address later to maint).
+
+ * The commit summary shown after making a commit is matched to what
+ is given in "git status" not to use the break-rewrite heuristics.
+ (merge 84792322ed rs/commit-summary-wo-break-rewrite later to maint).
+
+ * Update a few end-user facing messages around EOL conversion.
+ (merge c970d30c2c ah/convert-warning-message later to maint).
+
+ * Trace2 documentation updates.
+ (merge a6c80c313c js/trace2-doc-fixes later to maint).
+
+ * Build procedure fixup.
+ (merge 1fbfd96f50 mg/detect-compiler-in-c-locale later to maint).
+
+ * "git pull" without "--recurse-submodules=<arg>" made
+ submodule.recurse take precedence over fetch.recurseSubmodules by
+ mistake, which has been corrected.
+ (merge 5819417365 gc/pull-recurse-submodules later to maint).
+
+ * "git bisect" was too silent before it is ready to start computing
+ the actual bisection, which has been corrected.
+ (merge f11046e6de cd/bisect-messages-from-pre-flight-states later to maint).
+
+ * macOS CI jobs have been occasionally flaky due to tentative version
+ skew between perforce and the homebrew packager. Instead of
+ failing the whole CI job, just let it skip the p4 tests when this
+ happens.
+ (merge f15e00b463 cb/ci-make-p4-optional later to maint).
+
+ * A bit of test framework fixes with a few fixes to issues found by
+ valgrind.
+ (merge 7c898554d7 ab/valgrind-fixes later to maint).
+
+ * "git archive --add-file=<path>" picked up the raw permission bits
+ from the path and propagated to zip output in some cases, without
+ normalization, which has been corrected (tar output did not have
+ this issue).
+ (merge 6a61661967 jc/archive-add-file-normalize-mode later to maint).
+
+ * "make coverage-report" without first running "make coverage" did
+ not produce any meaningful result, which has been corrected.
+ (merge 96ddfecc5b ep/coverage-report-wants-test-to-have-run later to maint).
+
+ * The "--current" option of "git show-branch" should have been made
+ incompatible with the "--reflog" mode, but this was not enforced,
+ which has been corrected.
+ (merge 41c64ae0e7 jc/show-branch-g-current later to maint).
+
+ * "git fetch" unnecessarily failed when an unexpected optional
+ section appeared in the output, which has been corrected.
+ (merge 7709acf7be jt/fetch-peek-optional-section later to maint).
+
+ * The way "git fetch" without "--update-head-ok" ensures that HEAD in
+ no worktree points at any ref being updated was too wasteful, which
+ has been optimized a bit.
+ (merge f7400da800 os/fetch-check-not-current-branch later to maint).
+
+ * "git fetch --recurse-submodules" from multiple remotes (either from
+ a remote group, or "--all") used to make one extra "git fetch" in
+ the submodules, which has been corrected.
+ (merge 0353c68818 jc/avoid-redundant-submodule-fetch later to maint).
+
+ * With a recent update to refuse access to repositories of other
+ people by default, "sudo make install" and "sudo git describe"
+ stopped working, which has been corrected.
+ (merge 6b11e3d52e cb/path-owner-check-with-sudo-plus later to maint).
+
+ * The tests that ensured merges stop when interfering local changes
+ are present did not make sure that local changes are preserved; now
+ they do.
+ (merge 4b317450ce jc/t6424-failing-merge-preserve-local-changes later to maint).
+
+ * Some real problems noticed by gcc 12 have been fixed, while false
+ positives have been worked around.
+
+ * Update the version of FreeBSD image used in Cirrus CI.
+ (merge c58bebd4c6 pb/use-freebsd-12.3-in-cirrus-ci later to maint).
+
+ * The multi-pack-index code did not protect the packfile it is going
+ to depend on from getting removed while in use, which has been
+ corrected.
+ (merge 4090511e40 tb/midx-race-in-pack-objects later to maint).
+
+ * Teach "git repack --geometric" work better with "--keep-pack" and
+ avoid corrupting the repository when packsize limit is used.
+ (merge 66731ff921 tb/geom-repack-with-keep-and-max later to maint).
+
+ * The documentation on the interaction between "--add-file" and
+ "--prefix" options of "git archive" has been improved.
+ (merge a75910602a rs/document-archive-prefix later to maint).
+
+ * A git subcommand like "git add -p" spawns a separate git process
+ while relaying its command line arguments. A pathspec with only
+ negative elements was mistakenly passed with an empty string, which
+ has been corrected.
+ (merge b02fdbc80a jc/all-negative-pathspec later to maint).
+
+ * With a more targeted workaround in http.c in another topic, we may
+ be able to lift this blanket "GCC12 dangling-pointer warning is
+ broken and unsalvageable" workaround.
+ (merge 419141e495 cb/buggy-gcc-12-workaround later to maint).
+
+ * A misconfigured 'branch..remote' led to a bug in configuration
+ parsing.
+ (merge f1dfbd9ee0 gc/zero-length-branch-config-fix later to maint).
+
+ * "git -c diff.submodule=log range-diff" did not show anything for
+ submodules that changed in the ranges being compared, and
+ "git -c diff.submodule=diff range-diff" did not work correctly.
+ Fix this by including the "--submodule=short" output
+ unconditionally to be compared.
+
+ * In Git 2.36 we revamped the way how hooks are invoked. One change
+ that is end-user visible is that the output of a hook is no longer
+ directly connected to the standard output of "git" that spawns the
+ hook, which was noticed post release. This is getting corrected.
+ (merge a082345372 ab/hooks-regression-fix later to maint).
+
+ * Updating the graft information invalidates the list of parents of
+ in-core commit objects that used to be in the graft file.
+
+ * "git show-ref --heads" (and "--tags") still iterated over all the
+ refs only to discard refs outside the specified area, which has
+ been corrected.
+ (merge c0c9d35e27 tb/show-ref-optim later to maint).
+
+ * Remove redundant copying (with index v3 and older) or possible
+ over-reading beyond end of mmapped memory (with index v4) has been
+ corrected.
+ (merge 6d858341d2 zh/read-cache-copy-name-entry-fix later to maint).
+
+ * Sample watchman interface hook sometimes failed to produce
+ correctly formatted JSON message, which has been corrected.
+ (merge 134047b500 sn/fsmonitor-missing-clock later to maint).
+
+ * Use-after-free (with another forget-to-free) fix.
+ (merge 323822c72b ab/remote-free-fix later to maint).
+
+ * Remove a coccinelle rule that is no longer relevant.
+ (merge b1299de4a1 jc/cocci-cleanup later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge e6b2582da3 cm/reftable-0-length-memset later to maint).
+ (merge 0b75e5bf22 ab/misc-cleanup later to maint).
+ (merge 52e1ab8a76 ea/rebase-code-simplify later to maint).
+ (merge 756d15923b sg/safe-directory-tests-and-docs later to maint).
+ (merge d097a23bfa ds/do-not-call-bug-on-bad-refs later to maint).
+ (merge c36c27e75c rs/t7812-pcre2-ws-bug-test later to maint).
+ (merge 1da312742d gf/unused-includes later to maint).
+ (merge 465b30a92d pb/submodule-recurse-mode-enum later to maint).
+ (merge 82b28c4ed8 km/t3501-use-test-helpers later to maint).
+ (merge 72315e431b sa/t1011-use-helpers later to maint).
+ (merge 95b3002201 cg/vscode-with-gdb later to maint).
+ (merge fbe5f6b804 tk/p4-utf8-bom later to maint).
+ (merge 17f273ffba tk/p4-with-explicity-sync later to maint).
+ (merge 944db25c60 kf/p4-multiple-remotes later to maint).
+ (merge b014cee8de jc/update-ozlabs-url later to maint).
+ (merge 4ec5008062 pb/ggg-in-mfc-doc later to maint).
+ (merge af845a604d tb/receive-pack-code-cleanup later to maint).
+ (merge 2acf4cf001 js/ci-gcc-12-fixes later to maint).
+ (merge 05e280c0a6 jc/http-clear-finished-pointer later to maint).
+ (merge 8c49d704ef fh/transport-push-leakfix later to maint).
+ (merge 1d232d38bd tl/ls-tree-oid-only later to maint).
+ (merge db7961e6a6 gc/document-config-worktree-scope later to maint).
+ (merge ce18a30bb7 fs/ssh-default-key-command-doc later to maint).
diff --git a/RelNotes/2.37.1.adoc b/RelNotes/2.37.1.adoc
new file mode 100644
index 0000000..8460932
--- /dev/null
+++ b/RelNotes/2.37.1.adoc
@@ -0,0 +1,17 @@
+Git 2.37.1 Release Notes
+========================
+
+This release merges up the fixes that appear in v2.30.5, v2.31.4,
+v2.32.3, v2.33.4, v2.34.4, v2.35.4, and v2.36.2 to address the
+security issue CVE-2022-29187; see the release notes for these
+versions for details.
+
+Fixes since Git 2.37
+--------------------
+
+ * Rewrite of "git add -i" in C that appeared in Git 2.25 didn't
+ correctly record a removed file to the index, which is an old
+ regression but has become widely known because the C version has
+ become the default in the latest release.
+
+ * Fix for CVS-2022-29187.
diff --git a/RelNotes/2.37.2.adoc b/RelNotes/2.37.2.adoc
new file mode 100644
index 0000000..d82b29e
--- /dev/null
+++ b/RelNotes/2.37.2.adoc
@@ -0,0 +1,88 @@
+Git 2.37.2 Release Notes
+========================
+
+This primarily is to backport various fixes accumulated on the 'master'
+front since 2.37.1.
+
+Fixes since v2.37.1
+-------------------
+
+ * "git shortlog -n" relied on the underlying qsort() to be stable,
+ which shouldn't have. Fixed.
+
+ * Variable quoting fix in the vimdiff driver of "git mergetool".
+
+ * An earlier attempt to plug leaks placed a clean-up label to jump to
+ at a bogus place, which as been corrected.
+
+ * Fixes a long-standing corner case bug around directory renames in
+ the merge-ort strategy.
+
+ * Recent update to vimdiff layout code has been made more robust
+ against different end-user vim settings.
+
+ * In a non-bare repository, the behavior of Git when the
+ core.worktree configuration variable points at a directory that has
+ a repository as its subdirectory, regressed in Git 2.27 days.
+
+ * References to commands-to-be-typed-literally in "git rebase"
+ documentation mark-up have been corrected.
+
+ * Give _() markings to fatal/warning/usage: labels that are shown in
+ front of these messages.
+
+ * "git mktree --missing" lazily fetched objects that are missing from
+ the local object store, which was totally unnecessary for the purpose
+ of creating the tree object(s) from its input.
+
+ * Fixes for tests when the source directory has unusual characters in
+ its path, e.g. whitespaces, double-quotes, etc.
+
+ * Adjust technical/bitmap-format to be formatted by AsciiDoc, and
+ add some missing information to the documentation.
+
+ * Certain diff options are currently ignored when combined-diff is
+ shown; mark them as incompatible with the feature.
+
+ * "git clone" from a repository with some ref whose HEAD is unborn
+ did not set the HEAD in the resulting repository correctly, which
+ has been corrected.
+
+ * mkstemp() emulation on Windows has been improved.
+
+ * Add missing documentation for "include" and "includeIf" features in
+ "git config" file format, which incidentally teaches the command
+ line completion to include them in its offerings.
+
+ * Avoid "white/black-list" in documentation and code comments.
+
+ * Workaround for a compiler warning against use of die() in
+ osx-keychain (in contrib/).
+
+ * Workaround for a false positive compiler warning.
+
+ * The resolve-undo information in the index was not protected against
+ GC, which has been corrected.
+
+ * A corner case bug where lazily fetching objects from a promisor
+ remote resulted in infinite recursion has been corrected.
+
+ * "git p4" working on UTF-16 files on Windows did not implement
+ CRLF-to-LF conversion correctly, which has been corrected.
+
+ * "git p4" did not handle non-ASCII client name well, which has been
+ corrected.
+
+ * "rerere-train" script (in contrib/) used to honor commit.gpgSign
+ while recreating the throw-away merges.
+
+ * "git checkout" miscounted the paths it updated, which has been
+ corrected.
+
+ * Fix for a bug that makes write-tree to fail to write out a
+ non-existent index as a tree, introduced in 2.37.
+
+ * There was a bug in the codepath to upgrade generation information
+ in commit-graph from v1 to v2 format, which has been corrected.
+
+Also contains minor documentation updates and code clean-ups.
diff --git a/RelNotes/2.37.3.adoc b/RelNotes/2.37.3.adoc
new file mode 100644
index 0000000..d66689e
--- /dev/null
+++ b/RelNotes/2.37.3.adoc
@@ -0,0 +1,46 @@
+Git 2.37.3 Release Notes
+========================
+
+This primarily is to backport various fixes accumulated on the 'master'
+front since 2.37.2.
+
+Fixes since v2.37.2
+-------------------
+
+ * The build procedure for Windows that uses CMake has been updated to
+ pick up the shell interpreter from local installation location.
+
+ * Conditionally allow building Python interpreter on Windows
+
+ * Fix to lstat() emulation on Windows.
+
+ * Older gcc with -Wall complains about the universal zero initializer
+ "struct s = { 0 };" idiom, which makes developers' lives
+ inconvenient (as -Werror is enabled by DEVELOPER=YesPlease). The
+ build procedure has been tweaked to help these compilers.
+
+ * Plug memory leaks in the failure code path in the "merge-ort" merge
+ strategy backend.
+
+ * Avoid repeatedly running getconf to ask libc version in the test
+ suite, and instead just as it once per script.
+
+ * Platform-specific code that determines if a directory is OK to use
+ as a repository has been taught to report more details, especially
+ on Windows.
+
+ * "vimdiff3" regression has been corrected.
+
+ * "git fsck" reads mode from tree objects but canonicalizes the mode
+ before passing it to the logic to check object sanity, which has
+ hid broken tree objects from the checking logic. This has been
+ corrected, but to help exiting projects with broken tree objects
+ that they cannot fix retroactively, the severity of anomalies this
+ code detects has been demoted to "info" for now.
+
+ * Fixes to sparse index compatibility work for "reset" and "checkout"
+ commands.
+
+ * Documentation for "git add --renormalize" has been improved.
+
+Also contains other minor documentation updates and code clean-ups.
diff --git a/RelNotes/2.37.4.adoc b/RelNotes/2.37.4.adoc
new file mode 100644
index 0000000..e42a5c1
--- /dev/null
+++ b/RelNotes/2.37.4.adoc
@@ -0,0 +1,65 @@
+Git 2.37.4 Release Notes
+========================
+
+This primarily is to backport various fixes accumulated on the 'master'
+front since 2.37.3, and also includes the same security fixes as in
+v2.30.6.
+
+Fixes since v2.37.3
+-------------------
+
+ * CVE-2022-39253:
+ When relying on the `--local` clone optimization, Git dereferences
+ symbolic links in the source repository before creating hardlinks
+ (or copies) of the dereferenced link in the destination repository.
+ This can lead to surprising behavior where arbitrary files are
+ present in a repository's `$GIT_DIR` when cloning from a malicious
+ repository.
+
+ Git will no longer dereference symbolic links via the `--local`
+ clone mechanism, and will instead refuse to clone repositories that
+ have symbolic links present in the `$GIT_DIR/objects` directory.
+
+ Additionally, the value of `protocol.file.allow` is changed to be
+ "user" by default.
+
+ Credit for finding CVE-2022-39253 goes to Cory Snider of Mirantis.
+ The fix was authored by Taylor Blau, with help from Johannes
+ Schindelin.
+
+ * CVE-2022-39260:
+ An overly-long command string given to `git shell` can result in
+ overflow in `split_cmdline()`, leading to arbitrary heap writes and
+ remote code execution when `git shell` is exposed and the directory
+ `$HOME/git-shell-commands` exists.
+
+ `git shell` is taught to refuse interactive commands that are
+ longer than 4MiB in size. `split_cmdline()` is hardened to reject
+ inputs larger than 2GiB.
+
+ Credit for finding CVE-2022-39260 goes to Kevin Backhouse of
+ GitHub. The fix was authored by Kevin Backhouse, Jeff King, and
+ Taylor Blau.
+
+ * An earlier optimization discarded a tree-object buffer that is
+ still in use, which has been corrected.
+
+ * Fix deadlocks between main Git process and subprocess spawned via
+ the pipe_command() API, that can kill "git add -p" that was
+ reimplemented in C recently.
+
+ * xcalloc(), imitating calloc(), takes "number of elements of the
+ array", and "size of a single element", in this order. A call that
+ does not follow this ordering has been corrected.
+
+ * The preload-index codepath made copies of pathspec to give to
+ multiple threads, which were left leaked.
+
+ * Update the version of Ubuntu used for GitHub Actions CI from 18.04
+ to 22.04.
+
+ * The auto-stashed local changes created by "git merge --autostash"
+ was mixed into a conflicted state left in the working tree, which
+ has been corrected.
+
+Also contains other minor documentation updates and code clean-ups.
diff --git a/RelNotes/2.37.5.adoc b/RelNotes/2.37.5.adoc
new file mode 100644
index 0000000..faa1447
--- /dev/null
+++ b/RelNotes/2.37.5.adoc
@@ -0,0 +1,5 @@
+Git v2.37.5 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.30.7; see
+the release notes for that version for details.
diff --git a/RelNotes/2.37.6.adoc b/RelNotes/2.37.6.adoc
new file mode 100644
index 0000000..51dc149
--- /dev/null
+++ b/RelNotes/2.37.6.adoc
@@ -0,0 +1,7 @@
+Git v2.37.6 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.30.8, v2.31.7,
+v2.32.6, v2.33.7, v2.34.7, v2.35.7 and v2.36.5 to address the
+security issues CVE-2023-22490 and CVE-2023-23946; see the release
+notes for these versions for details.
diff --git a/RelNotes/2.37.7.adoc b/RelNotes/2.37.7.adoc
new file mode 100644
index 0000000..4b8165f
--- /dev/null
+++ b/RelNotes/2.37.7.adoc
@@ -0,0 +1,7 @@
+Git v2.37.7 Release Notes
+=========================
+
+This release merges up the fix that appears in v2.30.9, v2.31.8,
+v2.32.7, v2.33.8, v2.34.8, v2.35.8 and v2.36.6 to address the
+security issues CVE-2023-25652, CVE-2023-25815, and CVE-2023-29007;
+see the release notes for these versions for details.
diff --git a/RelNotes/2.38.0.adoc b/RelNotes/2.38.0.adoc
new file mode 100644
index 0000000..870581f
--- /dev/null
+++ b/RelNotes/2.38.0.adoc
@@ -0,0 +1,404 @@
+Git v2.38 Release Notes
+=======================
+
+UI, Workflows & Features
+
+ * "git remote show [-n] frotz" now pays attention to negative
+ pathspec.
+
+ * "git push" sometimes performs poorly when reachability bitmaps are
+ used, even in a repository where other operations are helped by
+ bitmaps. The push.useBitmaps configuration variable is introduced
+ to allow disabling use of reachability bitmaps only for "git push".
+
+ * "git grep -m<max-hits>" is a way to limit the hits shown per file.
+
+ * "git merge-tree" learned a new mode where it takes two commits and
+ computes a tree that would result in the merge commit, if the
+ histories leading to these two commits were to be merged.
+
+ * "git mv A B" in a sparsely populated working tree can be asked to
+ move a path between directories that are "in cone" (i.e. expected
+ to be materialized in the working tree) and "out of cone"
+ (i.e. expected to be hidden). The handling of such cases has been
+ improved.
+
+ * Earlier, HTTP transport clients learned to tell the server side
+ what locale they are in by sending Accept-Language HTTP header, but
+ this was done only for some requests but not others.
+
+ * Introduce a safe.barerepository configuration variable that
+ allows users to forbid discovery of bare repositories.
+
+ * Various messages that come from the pack-bitmap codepaths have been
+ tweaked.
+
+ * "git rebase -i" learns to update branches whose tip appear in the
+ rebased range with "--update-refs" option.
+
+ * "git ls-files" learns the "--format" option to tweak its output.
+
+ * "git cat-file" learned an option to use the mailmap when showing
+ commit and tag objects.
+
+ * When "git merge" finds that it cannot perform a merge, it should
+ restore the working tree to the state before the command was
+ initiated, but in some corner cases it didn't.
+
+ * Operating modes like "--batch" of "git cat-file" command learned to
+ take NUL-terminated input, instead of one-item-per-line.
+
+ * "git rm" has become more aware of the sparse-index feature.
+
+ * "git rev-list --disk-usage" learned to take an optional value
+ "human" to show the reported value in human-readable format, like
+ "3.40MiB".
+
+ * The "diagnose" feature to create a zip archive for diagnostic
+ material has been lifted from "scalar" and made into a feature of
+ "git bugreport".
+
+ * The namespaces used by "log --decorate" from "refs/" hierarchy by
+ default has been tightened.
+
+ * "git rev-list --ancestry-path=C A..B" is a natural extension of
+ "git rev-list A..B"; instead of choosing a subset of A..B to those
+ that have ancestry relationship with A, it lets a subset with
+ ancestry relationship with C.
+
+ * "scalar" now enables built-in fsmonitor on enlisted repositories,
+ when able.
+
+ * The bash prompt (in contrib/) learned to optionally indicate when
+ the index is unmerged.
+
+ * "git clone" command learned the "--bundle-uri" option to coordinate
+ with hosting sites the use of pre-prepared bundle files.
+
+ * "git range-diff" learned to honor pathspec argument if given.
+
+ * "git format-patch --from=<ident>" can be told to add an in-body
+ "From:" line even for commits that are authored by the given
+ <ident> with "--force-in-body-from" option.
+
+ * The built-in fsmonitor refuses to work on a network mounted
+ repositories; a configuration knob for users to override this has
+ been introduced.
+
+ * The "scalar" addition from Microsoft is now part of the core Git
+ installation.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * Collection of what is referenced by objects in promisor packs have
+ been optimized to inspect these objects in the in-pack order.
+
+ * Introduce a helper to see if a branch is already being worked on
+ (hence should not be newly checked out in a working tree), which
+ performs much better than the existing find_shared_symref() to
+ replace many uses of the latter.
+
+ * Teach "git archive" to (optionally and then by default) avoid
+ spawning an external "gzip" process when creating ".tar.gz" (and
+ ".tgz") archives.
+
+ * Allow large objects read from a packstream to be streamed into a
+ loose object file straight, without having to keep it in-core as a
+ whole.
+
+ * Further preparation to turn git-submodule.sh into a builtin
+ continues.
+
+ * Apply Coccinelle rule to turn raw memmove() into MOVE_ARRAY() cpp
+ macro, which would improve maintainability and readability.
+
+ * Teach "make all" to build gitweb as well.
+
+ * Tweak tests so that they still work when the "git init" template
+ did not create .git/info directory.
+
+ * Add Coccinelle rules to detect the pattern of initializing and then
+ finalizing a structure without using it in between at all, which
+ happens after code restructuring and the compilers fail to
+ recognize as an unused variable.
+
+ * The code to convert between GPG trust level strings and internal
+ constants we use to represent them have been cleaned up.
+
+ * Support for libnettle as SHA256 implementation has been added.
+
+ * The way "git multi-pack" uses parse-options API has been improved.
+
+ * A Coccinelle rule (in contrib/) to encourage use of COPY_ARRAY
+ macro has been improved.
+
+ * API tweak to make it easier to run fuzz testing on commit-graph parser.
+
+ * Omit fsync-related trace2 entries when their values are all zero.
+
+ * The codepath to write multi-pack index has been taught to release a
+ large chunk of memory that holds an array of objects in the packs,
+ as soon as it is done with the array, to reduce memory consumption.
+
+ * Add a level of redirection to array allocation API in xdiff part,
+ to make it easier to share with the libgit2 project.
+
+ * "git fetch" client logs the partial clone filter used in the trace2
+ output.
+
+ * The "bundle URI" design gets documented.
+
+ * The common ancestor negotiation exchange during a "git fetch"
+ session now leaves trace log.
+
+ * Test portability improvements.
+ (merge 4d1d843be7 mt/rot13-in-c later to maint).
+
+ * The "subcommand" mode is introduced to parse-options API and update
+ the command line parser of Git commands with subcommands.
+
+ * The pack bitmap file gained a bitmap-lookup table to speed up
+ locating the necessary bitmap for a given commit.
+
+ * The assembly version of SHA-1 implementation for PPC has been
+ removed.
+
+ * The server side that responds to "git fetch" and "git clone"
+ request has been optimized by allowing it to send objects in its
+ object store without recomputing and validating the object names.
+
+ * Annotate function parameters that are not used (but cannot be
+ removed for structural reasons), to prepare us to later compile
+ with -Wunused warning turned on.
+
+ * Share the text used to explain configuration variables used by "git
+ <subcmd>" in "git help <subcmd>" with the text from "git help config".
+
+ * "git mv A B" in a sparsely populated working tree can be asked to
+ move a path from a directory that is "in cone" to another directory
+ that is "out of cone". Handling of such a case has been improved.
+
+ * The chainlint script for our tests has been revamped.
+
+
+Fixes since v2.37
+-----------------
+
+ * Rewrite of "git add -i" in C that appeared in Git 2.25 didn't
+ correctly record a removed file to the index, which was fixed.
+
+ * Certain diff options are currently ignored when combined-diff is
+ shown; mark them as incompatible with the feature.
+
+ * Adjust technical/bitmap-format to be formatted by AsciiDoc, and
+ add some missing information to the documentation.
+
+ * Fixes for tests when the source directory has unusual characters in
+ its path, e.g. whitespaces, double-quotes, etc.
+
+ * "git mktree --missing" lazily fetched objects that are missing from
+ the local object store, which was totally unnecessary for the purpose
+ of creating the tree object(s) from its input.
+
+ * Give _() markings to fatal/warning/usage: labels that are shown in
+ front of these messages.
+
+ * References to commands-to-be-typed-literally in "git rebase"
+ documentation mark-up have been corrected.
+
+ * In a non-bare repository, the behavior of Git when the
+ core.worktree configuration variable points at a directory that has
+ a repository as its subdirectory, regressed in Git 2.27 days.
+
+ * Recent update to vimdiff layout code has been made more robust
+ against different end-user vim settings.
+
+ * Plug various memory leaks, both in the main code and in test-tool
+ commands.
+
+ * Fixes a long-standing corner case bug around directory renames in
+ the merge-ort strategy.
+
+ * The resolve-undo information in the index was not protected against
+ GC, which has been corrected.
+
+ * A corner case bug where lazily fetching objects from a promisor
+ remote resulted in infinite recursion has been corrected.
+
+ * "git clone" from a repository with some ref whose HEAD is unborn
+ did not set the HEAD in the resulting repository correctly, which
+ has been corrected.
+
+ * An earlier attempt to plug leaks placed a clean-up label to jump to
+ at a bogus place, which as been corrected.
+
+ * Variable quoting fix in the vimdiff driver of "git mergetool"
+
+ * "git shortlog -n" relied on the underlying qsort() to be stable,
+ which shouldn't have. Fixed.
+
+ * A fix for a regression in test framework.
+
+ * mkstemp() emulation on Windows has been improved.
+
+ * Add missing documentation for "include" and "includeIf" features in
+ "git config" file format, which incidentally teaches the command
+ line completion to include them in its offerings.
+
+ * Avoid "white/black-list" in documentation and code comments.
+
+ * Workaround for a compiler warning against use of die() in
+ osx-keychain (in contrib/).
+
+ * Workaround for a false positive compiler warning.
+
+ * "git p4" working on UTF-16 files on Windows did not implement
+ CRLF-to-LF conversion correctly, which has been corrected.
+
+ * "git p4" did not handle non-ASCII client name well, which has been
+ corrected.
+
+ * "rerere-train" script (in contrib/) used to honor commit.gpgSign
+ while recreating the throw-away merges.
+
+ * "git checkout" miscounted the paths it updated, which has been
+ corrected.
+
+ * Fix for a bug that makes write-tree to fail to write out a
+ non-existent index as a tree, introduced in 2.37.
+
+ * There was a bug in the codepath to upgrade generation information
+ in commit-graph from v1 to v2 format, which has been corrected.
+
+ * Gitweb had legacy URL shortener that is specific to the way
+ projects hosted on kernel.org used to (but no longer) work, which
+ has been removed.
+
+ * Fix build procedure for Windows that uses CMake so that it can pick
+ up the shell interpreter from local installation location.
+
+ * Conditionally allow building Python interpreter on Windows
+
+ * Fix to lstat() emulation on Windows.
+
+ * Older gcc with -Wall complains about the universal zero initializer
+ "struct s = { 0 };" idiom, which makes developers' lives
+ inconvenient (as -Werror is enabled by DEVELOPER=YesPlease). The
+ build procedure has been tweaked to help these compilers.
+
+ * Plug memory leaks in the failure code path in the "merge-ort" merge
+ strategy backend.
+
+ * "git symbolic-ref symref non..sen..se" is now diagnosed as an error.
+
+ * A follow-up fix to a fix for a regression in 2.36 around hooks.
+
+ * Avoid repeatedly running getconf to ask libc version in the test
+ suite, and instead just as it once per script.
+
+ * Platform-specific code that determines if a directory is OK to use
+ as a repository has been taught to report more details, especially
+ on Windows.
+
+ * "vimdiff3" regression fix.
+
+ * "git fsck" reads mode from tree objects but canonicalizes the mode
+ before passing it to the logic to check object sanity, which has
+ hid broken tree objects from the checking logic. This has been
+ corrected, but to help existing projects with broken tree objects
+ that they cannot fix retroactively, the severity of anomalies this
+ code detects has been demoted to "info" for now.
+
+ * Fixes to sparse index compatibility work for "reset" and "checkout"
+ commands.
+
+ * An earlier optimization discarded a tree-object buffer that is
+ still in use, which has been corrected.
+
+ * Fix deadlocks between main Git process and subprocess spawned via
+ the pipe_command() API, that can kill "git add -p" that was
+ reimplemented in C recently.
+
+ * The sequencer machinery translated messages left in the reflog by
+ mistake, which has been corrected.
+
+ * xcalloc(), imitating calloc(), takes "number of elements of the
+ array", and "size of a single element", in this order. A call that
+ does not follow this ordering has been corrected.
+
+ * The preload-index codepath made copies of pathspec to give to
+ multiple threads, which were left leaked.
+
+ * Update the version of Ubuntu used for GitHub Actions CI from 18.04
+ to 22.04.
+
+ * The auto-stashed local changes created by "git merge --autostash"
+ was mixed into a conflicted state left in the working tree, which
+ has been corrected.
+
+ * Multi-pack index got corrupted when preferred pack changed from one
+ pack to another in a certain way, which has been corrected.
+ (merge 99e4d084ff tb/midx-with-changing-preferred-pack-fix later to maint).
+
+ * The clean-up of temporary files created via mks_tempfile_dt() was
+ racy and attempted to unlink() the leading directory when signals
+ are involved, which has been corrected.
+ (merge babe2e0559 rs/tempfile-cleanup-race-fix later to maint).
+
+ * FreeBSD portability fix for "git maintenance" that spawns "crontab"
+ to schedule tasks.
+ (merge ee69e7884e bc/gc-crontab-fix later to maint).
+
+ * Those who use diff-so-fancy as the diff-filter noticed a regression
+ or two in the code that parses the diff output in the built-in
+ version of "add -p", which has been corrected.
+ (merge 0a101676e5 js/add-p-diff-parsing-fix later to maint).
+
+ * Segfault fix-up to an earlier fix to the topic to teach "git reset"
+ and "git checkout" work better in a sparse checkout.
+ (merge 037f8ea6d9 vd/sparse-reset-checkout-fixes later to maint).
+
+ * "git diff --no-index A B" managed its the pathnames of its two
+ input files rather haphazardly, sometimes leaking them. The
+ command line argument processing has been straightened out to clean
+ it up.
+ (merge 2b43dd0eb5 rs/diff-no-index-cleanup later to maint).
+
+ * "git rev-list --verify-objects" ought to inspect the contents of
+ objects and notice corrupted ones, but it didn't when the commit
+ graph is in use, which has been corrected.
+ (merge b27ccae34b jk/rev-list-verify-objects-fix later to maint).
+
+ * More fixes to "add -p"
+ (merge 64ec8efb83 js/builtin-add-p-portability-fix later to maint).
+
+ * The parser in the script interface to parse-options in "git
+ rev-parse" has been updated to diagnose a bogus input correctly.
+ (merge f20b9c36d0 ow/rev-parse-parseopt-fix later to maint).
+
+ * The code that manages list-object-filter structure, used in partial
+ clones, leaked the instances, which has been plugged.
+ (merge 66eede4a37 jk/plug-list-object-filter-leaks later to maint).
+
+ * Fix another UI regression in the reimplemented "add -p".
+ (merge f6f0ee247f rs/add-p-worktree-mode-prompt-fix later to maint).
+
+ * "git fetch" over protocol v2 sent an incorrect ref prefix request
+ to the server and made "git pull" with configured fetch refspec
+ that does not cover the remote branch to merge with fail, which has
+ been corrected.
+ (merge 49ca2fba39 jk/proto-v2-ref-prefix-fix later to maint).
+
+ * A result from opendir() was leaking in the commit-graph expiration
+ codepath, which has been plugged.
+ (merge 12f1ae5324 ml/commit-graph-expire-dir-leak-fix later to maint).
+
+ * Just like we have coding guidelines, we now have guidelines for
+ reviewers.
+ (merge e01b851923 vd/doc-reviewing-guidelines later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge 77b9e85c0f vd/fix-perf-tests later to maint).
+ (merge 0682bc43f5 jk/test-crontab-fixes later to maint).
+ (merge b46dd1726c cc/doc-trailer-whitespace-rules later to maint).
diff --git a/RelNotes/2.38.1.adoc b/RelNotes/2.38.1.adoc
new file mode 100644
index 0000000..b2b5854
--- /dev/null
+++ b/RelNotes/2.38.1.adoc
@@ -0,0 +1,5 @@
+Git v2.38.1 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.30.6; see
+the release notes for that version for details.
diff --git a/RelNotes/2.38.2.adoc b/RelNotes/2.38.2.adoc
new file mode 100644
index 0000000..92acb62
--- /dev/null
+++ b/RelNotes/2.38.2.adoc
@@ -0,0 +1,67 @@
+Git 2.38.2 Release Notes
+========================
+
+This is to backport various fixes accumulated during the development
+towards Git 2.39, the next feature release.
+
+
+Fixes since v2.38.1
+-------------------
+
+ * Update CodingGuidelines to clarify what features to use and avoid
+ in C99.
+
+ * The codepath that reads from the index v4 had unaligned memory
+ accesses, which has been corrected.
+
+ * "git remote rename" failed to rename a remote without fetch
+ refspec, which has been corrected.
+
+ * "git clone" did not like to see the "--bare" and the "--origin"
+ options used together without a good reason.
+
+ * Fix messages incorrectly marked for translation.
+
+ * "git fsck" failed to release contents of tree objects already used
+ from the memory, which has been fixed.
+
+ * "git rebase -i" can mistakenly attempt to apply a fixup to a commit
+ itself, which has been corrected.
+
+ * In read-only repositories, "git merge-tree" tried to come up with a
+ merge result tree object, which it failed (which is not wrong) and
+ led to a segfault (which is bad), which has been corrected.
+
+ * Force C locale while running tests around httpd to make sure we can
+ find expected error messages in the log.
+
+ * Fix a logic in "mailinfo -b" that miscomputed the length of a
+ substring, which lead to an out-of-bounds access.
+
+ * The codepath to sign learned to report errors when it fails to read
+ from "ssh-keygen".
+
+ * "GIT_EDITOR=: git branch --edit-description" resulted in failure,
+ which has been corrected.
+
+ * Documentation on various Boolean GIT_* environment variables have
+ been clarified.
+
+ * "git multi-pack-index repack/expire" used to repack unreachable
+ cruft into a new pack, which have been corrected.
+
+ * The code to clean temporary object directories (used for
+ quarantine) tried to remove them inside its signal handler, which
+ was a no-no.
+
+ * "git branch --edit-description" on an unborh branch misleadingly
+ said that no such branch exists, which has been corrected.
+
+ * GitHub CI settings have been adjusted to recent reality, merging
+ and cherry-picking necessary topics that have been prepared for Git
+ 2.39.
+
+ * `git rebase --update-refs` would delete references when all `update-ref`
+ commands in the sequencer were removed, which has been corrected.
+
+Also contains various documentation updates and code clean-ups.
diff --git a/RelNotes/2.38.3.adoc b/RelNotes/2.38.3.adoc
new file mode 100644
index 0000000..4a46bb4
--- /dev/null
+++ b/RelNotes/2.38.3.adoc
@@ -0,0 +1,5 @@
+Git v2.38.3 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.30.7; see
+the release notes for that version for details.
diff --git a/RelNotes/2.38.4.adoc b/RelNotes/2.38.4.adoc
new file mode 100644
index 0000000..fdfde22
--- /dev/null
+++ b/RelNotes/2.38.4.adoc
@@ -0,0 +1,7 @@
+Git v2.38.4 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.30.8, v2.31.7,
+v2.32.6, v2.33.7, v2.34.7, v2.35.7, v2.36.5 and v2.37.6 to
+address the security issues CVE-2023-22490 and CVE-2023-23946;
+see the release notes for these versions for details.
diff --git a/RelNotes/2.38.5.adoc b/RelNotes/2.38.5.adoc
new file mode 100644
index 0000000..2d1f3b1
--- /dev/null
+++ b/RelNotes/2.38.5.adoc
@@ -0,0 +1,8 @@
+Git v2.38.5 Release Notes
+=========================
+
+This release merges up the fix that appears in v2.30.9, v2.31.8,
+v2.32.7, v2.33.8, v2.34.8, v2.35.8, v2.36.6 and v2.37.7 to address
+the security issues CVE-2023-25652, CVE-2023-25815, and
+CVE-2023-29007; see the release notes for these versions for
+details.
diff --git a/RelNotes/2.39.0.adoc b/RelNotes/2.39.0.adoc
new file mode 100644
index 0000000..9bf00ec
--- /dev/null
+++ b/RelNotes/2.39.0.adoc
@@ -0,0 +1,346 @@
+Git v2.39 Release Notes
+=======================
+
+UI, Workflows & Features
+------------------------
+
+ * "git grep" learned to expand the sparse-index more lazily and on
+ demand in a sparse checkout.
+
+ * By default, use of fsmonitor on a repository on networked
+ filesystem is disabled. Add knobs to make it workable on macOS.
+
+ * After checking out a "branch" that is a symbolic-ref that points at
+ another branch, "git symbolic-ref HEAD" reports the underlying
+ branch, not the symbolic-ref the user gave checkout as argument.
+ The command learned the "--no-recurse" option to stop after
+ dereferencing a symbolic-ref only once.
+
+ * "git branch --edit-description @{-1}" is now a way to edit branch
+ description of the branch you were on before switching to the
+ current branch.
+
+ * "git merge-tree --stdin" is a new way to request a series of merges
+ and report the merge results.
+
+ * "git shortlog" learned to group by the "format" string.
+
+ * A new "--include-whitespace" option is added to "git patch-id", and
+ existing bugs in the internal patch-id logic that did not match
+ what "git patch-id" produces have been corrected.
+
+ * Enable gc.cruftpacks by default for those who opt into
+ feature.experimental setting.
+
+ * "git repack" learns to send cruft objects out of the way into
+ packfiles outside the repository.
+
+ * 'scalar reconfigure -a' is taught to automatically remove
+ scalar.repo entires which no longer exist.
+
+ * Redact headers from cURL's h2h3 module in GIT_CURL_VERBOSE and
+ others.
+
+ * 'git maintenance register' is taught to write configuration to an
+ arbitrary path, and 'git for-each-repo' is taught to expand tilde
+ characters in paths.
+
+ * When creating new notes, the template used to get a stray empty
+ newline, which has been removed.
+
+ * "git receive-pack" used to use all the local refs as the boundary for
+ checking connectivity of the data "git push" sent, but now it uses
+ only the refs that it advertised to the pusher. In a repository with
+ the .hideRefs configuration, this reduces the resources needed to
+ perform the check.
+
+ * With '--recurse-submodules=on-demand', all submodules are
+ recursively pushed.
+
+
+Performance, Internal Implementation, Development Support etc.
+--------------------------------------------------------------
+
+ * With a bit of header twiddling, use the native regexp library on
+ macOS instead of the compat/ one.
+
+ * Prepare for GNU [ef]grep that throw warning of their uses.
+
+ * Sources related to fuzz testing have been moved down to their own
+ directory.
+
+ * Most credential helpers ignored unknown entries in a credential
+ description, but a few died upon seeing them. The latter were
+ taught to ignore them, too
+
+ * "scalar unregister" in a repository that is already been
+ unregistered reported an error.
+
+ * Remove error detection from a function that fetches from promisor
+ remotes, and make it die when such a fetch fails to bring all the
+ requested objects, to give an early failure to various operations.
+
+ * Update CodingGuidelines to clarify what features to use and avoid
+ in C99.
+
+ * Avoid false-positive from LSan whose assumption may be broken with
+ higher optimization levels.
+
+ * Enable address and undefined sanitizer tasks at GitHub Actions CI.
+
+ * More UNUSED annotation to help using -Wunused option with the
+ compiler.
+ (merge 4b992f0a24 jk/unused-anno-more later to maint).
+
+ * Rewrite a deep recursion in the skipping negotiator to use a loop
+ with on-heap prio queue to avoid stack wastage.
+
+ * Add documentation for message IDs in fsck error messages.
+
+ * Define the logical elements of a "bundle list", data structure to
+ store them in-core, format to transfer them, and code to parse
+ them.
+
+ * The role the security mailing list plays in an embargoed release
+ has been documented.
+
+ * Two new facilities, "timer" and "counter", are introduced to the
+ trace2 API.
+
+ * Code simplification by using strvec_pushf() instead of building an
+ argument in a separate strbuf.
+
+ * Make sure generated dependency file is stably sorted to help
+ developers debugging their build issues.
+
+ * The glossary entries for "commit-graph file" and "reachability
+ bitmap" have been added.
+
+ * Various tests exercising the transfer.credentialsInUrl
+ configuration are taught to avoid making requests which require
+ resolving localhost to reduce CI-flakiness.
+
+ * A redundant diagnostic message is dropped from test_path_is_missing().
+
+ * Simplify the run-command API.
+
+ * Update the actions/github-script dependency in CI to avoid a
+ deprecation warning.
+
+ * Progress on being able to initialize a rev_info struct with a
+ macro.
+
+ * Add trace2 counters to the region to clear skip worktree bits in a
+ sparse checkout.
+
+ * Modernize test script to avoid "test -f" and friends.
+
+ * Avoid calling 'cache_tree_update()' when doing so would be
+ redundant.
+
+ * Update the credential-cache documentation to provide a more
+ realistic example.
+
+ * Makefile comments updates and reordering to clarify knobs used to
+ choose SHA implementations.
+
+ * A design document for sparse-checkout's future directions has been
+ added.
+
+ * Teach chainlint.pl to annotate the original test definition instead
+ of the token stream.
+
+ * "make coccicheck" is time consuming. It has been made to run more
+ incrementally.
+
+ * `parse_object()` has been hardened to check for the existence of a
+ suspected blob object.
+
+ * The build procedure has been adjusted to GNUmake version 4.4, which
+ made some changes to how pattern rule with multiple targets are
+ handled.
+
+
+Fixes since v2.38
+-----------------
+
+ * The codepath that reads from the index v4 had unaligned memory
+ accesses, which has been corrected.
+
+ * Fix messages incorrectly marked for translation.
+
+ * "git fsck" failed to release contents of tree objects already used
+ from the memory, which has been fixed.
+
+ * "git clone" did not like to see the "--bare" and the "--origin"
+ options used together without a good reason.
+
+ * "git remote rename" failed to rename a remote without fetch
+ refspec, which has been corrected.
+
+ * Documentation on various Boolean GIT_* environment variables have
+ been clarified.
+
+ * "git rebase -i" can mistakenly attempt to apply a fixup to a commit
+ itself, which has been corrected.
+
+ * "git multi-pack-index repack/expire" used to repack unreachable
+ cruft into a new pack, which have been corrected.
+
+ * In read-only repositories, "git merge-tree" tried to come up with a
+ merge result tree object, which it failed (which is not wrong) and
+ led to a segfault (which is bad), which has been corrected.
+
+ * Force C locale while running tests around httpd to make sure we can
+ find expected error messages in the log.
+
+ * Fix a logic in "mailinfo -b" that miscomputed the length of a
+ substring, which lead to an out-of-bounds access.
+
+ * The codepath to sign learned to report errors when it fails to read
+ from "ssh-keygen".
+
+ * Code clean-up that results in plugging a leak.
+
+ * "GIT_EDITOR=: git branch --edit-description" resulted in failure,
+ which has been corrected.
+
+ * The code to clean temporary object directories (used for
+ quarantine) tried to remove them inside its signal handler, which
+ was a no-no.
+
+ * Update comment in the Makefile about the RUNTIME_PREFIX config knob.
+
+ * Clarify that "the sentence after <area>: prefix does not begin with
+ a capital letter" rule applies only to the commit title.
+
+ * "git branch --edit-description" on an unborn branch misleadingly
+ said that no such branch exists, which has been corrected.
+
+ * Work around older clang that warns against C99 zero initialization
+ syntax for struct.
+
+ * Giving "--invert-grep" and "--all-match" without "--grep" to the
+ "git log" command resulted in an attempt to access grep pattern
+ expression structure that has not been allocated, which has been
+ corrected.
+ (merge db84376f98 ab/grep-simplify-extended-expression later to maint).
+
+ * "git diff rev^!" did not show combined diff to go to the rev from
+ its parents.
+ (merge a79c6b6081 rs/diff-caret-bang-with-parents later to maint).
+
+ * Allow configuration files in "protected" scopes to include other
+ configuration files.
+ (merge ecec57b3c9 gc/bare-repo-discovery later to maint).
+
+ * Give a bit more diversity to macOS CI by using sha1dc in one of the
+ jobs (the other one tests Apple Common Crypto).
+ (merge 1ad5c3df35 jc/ci-osx-with-sha1dc later to maint).
+
+ * A bugfix with tracing support in midx codepath
+ (merge e9c3839944 tb/midx-bitmap-selection-fix later to maint).
+
+ * When geometric repacking feature is in use together with the
+ --pack-kept-objects option, we lost packs marked with .keep files.
+ (merge 197443e80a tb/save-keep-pack-during-geometric-repack later to maint).
+
+ * Move a global variable added as a hack during regression fixes to
+ its proper place in the API.
+ (merge 0b0ab95f17 ab/run-hook-api-cleanup later to maint).
+
+ * Update to build procedure with VS using CMake/CTest.
+ (merge c858750b41 js/cmake-updates later to maint).
+
+ * The short-help text shown by "git cmd -h" and the synopsis text
+ shown at the beginning of "git help cmd" have been made more
+ consistent.
+
+ * When creating a multi-pack bitmap, remove per-pack bitmap files
+ unconditionally as they will never be consulted.
+ (merge 55d902cd61 tb/remove-unused-pack-bitmap later to maint).
+
+ * Fix a longstanding syntax error in Git.pm error codepath.
+
+ * "git diff --stat" etc. were invented back when everything was ASCII
+ and strlen() was a way to measure the display width of a string;
+ adjust them to compute the display width assuming UTF-8 pathnames.
+ (merge ce8529b2bb tb/diffstat-with-utf8-strwidth later to maint).
+
+ * "git branch --edit-description" can exit with status -1 which is
+ not a good practice; it learned to use 1 as everybody else instead.
+
+ * "git apply" limits its input to a bit less than 1 GiB.
+
+ * Merging a branch with directory renames into a branch that changes
+ the directory to a symlink was mishandled by the ort merge
+ strategy, which has been corrected.
+
+ * A bugfix to "git subtree" in its split and merge features.
+
+ * Fix some bugs in the reflog messages when rebasing and changes the
+ reflog messages of "rebase --apply" to match "rebase --merge" with
+ the aim of making the reflog easier to parse.
+
+ * "git rebase --keep-base" used to discard the commits that are
+ already cherry-picked to the upstream, even when "keep-base" meant
+ that the base, on top of which the history is being rebuilt, does
+ not yet include these cherry-picked commits. The --keep-base
+ option now implies --reapply-cherry-picks and --no-fork-point
+ options.
+
+ * The way "git repack" created temporary files when it received a
+ signal was prone to deadlocking, which has been corrected.
+
+ * Various tests exercising the transfer.credentialsInUrl
+ configuration are taught to avoid making requests which require
+ resolving localhost to reduce CI-flakiness.
+
+ * The adjust_shared_perm() helper function learned to refrain from
+ setting the "g+s" bit on directories when it is not necessary.
+
+ * "git archive" mistakenly complained twice about a missing
+ executable, which has been corrected.
+
+ * Fix a bug where `git branch -d` did not work on an orphaned HEAD.
+
+ * `git rebase --update-refs` would delete references when all
+ `update-ref` commands in the sequencer were removed, which has been
+ corrected.
+
+ * Fix a regression in the bisect-helper which mistakenly treats
+ arguments to the command given to 'git bisect run' as arguments to
+ the helper.
+
+ * Correct an error where `git rebase` would mistakenly use a branch or
+ tag named "refs/rewritten/xyz" when missing a rebase label.
+
+ * Assorted fixes of parsing end-user input as integers.
+ (merge 14770cf0de pw/config-int-parse-fixes later to maint).
+
+ * "git prune" may try to iterate over .git/objects/pack for trash
+ files to remove in it, and loudly fail when the directory is
+ missing, which is not necessary. The command has been taught to
+ ignore such a failure.
+ (merge 6974765352 ew/prune-with-missing-objects-pack later to maint).
+
+ * Add one more candidate directory that may house httpd modules while
+ running tests.
+ (merge 1c7dc23d41 es/locate-httpd-module-location-in-test later to maint).
+
+ * A handful of leaks in the line-log machinery have been plugged.
+
+ * The format of a line in /proc/cpuinfo that describes a CPU on s390x
+ looked different from everybody else, and the code in chainlint.pl
+ failed to parse it.
+ (merge 1f51b77f4f ah/chainlint-cpuinfo-parse-fix later to maint).
+
+ * Adjust the GitHub CI to newer ubuntu release.
+ (merge 0d3507f3e7 jx/ci-ubuntu-fix later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge 413bc6d20a ds/cmd-main-reorder later to maint).
+ (merge 8d2863e4ed nw/t1002-cleanup later to maint).
+ (merge 7c2dc122f9 rs/list-objects-filter-leakfix later to maint).
+ (merge 288fcb1c94 zk/push-use-bitmaps later to maint).
+ (merge 42db324c0f km/merge-recursive-typofix later to maint).
diff --git a/RelNotes/2.39.1.adoc b/RelNotes/2.39.1.adoc
new file mode 100644
index 0000000..60c86f4
--- /dev/null
+++ b/RelNotes/2.39.1.adoc
@@ -0,0 +1,5 @@
+Git v2.39.1 Release Notes
+=========================
+
+This release merges the security fix that appears in v2.30.7; see
+the release notes for that version for details.
diff --git a/RelNotes/2.39.2.adoc b/RelNotes/2.39.2.adoc
new file mode 100644
index 0000000..ebb9900
--- /dev/null
+++ b/RelNotes/2.39.2.adoc
@@ -0,0 +1,7 @@
+Git v2.39.2 Release Notes
+=========================
+
+This release merges up the fixes that appear in v2.30.8, v2.31.7,
+v2.32.6, v2.33.7, v2.34.7, v2.35.7, v2.36.5, v2.37.6 and v2.38.4
+to address the security issues CVE-2023-22490 and CVE-2023-23946;
+see the release notes for these versions for details.
diff --git a/RelNotes/2.39.3.adoc b/RelNotes/2.39.3.adoc
new file mode 100644
index 0000000..66351b6
--- /dev/null
+++ b/RelNotes/2.39.3.adoc
@@ -0,0 +1,64 @@
+Git v2.39.3 Release Notes
+=========================
+
+This release merges up the fix that appears in v2.30.9, v2.31.8,
+v2.32.7, v2.33.8, v2.34.8, v2.35.8, v2.36.6, v2.37.7 and v2.38.5 to
+address the security issues CVE-2023-25652, CVE-2023-25815, and
+CVE-2023-29007; see the release notes for these versions for
+details.
+
+This release also merges fixes that have accumulated on the 'master'
+front to prepare for the 2.40 release that are still relevant to
+2.39.x maintenance track.
+
+Fixes since v2.39.2
+-------------------
+
+ * Stop running win+VS build by default.
+
+ * CI updates. We probably want a clean-up to move the long shell
+ script embedded in yaml file into a separate file, but that can
+ come later.
+
+ * Avoid unnecessary builds in CI, with settings configured in
+ ci-config.
+
+ * Redefining system functions for a few functions did not follow our
+ usual "implement git_foo() and #define foo(args) git_foo(args)"
+ pattern, which has broken build for some folks.
+
+ * Deal with a few deprecation warning from cURL library.
+
+ * Newer regex library macOS stopped enabling GNU-like enhanced BRE,
+ where '\(A\|B\)' works as alternation, unless explicitly asked with
+ the REG_ENHANCED flag. "git grep" now can be compiled to do so, to
+ retain the old behaviour.
+
+ * When given a pattern that matches an empty string at the end of a
+ line, the code to parse the "git diff" line-ranges fell into an
+ infinite loop, which has been corrected.
+
+ * Fix the sequence to fsync $GIT_DIR/packed-refs file that forgot to
+ flush its output to the disk..
+
+ * "git diff --relative" did not mix well with "git diff --ext-diff",
+ which has been corrected.
+
+ * The logic to see if we are using the "cone" mode by checking the
+ sparsity patterns has been tightened to avoid mistaking a pattern
+ that names a single file as specifying a cone.
+
+ * Doc update for environment variables set when hooks are invoked.
+
+ * Document ORIG_HEAD a bit more.
+
+ * "git ls-tree --format='%(path) %(path)' $tree $path" showed the
+ path three times, which has been corrected.
+
+ * Document that "branch -f <branch>" disables only the safety to
+ avoid recreating an existing branch.
+
+ * Clarify how "checkout -b/-B" and "git branch [-f]" are similar but
+ different in the documentation.
+
+Also contains minor documentation updates and code clean-ups.
diff --git a/RelNotes/2.39.4.adoc b/RelNotes/2.39.4.adoc
new file mode 100644
index 0000000..7f54521
--- /dev/null
+++ b/RelNotes/2.39.4.adoc
@@ -0,0 +1,79 @@
+Git v2.39.4 Release Notes
+=========================
+
+This addresses the security issues CVE-2024-32002, CVE-2024-32004,
+CVE-2024-32020 and CVE-2024-32021.
+
+This release also backports fixes necessary to let the CI builds pass
+successfully.
+
+Fixes since v2.39.3
+-------------------
+
+ * CVE-2024-32002:
+
+ Recursive clones on case-insensitive filesystems that support symbolic
+ links are susceptible to case confusion that can be exploited to
+ execute just-cloned code during the clone operation.
+
+ * CVE-2024-32004:
+
+ Repositories can be configured to execute arbitrary code during local
+ clones. To address this, the ownership checks introduced in v2.30.3
+ are now extended to cover cloning local repositories.
+
+ * CVE-2024-32020:
+
+ Local clones may end up hardlinking files into the target repository's
+ object database when source and target repository reside on the same
+ disk. If the source repository is owned by a different user, then
+ those hardlinked files may be rewritten at any point in time by the
+ untrusted user.
+
+ * CVE-2024-32021:
+
+ When cloning a local source repository that contains symlinks via the
+ filesystem, Git may create hardlinks to arbitrary user-readable files
+ on the same filesystem as the target repository in the objects/
+ directory.
+
+ * CVE-2024-32465:
+
+ It is supposed to be safe to clone untrusted repositories, even those
+ unpacked from zip archives or tarballs originating from untrusted
+ sources, but Git can be tricked to run arbitrary code as part of the
+ clone.
+
+ * Defense-in-depth: submodule: require the submodule path to contain
+ directories only.
+
+ * Defense-in-depth: clone: when symbolic links collide with directories, keep
+ the latter.
+
+ * Defense-in-depth: clone: prevent hooks from running during a clone.
+
+ * Defense-in-depth: core.hooksPath: add some protection while cloning.
+
+ * Defense-in-depth: fsck: warn about symlink pointing inside a gitdir.
+
+ * Various fix-ups on HTTP tests.
+
+ * Test update.
+
+ * HTTP Header redaction code has been adjusted for a newer version of
+ cURL library that shows its traces differently from earlier
+ versions.
+
+ * Fix was added to work around a regression in libcURL 8.7.0 (which has
+ already been fixed in their tip of the tree).
+
+ * Replace macos-12 used at GitHub CI with macos-13.
+
+ * ci(linux-asan/linux-ubsan): let's save some time
+
+ * Tests with LSan from time to time seem to emit harmless message that makes
+ our tests unnecessarily flakey; we work it around by filtering the
+ uninteresting output.
+
+ * Update GitHub Actions jobs to avoid warnings against using deprecated
+ version of Node.js.
diff --git a/RelNotes/2.39.5.adoc b/RelNotes/2.39.5.adoc
new file mode 100644
index 0000000..97c0185
--- /dev/null
+++ b/RelNotes/2.39.5.adoc
@@ -0,0 +1,26 @@
+Git v2.39.5 Release Notes
+=========================
+
+In preparing security fixes for four CVEs, we made overly aggressive
+"defense in depth" changes that broke legitimate use cases like 'git
+lfs' and 'git annex.' This release is to revert these misguided, if
+well-intentioned, changes that were shipped in 2.39.4 and were not
+direct security fixes.
+
+Jeff King (5):
+ send-email: drop FakeTerm hack
+ send-email: avoid creating more than one Term::ReadLine object
+ ci: drop mention of BREW_INSTALL_PACKAGES variable
+ ci: avoid bare "gcc" for osx-gcc job
+ ci: stop installing "gcc-13" for osx-gcc
+
+Johannes Schindelin (6):
+ hook: plug a new memory leak
+ init: use the correct path of the templates directory again
+ Revert "core.hooksPath: add some protection while cloning"
+ tests: verify that `clone -c core.hooksPath=/dev/null` works again
+ clone: drop the protections where hooks aren't run
+ Revert "Add a helper function to compare file contents"
+
+Junio C Hamano (1):
+ Revert "fsck: warn about symlink pointing inside a gitdir"
diff --git a/RelNotes/2.4.0.adoc b/RelNotes/2.4.0.adoc
new file mode 100644
index 0000000..cde64be
--- /dev/null
+++ b/RelNotes/2.4.0.adoc
@@ -0,0 +1,514 @@
+Git 2.4 Release Notes
+=====================
+
+Backward compatibility warning(s)
+---------------------------------
+
+This release has a few changes in the user-visible output from
+Porcelain commands. These are not meant to be parsed by scripts, but
+users still may want to be aware of the changes:
+
+ * The output from "git log --decorate" (and, more generally, the "%d"
+ format specifier used in the "--format=<string>" parameter to the
+ "git log" family of commands) has changed. It used to list "HEAD"
+ just like other branches; e.g.,
+
+ $ git log --decorate -1 master
+ commit bdb0f6788fa5e3cacc4315e9ff318a27b2676ff4 (HEAD, master)
+ ...
+
+ This release changes the output slightly when HEAD refers to a
+ branch whose name is also shown in the output. The above is now
+ shown as:
+
+ $ git log --decorate -1 master
+ commit bdb0f6788fa5e3cacc4315e9ff318a27b2676ff4 (HEAD -> master)
+ ...
+
+ * The phrasing "git branch" uses to describe a detached HEAD has been
+ updated to agree with the phrasing used by "git status":
+
+ - When HEAD is at the same commit as when it was originally
+ detached, they now both show "detached at <commit object name>".
+
+ - When HEAD has moved since it was originally detached, they now
+ both show "detached from <commit object name>".
+
+ Previously, "git branch" always used "from".
+
+
+Updates since v2.3
+------------------
+
+Ports
+
+ * Our default I/O size (8 MiB) for large files was too large for some
+ platforms with smaller SSIZE_MAX, leading to read(2)/write(2)
+ failures.
+
+ * We did not check the curl library version before using the
+ CURLOPT_PROXYAUTH feature, which did not exist in older versions of
+ the library.
+
+ * We now detect number of CPUs on older BSD-derived systems.
+
+ * Portability fixes and workarounds for shell scripts have been added
+ to help BSD-derived systems.
+
+
+UI, Workflows & Features
+
+ * The command usage info strings given by "git cmd -h" and in
+ documentation have been tweaked for consistency.
+
+ * The "sync" subcommand of "git p4" now allows users to exclude
+ subdirectories like its "clone" subcommand does.
+
+ * "git log --invert-grep --grep=WIP" will show only commits that do
+ not have the string "WIP" in their messages.
+
+ * "git push" has been taught an "--atomic" option that makes a push
+ that updates more than one ref an "all-or-none" affair.
+
+ * Extending the "push to deploy" feature that was added in 2.3, the
+ behaviour of "git push" when updating the branch that is checked
+ out can now be tweaked by a "push-to-checkout" hook.
+
+ * HTTP-based transports now send Accept-Language when making
+ requests. The languages to accept are inferred from environment
+ variables on the client side (LANGUAGE, etc).
+
+ * "git send-email" used to accept a mistaken "y" (or "yes") as an
+ answer to "What encoding do you want to use [UTF-8]?" without
+ questioning. Now it asks for confirmation when the answer looks too
+ short to be a valid encoding name.
+
+ * When "git apply --whitespace=fix" fixed whitespace errors in the
+ common context lines, the command reports that it did so.
+
+ * "git status" now allows the "-v" option to be given twice, in which
+ case it also shows the differences in the working tree that are not
+ staged to be committed.
+
+ * "git cherry-pick" used to clean up the log message even when it is
+ merely replaying an existing commit. It now replays the message
+ verbatim unless you are editing the message of the resulting
+ commit.
+
+ * "git archive" can now be told to set the 'text' attribute in the
+ resulting zip archive.
+
+ * Output from "git log --decorate" now distinguishes between a
+ detached HEAD vs. a HEAD that points at a branch.
+
+ This is a potentially backward-incompatible change; see above for
+ more information.
+
+ * When HEAD was detached when at commit xyz and hasn't been moved
+ since it was detached, "git status" would report "detached at xyz"
+ whereas "git branch" would report "detached from xyz". Now the
+ output of "git branch" agrees with that of "git status".
+
+ This is a potentially backward-incompatible change; see above for
+ more information.
+
+ * "git -C '' subcmd" now works in the current directory (analogously
+ to "cd ''") rather than dying with an error message.
+ (merge 6a536e2 kn/git-cd-to-empty later to maint).
+
+ * The versionsort.prereleaseSuffix configuration variable can be used
+ to specify that, for example, v1.0-pre1 comes before v1.0.
+
+ * A new "push.followTags" configuration turns the "--follow-tags"
+ option on by default for the "git push" command.
+
+ * "git log --graph --no-walk A B..." is a nonsensical combination of
+ options: "--no-walk" requests discrete points in the history, while
+ "--graph" asks to draw connections between these discrete points.
+ Forbid the use of these options together.
+
+ * "git rev-list --bisect --first-parent" does not work (yet) and can
+ even cause SEGV; forbid it. "git log --bisect --first-parent" would
+ not be useful until "git bisect --first-parent" materializes, so
+ also forbid it for now.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * Slightly change the implementation of the N_() macro to help us
+ detect mistakes.
+
+ * Restructure the implementation of "reflog expire" to fit better
+ with the recently updated reference API.
+
+ * The transport-helper did not pass transport options such as
+ verbosity, progress, cloning, etc. to import and export based
+ helpers, like it did for fetch and push based helpers, robbing them
+ of the chance to honor the wish of the end-users better.
+
+ * The tests that wanted to see that a file becomes unreadable after
+ running "chmod a-r file", and the tests that wanted to make sure
+ that they are not run as root, used "can we write into the /
+ directory?" as a cheap substitute. But on some platforms that is
+ not a good heuristic. The tests and their prerequisites have been
+ updated to check what they really require.
+ (merge f400e51 jk/sanity later to maint).
+
+ * Various issues around "reflog expire", e.g. using --updateref when
+ expiring a reflog for a symbolic reference, have been corrected
+ and/or made saner.
+
+ * The documentation for the strbuf API had been split between the API
+ documentation and the header file. Consolidate the documentation in
+ strbuf.h.
+
+ * The error handling functions and conventions are now documented in
+ the API manual (in api-error-handling.txt).
+
+ * Optimize gitattribute look-up, mostly useful in "git grep" on a
+ project that does not use many attributes, by avoiding it when we
+ (should) know that the attributes are not defined in the first
+ place.
+
+ * Typofix in comments.
+ (merge ef2956a ak/git-pm-typofix later to maint).
+
+ * Code clean-up.
+ (merge 0b868f0 sb/hex-object-name-is-at-most-41-bytes-long later to maint).
+ (merge 5d30851 dp/remove-duplicated-header-inclusion later to maint).
+
+ * Simplify the ref transaction API for verifying that "the ref should
+ be pointing at this object".
+
+ * Simplify the code in "git daemon" that parses out and holds
+ hostnames used in request interpolation.
+
+ * Restructure the "git push" codepath to make it easier to add new
+ configuration bits.
+
+ * The run-command interface made it easy to make a pipe for us to
+ read from a process, wait for the process to finish, and then
+ attempt to read its output. But this pattern can lead to deadlock.
+ So introduce a helper to do this correctly (i.e., first read, and
+ then wait the process to finish) and also add code to prevent such
+ abuse in the run-command helper.
+
+ * People often forget to chain the commands in their test together
+ with &&, letting a failure from an earlier command in the test go
+ unnoticed. The new GIT_TEST_CHAIN_LINT mechanism allows you to
+ catch such a mistake more easily.
+
+
+Also contains various documentation updates and code clean-ups.
+
+
+Fixes since v2.3
+----------------
+
+Unless otherwise noted, all the fixes since v2.3 in the maintenance
+track are contained in this release (see the maintenance releases'
+notes for details).
+
+ * "git blame HEAD -- missing" failed to correctly say "HEAD" when it
+ tried to say "No such path 'missing' in HEAD".
+ (merge a46442f jk/blame-commit-label later to maint).
+
+ * "git rerere" (invoked internally from many mergy operations) did
+ not correctly signal errors when it attempted to update the working
+ tree files but failed for whatever reason.
+ (merge 89ea903 jn/rerere-fail-on-auto-update-failure later to maint).
+
+ * Setting diff.submodule to 'log' made "git format-patch" produce
+ broken patches.
+ (merge 339de50 dk/format-patch-ignore-diff-submodule later to maint).
+
+ * After attempting and failing a password-less authentication (e.g.,
+ Kerberos), libcURL refuses to fall back to password-based Basic
+ authentication without a bit of help/encouragement.
+ (merge 4dbe664 bc/http-fallback-to-password-after-krb-fails later to maint).
+
+ * The "git push" documentation for the "--repo=<there>" option was
+ easily misunderstood.
+ (merge 57b92a7 mg/push-repo-option-doc later to maint).
+
+ * Code to read a branch name from various files in the .git/
+ directory would have overrun array limits if asked to read an empty
+ file.
+ (merge 66ec904 jk/status-read-branch-name-fix later to maint).
+
+ * Remove a superfluous conditional that is always true.
+ (merge 94ee8e2 jk/remote-curl-an-array-in-struct-cannot-be-null later to maint).
+
+ * The "git diff --raw" documentation incorrectly implied that C(opy)
+ and R(ename) are the only statuses that can be followed by a score
+ number.
+ (merge ac1c2d9 jc/diff-format-doc later to maint).
+
+ * A broken pack .idx file in the receiving repository prevented the
+ dumb http transport from fetching a good copy of it from the other
+ side.
+ (merge 8b9c2dd jk/dumb-http-idx-fetch-fix later to maint).
+
+ * The error message from "git commit", when a non-existing author
+ name was given as value to the "--author=" parameter, has been
+ reworded to avoid misunderstanding.
+ (merge 1044b1f mg/commit-author-no-match-malformed-message later to maint).
+
+ * "git log --help" used to show rev-list options that are irrelevant
+ to the "log" command.
+ (merge 3cab02d jc/doc-log-rev-list-options later to maint).
+
+ * "git apply --whitespace=fix" used to under-allocate memory when the
+ fix resulted in a longer text than the original patch.
+ (merge 407a792 jc/apply-ws-fix-expands later to maint).
+
+ * The interactive "show a list and let the user choose from it"
+ interface used by "git add -i" unnecessarily prompted the user even
+ when the candidate list was empty, against which the only "choice"
+ the user could have made was to choose nothing.
+ (merge a9c4641 ak/add-i-empty-candidates later to maint).
+
+ * The todo list created by "git rebase -i" did not fully honor
+ core.abbrev settings.
+ (merge edb72d5 ks/rebase-i-abbrev later to maint).
+
+ * "git fetch" over a remote-helper that cannot respond to the "list"
+ command could not fetch from a symbolic reference (e.g., HEAD).
+ (merge 33cae54 mh/deref-symref-over-helper-transport later to maint).
+
+ * "git push --signed" gave an incorrectly worded error message when
+ the other side did not support the capability.
+
+ * The "git push --signed" protocol extension did not limit what the
+ "nonce" (a server-chosen string) could contain nor how long it
+ could be, which was unnecessarily lax. Limit both the length and
+ the alphabet to a reasonably small space that can still have enough
+ entropy.
+ (merge afcb6ee jc/push-cert later to maint).
+
+ * The completion script (in contrib/) clobbered the shell variable $x
+ in the global shell namespace.
+ (merge 852ff1c ma/bash-completion-leaking-x later to maint).
+
+ * We incorrectly formatted a "uintmax_t" integer that doesn't fit in
+ "int".
+ (merge d306f3d jk/decimal-width-for-uintmax later to maint).
+
+ * The configuration parser used to be confused when reading
+ configuration from a blob object that ends with a lone CR.
+ (merge 1d0655c jk/config-no-ungetc-eof later to maint).
+
+ * The pack bitmap support did not build with older versions of GCC.
+ (merge bd4e882 jk/pack-bitmap later to maint).
+
+ * The documentation wasn't clear that "remote.<nick>.pushURL" and
+ "remote.<nick>.URL" are there to name the same repository accessed
+ via different transports, not two separate repositories.
+ (merge 697f652 jc/remote-set-url-doc later to maint).
+
+ * Older GnuPG implementations may not correctly import the keyring
+ material we prepare for the tests to use.
+ (merge 1f985d6 ch/new-gpg-drops-rfc-1991 later to maint).
+
+ * The credential helper for Windows (in contrib/) used to mishandle
+ user names that contain an at-sign.
+ (merge 13d261e av/wincred-with-at-in-username-fix later to maint).
+
+ * "diff-highlight" (in contrib/) used to show byte-by-byte
+ differences, which could cause multi-byte characters to be chopped
+ in the middle. It learned to pay attention to character boundaries
+ (assuming UTF-8).
+ (merge 8d00662 jk/colors later to maint).
+
+ * Document longstanding configuration variable naming rules in
+ CodingGuidelines.
+ (merge 35840a3 jc/conf-var-doc later to maint).
+
+ * An earlier workaround to squelch unhelpful deprecation warnings
+ from the compiler on OS X unnecessarily set a minimum required
+ version of the OS, which the user might want to raise (or lower)
+ for other reasons.
+ (merge 88c03eb es/squelch-openssl-warnings-on-macosx later to maint).
+
+ * Certain older vintages of cURL give irregular output from
+ "curl-config --vernum", which confused our build system.
+ (merge 3af6792 tc/curl-vernum-output-broken-in-7.11 later to maint).
+
+ * In v2.2.0, we broke "git prune" that runs in a repository that
+ borrows from an alternate object store.
+ (merge b0a4264 jk/prune-mtime later to maint).
+
+ * "git submodule add" failed to squash "path/to/././submodule" to
+ "path/to/submodule".
+ (merge 8196e72 ps/submodule-sanitize-path-upon-add later to maint).
+
+ * "git merge-file" did not work correctly when invoked in a
+ subdirectory.
+ (merge 204a8ff ab/merge-file-prefix later to maint).
+
+ * "git blame" could die trying to free an uninitialized piece of
+ memory.
+ (merge e600592 es/blame-commit-info-fix later to maint).
+
+ * "git fast-import" used to crash when it could not close and
+ finalize the resulting packfile cleanly.
+ (merge 5e915f3 jk/fast-import-die-nicely-fix later to maint).
+
+ * "update-index --refresh" used to leak memory when an entry could
+ not be refreshed for whatever reason.
+ (merge bc1c2ca sb/plug-leak-in-make-cache-entry later to maint).
+
+ * The "interpolated-path" option of "git daemon" inserted any string
+ the client declared on the "host=" capability request without
+ checking. Sanitize and limit %H and %CH to a saner and a valid DNS
+ name.
+ (merge b485373 jk/daemon-interpolate later to maint).
+
+ * "git daemon" unnecessarily looked up the hostname even when "%CH"
+ and "%IP" interpolations were not requested.
+ (merge dc8edc8 rs/daemon-interpolate later to maint).
+
+ * We relied on "--no-" prefix handling in Perl's Getopt::Long
+ package, even though that support didn't exist in Perl 5.8 (which
+ we still support). Manually add support to help people with older
+ Getopt::Long packages.
+ (merge f471494 km/send-email-getopt-long-workarounds later to maint).
+
+ * "git apply" was not very careful about reading from, removing,
+ updating and creating paths outside the working tree (under
+ --index/--cached) or the current directory (when used as a
+ replacement for GNU patch).
+ (merge e0d201b jc/apply-beyond-symlink later to maint).
+
+ * Correct a breakage in git-svn, introduced around the v2.2 era, that
+ can cause FileHandles to be closed prematurely.
+ (merge e426311 ew/svn-maint-fixes later to maint).
+
+ * We did not parse usernames followed by literal IPv6 addresses
+ correctly in SSH transport URLs; e.g.,
+ ssh://user@[2001:db8::1]:22/repo.git.
+ (merge 6b6c5f7 tb/connect-ipv6-parse-fix later to maint).
+
+ * The configuration variable 'mailinfo.scissors' was hard to
+ discover in the documentation.
+ (merge afb5de7 mm/am-c-doc later to maint).
+
+ * The interaction between "git submodule update" and the
+ submodule.*.update configuration was not clearly documented.
+ (merge 5c31acf ms/submodule-update-config-doc later to maint).
+
+ * "git diff --shortstat" used together with "--dirstat=changes" or
+ "--dirstat=files" incorrectly output dirstat information twice.
+ (merge ab27389 mk/diff-shortstat-dirstat-fix later to maint).
+
+ * The manpage for "git remote add" mentioned "--tags" and "--no-tags"
+ but did not explain what happens if neither option is provided.
+ (merge aaba0ab mg/doc-remote-tags-or-not later to maint).
+
+ * The description of "--exclude-standard option" in the output of
+ "git grep -h" was phrased poorly.
+ (merge 77fdb8a nd/grep-exclude-standard-help-fix later to maint).
+
+ * "git rebase -i" recently started to include the number of commits
+ in the todo list, but that output included extraneous whitespace on
+ a platform that prepends leading whitespaces to its "wc -l" output.
+ (merge 2185d3b es/rebase-i-count-todo later to maint).
+
+ * The borrowed code in the kwset API did not follow our usual
+ convention to use "unsigned char" to store values that range from
+ 0-255.
+ (merge 189c860 bw/kwset-use-unsigned later to maint).
+
+ * A corrupt input to "git diff -M" used to cause it to segfault.
+ (merge 4d6be03 jk/diffcore-rename-duplicate later to maint).
+
+ * Certain builds of GPG triggered false breakages in a test.
+ (merge 3f88c1b mg/verify-commit later to maint).
+
+ * "git imap-send" learned to optionally talk with an IMAP server via
+ libcURL. Because there is no other option when Git is built with
+ the NO_OPENSSL option, use libcURL by default in that case.
+ (merge dcd01ea km/imap-send-libcurl-options later to maint).
+
+ * "git log --decorate" did not reset colors correctly around the
+ branch names.
+ (merge 5ee8758 jc/decorate-leaky-separator-color later to maint).
+
+ * The code that reads from the ctags file in the completion script
+ (in contrib/) did not spell ${param/pattern/string} substitution
+ correctly, which happened to work with bash but not with zsh.
+ (merge db8d750 js/completion-ctags-pattern-substitution-fix later to maint).
+
+ * The transfer.hiderefs support did not quite work for smart-http
+ transport.
+ (merge 8ddf3ca jk/smart-http-hide-refs later to maint).
+
+ * In the "git tag -h" output, move the documentation for the
+ "--column" and "--sort" options to the "Tag listing options"
+ section.
+ (merge dd059c6 jk/tag-h-column-is-a-listing-option later to maint).
+
+ * "git prune" used to largely ignore broken refs when deciding which
+ objects are still being used, which could cause reference
+ corruption to lead to object loss.
+ (merge ea56c4e jk/prune-with-corrupt-refs later to maint).
+
+ * The split-index mode introduced in v2.3.0-rc0~41 was broken in the
+ codepath to protect us against a broken reimplementation of Git
+ that writes an invalid index with duplicated index entries, etc.
+ (merge 03f15a7 tg/fix-check-order-with-split-index later to maint).
+
+ * "git fetch", when fetching a commit using the
+ allow-tip-sha1-in-want extension, could have failed to fetch all of
+ the requested refs.
+ (merge 32d0462 jk/fetch-pack later to maint).
+
+ * An failure early in the "git clone" that started creating the
+ working tree and repository could have resulted in the failure to
+ clean up some directories and files.
+ (merge 16eff6c jk/cleanup-failed-clone later to maint).
+
+ * Recommend format-patch and send-email for those who want to submit
+ patches to this project.
+ (merge b25c469 jc/submitting-patches-mention-send-email later to maint).
+
+ * Do not spawn the pager when "git grep" is run with "--quiet".
+ (merge c2048f0 ws/grep-quiet-no-pager later to maint).
+
+ * The prompt script (in contrib/) did not show the untracked sign
+ when working in a subdirectory without any untracked files.
+ (merge 9bdc517 ct/prompt-untracked-fix later to maint).
+
+ * An earlier update to the URL parser broke an address that contains
+ a colon but an empty string for the port number, like
+ ssh://example.com:/path/to/repo.
+ (merge 6b6c5f7 tb/connect-ipv6-parse-fix later to maint).
+
+ * Code cleanups and documentation updates.
+ (merge 2ce63e9 rs/simple-cleanups later to maint).
+ (merge 33baa69 rj/no-xopen-source-for-cygwin later to maint).
+ (merge 817d03e jc/diff-test-updates later to maint).
+ (merge eb32c66 ak/t5516-typofix later to maint).
+ (merge bcd57cb mr/doc-clean-f-f later to maint).
+ (merge 0d6accc mg/doc-status-color-slot later to maint).
+ (merge 53e53c7 sg/completion-remote later to maint).
+ (merge 8fa7975 ak/git-done-help-cleanup later to maint).
+ (merge 9a6f128 rs/deflate-init-cleanup later to maint).
+ (merge 6f75d45 rs/use-isxdigit later to maint).
+ (merge 376e4b3 jk/test-annoyances later to maint).
+ (merge 7032054 nd/doc-git-index-version later to maint).
+ (merge e869c5e tg/test-index-v4 later to maint).
+ (merge 599d223 jk/simplify-csum-file-sha1fd-check later to maint).
+ (merge 260d585 sg/completion-gitcomp-nl-for-refs later to maint).
+ (merge 777c55a jc/report-path-error-to-dir later to maint).
+ (merge fddfaf8 ph/push-doc-cas later to maint).
+ (merge d50d31e ss/pull-rebase-preserve later to maint).
+ (merge c8c3f1d pt/enter-repo-comment-fix later to maint).
+ (merge d7bfb9e jz/gitweb-conf-doc-fix later to maint).
+ (merge f907282 jk/cherry-pick-docfix later to maint).
+ (merge d3c0811 iu/fix-parse-options-h-comment later to maint).
+ (merge 6c3b2af jg/cguide-we-cannot-count later to maint).
+ (merge 2b8bd44 jk/pack-corruption-post-mortem later to maint).
+ (merge 9585cb8 jn/doc-fast-import-no-16-octopus-limit later to maint).
+ (merge 5dcd1b1 ps/grep-help-all-callback-arg later to maint).
+ (merge f1f4c84 va/fix-git-p4-tests later to maint).
diff --git a/RelNotes/2.4.1.adoc b/RelNotes/2.4.1.adoc
new file mode 100644
index 0000000..a65a6c5
--- /dev/null
+++ b/RelNotes/2.4.1.adoc
@@ -0,0 +1,40 @@
+Git v2.4.1 Release Notes
+========================
+
+Fixes since v2.4
+----------------
+
+ * The usual "git diff" when seeing a file turning into a directory
+ showed a patchset to remove the file and create all files in the
+ directory, but "git diff --no-index" simply refused to work. Also,
+ when asked to compare a file and a directory, imitate POSIX "diff"
+ and compare the file with the file with the same name in the
+ directory, instead of refusing to run.
+
+ * The default $HOME/.gitconfig file created upon "git config --global"
+ that edits it had incorrectly spelled user.name and user.email
+ entries in it.
+
+ * "git commit --date=now" or anything that relies on approxidate lost
+ the daylight-saving-time offset.
+
+ * "git cat-file bl $blob" failed to barf even though there is no
+ object type that is "bl".
+
+ * Teach the codepaths that read .gitignore and .gitattributes files
+ that these files encoded in UTF-8 may have UTF-8 BOM marker at the
+ beginning; this makes it in line with what we do for configuration
+ files already.
+
+ * Access to objects in repositories that borrow from another one on a
+ slow NFS server unnecessarily got more expensive due to recent code
+ becoming more cautious in a naive way not to lose objects to pruning.
+
+ * We avoid setting core.worktree when the repository location is the
+ ".git" directory directly at the top level of the working tree, but
+ the code misdetected the case in which the working tree is at the
+ root level of the filesystem (which arguably is a silly thing to
+ do, but still valid).
+
+Also contains typofixes, documentation updates and trivial code
+clean-ups.
diff --git a/RelNotes/2.4.10.adoc b/RelNotes/2.4.10.adoc
new file mode 100644
index 0000000..702d8d4
--- /dev/null
+++ b/RelNotes/2.4.10.adoc
@@ -0,0 +1,18 @@
+Git v2.4.10 Release Notes
+=========================
+
+Fixes since v2.4.9
+------------------
+
+ * xdiff code we use to generate diffs is not prepared to handle
+ extremely large files. It uses "int" in many places, which can
+ overflow if we have a very large number of lines or even bytes in
+ our input files, for example. Cap the input size to somewhere
+ around 1GB for now.
+
+ * Some protocols (like git-remote-ext) can execute arbitrary code
+ found in the URL. The URLs that submodules use may come from
+ arbitrary sources (e.g., .gitmodules files in a remote
+ repository), and can hurt those who blindly enable recursive
+ fetch. Restrict the allowed protocols to well known and safe
+ ones.
diff --git a/RelNotes/2.4.11.adoc b/RelNotes/2.4.11.adoc
new file mode 100644
index 0000000..7233602
--- /dev/null
+++ b/RelNotes/2.4.11.adoc
@@ -0,0 +1,11 @@
+Git v2.4.11 Release Notes
+=========================
+
+Fixes since v2.4.10
+-------------------
+
+ * Bugfix patches were backported from the 'master' front to plug heap
+ corruption holes, to catch integer overflow in the computation of
+ pathname lengths, and to get rid of the name_path API. Both of
+ these would have resulted in writing over an under-allocated buffer
+ when formulating pathnames while tree traversal.
diff --git a/RelNotes/2.4.12.adoc b/RelNotes/2.4.12.adoc
new file mode 100644
index 0000000..7d15f94
--- /dev/null
+++ b/RelNotes/2.4.12.adoc
@@ -0,0 +1,12 @@
+Git v2.4.12 Release Notes
+=========================
+
+Fixes since v2.4.11
+-------------------
+
+ * "git-shell" rejects a request to serve a repository whose name
+ begins with a dash, which makes it no longer possible to get it
+ confused into spawning service programs like "git-upload-pack" with
+ an option like "--help", which in turn would spawn an interactive
+ pager, instead of working with the repository user asked to access
+ (i.e. the one whose name is "--help").
diff --git a/RelNotes/2.4.2.adoc b/RelNotes/2.4.2.adoc
new file mode 100644
index 0000000..250cdc4
--- /dev/null
+++ b/RelNotes/2.4.2.adoc
@@ -0,0 +1,45 @@
+Git v2.4.2 Release Notes
+========================
+
+Fixes since v2.4.1
+------------------
+
+ * "git rev-list --objects $old --not --all" to see if everything that
+ is reachable from $old is already connected to the existing refs
+ was very inefficient.
+
+ * "hash-object --literally" introduced in v2.2 was not prepared to
+ take a really long object type name.
+
+ * "git rebase --quiet" was not quite quiet when there is nothing to
+ do.
+
+ * The completion for "log --decorate=" parameter value was incorrect.
+
+ * "filter-branch" corrupted commit log message that ends with an
+ incomplete line on platforms with some "sed" implementations that
+ munge such a line. Work it around by avoiding to use "sed".
+
+ * "git daemon" fails to build from the source under NO_IPV6
+ configuration (regression in 2.4).
+
+ * "git stash pop/apply" forgot to make sure that not just the working
+ tree is clean but also the index is clean. The latter is important
+ as a stash application can conflict and the index will be used for
+ conflict resolution.
+
+ * We have prepended $GIT_EXEC_PATH and the path "git" is installed in
+ (typically "/usr/bin") to $PATH when invoking subprograms and hooks
+ for almost eternity, but the original use case the latter tried to
+ support was semi-bogus (i.e. install git to /opt/foo/git and run it
+ without having /opt/foo on $PATH), and more importantly it has
+ become less and less relevant as Git grew more mainstream (i.e. the
+ users would _want_ to have it on their $PATH). Stop prepending the
+ path in which "git" is installed to users' $PATH, as that would
+ interfere the command search order people depend on (e.g. they may
+ not like versions of programs that are unrelated to Git in /usr/bin
+ and want to override them by having different ones in /usr/local/bin
+ and have the latter directory earlier in their $PATH).
+
+Also contains typofixes, documentation updates and trivial code
+clean-ups.
diff --git a/RelNotes/2.4.3.adoc b/RelNotes/2.4.3.adoc
new file mode 100644
index 0000000..422e930
--- /dev/null
+++ b/RelNotes/2.4.3.adoc
@@ -0,0 +1,76 @@
+Git v2.4.3 Release Notes
+========================
+
+Fixes since v2.4.3
+------------------
+
+ * Error messages from "git branch" called remote-tracking branches as
+ "remote branches".
+
+ * "git rerere forget" in a repository without rerere enabled gave a
+ cryptic error message; it should be a silent no-op instead.
+
+ * "git pull --log" and "git pull --no-log" worked as expected, but
+ "git pull --log=20" did not.
+
+ * The pull.ff configuration was supposed to override the merge.ff
+ configuration, but it didn't.
+
+ * The code to read pack-bitmap wanted to allocate a few hundred
+ pointers to a structure, but by mistake allocated and leaked memory
+ enough to hold that many actual structures. Correct the allocation
+ size and also have it on stack, as it is small enough.
+
+ * Various documentation mark-up fixes to make the output more
+ consistent in general and also make AsciiDoctor (an alternative
+ formatter) happier.
+
+ * "git bundle verify" did not diagnose extra parameters on the
+ command line.
+
+ * Multi-ref transaction support we merged a few releases ago
+ unnecessarily kept many file descriptors open, risking to fail with
+ resource exhaustion.
+
+ * The ref API did not handle cases where 'refs/heads/xyzzy/frotz' is
+ removed at the same time as 'refs/heads/xyzzy' is added (or vice
+ versa) very well.
+
+ * The "log --decorate" enhancement in Git 2.4 that shows the commit
+ at the tip of the current branch e.g. "HEAD -> master", did not
+ work with --decorate=full.
+
+ * There was a commented-out (instead of being marked to expect
+ failure) test that documented a breakage that was fixed since the
+ test was written; turn it into a proper test.
+
+ * core.excludesfile (defaulting to $XDG_HOME/git/ignore) is supposed
+ to be overridden by repository-specific .git/info/exclude file, but
+ the order was swapped from the beginning. This belatedly fixes it.
+
+ * The connection initiation code for "ssh" transport tried to absorb
+ differences between the stock "ssh" and Putty-supplied "plink" and
+ its derivatives, but the logic to tell that we are using "plink"
+ variants were too loose and falsely triggered when "plink" appeared
+ anywhere in the path (e.g. "/home/me/bin/uplink/ssh").
+
+ * "git rebase -i" moved the "current" command from "todo" to "done" a
+ bit too prematurely, losing a step when a "pick" did not even start.
+
+ * "git add -e" did not allow the user to abort the operation by
+ killing the editor.
+
+ * Git 2.4 broke setting verbosity and progress levels on "git clone"
+ with native transports.
+
+ * Some time ago, "git blame" (incorrectly) lost the convert_to_git()
+ call when synthesizing a fake "tip" commit that represents the
+ state in the working tree, which broke folks who record the history
+ with LF line ending to make their project portable across
+ platforms while terminating lines in their working tree files with
+ CRLF for their platform.
+
+ * Code clean-up for xdg configuration path support.
+
+Also contains typofixes, documentation updates and trivial code
+clean-ups.
diff --git a/RelNotes/2.4.4.adoc b/RelNotes/2.4.4.adoc
new file mode 100644
index 0000000..f1ccd00
--- /dev/null
+++ b/RelNotes/2.4.4.adoc
@@ -0,0 +1,35 @@
+Git v2.4.4 Release Notes
+========================
+
+Fixes since v2.4.3
+------------------
+
+ * l10n updates for German.
+
+ * An earlier leakfix to bitmap testing code was incomplete.
+
+ * "git clean pathspec..." tried to lstat(2) and complain even for
+ paths outside the given pathspec.
+
+ * Communication between the HTTP server and http_backend process can
+ lead to a dead-lock when relaying a large ref negotiation request.
+ Diagnose the situation better, and mitigate it by reading such a
+ request first into core (to a reasonable limit).
+
+ * The clean/smudge interface did not work well when filtering an
+ empty contents (failed and then passed the empty input through).
+ It can be argued that a filter that produces anything but empty for
+ an empty input is nonsense, but if the user wants to do strange
+ things, then why not?
+
+ * Make "git stash something --help" error out, so that users can
+ safely say "git stash drop --help".
+
+ * Clarify that "log --raw" and "log --format=raw" are unrelated
+ concepts.
+
+ * Catch a programmer mistake to feed a pointer not an array to
+ ARRAY_SIZE() macro, by using a couple of GCC extensions.
+
+Also contains typofixes, documentation updates and trivial code
+clean-ups.
diff --git a/RelNotes/2.4.5.adoc b/RelNotes/2.4.5.adoc
new file mode 100644
index 0000000..568297c
--- /dev/null
+++ b/RelNotes/2.4.5.adoc
@@ -0,0 +1,28 @@
+Git v2.4.5 Release Notes
+========================
+
+Fixes since v2.4.4
+------------------
+
+ * The setup code used to die when core.bare and core.worktree are set
+ inconsistently, even for commands that do not need working tree.
+
+ * There was a dead code that used to handle "git pull --tags" and
+ show special-cased error message, which was made irrelevant when
+ the semantics of the option changed back in Git 1.9 days.
+
+ * "color.diff.plain" was a misnomer; give it 'color.diff.context' as
+ a more logical synonym.
+
+ * The configuration reader/writer uses mmap(2) interface to access
+ the files; when we find a directory, it barfed with "Out of memory?".
+
+ * Recent "git prune" traverses young unreachable objects to safekeep
+ old objects in the reachability chain from them, which sometimes
+ showed unnecessary error messages that are alarming.
+
+ * "git rebase -i" fired post-rewrite hook when it shouldn't (namely,
+ when it was told to stop sequencing with 'exec' insn).
+
+Also contains typofixes, documentation updates and trivial code
+clean-ups.
diff --git a/RelNotes/2.4.6.adoc b/RelNotes/2.4.6.adoc
new file mode 100644
index 0000000..b53f353
--- /dev/null
+++ b/RelNotes/2.4.6.adoc
@@ -0,0 +1,23 @@
+Git v2.4.6 Release Notes
+========================
+
+Fixes since v2.4.5
+------------------
+
+ * "git fetch --depth=<depth>" and "git clone --depth=<depth>" issued
+ a shallow transfer request even to an upload-pack that does not
+ support the capability.
+
+ * "git fsck" used to ignore missing or invalid objects recorded in reflog.
+
+ * The tcsh completion writes a bash scriptlet but that would have
+ failed for users with noclobber set.
+
+ * Recent Mac OS X updates breaks the logic to detect that the machine
+ is on the AC power in the sample pre-auto-gc script.
+
+ * "git format-patch --ignore-if-upstream A..B" did not like to be fed
+ tags as boundary commits.
+
+Also contains typofixes, documentation updates and trivial code
+clean-ups.
diff --git a/RelNotes/2.4.7.adoc b/RelNotes/2.4.7.adoc
new file mode 100644
index 0000000..b3ac412
--- /dev/null
+++ b/RelNotes/2.4.7.adoc
@@ -0,0 +1,53 @@
+Git v2.4.7 Release Notes
+========================
+
+Fixes since v2.4.6
+------------------
+
+ * A minor regression to "git fsck" in v2.2 era was fixed; it
+ complained about a body-less tag object when it lacked a
+ separator empty line after its header to separate it with a
+ non-existent body.
+
+ * We used to ask libCURL to use the most secure authentication method
+ available when talking to an HTTP proxy only when we were told to
+ talk to one via configuration variables. We now ask libCURL to
+ always use the most secure authentication method, because the user
+ can tell libCURL to use an HTTP proxy via an environment variable
+ without using configuration variables.
+
+ * When you say "!<ENTER>" while running say "git log", you'd confuse
+ yourself in the resulting shell, that may look as if you took
+ control back to the original shell you spawned "git log" from but
+ that isn't what is happening. To that new shell, we leaked
+ GIT_PAGER_IN_USE environment variable that was meant as a local
+ communication between the original "Git" and subprocesses that was
+ spawned by it after we launched the pager, which caused many
+ "interesting" things to happen, e.g. "git diff | cat" still paints
+ its output in color by default.
+
+ Stop leaking that environment variable to the pager's half of the
+ fork; we only need it on "Git" side when we spawn the pager.
+
+ * Avoid possible ssize_t to int truncation.
+
+ * "git config" failed to update the configuration file when the
+ underlying filesystem is incapable of renaming a file that is still
+ open.
+
+ * A minor bugfix when pack bitmap is used with "rev-list --count".
+
+ * An ancient test framework enhancement to allow color was not
+ entirely correct; this makes it work even when tput needs to read
+ from the ~/.terminfo under the user's real HOME directory.
+
+ * Fix a small bug in our use of umask() return value.
+
+ * "git rebase" did not exit with failure when format-patch it invoked
+ failed for whatever reason.
+
+ * Disable "have we lost a race with competing repack?" check while
+ receiving a huge object transfer that runs index-pack.
+
+Also contains typofixes, documentation updates and trivial code
+clean-ups.
diff --git a/RelNotes/2.4.8.adoc b/RelNotes/2.4.8.adoc
new file mode 100644
index 0000000..ad946b2
--- /dev/null
+++ b/RelNotes/2.4.8.adoc
@@ -0,0 +1,21 @@
+Git v2.4.8 Release Notes
+========================
+
+Fixes since v2.4.7
+------------------
+
+ * Abandoning an already applied change in "git rebase -i" with
+ "--continue" left CHERRY_PICK_HEAD and confused later steps.
+
+ * Various fixes around "git am" that applies a patch to a history
+ that is not there yet.
+
+ * "git for-each-ref" reported "missing object" for 0{40} when it
+ encounters a broken ref. The lack of object whose name is 0{40} is
+ not the problem; the ref being broken is.
+
+ * "git commit --cleanup=scissors" was not careful enough to protect
+ against getting fooled by a line that looked like scissors.
+
+Also contains typofixes, documentation updates and trivial code
+clean-ups.
diff --git a/RelNotes/2.4.9.adoc b/RelNotes/2.4.9.adoc
new file mode 100644
index 0000000..09af9dd
--- /dev/null
+++ b/RelNotes/2.4.9.adoc
@@ -0,0 +1,9 @@
+Git v2.4.9 Release Notes
+========================
+
+Fixes since v2.4.9
+------------------
+
+ * A handful of codepaths that used to use fixed-sized arrays to hold
+ pathnames have been corrected to use strbuf and other mechanisms to
+ allow longer pathnames without fearing overflows.
diff --git a/RelNotes/2.40.0.adoc b/RelNotes/2.40.0.adoc
new file mode 100644
index 0000000..3ea445b
--- /dev/null
+++ b/RelNotes/2.40.0.adoc
@@ -0,0 +1,320 @@
+Git v2.40 Release Notes
+=======================
+
+UI, Workflows & Features
+
+ * "merge-tree" learns a new `--merge-base` option.
+
+ * "git jump" (in contrib/) learned to present the "quickfix list" to
+ its standard output (instead of letting it consumed by the editor
+ it invokes), and learned to also drive emacs/emacsclient.
+
+ * "git var UNKNOWN_VARIABLE" and "git var VARIABLE" with the variable
+ given an empty value used to behave identically. Now the latter
+ just gives an empty output, while the former still gives an error
+ message.
+
+ * Introduce a case insensitive mode to the Bash completion helpers.
+
+ * The advice message given by "git status" when it takes long time to
+ enumerate untracked paths has been updated.
+
+ * Just like "git var GIT_EDITOR" abstracts the complex logic to
+ choose which editor gets used behind it, "git var" now give support
+ to GIT_SEQUENCE_EDITOR.
+
+ * "git format-patch" learned to honor format.mboxrd even when sending
+ patches to the standard output stream,
+
+ * 'cat-file' gains mailmap support for its '--batch-check' and '-s'
+ options.
+
+ * Conditionally skip the pre-applypatch and applypatch-msg hooks when
+ applying patches with 'git am'.
+
+ * Introduce an optional configuration to allow the trailing hash that
+ protects the index file from bit flipping.
+
+ * "git check-attr" learned to take an optional tree-ish to read the
+ .gitattributes file from.
+
+ * "scalar" learned to give progress bar.
+
+ * "grep -P" learned to use Unicode Character Property to grok
+ character classes when processing \b and \w etc.
+
+ * "git rebase" often ignored incompatible options instead of
+ complaining, which has been corrected.
+
+ * "scalar" warns but continues when its periodic maintenance
+ feature cannot be enabled.
+
+ * The bundle-URI subsystem adds support for creation-token heuristics
+ to help incremental fetches.
+
+ * Userdiff regexp update for Java language.
+
+ * "git fetch --jobs=0" used to hit a BUG(), which has been corrected
+ to use the available CPUs.
+
+ * An invalid label or ref in the "rebase -i" todo file used to
+ trigger an runtime error. SUch an error is now diagnosed while the
+ todo file is parsed.
+
+ * The "diff" drivers specified by the "diff" attribute attached to
+ paths can now specify which algorithm (e.g. histogram) to use.
+
+ * "git range-diff" learned --abbrev=<num> option.
+
+ * "git archive HEAD^{tree}" records the paths with the current
+ timestamp in the archive, making it harder to obtain a stable
+ output. The command learned the --mtime option to specify an
+ arbitrary timestamp (e.g. --mtime="@0 +0000" for the epoch).
+
+ * The credential subsystem learned that a password may have an
+ explicit expiration.
+
+ * The format.attach configuration variable lacked a way to override a
+ value defined in a lower-priority configuration file (e.g. the
+ system one) by redefining it in a higher-priority configuration
+ file. Now, setting format.attach to an empty string means show the
+ patch inline in the e-mail message, without using MIME attachment.
+
+ This is a backward incompatible change.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * `git bisect` becomes a builtin.
+
+ * The pack-bitmap machinery is taught to log the paths of redundant
+ bitmap(s) to trace2 instead of stderr.
+
+ * Use the SHA1DC implementation on macOS, just like other platforms,
+ by default.
+
+ * Even in a repository with promisor remote, it is useless to
+ attempt to lazily attempt fetching an object that is expected to be
+ commit, because no "filter" mode omits commit objects. Take
+ advantage of this assumption to fail fast on errors.
+
+ * Stop using "git --super-prefix" and narrow the scope of its use to
+ the submodule--helper.
+
+ * Stop running win+VS build by default.
+
+ * CI updates. We probably want a clean-up to move the long shell
+ script embedded in yaml file into a separate file, but that can
+ come later.
+
+ * Use `git diff --no-index` as a test_cmp on Windows.
+
+ We'd probably need to revisit "do we really want to, and have to,
+ lose CRLF vs LF?" later, at which time we may be able to further
+ clean this up by replacing "git diff --no-index" with "diff -u".
+
+ * Avoid unnecessary builds in CI, with settings configured in
+ ci-config.
+
+ * Plug leaks in sequencer subsystem and its users.
+
+ * In-tree .gitattributes update to match the way we recommend our
+ users to mark a file as text.
+ (merge 1f34e0cd3d po/attributes-text later to maint).
+
+ * Finally retire the scripted "git add -p/-i" implementation and have
+ everybody use the one reimplemented in C.
+
+
+Fixes since v2.39
+-----------------
+
+ * Various leak fixes.
+
+ * Fix a bug where `pack-objects` would not respect multiple `--filter`
+ arguments when invoked directly.
+ (merge d4f7036887 rs/multi-filter-args later to maint).
+
+ * Make fsmonitor more robust to avoid the flakiness seen in t7527.
+ (merge 6692d45477 jh/t7527-unflake-by-forcing-cookie later to maint).
+
+ * Stop using deprecated macOS API in fsmonitor.
+ (merge b0226007f0 jh/fsmonitor-darwin-modernize later to maint).
+
+ * Redefining system functions for a few functions did not follow our
+ usual "implement git_foo() and #define foo(args) git_foo(args)"
+ pattern, which has broken build for some folks.
+
+ * The way the diff machinery prepares the options array for the
+ parse_options API has been refactored to avoid resource leaks.
+ (merge 189e97bc4b rs/diff-parseopts later to maint).
+
+ * Correct pthread API usage.
+ (merge 786e67611d sx/pthread-error-check-fix later to maint).
+
+ * The code to auto-correct a misspelt subcommand unnecessarily called
+ into git_default_config() from the early config codepath, which was
+ a no-no. This has bee corrected.
+ (merge 0918d08887 sg/help-autocorrect-config-fix later to maint).
+
+ * "git http-fetch" (which is rarely used) forgot to identify itself
+ in the trace2 output.
+ (merge 7abb43cbc8 jt/http-fetch-trace2-report-name later to maint).
+
+ * The output from "git diff --stat" on an unmerged path lost the
+ terminating LF in Git 2.39, which has been corrected.
+ (merge 209d9cb011 pg/diff-stat-unmerged-regression-fix later to maint).
+
+ * "git pull -v --recurse-submodules" attempted to pass "-v" down to
+ underlying "git submodule update", which did not understand the
+ request and barfed, which has been corrected.
+ (merge 6f65f84766 ss/pull-v-recurse-fix later to maint).
+
+ * When given a pattern that matches an empty string at the end of a
+ line, the code to parse the "git diff" line-ranges fell into an
+ infinite loop, which has been corrected.
+
+ * Fix the sequence to fsync $GIT_DIR/packed-refs file that forgot to
+ flush its output to the disk..
+
+ * Fix to a small regression in 2.38 days.
+
+ * "git diff --relative" did not mix well with "git diff --ext-diff",
+ which has been corrected.
+
+ * The logic to see if we are using the "cone" mode by checking the
+ sparsity patterns has been tightened to avoid mistaking a pattern
+ that names a single file as specifying a cone.
+
+ * Deal with a few deprecation warning from cURL library.
+
+ * Doc update for environment variables set when hooks are invoked.
+
+ * Document ORIG_HEAD a bit more.
+
+ * "git ls-tree --format='%(path) %(path)' $tree $path" showed the
+ path three times, which has been corrected.
+
+ * Remove "git env--helper" and demote it to a test-tool subcommand.
+ (merge 4a1baacd46 ab/test-env-helper later to maint).
+
+ * Newer regex library macOS stopped enabling GNU-like enhanced BRE,
+ where '\(A\|B\)' works as alternation, unless explicitly asked with
+ the REG_ENHANCED flag. "git grep" now can be compiled to do so, to
+ retain the old behaviour.
+
+ * Pthread emulation on Win32 leaked thread handle when a thread is
+ joined.
+ (merge 238a9dfe86 sk/win32-close-handle-upon-pthread-join later to maint).
+
+ * "git send-email -v 3" used to be expanded to "git send-email
+ --validate 3" when the user meant to pass them down to
+ "format-patch", which has been corrected.
+ (merge 8774aa56ad km/send-email-with-v-reroll-count later to maint).
+
+ * Document that "branch -f <branch>" disables only the safety to
+ avoid recreating an existing branch.
+
+ * "git fetch <group>", when "<group>" of remotes lists the same
+ remote twice, unnecessarily failed when parallel fetching was
+ enabled, which has been corrected.
+ (merge 06a668cb90 cw/fetch-remote-group-with-duplication later to maint).
+
+ * Clarify how "checkout -b/-B" and "git branch [-f]" are similar but
+ different in the documentation.
+
+ * "git hash-object" now checks that the resulting object is well
+ formed with the same code as "git fsck".
+ (merge 8e4309038f jk/hash-object-fsck later to maint).
+
+ * Improve the error message given when private key is not loaded in
+ the ssh agent in the codepath to sign with an ssh key.
+ (merge dce7b31126 as/ssh-signing-improve-key-missing-error later to maint).
+
+ * Adjust "git request-pull" to strip embedded signature from signed
+ tags to notice non-PGP signatures.
+ (merge a9cad02538 gm/request-pull-with-non-pgp-signed-tags later to maint).
+
+ * Remove support for MSys, which now lags way behind MSys2.
+ (merge 2987407f3c hj/remove-msys-support later to maint).
+
+ * Fix use of CreateThread() API call made early in the windows
+ start-up code.
+ (merge 592bcab61b sk/winansi-createthread-fix later to maint).
+
+ * "git pack-objects" learned to release delta-island bitmap data when
+ it is done using it, saving peak heap memory usage.
+ (merge 647982bb71 ew/free-island-marks later to maint).
+
+ * In an environment where dynamically generated code is prohibited to
+ run (e.g. SELinux), failure to JIT pcre patterns is expected. Fall
+ back to interpreted execution in such a case.
+ (merge 50b6ad55b0 cb/grep-fallback-failing-jit later to maint).
+
+ * "git name-rev" heuristics update.
+ (merge b2182a8730 en/name-rev-make-taggerdate-much-less-important later to maint).
+
+ * Remove more remaining uses of macros that relies on the_index
+ singleton instance without explicitly spelling it out.
+
+ * Remove unnecessary explicit sizing of strbuf.
+ (merge 93ea118bed rs/cache-tree-strbuf-growth-fix later to maint).
+
+ * Doc update.
+ (merge d9ec3b0dc0 jk/doc-ls-remote-matching later to maint).
+
+ * Error messages given upon a signature verification failure used to
+ discard the errors from underlying gpg program, which has been
+ corrected.
+ (merge ad6b320756 js/gpg-errors later to maint).
+
+ * Update --date=default documentation.
+ (merge 9deef088ae rd/doc-default-date-format later to maint).
+
+ * A test helper had a single write(2) of 256kB, which was too big for
+ some platforms (e.g. NonStop), which has been corrected by using
+ xwrite() wrapper appropriately.
+ (merge 58eab6ff13 jc/genzeros-avoid-raw-write later to maint).
+
+ * sscanf(3) used in "git symbolic-ref --short" implementation found
+ to be not working reliably on macOS in UTF-8 locales. Rewrite the
+ code to avoid sscanf() altogether to work it around.
+ (merge 613bef56b8 jk/shorten-unambiguous-ref-wo-sscanf later to maint).
+
+ * Various fix-ups on HTTP tests.
+ (merge 8f2146dbf1 jk/http-test-fixes later to maint).
+
+ * Fixes to code that parses the todo file used in "rebase -i".
+ (merge 666b6e1135 pw/rebase-i-parse-fix later to maint).
+
+ * Test library clean-up.
+ (merge c600a91c94 ar/test-lib-remove-stale-comment later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge 4eb1ccecd4 dh/mingw-ownership-check-typofix later to maint).
+ (merge f95526419b ar/typofix-gitattributes-doc later to maint).
+ (merge 27875aeec9 km/doc-branch-start-point later to maint).
+ (merge 35c194dc57 es/t1509-root-fixes later to maint).
+ (merge 7b341645e3 pw/ci-print-failure-name-fix later to maint).
+ (merge bcb71d45bf jx/t1301-updates later to maint).
+ (merge ebdc46c242 jc/doc-diff-patch.txt later to maint).
+ (merge a87a20cbb4 ar/test-cleanup later to maint).
+ (merge f5156f1885 ar/bisect-doc-update later to maint).
+ (merge fca2d86c97 jk/interop-error later to maint).
+ (merge cf4936ed74 tl/ls-tree-code-clean-up later to maint).
+ (merge dcb47e52b0 en/t6426-todo-cleanup later to maint).
+ (merge 5b8db44bdd jc/format-patch-v-unleak later to maint).
+ (merge 590b636737 jk/hash-object-literally-fd-leak later to maint).
+ (merge 5458ba0a4d tb/t0003-invoke-dd-more-portably later to maint).
+ (merge 70661d288b ar/markup-em-dash later to maint).
+ (merge e750951e74 en/ls-files-doc-update later to maint).
+ (merge 4f542975d1 mh/doc-credential-cache-only-in-core later to maint).
+ (merge 3a2ebaebc7 gc/index-format-doc later to maint).
+ (merge b08edf709d jk/httpd-test-updates later to maint).
+ (merge d85e9448dd wl/new-command-doc later to maint).
+ (merge d912a603ed kf/t5000-modernise later to maint).
+ (merge e65b868d07 rs/size-t-fixes later to maint).
+ (merge 3eb1e1ca9a ab/config-h-remove-unused later to maint).
+ (merge d390e08076 cw/doc-pushurl-vs-url later to maint).
+ (merge 567342fc77 rs/ctype-test later to maint).
+ (merge d35d8f2e7a ap/t2015-style-update later to maint).
diff --git a/RelNotes/2.40.1.adoc b/RelNotes/2.40.1.adoc
new file mode 100644
index 0000000..e72f6b1
--- /dev/null
+++ b/RelNotes/2.40.1.adoc
@@ -0,0 +1,8 @@
+Git v2.40.1 Release Notes
+=========================
+
+This release merges up the fix that appears in v2.30.9, v2.31.8,
+v2.32.7, v2.33.8, v2.34.8, v2.35.8, v2.36.6, v2.37.7, v2.38.5
+and v2.39.3 to address the security issues CVE-2023-25652,
+CVE-2023-25815, and CVE-2023-29007; see the release notes for these
+versions for details.
diff --git a/RelNotes/2.40.2.adoc b/RelNotes/2.40.2.adoc
new file mode 100644
index 0000000..646a2cc
--- /dev/null
+++ b/RelNotes/2.40.2.adoc
@@ -0,0 +1,7 @@
+Git v2.40.2 Release Notes
+=========================
+
+This release merges up the fix that appears in v2.39.4 to address
+the security issues CVE-2024-32002, CVE-2024-32004, CVE-2024-32020,
+CVE-2024-32021 and CVE-2024-32465; see the release notes for that
+version for details.
diff --git a/RelNotes/2.40.3.adoc b/RelNotes/2.40.3.adoc
new file mode 100644
index 0000000..6ca088e
--- /dev/null
+++ b/RelNotes/2.40.3.adoc
@@ -0,0 +1,26 @@
+Git v2.40.3 Release Notes
+=========================
+
+In preparing security fixes for four CVEs, we made overly aggressive
+"defense in depth" changes that broke legitimate use cases like 'git
+lfs' and 'git annex.' This release is to revert these misguided, if
+well-intentioned, changes that were shipped in 2.40.2 and were not
+direct security fixes.
+
+Jeff King (5):
+ send-email: drop FakeTerm hack
+ send-email: avoid creating more than one Term::ReadLine object
+ ci: drop mention of BREW_INSTALL_PACKAGES variable
+ ci: avoid bare "gcc" for osx-gcc job
+ ci: stop installing "gcc-13" for osx-gcc
+
+Johannes Schindelin (6):
+ hook: plug a new memory leak
+ init: use the correct path of the templates directory again
+ Revert "core.hooksPath: add some protection while cloning"
+ tests: verify that `clone -c core.hooksPath=/dev/null` works again
+ clone: drop the protections where hooks aren't run
+ Revert "Add a helper function to compare file contents"
+
+Junio C Hamano (1):
+ Revert "fsck: warn about symlink pointing inside a gitdir"
diff --git a/RelNotes/2.40.4.adoc b/RelNotes/2.40.4.adoc
new file mode 100644
index 0000000..0ff29f3
--- /dev/null
+++ b/RelNotes/2.40.4.adoc
@@ -0,0 +1,5 @@
+Git v2.40.4 Release Notes
+=========================
+
+This release lets Git refuse to accept URLs that contain control
+sequences. This addresses CVE-2024-50349 and CVE-2024-52006.
diff --git a/RelNotes/2.41.0.adoc b/RelNotes/2.41.0.adoc
new file mode 100644
index 0000000..8a9e170
--- /dev/null
+++ b/RelNotes/2.41.0.adoc
@@ -0,0 +1,399 @@
+Git v2.41 Release Notes
+=======================
+
+UI, Workflows & Features
+
+ * Allow information carried on the WWW-Authenticate header to be
+ passed to the credential helpers.
+
+ * A new "fetch.hideRefs" option can be used to exclude specified refs
+ from "rev-list --objects --stdin --not --all" traversal for
+ checking object connectivity, most useful when there are many
+ unrelated histories in a single repository.
+
+ * "git push" has been taught to allow deletion of refs with one-level
+ names to help repairing a repository who acquired such a ref by
+ mistake. In general, we don't encourage use of such a ref, and
+ creation or update to such a ref is rejected as before.
+
+ * Allow "git bisect reset" to check out the original branch when the
+ branch is already checked out in a different worktree linked to the
+ same repository.
+
+ * A few subcommands have been taught to stop users from working on a
+ branch that is being used in another worktree linked to the same
+ repository.
+
+ * "git format-patch" learned to write a log-message only output file
+ for empty commits.
+
+ * "git format-patch" honors the src/dst prefixes set to nonstandard
+ values with configuration variables like "diff.noprefix", causing
+ receiving end of the patch that expects the standard -p1 format to
+ break. "format-patch" has been taught to ignore end-user configuration
+ and always use the standard prefixes.
+
+ This is a backward compatibility breaking change.
+
+ * Lift the limitation that colored prompts can only be used with
+ PROMPT_COMMAND mode.
+
+ * "git blame --contents=<file> <rev> -- <path>" used to be forbidden,
+ but now it finds the origins of lines starting at <file> contents
+ through the history that leads to <rev>.
+
+ * "git pack-redundant" gave a warning when run, as the command has
+ outlived its usefulness long ago and is nominated for future
+ removal. Now we escalate to give an error.
+
+ * "git clone" from an empty repository learned to propagate the
+ choice of the hash algorithm from the source repository to the
+ newly created repository over any one of the v0/v1/v2 protocol.
+
+ * "git mergetool" and "git difftool" learns a new configuration
+ guiDefault to optionally favor configured guitool over non-gui-tool
+ automatically when $DISPLAY is set.
+
+ * "git branch -d origin/master" would say "no such branch", but it is
+ likely a missed "-r" if refs/remotes/origin/master exists. The
+ command has been taught to give such a hint in its error message.
+
+ * Clean-up of the code path that deals with merge strategy option
+ handling in "git rebase".
+
+ * "git clone --local" stops copying from an original repository that
+ has symbolic links inside its $GIT_DIR; an error message when that
+ happens has been updated.
+
+ * The "--format=..." option of "git for-each-ref", "git branch", and
+ "git tag" commands learn "--omit-empty" to hide refs whose
+ formatting results in an empty string from the output.
+
+ * The sendemail-validate validate hook learned to pass the total
+ number of input files and where in the sequence each invocation is
+ via environment variables.
+
+ * When "gc" needs to retain unreachable objects, packing them into
+ cruft packs (instead of exploding them into loose object files) has
+ been offered as a more efficient option for some time. Now the use
+ of cruft packs has been made the default and no longer considered
+ an experimental feature.
+
+ * The output given by "git blame" that attributes a line to contents
+ taken from the file specified by the "--contents" option shows it
+ differently from a line attributed to the working tree file.
+
+ * "git send-email" learned to give the e-mail headers to the validate
+ hook by passing an extra argument from the command line.
+
+ * The credential subsystem learns to help OAuth framework.
+
+ * The titles of manual pages used to be chomped at an unreasonably
+ short limit, which has been removed.
+
+ * Error messages given when working on an unborn branch that is
+ checked out in another worktree have been improved.
+
+ * The documentation was misleading about the interaction between
+ GIT_DEFAULT_HASH and "git clone", which has been clarified to
+ stress that the variable is to be ignored by the command.
+
+ * "git send-email" learned "--header-cmd=<cmd>" that can inject
+ arbitrary e-mail header lines to the outgoing messages.
+
+ * "git fsck" learned to detect bit-flip breakages in the reachability
+ bitmap files.
+
+ * The "--stdin" option of "git name-rev" has been replaced with
+ the "--annotate-stdin" option more than a year ago. We stop
+ advertising it in the "git name-rev -h" output.
+
+ * "git push --all" gained an alias "git push --branches".
+
+ * "git fetch" learned the "--porcelain" option that emits what it did
+ in a machine-parseable format.
+
+ * "git --attr-source=<tree> cmd $args" is a new way to have any
+ command to read attributes not from the working tree but from the
+ given tree object.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * Code clean-up to clarify directory traversal API.
+
+ * Code clean-up to clarify the rule that "git-compat-util.h" must be
+ the first to be included.
+
+ * More work towards -Wunused.
+
+ * Instead of forcing each command to choose to honor GPG related
+ configuration variables, make the subsystem lazily initialize
+ itself.
+
+ * Remove workaround for ancient versions of DocBook to make it work
+ correctly with groff, which has not been necessary since docbook
+ 1.76 from 2010.
+
+ * Code clean-up to include and/or uninclude parse-options.h file as
+ needed.
+
+ * The code path that reports what "git fetch" did to each ref has
+ been cleaned up.
+
+ * Assorted config API updates.
+
+ * A few configuration variables to tell the cURL library that
+ different types of ssl-cert and ssl-key are in use have been added.
+
+ * Split key function and data structure definitions out of cache.h to
+ new header files and adjust the users.
+
+ * "git fetch --all" does not have to download and handle the same
+ bundleURI over and over, which has been corrected.
+
+ * "git sparse-checkout" command learns a debugging aid for the sparse
+ rule definitions.
+
+ * "git write-tree" learns to work better with sparse-index.
+
+ * The on-disk reverse index that allows mapping from the pack offset
+ to the object name for the object stored at the offset has been
+ enabled by default.
+
+ * "git fsck" learned to validate the on-disk pack reverse index files.
+
+ * strtok() and strtok_r() are banned in this codebase.
+
+ * The detect-compilers script to help auto-tweaking the build system
+ had trouble working with compilers whose version number has extra
+ suffixes. The script has been taught that certain suffixes (like
+ "-win32" in "gcc 10-win32") can be safely stripped as they share
+ the same features and bugs with the version without the suffix.
+
+ * ctype tests have been taught to test EOF, too.
+
+ * The implementation of credential helpers used fgets() over fixed
+ size buffers to read protocol messages, causing the remainder of
+ the folded long line to trigger unexpected behaviour, which has
+ been corrected.
+
+ * The implementation of the default "negotiator", used to find common
+ ancestor over the network for object tranfer, used to be recursive;
+ it was updated to be iterative to conserve stackspace usage.
+
+ * Our custom callout formatter is no longer used in the documentation
+ formatting toolchain, as the upstream default ones give better
+ output these days.
+
+ * The tracing mechanism learned to notice and report when
+ auto-discovered bare repositories are being used, as allowing so
+ without explicitly stating the user intends to do so (with setting
+ GIT_DIR for example) can be used with social engineering as an
+ attack vector.
+
+ * "git diff-files" learned not to expand sparse-index unless needed.
+
+
+Fixes since v2.40
+-----------------
+
+ * "git fsck" learned to check the index files in other worktrees,
+ just like "git gc" honors them as anchoring points.
+ (merge 8d3e7eac52 jk/fsck-indices-in-worktrees later to maint).
+
+ * Fix a segfaulting loop. The function and its caller may need
+ further clean-up.
+ (merge c5773dc078 ew/commit-reach-clean-up-flags-fix later to maint).
+
+ * "git restore" supports options like "--ours" that are only
+ meaningful during a conflicted merge, but these options are only
+ meaningful when updating the working tree files. These options are
+ marked to be incompatible when both "--staged" and "--worktree" are
+ in effect.
+ (merge ee8a88826a ak/restore-both-incompatible-with-conflicts later to maint).
+
+ * Simplify UI to control progress meter given by "git bundle" command.
+ (merge 8b95521edb jk/bundle-progress later to maint).
+
+ * "git bundle" learned that "-" is a common way to say that the input
+ comes from the standard input and/or the output goes to the
+ standard output. It used to work only for output and only from the
+ root level of the working tree.
+ (merge 0bbe10313e jk/bundle-use-dash-for-stdfiles later to maint).
+
+ * Once we start running, we assumed that the list of alternate object
+ databases would never change. Hook into the machinery used to
+ update the list of packfiles during runtime to update this list as
+ well.
+ (merge e2d003dbed ds/reprepare-alternates-when-repreparing-packfiles later to maint).
+
+ * The code to parse "git rebase -X<opt>" was not prepared to see an
+ unparsable option string, which has been corrected.
+ (merge 15a4cc912e ab/fix-strategy-opts-parsing later to maint).
+
+ * "git add -p" while the index is unmerged sometimes failed to parse
+ the diff output it internally produces and died, which has been
+ corrected.
+ (merge 28d1122f9c jk/add-p-unmerged-fix later to maint).
+
+ * Fix for a "ls-files --format="%(path)" that produced nonsense
+ output, which was a bug in 2.38.
+ (merge cfb62dd006 aj/ls-files-format-fix later to maint).
+
+ * "git receive-pack" that responds to "git push" requests failed to
+ clean a stale lockfile when killed in the middle, which has been
+ corrected.
+ (merge c55c30669c ps/receive-pack-unlock-before-die later to maint).
+
+ * "git rev-parse --quiet foo@{u}", or anything that asks @{u} to be
+ parsed with GET_OID_QUIETLY option, did not quietly fail, which has
+ been corrected.
+ (merge dfbfdc521d fc/oid-quietly-parse-upstream later to maint).
+
+ * Transports that do not support protocol v2 did not correctly fall
+ back to protocol v0 under certain conditions, which has been
+ corrected.
+ (merge eaa0fd6584 jk/fix-proto-downgrade-to-v0 later to maint).
+
+ * time(2) on glib 2.31+, especially on Linux, goes out of sync with
+ higher resolution timers used for gettimeofday(2) and by the
+ filesystem. Replace all calls to it with a git_time() wrapper and
+ (merge 370ddcbc89 pe/time-use-gettimeofday later to maint).
+
+ * Code clean-up to use designated initializers in parse-options API.
+ (merge 353e6d4554 sg/parse-options-h-initializers later to maint).
+
+ * A recent-ish change to allow unicode character classes to be used
+ with "grep -P" triggered a JIT bug in older pcre2 libraries.
+ The problematic change in Git built with these older libraries has
+ been disabled to work around the bug.
+ (merge 14b9a04479 mk/workaround-pcre-jit-ucp-bug later to maint).
+
+ * The wildmatch library code unlearns exponential behaviour it
+ acquired some time ago since it was borrowed from rsync.
+ (merge 3dc0b7f0dc pw/wildmatch-fixes later to maint).
+
+ * The index files can become corrupt under certain conditions when
+ the split-index feature is in use, especially together with
+ fsmonitor, which have been corrected.
+ (merge 061dd722dc js/split-index-fixes later to maint).
+
+ * Document what the pathname-looking strings in "rev-list --object"
+ output are for and what they mean.
+ (merge 15364d2a3c jk/document-rev-list-object-name later to maint).
+
+ * Fix unnecessary truncation of generation numbers used in-core.
+ (merge d3af1c193d ps/ahead-behind-truncation-fix later to maint).
+
+ * Code clean-up around the use of the_repository.
+ (merge 4a93b899c1 ab/remove-implicit-use-of-the-repository later to maint).
+
+ * Consistently spell "Message-ID" as such, not "Message-Id".
+ (merge ba4324c4e1 jc/spell-id-in-both-caps-in-message-id later to maint).
+
+ * Correct use of an uninitialized structure member.
+ (merge dc12ee77ab jx/cap-object-info-uninitialized-fix later to maint).
+
+ * Tests had a few places where we ignored PERL_PATH and blindly used
+ /usr/bin/perl, which have been corrected.
+ (merge c1917156a0 jk/use-perl-path-consistently later to maint).
+
+ * Documentation mark-up fix.
+ (merge 78b6369e67 la/mfc-markup-fix later to maint).
+
+ * Doc toolchain update to remove old workaround for AsciiDoc.
+ (merge 8806120de6 fc/remove-header-workarounds-for-asciidoc later to maint).
+
+ * The userdiff regexp patterns for various filetypes that are built
+ into the system have been updated to avoid triggering regexp errors
+ from UTF-8 aware regex engines.
+ (merge be39144954 rs/userdiff-multibyte-regex later to maint).
+
+ * The approxidate() API has been simplified by losing an extra
+ function that did the same thing as another one.
+ (merge 8a7f0b666f rs/remove-approxidate-relative later to maint).
+
+ * Code clean-up to replace a hardcoded constant with a CPP macro.
+ (merge c870de6502 rs/get-tar-commit-id-use-defined-const later to maint).
+
+ * Doc build simplification.
+ (merge 9a09ed3229 fc/doc-stop-using-manversion later to maint).
+
+ * "git archive" run from a subdirectory mishandled attributes and
+ paths outside the current directory.
+ (merge 92b1dd1b9e rs/archive-from-subdirectory-fixes later to maint).
+
+ * The code to parse capability list for v0 on-wire protocol fell into
+ an infinite loop when a capability appears multiple times, which
+ has been corrected.
+
+ * Geometric repacking ("git repack --geometric=<n>") in a repository
+ that borrows from an alternate object database had various corner
+ case bugs, which have been corrected.
+ (merge d85cd18777 ps/fix-geom-repack-with-alternates later to maint).
+
+ * The "%GT" placeholder for the "--format" option of "git log" and
+ friends caused BUG() to trigger on a commit signed with an unknown
+ key, which has been corrected.
+ (merge 7891e46585 jk/gpg-trust-level-fix later to maint).
+
+ * The completion script used to use bare "read" without the "-r"
+ option to read the contents of various state files, which risked
+ getting confused with backslashes in them. This has been
+ corrected.
+ (merge 197152098a ek/completion-use-read-r-to-read-literally later to maint).
+
+ * A small API fix to the ort merge strategy backend.
+ (merge 000c4ceca7 en/ort-finalize-after-0-merges-fix later to maint).
+
+ * The commit object parser has been taught to be a bit more lenient
+ to parse timestamps on the author/committer line with a malformed
+ author/committer ident.
+ (merge 90ef0f14eb jk/parse-commit-with-malformed-ident later to maint).
+
+ * Retitle a test script with an overly narrow name.
+ (merge 8bb19c14fb ob/t3501-retitle later to maint).
+
+ * Doc update to clarify how text and eol attributes interact to
+ specify the end-of-line conversion.
+ (merge 6696077ace ah/doc-attributes-text later to maint).
+
+ * Gitk updates from GfW project.
+ (merge 99e70f3077 js/gitk-fixes-from-gfw later to maint).
+
+ * "git diff --dirstat" leaked memory, which has been plugged.
+ (merge 83973981eb jc/dirstat-plug-leaks later to maint).
+
+ * "git merge-tree" reads the basic configuration, which can be used
+ by git forges to disable replace-refs feature.
+ (merge b6551feadf ds/merge-tree-use-config later to maint).
+
+ * A few bugs in the sequencer machinery that results in miscounting
+ the steps have been corrected.
+ (merge 170eea9750 js/rebase-count-fixes later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge f7111175df as/doc-markup-fix later to maint).
+ (merge 90ff7c9898 fc/test-aggregation-clean-up later to maint).
+ (merge 9b0c7f308a jc/am-doc-refer-to-format-patch later to maint).
+ (merge b10cbdac4c bb/unicode-width-table-15 later to maint).
+ (merge 3457b50e8c ab/retire-scripted-add-p later to maint).
+ (merge d52fcf493b ds/p2000-fix-grep-sparse later to maint).
+ (merge ec063d2591 ss/hashmap-typofix later to maint).
+ (merge 1aaed69d11 rs/archive-mtime later to maint).
+ (merge 2da2cc9b28 ob/rollback-after-commit-lock-failure later to maint).
+ (merge 54dbd0933b ob/sequencer-save-head-simplify later to maint).
+ (merge a93cbe8d78 ar/test-cleanup-unused-file-creation later to maint).
+ (merge cc48ddd937 jk/chainlint-fixes later to maint).
+ (merge 4833b08426 ow/ref-format-remove-unused-member later to maint).
+ (merge d0ea2ca1cf dw/doc-submittingpatches-grammofix later to maint).
+ (merge fd72637423 ar/t2024-checkout-output-fix later to maint).
+ (merge d45cbe3fe0 ob/sequencer-i18n-fix later to maint).
+ (merge b734fe49fd ob/messages-capitalize-exception later to maint).
+ (merge ad353d7e77 ma/gittutorial-fixes later to maint).
+ (merge a5855fd8d4 ar/test-cleanup-unused-file-creation-part2 later to maint).
+ (merge 0c5308af30 sd/doc-gitignore-and-rm-cached later to maint).
+ (merge cbb83daeaf kh/doc-interpret-trailers-updates later to maint).
+ (merge 3d77fbb664 ar/config-count-tests-updates later to maint).
+ (merge b7cf25c8f4 jc/t9800-fix-use-of-show-s-raw later to maint).
diff --git a/RelNotes/2.41.1.adoc b/RelNotes/2.41.1.adoc
new file mode 100644
index 0000000..9fb4c21
--- /dev/null
+++ b/RelNotes/2.41.1.adoc
@@ -0,0 +1,7 @@
+Git v2.41.1 Release Notes
+=========================
+
+This release merges up the fix that appears in v2.39.4 and v2.40.2
+to address the security issues CVE-2024-32002, CVE-2024-32004,
+CVE-2024-32020, CVE-2024-32021 and CVE-2024-32465; see the release
+notes for these versions for details.
diff --git a/RelNotes/2.41.2.adoc b/RelNotes/2.41.2.adoc
new file mode 100644
index 0000000..f94afde
--- /dev/null
+++ b/RelNotes/2.41.2.adoc
@@ -0,0 +1,26 @@
+Git v2.41.2 Release Notes
+=========================
+
+In preparing security fixes for four CVEs, we made overly aggressive
+"defense in depth" changes that broke legitimate use cases like 'git
+lfs' and 'git annex.' This release is to revert these misguided, if
+well-intentioned, changes that were shipped in 2.41.1 and were not
+direct security fixes.
+
+Jeff King (5):
+ send-email: drop FakeTerm hack
+ send-email: avoid creating more than one Term::ReadLine object
+ ci: drop mention of BREW_INSTALL_PACKAGES variable
+ ci: avoid bare "gcc" for osx-gcc job
+ ci: stop installing "gcc-13" for osx-gcc
+
+Johannes Schindelin (6):
+ hook: plug a new memory leak
+ init: use the correct path of the templates directory again
+ Revert "core.hooksPath: add some protection while cloning"
+ tests: verify that `clone -c core.hooksPath=/dev/null` works again
+ clone: drop the protections where hooks aren't run
+ Revert "Add a helper function to compare file contents"
+
+Junio C Hamano (1):
+ Revert "fsck: warn about symlink pointing inside a gitdir"
diff --git a/RelNotes/2.41.3.adoc b/RelNotes/2.41.3.adoc
new file mode 100644
index 0000000..b5aba88
--- /dev/null
+++ b/RelNotes/2.41.3.adoc
@@ -0,0 +1,6 @@
+Git v2.41.3 Release Notes
+=========================
+
+This release merges up the fix that appears in v2.40.4 to address
+the security issues CVE-2024-50349 and CVE-2024-52006; see the
+release notes for that version for details.
diff --git a/RelNotes/2.42.0.adoc b/RelNotes/2.42.0.adoc
new file mode 100644
index 0000000..0f1897a
--- /dev/null
+++ b/RelNotes/2.42.0.adoc
@@ -0,0 +1,329 @@
+Git v2.42 Release Notes
+=======================
+
+UI, Workflows & Features
+
+ * "git pack-refs" learns "--include" and "--exclude" to tweak the ref
+ hierarchy to be packed using pattern matching.
+
+ * 'git worktree add' learned how to create a worktree based on an
+ orphaned branch with `--orphan`.
+
+ * "git pack-objects" learned to invoke a new hook program that
+ enumerates extra objects to be used as anchoring points to keep
+ otherwise unreachable objects in cruft packs.
+
+ * Add more "git var" for toolsmiths to learn various locations Git is
+ configured with either via the configuration or hard-coded defaults.
+
+ * 'git notes append' was taught '--separator' to specify string to insert
+ between paragraphs.
+
+ * The "git for-each-ref" family of commands learned placeholders
+ related to GPG signature verification.
+
+ * "git diff --no-index" learned to read from named pipes as if they
+ were regular files, to allow "git diff <(process) <(substitution)"
+ some shells support.
+
+ * Help newbies by suggesting that there are cases where force-pushing
+ is a valid and sensible thing to update a branch at a remote
+ repository, rather than reconciling with merge/rebase.
+
+ * "git blame --contents=file" has been taught to work in a bare
+ repository.
+
+ * "git branch -f X" to repoint the branch X said that X was "checked
+ out" in another worktree, even when branch X was not and instead
+ being bisected or rebased. The message was reworded to say the
+ branch was "in use".
+
+ * Tone down the warning on SHA-256 repositories being an experimental
+ curiosity. We do not have support for them to interoperate with
+ traditional SHA-1 repositories, but at this point, we do not plan
+ to make breaking changes to SHA-256 repositories and there is no
+ longer need for such a strongly phrased warning.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * "git diff-tree" has been taught to take advantage of the
+ sparse-index feature.
+
+ * Clang's sanitizer implementation seems to work better than GCC's.
+ (merge d88d727143 jk/ci-use-clang-for-sanitizer-jobs later to maint).
+
+ * The object traversal using reachability bitmap done by
+ "pack-object" has been tweaked to take advantage of the fact that
+ using "boundary" commits as representative of all the uninteresting
+ ones can save quite a lot of object enumeration.
+
+ * discover_git_directory() no longer touches the_repository.
+
+ * "git worktree" learned to work better with sparse index feature.
+
+ * When the external merge driver is killed by a signal, its output
+ should not be trusted as a resolution with conflicts that is
+ proposed by the driver, but the code did.
+
+ * The set-up code for the get_revision() API now allows feeding
+ options like --all and --not in the --stdin mode.
+
+ * Move functions that are not about pure string manipulation out of
+ strbuf.[ch]
+
+ * "imap-send" codepaths got cleaned up to get rid of unused
+ parameters.
+
+ * Enumerating refs in the packed-refs file, while excluding refs that
+ match certain patterns, has been optimized.
+
+ * Mark-up unused parameters in the code so that we can eventually
+ enable -Wunused-parameter by default.
+
+ * Instead of inventing a custom counter variables for debugging,
+ use existing trace2 facility in the fsync customization codepath.
+
+ * "git branch --list --format=<format>" and friends are taught
+ a new "%(describe)" placeholder.
+
+ * Clarify how to choose the starting point for a new topic in
+ developer guidance document.
+
+ * The implementation of "get_sha1_hex()" that reads a hexadecimal
+ string that spells a full object name has been extended to cope
+ with any hash function used in the repository, but the "sha1" in
+ its name survived. Rename it to get_hash_hex(), a name that is
+ more consistent within its friends like get_hash_hex_algop().
+
+ * Command line parser fix, and a small parse-options API update.
+
+
+Fixes since v2.41
+-----------------
+
+ * "git tag" learned to leave the "$GIT_DIR/TAG_EDITMSG" file when the
+ command failed, so that the user can salvage what they typed.
+ (merge 08c12ec1d0 kh/keep-tag-editmsg-upon-failure later to maint).
+
+ * The "-s" (silent, squelch) option of the "diff" family of commands
+ did not interact with other options that specify the output format
+ well. This has been cleaned up so that it will clear all the
+ formatting options given before.
+ (merge 9d484b92ed jc/diff-s-with-other-options later to maint).
+
+ * Update documentation regarding Coccinelle patches.
+ (merge 3bd0097cfc gc/doc-cocci-updates later to maint).
+
+ * Some atoms that can be used in "--format=<format>" for "git ls-tree"
+ were not supported by "git ls-files", even though they were relevant
+ in the context of the latter.
+ (merge 4d28c4f75f zh/ls-files-format-atoms later to maint).
+
+ * Document more pseudo-refs and teach the command line completion
+ machinery to complete AUTO_MERGE.
+ (merge 982ff3a649 pb/complete-and-document-auto-merge-and-friends later to maint).
+
+ * "git submodule" code trusted the data coming from the config (and
+ the in-tree .gitmodules file) too much without validating, leading
+ to NULL dereference if the user mucks with a repository (e.g.
+ submodule.<name>.url is removed). This has been corrected.
+ (merge fbc806acd1 tb/submodule-null-deref-fix later to maint).
+
+ * The value of config.worktree is per-repository, but has been kept
+ in a singleton global variable per process. This has been OK as
+ most Git operations interacted with a single repository at a time,
+ but not right for operations like recursive "grep" that want to
+ access multiple repositories from a single process without forking.
+
+ The global variable has been eliminated and made into a member in
+ the per-repository data structure.
+ (merge 3867f6d650 vd/worktree-config-is-per-repository later to maint).
+
+ * "git [-c log.follow=true] log [--follow] ':(glob)f**'" used to barf.
+ (merge 8260bc5902 jk/log-follow-with-non-literal-pathspec later to maint).
+
+ * Introduce a mechanism to disable replace refs globally and per
+ repository.
+ (merge 9c7d1b057f ds/disable-replace-refs later to maint).
+
+ * "git cat-file --batch" and friends learned "-Z" that uses NUL
+ delimiter for both input and output.
+ (merge f79e18849b ps/cat-file-null-output later to maint).
+
+ * The reimplemented "git add -i" did not honor color.ui configuration.
+ (merge 6f74648cea ds/add-i-color-configuration-fix later to maint).
+
+ * Compilation fix for platforms without D_TYPE in struct dirent.
+ (merge 03bf92b9bf as/dtype-compilation-fix later to maint).
+
+ * Suggest to refrain from using hex literals that are non-portable
+ when writing printf(1) format strings.
+ (merge f0b68f0546 jt/doc-use-octal-with-printf later to maint).
+
+ * Simplify error message when run-command fails to start a command.
+ (merge 6d224ac286 rs/run-command-exec-error-on-noent later to maint).
+
+ * Gracefully deal with a stale MIDX file that lists a packfile that
+ no longer exists.
+ (merge 06f3867865 tb/open-midx-bitmap-fallback later to maint).
+
+ * Even when diff.ignoreSubmodules tells us to ignore submodule
+ changes, "git commit" with an index that already records changes to
+ submodules should include the submodule changes in the resulting
+ commit, but it did not.
+ (merge 5768478edc js/defeat-ignore-submodules-config-with-explicit-addition later to maint).
+
+ * When "git commit --trailer=..." invokes the interpret-trailers
+ machinery, it knows what it feeds to interpret-trailers is a full
+ log message without any patch, but failed to express that by
+ passing the "--no-divider" option, which has been corrected.
+ (merge be3d654343 jk/commit-use-no-divider-with-interpret-trailers later to maint).
+
+ * Avoid breakage of "git pack-objects --cruft" due to inconsistency
+ between the way the code enumerates packfiles in the repository.
+ (merge 73320e49ad tb/collect-pack-filenames-fix later to maint).
+
+ * We create .pack and then .idx, we consider only packfiles that have
+ .idx usable (those with only .pack are not ready yet), so we should
+ remove .idx before removing .pack for consistency.
+ (merge 0dd1324a73 ds/remove-idx-before-pack later to maint).
+
+ * Partially revert a sanity check that the rest of the config code
+ was not ready, to avoid triggering it in a corner case.
+ (merge a53f43f900 gc/config-partial-submodule-kvi-fix later to maint).
+
+ * "git apply" punts when it is fed too large a patch input; the error
+ message it gives when it happens has been clarified.
+ (merge 42612e18d2 pw/apply-too-large later to maint).
+
+ * During a cherry-pick or revert session that works on multiple
+ commits, "git status" did not give correct information, which has
+ been corrected.
+ (merge a096a889f4 jk/cherry-pick-revert-status later to maint).
+
+ * A few places failed to differentiate the case where the index is
+ truly empty (nothing added) and we haven't yet read from the
+ on-disk index file, which have been corrected.
+ (merge 2ee045eea1 js/empty-index-fixes later to maint).
+
+ * "git bugreport" tests did not test what it wanted to test, which
+ has been corrected.
+ (merge 1aa92b8500 ma/t0091-fixup later to maint).
+
+ * Code snippets in a tutorial document no longer compiled after
+ recent header shuffling, which have been corrected.
+ (merge bbd7c7b7c0 vd/adjust-mfow-doc-to-updated-headers later to maint).
+
+ * "git ls-files '(attr:X)D/'" that triggers the common prefix
+ optimization codepath failed to read from "D/.gitattributes",
+ which has been corrected.
+ (merge f4a8fde057 jc/pathspec-match-with-common-prefix later to maint).
+
+ * "git fsck --no-progress" still spewed noise from the commit-graph
+ subsystem, which has been corrected.
+ (merge 9281cd07f0 tb/fsck-no-progress later to maint).
+
+ * Various offset computation in the code that accesses the packfiles
+ and other data in the object layer has been hardened against
+ arithmetic overflow, especially on 32-bit systems.
+ (merge 9a25cad7e0 tb/object-access-overflow-protection later to maint).
+
+ * Names of MinGW header files are spelled in mixed case in some
+ source files, but the build host can be using case sensitive
+ filesystem with header files with their name spelled in all
+ lowercase.
+ (merge 4a53d0d0bc mh/mingw-case-sensitive-build later to maint).
+
+ * Update message mark-up for i18n in "git bundle".
+ (merge bbb6acd998 dk/bundle-i18n-more later to maint).
+
+ * "git tag --list --points-at X" showed tags that directly refers to
+ object X, but did not list a tag that points at such a tag, which
+ has been corrected.
+
+ * "./configure --with-expat=no" did not work as a way to refuse use
+ of the expat library on a system with the library installed, which
+ has been corrected.
+ (merge fb8f7269c2 ah/autoconf-fixes later to maint).
+
+ * When the user edits "rebase -i" todo file so that it starts with a
+ "fixup", which would make it invalid, the command truncated the
+ rest of the file before giving an error and returning the control
+ back to the user. Stop truncating to make it easier to correct
+ such a malformed todo file.
+ (merge 9645a087c2 ah/sequencer-rewrite-todo-fix later to maint).
+
+ * Rewrite the description of giving a custom command to the
+ submodule.<name>.update configuration variable.
+ (merge 7cebc5bd78 pv/doc-submodule-update-settings later to maint).
+
+ * Adjust to OpenSSL 3+, which deprecates its SHA-1 functions based on
+ its traditional API, by using its EVP API instead.
+ (merge bda9c12073 ew/hash-with-openssl-evp later to maint).
+
+ * Exclude "." from the set of characters to be removed from the
+ beginning and the end of the human-readable name.
+ (merge 1c04cb0744 bc/ident-dot-is-no-longer-crud-letter later to maint).
+
+ * "git bisect visualize" stopped running "gitk" on Git for Windows
+ when the command was reimplemented in C around Git 2.34 timeframe.
+ This has been corrected.
+ (merge fff1594fa7 ma/locate-in-path-for-windows later to maint).
+
+ * "git rebase -i" with a series of squash/fixup, when one of the
+ steps stopped in conflicts and ended up getting skipped, did not
+ handle the accumulated commit log messages, which has been
+ corrected.
+ (merge 6ce7afe163 pw/rebase-skip-commit-message-fix later to maint).
+
+ * Adjust to newer Term::ReadLine to prevent it from breaking
+ the interactive prompt code in send-email.
+ (merge c016726c2d jk/send-email-with-new-readline later to maint).
+
+ * Windows updates.
+ (merge 0050f8e401 ds/maintenance-on-windows-fix later to maint).
+
+ * Correct use of lstat() that assumed a failing call would not
+ clobber the statbuf.
+ (merge 72695d8214 st/mv-lstat-fix later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge 51f9d2e563 sa/doc-ls-remote later to maint).
+ (merge c6d26a9dda jk/format-patch-message-id-unleak later to maint).
+ (merge f7e063f326 ps/fetch-cleanups later to maint).
+ (merge e4cf013468 tl/quote-problematic-arg-for-clarity later to maint).
+ (merge 20025fdfc7 tz/test-ssh-verifytime-fix later to maint).
+ (merge e48a21df65 tz/test-fix-pthreads-prereq later to maint).
+ (merge 68b51172e3 mh/commit-reach-get-reachable-plug-leak later to maint).
+ (merge aeee1408ce kh/use-default-notes-doc later to maint).
+ (merge 3b8724bce6 jc/test-modernization later to maint).
+ (merge 447a3b7331 jc/test-modernization-2 later to maint).
+ (merge d57fa7fc73 la/doc-interpret-trailers later to maint).
+ (merge 548afb0d9a la/docs-typofixes later to maint).
+ (merge 3744ffcbcd rs/doc-ls-tree-hex-literal later to maint).
+ (merge 6c26da8404 mh/credential-erase-improvements later to maint).
+ (merge 78e56cff69 tz/lib-gpg-prereq-fix later to maint).
+ (merge 80d32e84b5 rj/leakfixes later to maint).
+ (merge 0a868031ed pb/complete-diff-options later to maint).
+ (merge d4f28279ad jc/doc-hash-object-types later to maint).
+ (merge 1876a5ae15 ks/t4205-test-describe-with-abbrev-fix later to maint).
+ (merge 6e6a529b57 jk/fsck-indices-in-worktrees later to maint).
+ (merge 3e81b896f7 rs/packet-length-simplify later to maint).
+ (merge 4c9cb51fe7 mh/doc-credential-helpers later to maint).
+ (merge 3437f549dd jr/gitignore-doc-example-markup later to maint).
+ (merge 947ebd62a0 jc/am-parseopt-fix later to maint).
+ (merge e12cb98e1e jc/branch-parseopt-fix later to maint).
+ (merge d6f598e443 jc/gitignore-doc-pattern-markup later to maint).
+ (merge a2dad4868b jc/transport-parseopt-fix later to maint).
+ (merge 68cbb20e73 jc/parse-options-show-branch later to maint).
+ (merge 3821eb6c3d jc/parse-options-reset later to maint).
+ (merge c48af99a3e bb/trace2-comment-fix later to maint).
+ (merge c95ae3ff9c rs/describe-parseopt-fix later to maint).
+ (merge 36f76d2a25 rs/pack-objects-parseopt-fix later to maint).
+ (merge 30c8c55cbf jc/tree-walk-drop-base-offset later to maint).
+ (merge d089a06421 rs/bundle-parseopt-cleanup later to maint).
+ (merge 823839bda1 ew/sha256-gcrypt-leak-fixes later to maint).
+ (merge a5c01603b3 bc/ignore-clangd-cache later to maint).
+ (merge 12009a182b js/allow-t4000-to-be-indented-with-spaces later to maint).
+ (merge b3dcd24b8a jc/send-email-pre-process-fix later to maint).
diff --git a/RelNotes/2.42.1.adoc b/RelNotes/2.42.1.adoc
new file mode 100644
index 0000000..3d391b7
--- /dev/null
+++ b/RelNotes/2.42.1.adoc
@@ -0,0 +1,88 @@
+Git 2.42.1 Release Notes
+========================
+
+There is nothing exciting to see here. Relative to Git 2.42, this
+release contains the fixes that have already been merged to the
+'master' branch of the development towards Git 2.43 that has been
+tagged as Git 2.43.0-rc0.
+
+Fixes since Git 2.42.0
+----------------------
+
+ * Tests that are known to pass with LSan are now marked as such.
+
+ * Flaky "git p4" tests, as well as "git svn" tests, are now skipped
+ in the (rather expensive) sanitizer CI job.
+
+ * Tests with LSan from time to time seem to emit harmless message
+ that makes our tests unnecessarily flaky; we work it around by
+ filtering the uninteresting output.
+
+ * GitHub CI workflow has learned to trigger Coverity check.
+
+ * Overly long label names used in the sequencer machinery are now
+ chopped to fit under filesystem limitation.
+
+ * Scalar updates.
+
+ * Tweak GitHub Actions CI so that pushing the same commit to multiple
+ branch tips at the same time will not waste building and testing
+ the same thing twice.
+
+ * The commit-graph verification code that detects mixture of zero and
+ non-zero generation numbers has been updated.
+
+ * "git diff -w --exit-code" with various options did not work
+ correctly, which is being addressed.
+
+ * transfer.unpackLimit ought to be used as a fallback, but overrode
+ fetch.unpackLimit and receive.unpackLimit instead.
+
+ * The use of API between two calls to require_clean_work_tree() from
+ the sequencer code has been cleaned up for consistency.
+
+ * "git diff --no-such-option" and other corner cases around the exit
+ status of the "diff" command has been corrected.
+
+ * "git for-each-ref --sort='contents:size'" sorts the refs according
+ to size numerically, giving a ref that points at a blob twelve-byte
+ (12) long before showing a blob hundred-byte (100) long.
+
+ * Various fixes to the behavior of "rebase -i" when the command got
+ interrupted by conflicting changes.
+
+ * References from description of the `--patch` option in various
+ manual pages have been simplified and improved.
+
+ * "git grep -e A --no-or -e B" is accepted, even though the negation
+ of "or" did not mean anything, which has been tightened.
+
+ * The completion script (in contrib/) has been taught to treat the
+ "-t" option to "git checkout" and "git switch" just like the
+ "--track" option, to complete remote-tracking branches.
+
+ * "git diff --no-index -R <(one) <(two)" did not work correctly,
+ which has been corrected.
+
+ * Update "git maintenance" timers' implementation based on systemd
+ timers to work with WSL.
+
+ * "git diff --cached" codepath did not fill the necessary stat
+ information for a file when fsmonitor knows it is clean and ended
+ up behaving as if it is not clean, which has been corrected.
+
+ * Clarify how "alias.foo = : git cmd ; aliased-command-string" should
+ be spelled with necessary whitespaces around punctuation marks to
+ work.
+
+ * HTTP Header redaction code has been adjusted for a newer version of
+ cURL library that shows its traces differently from earlier
+ versions.
+
+ * An error message given by "git send-email" when given a malformed
+ address did not give correct information, which has been corrected.
+
+ * UBSan options were not propagated through the test framework to git
+ run via the httpd, unlike ASan options, which has been corrected.
+
+Also contains various documentation updates, code clean-ups and minor fixups.
diff --git a/RelNotes/2.42.2.adoc b/RelNotes/2.42.2.adoc
new file mode 100644
index 0000000..dbf761a
--- /dev/null
+++ b/RelNotes/2.42.2.adoc
@@ -0,0 +1,7 @@
+Git v2.42.2 Release Notes
+=========================
+
+This release merges up the fix that appears in v2.39.4, v2.40.2
+and v2.41.1 to address the security issues CVE-2024-32002,
+CVE-2024-32004, CVE-2024-32020, CVE-2024-32021 and CVE-2024-32465;
+see the release notes for these versions for details.
diff --git a/RelNotes/2.42.3.adoc b/RelNotes/2.42.3.adoc
new file mode 100644
index 0000000..bfe3ba5
--- /dev/null
+++ b/RelNotes/2.42.3.adoc
@@ -0,0 +1,26 @@
+Git v2.42.3 Release Notes
+=========================
+
+In preparing security fixes for four CVEs, we made overly aggressive
+"defense in depth" changes that broke legitimate use cases like 'git
+lfs' and 'git annex.' This release is to revert these misguided, if
+well-intentioned, changes that were shipped in 2.42.2 and were not
+direct security fixes.
+
+Jeff King (5):
+ send-email: drop FakeTerm hack
+ send-email: avoid creating more than one Term::ReadLine object
+ ci: drop mention of BREW_INSTALL_PACKAGES variable
+ ci: avoid bare "gcc" for osx-gcc job
+ ci: stop installing "gcc-13" for osx-gcc
+
+Johannes Schindelin (6):
+ hook: plug a new memory leak
+ init: use the correct path of the templates directory again
+ Revert "core.hooksPath: add some protection while cloning"
+ tests: verify that `clone -c core.hooksPath=/dev/null` works again
+ clone: drop the protections where hooks aren't run
+ Revert "Add a helper function to compare file contents"
+
+Junio C Hamano (1):
+ Revert "fsck: warn about symlink pointing inside a gitdir"
diff --git a/RelNotes/2.42.4.adoc b/RelNotes/2.42.4.adoc
new file mode 100644
index 0000000..3129d76
--- /dev/null
+++ b/RelNotes/2.42.4.adoc
@@ -0,0 +1,6 @@
+Git v2.42.4 Release Notes
+=========================
+
+This release merges up the fix that appears in v2.40.4 and v2.41.3
+to address the security issues CVE-2024-50349 and CVE-2024-52006;
+see the release notes for these versions for details.
diff --git a/RelNotes/2.43.0.adoc b/RelNotes/2.43.0.adoc
new file mode 100644
index 0000000..e0e5b53
--- /dev/null
+++ b/RelNotes/2.43.0.adoc
@@ -0,0 +1,323 @@
+Git v2.43 Release Notes
+=======================
+
+Backward Compatibility Notes
+
+ * The "--rfc" option of "git format-patch" used to be a valid way to
+ override an earlier "--subject-prefix=<something>" on the command
+ line and replace it with "[RFC PATCH]", but from this release, it
+ merely prefixes the string "RFC " in front of the given subject
+ prefix. If you are negatively affected by this change, please use
+ "--subject-prefix=PATCH --rfc" as a replacement.
+
+ * In Git 2.42, "git rev-list --stdin" learned to take non-revisions
+ (like "--not") from the standard input, but the way such a "--not" was
+ handled was quite confusing, which has been rethought. The updated
+ rule is that "--not" given from the command line only affects revs
+ given from the command line that comes but not revs read from the
+ standard input, and "--not" read from the standard input affects
+ revs given from the standard input and not revs given from the
+ command line.
+
+UI, Workflows & Features
+
+ * A message written in olden time prevented a branch from getting
+ checked out, saying it is already checked out elsewhere. But these
+ days, we treat a branch that is being bisected or rebased just like
+ a branch that is checked out and protect it from getting modified
+ with the same codepath. The message has been rephrased to say that
+ the branch is "in use" to avoid confusion.
+
+ * Hourly and other schedules of "git maintenance" jobs are randomly
+ distributed now.
+
+ * "git cmd -h" learned to signal which options can be negated by
+ listing such options like "--[no-]opt".
+
+ * The way authentication related data other than passwords (e.g.,
+ oauth token and password expiration data) are stored in libsecret
+ keyrings has been rethought.
+
+ * Update the libsecret and wincred credential helpers to correctly
+ match which credential to erase; they erased the wrong entry in
+ some cases.
+
+ * Git GUI updates.
+
+ * "git format-patch" learned a new "--description-file" option that
+ lets cover letter description to be fed; this can be used on
+ detached HEAD where there is no branch description available, and
+ also can override the branch description if there is one.
+
+ * Use of the "--max-pack-size" option to allow multiple packfiles to
+ be created is now supported even when we are sending unreachable
+ objects to cruft packs.
+
+ * "git format-patch --rfc --subject-prefix=<foo>" used to ignore the
+ "--subject-prefix" option and used "[RFC PATCH]"; now we will add
+ "RFC" prefix to whatever subject prefix is specified.
+
+ * "git log --format" has been taught the %(decorate) placeholder for
+ further customization over what the "--decorate" option offers.
+
+ * The default log message created by "git revert", when reverting a
+ commit that records a revert, has been tweaked, to encourage people
+ to describe complex "revert of revert of revert" situations better in
+ their own words.
+
+ * The command-line completion support (in contrib/) learned to
+ complete "git commit --trailer=" for possible trailer keys.
+
+ * "git update-index" learned the "--show-index-version" option to
+ inspect the index format version used by the on-disk index file.
+
+ * "git diff" learned the "diff.statNameWidth" configuration variable,
+ to give the default width for the name part in the "--stat" output.
+
+ * "git range-diff --notes=foo" compared "log --notes=foo --notes" of
+ the two ranges, instead of using just the specified notes tree,
+ which has been corrected to use only the specified notes tree.
+
+ * The command line completion script (in contrib/) can be told to
+ complete aliases by including ": git <cmd> ;" in the alias to tell
+ it that the alias should be completed in a similar way to how "git
+ <cmd>" is completed. The parsing code for the alias has been
+ loosened to allow ';' without an extra space before it.
+
+ * "git for-each-ref" and friends learned to apply mailmap to
+ authorname and other fields in a more flexible way than using
+ separate placeholder letters like %a[eElL] every time we want to
+ come up with small variants.
+
+ * "git repack" machinery learned to pay attention to the "--filter="
+ option.
+
+ * "git repack" learned the "--max-cruft-size" option to prevent cruft
+ packs from growing without bounds.
+
+ * "git merge-tree" learned to take strategy backend specific options
+ via the "-X" option, like "git merge" does.
+
+ * "git log" and friends learned the "--dd" option that is a
+ short-hand for "--diff-merges=first-parent -p".
+
+ * The attribute subsystem learned to honor the "attr.tree"
+ configuration variable that specifies which tree to read the
+ .gitattributes files from.
+
+ * "git merge-file" learns a mode to read three variants of the
+ contents to be merged from blob objects.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * "git check-attr" has been taught to work better with sparse-index.
+
+ * It may be tempting to leave the help text NULL for a command line
+ option that is either hidden or too obvious, but "git subcmd -h"
+ and "git subcmd --help-all" would have segfaulted if done so. Now
+ the help text is truly optional.
+
+ * Tests that are known to pass with LSan are now marked as such.
+
+ * Flaky "git p4" tests, as well as "git svn" tests, are now skipped
+ in the (rather expensive) sanitizer CI job.
+
+ * Tests with LSan from time to time seem to emit harmless messages
+ that make our tests unnecessarily flaky; we work around it by
+ filtering the uninteresting output.
+
+ * Unused parameters to functions are marked as such, and/or removed,
+ in order to bring us closer to "-Wunused-parameter" clean.
+
+ * The code to keep track of existing packs in the repository while
+ repacking has been refactored.
+
+ * The "streaming" interface used for bulk-checkin codepath has been
+ narrowed to take only blob objects for now, with no real loss of
+ functionality.
+
+ * GitHub CI workflow has learned to trigger Coverity check.
+
+ * Test coverage for trailers has been improved.
+
+ * The code to iterate over loose references has been optimized to
+ reduce the number of lstat() system calls.
+
+ * The codepaths that read "chunk" formatted files have been corrected
+ to pay attention to the chunk size and notice broken files.
+
+ * Replace macos-12 used at GitHub CI with macos-13.
+ (merge 682a868f67 js/ci-use-macos-13 later to maint).
+
+
+Fixes since v2.42
+-----------------
+
+ * Overly long label names used in the sequencer machinery are now
+ chopped to fit under filesystem limitation.
+
+ * Scalar updates.
+
+ * Tweak GitHub Actions CI so that pushing the same commit to multiple
+ branch tips at the same time will not waste building and testing
+ the same thing twice.
+
+ * The commit-graph verification code that detects a mixture of zero and
+ non-zero generation numbers has been updated.
+
+ * "git diff -w --exit-code" with various options did not work
+ correctly, which has been corrected.
+
+ * The "transfer.unpackLimit" configuration variable ought to be used
+ as a fallback, but overrode the more specific "fetch.unpackLimit"
+ and "receive.unpackLimit" configuration variables by mistake, which
+ has been corrected.
+
+ * The use of API between two calls to require_clean_work_tree() from
+ the sequencer code has been cleaned up for consistency.
+
+ * "git diff --no-such-option" and other corner cases around the exit
+ status of the "diff" command have been corrected.
+
+ * "git for-each-ref --sort='contents:size'" sorted the refs according
+ to size numerically, giving a ref that points at a blob twelve-byte
+ (12) long before showing a blob hundred-byte (100) long, which has
+ been corrected.
+
+ * We now limit the depth of the tree objects and maximum length of
+ pathnames recorded in tree objects.
+ (merge 4d5693ba05 jk/tree-name-and-depth-limit later to maint).
+
+ * Various fixes to the behavior of "rebase -i", when the command got
+ interrupted by conflicting changes, have been made.
+
+ * References from a description of the `--patch` option in various
+ manual pages have been simplified and improved.
+
+ * "git grep -e A --no-or -e B" is accepted, even though the negation
+ of the "--or" option did not mean anything, which has been tightened.
+
+ * The completion script (in contrib/) has been taught to treat the
+ "-t" option to "git checkout" and "git switch" just like the
+ "--track" option, to complete remote-tracking branches.
+
+ * "git diff --no-index -R <(one) <(two)" did not work correctly,
+ which has been corrected.
+
+ * "git maintenance" timers' implementation has been updated, based on
+ systemd timers, to work with WSL.
+
+ * "git diff --cached" codepath did not fill the necessary stat
+ information for a file when fsmonitor knows it is clean and ended
+ up behaving as if it were not clean, which has been corrected.
+
+ * How "alias.foo = : git cmd ; aliased-command-string" should be
+ spelled with necessary whitespace around punctuation marks to work
+ has been more clearly documented (but this will be moot with newer
+ versions of Git where the parsing rules have been improved).
+
+ * HTTP Header redaction code has been adjusted for a newer version of
+ cURL library that shows its traces differently from earlier
+ versions.
+
+ * An error message given by "git send-email", when given a malformed
+ address, did not show the offending address, which has been corrected.
+
+ * UBSan options were not propagated through the test framework to git
+ run via the httpd, unlike ASan options, which has been corrected.
+
+ * "checkout --merge -- path" and "update-index --unresolve path" did
+ not resurrect conflicted state that was resolved to remove path,
+ but now they do.
+ (merge 5bdedac3c7 jc/unresolve-removal later to maint).
+
+ * The display width table for unicode characters has been updated for
+ Unicode 15.1
+ (merge 872976c37e bb/unicode-width-table-15 later to maint).
+
+ * Update mailmap entry for Derrick.
+ (merge 6e5457d8c7 ds/mailmap-entry-update later to maint).
+
+ * In the ".gitmodules" files, submodules are keyed by their names,
+ and the path to the submodule whose name is $name is specified by
+ the submodule.$name.path variable. There were a few codepaths that
+ mixed the name and path up when consulting the submodule database,
+ which have been corrected. It took long for these bugs to be found
+ as the name of a submodule initially is the same as its path, and
+ the problem does not surface until it is moved to a different path,
+ which apparently happens very rarely.
+
+ * "git diff --merge-base X other args..." insisted that X must be a
+ commit and errored out when given an annotated tag that peels to a
+ commit, but we only need it to be a committish. This has been
+ corrected.
+ (merge 4adceb5a29 ar/diff-index-merge-base-fix later to maint).
+
+ * "git merge-tree" used to segfault when the "--attr-source"
+ option is used, which has been corrected.
+ (merge e95bafc52f jc/merge-ort-attr-index-fix later to maint).
+
+ * Unlike "git log --pretty=%D", "git log --pretty="%(decorate)" did
+ not auto-initialize the decoration subsystem, which has been
+ corrected.
+
+ * Feeding "git stash store" with a random commit that was not created
+ by "git stash create" now errors out.
+ (merge d9b6634589 jc/fail-stash-to-store-non-stash later to maint).
+
+ * The index file has room only for the lower 32-bit of the file size in
+ the cached stat information, which means cached stat information
+ will have 0 in its sd_size member for a file whose size is a multiple
+ of 4GiB. This is mistaken for a racily clean path. Avoid it by
+ storing a bogus sd_size value instead for such files.
+ (merge 5143ac07b1 bc/racy-4gb-files later to maint).
+
+ * "git p4" tried to store symlinks to LFS when told, but has been
+ fixed not to do so, because it does not make sense.
+ (merge 10c89a02b0 mm/p4-symlink-with-lfs later to maint).
+
+ * The codepath to handle recipient addresses `git send-email
+ --compose` learns from the user was completely broken, which has
+ been corrected.
+ (merge 3ec6167567 jk/send-email-fix-addresses-from-composed-messages later to maint).
+
+ * "cd sub && git grep -f patterns" tried to read "patterns" file at
+ the top level of the working tree; it has been corrected to read
+ "sub/patterns" instead.
+
+ * "git reflog expire --single-worktree" has been broken for the past
+ 20 months or so, which has been corrected.
+
+ * "git send-email" did not have certain pieces of data computed yet
+ when it tried to validate the outgoing messages and its recipient
+ addresses, which has been sorted out.
+
+ * "git bugreport" learned to complain when it received a command line
+ argument that it will not use.
+
+ * The codepath to traverse the commit-graph learned to notice that a
+ commit is missing (e.g., corrupt repository lost an object), even
+ though it knows something about the commit (like its parents) from
+ what is in commit-graph.
+ (merge 7a5d604443 ps/do-not-trust-commit-graph-blindly-for-existence later to maint).
+
+ * "git rev-list --missing" did not work for missing commit objects,
+ which has been corrected.
+
+ * "git rev-list --unpacked --objects" failed to exclude packed
+ non-commit objects, which has been corrected.
+ (merge 7b3c8e9f38 tb/rev-list-unpacked-fix later to maint).
+
+ * "To dereference" and "to peel" were sometimes used in in-code
+ comments and documentation but without description in the glossary.
+ (merge 893dce2ffb vd/glossary-dereference-peel later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge c2c349a15c xz/commit-title-soft-limit-doc later to maint).
+ (merge 1bd809938a tb/format-pack-doc-update later to maint).
+ (merge 8f81532599 an/clang-format-typofix later to maint).
+ (merge 3ca86adc2d la/strvec-header-fix later to maint).
+ (merge 6789275d37 jc/test-i18ngrep later to maint).
+ (merge 9972cd6004 ps/leakfixes later to maint).
+ (merge 46edab516b tz/send-email-helpfix later to maint).
diff --git a/RelNotes/2.43.1.adoc b/RelNotes/2.43.1.adoc
new file mode 100644
index 0000000..20e96f2
--- /dev/null
+++ b/RelNotes/2.43.1.adoc
@@ -0,0 +1,82 @@
+Git 2.43.1 Release Notes
+========================
+
+There is nothing exciting to see here. Relative to Git 2.43, this
+release contains the fixes that have already been merged to the
+'master' branch of the development towards the next major release.
+
+Fixes since Git 2.43.0
+----------------------
+
+ * The way CI testing used "prove" could lead to running the test
+ suite twice needlessly, which has been corrected.
+
+ * Newer versions of Getopt::Long started giving warnings against our
+ (ab)use of it in "git send-email". Bump the minimum version
+ requirement for Perl to 5.8.1 (from September 2002) to allow
+ simplifying our implementation.
+
+ * Earlier we stopped relying on commit-graph that (still) records
+ information about commits that are lost from the object store,
+ which has negative performance implications. The default has been
+ flipped to disable this pessimization.
+
+ * Stale URLs have been updated to their current counterparts (or
+ archive.org) and HTTP links are replaced with working HTTPS links.
+
+ * trace2 streams used to record the URLs that potentially embed
+ authentication material, which has been corrected.
+
+ * The sample pre-commit hook that tries to catch introduction of new
+ paths that use potentially non-portable characters did not notice
+ an existing path getting renamed to such a problematic path, when
+ rename detection was enabled.
+
+ * The command line parser for the "log" family of commands was too
+ loose when parsing certain numbers, e.g., silently ignoring the
+ extra 'q' in "git log -n 1q" without complaining, which has been
+ tightened up.
+
+ * "git $cmd --end-of-options --rev -- --path" for some $cmd failed
+ to interpret "--rev" as a rev, and "--path" as a path. This was
+ fixed for many programs like "reset" and "checkout".
+
+ * "git bisect reset" has been taught to clean up state files and refs
+ even when BISECT_START file is gone.
+
+ * Some codepaths did not correctly parse configuration variables
+ specified with valueless "true", which has been corrected.
+
+ * Code clean-up for sanity checking of command line options for "git
+ show-ref".
+
+ * The code to parse the From e-mail header has been updated to avoid
+ recursion.
+
+ * "git fetch --atomic" issued an unnecessary empty error message,
+ which has been corrected.
+
+ * Command line completion script (in contrib/) learned to work better
+ with the reftable backend.
+
+ * "git status" is taught to show both the branch being bisected and
+ being rebased when both are in effect at the same time.
+ cf. <xmqqil76kyov.fsf@gitster.g>
+
+ * "git archive --list extra garbage" silently ignored excess command
+ line parameters, which has been corrected.
+
+ * "git sparse-checkout set" added default patterns even when the
+ patterns are being fed from the standard input, which has been
+ corrected.
+
+ * Unlike other environment variables that took the usual
+ true/false/yes/no as well as 0/1, GIT_FLUSH only understood 0/1,
+ which has been corrected.
+
+ * Clearing in-core repository (happens during e.g., "git fetch
+ --recurse-submodules" with commit graph enabled) made in-core
+ commit object in an inconsistent state by discarding the necessary
+ data from commit-graph too early, which has been corrected.
+
+Also contains various documentation updates, code clean-ups and minor fixups.
diff --git a/RelNotes/2.43.2.adoc b/RelNotes/2.43.2.adoc
new file mode 100644
index 0000000..5895e23
--- /dev/null
+++ b/RelNotes/2.43.2.adoc
@@ -0,0 +1,37 @@
+Git 2.43.2 Release Notes
+========================
+
+Relative to Git 2.43.1, this release has two important fixes to allow
+"git imap-send" to be built with NO_CURL defined, and to restore the
+forced flushing behaviour when GIT_FLUSH=1 is set. It also contains
+other, unexciting, fixes that have already been merged to the 'master'
+branch of the development towards the next major release.
+
+Fixes since Git 2.43.1
+----------------------
+
+ * Update to a new feature recently added, "git show-ref --exists".
+
+ * Rename detection logic ignored the final line of a file if it is an
+ incomplete line.
+
+ * "git diff --no-rename A B" did not disable rename detection but did
+ not trigger an error from the command line parser.
+
+ * "git diff --no-index file1 file2" segfaulted while invoking the
+ external diff driver, which has been corrected.
+
+ * Rewrite //-comments to /* comments */ in files whose comments
+ prevalently use the latter.
+
+ * A failed "git tag -s" did not necessarily result in an error
+ depending on the crypto backend, which has been corrected.
+
+ * "git stash" sometimes was silent even when it failed due to
+ unwritable index file, which has been corrected.
+
+ * Recent conversion to allow more than 0/1 in GIT_FLUSH broke the
+ mechanism by flipping what yes/no means by mistake, which has been
+ corrected.
+
+Also contains documentation updates, code clean-ups and minor fixups.
diff --git a/RelNotes/2.43.3.adoc b/RelNotes/2.43.3.adoc
new file mode 100644
index 0000000..924f205
--- /dev/null
+++ b/RelNotes/2.43.3.adoc
@@ -0,0 +1,12 @@
+Git 2.43.3 Release Notes
+========================
+
+Relative to Git 2.43.2, this release fixes one regression that
+manifests while running "git commit -v --trailer".
+
+Fixes since Git 2.43.2
+----------------------
+
+ * "git commit -v --trailer=..." was broken with recent update and
+ placed the trailer _after_ the divider line, which has been
+ corrected.
diff --git a/RelNotes/2.43.4.adoc b/RelNotes/2.43.4.adoc
new file mode 100644
index 0000000..0a84251
--- /dev/null
+++ b/RelNotes/2.43.4.adoc
@@ -0,0 +1,7 @@
+Git v2.43.4 Release Notes
+=========================
+
+This release merges up the fix that appears in v2.39.4, v2.40.2,
+v2.41.1 and v2.42.2 to address the security issues CVE-2024-32002,
+CVE-2024-32004, CVE-2024-32020, CVE-2024-32021 and CVE-2024-32465;
+see the release notes for these versions for details.
diff --git a/RelNotes/2.43.5.adoc b/RelNotes/2.43.5.adoc
new file mode 100644
index 0000000..236b234
--- /dev/null
+++ b/RelNotes/2.43.5.adoc
@@ -0,0 +1,26 @@
+Git v2.43.5 Release Notes
+=========================
+
+In preparing security fixes for four CVEs, we made overly aggressive
+"defense in depth" changes that broke legitimate use cases like 'git
+lfs' and 'git annex.' This release is to revert these misguided, if
+well-intentioned, changes that were shipped in 2.43.4 and were not
+direct security fixes.
+
+Jeff King (5):
+ send-email: drop FakeTerm hack
+ send-email: avoid creating more than one Term::ReadLine object
+ ci: drop mention of BREW_INSTALL_PACKAGES variable
+ ci: avoid bare "gcc" for osx-gcc job
+ ci: stop installing "gcc-13" for osx-gcc
+
+Johannes Schindelin (6):
+ hook: plug a new memory leak
+ init: use the correct path of the templates directory again
+ Revert "core.hooksPath: add some protection while cloning"
+ tests: verify that `clone -c core.hooksPath=/dev/null` works again
+ clone: drop the protections where hooks aren't run
+ Revert "Add a helper function to compare file contents"
+
+Junio C Hamano (1):
+ Revert "fsck: warn about symlink pointing inside a gitdir"
diff --git a/RelNotes/2.43.6.adoc b/RelNotes/2.43.6.adoc
new file mode 100644
index 0000000..2114b9f
--- /dev/null
+++ b/RelNotes/2.43.6.adoc
@@ -0,0 +1,7 @@
+Git v2.43.6 Release Notes
+=========================
+
+This release merges up the fix that appears in v2.40.4, v2.41.3
+and v2.42.4 to address the security issues CVE-2024-50349 and
+CVE-2024-52006; see the release notes for these versions for
+details.
diff --git a/RelNotes/2.44.0.adoc b/RelNotes/2.44.0.adoc
new file mode 100644
index 0000000..14f9ce8
--- /dev/null
+++ b/RelNotes/2.44.0.adoc
@@ -0,0 +1,334 @@
+Git v2.44 Release Notes
+=======================
+
+Backward Compatibility Notes
+
+ * "git checkout -B <branch>" used to allow switching to a branch that
+ is in use on another worktree, but this was by mistake. The users
+ need to use "--ignore-other-worktrees" option.
+
+
+UI, Workflows & Features
+
+ * "git add" and "git stash" learned to support the ":(attr:...)"
+ magic pathspec.
+
+ * "git rebase --autosquash" is now enabled for non-interactive rebase,
+ but it is still incompatible with the apply backend.
+
+ * Introduce "git replay", a tool meant on the server side without
+ working tree to recreate a history.
+
+ * "git merge-file" learned to take the "--diff-algorithm" option to
+ use algorithm different from the default "myers" diff.
+
+ * Command line completion (in contrib/) learned to complete path
+ arguments to the "add/set" subcommands of "git sparse-checkout"
+ better.
+
+ * "git checkout -B <branch> [<start-point>]" allowed a branch that is
+ in use in another worktree to be updated and checked out, which
+ might be a bit unexpected. The rule has been tightened, which is a
+ breaking change. "--ignore-other-worktrees" option is required to
+ unbreak you, if you are used to the current behaviour that "-B"
+ overrides the safety.
+
+ * The builtin_objectmode attribute is populated for each path
+ without adding anything in .gitattributes files, which would be
+ useful in magic pathspec, e.g., ":(attr:builtin_objectmode=100755)"
+ to limit to executables.
+
+ * "git fetch" learned to pay attention to "fetch.all" configuration
+ variable, which pretends as if "--all" was passed from the command
+ line when no remote parameter was given.
+
+ * In addition to (rather cryptic) Security Identifiers, show username
+ and domain in the error message when we barf on mismatch between
+ the Git directory and the current user on Windows.
+
+ * The error message given when "git branch -d branch" fails due to
+ commits unique to the branch has been split into an error and a new
+ conditional advice message.
+
+ * When given an existing but unreadable file as a configuration file,
+ gitweb behaved as if the file did not exist at all, but now it
+ errors out. This is a change that may break backward compatibility.
+
+ * When $HOME/.gitconfig is missing but XDG config file is available, we
+ should write into the latter, not former. "git gc" and "git
+ maintenance" wrote into a wrong "global config" file, which have
+ been corrected.
+
+ * Define "special ref" as a very narrow set that consists of
+ FETCH_HEAD and MERGE_HEAD, and clarify everything else that used to
+ be classified as such are actually just pseudorefs.
+
+ * All conditional "advice" messages show how to turn them off, which
+ becomes repetitive. Setting advice.* configuration explicitly on
+ now omits the instruction part.
+
+ * The "disable repository discovery of a bare repository" check,
+ triggered by setting safe.bareRepository configuration variable to
+ 'explicit', has been loosened to exclude the ".git/" directory inside
+ a non-bare repository from the check. So you can do "cd .git &&
+ git cmd" to run a Git command that works on a bare repository without
+ explicitly specifying $GIT_DIR now.
+
+ * The completion script (in contrib/) learned more options that can
+ be used with "git log".
+
+ * The labels on conflict markers for the common ancestor, our version,
+ and the other version are available to custom 3-way merge driver
+ via %S, %X, and %Y placeholders.
+
+ * The write codepath for the reftable data learned to honor
+ core.fsync configuration.
+
+ * The "--fsck-objects" option of "git index-pack" now can take the
+ optional parameter to tweak severity of different fsck errors.
+
+ * The wincred credential backend has been taught to support oauth
+ refresh token the same way as credential-cache and
+ credential-libsecret backends.
+
+ * Command line completion support (in contrib/) has been
+ updated for "git bisect".
+
+ * "git branch" and friends learned to use the formatted text as
+ sorting key, not the underlying timestamp value, when the --sort
+ option is used with author or committer timestamp with a format
+ specifier (e.g., "--sort=creatordate:format:%H:%M:%S").
+
+ * The command line completion script (in contrib/) learned to
+ complete configuration variable names better.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * Process to add some form of low-level unit tests has started.
+
+ * Add support for GitLab CI.
+
+ * "git for-each-ref --no-sort" still sorted the refs alphabetically
+ which paid non-trivial cost. It has been redefined to show output
+ in an unspecified order, to allow certain optimizations to take
+ advantage of.
+
+ * Simplify API implementation to delete references by eliminating
+ duplication.
+
+ * Subject approxidate() and show_date() machinery to OSS-Fuzz.
+
+ * A new helper to let us pretend that we called lstat() when we know
+ our cache_entry is up-to-date via fsmonitor.
+
+ * The optimization based on fsmonitor in the "diff --cached"
+ codepath is resurrected with the "fake-lstat" introduced earlier.
+
+ * Test balloon to use C99 "bool" type from <stdbool.h> has been
+ added.
+
+ * "git clone" has been prepared to allow cloning a repository with
+ non-default hash function into a repository that uses the reftable
+ backend.
+
+ * Streaming spans of packfile data used to be done only from a
+ single, primary, pack in a repository with multiple packfiles. It
+ has been extended to allow reuse from other packfiles, too.
+
+ * Comment updates to help developers not to attempt to modify
+ messages from plumbing commands that must stay constant.
+
+ It might make sense to reassess the plumbing needs every few years,
+ but that should be done as a separate effort.
+
+ * Move test-ctype helper to the unit-test framework.
+
+ * Instead of manually creating refs/ hierarchy on disk upon a
+ creation of a secondary worktree, which is only usable via the
+ files backend, use the refs API to populate it.
+
+ * CI for GitLab learned to drive macOS jobs.
+
+ * A few tests to "git commit -o <pathspec>" and "git commit -i
+ <pathspec>" has been added.
+
+ * Tests on ref API are moved around to prepare for reftable.
+
+ * The Makefile often had to say "-L$(path) -R$(path)" that repeats
+ the path to the same library directory for link time and runtime.
+ A Makefile template is used to reduce such repetition.
+
+ * The priority queue test has been migrated to the unit testing
+ framework.
+
+ * Setting `feature.experimental` opts the user into multi-pack reuse
+ experiment
+
+ * Squelch node.js 16 deprecation warnings from GitHub Actions CI
+ by updating actions/github-script and actions/checkout that use
+ node.js 20.
+
+ * The mechanism to report the filename in the source code, used by
+ the unit-test machinery, assumed that the compiler expanded __FILE__
+ to the path to the source given to the $(CC), but some compilers
+ give full path, breaking the output. This has been corrected.
+
+
+Fixes since v2.43
+-----------------
+
+ * The way CI testing used "prove" could lead to running the test
+ suite twice needlessly, which has been corrected.
+
+ * Update ref-related tests.
+
+ * "git format-patch --encode-email-headers" ignored the option when
+ preparing the cover letter, which has been corrected.
+
+ * Newer versions of Getopt::Long started giving warnings against our
+ (ab)use of it in "git send-email". Bump the minimum version
+ requirement for Perl to 5.8.1 (from September 2002) to allow
+ simplifying our implementation.
+
+ * Earlier we stopped relying on commit-graph that (still) records
+ information about commits that are lost from the object store,
+ which has negative performance implications. The default has been
+ flipped to disable this pessimization.
+
+ * Stale URLs have been updated to their current counterparts (or
+ archive.org) and HTTP links are replaced with working HTTPS links.
+
+ * trace2 streams used to record the URLs that potentially embed
+ authentication material, which has been corrected.
+
+ * The sample pre-commit hook that tries to catch introduction of new
+ paths that use potentially non-portable characters did not notice
+ an existing path getting renamed to such a problematic path, when
+ rename detection was enabled.
+
+ * The command line parser for the "log" family of commands was too
+ loose when parsing certain numbers, e.g., silently ignoring the
+ extra 'q' in "git log -n 1q" without complaining, which has been
+ tightened up.
+
+ * "git $cmd --end-of-options --rev -- --path" for some $cmd failed
+ to interpret "--rev" as a rev, and "--path" as a path. This was
+ fixed for many programs like "reset" and "checkout".
+
+ * "git bisect reset" has been taught to clean up state files and refs
+ even when BISECT_START file is gone.
+
+ * Some codepaths did not correctly parse configuration variables
+ specified with valueless "true", which has been corrected.
+
+ * Code clean-up for sanity checking of command line options for "git
+ show-ref".
+
+ * The code to parse the From e-mail header has been updated to avoid
+ recursion.
+
+ * "git fetch --atomic" issued an unnecessary empty error message,
+ which has been corrected.
+
+ * Command line completion script (in contrib/) learned to work better
+ with the reftable backend.
+
+ * "git status" is taught to show both the branch being bisected and
+ being rebased when both are in effect at the same time.
+
+ * "git archive --list extra garbage" silently ignored excess command
+ line parameters, which has been corrected.
+
+ * "git sparse-checkout set" added default patterns even when the
+ patterns are being fed from the standard input, which has been
+ corrected.
+
+ * "git sparse-checkout (add|set) --[no-]cone --end-of-options" did
+ not handle "--end-of-options" correctly after a recent update.
+
+ * Unlike other environment variables that took the usual
+ true/false/yes/no as well as 0/1, GIT_FLUSH only understood 0/1,
+ which has been corrected.
+
+ * Clearing in-core repository (happens during e.g., "git fetch
+ --recurse-submodules" with commit graph enabled) made in-core
+ commit object in an inconsistent state by discarding the necessary
+ data from commit-graph too early, which has been corrected.
+
+ * Update to a new feature recently added, "git show-ref --exists".
+
+ * oss-fuzz tests are built and run in CI.
+ (merge c4a9cf1df3 js/oss-fuzz-build-in-ci later to maint).
+
+ * Rename detection logic ignored the final line of a file if it is an
+ incomplete line.
+
+ * GitHub CI update.
+ (merge 0188b2c8e0 pb/ci-github-skip-logs-for-broken-tests later to maint).
+
+ * "git diff --no-rename A B" did not disable rename detection but did
+ not trigger an error from the command line parser.
+
+ * "git archive --remote=<remote>" learned to talk over the smart
+ http (aka stateless) transport.
+ (merge 176cd68634 jx/remote-archive-over-smart-http later to maint).
+
+ * Fetching via protocol v0 over Smart HTTP transport sometimes failed
+ to correctly auto-follow tags.
+ (merge fba732c462 jk/fetch-auto-tag-following-fix later to maint).
+
+ * The documentation for the --exclude-per-directory option marked it
+ as deprecated, which confused readers into thinking there may be a
+ plan to remove it in the future, which was not our intention.
+ (merge 0009542cab jc/ls-files-doc-update later to maint).
+
+ * "git diff --no-index file1 file2" segfaulted while invoking the
+ external diff driver, which has been corrected.
+
+ * Rewrite //-comments to /* comments */ in files whose comments
+ prevalently use the latter.
+
+ * Cirrus CI jobs started breaking because we specified version of
+ FreeBSD that is no longer available, which has been corrected.
+ (merge 81fffb66d3 cb/use-freebsd-13-2-at-cirrus-ci later to maint).
+
+ * A caller called index_file_exists() that takes a string expressed
+ as <ptr, length> with a wrong length, which has been corrected.
+ (merge 156e28b36d jh/sparse-index-expand-to-path-fix later to maint).
+
+ * A failed "git tag -s" did not necessarily result in an error
+ depending on the crypto backend, which has been corrected.
+
+ * "git stash" sometimes was silent even when it failed due to
+ unwritable index file, which has been corrected.
+
+ * "git show-ref --verify" did not show things like "CHERRY_PICK_HEAD",
+ which has been corrected.
+
+ * Recent conversion to allow more than 0/1 in GIT_FLUSH broke the
+ mechanism by flipping what yes/no means by mistake, which has been
+ corrected.
+
+ * The sequencer machinery does not use the ref API and instead
+ records names of certain objects it needs for its correct operation
+ in temporary files, which makes these objects susceptible to loss
+ by garbage collection. These temporary files have been added as
+ starting points for reachability analysis to fix this.
+ (merge bc7f5db896 pw/gc-during-rebase later to maint).
+
+ * "git cherry-pick" invoked during "git rebase -i" session lost
+ the authorship information, which has been corrected.
+ (merge e4301f73ff vn/rebase-with-cherry-pick-authorship later to maint).
+
+ * The code paths that call repo_read_object_file() have been
+ tightened to react to errors.
+ (merge 568459bf5e js/check-null-from-read-object-file later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge 5aea3955bc rj/clarify-branch-doc-m later to maint).
+ (merge 9cce3be2df bk/bisect-doc-fix later to maint).
+ (merge 8430b438f6 vd/fsck-submodule-url-test later to maint).
+ (merge 3cb4384683 jc/t0091-with-unknown-git later to maint).
+ (merge 020456cb74 rs/receive-pack-remove-find-header later to maint).
+ (merge bc47139f4f la/trailer-cleanups later to maint).
diff --git a/RelNotes/2.44.1.adoc b/RelNotes/2.44.1.adoc
new file mode 100644
index 0000000..b5135c3
--- /dev/null
+++ b/RelNotes/2.44.1.adoc
@@ -0,0 +1,8 @@
+Git v2.44.1 Release Notes
+=========================
+
+This release merges up the fix that appears in v2.39.4, v2.40.2,
+v2.41.1, v2.42.2 and v2.43.4 to address the security issues
+CVE-2024-32002, CVE-2024-32004, CVE-2024-32020, CVE-2024-32021
+and CVE-2024-32465; see the release notes for these versions
+for details.
diff --git a/RelNotes/2.44.2.adoc b/RelNotes/2.44.2.adoc
new file mode 100644
index 0000000..76700f0
--- /dev/null
+++ b/RelNotes/2.44.2.adoc
@@ -0,0 +1,26 @@
+Git v2.44.2 Release Notes
+=========================
+
+In preparing security fixes for four CVEs, we made overly aggressive
+"defense in depth" changes that broke legitimate use cases like 'git
+lfs' and 'git annex.' This release is to revert these misguided, if
+well-intentioned, changes that were shipped in 2.44.1 and were not
+direct security fixes.
+
+Jeff King (5):
+ send-email: drop FakeTerm hack
+ send-email: avoid creating more than one Term::ReadLine object
+ ci: drop mention of BREW_INSTALL_PACKAGES variable
+ ci: avoid bare "gcc" for osx-gcc job
+ ci: stop installing "gcc-13" for osx-gcc
+
+Johannes Schindelin (6):
+ hook: plug a new memory leak
+ init: use the correct path of the templates directory again
+ Revert "core.hooksPath: add some protection while cloning"
+ tests: verify that `clone -c core.hooksPath=/dev/null` works again
+ clone: drop the protections where hooks aren't run
+ Revert "Add a helper function to compare file contents"
+
+Junio C Hamano (1):
+ Revert "fsck: warn about symlink pointing inside a gitdir"
diff --git a/RelNotes/2.44.3.adoc b/RelNotes/2.44.3.adoc
new file mode 100644
index 0000000..5862845
--- /dev/null
+++ b/RelNotes/2.44.3.adoc
@@ -0,0 +1,7 @@
+Git v2.44.3 Release Notes
+=========================
+
+This release merges up the fix that appears in v2.40.4, v2.41.3,
+v2.42.4 and v2.43.6 to address the security issues CVE-2024-50349
+and CVE-2024-52006; see the release notes for these versions
+for details.
diff --git a/RelNotes/2.45.0.adoc b/RelNotes/2.45.0.adoc
new file mode 100644
index 0000000..aa03152
--- /dev/null
+++ b/RelNotes/2.45.0.adoc
@@ -0,0 +1,476 @@
+Git v2.45 Release Notes
+=======================
+
+Backward Compatibility Notes
+
+UI, Workflows & Features
+
+ * Integrate the reftable code into the refs framework as a backend.
+ With "git init --ref-format=reftable", hopefully it would be a lot
+ more efficient to manage a repository with many references.
+
+ * "git checkout -p" and friends learned that "@" is a synonym
+ for "HEAD".
+
+ * Variants of vimdiff learned to honor mergetool.<variant>.layout
+ settings.
+
+ * "git reflog" learned a "list" subcommand that enumerates known reflogs.
+
+ * When a merge conflicted at a submodule, merge-ort backend used to
+ unconditionally give a lengthy message to suggest how to resolve
+ it. Now the message can be squelched as an advice message.
+
+ * "git for-each-ref" learned "--include-root-refs" option to show
+ even the stuff outside the 'refs/' hierarchy.
+
+ * "git rev-list --missing=print" has learned to optionally take
+ "--allow-missing-tips", which allows the objects at the starting
+ points to be missing.
+
+ * "git merge-tree" has learned that the three trees involved in the
+ 3-way merge only need to be trees, not necessarily commits.
+
+ * "git log --merge" learned to pay attention to CHERRY_PICK_HEAD and
+ other kinds of *_HEAD pseudorefs.
+
+ * Platform specific tweaks for OS/390 has been added to
+ config.mak.uname.
+
+ * Users with safe.bareRepository=explicit can still work from within
+ $GIT_DIR of a seconary worktree (which resides at .git/worktrees/$name/)
+ of the primary worktree without explicitly specifying the $GIT_DIR
+ environment variable or the --git-dir=<path> option.
+
+ * The output format for dates "iso-strict" has been tweaked to show
+ a time in the Zulu timezone with "Z" suffix, instead of "+00:00".
+
+ * "git diff" and friends learned two extra configuration variables,
+ diff.srcPrefix and diff.dstPrefix.
+
+ * The status.showUntrackedFiles configuration variable had a name
+ that tempts users to set a Boolean value expressed in our usual
+ "false", "off", and "0", but it only took "no". This has been
+ corrected so "true" and its synonyms are taken as "normal", while
+ "false" and its synonyms are taken as "no".
+
+ * Remove an ancient and not well maintained Hg-to-git migration
+ script from contrib/.
+
+ * Hints that suggest what to do after resolving conflicts can now be
+ squelched by disabling advice.mergeConflict.
+
+ * Allow git-cherry-pick(1) to automatically drop redundant commits via
+ a new `--empty` option, similar to the `--empty` options for
+ git-rebase(1) and git-am(1). Includes a soft deprecation of
+ `--keep-redundant-commits` as well as some related docs changes and
+ sequencer code cleanup.
+
+ * "git config" learned "--comment=<message>" option to leave a
+ comment immediately after the "variable = value" on the same line
+ in the configuration file.
+
+ * core.commentChar used to be limited to a single byte, but has been
+ updated to allow an arbitrary multi-byte sequence.
+
+ * "git add -p" and other "interactive hunk selection" UI has learned to
+ skip showing the hunk immediately after it has already been shown, and
+ an additional action to explicitly ask to reshow the current hunk.
+
+ * "git pack-refs" learned the "--auto" option, which defers the decision of
+ whether and how to pack to the ref backend. This is used by the reftable
+ backend to avoid repacking of an already-optimal ref database. The new mode
+ is triggered from "git gc --auto".
+
+ * "git add -u <pathspec>" and "git commit [-i] <pathspec>" did not
+ diagnose a pathspec element that did not match any files in certain
+ situations, unlike "git add <pathspec>" did.
+
+ * The userdiff patterns for C# has been updated.
+
+ * Git writes a "waiting for your editor" message on an incomplete
+ line after launching an editor, and then append another error
+ message on the same line if the editor errors out. It now clears
+ the "waiting for..." line before giving the error message.
+
+ * The filename used for rejected hunks "git apply --reject" creates
+ was limited to PATH_MAX, which has been lifted.
+
+ * When "git bisect" reports the commit it determined to be the
+ culprit, we used to show it in a format that does not honor common
+ UI tweaks, like log.date and log.decorate. The code has been
+ taught to use "git show" to follow more customizations.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * The code to iterate over refs with the reftable backend has seen
+ some optimization.
+
+ * More tests that are marked as "ref-files only" have been updated to
+ improve test coverage of reftable backend.
+
+ * Some parts of command line completion script (in contrib/) have
+ been micro-optimized.
+
+ * The way placeholders are to be marked-up in documentation have been
+ specified; use "_<placeholder>_" to typeset the word inside a pair
+ of <angle-brackets> emphasized.
+
+ * "git --no-lazy-fetch cmd" allows to run "cmd" while disabling lazy
+ fetching of objects from the promisor remote, which may be handy
+ for debugging.
+
+ * The implementation in "git clean" that makes "-n" and "-i" ignore
+ clean.requireForce has been simplified, together with the
+ documentation.
+
+ * Uses of xwrite() helper have been audited and updated for better
+ error checking and simpler code.
+
+ * Some trace2 events that lacked def_param have learned to show it,
+ enriching the output.
+
+ * The parse-options code that deals with abbreviated long option
+ names have been cleaned up.
+
+ * The code in reftable backend that creates new table files works
+ better with the tempfile framework to avoid leaving cruft after a
+ failure.
+
+ * The reftable code has its own custom binary search function whose
+ comparison callback has an unusual interface, which caused the
+ binary search to degenerate into a linear search, which has been
+ corrected.
+
+ * The code to iterate over reflogs in the reftable has been optimized
+ to reduce memory allocation and deallocation.
+
+ * Work to support a repository that work with both SHA-1 and SHA-256
+ hash algorithms has started.
+
+ * A new fuzz target that exercises config parsing code has been
+ added.
+
+ * Fix the way recently added tests interpolate variables defined
+ outside them, and document the best practice to help future
+ developers.
+
+ * Introduce an experimental protocol for contributors to propose the
+ topic description to be used in the "What's cooking" report, the
+ merge commit message for the topic, and in the release notes and
+ document it in the SubmittingPatches document.
+
+ * The t/README file now gives a hint on running individual tests in
+ the "t/" directory with "make t<num>-*.sh t<num>-*.sh".
+ (merge 8d383806fc pb/test-scripts-are-build-targets later to maint).
+
+ * The "hint:" messages given by the advice mechanism, when given a
+ message with a blank line, left a line with trailing whitespace,
+ which has been cleansed.
+
+ * Documentation rules has been explicitly described how to mark-up
+ literal parts and a few manual pages have been updated as examples.
+
+ * The .editorconfig file has been taught that a Makefile uses HT
+ indentation.
+
+ * t-prio-queue test has been cleaned up by using C99 compound
+ literals; this is meant to also serve as a weather-balloon to smoke
+ out folks with compilers who have trouble compiling code that uses
+ the feature.
+
+ * Windows binary used to decide the use of unix-domain socket at
+ build time, but it learned to make the decision at runtime instead.
+
+ * The "shared repository" test in the t0610 reftable test failed
+ under restrictive umask setting (e.g. 007), which has been
+ corrected.
+
+ * Document and apply workaround for a buggy version of dash that
+ mishandles "local var=val" construct.
+
+ * The codepaths that reach date_mode_from_type() have been updated to
+ pass "struct date_mode" by value to make them thread safe.
+
+ * The strategy to compact multiple tables of reftables after many
+ operations accumulate many entries has been improved to avoid
+ accumulating too many tables uncollected.
+
+ * The code to iterate over reftable blocks has seen some optimization
+ to reduce memory allocation and deallocation.
+
+ * The way "git fast-import" handles paths described in its input has
+ been tightened up and more clearly documented.
+
+ * The cvsimport tests required that the platform understands
+ traditional timezone notations like CST6CDT, which has been
+ updated to work on those systems as long as they understand
+ POSIX notation with explicit tz transition dates.
+
+ * The code to format trailers have been cleaned up.
+
+
+Fixes since v2.44
+-----------------
+
+ * "git apply" on a filesystem without filemode support have learned
+ to take a hint from what is in the index for the path, even when
+ not working with the "--index" or "--cached" option, when checking
+ the executable bit match what is required by the preimage in the
+ patch.
+ (merge 45b625142d cp/apply-core-filemode later to maint).
+
+ * "git column" has been taught to reject negative padding value, as
+ it would lead to nonsense behaviour including division by zero.
+ (merge 76fb807faa kh/column-reject-negative-padding later to maint).
+
+ * "git am --help" now tells readers what actions are available in
+ "git am --whitespace=<action>", in addition to saying that the
+ option is passed through to the underlying "git apply".
+ (merge a171dac734 jc/am-whitespace-doc later to maint).
+
+ * "git tag --column" failed to check the exit status of its "git
+ column" invocation, which has been corrected.
+ (merge 92e66478fc rj/tag-column-fix later to maint).
+
+ * Credential helper based on libsecret (in contrib/) has been updated
+ to handle an empty password correctly.
+ (merge 8f1f2023b7 mh/libsecret-empty-password-fix later to maint).
+
+ * "git difftool --dir-diff" learned to honor the "--trust-exit-code"
+ option; it used to always exit with 0 and signalled success.
+ (merge eb84c8b6ce ps/difftool-dir-diff-exit-code later to maint).
+
+ * The code incorrectly attempted to use textconv cache when asked,
+ even when we are not running in a repository, which has been
+ corrected.
+ (merge affe355fe7 jk/textconv-cache-outside-repo-fix later to maint).
+
+ * Remove an empty file that shouldn't have been added in the first
+ place.
+ (merge 4f66942215 js/remove-cruft-files later to maint).
+
+ * The logic to access reflog entries by date and number had ugly
+ corner cases at the boundaries, which have been cleaned up.
+ (merge 5edd126720 jk/reflog-special-cases-fix later to maint).
+
+ * An error message from "git upload-pack", which responds to "git
+ fetch" requests, had a trailing NUL in it, which has been
+ corrected.
+ (merge 3f4c7a0805 sg/upload-pack-error-message-fix later to maint).
+
+ * Clarify wording in the CodingGuidelines that requires <git-compat-util.h>
+ to be the first header file.
+ (merge 4e89f0e07c jc/doc-compat-util later to maint).
+
+ * "git commit -v --cleanup=scissors" used to add the scissors line
+ twice in the log message buffer, which has been corrected.
+ (merge e90cc075cc jt/commit-redundant-scissors-fix later to maint).
+
+ * A custom remote helper no longer cannot access the newly created
+ repository during "git clone", which is a regression in Git 2.44.
+ This has been corrected.
+ (merge 199f44cb2e ps/remote-helper-repo-initialization-fix later to maint).
+
+ * Various parts of upload-pack have been updated to bound the resource
+ consumption relative to the size of the repository to protect from
+ abusive clients.
+ (merge 6cd05e768b jk/upload-pack-bounded-resources later to maint).
+
+ * The upload-pack program, when talking over v2, accepted the
+ packfile-uris protocol extension from the client, even if it did
+ not advertise the capability, which has been corrected.
+ (merge a922bfa3b5 jk/upload-pack-v2-capability-cleanup later to maint).
+
+ * Make sure failure return from merge_bases_many() is properly caught.
+ (merge 25fd20eb44 js/merge-base-with-missing-commit later to maint).
+
+ * FSMonitor client code was confused when FSEvents were given in a
+ different case on a case-insensitive filesystem, which has been
+ corrected.
+ (merge 29c139ce78 jh/fsmonitor-icase-corner-case-fix later to maint).
+
+ * The "core.commentChar" configuration variable only allows an ASCII
+ character, which was not clearly documented, which has been
+ corrected.
+ (merge fb7c556f58 kh/doc-commentchar-is-a-byte later to maint).
+
+ * With release 2.44 we got rid of all uses of test_i18ngrep and there
+ is no in-flight topic that adds a new use of it. Make a call to
+ test_i18ngrep a hard failure, so that we can remove it at the end
+ of this release cycle.
+ (merge 381a83dfa3 jc/test-i18ngrep later to maint).
+
+ * The command line completion script (in contrib/) learned to
+ complete "git reflog" better.
+ (merge 1284f9cc11 rj/complete-reflog later to maint).
+
+ * The logic to complete the command line arguments to "git worktree"
+ subcommand (in contrib/) has been updated to correctly honor things
+ like "git -C dir" etc.
+ (merge 3574816d98 rj/complete-worktree-paths-fix later to maint).
+
+ * When git refuses to create a branch because the proposed branch
+ name is not a valid refname, an advice message is given to refer
+ the user to exact naming rules.
+ (merge 8fbd903e58 kh/branch-ref-syntax-advice later to maint).
+
+ * Code simplification by getting rid of code that sets an environment
+ variable that is no longer used.
+ (merge 72a8d3f027 pw/rebase-i-ignore-cherry-pick-help-environment later to maint).
+
+ * The code to find the effective end of log messages can fall into an
+ endless loop, which has been corrected.
+ (merge 2541cba2d6 fs/find-end-of-log-message-fix later to maint).
+
+ * Mark-up used in the documentation has been improved for
+ consistency.
+ (merge 45d5ed3e50 ja/doc-markup-fixes later to maint).
+
+ * The status.showUntrackedFiles configuration variable was
+ incorrectly documented to accept "false", which has been corrected.
+
+ * Leaks from "git restore" have been plugged.
+ (merge 2f64da0790 rj/restore-plug-leaks later to maint).
+
+ * "git bugreport --no-suffix" was not supported and instead
+ segfaulted, which has been corrected.
+ (merge b3b57c69da js/bugreport-no-suffix-fix later to maint).
+
+ * The documentation for "%(trailers[:options])" placeholder in the
+ "--pretty" option of commands in the "git log" family has been
+ updated.
+ (merge bff85a338c bl/doc-key-val-sep-fix later to maint).
+
+ * "git checkout --conflict=bad" reported a bad conflictStyle as if it
+ were given to a configuration variable; it has been corrected to
+ report that the command line option is bad.
+ (merge 5a99c1ac1a pw/checkout-conflict-errorfix later to maint).
+
+ * Code clean-up in the "git log" machinery that implements custom log
+ message formatting.
+ (merge 1c10b8e5b0 jk/pretty-subject-cleanup later to maint).
+
+ * "git config" corrupted literal HT characters written in the
+ configuration file as part of a value, which has been corrected.
+ (merge e6895c3f97 ds/config-internal-whitespace-fix later to maint).
+
+ * A unit test for reftable code tried to enumerate all files in a
+ directory after reftable operations and expected to see nothing but
+ the files it wanted to leave there, but was fooled by .nfs* cruft
+ files left, which has been corrected.
+ (merge 0068aa7946 ps/reftable-unit-test-nfs-workaround later to maint).
+
+ * The implementation and documentation of "object-format" option
+ exchange between the Git itself and its remote helpers did not
+ quite match, which has been corrected.
+
+ * The "--pretty=<shortHand>" option of the commands in the "git log"
+ family, defined as "[pretty] shortHand = <expansion>" should have
+ been looked up case insensitively, but was not, which has been
+ corrected.
+ (merge f999d5188b bl/pretty-shorthand-config-fix later to maint).
+
+ * "git apply" failed to extract the filename the patch applied to,
+ when the change was about an empty file created in or deleted from
+ a directory whose name ends with a SP, which has been corrected.
+ (merge 776ffd1a30 jc/apply-parse-diff-git-header-names-fix later to maint).
+
+ * Update a more recent tutorial doc.
+ (merge 95ab557b4b dg/myfirstobjectwalk-updates later to maint).
+
+ * The test script had an incomplete and ineffective attempt to avoid
+ clobbering the testing user's real crontab (and its equivalents),
+ which has been completed.
+ (merge 73cb87773b es/test-cron-safety later to maint).
+
+ * Use advice_if_enabled() API to rewrite a simple pattern to
+ call advise() after checking advice_enabled().
+ (merge 6412d01527 rj/use-adv-if-enabled later to maint).
+
+ * Another "set -u" fix for the bash prompt (in contrib/) script.
+ (merge d7805bc743 vs/complete-with-set-u-fix later to maint).
+
+ * "git checkout/switch --detach foo", after switching to the detached
+ HEAD state, gave the tracking information for the 'foo' branch,
+ which was pointless.
+
+ * "git apply" has been updated to lift the hardcoded pathname length
+ limit, which in turn allowed a mksnpath() function that is no
+ longer used.
+ (merge 708f7e0590 rs/apply-lift-path-length-limit later to maint).
+
+ * A file descriptor leak in an error codepath, used when "git apply
+ --reject" fails to create the *.rej file, has been corrected.
+ (merge 2b1f456adf rs/apply-reject-fd-leakfix later to maint).
+
+ * A config parser callback function fell through instead of returning
+ after recognising and processing a variable, wasting cycles, which
+ has been corrected.
+ (merge a816ccd642 ds/fetch-config-parse-microfix later to maint).
+
+ * Fix was added to work around a regression in libcURL 8.7.0 (which has
+ already been fixed in their tip of the tree).
+ (merge 92a209bf24 jk/libcurl-8.7-regression-workaround later to maint).
+
+ * The variable that holds the value read from the core.excludefile
+ configuration variable used to leak, which has been corrected.
+ (merge 0e0fefb29f jc/unleak-core-excludesfile later to maint).
+
+ * vreportf(), which is used by error() and friends, has been taught
+ to give the error message printf-format string when its vsnprintf()
+ call fails, instead of showing nothing useful to identify the
+ nature of the error.
+ (merge c63adab961 rs/usage-fallback-to-show-message-format later to maint).
+
+ * Adjust to an upcoming changes to GNU make that breaks our Makefiles.
+ (merge 227b8fd902 tb/make-indent-conditional-with-non-spaces later to maint).
+
+ * Git 2.44 introduced a regression that makes the updated code to
+ barf in repositories with multi-pack index written by older
+ versions of Git, which has been corrected.
+
+ * When .git/rr-cache/ rerere database gets corrupted or rerere is fed to
+ work on a file with conflicted hunks resolved incompletely, the rerere
+ machinery got confused and segfaulted, which has been corrected.
+ (merge 167395bb47 mr/rerere-crash-fix later to maint).
+
+ * The "receive-pack" program (which responds to "git push") was not
+ converted to run "git maintenance --auto" when other codepaths that
+ used to run "git gc --auto" were updated, which has been corrected.
+ (merge 7bf3057d9c ps/run-auto-maintenance-in-receive-pack later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge f0e578c69c rs/use-xstrncmpz later to maint).
+ (merge 83e6eb7d7a ba/credential-test-clean-fix later to maint).
+ (merge 64562d784d jb/doc-interactive-singlekey-do-not-need-perl later to maint).
+ (merge c431a235e2 cp/t9146-use-test-path-helpers later to maint).
+ (merge 82d75402d5 ds/doc-send-email-capitalization later to maint).
+ (merge 41bff66e35 jc/doc-add-placeholder-fix later to maint).
+ (merge 6835f0efe9 jw/remote-doc-typofix later to maint).
+ (merge 244001aa20 hs/rebase-not-in-progress later to maint).
+ (merge 2ca6c07db2 jc/no-include-of-compat-util-from-headers later to maint).
+ (merge 87bd7fbb9c rs/fetch-simplify-with-starts-with later to maint).
+ (merge f39addd0d9 rs/name-rev-with-mempool later to maint).
+ (merge 9a97b43e03 rs/submodule-prefix-simplify later to maint).
+ (merge 40b8076462 ak/rebase-autosquash later to maint).
+ (merge 3223204456 eg/add-uflags later to maint).
+ (merge 5f78d52dce es/config-doc-sort-sections later to maint).
+ (merge 781fb7b4c2 as/option-names-in-messages later to maint).
+ (merge 51d41dc243 jk/doc-remote-helpers-markup-fix later to maint).
+ (merge e1aaf309db pb/ci-win-artifact-names-fix later to maint).
+ (merge ad538c61da jc/index-pack-fsck-levels later to maint).
+ (merge 67471bc704 ja/doc-formatting-fix later to maint).
+ (merge 86f9ce7dd6 bl/doc-config-fixes later to maint).
+ (merge 0d527842b7 az/grep-group-error-message-update later to maint).
+ (merge 7c43bdf07b rs/strbuf-expand-bad-format later to maint).
+ (merge 8b68b48d5c ds/typofix-core-config-doc later to maint).
+ (merge 39bb692152 rs/imap-send-use-xsnprintf later to maint).
+ (merge 8d320cec60 jc/t2104-style-fixes later to maint).
+ (merge b4454d5a7b pw/t3428-cleanup later to maint).
+ (merge 84a7c33a4b pf/commitish-committish later to maint).
+ (merge 8882ee9d68 la/mailmap-entry later to maint).
+ (merge 44bdba2fa6 rs/no-openssl-compilation-fix-on-macos later to maint).
+ (merge f412d72c19 yb/replay-doc-linkfix later to maint).
+ (merge 5da40be8d7 xx/rfc2822-date-format-in-doc later to maint).
diff --git a/RelNotes/2.45.1.adoc b/RelNotes/2.45.1.adoc
new file mode 100644
index 0000000..3b0d60c
--- /dev/null
+++ b/RelNotes/2.45.1.adoc
@@ -0,0 +1,8 @@
+Git v2.45.1 Release Notes
+=========================
+
+This release merges up the fix that appears in v2.39.4,
+v2.40.2, v2.41.1, v2.42.2, v2.43.4 and v2.44.1 to address the
+security issues CVE-2024-32002, CVE-2024-32004, CVE-2024-32020,
+CVE-2024-32021 and CVE-2024-32465; see the release notes for
+these versions for details.
diff --git a/RelNotes/2.45.2.adoc b/RelNotes/2.45.2.adoc
new file mode 100644
index 0000000..13429e6
--- /dev/null
+++ b/RelNotes/2.45.2.adoc
@@ -0,0 +1,26 @@
+Git v2.45.2 Release Notes
+=========================
+
+In preparing security fixes for four CVEs, we made overly aggressive
+"defense in depth" changes that broke legitimate use cases like 'git
+lfs' and 'git annex.' This release is to revert these misguided, if
+well-intentioned, changes that were shipped in 2.45.1 and were not
+direct security fixes.
+
+Jeff King (5):
+ send-email: drop FakeTerm hack
+ send-email: avoid creating more than one Term::ReadLine object
+ ci: drop mention of BREW_INSTALL_PACKAGES variable
+ ci: avoid bare "gcc" for osx-gcc job
+ ci: stop installing "gcc-13" for osx-gcc
+
+Johannes Schindelin (6):
+ hook: plug a new memory leak
+ init: use the correct path of the templates directory again
+ Revert "core.hooksPath: add some protection while cloning"
+ tests: verify that `clone -c core.hooksPath=/dev/null` works again
+ clone: drop the protections where hooks aren't run
+ Revert "Add a helper function to compare file contents"
+
+Junio C Hamano (1):
+ Revert "fsck: warn about symlink pointing inside a gitdir"
diff --git a/RelNotes/2.45.3.adoc b/RelNotes/2.45.3.adoc
new file mode 100644
index 0000000..ddb3cb6
--- /dev/null
+++ b/RelNotes/2.45.3.adoc
@@ -0,0 +1,112 @@
+Git v2.45.3 Release Notes
+=========================
+
+This release merges up the fix that appears in v2.40.4, v2.41.3,
+v2.42.4, v2.43.6 and v2.44.3 to address the security issues
+CVE-2024-50349 and CVE-2024-52006; see the release notes for
+these versions for details.
+
+This version also backports various small fixes accumulated on the
+'master' front during the development towards Git 2.46, the next
+feature release.
+
+
+Fixes since v2.45.2
+-------------------
+
+ * Git-GUI has a new maintainer, Johannes Sixt.
+
+ * Tests that try to corrupt in-repository files in chunked format did
+ not work well on macOS due to its broken "mv", which has been
+ worked around.
+
+ * The maximum size of attribute files is enforced more consistently.
+
+ * Unbreak CI jobs so that we do not attempt to use Python 2 that has
+ been removed from the platform.
+
+ * Git 2.43 started using the tree of HEAD as the source of attributes
+ in a bare repository, which has severe performance implications.
+ For now, revert the change, without ripping out a more explicit
+ support for the attr.tree configuration variable.
+
+ * Windows CI running in GitHub Actions started complaining about the
+ order of arguments given to calloc(); the imported regex code uses
+ the wrong order almost consistently, which has been corrected.
+
+ * The SubmittingPatches document now refers folks to manpages
+ translation project.
+
+ * "git rebase --signoff" used to forget that it needs to add a
+ sign-off to the resulting commit when told to continue after a
+ conflict stops its operation.
+
+ * The procedure to build multi-pack-index got confused by the
+ replace-refs mechanism, which has been corrected by disabling the
+ latter.
+
+ * "git stash -S" did not handle binary files correctly, which has
+ been corrected.
+
+ * A scheduled "git maintenance" job is expected to work on all
+ repositories it knows about, but it stopped at the first one that
+ errored out. Now it keeps going.
+
+ * zsh can pretend to be a normal shell pretty well except for some
+ glitches that we tickle in some of our scripts. Work them around
+ so that "vimdiff" and our test suite works well enough with it.
+
+ * Command line completion support for zsh (in contrib/) has been
+ updated to stop exposing internal state to end-user shell
+ interaction.
+
+ * The documentation for "git diff --name-only" has been clarified
+ that it is about showing the names in the post-image tree.
+
+ * The chainlint script (invoked during "make test") did nothing when
+ it failed to detect the number of available CPUs. It now falls
+ back to 1 CPU to avoid the problem.
+
+ * "git init" in an already created directory, when the user
+ configuration has includeif.onbranch, started to fail recently,
+ which has been corrected.
+
+ * The safe.directory configuration knob has been updated to
+ optionally allow leading path matches.
+
+ * An overly large ".gitignore" files are now rejected silently.
+
+ * Fix for an embarrassing typo that prevented Python2 tests from running
+ anywhere.
+
+ * Varargs functions that are unannotated as printf-like or execl-like
+ have been annotated as such.
+
+ * The "-k" and "--rfc" options of "format-patch" will now error out
+ when used together, as one tells us not to add anything to the
+ title of the commit, and the other one tells us to add "RFC" in
+ addition to "PATCH".
+
+ * When the user adds to "git rebase -i" instruction to "pick" a merge
+ commit, the error experience is not pleasant. Such an error is now
+ caught earlier in the process that parses the todo list.
+
+ * We forgot to normalize the result of getcwd() to NFC on macOS where
+ all other paths are normalized, which has been corrected. This still
+ does not address the case where core.precomposeUnicode configuration
+ is not defined globally.
+
+ * Earlier we stopped using the tree of HEAD as the default source of
+ attributes in a bare repository, but failed to document it. This
+ has been corrected.
+
+ * An unused extern declaration for mingw has been removed to prevent
+ it from causing build failure.
+
+ * A helper function shared between two tests had a copy-paste bug,
+ which has been corrected.
+
+ * "git fetch-pack -k -k" without passing "--lock-pack" (which we
+ never do ourselves) did not work at all, which has been corrected.
+
+Also contains various documentation updates and code clean-ups.
diff --git a/RelNotes/2.46.0.adoc b/RelNotes/2.46.0.adoc
new file mode 100644
index 0000000..c06a04a
--- /dev/null
+++ b/RelNotes/2.46.0.adoc
@@ -0,0 +1,461 @@
+Git v2.46 Release Notes
+=======================
+
+UI, Workflows & Features
+
+ * The "--rfc" option of "git format-patch" learned to take an
+ optional string value to be used in place of "RFC" to tweak the
+ "[PATCH]" on the subject header.
+
+ * The credential helper protocol, together with the HTTP layer, have
+ been enhanced to support authentication schemes different from
+ username & password pair, like Bearer and NTLM.
+
+ * Command line completion script (in contrib/) learned to complete
+ "git symbolic-ref" a bit better (you need to enable plumbing
+ commands to be completed with GIT_COMPLETION_SHOW_ALL_COMMANDS).
+
+ * When the user responds to a prompt given by "git add -p" with an
+ unsupported command, list of available commands were given, which
+ was too much if the user knew what they wanted to type but merely
+ made a typo. Now the user gets a much shorter error message.
+
+ * The color parsing code learned to handle 12-bit RGB colors, spelled
+ as "#RGB" (in addition to "#RRGGBB" that is already supported).
+
+ * The operation mode options (like "--get") the "git config" command
+ uses have been deprecated and replaced with subcommands (like "git
+ config get").
+
+ * "git tag" learned the "--trailer" option to futz with the trailers
+ in the same way as "git commit" does.
+
+ * A new global "--no-advice" option can be used to disable all advice
+ messages, which is meant to be used only in scripts.
+
+ * Updates to symbolic refs can now be made as a part of ref
+ transaction.
+
+ * The trailer API has been reshuffled a bit.
+
+ * Terminology to call various ref-like things are getting
+ straightened out.
+
+ * The command line completion script (in contrib/) has been adjusted
+ to the recent update to "git config" that adopted subcommand based
+ UI.
+
+ * The knobs to tweak how reftable files are written have been made
+ available as configuration variables.
+
+ * When "git push" notices that the commit at the tip of the ref on
+ the other side it is about to overwrite does not exist locally, it
+ used to first try fetching it if the local repository is a partial
+ clone. The command has been taught not to do so and immediately
+ fail instead.
+
+ * The promisor.quiet configuration knob can be set to true to make
+ lazy fetching from promisor remotes silent.
+
+ * The inter/range-diff output has been moved to the end of the patch
+ when format-patch adds it to a single patch, instead of writing it
+ before the patch text, to be consistent with what is done for a
+ cover letter for a multi-patch series.
+
+ * A new command has been added to migrate a repository that uses the
+ files backend for its ref storage to use the reftable backend, with
+ limitations.
+
+ * "git diff --exit-code --ext-diff" learned to take the exit status
+ of the external diff driver into account when deciding the exit
+ status of the overall "git diff" invocation when configured to do
+ so.
+
+ * "git update-ref --stdin" learned to handle transactional updates of
+ symbolic-refs.
+
+ * "git format-patch --interdiff" for multi-patch series learned to
+ turn on cover letters automatically (unless told never to enable
+ cover letter with "--no-cover-letter" and such).
+
+ * The "--heads" option of "ls-remote" and "show-ref" has been
+ deprecated; "--branches" replaces "--heads".
+
+ * For over a year, setting add.interactive.useBuiltin configuration
+ variable did nothing but giving a "this does not do anything"
+ warning. The warning has been removed.
+
+ * The http transport can now be told to send request with
+ authentication material without first getting a 401 response.
+
+ * A handful of entries are added to the GitFAQ document.
+
+ * "git var GIT_SHELL_PATH" should report the path to the shell used
+ to spawn external commands, but it didn't do so on Windows, which
+ has been corrected.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * Advertise "git contacts", a tool for newcomers to find people to
+ ask review for their patches, a bit more in our developer
+ documentation.
+
+ * In addition to building the objects needed, try to link the objects
+ that are used in fuzzer tests, to make sure at least they build
+ without bitrot, in Linux CI runs.
+
+ * Code to write out reftable has seen some optimization and
+ simplification.
+
+ * Tests to ensure interoperability between reftable written by jgit
+ and our code have been added and enabled in CI.
+
+ * The singleton index_state instance "the_index" has been eliminated
+ by always instantiating "the_repository" and replacing references
+ to "the_index" with references to its .index member.
+
+ * Git-GUI has a new maintainer, Johannes Sixt.
+
+ * The "test-tool" has been taught to run testsuite tests in parallel,
+ bypassing the need to use the "prove" tool.
+
+ * The "whitespace check" task that was enabled for GitHub Actions CI
+ has been ported to GitLab CI.
+
+ * The refs API lost functions that implicitly assumes to work on the
+ primary ref_store by forcing the callers to pass a ref_store as an
+ argument.
+
+ * Code clean-up to reduce inter-function communication inside
+ builtin/config.c done via the use of global variables.
+
+ * The pack bitmap code saw some clean-up to prepare for a follow-up topic.
+
+ * Preliminary code clean-up for "git send-email".
+
+ * The default "creation-factor" used by "git format-patch" has been
+ raised to make it more aggressively find matching commits.
+
+ * Before discovering the repository details, We used to assume SHA-1
+ as the "default" hash function, which has been corrected. Hopefully
+ this will smoke out codepaths that rely on such an unwarranted
+ assumptions.
+
+ * The project decision making policy has been documented.
+
+ * The strcmp-offset tests have been rewritten using the unit test
+ framework.
+
+ * "git add -p" learned to complain when an answer with more than one
+ letter is given to a prompt that expects a single letter answer.
+
+ * The alias-expanded command lines are logged to the trace output.
+
+ * A new test was added to ensure git commands that are designed to
+ run outside repositories do work.
+
+ * A few tests in reftable library have been rewritten using the
+ unit test framework.
+
+ * A pair of test helpers that essentially are unit tests on hash
+ algorithms have been rewritten using the unit-tests framework.
+
+ * A test helper that essentially is unit tests on the "decorate"
+ logic has been rewritten using the unit-tests framework.
+
+ * Many memory leaks in the sparse-checkout code paths have been
+ plugged.
+
+ * "make check-docs" noticed problems and reported to its output but
+ failed to signal its findings with its exit status, which has been
+ corrected.
+
+ * Building with "-Werror -Wwrite-strings" is now supported.
+
+ * To help developers, the build procedure now allows builders to use
+ CFLAGS_APPEND to specify additional CFLAGS.
+
+ * "oidtree" tests were rewritten to use the unit test framework.
+
+ * The structure of the document that records longer-term project
+ decisions to deprecate/remove/update various behaviour has been
+ outlined.
+
+ * The pseudo-merge reachability bitmap to help more efficient storage
+ of the reachability bitmap in a repository with too many refs has
+ been added.
+
+ * When "git merge" sees that the index cannot be refreshed (e.g. due
+ to another process doing the same in the background), it died but
+ after writing MERGE_HEAD etc. files, which was useless for the
+ purpose to recover from the failure.
+
+ * The output from "git cat-file --batch-check" and "--batch-command
+ (info)" should not be unbuffered, for which some tests have been
+ added.
+
+ * A CPP macro USE_THE_REPOSITORY_VARIABLE is introduced to help
+ transition the codebase to rely less on the availability of the
+ singleton the_repository instance.
+
+ * "git version --build-options" reports the version information of
+ OpenSSL and other libraries (if used) in the build.
+
+ * Memory ownership rules for the in-core representation of
+ remote.*.url configuration values have been straightened out, which
+ resulted in a few leak fixes and code clarification.
+
+ * When bundleURI interface fetches multiple bundles, Git failed to
+ take full advantage of all bundles and ended up slurping duplicated
+ objects, which has been corrected.
+
+ * The code to deal with modified paths that are out-of-cone in a
+ sparsely checked out working tree has been optimized.
+
+ * An existing test of oidmap API has been rewritten with the
+ unit-test framework.
+
+ * The "ort" merge backend saw one bugfix for a crash that happens
+ when inner merge gets killed, and assorted code clean-ups.
+
+ * A new warning message is issued when a command has to expand a
+ sparse index to handle working tree cruft that are outside of the
+ sparse checkout.
+
+ * The test framework learned to take the test body not as a single
+ string but as a here-document.
+
+ * "git push '' HEAD:there" used to hit a BUG(); it has been corrected
+ to die with "fatal: bad repository ''".
+
+ * What happens when http.cookieFile gets the special value "" has
+ been clarified in the documentation.
+
+
+Fixes since v2.45
+-----------------
+
+ * "git rebase --signoff" used to forget that it needs to add a
+ sign-off to the resulting commit when told to continue after a
+ conflict stops its operation.
+
+ * The procedure to build multi-pack-index got confused by the
+ replace-refs mechanism, which has been corrected by disabling the
+ latter.
+
+ * The "-k" and "--rfc" options of "format-patch" will now error out
+ when used together, as one tells us not to add anything to the
+ title of the commit, and the other one tells us to add "RFC" in
+ addition to "PATCH".
+
+ * "git stash -S" did not handle binary files correctly, which has
+ been corrected.
+
+ * A scheduled "git maintenance" job is expected to work on all
+ repositories it knows about, but it stopped at the first one that
+ errored out. Now it keeps going.
+
+ * zsh can pretend to be a normal shell pretty well except for some
+ glitches that we tickle in some of our scripts. Work them around
+ so that "vimdiff" and our test suite works well enough with it.
+
+ * Command line completion support for zsh (in contrib/) has been
+ updated to stop exposing internal state to end-user shell
+ interaction.
+
+ * Tests that try to corrupt in-repository files in chunked format did
+ not work well on macOS due to its broken "mv", which has been
+ worked around.
+
+ * The maximum size of attribute files is enforced more consistently.
+
+ * Unbreak CI jobs so that we do not attempt to use Python 2 that has
+ been removed from the platform.
+
+ * Git 2.43 started using the tree of HEAD as the source of attributes
+ in a bare repository, which has severe performance implications.
+ For now, revert the change, without ripping out a more explicit
+ support for the attr.tree configuration variable.
+
+ * The "--exit-code" option of "git diff" command learned to work with
+ the "--ext-diff" option.
+
+ * Windows CI running in GitHub Actions started complaining about the
+ order of arguments given to calloc(); the imported regex code uses
+ the wrong order almost consistently, which has been corrected.
+
+ * Expose "name conflict" error when a ref creation fails due to D/F
+ conflict in the ref namespace, to improve an error message given by
+ "git fetch".
+ (merge 9339fca23e it/refs-name-conflict later to maint).
+
+ * The SubmittingPatches document now refers folks to manpages
+ translation project.
+
+ * The documentation for "git diff --name-only" has been clarified
+ that it is about showing the names in the post-image tree.
+
+ * The credential helper that talks with osx keychain learned to avoid
+ storing back the authentication material it just got received from
+ the keychain.
+ (merge e1ab45b2da kn/osxkeychain-skip-idempotent-store later to maint).
+
+ * The chainlint script (invoked during "make test") did nothing when
+ it failed to detect the number of available CPUs. It now falls
+ back to 1 CPU to avoid the problem.
+
+ * Revert overly aggressive "layered defence" that went into 2.45.1
+ and friends, which broke "git-lfs", "git-annex", and other use
+ cases, so that we can rebuild necessary counterparts in the open.
+
+ * "git init" in an already created directory, when the user
+ configuration has includeif.onbranch, started to fail recently,
+ which has been corrected.
+
+ * Memory leaks in "git mv" has been plugged.
+
+ * The safe.directory configuration knob has been updated to
+ optionally allow leading path matches.
+
+ * An overly large ".gitignore" files are now rejected silently.
+
+ * Upon expiration event, the credential subsystem forgot to clear
+ in-core authentication material other than password (whose support
+ was added recently), which has been corrected.
+
+ * Fix for an embarrassing typo that prevented Python2 tests from running
+ anywhere.
+
+ * Varargs functions that are unannotated as printf-like or execl-like
+ have been annotated as such.
+
+ * "git am" has a safety feature to prevent it from starting a new
+ session when there already is a session going. It reliably
+ triggers when a mbox is given on the command line, but it has to
+ rely on the tty-ness of the standard input. Add an explicit way to
+ opt out of this safety with a command line option.
+ (merge 62c71ace44 jk/am-retry later to maint).
+
+ * A leak in "git imap-send" that somehow escapes LSan has been
+ plugged.
+
+ * Setting core.abbrev too early before the repository set-up
+ (typically in "git clone") caused segfault, which as been
+ corrected.
+
+ * When the user adds to "git rebase -i" instruction to "pick" a merge
+ commit, the error experience is not pleasant. Such an error is now
+ caught earlier in the process that parses the todo list.
+
+ * We forgot to normalize the result of getcwd() to NFC on macOS where
+ all other paths are normalized, which has been corrected. This still
+ does not address the case where core.precomposeUnicode configuration
+ is not defined globally.
+
+ * Earlier we stopped using the tree of HEAD as the default source of
+ attributes in a bare repository, but failed to document it. This
+ has been corrected.
+
+ * "git update-server-info" and "git commit-graph --write" have been
+ updated to use the tempfile API to avoid leaving cruft after
+ failing.
+
+ * An unused extern declaration for mingw has been removed to prevent
+ it from causing build failure.
+
+ * A helper function shared between two tests had a copy-paste bug,
+ which has been corrected.
+
+ * "git fetch-pack -k -k" without passing "--lock-pack" (which we
+ never do ourselves) did not work at all, which has been corrected.
+
+ * CI job to build minimum fuzzers learned to pass NO_CURL=NoThanks to
+ the build procedure, as its build environment does not offer, or
+ the rest of the build needs, anything cURL.
+ (merge 4e66b5a990 jc/fuzz-sans-curl later to maint).
+
+ * "git diff --no-ext-diff" when diff.external is configured ignored
+ the "--color-moved" option.
+ (merge 0f4b0d4cf0 rs/diff-color-moved-w-no-ext-diff-fix later to maint).
+
+ * "git archive --add-virtual-file=<path>:<contents>" never paid
+ attention to the --prefix=<prefix> option but the documentation
+ said it would. The documentation has been corrected.
+ (merge 72c282098d jc/archive-prefix-with-add-virtual-file later to maint).
+
+ * When GIT_PAGER failed to spawn, depending on the code path taken,
+ we failed immediately (correct) or just spew the payload to the
+ standard output (incorrect). The code now always fail immediately
+ when GIT_PAGER fails.
+ (merge 78f0a5d187 rj/pager-die-upon-exec-failure later to maint).
+
+ * date parser updates to be more careful about underflowing epoch
+ based timestamp.
+ (merge 9d69789770 db/date-underflow-fix later to maint).
+
+ * The Bloom filter used for path limited history traversal was broken
+ on systems whose "char" is unsigned; update the implementation and
+ bump the format version to 2.
+ (merge 9c8a9ec787 tb/path-filter-fix later to maint).
+
+ * Typofix.
+ (merge 231cf7370e as/pathspec-h-typofix later to maint).
+
+ * Code clean-up.
+ (merge 4b837f821e rs/simplify-submodule-helper-super-prefix-invocation later to maint).
+
+ * "git describe --dirty --broken" forgot to refresh the index before
+ seeing if there is any chang, ("git describe --dirty" correctly did
+ so), which has been corrected.
+ (merge b8ae42e292 as/describe-broken-refresh-index-fix later to maint).
+
+ * Test suite has been taught not to unnecessarily rely on DNS failing
+ a bogus external name.
+ (merge 407cdbd271 jk/tests-without-dns later to maint).
+
+ * GitWeb update to use committer date consistently in rss/atom feeds.
+ (merge cf6ead095b am/gitweb-feed-use-committer-date later to maint).
+
+ * Custom control structures we invented more recently have been
+ taught to the clang-format file.
+ (merge 1457dff9be rs/clang-format-updates later to maint).
+
+ * Developer build procedure fix.
+ (merge df32729866 tb/dev-build-pedantic-fix later to maint).
+
+ * "git push" that pushes only deletion gave an unnecessary and
+ harmless error message when push negotiation is configured, which
+ has been corrected.
+ (merge 4d8ee0317f jc/disable-push-nego-for-deletion later to maint).
+
+ * Address-looking strings found on the trailer are now placed on the
+ Cc: list after running through sanitize_address by "git send-email".
+ (merge c852531f45 cb/send-email-sanitize-trailer-addresses later to maint).
+
+ * Tests that use GIT_TEST_SANITIZE_LEAK_LOG feature got their exit
+ status inverted, which has been corrected.
+ (merge 8c1d6691bc rj/test-sanitize-leak-log-fix later to maint).
+
+ * The http.cookieFile and http.saveCookies configuration variables
+ have a few values that need to be avoided, which are now ignored
+ with warning messages.
+ (merge 4f5822076f jc/http-cookiefile later to maint).
+
+ * Repacking a repository with multi-pack index started making stupid
+ pack selections in Git 2.45, which has been corrected.
+ (merge 8fb6d11fad ds/midx-write-repack-fix later to maint).
+
+ * Fix documentation mark-up regression in 2.45.
+ (merge 6474da0aa4 ja/doc-markup-updates-fix later to maint).
+
+ * Work around asciidoctor's css that renders `monospace` material
+ in the SYNOPSIS section of manual pages as block elements.
+ (merge d44ce6ddd5 js/doc-markup-updates-fix later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge 493fdae046 ew/object-convert-leakfix later to maint).
+ (merge 00f3661a0a ss/doc-eol-attr-fix later to maint).
+ (merge 428c40da61 ri/doc-show-branch-fix later to maint).
+ (merge 58696bfcaa jc/where-is-bash-for-ci later to maint).
+ (merge 616e94ca24 tb/doc-max-tree-depth-fix later to maint).
diff --git a/RelNotes/2.46.1.adoc b/RelNotes/2.46.1.adoc
new file mode 100644
index 0000000..e55c2c4
--- /dev/null
+++ b/RelNotes/2.46.1.adoc
@@ -0,0 +1,75 @@
+Git 2.46.1 Release Notes
+========================
+
+This release is primarily to merge fixes accumulated on the 'master'
+front to prepare for 2.47 release that are still relevant to 2.46.x
+maintenance track.
+
+Fixes since Git 2.46
+--------------------
+
+ * "git checkout --ours" (no other arguments) complained that the
+ option is incompatible with branch switching, which is technically
+ correct, but found confusing by some users. It now says that the
+ user needs to give pathspec to specify what paths to checkout.
+
+ * It has been documented that we avoid "VAR=VAL shell_func" and why.
+
+ * "git add -p" by users with diff.suppressBlankEmpty set to true
+ failed to parse the patch that represents an unmodified empty line
+ with an empty line (not a line with a single space on it), which
+ has been corrected.
+
+ * "git rebase --help" referred to "offset" (the difference between
+ the location a change was taken from and the change gets replaced)
+ incorrectly and called it "fuzz", which has been corrected.
+
+ * "git notes add -m '' --allow-empty" and friends that take prepared
+ data to create notes should not invoke an editor, but it started
+ doing so since Git 2.42, which has been corrected.
+
+ * An expensive operation to prepare tracing was done in re-encoding
+ code path even when the tracing was not requested, which has been
+ corrected.
+
+ * Perforce tests have been updated.
+
+ * The credential helper to talk to OSX keychain sometimes sent
+ garbage bytes after the username, which has been corrected.
+
+ * A recent update broke "git ls-remote" used outside a repository,
+ which has been corrected.
+
+ * "git config --value=foo --fixed-value section.key newvalue" barfed
+ when the existing value in the configuration file used the
+ valueless true syntax, which has been corrected.
+
+ * "git reflog expire" failed to honor annotated tags when computing
+ reachable commits.
+
+ * A flakey test and incorrect calls to strtoX() functions have been
+ fixed.
+
+ * Follow-up on 2.45.1 regression fix.
+
+ * "git rev-list ... | git diff-tree -p --remerge-diff --stdin" should
+ behave more or less like "git log -p --remerge-diff" but instead it
+ crashed, forgetting to prepare a temporary object store needed.
+
+ * The patch parser in "git patch-id" has been tightened to avoid
+ getting confused by lines that look like a patch header in the log
+ message.
+
+ * "git bundle unbundle" outside a repository triggered a BUG()
+ unnecessarily, which has been corrected.
+
+ * The code forgot to discard unnecessary in-core commit buffer data
+ for commits that "git log --skip=<number>" traversed but omitted
+ from the output, which has been corrected.
+
+ * "git verify-pack" and "git index-pack" started dying outside a
+ repository, which has been corrected.
+
+ * A corner case bug in "git stash" was fixed.
+
+Also contains minor documentation updates and code clean-ups.
diff --git a/RelNotes/2.46.2.adoc b/RelNotes/2.46.2.adoc
new file mode 100644
index 0000000..6133868
--- /dev/null
+++ b/RelNotes/2.46.2.adoc
@@ -0,0 +1,23 @@
+Git 2.46.2 Release Notes
+========================
+
+This release is primarily to merge changes to unbreak the 32-bit
+GitHub actions jobs we use for CI testing, so that we can release
+real fixes for the 2.46.x track after they pass CI.
+
+It also reverts the "git patch-id" change that went into 2.46.1,
+as it seems to have got a regression reported (I haven't verified,
+but it is better to keep a known breakage than adding an unintended
+regression).
+
+Other than that, a handful of minor bugfixes are included.
+
+ * In a few corner cases "git diff --exit-code" failed to report
+ "changes" (e.g., renamed without any content change), which has
+ been corrected.
+
+ * Cygwin does have /dev/tty support that is needed by things like
+ single-key input mode.
+
+ * The interpret-trailers command failed to recognise the end of the
+ message when the commit log ends in an incomplete line.
diff --git a/RelNotes/2.46.3.adoc b/RelNotes/2.46.3.adoc
new file mode 100644
index 0000000..4af032b
--- /dev/null
+++ b/RelNotes/2.46.3.adoc
@@ -0,0 +1,6 @@
+Git v2.46.3 Release Notes
+=========================
+
+This release merges up the fix that appears in v2.40.4, v2.41.3, v2.42.4,
+v2.43.6, v2.44.3 and v2.45.3 to address the security issues CVE-2024-50349 and
+CVE-2024-52006; see the release notes for these versions for details.
diff --git a/RelNotes/2.47.0.adoc b/RelNotes/2.47.0.adoc
new file mode 100644
index 0000000..b63c336
--- /dev/null
+++ b/RelNotes/2.47.0.adoc
@@ -0,0 +1,342 @@
+Git v2.47 Release Notes
+=======================
+
+UI, Workflows & Features
+------------------------
+
+ * Many Porcelain commands that internally use the merge machinery
+ were taught to consistently honor the diff.algorithm configuration.
+
+ * A few descriptions in "git show-ref -h" have been clarified.
+
+ * A 'P' command to "git add -p" that passes the patch hunk to the
+ pager has been added.
+
+ * "git grep -W" omits blank lines that follow the found function at
+ the end of the file, just like it omits blank lines before the next
+ function.
+
+ * The value of http.proxy can have "path" at the end for a socks
+ proxy that listens to a unix-domain socket, but we started to
+ discard it when we taught proxy auth code path to use the
+ credential helpers, which has been corrected.
+
+ * The code paths to compact multiple reftable files have been updated
+ to correctly deal with multiple compaction triggering at the same
+ time.
+
+ * Support to specify ref backend for submodules has been enhanced.
+
+ * "git svn" has been taught about svn:global-ignores property
+ recent versions of Subversion has.
+
+ * The default object hash and ref backend format used to be settable
+ only with explicit command line option to "git init" and
+ environment variables, but now they can be configured in the user's
+ global and system wide configuration.
+
+ * "git send-email" learned "--translate-aliases" option that reads
+ addresses from the standard input and emits the result of applying
+ aliases on them to the standard output.
+
+ * 'git for-each-ref' learned a new "--format" atom to find the branch
+ that the history leading to a given commit "%(is-base:<commit>)" is
+ likely based on.
+
+ * The command line prompt support used to be littered with bash-isms,
+ which has been corrected to work with more shells.
+
+ * Support for the RUNTIME_PREFIX feature has been added to z/OS port.
+
+ * "git send-email" learned "--mailmap" option to allow rewriting the
+ recipient addresses.
+
+ * "git mergetool" learned to use VSCode as a merge backend.
+
+ * "git pack-redundant" has been marked for removal in Git 3.0.
+
+ * One-line messages to "die" and other helper functions will get LF
+ added by these helper functions, but many existing messages had an
+ unnecessary LF at the end, which have been corrected.
+
+ * The "scalar clone" command learned the "--no-tags" option.
+
+ * The environment GIT_ADVICE has been intentionally kept undocumented
+ to discourage its use by interactive users. Add documentation to
+ help tool writers.
+
+ * "git apply --3way" learned to take "--ours" and other options.
+
+
+Performance, Internal Implementation, Development Support etc.
+--------------------------------------------------------------
+
+ * A build tweak knob has been simplified by not setting the value
+ that is already the default; another unused one has been removed.
+
+ * A CI job that use clang-format to check coding style issues in new
+ code has been added.
+
+ * The reviewing guidelines document now explicitly encourages people
+ to give positive reviews and how.
+
+ * Test script linter has been updated to catch an attempt to use
+ one-shot export construct "VAR=VAL func" for shell functions (which
+ does not work for some shells) better.
+
+ * Some project conventions have been added to CodingGuidelines.
+
+ * In the refs subsystem, implicit reliance of the_repository has been
+ eliminated; the repository associated with the ref store object is
+ used instead.
+
+ * Various tests in reftable library have been rewritten using the unit test
+ framework.
+
+ * A test that fails on an unusually slow machine was found, and made
+ less likely to cause trouble by lengthening the expiry value it
+ uses.
+
+ * An existing test of hashmap API has been rewritten with the
+ unit-test framework.
+
+ * A policy document that describes platform support levels and
+ expectation on platform stakeholders has been introduced.
+
+ * The refs API has been taught to give symref target information to
+ the users of ref iterators, allowing for-each-ref and friends to
+ avoid an extra ref_resolve_* API call per a symbolic ref.
+
+ * Unit-test framework has learned a simple control structure to allow
+ embedding test statements in-line instead of having to create a new
+ function to contain them.
+
+ * Incremental updates of multi-pack index files is getting worked on.
+
+ * Use of API functions that implicitly depend on the_repository
+ object in the config subsystem has been rewritten to pass a
+ repository object through the callchain.
+
+ * Unused parameters have been either marked as UNUSED to squelch
+ -Wunused warnings or dropped from many functions..
+
+ * The code in the reftable library has been cleaned up by discarding
+ unused "generic" interface.
+
+ * The underlying machinery for "git diff-index" has long been made to
+ expand the sparse index as needed, but the command fully expanded
+ the sparse index upfront, which now has been taught not to do.
+
+ * More trace2 events at key points on push and fetch code paths have
+ been added.
+
+ * Make our codebase compilable with the -Werror=unused-parameter
+ option.
+
+ * "git cat-file" works well with the sparse-index, and gets marked as
+ such.
+
+ * CI started failing completely for linux32 jobs, as the step to
+ upload failed test directory uses GitHub actions that is deprecated
+ and is now disabled.
+
+ * Import clar unit tests framework libgit2 folks invented for our
+ use.
+
+ * The error messages from the test script checker have been improved.
+
+ * The convention to calling into built-in command implementation has
+ been updated to pass the repository, if known, together with the
+ prefix value.
+
+ * "git apply" had custom buffer management code that predated before
+ use of strbuf got widespread, which has been updated to use strbuf,
+ which also plugged some memory leaks.
+
+ * The reftable backend learned to more efficiently handle exclude
+ patterns while enumerating the refs.
+
+ * CI updates. FreeBSD image has been updated to 13.4.
+ (merge 2eeb29702e cb/ci-freebsd-13-4 later to maint).
+
+ * Give timeout to the locking code to write to reftable, instead of
+ failing on the first failure without retrying.
+
+ * The checksum at the tail of files are now computed without
+ collision detection protection. This is safe as the consumer of
+ the information to protect itself from replay attacks checks for
+ hash collisions independently.
+
+
+Fixes since v2.46
+-----------------
+
+ * "git add -p" by users with diff.suppressBlankEmpty set to true
+ failed to parse the patch that represents an unmodified empty line
+ with an empty line (not a line with a single space on it), which
+ has been corrected.
+
+ * "git checkout --ours" (no other arguments) complained that the
+ option is incompatible with branch switching, which is technically
+ correct, but found confusing by some users. It now says that the
+ user needs to give pathspec to specify what paths to checkout.
+
+ * It has been documented that we avoid "VAR=VAL shell_func" and why.
+
+ * "git rebase --help" referred to "offset" (the difference between
+ the location a change was taken from and the change gets replaced)
+ incorrectly and called it "fuzz", which has been corrected.
+
+ * "git notes add -m '' --allow-empty" and friends that take prepared
+ data to create notes should not invoke an editor, but it started
+ doing so since Git 2.42, which has been corrected.
+
+ * An expensive operation to prepare tracing was done in re-encoding
+ code path even when the tracing was not requested, which has been
+ corrected.
+
+ * More leakfixes.
+
+ * The credential helper to talk to OSX keychain sometimes sent
+ garbage bytes after the username, which has been corrected.
+
+ * A recent update broke "git ls-remote" used outside a repository,
+ which has been corrected.
+
+ * The patch parser in 'git apply' has been a bit more lenient against
+ unexpected mode bits, like 100664, recorded on extended header lines.
+
+ * "git config --value=foo --fixed-value section.key newvalue" barfed
+ when the existing value in the configuration file used the
+ valueless true syntax, which has been corrected.
+
+ * The patch parser in "git patch-id" has been tightened to avoid
+ getting confused by lines that look like a patch header in the log
+ message.
+
+ * "git reflog expire" failed to honor annotated tags when computing
+ reachable commits.
+
+ * A flakey test and incorrect calls to strtoX() functions have been
+ fixed.
+
+ * Follow-up on 2.45.1 regression fix.
+
+ * "git rev-list ... | git diff-tree -p --remerge-diff --stdin" should
+ behave more or less like "git log -p --remerge-diff" but instead it
+ crashed, forgetting to prepare a temporary object store needed.
+
+ * "git bundle unbundle" outside a repository triggered a BUG()
+ unnecessarily, which has been corrected.
+
+ * Maintenance tasks other than "gc" now properly go background when
+ "git maintenance" runs them.
+
+ * We created a useless pseudo-merge reachability bitmap that is about
+ 0 commits, and attempted to include commits that are not in packs,
+ which made no sense. These bugs have been corrected.
+ (merge a72dfab8b8 tb/pseudo-merge-bitmap-fixes later to maint).
+
+ * "git rebase -x --quiet" was not quiet, which was corrected.
+
+ * The code path for compacting reftable files saw some bugfixes
+ against concurrent operation.
+
+ * The code forgot to discard unnecessary in-core commit buffer data
+ for commits that "git log --skip=<number>" traversed but omitted
+ from the output, which has been corrected.
+
+ * "git verify-pack" and "git index-pack" started dying outside a
+ repository, which has been corrected.
+
+ * A data corruption bug when multi-pack-index is used and the same
+ objects are stored in multiple packfiles has been corrected.
+
+ * "git pack-refs --auto" for the files backend was too aggressive,
+ which has been a bit tamed.
+ (merge c3459ae9ef ps/pack-refs-auto-heuristics later to maint).
+
+ * A file descriptor left open is now properly closed when "git
+ sparse-checkout" updates the sparse patterns.
+
+ * In a few corner cases "git diff --exit-code" failed to report
+ "changes" (e.g., renamed without any content change), which has
+ been corrected.
+
+ * Cygwin does have /dev/tty support that is needed by things like
+ single-key input mode.
+
+ * The interpret-trailers command failed to recognise the end of the
+ message when the commit log ends in an incomplete line.
+
+ * "git rebase --autostash" failed to resurrect the autostashed
+ changes when the command gets aborted after giving back control
+ asking for hlep in conflict resolution.
+ (merge bf6ab087d1 pw/rebase-autostash-fix later to maint).
+
+ * The "imap-send" now allows to be compiled with NO_OPENSSL and
+ OPENSSL_SHA1 defined together.
+ (merge 997950a750 jk/no-openssl-with-openssl-sha1 later to maint).
+
+ * The support to customize build options to adjust for older versions
+ and/or older systems for the interop tests has been improved.
+ (merge 22ef5f02a8 jk/interop-test-build-options later to maint).
+
+ * Update the character width table for Unicode 16.
+ (merge 44dc651132 bb/unicode-width-table-16 later to maint).
+
+ * In Git 2.39, Git.pm stopped working in a bare repository, which has
+ been corrected.
+ (merge d3edb0bdde jk/git-pm-bare-repo-fix later to maint).
+
+ * When a remote-helper dies before Git writes to it, SIGPIPE killed
+ Git silently. We now explain the situation a bit better to the end
+ user in our error message.
+ (merge 6e7fac9bca jk/diag-unexpected-remote-helper-death later to maint).
+
+ * A few usability fixes to "git jump" (in contrib/).
+ (merge 083b82544d jk/jump-quickfix-fixes later to maint).
+
+ * "git diff --exit-code" ignored modified binary files, which has
+ been corrected.
+ (merge 9a41735af6 rs/diff-exit-code-binary later to maint).
+
+ * When a subprocess to work in a submodule spawned by "git submodule"
+ fails with SIGPIPE, the parent Git process caught the death of it,
+ but gave a generic "failed to work in that submodule", which was
+ misleading. We now behave as if the parent got SIGPIPE and die.
+ (merge 082caf527e pw/submodule-process-sigpipe later to maint).
+
+ * "git archive" with pathspec magic that uses the attribute
+ information did not work well, which has been corrected.
+ (merge 296743a7ca rs/archive-with-attr-pathspec-fix later to maint).
+
+ * Background tasks "git maintenance" runs may need to use credential
+ information when going over the network, but a credential helper
+ may work only in an interactive environment, and end up blocking a
+ scheduled task waiting for UI. Credential helpers can now behave
+ differently when they are not running interactively.
+ (merge b9183b0a02 ds/background-maintenance-with-credential later to maint).
+
+ * "git --git-dir=nowhere cmd" failed to properly notice that it
+ wasn't in any repository while processing includeIf.onbranch
+ configuration and instead crashed.
+
+ * When "git sparse-checkout disable" turns a sparse checkout into a
+ regular checkout, the index is fully expanded. This totally
+ expected behaviour however had an "oops, we are expanding the
+ index" advice message, which has been corrected.
+ (merge 537e516a39 ds/sparse-checkout-expansion-advice later to maint).
+
+ * macOS with fsmonitor daemon can hang forever when a submodule is
+ involved, which has been corrected.
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge be10ac7037 jc/mailinfo-header-cleanup later to maint).
+ (merge 4460e052e0 jc/range-diff-lazy-setup later to maint).
+ (merge 0627c58e7a ak/typofixes later to maint).
+ (merge 83799f1500 jk/t9001-deflake later to maint).
+ (merge e02cc08a88 ak/typofix-2.46-maint later to maint).
+ (merge 5c5d29e1c4 ps/ci-gitlab-upgrade later to maint).
+ (merge 9c4c840901 jc/doc-discarding-stalled-topics later to maint).
+ (merge 5e6f359f6b ds/read-cache-mempool-leakfix later to maint).
diff --git a/RelNotes/2.47.1.adoc b/RelNotes/2.47.1.adoc
new file mode 100644
index 0000000..39206c0
--- /dev/null
+++ b/RelNotes/2.47.1.adoc
@@ -0,0 +1,31 @@
+Git 2.47.1 Release Notes
+========================
+
+This is to flush accumulated fixes since 2.47.0 on the 'master'
+front down to the maintenance track.
+
+
+Fixes since Git 2.47
+--------------------
+
+ * Use after free and double freeing at the end in "git log -L... -p"
+ had been identified and fixed.
+
+ * On macOS, fsmonitor can fall into a race condition that results in
+ a client waiting forever to be notified for an event that have
+ already happened. This problem has been corrected.
+
+ * "git maintenance start" crashed due to an uninitialized variable
+ reference, which has been corrected.
+
+ * Fail gracefully instead of crashing when attempting to write the
+ contents of a corrupt in-core index as a tree object.
+
+ * A "git fetch" from the superproject going down to a submodule used
+ a wrong remote when the default remote names are set differently
+ between them.
+
+ * The "gitk" project tree has been synchronized again with its new
+ maintainer, Johannes Sixt.
+
+Also contains minor documentation updates and code clean-ups.
diff --git a/RelNotes/2.47.2.adoc b/RelNotes/2.47.2.adoc
new file mode 100644
index 0000000..7a52ad8
--- /dev/null
+++ b/RelNotes/2.47.2.adoc
@@ -0,0 +1,7 @@
+Git v2.47.2 Release Notes
+=========================
+
+This release merges up the fix that appears in v2.40.4, v2.41.3,
+v2.42.4, v2.43.6, v2.44.3, v2.45.3 and v2.46.3 to address the
+security issues CVE-2024-50349 and CVE-2024-52006; see the release
+notes for these versions for details.
diff --git a/RelNotes/2.48.0.adoc b/RelNotes/2.48.0.adoc
new file mode 100644
index 0000000..eff93be
--- /dev/null
+++ b/RelNotes/2.48.0.adoc
@@ -0,0 +1,330 @@
+Git v2.48 Release Notes
+=======================
+
+UI, Workflows & Features
+------------------------
+
+ * A new configuration variable remote.<name>.serverOption makes the
+ transport layer act as if the --serverOption=<value> option is
+ given from the command line.
+
+ * "git rebase --rebase-merges" now uses branch names as labels when
+ able.
+
+ * Describe the policy to introduce breaking changes.
+
+ * Teach 'git notes add' and 'git notes append' a new '-e' flag,
+ instructing them to open the note in $GIT_EDITOR before saving.
+
+ * Documentation for "git bundle" saw improvements to more prominently
+ call out the use of '--all' when creating bundles.
+
+ * Drop support for older libcURL and Perl.
+
+ * End-user experience of "git mergetool" when the command errors out
+ has been improved.
+
+ * "git bundle --unbundle" and "git clone" running on a bundle file
+ both learned to trigger fsck over the new objects with configurable
+ fck check levels.
+
+ * When "git fetch $remote" notices that refs/remotes/$remote/HEAD is
+ missing and discovers what branch the other side points with its
+ HEAD, refs/remotes/$remote/HEAD is updated to point to it.
+
+ * "git fetch" honors "remote.<remote>.followRemoteHEAD" settings to
+ tweak the remote-tracking HEAD in "refs/remotes/<remote>/HEAD".
+
+ * "git range-diff" learned to optionally show and compare merge
+ commits in the ranges being compared, with the --diff-merges
+ option.
+
+
+Performance, Internal Implementation, Development Support etc.
+--------------------------------------------------------------
+
+ * Document "amlog" notes.
+
+ * The way AsciiDoc is used for SYNOPSIS part of the manual pages has
+ been revamped. The sources, at least for the simple cases, got
+ vastly more pleasant to work with.
+
+ * The reftable library is now prepared to expect that the memory
+ allocation function given to it may fail to allocate and to deal
+ with such an error.
+
+ * An extra worktree attached to a repository points at each other to
+ allow finding the repository from the worktree (and vice versa)
+ possible. Use relative paths for this linkage.
+
+ * Enable Windows-based CI in GitLab.
+
+ * Commands that can also work outside Git have learned to take the
+ repository instance "repo" when we know we are in a repository, and
+ NULL when we are not, in a parameter. The uses of the_repository
+ variable in a few of them have been removed using the new calling
+ convention.
+
+ * The reftable sub-system grew a new reftable-specific strbuf
+ replacement to reduce its dependency on Git-specific data
+ structures.
+
+ * The ref-filter machinery learns to recognize and avoid cases where
+ sorting would be redundant.
+
+ * Various platform compatibility fixes split out of the larger effort
+ to use Meson as the primary build tool.
+
+ * Treat ECONNABORTED the same as ECONNRESET in 'git credential-cache'
+ to work around a possible Cygwin regression. This resolves a race
+ condition caused by changes in Cygwin's handling of socket
+ closures, allowing the client to exit cleanly when encountering
+ ECONNABORTED.
+
+ * Demonstrate an assertion failure in 'git mv'.
+
+ * Documentation update to clarify that 'uploadpack.allowAnySHA1InWant'
+ implies both 'allowTipSHA1InWant' and 'allowReachableSHA1InWant'.
+
+ * Replace various calls to atoi() with strtol_i() and strtoul_ui(),
+ and add improved error handling.
+
+ * Documentation updates to 'git-update-ref(1)'.
+
+ * Update the project's CodingGuidelines to discourage naming functions
+ with a "_1()" suffix.
+
+ * Update '.clang-format' to match project conventions.
+
+ * Centralize documentation for repository extensions into a single place.
+
+ * Buildfix and upgrade of Clar to a newer version.
+
+ * Documentation mark-up updates.
+
+ * Renaming a handful of variables and structure fields.
+
+ * Fix for clar unit tests to support CMake build.
+
+ * C23 compatibility updates.
+
+ * GCC 15 compatibility updates.
+
+ * We now ensure "index-pack" is used with the "--promisor" option
+ only during a "git fetch".
+
+ * The migration procedure between two ref backends has been optimized.
+
+ * "git fsck" learned to issue warnings on "curiously formatted" ref
+ contents that have always been treated as valid but that Git
+ wouldn't have written itself (e.g., missing terminating end-of-line
+ after the full object name).
+
+ * Work around Coverity warning that would not trigger in practice.
+
+ * Built-in Git subcommands are supplied the repository object to work
+ with; they learned to do the same when they invoke sub-subcommands.
+
+ * Drop support for ancient environments in various CI jobs.
+
+ * Isolate the reftable subsystem from the rest of Git's codebase by
+ using fewer pieces of Git's infrastructure.
+
+ * Optimize reading random references out of the reftable backend by
+ allowing reuse of iterator objects.
+
+ * Backport oss-fuzz tests to our codebase.
+
+ * Introduce a new repository extension to prevent older Git versions
+ from mis-interpreting worktrees created with relative paths.
+
+ * Yet another "pass the repository through the callchain" topic.
+
+ * "git describe" learned to stop digging the history needlessly
+ deeper.
+
+ * Build procedure update plus introduction of Meson based builds.
+
+ * Recent reftable updates mistook a NULL return from a request for
+ 0-byte allocation as OOM and died unnecessarily, which has been
+ corrected.
+
+ * Reftable backend adds check for upper limit of log's update_index.
+
+ * Start working to make the codebase buildable with -Wsign-compare.
+
+ * Regression fix for 'show-index' when run outside of a repository.
+
+ * The meson-build procedure is integrated into CI to catch and
+ prevent bitrotting.
+
+ * "git refs migrate" learned to also migrate the reflog data across
+ backends.
+
+ * The developer documentation has been updated to give the latest
+ info on gitk and git-gui maintainer.
+
+
+ * CI jobs that run threaded programs under LSan has been giving false
+ positives from time to time, which has been worked around.
+
+
+Fixes since v2.47
+-----------------
+
+ * Doc update to clarify how periodical maintenance are scheduled,
+ spread across time to avoid thundering herds.
+
+ * Use after free and double freeing at the end in "git log -L... -p"
+ had been identified and fixed.
+
+ * On macOS, fsmonitor can fall into a race condition that results in
+ a client waiting forever to be notified about an event that has
+ already happened. This problem has been corrected.
+
+ * "git maintenance start" crashed due to an uninitialized variable
+ reference, which has been corrected.
+
+ * Fail gracefully instead of crashing when attempting to write the
+ contents of a corrupt in-core index as a tree object.
+
+ * A "git fetch" from the superproject going down to a submodule used
+ a wrong remote when the default remote names are set differently
+ between them.
+
+ * Fixes compile time warnings with 64-bit MSVC.
+
+ * Teaches 'shortlog' to explicitly use SHA-1 when operating outside
+ of a repository.
+
+ * Fix 'git grep' regression on macOS by disabling lookahead when
+ encountering invalid UTF-8 byte sequences.
+
+ * The dumb-http code regressed when the result of re-indexing a pack
+ yielded an *.idx file that differs in content from the *.idx file
+ it downloaded from the remote. This has been corrected by no longer
+ relying on the *.idx file we got from the remote.
+
+ * When called with '--left-right' and '--use-bitmap-index', 'rev-list'
+ will produce output without any left/right markers, which has been
+ corrected.
+
+ * More leakfixes.
+
+ * Test modernization.
+
+ * The "--shallow-exclude=<ref>" option to various history transfer
+ commands takes a ref, not an arbitrary revision.
+
+ * A regression where commit objects missing from a commit-graph can
+ cause an infinite loop when doing a fetch in a partial clone has
+ been fixed.
+
+ * The MinGW compatibility layer has been taught to support POSIX
+ semantics for atomic renames when other process(es) have a file
+ opened at the destination path.
+
+ * "git gc" discards any objects that are outside promisor packs that
+ are referred to by an object in a promisor pack, and we do not
+ refetch them from the promisor at runtime, resulting an unusable
+ repository. Work around it by including these objects in the
+ referring promisor pack at the receiving end of the fetch.
+
+ * Avoid build/test breakage on a system without working malloc debug
+ support dynamic library.
+ (merge 72ad6dc368 jk/test-malloc-debug-check later to maint).
+
+ * Double-free fix.
+ (merge fe17a25905 jk/fetch-prefetch-double-free-fix later to maint).
+
+ * Use of some uninitialized variables in "git difftool" has been
+ corrected.
+
+ * Object reuse code based on multi-pack-index sent an unwanted copy
+ of object.
+ (merge e199290592 tb/multi-pack-reuse-dupfix later to maint).
+
+ * "git fast-import" can be tricked into a replace ref that maps an
+ object to itself, which is a useless thing to do.
+ (merge 5e904f1a4a en/fast-import-avoid-self-replace later to maint).
+
+ * The ref-transaction hook triggered for reflog updates, which has
+ been corrected.
+ (merge b886db48c6 kn/ref-transaction-hook-with-reflog later to maint).
+
+ * Give a bit of advice/hint message when "git maintenance" stops finding a
+ lock file left by another instance that still is potentially running.
+ (merge ba874d1dac ps/gc-stale-lock-warning later to maint).
+
+ * Use the right helper program to measure file size in performance tests.
+ (merge 3f97f1bce6 tb/use-test-file-size-more later to maint).
+
+ * A double-free that may not trigger in practice by luck has been
+ corrected in the reference resolution code.
+ (merge b6318cf23a sj/refs-symref-referent-fix later to maint).
+
+ * The sequencer failed to honor core.commentString in some places.
+
+ * Describe a case where an option value needs to be spelled as a
+ separate argument, i.e. "--opt val", not "--opt=val".
+ (merge 1bc1e94091 jc/doc-opt-tilde-expand later to maint).
+
+ * Loosen overly strict ownership check introduced in the recent past,
+ to keep the promise "cloning a suspicious repository is a safe
+ first step to inspect it".
+ (merge 0ffb5a6bf1 bc/allow-upload-pack-from-other-people later to maint).
+
+ * "git fast-import" learned to reject paths with ".." and "." as
+ their components to avoid creating invalid tree objects.
+ (merge 8cb4c6e62f en/fast-import-verify-path later to maint).
+
+ * The --ancestry-path option is designed to be given a commit that is
+ on the path, which was not documented, which has been corrected.
+ (merge bc1a980759 kk/doc-ancestry-path later to maint).
+
+ * "git tag" has been taught to refuse to create refs/tags/HEAD
+ since such a tag will be confusing in the context of the UI provided by
+ the Git Porcelain commands.
+ (merge bbd445d5ef jc/forbid-head-as-tagname later to maint).
+
+ * The advice messages now tell the newer 'git config set' command to
+ set the advice.token configuration variable to squelch a message.
+ (merge 6c397d0104 bf/explicit-config-set-in-advice-messages later to maint).
+
+ * The syntax ":/<text>" to name the latest commit with the matching
+ text was broken with a recent change, which has been corrected.
+ (merge 0ff919e87a ps/commit-with-message-syntax-fix later to maint).
+
+ * Fix performance regression of a recent "fatten promisor pack with
+ local objects" protection against an unwanted gc.
+
+ * "git log -p --remerge-diff --reverse" was completely broken.
+ (merge f94bfa1516 js/log-remerge-keep-ancestry later to maint).
+
+ * "git bundle create" with an annotated tag on the positive end of
+ the revision range had a workaround code for older limitation in
+ the revision walker, which has become unnecessary.
+ (merge dd1072dfa8 tc/bundle-with-tag-remove-workaround later to maint).
+
+ * GitLab CI updates.
+ (merge c6b43f663e ps/ci-gitlab-update later to maint).
+
+ * Code to reuse objects based on bitmap contents have been tightened
+ to avoid race condition even when multiple packs are involved.
+ (merge 62b3ec8a3f tb/bitmap-fix-pack-reuse later to maint).
+
+ * An earlier "csum-file checksum does not have to be computed with
+ sha1dc" topic had a few code paths that had initialized an
+ implementation of a hash function to be used by an unmatching hash
+ by mistake, which have been corrected.
+ (merge 599a63409b ps/weak-sha1-for-tail-sum-fix later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge 77af53f56f aa/t7300-modernize later to maint).
+ (merge dcd590a39d bf/t-readme-mention-reftable later to maint).
+ (merge 68e3c69efa kh/trailer-in-glossary later to maint).
+ (merge 91f88f76e6 tb/boundary-traversal-fix later to maint).
+ (merge 168ebb7159 jc/doc-error-message-guidelines later to maint).
+ (merge 18693d7d65 kh/doc-bundle-typofix later to maint).
+ (merge e2f5d3b491 kh/doc-update-ref-grammofix later to maint).
+ (merge 8525e92886 mh/doc-windows-home-env later to maint).
diff --git a/RelNotes/2.48.1.adoc b/RelNotes/2.48.1.adoc
new file mode 100644
index 0000000..26c59b6
--- /dev/null
+++ b/RelNotes/2.48.1.adoc
@@ -0,0 +1,7 @@
+Git v2.48.1 Release Notes
+=========================
+
+This release merges up the fix that appears in v2.40.4, v2.41.3,
+v2.42.4, v2.43.6, v2.44.3, v2.45.3, v2.46.3, and v2.47.2 to address
+the security issues CVE-2024-50349 and CVE-2024-52006; see the release
+notes for these versions for details.
diff --git a/RelNotes/2.49.0.adoc b/RelNotes/2.49.0.adoc
new file mode 100644
index 0000000..05b720f
--- /dev/null
+++ b/RelNotes/2.49.0.adoc
@@ -0,0 +1,202 @@
+Git v2.49 Release Notes
+=======================
+
+UI, Workflows & Features
+------------------------
+
+ * Completion script updates for zsh
+
+ * "git pack-objects" and its wrapper "git repack" learned an option
+ to use an alternative path-hash function to improve delta-base
+ selection to produce a packfile with deeper history than window
+ size.
+
+ * "git gc" learned the "--expire-to" option and passes it down to
+ underlying "git repack".
+
+ * "[help] autocorrect = 1" used to be a way to say "please wait for
+ 0.1 second after suggesting a typofix of the command name before
+ running that command"; now it means "yes, if there is a plausible
+ typofix for the command name, please run it immediately".
+
+ * "git clone" learned to make a shallow clone for a single commit
+ that is not necessarily be at the tip of any branch.
+
+
+Performance, Internal Implementation, Development Support etc.
+--------------------------------------------------------------
+
+ * More -Wsign-compare fixes.
+
+ * meson-based build now supports the unsafe-sha1 build knob.
+
+ * The code to check LSan results has been simplified and made more
+ robust.
+ (merge 164a2516eb jk/lsan-race-ignore-false-positive later to maint).
+
+ * More code paths have a repository passed through the callchain,
+ instead of assuming the primary the_repository object.
+
+ * Move a few more unit tests to the clar test framework.
+
+ * Introduce a new API to visit objects in batches based on a common
+ path, or by type.
+
+ * Following the procedure we established to introduce breaking
+ changes for Git 3.0, allow an early opt-in for removing support of
+ $GIT_DIR/branches/ and $GIT_DIR/remotes/ directories to configure
+ remotes.
+
+ * The code paths to interact with zlib has been cleaned up in
+ preparation for building with zlib-ng.
+
+ * Foreign language interface for Rust into our code base has been added.
+
+ * All the documentation .txt files have been renamed to .adoc to help
+ content aware editors.
+
+
+Fixes since v2.48
+-----------------
+
+ * "git submodule" learned various ways to spell the same option,
+ e.g. "--branch=B" can be spelled "--branch B" or "-bB".
+ (merge b86f0f9071 re/submodule-parse-opt later to maint).
+
+ * Tweak the help text used for the option value placeholders by
+ parse-options API so that translations can customize the "<>"
+ placeholder signal (e.g. "--option=<value>").
+ (merge 5b34dd08d0 as/long-option-help-i18n later to maint).
+
+ * CI jobs gave sporadic failures, which turns out that that the
+ object finalization code was giving an error when it did not have
+ to.
+ (merge d7fcbe2c56 ps/object-collision-check later to maint).
+
+ * The code to compute "unique" name used git_rand() which can fail or
+ get stuck; the callsite does not require cryptographic security.
+ Introduce the "insecure" mode and use it appropriately.
+ (merge 0b4f8afef6 ps/reftable-get-random-fix later to maint).
+
+ * A misconfigured "fsck.skiplist" configuration variable was not
+ diagnosed as an error, which has been corrected.
+ (merge ca7158076f jt/fsck-skiplist-parse-fix later to maint).
+
+ * Extended SHA-1 expression parser did not work well when a branch
+ with an unusual name (e.g. "foo{bar") is involved.
+ (merge 191f0c8db2 en/object-name-with-funny-refname-fix later to maint).
+
+ * The meson build procedure looked for the 'version-def.h' file in a
+ wrong directory, which has been corrected.
+ (merge 4771501c0a tc/meson-use-our-version-def-h later to maint).
+
+ * The meson build procedure for Documentation/technical/ hierarchy was
+ missing necessary dependencies, which has been corrected.
+ (merge 1dca492edd sj/meson-doc-technical-dependency-fix later to maint).
+
+ * The "instaweb" bound only to local IP address without "--local" and
+ to all addresses with "--local", which was the other way around, when
+ using Python's http.server class, which has been corrected.
+ (merge 76baf97fa1 ak/instaweb-python-port-binding-fix later to maint).
+
+ * Document that it is insecure to use Personal Access Tokens, which
+ some hosting providers take as username/password, embedded in URLs.
+ (merge a90ff409f0 mh/doc-credential-helpers-with-pat later to maint).
+
+ * The help text from "git $cmd -h" appear on the standard output for
+ some $cmd and the standard error for others. The built-in commands
+ have been fixed to show them on the standard output consistently.
+ (merge f66d1423f5 jc/show-usage-help later to maint).
+
+ * The meson-driven build is now aware of "git-subtree" housed in
+ contrib/subtree hierarchy.
+ (merge 8454b42f94 ps/build-meson-subtree later to maint).
+
+ * It was possible for "git unpack-objects" and "git index-pack" to
+ make an unaligned access, which has been corrected.
+ (merge 98046591b9 jk/pack-header-parse-alignment-fix later to maint).
+
+ * The "cache" credential back-end did not handle authtype correctly,
+ which has been corrected.
+ (merge 0b43274850 mh/credential-cache-authtype-request-fix later to maint).
+
+ * "git branch --sort=..." and "git for-each-ref --format=... --sort=..."
+ did not work as expected with some atoms, which has been corrected.
+ (merge c5490ce9d1 rs/ref-fitler-used-atoms-value-fix later to maint).
+
+ * reflog entries for symbolic ref updates were broken, which has been
+ corrected.
+ (merge 3519492430 kn/reflog-symref-fix later to maint).
+
+ * The trace2 code was not prepared to show a configuration variable
+ that is set to true using the valueless true syntax, which has been
+ corrected.
+ (merge 2fd367cf63 am/trace2-with-valueless-true later to maint).
+
+ * The "git refs migrate" command did not migrate the reflog for
+ refs/stash, which is the contents of the stashes, which has been
+ corrected.
+ (merge a0bea0978f ps/reflog-migration-with-logall-fix later to maint).
+
+ * Doc and short-help text for "show-index" has been clarified to
+ stress that the command reads its data from the standard input.
+ (merge 49edce4ff9 jc/show-index-h-update later to maint).
+
+ * The API around choosing to use unsafe variant of SHA-1
+ implementation has been updated in an attempt to make it harder to
+ abuse.
+ (merge 04292c3796 tb/unsafe-hash-cleanup later to maint).
+
+ * Fix bugs in an earlier attempt to fix "git refs migration".
+ (merge f11f0a5a2d kn/reflog-migration-fix-fix later to maint).
+
+ * The code path used when "git fetch" fetches from a bundle file
+ closed the same file descriptor twice, which sometimes broke things
+ unexpectedly when the file descriptor was reused, which has been
+ corrected.
+ (merge 9a84794ad8 js/bundle-unbundle-fd-reuse-fix later to maint).
+
+ * "git init" to reinitialize a repository that already exists cannot
+ change the hash function and ref backends; such a request is
+ silently ignored now.
+ (merge 7e88640cd1 ps/setup-reinit-fixes later to maint).
+
+ * "git apply" internally uses unsigned long for line numbers and uses
+ strtoul() to parse numbers on the hunk headers. It however forgot
+ to check parse errors.
+ (merge a206058fda pw/apply-ulong-overflow-check later to maint).
+
+ * Two CI tasks, whitespace check and style check, work on the
+ difference from the base version and the version being checked, but
+ the base was computed incorrectly in GitLab CI in some cases, which
+ has been corrected.
+ (merge acc4fb302b jt/gitlab-ci-base-fix later to maint).
+
+ * "git repack --keep-unreachable" to send unreachable objects to the
+ main pack "git repack -ad" produces did not work when there is no
+ existing packs, which has been corrected.
+ (merge 414c82300a ps/repack-keep-unreachable-in-unpacked-repo later to maint).
+
+ * Going into a secondary worktree and asking "is the main worktree
+ bare?" did not work correctly when per-worktree configuration
+ option was in use, which has been corrected.
+
+ * Fetching into a bare repository incorrectly assumed it always used
+ a mirror layout when deciding to update remote-tracking HEAD, which
+ has been corrected.
+ (merge 93dc16483a bf/fetch-set-head-fix later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+ (merge ddb5287894 jk/t7407-use-test-grep later to maint).
+ (merge 21e1b44865 aj/difftool-config-doc-fix later to maint).
+ (merge 6a63995335 mh/gitattr-doc-markup-fix later to maint).
+ (merge 43850dcf9c sk/unit-test-hash later to maint).
+ (merge 4ad47d2de3 jc/cli-doc-option-and-config later to maint).
+ (merge 2d0ff147e5 jp/t8002-printf-fix later to maint).
+ (merge 69666e6746 ja/doc-restore-markup-update later to maint).
+ (merge d11d003ba5 sk/strlen-returns-size_t later to maint).
+ (merge 77b2d29e91 ja/doc-notes-markup-updates later to maint).
+ (merge 6979bf6f8f jk/combine-diff-cleanup later to maint).
+ (merge 8705c9bd13 kn/pack-write-with-reduced-globals later to maint).
+ (merge 087740d65a ps/leakfixes-0129 later to maint).
+ (merge 6bba6f604b jp/doc-trailer-config later to maint).
diff --git a/RelNotes/2.5.0.adoc b/RelNotes/2.5.0.adoc
new file mode 100644
index 0000000..84723f9
--- /dev/null
+++ b/RelNotes/2.5.0.adoc
@@ -0,0 +1,564 @@
+Git 2.5 Release Notes
+=====================
+
+Updates since v2.4
+------------------
+
+UI, Workflows & Features
+
+ * The bash completion script (in contrib/) learned a few options that
+ "git revert" takes.
+
+ * Whitespace breakages in deleted and context lines can also be
+ painted in the output of "git diff" and friends with the new
+ --ws-error-highlight option.
+
+ * List of commands shown by "git help" are grouped along the workflow
+ elements to help early learners.
+
+ * "git p4" now detects the filetype (e.g. binary) correctly even when
+ the files are opened exclusively.
+
+ * git p4 attempts to better handle branches in Perforce.
+
+ * "git p4" learned "--changes-block-size <n>" to read the changes in
+ chunks from Perforce, instead of making one call to "p4 changes"
+ that may trigger "too many rows scanned" error from Perforce.
+
+ * More workaround for Perforce's row number limit in "git p4".
+
+ * Unlike "$EDITOR" and "$GIT_EDITOR" that can hold the path to the
+ command and initial options (e.g. "/path/to/emacs -nw"), 'git p4'
+ did not let the shell interpolate the contents of the environment
+ variable that name the editor "$P4EDITOR" (and "$EDITOR", too).
+ This release makes it in line with the rest of Git, as well as with
+ Perforce.
+
+ * A new short-hand <branch>@{push} denotes the remote-tracking branch
+ that tracks the branch at the remote the <branch> would be pushed
+ to.
+
+ * "git show-branch --topics HEAD" (with no other arguments) did not
+ do anything interesting. Instead, contrast the given revision
+ against all the local branches by default.
+
+ * A replacement for contrib/workdir/git-new-workdir that does not
+ rely on symbolic links and make sharing of objects and refs safer
+ by making the borrowee and borrowers aware of each other.
+
+ Consider this as still an experimental feature; its UI is still
+ likely to change.
+
+ * Tweak the sample "store" backend of the credential helper to honor
+ XDG configuration file locations when specified.
+
+ * A heuristic we use to catch mistyped paths on the command line
+ "git <cmd> <revs> <pathspec>" is to make sure that all the non-rev
+ parameters in the later part of the command line are names of the
+ files in the working tree, but that means "git grep $str -- \*.c"
+ must always be disambiguated with "--", because nobody sane will
+ create a file whose name literally is asterisk-dot-see. Loosen the
+ heuristic to declare that with a wildcard string the user likely
+ meant to give us a pathspec.
+
+ * "git merge FETCH_HEAD" learned that the previous "git fetch" could
+ be to create an Octopus merge, i.e. recording multiple branches
+ that are not marked as "not-for-merge"; this allows us to lose an
+ old style invocation "git merge <msg> HEAD $commits..." in the
+ implementation of "git pull" script; the old style syntax can now
+ be deprecated (but not removed yet).
+
+ * Filter scripts were run with SIGPIPE disabled on the Git side,
+ expecting that they may not read what Git feeds them to filter.
+ We however treated a filter that does not read its input fully
+ before exiting as an error. We no longer do and ignore EPIPE
+ when writing to feed the filter scripts.
+
+ This changes semantics, but arguably in a good way. If a filter
+ can produce its output without fully consuming its input using
+ whatever magic, we now let it do so, instead of diagnosing it
+ as a programming error.
+
+ * Instead of dying immediately upon failing to obtain a lock, the
+ locking (of refs etc) retries after a short while with backoff.
+
+ * Introduce http.<url>.SSLCipherList configuration variable to tweak
+ the list of cipher suite to be used with libcURL when talking with
+ https:// sites.
+
+ * "git subtree" script (in contrib/) used "echo -n" to produce
+ progress messages in a non-portable way.
+
+ * "git subtree" script (in contrib/) does not have --squash option
+ when pushing, but the documentation and help text pretended as if
+ it did.
+
+ * The Git subcommand completion (in contrib/) no longer lists credential
+ helpers among candidates; they are not something the end user would
+ invoke interactively.
+
+ * The index file can be taught with "update-index --untracked-cache"
+ to optionally remember already seen untracked files, in order to
+ speed up "git status" in a working tree with tons of cruft.
+
+ * "git mergetool" learned to drive WinMerge as a backend.
+
+ * "git upload-pack" that serves "git fetch" can be told to serve
+ commits that are not at the tip of any ref, as long as they are
+ reachable from a ref, with uploadpack.allowReachableSHA1InWant
+ configuration variable.
+
+ * "git cat-file --batch(-check)" learned the "--follow-symlinks"
+ option that follows an in-tree symbolic link when asked about an
+ object via extended SHA-1 syntax, e.g. HEAD:RelNotes that points at
+ Documentation/RelNotes/2.5.0.txt. With the new option, the command
+ behaves as if HEAD:Documentation/RelNotes/2.5.0.txt was given as
+ input instead.
+
+ Consider this as still an experimental and incomplete feature:
+
+ - We may want to do the same for in-index objects, e.g.
+ asking for :RelNotes with this option should give
+ :Documentation/RelNotes/2.5.0.txt, too
+
+ - "git cat-file --follow-symlinks blob HEAD:RelNotes"
+ may also be something we want to allow in the future.
+
+ * "git send-email" learned the alias file format used by the sendmail
+ program (in a simplified form; we obviously do not feed pipes).
+
+ * Traditionally, external low-level 3-way merge drivers are expected
+ to produce their results based solely on the contents of the three
+ variants given in temporary files named by %O, %A and %B on their
+ command line. Additionally allow them to look at the final path
+ (given by %P).
+
+ * "git blame" learned blame.showEmail configuration variable.
+
+ * "git apply" cannot diagnose a patch corruption when the breakage is
+ to mark the length of the hunk shorter than it really is on the
+ hunk header line "@@ -l,k +m,n @@"; one special case it could is
+ when the hunk becomes no-op (e.g. k == n == 2 for two-line context
+ patch output), and it learned to do so in this special case.
+
+ * Add the "--allow-unknown-type" option to "cat-file" to allow
+ inspecting loose objects of an experimental or a broken type.
+
+ * Many long-running operations show progress eye-candy, even when
+ they are later backgrounded. Hide the eye-candy when the process
+ is sent to the background instead.
+ (merge a4fb76c lm/squelch-bg-progress later to maint).
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * "unsigned char [20]" used throughout the code to represent object
+ names are being converted into a semi-opaque "struct object_id".
+ This effort is expected to interfere with other topics in flight,
+ but hopefully will give us one extra level of abstraction in the
+ end, when completed.
+
+ * for_each_ref() callback functions were taught to name the objects
+ not with "unsigned char sha1[20]" but with "struct object_id".
+
+ * Catch a programmer mistake to feed a pointer not an array to
+ ARRAY_SIZE() macro, by using a couple of GCC extensions.
+
+ * Some error messages in "git config" were emitted without calling
+ the usual error() facility.
+
+ * When "add--interactive" splits a hunk into two overlapping hunks
+ and then let the user choose only one, it sometimes feeds an
+ incorrect patch text to "git apply". Add tests to demonstrate
+ this.
+
+ I have a slight suspicion that this may be
+ cf. <7vtzf77wjp.fsf@gitster.siamese.dyndns.org> coming back
+ and biting us (I seem to have said "let's run with this and see
+ what happens" back then).
+
+ * More line-ending tests.
+
+ * An earlier rewrite to use strbuf_getwholeline() instead of fgets(3)
+ to read packed-refs file revealed that the former is unacceptably
+ inefficient. It has been optimized by using getdelim(3) when
+ available.
+
+ * The refs API uses ref_lock struct which had its own "int fd", even
+ though the same file descriptor was in the lock struct it contains.
+ Clean-up the code to lose this redundant field.
+
+ * There was a dead code that used to handle "git pull --tags" and
+ show special-cased error message, which was made irrelevant when
+ the semantics of the option changed back in Git 1.9 days.
+ (merge 19d122b pt/pull-tags-error-diag later to maint).
+
+ * Help us to find broken test script that splits the body part of the
+ test by mistaken use of wrong kind of quotes.
+ (merge d93d5d5 jc/test-prereq-validate later to maint).
+
+ * Developer support to automatically detect broken &&-chain in the
+ test scripts is now turned on by default.
+ (merge 92b269f jk/test-chain-lint later to maint).
+
+ * Error reporting mechanism used in "refs" API has been made more
+ consistent.
+
+ * "git pull" has more test coverage now.
+
+ * "git pull" has become more aware of the options meant for
+ underlying "git fetch" and then learned to use parse-options
+ parser.
+
+ * Clarify in the Makefile a guideline to decide use of USE_NSEC.
+
+Also contains various documentation updates and code clean-ups.
+
+
+Fixes since v2.4
+----------------
+
+Unless otherwise noted, all the fixes since v2.4 in the maintenance
+track are contained in this release (see the maintenance releases'
+notes for details).
+
+ * Git 2.4 broke setting verbosity and progress levels on "git clone"
+ with native transports.
+ (merge 822f0c4 mh/clone-verbosity-fix later to maint).
+
+ * "git add -e" did not allow the user to abort the operation by
+ killing the editor.
+ (merge cb64800 jk/add-e-kill-editor later to maint).
+
+ * Memory usage of "git index-pack" has been trimmed by tens of
+ per-cent.
+ (merge f0e7f11 nd/slim-index-pack-memory-usage later to maint).
+
+ * "git rev-list --objects $old --not --all" to see if everything that
+ is reachable from $old is already connected to the existing refs
+ was very inefficient.
+ (merge b6e8a3b jk/still-interesting later to maint).
+
+ * "hash-object --literally" introduced in v2.2 was not prepared to
+ take a really long object type name.
+ (merge 1427a7f jc/hash-object later to maint).
+
+ * "git rebase --quiet" was not quite quiet when there is nothing to
+ do.
+ (merge 22946a9 jk/rebase-quiet-noop later to maint).
+
+ * The completion for "log --decorate=" parameter value was incorrect.
+ (merge af16bda sg/complete-decorate-full-not-long later to maint).
+
+ * "filter-branch" corrupted commit log message that ends with an
+ incomplete line on platforms with some "sed" implementations that
+ munge such a line. Work it around by avoiding to use "sed".
+ (merge df06201 jk/filter-branch-use-of-sed-on-incomplete-line later to maint).
+
+ * "git daemon" fails to build from the source under NO_IPV6
+ configuration (regression in 2.4).
+ (merge d358f77 jc/daemon-no-ipv6-for-2.4.1 later to maint).
+
+ * Some time ago, "git blame" (incorrectly) lost the convert_to_git()
+ call when synthesizing a fake "tip" commit that represents the
+ state in the working tree, which broke folks who record the history
+ with LF line ending to make their project portable across platforms
+ while terminating lines in their working tree files with CRLF for
+ their platform.
+ (merge 4bf256d tb/blame-resurrect-convert-to-git later to maint).
+
+ * We avoid setting core.worktree when the repository location is the
+ ".git" directory directly at the top level of the working tree, but
+ the code misdetected the case in which the working tree is at the
+ root level of the filesystem (which arguably is a silly thing to
+ do, but still valid).
+ (merge 84ccad8 jk/init-core-worktree-at-root later to maint).
+
+ * "git commit --date=now" or anything that relies on approxidate lost
+ the daylight-saving-time offset.
+ (merge f6e6362 jc/epochtime-wo-tz later to maint).
+
+ * Access to objects in repositories that borrow from another one on a
+ slow NFS server unnecessarily got more expensive due to recent code
+ becoming more cautious in a naive way not to lose objects to pruning.
+ (merge ee1c6c3 jk/prune-mtime later to maint).
+
+ * The codepaths that read .gitignore and .gitattributes files have been
+ taught that these files encoded in UTF-8 may have UTF-8 BOM marker at
+ the beginning; this makes it in line with what we do for configuration
+ files already.
+ (merge 27547e5 cn/bom-in-gitignore later to maint).
+
+ * a few helper scripts in the test suite did not report errors
+ correctly.
+ (merge de248e9 ep/fix-test-lib-functions-report later to maint).
+
+ * The default $HOME/.gitconfig file created upon "git config --global"
+ that edits it had incorrectly spelled user.name and user.email
+ entries in it.
+ (merge 7e11052 oh/fix-config-default-user-name-section later to maint).
+
+ * "git cat-file bl $blob" failed to barf even though there is no
+ object type that is "bl".
+ (merge b7994af jk/type-from-string-gently later to maint).
+
+ * The usual "git diff" when seeing a file turning into a directory
+ showed a patchset to remove the file and create all files in the
+ directory, but "git diff --no-index" simply refused to work. Also,
+ when asked to compare a file and a directory, imitate POSIX "diff"
+ and compare the file with the file with the same name in the
+ directory, instead of refusing to run.
+ (merge 0615173 jc/diff-no-index-d-f later to maint).
+
+ * "git rebase -i" moved the "current" command from "todo" to "done" a
+ bit too prematurely, losing a step when a "pick" did not even start.
+ (merge 8cbc57c ph/rebase-i-redo later to maint).
+
+ * The connection initiation code for "ssh" transport tried to absorb
+ differences between the stock "ssh" and Putty-supplied "plink" and
+ its derivatives, but the logic to tell that we are using "plink"
+ variants were too loose and falsely triggered when "plink" appeared
+ anywhere in the path (e.g. "/home/me/bin/uplink/ssh").
+ (merge baaf233 bc/connect-plink later to maint).
+
+ * We have prepended $GIT_EXEC_PATH and the path "git" is installed in
+ (typically "/usr/bin") to $PATH when invoking subprograms and hooks
+ for almost eternity, but the original use case the latter tried to
+ support was semi-bogus (i.e. install git to /opt/foo/git and run it
+ without having /opt/foo on $PATH), and more importantly it has
+ become less and less relevant as Git grew more mainstream (i.e. the
+ users would _want_ to have it on their $PATH). Stop prepending the
+ path in which "git" is installed to users' $PATH, as that would
+ interfere the command search order people depend on (e.g. they may
+ not like versions of programs that are unrelated to Git in /usr/bin
+ and want to override them by having different ones in /usr/local/bin
+ and have the latter directory earlier in their $PATH).
+ (merge a0b4507 jk/git-no-more-argv0-path-munging later to maint).
+
+ * core.excludesfile (defaulting to $XDG_HOME/git/ignore) is supposed
+ to be overridden by repository-specific .git/info/exclude file, but
+ the order was swapped from the beginning. This belatedly fixes it.
+ (merge 099d2d8 jc/gitignore-precedence later to maint).
+
+ * There was a commented-out (instead of being marked to expect
+ failure) test that documented a breakage that was fixed since the
+ test was written; turn it into a proper test.
+ (merge 66d2e04 sb/t1020-cleanup later to maint).
+
+ * The "log --decorate" enhancement in Git 2.4 that shows the commit
+ at the tip of the current branch e.g. "HEAD -> master", did not
+ work with --decorate=full.
+ (merge 429ad20 mg/log-decorate-HEAD later to maint).
+
+ * The ref API did not handle cases where 'refs/heads/xyzzy/frotz' is
+ removed at the same time as 'refs/heads/xyzzy' is added (or vice
+ versa) very well.
+ (merge c628edf mh/ref-directory-file later to maint).
+
+ * Multi-ref transaction support we merged a few releases ago
+ unnecessarily kept many file descriptors open, risking to fail with
+ resource exhaustion. This is for 2.4.x track.
+ (merge 185ce3a mh/write-refs-sooner-2.4 later to maint).
+
+ * "git bundle verify" did not diagnose extra parameters on the
+ command line.
+ (merge 7886cfa ps/bundle-verify-arg later to maint).
+
+ * Various documentation mark-up fixes to make the output more
+ consistent in general and also make AsciiDoctor (an alternative
+ formatter) happier.
+ (merge d0258b9 jk/asciidoc-markup-fix later to maint).
+ (merge ad3967a jk/stripspace-asciidoctor-fix later to maint).
+ (merge 975e382 ja/tutorial-asciidoctor-fix later to maint).
+
+ * The code to read pack-bitmap wanted to allocate a few hundred
+ pointers to a structure, but by mistake allocated and leaked memory
+ enough to hold that many actual structures. Correct the allocation
+ size and also have it on stack, as it is small enough.
+ (merge 599dc76 rs/plug-leak-in-pack-bitmaps later to maint).
+
+ * The pull.ff configuration was supposed to override the merge.ff
+ configuration, but it didn't.
+ (merge db9bb28 pt/pull-ff-vs-merge-ff later to maint).
+
+ * "git pull --log" and "git pull --no-log" worked as expected, but
+ "git pull --log=20" did not.
+ (merge 5061a44 pt/pull-log-n later to maint).
+
+ * "git rerere forget" in a repository without rerere enabled gave a
+ cryptic error message; it should be a silent no-op instead.
+ (merge 0544574 jk/rerere-forget-check-enabled later to maint).
+
+ * "git rebase -i" fired post-rewrite hook when it shouldn't (namely,
+ when it was told to stop sequencing with 'exec' insn).
+ (merge 141ff8f mm/rebase-i-post-rewrite-exec later to maint).
+
+ * Clarify that "log --raw" and "log --format=raw" are unrelated
+ concepts.
+ (merge 92de921 mm/log-format-raw-doc later to maint).
+
+ * Make "git stash something --help" error out, so that users can
+ safely say "git stash drop --help".
+ (merge 5ba2831 jk/stash-options later to maint).
+
+ * The clean/smudge interface did not work well when filtering an
+ empty contents (failed and then passed the empty input through).
+ It can be argued that a filter that produces anything but empty for
+ an empty input is nonsense, but if the user wants to do strange
+ things, then why not?
+ (merge f6a1e1e jh/filter-empty-contents later to maint).
+
+ * Communication between the HTTP server and http_backend process can
+ lead to a dead-lock when relaying a large ref negotiation request.
+ Diagnose the situation better, and mitigate it by reading such a
+ request first into core (to a reasonable limit).
+ (merge 636614f jk/http-backend-deadlock later to maint).
+
+ * "git clean pathspec..." tried to lstat(2) and complain even for
+ paths outside the given pathspec.
+ (merge 838d6a9 dt/clean-pathspec-filter-then-lstat later to maint).
+
+ * Recent "git prune" traverses young unreachable objects to safekeep
+ old objects in the reachability chain from them, which sometimes
+ caused error messages that are unnecessarily alarming.
+ (merge ce4e7b2 jk/squelch-missing-link-warning-for-unreachable later to maint).
+
+ * The configuration reader/writer uses mmap(2) interface to access
+ the files; when we find a directory, it barfed with "Out of memory?".
+ (merge 9ca0aaf jk/diagnose-config-mmap-failure later to maint).
+
+ * "color.diff.plain" was a misnomer; give it 'color.diff.context' as
+ a more logical synonym.
+ (merge 8dbf3eb jk/color-diff-plain-is-context later to maint).
+
+ * The setup code used to die when core.bare and core.worktree are set
+ inconsistently, even for commands that do not need working tree.
+ (merge fada767 jk/die-on-bogus-worktree-late later to maint).
+
+ * Recent Mac OS X updates breaks the logic to detect that the machine
+ is on the AC power in the sample pre-auto-gc script.
+ (merge c54c7b3 pa/auto-gc-mac-osx later to maint).
+
+ * "git commit --cleanup=scissors" was not careful enough to protect
+ against getting fooled by a line that looked like scissors.
+ (merge fbfa097 sg/commit-cleanup-scissors later to maint).
+
+ * "Have we lost a race with competing repack?" check was too
+ expensive, especially while receiving a huge object transfer
+ that runs index-pack (e.g. "clone" or "fetch").
+ (merge 0eeb077 jk/index-pack-reduce-recheck later to maint).
+
+ * The tcsh completion writes a bash scriptlet but that would have
+ failed for users with noclobber set.
+ (merge 0b1f688 af/tcsh-completion-noclobber later to maint).
+
+ * "git for-each-ref" reported "missing object" for 0{40} when it
+ encounters a broken ref. The lack of object whose name is 0{40} is
+ not the problem; the ref being broken is.
+ (merge 501cf47 mh/reporting-broken-refs-from-for-each-ref later to maint).
+
+ * Various fixes around "git am" that applies a patch to a history
+ that is not there yet.
+ (merge 6ea3b67 pt/am-abort-fix later to maint).
+
+ * "git fsck" used to ignore missing or invalid objects recorded in reflog.
+ (merge 19bf6c9 mh/fsck-reflog-entries later to maint).
+
+ * "git format-patch --ignore-if-upstream A..B" did not like to be fed
+ tags as boundary commits.
+ (merge 9b7a61d jc/do-not-feed-tags-to-clear-commit-marks later to maint).
+
+ * "git fetch --depth=<depth>" and "git clone --depth=<depth>" issued
+ a shallow transfer request even to an upload-pack that does not
+ support the capability.
+ (merge eb86a50 me/fetch-into-shallow-safety later to maint).
+
+ * "git rebase" did not exit with failure when format-patch it invoked
+ failed for whatever reason.
+ (merge 60d708b cb/rebase-am-exit-code later to maint).
+
+ * Fix a small bug in our use of umask() return value.
+ (merge 3096b2e jk/fix-refresh-utime later to maint).
+
+ * An ancient test framework enhancement to allow color was not
+ entirely correct; this makes it work even when tput needs to read
+ from the ~/.terminfo under the user's real HOME directory.
+ (merge d5c1b7c rh/test-color-avoid-terminfo-in-original-home later to maint).
+
+ * A minor bugfix when pack bitmap is used with "rev-list --count".
+ (merge c8a70d3 jk/rev-list-no-bitmap-while-pruning later to maint).
+
+ * "git config" failed to update the configuration file when the
+ underlying filesystem is incapable of renaming a file that is still
+ open.
+ (merge 7a64592 kb/config-unmap-before-renaming later to maint).
+
+ * Avoid possible ssize_t to int truncation.
+ (merge 6c8afe4 mh/strbuf-read-file-returns-ssize-t later to maint).
+
+ * When you say "!<ENTER>" while running say "git log", you'd confuse
+ yourself in the resulting shell, that may look as if you took
+ control back to the original shell you spawned "git log" from but
+ that isn't what is happening. To that new shell, we leaked
+ GIT_PAGER_IN_USE environment variable that was meant as a local
+ communication between the original "Git" and subprocesses that was
+ spawned by it after we launched the pager, which caused many
+ "interesting" things to happen, e.g. "git diff | cat" still paints
+ its output in color by default.
+
+ Stop leaking that environment variable to the pager's half of the
+ fork; we only need it on "Git" side when we spawn the pager.
+ (merge 124b519 jc/unexport-git-pager-in-use-in-pager later to maint).
+
+ * Abandoning an already applied change in "git rebase -i" with
+ "--continue" left CHERRY_PICK_HEAD and confused later steps.
+ (merge 0e0aff4 js/rebase-i-clean-up-upon-continue-to-skip later to maint).
+
+ * We used to ask libCURL to use the most secure authentication method
+ available when talking to an HTTP proxy only when we were told to
+ talk to one via configuration variables. We now ask libCURL to
+ always use the most secure authentication method, because the user
+ can tell libCURL to use an HTTP proxy via an environment variable
+ without using configuration variables.
+ (merge 5841520 et/http-proxyauth later to maint).
+
+ * A fix to a minor regression to "git fsck" in v2.2 era that started
+ complaining about a body-less tag object when it lacks a separator
+ empty line after its header to separate it with a non-existent body.
+ (merge 84d18c0 jc/fsck-retire-require-eoh later to maint).
+
+ * Code cleanups and documentation updates.
+ (merge 0269f96 mm/usage-log-l-can-take-regex later to maint).
+ (merge 64f2589 nd/t1509-chroot-test later to maint).
+ (merge d201a1e sb/test-bitmap-free-at-end later to maint).
+ (merge 05bfc7d sb/line-log-plug-pairdiff-leak later to maint).
+ (merge 846e5df pt/xdg-config-path later to maint).
+ (merge 1154aa4 jc/plug-fmt-merge-msg-leak later to maint).
+ (merge 319b678 jk/sha1-file-reduce-useless-warnings later to maint).
+ (merge 9a35c14 fg/document-commit-message-stripping later to maint).
+ (merge bbf431c ps/doc-packfile-vs-pack-file later to maint).
+ (merge 309a9e3 jk/skip-http-tests-under-no-curl later to maint).
+ (merge ccd593c dl/branch-error-message later to maint).
+ (merge 22570b6 rs/janitorial later to maint).
+ (merge 5c2a581 mc/commit-doc-grammofix later to maint).
+ (merge ce41720 ah/usage-strings later to maint).
+ (merge e6a268c sb/glossary-submodule later to maint).
+ (merge ec48a76 sb/submodule-doc-intro later to maint).
+ (merge 14f8b9b jk/clone-dissociate later to maint).
+ (merge 055c7e9 sb/pack-protocol-mention-smart-http later to maint).
+ (merge 7c37a5d jk/make-fix-dependencies later to maint).
+ (merge fc0aa39 sg/merge-summary-config later to maint).
+ (merge 329af6c pt/t0302-needs-sanity later to maint).
+ (merge d614f07 fk/doc-format-patch-vn later to maint).
+ (merge 72dbb36 sg/completion-commit-cleanup later to maint).
+ (merge e654eb2 es/utf8-stupid-compiler-workaround later to maint).
+ (merge 34b935c es/osx-header-pollutes-mask-macro later to maint).
+ (merge ab7fade jc/prompt-document-ps1-state-separator later to maint).
+ (merge 25f600e mm/describe-doc later to maint).
+ (merge 83fe167 mm/branch-doc-updates later to maint).
+ (merge 75d2e5a ls/hint-rev-list-count later to maint).
+ (merge edc8f71 cb/subtree-tests-update later to maint).
+ (merge 5330e6e sb/p5310-and-chain later to maint).
+ (merge c4ac525 tb/checkout-doc later to maint).
+ (merge e479c5f jk/pretty-encoding-doc later to maint).
+ (merge 7e837c6 ss/clone-guess-dir-name-simplify later to maint).
diff --git a/RelNotes/2.5.1.adoc b/RelNotes/2.5.1.adoc
new file mode 100644
index 0000000..b705533
--- /dev/null
+++ b/RelNotes/2.5.1.adoc
@@ -0,0 +1,65 @@
+Git v2.5.1 Release Notes
+========================
+
+Fixes since v2.5
+----------------
+
+ * Running an aliased command from a subdirectory when the .git thing
+ in the working tree is a gitfile pointing elsewhere did not work.
+
+ * Often a fast-import stream builds a new commit on top of the
+ previous commit it built, and it often unconditionally emits a
+ "from" command to specify the first parent, which can be omitted in
+ such a case. This caused fast-import to forget the tree of the
+ previous commit and then re-read it from scratch, which was
+ inefficient. Optimize for this common case.
+
+ * The "rev-parse --parseopt" mode parsed the option specification
+ and the argument hint in a strange way to allow '=' and other
+ special characters in the option name while forbidding them from
+ the argument hint. This made it impossible to define an option
+ like "--pair <key>=<value>" with "pair=key=value" specification,
+ which instead would have defined a "--pair=key <value>" option.
+
+ * A "rebase" replays changes of the local branch on top of something
+ else, as such they are placed in stage #3 and referred to as
+ "theirs", while the changes in the new base, typically a foreign
+ work, are placed in stage #2 and referred to as "ours". Clarify
+ the "checkout --ours/--theirs".
+
+ * An experimental "untracked cache" feature used uname(2) in a
+ slightly unportable way.
+
+ * "sparse checkout" misbehaved for a path that is excluded from the
+ checkout when switching between branches that differ at the path.
+
+ * The low-level "git send-pack" did not honor 'user.signingkey'
+ configuration variable when sending a signed-push.
+
+ * An attempt to delete a ref by pushing into a repository whose HEAD
+ symbolic reference points at an unborn branch that cannot be
+ created due to ref D/F conflict (e.g. refs/heads/a/b exists, HEAD
+ points at refs/heads/a) failed.
+
+ * "git subtree" (in contrib/) depended on "git log" output to be
+ stable, which was a no-no. Apply a workaround to force a
+ particular date format.
+
+ * "git clone $URL" in recent releases of Git contains a regression in
+ the code that invents a new repository name incorrectly based on
+ the $URL. This has been corrected.
+ (merge db2e220 jk/guess-repo-name-regression-fix later to maint).
+
+ * Running tests with the "-x" option to make them verbose had some
+ unpleasant interactions with other features of the test suite.
+ (merge 9b5fe78 jk/test-with-x later to maint).
+
+ * "git pull" in recent releases of Git has a regression in the code
+ that allows custom path to the --upload-pack=<program>. This has
+ been corrected.
+
+ * pipe() emulation used in Git for Windows looked at a wrong variable
+ when checking for an error from an _open_osfhandle() call.
+
+Also contains typofixes, documentation updates and trivial code
+clean-ups.
diff --git a/RelNotes/2.5.2.adoc b/RelNotes/2.5.2.adoc
new file mode 100644
index 0000000..3f74939
--- /dev/null
+++ b/RelNotes/2.5.2.adoc
@@ -0,0 +1,63 @@
+Git v2.5.2 Release Notes
+========================
+
+Fixes since v2.5.1
+------------------
+
+ * "git init empty && git -C empty log" said "bad default revision 'HEAD'",
+ which was found to be a bit confusing to new users.
+
+ * The "interpret-trailers" helper mistook a multi-paragraph title of
+ a commit log message with a colon in it as the end of the trailer
+ block.
+
+ * When re-priming the cache-tree opportunistically while committing
+ the in-core index as-is, we mistakenly invalidated the in-core
+ index too aggressively, causing the experimental split-index code
+ to unnecessarily rewrite the on-disk index file(s).
+
+ * "git archive" did not use zip64 extension when creating an archive
+ with more than 64k entries, which nobody should need, right ;-)?
+
+ * The code in "multiple-worktree" support that attempted to recover
+ from an inconsistent state updated an incorrect file.
+
+ * "git rev-list" does not take "--notes" option, but did not complain
+ when one is given.
+
+ * Because the configuration system does not allow "alias.0foo" and
+ "pager.0foo" as the configuration key, the user cannot use '0foo'
+ as a custom command name anyway, but "git 0foo" tried to look these
+ keys up and emitted useless warnings before saying '0foo is not a
+ git command'. These warning messages have been squelched.
+
+ * We recently rewrote one of the build scripts in Perl, which made it
+ necessary to have Perl to build Git. Reduced Perl dependency by
+ rewriting it again using sed.
+
+ * t1509 test that requires a dedicated VM environment had some
+ bitrot, which has been corrected.
+
+ * strbuf_read() used to have one extra iteration (and an unnecessary
+ strbuf_grow() of 8kB), which was eliminated.
+
+ * The codepath to produce error messages had a hard-coded limit to
+ the size of the message, primarily to avoid memory allocation while
+ calling die().
+
+ * When trying to see that an object does not exist, a state errno
+ leaked from our "first try to open a packfile with O_NOATIME and
+ then if it fails retry without it" logic on a system that refuses
+ O_NOATIME. This confused us and caused us to die, saying that the
+ packfile is unreadable, when we should have just reported that the
+ object does not exist in that packfile to the caller.
+
+ * An off-by-one error made "git remote" to mishandle a remote with a
+ single letter nickname.
+
+ * A handful of codepaths that used to use fixed-sized arrays to hold
+ pathnames have been corrected to use strbuf and other mechanisms to
+ allow longer pathnames without fearing overflows.
+
+Also contains typofixes, documentation updates and trivial code
+clean-ups.
diff --git a/RelNotes/2.5.3.adoc b/RelNotes/2.5.3.adoc
new file mode 100644
index 0000000..d143685
--- /dev/null
+++ b/RelNotes/2.5.3.adoc
@@ -0,0 +1,17 @@
+Git v2.5.3 Release Notes
+========================
+
+Fixes since v2.5.2
+------------------
+
+ * The experimental untracked-cache feature were buggy when paths with
+ a few levels of subdirectories are involved.
+
+ * Recent versions of scripted "git am" has a performance regression
+ in "git am --skip" codepath, which no longer exists in the
+ built-in version on the 'master' front. Fix the regression in
+ the last scripted version that appear in 2.5.x maintenance track
+ and older.
+
+Also contains typofixes, documentation updates and trivial code
+clean-ups.
diff --git a/RelNotes/2.5.4.adoc b/RelNotes/2.5.4.adoc
new file mode 100644
index 0000000..b8a2f93
--- /dev/null
+++ b/RelNotes/2.5.4.adoc
@@ -0,0 +1,18 @@
+Git v2.5.4 Release Notes
+========================
+
+Fixes since v2.5.4
+------------------
+
+ * xdiff code we use to generate diffs is not prepared to handle
+ extremely large files. It uses "int" in many places, which can
+ overflow if we have a very large number of lines or even bytes in
+ our input files, for example. Cap the input size to somewhere
+ around 1GB for now.
+
+ * Some protocols (like git-remote-ext) can execute arbitrary code
+ found in the URL. The URLs that submodules use may come from
+ arbitrary sources (e.g., .gitmodules files in a remote
+ repository), and can hurt those who blindly enable recursive
+ fetch. Restrict the allowed protocols to well known and safe
+ ones.
diff --git a/RelNotes/2.5.5.adoc b/RelNotes/2.5.5.adoc
new file mode 100644
index 0000000..37eae9a
--- /dev/null
+++ b/RelNotes/2.5.5.adoc
@@ -0,0 +1,11 @@
+Git v2.5.5 Release Notes
+========================
+
+Fixes since v2.5.4
+------------------
+
+ * Bugfix patches were backported from the 'master' front to plug heap
+ corruption holes, to catch integer overflow in the computation of
+ pathname lengths, and to get rid of the name_path API. Both of
+ these would have resulted in writing over an under-allocated buffer
+ when formulating pathnames while tree traversal.
diff --git a/RelNotes/2.5.6.adoc b/RelNotes/2.5.6.adoc
new file mode 100644
index 0000000..9cd025b
--- /dev/null
+++ b/RelNotes/2.5.6.adoc
@@ -0,0 +1,12 @@
+Git v2.5.6 Release Notes
+========================
+
+Fixes since v2.5.5
+------------------
+
+ * "git-shell" rejects a request to serve a repository whose name
+ begins with a dash, which makes it no longer possible to get it
+ confused into spawning service programs like "git-upload-pack" with
+ an option like "--help", which in turn would spawn an interactive
+ pager, instead of working with the repository user asked to access
+ (i.e. the one whose name is "--help").
diff --git a/RelNotes/2.6.0.adoc b/RelNotes/2.6.0.adoc
new file mode 100644
index 0000000..7288aaf
--- /dev/null
+++ b/RelNotes/2.6.0.adoc
@@ -0,0 +1,370 @@
+Git 2.6 Release Notes
+=====================
+
+Updates since v2.5
+------------------
+
+UI, Workflows & Features
+
+ * An asterisk as a substring (as opposed to the entirety) of a path
+ component for both side of a refspec, e.g.
+ "refs/heads/o*:refs/remotes/heads/i*", is now allowed.
+
+ * New userdiff pattern definition for fountain screenwriting markup
+ format has been added.
+
+ * "git log" and friends learned a new "--date=format:..." option to
+ format timestamps using system's strftime(3).
+
+ * "git fast-import" learned to respond to the get-mark command via
+ its cat-blob-fd interface.
+
+ * "git rebase -i" learned "drop commit-object-name subject" command
+ as another way to skip replaying of a commit.
+
+ * A new configuration variable can enable "--follow" automatically
+ when "git log" is run with one pathspec argument.
+
+ * "git status" learned to show a more detailed information regarding
+ the "rebase -i" session in progress.
+
+ * "git cat-file" learned "--batch-all-objects" option to enumerate all
+ available objects in the repository more quickly than "rev-list
+ --all --objects" (the output includes unreachable objects, though).
+
+ * "git fsck" learned to ignore errors on a set of known-to-be-bad
+ objects, and also allows the warning levels of various kinds of
+ non-critical breakages to be tweaked.
+
+ * "git rebase -i"'s list of todo is made configurable.
+
+ * "git send-email" now performs alias-expansion on names that are
+ given via --cccmd, etc.
+
+ * An environment variable GIT_REPLACE_REF_BASE tells Git to look into
+ refs hierarchy other than refs/replace/ for the object replacement
+ data.
+
+ * Allow untracked cache (experimental) to be used when sparse
+ checkout (experimental) is also in use.
+
+ * "git pull --rebase" has been taught to pay attention to
+ rebase.autostash configuration.
+
+ * The command-line completion script (in contrib/) has been updated.
+
+ * A negative !ref entry in multi-value transfer.hideRefs
+ configuration can be used to say "don't hide this one".
+
+ * After "git am" without "-3" stops, running "git am -3" pays attention
+ to "-3" only for the patch that caused the original invocation
+ to stop.
+
+ * When linked worktree is used, simultaneous "notes merge" instances
+ for the same ref in refs/notes/* are prevented from stomping on
+ each other.
+
+ * "git send-email" learned a new option --smtp-auth to limit the SMTP
+ AUTH mechanisms to be used to a subset of what the system library
+ supports.
+
+ * A new configuration variable http.sslVersion can be used to specify
+ what specific version of SSL/TLS to use to make a connection.
+
+ * "git notes merge" can be told with "--strategy=<how>" option how to
+ automatically handle conflicts; this can now be configured by
+ setting notes.mergeStrategy configuration variable.
+
+ * "git log --cc" did not show any patch, even though most of the time
+ the user meant "git log --cc -p -m" to see patch output for commits
+ with a single parent, and combined diff for merge commits. The
+ command is taught to DWIM "--cc" (without "--raw" and other forms
+ of output specification) to "--cc -p -m".
+
+ * "git config --list" output was hard to parse when values consist of
+ multiple lines. "--name-only" option is added to help this.
+
+ * A handful of usability & cosmetic fixes to gitk and l10n updates.
+
+ * A completely empty e-mail address <> is now allowed in the authors
+ file used by git-svn, to match the way it accepts the output from
+ authors-prog.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * In preparation for allowing different "backends" to store the refs
+ in a way different from the traditional "one ref per file in
+ $GIT_DIR or in a $GIT_DIR/packed-refs file" filesystem storage,
+ direct filesystem access to ref-like things like CHERRY_PICK_HEAD
+ from scripts and programs has been reduced.
+
+ * Computation of untracked status indicator by bash prompt
+ script (in contrib/) has been optimized.
+
+ * Memory use reduction when commit-slab facility is used to annotate
+ sparsely (which is not recommended in the first place).
+
+ * Clean up refs API and make "git clone" less intimate with the
+ implementation detail.
+
+ * "git pull" was reimplemented in C.
+
+ * The packet tracing machinery allows to capture an incoming pack
+ data to a file for debugging.
+
+ * Move machinery to parse human-readable scaled numbers like 1k, 4M,
+ and 2G as an option parameter's value from pack-objects to
+ parse-options API, to make it available to other codepaths.
+
+ * "git verify-tag" and "git verify-commit" have been taught to share
+ more code, and then learned to optionally show the verification
+ message from the underlying GPG implementation.
+
+ * Various enhancements around "git am" reading patches generated by
+ foreign SCM have been made.
+
+ * Ref listing by "git branch -l" and "git tag -l" commands has
+ started to be rebuilt, based on the for-each-ref machinery.
+
+ * The code to perform multi-tree merges has been taught to repopulate
+ the cache-tree upon a successful merge into the index, so that
+ subsequent "diff-index --cached" (hence "status") and "write-tree"
+ (hence "commit") will go faster.
+
+ The same logic in "git checkout" may now be removed, but that is a
+ separate issue.
+
+ * Tests that assume how reflogs are represented on the filesystem too
+ much have been corrected.
+
+ * "git am" has been rewritten in "C".
+
+ * git_path() and mkpath() are handy helper functions but it is easy
+ to misuse, as the callers need to be careful to keep the number of
+ active results below 4. Their uses have been reduced.
+
+ * The "lockfile" API has been rebuilt on top of a new "tempfile" API.
+
+ * To prepare for allowing a different "ref" backend to be plugged in
+ to the system, update_ref()/delete_ref() have been taught about
+ ref-like things like MERGE_HEAD that are per-worktree (they will
+ always be written to the filesystem inside $GIT_DIR).
+
+ * The gitmodules API that is accessed from the C code learned to
+ cache stuff lazily.
+
+
+Also contains various documentation updates and code clean-ups.
+
+
+Fixes since v2.5
+----------------
+
+Unless otherwise noted, all the fixes since v2.5 in the maintenance
+track are contained in this release (see the maintenance releases'
+notes for details).
+
+ * "git subtree" (in contrib/) depended on "git log" output to be
+ stable, which was a no-no. Apply a workaround to force a
+ particular date format.
+ (merge e7aac44 da/subtree-date-confusion later to maint).
+
+ * An attempt to delete a ref by pushing into a repository whose HEAD
+ symbolic reference points at an unborn branch that cannot be
+ created due to ref D/F conflict (e.g. refs/heads/a/b exists, HEAD
+ points at refs/heads/a) failed.
+ (merge b112b14 jx/do-not-crash-receive-pack-wo-head later to maint).
+
+ * The low-level "git send-pack" did not honor 'user.signingkey'
+ configuration variable when sending a signed-push.
+ (merge d830d39 db/send-pack-user-signingkey later to maint).
+
+ * "sparse checkout" misbehaved for a path that is excluded from the
+ checkout when switching between branches that differ at the path.
+ (merge 7d78241 as/sparse-checkout-removal later to maint).
+
+ * An experimental "untracked cache" feature used uname(2) in a
+ slightly unportable way.
+ (merge 100e433 cb/uname-in-untracked later to maint).
+
+ * A "rebase" replays changes of the local branch on top of something
+ else, as such they are placed in stage #3 and referred to as
+ "theirs", while the changes in the new base, typically a foreign
+ work, are placed in stage #2 and referred to as "ours". Clarify
+ the "checkout --ours/--theirs".
+ (merge f303016 se/doc-checkout-ours-theirs later to maint).
+
+ * The "rev-parse --parseopt" mode parsed the option specification
+ and the argument hint in a strange way to allow '=' and other
+ special characters in the option name while forbidding them from
+ the argument hint. This made it impossible to define an option
+ like "--pair <key>=<value>" with "pair=key=value" specification,
+ which instead would have defined a "--pair=key <value>" option.
+ (merge 2d893df ib/scripted-parse-opt-better-hint-string later to maint).
+
+ * Often a fast-import stream builds a new commit on top of the
+ previous commit it built, and it often unconditionally emits a
+ "from" command to specify the first parent, which can be omitted in
+ such a case. This caused fast-import to forget the tree of the
+ previous commit and then re-read it from scratch, which was
+ inefficient. Optimize for this common case.
+ (merge 0df3245 mh/fast-import-optimize-current-from later to maint).
+
+ * Running an aliased command from a subdirectory when the .git thing
+ in the working tree is a gitfile pointing elsewhere did not work.
+ (merge d95138e nd/export-worktree later to maint).
+
+ * "Is this subdirectory a separate repository that should not be
+ touched?" check "git clean" was inefficient. This was replaced
+ with a more optimized check.
+ (merge fbf2fec ee/clean-remove-dirs later to maint).
+
+ * The "new-worktree-mode" hack in "checkout" that was added in
+ nd/multiple-work-trees topic has been removed by updating the
+ implementation of new "worktree add".
+ (merge 65f9b75 es/worktree-add-cleanup later to maint).
+
+ * Remove remaining cruft from "git checkout --to", which
+ transitioned to "git worktree add".
+ (merge 114ff88 es/worktree-add later to maint).
+
+ * An off-by-one error made "git remote" to mishandle a remote with a
+ single letter nickname.
+ (merge bc598c3 mh/get-remote-group-fix later to maint).
+
+ * "git clone $URL", when cloning from a site whose sole purpose is to
+ host a single repository (hence, no path after <scheme>://<site>/),
+ tried to use the site name as the new repository name, but did not
+ remove username or password when <site> part was of the form
+ <user>@<pass>:<host>. The code is taught to redact these.
+ (merge adef956 ps/guess-repo-name-at-root later to maint).
+
+ * Running tests with the "-x" option to make them verbose had some
+ unpleasant interactions with other features of the test suite.
+ (merge 9b5fe78 jk/test-with-x later to maint).
+
+ * t1509 test that requires a dedicated VM environment had some
+ bitrot, which has been corrected.
+ (merge faacc5a ps/t1509-chroot-test-fixup later to maint).
+
+ * "git pull" in recent releases of Git has a regression in the code
+ that allows custom path to the --upload-pack=<program>. This has
+ been corrected.
+
+ Note that this is irrelevant for 'master' with "git pull" rewritten
+ in C.
+ (merge 13e0e28 mm/pull-upload-pack later to maint).
+
+ * When trying to see that an object does not exist, a state errno
+ leaked from our "first try to open a packfile with O_NOATIME and
+ then if it fails retry without it" logic on a system that refuses
+ O_NOATIME. This confused us and caused us to die, saying that the
+ packfile is unreadable, when we should have just reported that the
+ object does not exist in that packfile to the caller.
+ (merge dff6f28 cb/open-noatime-clear-errno later to maint).
+
+ * The codepath to produce error messages had a hard-coded limit to
+ the size of the message, primarily to avoid memory allocation while
+ calling die().
+ (merge f4c3edc jk/long-error-messages later to maint).
+
+ * strbuf_read() used to have one extra iteration (and an unnecessary
+ strbuf_grow() of 8kB), which was eliminated.
+ (merge 3ebbd00 jh/strbuf-read-use-read-in-full later to maint).
+
+ * We rewrote one of the build scripts in Perl but this reimplements
+ in Bourne shell.
+ (merge 57cee8a sg/help-group later to maint).
+
+ * The experimental untracked-cache feature were buggy when paths with
+ a few levels of subdirectories are involved.
+ (merge 73f9145 dt/untracked-subdir later to maint).
+
+ * "interpret-trailers" helper mistook a single-liner log message that
+ has a colon as the end of existing trailer.
+
+ * The "interpret-trailers" helper mistook a multi-paragraph title of
+ a commit log message with a colon in it as the end of the trailer
+ block.
+ (merge 5c99995 cc/trailers-corner-case-fix later to maint).
+
+ * "git describe" without argument defaulted to describe the HEAD
+ commit, but "git describe --contains" didn't. Arguably, in a
+ repository used for active development, such defaulting would not
+ be very useful as the tip of branch is typically not tagged, but it
+ is better to be consistent.
+ (merge 2bd0706 sg/describe-contains later to maint).
+
+ * The client side codepaths in "git push" have been cleaned up
+ and the user can request to perform an optional "signed push",
+ i.e. sign only when the other end accepts signed push.
+ (merge 68c757f db/push-sign-if-asked later to maint).
+
+ * Because the configuration system does not allow "alias.0foo" and
+ "pager.0foo" as the configuration key, the user cannot use '0foo'
+ as a custom command name anyway, but "git 0foo" tried to look these
+ keys up and emitted useless warnings before saying '0foo is not a
+ git command'. These warning messages have been squelched.
+ (merge 9e9de18 jk/fix-alias-pager-config-key-warnings later to maint).
+
+ * "git rev-list" does not take "--notes" option, but did not complain
+ when one is given.
+ (merge 2aea7a5 jk/rev-list-has-no-notes later to maint).
+
+ * When re-priming the cache-tree opportunistically while committing
+ the in-core index as-is, we mistakenly invalidated the in-core
+ index too aggressively, causing the experimental split-index code
+ to unnecessarily rewrite the on-disk index file(s).
+ (merge 475a344 dt/commit-preserve-base-index-upon-opportunistic-cache-tree-update later to maint).
+
+ * "git archive" did not use zip64 extension when creating an archive
+ with more than 64k entries, which nobody should need, right ;-)?
+ (merge 88329ca rs/archive-zip-many later to maint).
+
+ * The code in "multiple-worktree" support that attempted to recover
+ from an inconsistent state updated an incorrect file.
+ (merge 82fde87 nd/fixup-linked-gitdir later to maint).
+
+ * On case insensitive systems, "git p4" did not work well with client
+ specs.
+
+ * "git init empty && git -C empty log" said "bad default revision 'HEAD'",
+ which was found to be a bit confusing to new users.
+ (merge ce11360 jk/log-missing-default-HEAD later to maint).
+
+ * Recent versions of scripted "git am" has a performance regression in
+ "git am --skip" codepath, which no longer exists in the built-in
+ version on the 'master' front. Fix the regression in the last
+ scripted version that appear in 2.5.x maintenance track and older.
+ (merge b9d6689 js/maint-am-skip-performance-regression later to maint).
+
+ * The branch descriptions that are set with "git branch --edit-description"
+ option were used in many places but they weren't clearly documented.
+ (merge 561d2b7 po/doc-branch-desc later to maint).
+
+ * Code cleanups and documentation updates.
+ (merge 1c601af es/doc-clean-outdated-tools later to maint).
+ (merge 3581304 kn/tag-doc-fix later to maint).
+ (merge 3a59e59 kb/i18n-doc later to maint).
+ (merge 45abdee sb/remove-unused-var-from-builtin-add later to maint).
+ (merge 14691e3 sb/parse-options-codeformat later to maint).
+ (merge 4a6ada3 ad/bisect-cleanup later to maint).
+ (merge da4c5ad ta/docfix-index-format-tech later to maint).
+ (merge ae25fd3 sb/check-return-from-read-ref later to maint).
+ (merge b3325df nd/dwim-wildcards-as-pathspecs later to maint).
+ (merge 7aa9b9b sg/wt-status-header-inclusion later to maint).
+ (merge f04c690 as/docfix-reflog-expire-unreachable later to maint).
+ (merge 1269847 sg/t3020-typofix later to maint).
+ (merge 8b54c23 jc/calloc-pathspec later to maint).
+ (merge a6926b8 po/po-readme later to maint).
+ (merge 54d160e ss/fix-config-fd-leak later to maint).
+ (merge b80fa84 ah/submodule-typofix-in-error later to maint).
+ (merge 99885bc ah/reflog-typofix-in-error later to maint).
+ (merge 9476c2c ah/read-tree-usage-string later to maint).
+ (merge b8c1d27 ah/pack-objects-usage-strings later to maint).
+ (merge 486e1e1 br/svn-doc-include-paths-config later to maint).
+ (merge 1733ed3 ee/clean-test-fixes later to maint).
+ (merge 5fcadc3 gb/apply-comment-typofix later to maint).
+ (merge b894d3e mp/t7060-diff-index-test later to maint).
+ (merge d238710 as/config-doc-markup-fix later to maint).
diff --git a/RelNotes/2.6.1.adoc b/RelNotes/2.6.1.adoc
new file mode 100644
index 0000000..f37ea89
--- /dev/null
+++ b/RelNotes/2.6.1.adoc
@@ -0,0 +1,18 @@
+Git v2.6.1 Release Notes
+========================
+
+Fixes since v2.6
+----------------
+
+ * xdiff code we use to generate diffs is not prepared to handle
+ extremely large files. It uses "int" in many places, which can
+ overflow if we have a very large number of lines or even bytes in
+ our input files, for example. Cap the input size to somewhere
+ around 1GB for now.
+
+ * Some protocols (like git-remote-ext) can execute arbitrary code
+ found in the URL. The URLs that submodules use may come from
+ arbitrary sources (e.g., .gitmodules files in a remote
+ repository), and can hurt those who blindly enable recursive
+ fetch. Restrict the allowed protocols to well known and safe
+ ones.
diff --git a/RelNotes/2.6.2.adoc b/RelNotes/2.6.2.adoc
new file mode 100644
index 0000000..5b65e35
--- /dev/null
+++ b/RelNotes/2.6.2.adoc
@@ -0,0 +1,65 @@
+Git v2.6.2 Release Notes
+========================
+
+Fixes since v2.6.1
+------------------
+
+ * There were some classes of errors that "git fsck" diagnosed to its
+ standard error that did not cause it to exit with non-zero status.
+
+ * A test script for the HTTP service had a timing dependent bug,
+ which was fixed.
+
+ * Performance-measurement tests did not work without an installed Git.
+
+ * On a case insensitive filesystems, setting GIT_WORK_TREE variable
+ using a random cases that does not agree with what the filesystem
+ thinks confused Git that it wasn't inside the working tree.
+
+ * When "git am" was rewritten as a built-in, it stopped paying
+ attention to user.signingkey, which was fixed.
+
+ * After "git checkout --detach", "git status" reported a fairly
+ useless "HEAD detached at HEAD", instead of saying at which exact
+ commit.
+
+ * "git rebase -i" had a minor regression recently, which stopped
+ considering a line that begins with an indented '#' in its insn
+ sheet not a comment, which is now fixed.
+
+ * Description of the "log.follow" configuration variable in "git log"
+ documentation is now also copied to "git config" documentation.
+
+ * Allocation related functions and stdio are unsafe things to call
+ inside a signal handler, and indeed killing the pager can cause
+ glibc to deadlock waiting on allocation mutex as our signal handler
+ tries to free() some data structures in wait_for_pager(). Reduce
+ these unsafe calls.
+
+ * The way how --ref/--notes to specify the notes tree reference are
+ DWIMmed was not clearly documented.
+
+ * Customization to change the behaviour with "make -w" and "make -s"
+ in our Makefile was broken when they were used together.
+
+ * The Makefile always runs the library archiver with hardcoded "crs"
+ options, which was inconvenient for exotic platforms on which
+ people want to use programs with totally different set of command
+ line options.
+
+ * The ssh transport, just like any other transport over the network,
+ did not clear GIT_* environment variables, but it is possible to
+ use SendEnv and AcceptEnv to leak them to the remote invocation of
+ Git, which is not a good idea at all. Explicitly clear them just
+ like we do for the local transport.
+
+ * "git blame --first-parent v1.0..v2.0" was not rejected but did not
+ limit the blame to commits on the first parent chain.
+
+ * Very small number of options take a parameter that is optional
+ (which is not a great UI element as they can only appear at the end
+ of the command line). Add notice to documentation of each and
+ every one of them.
+
+Also contains typofixes, documentation updates and trivial code
+clean-ups.
diff --git a/RelNotes/2.6.3.adoc b/RelNotes/2.6.3.adoc
new file mode 100644
index 0000000..fc6fe17
--- /dev/null
+++ b/RelNotes/2.6.3.adoc
@@ -0,0 +1,111 @@
+Git v2.6.3 Release Notes
+========================
+
+Fixes since v2.6.2
+------------------
+
+ * The error message from "git blame --contents --reverse" incorrectly
+ talked about "--contents --children".
+
+ * "git merge-file" tried to signal how many conflicts it found, which
+ obviously would not work well when there are too many of them.
+
+ * The name-hash subsystem that is used to cope with case insensitive
+ filesystems keeps track of directories and their on-filesystem
+ cases for all the paths in the index by holding a pointer to a
+ randomly chosen cache entry that is inside the directory (for its
+ ce->ce_name component). This pointer was not updated even when the
+ cache entry was removed from the index, leading to use after free.
+ This was fixed by recording the path for each directory instead of
+ borrowing cache entries and restructuring the API somewhat.
+
+ * When the "git am" command was reimplemented in C, "git am -3" had a
+ small regression where it is aborted in its error handling codepath
+ when underlying merge-recursive failed in some ways.
+
+ * The synopsis text and the usage string of subcommands that read
+ list of things from the standard input are often shown as if they
+ only take input from a file on a filesystem, which was misleading.
+
+ * A couple of commands still showed "[options]" in their usage string
+ to note where options should come on their command line, but we
+ spell that "[<options>]" in most places these days.
+
+ * The submodule code has been taught to work better with separate
+ work trees created via "git worktree add".
+
+ * When "git gc --auto" is backgrounded, its diagnosis message is
+ lost. It now is saved to a file in $GIT_DIR and is shown next time
+ the "gc --auto" is run.
+
+ * Work around "git p4" failing when the P4 depot records the contents
+ in UTF-16 without UTF-16 BOM.
+
+ * Recent update to "rebase -i" that tries to sanity check the edited
+ insn sheet before it uses it has become too picky on Windows where
+ CRLF left by the editor is turned into a trailing CR on the line
+ read via the "read" built-in command.
+
+ * "git clone --dissociate" runs a big "git repack" process at the
+ end, and it helps to close file descriptors that are open on the
+ packs and their idx files before doing so on filesystems that
+ cannot remove a file that is still open.
+
+ * Correct "git p4 --detect-labels" so that it does not fail to create
+ a tag that points at a commit that is also being imported.
+
+ * The internal stripspace() function has been moved to where it
+ logically belongs to, i.e. strbuf API, and the command line parser
+ of "git stripspace" has been updated to use the parse_options API.
+
+ * Prepare for Git on-disk repository representation to undergo
+ backward incompatible changes by introducing a new repository
+ format version "1", with an extension mechanism.
+
+ * "git gc" used to barf when a symbolic ref has gone dangling
+ (e.g. the branch that used to be your upstream's default when you
+ cloned from it is now gone, and you did "fetch --prune").
+
+ * The normalize_ceiling_entry() function does not muck with the end
+ of the path it accepts, and the real world callers do rely on that,
+ but a test insisted that the function drops a trailing slash.
+
+ * "git gc" is safe to run anytime only because it has the built-in
+ grace period to protect young objects. In order to run with no
+ grace period, the user must make sure that the repository is
+ quiescent.
+
+ * A recent "filter-branch --msg-filter" broke skipping of the commit
+ object header, which is fixed.
+
+ * "git --literal-pathspecs add -u/-A" without any command line
+ argument misbehaved ever since Git 2.0.
+
+ * Merging a branch that removes a path and another that changes the
+ mode bits on the same path should have conflicted at the path, but
+ it didn't and silently favoured the removal.
+
+ * "git imap-send" did not compile well with older version of cURL library.
+
+ * The linkage order of libraries was wrong in places around libcurl.
+
+ * It was not possible to use a repository-lookalike created by "git
+ worktree add" as a local source of "git clone".
+
+ * When "git send-email" wanted to talk over Net::SMTP::SSL,
+ Net::Cmd::datasend() did not like to be fed too many bytes at the
+ same time and failed to send messages. Send the payload one line
+ at a time to work around the problem.
+
+ * We peek objects from submodule's object store by linking it to the
+ list of alternate object databases, but the code to do so forgot to
+ correctly initialize the list.
+
+ * "git status --branch --short" accessed beyond the constant string
+ "HEAD", which has been corrected.
+
+ * "git daemon" uses "run_command()" without "finish_command()", so it
+ needs to release resources itself, which it forgot to do.
+
+Also contains typofixes, documentation updates and trivial code
+clean-ups.
diff --git a/RelNotes/2.6.4.adoc b/RelNotes/2.6.4.adoc
new file mode 100644
index 0000000..b0256a2
--- /dev/null
+++ b/RelNotes/2.6.4.adoc
@@ -0,0 +1,63 @@
+Git v2.6.4 Release Notes
+========================
+
+Fixes since v2.6.3
+------------------
+
+ * The "configure" script did not test for -lpthread correctly, which
+ upset some linkers.
+
+ * Add support for talking http/https over socks proxy.
+
+ * Portability fix for Windows, which may rewrite $SHELL variable using
+ non-POSIX paths.
+
+ * We now consistently allow all hooks to ignore their standard input,
+ rather than having git complain of SIGPIPE.
+
+ * Fix shell quoting in contrib script.
+
+ * Test portability fix for a topic in v2.6.1.
+
+ * Allow tilde-expansion in some http config variables.
+
+ * Give a useful special case "diff/show --word-diff-regex=." as an
+ example in the documentation.
+
+ * Fix for a corner case in filter-branch.
+
+ * Make git-p4 work on a detached head.
+
+ * Documentation clarification for "check-ignore" without "--verbose".
+
+ * Just like the working tree is cleaned up when the user cancelled
+ submission in P4Submit.applyCommit(), clean up the mess if "p4
+ submit" fails.
+
+ * Having a leftover .idx file without corresponding .pack file in
+ the repository hurts performance; "git gc" learned to prune them.
+
+ * The code to prepare the working tree side of temporary directory
+ for the "dir-diff" feature forgot that symbolic links need not be
+ copied (or symlinked) to the temporary area, as the code already
+ special cases and overwrites them. Besides, it was wrong to try
+ computing the object name of the target of symbolic link, which may
+ not even exist or may be a directory.
+
+ * There was no way to defeat a configured rebase.autostash variable
+ from the command line, as "git rebase --no-autostash" was missing.
+
+ * Allow "git interpret-trailers" to run outside of a Git repository.
+
+ * Produce correct "dirty" marker for shell prompts, even when we
+ are on an orphan or an unborn branch.
+
+ * Some corner cases have been fixed in string-matching done in "git
+ status".
+
+ * Apple's common crypto implementation of SHA1_Update() does not take
+ more than 4GB at a time, and we now have a compile-time workaround
+ for it.
+
+Also contains typofixes, documentation updates and trivial code
+clean-ups.
diff --git a/RelNotes/2.6.5.adoc b/RelNotes/2.6.5.adoc
new file mode 100644
index 0000000..f0924b6
--- /dev/null
+++ b/RelNotes/2.6.5.adoc
@@ -0,0 +1,58 @@
+Git v2.6.5 Release Notes
+========================
+
+Fixes since v2.6.4
+------------------
+
+ * Because "test_when_finished" in our test framework queues the
+ clean-up tasks to be done in a shell variable, it should not be
+ used inside a subshell. Add a mechanism to allow 'bash' to catch
+ such uses, and fix the ones that were found.
+
+ * Update "git subtree" (in contrib/) so that it can take whitespaces
+ in the pathnames, not only in the in-tree pathname but the name of
+ the directory that the repository is in.
+
+ * Cosmetic improvement to lock-file error messages.
+
+ * mark_tree_uninteresting() has code to handle the case where it gets
+ passed a NULL pointer in its 'tree' parameter, but the function had
+ 'object = &tree->object' assignment before checking if tree is
+ NULL. This gives a compiler an excuse to declare that tree will
+ never be NULL and apply a wrong optimization. Avoid it.
+
+ * The helper used to iterate over loose object directories to prune
+ stale objects did not closedir() immediately when it is done with a
+ directory--a callback such as the one used for "git prune" may want
+ to do rmdir(), but it would fail on open directory on platforms
+ such as WinXP.
+
+ * "git p4" used to import Perforce CLs that touch only paths outside
+ the client spec as empty commits. It has been corrected to ignore
+ them instead, with a new configuration git-p4.keepEmptyCommits as a
+ backward compatibility knob.
+
+ * The exit code of git-fsck did not reflect some types of errors
+ found in packed objects, which has been corrected.
+
+ * The completion script (in contrib/) used to list "git column"
+ (which is not an end-user facing command) as one of the choices
+
+ * Improve error reporting when SMTP TLS fails.
+
+ * When getpwuid() on the system returned NULL (e.g. the user is not
+ in the /etc/passwd file or other uid-to-name mappings), the
+ codepath to find who the user is to record it in the reflog barfed
+ and died. Loosen the check in this codepath, which already accepts
+ questionable ident string (e.g. host part of the e-mail address is
+ obviously bogus), and in general when we operate fmt_ident() function
+ in non-strict mode.
+
+ * "git symbolic-ref" forgot to report a failure with its exit status.
+
+ * History traversal with "git log --source" that starts with an
+ annotated tag failed to report the tag as "source", due to an
+ old regression in the command line parser back in v2.2 days.
+
+Also contains typofixes, documentation updates and trivial code
+clean-ups.
diff --git a/RelNotes/2.6.6.adoc b/RelNotes/2.6.6.adoc
new file mode 100644
index 0000000..023ad85
--- /dev/null
+++ b/RelNotes/2.6.6.adoc
@@ -0,0 +1,11 @@
+Git v2.6.6 Release Notes
+========================
+
+Fixes since v2.6.5
+------------------
+
+ * Bugfix patches were backported from the 'master' front to plug heap
+ corruption holes, to catch integer overflow in the computation of
+ pathname lengths, and to get rid of the name_path API. Both of
+ these would have resulted in writing over an under-allocated buffer
+ when formulating pathnames while tree traversal.
diff --git a/RelNotes/2.6.7.adoc b/RelNotes/2.6.7.adoc
new file mode 100644
index 0000000..1335de4
--- /dev/null
+++ b/RelNotes/2.6.7.adoc
@@ -0,0 +1,12 @@
+Git v2.6.7 Release Notes
+========================
+
+Fixes since v2.6.6
+------------------
+
+ * "git-shell" rejects a request to serve a repository whose name
+ begins with a dash, which makes it no longer possible to get it
+ confused into spawning service programs like "git-upload-pack" with
+ an option like "--help", which in turn would spawn an interactive
+ pager, instead of working with the repository user asked to access
+ (i.e. the one whose name is "--help").
diff --git a/RelNotes/2.7.0.adoc b/RelNotes/2.7.0.adoc
new file mode 100644
index 0000000..e3cbf3a
--- /dev/null
+++ b/RelNotes/2.7.0.adoc
@@ -0,0 +1,414 @@
+Git 2.7 Release Notes
+=====================
+
+Updates since v2.6
+------------------
+
+UI, Workflows & Features
+
+ * The appearance of "gitk", particularly on high DPI monitors, have
+ been improved. "gitk" also comes with an undated translation for
+ Swedish and Japanese.
+
+ * "git remote" learned "get-url" subcommand to show the URL for a
+ given remote name used for fetching and pushing.
+
+ * There was no way to defeat a configured rebase.autostash variable
+ from the command line, as "git rebase --no-autostash" was missing.
+
+ * "git log --date=local" used to only show the normal (default)
+ format in the local timezone. The command learned to take 'local'
+ as an instruction to use the local timezone with other formats,
+
+ * The refs used during a "git bisect" session is now per-worktree so
+ that independent bisect sessions can be done in different worktrees
+ created with "git worktree add".
+
+ * Users who are too busy to type three extra keystrokes to ask for
+ "git stash show -p" can now set stash.showPatch configuration
+ variable to true to always see the actual patch, not just the list
+ of paths affected with feel for the extent of damage via diffstat.
+
+ * "quiltimport" allows to specify the series file by honoring the
+ $QUILT_SERIES environment and also --series command line option.
+
+ * The use of 'good/bad' in "git bisect" made it confusing to use when
+ hunting for a state change that is not a regression (e.g. bugfix).
+ The command learned 'old/new' and then allows the end user to
+ say e.g. "bisect start --term-old=fast --term-new=slow" to find a
+ performance regression.
+
+ * "git interpret-trailers" can now run outside of a Git repository.
+
+ * "git p4" learned to re-encode the pathname it uses to communicate
+ with the p4 depot with a new option.
+
+ * Give progress meter to "git filter-branch".
+
+ * Allow a later "!/abc/def" to override an earlier "/abc" that
+ appears in the same .gitignore file to make it easier to express
+ "everything in /abc directory is ignored, except for ...".
+
+ * Teach "git p4" to send large blobs outside the repository by
+ talking to Git LFS.
+
+ * Prepare for Git on-disk repository representation to undergo
+ backward incompatible changes by introducing a new repository
+ format version "1", with an extension mechanism.
+
+ * "git worktree" learned a "list" subcommand.
+
+ * "git clone --dissociate" learned that it can be used even when
+ "--reference" was not used at the same time.
+
+ * "git blame" learnt to take "--first-parent" and "--reverse" at the
+ same time when it makes sense.
+
+ * "git checkout" did not follow the usual "--[no-]progress"
+ convention and implemented only "--quiet" that is essentially
+ a superset of "--no-progress". Extend the command to support the
+ usual "--[no-]progress".
+
+ * The semantics of transfer.hideRefs configuration variable have been
+ extended to work better with the ref "namespace" feature that lets
+ you throw unrelated bunches of repositories in a single physical
+ repository and virtually serve them as separate ones.
+
+ * send-email config variables whose values are pathnames now go
+ through the ~username/ expansion.
+
+ * bash completion learnt to TAB-complete recipient addresses given
+ to send-email.
+
+ * The credential-cache daemon can be told to ignore SIGHUP to work
+ around issue when running Git from inside emacs.
+
+ * "git push" learned new configuration for doing "--recurse-submodules"
+ on each push.
+
+ * "format-patch" has learned a new option to zero-out the commit
+ object name on the mbox "From " line.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * The infrastructure to rewrite "git submodule" in C is being built
+ incrementally. Let's polish these early parts well enough and make
+ them graduate to 'next' and 'master', so that the more involved
+ follow-up can start cooking on a solid ground.
+
+ * Some features from "git tag -l" and "git branch -l" have been made
+ available to "git for-each-ref" so that eventually the unified
+ implementation can be shared across all three. The version merged
+ to the 'master' branch earlier had a performance regression in "tag
+ --contains", which has since been corrected.
+
+ * Because "test_when_finished" in our test framework queues the
+ clean-up tasks to be done in a shell variable, it should not be
+ used inside a subshell. Add a mechanism to allow 'bash' to catch
+ such uses, and fix the ones that were found.
+
+ * The debugging infrastructure for pkt-line based communication has
+ been improved to mark the side-band communication specifically.
+
+ * Update "git branch" that list existing branches, using the
+ ref-filter API that is shared with "git tag" and "git
+ for-each-ref".
+
+ * The test for various line-ending conversions has been enhanced.
+
+ * A few test scripts around "git p4" have been improved for
+ portability.
+
+ * Many allocations that is manually counted (correctly) that are
+ followed by strcpy/sprintf have been replaced with a less error
+ prone constructs such as xstrfmt.
+
+ * The internal stripspace() function has been moved to where it
+ logically belongs to, i.e. strbuf API, and the command line parser
+ of "git stripspace" has been updated to use the parse_options API.
+
+ * "git am" used to spawn "git mailinfo" via run_command() API once
+ per each patch, but learned to make a direct call to mailinfo()
+ instead.
+
+ * The implementation of "git mailinfo" was refactored so that a
+ mailinfo() function can be directly called from inside a process.
+
+ * With a "debug" helper, debugging of a single "git" invocation in
+ our test scripts has become a lot easier.
+
+ * The "configure" script did not test for -lpthread correctly, which
+ upset some linkers.
+
+ * Cross completed task off of subtree project's todo list.
+
+ * Test cleanups for the subtree project.
+
+ * Clean up style in an ancient test t9300.
+
+ * Work around some test flakiness with p4d.
+
+ * Fsck did not correctly detect a NUL-truncated header in a tag.
+
+ * Use a safer behavior when we hit errors verifying remote certificates.
+
+ * Speed up filter-branch for cases where we only care about rewriting
+ commits, not tree data.
+
+ * The parse-options API has been updated to make "-h" command line
+ option work more consistently in all commands.
+
+ * "git svn rebase/mkdirs" got optimized by keeping track of empty
+ directories better.
+
+ * Fix some racy client/server tests by treating SIGPIPE the same as a
+ normal non-zero exit.
+
+ * The necessary infrastructure to build topics using the free Travis
+ CI has been added. Developers forking from this topic (and enabling
+ Travis) can do their own builds, and we can turn on auto-builds for
+ git/git (including build-status for pull requests that people
+ open).
+
+ * The write(2) emulation for Windows learned to set errno to EPIPE
+ when necessary.
+
+
+Also contains various documentation updates and code clean-ups.
+
+
+Fixes since v2.6
+----------------
+
+Unless otherwise noted, all the fixes since v2.6 in the maintenance
+track are contained in this release (see the maintenance releases'
+notes for details).
+
+ * Very small number of options take a parameter that is optional
+ (which is not a great UI element as they can only appear at the end
+ of the command line). Add notice to documentation of each and
+ every one of them.
+
+ * "git blame --first-parent v1.0..v2.0" was not rejected but did not
+ limit the blame to commits on the first parent chain.
+
+ * "git subtree" (in contrib/) now can take whitespaces in the
+ pathnames, not only in the in-tree pathname but the name of the
+ directory that the repository is in.
+
+ * The ssh transport, just like any other transport over the network,
+ did not clear GIT_* environment variables, but it is possible to
+ use SendEnv and AcceptEnv to leak them to the remote invocation of
+ Git, which is not a good idea at all. Explicitly clear them just
+ like we do for the local transport.
+
+ * Correct "git p4 --detect-labels" so that it does not fail to create
+ a tag that points at a commit that is also being imported.
+
+ * The Makefile always runs the library archiver with hardcoded "crs"
+ options, which was inconvenient for exotic platforms on which
+ people want to use programs with totally different set of command
+ line options.
+
+ * Customization to change the behaviour with "make -w" and "make -s"
+ in our Makefile was broken when they were used together.
+
+ * Allocation related functions and stdio are unsafe things to call
+ inside a signal handler, and indeed killing the pager can cause
+ glibc to deadlock waiting on allocation mutex as our signal handler
+ tries to free() some data structures in wait_for_pager(). Reduce
+ these unsafe calls.
+
+ * The way how --ref/--notes to specify the notes tree reference are
+ DWIMmed was not clearly documented.
+
+ * "git gc" used to barf when a symbolic ref has gone dangling
+ (e.g. the branch that used to be your upstream's default when you
+ cloned from it is now gone, and you did "fetch --prune").
+
+ * "git clone --dissociate" runs a big "git repack" process at the
+ end, and it helps to close file descriptors that are open on the
+ packs and their idx files before doing so on filesystems that
+ cannot remove a file that is still open.
+
+ * Description of the "log.follow" configuration variable in "git log"
+ documentation is now also copied to "git config" documentation.
+
+ * "git rebase -i" had a minor regression recently, which stopped
+ considering a line that begins with an indented '#' in its insn
+ sheet not a comment. Further, the code was still too picky on
+ Windows where CRLF left by the editor is turned into a trailing CR
+ on the line read via the "read" built-in command of bash. Both of
+ these issues are now fixed.
+
+ * After "git checkout --detach", "git status" reported a fairly
+ useless "HEAD detached at HEAD", instead of saying at which exact
+ commit.
+
+ * When "git send-email" wanted to talk over Net::SMTP::SSL,
+ Net::Cmd::datasend() did not like to be fed too many bytes at the
+ same time and failed to send messages. Send the payload one line
+ at a time to work around the problem.
+
+ * When "git am" was rewritten as a built-in, it stopped paying
+ attention to user.signingkey, which was fixed.
+
+ * It was not possible to use a repository-lookalike created by "git
+ worktree add" as a local source of "git clone".
+
+ * On a case insensitive filesystems, setting GIT_WORK_TREE variable
+ using a random cases that does not agree with what the filesystem
+ thinks confused Git that it wasn't inside the working tree.
+
+ * Performance-measurement tests did not work without an installed Git.
+
+ * A test script for the HTTP service had a timing dependent bug,
+ which was fixed.
+
+ * There were some classes of errors that "git fsck" diagnosed to its
+ standard error that did not cause it to exit with non-zero status.
+
+ * Work around "git p4" failing when the P4 depot records the contents
+ in UTF-16 without UTF-16 BOM.
+
+ * When "git gc --auto" is backgrounded, its diagnosis message is
+ lost. Save it to a file in $GIT_DIR and show it next time the "gc
+ --auto" is run.
+
+ * The submodule code has been taught to work better with separate
+ work trees created via "git worktree add".
+
+ * "git gc" is safe to run anytime only because it has the built-in
+ grace period to protect young objects. In order to run with no
+ grace period, the user must make sure that the repository is
+ quiescent.
+
+ * A recent "filter-branch --msg-filter" broke skipping of the commit
+ object header, which is fixed.
+
+ * The normalize_ceiling_entry() function does not muck with the end
+ of the path it accepts, and the real world callers do rely on that,
+ but a test insisted that the function drops a trailing slash.
+
+ * A test for interaction between untracked cache and sparse checkout
+ added in Git 2.5 days were flaky.
+
+ * A couple of commands still showed "[options]" in their usage string
+ to note where options should come on their command line, but we
+ spell that "[<options>]" in most places these days.
+
+ * The synopsis text and the usage string of subcommands that read
+ list of things from the standard input are often shown as if they
+ only take input from a file on a filesystem, which was misleading.
+
+ * "git am -3" had a small regression where it is aborted in its error
+ handling codepath when underlying merge-recursive failed in certain
+ ways, as it assumed that the internal call to merge-recursive will
+ never die, which is not the case (yet).
+
+ * The linkage order of libraries was wrong in places around libcurl.
+
+ * The name-hash subsystem that is used to cope with case insensitive
+ filesystems keeps track of directories and their on-filesystem
+ cases for all the paths in the index by holding a pointer to a
+ randomly chosen cache entry that is inside the directory (for its
+ ce->ce_name component). This pointer was not updated even when the
+ cache entry was removed from the index, leading to use after free.
+ This was fixed by recording the path for each directory instead of
+ borrowing cache entries and restructuring the API somewhat.
+
+ * "git merge-file" tried to signal how many conflicts it found, which
+ obviously would not work well when there are too many of them.
+
+ * The error message from "git blame --contents --reverse" incorrectly
+ talked about "--contents --children".
+
+ * "git imap-send" did not compile well with older version of cURL library.
+
+ * Merging a branch that removes a path and another that changes the
+ mode bits on the same path should have conflicted at the path, but
+ it didn't and silently favoured the removal.
+
+ * "git --literal-pathspecs add -u/-A" without any command line
+ argument misbehaved ever since Git 2.0.
+
+ * "git daemon" uses "run_command()" without "finish_command()", so it
+ needs to release resources itself, which it forgot to do.
+
+ * "git status --branch --short" accessed beyond the constant string
+ "HEAD", which has been corrected.
+
+ * We peek objects from submodule's object store by linking it to the
+ list of alternate object databases, but the code to do so forgot to
+ correctly initialize the list.
+
+ * The code to prepare the working tree side of temporary directory
+ for the "dir-diff" feature forgot that symbolic links need not be
+ copied (or symlinked) to the temporary area, as the code already
+ special cases and overwrites them. Besides, it was wrong to try
+ computing the object name of the target of symbolic link, which may
+ not even exist or may be a directory.
+
+ * A Range: request can be responded with a full response and when
+ asked properly libcurl knows how to strip the result down to the
+ requested range. However, we were hand-crafting a range request
+ and it did not kick in.
+
+ * Having a leftover .idx file without corresponding .pack file in
+ the repository hurts performance; "git gc" learned to prune them.
+
+ * Apple's common crypto implementation of SHA1_Update() does not take
+ more than 4GB at a time, and we now have a compile-time workaround
+ for it.
+
+ * Produce correct "dirty" marker for shell prompts, even when we
+ are on an orphan or an unborn branch.
+
+ * A build without NO_IPv6 used to use gethostbyname() when guessing
+ user's hostname, instead of getaddrinfo() that is used in other
+ codepaths in such a build.
+
+ * The exit code of git-fsck did not reflect some types of errors
+ found in packed objects, which has been corrected.
+
+ * The helper used to iterate over loose object directories to prune
+ stale objects did not closedir() immediately when it is done with a
+ directory--a callback such as the one used for "git prune" may want
+ to do rmdir(), but it would fail on open directory on platforms
+ such as WinXP.
+
+ * "git p4" used to import Perforce CLs that touch only paths outside
+ the client spec as empty commits. It has been corrected to ignore
+ them instead, with a new configuration git-p4.keepEmptyCommits as a
+ backward compatibility knob.
+
+ * The completion script (in contrib/) used to list "git column"
+ (which is not an end-user facing command) as one of the choices
+ (merge 160fcdb sg/completion-no-column later to maint).
+
+ * The error reporting from "git send-email", when SMTP TLS fails, has
+ been improved.
+ (merge 9d60524 jk/send-email-ssl-errors later to maint).
+
+ * When getpwuid() on the system returned NULL (e.g. the user is not
+ in the /etc/passwd file or other uid-to-name mappings), the
+ codepath to find who the user is to record it in the reflog barfed
+ and died. Loosen the check in this codepath, which already accepts
+ questionable ident string (e.g. host part of the e-mail address is
+ obviously bogus), and in general when we operate fmt_ident() function
+ in non-strict mode.
+ (merge 92bcbb9 jk/ident-loosen-getpwuid later to maint).
+
+ * "git symbolic-ref" forgot to report a failure with its exit status.
+ (merge f91b273 jk/symbolic-ref-maint later to maint).
+
+ * History traversal with "git log --source" that starts with an
+ annotated tag failed to report the tag as "source", due to an
+ old regression in the command line parser back in v2.2 days.
+ (merge 728350b jk/pending-keep-tag-name later to maint).
+
+ * "git p4" when interacting with multiple depots at the same time
+ used to incorrectly drop changes.
+
+ * Code clean-up, minor fixes etc.
diff --git a/RelNotes/2.7.1.adoc b/RelNotes/2.7.1.adoc
new file mode 100644
index 0000000..6323fea
--- /dev/null
+++ b/RelNotes/2.7.1.adoc
@@ -0,0 +1,87 @@
+Git v2.7.1 Release Notes
+========================
+
+Fixes since v2.7
+----------------
+
+ * An earlier change in 2.5.x-era broke users' hooks and aliases by
+ exporting GIT_WORK_TREE to point at the root of the working tree,
+ interfering when they tried to use a different working tree without
+ setting GIT_WORK_TREE environment themselves.
+
+ * The "exclude_list" structure has the usual "alloc, nr" pair of
+ fields to be used by ALLOC_GROW(), but clear_pattern_list() forgot
+ to reset 'alloc' to 0 when it cleared 'nr' to discard the managed
+ array.
+
+ * "git send-email" was confused by escaped quotes stored in the alias
+ files saved by "mutt", which has been corrected.
+
+ * A few unportable C construct have been spotted by clang compiler
+ and have been fixed.
+
+ * The documentation has been updated to hint the connection between
+ the '--signoff' option and DCO.
+
+ * "git reflog" incorrectly assumed that all objects that used to be
+ at the tip of a ref must be commits, which caused it to segfault.
+
+ * The ignore mechanism saw a few regressions around untracked file
+ listing and sparse checkout selection areas in 2.7.0; the change
+ that is responsible for the regression has been reverted.
+
+ * Some codepaths used fopen(3) when opening a fixed path in $GIT_DIR
+ (e.g. COMMIT_EDITMSG) that is meant to be left after the command is
+ done. This however did not work well if the repository is set to
+ be shared with core.sharedRepository and the umask of the previous
+ user is tighter. They have been made to work better by calling
+ unlink(2) and retrying after fopen(3) fails with EPERM.
+
+ * Asking gitweb for a nonexistent commit left a warning in the server
+ log.
+
+ * "git rebase", unlike all other callers of "gc --auto", did not
+ ignore the exit code from "gc --auto".
+
+ * Many codepaths that run "gc --auto" before exiting kept packfiles
+ mapped and left the file descriptors to them open, which was not
+ friendly to systems that cannot remove files that are open. They
+ now close the packs before doing so.
+
+ * A recent optimization to filter-branch in v2.7.0 introduced a
+ regression when --prune-empty filter is used, which has been
+ corrected.
+
+ * The description for SANITY prerequisite the test suite uses has
+ been clarified both in the comment and in the implementation.
+
+ * "git tag" started listing a tag "foo" as "tags/foo" when a branch
+ named "foo" exists in the same repository; remove this unnecessary
+ disambiguation, which is a regression introduced in v2.7.0.
+
+ * The way "git svn" uses auth parameter was broken by Subversion
+ 1.9.0 and later.
+
+ * The "split" subcommand of "git subtree" (in contrib/) incorrectly
+ skipped merges when it shouldn't, which was corrected.
+
+ * A few options of "git diff" did not work well when the command was
+ run from a subdirectory.
+
+ * dirname() emulation has been added, as Msys2 lacks it.
+
+ * The underlying machinery used by "ls-files -o" and other commands
+ have been taught not to create empty submodule ref cache for a
+ directory that is not a submodule. This removes a ton of wasted
+ CPU cycles.
+
+ * Drop a few old "todo" items by deciding that the change one of them
+ suggests is not such a good idea, and doing the change the other
+ one suggested to do.
+
+ * Documentation for "git fetch --depth" has been updated for clarity.
+
+ * The command line completion learned a handful of additional options
+ and command specific syntax.
+
+Also includes a handful of documentation and test updates.
diff --git a/RelNotes/2.7.2.adoc b/RelNotes/2.7.2.adoc
new file mode 100644
index 0000000..4feef76
--- /dev/null
+++ b/RelNotes/2.7.2.adoc
@@ -0,0 +1,41 @@
+Git v2.7.2 Release Notes
+========================
+
+Fixes since v2.7.1
+------------------
+
+ * The low-level merge machinery has been taught to use CRLF line
+ termination when inserting conflict markers to merged contents that
+ are themselves CRLF line-terminated.
+
+ * "git worktree" had a broken code that attempted to auto-fix
+ possible inconsistency that results from end-users moving a
+ worktree to different places without telling Git (the original
+ repository needs to maintain backpointers to its worktrees, but
+ "mv" run by end-users who are not familiar with that fact will
+ obviously not adjust them), which actually made things worse
+ when triggered.
+
+ * "git push --force-with-lease" has been taught to report if the push
+ needed to force (or fast-forwarded).
+
+ * The emulated "yes" command used in our test scripts has been
+ tweaked not to spend too much time generating unnecessary output
+ that is not used, to help those who test on Windows where it would
+ not stop until it fills the pipe buffer due to lack of SIGPIPE.
+
+ * The vimdiff backend for "git mergetool" has been tweaked to arrange
+ and number buffers in the order that would match the expectation of
+ majority of people who read left to right, then top down and assign
+ buffers 1 2 3 4 "mentally" to local base remote merge windows based
+ on that order.
+
+ * The documentation for "git clean" has been corrected; it mentioned
+ that .git/modules/* are removed by giving two "-f", which has never
+ been the case.
+
+ * Paths that have been told the index about with "add -N" are not
+ quite yet in the index, but a few commands behaved as if they
+ already are in a harmful way.
+
+Also includes tiny documentation and test updates.
diff --git a/RelNotes/2.7.3.adoc b/RelNotes/2.7.3.adoc
new file mode 100644
index 0000000..f618d71
--- /dev/null
+++ b/RelNotes/2.7.3.adoc
@@ -0,0 +1,62 @@
+Git v2.7.3 Release Notes
+========================
+
+Fixes since v2.7.2
+------------------
+
+ * Traditionally, the tests that try commands that work on the
+ contents in the working tree were named with "worktree" in their
+ filenames, but with the recent addition of "git worktree"
+ subcommand, whose tests are also named similarly, it has become
+ harder to tell them apart. The traditional tests have been renamed
+ to use "work-tree" instead in an attempt to differentiate them.
+
+ * Many codepaths forget to check return value from git_config_set();
+ the function is made to die() to make sure we do not proceed when
+ setting a configuration variable failed.
+
+ * Handling of errors while writing into our internal asynchronous
+ process has been made more robust, which reduces flakiness in our
+ tests.
+
+ * "git show 'HEAD:Foo[BAR]Baz'" did not interpret the argument as a
+ rev, i.e. the object named by the pathname with wildcard
+ characters in a tree object.
+
+ * "git rev-parse --git-common-dir" used in the worktree feature
+ misbehaved when run from a subdirectory.
+
+ * The "v(iew)" subcommand of the interactive "git am -i" command was
+ broken in 2.6.0 timeframe when the command was rewritten in C.
+
+ * "git merge-tree" used to mishandle "both sides added" conflict with
+ its own "create a fake ancestor file that has the common parts of
+ what both sides have added and do a 3-way merge" logic; this has
+ been updated to use the usual "3-way merge with an empty blob as
+ the fake common ancestor file" approach used in the rest of the
+ system.
+
+ * The memory ownership rule of fill_textconv() API, which was a bit
+ tricky, has been documented a bit better.
+
+ * The documentation did not clearly state that the 'simple' mode is
+ now the default for "git push" when push.default configuration is
+ not set.
+
+ * Recent versions of GNU grep are pickier when their input contains
+ arbitrary binary data, which some of our tests uses. Rewrite the
+ tests to sidestep the problem.
+
+ * A helper function "git submodule" uses since v2.7.0 to list the
+ modules that match the pathspec argument given to its subcommands
+ (e.g. "submodule add <repo> <path>") has been fixed.
+
+ * "git config section.var value" to set a value in per-repository
+ configuration file failed when it was run outside any repository,
+ but didn't say the reason correctly.
+
+ * The code to read the pack data using the offsets stored in the pack
+ idx file has been made more carefully check the validity of the
+ data in the idx.
+
+Also includes documentation and test updates.
diff --git a/RelNotes/2.7.4.adoc b/RelNotes/2.7.4.adoc
new file mode 100644
index 0000000..883ae89
--- /dev/null
+++ b/RelNotes/2.7.4.adoc
@@ -0,0 +1,11 @@
+Git v2.7.4 Release Notes
+========================
+
+Fixes since v2.7.3
+------------------
+
+ * Bugfix patches were backported from the 'master' front to plug heap
+ corruption holes, to catch integer overflow in the computation of
+ pathname lengths, and to get rid of the name_path API. Both of
+ these would have resulted in writing over an under-allocated buffer
+ when formulating pathnames while tree traversal.
diff --git a/RelNotes/2.7.5.adoc b/RelNotes/2.7.5.adoc
new file mode 100644
index 0000000..83559ce
--- /dev/null
+++ b/RelNotes/2.7.5.adoc
@@ -0,0 +1,14 @@
+Git v2.7.5 Release Notes
+========================
+
+Fixes since v2.7.4
+------------------
+
+ * "git-shell" rejects a request to serve a repository whose name
+ begins with a dash, which makes it no longer possible to get it
+ confused into spawning service programs like "git-upload-pack" with
+ an option like "--help", which in turn would spawn an interactive
+ pager, instead of working with the repository user asked to access
+ (i.e. the one whose name is "--help").
+
+Also contains a few fixes backported from later development tracks.
diff --git a/RelNotes/2.7.6.adoc b/RelNotes/2.7.6.adoc
new file mode 100644
index 0000000..4c6d1dc
--- /dev/null
+++ b/RelNotes/2.7.6.adoc
@@ -0,0 +1,25 @@
+Git v2.7.6 Release Notes
+========================
+
+Fixes since v2.7.5
+------------------
+
+ * A "ssh://..." URL can result in a "ssh" command line with a
+ hostname that begins with a dash "-", which would cause the "ssh"
+ command to instead (mis)treat it as an option. This is now
+ prevented by forbidding such a hostname (which will not be
+ necessary in the real world).
+
+ * Similarly, when GIT_PROXY_COMMAND is configured, the command is
+ run with host and port that are parsed out from "ssh://..." URL;
+ a poorly written GIT_PROXY_COMMAND could be tricked into treating
+ a string that begins with a dash "-". This is now prevented by
+ forbidding such a hostname and port number (again, which will not
+ be necessary in the real world).
+
+ * In the same spirit, a repository name that begins with a dash "-"
+ is also forbidden now.
+
+Credits go to Brian Neel at GitLab, Joern Schneeweisz of Recurity
+Labs and Jeff King at GitHub.
+
diff --git a/RelNotes/2.8.0.adoc b/RelNotes/2.8.0.adoc
new file mode 100644
index 0000000..3845328
--- /dev/null
+++ b/RelNotes/2.8.0.adoc
@@ -0,0 +1,439 @@
+Git 2.8 Release Notes
+=====================
+
+Backward compatibility note
+---------------------------
+
+The rsync:// transport has been removed.
+
+
+Updates since v2.7
+------------------
+
+UI, Workflows & Features
+
+ * It turns out "git clone" over rsync transport has been broken when
+ the source repository has packed references for a long time, and
+ nobody noticed nor complained about it.
+
+ * "push" learned that its "--delete" option can be shortened to
+ "-d", just like "branch --delete" and "branch -d" are the same
+ thing.
+
+ * "git blame" learned to produce the progress eye-candy when it takes
+ too much time before emitting the first line of the result.
+
+ * "git grep" can now be configured (or told from the command line)
+ how many threads to use when searching in the working tree files.
+
+ * Some "git notes" operations, e.g. "git log --notes=<note>", should
+ be able to read notes from any tree-ish that is shaped like a notes
+ tree, but the notes infrastructure required that the argument must
+ be a ref under refs/notes/. Loosen it to require a valid ref only
+ when the operation would update the notes (in which case we must
+ have a place to store the updated notes tree, iow, a ref).
+
+ * "git grep" by default does not fall back to its "--no-index"
+ behavior outside a directory under Git's control (otherwise the
+ user may by mistake end up running a huge recursive search); with a
+ new configuration (set in $HOME/.gitconfig--by definition this
+ cannot be set in the config file per project), this safety can be
+ disabled.
+
+ * "git pull --rebase" has been extended to allow invoking
+ "rebase -i".
+
+ * "git p4" learned to cope with the type of a file getting changed.
+
+ * "git format-patch" learned to notice format.outputDirectory
+ configuration variable. This allows "-o <dir>" option to be
+ omitted on the command line if you always use the same directory in
+ your workflow.
+
+ * "interpret-trailers" has been taught to optionally update a file in
+ place, instead of always writing the result to the standard output.
+
+ * Many commands that read files that are expected to contain text
+ that is generated (or can be edited) by the end user to control
+ their behavior (e.g. "git grep -f <filename>") have been updated
+ to be more tolerant to lines that are terminated with CRLF (they
+ used to treat such a line to contain payload that ends with CR,
+ which is usually not what the users expect).
+
+ * "git notes merge" used to limit the source of the merged notes tree
+ to somewhere under refs/notes/ hierarchy, which was too limiting
+ when inventing a workflow to exchange notes with remote
+ repositories using remote-tracking notes trees (located in e.g.
+ refs/remote-notes/ or somesuch).
+
+ * "git ls-files" learned a new "--eol" option to help diagnose
+ end-of-line problems.
+
+ * "ls-remote" learned an option to show which branch the remote
+ repository advertises as its primary by pointing its HEAD at.
+
+ * New http.proxyAuthMethod configuration variable can be used to
+ specify what authentication method to use, as a way to work around
+ proxies that do not give error response expected by libcurl when
+ CURLAUTH_ANY is used. Also, the codepath for proxy authentication
+ has been taught to use credential API to store the authentication
+ material in user's keyrings.
+
+ * Update the untracked cache subsystem and change its primary UI from
+ "git update-index" to "git config".
+
+ * There were a few "now I am doing this thing" progress messages in
+ the TCP connection code that can be triggered by setting a verbose
+ option internally in the code, but "git fetch -v" and friends never
+ passed the verbose option down to that codepath.
+
+ * Clean/smudge filters defined in a configuration file of lower
+ precedence can now be overridden to be a pass-through no-op by
+ setting the variable to an empty string.
+
+ * A new "<branch>^{/!-<pattern>}" notation can be used to name a
+ commit that is reachable from <branch> that does not match the
+ given <pattern>.
+
+ * The "user.useConfigOnly" configuration variable can be used to
+ force the user to always set user.email & user.name configuration
+ variables, serving as a reminder for those who work on multiple
+ projects and do not want to put these in their $HOME/.gitconfig.
+
+ * "git fetch" and friends that make network connections can now be
+ told to only use ipv4 (or ipv6).
+
+ * Some authentication methods do not need username or password, but
+ libcurl needs some hint that it needs to perform authentication.
+ Supplying an empty username and password string is a valid way to
+ do so, but you can set the http.[<url>.]emptyAuth configuration
+ variable to achieve the same, if you find it cleaner.
+
+ * You can now set http.[<url>.]pinnedpubkey to specify the pinned
+ public key when building with recent enough versions of libcURL.
+
+ * The configuration system has been taught to phrase where it found a
+ bad configuration variable in a better way in its error messages.
+ "git config" learnt a new "--show-origin" option to indicate where
+ the values come from.
+
+ * The "credential-cache" daemon process used to run in whatever
+ directory it happened to start in, but this made umount(2)ing the
+ filesystem that houses the repository harder; now the process
+ chdir()s to the directory that house its own socket on startup.
+
+ * When "git submodule update" did not result in fetching the commit
+ object in the submodule that is referenced by the superproject, the
+ command learned to retry another fetch, specifically asking for
+ that commit that may not be connected to the refs it usually
+ fetches.
+
+ * "git merge-recursive" learned "--no-renames" option to disable its
+ rename detection logic.
+
+ * Across the transition at around Git version 2.0, the user used to
+ get a pretty loud warning when running "git push" without setting
+ push.default configuration variable. We no longer warn because the
+ transition was completed a long time ago.
+
+ * README has been renamed to README.md and its contents got tweaked
+ slightly to make it easier on the eyes.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * Add a framework to spawn a group of processes in parallel, and use
+ it to run "git fetch --recurse-submodules" in parallel.
+
+ * A slight update to the Makefile to mark ".PHONY" targets as such
+ correctly.
+
+ * In-core storage of the reverse index for .pack files (which lets
+ you go from a pack offset to an object name) has been streamlined.
+
+ * d95138e6 (setup: set env $GIT_WORK_TREE when work tree is set, like
+ $GIT_DIR, 2015-06-26) attempted to work around a glitch in alias
+ handling by overwriting GIT_WORK_TREE environment variable to
+ affect subprocesses when set_git_work_tree() gets called, which
+ resulted in a rather unpleasant regression to "clone" and "init".
+ Try to address the same issue by always restoring the environment
+ and respawning the real underlying command when handling alias.
+
+ * The low-level code that is used to create symbolic references has
+ been updated to share more code with the code that deals with
+ normal references.
+
+ * strbuf_getline() and friends have been redefined to make it easier
+ to identify which callsite of (new) strbuf_getline_lf() should
+ allow and silently ignore carriage-return at the end of the line to
+ help users on DOSsy systems.
+
+ * "git shortlog" used to accumulate various pieces of information
+ regardless of what was asked to be shown in the final output. It
+ has been optimized by noticing what need not to be collected
+ (e.g. there is no need to collect the log messages when showing
+ only the number of changes).
+
+ * "git checkout $branch" (and other operations that share the same
+ underlying machinery) has been optimized.
+
+ * Automated tests in Travis CI environment has been optimized by
+ persisting runtime statistics of previous "prove" run, executing
+ tests that take longer before other ones; this reduces the total
+ wallclock time.
+
+ * Test scripts have been updated to remove assumptions that are not
+ portable between Git for POSIX and Git for Windows, or to skip ones
+ with expectations that are not satisfiable on Git for Windows.
+
+ * Some calls to strcpy(3) triggers a false warning from static
+ analyzers that are less intelligent than humans, and reducing the
+ number of these false hits helps us notice real issues. A few
+ calls to strcpy(3) in a couple of programs that are already safe
+ has been rewritten to avoid false warnings.
+
+ * The "name_path" API was an attempt to reduce the need to construct
+ the full path out of a series of path components while walking a
+ tree hierarchy, but over time made less efficient because the path
+ needs to be flattened, e.g. to be compared with another path that
+ is already flat. The API has been removed and its users have been
+ rewritten to simplify the overall code complexity.
+
+ * Help those who debug http(s) part of the system.
+ (merge 0054045 sp/remote-curl-ssl-strerror later to maint).
+
+ * The internal API to interact with "remote.*" configuration
+ variables has been streamlined.
+
+ * The ref-filter's format-parsing code has been refactored, in
+ preparation for "branch --format" and friends.
+
+ * Traditionally, the tests that try commands that work on the
+ contents in the working tree were named with "worktree" in their
+ filenames, but with the recent addition of "git worktree"
+ subcommand, whose tests are also named similarly, it has become
+ harder to tell them apart. The traditional tests have been renamed
+ to use "work-tree" instead in an attempt to differentiate them.
+ (merge 5549029 mg/work-tree-tests later to maint).
+
+ * Many codepaths forget to check return value from git_config_set();
+ the function is made to die() to make sure we do not proceed when
+ setting a configuration variable failed.
+ (merge 3d18064 ps/config-error later to maint).
+
+ * Handling of errors while writing into our internal asynchronous
+ process has been made more robust, which reduces flakiness in our
+ tests.
+ (merge 43f3afc jk/epipe-in-async later to maint).
+
+ * There is a new DEVELOPER knob that enables many compiler warning
+ options in the Makefile.
+
+ * The way the test scripts configure the Apache web server has been
+ updated to work also for Apache 2.4 running on RedHat derived
+ distros.
+
+ * Out of maintenance gcc on OSX 10.6 fails to compile the code in
+ 'master'; work it around by using clang by default on the platform.
+
+ * The "name_path" API was an attempt to reduce the need to construct
+ the full path out of a series of path components while walking a
+ tree hierarchy, but over time made less efficient because the path
+ needs to be flattened, e.g. to be compared with another path that
+ is already flat, in many cases. The API has been removed and its
+ users have been rewritten to simplify the overall code complexity.
+ This incidentally also closes some heap-corruption holes.
+
+ * Recent versions of GNU grep is pickier than before to decide if a
+ file is "binary" and refuse to give line-oriented hits when we
+ expect it to, unless explicitly told with "-a" option. As our
+ scripted Porcelains use sane_grep wrapper for line-oriented data,
+ even when the line may contain non-ASCII payload we took from
+ end-user data, use "grep -a" to implement sane_grep wrapper when
+ using an implementation of "grep" that takes the "-a" option.
+
+
+
+Also contains various documentation updates and code clean-ups.
+
+
+Fixes since v2.7
+----------------
+
+Unless otherwise noted, all the fixes since v2.7 in the maintenance
+track are contained in this release (see the maintenance releases'
+notes for details).
+
+ * An earlier change in 2.5.x-era broke users' hooks and aliases by
+ exporting GIT_WORK_TREE to point at the root of the working tree,
+ interfering when they tried to use a different working tree without
+ setting GIT_WORK_TREE environment themselves.
+
+ * The "exclude_list" structure has the usual "alloc, nr" pair of
+ fields to be used by ALLOC_GROW(), but clear_pattern_list() forgot
+ to reset 'alloc' to 0 when it cleared 'nr' to discard the managed
+ array.
+
+ * Paths that have been told the index about with "add -N" are not
+ quite yet in the index, but a few commands behaved as if they
+ already are in a harmful way.
+
+ * "git send-email" was confused by escaped quotes stored in the alias
+ files saved by "mutt", which has been corrected.
+
+ * A few non-portable C construct have been spotted by clang compiler
+ and have been fixed.
+
+ * The documentation has been updated to hint the connection between
+ the '--signoff' option and DCO.
+
+ * "git reflog" incorrectly assumed that all objects that used to be
+ at the tip of a ref must be commits, which caused it to segfault.
+
+ * The ignore mechanism saw a few regressions around untracked file
+ listing and sparse checkout selection areas in 2.7.0; the change
+ that is responsible for the regression has been reverted.
+
+ * Some codepaths used fopen(3) when opening a fixed path in $GIT_DIR
+ (e.g. COMMIT_EDITMSG) that is meant to be left after the command is
+ done. This however did not work well if the repository is set to
+ be shared with core.sharedRepository and the umask of the previous
+ user is tighter. They have been made to work better by calling
+ unlink(2) and retrying after fopen(3) fails with EPERM.
+
+ * Asking gitweb for a nonexistent commit left a warning in the server
+ log.
+
+ Somebody may want to follow this up with an additional test, perhaps?
+ IIRC, we do test that no Perl warnings are given to the server log,
+ so this should have been caught if our test coverage were good.
+
+ * "git rebase", unlike all other callers of "gc --auto", did not
+ ignore the exit code from "gc --auto".
+
+ * Many codepaths that run "gc --auto" before exiting kept packfiles
+ mapped and left the file descriptors to them open, which was not
+ friendly to systems that cannot remove files that are open. They
+ now close the packs before doing so.
+
+ * A recent optimization to filter-branch in v2.7.0 introduced a
+ regression when --prune-empty filter is used, which has been
+ corrected.
+
+ * The description for SANITY prerequisite the test suite uses has
+ been clarified both in the comment and in the implementation.
+
+ * "git tag" started listing a tag "foo" as "tags/foo" when a branch
+ named "foo" exists in the same repository; remove this unnecessary
+ disambiguation, which is a regression introduced in v2.7.0.
+
+ * The way "git svn" uses auth parameter was broken by Subversion
+ 1.9.0 and later.
+
+ * The "split" subcommand of "git subtree" (in contrib/) incorrectly
+ skipped merges when it shouldn't, which was corrected.
+
+ * A few options of "git diff" did not work well when the command was
+ run from a subdirectory.
+
+ * The command line completion learned a handful of additional options
+ and command specific syntax.
+
+ * dirname() emulation has been added, as Msys2 lacks it.
+
+ * The underlying machinery used by "ls-files -o" and other commands
+ has been taught not to create empty submodule ref cache for a
+ directory that is not a submodule. This removes a ton of wasted
+ CPU cycles.
+
+ * "git worktree" had a broken code that attempted to auto-fix
+ possible inconsistency that results from end-users moving a
+ worktree to different places without telling Git (the original
+ repository needs to maintain back-pointers to its worktrees,
+ but "mv" run by end-users who are not familiar with that fact
+ will obviously not adjust them), which actually made things
+ worse when triggered.
+
+ * The low-level merge machinery has been taught to use CRLF line
+ termination when inserting conflict markers to merged contents that
+ are themselves CRLF line-terminated.
+
+ * "git push --force-with-lease" has been taught to report if the push
+ needed to force (or fast-forwarded).
+
+ * The emulated "yes" command used in our test scripts has been
+ tweaked not to spend too much time generating unnecessary output
+ that is not used, to help those who test on Windows where it would
+ not stop until it fills the pipe buffer due to lack of SIGPIPE.
+
+ * The documentation for "git clean" has been corrected; it mentioned
+ that .git/modules/* are removed by giving two "-f", which has never
+ been the case.
+
+ * The vimdiff backend for "git mergetool" has been tweaked to arrange
+ and number buffers in the order that would match the expectation of
+ majority of people who read left to right, then top down and assign
+ buffers 1 2 3 4 "mentally" to local base remote merge windows based
+ on that order.
+
+ * "git show 'HEAD:Foo[BAR]Baz'" did not interpret the argument as a
+ rev, i.e. the object named by the pathname with wildcard
+ characters in a tree object.
+ (merge aac4fac nd/dwim-wildcards-as-pathspecs later to maint).
+
+ * "git rev-parse --git-common-dir" used in the worktree feature
+ misbehaved when run from a subdirectory.
+ (merge 17f1365 nd/git-common-dir-fix later to maint).
+
+ * "git worktree add -B <branchname>" did not work.
+
+ * The "v(iew)" subcommand of the interactive "git am -i" command was
+ broken in 2.6.0 timeframe when the command was rewritten in C.
+ (merge 708b8cc jc/am-i-v-fix later to maint).
+
+ * "git merge-tree" used to mishandle "both sides added" conflict with
+ its own "create a fake ancestor file that has the common parts of
+ what both sides have added and do a 3-way merge" logic; this has
+ been updated to use the usual "3-way merge with an empty blob as
+ the fake common ancestor file" approach used in the rest of the
+ system.
+ (merge 907681e jk/no-diff-emit-common later to maint).
+
+ * The memory ownership rule of fill_textconv() API, which was a bit
+ tricky, has been documented a bit better.
+ (merge a64e6a4 jk/more-comments-on-textconv later to maint).
+
+ * Update various codepaths to avoid manually-counted malloc().
+ (merge 08c95df jk/tighten-alloc later to maint).
+
+ * The documentation did not clearly state that the 'simple' mode is
+ now the default for "git push" when push.default configuration is
+ not set.
+ (merge f6b1fb3 mm/push-simple-doc later to maint).
+
+ * Recent versions of GNU grep are pickier when their input contains
+ arbitrary binary data, which some of our tests uses. Rewrite the
+ tests to sidestep the problem.
+ (merge 3b1442d jk/grep-binary-workaround-in-test later to maint).
+
+ * A helper function "git submodule" uses since v2.7.0 to list the
+ modules that match the pathspec argument given to its subcommands
+ (e.g. "submodule add <repo> <path>") has been fixed.
+ (merge 2b56bb7 sb/submodule-module-list-fix later to maint).
+
+ * "git config section.var value" to set a value in per-repository
+ configuration file failed when it was run outside any repository,
+ but didn't say the reason correctly.
+ (merge 638fa62 js/config-set-in-non-repository later to maint).
+
+ * The code to read the pack data using the offsets stored in the pack
+ idx file has been made more carefully check the validity of the
+ data in the idx.
+ (merge 7465feb jk/pack-idx-corruption-safety later to maint).
+
+ * Other minor clean-ups and documentation updates
+ (merge f459823 ak/extract-argv0-last-dir-sep later to maint).
+ (merge 63ca1c0 ak/git-strip-extension-from-dashed-command later to maint).
+ (merge 4867f11 ps/plug-xdl-merge-leak later to maint).
+ (merge 4938686 dt/initial-ref-xn-commit-doc later to maint).
+ (merge 9537f21 ma/update-hooks-sample-typofix later to maint).
diff --git a/RelNotes/2.8.1.adoc b/RelNotes/2.8.1.adoc
new file mode 100644
index 0000000..ef6d80b
--- /dev/null
+++ b/RelNotes/2.8.1.adoc
@@ -0,0 +1,9 @@
+Git v2.8.1 Release Notes
+========================
+
+Fixes since v2.8
+----------------
+
+ * "make rpmbuild" target was broken as its input, git.spec.in, was
+ not updated to match a file it describes that has been renamed
+ recently. This has been fixed.
diff --git a/RelNotes/2.8.2.adoc b/RelNotes/2.8.2.adoc
new file mode 100644
index 0000000..447b193
--- /dev/null
+++ b/RelNotes/2.8.2.adoc
@@ -0,0 +1,70 @@
+Git v2.8.2 Release Notes
+========================
+
+Fixes since v2.8.1
+------------------
+
+ * The embedded args argv-array in the child process is used to build
+ the command line to run pack-objects instead of using a separate
+ array of strings.
+
+ * Bunch of tests on "git clone" has been renumbered for better
+ organization.
+
+ * The tests that involve running httpd leaked the system-wide
+ configuration in /etc/gitconfig to the tested environment.
+
+ * "index-pack --keep=<msg>" was broken since v2.1.0 timeframe.
+
+ * "git config --get-urlmatch", unlike other variants of the "git
+ config --get" family, did not signal error with its exit status
+ when there was no matching configuration.
+
+ * The "--local-env-vars" and "--resolve-git-dir" options of "git
+ rev-parse" failed to work outside a repository when the command's
+ option parsing was rewritten in 1.8.5 era.
+
+ * Fetching of history by naming a commit object name directly didn't
+ work across remote-curl transport.
+
+ * A small memory leak in an error codepath has been plugged in xdiff
+ code.
+
+ * strbuf_getwholeline() did not NUL-terminate the buffer on certain
+ corner cases in its error codepath.
+
+ * The startup_info data, which records if we are working inside a
+ repository (among other things), are now uniformly available to Git
+ subcommand implementations, and Git avoids attempting to touch
+ references when we are not in a repository.
+
+ * "git mergetool" did not work well with conflicts that both sides
+ deleted.
+
+ * "git send-email" had trouble parsing alias file in mailrc format
+ when lines in it had trailing whitespaces on them.
+
+ * When "git merge --squash" stopped due to conflict, the concluding
+ "git commit" failed to read in the SQUASH_MSG that shows the log
+ messages from all the squashed commits.
+
+ * "git merge FETCH_HEAD" dereferenced NULL pointer when merging
+ nothing into an unborn history (which is arguably unusual usage,
+ which perhaps was the reason why nobody noticed it).
+
+ * Build updates for MSVC.
+
+ * "git diff -M" used to work better when two originally identical
+ files A and B got renamed to X/A and X/B by pairing A to X/A and B
+ to X/B, but this was broken in the 2.0 timeframe.
+
+ * "git send-pack --all <there>" was broken when its command line
+ option parsing was written in the 2.6 timeframe.
+
+ * When running "git blame $path" with unnormalized data in the index
+ for the path, the data in the working tree was blamed, even though
+ "git add" would not have changed what is already in the index, due
+ to "safe crlf" that disables the line-end conversion. It has been
+ corrected.
+
+Also contains minor documentation updates and code clean-ups.
diff --git a/RelNotes/2.8.3.adoc b/RelNotes/2.8.3.adoc
new file mode 100644
index 0000000..a63825e
--- /dev/null
+++ b/RelNotes/2.8.3.adoc
@@ -0,0 +1,101 @@
+Git v2.8.3 Release Notes
+========================
+
+Fixes since v2.8.2
+------------------
+
+ * "git send-email" now uses a more readable timestamps when
+ formulating a message ID.
+
+ * The repository set-up sequence has been streamlined (the biggest
+ change is that there is no longer git_config_early()), so that we
+ do not attempt to look into refs/* when we know we do not have a
+ Git repository.
+
+ * When "git worktree" feature is in use, "git branch -d" allowed
+ deletion of a branch that is checked out in another worktree
+
+ * When "git worktree" feature is in use, "git branch -m" renamed a
+ branch that is checked out in another worktree without adjusting
+ the HEAD symbolic ref for the worktree.
+
+ * "git format-patch --help" showed `-s` and `--no-patch` as if these
+ are valid options to the command. We already hide `--patch` option
+ from the documentation, because format-patch is about showing the
+ diff, and the documentation now hides these options as well.
+
+ * A change back in version 2.7 to "git branch" broke display of a
+ symbolic ref in a non-standard place in the refs/ hierarchy (we
+ expect symbolic refs to appear in refs/remotes/*/HEAD to point at
+ the primary branch the remote has, and as .git/HEAD to point at the
+ branch we locally checked out).
+
+ * A partial rewrite of "git submodule" in the 2.7 timeframe changed
+ the way the gitdir: pointer in the submodules point at the real
+ repository location to use absolute paths by accident. This has
+ been corrected.
+
+ * "git commit" misbehaved in a few minor ways when an empty message
+ is given via -m '', all of which has been corrected.
+
+ * Support for CRAM-MD5 authentication method in "git imap-send" did
+ not work well.
+
+ * The socks5:// proxy support added back in 2.6.4 days was not aware
+ that socks5h:// proxies behave differently.
+
+ * "git config" had a codepath that tried to pass a NULL to
+ printf("%s"), which nobody seems to have noticed.
+
+ * On Cygwin, object creation uses the "create a temporary and then
+ rename it to the final name" pattern, not "create a temporary,
+ hardlink it to the final name and then unlink the temporary"
+ pattern.
+
+ This is necessary to use Git on Windows shared directories, and is
+ already enabled for the MinGW and plain Windows builds. It also
+ has been used in Cygwin packaged versions of Git for quite a while.
+ See https://lore.kernel.org/git/20160419091055.GF2345@dinwoodie.org/
+ and https://lore.kernel.org/git/20150811100527.GW14466@dinwoodie.org/.
+
+ * "git replace -e" did not honour "core.editor" configuration.
+
+ * Upcoming OpenSSL 1.1.0 will break compilation b updating a few APIs
+ we use in imap-send, which has been adjusted for the change.
+
+ * "git submodule" reports the paths of submodules the command
+ recurses into, but this was incorrect when the command was not run
+ from the root level of the superproject.
+
+ * The test scripts for "git p4" (but not "git p4" implementation
+ itself) has been updated so that they would work even on a system
+ where the installed version of Python is python 3.
+
+ * The "user.useConfigOnly" configuration variable makes it an error
+ if users do not explicitly set user.name and user.email. However,
+ its check was not done early enough and allowed another error to
+ trigger, reporting that the default value we guessed from the
+ system setting was unusable. This was a suboptimal end-user
+ experience as we want the users to set user.name/user.email without
+ relying on the auto-detection at all.
+
+ * "git mv old new" did not adjust the path for a submodule that lives
+ as a subdirectory inside old/ directory correctly.
+
+ * "git push" from a corrupt repository that attempts to push a large
+ number of refs deadlocked; the thread to relay rejection notices
+ for these ref updates blocked on writing them to the main thread,
+ after the main thread at the receiving end notices that the push
+ failed and decides not to read these notices and return a failure.
+
+ * A question by "git send-email" to ask the identity of the sender
+ has been updated.
+
+ * Recent update to Git LFS broke "git p4" by changing the output from
+ its "lfs pointer" subcommand.
+
+ * Some multi-byte encoding can have a backslash byte as a later part
+ of one letter, which would confuse "highlight" filter used in
+ gitweb.
+
+Also contains minor documentation updates and code clean-ups.
diff --git a/RelNotes/2.8.4.adoc b/RelNotes/2.8.4.adoc
new file mode 100644
index 0000000..f4e2552
--- /dev/null
+++ b/RelNotes/2.8.4.adoc
@@ -0,0 +1,69 @@
+Git v2.8.4 Release Notes
+========================
+
+Fixes since v2.8.3
+------------------
+
+ * Documentation for "git merge --verify-signatures" has been updated
+ to clarify that the signature of only the commit at the tip is
+ verified. Also the phrasing used for signature and key validity is
+ adjusted to align with that used by OpenPGP.
+
+ * On Windows, .git and optionally any files whose name starts with a
+ dot are now marked as hidden, with a core.hideDotFiles knob to
+ customize this behaviour.
+
+ * Portability enhancement for "rebase -i" to help platforms whose
+ shell does not like "for i in <empty>" (which is not POSIX-kosher).
+
+ * "git fsck" learned to catch NUL byte in a commit object as
+ potential error and warn.
+
+ * CI test was taught to build documentation pages.
+
+ * Many 'linkgit:<git documentation page>' references were broken,
+ which are all fixed with this.
+
+ * "git describe --contains" often made a hard-to-justify choice of
+ tag to give name to a given commit, because it tried to come up
+ with a name with smallest number of hops from a tag, causing an old
+ commit whose close descendant that is recently tagged were not
+ described with respect to an old tag but with a newer tag. It did
+ not help that its computation of "hop" count was further tweaked to
+ penalize being on a side branch of a merge. The logic has been
+ updated to favor using the tag with the oldest tagger date, which
+ is a lot easier to explain to the end users: "We describe a commit
+ in terms of the (chronologically) oldest tag that contains the
+ commit."
+
+ * Running tests with '-x' option to trace the individual command
+ executions is a useful way to debug test scripts, but some tests
+ that capture the standard error stream and check what the command
+ said can be broken with the trace output mixed in. When running
+ our tests under "bash", however, we can redirect the trace output
+ to another file descriptor to keep the standard error of programs
+ being tested intact.
+
+ * "http.cookieFile" configuration variable clearly wants a pathname,
+ but we forgot to treat it as such by e.g. applying tilde expansion.
+
+ * When de-initialising all submodules, "git submodule deinit" gave a
+ faulty recommendation to use "git submodule deinit .", which would
+ result in a strange error message in a pathological corner case.
+ This has been corrected to suggest "submodule deinit --all" instead.
+
+ * Many commands normalize command line arguments from NFD to NFC
+ variant of UTF-8 on OSX, but commands in the "diff" family did
+ not, causing "git diff $path" to complain that no such path is
+ known to Git. They have been taught to do the normalization.
+
+ * A couple of bugs around core.autocrlf have been fixed.
+
+ * "git difftool" learned to handle unmerged paths correctly in
+ dir-diff mode.
+
+ * The "are we talking with TTY, doing an interactive session?"
+ detection has been updated to work better for "Git for Windows".
+
+
+Also contains other minor documentation updates and code clean-ups.
diff --git a/RelNotes/2.8.5.adoc b/RelNotes/2.8.5.adoc
new file mode 100644
index 0000000..7bd179f
--- /dev/null
+++ b/RelNotes/2.8.5.adoc
@@ -0,0 +1,12 @@
+Git v2.8.5 Release Notes
+========================
+
+Fixes since v2.8.4
+------------------
+
+ * "git-shell" rejects a request to serve a repository whose name
+ begins with a dash, which makes it no longer possible to get it
+ confused into spawning service programs like "git-upload-pack" with
+ an option like "--help", which in turn would spawn an interactive
+ pager, instead of working with the repository user asked to access
+ (i.e. the one whose name is "--help").
diff --git a/RelNotes/2.8.6.adoc b/RelNotes/2.8.6.adoc
new file mode 100644
index 0000000..d8db55d
--- /dev/null
+++ b/RelNotes/2.8.6.adoc
@@ -0,0 +1,4 @@
+Git v2.8.6 Release Notes
+========================
+
+This release forward-ports the fix for "ssh://..." URL from Git v2.7.6
diff --git a/RelNotes/2.9.0.adoc b/RelNotes/2.9.0.adoc
new file mode 100644
index 0000000..9916401
--- /dev/null
+++ b/RelNotes/2.9.0.adoc
@@ -0,0 +1,512 @@
+Git 2.9 Release Notes
+=====================
+
+Backward compatibility notes
+----------------------------
+
+The end-user facing Porcelain level commands in the "git diff" and
+"git log" family by default enable the rename detection; you can still
+use "diff.renames" configuration variable to disable this.
+
+Merging two branches that have no common ancestor with "git merge" is
+by default forbidden now to prevent creating such an unusual merge by
+mistake.
+
+The output formats of "git log" that indents the commit log message by
+4 spaces now expands HT in the log message by default. You can use
+the "--no-expand-tabs" option to disable this.
+
+"git commit-tree" plumbing command required the user to always sign
+its result when the user sets the commit.gpgsign configuration
+variable, which was an ancient mistake, which this release corrects.
+A script that drives commit-tree, if it relies on this mistake, now
+needs to read commit.gpgsign and pass the -S option as necessary.
+
+
+Updates since v2.8
+------------------
+
+UI, Workflows & Features
+
+ * Comes with git-multimail 1.3.1 (in contrib/).
+
+ * The end-user facing commands like "git diff" and "git log"
+ now enable the rename detection by default.
+
+ * The credential.helper configuration variable is cumulative and
+ there is no good way to override it from the command line. As
+ a special case, giving an empty string as its value now serves
+ as the signal to clear the values specified in various files.
+
+ * A new "interactive.diffFilter" configuration can be used to
+ customize the diff shown in "git add -i" sessions.
+
+ * "git p4" now allows P4 author names to be mapped to Git author
+ names.
+
+ * "git rebase -x" can be used without passing "-i" option.
+
+ * "git -c credential.<var>=<value> submodule" can now be used to
+ propagate configuration variables related to credential helper
+ down to the submodules.
+
+ * "git tag" can create an annotated tag without explicitly given an
+ "-a" (or "-s") option (i.e. when a tag message is given). A new
+ configuration variable, tag.forceSignAnnotated, can be used to tell
+ the command to create signed tag in such a situation.
+
+ * "git merge" used to allow merging two branches that have no common
+ base by default, which led to a brand new history of an existing
+ project created and then get pulled by an unsuspecting maintainer,
+ which allowed an unnecessary parallel history merged into the
+ existing project. The command has been taught not to allow this by
+ default, with an escape hatch "--allow-unrelated-histories" option
+ to be used in a rare event that merges histories of two projects
+ that started their lives independently.
+
+ * "git pull" has been taught to pass the "--allow-unrelated-histories"
+ option to underlying "git merge".
+
+ * "git apply -v" learned to report paths in the patch that were
+ skipped via --include/--exclude mechanism or being outside the
+ current working directory.
+
+ * Shell completion (in contrib/) updates.
+
+ * The commit object name reported when "rebase -i" stops has been
+ shortened.
+
+ * "git worktree add" can be given "--no-checkout" option to only
+ create an empty worktree without checking out the files.
+
+ * "git mergetools" learned to drive ExamDiff.
+
+ * "git pull --rebase" learned "--[no-]autostash" option, so that
+ the rebase.autostash configuration variable set to true can be
+ overridden from the command line.
+
+ * When "git log" shows the log message indented by 4-spaces, the
+ remainder of a line after a HT does not align in the way the author
+ originally intended. The command now expands tabs by default to help
+ such a case, and allows the users to override it with a new option,
+ "--no-expand-tabs".
+
+ * "git send-email" now uses a more readable timestamps when
+ formulating a message ID.
+
+ * "git rerere" can encounter two or more files with the same conflict
+ signature that have to be resolved in different ways, but there was
+ no way to record these separate resolutions.
+
+ * "git p4" learned to record P4 jobs in Git commit that imports from
+ the history in Perforce.
+
+ * "git describe --contains" often made a hard-to-justify choice of
+ tag to name a given commit, because it tried to come up
+ with a name with smallest number of hops from a tag, causing an old
+ commit whose close descendant that is recently tagged were not
+ described with respect to an old tag but with a newer tag. It did
+ not help that its computation of "hop" count was further tweaked to
+ penalize being on a side branch of a merge. The logic has been
+ updated to favor using the tag with the oldest tagger date, which
+ is a lot easier to explain to the end users: "We describe a commit
+ in terms of the (chronologically) oldest tag that contains the
+ commit."
+
+ * "git clone" learned the "--shallow-submodules" option.
+
+ * HTTP transport clients learned to throw extra HTTP headers at the
+ server, specified via http.extraHeader configuration variable.
+
+ * The "--compaction-heuristic" option to "git diff" family of
+ commands enables a heuristic to make the patch output more readable
+ by using a blank line as a strong hint that the contents before and
+ after it belong to logically separate units. It is still
+ experimental.
+
+ * A new configuration variable core.hooksPath allows customizing
+ where the hook directory is.
+
+ * An earlier addition of "sanitize_submodule_env" with 14111fc4 (git:
+ submodule honor -c credential.* from command line, 2016-02-29)
+ turned out to be a convoluted no-op; implement what it wanted to do
+ correctly, and stop filtering settings given via "git -c var=val".
+
+ * "git commit --dry-run" reported "No, no, you cannot commit." in one
+ case where "git commit" would have allowed you to commit, and this
+ improves it a little bit ("git commit --dry-run --short" still does
+ not give you the correct answer, for example). This is a stop-gap
+ measure in that "commit --short --dry-run" still gives an incorrect
+ result.
+
+ * The experimental "multiple worktree" feature gains more safety to
+ forbid operations on a branch that is checked out or being actively
+ worked on elsewhere, by noticing that e.g. it is being rebased.
+
+ * "git format-patch" learned a new "--base" option to record what
+ (public, well-known) commit the original series was built on in
+ its output.
+
+ * "git commit" learned to pay attention to the "commit.verbose"
+ configuration variable and act as if the "--verbose" option
+ was given from the command line.
+
+ * Updated documentation gives hints to GMail users with two-factor
+ auth enabled that they need app-specific-password when using
+ "git send-email".
+
+ * The manpage output of our documentation did not render well in
+ terminal; typeset literals in bold by default to make them stand
+ out more.
+
+ * The mark-up in the top-level README.md file has been updated to
+ typeset CLI command names differently from the body text.
+
+
+Performance, Internal Implementation, Development Support etc.
+
+ * The embedded args argv-array in the child process is used to build
+ the command line to run pack-objects instead of using a separate
+ array of strings.
+
+ * A test for tags has been restructured so that more parts of it can
+ easily be run on a platform without a working GnuPG.
+
+ * The startup_info data, which records if we are working inside a
+ repository (among other things), are now uniformly available to Git
+ subcommand implementations, and Git avoids attempting to touch
+ references when we are not in a repository.
+
+ * The command line argument parser for "receive-pack" has been
+ rewritten to use parse-options.
+
+ * A major part of "git submodule update" has been ported to C to take
+ advantage of the recently added framework to run download tasks in
+ parallel. Other updates to "git submodule" that move pieces of
+ logic to C continues.
+
+ * Rename bunch of tests on "git clone" for better organization.
+
+ * The tests that involve running httpd leaked the system-wide
+ configuration in /etc/gitconfig to the tested environment.
+
+ * Build updates for MSVC.
+
+ * The repository set-up sequence has been streamlined (the biggest
+ change is that there is no longer git_config_early()), so that we
+ do not attempt to look into refs/* when we know we do not have a
+ Git repository.
+
+ * Code restructuring around the "refs" API to prepare for pluggable
+ refs backends.
+
+ * Sources to many test helper binaries and the generated helpers
+ have been moved to t/helper/ subdirectory to reduce clutter at the
+ top level of the tree.
+
+ * Unify internal logic between "git tag -v" and "git verify-tag"
+ commands by making one directly call into the other.
+
+ * "merge-recursive" strategy incorrectly checked if a path that is
+ involved in its internal merge exists in the working tree.
+
+ * The test scripts for "git p4" (but not "git p4" implementation
+ itself) has been updated so that they would work even on a system
+ where the installed version of Python is python 3.
+
+ * As nobody maintains our in-tree git.spec.in and distros use their
+ own spec file, we stopped pretending that we support "make rpm".
+
+ * Move from "unsigned char[20]" to "struct object_id" continues.
+
+ * The code for warning_errno/die_errno has been refactored and a new
+ error_errno() reporting helper is introduced.
+ (merge 1da045f nd/error-errno later to maint).
+
+ * Running tests with '-x' option to trace the individual command
+ executions is a useful way to debug test scripts, but some tests
+ that capture the standard error stream and check what the command
+ said can be broken with the trace output mixed in. When running
+ our tests under "bash", however, we can redirect the trace output
+ to another file descriptor to keep the standard error of programs
+ being tested intact.
+
+ * t0040 had too many unnecessary repetitions in its test data. Teach
+ test-parse-options program so that a caller can tell what it
+ expects in its output, so that these repetitions can be cleaned up.
+
+ * Add perf test for "rebase -i".
+
+ * Common mistakes when writing gitlink: in our documentation are
+ found by "make check-docs".
+
+ * t9xxx series has been updated primarily for readability, while
+ fixing small bugs in it. A few scripted Porcelain commands have
+ also been updated to fix possible bugs around their use of
+ "test -z" and "test -n".
+
+ * CI test was taught to run git-svn tests.
+
+ * "git cat-file --batch-all" has been sped up, by taking advantage
+ of the fact that it does not have to read a list of objects, in two
+ ways.
+
+ * test updates to make it more readable and maintainable.
+ (merge e6273f4 es/t1500-modernize later to maint).
+
+ * "make DEVELOPER=1" worked as expected; setting DEVELOPER=1 in
+ config.mak didn't.
+ (merge 51dd3e8 mm/makefile-developer-can-be-in-config-mak later to maint).
+
+ * The way how "submodule--helper list" signals unmatch error to its
+ callers has been updated.
+
+ * A bash-ism "local" has been removed from "git submodule" scripted
+ Porcelain.
+
+
+Also contains various documentation updates and code clean-ups.
+
+
+Fixes since v2.8
+----------------
+
+Unless otherwise noted, all the fixes since v2.8 in the maintenance
+track are contained in this release (see the maintenance releases'
+notes for details).
+
+ * "git config --get-urlmatch", unlike other variants of the "git
+ config --get" family, did not signal error with its exit status
+ when there was no matching configuration.
+
+ * The "--local-env-vars" and "--resolve-git-dir" options of "git
+ rev-parse" failed to work outside a repository when the command's
+ option parsing was rewritten in 1.8.5 era.
+
+ * "git index-pack --keep[=<msg>] pack-$name.pack" simply did not work.
+
+ * Fetching of history by naming a commit object name directly didn't
+ work across remote-curl transport.
+
+ * A small memory leak in an error codepath has been plugged in xdiff
+ code.
+
+ * strbuf_getwholeline() did not NUL-terminate the buffer on certain
+ corner cases in its error codepath.
+
+ * "git mergetool" did not work well with conflicts that both sides
+ deleted.
+
+ * "git send-email" had trouble parsing alias file in mailrc format
+ when lines in it had trailing whitespaces on them.
+
+ * When "git merge --squash" stopped due to conflict, the concluding
+ "git commit" failed to read in the SQUASH_MSG that shows the log
+ messages from all the squashed commits.
+
+ * "git merge FETCH_HEAD" dereferenced NULL pointer when merging
+ nothing into an unborn history (which is arguably unusual usage,
+ which perhaps was the reason why nobody noticed it).
+
+ * When "git worktree" feature is in use, "git branch -d" allowed
+ deletion of a branch that is checked out in another worktree,
+ which was wrong.
+
+ * When "git worktree" feature is in use, "git branch -m" renamed a
+ branch that is checked out in another worktree without adjusting
+ the HEAD symbolic ref for the worktree.
+
+ * "git diff -M" used to work better when two originally identical
+ files A and B got renamed to X/A and X/B by pairing A to X/A and B
+ to X/B, but this was broken in the 2.0 timeframe.
+
+ * "git send-pack --all <there>" was broken when its command line
+ option parsing was written in the 2.6 timeframe.
+
+ * "git format-patch --help" showed `-s` and `--no-patch` as if these
+ are valid options to the command. We already hide `--patch` option
+ from the documentation, because format-patch is about showing the
+ diff, and the documentation now hides these options as well.
+
+ * When running "git blame $path" with unnormalized data in the index
+ for the path, the data in the working tree was blamed, even though
+ "git add" would not have changed what is already in the index, due
+ to "safe crlf" that disables the line-end conversion. It has been
+ corrected.
+
+ * A change back in version 2.7 to "git branch" broke display of a
+ symbolic ref in a non-standard place in the refs/ hierarchy (we
+ expect symbolic refs to appear in refs/remotes/*/HEAD to point at
+ the primary branch the remote has, and as .git/HEAD to point at the
+ branch we locally checked out).
+
+ * A partial rewrite of "git submodule" in the 2.7 timeframe changed
+ the way the gitdir: pointer in the submodules point at the real
+ repository location to use absolute paths by accident. This has
+ been corrected.
+
+ * "git commit" misbehaved in a few minor ways when an empty message
+ is given via -m '', all of which has been corrected.
+
+ * Support for CRAM-MD5 authentication method in "git imap-send" did
+ not work well.
+
+ * Upcoming OpenSSL 1.1.0 will break compilation by updating a few API
+ elements we use in imap-send, which has been adjusted for the change.
+
+ * The socks5:// proxy support added back in 2.6.4 days was not aware
+ that socks5h:// proxies behave differently from socks5:// proxies.
+
+ * "git config" had a codepath that tried to pass a NULL to
+ printf("%s"), which nobody seems to have noticed.
+
+ * On Cygwin, object creation uses the "create a temporary and then
+ rename it to the final name" pattern, not "create a temporary,
+ hardlink it to the final name and then unlink the temporary"
+ pattern.
+
+ This is necessary to use Git on Windows shared directories, and is
+ already enabled for the MinGW and plain Windows builds. It also
+ has been used in Cygwin packaged versions of Git for quite a while.
+ See https://lore.kernel.org/git/20160419091055.GF2345@dinwoodie.org/
+
+ * "merge-octopus" strategy did not ensure that the index is clean
+ when merge begins.
+
+ * When "git merge" notices that the merge can be resolved purely at
+ the tree level (without having to merge blobs) and the resulting
+ tree happens to already exist in the object store, it forgot to
+ update the index, which left an inconsistent state that would
+ break later operations.
+
+ * "git submodule" reports the paths of submodules the command
+ recurses into, but these paths were incorrectly reported when
+ the command was not run from the root level of the superproject.
+
+ * The "user.useConfigOnly" configuration variable makes it an error
+ if users do not explicitly set user.name and user.email. However,
+ its check was not done early enough and allowed another error to
+ trigger, reporting that the default value we guessed from the
+ system setting was unusable. This was a suboptimal end-user
+ experience as we want the users to set user.name/user.email without
+ relying on the auto-detection at all.
+
+ * "git mv old new" did not adjust the path for a submodule that lives
+ as a subdirectory inside old/ directory correctly.
+
+ * "git replace -e" did not honour "core.editor" configuration.
+
+ * "git push" from a corrupt repository that attempts to push a large
+ number of refs deadlocked; the thread to relay rejection notices
+ for these ref updates blocked on writing them to the main thread,
+ after the main thread at the receiving end notices that the push
+ failed and decides not to read these notices and return a failure.
+
+ * mmap emulation on Windows has been optimized and work better without
+ consuming paging store when not needed.
+
+ * A question by "git send-email" to ask the identity of the sender
+ has been updated.
+
+ * UI consistency improvements for "git mergetool".
+
+ * "git rebase -m" could be asked to rebase an entire branch starting
+ from the root, but failed by assuming that there always is a parent
+ commit to the first commit on the branch.
+
+ * Fix a broken "p4 lfs" test.
+
+ * Recent update to Git LFS broke "git p4" by changing the output from
+ its "lfs pointer" subcommand.
+
+ * "git fetch" test t5510 was flaky while running a (forced) automagic
+ garbage collection.
+
+ * Documentation updates to help contributors setting up Travis CI
+ test for their patches.
+
+ * Some multi-byte encoding can have a backslash byte as a later part
+ of one letter, which would confuse "highlight" filter used in
+ gitweb.
+
+ * "git commit-tree" plumbing command required the user to always sign
+ its result when the user sets the commit.gpgsign configuration
+ variable, which was an ancient mistake. Rework "git rebase" that
+ relied on this mistake so that it reads commit.gpgsign and pass (or
+ not pass) the -S option to "git commit-tree" to keep the end-user
+ expectation the same, while teaching "git commit-tree" to ignore
+ the configuration variable. This will stop requiring the users to
+ sign commit objects used internally as an implementation detail of
+ "git stash".
+
+ * "http.cookieFile" configuration variable clearly wants a pathname,
+ but we forgot to treat it as such by e.g. applying tilde expansion.
+
+ * Consolidate description of tilde-expansion that is done to
+ configuration variables that take pathname to a single place.
+
+ * Correct faulty recommendation to use "git submodule deinit ." when
+ de-initialising all submodules, which would result in a strange
+ error message in a pathological corner case.
+
+ * Many 'linkgit:<git documentation page>' references were broken,
+ which are all fixed with this.
+
+ * "git rerere" can get confused by conflict markers deliberately left
+ by the inner merge step, because they are indistinguishable from
+ the real conflict markers left by the outermost merge which are
+ what the end user and "rerere" need to look at. This was fixed by
+ making the conflict markers left by the inner merges a bit longer.
+ (merge 0f9fd5c jc/ll-merge-internal later to maint).
+
+ * CI test was taught to build documentation pages.
+
+ * "git fsck" learned to catch NUL byte in a commit object as
+ potential error and warn.
+
+ * Portability enhancement for "rebase -i" to help platforms whose
+ shell does not like "for i in <empty>" (which is not POSIX-kosher).
+
+ * On Windows, .git and optionally any files whose name starts with a
+ dot are now marked as hidden, with a core.hideDotFiles knob to
+ customize this behaviour.
+
+ * Documentation for "git merge --verify-signatures" has been updated
+ to clarify that the signature of only the commit at the tip is
+ verified. Also the phrasing used for signature and key validity is
+ adjusted to align with that used by OpenPGP.
+
+ * A couple of bugs around core.autocrlf have been fixed.
+
+ * Many commands normalize command line arguments from NFD to NFC
+ variant of UTF-8 on OSX, but commands in the "diff" family did
+ not, causing "git diff $path" to complain that no such path is
+ known to Git. They have been taught to do the normalization.
+
+ * "git difftool" learned to handle unmerged paths correctly in
+ dir-diff mode.
+
+ * The "are we talking with TTY, doing an interactive session?"
+ detection has been updated to work better for "Git for Windows".
+
+ * We forgot to add "git log --decorate=auto" to documentation when we
+ added the feature back in v2.1.0 timeframe.
+ (merge 462cbb4 rj/log-decorate-auto later to maint).
+
+ * "git fast-import --export-marks" would overwrite the existing marks
+ file even when it makes a dump from its custom die routine.
+ Prevent it from doing so when we have an import-marks file but
+ haven't finished reading it.
+ (merge f4beed6 fc/fast-import-broken-marks-file later to maint).
+
+ * "git rebase -i", after it fails to auto-resolve the conflict, had
+ an unnecessary call to "git rerere" from its very early days, which
+ was spotted recently; the call has been removed.
+ (merge 7063693 js/rebase-i-dedup-call-to-rerere later to maint).
+
+ * Other minor clean-ups and documentation updates
+ (merge cd82b7a pa/cherry-pick-doc-typo later to maint).
+ (merge 2bb73ae rs/patch-id-use-skip-prefix later to maint).
+ (merge aa20cbc rs/apply-name-terminate later to maint).
+ (merge fe17fc0 jc/t2300-setup later to maint).
+ (merge e256eec jk/shell-portability later to maint).
diff --git a/RelNotes/2.9.1.adoc b/RelNotes/2.9.1.adoc
new file mode 100644
index 0000000..3383940
--- /dev/null
+++ b/RelNotes/2.9.1.adoc
@@ -0,0 +1,117 @@
+Git v2.9.1 Release Notes
+========================
+
+Fixes since v2.9
+----------------
+
+ * When "git daemon" is run without --[init-]timeout specified, a
+ connection from a client that silently goes offline can hang around
+ for a long time, wasting resources. The socket-level KEEPALIVE has
+ been enabled to allow the OS to notice such failed connections.
+
+ * The commands in `git log` family take %C(auto) in a custom format
+ string. This unconditionally turned the color on, ignoring
+ --no-color or with --color=auto when the output is not connected to
+ a tty; this was corrected to make the format truly behave as
+ "auto".
+
+ * "git rev-list --count" whose walk-length is limited with "-n"
+ option did not work well with the counting optimized to look at the
+ bitmap index.
+
+ * "git show -W" (extend hunks to cover the entire function, delimited
+ by lines that match the "funcname" pattern) used to show the entire
+ file when a change added an entire function at the end of the file,
+ which has been fixed.
+
+ * The documentation set has been updated so that literal commands,
+ configuration variables and environment variables are consistently
+ typeset in fixed-width font and bold in manpages.
+
+ * "git svn propset" subcommand that was added in 2.3 days is
+ documented now.
+
+ * The documentation tries to consistently spell "GPG"; when
+ referring to the specific program name, "gpg" is used.
+
+ * "git reflog" stopped upon seeing an entry that denotes a branch
+ creation event (aka "unborn"), which made it appear as if the
+ reflog was truncated.
+
+ * The git-prompt scriptlet (in contrib/) was not friendly with those
+ who uses "set -u", which has been fixed.
+
+ * A codepath that used alloca(3) to place an unbounded amount of data
+ on the stack has been updated to avoid doing so.
+
+ * "git update-index --add --chmod=+x file" may be usable as an escape
+ hatch, but not a friendly thing to force for people who do need to
+ use it regularly. "git add --chmod=+x file" can be used instead.
+
+ * Build improvements for gnome-keyring (in contrib/)
+
+ * "git status" used to say "working directory" when it meant "working
+ tree".
+
+ * Comments about misbehaving FreeBSD shells have been clarified with
+ the version number (9.x and before are broken, newer ones are OK).
+
+ * "git cherry-pick A" worked on an unborn branch, but "git
+ cherry-pick A..B" didn't.
+
+ * "git add -i/-p" learned to honor diff.compactionHeuristic
+ experimental knob, so that the user can work on the same hunk split
+ as "git diff" output.
+
+ * "log --graph --format=" learned that "%>|(N)" specifies the width
+ relative to the terminal's left edge, not relative to the area to
+ draw text that is to the right of the ancestry-graph section. It
+ also now accepts negative N that means the column limit is relative
+ to the right border.
+
+ * The ownership rule for the piece of memory that hold references to
+ be fetched in "git fetch" was screwy, which has been cleaned up.
+
+ * "git bisect" makes an internal call to "git diff-tree" when
+ bisection finds the culprit, but this call did not initialize the
+ data structure to pass to the diff-tree API correctly.
+
+ * Formats of the various data (and how to validate them) where we use
+ GPG signature have been documented.
+
+ * Fix an unintended regression in v2.9 that breaks "clone --depth"
+ that recurses down to submodules by forcing the submodules to also
+ be cloned shallowly, which many server instances that host upstream
+ of the submodules are not prepared for.
+
+ * Fix unnecessarily waste in the idiomatic use of ': ${VAR=default}'
+ to set the default value, without enclosing it in double quotes.
+
+ * Some platform-specific code had non-ANSI strict declarations of C
+ functions that do not take any parameters, which has been
+ corrected.
+
+ * The internal code used to show local timezone offset is not
+ prepared to handle timestamps beyond year 2100, and gave a
+ bogus offset value to the caller. Use a more benign looking
+ +0000 instead and let "git log" going in such a case, instead
+ of aborting.
+
+ * One among four invocations of readlink(1) in our test suite has
+ been rewritten so that the test can run on systems without the
+ command (others are in valgrind test framework and t9802).
+
+ * t/perf needs /usr/bin/time with GNU extension; the invocation of it
+ is updated to "gtime" on Darwin.
+
+ * A bug, which caused "git p4" while running under verbose mode to
+ report paths that are omitted due to branch prefix incorrectly, has
+ been fixed; the command said "Ignoring file outside of prefix" for
+ paths that are _inside_.
+
+ * The top level documentation "git help git" still pointed at the
+ documentation set hosted at now-defunct google-code repository.
+ Update it to point to https://git.github.io/htmldocs/git.html
+ instead.
+
+Also contains minor documentation updates and code clean-ups.
diff --git a/RelNotes/2.9.2.adoc b/RelNotes/2.9.2.adoc
new file mode 100644
index 0000000..2620003
--- /dev/null
+++ b/RelNotes/2.9.2.adoc
@@ -0,0 +1,13 @@
+Git v2.9.2 Release Notes
+========================
+
+Fixes since v2.9.1
+------------------
+
+ * A fix merged to v2.9.1 had a few tests that are not meant to be
+ run on platforms without 64-bit long, which caused unnecessary
+ test failures on them because we didn't detect the platform and
+ skip them. These tests are now skipped on platforms that they
+ are not applicable to.
+
+No other change is included in this update.
diff --git a/RelNotes/2.9.3.adoc b/RelNotes/2.9.3.adoc
new file mode 100644
index 0000000..305e080
--- /dev/null
+++ b/RelNotes/2.9.3.adoc
@@ -0,0 +1,170 @@
+Git v2.9.3 Release Notes
+========================
+
+Fixes since v2.9.2
+------------------
+
+ * A helper function that takes the contents of a commit object and
+ finds its subject line did not ignore leading blank lines, as is
+ commonly done by other codepaths. Make it ignore leading blank
+ lines to match.
+
+ * Git does not know what the contents in the index should be for a
+ path added with "git add -N" yet, so "git grep --cached" should not
+ show hits (or show lack of hits, with -L) in such a path, but that
+ logic does not apply to "git grep", i.e. searching in the working
+ tree files. But we did so by mistake, which has been corrected.
+
+ * "git rebase -i --autostash" did not restore the auto-stashed change
+ when the operation was aborted.
+
+ * "git commit --amend --allow-empty-message -S" for a commit without
+ any message body could have misidentified where the header of the
+ commit object ends.
+
+ * More mark-up updates to typeset strings that are expected to
+ literally typed by the end user in fixed-width font.
+
+ * For a long time, we carried an in-code comment that said our
+ colored output would work only when we use fprintf/fputs on
+ Windows, which no longer is the case for the past few years.
+
+ * "gc.autoPackLimit" when set to 1 should not trigger a repacking
+ when there is only one pack, but the code counted poorly and did
+ so.
+
+ * One part of "git am" had an oddball helper function that called
+ stuff from outside "his" as opposed to calling what we have "ours",
+ which was not gender-neutral and also inconsistent with the rest of
+ the system where outside stuff is usually called "theirs" in
+ contrast to "ours".
+
+ * The test framework learned a new helper test_match_signal to
+ check an exit code from getting killed by an expected signal.
+
+ * "git blame -M" missed a single line that was moved within the file.
+
+ * Fix recently introduced codepaths that are involved in parallel
+ submodule operations, which gave up on reading too early, and
+ could have wasted CPU while attempting to write under a corner
+ case condition.
+
+ * "git grep -i" has been taught to fold case in non-ascii locales
+ correctly.
+
+ * A test that unconditionally used "mktemp" learned that the command
+ is not necessarily available everywhere.
+
+ * "git blame file" allowed the lineage of lines in the uncommitted,
+ unadded contents of "file" to be inspected, but it refused when
+ "file" did not appear in the current commit. When "file" was
+ created by renaming an existing file (but the change has not been
+ committed), this restriction was unnecessarily tight.
+
+ * "git add -N dir/file && git write-tree" produced an incorrect tree
+ when there are other paths in the same directory that sorts after
+ "file".
+
+ * "git fetch http://user:pass@host/repo..." scrubbed the userinfo
+ part, but "git push" didn't.
+
+ * An age old bug that caused "git diff --ignore-space-at-eol"
+ misbehave has been fixed.
+
+ * "git notes merge" had a code to see if a path exists (and fails if
+ it does) and then open the path for writing (when it doesn't).
+ Replace it with open with O_EXCL.
+
+ * "git pack-objects" and "git index-pack" mostly operate with off_t
+ when talking about the offset of objects in a packfile, but there
+ were a handful of places that used "unsigned long" to hold that
+ value, leading to an unintended truncation.
+
+ * Recent update to "git daemon" tries to enable the socket-level
+ KEEPALIVE, but when it is spawned via inetd, the standard input
+ file descriptor may not necessarily be connected to a socket.
+ Suppress an ENOTSOCK error from setsockopt().
+
+ * Recent FreeBSD stopped making perl available at /usr/bin/perl;
+ switch the default the built-in path to /usr/local/bin/perl on not
+ too ancient FreeBSD releases.
+
+ * "git status" learned to suggest "merge --abort" during a conflicted
+ merge, just like it already suggests "rebase --abort" during a
+ conflicted rebase.
+
+ * The .c/.h sources are marked as such in our .gitattributes file so
+ that "git diff -W" and friends would work better.
+
+ * Existing autoconf generated test for the need to link with pthread
+ library did not check all the functions from pthread libraries;
+ recent FreeBSD has some functions in libc but not others, and we
+ mistakenly thought linking with libc is enough when it is not.
+
+ * Allow http daemon tests in Travis CI tests.
+
+ * Users of the parse_options_concat() API function need to allocate
+ extra slots in advance and fill them with OPT_END() when they want
+ to decide the set of supported options dynamically, which makes the
+ code error-prone and hard to read. This has been corrected by tweaking
+ the API to allocate and return a new copy of "struct option" array.
+
+ * The use of strbuf in "git rm" to build filename to remove was a bit
+ suboptimal, which has been fixed.
+
+ * "git commit --help" said "--no-verify" is only about skipping the
+ pre-commit hook, and failed to say that it also skipped the
+ commit-msg hook.
+
+ * "git merge" in Git v2.9 was taught to forbid merging an unrelated
+ lines of history by default, but that is exactly the kind of thing
+ the "--rejoin" mode of "git subtree" (in contrib/) wants to do.
+ "git subtree" has been taught to use the "--allow-unrelated-histories"
+ option to override the default.
+
+ * The build procedure for "git persistent-https" helper (in contrib/)
+ has been updated so that it can be built with more recent versions
+ of Go.
+
+ * There is an optimization used in "git diff $treeA $treeB" to borrow
+ an already checked-out copy in the working tree when it is known to
+ be the same as the blob being compared, expecting that open/mmap of
+ such a file is faster than reading it from the object store, which
+ involves inflating and applying delta. This however kicked in even
+ when the checked-out copy needs to go through the convert-to-git
+ conversion (including the clean filter), which defeats the whole
+ point of the optimization. The optimization has been disabled when
+ the conversion is necessary.
+
+ * "git -c grep.patternType=extended log --basic-regexp" misbehaved
+ because the internal API to access the grep machinery was not
+ designed well.
+
+ * Windows port was failing some tests in t4130, due to the lack of
+ inum in the returned values by its lstat(2) emulation.
+
+ * The characters in the label shown for tags/refs for commits in
+ "gitweb" output are now properly escaped for proper HTML output.
+
+ * FreeBSD can lie when asked mtime of a directory, which made the
+ untracked cache code to fall back to a slow-path, which in turn
+ caused tests in t7063 to fail because it wanted to verify the
+ behaviour of the fast-path.
+
+ * Squelch compiler warnings for netmalloc (in compat/) library.
+
+ * The API documentation for hashmap was unclear if hashmap_entry
+ can be safely discarded without any other consideration. State
+ that it is safe to do so.
+
+ * Not-so-recent rewrite of "git am" that started making internal
+ calls into the commit machinery had an unintended regression, in
+ that no matter how many seconds it took to apply many patches, the
+ resulting committer timestamp for the resulting commits were all
+ the same.
+
+ * "git difftool <paths>..." started in a subdirectory failed to
+ interpret the paths relative to that directory, which has been
+ fixed.
+
+Also contains minor documentation updates and code clean-ups.
diff --git a/RelNotes/2.9.4.adoc b/RelNotes/2.9.4.adoc
new file mode 100644
index 0000000..9768293
--- /dev/null
+++ b/RelNotes/2.9.4.adoc
@@ -0,0 +1,90 @@
+Git v2.9.4 Release Notes
+========================
+
+Fixes since v2.9.3
+------------------
+
+ * There are certain house-keeping tasks that need to be performed at
+ the very beginning of any Git program, and programs that are not
+ built-in commands had to do them exactly the same way as "git"
+ potty does. It was easy to make mistakes in one-off standalone
+ programs (like test helpers). A common "main()" function that
+ calls cmd_main() of individual program has been introduced to
+ make it harder to make mistakes.
+
+ * "git merge" with renormalization did not work well with
+ merge-recursive, due to "safer crlf" conversion kicking in when it
+ shouldn't.
+
+ * The reflog output format is documented better, and a new format
+ --date=unix to report the seconds-since-epoch (without timezone)
+ has been added.
+
+ * "git push --force-with-lease" already had enough logic to allow
+ ensuring that such a push results in creation of a ref (i.e. the
+ receiving end did not have another push from sideways that would be
+ discarded by our force-pushing), but didn't expose this possibility
+ to the users. It does so now.
+
+ * "import-tars" fast-import script (in contrib/) used to ignore a
+ hardlink target and replaced it with an empty file, which has been
+ corrected to record the same blob as the other file the hardlink is
+ shared with.
+
+ * "git mv dir non-existing-dir/" did not work in some environments
+ the same way as existing mainstream platforms. The code now moves
+ "dir" to "non-existing-dir", without relying on rename("A", "B/")
+ that strips the trailing slash of '/'.
+
+ * The "t/" hierarchy is prone to get an unusual pathname; "make test"
+ has been taught to make sure they do not contain paths that cannot
+ be checked out on Windows (and the mechanism can be reusable to
+ catch pathnames that are not portable to other platforms as need
+ arises).
+
+ * When "git merge-recursive" works on history with many criss-cross
+ merges in "verbose" mode, the names the command assigns to the
+ virtual merge bases could have overwritten each other by unintended
+ reuse of the same piece of memory.
+
+ * "git checkout --detach <branch>" used to give the same advice
+ message as that is issued when "git checkout <tag>" (or anything
+ that is not a branch name) is given, but asking with "--detach" is
+ an explicit enough sign that the user knows what is going on. The
+ advice message has been squelched in this case.
+
+ * "git difftool" by default ignores the error exit from the backend
+ commands it spawns, because often they signal that they found
+ differences by exiting with a non-zero status code just like "diff"
+ does; the exit status codes 126 and above however are special in
+ that they are used to signal that the command is not executable,
+ does not exist, or killed by a signal. "git difftool" has been
+ taught to notice these exit status codes.
+
+ * On Windows, help.browser configuration variable used to be ignored,
+ which has been corrected.
+
+ * The "git -c var[=val] cmd" facility to append a configuration
+ variable definition at the end of the search order was described in
+ git(1) manual page, but not in git-config(1), which was more likely
+ place for people to look for when they ask "can I make a one-shot
+ override, and if so how?"
+
+ * The tempfile (hence its user lockfile) API lets the caller to open
+ a file descriptor to a temporary file, write into it and then
+ finalize it by first closing the filehandle and then either
+ removing or renaming the temporary file. When the process spawns a
+ subprocess after obtaining the file descriptor, and if the
+ subprocess has not exited when the attempt to remove or rename is
+ made, the last step fails on Windows, because the subprocess has
+ the file descriptor still open. Open tempfile with O_CLOEXEC flag
+ to avoid this (on Windows, this is mapped to O_NOINHERIT).
+
+ * "git-shell" rejects a request to serve a repository whose name
+ begins with a dash, which makes it no longer possible to get it
+ confused into spawning service programs like "git-upload-pack" with
+ an option like "--help", which in turn would spawn an interactive
+ pager, instead of working with the repository user asked to access
+ (i.e. the one whose name is "--help").
+
+Also contains minor documentation updates and code clean-ups.
diff --git a/RelNotes/2.9.5.adoc b/RelNotes/2.9.5.adoc
new file mode 100644
index 0000000..668313a
--- /dev/null
+++ b/RelNotes/2.9.5.adoc
@@ -0,0 +1,4 @@
+Git v2.9.5 Release Notes
+========================
+
+This release forward-ports the fix for "ssh://..." URL from Git v2.7.6
diff --git a/ReviewingGuidelines.adoc b/ReviewingGuidelines.adoc
new file mode 100644
index 0000000..6534643
--- /dev/null
+++ b/ReviewingGuidelines.adoc
@@ -0,0 +1,179 @@
+Reviewing Patches in the Git Project
+====================================
+
+Introduction
+------------
+The Git development community is a widely distributed, diverse, ever-changing
+group of individuals. Asynchronous communication via the Git mailing list poses
+unique challenges when reviewing or discussing patches. This document contains
+some guiding principles and helpful tools you can use to make your reviews both
+more efficient for yourself and more effective for other contributors.
+
+Note that none of the recommendations here are binding or in any way a
+requirement of participation in the Git community. They are provided as a
+resource to supplement your skills as a contributor.
+
+Principles
+----------
+
+Selecting patch(es) to review
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+If you are looking for a patch series in need of review, start by checking
+the latest "What's cooking in git.git" email
+(https://lore.kernel.org/git/xmqqilm1yp3m.fsf@gitster.g/[example]). The "What's
+cooking" emails & replies can be found using the query `s:"What's cooking"` on
+the https://lore.kernel.org/git/[`lore.kernel.org` mailing list archive];
+alternatively, you can find the contents of the "What's cooking" email tracked
+in `whats-cooking.txt` on the `todo` branch of Git. Topics tagged with "Needs
+review" and those in the "[New Topics]" section are typically those that would
+benefit the most from additional review.
+
+Patches can also be searched manually in the mailing list archive using a query
+like `s:"PATCH" -s:"Re:"`. You can browse these results for topics relevant to
+your expertise or interest.
+
+If you've already contributed to Git, you may also be CC'd in another
+contributor's patch series. These are topics where the author feels that your
+attention is warranted. This may be because their patch changes something you
+wrote previously (making you a good judge of whether the new approach does or
+doesn't work), or because you have the expertise to provide an exceptionally
+helpful review. There is no requirement to review these patches but, in the
+spirit of open source collaboration, you should strongly consider doing so.
+
+Reviewing patches
+~~~~~~~~~~~~~~~~~
+While every contributor takes their own approach to reviewing patches, here are
+some general pieces of advice to make your reviews as clear and helpful as
+possible. The advice is broken into two rough categories: high-level reviewing
+guidance, and concrete tips for interacting with patches on the mailing list.
+
+==== High-level guidance
+- Remember to review the content of commit messages for correctness and clarity,
+ in addition to the code change in the patch's diff. The commit message of a
+ patch should accurately and fully explain the code change being made in the
+ diff.
+
+- Reviewing test coverage is an important - but easy to overlook - component of
+ reviews. A patch's changes may be covered by existing tests, or new tests may
+ be introduced to exercise new behavior. Checking out a patch or series locally
+ allows you to manually mutate lines of new & existing tests to verify expected
+ pass/fail behavior. You can use this information to verify proper coverage or
+ to suggest additional tests the author could add.
+
+- When providing a recommendation, be as clear as possible about whether you
+ consider it "blocking" (the code would be broken or otherwise made worse if an
+ issue isn't fixed) or "non-blocking" (the patch could be made better by taking
+ the recommendation, but acceptance of the series does not require it).
+ Non-blocking recommendations can be particularly ambiguous when they are
+ related to - but outside the scope of - a series ("nice-to-have"s), or when
+ they represent only stylistic differences between the author and reviewer.
+
+- When commenting on an issue, try to include suggestions for how the author
+ could fix it. This not only helps the author to understand and fix the issue,
+ it also deepens and improves your understanding of the topic.
+
+- Reviews do not need to exclusively point out problems. Positive
+ reviews indicate that it is not only the original author of the
+ patches who care about the issue the patches address, and are
+ highly encouraged.
+
+- Do not hesitate to give positive reviews on a series from your
+ work colleague. If your positive review is written well, it will
+ not make you look as if you two are representing corporate
+ interest on a series that is otherwise uninteresting to other
+ community members and shoving it down their throat.
+
+- Write a positive review in such a way that others can understand
+ why you support the goal, the approach, and the implementation the
+ patches took. Make sure to demonstrate that you did thoroughly read
+ the series and understood problem area well enough to be able to
+ say that the patches are written well. Feel free to "think out
+ loud" in your review: describe how you read & understood a complex section of
+ a patch, ask a question about something that confused you, point out something
+ you found exceptionally well-written, etc.
+
+- In particular, uplifting feedback goes a long way towards
+ encouraging contributors to participate more actively in the Git
+ community.
+
+==== Performing your review
+- Provide your review comments per-patch in a plaintext "Reply-All" email to the
+ relevant patch. Comments should be made inline, immediately below the relevant
+ section(s).
+
+- You may find that the limited context provided in the patch diff is sometimes
+ insufficient for a thorough review. In such cases, you can review patches in
+ your local tree by either applying patches with linkgit:git-am[1] or checking
+ out the associated branch from https://github.com/gitster/git once the series
+ is tracked there.
+
+- Large, complicated patch diffs are sometimes unavoidable, such as when they
+ refactor existing code. If you find such a patch difficult to parse, try
+ reviewing the diff produced with the `--color-moved` and/or
+ `--ignore-space-change` options.
+
+- If a patch is long, you are encouraged to delete parts of it that are
+ unrelated to your review from the email reply. Make sure to leave enough
+ context for readers to understand your comments!
+
+- If you cannot complete a full review of a series all at once, consider letting
+ the author know (on- or off-list) if/when you plan to review the rest of the
+ series.
+
+Completing a review
+~~~~~~~~~~~~~~~~~~~
+Once each patch of a series is reviewed, the author (and/or other contributors)
+may discuss the review(s). This may result in no changes being applied, or the
+author will send a new version of their patch(es).
+
+After a series is rerolled in response to your or others' review, make sure to
+re-review the updates. If you are happy with the state of the patch series,
+explicitly indicate your approval (typically with a reply to the latest
+version's cover letter). Optionally, you can let the author know that they can
+add a "Reviewed-by: <you>" trailer if they resubmit the reviewed patch verbatim
+in a later iteration of the series.
+
+Finally, subsequent "What's cooking" emails may explicitly ask whether a
+reviewed topic is ready for merging to the `next` branch (typically phrased
+"Will merge to \'next\'?"). You can help the maintainer and author by responding
+with a short description of the state of your (and others', if applicable)
+review, including the links to the relevant thread(s).
+
+Terminology
+-----------
+nit: ::
+ Denotes a small issue that should be fixed, such as a typographical error
+ or misalignment of conditions in an `if()` statement.
+
+aside: ::
+optional: ::
+non-blocking: ::
+ Indicates to the reader that the following comment should not block the
+ acceptance of the patch or series. These are typically recommendations
+ related to code organization & style, or musings about topics related to
+ the patch in question, but beyond its scope.
+
+s/<before>/<after>/::
+ Shorthand for "you wrote <before>, but I think you meant <after>," usually
+ for misspellings or other typographical errors. The syntax is a reference
+ to "substitute" command commonly found in Unix tools such as `ed`, `sed`,
+ `vim`, and `perl`.
+
+cover letter::
+ The "Patch 0" of a multi-patch series. This email describes the
+ high-level intent and structure of the patch series to readers on the
+ Git mailing list. It is also where the changelog notes and range-diff of
+ subsequent versions are provided by the author.
++
+On single-patch submissions, cover letter content is typically not sent as a
+separate email. Instead, it is inserted between the end of the patch's commit
+message (after the `---`) and the beginning of the diff.
+
+#leftoverbits::
+ Used by either an author or a reviewer to describe features or suggested
+ changes that are out-of-scope of a given patch or series, but are relevant
+ to the topic for the sake of discussion.
+
+See Also
+--------
+link:MyFirstContribution.html[MyFirstContribution]
diff --git a/SubmittingPatches.adoc b/SubmittingPatches.adoc
new file mode 100644
index 0000000..958e3cc
--- /dev/null
+++ b/SubmittingPatches.adoc
@@ -0,0 +1,838 @@
+Submitting Patches
+==================
+
+== Guidelines
+
+Here are some guidelines for contributing back to this
+project. There is also a link:MyFirstContribution.html[step-by-step tutorial]
+available which covers many of these same guidelines.
+
+[[patch-flow]]
+=== A typical life cycle of a patch series
+
+To help us understand the reason behind various guidelines given later
+in the document, first let's understand how the life cycle of a
+typical patch series for this project goes.
+
+. You come up with an itch. You code it up. You do not need any
+ pre-authorization from the project to do so.
++
+Your patches will be reviewed by other contributors on the mailing
+list, and the reviews will be done to assess the merit of various
+things, like the general idea behind your patch (including "is it
+solving a problem worth solving in the first place?"), the reason
+behind the design of the solution, and the actual implementation.
+The guidelines given here are there to help your patches by making
+them easier to understand by the reviewers.
+
+. You send the patches to the list and cc people who may need to know
+ about the change. Your goal is *not* necessarily to convince others
+ that what you are building is good. Your goal is to get help in
+ coming up with a solution for the "itch" that is better than what
+ you can build alone.
++
+The people who may need to know are the ones who worked on the code
+you are touching. These people happen to be the ones who are
+most likely to be knowledgeable enough to help you, but
+they have no obligation to help you (i.e. you ask them for help,
+you don't demand). +git log -p {litdd} _$area_you_are_modifying_+ would
+help you find out who they are.
+
+. You get comments and suggestions for improvements. You may even get
+ them in an "on top of your change" patch form. You are expected to
+ respond to them with "Reply-All" on the mailing list, while taking
+ them into account while preparing an updated set of patches.
+
+. Polish, refine, and re-send your patches to the list and to the people
+ who spent their time to improve your patch. Go back to step (2).
+
+. While the above iterations improve your patches, the maintainer may
+ pick the patches up from the list and queue them to the `seen`
+ branch, in order to make it easier for people to play with it
+ without having to pick up and apply the patches to their trees
+ themselves. Being in `seen` has no other meaning. Specifically, it
+ does not mean the patch was "accepted" in any way.
+
+. When the discussion reaches a consensus that the latest iteration of
+ the patches are in good enough shape, the maintainer includes the
+ topic in the "What's cooking" report that are sent out a few times a
+ week to the mailing list, marked as "Will merge to 'next'." This
+ decision is primarily made by the maintainer with help from those
+ who participated in the review discussion.
+
+. After the patches are merged to the 'next' branch, the discussion
+ can still continue to further improve them by adding more patches on
+ top, but by the time a topic gets merged to 'next', it is expected
+ that everybody agrees that the scope and the basic direction of the
+ topic are appropriate, so such an incremental updates are limited to
+ small corrections and polishing. After a topic cooks for some time
+ (like 7 calendar days) in 'next' without needing further tweaks on
+ top, it gets merged to the 'master' branch and wait to become part
+ of the next major release.
+
+In the following sections, many techniques and conventions are listed
+to help your patches get reviewed effectively in such a life cycle.
+
+
+[[choose-starting-point]]
+=== Choose a starting point.
+
+As a preliminary step, you must first choose a starting point for your
+work. Typically this means choosing a branch, although technically
+speaking it is actually a particular commit (typically the HEAD, or tip,
+of the branch).
+
+There are several important branches to be aware of. Namely, there are
+four integration branches as discussed in linkgit:gitworkflows[7]:
+
+* maint
+* master
+* next
+* seen
+
+The branches lower on the list are typically descendants of the ones
+that come before it. For example, `maint` is an "older" branch than
+`master` because `master` usually has patches (commits) on top of
+`maint`.
+
+There are also "topic" branches, which contain work from other
+contributors. Topic branches are created by the Git maintainer (in
+their fork) to organize the current set of incoming contributions on
+the mailing list, and are itemized in the regular "What's cooking in
+git.git" announcements. To find the tip of a topic branch, run `git log
+--first-parent master..seen` and look for the merge commit. The second
+parent of this commit is the tip of the topic branch.
+
+There is one guiding principle for choosing the right starting point: in
+general, always base your work on the oldest integration branch that
+your change is relevant to (see "Merge upwards" in
+linkgit:gitworkflows[7]). What this principle means is that for the
+vast majority of cases, the starting point for new work should be the
+latest HEAD commit of `maint` or `master` based on the following cases:
+
+* If you are fixing bugs in the released version, use `maint` as the
+ starting point (which may mean you have to fix things without using
+ new API features on the cutting edge that recently appeared in
+ `master` but were not available in the released version).
+
+* Otherwise (such as if you are adding new features) use `master`.
+
+
+NOTE: In exceptional cases, a bug that was introduced in an old
+version may have to be fixed for users of releases that are much older
+than the recent releases. `git describe --contains X` may describe
+`X` as `v2.30.0-rc2-gXXXXXX` for the commit `X` that introduced the
+bug, and the bug may be so high-impact that we may need to issue a new
+maintenance release for Git 2.30.x series, when "Git 2.41.0" is the
+current release. In such a case, you may want to use the tip of the
+maintenance branch for the 2.30.x series, which may be available in the
+`maint-2.30` branch in https://github.com/gitster/git[the maintainer's
+"broken out" repo].
+
+This also means that `next` or `seen` are inappropriate starting points
+for your work, if you want your work to have a realistic chance of
+graduating to `master`. They are simply not designed to be used as a
+base for new work; they are only there to make sure that topics in
+flight work well together. This is why both `next` and `seen` are
+frequently re-integrated with incoming patches on the mailing list and
+force-pushed to replace previous versions of themselves. A topic that is
+literally built on top of `next` cannot be merged to `master` without
+dragging in all the other topics in `next`, some of which may not be
+ready.
+
+For example, if you are making tree-wide changes, while somebody else is
+also making their own tree-wide changes, your work may have severe
+overlap with the other person's work. This situation may tempt you to
+use `next` as your starting point (because it would have the other
+person's work included in it), but doing so would mean you'll not only
+depend on the other person's work, but all the other random things from
+other contributors that are already integrated into `next`. And as soon
+as `next` is updated with a new version, all of your work will need to
+be rebased anyway in order for them to be cleanly applied by the
+maintainer.
+
+Under truly exceptional circumstances where you absolutely must depend
+on a select few topic branches that are already in `next` but not in
+`master`, you may want to create your own custom base-branch by forking
+`master` and merging the required topic branches into it. You could then
+work on top of this base-branch. But keep in mind that this base-branch
+would only be known privately to you. So when you are ready to send
+your patches to the list, be sure to communicate how you created it in
+your cover letter. This critical piece of information would allow
+others to recreate your base-branch on their end in order for them to
+try out your work.
+
+Finally, note that some parts of the system have dedicated maintainers
+with their own separate source code repositories (see the section
+"Subsystems" below).
+
+[[separate-commits]]
+=== Make separate commits for logically separate changes.
+
+Unless your patch is really trivial, you should not be sending
+out a patch that was generated between your working tree and
+your commit head. Instead, always make a commit with complete
+commit message and generate a series of patches from your
+repository. It is a good discipline.
+
+Give an explanation for the change(s) that is detailed enough so
+that people can judge if it is good thing to do, without reading
+the actual patch text to determine how well the code does what
+the explanation promises to do.
+
+If your description starts to get too long, that's a sign that you
+probably need to split up your commit to finer grained pieces.
+That being said, patches which plainly describe the things that
+help reviewers check the patch, and future maintainers understand
+the code, are the most beautiful patches. Descriptions that summarize
+the point in the subject well, and describe the motivation for the
+change, the approach taken by the change, and if relevant how this
+differs substantially from the prior version, are all good things
+to have.
+
+Make sure that you have tests for the bug you are fixing. See
+`t/README` for guidance.
+
+[[tests]]
+When adding a new feature, make sure that you have new tests to show
+the feature triggers the new behavior when it should, and to show the
+feature does not trigger when it shouldn't. After any code change,
+make sure that the entire test suite passes. When fixing a bug, make
+sure you have new tests that break if somebody else breaks what you
+fixed by accident to avoid regression. Also, try merging your work to
+'next' and 'seen' and make sure the tests still pass; topics by others
+that are still in flight may have unexpected interactions with what
+you are trying to do in your topic.
+
+Pushing to a fork of https://github.com/git/git will use their CI
+integration to test your changes on Linux, Mac and Windows. See the
+<<GHCI,GitHub CI>> section for details.
+
+Do not forget to update the documentation to describe the updated
+behavior and make sure that the resulting documentation set formats
+well (try the Documentation/doc-diff script).
+
+We currently have a liberal mixture of US and UK English norms for
+spelling and grammar, which is somewhat unfortunate. A huge patch that
+touches the files all over the place only to correct the inconsistency
+is not welcome, though. Potential clashes with other changes that can
+result from such a patch are not worth it. We prefer to gradually
+reconcile the inconsistencies in favor of US English, with small and
+easily digestible patches, as a side effect of doing some other real
+work in the vicinity (e.g. rewriting a paragraph for clarity, while
+turning en_UK spelling to en_US). Obvious typographical fixes are much
+more welcomed ("teh -> "the"), preferably submitted as independent
+patches separate from other documentation changes.
+
+[[whitespace-check]]
+Oh, another thing. We are picky about whitespaces. Make sure your
+changes do not trigger errors with the sample pre-commit hook shipped
+in `templates/hooks--pre-commit`. To help ensure this does not happen,
+run `git diff --check` on your changes before you commit.
+
+[[describe-changes]]
+=== Describe your changes well.
+
+The log message that explains your changes is just as important as the
+changes themselves. Your code may be clearly written with in-code
+comment to sufficiently explain how it works with the surrounding
+code, but those who need to fix or enhance your code in the future
+will need to know _why_ your code does what it does, for a few
+reasons:
+
+. Your code may be doing something differently from what you wanted it
+ to do. Writing down what you actually wanted to achieve will help
+ them fix your code and make it do what it should have been doing
+ (also, you often discover your own bugs yourself, while writing the
+ log message to summarize the thought behind it).
+
+. Your code may be doing things that were only necessary for your
+ immediate needs (e.g. "do X to directories" without implementing or
+ even designing what is to be done on files). Writing down why you
+ excluded what the code does not do will help guide future developers.
+ Writing down "we do X to directories, because directories have
+ characteristic Y" would help them infer "oh, files also have the same
+ characteristic Y, so perhaps doing X to them would also make sense?".
+ Saying "we don't do the same X to files, because ..." will help them
+ decide if the reasoning is sound (in which case they do not waste
+ time extending your code to cover files), or reason differently (in
+ which case, they can explain why they extend your code to cover
+ files, too).
+
+The goal of your log message is to convey the _why_ behind your change
+to help future developers. The reviewers will also make sure that
+your proposed log message will serve this purpose well.
+
+The first line of the commit message should be a short description (50
+characters is the soft limit, see DISCUSSION in linkgit: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.
+
+* doc: clarify distinction between sign-off and pgp-signing
+* githooks.txt: improve the intro section
+
+If in doubt which identifier to use, run `git log --no-merges` on the
+files you are modifying to see the current conventions.
+
+[[summary-section]]
+The title sentence after the "area:" prefix omits the full stop at the
+end, and its first word is not capitalized (the omission
+of capitalization applies only to the word after the "area:"
+prefix of the title) unless there is a reason to
+capitalize it other than because it is the first word in the sentence.
+E.g. "doc: clarify...", not "doc: Clarify...", or "githooks.txt:
+improve...", not "githooks.txt: Improve...". But "refs: HEAD is also
+treated as a ref" is correct, as we spell `HEAD` in all caps even when
+it appears in the middle of a sentence.
+
+[[meaningful-message]]
+The body should provide a meaningful commit message, which:
+
+. explains the problem the change tries to solve, i.e. what is wrong
+ with the current code without the change.
+
+. justifies the way the change solves the problem, i.e. why the
+ result with the change is better.
+
+. alternate solutions considered but discarded, if any.
+
+[[present-tense]]
+The problem statement that describes the status quo is written in the
+present tense. Write "The code does X when it is given input Y",
+instead of "The code used to do Y when given input X". You do not
+have to say "Currently"---the status quo in the problem statement is
+about the code _without_ your change, by project convention.
+
+[[imperative-mood]]
+Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
+instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
+to do frotz", as if you are giving orders to the codebase to change
+its behavior. Try to make sure your explanation can be understood
+without external resources. Instead of giving a URL to a mailing list
+archive, summarize the relevant points of the discussion.
+
+[[commit-reference]]
+
+There are a few reasons why you may want to refer to another commit in
+the "more stable" part of the history (i.e. on branches like `maint`,
+`master`, and `next`):
+
+. A commit that introduced the root cause of a bug you are fixing.
+
+. A commit that introduced a feature that you are enhancing.
+
+. A commit that conflicts with your work when you made a trial merge
+ of your work into `next` and `seen` for testing.
+
+When you reference a commit on a more stable branch (like `master`,
+`maint` and `next`), use the format "abbreviated hash (subject,
+date)", like this:
+
+....
+ Commit f86a374 (pack-bitmap.c: fix a memleak, 2015-03-30)
+ noticed that ...
+....
+
+The "Copy commit reference" command of gitk can be used to obtain this
+format (with the subject enclosed in a pair of double-quotes), or this
+invocation of `git show`:
+
+....
+ git show -s --pretty=reference <commit>
+....
+
+or, on an older version of Git without support for --pretty=reference:
+
+....
+ git show -s --date=short --pretty='format:%h (%s, %ad)' <commit>
+....
+
+[[sign-off]]
+=== Certify your work by adding your `Signed-off-by` trailer
+
+To improve tracking of who did what, we ask you to certify that you
+wrote the patch or have the right to pass it on under the same license
+as ours, by "signing off" your patch. Without sign-off, we cannot
+accept your patches.
+
+If (and only if) you certify the below D-C-O:
+
+[[dco]]
+.Developer's Certificate of Origin 1.1
+____
+By making a contribution to this project, I certify that:
+
+a. The contribution was created in whole or in part by me and I
+ have the right to submit it under the open source license
+ indicated in the file; or
+
+b. The contribution is based upon previous work that, to the best
+ of my knowledge, is covered under an appropriate open source
+ license and I have the right under that license to submit that
+ work with modifications, whether created in whole or in part
+ by me, under the same open source license (unless I am
+ permitted to submit under a different license), as indicated
+ in the file; or
+
+c. The contribution was provided directly to me by some other
+ person who certified (a), (b) or (c) and I have not modified
+ it.
+
+d. I understand and agree that this project and the contribution
+ are public and that a record of the contribution (including all
+ personal information I submit with it, including my sign-off) is
+ maintained indefinitely and may be redistributed consistent with
+ this project or the open source license(s) involved.
+____
+
+you add a "Signed-off-by" trailer to your commit, that looks like
+this:
+
+....
+ Signed-off-by: Random J Developer <random@developer.example.org>
+....
+
+This line can be added by Git if you run the git-commit command with
+the -s option.
+
+Notice that you can place your own `Signed-off-by` trailer when
+forwarding somebody else's patch with the above rules for
+D-C-O. Indeed you are encouraged to do so. Do not forget to
+place an in-body "From: " line at the beginning to properly attribute
+the change to its true author (see (2) above).
+
+This procedure originally came from the Linux kernel project, so our
+rule is quite similar to theirs, but what exactly it means to sign-off
+your patch differs from project to project, so it may be different
+from that of the project you are accustomed to.
+
+[[real-name]]
+Also notice that a real name is used in the `Signed-off-by` trailer. Please
+don't hide your real name.
+
+[[commit-trailers]]
+If you like, you can put extra trailers at the end:
+
+. `Reported-by:` is used to credit someone who found the bug that
+ the patch attempts to fix.
+. `Acked-by:` says that the person who is more familiar with the area
+ the patch attempts to modify liked the patch.
+. `Reviewed-by:`, unlike the other trailers, can only be offered by the
+ reviewers themselves when they are completely satisfied with the
+ patch after a detailed analysis.
+. `Tested-by:` is used to indicate that the person applied the patch
+ and found it to have the desired effect.
+. `Co-authored-by:` is used to indicate that people exchanged drafts
+ of a patch before submitting it.
+. `Helped-by:` is used to credit someone who suggested ideas for
+ changes without providing the precise changes in patch form.
+. `Mentored-by:` is used to credit someone with helping develop a
+ patch as part of a mentorship program (e.g., GSoC or Outreachy).
+. `Suggested-by:` is used to credit someone with suggesting the idea
+ for a patch.
+
+While you can also create your own trailer if the situation warrants it, we
+encourage you to instead use one of the common trailers in this project
+highlighted above.
+
+Only capitalize the very first letter of the trailer, i.e. favor
+"Signed-off-by" over "Signed-Off-By" and "Acked-by:" over "Acked-By".
+
+[[git-tools]]
+=== Generate your patch using Git tools out of your commits.
+
+Git based diff tools generate unidiff which is the preferred format.
+
+You do not have to be afraid to use `-M` option to `git diff` or
+`git format-patch`, if your patch involves file renames. The
+receiving end can handle them just fine.
+
+[[review-patch]]
+Please make sure your patch does not add commented out debugging code,
+or include any extra files which do not relate to what your patch
+is trying to achieve. Make sure to review
+your patch after generating it, to ensure accuracy. Before
+sending out, please make sure it cleanly applies to the starting point you
+have chosen in the "Choose a starting point" section.
+
+NOTE: From the perspective of those reviewing your patch, the `master`
+branch is the default expected starting point. So if you have chosen a
+different starting point, please communicate this choice in your cover
+letter.
+
+
+[[send-patches]]
+=== Sending your patches.
+
+==== Choosing your reviewers
+
+:security-ml: footnoteref:[security-ml,The Git Security mailing list: git-security@googlegroups.com]
+
+NOTE: Patches that may be
+security relevant should be submitted privately to the Git Security
+mailing list{security-ml}, instead of the public mailing list.
+
+:contrib-scripts: footnoteref:[contrib-scripts,Scripts under `contrib/` are +
+not part of the core `git` binary and must be called directly. Clone the Git +
+codebase and run `perl contrib/contacts/git-contacts`.]
+
+Send your patch with "To:" set to the mailing list, with "cc:" listing
+people who are involved in the area you are touching (the `git-contacts`
+script in `contrib/contacts/`{contrib-scripts} can help to
+identify them), to solicit comments and reviews. Also, when you made
+trial merges of your topic to `next` and `seen`, you may have noticed
+work by others conflicting with your changes. There is a good possibility
+that these people may know the area you are touching well.
+
+If you are using `send-email`, you can feed it the output of `git-contacts` like
+this:
+
+....
+ git send-email --cc-cmd='perl contrib/contacts/git-contacts' feature/*.patch
+....
+
+:current-maintainer: footnote:[The current maintainer: gitster@pobox.com]
+:git-ml: footnote:[The mailing list: git@vger.kernel.org]
+
+After the list reached a consensus that it is a good idea to apply the
+patch, re-send it with "To:" set to the maintainer{current-maintainer}
+and "cc:" the list{git-ml} for inclusion. This is especially relevant
+when the maintainer did not heavily participate in the discussion and
+instead left the review to trusted others.
+
+Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and
+`Tested-by:` lines as necessary to credit people who helped your
+patch, and "cc:" them when sending such a final version for inclusion.
+
+==== `format-patch` and `send-email`
+
+Learn to use `format-patch` and `send-email` if possible. These commands
+are optimized for the workflow of sending patches, avoiding many ways
+your existing e-mail client (often optimized for "multipart/*" MIME
+type e-mails) might render your patches unusable.
+
+NOTE: Here we outline the procedure using `format-patch` and
+`send-email`, but you can instead use GitGitGadget to send in your
+patches (see link:MyFirstContribution.html[MyFirstContribution]).
+
+People on the Git mailing list need to be able to read and
+comment on the changes you are submitting. It is important for
+a developer to be able to "quote" your changes, using standard
+e-mail tools, so that they may comment on specific portions of
+your code. For this reason, each patch should be submitted
+"inline" in a separate message.
+
+All subsequent versions of a patch series and other related patches should be
+grouped into their own e-mail thread to help readers find all parts of the
+series. To that end, send them as replies to either an additional "cover
+letter" message (see below), the first patch, or the respective preceding patch.
+Here is a link:MyFirstContribution.html#v2-git-send-email[step-by-step guide] on
+how to submit updated versions of a patch series.
+
+If your log message (including your name on the
+`Signed-off-by` trailer) is not writable in ASCII, make sure that
+you send off a message in the correct encoding.
+
+WARNING: Be wary of your MUAs word-wrap
+corrupting your patch. Do not cut-n-paste your patch; you can
+lose tabs that way if you are not careful.
+
+It is a common convention to prefix your subject line with
+[PATCH]. This lets people easily distinguish patches from other
+e-mail discussions. Use of markers in addition to PATCH within
+the brackets to describe the nature of the patch is also
+encouraged. E.g. [RFC PATCH] (where RFC stands for "request for
+comments") is often used to indicate a patch needs further
+discussion before being accepted, [PATCH v2], [PATCH v3] etc.
+are often seen when you are sending an update to what you have
+previously sent.
+
+The `git format-patch` command follows the best current practice to
+format the body of an e-mail message. At the beginning of the
+patch should come your commit message, ending with the
+`Signed-off-by` trailers, and a line that consists of three dashes,
+followed by the diffstat information and the patch itself. If
+you are forwarding a patch from somebody else, optionally, at
+the beginning of the e-mail message just before the commit
+message starts, you can put a "From: " line to name that person.
+To change the default "[PATCH]" in the subject to "[<text>]", use
+`git format-patch --subject-prefix=<text>`. As a shortcut, you
+can use `--rfc` instead of `--subject-prefix="RFC PATCH"`, or
+`-v <n>` instead of `--subject-prefix="PATCH v<n>"`.
+
+You often want to add additional explanation about the patch,
+other than the commit message itself. Place such "cover letter"
+material between the three-dash line and the diffstat. For
+patches requiring multiple iterations of review and discussion,
+an explanation of changes between each iteration can be kept in
+Git-notes and inserted automatically following the three-dash
+line via `git format-patch --notes`.
+
+[[the-topic-summary]]
+*This is EXPERIMENTAL*.
+
+When sending a topic, you can propose a one-paragraph summary that
+should appear in the "What's cooking" report when it is picked up to
+explain the topic. If you choose to do so, please write a 2-5 line
+paragraph that will fit well in our release notes (see many bulleted
+entries in the Documentation/RelNotes/* files for examples), and make
+it the first paragraph of the cover letter. For a single-patch
+series, use the space between the three-dash line and the diffstat, as
+described earlier.
+
+[[attachment]]
+Do not attach the patch as a MIME attachment, compressed or not.
+Do not let your e-mail client send quoted-printable. Do not let
+your e-mail client send format=flowed which would destroy
+whitespaces in your patches. Many
+popular e-mail applications will not always transmit a MIME
+attachment as plain text, making it impossible to comment on
+your code. A MIME attachment also takes a bit more time to
+process. This does not decrease the likelihood of your
+MIME-attached change being accepted, but it makes it more likely
+that it will be postponed.
+
+Exception: If your mailer is mangling patches then someone may ask
+you to re-send them using MIME, that is OK.
+
+[[pgp-signature]]
+Do not PGP sign your patch. Most likely, your maintainer or other people on the
+list would not have your PGP key and would not bother obtaining it anyway.
+Your patch is not judged by who you are; a good patch from an unknown origin
+has a far better chance of being accepted than a patch from a known, respected
+origin that is done poorly or does incorrect things.
+
+If you really really really really want to do a PGP signed
+patch, format it as "multipart/signed", not a text/plain message
+that starts with `-----BEGIN PGP SIGNED MESSAGE-----`. That is
+not a text/plain, it's something else.
+
+=== Handling Conflicts and Iterating Patches
+
+When revising changes made to your patches, it's important to
+acknowledge the possibility of conflicts with other ongoing topics. To
+navigate these potential conflicts effectively, follow the recommended
+steps outlined below:
+
+. Build on a suitable base branch, see the <<choose-starting-point, section above>>,
+and format-patch the series. If you are doing "rebase -i" in-place to
+update from the previous round, this will reuse the previous base so
+(2) and (3) may become trivial.
+
+. Find the base of where the last round was queued
++
+ $ mine='kn/ref-transaction-symref'
+ $ git checkout "origin/seen^{/^Merge branch '$mine'}...master"
+
+. Apply your format-patch result. There are two cases
+.. Things apply cleanly and tests fine. Go to (4).
+.. Things apply cleanly but does not build or test fails, or things do
+not apply cleanly.
++
+In the latter case, you have textual or semantic conflicts coming from
+the difference between the old base and the base you used to build in
+(1). Identify what caused the breakages (e.g., a topic or two may have
+merged since the base used by (2) until the base used by (1)).
++
+Check out the latest 'origin/master' (which may be newer than the base
+used by (2)), "merge --no-ff" the topics you newly depend on in there,
+and use the result of the merge(s) as the base, rebuild the series and
+test again. Run format-patch from the last such merges to the tip of
+your topic. If you did
++
+ $ git checkout origin/master
+ $ git merge --no-ff --into-name kn/ref-transaction-symref fo/obar
+ $ git merge --no-ff --into-name kn/ref-transaction-symref ba/zqux
+ ... rebuild the topic ...
++
+Then you'd just format your topic above these "preparing the ground"
+merges, e.g.
++
+ $ git format-patch "HEAD^{/^Merge branch 'ba/zqux'}"..HEAD
++
+Do not forget to write in the cover letter you did this, including the
+topics you have in your base on top of 'master'. Then go to (4).
+
+. Make a trial merge of your topic into 'next' and 'seen', e.g.
++
+ $ git checkout --detach 'origin/seen'
+ $ git revert -m 1 <the merge of the previous iteration into seen>
+ $ git merge kn/ref-transaction-symref
++
+The "revert" is needed if the previous iteration of your topic is
+already in 'seen' (like in this case). You could choose to rebuild
+master..origin/seen from scratch while excluding your previous
+iteration, which may emulate what happens on the maintainers end more
+closely.
++
+This trial merge may conflict. It is primarily to see what conflicts
+_other_ topics may have with your topic. In other words, you do not
+have to depend on it to make your topic work on 'master'. It may
+become the job of the other topic owners to resolve conflicts if your
+topic goes to 'next' before theirs.
++
+Make a note on what conflict you saw in the cover letter. You do not
+necessarily have to resolve them, but it would be a good opportunity to
+learn what others are doing in related areas.
++
+ $ git checkout --detach 'origin/next'
+ $ git merge kn/ref-transaction-symref
++
+This is to see what conflicts your topic has with other topics that are
+already cooking. This should not conflict if (3)-2 prepared a base on
+top of updated master plus dependent topics taken from 'next'. Unless
+the context is severe (one way to tell is try the same trial merge with
+your old iteration, which may conflict in a similar way), expect that it
+will be handled on maintainers end (if it gets unmanageable, I'll ask to
+rebase when I receive your patches).
+
+== Subsystems with dedicated maintainers
+
+Some parts of the system have dedicated maintainers with their own
+repositories.
+
+- `git-gui/` comes from the git-gui project, maintained by Johannes Sixt:
+
+ https://github.com/j6t/git-gui
+
+ Contibutions should go via the git mailing list.
+
+- `gitk-git/` comes from the gitk project, maintained by Johannes Sixt:
+
+ https://github.com/j6t/gitk
+
+ Contibutions should go via the git mailing list.
+
+- `po/` comes from the localization coordinator, Jiang Xin:
+
+ https://github.com/git-l10n/git-po/
+
+Patches to these parts should be based on their trees.
+
+- The "Git documentation translations" project, led by Jean-Noël
+ Avila, translates our documentation pages. Their work products are
+ maintained separately from this project, not as part of our tree:
+
+ https://github.com/jnavila/git-manpages-l10n/
+
+
+== GitHub CI[[GHCI]]
+
+With an account at GitHub, you can use GitHub CI to test your changes
+on Linux, Mac and Windows. See
+https://github.com/git/git/actions/workflows/main.yml for examples of
+recent CI runs.
+
+Follow these steps for the initial setup:
+
+. Fork https://github.com/git/git to your GitHub account.
+ You can find detailed instructions how to fork here:
+ https://help.github.com/articles/fork-a-repo/
+
+After the initial setup, CI will run whenever you push new changes
+to your fork of Git on GitHub. You can monitor the test state of all your
+branches here: `https://github.com/<Your GitHub handle>/git/actions/workflows/main.yml`
+
+If a branch does not pass all test cases then it will be marked with a
+red +x+, instead of a green check. In that case, you can click on the
+failing job and navigate to "ci/run-build-and-tests.sh" and/or
+"ci/print-test-failures.sh". You can also download "Artifacts" which
+are zip archives containing tarred (or zipped) archives with test data
+relevant for debugging.
+
+Then fix the problem and push your fix to your GitHub fork. This will
+trigger a new CI build to ensure all tests pass.
+
+[[mua]]
+== MUA specific hints
+
+Some of the patches I receive or pick up from the list share common
+patterns of breakage. Please make sure your MUA is set up
+properly not to corrupt whitespaces.
+
+See the DISCUSSION section of linkgit:git-format-patch[1] for hints on
+checking your patch by mailing it to yourself and applying with
+linkgit:git-am[1].
+
+While you are at it, check the resulting commit log message from
+a trial run of applying the patch. If what is in the resulting
+commit is not exactly what you would want to see, it is very
+likely that your maintainer would end up hand editing the log
+message when he applies your patch. Things like "Hi, this is my
+first patch.\n", if you really want to put in the patch e-mail,
+should come after the three-dash line that signals the end of the
+commit message.
+
+
+=== Pine
+
+(Johannes Schindelin)
+
+....
+I don't know how many people still use pine, but for those poor
+souls it may be good to mention that the quell-flowed-text is
+needed for recent versions.
+
+... the "no-strip-whitespace-before-send" option, too. AFAIK it
+was introduced in 4.60.
+....
+
+(Linus Torvalds)
+
+....
+And 4.58 needs at least this.
+
+diff-tree 8326dd8350be64ac7fc805f6563a1d61ad10d32c (from e886a61f76edf5410573e92e38ce22974f9c40f1)
+Author: Linus Torvalds <torvalds@g5.osdl.org>
+Date: Mon Aug 15 17:23:51 2005 -0700
+
+ Fix pine whitespace-corruption bug
+
+ There's no excuse for unconditionally removing whitespace from
+ the pico buffers on close.
+
+diff --git a/pico/pico.c b/pico/pico.c
+--- a/pico/pico.c
++++ b/pico/pico.c
+@@ -219,7 +219,9 @@ PICO *pm;
+ switch(pico_all_done){ /* prepare for/handle final events */
+ case COMP_EXIT : /* already confirmed */
+ packheader();
++#if 0
+ stripwhitespace();
++#endif
+ c |= COMP_EXIT;
+ break;
+....
+
+(Daniel Barkalow)
+
+....
+> A patch to SubmittingPatches, MUA specific help section for
+> users of Pine 4.63 would be very much appreciated.
+
+Ah, it looks like a recent version changed the default behavior to do the
+right thing, and inverted the sense of the configuration option. (Either
+that or Gentoo did it.) So you need to set the
+"no-strip-whitespace-before-send" option, unless the option you have is
+"strip-whitespace-before-send", in which case you should avoid checking
+it.
+....
+
+=== Thunderbird, KMail, GMail
+
+See the MUA-SPECIFIC HINTS section of linkgit:git-format-patch[1].
+
+=== Gnus
+
+"|" in the `*Summary*` buffer can be used to pipe the current
+message to an external program, and this is a handy way to drive
+`git am`. However, if the message is MIME encoded, what is
+piped into the program is the representation you see in your
+`*Article*` buffer after unwrapping MIME. This is often not what
+you would want for two reasons. It tends to screw up non-ASCII
+characters (most notably in people's names), and also
+whitespaces (fatal in patches). Running "C-u g" to display the
+message in raw form before using "|" to run the pipe can work
+this problem around.
diff --git a/ToolsForGit.adoc b/ToolsForGit.adoc
new file mode 100644
index 0000000..ae7690b
--- /dev/null
+++ b/ToolsForGit.adoc
@@ -0,0 +1,51 @@
+Tools for developing Git
+========================
+:sectanchors:
+
+[[summary]]
+== Summary
+
+This document gathers tips, scripts, and configuration files to help people
+working on Git's codebase use their favorite tools while following Git's
+coding style.
+
+[[author]]
+=== Author
+
+The Git community.
+
+[[table_of_contents]]
+== Table of contents
+
+- <<vscode>>
+- <<emacs>>
+
+[[vscode]]
+=== Visual Studio Code (VS Code)
+
+The contrib/vscode/init.sh script creates configuration files that enable
+several valuable VS Code features. See contrib/vscode/README.md for more
+information on using the script.
+
+[[emacs]]
+=== Emacs
+
+This is adapted from Linux's suggestion in its CodingStyle document:
+
+- To follow the rules in CodingGuidelines, it's useful to put the following in
+GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+----
+;; note the first part is useful for C editing, too
+((nil . ((indent-tabs-mode . t)
+ (tab-width . 8)
+ (fill-column . 80)))
+ (cperl-mode . ((cperl-indent-level . 8)
+ (cperl-extra-newline-before-brace . nil)
+ (cperl-merge-trailing-else . t))))
+----
+
+For a more complete setup, since Git's codebase uses a coding style
+similar to the Linux kernel's style, tips given in Linux's CodingStyle
+document can be applied here too.
+
+==== https://www.kernel.org/doc/html/v4.10/process/coding-style.html#you-ve-made-a-mess-of-it
diff --git a/blame-options.adoc b/blame-options.adoc
new file mode 100644
index 0000000..aa77406
--- /dev/null
+++ b/blame-options.adoc
@@ -0,0 +1,149 @@
+-b::
+ Show blank SHA-1 for boundary commits. This can also
+ be controlled via the `blame.blankBoundary` config option.
+
+--root::
+ Do not treat root commits as boundaries. This can also be
+ controlled via the `blame.showRoot` config option.
+
+--show-stats::
+ Include additional statistics at the end of blame output.
+
+-L <start>,<end>::
+-L :<funcname>::
+ Annotate only the line range given by '<start>,<end>',
+ or by the function name regex '<funcname>'.
+ May be specified multiple times. Overlapping ranges are allowed.
++
+'<start>' and '<end>' are optional. `-L <start>` or `-L <start>,` spans from
+'<start>' to end of file. `-L ,<end>` spans from start of file to '<end>'.
++
+include::line-range-format.adoc[]
+
+-l::
+ Show long rev (Default: off).
+
+-t::
+ Show raw timestamp (Default: off).
+
+-S <revs-file>::
+ Use revisions from revs-file instead of calling linkgit:git-rev-list[1].
+
+--reverse <rev>..<rev>::
+ Walk history forward instead of backward. Instead of showing
+ the revision in which a line appeared, this shows the last
+ revision in which a line has existed. This requires a range of
+ revision like START..END where the path to blame exists in
+ START. `git blame --reverse START` is taken as `git blame
+ --reverse START..HEAD` for convenience.
+
+--first-parent::
+ Follow only the first parent commit upon seeing a merge
+ commit. This option can be used to determine when a line
+ was introduced to a particular integration branch, rather
+ than when it was introduced to the history overall.
+
+-p::
+--porcelain::
+ Show in a format designed for machine consumption.
+
+--line-porcelain::
+ Show the porcelain format, but output commit information for
+ each line, not just the first time a commit is referenced.
+ Implies --porcelain.
+
+--incremental::
+ Show the result incrementally in a format designed for
+ machine consumption.
+
+--encoding=<encoding>::
+ Specifies the encoding used to output author names
+ and commit summaries. Setting it to `none` makes blame
+ output unconverted data. For more information see the
+ discussion about encoding in the linkgit:git-log[1]
+ manual page.
+
+--contents <file>::
+ Annotate using the contents from the named file, starting from <rev>
+ if it is specified, and HEAD otherwise. You may specify '-' to make
+ the command read from the standard input for the file contents.
+
+--date <format>::
+ Specifies the format used to output dates. If --date is not
+ provided, the value of the blame.date config variable is
+ used. If the blame.date config variable is also not set, the
+ iso format is used. For supported values, see the discussion
+ of the --date option at linkgit:git-log[1].
+
+--[no-]progress::
+ Progress status is reported on the standard error stream
+ by default when it is attached to a terminal. This flag
+ enables progress reporting even if not attached to a
+ terminal. Can't use `--progress` together with `--porcelain`
+ or `--incremental`.
+
+-M[<num>]::
+ Detect moved or copied lines within a file. When a commit
+ moves or copies a block of lines (e.g. the original file
+ has A and then B, and the commit changes it to B and then
+ A), the traditional 'blame' algorithm notices only half of
+ the movement and typically blames the lines that were moved
+ up (i.e. B) to the parent and assigns blame to the lines that
+ were moved down (i.e. A) to the child commit. With this
+ option, both groups of lines are blamed on the parent by
+ running extra passes of inspection.
++
+<num> is optional but it is the lower bound on the number of
+alphanumeric characters that Git must detect as moving/copying
+within a file for it to associate those lines with the parent
+commit. The default value is 20.
+
+-C[<num>]::
+ In addition to `-M`, detect lines moved or copied from other
+ files that were modified in the same commit. This is
+ useful when you reorganize your program and move code
+ around across files. When this option is given twice,
+ the command additionally looks for copies from other
+ files in the commit that creates the file. When this
+ option is given three times, the command additionally
+ looks for copies from other files in any commit.
++
+<num> is optional but it is the lower bound on the number of
+alphanumeric characters that Git must detect as moving/copying
+between files for it to associate those lines with the parent
+commit. And the default value is 40. If there are more than one
+`-C` options given, the <num> argument of the last `-C` will
+take effect.
+
+--ignore-rev <rev>::
+ Ignore changes made by the revision when assigning blame, as if the
+ change never happened. Lines that were changed or added by an ignored
+ commit will be blamed on the previous commit that changed that line or
+ nearby lines. This option may be specified multiple times to ignore
+ more than one revision. If the `blame.markIgnoredLines` config option
+ is set, then lines that were changed by an ignored commit and attributed to
+ another commit will be marked with a `?` in the blame output. If the
+ `blame.markUnblamableLines` config option is set, then those lines touched
+ by an ignored commit that we could not attribute to another revision are
+ marked with a '*'.
+
+--ignore-revs-file <file>::
+ Ignore revisions listed in `file`, which must be in the same format as an
+ `fsck.skipList`. This option may be repeated, and these files will be
+ processed after any files specified with the `blame.ignoreRevsFile` config
+ option. An empty file name, `""`, will clear the list of revs from
+ previously processed files.
+
+--color-lines::
+ Color line annotations in the default format differently if they come from
+ the same commit as the preceding line. This makes it easier to distinguish
+ code blocks introduced by different commits. The color defaults to cyan and
+ can be adjusted using the `color.blame.repeatedLines` config option.
+
+--color-by-age::
+ Color line annotations depending on the age of the line in the default format.
+ The `color.blame.highlightRecent` config option controls what color is used for
+ each range of age.
+
+-h::
+ Show help message.
diff --git a/cmds-ancillaryinterrogators.adoc b/cmds-ancillaryinterrogators.adoc
new file mode 100644
index 0000000..f13a361
--- /dev/null
+++ b/cmds-ancillaryinterrogators.adoc
@@ -0,0 +1,51 @@
+linkgit:git-annotate[1]::
+ Annotate file lines with commit information.
+
+linkgit:git-blame[1]::
+ Show what revision and author last modified each line of a file.
+
+linkgit:git-bugreport[1]::
+ Collect information for user to file a bug report.
+
+linkgit:git-count-objects[1]::
+ Count unpacked number of objects and their disk consumption.
+
+linkgit:git-diagnose[1]::
+ Generate a zip archive of diagnostic information.
+
+linkgit:git-difftool[1]::
+ Show changes using common diff tools.
+
+linkgit:git-fsck[1]::
+ Verifies the connectivity and validity of the objects in the database.
+
+linkgit:git-help[1]::
+ Display help information about Git.
+
+linkgit:git-instaweb[1]::
+ Instantly browse your working repository in gitweb.
+
+linkgit:git-merge-tree[1]::
+ Perform merge without touching index or working tree.
+
+linkgit:git-rerere[1]::
+ Reuse recorded resolution of conflicted merges.
+
+linkgit:git-show-branch[1]::
+ Show branches and their commits.
+
+linkgit:git-verify-commit[1]::
+ Check the GPG signature of commits.
+
+linkgit:git-verify-tag[1]::
+ Check the GPG signature of tags.
+
+linkgit:git-version[1]::
+ Display version information about Git.
+
+linkgit:git-whatchanged[1]::
+ Show logs with differences each commit introduces.
+
+linkgit:gitweb[1]::
+ Git web interface (web frontend to Git repositories).
+
diff --git a/cmds-ancillarymanipulators.adoc b/cmds-ancillarymanipulators.adoc
new file mode 100644
index 0000000..6fa09e2
--- /dev/null
+++ b/cmds-ancillarymanipulators.adoc
@@ -0,0 +1,36 @@
+linkgit:git-config[1]::
+ Get and set repository or global options.
+
+linkgit:git-fast-export[1]::
+ Git data exporter.
+
+linkgit:git-fast-import[1]::
+ Backend for fast Git data importers.
+
+linkgit:git-filter-branch[1]::
+ Rewrite branches.
+
+linkgit:git-mergetool[1]::
+ Run merge conflict resolution tools to resolve merge conflicts.
+
+linkgit:git-pack-refs[1]::
+ Pack heads and tags for efficient repository access.
+
+linkgit:git-prune[1]::
+ Prune all unreachable objects from the object database.
+
+linkgit:git-reflog[1]::
+ Manage reflog information.
+
+linkgit:git-refs[1]::
+ Low-level access to refs.
+
+linkgit:git-remote[1]::
+ Manage set of tracked repositories.
+
+linkgit:git-repack[1]::
+ Pack unpacked objects in a repository.
+
+linkgit:git-replace[1]::
+ Create, list, delete refs to replace objects.
+
diff --git a/cmds-developerinterfaces.adoc b/cmds-developerinterfaces.adoc
new file mode 100644
index 0000000..810ebe5
--- /dev/null
+++ b/cmds-developerinterfaces.adoc
@@ -0,0 +1,33 @@
+linkgit:gitformat-bundle[5]::
+ The bundle file format.
+
+linkgit:gitformat-chunk[5]::
+ Chunk-based file formats.
+
+linkgit:gitformat-commit-graph[5]::
+ Git commit-graph format.
+
+linkgit:gitformat-index[5]::
+ Git index format.
+
+linkgit:gitformat-pack[5]::
+ Git pack format.
+
+linkgit:gitformat-signature[5]::
+ Git cryptographic signature formats.
+
+linkgit:gitprotocol-capabilities[5]::
+ Protocol v0 and v1 capabilities.
+
+linkgit:gitprotocol-common[5]::
+ Things common to various protocols.
+
+linkgit:gitprotocol-http[5]::
+ Git HTTP-based protocols.
+
+linkgit:gitprotocol-pack[5]::
+ How packs are transferred over-the-wire.
+
+linkgit:gitprotocol-v2[5]::
+ Git Wire Protocol, Version 2.
+
diff --git a/cmds-foreignscminterface.adoc b/cmds-foreignscminterface.adoc
new file mode 100644
index 0000000..29236a0
--- /dev/null
+++ b/cmds-foreignscminterface.adoc
@@ -0,0 +1,30 @@
+linkgit:git-archimport[1]::
+ Import a GNU Arch repository into Git.
+
+linkgit:git-cvsexportcommit[1]::
+ Export a single commit to a CVS checkout.
+
+linkgit:git-cvsimport[1]::
+ Salvage your data out of another SCM people love to hate.
+
+linkgit:git-cvsserver[1]::
+ A CVS server emulator for Git.
+
+linkgit:git-imap-send[1]::
+ Send a collection of patches from stdin to an IMAP folder.
+
+linkgit:git-p4[1]::
+ Import from and submit to Perforce repositories.
+
+linkgit:git-quiltimport[1]::
+ Applies a quilt patchset onto the current branch.
+
+linkgit:git-request-pull[1]::
+ Generates a summary of pending changes.
+
+linkgit:git-send-email[1]::
+ Send a collection of patches as emails.
+
+linkgit:git-svn[1]::
+ Bidirectional operation between a Subversion repository and Git.
+
diff --git a/cmds-guide.adoc b/cmds-guide.adoc
new file mode 100644
index 0000000..3c0eeb3
--- /dev/null
+++ b/cmds-guide.adoc
@@ -0,0 +1,39 @@
+linkgit:gitcore-tutorial[7]::
+ A Git core tutorial for developers.
+
+linkgit:gitcredentials[7]::
+ Providing usernames and passwords to Git.
+
+linkgit:gitcvs-migration[7]::
+ Git for CVS users.
+
+linkgit:gitdiffcore[7]::
+ Tweaking diff output.
+
+linkgit:giteveryday[7]::
+ A useful minimum set of commands for Everyday Git.
+
+linkgit:gitfaq[7]::
+ Frequently asked questions about using Git.
+
+linkgit:gitglossary[7]::
+ A Git Glossary.
+
+linkgit:gitnamespaces[7]::
+ Git namespaces.
+
+linkgit:gitremote-helpers[7]::
+ Helper programs to interact with remote repositories.
+
+linkgit:gitsubmodules[7]::
+ Mounting one repository inside another.
+
+linkgit:gittutorial[7]::
+ A tutorial introduction to Git.
+
+linkgit:gittutorial-2[7]::
+ A tutorial introduction to Git: part two.
+
+linkgit:gitworkflows[7]::
+ An overview of recommended workflows with Git.
+
diff --git a/cmds-mainporcelain.adoc b/cmds-mainporcelain.adoc
new file mode 100644
index 0000000..a3714d7
--- /dev/null
+++ b/cmds-mainporcelain.adoc
@@ -0,0 +1,132 @@
+linkgit:git-add[1]::
+ Add file contents to the index.
+
+linkgit:git-am[1]::
+ Apply a series of patches from a mailbox.
+
+linkgit:git-archive[1]::
+ Create an archive of files from a named tree.
+
+linkgit:git-bisect[1]::
+ Use binary search to find the commit that introduced a bug.
+
+linkgit:git-branch[1]::
+ List, create, or delete branches.
+
+linkgit:git-bundle[1]::
+ Move objects and refs by archive.
+
+linkgit:git-checkout[1]::
+ Switch branches or restore working tree files.
+
+linkgit:git-cherry-pick[1]::
+ Apply the changes introduced by some existing commits.
+
+linkgit:git-citool[1]::
+ Graphical alternative to git-commit.
+
+linkgit:git-clean[1]::
+ Remove untracked files from the working tree.
+
+linkgit:git-clone[1]::
+ Clone a repository into a new directory.
+
+linkgit:git-commit[1]::
+ Record changes to the repository.
+
+linkgit:git-describe[1]::
+ Give an object a human readable name based on an available ref.
+
+linkgit:git-diff[1]::
+ Show changes between commits, commit and working tree, etc.
+
+linkgit:git-fetch[1]::
+ Download objects and refs from another repository.
+
+linkgit:git-format-patch[1]::
+ Prepare patches for e-mail submission.
+
+linkgit:git-gc[1]::
+ Cleanup unnecessary files and optimize the local repository.
+
+linkgit:git-grep[1]::
+ Print lines matching a pattern.
+
+linkgit:git-gui[1]::
+ A portable graphical interface to Git.
+
+linkgit:git-init[1]::
+ Create an empty Git repository or reinitialize an existing one.
+
+linkgit:git-log[1]::
+ Show commit logs.
+
+linkgit:git-maintenance[1]::
+ Run tasks to optimize Git repository data.
+
+linkgit:git-merge[1]::
+ Join two or more development histories together.
+
+linkgit:git-mv[1]::
+ Move or rename a file, a directory, or a symlink.
+
+linkgit:git-notes[1]::
+ Add or inspect object notes.
+
+linkgit:git-pull[1]::
+ Fetch from and integrate with another repository or a local branch.
+
+linkgit:git-push[1]::
+ Update remote refs along with associated objects.
+
+linkgit:git-range-diff[1]::
+ Compare two commit ranges (e.g. two versions of a branch).
+
+linkgit:git-rebase[1]::
+ Reapply commits on top of another base tip.
+
+linkgit:git-reset[1]::
+ Reset current HEAD to the specified state.
+
+linkgit:git-restore[1]::
+ Restore working tree files.
+
+linkgit:git-revert[1]::
+ Revert some existing commits.
+
+linkgit:git-rm[1]::
+ Remove files from the working tree and from the index.
+
+linkgit:git-shortlog[1]::
+ Summarize 'git log' output.
+
+linkgit:git-show[1]::
+ Show various types of objects.
+
+linkgit:git-sparse-checkout[1]::
+ Reduce your working tree to a subset of tracked files.
+
+linkgit:git-stash[1]::
+ Stash the changes in a dirty working directory away.
+
+linkgit:git-status[1]::
+ Show the working tree status.
+
+linkgit:git-submodule[1]::
+ Initialize, update or inspect submodules.
+
+linkgit:git-switch[1]::
+ Switch branches.
+
+linkgit:git-tag[1]::
+ Create, list, delete or verify a tag object signed with GPG.
+
+linkgit:git-worktree[1]::
+ Manage multiple working trees.
+
+linkgit:gitk[1]::
+ The Git repository browser.
+
+linkgit:scalar[1]::
+ A tool for managing large Git repositories.
+
diff --git a/cmds-plumbinginterrogators.adoc b/cmds-plumbinginterrogators.adoc
new file mode 100644
index 0000000..4fe8eae
--- /dev/null
+++ b/cmds-plumbinginterrogators.adoc
@@ -0,0 +1,63 @@
+linkgit:git-cat-file[1]::
+ Provide contents or details of repository objects.
+
+linkgit:git-cherry[1]::
+ Find commits yet to be applied to upstream.
+
+linkgit:git-diff-files[1]::
+ Compares files in the working tree and the index.
+
+linkgit:git-diff-index[1]::
+ Compare a tree to the working tree or index.
+
+linkgit:git-diff-tree[1]::
+ Compares the content and mode of blobs found via two tree objects.
+
+linkgit:git-for-each-ref[1]::
+ Output information on each ref.
+
+linkgit:git-for-each-repo[1]::
+ Run a Git command on a list of repositories.
+
+linkgit:git-get-tar-commit-id[1]::
+ Extract commit ID from an archive created using git-archive.
+
+linkgit:git-ls-files[1]::
+ Show information about files in the index and the working tree.
+
+linkgit:git-ls-remote[1]::
+ List references in a remote repository.
+
+linkgit:git-ls-tree[1]::
+ List the contents of a tree object.
+
+linkgit:git-merge-base[1]::
+ Find as good common ancestors as possible for a merge.
+
+linkgit:git-name-rev[1]::
+ Find symbolic names for given revs.
+
+linkgit:git-pack-redundant[1]::
+ Find redundant pack files.
+
+linkgit:git-rev-list[1]::
+ Lists commit objects in reverse chronological order.
+
+linkgit:git-rev-parse[1]::
+ Pick out and massage parameters.
+
+linkgit:git-show-index[1]::
+ Show packed archive index.
+
+linkgit:git-show-ref[1]::
+ List references in a local repository.
+
+linkgit:git-unpack-file[1]::
+ Creates a temporary file with a blob's contents.
+
+linkgit:git-var[1]::
+ Show a Git logical variable.
+
+linkgit:git-verify-pack[1]::
+ Validate packed Git archive files.
+
diff --git a/cmds-plumbingmanipulators.adoc b/cmds-plumbingmanipulators.adoc
new file mode 100644
index 0000000..6ea8c60
--- /dev/null
+++ b/cmds-plumbingmanipulators.adoc
@@ -0,0 +1,60 @@
+linkgit:git-apply[1]::
+ Apply a patch to files and/or to the index.
+
+linkgit:git-checkout-index[1]::
+ Copy files from the index to the working tree.
+
+linkgit:git-commit-graph[1]::
+ Write and verify Git commit-graph files.
+
+linkgit:git-commit-tree[1]::
+ Create a new commit object.
+
+linkgit:git-hash-object[1]::
+ Compute object ID and optionally create an object from a file.
+
+linkgit:git-index-pack[1]::
+ Build pack index file for an existing packed archive.
+
+linkgit:git-merge-file[1]::
+ Run a three-way file merge.
+
+linkgit:git-merge-index[1]::
+ Run a merge for files needing merging.
+
+linkgit:git-mktag[1]::
+ Creates a tag object with extra validation.
+
+linkgit:git-mktree[1]::
+ Build a tree-object from ls-tree formatted text.
+
+linkgit:git-multi-pack-index[1]::
+ Write and verify multi-pack-indexes.
+
+linkgit:git-pack-objects[1]::
+ Create a packed archive of objects.
+
+linkgit:git-prune-packed[1]::
+ Remove extra objects that are already in pack files.
+
+linkgit:git-read-tree[1]::
+ Reads tree information into the index.
+
+linkgit:git-replay[1]::
+ EXPERIMENTAL: Replay commits on a new base, works with bare repos too.
+
+linkgit:git-symbolic-ref[1]::
+ Read, modify and delete symbolic refs.
+
+linkgit:git-unpack-objects[1]::
+ Unpack objects from a packed archive.
+
+linkgit:git-update-index[1]::
+ Register file contents in the working tree to the index.
+
+linkgit:git-update-ref[1]::
+ Update the object name stored in a ref safely.
+
+linkgit:git-write-tree[1]::
+ Create a tree object from the current index.
+
diff --git a/cmds-purehelpers.adoc b/cmds-purehelpers.adoc
new file mode 100644
index 0000000..2592988
--- /dev/null
+++ b/cmds-purehelpers.adoc
@@ -0,0 +1,54 @@
+linkgit:git-check-attr[1]::
+ Display gitattributes information.
+
+linkgit:git-check-ignore[1]::
+ Debug gitignore / exclude files.
+
+linkgit:git-check-mailmap[1]::
+ Show canonical names and email addresses of contacts.
+
+linkgit:git-check-ref-format[1]::
+ Ensures that a reference name is well formed.
+
+linkgit:git-column[1]::
+ Display data in columns.
+
+linkgit:git-credential[1]::
+ Retrieve and store user credentials.
+
+linkgit:git-credential-cache[1]::
+ Helper to temporarily store passwords in memory.
+
+linkgit:git-credential-store[1]::
+ Helper to store credentials on disk.
+
+linkgit:git-fmt-merge-msg[1]::
+ Produce a merge commit message.
+
+linkgit:git-hook[1]::
+ Run git hooks.
+
+linkgit:git-interpret-trailers[1]::
+ Add or parse structured information in commit messages.
+
+linkgit:git-mailinfo[1]::
+ Extracts patch and authorship from a single e-mail message.
+
+linkgit:git-mailsplit[1]::
+ Simple UNIX mbox splitter program.
+
+linkgit:git-merge-one-file[1]::
+ The standard helper program to use with git-merge-index.
+
+linkgit:git-patch-id[1]::
+ Compute unique ID for a patch.
+
+linkgit:git-sh-i18n[1]::
+ Git's i18n setup code for shell scripts.
+
+linkgit:git-sh-setup[1]::
+ Common Git shell script setup code.
+
+linkgit:git-stripspace[1]::
+ Remove unnecessary whitespace.
+
diff --git a/cmds-synchelpers.adoc b/cmds-synchelpers.adoc
new file mode 100644
index 0000000..253c5d3
--- /dev/null
+++ b/cmds-synchelpers.adoc
@@ -0,0 +1,18 @@
+linkgit:git-http-fetch[1]::
+ Download from a remote Git repository via HTTP.
+
+linkgit:git-http-push[1]::
+ Push objects over HTTP/DAV to another repository.
+
+linkgit:git-receive-pack[1]::
+ Receive what is pushed into the repository.
+
+linkgit:git-shell[1]::
+ Restricted login shell for Git-only SSH access.
+
+linkgit:git-upload-archive[1]::
+ Send archive back to git-archive.
+
+linkgit:git-upload-pack[1]::
+ Send objects packed back to git-fetch-pack.
+
diff --git a/cmds-synchingrepositories.adoc b/cmds-synchingrepositories.adoc
new file mode 100644
index 0000000..d3ddba3
--- /dev/null
+++ b/cmds-synchingrepositories.adoc
@@ -0,0 +1,15 @@
+linkgit:git-daemon[1]::
+ A really simple server for Git repositories.
+
+linkgit:git-fetch-pack[1]::
+ Receive missing objects from another repository.
+
+linkgit:git-http-backend[1]::
+ Server side implementation of Git over HTTP.
+
+linkgit:git-send-pack[1]::
+ Push objects over Git protocol to another repository.
+
+linkgit:git-update-server-info[1]::
+ Update auxiliary info file to help dumb servers.
+
diff --git a/cmds-userinterfaces.adoc b/cmds-userinterfaces.adoc
new file mode 100644
index 0000000..dae8053
--- /dev/null
+++ b/cmds-userinterfaces.adoc
@@ -0,0 +1,24 @@
+linkgit:gitattributes[5]::
+ Defining attributes per path.
+
+linkgit:gitcli[7]::
+ Git command-line interface and conventions.
+
+linkgit:githooks[5]::
+ Hooks used by Git.
+
+linkgit:gitignore[5]::
+ Specifies intentionally untracked files to ignore.
+
+linkgit:gitmailmap[5]::
+ Map author/committer names and/or E-Mail addresses.
+
+linkgit:gitmodules[5]::
+ Defining submodule properties.
+
+linkgit:gitrepository-layout[5]::
+ Git Repository Layout.
+
+linkgit:gitrevisions[7]::
+ Specifying revisions and ranges for Git.
+
diff --git a/config.adoc b/config.adoc
new file mode 100644
index 0000000..cc76925
--- /dev/null
+++ b/config.adoc
@@ -0,0 +1,559 @@
+CONFIGURATION FILE
+------------------
+
+The Git configuration file contains a number of variables that affect
+the Git commands' behavior. The files `.git/config` and optionally
+`config.worktree` (see the "CONFIGURATION FILE" section of
+linkgit:git-worktree[1]) in each repository are used to store the
+configuration for that repository, and `$HOME/.gitconfig` is used to
+store a per-user configuration as fallback values for the `.git/config`
+file. The file `/etc/gitconfig` can be used to store a system-wide
+default configuration.
+
+The configuration variables are used by both the Git plumbing
+and the porcelain commands. The variables are divided into sections, wherein
+the fully qualified variable name of the variable itself is the last
+dot-separated segment and the section name is everything before the last
+dot. The variable names are case-insensitive, allow only alphanumeric
+characters and `-`, and must start with an alphabetic character. Some
+variables may appear multiple times; we say then that the variable is
+multivalued.
+
+Syntax
+~~~~~~
+
+The syntax is fairly flexible and permissive. Whitespace characters,
+which in this context are the space character (SP) and the horizontal
+tabulation (HT), are mostly ignored. The '#' and ';' characters begin
+comments to the end of line. Blank lines are ignored.
+
+The file consists of sections and variables. A section begins with
+the name of the section in square brackets and continues until the next
+section begins. Section names are case-insensitive. Only alphanumeric
+characters, `-` and `.` are allowed in section names. Each variable
+must belong to some section, which means that there must be a section
+header before the first setting of a variable.
+
+Sections can be further divided into subsections. To begin a subsection
+put its name in double quotes, separated by space from the section name,
+in the section header, like in the example below:
+
+--------
+ [section "subsection"]
+
+--------
+
+Subsection names are case sensitive and can contain any characters except
+newline and the null byte. Doublequote `"` and backslash can be included
+by escaping them as `\"` and `\\`, respectively. Backslashes preceding
+other characters are dropped when reading; for example, `\t` is read as
+`t` and `\0` is read as `0`. Section headers cannot span multiple lines.
+Variables may belong directly to a section or to a given subsection. You
+can have `[section]` if you have `[section "subsection"]`, but you don't
+need to.
+
+There is also a deprecated `[section.subsection]` syntax. With this
+syntax, the subsection name is converted to lower-case and is also
+compared case sensitively. These subsection names follow the same
+restrictions as section names.
+
+All the other lines (and the remainder of the line after the section
+header) are recognized as setting variables, in the form
+'name = value' (or just 'name', which is a short-hand to say that
+the variable is the boolean "true").
+The variable names are case-insensitive, allow only alphanumeric characters
+and `-`, and must start with an alphabetic character.
+
+Whitespace characters surrounding `name`, `=` and `value` are discarded.
+Internal whitespace characters within 'value' are retained verbatim.
+Comments starting with either `#` or `;` and extending to the end of line
+are discarded. A line that defines a value can be continued to the next
+line by ending it with a backslash (`\`); the backslash and the end-of-line
+characters are discarded.
+
+If `value` needs to contain leading or trailing whitespace characters,
+it must be enclosed in double quotation marks (`"`). Inside double quotation
+marks, double quote (`"`) and backslash (`\`) characters must be escaped:
+use `\"` for `"` and `\\` for `\`.
+
+The following escape sequences (beside `\"` and `\\`) are recognized:
+`\n` for newline character (NL), `\t` for horizontal tabulation (HT, TAB)
+and `\b` for backspace (BS). Other char escape sequences (including octal
+escape sequences) are invalid.
+
+
+Includes
+~~~~~~~~
+
+The `include` and `includeIf` sections allow you to include config
+directives from another source. These sections behave identically to
+each other with the exception that `includeIf` sections may be ignored
+if their condition does not evaluate to true; see "Conditional includes"
+below.
+
+You can include a config file from another by setting the special
+`include.path` (or `includeIf.*.path`) variable to the name of the file
+to be included. The variable takes a pathname as its value, and is
+subject to tilde expansion. These variables can be given multiple times.
+
+The contents of the included file are inserted immediately, as if they
+had been found at the location of the include directive. If the value of the
+variable is a relative path, the path is considered to
+be relative to the configuration file in which the include directive
+was found. See below for examples.
+
+Conditional includes
+~~~~~~~~~~~~~~~~~~~~
+
+You can conditionally include a config file from another by setting an
+`includeIf.<condition>.path` variable to the name of the file to be
+included.
+
+The condition starts with a keyword followed by a colon and some data
+whose format and meaning depends on the keyword. Supported keywords
+are:
+
+`gitdir`::
+
+ The data that follows the keyword `gitdir:` is used as a glob
+ pattern. If the location of the .git directory matches the
+ pattern, the include condition is met.
++
+The .git location may be auto-discovered, or come from `$GIT_DIR`
+environment variable. If the repository is auto-discovered via a .git
+file (e.g. from submodules, or a linked worktree), the .git location
+would be the final location where the .git directory is, not where the
+.git file is.
++
+The pattern can contain standard globbing wildcards and two additional
+ones, `**/` and `/**`, that can match multiple path components. Please
+refer to linkgit:gitignore[5] for details. For convenience:
+
+ * If the pattern starts with `~/`, `~` will be substituted with the
+ content of the environment variable `HOME`.
+
+ * If the pattern starts with `./`, it is replaced with the directory
+ containing the current config file.
+
+ * If the pattern does not start with either `~/`, `./` or `/`, `**/`
+ will be automatically prepended. For example, the pattern `foo/bar`
+ becomes `**/foo/bar` and would match `/any/path/to/foo/bar`.
+
+ * If the pattern ends with `/`, `**` will be automatically added. For
+ example, the pattern `foo/` becomes `foo/**`. In other words, it
+ matches "foo" and everything inside, recursively.
+
+`gitdir/i`::
+ This is the same as `gitdir` except that matching is done
+ case-insensitively (e.g. on case-insensitive file systems)
+
+`onbranch`::
+ The data that follows the keyword `onbranch:` is taken to be a
+ pattern with standard globbing wildcards and two additional
+ ones, `**/` and `/**`, that can match multiple path components.
+ If we are in a worktree where the name of the branch that is
+ currently checked out matches the pattern, the include condition
+ is met.
++
+If the pattern ends with `/`, `**` will be automatically added. For
+example, the pattern `foo/` becomes `foo/**`. In other words, it matches
+all branches that begin with `foo/`. This is useful if your branches are
+organized hierarchically and you would like to apply a configuration to
+all the branches in that hierarchy.
+
+`hasconfig:remote.*.url:`::
+ The data that follows this keyword is taken to
+ be a pattern with standard globbing wildcards and two
+ additional ones, `**/` and `/**`, that can match multiple
+ components. The first time this keyword is seen, the rest of
+ the config files will be scanned for remote URLs (without
+ applying any values). If there exists at least one remote URL
+ that matches this pattern, the include condition is met.
++
+Files included by this option (directly or indirectly) are not allowed
+to contain remote URLs.
++
+Note that unlike other includeIf conditions, resolving this condition
+relies on information that is not yet known at the point of reading the
+condition. A typical use case is this option being present as a
+system-level or global-level config, and the remote URL being in a
+local-level config; hence the need to scan ahead when resolving this
+condition. In order to avoid the chicken-and-egg problem in which
+potentially-included files can affect whether such files are potentially
+included, Git breaks the cycle by prohibiting these files from affecting
+the resolution of these conditions (thus, prohibiting them from
+declaring remote URLs).
++
+As for the naming of this keyword, it is for forwards compatibility with
+a naming scheme that supports more variable-based include conditions,
+but currently Git only supports the exact keyword described above.
+
+A few more notes on matching via `gitdir` and `gitdir/i`:
+
+ * Symlinks in `$GIT_DIR` are not resolved before matching.
+
+ * Both the symlink & realpath versions of paths will be matched
+ outside of `$GIT_DIR`. E.g. if ~/git is a symlink to
+ /mnt/storage/git, both `gitdir:~/git` and `gitdir:/mnt/storage/git`
+ will match.
++
+This was not the case in the initial release of this feature in
+v2.13.0, which only matched the realpath version. Configuration that
+wants to be compatible with the initial release of this feature needs
+to either specify only the realpath version, or both versions.
+
+ * Note that "../" is not special and will match literally, which is
+ unlikely what you want.
+
+Example
+~~~~~~~
+
+----
+# Core variables
+[core]
+ ; Don't trust file modes
+ filemode = false
+
+# Our diff algorithm
+[diff]
+ external = /usr/local/bin/diff-wrapper
+ renames = true
+
+[branch "devel"]
+ remote = origin
+ merge = refs/heads/devel
+
+# Proxy settings
+[core]
+ gitProxy="ssh" for "kernel.org"
+ gitProxy=default-proxy ; for the rest
+
+[include]
+ path = /path/to/foo.inc ; include by absolute path
+ path = foo.inc ; find "foo.inc" relative to the current file
+ path = ~/foo.inc ; find "foo.inc" in your `$HOME` directory
+
+; include if $GIT_DIR is /path/to/foo/.git
+[includeIf "gitdir:/path/to/foo/.git"]
+ path = /path/to/foo.inc
+
+; include for all repositories inside /path/to/group
+[includeIf "gitdir:/path/to/group/"]
+ path = /path/to/foo.inc
+
+; include for all repositories inside $HOME/to/group
+[includeIf "gitdir:~/to/group/"]
+ path = /path/to/foo.inc
+
+; relative paths are always relative to the including
+; file (if the condition is true); their location is not
+; affected by the condition
+[includeIf "gitdir:/path/to/group/"]
+ path = foo.inc
+
+; include only if we are in a worktree where foo-branch is
+; currently checked out
+[includeIf "onbranch:foo-branch"]
+ path = foo.inc
+
+; include only if a remote with the given URL exists (note
+; that such a URL may be provided later in a file or in a
+; file read after this file is read, as seen in this example)
+[includeIf "hasconfig:remote.*.url:https://example.com/**"]
+ path = foo.inc
+[remote "origin"]
+ url = https://example.com/git
+----
+
+Values
+~~~~~~
+
+Values of many variables are treated as a simple string, but there
+are variables that take values of specific types and there are rules
+as to how to spell them.
+
+boolean::
+
+ When a variable is said to take a boolean value, many
+ synonyms are accepted for 'true' and 'false'; these are all
+ case-insensitive.
+
+ true;; Boolean true literals are `yes`, `on`, `true`,
+ and `1`. Also, a variable defined without `= <value>`
+ is taken as true.
+
+ false;; Boolean false literals are `no`, `off`, `false`,
+ `0` and the empty string.
++
+When converting a value to its canonical form using the `--type=bool` type
+specifier, 'git config' will ensure that the output is "true" or
+"false" (spelled in lowercase).
+
+integer::
+ The value for many variables that specify various sizes can
+ be suffixed with `k`, `M`,... to mean "scale the number by
+ 1024", "by 1024x1024", etc.
+
+color::
+ The value for a variable that takes a color is a list of
+ colors (at most two, one for foreground and one for background)
+ and attributes (as many as you want), separated by spaces.
++
+The basic colors accepted are `normal`, `black`, `red`, `green`,
+`yellow`, `blue`, `magenta`, `cyan`, `white` and `default`. The first
+color given is the foreground; the second is the background. All the
+basic colors except `normal` and `default` have a bright variant that can
+be specified by prefixing the color with `bright`, like `brightred`.
++
+The color `normal` makes no change to the color. It is the same as an
+empty string, but can be used as the foreground color when specifying a
+background color alone (for example, "normal red").
++
+The color `default` explicitly resets the color to the terminal default,
+for example to specify a cleared background. Although it varies between
+terminals, this is usually not the same as setting to "white black".
++
+Colors may also be given as numbers between 0 and 255; these use ANSI
+256-color mode (but note that not all terminals may support this). If
+your terminal supports it, you may also specify 24-bit RGB values as
+hex, like `#ff0ab3`, or 12-bit RGB values like `#f1b`, which is
+equivalent to the 24-bit color `#ff11bb`.
++
+The accepted attributes are `bold`, `dim`, `ul`, `blink`, `reverse`,
+`italic`, and `strike` (for crossed-out or "strikethrough" letters).
+The position of any attributes with respect to the colors
+(before, after, or in between), doesn't matter. Specific attributes may
+be turned off by prefixing them with `no` or `no-` (e.g., `noreverse`,
+`no-ul`, etc).
++
+The pseudo-attribute `reset` resets all colors and attributes before
+applying the specified coloring. For example, `reset green` will result
+in a green foreground and default background without any active
+attributes.
++
+An empty color string produces no color effect at all. This can be used
+to avoid coloring specific elements without disabling color entirely.
++
+For git's pre-defined color slots, the attributes are meant to be reset
+at the beginning of each item in the colored output. So setting
+`color.decorate.branch` to `black` will paint that branch name in a
+plain `black`, even if the previous thing on the same output line (e.g.
+opening parenthesis before the list of branch names in `log --decorate`
+output) is set to be painted with `bold` or some other attribute.
+However, custom log formats may do more complicated and layered
+coloring, and the negated forms may be useful there.
+
+pathname::
+ A variable that takes a pathname value can be given a
+ string that begins with "`~/`" or "`~user/`", and the usual
+ tilde expansion happens to such a string: `~/`
+ is expanded to the value of `$HOME`, and `~user/` to the
+ specified user's home directory.
++
+If a path starts with `%(prefix)/`, the remainder is interpreted as a
+path relative to Git's "runtime prefix", i.e. relative to the location
+where Git itself was installed. For example, `%(prefix)/bin/` refers to
+the directory in which the Git executable itself lives. If Git was
+compiled without runtime prefix support, the compiled-in prefix will be
+substituted instead. In the unlikely event that a literal path needs to
+be specified that should _not_ be expanded, it needs to be prefixed by
+`./`, like so: `./%(prefix)/bin`.
+
+
+Variables
+~~~~~~~~~
+
+Note that this list is non-comprehensive and not necessarily complete.
+For command-specific variables, you will find a more detailed description
+in the appropriate manual page.
+
+Other git-related tools may and do use their own variables. When
+inventing new variables for use in your own tool, make sure their
+names do not conflict with those that are used by Git itself and
+other popular tools, and describe them in your documentation.
+
+include::config/add.adoc[]
+
+include::config/advice.adoc[]
+
+include::config/alias.adoc[]
+
+include::config/am.adoc[]
+
+include::config/apply.adoc[]
+
+include::config/attr.adoc[]
+
+include::config/bitmap-pseudo-merge.adoc[]
+
+include::config/blame.adoc[]
+
+include::config/branch.adoc[]
+
+include::config/browser.adoc[]
+
+include::config/bundle.adoc[]
+
+include::config/checkout.adoc[]
+
+include::config/clean.adoc[]
+
+include::config/clone.adoc[]
+
+include::config/color.adoc[]
+
+include::config/column.adoc[]
+
+include::config/commit.adoc[]
+
+include::config/commitgraph.adoc[]
+
+include::config/completion.adoc[]
+
+include::config/core.adoc[]
+
+include::config/credential.adoc[]
+
+include::config/diff.adoc[]
+
+include::config/difftool.adoc[]
+
+include::config/extensions.adoc[]
+
+include::config/fastimport.adoc[]
+
+include::config/feature.adoc[]
+
+include::config/fetch.adoc[]
+
+include::config/filter.adoc[]
+
+include::config/format.adoc[]
+
+include::config/fsck.adoc[]
+
+include::config/fsmonitor--daemon.adoc[]
+
+include::config/gc.adoc[]
+
+include::config/gitcvs.adoc[]
+
+include::config/gitweb.adoc[]
+
+include::config/gpg.adoc[]
+
+include::config/grep.adoc[]
+
+include::config/gui.adoc[]
+
+include::config/guitool.adoc[]
+
+include::config/help.adoc[]
+
+include::config/http.adoc[]
+
+include::config/i18n.adoc[]
+
+include::config/imap.adoc[]
+
+include::config/includeif.adoc[]
+
+include::config/index.adoc[]
+
+include::config/init.adoc[]
+
+include::config/instaweb.adoc[]
+
+include::config/interactive.adoc[]
+
+include::config/log.adoc[]
+
+include::config/lsrefs.adoc[]
+
+include::config/mailinfo.adoc[]
+
+include::config/mailmap.adoc[]
+
+include::config/maintenance.adoc[]
+
+include::config/man.adoc[]
+
+include::config/merge.adoc[]
+
+include::config/mergetool.adoc[]
+
+include::config/notes.adoc[]
+
+include::config/pack.adoc[]
+
+include::config/pager.adoc[]
+
+include::config/pretty.adoc[]
+
+include::config/promisor.adoc[]
+
+include::config/protocol.adoc[]
+
+include::config/pull.adoc[]
+
+include::config/push.adoc[]
+
+include::config/rebase.adoc[]
+
+include::config/receive.adoc[]
+
+include::config/reftable.adoc[]
+
+include::config/remote.adoc[]
+
+include::config/remotes.adoc[]
+
+include::config/repack.adoc[]
+
+include::config/rerere.adoc[]
+
+include::config/revert.adoc[]
+
+include::config/safe.adoc[]
+
+include::config/sendemail.adoc[]
+
+include::config/sequencer.adoc[]
+
+include::config/showbranch.adoc[]
+
+include::config/sparse.adoc[]
+
+include::config/splitindex.adoc[]
+
+include::config/ssh.adoc[]
+
+include::config/stash.adoc[]
+
+include::config/status.adoc[]
+
+include::config/submodule.adoc[]
+
+include::config/tag.adoc[]
+
+include::config/tar.adoc[]
+
+include::config/trace2.adoc[]
+
+include::config/trailer.adoc[]
+
+include::config/transfer.adoc[]
+
+include::config/uploadarchive.adoc[]
+
+include::config/uploadpack.adoc[]
+
+include::config/url.adoc[]
+
+include::config/user.adoc[]
+
+include::config/versionsort.adoc[]
+
+include::config/web.adoc[]
+
+include::config/worktree.adoc[]
diff --git a/date-formats.adoc b/date-formats.adoc
new file mode 100644
index 0000000..e24517c
--- /dev/null
+++ b/date-formats.adoc
@@ -0,0 +1,31 @@
+DATE FORMATS
+------------
+
+The `GIT_AUTHOR_DATE` and `GIT_COMMITTER_DATE` environment variables
+support the following date formats:
+
+Git internal format::
+ It is `<unix-timestamp> <time-zone-offset>`, where
+ `<unix-timestamp>` is the number of seconds since the UNIX epoch.
+ `<time-zone-offset>` is a positive or negative offset from UTC.
+ For example CET (which is 1 hour ahead of UTC) is `+0100`.
+
+RFC 2822::
+ The standard date format as described by RFC 2822, for example
+ `Thu, 07 Apr 2005 22:13:13 +0200`.
+
+ISO 8601::
+ Time and date specified by the ISO 8601 standard, for example
+ `2005-04-07T22:13:13`. The parser accepts a space instead of the
+ `T` character as well. Fractional parts of a second will be ignored,
+ for example `2005-04-07T22:13:13.019` will be treated as
+ `2005-04-07T22:13:13`.
++
+NOTE: In addition, the date part is accepted in the following formats:
+`YYYY.MM.DD`, `MM/DD/YYYY` and `DD.MM.YYYY`.
+
+ifdef::git-commit[]
+In addition to recognizing all date formats above, the `--date` option
+will also try to make sense of other, more human-centric date formats,
+such as relative dates like "yesterday" or "last Friday at noon".
+endif::git-commit[]
diff --git a/diff-format.adoc b/diff-format.adoc
new file mode 100644
index 0000000..80e36e1
--- /dev/null
+++ b/diff-format.adoc
@@ -0,0 +1,185 @@
+Raw output format
+-----------------
+
+The raw output format from `git-diff-index`, `git-diff-tree`,
+`git-diff-files` and `git diff --raw` are very similar.
+
+These commands all compare two sets of things; what is
+compared differs:
+
+`git-diff-index <tree-ish>`::
+ compares the _<tree-ish>_ and the files on the filesystem.
+
+`git-diff-index --cached <tree-ish>`::
+ compares the _<tree-ish>_ and the index.
+
+`git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>...]`::
+ compares the trees named by the two arguments.
+
+`git-diff-files [<pattern>...]`::
+ compares the index and the files on the filesystem.
+
+The `git-diff-tree` command begins its output by printing the hash of
+what is being compared. After that, all the commands print one output
+line per changed file.
+
+An output line is formatted this way:
+
+------------------------------------------------
+in-place edit :100644 100644 bcd1234 0123456 M file0
+copy-edit :100644 100644 abcd123 1234567 C68 file1 file2
+rename-edit :100644 100644 abcd123 1234567 R86 file1 file3
+create :000000 100644 0000000 1234567 A file4
+delete :100644 000000 1234567 0000000 D file5
+unmerged :000000 000000 0000000 0000000 U file6
+------------------------------------------------
+
+That is, from the left to the right:
+
+. a colon.
+. mode for "src"; 000000 if creation or unmerged.
+. a space.
+. mode for "dst"; 000000 if deletion or unmerged.
+. a space.
+. sha1 for "src"; 0\{40\} if creation or unmerged.
+. a space.
+. sha1 for "dst"; 0\{40\} if deletion, unmerged or "work tree out of sync with the index".
+. a space.
+. status, followed by optional "score" number.
+. a tab or a NUL when `-z` option is used.
+. path for "src"
+. a tab or a NUL when `-z` option is used; only exists for C or R.
+. path for "dst"; only exists for C or R.
+. an LF or a NUL when `-z` option is used, to terminate the record.
+
+Possible status letters are:
+
+- `A`: addition of a file
+- `C`: copy of a file into a new one
+- `D`: deletion of a file
+- `M`: modification of the contents or mode of a file
+- `R`: renaming of a file
+- `T`: change in the type of the file (regular file, symbolic link or submodule)
+- `U`: file is unmerged (you must complete the merge before it can
+ be committed)
+- `X`: "unknown" change type (most probably a bug, please report it)
+
+Status letters `C` and `R` are always followed by a score (denoting the
+percentage of similarity between the source and target of the move or
+copy). Status letter `M` may be followed by a score (denoting the
+percentage of dissimilarity) for file rewrites.
+
+The sha1 for "dst" is shown as all 0's if a file on the filesystem
+is out of sync with the index.
+
+Example:
+
+------------------------------------------------
+:100644 100644 5be4a4a 0000000 M file.c
+------------------------------------------------
+
+Without the `-z` option, pathnames with "unusual" characters are
+quoted as explained for the configuration variable `core.quotePath`
+(see linkgit:git-config[1]). Using `-z` the filename is output
+verbatim and the line is terminated by a NUL byte.
+
+diff format for merges
+----------------------
+
+`git-diff-tree`, `git-diff-files` and `git-diff --raw`
+can take `-c` or `--cc` option
+to generate diff output also for merge commits. The output differs
+from the format described above in the following way:
+
+. there is a colon for each parent
+. there are more "src" modes and "src" sha1
+. status is concatenated status characters for each parent
+. no optional "score" number
+. tab-separated pathname(s) of the file
+
+For `-c` and `--cc`, only the destination or final path is shown even
+if the file was renamed on any side of history. With
+`--combined-all-paths`, the name of the path in each parent is shown
+followed by the name of the path in the merge commit.
+
+Examples for `-c` and `--cc` without `--combined-all-paths`:
+------------------------------------------------
+::100644 100644 100644 fabadb8 cc95eb0 4866510 MM desc.c
+::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM bar.sh
+::100644 100644 100644 e07d6c5 9042e82 ee91881 RR phooey.c
+------------------------------------------------
+
+Examples when `--combined-all-paths` added to either `-c` or `--cc`:
+
+------------------------------------------------
+::100644 100644 100644 fabadb8 cc95eb0 4866510 MM desc.c desc.c desc.c
+::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM foo.sh bar.sh bar.sh
+::100644 100644 100644 e07d6c5 9042e82 ee91881 RR fooey.c fuey.c phooey.c
+------------------------------------------------
+
+Note that 'combined diff' lists only files which were modified from
+all parents.
+
+
+include::diff-generate-patch.adoc[]
+
+
+other diff formats
+------------------
+
+The `--summary` option describes newly added, deleted, renamed and
+copied files. The `--stat` option adds `diffstat`(1) graph to the
+output. These options can be combined with other options, such as
+`-p`, and are meant for human consumption.
+
+When showing a change that involves a rename or a copy, `--stat` output
+formats the pathnames compactly by combining common prefix and suffix of
+the pathnames. For example, a change that moves `arch/i386/Makefile` to
+`arch/x86/Makefile` while modifying 4 lines will be shown like this:
+
+------------------------------------
+arch/{i386 => x86}/Makefile | 4 +--
+------------------------------------
+
+The `--numstat` option gives the diffstat(1) information but is designed
+for easier machine consumption. An entry in `--numstat` output looks
+like this:
+
+----------------------------------------
+1 2 README
+3 1 arch/{i386 => x86}/Makefile
+----------------------------------------
+
+That is, from left to right:
+
+. the number of added lines;
+. a tab;
+. the number of deleted lines;
+. a tab;
+. pathname (possibly with rename/copy information);
+. a newline.
+
+When `-z` output option is in effect, the output is formatted this way:
+
+----------------------------------------
+1 2 README NUL
+3 1 NUL arch/i386/Makefile NUL arch/x86/Makefile NUL
+----------------------------------------
+
+That is:
+
+. the number of added lines;
+. a tab;
+. the number of deleted lines;
+. a tab;
+. a NUL (only exists if renamed/copied);
+. pathname in preimage;
+. a NUL (only exists if renamed/copied);
+. pathname in postimage (only exists if renamed/copied);
+. a NUL.
+
+The extra `NUL` before the preimage path in renamed case is to allow
+scripts that read the output to tell if the current record being read is
+a single-path record or a rename/copy record without reading ahead.
+After reading added and deleted lines, reading up to `NUL` would yield
+the pathname, but if that is `NUL`, the record will show two paths.
diff --git a/diff-generate-patch.adoc b/diff-generate-patch.adoc
new file mode 100644
index 0000000..e5c813c
--- /dev/null
+++ b/diff-generate-patch.adoc
@@ -0,0 +1,210 @@
+[[generate_patch_text_with_p]]
+Generating patch text with -p
+-----------------------------
+
+Running
+linkgit:git-diff[1],
+linkgit:git-log[1],
+linkgit:git-show[1],
+linkgit:git-diff-index[1],
+linkgit:git-diff-tree[1], or
+linkgit:git-diff-files[1]
+with the `-p` option produces patch text.
+You can customize the creation of patch text via the
+`GIT_EXTERNAL_DIFF` and the `GIT_DIFF_OPTS` environment variables
+(see linkgit:git[1]), and the `diff` attribute (see linkgit:gitattributes[5]).
+
+What the `-p` option produces is slightly different from the traditional
+diff format:
+
+1. It is preceded by a "git diff" header that looks like this:
+
+ diff --git a/file1 b/file2
++
+The `a/` and `b/` filenames are the same unless rename/copy is
+involved. Especially, even for a creation or a deletion,
+`/dev/null` is _not_ used in place of the `a/` or `b/` filenames.
++
+When a rename/copy is involved, `file1` and `file2` show the
+name of the source file of the rename/copy and the name of
+the file that the rename/copy produces, respectively.
+
+2. It is followed by one or more extended header lines:
++
+[synopsis]
+old mode <mode>
+new mode <mode>
+deleted file mode <mode>
+new file mode <mode>
+copy from <path>
+copy to <path>
+rename from <path>
+rename to <path>
+similarity index <number>
+dissimilarity index <number>
+index <hash>..<hash> <mode>
++
+File modes _<mode>_ are printed as 6-digit octal numbers including the file type
+and file permission bits.
++
+Path names in extended headers do not include the `a/` and `b/` prefixes.
++
+The similarity index is the percentage of unchanged lines, and
+the dissimilarity index is the percentage of changed lines. It
+is a rounded down integer, followed by a percent sign. The
+similarity index value of 100% is thus reserved for two equal
+files, while 100% dissimilarity means that no line from the old
+file made it into the new one.
++
+The index line includes the blob object names before and after the change.
+The _<mode>_ is included if the file mode does not change; otherwise,
+separate lines indicate the old and the new mode.
+
+3. Pathnames with "unusual" characters are quoted as explained for
+ the configuration variable `core.quotePath` (see
+ linkgit:git-config[1]).
+
+4. All the `file1` files in the output refer to files before the
+ commit, and all the `file2` files refer to files after the commit.
+ It is incorrect to apply each change to each file sequentially. For
+ example, this patch will swap a and b:
+
+ diff --git a/a b/b
+ rename from a
+ rename to b
+ diff --git a/b b/a
+ rename from b
+ rename to a
+
+5. Hunk headers mention the name of the function to which the hunk
+ applies. See "Defining a custom hunk-header" in
+ linkgit:gitattributes[5] for details of how to tailor this to
+ specific languages.
+
+
+Combined diff format
+--------------------
+
+Any diff-generating command can take the `-c` or `--cc` option to
+produce a 'combined diff' when showing a merge. This is the default
+format when showing merges with linkgit:git-diff[1] or
+linkgit:git-show[1]. Note also that you can give suitable
+`--diff-merges` option to any of these commands to force generation of
+diffs in a specific format.
+
+A "combined diff" format looks like this:
+
+------------
+diff --combined describe.c
+index fabadb8,cc95eb0..4866510
+--- a/describe.c
++++ b/describe.c
+@@@ -98,20 -98,12 +98,20 @@@
+ return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
+ }
+
+- static void describe(char *arg)
+ -static void describe(struct commit *cmit, int last_one)
+++static void describe(char *arg, int last_one)
+ {
+ + unsigned char sha1[20];
+ + struct commit *cmit;
+ struct commit_list *list;
+ static int initialized = 0;
+ struct commit_name *n;
+
+ + if (get_sha1(arg, sha1) < 0)
+ + usage(describe_usage);
+ + cmit = lookup_commit_reference(sha1);
+ + if (!cmit)
+ + usage(describe_usage);
+ +
+ if (!initialized) {
+ initialized = 1;
+ for_each_ref(get_name);
+------------
+
+1. It is preceded by a "git diff" header, that looks like
+ this (when the `-c` option is used):
+
+ diff --combined file
++
+or like this (when the `--cc` option is used):
+
+ diff --cc file
+
+2. It is followed by one or more extended header lines
+ (this example shows a merge with two parents):
++
+[synopsis]
+index <hash>,<hash>..<hash>
+mode <mode>,<mode>`..`<mode>
+new file mode <mode>
+deleted file mode <mode>,<mode>
++
+The `mode <mode>,<mode>..<mode>` line appears only if at least one of
+the <mode> is different from the rest. Extended headers with
+information about detected content movement (renames and
+copying detection) are designed to work with the diff of two
+_<tree-ish>_ and are not used by combined diff format.
+
+3. It is followed by a two-line from-file/to-file header:
+
+ --- a/file
+ +++ b/file
++
+Similar to the two-line header for the traditional 'unified' diff
+format, `/dev/null` is used to signal created or deleted
+files.
++
+However, if the --combined-all-paths option is provided, instead of a
+two-line from-file/to-file, you get an N+1 line from-file/to-file header,
+where N is the number of parents in the merge commit:
+
+ --- a/file
+ --- a/file
+ --- a/file
+ +++ b/file
++
+This extended format can be useful if rename or copy detection is
+active, to allow you to see the original name of the file in different
+parents.
+
+4. Chunk header format is modified to prevent people from
+ accidentally feeding it to `patch -p1`. Combined diff format
+ was created for review of merge commit changes, and was not
+ meant to be applied. The change is similar to the change in the
+ extended 'index' header:
+
+ @@@ <from-file-range> <from-file-range> <to-file-range> @@@
++
+There are (number of parents + 1) `@` characters in the chunk
+header for combined diff format.
+
+Unlike the traditional 'unified' diff format, which shows two
+files A and B with a single column that has `-` (minus --
+appears in A but removed in B), `+` (plus -- missing in A but
+added to B), or `" "` (space -- unchanged) prefix, this format
+compares two or more files file1, file2,... with one file X, and
+shows how X differs from each of fileN. One column for each of
+fileN is prepended to the output line to note how X's line is
+different from it.
+
+A `-` character in the column N means that the line appears in
+fileN but it does not appear in the result. A `+` character
+in the column N means that the line appears in the result,
+and fileN does not have that line (in other words, the line was
+added, from the point of view of that parent).
+
+In the above example output, the function signature was changed
+from both files (hence two `-` removals from both file1 and
+file2, plus `++` to mean one line that was added does not appear
+in either file1 or file2). Also, eight other lines are the same
+from file1 but do not appear in file2 (hence prefixed with `+`).
+
+When shown by `git diff-tree -c`, it compares the parents of a
+merge commit with the merge result (i.e. file1..fileN are the
+parents). When shown by `git diff-files -c`, it compares the
+two unresolved merge parents with the working tree file
+(i.e. file1 is stage 2 aka "our version", file2 is stage 3 aka
+"their version").
diff --git a/diff-options.adoc b/diff-options.adoc
new file mode 100644
index 0000000..640eb6e
--- /dev/null
+++ b/diff-options.adoc
@@ -0,0 +1,891 @@
+// Please don't remove this comment as asciidoc behaves badly when
+// the first non-empty line is ifdef/ifndef. The symptom is that
+// without this comment the <git-diff-core> attribute conditionally
+// defined below ends up being defined unconditionally.
+// Last checked with asciidoc 7.0.2.
+
+ifndef::git-format-patch[]
+ifndef::git-diff[]
+ifndef::git-log[]
+:git-diff-core: 1
+endif::git-log[]
+endif::git-diff[]
+endif::git-format-patch[]
+
+ifdef::git-format-patch[]
+-p::
+--no-stat::
+ Generate plain patches without any diffstats.
+endif::git-format-patch[]
+
+ifndef::git-format-patch[]
+`-p`::
+`-u`::
+`--patch`::
+ Generate patch (see <<generate_patch_text_with_p>>).
+ifdef::git-diff[]
+ This is the default.
+endif::git-diff[]
+
+`-s`::
+`--no-patch`::
+ Suppress all output from the diff machinery. Useful for
+ commands like `git show` that show the patch by default to
+ squelch their output, or to cancel the effect of options like
+ `--patch`, `--stat` earlier on the command line in an alias.
+
+endif::git-format-patch[]
+
+ifdef::git-log[]
+-m::
+ Show diffs for merge commits in the default format. This is
+ similar to `--diff-merges=on`, except `-m` will
+ produce no output unless `-p` is given as well.
+
+-c::
+ Produce combined diff output for merge commits.
+ Shortcut for `--diff-merges=combined -p`.
+
+--cc::
+ Produce dense combined diff output for merge commits.
+ Shortcut for `--diff-merges=dense-combined -p`.
+
+--dd::
+ Produce diff with respect to first parent for both merge and
+ regular commits.
+ Shortcut for `--diff-merges=first-parent -p`.
+
+--remerge-diff::
+ Produce remerge-diff output for merge commits.
+ Shortcut for `--diff-merges=remerge -p`.
+
+--no-diff-merges::
+ Synonym for `--diff-merges=off`.
+
+--diff-merges=<format>::
+ Specify diff format to be used for merge commits. Default is
+ {diff-merges-default} unless `--first-parent` is in use, in
+ which case `first-parent` is the default.
++
+The following formats are supported:
++
+--
+off, none::
+ Disable output of diffs for merge commits. Useful to override
+ implied value.
+
+on, m::
+ Make diff output for merge commits to be shown in the default
+ format. The default format can be changed using
+ `log.diffMerges` configuration variable, whose default value
+ is `separate`.
+
+first-parent, 1::
+ Show full diff with respect to first parent. This is the same
+ format as `--patch` produces for non-merge commits.
+
+separate::
+ Show full diff with respect to each of parents.
+ Separate log entry and diff is generated for each parent.
+
+combined, c::
+ Show differences from each of the parents to the merge
+ result simultaneously instead of showing pairwise diff between
+ a parent and the result one at a time. Furthermore, it lists
+ only files which were modified from all parents.
+
+dense-combined, cc::
+ Further compress output produced by `--diff-merges=combined`
+ by omitting uninteresting hunks whose contents in the parents
+ have only two variants and the merge result picks one of them
+ without modification.
+
+remerge, r::
+ Remerge two-parent merge commits to create a temporary tree
+ object--potentially containing files with conflict markers
+ and such. A diff is then shown between that temporary tree
+ and the actual merge commit.
++
+The output emitted when this option is used is subject to change, and
+so is its interaction with other options (unless explicitly
+documented).
+--
+
+--combined-all-paths::
+ Cause combined diffs (used for merge commits) to
+ list the name of the file from all parents. It thus only has
+ effect when `--diff-merges=[dense-]combined` is in use, and
+ is likely only useful if filename changes are detected (i.e.
+ when either rename or copy detection have been requested).
+endif::git-log[]
+
+`-U<n>`::
+`--unified=<n>`::
+ Generate diffs with _<n>_ lines of context instead of
+ the usual three.
+ifndef::git-format-patch[]
+ Implies `--patch`.
+endif::git-format-patch[]
+
+`--output=<file>`::
+ Output to a specific file instead of stdout.
+
+`--output-indicator-new=<char>`::
+`--output-indicator-old=<char>`::
+`--output-indicator-context=<char>`::
+ Specify the character used to indicate new, old or context
+ lines in the generated patch. Normally they are `+`, `-` and
+ ' ' respectively.
+
+ifndef::git-format-patch[]
+`--raw`::
+ifndef::git-log[]
+ Generate the diff in raw format.
+ifdef::git-diff-core[]
+ This is the default.
+endif::git-diff-core[]
+endif::git-log[]
+ifdef::git-log[]
+ For each commit, show a summary of changes using the raw diff
+ format. See the "RAW OUTPUT FORMAT" section of
+ linkgit:git-diff[1]. This is different from showing the log
+ itself in raw format, which you can achieve with
+ `--format=raw`.
+endif::git-log[]
+endif::git-format-patch[]
+
+ifndef::git-format-patch[]
+`--patch-with-raw`::
+ Synonym for `-p --raw`.
+endif::git-format-patch[]
+
+ifdef::git-log[]
+`-t`::
+ Show the tree objects in the diff output.
+endif::git-log[]
+
+`--indent-heuristic`::
+ Enable the heuristic that shifts diff hunk boundaries to make patches
+ easier to read. This is the default.
+
+`--no-indent-heuristic`::
+ Disable the indent heuristic.
+
+`--minimal`::
+ Spend extra time to make sure the smallest possible
+ diff is produced.
+
+`--patience`::
+ Generate a diff using the "patience diff" algorithm.
+
+`--histogram`::
+ Generate a diff using the "histogram diff" algorithm.
+
+`--anchored=<text>`::
+ Generate a diff using the "anchored diff" algorithm.
++
+This option may be specified more than once.
++
+If a line exists in both the source and destination, exists only once,
+and starts with _<text>_, this algorithm attempts to prevent it from
+appearing as a deletion or addition in the output. It uses the "patience
+diff" algorithm internally.
+
+`--diff-algorithm=(patience|minimal|histogram|myers)`::
+ Choose a diff algorithm. The variants are as follows:
++
+--
+ `default`;;
+ `myers`;;
+ The basic greedy diff algorithm. Currently, this is the default.
+ `minimal`;;
+ Spend extra time to make sure the smallest possible diff is
+ produced.
+ `patience`;;
+ Use "patience diff" algorithm when generating patches.
+ `histogram`;;
+ This algorithm extends the patience algorithm to "support
+ low-occurrence common elements".
+--
++
+For instance, if you configured the `diff.algorithm` variable to a
+non-default value and want to use the default one, then you
+have to use `--diff-algorithm=default` option.
+
+`--stat[=<width>[,<name-width>[,<count>]]]`::
+ Generate a diffstat. By default, as much space as necessary
+ will be used for the filename part, and the rest for the graph
+ part. Maximum width defaults to terminal width, or 80 columns
+ if not connected to a terminal, and can be overridden by
+ _<width>_. The width of the filename part can be limited by
+ giving another width _<name-width>_ after a comma or by setting
+ `diff.statNameWidth=<name-width>`. The width of the graph part can be
+ limited by using `--stat-graph-width=<graph-width>` or by setting
+ `diff.statGraphWidth=<graph-width>`. Using `--stat` or
+ `--stat-graph-width` affects all commands generating a stat graph,
+ while setting `diff.statNameWidth` or `diff.statGraphWidth`
+ does not affect `git format-patch`.
+ By giving a third parameter _<count>_, you can limit the output to
+ the first _<count>_ lines, followed by `...` if there are more.
++
+These parameters can also be set individually with `--stat-width=<width>`,
+`--stat-name-width=<name-width>` and `--stat-count=<count>`.
+
+`--compact-summary`::
+ Output a condensed summary of extended header information such
+ as file creations or deletions ("new" or "gone", optionally `+l`
+ if it's a symlink) and mode changes (`+x` or `-x` for adding
+ or removing executable bit respectively) in diffstat. The
+ information is put between the filename part and the graph
+ part. Implies `--stat`.
+
+`--numstat`::
+ Similar to `--stat`, but shows number of added and
+ deleted lines in decimal notation and pathname without
+ abbreviation, to make it more machine friendly. For
+ binary files, outputs two `-` instead of saying
+ `0 0`.
+
+`--shortstat`::
+ Output only the last line of the `--stat` format containing total
+ number of modified files, as well as number of added and deleted
+ lines.
+
+`-X [<param>,...]`::
+`--dirstat[=<param>,...]`::
+ Output the distribution of relative amount of changes for each
+ sub-directory. The behavior of `--dirstat` can be customized by
+ passing it a comma separated list of parameters.
+ The defaults are controlled by the `diff.dirstat` configuration
+ variable (see linkgit:git-config[1]).
+ The following parameters are available:
++
+--
+`changes`;;
+ Compute the dirstat numbers by counting the lines that have been
+ removed from the source, or added to the destination. This ignores
+ the amount of pure code movements within a file. In other words,
+ rearranging lines in a file is not counted as much as other changes.
+ This is the default behavior when no parameter is given.
+`lines`;;
+ Compute the dirstat numbers by doing the regular line-based diff
+ analysis, and summing the removed/added line counts. (For binary
+ files, count 64-byte chunks instead, since binary files have no
+ natural concept of lines). This is a more expensive `--dirstat`
+ behavior than the `changes` behavior, but it does count rearranged
+ lines within a file as much as other changes. The resulting output
+ is consistent with what you get from the other `--*stat` options.
+`files`;;
+ Compute the dirstat numbers by counting the number of files changed.
+ Each changed file counts equally in the dirstat analysis. This is
+ the computationally cheapest `--dirstat` behavior, since it does
+ not have to look at the file contents at all.
+`cumulative`;;
+ Count changes in a child directory for the parent directory as well.
+ Note that when using `cumulative`, the sum of the percentages
+ reported may exceed 100%. The default (non-cumulative) behavior can
+ be specified with the `noncumulative` parameter.
+_<limit>_;;
+ An integer parameter specifies a cut-off percent (3% by default).
+ Directories contributing less than this percentage of the changes
+ are not shown in the output.
+--
++
+Example: The following will count changed files, while ignoring
+directories with less than 10% of the total amount of changed files,
+and accumulating child directory counts in the parent directories:
+`--dirstat=files,10,cumulative`.
+
+`--cumulative`::
+ Synonym for `--dirstat=cumulative`.
+
+`--dirstat-by-file[=<param>,...]`::
+ Synonym for `--dirstat=files,<param>,...`.
+
+`--summary`::
+ Output a condensed summary of extended header information
+ such as creations, renames and mode changes.
+
+ifndef::git-format-patch[]
+`--patch-with-stat`::
+ Synonym for `-p --stat`.
+endif::git-format-patch[]
+
+ifndef::git-format-patch[]
+
+`-z`::
+ifdef::git-log[]
+ Separate the commits with __NUL__s instead of newlines.
++
+Also, when `--raw` or `--numstat` has been given, do not munge
+pathnames and use __NUL__s as output field terminators.
+endif::git-log[]
+ifndef::git-log[]
+ When `--raw`, `--numstat`, `--name-only` or `--name-status` has been
+ given, do not munge pathnames and use NULs as output field terminators.
+endif::git-log[]
++
+Without this option, pathnames with "unusual" characters are quoted as
+explained for the configuration variable `core.quotePath` (see
+linkgit:git-config[1]).
+
+`--name-only`::
+ Show only the name of each changed file in the post-image tree.
+ The file names are often encoded in UTF-8.
+ For more information see the discussion about encoding in the linkgit:git-log[1]
+ manual page.
+
+`--name-status`::
+ Show only the name(s) and status of each changed file. See the description
+ of the `--diff-filter` option on what the status letters mean.
+ Just like `--name-only` the file names are often encoded in UTF-8.
+
+`--submodule[=<format>]`::
+ Specify how differences in submodules are shown. When specifying
+ `--submodule=short` the `short` format is used. This format just
+ shows the names of the commits at the beginning and end of the range.
+ When `--submodule` or `--submodule=log` is specified, the `log`
+ format is used. This format lists the commits in the range like
+ linkgit:git-submodule[1] `summary` does. When `--submodule=diff`
+ is specified, the `diff` format is used. This format shows an
+ inline diff of the changes in the submodule contents between the
+ commit range. Defaults to `diff.submodule` or the `short` format
+ if the config option is unset.
+
+`--color[=<when>]`::
+ Show colored diff.
+ `--color` (i.e. without `=<when>`) is the same as `--color=always`.
+ _<when>_ can be one of `always`, `never`, or `auto`.
+ifdef::git-diff[]
+ It can be changed by the `color.ui` and `color.diff`
+ configuration settings.
+endif::git-diff[]
+
+`--no-color`::
+ Turn off colored diff.
+ifdef::git-diff[]
+ This can be used to override configuration settings.
+endif::git-diff[]
+ It is the same as `--color=never`.
+
+`--color-moved[=<mode>]`::
+ Moved lines of code are colored differently.
+ifdef::git-diff[]
+ It can be changed by the `diff.colorMoved` configuration setting.
+endif::git-diff[]
+ The _<mode>_ defaults to `no` if the option is not given
+ and to `zebra` if the option with no mode is given.
+ The mode must be one of:
++
+--
+`no`::
+ Moved lines are not highlighted.
+`default`::
+ Is a synonym for `zebra`. This may change to a more sensible mode
+ in the future.
+`plain`::
+ Any line that is added in one location and was removed
+ in another location will be colored with `color.diff.newMoved`.
+ Similarly `color.diff.oldMoved` will be used for removed lines
+ that are added somewhere else in the diff. This mode picks up any
+ moved line, but it is not very useful in a review to determine
+ if a block of code was moved without permutation.
+`blocks`::
+ Blocks of moved text of at least 20 alphanumeric characters
+ are detected greedily. The detected blocks are
+ painted using either the `color.diff.(old|new)Moved` color.
+ Adjacent blocks cannot be told apart.
+`zebra`::
+ Blocks of moved text are detected as in `blocks` mode. The blocks
+ are painted using either the `color.diff.(old|new)Moved` color or
+ `color.diff.(old|new)MovedAlternative`. The change between
+ the two colors indicates that a new block was detected.
+`dimmed-zebra`::
+ Similar to `zebra`, but additional dimming of uninteresting parts
+ of moved code is performed. The bordering lines of two adjacent
+ blocks are considered interesting, the rest is uninteresting.
+ `dimmed_zebra` is a deprecated synonym.
+--
+
+`--no-color-moved`::
+ Turn off move detection. This can be used to override configuration
+ settings. It is the same as `--color-moved=no`.
+
+`--color-moved-ws=<mode>,...`::
+ This configures how whitespace is ignored when performing the
+ move detection for `--color-moved`.
+ifdef::git-diff[]
+ It can be set by the `diff.colorMovedWS` configuration setting.
+endif::git-diff[]
+ These modes can be given as a comma separated list:
++
+--
+`no`::
+ Do not ignore whitespace when performing move detection.
+`ignore-space-at-eol`::
+ Ignore changes in whitespace at EOL.
+`ignore-space-change`::
+ Ignore changes in amount of whitespace. This ignores whitespace
+ at line end, and considers all other sequences of one or
+ more whitespace characters to be equivalent.
+`ignore-all-space`::
+ Ignore whitespace when comparing lines. This ignores differences
+ even if one line has whitespace where the other line has none.
+`allow-indentation-change`::
+ Initially ignore any whitespace in the move detection, then
+ group the moved code blocks only into a block if the change in
+ whitespace is the same per line. This is incompatible with the
+ other modes.
+--
+
+`--no-color-moved-ws`::
+ Do not ignore whitespace when performing move detection. This can be
+ used to override configuration settings. It is the same as
+ `--color-moved-ws=no`.
+
+`--word-diff[=<mode>]`::
+ By default, words are delimited by whitespace; see
+ `--word-diff-regex` below. The _<mode>_ defaults to `plain`, and
+ must be one of:
++
+--
+`color`::
+ Highlight changed words using only colors. Implies `--color`.
+`plain`::
+ Show words as ++[-removed-]++ and ++{+added+}++. Makes no
+ attempts to escape the delimiters if they appear in the input,
+ so the output may be ambiguous.
+`porcelain`::
+ Use a special line-based format intended for script
+ consumption. Added/removed/unchanged runs are printed in the
+ usual unified diff format, starting with a `+`/`-`/` `
+ character at the beginning of the line and extending to the
+ end of the line. Newlines in the input are represented by a
+ tilde `~` on a line of its own.
+`none`::
+ Disable word diff again.
+--
++
+Note that despite the name of the first mode, color is used to
+highlight the changed parts in all modes if enabled.
+
+`--word-diff-regex=<regex>`::
+ Use _<regex>_ to decide what a word is, instead of considering
+ runs of non-whitespace to be a word. Also implies
+ `--word-diff` unless it was already enabled.
++
+Every non-overlapping match of the
+_<regex>_ is considered a word. Anything between these matches is
+considered whitespace and ignored(!) for the purposes of finding
+differences. You may want to append `|[^[:space:]]` to your regular
+expression to make sure that it matches all non-whitespace characters.
+A match that contains a newline is silently truncated(!) at the
+newline.
++
+For example, `--word-diff-regex=.` will treat each character as a word
+and, correspondingly, show differences character by character.
++
+The regex can also be set via a diff driver or configuration option, see
+linkgit:gitattributes[5] or linkgit:git-config[1]. Giving it explicitly
+overrides any diff driver or configuration setting. Diff drivers
+override configuration settings.
+
+`--color-words[=<regex>]`::
+ Equivalent to `--word-diff=color` plus (if a regex was
+ specified) `--word-diff-regex=<regex>`.
+endif::git-format-patch[]
+
+`--no-renames`::
+ Turn off rename detection, even when the configuration
+ file gives the default to do so.
+
+`--[no-]rename-empty`::
+ Whether to use empty blobs as rename source.
+
+ifndef::git-format-patch[]
+`--check`::
+ Warn if changes introduce conflict markers or whitespace errors.
+ What are considered whitespace errors is controlled by `core.whitespace`
+ configuration. By default, trailing whitespaces (including
+ lines that consist solely of whitespaces) and a space character
+ that is immediately followed by a tab character inside the
+ initial indent of the line are considered whitespace errors.
+ Exits with non-zero status if problems are found. Not compatible
+ with `--exit-code`.
+
+`--ws-error-highlight=<kind>`::
+ Highlight whitespace errors in the `context`, `old` or `new`
+ lines of the diff. Multiple values are separated by comma,
+ `none` resets previous values, `default` reset the list to
+ `new` and `all` is a shorthand for `old,new,context`. When
+ this option is not given, and the configuration variable
+ `diff.wsErrorHighlight` is not set, only whitespace errors in
+ `new` lines are highlighted. The whitespace errors are colored
+ with `color.diff.whitespace`.
+
+endif::git-format-patch[]
+
+`--full-index`::
+ Instead of the first handful of characters, show the full
+ pre- and post-image blob object names on the "index"
+ line when generating patch format output.
+
+`--binary`::
+ In addition to `--full-index`, output a binary diff that
+ can be applied with `git-apply`.
+ifndef::git-format-patch[]
+ Implies `--patch`.
+endif::git-format-patch[]
+
+`--abbrev[=<n>]`::
+ Instead of showing the full 40-byte hexadecimal object
+ name in diff-raw format output and diff-tree header
+ lines, show the shortest prefix that is at least _<n>_
+ hexdigits long that uniquely refers the object.
+ In diff-patch output format, `--full-index` takes higher
+ precedence, i.e. if `--full-index` is specified, full blob
+ names will be shown regardless of `--abbrev`.
+ Non default number of digits can be specified with `--abbrev=<n>`.
+
+`-B[<n>][/<m>]`::
+`--break-rewrites[=[<n>][/<m>]]`::
+ Break complete rewrite changes into pairs of delete and
+ create. This serves two purposes:
++
+It affects the way a change that amounts to a total rewrite of a file
+not as a series of deletion and insertion mixed together with a very
+few lines that happen to match textually as the context, but as a
+single deletion of everything old followed by a single insertion of
+everything new, and the number _<m>_ controls this aspect of the `-B`
+option (defaults to 60%). `-B/70%` specifies that less than 30% of the
+original should remain in the result for Git to consider it a total
+rewrite (i.e. otherwise the resulting patch will be a series of
+deletion and insertion mixed together with context lines).
++
+When used with `-M`, a totally-rewritten file is also considered as the
+source of a rename (usually `-M` only considers a file that disappeared
+as the source of a rename), and the number _<n>_ controls this aspect of
+the `-B` option (defaults to 50%). `-B20%` specifies that a change with
+addition and deletion compared to 20% or more of the file's size are
+eligible for being picked up as a possible source of a rename to
+another file.
+
+`-M[<n>]`::
+`--find-renames[=<n>]`::
+ifndef::git-log[]
+ Detect renames.
+endif::git-log[]
+ifdef::git-log[]
+ If generating diffs, detect and report renames for each commit.
+ For following files across renames while traversing history, see
+ `--follow`.
+endif::git-log[]
+ If _<n>_ is specified, it is a threshold on the similarity
+ 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. 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%`. The default similarity index is 50%.
+
+`-C[<n>]`::
+`--find-copies[=<n>]`::
+ Detect copies as well as renames. See also `--find-copies-harder`.
+ If _<n>_ is specified, it has the same meaning as for `-M<n>`.
+
+`--find-copies-harder`::
+ For performance reasons, by default, `-C` option finds copies only
+ if the original file of the copy was modified in the same
+ changeset. This flag makes the command
+ inspect unmodified files as candidates for the source of
+ copy. This is a very expensive operation for large
+ projects, so use it with caution. Giving more than one
+ `-C` option has the same effect.
+
+`-D`::
+`--irreversible-delete`::
+ Omit the preimage for deletes, i.e. print only the header but not
+ the diff between the preimage and `/dev/null`. The resulting patch
+ is not meant to be applied with `patch` or `git apply`; this is
+ solely for people who want to just concentrate on reviewing the
+ text after the change. In addition, the output obviously lacks
+ enough information to apply such a patch in reverse, even manually,
+ hence the name of the option.
++
+When used together with `-B`, omit also the preimage in the deletion part
+of a delete/create pair.
+
+`-l<num>`::
+ The `-M` and `-C` options involve some preliminary steps that
+ can detect subsets of renames/copies cheaply, followed by an
+ exhaustive fallback portion that compares all remaining
+ unpaired destinations to all relevant sources. (For renames,
+ only remaining unpaired sources are relevant; for copies, all
+ original sources are relevant.) For N sources and
+ destinations, this exhaustive check is O(N^2). This option
+ prevents the exhaustive portion of rename/copy detection from
+ running if the number of source/destination files involved
+ exceeds the specified number. Defaults to `diff.renameLimit`.
+ Note that a value of 0 is treated as unlimited.
+
+ifndef::git-format-patch[]
+`--diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]`::
+ Select only files that are Added (`A`), Copied (`C`),
+ Deleted (`D`), Modified (`M`), Renamed (`R`), have their
+ type (i.e. regular file, symlink, submodule, ...) changed (`T`),
+ are Unmerged (`U`), are
+ Unknown (`X`), or have had their pairing Broken (`B`).
+ Any combination of the filter characters (including none) can be used.
+ When `*` (All-or-none) is added to the combination, all
+ paths are selected if there is any file that matches
+ other criteria in the comparison; if there is no file
+ that matches other criteria, nothing is selected.
++
+Also, these upper-case letters can be downcased to exclude. E.g.
+`--diff-filter=ad` excludes added and deleted paths.
++
+Note that not all diffs can feature all types. For instance, copied and
+renamed entries cannot appear if detection for those types is disabled.
+
+`-S<string>`::
+ Look for differences that change the number of occurrences of
+ the specified _<string>_ (i.e. addition/deletion) in a file.
+ Intended for the scripter's use.
++
+It is useful when you're looking for an exact block of code (like a
+struct), and want to know the history of that block since it first
+came into being: use the feature iteratively to feed the interesting
+block in the preimage back into `-S`, and keep going until you get the
+very first version of the block.
++
+Binary files are searched as well.
+
+`-G<regex>`::
+ Look for differences whose patch text contains added/removed
+ lines that match _<regex>_.
++
+To illustrate the difference between `-S<regex>` `--pickaxe-regex` and
+`-G<regex>`, consider a commit with the following diff in the same
+file:
++
+----
++ return frotz(nitfol, two->ptr, 1, 0);
+...
+- hit = frotz(nitfol, mf2.ptr, 1, 0);
+----
++
+While `git log -G"frotz\(nitfol"` will show this commit, `git log
+-S"frotz\(nitfol" --pickaxe-regex` will not (because the number of
+occurrences of that string did not change).
++
+Unless `--text` is supplied patches of binary files without a textconv
+filter will be ignored.
++
+See the 'pickaxe' entry in linkgit:gitdiffcore[7] for more
+information.
+
+`--find-object=<object-id>`::
+ Look for differences that change the number of occurrences of
+ the specified object. Similar to `-S`, just the argument is different
+ in that it doesn't search for a specific string but for a specific
+ object id.
++
+The object can be a blob or a submodule commit. It implies the `-t` option in
+`git-log` to also find trees.
+
+`--pickaxe-all`::
+ When `-S` or `-G` finds a change, show all the changes in that
+ changeset, not just the files that contain the change
+ in _<string>_.
+
+`--pickaxe-regex`::
+ Treat the _<string>_ given to `-S` as an extended POSIX regular
+ expression to match.
+
+endif::git-format-patch[]
+
+`-O<orderfile>`::
+ Control the order in which files appear in the output.
+ This overrides the `diff.orderFile` configuration variable
+ (see linkgit:git-config[1]). To cancel `diff.orderFile`,
+ use `-O/dev/null`.
++
+The output order is determined by the order of glob patterns in
+_<orderfile>_.
+All files with pathnames that match the first pattern are output
+first, all files with pathnames that match the second pattern (but not
+the first) are output next, and so on.
+All files with pathnames that do not match any pattern are output
+last, as if there was an implicit match-all pattern at the end of the
+file.
+If multiple pathnames have the same rank (they match the same pattern
+but no earlier patterns), their output order relative to each other is
+the normal order.
++
+_<orderfile>_ is parsed as follows:
++
+--
+ - Blank lines are ignored, so they can be used as separators for
+ readability.
+
+ - Lines starting with a hash ("`#`") are ignored, so they can be used
+ for comments. Add a backslash ("`\`") to the beginning of the
+ pattern if it starts with a hash.
+
+ - Each other line contains a single pattern.
+--
++
+Patterns have the same syntax and semantics as patterns used for
+`fnmatch`(3) without the `FNM_PATHNAME` flag, except a pathname also
+matches a pattern if removing any number of the final pathname
+components matches the pattern. For example, the pattern "`foo*bar`"
+matches "`fooasdfbar`" and "`foo/bar/baz/asdf`" but not "`foobarx`".
+
+`--skip-to=<file>`::
+`--rotate-to=<file>`::
+ Discard the files before the named _<file>_ from the output
+ (i.e. 'skip to'), or move them to the end of the output
+ (i.e. 'rotate to'). These options were invented primarily for the use
+ of the `git difftool` command, and may not be very useful
+ otherwise.
+
+ifndef::git-format-patch[]
+`-R`::
+ Swap two inputs; that is, show differences from index or
+ on-disk file to tree contents.
+endif::git-format-patch[]
+
+`--relative[=<path>]`::
+`--no-relative`::
+ When run from a subdirectory of the project, it can be
+ told to exclude changes outside the directory and show
+ pathnames relative to it with this option. When you are
+ not in a subdirectory (e.g. in a bare repository), you
+ can name which subdirectory to make the output relative
+ to by giving a _<path>_ as an argument.
+ `--no-relative` can be used to countermand both `diff.relative` config
+ option and previous `--relative`.
+
+`-a`::
+`--text`::
+ Treat all files as text.
+
+`--ignore-cr-at-eol`::
+ Ignore carriage-return at the end of line when doing a comparison.
+
+`--ignore-space-at-eol`::
+ Ignore changes in whitespace at EOL.
+
+`-b`::
+`--ignore-space-change`::
+ Ignore changes in amount of whitespace. This ignores whitespace
+ at line end, and considers all other sequences of one or
+ more whitespace characters to be equivalent.
+
+`-w`::
+`--ignore-all-space`::
+ Ignore whitespace when comparing lines. This ignores
+ differences even if one line has whitespace where the other
+ line has none.
+
+`--ignore-blank-lines`::
+ Ignore changes whose lines are all blank.
+
+
+`-I<regex>`::
+`--ignore-matching-lines=<regex>`::
+ Ignore changes whose all lines match _<regex>_. This option may
+ be specified more than once.
+
+`--inter-hunk-context=<number>`::
+ Show the context between diff hunks, up to the specified _<number>_
+ of lines, thereby fusing hunks that are close to each other.
+ Defaults to `diff.interHunkContext` or 0 if the config option
+ is unset.
+
+`-W`::
+`--function-context`::
+ Show whole function as context lines for each change.
+ The function names are determined in the same way as
+ `git diff` works out patch hunk headers (see "Defining a
+ custom hunk-header" in linkgit:gitattributes[5]).
+
+ifndef::git-format-patch[]
+ifndef::git-log[]
+`--exit-code`::
+ Make the program exit with codes similar to `diff`(1).
+ That is, it exits with 1 if there were differences and
+ 0 means no differences.
+
+`--quiet`::
+ Disable all output of the program. Implies `--exit-code`.
+ Disables execution of external diff helpers whose exit code
+ is not trusted, i.e. their respective configuration option
+ `diff.trustExitCode` or ++diff.++__<driver>__++.trustExitCode++ or
+ environment variable `GIT_EXTERNAL_DIFF_TRUST_EXIT_CODE` is
+ false.
+endif::git-log[]
+endif::git-format-patch[]
+
+`--ext-diff`::
+ Allow an external diff helper to be executed. If you set an
+ external diff driver with linkgit:gitattributes[5], you need
+ to use this option with linkgit:git-log[1] and friends.
+
+`--no-ext-diff`::
+ Disallow external diff drivers.
+
+`--textconv`::
+`--no-textconv`::
+ Allow (or disallow) external text conversion filters to be run
+ when comparing binary files. See linkgit:gitattributes[5] for
+ details. Because textconv filters are typically a one-way
+ conversion, the resulting diff is suitable for human
+ consumption, but cannot be applied. For this reason, textconv
+ filters are enabled by default only for linkgit:git-diff[1] and
+ linkgit:git-log[1], but not for linkgit:git-format-patch[1] or
+ diff plumbing commands.
+
+
+`--ignore-submodules[=(none|untracked|dirty|all)]`::
+ Ignore changes to submodules in the diff generation. `all` is the default.
+ Using `none` will consider the submodule modified when it either contains
+ untracked or modified files or its `HEAD` differs from the commit recorded
+ in the superproject and can be used to override any settings of the
+ `ignore` option in linkgit:git-config[1] or linkgit:gitmodules[5]. When
+ `untracked` is used submodules are not considered dirty when they only
+ contain untracked content (but they are still scanned for modified
+ content). Using `dirty` ignores all changes to the work tree of submodules,
+ only changes to the commits stored in the superproject are shown (this was
+ the behavior until 1.7.0). Using `all` hides all changes to submodules.
+
+`--src-prefix=<prefix>`::
+ Show the given source _<prefix>_ instead of "a/".
+
+`--dst-prefix=<prefix>`::
+ Show the given destination _<prefix>_ instead of "b/".
+
+`--no-prefix`::
+ Do not show any source or destination prefix.
+
+`--default-prefix`::
+ Use the default source and destination prefixes ("a/" and "b/").
+ This overrides configuration variables such as `diff.noprefix`,
+ `diff.srcPrefix`, `diff.dstPrefix`, and `diff.mnemonicPrefix`
+ (see linkgit:git-config[1]).
+
+`--line-prefix=<prefix>`::
+ Prepend an additional _<prefix>_ to every line of output.
+
+`--ita-invisible-in-index`::
+ By default entries added by `git add -N` appear as an existing
+ empty file in `git diff` and a new file in `git diff --cached`.
+ This option makes the entry appear as a new file in `git diff`
+ and non-existent in `git diff --cached`. This option could be
+ reverted with `--ita-visible-in-index`. Both options are
+ experimental and could be removed in future.
+
+For more detailed explanation on these common options, see also
+linkgit:gitdiffcore[7].
diff --git a/fetch-options.adoc b/fetch-options.adoc
new file mode 100644
index 0000000..b01372e
--- /dev/null
+++ b/fetch-options.adoc
@@ -0,0 +1,331 @@
+--[no-]all::
+ Fetch all remotes, except for the ones that has the
+ `remote.<name>.skipFetchAll` configuration variable set.
+ This overrides the configuration variable fetch.all`.
+
+-a::
+--append::
+ Append ref names and object names of fetched refs to the
+ existing contents of `.git/FETCH_HEAD`. Without this
+ option old data in `.git/FETCH_HEAD` will be overwritten.
+
+--atomic::
+ Use an atomic transaction to update local refs. Either all refs are
+ updated, or on error, no refs are updated.
+
+--depth=<depth>::
+ Limit fetching to the specified number of commits from the tip of
+ each remote branch history. If fetching to a 'shallow' repository
+ created by `git clone` with `--depth=<depth>` option (see
+ linkgit:git-clone[1]), deepen or shorten the history to the specified
+ number of commits. Tags for the deepened commits are not fetched.
+
+--deepen=<depth>::
+ Similar to --depth, except it specifies the number of commits
+ from the current shallow boundary instead of from the tip of
+ each remote branch history.
+
+--shallow-since=<date>::
+ Deepen or shorten the history of a shallow repository to
+ include all reachable commits after <date>.
+
+--shallow-exclude=<ref>::
+ Deepen or shorten the history of a shallow repository to
+ exclude commits reachable from a specified remote branch or tag.
+ This option can be specified multiple times.
+
+--unshallow::
+ If the source repository is complete, convert a shallow
+ repository to a complete one, removing all the limitations
+ imposed by shallow repositories.
++
+If the source repository is shallow, fetch as much as possible so that
+the current repository has the same history as the source repository.
+
+--update-shallow::
+ By default when fetching from a shallow repository,
+ `git fetch` refuses refs that require updating
+ .git/shallow. This option updates .git/shallow and accepts such
+ refs.
+
+--negotiation-tip=<commit|glob>::
+ By default, Git will report, to the server, commits reachable
+ from all local refs to find common commits in an attempt to
+ reduce the size of the to-be-received packfile. If specified,
+ Git will only report commits reachable from the given tips.
+ This is useful to speed up fetches when the user knows which
+ local ref is likely to have commits in common with the
+ upstream ref being fetched.
++
+This option may be specified more than once; if so, Git will report
+commits reachable from any of the given commits.
++
+The argument to this option may be a glob on ref names, a ref, or the (possibly
+abbreviated) SHA-1 of a commit. Specifying a glob is equivalent to specifying
+this option multiple times, one for each matching ref name.
++
+See also the `fetch.negotiationAlgorithm` and `push.negotiate`
+configuration variables documented in linkgit:git-config[1], and the
+`--negotiate-only` option below.
+
+--negotiate-only::
+ Do not fetch anything from the server, and instead print the
+ ancestors of the provided `--negotiation-tip=*` arguments,
+ which we have in common with the server.
++
+This is incompatible with `--recurse-submodules=[yes|on-demand]`.
+Internally this is used to implement the `push.negotiate` option, see
+linkgit:git-config[1].
+
+--dry-run::
+ Show what would be done, without making any changes.
+
+--porcelain::
+ Print the output to standard output in an easy-to-parse format for
+ scripts. See section OUTPUT in linkgit:git-fetch[1] for details.
++
+This is incompatible with `--recurse-submodules=[yes|on-demand]` and takes
+precedence over the `fetch.output` config option.
+
+ifndef::git-pull[]
+--[no-]write-fetch-head::
+ Write the list of remote refs fetched in the `FETCH_HEAD`
+ file directly under `$GIT_DIR`. This is the default.
+ Passing `--no-write-fetch-head` from the command line tells
+ Git not to write the file. Under `--dry-run` option, the
+ file is never written.
+endif::git-pull[]
+
+-f::
+--force::
+ When 'git fetch' is used with `<src>:<dst>` refspec, it may
+ refuse to update the local branch as discussed
+ifdef::git-pull[]
+ in the `<refspec>` part of the linkgit:git-fetch[1]
+ documentation.
+endif::git-pull[]
+ifndef::git-pull[]
+ in the `<refspec>` part below.
+endif::git-pull[]
+ This option overrides that check.
+
+-k::
+--keep::
+ Keep downloaded pack.
+
+ifndef::git-pull[]
+--multiple::
+ Allow several <repository> and <group> arguments to be
+ specified. No <refspec>s may be specified.
+
+--[no-]auto-maintenance::
+--[no-]auto-gc::
+ Run `git maintenance run --auto` at the end to perform automatic
+ repository maintenance if needed. (`--[no-]auto-gc` is a synonym.)
+ This is enabled by default.
+
+--[no-]write-commit-graph::
+ Write a commit-graph after fetching. This overrides the config
+ setting `fetch.writeCommitGraph`.
+endif::git-pull[]
+
+--prefetch::
+ Modify the configured refspec to place all refs into the
+ `refs/prefetch/` namespace. See the `prefetch` task in
+ linkgit:git-maintenance[1].
+
+-p::
+--prune::
+ Before fetching, remove any remote-tracking references that no
+ longer exist on the remote. Tags are not subject to pruning
+ if they are fetched only because of the default tag
+ auto-following or due to a --tags option. However, if tags
+ are fetched due to an explicit refspec (either on the command
+ line or in the remote configuration, for example if the remote
+ was cloned with the --mirror option), then they are also
+ subject to pruning. Supplying `--prune-tags` is a shorthand for
+ providing the tag refspec.
+ifndef::git-pull[]
++
+See the PRUNING section below for more details.
+
+-P::
+--prune-tags::
+ Before fetching, remove any local tags that no longer exist on
+ the remote if `--prune` is enabled. This option should be used
+ more carefully, unlike `--prune` it will remove any local
+ references (local tags) that have been created. This option is
+ a shorthand for providing the explicit tag refspec along with
+ `--prune`, see the discussion about that in its documentation.
++
+See the PRUNING section below for more details.
+
+endif::git-pull[]
+
+ifndef::git-pull[]
+-n::
+endif::git-pull[]
+--no-tags::
+ By default, tags that point at objects that are downloaded
+ from the remote repository are fetched and stored locally.
+ This option disables this automatic tag following. The default
+ behavior for a remote may be specified with the remote.<name>.tagOpt
+ setting. See linkgit:git-config[1].
+
+ifndef::git-pull[]
+--refetch::
+ Instead of negotiating with the server to avoid transferring commits and
+ associated objects that are already present locally, this option fetches
+ all objects as a fresh clone would. Use this to reapply a partial clone
+ filter from configuration or using `--filter=` when the filter
+ definition has changed. Automatic post-fetch maintenance will perform
+ object database pack consolidation to remove any duplicate objects.
+endif::git-pull[]
+
+--refmap=<refspec>::
+ When fetching refs listed on the command line, use the
+ specified refspec (can be given more than once) to map the
+ refs to remote-tracking branches, instead of the values of
+ `remote.*.fetch` configuration variables for the remote
+ repository. Providing an empty `<refspec>` to the
+ `--refmap` option causes Git to ignore the configured
+ refspecs and rely entirely on the refspecs supplied as
+ command-line arguments. See section on "Configured Remote-tracking
+ Branches" for details.
+
+-t::
+--tags::
+ Fetch all tags from the remote (i.e., fetch remote tags
+ `refs/tags/*` into local tags with the same name), in addition
+ to whatever else would otherwise be fetched. Using this
+ option alone does not subject tags to pruning, even if --prune
+ is used (though tags may be pruned anyway if they are also the
+ destination of an explicit refspec; see `--prune`).
+
+ifndef::git-pull[]
+--recurse-submodules[=(yes|on-demand|no)]::
+ This option controls if and under what conditions new commits of
+ submodules should be fetched too. When recursing through submodules,
+ `git fetch` always attempts to fetch "changed" submodules, that is, a
+ submodule that has commits that are referenced by a newly fetched
+ superproject commit but are missing in the local submodule clone. A
+ changed submodule can be fetched as long as it is present locally e.g.
+ in `$GIT_DIR/modules/` (see linkgit:gitsubmodules[7]); if the upstream
+ adds a new submodule, that submodule cannot be fetched until it is
+ cloned e.g. by `git submodule update`.
++
+When set to 'on-demand', only changed submodules are fetched. When set
+to 'yes', all populated submodules are fetched and submodules that are
+both unpopulated and changed are fetched. When set to 'no', submodules
+are never fetched.
++
+When unspecified, this uses the value of `fetch.recurseSubmodules` if it
+is set (see linkgit:git-config[1]), defaulting to 'on-demand' if unset.
+When this option is used without any value, it defaults to 'yes'.
+endif::git-pull[]
+
+-j::
+--jobs=<n>::
+ Number of parallel children to be used for all forms of fetching.
++
+If the `--multiple` option was specified, the different remotes will be fetched
+in parallel. If multiple submodules are fetched, they will be fetched in
+parallel. To control them independently, use the config settings
+`fetch.parallel` and `submodule.fetchJobs` (see linkgit:git-config[1]).
++
+Typically, parallel recursive and multi-remote fetches will be faster. By
+default fetches are performed sequentially, not in parallel.
+
+ifndef::git-pull[]
+--no-recurse-submodules::
+ Disable recursive fetching of submodules (this has the same effect as
+ using the `--recurse-submodules=no` option).
+endif::git-pull[]
+
+--set-upstream::
+ If the remote is fetched successfully, add upstream
+ (tracking) reference, used by argument-less
+ linkgit:git-pull[1] and other commands. For more information,
+ see `branch.<name>.merge` and `branch.<name>.remote` in
+ linkgit:git-config[1].
+
+ifndef::git-pull[]
+--submodule-prefix=<path>::
+ Prepend <path> to paths printed in informative messages
+ such as "Fetching submodule foo". This option is used
+ internally when recursing over submodules.
+
+--recurse-submodules-default=[yes|on-demand]::
+ This option is used internally to temporarily provide a
+ non-negative default value for the --recurse-submodules
+ option. All other methods of configuring fetch's submodule
+ recursion (such as settings in linkgit:gitmodules[5] and
+ linkgit:git-config[1]) override this option, as does
+ specifying --[no-]recurse-submodules directly.
+
+-u::
+--update-head-ok::
+ By default 'git fetch' refuses to update the head which
+ corresponds to the current branch. This flag disables the
+ check. This is purely for the internal use for 'git pull'
+ to communicate with 'git fetch', and unless you are
+ implementing your own Porcelain you are not supposed to
+ use it.
+endif::git-pull[]
+
+--upload-pack <upload-pack>::
+ When given, and the repository to fetch from is handled
+ by 'git fetch-pack', `--exec=<upload-pack>` is passed to
+ the command to specify non-default path for the command
+ run on the other end.
+
+ifndef::git-pull[]
+-q::
+--quiet::
+ Pass --quiet to git-fetch-pack and silence any other internally
+ used git commands. Progress is not reported to the standard error
+ stream.
+
+-v::
+--verbose::
+ Be verbose.
+endif::git-pull[]
+
+--progress::
+ Progress status is reported on the standard error stream
+ by default when it is attached to a terminal, unless -q
+ is specified. This flag forces progress status even if the
+ standard error stream is not directed to a terminal.
+
+-o <option>::
+--server-option=<option>::
+ Transmit the given string to the server when communicating using
+ protocol version 2. The given string must not contain a NUL or LF
+ character. The server's handling of server options, including
+ unknown ones, is server-specific.
+ When multiple `--server-option=<option>` are given, they are all
+ sent to the other side in the order listed on the command line.
+ When no `--server-option=<option>` is given from the command line,
+ the values of configuration variable `remote.<name>.serverOption`
+ are used instead.
+
+--show-forced-updates::
+ By default, git checks if a branch is force-updated during
+ fetch. This can be disabled through fetch.showForcedUpdates, but
+ the --show-forced-updates option guarantees this check occurs.
+ See linkgit:git-config[1].
+
+--no-show-forced-updates::
+ By default, git checks if a branch is force-updated during
+ fetch. Pass --no-show-forced-updates or set fetch.showForcedUpdates
+ to false to skip this check for performance reasons. If used during
+ 'git-pull' the --ff-only option will still check for forced updates
+ before attempting a fast-forward update. See linkgit:git-config[1].
+
+-4::
+--ipv4::
+ Use IPv4 addresses only, ignoring IPv6 addresses.
+
+-6::
+--ipv6::
+ Use IPv6 addresses only, ignoring IPv4 addresses.
diff --git a/fsck-msgids.adoc b/fsck-msgids.adoc
new file mode 100644
index 0000000..b14bc44
--- /dev/null
+++ b/fsck-msgids.adoc
@@ -0,0 +1,221 @@
+`badDate`::
+ (ERROR) Invalid date format in an author/committer line.
+
+`badDateOverflow`::
+ (ERROR) Invalid date value in an author/committer line.
+
+`badEmail`::
+ (ERROR) Invalid email format in an author/committer line.
+
+`badFilemode`::
+ (INFO) A tree contains a bad filemode entry.
+
+`badName`::
+ (ERROR) An author/committer name is empty.
+
+`badObjectSha1`::
+ (ERROR) An object has a bad sha1.
+
+`badParentSha1`::
+ (ERROR) A commit object has a bad parent sha1.
+
+`badRefContent`::
+ (ERROR) A ref has bad content.
+
+`badRefFiletype`::
+ (ERROR) A ref has a bad file type.
+
+`badRefName`::
+ (ERROR) A ref has an invalid format.
+
+`badReferentName`::
+ (ERROR) The referent name of a symref is invalid.
+
+`badTagName`::
+ (INFO) A tag has an invalid format.
+
+`badTimezone`::
+ (ERROR) Found an invalid time zone in an author/committer line.
+
+`badTree`::
+ (ERROR) A tree cannot be parsed.
+
+`badTreeSha1`::
+ (ERROR) A tree has an invalid format.
+
+`badType`::
+ (ERROR) Found an invalid object type.
+
+`duplicateEntries`::
+ (ERROR) A tree contains duplicate file entries.
+
+`emptyName`::
+ (WARN) A path contains an empty name.
+
+`extraHeaderEntry`::
+ (IGNORE) Extra headers found after `tagger`.
+
+`fullPathname`::
+ (WARN) A path contains the full path starting with "/".
+
+`gitattributesBlob`::
+ (ERROR) A non-blob found at `.gitattributes`.
+
+`gitattributesLarge`::
+ (ERROR) The `.gitattributes` blob is too large.
+
+`gitattributesLineLength`::
+ (ERROR) The `.gitattributes` blob contains too long lines.
+
+`gitattributesMissing`::
+ (ERROR) Unable to read `.gitattributes` blob.
+
+`gitattributesSymlink`::
+ (INFO) `.gitattributes` is a symlink.
+
+`gitignoreSymlink`::
+ (INFO) `.gitignore` is a symlink.
+
+`gitmodulesBlob`::
+ (ERROR) A non-blob found at `.gitmodules`.
+
+`gitmodulesLarge`::
+ (ERROR) The `.gitmodules` file is too large to parse.
+
+`gitmodulesMissing`::
+ (ERROR) Unable to read `.gitmodules` blob.
+
+`gitmodulesName`::
+ (ERROR) A submodule name is invalid.
+
+`gitmodulesParse`::
+ (INFO) Could not parse `.gitmodules` blob.
+
+`gitmodulesLarge`;
+ (ERROR) `.gitmodules` blob is too large to parse.
+
+`gitmodulesPath`::
+ (ERROR) `.gitmodules` path is invalid.
+
+`gitmodulesSymlink`::
+ (ERROR) `.gitmodules` is a symlink.
+
+`gitmodulesUpdate`::
+ (ERROR) Found an invalid submodule update setting.
+
+`gitmodulesUrl`::
+ (ERROR) Found an invalid submodule url.
+
+`hasDot`::
+ (WARN) A tree contains an entry named `.`.
+
+`hasDotdot`::
+ (WARN) A tree contains an entry named `..`.
+
+`hasDotgit`::
+ (WARN) A tree contains an entry named `.git`.
+
+`largePathname`::
+ (WARN) A tree contains an entry with a very long path name. If
+ the value of `fsck.largePathname` contains a colon, that value
+ is used as the maximum allowable length (e.g., "warn:10" would
+ complain about any path component of 11 or more bytes). The
+ default value is 4096.
+
+`mailmapSymlink`::
+ (INFO) `.mailmap` is a symlink.
+
+`missingAuthor`::
+ (ERROR) Author is missing.
+
+`missingCommitter`::
+ (ERROR) Committer is missing.
+
+`missingEmail`::
+ (ERROR) Email is missing in an author/committer line.
+
+`missingNameBeforeEmail`::
+ (ERROR) Missing name before an email in an author/committer line.
+
+`missingObject`::
+ (ERROR) Missing `object` line in tag object.
+
+`missingSpaceBeforeDate`::
+ (ERROR) Missing space before date in an author/committer line.
+
+`missingSpaceBeforeEmail`::
+ (ERROR) Missing space before the email in an author/committer line.
+
+`missingTag`::
+ (ERROR) Unexpected end after `type` line in a tag object.
+
+`missingTagEntry`::
+ (ERROR) Missing `tag` line in a tag object.
+
+`missingTaggerEntry`::
+ (INFO) Missing `tagger` line in a tag object.
+
+`missingTree`::
+ (ERROR) Missing `tree` line in a commit object.
+
+`missingType`::
+ (ERROR) Invalid type value on the `type` line in a tag object.
+
+`missingTypeEntry`::
+ (ERROR) Missing `type` line in a tag object.
+
+`multipleAuthors`::
+ (ERROR) Multiple author lines found in a commit.
+
+`nulInCommit`::
+ (WARN) Found a NUL byte in the commit object body.
+
+`nulInHeader`::
+ (FATAL) NUL byte exists in the object header.
+
+`nullSha1`::
+ (WARN) Tree contains entries pointing to a null sha1.
+
+`refMissingNewline`::
+ (INFO) A loose ref that does not end with newline(LF). As
+ valid implementations of Git never created such a loose ref
+ file, it may become an error in the future. Report to the
+ git@vger.kernel.org mailing list if you see this error, as
+ we need to know what tools created such a file.
+
+`symlinkRef`::
+ (INFO) A symbolic link is used as a symref. Report to the
+ git@vger.kernel.org mailing list if you see this error, as we
+ are assessing the feasibility of dropping the support to drop
+ creating symbolic links as symrefs.
+
+`symrefTargetIsNotARef`::
+ (INFO) The target of a symbolic reference points neither to
+ a root reference nor to a reference starting with "refs/".
+ Although we allow create a symref pointing to the referent which
+ is outside the "ref" by using `git symbolic-ref`, we may tighten
+ the rule in the future. Report to the git@vger.kernel.org
+ mailing list if you see this error, as we need to know what tools
+ created such a file.
+
+`trailingRefContent`::
+ (INFO) A loose ref has trailing content. As valid implementations
+ of Git never created such a loose ref file, it may become an
+ error in the future. Report to the git@vger.kernel.org mailing
+ list if you see this error, as we need to know what tools
+ created such a file.
+
+`treeNotSorted`::
+ (ERROR) A tree is not properly sorted.
+
+`unknownType`::
+ (ERROR) Found an unknown object type.
+
+`unterminatedHeader`::
+ (FATAL) Missing end-of-line in the object header.
+
+`zeroPaddedDate`::
+ (ERROR) Found a zero padded date in an author/committer line.
+
+`zeroPaddedFilemode`::
+ (WARN) Found a zero padded filemode in a tree.
diff --git a/git-add.adoc b/git-add.adoc
new file mode 100644
index 0000000..eba0b41
--- /dev/null
+++ b/git-add.adoc
@@ -0,0 +1,456 @@
+git-add(1)
+==========
+
+NAME
+----
+git-add - Add file contents to the index
+
+SYNOPSIS
+--------
+[synopsis]
+git add [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p]
+ [--edit | -e] [--[no-]all | -A | --[no-]ignore-removal | [--update | -u]] [--sparse]
+ [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--renormalize]
+ [--chmod=(+|-)x] [--pathspec-from-file=<file> [--pathspec-file-nul]]
+ [--] [<pathspec>...]
+
+DESCRIPTION
+-----------
+This command updates the index using the current content found in
+the working tree, to prepare the content staged for the next commit.
+It typically adds the current content of existing paths as a whole,
+but with some options it can also be used to add content with
+only part of the changes made to the working tree files applied, or
+remove paths that do not exist in the working tree anymore.
+
+The "index" holds a snapshot of the content of the working tree, and it
+is this snapshot that is taken as the contents of the next commit. Thus
+after making any changes to the working tree, and before running
+the commit command, you must use the `add` command to add any new or
+modified files to the index.
+
+This command can be performed multiple times before a commit. It only
+adds the content of the specified file(s) at the time the add command is
+run; if you want subsequent changes included in the next commit, then
+you must run `git add` again to add the new content to the index.
+
+The `git status` command can be used to obtain a summary of which
+files have changes that are staged for the next commit.
+
+The `git add` command will not add ignored files by default. If any
+ignored files were explicitly specified on the command line, `git add`
+will fail with a list of ignored files. Ignored files reached by
+directory recursion or filename globbing performed by Git (quote your
+globs before the shell) will be silently ignored. The `git add` command can
+be used to add ignored files with the `-f` (force) option.
+
+Please see linkgit:git-commit[1] for alternative ways to add content to a
+commit.
+
+
+OPTIONS
+-------
+`<pathspec>...`::
+ Files to add content from. Fileglobs (e.g. `*.c`) can
+ be given to add all matching files. Also a
+ leading directory name (e.g. `dir` to add `dir/file1`
+ and `dir/file2`) can be given to update the index to
+ match the current state of the directory as a whole (e.g.
+ specifying `dir` will record not just a file `dir/file1`
+ modified in the working tree, a file `dir/file2` added to
+ the working tree, but also a file `dir/file3` removed from
+ the working tree). Note that older versions of Git used
+ to ignore removed files; use `--no-all` option if you want
+ to add modified or new files but ignore removed ones.
++
+For more details about the _<pathspec>_ syntax, see the 'pathspec' entry
+in linkgit:gitglossary[7].
+
+`-n`::
+`--dry-run`::
+ Don't actually add the file(s), just show if they exist and/or will
+ be ignored.
+
+`-v`::
+`--verbose`::
+ Be verbose.
+
+`-f`::
+`--force`::
+ Allow adding otherwise ignored files.
+
+`--sparse`::
+ Allow updating index entries outside of the sparse-checkout cone.
+ Normally, `git add` refuses to update index entries whose paths do
+ not fit within the sparse-checkout cone, since those files might
+ be removed from the working tree without warning. See
+ linkgit:git-sparse-checkout[1] for more details.
+
+`-i`::
+`--interactive`::
+ Add modified contents in the working tree interactively to
+ the index. Optional path arguments may be supplied to limit
+ operation to a subset of the working tree. See ``Interactive
+ mode'' for details.
+
+`-p`::
+`--patch`::
+ Interactively choose hunks of patch between the index and the
+ work tree and add them to the index. This gives the user a chance
+ to review the difference before adding modified contents to the
+ index.
++
+This effectively runs `add --interactive`, but bypasses the
+initial command menu and directly jumps to the `patch` subcommand.
+See ``Interactive mode'' for details.
+
+`-e`::
+`--edit`::
+ Open the diff vs. the index in an editor and let the user
+ edit it. After the editor was closed, adjust the hunk headers
+ and apply the patch to the index.
++
+The intent of this option is to pick and choose lines of the patch to
+apply, or even to modify the contents of lines to be staged. This can be
+quicker and more flexible than using the interactive hunk selector.
+However, it is easy to confuse oneself and create a patch that does not
+apply to the index. See EDITING PATCHES below.
+
+`-u`::
+`--update`::
+ Update the index just where it already has an entry matching
+ _<pathspec>_. This removes as well as modifies index entries to
+ match the working tree, but adds no new files.
++
+If no _<pathspec>_ is given when `-u` option is used, all
+tracked files in the entire working tree are updated (old versions
+of Git used to limit the update to the current directory and its
+subdirectories).
+
+`-A`::
+`--all`::
+`--no-ignore-removal`::
+ Update the index not only where the working tree has a file
+ matching _<pathspec>_ but also where the index already has an
+ entry. This adds, modifies, and removes index entries to
+ match the working tree.
++
+If no _<pathspec>_ is given when `-A` option is used, all
+files in the entire working tree are updated (old versions
+of Git used to limit the update to the current directory and its
+subdirectories).
+
+`--no-all`::
+`--ignore-removal`::
+ Update the index by adding new files that are unknown to the
+ index and files modified in the working tree, but ignore
+ files that have been removed from the working tree. This
+ option is a no-op when no _<pathspec>_ is used.
++
+This option is primarily to help users who are used to older
+versions of Git, whose `git add <pathspec>...` was a synonym
+for `git add --no-all <pathspec>...`, i.e. ignored removed files.
+
+`-N`::
+`--intent-to-add`::
+ Record only the fact that the path will be added later. An entry
+ for the path is placed in the index with no content. This is
+ useful for, among other things, showing the unstaged content of
+ such files with `git diff` and committing them with `git commit
+ -a`.
+
+`--refresh`::
+ Don't add the file(s), but only refresh their stat()
+ information in the index.
+
+`--ignore-errors`::
+ If some files could not be added because of errors indexing
+ them, do not abort the operation, but continue adding the
+ others. The command shall still exit with non-zero status.
+ The configuration variable `add.ignoreErrors` can be set to
+ true to make this the default behaviour.
+
+`--ignore-missing`::
+ This option can only be used together with `--dry-run`. By using
+ this option the user can check if any of the given files would
+ be ignored, no matter if they are already present in the work
+ tree or not.
+
+`--no-warn-embedded-repo`::
+ By default, `git add` will warn when adding an embedded
+ repository to the index without using `git submodule add` to
+ create an entry in `.gitmodules`. This option will suppress the
+ warning (e.g., if you are manually performing operations on
+ submodules).
+
+`--renormalize`::
+ Apply the "clean" process freshly to all tracked files to
+ forcibly add them again to the index. This is useful after
+ changing `core.autocrlf` configuration or the `text` attribute
+ in order to correct files added with wrong _CRLF/LF_ line endings.
+ This option implies `-u`. Lone CR characters are untouched, thus
+ while a _CRLF_ cleans to _LF_, a _CRCRLF_ sequence is only partially
+ cleaned to _CRLF_.
+
+`--chmod=(+|-)x`::
+ Override the executable bit of the added files. The executable
+ bit is only changed in the index, the files on disk are left
+ unchanged.
+
+`--pathspec-from-file=<file>`::
+ Pathspec is passed in _<file>_ instead of commandline args. If
+ _<file>_ is exactly `-` then standard input is used. Pathspec
+ elements are separated by _LF_ or _CR/LF_. Pathspec elements can be
+ quoted as explained for the configuration variable `core.quotePath`
+ (see linkgit:git-config[1]). See also `--pathspec-file-nul` and
+ global `--literal-pathspecs`.
+
+`--pathspec-file-nul`::
+ Only meaningful with `--pathspec-from-file`. Pathspec elements are
+ separated with _NUL_ character and all other characters are taken
+ literally (including newlines and quotes).
+
+`--`::
+ This option can be used to separate command-line options from
+ the list of files, (useful when filenames might be mistaken
+ for command-line options).
+
+
+EXAMPLES
+--------
+
+* Adds content from all ++*.txt++ files under `Documentation` directory
+ and its subdirectories:
++
+------------
+$ git add Documentation/\*.txt
+------------
++
+Note that the asterisk ++*++ is quoted from the shell in this
+example; this lets the command include the files from
+subdirectories of `Documentation/` directory.
+
+* Considers adding content from all ++git-*.sh++ scripts:
++
+------------
+$ git add git-*.sh
+------------
++
+Because this example lets the shell expand the asterisk (i.e. you are
+listing the files explicitly), it does not consider
+`subdir/git-foo.sh`.
+
+INTERACTIVE MODE
+----------------
+When the command enters the interactive mode, it shows the
+output of the 'status' subcommand, and then goes into its
+interactive command loop.
+
+The command loop shows the list of subcommands available, and
+gives a prompt "What now> ". In general, when the prompt ends
+with a single '>', you can pick only one of the choices given
+and type return, like this:
+
+------------
+ *** Commands ***
+ 1: status 2: update 3: revert 4: add untracked
+ 5: patch 6: diff 7: quit 8: help
+ What now> 1
+------------
+
+You also could say `s` or `sta` or `status` above as long as the
+choice is unique.
+
+The main command loop has 6 subcommands (plus help and quit).
+
+status::
+
+ This shows the change between `HEAD` and index (i.e. what will be
+ committed if you say `git commit`), and between index and
+ working tree files (i.e. what you could stage further before
+ `git commit` using `git add`) for each path. A sample output
+ looks like this:
++
+------------
+ staged unstaged path
+ 1: binary nothing foo.png
+ 2: +403/-35 +1/-1 add-interactive.c
+------------
++
+It shows that `foo.png` has differences from `HEAD` (but that is
+binary so line count cannot be shown) and there is no
+difference between indexed copy and the working tree
+version (if the working tree version were also different,
+'binary' would have been shown in place of 'nothing'). The
+other file, `add-interactive.c`, has 403 lines added
+and 35 lines deleted if you commit what is in the index, but
+working tree file has further modifications (one addition and
+one deletion).
+
+update::
+
+ This shows the status information and issues an "Update>>"
+ prompt. When the prompt ends with double '>>', you can
+ make more than one selection, concatenated with whitespace or
+ comma. Also you can say ranges. E.g. "2-5 7,9" to choose
+ 2,3,4,5,7,9 from the list. If the second number in a range is
+ omitted, all remaining patches are taken. E.g. "7-" to choose
+ 7,8,9 from the list. You can say '*' to choose everything.
++
+What you chose are then highlighted with '*',
+like this:
++
+------------
+ staged unstaged path
+ 1: binary nothing foo.png
+* 2: +403/-35 +1/-1 add-interactive.c
+------------
++
+To remove selection, prefix the input with `-`
+like this:
++
+------------
+Update>> -2
+------------
++
+After making the selection, answer with an empty line to stage the
+contents of working tree files for selected paths in the index.
+
+revert::
+
+ This has a very similar UI to 'update', and the staged
+ information for selected paths are reverted to that of the
+ HEAD version. Reverting new paths makes them untracked.
+
+add untracked::
+
+ This has a very similar UI to 'update' and
+ 'revert', and lets you add untracked paths to the index.
+
+patch::
+
+ This lets you choose one path out of a 'status' like selection.
+ After choosing the path, it presents the diff between the index
+ and the working tree file and asks you if you want to stage
+ the change of each hunk. You can select one of the following
+ options and type return:
+
+ y - stage this hunk
+ n - do not stage this hunk
+ q - quit; do not stage this hunk or any of the remaining ones
+ a - stage this hunk and all later hunks in the file
+ d - do not stage this hunk or any of the later hunks in the file
+ g - select a hunk to go to
+ / - search for a hunk matching the given regex
+ j - leave this hunk undecided, see next undecided hunk
+ J - leave this hunk undecided, see next hunk
+ k - leave this hunk undecided, see previous undecided hunk
+ K - leave this hunk undecided, see previous hunk
+ s - split the current hunk into smaller hunks
+ e - manually edit the current hunk
+ p - print the current hunk
+ ? - print help
++
+After deciding the fate for all hunks, if there is any hunk
+that was chosen, the index is updated with the selected hunks.
++
+You can omit having to type return here, by setting the configuration
+variable `interactive.singleKey` to `true`.
+
+diff::
+
+ This lets you review what will be committed (i.e. between
+ `HEAD` and index).
+
+
+EDITING PATCHES
+---------------
+
+Invoking `git add -e` or selecting `e` from the interactive hunk
+selector will open a patch in your editor; after the editor exits, the
+result is applied to the index. You are free to make arbitrary changes
+to the patch, but note that some changes may have confusing results, or
+even result in a patch that cannot be applied. If you want to abort the
+operation entirely (i.e., stage nothing new in the index), simply delete
+all lines of the patch. The list below describes some common things you
+may see in a patch, and which editing operations make sense on them.
+
+--
+added content::
+
+Added content is represented by lines beginning with "{plus}". You can
+prevent staging any addition lines by deleting them.
+
+removed content::
+
+Removed content is represented by lines beginning with "-". You can
+prevent staging their removal by converting the "-" to a " " (space).
+
+modified content::
+
+Modified content is represented by "-" lines (removing the old content)
+followed by "{plus}" lines (adding the replacement content). You can
+prevent staging the modification by converting "-" lines to " ", and
+removing "{plus}" lines. Beware that modifying only half of the pair is
+likely to introduce confusing changes to the index.
+--
+
+There are also more complex operations that can be performed. But beware
+that because the patch is applied only to the index and not the working
+tree, the working tree will appear to "undo" the change in the index.
+For example, introducing a new line into the index that is in neither
+the `HEAD` nor the working tree will stage the new line for commit, but
+the line will appear to be reverted in the working tree.
+
+Avoid using these constructs, or do so with extreme caution.
+
+--
+removing untouched content::
+
+Content which does not differ between the index and working tree may be
+shown on context lines, beginning with a " " (space). You can stage
+context lines for removal by converting the space to a "-". The
+resulting working tree file will appear to re-add the content.
+
+modifying existing content::
+
+One can also modify context lines by staging them for removal (by
+converting " " to "-") and adding a "{plus}" line with the new content.
+Similarly, one can modify "{plus}" lines for existing additions or
+modifications. In all cases, the new modification will appear reverted
+in the working tree.
+
+new content::
+
+You may also add new content that does not exist in the patch; simply
+add new lines, each starting with "{plus}". The addition will appear
+reverted in the working tree.
+--
+
+There are also several operations which should be avoided entirely, as
+they will make the patch impossible to apply:
+
+* adding context (" ") or removal ("-") lines
+* deleting context or removal lines
+* modifying the contents of context or removal lines
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+:git-add: 1
+include::config/add.adoc[]
+
+SEE ALSO
+--------
+linkgit:git-status[1]
+linkgit:git-rm[1]
+linkgit:git-reset[1]
+linkgit:git-mv[1]
+linkgit:git-commit[1]
+linkgit:git-update-index[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-am.adoc b/git-am.adoc
new file mode 100644
index 0000000..221070d
--- /dev/null
+++ b/git-am.adoc
@@ -0,0 +1,298 @@
+git-am(1)
+=========
+
+NAME
+----
+git-am - Apply a series of patches from a mailbox
+
+
+SYNOPSIS
+--------
+[verse]
+'git am' [--signoff] [--keep] [--[no-]keep-cr] [--[no-]utf8] [--no-verify]
+ [--[no-]3way] [--interactive] [--committer-date-is-author-date]
+ [--ignore-date] [--ignore-space-change | --ignore-whitespace]
+ [--whitespace=<action>] [-C<n>] [-p<n>] [--directory=<dir>]
+ [--exclude=<path>] [--include=<path>] [--reject] [-q | --quiet]
+ [--[no-]scissors] [-S[<keyid>]] [--patch-format=<format>]
+ [--quoted-cr=<action>]
+ [--empty=(stop|drop|keep)]
+ [(<mbox> | <Maildir>)...]
+'git am' (--continue | --skip | --abort | --quit | --retry | --show-current-patch[=(diff|raw)] | --allow-empty)
+
+DESCRIPTION
+-----------
+Splits mail messages in a mailbox into commit log messages,
+authorship information, and patches, and applies them to the
+current branch. You could think of it as a reverse operation
+of linkgit:git-format-patch[1] run on a branch with a straight
+history without merges.
+
+OPTIONS
+-------
+(<mbox>|<Maildir>)...::
+ The list of mailbox files to read patches from. If you do not
+ supply this argument, the command reads from the standard input.
+ If you supply directories, they will be treated as Maildirs.
+
+-s::
+--signoff::
+ Add a `Signed-off-by` trailer to the commit message, using
+ the committer identity of yourself.
+ See the signoff option in linkgit:git-commit[1] for more information.
+
+-k::
+--keep::
+ Pass `-k` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).
+
+--keep-non-patch::
+ Pass `-b` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).
+
+--[no-]keep-cr::
+ With `--keep-cr`, call 'git mailsplit' (see linkgit:git-mailsplit[1])
+ with the same option, to prevent it from stripping CR at the end of
+ lines. `am.keepcr` configuration variable can be used to specify the
+ default behaviour. `--no-keep-cr` is useful to override `am.keepcr`.
+
+-c::
+--scissors::
+ Remove everything in body before a scissors line (see
+ linkgit:git-mailinfo[1]). Can be activated by default using
+ the `mailinfo.scissors` configuration variable.
+
+--no-scissors::
+ Ignore scissors lines (see linkgit:git-mailinfo[1]).
+
+--quoted-cr=<action>::
+ This flag will be passed down to 'git mailinfo' (see linkgit:git-mailinfo[1]).
+
+--empty=(drop|keep|stop)::
+ How to handle an e-mail message lacking a patch:
++
+--
+`drop`;;
+ The e-mail message will be skipped.
+`keep`;;
+ An empty commit will be created, with the contents of the e-mail
+ message as its log.
+`stop`;;
+ The command will fail, stopping in the middle of the current `am`
+ session. This is the default behavior.
+--
+
+-m::
+--message-id::
+ Pass the `-m` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]),
+ so that the Message-ID header is added to the commit message.
+ The `am.messageid` configuration variable can be used to specify
+ the default behaviour.
+
+--no-message-id::
+ Do not add the Message-ID header to the commit message.
+ `no-message-id` is useful to override `am.messageid`.
+
+-q::
+--quiet::
+ Be quiet. Only print error messages.
+
+-u::
+--utf8::
+ Pass `-u` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).
+ The proposed commit log message taken from the e-mail
+ is re-coded into UTF-8 encoding (configuration variable
+ `i18n.commitEncoding` can be used to specify the project's
+ preferred encoding if it is not UTF-8).
++
+This was optional in prior versions of git, but now it is the
+default. You can use `--no-utf8` to override this.
+
+--no-utf8::
+ Pass `-n` flag to 'git mailinfo' (see
+ linkgit:git-mailinfo[1]).
+
+-3::
+--3way::
+--no-3way::
+ When the patch does not apply cleanly, fall back on
+ 3-way merge if the patch records the identity of blobs
+ it is supposed to apply to and we have those blobs
+ available locally. `--no-3way` can be used to override
+ am.threeWay configuration variable. For more information,
+ see am.threeWay in linkgit:git-config[1].
+
+include::rerere-options.adoc[]
+
+--ignore-space-change::
+--ignore-whitespace::
+--whitespace=<action>::
+-C<n>::
+-p<n>::
+--directory=<dir>::
+--exclude=<path>::
+--include=<path>::
+--reject::
+ These flags are passed to the 'git apply' (see linkgit:git-apply[1])
+ program that applies
+ the patch.
++
+Valid <action> for the `--whitespace` option are:
+`nowarn`, `warn`, `fix`, `error`, and `error-all`.
+
+--patch-format::
+ By default the command will try to detect the patch format
+ automatically. This option allows the user to bypass the automatic
+ detection and specify the patch format that the patch(es) should be
+ interpreted as. Valid formats are mbox, mboxrd,
+ stgit, stgit-series, and hg.
+
+-i::
+--interactive::
+ Run interactively.
+
+-n::
+--no-verify::
+ By default, the pre-applypatch and applypatch-msg hooks are run.
+ When any of `--no-verify` or `-n` is given, these are bypassed.
+ See also linkgit:githooks[5].
+
+--committer-date-is-author-date::
+ By default the command records the date from the e-mail
+ message as the commit author date, and uses the time of
+ commit creation as the committer date. This allows the
+ user to lie about the committer date by using the same
+ value as the author date.
+
+--ignore-date::
+ By default the command records the date from the e-mail
+ message as the commit author date, and uses the time of
+ commit creation as the committer date. This allows the
+ user to lie about the author date by using the same
+ value as the committer date.
+
+--skip::
+ Skip the current patch. This is only meaningful when
+ restarting an aborted patch.
+
+-S[<keyid>]::
+--gpg-sign[=<keyid>]::
+--no-gpg-sign::
+ GPG-sign commits. The `keyid` argument is optional and
+ defaults to the committer identity; if specified, it must be
+ stuck to the option without a space. `--no-gpg-sign` is useful to
+ countermand both `commit.gpgSign` configuration variable, and
+ earlier `--gpg-sign`.
+
+--continue::
+-r::
+--resolved::
+ After a patch failure (e.g. attempting to apply
+ conflicting patch), the user has applied it by hand and
+ the index file stores the result of the application.
+ Make a commit using the authorship and commit log
+ extracted from the e-mail message and the current index
+ file, and continue.
+
+--resolvemsg=<msg>::
+ When a patch failure occurs, <msg> will be printed
+ to the screen before exiting. This overrides the
+ standard message informing you to use `--continue`
+ or `--skip` to handle the failure. This is solely
+ for internal use between 'git rebase' and 'git am'.
+
+--abort::
+ Restore the original branch and abort the patching operation.
+ Revert the contents of files involved in the am operation to their
+ pre-am state.
+
+--quit::
+ Abort the patching operation but keep HEAD and the index
+ untouched.
+
+--retry::
+ Try to apply the last conflicting patch again. This is generally
+ only useful for passing extra options to the retry attempt
+ (e.g., `--3way`), since otherwise you'll just see the same
+ failure again.
+
+--show-current-patch[=(diff|raw)]::
+ Show the message at which `git am` has stopped due to
+ conflicts. If `raw` is specified, show the raw contents of
+ the e-mail message; if `diff`, show the diff portion only.
+ Defaults to `raw`.
+
+--allow-empty::
+ After a patch failure on an input e-mail message lacking a patch,
+ create an empty commit with the contents of the e-mail message
+ as its log message.
+
+DISCUSSION
+----------
+
+The commit author name is taken from the "From: " line of the
+message, and commit author date is taken from the "Date: " line
+of the message. The "Subject: " line is used as the title of
+the commit, after stripping common prefix "[PATCH <anything>]".
+The "Subject: " line is supposed to concisely describe what the
+commit is about in one line of text.
+
+"From: ", "Date: ", and "Subject: " lines starting the body override the
+respective commit author name and title values taken from the headers.
+
+The commit message is formed by the title taken from the
+"Subject: ", a blank line and the body of the message up to
+where the patch begins. Excess whitespace at the end of each
+line is automatically stripped.
+
+The patch is expected to be inline, directly following the
+message. Any line that is of the form:
+
+* three-dashes and end-of-line, or
+* a line that begins with "diff -", or
+* a line that begins with "Index: "
+
+is taken as the beginning of a patch, and the commit log message
+is terminated before the first occurrence of such a line.
+
+When initially invoking `git am`, you give it the names of the mailboxes
+to process. Upon seeing the first patch that does not apply, it
+aborts in the middle. You can recover from this in one of two ways:
+
+. skip the current patch by re-running the command with the `--skip`
+ option.
+
+. hand resolve the conflict in the working directory, and update
+ the index file to bring it into a state that the patch should
+ have produced. Then run the command with the `--continue` option.
+
+The command refuses to process new mailboxes until the current
+operation is finished, so if you decide to start over from scratch,
+run `git am --abort` before running the command with mailbox
+names.
+
+Before any patches are applied, ORIG_HEAD is set to the tip of the
+current branch. This is useful if you have problems with multiple
+commits, like running 'git am' on the wrong branch or an error in the
+commits that is more easily fixed by changing the mailbox (e.g.
+errors in the "From:" lines).
+
+HOOKS
+-----
+This command can run `applypatch-msg`, `pre-applypatch`,
+and `post-applypatch` hooks. See linkgit:githooks[5] for more
+information.
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/am.adoc[]
+
+SEE ALSO
+--------
+linkgit:git-apply[1],
+linkgit:git-format-patch[1].
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-annotate.adoc b/git-annotate.adoc
new file mode 100644
index 0000000..965bc67
--- /dev/null
+++ b/git-annotate.adoc
@@ -0,0 +1,33 @@
+git-annotate(1)
+===============
+
+NAME
+----
+git-annotate - Annotate file lines with commit information
+
+SYNOPSIS
+--------
+[verse]
+'git annotate' [<options>] [<rev-opts>] [<rev>] [--] <file>
+
+DESCRIPTION
+-----------
+Annotates each line in the given file with information from the commit
+which introduced the line. Optionally annotates from a given revision.
+
+The only difference between this command and linkgit:git-blame[1] is that
+they use slightly different output formats, and this command exists only
+for backward compatibility to support existing scripts, and provide a more
+familiar command name for people coming from other SCM systems.
+
+OPTIONS
+-------
+include::blame-options.adoc[]
+
+SEE ALSO
+--------
+linkgit:git-blame[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-apply.adoc b/git-apply.adoc
new file mode 100644
index 0000000..952518b
--- /dev/null
+++ b/git-apply.adoc
@@ -0,0 +1,298 @@
+git-apply(1)
+============
+
+NAME
+----
+git-apply - Apply a patch to files and/or to the index
+
+
+SYNOPSIS
+--------
+[verse]
+'git apply' [--stat] [--numstat] [--summary] [--check]
+ [--index | --intent-to-add] [--3way] [--ours | --theirs | --union]
+ [--apply] [--no-add] [--build-fake-ancestor=<file>] [-R | --reverse]
+ [--allow-binary-replacement | --binary] [--reject] [-z]
+ [-p<n>] [-C<n>] [--inaccurate-eof] [--recount] [--cached]
+ [--ignore-space-change | --ignore-whitespace]
+ [--whitespace=(nowarn|warn|fix|error|error-all)]
+ [--exclude=<path>] [--include=<path>] [--directory=<root>]
+ [--verbose | --quiet] [--unsafe-paths] [--allow-empty] [<patch>...]
+
+DESCRIPTION
+-----------
+Reads the supplied diff output (i.e. "a patch") and applies it to files.
+When running from a subdirectory in a repository, patched paths
+outside the directory are ignored.
+With the `--index` option, the patch is also applied to the index, and
+with the `--cached` option, the patch is only applied to the index.
+Without these options, the command applies the patch only to files,
+and does not require them to be in a Git repository.
+
+This command applies the patch but does not create a commit. Use
+linkgit:git-am[1] to create commits from patches generated by
+linkgit:git-format-patch[1] and/or received by email.
+
+OPTIONS
+-------
+<patch>...::
+ The files to read the patch from. '-' can be used to read
+ from the standard input.
+
+--stat::
+ Instead of applying the patch, output diffstat for the
+ input. Turns off "apply".
+
+--numstat::
+ Similar to `--stat`, but shows the number of added and
+ deleted lines in decimal notation and the pathname without
+ abbreviation, to make it more machine friendly. For
+ binary files, outputs two `-` instead of saying
+ `0 0`. Turns off "apply".
+
+--summary::
+ Instead of applying the patch, output a condensed
+ summary of information obtained from git diff extended
+ headers, such as creations, renames, and mode changes.
+ Turns off "apply".
+
+--check::
+ Instead of applying the patch, see if the patch is
+ applicable to the current working tree and/or the index
+ file and detects errors. Turns off "apply".
+
+--index::
+ Apply the patch to both the index and the working tree (or
+ merely check that it would apply cleanly to both if `--check` is
+ in effect). Note that `--index` expects index entries and
+ working tree copies for relevant paths to be identical (their
+ contents and metadata such as file mode must match), and will
+ raise an error if they are not, even if the patch would apply
+ cleanly to both the index and the working tree in isolation.
+
+--cached::
+ Apply the patch to just the index, without touching the working
+ tree. If `--check` is in effect, merely check that it would
+ apply cleanly to the index entry.
+
+--intent-to-add::
+ When applying the patch only to the working tree, mark new
+ files to be added to the index later (see `--intent-to-add`
+ option in linkgit:git-add[1]). This option is ignored unless
+ running in a Git repository and `--index` is not specified.
+ Note that `--index` could be implied by other options such
+ as `--cached` or `--3way`.
+
+-3::
+--3way::
+ Attempt 3-way merge if the patch records the identity of blobs it is supposed
+ to apply to and we have those blobs available locally, possibly leaving the
+ conflict markers in the files in the working tree for the user to
+ resolve. This option implies the `--index` option unless the
+ `--cached` option is used, and is incompatible with the `--reject` option.
+ When used with the `--cached` option, any conflicts are left at higher stages
+ in the cache.
+
+--ours::
+--theirs::
+--union::
+ Instead of leaving conflicts in the file, resolve conflicts favouring
+ our (or their or both) side of the lines. Requires --3way.
+
+--build-fake-ancestor=<file>::
+ Newer 'git diff' output has embedded 'index information'
+ for each blob to help identify the original version that
+ the patch applies to. When this flag is given, and if
+ the original versions of the blobs are available locally,
+ builds a temporary index containing those blobs.
++
+When a pure mode change is encountered (which has no index information),
+the information is read from the current index instead.
+
+-R::
+--reverse::
+ Apply the patch in reverse.
+
+--reject::
+ For atomicity, 'git apply' by default fails the whole patch and
+ does not touch the working tree when some of the hunks
+ do not apply. This option makes it apply
+ the parts of the patch that are applicable, and leave the
+ rejected hunks in corresponding *.rej files.
+
+-z::
+ When `--numstat` has been given, do not munge pathnames,
+ but use a NUL-terminated machine-readable format.
++
+Without this option, pathnames with "unusual" characters are quoted as
+explained for the configuration variable `core.quotePath` (see
+linkgit:git-config[1]).
+
+-p<n>::
+ Remove <n> leading path components (separated by slashes) from
+ traditional diff paths. E.g., with `-p2`, a patch against
+ `a/dir/file` will be applied directly to `file`. The default is
+ 1.
+
+-C<n>::
+ Ensure at least <n> lines of surrounding context match before
+ and after each change. When fewer lines of surrounding
+ context exist they all must match. By default no context is
+ ever ignored.
+
+--unidiff-zero::
+ By default, 'git apply' expects that the patch being
+ applied is a unified diff with at least one line of context.
+ This provides good safety measures, but breaks down when
+ applying a diff generated with `--unified=0`. To bypass these
+ checks use `--unidiff-zero`.
++
+Note, for the reasons stated above, the usage of context-free patches is
+discouraged.
+
+--apply::
+ If you use any of the options marked "Turns off
+ 'apply'" above, 'git apply' reads and outputs the
+ requested information without actually applying the
+ patch. Give this flag after those flags to also apply
+ the patch.
+
+--no-add::
+ When applying a patch, ignore additions made by the
+ patch. This can be used to extract the common part between
+ two files by first running 'diff' on them and applying
+ the result with this option, which would apply the
+ deletion part but not the addition part.
+
+--allow-binary-replacement::
+--binary::
+ Historically we did not allow binary patch application
+ without an explicit permission from the user, and this
+ flag was the way to do so. Currently, we always allow binary
+ patch application, so this is a no-op.
+
+--exclude=<path-pattern>::
+ Don't apply changes to files matching the given path pattern. This can
+ be useful when importing patchsets, where you want to exclude certain
+ files or directories.
+
+--include=<path-pattern>::
+ Apply changes to files matching the given path pattern. This can
+ be useful when importing patchsets, where you want to include certain
+ files or directories.
++
+When `--exclude` and `--include` patterns are used, they are examined in the
+order they appear on the command line, and the first match determines if a
+patch to each path is used. A patch to a path that does not match any
+include/exclude pattern is used by default if there is no include pattern
+on the command line, and ignored if there is any include pattern.
+
+--ignore-space-change::
+--ignore-whitespace::
+ When applying a patch, ignore changes in whitespace in context
+ lines if necessary.
+ Context lines will preserve their whitespace, and they will not
+ undergo whitespace fixing regardless of the value of the
+ `--whitespace` option. New lines will still be fixed, though.
+
+--whitespace=<action>::
+ When applying a patch, detect a new or modified line that has
+ whitespace errors. What are considered whitespace errors is
+ controlled by `core.whitespace` configuration. By default,
+ trailing whitespaces (including lines that solely consist of
+ whitespaces) and a space character that is immediately followed
+ by a tab character inside the initial indent of the line are
+ considered whitespace errors.
++
+By default, the command outputs warning messages but applies the patch.
+When `git-apply` is used for statistics and not applying a
+patch, it defaults to `nowarn`.
++
+You can use different `<action>` values to control this
+behavior:
++
+* `nowarn` turns off the trailing whitespace warning.
+* `warn` outputs warnings for a few such errors, but applies the
+ patch as-is (default).
+* `fix` outputs warnings for a few such errors, and applies the
+ patch after fixing them (`strip` is a synonym -- the tool
+ used to consider only trailing whitespace characters as errors, and the
+ fix involved 'stripping' them, but modern Gits do more).
+* `error` outputs warnings for a few such errors, and refuses
+ to apply the patch.
+* `error-all` is similar to `error` but shows all errors.
+
+--inaccurate-eof::
+ Under certain circumstances, some versions of 'diff' do not correctly
+ detect a missing new-line at the end of the file. As a result, patches
+ created by such 'diff' programs do not record incomplete lines
+ correctly. This option adds support for applying such patches by
+ working around this bug.
+
+-v::
+--verbose::
+ Report progress to stderr. By default, only a message about the
+ current patch being applied will be printed. This option will cause
+ additional information to be reported.
+
+-q::
+--quiet::
+ Suppress stderr output. Messages about patch status and progress
+ will not be printed.
+
+--recount::
+ Do not trust the line counts in the hunk headers, but infer them
+ by inspecting the patch (e.g. after editing the patch without
+ adjusting the hunk headers appropriately).
+
+--directory=<root>::
+ Prepend <root> to all filenames. If a "-p" argument was also passed,
+ it is applied before prepending the new root.
++
+For example, a patch that talks about updating `a/git-gui.sh` to `b/git-gui.sh`
+can be applied to the file in the working tree `modules/git-gui/git-gui.sh` by
+running `git apply --directory=modules/git-gui`.
+
+--unsafe-paths::
+ By default, a patch that affects outside the working area
+ (either a Git controlled working tree, or the current working
+ directory when "git apply" is used as a replacement of GNU
+ patch) is rejected as a mistake (or a mischief).
++
+When `git apply` is used as a "better GNU patch", the user can pass
+the `--unsafe-paths` option to override this safety check. This option
+has no effect when `--index` or `--cached` is in use.
+
+--allow-empty::
+ Don't return an error for patches containing no diff. This includes
+ empty patches and patches with commit text only.
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/apply.adoc[]
+
+SUBMODULES
+----------
+If the patch contains any changes to submodules then 'git apply'
+treats these changes as follows.
+
+If `--index` is specified (explicitly or implicitly), then the submodule
+commits must match the index exactly for the patch to apply. If any
+of the submodules are checked-out, then these check-outs are completely
+ignored, i.e., they are not required to be up to date or clean and they
+are not updated.
+
+If `--index` is not specified, then the submodule commits in the patch
+are ignored and only the absence or presence of the corresponding
+subdirectory is checked and (if possible) updated.
+
+SEE ALSO
+--------
+linkgit:git-am[1].
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-archimport.adoc b/git-archimport.adoc
new file mode 100644
index 0000000..847777f
--- /dev/null
+++ b/git-archimport.adoc
@@ -0,0 +1,113 @@
+git-archimport(1)
+=================
+
+NAME
+----
+git-archimport - Import a GNU Arch repository into Git
+
+
+SYNOPSIS
+--------
+[verse]
+'git archimport' [-h] [-v] [-o] [-a] [-f] [-T] [-D <depth>] [-t <tempdir>]
+ <archive>/<branch>[:<git-branch>]...
+
+DESCRIPTION
+-----------
+Imports a project from one or more GNU Arch repositories.
+It will follow branches
+and repositories within the namespaces defined by the <archive>/<branch>
+parameters supplied. If it cannot find the remote branch a merge comes from
+it will just import it as a regular commit. If it can find it, it will mark it
+as a merge whenever possible (see discussion below).
+
+The script expects you to provide the key roots where it can start the import
+from an 'initial import' or 'tag' type of Arch commit. It will follow and
+import new branches within the provided roots.
+
+It expects to be dealing with one project only. If it sees
+branches that have different roots, it will refuse to run. In that case,
+edit your <archive>/<branch> parameters to define clearly the scope of the
+import.
+
+'git archimport' uses `tla` extensively in the background to access the
+Arch repository.
+Make sure you have a recent version of `tla` available in the path. `tla` must
+know about the repositories you pass to 'git archimport'.
+
+For the initial import, 'git archimport' expects to find itself in an empty
+directory. To follow the development of a project that uses Arch, rerun
+'git archimport' with the same parameters as the initial import to perform
+incremental imports.
+
+While 'git archimport' will try to create sensible branch names for the
+archives that it imports, it is also possible to specify Git branch names
+manually. To do so, write a Git branch name after each <archive>/<branch>
+parameter, separated by a colon. This way, you can shorten the Arch
+branch names and convert Arch jargon to Git jargon, for example mapping a
+"PROJECT{litdd}devo{litdd}VERSION" branch to "master".
+
+Associating multiple Arch branches to one Git branch is possible; the
+result will make the most sense only if no commits are made to the first
+branch, after the second branch is created. Still, this is useful to
+convert Arch repositories that had been rotated periodically.
+
+
+MERGES
+------
+Patch merge data from Arch is used to mark merges in Git as well. Git
+does not care much about tracking patches, and only considers a merge when a
+branch incorporates all the commits since the point they forked. The end result
+is that Git will have a good idea of how far branches have diverged. So the
+import process does lose some patch-trading metadata.
+
+Fortunately, when you try and merge branches imported from Arch,
+Git will find a good merge base, and it has a good chance of identifying
+patches that have been traded out-of-sequence between the branches.
+
+OPTIONS
+-------
+
+-h::
+ Display usage.
+
+-v::
+ Verbose output.
+
+-T::
+ Many tags. Will create a tag for every commit, reflecting the commit
+ name in the Arch repository.
+
+-f::
+ Use the fast patchset import strategy. This can be significantly
+ faster for large trees, but cannot handle directory renames or
+ permissions changes. The default strategy is slow and safe.
+
+-o::
+ Use this for compatibility with old-style branch names used by
+ earlier versions of 'git archimport'. Old-style branch names
+ were category{litdd}branch, whereas new-style branch names are
+ archive,category{litdd}branch{litdd}version. In both cases, names given
+ on the command-line will override the automatically-generated
+ ones.
+
+-D <depth>::
+ Follow merge ancestry and attempt to import trees that have been
+ merged from. Specify a depth greater than 1 if patch logs have been
+ pruned.
+
+-a::
+ Attempt to auto-register archives at `http://mirrors.sourcecontrol.net`
+ This is particularly useful with the -D option.
+
+-t <tmpdir>::
+ Override the default tempdir.
+
+
+<archive>/<branch>::
+ <archive>/<branch> identifier in a format that `tla log` understands.
+
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-archive.adoc b/git-archive.adoc
new file mode 100644
index 0000000..a0e3fe7
--- /dev/null
+++ b/git-archive.adoc
@@ -0,0 +1,243 @@
+git-archive(1)
+==============
+
+NAME
+----
+git-archive - Create an archive of files from a named tree
+
+
+SYNOPSIS
+--------
+[verse]
+'git archive' [--format=<fmt>] [--list] [--prefix=<prefix>/] [<extra>]
+ [-o <file> | --output=<file>] [--worktree-attributes]
+ [--remote=<repo> [--exec=<git-upload-archive>]] <tree-ish>
+ [<path>...]
+
+DESCRIPTION
+-----------
+Creates an archive of the specified format containing the tree
+structure for the named tree, and writes it out to the standard
+output. If <prefix> is specified it is
+prepended to the filenames in the archive.
+
+'git archive' behaves differently when given a tree ID as opposed to a
+commit ID or tag ID. When a tree ID is provided, the current time is
+used as the modification time of each file in the archive. On the
+other hand, when a commit ID or tag ID is provided, the commit time as
+recorded in the referenced commit object is used instead.
+Additionally the commit ID is stored in a global extended pax header
+if the tar format is used; it can be extracted using 'git
+get-tar-commit-id'. In ZIP files it is stored as a file comment.
+
+OPTIONS
+-------
+
+--format=<fmt>::
+ Format of the resulting archive. Possible values are `tar`,
+ `zip`, `tar.gz`, `tgz`, and any format defined using the
+ configuration option `tar.<format>.command`. If `--format`
+ is not given, and the output file is specified, the format is
+ inferred from the filename if possible (e.g. writing to `foo.zip`
+ makes the output to be in the `zip` format). Otherwise the output
+ format is `tar`.
+
+-l::
+--list::
+ Show all available formats.
+
+-v::
+--verbose::
+ Report progress to stderr.
+
+--prefix=<prefix>/::
+ Prepend <prefix>/ to paths in the archive. Can be repeated; its
+ rightmost value is used for all tracked files. See below which
+ value gets used by `--add-file`.
+
+-o <file>::
+--output=<file>::
+ Write the archive to <file> instead of stdout.
+
+--add-file=<file>::
+ Add a non-tracked file to the archive. Can be repeated to add
+ multiple files. The path of the file in the archive is built by
+ concatenating the value of the last `--prefix` option (if any)
+ before this `--add-file` and the basename of <file>.
+
+--add-virtual-file=<path>:<content>::
+ Add the specified contents to the archive. Can be repeated to add
+ multiple files.
++
+The `<path>` argument can start and end with a literal double-quote
+character; the contained file name is interpreted as a C-style string,
+i.e. the backslash is interpreted as escape character. The path must
+be quoted if it contains a colon, to avoid the colon from being
+misinterpreted as the separator between the path and the contents, or
+if the path begins or ends with a double-quote character.
++
+The file mode is limited to a regular file, and the option may be
+subject to platform-dependent command-line limits. For non-trivial
+cases, write an untracked file and use `--add-file` instead.
++
+Note that unlike `--add-file` the path created in the archive is not
+affected by the `--prefix` option, as a full `<path>` can be given as
+the value of the option.
+
+--worktree-attributes::
+ Look for attributes in .gitattributes files in the working tree
+ as well (see <<ATTRIBUTES>>).
+
+--mtime=<time>::
+ Set modification time of archive entries. Without this option
+ the committer time is used if `<tree-ish>` is a commit or tag,
+ and the current time if it is a tree.
+
+<extra>::
+ This can be any options that the archiver backend understands.
+ See next section.
+
+--remote=<repo>::
+ Instead of making a tar archive from the local repository,
+ retrieve a tar archive from a remote repository. Note that the
+ remote repository may place restrictions on which sha1
+ expressions may be allowed in `<tree-ish>`. See
+ linkgit:git-upload-archive[1] for details.
+
+--exec=<git-upload-archive>::
+ Used with --remote to specify the path to the
+ 'git-upload-archive' on the remote side.
+
+<tree-ish>::
+ The tree or commit to produce an archive for.
+
+<path>::
+ Without an optional path parameter, all files and subdirectories
+ of the current working directory are included in the archive.
+ If one or more paths are specified, only these are included.
+
+BACKEND EXTRA OPTIONS
+---------------------
+
+zip
+~~~
+-<digit>::
+ Specify compression level. Larger values allow the command
+ to spend more time to compress to smaller size. Supported
+ values are from `-0` (store-only) to `-9` (best ratio).
+ Default is `-6` if not given.
+
+tar
+~~~
+-<number>::
+ Specify compression level. The value will be passed to the
+ compression command configured in `tar.<format>.command`. See
+ manual page of the configured command for the list of supported
+ levels and the default level if this option isn't specified.
+
+CONFIGURATION
+-------------
+
+tar.umask::
+ This variable can be used to restrict the permission bits of
+ tar archive entries. The default is 0002, which turns off the
+ world write bit. The special value "user" indicates that the
+ archiving user's umask will be used instead. See umask(2) for
+ details. If `--remote` is used then only the configuration of
+ the remote repository takes effect.
+
+tar.<format>.command::
+ This variable specifies a shell command through which the tar
+ output generated by `git archive` should be piped. The command
+ is executed using the shell with the generated tar file on its
+ standard input, and should produce the final output on its
+ standard output. Any compression-level options will be passed
+ to the command (e.g., `-9`).
++
+The `tar.gz` and `tgz` formats are defined automatically and use the
+magic command `git archive gzip` by default, which invokes an internal
+implementation of gzip.
+
+tar.<format>.remote::
+ If true, enable the format for use by remote clients via
+ linkgit:git-upload-archive[1]. Defaults to false for
+ user-defined formats, but true for the `tar.gz` and `tgz`
+ formats.
+
+[[ATTRIBUTES]]
+ATTRIBUTES
+----------
+
+export-ignore::
+ Files and directories with the attribute export-ignore won't be
+ added to archive files. See linkgit:gitattributes[5] for details.
+
+export-subst::
+ If the attribute export-subst is set for a file then Git will
+ expand several placeholders when adding this file to an archive.
+ See linkgit:gitattributes[5] for details.
+
+Note that attributes are by default taken from the `.gitattributes` files
+in the tree that is being archived. If you want to tweak the way the
+output is generated after the fact (e.g. you committed without adding an
+appropriate export-ignore in its `.gitattributes`), adjust the checked out
+`.gitattributes` file as necessary and use `--worktree-attributes`
+option. Alternatively you can keep necessary attributes that should apply
+while archiving any tree in your `$GIT_DIR/info/attributes` file.
+
+EXAMPLES
+--------
+`git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -)`::
+
+ Create a tar archive that contains the contents of the
+ latest commit on the current branch, and extract it in the
+ `/var/tmp/junk` directory.
+
+`git archive --format=tar --prefix=git-1.4.0/ v1.4.0 | gzip >git-1.4.0.tar.gz`::
+
+ Create a compressed tarball for v1.4.0 release.
+
+`git archive --format=tar.gz --prefix=git-1.4.0/ v1.4.0 >git-1.4.0.tar.gz`::
+
+ Same as above, but using the builtin tar.gz handling.
+
+`git archive --prefix=git-1.4.0/ -o git-1.4.0.tar.gz v1.4.0`::
+
+ Same as above, but the format is inferred from the output file.
+
+`git archive --format=tar --prefix=git-1.4.0/ v1.4.0^{tree} | gzip >git-1.4.0.tar.gz`::
+
+ Create a compressed tarball for v1.4.0 release, but without a
+ global extended pax header.
+
+`git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ > git-1.4.0-docs.zip`::
+
+ Put everything in the current head's Documentation/ directory
+ into 'git-1.4.0-docs.zip', with the prefix 'git-docs/'.
+
+`git archive -o latest.zip HEAD`::
+
+ Create a Zip archive that contains the contents of the latest
+ commit on the current branch. Note that the output format is
+ inferred by the extension of the output file.
+
+`git archive -o latest.tar --prefix=build/ --add-file=configure --prefix= HEAD`::
+
+ Creates a tar archive that contains the contents of the latest
+ commit on the current branch with no prefix and the untracked
+ file 'configure' with the prefix 'build/'.
+
+`git config tar.tar.xz.command "xz -c"`::
+
+ Configure a "tar.xz" format for making LZMA-compressed tarfiles.
+ You can use it specifying `--format=tar.xz`, or by creating an
+ output file like `-o foo.tar.xz`.
+
+
+SEE ALSO
+--------
+linkgit:gitattributes[5]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-bisect-lk2009.adoc b/git-bisect-lk2009.adoc
new file mode 100644
index 0000000..0bc1657
--- /dev/null
+++ b/git-bisect-lk2009.adoc
@@ -0,0 +1,1358 @@
+Fighting regressions with git bisect
+====================================
+:Author: Christian Couder
+:Email: chriscool@tuxfamily.org
+:Date: 2009/11/08
+
+Abstract
+--------
+
+"git bisect" enables software users and developers to easily find the
+commit that introduced a regression. We show why it is important to
+have good tools to fight regressions. We describe how "git bisect"
+works from the outside and the algorithms it uses inside. Then we
+explain how to take advantage of "git bisect" to improve current
+practices. And we discuss how "git bisect" could improve in the
+future.
+
+
+Introduction to "git bisect"
+----------------------------
+
+Git is a Distributed Version Control system (DVCS) created by Linus
+Torvalds and maintained by Junio Hamano.
+
+In Git like in many other Version Control Systems (VCS), the different
+states of the data that is managed by the system are called
+commits. And, as VCS are mostly used to manage software source code,
+sometimes "interesting" changes of behavior in the software are
+introduced in some commits.
+
+In fact people are specially interested in commits that introduce a
+"bad" behavior, called a bug or a regression. They are interested in
+these commits because a commit (hopefully) contains a very small set
+of source code changes. And it's much easier to understand and
+properly fix a problem when you only need to check a very small set of
+changes, than when you don't know where look in the first place.
+
+So to help people find commits that introduce a "bad" behavior, the
+"git bisect" set of commands was invented. And it follows of course
+that in "git bisect" parlance, commits where the "interesting
+behavior" is present are called "bad" commits, while other commits are
+called "good" commits. And a commit that introduce the behavior we are
+interested in is called a "first bad commit". Note that there could be
+more than one "first bad commit" in the commit space we are searching.
+
+So "git bisect" is designed to help find a "first bad commit". And to
+be as efficient as possible, it tries to perform a binary search.
+
+
+Fighting regressions overview
+-----------------------------
+
+Regressions: a big problem
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Regressions are a big problem in the software industry. But it's
+difficult to put some real numbers behind that claim.
+
+There are some numbers about bugs in general, like a NIST study in
+2002 <<1>> that said:
+
+_____________
+Software bugs, or errors, are so prevalent and so detrimental that
+they cost the U.S. economy an estimated $59.5 billion annually, or
+about 0.6 percent of the gross domestic product, according to a newly
+released study commissioned by the Department of Commerce's National
+Institute of Standards and Technology (NIST). At the national level,
+over half of the costs are borne by software users and the remainder
+by software developers/vendors. The study also found that, although
+all errors cannot be removed, more than a third of these costs, or an
+estimated $22.2 billion, could be eliminated by an improved testing
+infrastructure that enables earlier and more effective identification
+and removal of software defects. These are the savings associated with
+finding an increased percentage (but not 100 percent) of errors closer
+to the development stages in which they are introduced. Currently,
+over half of all errors are not found until "downstream" in the
+development process or during post-sale software use.
+_____________
+
+And then:
+
+_____________
+Software developers already spend approximately 80 percent of
+development costs on identifying and correcting defects, and yet few
+products of any type other than software are shipped with such high
+levels of errors.
+_____________
+
+Eventually the conclusion started with:
+
+_____________
+The path to higher software quality is significantly improved software
+testing.
+_____________
+
+There are other estimates saying that 80% of the cost related to
+software is about maintenance <<2>>.
+
+Though, according to Wikipedia <<3>>:
+
+_____________
+A common perception of maintenance is that it is merely fixing
+bugs. However, studies and surveys over the years have indicated that
+the majority, over 80%, of the maintenance effort is used for
+non-corrective actions (Pigosky 1997). This perception is perpetuated
+by users submitting problem reports that in reality are functionality
+enhancements to the system.
+_____________
+
+But we can guess that improving on existing software is very costly
+because you have to watch out for regressions. At least this would
+make the above studies consistent among themselves.
+
+Of course some kind of software is developed, then used during some
+time without being improved on much, and then finally thrown away. In
+this case, of course, regressions may not be a big problem. But on the
+other hand, there is a lot of big software that is continually
+developed and maintained during years or even tens of years by a lot
+of people. And as there are often many people who depend (sometimes
+critically) on such software, regressions are a really big problem.
+
+One such software is the Linux kernel. And if we look at the Linux
+kernel, we can see that a lot of time and effort is spent to fight
+regressions. The release cycle start with a 2 weeks long merge
+window. Then the first release candidate (rc) version is tagged. And
+after that about 7 or 8 more rc versions will appear with around one
+week between each of them, before the final release.
+
+The time between the first rc release and the final release is
+supposed to be used to test rc versions and fight bugs and especially
+regressions. And this time is more than 80% of the release cycle
+time. But this is not the end of the fight yet, as of course it
+continues after the release.
+
+And then this is what Ingo Molnar (a well known Linux kernel
+developer) says about his use of git bisect:
+
+_____________
+I most actively use it during the merge window (when a lot of trees
+get merged upstream and when the influx of bugs is the highest) - and
+yes, there have been cases that i used it multiple times a day. My
+average is roughly once a day.
+_____________
+
+So regressions are fought all the time by developers, and indeed it is
+well known that bugs should be fixed as soon as possible, so as soon
+as they are found. That's why it is interesting to have good tools for
+this purpose.
+
+Other tools to fight regressions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+So what are the tools used to fight regressions? They are nearly the
+same as those used to fight regular bugs. The only specific tools are
+test suites and tools similar as "git bisect".
+
+Test suites are very nice. But when they are used alone, they are
+supposed to be used so that all the tests are checked after each
+commit. This means that they are not very efficient, because many
+tests are run for no interesting result, and they suffer from
+combinatorial explosion.
+
+In fact the problem is that big software often has many different
+configuration options and that each test case should pass for each
+configuration after each commit. So if you have for each release: N
+configurations, M commits and T test cases, you should perform:
+
+-------------
+N * M * T tests
+-------------
+
+where N, M and T are all growing with the size your software.
+
+So very soon it will not be possible to completely test everything.
+
+And if some bugs slip through your test suite, then you can add a test
+to your test suite. But if you want to use your new improved test
+suite to find where the bug slipped in, then you will either have to
+emulate a bisection process or you will perhaps bluntly test each
+commit backward starting from the "bad" commit you have which may be
+very wasteful.
+
+"git bisect" overview
+---------------------
+
+Starting a bisection
+~~~~~~~~~~~~~~~~~~~~
+
+The first "git bisect" subcommand to use is "git bisect start" to
+start the search. Then bounds must be set to limit the commit
+space. This is done usually by giving one "bad" and at least one
+"good" commit. They can be passed in the initial call to "git bisect
+start" like this:
+
+-------------
+$ git bisect start [BAD [GOOD...]]
+-------------
+
+or they can be set using:
+
+-------------
+$ git bisect bad [COMMIT]
+-------------
+
+and:
+
+-------------
+$ git bisect good [COMMIT...]
+-------------
+
+where BAD, GOOD and COMMIT are all names that can be resolved to a
+commit.
+
+Then "git bisect" will checkout a commit of its choosing and ask the
+user to test it, like this:
+
+-------------
+$ git bisect start v2.6.27 v2.6.25
+Bisecting: 10928 revisions left to test after this (roughly 14 steps)
+[2ec65f8b89ea003c27ff7723525a2ee335a2b393] x86: clean up using max_low_pfn on 32-bit
+-------------
+
+Note that the example that we will use is really a toy example, we
+will be looking for the first commit that has a version like
+"2.6.26-something", that is the commit that has a "SUBLEVEL = 26" line
+in the top level Makefile. This is a toy example because there are
+better ways to find this commit with Git than using "git bisect" (for
+example "git blame" or "git log -S<string>").
+
+Driving a bisection manually
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+At this point there are basically 2 ways to drive the search. It can
+be driven manually by the user or it can be driven automatically by a
+script or a command.
+
+If the user is driving it, then at each step of the search, the user
+will have to test the current commit and say if it is "good" or "bad"
+using the "git bisect good" or "git bisect bad" commands respectively
+that have been described above. For example:
+
+-------------
+$ git bisect bad
+Bisecting: 5480 revisions left to test after this (roughly 13 steps)
+[66c0b394f08fd89236515c1c84485ea712a157be] KVM: kill file->f_count abuse in kvm
+-------------
+
+And after a few more steps like that, "git bisect" will eventually
+find a first bad commit:
+
+-------------
+$ git bisect bad
+2ddcca36c8bcfa251724fe342c8327451988be0d is the first bad commit
+commit 2ddcca36c8bcfa251724fe342c8327451988be0d
+Author: Linus Torvalds <torvalds@linux-foundation.org>
+Date: Sat May 3 11:59:44 2008 -0700
+
+ Linux 2.6.26-rc1
+
+:100644 100644 5cf82581... 4492984e... M Makefile
+-------------
+
+At this point we can see what the commit does, check it out (if it's
+not already checked out) or tinker with it, for example:
+
+-------------
+$ git show HEAD
+commit 2ddcca36c8bcfa251724fe342c8327451988be0d
+Author: Linus Torvalds <torvalds@linux-foundation.org>
+Date: Sat May 3 11:59:44 2008 -0700
+
+ Linux 2.6.26-rc1
+
+diff --git a/Makefile b/Makefile
+index 5cf8258..4492984 100644
+--- a/Makefile
++++ b/Makefile
+@@ -1,7 +1,7 @@
+ VERSION = 2
+ PATCHLEVEL = 6
+-SUBLEVEL = 25
+-EXTRAVERSION =
++SUBLEVEL = 26
++EXTRAVERSION = -rc1
+ NAME = Funky Weasel is Jiggy wit it
+
+ # *DOCUMENTATION*
+-------------
+
+And when we are finished we can use "git bisect reset" to go back to
+the branch we were in before we started bisecting:
+
+-------------
+$ git bisect reset
+Checking out files: 100% (21549/21549), done.
+Previous HEAD position was 2ddcca3... Linux 2.6.26-rc1
+Switched to branch 'master'
+-------------
+
+Driving a bisection automatically
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The other way to drive the bisection process is to tell "git bisect"
+to launch a script or command at each bisection step to know if the
+current commit is "good" or "bad". To do that, we use the "git bisect
+run" command. For example:
+
+-------------
+$ git bisect start v2.6.27 v2.6.25
+Bisecting: 10928 revisions left to test after this (roughly 14 steps)
+[2ec65f8b89ea003c27ff7723525a2ee335a2b393] x86: clean up using max_low_pfn on 32-bit
+$
+$ git bisect run grep '^SUBLEVEL = 25' Makefile
+running grep ^SUBLEVEL = 25 Makefile
+Bisecting: 5480 revisions left to test after this (roughly 13 steps)
+[66c0b394f08fd89236515c1c84485ea712a157be] KVM: kill file->f_count abuse in kvm
+running grep ^SUBLEVEL = 25 Makefile
+SUBLEVEL = 25
+Bisecting: 2740 revisions left to test after this (roughly 12 steps)
+[671294719628f1671faefd4882764886f8ad08cb] V4L/DVB(7879): Adding cx18 Support for mxl5005s
+...
+...
+running grep ^SUBLEVEL = 25 Makefile
+Bisecting: 0 revisions left to test after this (roughly 0 steps)
+[2ddcca36c8bcfa251724fe342c8327451988be0d] Linux 2.6.26-rc1
+running grep ^SUBLEVEL = 25 Makefile
+2ddcca36c8bcfa251724fe342c8327451988be0d is the first bad commit
+commit 2ddcca36c8bcfa251724fe342c8327451988be0d
+Author: Linus Torvalds <torvalds@linux-foundation.org>
+Date: Sat May 3 11:59:44 2008 -0700
+
+ Linux 2.6.26-rc1
+
+:100644 100644 5cf82581... 4492984e... M Makefile
+bisect run success
+-------------
+
+In this example, we passed "grep '^SUBLEVEL = 25' Makefile" as
+parameter to "git bisect run". This means that at each step, the grep
+command we passed will be launched. And if it exits with code 0 (that
+means success) then git bisect will mark the current state as
+"good". If it exits with code 1 (or any code between 1 and 127
+included, except the special code 125), then the current state will be
+marked as "bad".
+
+Exit code between 128 and 255 are special to "git bisect run". They
+make it stop immediately the bisection process. This is useful for
+example if the command passed takes too long to complete, because you
+can kill it with a signal and it will stop the bisection process.
+
+It can also be useful in scripts passed to "git bisect run" to "exit
+255" if some very abnormal situation is detected.
+
+Avoiding untestable commits
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Sometimes it happens that the current state cannot be tested, for
+example if it does not compile because there was a bug preventing it
+at that time. This is what the special exit code 125 is for. It tells
+"git bisect run" that the current commit should be marked as
+untestable and that another one should be chosen and checked out.
+
+If the bisection process is driven manually, you can use "git bisect
+skip" to do the same thing. (In fact the special exit code 125 makes
+"git bisect run" use "git bisect skip" in the background.)
+
+Or if you want more control, you can inspect the current state using
+for example "git bisect visualize". It will launch gitk (or "git log"
+if the `DISPLAY` environment variable is not set) to help you find a
+better bisection point.
+
+Either way, if you have a string of untestable commits, it might
+happen that the regression you are looking for has been introduced by
+one of these untestable commits. In this case it's not possible to
+tell for sure which commit introduced the regression.
+
+So if you used "git bisect skip" (or the run script exited with
+special code 125) you could get a result like this:
+
+-------------
+There are only 'skip'ped commits left to test.
+The first bad commit could be any of:
+15722f2fa328eaba97022898a305ffc8172db6b1
+78e86cf3e850bd755bb71831f42e200626fbd1e0
+e15b73ad3db9b48d7d1ade32f8cd23a751fe0ace
+070eab2303024706f2924822bfec8b9847e4ac1b
+We cannot bisect more!
+-------------
+
+Saving a log and replaying it
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If you want to show other people your bisection process, you can get a
+log using for example:
+
+-------------
+$ git bisect log > bisect_log.txt
+-------------
+
+And it is possible to replay it using:
+
+-------------
+$ git bisect replay bisect_log.txt
+-------------
+
+
+"git bisect" details
+--------------------
+
+Bisection algorithm
+~~~~~~~~~~~~~~~~~~~
+
+As the Git commits form a directed acyclic graph (DAG), finding the
+best bisection commit to test at each step is not so simple. Anyway
+Linus found and implemented a "truly stupid" algorithm, later improved
+by Junio Hamano, that works quite well.
+
+So the algorithm used by "git bisect" to find the best bisection
+commit when there are no skipped commits is the following:
+
+1) keep only the commits that:
+
+a) are ancestor of the "bad" commit (including the "bad" commit itself),
+b) are not ancestor of a "good" commit (excluding the "good" commits).
+
+This means that we get rid of the uninteresting commits in the DAG.
+
+For example if we start with a graph like this:
+
+-------------
+G-Y-G-W-W-W-X-X-X-X
+ \ /
+ W-W-B
+ /
+Y---G-W---W
+ \ / \
+Y-Y X-X-X-X
+
+-> time goes this way ->
+-------------
+
+where B is the "bad" commit, "G" are "good" commits and W, X, and Y
+are other commits, we will get the following graph after this first
+step:
+
+-------------
+W-W-W
+ \
+ W-W-B
+ /
+W---W
+-------------
+
+So only the W and B commits will be kept. Because commits X and Y will
+have been removed by rules a) and b) respectively, and because commits
+G are removed by rule b) too.
+
+Note for Git users, that it is equivalent as keeping only the commit
+given by:
+
+-------------
+git rev-list BAD --not GOOD1 GOOD2...
+-------------
+
+Also note that we don't require the commits that are kept to be
+descendants of a "good" commit. So in the following example, commits W
+and Z will be kept:
+
+-------------
+G-W-W-W-B
+ /
+Z-Z
+-------------
+
+2) starting from the "good" ends of the graph, associate to each
+ commit the number of ancestors it has plus one
+
+For example with the following graph where H is the "bad" commit and A
+and D are some parents of some "good" commits:
+
+-------------
+A-B-C
+ \
+ F-G-H
+ /
+D---E
+-------------
+
+this will give:
+
+-------------
+1 2 3
+A-B-C
+ \6 7 8
+ F-G-H
+1 2/
+D---E
+-------------
+
+3) associate to each commit: min(X, N - X)
+
+where X is the value associated to the commit in step 2) and N is the
+total number of commits in the graph.
+
+In the above example we have N = 8, so this will give:
+
+-------------
+1 2 3
+A-B-C
+ \2 1 0
+ F-G-H
+1 2/
+D---E
+-------------
+
+4) the best bisection point is the commit with the highest associated
+ number
+
+So in the above example the best bisection point is commit C.
+
+5) note that some shortcuts are implemented to speed up the algorithm
+
+As we know N from the beginning, we know that min(X, N - X) can't be
+greater than N/2. So during steps 2) and 3), if we would associate N/2
+to a commit, then we know this is the best bisection point. So in this
+case we can just stop processing any other commit and return the
+current commit.
+
+Bisection algorithm debugging
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+For any commit graph, you can see the number associated with each
+commit using "git rev-list --bisect-all".
+
+For example, for the above graph, a command like:
+
+-------------
+$ git rev-list --bisect-all BAD --not GOOD1 GOOD2
+-------------
+
+would output something like:
+
+-------------
+e15b73ad3db9b48d7d1ade32f8cd23a751fe0ace (dist=3)
+15722f2fa328eaba97022898a305ffc8172db6b1 (dist=2)
+78e86cf3e850bd755bb71831f42e200626fbd1e0 (dist=2)
+a1939d9a142de972094af4dde9a544e577ddef0e (dist=2)
+070eab2303024706f2924822bfec8b9847e4ac1b (dist=1)
+a3864d4f32a3bf5ed177ddef598490a08760b70d (dist=1)
+a41baa717dd74f1180abf55e9341bc7a0bb9d556 (dist=1)
+9e622a6dad403b71c40979743bb9d5be17b16bd6 (dist=0)
+-------------
+
+Bisection algorithm discussed
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+First let's define "best bisection point". We will say that a commit X
+is a best bisection point or a best bisection commit if knowing its
+state ("good" or "bad") gives as much information as possible whether
+the state of the commit happens to be "good" or "bad".
+
+This means that the best bisection commits are the commits where the
+following function is maximum:
+
+-------------
+f(X) = min(information_if_good(X), information_if_bad(X))
+-------------
+
+where information_if_good(X) is the information we get if X is good
+and information_if_bad(X) is the information we get if X is bad.
+
+Now we will suppose that there is only one "first bad commit". This
+means that all its descendants are "bad" and all the other commits are
+"good". And we will suppose that all commits have an equal probability
+of being good or bad, or of being the first bad commit, so knowing the
+state of c commits gives always the same amount of information
+wherever these c commits are on the graph and whatever c is. (So we
+suppose that these commits being for example on a branch or near a
+good or a bad commit does not give more or less information).
+
+Let's also suppose that we have a cleaned up graph like one after step
+1) in the bisection algorithm above. This means that we can measure
+ the information we get in terms of number of commit we can remove
+ from the graph..
+
+And let's take a commit X in the graph.
+
+If X is found to be "good", then we know that its ancestors are all
+"good", so we want to say that:
+
+-------------
+information_if_good(X) = number_of_ancestors(X) (TRUE)
+-------------
+
+And this is true because at step 1) b) we remove the ancestors of the
+"good" commits.
+
+If X is found to be "bad", then we know that its descendants are all
+"bad", so we want to say that:
+
+-------------
+information_if_bad(X) = number_of_descendants(X) (WRONG)
+-------------
+
+But this is wrong because at step 1) a) we keep only the ancestors of
+the bad commit. So we get more information when a commit is marked as
+"bad", because we also know that the ancestors of the previous "bad"
+commit that are not ancestors of the new "bad" commit are not the
+first bad commit. We don't know if they are good or bad, but we know
+that they are not the first bad commit because they are not ancestor
+of the new "bad" commit.
+
+So when a commit is marked as "bad" we know we can remove all the
+commits in the graph except those that are ancestors of the new "bad"
+commit. This means that:
+
+-------------
+information_if_bad(X) = N - number_of_ancestors(X) (TRUE)
+-------------
+
+where N is the number of commits in the (cleaned up) graph.
+
+So in the end this means that to find the best bisection commits we
+should maximize the function:
+
+-------------
+f(X) = min(number_of_ancestors(X), N - number_of_ancestors(X))
+-------------
+
+And this is nice because at step 2) we compute number_of_ancestors(X)
+and so at step 3) we compute f(X).
+
+Let's take the following graph as an example:
+
+-------------
+ G-H-I-J
+ / \
+A-B-C-D-E-F O
+ \ /
+ K-L-M-N
+-------------
+
+If we compute the following non optimal function on it:
+
+-------------
+g(X) = min(number_of_ancestors(X), number_of_descendants(X))
+-------------
+
+we get:
+
+-------------
+ 4 3 2 1
+ G-H-I-J
+1 2 3 4 5 6/ \0
+A-B-C-D-E-F O
+ \ /
+ K-L-M-N
+ 4 3 2 1
+-------------
+
+but with the algorithm used by git bisect we get:
+
+-------------
+ 7 7 6 5
+ G-H-I-J
+1 2 3 4 5 6/ \0
+A-B-C-D-E-F O
+ \ /
+ K-L-M-N
+ 7 7 6 5
+-------------
+
+So we chose G, H, K or L as the best bisection point, which is better
+than F. Because if for example L is bad, then we will know not only
+that L, M and N are bad but also that G, H, I and J are not the first
+bad commit (since we suppose that there is only one first bad commit
+and it must be an ancestor of L).
+
+So the current algorithm seems to be the best possible given what we
+initially supposed.
+
+Skip algorithm
+~~~~~~~~~~~~~~
+
+When some commits have been skipped (using "git bisect skip"), then
+the bisection algorithm is the same for step 1) to 3). But then we use
+roughly the following steps:
+
+6) sort the commit by decreasing associated value
+
+7) if the first commit has not been skipped, we can return it and stop
+ here
+
+8) otherwise filter out all the skipped commits in the sorted list
+
+9) use a pseudo random number generator (PRNG) to generate a random
+ number between 0 and 1
+
+10) multiply this random number with its square root to bias it toward
+ 0
+
+11) multiply the result by the number of commits in the filtered list
+ to get an index into this list
+
+12) return the commit at the computed index
+
+Skip algorithm discussed
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+After step 7) (in the skip algorithm), we could check if the second
+commit has been skipped and return it if it is not the case. And in
+fact that was the algorithm we used from when "git bisect skip" was
+developed in Git version 1.5.4 (released on February 1st 2008) until
+Git version 1.6.4 (released July 29th 2009).
+
+But Ingo Molnar and H. Peter Anvin (another well known linux kernel
+developer) both complained that sometimes the best bisection points
+all happened to be in an area where all the commits are
+untestable. And in this case the user was asked to test many
+untestable commits, which could be very inefficient.
+
+Indeed untestable commits are often untestable because a breakage was
+introduced at one time, and that breakage was fixed only after many
+other commits were introduced.
+
+This breakage is of course most of the time unrelated to the breakage
+we are trying to locate in the commit graph. But it prevents us to
+know if the interesting "bad behavior" is present or not.
+
+So it is a fact that commits near an untestable commit have a high
+probability of being untestable themselves. And the best bisection
+commits are often found together too (due to the bisection algorithm).
+
+This is why it is a bad idea to just chose the next best unskipped
+bisection commit when the first one has been skipped.
+
+We found that most commits on the graph may give quite a lot of
+information when they are tested. And the commits that will not on
+average give a lot of information are the one near the good and bad
+commits.
+
+So using a PRNG with a bias to favor commits away from the good and
+bad commits looked like a good choice.
+
+One obvious improvement to this algorithm would be to look for a
+commit that has an associated value near the one of the best bisection
+commit, and that is on another branch, before using the PRNG. Because
+if such a commit exists, then it is not very likely to be untestable
+too, so it will probably give more information than a nearly randomly
+chosen one.
+
+Checking merge bases
+~~~~~~~~~~~~~~~~~~~~
+
+There is another tweak in the bisection algorithm that has not been
+described in the "bisection algorithm" above.
+
+We supposed in the previous examples that the "good" commits were
+ancestors of the "bad" commit. But this is not a requirement of "git
+bisect".
+
+Of course the "bad" commit cannot be an ancestor of a "good" commit,
+because the ancestors of the good commits are supposed to be
+"good". And all the "good" commits must be related to the bad commit.
+They cannot be on a branch that has no link with the branch of the
+"bad" commit. But it is possible for a good commit to be related to a
+bad commit and yet not be neither one of its ancestor nor one of its
+descendants.
+
+For example, there can be a "main" branch, and a "dev" branch that was
+forked of the main branch at a commit named "D" like this:
+
+-------------
+A-B-C-D-E-F-G <--main
+ \
+ H-I-J <--dev
+-------------
+
+The commit "D" is called a "merge base" for branch "main" and "dev"
+because it's the best common ancestor for these branches for a merge.
+
+Now let's suppose that commit J is bad and commit G is good and that
+we apply the bisection algorithm like it has been previously
+described.
+
+As described in step 1) b) of the bisection algorithm, we remove all
+the ancestors of the good commits because they are supposed to be good
+too.
+
+So we would be left with only:
+
+-------------
+H-I-J
+-------------
+
+But what happens if the first bad commit is "B" and if it has been
+fixed in the "main" branch by commit "F"?
+
+The result of such a bisection would be that we would find that H is
+the first bad commit, when in fact it's B. So that would be wrong!
+
+And yes it can happen in practice that people working on one branch
+are not aware that people working on another branch fixed a bug! It
+could also happen that F fixed more than one bug or that it is a
+revert of some big development effort that was not ready to be
+released.
+
+In fact development teams often maintain both a development branch and
+a maintenance branch, and it would be quite easy for them if "git
+bisect" just worked when they want to bisect a regression on the
+development branch that is not on the maintenance branch. They should
+be able to start bisecting using:
+
+-------------
+$ git bisect start dev main
+-------------
+
+To enable that additional nice feature, when a bisection is started
+and when some good commits are not ancestors of the bad commit, we
+first compute the merge bases between the bad and the good commits and
+we chose these merge bases as the first commits that will be checked
+out and tested.
+
+If it happens that one merge base is bad, then the bisection process
+is stopped with a message like:
+
+-------------
+The merge base BBBBBB is bad.
+This means the bug has been fixed between BBBBBB and [GGGGGG,...].
+-------------
+
+where BBBBBB is the sha1 hash of the bad merge base and [GGGGGG,...]
+is a comma separated list of the sha1 of the good commits.
+
+If some of the merge bases are skipped, then the bisection process
+continues, but the following message is printed for each skipped merge
+base:
+
+-------------
+Warning: the merge base between BBBBBB and [GGGGGG,...] must be skipped.
+So we cannot be sure the first bad commit is between MMMMMM and BBBBBB.
+We continue anyway.
+-------------
+
+where BBBBBB is the sha1 hash of the bad commit, MMMMMM is the sha1
+hash of the merge base that is skipped and [GGGGGG,...] is a comma
+separated list of the sha1 of the good commits.
+
+So if there is no bad merge base, the bisection process continues as
+usual after this step.
+
+Best bisecting practices
+------------------------
+
+Using test suites and git bisect together
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If you both have a test suite and use git bisect, then it becomes less
+important to check that all tests pass after each commit. Though of
+course it is probably a good idea to have some checks to avoid
+breaking too many things because it could make bisecting other bugs
+more difficult.
+
+You can focus your efforts to check at a few points (for example rc
+and beta releases) that all the T test cases pass for all the N
+configurations. And when some tests don't pass you can use "git
+bisect" (or better "git bisect run"). So you should perform roughly:
+
+-------------
+c * N * T + b * M * log2(M) tests
+-------------
+
+where c is the number of rounds of test (so a small constant) and b is
+the ratio of bug per commit (hopefully a small constant too).
+
+So of course it's much better as it's O(N * T) vs O(N * T * M) if
+you would test everything after each commit.
+
+This means that test suites are good to prevent some bugs from being
+committed and they are also quite good to tell you that you have some
+bugs. But they are not so good to tell you where some bugs have been
+introduced. To tell you that efficiently, git bisect is needed.
+
+The other nice thing with test suites, is that when you have one, you
+already know how to test for bad behavior. So you can use this
+knowledge to create a new test case for "git bisect" when it appears
+that there is a regression. So it will be easier to bisect the bug and
+fix it. And then you can add the test case you just created to your
+test suite.
+
+So if you know how to create test cases and how to bisect, you will be
+subject to a virtuous circle:
+
+more tests => easier to create tests => easier to bisect => more tests
+
+So test suites and "git bisect" are complementary tools that are very
+powerful and efficient when used together.
+
+Bisecting build failures
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can very easily automatically bisect broken builds using something
+like:
+
+-------------
+$ git bisect start BAD GOOD
+$ git bisect run make
+-------------
+
+Passing sh -c "some commands" to "git bisect run"
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+For example:
+
+-------------
+$ git bisect run sh -c "make || exit 125; ./my_app | grep 'good output'"
+-------------
+
+On the other hand if you do this often, then it can be worth having
+scripts to avoid too much typing.
+
+Finding performance regressions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Here is an example script that comes slightly modified from a real
+world script used by Junio Hamano <<4>>.
+
+This script can be passed to "git bisect run" to find the commit that
+introduced a performance regression:
+
+-------------
+#!/bin/sh
+
+# Build errors are not what I am interested in.
+make my_app || exit 255
+
+# We are checking if it stops in a reasonable amount of time, so
+# let it run in the background...
+
+./my_app >log 2>&1 &
+
+# ... and grab its process ID.
+pid=$!
+
+# ... and then wait for sufficiently long.
+sleep $NORMAL_TIME
+
+# ... and then see if the process is still there.
+if kill -0 $pid
+then
+ # It is still running -- that is bad.
+ kill $pid; sleep 1; kill $pid;
+ exit 1
+else
+ # It has already finished (the $pid process was no more),
+ # and we are happy.
+ exit 0
+fi
+-------------
+
+Following general best practices
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It is obviously a good idea not to have commits with changes that
+knowingly break things, even if some other commits later fix the
+breakage.
+
+It is also a good idea when using any VCS to have only one small
+logical change in each commit.
+
+The smaller the changes in your commit, the most effective "git
+bisect" will be. And you will probably need "git bisect" less in the
+first place, as small changes are easier to review even if they are
+only reviewed by the committer.
+
+Another good idea is to have good commit messages. They can be very
+helpful to understand why some changes were made.
+
+These general best practices are very helpful if you bisect often.
+
+Avoiding bug prone merges
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+First merges by themselves can introduce some regressions even when
+the merge needs no source code conflict resolution. This is because a
+semantic change can happen in one branch while the other branch is not
+aware of it.
+
+For example one branch can change the semantic of a function while the
+other branch add more calls to the same function.
+
+This is made much worse if many files have to be fixed to resolve
+conflicts. That's why such merges are called "evil merges". They can
+make regressions very difficult to track down. It can even be
+misleading to know the first bad commit if it happens to be such a
+merge, because people might think that the bug comes from bad conflict
+resolution when it comes from a semantic change in one branch.
+
+Anyway "git rebase" can be used to linearize history. This can be used
+either to avoid merging in the first place. Or it can be used to
+bisect on a linear history instead of the non linear one, as this
+should give more information in case of a semantic change in one
+branch.
+
+Merges can be also made simpler by using smaller branches or by using
+many topic branches instead of only long version related branches.
+
+And testing can be done more often in special integration branches
+like linux-next for the linux kernel.
+
+Adapting your work-flow
+~~~~~~~~~~~~~~~~~~~~~~~
+
+A special work-flow to process regressions can give great results.
+
+Here is an example of a work-flow used by Andreas Ericsson:
+
+* write, in the test suite, a test script that exposes the regression
+* use "git bisect run" to find the commit that introduced it
+* fix the bug that is often made obvious by the previous step
+* commit both the fix and the test script (and if needed more tests)
+
+And here is what Andreas said about this work-flow <<5>>:
+
+_____________
+To give some hard figures, we used to have an average report-to-fix
+cycle of 142.6 hours (according to our somewhat weird bug-tracker
+which just measures wall-clock time). Since we moved to Git, we've
+lowered that to 16.2 hours. Primarily because we can stay on top of
+the bug fixing now, and because everyone's jockeying to get to fix
+bugs (we're quite proud of how lazy we are to let Git find the bugs
+for us). Each new release results in ~40% fewer bugs (almost certainly
+due to how we now feel about writing tests).
+_____________
+
+Clearly this work-flow uses the virtuous circle between test suites
+and "git bisect". In fact it makes it the standard procedure to deal
+with regression.
+
+In other messages Andreas says that they also use the "best practices"
+described above: small logical commits, topic branches, no evil
+merge,... These practices all improve the bisectability of the commit
+graph, by making it easier and more useful to bisect.
+
+So a good work-flow should be designed around the above points. That
+is making bisecting easier, more useful and standard.
+
+Involving QA people and if possible end users
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+One nice about "git bisect" is that it is not only a developer
+tool. It can effectively be used by QA people or even end users (if
+they have access to the source code or if they can get access to all
+the builds).
+
+There was a discussion at one point on the linux kernel mailing list
+of whether it was ok to always ask end user to bisect, and very good
+points were made to support the point of view that it is ok.
+
+For example David Miller wrote <<6>>:
+
+_____________
+What people don't get is that this is a situation where the "end node
+principle" applies. When you have limited resources (here: developers)
+you don't push the bulk of the burden upon them. Instead you push
+things out to the resource you have a lot of, the end nodes (here:
+users), so that the situation actually scales.
+_____________
+
+This means that it is often "cheaper" if QA people or end users can do
+it.
+
+What is interesting too is that end users that are reporting bugs (or
+QA people that reproduced a bug) have access to the environment where
+the bug happens. So they can often more easily reproduce a
+regression. And if they can bisect, then more information will be
+extracted from the environment where the bug happens, which means that
+it will be easier to understand and then fix the bug.
+
+For open source projects it can be a good way to get more useful
+contributions from end users, and to introduce them to QA and
+development activities.
+
+Using complex scripts
+~~~~~~~~~~~~~~~~~~~~~
+
+In some cases like for kernel development it can be worth developing
+complex scripts to be able to fully automate bisecting.
+
+Here is what Ingo Molnar says about that <<7>>:
+
+_____________
+i have a fully automated bootup-hang bisection script. It is based on
+"git-bisect run". I run the script, it builds and boots kernels fully
+automatically, and when the bootup fails (the script notices that via
+the serial log, which it continuously watches - or via a timeout, if
+the system does not come up within 10 minutes it's a "bad" kernel),
+the script raises my attention via a beep and i power cycle the test
+box. (yeah, i should make use of a managed power outlet to 100%
+automate it)
+_____________
+
+Combining test suites, git bisect and other systems together
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+We have seen that test suites and git bisect are very powerful when
+used together. It can be even more powerful if you can combine them
+with other systems.
+
+For example some test suites could be run automatically at night with
+some unusual (or even random) configurations. And if a regression is
+found by a test suite, then "git bisect" can be automatically
+launched, and its result can be emailed to the author of the first bad
+commit found by "git bisect", and perhaps other people too. And a new
+entry in the bug tracking system could be automatically created too.
+
+
+The future of bisecting
+-----------------------
+
+"git replace"
+~~~~~~~~~~~~~
+
+We saw earlier that "git bisect skip" is now using a PRNG to try to
+avoid areas in the commit graph where commits are untestable. The
+problem is that sometimes the first bad commit will be in an
+untestable area.
+
+To simplify the discussion we will suppose that the untestable area is
+a simple string of commits and that it was created by a breakage
+introduced by one commit (let's call it BBC for bisect breaking
+commit) and later fixed by another one (let's call it BFC for bisect
+fixing commit).
+
+For example:
+
+-------------
+...-Y-BBC-X1-X2-X3-X4-X5-X6-BFC-Z-...
+-------------
+
+where we know that Y is good and BFC is bad, and where BBC and X1 to
+X6 are untestable.
+
+In this case if you are bisecting manually, what you can do is create
+a special branch that starts just before the BBC. The first commit in
+this branch should be the BBC with the BFC squashed into it. And the
+other commits in the branch should be the commits between BBC and BFC
+rebased on the first commit of the branch and then the commit after
+BFC also rebased on.
+
+For example:
+
+-------------
+ (BBC+BFC)-X1'-X2'-X3'-X4'-X5'-X6'-Z'
+ /
+...-Y-BBC-X1-X2-X3-X4-X5-X6-BFC-Z-...
+-------------
+
+where commits quoted with ' have been rebased.
+
+You can easily create such a branch with Git using interactive rebase.
+
+For example using:
+
+-------------
+$ git rebase -i Y Z
+-------------
+
+and then moving BFC after BBC and squashing it.
+
+After that you can start bisecting as usual in the new branch and you
+should eventually find the first bad commit.
+
+For example:
+
+-------------
+$ git bisect start Z' Y
+-------------
+
+If you are using "git bisect run", you can use the same manual fix up
+as above, and then start another "git bisect run" in the special
+branch. Or as the "git bisect" man page says, the script passed to
+"git bisect run" can apply a patch before it compiles and test the
+software <<8>>. The patch should turn a current untestable commits
+into a testable one. So the testing will result in "good" or "bad" and
+"git bisect" will be able to find the first bad commit. And the script
+should not forget to remove the patch once the testing is done before
+exiting from the script.
+
+(Note that instead of a patch you can use "git cherry-pick BFC" to
+apply the fix, and in this case you should use "git reset --hard
+HEAD^" to revert the cherry-pick after testing and before returning
+from the script.)
+
+But the above ways to work around untestable areas are a little bit
+clunky. Using special branches is nice because these branches can be
+shared by developers like usual branches, but the risk is that people
+will get many such branches. And it disrupts the normal "git bisect"
+work-flow. So, if you want to use "git bisect run" completely
+automatically, you have to add special code in your script to restart
+bisection in the special branches.
+
+Anyway one can notice in the above special branch example that the Z'
+and Z commits should point to the same source code state (the same
+"tree" in git parlance). That's because Z' result from applying the
+same changes as Z just in a slightly different order.
+
+So if we could just "replace" Z by Z' when we bisect, then we would
+not need to add anything to a script. It would just work for anyone in
+the project sharing the special branches and the replacements.
+
+With the example above that would give:
+
+-------------
+ (BBC+BFC)-X1'-X2'-X3'-X4'-X5'-X6'-Z'-...
+ /
+...-Y-BBC-X1-X2-X3-X4-X5-X6-BFC-Z
+-------------
+
+That's why the "git replace" command was created. Technically it
+stores replacements "refs" in the "refs/replace/" hierarchy. These
+"refs" are like branches (that are stored in "refs/heads/") or tags
+(that are stored in "refs/tags"), and that means that they can
+automatically be shared like branches or tags among developers.
+
+"git replace" is a very powerful mechanism. It can be used to fix
+commits in already released history, for example to change the commit
+message or the author. And it can also be used instead of git "grafts"
+to link a repository with another old repository.
+
+In fact it's this last feature that "sold" it to the Git community, so
+it is now in the "master" branch of Git's Git repository and it should
+be released in Git 1.6.5 in October or November 2009.
+
+One problem with "git replace" is that currently it stores all the
+replacements refs in "refs/replace/", but it would be perhaps better
+if the replacement refs that are useful only for bisecting would be in
+"refs/replace/bisect/". This way the replacement refs could be used
+only for bisecting, while other refs directly in "refs/replace/" would
+be used nearly all the time.
+
+Bisecting sporadic bugs
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Another possible improvement to "git bisect" would be to optionally
+add some redundancy to the tests performed so that it would be more
+reliable when tracking sporadic bugs.
+
+This has been requested by some kernel developers because some bugs
+called sporadic bugs do not appear in all the kernel builds because
+they are very dependent on the compiler output.
+
+The idea is that every 3 test for example, "git bisect" could ask the
+user to test a commit that has already been found to be "good" or
+"bad" (because one of its descendants or one of its ancestors has been
+found to be "good" or "bad" respectively). If it happens that a commit
+has been previously incorrectly classified then the bisection can be
+aborted early, hopefully before too many mistakes have been made. Then
+the user will have to look at what happened and then restart the
+bisection using a fixed bisect log.
+
+There is already a project called BBChop created by Ealdwulf Wuffinga
+on Github that does something like that using Bayesian Search Theory
+<<9>>:
+
+_____________
+BBChop is like 'git bisect' (or equivalent), but works when your bug
+is intermittent. That is, it works in the presence of false negatives
+(when a version happens to work this time even though it contains the
+bug). It assumes that there are no false positives (in principle, the
+same approach would work, but adding it may be non-trivial).
+_____________
+
+But BBChop is independent of any VCS and it would be easier for Git
+users to have something integrated in Git.
+
+Conclusion
+----------
+
+We have seen that regressions are an important problem, and that "git
+bisect" has nice features that complement very well practices and
+other tools, especially test suites, that are generally used to fight
+regressions. But it might be needed to change some work-flows and
+(bad) habits to get the most out of it.
+
+Some improvements to the algorithms inside "git bisect" are possible
+and some new features could help in some cases, but overall "git
+bisect" works already very well, is used a lot, and is already very
+useful. To back up that last claim, let's give the final word to Ingo
+Molnar when he was asked by the author how much time does he think
+"git bisect" saves him when he uses it:
+
+_____________
+a _lot_.
+
+About ten years ago did i do my first 'bisection' of a Linux patch
+queue. That was prior the Git (and even prior the BitKeeper) days. I
+literally days spent sorting out patches, creating what in essence
+were standalone commits that i guessed to be related to that bug.
+
+It was a tool of absolute last resort. I'd rather spend days looking
+at printk output than do a manual 'patch bisection'.
+
+With Git bisect it's a breeze: in the best case i can get a ~15 step
+kernel bisection done in 20-30 minutes, in an automated way. Even with
+manual help or when bisecting multiple, overlapping bugs, it's rarely
+more than an hour.
+
+In fact it's invaluable because there are bugs i would never even
+_try_ to debug if it wasn't for git bisect. In the past there were bug
+patterns that were immediately hopeless for me to debug - at best i
+could send the crash/bug signature to lkml and hope that someone else
+can think of something.
+
+And even if a bisection fails today it tells us something valuable
+about the bug: that it's non-deterministic - timing or kernel image
+layout dependent.
+
+So git bisect is unconditional goodness - and feel free to quote that
+;-)
+_____________
+
+Acknowledgments
+---------------
+
+Many thanks to Junio Hamano for his help in reviewing this paper, for
+reviewing the patches I sent to the Git mailing list, for discussing
+some ideas and helping me improve them, for improving "git bisect" a
+lot and for his awesome work in maintaining and developing Git.
+
+Many thanks to Ingo Molnar for giving me very useful information that
+appears in this paper, for commenting on this paper, for his
+suggestions to improve "git bisect" and for evangelizing "git bisect"
+on the linux kernel mailing lists.
+
+Many thanks to Linus Torvalds for inventing, developing and
+evangelizing "git bisect", Git and Linux.
+
+Many thanks to the many other great people who helped one way or
+another when I worked on Git, especially to Andreas Ericsson, Johannes
+Schindelin, H. Peter Anvin, Daniel Barkalow, Bill Lear, John Hawley,
+Shawn O. Pierce, Jeff King, Sam Vilain, Jon Seymour.
+
+Many thanks to the Linux-Kongress program committee for choosing the
+author to given a talk and for publishing this paper.
+
+References
+----------
+
+- [[[1]]] https://web.archive.org/web/20091206032101/http://www.nist.gov/public_affairs/releases/n02-10.htm['Software Errors Cost U.S. Economy $59.5 Billion Annually'. Nist News Release.] See also https://www.nist.gov/system/files/documents/director/planning/report02-3.pdf['The Economic Impacts of Inadequate Infratructure for Software Testing'. Nist Planning Report 02-3], Executive Summary and Chapter 8.
+- [[[2]]] https://www.oracle.com/java/technologies/javase/codeconventions-introduction.html['Code Conventions for the Java Programming Language: 1. Introduction'. Sun Microsystems.]
+- [[[3]]] https://en.wikipedia.org/wiki/Software_maintenance['Software maintenance'. Wikipedia.]
+- [[[4]]] https://lore.kernel.org/git/7vps5xsbwp.fsf_-_@assigned-by-dhcp.cox.net/[Junio C Hamano. 'Automated bisect success story'.]
+- [[[5]]] https://lwn.net/Articles/317154/[Christian Couder. 'Fully automated bisecting with "git bisect run"'. LWN.net.]
+- [[[6]]] https://lwn.net/Articles/277872/[Jonathan Corbet. 'Bisection divides users and developers'. LWN.net.]
+- [[[7]]] https://lore.kernel.org/lkml/20071207113734.GA14598@elte.hu/[Ingo Molnar. 'Re: BUG 2.6.23-rc3 can't see sd partitions on Alpha'. Linux-kernel mailing list.]
+- [[[8]]] https://www.kernel.org/pub/software/scm/git/docs/git-bisect.html[Junio C Hamano and the git-list. 'git-bisect(1) Manual Page'. Linux Kernel Archives.]
+- [[[9]]] https://github.com/Ealdwulf/bbchop[Ealdwulf. 'bbchop'. GitHub.]
diff --git a/git-bisect.adoc b/git-bisect.adoc
new file mode 100644
index 0000000..82f944d
--- /dev/null
+++ b/git-bisect.adoc
@@ -0,0 +1,517 @@
+git-bisect(1)
+=============
+
+NAME
+----
+git-bisect - Use binary search to find the commit that introduced a bug
+
+
+SYNOPSIS
+--------
+[verse]
+'git bisect' <subcommand> <options>
+
+DESCRIPTION
+-----------
+The command takes various subcommands, and different options depending
+on the subcommand:
+
+ git bisect start [--term-(bad|new)=<term-new> --term-(good|old)=<term-old>]
+ [--no-checkout] [--first-parent] [<bad> [<good>...]] [--] [<pathspec>...]
+ git bisect (bad|new|<term-new>) [<rev>]
+ git bisect (good|old|<term-old>) [<rev>...]
+ git bisect terms [--term-(good|old) | --term-(bad|new)]
+ git bisect skip [(<rev>|<range>)...]
+ git bisect reset [<commit>]
+ git bisect (visualize|view)
+ git bisect replay <logfile>
+ git bisect log
+ git bisect run <cmd> [<arg>...]
+ git bisect help
+
+This command uses a binary search algorithm to find which commit in
+your project's history introduced a bug. You use it by first telling
+it a "bad" commit that is known to contain the bug, and a "good"
+commit that is known to be before the bug was introduced. Then `git
+bisect` picks a commit between those two endpoints and asks you
+whether the selected commit is "good" or "bad". It continues narrowing
+down the range until it finds the exact commit that introduced the
+change.
+
+In fact, `git bisect` can be used to find the commit that changed
+*any* property of your project; e.g., the commit that fixed a bug, or
+the commit that caused a benchmark's performance to improve. To
+support this more general usage, the terms "old" and "new" can be used
+in place of "good" and "bad", or you can choose your own terms. See
+section "Alternate terms" below for more information.
+
+Basic bisect commands: start, bad, good
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+As an example, suppose you are trying to find the commit that broke a
+feature that was known to work in version `v2.6.13-rc2` of your
+project. You start a bisect session as follows:
+
+------------------------------------------------
+$ git bisect start
+$ git bisect bad # Current version is bad
+$ git bisect good v2.6.13-rc2 # v2.6.13-rc2 is known to be good
+------------------------------------------------
+
+Once you have specified at least one bad and one good commit, `git
+bisect` selects a commit in the middle of that range of history,
+checks it out, and outputs something similar to the following:
+
+------------------------------------------------
+Bisecting: 675 revisions left to test after this (roughly 10 steps)
+------------------------------------------------
+
+You should now compile the checked-out version and test it. If that
+version works correctly, type
+
+------------------------------------------------
+$ git bisect good
+------------------------------------------------
+
+If that version is broken, type
+
+------------------------------------------------
+$ git bisect bad
+------------------------------------------------
+
+Then `git bisect` will respond with something like
+
+------------------------------------------------
+Bisecting: 337 revisions left to test after this (roughly 9 steps)
+------------------------------------------------
+
+Keep repeating the process: compile the tree, test it, and depending
+on whether it is good or bad run `git bisect good` or `git bisect bad`
+to ask for the next commit that needs testing.
+
+Eventually there will be no more revisions left to inspect, and the
+command will print out a description of the first bad commit. The
+reference `refs/bisect/bad` will be left pointing at that commit.
+
+
+Bisect reset
+~~~~~~~~~~~~
+
+After a bisect session, to clean up the bisection state and return to
+the original HEAD, issue the following command:
+
+------------------------------------------------
+$ git bisect reset
+------------------------------------------------
+
+By default, this will return your tree to the commit that was checked
+out before `git bisect start`. (A new `git bisect start` will also do
+that, as it cleans up the old bisection state.)
+
+With an optional argument, you can return to a different commit
+instead:
+
+------------------------------------------------
+$ git bisect reset <commit>
+------------------------------------------------
+
+For example, `git bisect reset bisect/bad` will check out the first
+bad revision, while `git bisect reset HEAD` will leave you on the
+current bisection commit and avoid switching commits at all.
+
+
+Alternate terms
+~~~~~~~~~~~~~~~
+
+Sometimes you are not looking for the commit that introduced a
+breakage, but rather for a commit that caused a change between some
+other "old" state and "new" state. For example, you might be looking
+for the commit that introduced a particular fix. Or you might be
+looking for the first commit in which the source-code filenames were
+finally all converted to your company's naming standard. Or whatever.
+
+In such cases it can be very confusing to use the terms "good" and
+"bad" to refer to "the state before the change" and "the state after
+the change". So instead, you can use the terms "old" and "new",
+respectively, in place of "good" and "bad". (But note that you cannot
+mix "good" and "bad" with "old" and "new" in a single session.)
+
+In this more general usage, you provide `git bisect` with a "new"
+commit that has some property and an "old" commit that doesn't have that
+property. Each time `git bisect` checks out a commit, you test if that
+commit has the property. If it does, mark the commit as "new";
+otherwise, mark it as "old". When the bisection is done, `git bisect`
+will report which commit introduced the property.
+
+To use "old" and "new" instead of "good" and bad, you must run `git
+bisect start` without commits as argument and then run the following
+commands to add the commits:
+
+------------------------------------------------
+git bisect old [<rev>]
+------------------------------------------------
+
+to indicate that a commit was before the sought change, or
+
+------------------------------------------------
+git bisect new [<rev>...]
+------------------------------------------------
+
+to indicate that it was after.
+
+To get a reminder of the currently used terms, use
+
+------------------------------------------------
+git bisect terms
+------------------------------------------------
+
+You can get just the old term with `git bisect terms --term-old`
+or `git bisect terms --term-good`; `git bisect terms --term-new`
+and `git bisect terms --term-bad` can be used to learn how to call
+the commits more recent than the sought change.
+
+If you would like to use your own terms instead of "bad"/"good" or
+"new"/"old", you can choose any names you like (except existing bisect
+subcommands like `reset`, `start`, ...) by starting the
+bisection using
+
+------------------------------------------------
+git bisect start --term-old <term-old> --term-new <term-new>
+------------------------------------------------
+
+For example, if you are looking for a commit that introduced a
+performance regression, you might use
+
+------------------------------------------------
+git bisect start --term-old fast --term-new slow
+------------------------------------------------
+
+Or if you are looking for the commit that fixed a bug, you might use
+
+------------------------------------------------
+git bisect start --term-new fixed --term-old broken
+------------------------------------------------
+
+Then, use `git bisect <term-old>` and `git bisect <term-new>` instead
+of `git bisect good` and `git bisect bad` to mark commits.
+
+Bisect visualize/view
+~~~~~~~~~~~~~~~~~~~~~
+
+To see the currently remaining suspects in 'gitk', issue the following
+command during the bisection process (the subcommand `view` can be used
+as an alternative to `visualize`):
+
+------------
+$ git bisect visualize
+------------
+
+Git detects a graphical environment through various environment variables:
+`DISPLAY`, which is set in X Window System environments on Unix systems.
+`SESSIONNAME`, which is set under Cygwin in interactive desktop sessions.
+`MSYSTEM`, which is set under Msys2 and Git for Windows.
+`SECURITYSESSIONID`, which may be set on macOS in interactive desktop sessions.
+
+If none of these environment variables is set, 'git log' is used instead.
+You can also give command-line options such as `-p` and `--stat`.
+
+------------
+$ git bisect visualize --stat
+------------
+
+Bisect log and bisect replay
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+After having marked revisions as good or bad, issue the following
+command to show what has been done so far:
+
+------------
+$ git bisect log
+------------
+
+If you discover that you made a mistake in specifying the status of a
+revision, you can save the output of this command to a file, edit it to
+remove the incorrect entries, and then issue the following commands to
+return to a corrected state:
+
+------------
+$ git bisect reset
+$ git bisect replay that-file
+------------
+
+Avoiding testing a commit
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If, in the middle of a bisect session, you know that the suggested
+revision is not a good one to test (e.g. it fails to build and you
+know that the failure does not have anything to do with the bug you
+are chasing), you can manually select a nearby commit and test that
+one instead.
+
+For example:
+
+------------
+$ git bisect good/bad # previous round was good or bad.
+Bisecting: 337 revisions left to test after this (roughly 9 steps)
+$ git bisect visualize # oops, that is uninteresting.
+$ git reset --hard HEAD~3 # try 3 revisions before what
+ # was suggested
+------------
+
+Then compile and test the chosen revision, and afterwards mark
+the revision as good or bad in the usual manner.
+
+Bisect skip
+~~~~~~~~~~~
+
+Instead of choosing a nearby commit by yourself, you can ask Git to do
+it for you by issuing the command:
+
+------------
+$ git bisect skip # Current version cannot be tested
+------------
+
+However, if you skip a commit adjacent to the one you are looking for,
+Git will be unable to tell exactly which of those commits was the
+first bad one.
+
+You can also skip a range of commits, instead of just one commit,
+using range notation. For example:
+
+------------
+$ git bisect skip v2.5..v2.6
+------------
+
+This tells the bisect process that no commit after `v2.5`, up to and
+including `v2.6`, should be tested.
+
+Note that if you also want to skip the first commit of the range you
+would issue the command:
+
+------------
+$ git bisect skip v2.5 v2.5..v2.6
+------------
+
+This tells the bisect process that the commits between `v2.5` and
+`v2.6` (inclusive) should be skipped.
+
+
+Cutting down bisection by giving more parameters to bisect start
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can further cut down the number of trials, if you know what part of
+the tree is involved in the problem you are tracking down, by specifying
+pathspec parameters when issuing the `bisect start` command:
+
+------------
+$ git bisect start -- arch/i386 include/asm-i386
+------------
+
+If you know beforehand more than one good commit, you can narrow the
+bisect space down by specifying all of the good commits immediately after
+the bad commit when issuing the `bisect start` command:
+
+------------
+$ git bisect start v2.6.20-rc6 v2.6.20-rc4 v2.6.20-rc1 --
+ # v2.6.20-rc6 is bad
+ # v2.6.20-rc4 and v2.6.20-rc1 are good
+------------
+
+Bisect run
+~~~~~~~~~~
+
+If you have a script that can tell if the current source code is good
+or bad, you can bisect by issuing the command:
+
+------------
+$ git bisect run my_script arguments
+------------
+
+Note that the script (`my_script` in the above example) should exit
+with code 0 if the current source code is good/old, and exit with a
+code between 1 and 127 (inclusive), except 125, if the current source
+code is bad/new.
+
+Any other exit code will abort the bisect process. It should be noted
+that a program that terminates via `exit(-1)` leaves $? = 255, (see the
+exit(3) manual page), as the value is chopped with `& 0377`.
+
+The special exit code 125 should be used when the current source code
+cannot be tested. If the script exits with this code, the current
+revision will be skipped (see `git bisect skip` above). 125 was chosen
+as the highest sensible value to use for this purpose, because 126 and 127
+are used by POSIX shells to signal specific error status (127 is for
+command not found, 126 is for command found but not executable--these
+details do not matter, as they are normal errors in the script, as far as
+`bisect run` is concerned).
+
+You may often find that during a bisect session you want to have
+temporary modifications (e.g. s/#define DEBUG 0/#define DEBUG 1/ in a
+header file, or "revision that does not have this commit needs this
+patch applied to work around another problem this bisection is not
+interested in") applied to the revision being tested.
+
+To cope with such a situation, after the inner 'git bisect' finds the
+next revision to test, the script can apply the patch
+before compiling, run the real test, and afterwards decide if the
+revision (possibly with the needed patch) passed the test and then
+rewind the tree to the pristine state. Finally the script should exit
+with the status of the real test to let the `git bisect run` command loop
+determine the eventual outcome of the bisect session.
+
+OPTIONS
+-------
+--no-checkout::
++
+Do not checkout the new working tree at each iteration of the bisection
+process. Instead just update the reference named `BISECT_HEAD` to make
+it point to the commit that should be tested.
++
+This option may be useful when the test you would perform in each step
+does not require a checked out tree.
++
+If the repository is bare, `--no-checkout` is assumed.
+
+--first-parent::
++
+Follow only the first parent commit upon seeing a merge commit.
++
+In detecting regressions introduced through the merging of a branch, the merge
+commit will be identified as introduction of the bug and its ancestors will be
+ignored.
++
+This option is particularly useful in avoiding false positives when a merged
+branch contained broken or non-buildable commits, but the merge itself was OK.
+
+EXAMPLES
+--------
+
+* Automatically bisect a broken build between v1.2 and HEAD:
++
+------------
+$ git bisect start HEAD v1.2 -- # HEAD is bad, v1.2 is good
+$ git bisect run make # "make" builds the app
+$ git bisect reset # quit the bisect session
+------------
+
+* Automatically bisect a test failure between origin and HEAD:
++
+------------
+$ git bisect start HEAD origin -- # HEAD is bad, origin is good
+$ git bisect run make test # "make test" builds and tests
+$ git bisect reset # quit the bisect session
+------------
+
+* Automatically bisect a broken test case:
++
+------------
+$ cat ~/test.sh
+#!/bin/sh
+make || exit 125 # this skips broken builds
+~/check_test_case.sh # does the test case pass?
+$ git bisect start HEAD HEAD~10 -- # culprit is among the last 10
+$ git bisect run ~/test.sh
+$ git bisect reset # quit the bisect session
+------------
++
+Here we use a `test.sh` custom script. In this script, if `make`
+fails, we skip the current commit.
+`check_test_case.sh` should `exit 0` if the test case passes,
+and `exit 1` otherwise.
++
+It is safer if both `test.sh` and `check_test_case.sh` are
+outside the repository to prevent interactions between the bisect,
+make and test processes and the scripts.
+
+* Automatically bisect with temporary modifications (hot-fix):
++
+------------
+$ cat ~/test.sh
+#!/bin/sh
+
+# tweak the working tree by merging the hot-fix branch
+# and then attempt a build
+if git merge --no-commit --no-ff hot-fix &&
+ make
+then
+ # run project specific test and report its status
+ ~/check_test_case.sh
+ status=$?
+else
+ # tell the caller this is untestable
+ status=125
+fi
+
+# undo the tweak to allow clean flipping to the next commit
+git reset --hard
+
+# return control
+exit $status
+------------
++
+This applies modifications from a hot-fix branch before each test run,
+e.g. in case your build or test environment changed so that older
+revisions may need a fix which newer ones have already. (Make sure the
+hot-fix branch is based off a commit which is contained in all revisions
+which you are bisecting, so that the merge does not pull in too much, or
+use `git cherry-pick` instead of `git merge`.)
+
+* Automatically bisect a broken test case:
++
+------------
+$ git bisect start HEAD HEAD~10 -- # culprit is among the last 10
+$ git bisect run sh -c "make || exit 125; ~/check_test_case.sh"
+$ git bisect reset # quit the bisect session
+------------
++
+This shows that you can do without a run script if you write the test
+on a single line.
+
+* Locate a good region of the object graph in a damaged repository
++
+------------
+$ git bisect start HEAD <known-good-commit> [ <boundary-commit> ... ] --no-checkout
+$ git bisect run sh -c '
+ GOOD=$(git for-each-ref "--format=%(objectname)" refs/bisect/good-*) &&
+ git rev-list --objects BISECT_HEAD --not $GOOD >tmp.$$ &&
+ git pack-objects --stdout >/dev/null <tmp.$$
+ rc=$?
+ rm -f tmp.$$
+ test $rc = 0'
+
+$ git bisect reset # quit the bisect session
+------------
++
+In this case, when 'git bisect run' finishes, bisect/bad will refer to a commit that
+has at least one parent whose reachable graph is fully traversable in the sense
+required by 'git pack objects'.
+
+* Look for a fix instead of a regression in the code
++
+------------
+$ git bisect start
+$ git bisect new HEAD # current commit is marked as new
+$ git bisect old HEAD~10 # the tenth commit from now is marked as old
+------------
++
+or:
+------------
+$ git bisect start --term-old broken --term-new fixed
+$ git bisect fixed
+$ git bisect broken HEAD~10
+------------
+
+Getting help
+~~~~~~~~~~~~
+
+Use `git bisect` to get a short usage description, and `git bisect
+help` or `git bisect -h` to get a long usage description.
+
+SEE ALSO
+--------
+link:git-bisect-lk2009.html[Fighting regressions with git bisect],
+linkgit:git-blame[1].
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-blame.adoc b/git-blame.adoc
new file mode 100644
index 0000000..f75ed44
--- /dev/null
+++ b/git-blame.adoc
@@ -0,0 +1,257 @@
+git-blame(1)
+============
+
+NAME
+----
+git-blame - Show what revision and author last modified each line of a file
+
+SYNOPSIS
+--------
+[verse]
+'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental]
+ [-L <range>] [-S <revs-file>] [-M] [-C] [-C] [-C] [--since=<date>]
+ [--ignore-rev <rev>] [--ignore-revs-file <file>]
+ [--color-lines] [--color-by-age] [--progress] [--abbrev=<n>]
+ [ --contents <file> ] [<rev> | --reverse <rev>..<rev>] [--] <file>
+
+DESCRIPTION
+-----------
+
+Annotates each line in the given file with information from the revision which
+last modified the line. Optionally, start annotating from the given revision.
+
+When specified one or more times, `-L` restricts annotation to the requested
+lines.
+
+The origin of lines is automatically followed across whole-file
+renames (currently there is no option to turn the rename-following
+off). To follow lines moved from one file to another, or to follow
+lines that were copied and pasted from another file, etc., see the
+`-C` and `-M` options.
+
+The report does not tell you anything about lines which have been deleted or
+replaced; you need to use a tool such as 'git diff' or the "pickaxe"
+interface briefly mentioned in the following paragraph.
+
+Apart from supporting file annotation, Git also supports searching the
+development history for when a code snippet occurred in a change. This makes it
+possible to track when a code snippet was added to a file, moved or copied
+between files, and eventually deleted or replaced. It works by searching for
+a text string in the diff. A small example of the pickaxe interface
+that searches for `blame_usage`:
+
+-----------------------------------------------------------------------------
+$ git log --pretty=oneline -S'blame_usage'
+5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file>
+ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output
+-----------------------------------------------------------------------------
+
+OPTIONS
+-------
+include::blame-options.adoc[]
+
+-c::
+ Use the same output mode as linkgit:git-annotate[1] (Default: off).
+
+--score-debug::
+ Include debugging information related to the movement of
+ lines between files (see `-C`) and lines moved within a
+ file (see `-M`). The first number listed is the score.
+ This is the number of alphanumeric characters detected
+ as having been moved between or within files. This must be above
+ a certain threshold for 'git blame' to consider those lines
+ of code to have been moved.
+
+-f::
+--show-name::
+ Show the filename in the original commit. By default
+ the filename is shown if there is any line that came from a
+ file with a different name, due to rename detection.
+
+-n::
+--show-number::
+ Show the line number in the original commit (Default: off).
+
+-s::
+ Suppress the author name and timestamp from the output.
+
+-e::
+--show-email::
+ Show the author email instead of the author name (Default: off).
+ This can also be controlled via the `blame.showEmail` config
+ option.
+
+-w::
+ Ignore whitespace when comparing the parent's version and
+ the child's to find where the lines came from.
+
+--abbrev=<n>::
+ Instead of using the default 7+1 hexadecimal digits as the
+ abbreviated object name, use <m>+1 digits, where <m> is at
+ least <n> but ensures the commit object names are unique.
+ Note that 1 column
+ is used for a caret to mark the boundary commit.
+
+
+THE DEFAULT FORMAT
+------------------
+
+When neither `--porcelain` nor `--incremental` option is specified,
+`git blame` will output annotation for each line with:
+
+- abbreviated object name for the commit the line came from;
+- author ident (by default the author name and date, unless `-s` or `-e`
+ is specified); and
+- line number
+
+before the line contents.
+
+THE PORCELAIN FORMAT
+--------------------
+
+In this format, each line is output after a header; the
+header at the minimum has the first line which has:
+
+- 40-byte SHA-1 of the commit the line is attributed to;
+- the line number of the line in the original file;
+- the line number of the line in the final file;
+- on a line that starts a group of lines from a different
+ commit than the previous one, the number of lines in this
+ group. On subsequent lines this field is absent.
+
+This header line is followed by the following information
+at least once for each commit:
+
+- the author name ("author"), email ("author-mail"), time
+ ("author-time"), and time zone ("author-tz"); similarly
+ for committer.
+- the filename in the commit that the line is attributed to.
+- the first line of the commit log message ("summary").
+
+The contents of the actual line are output after the above
+header, prefixed by a TAB. This is to allow adding more
+header elements later.
+
+The porcelain format generally suppresses commit information that has
+already been seen. For example, two lines that are blamed to the same
+commit will both be shown, but the details for that commit will be shown
+only once. This is more efficient, but may require more state be kept by
+the reader. The `--line-porcelain` option can be used to output full
+commit information for each line, allowing simpler (but less efficient)
+usage like:
+
+ # count the number of lines attributed to each author
+ git blame --line-porcelain file |
+ sed -n 's/^author //p' |
+ sort | uniq -c | sort -rn
+
+
+SPECIFYING RANGES
+-----------------
+
+Unlike 'git blame' and 'git annotate' in older versions of git, the extent
+of the annotation can be limited to both line ranges and revision
+ranges. The `-L` option, which limits annotation to a range of lines, may be
+specified multiple times.
+
+When you are interested in finding the origin for
+lines 40-60 for file `foo`, you can use the `-L` option like so
+(they mean the same thing -- both ask for 21 lines starting at
+line 40):
+
+ git blame -L 40,60 foo
+ git blame -L 40,+21 foo
+
+Also you can use a regular expression to specify the line range:
+
+ git blame -L '/^sub hello {/,/^}$/' foo
+
+which limits the annotation to the body of the `hello` subroutine.
+
+When you are not interested in changes older than version
+v2.6.18, or changes older than 3 weeks, you can use revision
+range specifiers similar to 'git rev-list':
+
+ git blame v2.6.18.. -- foo
+ git blame --since=3.weeks -- foo
+
+When revision range specifiers are used to limit the annotation,
+lines that have not changed since the range boundary (either the
+commit v2.6.18 or the most recent commit that is more than 3
+weeks old in the above example) are blamed for that range
+boundary commit.
+
+A particularly useful way is to see if an added file has lines
+created by copy-and-paste from existing files. Sometimes this
+indicates that the developer was being sloppy and did not
+refactor the code properly. You can first find the commit that
+introduced the file with:
+
+ git log --diff-filter=A --pretty=short -- foo
+
+and then annotate the change between the commit and its
+parents, using `commit^!` notation:
+
+ git blame -C -C -f $commit^! -- foo
+
+
+INCREMENTAL OUTPUT
+------------------
+
+When called with `--incremental` option, the command outputs the
+result as it is built. The output generally will talk about
+lines touched by more recent commits first (i.e. the lines will
+be annotated out of order) and is meant to be used by
+interactive viewers.
+
+The output format is similar to the Porcelain format, but it
+does not contain the actual lines from the file that is being
+annotated.
+
+. Each blame entry always starts with a line of:
+
+ <40-byte-hex-sha1> <sourceline> <resultline> <num-lines>
++
+Line numbers count from 1.
+
+. The first time that a commit shows up in the stream, it has various
+ other information about it printed out with a one-word tag at the
+ beginning of each line describing the extra commit information (author,
+ email, committer, dates, summary, etc.).
+
+. Unlike the Porcelain format, the filename information is always
+ given and terminates the entry:
+
+ "filename" <whitespace-quoted-filename-goes-here>
++
+and thus it is really quite easy to parse for some line- and word-oriented
+parser (which should be quite natural for most scripting languages).
++
+[NOTE]
+For people who do parsing: to make it more robust, just ignore any
+lines between the first and last one ("<sha1>" and "filename" lines)
+where you do not recognize the tag words (or care about that particular
+one) at the beginning of the "extended information" lines. That way, if
+there is ever added information (like the commit encoding or extended
+commit commentary), a blame viewer will not care.
+
+
+MAPPING AUTHORS
+---------------
+
+See linkgit:gitmailmap[5].
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/blame.adoc[]
+
+SEE ALSO
+--------
+linkgit:git-annotate[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-branch.adoc b/git-branch.adoc
new file mode 100644
index 0000000..7a073a3
--- /dev/null
+++ b/git-branch.adoc
@@ -0,0 +1,430 @@
+git-branch(1)
+=============
+
+NAME
+----
+git-branch - List, create, or delete branches
+
+SYNOPSIS
+--------
+[verse]
+'git branch' [--color[=<when>] | --no-color] [--show-current]
+ [-v [--abbrev=<n> | --no-abbrev]]
+ [--column[=<options>] | --no-column] [--sort=<key>]
+ [--merged [<commit>]] [--no-merged [<commit>]]
+ [--contains [<commit>]] [--no-contains [<commit>]]
+ [--points-at <object>] [--format=<format>]
+ [(-r | --remotes) | (-a | --all)]
+ [--list] [<pattern>...]
+'git branch' [--track[=(direct|inherit)] | --no-track] [-f]
+ [--recurse-submodules] <branchname> [<start-point>]
+'git branch' (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>]
+'git branch' --unset-upstream [<branchname>]
+'git branch' (-m | -M) [<oldbranch>] <newbranch>
+'git branch' (-c | -C) [<oldbranch>] <newbranch>
+'git branch' (-d | -D) [-r] <branchname>...
+'git branch' --edit-description [<branchname>]
+
+DESCRIPTION
+-----------
+
+If `--list` is given, or if there are no non-option arguments, existing
+branches are listed; the current branch will be highlighted in green and
+marked with an asterisk. Any branches checked out in linked worktrees will
+be highlighted in cyan and marked with a plus sign. Option `-r` causes the
+remote-tracking branches to be listed,
+and option `-a` shows both local and remote branches.
+
+If a `<pattern>`
+is given, it is used as a shell wildcard to restrict the output to
+matching branches. If multiple patterns are given, a branch is shown if
+it matches any of the patterns.
+
+Note that when providing a
+`<pattern>`, you must use `--list`; otherwise the command may be interpreted
+as branch creation.
+
+With `--contains`, shows only the branches that contain the named commit
+(in other words, the branches whose tip commits are descendants of the
+named commit), `--no-contains` inverts it. With `--merged`, only branches
+merged into the named commit (i.e. the branches whose tip commits are
+reachable from the named commit) will be listed. With `--no-merged` only
+branches not merged into the named commit will be listed. If the <commit>
+argument is missing it defaults to `HEAD` (i.e. the tip of the current
+branch).
+
+The command's second form creates a new branch head named <branchname>
+which points to the current `HEAD`, or <start-point> if given. As a
+special case, for <start-point>, you may use `"A...B"` as a shortcut for
+the merge base of `A` and `B` if there is exactly one merge base. You
+can leave out at most one of `A` and `B`, in which case it defaults to
+`HEAD`.
+
+Note that this will create the new branch, but it will not switch the
+working tree to it; use "git switch <newbranch>" to switch to the
+new branch.
+
+When a local branch is started off a remote-tracking branch, Git sets up the
+branch (specifically the `branch.<name>.remote` and `branch.<name>.merge`
+configuration entries) so that 'git pull' will appropriately merge from
+the remote-tracking branch. This behavior may be changed via the global
+`branch.autoSetupMerge` configuration flag. That setting can be
+overridden by using the `--track` and `--no-track` options, and
+changed later using `git branch --set-upstream-to`.
+
+With a `-m` or `-M` option, <oldbranch> will be renamed to <newbranch>.
+If <oldbranch> had a corresponding reflog, it is renamed to match
+<newbranch>, and a reflog entry is created to remember the branch
+renaming. If <newbranch> exists, -M must be used to force the rename
+to happen.
+
+The `-c` and `-C` options have the exact same semantics as `-m` and
+`-M`, except instead of the branch being renamed, it will be copied to a
+new name, along with its config and reflog.
+
+With a `-d` or `-D` option, `<branchname>` will be deleted. You may
+specify more than one branch for deletion. If the branch currently
+has a reflog then the reflog will also be deleted.
+
+Use `-r` together with `-d` to delete remote-tracking branches. Note, that it
+only makes sense to delete remote-tracking branches if they no longer exist
+in the remote repository or if 'git fetch' was configured not to fetch
+them again. See also the 'prune' subcommand of linkgit:git-remote[1] for a
+way to clean up all obsolete remote-tracking branches.
+
+
+OPTIONS
+-------
+-d::
+--delete::
+ Delete a branch. The branch must be fully merged in its
+ upstream branch, or in `HEAD` if no upstream was set with
+ `--track` or `--set-upstream-to`.
+
+-D::
+ Shortcut for `--delete --force`.
+
+--create-reflog::
+ Create the branch's reflog. This activates recording of
+ all changes made to the branch ref, enabling use of date
+ based sha1 expressions such as "<branchname>@\{yesterday}".
+ Note that in non-bare repositories, reflogs are usually
+ enabled by default by the `core.logAllRefUpdates` config option.
+ The negated form `--no-create-reflog` only overrides an earlier
+ `--create-reflog`, but currently does not negate the setting of
+ `core.logAllRefUpdates`.
+
+-f::
+--force::
+ Reset <branchname> to <start-point>, even if <branchname> exists
+ already. Without `-f`, 'git branch' refuses to change an existing branch.
+ In combination with `-d` (or `--delete`), allow deleting the
+ branch irrespective of its merged status, or whether it even
+ points to a valid commit. In combination with
+ `-m` (or `--move`), allow renaming the branch even if the new
+ branch name already exists, the same applies for `-c` (or `--copy`).
++
+Note that 'git branch -f <branchname> [<start-point>]', even with '-f',
+refuses to change an existing branch `<branchname>` that is checked out
+in another worktree linked to the same repository.
+
+-m::
+--move::
+ Move/rename a branch, together with its config and reflog.
+
+-M::
+ Shortcut for `--move --force`.
+
+-c::
+--copy::
+ Copy a branch, together with its config and reflog.
+
+-C::
+ Shortcut for `--copy --force`.
+
+--color[=<when>]::
+ Color branches to highlight current, local, and
+ remote-tracking branches.
+ The value must be always (the default), never, or auto.
+
+--no-color::
+ Turn off branch colors, even when the configuration file gives the
+ default to color output.
+ Same as `--color=never`.
+
+-i::
+--ignore-case::
+ Sorting and filtering branches are case insensitive.
+
+--omit-empty::
+ Do not print a newline after formatted refs where the format expands
+ to the empty string.
+
+--column[=<options>]::
+--no-column::
+ Display branch listing in columns. See configuration variable
+ `column.branch` for option syntax. `--column` and `--no-column`
+ without options are equivalent to 'always' and 'never' respectively.
++
+This option is only applicable in non-verbose mode.
+
+-r::
+--remotes::
+ List or delete (if used with -d) the remote-tracking branches.
+ Combine with `--list` to match the optional pattern(s).
+
+-a::
+--all::
+ List both remote-tracking branches and local branches.
+ Combine with `--list` to match optional pattern(s).
+
+-l::
+--list::
+ List branches. With optional `<pattern>...`, e.g. `git
+ branch --list 'maint-*'`, list only the branches that match
+ the pattern(s).
+
+--show-current::
+ Print the name of the current branch. In detached HEAD state,
+ nothing is printed.
+
+-v::
+-vv::
+--verbose::
+ When in list mode,
+ show sha1 and commit subject line for each head, along with
+ relationship to upstream branch (if any). If given twice, print
+ the path of the linked worktree (if any) and the name of the upstream
+ branch, as well (see also `git remote show <remote>`). Note that the
+ current worktree's HEAD will not have its path printed (it will always
+ be your current directory).
+
+-q::
+--quiet::
+ Be more quiet when creating or deleting a branch, suppressing
+ non-error messages.
+
+--abbrev=<n>::
+ In the verbose listing that show the commit object name,
+ show the shortest prefix that is at least '<n>' hexdigits
+ long that uniquely refers the object.
+ The default value is 7 and can be overridden by the `core.abbrev`
+ config option.
+
+--no-abbrev::
+ Display the full sha1s in the output listing rather than abbreviating them.
+
+-t::
+--track[=(direct|inherit)]::
+ When creating a new branch, set up `branch.<name>.remote` and
+ `branch.<name>.merge` configuration entries to set "upstream" tracking
+ configuration for the new branch. This
+ configuration will tell git to show the relationship between the
+ two branches in `git status` and `git branch -v`. Furthermore,
+ it directs `git pull` without arguments to pull from the
+ upstream when the new branch is checked out.
++
+The exact upstream branch is chosen depending on the optional argument:
+`-t`, `--track`, or `--track=direct` means to use the start-point branch
+itself as the upstream; `--track=inherit` means to copy the upstream
+configuration of the start-point branch.
++
+The branch.autoSetupMerge configuration variable specifies how `git switch`,
+`git checkout` and `git branch` should behave when neither `--track` nor
+`--no-track` are specified:
++
+The default option, `true`, behaves as though `--track=direct`
+were given whenever the start-point is a remote-tracking branch.
+`false` behaves as if `--no-track` were given. `always` behaves as though
+`--track=direct` were given. `inherit` behaves as though `--track=inherit`
+were given. `simple` behaves as though `--track=direct` were given only when
+the start-point is a remote-tracking branch and the new branch has the same
+name as the remote branch.
++
+See linkgit:git-pull[1] and linkgit:git-config[1] for additional discussion on
+how the `branch.<name>.remote` and `branch.<name>.merge` options are used.
+
+--no-track::
+ Do not set up "upstream" configuration, even if the
+ branch.autoSetupMerge configuration variable is set.
+
+--recurse-submodules::
+ THIS OPTION IS EXPERIMENTAL! Causes the current command to
+ recurse into submodules if `submodule.propagateBranches` is
+ enabled. See `submodule.propagateBranches` in
+ linkgit:git-config[1]. Currently, only branch creation is
+ supported.
++
+When used in branch creation, a new branch <branchname> will be created
+in the superproject and all of the submodules in the superproject's
+<start-point>. In submodules, the branch will point to the submodule
+commit in the superproject's <start-point> but the branch's tracking
+information will be set up based on the submodule's branches and remotes
+e.g. `git branch --recurse-submodules topic origin/main` will create the
+submodule branch "topic" that points to the submodule commit in the
+superproject's "origin/main", but tracks the submodule's "origin/main".
+
+--set-upstream::
+ As this option had confusing syntax, it is no longer supported.
+ Please use `--track` or `--set-upstream-to` instead.
+
+-u <upstream>::
+--set-upstream-to=<upstream>::
+ Set up <branchname>'s tracking information so <upstream> is
+ considered <branchname>'s upstream branch. If no <branchname>
+ is specified, then it defaults to the current branch.
+
+--unset-upstream::
+ Remove the upstream information for <branchname>. If no branch
+ is specified it defaults to the current branch.
+
+--edit-description::
+ Open an editor and edit the text to explain what the branch is
+ for, to be used by various other commands (e.g. `format-patch`,
+ `request-pull`, and `merge` (if enabled)). Multi-line explanations
+ may be used.
+
+--contains [<commit>]::
+ Only list branches which contain the specified commit (HEAD
+ if not specified). Implies `--list`.
+
+--no-contains [<commit>]::
+ Only list branches which don't contain the specified commit
+ (HEAD if not specified). Implies `--list`.
+
+--merged [<commit>]::
+ Only list branches whose tips are reachable from the
+ specified commit (HEAD if not specified). Implies `--list`.
+
+--no-merged [<commit>]::
+ Only list branches whose tips are not reachable from the
+ specified commit (HEAD if not specified). Implies `--list`.
+
+<branchname>::
+ The name of the branch to create or delete.
+ The new branch name must pass all checks defined by
+ linkgit:git-check-ref-format[1]. Some of these checks
+ may restrict the characters allowed in a branch name.
+
+<start-point>::
+ The new branch head will point to this commit. It may be
+ given as a branch name, a commit-id, or a tag. If this
+ option is omitted, the current HEAD will be used instead.
+
+<oldbranch>::
+ The name of an existing branch. If this option is omitted,
+ the name of the current branch will be used instead.
+
+<newbranch>::
+ The new name for an existing branch. The same restrictions as for
+ <branchname> apply.
+
+--sort=<key>::
+ Sort based on the key given. Prefix `-` to sort in descending
+ order of the value. You may use the --sort=<key> option
+ multiple times, in which case the last key becomes the primary
+ key. The keys supported are the same as those in `git
+ for-each-ref`. Sort order defaults to the value configured for the
+ `branch.sort` variable if it exists, or to sorting based on the
+ full refname (including `refs/...` prefix). This lists
+ detached HEAD (if present) first, then local branches and
+ finally remote-tracking branches. See linkgit:git-config[1].
+
+
+--points-at <object>::
+ Only list branches of the given object.
+
+--format <format>::
+ A string that interpolates `%(fieldname)` from a branch ref being shown
+ and the object it points at. The format is the same as
+ that of linkgit:git-for-each-ref[1].
+
+CONFIGURATION
+-------------
+`pager.branch` is only respected when listing branches, i.e., when
+`--list` is used or implied. The default is to use a pager.
+See linkgit:git-config[1].
+
+include::includes/cmd-config-section-rest.adoc[]
+
+include::config/branch.adoc[]
+
+EXAMPLES
+--------
+
+Start development from a known tag::
++
+------------
+$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
+$ cd my2.6
+$ git branch my2.6.14 v2.6.14 <1>
+$ git switch my2.6.14
+------------
++
+<1> This step and the next one could be combined into a single step with
+ "checkout -b my2.6.14 v2.6.14".
+
+Delete an unneeded branch::
++
+------------
+$ git clone git://git.kernel.org/.../git.git my.git
+$ cd my.git
+$ git branch -d -r origin/todo origin/html origin/man <1>
+$ git branch -D test <2>
+------------
++
+<1> Delete the remote-tracking branches "todo", "html" and "man". The next
+ 'fetch' or 'pull' will create them again unless you configure them not to.
+ See linkgit:git-fetch[1].
+<2> Delete the "test" branch even if the "master" branch (or whichever branch
+ is currently checked out) does not have all commits from the test branch.
+
+Listing branches from a specific remote::
++
+------------
+$ git branch -r -l '<remote>/<pattern>' <1>
+$ git for-each-ref 'refs/remotes/<remote>/<pattern>' <2>
+------------
++
+<1> Using `-a` would conflate <remote> with any local branches you happen to
+ have been prefixed with the same <remote> pattern.
+<2> `for-each-ref` can take a wide range of options. See linkgit:git-for-each-ref[1]
+
+Patterns will normally need quoting.
+
+NOTES
+-----
+
+If you are creating a branch that you want to switch to immediately,
+it is easier to use the "git switch" command with its `-c` option to
+do the same thing with a single command.
+
+The options `--contains`, `--no-contains`, `--merged` and `--no-merged`
+serve four related but different purposes:
+
+- `--contains <commit>` is used to find all branches which will need
+ special attention if <commit> were to be rebased or amended, since those
+ branches contain the specified <commit>.
+
+- `--no-contains <commit>` is the inverse of that, i.e. branches that don't
+ contain the specified <commit>.
+
+- `--merged` is used to find all branches which can be safely deleted,
+ since those branches are fully contained by HEAD.
+
+- `--no-merged` is used to find branches which are candidates for merging
+ into HEAD, since those branches are not fully contained by HEAD.
+
+include::ref-reachability-filters.adoc[]
+
+SEE ALSO
+--------
+linkgit:git-check-ref-format[1],
+linkgit:git-fetch[1],
+linkgit:git-remote[1],
+link:user-manual.html#what-is-a-branch[``Understanding history: What is
+a branch?''] in the Git User's Manual.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-bugreport.adoc b/git-bugreport.adoc
new file mode 100644
index 0000000..112658b
--- /dev/null
+++ b/git-bugreport.adoc
@@ -0,0 +1,77 @@
+git-bugreport(1)
+================
+
+NAME
+----
+git-bugreport - Collect information for user to file a bug report
+
+SYNOPSIS
+--------
+[verse]
+'git bugreport' [(-o | --output-directory) <path>]
+ [(-s | --suffix) <format> | --no-suffix]
+ [--diagnose[=<mode>]]
+
+DESCRIPTION
+-----------
+Collects information about the user's machine, Git client, and repository
+state, in addition to a form requesting information about the behavior the
+user observed, and stores it in a single text file which the user can then
+share, for example to the Git mailing list, in order to report an observed
+bug.
+
+The following information is requested from the user:
+
+ - Reproduction steps
+ - Expected behavior
+ - Actual behavior
+
+The following information is captured automatically:
+
+ - 'git version --build-options'
+ - uname sysname, release, version, and machine strings
+ - Compiler-specific info string
+ - A list of enabled hooks
+ - $SHELL
+
+Additional information may be gathered into a separate zip archive using the
+`--diagnose` option, and can be attached alongside the bugreport document to
+provide additional context to readers.
+
+This tool is invoked via the typical Git setup process, which means that in some
+cases, it might not be able to launch - for example, if a relevant config file
+is unreadable. In this kind of scenario, it may be helpful to manually gather
+the kind of information listed above when manually asking for help.
+
+OPTIONS
+-------
+-o <path>::
+--output-directory <path>::
+ Place the resulting bug report file in `<path>` instead of the current
+ directory.
+
+-s <format>::
+--suffix <format>::
+--no-suffix::
+ Specify an alternate suffix for the bugreport name, to create a file
+ named 'git-bugreport-<formatted-suffix>'. This should take the form of a
+ strftime(3) format string; the current local time will be used.
+ `--no-suffix` disables the suffix and the file is just named
+ `git-bugreport` without any disambiguation measure.
+
+--no-diagnose::
+--diagnose[=<mode>]::
+ Create a zip archive of supplemental information about the user's
+ machine, Git client, and repository state. The archive is written to the
+ same output directory as the bug report and is named
+ 'git-diagnostics-<formatted-suffix>'.
++
+Without `mode` specified, the diagnostic archive will contain the default set of
+statistics reported by `git diagnose`. An optional `mode` value may be specified
+to change which information is included in the archive. See
+linkgit:git-diagnose[1] for the list of valid values for `mode` and details
+about their usage.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-bundle.adoc b/git-bundle.adoc
new file mode 100644
index 0000000..03cd36f
--- /dev/null
+++ b/git-bundle.adoc
@@ -0,0 +1,372 @@
+git-bundle(1)
+=============
+
+NAME
+----
+git-bundle - Move objects and refs by archive
+
+
+SYNOPSIS
+--------
+[verse]
+'git bundle' create [-q | --quiet | --progress]
+ [--version=<version>] <file> <git-rev-list-args>
+'git bundle' verify [-q | --quiet] <file>
+'git bundle' list-heads <file> [<refname>...]
+'git bundle' unbundle [--progress] <file> [<refname>...]
+
+DESCRIPTION
+-----------
+
+Create, unpack, and manipulate "bundle" files. Bundles are used for
+the "offline" transfer of Git objects without an active "server"
+sitting on the other side of the network connection.
+
+They can be used to create both incremental and full backups of a
+repository (see the "full backup" example in "EXAMPLES"), and to relay
+the state of the references in one repository to another (see the second
+example).
+
+Git commands that fetch or otherwise "read" via protocols such as
+`ssh://` and `https://` can also operate on bundle files. It is
+possible linkgit:git-clone[1] a new repository from a bundle, to use
+linkgit:git-fetch[1] to fetch from one, and to list the references
+contained within it with linkgit:git-ls-remote[1]. There's no
+corresponding "write" support, i.e. a 'git push' into a bundle is not
+supported.
+
+BUNDLE FORMAT
+-------------
+
+Bundles are `.pack` files (see linkgit:git-pack-objects[1]) with a
+header indicating what references are contained within the bundle.
+
+Like the packed archive format itself bundles can either be
+self-contained, or be created using exclusions.
+See the "OBJECT PREREQUISITES" section below.
+
+Bundles created using revision exclusions are "thin packs" created
+using the `--thin` option to linkgit:git-pack-objects[1], and
+unbundled using the `--fix-thin` option to linkgit:git-index-pack[1].
+
+There is no option to create a "thick pack" when using revision
+exclusions, and users should not be concerned about the difference. By
+using "thin packs", bundles created using exclusions are smaller in
+size. That they're "thin" under the hood is merely noted here as a
+curiosity, and as a reference to other documentation.
+
+See linkgit:gitformat-bundle[5] for more details and the discussion of
+"thin pack" in linkgit:gitformat-pack[5] for further details.
+
+OPTIONS
+-------
+
+create [options] <file> <git-rev-list-args>::
+ Used to create a bundle named 'file'. This requires the
+ '<git-rev-list-args>' arguments to define the bundle contents.
+ 'options' contains the options specific to the 'git bundle create'
+ subcommand. If 'file' is `-`, the bundle is written to stdout.
+
+verify <file>::
+ Used to check that a bundle file is valid and will apply
+ cleanly to the current repository. This includes checks on the
+ bundle format itself as well as checking that the prerequisite
+ commits exist and are fully linked in the current repository.
+ Then, 'git bundle' prints a list of missing commits, if any.
+ Finally, information about additional capabilities, such as "object
+ filter", is printed. See "Capabilities" in linkgit:gitformat-bundle[5]
+ for more information. The exit code is zero for success, but will
+ be nonzero if the bundle file is invalid. If 'file' is `-`, the
+ bundle is read from stdin.
+
+list-heads <file>::
+ Lists the references defined in the bundle. If followed by a
+ list of references, only references matching those given are
+ printed out. If 'file' is `-`, the bundle is read from stdin.
+
+unbundle <file>::
+ Passes the objects in the bundle to 'git index-pack'
+ for storage in the repository, then prints the names of all
+ defined references. If a list of references is given, only
+ references matching those in the list are printed. This command is
+ really plumbing, intended to be called only by 'git fetch'.
+ If 'file' is `-`, the bundle is read from stdin.
+
+<git-rev-list-args>::
+ A list of arguments, acceptable to 'git rev-parse' and
+ 'git rev-list' (and containing a named ref, see SPECIFYING REFERENCES
+ below), that specifies the specific objects and references
+ to transport. For example, `master~10..master` causes the
+ current master reference to be packaged along with all objects
+ added since its 10th ancestor commit. There is no explicit
+ limit to the number of references and objects that may be
+ packaged.
+
+
+[<refname>...]::
+ A list of references used to limit the references reported as
+ available. This is principally of use to 'git fetch', which
+ expects to receive only those references asked for and not
+ necessarily everything in the pack (in this case, 'git bundle' acts
+ like 'git fetch-pack').
+
+--progress::
+ Progress status is reported on the standard error stream
+ by default when it is attached to a terminal, unless -q
+ is specified. This flag forces progress status even if
+ the standard error stream is not directed to a terminal.
+
+--version=<version>::
+ Specify the bundle version. Version 2 is the older format and can only be
+ used with SHA-1 repositories; the newer version 3 contains capabilities that
+ permit extensions. The default is the oldest supported format, based on the
+ hash algorithm in use.
+
+-q::
+--quiet::
+ This flag makes the command not to report its progress
+ on the standard error stream.
+
+SPECIFYING REFERENCES
+---------------------
+
+Revisions must be accompanied by reference names to be packaged in a
+bundle. Alternatively `--all` can be used to package all refs.
+
+More than one reference may be packaged, and more than one set of prerequisite objects can
+be specified. The objects packaged are those not contained in the
+union of the prerequisites.
+
+The 'git bundle create' command resolves the reference names for you
+using the same rules as `git rev-parse --abbrev-ref=loose`. Each
+prerequisite can be specified explicitly (e.g. `^master~10`), or implicitly
+(e.g. `master~10..master`, `--since=10.days.ago master`).
+
+All of these simple cases are OK (assuming we have a "master" and
+"next" branch):
+
+----------------
+$ git bundle create master.bundle master
+$ echo master | git bundle create master.bundle --stdin
+$ git bundle create master-and-next.bundle master next
+$ (echo master; echo next) | git bundle create master-and-next.bundle --stdin
+----------------
+
+And so are these (and the same but omitted `--stdin` examples):
+
+----------------
+$ git bundle create recent-master.bundle master~10..master
+$ git bundle create recent-updates.bundle master~10..master next~5..next
+----------------
+
+A revision name or a range whose right-hand-side cannot be resolved to
+a reference is not accepted:
+
+----------------
+$ git bundle create HEAD.bundle $(git rev-parse HEAD)
+fatal: Refusing to create empty bundle.
+$ git bundle create master-yesterday.bundle master~10..master~5
+fatal: Refusing to create empty bundle.
+----------------
+
+OBJECT PREREQUISITES
+--------------------
+
+When creating bundles it is possible to create a self-contained bundle
+that can be unbundled in a repository with no common history, as well
+as providing negative revisions to exclude objects needed in the
+earlier parts of the history.
+
+Feeding a revision such as `new` to `git bundle create` will create a
+bundle file that contains all the objects reachable from the revision
+`new`. That bundle can be unbundled in any repository to obtain a full
+history that leads to the revision `new`:
+
+----------------
+$ git bundle create full.bundle new
+----------------
+
+A revision range such as `old..new` will produce a bundle file that
+will require the revision `old` (and any objects reachable from it)
+to exist for the bundle to be "unbundle"-able:
+
+----------------
+$ git bundle create full.bundle old..new
+----------------
+
+A self-contained bundle without any prerequisites can be extracted
+into anywhere, even into an empty repository, or be cloned from
+(i.e., `new`, but not `old..new`).
+
+It is okay to err on the side of caution, causing the bundle file
+to contain objects already in the destination, as these are ignored
+when unpacking at the destination.
+
+If you want to provide the same set of refs that a clone directly
+from the source repository would get, use `--branches --tags` for
+the `<git-rev-list-args>`.
+
+The 'git bundle verify' command can be used to check whether your
+recipient repository has the required prerequisite commits for a
+bundle.
+
+EXAMPLES
+--------
+
+We'll discuss two cases:
+
+1. Taking a full backup of a repository
+2. Transferring the history of a repository to another machine when the
+ two machines have no direct connection
+
+First let's consider a full backup of the repository. The following
+command will take a full backup of the repository in the sense that all
+refs are included in the bundle:
+
+----------------
+$ git bundle create backup.bundle --all
+----------------
+
+But note again that this is only for the refs, i.e. you will only
+include refs and commits reachable from those refs. You will not
+include other local state, such as the contents of the index, working
+tree, the stash, per-repository configuration, hooks, etc.
+
+You can later recover that repository by using for example
+linkgit:git-clone[1]:
+
+----------------
+$ git clone backup.bundle <new directory>
+----------------
+
+For the next example, assume you want to transfer the history from a
+repository R1 on machine A to another repository R2 on machine B.
+For whatever reason, direct connection between A and B is not allowed,
+but we can move data from A to B via some mechanism (CD, email, etc.).
+We want to update R2 with development made on the branch master in R1.
+
+To bootstrap the process, you can first create a bundle that does not have
+any prerequisites. You can use a tag to remember up to what commit you last
+processed, in order to make it easy to later update the other repository
+with an incremental bundle:
+
+----------------
+machineA$ cd R1
+machineA$ git bundle create file.bundle master
+machineA$ git tag -f lastR2bundle master
+----------------
+
+Then you transfer file.bundle to the target machine B. Because this
+bundle does not require any existing object to be extracted, you can
+create a new repository on machine B by cloning from it:
+
+----------------
+machineB$ git clone -b master /home/me/tmp/file.bundle R2
+----------------
+
+This will define a remote called "origin" in the resulting repository that
+lets you fetch and pull from the bundle. The $GIT_DIR/config file in R2 will
+have an entry like this:
+
+------------------------
+[remote "origin"]
+ url = /home/me/tmp/file.bundle
+ fetch = refs/heads/*:refs/remotes/origin/*
+------------------------
+
+To update the resulting mine.git repository, you can fetch or pull after
+replacing the bundle stored at /home/me/tmp/file.bundle with incremental
+updates.
+
+After working some more in the original repository, you can create an
+incremental bundle to update the other repository:
+
+----------------
+machineA$ cd R1
+machineA$ git bundle create file.bundle lastR2bundle..master
+machineA$ git tag -f lastR2bundle master
+----------------
+
+You then transfer the bundle to the other machine to replace
+/home/me/tmp/file.bundle, and pull from it.
+
+----------------
+machineB$ cd R2
+machineB$ git pull
+----------------
+
+If you know up to what commit the intended recipient repository should
+have the necessary objects, you can use that knowledge to specify the
+prerequisites, giving a cut-off point to limit the revisions and objects that go
+in the resulting bundle. The previous example used the lastR2bundle tag
+for this purpose, but you can use any other options that you would give to
+the linkgit:git-log[1] command. Here are more examples:
+
+You can use a tag that is present in both:
+
+----------------
+$ git bundle create mybundle v1.0.0..master
+----------------
+
+You can use a prerequisite based on time:
+
+----------------
+$ git bundle create mybundle --since=10.days master
+----------------
+
+You can use the number of commits:
+
+----------------
+$ git bundle create mybundle -10 master
+----------------
+
+You can run `git-bundle verify` to see if you can extract from a bundle
+that was created with a prerequisite:
+
+----------------
+$ git bundle verify mybundle
+----------------
+
+This will list what commits you must have in order to extract from the
+bundle and will error out if you do not have them.
+
+A bundle from a recipient repository's point of view is just like a
+regular repository which it fetches or pulls from. You can, for example, map
+references when fetching:
+
+----------------
+$ git fetch mybundle master:localRef
+----------------
+
+You can also see what references it offers:
+
+----------------
+$ git ls-remote mybundle
+----------------
+
+DISCUSSION
+----------
+
+A naive way to make a full backup of a repository is to use something to
+the effect of `cp -r <repo> <destination>`. This is discouraged since
+the repository could be written to during the copy operation. In turn
+some files at `<destination>` could be corrupted.
+
+This is why it is recommended to use Git tooling for making repository
+backups, either with this command or with e.g. linkgit:git-clone[1].
+But keep in mind that these tools will not help you backup state other
+than refs and commits. In other words they will not help you backup
+contents of the index, working tree, the stash, per-repository
+configuration, hooks, etc.
+
+See also linkgit:gitfaq[7], section "TRANSFERS" for a discussion of the
+problems associated with file syncing across systems.
+
+FILE FORMAT
+-----------
+
+See linkgit:gitformat-bundle[5].
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-cat-file.adoc b/git-cat-file.adoc
new file mode 100644
index 0000000..d5890ae
--- /dev/null
+++ b/git-cat-file.adoc
@@ -0,0 +1,412 @@
+git-cat-file(1)
+===============
+
+NAME
+----
+git-cat-file - Provide contents or details of repository objects
+
+SYNOPSIS
+--------
+[verse]
+'git cat-file' <type> <object>
+'git cat-file' (-e | -p) <object>
+'git cat-file' (-t | -s) [--allow-unknown-type] <object>
+'git cat-file' (--textconv | --filters)
+ [<rev>:<path|tree-ish> | --path=<path|tree-ish> <rev>]
+'git cat-file' (--batch | --batch-check | --batch-command) [--batch-all-objects]
+ [--buffer] [--follow-symlinks] [--unordered]
+ [--textconv | --filters] [-Z]
+
+DESCRIPTION
+-----------
+Output the contents or other properties such as size, type or delta
+information of one or more objects.
+
+This command can operate in two modes, depending on whether an option
+from the `--batch` family is specified.
+
+In non-batch mode, the command provides information on an object
+named on the command line.
+
+In batch mode, arguments are read from standard input.
+
+OPTIONS
+-------
+<object>::
+ The name of the object to show.
+ For a more complete list of ways to spell object names, see
+ the "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
+
+-t::
+ Instead of the content, show the object type identified by
+ `<object>`.
+
+-s::
+ Instead of the content, show the object size identified by
+ `<object>`. If used with `--use-mailmap` option, will show
+ the size of updated object after replacing idents using the
+ mailmap mechanism.
+
+-e::
+ Exit with zero status if `<object>` exists and is a valid
+ object. If `<object>` is of an invalid format, exit with non-zero
+ status and emit an error on stderr.
+
+-p::
+ Pretty-print the contents of `<object>` based on its type.
+
+<type>::
+ Typically this matches the real type of `<object>` but asking
+ for a type that can trivially be dereferenced from the given
+ `<object>` is also permitted. An example is to ask for a
+ "tree" with `<object>` being a commit object that contains it,
+ or to ask for a "blob" with `<object>` being a tag object that
+ points at it.
+
+--[no-]mailmap::
+--[no-]use-mailmap::
+ Use mailmap file to map author, committer and tagger names
+ and email addresses to canonical real names and email addresses.
+ See linkgit:git-shortlog[1].
+
+--textconv::
+ Show the content as transformed by a textconv filter. In this case,
+ `<object>` has to be of the form `<tree-ish>:<path>`, or `:<path>` in
+ order to apply the filter to the content recorded in the index at
+ `<path>`.
+
+--filters::
+ Show the content as converted by the filters configured in
+ the current working tree for the given `<path>` (i.e. smudge filters,
+ end-of-line conversion, etc). In this case, `<object>` has to be of
+ the form `<tree-ish>:<path>`, or `:<path>`.
+
+--path=<path>::
+ For use with `--textconv` or `--filters`, to allow specifying an object
+ name and a path separately, e.g. when it is difficult to figure out
+ the revision from which the blob came.
+
+--batch::
+--batch=<format>::
+ Print object information and contents for each object provided
+ on stdin. May not be combined with any other options or arguments
+ except `--textconv`, `--filters`, or `--use-mailmap`.
++
+--
+ * When used with `--textconv` or `--filters`, the input lines
+ must specify the path, separated by whitespace. See the section
+ `BATCH OUTPUT` below for details.
+
+ * When used with `--use-mailmap`, for commit and tag objects, the
+ contents part of the output shows the identities replaced using the
+ mailmap mechanism, while the information part of the output shows
+ the size of the object as if it actually recorded the replacement
+ identities.
+--
+
+--batch-check::
+--batch-check=<format>::
+ Print object information for each object provided on stdin. May not be
+ combined with any other options or arguments except `--textconv`, `--filters`
+ or `--use-mailmap`.
++
+--
+ * When used with `--textconv` or `--filters`, the input lines must
+ specify the path, separated by whitespace. See the section
+ `BATCH OUTPUT` below for details.
+
+ * When used with `--use-mailmap`, for commit and tag objects, the
+ printed object information shows the size of the object as if the
+ identities recorded in it were replaced by the mailmap mechanism.
+--
+
+--batch-command::
+--batch-command=<format>::
+ Enter a command mode that reads commands and arguments from stdin. May
+ only be combined with `--buffer`, `--textconv`, `--use-mailmap` or
+ `--filters`.
++
+--
+ * When used with `--textconv` or `--filters`, the input lines must
+ specify the path, separated by whitespace. See the section
+ `BATCH OUTPUT` below for details.
+
+ * When used with `--use-mailmap`, for commit and tag objects, the
+ `contents` command shows the identities replaced using the
+ mailmap mechanism, while the `info` command shows the size
+ of the object as if it actually recorded the replacement
+ identities.
+--
++
+`--batch-command` recognizes the following commands:
++
+--
+contents <object>::
+ Print object contents for object reference `<object>`. This corresponds to
+ the output of `--batch`.
+
+info <object>::
+ Print object info for object reference `<object>`. This corresponds to the
+ output of `--batch-check`.
+
+flush::
+ Used with `--buffer` to execute all preceding commands that were issued
+ since the beginning or since the last flush was issued. When `--buffer`
+ is used, no output will come until a `flush` is issued. When `--buffer`
+ is not used, commands are flushed each time without issuing `flush`.
+--
++
+
+--batch-all-objects::
+ Instead of reading a list of objects on stdin, perform the
+ requested batch operation on all objects in the repository and
+ any alternate object stores (not just reachable objects).
+ Requires `--batch` or `--batch-check` be specified. By default,
+ the objects are visited in order sorted by their hashes; see
+ also `--unordered` below. Objects are presented as-is, without
+ respecting the "replace" mechanism of linkgit:git-replace[1].
+
+--buffer::
+ Normally batch output is flushed after each object is output, so
+ that a process can interactively read and write from
+ `cat-file`. With this option, the output uses normal stdio
+ buffering; this is much more efficient when invoking
+ `--batch-check` or `--batch-command` on a large number of objects.
+
+--unordered::
+ When `--batch-all-objects` is in use, visit objects in an
+ order which may be more efficient for accessing the object
+ contents than hash order. The exact details of the order are
+ unspecified, but if you do not require a specific order, this
+ should generally result in faster output, especially with
+ `--batch`. Note that `cat-file` will still show each object
+ only once, even if it is stored multiple times in the
+ repository.
+
+--allow-unknown-type::
+ Allow `-s` or `-t` to query broken/corrupt objects of unknown type.
+
+--follow-symlinks::
+ With `--batch` or `--batch-check`, follow symlinks inside the
+ repository when requesting objects with extended SHA-1
+ expressions of the form tree-ish:path-in-tree. Instead of
+ providing output about the link itself, provide output about
+ the linked-to object. If a symlink points outside the
+ tree-ish (e.g. a link to `/foo` or a root-level link to `../foo`),
+ the portion of the link which is outside the tree will be
+ printed.
++
+This option does not (currently) work correctly when an object in the
+index is specified (e.g. `:link` instead of `HEAD:link`) rather than
+one in the tree.
++
+This option cannot (currently) be used unless `--batch` or
+`--batch-check` is used.
++
+For example, consider a git repository containing:
++
+--
+ f: a file containing "hello\n"
+ link: a symlink to f
+ dir/link: a symlink to ../f
+ plink: a symlink to ../f
+ alink: a symlink to /etc/passwd
+--
++
+For a regular file `f`, `echo HEAD:f | git cat-file --batch` would print
++
+--
+ ce013625030ba8dba906f756967f9e9ca394464a blob 6
+--
++
+And `echo HEAD:link | git cat-file --batch --follow-symlinks` would
+print the same thing, as would `HEAD:dir/link`, as they both point at
+`HEAD:f`.
++
+Without `--follow-symlinks`, these would print data about the symlink
+itself. In the case of `HEAD:link`, you would see
++
+--
+ 4d1ae35ba2c8ec712fa2a379db44ad639ca277bd blob 1
+--
++
+Both `plink` and `alink` point outside the tree, so they would
+respectively print:
++
+--
+ symlink 4
+ ../f
+
+ symlink 11
+ /etc/passwd
+--
+
+-Z::
+ Only meaningful with `--batch`, `--batch-check`, or
+ `--batch-command`; input and output is NUL-delimited instead of
+ newline-delimited.
+
+-z::
+ Only meaningful with `--batch`, `--batch-check`, or
+ `--batch-command`; input is NUL-delimited instead of
+ newline-delimited. This option is deprecated in favor of
+ `-Z` as the output can otherwise be ambiguous.
+
+
+OUTPUT
+------
+If `-t` is specified, one of the `<type>`.
+
+If `-s` is specified, the size of the `<object>` in bytes.
+
+If `-e` is specified, no output, unless the `<object>` is malformed.
+
+If `-p` is specified, the contents of `<object>` are pretty-printed.
+
+If `<type>` is specified, the raw (though uncompressed) contents of the `<object>`
+will be returned.
+
+BATCH OUTPUT
+------------
+
+If `--batch` or `--batch-check` is given, `cat-file` will read objects
+from stdin, one per line, and print information about them in the same
+order as they have been read. By default, the whole line is
+considered as an object, as if it were fed to linkgit:git-rev-parse[1].
+
+When `--batch-command` is given, `cat-file` will read commands from stdin,
+one per line, and print information based on the command given. With
+`--batch-command`, the `info` command followed by an object will print
+information about the object the same way `--batch-check` would, and the
+`contents` command followed by an object prints contents in the same way
+`--batch` would.
+
+You can specify the information shown for each object by using a custom
+`<format>`. The `<format>` is copied literally to stdout for each
+object, with placeholders of the form `%(atom)` expanded, followed by a
+newline. The available atoms are:
+
+`objectname`::
+ The full hex representation of the object name.
+
+`objecttype`::
+ The type of the object (the same as `cat-file -t` reports).
+
+`objectsize`::
+ The size, in bytes, of the object (the same as `cat-file -s`
+ reports).
+
+`objectsize:disk`::
+ The size, in bytes, that the object takes up on disk. See the
+ note about on-disk sizes in the `CAVEATS` section below.
+
+`deltabase`::
+ If the object is stored as a delta on-disk, this expands to the
+ full hex representation of the delta base object name.
+ Otherwise, expands to the null OID (all zeroes). See `CAVEATS`
+ below.
+
+`rest`::
+ If this atom is used in the output string, input lines are split
+ at the first whitespace boundary. All characters before that
+ whitespace are considered to be the object name; characters
+ after that first run of whitespace (i.e., the "rest" of the
+ line) are output in place of the `%(rest)` atom.
+
+If no format is specified, the default format is `%(objectname)
+%(objecttype) %(objectsize)`.
+
+If `--batch` is specified, or if `--batch-command` is used with the `contents`
+command, the object information is followed by the object contents (consisting
+of `%(objectsize)` bytes), followed by a newline.
+
+For example, `--batch` without a custom format would produce:
+
+------------
+<oid> SP <type> SP <size> LF
+<contents> LF
+------------
+
+Whereas `--batch-check='%(objectname) %(objecttype)'` would produce:
+
+------------
+<oid> SP <type> LF
+------------
+
+If a name is specified on stdin that cannot be resolved to an object in
+the repository, then `cat-file` will ignore any custom format and print:
+
+------------
+<object> SP missing LF
+------------
+
+If a name is specified that might refer to more than one object (an ambiguous short sha), then `cat-file` will ignore any custom format and print:
+
+------------
+<object> SP ambiguous LF
+------------
+
+If `--follow-symlinks` is used, and a symlink in the repository points
+outside the repository, then `cat-file` will ignore any custom format
+and print:
+
+------------
+symlink SP <size> LF
+<symlink> LF
+------------
+
+The symlink will either be absolute (beginning with a `/`), or relative
+to the tree root. For instance, if dir/link points to `../../foo`, then
+`<symlink>` will be `../foo`. `<size>` is the size of the symlink in bytes.
+
+If `--follow-symlinks` is used, the following error messages will be
+displayed:
+
+------------
+<object> SP missing LF
+------------
+is printed when the initial symlink requested does not exist.
+
+------------
+dangling SP <size> LF
+<object> LF
+------------
+is printed when the initial symlink exists, but something that
+it (transitive-of) points to does not.
+
+------------
+loop SP <size> LF
+<object> LF
+------------
+is printed for symlink loops (or any symlinks that
+require more than 40 link resolutions to resolve).
+
+------------
+notdir SP <size> LF
+<object> LF
+------------
+is printed when, during symlink resolution, a file is used as a
+directory name.
+
+Alternatively, when `-Z` is passed, the line feeds in any of the above examples
+are replaced with NUL terminators. This ensures that output will be parsable if
+the output itself would contain a linefeed and is thus recommended for
+scripting purposes.
+
+CAVEATS
+-------
+
+Note that the sizes of objects on disk are reported accurately, but care
+should be taken in drawing conclusions about which refs or objects are
+responsible for disk usage. The size of a packed non-delta object may be
+much larger than the size of objects which delta against it, but the
+choice of which object is the base and which is the delta is arbitrary
+and is subject to change during a repack.
+
+Note also that multiple copies of an object may be present in the object
+database; in this case, it is undefined which copy's size or delta base
+will be reported.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-check-attr.adoc b/git-check-attr.adoc
new file mode 100644
index 0000000..cb5a6c8
--- /dev/null
+++ b/git-check-attr.adoc
@@ -0,0 +1,125 @@
+git-check-attr(1)
+=================
+
+NAME
+----
+git-check-attr - Display gitattributes information
+
+
+SYNOPSIS
+--------
+[verse]
+'git check-attr' [--source <tree-ish>] [-a | --all | <attr>...] [--] <pathname>...
+'git check-attr' --stdin [-z] [--source <tree-ish>] [-a | --all | <attr>...]
+
+DESCRIPTION
+-----------
+For every pathname, this command will list if each attribute is 'unspecified',
+'set', or 'unset' as a gitattribute on that pathname.
+
+OPTIONS
+-------
+-a, --all::
+ List all attributes that are associated with the specified
+ paths. If this option is used, then 'unspecified' attributes
+ will not be included in the output.
+
+--cached::
+ Consider `.gitattributes` in the index only, ignoring the working tree.
+
+--stdin::
+ Read pathnames from the standard input, one per line,
+ instead of from the command line.
+
+-z::
+ The output format is modified to be machine-parsable.
+ If `--stdin` is also given, input paths are separated
+ with a NUL character instead of a linefeed character.
+
+--source=<tree-ish>::
+ Check attributes against the specified tree-ish. It is common to
+ specify the source tree by naming a commit, branch, or tag associated
+ with it.
+
+\--::
+ Interpret all preceding arguments as attributes and all following
+ arguments as path names.
+
+If none of `--stdin`, `--all`, or `--` is used, the first argument
+will be treated as an attribute and the rest of the arguments as
+pathnames.
+
+OUTPUT
+------
+
+The output is of the form:
+<path> COLON SP <attribute> COLON SP <info> LF
+
+unless `-z` is in effect, in which case NUL is used as delimiter:
+<path> NUL <attribute> NUL <info> NUL
+
+
+<path> is the path of a file being queried, <attribute> is an attribute
+being queried, and <info> can be either:
+
+'unspecified';; when the attribute is not defined for the path.
+'unset';; when the attribute is defined as false.
+'set';; when the attribute is defined as true.
+<value>;; when a value has been assigned to the attribute.
+
+Buffering happens as documented under the `GIT_FLUSH` option in
+linkgit:git[1]. The caller is responsible for avoiding deadlocks
+caused by overfilling an input buffer or reading from an empty output
+buffer.
+
+EXAMPLES
+--------
+
+In the examples, the following '.gitattributes' file is used:
+---------------
+*.java diff=java -crlf myAttr
+NoMyAttr.java !myAttr
+README caveat=unspecified
+---------------
+
+* Listing a single attribute:
+---------------
+$ git check-attr diff org/example/MyClass.java
+org/example/MyClass.java: diff: java
+---------------
+
+* Listing multiple attributes for a file:
+---------------
+$ git check-attr crlf diff myAttr -- org/example/MyClass.java
+org/example/MyClass.java: crlf: unset
+org/example/MyClass.java: diff: java
+org/example/MyClass.java: myAttr: set
+---------------
+
+* Listing all attributes for a file:
+---------------
+$ git check-attr --all -- org/example/MyClass.java
+org/example/MyClass.java: diff: java
+org/example/MyClass.java: myAttr: set
+---------------
+
+* Listing an attribute for multiple files:
+---------------
+$ git check-attr myAttr -- org/example/MyClass.java org/example/NoMyAttr.java
+org/example/MyClass.java: myAttr: set
+org/example/NoMyAttr.java: myAttr: unspecified
+---------------
+
+* Not all values are equally unambiguous:
+---------------
+$ git check-attr caveat README
+README: caveat: unspecified
+---------------
+
+SEE ALSO
+--------
+linkgit:gitattributes[5].
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-check-ignore.adoc b/git-check-ignore.adoc
new file mode 100644
index 0000000..3e3b4e3
--- /dev/null
+++ b/git-check-ignore.adoc
@@ -0,0 +1,126 @@
+git-check-ignore(1)
+===================
+
+NAME
+----
+git-check-ignore - Debug gitignore / exclude files
+
+
+SYNOPSIS
+--------
+[verse]
+'git check-ignore' [<options>] <pathname>...
+'git check-ignore' [<options>] --stdin
+
+DESCRIPTION
+-----------
+
+For each pathname given via the command-line or from a file via
+`--stdin`, check whether the file is excluded by .gitignore (or other
+input files to the exclude mechanism) and output the path if it is
+excluded.
+
+By default, tracked files are not shown at all since they are not
+subject to exclude rules; but see `--no-index'.
+
+OPTIONS
+-------
+-q, --quiet::
+ Don't output anything, just set exit status. This is only
+ valid with a single pathname.
+
+-v, --verbose::
+ Instead of printing the paths that are excluded, for each path
+ that matches an exclude pattern, print the exclude pattern
+ together with the path. (Matching an exclude pattern usually
+ means the path is excluded, but if the pattern begins with "`!`"
+ then it is a negated pattern and matching it means the path is
+ NOT excluded.)
++
+For precedence rules within and between exclude sources, see
+linkgit:gitignore[5].
+
+--stdin::
+ Read pathnames from the standard input, one per line,
+ instead of from the command-line.
+
+-z::
+ The output format is modified to be machine-parsable (see
+ below). If `--stdin` is also given, input paths are separated
+ with a NUL character instead of a linefeed character.
+
+-n, --non-matching::
+ Show given paths which don't match any pattern. This only
+ makes sense when `--verbose` is enabled, otherwise it would
+ not be possible to distinguish between paths which match a
+ pattern and those which don't.
+
+--no-index::
+ Don't look in the index when undertaking the checks. This can
+ be used to debug why a path became tracked by e.g. `git add .`
+ and was not ignored by the rules as expected by the user or when
+ developing patterns including negation to match a path previously
+ added with `git add -f`.
+
+OUTPUT
+------
+
+By default, any of the given pathnames which match an ignore pattern
+will be output, one per line. If no pattern matches a given path,
+nothing will be output for that path; this means that path will not be
+ignored.
+
+If `--verbose` is specified, the output is a series of lines of the form:
+
+<source> <COLON> <linenum> <COLON> <pattern> <HT> <pathname>
+
+<pathname> is the path of a file being queried, <pattern> is the
+matching pattern, <source> is the pattern's source file, and <linenum>
+is the line number of the pattern within that source. If the pattern
+contained a "`!`" prefix or "`/`" suffix, it will be preserved in the
+output. <source> will be an absolute path when referring to the file
+configured by `core.excludesFile`, or relative to the repository root
+when referring to `.git/info/exclude` or a per-directory exclude file.
+
+If `-z` is specified, the pathnames in the output are delimited by the
+null character; if `--verbose` is also specified then null characters
+are also used instead of colons and hard tabs:
+
+<source> <NULL> <linenum> <NULL> <pattern> <NULL> <pathname> <NULL>
+
+If `-n` or `--non-matching` are specified, non-matching pathnames will
+also be output, in which case all fields in each output record except
+for <pathname> will be empty. This can be useful when running
+non-interactively, so that files can be incrementally streamed to
+STDIN of a long-running check-ignore process, and for each of these
+files, STDOUT will indicate whether that file matched a pattern or
+not. (Without this option, it would be impossible to tell whether the
+absence of output for a given file meant that it didn't match any
+pattern, or that the output hadn't been generated yet.)
+
+Buffering happens as documented under the `GIT_FLUSH` option in
+linkgit:git[1]. The caller is responsible for avoiding deadlocks
+caused by overfilling an input buffer or reading from an empty output
+buffer.
+
+EXIT STATUS
+-----------
+
+0::
+ One or more of the provided paths is ignored.
+
+1::
+ None of the provided paths are ignored.
+
+128::
+ A fatal error was encountered.
+
+SEE ALSO
+--------
+linkgit:gitignore[5]
+linkgit:git-config[1]
+linkgit:git-ls-files[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-check-mailmap.adoc b/git-check-mailmap.adoc
new file mode 100644
index 0000000..966c91c
--- /dev/null
+++ b/git-check-mailmap.adoc
@@ -0,0 +1,64 @@
+git-check-mailmap(1)
+====================
+
+NAME
+----
+git-check-mailmap - Show canonical names and email addresses of contacts
+
+
+SYNOPSIS
+--------
+[verse]
+'git check-mailmap' [<options>] <contact>...
+
+
+DESCRIPTION
+-----------
+
+For each ``Name $$<user@host>$$'', ``$$<user@host>$$'', or ``$$user@host$$''
+from the command-line or standard input (when using `--stdin`), look up the
+person's canonical name and email address (see "Mapping Authors" below). If
+found, print them; otherwise print the input as-is.
+
+
+OPTIONS
+-------
+--stdin::
+ Read contacts, one per line, from the standard input after exhausting
+ contacts provided on the command-line.
+
+--mailmap-file=<file>::
+ In addition to any configured mailmap files, read the specified
+ mailmap file. Entries in this file take precedence over entries in
+ either the default mailmap file or any configured mailmap file.
+
+--mailmap-blob=<blob>::
+ Like `--mailmap-file`, but consider the value as a reference to a
+ blob in the repository. If both `--mailmap-file` and
+ `--mailmap-blob` are specified, entries in `--mailmap-file` will
+ take precedence.
+
+OUTPUT
+------
+
+For each contact, a single line is output, terminated by a newline. If the
+name is provided or known to the 'mailmap', ``Name $$<user@host>$$'' is
+printed; otherwise only ``$$<user@host>$$'' is printed.
+
+
+CONFIGURATION
+-------------
+
+See `mailmap.file` and `mailmap.blob` in linkgit:git-config[1] for how
+to specify a custom `.mailmap` target file or object.
+
+
+MAPPING AUTHORS
+---------------
+
+See linkgit:gitmailmap[5].
+
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-check-ref-format.adoc b/git-check-ref-format.adoc
new file mode 100644
index 0000000..2aacfd1
--- /dev/null
+++ b/git-check-ref-format.adoc
@@ -0,0 +1,140 @@
+git-check-ref-format(1)
+=======================
+
+NAME
+----
+git-check-ref-format - Ensures that a reference name is well formed
+
+SYNOPSIS
+--------
+[verse]
+'git check-ref-format' [--normalize]
+ [--[no-]allow-onelevel] [--refspec-pattern]
+ <refname>
+'git check-ref-format' --branch <branchname-shorthand>
+
+DESCRIPTION
+-----------
+Checks if a given 'refname' is acceptable, and exits with a non-zero
+status if it is not.
+
+A reference is used in Git to specify branches and tags. A
+branch head is stored in the `refs/heads` hierarchy, while
+a tag is stored in the `refs/tags` hierarchy of the ref namespace
+(typically in `$GIT_DIR/refs/heads` and `$GIT_DIR/refs/tags`
+directories or, as entries in file `$GIT_DIR/packed-refs`
+if refs are packed by `git gc`).
+
+Git imposes the following rules on how references are named:
+
+. They can include slash `/` for hierarchical (directory)
+ grouping, but no slash-separated component can begin with a
+ dot `.` or end with the sequence `.lock`.
+
+. They must contain at least one `/`. This enforces the presence of a
+ category like `heads/`, `tags/` etc. but the actual names are not
+ restricted. If the `--allow-onelevel` option is used, this rule
+ is waived.
+
+. They cannot have two consecutive dots `..` anywhere.
+
+. They cannot have ASCII control characters (i.e. bytes whose
+ values are lower than \040, or \177 `DEL`), space, tilde `~`,
+ caret `^`, or colon `:` anywhere.
+
+. They cannot have question-mark `?`, asterisk `*`, or open
+ bracket `[` anywhere. See the `--refspec-pattern` option below for
+ an exception to this rule.
+
+. They cannot begin or end with a slash `/` or contain multiple
+ consecutive slashes (see the `--normalize` option below for an
+ exception to this rule).
+
+. They cannot end with a dot `.`.
+
+. They cannot contain a sequence `@{`.
+
+. They cannot be the single character `@`.
+
+. They cannot contain a `\`.
+
+These rules make it easy for shell script based tools to parse
+reference names, pathname expansion by the shell when a reference name is used
+unquoted (by mistake), and also avoid ambiguities in certain
+reference name expressions (see linkgit:gitrevisions[7]):
+
+. A double-dot `..` is often used as in `ref1..ref2`, and in some
+ contexts this notation means `^ref1 ref2` (i.e. not in
+ `ref1` and in `ref2`).
+
+. A tilde `~` and caret `^` are used to introduce the postfix
+ 'nth parent' and 'peel onion' operation.
+
+. A colon `:` is used as in `srcref:dstref` to mean "use srcref\'s
+ value and store it in dstref" in fetch and push operations.
+ It may also be used to select a specific object such as with
+ 'git cat-file': "git cat-file blob v1.3.3:refs.c".
+
+. at-open-brace `@{` is used as a notation to access a reflog entry.
+
+With the `--branch` option, the command takes a name and checks if
+it can be used as a valid branch name (e.g. when creating a new
+branch). But be cautious when using the
+previous checkout syntax that may refer to a detached HEAD state.
+The rule `git check-ref-format --branch $name` implements
+may be stricter than what `git check-ref-format refs/heads/$name`
+says (e.g. a dash may appear at the beginning of a ref component,
+but it is explicitly forbidden at the beginning of a branch name).
+When run with the `--branch` option in a repository, the input is first
+expanded for the ``previous checkout syntax''
+`@{-n}`. For example, `@{-1}` is a way to refer the last thing that
+was checked out using "git switch" or "git checkout" operation.
+This option should be
+used by porcelains to accept this syntax anywhere a branch name is
+expected, so they can act as if you typed the branch name. As an
+exception note that, the ``previous checkout operation'' might result
+in a commit object name when the N-th last thing checked out was not
+a branch.
+
+OPTIONS
+-------
+--[no-]allow-onelevel::
+ Controls whether one-level refnames are accepted (i.e.,
+ refnames that do not contain multiple `/`-separated
+ components). The default is `--no-allow-onelevel`.
+
+--refspec-pattern::
+ Interpret <refname> as a reference name pattern for a refspec
+ (as used with remote repositories). If this option is
+ enabled, <refname> is allowed to contain a single `*`
+ in the refspec (e.g., `foo/bar*/baz` or `foo/bar*baz/`
+ but not `foo/bar*/baz*`).
+
+--normalize::
+ Normalize 'refname' by removing any leading slash (`/`)
+ characters and collapsing runs of adjacent slashes between
+ name components into a single slash. If the normalized
+ refname is valid then print it to standard output and exit
+ with a status of 0, otherwise exit with a non-zero status.
+ (`--print` is a deprecated way to spell `--normalize`.)
+
+
+EXAMPLES
+--------
+
+* Print the name of the previous thing checked out:
++
+------------
+$ git check-ref-format --branch @{-1}
+------------
+
+* Determine the reference name to use for a new branch:
++
+------------
+$ ref=$(git check-ref-format --normalize "refs/heads/$newbranch")||
+{ echo "we do not like '$newbranch' as a branch name." >&2 ; exit 1 ; }
+------------
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-checkout-index.adoc b/git-checkout-index.adoc
new file mode 100644
index 0000000..faf8d6c
--- /dev/null
+++ b/git-checkout-index.adoc
@@ -0,0 +1,183 @@
+git-checkout-index(1)
+=====================
+
+NAME
+----
+git-checkout-index - Copy files from the index to the working tree
+
+
+SYNOPSIS
+--------
+[verse]
+'git checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
+ [--stage=<number>|all]
+ [--temp]
+ [--ignore-skip-worktree-bits]
+ [-z] [--stdin]
+ [--] [<file>...]
+
+DESCRIPTION
+-----------
+Copies all listed files from the index to the working directory
+(not overwriting existing files).
+
+OPTIONS
+-------
+-u::
+--index::
+ update stat information for the checked out entries in
+ the index file.
+
+-q::
+--quiet::
+ be quiet if files exist or are not in the index
+
+-f::
+--force::
+ forces overwrite of existing files
+
+-a::
+--all::
+ checks out all files in the index except for those with the
+ skip-worktree bit set (see `--ignore-skip-worktree-bits`).
+ Cannot be used together with explicit filenames.
+
+-n::
+--no-create::
+ Don't checkout new files, only refresh files already checked
+ out.
+
+--prefix=<string>::
+ When creating files, prepend <string> (usually a directory
+ including a trailing /)
+
+--stage=<number>|all::
+ Instead of checking out unmerged entries, copy out the
+ files from the named stage. <number> must be between 1 and 3.
+ Note: --stage=all automatically implies --temp.
+
+--temp::
+ Instead of copying the files to the working directory,
+ write the content to temporary files. The temporary name
+ associations will be written to stdout.
+
+--ignore-skip-worktree-bits::
+ Check out all files, including those with the skip-worktree bit
+ set.
+
+--stdin::
+ Instead of taking a list of paths from the command line,
+ read the list of paths from the standard input. Paths are
+ separated by LF (i.e. one path per line) by default.
+
+-z::
+ Only meaningful with `--stdin`; paths are separated with
+ NUL character instead of LF.
+
+\--::
+ Do not interpret any more arguments as options.
+
+The order of the flags used to matter, but not anymore.
+
+Just doing `git checkout-index` does nothing. You probably meant
+`git checkout-index -a`. And if you want to force it, you want
+`git checkout-index -f -a`.
+
+Intuitiveness is not the goal here. Repeatability is. The reason for
+the "no arguments means no work" behavior is that from scripts you are
+supposed to be able to do:
+
+----------------
+$ find . -name '*.h' -print0 | xargs -0 git checkout-index -f --
+----------------
+
+which will force all existing `*.h` files to be replaced with their
+cached copies. If an empty command line implied "all", then this would
+force-refresh everything in the index, which was not the point. But
+since 'git checkout-index' accepts --stdin it would be faster to use:
+
+----------------
+$ find . -name '*.h' -print0 | git checkout-index -f -z --stdin
+----------------
+
+The `--` is just a good idea when you know the rest will be filenames;
+it will prevent problems with a filename of, for example, `-a`.
+Using `--` is probably a good policy in scripts.
+
+
+Using --temp or --stage=all
+---------------------------
+When `--temp` is used (or implied by `--stage=all`)
+'git checkout-index' will create a temporary file for each index
+entry being checked out. The index will not be updated with stat
+information. These options can be useful if the caller needs all
+stages of all unmerged entries so that the unmerged files can be
+processed by an external merge tool.
+
+A listing will be written to stdout providing the association of
+temporary file names to tracked path names. The listing format
+has two variations:
+
+ . tempname TAB path RS
++
+The first format is what gets used when `--stage` is omitted or
+is not `--stage=all`. The field tempname is the temporary file
+name holding the file content and path is the tracked path name in
+the index. Only the requested entries are output.
+
+ . stage1temp SP stage2temp SP stage3tmp TAB path RS
++
+The second format is what gets used when `--stage=all`. The three
+stage temporary fields (stage1temp, stage2temp, stage3temp) list the
+name of the temporary file if there is a stage entry in the index
+or `.` if there is no stage entry. Paths which only have a stage 0
+entry will always be omitted from the output.
+
+In both formats RS (the record separator) is newline by default
+but will be the null byte if -z was passed on the command line.
+The temporary file names are always safe strings; they will never
+contain directory separators or whitespace characters. The path
+field is always relative to the current directory and the temporary
+file names are always relative to the top level directory.
+
+If the object being copied out to a temporary file is a symbolic
+link the content of the link will be written to a normal file. It is
+up to the end-user or the Porcelain to make use of this information.
+
+
+EXAMPLES
+--------
+To update and refresh only the files already checked out::
++
+----------------
+$ git checkout-index -n -f -a && git update-index --ignore-missing --refresh
+----------------
+
+Using 'git checkout-index' to "export an entire tree"::
+ The prefix ability basically makes it trivial to use
+ 'git checkout-index' as an "export as tree" function.
+ Just read the desired tree into the index, and do:
++
+----------------
+$ git checkout-index --prefix=git-export-dir/ -a
+----------------
++
+`git checkout-index` will "export" the index into the specified
+directory.
++
+The final "/" is important. The exported name is literally just
+prefixed with the specified string. Contrast this with the
+following example.
+
+Export files with a prefix::
++
+----------------
+$ git checkout-index --prefix=.merged- Makefile
+----------------
++
+This will check out the currently cached copy of `Makefile`
+into the file `.merged-Makefile`.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-checkout.adoc b/git-checkout.adoc
new file mode 100644
index 0000000..a66c53a
--- /dev/null
+++ b/git-checkout.adoc
@@ -0,0 +1,626 @@
+git-checkout(1)
+===============
+
+NAME
+----
+git-checkout - Switch branches or restore working tree files
+
+SYNOPSIS
+--------
+[verse]
+'git checkout' [-q] [-f] [-m] [<branch>]
+'git checkout' [-q] [-f] [-m] --detach [<branch>]
+'git checkout' [-q] [-f] [-m] [--detach] <commit>
+'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] <new-branch>] [<start-point>]
+'git checkout' [-f] <tree-ish> [--] <pathspec>...
+'git checkout' [-f] <tree-ish> --pathspec-from-file=<file> [--pathspec-file-nul]
+'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [--] <pathspec>...
+'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] --pathspec-from-file=<file> [--pathspec-file-nul]
+'git checkout' (-p|--patch) [<tree-ish>] [--] [<pathspec>...]
+
+DESCRIPTION
+-----------
+Updates files in the working tree to match the version in the index
+or the specified tree. If no pathspec was given, 'git checkout' will
+also update `HEAD` to set the specified branch as the current
+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 and
+`--no-guess` is not specified, 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
+rather expensive side-effects to show only the tracking information,
+if it exists, for the current branch.
+
+'git checkout' -b|-B <new-branch> [<start-point>]::
+
+ 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
++
+------------
+$ git branch -f <branch> [<start-point>]
+$ git checkout <branch>
+------------
++
+that is to say, the branch is not reset/created unless "git checkout" is
+successful (e.g., when the branch is in use in another worktree, not
+just the current branch stays the same, but the branch is not reset to
+the start-point, either).
+
+'git checkout' --detach [<branch>]::
+'git checkout' [--detach] <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.
++
+When the `<commit>` argument is a branch name, the `--detach` option can
+be used to detach `HEAD` at the tip of the branch (`git checkout
+<branch>` would check out that branch without detaching `HEAD`).
++
+Omitting `<branch>` detaches `HEAD` at the tip of the current branch.
+
+'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <pathspec>...::
+'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] --pathspec-from-file=<file> [--pathspec-file-nul]::
+
+ Overwrite the contents of the files that match the pathspec.
+ When the `<tree-ish>` (most often a commit) is not given,
+ overwrite working tree with the contents in the index.
+ When the `<tree-ish>` is given, overwrite both the index and
+ the working tree with the contents at the `<tree-ish>`.
++
+The index may contain unmerged entries because of a previous failed merge.
+By default, if you try to check out such an entry from the index, the
+checkout operation will fail and nothing will be checked out.
+Using `-f` will ignore these unmerged entries. The contents from a
+specific side of the merge can be checked out of the index by
+using `--ours` or `--theirs`. With `-m`, changes made to the working tree
+file can be discarded to re-create the original conflicted merge result.
+
+'git checkout' (-p|--patch) [<tree-ish>] [--] [<pathspec>...]::
+ This is similar to the previous mode, but lets you use the
+ interactive interface to show the "diff" output and choose which
+ hunks to use in the result. See below for the description of
+ `--patch` option.
+
+OPTIONS
+-------
+-q::
+--quiet::
+ Quiet, suppress feedback messages.
+
+--progress::
+--no-progress::
+ Progress status is reported on the standard error stream
+ by default when it is attached to a terminal, unless `--quiet`
+ is specified. This flag enables progress reporting even if not
+ attached to a terminal, regardless of `--quiet`.
+
+-f::
+--force::
+ When switching branches, proceed even if the index or the
+ working tree differs from `HEAD`, and even if there are untracked
+ files in the way. This is used to throw away local changes and
+ any untracked files or directories that are in the way.
++
+When checking out paths from the index, do not fail upon unmerged
+entries; instead, unmerged entries are ignored.
+
+--ours::
+--theirs::
+ When checking out paths from the index, check out stage #2
+ ('ours') or #3 ('theirs') for unmerged paths.
++
+Note that during `git rebase` and `git pull --rebase`, 'ours' and
+'theirs' may appear swapped; `--ours` gives the version from the
+branch the changes are rebased onto, while `--theirs` gives the
+version from the branch that holds your work that is being rebased.
++
+This is because `rebase` is used in a workflow that treats the
+history at the remote as the shared canonical one, and treats the
+work done on the branch you are rebasing as the third-party work to
+be integrated, and you are temporarily assuming the role of the
+keeper of the canonical history during the rebase. As the keeper of
+the canonical history, you need to view the history from the remote
+as `ours` (i.e. "our shared canonical history"), while what you did
+on your side branch as `theirs` (i.e. "one contributor's work on top
+of it").
+
+-b <new-branch>::
+ Create a new branch named `<new-branch>`, start it at
+ `<start-point>`, and check the resulting branch out;
+ see linkgit:git-branch[1] for details.
+
+-B <new-branch>::
+ Creates the branch `<new-branch>`, start it at `<start-point>`;
+ if it already exists, then reset it to `<start-point>`. And then
+ check the resulting branch out. This is equivalent to running
+ "git branch" with "-f" followed by "git checkout" of that branch;
+ see linkgit:git-branch[1] for details.
+
+-t::
+--track[=(direct|inherit)]::
+ When creating a new branch, set up "upstream" configuration. See
+ "--track" in linkgit:git-branch[1] for details.
++
+If no `-b` option is given, the name of the new branch will be
+derived from the remote-tracking branch, by looking at the local part of
+the refspec configured for the corresponding remote, and then stripping
+the initial part up to the "*".
+This would tell us to use `hack` as the local branch when branching
+off of `origin/hack` (or `remotes/origin/hack`, or even
+`refs/remotes/origin/hack`). If the given name has no slash, or the above
+guessing results in an empty name, the guessing is aborted. You can
+explicitly give a name with `-b` in such a case.
+
+--no-track::
+ Do not set up "upstream" configuration, even if the
+ `branch.autoSetupMerge` configuration variable is true.
+
+--guess::
+--no-guess::
+ 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>
+------------
++
+If the branch exists in multiple remotes and one of them is named by
+the `checkout.defaultRemote` configuration variable, we'll use that
+one for the purposes of disambiguation, even if the `<branch>` isn't
+unique across all remotes. Set it to
+e.g. `checkout.defaultRemote=origin` to always checkout remote
+branches from there if `<branch>` is ambiguous but exists on the
+'origin' remote. See also `checkout.defaultRemote` in
+linkgit:git-config[1].
++
+`--guess` is the default behavior. Use `--no-guess` to disable it.
++
+The default behavior can be set via the `checkout.guess` configuration
+variable.
+
+-l::
+ Create the new branch's reflog; see linkgit:git-branch[1] for
+ details.
+
+-d::
+--detach::
+ Rather than checking out a branch to work on it, check out a
+ commit for inspection and discardable experiments.
+ This is the default behavior of `git checkout <commit>` when
+ `<commit>` is not a branch name. See the "DETACHED HEAD" section
+ below for details.
+
+--orphan <new-branch>::
+ Create a new unborn branch, named `<new-branch>`, started from
+ `<start-point>` and switch to it. The first commit made on this
+ new branch will have no parents and it will be the root of a new
+ history totally disconnected from all the other branches and
+ commits.
++
+The index and the working tree are adjusted as if you had previously run
+`git checkout <start-point>`. This allows you to start a new history
+that records a set of paths similar to `<start-point>` by easily running
+`git commit -a` to make the root commit.
++
+This can be useful when you want to publish the tree from a commit
+without exposing its full history. You might want to do this to publish
+an open source branch of a project whose current tree is "clean", but
+whose full history contains proprietary or otherwise encumbered bits of
+code.
++
+If you want to start a disconnected history that records a set of paths
+that is totally different from the one of `<start-point>`, then you should
+clear the index and the working tree right after creating the orphan
+branch by running `git rm -rf .` from the top level of the working tree.
+Afterwards you will be ready to prepare your new files, repopulating the
+working tree, by copying them from elsewhere, extracting a tarball, etc.
+
+--ignore-skip-worktree-bits::
+ In sparse checkout mode, `git checkout -- <paths>` would
+ update only entries matched by `<paths>` and sparse patterns
+ in `$GIT_DIR/info/sparse-checkout`. This option ignores
+ the sparse patterns and adds back any files in `<paths>`.
+
+-m::
+--merge::
+ When switching branches,
+ if you have local modifications to one or more files that
+ are different between the current branch and the branch to
+ which you are switching, the command refuses to switch
+ branches in order to preserve your modifications in context.
+ However, with this option, a three-way merge between the current
+ branch, your working tree contents, and the new branch
+ is done, and you will be on the new branch.
++
+When a merge conflict happens, the index entries for conflicting
+paths are left unmerged, and you need to resolve the conflicts
+and mark the resolved paths with `git add` (or `git rm` if the merge
+should result in deletion of the path).
++
+When checking out paths from the index, this option lets you recreate
+the conflicted merge in the specified paths. This option cannot be
+used when checking out paths from a tree-ish.
++
+When switching branches with `--merge`, staged changes may be lost.
+
+--conflict=<style>::
+ The same as `--merge` option above, but changes the way the
+ conflicting hunks are presented, overriding the
+ `merge.conflictStyle` configuration variable. Possible values are
+ "merge" (default), "diff3", and "zdiff3".
+
+-p::
+--patch::
+ Interactively select hunks in the difference between the
+ `<tree-ish>` (or the index, if unspecified) and the working
+ tree. The chosen hunks are then applied in reverse to the
+ working tree (and if a `<tree-ish>` was specified, the index).
++
+This means that you can use `git checkout -p` to selectively discard
+edits from your current working tree. See the ``Interactive Mode''
+section of linkgit:git-add[1] to learn how to operate the `--patch` mode.
++
+Note that this option uses the no overlay mode by default (see also
+`--overlay`), and currently doesn't support overlay mode.
+
+--ignore-other-worktrees::
+ `git checkout` refuses when the wanted branch is already checked
+ out or otherwise in use by another worktree. This option makes
+ it check the branch out anyway. In other words, the branch can
+ be in use by more than one worktree.
+
+--overwrite-ignore::
+--no-overwrite-ignore::
+ Silently overwrite ignored files when switching branches. This
+ is the default behavior. Use `--no-overwrite-ignore` to abort
+ the operation when the new branch contains ignored files.
+
+--recurse-submodules::
+--no-recurse-submodules::
+ Using `--recurse-submodules` will update the content of all active
+ submodules according to the commit recorded in the superproject. If
+ local modifications in a submodule would be overwritten the checkout
+ will fail unless `-f` is used. If nothing (or `--no-recurse-submodules`)
+ is used, submodules working trees will not be updated.
+ Just like linkgit:git-submodule[1], this will detach `HEAD` of the
+ submodule.
+
+--overlay::
+--no-overlay::
+ In the default overlay mode, `git checkout` never
+ removes files from the index or the working tree. When
+ specifying `--no-overlay`, files that appear in the index and
+ working tree, but not in `<tree-ish>` are removed, to make them
+ match `<tree-ish>` exactly.
+
+--pathspec-from-file=<file>::
+ Pathspec is passed in `<file>` instead of commandline args. If
+ `<file>` is exactly `-` then standard input is used. Pathspec
+ elements are separated by LF or CR/LF. Pathspec elements can be
+ quoted as explained for the configuration variable `core.quotePath`
+ (see linkgit:git-config[1]). See also `--pathspec-file-nul` and
+ global `--literal-pathspecs`.
+
+--pathspec-file-nul::
+ Only meaningful with `--pathspec-from-file`. Pathspec elements are
+ separated with NUL character and all other characters are taken
+ literally (including newlines and quotes).
+
+<branch>::
+ Branch to checkout; if it refers to a branch (i.e., a name that,
+ when prepended with "refs/heads/", is a valid ref), then that
+ branch is checked out. Otherwise, if it refers to a valid
+ commit, your `HEAD` becomes "detached" and you are no longer on
+ any branch (see below for details).
++
+You can use the `@{-N}` syntax to refer to the N-th last
+branch/commit checked out using "git checkout" operation. You may
+also specify `-` which is synonymous to `@{-1}`.
++
+As a special case, you may use `A...B` as a shortcut for the
+merge base of `A` and `B` if there is exactly one merge base. You can
+leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.
+
+<new-branch>::
+ Name for the new branch.
+
+<start-point>::
+ The name of a commit at which to start the new branch; see
+ linkgit:git-branch[1] for details. Defaults to `HEAD`.
++
+As a special case, you may use `"A...B"` as a shortcut for the
+merge base of `A` and `B` if there is exactly one merge base. You can
+leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.
+
+<tree-ish>::
+ Tree to checkout from (when paths are given). If not specified,
+ the index will be used.
++
+As a special case, you may use `"A...B"` as a shortcut for the
+merge base of `A` and `B` if there is exactly one merge base. You can
+leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.
+
+\--::
+ Do not interpret any more arguments as options.
+
+<pathspec>...::
+ Limits the paths affected by the operation.
++
+For more details, see the 'pathspec' entry in linkgit:gitglossary[7].
+
+DETACHED HEAD
+-------------
+`HEAD` normally refers to a named branch (e.g. `master`). Meanwhile, each
+branch refers to a specific commit. Let's look at a repo with three
+commits, one of them tagged, and with branch `master` checked out:
+
+------------
+ HEAD (refers to branch 'master')
+ |
+ v
+a---b---c branch 'master' (refers to commit 'c')
+ ^
+ |
+ tag 'v2.0' (refers to commit 'b')
+------------
+
+When a commit is created in this state, the branch is updated to refer to
+the new commit. Specifically, 'git commit' creates a new commit `d`, whose
+parent is commit `c`, and then updates branch `master` to refer to new
+commit `d`. `HEAD` still refers to branch `master` and so indirectly now refers
+to commit `d`:
+
+------------
+$ edit; git add; git commit
+
+ HEAD (refers to branch 'master')
+ |
+ v
+a---b---c---d branch 'master' (refers to commit 'd')
+ ^
+ |
+ tag 'v2.0' (refers to commit 'b')
+------------
+
+It is sometimes useful to be able to checkout a commit that is not at
+the tip of any named branch, or even to create a new commit that is not
+referenced by a named branch. Let's look at what happens when we
+checkout commit `b` (here we show two ways this may be done):
+
+------------
+$ git checkout v2.0 # or
+$ git checkout master^^
+
+ HEAD (refers to commit 'b')
+ |
+ v
+a---b---c---d branch 'master' (refers to commit 'd')
+ ^
+ |
+ tag 'v2.0' (refers to commit 'b')
+------------
+
+Notice that regardless of which checkout command we use, `HEAD` now refers
+directly to commit `b`. This is known as being in detached `HEAD` state.
+It means simply that `HEAD` refers to a specific commit, as opposed to
+referring to a named branch. Let's see what happens when we create a commit:
+
+------------
+$ edit; git add; git commit
+
+ HEAD (refers to commit 'e')
+ |
+ v
+ e
+ /
+a---b---c---d branch 'master' (refers to commit 'd')
+ ^
+ |
+ tag 'v2.0' (refers to commit 'b')
+------------
+
+There is now a new commit `e`, but it is referenced only by `HEAD`. We can
+of course add yet another commit in this state:
+
+------------
+$ edit; git add; git commit
+
+ HEAD (refers to commit 'f')
+ |
+ v
+ e---f
+ /
+a---b---c---d branch 'master' (refers to commit 'd')
+ ^
+ |
+ tag 'v2.0' (refers to commit 'b')
+------------
+
+In fact, we can perform all the normal Git operations. But, let's look
+at what happens when we then checkout `master`:
+
+------------
+$ git checkout master
+
+ HEAD (refers to branch 'master')
+ e---f |
+ / v
+a---b---c---d branch 'master' (refers to commit 'd')
+ ^
+ |
+ tag 'v2.0' (refers to commit 'b')
+------------
+
+It is important to realize that at this point nothing refers to commit
+`f`. Eventually commit `f` (and by extension commit `e`) will be deleted
+by the routine Git garbage collection process, unless we create a reference
+before that happens. If we have not yet moved away from commit `f`,
+any of these will create a reference to it:
+
+------------
+$ git checkout -b foo # or "git switch -c foo" <1>
+$ git branch foo <2>
+$ git tag foo <3>
+------------
+<1> creates a new branch `foo`, which refers to commit `f`, and then
+ updates `HEAD` to refer to branch `foo`. In other words, we'll no longer
+ be in detached `HEAD` state after this command.
+<2> similarly creates a new branch `foo`, which refers to commit `f`,
+ but leaves `HEAD` detached.
+<3> creates a new tag `foo`, which refers to commit `f`,
+ leaving `HEAD` detached.
+
+If we have moved away from commit `f`, then we must first recover its object
+name (typically by using git reflog), and then we can create a reference to
+it. For example, to see the last two commits to which `HEAD` referred, we
+can use either of these commands:
+
+------------
+$ git reflog -2 HEAD # or
+$ git log -g -2 HEAD
+------------
+
+ARGUMENT DISAMBIGUATION
+-----------------------
+
+When there is only one argument given and it is not `--` (e.g. `git
+checkout abc`), and when the argument is both a valid `<tree-ish>`
+(e.g. a branch `abc` exists) and a valid `<pathspec>` (e.g. a file
+or a directory whose name is "abc" exists), Git would usually ask
+you to disambiguate. Because checking out a branch is so common an
+operation, however, `git checkout abc` takes "abc" as a `<tree-ish>`
+in such a situation. Use `git checkout -- <pathspec>` if you want
+to checkout these paths out of the index.
+
+EXAMPLES
+--------
+
+=== 1. Paths
+
+The following sequence checks out the `master` branch, reverts
+the `Makefile` to two revisions back, deletes `hello.c` by
+mistake, and gets it back from the index.
+
+------------
+$ git checkout master <1>
+$ git checkout master~2 Makefile <2>
+$ rm -f hello.c
+$ git checkout hello.c <3>
+------------
+<1> switch branch
+<2> take a file out of another commit
+<3> restore `hello.c` from the index
+
+If you want to check out _all_ C source files out of the index,
+you can say
+
+------------
+$ git checkout -- '*.c'
+------------
+
+Note the quotes around `*.c`. The file `hello.c` will also be
+checked out, even though it is no longer in the working tree,
+because the file globbing is used to match entries in the index
+(not in the working tree by the shell).
+
+If you have an unfortunate branch that is named `hello.c`, this
+step would be confused as an instruction to switch to that branch.
+You should instead write:
+
+------------
+$ git checkout -- hello.c
+------------
+
+=== 2. Merge
+
+After working in the wrong branch, switching to the correct
+branch would be done using:
+
+------------
+$ git checkout mytopic
+------------
+
+However, your "wrong" branch and correct `mytopic` branch may
+differ in files that you have modified locally, in which case
+the above checkout would fail like this:
+
+------------
+$ git checkout mytopic
+error: You have local changes to 'frotz'; not switching branches.
+------------
+
+You can give the `-m` flag to the command, which would try a
+three-way merge:
+
+------------
+$ git checkout -m mytopic
+Auto-merging frotz
+------------
+
+After this three-way merge, the local modifications are _not_
+registered in your index file, so `git diff` would show you what
+changes you made since the tip of the new branch.
+
+=== 3. Merge conflict
+
+When a merge conflict happens during switching branches with
+the `-m` option, you would see something like this:
+
+------------
+$ git checkout -m mytopic
+Auto-merging frotz
+ERROR: Merge conflict in frotz
+fatal: merge program failed
+------------
+
+At this point, `git diff` shows the changes cleanly merged as in
+the previous example, as well as the changes in the conflicted
+files. Edit and resolve the conflict and mark it resolved with
+`git add` as usual:
+
+------------
+$ edit frotz
+$ git add frotz
+------------
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/checkout.adoc[]
+
+SEE ALSO
+--------
+linkgit:git-switch[1],
+linkgit:git-restore[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-cherry-pick.adoc b/git-cherry-pick.adoc
new file mode 100644
index 0000000..42b4192
--- /dev/null
+++ b/git-cherry-pick.adoc
@@ -0,0 +1,259 @@
+git-cherry-pick(1)
+==================
+
+NAME
+----
+git-cherry-pick - Apply the changes introduced by some existing commits
+
+SYNOPSIS
+--------
+[verse]
+'git cherry-pick' [--edit] [-n] [-m <parent-number>] [-s] [-x] [--ff]
+ [-S[<keyid>]] <commit>...
+'git cherry-pick' (--continue | --skip | --abort | --quit)
+
+DESCRIPTION
+-----------
+
+Given one or more existing commits, apply the change each one
+introduces, recording a new commit for each. This requires your
+working tree to be clean (no modifications from the HEAD commit).
+
+When it is not obvious how to apply a change, the following
+happens:
+
+1. The current branch and `HEAD` pointer stay at the last commit
+ successfully made.
+2. The `CHERRY_PICK_HEAD` ref is set to point at the commit that
+ introduced the change that is difficult to apply.
+3. Paths in which the change applied cleanly are updated both
+ in the index file and in your working tree.
+4. For conflicting paths, the index file records up to three
+ versions, as described in the "TRUE MERGE" section of
+ linkgit:git-merge[1]. The working tree files will include
+ a description of the conflict bracketed by the usual
+ conflict markers `<<<<<<<` and `>>>>>>>`.
+5. No other modifications are made.
+
+See linkgit:git-merge[1] for some hints on resolving such
+conflicts.
+
+OPTIONS
+-------
+<commit>...::
+ Commits to cherry-pick.
+ For a more complete list of ways to spell commits, see
+ linkgit:gitrevisions[7].
+ Sets of commits can be passed but no traversal is done by
+ default, as if the `--no-walk` option was specified, see
+ linkgit:git-rev-list[1]. Note that specifying a range will
+ feed all <commit>... arguments to a single revision walk
+ (see a later example that uses 'maint master..next').
+
+-e::
+--edit::
+ With this option, 'git cherry-pick' will let you edit the commit
+ message prior to committing.
+
+--cleanup=<mode>::
+ This option determines how the commit message will be cleaned up before
+ being passed on to the commit machinery. See linkgit:git-commit[1] for more
+ details. In particular, if the '<mode>' is given a value of `scissors`,
+ scissors will be appended to `MERGE_MSG` before being passed on in the case
+ of a conflict.
+
+-x::
+ When recording the commit, append a line that says
+ "(cherry picked from commit ...)" to the original commit
+ message in order to indicate which commit this change was
+ cherry-picked from. This is done only for cherry
+ picks without conflicts. Do not use this option if
+ you are cherry-picking from your private branch because
+ the information is useless to the recipient. If on the
+ other hand you are cherry-picking between two publicly
+ visible branches (e.g. backporting a fix to a
+ maintenance branch for an older release from a
+ development branch), adding this information can be
+ useful.
+
+-r::
+ It used to be that the command defaulted to do `-x`
+ described above, and `-r` was to disable it. Now the
+ default is not to do `-x` so this option is a no-op.
+
+-m <parent-number>::
+--mainline <parent-number>::
+ Usually you cannot cherry-pick a merge because you do not know which
+ side of the merge should be considered the mainline. This
+ option specifies the parent number (starting from 1) of
+ the mainline and allows cherry-pick to replay the change
+ relative to the specified parent.
+
+-n::
+--no-commit::
+ Usually the command automatically creates a sequence of commits.
+ This flag applies the changes necessary to cherry-pick
+ each named commit to your working tree and the index,
+ without making any commit. In addition, when this
+ option is used, your index does not have to match the
+ HEAD commit. The cherry-pick is done against the
+ beginning state of your index.
++
+This is useful when cherry-picking more than one commits'
+effect to your index in a row.
+
+-s::
+--signoff::
+ Add a `Signed-off-by` trailer at the end of the commit message.
+ See the signoff option in linkgit:git-commit[1] for more information.
+
+-S[<keyid>]::
+--gpg-sign[=<keyid>]::
+--no-gpg-sign::
+ GPG-sign commits. The `keyid` argument is optional and
+ defaults to the committer identity; if specified, it must be
+ stuck to the option without a space. `--no-gpg-sign` is useful to
+ countermand both `commit.gpgSign` configuration variable, and
+ earlier `--gpg-sign`.
+
+--ff::
+ If the current HEAD is the same as the parent of the
+ cherry-pick'ed commit, then a fast forward to this commit will
+ be performed.
+
+--allow-empty::
+ By default, cherry-picking an empty commit will fail,
+ indicating that an explicit invocation of `git commit
+ --allow-empty` is required. This option overrides that
+ behavior, allowing empty commits to be preserved automatically
+ in a cherry-pick. Note that when "--ff" is in effect, empty
+ commits that meet the "fast-forward" requirement will be kept
+ even without this option. Note also, that use of this option only
+ keeps commits that were initially empty (i.e. the commit recorded the
+ same tree as its parent). Commits which are made empty due to a
+ previous commit will cause the cherry-pick to fail. To force the
+ inclusion of those commits, use `--empty=keep`.
+
+--allow-empty-message::
+ By default, cherry-picking a commit with an empty message will fail.
+ This option overrides that behavior, allowing commits with empty
+ messages to be cherry picked.
+
+--empty=(drop|keep|stop)::
+ How to handle commits being cherry-picked that are redundant with
+ changes already in the current history.
++
+--
+`drop`;;
+ The commit will be dropped.
+`keep`;;
+ The commit will be kept. Implies `--allow-empty`.
+`stop`;;
+ The cherry-pick will stop when the commit is applied, allowing
+ you to examine the commit. This is the default behavior.
+--
++
+Note that `--empty=drop` and `--empty=stop` only specify how to handle a
+commit that was not initially empty, but rather became empty due to a previous
+commit. Commits that were initially empty will still cause the cherry-pick to
+fail unless one of `--empty=keep` or `--allow-empty` are specified.
++
+
+--keep-redundant-commits::
+ Deprecated synonym for `--empty=keep`.
+
+--strategy=<strategy>::
+ Use the given merge strategy. Should only be used once.
+ See the MERGE STRATEGIES section in linkgit:git-merge[1]
+ for details.
+
+-X<option>::
+--strategy-option=<option>::
+ Pass the merge strategy-specific option through to the
+ merge strategy. See linkgit:git-merge[1] for details.
+
+include::rerere-options.adoc[]
+
+SEQUENCER SUBCOMMANDS
+---------------------
+include::sequencer.adoc[]
+
+EXAMPLES
+--------
+`git cherry-pick master`::
+
+ Apply the change introduced by the commit at the tip of the
+ master branch and create a new commit with this change.
+
+`git cherry-pick ..master`::
+`git cherry-pick ^HEAD master`::
+
+ Apply the changes introduced by all commits that are ancestors
+ of master but not of HEAD to produce new commits.
+
+`git cherry-pick maint next ^master`::
+`git cherry-pick maint master..next`::
+
+ Apply the changes introduced by all commits that are
+ ancestors of maint or next, but not master or any of its
+ ancestors. Note that the latter does not mean `maint` and
+ everything between `master` and `next`; specifically,
+ `maint` will not be used if it is included in `master`.
+
+`git cherry-pick master~4 master~2`::
+
+ Apply the changes introduced by the fifth and third last
+ commits pointed to by master and create 2 new commits with
+ these changes.
+
+`git cherry-pick -n master~1 next`::
+
+ Apply to the working tree and the index the changes introduced
+ by the second last commit pointed to by master and by the last
+ commit pointed to by next, but do not create any commit with
+ these changes.
+
+`git cherry-pick --ff ..next`::
+
+ If history is linear and HEAD is an ancestor of next, update
+ the working tree and advance the HEAD pointer to match next.
+ Otherwise, apply the changes introduced by those commits that
+ are in next but not HEAD to the current branch, creating a new
+ commit for each new change.
+
+`git rev-list --reverse master -- README | git cherry-pick -n --stdin`::
+
+ Apply the changes introduced by all commits on the master
+ branch that touched README to the working tree and index,
+ so the result can be inspected and made into a single new
+ commit if suitable.
+
+The following sequence attempts to backport a patch, bails out because
+the code the patch applies to has changed too much, and then tries
+again, this time exercising more care about matching up context lines.
+
+------------
+$ git cherry-pick topic^ <1>
+$ git diff <2>
+$ git cherry-pick --abort <3>
+$ git cherry-pick -Xpatience topic^ <4>
+------------
+<1> apply the change that would be shown by `git show topic^`.
+ In this example, the patch does not apply cleanly, so
+ information about the conflict is written to the index and
+ working tree and no new commit results.
+<2> summarize changes to be reconciled
+<3> cancel the cherry-pick. In other words, return to the
+ pre-cherry-pick state, preserving any local modifications
+ you had in the working tree.
+<4> try to apply the change introduced by `topic^` again,
+ spending extra time to avoid mistakes based on incorrectly
+ matching context lines.
+
+SEE ALSO
+--------
+linkgit:git-revert[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-cherry.adoc b/git-cherry.adoc
new file mode 100644
index 0000000..0ea921a
--- /dev/null
+++ b/git-cherry.adoc
@@ -0,0 +1,145 @@
+git-cherry(1)
+=============
+
+NAME
+----
+git-cherry - Find commits yet to be applied to upstream
+
+SYNOPSIS
+--------
+[verse]
+'git cherry' [-v] [<upstream> [<head> [<limit>]]]
+
+DESCRIPTION
+-----------
+Determine whether there are commits in `<head>..<upstream>` that are
+equivalent to those in the range `<limit>..<head>`.
+
+The equivalence test is based on the diff, after removing whitespace
+and line numbers. git-cherry therefore detects when commits have been
+"copied" by means of linkgit:git-cherry-pick[1], linkgit:git-am[1] or
+linkgit:git-rebase[1].
+
+Outputs the SHA1 of every commit in `<limit>..<head>`, prefixed with
+`-` for commits that have an equivalent in <upstream>, and `+` for
+commits that do not.
+
+OPTIONS
+-------
+-v::
+ Show the commit subjects next to the SHA1s.
+
+<upstream>::
+ Upstream branch to search for equivalent commits.
+ Defaults to the upstream branch of HEAD.
+
+<head>::
+ Working branch; defaults to HEAD.
+
+<limit>::
+ Do not report commits up to (and including) limit.
+
+EXAMPLES
+--------
+
+Patch workflows
+~~~~~~~~~~~~~~~
+
+git-cherry is frequently used in patch-based workflows (see
+linkgit:gitworkflows[7]) to determine if a series of patches has been
+applied by the upstream maintainer. In such a workflow you might
+create and send a topic branch like this:
+
+------------
+$ git checkout -b topic origin/master
+# work and create some commits
+$ git format-patch origin/master
+$ git send-email ... 00*
+------------
+
+Later, you can see whether your changes have been applied by saying
+(still on `topic`):
+
+------------
+$ git fetch # update your notion of origin/master
+$ git cherry -v
+------------
+
+Concrete example
+~~~~~~~~~~~~~~~~
+
+In a situation where topic consisted of three commits, and the
+maintainer applied two of them, the situation might look like:
+
+------------
+$ git log --graph --oneline --decorate --boundary origin/master...topic
+* 7654321 (origin/master) upstream tip commit
+[... snip some other commits ...]
+* cccc111 cherry-pick of C
+* aaaa111 cherry-pick of A
+[... snip a lot more that has happened ...]
+| * cccc000 (topic) commit C
+| * bbbb000 commit B
+| * aaaa000 commit A
+|/
+o 1234567 branch point
+------------
+
+In such cases, git-cherry shows a concise summary of what has yet to
+be applied:
+
+------------
+$ git cherry origin/master topic
+- cccc000... commit C
++ bbbb000... commit B
+- aaaa000... commit A
+------------
+
+Here, we see that the commits A and C (marked with `-`) can be
+dropped from your `topic` branch when you rebase it on top of
+`origin/master`, while the commit B (marked with `+`) still needs to
+be kept so that it will be sent to be applied to `origin/master`.
+
+
+Using a limit
+~~~~~~~~~~~~~
+
+The optional <limit> is useful in cases where your topic is based on
+other work that is not in upstream. Expanding on the previous
+example, this might look like:
+
+------------
+$ git log --graph --oneline --decorate --boundary origin/master...topic
+* 7654321 (origin/master) upstream tip commit
+[... snip some other commits ...]
+* cccc111 cherry-pick of C
+* aaaa111 cherry-pick of A
+[... snip a lot more that has happened ...]
+| * cccc000 (topic) commit C
+| * bbbb000 commit B
+| * aaaa000 commit A
+| * 0000fff (base) unpublished stuff F
+[... snip ...]
+| * 0000aaa unpublished stuff A
+|/
+o 1234567 merge-base between upstream and topic
+------------
+
+By specifying `base` as the limit, you can avoid listing commits
+between `base` and `topic`:
+
+------------
+$ git cherry origin/master topic base
+- cccc000... commit C
++ bbbb000... commit B
+- aaaa000... commit A
+------------
+
+
+SEE ALSO
+--------
+linkgit:git-patch-id[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-citool.adoc b/git-citool.adoc
new file mode 100644
index 0000000..c7a11c3
--- /dev/null
+++ b/git-citool.adoc
@@ -0,0 +1,25 @@
+git-citool(1)
+=============
+
+NAME
+----
+git-citool - Graphical alternative to git-commit
+
+SYNOPSIS
+--------
+[verse]
+'git citool'
+
+DESCRIPTION
+-----------
+A Tcl/Tk based graphical interface to review modified files, stage
+them into the index, enter a commit message and record the new
+commit onto the current branch. This interface is an alternative
+to the less interactive 'git commit' program.
+
+'git citool' is actually a standard alias for `git gui citool`.
+See linkgit:git-gui[1] for more details.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-clean.adoc b/git-clean.adoc
new file mode 100644
index 0000000..bed52c2
--- /dev/null
+++ b/git-clean.adoc
@@ -0,0 +1,153 @@
+git-clean(1)
+============
+
+NAME
+----
+git-clean - Remove untracked files from the working tree
+
+SYNOPSIS
+--------
+[verse]
+'git clean' [-d] [-f] [-i] [-n] [-q] [-e <pattern>] [-x | -X] [--] [<pathspec>...]
+
+DESCRIPTION
+-----------
+
+Cleans the working tree by recursively removing files that are not
+under version control, starting from the current directory.
+
+Normally, only files unknown to Git are removed, but if the `-x`
+option is specified, ignored files are also removed. This can, for
+example, be useful to remove all build products.
+
+If any optional `<pathspec>...` arguments are given, only those paths
+that match the pathspec are affected.
+
+OPTIONS
+-------
+-d::
+ Normally, when no <pathspec> is specified, git clean will not
+ recurse into untracked directories to avoid removing too much.
+ Specify -d to have it recurse into such directories as well.
+ If a <pathspec> is specified, -d is irrelevant; all untracked
+ files matching the specified paths (with exceptions for nested
+ git directories mentioned under `--force`) will be removed.
+
+-f::
+--force::
+ If the Git configuration variable clean.requireForce is not set
+ to false, 'git clean' will refuse to delete files or directories
+ unless given -f. Git will refuse to modify untracked
+ nested git repositories (directories with a .git subdirectory)
+ unless a second -f is given.
+
+-i::
+--interactive::
+ Show what would be done and clean files interactively. See
+ ``Interactive mode'' for details.
+ Configuration variable `clean.requireForce` is ignored, as
+ this mode gives its own safety protection by going interactive.
+
+-n::
+--dry-run::
+ Don't actually remove anything, just show what would be done.
+ Configuration variable `clean.requireForce` is ignored, as
+ nothing will be deleted anyway.
+
+-q::
+--quiet::
+ Be quiet, only report errors, but not the files that are
+ successfully removed.
+
+-e <pattern>::
+--exclude=<pattern>::
+ Use the given exclude pattern in addition to the standard ignore rules
+ (see linkgit:gitignore[5]).
+
+-x::
+ Don't use the standard ignore rules (see linkgit:gitignore[5]), but
+ still use the ignore rules given with `-e` options from the command
+ line. This allows removing all untracked
+ files, including build products. This can be used (possibly in
+ conjunction with 'git restore' or 'git reset') to create a pristine
+ working directory to test a clean build.
+
+-X::
+ Remove only files ignored by Git. This may be useful to rebuild
+ everything from scratch, but keep manually created files.
+
+Interactive mode
+----------------
+When the command enters the interactive mode, it shows the
+files and directories to be cleaned, and goes into its
+interactive command loop.
+
+The command loop shows the list of subcommands available, and
+gives a prompt "What now> ". In general, when the prompt ends
+with a single '>', you can pick only one of the choices given
+and type return, like this:
+
+------------
+ *** Commands ***
+ 1: clean 2: filter by pattern 3: select by numbers
+ 4: ask each 5: quit 6: help
+ What now> 1
+------------
+
+You also could say `c` or `clean` above as long as the choice is unique.
+
+The main command loop has 6 subcommands.
+
+clean::
+
+ Start cleaning files and directories, and then quit.
+
+filter by pattern::
+
+ This shows the files and directories to be deleted and issues an
+ "Input ignore patterns>>" prompt. You can input space-separated
+ patterns to exclude files and directories from deletion.
+ E.g. "*.c *.h" will exclude files ending with ".c" and ".h" from
+ deletion. When you are satisfied with the filtered result, press
+ ENTER (empty) back to the main menu.
+
+select by numbers::
+
+ This shows the files and directories to be deleted and issues an
+ "Select items to delete>>" prompt. When the prompt ends with double
+ '>>' like this, you can make more than one selection, concatenated
+ with whitespace or comma. Also you can say ranges. E.g. "2-5 7,9"
+ to choose 2,3,4,5,7,9 from the list. If the second number in a
+ range is omitted, all remaining items are selected. E.g. "7-" to
+ choose 7,8,9 from the list. You can say '*' to choose everything.
+ Also when you are satisfied with the filtered result, press ENTER
+ (empty) back to the main menu.
+
+ask each::
+
+ This will start to clean, and you must confirm one by one in order
+ to delete items. Please note that this action is not as efficient
+ as the above two actions.
+
+quit::
+
+ This lets you quit without doing any cleaning.
+
+help::
+
+ Show brief usage of interactive git-clean.
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/clean.adoc[]
+
+SEE ALSO
+--------
+linkgit:gitignore[5]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-clone.adoc b/git-clone.adoc
new file mode 100644
index 0000000..510b91b
--- /dev/null
+++ b/git-clone.adoc
@@ -0,0 +1,420 @@
+git-clone(1)
+============
+
+NAME
+----
+git-clone - Clone a repository into a new directory
+
+
+SYNOPSIS
+--------
+[synopsis]
+git clone [--template=<template-directory>]
+ [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
+ [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>]
+ [--dissociate] [--separate-git-dir <git-dir>]
+ [--depth <depth>] [--[no-]single-branch] [--[no-]tags]
+ [--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules]
+ [--[no-]remote-submodules] [--jobs <n>] [--sparse] [--[no-]reject-shallow]
+ [--filter=<filter-spec>] [--also-filter-submodules]] [--] <repository>
+ [<directory>]
+
+DESCRIPTION
+-----------
+
+Clones a repository into a newly created directory, creates
+remote-tracking branches for each branch in the cloned repository
+(visible using `git branch --remotes`), and creates and checks out an
+initial branch that is forked from the cloned repository's
+currently active branch.
+
+After the clone, a plain `git fetch` without arguments will update
+all the remote-tracking branches, and a `git pull` without
+arguments will in addition merge the remote master branch into the
+current master branch, if any (this is untrue when `--single-branch`
+is given; see below).
+
+This default configuration is achieved by creating references to
+the remote branch heads under `refs/remotes/origin` and
+by initializing `remote.origin.url` and `remote.origin.fetch`
+configuration variables.
+
+
+OPTIONS
+-------
+`-l`::
+`--local`::
+ When the repository to clone from is on a local machine,
+ this flag bypasses the normal "Git aware" transport
+ mechanism and clones the repository by making a copy of
+ `HEAD` and everything under objects and refs directories.
+ The files under `.git/objects/` directory are hardlinked
+ to save space when possible.
++
+If the repository is specified as a local path (e.g., `/path/to/repo`),
+this is the default, and `--local` is essentially a no-op. If the
+repository is specified as a URL, then this flag is ignored (and we
+never use the local optimizations). Specifying `--no-local` will
+override the default when `/path/to/repo` is given, using the regular
+Git transport instead.
++
+If the repository's `$GIT_DIR/objects` has symbolic links or is a
+symbolic link, the clone will fail. This is a security measure to
+prevent the unintentional copying of files by dereferencing the symbolic
+links.
++
+This option does not work with repositories owned by other users for security
+reasons, and `--no-local` must be specified for the clone to succeed.
++
+*NOTE*: this operation can race with concurrent modification to the
+source repository, similar to running `cp -r <src> <dst>` while modifying
+_<src>_.
+
+`--no-hardlinks`::
+ Force the cloning process from a repository on a local
+ filesystem to copy the files under the `.git/objects`
+ directory instead of using hardlinks. This may be desirable
+ if you are trying to make a back-up of your repository.
+
+`-s`::
+`--shared`::
+ When the repository to clone is on the local machine,
+ instead of using hard links, automatically setup
+ `.git/objects/info/alternates` to share the objects
+ with the source repository. The resulting repository
+ starts out without any object of its own.
++
+*NOTE*: this is a possibly dangerous operation; do *not* use
+it unless you understand what it does. If you clone your
+repository using this option and then delete branches (or use any
+other Git command that makes any existing commit unreferenced) in the
+source repository, some objects may become unreferenced (or dangling).
+These objects may be removed by normal Git operations (such as `git commit`)
+which automatically call `git maintenance run --auto`. (See
+linkgit:git-maintenance[1].) If these objects are removed and were referenced
+by the cloned repository, then the cloned repository will become corrupt.
++
+Note that running `git repack` without the `--local` option in a repository
+cloned with `--shared` will copy objects from the source repository into a pack
+in the cloned repository, removing the disk space savings of `clone --shared`.
+It is safe, however, to run `git gc`, which uses the `--local` option by
+default.
++
+If you want to break the dependency of a repository cloned with `--shared` on
+its source repository, you can simply run `git repack -a` to copy all
+objects from the source repository into a pack in the cloned repository.
+
+`--reference[-if-able] <repository>`::
+ If the reference _<repository>_ is on the local machine,
+ automatically setup `.git/objects/info/alternates` to
+ obtain objects from the reference _<repository>_. Using
+ an already existing repository as an alternate will
+ require fewer objects to be copied from the repository
+ being cloned, reducing network and local storage costs.
+ When using the `--reference-if-able`, a non existing
+ directory is skipped with a warning instead of aborting
+ the clone.
++
+*NOTE*: see the NOTE for the `--shared` option, and also the
+`--dissociate` option.
+
+`--dissociate`::
+ Borrow the objects from reference repositories specified
+ with the `--reference` options only to reduce network
+ transfer, and stop borrowing from them after a clone is made
+ by making necessary local copies of borrowed objects. This
+ option can also be used when cloning locally from a
+ repository that already borrows objects from another
+ repository--the new repository will borrow objects from the
+ same repository, and this option can be used to stop the
+ borrowing.
+
+`-q`::
+`--quiet`::
+ Operate quietly. Progress is not reported to the standard
+ error stream.
+
+`-v`::
+`--verbose`::
+ Run verbosely. Does not affect the reporting of progress status
+ to the standard error stream.
+
+`--progress`::
+ Progress status is reported on the standard error stream
+ by default when it is attached to a terminal, unless `--quiet`
+ is specified. This flag forces progress status even if the
+ standard error stream is not directed to a terminal.
+
+`--server-option=<option>`::
+ Transmit the given string to the server when communicating using
+ protocol version 2. The given string must not contain a NUL or LF
+ character. The server's handling of server options, including
+ unknown ones, is server-specific.
+ When multiple `--server-option=<option>` are given, they are all
+ sent to the other side in the order listed on the command line.
+ When no ++--server-option=++__<option>__ is given from the command
+ line, the values of configuration variable `remote.<name>.serverOption`
+ are used instead.
+
+`-n`::
+`--no-checkout`::
+ No checkout of `HEAD` is performed after the clone is complete.
+
+`--`[`no-`]`reject-shallow`::
+ Fail if the source repository is a shallow repository.
+ The `clone.rejectShallow` configuration variable can be used to
+ specify the default.
+
+`--bare`::
+ Make a 'bare' Git repository. That is, instead of
+ creating _<directory>_ and placing the administrative
+ files in `<directory>/.git`, make the _<directory>_
+ itself the `$GIT_DIR`. This obviously implies the `--no-checkout`
+ because there is nowhere to check out the working tree.
+ Also the branch heads at the remote are copied directly
+ to corresponding local branch heads, without mapping
+ them to `refs/remotes/origin/`. When this option is
+ used, neither remote-tracking branches nor the related
+ configuration variables are created.
+
+`--sparse`::
+ Employ a sparse-checkout, with only files in the toplevel
+ directory initially being present. The
+ linkgit:git-sparse-checkout[1] command can be used to grow the
+ working directory as needed.
+
+`--filter=<filter-spec>`::
+ Use the partial clone feature and request that the server sends
+ a subset of reachable objects according to a given object filter.
+ When using `--filter`, the supplied _<filter-spec>_ is used for
+ the partial clone filter. For example, `--filter=blob:none` will
+ filter out all blobs (file contents) until needed by Git. Also,
+ `--filter=blob:limit=<size>` will filter out all blobs of size
+ at least _<size>_. For more details on filter specifications, see
+ the `--filter` option in linkgit:git-rev-list[1].
+
+`--also-filter-submodules`::
+ Also apply the partial clone filter to any submodules in the repository.
+ Requires `--filter` and `--recurse-submodules`. This can be turned on by
+ default by setting the `clone.filterSubmodules` config option.
+
+`--mirror`::
+ Set up a mirror of the source repository. This implies `--bare`.
+ Compared to `--bare`, `--mirror` not only maps local branches of the
+ source to local branches of the target, it maps all refs (including
+ remote-tracking branches, notes etc.) and sets up a refspec configuration such
+ that all these refs are overwritten by a `git remote update` in the
+ target repository.
+
+`-o` _<name>_::
+`--origin` _<name>_::
+ Instead of using the remote name `origin` to keep track of the upstream
+ repository, use _<name>_. Overrides `clone.defaultRemoteName` from the
+ config.
+
+`-b` _<name>_::
+`--branch` _<name>_::
+ Instead of pointing the newly created `HEAD` to the branch pointed
+ to by the cloned repository's `HEAD`, point to _<name>_ branch
+ instead. In a non-bare repository, this is the branch that will
+ be checked out.
+ `--branch` can also take tags and detaches the `HEAD` at that commit
+ in the resulting repository.
+
+`--revision=<rev>`::
+ Create a new repository, and fetch the history leading to the given
+ revision _<rev>_ (and nothing else), without making any remote-tracking
+ branch, and without making any local branch, and detach `HEAD` to
+ _<rev>_. The argument can be a ref name (e.g. `refs/heads/main` or
+ `refs/tags/v1.0`) that peels down to a commit, or a hexadecimal object
+ name.
+ This option is incompatible with `--branch` and `--mirror`.
+
+`-u` _<upload-pack>_::
+`--upload-pack` _<upload-pack>_::
+ When given, and the repository to clone from is accessed
+ via ssh, this specifies a non-default path for the command
+ run on the other end.
+
+`--template=<template-directory>`::
+ Specify the directory from which templates will be used;
+ (See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].)
+
+`-c` `<key>=<value>`::
+`--config` `<key>=<value>`::
+ Set a configuration variable in the newly-created repository;
+ this takes effect immediately after the repository is
+ initialized, but before the remote history is fetched or any
+ files checked out. The _<key>_ is in the same format as expected by
+ linkgit:git-config[1] (e.g., `core.eol=true`). If multiple
+ values are given for the same key, each value will be written to
+ the config file. This makes it safe, for example, to add
+ additional fetch refspecs to the origin remote.
++
+Due to limitations of the current implementation, some configuration
+variables do not take effect until after the initial fetch and checkout.
+Configuration variables known to not take effect are:
+`remote.<name>.mirror` and `remote.<name>.tagOpt`. Use the
+corresponding `--mirror` and `--no-tags` options instead.
+
+`--depth <depth>`::
+ Create a 'shallow' clone with a history truncated to the
+ specified number of commits. Implies `--single-branch` unless
+ `--no-single-branch` is given to fetch the histories near the
+ tips of all branches. If you want to clone submodules shallowly,
+ also pass `--shallow-submodules`.
+
+`--shallow-since=<date>`::
+ Create a shallow clone with a history after the specified time.
+
+`--shallow-exclude=<ref>`::
+ Create a shallow clone with a history, excluding commits
+ reachable from a specified remote branch or tag. This option
+ can be specified multiple times.
+
+`--[no-]single-branch`::
+ Clone only the history leading to the tip of a single branch,
+ either specified by the `--branch` option or the primary
+ branch remote's `HEAD` points at.
+ Further fetches into the resulting repository will only update the
+ remote-tracking branch for the branch this option was used for the
+ initial cloning. If the `HEAD` at the remote did not point at any
+ branch when `--single-branch` clone was made, no remote-tracking
+ branch is created.
+
+`--[no-]tags`::
+ Control whether or not tags will be cloned. When `--no-tags` is
+ given, the option will be become permanent by setting the
+ `remote.<remote>.tagOpt=--no-tags` configuration. This ensures that
+ future `git pull` and `git fetch` won't follow any tags. Subsequent
+ explicit tag fetches will still work (see linkgit:git-fetch[1]).
+
+ By default, tags are cloned and passing `--tags` is thus typically a
+ no-op, unless it cancels out a previous `--no-tags`.
++
+Can be used in conjunction with `--single-branch` to clone and
+maintain a branch with no references other than a single cloned
+branch. This is useful e.g. to maintain minimal clones of the default
+branch of some repository for search indexing.
+
+`--recurse-submodules[=<pathspec>]`::
+ After the clone is created, initialize and clone submodules
+ within based on the provided _<pathspec>_. If no `=<pathspec>` is
+ provided, all submodules are initialized and cloned.
+ This option can be given multiple times for pathspecs consisting
+ of multiple entries. The resulting clone has `submodule.active` set to
+ the provided pathspec, or "`.`" (meaning all submodules) if no
+ pathspec is provided.
++
+Submodules are initialized and cloned using their default settings. This is
+equivalent to running
+`git submodule update --init --recursive <pathspec>` immediately after
+the clone is finished. This option is ignored if the cloned repository does
+not have a worktree/checkout (i.e. if any of `--no-checkout`/`-n`, `--bare`,
+or `--mirror` is given)
+
+`--[no-]shallow-submodules`::
+ All submodules which are cloned will be shallow with a depth of 1.
+
+`--[no-]remote-submodules`::
+ All submodules which are cloned will use the status of the submodule's
+ remote-tracking branch to update the submodule, rather than the
+ superproject's recorded SHA-1. Equivalent to passing `--remote` to
+ `git submodule update`.
+
+`--separate-git-dir=<git-dir>`::
+ Instead of placing the cloned repository where it is supposed
+ to be, place the cloned repository at the specified directory,
+ then make a filesystem-agnostic Git symbolic link to there.
+ The result is Git repository can be separated from working
+ tree.
+
+`--ref-format=<ref-format>`::
+
+Specify the given ref storage format for the repository. The valid values are:
++
+include::ref-storage-format.adoc[]
+
+`-j` _<n>_::
+`--jobs` _<n>_::
+ The number of submodules fetched at the same time.
+ Defaults to the `submodule.fetchJobs` option.
+
+_<repository>_::
+ The (possibly remote) _<repository>_ to clone from. See the
+ <<URLS,GIT URLS>> section below for more information on specifying
+ repositories.
+
+_<directory>_::
+ The name of a new directory to clone into. The "humanish"
+ part of the source repository is used if no _<directory>_ is
+ explicitly given (`repo` for `/path/to/repo.git` and `foo`
+ for `host.xz:foo/.git`). Cloning into an existing directory
+ is only allowed if the directory is empty.
+
+`--bundle-uri=<uri>`::
+ Before fetching from the remote, fetch a bundle from the given
+ _<uri>_ and unbundle the data into the local repository. The refs
+ in the bundle will be stored under the hidden `refs/bundle/*`
+ namespace. This option is incompatible with `--depth`,
+ `--shallow-since`, and `--shallow-exclude`.
+
+:git-clone: 1
+include::urls.adoc[]
+
+EXAMPLES
+--------
+
+* Clone from upstream:
++
+------------
+$ git clone git://git.kernel.org/pub/scm/.../linux.git my-linux
+$ cd my-linux
+$ make
+------------
+
+
+* Make a local clone that borrows from the current directory, without checking things out:
++
+------------
+$ git clone -l -s -n . ../copy
+$ cd ../copy
+$ git show-branch
+------------
+
+
+* Clone from upstream while borrowing from an existing local directory:
++
+------------
+$ git clone --reference /git/linux.git \
+ git://git.kernel.org/pub/scm/.../linux.git \
+ my-linux
+$ cd my-linux
+------------
+
+
+* Create a bare repository to publish your changes to the public:
++
+------------
+$ git clone --bare -l /home/proj/.git /pub/scm/proj.git
+------------
+
+* Clone a local repository from a different user:
++
+------------
+$ git clone --no-local /home/otheruser/proj.git /pub/scm/proj.git
+------------
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/init.adoc[]
+
+include::config/clone.adoc[]
+
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-clone.html b/git-clone.html
index 9d5e108..9f4a684 100644
--- a/git-clone.html
+++ b/git-clone.html
@@ -455,7 +455,7 @@
[<code>-l</code>] [<code>-s</code>] [<code>--no-hardlinks</code>] [<code>-q</code>] [<code>-n</code>] [<code>--bare</code>] [<code>--mirror</code>]
[<code>-o</code> <em><name></em>] [<code>-b</code> <em><name></em>] [<code>-u</code> <em><upload-pack></em>] [<code>--reference</code> <em><repository></em>]
[<code>--dissociate</code>] [<code>--separate-git-dir</code> <em><git-dir></em>]
- [<code>--depth</code> <em><depth></em>] [<code>--</code>[<code>no-</code>]<code>single-branch</code>] [<code>--no-tags</code>]
+ [<code>--depth</code> <em><depth></em>] [<code>--</code>[<code>no-</code>]<code>single-branch</code>] [<code>--</code>[<code>no-</code>]<code>tags</code>]
[<code>--recurse-submodules</code>[<code>=</code><em><pathspec></em>]] [<code>--</code>[<code>no-</code>]<code>shallow-submodules</code>]
[<code>--</code>[<code>no-</code>]<code>remote-submodules</code>] [<code>--jobs</code> <em><n></em>] [<code>--sparse</code>] [<code>--</code>[<code>no-</code>]<code>reject-shallow</code>]
[<code>--filter=</code><em><filter-spec></em>] [<code>--also-filter-submodules</code>]] [<code>--</code>] <em><repository></em>
@@ -698,6 +698,16 @@
<code>--branch</code> can also take tags and detaches the <code>HEAD</code> at that commit
in the resulting repository.</p>
</dd>
+<dt class="hdlist1"><code>--revision=</code><em><rev></em></dt>
+<dd>
+<p>Create a new repository, and fetch the history leading to the given
+revision <em><rev></em> (and nothing else), without making any remote-tracking
+branch, and without making any local branch, and detach <code>HEAD</code> to
+<em><rev></em>. The argument can be a ref name (e.g. <code>refs/heads/main</code> or
+<code>refs/tags/v1.0</code>) that peels down to a commit, or a hexadecimal object
+name.
+This option is incompatible with <code>--branch</code> and <code>--mirror</code>.</p>
+</dd>
<dt class="hdlist1"><code>-u</code> <em><upload-pack></em></dt>
<dt class="hdlist1"><code>--upload-pack</code> <em><upload-pack></em></dt>
<dd>
@@ -758,13 +768,19 @@
branch when <code>--single-branch</code> clone was made, no remote-tracking
branch is created.</p>
</dd>
-<dt class="hdlist1"><code>--no-tags</code></dt>
+<dt class="hdlist1"><code>--</code>[<code>no-</code>]<code>tags</code></dt>
<dd>
-<p>Don’t clone any tags, and set
-<code>remote.</code><em><remote></em><code>.tagOpt=--no-tags</code> in the config, ensuring
-that future <code>git</code> <code>pull</code> and <code>git</code> <code>fetch</code> operations won’t follow
-any tags. Subsequent explicit tag fetches will still work,
-(see <a href="git-fetch.html">git-fetch(1)</a>).</p>
+<p>Control whether or not tags will be cloned. When <code>--no-tags</code> is
+given, the option will be become permanent by setting the
+<code>remote.</code><em><remote></em><code>.tagOpt=--no-tags</code> configuration. This ensures that
+future <code>git</code> <code>pull</code> and <code>git</code> <code>fetch</code> won’t follow any tags. Subsequent
+explicit tag fetches will still work (see <a href="git-fetch.html">git-fetch(1)</a>).</p>
+<div class="literalblock">
+<div class="content">
+<pre>By default, tags are cloned and passing `--tags` is thus typically a
+no-op, unless it cancels out a previous `--no-tags`.</pre>
+</div>
+</div>
<div class="paragraph">
<p>Can be used in conjunction with <code>--single-branch</code> to clone and
maintain a branch with no references other than a single cloned
@@ -1136,7 +1152,7 @@
</div>
<div id="footer">
<div id="footer-text">
-Last updated 2024-12-10 04:07:44 -0800
+Last updated 2025-02-14 21:38:14 -0800
</div>
</div>
</body>
diff --git a/git-column.adoc b/git-column.adoc
new file mode 100644
index 0000000..85fb87c
--- /dev/null
+++ b/git-column.adoc
@@ -0,0 +1,86 @@
+git-column(1)
+=============
+
+NAME
+----
+git-column - Display data in columns
+
+SYNOPSIS
+--------
+[verse]
+'git column' [--command=<name>] [--[raw-]mode=<mode>] [--width=<width>]
+ [--indent=<string>] [--nl=<string>] [--padding=<n>]
+
+DESCRIPTION
+-----------
+This command formats the lines of its standard input into a table with
+multiple columns. Each input line occupies one cell of the table. It
+is used internally by other git commands to format output into
+columns.
+
+OPTIONS
+-------
+--command=<name>::
+ Look up layout mode using configuration variable column.<name> and
+ column.ui.
+
+--mode=<mode>::
+ Specify layout mode. See configuration variable column.ui for option
+ syntax in linkgit:git-config[1].
+
+--raw-mode=<n>::
+ Same as --mode but take mode encoded as a number. This is mainly used
+ by other commands that have already parsed layout mode.
+
+--width=<width>::
+ Specify the terminal width. By default 'git column' will detect the
+ terminal width, or fall back to 80 if it is unable to do so.
+
+--indent=<string>::
+ String to be printed at the beginning of each line.
+
+--nl=<string>::
+ String to be printed at the end of each line,
+ including newline character.
+
+--padding=<N>::
+ The number of spaces between columns. One space by default.
+
+EXAMPLES
+--------
+
+Format data by columns:
+------------
+$ seq 1 24 | git column --mode=column --padding=5
+1 4 7 10 13 16 19 22
+2 5 8 11 14 17 20 23
+3 6 9 12 15 18 21 24
+------------
+
+Format data by rows:
+------------
+$ seq 1 21 | git column --mode=row --padding=5
+1 2 3 4 5 6 7
+8 9 10 11 12 13 14
+15 16 17 18 19 20 21
+------------
+
+List some tags in a table with unequal column widths:
+------------
+$ git tag --list 'v2.4.*' --column=row,dense
+v2.4.0 v2.4.0-rc0 v2.4.0-rc1 v2.4.0-rc2 v2.4.0-rc3
+v2.4.1 v2.4.10 v2.4.11 v2.4.12 v2.4.2
+v2.4.3 v2.4.4 v2.4.5 v2.4.6 v2.4.7
+v2.4.8 v2.4.9
+------------
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/column.adoc[]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-commit-graph.adoc b/git-commit-graph.adoc
new file mode 100644
index 0000000..50b5016
--- /dev/null
+++ b/git-commit-graph.adoc
@@ -0,0 +1,163 @@
+git-commit-graph(1)
+===================
+
+NAME
+----
+git-commit-graph - Write and verify Git commit-graph files
+
+
+SYNOPSIS
+--------
+[verse]
+'git commit-graph verify' [--object-dir <dir>] [--shallow] [--[no-]progress]
+'git commit-graph write' [--object-dir <dir>] [--append]
+ [--split[=<strategy>]] [--reachable | --stdin-packs | --stdin-commits]
+ [--changed-paths] [--[no-]max-new-filters <n>] [--[no-]progress]
+ <split-options>
+
+
+DESCRIPTION
+-----------
+
+Manage the serialized commit-graph file.
+
+
+OPTIONS
+-------
+--object-dir::
+ Use given directory for the location of packfiles and commit-graph
+ file. This parameter exists to specify the location of an alternate
+ that only has the objects directory, not a full `.git` directory. The
+ commit-graph file is expected to be in the `<dir>/info` directory and
+ the packfiles are expected to be in `<dir>/pack`. If the directory
+ could not be made into an absolute path, or does not match any known
+ object directory, `git commit-graph ...` will exit with non-zero
+ status.
+
+--[no-]progress::
+ Turn progress on/off explicitly. If neither is specified, progress is
+ shown if standard error is connected to a terminal.
+
+COMMANDS
+--------
+'write'::
+
+Write a commit-graph file based on the commits found in packfiles. If
+the config option `core.commitGraph` is disabled, then this command will
+output a warning, then return success without writing a commit-graph file.
++
+With the `--stdin-packs` option, generate the new commit graph by
+walking objects only in the specified pack-indexes. (Cannot be combined
+with `--stdin-commits` or `--reachable`.)
++
+With the `--stdin-commits` option, generate the new commit graph by
+walking commits starting at the commits specified in stdin as a list
+of OIDs in hex, one OID per line. OIDs that resolve to non-commits
+(either directly, or by peeling tags) are silently ignored. OIDs that
+are malformed, or do not exist generate an error. (Cannot be combined
+with `--stdin-packs` or `--reachable`.)
++
+With the `--reachable` option, generate the new commit graph by walking
+commits starting at all refs. (Cannot be combined with `--stdin-commits`
+or `--stdin-packs`.)
++
+With the `--append` option, include all commits that are present in the
+existing commit-graph file.
++
+With the `--changed-paths` option, compute and write information about the
+paths changed between a commit and its first parent. This operation can
+take a while on large repositories. It provides significant performance gains
+for getting history of a directory or a file with `git log -- <path>`. If
+this option is given, future commit-graph writes will automatically assume
+that this option was intended. Use `--no-changed-paths` to stop storing this
+data.
++
+With the `--max-new-filters=<n>` option, generate at most `n` new Bloom
+filters (if `--changed-paths` is specified). If `n` is `-1`, no limit is
+enforced. Only commits present in the new layer count against this
+limit. To retroactively compute Bloom filters over earlier layers, it is
+advised to use `--split=replace`. Overrides the `commitGraph.maxNewFilters`
+configuration.
++
+With the `--split[=<strategy>]` option, write the commit-graph as a
+chain of multiple commit-graph files stored in
+`<dir>/info/commit-graphs`. Commit-graph layers are merged based on the
+strategy and other splitting options. The new commits not already in the
+commit-graph are added in a new "tip" file. This file is merged with the
+existing file if the following merge conditions are met:
++
+* If `--split=no-merge` is specified, a merge is never performed, and
+the remaining options are ignored. `--split=replace` overwrites the
+existing chain with a new one. A bare `--split` defers to the remaining
+options. (Note that merging a chain of commit graphs replaces the
+existing chain with a length-1 chain where the first and only
+incremental holds the entire graph).
++
+* If `--size-multiple=<X>` is not specified, let `X` equal 2. If the new
+tip file would have `N` commits and the previous tip has `M` commits and
+`X` times `N` is greater than `M`, instead merge the two files into a
+single file.
++
+* If `--max-commits=<M>` is specified with `M` a positive integer, and the
+new tip file would have more than `M` commits, then instead merge the new
+tip with the previous tip.
++
+Finally, if `--expire-time=<datetime>` is not specified, let `datetime`
+be the current time. After writing the split commit-graph, delete all
+unused commit-graph whose modified times are older than `datetime`.
+
+'verify'::
+
+Read the commit-graph file and verify its contents against the object
+database. Used to check for corrupted data.
++
+With the `--shallow` option, only check the tip commit-graph file in
+a chain of split commit-graphs.
+
+
+EXAMPLES
+--------
+
+* Write a commit-graph file for the packed commits in your local `.git`
+ directory.
++
+------------------------------------------------
+$ git commit-graph write
+------------------------------------------------
+
+* Write a commit-graph file, extending the current commit-graph file
+ using commits in `<pack-index>`.
++
+------------------------------------------------
+$ echo <pack-index> | git commit-graph write --stdin-packs
+------------------------------------------------
+
+* Write a commit-graph file containing all reachable commits.
++
+------------------------------------------------
+$ git show-ref -s | git commit-graph write --stdin-commits
+------------------------------------------------
+
+* Write a commit-graph file containing all commits in the current
+ commit-graph file along with those reachable from `HEAD`.
++
+------------------------------------------------
+$ git rev-parse HEAD | git commit-graph write --stdin-commits --append
+------------------------------------------------
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/commitgraph.adoc[]
+
+
+FILE FORMAT
+-----------
+
+see linkgit:gitformat-commit-graph[5].
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-commit-tree.adoc b/git-commit-tree.adoc
new file mode 100644
index 0000000..6472921
--- /dev/null
+++ b/git-commit-tree.adoc
@@ -0,0 +1,101 @@
+git-commit-tree(1)
+==================
+
+NAME
+----
+git-commit-tree - Create a new commit object
+
+
+SYNOPSIS
+--------
+[verse]
+'git commit-tree' <tree> [(-p <parent>)...]
+'git commit-tree' [(-p <parent>)...] [-S[<keyid>]] [(-m <message>)...]
+ [(-F <file>)...] <tree>
+
+
+DESCRIPTION
+-----------
+This is usually not what an end user wants to run directly. See
+linkgit:git-commit[1] instead.
+
+Creates a new commit object based on the provided tree object and
+emits the new commit object id on stdout. The log message is read
+from the standard input, unless `-m` or `-F` options are given.
+
+The `-m` and `-F` options can be given any number of times, in any
+order. The commit log message will be composed in the order in which
+the options are given.
+
+A commit object may have any number of parents. With exactly one
+parent, it is an ordinary commit. Having more than one parent makes
+the commit a merge between several lines of history. Initial (root)
+commits have no parents.
+
+While a tree represents a particular directory state of a working
+directory, a commit represents that state in "time", and explains how
+to get there.
+
+Normally a commit would identify 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 that is pointed at by
+`.git/HEAD`, so that we can always see what the last committed
+state was.
+
+OPTIONS
+-------
+<tree>::
+ An existing tree object.
+
+-p <parent>::
+ Each `-p` indicates the id of a parent commit object.
+
+-m <message>::
+ A paragraph in the commit log message. This can be given more than
+ once and each <message> becomes its own paragraph.
+
+-F <file>::
+ Read the commit log message from the given file. Use `-` to read
+ from the standard input. This can be given more than once and the
+ content of each file becomes its own paragraph.
+
+-S[<keyid>]::
+--gpg-sign[=<keyid>]::
+--no-gpg-sign::
+ GPG-sign commits. The `keyid` argument is optional and
+ defaults to the committer identity; if specified, it must be
+ stuck to the option without a space. `--no-gpg-sign` is useful to
+ countermand a `--gpg-sign` option given earlier on the command line.
+
+Commit Information
+------------------
+
+A commit encapsulates:
+
+- all parent object ids
+- author name, email and date
+- committer name and email and the commit time.
+
+A commit comment is read from stdin. If a changelog
+entry is not provided via "<" redirection, 'git commit-tree' will just wait
+for one to be entered and terminated with ^D.
+
+include::date-formats.adoc[]
+
+Discussion
+----------
+
+include::i18n.adoc[]
+
+FILES
+-----
+/etc/mailname
+
+SEE ALSO
+--------
+linkgit:git-write-tree[1]
+linkgit:git-commit[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-commit.adoc b/git-commit.adoc
new file mode 100644
index 0000000..dfb7816
--- /dev/null
+++ b/git-commit.adoc
@@ -0,0 +1,589 @@
+git-commit(1)
+=============
+
+NAME
+----
+git-commit - Record changes to the repository
+
+SYNOPSIS
+--------
+[synopsis]
+git commit [-a | --interactive | --patch] [-s] [-v] [-u[<mode>]] [--amend]
+ [--dry-run] [(-c | -C | --squash) <commit> | --fixup [(amend|reword):]<commit>]
+ [-F <file> | -m <msg>] [--reset-author] [--allow-empty]
+ [--allow-empty-message] [--no-verify] [-e] [--author=<author>]
+ [--date=<date>] [--cleanup=<mode>] [--[no-]status]
+ [-i | -o] [--pathspec-from-file=<file> [--pathspec-file-nul]]
+ [(--trailer <token>[(=|:)<value>])...] [-S[<keyid>]]
+ [--] [<pathspec>...]
+
+DESCRIPTION
+-----------
+Create a new commit containing the current contents of the index and
+the given log message describing the changes. The new commit is a
+direct child of HEAD, usually the tip of the current branch, and the
+branch is updated to point to it (unless no branch is associated with
+the working tree, in which case `HEAD` is "detached" as described in
+linkgit:git-checkout[1]).
+
+The content to be committed can be specified in several ways:
+
+1. by using linkgit:git-add[1] to incrementally "add" changes to the
+ index before using the `commit` command (Note: even modified files
+ must be "added");
+
+2. by using linkgit:git-rm[1] to remove files from the working tree
+ and the index, again before using the `commit` command;
+
+3. by listing files as arguments to the `commit` command
+ (without `--interactive` or `--patch` switch), in which
+ case the commit will ignore changes staged in the index, and instead
+ record the current content of the listed files (which must already
+ be known to Git);
+
+4. by using the `-a` switch with the `commit` command to automatically
+ "add" changes from all known files (i.e. all files that are already
+ listed in the index) and to automatically "rm" files in the index
+ that have been removed from the working tree, and then perform the
+ actual commit;
+
+5. by using the `--interactive` or `--patch` switches with the `commit` command
+ to decide one by one which files or hunks should be part of the commit
+ in addition to contents in the index,
+ before finalizing the operation. See the ``Interactive Mode'' section of
+ linkgit:git-add[1] to learn how to operate these modes.
+
+The `--dry-run` option can be used to obtain a
+summary of what is included by any of the above for the next
+commit by giving the same set of parameters (options and paths).
+
+If you make a commit and then find a mistake immediately after
+that, you can recover from it with `git reset`.
+
+:git-commit: 1
+
+OPTIONS
+-------
+`-a`::
+`--all`::
+ Automatically stage files that have
+ been modified and deleted, but new files you have not
+ told Git about are not affected.
+
+`-p`::
+`--patch`::
+ Use the interactive patch selection interface to choose
+ which changes to commit. See linkgit:git-add[1] for
+ details.
+
+`-C <commit>`::
+`--reuse-message=<commit>`::
+ Take an existing _<commit>_ object, and reuse the log message
+ and the authorship information (including the timestamp)
+ when creating the commit.
+
+`-c <commit>`::
+`--reedit-message=<commit>`::
+ Like `-C`, but with `-c` the editor is invoked, so that
+ the user can further edit the commit message.
+
+`--fixup=[(amend|reword):]<commit>`::
+ Create a new commit which "fixes up" _<commit>_ when applied with
+ `git rebase --autosquash`. Plain `--fixup=<commit>` creates a
+ "fixup!" commit which changes the content of _<commit>_ but leaves
+ its log message untouched. `--fixup=amend:<commit>` is similar but
+ creates an "amend!" commit which also replaces the log message of
+ _<commit>_ with the log message of the "amend!" commit.
+ `--fixup=reword:<commit>` creates an "amend!" commit which
+ replaces the log message of _<commit>_ with its own log message
+ but makes no changes to the content of _<commit>_.
++
+The commit created by plain `--fixup=<commit>` has a subject
+composed of "fixup!" followed by the subject line from _<commit>_,
+and is recognized specially by `git rebase --autosquash`. The `-m`
+option may be used to supplement the log message of the created
+commit, but the additional commentary will be thrown away once the
+"fixup!" commit is squashed into _<commit>_ by
+`git rebase --autosquash`.
++
+The commit created by `--fixup=amend:<commit>` is similar but its
+subject is instead prefixed with "amend!". The log message of
+_<commit>_ is copied into the log message of the "amend!" commit and
+opened in an editor so it can be refined. When `git rebase
+--autosquash` squashes the "amend!" commit into _<commit>_, the
+log message of _<commit>_ is replaced by the refined log message
+from the "amend!" commit. It is an error for the "amend!" commit's
+log message to be empty unless `--allow-empty-message` is
+specified.
++
+`--fixup=reword:<commit>` is shorthand for `--fixup=amend:<commit>
+ --only`. It creates an "amend!" commit with only a log message
+(ignoring any changes staged in the index). When squashed by `git
+rebase --autosquash`, it replaces the log message of _<commit>_
+without making any other changes.
++
+Neither "fixup!" nor "amend!" commits change authorship of
+_<commit>_ when applied by `git rebase --autosquash`.
+See linkgit:git-rebase[1] for details.
+
+`--squash=<commit>`::
+ Construct a commit message for use with `git rebase --autosquash`.
+ The commit message subject line is taken from the specified
+ commit with a prefix of "squash! ". Can be used with additional
+ commit message options (`-m`/`-c`/`-C`/`-F`). See
+ linkgit:git-rebase[1] for details.
+
+`--reset-author`::
+ When used with `-C`/`-c`/`--amend` options, or when committing after a
+ conflicting cherry-pick, declare that the authorship of the
+ resulting commit now belongs to the committer. This also renews
+ the author timestamp.
+
+`--short`::
+ When doing a dry-run, give the output in the short-format. See
+ linkgit:git-status[1] for details. Implies `--dry-run`.
+
+`--branch`::
+ Show the branch and tracking info even in short-format.
+
+`--porcelain`::
+ When doing a dry-run, give the output in a porcelain-ready
+ format. See linkgit:git-status[1] for details. Implies
+ `--dry-run`.
+
+`--long`::
+ When doing a dry-run, give the output in the long-format.
+ Implies `--dry-run`.
+
+`-z`::
+`--null`::
+ When showing `short` or `porcelain` status output, print the
+ filename verbatim and terminate the entries with _NUL_, instead of _LF_.
+ If no format is given, implies the `--porcelain` output format.
+ Without the `-z` option, filenames with "unusual" characters are
+ quoted as explained for the configuration variable `core.quotePath`
+ (see linkgit:git-config[1]).
+
+`-F <file>`::
+`--file=<file>`::
+ Take the commit message from _<file>_. Use '-' to
+ read the message from the standard input.
+
+`--author=<author>`::
+ Override the commit author. Specify an explicit author using the
+ standard `A U Thor <author@example.com>` format. Otherwise _<author>_
+ is assumed to be a pattern and is used to search for an existing
+ commit by that author (i.e. `git rev-list --all -i --author=<author>`);
+ the commit author is then copied from the first such commit found.
+
+`--date=<date>`::
+ Override the author date used in the commit.
+
+`-m <msg>`::
+`--message=<msg>`::
+ Use _<msg>_ as the commit message.
+ If multiple `-m` options are given, their values are
+ concatenated as separate paragraphs.
++
+The `-m` option is mutually exclusive with `-c`, `-C`, and `-F`.
+
+`-t <file>`::
+`--template=<file>`::
+ When editing the commit message, start the editor with the
+ contents in _<file>_. The `commit.template` configuration
+ variable is often used to give this option implicitly to the
+ command. This mechanism can be used by projects that want to
+ guide participants with some hints on what to write in the message
+ in what order. If the user exits the editor without editing the
+ message, the commit is aborted. This has no effect when a message
+ is given by other means, e.g. with the `-m` or `-F` options.
+
+include::signoff-option.adoc[]
+
+`--trailer <token>[(=|:)<value>]`::
+ Specify a (_<token>_, _<value>_) pair that should be applied as a
+ trailer. (e.g. `git commit --trailer "Signed-off-by:C O Mitter \
+ <committer@example.com>" --trailer "Helped-by:C O Mitter \
+ <committer@example.com>"` will add the `Signed-off-by` trailer
+ and the `Helped-by` trailer to the commit message.)
+ The `trailer.*` configuration variables
+ (linkgit:git-interpret-trailers[1]) can be used to define if
+ a duplicated trailer is omitted, where in the run of trailers
+ each trailer would appear, and other details.
+
+`-n`::
+`--[no-]verify`::
+ Bypass the `pre-commit` and `commit-msg` hooks.
+ See also linkgit:githooks[5].
+
+`--allow-empty`::
+ Usually recording a commit that has the exact same tree as its
+ sole parent commit is a mistake, and the command prevents you
+ from making such a commit. This option bypasses the safety, and
+ is primarily for use by foreign SCM interface scripts.
+
+`--allow-empty-message`::
+ Create a commit with an empty commit message without using plumbing
+ commands like linkgit:git-commit-tree[1]. Like `--allow-empty`, this
+ command is primarily for use by foreign SCM interface scripts.
+
+`--cleanup=<mode>`::
+ Determine how the supplied commit message should be
+ cleaned up before committing. The '<mode>' can be `strip`,
+ `whitespace`, `verbatim`, `scissors` or `default`.
++
+--
+`strip`::
+ Strip leading and trailing empty lines, trailing whitespace,
+ commentary and collapse consecutive empty lines.
+`whitespace`::
+ Same as `strip` except #commentary is not removed.
+`verbatim`::
+ Do not change the message at all.
+`scissors`::
+ Same as `whitespace` except that everything from (and including)
+ the line found below is truncated, if the message is to be edited.
+ "`#`" can be customized with `core.commentChar`.
+
+ # ------------------------ >8 ------------------------
+
+`default`::
+ Same as `strip` if the message is to be edited.
+ Otherwise `whitespace`.
+--
++
+The default can be changed by the `commit.cleanup` configuration
+variable (see linkgit:git-config[1]).
+
+`-e`::
+`--edit`::
+ Let the user further edit the message taken from _<file>_
+ with `-F <file>`, command line with `-m <message>`, and
+ from _<commit>_ with `-C <commit>`.
+
+`--no-edit`::
+ Use the selected commit message without launching an editor.
+ For example, `git commit --amend --no-edit` amends a commit
+ without changing its commit message.
+
+`--amend`::
+ Replace the tip of the current branch by creating a new
+ commit. The recorded tree is prepared as usual (including
+ the effect of the `-i` and `-o` options and explicit
+ pathspec), and the message from the original commit is used
+ as the starting point, instead of an empty message, when no
+ other message is specified from the command line via options
+ such as `-m`, `-F`, `-c`, etc. The new commit has the same
+ parents and author as the current one (the `--reset-author`
+ option can countermand this).
++
+--
+It is a rough equivalent for:
+------
+ $ git reset --soft HEAD^
+ $ ... do something else to come up with the right tree ...
+ $ git commit -c ORIG_HEAD
+
+------
+but can be used to amend a merge commit.
+--
++
+You should understand the implications of rewriting history if you
+amend a commit that has already been published. (See the "RECOVERING
+FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
+
+`--no-post-rewrite`::
+ Bypass the `post-rewrite` hook.
+
+`-i`::
+`--include`::
+ Before making a commit out of staged contents so far,
+ stage the contents of paths given on the command line
+ as well. This is usually not what you want unless you
+ are concluding a conflicted merge.
+
+`-o`::
+`--only`::
+ Make a commit by taking the updated working tree contents
+ of the paths specified on the
+ command line, disregarding any contents that have been
+ staged for other paths. This is the default mode of operation of
+ `git commit` if any paths are given on the command line,
+ in which case this option can be omitted.
+ If this option is specified together with `--amend`, then
+ no paths need to be specified, which can be used to amend
+ the last commit without committing changes that have
+ already been staged. If used together with `--allow-empty`
+ paths are also not required, and an empty commit will be created.
+
+`--pathspec-from-file=<file>`::
+ Pass pathspec in _<file>_ instead of commandline args. If
+ _<file>_ is exactly `-` then standard input is used. Pathspec
+ elements are separated by _LF_ or _CR_/_LF_. Pathspec elements can be
+ quoted as explained for the configuration variable `core.quotePath`
+ (see linkgit:git-config[1]). See also `--pathspec-file-nul` and
+ global `--literal-pathspecs`.
+
+`--pathspec-file-nul`::
+ Only meaningful with `--pathspec-from-file`. Pathspec elements are
+ separated with _NUL_ character and all other characters are taken
+ literally (including newlines and quotes).
+
+`-u[<mode>]`::
+`--untracked-files[=<mode>]`::
+ Show untracked files.
++
+--
+The _<mode>_ parameter is optional (defaults to `all`), and is used to
+specify the handling of untracked files; when `-u` is not used, the
+default is `normal`, i.e. show untracked files and directories.
+
+The possible options are:
+
+`no`:: Show no untracked files
+`normal`:: Shows untracked files and directories
+`all`:: Also shows individual files in untracked directories.
+
+All usual spellings for Boolean value `true` are taken as `normal`
+and `false` as `no`.
+The default can be changed using the `status.showUntrackedFiles`
+configuration variable documented in linkgit:git-config[1].
+--
+
+`-v`::
+`--verbose`::
+ Show unified diff between the `HEAD` commit and what
+ would be committed at the bottom of the commit message
+ template to help the user describe the commit by reminding
+ what changes the commit has.
+ Note that this diff output doesn't have its
+ lines prefixed with `#`. This diff will not be a part
+ of the commit message. See the `commit.verbose` configuration
+ variable in linkgit:git-config[1].
++
+If specified twice, show in addition the unified diff between
+what would be committed and the worktree files, i.e. the unstaged
+changes to tracked files.
+
+`-q`::
+`--quiet`::
+ Suppress commit summary message.
+
+`--dry-run`::
+ Do not create a commit, but show a list of paths that are
+ to be committed, paths with local changes that will be left
+ uncommitted and paths that are untracked.
+
+`--status`::
+ Include the output of linkgit:git-status[1] in the commit
+ message template when using an editor to prepare the commit
+ message. Defaults to on, but can be used to override
+ configuration variable `commit.status`.
+
+`--no-status`::
+ Do not include the output of linkgit:git-status[1] in the
+ commit message template when using an editor to prepare the
+ default commit message.
+
+`-S[<key-id>]`::
+`--gpg-sign[=<key-id>]`::
+`--no-gpg-sign`::
+ GPG-sign commits. The _<key-id>_ is optional and
+ defaults to the committer identity; if specified, it must be
+ stuck to the option without a space. `--no-gpg-sign` is useful to
+ countermand both `commit.gpgSign` configuration variable, and
+ earlier `--gpg-sign`.
+
+`--`::
+ Do not interpret any more arguments as options.
+
+`<pathspec>...`::
+ When _<pathspec>_ is given on the command line, commit the contents of
+ the files that match the pathspec without recording the changes
+ already added to the index. The contents of these files are also
+ staged for the next commit on top of what have been staged before.
++
+For more details, see the 'pathspec' entry in linkgit:gitglossary[7].
+
+EXAMPLES
+--------
+When recording your own work, the contents of modified files in
+your working tree are temporarily stored to a staging area
+called the "index" with `git add`. A file can be
+reverted back, only in the index but not in the working tree,
+to that of the last commit with `git restore --staged <file>`,
+which effectively reverts `git add` and prevents the changes to
+this file from participating in the next commit. After building
+the state to be committed incrementally with these commands,
+`git commit` (without any pathname parameter) is used to record what
+has been staged so far. This is the most basic form of the
+command. An example:
+
+------------
+$ edit hello.c
+$ git rm goodbye.c
+$ git add hello.c
+$ git commit
+------------
+
+Instead of staging files after each individual change, you can
+tell `git commit` to notice the changes to the files whose
+contents are tracked in
+your working tree and do corresponding `git add` and `git rm`
+for you. That is, this example does the same as the earlier
+example if there is no other change in your working tree:
+
+------------
+$ edit hello.c
+$ rm goodbye.c
+$ git commit -a
+------------
+
+The command `git commit -a` first looks at your working tree,
+notices that you have modified `hello.c` and removed `goodbye.c`,
+and performs necessary `git add` and `git rm` for you.
+
+After staging changes to many files, you can alter the order the
+changes are recorded in, by giving pathnames to `git commit`.
+When pathnames are given, the command makes a commit that
+only records the changes made to the named paths:
+
+------------
+$ edit hello.c hello.h
+$ git add hello.c hello.h
+$ edit Makefile
+$ git commit Makefile
+------------
+
+This makes a commit that records the modification to `Makefile`.
+The changes staged for `hello.c` and `hello.h` are not included
+in the resulting commit. However, their changes are not lost --
+they are still staged and merely held back. After the above
+sequence, if you do:
+
+------------
+$ git commit
+------------
+
+this second commit would record the changes to `hello.c` and
+`hello.h` as expected.
+
+After a merge (initiated by `git merge` or `git pull`) stops
+because of conflicts, cleanly merged
+paths are already staged to be committed for you, and paths that
+conflicted are left in unmerged state. You would have to first
+check which paths are conflicting with `git status`
+and after fixing them manually in your working tree, you would
+stage the result as usual with `git add`:
+
+------------
+$ git status | grep unmerged
+unmerged: hello.c
+$ edit hello.c
+$ git add hello.c
+------------
+
+After resolving conflicts and staging the result, `git ls-files -u`
+would stop mentioning the conflicted path. When you are done,
+run `git commit` to finally record the merge:
+
+------------
+$ git commit
+------------
+
+As with the case to record your own changes, you can use `-a`
+option to save typing. One difference is that during a merge
+resolution, you cannot use `git commit` with pathnames to
+alter the order the changes are committed, because the merge
+should be recorded as a single commit. In fact, the command
+refuses to run when given pathnames (but see `-i` option).
+
+COMMIT INFORMATION
+------------------
+
+Author and committer information is taken from the following environment
+variables, if set:
+
+ * `GIT_AUTHOR_NAME`
+ * `GIT_AUTHOR_EMAIL`
+ * `GIT_AUTHOR_DATE`
+ * `GIT_COMMITTER_NAME`
+ * `GIT_COMMITTER_EMAIL`
+ * `GIT_COMMITTER_DATE`
+
+(nb "<", ">" and "\n"s are stripped)
+
+The author and committer names are by convention some form of a personal name
+(that is, the name by which other humans refer to you), although Git does not
+enforce or require any particular form. Arbitrary Unicode may be used, subject
+to the constraints listed above. This name has no effect on authentication; for
+that, see the `credential.username` variable in linkgit:git-config[1].
+
+In case (some of) these environment variables are not set, the information
+is taken from the configuration items `user.name` and `user.email`, or, if not
+present, the environment variable `EMAIL`, or, if that is not set,
+system user name and the hostname used for outgoing mail (taken
+from `/etc/mailname` and falling back to the fully qualified hostname when
+that file does not exist).
+
+The `author.name` and `committer.name` and their corresponding email options
+override `user.name` and `user.email` if set and are overridden themselves by
+the environment variables.
+
+The typical usage is to set just the `user.name` and `user.email` variables;
+the other options are provided for more complex use cases.
+
+:git-commit: 1
+include::date-formats.adoc[]
+
+DISCUSSION
+----------
+
+Though not required, it's a good idea to begin the commit message
+with a single short (no more than 50 characters) line summarizing the
+change, followed by a blank line and then a more thorough description.
+The text up to the first blank line in a commit message is treated
+as the commit title, and that title is used throughout Git.
+For example, linkgit:git-format-patch[1] turns a commit into email, and it uses
+the title on the Subject line and the rest of the commit in the body.
+
+include::i18n.adoc[]
+
+ENVIRONMENT AND CONFIGURATION VARIABLES
+---------------------------------------
+The editor used to edit the commit log message will be chosen from the
+`GIT_EDITOR` environment variable, the `core.editor` configuration variable, the
+`VISUAL` environment variable, or the `EDITOR` environment variable (in that
+order). See linkgit:git-var[1] for details.
+
+include::includes/cmd-config-section-rest.adoc[]
+
+include::config/commit.adoc[]
+
+HOOKS
+-----
+This command can run `commit-msg`, `prepare-commit-msg`, `pre-commit`,
+`post-commit` and `post-rewrite` hooks. See linkgit:githooks[5] for more
+information.
+
+FILES
+-----
+
+`$GIT_DIR/COMMIT_EDITMSG`::
+ This file contains the commit message of a commit in progress.
+ If `git commit` exits due to an error before creating a commit,
+ any commit message that has been provided by the user (e.g., in
+ an editor session) will be available in this file, but will be
+ overwritten by the next invocation of `git commit`.
+
+SEE ALSO
+--------
+linkgit:git-add[1],
+linkgit:git-rm[1],
+linkgit:git-mv[1],
+linkgit:git-merge[1],
+linkgit:git-commit-tree[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-config.adoc b/git-config.adoc
new file mode 100644
index 0000000..888f8ba
--- /dev/null
+++ b/git-config.adoc
@@ -0,0 +1,638 @@
+git-config(1)
+=============
+
+NAME
+----
+git-config - Get and set repository or global options
+
+
+SYNOPSIS
+--------
+[verse]
+'git config list' [<file-option>] [<display-option>] [--includes]
+'git config get' [<file-option>] [<display-option>] [--includes] [--all] [--regexp] [--value=<value>] [--fixed-value] [--default=<default>] <name>
+'git config set' [<file-option>] [--type=<type>] [--all] [--value=<value>] [--fixed-value] <name> <value>
+'git config unset' [<file-option>] [--all] [--value=<value>] [--fixed-value] <name>
+'git config rename-section' [<file-option>] <old-name> <new-name>
+'git config remove-section' [<file-option>] <name>
+'git config edit' [<file-option>]
+'git config' [<file-option>] --get-colorbool <name> [<stdout-is-tty>]
+
+DESCRIPTION
+-----------
+You can query/set/replace/unset options with this command. The name is
+actually the section and the key separated by a dot, and the value will be
+escaped.
+
+Multiple lines can be added to an option by using the `--append` option.
+If you want to update or unset an option which can occur on multiple
+lines, a `value-pattern` (which is an extended regular expression,
+unless the `--fixed-value` option is given) needs to be given. Only the
+existing values that match the pattern are updated or unset. If
+you want to handle the lines that do *not* match the pattern, just
+prepend a single exclamation mark in front (see also <<EXAMPLES>>),
+but note that this only works when the `--fixed-value` option is not
+in use.
+
+The `--type=<type>` option instructs 'git config' to ensure that incoming and
+outgoing values are canonicalize-able under the given <type>. If no
+`--type=<type>` is given, no canonicalization will be performed. Callers may
+unset an existing `--type` specifier with `--no-type`.
+
+When reading, the values are read from the system, global and
+repository local configuration files by default, and options
+`--system`, `--global`, `--local`, `--worktree` and
+`--file <filename>` can be used to tell the command to read from only
+that location (see <<FILES>>).
+
+When writing, the new value is written to the repository local
+configuration file by default, and options `--system`, `--global`,
+`--worktree`, `--file <filename>` can be used to tell the command to
+write to that location (you can say `--local` but that is the
+default).
+
+This command will fail with non-zero status upon error. Some exit
+codes are:
+
+- The section or key is invalid (ret=1),
+- no section or name was provided (ret=2),
+- the config file is invalid (ret=3),
+- the config file cannot be written (ret=4),
+- you try to unset an option which does not exist (ret=5),
+- you try to unset/set an option for which multiple lines match (ret=5), or
+- you try to use an invalid regexp (ret=6).
+
+On success, the command returns the exit code 0.
+
+A list of all available configuration variables can be obtained using the
+`git help --config` command.
+
+COMMANDS
+--------
+
+list::
+ List all variables set in config file, along with their values.
+
+get::
+ Emits the value of the specified key. If key is present multiple times
+ in the configuration, emits the last value. If `--all` is specified,
+ emits all values associated with key. Returns error code 1 if key is
+ not present.
+
+set::
+ Set value for one or more config options. By default, this command
+ refuses to write multi-valued config options. Passing `--all` will
+ replace all multi-valued config options with the new value, whereas
+ `--value=` will replace all config options whose values match the given
+ pattern.
+
+unset::
+ Unset value for one or more config options. By default, this command
+ refuses to unset multi-valued keys. Passing `--all` will unset all
+ multi-valued config options, whereas `--value` will unset all config
+ options whose values match the given pattern.
+
+rename-section::
+ Rename the given section to a new name.
+
+remove-section::
+ Remove the given section from the configuration file.
+
+edit::
+ Opens an editor to modify the specified config file; either
+ `--system`, `--global`, `--local` (default), `--worktree`, or
+ `--file <config-file>`.
+
+[[OPTIONS]]
+OPTIONS
+-------
+
+--replace-all::
+ Default behavior is to replace at most one line. This replaces
+ all lines matching the key (and optionally the `value-pattern`).
+
+--append::
+ Adds a new line to the option without altering any existing
+ values. This is the same as providing '--value=^$' in `set`.
+
+--comment <message>::
+ Append a comment at the end of new or modified lines.
+
+ If _<message>_ begins with one or more whitespaces followed
+ by "#", it is used as-is. If it begins with "#", a space is
+ prepended before it is used. Otherwise, a string " # " (a
+ space followed by a hash followed by a space) is prepended
+ to it. And the resulting string is placed immediately after
+ the value defined for the variable. The _<message>_ must
+ not contain linefeed characters (no multi-line comments are
+ permitted).
+
+--all::
+ With `get`, return all values for a multi-valued key.
+
+--regexp::
+ With `get`, interpret the name as a regular expression. Regular
+ expression matching is currently case-sensitive and done against a
+ canonicalized version of the key in which section and variable names
+ are lowercased, but subsection names are not.
+
+--url=<URL>::
+ When given a two-part <name> as <section>.<key>, the value for
+ <section>.<URL>.<key> whose <URL> part matches the best to the
+ given URL is returned (if no such key exists, the value for
+ <section>.<key> is used as a fallback). When given just the
+ <section> as name, do so for all the keys in the section and
+ list them. Returns error code 1 if no value is found.
+
+--global::
+ For writing options: write to global `~/.gitconfig` file
+ rather than the repository `.git/config`, write to
+ `$XDG_CONFIG_HOME/git/config` file if this file exists and the
+ `~/.gitconfig` file doesn't.
++
+For reading options: read only from global `~/.gitconfig` and from
+`$XDG_CONFIG_HOME/git/config` rather than from all available files.
++
+See also <<FILES>>.
+
+--system::
+ For writing options: write to system-wide
+ `$(prefix)/etc/gitconfig` rather than the repository
+ `.git/config`.
++
+For reading options: read only from system-wide `$(prefix)/etc/gitconfig`
+rather than from all available files.
++
+See also <<FILES>>.
+
+--local::
+ For writing options: write to the repository `.git/config` file.
+ This is the default behavior.
++
+For reading options: read only from the repository `.git/config` rather than
+from all available files.
++
+See also <<FILES>>.
+
+--worktree::
+ Similar to `--local` except that `$GIT_DIR/config.worktree` is
+ read from or written to if `extensions.worktreeConfig` is
+ enabled. If not it's the same as `--local`. Note that `$GIT_DIR`
+ is equal to `$GIT_COMMON_DIR` for the main working tree, but is of
+ the form `$GIT_DIR/worktrees/<id>/` for other working trees. See
+ linkgit:git-worktree[1] to learn how to enable
+ `extensions.worktreeConfig`.
+
+-f <config-file>::
+--file <config-file>::
+ For writing options: write to the specified file rather than the
+ repository `.git/config`.
++
+For reading options: read only from the specified file rather than from all
+available files.
++
+See also <<FILES>>.
+
+--blob <blob>::
+ Similar to `--file` but use the given blob instead of a file. E.g.
+ you can use 'master:.gitmodules' to read values from the file
+ '.gitmodules' in the master branch. See "SPECIFYING REVISIONS"
+ section in linkgit:gitrevisions[7] for a more complete list of
+ ways to spell blob names.
+
+--fixed-value::
+ When used with the `value-pattern` argument, treat `value-pattern` as
+ an exact string instead of a regular expression. This will restrict
+ the name/value pairs that are matched to only those where the value
+ is exactly equal to the `value-pattern`.
+
+--type <type>::
+ 'git config' will ensure that any input or output is valid under the given
+ type constraint(s), and will canonicalize outgoing values in `<type>`'s
+ canonical form.
++
+Valid `<type>`'s include:
++
+- 'bool': canonicalize values as either "true" or "false".
+- 'int': canonicalize values as simple decimal numbers. An optional suffix of
+ 'k', 'm', or 'g' will cause the value to be multiplied by 1024, 1048576, or
+ 1073741824 upon input.
+- 'bool-or-int': canonicalize according to either 'bool' or 'int', as described
+ above.
+- 'path': canonicalize by expanding a leading `~` to the value of `$HOME` and
+ `~user` to the home directory for the specified user. This specifier has no
+ effect when setting the value (but you can use `git config section.variable
+ ~/` from the command line to let your shell do the expansion.)
+- 'expiry-date': canonicalize by converting from a fixed or relative date-string
+ to a timestamp. This specifier has no effect when setting the value.
+- 'color': When getting a value, canonicalize by converting to an ANSI color
+ escape sequence. When setting a value, a sanity-check is performed to ensure
+ that the given value is canonicalize-able as an ANSI color, but it is written
+ as-is.
++
+
+--bool::
+--int::
+--bool-or-int::
+--path::
+--expiry-date::
+ Historical options for selecting a type specifier. Prefer instead `--type`
+ (see above).
+
+--no-type::
+ Un-sets the previously set type specifier (if one was previously set). This
+ option requests that 'git config' not canonicalize the retrieved variable.
+ `--no-type` has no effect without `--type=<type>` or `--<type>`.
+
+-z::
+--null::
+ For all options that output values and/or keys, always
+ end values with the null character (instead of a
+ newline). Use newline instead as a delimiter between
+ key and value. This allows for secure parsing of the
+ output without getting confused e.g. by values that
+ contain line breaks.
+
+--name-only::
+ Output only the names of config variables for `list` or
+ `get`.
+
+--show-origin::
+ Augment the output of all queried config options with the
+ origin type (file, standard input, blob, command line) and
+ the actual origin (config file path, ref, or blob id if
+ applicable).
+
+--show-scope::
+ Similar to `--show-origin` in that it augments the output of
+ all queried config options with the scope of that value
+ (worktree, local, global, system, command).
+
+--get-colorbool <name> [<stdout-is-tty>]::
+
+ Find the color setting for `<name>` (e.g. `color.diff`) and output
+ "true" or "false". `<stdout-is-tty>` should be either "true" or
+ "false", and is taken into account when configuration says
+ "auto". If `<stdout-is-tty>` is missing, then checks the standard
+ output of the command itself, and exits with status 0 if color
+ is to be used, or exits with status 1 otherwise.
+ When the color setting for `name` is undefined, the command uses
+ `color.ui` as fallback.
+
+--[no-]includes::
+ Respect `include.*` directives in config files when looking up
+ values. Defaults to `off` when a specific file is given (e.g.,
+ using `--file`, `--global`, etc) and `on` when searching all
+ config files.
+
+--default <value>::
+ When using `get`, and the requested variable is not found, behave as if
+ <value> were the value assigned to that variable.
+
+DEPRECATED MODES
+----------------
+
+The following modes have been deprecated in favor of subcommands. It is
+recommended to migrate to the new syntax.
+
+'git config <name>'::
+ Replaced by `git config get <name>`.
+
+'git config <name> <value> [<value-pattern>]'::
+ Replaced by `git config set [--value=<pattern>] <name> <value>`.
+
+-l::
+--list::
+ Replaced by `git config list`.
+
+--get <name> [<value-pattern>]::
+ Replaced by `git config get [--value=<pattern>] <name>`.
+
+--get-all <name> [<value-pattern>]::
+ Replaced by `git config get [--value=<pattern>] --all <name>`.
+
+--get-regexp <name-regexp>::
+ Replaced by `git config get --all --show-names --regexp <name-regexp>`.
+
+--get-urlmatch <name> <URL>::
+ Replaced by `git config get --all --show-names --url=<URL> <name>`.
+
+--get-color <name> [<default>]::
+ Replaced by `git config get --type=color [--default=<default>] <name>`.
+
+--add <name> <value>::
+ Replaced by `git config set --append <name> <value>`.
+
+--unset <name> [<value-pattern>]::
+ Replaced by `git config unset [--value=<pattern>] <name>`.
+
+--unset-all <name> [<value-pattern>]::
+ Replaced by `git config unset [--value=<pattern>] --all <name>`.
+
+--rename-section <old-name> <new-name>::
+ Replaced by `git config rename-section <old-name> <new-name>`.
+
+--remove-section <name>::
+ Replaced by `git config remove-section <name>`.
+
+-e::
+--edit::
+ Replaced by `git config edit`.
+
+CONFIGURATION
+-------------
+`pager.config` is only respected when listing configuration, i.e., when
+using `list` or `get` which may return multiple results. The default is to use
+a pager.
+
+[[FILES]]
+FILES
+-----
+
+By default, 'git config' will read configuration options from multiple
+files:
+
+$(prefix)/etc/gitconfig::
+ System-wide configuration file.
+
+$XDG_CONFIG_HOME/git/config::
+~/.gitconfig::
+ User-specific configuration files. When the XDG_CONFIG_HOME environment
+ variable is not set or empty, $HOME/.config/ is used as
+ $XDG_CONFIG_HOME.
++
+These are also called "global" configuration files. If both files exist, both
+files are read in the order given above.
+
+$GIT_DIR/config::
+ Repository specific configuration file.
+
+$GIT_DIR/config.worktree::
+ This is optional and is only searched when
+ `extensions.worktreeConfig` is present in $GIT_DIR/config.
+
+You may also provide additional configuration parameters when running any
+git command by using the `-c` option. See linkgit:git[1] for details.
+
+Options will be read from all of these files that are available. If the
+global or the system-wide configuration files are missing or unreadable they
+will be ignored. If the repository configuration file is missing or unreadable,
+'git config' will exit with a non-zero error code. An error message is produced
+if the file is unreadable, but not if it is missing.
+
+The files are read in the order given above, with last value found taking
+precedence over values read earlier. When multiple values are taken then all
+values of a key from all files will be used.
+
+By default, options are only written to the repository specific
+configuration file. Note that this also affects options like `set`
+and `unset`. *'git config' will only ever change one file at a time*.
+
+You can limit which configuration sources are read from or written to by
+specifying the path of a file with the `--file` option, or by specifying a
+configuration scope with `--system`, `--global`, `--local`, or `--worktree`.
+For more, see <<OPTIONS>> above.
+
+[[SCOPES]]
+SCOPES
+------
+
+Each configuration source falls within a configuration scope. The scopes
+are:
+
+system::
+ $(prefix)/etc/gitconfig
+
+global::
+ $XDG_CONFIG_HOME/git/config
++
+~/.gitconfig
+
+local::
+ $GIT_DIR/config
+
+worktree::
+ $GIT_DIR/config.worktree
+
+command::
+ GIT_CONFIG_{COUNT,KEY,VALUE} environment variables (see <<ENVIRONMENT>>
+ below)
++
+the `-c` option
+
+With the exception of 'command', each scope corresponds to a command line
+option: `--system`, `--global`, `--local`, `--worktree`.
+
+When reading options, specifying a scope will only read options from the
+files within that scope. When writing options, specifying a scope will write
+to the files within that scope (instead of the repository specific
+configuration file). See <<OPTIONS>> above for a complete description.
+
+Most configuration options are respected regardless of the scope it is
+defined in, but some options are only respected in certain scopes. See the
+respective option's documentation for the full details.
+
+Protected configuration
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Protected configuration refers to the 'system', 'global', and 'command' scopes.
+For security reasons, certain options are only respected when they are
+specified in protected configuration, and ignored otherwise.
+
+Git treats these scopes as if they are controlled by the user or a trusted
+administrator. This is because an attacker who controls these scopes can do
+substantial harm without using Git, so it is assumed that the user's environment
+protects these scopes against attackers.
+
+[[ENVIRONMENT]]
+ENVIRONMENT
+-----------
+
+GIT_CONFIG_GLOBAL::
+GIT_CONFIG_SYSTEM::
+ Take the configuration from the given files instead from global or
+ system-level configuration. See linkgit:git[1] for details.
+
+GIT_CONFIG_NOSYSTEM::
+ Whether to skip reading settings from the system-wide
+ $(prefix)/etc/gitconfig file. See linkgit:git[1] for details.
+
+See also <<FILES>>.
+
+GIT_CONFIG_COUNT::
+GIT_CONFIG_KEY_<n>::
+GIT_CONFIG_VALUE_<n>::
+ If GIT_CONFIG_COUNT is set to a positive number, all environment pairs
+ GIT_CONFIG_KEY_<n> and GIT_CONFIG_VALUE_<n> up to that number will be
+ added to the process's runtime configuration. The config pairs are
+ zero-indexed. Any missing key or value is treated as an error. An empty
+ GIT_CONFIG_COUNT is treated the same as GIT_CONFIG_COUNT=0, namely no
+ pairs are processed. These environment variables will override values
+ in configuration files, but will be overridden by any explicit options
+ passed via `git -c`.
++
+This is useful for cases where you want to spawn multiple git commands
+with a common configuration but cannot depend on a configuration file,
+for example when writing scripts.
+
+GIT_CONFIG::
+ If no `--file` option is provided to `git config`, use the file
+ given by `GIT_CONFIG` as if it were provided via `--file`. This
+ variable has no effect on other Git commands, and is mostly for
+ historical compatibility; there is generally no reason to use it
+ instead of the `--file` option.
+
+[[EXAMPLES]]
+EXAMPLES
+--------
+
+Given a .git/config like this:
+
+------------
+#
+# This is the config file, and
+# a '#' or ';' character indicates
+# a comment
+#
+
+; core variables
+[core]
+ ; Don't trust file modes
+ filemode = false
+
+; Our diff algorithm
+[diff]
+ external = /usr/local/bin/diff-wrapper
+ renames = true
+
+; Proxy settings
+[core]
+ gitproxy=proxy-command for kernel.org
+ gitproxy=default-proxy ; for all the rest
+
+; HTTP
+[http]
+ sslVerify
+[http "https://weak.example.com"]
+ sslVerify = false
+ cookieFile = /tmp/cookie.txt
+------------
+
+you can set the filemode to true with
+
+------------
+% git config set core.filemode true
+------------
+
+The hypothetical proxy command entries actually have a postfix to discern
+what URL they apply to. Here is how to change the entry for kernel.org
+to "ssh".
+
+------------
+% git config set --value='for kernel.org$' core.gitproxy '"ssh" for kernel.org'
+------------
+
+This makes sure that only the key/value pair for kernel.org is replaced.
+
+To delete the entry for renames, do
+
+------------
+% git config unset diff.renames
+------------
+
+If you want to delete an entry for a multivar (like core.gitproxy above),
+you have to provide a regex matching the value of exactly one line.
+
+To query the value for a given key, do
+
+------------
+% git config get core.filemode
+------------
+
+or, to query a multivar:
+
+------------
+% git config get --value="for kernel.org$" core.gitproxy
+------------
+
+If you want to know all the values for a multivar, do:
+
+------------
+% git config get --all --show-names core.gitproxy
+------------
+
+If you like to live dangerously, you can replace *all* core.gitproxy by a
+new one with
+
+------------
+% git config set --all core.gitproxy ssh
+------------
+
+However, if you really only want to replace the line for the default proxy,
+i.e. the one without a "for ..." postfix, do something like this:
+
+------------
+% git config set --value='! for ' core.gitproxy ssh
+------------
+
+To actually match only values with an exclamation mark, you have to
+
+------------
+% git config set --value='[!]' section.key value
+------------
+
+To add a new proxy, without altering any of the existing ones, use
+
+------------
+% git config set --append core.gitproxy '"proxy-command" for example.com'
+------------
+
+An example to use customized color from the configuration in your
+script:
+
+------------
+#!/bin/sh
+WS=$(git config get --type=color --default="blue reverse" color.diff.whitespace)
+RESET=$(git config get --type=color --default="reset" "")
+echo "${WS}your whitespace color or blue reverse${RESET}"
+------------
+
+For URLs in `https://weak.example.com`, `http.sslVerify` is set to
+false, while it is set to `true` for all others:
+
+------------
+% git config get --type=bool --url=https://good.example.com http.sslverify
+true
+% git config get --type=bool --url=https://weak.example.com http.sslverify
+false
+% git config get --url=https://weak.example.com http
+http.cookieFile /tmp/cookie.txt
+http.sslverify false
+------------
+
+include::config.adoc[]
+
+BUGS
+----
+When using the deprecated `[section.subsection]` syntax, changing a value
+will result in adding a multi-line key instead of a change, if the subsection
+is given with at least one uppercase character. For example when the config
+looks like
+
+--------
+ [section.subsection]
+ key = value1
+--------
+
+and running `git config section.Subsection.key value2` will result in
+
+--------
+ [section.subsection]
+ key = value1
+ key = value2
+--------
+
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-count-objects.adoc b/git-count-objects.adoc
new file mode 100644
index 0000000..97f9f12
--- /dev/null
+++ b/git-count-objects.adoc
@@ -0,0 +1,54 @@
+git-count-objects(1)
+====================
+
+NAME
+----
+git-count-objects - Count unpacked number of objects and their disk consumption
+
+SYNOPSIS
+--------
+[verse]
+'git count-objects' [-v] [-H | --human-readable]
+
+DESCRIPTION
+-----------
+Counts the number of unpacked object files and disk space consumed by
+them, to help you decide when it is a good time to repack.
+
+
+OPTIONS
+-------
+-v::
+--verbose::
+ Provide more detailed reports:
++
+count: the number of loose objects
++
+size: disk space consumed by loose objects, in KiB (unless -H is specified)
++
+in-pack: the number of in-pack objects
++
+size-pack: disk space consumed by the packs, in KiB (unless -H is specified)
++
+prune-packable: the number of loose objects that are also present in
+the packs. These objects could be pruned using `git prune-packed`.
++
+garbage: the number of files in the object database that are neither valid loose
+objects nor valid packs
++
+size-garbage: disk space consumed by garbage files, in KiB (unless -H is
+specified)
++
+alternate: absolute path of alternate object databases; may appear
+multiple times, one line per path. Note that if the path contains
+non-printable characters, it may be surrounded by double-quotes and
+contain C-style backslashed escape sequences.
+
+-H::
+--human-readable::
+
+Print sizes in human readable format
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-credential-cache--daemon.adoc b/git-credential-cache--daemon.adoc
new file mode 100644
index 0000000..650a15a
--- /dev/null
+++ b/git-credential-cache--daemon.adoc
@@ -0,0 +1,30 @@
+git-credential-cache{litdd}daemon(1)
+====================================
+
+NAME
+----
+git-credential-cache--daemon - Temporarily store user credentials in memory
+
+SYNOPSIS
+--------
+[verse]
+'git credential-cache{litdd}daemon' [--debug] <socket-path>
+
+DESCRIPTION
+-----------
+
+NOTE: You probably don't want to invoke this command yourself; it is
+started automatically when you use linkgit:git-credential-cache[1].
+
+This command listens on the Unix domain socket specified by `<socket-path>`
+for `git-credential-cache` clients. Clients may store and retrieve
+credentials. Each credential is held for a timeout specified by the
+client; once no credentials are held, the daemon exits.
+
+If the `--debug` option is specified, the daemon does not close its
+stderr stream, and may output extra diagnostics to it even after it has
+begun listening for clients.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-credential-cache.adoc b/git-credential-cache.adoc
new file mode 100644
index 0000000..54fa7a2
--- /dev/null
+++ b/git-credential-cache.adoc
@@ -0,0 +1,100 @@
+git-credential-cache(1)
+=======================
+
+NAME
+----
+git-credential-cache - Helper to temporarily store passwords in memory
+
+SYNOPSIS
+--------
+-----------------------------
+git config credential.helper 'cache [<options>]'
+-----------------------------
+
+DESCRIPTION
+-----------
+
+This command caches credentials for use by future Git programs.
+The stored credentials are kept in memory of the cache-daemon
+process (instead of being written to a file) and are forgotten after a
+configurable timeout. Credentials are forgotten sooner if the
+cache-daemon dies, for example if the system restarts. The cache
+is accessible over a Unix domain socket, restricted to the current
+user by filesystem permissions.
+
+You probably don't want to invoke this command directly; it is meant to
+be used as a credential helper by other parts of Git. See
+linkgit:gitcredentials[7] or `EXAMPLES` below.
+
+OPTIONS
+-------
+
+--timeout <seconds>::
+
+ Number of seconds to cache credentials (default: 900).
+
+--socket <path>::
+
+ Use `<path>` to contact a running cache daemon (or start a new
+ cache daemon if one is not started).
+ Defaults to `$XDG_CACHE_HOME/git/credential/socket` unless
+ `~/.git-credential-cache/` exists in which case
+ `~/.git-credential-cache/socket` is used instead.
+ If your home directory is on a network-mounted filesystem, you
+ may need to change this to a local filesystem. You must specify
+ an absolute path.
+
+CONTROLLING THE DAEMON
+----------------------
+
+If you would like the daemon to exit early, forgetting all cached
+credentials before their timeout, you can issue an `exit` action:
+
+--------------------------------------
+git credential-cache exit
+--------------------------------------
+
+EXAMPLES
+--------
+
+The point of this helper is to reduce the number of times you must type
+your username or password. For example:
+
+------------------------------------
+$ git config credential.helper cache
+$ git push http://example.com/repo.git
+Username: <type your username>
+Password: <type your password>
+
+[work for 5 more minutes]
+$ git push http://example.com/repo.git
+[your credentials are used automatically]
+------------------------------------
+
+You can provide options via the credential.helper configuration
+variable (this example increases the cache time to 1 hour):
+
+-------------------------------------------------------
+$ git config credential.helper 'cache --timeout=3600'
+-------------------------------------------------------
+
+PERSONAL ACCESS TOKENS
+----------------------
+
+Some remotes accept personal access tokens, which are randomly
+generated and hard to memorise. They typically have a lifetime of weeks
+or months.
+
+git-credential-cache is inherently unsuitable for persistent storage of
+personal access tokens. The credential will be forgotten after the cache
+timeout. Even if you configure a long timeout, credentials will be
+forgotten if the daemon dies.
+
+To avoid frequently regenerating personal access tokens, configure a
+credential helper with persistent storage. Alternatively, configure an
+OAuth credential helper to generate credentials automatically. See
+linkgit:gitcredentials[7], sections "Available helpers" and "OAuth".
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-credential-store.adoc b/git-credential-store.adoc
new file mode 100644
index 0000000..71864a8
--- /dev/null
+++ b/git-credential-store.adoc
@@ -0,0 +1,110 @@
+git-credential-store(1)
+=======================
+
+NAME
+----
+git-credential-store - Helper to store credentials on disk
+
+SYNOPSIS
+--------
+-------------------
+git config credential.helper 'store [<options>]'
+-------------------
+
+DESCRIPTION
+-----------
+
+NOTE: Using this helper will store your passwords unencrypted on disk,
+protected only by filesystem permissions. If this is not an acceptable
+security tradeoff, try linkgit:git-credential-cache[1], or find a helper
+that integrates with secure storage provided by your operating system.
+
+This command stores credentials indefinitely on disk for use by future
+Git programs.
+
+You probably don't want to invoke this command directly; it is meant to
+be used as a credential helper by other parts of git. See
+linkgit:gitcredentials[7] or `EXAMPLES` below.
+
+OPTIONS
+-------
+
+--file=<path>::
+
+ Use `<path>` to lookup and store credentials. The file will have its
+ filesystem permissions set to prevent other users on the system
+ from reading it, but it will not be encrypted or otherwise
+ protected. If not specified, credentials will be searched for from
+ `~/.git-credentials` and `$XDG_CONFIG_HOME/git/credentials`, and
+ credentials will be written to `~/.git-credentials` if it exists, or
+ `$XDG_CONFIG_HOME/git/credentials` if it exists and the former does
+ not. See also <<FILES>>.
+
+[[FILES]]
+FILES
+-----
+
+If not set explicitly with `--file`, there are two files where
+git-credential-store will search for credentials in order of precedence:
+
+~/.git-credentials::
+ User-specific credentials file.
+
+$XDG_CONFIG_HOME/git/credentials::
+ Second user-specific credentials file. If '$XDG_CONFIG_HOME' is not set
+ or empty, `$HOME/.config/git/credentials` will be used. Any credentials
+ stored in this file will not be used if `~/.git-credentials` has a
+ matching credential as well. It is a good idea not to create this file
+ if you sometimes use older versions of Git that do not support it.
+
+For credential lookups, the files are read in the order given above, with the
+first matching credential found taking precedence over credentials found in
+files further down the list.
+
+Credential storage will by default write to the first existing file in the
+list. If none of these files exist, `~/.git-credentials` will be created and
+written to.
+
+When erasing credentials, matching credentials will be erased from all files.
+
+EXAMPLES
+--------
+
+The point of this helper is to reduce the number of times you must type
+your username or password. For example:
+
+------------------------------------------
+$ git config credential.helper store
+$ git push http://example.com/repo.git
+Username: <type your username>
+Password: <type your password>
+
+[several days later]
+$ git push http://example.com/repo.git
+[your credentials are used automatically]
+------------------------------------------
+
+STORAGE FORMAT
+--------------
+
+The `.git-credentials` file is stored in plaintext. Each credential is
+stored on its own line as a URL like:
+
+------------------------------
+https://user:pass@example.com
+------------------------------
+
+No other kinds of lines (e.g. empty lines or comment lines) are
+allowed in the file, even though some may be silently ignored. Do
+not view or edit the file with editors.
+
+When Git needs authentication for a particular URL context,
+credential-store will consider that context a pattern to match against
+each entry in the credentials file. If the protocol, hostname, and
+username (if we already have one) match, then the password is returned
+to Git. See the discussion of configuration in linkgit:gitcredentials[7]
+for more information.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-credential.adoc b/git-credential.adoc
new file mode 100644
index 0000000..e414932
--- /dev/null
+++ b/git-credential.adoc
@@ -0,0 +1,294 @@
+git-credential(1)
+=================
+
+NAME
+----
+git-credential - Retrieve and store user credentials
+
+SYNOPSIS
+--------
+------------------
+'git credential' (fill|approve|reject|capability)
+------------------
+
+DESCRIPTION
+-----------
+
+Git has an internal interface for storing and retrieving credentials
+from system-specific helpers, as well as prompting the user for
+usernames and passwords. The git-credential command exposes this
+interface to scripts which may want to retrieve, store, or prompt for
+credentials in the same manner as Git. The design of this scriptable
+interface models the internal C API; see credential.h for more
+background on the concepts.
+
+git-credential takes an "action" option on the command-line (one of
+`fill`, `approve`, or `reject`) and reads a credential description
+on stdin (see <<IOFMT,INPUT/OUTPUT FORMAT>>).
+
+If the action is `fill`, git-credential will attempt to add "username"
+and "password" attributes to the description by reading config files,
+by contacting any configured credential helpers, or by prompting the
+user. The username and password attributes of the credential
+description are then printed to stdout together with the attributes
+already provided.
+
+If the action is `approve`, git-credential will send the description
+to any configured credential helpers, which may store the credential
+for later use.
+
+If the action is `reject`, git-credential will send the description to
+any configured credential helpers, which may erase any stored
+credentials matching the description.
+
+If the action is `capability`, git-credential will announce any capabilities
+it supports to standard output.
+
+If the action is `approve` or `reject`, no output should be emitted.
+
+TYPICAL USE OF GIT CREDENTIAL
+-----------------------------
+
+An application using git-credential will typically use `git
+credential` following these steps:
+
+ 1. Generate a credential description based on the context.
++
+For example, if we want a password for
+`https://example.com/foo.git`, we might generate the following
+credential description (don't forget the blank line at the end; it
+tells `git credential` that the application finished feeding all the
+information it has):
+
+ protocol=https
+ host=example.com
+ path=foo.git
+
+ 2. Ask git-credential to give us a username and password for this
+ description. This is done by running `git credential fill`,
+ feeding the description from step (1) to its standard input. The complete
+ credential description (including the credential per se, i.e. the
+ login and password) will be produced on standard output, like:
+
+ protocol=https
+ host=example.com
+ username=bob
+ password=secr3t
++
+In most cases, this means the attributes given in the input will be
+repeated in the output, but Git may also modify the credential
+description, for example by removing the `path` attribute when the
+protocol is HTTP(s) and `credential.useHttpPath` is false.
++
+If the `git credential` knew about the password, this step may
+not have involved the user actually typing this password (the
+user may have typed a password to unlock the keychain instead,
+or no user interaction was done if the keychain was already
+unlocked) before it returned `password=secr3t`.
+
+ 3. Use the credential (e.g., access the URL with the username and
+ password from step (2)), and see if it's accepted.
+
+ 4. Report on the success or failure of the password. If the
+ credential allowed the operation to complete successfully, then
+ it can be marked with an "approve" action to tell `git
+ credential` to reuse it in its next invocation. If the credential
+ was rejected during the operation, use the "reject" action so
+ that `git credential` will ask for a new password in its next
+ invocation. In either case, `git credential` should be fed with
+ the credential description obtained from step (2) (which also
+ contains the fields provided in step (1)).
+
+[[IOFMT]]
+INPUT/OUTPUT FORMAT
+-------------------
+
+`git credential` reads and/or writes (depending on the action used)
+credential information in its standard input/output. This information
+can correspond either to keys for which `git credential` will obtain
+the login information (e.g. host, protocol, path), or to the actual
+credential data to be obtained (username/password).
+
+The credential is split into a set of named attributes, with one
+attribute per line. Each attribute is specified by a key-value pair,
+separated by an `=` (equals) sign, followed by a newline.
+
+The key may contain any bytes except `=`, newline, or NUL. The value may
+contain any bytes except newline or NUL. A line, including the trailing
+newline, may not exceed 65535 bytes in order to allow implementations to
+parse efficiently.
+
+Attributes with keys that end with C-style array brackets `[]` can have
+multiple values. Each instance of a multi-valued attribute forms an
+ordered list of values - the order of the repeated attributes defines
+the order of the values. An empty multi-valued attribute (`key[]=\n`)
+acts to clear any previous entries and reset the list.
+
+In all cases, all bytes are treated as-is (i.e., there is no quoting,
+and one cannot transmit a value with newline or NUL in it). The list of
+attributes is terminated by a blank line or end-of-file.
+
+Git understands the following attributes:
+
+`protocol`::
+
+ The protocol over which the credential will be used (e.g.,
+ `https`).
+
+`host`::
+
+ The remote hostname for a network credential. This includes
+ the port number if one was specified (e.g., "example.com:8088").
+
+`path`::
+
+ The path with which the credential will be used. E.g., for
+ accessing a remote https repository, this will be the
+ repository's path on the server.
+
+`username`::
+
+ The credential's username, if we already have one (e.g., from a
+ URL, the configuration, the user, or from a previously run helper).
+
+`password`::
+
+ The credential's password, if we are asking it to be stored.
+
+`password_expiry_utc`::
+
+ Generated passwords such as an OAuth access token may have an expiry date.
+ When reading credentials from helpers, `git credential fill` ignores expired
+ passwords. Represented as Unix time UTC, seconds since 1970.
+
+`oauth_refresh_token`::
+
+ An OAuth refresh token may accompany a password that is an OAuth access
+ token. Helpers must treat this attribute as confidential like the password
+ attribute. Git itself has no special behaviour for this attribute.
+
+`url`::
+
+ When this special attribute is read by `git credential`, the
+ value is parsed as a URL and treated as if its constituent parts
+ were read (e.g., `url=https://example.com` would behave as if
+ `protocol=https` and `host=example.com` had been provided). This
+ can help callers avoid parsing URLs themselves.
++
+Note that specifying a protocol is mandatory and if the URL
+doesn't specify a hostname (e.g., "cert:///path/to/file") the
+credential will contain a hostname attribute whose value is an
+empty string.
++
+Components which are missing from the URL (e.g., there is no
+username in the example above) will be left unset.
+
+`authtype`::
+ This indicates that the authentication scheme in question should be used.
+ Common values for HTTP and HTTPS include `basic`, `bearer`, and `digest`,
+ although the latter is insecure and should not be used. If `credential`
+ is used, this may be set to an arbitrary string suitable for the protocol in
+ question (usually HTTP).
++
+This value should not be sent unless the appropriate capability (see below) is
+provided on input.
+
+`credential`::
+ The pre-encoded credential, suitable for the protocol in question (usually
+ HTTP). If this key is sent, `authtype` is mandatory, and `username` and
+ `password` are not used. For HTTP, Git concatenates the `authtype` value and
+ this value with a single space to determine the `Authorization` header.
++
+This value should not be sent unless the appropriate capability (see below) is
+provided on input.
+
+`ephemeral`::
+ This boolean value indicates, if true, that the value in the `credential`
+ field should not be saved by the credential helper because its usefulness is
+ limited in time. For example, an HTTP Digest `credential` value is computed
+ using a nonce and reusing it will not result in successful authentication.
+ This may also be used for situations with short duration (e.g., 24-hour)
+ credentials. The default value is false.
++
+The credential helper will still be invoked with `store` or `erase` so that it
+can determine whether the operation was successful.
++
+This value should not be sent unless the appropriate capability (see below) is
+provided on input.
+
+`state[]`::
+ This value provides an opaque state that will be passed back to this helper
+ if it is called again. Each different credential helper may specify this
+ once. The value should include a prefix unique to the credential helper and
+ should ignore values that don't match its prefix.
++
+This value should not be sent unless the appropriate capability (see below) is
+provided on input.
+
+`continue`::
+ This is a boolean value, which, if enabled, indicates that this
+ authentication is a non-final part of a multistage authentication step. This
+ is common in protocols such as NTLM and Kerberos, where two rounds of client
+ authentication are required, and setting this flag allows the credential
+ helper to implement the multistage authentication step. This flag should
+ only be sent if a further stage is required; that is, if another round of
+ authentication is expected.
++
+This value should not be sent unless the appropriate capability (see below) is
+provided on input. This attribute is 'one-way' from a credential helper to
+pass information to Git (or other programs invoking `git credential`).
+
+`wwwauth[]`::
+
+ When an HTTP response is received by Git that includes one or more
+ 'WWW-Authenticate' authentication headers, these will be passed by Git
+ to credential helpers.
++
+Each 'WWW-Authenticate' header value is passed as a multi-valued
+attribute 'wwwauth[]', where the order of the attributes is the same as
+they appear in the HTTP response. This attribute is 'one-way' from Git
+to pass additional information to credential helpers.
+
+`capability[]`::
+ This signals that Git, or the helper, as appropriate, supports the capability
+ in question. This can be used to provide better, more specific data as part
+ of the protocol. A `capability[]` directive must precede any value depending
+ on it and these directives _should_ be the first item announced in the
+ protocol.
++
+There are two currently supported capabilities. The first is `authtype`, which
+indicates that the `authtype`, `credential`, and `ephemeral` values are
+understood. The second is `state`, which indicates that the `state[]` and
+`continue` values are understood.
++
+It is not obligatory to use the additional features just because the capability
+is supported, but they should not be provided without the capability.
+
+Unrecognised attributes and capabilities are silently discarded.
+
+[[CAPA-IOFMT]]
+CAPABILITY INPUT/OUTPUT FORMAT
+------------------------------
+
+For `git credential capability`, the format is slightly different. First, a
+`version 0` announcement is made to indicate the current version of the
+protocol, and then each capability is announced with a line like `capability
+authtype`. Credential helpers may also implement this format, again with the
+`capability` argument. Additional lines may be added in the future; callers
+should ignore lines which they don't understand.
+
+Because this is a new part of the credential helper protocol, older versions of
+Git, as well as some credential helpers, may not support it. If a non-zero
+exit status is received, or if the first line doesn't start with the word
+`version` and a space, callers should assume that no capabilities are supported.
+
+The intention of this format is to differentiate it from the credential output
+in an unambiguous way. It is possible to use very simple credential helpers
+(e.g., inline shell scripts) which always produce identical output. Using a
+distinct format allows users to continue to use this syntax without having to
+worry about correctly implementing capability advertisements or accidentally
+confusing callers querying for capabilities.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-cvsexportcommit.adoc b/git-cvsexportcommit.adoc
new file mode 100644
index 0000000..41c8a8a
--- /dev/null
+++ b/git-cvsexportcommit.adoc
@@ -0,0 +1,118 @@
+git-cvsexportcommit(1)
+======================
+
+NAME
+----
+git-cvsexportcommit - Export a single commit to a CVS checkout
+
+
+SYNOPSIS
+--------
+[verse]
+'git cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d <cvsroot>]
+ [-w <cvs-workdir>] [-W] [-f] [-m <msgprefix>] [<parent-commit>] <commit-id>
+
+
+DESCRIPTION
+-----------
+Exports a commit from Git to a CVS checkout, making it easier
+to merge patches from a Git repository into a CVS repository.
+
+Specify the name of a CVS checkout using the -w switch or execute it
+from the root of the CVS working copy. In the latter case GIT_DIR must
+be defined. See examples below.
+
+It does its best to do the safe thing, it will check that the files are
+unchanged and up to date in the CVS checkout, and it will not autocommit
+by default.
+
+Supports file additions, removals, and commits that affect binary files.
+
+If the commit is a merge commit, you must tell 'git cvsexportcommit' what
+parent the changeset should be done against.
+
+OPTIONS
+-------
+
+-c::
+ Commit automatically if the patch applied cleanly. It will not
+ commit if any hunks fail to apply or there were other problems.
+
+-p::
+ Be pedantic (paranoid) when applying patches. Invokes patch with
+ --fuzz=0
+
+-a::
+ Add authorship information. Adds Author line, and Committer (if
+ different from Author) to the message.
+
+-d::
+ Set an alternative CVSROOT to use. This corresponds to the CVS
+ -d parameter. Usually users will not want to set this, except
+ if using CVS in an asymmetric fashion.
+
+-f::
+ Force the merge even if the files are not up to date.
+
+-P::
+ Force the parent commit, even if it is not a direct parent.
+
+-m::
+ Prepend the commit message with the provided prefix.
+ Useful for patch series and the like.
+
+-u::
+ Update affected files from CVS repository before attempting export.
+
+-k::
+ Reverse CVS keyword expansion (e.g. $Revision: 1.2.3.4$
+ becomes $Revision$) in working CVS checkout before applying patch.
+
+-w::
+ Specify the location of the CVS checkout to use for the export. This
+ option does not require GIT_DIR to be set before execution if the
+ current directory is within a Git repository. The default is the
+ value of 'cvsexportcommit.cvsdir'.
+
+-W::
+ Tell cvsexportcommit that the current working directory is not only
+ a Git checkout, but also the CVS checkout. Therefore, Git will
+ reset the working directory to the parent commit before proceeding.
+
+-v::
+ Verbose.
+
+CONFIGURATION
+-------------
+cvsexportcommit.cvsdir::
+ The default location of the CVS checkout to use for the export.
+
+EXAMPLES
+--------
+
+Merge one patch into CVS::
++
+------------
+$ export GIT_DIR=~/project/.git
+$ cd ~/project_cvs_checkout
+$ git cvsexportcommit -v <commit-sha1>
+$ cvs commit -F .msg <files>
+------------
+
+Merge one patch into CVS (-c and -w options). The working directory is within the Git Repo::
++
+------------
+ $ git cvsexportcommit -v -c -w ~/project_cvs_checkout <commit-sha1>
+------------
+
+Merge pending patches into CVS automatically -- only if you really know what you are doing::
++
+------------
+$ export GIT_DIR=~/project/.git
+$ cd ~/project_cvs_checkout
+$ git cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git cvsexportcommit -c -p -v
+------------
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-cvsimport.adoc b/git-cvsimport.adoc
new file mode 100644
index 0000000..90fdc25
--- /dev/null
+++ b/git-cvsimport.adoc
@@ -0,0 +1,228 @@
+git-cvsimport(1)
+================
+
+NAME
+----
+git-cvsimport - Salvage your data out of another SCM people love to hate
+
+
+SYNOPSIS
+--------
+[verse]
+'git cvsimport' [-o <branch-for-HEAD>] [-h] [-v] [-d <CVSROOT>]
+ [-A <author-conv-file>] [-p <options-for-cvsps>] [-P <file>]
+ [-C <git-repository>] [-z <fuzz>] [-i] [-k] [-u] [-s <subst>]
+ [-a] [-m] [-M <regex>] [-S <regex>] [-L <commit-limit>]
+ [-r <remote>] [-R] [<CVS-module>]
+
+
+DESCRIPTION
+-----------
+*WARNING:* `git cvsimport` uses cvsps version 2, which is considered
+deprecated; it does not work with cvsps version 3 and later. If you are
+performing a one-shot import of a CVS repository consider using
+http://cvs2svn.tigris.org/cvs2git.html[cvs2git] or
+https://gitlab.com/esr/cvs-fast-export[cvs-fast-export].
+
+Imports a CVS repository into Git. It will either create a new
+repository, or incrementally import into an existing one.
+
+Splitting the CVS log into patch sets is done by 'cvsps'.
+At least version 2.1 is required.
+
+*WARNING:* for certain situations the import leads to incorrect results.
+Please see the section <<issues,ISSUES>> for further reference.
+
+You should *never* do any work of your own on the branches that are
+created by 'git cvsimport'. By default initial import will create and populate a
+"master" branch from the CVS repository's main branch which you're free
+to work with; after that, you need to 'git merge' incremental imports, or
+any CVS branches, yourself. It is advisable to specify a named remote via
+-r to separate and protect the incoming branches.
+
+If you intend to set up a shared public repository that all developers can
+read/write, or if you want to use linkgit:git-cvsserver[1], then you
+probably want to make a bare clone of the imported repository,
+and use the clone as the shared repository.
+See linkgit:gitcvs-migration[7].
+
+
+OPTIONS
+-------
+-v::
+ Verbosity: let 'cvsimport' report what it is doing.
+
+-d <CVSROOT>::
+ The root of the CVS archive. May be local (a simple path) or remote;
+ currently, only the :local:, :ext: and :pserver: access methods
+ are supported. If not given, 'git cvsimport' will try to read it
+ from `CVS/Root`. If no such file exists, it checks for the
+ `CVSROOT` environment variable.
+
+<CVS-module>::
+ The CVS module you want to import. Relative to <CVSROOT>.
+ If not given, 'git cvsimport' tries to read it from
+ `CVS/Repository`.
+
+-C <target-dir>::
+ The Git repository to import to. If the directory doesn't
+ exist, it will be created. Default is the current directory.
+
+-r <remote>::
+ The Git remote to import this CVS repository into.
+ Moves all CVS branches into remotes/<remote>/<branch>
+ akin to the way 'git clone' uses 'origin' by default.
+
+-o <branch-for-HEAD>::
+ When no remote is specified (via -r) the `HEAD` branch
+ from CVS is imported to the 'origin' branch within the Git
+ repository, as `HEAD` already has a special meaning for Git.
+ When a remote is specified the `HEAD` branch is named
+ remotes/<remote>/master mirroring 'git clone' behaviour.
+ Use this option if you want to import into a different
+ branch.
++
+Use '-o master' for continuing an import that was initially done by
+the old cvs2git tool.
+
+-i::
+ Import-only: don't perform a checkout after importing. This option
+ ensures the working directory and index remain untouched and will
+ not create them if they do not exist.
+
+-k::
+ Kill keywords: will extract files with '-kk' from the CVS archive
+ to avoid noisy changesets. Highly recommended, but off by default
+ to preserve compatibility with early imported trees.
+
+-u::
+ Convert underscores in tag and branch names to dots.
+
+-s <subst>::
+ Substitute the character "/" in branch names with <subst>
+
+-p <options-for-cvsps>::
+ Additional options for cvsps.
+ The options `-u` and '-A' are implicit and should not be used here.
++
+If you need to pass multiple options, separate them with a comma.
+
+-z <fuzz>::
+ Pass the timestamp fuzz factor to cvsps, in seconds. If unset,
+ cvsps defaults to 300s.
+
+-P <cvsps-output-file>::
+ Instead of calling cvsps, read the provided cvsps output file. Useful
+ for debugging or when cvsps is being handled outside cvsimport.
+
+-m::
+ Attempt to detect merges based on the commit message. This option
+ will enable default regexes that try to capture the source
+ branch name from the commit message.
+
+-M <regex>::
+ Attempt to detect merges based on the commit message with a custom
+ regex. It can be used with `-m` to enable the default regexes
+ as well. You must escape forward slashes.
++
+The regex must capture the source branch name in $1.
++
+This option can be used several times to provide several detection regexes.
+
+-S <regex>::
+ Skip paths matching the regex.
+
+-a::
+ Import all commits, including recent ones. cvsimport by default
+ skips commits that have a timestamp less than 10 minutes ago.
+
+-L <limit>::
+ Limit the number of commits imported. Workaround for cases where
+ cvsimport leaks memory.
+
+-A <author-conv-file>::
+ CVS by default uses the Unix username when writing its
+ commit logs. Using this option and an author-conv-file
+ maps the name recorded in CVS to author name, e-mail and
+ optional time zone:
++
+---------
+ exon=Andreas Ericsson <ae@op5.se>
+ spawn=Simon Pawn <spawn@frog-pond.org> America/Chicago
+
+---------
++
+'git cvsimport' will make it appear as those authors had
+their GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL set properly
+all along. If a time zone is specified, GIT_AUTHOR_DATE will
+have the corresponding offset applied.
++
+For convenience, this data is saved to `$GIT_DIR/cvs-authors`
+each time the '-A' option is provided and read from that same
+file each time 'git cvsimport' is run.
++
+It is not recommended to use this feature if you intend to
+export changes back to CVS again later with
+'git cvsexportcommit'.
+
+-R::
+ Generate a `$GIT_DIR/cvs-revisions` file containing a mapping from CVS
+ revision numbers to newly-created Git commit IDs. The generated file
+ will contain one line for each (filename, revision) pair imported;
+ each line will look like
++
+---------
+src/widget.c 1.1 1d862f173cdc7325b6fa6d2ae1cfd61fd1b512b7
+---------
++
+The revision data is appended to the file if it already exists, for use when
+doing incremental imports.
++
+This option may be useful if you have CVS revision numbers stored in commit
+messages, bug-tracking systems, email archives, and the like.
+
+-h::
+ Print a short usage message and exit.
+
+OUTPUT
+------
+If `-v` is specified, the script reports what it is doing.
+
+Otherwise, success is indicated the Unix way, i.e. by simply exiting with
+a zero exit status.
+
+[[issues]]
+ISSUES
+------
+Problems related to timestamps:
+
+ * If timestamps of commits in the CVS repository are not stable enough
+ to be used for ordering commits changes may show up in the wrong
+ order.
+ * If any files were ever "cvs import"ed more than once (e.g., import of
+ more than one vendor release) the HEAD contains the wrong content.
+ * If the timestamp order of different files cross the revision order
+ within the commit matching time window the order of commits may be
+ wrong.
+
+Problems related to branches:
+
+ * Branches on which no commits have been made are not imported.
+ * All files from the branching point are added to a branch even if
+ never added in CVS.
+ * This applies to files added to the source branch *after* a daughter
+ branch was created: if previously no commit was made on the daughter
+ branch they will erroneously be added to the daughter branch in git.
+
+Problems related to tags:
+
+* Multiple tags on the same revision are not imported.
+
+If you suspect that any of these issues may apply to the repository you
+want to import, consider using cvs2git:
+
+* cvs2git (part of cvs2svn), `https://subversion.apache.org/`
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-cvsserver.adoc b/git-cvsserver.adoc
new file mode 100644
index 0000000..4c475ef
--- /dev/null
+++ b/git-cvsserver.adoc
@@ -0,0 +1,433 @@
+git-cvsserver(1)
+================
+
+NAME
+----
+git-cvsserver - A CVS server emulator for Git
+
+SYNOPSIS
+--------
+
+SSH:
+
+[verse]
+export CVS_SERVER="git cvsserver"
+'cvs' -d :ext:user@server/path/repo.git co <HEAD_name>
+
+pserver (/etc/inetd.conf):
+
+[verse]
+cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver
+
+Usage:
+
+[verse]
+'git-cvsserver' [<options>] [pserver|server] [<directory> ...]
+
+DESCRIPTION
+-----------
+
+This application is a CVS emulation layer for Git.
+
+It is highly functional. However, not all methods are implemented,
+and for those methods that are implemented,
+not all switches are implemented.
+
+Testing has been done using both the CLI CVS client, and the Eclipse CVS
+plugin. Most functionality works fine with both of these clients.
+
+OPTIONS
+-------
+
+All these options obviously only make sense if enforced by the server side.
+They have been implemented to resemble the linkgit:git-daemon[1] options as
+closely as possible.
+
+--base-path <path>::
+Prepend 'path' to requested CVSROOT
+
+--strict-paths::
+Don't allow recursing into subdirectories
+
+--export-all::
+Don't check for `gitcvs.enabled` in config. You also have to specify a list
+of allowed directories (see below) if you want to use this option.
+
+-V::
+--version::
+Print version information and exit
+
+-h::
+-H::
+--help::
+Print usage information and exit
+
+<directory>::
+The remaining arguments provide a list of directories. If no directories
+are given, then all are allowed. Repositories within these directories
+still require the `gitcvs.enabled` config option, unless `--export-all`
+is specified.
+
+LIMITATIONS
+-----------
+
+CVS clients cannot tag, branch or perform Git merges.
+
+'git-cvsserver' maps Git branches to CVS modules. This is very different
+from what most CVS users would expect since in CVS modules usually represent
+one or more directories.
+
+INSTALLATION
+------------
+
+1. If you are going to offer CVS access via pserver, add a line in
+ /etc/inetd.conf like
++
+--
+------
+ cvspserver stream tcp nowait nobody git-cvsserver pserver
+
+------
+Note: Some inetd servers let you specify the name of the executable
+independently of the value of argv[0] (i.e. the name the program assumes
+it was executed with). In this case the correct line in /etc/inetd.conf
+looks like
+
+------
+ cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver
+
+------
+
+Only anonymous access is provided by pserver by default. To commit you
+will have to create pserver accounts, simply add a gitcvs.authdb
+setting in the config file of the repositories you want the cvsserver
+to allow writes to, for example:
+
+------
+
+ [gitcvs]
+ authdb = /etc/cvsserver/passwd
+
+------
+The format of these files is username followed by the encrypted password,
+for example:
+
+------
+ myuser:sqkNi8zPf01HI
+ myuser:$1$9K7FzU28$VfF6EoPYCJEYcVQwATgOP/
+ myuser:$5$.NqmNH1vwfzGpV8B$znZIcumu1tNLATgV2l6e1/mY8RzhUDHMOaVOeL1cxV3
+------
+You can use the 'htpasswd' facility that comes with Apache to make these
+files, but only with the -d option (or -B if your system supports it).
+
+Preferably use the system specific utility that manages password hash
+creation in your platform (e.g. mkpasswd in Linux, encrypt in OpenBSD or
+pwhash in NetBSD) and paste it in the right location.
+
+Then provide your password via the pserver method, for example:
+------
+ cvs -d:pserver:someuser:somepassword@server:/path/repo.git co <HEAD_name>
+------
+No special setup is needed for SSH access, other than having Git tools
+in the PATH. If you have clients that do not accept the CVS_SERVER
+environment variable, you can rename 'git-cvsserver' to `cvs`.
+
+Note: Newer CVS versions (>= 1.12.11) also support specifying
+CVS_SERVER directly in CVSROOT like
+
+------
+ cvs -d ":ext;CVS_SERVER=git cvsserver:user@server/path/repo.git" co <HEAD_name>
+------
+This has the advantage that it will be saved in your 'CVS/Root' files and
+you don't need to worry about always setting the correct environment
+variable. SSH users restricted to 'git-shell' don't need to override the default
+with CVS_SERVER (and shouldn't) as 'git-shell' understands `cvs` to mean
+'git-cvsserver' and pretends that the other end runs the real 'cvs' better.
+--
+2. For each repo that you want accessible from CVS you need to edit config in
+ the repo and add the following section.
++
+--
+------
+ [gitcvs]
+ enabled=1
+ # optional for debugging
+ logFile=/path/to/logfile
+
+------
+Note: you need to ensure each user that is going to invoke 'git-cvsserver' has
+write access to the log file and to the database (see
+<<dbbackend,Database Backend>>. If you want to offer write access over
+SSH, the users of course also need write access to the Git repository itself.
+
+You also need to ensure that each repository is "bare" (without a Git index
+file) for `cvs commit` to work. See linkgit:gitcvs-migration[7].
+
+[[configaccessmethod]]
+All configuration variables can also be overridden for a specific method of
+access. Valid method names are "ext" (for SSH access) and "pserver". The
+following example configuration would disable pserver access while still
+allowing access over SSH.
+------
+ [gitcvs]
+ enabled=0
+
+ [gitcvs "ext"]
+ enabled=1
+------
+--
+3. If you didn't specify the CVSROOT/CVS_SERVER directly in the checkout command,
+ automatically saving it in your 'CVS/Root' files, then you need to set them
+ explicitly in your environment. CVSROOT should be set as per normal, but the
+ directory should point at the appropriate Git repo. As above, for SSH clients
+ _not_ restricted to 'git-shell', CVS_SERVER should be set to 'git-cvsserver'.
++
+--
+------
+ export CVSROOT=:ext:user@server:/var/git/project.git
+ export CVS_SERVER="git cvsserver"
+------
+--
+4. For SSH clients that will make commits, make sure their server-side
+ .ssh/environment files (or .bashrc, etc., according to their specific shell)
+ export appropriate values for GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL,
+ GIT_COMMITTER_NAME, and GIT_COMMITTER_EMAIL. For SSH clients whose login
+ shell is bash, .bashrc may be a reasonable alternative.
+
+5. Clients should now be able to check out the project. Use the CVS 'module'
+ name to indicate what Git 'head' you want to check out. This also sets the
+ name of your newly checked-out directory, unless you tell it otherwise with
+ `-d <dir-name>`. For example, this checks out 'master' branch to the
+ `project-master` directory:
++
+------
+ cvs co -d project-master master
+------
+
+[[dbbackend]]
+DATABASE BACKEND
+----------------
+
+'git-cvsserver' uses one database per Git head (i.e. CVS module) to
+store information about the repository to maintain consistent
+CVS revision numbers. The database needs to be
+updated (i.e. written to) after every commit.
+
+If the commit is done directly by using `git` (as opposed to
+using 'git-cvsserver') the update will need to happen on the
+next repository access by 'git-cvsserver', independent of
+access method and requested operation.
+
+That means that even if you offer only read access (e.g. by using
+the pserver method), 'git-cvsserver' should have write access to
+the database to work reliably (otherwise you need to make sure
+that the database is up to date any time 'git-cvsserver' is executed).
+
+By default it uses SQLite databases in the Git directory, named
+`gitcvs.<module-name>.sqlite`. Note that the SQLite backend creates
+temporary files in the same directory as the database file on
+write so it might not be enough to grant the users using
+'git-cvsserver' write access to the database file without granting
+them write access to the directory, too.
+
+The database cannot be reliably regenerated in a
+consistent form after the branch it is tracking has changed.
+Example: For merged branches, 'git-cvsserver' only tracks
+one branch of development, and after a 'git merge' an
+incrementally updated database may track a different branch
+than a database regenerated from scratch, causing inconsistent
+CVS revision numbers. `git-cvsserver` has no way of knowing which
+branch it would have picked if it had been run incrementally
+pre-merge. So if you have to fully or partially (from old
+backup) regenerate the database, you should be suspicious
+of pre-existing CVS sandboxes.
+
+You can configure the database backend with the following
+configuration variables:
+
+Configuring database backend
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+'git-cvsserver' uses the Perl DBI module. Please also read
+its documentation if changing these variables, especially
+about `DBI->connect()`.
+
+gitcvs.dbName::
+ Database name. The exact meaning depends on the
+ selected database driver, for SQLite this is a filename.
+ Supports variable substitution (see below). May
+ not contain semicolons (`;`).
+ Default: '%Ggitcvs.%m.sqlite'
+
+gitcvs.dbDriver::
+ Used DBI driver. You can specify any available driver
+ for this here, but it might not work. cvsserver is tested
+ with 'DBD::SQLite', reported to work with
+ 'DBD::Pg', and reported *not* to work with 'DBD::mysql'.
+ Please regard this as an experimental feature. May not
+ contain colons (`:`).
+ Default: 'SQLite'
+
+gitcvs.dbuser::
+ Database user. Only useful if setting `dbDriver`, since
+ SQLite has no concept of database users. Supports variable
+ substitution (see below).
+
+gitcvs.dbPass::
+ Database password. Only useful if setting `dbDriver`, since
+ SQLite has no concept of database passwords.
+
+gitcvs.dbTableNamePrefix::
+ Database table name prefix. Supports variable substitution
+ (see below). Any non-alphabetic characters will be replaced
+ with underscores.
+
+All variables can also be set per access method, see <<configaccessmethod,above>>.
+
+Variable substitution
+^^^^^^^^^^^^^^^^^^^^^
+In `dbDriver` and `dbUser` you can use the following variables:
+
+%G::
+ Git directory name
+%g::
+ Git directory name, where all characters except for
+ alphanumeric ones, `.`, and `-` are replaced with
+ `_` (this should make it easier to use the directory
+ name in a filename if wanted)
+%m::
+ CVS module/Git head name
+%a::
+ access method (one of "ext" or "pserver")
+%u::
+ Name of the user running 'git-cvsserver'.
+ If no name can be determined, the
+ numeric uid is used.
+
+ENVIRONMENT
+-----------
+
+These variables obviate the need for command-line options in some
+circumstances, allowing easier restricted usage through git-shell.
+
+GIT_CVSSERVER_BASE_PATH::
+ This variable replaces the argument to --base-path.
+
+GIT_CVSSERVER_ROOT::
+ This variable specifies a single directory, replacing the
+ `<directory>...` argument list. The repository still requires the
+ `gitcvs.enabled` config option, unless `--export-all` is specified.
+
+When these environment variables are set, the corresponding
+command-line arguments may not be used.
+
+ECLIPSE CVS CLIENT NOTES
+------------------------
+
+To get a checkout with the Eclipse CVS client:
+
+1. Select "Create a new project -> From CVS checkout"
+2. Create a new location. See the notes below for details on how to choose the
+ right protocol.
+3. Browse the 'modules' available. It will give you a list of the heads in
+ the repository. You will not be able to browse the tree from there. Only
+ the heads.
+4. Pick `HEAD` when it asks what branch/tag to check out. Untick the
+ "launch commit wizard" to avoid committing the .project file.
+
+Protocol notes: If you are using anonymous access via pserver, just select that.
+Those using SSH access should choose the 'ext' protocol, and configure 'ext'
+access on the Preferences->Team->CVS->ExtConnection pane. Set CVS_SERVER to
+"`git cvsserver`". Note that password support is not good when using 'ext',
+you will definitely want to have SSH keys setup.
+
+Alternatively, you can just use the non-standard extssh protocol that Eclipse
+offer. In that case CVS_SERVER is ignored, and you will have to replace
+the cvs utility on the server with 'git-cvsserver' or manipulate your `.bashrc`
+so that calling 'cvs' effectively calls 'git-cvsserver'.
+
+CLIENTS KNOWN TO WORK
+---------------------
+
+- CVS 1.12.9 on Debian
+- CVS 1.11.17 on MacOSX (from Fink package)
+- Eclipse 3.0, 3.1.2 on MacOSX (see Eclipse CVS Client Notes)
+- TortoiseCVS
+
+OPERATIONS SUPPORTED
+--------------------
+
+All the operations required for normal use are supported, including
+checkout, diff, status, update, log, add, remove, commit.
+
+Most CVS command arguments that read CVS tags or revision numbers
+(typically -r) work, and also support any git refspec
+(tag, branch, commit ID, etc).
+However, CVS revision numbers for non-default branches are not well
+emulated, and cvs log does not show tags or branches at
+all. (Non-main-branch CVS revision numbers superficially resemble CVS
+revision numbers, but they actually encode a git commit ID directly,
+rather than represent the number of revisions since the branch point.)
+
+Note that there are two ways to checkout a particular branch.
+As described elsewhere on this page, the "module" parameter
+of cvs checkout is interpreted as a branch name, and it becomes
+the main branch. It remains the main branch for a given sandbox
+even if you temporarily make another branch sticky with
+cvs update -r. Alternatively, the -r argument can indicate
+some other branch to actually checkout, even though the module
+is still the "main" branch. Tradeoffs (as currently
+implemented): Each new "module" creates a new database on disk with
+a history for the given module, and after the database is created,
+operations against that main branch are fast. Or alternatively,
+-r doesn't take any extra disk space, but may be significantly slower for
+many operations, like cvs update.
+
+If you want to refer to a git refspec that has characters that are
+not allowed by CVS, you have two options. First, it may just work
+to supply the git refspec directly to the appropriate CVS -r argument;
+some CVS clients don't seem to do much sanity checking of the argument.
+Second, if that fails, you can use a special character escape mechanism
+that only uses characters that are valid in CVS tags. A sequence
+of 4 or 5 characters of the form (underscore (`"_"`), dash (`"-"`),
+one or two characters, and dash (`"-"`)) can encode various characters based
+on the one or two letters: `"s"` for slash (`"/"`), `"p"` for
+period (`"."`), `"u"` for underscore (`"_"`), or two hexadecimal digits
+for any byte value at all (typically an ASCII number, or perhaps a part
+of a UTF-8 encoded character).
+
+Legacy monitoring operations are not supported (edit, watch and related).
+Exports and tagging (tags and branches) are not supported at this stage.
+
+CRLF Line Ending Conversions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+By default the server leaves the `-k` mode blank for all files,
+which causes the CVS client to treat them as a text files, subject
+to end-of-line conversion on some platforms.
+
+You can make the server use the end-of-line conversion attributes to
+set the `-k` modes for files by setting the `gitcvs.usecrlfattr`
+config variable. See linkgit:gitattributes[5] for more information
+about end-of-line conversion.
+
+Alternatively, if `gitcvs.usecrlfattr` config is not enabled
+or the attributes do not allow automatic detection for a filename, then
+the server uses the `gitcvs.allBinary` config for the default setting.
+If `gitcvs.allBinary` is set, then file not otherwise
+specified will default to '-kb' mode. Otherwise the `-k` mode
+is left blank. But if `gitcvs.allBinary` is set to "guess", then
+the correct `-k` mode will be guessed based on the contents of
+the file.
+
+For best consistency with 'cvs', it is probably best to override the
+defaults by setting `gitcvs.usecrlfattr` to true,
+and `gitcvs.allBinary` to "guess".
+
+DEPENDENCIES
+------------
+'git-cvsserver' depends on DBD::SQLite.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-daemon.adoc b/git-daemon.adoc
new file mode 100644
index 0000000..ede7b93
--- /dev/null
+++ b/git-daemon.adoc
@@ -0,0 +1,341 @@
+git-daemon(1)
+=============
+
+NAME
+----
+git-daemon - A really simple server for Git repositories
+
+SYNOPSIS
+--------
+[verse]
+'git daemon' [--verbose] [--syslog] [--export-all]
+ [--timeout=<n>] [--init-timeout=<n>] [--max-connections=<n>]
+ [--strict-paths] [--base-path=<path>] [--base-path-relaxed]
+ [--user-path | --user-path=<path>]
+ [--interpolated-path=<pathtemplate>]
+ [--reuseaddr] [--detach] [--pid-file=<file>]
+ [--enable=<service>] [--disable=<service>]
+ [--allow-override=<service>] [--forbid-override=<service>]
+ [--access-hook=<path>] [--[no-]informative-errors]
+ [--inetd |
+ [--listen=<host-or-ipaddr>] [--port=<n>]
+ [--user=<user> [--group=<group>]]]
+ [--log-destination=(stderr|syslog|none)]
+ [<directory>...]
+
+DESCRIPTION
+-----------
+A really simple TCP Git daemon that normally listens on port "DEFAULT_GIT_PORT"
+aka 9418. It waits for a connection asking for a service, and will serve
+that service if it is enabled.
+
+It verifies that the directory has the magic file "git-daemon-export-ok", and
+it will refuse to export any Git directory that hasn't explicitly been marked
+for export this way (unless the `--export-all` parameter is specified). If you
+pass some directory paths as 'git daemon' arguments, the offers are limited to
+repositories within those directories.
+
+By default, only `upload-pack` service is enabled, which serves
+'git fetch-pack' and 'git ls-remote' clients, which are invoked
+from 'git fetch', 'git pull', and 'git clone'.
+
+This is ideally suited for read-only updates, i.e., pulling from
+Git repositories.
+
+An `upload-archive` also exists to serve 'git archive'.
+
+OPTIONS
+-------
+--strict-paths::
+ Match paths exactly (i.e. don't allow "/foo/repo" when the real path is
+ "/foo/repo.git" or "/foo/repo/.git") and don't do user-relative paths.
+ 'git daemon' will refuse to start when this option is enabled and no
+ directory arguments are provided.
+
+--base-path=<path>::
+ Remap all the path requests as relative to the given path.
+ This is sort of "Git root" - if you run 'git daemon' with
+ '--base-path=/srv/git' on example.com, then if you later try to pull
+ 'git://example.com/hello.git', 'git daemon' will interpret the path
+ as `/srv/git/hello.git`.
+
+--base-path-relaxed::
+ If --base-path is enabled and repo lookup fails, with this option
+ 'git daemon' will attempt to lookup without prefixing the base path.
+ This is useful for switching to --base-path usage, while still
+ allowing the old paths.
+
+--interpolated-path=<pathtemplate>::
+ To support virtual hosting, an interpolated path template can be
+ used to dynamically construct alternate paths. The template
+ supports %H for the target hostname as supplied by the client but
+ converted to all lowercase, %CH for the canonical hostname,
+ %IP for the server's IP address, %P for the port number,
+ and %D for the absolute path of the named repository.
+ After interpolation, the path is validated against the directory
+ list.
+
+--export-all::
+ Allow pulling from all directories that look like Git repositories
+ (have the 'objects' and 'refs' subdirectories), even if they
+ do not have the 'git-daemon-export-ok' file.
+
+--inetd::
+ Have the server run as an inetd service. Implies --syslog (may be
+ overridden with `--log-destination=`).
+ Incompatible with --detach, --port, --listen, --user and --group
+ options.
+
+--listen=<host-or-ipaddr>::
+ Listen on a specific IP address or hostname. IP addresses can
+ be either an IPv4 address or an IPv6 address if supported. If IPv6
+ is not supported, then --listen=<hostname> is also not supported and
+ --listen must be given an IPv4 address.
+ Can be given more than once.
+ Incompatible with `--inetd` option.
+
+--port=<n>::
+ Listen on an alternative port. Incompatible with `--inetd` option.
+
+--init-timeout=<n>::
+ Timeout (in seconds) between the moment the connection is established
+ and the client request is received (typically a rather low value, since
+ that should be basically immediate).
+
+--timeout=<n>::
+ Timeout (in seconds) for specific client sub-requests. This includes
+ the time it takes for the server to process the sub-request and the
+ time spent waiting for the next client's request.
+
+--max-connections=<n>::
+ Maximum number of concurrent clients, defaults to 32. Set it to
+ zero for no limit.
+
+--syslog::
+ Short for `--log-destination=syslog`.
+
+--log-destination=<destination>::
+ Send log messages to the specified destination.
+ Note that this option does not imply --verbose,
+ thus by default only error conditions will be logged.
+ The <destination> must be one of:
++
+--
+stderr::
+ Write to standard error.
+ Note that if `--detach` is specified,
+ the process disconnects from the real standard error,
+ making this destination effectively equivalent to `none`.
+syslog::
+ Write to syslog, using the `git-daemon` identifier.
+none::
+ Disable all logging.
+--
++
+The default destination is `syslog` if `--inetd` or `--detach` is specified,
+otherwise `stderr`.
+
+--user-path::
+--user-path=<path>::
+ Allow {tilde}user notation to be used in requests. When
+ specified with no parameter, a request to
+ git://host/{tilde}alice/foo is taken as a request to access
+ 'foo' repository in the home directory of user `alice`.
+ If `--user-path=<path>` is specified, the same request is
+ taken as a request to access `<path>/foo` repository in
+ the home directory of user `alice`.
+
+--verbose::
+ Log details about the incoming connections and requested files.
+
+--reuseaddr::
+ Use SO_REUSEADDR when binding the listening socket.
+ This allows the server to restart without waiting for
+ old connections to time out.
+
+--detach::
+ Detach from the shell. Implies --syslog.
+
+--pid-file=<file>::
+ Save the process id in 'file'. Ignored when the daemon
+ is run under `--inetd`.
+
+--user=<user>::
+--group=<group>::
+ Change daemon's uid and gid before entering the service loop.
+ When only `--user` is given without `--group`, the
+ primary group ID for the user is used. The values of
+ the option are given to `getpwnam(3)` and `getgrnam(3)`
+ and numeric IDs are not supported.
++
+Giving these options is an error when used with `--inetd`; use
+the facility of inet daemon to achieve the same before spawning
+'git daemon' if needed.
++
+Like many programs that switch user id, the daemon does not reset
+environment variables such as `$HOME` when it runs git programs,
+e.g. `upload-pack` and `receive-pack`. When using this option, you
+may also want to set and export `HOME` to point at the home
+directory of `<user>` before starting the daemon, and make sure any
+Git configuration files in that directory are readable by `<user>`.
+
+--enable=<service>::
+--disable=<service>::
+ Enable/disable the service site-wide per default. Note
+ that a service disabled site-wide can still be enabled
+ per repository if it is marked overridable and the
+ repository enables the service with a configuration
+ item.
+
+--allow-override=<service>::
+--forbid-override=<service>::
+ Allow/forbid overriding the site-wide default with per
+ repository configuration. By default, all the services
+ may be overridden.
+
+--[no-]informative-errors::
+ When informative errors are turned on, git-daemon will report
+ more verbose errors to the client, differentiating conditions
+ like "no such repository" from "repository not exported". This
+ is more convenient for clients, but may leak information about
+ the existence of unexported repositories. When informative
+ errors are not enabled, all errors report "access denied" to the
+ client. The default is --no-informative-errors.
+
+--access-hook=<path>::
+ Every time a client connects, first run an external command
+ specified by the <path> with service name (e.g. "upload-pack"),
+ path to the repository, hostname (%H), canonical hostname
+ (%CH), IP address (%IP), and TCP port (%P) as its command-line
+ arguments. The external command can decide to decline the
+ service by exiting with a non-zero status (or to allow it by
+ exiting with a zero status). It can also look at the $REMOTE_ADDR
+ and `$REMOTE_PORT` environment variables to learn about the
+ requestor when making this decision.
++
+The external command can optionally write a single line to its
+standard output to be sent to the requestor as an error message when
+it declines the service.
+
+<directory>::
+ The remaining arguments provide a list of directories. If any
+ directories are specified, then the `git-daemon` process will
+ serve a requested directory only if it is contained in one of
+ these directories. If `--strict-paths` is specified, then the
+ requested directory must match one of these directories exactly.
+
+SERVICES
+--------
+
+These services can be globally enabled/disabled using the
+command-line options of this command. If finer-grained
+control is desired (e.g. to allow 'git archive' to be run
+against only in a few selected repositories the daemon serves),
+the per-repository configuration file can be used to enable or
+disable them.
+
+upload-pack::
+ This serves 'git fetch-pack' and 'git ls-remote'
+ clients. It is enabled by default, but a repository can
+ disable it by setting `daemon.uploadpack` configuration
+ item to `false`.
+
+upload-archive::
+ This serves 'git archive --remote'. It is disabled by
+ default, but a repository can enable it by setting
+ `daemon.uploadarch` configuration item to `true`.
+
+receive-pack::
+ This serves 'git send-pack' clients, allowing anonymous
+ push. It is disabled by default, as there is _no_
+ authentication in the protocol (in other words, anybody
+ can push anything into the repository, including removal
+ of refs). This is solely meant for a closed LAN setting
+ where everybody is friendly. This service can be
+ enabled by setting `daemon.receivepack` configuration item to
+ `true`.
+
+EXAMPLES
+--------
+We assume the following in /etc/services::
++
+------------
+$ grep 9418 /etc/services
+git 9418/tcp # Git Version Control System
+------------
+
+'git daemon' as inetd server::
+ To set up 'git daemon' as an inetd service that handles any
+ repository within `/pub/foo` or `/pub/bar`, place an entry like
+ the following into `/etc/inetd` all on one line:
++
+------------------------------------------------
+ git stream tcp nowait nobody /usr/bin/git
+ git daemon --inetd --verbose --export-all
+ /pub/foo /pub/bar
+------------------------------------------------
+
+
+'git daemon' as inetd server for virtual hosts::
+ To set up 'git daemon' as an inetd service that handles
+ repositories for different virtual hosts, `www.example.com`
+ and `www.example.org`, place an entry like the following into
+ `/etc/inetd` all on one line:
++
+------------------------------------------------
+ git stream tcp nowait nobody /usr/bin/git
+ git daemon --inetd --verbose --export-all
+ --interpolated-path=/pub/%H%D
+ /pub/www.example.org/software
+ /pub/www.example.com/software
+ /software
+------------------------------------------------
++
+In this example, the root-level directory `/pub` will contain
+a subdirectory for each virtual host name supported.
+Further, both hosts advertise repositories simply as
+`git://www.example.com/software/repo.git`. For pre-1.4.0
+clients, a symlink from `/software` into the appropriate
+default repository could be made as well.
+
+
+'git daemon' as regular daemon for virtual hosts::
+ To set up 'git daemon' as a regular, non-inetd service that
+ handles repositories for multiple virtual hosts based on
+ their IP addresses, start the daemon like this:
++
+------------------------------------------------
+ git daemon --verbose --export-all
+ --interpolated-path=/pub/%IP/%D
+ /pub/192.168.1.200/software
+ /pub/10.10.220.23/software
+------------------------------------------------
++
+In this example, the root-level directory `/pub` will contain
+a subdirectory for each virtual host IP address supported.
+Repositories can still be accessed by hostname though, assuming
+they correspond to these IP addresses.
+
+selectively enable/disable services per repository::
+ To enable 'git archive --remote' and disable 'git fetch' against
+ a repository, have the following in the configuration file in the
+ repository (that is the file 'config' next to `HEAD`, 'refs' and
+ 'objects').
++
+----------------------------------------------------------------
+ [daemon]
+ uploadpack = false
+ uploadarch = true
+----------------------------------------------------------------
+
+
+ENVIRONMENT
+-----------
+'git daemon' will set REMOTE_ADDR to the IP address of the client
+that connected to it, if the IP address is available. REMOTE_ADDR will
+be available in the environment of hooks called when
+services are performed.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-describe.adoc b/git-describe.adoc
new file mode 100644
index 0000000..08ff715
--- /dev/null
+++ b/git-describe.adoc
@@ -0,0 +1,211 @@
+git-describe(1)
+===============
+
+NAME
+----
+git-describe - Give an object a human readable name based on an available ref
+
+SYNOPSIS
+--------
+[verse]
+'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] [<commit-ish>...]
+'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] --dirty[=<mark>]
+'git describe' <blob>
+
+DESCRIPTION
+-----------
+The command finds the most recent tag that is reachable from a
+commit. If the tag points to the commit, then only the tag is
+shown. Otherwise, it suffixes the tag name with the number of
+additional commits on top of the tagged object and the
+abbreviated object name of the most recent commit. The result
+is a "human-readable" object name which can also be used to
+identify the commit to other git commands.
+
+By default (without --all or --tags) `git describe` only shows
+annotated tags. For more information about creating annotated tags
+see the -a and -s options to linkgit:git-tag[1].
+
+If the given object refers to a blob, it will be described
+as `<commit-ish>:<path>`, such that the blob can be found
+at `<path>` in the `<commit-ish>`, which itself describes the
+first commit in which this blob occurs in a reverse revision walk
+from HEAD.
+
+OPTIONS
+-------
+<commit-ish>...::
+ Commit-ish object names to describe. Defaults to HEAD if omitted.
+
+--dirty[=<mark>]::
+--broken[=<mark>]::
+ Describe the state of the working tree. When the working
+ tree matches HEAD, the output is the same as "git describe
+ HEAD". If the working tree has local modification "-dirty"
+ is appended to it. If a repository is corrupt and Git
+ cannot determine if there is local modification, Git will
+ error out, unless `--broken' is given, which appends
+ the suffix "-broken" instead.
+
+--all::
+ Instead of using only the annotated tags, use any ref
+ found in `refs/` namespace. This option enables matching
+ any known branch, remote-tracking branch, or lightweight tag.
+
+--tags::
+ Instead of using only the annotated tags, use any tag
+ found in `refs/tags` namespace. This option enables matching
+ a lightweight (non-annotated) tag.
+
+--contains::
+ Instead of finding the tag that predates the commit, find
+ the tag that comes after the commit, and thus contains it.
+ Automatically implies --tags.
+
+--abbrev=<n>::
+ Instead of using the default number of hexadecimal digits (which
+ will vary according to the number of objects in the repository with
+ a default of 7) of the abbreviated object name, use <n> digits, or
+ as many digits as needed to form a unique object name. An <n> of 0
+ will suppress long format, only showing the closest tag.
+
+--candidates=<n>::
+ Instead of considering only the 10 most recent tags as
+ candidates to describe the input commit-ish consider
+ up to <n> candidates. Increasing <n> above 10 will take
+ slightly longer but may produce a more accurate result.
+ An <n> of 0 will cause only exact matches to be output.
+
+--exact-match::
+ Only output exact matches (a tag directly references the
+ supplied commit). This is a synonym for --candidates=0.
+
+--debug::
+ Verbosely display information about the searching strategy
+ being employed to standard error. The tag name will still
+ be printed to standard out.
+
+--long::
+ Always output the long format (the tag, the number of commits
+ and the abbreviated commit name) even when it matches a tag.
+ This is useful when you want to see parts of the commit object name
+ in "describe" output, even when the commit in question happens to be
+ a tagged version. Instead of just emitting the tag name, it will
+ describe such a commit as v1.2-0-gdeadbee (0th commit since tag v1.2
+ that points at object deadbee....).
+
+--match <pattern>::
+ Only consider tags matching the given `glob(7)` pattern,
+ excluding the "refs/tags/" prefix. If used with `--all`, it also
+ considers local branches and remote-tracking references matching the
+ pattern, excluding respectively "refs/heads/" and "refs/remotes/"
+ prefix; references of other types are never considered. If given
+ multiple times, a list of patterns will be accumulated, and tags
+ matching any of the patterns will be considered. Use `--no-match` to
+ clear and reset the list of patterns.
+
+--exclude <pattern>::
+ Do not consider tags matching the given `glob(7)` pattern, excluding
+ the "refs/tags/" prefix. If used with `--all`, it also does not consider
+ local branches and remote-tracking references matching the pattern,
+ excluding respectively "refs/heads/" and "refs/remotes/" prefix;
+ references of other types are never considered. If given multiple times,
+ a list of patterns will be accumulated and tags matching any of the
+ patterns will be excluded. When combined with --match a tag will be
+ considered when it matches at least one --match pattern and does not
+ match any of the --exclude patterns. Use `--no-exclude` to clear and
+ reset the list of patterns.
+
+--always::
+ Show uniquely abbreviated commit object as fallback.
+
+--first-parent::
+ Follow only the first parent commit upon seeing a merge commit.
+ This is useful when you wish to not match tags on branches merged
+ in the history of the target commit.
+
+EXAMPLES
+--------
+
+With something like git.git current tree, I get:
+
+ [torvalds@g5 git]$ git describe parent
+ v1.0.4-14-g2414721
+
+i.e. the current head of my "parent" branch is based on v1.0.4,
+but since it has a few commits on top of that,
+describe has added the number of additional commits ("14") and
+an abbreviated object name for the commit itself ("2414721")
+at the end.
+
+The number of additional commits is the number
+of commits which would be displayed by "git log v1.0.4..parent".
+The hash suffix is "-g" + an unambiguous abbreviation for the tip commit
+of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`). The
+length of the abbreviation scales as the repository grows, using the
+approximate number of objects in the repository and a bit of math
+around the birthday paradox, and defaults to a minimum of 7.
+The "g" prefix stands for "git" and is used to allow describing the version of
+a software depending on the SCM the software is managed with. This is useful
+in an environment where people may use different SCMs.
+
+Doing a 'git describe' on a tag-name will just show the tag name:
+
+ [torvalds@g5 git]$ git describe v1.0.4
+ v1.0.4
+
+With --all, the command can use branch heads as references, so
+the output shows the reference path as well:
+
+ [torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5^2
+ tags/v1.0.0-21-g975b
+
+ [torvalds@g5 git]$ git describe --all --abbrev=4 HEAD^
+ heads/lt/describe-7-g975b
+
+With --abbrev set to 0, the command can be used to find the
+closest tagname without any suffix:
+
+ [torvalds@g5 git]$ git describe --abbrev=0 v1.0.5^2
+ tags/v1.0.0
+
+Note that the suffix you get if you type these commands today may be
+longer than what Linus saw above when he ran these commands, as your
+Git repository may have new commits whose object names begin with
+975b that did not exist back then, and "-g975b" suffix alone may not
+be sufficient to disambiguate these commits.
+
+
+SEARCH STRATEGY
+---------------
+
+For each commit-ish supplied, 'git describe' will first look for
+a tag which tags exactly that commit. Annotated tags will always
+be preferred over lightweight tags, and tags with newer dates will
+always be preferred over tags with older dates. If an exact match
+is found, its name will be output and searching will stop.
+
+If an exact match was not found, 'git describe' will walk back
+through the commit history to locate an ancestor commit which
+has been tagged. The ancestor's tag will be output along with an
+abbreviation of the input commit-ish's SHA-1. If `--first-parent` was
+specified then the walk will only consider the first parent of each
+commit.
+
+If multiple tags were found during the walk then the tag which
+has the fewest commits different from the input commit-ish will be
+selected and output. Here fewest commits different is defined as
+the number of commits which would be shown by `git log tag..input`
+will be the smallest number of commits possible.
+
+BUGS
+----
+
+Tree objects as well as tag objects not pointing at commits, cannot be described.
+When describing blobs, the lightweight tags pointing at blobs are ignored,
+but the blob is still described as <commit-ish>:<path> despite the lightweight
+tag being favorable.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-diagnose.adoc b/git-diagnose.adoc
new file mode 100644
index 0000000..0711959
--- /dev/null
+++ b/git-diagnose.adoc
@@ -0,0 +1,65 @@
+git-diagnose(1)
+================
+
+NAME
+----
+git-diagnose - Generate a zip archive of diagnostic information
+
+SYNOPSIS
+--------
+[verse]
+'git diagnose' [(-o | --output-directory) <path>] [(-s | --suffix) <format>]
+ [--mode=<mode>]
+
+DESCRIPTION
+-----------
+Collects detailed information about the user's machine, Git client, and
+repository state and packages that information into a zip archive. The
+generated archive can then, for example, be shared with the Git mailing list to
+help debug an issue or serve as a reference for independent debugging.
+
+By default, the following information is captured in the archive:
+
+ * 'git version --build-options'
+ * The path to the repository root
+ * The available disk space on the filesystem
+ * The name and size of each packfile, including those in alternate object
+ stores
+ * The total count of loose objects, as well as counts broken down by
+ `.git/objects` subdirectory
+
+Additional information can be collected by selecting a different diagnostic mode
+using the `--mode` option.
+
+This tool differs from linkgit:git-bugreport[1] in that it collects much more
+detailed information with a greater focus on reporting the size and data shape
+of repository contents.
+
+OPTIONS
+-------
+-o <path>::
+--output-directory <path>::
+ Place the resulting diagnostics archive in `<path>` instead of the
+ current directory.
+
+-s <format>::
+--suffix <format>::
+ Specify an alternate suffix for the diagnostics archive name, to create
+ a file named 'git-diagnostics-<formatted-suffix>'. This should take the
+ form of a strftime(3) format string; the current local time will be
+ used.
+
+--mode=(stats|all)::
+ Specify the type of diagnostics that should be collected. The default behavior
+ of 'git diagnose' is equivalent to `--mode=stats`.
++
+The `--mode=all` option collects everything included in `--mode=stats`, as well
+as copies of `.git`, `.git/hooks`, `.git/info`, `.git/logs`, and
+`.git/objects/info` directories. This additional information may be sensitive,
+as it can be used to reconstruct the full contents of the diagnosed repository.
+Users should exercise caution when sharing an archive generated with
+`--mode=all`.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-diff-files.adoc b/git-diff-files.adoc
new file mode 100644
index 0000000..2b2358c
--- /dev/null
+++ b/git-diff-files.adoc
@@ -0,0 +1,52 @@
+git-diff-files(1)
+=================
+
+NAME
+----
+git-diff-files - Compares files in the working tree and the index
+
+
+SYNOPSIS
+--------
+[verse]
+'git diff-files' [-q] [-0 | -1 | -2 | -3 | -c | --cc] [<common-diff-options>] [<path>...]
+
+DESCRIPTION
+-----------
+Compares the files in the working tree and the index. When paths
+are specified, compares only those named paths. Otherwise all
+entries in the index are compared. The output format is the
+same as for 'git diff-index' and 'git diff-tree'.
+
+OPTIONS
+-------
+include::diff-options.adoc[]
+
+-1 --base::
+-2 --ours::
+-3 --theirs::
+-0::
+ Diff against the "base" version, "our branch", or "their
+ branch" respectively. With these options, diffs for
+ merged entries are not shown.
++
+The default is to diff against our branch (-2) and the
+cleanly resolved paths. The option -0 can be given to
+omit diff output for unmerged entries and just show "Unmerged".
+
+-c::
+--cc::
+ This compares stage 2 (our branch), stage 3 (their
+ branch), and the working tree file and outputs a combined
+ diff, similar to the way 'diff-tree' shows a merge
+ commit with these flags.
+
+-q::
+ Remain silent even for nonexistent files
+
+
+include::diff-format.adoc[]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-diff-index.adoc b/git-diff-index.adoc
new file mode 100644
index 0000000..911446a
--- /dev/null
+++ b/git-diff-index.adoc
@@ -0,0 +1,127 @@
+git-diff-index(1)
+=================
+
+NAME
+----
+git-diff-index - Compare a tree to the working tree or index
+
+
+SYNOPSIS
+--------
+[verse]
+'git diff-index' [-m] [--cached] [--merge-base] [<common-diff-options>] <tree-ish> [<path>...]
+
+DESCRIPTION
+-----------
+Compare the content and mode of the blobs found in a tree object
+with the corresponding tracked files in the working tree, or with the
+corresponding paths in the index. When <path> arguments are present,
+compare only paths matching those patterns. Otherwise all tracked
+files are compared.
+
+OPTIONS
+-------
+include::diff-options.adoc[]
+
+<tree-ish>::
+ The id of a tree object to diff against.
+
+--cached::
+ Do not consider the on-disk file at all.
+
+--merge-base::
+ Instead of comparing <tree-ish> directly, use the merge base
+ between <tree-ish> and HEAD instead. <tree-ish> must be a
+ commit.
+
+-m::
+ By default, files recorded in the index but not checked
+ out are reported as deleted. This flag makes
+ 'git diff-index' say that all non-checked-out files are up
+ to date.
+
+include::diff-format.adoc[]
+
+OPERATING MODES
+---------------
+You can choose whether you want to trust the index file entirely
+(using the `--cached` flag) or ask the diff logic to show any files
+that don't match the stat state as being "tentatively changed". Both
+of these operations are very useful indeed.
+
+CACHED MODE
+-----------
+If `--cached` is specified, it allows you to ask:
+
+ show me the differences between HEAD and the current index
+ contents (the ones I'd write using 'git write-tree')
+
+For example, let's say that you have worked on your working directory, updated
+some files in the index and are ready to commit. You want to see exactly
+*what* you are going to commit, without having to write a new tree
+object and compare it that way, and to do that, you just do
+
+ git diff-index --cached HEAD
+
+Example: let's say I had renamed `commit.c` to `git-commit.c`, and I had
+done an `update-index` to make that effective in the index file.
+`git diff-files` wouldn't show anything at all, since the index file
+matches my working directory. But doing a 'git diff-index' does:
+
+ torvalds@ppc970:~/git> git diff-index --cached HEAD
+ :100644 000000 4161aecc6700a2eb579e842af0b7f22b98443f74 0000000000000000000000000000000000000000 D commit.c
+ :000000 100644 0000000000000000000000000000000000000000 4161aecc6700a2eb579e842af0b7f22b98443f74 A git-commit.c
+
+You can see easily that the above is a rename.
+
+In fact, `git diff-index --cached` *should* always be entirely equivalent to
+actually doing a 'git write-tree' and comparing that. Except this one is much
+nicer for the case where you just want to check where you are.
+
+So doing a `git diff-index --cached` is basically very useful when you are
+asking yourself "what have I already marked for being committed, and
+what's the difference to a previous tree".
+
+NON-CACHED MODE
+---------------
+The "non-cached" mode takes a different approach, and is potentially
+the more useful of the two in that what it does can't be emulated with
+a 'git write-tree' + 'git diff-tree'. Thus that's the default mode.
+The non-cached version asks the question:
+
+ show me the differences between HEAD and the currently checked out
+ tree - index contents _and_ files that aren't up to date
+
+which is obviously a very useful question too, since that tells you what
+you *could* commit. Again, the output matches the 'git diff-tree -r'
+output to a tee, but with a twist.
+
+The twist is that if some file doesn't match the index, we don't have
+a backing store thing for it, and we use the magic "all-zero" sha1 to
+show that. So let's say that you have edited `kernel/sched.c`, but
+have not actually done a 'git update-index' on it yet - there is no
+"object" associated with the new state, and you get:
+
+ torvalds@ppc970:~/v2.6/linux> git diff-index --abbrev HEAD
+ :100644 100644 7476bb5ba 000000000 M kernel/sched.c
+
+i.e., it shows that the tree has changed, and that `kernel/sched.c` is
+not up to date and may contain new stuff. The all-zero sha1 means that to
+get the real diff, you need to look at the object in the working directory
+directly rather than do an object-to-object diff.
+
+NOTE: As with other commands of this type, 'git diff-index' does not
+actually look at the contents of the file at all. So maybe
+`kernel/sched.c` hasn't actually changed, and it's just that you
+touched it. In either case, it's a note that you need to
+'git update-index' it to make the index be in sync.
+
+NOTE: You can have a mixture of files show up as "has been updated"
+and "is still dirty in the working directory" together. You can always
+tell which file is in which state, since the "has been updated" ones
+show a valid sha1, and the "not in sync with the index" ones will
+always have the special all-zero sha1.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-diff-tree.adoc b/git-diff-tree.adoc
new file mode 100644
index 0000000..f1e3134
--- /dev/null
+++ b/git-diff-tree.adoc
@@ -0,0 +1,131 @@
+git-diff-tree(1)
+================
+
+NAME
+----
+git-diff-tree - Compares the content and mode of blobs found via two tree objects
+
+
+SYNOPSIS
+--------
+[verse]
+'git diff-tree' [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty]
+ [-t] [-r] [-c | --cc] [--combined-all-paths] [--root] [--merge-base]
+ [<common-diff-options>] <tree-ish> [<tree-ish>] [<path>...]
+
+DESCRIPTION
+-----------
+Compare the content and mode of blobs found via two tree objects.
+
+If there is only one <tree-ish> given, the commit is compared with its parents
+(see --stdin below).
+
+Note that 'git diff-tree' can use the tree encapsulated in a commit object.
+
+OPTIONS
+-------
+include::diff-options.adoc[]
+
+<tree-ish>::
+ The id of a tree object.
+
+<path>...::
+ If provided, the results are limited to a subset of files
+ matching one of the provided pathspecs.
+
+-r::
+ Recurse into sub-trees.
+
+-t::
+ Show tree entry itself as well as subtrees. Implies -r.
+
+--root::
+ When `--root` is specified the initial commit will be shown as a big
+ creation event. This is equivalent to a diff against the NULL tree.
+
+--merge-base::
+ Instead of comparing the <tree-ish>s directly, use the merge
+ base between the two <tree-ish>s as the "before" side. There
+ must be two <tree-ish>s given and they must both be commits.
+
+--stdin::
+ When `--stdin` is specified, the command does not take
+ <tree-ish> arguments from the command line. Instead, it
+ reads lines containing either two <tree>, one <commit>, or a
+ list of <commit> from its standard input. (Use a single space
+ as separator.)
++
+When two trees are given, it compares the first tree with the second.
+When a single commit is given, it compares the commit with its
+parents. The remaining commits, when given, are used as if they are
+parents of the first commit.
++
+When comparing two trees, the ID of both trees (separated by a space
+and terminated by a newline) is printed before the difference. When
+comparing commits, the ID of the first (or only) commit, followed by a
+newline, is printed.
++
+The following flags further affect the behavior when comparing
+commits (but not trees).
+
+-m::
+ By default, 'git diff-tree --stdin' does not show
+ differences for merge commits. With this flag, it shows
+ differences to that commit from all of its parents. See
+ also `-c`.
+
+-s::
+ By default, 'git diff-tree --stdin' shows differences,
+ either in machine-readable form (without `-p`) or in patch
+ form (with `-p`). This output can be suppressed. It is
+ only useful with the `-v` flag.
+
+-v::
+ This flag causes 'git diff-tree --stdin' to also show
+ the commit message before the differences.
+
+include::pretty-options.adoc[]
+
+--no-commit-id::
+ 'git diff-tree' outputs a line with the commit ID when
+ applicable. This flag suppresses the commit ID output.
+
+-c::
+ This flag changes the way a merge commit is displayed
+ (which means it is useful only when the command is given
+ one <tree-ish>, or `--stdin`). It shows the differences
+ from each of the parents to the merge result simultaneously
+ instead of showing pairwise diff between a parent and the
+ result one at a time (which is what the `-m` option does).
+ Furthermore, it lists only files which were modified
+ from all parents.
+
+--cc::
+ This flag changes the way a merge commit patch is displayed,
+ in a similar way to the `-c` option. It implies the `-c`
+ and `-p` options and further compresses the patch output
+ by omitting uninteresting hunks whose contents in the parents
+ have only two variants and the merge result picks one of them
+ without modification. When all hunks are uninteresting, the commit
+ itself and the commit log message are not shown, just like in any other
+ "empty diff" case.
+
+--combined-all-paths::
+ This flag causes combined diffs (used for merge commits) to
+ list the name of the file from all parents. It thus only has
+ effect when -c or --cc are specified, and is likely only
+ useful if filename changes are detected (i.e. when either
+ rename or copy detection have been requested).
+
+--always::
+ Show the commit itself and the commit log message even
+ if the diff itself is empty.
+
+
+include::pretty-formats.adoc[]
+
+include::diff-format.adoc[]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-diff.adoc b/git-diff.adoc
new file mode 100644
index 0000000..dec173a
--- /dev/null
+++ b/git-diff.adoc
@@ -0,0 +1,252 @@
+git-diff(1)
+===========
+
+NAME
+----
+git-diff - Show changes between commits, commit and working tree, etc
+
+
+SYNOPSIS
+--------
+[synopsis]
+git diff [<options>] [<commit>] [--] [<path>...]
+git diff [<options>] --cached [--merge-base] [<commit>] [--] [<path>...]
+git diff [<options>] [--merge-base] <commit> [<commit>...] <commit> [--] [<path>...]
+git diff [<options>] <commit>...<commit> [--] [<path>...]
+git diff [<options>] <blob> <blob>
+git diff [<options>] --no-index [--] <path> <path>
+
+DESCRIPTION
+-----------
+Show changes between the working tree and the index or a tree, changes
+between the index and a tree, changes between two trees, changes resulting
+from a merge, changes between two blob objects, or changes between two
+files on disk.
+
+`git diff [<options>] [--] [<path>...]`::
+
+ This form is to view the changes you made relative to
+ the index (staging area for the next commit). In other
+ words, the differences are what you _could_ tell Git to
+ further add to the index but you still haven't. You can
+ stage these changes by using linkgit:git-add[1].
+
+`git diff [<options>] --no-index [--] <path> <path>`::
+
+ This form is to compare the given two paths on the
+ filesystem. You can omit the `--no-index` option when
+ running the command in a working tree controlled by Git and
+ at least one of the paths points outside the working tree,
+ or when running the command outside a working tree
+ controlled by Git. This form implies `--exit-code`.
+
+`git diff [<options>] --cached [--merge-base] [<commit>] [--] [<path>...]`::
+
+ This form is to view the changes you staged for the next
+ commit relative to the named _<commit>_. Typically you
+ would want comparison with the latest commit, so if you
+ do not give _<commit>_, it defaults to `HEAD`.
+ If `HEAD` does not exist (e.g. unborn branches) and
+ _<commit>_ is not given, it shows all staged changes.
+ `--staged` is a synonym of `--cached`.
++
+If `--merge-base` is given, instead of using _<commit>_, use the merge base
+of _<commit>_ and `HEAD`. `git diff --cached --merge-base A` is equivalent to
+`git diff --cached $(git merge-base A HEAD)`.
+
+`git diff [<options>] [--merge-base] <commit> [--] [<path>...]`::
+
+ This form is to view the changes you have in your
+ working tree relative to the named _<commit>_. You can
+ use `HEAD` to compare it with the latest commit, or a
+ branch name to compare with the tip of a different
+ branch.
++
+If `--merge-base` is given, instead of using _<commit>_, use the merge base
+of _<commit>_ and `HEAD`. `git diff --merge-base A` is equivalent to
+`git diff $(git merge-base A HEAD)`.
+
+`git diff [<options>] [--merge-base] <commit> <commit> [--] [<path>...]`::
+
+ This is to view the changes between two arbitrary
+ _<commit>_.
++
+If `--merge-base` is given, use the merge base of the two commits for the
+"before" side. `git diff --merge-base A B` is equivalent to
+`git diff $(git merge-base A B) B`.
+
+`git diff [<options>] <commit> <commit>...<commit> [--] [<path>...]`::
+
+ This form is to view the results of a merge commit. The first
+ listed _<commit>_ must be the merge itself; the remaining two or
+ more commits should be its parents. Convenient ways to produce
+ the desired set of revisions are to use the suffixes `@` and
+ `^!`. If `A` is a merge commit, then `git diff A A^@`,
+ `git diff A^!` and `git show A` all give the same combined diff.
+
+`git diff [<options>] <commit>..<commit> [--] [<path>...]`::
+
+ This is synonymous to the earlier form (without the `..`) for
+ viewing the changes between two arbitrary _<commit>_. If _<commit>_ on
+ one side is omitted, it will have the same effect as
+ using `HEAD` instead.
+
+`git diff [<options>] <commit>...<commit> [--] [<path>...]`::
+
+ This form is to view the changes on the branch containing
+ and up to the second _<commit>_, starting at a common ancestor
+ of both _<commit>_. `git diff A...B` is equivalent to
+ `git diff $(git merge-base A B) B`. You can omit any one
+ of _<commit>_, which has the same effect as using `HEAD` instead.
+
+Just in case you are doing something exotic, it should be
+noted that all of the _<commit>_ in the above description, except
+in the `--merge-base` case and in the last two forms that use `..`
+notations, can be any _<tree>_. A tree of interest is the one pointed to
+by the ref named `AUTO_MERGE`, which is written by the `ort` merge
+strategy upon hitting merge conflicts (see linkgit:git-merge[1]).
+Comparing the working tree with `AUTO_MERGE` shows changes you've made
+so far to resolve textual conflicts (see the examples below).
+
+For a more complete list of ways to spell _<commit>_, see
+"SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
+However, `diff` is about comparing two _endpoints_, not ranges,
+and the range notations (`<commit>..<commit>` and `<commit>...<commit>`)
+do not mean a range as defined in the
+"SPECIFYING RANGES" section in linkgit:gitrevisions[7].
+
+`git diff [<options>] <blob> <blob>`::
+
+ This form is to view the differences between the raw
+ contents of two blob objects.
+
+OPTIONS
+-------
+:git-diff: 1
+include::diff-options.adoc[]
+
+`-1`::
+`--base`::
+`-2`::
+`--ours`::
+`-3`::
+`--theirs`::
+ Compare the working tree with
++
+--
+ * the "base" version (stage #1) when using `-1` or `--base`,
+ * "our branch" (stage #2) when using `-2` or `--ours`, or
+ * "their branch" (stage #3) when using `-3` or `--theirs`.
+--
++
+The index contains these stages only for unmerged entries i.e.
+while resolving conflicts. See linkgit:git-read-tree[1]
+section "3-Way Merge" for detailed information.
+
+`-0`::
+ Omit diff output for unmerged entries and just show
+ "Unmerged". Can be used only when comparing the working tree
+ with the index.
+
+`<path>...`::
+ The _<path>_ parameters, when given, are used to limit
+ the diff to the named paths (you can give directory
+ names and get diff for all files under them).
+
+
+include::diff-format.adoc[]
+
+EXAMPLES
+--------
+
+Various ways to check your working tree::
++
+------------
+$ git diff <1>
+$ git diff --cached <2>
+$ git diff HEAD <3>
+$ git diff AUTO_MERGE <4>
+------------
++
+<1> Changes in the working tree not yet staged for the next commit.
+<2> Changes between the index and your last commit; what you
+ would be committing if you run `git commit` without `-a` option.
+<3> Changes in the working tree since your last commit; what you
+ would be committing if you run `git commit -a`
+<4> Changes in the working tree you've made to resolve textual
+ conflicts so far.
+
+Comparing with arbitrary commits::
++
+------------
+$ git diff test <1>
+$ git diff HEAD -- ./test <2>
+$ git diff HEAD^ HEAD <3>
+------------
++
+<1> Instead of using the tip of the current branch, compare with the
+ tip of "test" branch.
+<2> Instead of comparing with the tip of "test" branch, compare with
+ the tip of the current branch, but limit the comparison to the
+ file "test".
+<3> Compare the version before the last commit and the last commit.
+
+Comparing branches::
++
+------------
+$ git diff topic master <1>
+$ git diff topic..master <2>
+$ git diff topic...master <3>
+------------
++
+<1> Changes between the tips of the topic and the master branches.
+<2> Same as above.
+<3> Changes that occurred on the master branch since when the topic
+ branch was started off it.
+
+Limiting the diff output::
++
+------------
+$ git diff --diff-filter=MRC <1>
+$ git diff --name-status <2>
+$ git diff arch/i386 include/asm-i386 <3>
+------------
++
+<1> Show only modification, rename, and copy, but not addition
+ or deletion.
+<2> Show only names and the nature of change, but not actual
+ diff output.
+<3> Limit diff output to named subtrees.
+
+Munging the diff output::
++
+------------
+$ git diff --find-copies-harder -B -C <1>
+$ git diff -R <2>
+------------
++
+<1> Spend extra cycles to find renames, copies and complete
+ rewrites (very expensive).
+<2> Output diff in reverse.
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+:git-diff: 1
+include::config/diff.adoc[]
+
+SEE ALSO
+--------
+`diff`(1),
+linkgit:git-difftool[1],
+linkgit:git-log[1],
+linkgit:gitdiffcore[7],
+linkgit:git-format-patch[1],
+linkgit:git-apply[1],
+linkgit:git-show[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-difftool.adoc b/git-difftool.adoc
new file mode 100644
index 0000000..d596205
--- /dev/null
+++ b/git-difftool.adoc
@@ -0,0 +1,139 @@
+git-difftool(1)
+===============
+
+NAME
+----
+git-difftool - Show changes using common diff tools
+
+SYNOPSIS
+--------
+[verse]
+'git difftool' [<options>] [<commit> [<commit>]] [--] [<path>...]
+
+DESCRIPTION
+-----------
+'git difftool' is a Git command that allows you to compare and edit files
+between revisions using common diff tools. 'git difftool' is a frontend
+to 'git diff' and accepts the same options and arguments. See
+linkgit:git-diff[1].
+
+OPTIONS
+-------
+-d::
+--dir-diff::
+ Copy the modified files to a temporary location and perform
+ a directory diff on them. This mode never prompts before
+ launching the diff tool.
+
+-y::
+--no-prompt::
+ Do not prompt before launching a diff tool.
+
+--prompt::
+ Prompt before each invocation of the diff tool.
+ This is the default behaviour; the option is provided to
+ override any configuration settings.
+
+--rotate-to=<file>::
+ Start showing the diff for the given path,
+ the paths before it will move to the end and output.
+
+--skip-to=<file>::
+ Start showing the diff for the given path, skipping all
+ the paths before it.
+
+-t <tool>::
+--tool=<tool>::
+ Use the diff tool specified by <tool>. Valid values include
+ emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help`
+ for the list of valid <tool> settings.
++
+If a diff tool is not specified, 'git difftool'
+will use the configuration variable `diff.tool`. If the
+configuration variable `diff.tool` is not set, 'git difftool'
+will pick a suitable default.
++
+You can explicitly provide a full path to the tool by setting the
+configuration variable `difftool.<tool>.path`. For example, you
+can configure the absolute path to kdiff3 by setting
+`difftool.kdiff3.path`. Otherwise, 'git difftool' assumes the
+tool is available in PATH.
++
+Instead of running one of the known diff tools,
+'git difftool' can be customized to run an alternative program
+by specifying the command line to invoke in a configuration
+variable `difftool.<tool>.cmd`.
++
+When 'git difftool' is invoked with this tool (either through the
+`-t` or `--tool` option or the `diff.tool` configuration variable)
+the configured command line will be invoked with the following
+variables available: `$LOCAL` is set to the name of the temporary
+file containing the contents of the diff pre-image and `$REMOTE`
+is set to the name of the temporary file containing the contents
+of the diff post-image. `$MERGED` is the name of the file which is
+being compared. `$BASE` is provided for compatibility
+with custom merge tool commands and has the same value as `$MERGED`.
+
+--tool-help::
+ Print a list of diff tools that may be used with `--tool`.
+
+--[no-]symlinks::
+ 'git difftool''s default behavior is to create symlinks to the
+ working tree when run in `--dir-diff` mode and the right-hand
+ side of the comparison yields the same content as the file in
+ the working tree.
++
+Specifying `--no-symlinks` instructs 'git difftool' to create copies
+instead. `--no-symlinks` is the default on Windows.
+
+-x <command>::
+--extcmd=<command>::
+ Specify a custom command for viewing diffs.
+ 'git-difftool' ignores the configured defaults and runs
+ `<command> $LOCAL $REMOTE` when this option is specified.
+ Additionally, `$BASE` is set in the environment.
+
+-g::
+--[no-]gui::
+ When 'git-difftool' is invoked with the `-g` or `--gui` option
+ the default diff tool will be read from the configured
+ `diff.guitool` variable instead of `diff.tool`. This may be
+ selected automatically using the configuration variable
+ `difftool.guiDefault`. The `--no-gui` option can be used to
+ override these settings. If `diff.guitool` is not set, we will
+ fallback in the order of `merge.guitool`, `diff.tool`,
+ `merge.tool` until a tool is found.
+
+--[no-]trust-exit-code::
+ Errors reported by the diff tool are ignored by default.
+ Use `--trust-exit-code` to make 'git-difftool' exit when an
+ invoked diff tool returns a non-zero exit code.
++
+'git-difftool' will forward the exit code of the invoked tool when
+`--trust-exit-code` is used.
+
+See linkgit:git-diff[1] for the full list of supported options.
+
+CONFIGURATION
+-------------
+'git difftool' falls back to 'git mergetool' config variables when the
+difftool equivalents have not been defined.
+
+include::includes/cmd-config-section-rest.adoc[]
+
+include::config/difftool.adoc[]
+
+SEE ALSO
+--------
+linkgit:git-diff[1]::
+ Show changes between commits, commit and working tree, etc
+
+linkgit:git-mergetool[1]::
+ Run merge conflict resolution tools to resolve merge conflicts
+
+linkgit:git-config[1]::
+ Get and set repository or global options
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-fast-export.adoc b/git-fast-export.adoc
new file mode 100644
index 0000000..752e4b9
--- /dev/null
+++ b/git-fast-export.adoc
@@ -0,0 +1,284 @@
+git-fast-export(1)
+==================
+
+NAME
+----
+git-fast-export - Git data exporter
+
+
+SYNOPSIS
+--------
+[verse]
+'git fast-export' [<options>] | 'git fast-import'
+
+DESCRIPTION
+-----------
+This program dumps the given revisions in a form suitable to be piped
+into 'git fast-import'.
+
+You can use it as a human-readable bundle replacement (see
+linkgit:git-bundle[1]), or as a format that can be edited before being
+fed to 'git fast-import' in order to do history rewrites (an ability
+relied on by tools like 'git filter-repo').
+
+OPTIONS
+-------
+--progress=<n>::
+ Insert 'progress' statements every <n> objects, to be shown by
+ 'git fast-import' during import.
+
+--signed-tags=(verbatim|warn|warn-strip|strip|abort)::
+ Specify how to handle signed tags. Since any transformation
+ after the export can change the tag names (which can also happen
+ when excluding revisions) the signatures will not match.
++
+When asking to 'abort' (which is the default), this program will die
+when encountering a signed tag. With 'strip', the tags will silently
+be made unsigned, with 'warn-strip' they will be made unsigned but a
+warning will be displayed, with 'verbatim', they will be silently
+exported and with 'warn', they will be exported, but you will see a
+warning.
+
+--tag-of-filtered-object=(abort|drop|rewrite)::
+ Specify how to handle tags whose tagged object is filtered out.
+ Since revisions and files to export can be limited by path,
+ tagged objects may be filtered completely.
++
+When asking to 'abort' (which is the default), this program will die
+when encountering such a tag. With 'drop' it will omit such tags from
+the output. With 'rewrite', if the tagged object is a commit, it will
+rewrite the tag to tag an ancestor commit (via parent rewriting; see
+linkgit:git-rev-list[1]).
+
+-M::
+-C::
+ Perform move and/or copy detection, as described in the
+ linkgit:git-diff[1] manual page, and use it to generate
+ rename and copy commands in the output dump.
++
+Note that earlier versions of this command did not complain and
+produced incorrect results if you gave these options.
+
+--export-marks=<file>::
+ Dumps the internal marks table to <file> when complete.
+ Marks are written one per line as `:markid SHA-1`. Only marks
+ for revisions are dumped; marks for blobs are ignored.
+ Backends can use this file to validate imports after they
+ have been completed, or to save the marks table across
+ incremental runs. As <file> is only opened and truncated
+ at completion, the same path can also be safely given to
+ --import-marks.
+ The file will not be written if no new object has been
+ marked/exported.
+
+--import-marks=<file>::
+ Before processing any input, load the marks specified in
+ <file>. The input file must exist, must be readable, and
+ must use the same format as produced by --export-marks.
+
+--mark-tags::
+ In addition to labelling blobs and commits with mark ids, also
+ label tags. This is useful in conjunction with
+ `--export-marks` and `--import-marks`, and is also useful (and
+ necessary) for exporting of nested tags. It does not hurt
+ other cases and would be the default, but many fast-import
+ frontends are not prepared to accept tags with mark
+ identifiers.
++
+Any commits (or tags) that have already been marked will not be
+exported again. If the backend uses a similar --import-marks file,
+this allows for incremental bidirectional exporting of the repository
+by keeping the marks the same across runs.
+
+--fake-missing-tagger::
+ Some old repositories have tags without a tagger. The
+ fast-import protocol was pretty strict about that, and did not
+ allow that. So fake a tagger to be able to fast-import the
+ output.
+
+--use-done-feature::
+ Start the stream with a 'feature done' stanza, and terminate
+ it with a 'done' command.
+
+--no-data::
+ Skip output of blob objects and instead refer to blobs via
+ their original SHA-1 hash. This is useful when rewriting the
+ directory structure or history of a repository without
+ touching the contents of individual files. Note that the
+ resulting stream can only be used by a repository which
+ already contains the necessary objects.
+
+--full-tree::
+ This option will cause fast-export to issue a "deleteall"
+ directive for each commit followed by a full list of all files
+ in the commit (as opposed to just listing the files which are
+ different from the commit's first parent).
+
+--anonymize::
+ Anonymize the contents of the repository while still retaining
+ the shape of the history and stored tree. See the section on
+ `ANONYMIZING` below.
+
+--anonymize-map=<from>[:<to>]::
+ Convert token `<from>` to `<to>` in the anonymized output. If
+ `<to>` is omitted, map `<from>` to itself (i.e., do not
+ anonymize it). See the section on `ANONYMIZING` below.
+
+--reference-excluded-parents::
+ By default, running a command such as `git fast-export
+ master~5..master` will not include the commit master{tilde}5
+ and will make master{tilde}4 no longer have master{tilde}5 as
+ a parent (though both the old master{tilde}4 and new
+ master{tilde}4 will have all the same files). Use
+ --reference-excluded-parents to instead have the stream
+ refer to commits in the excluded range of history by their
+ sha1sum. Note that the resulting stream can only be used by a
+ repository which already contains the necessary parent
+ commits.
+
+--show-original-ids::
+ Add an extra directive to the output for commits and blobs,
+ `original-oid <SHA1SUM>`. While such directives will likely be
+ ignored by importers such as git-fast-import, it may be useful
+ for intermediary filters (e.g. for rewriting commit messages
+ which refer to older commits, or for stripping blobs by id).
+
+--reencode=(yes|no|abort)::
+ Specify how to handle `encoding` header in commit objects. When
+ asking to 'abort' (which is the default), this program will die
+ when encountering such a commit object. With 'yes', the commit
+ message will be re-encoded into UTF-8. With 'no', the original
+ encoding will be preserved.
+
+--refspec::
+ Apply the specified refspec to each ref exported. Multiple of them can
+ be specified.
+
+[<git-rev-list-args>...]::
+ A list of arguments, acceptable to 'git rev-parse' and
+ 'git rev-list', that specifies the specific objects and references
+ to export. For example, `master~10..master` causes the
+ current master reference to be exported along with all objects
+ added since its 10th ancestor commit and (unless the
+ --reference-excluded-parents option is specified) all files
+ common to master{tilde}9 and master{tilde}10.
+
+EXAMPLES
+--------
+
+-------------------------------------------------------------------
+$ git fast-export --all | (cd /empty/repository && git fast-import)
+-------------------------------------------------------------------
+
+This will export the whole repository and import it into the existing
+empty repository. Except for reencoding commits that are not in
+UTF-8, it would be a one-to-one mirror.
+
+-----------------------------------------------------
+$ git fast-export master~5..master |
+ sed "s|refs/heads/master|refs/heads/other|" |
+ git fast-import
+-----------------------------------------------------
+
+This makes a new branch called 'other' from 'master~5..master'
+(i.e. if 'master' has linear history, it will take the last 5 commits).
+
+Note that this assumes that none of the blobs and commit messages
+referenced by that revision range contains the string
+'refs/heads/master'.
+
+
+ANONYMIZING
+-----------
+
+If the `--anonymize` option is given, git will attempt to remove all
+identifying information from the repository while still retaining enough
+of the original tree and history patterns to reproduce some bugs. The
+goal is that a git bug which is found on a private repository will
+persist in the anonymized repository, and the latter can be shared with
+git developers to help solve the bug.
+
+With this option, git will replace all refnames, paths, blob contents,
+commit and tag messages, names, and email addresses in the output with
+anonymized data. Two instances of the same string will be replaced
+equivalently (e.g., two commits with the same author will have the same
+anonymized author in the output, but bear no resemblance to the original
+author string). The relationship between commits, branches, and tags is
+retained, as well as the commit timestamps (but the commit messages and
+refnames bear no resemblance to the originals). The relative makeup of
+the tree is retained (e.g., if you have a root tree with 10 files and 3
+trees, so will the output), but their names and the contents of the
+files will be replaced.
+
+If you think you have found a git bug, you can start by exporting an
+anonymized stream of the whole repository:
+
+---------------------------------------------------
+$ git fast-export --anonymize --all >anon-stream
+---------------------------------------------------
+
+Then confirm that the bug persists in a repository created from that
+stream (many bugs will not, as they really do depend on the exact
+repository contents):
+
+---------------------------------------------------
+$ git init anon-repo
+$ cd anon-repo
+$ git fast-import <../anon-stream
+$ ... test your bug ...
+---------------------------------------------------
+
+If the anonymized repository shows the bug, it may be worth sharing
+`anon-stream` along with a regular bug report. Note that the anonymized
+stream compresses very well, so gzipping it is encouraged. If you want
+to examine the stream to see that it does not contain any private data,
+you can peruse it directly before sending. You may also want to try:
+
+---------------------------------------------------
+$ perl -pe 's/\d+/X/g' <anon-stream | sort -u | less
+---------------------------------------------------
+
+which shows all of the unique lines (with numbers converted to "X", to
+collapse "User 0", "User 1", etc into "User X"). This produces a much
+smaller output, and it is usually easy to quickly confirm that there is
+no private data in the stream.
+
+Reproducing some bugs may require referencing particular commits or
+paths, which becomes challenging after refnames and paths have been
+anonymized. You can ask for a particular token to be left as-is or
+mapped to a new value. For example, if you have a bug which reproduces
+with `git rev-list sensitive -- secret.c`, you can run:
+
+---------------------------------------------------
+$ git fast-export --anonymize --all \
+ --anonymize-map=sensitive:foo \
+ --anonymize-map=secret.c:bar.c \
+ >stream
+---------------------------------------------------
+
+After importing the stream, you can then run `git rev-list foo -- bar.c`
+in the anonymized repository.
+
+Note that paths and refnames are split into tokens at slash boundaries.
+The command above would anonymize `subdir/secret.c` as something like
+`path123/bar.c`; you could then search for `bar.c` in the anonymized
+repository to determine the final pathname.
+
+To make referencing the final pathname simpler, you can map each path
+component; so if you also anonymize `subdir` to `publicdir`, then the
+final pathname would be `publicdir/bar.c`.
+
+LIMITATIONS
+-----------
+
+Since 'git fast-import' cannot tag trees, you will not be
+able to export the linux.git repository completely, as it contains
+a tag referencing a tree instead of a commit.
+
+SEE ALSO
+--------
+linkgit:git-fast-import[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-fast-import.adoc b/git-fast-import.adoc
new file mode 100644
index 0000000..58a2eaa
--- /dev/null
+++ b/git-fast-import.adoc
@@ -0,0 +1,1591 @@
+git-fast-import(1)
+==================
+
+NAME
+----
+git-fast-import - Backend for fast Git data importers
+
+
+SYNOPSIS
+--------
+[verse]
+frontend | 'git fast-import' [<options>]
+
+DESCRIPTION
+-----------
+This program is usually not what the end user wants to run directly.
+Most end users want to use one of the existing frontend programs,
+which parses a specific type of foreign source and feeds the contents
+stored there to 'git fast-import'.
+
+fast-import reads a mixed command/data stream from standard input and
+writes one or more packfiles directly into the current repository.
+When EOF is received on standard input, fast import writes out
+updated branch and tag refs, fully updating the current repository
+with the newly imported data.
+
+The fast-import backend itself can import into an empty repository (one that
+has already been initialized by 'git init') or incrementally
+update an existing populated repository. Whether or not incremental
+imports are supported from a particular foreign source depends on
+the frontend program in use.
+
+
+OPTIONS
+-------
+
+--force::
+ Force updating modified existing branches, even if doing
+ so would cause commits to be lost (as the new commit does
+ not contain the old commit).
+
+--quiet::
+ Disable the output shown by --stats, making fast-import usually
+ be silent when it is successful. However, if the import stream
+ has directives intended to show user output (e.g. `progress`
+ directives), the corresponding messages will still be shown.
+
+--stats::
+ Display some basic statistics about the objects fast-import has
+ created, the packfiles they were stored into, and the
+ memory used by fast-import during this run. Showing this output
+ is currently the default, but can be disabled with --quiet.
+
+--allow-unsafe-features::
+ Many command-line options can be provided as part of the
+ fast-import stream itself by using the `feature` or `option`
+ commands. However, some of these options are unsafe (e.g.,
+ allowing fast-import to access the filesystem outside of the
+ repository). These options are disabled by default, but can be
+ allowed by providing this option on the command line. This
+ currently impacts only the `export-marks`, `import-marks`, and
+ `import-marks-if-exists` feature commands.
++
+ Only enable this option if you trust the program generating the
+ fast-import stream! This option is enabled automatically for
+ remote-helpers that use the `import` capability, as they are
+ already trusted to run their own code.
+
+Options for Frontends
+~~~~~~~~~~~~~~~~~~~~~
+
+--cat-blob-fd=<fd>::
+ Write responses to `get-mark`, `cat-blob`, and `ls` queries to the
+ file descriptor <fd> instead of `stdout`. Allows `progress`
+ output intended for the end-user to be separated from other
+ output.
+
+--date-format=<fmt>::
+ Specify the type of dates the frontend will supply to
+ fast-import within `author`, `committer` and `tagger` commands.
+ See ``Date Formats'' below for details about which formats
+ are supported, and their syntax.
+
+--done::
+ Terminate with error if there is no `done` command at the end of
+ the stream. This option might be useful for detecting errors
+ that cause the frontend to terminate before it has started to
+ write a stream.
+
+Locations of Marks Files
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+--export-marks=<file>::
+ Dumps the internal marks table to <file> when complete.
+ Marks are written one per line as `:markid SHA-1`.
+ Frontends can use this file to validate imports after they
+ have been completed, or to save the marks table across
+ incremental runs. As <file> is only opened and truncated
+ at checkpoint (or completion) the same path can also be
+ safely given to --import-marks.
+
+--import-marks=<file>::
+ Before processing any input, load the marks specified in
+ <file>. The input file must exist, must be readable, and
+ must use the same format as produced by --export-marks.
+ Multiple options may be supplied to import more than one
+ set of marks. If a mark is defined to different values,
+ the last file wins.
+
+--import-marks-if-exists=<file>::
+ Like --import-marks but instead of erroring out, silently
+ skips the file if it does not exist.
+
+--[no-]relative-marks::
+ After specifying --relative-marks the paths specified
+ with --import-marks= and --export-marks= are relative
+ to an internal directory in the current repository.
+ In git-fast-import this means that the paths are relative
+ to the .git/info/fast-import directory. However, other
+ importers may use a different location.
++
+Relative and non-relative marks may be combined by interweaving
+--(no-)-relative-marks with the --(import|export)-marks= options.
+
+Submodule Rewriting
+~~~~~~~~~~~~~~~~~~~
+
+--rewrite-submodules-from=<name>:<file>::
+--rewrite-submodules-to=<name>:<file>::
+ Rewrite the object IDs for the submodule specified by <name> from the values
+ used in the from <file> to those used in the to <file>. The from marks should
+ have been created by `git fast-export`, and the to marks should have been
+ created by `git fast-import` when importing that same submodule.
++
+<name> may be any arbitrary string not containing a colon character, but the
+same value must be used with both options when specifying corresponding marks.
+Multiple submodules may be specified with different values for <name>. It is an
+error not to use these options in corresponding pairs.
++
+These options are primarily useful when converting a repository from one hash
+algorithm to another; without them, fast-import will fail if it encounters a
+submodule because it has no way of writing the object ID into the new hash
+algorithm.
+
+Performance and Compression Tuning
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+--active-branches=<n>::
+ Maximum number of branches to maintain active at once.
+ See ``Memory Utilization'' below for details. Default is 5.
+
+--big-file-threshold=<n>::
+ Maximum size of a blob that fast-import will attempt to
+ create a delta for, expressed in bytes. The default is 512m
+ (512 MiB). Some importers may wish to lower this on systems
+ with constrained memory.
+
+--depth=<n>::
+ Maximum delta depth, for blob and tree deltification.
+ Default is 50.
+
+--export-pack-edges=<file>::
+ After creating a packfile, print a line of data to
+ <file> listing the filename of the packfile and the last
+ commit on each branch that was written to that packfile.
+ This information may be useful after importing projects
+ whose total object set exceeds the 4 GiB packfile limit,
+ as these commits can be used as edge points during calls
+ to 'git pack-objects'.
+
+--max-pack-size=<n>::
+ Maximum size of each output packfile.
+ The default is unlimited.
+
+fastimport.unpackLimit::
+ See linkgit:git-config[1]
+
+PERFORMANCE
+-----------
+The design of fast-import allows it to import large projects in a minimum
+amount of memory usage and processing time. Assuming the frontend
+is able to keep up with fast-import and feed it a constant stream of data,
+import times for projects holding 10+ years of history and containing
+100,000+ individual commits are generally completed in just 1-2
+hours on quite modest (~$2,000 USD) hardware.
+
+Most bottlenecks appear to be in foreign source data access (the
+source just cannot extract revisions fast enough) or disk IO (fast-import
+writes as fast as the disk will take the data). Imports will run
+faster if the source data is stored on a different drive than the
+destination Git repository (due to less IO contention).
+
+
+DEVELOPMENT COST
+----------------
+A typical frontend for fast-import tends to weigh in at approximately 200
+lines of Perl/Python/Ruby code. Most developers have been able to
+create working importers in just a couple of hours, even though it
+is their first exposure to fast-import, and sometimes even to Git. This is
+an ideal situation, given that most conversion tools are throw-away
+(use once, and never look back).
+
+
+PARALLEL OPERATION
+------------------
+Like 'git push' or 'git fetch', imports handled by fast-import are safe to
+run alongside parallel `git repack -a -d` or `git gc` invocations,
+or any other Git operation (including 'git prune', as loose objects
+are never used by fast-import).
+
+fast-import does not lock the branch or tag refs it is actively importing.
+After the import, during its ref update phase, fast-import tests each
+existing branch ref to verify the update will be a fast-forward
+update (the commit stored in the ref is contained in the new
+history of the commit to be written). If the update is not a
+fast-forward update, fast-import will skip updating that ref and instead
+prints a warning message. fast-import will always attempt to update all
+branch refs, and does not stop on the first failure.
+
+Branch updates can be forced with --force, but it's recommended that
+this only be used on an otherwise quiet repository. Using --force
+is not necessary for an initial import into an empty repository.
+
+
+TECHNICAL DISCUSSION
+--------------------
+fast-import tracks a set of branches in memory. Any branch can be created
+or modified at any point during the import process by sending a
+`commit` command on the input stream. This design allows a frontend
+program to process an unlimited number of branches simultaneously,
+generating commits in the order they are available from the source
+data. It also simplifies the frontend programs considerably.
+
+fast-import does not use or alter the current working directory, or any
+file within it. (It does however update the current Git repository,
+as referenced by `GIT_DIR`.) Therefore an import frontend may use
+the working directory for its own purposes, such as extracting file
+revisions from the foreign source. This ignorance of the working
+directory also allows fast-import to run very quickly, as it does not
+need to perform any costly file update operations when switching
+between branches.
+
+INPUT FORMAT
+------------
+With the exception of raw file data (which Git does not interpret)
+the fast-import input format is text (ASCII) based. This text based
+format simplifies development and debugging of frontend programs,
+especially when a higher level language such as Perl, Python or
+Ruby is being used.
+
+fast-import is very strict about its input. Where we say SP below we mean
+*exactly* one space. Likewise LF means one (and only one) linefeed
+and HT one (and only one) horizontal tab.
+Supplying additional whitespace characters will cause unexpected
+results, such as branch names or file names with leading or trailing
+spaces in their name, or early termination of fast-import when it encounters
+unexpected input.
+
+Stream Comments
+~~~~~~~~~~~~~~~
+To aid in debugging frontends fast-import ignores any line that
+begins with `#` (ASCII pound/hash) up to and including the line
+ending `LF`. A comment line may contain any sequence of bytes
+that does not contain an LF and therefore may be used to include
+any detailed debugging information that might be specific to the
+frontend and useful when inspecting a fast-import data stream.
+
+Date Formats
+~~~~~~~~~~~~
+The following date formats are supported. A frontend should select
+the format it will use for this import by passing the format name
+in the --date-format=<fmt> command-line option.
+
+`raw`::
+ This is the Git native format and is `<time> SP <offutc>`.
+ It is also fast-import's default format, if --date-format was
+ not specified.
++
+The time of the event is specified by `<time>` as the number of
+seconds since the UNIX epoch (midnight, Jan 1, 1970, UTC) and is
+written as an ASCII decimal integer.
++
+The local offset is specified by `<offutc>` as a positive or negative
+offset from UTC. For example EST (which is 5 hours behind UTC)
+would be expressed in `<tz>` by ``-0500'' while UTC is ``+0000''.
+The local offset does not affect `<time>`; it is used only as an
+advisement to help formatting routines display the timestamp.
++
+If the local offset is not available in the source material, use
+``+0000'', or the most common local offset. For example many
+organizations have a CVS repository which has only ever been accessed
+by users who are located in the same location and time zone. In this
+case a reasonable offset from UTC could be assumed.
++
+Unlike the `rfc2822` format, this format is very strict. Any
+variation in formatting will cause fast-import to reject the value,
+and some sanity checks on the numeric values may also be performed.
+
+`raw-permissive`::
+ This is the same as `raw` except that no sanity checks on
+ the numeric epoch and local offset are performed. This can
+ be useful when trying to filter or import an existing history
+ with e.g. bogus timezone values.
+
+`rfc2822`::
+ This is the standard date format as described by RFC 2822.
++
+An example value is ``Tue Feb 6 11:22:18 2007 -0500''. The Git
+parser is accurate, but a little on the lenient side. It is the
+same parser used by 'git am' when applying patches
+received from email.
++
+Some malformed strings may be accepted as valid dates. In some of
+these cases Git will still be able to obtain the correct date from
+the malformed string. There are also some types of malformed
+strings which Git will parse wrong, and yet consider valid.
+Seriously malformed strings will be rejected.
++
+Unlike the `raw` format above, the time zone/UTC offset information
+contained in an RFC 2822 date string is used to adjust the date
+value to UTC prior to storage. Therefore it is important that
+this information be as accurate as possible.
++
+If the source material uses RFC 2822 style dates,
+the frontend should let fast-import handle the parsing and conversion
+(rather than attempting to do it itself) as the Git parser has
+been well tested in the wild.
++
+Frontends should prefer the `raw` format if the source material
+already uses UNIX-epoch format, can be coaxed to give dates in that
+format, or its format is easily convertible to it, as there is no
+ambiguity in parsing.
+
+`now`::
+ Always use the current time and time zone. The literal
+ `now` must always be supplied for `<when>`.
++
+This is a toy format. The current time and time zone of this system
+is always copied into the identity string at the time it is being
+created by fast-import. There is no way to specify a different time or
+time zone.
++
+This particular format is supplied as it's short to implement and
+may be useful to a process that wants to create a new commit
+right now, without needing to use a working directory or
+'git update-index'.
++
+If separate `author` and `committer` commands are used in a `commit`
+the timestamps may not match, as the system clock will be polled
+twice (once for each command). The only way to ensure that both
+author and committer identity information has the same timestamp
+is to omit `author` (thus copying from `committer`) or to use a
+date format other than `now`.
+
+Commands
+~~~~~~~~
+fast-import accepts several commands to update the current repository
+and control the current import process. More detailed discussion
+(with examples) of each command follows later.
+
+`commit`::
+ Creates a new branch or updates an existing branch by
+ creating a new commit and updating the branch to point at
+ the newly created commit.
+
+`tag`::
+ Creates an annotated tag object from an existing commit or
+ branch. Lightweight tags are not supported by this command,
+ as they are not recommended for recording meaningful points
+ in time.
+
+`reset`::
+ Reset an existing branch (or a new branch) to a specific
+ revision. This command must be used to change a branch to
+ a specific revision without making a commit on it.
+
+`blob`::
+ Convert raw file data into a blob, for future use in a
+ `commit` command. This command is optional and is not
+ needed to perform an import.
+
+`alias`::
+ Record that a mark refers to a given object without first
+ creating any new object. Using --import-marks and referring
+ to missing marks will cause fast-import to fail, so aliases
+ can provide a way to set otherwise pruned commits to a valid
+ value (e.g. the nearest non-pruned ancestor).
+
+`checkpoint`::
+ Forces fast-import to close the current packfile, generate its
+ unique SHA-1 checksum and index, and start a new packfile.
+ This command is optional and is not needed to perform
+ an import.
+
+`progress`::
+ Causes fast-import to echo the entire line to its own
+ standard output. This command is optional and is not needed
+ to perform an import.
+
+`done`::
+ Marks the end of the stream. This command is optional
+ unless the `done` feature was requested using the
+ `--done` command-line option or `feature done` command.
+
+`get-mark`::
+ Causes fast-import to print the SHA-1 corresponding to a mark
+ to the file descriptor set with `--cat-blob-fd`, or `stdout` if
+ unspecified.
+
+`cat-blob`::
+ Causes fast-import to print a blob in 'cat-file --batch'
+ format to the file descriptor set with `--cat-blob-fd` or
+ `stdout` if unspecified.
+
+`ls`::
+ Causes fast-import to print a line describing a directory
+ entry in 'ls-tree' format to the file descriptor set with
+ `--cat-blob-fd` or `stdout` if unspecified.
+
+`feature`::
+ Enable the specified feature. This requires that fast-import
+ supports the specified feature, and aborts if it does not.
+
+`option`::
+ Specify any of the options listed under OPTIONS that do not
+ change stream semantic to suit the frontend's needs. This
+ command is optional and is not needed to perform an import.
+
+`commit`
+~~~~~~~~
+Create or update a branch with a new commit, recording one logical
+change to the project.
+
+....
+ 'commit' SP <ref> LF
+ mark?
+ original-oid?
+ ('author' (SP <name>)? SP LT <email> GT SP <when> LF)?
+ 'committer' (SP <name>)? SP LT <email> GT SP <when> LF
+ ('encoding' SP <encoding>)?
+ data
+ ('from' SP <commit-ish> LF)?
+ ('merge' SP <commit-ish> LF)*
+ (filemodify | filedelete | filecopy | filerename | filedeleteall | notemodify)*
+ LF?
+....
+
+where `<ref>` is the name of the branch to make the commit on.
+Typically branch names are prefixed with `refs/heads/` in
+Git, so importing the CVS branch symbol `RELENG-1_0` would use
+`refs/heads/RELENG-1_0` for the value of `<ref>`. The value of
+`<ref>` must be a valid refname in Git. As `LF` is not valid in
+a Git refname, no quoting or escaping syntax is supported here.
+
+A `mark` command may optionally appear, requesting fast-import to save a
+reference to the newly created commit for future use by the frontend
+(see below for format). It is very common for frontends to mark
+every commit they create, thereby allowing future branch creation
+from any imported commit.
+
+The `data` command following `committer` must supply the commit
+message (see below for `data` command syntax). To import an empty
+commit message use a 0 length data. Commit messages are free-form
+and are not interpreted by Git. Currently they must be encoded in
+UTF-8, as fast-import does not permit other encodings to be specified.
+
+Zero or more `filemodify`, `filedelete`, `filecopy`, `filerename`,
+`filedeleteall` and `notemodify` commands
+may be included to update the contents of the branch prior to
+creating the commit. These commands may be supplied in any order.
+However it is recommended that a `filedeleteall` command precede
+all `filemodify`, `filecopy`, `filerename` and `notemodify` commands in
+the same commit, as `filedeleteall` wipes the branch clean (see below).
+
+The `LF` after the command is optional (it used to be required). Note
+that for reasons of backward compatibility, if the commit ends with a
+`data` command (i.e. it has no `from`, `merge`, `filemodify`,
+`filedelete`, `filecopy`, `filerename`, `filedeleteall` or
+`notemodify` commands) then two `LF` commands may appear at the end of
+the command instead of just one.
+
+`author`
+^^^^^^^^
+An `author` command may optionally appear, if the author information
+might differ from the committer information. If `author` is omitted
+then fast-import will automatically use the committer's information for
+the author portion of the commit. See below for a description of
+the fields in `author`, as they are identical to `committer`.
+
+`committer`
+^^^^^^^^^^^
+The `committer` command indicates who made this commit, and when
+they made it.
+
+Here `<name>` is the person's display name (for example
+``Com M Itter'') and `<email>` is the person's email address
+(``\cm@example.com''). `LT` and `GT` are the literal less-than (\x3c)
+and greater-than (\x3e) symbols. These are required to delimit
+the email address from the other fields in the line. Note that
+`<name>` and `<email>` are free-form and may contain any sequence
+of bytes, except `LT`, `GT` and `LF`. `<name>` is typically UTF-8 encoded.
+
+The time of the change is specified by `<when>` using the date format
+that was selected by the --date-format=<fmt> command-line option.
+See ``Date Formats'' above for the set of supported formats, and
+their syntax.
+
+`encoding`
+^^^^^^^^^^
+The optional `encoding` command indicates the encoding of the commit
+message. Most commits are UTF-8 and the encoding is omitted, but this
+allows importing commit messages into git without first reencoding them.
+
+`from`
+^^^^^^
+The `from` command is used to specify the commit to initialize
+this branch from. This revision will be the first ancestor of the
+new commit. The state of the tree built at this commit will begin
+with the state at the `from` commit, and be altered by the content
+modifications in this commit.
+
+Omitting the `from` command in the first commit of a new branch
+will cause fast-import to create that commit with no ancestor. This
+tends to be desired only for the initial commit of a project.
+If the frontend creates all files from scratch when making a new
+branch, a `merge` command may be used instead of `from` to start
+the commit with an empty tree.
+Omitting the `from` command on existing branches is usually desired,
+as the current commit on that branch is automatically assumed to
+be the first ancestor of the new commit.
+
+As `LF` is not valid in a Git refname or SHA-1 expression, no
+quoting or escaping syntax is supported within `<commit-ish>`.
+
+Here `<commit-ish>` is any of the following:
+
+* The name of an existing branch already in fast-import's internal branch
+ table. If fast-import doesn't know the name, it's treated as a SHA-1
+ expression.
+
+* A mark reference, `:<idnum>`, where `<idnum>` is the mark number.
++
+The reason fast-import uses `:` to denote a mark reference is this character
+is not legal in a Git branch name. The leading `:` makes it easy
+to distinguish between the mark 42 (`:42`) and the branch 42 (`42`
+or `refs/heads/42`), or an abbreviated SHA-1 which happened to
+consist only of base-10 digits.
++
+Marks must be declared (via `mark`) before they can be used.
+
+* A complete 40 byte or abbreviated commit SHA-1 in hex.
+
+* Any valid Git SHA-1 expression that resolves to a commit. See
+ ``SPECIFYING REVISIONS'' in linkgit:gitrevisions[7] for details.
+
+* The special null SHA-1 (40 zeros) specifies that the branch is to be
+ removed.
+
+The special case of restarting an incremental import from the
+current branch value should be written as:
+----
+ from refs/heads/branch^0
+----
+The `^0` suffix is necessary as fast-import does not permit a branch to
+start from itself, and the branch is created in memory before the
+`from` command is even read from the input. Adding `^0` will force
+fast-import to resolve the commit through Git's revision parsing library,
+rather than its internal branch table, thereby loading in the
+existing value of the branch.
+
+`merge`
+^^^^^^^
+Includes one additional ancestor commit. The additional ancestry
+link does not change the way the tree state is built at this commit.
+If the `from` command is
+omitted when creating a new branch, the first `merge` commit will be
+the first ancestor of the current commit, and the branch will start
+out with no files. An unlimited number of `merge` commands per
+commit are permitted by fast-import, thereby establishing an n-way merge.
+
+Here `<commit-ish>` is any of the commit specification expressions
+also accepted by `from` (see above).
+
+`filemodify`
+^^^^^^^^^^^^
+Included in a `commit` command to add a new file or change the
+content of an existing file. This command has two different means
+of specifying the content of the file.
+
+External data format::
+ The data content for the file was already supplied by a prior
+ `blob` command. The frontend just needs to connect it.
++
+....
+ 'M' SP <mode> SP <dataref> SP <path> LF
+....
++
+Here usually `<dataref>` must be either a mark reference (`:<idnum>`)
+set by a prior `blob` command, or a full 40-byte SHA-1 of an
+existing Git blob object. If `<mode>` is `040000`` then
+`<dataref>` must be the full 40-byte SHA-1 of an existing
+Git tree object or a mark reference set with `--import-marks`.
+
+Inline data format::
+ The data content for the file has not been supplied yet.
+ The frontend wants to supply it as part of this modify
+ command.
++
+....
+ 'M' SP <mode> SP 'inline' SP <path> LF
+ data
+....
++
+See below for a detailed description of the `data` command.
+
+In both formats `<mode>` is the type of file entry, specified
+in octal. Git only supports the following modes:
+
+* `100644` or `644`: A normal (not-executable) file. The majority
+ of files in most projects use this mode. If in doubt, this is
+ what you want.
+* `100755` or `755`: A normal, but executable, file.
+* `120000`: A symlink, the content of the file will be the link target.
+* `160000`: A gitlink, SHA-1 of the object refers to a commit in
+ another repository. Git links can only be specified either by SHA or through
+ a commit mark. They are used to implement submodules.
+* `040000`: A subdirectory. Subdirectories can only be specified by
+ SHA or through a tree mark set with `--import-marks`.
+
+In both formats `<path>` is the complete path of the file to be added
+(if not already existing) or modified (if already existing).
+
+A `<path>` can be written as unquoted bytes or a C-style quoted string.
+
+When a `<path>` does not start with a double quote (`"`), it is an
+unquoted string and is parsed as literal bytes without any escape
+sequences. However, if the filename contains `LF` or starts with double
+quote, it cannot be represented as an unquoted string and must be
+quoted. Additionally, the source `<path>` in `filecopy` or `filerename`
+must be quoted if it contains SP.
+
+When a `<path>` starts with a double quote (`"`), it is a C-style quoted
+string, where the complete filename is enclosed in a pair of double
+quotes and escape sequences are used. Certain characters must be escaped
+by preceding them with a backslash: `LF` is written as `\n`, backslash
+as `\\`, and double quote as `\"`. Some characters may optionally be
+written with escape sequences: `\a` for bell, `\b` for backspace, `\f`
+for form feed, `\n` for line feed, `\r` for carriage return, `\t` for
+horizontal tab, and `\v` for vertical tab. Any byte can be written with
+3-digit octal codes (e.g., `\033`). All filenames can be represented as
+quoted strings.
+
+A `<path>` must use UNIX-style directory separators (forward slash `/`)
+and its value must be in canonical form. That is it must not:
+
+* contain an empty directory component (e.g. `foo//bar` is invalid),
+* end with a directory separator (e.g. `foo/` is invalid),
+* start with a directory separator (e.g. `/foo` is invalid),
+* contain the special component `.` or `..` (e.g. `foo/./bar` and
+ `foo/../bar` are invalid).
+
+The root of the tree can be represented by an empty string as `<path>`.
+
+`<path>` cannot contain NUL, either literally or escaped as `\000`.
+It is recommended that `<path>` always be encoded using UTF-8.
+
+`filedelete`
+^^^^^^^^^^^^
+Included in a `commit` command to remove a file or recursively
+delete an entire directory from the branch. If the file or directory
+removal makes its parent directory empty, the parent directory will
+be automatically removed too. This cascades up the tree until the
+first non-empty directory or the root is reached.
+
+....
+ 'D' SP <path> LF
+....
+
+here `<path>` is the complete path of the file or subdirectory to
+be removed from the branch.
+See `filemodify` above for a detailed description of `<path>`.
+
+`filecopy`
+^^^^^^^^^^
+Recursively copies an existing file or subdirectory to a different
+location within the branch. The existing file or directory must
+exist. If the destination exists it will be completely replaced
+by the content copied from the source.
+
+....
+ 'C' SP <path> SP <path> LF
+....
+
+here the first `<path>` is the source location and the second
+`<path>` is the destination. See `filemodify` above for a detailed
+description of what `<path>` may look like. To use a source path
+that contains SP the path must be quoted.
+
+A `filecopy` command takes effect immediately. Once the source
+location has been copied to the destination any future commands
+applied to the source location will not impact the destination of
+the copy.
+
+`filerename`
+^^^^^^^^^^^^
+Renames an existing file or subdirectory to a different location
+within the branch. The existing file or directory must exist. If
+the destination exists it will be replaced by the source directory.
+
+....
+ 'R' SP <path> SP <path> LF
+....
+
+here the first `<path>` is the source location and the second
+`<path>` is the destination. See `filemodify` above for a detailed
+description of what `<path>` may look like. To use a source path
+that contains SP the path must be quoted.
+
+A `filerename` command takes effect immediately. Once the source
+location has been renamed to the destination any future commands
+applied to the source location will create new files there and not
+impact the destination of the rename.
+
+Note that a `filerename` is the same as a `filecopy` followed by a
+`filedelete` of the source location. There is a slight performance
+advantage to using `filerename`, but the advantage is so small
+that it is never worth trying to convert a delete/add pair in
+source material into a rename for fast-import. This `filerename`
+command is provided just to simplify frontends that already have
+rename information and don't want bother with decomposing it into a
+`filecopy` followed by a `filedelete`.
+
+`filedeleteall`
+^^^^^^^^^^^^^^^
+Included in a `commit` command to remove all files (and also all
+directories) from the branch. This command resets the internal
+branch structure to have no files in it, allowing the frontend
+to subsequently add all interesting files from scratch.
+
+....
+ 'deleteall' LF
+....
+
+This command is extremely useful if the frontend does not know
+(or does not care to know) what files are currently on the branch,
+and therefore cannot generate the proper `filedelete` commands to
+update the content.
+
+Issuing a `filedeleteall` followed by the needed `filemodify`
+commands to set the correct content will produce the same results
+as sending only the needed `filemodify` and `filedelete` commands.
+The `filedeleteall` approach may however require fast-import to use slightly
+more memory per active branch (less than 1 MiB for even most large
+projects); so frontends that can easily obtain only the affected
+paths for a commit are encouraged to do so.
+
+`notemodify`
+^^^^^^^^^^^^
+Included in a `commit` `<notes-ref>` command to add a new note
+annotating a `<commit-ish>` or change this annotation contents.
+Internally it is similar to filemodify 100644 on `<commit-ish>`
+path (maybe split into subdirectories). It's not advised to
+use any other commands to write to the `<notes-ref>` tree except
+`filedeleteall` to delete all existing notes in this tree.
+This command has two different means of specifying the content
+of the note.
+
+External data format::
+ The data content for the note was already supplied by a prior
+ `blob` command. The frontend just needs to connect it to the
+ commit that is to be annotated.
++
+....
+ 'N' SP <dataref> SP <commit-ish> LF
+....
++
+Here `<dataref>` can be either a mark reference (`:<idnum>`)
+set by a prior `blob` command, or a full 40-byte SHA-1 of an
+existing Git blob object.
+
+Inline data format::
+ The data content for the note has not been supplied yet.
+ The frontend wants to supply it as part of this modify
+ command.
++
+....
+ 'N' SP 'inline' SP <commit-ish> LF
+ data
+....
++
+See below for a detailed description of the `data` command.
+
+In both formats `<commit-ish>` is any of the commit specification
+expressions also accepted by `from` (see above).
+
+`mark`
+~~~~~~
+Arranges for fast-import to save a reference to the current object, allowing
+the frontend to recall this object at a future point in time, without
+knowing its SHA-1. Here the current object is the object creation
+command the `mark` command appears within. This can be `commit`,
+`tag`, and `blob`, but `commit` is the most common usage.
+
+....
+ 'mark' SP ':' <idnum> LF
+....
+
+where `<idnum>` is the number assigned by the frontend to this mark.
+The value of `<idnum>` is expressed as an ASCII decimal integer.
+The value 0 is reserved and cannot be used as
+a mark. Only values greater than or equal to 1 may be used as marks.
+
+New marks are created automatically. Existing marks can be moved
+to another object simply by reusing the same `<idnum>` in another
+`mark` command.
+
+`original-oid`
+~~~~~~~~~~~~~~
+Provides the name of the object in the original source control system.
+fast-import will simply ignore this directive, but filter processes
+which operate on and modify the stream before feeding to fast-import
+may have uses for this information
+
+....
+ 'original-oid' SP <object-identifier> LF
+....
+
+where `<object-identifier>` is any string not containing LF.
+
+`tag`
+~~~~~
+Creates an annotated tag referring to a specific commit. To create
+lightweight (non-annotated) tags see the `reset` command below.
+
+....
+ 'tag' SP <name> LF
+ mark?
+ 'from' SP <commit-ish> LF
+ original-oid?
+ 'tagger' (SP <name>)? SP LT <email> GT SP <when> LF
+ data
+....
+
+where `<name>` is the name of the tag to create.
+
+Tag names are automatically prefixed with `refs/tags/` when stored
+in Git, so importing the CVS branch symbol `RELENG-1_0-FINAL` would
+use just `RELENG-1_0-FINAL` for `<name>`, and fast-import will write the
+corresponding ref as `refs/tags/RELENG-1_0-FINAL`.
+
+The value of `<name>` must be a valid refname in Git and therefore
+may contain forward slashes. As `LF` is not valid in a Git refname,
+no quoting or escaping syntax is supported here.
+
+The `from` command is the same as in the `commit` command; see
+above for details.
+
+The `tagger` command uses the same format as `committer` within
+`commit`; again see above for details.
+
+The `data` command following `tagger` must supply the annotated tag
+message (see below for `data` command syntax). To import an empty
+tag message use a 0 length data. Tag messages are free-form and are
+not interpreted by Git. Currently they must be encoded in UTF-8,
+as fast-import does not permit other encodings to be specified.
+
+Signing annotated tags during import from within fast-import is not
+supported. Trying to include your own PGP/GPG signature is not
+recommended, as the frontend does not (easily) have access to the
+complete set of bytes which normally goes into such a signature.
+If signing is required, create lightweight tags from within fast-import with
+`reset`, then create the annotated versions of those tags offline
+with the standard 'git tag' process.
+
+`reset`
+~~~~~~~
+Creates (or recreates) the named branch, optionally starting from
+a specific revision. The reset command allows a frontend to issue
+a new `from` command for an existing branch, or to create a new
+branch from an existing commit without creating a new commit.
+
+....
+ 'reset' SP <ref> LF
+ ('from' SP <commit-ish> LF)?
+ LF?
+....
+
+For a detailed description of `<ref>` and `<commit-ish>` see above
+under `commit` and `from`.
+
+The `LF` after the command is optional (it used to be required).
+
+The `reset` command can also be used to create lightweight
+(non-annotated) tags. For example:
+
+====
+ reset refs/tags/938
+ from :938
+====
+
+would create the lightweight tag `refs/tags/938` referring to
+whatever commit mark `:938` references.
+
+`blob`
+~~~~~~
+Requests writing one file revision to the packfile. The revision
+is not connected to any commit; this connection must be formed in
+a subsequent `commit` command by referencing the blob through an
+assigned mark.
+
+....
+ 'blob' LF
+ mark?
+ original-oid?
+ data
+....
+
+The mark command is optional here as some frontends have chosen
+to generate the Git SHA-1 for the blob on their own, and feed that
+directly to `commit`. This is typically more work than it's worth
+however, as marks are inexpensive to store and easy to use.
+
+`data`
+~~~~~~
+Supplies raw data (for use as blob/file content, commit messages, or
+annotated tag messages) to fast-import. Data can be supplied using an exact
+byte count or delimited with a terminating line. Real frontends
+intended for production-quality conversions should always use the
+exact byte count format, as it is more robust and performs better.
+The delimited format is intended primarily for testing fast-import.
+
+Comment lines appearing within the `<raw>` part of `data` commands
+are always taken to be part of the body of the data and are therefore
+never ignored by fast-import. This makes it safe to import any
+file/message content whose lines might start with `#`.
+
+Exact byte count format::
+ The frontend must specify the number of bytes of data.
++
+....
+ 'data' SP <count> LF
+ <raw> LF?
+....
++
+where `<count>` is the exact number of bytes appearing within
+`<raw>`. The value of `<count>` is expressed as an ASCII decimal
+integer. The `LF` on either side of `<raw>` is not
+included in `<count>` and will not be included in the imported data.
++
+The `LF` after `<raw>` is optional (it used to be required) but
+recommended. Always including it makes debugging a fast-import
+stream easier as the next command always starts in column 0
+of the next line, even if `<raw>` did not end with an `LF`.
+
+Delimited format::
+ A delimiter string is used to mark the end of the data.
+ fast-import will compute the length by searching for the delimiter.
+ This format is primarily useful for testing and is not
+ recommended for real data.
++
+....
+ 'data' SP '<<' <delim> LF
+ <raw> LF
+ <delim> LF
+ LF?
+....
++
+where `<delim>` is the chosen delimiter string. The string `<delim>`
+must not appear on a line by itself within `<raw>`, as otherwise
+fast-import will think the data ends earlier than it really does. The `LF`
+immediately trailing `<raw>` is part of `<raw>`. This is one of
+the limitations of the delimited format, it is impossible to supply
+a data chunk which does not have an LF as its last byte.
++
+The `LF` after `<delim> LF` is optional (it used to be required).
+
+`alias`
+~~~~~~~
+Record that a mark refers to a given object without first creating any
+new object.
+
+....
+ 'alias' LF
+ mark
+ 'to' SP <commit-ish> LF
+ LF?
+....
+
+For a detailed description of `<commit-ish>` see above under `from`.
+
+
+`checkpoint`
+~~~~~~~~~~~~
+Forces fast-import to close the current packfile, start a new one, and to
+save out all current branch refs, tags and marks.
+
+....
+ 'checkpoint' LF
+ LF?
+....
+
+Note that fast-import automatically switches packfiles when the current
+packfile reaches --max-pack-size, or 4 GiB, whichever limit is
+smaller. During an automatic packfile switch fast-import does not update
+the branch refs, tags or marks.
+
+As a `checkpoint` can require a significant amount of CPU time and
+disk IO (to compute the overall pack SHA-1 checksum, generate the
+corresponding index file, and update the refs) it can easily take
+several minutes for a single `checkpoint` command to complete.
+
+Frontends may choose to issue checkpoints during extremely large
+and long running imports, or when they need to allow another Git
+process access to a branch. However given that a 30 GiB Subversion
+repository can be loaded into Git through fast-import in about 3 hours,
+explicit checkpointing may not be necessary.
+
+The `LF` after the command is optional (it used to be required).
+
+`progress`
+~~~~~~~~~~
+Causes fast-import to print the entire `progress` line unmodified to
+its standard output channel (file descriptor 1) when the command is
+processed from the input stream. The command otherwise has no impact
+on the current import, or on any of fast-import's internal state.
+
+....
+ 'progress' SP <any> LF
+ LF?
+....
+
+The `<any>` part of the command may contain any sequence of bytes
+that does not contain `LF`. The `LF` after the command is optional.
+Callers may wish to process the output through a tool such as sed to
+remove the leading part of the line, for example:
+
+====
+ frontend | git fast-import | sed 's/^progress //'
+====
+
+Placing a `progress` command immediately after a `checkpoint` will
+inform the reader when the `checkpoint` has been completed and it
+can safely access the refs that fast-import updated.
+
+`get-mark`
+~~~~~~~~~~
+Causes fast-import to print the SHA-1 corresponding to a mark to
+stdout or to the file descriptor previously arranged with the
+`--cat-blob-fd` argument. The command otherwise has no impact on the
+current import; its purpose is to retrieve SHA-1s that later commits
+might want to refer to in their commit messages.
+
+....
+ 'get-mark' SP ':' <idnum> LF
+....
+
+See ``Responses To Commands'' below for details about how to read
+this output safely.
+
+`cat-blob`
+~~~~~~~~~~
+Causes fast-import to print a blob to a file descriptor previously
+arranged with the `--cat-blob-fd` argument. The command otherwise
+has no impact on the current import; its main purpose is to
+retrieve blobs that may be in fast-import's memory but not
+accessible from the target repository.
+
+....
+ 'cat-blob' SP <dataref> LF
+....
+
+The `<dataref>` can be either a mark reference (`:<idnum>`)
+set previously or a full 40-byte SHA-1 of a Git blob, preexisting or
+ready to be written.
+
+Output uses the same format as `git cat-file --batch`:
+
+====
+ <sha1> SP 'blob' SP <size> LF
+ <contents> LF
+====
+
+This command can be used where a `filemodify` directive can appear,
+allowing it to be used in the middle of a commit. For a `filemodify`
+using an inline directive, it can also appear right before the `data`
+directive.
+
+See ``Responses To Commands'' below for details about how to read
+this output safely.
+
+`ls`
+~~~~
+Prints information about the object at a path to a file descriptor
+previously arranged with the `--cat-blob-fd` argument. This allows
+printing a blob from the active commit (with `cat-blob`) or copying a
+blob or tree from a previous commit for use in the current one (with
+`filemodify`).
+
+The `ls` command can also be used where a `filemodify` directive can
+appear, allowing it to be used in the middle of a commit.
+
+Reading from the active commit::
+ This form can only be used in the middle of a `commit`.
+ The path names a directory entry within fast-import's
+ active commit. The path must be quoted in this case.
++
+....
+ 'ls' SP <path> LF
+....
+
+Reading from a named tree::
+ The `<dataref>` can be a mark reference (`:<idnum>`) or the
+ full 40-byte SHA-1 of a Git tag, commit, or tree object,
+ preexisting or waiting to be written.
+ The path is relative to the top level of the tree
+ named by `<dataref>`.
++
+....
+ 'ls' SP <dataref> SP <path> LF
+....
+
+See `filemodify` above for a detailed description of `<path>`.
+
+Output uses the same format as `git ls-tree <tree> -- <path>`:
+
+====
+ <mode> SP ('blob' | 'tree' | 'commit') SP <dataref> HT <path> LF
+====
+
+The <dataref> represents the blob, tree, or commit object at <path>
+and can be used in later 'get-mark', 'cat-blob', 'filemodify', or
+'ls' commands.
+
+If there is no file or subtree at that path, 'git fast-import' will
+instead report
+
+====
+ missing SP <path> LF
+====
+
+See ``Responses To Commands'' below for details about how to read
+this output safely.
+
+`feature`
+~~~~~~~~~
+Require that fast-import supports the specified feature, or abort if
+it does not.
+
+....
+ 'feature' SP <feature> ('=' <argument>)? LF
+....
+
+The <feature> part of the command may be any one of the following:
+
+date-format::
+export-marks::
+relative-marks::
+no-relative-marks::
+force::
+ Act as though the corresponding command-line option with
+ a leading `--` was passed on the command line
+ (see OPTIONS, above).
+
+import-marks::
+import-marks-if-exists::
+ Like --import-marks except in two respects: first, only one
+ "feature import-marks" or "feature import-marks-if-exists"
+ command is allowed per stream; second, an --import-marks=
+ or --import-marks-if-exists command-line option overrides
+ any of these "feature" commands in the stream; third,
+ "feature import-marks-if-exists" like a corresponding
+ command-line option silently skips a nonexistent file.
+
+get-mark::
+cat-blob::
+ls::
+ Require that the backend support the 'get-mark', 'cat-blob',
+ or 'ls' command respectively.
+ Versions of fast-import not supporting the specified command
+ will exit with a message indicating so.
+ This lets the import error out early with a clear message,
+ rather than wasting time on the early part of an import
+ before the unsupported command is detected.
+
+notes::
+ Require that the backend support the 'notemodify' (N)
+ subcommand to the 'commit' command.
+ Versions of fast-import not supporting notes will exit
+ with a message indicating so.
+
+done::
+ Error out if the stream ends without a 'done' command.
+ Without this feature, errors causing the frontend to end
+ abruptly at a convenient point in the stream can go
+ undetected. This may occur, for example, if an import
+ front end dies in mid-operation without emitting SIGTERM
+ or SIGKILL at its subordinate git fast-import instance.
+
+`option`
+~~~~~~~~
+Processes the specified option so that git fast-import behaves in a
+way that suits the frontend's needs.
+Note that options specified by the frontend are overridden by any
+options the user may specify to git fast-import itself.
+
+....
+ 'option' SP <option> LF
+....
+
+The `<option>` part of the command may contain any of the options
+listed in the OPTIONS section that do not change import semantics,
+without the leading `--` and is treated in the same way.
+
+Option commands must be the first commands on the input (not counting
+feature commands), to give an option command after any non-option
+command is an error.
+
+The following command-line options change import semantics and may therefore
+not be passed as option:
+
+* date-format
+* import-marks
+* export-marks
+* cat-blob-fd
+* force
+
+`done`
+~~~~~~
+If the `done` feature is not in use, treated as if EOF was read.
+This can be used to tell fast-import to finish early.
+
+If the `--done` command-line option or `feature done` command is
+in use, the `done` command is mandatory and marks the end of the
+stream.
+
+RESPONSES TO COMMANDS
+---------------------
+New objects written by fast-import are not available immediately.
+Most fast-import commands have no visible effect until the next
+checkpoint (or completion). The frontend can send commands to
+fill fast-import's input pipe without worrying about how quickly
+they will take effect, which improves performance by simplifying
+scheduling.
+
+For some frontends, though, it is useful to be able to read back
+data from the current repository as it is being updated (for
+example when the source material describes objects in terms of
+patches to be applied to previously imported objects). This can
+be accomplished by connecting the frontend and fast-import via
+bidirectional pipes:
+
+====
+ mkfifo fast-import-output
+ frontend <fast-import-output |
+ git fast-import >fast-import-output
+====
+
+A frontend set up this way can use `progress`, `get-mark`, `ls`, and
+`cat-blob` commands to read information from the import in progress.
+
+To avoid deadlock, such frontends must completely consume any
+pending output from `progress`, `ls`, `get-mark`, and `cat-blob` before
+performing writes to fast-import that might block.
+
+CRASH REPORTS
+-------------
+If fast-import is supplied invalid input it will terminate with a
+non-zero exit status and create a crash report in the top level of
+the Git repository it was importing into. Crash reports contain
+a snapshot of the internal fast-import state as well as the most
+recent commands that lead up to the crash.
+
+All recent commands (including stream comments, file changes and
+progress commands) are shown in the command history within the crash
+report, but raw file data and commit messages are excluded from the
+crash report. This exclusion saves space within the report file
+and reduces the amount of buffering that fast-import must perform
+during execution.
+
+After writing a crash report fast-import will close the current
+packfile and export the marks table. This allows the frontend
+developer to inspect the repository state and resume the import from
+the point where it crashed. The modified branches and tags are not
+updated during a crash, as the import did not complete successfully.
+Branch and tag information can be found in the crash report and
+must be applied manually if the update is needed.
+
+An example crash:
+
+====
+ $ cat >in <<END_OF_INPUT
+ # my very first test commit
+ commit refs/heads/master
+ committer Shawn O. Pearce <spearce> 19283 -0400
+ # who is that guy anyway?
+ data <<EOF
+ this is my commit
+ EOF
+ M 644 inline .gitignore
+ data <<EOF
+ .gitignore
+ EOF
+ M 777 inline bob
+ END_OF_INPUT
+
+ $ git fast-import <in
+ fatal: Corrupt mode: M 777 inline bob
+ fast-import: dumping crash report to .git/fast_import_crash_8434
+
+ $ cat .git/fast_import_crash_8434
+ fast-import crash report:
+ fast-import process: 8434
+ parent process : 1391
+ at Sat Sep 1 00:58:12 2007
+
+ fatal: Corrupt mode: M 777 inline bob
+
+ Most Recent Commands Before Crash
+ ---------------------------------
+ # my very first test commit
+ commit refs/heads/master
+ committer Shawn O. Pearce <spearce> 19283 -0400
+ # who is that guy anyway?
+ data <<EOF
+ M 644 inline .gitignore
+ data <<EOF
+ * M 777 inline bob
+
+ Active Branch LRU
+ -----------------
+ active_branches = 1 cur, 5 max
+
+ pos clock name
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 1) 0 refs/heads/master
+
+ Inactive Branches
+ -----------------
+ refs/heads/master:
+ status : active loaded dirty
+ tip commit : 0000000000000000000000000000000000000000
+ old tree : 0000000000000000000000000000000000000000
+ cur tree : 0000000000000000000000000000000000000000
+ commit clock: 0
+ last pack :
+
+
+ -------------------
+ END OF CRASH REPORT
+====
+
+TIPS AND TRICKS
+---------------
+The following tips and tricks have been collected from various
+users of fast-import, and are offered here as suggestions.
+
+Use One Mark Per Commit
+~~~~~~~~~~~~~~~~~~~~~~~
+When doing a repository conversion, use a unique mark per commit
+(`mark :<n>`) and supply the --export-marks option on the command
+line. fast-import will dump a file which lists every mark and the Git
+object SHA-1 that corresponds to it. If the frontend can tie
+the marks back to the source repository, it is easy to verify the
+accuracy and completeness of the import by comparing each Git
+commit to the corresponding source revision.
+
+Coming from a system such as Perforce or Subversion, this should be
+quite simple, as the fast-import mark can also be the Perforce changeset
+number or the Subversion revision number.
+
+Freely Skip Around Branches
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Don't bother trying to optimize the frontend to stick to one branch
+at a time during an import. Although doing so might be slightly
+faster for fast-import, it tends to increase the complexity of the frontend
+code considerably.
+
+The branch LRU builtin to fast-import tends to behave very well, and the
+cost of activating an inactive branch is so low that bouncing around
+between branches has virtually no impact on import performance.
+
+Handling Renames
+~~~~~~~~~~~~~~~~
+When importing a renamed file or directory, simply delete the old
+name(s) and modify the new name(s) during the corresponding commit.
+Git performs rename detection after-the-fact, rather than explicitly
+during a commit.
+
+Use Tag Fixup Branches
+~~~~~~~~~~~~~~~~~~~~~~
+Some other SCM systems let the user create a tag from multiple
+files which are not from the same commit/changeset. Or to create
+tags which are a subset of the files available in the repository.
+
+Importing these tags as-is in Git is impossible without making at
+least one commit which ``fixes up'' the files to match the content
+of the tag. Use fast-import's `reset` command to reset a dummy branch
+outside of your normal branch space to the base commit for the tag,
+then commit one or more file fixup commits, and finally tag the
+dummy branch.
+
+For example since all normal branches are stored under `refs/heads/`
+name the tag fixup branch `TAG_FIXUP`. This way it is impossible for
+the fixup branch used by the importer to have namespace conflicts
+with real branches imported from the source (the name `TAG_FIXUP`
+is not `refs/heads/TAG_FIXUP`).
+
+When committing fixups, consider using `merge` to connect the
+commit(s) which are supplying file revisions to the fixup branch.
+Doing so will allow tools such as 'git blame' to track
+through the real commit history and properly annotate the source
+files.
+
+After fast-import terminates the frontend will need to do `rm .git/TAG_FIXUP`
+to remove the dummy branch.
+
+Import Now, Repack Later
+~~~~~~~~~~~~~~~~~~~~~~~~
+As soon as fast-import completes the Git repository is completely valid
+and ready for use. Typically this takes only a very short time,
+even for considerably large projects (100,000+ commits).
+
+However repacking the repository is necessary to improve data
+locality and access performance. It can also take hours on extremely
+large projects (especially if -f and a large --window parameter is
+used). Since repacking is safe to run alongside readers and writers,
+run the repack in the background and let it finish when it finishes.
+There is no reason to wait to explore your new Git project!
+
+If you choose to wait for the repack, don't try to run benchmarks
+or performance tests until repacking is completed. fast-import outputs
+suboptimal packfiles that are simply never seen in real use
+situations.
+
+Repacking Historical Data
+~~~~~~~~~~~~~~~~~~~~~~~~~
+If you are repacking very old imported data (e.g. older than the
+last year), consider expending some extra CPU time and supplying
+--window=50 (or higher) when you run 'git repack'.
+This will take longer, but will also produce a smaller packfile.
+You only need to expend the effort once, and everyone using your
+project will benefit from the smaller repository.
+
+Include Some Progress Messages
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Every once in a while have your frontend emit a `progress` message
+to fast-import. The contents of the messages are entirely free-form,
+so one suggestion would be to output the current month and year
+each time the current commit date moves into the next month.
+Your users will feel better knowing how much of the data stream
+has been processed.
+
+
+PACKFILE OPTIMIZATION
+---------------------
+When packing a blob fast-import always attempts to deltify against the last
+blob written. Unless specifically arranged for by the frontend,
+this will probably not be a prior version of the same file, so the
+generated delta will not be the smallest possible. The resulting
+packfile will be compressed, but will not be optimal.
+
+Frontends which have efficient access to all revisions of a
+single file (for example reading an RCS/CVS ,v file) can choose
+to supply all revisions of that file as a sequence of consecutive
+`blob` commands. This allows fast-import to deltify the different file
+revisions against each other, saving space in the final packfile.
+Marks can be used to later identify individual file revisions during
+a sequence of `commit` commands.
+
+The packfile(s) created by fast-import do not encourage good disk access
+patterns. This is caused by fast-import writing the data in the order
+it is received on standard input, while Git typically organizes
+data within packfiles to make the most recent (current tip) data
+appear before historical data. Git also clusters commits together,
+speeding up revision traversal through better cache locality.
+
+For this reason it is strongly recommended that users repack the
+repository with `git repack -a -d` after fast-import completes, allowing
+Git to reorganize the packfiles for faster data access. If blob
+deltas are suboptimal (see above) then also adding the `-f` option
+to force recomputation of all deltas can significantly reduce the
+final packfile size (30-50% smaller can be quite typical).
+
+Instead of running `git repack` you can also run `git gc
+--aggressive`, which will also optimize other things after an import
+(e.g. pack loose refs). As noted in the "AGGRESSIVE" section in
+linkgit:git-gc[1] the `--aggressive` option will find new deltas with
+the `-f` option to linkgit:git-repack[1]. For the reasons elaborated
+on above using `--aggressive` after a fast-import is one of the few
+cases where it's known to be worthwhile.
+
+MEMORY UTILIZATION
+------------------
+There are a number of factors which affect how much memory fast-import
+requires to perform an import. Like critical sections of core
+Git, fast-import uses its own memory allocators to amortize any overheads
+associated with malloc. In practice fast-import tends to amortize any
+malloc overheads to 0, due to its use of large block allocations.
+
+per object
+~~~~~~~~~~
+fast-import maintains an in-memory structure for every object written in
+this execution. On a 32 bit system the structure is 32 bytes,
+on a 64 bit system the structure is 40 bytes (due to the larger
+pointer sizes). Objects in the table are not deallocated until
+fast-import terminates. Importing 2 million objects on a 32 bit system
+will require approximately 64 MiB of memory.
+
+The object table is actually a hashtable keyed on the object name
+(the unique SHA-1). This storage configuration allows fast-import to reuse
+an existing or already written object and avoid writing duplicates
+to the output packfile. Duplicate blobs are surprisingly common
+in an import, typically due to branch merges in the source.
+
+per mark
+~~~~~~~~
+Marks are stored in a sparse array, using 1 pointer (4 bytes or 8
+bytes, depending on pointer size) per mark. Although the array
+is sparse, frontends are still strongly encouraged to use marks
+between 1 and n, where n is the total number of marks required for
+this import.
+
+per branch
+~~~~~~~~~~
+Branches are classified as active and inactive. The memory usage
+of the two classes is significantly different.
+
+Inactive branches are stored in a structure which uses 96 or 120
+bytes (32 bit or 64 bit systems, respectively), plus the length of
+the branch name (typically under 200 bytes), per branch. fast-import will
+easily handle as many as 10,000 inactive branches in under 2 MiB
+of memory.
+
+Active branches have the same overhead as inactive branches, but
+also contain copies of every tree that has been recently modified on
+that branch. If subtree `include` has not been modified since the
+branch became active, its contents will not be loaded into memory,
+but if subtree `src` has been modified by a commit since the branch
+became active, then its contents will be loaded in memory.
+
+As active branches store metadata about the files contained on that
+branch, their in-memory storage size can grow to a considerable size
+(see below).
+
+fast-import automatically moves active branches to inactive status based on
+a simple least-recently-used algorithm. The LRU chain is updated on
+each `commit` command. The maximum number of active branches can be
+increased or decreased on the command line with --active-branches=.
+
+per active tree
+~~~~~~~~~~~~~~~
+Trees (aka directories) use just 12 bytes of memory on top of the
+memory required for their entries (see ``per active file'' below).
+The cost of a tree is virtually 0, as its overhead amortizes out
+over the individual file entries.
+
+per active file entry
+~~~~~~~~~~~~~~~~~~~~~
+Files (and pointers to subtrees) within active trees require 52 or 64
+bytes (32/64 bit platforms) per entry. To conserve space, file and
+tree names are pooled in a common string table, allowing the filename
+``Makefile'' to use just 16 bytes (after including the string header
+overhead) no matter how many times it occurs within the project.
+
+The active branch LRU, when coupled with the filename string pool
+and lazy loading of subtrees, allows fast-import to efficiently import
+projects with 2,000+ branches and 45,114+ files in a very limited
+memory footprint (less than 2.7 MiB per active branch).
+
+SIGNALS
+-------
+Sending *SIGUSR1* to the 'git fast-import' process ends the current
+packfile early, simulating a `checkpoint` command. The impatient
+operator can use this facility to peek at the objects and refs from an
+import in progress, at the cost of some added running time and worse
+compression.
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/fastimport.adoc[]
+
+SEE ALSO
+--------
+linkgit:git-fast-export[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-fetch-pack.adoc b/git-fetch-pack.adoc
new file mode 100644
index 0000000..b522357
--- /dev/null
+++ b/git-fetch-pack.adoc
@@ -0,0 +1,136 @@
+git-fetch-pack(1)
+=================
+
+NAME
+----
+git-fetch-pack - Receive missing objects from another repository
+
+
+SYNOPSIS
+--------
+[verse]
+'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag]
+ [--upload-pack=<git-upload-pack>]
+ [--depth=<n>] [--no-progress]
+ [-v] <repository> [<refs>...]
+
+DESCRIPTION
+-----------
+Usually you would want to use 'git fetch', which is a
+higher level wrapper of this command, instead.
+
+Invokes 'git-upload-pack' on a possibly remote repository
+and asks it to send objects missing from this repository, to
+update the named heads. The list of commits available locally
+is found out by scanning the local refs/ hierarchy and sent to
+'git-upload-pack' running on the other end.
+
+This command degenerates to download everything to complete the
+asked refs from the remote side when the local side does not
+have a common ancestor commit.
+
+
+OPTIONS
+-------
+--all::
+ Fetch all remote refs.
+
+--stdin::
+ Take the list of refs from stdin, one per line. If there
+ are refs specified on the command line in addition to this
+ option, then the refs from stdin are processed after those
+ on the command line.
++
+If `--stateless-rpc` is specified together with this option then
+the list of refs must be in packet format (pkt-line). Each ref must
+be in a separate packet, and the list must end with a flush packet.
+
+-q::
+--quiet::
+ Pass `-q` flag to 'git unpack-objects'; this makes the
+ cloning process less verbose.
+
+-k::
+--keep::
+ Do not invoke 'git unpack-objects' on received data, but
+ create a single packfile out of it instead, and store it
+ in the object database. If provided twice then the pack is
+ locked against repacking.
+
+--thin::
+ Fetch a "thin" pack, which records objects in deltified form based
+ on objects not included in the pack to reduce network traffic.
+
+--include-tag::
+ If the remote side supports it, annotated tags objects will
+ be downloaded on the same connection as the other objects if
+ the object the tag references is downloaded. The caller must
+ otherwise determine the tags this option made available.
+
+--upload-pack=<git-upload-pack>::
+ Use this to specify the path to 'git-upload-pack' on the
+ remote side, if it is not found on your $PATH.
+ Installations of sshd ignores the user's environment
+ setup scripts for login shells (e.g. .bash_profile) and
+ your privately installed git may not be found on the system
+ default $PATH. Another workaround suggested is to set
+ up your $PATH in ".bashrc", but this flag is for people
+ who do not want to pay the overhead for non-interactive
+ shells by having a lean .bashrc file (they set most of
+ the things up in .bash_profile).
+
+--exec=<git-upload-pack>::
+ Same as --upload-pack=<git-upload-pack>.
+
+--depth=<n>::
+ Limit fetching to ancestor-chains not longer than n.
+ 'git-upload-pack' treats the special depth 2147483647 as
+ infinite even if there is an ancestor-chain that long.
+
+--shallow-since=<date>::
+ Deepen or shorten the history of a shallow repository to
+ include all reachable commits after <date>.
+
+--shallow-exclude=<ref>::
+ Deepen or shorten the history of a shallow repository to
+ exclude commits reachable from a specified remote branch or tag.
+ This option can be specified multiple times.
+
+--deepen-relative::
+ Argument --depth specifies the number of commits from the
+ current shallow boundary instead of from the tip of each
+ remote branch history.
+
+--refetch::
+ Skips negotiating commits with the server in order to fetch all matching
+ objects. Use to reapply a new partial clone blob/tree filter.
+
+--no-progress::
+ Do not show the progress.
+
+--check-self-contained-and-connected::
+ Output "connectivity-ok" if the received pack is
+ self-contained and connected.
+
+-v::
+ Run verbosely.
+
+<repository>::
+ The URL to the remote repository.
+
+<refs>...::
+ The remote heads to update from. This is relative to
+ $GIT_DIR (e.g. "HEAD", "refs/heads/master"). When
+ unspecified, update from all heads the remote side has.
++
+If the remote has enabled the options `uploadpack.allowTipSHA1InWant`,
+`uploadpack.allowReachableSHA1InWant`, or `uploadpack.allowAnySHA1InWant`,
+they may alternatively be 40-hex sha1s present on the remote.
+
+SEE ALSO
+--------
+linkgit:git-fetch[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-fetch.adoc b/git-fetch.adoc
new file mode 100644
index 0000000..16f5d9d
--- /dev/null
+++ b/git-fetch.adoc
@@ -0,0 +1,317 @@
+git-fetch(1)
+============
+
+NAME
+----
+git-fetch - Download objects and refs from another repository
+
+
+SYNOPSIS
+--------
+[verse]
+'git fetch' [<options>] [<repository> [<refspec>...]]
+'git fetch' [<options>] <group>
+'git fetch' --multiple [<options>] [(<repository> | <group>)...]
+'git fetch' --all [<options>]
+
+
+DESCRIPTION
+-----------
+Fetch branches and/or tags (collectively, "refs") from one or more
+other repositories, along with the objects necessary to complete their
+histories. Remote-tracking branches are updated (see the description
+of <refspec> below for ways to control this behavior).
+
+By default, any tag that points into the histories being fetched is
+also fetched; the effect is to fetch tags that
+point at branches that you are interested in. This default behavior
+can be changed by using the --tags or --no-tags options or by
+configuring remote.<name>.tagOpt. By using a refspec that fetches tags
+explicitly, you can fetch tags that do not point into branches you
+are interested in as well.
+
+'git fetch' can fetch from either a single named repository or URL,
+or from several repositories at once if <group> is given and
+there is a remotes.<group> entry in the configuration file.
+(See linkgit:git-config[1]).
+
+When no remote is specified, by default the `origin` remote will be used,
+unless there's an upstream branch configured for the current branch.
+
+The names of refs that are fetched, together with the object names
+they point at, are written to `.git/FETCH_HEAD`. This information
+may be used by scripts or other git commands, such as linkgit:git-pull[1].
+
+OPTIONS
+-------
+include::fetch-options.adoc[]
+
+include::pull-fetch-param.adoc[]
+
+--stdin::
+ Read refspecs, one per line, from stdin in addition to those provided
+ as arguments. The "tag <name>" format is not supported.
+
+include::urls-remotes.adoc[]
+
+
+CONFIGURED REMOTE-TRACKING BRANCHES[[CRTB]]
+-------------------------------------------
+
+You often interact with the same remote repository by
+regularly and repeatedly fetching from it. In order to keep track
+of the progress of such a remote repository, `git fetch` allows you
+to configure `remote.<repository>.fetch` configuration variables.
+
+Typically such a variable may look like this:
+
+------------------------------------------------
+[remote "origin"]
+ fetch = +refs/heads/*:refs/remotes/origin/*
+------------------------------------------------
+
+This configuration is used in two ways:
+
+* When `git fetch` is run without specifying what branches
+ and/or tags to fetch on the command line, e.g. `git fetch origin`
+ or `git fetch`, `remote.<repository>.fetch` values are used as
+ the refspecs--they specify which refs to fetch and which local refs
+ to update. The example above will fetch
+ all branches that exist in the `origin` (i.e. any ref that matches
+ the left-hand side of the value, `refs/heads/*`) and update the
+ corresponding remote-tracking branches in the `refs/remotes/origin/*`
+ hierarchy.
+
+* When `git fetch` is run with explicit branches and/or tags
+ to fetch on the command line, e.g. `git fetch origin master`, the
+ <refspec>s given on the command line determine what are to be
+ fetched (e.g. `master` in the example,
+ which is a short-hand for `master:`, which in turn means
+ "fetch the 'master' branch but I do not explicitly say what
+ remote-tracking branch to update with it from the command line"),
+ and the example command will
+ fetch _only_ the 'master' branch. The `remote.<repository>.fetch`
+ values determine which
+ remote-tracking branch, if any, is updated. When used in this
+ way, the `remote.<repository>.fetch` values do not have any
+ effect in deciding _what_ gets fetched (i.e. the values are not
+ used as refspecs when the command-line lists refspecs); they are
+ only used to decide _where_ the refs that are fetched are stored
+ by acting as a mapping.
+
+The latter use of the `remote.<repository>.fetch` values can be
+overridden by giving the `--refmap=<refspec>` parameter(s) on the
+command line.
+
+PRUNING
+-------
+
+Git has a default disposition of keeping data unless it's explicitly
+thrown away; this extends to holding onto local references to branches
+on remotes that have themselves deleted those branches.
+
+If left to accumulate, these stale references might make performance
+worse on big and busy repos that have a lot of branch churn, and
+e.g. make the output of commands like `git branch -a --contains
+<commit>` needlessly verbose, as well as impacting anything else
+that'll work with the complete set of known references.
+
+These remote-tracking references can be deleted as a one-off with
+either of:
+
+------------------------------------------------
+# While fetching
+$ git fetch --prune <name>
+
+# Only prune, don't fetch
+$ git remote prune <name>
+------------------------------------------------
+
+To prune references as part of your normal workflow without needing to
+remember to run that, set `fetch.prune` globally, or
+`remote.<name>.prune` per-remote in the config. See
+linkgit:git-config[1].
+
+Here's where things get tricky and more specific. The pruning feature
+doesn't actually care about branches, instead it'll prune local <-->
+remote-references as a function of the refspec of the remote (see
+`<refspec>` and <<CRTB,CONFIGURED REMOTE-TRACKING BRANCHES>> above).
+
+Therefore if the refspec for the remote includes
+e.g. `refs/tags/*:refs/tags/*`, or you manually run e.g. `git fetch
+--prune <name> "refs/tags/*:refs/tags/*"` it won't be stale remote
+tracking branches that are deleted, but any local tag that doesn't
+exist on the remote.
+
+This might not be what you expect, i.e. you want to prune remote
+`<name>`, but also explicitly fetch tags from it, so when you fetch
+from it you delete all your local tags, most of which may not have
+come from the `<name>` remote in the first place.
+
+So be careful when using this with a refspec like
+`refs/tags/*:refs/tags/*`, or any other refspec which might map
+references from multiple remotes to the same local namespace.
+
+Since keeping up-to-date with both branches and tags on the remote is
+a common use-case the `--prune-tags` option can be supplied along with
+`--prune` to prune local tags that don't exist on the remote, and
+force-update those tags that differ. Tag pruning can also be enabled
+with `fetch.pruneTags` or `remote.<name>.pruneTags` in the config. See
+linkgit:git-config[1].
+
+The `--prune-tags` option is equivalent to having
+`refs/tags/*:refs/tags/*` declared in the refspecs of the remote. This
+can lead to some seemingly strange interactions:
+
+------------------------------------------------
+# These both fetch tags
+$ git fetch --no-tags origin 'refs/tags/*:refs/tags/*'
+$ git fetch --no-tags --prune-tags origin
+------------------------------------------------
+
+The reason it doesn't error out when provided without `--prune` or its
+config versions is for flexibility of the configured versions, and to
+maintain a 1=1 mapping between what the command line flags do, and
+what the configuration versions do.
+
+It's reasonable to e.g. configure `fetch.pruneTags=true` in
+`~/.gitconfig` to have tags pruned whenever `git fetch --prune` is
+run, without making every invocation of `git fetch` without `--prune`
+an error.
+
+Pruning tags with `--prune-tags` also works when fetching a URL
+instead of a named remote. These will all prune tags not found on
+origin:
+
+------------------------------------------------
+$ git fetch origin --prune --prune-tags
+$ git fetch origin --prune 'refs/tags/*:refs/tags/*'
+$ git fetch <url-of-origin> --prune --prune-tags
+$ git fetch <url-of-origin> --prune 'refs/tags/*:refs/tags/*'
+------------------------------------------------
+
+OUTPUT
+------
+
+The output of "git fetch" depends on the transport method used; this
+section describes the output when fetching over the Git protocol
+(either locally or via ssh) and Smart HTTP protocol.
+
+The status of the fetch is output in tabular form, with each line
+representing the status of a single ref. Each line is of the form:
+
+-------------------------------
+ <flag> <summary> <from> -> <to> [<reason>]
+-------------------------------
+
+When using `--porcelain`, the output format is intended to be
+machine-parseable. In contrast to the human-readable output formats it
+thus prints to standard output instead of standard error. Each line is
+of the form:
+
+-------------------------------
+<flag> <old-object-id> <new-object-id> <local-reference>
+-------------------------------
+
+The status of up-to-date refs is shown only if the --verbose option is
+used.
+
+In compact output mode, specified with configuration variable
+fetch.output, if either entire `<from>` or `<to>` is found in the
+other string, it will be substituted with `*` in the other string. For
+example, `master -> origin/master` becomes `master -> origin/*`.
+
+flag::
+ A single character indicating the status of the ref:
+(space);; for a successfully fetched fast-forward;
+`+`;; for a successful forced update;
+`-`;; for a successfully pruned ref;
+`t`;; for a successful tag update;
+`*`;; for a successfully fetched new ref;
+`!`;; for a ref that was rejected or failed to update; and
+`=`;; for a ref that was up to date and did not need fetching.
+
+summary::
+ For a successfully fetched ref, the summary shows the old and new
+ values of the ref in a form suitable for using as an argument to
+ `git log` (this is `<old>..<new>` in most cases, and
+ `<old>...<new>` for forced non-fast-forward updates).
+
+from::
+ The name of the remote ref being fetched from, minus its
+ `refs/<type>/` prefix. In the case of deletion, the name of
+ the remote ref is "(none)".
+
+to::
+ The name of the local ref being updated, minus its
+ `refs/<type>/` prefix.
+
+reason::
+ A human-readable explanation. In the case of successfully fetched
+ refs, no explanation is needed. For a failed ref, the reason for
+ failure is described.
+
+EXAMPLES
+--------
+
+* Update the remote-tracking branches:
++
+------------------------------------------------
+$ git fetch origin
+------------------------------------------------
++
+The above command copies all branches from the remote `refs/heads/`
+namespace and stores them to the local `refs/remotes/origin/` namespace,
+unless the `remote.<repository>.fetch` option is used to specify a
+non-default refspec.
+
+* Using refspecs explicitly:
++
+------------------------------------------------
+$ git fetch origin +seen:seen maint:tmp
+------------------------------------------------
++
+This updates (or creates, as necessary) branches `seen` and `tmp` in
+the local repository by fetching from the branches (respectively)
+`seen` and `maint` from the remote repository.
++
+The `seen` branch will be updated even if it does not fast-forward,
+because it is prefixed with a plus sign; `tmp` will not be.
+
+* Peek at a remote's branch, without configuring the remote in your local
+ repository:
++
+------------------------------------------------
+$ git fetch git://git.kernel.org/pub/scm/git/git.git maint
+$ git log FETCH_HEAD
+------------------------------------------------
++
+The first command fetches the `maint` branch from the repository at
+`git://git.kernel.org/pub/scm/git/git.git` and the second command uses
+`FETCH_HEAD` to examine the branch with linkgit:git-log[1]. The fetched
+objects will eventually be removed by git's built-in housekeeping (see
+linkgit:git-gc[1]).
+
+include::transfer-data-leaks.adoc[]
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/fetch.adoc[]
+
+BUGS
+----
+Using --recurse-submodules can only fetch new commits in submodules that are
+present locally e.g. in `$GIT_DIR/modules/`. If the upstream adds a new
+submodule, that submodule cannot be fetched until it is cloned e.g. by `git
+submodule update`. This is expected to be fixed in a future Git version.
+
+SEE ALSO
+--------
+linkgit:git-pull[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-filter-branch.adoc b/git-filter-branch.adoc
new file mode 100644
index 0000000..5a4f853
--- /dev/null
+++ b/git-filter-branch.adoc
@@ -0,0 +1,703 @@
+git-filter-branch(1)
+====================
+
+NAME
+----
+git-filter-branch - Rewrite branches
+
+SYNOPSIS
+--------
+[verse]
+'git filter-branch' [--setup <command>] [--subdirectory-filter <directory>]
+ [--env-filter <command>] [--tree-filter <command>]
+ [--index-filter <command>] [--parent-filter <command>]
+ [--msg-filter <command>] [--commit-filter <command>]
+ [--tag-name-filter <command>] [--prune-empty]
+ [--original <namespace>] [-d <directory>] [-f | --force]
+ [--state-branch <branch>] [--] [<rev-list-options>...]
+
+WARNING
+-------
+'git filter-branch' has a plethora of pitfalls that can produce non-obvious
+manglings of the intended history rewrite (and can leave you with little
+time to investigate such problems since it has such abysmal performance).
+These safety and performance issues cannot be backward compatibly fixed and
+as such, its use is not recommended. Please use an alternative history
+filtering tool such as https://github.com/newren/git-filter-repo/[git
+filter-repo]. If you still need to use 'git filter-branch', please
+carefully read <<SAFETY>> (and <<PERFORMANCE>>) to learn about the land
+mines of filter-branch, and then vigilantly avoid as many of the hazards
+listed there as reasonably possible.
+
+DESCRIPTION
+-----------
+Lets you rewrite Git revision history by rewriting the branches mentioned
+in the <rev-list-options>, applying custom filters on each revision.
+Those filters can modify each tree (e.g. removing a file or running
+a perl rewrite on all files) or information about each commit.
+Otherwise, all information (including original commit times or merge
+information) will be preserved.
+
+The command will only rewrite the _positive_ refs mentioned in the
+command line (e.g. if you pass 'a..b', only 'b' will be rewritten).
+If you specify no filters, the commits will be recommitted without any
+changes, which would normally have no effect. Nevertheless, this may be
+useful in the future for compensating for some Git bugs or such,
+therefore such a usage is permitted.
+
+*NOTE*: This command honors `.git/info/grafts` file and refs in
+the `refs/replace/` namespace.
+If you have any grafts or replacement refs defined, running this command
+will make them permanent.
+
+*WARNING*! The rewritten history will have different object names for all
+the objects and will not converge with the original branch. You will not
+be able to easily push and distribute the rewritten branch on top of the
+original branch. Please do not use this command if you do not know the
+full implications, and avoid using it anyway, if a simple single commit
+would suffice to fix your problem. (See the "RECOVERING FROM UPSTREAM
+REBASE" section in linkgit:git-rebase[1] for further information about
+rewriting published history.)
+
+Always verify that the rewritten version is correct: The original refs,
+if different from the rewritten ones, will be stored in the namespace
+'refs/original/'.
+
+Note that since this operation is very I/O expensive, it might
+be a good idea to redirect the temporary directory off-disk with the
+`-d` option, e.g. on tmpfs. Reportedly the speedup is very noticeable.
+
+
+Filters
+~~~~~~~
+
+The filters are applied in the order as listed below. The <command>
+argument is always evaluated in the shell context using the 'eval' command
+(with the notable exception of the commit filter, for technical reasons).
+Prior to that, the `$GIT_COMMIT` environment variable will be set to contain
+the id of the commit being rewritten. Also, GIT_AUTHOR_NAME,
+GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE, GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL,
+and GIT_COMMITTER_DATE are taken from the current commit and exported to
+the environment, in order to affect the author and committer identities of
+the replacement commit created by linkgit:git-commit-tree[1] after the
+filters have run.
+
+If any evaluation of <command> returns a non-zero exit status, the whole
+operation will be aborted.
+
+A 'map' function is available that takes an "original sha1 id" argument
+and outputs a "rewritten sha1 id" if the commit has been already
+rewritten, and "original sha1 id" otherwise; the 'map' function can
+return several ids on separate lines if your commit filter emitted
+multiple commits.
+
+
+OPTIONS
+-------
+
+--setup <command>::
+ This is not a real filter executed for each commit but a one
+ time setup just before the loop. Therefore no commit-specific
+ variables are defined yet. Functions or variables defined here
+ can be used or modified in the following filter steps except
+ the commit filter, for technical reasons.
+
+--subdirectory-filter <directory>::
+ Only look at the history which touches the given subdirectory.
+ The result will contain that directory (and only that) as its
+ project root. Implies <<Remap_to_ancestor>>.
+
+--env-filter <command>::
+ This filter may be used if you only need to modify the environment
+ in which the commit will be performed. Specifically, you might
+ want to rewrite the author/committer name/email/time environment
+ variables (see linkgit:git-commit-tree[1] for details).
+
+--tree-filter <command>::
+ This is the filter for rewriting the tree and its contents.
+ The argument is evaluated in shell with the working
+ directory set to the root of the checked out tree. The new tree
+ is then used as-is (new files are auto-added, disappeared files
+ are auto-removed - neither .gitignore files nor any other ignore
+ rules *HAVE ANY EFFECT*!).
+
+--index-filter <command>::
+ This is the filter for rewriting the index. It is similar to the
+ tree filter but does not check out the tree, which makes it much
+ faster. Frequently used with `git rm --cached
+ --ignore-unmatch ...`, see EXAMPLES below. For hairy
+ cases, see linkgit:git-update-index[1].
+
+--parent-filter <command>::
+ This is the filter for rewriting the commit's parent list.
+ It will receive the parent string on stdin and shall output
+ the new parent string on stdout. The parent string is in
+ the format described in linkgit:git-commit-tree[1]: empty for
+ the initial commit, "-p parent" for a normal commit and
+ "-p parent1 -p parent2 -p parent3 ..." for a merge commit.
+
+--msg-filter <command>::
+ This is the filter for rewriting the commit messages.
+ The argument is evaluated in the shell with the original
+ commit message on standard input; its standard output is
+ used as the new commit message.
+
+--commit-filter <command>::
+ This is the filter for performing the commit.
+ If this filter is specified, it will be called instead of the
+ 'git commit-tree' command, with arguments of the form
+ "<TREE_ID> [(-p <PARENT_COMMIT_ID>)...]" and the log message on
+ stdin. The commit id is expected on stdout.
++
+As a special extension, the commit filter may emit multiple
+commit ids; in that case, the rewritten children of the original commit will
+have all of them as parents.
++
+You can use the 'map' convenience function in this filter, and other
+convenience functions, too. For example, calling 'skip_commit "$@"'
+will leave out the current commit (but not its changes! If you want
+that, use 'git rebase' instead).
++
+You can also use the `git_commit_non_empty_tree "$@"` instead of
+`git commit-tree "$@"` if you don't wish to keep commits with a single parent
+and that makes no change to the tree.
+
+--tag-name-filter <command>::
+ This is the filter for rewriting tag names. When passed,
+ it will be called for every tag ref that points to a rewritten
+ object (or to a tag object which points to a rewritten object).
+ The original tag name is passed via standard input, and the new
+ tag name is expected on standard output.
++
+The original tags are not deleted, but can be overwritten;
+use "--tag-name-filter cat" to simply update the tags. In this
+case, be very careful and make sure you have the old tags
+backed up in case the conversion has run afoul.
++
+Nearly proper rewriting of tag objects is supported. If the tag has
+a message attached, a new tag object will be created with the same message,
+author, and timestamp. If the tag has a signature attached, the
+signature will be stripped. It is by definition impossible to preserve
+signatures. The reason this is "nearly" proper, is because ideally if
+the tag did not change (points to the same object, has the same name, etc.)
+it should retain any signature. That is not the case, signatures will always
+be removed, buyer beware. There is also no support for changing the
+author or timestamp (or the tag message for that matter). Tags which point
+to other tags will be rewritten to point to the underlying commit.
+
+--prune-empty::
+ Some filters will generate empty commits that leave the tree untouched.
+ This option instructs git-filter-branch to remove such commits if they
+ have exactly one or zero non-pruned parents; merge commits will
+ therefore remain intact. This option cannot be used together with
+ `--commit-filter`, though the same effect can be achieved by using the
+ provided `git_commit_non_empty_tree` function in a commit filter.
+
+--original <namespace>::
+ Use this option to set the namespace where the original commits
+ will be stored. The default value is 'refs/original'.
+
+-d <directory>::
+ Use this option to set the path to the temporary directory used for
+ rewriting. When applying a tree filter, the command needs to
+ temporarily check out the tree to some directory, which may consume
+ considerable space in case of large projects. By default it
+ does this in the `.git-rewrite/` directory but you can override
+ that choice by this parameter.
+
+-f::
+--force::
+ 'git filter-branch' refuses to start with an existing temporary
+ directory or when there are already refs starting with
+ 'refs/original/', unless forced.
+
+--state-branch <branch>::
+ This option will cause the mapping from old to new objects to
+ be loaded from named branch upon startup and saved as a new
+ commit to that branch upon exit, enabling incremental of large
+ trees. If '<branch>' does not exist it will be created.
+
+<rev-list options>...::
+ Arguments for 'git rev-list'. All positive refs included by
+ these options are rewritten. You may also specify options
+ such as `--all`, but you must use `--` to separate them from
+ the 'git filter-branch' options. Implies <<Remap_to_ancestor>>.
+
+
+[[Remap_to_ancestor]]
+Remap to ancestor
+~~~~~~~~~~~~~~~~~
+
+By using linkgit:git-rev-list[1] arguments, e.g., path limiters, you can limit the
+set of revisions which get rewritten. However, positive refs on the command
+line are distinguished: we don't let them be excluded by such limiters. For
+this purpose, they are instead rewritten to point at the nearest ancestor that
+was not excluded.
+
+
+EXIT STATUS
+-----------
+
+On success, the exit status is `0`. If the filter can't find any commits to
+rewrite, the exit status is `2`. On any other error, the exit status may be
+any other non-zero value.
+
+
+EXAMPLES
+--------
+
+Suppose you want to remove a file (containing confidential information
+or copyright violation) from all commits:
+
+-------------------------------------------------------
+git filter-branch --tree-filter 'rm filename' HEAD
+-------------------------------------------------------
+
+However, if the file is absent from the tree of some commit,
+a simple `rm filename` will fail for that tree and commit.
+Thus you may instead want to use `rm -f filename` as the script.
+
+Using `--index-filter` with 'git rm' yields a significantly faster
+version. Like with using `rm filename`, `git rm --cached filename`
+will fail if the file is absent from the tree of a commit. If you
+want to "completely forget" a file, it does not matter when it entered
+history, so we also add `--ignore-unmatch`:
+
+--------------------------------------------------------------------------
+git filter-branch --index-filter 'git rm --cached --ignore-unmatch filename' HEAD
+--------------------------------------------------------------------------
+
+Now, you will get the rewritten history saved in HEAD.
+
+To rewrite the repository to look as if `foodir/` had been its project
+root, and discard all other history:
+
+-------------------------------------------------------
+git filter-branch --subdirectory-filter foodir -- --all
+-------------------------------------------------------
+
+Thus you can, e.g., turn a library subdirectory into a repository of
+its own. Note the `--` that separates 'filter-branch' options from
+revision options, and the `--all` to rewrite all branches and tags.
+
+To set a commit (which typically is at the tip of another
+history) to be the parent of the current initial commit, in
+order to paste the other history behind the current history:
+
+-------------------------------------------------------------------
+git filter-branch --parent-filter 'sed "s/^\$/-p <graft-id>/"' HEAD
+-------------------------------------------------------------------
+
+(if the parent string is empty - which happens when we are dealing with
+the initial commit - add graftcommit as a parent). Note that this assumes
+history with a single root (that is, no merge without common ancestors
+happened). If this is not the case, use:
+
+--------------------------------------------------------------------------
+git filter-branch --parent-filter \
+ 'test $GIT_COMMIT = <commit-id> && echo "-p <graft-id>" || cat' HEAD
+--------------------------------------------------------------------------
+
+or even simpler:
+
+-----------------------------------------------
+git replace --graft $commit-id $graft-id
+git filter-branch $graft-id..HEAD
+-----------------------------------------------
+
+To remove commits authored by "Darl McBribe" from the history:
+
+------------------------------------------------------------------------------
+git filter-branch --commit-filter '
+ if [ "$GIT_AUTHOR_NAME" = "Darl McBribe" ];
+ then
+ skip_commit "$@";
+ else
+ git commit-tree "$@";
+ fi' HEAD
+------------------------------------------------------------------------------
+
+The function 'skip_commit' is defined as follows:
+
+--------------------------
+skip_commit()
+{
+ shift;
+ while [ -n "$1" ];
+ do
+ shift;
+ map "$1";
+ shift;
+ done;
+}
+--------------------------
+
+The shift magic first throws away the tree id and then the -p
+parameters. Note that this handles merges properly! In case Darl
+committed a merge between P1 and P2, it will be propagated properly
+and all children of the merge will become merge commits with P1,P2
+as their parents instead of the merge commit.
+
+*NOTE* the changes introduced by the commits, and which are not reverted
+by subsequent commits, will still be in the rewritten branch. If you want
+to throw out _changes_ together with the commits, you should use the
+interactive mode of 'git rebase'.
+
+You can rewrite the commit log messages using `--msg-filter`. For
+example, 'git svn-id' strings in a repository created by 'git svn' can
+be removed this way:
+
+-------------------------------------------------------
+git filter-branch --msg-filter '
+ sed -e "/^git-svn-id:/d"
+'
+-------------------------------------------------------
+
+If you need to add 'Acked-by' lines to, say, the last 10 commits (none
+of which is a merge), use this command:
+
+--------------------------------------------------------
+git filter-branch --msg-filter '
+ cat &&
+ echo "Acked-by: Bugs Bunny <bunny@bugzilla.org>"
+' HEAD~10..HEAD
+--------------------------------------------------------
+
+The `--env-filter` option can be used to modify committer and/or author
+identity. For example, if you found out that your commits have the wrong
+identity due to a misconfigured user.email, you can make a correction,
+before publishing the project, like this:
+
+--------------------------------------------------------
+git filter-branch --env-filter '
+ if test "$GIT_AUTHOR_EMAIL" = "root@localhost"
+ then
+ GIT_AUTHOR_EMAIL=john@example.com
+ fi
+ if test "$GIT_COMMITTER_EMAIL" = "root@localhost"
+ then
+ GIT_COMMITTER_EMAIL=john@example.com
+ fi
+' -- --all
+--------------------------------------------------------
+
+To restrict rewriting to only part of the history, specify a revision
+range in addition to the new branch name. The new branch name will
+point to the top-most revision that a 'git rev-list' of this range
+will print.
+
+Consider this history:
+
+------------------
+ D--E--F--G--H
+ / /
+A--B-----C
+------------------
+
+To rewrite only commits D,E,F,G,H, but leave A, B and C alone, use:
+
+--------------------------------
+git filter-branch ... C..H
+--------------------------------
+
+To rewrite commits E,F,G,H, use one of these:
+
+----------------------------------------
+git filter-branch ... C..H --not D
+git filter-branch ... D..H --not C
+----------------------------------------
+
+To move the whole tree into a subdirectory, or remove it from there:
+
+---------------------------------------------------------------
+git filter-branch --index-filter \
+ 'git ls-files -s | sed "s-\t\"*-&newsubdir/-" |
+ GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
+ git update-index --index-info &&
+ mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"' HEAD
+---------------------------------------------------------------
+
+
+
+CHECKLIST FOR SHRINKING A REPOSITORY
+------------------------------------
+
+git-filter-branch can be used to get rid of a subset of files,
+usually with some combination of `--index-filter` and
+`--subdirectory-filter`. People expect the resulting repository to
+be smaller than the original, but you need a few more steps to
+actually make it smaller, because Git tries hard not to lose your
+objects until you tell it to. First make sure that:
+
+* You really removed all variants of a filename, if a blob was moved
+ over its lifetime. `git log --name-only --follow --all -- filename`
+ can help you find renames.
+
+* You really filtered all refs: use `--tag-name-filter cat -- --all`
+ when calling git-filter-branch.
+
+Then there are two ways to get a smaller repository. A safer way is
+to clone, that keeps your original intact.
+
+* Clone it with `git clone file:///path/to/repo`. The clone
+ will not have the removed objects. See linkgit:git-clone[1]. (Note
+ that cloning with a plain path just hardlinks everything!)
+
+If you really don't want to clone it, for whatever reasons, check the
+following points instead (in this order). This is a very destructive
+approach, so *make a backup* or go back to cloning it. You have been
+warned.
+
+* Remove the original refs backed up by git-filter-branch: say `git
+ for-each-ref --format="%(refname)" refs/original/ | xargs -n 1 git
+ update-ref -d`.
+
+* Expire all reflogs with `git reflog expire --expire=now --all`.
+
+* Garbage collect all unreferenced objects with `git gc --prune=now`
+ (or if your git-gc is not new enough to support arguments to
+ `--prune`, use `git repack -ad; git prune` instead).
+
+[[PERFORMANCE]]
+PERFORMANCE
+-----------
+
+The performance of git-filter-branch is glacially slow; its design makes it
+impossible for a backward-compatible implementation to ever be fast:
+
+* In editing files, git-filter-branch by design checks out each and
+ every commit as it existed in the original repo. If your repo has
+ `10^5` files and `10^5` commits, but each commit only modifies five
+ files, then git-filter-branch will make you do `10^10` modifications,
+ despite only having (at most) `5*10^5` unique blobs.
+
+* If you try and cheat and try to make git-filter-branch only work on
+ files modified in a commit, then two things happen
+
+ ** you run into problems with deletions whenever the user is simply
+ trying to rename files (because attempting to delete files that
+ don't exist looks like a no-op; it takes some chicanery to remap
+ deletes across file renames when the renames happen via arbitrary
+ user-provided shell)
+
+ ** even if you succeed at the map-deletes-for-renames chicanery, you
+ still technically violate backward compatibility because users
+ are allowed to filter files in ways that depend upon topology of
+ commits instead of filtering solely based on file contents or
+ names (though this has not been observed in the wild).
+
+* Even if you don't need to edit files but only want to e.g. rename or
+ remove some and thus can avoid checking out each file (i.e. you can
+ use --index-filter), you still are passing shell snippets for your
+ filters. This means that for every commit, you have to have a
+ prepared git repo where those filters can be run. That's a
+ significant setup.
+
+* Further, several additional files are created or updated per commit
+ by git-filter-branch. Some of these are for supporting the
+ convenience functions provided by git-filter-branch (such as map()),
+ while others are for keeping track of internal state (but could have
+ also been accessed by user filters; one of git-filter-branch's
+ regression tests does so). This essentially amounts to using the
+ filesystem as an IPC mechanism between git-filter-branch and the
+ user-provided filters. Disks tend to be a slow IPC mechanism, and
+ writing these files also effectively represents a forced
+ synchronization point between separate processes that we hit with
+ every commit.
+
+* The user-provided shell commands will likely involve a pipeline of
+ commands, resulting in the creation of many processes per commit.
+ Creating and running another process takes a widely varying amount
+ of time between operating systems, but on any platform it is very
+ slow relative to invoking a function.
+
+* git-filter-branch itself is written in shell, which is kind of slow.
+ This is the one performance issue that could be backward-compatibly
+ fixed, but compared to the above problems that are intrinsic to the
+ design of git-filter-branch, the language of the tool itself is a
+ relatively minor issue.
+
+ ** Side note: Unfortunately, people tend to fixate on the
+ written-in-shell aspect and periodically ask if git-filter-branch
+ could be rewritten in another language to fix the performance
+ issues. Not only does that ignore the bigger intrinsic problems
+ with the design, it'd help less than you'd expect: if
+ git-filter-branch itself were not shell, then the convenience
+ functions (map(), skip_commit(), etc) and the `--setup` argument
+ could no longer be executed once at the beginning of the program
+ but would instead need to be prepended to every user filter (and
+ thus re-executed with every commit).
+
+The https://github.com/newren/git-filter-repo/[git filter-repo] tool is
+an alternative to git-filter-branch which does not suffer from these
+performance problems or the safety problems (mentioned below). For those
+with existing tooling which relies upon git-filter-branch, 'git
+filter-repo' also provides
+https://github.com/newren/git-filter-repo/blob/master/contrib/filter-repo-demos/filter-lamely[filter-lamely],
+a drop-in git-filter-branch replacement (with a few caveats). While
+filter-lamely suffers from all the same safety issues as
+git-filter-branch, it at least ameliorates the performance issues a
+little.
+
+[[SAFETY]]
+SAFETY
+------
+
+git-filter-branch is riddled with gotchas resulting in various ways to
+easily corrupt repos or end up with a mess worse than what you started
+with:
+
+* Someone can have a set of "working and tested filters" which they
+ document or provide to a coworker, who then runs them on a different
+ OS where the same commands are not working/tested (some examples in
+ the git-filter-branch manpage are also affected by this).
+ BSD vs. GNU userland differences can really bite. If lucky, error
+ messages are spewed. But just as likely, the commands either don't
+ do the filtering requested, or silently corrupt by making some
+ unwanted change. The unwanted change may only affect a few commits,
+ so it's not necessarily obvious either. (The fact that problems
+ won't necessarily be obvious means they are likely to go unnoticed
+ until the rewritten history is in use for quite a while, at which
+ point it's really hard to justify another flag-day for another
+ rewrite.)
+
+* Filenames with spaces are often mishandled by shell snippets since
+ they cause problems for shell pipelines. Not everyone is familiar
+ with find -print0, xargs -0, git-ls-files -z, etc. Even people who
+ are familiar with these may assume such flags are not relevant
+ because someone else renamed any such files in their repo back
+ before the person doing the filtering joined the project. And
+ often, even those familiar with handling arguments with spaces may
+ not do so just because they aren't in the mindset of thinking about
+ everything that could possibly go wrong.
+
+* Non-ascii filenames can be silently removed despite being in a
+ desired directory. Keeping only wanted paths is often done using
+ pipelines like `git ls-files | grep -v ^WANTED_DIR/ | xargs git rm`.
+ ls-files will only quote filenames if needed, so folks may not
+ notice that one of the files didn't match the regex (at least not
+ until it's much too late). Yes, someone who knows about
+ core.quotePath can avoid this (unless they have other special
+ characters like \t, \n, or "), and people who use ls-files -z with
+ something other than grep can avoid this, but that doesn't mean they
+ will.
+
+* Similarly, when moving files around, one can find that filenames
+ with non-ascii or special characters end up in a different
+ directory, one that includes a double quote character. (This is
+ technically the same issue as above with quoting, but perhaps an
+ interesting different way that it can and has manifested as a
+ problem.)
+
+* It's far too easy to accidentally mix up old and new history. It's
+ still possible with any tool, but git-filter-branch almost
+ invites it. If lucky, the only downside is users getting frustrated
+ that they don't know how to shrink their repo and remove the old
+ stuff. If unlucky, they merge old and new history and end up with
+ multiple "copies" of each commit, some of which have unwanted or
+ sensitive files and others which don't. This comes about in
+ multiple different ways:
+
+ ** the default to only doing a partial history rewrite ('--all' is not
+ the default and few examples show it)
+
+ ** the fact that there's no automatic post-run cleanup
+
+ ** the fact that --tag-name-filter (when used to rename tags) doesn't
+ remove the old tags but just adds new ones with the new name
+
+ ** the fact that little educational information is provided to inform
+ users of the ramifications of a rewrite and how to avoid mixing old
+ and new history. For example, this man page discusses how users
+ need to understand that they need to rebase their changes for all
+ their branches on top of new history (or delete and reclone), but
+ that's only one of multiple concerns to consider. See the
+ "DISCUSSION" section of the git filter-repo manual page for more
+ details.
+
+* Annotated tags can be accidentally converted to lightweight tags,
+ due to either of two issues:
+
+ ** Someone can do a history rewrite, realize they messed up, restore
+ from the backups in refs/original/, and then redo their
+ git-filter-branch command. (The backup in refs/original/ is not a
+ real backup; it dereferences tags first.)
+
+ ** Running git-filter-branch with either --tags or --all in your
+ <rev-list-options>. In order to retain annotated tags as
+ annotated, you must use --tag-name-filter (and must not have
+ restored from refs/original/ in a previously botched rewrite).
+
+* Any commit messages that specify an encoding will become corrupted
+ by the rewrite; git-filter-branch ignores the encoding, takes the
+ original bytes, and feeds it to commit-tree without telling it the
+ proper encoding. (This happens whether or not --msg-filter is
+ used.)
+
+* Commit messages (even if they are all UTF-8) by default become
+ corrupted due to not being updated -- any references to other commit
+ hashes in commit messages will now refer to no-longer-extant
+ commits.
+
+* There are no facilities for helping users find what unwanted crud
+ they should delete, which means they are much more likely to have
+ incomplete or partial cleanups that sometimes result in confusion
+ and people wasting time trying to understand. (For example, folks
+ tend to just look for big files to delete instead of big directories
+ or extensions, and once they do so, then sometime later folks using
+ the new repository who are going through history will notice a build
+ artifact directory that has some files but not others, or a cache of
+ dependencies (node_modules or similar) which couldn't have ever been
+ functional since it's missing some files.)
+
+* If --prune-empty isn't specified, then the filtering process can
+ create hoards of confusing empty commits
+
+* If --prune-empty is specified, then intentionally placed empty
+ commits from before the filtering operation are also pruned instead
+ of just pruning commits that became empty due to filtering rules.
+
+* If --prune-empty is specified, sometimes empty commits are missed
+ and left around anyway (a somewhat rare bug, but it happens...)
+
+* A minor issue, but users who have a goal to update all names and
+ emails in a repository may be led to --env-filter which will only
+ update authors and committers, missing taggers.
+
+* If the user provides a --tag-name-filter that maps multiple tags to
+ the same name, no warning or error is provided; git-filter-branch
+ simply overwrites each tag in some undocumented pre-defined order
+ resulting in only one tag at the end. (A git-filter-branch
+ regression test requires this surprising behavior.)
+
+Also, the poor performance of git-filter-branch often leads to safety
+issues:
+
+* Coming up with the correct shell snippet to do the filtering you
+ want is sometimes difficult unless you're just doing a trivial
+ modification such as deleting a couple files. Unfortunately, people
+ often learn if the snippet is right or wrong by trying it out, but
+ the rightness or wrongness can vary depending on special
+ circumstances (spaces in filenames, non-ascii filenames, funny
+ author names or emails, invalid timezones, presence of grafts or
+ replace objects, etc.), meaning they may have to wait a long time,
+ hit an error, then restart. The performance of git-filter-branch is
+ so bad that this cycle is painful, reducing the time available to
+ carefully re-check (to say nothing about what it does to the
+ patience of the person doing the rewrite even if they do technically
+ have more time available). This problem is extra compounded because
+ errors from broken filters may not be shown for a long time and/or
+ get lost in a sea of output. Even worse, broken filters often just
+ result in silent incorrect rewrites.
+
+* To top it all off, even when users finally find working commands,
+ they naturally want to share them. But they may be unaware that
+ their repo didn't have some special cases that someone else's does.
+ So, when someone else with a different repository runs the same
+ commands, they get hit by the problems above. Or, the user just
+ runs commands that really were vetted for special cases, but they
+ run it on a different OS where it doesn't work, as noted above.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-fmt-merge-msg.adoc b/git-fmt-merge-msg.adoc
new file mode 100644
index 0000000..0f33289
--- /dev/null
+++ b/git-fmt-merge-msg.adoc
@@ -0,0 +1,82 @@
+git-fmt-merge-msg(1)
+====================
+
+NAME
+----
+git-fmt-merge-msg - Produce a merge commit message
+
+
+SYNOPSIS
+--------
+[verse]
+'git fmt-merge-msg' [-m <message>] [--into-name <branch>] [--log[=<n>] | --no-log]
+'git fmt-merge-msg' [-m <message>] [--log[=<n>] | --no-log] -F <file>
+
+DESCRIPTION
+-----------
+Takes the list of merged objects on stdin and produces a suitable
+commit message to be used for the merge commit, usually to be
+passed as the '<merge-message>' argument of 'git merge'.
+
+This command is intended mostly for internal use by scripts
+automatically invoking 'git merge'.
+
+OPTIONS
+-------
+
+--log[=<n>]::
+ In addition to branch names, populate the log message with
+ one-line descriptions from the actual commits that are being
+ merged. At most <n> commits from each merge parent will be
+ used (20 if <n> is omitted). This overrides the `merge.log`
+ configuration variable.
+
+--no-log::
+ Do not list one-line descriptions from the actual commits being
+ merged.
+
+--[no-]summary::
+ Synonyms to --log and --no-log; these are deprecated and will be
+ removed in the future.
+
+-m <message>::
+--message <message>::
+ Use <message> instead of the branch names for the first line
+ of the log message. For use with `--log`.
+
+--into-name <branch>::
+ Prepare the merge message as if merging to the branch `<branch>`,
+ instead of the name of the real branch to which the merge is made.
+
+-F <file>::
+--file <file>::
+ Take the list of merged objects from <file> instead of
+ stdin.
+
+CONFIGURATION
+-------------
+include::config/fmt-merge-msg.adoc[]
+
+merge.summary::
+ Synonym to `merge.log`; this is deprecated and will be removed in
+ the future.
+
+EXAMPLES
+--------
+
+---------
+$ git fetch origin master
+$ git fmt-merge-msg --log <$GIT_DIR/FETCH_HEAD
+---------
+
+Print a log message describing a merge of the "master" branch from
+the "origin" remote.
+
+
+SEE ALSO
+--------
+linkgit:git-merge[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-for-each-ref.adoc b/git-for-each-ref.adoc
new file mode 100644
index 0000000..ffb97e6
--- /dev/null
+++ b/git-for-each-ref.adoc
@@ -0,0 +1,549 @@
+git-for-each-ref(1)
+===================
+
+NAME
+----
+git-for-each-ref - Output information on each ref
+
+SYNOPSIS
+--------
+[verse]
+'git for-each-ref' [--count=<count>] [--shell|--perl|--python|--tcl]
+ [(--sort=<key>)...] [--format=<format>]
+ [--include-root-refs] [ --stdin | <pattern>... ]
+ [--points-at=<object>]
+ [--merged[=<object>]] [--no-merged[=<object>]]
+ [--contains[=<object>]] [--no-contains[=<object>]]
+ [--exclude=<pattern> ...]
+
+DESCRIPTION
+-----------
+
+Iterate over all refs that match `<pattern>` and show them
+according to the given `<format>`, after sorting them according
+to the given set of `<key>`. If `<count>` is given, stop after
+showing that many refs. The interpolated values in `<format>`
+can optionally be quoted as string literals in the specified
+host language allowing their direct evaluation in that language.
+
+OPTIONS
+-------
+<pattern>...::
+ If one or more patterns are given, only refs are shown that
+ match against at least one pattern, either using fnmatch(3) or
+ literally, in the latter case matching completely or from the
+ beginning up to a slash.
+
+--stdin::
+ If `--stdin` is supplied, then the list of patterns is read from
+ standard input instead of from the argument list.
+
+--count=<count>::
+ By default the command shows all refs that match
+ `<pattern>`. This option makes it stop after showing
+ that many refs.
+
+--sort=<key>::
+ A field name to sort on. Prefix `-` to sort in
+ descending order of the value. When unspecified,
+ `refname` is used. You may use the --sort=<key> option
+ multiple times, in which case the last key becomes the primary
+ key.
+
+--format=<format>::
+ A string that interpolates `%(fieldname)` from a ref being shown and
+ the object it points at. In addition, the string literal `%%`
+ renders as `%` and `%xx` - where `xx` are hex digits - renders as
+ the character with hex code `xx`. For example, `%00` interpolates to
+ `\0` (NUL), `%09` to `\t` (TAB), and `%0a` to `\n` (LF).
++
+When unspecified, `<format>` defaults to `%(objectname) SPC %(objecttype)
+TAB %(refname)`.
+
+--color[=<when>]::
+ Respect any colors specified in the `--format` option. The
+ `<when>` field must be one of `always`, `never`, or `auto` (if
+ `<when>` is absent, behave as if `always` was given).
+
+--shell::
+--perl::
+--python::
+--tcl::
+ If given, strings that substitute `%(fieldname)`
+ placeholders are quoted as string literals suitable for
+ the specified host language. This is meant to produce
+ a scriptlet that can directly be `eval`ed.
+
+--points-at=<object>::
+ Only list refs which points at the given object.
+
+--merged[=<object>]::
+ Only list refs whose tips are reachable from the
+ specified commit (HEAD if not specified).
+
+--no-merged[=<object>]::
+ Only list refs whose tips are not reachable from the
+ specified commit (HEAD if not specified).
+
+--contains[=<object>]::
+ Only list refs which contain the specified commit (HEAD if not
+ specified).
+
+--no-contains[=<object>]::
+ Only list refs which don't contain the specified commit (HEAD
+ if not specified).
+
+--ignore-case::
+ Sorting and filtering refs are case insensitive.
+
+--omit-empty::
+ Do not print a newline after formatted refs where the format expands
+ to the empty string.
+
+--exclude=<pattern>::
+ If one or more patterns are given, only refs which do not match
+ any excluded pattern(s) are shown. Matching is done using the
+ same rules as `<pattern>` above.
+
+--include-root-refs::
+ List root refs (HEAD and pseudorefs) apart from regular refs.
+
+FIELD NAMES
+-----------
+
+Various values from structured fields in referenced objects can
+be used to interpolate into the resulting output, or as sort
+keys.
+
+For all objects, the following names can be used:
+
+refname::
+ The name of the ref (the part after $GIT_DIR/).
+ For a non-ambiguous short name of the ref append `:short`.
+ The option core.warnAmbiguousRefs is used to select the strict
+ abbreviation mode. If `lstrip=<N>` (`rstrip=<N>`) is appended, strips `<N>`
+ slash-separated path components from the front (back) of the refname
+ (e.g. `%(refname:lstrip=2)` turns `refs/tags/foo` into `foo` and
+ `%(refname:rstrip=2)` turns `refs/tags/foo` into `refs`).
+ If `<N>` is a negative number, strip as many path components as
+ necessary from the specified end to leave `-<N>` path components
+ (e.g. `%(refname:lstrip=-2)` turns
+ `refs/tags/foo` into `tags/foo` and `%(refname:rstrip=-1)`
+ turns `refs/tags/foo` into `refs`). When the ref does not have
+ enough components, the result becomes an empty string if
+ stripping with positive <N>, or it becomes the full refname if
+ stripping with negative <N>. Neither is an error.
++
+`strip` can be used as a synonym to `lstrip`.
+
+objecttype::
+ The type of the object (`blob`, `tree`, `commit`, `tag`).
+
+objectsize::
+ The size of the object (the same as 'git cat-file -s' reports).
+ Append `:disk` to get the size, in bytes, that the object takes up on
+ disk. See the note about on-disk sizes in the `CAVEATS` section below.
+objectname::
+ The object name (aka SHA-1).
+ For a non-ambiguous abbreviation of the object name append `:short`.
+ For an abbreviation of the object name with desired length append
+ `:short=<length>`, where the minimum length is MINIMUM_ABBREV. The
+ length may be exceeded to ensure unique object names.
+deltabase::
+ This expands to the object name of the delta base for the
+ given object, if it is stored as a delta. Otherwise it
+ expands to the null object name (all zeroes).
+
+upstream::
+ The name of a local ref which can be considered ``upstream''
+ from the displayed ref. Respects `:short`, `:lstrip` and
+ `:rstrip` in the same way as `refname` above. Additionally
+ respects `:track` to show "[ahead N, behind M]" and
+ `:trackshort` to show the terse version: ">" (ahead), "<"
+ (behind), "<>" (ahead and behind), or "=" (in sync). `:track`
+ also prints "[gone]" whenever unknown upstream ref is
+ encountered. Append `:track,nobracket` to show tracking
+ information without brackets (i.e "ahead N, behind M").
++
+For any remote-tracking branch `%(upstream)`, `%(upstream:remotename)`
+and `%(upstream:remoteref)` refer to the name of the remote and the
+name of the tracked remote ref, respectively. In other words, the
+remote-tracking branch can be updated explicitly and individually by
+using the refspec `%(upstream:remoteref):%(upstream)` to fetch from
+`%(upstream:remotename)`.
++
+Has no effect if the ref does not have tracking information associated
+with it. All the options apart from `nobracket` are mutually exclusive,
+but if used together the last option is selected.
+
+push::
+ The name of a local ref which represents the `@{push}`
+ location for the displayed ref. Respects `:short`, `:lstrip`,
+ `:rstrip`, `:track`, `:trackshort`, `:remotename`, and `:remoteref`
+ options as `upstream` does. Produces an empty string if no `@{push}`
+ ref is configured.
+
+HEAD::
+ '*' if HEAD matches current ref (the checked out branch), ' '
+ otherwise.
+
+color::
+ Change output color. Followed by `:<colorname>`, where color
+ names are described under Values in the "CONFIGURATION FILE"
+ section of linkgit:git-config[1]. For example,
+ `%(color:bold red)`.
+
+align::
+ Left-, middle-, or right-align the content between
+ %(align:...) and %(end). The "align:" is followed by
+ `width=<width>` and `position=<position>` in any order
+ separated by a comma, where the `<position>` is either left,
+ right or middle, default being left and `<width>` is the total
+ length of the content with alignment. For brevity, the
+ "width=" and/or "position=" prefixes may be omitted, and bare
+ <width> and <position> used instead. For instance,
+ `%(align:<width>,<position>)`. If the contents length is more
+ than the width then no alignment is performed. If used with
+ `--quote` everything in between %(align:...) and %(end) is
+ quoted, but if nested then only the topmost level performs
+ quoting.
+
+if::
+ Used as %(if)...%(then)...%(end) or
+ %(if)...%(then)...%(else)...%(end). If there is an atom with
+ value or string literal after the %(if) then everything after
+ the %(then) is printed, else if the %(else) atom is used, then
+ everything after %(else) is printed. We ignore space when
+ evaluating the string before %(then), this is useful when we
+ use the %(HEAD) atom which prints either "*" or " " and we
+ want to apply the 'if' condition only on the 'HEAD' ref.
+ Append ":equals=<string>" or ":notequals=<string>" to compare
+ the value between the %(if:...) and %(then) atoms with the
+ given string.
+
+symref::
+ The ref which the given symbolic ref refers to. If not a
+ symbolic ref, nothing is printed. Respects the `:short`,
+ `:lstrip` and `:rstrip` options in the same way as `refname`
+ above.
+
+signature::
+ The GPG signature of a commit.
+
+signature:grade::
+ Show "G" for a good (valid) signature, "B" for a bad
+ signature, "U" for a good signature with unknown validity, "X"
+ for a good signature that has expired, "Y" for a good
+ signature made by an expired key, "R" for a good signature
+ made by a revoked key, "E" if the signature cannot be
+ checked (e.g. missing key) and "N" for no signature.
+
+signature:signer::
+ The signer of the GPG signature of a commit.
+
+signature:key::
+ The key of the GPG signature of a commit.
+
+signature:fingerprint::
+ The fingerprint of the GPG signature of a commit.
+
+signature:primarykeyfingerprint::
+ The primary key fingerprint of the GPG signature of a commit.
+
+signature:trustlevel::
+ The trust level of the GPG signature of a commit. Possible
+ outputs are `ultimate`, `fully`, `marginal`, `never` and `undefined`.
+
+worktreepath::
+ The absolute path to the worktree in which the ref is checked
+ out, if it is checked out in any linked worktree. Empty string
+ otherwise.
+
+ahead-behind:<committish>::
+ Two integers, separated by a space, demonstrating the number of
+ commits ahead and behind, respectively, when comparing the output
+ ref to the `<committish>` specified in the format.
+
+is-base:<committish>::
+ In at most one row, `(<committish>)` will appear to indicate the ref
+ that is most likely the ref used as a starting point for the branch
+ that produced `<committish>`. This choice is made using a heuristic:
+ choose the ref that minimizes the number of commits in the
+ first-parent history of `<committish>` and not in the first-parent
+ history of the ref.
++
+For example, consider the following figure of first-parent histories of
+several refs:
++
+----
+*--*--*--*--*--* refs/heads/A
+\
+ \
+ *--*--*--* refs/heads/B
+ \ \
+ \ \
+ * * refs/heads/C
+ \
+ \
+ *--* refs/heads/D
+----
++
+Here, if `A`, `B`, and `C` are the filtered references, and the format
+string is `%(refname):%(is-base:D)`, then the output would be
++
+----
+refs/heads/A:
+refs/heads/B:(D)
+refs/heads/C:
+----
++
+This is because the first-parent history of `D` has its earliest
+intersection with the first-parent histories of the filtered refs at a
+common first-parent ancestor of `B` and `C` and ties are broken by the
+earliest ref in the sorted order.
++
+Note that this token will not appear if the first-parent history of
+`<committish>` does not intersect the first-parent histories of the
+filtered refs.
+
+describe[:options]::
+ A human-readable name, like linkgit:git-describe[1];
+ empty string for undescribable commits. The `describe` string may
+ be followed by a colon and one or more comma-separated options.
++
+--
+tags=<bool-value>;;
+ Instead of only considering annotated tags, consider
+ lightweight tags as well; see the corresponding option in
+ linkgit:git-describe[1] for details.
+abbrev=<number>;;
+ Use at least <number> hexadecimal digits; see the corresponding
+ option in linkgit:git-describe[1] for details.
+match=<pattern>;;
+ Only consider tags matching the given `glob(7)` pattern,
+ excluding the "refs/tags/" prefix; see the corresponding option
+ in linkgit:git-describe[1] for details.
+exclude=<pattern>;;
+ Do not consider tags matching the given `glob(7)` pattern,
+ excluding the "refs/tags/" prefix; see the corresponding option
+ in linkgit:git-describe[1] for details.
+--
+
+In addition to the above, for commit and tag objects, the header
+field names (`tree`, `parent`, `object`, `type`, and `tag`) can
+be used to specify the value in the header field.
+Fields `tree` and `parent` can also be used with modifier `:short` and
+`:short=<length>` just like `objectname`.
+
+For commit and tag objects, the special `creatordate` and `creator`
+fields will correspond to the appropriate date or name-email-date tuple
+from the `committer` or `tagger` fields depending on the object type.
+These are intended for working on a mix of annotated and lightweight tags.
+
+For tag objects, a `fieldname` prefixed with an asterisk (`*`) expands to
+the `fieldname` value of the peeled object, rather than that of the tag
+object itself.
+
+Fields that have name-email-date tuple as its value (`author`,
+`committer`, and `tagger`) can be suffixed with `name`, `email`,
+and `date` to extract the named component. For email fields (`authoremail`,
+`committeremail` and `taggeremail`), `:trim` can be appended to get the email
+without angle brackets, and `:localpart` to get the part before the `@` symbol
+out of the trimmed email. In addition to these, the `:mailmap` option and the
+corresponding `:mailmap,trim` and `:mailmap,localpart` can be used (order does
+not matter) to get values of the name and email according to the .mailmap file
+or according to the file set in the mailmap.file or mailmap.blob configuration
+variable (see linkgit:gitmailmap[5]).
+
+The raw data in an object is `raw`.
+
+raw:size::
+ The raw data size of the object.
+
+Note that `--format=%(raw)` can not be used with `--python`, `--shell`, `--tcl`,
+because such language may not support arbitrary binary data in their string
+variable type.
+
+The message in a commit or a tag object is `contents`, from which
+`contents:<part>` can be used to extract various parts out of:
+
+contents:size::
+ The size in bytes of the commit or tag message.
+
+contents:subject::
+ The first paragraph of the message, which typically is a
+ single line, is taken as the "subject" of the commit or the
+ tag message.
+ Instead of `contents:subject`, field `subject` can also be used to
+ obtain same results. `:sanitize` can be appended to `subject` for
+ subject line suitable for filename.
+
+contents:body::
+ The remainder of the commit or the tag message that follows
+ the "subject".
+
+contents:signature::
+ The optional GPG signature of the tag.
+
+contents:lines=N::
+ The first `N` lines of the message.
+
+Additionally, the trailers as interpreted by linkgit:git-interpret-trailers[1]
+are obtained as `trailers[:options]` (or by using the historical alias
+`contents:trailers[:options]`). For valid [:option] values see `trailers`
+section of linkgit:git-log[1].
+
+For sorting purposes, fields with numeric values sort in numeric order
+(`objectsize`, `authordate`, `committerdate`, `creatordate`, `taggerdate`).
+All other fields are used to sort in their byte-value order.
+
+There is also an option to sort by versions, this can be done by using
+the fieldname `version:refname` or its alias `v:refname`.
+
+In any case, a field name that refers to a field inapplicable to
+the object referred by the ref does not cause an error. It
+returns an empty string instead.
+
+As a special case for the date-type fields, you may specify a format for the
+date by adding `:` followed by date format name (see the values the `--date`
+option to linkgit:git-rev-list[1] takes). If this formatting is provided in
+a `--sort` key, references will be sorted according to the byte-value of the
+formatted string rather than the numeric value of the underlying timestamp.
+
+Some atoms like %(align) and %(if) always require a matching %(end).
+We call them "opening atoms" and sometimes denote them as %($open).
+
+When a scripting language specific quoting is in effect, everything
+between a top-level opening atom and its matching %(end) is evaluated
+according to the semantics of the opening atom and only its result
+from the top-level is quoted.
+
+
+EXAMPLES
+--------
+
+An example directly producing formatted text. Show the most recent
+3 tagged commits:
+
+------------
+#!/bin/sh
+
+git for-each-ref --count=3 --sort='-*authordate' \
+--format='From: %(*authorname) %(*authoremail)
+Subject: %(*subject)
+Date: %(*authordate)
+Ref: %(*refname)
+
+%(*body)
+' 'refs/tags'
+------------
+
+
+A simple example showing the use of shell eval on the output,
+demonstrating the use of --shell. List the prefixes of all heads:
+------------
+#!/bin/sh
+
+git for-each-ref --shell --format="ref=%(refname)" refs/heads | \
+while read entry
+do
+ eval "$entry"
+ echo `dirname $ref`
+done
+------------
+
+
+A bit more elaborate report on tags, demonstrating that the format
+may be an entire script:
+------------
+#!/bin/sh
+
+fmt='
+ r=%(refname)
+ t=%(*objecttype)
+ T=${r#refs/tags/}
+
+ o=%(*objectname)
+ n=%(*authorname)
+ e=%(*authoremail)
+ s=%(*subject)
+ d=%(*authordate)
+ b=%(*body)
+
+ kind=Tag
+ if test "z$t" = z
+ then
+ # could be a lightweight tag
+ t=%(objecttype)
+ kind="Lightweight tag"
+ o=%(objectname)
+ n=%(authorname)
+ e=%(authoremail)
+ s=%(subject)
+ d=%(authordate)
+ b=%(body)
+ fi
+ echo "$kind $T points at a $t object $o"
+ if test "z$t" = zcommit
+ then
+ echo "The commit was authored by $n $e
+at $d, and titled
+
+ $s
+
+Its message reads as:
+"
+ echo "$b" | sed -e "s/^/ /"
+ echo
+ fi
+'
+
+eval=`git for-each-ref --shell --format="$fmt" \
+ --sort='*objecttype' \
+ --sort=-taggerdate \
+ refs/tags`
+eval "$eval"
+------------
+
+
+An example to show the usage of %(if)...%(then)...%(else)...%(end).
+This prefixes the current branch with a star.
+
+------------
+git for-each-ref --format="%(if)%(HEAD)%(then)* %(else) %(end)%(refname:short)" refs/heads/
+------------
+
+
+An example to show the usage of %(if)...%(then)...%(end).
+This prints the authorname, if present.
+
+------------
+git for-each-ref --format="%(refname)%(if)%(authorname)%(then) Authored by: %(authorname)%(end)"
+------------
+
+CAVEATS
+-------
+
+Note that the sizes of objects on disk are reported accurately, but care
+should be taken in drawing conclusions about which refs or objects are
+responsible for disk usage. The size of a packed non-delta object may be
+much larger than the size of objects which delta against it, but the
+choice of which object is the base and which is the delta is arbitrary
+and is subject to change during a repack.
+
+Note also that multiple copies of an object may be present in the object
+database; in this case, it is undefined which copy's size or delta base
+will be reported.
+
+NOTES
+-----
+
+include::ref-reachability-filters.adoc[]
+
+SEE ALSO
+--------
+linkgit:git-show-ref[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-for-each-repo.adoc b/git-for-each-repo.adoc
new file mode 100644
index 0000000..abe3527
--- /dev/null
+++ b/git-for-each-repo.adoc
@@ -0,0 +1,68 @@
+git-for-each-repo(1)
+====================
+
+NAME
+----
+git-for-each-repo - Run a Git command on a list of repositories
+
+
+SYNOPSIS
+--------
+[verse]
+'git for-each-repo' --config=<config> [--] <arguments>
+
+
+DESCRIPTION
+-----------
+Run a Git command on a list of repositories. The arguments after the
+known options or `--` indicator are used as the arguments for the Git
+subprocess.
+
+THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
+
+For example, we could run maintenance on each of a list of repositories
+stored in a `maintenance.repo` config variable using
+
+-------------
+git for-each-repo --config=maintenance.repo maintenance run
+-------------
+
+This will run `git -C <repo> maintenance run` for each value `<repo>`
+in the multi-valued config variable `maintenance.repo`.
+
+
+OPTIONS
+-------
+--config=<config>::
+ Use the given config variable as a multi-valued list storing
+ absolute path names. Iterate on that list of paths to run
+ the given arguments.
++
+These config values are loaded from system, global, and local Git config,
+as available. If `git for-each-repo` is run in a directory that is not a
+Git repository, then only the system and global config is used.
+
+--keep-going::
+ Continue with the remaining repositories if the command failed
+ on a repository. The exit code will still indicate that the
+ overall operation was not successful.
++
+Note that the exact exit code of the failing command is not passed
+through as the exit code of the `for-each-repo` command: If the command
+failed in any of the specified repositories, the overall exit code will
+be 1.
+
+SUBPROCESS BEHAVIOR
+-------------------
+
+If any `git -C <repo> <arguments>` subprocess returns a non-zero exit code,
+then the `git for-each-repo` process returns that exit code without running
+more subprocesses.
+
+Each `git -C <repo> <arguments>` subprocess inherits the standard file
+descriptors `stdin`, `stdout`, and `stderr`.
+
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-format-patch.adoc b/git-format-patch.adoc
new file mode 100644
index 0000000..a8b53db
--- /dev/null
+++ b/git-format-patch.adoc
@@ -0,0 +1,797 @@
+git-format-patch(1)
+===================
+
+NAME
+----
+git-format-patch - Prepare patches for e-mail submission
+
+
+SYNOPSIS
+--------
+[verse]
+'git format-patch' [-k] [(-o|--output-directory) <dir> | --stdout]
+ [--no-thread | --thread[=<style>]]
+ [(--attach|--inline)[=<boundary>] | --no-attach]
+ [-s | --signoff]
+ [--signature=<signature> | --no-signature]
+ [--signature-file=<file>]
+ [-n | --numbered | -N | --no-numbered]
+ [--start-number <n>] [--numbered-files]
+ [--in-reply-to=<message-id>] [--suffix=.<sfx>]
+ [--ignore-if-in-upstream] [--always]
+ [--cover-from-description=<mode>]
+ [--rfc[=<rfc>]] [--subject-prefix=<subject-prefix>]
+ [(--reroll-count|-v) <n>]
+ [--to=<email>] [--cc=<email>]
+ [--[no-]cover-letter] [--quiet]
+ [--[no-]encode-email-headers]
+ [--no-notes | --notes[=<ref>]]
+ [--interdiff=<previous>]
+ [--range-diff=<previous> [--creation-factor=<percent>]]
+ [--filename-max-length=<n>]
+ [--progress]
+ [<common-diff-options>]
+ [ <since> | <revision-range> ]
+
+DESCRIPTION
+-----------
+
+Prepare each non-merge commit with its "patch" in
+one "message" per commit, formatted to resemble a UNIX mailbox.
+The output of this command is convenient for e-mail submission or
+for use with 'git am'.
+
+A "message" generated by the command consists of three parts:
+
+* A brief metadata header that begins with `From <commit>`
+ with a fixed `Mon Sep 17 00:00:00 2001` datestamp to help programs
+ like "file(1)" to recognize that the file is an output from this
+ command, fields that record the author identity, the author date,
+ and the title of the change (taken from the first paragraph of the
+ commit log message).
+
+* The second and subsequent paragraphs of the commit log message.
+
+* The "patch", which is the "diff -p --stat" output (see
+ linkgit:git-diff[1]) between the commit and its parent.
+
+The log message and the patch are separated by a line with a
+three-dash line.
+
+There are two ways to specify which commits to operate on.
+
+1. A single commit, <since>, specifies that the commits leading
+ to the tip of the current branch that are not in the history
+ that leads to the <since> to be output.
+
+2. Generic <revision-range> expression (see "SPECIFYING
+ REVISIONS" section in linkgit:gitrevisions[7]) means the
+ commits in the specified range.
+
+The first rule takes precedence in the case of a single <commit>. To
+apply the second rule, i.e., format everything since the beginning of
+history up until <commit>, use the `--root` option: `git format-patch
+--root <commit>`. If you want to format only <commit> itself, you
+can do this with `git format-patch -1 <commit>`.
+
+By default, each output file is numbered sequentially from 1, and uses the
+first line of the commit message (massaged for pathname safety) as
+the filename. With the `--numbered-files` option, the output file names
+will only be numbers, without the first line of the commit appended.
+The names of the output files are printed to standard
+output, unless the `--stdout` option is specified.
+
+If `-o` is specified, output files are created in <dir>. Otherwise
+they are created in the current working directory. The default path
+can be set with the `format.outputDirectory` configuration option.
+The `-o` option takes precedence over `format.outputDirectory`.
+To store patches in the current working directory even when
+`format.outputDirectory` points elsewhere, use `-o .`. All directory
+components will be created.
+
+By default, the subject of a single patch is "[PATCH] " followed by
+the concatenation of lines from the commit message up to the first blank
+line (see the DISCUSSION section of linkgit:git-commit[1]).
+
+When multiple patches are output, the subject prefix will instead be
+"[PATCH n/m] ". To force 1/1 to be added for a single patch, use `-n`.
+To omit patch numbers from the subject, use `-N`.
+
+If given `--thread`, `git-format-patch` will generate `In-Reply-To` and
+`References` headers to make the second and subsequent patch mails appear
+as replies to the first mail; this also generates a `Message-ID` header to
+reference.
+
+OPTIONS
+-------
+:git-format-patch: 1
+include::diff-options.adoc[]
+
+-<n>::
+ Prepare patches from the topmost <n> commits.
+
+-o <dir>::
+--output-directory <dir>::
+ Use <dir> to store the resulting files, instead of the
+ current working directory.
+
+-n::
+--numbered::
+ Name output in '[PATCH n/m]' format, even with a single patch.
+
+-N::
+--no-numbered::
+ Name output in '[PATCH]' format.
+
+--start-number <n>::
+ Start numbering the patches at <n> instead of 1.
+
+--numbered-files::
+ Output file names will be a simple number sequence
+ without the default first line of the commit appended.
+
+-k::
+--keep-subject::
+ Do not strip/add '[PATCH]' from the first line of the
+ commit log message.
+
+-s::
+--signoff::
+ Add a `Signed-off-by` trailer to the commit message, using
+ the committer identity of yourself.
+ See the signoff option in linkgit:git-commit[1] for more information.
+
+--stdout::
+ Print all commits to the standard output in mbox format,
+ instead of creating a file for each one.
+
+--attach[=<boundary>]::
+ Create multipart/mixed attachment, the first part of
+ which is the commit message and the patch itself in the
+ second part, with `Content-Disposition: attachment`.
+
+--no-attach::
+ Disable the creation of an attachment, overriding the
+ configuration setting.
+
+--inline[=<boundary>]::
+ Create multipart/mixed attachment, the first part of
+ which is the commit message and the patch itself in the
+ second part, with `Content-Disposition: inline`.
+
+--thread[=<style>]::
+--no-thread::
+ Controls addition of `In-Reply-To` and `References` headers to
+ make the second and subsequent mails appear as replies to the
+ first. Also controls generation of the `Message-ID` header to
+ reference.
++
+The optional <style> argument can be either `shallow` or `deep`.
+'shallow' threading makes every mail a reply to the head of the
+series, where the head is chosen from the cover letter, the
+`--in-reply-to`, and the first patch mail, in this order. 'deep'
+threading makes every mail a reply to the previous one.
++
+The default is `--no-thread`, unless the `format.thread` configuration
+is set. `--thread` without an argument is equivalent to `--thread=shallow`.
++
+Beware that the default for 'git send-email' is to thread emails
+itself. If you want `git format-patch` to take care of threading, you
+will want to ensure that threading is disabled for `git send-email`.
+
+--in-reply-to=<message-id>::
+ Make the first mail (or all the mails with `--no-thread`) appear as a
+ reply to the given <message-id>, which avoids breaking threads to
+ provide a new patch series.
+
+--ignore-if-in-upstream::
+ Do not include a patch that matches a commit in
+ <until>..<since>. This will examine all patches reachable
+ from <since> but not from <until> and compare them with the
+ patches being generated, and any patch that matches is
+ ignored.
+
+--always::
+ Include patches for commits that do not introduce any change,
+ which are omitted by default.
+
+--cover-from-description=<mode>::
+ Controls which parts of the cover letter will be automatically
+ populated using the branch's description.
++
+If `<mode>` is `message` or `default`, the cover letter subject will be
+populated with placeholder text. The body of the cover letter will be
+populated with the branch's description. This is the default mode when
+no configuration nor command line option is specified.
++
+If `<mode>` is `subject`, the first paragraph of the branch description will
+populate the cover letter subject. The remainder of the description will
+populate the body of the cover letter.
++
+If `<mode>` is `auto`, if the first paragraph of the branch description
+is greater than 100 bytes, then the mode will be `message`, otherwise
+`subject` will be used.
++
+If `<mode>` is `none`, both the cover letter subject and body will be
+populated with placeholder text.
+
+--description-file=<file>::
+ Use the contents of <file> instead of the branch's description
+ for generating the cover letter.
+
+--subject-prefix=<subject-prefix>::
+ Instead of the standard '[PATCH]' prefix in the subject
+ line, instead use '[<subject-prefix>]'. This can be used
+ to name a patch series, and can be combined with the
+ `--numbered` option.
++
+The configuration variable `format.subjectPrefix` may also be used
+to configure a subject prefix to apply to a given repository for
+all patches. This is often useful on mailing lists which receive
+patches for several repositories and can be used to disambiguate
+the patches (with a value of e.g. "PATCH my-project").
+
+--filename-max-length=<n>::
+ Instead of the standard 64 bytes, chomp the generated output
+ filenames at around '<n>' bytes (too short a value will be
+ silently raised to a reasonable length). Defaults to the
+ value of the `format.filenameMaxLength` configuration
+ variable, or 64 if unconfigured.
+
+--rfc[=<rfc>]::
+ Prepends the string _<rfc>_ (defaults to "RFC") to
+ the subject prefix. As the subject prefix defaults to
+ "PATCH", you'll get "RFC PATCH" by default.
++
+RFC means "Request For Comments"; use this when sending
+an experimental patch for discussion rather than application.
+"--rfc=WIP" may also be a useful way to indicate that a patch
+is not complete yet ("WIP" stands for "Work In Progress").
++
+If the convention of the receiving community for a particular extra
+string is to have it _after_ the subject prefix, the string _<rfc>_
+can be prefixed with a dash ("`-`") to signal that the rest of
+the _<rfc>_ string should be appended to the subject prefix instead,
+e.g., `--rfc='-(WIP)'` results in "PATCH (WIP)".
+
+-v <n>::
+--reroll-count=<n>::
+ Mark the series as the <n>-th iteration of the topic. The
+ output filenames have `v<n>` prepended to them, and the
+ subject prefix ("PATCH" by default, but configurable via the
+ `--subject-prefix` option) has ` v<n>` appended to it. E.g.
+ `--reroll-count=4` may produce `v4-0001-add-makefile.patch`
+ file that has "Subject: [PATCH v4 1/20] Add makefile" in it.
+ `<n>` does not have to be an integer (e.g. "--reroll-count=4.4",
+ or "--reroll-count=4rev2" are allowed), but the downside of
+ using such a reroll-count is that the range-diff/interdiff
+ with the previous version does not state exactly which
+ version the new iteration is compared against.
+
+--to=<email>::
+ Add a `To:` header to the email headers. This is in addition
+ to any configured headers, and may be used multiple times.
+ The negated form `--no-to` discards all `To:` headers added so
+ far (from config or command line).
+
+--cc=<email>::
+ Add a `Cc:` header to the email headers. This is in addition
+ to any configured headers, and may be used multiple times.
+ The negated form `--no-cc` discards all `Cc:` headers added so
+ far (from config or command line).
+
+--from::
+--from=<ident>::
+ Use `ident` in the `From:` header of each commit email. If the
+ author ident of the commit is not textually identical to the
+ provided `ident`, place a `From:` header in the body of the
+ message with the original author. If no `ident` is given, use
+ the committer ident.
++
+Note that this option is only useful if you are actually sending the
+emails and want to identify yourself as the sender, but retain the
+original author (and `git am` will correctly pick up the in-body
+header). Note also that `git send-email` already handles this
+transformation for you, and this option should not be used if you are
+feeding the result to `git send-email`.
+
+--[no-]force-in-body-from::
+ With the e-mail sender specified via the `--from` option, by
+ default, an in-body "From:" to identify the real author of
+ the commit is added at the top of the commit log message if
+ the sender is different from the author. With this option,
+ the in-body "From:" is added even when the sender and the
+ author have the same name and address, which may help if the
+ mailing list software mangles the sender's identity.
+ Defaults to the value of the `format.forceInBodyFrom`
+ configuration variable.
+
+--add-header=<header>::
+ Add an arbitrary header to the email headers. This is in addition
+ to any configured headers, and may be used multiple times.
+ For example, `--add-header="Organization: git-foo"`.
+ The negated form `--no-add-header` discards *all* (`To:`,
+ `Cc:`, and custom) headers added so far from config or command
+ line.
+
+--[no-]cover-letter::
+ In addition to the patches, generate a cover letter file
+ containing the branch description, shortlog and the overall diffstat. You can
+ fill in a description in the file before sending it out.
+
+--encode-email-headers::
+--no-encode-email-headers::
+ Encode email headers that have non-ASCII characters with
+ "Q-encoding" (described in RFC 2047), instead of outputting the
+ headers verbatim. Defaults to the value of the
+ `format.encodeEmailHeaders` configuration variable.
+
+--interdiff=<previous>::
+ As a reviewer aid, insert an interdiff into the cover letter,
+ or as commentary of the lone patch of a 1-patch series, showing
+ the differences between the previous version of the patch series and
+ the series currently being formatted. `previous` is a single revision
+ naming the tip of the previous series which shares a common base with
+ the series being formatted (for example `git format-patch
+ --cover-letter --interdiff=feature/v1 -3 feature/v2`).
+
+--range-diff=<previous>::
+ As a reviewer aid, insert a range-diff (see linkgit:git-range-diff[1])
+ into the cover letter, or as commentary of the lone patch of a
+ 1-patch series, showing the differences between the previous
+ version of the patch series and the series currently being formatted.
+ `previous` can be a single revision naming the tip of the previous
+ series if it shares a common base with the series being formatted (for
+ example `git format-patch --cover-letter --range-diff=feature/v1 -3
+ feature/v2`), or a revision range if the two versions of the series are
+ disjoint (for example `git format-patch --cover-letter
+ --range-diff=feature/v1~3..feature/v1 -3 feature/v2`).
++
+Note that diff options passed to the command affect how the primary
+product of `format-patch` is generated, and they are not passed to
+the underlying `range-diff` machinery used to generate the cover-letter
+material (this may change in the future).
+
+--creation-factor=<percent>::
+ Used with `--range-diff`, tweak the heuristic which matches up commits
+ between the previous and current series of patches by adjusting the
+ creation/deletion cost fudge factor. See linkgit:git-range-diff[1])
+ for details.
++
+Defaults to 999 (the linkgit:git-range-diff[1] uses 60), as the use
+case is to show comparison with an older iteration of the same
+topic and the tool should find more correspondence between the two
+sets of patches.
+
+--notes[=<ref>]::
+--no-notes::
+ Append the notes (see linkgit:git-notes[1]) for the commit
+ after the three-dash line.
++
+The expected use case of this is to write supporting explanation for
+the commit that does not belong to the commit log message proper,
+and include it with the patch submission. While one can simply write
+these explanations after `format-patch` has run but before sending,
+keeping them as Git notes allows them to be maintained between versions
+of the patch series (but see the discussion of the `notes.rewrite`
+configuration options in linkgit:git-notes[1] to use this workflow).
++
+The default is `--no-notes`, unless the `format.notes` configuration is
+set.
+
+--[no-]signature=<signature>::
+ Add a signature to each message produced. Per RFC 3676 the signature
+ is separated from the body by a line with '-- ' on it. If the
+ signature option is omitted the signature defaults to the Git version
+ number.
+
+--signature-file=<file>::
+ Works just like --signature except the signature is read from a file.
+
+--suffix=.<sfx>::
+ Instead of using `.patch` as the suffix for generated
+ filenames, use specified suffix. A common alternative is
+ `--suffix=.txt`. Leaving this empty will remove the `.patch`
+ suffix.
++
+Note that the leading character does not have to be a dot; for example,
+you can use `--suffix=-patch` to get `0001-description-of-my-change-patch`.
+
+-q::
+--quiet::
+ Do not print the names of the generated files to standard output.
+
+--no-binary::
+ Do not output contents of changes in binary files, instead
+ display a notice that those files changed. Patches generated
+ using this option cannot be applied properly, but they are
+ still useful for code review.
+
+--zero-commit::
+ Output an all-zero hash in each patch's From header instead
+ of the hash of the commit.
+
+--[no-]base[=<commit>]::
+ Record the base tree information to identify the state the
+ patch series applies to. See the BASE TREE INFORMATION section
+ below for details. If <commit> is "auto", a base commit is
+ automatically chosen. The `--no-base` option overrides a
+ `format.useAutoBase` configuration.
+
+--root::
+ Treat the revision argument as a <revision-range>, even if it
+ is just a single commit (that would normally be treated as a
+ <since>). Note that root commits included in the specified
+ range are always formatted as creation patches, independently
+ of this flag.
+
+--progress::
+ Show progress reports on stderr as patches are generated.
+
+CONFIGURATION
+-------------
+You can specify extra mail header lines to be added to each message,
+defaults for the subject prefix and file suffix, number patches when
+outputting more than one patch, add "To:" or "Cc:" headers, configure
+attachments, change the patch output directory, and sign off patches
+with configuration variables.
+
+------------
+[format]
+ headers = "Organization: git-foo\n"
+ subjectPrefix = CHANGE
+ suffix = .txt
+ numbered = auto
+ to = <email>
+ cc = <email>
+ attach [ = mime-boundary-string ]
+ signOff = true
+ outputDirectory = <directory>
+ coverLetter = auto
+ coverFromDescription = auto
+------------
+
+
+DISCUSSION
+----------
+
+The patch produced by 'git format-patch' is in UNIX mailbox format,
+with a fixed "magic" time stamp to indicate that the file is output
+from format-patch rather than a real mailbox, like so:
+
+------------
+From 8f72bad1baf19a53459661343e21d6491c3908d3 Mon Sep 17 00:00:00 2001
+From: Tony Luck <tony.luck@intel.com>
+Date: Tue, 13 Jul 2010 11:42:54 -0700
+Subject: [PATCH] =?UTF-8?q?[IA64]=20Put=20ia64=20config=20files=20on=20the=20?=
+ =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20diet?=
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+arch/arm config files were slimmed down using a python script
+(See commit c2330e286f68f1c408b4aa6515ba49d57f05beae comment)
+
+Do the same for ia64 so we can have sleek & trim looking
+...
+------------
+
+Typically it will be placed in a MUA's drafts folder, edited to add
+timely commentary that should not go in the changelog after the three
+dashes, and then sent as a message whose body, in our example, starts
+with "arch/arm config files were...". On the receiving end, readers
+can save interesting patches in a UNIX mailbox and apply them with
+linkgit:git-am[1].
+
+When a patch is part of an ongoing discussion, the patch generated by
+'git format-patch' can be tweaked to take advantage of the 'git am
+--scissors' feature. After your response to the discussion comes a
+line that consists solely of "`-- >8 --`" (scissors and perforation),
+followed by the patch with unnecessary header fields removed:
+
+------------
+...
+> So we should do such-and-such.
+
+Makes sense to me. How about this patch?
+
+-- >8 --
+Subject: [IA64] Put ia64 config files on the Uwe Kleine-König diet
+
+arch/arm config files were slimmed down using a python script
+...
+------------
+
+When sending a patch this way, most often you are sending your own
+patch, so in addition to the "`From $SHA1 $magic_timestamp`" marker you
+should omit `From:` and `Date:` lines from the patch file. The patch
+title is likely to be different from the subject of the discussion the
+patch is in response to, so it is likely that you would want to keep
+the Subject: line, like the example above.
+
+Checking for patch corruption
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Many mailers if not set up properly will corrupt whitespace. Here are
+two common types of corruption:
+
+* Empty context lines that do not have _any_ whitespace.
+
+* Non-empty context lines that have one extra whitespace at the
+ beginning.
+
+One way to test if your MUA is set up correctly is:
+
+* Send the patch to yourself, exactly the way you would, except
+ with To: and Cc: lines that do not contain the list and
+ maintainer address.
+
+* Save that patch to a file in UNIX mailbox format. Call it a.patch,
+ say.
+
+* Apply it:
+
+ $ git fetch <project> master:test-apply
+ $ git switch test-apply
+ $ git restore --source=HEAD --staged --worktree :/
+ $ git am a.patch
+
+If it does not apply correctly, there can be various reasons.
+
+* The patch itself does not apply cleanly. That is _bad_ but
+ does not have much to do with your MUA. You might want to rebase
+ the patch with linkgit:git-rebase[1] before regenerating it in
+ this case.
+
+* The MUA corrupted your patch; "am" would complain that
+ the patch does not apply. Look in the .git/rebase-apply/ subdirectory and
+ see what 'patch' file contains and check for the common
+ corruption patterns mentioned above.
+
+* While at it, check the 'info' and 'final-commit' files as well.
+ If what is in 'final-commit' is not exactly what you would want to
+ see in the commit log message, it is very likely that the
+ receiver would end up hand editing the log message when applying
+ your patch. Things like "Hi, this is my first patch.\n" in the
+ patch e-mail should come after the three-dash line that signals
+ the end of the commit message.
+
+MUA-SPECIFIC HINTS
+------------------
+Here are some hints on how to successfully submit patches inline using
+various mailers.
+
+GMail
+~~~~~
+GMail does not have any way to turn off line wrapping in the web
+interface, so it will mangle any emails that you send. You can however
+use "git send-email" and send your patches through the GMail SMTP server, or
+use any IMAP email client to connect to the google IMAP server and forward
+the emails through that.
+
+For hints on using 'git send-email' to send your patches through the
+GMail SMTP server, see the EXAMPLE section of linkgit:git-send-email[1].
+
+For hints on submission using the IMAP interface, see the EXAMPLE
+section of linkgit:git-imap-send[1].
+
+Thunderbird
+~~~~~~~~~~~
+By default, Thunderbird will both wrap emails as well as flag
+them as being 'format=flowed', both of which will make the
+resulting email unusable by Git.
+
+There are three different approaches: use an add-on to turn off line wraps,
+configure Thunderbird to not mangle patches, or use
+an external editor to keep Thunderbird from mangling the patches.
+
+Approach #1 (add-on)
+^^^^^^^^^^^^^^^^^^^^
+
+Install the Toggle Word Wrap add-on that is available from
+https://addons.mozilla.org/thunderbird/addon/toggle-word-wrap/
+It adds a menu entry "Enable Word Wrap" in the composer's "Options" menu
+that you can tick off. Now you can compose the message as you otherwise do
+(cut + paste, 'git format-patch' | 'git imap-send', etc), but you have to
+insert line breaks manually in any text that you type.
+
+Approach #2 (configuration)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Three steps:
+
+1. Configure your mail server composition as plain text:
+ Edit...Account Settings...Composition & Addressing,
+ uncheck "Compose Messages in HTML".
+
+2. Configure your general composition window to not wrap.
++
+In Thunderbird 2:
+Edit..Preferences..Composition, wrap plain text messages at 0
++
+In Thunderbird 3:
+Edit..Preferences..Advanced..Config Editor. Search for
+"mail.wrap_long_lines".
+Toggle it to make sure it is set to `false`. Also, search for
+"mailnews.wraplength" and set the value to 0.
+
+3. Disable the use of format=flowed:
+ Edit..Preferences..Advanced..Config Editor. Search for
+ "mailnews.send_plaintext_flowed".
+ Toggle it to make sure it is set to `false`.
+
+After that is done, you should be able to compose email as you
+otherwise would (cut + paste, 'git format-patch' | 'git imap-send', etc),
+and the patches will not be mangled.
+
+Approach #3 (external editor)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The following Thunderbird extensions are needed:
+AboutConfig from https://mjg.github.io/AboutConfig/ and
+External Editor from https://globs.org/articles.php?lng=en&pg=8
+
+1. Prepare the patch as a text file using your method of choice.
+
+2. Before opening a compose window, use Edit->Account Settings to
+ uncheck the "Compose messages in HTML format" setting in the
+ "Composition & Addressing" panel of the account to be used to
+ send the patch.
+
+3. In the main Thunderbird window, 'before' you open the compose
+ window for the patch, use Tools->about:config to set the
+ following to the indicated values:
++
+----------
+ mailnews.send_plaintext_flowed => false
+ mailnews.wraplength => 0
+----------
+
+4. Open a compose window and click the external editor icon.
+
+5. In the external editor window, read in the patch file and exit
+ the editor normally.
+
+Side note: it may be possible to do step 2 with
+about:config and the following settings but no one's tried yet.
+
+----------
+ mail.html_compose => false
+ mail.identity.default.compose_html => false
+ mail.identity.id?.compose_html => false
+----------
+
+There is a script in contrib/thunderbird-patch-inline which can help
+you include patches with Thunderbird in an easy way. To use it, do the
+steps above and then use the script as the external editor.
+
+KMail
+~~~~~
+This should help you to submit patches inline using KMail.
+
+1. Prepare the patch as a text file.
+
+2. Click on New Mail.
+
+3. Go under "Options" in the Composer window and be sure that
+ "Word wrap" is not set.
+
+4. Use Message -> Insert file... and insert the patch.
+
+5. Back in the compose window: add whatever other text you wish to the
+ message, complete the addressing and subject fields, and press send.
+
+BASE TREE INFORMATION
+---------------------
+
+The base tree information block is used for maintainers or third party
+testers to know the exact state the patch series applies to. It consists
+of the 'base commit', which is a well-known commit that is part of the
+stable part of the project history everybody else works off of, and zero
+or more 'prerequisite patches', which are well-known patches in flight
+that is not yet part of the 'base commit' that need to be applied on top
+of 'base commit' in topological order before the patches can be applied.
+
+The 'base commit' is shown as "base-commit: " followed by the 40-hex of
+the commit object name. A 'prerequisite patch' is shown as
+"prerequisite-patch-id: " followed by the 40-hex 'patch id', which can
+be obtained by passing the patch through the `git patch-id --stable`
+command.
+
+Imagine that on top of the public commit P, you applied well-known
+patches X, Y and Z from somebody else, and then built your three-patch
+series A, B, C, the history would be like:
+
+................................................
+---P---X---Y---Z---A---B---C
+................................................
+
+With `git format-patch --base=P -3 C` (or variants thereof, e.g. with
+`--cover-letter` or using `Z..C` instead of `-3 C` to specify the
+range), the base tree information block is shown at the end of the
+first message the command outputs (either the first patch, or the
+cover letter), like this:
+
+------------
+base-commit: P
+prerequisite-patch-id: X
+prerequisite-patch-id: Y
+prerequisite-patch-id: Z
+------------
+
+For non-linear topology, such as
+
+................................................
+---P---X---A---M---C
+ \ /
+ Y---Z---B
+................................................
+
+You can also use `git format-patch --base=P -3 C` to generate patches
+for A, B and C, and the identifiers for P, X, Y, Z are appended at the
+end of the first message.
+
+If set `--base=auto` in cmdline, it will automatically compute
+the base commit as the merge base of tip commit of the remote-tracking
+branch and revision-range specified in cmdline.
+For a local branch, you need to make it to track a remote branch by `git branch
+--set-upstream-to` before using this option.
+
+EXAMPLES
+--------
+
+* Extract commits between revisions R1 and R2, and apply them on top of
+ the current branch using 'git am' to cherry-pick them:
++
+------------
+$ git format-patch -k --stdout R1..R2 | git am -3 -k
+------------
+
+* Extract all commits which are in the current branch but not in the
+ origin branch:
++
+------------
+$ git format-patch origin
+------------
++
+For each commit a separate file is created in the current directory.
+
+* Extract all commits that lead to 'origin' since the inception of the
+ project:
++
+------------
+$ git format-patch --root origin
+------------
+
+* The same as the previous one:
++
+------------
+$ git format-patch -M -B origin
+------------
++
+Additionally, it detects and handles renames and complete rewrites
+intelligently to produce a renaming patch. A renaming patch reduces
+the amount of text output, and generally makes it easier to review.
+Note that non-Git "patch" programs won't understand renaming patches, so
+use it only when you know the recipient uses Git to apply your patch.
+
+* Extract three topmost commits from the current branch and format them
+ as e-mailable patches:
++
+------------
+$ git format-patch -3
+------------
+
+CAVEATS
+-------
+
+Note that `format-patch` will omit merge commits from the output, even
+if they are part of the requested range. A simple "patch" does not
+include enough information for the receiving end to reproduce the same
+merge commit.
+
+SEE ALSO
+--------
+linkgit:git-am[1], linkgit:git-send-email[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-fsck-objects.adoc b/git-fsck-objects.adoc
new file mode 100644
index 0000000..eec4bdb
--- /dev/null
+++ b/git-fsck-objects.adoc
@@ -0,0 +1,22 @@
+git-fsck-objects(1)
+===================
+
+NAME
+----
+git-fsck-objects - Verifies the connectivity and validity of the objects in the database
+
+
+SYNOPSIS
+--------
+[verse]
+'git fsck-objects' ...
+
+DESCRIPTION
+-----------
+
+This is a synonym for linkgit:git-fsck[1]. Please refer to the
+documentation of that command.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-fsck.adoc b/git-fsck.adoc
new file mode 100644
index 0000000..8f32800
--- /dev/null
+++ b/git-fsck.adoc
@@ -0,0 +1,181 @@
+git-fsck(1)
+===========
+
+NAME
+----
+git-fsck - Verifies the connectivity and validity of the objects in the database
+
+
+SYNOPSIS
+--------
+[verse]
+'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
+ [--[no-]full] [--strict] [--verbose] [--lost-found]
+ [--[no-]dangling] [--[no-]progress] [--connectivity-only]
+ [--[no-]name-objects] [<object>...]
+
+DESCRIPTION
+-----------
+Verifies the connectivity and validity of the objects in the database.
+
+OPTIONS
+-------
+<object>::
+ An object to treat as the head of an unreachability trace.
++
+If no objects are given, 'git fsck' defaults to using the
+index file, all SHA-1 references in the `refs` namespace, and all reflogs
+(unless --no-reflogs is given) as heads.
+
+--unreachable::
+ Print out objects that exist but that aren't reachable from any
+ of the reference nodes.
+
+--[no-]dangling::
+ Print objects that exist but that are never 'directly' used (default).
+ `--no-dangling` can be used to omit this information from the output.
+
+--root::
+ Report root nodes.
+
+--tags::
+ Report tags.
+
+--cache::
+ Consider any object recorded in the index also as a head node for
+ an unreachability trace.
+
+--no-reflogs::
+ Do not consider commits that are referenced only by an
+ entry in a reflog to be reachable. This option is meant
+ only to search for commits that used to be in a ref, but
+ now aren't, but are still in that corresponding reflog.
+
+--full::
+ Check not just objects in GIT_OBJECT_DIRECTORY
+ ($GIT_DIR/objects), but also the ones found in alternate
+ object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES
+ or $GIT_DIR/objects/info/alternates,
+ and in packed Git archives found in $GIT_DIR/objects/pack
+ and corresponding pack subdirectories in alternate
+ object pools. This is now default; you can turn it off
+ with --no-full.
+
+--connectivity-only::
+ Check only the connectivity of reachable objects, making sure
+ that any objects referenced by a reachable tag, commit, or tree
+ are present. This speeds up the operation by avoiding reading
+ blobs entirely (though it does still check that referenced blobs
+ exist). This will detect corruption in commits and trees, but
+ not do any semantic checks (e.g., for format errors). Corruption
+ in blob objects will not be detected at all.
++
+Unreachable tags, commits, and trees will also be accessed to find the
+tips of dangling segments of history. Use `--no-dangling` if you don't
+care about this output and want to speed it up further.
+
+--strict::
+ Enable more strict checking, namely to catch a file mode
+ recorded with g+w bit set, which was created by older
+ versions of Git. Existing repositories, including the
+ Linux kernel, Git itself, and sparse repository have old
+ objects that trigger this check, but it is recommended
+ to check new projects with this flag.
+
+--verbose::
+ Be chatty.
+
+--lost-found::
+ Write dangling objects into .git/lost-found/commit/ or
+ .git/lost-found/other/, depending on type. If the object is
+ a blob, the contents are written into the file, rather than
+ its object name.
+
+--name-objects::
+ When displaying names of reachable objects, in addition to the
+ SHA-1 also display a name that describes *how* they are reachable,
+ compatible with linkgit:git-rev-parse[1], e.g.
+ `HEAD@{1234567890}~25^2:src/`.
+
+--[no-]progress::
+ Progress status is reported on the standard error stream by
+ default when it is attached to a terminal, unless
+ --no-progress or --verbose is specified. --progress forces
+ progress status even if the standard error stream is not
+ directed to a terminal.
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/fsck.adoc[]
+
+DISCUSSION
+----------
+
+git-fsck tests SHA-1 and general object sanity, and it does full tracking
+of the resulting reachability and everything else. It prints out any
+corruption it finds (missing or bad objects), and if you use the
+`--unreachable` flag it will also print out objects that exist but that
+aren't reachable from any of the specified head nodes (or the default
+set, as mentioned above).
+
+Any corrupt objects you will have to find in backups or other archives
+(i.e., you can just remove them and do an 'rsync' with some other site in
+the hopes that somebody else has the object you have corrupted).
+
+If core.commitGraph is true, the commit-graph file will also be inspected
+using 'git commit-graph verify'. See linkgit:git-commit-graph[1].
+
+Extracted Diagnostics
+---------------------
+
+unreachable <type> <object>::
+ The <type> object <object>, isn't actually referred to directly
+ or indirectly in any of the trees or commits seen. This can
+ mean that there's another root node that you're not specifying
+ or that the tree is corrupt. If you haven't missed a root node
+ then you might as well delete unreachable nodes since they
+ can't be used.
+
+missing <type> <object>::
+ The <type> object <object>, is referred to but isn't present in
+ the database.
+
+dangling <type> <object>::
+ The <type> object <object>, is present in the database but never
+ 'directly' used. A dangling commit could be a root node.
+
+hash mismatch <object>::
+ The database has an object whose hash doesn't match the
+ object database value.
+ This indicates a serious data integrity problem.
+
+
+FSCK MESSAGES
+-------------
+
+The following lists the types of errors `git fsck` detects and what
+each error means, with their default severity. The severity of the
+error, other than those that are marked as "(FATAL)", can be tweaked
+by setting the corresponding `fsck.<msg-id>` configuration variable.
+
+include::fsck-msgids.adoc[]
+
+
+Environment Variables
+---------------------
+
+GIT_OBJECT_DIRECTORY::
+ used to specify the object database root (usually $GIT_DIR/objects)
+
+GIT_INDEX_FILE::
+ used to specify the index file of the index
+
+GIT_ALTERNATE_OBJECT_DIRECTORIES::
+ used to specify additional object database roots (usually unset)
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-fsmonitor--daemon.adoc b/git-fsmonitor--daemon.adoc
new file mode 100644
index 0000000..8fe5241
--- /dev/null
+++ b/git-fsmonitor--daemon.adoc
@@ -0,0 +1,106 @@
+git-fsmonitor{litdd}daemon(1)
+=============================
+
+NAME
+----
+git-fsmonitor--daemon - A Built-in Filesystem Monitor
+
+SYNOPSIS
+--------
+[verse]
+'git fsmonitor{litdd}daemon' start
+'git fsmonitor{litdd}daemon' run
+'git fsmonitor{litdd}daemon' stop
+'git fsmonitor{litdd}daemon' status
+
+DESCRIPTION
+-----------
+
+A daemon to watch the working directory for file and directory
+changes using platform-specific filesystem notification facilities.
+
+This daemon communicates directly with commands like `git status`
+using the link:technical/api-simple-ipc.html[simple IPC] interface
+instead of the slower linkgit:githooks[5] interface.
+
+This daemon is built into Git so that no third-party tools are
+required.
+
+OPTIONS
+-------
+
+start::
+ Starts a daemon in the background.
+
+run::
+ Runs a daemon in the foreground.
+
+stop::
+ Stops the daemon running in the current working
+ directory, if present.
+
+status::
+ Exits with zero status if a daemon is watching the
+ current working directory.
+
+REMARKS
+-------
+
+This daemon is a long running process used to watch a single working
+directory and maintain a list of the recently changed files and
+directories. Performance of commands such as `git status` can be
+increased if they just ask for a summary of changes to the working
+directory and can avoid scanning the disk.
+
+When `core.fsmonitor` is set to `true` (see linkgit:git-config[1])
+commands, such as `git status`, will ask the daemon for changes and
+automatically start it (if necessary).
+
+For more information see the "File System Monitor" section in
+linkgit:git-update-index[1].
+
+CAVEATS
+-------
+
+The fsmonitor daemon does not currently know about submodules and does
+not know to filter out filesystem events that happen within a
+submodule. If fsmonitor daemon is watching a super repo and a file is
+modified within the working directory of a submodule, it will report
+the change (as happening against the super repo). However, the client
+will properly ignore these extra events, so performance may be affected
+but it will not cause an incorrect result.
+
+By default, the fsmonitor daemon refuses to work with network-mounted
+repositories; this may be overridden by setting `fsmonitor.allowRemote` to
+`true`. Note, however, that the fsmonitor daemon is not guaranteed to work
+correctly with all network-mounted repositories, so such use is considered
+experimental.
+
+On Mac OS, the inter-process communication (IPC) between various Git
+commands and the fsmonitor daemon is done via a Unix domain socket (UDS) -- a
+special type of file -- which is supported by native Mac OS filesystems,
+but not on network-mounted filesystems, NTFS, or FAT32. Other filesystems
+may or may not have the needed support; the fsmonitor daemon is not guaranteed
+to work with these filesystems and such use is considered experimental.
+
+By default, the socket is created in the `.git` directory. However, if the
+`.git` directory is on a network-mounted filesystem, it will instead be
+created at `$HOME/.git-fsmonitor-*` unless `$HOME` itself is on a
+network-mounted filesystem, in which case you must set the configuration
+variable `fsmonitor.socketDir` to the path of a directory on a Mac OS native
+filesystem in which to create the socket file.
+
+If none of the above directories (`.git`, `$HOME`, or `fsmonitor.socketDir`)
+is on a native Mac OS file filesystem the fsmonitor daemon will report an
+error that will cause the daemon and the currently running command to exit.
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/fsmonitor--daemon.adoc[]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-gc.adoc b/git-gc.adoc
new file mode 100644
index 0000000..526ce01
--- /dev/null
+++ b/git-gc.adoc
@@ -0,0 +1,185 @@
+git-gc(1)
+=========
+
+NAME
+----
+git-gc - Cleanup unnecessary files and optimize the local repository
+
+
+SYNOPSIS
+--------
+[verse]
+'git gc' [--aggressive] [--auto] [--[no-]detach] [--quiet] [--prune=<date> | --no-prune] [--force] [--keep-largest-pack]
+
+DESCRIPTION
+-----------
+Runs a number of housekeeping tasks within the current repository,
+such as compressing file revisions (to reduce disk space and increase
+performance), removing unreachable objects which may have been
+created from prior invocations of 'git add', packing refs, pruning
+reflog, rerere metadata or stale working trees. May also update ancillary
+indexes such as the commit-graph.
+
+When common porcelain operations that create objects are run, they
+will check whether the repository has grown substantially since the
+last maintenance, and if so run `git gc` automatically. See `gc.auto`
+below for how to disable this behavior.
+
+Running `git gc` manually should only be needed when adding objects to
+a repository without regularly running such porcelain commands, to do
+a one-off repository optimization, or e.g. to clean up a suboptimal
+mass-import. See the "PACKFILE OPTIMIZATION" section in
+linkgit:git-fast-import[1] for more details on the import case.
+
+OPTIONS
+-------
+
+--aggressive::
+ Usually 'git gc' runs very quickly while providing good disk
+ space utilization and performance. This option will cause
+ 'git gc' to more aggressively optimize the repository at the expense
+ of taking much more time. The effects of this optimization are
+ mostly persistent. See the "AGGRESSIVE" section below for details.
+
+--auto::
+ With this option, 'git gc' checks whether any housekeeping is
+ required; if not, it exits without performing any work.
++
+See the `gc.auto` option in the "CONFIGURATION" section below for how
+this heuristic works.
++
+Once housekeeping is triggered by exceeding the limits of
+configuration options such as `gc.auto` and `gc.autoPackLimit`, all
+other housekeeping tasks (e.g. rerere, working trees, reflog...) will
+be performed as well.
+
+--[no-]detach::
+ Run in the background if the system supports it. This option overrides
+ the `gc.autoDetach` config.
+
+--[no-]cruft::
+ When expiring unreachable objects, pack them separately into a
+ cruft pack instead of storing them as loose objects. `--cruft`
+ is on by default.
+
+--max-cruft-size=<n>::
+ When packing unreachable objects into a cruft pack, limit the
+ size of new cruft packs to be at most `<n>` bytes. Overrides any
+ value specified via the `gc.maxCruftSize` configuration. See
+ the `--max-cruft-size` option of linkgit:git-repack[1] for
+ more.
+
+--expire-to=<dir>::
+ When packing unreachable objects into a cruft pack, write a cruft
+ pack containing pruned objects (if any) to the directory `<dir>`.
+ This option only has an effect when used together with `--cruft`.
+ See the `--expire-to` option of linkgit:git-repack[1] for
+ more information.
+
+--prune=<date>::
+ Prune loose objects older than date (default is 2 weeks ago,
+ overridable by the config variable `gc.pruneExpire`).
+ --prune=now prunes loose objects regardless of their age and
+ increases the risk of corruption if another process is writing to
+ the repository concurrently; see "NOTES" below. --prune is on by
+ default.
+
+--no-prune::
+ Do not prune any loose objects.
+
+--quiet::
+ Suppress all progress reports.
+
+--force::
+ Force `git gc` to run even if there may be another `git gc`
+ instance running on this repository.
+
+--keep-largest-pack::
+ All packs except the largest non-cruft pack, any packs marked
+ with a `.keep` file, and any cruft pack(s) are consolidated into
+ a single pack. When this option is used, `gc.bigPackThreshold`
+ is ignored.
+
+AGGRESSIVE
+----------
+
+When the `--aggressive` option is supplied, linkgit:git-repack[1] will
+be invoked with the `-f` flag, which in turn will pass
+`--no-reuse-delta` to linkgit:git-pack-objects[1]. This will throw
+away any existing deltas and re-compute them, at the expense of
+spending much more time on the repacking.
+
+The effects of this are mostly persistent, e.g. when packs and loose
+objects are coalesced into one another pack the existing deltas in
+that pack might get re-used, but there are also various cases where we
+might pick a sub-optimal delta from a newer pack instead.
+
+Furthermore, supplying `--aggressive` will tweak the `--depth` and
+`--window` options passed to linkgit:git-repack[1]. See the
+`gc.aggressiveDepth` and `gc.aggressiveWindow` settings below. By
+using a larger window size we're more likely to find more optimal
+deltas.
+
+It's probably not worth it to use this option on a given repository
+without running tailored performance benchmarks on it. It takes a lot
+more time, and the resulting space/delta optimization may or may not
+be worth it. Not using this at all is the right trade-off for most
+users and their repositories.
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/gc.adoc[]
+
+NOTES
+-----
+
+'git gc' tries very hard not to delete objects that are referenced
+anywhere in your repository. In particular, it will keep not only
+objects referenced by your current set of branches and tags, but also
+objects referenced by the index, remote-tracking branches, reflogs
+(which may reference commits in branches that were later amended or
+rewound), and anything else in the refs/* namespace. Note that a note
+(of the kind created by 'git notes') attached to an object does not
+contribute in keeping the object alive. If you are expecting some
+objects to be deleted and they aren't, check all of those locations
+and decide whether it makes sense in your case to remove those
+references.
+
+On the other hand, when 'git gc' runs concurrently with another process,
+there is a risk of it deleting an object that the other process is using
+but hasn't created a reference to. This may just cause the other process
+to fail or may corrupt the repository if the other process later adds a
+reference to the deleted object. Git has two features that significantly
+mitigate this problem:
+
+. Any object with modification time newer than the `--prune` date is kept,
+ along with everything reachable from it.
+
+. Most operations that add an object to the database update the
+ modification time of the object if it is already present so that #1
+ applies.
+
+However, these features fall short of a complete solution, so users who
+run commands concurrently have to live with some risk of corruption (which
+seems to be low in practice).
+
+HOOKS
+-----
+
+The 'git gc --auto' command will run the 'pre-auto-gc' hook. See
+linkgit:githooks[5] for more information.
+
+
+SEE ALSO
+--------
+linkgit:git-prune[1]
+linkgit:git-reflog[1]
+linkgit:git-repack[1]
+linkgit:git-rerere[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-get-tar-commit-id.adoc b/git-get-tar-commit-id.adoc
new file mode 100644
index 0000000..b537bb4
--- /dev/null
+++ b/git-get-tar-commit-id.adoc
@@ -0,0 +1,30 @@
+git-get-tar-commit-id(1)
+========================
+
+NAME
+----
+git-get-tar-commit-id - Extract commit ID from an archive created using git-archive
+
+
+SYNOPSIS
+--------
+[verse]
+'git get-tar-commit-id'
+
+
+DESCRIPTION
+-----------
+
+Read a tar archive created by 'git archive' from the standard input
+and extract the commit ID stored in it. It reads only the first
+1024 bytes of input, thus its runtime is not influenced by the size
+of the tar archive very much.
+
+If no commit ID is found, 'git get-tar-commit-id' quietly exits with a
+return code of 1. This can happen if the archive had not been created
+using 'git archive' or if the first parameter of 'git archive' had been
+a tree ID instead of a commit ID or tag.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-grep.adoc b/git-grep.adoc
new file mode 100644
index 0000000..a548585
--- /dev/null
+++ b/git-grep.adoc
@@ -0,0 +1,360 @@
+git-grep(1)
+===========
+
+NAME
+----
+git-grep - Print lines matching a pattern
+
+
+SYNOPSIS
+--------
+[verse]
+'git grep' [-a | --text] [-I] [--textconv] [-i | --ignore-case] [-w | --word-regexp]
+ [-v | --invert-match] [-h|-H] [--full-name]
+ [-E | --extended-regexp] [-G | --basic-regexp]
+ [-P | --perl-regexp]
+ [-F | --fixed-strings] [-n | --line-number] [--column]
+ [-l | --files-with-matches] [-L | --files-without-match]
+ [(-O | --open-files-in-pager) [<pager>]]
+ [-z | --null]
+ [ -o | --only-matching ] [-c | --count] [--all-match] [-q | --quiet]
+ [--max-depth <depth>] [--[no-]recursive]
+ [--color[=<when>] | --no-color]
+ [--break] [--heading] [-p | --show-function]
+ [-A <post-context>] [-B <pre-context>] [-C <context>]
+ [-W | --function-context]
+ [(-m | --max-count) <num>]
+ [--threads <num>]
+ [-f <file>] [-e] <pattern>
+ [--and|--or|--not|(|)|-e <pattern>...]
+ [--recurse-submodules] [--parent-basename <basename>]
+ [ [--[no-]exclude-standard] [--cached | --untracked | --no-index] | <tree>...]
+ [--] [<pathspec>...]
+
+DESCRIPTION
+-----------
+Look for specified patterns in the tracked files in the work tree, blobs
+registered in the index file, or blobs in given tree objects. Patterns
+are lists of one or more search expressions separated by newline
+characters. An empty string as search expression matches all lines.
+
+
+OPTIONS
+-------
+--cached::
+ Instead of searching tracked files in the working tree, search
+ blobs registered in the index file.
+
+--untracked::
+ In addition to searching in the tracked files in the working
+ tree, search also in untracked files.
+
+--no-index::
+ Search files in the current directory that is not managed by Git,
+ or by ignoring that the current directory is managed by Git. This
+ is rather similar to running the regular `grep(1)` utility with its
+ `-r` option specified, but with some additional benefits, such as
+ using pathspec patterns to limit paths; see the 'pathspec' entry
+ in linkgit:gitglossary[7] for more information.
++
+This option cannot be used together with `--cached` or `--untracked`.
+See also `grep.fallbackToNoIndex` in 'CONFIGURATION' below.
+
+--no-exclude-standard::
+ Also search in ignored files by not honoring the `.gitignore`
+ mechanism. Only useful with `--untracked`.
+
+--exclude-standard::
+ Do not pay attention to ignored files specified via the `.gitignore`
+ mechanism. Only useful when searching files in the current directory
+ with `--no-index`.
+
+--recurse-submodules::
+ Recursively search in each submodule that is active and
+ checked out in the repository. When used in combination with the
+ _<tree>_ option the prefix of all submodule output will be the name of
+ the parent project's _<tree>_ object. This option cannot be used together
+ with `--untracked`, and it has no effect if `--no-index` is specified.
+
+-a::
+--text::
+ Process binary files as if they were text.
+
+--textconv::
+ Honor textconv filter settings.
+
+--no-textconv::
+ Do not honor textconv filter settings.
+ This is the default.
+
+-i::
+--ignore-case::
+ Ignore case differences between the patterns and the
+ files.
+
+-I::
+ Don't match the pattern in binary files.
+
+--max-depth <depth>::
+ For each <pathspec> given on command line, descend at most <depth>
+ levels of directories. A value of -1 means no limit.
+ This option is ignored if <pathspec> contains active wildcards.
+ In other words if "a*" matches a directory named "a*",
+ "*" is matched literally so --max-depth is still effective.
+
+-r::
+--recursive::
+ Same as `--max-depth=-1`; this is the default.
+
+--no-recursive::
+ Same as `--max-depth=0`.
+
+-w::
+--word-regexp::
+ Match the pattern only at word boundary (either begin at the
+ beginning of a line, or preceded by a non-word character; end at
+ the end of a line or followed by a non-word character).
+
+-v::
+--invert-match::
+ Select non-matching lines.
+
+-h::
+-H::
+ By default, the command shows the filename for each
+ match. `-h` option is used to suppress this output.
+ `-H` is there for completeness and does not do anything
+ except it overrides `-h` given earlier on the command
+ line.
+
+--full-name::
+ When run from a subdirectory, the command usually
+ outputs paths relative to the current directory. This
+ option forces paths to be output relative to the project
+ top directory.
+
+-E::
+--extended-regexp::
+-G::
+--basic-regexp::
+ Use POSIX extended/basic regexp for patterns. Default
+ is to use basic regexp.
+
+-P::
+--perl-regexp::
+ Use Perl-compatible regular expressions for patterns.
++
+Support for these types of regular expressions is an optional
+compile-time dependency. If Git wasn't compiled with support for them
+providing this option will cause it to die.
+
+-F::
+--fixed-strings::
+ Use fixed strings for patterns (don't interpret pattern
+ as a regex).
+
+-n::
+--line-number::
+ Prefix the line number to matching lines.
+
+--column::
+ Prefix the 1-indexed byte-offset of the first match from the start of the
+ matching line.
+
+-l::
+--files-with-matches::
+--name-only::
+-L::
+--files-without-match::
+ Instead of showing every matched line, show only the
+ names of files that contain (or do not contain) matches.
+ For better compatibility with 'git diff', `--name-only` is a
+ synonym for `--files-with-matches`.
+
+-O[<pager>]::
+--open-files-in-pager[=<pager>]::
+ Open the matching files in the pager (not the output of 'grep').
+ If the pager happens to be "less" or "vi", and the user
+ specified only one pattern, the first file is positioned at
+ the first match automatically. The `pager` argument is
+ optional; if specified, it must be stuck to the option
+ without a space. If `pager` is unspecified, the default pager
+ will be used (see `core.pager` in linkgit:git-config[1]).
+
+-z::
+--null::
+ Use \0 as the delimiter for pathnames in the output, and print
+ them verbatim. Without this option, pathnames with "unusual"
+ characters are quoted as explained for the configuration
+ variable `core.quotePath` (see linkgit:git-config[1]).
+
+-o::
+--only-matching::
+ Print only the matched (non-empty) parts of a matching line, with each such
+ part on a separate output line.
+
+-c::
+--count::
+ Instead of showing every matched line, show the number of
+ lines that match.
+
+--color[=<when>]::
+ Show colored matches.
+ The value must be always (the default), never, or auto.
+
+--no-color::
+ Turn off match highlighting, even when the configuration file
+ gives the default to color output.
+ Same as `--color=never`.
+
+--break::
+ Print an empty line between matches from different files.
+
+--heading::
+ Show the filename above the matches in that file instead of
+ at the start of each shown line.
+
+-p::
+--show-function::
+ Show the preceding line that contains the function name of
+ the match, unless the matching line is a function name itself.
+ The name is determined in the same way as `git diff` works out
+ patch hunk headers (see 'Defining a custom hunk-header' in
+ linkgit:gitattributes[5]).
+
+-<num>::
+-C <num>::
+--context <num>::
+ Show <num> leading and trailing lines, and place a line
+ containing `--` between contiguous groups of matches.
+
+-A <num>::
+--after-context <num>::
+ Show <num> trailing lines, and place a line containing
+ `--` between contiguous groups of matches.
+
+-B <num>::
+--before-context <num>::
+ Show <num> leading lines, and place a line containing
+ `--` between contiguous groups of matches.
+
+-W::
+--function-context::
+ Show the surrounding text from the previous line containing a
+ function name up to the one before the next function name,
+ effectively showing the whole function in which the match was
+ found. The function names are determined in the same way as
+ `git diff` works out patch hunk headers (see 'Defining a
+ custom hunk-header' in linkgit:gitattributes[5]).
+
+-m <num>::
+--max-count <num>::
+ Limit the amount of matches per file. When using the `-v` or
+ `--invert-match` option, the search stops after the specified
+ number of non-matches. A value of -1 will return unlimited
+ results (the default). A value of 0 will exit immediately with
+ a non-zero status.
+
+--threads <num>::
+ Number of `grep` worker threads to use. See 'NOTES ON THREADS'
+ and `grep.threads` in 'CONFIGURATION' for more information.
+
+-f <file>::
+ Read patterns from <file>, one per line.
++
+Passing the pattern via <file> allows for providing a search pattern
+containing a \0.
++
+Not all pattern types support patterns containing \0. Git will error
+out if a given pattern type can't support such a pattern. The
+`--perl-regexp` pattern type when compiled against the PCRE v2 backend
+has the widest support for these types of patterns.
++
+In versions of Git before 2.23.0 patterns containing \0 would be
+silently considered fixed. This was never documented, there were also
+odd and undocumented interactions between e.g. non-ASCII patterns
+containing \0 and `--ignore-case`.
++
+In future versions we may learn to support patterns containing \0 for
+more search backends, until then we'll die when the pattern type in
+question doesn't support them.
+
+-e::
+ The next parameter is the pattern. This option has to be
+ used for patterns starting with `-` and should be used in
+ scripts passing user input to grep. Multiple patterns are
+ combined by 'or'.
+
+--and::
+--or::
+--not::
+( ... )::
+ Specify how multiple patterns are combined using Boolean
+ expressions. `--or` is the default operator. `--and` has
+ higher precedence than `--or`. `-e` has to be used for all
+ patterns.
+
+--all-match::
+ When giving multiple pattern expressions combined with `--or`,
+ this flag is specified to limit the match to files that
+ have lines to match all of them.
+
+-q::
+--quiet::
+ Do not output matched lines; instead, exit with status 0 when
+ there is a match and with non-zero status when there isn't.
+
+<tree>...::
+ Instead of searching tracked files in the working tree, search
+ blobs in the given trees.
+
+\--::
+ Signals the end of options; the rest of the parameters
+ are <pathspec> limiters.
+
+<pathspec>...::
+ If given, limit the search to paths matching at least one pattern.
+ Both leading paths match and glob(7) patterns are supported.
++
+For more details about the <pathspec> syntax, see the 'pathspec' entry
+in linkgit:gitglossary[7].
+
+EXAMPLES
+--------
+
+`git grep 'time_t' -- '*.[ch]'`::
+ Looks for `time_t` in all tracked .c and .h files in the working
+ directory and its subdirectories.
+
+`git grep -e '#define' --and \( -e MAX_PATH -e PATH_MAX \)`::
+ Looks for a line that has `#define` and either `MAX_PATH` or
+ `PATH_MAX`.
+
+`git grep --all-match -e NODE -e Unexpected`::
+ Looks for a line that has `NODE` or `Unexpected` in
+ files that have lines that match both.
+
+`git grep solution -- :^Documentation`::
+ Looks for `solution`, excluding files in `Documentation`.
+
+NOTES ON THREADS
+----------------
+
+The `--threads` option (and the `grep.threads` configuration) will be ignored when
+`--open-files-in-pager` is used, forcing a single-threaded execution.
+
+When grepping the object store (with `--cached` or giving tree objects), running
+with multiple threads might perform slower than single-threaded if `--textconv`
+is given and there are too many text conversions. Thus, if low performance is
+experienced in this case, it might be desirable to use `--threads=1`.
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/grep.adoc[]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-gui.adoc b/git-gui.adoc
new file mode 100644
index 0000000..f5b02ef
--- /dev/null
+++ b/git-gui.adoc
@@ -0,0 +1,121 @@
+git-gui(1)
+==========
+
+NAME
+----
+git-gui - A portable graphical interface to Git
+
+SYNOPSIS
+--------
+[verse]
+'git gui' [<command>] [<arguments>]
+
+DESCRIPTION
+-----------
+A Tcl/Tk based graphical user interface to Git. 'git gui' focuses
+on allowing users to make changes to their repository by making
+new commits, amending existing ones, creating branches, performing
+local merges, and fetching/pushing to remote repositories.
+
+Unlike 'gitk', 'git gui' focuses on commit generation
+and single file annotation and does not show project history.
+It does however supply menu actions to start a 'gitk' session from
+within 'git gui'.
+
+'git gui' is known to work on all popular UNIX systems, Mac OS X,
+and Windows (under both Cygwin and MSYS). To the extent possible
+OS specific user interface guidelines are followed, making 'git gui'
+a fairly native interface for users.
+
+COMMANDS
+--------
+blame::
+ Start a blame viewer on the specified file on the given
+ version (or working directory if not specified).
+
+browser::
+ Start a tree browser showing all files in the specified
+ commit. Files selected through the
+ browser are opened in the blame viewer.
+
+citool::
+ Start 'git gui' and arrange to make exactly one commit before
+ exiting and returning to the shell. The interface is limited
+ to only commit actions, slightly reducing the application's
+ startup time and simplifying the menubar.
+
+version::
+ Display the currently running version of 'git gui'.
+
+
+Examples
+--------
+`git gui blame Makefile`::
+
+ Show the contents of the file 'Makefile' in the current
+ working directory, and provide annotations for both the
+ original author of each line, and who moved the line to its
+ current location. The uncommitted file is annotated, and
+ uncommitted changes (if any) are explicitly attributed to
+ 'Not Yet Committed'.
+
+`git gui blame v0.99.8 Makefile`::
+
+ Show the contents of 'Makefile' in revision 'v0.99.8'
+ and provide annotations for each line. Unlike the above
+ example the file is read from the object database and not
+ the working directory.
+
+`git gui blame --line=100 Makefile`::
+
+ Loads annotations as described above and automatically
+ scrolls the view to center on line '100'.
+
+`git gui citool`::
+
+ Make one commit and return to the shell when it is complete.
+ This command returns a non-zero exit code if the window was
+ closed in any way other than by making a commit.
+
+`git gui citool --amend`::
+
+ Automatically enter the 'Amend Last Commit' mode of
+ the interface.
+
+`git gui citool --nocommit`::
+
+ Behave as normal citool, but instead of making a commit
+ simply terminate with a zero exit code. It still checks
+ that the index does not contain any unmerged entries, so
+ you can use it as a GUI version of linkgit:git-mergetool[1]
+
+`git citool`::
+
+ Same as `git gui citool` (above).
+
+`git gui browser maint`::
+
+ Show a browser for the tree of the 'maint' branch. Files
+ selected in the browser can be viewed with the internal
+ blame viewer.
+
+SEE ALSO
+--------
+linkgit:gitk[1]::
+ The Git repository browser. Shows branches, commit history
+ and file differences. gitk is the utility started by
+ 'git gui''s Repository Visualize actions.
+
+Other
+-----
+'git gui' is actually maintained as an independent project, but stable
+versions are distributed as part of the Git suite for the convenience
+of end users.
+
+The official repository of the 'git gui' project can be found at:
+
+ https://github.com/j6t/git-gui
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-hash-object.adoc b/git-hash-object.adoc
new file mode 100644
index 0000000..ef4719a
--- /dev/null
+++ b/git-hash-object.adoc
@@ -0,0 +1,65 @@
+git-hash-object(1)
+==================
+
+NAME
+----
+git-hash-object - Compute object ID and optionally create an object from a file
+
+
+SYNOPSIS
+--------
+[verse]
+'git hash-object' [-t <type>] [-w] [--path=<file> | --no-filters]
+ [--stdin [--literally]] [--] <file>...
+'git hash-object' [-t <type>] [-w] --stdin-paths [--no-filters]
+
+DESCRIPTION
+-----------
+Computes the object ID value for an object with specified type
+with the contents of the named file (which can be outside of the
+work tree), and optionally writes the resulting object into the
+object database. Reports its object ID to its standard output.
+When <type> is not specified, it defaults to "blob".
+
+OPTIONS
+-------
+
+-t <type>::
+ Specify the type of object to be created (default: "blob"). Possible
+ values are `commit`, `tree`, `blob`, and `tag`.
+
+-w::
+ Actually write the object into the object database.
+
+--stdin::
+ Read the object from standard input instead of from a file.
+
+--stdin-paths::
+ Read file names from the standard input, one per line, instead
+ of from the command-line.
+
+--path::
+ Hash object as if it were located at the given path. The location of
+ the file does not directly influence the hash value, but the path is
+ used to determine which Git filters should be applied to the object
+ before it can be placed in the object database. As a result of
+ applying filters, the actual blob put into the object database may
+ differ from the given file. This option is mainly useful for hashing
+ temporary files located outside of the working directory or files
+ read from stdin.
+
+--no-filters::
+ Hash the contents as is, ignoring any input filter that would
+ have been chosen by the attributes mechanism, including the end-of-line
+ conversion. If the file is read from standard input then this
+ is always implied, unless the `--path` option is given.
+
+--literally::
+ Allow `--stdin` to hash any garbage into a loose object which might not
+ otherwise pass standard object parsing or git-fsck checks. Useful for
+ stress-testing Git itself or reproducing characteristics of corrupt or
+ bogus objects encountered in the wild.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-help.adoc b/git-help.adoc
new file mode 100644
index 0000000..f0bedc1
--- /dev/null
+++ b/git-help.adoc
@@ -0,0 +1,231 @@
+git-help(1)
+===========
+
+NAME
+----
+git-help - Display help information about Git
+
+SYNOPSIS
+--------
+[verse]
+'git help' [-a|--all] [--[no-]verbose] [--[no-]external-commands] [--[no-]aliases]
+'git help' [[-i|--info] [-m|--man] [-w|--web]] [<command>|<doc>]
+'git help' [-g|--guides]
+'git help' [-c|--config]
+'git help' [--user-interfaces]
+'git help' [--developer-interfaces]
+
+DESCRIPTION
+-----------
+
+With no options and no '<command>' or '<doc>' given, the synopsis of the 'git'
+command and a list of the most commonly used Git commands are printed
+on the standard output.
+
+If the option `--all` or `-a` is given, all available commands are
+printed on the standard output.
+
+If the option `--guides` or `-g` is given, a list of the
+Git concept guides is also printed on the standard output.
+
+If a command or other documentation is given, the relevant manual page
+will be brought up. The 'man' program is used by default for this
+purpose, but this can be overridden by other options or configuration
+variables.
+
+If an alias is given, git shows the definition of the alias on
+standard output. To get the manual page for the aliased command, use
+`git <command> --help`.
+
+Note that `git --help ...` is identical to `git help ...` because the
+former is internally converted into the latter.
+
+To display the linkgit:git[1] man page, use `git help git`.
+
+This page can be displayed with 'git help help' or `git help --help`.
+
+OPTIONS
+-------
+-a::
+--all::
+ Print all the available commands on the standard output.
+
+--no-external-commands::
+ When used with `--all`, exclude the listing of external "git-*"
+ commands found in the `$PATH`.
+
+--no-aliases::
+ When used with `--all`, exclude the listing of configured
+ aliases.
+
+--verbose::
+ When used with `--all`, print description for all recognized
+ commands. This is the default.
+
+-c::
+--config::
+ List all available configuration variables. This is a short
+ summary of the list in linkgit:git-config[1].
+
+-g::
+--guides::
+ Print a list of the Git concept guides on the standard output.
+
+--user-interfaces::
+ Print a list of the repository, command and file interfaces
+ documentation on the standard output.
++
+In-repository file interfaces such as `.git/info/exclude` are
+documented here (see linkgit:gitrepository-layout[5]), as well as
+in-tree configuration such as `.mailmap` (see linkgit:gitmailmap[5]).
++
+This section of the documentation also covers general or widespread
+user-interface conventions (e.g. linkgit:gitcli[7]), and
+pseudo-configuration such as the file-based `.git/hooks/*` interface
+described in linkgit:githooks[5].
+
+--developer-interfaces::
+ Print a list of file formats, protocols and other developer
+ interfaces documentation on the standard output.
+
+-i::
+--info::
+ Display manual page for the command in the 'info' format. The
+ 'info' program will be used for that purpose.
+
+-m::
+--man::
+ Display manual page for the command in the 'man' format. This
+ option may be used to override a value set in the
+ `help.format` configuration variable.
++
+By default the 'man' program will be used to display the manual page,
+but the `man.viewer` configuration variable may be used to choose
+other display programs (see below).
+
+-w::
+--web::
+ Display manual page for the command in the 'web' (HTML)
+ format. A web browser will be used for that purpose.
++
+The web browser can be specified using the configuration variable
+`help.browser`, or `web.browser` if the former is not set. If neither of
+these config variables is set, the 'git web{litdd}browse' helper script
+(called by 'git help') will pick a suitable default. See
+linkgit:git-web{litdd}browse[1] for more information about this.
+
+CONFIGURATION VARIABLES
+-----------------------
+
+help.format
+~~~~~~~~~~~
+
+If no command-line option is passed, the `help.format` configuration
+variable will be checked. The following values are supported for this
+variable; they make 'git help' behave as their corresponding command-
+line option:
+
+* "man" corresponds to '-m|--man',
+* "info" corresponds to '-i|--info',
+* "web" or "html" correspond to '-w|--web'.
+
+help.browser, web.browser, and browser.<tool>.path
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The `help.browser`, `web.browser` and `browser.<tool>.path` will also
+be checked if the 'web' format is chosen (either by command-line
+option or configuration variable). See '-w|--web' in the OPTIONS
+section above and linkgit:git-web{litdd}browse[1].
+
+man.viewer
+~~~~~~~~~~
+
+The `man.viewer` configuration variable will be checked if the 'man'
+format is chosen. The following values are currently supported:
+
+* "man": use the 'man' program as usual,
+* "woman": use 'emacsclient' to launch the "woman" mode in emacs
+ (this only works starting with emacsclient versions 22),
+* "konqueror": use 'kfmclient' to open the man page in a new konqueror
+ tab (see 'Note about konqueror' below).
+
+Values for other tools can be used if there is a corresponding
+`man.<tool>.cmd` configuration entry (see below).
+
+Multiple values may be given to the `man.viewer` configuration
+variable. Their corresponding programs will be tried in the order
+listed in the configuration file.
+
+For example, this configuration:
+
+------------------------------------------------
+ [man]
+ viewer = konqueror
+ viewer = woman
+------------------------------------------------
+
+will try to use konqueror first. But this may fail (for example, if
+DISPLAY is not set) and in that case emacs' woman mode will be tried.
+
+If everything fails, or if no viewer is configured, the viewer specified
+in the `GIT_MAN_VIEWER` environment variable will be tried. If that
+fails too, the 'man' program will be tried anyway.
+
+man.<tool>.path
+~~~~~~~~~~~~~~~
+
+You can explicitly provide a full path to your preferred man viewer by
+setting the configuration variable `man.<tool>.path`. For example, you
+can configure the absolute path to konqueror by setting
+'man.konqueror.path'. Otherwise, 'git help' assumes the tool is
+available in PATH.
+
+man.<tool>.cmd
+~~~~~~~~~~~~~~
+
+When the man viewer, specified by the `man.viewer` configuration
+variables, is not among the supported ones, then the corresponding
+`man.<tool>.cmd` configuration variable will be looked up. If this
+variable exists then the specified tool will be treated as a custom
+command and a shell eval will be used to run the command with the man
+page passed as arguments.
+
+Note about konqueror
+~~~~~~~~~~~~~~~~~~~~
+
+When 'konqueror' is specified in the `man.viewer` configuration
+variable, we launch 'kfmclient' to try to open the man page on an
+already opened konqueror in a new tab if possible.
+
+For consistency, we also try such a trick if 'man.konqueror.path' is
+set to something like `A_PATH_TO/konqueror`. That means we will try to
+launch `A_PATH_TO/kfmclient` instead.
+
+If you really want to use 'konqueror', then you can use something like
+the following:
+
+------------------------------------------------
+ [man]
+ viewer = konq
+
+ [man "konq"]
+ cmd = A_PATH_TO/konqueror
+------------------------------------------------
+
+Note about git config --global
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Note that all these configuration variables should probably be set
+using the `--global` flag, for example like this:
+
+------------------------------------------------
+$ git config --global help.format web
+$ git config --global web.browser firefox
+------------------------------------------------
+
+as they are probably more user specific than repository specific.
+See linkgit:git-config[1] for more information about this.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-hook.adoc b/git-hook.adoc
new file mode 100644
index 0000000..f6cc72d
--- /dev/null
+++ b/git-hook.adoc
@@ -0,0 +1,50 @@
+git-hook(1)
+===========
+
+NAME
+----
+git-hook - Run git hooks
+
+SYNOPSIS
+--------
+[verse]
+'git hook' run [--ignore-missing] [--to-stdin=<path>] <hook-name> [-- <hook-args>]
+
+DESCRIPTION
+-----------
+
+A command interface for running git hooks (see linkgit:githooks[5]),
+for use by other scripted git commands.
+
+SUBCOMMANDS
+-----------
+
+run::
+ Run the `<hook-name>` hook. See linkgit:githooks[5] for
+ supported hook names.
++
+
+Any positional arguments to the hook should be passed after a
+mandatory `--` (or `--end-of-options`, see linkgit:gitcli[7]). See
+linkgit:githooks[5] for arguments hooks might expect (if any).
+
+OPTIONS
+-------
+
+--to-stdin::
+ For "run"; specify a file which will be streamed into the
+ hook's stdin. The hook will receive the entire file from
+ beginning to EOF.
+
+--ignore-missing::
+ Ignore any missing hook by quietly returning zero. Used for
+ tools that want to do a blind one-shot run of a hook that may
+ or may not be present.
+
+SEE ALSO
+--------
+linkgit:githooks[5]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-http-backend.adoc b/git-http-backend.adoc
new file mode 100644
index 0000000..1dea426
--- /dev/null
+++ b/git-http-backend.adoc
@@ -0,0 +1,305 @@
+git-http-backend(1)
+===================
+
+NAME
+----
+git-http-backend - Server side implementation of Git over HTTP
+
+SYNOPSIS
+--------
+[verse]
+'git http-backend'
+
+DESCRIPTION
+-----------
+A simple CGI program to serve the contents of a Git repository to Git
+clients accessing the repository over http:// and https:// protocols.
+The program supports clients fetching using both the smart HTTP protocol
+and the backwards-compatible dumb HTTP protocol, as well as clients
+pushing using the smart HTTP protocol. It also supports Git's
+more-efficient "v2" protocol if properly configured; see the
+discussion of `GIT_PROTOCOL` in the ENVIRONMENT section below.
+
+It verifies that the directory has the magic file
+"git-daemon-export-ok", and it will refuse to export any Git directory
+that hasn't explicitly been marked for export this way (unless the
+`GIT_HTTP_EXPORT_ALL` environment variable is set).
+
+By default, only the `upload-pack` service is enabled, which serves
+'git fetch-pack' and 'git ls-remote' clients, which are invoked from
+'git fetch', 'git pull', and 'git clone'. If the client is authenticated,
+the `receive-pack` service is enabled, which serves 'git send-pack'
+clients, which is invoked from 'git push'.
+
+SERVICES
+--------
+These services can be enabled/disabled using the per-repository
+configuration file:
+
+http.getanyfile::
+ This serves Git clients older than version 1.6.6 that are unable to use the
+ upload pack service. When enabled, clients are able to read
+ any file within the repository, including objects that are
+ no longer reachable from a branch but are still present.
+ It is enabled by default, but a repository can disable it
+ by setting this configuration value to `false`.
+
+http.uploadpack::
+ This serves 'git fetch-pack' and 'git ls-remote' clients.
+ It is enabled by default, but a repository can disable it
+ by setting this configuration value to `false`.
+
+http.receivepack::
+ This serves 'git send-pack' clients, allowing push. It is
+ disabled by default for anonymous users, and enabled by
+ default for users authenticated by the web server. It can be
+ disabled by setting this item to `false`, or enabled for all
+ users, including anonymous users, by setting it to `true`.
+
+http.uploadarchive::
+ This serves 'git archive' clients for remote archive over HTTP/HTTPS
+ protocols. It is disabled by default. It only works in protocol v2.
+
+URL TRANSLATION
+---------------
+To determine the location of the repository on disk, 'git http-backend'
+concatenates the environment variables PATH_INFO, which is set
+automatically by the web server, and GIT_PROJECT_ROOT, which must be set
+manually in the web server configuration. If GIT_PROJECT_ROOT is not
+set, 'git http-backend' reads PATH_TRANSLATED, which is also set
+automatically by the web server.
+
+EXAMPLES
+--------
+All of the following examples map `http://$hostname/git/foo/bar.git`
+to `/var/www/git/foo/bar.git`.
+
+Apache 2.x::
+ Ensure mod_cgi, mod_alias, and mod_env are enabled, set
+ GIT_PROJECT_ROOT (or DocumentRoot) appropriately, and
+ create a ScriptAlias to the CGI:
++
+----------------------------------------------------------------
+SetEnv GIT_PROJECT_ROOT /var/www/git
+SetEnv GIT_HTTP_EXPORT_ALL
+ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
+
+# This is not strictly necessary using Apache and a modern version of
+# git-http-backend, as the webserver will pass along the header in the
+# environment as HTTP_GIT_PROTOCOL, and http-backend will copy that into
+# GIT_PROTOCOL. But you may need this line (or something similar if you
+# are using a different webserver), or if you want to support older Git
+# versions that did not do that copying.
+#
+# Having the webserver set up GIT_PROTOCOL is perfectly fine even with
+# modern versions (and will take precedence over HTTP_GIT_PROTOCOL,
+# which means it can be used to override the client's request).
+SetEnvIf Git-Protocol ".*" GIT_PROTOCOL=$0
+----------------------------------------------------------------
++
+To enable anonymous read access but authenticated write access,
+require authorization for both the initial ref advertisement (which we
+detect as a push via the service parameter in the query string), and the
+receive-pack invocation itself:
++
+----------------------------------------------------------------
+RewriteCond %{QUERY_STRING} service=git-receive-pack [OR]
+RewriteCond %{REQUEST_URI} /git-receive-pack$
+RewriteRule ^/git/ - [E=AUTHREQUIRED:yes]
+
+<LocationMatch "^/git/">
+ Order Deny,Allow
+ Deny from env=AUTHREQUIRED
+
+ AuthType Basic
+ AuthName "Git Access"
+ Require group committers
+ Satisfy Any
+ ...
+</LocationMatch>
+----------------------------------------------------------------
++
+If you do not have `mod_rewrite` available to match against the query
+string, it is sufficient to just protect `git-receive-pack` itself,
+like:
++
+----------------------------------------------------------------
+<LocationMatch "^/git/.*/git-receive-pack$">
+ AuthType Basic
+ AuthName "Git Access"
+ Require group committers
+ ...
+</LocationMatch>
+----------------------------------------------------------------
++
+In this mode, the server will not request authentication until the
+client actually starts the object negotiation phase of the push, rather
+than during the initial contact. For this reason, you must also enable
+the `http.receivepack` config option in any repositories that should
+accept a push. The default behavior, if `http.receivepack` is not set,
+is to reject any pushes by unauthenticated users; the initial request
+will therefore report `403 Forbidden` to the client, without even giving
+an opportunity for authentication.
++
+To require authentication for both reads and writes, use a Location
+directive around the repository, or one of its parent directories:
++
+----------------------------------------------------------------
+<Location /git/private>
+ AuthType Basic
+ AuthName "Private Git Access"
+ Require group committers
+ ...
+</Location>
+----------------------------------------------------------------
++
+To serve gitweb at the same url, use a ScriptAliasMatch to only
+those URLs that 'git http-backend' can handle, and forward the
+rest to gitweb:
++
+----------------------------------------------------------------
+ScriptAliasMatch \
+ "(?x)^/git/(.*/(HEAD | \
+ info/refs | \
+ objects/(info/[^/]+ | \
+ [0-9a-f]{2}/[0-9a-f]{38} | \
+ pack/pack-[0-9a-f]{40}\.(pack|idx)) | \
+ git-(upload|receive)-pack))$" \
+ /usr/libexec/git-core/git-http-backend/$1
+
+ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/
+----------------------------------------------------------------
++
+To serve multiple repositories from different linkgit:gitnamespaces[7] in a
+single repository:
++
+----------------------------------------------------------------
+SetEnvIf Request_URI "^/git/([^/]*)" GIT_NAMESPACE=$1
+ScriptAliasMatch ^/git/[^/]*(.*) /usr/libexec/git-core/git-http-backend/storage.git$1
+----------------------------------------------------------------
+
+Accelerated static Apache 2.x::
+ Similar to the above, but Apache can be used to return static
+ files that are stored on disk. On many systems this may
+ be more efficient as Apache can ask the kernel to copy the
+ file contents from the file system directly to the network:
++
+----------------------------------------------------------------
+SetEnv GIT_PROJECT_ROOT /var/www/git
+
+AliasMatch ^/git/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$ /var/www/git/$1
+AliasMatch ^/git/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /var/www/git/$1
+ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
+----------------------------------------------------------------
++
+This can be combined with the gitweb configuration:
++
+----------------------------------------------------------------
+SetEnv GIT_PROJECT_ROOT /var/www/git
+
+AliasMatch ^/git/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$ /var/www/git/$1
+AliasMatch ^/git/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /var/www/git/$1
+ScriptAliasMatch \
+ "(?x)^/git/(.*/(HEAD | \
+ info/refs | \
+ objects/info/[^/]+ | \
+ git-(upload|receive)-pack))$" \
+ /usr/libexec/git-core/git-http-backend/$1
+ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/
+----------------------------------------------------------------
+
+Lighttpd::
+ Ensure that `mod_cgi`, `mod_alias`, `mod_auth`, `mod_setenv` are
+ loaded, then set `GIT_PROJECT_ROOT` appropriately and redirect
+ all requests to the CGI:
++
+----------------------------------------------------------------
+alias.url += ( "/git" => "/usr/lib/git-core/git-http-backend" )
+$HTTP["url"] =~ "^/git" {
+ cgi.assign = ("" => "")
+ setenv.add-environment = (
+ "GIT_PROJECT_ROOT" => "/var/www/git",
+ "GIT_HTTP_EXPORT_ALL" => ""
+ )
+}
+----------------------------------------------------------------
++
+To enable anonymous read access but authenticated write access:
++
+----------------------------------------------------------------
+$HTTP["querystring"] =~ "service=git-receive-pack" {
+ include "git-auth.conf"
+}
+$HTTP["url"] =~ "^/git/.*/git-receive-pack$" {
+ include "git-auth.conf"
+}
+----------------------------------------------------------------
++
+where `git-auth.conf` looks something like:
++
+----------------------------------------------------------------
+auth.require = (
+ "/" => (
+ "method" => "basic",
+ "realm" => "Git Access",
+ "require" => "valid-user"
+ )
+)
+# ...and set up auth.backend here
+----------------------------------------------------------------
++
+To require authentication for both reads and writes:
++
+----------------------------------------------------------------
+$HTTP["url"] =~ "^/git/private" {
+ include "git-auth.conf"
+}
+----------------------------------------------------------------
+
+
+ENVIRONMENT
+-----------
+'git http-backend' relies upon the `CGI` environment variables set
+by the invoking web server, including:
+
+* PATH_INFO (if GIT_PROJECT_ROOT is set, otherwise PATH_TRANSLATED)
+* REMOTE_USER
+* REMOTE_ADDR
+* CONTENT_TYPE
+* QUERY_STRING
+* REQUEST_METHOD
+
+The `GIT_HTTP_EXPORT_ALL` environment variable may be passed to
+'git-http-backend' to bypass the check for the "git-daemon-export-ok"
+file in each repository before allowing export of that repository.
+
+The `GIT_HTTP_MAX_REQUEST_BUFFER` environment variable (or the
+`http.maxRequestBuffer` config option) may be set to change the
+largest ref negotiation request that git will handle during a fetch; any
+fetch requiring a larger buffer will not succeed. This value should not
+normally need to be changed, but may be helpful if you are fetching from
+a repository with an extremely large number of refs. The value can be
+specified with a unit (e.g., `100M` for 100 megabytes). The default is
+10 megabytes.
+
+Clients may probe for optional protocol capabilities (like the v2
+protocol) using the `Git-Protocol` HTTP header. In order to support
+these, the contents of that header must appear in the `GIT_PROTOCOL`
+environment variable. Most webservers will pass this header to the CGI
+via the `HTTP_GIT_PROTOCOL` variable, and `git-http-backend` will
+automatically copy that to `GIT_PROTOCOL`. However, some webservers may
+be more selective about which headers they'll pass, in which case they
+need to be configured explicitly (see the mention of `Git-Protocol` in
+the Apache config from the earlier EXAMPLES section).
+
+The backend process sets GIT_COMMITTER_NAME to '$REMOTE_USER' and
+GIT_COMMITTER_EMAIL to '$\{REMOTE_USER}@http.$\{REMOTE_ADDR\}',
+ensuring that any reflogs created by 'git-receive-pack' contain some
+identifying information of the remote user who performed the push.
+
+All `CGI` environment variables are available to each of the hooks
+invoked by the 'git-receive-pack'.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-http-backend.html b/git-http-backend.html
index ee7591f..a760761 100644
--- a/git-http-backend.html
+++ b/git-http-backend.html
@@ -514,6 +514,11 @@
disabled by setting this item to <code>false</code>, or enabled for all
users, including anonymous users, by setting it to <code>true</code>.</p>
</dd>
+<dt class="hdlist1">http.uploadarchive</dt>
+<dd>
+<p>This serves <em>git archive</em> clients for remote archive over HTTP/HTTPS
+protocols. It is disabled by default. It only works in protocol v2.</p>
+</dd>
</dl>
</div>
</div>
@@ -829,7 +834,7 @@
</div>
<div id="footer">
<div id="footer-text">
-Last updated 2023-10-23 14:43:46 -0700
+Last updated 2025-02-14 21:38:14 -0800
</div>
</div>
</body>
diff --git a/git-http-fetch.adoc b/git-http-fetch.adoc
new file mode 100644
index 0000000..4ec7c68
--- /dev/null
+++ b/git-http-fetch.adoc
@@ -0,0 +1,62 @@
+git-http-fetch(1)
+=================
+
+NAME
+----
+git-http-fetch - Download from a remote Git repository via HTTP
+
+
+SYNOPSIS
+--------
+[verse]
+'git http-fetch' [-c] [-t] [-a] [-d] [-v] [-w <filename>] [--recover] [--stdin | --packfile=<hash> | <commit>] <URL>
+
+DESCRIPTION
+-----------
+Downloads a remote Git repository via HTTP.
+
+This command always gets all objects. Historically, there were three options
+`-a`, `-c` and `-t` for choosing which objects to download. They are now
+silently ignored.
+
+OPTIONS
+-------
+commit-id::
+ Either the hash or the filename under [URL]/refs/ to
+ pull.
+
+-a, -c, -t::
+ These options are ignored for historical reasons.
+-v::
+ Report what is downloaded.
+
+-w <filename>::
+ Writes the commit-id into the specified filename under $GIT_DIR/refs/<filename> on
+ the local end after the transfer is complete.
+
+--stdin::
+ Instead of a commit id on the command line (which is not expected in this
+ case), 'git http-fetch' expects lines on stdin in the format
+
+ <commit-id>['\t'<filename-as-in--w>]
+
+--packfile=<hash>::
+ For internal use only. Instead of a commit id on the command
+ line (which is not expected in
+ this case), 'git http-fetch' fetches the packfile directly at the given
+ URL and uses index-pack to generate corresponding .idx and .keep files.
+ The hash is used to determine the name of the temporary file and is
+ arbitrary. The output of index-pack is printed to stdout. Requires
+ --index-pack-args.
+
+--index-pack-args=<args>::
+ For internal use only. The command to run on the contents of the
+ downloaded pack. Arguments are URL-encoded separated by spaces.
+
+--recover::
+ Verify that everything reachable from target is fetched. Used after
+ an earlier fetch is interrupted.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-http-push.adoc b/git-http-push.adoc
new file mode 100644
index 0000000..ce0d808
--- /dev/null
+++ b/git-http-push.adoc
@@ -0,0 +1,96 @@
+git-http-push(1)
+================
+
+NAME
+----
+git-http-push - Push objects over HTTP/DAV to another repository
+
+
+SYNOPSIS
+--------
+[verse]
+'git http-push' [--all] [--dry-run] [--force] [--verbose] <URL> <ref> [<ref>...]
+
+DESCRIPTION
+-----------
+Sends missing objects to the remote repository, and updates the
+remote branch.
+
+*NOTE*: This command is temporarily disabled if your libcurl
+is older than 7.16, as the combination has been reported
+not to work and sometimes corrupts the repository.
+
+OPTIONS
+-------
+--all::
+ Do not assume that the remote repository is complete in its
+ current state, and verify all objects in the entire local
+ ref's history exist in the remote repository.
+
+--force::
+ Usually, the command refuses to update a remote ref that
+ is not an ancestor of the local ref used to overwrite it.
+ This flag disables the check. What this means is that
+ the remote repository can lose commits; use it with
+ care.
+
+--dry-run::
+ Do everything except actually send the updates.
+
+--verbose::
+ Report the list of objects being walked locally and the
+ list of objects successfully sent to the remote repository.
+
+-d::
+-D::
+ Remove <ref> from remote repository. The specified branch
+ cannot be the remote HEAD. If -d is specified, the following
+ other conditions must also be met:
+
+ - Remote HEAD must resolve to an object that exists locally
+ - Specified branch resolves to an object that exists locally
+ - Specified branch is an ancestor of the remote HEAD
+
+<ref>...::
+ The remote refs to update.
+
+
+SPECIFYING THE REFS
+-------------------
+
+A '<ref>' specification can be either a single pattern, or a pair
+of such patterns separated by a colon ":" (this means that a ref name
+cannot have a colon in it). A single pattern '<name>' is just a
+shorthand for '<name>:<name>'.
+
+Each pattern pair '<src>:<dst>' consists of the source side (before
+the colon) and the destination side (after the colon). The ref to be
+pushed is determined by finding a match that matches the source side,
+and where it is pushed is determined by using the destination side.
+
+ - It is an error if '<src>' does not match exactly one of the
+ local refs.
+
+ - If '<dst>' does not match any remote ref, either
+
+ * it has to start with "refs/"; <dst> is used as the
+ destination literally in this case.
+
+ * <src> == <dst> and the ref that matched the <src> must not
+ exist in the set of remote refs; the ref matched <src>
+ locally is used as the name of the destination.
+
+Without `--force`, the <src> ref is stored at the remote only if
+<dst> does not exist, or <dst> is a proper subset (i.e. an
+ancestor) of <src>. This check, known as "fast-forward check",
+is performed to avoid accidentally overwriting the
+remote ref and losing other peoples' commits from there.
+
+With `--force`, the fast-forward check is disabled for all refs.
+
+Optionally, a <ref> parameter can be prefixed with a plus '+' sign
+to disable the fast-forward check only on that ref.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-imap-send.adoc b/git-imap-send.adoc
new file mode 100644
index 0000000..26ccf4e
--- /dev/null
+++ b/git-imap-send.adoc
@@ -0,0 +1,146 @@
+git-imap-send(1)
+================
+
+NAME
+----
+git-imap-send - Send a collection of patches from stdin to an IMAP folder
+
+
+SYNOPSIS
+--------
+[verse]
+'git imap-send' [-v] [-q] [--[no-]curl]
+
+
+DESCRIPTION
+-----------
+This command uploads a mailbox generated with 'git format-patch'
+into an IMAP drafts folder. This allows patches to be sent as
+other email is when using mail clients that cannot read mailbox
+files directly. The command also works with any general mailbox
+in which emails have the fields "From", "Date", and "Subject" in
+that order.
+
+Typical usage is something like:
+
+git format-patch --signoff --stdout --attach origin | git imap-send
+
+
+OPTIONS
+-------
+
+-v::
+--verbose::
+ Be verbose.
+
+-q::
+--quiet::
+ Be quiet.
+
+--curl::
+ Use libcurl to communicate with the IMAP server, unless tunneling
+ into it. Ignored if Git was built without the USE_CURL_FOR_IMAP_SEND
+ option set.
+
+--no-curl::
+ Talk to the IMAP server using git's own IMAP routines instead of
+ using libcurl. Ignored if Git was built with the NO_OPENSSL option
+ set.
+
+
+CONFIGURATION
+-------------
+
+To use the tool, `imap.folder` and either `imap.tunnel` or `imap.host` must be set
+to appropriate values.
+
+include::includes/cmd-config-section-rest.adoc[]
+
+include::config/imap.adoc[]
+
+EXAMPLES
+--------
+Using tunnel mode:
+
+..........................
+[imap]
+ folder = "INBOX.Drafts"
+ tunnel = "ssh -q -C user@example.com /usr/bin/imapd ./Maildir 2> /dev/null"
+..........................
+
+Using direct mode:
+
+.........................
+[imap]
+ folder = "INBOX.Drafts"
+ host = imap://imap.example.com
+ user = bob
+ pass = p4ssw0rd
+.........................
+
+Using direct mode with SSL:
+
+.........................
+[imap]
+ folder = "INBOX.Drafts"
+ host = imaps://imap.example.com
+ user = bob
+ pass = p4ssw0rd
+ port = 123
+ ; sslVerify = false
+.........................
+
+
+[NOTE]
+You may want to use `sslVerify=false`
+while troubleshooting, if you suspect that the reason you are
+having trouble connecting is because the certificate you use at
+the private server `example.com` you are trying to set up (or
+have set up) may not be verified correctly.
+
+Using Gmail's IMAP interface:
+
+---------
+[imap]
+ folder = "[Gmail]/Drafts"
+ host = imaps://imap.gmail.com
+ user = user@gmail.com
+ port = 993
+---------
+
+[NOTE]
+You might need to instead use: `folder = "[Google Mail]/Drafts"` if you get an error
+that the "Folder doesn't exist".
+
+[NOTE]
+If your Gmail account is set to another language than English, the name of the "Drafts"
+folder will be localized.
+
+Once the commits are ready to be sent, run the following command:
+
+ $ git format-patch --cover-letter -M --stdout origin/master | git imap-send
+
+Just make sure to disable line wrapping in the email client (Gmail's web
+interface will wrap lines no matter what, so you need to use a real
+IMAP client).
+
+CAUTION
+-------
+It is still your responsibility to make sure that the email message
+sent by your email program meets the standards of your project.
+Many projects do not like patches to be attached. Some mail
+agents will transform patches (e.g. wrap lines, send them as
+format=flowed) in ways that make them fail. You will get angry
+flames ridiculing you if you don't check this.
+
+Thunderbird in particular is known to be problematic. Thunderbird
+users may wish to visit this web page for more information:
+ https://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird#Completely_plain_email
+
+SEE ALSO
+--------
+linkgit:git-format-patch[1], linkgit:git-send-email[1], mbox(5)
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-index-pack.adoc b/git-index-pack.adoc
new file mode 100644
index 0000000..270056c
--- /dev/null
+++ b/git-index-pack.adoc
@@ -0,0 +1,162 @@
+git-index-pack(1)
+=================
+
+NAME
+----
+git-index-pack - Build pack index file for an existing packed archive
+
+
+SYNOPSIS
+--------
+[verse]
+'git index-pack' [-v] [-o <index-file>] [--[no-]rev-index] <pack-file>
+'git index-pack' --stdin [--fix-thin] [--keep] [-v] [-o <index-file>]
+ [--[no-]rev-index] [<pack-file>]
+
+
+DESCRIPTION
+-----------
+Reads a packed archive (.pack) from the specified file,
+builds a pack index file (.idx) for it, and optionally writes a
+reverse-index (.rev) for the specified pack. The packed
+archive, together with the pack index, can then be placed in
+the objects/pack/ directory of a Git repository.
+
+
+OPTIONS
+-------
+-v::
+ Be verbose about what is going on, including progress status.
+
+-o <index-file>::
+ Write the generated pack index into the specified
+ file. Without this option the name of pack index
+ file is constructed from the name of packed archive
+ file by replacing .pack with .idx (and the program
+ fails if the name of packed archive does not end
+ with .pack).
+
+--[no-]rev-index::
+ When this flag is provided, generate a reverse index
+ (a `.rev` file) corresponding to the given pack. If
+ `--verify` is given, ensure that the existing
+ reverse index is correct. Takes precedence over
+ `pack.writeReverseIndex`.
+
+--stdin::
+ When this flag is provided, the pack is read from stdin
+ instead and a copy is then written to <pack-file>. If
+ <pack-file> is not specified, the pack is written to
+ objects/pack/ directory of the current Git repository with
+ a default name determined from the pack content. If
+ <pack-file> is not specified consider using --keep to
+ prevent a race condition between this process and
+ 'git repack'.
+
+--fix-thin::
+ Fix a "thin" pack produced by `git pack-objects --thin` (see
+ linkgit:git-pack-objects[1] for details) by adding the
+ excluded objects the deltified objects are based on to the
+ pack. This option only makes sense in conjunction with --stdin.
+
+--keep::
+ Before moving the index into its final destination
+ create an empty .keep file for the associated pack file.
+ This option is usually necessary with --stdin to prevent a
+ simultaneous 'git repack' process from deleting
+ the newly constructed pack and index before refs can be
+ updated to use objects contained in the pack.
+
+--keep=<msg>::
+ Like --keep, create a .keep file before moving the index into
+ its final destination. However, instead of creating an empty file
+ place '<msg>' followed by an LF into the .keep file. The '<msg>'
+ message can later be searched for within all .keep files to
+ locate any which have outlived their usefulness.
+
+--index-version=<version>[,<offset>]::
+ This is intended to be used by the test suite only. It allows
+ to force the version for the generated pack index, and to force
+ 64-bit index entries on objects located above the given offset.
+
+--strict[=<msg-id>=<severity>...]::
+ Die, if the pack contains broken objects or links. An optional
+ comma-separated list of `<msg-id>=<severity>` can be passed to change
+ the severity of some possible issues, e.g.,
+ `--strict="missingEmail=ignore,badTagName=error"`. See the entry for the
+ `fsck.<msg-id>` configuration options in linkgit:git-fsck[1] for more
+ information on the possible values of `<msg-id>` and `<severity>`.
+
+--progress-title::
+ For internal use only.
++
+Set the title of the progress bar. The title is "Receiving objects" by
+default and "Indexing objects" when `--stdin` is specified.
+
+--check-self-contained-and-connected::
+ Die if the pack contains broken links. For internal use only.
+
+--fsck-objects[=<msg-id>=<severity>...]::
+ Die if the pack contains broken objects, but unlike `--strict`, don't
+ choke on broken links. If the pack contains a tree pointing to a
+ .gitmodules blob that does not exist, prints the hash of that blob
+ (for the caller to check) after the hash that goes into the name of the
+ pack/idx file (see "Notes").
++
+An optional comma-separated list of `<msg-id>=<severity>` can be passed to
+change the severity of some possible issues, e.g.,
+`--fsck-objects="missingEmail=ignore,badTagName=ignore"`. See the entry for the
+`fsck.<msg-id>` configuration options in linkgit:git-fsck[1] for more
+information on the possible values of `<msg-id>` and `<severity>`.
+
+--threads=<n>::
+ Specifies the number of threads to spawn when resolving
+ deltas. This requires that index-pack be compiled with
+ pthreads otherwise this option is ignored with a warning.
+ This is meant to reduce packing time on multiprocessor
+ machines. The required amount of memory for the delta search
+ window is however multiplied by the number of threads.
+ Specifying 0 will cause Git to auto-detect the number of CPU's
+ and use maximum 3 threads.
+
+--max-input-size=<size>::
+ Die, if the pack is larger than <size>.
+
+--object-format=<hash-algorithm>::
+ Specify the given object format (hash algorithm) for the pack. The valid
+ values are 'sha1' and (if enabled) 'sha256'. The default is the algorithm for
+ the current repository (set by `extensions.objectFormat`), or 'sha1' if no
+ value is set or outside a repository.
++
+This option cannot be used with --stdin.
++
+include::object-format-disclaimer.adoc[]
+
+--promisor[=<message>]::
+ Before committing the pack-index, create a .promisor file for this
+ pack. Particularly helpful when writing a promisor pack with --fix-thin
+ since the name of the pack is not final until the pack has been fully
+ written. If a `<message>` is provided, then that content will be
+ written to the .promisor file for future reference. See
+ link:technical/partial-clone.html[partial clone] for more information.
++
+Also, if there are objects in the given pack that references non-promisor
+objects (in the repo), repacks those non-promisor objects into a promisor
+pack. This avoids a situation in which a repo has non-promisor objects that are
+accessible through promisor objects.
++
+Requires <pack-file> to not be specified.
+
+NOTES
+-----
+
+Once the index has been created, the hash that goes into the name of
+the pack/idx file is printed to stdout. If --stdin was
+also used then this is prefixed by either "pack\t", or "keep\t" if a
+new .keep file was successfully created. This is useful to remove a
+.keep file used as a lock to prevent the race with 'git repack'
+mentioned above.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-init-db.adoc b/git-init-db.adoc
new file mode 100644
index 0000000..18bf1a3
--- /dev/null
+++ b/git-init-db.adoc
@@ -0,0 +1,23 @@
+git-init-db(1)
+==============
+
+NAME
+----
+git-init-db - Creates an empty Git repository
+
+
+SYNOPSIS
+--------
+[verse]
+'git init-db' [-q | --quiet] [--bare] [--template=<template-directory>] [--separate-git-dir <git-dir>] [--shared[=<permissions>]]
+
+
+DESCRIPTION
+-----------
+
+This is a synonym for linkgit:git-init[1]. Please refer to the
+documentation of that command.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-init.adoc b/git-init.adoc
new file mode 100644
index 0000000..a0dffba
--- /dev/null
+++ b/git-init.adoc
@@ -0,0 +1,189 @@
+git-init(1)
+===========
+
+NAME
+----
+git-init - Create an empty Git repository or reinitialize an existing one
+
+
+SYNOPSIS
+--------
+[synopsis]
+git init [-q | --quiet] [--bare] [--template=<template-directory>]
+ [--separate-git-dir <git-dir>] [--object-format=<format>]
+ [--ref-format=<format>]
+ [-b <branch-name> | --initial-branch=<branch-name>]
+ [--shared[=<permissions>]] [<directory>]
+
+
+DESCRIPTION
+-----------
+
+This command creates an empty Git repository - basically a `.git`
+directory with subdirectories for `objects`, `refs/heads`,
+`refs/tags`, and template files. An initial branch without any
+commits will be created (see the `--initial-branch` option below
+for its name).
+
+If the `GIT_DIR` environment variable is set then it specifies a path
+to use instead of `./.git` for the base of the repository.
+
+If the object storage directory is specified via the
+`GIT_OBJECT_DIRECTORY` environment variable then the sha1 directories
+are created underneath; otherwise, the default `$GIT_DIR/objects`
+directory is used.
+
+Running `git init` in an existing repository is safe. It will not
+overwrite things that are already there. The primary reason for
+rerunning `git init` is to pick up newly added templates (or to move
+the repository to another place if `--separate-git-dir` is given).
+
+OPTIONS
+-------
+
+`-q`::
+`--quiet`::
+
+Only print error and warning messages; all other output will be suppressed.
+
+`--bare`::
+
+Create a bare repository. If `GIT_DIR` environment is not set, it is set to the
+current working directory.
+
+`--object-format=<format>`::
+Specify the given object _<format>_ (hash algorithm) for the repository. The valid
+values are `sha1` and (if enabled) `sha256`. `sha1` is the default.
++
+include::object-format-disclaimer.adoc[]
+
+`--ref-format=<format>`::
+Specify the given ref storage _<format>_ for the repository. The valid values are:
++
+include::ref-storage-format.adoc[]
+
+`--template=<template-directory>`::
+Specify the directory from which templates will be used. (See the "TEMPLATE
+DIRECTORY" section below.)
+
+`--separate-git-dir=<git-dir>`::
+Instead of initializing the repository as a directory to either `$GIT_DIR` or
+`./.git/`, create a text file there containing the path to the actual
+repository. This file acts as a filesystem-agnostic Git symbolic link to the
+repository.
++
+If this is a reinitialization, the repository will be moved to the specified path.
+
+`-b <branch-name>`::
+`--initial-branch=<branch-name>`::
+Use _<branch-name>_ for the initial branch in the newly created
+repository. If not specified, fall back to the default name (currently
+`master`, but this is subject to change in the future; the name can be
+customized via the `init.defaultBranch` configuration variable).
+
+`--shared[=(false|true|umask|group|all|world|everybody|<perm>)]`::
+
+Specify that the Git repository is to be shared amongst several users. This
+allows users belonging to the same group to push into that
+repository. When specified, the config variable `core.sharedRepository` is
+set so that files and directories under `$GIT_DIR` are created with the
+requested permissions. When not specified, Git will use permissions reported
+by `umask`(2).
++
+The option can have the following values, defaulting to `group` if no value
+is given:
++
+--
+`umask`::
+`false`::
+
+Use permissions reported by `umask`(2). The default, when `--shared` is not
+specified.
+
+`group`::
+`true`::
+
+Make the repository group-writable, (and `g+sx`, since the git group may not be
+the primary group of all users). This is used to loosen the permissions of an
+otherwise safe `umask`(2) value. Note that the umask still applies to the other
+permission bits (e.g. if umask is `0022`, using `group` will not remove read
+privileges from other (non-group) users). See `0xxx` for how to exactly specify
+the repository permissions.
+
+`all`::
+`world`::
+`everybody`::
+
+Same as `group`, but make the repository readable by all users.
+
+_<perm>_::
+
+_<perm>_ is a 3-digit octal number prefixed with `0` and each file
+will have mode _<perm>_. _<perm>_ will override users' `umask`(2)
+value (and not only loosen permissions as `group` and `all`
+do). `0640` will create a repository which is group-readable, but
+not group-writable or accessible to others. `0660` will create a repo
+that is readable and writable to the current user and group, but
+inaccessible to others (directories and executable files get their
+`x` bit from the `r` bit for corresponding classes of users).
+--
+
+By default, the configuration flag `receive.denyNonFastForwards` is enabled
+in shared repositories, so that you cannot force a non fast-forwarding push
+into it.
+
+If you provide a _<directory>_, the command is run inside it. If this directory
+does not exist, it will be created.
+
+TEMPLATE DIRECTORY
+------------------
+
+Files and directories in the template directory whose name do not start with a
+dot will be copied to the `$GIT_DIR` after it is created.
+
+The template directory will be one of the following (in order):
+
+ - the argument given with the `--template` option;
+
+ - the contents of the `$GIT_TEMPLATE_DIR` environment variable;
+
+ - the `init.templateDir` configuration variable; or
+
+ - the default template directory: `/usr/share/git-core/templates`.
+
+The default template directory includes some directory structure, suggested
+"exclude patterns" (see linkgit:gitignore[5]), and sample hook files.
+
+The sample hooks are all disabled by default. To enable one of the
+sample hooks rename it by removing its `.sample` suffix.
+
+See linkgit:githooks[5] for more general info on hook execution.
+
+EXAMPLES
+--------
+
+Start a new Git repository for an existing code base::
++
+----------------
+$ cd /path/to/my/codebase
+$ git init <1>
+$ git add . <2>
+$ git commit <3>
+----------------
++
+<1> Create a `/path/to/my/codebase/.git` directory.
+<2> Add all existing files to the index.
+<3> Record the pristine state as the first commit in the history.
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+:git-init:
+
+include::config/init.adoc[]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-instaweb.adoc b/git-instaweb.adoc
new file mode 100644
index 0000000..a54fe44
--- /dev/null
+++ b/git-instaweb.adoc
@@ -0,0 +1,94 @@
+git-instaweb(1)
+===============
+
+NAME
+----
+git-instaweb - Instantly browse your working repository in gitweb
+
+SYNOPSIS
+--------
+[verse]
+'git instaweb' [--local] [--httpd=<httpd>] [--port=<port>]
+ [--browser=<browser>]
+'git instaweb' [--start] [--stop] [--restart]
+
+DESCRIPTION
+-----------
+A simple script to set up `gitweb` and a web server for browsing the local
+repository.
+
+OPTIONS
+-------
+
+-l::
+--local::
+ Only bind the web server to the local IP (127.0.0.1).
+
+-d::
+--httpd::
+ The HTTP daemon command-line that will be executed.
+ Command-line options may be specified here, and the
+ configuration file will be added at the end of the command-line.
+ Currently apache2, lighttpd, mongoose, plackup, python and
+ webrick are supported.
+ (Default: lighttpd)
+
+-m::
+--module-path::
+ The module path (only needed if httpd is Apache).
+ (Default: /usr/lib/apache2/modules)
+
+-p::
+--port::
+ The port number to bind the httpd to. (Default: 1234)
+
+-b::
+--browser::
+ The web browser that should be used to view the gitweb
+ page. This will be passed to the 'git web{litdd}browse' helper
+ script along with the URL of the gitweb instance. See
+ linkgit:git-web{litdd}browse[1] for more information about this. If
+ the script fails, the URL will be printed to stdout.
+
+start::
+--start::
+ Start the httpd instance and exit. Regenerate configuration files
+ as necessary for spawning a new instance.
+
+stop::
+--stop::
+ Stop the httpd instance and exit. This does not generate
+ any of the configuration files for spawning a new instance,
+ nor does it close the browser.
+
+restart::
+--restart::
+ Restart the httpd instance and exit. Regenerate configuration files
+ as necessary for spawning a new instance.
+
+CONFIGURATION
+-------------
+
+You may specify configuration in your .git/config
+
+-----------------------------------------------------------------------
+[instaweb]
+ local = true
+ httpd = apache2 -f
+ port = 4321
+ browser = konqueror
+ modulePath = /usr/lib/apache2/modules
+
+-----------------------------------------------------------------------
+
+If the configuration variable `instaweb.browser` is not set,
+`web.browser` will be used instead if it is defined. See
+linkgit:git-web{litdd}browse[1] for more information about this.
+
+SEE ALSO
+--------
+linkgit:gitweb[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-interpret-trailers.adoc b/git-interpret-trailers.adoc
new file mode 100644
index 0000000..82c8780
--- /dev/null
+++ b/git-interpret-trailers.adoc
@@ -0,0 +1,390 @@
+git-interpret-trailers(1)
+=========================
+
+NAME
+----
+git-interpret-trailers - Add or parse structured information in commit messages
+
+SYNOPSIS
+--------
+[verse]
+'git interpret-trailers' [--in-place] [--trim-empty]
+ [(--trailer (<key>|<key-alias>)[(=|:)<value>])...]
+ [--parse] [<file>...]
+
+DESCRIPTION
+-----------
+Add or parse 'trailer' lines that look similar to RFC 822 e-mail
+headers, at the end of the otherwise free-form part of a commit
+message. For example, in the following commit message
+
+------------------------------------------------
+subject
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit.
+
+Signed-off-by: Alice <alice@example.com>
+Signed-off-by: Bob <bob@example.com>
+------------------------------------------------
+
+the last two lines starting with "Signed-off-by" are trailers.
+
+This command reads commit messages from either the
+<file> arguments or the standard input if no <file> is specified.
+If `--parse` is specified, the output consists of the parsed trailers
+coming from the input, without influencing them with any command line
+options or configuration variables.
+
+Otherwise, this command applies `trailer.*` configuration variables
+(which could potentially add new trailers, as well as reposition them),
+as well as any command line arguments that can override configuration
+variables (such as `--trailer=...` which could also add new trailers),
+to each input file. The result is emitted on the standard output.
+
+This command can also operate on the output of linkgit:git-format-patch[1],
+which is more elaborate than a plain commit message. Namely, such output
+includes a commit message (as above), a "---" divider line, and a patch part.
+For these inputs, the divider and patch parts are not modified by
+this command and are emitted as is on the output, unless
+`--no-divider` is specified.
+
+Some configuration variables control the way the `--trailer` arguments
+are applied to each input and the way any existing trailer in
+the input is changed. They also make it possible to
+automatically add some trailers.
+
+By default, a '<key>=<value>' or '<key>:<value>' argument given
+using `--trailer` will be appended after the existing trailers only if
+the last trailer has a different (<key>, <value>) pair (or if there
+is no existing trailer). The <key> and <value> parts will be trimmed
+to remove starting and trailing whitespace, and the resulting trimmed
+<key> and <value> will appear in the output like this:
+
+------------------------------------------------
+key: value
+------------------------------------------------
+
+This means that the trimmed <key> and <value> will be separated by
+`': '` (one colon followed by one space).
+
+For convenience, a <key-alias> can be configured to make using `--trailer`
+shorter to type on the command line. This can be configured using the
+'trailer.<key-alias>.key' configuration variable. The <keyAlias> must be a prefix
+of the full <key> string, although case sensitivity does not matter. For
+example, if you have
+
+------------------------------------------------
+trailer.sign.key "Signed-off-by: "
+------------------------------------------------
+
+in your configuration, you only need to specify `--trailer="sign: foo"`
+on the command line instead of `--trailer="Signed-off-by: foo"`.
+
+By default the new trailer will appear at the end of all the existing
+trailers. If there is no existing trailer, the new trailer will appear
+at the end of the input. A blank line will be added before the new
+trailer if there isn't one already.
+
+Existing trailers are extracted from the input by looking for
+a group of one or more lines that (i) is all trailers, or (ii) contains at
+least one Git-generated or user-configured trailer and consists of at
+least 25% trailers.
+The group must be preceded by one or more empty (or whitespace-only) lines.
+The group must either be at the end of the input or be the last
+non-whitespace lines before a line that starts with '---' (followed by a
+space or the end of the line).
+
+When reading trailers, there can be no whitespace before or inside the
+<key>, but any number of regular space and tab characters are allowed
+between the <key> and the separator. There can be whitespaces before,
+inside or after the <value>. The <value> may be split over multiple lines
+with each subsequent line starting with at least one whitespace, like
+the "folding" in RFC 822. Example:
+
+------------------------------------------------
+key: This is a very long value, with spaces and
+ newlines in it.
+------------------------------------------------
+
+Note that trailers do not follow (nor are they intended to follow) many of the
+rules for RFC 822 headers. For example they do not follow the encoding rule.
+
+OPTIONS
+-------
+--in-place::
+ Edit the files in place.
+
+--trim-empty::
+ If the <value> part of any trailer contains only whitespace,
+ the whole trailer will be removed from the output.
+ This applies to existing trailers as well as new trailers.
+
+--trailer <key>[(=|:)<value>]::
+ Specify a (<key>, <value>) pair that should be applied as a
+ trailer to the inputs. See the description of this
+ command.
+
+--where <placement>::
+--no-where::
+ Specify where all new trailers will be added. A setting
+ provided with '--where' overrides the `trailer.where` and any
+ applicable `trailer.<keyAlias>.where` configuration variables
+ and applies to all '--trailer' options until the next occurrence of
+ '--where' or '--no-where'. Upon encountering '--no-where', clear the
+ effect of any previous use of '--where', such that the relevant configuration
+ variables are no longer overridden. Possible placements are `after`,
+ `before`, `end` or `start`.
+
+--if-exists <action>::
+--no-if-exists::
+ Specify what action will be performed when there is already at
+ least one trailer with the same <key> in the input. A setting
+ provided with '--if-exists' overrides the `trailer.ifExists` and any
+ applicable `trailer.<keyAlias>.ifExists` configuration variables
+ and applies to all '--trailer' options until the next occurrence of
+ '--if-exists' or '--no-if-exists'. Upon encountering '--no-if-exists, clear the
+ effect of any previous use of '--if-exists, such that the relevant configuration
+ variables are no longer overridden. Possible actions are `addIfDifferent`,
+ `addIfDifferentNeighbor`, `add`, `replace` and `doNothing`.
+
+--if-missing <action>::
+--no-if-missing::
+ Specify what action will be performed when there is no other
+ trailer with the same <key> in the input. A setting
+ provided with '--if-missing' overrides the `trailer.ifMissing` and any
+ applicable `trailer.<keyAlias>.ifMissing` configuration variables
+ and applies to all '--trailer' options until the next occurrence of
+ '--if-missing' or '--no-if-missing'. Upon encountering '--no-if-missing,
+ clear the effect of any previous use of '--if-missing, such that the relevant
+ configuration variables are no longer overridden. Possible actions are `doNothing`
+ or `add`.
+
+--only-trailers::
+ Output only the trailers, not any other parts of the input.
+
+--only-input::
+ Output only trailers that exist in the input; do not add any
+ from the command-line or by applying `trailer.*` configuration
+ variables.
+
+--unfold::
+ If a trailer has a value that runs over multiple lines (aka "folded"),
+ reformat the value into a single line.
+
+--parse::
+ A convenience alias for `--only-trailers --only-input
+ --unfold`. This makes it easier to only see the trailers coming from the
+ input without influencing them with any command line options or
+ configuration variables, while also making the output machine-friendly with
+ --unfold.
+
+--no-divider::
+ Do not treat `---` as the end of the commit message. Use this
+ when you know your input contains just the commit message itself
+ (and not an email or the output of `git format-patch`).
+
+CONFIGURATION VARIABLES
+-----------------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/trailer.adoc[]
+
+EXAMPLES
+--------
+
+* Configure a 'sign' trailer with a 'Signed-off-by' key, and then
+ add two of these trailers to a commit message file:
++
+------------
+$ git config trailer.sign.key "Signed-off-by"
+$ cat msg.txt
+subject
+
+body text
+$ git interpret-trailers --trailer 'sign: Alice <alice@example.com>' --trailer 'sign: Bob <bob@example.com>' <msg.txt
+subject
+
+body text
+
+Signed-off-by: Alice <alice@example.com>
+Signed-off-by: Bob <bob@example.com>
+------------
+
+* Use the `--in-place` option to edit a commit message file in place:
++
+------------
+$ cat msg.txt
+subject
+
+body text
+
+Signed-off-by: Bob <bob@example.com>
+$ git interpret-trailers --trailer 'Acked-by: Alice <alice@example.com>' --in-place msg.txt
+$ cat msg.txt
+subject
+
+body text
+
+Signed-off-by: Bob <bob@example.com>
+Acked-by: Alice <alice@example.com>
+------------
+
+* Extract the last commit as a patch, and add a 'Cc' and a
+ 'Reviewed-by' trailer to it:
++
+------------
+$ git format-patch -1
+0001-foo.patch
+$ git interpret-trailers --trailer 'Cc: Alice <alice@example.com>' --trailer 'Reviewed-by: Bob <bob@example.com>' 0001-foo.patch >0001-bar.patch
+------------
+
+* Configure a 'sign' trailer with a command to automatically add a
+ 'Signed-off-by: ' with the author information only if there is no
+ 'Signed-off-by: ' already, and show how it works:
++
+------------
+$ cat msg1.txt
+subject
+
+body text
+$ git config trailer.sign.key "Signed-off-by: "
+$ git config trailer.sign.ifmissing add
+$ git config trailer.sign.ifexists doNothing
+$ git config trailer.sign.cmd 'echo "$(git config user.name) <$(git config user.email)>"'
+$ git interpret-trailers --trailer sign <msg1.txt
+subject
+
+body text
+
+Signed-off-by: Bob <bob@example.com>
+$ cat msg2.txt
+subject
+
+body text
+
+Signed-off-by: Alice <alice@example.com>
+$ git interpret-trailers --trailer sign <msg2.txt
+subject
+
+body text
+
+Signed-off-by: Alice <alice@example.com>
+------------
+
+* Configure a 'fix' trailer with a key that contains a '#' and no
+ space after this character, and show how it works:
++
+------------
+$ git config trailer.separators ":#"
+$ git config trailer.fix.key "Fix #"
+$ echo "subject" | git interpret-trailers --trailer fix=42
+subject
+
+Fix #42
+------------
+
+* Configure a 'help' trailer with a cmd use a script `glog-find-author`
+ which search specified author identity from git log in git repository
+ and show how it works:
++
+------------
+$ cat ~/bin/glog-find-author
+#!/bin/sh
+test -n "$1" && git log --author="$1" --pretty="%an <%ae>" -1 || true
+$ cat msg.txt
+subject
+
+body text
+$ git config trailer.help.key "Helped-by: "
+$ git config trailer.help.ifExists "addIfDifferentNeighbor"
+$ git config trailer.help.cmd "~/bin/glog-find-author"
+$ git interpret-trailers --trailer="help:Junio" --trailer="help:Couder" <msg.txt
+subject
+
+body text
+
+Helped-by: Junio C Hamano <gitster@pobox.com>
+Helped-by: Christian Couder <christian.couder@gmail.com>
+------------
+
+* Configure a 'ref' trailer with a cmd use a script `glog-grep`
+ to grep last relevant commit from git log in the git repository
+ and show how it works:
++
+------------
+$ cat ~/bin/glog-grep
+#!/bin/sh
+test -n "$1" && git log --grep "$1" --pretty=reference -1 || true
+$ cat msg.txt
+subject
+
+body text
+$ git config trailer.ref.key "Reference-to: "
+$ git config trailer.ref.ifExists "replace"
+$ git config trailer.ref.cmd "~/bin/glog-grep"
+$ git interpret-trailers --trailer="ref:Add copyright notices." <msg.txt
+subject
+
+body text
+
+Reference-to: 8bc9a0c769 (Add copyright notices., 2005-04-07)
+------------
+
+* Configure a 'see' trailer with a command to show the subject of a
+ commit that is related, and show how it works:
++
+------------
+$ cat msg.txt
+subject
+
+body text
+
+see: HEAD~2
+$ cat ~/bin/glog-ref
+#!/bin/sh
+git log -1 --oneline --format="%h (%s)" --abbrev-commit --abbrev=14
+$ git config trailer.see.key "See-also: "
+$ git config trailer.see.ifExists "replace"
+$ git config trailer.see.ifMissing "doNothing"
+$ git config trailer.see.cmd "glog-ref"
+$ git interpret-trailers --trailer=see <msg.txt
+subject
+
+body text
+
+See-also: fe3187489d69c4 (subject of related commit)
+------------
+
+* Configure a commit template with some trailers with empty values
+ (using sed to show and keep the trailing spaces at the end of the
+ trailers), then configure a commit-msg hook that uses
+ 'git interpret-trailers' to remove trailers with empty values and
+ to add a 'git-version' trailer:
++
+------------
+$ cat temp.txt
+***subject***
+
+***message***
+
+Fixes: Z
+Cc: Z
+Reviewed-by: Z
+Signed-off-by: Z
+$ sed -e 's/ Z$/ /' temp.txt > commit_template.txt
+$ git config commit.template commit_template.txt
+$ cat .git/hooks/commit-msg
+#!/bin/sh
+git interpret-trailers --trim-empty --trailer "git-version: \$(git describe)" "\$1" > "\$1.new"
+mv "\$1.new" "\$1"
+$ chmod +x .git/hooks/commit-msg
+------------
+
+SEE ALSO
+--------
+linkgit:git-commit[1], linkgit:git-format-patch[1], linkgit:git-config[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-log.adoc b/git-log.adoc
new file mode 100644
index 0000000..ae8a7e2
--- /dev/null
+++ b/git-log.adoc
@@ -0,0 +1,220 @@
+git-log(1)
+==========
+
+NAME
+----
+git-log - Show commit logs
+
+
+SYNOPSIS
+--------
+[verse]
+'git log' [<options>] [<revision-range>] [[--] <path>...]
+
+DESCRIPTION
+-----------
+Shows the commit logs.
+
+:git-log: 1
+include::rev-list-description.adoc[]
+
+The command takes options applicable to the linkgit:git-rev-list[1]
+command to control what is shown and how, and options applicable to
+the linkgit:git-diff[1] command to control how the changes
+each commit introduces are shown.
+
+
+OPTIONS
+-------
+
+--follow::
+ Continue listing the history of a file beyond renames
+ (works only for a single file).
+
+--no-decorate::
+--decorate[=short|full|auto|no]::
+ Print out the ref names of any commits that are shown. If 'short' is
+ specified, the ref name prefixes 'refs/heads/', 'refs/tags/' and
+ 'refs/remotes/' will not be printed. If 'full' is specified, the
+ full ref name (including prefix) will be printed. If 'auto' is
+ specified, then if the output is going to a terminal, the ref names
+ are shown as if 'short' were given, otherwise no ref names are
+ shown. The option `--decorate` is short-hand for `--decorate=short`.
+ Default to configuration value of `log.decorate` if configured,
+ otherwise, `auto`.
+
+--decorate-refs=<pattern>::
+--decorate-refs-exclude=<pattern>::
+ For each candidate reference, do not use it for decoration if it
+ matches any patterns given to `--decorate-refs-exclude` or if it
+ doesn't match any of the patterns given to `--decorate-refs`. The
+ `log.excludeDecoration` config option allows excluding refs from
+ the decorations, but an explicit `--decorate-refs` pattern will
+ override a match in `log.excludeDecoration`.
++
+If none of these options or config settings are given, then references are
+used as decoration if they match `HEAD`, `refs/heads/`, `refs/remotes/`,
+`refs/stash/`, or `refs/tags/`.
+
+--clear-decorations::
+ When specified, this option clears all previous `--decorate-refs`
+ or `--decorate-refs-exclude` options and relaxes the default
+ decoration filter to include all references. This option is
+ assumed if the config value `log.initialDecorationSet` is set to
+ `all`.
+
+--source::
+ Print out the ref name given on the command line by which each
+ commit was reached.
+
+--[no-]mailmap::
+--[no-]use-mailmap::
+ Use mailmap file to map author and committer names and email
+ addresses to canonical real names and email addresses. See
+ linkgit:git-shortlog[1].
+
+--full-diff::
+ Without this flag, `git log -p <path>...` shows commits that
+ touch the specified paths, and diffs about the same specified
+ paths. With this, the full diff is shown for commits that touch
+ the specified paths; this means that "<path>..." limits only
+ commits, and doesn't limit diff for those commits.
++
+Note that this affects all diff-based output types, e.g. those
+produced by `--stat`, etc.
+
+--log-size::
+ Include a line ``log size <number>'' in the output for each commit,
+ where <number> is the length of that commit's message in bytes.
+ Intended to speed up tools that read log messages from `git log`
+ output by allowing them to allocate space in advance.
+
+include::line-range-options.adoc[]
+
+<revision-range>::
+ Show only commits in the specified revision range. When no
+ <revision-range> is specified, it defaults to `HEAD` (i.e. the
+ whole history leading to the current commit). `origin..HEAD`
+ specifies all the commits reachable from the current commit
+ (i.e. `HEAD`), but not from `origin`. For a complete list of
+ ways to spell <revision-range>, see the 'Specifying Ranges'
+ section of linkgit:gitrevisions[7].
+
+[--] <path>...::
+ Show only commits that are enough to explain how the files
+ that match the specified paths came to be. See 'History
+ Simplification' below for details and other simplification
+ modes.
++
+Paths may need to be prefixed with `--` to separate them from
+options or the revision range, when confusion arises.
+
+include::rev-list-options.adoc[]
+
+include::pretty-formats.adoc[]
+
+DIFF FORMATTING
+---------------
+
+By default, `git log` does not generate any diff output. The options
+below can be used to show the changes made by each commit.
+
+Note that unless one of `--diff-merges` variants (including short
+`-m`, `-c`, `--cc`, and `--dd` options) is explicitly given, merge commits
+will not show a diff, even if a diff format like `--patch` is
+selected, nor will they match search options like `-S`. The exception
+is when `--first-parent` is in use, in which case `first-parent` is
+the default format for merge commits.
+
+:git-log: 1
+:diff-merges-default: `off`
+include::diff-options.adoc[]
+
+include::diff-generate-patch.adoc[]
+
+EXAMPLES
+--------
+`git log --no-merges`::
+
+ Show the whole commit history, but skip any merges
+
+`git log v2.6.12.. include/scsi drivers/scsi`::
+
+ Show all commits since version 'v2.6.12' that changed any file
+ in the `include/scsi` or `drivers/scsi` subdirectories
+
+`git log --since="2 weeks ago" -- gitk`::
+
+ Show the changes during the last two weeks to the file 'gitk'.
+ The `--` is necessary to avoid confusion with the *branch* named
+ 'gitk'
+
+`git log --name-status release..test`::
+
+ Show the commits that are in the "test" branch but not yet
+ in the "release" branch, along with the list of paths
+ each commit modifies.
+
+`git log --follow builtin/rev-list.c`::
+
+ Shows the commits that changed `builtin/rev-list.c`, including
+ those commits that occurred before the file was given its
+ present name.
+
+`git log --branches --not --remotes=origin`::
+
+ Shows all commits that are in any of local branches but not in
+ any of remote-tracking branches for 'origin' (what you have that
+ origin doesn't).
+
+`git log master --not --remotes=*/master`::
+
+ Shows all commits that are in local master but not in any remote
+ repository master branches.
+
+`git log -p -m --first-parent`::
+
+ Shows the history including change diffs, but only from the
+ ``main branch'' perspective, skipping commits that come from merged
+ branches, and showing full diffs of changes introduced by the merges.
+ This makes sense only when following a strict policy of merging all
+ topic branches when staying on a single integration branch.
+
+`git log -L '/int main/',/^}/:main.c`::
+
+ Shows how the function `main()` in the file `main.c` evolved
+ over time.
+
+`git log -3`::
+
+ Limits the number of commits to show to 3.
+
+DISCUSSION
+----------
+
+include::i18n.adoc[]
+
+CONFIGURATION
+-------------
+
+See linkgit:git-config[1] for core variables and linkgit:git-diff[1]
+for settings related to diff generation.
+
+format.pretty::
+ Default for the `--format` option. (See 'Pretty Formats' above.)
+ Defaults to `medium`.
+
+i18n.logOutputEncoding::
+ Encoding to use when displaying logs. (See 'Discussion' above.)
+ Defaults to the value of `i18n.commitEncoding` if set, and UTF-8
+ otherwise.
+
+include::includes/cmd-config-section-rest.adoc[]
+
+include::config/log.adoc[]
+
+include::config/notes.adoc[]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-ls-files.adoc b/git-ls-files.adoc
new file mode 100644
index 0000000..58c529a
--- /dev/null
+++ b/git-ls-files.adoc
@@ -0,0 +1,344 @@
+git-ls-files(1)
+===============
+
+NAME
+----
+git-ls-files - Show information about files in the index and the working tree
+
+
+SYNOPSIS
+--------
+[verse]
+'git ls-files' [-z] [-t] [-v] [-f]
+ [-c|--cached] [-d|--deleted] [-o|--others] [-i|--ignored]
+ [-s|--stage] [-u|--unmerged] [-k|--killed] [-m|--modified]
+ [--resolve-undo]
+ [--directory [--no-empty-directory]] [--eol]
+ [--deduplicate]
+ [-x <pattern>|--exclude=<pattern>]
+ [-X <file>|--exclude-from=<file>]
+ [--exclude-per-directory=<file>]
+ [--exclude-standard]
+ [--error-unmatch] [--with-tree=<tree-ish>]
+ [--full-name] [--recurse-submodules]
+ [--abbrev[=<n>]] [--format=<format>] [--] [<file>...]
+
+DESCRIPTION
+-----------
+This command merges the file listing in the index with the actual working
+directory list, and shows different combinations of the two.
+
+Several flags can be used to determine which files are
+shown, and each file may be printed multiple times if there are
+multiple entries in the index or if multiple statuses are applicable for
+the relevant file selection options.
+
+OPTIONS
+-------
+-c::
+--cached::
+ Show all files cached in Git's index, i.e. all tracked files.
+ (This is the default if no -c/-s/-d/-o/-u/-k/-m/--resolve-undo
+ options are specified.)
+
+-d::
+--deleted::
+ Show files with an unstaged deletion
+
+-m::
+--modified::
+ Show files with an unstaged modification (note that an unstaged
+ deletion also counts as an unstaged modification)
+
+-o::
+--others::
+ Show other (i.e. untracked) files in the output
+
+-i::
+--ignored::
+ Show only ignored files in the output. Must be used with
+ either an explicit '-c' or '-o'. When showing files in the
+ index (i.e. when used with '-c'), print only those files
+ matching an exclude pattern. When showing "other" files
+ (i.e. when used with '-o'), show only those matched by an
+ exclude pattern. Standard ignore rules are not automatically
+ activated; therefore, at least one of the `--exclude*` options
+ is required.
+
+-s::
+--stage::
+ Show staged contents' mode bits, object name and stage number in the output.
+
+--directory::
+ If a whole directory is classified as "other", show just its
+ name (with a trailing slash) and not its whole contents.
+ Has no effect without -o/--others.
+
+--no-empty-directory::
+ Do not list empty directories. Has no effect without --directory.
+
+-u::
+--unmerged::
+ Show information about unmerged files in the output, but do
+ not show any other tracked files (forces --stage, overrides
+ --cached).
+
+-k::
+--killed::
+ Show untracked files on the filesystem that need to be removed
+ due to file/directory conflicts for tracked files to be able to
+ be written to the filesystem.
+
+--resolve-undo::
+ Show files having resolve-undo information in the index
+ together with their resolve-undo information. (resolve-undo
+ information is what is used to implement "git checkout -m
+ $PATH", i.e. to recreate merge conflicts that were
+ accidentally resolved)
+
+-z::
+ \0 line termination on output and do not quote filenames.
+ See OUTPUT below for more information.
+
+--deduplicate::
+ When only filenames are shown, suppress duplicates that may
+ come from having multiple stages during a merge, or giving
+ `--deleted` and `--modified` option at the same time.
+ When any of the `-t`, `--unmerged`, or `--stage` option is
+ in use, this option has no effect.
+
+-x <pattern>::
+--exclude=<pattern>::
+ Skip untracked files matching pattern.
+ Note that pattern is a shell wildcard pattern. See EXCLUDE PATTERNS
+ below for more information.
+
+-X <file>::
+--exclude-from=<file>::
+ Read exclude patterns from <file>; 1 per line.
+
+--exclude-per-directory=<file>::
+ Read additional exclude patterns that apply only to the
+ directory and its subdirectories in <file>. If you are
+ trying to emulate the way Porcelain commands work, using
+ the `--exclude-standard` option instead is easier and more
+ thorough.
+
+--exclude-standard::
+ Add the standard Git exclusions: .git/info/exclude, .gitignore
+ in each directory, and the user's global exclusion file.
+
+--error-unmatch::
+ If any <file> does not appear in the index, treat this as an
+ error (return 1).
+
+--with-tree=<tree-ish>::
+ When using --error-unmatch to expand the user supplied
+ <file> (i.e. path pattern) arguments to paths, pretend
+ that paths which were removed in the index since the
+ named <tree-ish> are still present. Using this option
+ with `-s` or `-u` options does not make any sense.
+
+-t::
+ Show status tags together with filenames. Note that for
+ scripting purposes, linkgit:git-status[1] `--porcelain` and
+ linkgit:git-diff-files[1] `--name-status` are almost always
+ superior alternatives; users should look at
+ linkgit:git-status[1] `--short` or linkgit:git-diff[1]
+ `--name-status` for more user-friendly alternatives.
++
+--
+This option provides a reason for showing each filename, in the form
+of a status tag (which is followed by a space and then the filename).
+The status tags are all single characters from the following list:
+
+ H:: tracked file that is not either unmerged or skip-worktree
+ S:: tracked file that is skip-worktree
+ M:: tracked file that is unmerged
+ R:: tracked file with unstaged removal/deletion
+ C:: tracked file with unstaged modification/change
+ K:: untracked paths which are part of file/directory conflicts
+ which prevent checking out tracked files
+ ?:: untracked file
+ U:: file with resolve-undo information
+--
+
+-v::
+ Similar to `-t`, but use lowercase letters for files
+ that are marked as 'assume unchanged' (see
+ linkgit:git-update-index[1]).
+
+-f::
+ Similar to `-t`, but use lowercase letters for files
+ that are marked as 'fsmonitor valid' (see
+ linkgit:git-update-index[1]).
+
+--full-name::
+ When run from a subdirectory, the command usually
+ outputs paths relative to the current directory. This
+ option forces paths to be output relative to the project
+ top directory.
+
+--recurse-submodules::
+ Recursively calls ls-files on each active submodule in the repository.
+ Currently there is only support for the --cached and --stage modes.
+
+--abbrev[=<n>]::
+ Instead of showing the full 40-byte hexadecimal object
+ lines, show the shortest prefix that is at least '<n>'
+ hexdigits long that uniquely refers the object.
+ Non default number of digits can be specified with --abbrev=<n>.
+
+--debug::
+ After each line that describes a file, add more data about its
+ cache entry. This is intended to show as much information as
+ possible for manual inspection; the exact format may change at
+ any time.
+
+--eol::
+ Show <eolinfo> and <eolattr> of files.
+ <eolinfo> is the file content identification used by Git when
+ the "text" attribute is "auto" (or not set and core.autocrlf is not false).
+ <eolinfo> is either "-text", "none", "lf", "crlf", "mixed" or "".
++
+"" means the file is not a regular file, it is not in the index or
+not accessible in the working tree.
++
+<eolattr> is the attribute that is used when checking out or committing,
+it is either "", "-text", "text", "text=auto", "text eol=lf", "text eol=crlf".
+Since Git 2.10 "text=auto eol=lf" and "text=auto eol=crlf" are supported.
++
+Both the <eolinfo> in the index ("i/<eolinfo>")
+and in the working tree ("w/<eolinfo>") are shown for regular files,
+followed by the ("attr/<eolattr>").
+
+--sparse::
+ If the index is sparse, show the sparse directories without expanding
+ to the contained files. Sparse directories will be shown with a
+ trailing slash, such as "x/" for a sparse directory "x".
+
+--format=<format>::
+ A string that interpolates `%(fieldname)` from the result being shown.
+ It also interpolates `%%` to `%`, and `%xXX` where `XX` are hex digits
+ interpolates to character with hex code `XX`; for example `%x00`
+ interpolates to `\0` (NUL), `%x09` to `\t` (TAB) and %x0a to `\n` (LF).
+ --format cannot be combined with `-s`, `-o`, `-k`, `-t`, `--resolve-undo`
+ and `--eol`.
+\--::
+ Do not interpret any more arguments as options.
+
+<file>::
+ Files to show. If no files are given all files which match the other
+ specified criteria are shown.
+
+OUTPUT
+------
+'git ls-files' just outputs the filenames unless `--stage` is specified in
+which case it outputs:
+
+ [<tag> ]<mode> <object> <stage> <file>
+
+'git ls-files --eol' will show
+ i/<eolinfo><SPACES>w/<eolinfo><SPACES>attr/<eolattr><SPACE*><TAB><file>
+
+'git ls-files --unmerged' and 'git ls-files --stage' can be used to examine
+detailed information on unmerged paths.
+
+For an unmerged path, instead of recording a single mode/SHA-1 pair,
+the index records up to three such pairs; one from tree O in stage
+1, A in stage 2, and B in stage 3. This information can be used by
+the user (or the porcelain) to see what should eventually be recorded at the
+path. (see linkgit:git-read-tree[1] for more information on state)
+
+Without the `-z` option, pathnames with "unusual" characters are
+quoted as explained for the configuration variable `core.quotePath`
+(see linkgit:git-config[1]). Using `-z` the filename is output
+verbatim and the line is terminated by a NUL byte.
+
+It is possible to print in a custom format by using the `--format`
+option, which is able to interpolate different fields using
+a `%(fieldname)` notation. For example, if you only care about the
+"objectname" and "path" fields, you can execute with a specific
+"--format" like
+
+ git ls-files --format='%(objectname) %(path)'
+
+FIELD NAMES
+-----------
+The way each path is shown can be customized by using the
+`--format=<format>` option, where the %(fieldname) in the
+<format> string for various aspects of the index entry are
+interpolated. The following "fieldname" are understood:
+
+objectmode::
+ The mode of the file which is recorded in the index.
+objecttype::
+ The object type of the file which is recorded in the index.
+objectname::
+ The name of the file which is recorded in the index.
+objectsize[:padded]::
+ The object size of the file which is recorded in the index
+ ("-" if the object is a `commit` or `tree`).
+ It also supports a padded format of size with "%(objectsize:padded)".
+stage::
+ The stage of the file which is recorded in the index.
+eolinfo:index::
+eolinfo:worktree::
+ The <eolinfo> (see the description of the `--eol` option) of
+ the contents in the index or in the worktree for the path.
+eolattr::
+ The <eolattr> (see the description of the `--eol` option)
+ that applies to the path.
+path::
+ The pathname of the file which is recorded in the index.
+
+EXCLUDE PATTERNS
+----------------
+
+'git ls-files' can use a list of "exclude patterns" when
+traversing the directory tree and finding files to show when the
+flags --others or --ignored are specified. linkgit:gitignore[5]
+specifies the format of exclude patterns.
+
+These exclude patterns can be specified from the following places,
+in order:
+
+ 1. The command-line flag --exclude=<pattern> specifies a
+ single pattern. Patterns are ordered in the same order
+ they appear in the command line.
+
+ 2. The command-line flag --exclude-from=<file> specifies a
+ file containing a list of patterns. Patterns are ordered
+ in the same order they appear in the file.
+
+ 3. The command-line flag --exclude-per-directory=<name> specifies
+ a name of the file in each directory 'git ls-files'
+ examines, normally `.gitignore`. Files in deeper
+ directories take precedence. Patterns are ordered in the
+ same order they appear in the files.
+
+A pattern specified on the command line with --exclude or read
+from the file specified with --exclude-from is relative to the
+top of the directory tree. A pattern read from a file specified
+by --exclude-per-directory is relative to the directory that the
+pattern file appears in.
+
+Generally, you should be able to use `--exclude-standard` when you
+want the exclude rules applied the same way as what Porcelain
+commands do. To emulate what `--exclude-standard` specifies, you
+can give `--exclude-per-directory=.gitignore`, and then specify:
+
+ 1. The file specified by the `core.excludesfile` configuration
+ variable, if exists, or the `$XDG_CONFIG_HOME/git/ignore` file.
+
+ 2. The `$GIT_DIR/info/exclude` file.
+
+via the `--exclude-from=` option.
+
+SEE ALSO
+--------
+linkgit:git-read-tree[1], linkgit:gitignore[5]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-ls-remote.adoc b/git-ls-remote.adoc
new file mode 100644
index 0000000..d71c4ab
--- /dev/null
+++ b/git-ls-remote.adoc
@@ -0,0 +1,157 @@
+git-ls-remote(1)
+================
+
+NAME
+----
+git-ls-remote - List references in a remote repository
+
+
+SYNOPSIS
+--------
+[verse]
+'git ls-remote' [--branches] [--tags] [--refs] [--upload-pack=<exec>]
+ [-q | --quiet] [--exit-code] [--get-url] [--sort=<key>]
+ [--symref] [<repository> [<patterns>...]]
+
+DESCRIPTION
+-----------
+Displays references available in a remote repository along with the associated
+commit IDs.
+
+
+OPTIONS
+-------
+-b::
+--branches::
+-t::
+--tags::
+ Limit to only local branches and local tags, respectively.
+ These options are _not_ mutually exclusive; when given
+ both, references stored in refs/heads and refs/tags are
+ displayed. Note that `--heads` and `-h` are deprecated
+ synonyms for `--branches` and `-b` and may be removed in
+ the future. Also note that `git ls-remote -h` used without
+ anything else on the command line gives help, consistent
+ with other git subcommands.
+
+--refs::
+ Do not show peeled tags or pseudorefs like `HEAD` in the output.
+
+-q::
+--quiet::
+ Do not print remote URL to stderr.
+
+--upload-pack=<exec>::
+ Specify the full path of 'git-upload-pack' on the remote
+ host. This allows listing references from repositories accessed via
+ SSH and where the SSH daemon does not use the PATH configured by the
+ user.
+
+--exit-code::
+ Exit with status "2" when no matching refs are found in the remote
+ repository. Usually the command exits with status "0" to indicate
+ it successfully talked with the remote repository, whether it
+ found any matching refs.
+
+--get-url::
+ Expand the URL of the given remote repository taking into account any
+ "url.<base>.insteadOf" config setting (See linkgit:git-config[1]) and
+ exit without talking to the remote.
+
+--symref::
+ In addition to the object pointed by it, show the underlying
+ ref pointed by it when showing a symbolic ref. Currently,
+ upload-pack only shows the symref HEAD, so it will be the only
+ one shown by ls-remote.
+
+--sort=<key>::
+ Sort based on the key given. Prefix `-` to sort in descending order
+ of the value. Supports "version:refname" or "v:refname" (tag names
+ are treated as versions). The "version:refname" sort order can also
+ be affected by the "versionsort.suffix" configuration variable.
+ See linkgit:git-for-each-ref[1] for more sort options, but be aware
+ keys like `committerdate` that require access to the objects
+ themselves will not work for refs whose objects have not yet been
+ fetched from the remote, and will give a `missing object` error.
+
+-o <option>::
+--server-option=<option>::
+ Transmit the given string to the server when communicating using
+ protocol version 2. The given string must not contain a NUL or LF
+ character.
+ When multiple `--server-option=<option>` are given, they are all
+ sent to the other side in the order listed on the command line.
+ When no `--server-option=<option>` is given from the command line,
+ the values of configuration variable `remote.<name>.serverOption`
+ are used instead.
+
+<repository>::
+ The "remote" repository to query. This parameter can be
+ either a URL or the name of a remote (see the GIT URLS and
+ REMOTES sections of linkgit:git-fetch[1]).
+
+<patterns>...::
+ When unspecified, all references, after filtering done
+ with --heads and --tags, are shown. When <patterns>... are
+ specified, only references matching one or more of the given
+ patterns are displayed. Each pattern is interpreted as a glob
+ (see `glob` in linkgit:gitglossary[7]) which is matched against
+ the "tail" of a ref, starting either from the start of the ref
+ (so a full name like `refs/heads/foo` matches) or from a slash
+ separator (so `bar` matches `refs/heads/bar` but not
+ `refs/heads/foobar`).
+
+OUTPUT
+------
+
+The output is in the format:
+
+------------
+<oid> TAB <ref> LF
+------------
+
+When showing an annotated tag, unless `--refs` is given, two such
+lines are shown: one with the refname for the tag itself as `<ref>`,
+and another with `<ref>` followed by `^{}`. The `<oid>` on the latter
+line shows the name of the object the tag points at.
+
+EXAMPLES
+--------
+
+* List all references (including symbolics and pseudorefs), peeling
+ tags:
++
+----
+$ git ls-remote
+27d43aaaf50ef0ae014b88bba294f93658016a2e HEAD
+950264636c68591989456e3ba0a5442f93152c1a refs/heads/main
+d9ab777d41f92a8c1684c91cfb02053d7dd1046b refs/heads/next
+d4ca2e3147b409459955613c152220f4db848ee1 refs/tags/v2.40.0
+73876f4861cd3d187a4682290ab75c9dccadbc56 refs/tags/v2.40.0^{}
+----
+
+* List all references matching given patterns:
++
+----
+$ git ls-remote http://www.kernel.org/pub/scm/git/git.git master seen rc
+5fe978a5381f1fbad26a80e682ddd2a401966740 refs/heads/master
+c781a84b5204fb294c9ccc79f8b3baceeb32c061 refs/heads/seen
+----
+
+* List only tags matching a given wildcard pattern:
++
+----
+$ git ls-remote --tags http://www.kernel.org/pub/scm/git/git.git v\*
+485a869c64a68cc5795dd99689797c5900f4716d refs/tags/v2.39.2
+cbf04937d5b9fcf0a76c28f69e6294e9e3ecd7e6 refs/tags/v2.39.2^{}
+d4ca2e3147b409459955613c152220f4db848ee1 refs/tags/v2.40.0
+73876f4861cd3d187a4682290ab75c9dccadbc56 refs/tags/v2.40.0^{}
+----
+
+SEE ALSO
+--------
+linkgit:git-check-ref-format[1].
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-ls-tree.adoc b/git-ls-tree.adoc
new file mode 100644
index 0000000..6572095
--- /dev/null
+++ b/git-ls-tree.adoc
@@ -0,0 +1,165 @@
+git-ls-tree(1)
+==============
+
+NAME
+----
+git-ls-tree - List the contents of a tree object
+
+
+SYNOPSIS
+--------
+[verse]
+'git ls-tree' [-d] [-r] [-t] [-l] [-z]
+ [--name-only] [--name-status] [--object-only] [--full-name] [--full-tree] [--abbrev[=<n>]] [--format=<format>]
+ <tree-ish> [<path>...]
+
+DESCRIPTION
+-----------
+Lists the contents of a given tree object, like what "/bin/ls -a" does
+in the current working directory. Note that:
+
+ - the behaviour is slightly different from that of "/bin/ls" in that the
+ '<path>' denotes just a list of patterns to match, e.g. so specifying
+ directory name (without `-r`) will behave differently, and order of the
+ arguments does not matter.
+
+ - the behaviour is similar to that of "/bin/ls" in that the '<path>' is
+ taken as relative to the current working directory. E.g. when you are
+ in a directory 'sub' that has a directory 'dir', you can run 'git
+ ls-tree -r HEAD dir' to list the contents of the tree (that is
+ `sub/dir` in `HEAD`). You don't want to give a tree that is not at the
+ root level (e.g. `git ls-tree -r HEAD:sub dir`) in this case, as that
+ would result in asking for `sub/sub/dir` in the `HEAD` commit.
+ However, the current working directory can be ignored by passing
+ --full-tree option.
+
+OPTIONS
+-------
+<tree-ish>::
+ Id of a tree-ish.
+
+-d::
+ Show only the named tree entry itself, not its children.
+
+-r::
+ Recurse into sub-trees.
+
+-t::
+ Show tree entries even when going to recurse them. Has no effect
+ if `-r` was not passed. `-d` implies `-t`.
+
+-l::
+--long::
+ Show object size of blob (file) entries.
+
+-z::
+ \0 line termination on output and do not quote filenames.
+ See OUTPUT FORMAT below for more information.
+
+--name-only::
+--name-status::
+ List only filenames (instead of the "long" output), one per line.
+ Cannot be combined with `--object-only`.
+
+--object-only::
+ List only names of the objects, one per line. Cannot be combined
+ with `--name-only` or `--name-status`.
+ This is equivalent to specifying `--format='%(objectname)'`, but
+ for both this option and that exact format the command takes a
+ hand-optimized codepath instead of going through the generic
+ formatting mechanism.
+
+--abbrev[=<n>]::
+ Instead of showing the full 40-byte hexadecimal object
+ lines, show the shortest prefix that is at least '<n>'
+ hexdigits long that uniquely refers the object.
+ Non default number of digits can be specified with --abbrev=<n>.
+
+--full-name::
+ Instead of showing the path names relative to the current working
+ directory, show the full path names.
+
+--full-tree::
+ Do not limit the listing to the current working directory.
+ Implies --full-name.
+
+--format=<format>::
+ A string that interpolates `%(fieldname)` from the result
+ being shown. It also interpolates `%%` to `%`, and
+ `%xNN` where `NN` are hex digits interpolates to character
+ with hex code `NN`; for example `%x00` interpolates to
+ `\0` (NUL), `%x09` to `\t` (TAB) and `%x0a` to `\n` (LF).
+ When specified, `--format` cannot be combined with other
+ format-altering options, including `--long`, `--name-only`
+ and `--object-only`.
+
+[<path>...]::
+ When paths are given, show them (note that this isn't really raw
+ pathnames, but rather a list of patterns to match). Otherwise
+ implicitly uses the root level of the tree as the sole path argument.
+
+
+Output Format
+-------------
+
+The output format of `ls-tree` is determined by either the `--format`
+option, or other format-altering options such as `--name-only` etc.
+(see `--format` above).
+
+The use of certain `--format` directives is equivalent to using those
+options, but invoking the full formatting machinery can be slower than
+using an appropriate formatting option.
+
+In cases where the `--format` would exactly map to an existing option
+`ls-tree` will use the appropriate faster path. Thus the default format
+is equivalent to:
+
+ %(objectmode) %(objecttype) %(objectname)%x09%(path)
+
+This output format is compatible with what `--index-info --stdin` of
+'git update-index' expects.
+
+When the `-l` option is used, format changes to
+
+ %(objectmode) %(objecttype) %(objectname) %(objectsize:padded)%x09%(path)
+
+Object size identified by <objectname> is given in bytes, and right-justified
+with minimum width of 7 characters. Object size is given only for blobs
+(file) entries; for other entries `-` character is used in place of size.
+
+Without the `-z` option, pathnames with "unusual" characters are
+quoted as explained for the configuration variable `core.quotePath`
+(see linkgit:git-config[1]). Using `-z` the filename is output
+verbatim and the line is terminated by a NUL byte.
+
+Customized format:
+
+It is possible to print in a custom format by using the `--format` option,
+which is able to interpolate different fields using a `%(fieldname)` notation.
+For example, if you only care about the "objectname" and "path" fields, you
+can execute with a specific "--format" like
+
+ git ls-tree --format='%(objectname) %(path)' <tree-ish>
+
+FIELD NAMES
+-----------
+
+Various values from structured fields can be used to interpolate
+into the resulting output. For each outputting line, the following
+names can be used:
+
+objectmode::
+ The mode of the object.
+objecttype::
+ The type of the object (`commit`, `blob` or `tree`).
+objectname::
+ The name of the object.
+objectsize[:padded]::
+ The size of a `blob` object ("-" if it's a `commit` or `tree`).
+ It also supports a padded format of size with "%(objectsize:padded)".
+path::
+ The pathname of the object.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-mailinfo.adoc b/git-mailinfo.adoc
new file mode 100644
index 0000000..3b24c9a
--- /dev/null
+++ b/git-mailinfo.adoc
@@ -0,0 +1,127 @@
+git-mailinfo(1)
+===============
+
+NAME
+----
+git-mailinfo - Extracts patch and authorship from a single e-mail message
+
+
+SYNOPSIS
+--------
+[verse]
+'git mailinfo' [-k|-b] [-u | --encoding=<encoding> | -n]
+ [--[no-]scissors] [--quoted-cr=<action>]
+ <msg> <patch>
+
+
+DESCRIPTION
+-----------
+Reads a single e-mail message from the standard input, and
+writes the commit log message in <msg> file, and the patches in
+<patch> file. The author name, e-mail and e-mail subject are
+written out to the standard output to be used by 'git am'
+to create a commit. It is usually not necessary to use this
+command directly. See linkgit:git-am[1] instead.
+
+
+OPTIONS
+-------
+-k::
+ Usually the program removes email cruft from the Subject:
+ header line to extract the title line for the commit log
+ message. This option prevents this munging, and is most
+ useful when used to read back 'git format-patch -k' output.
++
+Specifically, the following are removed until none of them remain:
++
+--
+* Leading and trailing whitespace.
+
+* Leading `Re:`, `re:`, and `:`.
+
+* Leading bracketed strings (between `[` and `]`, usually
+ `[PATCH]`).
+--
++
+Finally, runs of whitespace are normalized to a single ASCII space
+character.
+
+-b::
+ When -k is not in effect, all leading strings bracketed with '['
+ and ']' pairs are stripped. This option limits the stripping to
+ only the pairs whose bracketed string contains the word "PATCH".
+
+-u::
+ The commit log message, author name and author email are
+ taken from the e-mail, and after minimally decoding MIME
+ transfer encoding, re-coded in the charset specified by
+ `i18n.commitEncoding` (defaulting to UTF-8) by transliterating
+ them. This used to be optional but now it is the default.
++
+Note that the patch is always used as-is without charset
+conversion, even with this flag.
+
+--encoding=<encoding>::
+ Similar to -u. But when re-coding, the charset specified here is
+ used instead of the one specified by `i18n.commitEncoding` or UTF-8.
+
+-n::
+ Disable all charset re-coding of the metadata.
+
+-m::
+--message-id::
+ Copy the Message-ID header at the end of the commit message. This
+ is useful in order to associate commits with mailing list discussions.
+
+--scissors::
+ Remove everything in body before a scissors line (e.g. "-- >8 --").
+ The line represents scissors and perforation marks, and is used to
+ request the reader to cut the message at that line. If that line
+ appears in the body of the message before the patch, everything
+ before it (including the scissors line itself) is ignored when
+ this option is used.
++
+This is useful if you want to begin your message in a discussion thread
+with comments and suggestions on the message you are responding to, and to
+conclude it with a patch submission, separating the discussion and the
+beginning of the proposed commit log message with a scissors line.
++
+This can be enabled by default with the configuration option mailinfo.scissors.
+
+--no-scissors::
+ Ignore scissors lines. Useful for overriding mailinfo.scissors settings.
+
+--quoted-cr=<action>::
+ Action when processes email messages sent with base64 or
+ quoted-printable encoding, and the decoded lines end with a CRLF
+ instead of a simple LF.
++
+The valid actions are:
++
+--
+* `nowarn`: Git will do nothing when such a CRLF is found.
+* `warn`: Git will issue a warning for each message if such a CRLF is
+ found.
+* `strip`: Git will convert those CRLF to LF.
+--
++
+The default action could be set by configuration option `mailinfo.quotedCR`.
+If no such configuration option has been set, `warn` will be used.
+
+<msg>::
+ The commit log message extracted from e-mail, usually
+ except the title line which comes from e-mail Subject.
+
+<patch>::
+ The patch extracted from e-mail.
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/mailinfo.adoc[]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-mailsplit.adoc b/git-mailsplit.adoc
new file mode 100644
index 0000000..3f0a666
--- /dev/null
+++ b/git-mailsplit.adoc
@@ -0,0 +1,57 @@
+git-mailsplit(1)
+================
+
+NAME
+----
+git-mailsplit - Simple UNIX mbox splitter program
+
+SYNOPSIS
+--------
+[verse]
+'git mailsplit' [-b] [-f<nn>] [-d<prec>] [--keep-cr] [--mboxrd]
+ -o<directory> [--] [(<mbox>|<Maildir>)...]
+
+DESCRIPTION
+-----------
+Splits a mbox file or a Maildir into a list of files: "0001" "0002" .. in the
+specified directory so you can process them further from there.
+
+IMPORTANT: Maildir splitting relies upon filenames being sorted to output
+patches in the correct order.
+
+OPTIONS
+-------
+<mbox>::
+ Mbox file to split. If not given, the mbox is read from
+ the standard input.
+
+<Maildir>::
+ Root of the Maildir to split. This directory should contain the cur, tmp
+ and new subdirectories.
+
+-o<directory>::
+ Directory in which to place the individual messages.
+
+-b::
+ If any file doesn't begin with a From line, assume it is a
+ single mail message instead of signaling an error.
+
+-d<prec>::
+ Instead of the default 4 digits with leading zeros,
+ different precision can be specified for the generated
+ filenames.
+
+-f<nn>::
+ Skip the first <nn> numbers, for example if -f3 is specified,
+ start the numbering with 0004.
+
+--keep-cr::
+ Do not remove `\r` from lines ending with `\r\n`.
+
+--mboxrd::
+ Input is of the "mboxrd" format and "^>+From " line escaping is
+ reversed.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-maintenance.adoc b/git-maintenance.adoc
new file mode 100644
index 0000000..0450d74
--- /dev/null
+++ b/git-maintenance.adoc
@@ -0,0 +1,419 @@
+git-maintenance(1)
+==================
+
+NAME
+----
+git-maintenance - Run tasks to optimize Git repository data
+
+
+SYNOPSIS
+--------
+[verse]
+'git maintenance' run [<options>]
+'git maintenance' start [--scheduler=<scheduler>]
+'git maintenance' (stop|register|unregister) [<options>]
+
+
+DESCRIPTION
+-----------
+Run tasks to optimize Git repository data, speeding up other Git commands
+and reducing storage requirements for the repository.
+
+Git commands that add repository data, such as `git add` or `git fetch`,
+are optimized for a responsive user experience. These commands do not take
+time to optimize the Git data, since such optimizations scale with the full
+size of the repository while these user commands each perform a relatively
+small action.
+
+The `git maintenance` command provides flexibility for how to optimize the
+Git repository.
+
+SUBCOMMANDS
+-----------
+
+run::
+ Run one or more maintenance tasks. If one or more `--task` options
+ are specified, then those tasks are run in that order. Otherwise,
+ the tasks are determined by which `maintenance.<task>.enabled`
+ config options are true. By default, only `maintenance.gc.enabled`
+ is true.
+
+start::
+ Start running maintenance on the current repository. This performs
+ the same config updates as the `register` subcommand, then updates
+ the background scheduler to run `git maintenance run --scheduled`
+ on an hourly basis.
+
+stop::
+ Halt the background maintenance schedule. The current repository
+ is not removed from the list of maintained repositories, in case
+ the background maintenance is restarted later.
+
+register::
+ Initialize Git config values so any scheduled maintenance will start
+ running on this repository. This adds the repository to the
+ `maintenance.repo` config variable in the current user's global config,
+ or the config specified by --config-file option, and enables some
+ recommended configuration values for `maintenance.<task>.schedule`. The
+ tasks that are enabled are safe for running in the background without
+ disrupting foreground processes.
++
+The `register` subcommand will also set the `maintenance.strategy` config
+value to `incremental`, if this value is not previously set. The
+`incremental` strategy uses the following schedule for each maintenance
+task:
++
+--
+* `gc`: disabled.
+* `commit-graph`: hourly.
+* `prefetch`: hourly.
+* `loose-objects`: daily.
+* `incremental-repack`: daily.
+--
++
+`git maintenance register` will also disable foreground maintenance by
+setting `maintenance.auto = false` in the current repository. This config
+setting will remain after a `git maintenance unregister` command.
+
+unregister::
+ Remove the current repository from background maintenance. This
+ only removes the repository from the configured list. It does not
+ stop the background maintenance processes from running.
++
+The `unregister` subcommand will report an error if the current repository
+is not already registered. Use the `--force` option to return success even
+when the current repository is not registered.
+
+TASKS
+-----
+
+commit-graph::
+ The `commit-graph` job updates the `commit-graph` files incrementally,
+ then verifies that the written data is correct. The incremental
+ write is safe to run alongside concurrent Git processes since it
+ will not expire `.graph` files that were in the previous
+ `commit-graph-chain` file. They will be deleted by a later run based
+ on the expiration delay.
+
+prefetch::
+ The `prefetch` task updates the object directory with the latest
+ objects from all registered remotes. For each remote, a `git fetch`
+ command is run. The configured refspec is modified to place all
+ requested refs within `refs/prefetch/`. Also, tags are not updated.
++
+This is done to avoid disrupting the remote-tracking branches. The end users
+expect these refs to stay unmoved unless they initiate a fetch. However,
+with the prefetch task, the objects necessary to complete a later real fetch
+would already be obtained, making the real fetch faster. In the ideal case,
+it will just become an update to a bunch of remote-tracking branches without
+any object transfer.
++
+The `remote.<name>.skipFetchAll` configuration can be used to
+exclude a particular remote from getting prefetched.
+
+gc::
+ Clean up unnecessary files and optimize the local repository. "GC"
+ stands for "garbage collection," but this task performs many
+ smaller tasks. This task can be expensive for large repositories,
+ as it repacks all Git objects into a single pack-file. It can also
+ be disruptive in some situations, as it deletes stale data. See
+ linkgit:git-gc[1] for more details on garbage collection in Git.
+
+loose-objects::
+ The `loose-objects` job cleans up loose objects and places them into
+ pack-files. In order to prevent race conditions with concurrent Git
+ commands, it follows a two-step process. First, it deletes any loose
+ objects that already exist in a pack-file; concurrent Git processes
+ will examine the pack-file for the object data instead of the loose
+ object. Second, it creates a new pack-file (starting with "loose-")
+ containing a batch of loose objects. The batch size is limited to 50
+ thousand objects to prevent the job from taking too long on a
+ repository with many loose objects. The `gc` task writes unreachable
+ objects as loose objects to be cleaned up by a later step only if
+ they are not re-added to a pack-file; for this reason it is not
+ advisable to enable both the `loose-objects` and `gc` tasks at the
+ same time.
+
+incremental-repack::
+ The `incremental-repack` job repacks the object directory
+ using the `multi-pack-index` feature. In order to prevent race
+ conditions with concurrent Git commands, it follows a two-step
+ process. First, it calls `git multi-pack-index expire` to delete
+ pack-files unreferenced by the `multi-pack-index` file. Second, it
+ calls `git multi-pack-index repack` to select several small
+ pack-files and repack them into a bigger one, and then update the
+ `multi-pack-index` entries that refer to the small pack-files to
+ refer to the new pack-file. This prepares those small pack-files
+ for deletion upon the next run of `git multi-pack-index expire`.
+ The selection of the small pack-files is such that the expected
+ size of the big pack-file is at least the batch size; see the
+ `--batch-size` option for the `repack` subcommand in
+ linkgit:git-multi-pack-index[1]. The default batch-size is zero,
+ which is a special case that attempts to repack all pack-files
+ into a single pack-file.
+
+pack-refs::
+ The `pack-refs` task collects the loose reference files and
+ collects them into a single file. This speeds up operations that
+ need to iterate across many references. See linkgit:git-pack-refs[1]
+ for more information.
+
+OPTIONS
+-------
+--auto::
+ When combined with the `run` subcommand, run maintenance tasks
+ only if certain thresholds are met. For example, the `gc` task
+ runs when the number of loose objects exceeds the number stored
+ in the `gc.auto` config setting, or when the number of pack-files
+ exceeds the `gc.autoPackLimit` config setting. Not compatible with
+ the `--schedule` option.
+
+--schedule::
+ When combined with the `run` subcommand, run maintenance tasks
+ only if certain time conditions are met, as specified by the
+ `maintenance.<task>.schedule` config value for each `<task>`.
+ This config value specifies a number of seconds since the last
+ time that task ran, according to the `maintenance.<task>.lastRun`
+ config value. The tasks that are tested are those provided by
+ the `--task=<task>` option(s) or those with
+ `maintenance.<task>.enabled` set to true.
+
+--quiet::
+ Do not report progress or other information over `stderr`.
+
+--task=<task>::
+ If this option is specified one or more times, then only run the
+ specified tasks in the specified order. If no `--task=<task>`
+ arguments are specified, then only the tasks with
+ `maintenance.<task>.enabled` configured as `true` are considered.
+ See the 'TASKS' section for the list of accepted `<task>` values.
+
+--scheduler=auto|crontab|systemd-timer|launchctl|schtasks::
+ When combined with the `start` subcommand, specify the scheduler
+ for running the hourly, daily and weekly executions of
+ `git maintenance run`.
+ Possible values for `<scheduler>` are `auto`, `crontab`
+ (POSIX), `systemd-timer` (Linux), `launchctl` (macOS), and
+ `schtasks` (Windows). When `auto` is specified, the
+ appropriate platform-specific scheduler is used; on Linux,
+ `systemd-timer` is used if available, otherwise
+ `crontab`. Default is `auto`.
+
+
+TROUBLESHOOTING
+---------------
+The `git maintenance` command is designed to simplify the repository
+maintenance patterns while minimizing user wait time during Git commands.
+A variety of configuration options are available to allow customizing this
+process. The default maintenance options focus on operations that complete
+quickly, even on large repositories.
+
+Users may find some cases where scheduled maintenance tasks do not run as
+frequently as intended. Each `git maintenance run` command takes a lock on
+the repository's object database, and this prevents other concurrent
+`git maintenance run` commands from running on the same repository. Without
+this safeguard, competing processes could leave the repository in an
+unpredictable state.
+
+The background maintenance schedule runs `git maintenance run` processes
+on an hourly basis. Each run executes the "hourly" tasks. At midnight,
+that process also executes the "daily" tasks. At midnight on the first day
+of the week, that process also executes the "weekly" tasks. A single
+process iterates over each registered repository, performing the scheduled
+tasks for that frequency. The processes are scheduled to a random minute of
+the hour per client to spread out the load that multiple clients might
+generate (e.g. from prefetching). Depending on the number of registered
+repositories and their sizes, this process may take longer than an hour.
+In this case, multiple `git maintenance run` commands may run on the same
+repository at the same time, colliding on the object database lock. This
+results in one of the two tasks not running.
+
+If you find that some maintenance windows are taking longer than one hour
+to complete, then consider reducing the complexity of your maintenance
+tasks. For example, the `gc` task is much slower than the
+`incremental-repack` task. However, this comes at a cost of a slightly
+larger object database. Consider moving more expensive tasks to be run
+less frequently.
+
+Expert users may consider scheduling their own maintenance tasks using a
+different schedule than is available through `git maintenance start` and
+Git configuration options. These users should be aware of the object
+database lock and how concurrent `git maintenance run` commands behave.
+Further, the `git gc` command should not be combined with
+`git maintenance run` commands. `git gc` modifies the object database
+but does not take the lock in the same way as `git maintenance run`. If
+possible, use `git maintenance run --task=gc` instead of `git gc`.
+
+The following sections describe the mechanisms put in place to run
+background maintenance by `git maintenance start` and how to customize
+them.
+
+BACKGROUND MAINTENANCE ON POSIX SYSTEMS
+---------------------------------------
+
+The standard mechanism for scheduling background tasks on POSIX systems
+is cron(8). This tool executes commands based on a given schedule. The
+current list of user-scheduled tasks can be found by running `crontab -l`.
+The schedule written by `git maintenance start` is similar to this:
+
+-----------------------------------------------------------------------
+# BEGIN GIT MAINTENANCE SCHEDULE
+# The following schedule was created by Git
+# Any edits made in this region might be
+# replaced in the future by a Git command.
+
+0 1-23 * * * "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=hourly
+0 0 * * 1-6 "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=daily
+0 0 * * 0 "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=weekly
+
+# END GIT MAINTENANCE SCHEDULE
+-----------------------------------------------------------------------
+
+The comments are used as a region to mark the schedule as written by Git.
+Any modifications within this region will be completely deleted by
+`git maintenance stop` or overwritten by `git maintenance start`.
+
+The `crontab` entry specifies the full path of the `git` executable to
+ensure that the executed `git` command is the same one with which
+`git maintenance start` was issued independent of `PATH`. If the same user
+runs `git maintenance start` with multiple Git executables, then only the
+latest executable is used.
+
+These commands use `git for-each-repo --config=maintenance.repo` to run
+`git maintenance run --schedule=<frequency>` on each repository listed in
+the multi-valued `maintenance.repo` config option. These are typically
+loaded from the user-specific global config. The `git maintenance` process
+then determines which maintenance tasks are configured to run on each
+repository with each `<frequency>` using the `maintenance.<task>.schedule`
+config options. These values are loaded from the global or repository
+config values.
+
+If the config values are insufficient to achieve your desired background
+maintenance schedule, then you can create your own schedule. If you run
+`crontab -e`, then an editor will load with your user-specific `cron`
+schedule. In that editor, you can add your own schedule lines. You could
+start by adapting the default schedule listed earlier, or you could read
+the crontab(5) documentation for advanced scheduling techniques. Please
+do use the full path and `--exec-path` techniques from the default
+schedule to ensure you are executing the correct binaries in your
+schedule.
+
+
+BACKGROUND MAINTENANCE ON LINUX SYSTEMD SYSTEMS
+-----------------------------------------------
+
+While Linux supports `cron`, depending on the distribution, `cron` may
+be an optional package not necessarily installed. On modern Linux
+distributions, systemd timers are superseding it.
+
+If user systemd timers are available, they will be used as a replacement
+of `cron`.
+
+In this case, `git maintenance start` will create user systemd timer units
+and start the timers. The current list of user-scheduled tasks can be found
+by running `systemctl --user list-timers`. The timers written by `git
+maintenance start` are similar to this:
+
+-----------------------------------------------------------------------
+$ systemctl --user list-timers
+NEXT LEFT LAST PASSED UNIT ACTIVATES
+Thu 2021-04-29 19:00:00 CEST 42min left Thu 2021-04-29 18:00:11 CEST 17min ago git-maintenance@hourly.timer git-maintenance@hourly.service
+Fri 2021-04-30 00:00:00 CEST 5h 42min left Thu 2021-04-29 00:00:11 CEST 18h ago git-maintenance@daily.timer git-maintenance@daily.service
+Mon 2021-05-03 00:00:00 CEST 3 days left Mon 2021-04-26 00:00:11 CEST 3 days ago git-maintenance@weekly.timer git-maintenance@weekly.service
+-----------------------------------------------------------------------
+
+One timer is registered for each `--schedule=<frequency>` option.
+
+The definition of the systemd units can be inspected in the following files:
+
+-----------------------------------------------------------------------
+~/.config/systemd/user/git-maintenance@.timer
+~/.config/systemd/user/git-maintenance@.service
+~/.config/systemd/user/timers.target.wants/git-maintenance@hourly.timer
+~/.config/systemd/user/timers.target.wants/git-maintenance@daily.timer
+~/.config/systemd/user/timers.target.wants/git-maintenance@weekly.timer
+-----------------------------------------------------------------------
+
+`git maintenance start` will overwrite these files and start the timer
+again with `systemctl --user`, so any customization should be done by
+creating a drop-in file, i.e. a `.conf` suffixed file in the
+`~/.config/systemd/user/git-maintenance@.service.d` directory.
+
+`git maintenance stop` will stop the user systemd timers and delete
+the above mentioned files.
+
+For more details, see `systemd.timer(5)`.
+
+
+BACKGROUND MAINTENANCE ON MACOS SYSTEMS
+---------------------------------------
+
+While macOS technically supports `cron`, using `crontab -e` requires
+elevated privileges and the executed process does not have a full user
+context. Without a full user context, Git and its credential helpers
+cannot access stored credentials, so some maintenance tasks are not
+functional.
+
+Instead, `git maintenance start` interacts with the `launchctl` tool,
+which is the recommended way to schedule timed jobs in macOS. Scheduling
+maintenance through `git maintenance (start|stop)` requires some
+`launchctl` features available only in macOS 10.11 or later.
+
+Your user-specific scheduled tasks are stored as XML-formatted `.plist`
+files in `~/Library/LaunchAgents/`. You can see the currently-registered
+tasks using the following command:
+
+-----------------------------------------------------------------------
+$ ls ~/Library/LaunchAgents/org.git-scm.git*
+org.git-scm.git.daily.plist
+org.git-scm.git.hourly.plist
+org.git-scm.git.weekly.plist
+-----------------------------------------------------------------------
+
+One task is registered for each `--schedule=<frequency>` option. To
+inspect how the XML format describes each schedule, open one of these
+`.plist` files in an editor and inspect the `<array>` element following
+the `<key>StartCalendarInterval</key>` element.
+
+`git maintenance start` will overwrite these files and register the
+tasks again with `launchctl`, so any customizations should be done by
+creating your own `.plist` files with distinct names. Similarly, the
+`git maintenance stop` command will unregister the tasks with `launchctl`
+and delete the `.plist` files.
+
+To create more advanced customizations to your background tasks, see
+launchctl.plist(5) for more information.
+
+
+BACKGROUND MAINTENANCE ON WINDOWS SYSTEMS
+-----------------------------------------
+
+Windows does not support `cron` and instead has its own system for
+scheduling background tasks. The `git maintenance start` command uses
+the `schtasks` command to submit tasks to this system. You can inspect
+all background tasks using the Task Scheduler application. The tasks
+added by Git have names of the form `Git Maintenance (<frequency>)`.
+The Task Scheduler GUI has ways to inspect these tasks, but you can also
+export the tasks to XML files and view the details there.
+
+Note that since Git is a console application, these background tasks
+create a console window visible to the current user. This can be changed
+manually by selecting the "Run whether user is logged in or not" option
+in Task Scheduler. This change requires a password input, which is why
+`git maintenance start` does not select it by default.
+
+If you want to customize the background tasks, please rename the tasks
+so future calls to `git maintenance (start|stop)` do not overwrite your
+custom tasks.
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/maintenance.adoc[]
+
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-merge-base.adoc b/git-merge-base.adoc
new file mode 100644
index 0000000..5ab957c
--- /dev/null
+++ b/git-merge-base.adoc
@@ -0,0 +1,247 @@
+git-merge-base(1)
+=================
+
+NAME
+----
+git-merge-base - Find as good common ancestors as possible for a merge
+
+
+SYNOPSIS
+--------
+[verse]
+'git merge-base' [-a | --all] <commit> <commit>...
+'git merge-base' [-a | --all] --octopus <commit>...
+'git merge-base' --is-ancestor <commit> <commit>
+'git merge-base' --independent <commit>...
+'git merge-base' --fork-point <ref> [<commit>]
+
+DESCRIPTION
+-----------
+
+'git merge-base' finds the best common ancestor(s) between two commits to use
+in a three-way merge. One common ancestor is 'better' than another common
+ancestor if the latter is an ancestor of the former. A common ancestor
+that does not have any better common ancestor is a 'best common
+ancestor', i.e. a 'merge base'. Note that there can be more than one
+merge base for a pair of commits.
+
+OPERATION MODES
+---------------
+
+In the most common special case, specifying only two commits on the
+command line means computing the merge base between the given two commits.
+
+More generally, among the two commits to compute the merge base from,
+one is specified by the first commit argument on the command line;
+the other commit is a (possibly hypothetical) commit that is a merge
+across all the remaining commits on the command line.
+
+As a consequence, the 'merge base' is not necessarily contained in each of the
+commit arguments if more than two commits are specified. This is different
+from linkgit:git-show-branch[1] when used with the `--merge-base` option.
+
+--octopus::
+ Compute the best common ancestors of all supplied commits,
+ in preparation for an n-way merge. This mimics the behavior
+ of 'git show-branch --merge-base'.
+
+--independent::
+ Instead of printing merge bases, print a minimal subset of
+ the supplied commits with the same ancestors. In other words,
+ among the commits given, list those which cannot be reached
+ from any other. This mimics the behavior of 'git show-branch
+ --independent'.
+
+--is-ancestor::
+ Check if the first <commit> is an ancestor of the second <commit>,
+ and exit with status 0 if true, or with status 1 if not.
+ Errors are signaled by a non-zero status that is not 1.
+
+--fork-point::
+ Find the point at which a branch (or any history that leads
+ to <commit>) forked from another branch (or any reference)
+ <ref>. This does not just look for the common ancestor of
+ the two commits, but also takes into account the reflog of
+ <ref> to see if the history leading to <commit> forked from
+ an earlier incarnation of the branch <ref> (see discussion
+ of this mode below).
+
+OPTIONS
+-------
+-a::
+--all::
+ Output all merge bases for the commits, instead of just one.
+
+DISCUSSION
+----------
+
+Given two commits 'A' and 'B', `git merge-base A B` will output a commit
+which is reachable from both 'A' and 'B' through the parent relationship.
+
+For example, with this topology:
+
+....
+ o---o---o---B
+ /
+---o---1---o---o---o---A
+....
+
+the merge base between 'A' and 'B' is '1'.
+
+Given three commits 'A', 'B', and 'C', `git merge-base A B C` will compute the
+merge base between 'A' and a hypothetical commit 'M', which is a merge
+between 'B' and 'C'. For example, with this topology:
+
+....
+ o---o---o---o---C
+ /
+ / o---o---o---B
+ / /
+---2---1---o---o---o---A
+....
+
+the result of `git merge-base A B C` is '1'. This is because the
+equivalent topology with a merge commit 'M' between 'B' and 'C' is:
+
+
+....
+ o---o---o---o---o
+ / \
+ / o---o---o---o---M
+ / /
+---2---1---o---o---o---A
+....
+
+and the result of `git merge-base A M` is '1'. Commit '2' is also a
+common ancestor between 'A' and 'M', but '1' is a better common ancestor,
+because '2' is an ancestor of '1'. Hence, '2' is not a merge base.
+
+The result of `git merge-base --octopus A B C` is '2', because '2' is
+the best common ancestor of all commits.
+
+When the history involves criss-cross merges, there can be more than one
+'best' common ancestor for two commits. For example, with this topology:
+
+....
+---1---o---A
+ \ /
+ X
+ / \
+---2---o---o---B
+....
+
+both '1' and '2' are merge bases of A and B. Neither one is better than
+the other (both are 'best' merge bases). When the `--all` option is not given,
+it is unspecified which best one is output.
+
+A common idiom to check "fast-forward-ness" between two commits A
+and B is (or at least used to be) to compute the merge base between
+A and B, and check if it is the same as A, in which case, A is an
+ancestor of B. You will see this idiom used often in older scripts.
+
+....
+A=$(git rev-parse --verify A)
+if test "$A" = "$(git merge-base A B)"
+then
+ ... A is an ancestor of B ...
+fi
+....
+
+In modern git, you can say this in a more direct way:
+
+....
+if git merge-base --is-ancestor A B
+then
+ ... A is an ancestor of B ...
+fi
+....
+
+instead.
+
+Discussion on fork-point mode
+-----------------------------
+
+After working on the `topic` branch created with `git switch -c
+topic origin/master`, the history of remote-tracking branch
+`origin/master` may have been rewound and rebuilt, leading to a
+history of this shape:
+
+....
+ o---B2
+ /
+---o---o---B1--o---o---o---B (origin/master)
+ \
+ B0
+ \
+ D0---D1---D (topic)
+....
+
+where `origin/master` used to point at commits B0, B1, B2 and now it
+points at B, and your `topic` branch was started on top of it back
+when `origin/master` was at B0, and you built three commits, D0, D1,
+and D, on top of it. Imagine that you now want to rebase the work
+you did on the topic on top of the updated origin/master.
+
+In such a case, `git merge-base origin/master topic` would return the
+parent of B0 in the above picture, but B0^..D is *not* the range of
+commits you would want to replay on top of B (it includes B0, which
+is not what you wrote; it is a commit the other side discarded when
+it moved its tip from B0 to B1).
+
+`git merge-base --fork-point origin/master topic` is designed to
+help in such a case. It takes not only B but also B0, B1, and B2
+(i.e. old tips of the remote-tracking branches your repository's
+reflog knows about) into account to see on which commit your topic
+branch was built and finds B0, allowing you to replay only the
+commits on your topic, excluding the commits the other side later
+discarded.
+
+Hence
+
+ $ fork_point=$(git merge-base --fork-point origin/master topic)
+
+will find B0, and
+
+ $ git rebase --onto origin/master $fork_point topic
+
+will replay D0, D1, and D on top of B to create a new history of this
+shape:
+
+....
+ o---B2
+ /
+---o---o---B1--o---o---o---B (origin/master)
+ \ \
+ B0 D0'--D1'--D' (topic - updated)
+ \
+ D0---D1---D (topic - old)
+....
+
+A caveat is that older reflog entries in your repository may be
+expired by `git gc`. If B0 no longer appears in the reflog of the
+remote-tracking branch `origin/master`, the `--fork-point` mode
+obviously cannot find it and fails, avoiding to give a random and
+useless result (such as the parent of B0, like the same command
+without the `--fork-point` option gives).
+
+Also, the remote-tracking branch you use the `--fork-point` mode
+with must be the one your topic forked from its tip. If you forked
+from an older commit than the tip, this mode would not find the fork
+point (imagine in the above sample history B0 did not exist,
+origin/master started at B1, moved to B2 and then B, and you forked
+your topic at origin/master^ when origin/master was B1; the shape of
+the history would be the same as above, without B0, and the parent
+of B1 is what `git merge-base origin/master topic` correctly finds,
+but the `--fork-point` mode will not, because it is not one of the
+commits that used to be at the tip of origin/master).
+
+
+See also
+--------
+linkgit:git-rev-list[1],
+linkgit:git-show-branch[1],
+linkgit:git-merge[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-merge-file.adoc b/git-merge-file.adoc
new file mode 100644
index 0000000..71915a0
--- /dev/null
+++ b/git-merge-file.adoc
@@ -0,0 +1,122 @@
+git-merge-file(1)
+=================
+
+NAME
+----
+git-merge-file - Run a three-way file merge
+
+
+SYNOPSIS
+--------
+[verse]
+'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
+ [--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>]
+ [--[no-]diff3] [--object-id] <current> <base> <other>
+
+
+DESCRIPTION
+-----------
+Given three files `<current>`, `<base>` and `<other>`,
+'git merge-file' incorporates all changes that lead from `<base>`
+to `<other>` into `<current>`. The result ordinarily goes into
+`<current>`. 'git merge-file' is useful for combining separate changes
+to an original. Suppose `<base>` is the original, and both
+`<current>` and `<other>` are modifications of `<base>`,
+then 'git merge-file' combines both changes.
+
+A conflict occurs if both `<current>` and `<other>` have changes
+in a common segment of lines. If a conflict is found, 'git merge-file'
+normally outputs a warning and brackets the conflict with lines containing
+<<<<<<< and >>>>>>> markers. A typical conflict will look like this:
+
+ <<<<<<< A
+ lines in file A
+ =======
+ lines in file B
+ >>>>>>> B
+
+If there are conflicts, the user should edit the result and delete one of
+the alternatives. When `--ours`, `--theirs`, or `--union` option is in effect,
+however, these conflicts are resolved favouring lines from `<current>`,
+lines from `<other>`, or lines from both respectively. The length of the
+conflict markers can be given with the `--marker-size` option.
+
+If `--object-id` is specified, exactly the same behavior occurs, except that
+instead of specifying what to merge as files, it is specified as a list of
+object IDs referring to blobs.
+
+The exit value of this program is negative on error, and the number of
+conflicts otherwise (truncated to 127 if there are more than that many
+conflicts). If the merge was clean, the exit value is 0.
+
+'git merge-file' is designed to be a minimal clone of RCS 'merge'; that is, it
+implements all of RCS 'merge''s functionality which is needed by
+linkgit:git[1].
+
+
+OPTIONS
+-------
+
+--object-id::
+ Specify the contents to merge as blobs in the current repository instead of
+ files. In this case, the operation must take place within a valid repository.
++
+If the `-p` option is specified, the merged file (including conflicts, if any)
+goes to standard output as normal; otherwise, the merged file is written to the
+object store and the object ID of its blob is written to standard output.
+
+-L <label>::
+ This option may be given up to three times, and
+ specifies labels to be used in place of the
+ corresponding file names in conflict reports. That is,
+ `git merge-file -L x -L y -L z a b c` generates output that
+ looks like it came from files x, y and z instead of
+ from files a, b and c.
+
+-p::
+ Send results to standard output instead of overwriting
+ `<current>`.
+
+-q::
+ Quiet; do not warn about conflicts.
+
+--diff3::
+ Show conflicts in "diff3" style.
+
+--zdiff3::
+ Show conflicts in "zdiff3" style.
+
+--ours::
+--theirs::
+--union::
+ Instead of leaving conflicts in the file, resolve conflicts
+ favouring our (or their or both) side of the lines.
+
+--diff-algorithm={patience|minimal|histogram|myers}::
+ Use a different diff algorithm while merging. The current default is "myers",
+ but selecting more recent algorithm such as "histogram" can help
+ avoid mismerges that occur due to unimportant matching lines
+ (such as braces from distinct functions). See also
+ linkgit:git-diff[1] `--diff-algorithm`.
+
+EXAMPLES
+--------
+
+`git merge-file README.my README README.upstream`::
+
+ combines the changes of README.my and README.upstream since README,
+ tries to merge them and writes the result into README.my.
+
+`git merge-file -L a -L b -L c tmp/a123 tmp/b234 tmp/c345`::
+
+ merges tmp/a123 and tmp/c345 with the base tmp/b234, but uses labels
+ `a` and `c` instead of `tmp/a123` and `tmp/c345`.
+
+`git merge-file -p --object-id abc1234 def567 890abcd`::
+
+ combines the changes of the blob abc1234 and 890abcd since def567,
+ tries to merge them and writes the result to standard output
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-merge-index.adoc b/git-merge-index.adoc
new file mode 100644
index 0000000..eea56b3
--- /dev/null
+++ b/git-merge-index.adoc
@@ -0,0 +1,83 @@
+git-merge-index(1)
+==================
+
+NAME
+----
+git-merge-index - Run a merge for files needing merging
+
+
+SYNOPSIS
+--------
+[verse]
+'git merge-index' [-o] [-q] <merge-program> (-a | ( [--] <file>...) )
+
+DESCRIPTION
+-----------
+This looks up the <file>(s) in the index and, if there are any merge
+entries, passes the SHA-1 hash for those files as arguments 1, 2, 3 (empty
+argument if no file), and <file> as argument 4. File modes for the three
+files are passed as arguments 5, 6 and 7.
+
+OPTIONS
+-------
+\--::
+ Do not interpret any more arguments as options.
+
+-a::
+ Run merge against all files in the index that need merging.
+
+-o::
+ Instead of stopping at the first failed merge, do all of them
+ in one shot - continue with merging even when previous merges
+ returned errors, and only return the error code after all the
+ merges.
+
+-q::
+ Do not complain about a failed merge program (a merge program
+ failure usually indicates conflicts during the merge). This is for
+ porcelains which might want to emit custom messages.
+
+If 'git merge-index' is called with multiple <file>s (or -a) then it
+processes them in turn only stopping if merge returns a non-zero exit
+code.
+
+Typically this is run with a script calling Git's imitation of
+the 'merge' command from the RCS package.
+
+A sample script called 'git merge-one-file' is included in the
+distribution.
+
+ALERT ALERT ALERT! The Git "merge object order" is different from the
+RCS 'merge' program merge object order. In the above ordering, the
+original is first. But the argument order to the 3-way merge program
+'merge' is to have the original in the middle. Don't ask me why.
+
+Examples:
+
+----
+torvalds@ppc970:~/merge-test> git merge-index cat MM
+This is MM from the original tree. # original
+This is modified MM in the branch A. # merge1
+This is modified MM in the branch B. # merge2
+This is modified MM in the branch B. # current contents
+----
+
+or
+
+----
+torvalds@ppc970:~/merge-test> git merge-index cat AA MM
+cat: : No such file or directory
+This is added AA in the branch A.
+This is added AA in the branch B.
+This is added AA in the branch B.
+fatal: merge program failed
+----
+
+where the latter example shows how 'git merge-index' will stop trying to
+merge once anything has returned an error (i.e., `cat` returned an error
+for the AA file, because it didn't exist in the original, and thus
+'git merge-index' didn't even try to merge the MM thing).
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-merge-one-file.adoc b/git-merge-one-file.adoc
new file mode 100644
index 0000000..04e803d
--- /dev/null
+++ b/git-merge-one-file.adoc
@@ -0,0 +1,21 @@
+git-merge-one-file(1)
+=====================
+
+NAME
+----
+git-merge-one-file - The standard helper program to use with git-merge-index
+
+
+SYNOPSIS
+--------
+[verse]
+'git merge-one-file'
+
+DESCRIPTION
+-----------
+This is the standard helper program to use with 'git merge-index'
+to resolve a merge after the trivial merge done with 'git read-tree -m'.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-merge-tree.adoc b/git-merge-tree.adoc
new file mode 100644
index 0000000..0b6a8a1
--- /dev/null
+++ b/git-merge-tree.adoc
@@ -0,0 +1,330 @@
+git-merge-tree(1)
+=================
+
+NAME
+----
+git-merge-tree - Perform merge without touching index or working tree
+
+
+SYNOPSIS
+--------
+[verse]
+'git merge-tree' [--write-tree] [<options>] <branch1> <branch2>
+'git merge-tree' [--trivial-merge] <base-tree> <branch1> <branch2> (deprecated)
+
+[[NEWMERGE]]
+DESCRIPTION
+-----------
+
+This command has a modern `--write-tree` mode and a deprecated
+`--trivial-merge` mode. With the exception of the
+<<DEPMERGE,DEPRECATED DESCRIPTION>> section at the end, the rest of
+this documentation describes the modern `--write-tree` mode.
+
+Performs a merge, but does not make any new commits and does not read
+from or write to either the working tree or index.
+
+The performed merge will use the same features as the "real"
+linkgit:git-merge[1], including:
+
+ * three way content merges of individual files
+ * rename detection
+ * proper directory/file conflict handling
+ * recursive ancestor consolidation (i.e. when there is more than one
+ merge base, creating a virtual merge base by merging the merge bases)
+ * etc.
+
+After the merge completes, a new toplevel tree object is created. See
+`OUTPUT` below for details.
+
+OPTIONS
+-------
+
+-z::
+ Do not quote filenames in the <Conflicted file info> section,
+ and end each filename with a NUL character rather than
+ newline. Also begin the messages section with a NUL character
+ instead of a newline. See <<OUTPUT>> below for more information.
+
+--name-only::
+ In the Conflicted file info section, instead of writing a list
+ of (mode, oid, stage, path) tuples to output for conflicted
+ files, just provide a list of filenames with conflicts (and
+ do not list filenames multiple times if they have multiple
+ conflicting stages).
+
+--[no-]messages::
+ Write any informational messages such as "Auto-merging <path>"
+ or CONFLICT notices to the end of stdout. If unspecified, the
+ default is to include these messages if there are merge
+ conflicts, and to omit them otherwise.
+
+--allow-unrelated-histories::
+ merge-tree will by default error out if the two branches specified
+ share no common history. This flag can be given to override that
+ check and make the merge proceed anyway.
+
+--merge-base=<tree-ish>::
+ Instead of finding the merge-bases for <branch1> and <branch2>,
+ specify a merge-base for the merge, and specifying multiple bases is
+ currently not supported. This option is incompatible with `--stdin`.
++
+As the merge-base is provided directly, <branch1> and <branch2> do not need
+to specify commits; trees are enough.
+
+-X<option>::
+--strategy-option=<option>::
+ Pass the merge strategy-specific option through to the merge strategy.
+ See linkgit:git-merge[1] for details.
+
+[[OUTPUT]]
+OUTPUT
+------
+
+For a successful merge, the output from git-merge-tree is simply one
+line:
+
+ <OID of toplevel tree>
+
+Whereas for a conflicted merge, the output is by default of the form:
+
+ <OID of toplevel tree>
+ <Conflicted file info>
+ <Informational messages>
+
+These are discussed individually below.
+
+However, there is an exception. If `--stdin` is passed, then there is
+an extra section at the beginning, a NUL character at the end, and then
+all the sections repeat for each line of input. Thus, if the first merge
+is conflicted and the second is clean, the output would be of the form:
+
+ <Merge status>
+ <OID of toplevel tree>
+ <Conflicted file info>
+ <Informational messages>
+ NUL
+ <Merge status>
+ <OID of toplevel tree>
+ NUL
+
+[[MS]]
+Merge status
+~~~~~~~~~~~~
+
+This is an integer status followed by a NUL character. The integer status is:
+
+ 0: merge had conflicts
+ 1: merge was clean
+ <0: something prevented the merge from running (e.g. access to repository
+ objects denied by filesystem)
+
+[[OIDTLT]]
+OID of toplevel tree
+~~~~~~~~~~~~~~~~~~~~
+
+This is a tree object that represents what would be checked out in the
+working tree at the end of `git merge`. If there were conflicts, then
+files within this tree may have embedded conflict markers. This section
+is always followed by a newline (or NUL if `-z` is passed).
+
+[[CFI]]
+Conflicted file info
+~~~~~~~~~~~~~~~~~~~~
+
+This is a sequence of lines with the format
+
+ <mode> <object> <stage> <filename>
+
+The filename will be quoted as explained for the configuration
+variable `core.quotePath` (see linkgit:git-config[1]). However, if
+the `--name-only` option is passed, the mode, object, and stage will
+be omitted. If `-z` is passed, the "lines" are terminated by a NUL
+character instead of a newline character.
+
+[[IM]]
+Informational messages
+~~~~~~~~~~~~~~~~~~~~~~
+
+This section provides informational messages, typically about
+conflicts. The format of the section varies significantly depending
+on whether `-z` is passed.
+
+If `-z` is passed:
+
+The output format is zero or more conflict informational records, each
+of the form:
+
+ <list-of-paths><conflict-type>NUL<conflict-message>NUL
+
+where <list-of-paths> is of the form
+
+ <number-of-paths>NUL<path1>NUL<path2>NUL...<pathN>NUL
+
+and includes paths (or branch names) affected by the conflict or
+informational message in <conflict-message>. Also, <conflict-type> is a
+stable string explaining the type of conflict, such as
+
+ * "Auto-merging"
+ * "CONFLICT (rename/delete)"
+ * "CONFLICT (submodule lacks merge base)"
+ * "CONFLICT (binary)"
+
+and <conflict-message> is a more detailed message about the conflict which often
+(but not always) embeds the <stable-short-type-description> within it. These
+strings may change in future Git versions. Some examples:
+
+ * "Auto-merging <file>"
+ * "CONFLICT (rename/delete): <oldfile> renamed...but deleted in..."
+ * "Failed to merge submodule <submodule> (no merge base)"
+ * "Warning: cannot merge binary files: <filename>"
+
+If `-z` is NOT passed:
+
+This section starts with a blank line to separate it from the previous
+sections, and then only contains the <conflict-message> information
+from the previous section (separated by newlines). These are
+non-stable strings that should not be parsed by scripts, and are just
+meant for human consumption. Also, note that while <conflict-message>
+strings usually do not contain embedded newlines, they sometimes do.
+(However, the free-form messages will never have an embedded NUL
+character). So, the entire block of information is meant for human
+readers as an agglomeration of all conflict messages.
+
+EXIT STATUS
+-----------
+
+For a successful, non-conflicted merge, the exit status is 0. When the
+merge has conflicts, the exit status is 1. If the merge is not able to
+complete (or start) due to some kind of error, the exit status is
+something other than 0 or 1 (and the output is unspecified). When
+--stdin is passed, the return status is 0 for both successful and
+conflicted merges, and something other than 0 or 1 if it cannot complete
+all the requested merges.
+
+USAGE NOTES
+-----------
+
+This command is intended as low-level plumbing, similar to
+linkgit:git-hash-object[1], linkgit:git-mktree[1],
+linkgit:git-commit-tree[1], linkgit:git-write-tree[1],
+linkgit:git-update-ref[1], and linkgit:git-mktag[1]. Thus, it can be
+used as a part of a series of steps such as:
+
+ vi message.txt
+ BRANCH1=refs/heads/test
+ BRANCH2=main
+ NEWTREE=$(git merge-tree --write-tree $BRANCH1 $BRANCH2) || {
+ echo "There were conflicts..." 1>&2
+ exit 1
+ }
+ NEWCOMMIT=$(git commit-tree $NEWTREE -F message.txt \
+ -p $BRANCH1 -p $BRANCH2)
+ git update-ref $BRANCH1 $NEWCOMMIT
+
+Note that when the exit status is non-zero, `NEWTREE` in this sequence
+will contain a lot more output than just a tree.
+
+For conflicts, the output includes the same information that you'd get
+with linkgit:git-merge[1]:
+
+ * what would be written to the working tree (the
+ <<OIDTLT,OID of toplevel tree>>)
+ * the higher order stages that would be written to the index (the
+ <<CFI,Conflicted file info>>)
+ * any messages that would have been printed to stdout (the
+ <<IM,Informational messages>>)
+
+INPUT FORMAT
+------------
+'git merge-tree --stdin' input format is fully text based. Each line
+has this format:
+
+ [<base-commit> -- ]<branch1> <branch2>
+
+If one line is separated by `--`, the string before the separator is
+used for specifying a merge-base for the merge and the string after
+the separator describes the branches to be merged.
+
+MISTAKES TO AVOID
+-----------------
+
+Do NOT look through the resulting toplevel tree to try to find which
+files conflict; parse the <<CFI,Conflicted file info>> section instead.
+Not only would parsing an entire tree be horrendously slow in large
+repositories, there are numerous types of conflicts not representable by
+conflict markers (modify/delete, mode conflict, binary file changed on
+both sides, file/directory conflicts, various rename conflict
+permutations, etc.)
+
+Do NOT interpret an empty <<CFI,Conflicted file info>> list as a clean
+merge; check the exit status. A merge can have conflicts without having
+individual files conflict (there are a few types of directory rename
+conflicts that fall into this category, and others might also be added
+in the future).
+
+Do NOT attempt to guess or make the user guess the conflict types from
+the <<CFI,Conflicted file info>> list. The information there is
+insufficient to do so. For example: Rename/rename(1to2) conflicts (both
+sides renamed the same file differently) will result in three different
+files having higher order stages (but each only has one higher order
+stage), with no way (short of the <<IM,Informational messages>> section)
+to determine which three files are related. File/directory conflicts
+also result in a file with exactly one higher order stage.
+Possibly-involved-in-directory-rename conflicts (when
+"merge.directoryRenames" is unset or set to "conflicts") also result in
+a file with exactly one higher order stage. In all cases, the
+<<IM,Informational messages>> section has the necessary info, though it
+is not designed to be machine parseable.
+
+Do NOT assume that each path from <<CFI,Conflicted file info>>, and
+the logical conflicts in the <<IM,Informational messages>> have a
+one-to-one mapping, nor that there is a one-to-many mapping, nor a
+many-to-one mapping. Many-to-many mappings exist, meaning that each
+path can have many logical conflict types in a single merge, and each
+logical conflict type can affect many paths.
+
+Do NOT assume all filenames listed in the <<IM,Informational messages>>
+section had conflicts. Messages can be included for files that have no
+conflicts, such as "Auto-merging <file>".
+
+AVOID taking the OIDS from the <<CFI,Conflicted file info>> and
+re-merging them to present the conflicts to the user. This will lose
+information. Instead, look up the version of the file found within the
+<<OIDTLT,OID of toplevel tree>> and show that instead. In particular,
+the latter will have conflict markers annotated with the original
+branch/commit being merged and, if renames were involved, the original
+filename. While you could include the original branch/commit in the
+conflict marker annotations when re-merging, the original filename is
+not available from the <<CFI,Conflicted file info>> and thus you would
+be losing information that might help the user resolve the conflict.
+
+[[DEPMERGE]]
+DEPRECATED DESCRIPTION
+----------------------
+
+Per the <<NEWMERGE,DESCRIPTION>> and unlike the rest of this
+documentation, this section describes the deprecated `--trivial-merge`
+mode.
+
+Other than the optional `--trivial-merge`, this mode accepts no
+options.
+
+This mode reads three tree-ish, and outputs trivial merge results and
+conflicting stages to the standard output in a semi-diff format.
+Since this was designed for higher level scripts to consume and merge
+the results back into the index, it omits entries that match
+<branch1>. The result of this second form is similar to what
+three-way 'git read-tree -m' does, but instead of storing the results
+in the index, the command outputs the entries to the standard output.
+
+This form not only has limited applicability (a trivial merge cannot
+handle content merges of individual files, rename detection, proper
+directory/file conflict handling, etc.), the output format is also
+difficult to work with, and it will generally be less performant than
+the first form even on successful merges (especially if working in
+large repositories).
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-merge.adoc b/git-merge.adoc
new file mode 100644
index 0000000..64281d6
--- /dev/null
+++ b/git-merge.adoc
@@ -0,0 +1,413 @@
+git-merge(1)
+============
+
+NAME
+----
+git-merge - Join two or more development histories together
+
+
+SYNOPSIS
+--------
+[verse]
+'git merge' [-n] [--stat] [--no-commit] [--squash] [--[no-]edit]
+ [--no-verify] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]]
+ [--[no-]allow-unrelated-histories]
+ [--[no-]rerere-autoupdate] [-m <msg>] [-F <file>]
+ [--into-name <branch>] [<commit>...]
+'git merge' (--continue | --abort | --quit)
+
+DESCRIPTION
+-----------
+Incorporates changes from the named commits (since the time their
+histories diverged from the current branch) into the current
+branch. This command is used by `git pull` to incorporate changes
+from another repository and can be used by hand to merge changes
+from one branch into another.
+
+Assume the following history exists and the current branch is
+`master`:
+
+------------
+ A---B---C topic
+ /
+ D---E---F---G master
+------------
+
+Then `git merge topic` will replay the changes made on the
+`topic` branch since it diverged from `master` (i.e., `E`) until
+its current commit (`C`) on top of `master`, and record the result
+in a new commit along with the names of the two parent commits and
+a log message from the user describing the changes. Before the operation,
+`ORIG_HEAD` is set to the tip of the current branch (`C`).
+
+------------
+ A---B---C topic
+ / \
+ D---E---F---G---H master
+------------
+
+A merge stops if there's a conflict that cannot be resolved
+automatically or if `--no-commit` was provided when initiating the
+merge. At that point you can run `git merge --abort` or `git merge
+--continue`.
+
+`git merge --abort` will abort the merge process and try to reconstruct
+the pre-merge state. However, if there were uncommitted changes when the
+merge started (and especially if those changes were further modified
+after the merge was started), `git merge --abort` will in some cases be
+unable to reconstruct the original (pre-merge) changes. Therefore:
+
+*Warning*: Running `git merge` with non-trivial uncommitted changes is
+discouraged: while possible, it may leave you in a state that is hard to
+back out of in the case of a conflict.
+
+OPTIONS
+-------
+:git-merge: 1
+
+include::merge-options.adoc[]
+
+-m <msg>::
+ Set the commit message to be used for the merge commit (in
+ case one is created).
++
+If `--log` is specified, a shortlog of the commits being merged
+will be appended to the specified message.
++
+The `git fmt-merge-msg` command can be
+used to give a good default for automated `git merge`
+invocations. The automated message can include the branch description.
+
+--into-name <branch>::
+ Prepare the default merge message as if merging to the branch
+ `<branch>`, instead of the name of the real branch to which
+ the merge is made.
+
+-F <file>::
+--file=<file>::
+ Read the commit message to be used for the merge commit (in
+ case one is created).
++
+If `--log` is specified, a shortlog of the commits being merged
+will be appended to the specified message.
+
+include::rerere-options.adoc[]
+
+--overwrite-ignore::
+--no-overwrite-ignore::
+ Silently overwrite ignored files from the merge result. This
+ is the default behavior. Use `--no-overwrite-ignore` to abort.
+
+--abort::
+ Abort the current conflict resolution process, and
+ try to reconstruct the pre-merge state. If an autostash entry is
+ present, apply it to the worktree.
++
+If there were uncommitted worktree changes present when the merge
+started, `git merge --abort` will in some cases be unable to
+reconstruct these changes. It is therefore recommended to always
+commit or stash your changes before running `git merge`.
++
+`git merge --abort` is equivalent to `git reset --merge` when
+`MERGE_HEAD` is present unless `MERGE_AUTOSTASH` is also present in
+which case `git merge --abort` applies the stash entry to the worktree
+whereas `git reset --merge` will save the stashed changes in the stash
+list.
+
+--quit::
+ Forget about the current merge in progress. Leave the index
+ and the working tree as-is. If `MERGE_AUTOSTASH` is present, the
+ stash entry will be saved to the stash list.
+
+--continue::
+ After a `git merge` stops due to conflicts you can conclude the
+ merge by running `git merge --continue` (see "HOW TO RESOLVE
+ CONFLICTS" section below).
+
+<commit>...::
+ Commits, usually other branch heads, to merge into our branch.
+ Specifying more than one commit will create a merge with
+ more than two parents (affectionately called an Octopus merge).
++
+If no commit is given from the command line, merge the remote-tracking
+branches that the current branch is configured to use as its upstream.
+See also the configuration section of this manual page.
++
+When `FETCH_HEAD` (and no other commit) is specified, the branches
+recorded in the `.git/FETCH_HEAD` file by the previous invocation
+of `git fetch` for merging are merged to the current branch.
+
+
+PRE-MERGE CHECKS
+----------------
+
+Before applying outside changes, you should get your own work in
+good shape and committed locally, so it will not be clobbered if
+there are conflicts. See also linkgit:git-stash[1].
+`git pull` and `git merge` will stop without doing anything when
+local uncommitted changes overlap with files that `git pull`/`git
+merge` may need to update.
+
+To avoid recording unrelated changes in the merge commit,
+`git pull` and `git merge` will also abort if there are any changes
+registered in the index relative to the `HEAD` commit. (Special
+narrow exceptions to this rule may exist depending on which merge
+strategy is in use, but generally, the index must match HEAD.)
+
+If all named commits are already ancestors of `HEAD`, `git merge`
+will exit early with the message "Already up to date."
+
+FAST-FORWARD MERGE
+------------------
+
+Often the current branch head is an ancestor of the named commit.
+This is the most common case especially when invoked from `git
+pull`: you are tracking an upstream repository, you have committed
+no local changes, and now you want to update to a newer upstream
+revision. In this case, a new commit is not needed to store the
+combined history; instead, the `HEAD` (along with the index) is
+updated to point at the named commit, without creating an extra
+merge commit.
+
+This behavior can be suppressed with the `--no-ff` option.
+
+TRUE MERGE
+----------
+
+Except in a fast-forward merge (see above), the branches to be
+merged must be tied together by a merge commit that has both of them
+as its parents.
+
+A merged version reconciling the changes from all branches to be
+merged is committed, and your `HEAD`, index, and working tree are
+updated to it. It is possible to have modifications in the working
+tree as long as they do not overlap; the update will preserve them.
+
+When it is not obvious how to reconcile the changes, the following
+happens:
+
+1. The `HEAD` pointer stays the same.
+2. The `MERGE_HEAD` ref is set to point to the other branch head.
+3. Paths that merged cleanly are updated both in the index file and
+ in your working tree.
+4. For conflicting paths, the index file records up to three
+ versions: stage 1 stores the version from the common ancestor,
+ stage 2 from `HEAD`, and stage 3 from `MERGE_HEAD` (you
+ can inspect the stages with `git ls-files -u`). The working
+ tree files contain the result of the merge operation; i.e. 3-way
+ merge results with familiar conflict markers `<<<` `===` `>>>`.
+5. A ref named `AUTO_MERGE` is written, pointing to a tree
+ corresponding to the current content of the working tree (including
+ conflict markers for textual conflicts). Note that this ref is only
+ written when the 'ort' merge strategy is used (the default).
+6. No other changes are made. In particular, the local
+ modifications you had before you started merge will stay the
+ same and the index entries for them stay as they were,
+ i.e. matching `HEAD`.
+
+If you tried a merge which resulted in complex conflicts and
+want to start over, you can recover with `git merge --abort`.
+
+MERGING TAG
+-----------
+
+When merging an annotated (and possibly signed) tag, Git always
+creates a merge commit even if a fast-forward merge is possible, and
+the commit message template is prepared with the tag message.
+Additionally, if the tag is signed, the signature check is reported
+as a comment in the message template. See also linkgit:git-tag[1].
+
+When you want to just integrate with the work leading to the commit
+that happens to be tagged, e.g. synchronizing with an upstream
+release point, you may not want to make an unnecessary merge commit.
+
+In such a case, you can "unwrap" the tag yourself before feeding it
+to `git merge`, or pass `--ff-only` when you do not have any work on
+your own. e.g.
+
+----
+git fetch origin
+git merge v1.2.3^0
+git merge --ff-only v1.2.3
+----
+
+
+HOW CONFLICTS ARE PRESENTED
+---------------------------
+
+During a merge, the working tree files are updated to reflect the result
+of the merge. Among the changes made to the common ancestor's version,
+non-overlapping ones (that is, you changed an area of the file while the
+other side left that area intact, or vice versa) are incorporated in the
+final result verbatim. When both sides made changes to the same area,
+however, Git cannot randomly pick one side over the other, and asks you to
+resolve it by leaving what both sides did to that area.
+
+By default, Git uses the same style as the one used by the "merge" program
+from the RCS suite to present such a conflicted hunk, like this:
+
+------------
+Here are lines that are either unchanged from the common
+ancestor, or cleanly resolved because only one side changed,
+or cleanly resolved because both sides changed the same way.
+<<<<<<< yours:sample.txt
+Conflict resolution is hard;
+let's go shopping.
+=======
+Git makes conflict resolution easy.
+>>>>>>> theirs:sample.txt
+And here is another line that is cleanly resolved or unmodified.
+------------
+
+The area where a pair of conflicting changes happened is marked with markers
+`<<<<<<<`, `=======`, and `>>>>>>>`. The part before the `=======`
+is typically your side, and the part afterwards is typically their side.
+
+The default format does not show what the original said in the conflicting
+area. You cannot tell how many lines are deleted and replaced with
+Barbie's remark on your side. The only thing you can tell is that your
+side wants to say it is hard and you'd prefer to go shopping, while the
+other side wants to claim it is easy.
+
+An alternative style can be used by setting the `merge.conflictStyle`
+configuration variable to either "diff3" or "zdiff3". In "diff3"
+style, the above conflict may look like this:
+
+------------
+Here are lines that are either unchanged from the common
+ancestor, or cleanly resolved because only one side changed,
+<<<<<<< yours:sample.txt
+or cleanly resolved because both sides changed the same way.
+Conflict resolution is hard;
+let's go shopping.
+||||||| base:sample.txt
+or cleanly resolved because both sides changed identically.
+Conflict resolution is hard.
+=======
+or cleanly resolved because both sides changed the same way.
+Git makes conflict resolution easy.
+>>>>>>> theirs:sample.txt
+And here is another line that is cleanly resolved or unmodified.
+------------
+
+while in "zdiff3" style, it may look like this:
+
+------------
+Here are lines that are either unchanged from the common
+ancestor, or cleanly resolved because only one side changed,
+or cleanly resolved because both sides changed the same way.
+<<<<<<< yours:sample.txt
+Conflict resolution is hard;
+let's go shopping.
+||||||| base:sample.txt
+or cleanly resolved because both sides changed identically.
+Conflict resolution is hard.
+=======
+Git makes conflict resolution easy.
+>>>>>>> theirs:sample.txt
+And here is another line that is cleanly resolved or unmodified.
+------------
+
+In addition to the `<<<<<<<`, `=======`, and `>>>>>>>` markers, it uses
+another `|||||||` marker that is followed by the original text. You can
+tell that the original just stated a fact, and your side simply gave in to
+that statement and gave up, while the other side tried to have a more
+positive attitude. You can sometimes come up with a better resolution by
+viewing the original.
+
+
+HOW TO RESOLVE CONFLICTS
+------------------------
+
+After seeing a conflict, you can do two things:
+
+ * Decide not to merge. The only clean-ups you need are to reset
+ the index file to the `HEAD` commit to reverse 2. and to clean
+ up working tree changes made by 2. and 3.; `git merge --abort`
+ can be used for this.
+
+ * Resolve the conflicts. Git will mark the conflicts in
+ the working tree. Edit the files into shape and
+ `git add` them to the index. Use `git commit` or
+ `git merge --continue` to seal the deal. The latter command
+ checks whether there is a (interrupted) merge in progress
+ before calling `git commit`.
+
+You can work through the conflict with a number of tools:
+
+ * Use a mergetool. `git mergetool` to launch a graphical
+ mergetool which will work through the merge with you.
+
+ * Look at the diffs. `git diff` will show a three-way diff,
+ highlighting changes from both the `HEAD` and `MERGE_HEAD`
+ versions. `git diff AUTO_MERGE` will show what changes you've
+ made so far to resolve textual conflicts.
+
+ * Look at the diffs from each branch. `git log --merge -p <path>`
+ will show diffs first for the `HEAD` version and then the
+ `MERGE_HEAD` version.
+
+ * Look at the originals. `git show :1:filename` shows the
+ common ancestor, `git show :2:filename` shows the `HEAD`
+ version, and `git show :3:filename` shows the `MERGE_HEAD`
+ version.
+
+
+EXAMPLES
+--------
+
+* Merge branches `fixes` and `enhancements` on top of
+ the current branch, making an octopus merge:
++
+------------------------------------------------
+$ git merge fixes enhancements
+------------------------------------------------
+
+* Merge branch `obsolete` into the current branch, using `ours`
+ merge strategy:
++
+------------------------------------------------
+$ git merge -s ours obsolete
+------------------------------------------------
+
+* Merge branch `maint` into the current branch, but do not make
+ a new commit automatically:
++
+------------------------------------------------
+$ git merge --no-commit maint
+------------------------------------------------
++
+This can be used when you want to include further changes to the
+merge, or want to write your own merge commit message.
++
+You should refrain from abusing this option to sneak substantial
+changes into a merge commit. Small fixups like bumping
+release/version name would be acceptable.
+
+
+include::merge-strategies.adoc[]
+
+CONFIGURATION
+-------------
+
+branch.<name>.mergeOptions::
+ Sets default options for merging into branch <name>. The syntax and
+ supported options are the same as those of `git merge`, but option
+ values containing whitespace characters are currently not supported.
+
+include::includes/cmd-config-section-rest.adoc[]
+
+include::config/merge.adoc[]
+
+SEE ALSO
+--------
+linkgit:git-fmt-merge-msg[1], linkgit:git-pull[1],
+linkgit:gitattributes[5],
+linkgit:git-reset[1],
+linkgit:git-diff[1], linkgit:git-ls-files[1],
+linkgit:git-add[1], linkgit:git-rm[1],
+linkgit:git-mergetool[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-mergetool--lib.adoc b/git-mergetool--lib.adoc
new file mode 100644
index 0000000..0726b56
--- /dev/null
+++ b/git-mergetool--lib.adoc
@@ -0,0 +1,53 @@
+git-mergetool{litdd}lib(1)
+==========================
+
+NAME
+----
+git-mergetool--lib - Common Git merge tool shell scriptlets
+
+SYNOPSIS
+--------
+[verse]
+'TOOL_MODE=(diff|merge) . "$(git --exec-path)/git-mergetool{litdd}lib"'
+
+DESCRIPTION
+-----------
+
+This is not a command the end user would want to run. Ever.
+This documentation is meant for people who are studying the
+Porcelain-ish scripts and/or are writing new ones.
+
+The 'git-mergetool{litdd}lib' scriptlet is designed to be sourced (using
+`.`) by other shell scripts to set up functions for working
+with Git merge tools.
+
+Before sourcing 'git-mergetool{litdd}lib', your script must set `TOOL_MODE`
+to define the operation mode for the functions listed below.
+'diff' and 'merge' are valid values.
+
+FUNCTIONS
+---------
+get_merge_tool::
+ Returns a merge tool. The return code is 1 if we returned a guessed
+ merge tool, else 0. '$GIT_MERGETOOL_GUI' may be set to 'true' to
+ search for the appropriate guitool.
+
+get_merge_tool_cmd::
+ Returns the custom command for a merge tool.
+
+get_merge_tool_path::
+ Returns the custom path for a merge tool.
+
+initialize_merge_tool::
+ Brings merge tool specific functions into scope so they can be used or
+ overridden.
+
+run_merge_tool::
+ Launches a merge tool given the tool name and a true/false
+ flag to indicate whether a merge base is present.
+ '$MERGED', '$LOCAL', '$REMOTE', and '$BASE' must be defined
+ for use by the merge tool.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-mergetool.adoc b/git-mergetool.adoc
new file mode 100644
index 0000000..046c325
--- /dev/null
+++ b/git-mergetool.adoc
@@ -0,0 +1,130 @@
+git-mergetool(1)
+================
+
+NAME
+----
+git-mergetool - Run merge conflict resolution tools to resolve merge conflicts
+
+SYNOPSIS
+--------
+[verse]
+'git mergetool' [--tool=<tool>] [-y | --[no-]prompt] [<file>...]
+
+DESCRIPTION
+-----------
+
+Use `git mergetool` to run one of several merge utilities to resolve
+merge conflicts. It is typically run after 'git merge'.
+
+If one or more <file> parameters are given, the merge tool program will
+be run to resolve differences in each file (skipping those without
+conflicts). Specifying a directory will include all unresolved files in
+that path. If no <file> names are specified, 'git mergetool' will run
+the merge tool program on every file with merge conflicts.
+
+OPTIONS
+-------
+-t <tool>::
+--tool=<tool>::
+ Use the merge resolution program specified by <tool>.
+ Valid values include emerge, gvimdiff, kdiff3,
+ meld, vimdiff, and tortoisemerge. Run `git mergetool --tool-help`
+ for the list of valid <tool> settings.
++
+If a merge resolution program is not specified, 'git mergetool'
+will use the configuration variable `merge.tool`. If the
+configuration variable `merge.tool` is not set, 'git mergetool'
+will pick a suitable default.
++
+You can explicitly provide a full path to the tool by setting the
+configuration variable `mergetool.<tool>.path`. For example, you
+can configure the absolute path to kdiff3 by setting
+`mergetool.kdiff3.path`. Otherwise, 'git mergetool' assumes the
+tool is available in PATH.
++
+Instead of running one of the known merge tool programs,
+'git mergetool' can be customized to run an alternative program
+by specifying the command line to invoke in a configuration
+variable `mergetool.<tool>.cmd`.
++
+When 'git mergetool' is invoked with this tool (either through the
+`-t` or `--tool` option or the `merge.tool` configuration
+variable), the configured command line will be invoked with `$BASE`
+set to the name of a temporary file containing the common base for
+the merge, if available; `$LOCAL` set to the name of a temporary
+file containing the contents of the file on the current branch;
+`$REMOTE` set to the name of a temporary file containing the
+contents of the file to be merged, and `$MERGED` set to the name
+of the file to which the merge tool should write the result of the
+merge resolution.
++
+If the custom merge tool correctly indicates the success of a
+merge resolution with its exit code, then the configuration
+variable `mergetool.<tool>.trustExitCode` can be set to `true`.
+Otherwise, 'git mergetool' will prompt the user to indicate the
+success of the resolution after the custom tool has exited.
+
+--tool-help::
+ Print a list of merge tools that may be used with `--tool`.
+
+-y::
+--no-prompt::
+ Don't prompt before each invocation of the merge resolution
+ program.
+ This is the default if the merge resolution program is
+ explicitly specified with the `--tool` option or with the
+ `merge.tool` configuration variable.
+
+--prompt::
+ Prompt before each invocation of the merge resolution program
+ to give the user a chance to skip the path.
+
+-g::
+--gui::
+ When 'git-mergetool' is invoked with the `-g` or `--gui` option,
+ the default merge tool will be read from the configured
+ `merge.guitool` variable instead of `merge.tool`. If
+ `merge.guitool` is not set, we will fallback to the tool
+ configured under `merge.tool`. This may be autoselected using
+ the configuration variable `mergetool.guiDefault`.
+
+--no-gui::
+ This overrides a previous `-g` or `--gui` setting or
+ `mergetool.guiDefault` configuration and reads the default merge
+ tool from the configured `merge.tool` variable.
+
+-O<orderfile>::
+ Process files in the order specified in the
+ <orderfile>, which has one shell glob pattern per line.
+ This overrides the `diff.orderFile` configuration variable
+ (see linkgit:git-config[1]). To cancel `diff.orderFile`,
+ use `-O/dev/null`.
+
+CONFIGURATION
+-------------
+:git-mergetool: 1
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/mergetool.adoc[]
+
+TEMPORARY FILES
+---------------
+`git mergetool` creates `*.orig` backup files while resolving merges.
+These are safe to remove once a file has been merged and its
+`git mergetool` session has completed.
+
+Setting the `mergetool.keepBackup` configuration variable to `false`
+causes `git mergetool` to automatically remove the backup files as files
+are successfully merged.
+
+BACKEND SPECIFIC HINTS
+----------------------
+
+vimdiff
+~~~~~~~
+include::mergetools/vimdiff.adoc[]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-mktag.adoc b/git-mktag.adoc
new file mode 100644
index 0000000..006d759
--- /dev/null
+++ b/git-mktag.adoc
@@ -0,0 +1,66 @@
+git-mktag(1)
+============
+
+NAME
+----
+git-mktag - Creates a tag object with extra validation
+
+
+SYNOPSIS
+--------
+[verse]
+'git mktag'
+
+DESCRIPTION
+-----------
+
+Reads a tag's contents on standard input and creates a tag object. The
+output is the new tag's <object> identifier.
+
+This command is mostly equivalent to linkgit:git-hash-object[1]
+invoked with `-t tag -w --stdin`. I.e. both of these will create and
+write a tag found in `my-tag`:
+
+ git mktag <my-tag
+ git hash-object -t tag -w --stdin <my-tag
+
+The difference is that mktag will die before writing the tag if the
+tag doesn't pass a linkgit:git-fsck[1] check.
+
+The "fsck" check done by mktag is stricter than what linkgit:git-fsck[1]
+would run by default in that all `fsck.<msg-id>` messages are promoted
+from warnings to errors (so e.g. a missing "tagger" line is an error).
+
+Extra headers in the object are also an error under mktag, but ignored
+by linkgit:git-fsck[1]. This extra check can be turned off by setting
+the appropriate `fsck.<msg-id>` variable:
+
+ git -c fsck.extraHeaderEntry=ignore mktag <my-tag-with-headers
+
+OPTIONS
+-------
+
+--strict::
+ By default mktag turns on the equivalent of
+ linkgit:git-fsck[1] `--strict` mode. Use `--no-strict` to
+ disable it.
+
+Tag Format
+----------
+A tag signature file, to be fed to this command's standard input,
+has a very simple fixed format: four lines of
+
+ object <hash>
+ type <typename>
+ tag <tagname>
+ tagger <tagger>
+
+followed by some 'optional' free-form message (some tags created
+by older Git may not have a `tagger` line). The message, when it
+exists, is separated by a blank line from the header. The
+message part may contain a signature that Git itself doesn't
+care about, but that can be verified with gpg.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-mktree.adoc b/git-mktree.adoc
new file mode 100644
index 0000000..383f09d
--- /dev/null
+++ b/git-mktree.adoc
@@ -0,0 +1,40 @@
+git-mktree(1)
+=============
+
+NAME
+----
+git-mktree - Build a tree-object from ls-tree formatted text
+
+
+SYNOPSIS
+--------
+[verse]
+'git mktree' [-z] [--missing] [--batch]
+
+DESCRIPTION
+-----------
+Reads standard input in non-recursive `ls-tree` output format, and creates
+a tree object. The order of the tree entries is normalized by mktree so
+pre-sorting the input is not required. The object name of the tree object
+built is written to the standard output.
+
+OPTIONS
+-------
+-z::
+ Read the NUL-terminated `ls-tree -z` output instead.
+
+--missing::
+ Allow missing objects. The default behaviour (without this option)
+ is to verify that each tree entry's hash identifies an existing
+ object. This option has no effect on the treatment of gitlink entries
+ (aka "submodules") which are always allowed to be missing.
+
+--batch::
+ Allow building of more than one tree object before exiting. Each
+ tree is separated by a single blank line. The final newline is
+ optional. Note - if the `-z` option is used, lines are terminated
+ with NUL.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-multi-pack-index.adoc b/git-multi-pack-index.adoc
new file mode 100644
index 0000000..631d5c7
--- /dev/null
+++ b/git-multi-pack-index.adoc
@@ -0,0 +1,147 @@
+git-multi-pack-index(1)
+=======================
+
+NAME
+----
+git-multi-pack-index - Write and verify multi-pack-indexes
+
+
+SYNOPSIS
+--------
+[verse]
+'git multi-pack-index' [--object-dir=<dir>] [--[no-]bitmap] <sub-command>
+
+DESCRIPTION
+-----------
+Write or verify a multi-pack-index (MIDX) file.
+
+OPTIONS
+-------
+
+--object-dir=<dir>::
+ Use given directory for the location of Git objects. We check
+ `<dir>/packs/multi-pack-index` for the current MIDX file, and
+ `<dir>/packs` for the pack-files to index.
++
+`<dir>` must be an alternate of the current repository.
+
+--[no-]progress::
+ Turn progress on/off explicitly. If neither is specified, progress is
+ shown if standard error is connected to a terminal. Supported by
+ sub-commands `write`, `verify`, `expire`, and `repack.
+
+The following subcommands are available:
+
+write::
+ Write a new MIDX file. The following options are available for
+ the `write` sub-command:
++
+--
+ --preferred-pack=<pack>::
+ Optionally specify the tie-breaking pack used when
+ multiple packs contain the same object. `<pack>` must
+ contain at least one object. If not given, ties are
+ broken in favor of the pack with the lowest mtime.
+
+ --[no-]bitmap::
+ Control whether or not a multi-pack bitmap is written.
+
+ --stdin-packs::
+ Write a multi-pack index containing only the set of
+ line-delimited pack index basenames provided over stdin.
+
+ --refs-snapshot=<path>::
+ With `--bitmap`, optionally specify a file which
+ contains a "refs snapshot" taken prior to repacking.
++
+A reference snapshot is composed of line-delimited OIDs corresponding to
+the reference tips, usually taken by `git repack` prior to generating a
+new pack. A line may optionally start with a `+` character to indicate
+that the reference which corresponds to that OID is "preferred" (see
+linkgit:git-config[1]'s `pack.preferBitmapTips`.)
++
+The file given at `<path>` is expected to be readable, and can contain
+duplicates. (If a given OID is given more than once, it is marked as
+preferred if at least one instance of it begins with the special `+`
+marker).
+
+ --incremental::
+ Write an incremental MIDX file containing only objects
+ and packs not present in an existing MIDX layer.
+ Migrates non-incremental MIDXs to incremental ones when
+ necessary. Incompatible with `--bitmap`.
+--
+
+verify::
+ Verify the contents of the MIDX file.
+
+expire::
+ Delete the pack-files that are tracked by the MIDX file, but
+ have no objects referenced by the MIDX (with the exception of
+ `.keep` packs and cruft packs). Rewrite the MIDX file afterward
+ to remove all references to these pack-files.
++
+NOTE: this mode is incompatible with incremental MIDX files.
+
+repack::
+ Create a new pack-file containing objects in small pack-files
+ referenced by the multi-pack-index. If the size given by the
+ `--batch-size=<size>` argument is zero, then create a pack
+ containing all objects referenced by the multi-pack-index. For
+ a non-zero batch size, Select the pack-files by examining packs
+ from oldest-to-newest, computing the "expected size" by counting
+ the number of objects in the pack referenced by the
+ multi-pack-index, then divide by the total number of objects in
+ the pack and multiply by the pack size. We select packs with
+ expected size below the batch size until the set of packs have
+ total expected size at least the batch size, or all pack-files
+ are considered. If only one pack-file is selected, then do
+ nothing. If a new pack-file is created, rewrite the
+ multi-pack-index to reference the new pack-file. A later run of
+ 'git multi-pack-index expire' will delete the pack-files that
+ were part of this batch.
++
+If `repack.packKeptObjects` is `false`, then any pack-files with an
+associated `.keep` file will not be selected for the batch to repack.
++
+NOTE: this mode is incompatible with incremental MIDX files.
+
+EXAMPLES
+--------
+
+* Write a MIDX file for the packfiles in the current `.git` directory.
++
+-----------------------------------------------
+$ git multi-pack-index write
+-----------------------------------------------
+
+* Write a MIDX file for the packfiles in the current `.git` directory with a
+corresponding bitmap.
++
+-------------------------------------------------------------
+$ git multi-pack-index write --preferred-pack=<pack> --bitmap
+-------------------------------------------------------------
+
+* Write a MIDX file for the packfiles in an alternate object store.
++
+-----------------------------------------------
+$ git multi-pack-index --object-dir <alt> write
+-----------------------------------------------
+
+* Verify the MIDX file for the packfiles in the current `.git` directory.
++
+-----------------------------------------------
+$ git multi-pack-index verify
+-----------------------------------------------
+
+
+SEE ALSO
+--------
+See link:technical/multi-pack-index.html[The Multi-Pack-Index Design
+Document] and linkgit:gitformat-pack[5] for more information on the
+multi-pack-index feature and its file format.
+
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-mv.adoc b/git-mv.adoc
new file mode 100644
index 0000000..dc1bf61
--- /dev/null
+++ b/git-mv.adoc
@@ -0,0 +1,69 @@
+git-mv(1)
+=========
+
+NAME
+----
+git-mv - Move or rename a file, a directory, or a symlink
+
+
+SYNOPSIS
+--------
+[verse]
+'git mv' [<options>] <source>... <destination>
+
+DESCRIPTION
+-----------
+Move or rename a file, directory, or symlink.
+
+ git mv [-v] [-f] [-n] [-k] <source> <destination>
+ git mv [-v] [-f] [-n] [-k] <source> ... <destination-directory>
+
+In the first form, it renames <source>, which must exist and be either
+a file, symlink or directory, to <destination>.
+In the second form, the last argument has to be an existing
+directory; the given sources will be moved into this directory.
+
+The index is updated after successful completion, but the change must still be
+committed.
+
+OPTIONS
+-------
+-f::
+--force::
+ Force renaming or moving of a file even if the <destination> exists.
+-k::
+ Skip move or rename actions which would lead to an error
+ condition. An error happens when a source is neither existing nor
+ controlled by Git, or when it would overwrite an existing
+ file unless `-f` is given.
+-n::
+--dry-run::
+ Do nothing; only show what would happen
+
+-v::
+--verbose::
+ Report the names of files as they are moved.
+
+SUBMODULES
+----------
+Moving a submodule using a gitfile (which means they were cloned
+with a Git version 1.7.8 or newer) will update the gitfile and
+core.worktree setting to make the submodule work in the new location.
+It also will attempt to update the submodule.<name>.path setting in
+the linkgit:gitmodules[5] file and stage that file (unless -n is used).
+
+BUGS
+----
+Each time a superproject update moves a populated submodule (e.g. when
+switching between commits before and after the move) a stale submodule
+checkout will remain in the old location and an empty directory will
+appear in the new location. To populate the submodule again in the new
+location the user will have to run "git submodule update"
+afterwards. Removing the old directory is only safe when it uses a
+gitfile, as otherwise the history of the submodule will be deleted
+too. Both steps will be obsolete when recursive submodule update has
+been implemented.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-name-rev.adoc b/git-name-rev.adoc
new file mode 100644
index 0000000..d4f1c4d
--- /dev/null
+++ b/git-name-rev.adoc
@@ -0,0 +1,112 @@
+git-name-rev(1)
+===============
+
+NAME
+----
+git-name-rev - Find symbolic names for given revs
+
+
+SYNOPSIS
+--------
+[verse]
+'git name-rev' [--tags] [--refs=<pattern>]
+ ( --all | --annotate-stdin | <commit-ish>... )
+
+DESCRIPTION
+-----------
+Finds symbolic names suitable for human digestion for revisions given in any
+format parsable by 'git rev-parse'.
+
+
+OPTIONS
+-------
+
+--tags::
+ Do not use branch names, but only tags to name the commits
+
+--refs=<pattern>::
+ Only use refs whose names match a given shell pattern. The pattern
+ can be a branch name, a tag name, or a fully qualified ref name. If
+ given multiple times, use refs whose names match any of the given shell
+ patterns. Use `--no-refs` to clear any previous ref patterns given.
+
+--exclude=<pattern>::
+ Do not use any ref whose name matches a given shell pattern. The
+ pattern can be one of branch name, tag name or fully qualified ref
+ name. If given multiple times, a ref will be excluded when it matches
+ any of the given patterns. When used together with --refs, a ref will
+ be used as a match only when it matches at least one --refs pattern and
+ does not match any --exclude patterns. Use `--no-exclude` to clear the
+ list of exclude patterns.
+
+--all::
+ List all commits reachable from all refs
+
+--annotate-stdin::
+ Transform stdin by substituting all the 40-character SHA-1
+ hexes (say $hex) with "$hex ($rev_name)". When used with
+ --name-only, substitute with "$rev_name", omitting $hex
+ altogether. This option was called `--stdin` in older versions
+ of Git.
++
+For example:
++
+-----------
+$ cat sample.txt
+
+An abbreviated revision 2ae0a9cb82 will not be substituted.
+The full name after substitution is 2ae0a9cb8298185a94e5998086f380a355dd8907,
+while its tree object is 70d105cc79e63b81cfdcb08a15297c23e60b07ad
+
+$ git name-rev --annotate-stdin <sample.txt
+
+An abbreviated revision 2ae0a9cb82 will not be substituted.
+The full name after substitution is 2ae0a9cb8298185a94e5998086f380a355dd8907 (master),
+while its tree object is 70d105cc79e63b81cfdcb08a15297c23e60b07ad
+
+$ git name-rev --name-only --annotate-stdin <sample.txt
+
+An abbreviated revision 2ae0a9cb82 will not be substituted.
+The full name after substitution is master,
+while its tree object is 70d105cc79e63b81cfdcb08a15297c23e60b07ad
+-----------
+
+--name-only::
+ Instead of printing both the SHA-1 and the name, print only
+ the name. If given with --tags the usual tag prefix of
+ "tags/" is also omitted from the name, matching the output
+ of `git-describe` more closely.
+
+--no-undefined::
+ Die with error code != 0 when a reference is undefined,
+ instead of printing `undefined`.
+
+--always::
+ Show uniquely abbreviated commit object as fallback.
+
+EXAMPLES
+--------
+
+Given a commit, find out where it is relative to the local refs. Say somebody
+wrote you about that fantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a.
+Of course, you look into the commit, but that only tells you what happened, but
+not the context.
+
+Enter 'git name-rev':
+
+------------
+% git name-rev 33db5f4d9027a10e477ccf054b2c1ab94f74c85a
+33db5f4d9027a10e477ccf054b2c1ab94f74c85a tags/v0.99~940
+------------
+
+Now you are wiser, because you know that it happened 940 revisions before v0.99.
+
+Another nice thing you can do is:
+
+------------
+% git log | git name-rev --annotate-stdin
+------------
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-notes.adoc b/git-notes.adoc
new file mode 100644
index 0000000..bcfe3da
--- /dev/null
+++ b/git-notes.adoc
@@ -0,0 +1,387 @@
+git-notes(1)
+============
+
+NAME
+----
+git-notes - Add or inspect object notes
+
+SYNOPSIS
+--------
+[synopsis]
+git notes [list [<object>]]
+git notes add [-f] [--allow-empty] [--[no-]separator | --separator=<paragraph-break>] [--[no-]stripspace] [-F <file> | -m <msg> | (-c | -C) <object>] [-e] [<object>]
+git notes copy [-f] ( --stdin | <from-object> [<to-object>] )
+git notes append [--allow-empty] [--[no-]separator | --separator=<paragraph-break>] [--[no-]stripspace] [-F <file> | -m <msg> | (-c | -C) <object>] [-e] [<object>]
+git notes edit [--allow-empty] [<object>] [--[no-]stripspace]
+git notes show [<object>]
+git notes merge [-v | -q] [-s <strategy> ] <notes-ref>
+git notes merge --commit [-v | -q]
+git notes merge --abort [-v | -q]
+git notes remove [--ignore-missing] [--stdin] [<object>...]
+git notes prune [-n] [-v]
+git notes get-ref
+
+
+DESCRIPTION
+-----------
+Adds, removes, or reads notes attached to objects, without touching
+the objects themselves.
+
+By default, notes are saved to and read from `refs/notes/commits`, but
+this default can be overridden. See the OPTIONS, CONFIGURATION, and
+ENVIRONMENT sections below. If this ref does not exist, it will be
+quietly created when it is first needed to store a note.
+
+A typical use of notes is to supplement a commit message without
+changing the commit itself. Notes can be shown by `git log` along with
+the original commit message. To distinguish these notes from the
+message stored in the commit object, the notes are indented like the
+message, after an unindented line saying "Notes (_<refname>_):" (or
+"Notes:" for `refs/notes/commits`).
+
+Notes can also be added to patches prepared with `git format-patch` by
+using the `--notes` option. Such notes are added as a patch commentary
+after a three dash separator line.
+
+To change which notes are shown by `git log`, see the
+`notes.displayRef` discussion in <<CONFIGURATION,CONFIGURATION>>.
+
+See the `notes.rewrite.<command>` configuration for a way to carry
+notes across commands that rewrite commits.
+
+
+SUBCOMMANDS
+-----------
+
+`list`::
+ List the notes object for a given object. If no object is
+ given, show a list of all note objects and the objects they
+ annotate (in the format "`<note-object> <annotated-object>`").
+ This is the default subcommand if no subcommand is given.
+
+`add`::
+ Add notes for a given object (defaults to `HEAD`). Abort if the
+ object already has notes (use `-f` to overwrite existing notes).
+ However, if you're using `add` interactively (using an editor
+ to supply the notes contents), then - instead of aborting -
+ the existing notes will be opened in the editor (like the `edit`
+ subcommand). If you specify multiple `-m` and `-F`, a blank
+ line will be inserted between the messages. Use the `--separator`
+ option to insert other delimiters. You can use `-e` to edit and
+ fine-tune the message(s) supplied from `-m` and `-F` options
+ interactively (using an editor) before adding the note.
+
+`copy`::
+ Copy the notes for the first object onto the second object (defaults to
+ `HEAD`). Abort if the second object already has notes, or if the first
+ object has none (use `-f` to overwrite existing notes to the
+ second object). This subcommand is equivalent to:
+ `git notes add [-f] -C $(git notes list <from-object>) <to-object>`
++
+In `--stdin` mode, take lines in the format
++
+----------
+<from-object> SP <to-object> [ SP <rest> ] LF
+----------
++
+on standard input, and copy the notes from each _<from-object>_ to its
+corresponding _<to-object>_. (The optional _<rest>_ is ignored so that
+the command can read the input given to the `post-rewrite` hook.)
+
+`append`::
+ Append new message(s) given by `-m` or `-F` options to an
+ existing note, or add them as a new note if one does not
+ exist, for the object (defaults to `HEAD`). When appending to
+ an existing note, a blank line is added before each new
+ message as an inter-paragraph separator. The separator can
+ be customized with the `--separator` option.
+ Edit the notes to be appended given by `-m` and `-F` options with
+ `-e` interactively (using an editor) before appending the note.
+
+`edit`::
+ Edit the notes for a given object (defaults to `HEAD`).
+
+`show`::
+ Show the notes for a given object (defaults to `HEAD`).
+
+`merge`::
+ Merge the given notes ref into the current notes ref.
+ This will try to merge the changes made by the given
+ notes ref (called "remote") since the merge-base (if
+ any) into the current notes ref (called "local").
++
+If conflicts arise and a strategy for automatically resolving
+conflicting notes (see the "NOTES MERGE STRATEGIES" section) is not given,
+the `manual` resolver is used. This resolver checks out the
+conflicting notes in a special worktree (`.git/NOTES_MERGE_WORKTREE`),
+and instructs the user to manually resolve the conflicts there.
+When done, the user can either finalize the merge with
+`git notes merge --commit`, or abort the merge with
+`git notes merge --abort`.
+
+`remove`::
+ Remove the notes for given objects (defaults to `HEAD`). When
+ giving zero or one object from the command line, this is
+ equivalent to specifying an empty note message to
+ the `edit` subcommand.
+
+`prune`::
+ Remove all notes for non-existing/unreachable objects.
+
+`get-ref`::
+ Print the current notes ref. This provides an easy way to
+ retrieve the current notes ref (e.g. from scripts).
+
+OPTIONS
+-------
+`-f`::
+`--force`::
+ When adding notes to an object that already has notes,
+ overwrite the existing notes (instead of aborting).
+
+`-m <msg>`::
+`--message=<msg>`::
+ Use the given note message (instead of prompting).
+ If multiple `-m` options are given, their values
+ are concatenated as separate paragraphs.
+ Lines starting with `#` and empty lines other than a
+ single line between paragraphs will be stripped out.
+ If you wish to keep them verbatim, use `--no-stripspace`.
+
+`-F <file>`::
+`--file=<file>`::
+ Take the note message from the given file. Use `-` to
+ read the note message from the standard input.
+ Lines starting with `#` and empty lines other than a
+ single line between paragraphs will be stripped out.
+ If you wish to keep them verbatim, use `--no-stripspace`.
+
+`-C <object>`::
+`--reuse-message=<object>`::
+ Take the given blob object (for example, another note) as the
+ note message. (Use `git notes copy <object>` instead to
+ copy notes between objects.). By default, message will be
+ copied verbatim, but if you wish to strip out the lines
+ starting with `#` and empty lines other than a single line
+ between paragraphs, use with `--stripspace` option.
+
+`-c <object>`::
+`--reedit-message=<object>`::
+ Like `-C`, but with `-c` the editor is invoked, so that
+ the user can further edit the note message.
+
+`--allow-empty`::
+ Allow an empty note object to be stored. The default behavior is
+ to automatically remove empty notes.
+
+`--[no-]separator`::
+`--separator=<paragraph-break>`::
+ Specify a string used as a custom inter-paragraph separator
+ (a newline is added at the end as needed). If `--no-separator`, no
+ separators will be added between paragraphs. Defaults to a blank
+ line.
+
+`--[no-]stripspace`::
+ Strip leading and trailing whitespace from the note message.
+ Also strip out empty lines other than a single line between
+ paragraphs. Lines starting with `#` will be stripped out
+ in non-editor cases like `-m`, `-F` and `-C`, but not in
+ editor case like `git notes edit`, `-c`, etc.
+
+`--ref <ref>`::
+ Manipulate the notes tree in _<ref>_. This overrides
+ `GIT_NOTES_REF` and the `core.notesRef` configuration. The ref
+ specifies the full refname when it begins with `refs/notes/`; when it
+ begins with `notes/`, `refs/` and otherwise `refs/notes/` is prefixed
+ to form a full name of the ref.
+
+`--ignore-missing`::
+ Do not consider it an error to request removing notes from an
+ object that does not have notes attached to it.
+
+`--stdin`::
+ Also read the object names to remove notes from the standard
+ input (there is no reason you cannot combine this with object
+ names from the command line).
+
+`-n`::
+`--dry-run`::
+ Do not remove anything; just report the object names whose notes
+ would be removed.
+
+`-s <strategy>`::
+`--strategy=<strategy>`::
+ When merging notes, resolve notes conflicts using the given
+ strategy. The following strategies are recognized: `manual`
+ (default), `ours`, `theirs`, `union` and `cat_sort_uniq`.
+ This option overrides the `notes.mergeStrategy` configuration setting.
+ See the "NOTES MERGE STRATEGIES" section below for more
+ information on each notes merge strategy.
+
+`--commit`::
+ Finalize an in-progress `git notes merge`. Use this option
+ when you have resolved the conflicts that `git notes merge`
+ stored in `.git/NOTES_MERGE_WORKTREE`. This amends the partial
+ merge commit created by `git notes merge` (stored in
+ `.git/NOTES_MERGE_PARTIAL`) by adding the notes in
+ `.git/NOTES_MERGE_WORKTREE`. The notes ref stored in the
+ `.git/NOTES_MERGE_REF` symref is updated to the resulting commit.
+
+`--abort`::
+ Abort/reset an in-progress `git notes merge`, i.e. a notes merge
+ with conflicts. This simply removes all files related to the
+ notes merge.
+
+`-q`::
+`--quiet`::
+ When merging notes, operate quietly.
+
+`-v`::
+`--verbose`::
+ When merging notes, be more verbose.
+ When pruning notes, report all object names whose notes are
+ removed.
+
+
+DISCUSSION
+----------
+
+Commit notes are blobs containing extra information about an object
+(usually information to supplement a commit's message). These blobs
+are taken from notes refs. A notes ref is usually a branch which
+contains "files" whose paths are the object names for the objects
+they describe, with some directory separators included for performance
+reasons footnote:[Permitted pathnames have the form
+'bf'`/`'fe'`/`'30'`/`'...'`/`'680d5a...': a sequence of directory
+names of two hexadecimal digits each followed by a filename with the
+rest of the object ID.].
+
+Every notes change creates a new commit at the specified notes ref.
+You can therefore inspect the history of the notes by invoking, e.g.,
+`git log -p notes/commits`. Currently the commit message only records
+which operation triggered the update, and the commit authorship is
+determined according to the usual rules (see linkgit:git-commit[1]).
+These details may change in the future.
+
+It is also permitted for a notes ref to point directly to a tree
+object, in which case the history of the notes can be read with
+`git log -p -g <refname>`.
+
+
+NOTES MERGE STRATEGIES
+----------------------
+
+The default notes merge strategy is `manual`, which checks out
+conflicting notes in a special work tree for resolving notes conflicts
+(`.git/NOTES_MERGE_WORKTREE`), and instructs the user to resolve the
+conflicts in that work tree.
+When done, the user can either finalize the merge with
+`git notes merge --commit`, or abort the merge with
+`git notes merge --abort`.
+
+Users may select an automated merge strategy from among the following using
+either `-s`/`--strategy` option or configuring `notes.mergeStrategy` accordingly:
+
+`ours` automatically resolves conflicting notes in favor of the local
+version (i.e. the current notes ref).
+
+`theirs` automatically resolves notes conflicts in favor of the remote
+version (i.e. the given notes ref being merged into the current notes
+ref).
+
+`union` automatically resolves notes conflicts by concatenating the
+local and remote versions.
+
+`cat_sort_uniq` is similar to `union`, but in addition to concatenating
+the local and remote versions, this strategy also sorts the resulting
+lines, and removes duplicate lines from the result. This is equivalent
+to applying the "cat | sort | uniq" shell pipeline to the local and
+remote versions. This strategy is useful if the notes follow a line-based
+format where one wants to avoid duplicated lines in the merge result.
+Note that if either the local or remote version contain duplicate lines
+prior to the merge, these will also be removed by this notes merge
+strategy.
+
+
+EXAMPLES
+--------
+
+You can use notes to add annotations with information that was not
+available at the time a commit was written.
+
+------------
+$ git notes add -m 'Tested-by: Johannes Sixt <j6t@kdbg.org>' 72a144e2
+$ git show -s 72a144e
+[...]
+ Signed-off-by: Junio C Hamano <gitster@pobox.com>
+
+Notes:
+ Tested-by: Johannes Sixt <j6t@kdbg.org>
+------------
+
+In principle, a note is a regular Git blob, and any kind of
+(non-)format is accepted. You can binary-safely create notes from
+arbitrary files using `git hash-object`:
+
+------------
+$ cc *.c
+$ blob=$(git hash-object -w a.out)
+$ git notes --ref=built add --allow-empty -C "$blob" HEAD
+------------
+
+(You cannot simply use `git notes --ref=built add -F a.out HEAD`
+because that is not binary-safe.)
+Of course, it doesn't make much sense to display non-text-format notes
+with `git log`, so if you use such notes, you'll probably need to write
+some special-purpose tools to do something useful with them.
+
+
+[[CONFIGURATION]]
+CONFIGURATION
+-------------
+
+`core.notesRef`::
+ Notes ref to read and manipulate instead of
+ `refs/notes/commits`. Must be an unabbreviated ref name.
+ This setting can be overridden through the environment and
+ command line.
+
+include::includes/cmd-config-section-rest.adoc[]
+
+include::config/notes.adoc[]
+
+
+ENVIRONMENT
+-----------
+
+`GIT_NOTES_REF`::
+ Which ref to manipulate notes from, instead of `refs/notes/commits`.
+ This overrides the `core.notesRef` setting.
+
+`GIT_NOTES_DISPLAY_REF`::
+ Colon-delimited list of refs or globs indicating which refs,
+ in addition to the default from `core.notesRef` or
+ `GIT_NOTES_REF`, to read notes from when showing commit
+ messages.
+ This overrides the `notes.displayRef` setting.
++
+A warning will be issued for refs that do not exist, but a glob that
+does not match any refs is silently ignored.
+
+`GIT_NOTES_REWRITE_MODE`::
+ When copying notes during a rewrite, what to do if the target
+ commit already has a note.
+ Must be one of `overwrite`, `concatenate`, `cat_sort_uniq`, or `ignore`.
+ This overrides the `core.rewriteMode` setting.
+
+`GIT_NOTES_REWRITE_REF`::
+ When rewriting commits, which notes to copy from the original
+ to the rewritten commit. Must be a colon-delimited list of
+ refs or globs.
++
+If not set in the environment, the list of notes to copy depends
+on the `notes.rewrite.<command>` and `notes.rewriteRef` settings.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-p4.adoc b/git-p4.adoc
new file mode 100644
index 0000000..de5ee67
--- /dev/null
+++ b/git-p4.adoc
@@ -0,0 +1,803 @@
+git-p4(1)
+=========
+
+NAME
+----
+git-p4 - Import from and submit to Perforce repositories
+
+
+SYNOPSIS
+--------
+[verse]
+'git p4 clone' [<sync-options>] [<clone-options>] <p4-depot-path>...
+'git p4 sync' [<sync-options>] [<p4-depot-path>...]
+'git p4 rebase'
+'git p4 submit' [<submit-options>] [<master-branch-name>]
+
+
+DESCRIPTION
+-----------
+This command provides a way to interact with p4 repositories
+using Git.
+
+Create a new Git repository from an existing p4 repository using
+'git p4 clone', giving it one or more p4 depot paths. Incorporate
+new commits from p4 changes with 'git p4 sync'. The 'sync' command
+is also used to include new branches from other p4 depot paths.
+Submit Git changes back to p4 using 'git p4 submit'. The command
+'git p4 rebase' does a sync plus rebases the current branch onto
+the updated p4 remote branch.
+
+
+EXAMPLES
+--------
+* Clone a repository:
++
+------------
+$ git p4 clone //depot/path/project
+------------
+
+* Do some work in the newly created Git repository:
++
+------------
+$ cd project
+$ vi foo.h
+$ git commit -a -m "edited foo.h"
+------------
+
+* Update the Git repository with recent changes from p4, rebasing your
+ work on top:
++
+------------
+$ git p4 rebase
+------------
+
+* Submit your commits back to p4:
++
+------------
+$ git p4 submit
+------------
+
+
+COMMANDS
+--------
+
+Clone
+~~~~~
+Generally, 'git p4 clone' is used to create a new Git directory
+from an existing p4 repository:
+------------
+$ git p4 clone //depot/path/project
+------------
+This:
+
+1. Creates an empty Git repository in a subdirectory called 'project'.
++
+2. Imports the full contents of the head revision from the given p4
+ depot path into a single commit in the Git branch 'refs/remotes/p4/master'.
++
+3. Creates a local branch, 'master' from this remote and checks it out.
+
+To reproduce the entire p4 history in Git, use the '@all' modifier on
+the depot path:
+------------
+$ git p4 clone //depot/path/project@all
+------------
+
+
+Sync
+~~~~
+As development continues in the p4 repository, those changes can
+be included in the Git repository using:
+------------
+$ git p4 sync
+------------
+This command finds new changes in p4 and imports them as Git commits.
+
+P4 repositories can be added to an existing Git repository using
+'git p4 sync' too:
+------------
+$ mkdir repo-git
+$ cd repo-git
+$ git init
+$ git p4 sync //path/in/your/perforce/depot
+------------
+This imports the specified depot into
+'refs/remotes/p4/master' in an existing Git repository. The
+`--branch` option can be used to specify a different branch to
+be used for the p4 content.
+
+If a Git repository includes branches 'refs/remotes/origin/p4', these
+will be fetched and consulted first during a 'git p4 sync'. Since
+importing directly from p4 is considerably slower than pulling changes
+from a Git remote, this can be useful in a multi-developer environment.
+
+If there are multiple branches, doing 'git p4 sync' will automatically
+use the "BRANCH DETECTION" algorithm to try to partition new changes
+into the right branch. This can be overridden with the `--branch`
+option to specify just a single branch to update.
+
+
+Rebase
+~~~~~~
+A common working pattern is to fetch the latest changes from the p4 depot
+and merge them with local uncommitted changes. Often, the p4 repository
+is the ultimate location for all code, thus a rebase workflow makes
+sense. This command does 'git p4 sync' followed by 'git rebase' to move
+local commits on top of updated p4 changes.
+------------
+$ git p4 rebase
+------------
+
+
+Submit
+~~~~~~
+Submitting changes from a Git repository back to the p4 repository
+requires a separate p4 client workspace. This should be specified
+using the `P4CLIENT` environment variable or the Git configuration
+variable 'git-p4.client'. The p4 client must exist, but the client root
+will be created and populated if it does not already exist.
+
+To submit all changes that are in the current Git branch but not in
+the 'p4/master' branch, use:
+------------
+$ git p4 submit
+------------
+
+To specify a branch other than the current one, use:
+------------
+$ git p4 submit topicbranch
+------------
+
+To specify a single commit or a range of commits, use:
+------------
+$ git p4 submit --commit <sha1>
+$ git p4 submit --commit <sha1..sha1>
+------------
+
+The upstream reference is generally 'refs/remotes/p4/master', but can
+be overridden using the `--origin=` command-line option.
+
+The p4 changes will be created as the user invoking 'git p4 submit'. The
+`--preserve-user` option will cause ownership to be modified
+according to the author of the Git commit. This option requires admin
+privileges in p4, which can be granted using 'p4 protect'.
+
+To shelve changes instead of submitting, use `--shelve` and `--update-shelve`:
+
+----
+$ git p4 submit --shelve
+$ git p4 submit --update-shelve 1234 --update-shelve 2345
+----
+
+
+Unshelve
+~~~~~~~~
+Unshelving will take a shelved P4 changelist, and produce the equivalent git commit
+in the branch refs/remotes/p4-unshelved/<changelist>.
+
+The git commit is created relative to the current origin revision (HEAD by default).
+A parent commit is created based on the origin, and then the unshelve commit is
+created based on that.
+
+The origin revision can be changed with the "--origin" option.
+
+If the target branch in refs/remotes/p4-unshelved already exists, the old one will
+be renamed.
+
+----
+$ git p4 sync
+$ git p4 unshelve 12345
+$ git show p4-unshelved/12345
+<submit more changes via p4 to the same files>
+$ git p4 unshelve 12345
+<refuses to unshelve until git is in sync with p4 again>
+
+----
+
+OPTIONS
+-------
+
+General options
+~~~~~~~~~~~~~~~
+All commands except clone accept these options.
+
+--git-dir <dir>::
+ Set the `GIT_DIR` environment variable. See linkgit:git[1].
+
+-v::
+--verbose::
+ Provide more progress information.
+
+Sync options
+~~~~~~~~~~~~
+These options can be used in the initial 'clone' as well as in
+subsequent 'sync' operations.
+
+--branch <ref>::
+ Import changes into <ref> instead of refs/remotes/p4/master.
+ If <ref> starts with refs/, it is used as is. Otherwise, if
+ it does not start with p4/, that prefix is added.
++
+By default a <ref> not starting with refs/ is treated as the
+name of a remote-tracking branch (under refs/remotes/). This
+behavior can be modified using the --import-local option.
++
+The default <ref> is "master".
++
+This example imports a new remote "p4/proj2" into an existing
+Git repository:
++
+----
+ $ git init
+ $ git p4 sync --branch=refs/remotes/p4/proj2 //depot/proj2
+----
+
+--detect-branches::
+ Use the branch detection algorithm to find new paths in p4. It is
+ documented below in "BRANCH DETECTION".
+
+--changesfile <file>::
+ Import exactly the p4 change numbers listed in 'file', one per
+ line. Normally, 'git p4' inspects the current p4 repository
+ state and detects the changes it should import.
+
+--silent::
+ Do not print any progress information.
+
+--detect-labels::
+ Query p4 for labels associated with the depot paths, and add
+ them as tags in Git. Limited usefulness as only imports labels
+ associated with new changelists. Deprecated.
+
+--import-labels::
+ Import labels from p4 into Git.
+
+--import-local::
+ By default, p4 branches are stored in 'refs/remotes/p4/',
+ where they will be treated as remote-tracking branches by
+ linkgit:git-branch[1] and other commands. This option instead
+ puts p4 branches in 'refs/heads/p4/'. Note that future
+ sync operations must specify `--import-local` as well so that
+ they can find the p4 branches in refs/heads.
+
+--max-changes <n>::
+ Import at most 'n' changes, rather than the entire range of
+ changes included in the given revision specifier. A typical
+ usage would be use '@all' as the revision specifier, but then
+ to use '--max-changes 1000' to import only the last 1000
+ revisions rather than the entire revision history.
+
+--changes-block-size <n>::
+ The internal block size to use when converting a revision
+ specifier such as '@all' into a list of specific change
+ numbers. Instead of using a single call to 'p4 changes' to
+ find the full list of changes for the conversion, there are a
+ sequence of calls to 'p4 changes -m', each of which requests
+ one block of changes of the given size. The default block size
+ is 500, which should usually be suitable.
+
+--keep-path::
+ The mapping of file names from the p4 depot path to Git, by
+ default, involves removing the entire depot path. With this
+ option, the full p4 depot path is retained in Git. For example,
+ path '//depot/main/foo/bar.c', when imported from
+ '//depot/main/', becomes 'foo/bar.c'. With `--keep-path`, the
+ Git path is instead 'depot/main/foo/bar.c'.
+
+--use-client-spec::
+ Use a client spec to find the list of interesting files in p4.
+ See the "CLIENT SPEC" section below.
+
+-/ <path>::
+ Exclude selected depot paths when cloning or syncing.
+
+Clone options
+~~~~~~~~~~~~~
+These options can be used in an initial 'clone', along with the 'sync'
+options described above.
+
+--destination <directory>::
+ Where to create the Git repository. If not provided, the last
+ component in the p4 depot path is used to create a new
+ directory.
+
+--bare::
+ Perform a bare clone. See linkgit:git-clone[1].
+
+Submit options
+~~~~~~~~~~~~~~
+These options can be used to modify 'git p4 submit' behavior.
+
+--origin <commit>::
+ Upstream location from which commits are identified to submit to
+ p4. By default, this is the most recent p4 commit reachable
+ from `HEAD`.
+
+-M::
+ Detect renames. See linkgit:git-diff[1]. Renames will be
+ represented in p4 using explicit 'move' operations. There
+ is no corresponding option to detect copies, but there are
+ variables for both moves and copies.
+
+--preserve-user::
+ Re-author p4 changes before submitting to p4. This option
+ requires p4 admin privileges.
+
+--export-labels::
+ Export tags from Git as p4 labels. Tags found in Git are applied
+ to the perforce working directory.
+
+-n::
+--dry-run::
+ Show just what commits would be submitted to p4; do not change
+ state in Git or p4.
+
+--prepare-p4-only::
+ Apply a commit to the p4 workspace, opening, adding and deleting
+ files in p4 as for a normal submit operation. Do not issue the
+ final "p4 submit", but instead print a message about how to
+ submit manually or revert. This option always stops after the
+ first (oldest) commit. Git tags are not exported to p4.
+
+--shelve::
+ Instead of submitting create a series of shelved changelists.
+ After creating each shelve, the relevant files are reverted/deleted.
+ If you have multiple commits pending multiple shelves will be created.
+
+--update-shelve CHANGELIST::
+ Update an existing shelved changelist with this commit. Implies
+ --shelve. Repeat for multiple shelved changelists.
+
+--conflict=(ask|skip|quit)::
+ Conflicts can occur when applying a commit to p4. When this
+ happens, the default behavior ("ask") is to prompt whether to
+ skip this commit and continue, or quit. This option can be used
+ to bypass the prompt, causing conflicting commits to be automatically
+ skipped, or to quit trying to apply commits, without prompting.
+
+--branch <branch>::
+ After submitting, sync this named branch instead of the default
+ p4/master. See the "Sync options" section above for more
+ information.
+
+--commit (<sha1>|<sha1>..<sha1>)::
+ Submit only the specified commit or range of commits, instead of the full
+ list of changes that are in the current Git branch.
+
+--disable-rebase::
+ Disable the automatic rebase after all commits have been successfully
+ submitted. Can also be set with git-p4.disableRebase.
+
+--disable-p4sync::
+ Disable the automatic sync of p4/master from Perforce after commits have
+ been submitted. Implies --disable-rebase. Can also be set with
+ git-p4.disableP4Sync. Sync with origin/master still goes ahead if possible.
+
+Hooks for submit
+----------------
+
+p4-pre-submit
+~~~~~~~~~~~~~
+
+The `p4-pre-submit` hook is executed if it exists and is executable.
+The hook takes no parameters and nothing from standard input. Exiting with
+non-zero status from this script prevents `git-p4 submit` from launching.
+It can be bypassed with the `--no-verify` command line option.
+
+One usage scenario is to run unit tests in the hook.
+
+p4-prepare-changelist
+~~~~~~~~~~~~~~~~~~~~~
+
+The `p4-prepare-changelist` hook is executed right after preparing
+the default changelist message and before the editor is started.
+It takes one parameter, the name of the file that contains the
+changelist text. Exiting with a non-zero status from the script
+will abort the process.
+
+The purpose of the hook is to edit the message file in place,
+and it is not suppressed by the `--no-verify` option. This hook
+is called even if `--prepare-p4-only` is set.
+
+p4-changelist
+~~~~~~~~~~~~~
+
+The `p4-changelist` hook is executed after the changelist
+message has been edited by the user. It can be bypassed with the
+`--no-verify` option. It takes a single parameter, the name
+of the file that holds the proposed changelist text. Exiting
+with a non-zero status causes the command to abort.
+
+The hook is allowed to edit the changelist file and can be used
+to normalize the text into some project standard format. It can
+also be used to refuse the Submit after inspect the message file.
+
+p4-post-changelist
+~~~~~~~~~~~~~~~~~~
+
+The `p4-post-changelist` hook is invoked after the submit has
+successfully occurred in P4. It takes no parameters and is meant
+primarily for notification and cannot affect the outcome of the
+git p4 submit action.
+
+
+
+Rebase options
+~~~~~~~~~~~~~~
+These options can be used to modify 'git p4 rebase' behavior.
+
+--import-labels::
+ Import p4 labels.
+
+Unshelve options
+~~~~~~~~~~~~~~~~
+
+--origin::
+ Sets the git refspec against which the shelved P4 changelist is compared.
+ Defaults to p4/master.
+
+DEPOT PATH SYNTAX
+-----------------
+The p4 depot path argument to 'git p4 sync' and 'git p4 clone' can
+be one or more space-separated p4 depot paths, with an optional
+p4 revision specifier on the end:
+
+"//depot/my/project"::
+ Import one commit with all files in the '#head' change under that tree.
+
+"//depot/my/project@all"::
+ Import one commit for each change in the history of that depot path.
+
+"//depot/my/project@1,6"::
+ Import only changes 1 through 6.
+
+"//depot/proj1@all //depot/proj2@all"::
+ Import all changes from both named depot paths into a single
+ repository. Only files below these directories are included.
+ There is not a subdirectory in Git for each "proj1" and "proj2".
+ You must use the `--destination` option when specifying more
+ than one depot path. The revision specifier must be specified
+ identically on each depot path. If there are files in the
+ depot paths with the same name, the path with the most recently
+ updated version of the file is the one that appears in Git.
+
+See 'p4 help revisions' for the full syntax of p4 revision specifiers.
+
+
+CLIENT SPEC
+-----------
+The p4 client specification is maintained with the 'p4 client' command
+and contains among other fields, a View that specifies how the depot
+is mapped into the client repository. The 'clone' and 'sync' commands
+can consult the client spec when given the `--use-client-spec` option or
+when the useClientSpec variable is true. After 'git p4 clone', the
+useClientSpec variable is automatically set in the repository
+configuration file. This allows future 'git p4 submit' commands to
+work properly; the submit command looks only at the variable and does
+not have a command-line option.
+
+The full syntax for a p4 view is documented in 'p4 help views'. 'git p4'
+knows only a subset of the view syntax. It understands multi-line
+mappings, overlays with '+', exclusions with '-' and double-quotes
+around whitespace. Of the possible wildcards, 'git p4' only handles
+'...', and only when it is at the end of the path. 'git p4' will complain
+if it encounters an unhandled wildcard.
+
+Bugs in the implementation of overlap mappings exist. If multiple depot
+paths map through overlays to the same location in the repository,
+'git p4' can choose the wrong one. This is hard to solve without
+dedicating a client spec just for 'git p4'.
+
+The name of the client can be given to 'git p4' in multiple ways. The
+variable 'git-p4.client' takes precedence if it exists. Otherwise,
+normal p4 mechanisms of determining the client are used: environment
+variable `P4CLIENT`, a file referenced by `P4CONFIG`, or the local host name.
+
+
+BRANCH DETECTION
+----------------
+P4 does not have the same concept of a branch as Git. Instead,
+p4 organizes its content as a directory tree, where by convention
+different logical branches are in different locations in the tree.
+The 'p4 branch' command is used to maintain mappings between
+different areas in the tree, and indicate related content. 'git p4'
+can use these mappings to determine branch relationships.
+
+If you have a repository where all the branches of interest exist as
+subdirectories of a single depot path, you can use `--detect-branches`
+when cloning or syncing to have 'git p4' automatically find
+subdirectories in p4, and to generate these as branches in Git.
+
+For example, if the P4 repository structure is:
+----
+//depot/main/...
+//depot/branch1/...
+----
+
+And "p4 branch -o branch1" shows a View line that looks like:
+----
+//depot/main/... //depot/branch1/...
+----
+
+Then this 'git p4 clone' command:
+----
+git p4 clone --detect-branches //depot@all
+----
+produces a separate branch in 'refs/remotes/p4/' for //depot/main,
+called 'master', and one for //depot/branch1 called 'depot/branch1'.
+
+However, it is not necessary to create branches in p4 to be able to use
+them like branches. Because it is difficult to infer branch
+relationships automatically, a Git configuration setting
+'git-p4.branchList' can be used to explicitly identify branch
+relationships. It is a list of "source:destination" pairs, like a
+simple p4 branch specification, where the "source" and "destination" are
+the path elements in the p4 repository. The example above relied on the
+presence of the p4 branch. Without p4 branches, the same result will
+occur with:
+----
+git init depot
+cd depot
+git config git-p4.branchList main:branch1
+git p4 clone --detect-branches //depot@all .
+----
+
+
+PERFORMANCE
+-----------
+The fast-import mechanism used by 'git p4' creates one pack file for
+each invocation of 'git p4 sync'. Normally, Git garbage compression
+(linkgit:git-gc[1]) automatically compresses these to fewer pack files,
+but explicit invocation of 'git repack -adf' may improve performance.
+
+
+CONFIGURATION VARIABLES
+-----------------------
+The following config settings can be used to modify 'git p4' behavior.
+They all are in the 'git-p4' section.
+
+General variables
+~~~~~~~~~~~~~~~~~
+git-p4.user::
+ User specified as an option to all p4 commands, with '-u <user>'.
+ The environment variable `P4USER` can be used instead.
+
+git-p4.password::
+ Password specified as an option to all p4 commands, with
+ '-P <password>'.
+ The environment variable `P4PASS` can be used instead.
+
+git-p4.port::
+ Port specified as an option to all p4 commands, with
+ '-p <port>'.
+ The environment variable `P4PORT` can be used instead.
+
+git-p4.host::
+ Host specified as an option to all p4 commands, with
+ '-h <host>'.
+ The environment variable `P4HOST` can be used instead.
+
+git-p4.client::
+ Client specified as an option to all p4 commands, with
+ '-c <client>', including the client spec.
+
+git-p4.retries::
+ Specifies the number of times to retry a p4 command (notably,
+ 'p4 sync') if the network times out. The default value is 3.
+ Set the value to 0 to disable retries or if your p4 version
+ does not support retries (pre 2012.2).
+
+Clone and sync variables
+~~~~~~~~~~~~~~~~~~~~~~~~
+git-p4.syncFromOrigin::
+ Because importing commits from other Git repositories is much faster
+ than importing them from p4, a mechanism exists to find p4 changes
+ first in Git remotes. If branches exist under 'refs/remote/origin/p4',
+ those will be fetched and used when syncing from p4. This
+ variable can be set to 'false' to disable this behavior.
+
+git-p4.branchUser::
+ One phase in branch detection involves looking at p4 branches
+ to find new ones to import. By default, all branches are
+ inspected. This option limits the search to just those owned
+ by the single user named in the variable.
+
+git-p4.branchList::
+ List of branches to be imported when branch detection is
+ enabled. Each entry should be a pair of branch names separated
+ by a colon (:). This example declares that both branchA and
+ branchB were created from main:
++
+-------------
+git config git-p4.branchList main:branchA
+git config --add git-p4.branchList main:branchB
+-------------
+
+git-p4.ignoredP4Labels::
+ List of p4 labels to ignore. This is built automatically as
+ unimportable labels are discovered.
+
+git-p4.importLabels::
+ Import p4 labels into git, as per --import-labels.
+
+git-p4.labelImportRegexp::
+ Only p4 labels matching this regular expression will be imported. The
+ default value is '[a-zA-Z0-9_\-.]+$'.
+
+git-p4.useClientSpec::
+ Specify that the p4 client spec should be used to identify p4
+ depot paths of interest. This is equivalent to specifying the
+ option `--use-client-spec`. See the "CLIENT SPEC" section above.
+ This variable is a boolean, not the name of a p4 client.
+
+git-p4.pathEncoding::
+ Perforce keeps the encoding of a path as given by the originating OS.
+ Git expects paths encoded as UTF-8. Use this config to tell git-p4
+ what encoding Perforce had used for the paths. This encoding is used
+ to transcode the paths to UTF-8. As an example, Perforce on Windows
+ often uses "cp1252" to encode path names. If this option is passed
+ into a p4 clone request, it is persisted in the resulting new git
+ repo.
+
+git-p4.metadataDecodingStrategy::
+ Perforce keeps the encoding of a changelist descriptions and user
+ full names as stored by the client on a given OS. The p4v client
+ uses the OS-local encoding, and so different users can end up storing
+ different changelist descriptions or user full names in different
+ encodings, in the same depot.
+ Git tolerates inconsistent/incorrect encodings in commit messages
+ and author names, but expects them to be specified in utf-8.
+ git-p4 can use three different decoding strategies in handling the
+ encoding uncertainty in Perforce: 'passthrough' simply passes the
+ original bytes through from Perforce to git, creating usable but
+ incorrectly-encoded data when the Perforce data is encoded as
+ anything other than utf-8. 'strict' expects the Perforce data to be
+ encoded as utf-8, and fails to import when this is not true.
+ 'fallback' attempts to interpret the data as utf-8, and otherwise
+ falls back to using a secondary encoding - by default the common
+ windows encoding 'cp-1252' - with upper-range bytes escaped if
+ decoding with the fallback encoding also fails.
+ Under python2 the default strategy is 'passthrough' for historical
+ reasons, and under python3 the default is 'fallback'.
+ When 'strict' is selected and decoding fails, the error message will
+ propose changing this config parameter as a workaround. If this
+ option is passed into a p4 clone request, it is persisted into the
+ resulting new git repo.
+
+git-p4.metadataFallbackEncoding::
+ Specify the fallback encoding to use when decoding Perforce author
+ names and changelists descriptions using the 'fallback' strategy
+ (see git-p4.metadataDecodingStrategy). The fallback encoding will
+ only be used when decoding as utf-8 fails. This option defaults to
+ cp1252, a common windows encoding. If this option is passed into a
+ p4 clone request, it is persisted into the resulting new git repo.
+
+git-p4.largeFileSystem::
+ Specify the system that is used for large (binary) files. Please note
+ that large file systems do not support the 'git p4 submit' command.
+ Only Git LFS is implemented right now (see https://git-lfs.github.com/
+ for more information). Download and install the Git LFS command line
+ extension to use this option and configure it like this:
++
+-------------
+git config git-p4.largeFileSystem GitLFS
+-------------
+
+git-p4.largeFileExtensions::
+ All files matching a file extension in the list will be processed
+ by the large file system. Do not prefix the extensions with '.'.
+
+git-p4.largeFileThreshold::
+ All files with an uncompressed size exceeding the threshold will be
+ processed by the large file system. By default the threshold is
+ defined in bytes. Add the suffix k, m, or g to change the unit.
+
+git-p4.largeFileCompressedThreshold::
+ All files with a compressed size exceeding the threshold will be
+ processed by the large file system. This option might slow down
+ your clone/sync process. By default the threshold is defined in
+ bytes. Add the suffix k, m, or g to change the unit.
+
+git-p4.largeFilePush::
+ Boolean variable which defines if large files are automatically
+ pushed to a server.
+
+git-p4.keepEmptyCommits::
+ A changelist that contains only excluded files will be imported
+ as an empty commit if this boolean option is set to true.
+
+git-p4.mapUser::
+ Map a P4 user to a name and email address in Git. Use a string
+ with the following format to create a mapping:
++
+-------------
+git config --add git-p4.mapUser "p4user = First Last <mail@address.com>"
+-------------
++
+A mapping will override any user information from P4. Mappings for
+multiple P4 user can be defined.
+
+Submit variables
+~~~~~~~~~~~~~~~~
+git-p4.detectRenames::
+ Detect renames. See linkgit:git-diff[1]. This can be true,
+ false, or a score as expected by 'git diff -M'.
+
+git-p4.detectCopies::
+ Detect copies. See linkgit:git-diff[1]. This can be true,
+ false, or a score as expected by 'git diff -C'.
+
+git-p4.detectCopiesHarder::
+ Detect copies harder. See linkgit:git-diff[1]. A boolean.
+
+git-p4.preserveUser::
+ On submit, re-author changes to reflect the Git author,
+ regardless of who invokes 'git p4 submit'.
+
+git-p4.allowMissingP4Users::
+ When 'preserveUser' is true, 'git p4' normally dies if it
+ cannot find an author in the p4 user map. This setting
+ submits the change regardless.
+
+git-p4.skipSubmitEdit::
+ The submit process invokes the editor before each p4 change
+ is submitted. If this setting is true, though, the editing
+ step is skipped.
+
+git-p4.skipSubmitEditCheck::
+ After editing the p4 change message, 'git p4' makes sure that
+ the description really was changed by looking at the file
+ modification time. This option disables that test.
+
+git-p4.allowSubmit::
+ By default, any branch can be used as the source for a 'git p4
+ submit' operation. This configuration variable, if set, permits only
+ the named branches to be used as submit sources. Branch names
+ must be the short names (no "refs/heads/"), and should be
+ separated by commas (","), with no spaces.
+
+git-p4.skipUserNameCheck::
+ If the user running 'git p4 submit' does not exist in the p4
+ user map, 'git p4' exits. This option can be used to force
+ submission regardless.
+
+git-p4.attemptRCSCleanup::
+ If enabled, 'git p4 submit' will attempt to cleanup RCS keywords
+ ($Header$, etc). These would otherwise cause merge conflicts and prevent
+ the submit going ahead. This option should be considered experimental at
+ present.
+
+git-p4.exportLabels::
+ Export Git tags to p4 labels, as per --export-labels.
+
+git-p4.labelExportRegexp::
+ Only p4 labels matching this regular expression will be exported. The
+ default value is '[a-zA-Z0-9_\-.]+$'.
+
+git-p4.conflict::
+ Specify submit behavior when a conflict with p4 is found, as per
+ --conflict. The default behavior is 'ask'.
+
+git-p4.disableRebase::
+ Do not rebase the tree against p4/master following a submit.
+
+git-p4.disableP4Sync::
+ Do not sync p4/master with Perforce following a submit. Implies git-p4.disableRebase.
+
+IMPLEMENTATION DETAILS
+----------------------
+* Changesets from p4 are imported using Git fast-import.
+* Cloning or syncing does not require a p4 client; file contents are
+ collected using 'p4 print'.
+* Submitting requires a p4 client, which is not in the same location
+ as the Git repository. Patches are applied, one at a time, to
+ this p4 client and submitted from there.
+* Each commit imported by 'git p4' has a line at the end of the log
+ message indicating the p4 depot location and change number. This
+ line is used by later 'git p4 sync' operations to know which p4
+ changes are new.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-pack-objects.adoc b/git-pack-objects.adoc
new file mode 100644
index 0000000..7f69ae4
--- /dev/null
+++ b/git-pack-objects.adoc
@@ -0,0 +1,490 @@
+git-pack-objects(1)
+===================
+
+NAME
+----
+git-pack-objects - Create a packed archive of objects
+
+
+SYNOPSIS
+--------
+[verse]
+'git pack-objects' [-q | --progress | --all-progress] [--all-progress-implied]
+ [--no-reuse-delta] [--delta-base-offset] [--non-empty]
+ [--local] [--incremental] [--window=<n>] [--depth=<n>]
+ [--revs [--unpacked | --all]] [--keep-pack=<pack-name>]
+ [--cruft] [--cruft-expiration=<time>]
+ [--stdout [--filter=<filter-spec>] | <base-name>]
+ [--shallow] [--keep-true-parents] [--[no-]sparse]
+ [--name-hash-version=<n>] < <object-list>
+
+
+DESCRIPTION
+-----------
+Reads list of objects from the standard input, and writes either one or
+more packed archives with the specified base-name to disk, or a packed
+archive to the standard output.
+
+A packed archive is an efficient way to transfer a set of objects
+between two repositories as well as an access efficient archival
+format. In a packed archive, an object is either stored as a
+compressed whole or as a difference from some other object.
+The latter is often called a delta.
+
+The packed archive format (.pack) is designed to be self-contained
+so that it can be unpacked without any further information. Therefore,
+each object that a delta depends upon must be present within the pack.
+
+A pack index file (.idx) is generated for fast, random access to the
+objects in the pack. Placing both the index file (.idx) and the packed
+archive (.pack) in the pack/ subdirectory of $GIT_OBJECT_DIRECTORY (or
+any of the directories on $GIT_ALTERNATE_OBJECT_DIRECTORIES)
+enables Git to read from the pack archive.
+
+The 'git unpack-objects' command can read the packed archive and
+expand the objects contained in the pack into "one-file
+one-object" format; this is typically done by the smart-pull
+commands when a pack is created on-the-fly for efficient network
+transport by their peers.
+
+
+OPTIONS
+-------
+base-name::
+ Write into pairs of files (.pack and .idx), using
+ <base-name> to determine the name of the created file.
+ When this option is used, the two files in a pair are written in
+ <base-name>-<SHA-1>.{pack,idx} files. <SHA-1> is a hash
+ based on the pack content and is written to the standard
+ output of the command.
+
+--stdout::
+ Write the pack contents (what would have been written to
+ .pack file) out to the standard output.
+
+--revs::
+ Read the revision arguments from the standard input, instead of
+ individual object names. The revision arguments are processed
+ the same way as 'git rev-list' with the `--objects` flag
+ uses its `commit` arguments to build the list of objects it
+ outputs. The objects on the resulting list are packed.
+ Besides revisions, `--not` or `--shallow <SHA-1>` lines are
+ also accepted.
+
+--unpacked::
+ This implies `--revs`. When processing the list of
+ revision arguments read from the standard input, limit
+ the objects packed to those that are not already packed.
+
+--all::
+ This implies `--revs`. In addition to the list of
+ revision arguments read from the standard input, pretend
+ as if all refs under `refs/` are specified to be
+ included.
+
+--include-tag::
+ Include unasked-for annotated tags if the object they
+ reference was included in the resulting packfile. This
+ can be useful to send new tags to native Git clients.
+
+--stdin-packs::
+ Read the basenames of packfiles (e.g., `pack-1234abcd.pack`)
+ from the standard input, instead of object names or revision
+ arguments. The resulting pack contains all objects listed in the
+ included packs (those not beginning with `^`), excluding any
+ objects listed in the excluded packs (beginning with `^`).
++
+Incompatible with `--revs`, or options that imply `--revs` (such as
+`--all`), with the exception of `--unpacked`, which is compatible.
+
+--cruft::
+ Packs unreachable objects into a separate "cruft" pack, denoted
+ by the existence of a `.mtimes` file. Typically used by `git
+ repack --cruft`. Callers provide a list of pack names and
+ indicate which packs will remain in the repository, along with
+ which packs will be deleted (indicated by the `-` prefix). The
+ contents of the cruft pack are all objects not contained in the
+ surviving packs which have not exceeded the grace period (see
+ `--cruft-expiration` below), or which have exceeded the grace
+ period, but are reachable from an other object which hasn't.
++
+When the input lists a pack containing all reachable objects (and lists
+all other packs as pending deletion), the corresponding cruft pack will
+contain all unreachable objects (with mtime newer than the
+`--cruft-expiration`) along with any unreachable objects whose mtime is
+older than the `--cruft-expiration`, but are reachable from an
+unreachable object whose mtime is newer than the `--cruft-expiration`).
++
+Incompatible with `--unpack-unreachable`, `--keep-unreachable`,
+`--pack-loose-unreachable`, `--stdin-packs`, as well as any other
+options which imply `--revs`.
+
+--cruft-expiration=<approxidate>::
+ If specified, objects are eliminated from the cruft pack if they
+ have an mtime older than `<approxidate>`. If unspecified (and
+ given `--cruft`), then no objects are eliminated.
+
+--window=<n>::
+--depth=<n>::
+ These two options affect how the objects contained in
+ the pack are stored using delta compression. The
+ objects are first internally sorted by type, size and
+ optionally names and compared against the other objects
+ within --window to see if using delta compression saves
+ space. --depth limits the maximum delta depth; making
+ it too deep affects the performance on the unpacker
+ side, because delta data needs to be applied that many
+ times to get to the necessary object.
++
+The default value for --window is 10 and --depth is 50. The maximum
+depth is 4095.
+
+--window-memory=<n>::
+ This option provides an additional limit on top of `--window`;
+ the window size will dynamically scale down so as to not take
+ up more than '<n>' bytes in memory. This is useful in
+ repositories with a mix of large and small objects to not run
+ out of memory with a large window, but still be able to take
+ advantage of the large window for the smaller objects. The
+ size can be suffixed with "k", "m", or "g".
+ `--window-memory=0` makes memory usage unlimited. The default
+ is taken from the `pack.windowMemory` configuration variable.
+
+--max-pack-size=<n>::
+ In unusual scenarios, you may not be able to create files
+ larger than a certain size on your filesystem, and this option
+ can be used to tell the command to split the output packfile
+ into multiple independent packfiles, each not larger than the
+ given size. The size can be suffixed with
+ "k", "m", or "g". The minimum size allowed is limited to 1 MiB.
+ The default is unlimited, unless the config variable
+ `pack.packSizeLimit` is set. Note that this option may result in
+ a larger and slower repository; see the discussion in
+ `pack.packSizeLimit`.
+
+--honor-pack-keep::
+ This flag causes an object already in a local pack that
+ has a .keep file to be ignored, even if it would have
+ otherwise been packed.
+
+--keep-pack=<pack-name>::
+ This flag causes an object already in the given pack to be
+ ignored, even if it would have otherwise been
+ packed. `<pack-name>` is the pack file name without
+ leading directory (e.g. `pack-123.pack`). The option could be
+ specified multiple times to keep multiple packs.
+
+--incremental::
+ This flag causes an object already in a pack to be ignored
+ even if it would have otherwise been packed.
+
+--local::
+ This flag causes an object that is borrowed from an alternate
+ object store to be ignored even if it would have otherwise been
+ packed.
+
+--non-empty::
+ Only create a packed archive if it would contain at
+ least one object.
+
+--progress::
+ Progress status is reported on the standard error stream
+ by default when it is attached to a terminal, unless -q
+ is specified. This flag forces progress status even if
+ the standard error stream is not directed to a terminal.
+
+--all-progress::
+ When --stdout is specified then progress report is
+ displayed during the object count and compression phases
+ but inhibited during the write-out phase. The reason is
+ that in some cases the output stream is directly linked
+ to another command which may wish to display progress
+ status of its own as it processes incoming pack data.
+ This flag is like --progress except that it forces progress
+ report for the write-out phase as well even if --stdout is
+ used.
+
+--all-progress-implied::
+ This is used to imply --all-progress whenever progress display
+ is activated. Unlike --all-progress this flag doesn't actually
+ force any progress display by itself.
+
+-q::
+ This flag makes the command not to report its progress
+ on the standard error stream.
+
+--no-reuse-delta::
+ When creating a packed archive in a repository that
+ has existing packs, the command reuses existing deltas.
+ This sometimes results in a slightly suboptimal pack.
+ This flag tells the command not to reuse existing deltas
+ but compute them from scratch.
+
+--no-reuse-object::
+ This flag tells the command not to reuse existing object data at all,
+ including non deltified object, forcing recompression of everything.
+ This implies --no-reuse-delta. Useful only in the obscure case where
+ wholesale enforcement of a different compression level on the
+ packed data is desired.
+
+--compression=<n>::
+ Specifies compression level for newly-compressed data in the
+ generated pack. If not specified, pack compression level is
+ determined first by pack.compression, then by core.compression,
+ and defaults to -1, the zlib default, if neither is set.
+ Add --no-reuse-object if you want to force a uniform compression
+ level on all data no matter the source.
+
+--[no-]sparse::
+ Toggle the "sparse" algorithm to determine which objects to include in
+ the pack, when combined with the "--revs" option. This algorithm
+ only walks trees that appear in paths that introduce new objects.
+ This can have significant performance benefits when computing
+ a pack to send a small change. However, it is possible that extra
+ objects are added to the pack-file if the included commits contain
+ certain types of direct renames. If this option is not included,
+ it defaults to the value of `pack.useSparse`, which is true unless
+ otherwise specified.
+
+--thin::
+ Create a "thin" pack by omitting the common objects between a
+ sender and a receiver in order to reduce network transfer. This
+ option only makes sense in conjunction with --stdout.
++
+Note: A thin pack violates the packed archive format by omitting
+required objects and is thus unusable by Git without making it
+self-contained. Use `git index-pack --fix-thin`
+(see linkgit:git-index-pack[1]) to restore the self-contained property.
+
+--shallow::
+ Optimize a pack that will be provided to a client with a shallow
+ repository. This option, combined with --thin, can result in a
+ smaller pack at the cost of speed.
+
+--delta-base-offset::
+ A packed archive can express the base object of a delta as
+ either a 20-byte object name or as an offset in the
+ stream, but ancient versions of Git don't understand the
+ latter. By default, 'git pack-objects' only uses the
+ former format for better compatibility. This option
+ allows the command to use the latter format for
+ compactness. Depending on the average delta chain
+ length, this option typically shrinks the resulting
+ packfile by 3-5 per-cent.
++
+Note: Porcelain commands such as `git gc` (see linkgit:git-gc[1]),
+`git repack` (see linkgit:git-repack[1]) pass this option by default
+in modern Git when they put objects in your repository into pack files.
+So does `git bundle` (see linkgit:git-bundle[1]) when it creates a bundle.
+
+--threads=<n>::
+ Specifies the number of threads to spawn when searching for best
+ delta matches. This requires that pack-objects be compiled with
+ pthreads otherwise this option is ignored with a warning.
+ This is meant to reduce packing time on multiprocessor machines.
+ The required amount of memory for the delta search window is
+ however multiplied by the number of threads.
+ Specifying 0 will cause Git to auto-detect the number of CPU's
+ and set the number of threads accordingly.
+
+--index-version=<version>[,<offset>]::
+ This is intended to be used by the test suite only. It allows
+ to force the version for the generated pack index, and to force
+ 64-bit index entries on objects located above the given offset.
+
+--keep-true-parents::
+ With this option, parents that are hidden by grafts are packed
+ nevertheless.
+
+--filter=<filter-spec>::
+ Omits certain objects (usually blobs) from the resulting
+ packfile. See linkgit:git-rev-list[1] for valid
+ `<filter-spec>` forms.
+
+--no-filter::
+ Turns off any previous `--filter=` argument.
+
+--missing=<missing-action>::
+ A debug option to help with future "partial clone" development.
+ This option specifies how missing objects are handled.
++
+The form '--missing=error' requests that pack-objects stop with an error if
+a missing object is encountered. If the repository is a partial clone, an
+attempt to fetch missing objects will be made before declaring them missing.
+This is the default action.
++
+The form '--missing=allow-any' will allow object traversal to continue
+if a missing object is encountered. No fetch of a missing object will occur.
+Missing objects will silently be omitted from the results.
++
+The form '--missing=allow-promisor' is like 'allow-any', but will only
+allow object traversal to continue for EXPECTED promisor missing objects.
+No fetch of a missing object will occur. An unexpected missing object will
+raise an error.
+
+--exclude-promisor-objects::
+ Omit objects that are known to be in the promisor remote. (This
+ option has the purpose of operating only on locally created objects,
+ so that when we repack, we still maintain a distinction between
+ locally created objects [without .promisor] and objects from the
+ promisor remote [with .promisor].) This is used with partial clone.
+
+--keep-unreachable::
+ Objects unreachable from the refs in packs named with
+ --unpacked= option are added to the resulting pack, in
+ addition to the reachable objects that are not in packs marked
+ with *.keep files. This implies `--revs`.
+
+--pack-loose-unreachable::
+ Pack unreachable loose objects (and their loose counterparts
+ removed). This implies `--revs`.
+
+--unpack-unreachable::
+ Keep unreachable objects in loose form. This implies `--revs`.
+
+--delta-islands::
+ Restrict delta matches based on "islands". See DELTA ISLANDS
+ below.
+
+--name-hash-version=<n>::
+ While performing delta compression, Git groups objects that may be
+ similar based on heuristics using the path to that object. While
+ grouping objects by an exact path match is good for paths with
+ many versions, there are benefits for finding delta pairs across
+ different full paths. Git collects objects by type and then by a
+ "name hash" of the path and then by size, hoping to group objects
+ that will compress well together.
++
+The default name hash version is `1`, which prioritizes hash locality by
+considering the final bytes of the path as providing the maximum magnitude
+to the hash function. This version excels at distinguishing short paths
+and finding renames across directories. However, the hash function depends
+primarily on the final 16 bytes of the path. If there are many paths in
+the repo that have the same final 16 bytes and differ only by parent
+directory, then this name-hash may lead to too many collisions and cause
+poor results. At the moment, this version is required when writing
+reachability bitmap files with `--write-bitmap-index`.
++
+The name hash version `2` has similar locality features as version `1`,
+except it considers each path component separately and overlays the hashes
+with a shift. This still prioritizes the final bytes of the path, but also
+"salts" the lower bits of the hash using the parent directory names. This
+method allows for some of the locality benefits of version `1` while
+breaking most of the collisions from a similarly-named file appearing in
+many different directories. At the moment, this version is not allowed
+when writing reachability bitmap files with `--write-bitmap-index` and it
+will be automatically changed to version `1`.
+
+
+DELTA ISLANDS
+-------------
+
+When possible, `pack-objects` tries to reuse existing on-disk deltas to
+avoid having to search for new ones on the fly. This is an important
+optimization for serving fetches, because it means the server can avoid
+inflating most objects at all and just send the bytes directly from
+disk. This optimization can't work when an object is stored as a delta
+against a base which the receiver does not have (and which we are not
+already sending). In that case the server "breaks" the delta and has to
+find a new one, which has a high CPU cost. Therefore it's important for
+performance that the set of objects in on-disk delta relationships match
+what a client would fetch.
+
+In a normal repository, this tends to work automatically. The objects
+are mostly reachable from the branches and tags, and that's what clients
+fetch. Any deltas we find on the server are likely to be between objects
+the client has or will have.
+
+But in some repository setups, you may have several related but separate
+groups of ref tips, with clients tending to fetch those groups
+independently. For example, imagine that you are hosting several "forks"
+of a repository in a single shared object store, and letting clients
+view them as separate repositories through `GIT_NAMESPACE` or separate
+repos using the alternates mechanism. A naive repack may find that the
+optimal delta for an object is against a base that is only found in
+another fork. But when a client fetches, they will not have the base
+object, and we'll have to find a new delta on the fly.
+
+A similar situation may exist if you have many refs outside of
+`refs/heads/` and `refs/tags/` that point to related objects (e.g.,
+`refs/pull` or `refs/changes` used by some hosting providers). By
+default, clients fetch only heads and tags, and deltas against objects
+found only in those other groups cannot be sent as-is.
+
+Delta islands solve this problem by allowing you to group your refs into
+distinct "islands". Pack-objects computes which objects are reachable
+from which islands, and refuses to make a delta from an object `A`
+against a base which is not present in all of `A`'s islands. This
+results in slightly larger packs (because we miss some delta
+opportunities), but guarantees that a fetch of one island will not have
+to recompute deltas on the fly due to crossing island boundaries.
+
+When repacking with delta islands the delta window tends to get
+clogged with candidates that are forbidden by the config. Repacking
+with a big --window helps (and doesn't take as long as it otherwise
+might because we can reject some object pairs based on islands before
+doing any computation on the content).
+
+Islands are configured via the `pack.island` option, which can be
+specified multiple times. Each value is a left-anchored regular
+expressions matching refnames. For example:
+
+-------------------------------------------
+[pack]
+island = refs/heads/
+island = refs/tags/
+-------------------------------------------
+
+puts heads and tags into an island (whose name is the empty string; see
+below for more on naming). Any refs which do not match those regular
+expressions (e.g., `refs/pull/123`) is not in any island. Any object
+which is reachable only from `refs/pull/` (but not heads or tags) is
+therefore not a candidate to be used as a base for `refs/heads/`.
+
+Refs are grouped into islands based on their "names", and two regexes
+that produce the same name are considered to be in the same
+island. The names are computed from the regexes by concatenating any
+capture groups from the regex, with a '-' dash in between. (And if
+there are no capture groups, then the name is the empty string, as in
+the above example.) This allows you to create arbitrary numbers of
+islands. Only up to 14 such capture groups are supported though.
+
+For example, imagine you store the refs for each fork in
+`refs/virtual/ID`, where `ID` is a numeric identifier. You might then
+configure:
+
+-------------------------------------------
+[pack]
+island = refs/virtual/([0-9]+)/heads/
+island = refs/virtual/([0-9]+)/tags/
+island = refs/virtual/([0-9]+)/(pull)/
+-------------------------------------------
+
+That puts the heads and tags for each fork in their own island (named
+"1234" or similar), and the pull refs for each go into their own
+"1234-pull".
+
+Note that we pick a single island for each regex to go into, using "last
+one wins" ordering (which allows repo-specific config to take precedence
+over user-wide config, and so forth).
+
+
+CONFIGURATION
+-------------
+
+Various configuration variables affect packing, see
+linkgit:git-config[1] (search for "pack" and "delta").
+
+Notably, delta compression is not used on objects larger than the
+`core.bigFileThreshold` configuration variable and on files with the
+attribute `delta` set to false.
+
+SEE ALSO
+--------
+linkgit:git-rev-list[1]
+linkgit:git-repack[1]
+linkgit:git-prune-packed[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-pack-redundant.adoc b/git-pack-redundant.adoc
new file mode 100644
index 0000000..13c3eb5
--- /dev/null
+++ b/git-pack-redundant.adoc
@@ -0,0 +1,64 @@
+git-pack-redundant(1)
+=====================
+
+NAME
+----
+git-pack-redundant - Find redundant pack files
+
+
+SYNOPSIS
+--------
+[verse]
+'git pack-redundant' [--verbose] [--alt-odb] (--all | <pack-filename>...)
+
+WARNING
+-------
+`git pack-redundant` has been deprecated and is scheduled for removal in
+a future version of Git. Because it can only remove entire duplicate
+packs and not individual duplicate objects, it is generally not a useful
+tool for reducing repository size. You are better off using `git gc` to
+do so, which will put objects into a new pack, removing duplicates.
+
+Running `pack-redundant` without the `--i-still-use-this` flag will fail
+in this release. If you believe you have a use case for which
+`pack-redundant` is better suited and oppose this removal, please
+contact the Git mailing list at git@vger.kernel.org. More information
+about the list is available at https://git-scm.com/community.
+
+DESCRIPTION
+-----------
+This program computes which packs in your repository
+are redundant. The output is suitable for piping to
+`xargs rm` if you are in the root of the repository.
+
+'git pack-redundant' accepts a list of objects on standard input. Any objects
+given will be ignored when checking which packs are required. This makes the
+following command useful when wanting to remove packs which contain unreachable
+objects.
+
+git fsck --full --unreachable | cut -d ' ' -f3 | \
+git pack-redundant --all | xargs rm
+
+OPTIONS
+-------
+
+
+--all::
+ Processes all packs. Any filenames on the command line are ignored.
+
+--alt-odb::
+ Don't require objects present in packs from alternate object
+ database (odb) directories to be present in local packs.
+
+--verbose::
+ Outputs some statistics to stderr. Has a small performance penalty.
+
+SEE ALSO
+--------
+linkgit:git-pack-objects[1]
+linkgit:git-repack[1]
+linkgit:git-prune-packed[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-pack-refs.adoc b/git-pack-refs.adoc
new file mode 100644
index 0000000..2dcabaf
--- /dev/null
+++ b/git-pack-refs.adoc
@@ -0,0 +1,109 @@
+git-pack-refs(1)
+================
+
+NAME
+----
+git-pack-refs - Pack heads and tags for efficient repository access
+
+SYNOPSIS
+--------
+[verse]
+'git pack-refs' [--all] [--no-prune] [--auto] [--include <pattern>] [--exclude <pattern>]
+
+DESCRIPTION
+-----------
+
+Traditionally, tips of branches and tags (collectively known as
+'refs') were stored one file per ref in a (sub)directory
+under `$GIT_DIR/refs`
+directory. While many branch tips tend to be updated often,
+most tags and some branch tips are never updated. When a
+repository has hundreds or thousands of tags, this
+one-file-per-ref format both wastes storage and hurts
+performance.
+
+This command is used to solve the storage and performance
+problem by storing the refs in a single file,
+`$GIT_DIR/packed-refs`. When a ref is missing from the
+traditional `$GIT_DIR/refs` directory hierarchy, it is looked
+up in this
+file and used if found.
+
+Subsequent updates to branches always create new files under
+`$GIT_DIR/refs` directory hierarchy.
+
+A recommended practice to deal with a repository with too many
+refs is to pack its refs with `--all` once, and
+occasionally run `git pack-refs`. Tags are by
+definition stationary and are not expected to change. Branch
+heads will be packed with the initial `pack-refs --all`, but
+only the currently active branch heads will become unpacked,
+and the next `pack-refs` (without `--all`) will leave them
+unpacked.
+
+
+OPTIONS
+-------
+
+--all::
+
+The command by default packs all tags and refs that are already
+packed, and leaves other refs
+alone. This is because branches are expected to be actively
+developed and packing their tips does not help performance.
+This option causes all refs to be packed as well, with the exception
+of hidden refs, broken refs, and symbolic refs. Useful for a repository
+with many branches of historical interests.
+
+--no-prune::
+
+The command usually removes loose refs under `$GIT_DIR/refs`
+hierarchy after packing them. This option tells it not to.
+
+--auto::
+
+Pack refs as needed depending on the current state of the ref database. The
+behavior depends on the ref format used by the repository and may change in the
+future.
++
+ - "files": No special handling for `--auto` has been implemented.
++
+ - "reftable": Tables are compacted such that they form a geometric
+ sequence. For two tables N and N+1, where N+1 is newer, this
+ maintains the property that N is at least twice as big as N+1. Only
+ tables that violate this property are compacted.
+
+--include <pattern>::
+
+Pack refs based on a `glob(7)` pattern. Repetitions of this option
+accumulate inclusion patterns. If a ref is both included in `--include` and
+`--exclude`, `--exclude` takes precedence. Using `--include` will preclude all
+tags from being included by default. Symbolic refs and broken refs will never
+be packed. When used with `--all`, it will be a noop. Use `--no-include` to clear
+and reset the list of patterns.
+
+--exclude <pattern>::
+
+Do not pack refs matching the given `glob(7)` pattern. Repetitions of this option
+accumulate exclusion patterns. Use `--no-exclude` to clear and reset the list of
+patterns. If a ref is already packed, including it with `--exclude` will not
+unpack it.
+
+When used with `--all`, pack only loose refs which do not match any of
+the provided `--exclude` patterns.
+
+When used with `--include`, refs provided to `--include`, minus refs that are
+provided to `--exclude` will be packed.
+
+
+BUGS
+----
+
+Older documentation written before the packed-refs mechanism was
+introduced may still say things like ".git/refs/heads/<branch> file
+exists" when it means "branch <branch> exists".
+
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-patch-id.adoc b/git-patch-id.adoc
new file mode 100644
index 0000000..1d15fa4
--- /dev/null
+++ b/git-patch-id.adoc
@@ -0,0 +1,69 @@
+git-patch-id(1)
+===============
+
+NAME
+----
+git-patch-id - Compute unique ID for a patch
+
+SYNOPSIS
+--------
+[verse]
+'git patch-id' [--stable | --unstable | --verbatim]
+
+DESCRIPTION
+-----------
+Read a patch from the standard input and compute the patch ID for it.
+
+A "patch ID" is nothing but a sum of SHA-1 of the file diffs associated with a
+patch, with line numbers ignored. As such, it's "reasonably stable", but at
+the same time also reasonably unique, i.e., two patches that have the same
+"patch ID" are almost guaranteed to be the same thing.
+
+The main usecase for this command is to look for likely duplicate commits.
+
+When dealing with 'git diff-tree' output, it takes advantage of
+the fact that the patch is prefixed with the object name of the
+commit, and outputs two 40-byte hexadecimal strings. The first
+string is the patch ID, and the second string is the commit ID.
+This can be used to make a mapping from patch ID to commit ID.
+
+OPTIONS
+-------
+
+--verbatim::
+ Calculate the patch-id of the input as it is given, do not strip
+ any whitespace.
+
+ This is the default if patchid.verbatim is true.
+
+--stable::
+ Use a "stable" sum of hashes as the patch ID. With this option:
+ - Reordering file diffs that make up a patch does not affect the ID.
+ In particular, two patches produced by comparing the same two trees
+ with two different settings for "-O<orderfile>" result in the same
+ patch ID signature, thereby allowing the computed result to be used
+ as a key to index some meta-information about the change between
+ the two trees;
+
+ - Result is different from the value produced by git 1.9 and older
+ or produced when an "unstable" hash (see --unstable below) is
+ configured - even when used on a diff output taken without any use
+ of "-O<orderfile>", thereby making existing databases storing such
+ "unstable" or historical patch-ids unusable.
+
+ - All whitespace within the patch is ignored and does not affect the id.
+
+ This is the default if patchid.stable is set to true.
+
+--unstable::
+ Use an "unstable" hash as the patch ID. With this option,
+ the result produced is compatible with the patch-id value produced
+ by git 1.9 and older and whitespace is ignored. Users with pre-existing
+ databases storing patch-ids produced by git 1.9 and older (who do not deal
+ with reordered patches) may want to use this option.
+
+ This is the default.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-prune-packed.adoc b/git-prune-packed.adoc
new file mode 100644
index 0000000..db742dc
--- /dev/null
+++ b/git-prune-packed.adoc
@@ -0,0 +1,47 @@
+git-prune-packed(1)
+===================
+
+NAME
+----
+git-prune-packed - Remove extra objects that are already in pack files
+
+
+SYNOPSIS
+--------
+[verse]
+'git prune-packed' [-n | --dry-run] [-q | --quiet]
+
+
+DESCRIPTION
+-----------
+This program searches the `$GIT_OBJECT_DIRECTORY` for all objects that currently
+exist in a pack file as well as in the independent object directories.
+
+All such extra objects are removed.
+
+A pack is a collection of objects, individually compressed, with delta
+compression applied, stored in a single file, with an associated index file.
+
+Packs are used to reduce the load on mirror systems, backup engines,
+disk storage, etc.
+
+
+OPTIONS
+-------
+-n::
+--dry-run::
+ Don't actually remove any objects, only show those that would have been
+ removed.
+
+-q::
+--quiet::
+ Squelch the progress indicator.
+
+SEE ALSO
+--------
+linkgit:git-pack-objects[1]
+linkgit:git-repack[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-prune.adoc b/git-prune.adoc
new file mode 100644
index 0000000..9a45571
--- /dev/null
+++ b/git-prune.adoc
@@ -0,0 +1,89 @@
+git-prune(1)
+============
+
+NAME
+----
+git-prune - Prune all unreachable objects from the object database
+
+
+SYNOPSIS
+--------
+[verse]
+'git prune' [-n] [-v] [--progress] [--expire <time>] [--] [<head>...]
+
+DESCRIPTION
+-----------
+
+NOTE: In most cases, users should run 'git gc', which calls
+'git prune'. See the section "NOTES", below.
+
+This runs 'git fsck --unreachable' using all the refs
+available in `refs/`, optionally with an additional set of
+objects specified on the command line, and prunes all unpacked
+objects unreachable from any of these head objects from the object database.
+In addition, it
+prunes the unpacked objects that are also found in packs by
+running 'git prune-packed'.
+It also removes entries from .git/shallow that are not reachable by
+any ref.
+
+Note that unreachable, packed objects will remain. If this is
+not desired, see linkgit:git-repack[1].
+
+OPTIONS
+-------
+
+-n::
+--dry-run::
+ Do not remove anything; just report what it would
+ remove.
+
+-v::
+--verbose::
+ Report all removed objects.
+
+--progress::
+ Show progress.
+
+--expire <time>::
+ Only expire loose objects older than <time>.
+
+\--::
+ Do not interpret any more arguments as options.
+
+<head>...::
+ In addition to objects
+ reachable from any of our references, keep objects
+ reachable from listed <head>s.
+
+EXAMPLES
+--------
+
+To prune objects not used by your repository or another that
+borrows from your repository via its
+`.git/objects/info/alternates`:
+
+------------
+$ git prune $(cd ../another && git rev-parse --all)
+------------
+
+NOTES
+-----
+
+In most cases, users will not need to call 'git prune' directly, but
+should instead call 'git gc', which handles pruning along with
+many other housekeeping tasks.
+
+For a description of which objects are considered for pruning, see
+'git fsck''s --unreachable option.
+
+SEE ALSO
+--------
+
+linkgit:git-fsck[1],
+linkgit:git-gc[1],
+linkgit:git-reflog[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-pull.adoc b/git-pull.adoc
new file mode 100644
index 0000000..3f4ecc4
--- /dev/null
+++ b/git-pull.adoc
@@ -0,0 +1,254 @@
+git-pull(1)
+===========
+
+NAME
+----
+git-pull - Fetch from and integrate with another repository or a local branch
+
+
+SYNOPSIS
+--------
+[verse]
+'git pull' [<options>] [<repository> [<refspec>...]]
+
+
+DESCRIPTION
+-----------
+
+Incorporates changes from a remote repository into the current branch.
+If the current branch is behind the remote, then by default it will
+fast-forward the current branch to match the remote. If the current
+branch and the remote have diverged, the user needs to specify how to
+reconcile the divergent branches with `--rebase` or `--no-rebase` (or
+the corresponding configuration option in `pull.rebase`).
+
+More precisely, `git pull` runs `git fetch` with the given parameters
+and then depending on configuration options or command line flags,
+will call either `git rebase` or `git merge` to reconcile diverging
+branches.
+
+<repository> should be the name of a remote repository as
+passed to linkgit:git-fetch[1]. <refspec> can name an
+arbitrary remote ref (for example, the name of a tag) or even
+a collection of refs with corresponding remote-tracking branches
+(e.g., refs/heads/{asterisk}:refs/remotes/origin/{asterisk}),
+but usually it is the name of a branch in the remote repository.
+
+Default values for <repository> and <branch> are read from the
+"remote" and "merge" configuration for the current branch
+as set by linkgit:git-branch[1] `--track`.
+
+Assume the following history exists and the current branch is
+"`master`":
+
+------------
+ A---B---C master on origin
+ /
+ D---E---F---G master
+ ^
+ origin/master in your repository
+------------
+
+Then "`git pull`" will fetch and replay the changes from the remote
+`master` branch since it diverged from the local `master` (i.e., `E`)
+until its current commit (`C`) on top of `master` and record the
+result in a new commit along with the names of the two parent commits
+and a log message from the user describing the changes.
+
+------------
+ A---B---C origin/master
+ / \
+ D---E---F---G---H master
+------------
+
+See linkgit:git-merge[1] for details, including how conflicts
+are presented and handled.
+
+In Git 1.7.0 or later, to cancel a conflicting merge, use
+`git reset --merge`. *Warning*: In older versions of Git, running 'git pull'
+with uncommitted changes is discouraged: while possible, it leaves you
+in a state that may be hard to back out of in the case of a conflict.
+
+If any of the remote changes overlap with local uncommitted changes,
+the merge will be automatically canceled and the work tree untouched.
+It is generally best to get any local changes in working order before
+pulling or stash them away with linkgit:git-stash[1].
+
+OPTIONS
+-------
+
+-q::
+--quiet::
+ This is passed to both underlying git-fetch to squelch reporting of
+ during transfer, and underlying git-merge to squelch output during
+ merging.
+
+-v::
+--verbose::
+ Pass --verbose to git-fetch and git-merge.
+
+--[no-]recurse-submodules[=(yes|on-demand|no)]::
+ This option controls if new commits of populated submodules should
+ be fetched, and if the working trees of active submodules should be
+ updated, too (see linkgit:git-fetch[1], linkgit:git-config[1] and
+ linkgit:gitmodules[5]).
++
+If the checkout is done via rebase, local submodule commits are rebased as well.
++
+If the update is done via merge, the submodule conflicts are resolved and checked out.
+
+Options related to merging
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+:git-pull: 1
+
+include::merge-options.adoc[]
+
+-r::
+--rebase[=(false|true|merges|interactive)]::
+ When true, rebase the current branch on top of the upstream
+ branch after fetching. If there is a remote-tracking branch
+ corresponding to the upstream branch and the upstream branch
+ was rebased since last fetched, the rebase uses that information
+ to avoid rebasing non-local changes.
++
+When set to `merges`, rebase using `git rebase --rebase-merges` so that
+the local merge commits are included in the rebase (see
+linkgit:git-rebase[1] for details).
++
+When false, merge the upstream branch into the current branch.
++
+When `interactive`, enable the interactive mode of rebase.
++
+See `pull.rebase`, `branch.<name>.rebase` and `branch.autoSetupRebase` in
+linkgit:git-config[1] if you want to make `git pull` always use
+`--rebase` instead of merging.
++
+[NOTE]
+This is a potentially _dangerous_ mode of operation.
+It rewrites history, which does not bode well when you
+published that history already. Do *not* use this option
+unless you have read linkgit:git-rebase[1] carefully.
+
+--no-rebase::
+ This is shorthand for --rebase=false.
+
+Options related to fetching
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+include::fetch-options.adoc[]
+
+include::pull-fetch-param.adoc[]
+
+include::urls-remotes.adoc[]
+
+include::merge-strategies.adoc[]
+
+DEFAULT BEHAVIOUR
+-----------------
+
+Often people use `git pull` without giving any parameter.
+Traditionally, this has been equivalent to saying `git pull
+origin`. However, when configuration `branch.<name>.remote` is
+present while on branch `<name>`, that value is used instead of
+`origin`.
+
+In order to determine what URL to use to fetch from, the value
+of the configuration `remote.<origin>.url` is consulted
+and if there is not any such variable, the value on the `URL:` line
+in `$GIT_DIR/remotes/<origin>` is used.
+
+In order to determine what remote branches to fetch (and
+optionally store in the remote-tracking branches) when the command is
+run without any refspec parameters on the command line, values
+of the configuration variable `remote.<origin>.fetch` are
+consulted, and if there aren't any, `$GIT_DIR/remotes/<origin>`
+is consulted and its `Pull:` lines are used.
+In addition to the refspec formats described in the OPTIONS
+section, you can have a globbing refspec that looks like this:
+
+------------
+refs/heads/*:refs/remotes/origin/*
+------------
+
+A globbing refspec must have a non-empty RHS (i.e. must store
+what were fetched in remote-tracking branches), and its LHS and RHS
+must end with `/*`. The above specifies that all remote
+branches are tracked using remote-tracking branches in
+`refs/remotes/origin/` hierarchy under the same name.
+
+The rule to determine which remote branch to merge after
+fetching is a bit involved, in order not to break backward
+compatibility.
+
+If explicit refspecs were given on the command
+line of `git pull`, they are all merged.
+
+When no refspec was given on the command line, then `git pull`
+uses the refspec from the configuration or
+`$GIT_DIR/remotes/<origin>`. In such cases, the following
+rules apply:
+
+. If `branch.<name>.merge` configuration for the current
+ branch `<name>` exists, that is the name of the branch at the
+ remote site that is merged.
+
+. If the refspec is a globbing one, nothing is merged.
+
+. Otherwise the remote branch of the first refspec is merged.
+
+
+EXAMPLES
+--------
+
+* Update the remote-tracking branches for the repository
+ you cloned from, then merge one of them into your
+ current branch:
++
+------------------------------------------------
+$ git pull
+$ git pull origin
+------------------------------------------------
++
+Normally the branch merged in is the HEAD of the remote repository,
+but the choice is determined by the branch.<name>.remote and
+branch.<name>.merge options; see linkgit:git-config[1] for details.
+
+* Merge into the current branch the remote branch `next`:
++
+------------------------------------------------
+$ git pull origin next
+------------------------------------------------
++
+This leaves a copy of `next` temporarily in FETCH_HEAD, and
+updates the remote-tracking branch `origin/next`.
+The same can be done by invoking fetch and merge:
++
+------------------------------------------------
+$ git fetch origin
+$ git merge origin/next
+------------------------------------------------
+
+
+If you tried a pull which resulted in complex conflicts and
+would want to start over, you can recover with 'git reset'.
+
+
+include::transfer-data-leaks.adoc[]
+
+BUGS
+----
+Using --recurse-submodules can only fetch new commits in already checked
+out submodules right now. When e.g. upstream added a new submodule in the
+just fetched commits of the superproject the submodule itself cannot be
+fetched, making it impossible to check out that submodule later without
+having to do a fetch again. This is expected to be fixed in a future Git
+version.
+
+SEE ALSO
+--------
+linkgit:git-fetch[1], linkgit:git-merge[1], linkgit:git-config[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-push.adoc b/git-push.adoc
new file mode 100644
index 0000000..d197865
--- /dev/null
+++ b/git-push.adoc
@@ -0,0 +1,709 @@
+git-push(1)
+===========
+
+NAME
+----
+git-push - Update remote refs along with associated objects
+
+
+SYNOPSIS
+--------
+[verse]
+'git push' [--all | --branches | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
+ [--repo=<repository>] [-f | --force] [-d | --delete] [--prune] [-q | --quiet] [-v | --verbose]
+ [-u | --set-upstream] [-o <string> | --push-option=<string>]
+ [--[no-]signed|--signed=(true|false|if-asked)]
+ [--force-with-lease[=<refname>[:<expect>]] [--force-if-includes]]
+ [--no-verify] [<repository> [<refspec>...]]
+
+DESCRIPTION
+-----------
+
+Updates remote refs using local refs, while sending objects
+necessary to complete the given refs.
+
+You can make interesting things happen to a repository
+every time you push into it, by setting up 'hooks' there. See
+documentation for linkgit:git-receive-pack[1].
+
+When the command line does not specify where to push with the
+`<repository>` argument, `branch.*.remote` configuration for the
+current branch is consulted to determine where to push. If the
+configuration is missing, it defaults to 'origin'.
+
+When the command line does not specify what to push with `<refspec>...`
+arguments or `--all`, `--mirror`, `--tags` options, the command finds
+the default `<refspec>` by consulting `remote.*.push` configuration,
+and if it is not found, honors `push.default` configuration to decide
+what to push (See linkgit:git-config[1] for the meaning of `push.default`).
+
+When neither the command-line nor the configuration specifies what to
+push, the default behavior is used, which corresponds to the `simple`
+value for `push.default`: the current branch is pushed to the
+corresponding upstream branch, but as a safety measure, the push is
+aborted if the upstream branch does not have the same name as the
+local one.
+
+
+OPTIONS[[OPTIONS]]
+------------------
+<repository>::
+ The "remote" repository that is the destination of a push
+ operation. This parameter can be either a URL
+ (see the section <<URLS,GIT URLS>> below) or the name
+ of a remote (see the section <<REMOTES,REMOTES>> below).
+
+<refspec>...::
+ Specify what destination ref to update with what source object.
+ The format of a <refspec> parameter is an optional plus
+ `+`, followed by the source object <src>, followed
+ by a colon `:`, followed by the destination ref <dst>.
++
+The <src> is often the name of the branch you would want to push, but
+it can be any arbitrary "SHA-1 expression", such as `master~4` or
+`HEAD` (see linkgit:gitrevisions[7]).
++
+The <dst> tells which ref on the remote side is updated with this
+push. Arbitrary expressions cannot be used here, an actual ref must
+be named.
+If `git push [<repository>]` without any `<refspec>` argument is set to
+update some ref at the destination with `<src>` with
+`remote.<repository>.push` configuration variable, `:<dst>` part can
+be omitted--such a push will update a ref that `<src>` normally updates
+without any `<refspec>` on the command line. Otherwise, missing
+`:<dst>` means to update the same ref as the `<src>`.
++
+If <dst> doesn't start with `refs/` (e.g. `refs/heads/master`) we will
+try to infer where in `refs/*` on the destination <repository> it
+belongs based on the type of <src> being pushed and whether <dst>
+is ambiguous.
++
+--
+* If <dst> unambiguously refers to a ref on the <repository> remote,
+ then push to that ref.
+
+* If <src> resolves to a ref starting with refs/heads/ or refs/tags/,
+ then prepend that to <dst>.
+
+* Other ambiguity resolutions might be added in the future, but for
+ now any other cases will error out with an error indicating what we
+ tried, and depending on the `advice.pushUnqualifiedRefname`
+ configuration (see linkgit:git-config[1]) suggest what refs/
+ namespace you may have wanted to push to.
+
+--
++
+The object referenced by <src> is used to update the <dst> reference
+on the remote side. Whether this is allowed depends on where in
+`refs/*` the <dst> reference lives as described in detail below, in
+those sections "update" means any modifications except deletes, which
+as noted after the next few sections are treated differently.
++
+The `refs/heads/*` namespace will only accept commit objects, and
+updates only if they can be fast-forwarded.
++
+The `refs/tags/*` namespace will accept any kind of object (as
+commits, trees and blobs can be tagged), and any updates to them will
+be rejected.
++
+It's possible to push any type of object to any namespace outside of
+`refs/{tags,heads}/*`. In the case of tags and commits, these will be
+treated as if they were the commits inside `refs/heads/*` for the
+purposes of whether the update is allowed.
++
+I.e. a fast-forward of commits and tags outside `refs/{tags,heads}/*`
+is allowed, even in cases where what's being fast-forwarded is not a
+commit, but a tag object which happens to point to a new commit which
+is a fast-forward of the commit the last tag (or commit) it's
+replacing. Replacing a tag with an entirely different tag is also
+allowed, if it points to the same commit, as well as pushing a peeled
+tag, i.e. pushing the commit that existing tag object points to, or a
+new tag object which an existing commit points to.
++
+Tree and blob objects outside of `refs/{tags,heads}/*` will be treated
+the same way as if they were inside `refs/tags/*`, any update of them
+will be rejected.
++
+All of the rules described above about what's not allowed as an update
+can be overridden by adding an the optional leading `+` to a refspec
+(or using `--force` command line option). The only exception to this
+is that no amount of forcing will make the `refs/heads/*` namespace
+accept a non-commit object. Hooks and configuration can also override
+or amend these rules, see e.g. `receive.denyNonFastForwards` in
+linkgit:git-config[1] and `pre-receive` and `update` in
+linkgit:githooks[5].
++
+Pushing an empty <src> allows you to delete the <dst> ref from the
+remote repository. Deletions are always accepted without a leading `+`
+in the refspec (or `--force`), except when forbidden by configuration
+or hooks. See `receive.denyDeletes` in linkgit:git-config[1] and
+`pre-receive` and `update` in linkgit:githooks[5].
++
+The special refspec `:` (or `+:` to allow non-fast-forward updates)
+directs Git to push "matching" branches: for every branch that exists on
+the local side, the remote side is updated if a branch of the same name
+already exists on the remote side.
++
+`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
+
+--all::
+--branches::
+ Push all branches (i.e. refs under `refs/heads/`); cannot be
+ used with other <refspec>.
+
+--prune::
+ Remove remote branches that don't have a local counterpart. For example
+ a remote branch `tmp` will be removed if a local branch with the same
+ name doesn't exist any more. This also respects refspecs, e.g.
+ `git push --prune remote refs/heads/*:refs/tmp/*` would
+ make sure that remote `refs/tmp/foo` will be removed if `refs/heads/foo`
+ doesn't exist.
+
+--mirror::
+ Instead of naming each ref to push, specifies that all
+ refs under `refs/` (which includes but is not
+ limited to `refs/heads/`, `refs/remotes/`, and `refs/tags/`)
+ be mirrored to the remote repository. Newly created local
+ refs will be pushed to the remote end, locally updated refs
+ will be force updated on the remote end, and deleted refs
+ will be removed from the remote end. This is the default
+ if the configuration option `remote.<remote>.mirror` is
+ set.
+
+-n::
+--dry-run::
+ Do everything except actually send the updates.
+
+--porcelain::
+ Produce machine-readable output. The output status line for each ref
+ will be tab-separated and sent to stdout instead of stderr. The full
+ symbolic names of the refs will be given.
+
+-d::
+--delete::
+ All listed refs are deleted from the remote repository. This is
+ the same as prefixing all refs with a colon.
+
+--tags::
+ All refs under `refs/tags` are pushed, in
+ addition to refspecs explicitly listed on the command
+ line.
+
+--follow-tags::
+ Push all the refs that would be pushed without this option,
+ and also push annotated tags in `refs/tags` that are missing
+ from the remote but are pointing at commit-ish that are
+ reachable from the refs being pushed. This can also be specified
+ with configuration variable `push.followTags`. For more
+ information, see `push.followTags` in linkgit:git-config[1].
+
+--[no-]signed::
+--signed=(true|false|if-asked)::
+ GPG-sign the push request to update refs on the receiving
+ side, to allow it to be checked by the hooks and/or be
+ logged. If `false` or `--no-signed`, no signing will be
+ attempted. If `true` or `--signed`, the push will fail if the
+ server does not support signed pushes. If set to `if-asked`,
+ sign if and only if the server supports signed pushes. The push
+ will also fail if the actual call to `gpg --sign` fails. See
+ linkgit:git-receive-pack[1] for the details on the receiving end.
+
+--[no-]atomic::
+ Use an atomic transaction on the remote side if available.
+ Either all refs are updated, or on error, no refs are updated.
+ If the server does not support atomic pushes the push will fail.
+
+-o <option>::
+--push-option=<option>::
+ Transmit the given string to the server, which passes them to
+ the pre-receive as well as the post-receive hook. The given string
+ must not contain a NUL or LF character.
+ When multiple `--push-option=<option>` are given, they are
+ all sent to the other side in the order listed on the
+ command line.
+ When no `--push-option=<option>` is given from the command
+ line, the values of configuration variable `push.pushOption`
+ are used instead.
+
+--receive-pack=<git-receive-pack>::
+--exec=<git-receive-pack>::
+ Path to the 'git-receive-pack' program on the remote
+ end. Sometimes useful when pushing to a remote
+ repository over ssh, and you do not have the program in
+ a directory on the default $PATH.
+
+--[no-]force-with-lease::
+--force-with-lease=<refname>::
+--force-with-lease=<refname>:<expect>::
+ Usually, "git push" refuses to update a remote ref that is
+ not an ancestor of the local ref used to overwrite it.
++
+This option overrides this restriction if the current value of the
+remote ref is the expected value. "git push" fails otherwise.
++
+Imagine that you have to rebase what you have already published.
+You will have to bypass the "must fast-forward" rule in order to
+replace the history you originally published with the rebased history.
+If somebody else built on top of your original history while you are
+rebasing, the tip of the branch at the remote may advance with their
+commit, and blindly pushing with `--force` will lose their work.
++
+This option allows you to say that you expect the history you are
+updating is what you rebased and want to replace. If the remote ref
+still points at the commit you specified, you can be sure that no
+other people did anything to the ref. It is like taking a "lease" on
+the ref without explicitly locking it, and the remote ref is updated
+only if the "lease" is still valid.
++
+`--force-with-lease` alone, without specifying the details, will protect
+all remote refs that are going to be updated by requiring their
+current value to be the same as the remote-tracking branch we have
+for them.
++
+`--force-with-lease=<refname>`, without specifying the expected value, will
+protect the named ref (alone), if it is going to be updated, by
+requiring its current value to be the same as the remote-tracking
+branch we have for it.
++
+`--force-with-lease=<refname>:<expect>` will protect the named ref (alone),
+if it is going to be updated, by requiring its current value to be
+the same as the specified value `<expect>` (which is allowed to be
+different from the remote-tracking branch we have for the refname,
+or we do not even have to have such a remote-tracking branch when
+this form is used). If `<expect>` is the empty string, then the named ref
+must not already exist.
++
+Note that all forms other than `--force-with-lease=<refname>:<expect>`
+that specifies the expected current value of the ref explicitly are
+still experimental and their semantics may change as we gain experience
+with this feature.
++
+"--no-force-with-lease" will cancel all the previous --force-with-lease on the
+command line.
++
+A general note on safety: supplying this option without an expected
+value, i.e. as `--force-with-lease` or `--force-with-lease=<refname>`
+interacts very badly with anything that implicitly runs `git fetch` on
+the remote to be pushed to in the background, e.g. `git fetch origin`
+on your repository in a cronjob.
++
+The protection it offers over `--force` is ensuring that subsequent
+changes your work wasn't based on aren't clobbered, but this is
+trivially defeated if some background process is updating refs in the
+background. We don't have anything except the remote tracking info to
+go by as a heuristic for refs you're expected to have seen & are
+willing to clobber.
++
+If your editor or some other system is running `git fetch` in the
+background for you a way to mitigate this is to simply set up another
+remote:
++
+ git remote add origin-push $(git config remote.origin.url)
+ git fetch origin-push
++
+Now when the background process runs `git fetch origin` the references
+on `origin-push` won't be updated, and thus commands like:
++
+ git push --force-with-lease origin-push
++
+Will fail unless you manually run `git fetch origin-push`. This method
+is of course entirely defeated by something that runs `git fetch
+--all`, in that case you'd need to either disable it or do something
+more tedious like:
++
+ git fetch # update 'master' from remote
+ git tag base master # mark our base point
+ git rebase -i master # rewrite some commits
+ git push --force-with-lease=master:base master:master
++
+I.e. create a `base` tag for versions of the upstream code that you've
+seen and are willing to overwrite, then rewrite history, and finally
+force push changes to `master` if the remote version is still at
+`base`, regardless of what your local `remotes/origin/master` has been
+updated to in the background.
++
+Alternatively, specifying `--force-if-includes` as an ancillary option
+along with `--force-with-lease[=<refname>]` (i.e., without saying what
+exact commit the ref on the remote side must be pointing at, or which
+refs on the remote side are being protected) at the time of "push" will
+verify if updates from the remote-tracking refs that may have been
+implicitly updated in the background are integrated locally before
+allowing a forced update.
+
+-f::
+--force::
+ Usually, the command refuses to update a remote ref that is
+ not an ancestor of the local ref used to overwrite it.
+ Also, when `--force-with-lease` option is used, the command refuses
+ to update a remote ref whose current value does not match
+ what is expected.
++
+This flag disables these checks, and can cause the remote repository
+to lose commits; use it with care.
++
+Note that `--force` applies to all the refs that are pushed, hence
+using it with `push.default` set to `matching` or with multiple push
+destinations configured with `remote.*.push` may overwrite refs
+other than the current branch (including local refs that are
+strictly behind their remote counterpart). To force a push to only
+one branch, use a `+` in front of the refspec to push (e.g `git push
+origin +master` to force a push to the `master` branch). See the
+`<refspec>...` section above for details.
+
+--[no-]force-if-includes::
+ Force an update only if the tip of the remote-tracking ref
+ has been integrated locally.
++
+This option enables a check that verifies if the tip of the
+remote-tracking ref is reachable from one of the "reflog" entries of
+the local branch based in it for a rewrite. The check ensures that any
+updates from the remote have been incorporated locally by rejecting the
+forced update if that is not the case.
++
+If the option is passed without specifying `--force-with-lease`, or
+specified along with `--force-with-lease=<refname>:<expect>`, it is
+a "no-op".
++
+Specifying `--no-force-if-includes` disables this behavior.
+
+--repo=<repository>::
+ This option is equivalent to the <repository> argument. If both
+ are specified, the command-line argument takes precedence.
+
+-u::
+--set-upstream::
+ For every branch that is up to date or successfully pushed, add
+ upstream (tracking) reference, used by argument-less
+ linkgit:git-pull[1] and other commands. For more information,
+ see `branch.<name>.merge` in linkgit:git-config[1].
+
+--[no-]thin::
+ These options are passed to linkgit:git-send-pack[1]. A thin transfer
+ significantly reduces the amount of sent data when the sender and
+ receiver share many of the same objects in common. The default is
+ `--thin`.
+
+-q::
+--quiet::
+ Suppress all output, including the listing of updated refs,
+ unless an error occurs. Progress is not reported to the standard
+ error stream.
+
+-v::
+--verbose::
+ Run verbosely.
+
+--progress::
+ Progress status is reported on the standard error stream
+ by default when it is attached to a terminal, unless -q
+ is specified. This flag forces progress status even if the
+ standard error stream is not directed to a terminal.
+
+--no-recurse-submodules::
+--recurse-submodules=check|on-demand|only|no::
+ May be used to make sure all submodule commits used by the
+ revisions to be pushed are available on a remote-tracking branch.
+ If 'check' is used Git will verify that all submodule commits that
+ changed in the revisions to be pushed are available on at least one
+ remote of the submodule. If any commits are missing the push will
+ be aborted and exit with non-zero status. If 'on-demand' is used
+ all submodules that changed in the revisions to be pushed will be
+ pushed. If on-demand was not able to push all necessary revisions it will
+ also be aborted and exit with non-zero status. If 'only' is used all
+ submodules will be pushed while the superproject is left
+ unpushed. A value of 'no' or using `--no-recurse-submodules` can be used
+ to override the push.recurseSubmodules configuration variable when no
+ submodule recursion is required.
++
+When using 'on-demand' or 'only', if a submodule has a
+"push.recurseSubmodules={on-demand,only}" or "submodule.recurse" configuration,
+further recursion will occur. In this case, "only" is treated as "on-demand".
+
+--[no-]verify::
+ Toggle the pre-push hook (see linkgit:githooks[5]). The
+ default is --verify, giving the hook a chance to prevent the
+ push. With --no-verify, the hook is bypassed completely.
+
+-4::
+--ipv4::
+ Use IPv4 addresses only, ignoring IPv6 addresses.
+
+-6::
+--ipv6::
+ Use IPv6 addresses only, ignoring IPv4 addresses.
+
+include::urls-remotes.adoc[]
+
+OUTPUT
+------
+
+The output of "git push" depends on the transport method used; this
+section describes the output when pushing over the Git protocol (either
+locally or via ssh).
+
+The status of the push is output in tabular form, with each line
+representing the status of a single ref. Each line is of the form:
+
+-------------------------------
+ <flag> <summary> <from> -> <to> (<reason>)
+-------------------------------
+
+If --porcelain is used, then each line of the output is of the form:
+
+-------------------------------
+ <flag> \t <from>:<to> \t <summary> (<reason>)
+-------------------------------
+
+The status of up-to-date refs is shown only if --porcelain or --verbose
+option is used.
+
+flag::
+ A single character indicating the status of the ref:
+(space);; for a successfully pushed fast-forward;
+`+`;; for a successful forced update;
+`-`;; for a successfully deleted ref;
+`*`;; for a successfully pushed new ref;
+`!`;; for a ref that was rejected or failed to push; and
+`=`;; for a ref that was up to date and did not need pushing.
+
+summary::
+ For a successfully pushed ref, the summary shows the old and new
+ values of the ref in a form suitable for using as an argument to
+ `git log` (this is `<old>..<new>` in most cases, and
+ `<old>...<new>` for forced non-fast-forward updates).
++
+For a failed update, more details are given:
++
+--
+rejected::
+ Git did not try to send the ref at all, typically because it
+ is not a fast-forward and you did not force the update.
+
+remote rejected::
+ The remote end refused the update. Usually caused by a hook
+ on the remote side, or because the remote repository has one
+ of the following safety options in effect:
+ `receive.denyCurrentBranch` (for pushes to the checked out
+ branch), `receive.denyNonFastForwards` (for forced
+ non-fast-forward updates), `receive.denyDeletes` or
+ `receive.denyDeleteCurrent`. See linkgit:git-config[1].
+
+remote failure::
+ The remote end did not report the successful update of the ref,
+ perhaps because of a temporary error on the remote side, a
+ break in the network connection, or other transient error.
+--
+
+from::
+ The name of the local ref being pushed, minus its
+ `refs/<type>/` prefix. In the case of deletion, the
+ name of the local ref is omitted.
+
+to::
+ The name of the remote ref being updated, minus its
+ `refs/<type>/` prefix.
+
+reason::
+ A human-readable explanation. In the case of successfully pushed
+ refs, no explanation is needed. For a failed ref, the reason for
+ failure is described.
+
+NOTE ABOUT FAST-FORWARDS
+------------------------
+
+When an update changes a branch (or more in general, a ref) that used to
+point at commit A to point at another commit B, it is called a
+fast-forward update if and only if B is a descendant of A.
+
+In a fast-forward update from A to B, the set of commits that the original
+commit A built on top of is a subset of the commits the new commit B
+builds on top of. Hence, it does not lose any history.
+
+In contrast, a non-fast-forward update will lose history. For example,
+suppose you and somebody else started at the same commit X, and you built
+a history leading to commit B while the other person built a history
+leading to commit A. The history looks like this:
+
+----------------
+
+ B
+ /
+ ---X---A
+
+----------------
+
+Further suppose that the other person already pushed changes leading to A
+back to the original repository from which you two obtained the original
+commit X.
+
+The push done by the other person updated the branch that used to point at
+commit X to point at commit A. It is a fast-forward.
+
+But if you try to push, you will attempt to update the branch (that
+now points at A) with commit B. This does _not_ fast-forward. If you did
+so, the changes introduced by commit A will be lost, because everybody
+will now start building on top of B.
+
+The command by default does not allow an update that is not a fast-forward
+to prevent such loss of history.
+
+If you do not want to lose your work (history from X to B) or the work by
+the other person (history from X to A), you would need to first fetch the
+history from the repository, create a history that contains changes done
+by both parties, and push the result back.
+
+You can perform "git pull", resolve potential conflicts, and "git push"
+the result. A "git pull" will create a merge commit C between commits A
+and B.
+
+----------------
+
+ B---C
+ / /
+ ---X---A
+
+----------------
+
+Updating A with the resulting merge commit will fast-forward and your
+push will be accepted.
+
+Alternatively, you can rebase your change between X and B on top of A,
+with "git pull --rebase", and push the result back. The rebase will
+create a new commit D that builds the change between X and B on top of
+A.
+
+----------------
+
+ B D
+ / /
+ ---X---A
+
+----------------
+
+Again, updating A with this commit will fast-forward and your push will be
+accepted.
+
+There is another common situation where you may encounter non-fast-forward
+rejection when you try to push, and it is possible even when you are
+pushing into a repository nobody else pushes into. After you push commit
+A yourself (in the first picture in this section), replace it with "git
+commit --amend" to produce commit B, and you try to push it out, because
+forgot that you have pushed A out already. In such a case, and only if
+you are certain that nobody in the meantime fetched your earlier commit A
+(and started building on top of it), you can run "git push --force" to
+overwrite it. In other words, "git push --force" is a method reserved for
+a case where you do mean to lose history.
+
+
+EXAMPLES
+--------
+
+`git push`::
+ Works like `git push <remote>`, where <remote> is the
+ current branch's remote (or `origin`, if no remote is
+ configured for the current branch).
+
+`git push origin`::
+ Without additional configuration, pushes the current branch to
+ the configured upstream (`branch.<name>.merge` configuration
+ variable) if it has the same name as the current branch, and
+ errors out without pushing otherwise.
++
+The default behavior of this command when no <refspec> is given can be
+configured by setting the `push` option of the remote, or the `push.default`
+configuration variable.
++
+For example, to default to pushing only the current branch to `origin`
+use `git config remote.origin.push HEAD`. Any valid <refspec> (like
+the ones in the examples below) can be configured as the default for
+`git push origin`.
+
+`git push origin :`::
+ Push "matching" branches to `origin`. See
+ <refspec> in the <<OPTIONS,OPTIONS>> section above for a
+ description of "matching" branches.
+
+`git push origin master`::
+ Find a ref that matches `master` in the source repository
+ (most likely, it would find `refs/heads/master`), and update
+ the same ref (e.g. `refs/heads/master`) in `origin` repository
+ with it. If `master` did not exist remotely, it would be
+ created.
+
+`git push origin HEAD`::
+ A handy way to push the current branch to the same name on the
+ remote.
+
+`git push mothership master:satellite/master dev:satellite/dev`::
+ Use the source ref that matches `master` (e.g. `refs/heads/master`)
+ to update the ref that matches `satellite/master` (most probably
+ `refs/remotes/satellite/master`) in the `mothership` repository;
+ do the same for `dev` and `satellite/dev`.
++
+See the section describing `<refspec>...` above for a discussion of
+the matching semantics.
++
+This is to emulate `git fetch` run on the `mothership` using `git
+push` that is run in the opposite direction in order to integrate
+the work done on `satellite`, and is often necessary when you can
+only make connection in one way (i.e. satellite can ssh into
+mothership but mothership cannot initiate connection to satellite
+because the latter is behind a firewall or does not run sshd).
++
+After running this `git push` on the `satellite` machine, you would
+ssh into the `mothership` and run `git merge` there to complete the
+emulation of `git pull` that were run on `mothership` to pull changes
+made on `satellite`.
+
+`git push origin HEAD:master`::
+ Push the current branch to the remote ref matching `master` in the
+ `origin` repository. This form is convenient to push the current
+ branch without thinking about its local name.
+
+`git push origin master:refs/heads/experimental`::
+ Create the branch `experimental` in the `origin` repository
+ by copying the current `master` branch. This form is only
+ needed to create a new branch or tag in the remote repository when
+ the local name and the remote name are different; otherwise,
+ the ref name on its own will work.
+
+`git push origin :experimental`::
+ Find a ref that matches `experimental` in the `origin` repository
+ (e.g. `refs/heads/experimental`), and delete it.
+
+`git push origin +dev:master`::
+ Update the origin repository's master branch with the dev branch,
+ allowing non-fast-forward updates. *This can leave unreferenced
+ commits dangling in the origin repository.* Consider the
+ following situation, where a fast-forward is not possible:
++
+----
+ o---o---o---A---B origin/master
+ \
+ X---Y---Z dev
+----
++
+The above command would change the origin repository to
++
+----
+ A---B (unnamed branch)
+ /
+ o---o---o---X---Y---Z master
+----
++
+Commits A and B would no longer belong to a branch with a symbolic name,
+and so would be unreachable. As such, these commits would be removed by
+a `git gc` command on the origin repository.
+
+include::transfer-data-leaks.adoc[]
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/push.adoc[]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-quiltimport.adoc b/git-quiltimport.adoc
new file mode 100644
index 0000000..40e02d9
--- /dev/null
+++ b/git-quiltimport.adoc
@@ -0,0 +1,64 @@
+git-quiltimport(1)
+==================
+
+NAME
+----
+git-quiltimport - Applies a quilt patchset onto the current branch
+
+
+SYNOPSIS
+--------
+[verse]
+'git quiltimport' [--dry-run | -n] [--author <author>] [--patches <dir>]
+ [--series <file>] [--keep-non-patch]
+
+
+DESCRIPTION
+-----------
+Applies a quilt patchset onto the current Git branch, preserving
+the patch boundaries, patch order, and patch descriptions present
+in the quilt patchset.
+
+For each patch the code attempts to extract the author from the
+patch description. If that fails it falls back to the author
+specified with --author. If the --author flag was not given
+the patch description is displayed and the user is asked to
+interactively enter the author of the patch.
+
+If a subject is not found in the patch description the patch name is
+preserved as the 1 line subject in the Git description.
+
+OPTIONS
+-------
+
+-n::
+--dry-run::
+ Walk through the patches in the series and warn
+ if we cannot find all of the necessary information to commit
+ a patch. At the time of this writing only missing author
+ information is warned about.
+
+--author 'Author Name <Author Email>'::
+ The author name and email address to use when no author
+ information can be found in the patch description.
+
+--patches <dir>::
+ The directory to find the quilt patches.
++
+The default for the patch directory is 'patches'
+or the value of the `$QUILT_PATCHES` environment
+variable.
+
+--series <file>::
+ The quilt series file.
++
+The default for the series file is <patches>/series
+or the value of the `$QUILT_SERIES` environment
+variable.
+
+--keep-non-patch::
+ Pass `-b` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-range-diff.adoc b/git-range-diff.adoc
new file mode 100644
index 0000000..db0e427
--- /dev/null
+++ b/git-range-diff.adoc
@@ -0,0 +1,312 @@
+git-range-diff(1)
+=================
+
+NAME
+----
+git-range-diff - Compare two commit ranges (e.g. two versions of a branch)
+
+SYNOPSIS
+--------
+[verse]
+'git range-diff' [--color=[<when>]] [--no-color] [<diff-options>]
+ [--no-dual-color] [--creation-factor=<factor>]
+ [--left-only | --right-only] [--diff-merges=<format>]
+ [--remerge-diff]
+ ( <range1> <range2> | <rev1>...<rev2> | <base> <rev1> <rev2> )
+ [[--] <path>...]
+
+DESCRIPTION
+-----------
+
+This command shows the differences between two versions of a patch
+series, or more generally, two commit ranges (ignoring merge commits).
+
+In the presence of `<path>` arguments, these commit ranges are limited
+accordingly.
+
+To that end, it first finds pairs of commits from both commit ranges
+that correspond with each other. Two commits are said to correspond when
+the diff between their patches (i.e. the author information, the commit
+message and the commit diff) is reasonably small compared to the
+patches' size. See ``Algorithm`` below for details.
+
+Finally, the list of matching commits is shown in the order of the
+second commit range, with unmatched commits being inserted just after
+all of their ancestors have been shown.
+
+There are three ways to specify the commit ranges:
+
+- `<range1> <range2>`: Either commit range can be of the form
+ `<base>..<rev>`, `<rev>^!` or `<rev>^-<n>`. See `SPECIFYING RANGES`
+ in linkgit:gitrevisions[7] for more details.
+
+- `<rev1>...<rev2>`. This is equivalent to
+ `<rev2>..<rev1> <rev1>..<rev2>`.
+
+- `<base> <rev1> <rev2>`: This is equivalent to `<base>..<rev1>
+ <base>..<rev2>`.
+
+OPTIONS
+-------
+--no-dual-color::
+ When the commit diffs differ, `git range-diff` recreates the
+ original diffs' coloring, and adds outer -/+ diff markers with
+ the *background* being red/green to make it easier to see e.g.
+ when there was a change in what exact lines were added.
++
+Additionally, the commit diff lines that are only present in the first commit
+range are shown "dimmed" (this can be overridden using the `color.diff.<slot>`
+config setting where `<slot>` is one of `contextDimmed`, `oldDimmed` and
+`newDimmed`), and the commit diff lines that are only present in the second
+commit range are shown in bold (which can be overridden using the config
+settings `color.diff.<slot>` with `<slot>` being one of `contextBold`,
+`oldBold` or `newBold`).
++
+This is known to `range-diff` as "dual coloring". Use `--no-dual-color`
+to revert to color all lines according to the outer diff markers
+(and completely ignore the inner diff when it comes to color).
+
+--creation-factor=<percent>::
+ Set the creation/deletion cost fudge factor to `<percent>`.
+ Defaults to 60. Try a larger value if `git range-diff` erroneously
+ considers a large change a total rewrite (deletion of one commit
+ and addition of another), and a smaller one in the reverse case.
+ See the ``Algorithm`` section below for an explanation of why this is
+ needed.
+
+--left-only::
+ Suppress commits that are missing from the first specified range
+ (or the "left range" when using the `<rev1>...<rev2>` format).
+
+--right-only::
+ Suppress commits that are missing from the second specified range
+ (or the "right range" when using the `<rev1>...<rev2>` format).
+
+--diff-merges=<format>::
+ Instead of ignoring merge commits, generate diffs for them using the
+ corresponding `--diff-merges=<format>` option of linkgit:git-log[1],
+ and include them in the comparison.
++
+Note: In the common case, the `remerge` mode will be the most natural one
+to use, as it shows only the diff on top of what Git's merge machinery would
+have produced. In other words, if a merge commit is the result of a
+non-conflicting `git merge`, the `remerge` mode will represent it with an empty
+diff.
+
+--remerge-diff::
+ Convenience option, equivalent to `--diff-merges=remerge`.
+
+--[no-]notes[=<ref>]::
+ This flag is passed to the `git log` program
+ (see linkgit:git-log[1]) that generates the patches.
+
+<range1> <range2>::
+ Compare the commits specified by the two ranges, where
+ `<range1>` is considered an older version of `<range2>`.
+
+<rev1>...<rev2>::
+ Equivalent to passing `<rev2>..<rev1>` and `<rev1>..<rev2>`.
+
+<base> <rev1> <rev2>::
+ Equivalent to passing `<base>..<rev1>` and `<base>..<rev2>`.
+ Note that `<base>` does not need to be the exact branch point
+ of the branches. Example: after rebasing a branch `my-topic`,
+ `git range-diff my-topic@{u} my-topic@{1} my-topic` would
+ show the differences introduced by the rebase.
+
+`git range-diff` also accepts the regular diff options (see
+linkgit:git-diff[1]), most notably the `--color=[<when>]` and
+`--no-color` options. These options are used when generating the "diff
+between patches", i.e. to compare the author, commit message and diff of
+corresponding old/new commits. There is currently no means to tweak most of the
+diff options passed to `git log` when generating those patches.
+
+OUTPUT STABILITY
+----------------
+
+The output of the `range-diff` command is subject to change. It is
+intended to be human-readable porcelain output, not something that can
+be used across versions of Git to get a textually stable `range-diff`
+(as opposed to something like the `--stable` option to
+linkgit:git-patch-id[1]). There's also no equivalent of
+linkgit:git-apply[1] for `range-diff`, the output is not intended to
+be machine-readable.
+
+This is particularly true when passing in diff options. Currently some
+options like `--stat` can, as an emergent effect, produce output
+that's quite useless in the context of `range-diff`. Future versions
+of `range-diff` may learn to interpret such options in a manner
+specific to `range-diff` (e.g. for `--stat` producing human-readable
+output which summarizes how the diffstat changed).
+
+CONFIGURATION
+-------------
+This command uses the `diff.color.*` and `pager.range-diff` settings
+(the latter is on by default).
+See linkgit:git-config[1].
+
+
+EXAMPLES
+--------
+
+When a rebase required merge conflicts to be resolved, compare the changes
+introduced by the rebase directly afterwards using:
+
+------------
+$ git range-diff @{u} @{1} @
+------------
+
+
+A typical output of `git range-diff` would look like this:
+
+------------
+-: ------- > 1: 0ddba11 Prepare for the inevitable!
+1: c0debee = 2: cab005e Add a helpful message at the start
+2: f00dbal ! 3: decafe1 Describe a bug
+ @@ -1,3 +1,3 @@
+ Author: A U Thor <author@example.com>
+
+ -TODO: Describe a bug
+ +Describe a bug
+ @@ -324,5 +324,6
+ This is expected.
+
+ -+What is unexpected is that it will also crash.
+ ++Unexpectedly, it also crashes. This is a bug, and the jury is
+ ++still out there how to fix it best. See ticket #314 for details.
+
+ Contact
+3: bedead < -: ------- TO-UNDO
+------------
+
+In this example, there are 3 old and 3 new commits, where the developer
+removed the 3rd, added a new one before the first two, and modified the
+commit message of the 2nd commit as well as its diff.
+
+When the output goes to a terminal, it is color-coded by default, just
+like regular `git diff`'s output. In addition, the first line (adding a
+commit) is green, the last line (deleting a commit) is red, the second
+line (with a perfect match) is yellow like the commit header of `git
+show`'s output, and the third line colors the old commit red, the new
+one green and the rest like `git show`'s commit header.
+
+A naive color-coded diff of diffs is actually a bit hard to read,
+though, as it colors the entire lines red or green. The line that added
+"What is unexpected" in the old commit, for example, is completely red,
+even if the intent of the old commit was to add something.
+
+To help with that, `range` uses the `--dual-color` mode by default. In
+this mode, the diff of diffs will retain the original diff colors, and
+prefix the lines with -/+ markers that have their *background* red or
+green, to make it more obvious that they describe how the diff itself
+changed.
+
+
+Algorithm
+---------
+
+The general idea is this: we generate a cost matrix between the commits
+in both commit ranges, then solve the least-cost assignment.
+
+The cost matrix is populated thusly: for each pair of commits, both
+diffs are generated and the "diff of diffs" is generated, with 3 context
+lines, then the number of lines in that diff is used as cost.
+
+To avoid false positives (e.g. when a patch has been removed, and an
+unrelated patch has been added between two iterations of the same patch
+series), the cost matrix is extended to allow for that, by adding
+fixed-cost entries for wholesale deletes/adds.
+
+Example: Let commits `1--2` be the first iteration of a patch series and
+`A--C` the second iteration. Let's assume that `A` is a cherry-pick of
+`2,` and `C` is a cherry-pick of `1` but with a small modification (say,
+a fixed typo). Visualize the commits as a bipartite graph:
+
+------------
+ 1 A
+
+ 2 B
+
+ C
+------------
+
+We are looking for a "best" explanation of the new series in terms of
+the old one. We can represent an "explanation" as an edge in the graph:
+
+
+------------
+ 1 A
+ /
+ 2 --------' B
+
+ C
+------------
+
+This explanation comes for "free" because there was no change. Similarly
+`C` could be explained using `1`, but that comes at some cost c>0
+because of the modification:
+
+------------
+ 1 ----. A
+ | /
+ 2 ----+---' B
+ |
+ `----- C
+ c>0
+------------
+
+In mathematical terms, what we are looking for is some sort of a minimum
+cost bipartite matching; `1` is matched to `C` at some cost, etc. The
+underlying graph is in fact a complete bipartite graph; the cost we
+associate with every edge is the size of the diff between the two
+commits' patches. To explain also new commits, we introduce dummy nodes
+on both sides:
+
+------------
+ 1 ----. A
+ | /
+ 2 ----+---' B
+ |
+ o `----- C
+ c>0
+ o o
+
+ o o
+------------
+
+The cost of an edge `o--C` is the size of `C`'s diff, modified by a
+fudge factor that should be smaller than 100%. The cost of an edge
+`o--o` is free. The fudge factor is necessary because even if `1` and
+`C` have nothing in common, they may still share a few empty lines and
+such, possibly making the assignment `1--C`, `o--o` slightly cheaper
+than `1--o`, `o--C` even if `1` and `C` have nothing in common. With the
+fudge factor we require a much larger common part to consider patches as
+corresponding.
+
+The overall time needed to compute this algorithm is the time needed to
+compute n+m commit diffs and then n*m diffs of patches, plus the time
+needed to compute the least-cost assignment between n and m diffs. Git
+uses an implementation of the Jonker-Volgenant algorithm to solve the
+assignment problem, which has cubic runtime complexity. The matching
+found in this case will look like this:
+
+------------
+ 1 ----. A
+ | /
+ 2 ----+---' B
+ .--+-----'
+ o -' `----- C
+ c>0
+ o ---------- o
+
+ o ---------- o
+------------
+
+
+SEE ALSO
+--------
+linkgit:git-log[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-read-tree.adoc b/git-read-tree.adoc
new file mode 100644
index 0000000..1c48c28
--- /dev/null
+++ b/git-read-tree.adoc
@@ -0,0 +1,437 @@
+git-read-tree(1)
+================
+
+NAME
+----
+git-read-tree - Reads tree information into the index
+
+
+SYNOPSIS
+--------
+[verse]
+'git read-tree' [(-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>)
+ [-u | -i]] [--index-output=<file>] [--no-sparse-checkout]
+ (--empty | <tree-ish1> [<tree-ish2> [<tree-ish3>]])
+
+
+DESCRIPTION
+-----------
+Reads the tree information given by <tree-ish> into the index,
+but does not actually *update* any of the files it "caches". (see:
+linkgit:git-checkout-index[1])
+
+Optionally, it can merge a tree into the index, perform a
+fast-forward (i.e. 2-way) merge, or a 3-way merge, with the `-m`
+flag. When used with `-m`, the `-u` flag causes it to also update
+the files in the work tree with the result of the merge.
+
+Only trivial merges are done by 'git read-tree' itself. Only conflicting paths
+will be in an unmerged state when 'git read-tree' returns.
+
+OPTIONS
+-------
+-m::
+ Perform a merge, not just a read. The command will
+ refuse to run if your index file has unmerged entries,
+ indicating that you have not finished a previous merge you
+ started.
+
+--reset::
+ Same as -m, except that unmerged entries are discarded instead
+ of failing. When used with `-u`, updates leading to loss of
+ working tree changes or untracked files or directories will not
+ abort the operation.
+
+-u::
+ After a successful merge, update the files in the work
+ tree with the result of the merge.
+
+-i::
+ Usually a merge requires the index file as well as the
+ files in the working tree to be up to date with the
+ current head commit, in order not to lose local
+ changes. This flag disables the check with the working
+ tree and is meant to be used when creating a merge of
+ trees that are not directly related to the current
+ working tree status into a temporary index file.
+
+-n::
+--dry-run::
+ Check if the command would error out, without updating the index
+ or the files in the working tree for real.
+
+-v::
+ Show the progress of checking files out.
+
+--trivial::
+ Restrict three-way merge by 'git read-tree' to happen
+ only if there is no file-level merging required, instead
+ of resolving merge for trivial cases and leaving
+ conflicting files unresolved in the index.
+
+--aggressive::
+ Usually a three-way merge by 'git read-tree' resolves
+ the merge for really trivial cases and leaves other
+ cases unresolved in the index, so that porcelains can
+ implement different merge policies. This flag makes the
+ command resolve a few more cases internally:
++
+* when one side removes a path and the other side leaves the path
+ unmodified. The resolution is to remove that path.
+* when both sides remove a path. The resolution is to remove that path.
+* when both sides add a path identically. The resolution
+ is to add that path.
+
+--prefix=<prefix>::
+ Keep the current index contents, and read the contents
+ of the named tree-ish under the directory at `<prefix>`.
+ The command will refuse to overwrite entries that already
+ existed in the original index file.
+
+--index-output=<file>::
+ Instead of writing the results out to `$GIT_INDEX_FILE`,
+ write the resulting index in the named file. While the
+ command is operating, the original index file is locked
+ with the same mechanism as usual. The file must allow
+ to be rename(2)ed into from a temporary file that is
+ created next to the usual index file; typically this
+ means it needs to be on the same filesystem as the index
+ file itself, and you need write permission to the
+ directories the index file and index output file are
+ located in.
+
+--[no-]recurse-submodules::
+ Using --recurse-submodules will update the content of all active
+ submodules according to the commit recorded in the superproject by
+ calling read-tree recursively, also setting the submodules' HEAD to be
+ detached at that commit.
+
+--no-sparse-checkout::
+ Disable sparse checkout support even if `core.sparseCheckout`
+ is true.
+
+--empty::
+ Instead of reading tree object(s) into the index, just empty
+ it.
+
+-q::
+--quiet::
+ Quiet, suppress feedback messages.
+
+<tree-ish#>::
+ The id of the tree object(s) to be read/merged.
+
+
+MERGING
+-------
+If `-m` is specified, 'git read-tree' can perform 3 kinds of
+merge, a single tree merge if only 1 tree is given, a
+fast-forward merge with 2 trees, or a 3-way merge if 3 or more trees are
+provided.
+
+
+Single Tree Merge
+~~~~~~~~~~~~~~~~~
+If only 1 tree is specified, 'git read-tree' operates as if the user did not
+specify `-m`, except that if the original index has an entry for a
+given pathname, and the contents of the path match with the tree
+being read, the stat info from the index is used. (In other words, the
+index's stat()s take precedence over the merged tree's).
+
+That means that if you do a `git read-tree -m <newtree>` followed by a
+`git checkout-index -f -u -a`, the 'git checkout-index' only checks out
+the stuff that really changed.
+
+This is used to avoid unnecessary false hits when 'git diff-files' is
+run after 'git read-tree'.
+
+
+Two Tree Merge
+~~~~~~~~~~~~~~
+
+Typically, this is invoked as `git read-tree -m $H $M`, where $H
+is the head commit of the current repository, and $M is the head
+of a foreign tree, which is simply ahead of $H (i.e. we are in a
+fast-forward situation).
+
+When two trees are specified, the user is telling 'git read-tree'
+the following:
+
+ 1. The current index and work tree is derived from $H, but
+ the user may have local changes in them since $H.
+
+ 2. The user wants to fast-forward to $M.
+
+In this case, the `git read-tree -m $H $M` command makes sure
+that no local change is lost as the result of this "merge".
+Here are the "carry forward" rules, where "I" denotes the index,
+"clean" means that index and work tree coincide, and "exists"/"nothing"
+refer to the presence of a path in the specified commit:
+
+....
+ I H M Result
+ -------------------------------------------------------
+ 0 nothing nothing nothing (does not happen)
+ 1 nothing nothing exists use M
+ 2 nothing exists nothing remove path from index
+ 3 nothing exists exists, use M if "initial checkout",
+ H == M keep index otherwise
+ exists, fail
+ H != M
+
+ clean I==H I==M
+ ------------------
+ 4 yes N/A N/A nothing nothing keep index
+ 5 no N/A N/A nothing nothing keep index
+
+ 6 yes N/A yes nothing exists keep index
+ 7 no N/A yes nothing exists keep index
+ 8 yes N/A no nothing exists fail
+ 9 no N/A no nothing exists fail
+
+ 10 yes yes N/A exists nothing remove path from index
+ 11 no yes N/A exists nothing fail
+ 12 yes no N/A exists nothing fail
+ 13 no no N/A exists nothing fail
+
+ clean (H==M)
+ ------
+ 14 yes exists exists keep index
+ 15 no exists exists keep index
+
+ clean I==H I==M (H!=M)
+ ------------------
+ 16 yes no no exists exists fail
+ 17 no no no exists exists fail
+ 18 yes no yes exists exists keep index
+ 19 no no yes exists exists keep index
+ 20 yes yes no exists exists use M
+ 21 no yes no exists exists fail
+....
+
+In all "keep index" cases, the index entry stays as in the
+original index file. If the entry is not up to date,
+'git read-tree' keeps the copy in the work tree intact when
+operating under the -u flag.
+
+When this form of 'git read-tree' returns successfully, you can
+see which of the "local changes" that you made were carried forward by running
+`git diff-index --cached $M`. Note that this does not
+necessarily match what `git diff-index --cached $H` would have
+produced before such a two tree merge. This is because of cases
+18 and 19 -- if you already had the changes in $M (e.g. maybe
+you picked it up via e-mail in a patch form), `git diff-index
+--cached $H` would have told you about the change before this
+merge, but it would not show in `git diff-index --cached $M`
+output after the two-tree merge.
+
+Case 3 is slightly tricky and needs explanation. The result from this
+rule logically should be to remove the path if the user staged the removal
+of the path and then switching to a new branch. That however will prevent
+the initial checkout from happening, so the rule is modified to use M (new
+tree) only when the content of the index is empty. Otherwise the removal
+of the path is kept as long as $H and $M are the same.
+
+3-Way Merge
+~~~~~~~~~~~
+Each "index" entry has two bits worth of "stage" state. stage 0 is the
+normal one, and is the only one you'd see in any kind of normal use.
+
+However, when you do 'git read-tree' with three trees, the "stage"
+starts out at 1.
+
+This means that you can do
+
+----------------
+$ git read-tree -m <tree1> <tree2> <tree3>
+----------------
+
+and you will end up with an index with all of the <tree1> entries in
+"stage1", all of the <tree2> entries in "stage2" and all of the
+<tree3> entries in "stage3". When performing a merge of another
+branch into the current branch, we use the common ancestor tree
+as <tree1>, the current branch head as <tree2>, and the other
+branch head as <tree3>.
+
+Furthermore, 'git read-tree' has special-case logic that says: if you see
+a file that matches in all respects in the following states, it
+"collapses" back to "stage0":
+
+ - stage 2 and 3 are the same; take one or the other (it makes no
+ difference - the same work has been done on our branch in
+ stage 2 and their branch in stage 3)
+
+ - stage 1 and stage 2 are the same and stage 3 is different; take
+ stage 3 (our branch in stage 2 did not do anything since the
+ ancestor in stage 1 while their branch in stage 3 worked on
+ it)
+
+ - stage 1 and stage 3 are the same and stage 2 is different take
+ stage 2 (we did something while they did nothing)
+
+The 'git write-tree' command refuses to write a nonsensical tree, and it
+will complain about unmerged entries if it sees a single entry that is not
+stage 0.
+
+OK, this all sounds like a collection of totally nonsensical rules,
+but it's actually exactly what you want in order to do a fast
+merge. The different stages represent the "result tree" (stage 0, aka
+"merged"), the original tree (stage 1, aka "orig"), and the two trees
+you are trying to merge (stage 2 and 3 respectively).
+
+The order of stages 1, 2 and 3 (hence the order of three
+<tree-ish> command-line arguments) are significant when you
+start a 3-way merge with an index file that is already
+populated. Here is an outline of how the algorithm works:
+
+- if a file exists in identical format in all three trees, it will
+ automatically collapse to "merged" state by 'git read-tree'.
+
+- a file that has _any_ difference what-so-ever in the three trees
+ will stay as separate entries in the index. It's up to "porcelain
+ policy" to determine how to remove the non-0 stages, and insert a
+ merged version.
+
+- the index file saves and restores with all this information, so you
+ can merge things incrementally, but as long as it has entries in
+ stages 1/2/3 (i.e., "unmerged entries") you can't write the result. So
+ now the merge algorithm ends up being really simple:
+
+ * you walk the index in order, and ignore all entries of stage 0,
+ since they've already been done.
+
+ * if you find a "stage1", but no matching "stage2" or "stage3", you
+ know it's been removed from both trees (it only existed in the
+ original tree), and you remove that entry.
+
+ * if you find a matching "stage2" and "stage3" tree, you remove one
+ of them, and turn the other into a "stage0" entry. Remove any
+ matching "stage1" entry if it exists too. .. all the normal
+ trivial rules ..
+
+You would normally use 'git merge-index' with supplied
+'git merge-one-file' to do this last step. The script updates
+the files in the working tree as it merges each path and at the
+end of a successful merge.
+
+When you start a 3-way merge with an index file that is already
+populated, it is assumed that it represents the state of the
+files in your work tree, and you can even have files with
+changes unrecorded in the index file. It is further assumed
+that this state is "derived" from the stage 2 tree. The 3-way
+merge refuses to run if it finds an entry in the original index
+file that does not match stage 2.
+
+This is done to prevent you from losing your work-in-progress
+changes, and mixing your random changes in an unrelated merge
+commit. To illustrate, suppose you start from what has been
+committed last to your repository:
+
+----------------
+$ JC=`git rev-parse --verify "HEAD^0"`
+$ git checkout-index -f -u -a $JC
+----------------
+
+You do random edits, without running 'git update-index'. And then
+you notice that the tip of your "upstream" tree has advanced
+since you pulled from him:
+
+----------------
+$ git fetch git://.... linus
+$ LT=`git rev-parse FETCH_HEAD`
+----------------
+
+Your work tree is still based on your HEAD ($JC), but you have
+some edits since. Three-way merge makes sure that you have not
+added or modified index entries since $JC, and if you haven't,
+then does the right thing. So with the following sequence:
+
+----------------
+$ git read-tree -m -u `git merge-base $JC $LT` $JC $LT
+$ git merge-index git-merge-one-file -a
+$ echo "Merge with Linus" | \
+ git commit-tree `git write-tree` -p $JC -p $LT
+----------------
+
+what you would commit is a pure merge between $JC and $LT without
+your work-in-progress changes, and your work tree would be
+updated to the result of the merge.
+
+However, if you have local changes in the working tree that
+would be overwritten by this merge, 'git read-tree' will refuse
+to run to prevent your changes from being lost.
+
+In other words, there is no need to worry about what exists only
+in the working tree. When you have local changes in a part of
+the project that is not involved in the merge, your changes do
+not interfere with the merge, and are kept intact. When they
+*do* interfere, the merge does not even start ('git read-tree'
+complains loudly and fails without modifying anything). In such
+a case, you can simply continue doing what you were in the
+middle of doing, and when your working tree is ready (i.e. you
+have finished your work-in-progress), attempt the merge again.
+
+
+SPARSE CHECKOUT
+---------------
+
+Note: The skip-worktree capabilities in linkgit:git-update-index[1]
+and `read-tree` predated the introduction of
+linkgit:git-sparse-checkout[1]. Users are encouraged to use the
+`sparse-checkout` command in preference to these plumbing commands for
+sparse-checkout/skip-worktree related needs. However, the information
+below might be useful to users trying to understand the pattern style
+used in non-cone mode of the `sparse-checkout` command.
+
+"Sparse checkout" allows populating the working directory sparsely.
+It uses the skip-worktree bit (see linkgit:git-update-index[1]) to
+tell Git whether a file in the working directory is worth looking at.
+
+'git read-tree' and other merge-based commands ('git merge', 'git
+checkout'...) can help maintaining the skip-worktree bitmap and working
+directory update. `$GIT_DIR/info/sparse-checkout` is used to
+define the skip-worktree reference bitmap. When 'git read-tree' needs
+to update the working directory, it resets the skip-worktree bit in the index
+based on this file, which uses the same syntax as .gitignore files.
+If an entry matches a pattern in this file, or the entry corresponds to
+a file present in the working tree, then skip-worktree will not be
+set on that entry. Otherwise, skip-worktree will be set.
+
+Then it compares the new skip-worktree value with the previous one. If
+skip-worktree turns from set to unset, it will add the corresponding
+file back. If it turns from unset to set, that file will be removed.
+
+While `$GIT_DIR/info/sparse-checkout` is usually used to specify what
+files are in, you can also specify what files are _not_ in, using
+negate patterns. For example, to remove the file `unwanted`:
+
+----------------
+/*
+!unwanted
+----------------
+
+Another tricky thing is fully repopulating the working directory when you
+no longer want sparse checkout. You cannot just disable "sparse
+checkout" because skip-worktree bits are still in the index and your working
+directory is still sparsely populated. You should re-populate the working
+directory with the `$GIT_DIR/info/sparse-checkout` file content as
+follows:
+
+----------------
+/*
+----------------
+
+Then you can disable sparse checkout. Sparse checkout support in 'git
+read-tree' and similar commands is disabled by default. You need to
+turn `core.sparseCheckout` on in order to have sparse checkout
+support.
+
+
+SEE ALSO
+--------
+linkgit:git-write-tree[1], linkgit:git-ls-files[1],
+linkgit:gitignore[5], linkgit:git-sparse-checkout[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-rebase.adoc b/git-rebase.adoc
new file mode 100644
index 0000000..133fe8c
--- /dev/null
+++ b/git-rebase.adoc
@@ -0,0 +1,1304 @@
+git-rebase(1)
+=============
+
+NAME
+----
+git-rebase - Reapply commits on top of another base tip
+
+SYNOPSIS
+--------
+[verse]
+'git rebase' [-i | --interactive] [<options>] [--exec <cmd>]
+ [--onto <newbase> | --keep-base] [<upstream> [<branch>]]
+'git rebase' [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>]
+ --root [<branch>]
+'git rebase' (--continue|--skip|--abort|--quit|--edit-todo|--show-current-patch)
+
+DESCRIPTION
+-----------
+If `<branch>` is specified, `git rebase` will perform an automatic
+`git switch <branch>` before doing anything else. Otherwise
+it remains on the current branch.
+
+If `<upstream>` is not specified, the upstream configured in
+`branch.<name>.remote` and `branch.<name>.merge` options will be used (see
+linkgit:git-config[1] for details) and the `--fork-point` option is
+assumed. If you are currently not on any branch or if the current
+branch does not have a configured upstream, the rebase will abort.
+
+All changes made by commits in the current branch but that are not
+in `<upstream>` are saved to a temporary area. This is the same set
+of commits that would be shown by `git log <upstream>..HEAD`; or by
+`git log 'fork_point'..HEAD`, if `--fork-point` is active (see the
+description on `--fork-point` below); or by `git log HEAD`, if the
+`--root` option is specified.
+
+The current branch is reset to `<upstream>` or `<newbase>` if the
+`--onto` option was supplied. This has the exact same effect as
+`git reset --hard <upstream>` (or `<newbase>`). `ORIG_HEAD` is set
+to point at the tip of the branch before the reset.
+
+[NOTE]
+`ORIG_HEAD` is not guaranteed to still point to the previous branch tip
+at the end of the rebase if other commands that write that pseudo-ref
+(e.g. `git reset`) are used during the rebase. The previous branch tip,
+however, is accessible using the reflog of the current branch
+(i.e. `@{1}`, see linkgit:gitrevisions[7]).
+
+The commits that were previously saved into the temporary area are
+then reapplied to the current branch, one by one, in order. Note that
+any commits in `HEAD` which introduce the same textual changes as a commit
+in `HEAD..<upstream>` are omitted (i.e., a patch already accepted upstream
+with a different commit message or timestamp will be skipped).
+
+It is possible that a merge failure will prevent this process from being
+completely automatic. You will have to resolve any such merge failure
+and run `git rebase --continue`. Another option is to bypass the commit
+that caused the merge failure with `git rebase --skip`. To check out the
+original `<branch>` and remove the `.git/rebase-apply` working files, use
+the command `git rebase --abort` instead.
+
+Assume the following history exists and the current branch is "topic":
+
+------------
+ A---B---C topic
+ /
+ D---E---F---G master
+------------
+
+From this point, the result of either of the following commands:
+
+
+ git rebase master
+ git rebase master topic
+
+would be:
+
+------------
+ A'--B'--C' topic
+ /
+ D---E---F---G master
+------------
+
+*NOTE:* The latter form is just a short-hand of `git checkout topic`
+followed by `git rebase master`. When rebase exits `topic` will
+remain the checked-out branch.
+
+If the upstream branch already contains a change you have made (e.g.,
+because you mailed a patch which was applied upstream), then that commit
+will be skipped and warnings will be issued (if the 'merge' backend is
+used). For example, running `git rebase master` on the following
+history (in which `A'` and `A` introduce the same set of changes, but
+have different committer information):
+
+------------
+ A---B---C topic
+ /
+ D---E---A'---F master
+------------
+
+will result in:
+
+------------
+ B'---C' topic
+ /
+ D---E---A'---F master
+------------
+
+Here is how you would transplant a topic branch based on one
+branch to another, to pretend that you forked the topic branch
+from the latter branch, using `rebase --onto`.
+
+First let's assume your 'topic' is based on branch 'next'.
+For example, a feature developed in 'topic' depends on some
+functionality which is found in 'next'.
+
+------------
+ o---o---o---o---o master
+ \
+ o---o---o---o---o next
+ \
+ o---o---o topic
+------------
+
+We want to make 'topic' forked from branch 'master'; for example,
+because the functionality on which 'topic' depends was merged into the
+more stable 'master' branch. We want our tree to look like this:
+
+------------
+ o---o---o---o---o master
+ | \
+ | o'--o'--o' topic
+ \
+ o---o---o---o---o next
+------------
+
+We can get this using the following command:
+
+ git rebase --onto master next topic
+
+
+Another example of --onto option is to rebase part of a
+branch. If we have the following situation:
+
+------------
+ H---I---J topicB
+ /
+ E---F---G topicA
+ /
+ A---B---C---D master
+------------
+
+then the command
+
+ git rebase --onto master topicA topicB
+
+would result in:
+
+------------
+ H'--I'--J' topicB
+ /
+ | E---F---G topicA
+ |/
+ A---B---C---D master
+------------
+
+This is useful when topicB does not depend on topicA.
+
+A range of commits could also be removed with rebase. If we have
+the following situation:
+
+------------
+ E---F---G---H---I---J topicA
+------------
+
+then the command
+
+ git rebase --onto topicA~5 topicA~3 topicA
+
+would result in the removal of commits F and G:
+
+------------
+ E---H'---I'---J' topicA
+------------
+
+This is useful if F and G were flawed in some way, or should not be
+part of topicA. Note that the argument to `--onto` and the `<upstream>`
+parameter can be any valid commit-ish.
+
+In case of conflict, `git rebase` will stop at the first problematic commit
+and leave conflict markers in the tree. You can use `git diff` to locate
+the markers (<<<<<<) and make edits to resolve the conflict. For each
+file you edit, you need to tell Git that the conflict has been resolved,
+typically this would be done with
+
+
+ git add <filename>
+
+
+After resolving the conflict manually and updating the index with the
+desired resolution, you can continue the rebasing process with
+
+
+ git rebase --continue
+
+
+Alternatively, you can undo the 'git rebase' with
+
+
+ git rebase --abort
+
+MODE OPTIONS
+------------
+
+The options in this section cannot be used with any other option,
+including not with each other:
+
+--continue::
+ Restart the rebasing process after having resolved a merge conflict.
+
+--skip::
+ Restart the rebasing process by skipping the current patch.
+
+--abort::
+ Abort the rebase operation and reset HEAD to the original
+ branch. If `<branch>` was provided when the rebase operation was
+ started, then `HEAD` will be reset to `<branch>`. Otherwise `HEAD`
+ will be reset to where it was when the rebase operation was
+ started.
+
+--quit::
+ Abort the rebase operation but `HEAD` is not reset back to the
+ original branch. The index and working tree are also left
+ unchanged as a result. If a temporary stash entry was created
+ using `--autostash`, it will be saved to the stash list.
+
+--edit-todo::
+ Edit the todo list during an interactive rebase.
+
+--show-current-patch::
+ Show the current patch in an interactive rebase or when rebase
+ is stopped because of conflicts. This is the equivalent of
+ `git show REBASE_HEAD`.
+
+OPTIONS
+-------
+--onto <newbase>::
+ Starting point at which to create the new commits. If the
+ `--onto` option is not specified, the starting point is
+ `<upstream>`. May be any valid commit, and not just an
+ existing branch name.
++
+As a special case, you may use "A\...B" as a shortcut for the
+merge base of A and B if there is exactly one merge base. You can
+leave out at most one of A and B, in which case it defaults to HEAD.
+
+--keep-base::
+ Set the starting point at which to create the new commits to the
+ merge base of `<upstream>` and `<branch>`. Running
+ `git rebase --keep-base <upstream> <branch>` is equivalent to
+ running
+ `git rebase --reapply-cherry-picks --no-fork-point --onto <upstream>...<branch> <upstream> <branch>`.
++
+This option is useful in the case where one is developing a feature on
+top of an upstream branch. While the feature is being worked on, the
+upstream branch may advance and it may not be the best idea to keep
+rebasing on top of the upstream but to keep the base commit as-is. As
+the base commit is unchanged this option implies `--reapply-cherry-picks`
+to avoid losing commits.
++
+Although both this option and `--fork-point` find the merge base between
+`<upstream>` and `<branch>`, this option uses the merge base as the _starting
+point_ on which new commits will be created, whereas `--fork-point` uses
+the merge base to determine the _set of commits_ which will be rebased.
++
+See also INCOMPATIBLE OPTIONS below.
+
+<upstream>::
+ Upstream branch to compare against. May be any valid commit,
+ not just an existing branch name. Defaults to the configured
+ upstream for the current branch.
+
+<branch>::
+ Working branch; defaults to `HEAD`.
+
+--apply::
+ Use applying strategies to rebase (calling `git-am`
+ internally). This option may become a no-op in the future
+ once the merge backend handles everything the apply one does.
++
+See also INCOMPATIBLE OPTIONS below.
+
+--empty=(drop|keep|stop)::
+ How to handle commits that are not empty to start and are not
+ clean cherry-picks of any upstream commit, but which become
+ empty after rebasing (because they contain a subset of already
+ upstream changes):
++
+--
+`drop`;;
+ The commit will be dropped. This is the default behavior.
+`keep`;;
+ The commit will be kept. This option is implied when `--exec` is
+ specified unless `-i`/`--interactive` is also specified.
+`stop`;;
+`ask`;;
+ The rebase will halt when the commit is applied, allowing you to
+ choose whether to drop it, edit files more, or just commit the empty
+ changes. This option is implied when `-i`/`--interactive` is
+ specified. `ask` is a deprecated synonym of `stop`.
+--
++
+Note that commits which start empty are kept (unless `--no-keep-empty`
+is specified), and commits which are clean cherry-picks (as determined
+by `git log --cherry-mark ...`) are detected and dropped as a
+preliminary step (unless `--reapply-cherry-picks` or `--keep-base` is
+passed).
++
+See also INCOMPATIBLE OPTIONS below.
+
+--no-keep-empty::
+--keep-empty::
+ Do not keep commits that start empty before the rebase
+ (i.e. that do not change anything from its parent) in the
+ result. The default is to keep commits which start empty,
+ since creating such commits requires passing the `--allow-empty`
+ override flag to `git commit`, signifying that a user is very
+ intentionally creating such a commit and thus wants to keep
+ it.
++
+Usage of this flag will probably be rare, since you can get rid of
+commits that start empty by just firing up an interactive rebase and
+removing the lines corresponding to the commits you don't want. This
+flag exists as a convenient shortcut, such as for cases where external
+tools generate many empty commits and you want them all removed.
++
+For commits which do not start empty but become empty after rebasing,
+see the `--empty` flag.
++
+See also INCOMPATIBLE OPTIONS below.
+
+--reapply-cherry-picks::
+--no-reapply-cherry-picks::
+ Reapply all clean cherry-picks of any upstream commit instead
+ of preemptively dropping them. (If these commits then become
+ empty after rebasing, because they contain a subset of already
+ upstream changes, the behavior towards them is controlled by
+ the `--empty` flag.)
++
+In the absence of `--keep-base` (or if `--no-reapply-cherry-picks` is
+given), these commits will be automatically dropped. Because this
+necessitates reading all upstream commits, this can be expensive in
+repositories with a large number of upstream commits that need to be
+read. When using the 'merge' backend, warnings will be issued for each
+dropped commit (unless `--quiet` is given). Advice will also be issued
+unless `advice.skippedCherryPicks` is set to false (see
+linkgit:git-config[1]).
++
+`--reapply-cherry-picks` allows rebase to forgo reading all upstream
+commits, potentially improving performance.
++
+See also INCOMPATIBLE OPTIONS below.
+
+--allow-empty-message::
+ No-op. Rebasing commits with an empty message used to fail
+ and this option would override that behavior, allowing commits
+ with empty messages to be rebased. Now commits with an empty
+ message do not cause rebasing to halt.
++
+See also INCOMPATIBLE OPTIONS below.
+
+-m::
+--merge::
+ Using merging strategies to rebase (default).
++
+Note that a rebase merge works by replaying each commit from the working
+branch on top of the `<upstream>` branch. Because of this, when a merge
+conflict happens, the side reported as 'ours' is the so-far rebased
+series, starting with `<upstream>`, and 'theirs' is the working branch.
+In other words, the sides are swapped.
++
+See also INCOMPATIBLE OPTIONS below.
+
+-s <strategy>::
+--strategy=<strategy>::
+ Use the given merge strategy, instead of the default `ort`.
+ This implies `--merge`.
++
+Because `git rebase` replays each commit from the working branch
+on top of the `<upstream>` branch using the given strategy, using
+the `ours` strategy simply empties all patches from the `<branch>`,
+which makes little sense.
++
+See also INCOMPATIBLE OPTIONS below.
+
+-X <strategy-option>::
+--strategy-option=<strategy-option>::
+ Pass the <strategy-option> through to the merge strategy.
+ This implies `--merge` and, if no strategy has been
+ specified, `-s ort`. Note the reversal of 'ours' and
+ 'theirs' as noted above for the `-m` option.
++
+See also INCOMPATIBLE OPTIONS below.
+
+include::rerere-options.adoc[]
+
+-S[<keyid>]::
+--gpg-sign[=<keyid>]::
+--no-gpg-sign::
+ GPG-sign commits. The `keyid` argument is optional and
+ defaults to the committer identity; if specified, it must be
+ stuck to the option without a space. `--no-gpg-sign` is useful to
+ countermand both `commit.gpgSign` configuration variable, and
+ earlier `--gpg-sign`.
+
+-q::
+--quiet::
+ Be quiet. Implies `--no-stat`.
+
+-v::
+--verbose::
+ Be verbose. Implies `--stat`.
+
+--stat::
+ Show a diffstat of what changed upstream since the last rebase. The
+ diffstat is also controlled by the configuration option rebase.stat.
+
+-n::
+--no-stat::
+ Do not show a diffstat as part of the rebase process.
+
+--no-verify::
+ This option bypasses the pre-rebase hook. See also linkgit:githooks[5].
+
+--verify::
+ Allows the pre-rebase hook to run, which is the default. This option can
+ be used to override `--no-verify`. See also linkgit:githooks[5].
+
+-C<n>::
+ Ensure at least `<n>` lines of surrounding context match before
+ and after each change. When fewer lines of surrounding
+ context exist they all must match. By default no context is
+ ever ignored. Implies `--apply`.
++
+See also INCOMPATIBLE OPTIONS below.
+
+--no-ff::
+--force-rebase::
+-f::
+ Individually replay all rebased commits instead of fast-forwarding
+ over the unchanged ones. This ensures that the entire history of
+ the rebased branch is composed of new commits.
++
+You may find this helpful after reverting a topic branch merge, as this option
+recreates the topic branch with fresh commits so it can be remerged
+successfully without needing to "revert the reversion" (see the
+link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for
+details).
+
+--fork-point::
+--no-fork-point::
+ Use reflog to find a better common ancestor between `<upstream>`
+ and `<branch>` when calculating which commits have been
+ introduced by `<branch>`.
++
+When `--fork-point` is active, 'fork_point' will be used instead of
+`<upstream>` to calculate the set of commits to rebase, where
+'fork_point' is the result of `git merge-base --fork-point <upstream>
+<branch>` command (see linkgit:git-merge-base[1]). If 'fork_point'
+ends up being empty, the `<upstream>` will be used as a fallback.
++
+If `<upstream>` or `--keep-base` is given on the command line, then
+the default is `--no-fork-point`, otherwise the default is
+`--fork-point`. See also `rebase.forkpoint` in linkgit:git-config[1].
++
+If your branch was based on `<upstream>` but `<upstream>` was rewound and
+your branch contains commits which were dropped, this option can be used
+with `--keep-base` in order to drop those commits from your branch.
++
+See also INCOMPATIBLE OPTIONS below.
+
+--ignore-whitespace::
+ Ignore whitespace differences when trying to reconcile
+ differences. Currently, each backend implements an approximation of
+ this behavior:
++
+apply backend;;
+ When applying a patch, ignore changes in whitespace in context
+ lines. Unfortunately, this means that if the "old" lines being
+ replaced by the patch differ only in whitespace from the existing
+ file, you will get a merge conflict instead of a successful patch
+ application.
++
+merge backend;;
+ Treat lines with only whitespace changes as unchanged when merging.
+ Unfortunately, this means that any patch hunks that were intended
+ to modify whitespace and nothing else will be dropped, even if the
+ other side had no changes that conflicted.
+
+--whitespace=<option>::
+ This flag is passed to the `git apply` program
+ (see linkgit:git-apply[1]) that applies the patch.
+ Implies `--apply`.
++
+See also INCOMPATIBLE OPTIONS below.
+
+--committer-date-is-author-date::
+ Instead of using the current time as the committer date, use
+ the author date of the commit being rebased as the committer
+ date. This option implies `--force-rebase`.
+
+--ignore-date::
+--reset-author-date::
+ Instead of using the author date of the original commit, use
+ the current time as the author date of the rebased commit. This
+ option implies `--force-rebase`.
++
+See also INCOMPATIBLE OPTIONS below.
+
+--signoff::
+ Add a `Signed-off-by` trailer to all the rebased commits. Note
+ that if `--interactive` is given then only commits marked to be
+ picked, edited or reworded will have the trailer added.
++
+See also INCOMPATIBLE OPTIONS below.
+
+-i::
+--interactive::
+ Make a list of the commits which are about to be rebased. Let the
+ user edit that list before rebasing. This mode can also be used to
+ split commits (see SPLITTING COMMITS below).
++
+The commit list format can be changed by setting the configuration option
+rebase.instructionFormat. A customized instruction format will automatically
+have the commit hash prepended to the format.
++
+See also INCOMPATIBLE OPTIONS below.
+
+-r::
+--rebase-merges[=(rebase-cousins|no-rebase-cousins)]::
+--no-rebase-merges::
+ By default, a rebase will simply drop merge commits from the todo
+ list, and put the rebased commits into a single, linear branch.
+ With `--rebase-merges`, the rebase will instead try to preserve
+ the branching structure within the commits that are to be rebased,
+ by recreating the merge commits. Any resolved merge conflicts or
+ manual amendments in these merge commits will have to be
+ resolved/re-applied manually. `--no-rebase-merges` can be used to
+ countermand both the `rebase.rebaseMerges` config option and a previous
+ `--rebase-merges`.
++
+When rebasing merges, there are two modes: `rebase-cousins` and
+`no-rebase-cousins`. If the mode is not specified, it defaults to
+`no-rebase-cousins`. In `no-rebase-cousins` mode, commits which do not have
+`<upstream>` as direct ancestor will keep their original branch point, i.e.
+commits that would be excluded by linkgit:git-log[1]'s `--ancestry-path`
+option will keep their original ancestry by default. In `rebase-cousins` mode,
+such commits are instead rebased onto `<upstream>` (or `<onto>`, if
+specified).
++
+It is currently only possible to recreate the merge commits using the
+`ort` merge strategy; different merge strategies can be used only via
+explicit `exec git merge -s <strategy> [...]` commands.
++
+See also REBASING MERGES and INCOMPATIBLE OPTIONS below.
+
+-x <cmd>::
+--exec <cmd>::
+ Append "exec <cmd>" after each line creating a commit in the
+ final history. `<cmd>` will be interpreted as one or more shell
+ commands. Any command that fails will interrupt the rebase,
+ with exit code 1.
++
+You may execute several commands by either using one instance of `--exec`
+with several commands:
++
+ git rebase -i --exec "cmd1 && cmd2 && ..."
++
+or by giving more than one `--exec`:
++
+ git rebase -i --exec "cmd1" --exec "cmd2" --exec ...
++
+If `--autosquash` is used, `exec` lines will not be appended for
+the intermediate commits, and will only appear at the end of each
+squash/fixup series.
++
+This uses the `--interactive` machinery internally, but it can be run
+without an explicit `--interactive`.
++
+See also INCOMPATIBLE OPTIONS below.
+
+--root::
+ Rebase all commits reachable from `<branch>`, instead of
+ limiting them with an `<upstream>`. This allows you to rebase
+ the root commit(s) on a branch.
++
+See also INCOMPATIBLE OPTIONS below.
+
+--autosquash::
+--no-autosquash::
+ Automatically squash commits with specially formatted messages into
+ previous commits being rebased. If a commit message starts with
+ "squash! ", "fixup! " or "amend! ", the remainder of the subject line
+ is taken as a commit specifier, which matches a previous commit if it
+ matches the subject line or the hash of that commit. If no commit
+ matches fully, matches of the specifier with the start of commit
+ subjects are considered.
++
+In the rebase todo list, the actions of squash, fixup and amend commits are
+changed from `pick` to `squash`, `fixup` or `fixup -C`, respectively, and they
+are moved right after the commit they modify. The `--interactive` option can
+be used to review and edit the todo list before proceeding.
++
+The recommended way to create commits with squash markers is by using the
+`--squash`, `--fixup`, `--fixup=amend:` or `--fixup=reword:` options of
+linkgit:git-commit[1], which take the target commit as an argument and
+automatically fill in the subject line of the new commit from that.
++
+Setting configuration variable `rebase.autoSquash` to true enables
+auto-squashing by default for interactive rebase. The `--no-autosquash`
+option can be used to override that setting.
++
+See also INCOMPATIBLE OPTIONS below.
+
+--autostash::
+--no-autostash::
+ Automatically create a temporary stash entry before the operation
+ begins, and apply it after the operation ends. This means
+ that you can run rebase on a dirty worktree. However, use
+ with care: the final stash application after a successful
+ rebase might result in non-trivial conflicts.
+
+--reschedule-failed-exec::
+--no-reschedule-failed-exec::
+ Automatically reschedule `exec` commands that failed. This only makes
+ sense in interactive mode (or when an `--exec` option was provided).
++
+This option applies once a rebase is started. It is preserved for the whole
+rebase based on, in order, the command line option provided to the initial `git
+rebase`, the `rebase.rescheduleFailedExec` configuration (see
+linkgit:git-config[1] or "CONFIGURATION" below), or it defaults to false.
++
+Recording this option for the whole rebase is a convenience feature. Otherwise
+an explicit `--no-reschedule-failed-exec` at the start would be overridden by
+the presence of a `rebase.rescheduleFailedExec=true` configuration when `git
+rebase --continue` is invoked. Currently, you cannot pass
+`--[no-]reschedule-failed-exec` to `git rebase --continue`.
+
+--update-refs::
+--no-update-refs::
+ Automatically force-update any branches that point to commits that
+ are being rebased. Any branches that are checked out in a worktree
+ are not updated in this way.
++
+If the configuration variable `rebase.updateRefs` is set, then this option
+can be used to override and disable this setting.
++
+See also INCOMPATIBLE OPTIONS below.
+
+INCOMPATIBLE OPTIONS
+--------------------
+
+The following options:
+
+ * --apply
+ * --whitespace
+ * -C
+
+are incompatible with the following options:
+
+ * --merge
+ * --strategy
+ * --strategy-option
+ * --autosquash
+ * --rebase-merges
+ * --interactive
+ * --exec
+ * --no-keep-empty
+ * --empty=
+ * --[no-]reapply-cherry-picks when used without --keep-base
+ * --update-refs
+ * --root when used without --onto
+
+In addition, the following pairs of options are incompatible:
+
+ * --keep-base and --onto
+ * --keep-base and --root
+ * --fork-point and --root
+
+BEHAVIORAL DIFFERENCES
+-----------------------
+
+`git rebase` has two primary backends: 'apply' and 'merge'. (The 'apply'
+backend used to be known as the 'am' backend, but the name led to
+confusion as it looks like a verb instead of a noun. Also, the 'merge'
+backend used to be known as the interactive backend, but it is now
+used for non-interactive cases as well. Both were renamed based on
+lower-level functionality that underpinned each.) There are some
+subtle differences in how these two backends behave:
+
+Empty commits
+~~~~~~~~~~~~~
+
+The 'apply' backend unfortunately drops intentionally empty commits, i.e.
+commits that started empty, though these are rare in practice. It
+also drops commits that become empty and has no option for controlling
+this behavior.
+
+The 'merge' backend keeps intentionally empty commits by default (though
+with `-i` they are marked as empty in the todo list editor, or they can
+be dropped automatically with `--no-keep-empty`).
+
+Similar to the apply backend, by default the merge backend drops
+commits that become empty unless `-i`/`--interactive` is specified (in
+which case it stops and asks the user what to do). The merge backend
+also has an `--empty=(drop|keep|stop)` option for changing the behavior
+of handling commits that become empty.
+
+Directory rename detection
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Due to the lack of accurate tree information (arising from
+constructing fake ancestors with the limited information available in
+patches), directory rename detection is disabled in the 'apply' backend.
+Disabled directory rename detection means that if one side of history
+renames a directory and the other adds new files to the old directory,
+then the new files will be left behind in the old directory without
+any warning at the time of rebasing that you may want to move these
+files into the new directory.
+
+Directory rename detection works with the 'merge' backend to provide you
+warnings in such cases.
+
+Context
+~~~~~~~
+
+The 'apply' backend works by creating a sequence of patches (by calling
+`format-patch` internally), and then applying the patches in sequence
+(calling `am` internally). Patches are composed of multiple hunks,
+each with line numbers, a context region, and the actual changes. The
+line numbers have to be taken with some offset, since the other side
+will likely have inserted or deleted lines earlier in the file. The
+context region is meant to help find how to adjust the line numbers in
+order to apply the changes to the right lines. However, if multiple
+areas of the code have the same surrounding lines of context, the
+wrong one can be picked. There are real-world cases where this has
+caused commits to be reapplied incorrectly with no conflicts reported.
+Setting `diff.context` to a larger value may prevent such types of
+problems, but increases the chance of spurious conflicts (since it
+will require more lines of matching context to apply).
+
+The 'merge' backend works with a full copy of each relevant file,
+insulating it from these types of problems.
+
+Labelling of conflicts markers
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When there are content conflicts, the merge machinery tries to
+annotate each side's conflict markers with the commits where the
+content came from. Since the 'apply' backend drops the original
+information about the rebased commits and their parents (and instead
+generates new fake commits based off limited information in the
+generated patches), those commits cannot be identified; instead it has
+to fall back to a commit summary. Also, when `merge.conflictStyle` is
+set to `diff3` or `zdiff3`, the 'apply' backend will use "constructed merge
+base" to label the content from the merge base, and thus provide no
+information about the merge base commit whatsoever.
+
+The 'merge' backend works with the full commits on both sides of history
+and thus has no such limitations.
+
+Hooks
+~~~~~
+
+The 'apply' backend has not traditionally called the post-commit hook,
+while the 'merge' backend has. Both have called the post-checkout hook,
+though the 'merge' backend has squelched its output. Further, both
+backends only call the post-checkout hook with the starting point
+commit of the rebase, not the intermediate commits nor the final
+commit. In each case, the calling of these hooks was by accident of
+implementation rather than by design (both backends were originally
+implemented as shell scripts and happened to invoke other commands
+like `git checkout` or `git commit` that would call the hooks). Both
+backends should have the same behavior, though it is not entirely
+clear which, if any, is correct. We will likely make rebase stop
+calling either of these hooks in the future.
+
+Interruptability
+~~~~~~~~~~~~~~~~
+
+The 'apply' backend has safety problems with an ill-timed interrupt; if
+the user presses Ctrl-C at the wrong time to try to abort the rebase,
+the rebase can enter a state where it cannot be aborted with a
+subsequent `git rebase --abort`. The 'merge' backend does not appear to
+suffer from the same shortcoming. (See
+https://lore.kernel.org/git/20200207132152.GC2868@szeder.dev/ for
+details.)
+
+Commit Rewording
+~~~~~~~~~~~~~~~~
+
+When a conflict occurs while rebasing, rebase stops and asks the user
+to resolve. Since the user may need to make notable changes while
+resolving conflicts, after conflicts are resolved and the user has run
+`git rebase --continue`, the rebase should open an editor and ask the
+user to update the commit message. The 'merge' backend does this, while
+the 'apply' backend blindly applies the original commit message.
+
+Miscellaneous differences
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+There are a few more behavioral differences that most folks would
+probably consider inconsequential but which are mentioned for
+completeness:
+
+* Reflog: The two backends will use different wording when describing
+ the changes made in the reflog, though both will make use of the
+ word "rebase".
+
+* Progress, informational, and error messages: The two backends
+ provide slightly different progress and informational messages.
+ Also, the apply backend writes error messages (such as "Your files
+ would be overwritten...") to stdout, while the merge backend writes
+ them to stderr.
+
+* State directories: The two backends keep their state in different
+ directories under `.git/`
+
+include::merge-strategies.adoc[]
+
+NOTES
+-----
+
+You should understand the implications of using `git rebase` on a
+repository that you share. See also RECOVERING FROM UPSTREAM REBASE
+below.
+
+When the rebase is run, it will first execute a `pre-rebase` hook if one
+exists. You can use this hook to do sanity checks and reject the rebase
+if it isn't appropriate. Please see the template `pre-rebase` hook script
+for an example.
+
+Upon completion, `<branch>` will be the current branch.
+
+INTERACTIVE MODE
+----------------
+
+Rebasing interactively means that you have a chance to edit the commits
+which are rebased. You can reorder the commits, and you can
+remove them (weeding out bad or otherwise unwanted patches).
+
+The interactive mode is meant for this type of workflow:
+
+1. have a wonderful idea
+2. hack on the code
+3. prepare a series for submission
+4. submit
+
+where point 2. consists of several instances of
+
+a) regular use
+
+ 1. finish something worthy of a commit
+ 2. commit
+
+b) independent fixup
+
+ 1. realize that something does not work
+ 2. fix that
+ 3. commit it
+
+Sometimes the thing fixed in b.2. cannot be amended to the not-quite
+perfect commit it fixes, because that commit is buried deeply in a
+patch series. That is exactly what interactive rebase is for: use it
+after plenty of "a"s and "b"s, by rearranging and editing
+commits, and squashing multiple commits into one.
+
+Start it with the last commit you want to retain as-is:
+
+ git rebase -i <after-this-commit>
+
+An editor will be fired up with all the commits in your current branch
+(ignoring merge commits), which come after the given commit. You can
+reorder the commits in this list to your heart's content, and you can
+remove them. The list looks more or less like this:
+
+-------------------------------------------
+pick deadbee The oneline of this commit
+pick fa1afe1 The oneline of the next commit
+...
+-------------------------------------------
+
+The oneline descriptions are purely for your pleasure; 'git rebase' will
+not look at them but at the commit names ("deadbee" and "fa1afe1" in this
+example), so do not delete or edit the names.
+
+By replacing the command "pick" with the command "edit", you can tell
+`git rebase` to stop after applying that commit, so that you can edit
+the files and/or the commit message, amend the commit, and continue
+rebasing.
+
+To interrupt the rebase (just like an "edit" command would do, but without
+cherry-picking any commit first), use the "break" command.
+
+If you just want to edit the commit message for a commit, replace the
+command "pick" with the command "reword".
+
+To drop a commit, replace the command "pick" with "drop", or just
+delete the matching line.
+
+If you want to fold two or more commits into one, replace the command
+"pick" for the second and subsequent commits with "squash" or "fixup".
+If the commits had different authors, the folded commit will be
+attributed to the author of the first commit. The suggested commit
+message for the folded commit is the concatenation of the first
+commit's message with those identified by "squash" commands, omitting the
+messages of commits identified by "fixup" commands, unless "fixup -c"
+is used. In that case the suggested commit message is only the message
+of the "fixup -c" commit, and an editor is opened allowing you to edit
+the message. The contents (patch) of the "fixup -c" commit are still
+incorporated into the folded commit. If there is more than one "fixup -c"
+commit, the message from the final one is used. You can also use
+"fixup -C" to get the same behavior as "fixup -c" except without opening
+an editor.
+
+`git rebase` will stop when "pick" has been replaced with "edit" or
+when a command fails due to merge errors. When you are done editing
+and/or resolving conflicts you can continue with `git rebase --continue`.
+
+For example, if you want to reorder the last 5 commits, such that what
+was `HEAD~4` becomes the new `HEAD`. To achieve that, you would call
+`git rebase` like this:
+
+----------------------
+$ git rebase -i HEAD~5
+----------------------
+
+And move the first patch to the end of the list.
+
+You might want to recreate merge commits, e.g. if you have a history
+like this:
+
+------------------
+ X
+ \
+ A---M---B
+ /
+---o---O---P---Q
+------------------
+
+Suppose you want to rebase the side branch starting at "A" to "Q". Make
+sure that the current `HEAD` is "B", and call
+
+-----------------------------
+$ git rebase -i -r --onto Q O
+-----------------------------
+
+Reordering and editing commits usually creates untested intermediate
+steps. You may want to check that your history editing did not break
+anything by running a test, or at least recompiling at intermediate
+points in history by using the "exec" command (shortcut "x"). You may
+do so by creating a todo list like this one:
+
+-------------------------------------------
+pick deadbee Implement feature XXX
+fixup f1a5c00 Fix to feature XXX
+exec make
+pick c0ffeee The oneline of the next commit
+edit deadbab The oneline of the commit after
+exec cd subdir; make test
+...
+-------------------------------------------
+
+The interactive rebase will stop when a command fails (i.e. exits with
+non-0 status) to give you an opportunity to fix the problem. You can
+continue with `git rebase --continue`.
+
+The "exec" command launches the command in a shell (the default one, usually
+/bin/sh), so you can use shell features (like "cd", ">", ";" ...). The command
+is run from the root of the working tree.
+
+----------------------------------
+$ git rebase -i --exec "make test"
+----------------------------------
+
+This command lets you check that intermediate commits are compilable.
+The todo list becomes like that:
+
+--------------------
+pick 5928aea one
+exec make test
+pick 04d0fda two
+exec make test
+pick ba46169 three
+exec make test
+pick f4593f9 four
+exec make test
+--------------------
+
+SPLITTING COMMITS
+-----------------
+
+In interactive mode, you can mark commits with the action "edit". However,
+this does not necessarily mean that `git rebase` expects the result of this
+edit to be exactly one commit. Indeed, you can undo the commit, or you can
+add other commits. This can be used to split a commit into two:
+
+- Start an interactive rebase with `git rebase -i <commit>^`, where
+ `<commit>` is the commit you want to split. In fact, any commit range
+ will do, as long as it contains that commit.
+
+- Mark the commit you want to split with the action "edit".
+
+- When it comes to editing that commit, execute `git reset HEAD^`. The
+ effect is that the `HEAD` is rewound by one, and the index follows suit.
+ However, the working tree stays the same.
+
+- Now add the changes to the index that you want to have in the first
+ commit. You can use `git add` (possibly interactively) or
+ `git gui` (or both) to do that.
+
+- Commit the now-current index with whatever commit message is appropriate
+ now.
+
+- Repeat the last two steps until your working tree is clean.
+
+- Continue the rebase with `git rebase --continue`.
+
+If you are not absolutely sure that the intermediate revisions are
+consistent (they compile, pass the testsuite, etc.) you should use
+`git stash` to stash away the not-yet-committed changes
+after each commit, test, and amend the commit if fixes are necessary.
+
+
+RECOVERING FROM UPSTREAM REBASE
+-------------------------------
+
+Rebasing (or any other form of rewriting) a branch that others have
+based work on is a bad idea: anyone downstream of it is forced to
+manually fix their history. This section explains how to do the fix
+from the downstream's point of view. The real fix, however, would be
+to avoid rebasing the upstream in the first place.
+
+To illustrate, suppose you are in a situation where someone develops a
+'subsystem' branch, and you are working on a 'topic' that is dependent
+on this 'subsystem'. You might end up with a history like the
+following:
+
+------------
+ o---o---o---o---o---o---o---o master
+ \
+ o---o---o---o---o subsystem
+ \
+ *---*---* topic
+------------
+
+If 'subsystem' is rebased against 'master', the following happens:
+
+------------
+ o---o---o---o---o---o---o---o master
+ \ \
+ o---o---o---o---o o'--o'--o'--o'--o' subsystem
+ \
+ *---*---* topic
+------------
+
+If you now continue development as usual, and eventually merge 'topic'
+to 'subsystem', the commits from 'subsystem' will remain duplicated forever:
+
+------------
+ o---o---o---o---o---o---o---o master
+ \ \
+ o---o---o---o---o o'--o'--o'--o'--o'--M subsystem
+ \ /
+ *---*---*-..........-*--* topic
+------------
+
+Such duplicates are generally frowned upon because they clutter up
+history, making it harder to follow. To clean things up, you need to
+transplant the commits on 'topic' to the new 'subsystem' tip, i.e.,
+rebase 'topic'. This becomes a ripple effect: anyone downstream from
+'topic' is forced to rebase too, and so on!
+
+There are two kinds of fixes, discussed in the following subsections:
+
+Easy case: The changes are literally the same.::
+
+ This happens if the 'subsystem' rebase was a simple rebase and
+ had no conflicts.
+
+Hard case: The changes are not the same.::
+
+ This happens if the 'subsystem' rebase had conflicts, or used
+ `--interactive` to omit, edit, squash, or fixup commits; or
+ if the upstream used one of `commit --amend`, `reset`, or
+ a full history rewriting command like
+ https://github.com/newren/git-filter-repo[`filter-repo`].
+
+
+The easy case
+~~~~~~~~~~~~~
+
+Only works if the changes (patch IDs based on the diff contents) on
+'subsystem' are literally the same before and after the rebase
+'subsystem' did.
+
+In that case, the fix is easy because 'git rebase' knows to skip
+changes that are already present in the new upstream (unless
+`--reapply-cherry-picks` is given). So if you say
+(assuming you're on 'topic')
+------------
+ $ git rebase subsystem
+------------
+you will end up with the fixed history
+------------
+ o---o---o---o---o---o---o---o master
+ \
+ o'--o'--o'--o'--o' subsystem
+ \
+ *---*---* topic
+------------
+
+
+The hard case
+~~~~~~~~~~~~~
+
+Things get more complicated if the 'subsystem' changes do not exactly
+correspond to the ones before the rebase.
+
+NOTE: While an "easy case recovery" sometimes appears to be successful
+ even in the hard case, it may have unintended consequences. For
+ example, a commit that was removed via `git rebase
+ --interactive` will be **resurrected**!
+
+The idea is to manually tell `git rebase` "where the old 'subsystem'
+ended and your 'topic' began", that is, what the old merge base
+between them was. You will have to find a way to name the last commit
+of the old 'subsystem', for example:
+
+* With the 'subsystem' reflog: after `git fetch`, the old tip of
+ 'subsystem' is at `subsystem@{1}`. Subsequent fetches will
+ increase the number. (See linkgit:git-reflog[1].)
+
+* Relative to the tip of 'topic': knowing that your 'topic' has three
+ commits, the old tip of 'subsystem' must be `topic~3`.
+
+You can then transplant the old `subsystem..topic` to the new tip by
+saying (for the reflog case, and assuming you are on 'topic' already):
+------------
+ $ git rebase --onto subsystem subsystem@{1}
+------------
+
+The ripple effect of a "hard case" recovery is especially bad:
+'everyone' downstream from 'topic' will now have to perform a "hard
+case" recovery too!
+
+REBASING MERGES
+---------------
+
+The interactive rebase command was originally designed to handle
+individual patch series. As such, it makes sense to exclude merge
+commits from the todo list, as the developer may have merged the
+then-current `master` while working on the branch, only to rebase
+all the commits onto `master` eventually (skipping the merge
+commits).
+
+However, there are legitimate reasons why a developer may want to
+recreate merge commits: to keep the branch structure (or "commit
+topology") when working on multiple, inter-related branches.
+
+In the following example, the developer works on a topic branch that
+refactors the way buttons are defined, and on another topic branch
+that uses that refactoring to implement a "Report a bug" button. The
+output of `git log --graph --format=%s -5` may look like this:
+
+------------
+* Merge branch 'report-a-bug'
+|\
+| * Add the feedback button
+* | Merge branch 'refactor-button'
+|\ \
+| |/
+| * Use the Button class for all buttons
+| * Extract a generic Button class from the DownloadButton one
+------------
+
+The developer might want to rebase those commits to a newer `master`
+while keeping the branch topology, for example when the first topic
+branch is expected to be integrated into `master` much earlier than the
+second one, say, to resolve merge conflicts with changes to the
+DownloadButton class that made it into `master`.
+
+This rebase can be performed using the `--rebase-merges` option.
+It will generate a todo list looking like this:
+
+------------
+label onto
+
+# Branch: refactor-button
+reset onto
+pick 123456 Extract a generic Button class from the DownloadButton one
+pick 654321 Use the Button class for all buttons
+label refactor-button
+
+# Branch: report-a-bug
+reset refactor-button # Use the Button class for all buttons
+pick abcdef Add the feedback button
+label report-a-bug
+
+reset onto
+merge -C a1b2c3 refactor-button # Merge 'refactor-button'
+merge -C 6f5e4d report-a-bug # Merge 'report-a-bug'
+------------
+
+In contrast to a regular interactive rebase, there are `label`, `reset`
+and `merge` commands in addition to `pick` ones.
+
+The `label` command associates a label with the current HEAD when that
+command is executed. These labels are created as worktree-local refs
+(`refs/rewritten/<label>`) that will be deleted when the rebase
+finishes. That way, rebase operations in multiple worktrees linked to
+the same repository do not interfere with one another. If the `label`
+command fails, it is rescheduled immediately, with a helpful message how
+to proceed.
+
+The `reset` command resets the HEAD, index and worktree to the specified
+revision. It is similar to an `exec git reset --hard <label>`, but
+refuses to overwrite untracked files. If the `reset` command fails, it is
+rescheduled immediately, with a helpful message how to edit the todo list
+(this typically happens when a `reset` command was inserted into the todo
+list manually and contains a typo).
+
+The `merge` command will merge the specified revision(s) into whatever
+is HEAD at that time. With `-C <original-commit>`, the commit message of
+the specified merge commit will be used. When the `-C` is changed to
+a lower-case `-c`, the message will be opened in an editor after a
+successful merge so that the user can edit the message.
+
+If a `merge` command fails for any reason other than merge conflicts (i.e.
+when the merge operation did not even start), it is rescheduled immediately.
+
+By default, the `merge` command will use the `ort` merge strategy for
+regular merges, and `octopus` for octopus merges. One can specify a
+default strategy for all merges using the `--strategy` argument when
+invoking rebase, or can override specific merges in the interactive
+list of commands by using an `exec` command to call `git merge`
+explicitly with a `--strategy` argument. Note that when calling `git
+merge` explicitly like this, you can make use of the fact that the
+labels are worktree-local refs (the ref `refs/rewritten/onto` would
+correspond to the label `onto`, for example) in order to refer to the
+branches you want to merge.
+
+Note: the first command (`label onto`) labels the revision onto which
+the commits are rebased; The name `onto` is just a convention, as a nod
+to the `--onto` option.
+
+It is also possible to introduce completely new merge commits from scratch
+by adding a command of the form `merge <merge-head>`. This form will
+generate a tentative commit message and always open an editor to let the
+user edit it. This can be useful e.g. when a topic branch turns out to
+address more than a single concern and wants to be split into two or
+even more topic branches. Consider this todo list:
+
+------------
+pick 192837 Switch from GNU Makefiles to CMake
+pick 5a6c7e Document the switch to CMake
+pick 918273 Fix detection of OpenSSL in CMake
+pick afbecd http: add support for TLS v1.3
+pick fdbaec Fix detection of cURL in CMake on Windows
+------------
+
+The one commit in this list that is not related to CMake may very well
+have been motivated by working on fixing all those bugs introduced by
+switching to CMake, but it addresses a different concern. To split this
+branch into two topic branches, the todo list could be edited like this:
+
+------------
+label onto
+
+pick afbecd http: add support for TLS v1.3
+label tlsv1.3
+
+reset onto
+pick 192837 Switch from GNU Makefiles to CMake
+pick 918273 Fix detection of OpenSSL in CMake
+pick fdbaec Fix detection of cURL in CMake on Windows
+pick 5a6c7e Document the switch to CMake
+label cmake
+
+reset onto
+merge tlsv1.3
+merge cmake
+------------
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/rebase.adoc[]
+include::config/sequencer.adoc[]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-receive-pack.adoc b/git-receive-pack.adoc
new file mode 100644
index 0000000..20aca92
--- /dev/null
+++ b/git-receive-pack.adoc
@@ -0,0 +1,261 @@
+git-receive-pack(1)
+===================
+
+NAME
+----
+git-receive-pack - Receive what is pushed into the repository
+
+
+SYNOPSIS
+--------
+[verse]
+'git receive-pack' <git-dir>
+
+DESCRIPTION
+-----------
+Invoked by 'git send-pack' and updates the repository with the
+information fed from the remote end.
+
+This command is usually not invoked directly by the end user.
+The UI for the protocol is on the 'git send-pack' side, and the
+program pair is meant to be used to push updates to a remote
+repository. For pull operations, see linkgit:git-fetch-pack[1].
+
+The command allows for the creation and fast-forwarding of sha1 refs
+(heads/tags) on the remote end (strictly speaking, it is the
+local end 'git-receive-pack' runs, but to the user who is sitting at
+the send-pack end, it is updating the remote. Confused?)
+
+There are other real-world examples of using update and
+post-update hooks found in the Documentation/howto directory.
+
+'git-receive-pack' honours the receive.denyNonFastForwards config
+option, which tells it if updates to a ref should be denied if they
+are not fast-forwards.
+
+A number of other receive.* config options are available to tweak
+its behavior, see linkgit:git-config[1].
+
+OPTIONS
+-------
+<git-dir>::
+ The repository to sync into.
+
+--http-backend-info-refs::
+ Used by linkgit:git-http-backend[1] to serve up
+ `$GIT_URL/info/refs?service=git-receive-pack` requests. See
+ `--http-backend-info-refs` in linkgit:git-upload-pack[1].
+
+PRE-RECEIVE HOOK
+----------------
+Before any ref is updated, if $GIT_DIR/hooks/pre-receive file exists
+and is executable, it will be invoked once with no parameters. The
+standard input of the hook will be one line per ref to be updated:
+
+ sha1-old SP sha1-new SP refname LF
+
+The refname value is relative to $GIT_DIR; e.g. for the master
+head this is "refs/heads/master". The two sha1 values before
+each refname are the object names for the refname before and after
+the update. Refs to be created will have sha1-old equal to 0\{40},
+while refs to be deleted will have sha1-new equal to 0\{40}, otherwise
+sha1-old and sha1-new should be valid objects in the repository.
+
+When accepting a signed push (see linkgit:git-push[1]), the signed
+push certificate is stored in a blob and an environment variable
+`GIT_PUSH_CERT` can be consulted for its object name. See the
+description of `post-receive` hook for an example. In addition, the
+certificate is verified using GPG and the result is exported with
+the following environment variables:
+
+`GIT_PUSH_CERT_SIGNER`::
+ The name and the e-mail address of the owner of the key that
+ signed the push certificate.
+
+`GIT_PUSH_CERT_KEY`::
+ The GPG key ID of the key that signed the push certificate.
+
+`GIT_PUSH_CERT_STATUS`::
+ The status of GPG verification of the push certificate,
+ using the same mnemonic as used in `%G?` format of `git log`
+ family of commands (see linkgit:git-log[1]).
+
+`GIT_PUSH_CERT_NONCE`::
+ The nonce string the process asked the signer to include
+ in the push certificate. If this does not match the value
+ recorded on the "nonce" header in the push certificate, it
+ may indicate that the certificate is a valid one that is
+ being replayed from a separate "git push" session.
+
+`GIT_PUSH_CERT_NONCE_STATUS`::
+`UNSOLICITED`;;
+ "git push --signed" sent a nonce when we did not ask it to
+ send one.
+`MISSING`;;
+ "git push --signed" did not send any nonce header.
+`BAD`;;
+ "git push --signed" sent a bogus nonce.
+`OK`;;
+ "git push --signed" sent the nonce we asked it to send.
+`SLOP`;;
+ "git push --signed" sent a nonce different from what we
+ asked it to send now, but in a previous session. See
+ `GIT_PUSH_CERT_NONCE_SLOP` environment variable.
+
+`GIT_PUSH_CERT_NONCE_SLOP`::
+ "git push --signed" sent a nonce different from what we
+ asked it to send now, but in a different session whose
+ starting time is different by this many seconds from the
+ current session. Only meaningful when
+ `GIT_PUSH_CERT_NONCE_STATUS` says `SLOP`.
+ Also read about `receive.certNonceSlop` variable in
+ linkgit:git-config[1].
+
+This hook is called before any refname is updated and before any
+fast-forward checks are performed.
+
+If the pre-receive hook exits with a non-zero exit status no updates
+will be performed, and the update, post-receive and post-update
+hooks will not be invoked either. This can be useful to quickly
+bail out if the update is not to be supported.
+
+See the notes on the quarantine environment below.
+
+UPDATE HOOK
+-----------
+Before each ref is updated, if $GIT_DIR/hooks/update file exists
+and is executable, it is invoked once per ref, with three parameters:
+
+ $GIT_DIR/hooks/update refname sha1-old sha1-new
+
+The refname parameter is relative to $GIT_DIR; e.g. for the master
+head this is "refs/heads/master". The two sha1 arguments are
+the object names for the refname before and after the update.
+Note that the hook is called before the refname is updated,
+so either sha1-old is 0\{40} (meaning there is no such ref yet),
+or it should match what is recorded in refname.
+
+The hook should exit with non-zero status if it wants to disallow
+updating the named ref. Otherwise it should exit with zero.
+
+Successful execution (a zero exit status) of this hook does not
+ensure the ref will actually be updated, it is only a prerequisite.
+As such it is not a good idea to send notices (e.g. email) from
+this hook. Consider using the post-receive hook instead.
+
+POST-RECEIVE HOOK
+-----------------
+After all refs were updated (or attempted to be updated), if any
+ref update was successful, and if $GIT_DIR/hooks/post-receive
+file exists and is executable, it will be invoked once with no
+parameters. The standard input of the hook will be one line
+for each successfully updated ref:
+
+ sha1-old SP sha1-new SP refname LF
+
+The refname value is relative to $GIT_DIR; e.g. for the master
+head this is "refs/heads/master". The two sha1 values before
+each refname are the object names for the refname before and after
+the update. Refs that were created will have sha1-old equal to
+0\{40}, while refs that were deleted will have sha1-new equal to
+0\{40}, otherwise sha1-old and sha1-new should be valid objects in
+the repository.
+
+The `GIT_PUSH_CERT*` environment variables can be inspected, just as
+in `pre-receive` hook, after accepting a signed push.
+
+Using this hook, it is easy to generate mails describing the updates
+to the repository. This example script sends one mail message per
+ref listing the commits pushed to the repository, and logs the push
+certificates of signed pushes with good signatures to a logger
+service:
+
+----
+#!/bin/sh
+# mail out commit update information.
+while read oval nval ref
+do
+ if expr "$oval" : '0*$' >/dev/null
+ then
+ echo "Created a new ref, with the following commits:"
+ git rev-list --pretty "$nval"
+ else
+ echo "New commits:"
+ git rev-list --pretty "$nval" "^$oval"
+ fi |
+ mail -s "Changes to ref $ref" commit-list@mydomain
+done
+# log signed push certificate, if any
+if test -n "${GIT_PUSH_CERT-}" && test ${GIT_PUSH_CERT_STATUS} = G
+then
+ (
+ echo expected nonce is ${GIT_PUSH_NONCE}
+ git cat-file blob ${GIT_PUSH_CERT}
+ ) | mail -s "push certificate from $GIT_PUSH_CERT_SIGNER" push-log@mydomain
+fi
+exit 0
+----
+
+The exit code from this hook invocation is ignored, however a
+non-zero exit code will generate an error message.
+
+Note that it is possible for refname to not have sha1-new when this
+hook runs. This can easily occur if another user modifies the ref
+after it was updated by 'git-receive-pack', but before the hook was able
+to evaluate it. It is recommended that hooks rely on sha1-new
+rather than the current value of refname.
+
+POST-UPDATE HOOK
+----------------
+After all other processing, if at least one ref was updated, and
+if $GIT_DIR/hooks/post-update file exists and is executable, then
+post-update will be called with the list of refs that have been updated.
+This can be used to implement any repository wide cleanup tasks.
+
+The exit code from this hook invocation is ignored; the only thing
+left for 'git-receive-pack' to do at that point is to exit itself
+anyway.
+
+This hook can be used, for example, to run `git update-server-info`
+if the repository is packed and is served via a dumb transport.
+
+----
+#!/bin/sh
+exec git update-server-info
+----
+
+
+QUARANTINE ENVIRONMENT
+----------------------
+
+When `receive-pack` takes in objects, they are placed into a temporary
+"quarantine" directory within the `$GIT_DIR/objects` directory and
+migrated into the main object store only after the `pre-receive` hook
+has completed. If the push fails before then, the temporary directory is
+removed entirely.
+
+This has a few user-visible effects and caveats:
+
+ 1. Pushes which fail due to problems with the incoming pack, missing
+ objects, or due to the `pre-receive` hook will not leave any
+ on-disk data. This is usually helpful to prevent repeated failed
+ pushes from filling up your disk, but can make debugging more
+ challenging.
+
+ 2. Any objects created by the `pre-receive` hook will be created in
+ the quarantine directory (and migrated only if it succeeds).
+
+ 3. The `pre-receive` hook MUST NOT update any refs to point to
+ quarantined objects. Other programs accessing the repository will
+ not be able to see the objects (and if the pre-receive hook fails,
+ those refs would become corrupted). For safety, any ref updates
+ from within `pre-receive` are automatically rejected.
+
+
+SEE ALSO
+--------
+linkgit:git-send-pack[1], linkgit:gitnamespaces[7]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-reflog.adoc b/git-reflog.adoc
new file mode 100644
index 0000000..a929c52
--- /dev/null
+++ b/git-reflog.adoc
@@ -0,0 +1,138 @@
+git-reflog(1)
+=============
+
+NAME
+----
+git-reflog - Manage reflog information
+
+
+SYNOPSIS
+--------
+[verse]
+'git reflog' [show] [<log-options>] [<ref>]
+'git reflog list'
+'git reflog expire' [--expire=<time>] [--expire-unreachable=<time>]
+ [--rewrite] [--updateref] [--stale-fix]
+ [--dry-run | -n] [--verbose] [--all [--single-worktree] | <refs>...]
+'git reflog delete' [--rewrite] [--updateref]
+ [--dry-run | -n] [--verbose] <ref>@{<specifier>}...
+'git reflog exists' <ref>
+
+DESCRIPTION
+-----------
+This command manages the information recorded in the reflogs.
+
+Reference logs, or "reflogs", record when the tips of branches and
+other references were updated in the local repository. Reflogs are
+useful in various Git commands, to specify the old value of a
+reference. For example, `HEAD@{2}` means "where HEAD used to be two
+moves ago", `master@{one.week.ago}` means "where master used to point
+to one week ago in this local repository", and so on. See
+linkgit:gitrevisions[7] for more details.
+
+The command takes various subcommands, and different options
+depending on the subcommand:
+
+The "show" subcommand (which is also the default, in the absence of
+any subcommands) shows the log of the reference provided in the
+command-line (or `HEAD`, by default). The reflog covers all recent
+actions, and in addition the `HEAD` reflog records branch switching.
+`git reflog show` is an alias for `git log -g --abbrev-commit
+--pretty=oneline`; see linkgit:git-log[1] for more information.
+
+The "list" subcommand lists all refs which have a corresponding reflog.
+
+The "expire" subcommand prunes older reflog entries. Entries older
+than `expire` time, or entries older than `expire-unreachable` time
+and not reachable from the current tip, are removed from the reflog.
+This is typically not used directly by end users -- instead, see
+linkgit:git-gc[1].
+
+The "delete" subcommand deletes single entries from the reflog. Its
+argument must be an _exact_ entry (e.g. "`git reflog delete
+master@{2}`"). This subcommand is also typically not used directly by
+end users.
+
+The "exists" subcommand checks whether a ref has a reflog. It exits
+with zero status if the reflog exists, and non-zero status if it does
+not.
+
+OPTIONS
+-------
+
+Options for `show`
+~~~~~~~~~~~~~~~~~~
+
+`git reflog show` accepts any of the options accepted by `git log`.
+
+
+Options for `expire`
+~~~~~~~~~~~~~~~~~~~~
+
+--all::
+ Process the reflogs of all references.
+
+--single-worktree::
+ By default when `--all` is specified, reflogs from all working
+ trees are processed. This option limits the processing to reflogs
+ from the current working tree only.
+
+--expire=<time>::
+ Prune entries older than the specified time. If this option is
+ not specified, the expiration time is taken from the
+ configuration setting `gc.reflogExpire`, which in turn
+ defaults to 90 days. `--expire=all` prunes entries regardless
+ of their age; `--expire=never` turns off pruning of reachable
+ entries (but see `--expire-unreachable`).
+
+--expire-unreachable=<time>::
+ Prune entries older than `<time>` that are not reachable from
+ the current tip of the branch. If this option is not
+ specified, the expiration time is taken from the configuration
+ setting `gc.reflogExpireUnreachable`, which in turn defaults
+ to 30 days. `--expire-unreachable=all` prunes unreachable
+ entries regardless of their age; `--expire-unreachable=never`
+ turns off early pruning of unreachable entries (but see
+ `--expire`).
+
+--updateref::
+ Update the reference to the value of the top reflog entry (i.e.
+ <ref>@\{0\}) if the previous top entry was pruned. (This
+ option is ignored for symbolic references.)
+
+--rewrite::
+ If a reflog entry's predecessor is pruned, adjust its "old"
+ SHA-1 to be equal to the "new" SHA-1 field of the entry that
+ now precedes it.
+
+--stale-fix::
+ Prune any reflog entries that point to "broken commits". A
+ broken commit is a commit that is not reachable from any of
+ the reference tips and that refers, directly or indirectly, to
+ a missing commit, tree, or blob object.
++
+This computation involves traversing all the reachable objects, i.e. it
+has the same cost as 'git prune'. It is primarily intended to fix
+corruption caused by garbage collecting using older versions of Git,
+which didn't protect objects referred to by reflogs.
+
+-n::
+--dry-run::
+ Do not actually prune any entries; just show what would have
+ been pruned.
+
+--verbose::
+ Print extra information on screen.
+
+
+Options for `delete`
+~~~~~~~~~~~~~~~~~~~~
+
+`git reflog delete` accepts options `--updateref`, `--rewrite`, `-n`,
+`--dry-run`, and `--verbose`, with the same meanings as when they are
+used with `expire`.
+
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-refs.adoc b/git-refs.adoc
new file mode 100644
index 0000000..95f2577
--- /dev/null
+++ b/git-refs.adoc
@@ -0,0 +1,72 @@
+git-refs(1)
+===========
+
+NAME
+----
+git-refs - Low-level access to refs
+
+
+SYNOPSIS
+--------
+[verse]
+'git refs migrate' --ref-format=<format> [--dry-run]
+'git refs verify' [--strict] [--verbose]
+
+DESCRIPTION
+-----------
+
+This command provides low-level access to refs.
+
+COMMANDS
+--------
+
+migrate::
+ Migrate ref store between different formats.
+
+verify::
+ Verify reference database consistency.
+
+OPTIONS
+-------
+
+The following options are specific to 'git refs migrate':
+
+--ref-format=<format>::
+ The ref format to migrate the ref store to. Can be one of:
++
+include::ref-storage-format.adoc[]
+
+--dry-run::
+ Perform the migration, but do not modify the repository. The migrated
+ refs will be written into a separate directory that can be inspected
+ separately. The name of the directory will be reported on stdout. This
+ can be used to double check that the migration works as expected before
+ performing the actual migration.
+
+The following options are specific to 'git refs verify':
+
+--strict::
+ Enable stricter error checking. This will cause warnings to be
+ reported as errors. See linkgit:git-fsck[1].
+
+--verbose::
+ When verifying the reference database consistency, be chatty.
+
+KNOWN LIMITATIONS
+-----------------
+
+The ref format migration has several known limitations in its current form:
+
+* It is not possible to migrate repositories that have worktrees.
+
+* There is no way to block concurrent writes to the repository during an
+ ongoing migration. Concurrent writes can lead to an inconsistent migrated
+ state. Users are expected to block writes on a higher level. If your
+ repository is registered for scheduled maintenance, it is recommended to
+ unregister it first with git-maintenance(1).
+
+These limitations may eventually be lifted.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-remote-ext.adoc b/git-remote-ext.adoc
new file mode 100644
index 0000000..b33ee3c
--- /dev/null
+++ b/git-remote-ext.adoc
@@ -0,0 +1,125 @@
+git-remote-ext(1)
+=================
+
+NAME
+----
+git-remote-ext - Bridge smart transport to external command.
+
+SYNOPSIS
+--------
+[verse]
+git remote add <nick> "ext::<command>[ <arguments>...]"
+
+DESCRIPTION
+-----------
+This remote helper uses the specified '<command>' to connect
+to a remote Git server.
+
+Data written to stdin of the specified '<command>' is assumed
+to be sent to a git:// server, git-upload-pack, git-receive-pack
+or git-upload-archive (depending on situation), and data read
+from stdout of <command> is assumed to be received from
+the same service.
+
+Command and arguments are separated by an unescaped space.
+
+The following sequences have a special meaning:
+
+'% '::
+ Literal space in command or argument.
+
+'%%'::
+ Literal percent sign.
+
+'%s'::
+ Replaced with name (receive-pack, upload-pack, or
+ upload-archive) of the service Git wants to invoke.
+
+'%S'::
+ Replaced with long name (git-receive-pack,
+ git-upload-pack, or git-upload-archive) of the service
+ Git wants to invoke.
+
+'%G' (must be the first characters in an argument)::
+ This argument will not be passed to '<command>'. Instead, it
+ will cause the helper to start by sending git:// service requests to
+ the remote side with the service field set to an appropriate value and
+ the repository field set to the rest of the argument. Default is not to send
+ such a request.
++
+This is useful if the remote side is git:// server accessed over
+some tunnel.
+
+'%V' (must be first characters in argument)::
+ This argument will not be passed to '<command>'. Instead it sets
+ the vhost field in the git:// service request (to the rest of the argument).
+ Default is not to send vhost in such request (if sent).
+
+ENVIRONMENT VARIABLES
+---------------------
+
+GIT_TRANSLOOP_DEBUG::
+ If set, prints debugging information about various reads/writes.
+
+ENVIRONMENT VARIABLES PASSED TO COMMAND
+---------------------------------------
+
+GIT_EXT_SERVICE::
+ Set to long name (git-upload-pack, etc...) of service helper needs
+ to invoke.
+
+GIT_EXT_SERVICE_NOPREFIX::
+ Set to long name (upload-pack, etc...) of service helper needs
+ to invoke.
+
+
+EXAMPLES
+--------
+This remote helper is transparently used by Git when
+you use commands such as "git fetch <URL>", "git clone <URL>",
+, "git push <URL>" or "git remote add <nick> <URL>", where <URL>
+begins with `ext::`. Examples:
+
+"ext::ssh -i /home/foo/.ssh/somekey user@host.example %S 'foo/repo'"::
+ Like host.example:foo/repo, but use /home/foo/.ssh/somekey as
+ keypair and user as the user on the remote side. This avoids the need to
+ edit .ssh/config.
+
+"ext::socat -t3600 - ABSTRACT-CONNECT:/git-server %G/somerepo"::
+ Represents repository with path /somerepo accessible over
+ git protocol at the abstract namespace address /git-server.
+
+"ext::git-server-alias foo %G/repo"::
+ Represents a repository with path /repo accessed using the
+ helper program "git-server-alias foo". The path to the
+ repository and type of request are not passed on the command
+ line but as part of the protocol stream, as usual with git://
+ protocol.
+
+"ext::git-server-alias foo %G/repo %Vfoo"::
+ Represents a repository with path /repo accessed using the
+ helper program "git-server-alias foo". The hostname for the
+ remote server passed in the protocol stream will be "foo"
+ (this allows multiple virtual Git servers to share a
+ link-level address).
+
+"ext::git-server-alias foo %G/repo% with% spaces %Vfoo"::
+ Represents a repository with path `/repo with spaces` accessed
+ using the helper program "git-server-alias foo". The hostname for
+ the remote server passed in the protocol stream will be "foo"
+ (this allows multiple virtual Git servers to share a
+ link-level address).
+
+"ext::git-ssl foo.example /bar"::
+ Represents a repository accessed using the helper program
+ "git-ssl foo.example /bar". The type of request can be
+ determined by the helper using environment variables (see
+ above).
+
+SEE ALSO
+--------
+linkgit:gitremote-helpers[7]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-remote-fd.adoc b/git-remote-fd.adoc
new file mode 100644
index 0000000..1dd2648
--- /dev/null
+++ b/git-remote-fd.adoc
@@ -0,0 +1,59 @@
+git-remote-fd(1)
+================
+
+NAME
+----
+git-remote-fd - Reflect smart transport stream back to caller
+
+SYNOPSIS
+--------
+"fd::<infd>[,<outfd>][/<anything>]" (as URL)
+
+DESCRIPTION
+-----------
+This helper uses specified file descriptors to connect to a remote Git server.
+This is not meant for end users but for programs and scripts calling git
+fetch, push, or archive.
+
+If only <infd> is given, it is assumed to be a bidirectional socket connected
+to a remote Git server (git-upload-pack, git-receive-pack, or
+git-upload-archive). If both <infd> and <outfd> are given, they are assumed
+to be pipes connected to a remote Git server (<infd> being the inbound pipe
+and <outfd> being the outbound pipe).
+
+It is assumed that any handshaking procedures have already been completed
+(such as sending service request for git://) before this helper is started.
+
+<anything> can be any string. It is ignored. It is meant for providing
+information to the user in the URL in case that URL is displayed in some
+context.
+
+ENVIRONMENT VARIABLES
+---------------------
+GIT_TRANSLOOP_DEBUG::
+ If set, prints debugging information about various reads/writes.
+
+EXAMPLES
+--------
+`git fetch fd::17 master`::
+ Fetch master, using file descriptor #17 to communicate with
+ git-upload-pack.
+
+`git fetch fd::17/foo master`::
+ Same as above.
+
+`git push fd::7,8 master (as URL)`::
+ Push master, using file descriptor #7 to read data from
+ git-receive-pack and file descriptor #8 to write data to
+ the same service.
+
+`git push fd::7,8/bar master`::
+ Same as above.
+
+SEE ALSO
+--------
+linkgit:gitremote-helpers[7]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-remote.adoc b/git-remote.adoc
new file mode 100644
index 0000000..932a5c3
--- /dev/null
+++ b/git-remote.adoc
@@ -0,0 +1,269 @@
+git-remote(1)
+=============
+
+NAME
+----
+git-remote - Manage set of tracked repositories
+
+
+SYNOPSIS
+--------
+[verse]
+'git remote' [-v | --verbose]
+'git remote add' [-t <branch>] [-m <master>] [-f] [--[no-]tags] [--mirror=(fetch|push)] <name> <URL>
+'git remote rename' [--[no-]progress] <old> <new>
+'git remote remove' <name>
+'git remote set-head' <name> (-a | --auto | -d | --delete | <branch>)
+'git remote set-branches' [--add] <name> <branch>...
+'git remote get-url' [--push] [--all] <name>
+'git remote set-url' [--push] <name> <newurl> [<oldurl>]
+'git remote set-url --add' [--push] <name> <newurl>
+'git remote set-url --delete' [--push] <name> <URL>
+'git remote' [-v | --verbose] 'show' [-n] <name>...
+'git remote prune' [-n | --dry-run] <name>...
+'git remote' [-v | --verbose] 'update' [-p | --prune] [(<group> | <remote>)...]
+
+DESCRIPTION
+-----------
+
+Manage the set of repositories ("remotes") whose branches you track.
+
+
+OPTIONS
+-------
+
+-v::
+--verbose::
+ Be a little more verbose and show remote url after name.
+ For promisor remotes, also show which filters (`blob:none` etc.)
+ are configured.
+ NOTE: This must be placed between `remote` and subcommand.
+
+
+COMMANDS
+--------
+
+With no arguments, shows a list of existing remotes. Several
+subcommands are available to perform operations on the remotes.
+
+'add'::
+
+Add a remote named <name> for the repository at
+<URL>. The command `git fetch <name>` can then be used to create and
+update remote-tracking branches <name>/<branch>.
++
+With `-f` option, `git fetch <name>` is run immediately after
+the remote information is set up.
++
+With `--tags` option, `git fetch <name>` imports every tag from the
+remote repository.
++
+With `--no-tags` option, `git fetch <name>` does not import tags from
+the remote repository.
++
+By default, only tags on fetched branches are imported
+(see linkgit:git-fetch[1]).
++
+With `-t <branch>` option, instead of the default glob
+refspec for the remote to track all branches under
+the `refs/remotes/<name>/` namespace, a refspec to track only `<branch>`
+is created. You can give more than one `-t <branch>` to track
+multiple branches without grabbing all branches.
++
+With `-m <master>` option, a symbolic-ref `refs/remotes/<name>/HEAD` is set
+up to point at remote's `<master>` branch. See also the set-head command.
++
+When a fetch mirror is created with `--mirror=fetch`, the refs will not
+be stored in the 'refs/remotes/' namespace, but rather everything in
+'refs/' on the remote will be directly mirrored into 'refs/' in the
+local repository. This option only makes sense in bare repositories,
+because a fetch would overwrite any local commits.
++
+When a push mirror is created with `--mirror=push`, then `git push`
+will always behave as if `--mirror` was passed.
+
+'rename'::
+
+Rename the remote named <old> to <new>. All remote-tracking branches and
+configuration settings for the remote are updated.
++
+In case <old> and <new> are the same, and <old> is a file under
+`$GIT_DIR/remotes` or `$GIT_DIR/branches`, the remote is converted to
+the configuration file format.
+
+'remove'::
+'rm'::
+
+Remove the remote named <name>. All remote-tracking branches and
+configuration settings for the remote are removed.
+
+'set-head'::
+
+Sets or deletes the default branch (i.e. the target of the
+symbolic-ref `refs/remotes/<name>/HEAD`) for
+the named remote. Having a default branch for a remote is not required,
+but allows the name of the remote to be specified in lieu of a specific
+branch. For example, if the default branch for `origin` is set to
+`master`, then `origin` may be specified wherever you would normally
+specify `origin/master`.
++
+With `-d` or `--delete`, the symbolic ref `refs/remotes/<name>/HEAD` is deleted.
++
+With `-a` or `--auto`, the remote is queried to determine its `HEAD`, then the
+symbolic-ref `refs/remotes/<name>/HEAD` is set to the same branch. e.g., if the remote
+`HEAD` is pointed at `next`, `git remote set-head origin -a` will set
+the symbolic-ref `refs/remotes/origin/HEAD` to `refs/remotes/origin/next`. This will
+only work if `refs/remotes/origin/next` already exists; if not it must be
+fetched first.
++
+Use `<branch>` to set the symbolic-ref `refs/remotes/<name>/HEAD` explicitly. e.g., `git
+remote set-head origin master` will set the symbolic-ref `refs/remotes/origin/HEAD` to
+`refs/remotes/origin/master`. This will only work if
+`refs/remotes/origin/master` already exists; if not it must be fetched first.
++
+
+'set-branches'::
+
+Changes the list of branches tracked by the named remote.
+This can be used to track a subset of the available remote branches
+after the initial setup for a remote.
++
+The named branches will be interpreted as if specified with the
+`-t` option on the `git remote add` command line.
++
+With `--add`, instead of replacing the list of currently tracked
+branches, adds to that list.
+
+'get-url'::
+
+Retrieves the URLs for a remote. Configurations for `insteadOf` and
+`pushInsteadOf` are expanded here. By default, only the first URL is listed.
++
+With `--push`, push URLs are queried rather than fetch URLs.
++
+With `--all`, all URLs for the remote will be listed.
+
+'set-url'::
+
+Changes URLs for the remote. Sets first URL for remote <name> that matches
+regex <oldurl> (first URL if no <oldurl> is given) to <newurl>. If
+<oldurl> doesn't match any URL, an error occurs and nothing is changed.
++
+With `--push`, push URLs are manipulated instead of fetch URLs.
++
+With `--add`, instead of changing existing URLs, new URL is added.
++
+With `--delete`, instead of changing existing URLs, all URLs matching
+regex <URL> are deleted for remote <name>. Trying to delete all
+non-push URLs is an error.
++
+Note that the push URL and the fetch URL, even though they can
+be set differently, must still refer to the same place. What you
+pushed to the push URL should be what you would see if you
+immediately fetched from the fetch URL. If you are trying to
+fetch from one place (e.g. your upstream) and push to another (e.g.
+your publishing repository), use two separate remotes.
+
+
+'show'::
+
+Gives some information about the remote <name>.
++
+With `-n` option, the remote heads are not queried first with
+`git ls-remote <name>`; cached information is used instead.
+
+'prune'::
+
+Deletes stale references associated with <name>. By default, stale
+remote-tracking branches under <name> are deleted, but depending on
+global configuration and the configuration of the remote we might even
+prune local tags that haven't been pushed there. Equivalent to `git
+fetch --prune <name>`, except that no new references will be fetched.
++
+See the PRUNING section of linkgit:git-fetch[1] for what it'll prune
+depending on various configuration.
++
+With `--dry-run` option, report what branches would be pruned, but do not
+actually prune them.
+
+'update'::
+
+Fetch updates for remotes or remote groups in the repository as defined by
+`remotes.<group>`. If neither group nor remote is specified on the command line,
+the configuration parameter remotes.default will be used; if
+remotes.default is not defined, all remotes which do not have the
+configuration parameter `remote.<name>.skipDefaultUpdate` set to true will
+be updated. (See linkgit:git-config[1]).
++
+With `--prune` option, run pruning against all the remotes that are updated.
+
+
+DISCUSSION
+----------
+
+The remote configuration is achieved using the `remote.origin.url` and
+`remote.origin.fetch` configuration variables. (See
+linkgit:git-config[1]).
+
+EXIT STATUS
+-----------
+
+On success, the exit status is `0`.
+
+When subcommands such as 'add', 'rename', and 'remove' can't find the
+remote in question, the exit status is `2`. When the remote already
+exists, the exit status is `3`.
+
+On any other error, the exit status may be any other non-zero value.
+
+EXAMPLES
+--------
+
+* Add a new remote, fetch, and check out a branch from it
++
+------------
+$ git remote
+origin
+$ git branch -r
+ origin/HEAD -> origin/master
+ origin/master
+$ git remote add staging git://git.kernel.org/.../gregkh/staging.git
+$ git remote
+origin
+staging
+$ git fetch staging
+...
+From git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
+ * [new branch] master -> staging/master
+ * [new branch] staging-linus -> staging/staging-linus
+ * [new branch] staging-next -> staging/staging-next
+$ git branch -r
+ origin/HEAD -> origin/master
+ origin/master
+ staging/master
+ staging/staging-linus
+ staging/staging-next
+$ git switch -c staging staging/master
+...
+------------
+
+* Imitate 'git clone' but track only selected branches
++
+------------
+$ mkdir project.git
+$ cd project.git
+$ git init
+$ git remote add -f -t master -m master origin git://example.com/git.git/
+$ git merge origin
+------------
+
+
+SEE ALSO
+--------
+linkgit:git-fetch[1]
+linkgit:git-branch[1]
+linkgit:git-config[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-repack.adoc b/git-repack.adoc
new file mode 100644
index 0000000..5852a5c
--- /dev/null
+++ b/git-repack.adoc
@@ -0,0 +1,286 @@
+git-repack(1)
+=============
+
+NAME
+----
+git-repack - Pack unpacked objects in a repository
+
+
+SYNOPSIS
+--------
+[verse]
+'git repack' [-a] [-A] [-d] [-f] [-F] [-l] [-n] [-q] [-b] [-m]
+ [--window=<n>] [--depth=<n>] [--threads=<n>] [--keep-pack=<pack-name>]
+ [--write-midx] [--name-hash-version=<n>]
+
+DESCRIPTION
+-----------
+
+This command is used to combine all objects that do not currently
+reside in a "pack", into a pack. It can also be used to re-organize
+existing packs into a single, more efficient pack.
+
+A pack is a collection of objects, individually compressed, with
+delta compression applied, stored in a single file, with an
+associated index file.
+
+Packs are used to reduce the load on mirror systems, backup
+engines, disk storage, etc.
+
+OPTIONS
+-------
+
+-a::
+ Instead of incrementally packing the unpacked objects,
+ pack everything referenced into a single pack.
+ Especially useful when packing a repository that is used
+ for private development. Use
+ with `-d`. This will clean up the objects that `git prune`
+ leaves behind, but `git fsck --full --dangling` shows as
+ dangling.
++
+Note that users fetching over dumb protocols will have to fetch the
+whole new pack in order to get any contained object, no matter how many
+other objects in that pack they already have locally.
++
+Promisor packfiles are repacked separately: if there are packfiles that
+have an associated ".promisor" file, these packfiles will be repacked
+into another separate pack, and an empty ".promisor" file corresponding
+to the new separate pack will be written.
+
+-A::
+ Same as `-a`, unless `-d` is used. Then any unreachable
+ objects in a previous pack become loose, unpacked objects,
+ instead of being left in the old pack. Unreachable objects
+ are never intentionally added to a pack, even when repacking.
+ This option prevents unreachable objects from being immediately
+ deleted by way of being left in the old pack and then
+ removed. Instead, the loose unreachable objects
+ will be pruned according to normal expiry rules
+ with the next 'git gc' invocation. See linkgit:git-gc[1].
+
+-d::
+ After packing, if the newly created packs make some
+ existing packs redundant, remove the redundant packs.
+ Also run 'git prune-packed' to remove redundant
+ loose object files.
+
+--cruft::
+ Same as `-a`, unless `-d` is used. Then any unreachable objects
+ are packed into a separate cruft pack. Unreachable objects can
+ be pruned using the normal expiry rules with the next `git gc`
+ invocation (see linkgit:git-gc[1]). Incompatible with `-k`.
+
+--cruft-expiration=<approxidate>::
+ Expire unreachable objects older than `<approxidate>`
+ immediately instead of waiting for the next `git gc` invocation.
+ Only useful with `--cruft -d`.
+
+--max-cruft-size=<n>::
+ Repack cruft objects into packs as large as `<n>` bytes before
+ creating new packs. As long as there are enough cruft packs
+ smaller than `<n>`, repacking will cause a new cruft pack to
+ be created containing objects from any combined cruft packs,
+ along with any new unreachable objects. Cruft packs larger than
+ `<n>` will not be modified. When the new cruft pack is larger
+ than `<n>` bytes, it will be split into multiple packs, all of
+ which are guaranteed to be at most `<n>` bytes in size. Only
+ useful with `--cruft -d`.
+
+--expire-to=<dir>::
+ Write a cruft pack containing pruned objects (if any) to the
+ directory `<dir>`. This option is useful for keeping a copy of
+ any pruned objects in a separate directory as a backup. Only
+ useful with `--cruft -d`.
+
+-l::
+ Pass the `--local` option to 'git pack-objects'. See
+ linkgit:git-pack-objects[1].
+
+-f::
+ Pass the `--no-reuse-delta` option to `git-pack-objects`, see
+ linkgit:git-pack-objects[1].
+
+-F::
+ Pass the `--no-reuse-object` option to `git-pack-objects`, see
+ linkgit:git-pack-objects[1].
+
+-q::
+--quiet::
+ Show no progress over the standard error stream and pass the `-q`
+ option to 'git pack-objects'. See linkgit:git-pack-objects[1].
+
+-n::
+ Do not update the server information with
+ 'git update-server-info'. This option skips
+ updating local catalog files needed to publish
+ this repository (or a direct copy of it)
+ over HTTP or FTP. See linkgit:git-update-server-info[1].
+
+--window=<n>::
+--depth=<n>::
+ These two options affect how the objects contained in the pack are
+ stored using delta compression. The objects are first internally
+ sorted by type, size and optionally names and compared against the
+ other objects within `--window` to see if using delta compression saves
+ space. `--depth` limits the maximum delta depth; making it too deep
+ affects the performance on the unpacker side, because delta data needs
+ to be applied that many times to get to the necessary object.
++
+The default value for --window is 10 and --depth is 50. The maximum
+depth is 4095.
+
+--threads=<n>::
+ This option is passed through to `git pack-objects`.
+
+--window-memory=<n>::
+ This option provides an additional limit on top of `--window`;
+ the window size will dynamically scale down so as to not take
+ up more than '<n>' bytes in memory. This is useful in
+ repositories with a mix of large and small objects to not run
+ out of memory with a large window, but still be able to take
+ advantage of the large window for the smaller objects. The
+ size can be suffixed with "k", "m", or "g".
+ `--window-memory=0` makes memory usage unlimited. The default
+ is taken from the `pack.windowMemory` configuration variable.
+ Note that the actual memory usage will be the limit multiplied
+ by the number of threads used by linkgit:git-pack-objects[1].
+
+--max-pack-size=<n>::
+ Maximum size of each output pack file. The size can be suffixed with
+ "k", "m", or "g". The minimum size allowed is limited to 1 MiB.
+ If specified, multiple packfiles may be created, which also
+ prevents the creation of a bitmap index.
+ The default is unlimited, unless the config variable
+ `pack.packSizeLimit` is set. Note that this option may result in
+ a larger and slower repository; see the discussion in
+ `pack.packSizeLimit`.
+
+--filter=<filter-spec>::
+ Remove objects matching the filter specification from the
+ resulting packfile and put them into a separate packfile. Note
+ that objects used in the working directory are not filtered
+ out. So for the split to fully work, it's best to perform it
+ in a bare repo and to use the `-a` and `-d` options along with
+ this option. Also `--no-write-bitmap-index` (or the
+ `repack.writebitmaps` config option set to `false`) should be
+ used otherwise writing bitmap index will fail, as it supposes
+ a single packfile containing all the objects. See
+ linkgit:git-rev-list[1] for valid `<filter-spec>` forms.
+
+--filter-to=<dir>::
+ Write the pack containing filtered out objects to the
+ directory `<dir>`. Only useful with `--filter`. This can be
+ used for putting the pack on a separate object directory that
+ is accessed through the Git alternates mechanism. **WARNING:**
+ If the packfile containing the filtered out objects is not
+ accessible, the repo can become corrupt as it might not be
+ possible to access the objects in that packfile. See the
+ `objects` and `objects/info/alternates` sections of
+ linkgit:gitrepository-layout[5].
+
+-b::
+--write-bitmap-index::
+ Write a reachability bitmap index as part of the repack. This
+ only makes sense when used with `-a`, `-A` or `-m`, as the bitmaps
+ must be able to refer to all reachable objects. This option
+ overrides the setting of `repack.writeBitmaps`. This option
+ has no effect if multiple packfiles are created, unless writing a
+ MIDX (in which case a multi-pack bitmap is created).
+
+--pack-kept-objects::
+ Include objects in `.keep` files when repacking. Note that we
+ still do not delete `.keep` packs after `pack-objects` finishes.
+ This means that we may duplicate objects, but this makes the
+ option safe to use when there are concurrent pushes or fetches.
+ This option is generally only useful if you are writing bitmaps
+ with `-b` or `repack.writeBitmaps`, as it ensures that the
+ bitmapped packfile has the necessary objects.
+
+--keep-pack=<pack-name>::
+ Exclude the given pack from repacking. This is the equivalent
+ of having `.keep` file on the pack. `<pack-name>` is the
+ pack file name without leading directory (e.g. `pack-123.pack`).
+ The option can be specified multiple times to keep multiple
+ packs.
+
+--unpack-unreachable=<when>::
+ When loosening unreachable objects, do not bother loosening any
+ objects older than `<when>`. This can be used to optimize out
+ the write of any objects that would be immediately pruned by
+ a follow-up `git prune`.
+
+-k::
+--keep-unreachable::
+ When used with `-ad`, any unreachable objects from existing
+ packs will be appended to the end of the packfile instead of
+ being removed. In addition, any unreachable loose objects will
+ be packed (and their loose counterparts removed).
+
+-i::
+--delta-islands::
+ Pass the `--delta-islands` option to `git-pack-objects`, see
+ linkgit:git-pack-objects[1].
+
+-g<factor>::
+--geometric=<factor>::
+ Arrange resulting pack structure so that each successive pack
+ contains at least `<factor>` times the number of objects as the
+ next-largest pack.
++
+`git repack` ensures this by determining a "cut" of packfiles that need
+to be repacked into one in order to ensure a geometric progression. It
+picks the smallest set of packfiles such that as many of the larger
+packfiles (by count of objects contained in that pack) may be left
+intact.
++
+Unlike other repack modes, the set of objects to pack is determined
+uniquely by the set of packs being "rolled-up"; in other words, the
+packs determined to need to be combined in order to restore a geometric
+progression.
++
+Loose objects are implicitly included in this "roll-up", without respect to
+their reachability. This is subject to change in the future.
++
+When writing a multi-pack bitmap, `git repack` selects the largest resulting
+pack as the preferred pack for object selection by the MIDX (see
+linkgit:git-multi-pack-index[1]).
+
+-m::
+--write-midx::
+ Write a multi-pack index (see linkgit:git-multi-pack-index[1])
+ containing the non-redundant packs.
+
+--name-hash-version=<n>::
+ Provide this argument to the underlying `git pack-objects` process.
+ See linkgit:git-pack-objects[1] for full details.
+
+
+CONFIGURATION
+-------------
+
+Various configuration variables affect packing, see
+linkgit:git-config[1] (search for "pack" and "delta").
+
+By default, the command passes `--delta-base-offset` option to
+'git pack-objects'; this typically results in slightly smaller packs,
+but the generated packs are incompatible with versions of Git older than
+version 1.4.4. If you need to share your repository with such ancient Git
+versions, either directly or via the dumb http protocol, then you
+need to set the configuration variable `repack.UseDeltaBaseOffset` to
+"false" and repack. Access from old Git versions over the native protocol
+is unaffected by this option as the conversion is performed on the fly
+as needed in that case.
+
+Delta compression is not used on objects larger than the
+`core.bigFileThreshold` configuration variable and on files with the
+attribute `delta` set to false.
+
+SEE ALSO
+--------
+linkgit:git-pack-objects[1]
+linkgit:git-prune-packed[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-replace.adoc b/git-replace.adoc
new file mode 100644
index 0000000..0a65460
--- /dev/null
+++ b/git-replace.adoc
@@ -0,0 +1,161 @@
+git-replace(1)
+==============
+
+NAME
+----
+git-replace - Create, list, delete refs to replace objects
+
+SYNOPSIS
+--------
+[verse]
+'git replace' [-f] <object> <replacement>
+'git replace' [-f] --edit <object>
+'git replace' [-f] --graft <commit> [<parent>...]
+'git replace' [-f] --convert-graft-file
+'git replace' -d <object>...
+'git replace' [--format=<format>] [-l [<pattern>]]
+
+DESCRIPTION
+-----------
+Adds a 'replace' reference in `refs/replace/` namespace.
+
+The name of the 'replace' reference is the SHA-1 of the object that is
+replaced. The content of the 'replace' reference is the SHA-1 of the
+replacement object.
+
+The replaced object and the replacement object must be of the same type.
+This restriction can be bypassed using `-f`.
+
+Unless `-f` is given, the 'replace' reference must not yet exist.
+
+There is no other restriction on the replaced and replacement objects.
+Merge commits can be replaced by non-merge commits and vice versa.
+
+Replacement references will be used by default by all Git commands
+except those doing reachability traversal (prune, pack transfer and
+fsck).
+
+It is possible to disable the use of replacement references for any
+command using the `--no-replace-objects` option just after 'git'.
+
+For example if commit 'foo' has been replaced by commit 'bar':
+
+------------------------------------------------
+$ git --no-replace-objects cat-file commit foo
+------------------------------------------------
+
+shows information about commit 'foo', while:
+
+------------------------------------------------
+$ git cat-file commit foo
+------------------------------------------------
+
+shows information about commit 'bar'.
+
+The `GIT_NO_REPLACE_OBJECTS` environment variable can be set to
+achieve the same effect as the `--no-replace-objects` option.
+
+OPTIONS
+-------
+-f::
+--force::
+ If an existing replace ref for the same object exists, it will
+ be overwritten (instead of failing).
+
+-d::
+--delete::
+ Delete existing replace refs for the given objects.
+
+--edit <object>::
+ Edit an object's content interactively. The existing content
+ for <object> is pretty-printed into a temporary file, an
+ editor is launched on the file, and the result is parsed to
+ create a new object of the same type as <object>. A
+ replacement ref is then created to replace <object> with the
+ newly created object. See linkgit:git-var[1] for details about
+ how the editor will be chosen.
+
+--raw::
+ When editing, provide the raw object contents rather than
+ pretty-printed ones. Currently this only affects trees, which
+ will be shown in their binary form. This is harder to work with,
+ but can help when repairing a tree that is so corrupted it
+ cannot be pretty-printed. Note that you may need to configure
+ your editor to cleanly read and write binary data.
+
+--graft <commit> [<parent>...]::
+ Create a graft commit. A new commit is created with the same
+ content as <commit> except that its parents will be
+ [<parent>...] instead of <commit>'s parents. A replacement ref
+ is then created to replace <commit> with the newly created
+ commit. Use `--convert-graft-file` to convert a
+ `$GIT_DIR/info/grafts` file and use replace refs instead.
+
+--convert-graft-file::
+ Creates graft commits for all entries in `$GIT_DIR/info/grafts`
+ and deletes that file upon success. The purpose is to help users
+ with transitioning off of the now-deprecated graft file.
+
+-l <pattern>::
+--list <pattern>::
+ List replace refs for objects that match the given pattern (or
+ all if no pattern is given).
+ Typing "git replace" without arguments, also lists all replace
+ refs.
+
+--format=<format>::
+ When listing, use the specified <format>, which can be one of
+ 'short', 'medium' and 'long'. When omitted, the format
+ defaults to 'short'.
+
+FORMATS
+-------
+
+The following formats are available:
+
+* 'short':
+ <replaced-sha1>
+* 'medium':
+ <replaced-sha1> -> <replacement-sha1>
+* 'long':
+ <replaced-sha1> (<replaced-type>) -> <replacement-sha1> (<replacement-type>)
+
+CREATING REPLACEMENT OBJECTS
+----------------------------
+
+linkgit:git-hash-object[1], linkgit:git-rebase[1], and
+https://github.com/newren/git-filter-repo[git-filter-repo], among other git commands, can be used to
+create replacement objects from existing objects. The `--edit` option
+can also be used with 'git replace' to create a replacement object by
+editing an existing object.
+
+If you want to replace many blobs, trees or commits that are part of a
+string of commits, you may just want to create a replacement string of
+commits and then only replace the commit at the tip of the target
+string of commits with the commit at the tip of the replacement string
+of commits.
+
+BUGS
+----
+Comparing blobs or trees that have been replaced with those that
+replace them will not work properly. And using `git reset --hard` to
+go back to a replaced commit will move the branch to the replacement
+commit instead of the replaced commit.
+
+There may be other problems when using 'git rev-list' related to
+pending objects.
+
+SEE ALSO
+--------
+linkgit:git-hash-object[1]
+linkgit:git-rebase[1]
+linkgit:git-tag[1]
+linkgit:git-branch[1]
+linkgit:git-commit[1]
+linkgit:git-var[1]
+linkgit:git[1]
+https://github.com/newren/git-filter-repo[git-filter-repo]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-replay.adoc b/git-replay.adoc
new file mode 100644
index 0000000..0b12bf8
--- /dev/null
+++ b/git-replay.adoc
@@ -0,0 +1,127 @@
+git-replay(1)
+=============
+
+NAME
+----
+git-replay - EXPERIMENTAL: Replay commits on a new base, works with bare repos too
+
+
+SYNOPSIS
+--------
+[verse]
+(EXPERIMENTAL!) 'git replay' ([--contained] --onto <newbase> | --advance <branch>) <revision-range>...
+
+DESCRIPTION
+-----------
+
+Takes ranges of commits and replays them onto a new location. Leaves
+the working tree and the index untouched, and updates no references.
+The output of this command is meant to be used as input to
+`git update-ref --stdin`, which would update the relevant branches
+(see the OUTPUT section below).
+
+THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
+
+OPTIONS
+-------
+
+--onto <newbase>::
+ Starting point at which to create the new commits. May be any
+ valid commit, and not just an existing branch name.
++
+When `--onto` is specified, the update-ref command(s) in the output will
+update the branch(es) in the revision range to point at the new
+commits, similar to the way how `git rebase --update-refs` updates
+multiple branches in the affected range.
+
+--advance <branch>::
+ Starting point at which to create the new commits; must be a
+ branch name.
++
+When `--advance` is specified, the update-ref command(s) in the output
+will update the branch passed as an argument to `--advance` to point at
+the new commits (in other words, this mimics a cherry-pick operation).
+
+<revision-range>::
+ Range of commits to replay. More than one <revision-range> can
+ be passed, but in `--advance <branch>` mode, they should have
+ a single tip, so that it's clear where <branch> should point
+ to. See "Specifying Ranges" in linkgit:git-rev-parse[1] and the
+ "Commit Limiting" options below.
+
+include::rev-list-options.adoc[]
+
+OUTPUT
+------
+
+When there are no conflicts, the output of this command is usable as
+input to `git update-ref --stdin`. It is of the form:
+
+ update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH}
+ update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH}
+ update refs/heads/branch3 ${NEW_branch3_HASH} ${OLD_branch3_HASH}
+
+where the number of refs updated depends on the arguments passed and
+the shape of the history being replayed. When using `--advance`, the
+number of refs updated is always one, but for `--onto`, it can be one
+or more (rebasing multiple branches simultaneously is supported).
+
+EXIT STATUS
+-----------
+
+For a successful, non-conflicted replay, the exit status is 0. When
+the replay has conflicts, the exit status is 1. If the replay is not
+able to complete (or start) due to some kind of error, the exit status
+is something other than 0 or 1.
+
+EXAMPLES
+--------
+
+To simply rebase `mybranch` onto `target`:
+
+------------
+$ git replay --onto target origin/main..mybranch
+update refs/heads/mybranch ${NEW_mybranch_HASH} ${OLD_mybranch_HASH}
+------------
+
+To cherry-pick the commits from mybranch onto target:
+
+------------
+$ git replay --advance target origin/main..mybranch
+update refs/heads/target ${NEW_target_HASH} ${OLD_target_HASH}
+------------
+
+Note that the first two examples replay the exact same commits and on
+top of the exact same new base, they only differ in that the first
+provides instructions to make mybranch point at the new commits and
+the second provides instructions to make target point at them.
+
+What if you have a stack of branches, one depending upon another, and
+you'd really like to rebase the whole set?
+
+------------
+$ git replay --contained --onto origin/main origin/main..tipbranch
+update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH}
+update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH}
+update refs/heads/tipbranch ${NEW_tipbranch_HASH} ${OLD_tipbranch_HASH}
+------------
+
+When calling `git replay`, one does not need to specify a range of
+commits to replay using the syntax `A..B`; any range expression will
+do:
+
+------------
+$ git replay --onto origin/main ^base branch1 branch2 branch3
+update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH}
+update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH}
+update refs/heads/branch3 ${NEW_branch3_HASH} ${OLD_branch3_HASH}
+------------
+
+This will simultaneously rebase `branch1`, `branch2`, and `branch3`,
+all commits they have since `base`, playing them on top of
+`origin/main`. These three branches may have commits on top of `base`
+that they have in common, but that does not need to be the case.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-request-pull.adoc b/git-request-pull.adoc
new file mode 100644
index 0000000..15dcbb6
--- /dev/null
+++ b/git-request-pull.adoc
@@ -0,0 +1,79 @@
+git-request-pull(1)
+===================
+
+NAME
+----
+git-request-pull - Generates a summary of pending changes
+
+SYNOPSIS
+--------
+[verse]
+'git request-pull' [-p] <start> <URL> [<end>]
+
+DESCRIPTION
+-----------
+
+Generate a request asking your upstream project to pull changes into
+their tree. The request, printed to the standard output,
+begins with the branch description, summarizes
+the changes, and indicates from where they can be pulled.
+
+The upstream project is expected to have the commit named by
+`<start>` and the output asks it to integrate the changes you made
+since that commit, up to the commit named by `<end>`, by visiting
+the repository named by `<URL>`.
+
+
+OPTIONS
+-------
+-p::
+ Include patch text in the output.
+
+<start>::
+ Commit to start at. This names a commit that is already in
+ the upstream history.
+
+<URL>::
+ The repository URL to be pulled from.
+
+<end>::
+ Commit to end at (defaults to HEAD). This names the commit
+ at the tip of the history you are asking to be pulled.
++
+When the repository named by `<URL>` has the commit at a tip of a
+ref that is different from the ref you have locally, you can use the
+`<local>:<remote>` syntax, to have its local name, a colon `:`, and
+its remote name.
+
+
+EXAMPLES
+--------
+
+Imagine that you built your work on your `master` branch on top of
+the `v1.0` release, and want it to be integrated into the project.
+First you push that change to your public repository for others to
+see:
+
+ git push https://git.ko.xz/project master
+
+Then, you run this command:
+
+ git request-pull v1.0 https://git.ko.xz/project master
+
+which will produce a request to the upstream, summarizing the
+changes between the `v1.0` release and your `master`, to pull it
+from your public repository.
+
+If you pushed your change to a branch whose name is different from
+the one you have locally, e.g.
+
+ git push https://git.ko.xz/project master:for-linus
+
+then you can ask that to be pulled with
+
+ git request-pull v1.0 https://git.ko.xz/project master:for-linus
+
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-rerere.adoc b/git-rerere.adoc
new file mode 100644
index 0000000..992b469
--- /dev/null
+++ b/git-rerere.adoc
@@ -0,0 +1,222 @@
+git-rerere(1)
+=============
+
+NAME
+----
+git-rerere - Reuse recorded resolution of conflicted merges
+
+SYNOPSIS
+--------
+[verse]
+'git rerere' [clear | forget <pathspec>... | diff | status | remaining | gc]
+
+DESCRIPTION
+-----------
+
+In a workflow employing relatively long lived topic branches,
+the developer sometimes needs to resolve the same conflicts over
+and over again until the topic branches are done (either merged
+to the "release" branch, or sent out and accepted upstream).
+
+This command assists the developer in this process by recording
+conflicted automerge results and corresponding hand resolve results
+on the initial manual merge, and applying previously recorded
+hand resolutions to their corresponding automerge results.
+
+[NOTE]
+You need to set the configuration variable `rerere.enabled` in order to
+enable this command.
+
+
+COMMANDS
+--------
+
+Normally, 'git rerere' is run without arguments or user-intervention.
+However, it has several commands that allow it to interact with
+its working state.
+
+'clear'::
+
+Reset the metadata used by rerere if a merge resolution is to be
+aborted. Calling 'git am [--skip|--abort]' or 'git rebase [--skip|--abort]'
+will automatically invoke this command.
+
+'forget' <pathspec>::
+
+Reset the conflict resolutions which rerere has recorded for the current
+conflict in <pathspec>.
+
+'diff'::
+
+Display diffs for the current state of the resolution. It is
+useful for tracking what has changed while the user is resolving
+conflicts. Additional arguments are passed directly to the system
+'diff' command installed in PATH.
+
+'status'::
+
+Print paths with conflicts whose merge resolution rerere will record.
+
+'remaining'::
+
+Print paths with conflicts that have not been autoresolved by rerere.
+This includes paths whose resolutions cannot be tracked by rerere,
+such as conflicting submodules.
+
+'gc'::
+
+Prune records of conflicted merges that
+occurred a long time ago. By default, unresolved conflicts older
+than 15 days and resolved conflicts older than 60
+days are pruned. These defaults are controlled via the
+`gc.rerereUnresolved` and `gc.rerereResolved` configuration
+variables respectively.
+
+
+DISCUSSION
+----------
+
+When your topic branch modifies an overlapping area that your
+master branch (or upstream) touched since your topic branch
+forked from it, you may want to test it with the latest master,
+even before your topic branch is ready to be pushed upstream:
+
+------------
+ o---*---o topic
+ /
+ o---o---o---*---o---o master
+------------
+
+For such a test, you need to merge master and topic somehow.
+One way to do it is to pull master into the topic branch:
+
+------------
+ $ git switch topic
+ $ git merge master
+
+ o---*---o---+ topic
+ / /
+ o---o---o---*---o---o master
+------------
+
+The commits marked with `*` touch the same area in the same
+file; you need to resolve the conflicts when creating the commit
+marked with `+`. Then you can test the result to make sure your
+work-in-progress still works with what is in the latest master.
+
+After this test merge, there are two ways to continue your work
+on the topic. The easiest is to build on top of the test merge
+commit `+`, and when your work in the topic branch is finally
+ready, pull the topic branch into master, and/or ask the
+upstream to pull from you. By that time, however, the master or
+the upstream might have been advanced since the test merge `+`,
+in which case the final commit graph would look like this:
+
+------------
+ $ git switch topic
+ $ git merge master
+ $ ... work on both topic and master branches
+ $ git switch master
+ $ git merge topic
+
+ o---*---o---+---o---o topic
+ / / \
+ o---o---o---*---o---o---o---o---+ master
+------------
+
+When your topic branch is long-lived, however, your topic branch
+would end up having many such "Merge from master" commits on it,
+which would unnecessarily clutter the development history.
+Readers of the Linux kernel mailing list may remember that Linus
+complained about such too frequent test merges when a subsystem
+maintainer asked to pull from a branch full of "useless merges".
+
+As an alternative, to keep the topic branch clean of test
+merges, you could blow away the test merge, and keep building on
+top of the tip before the test merge:
+
+------------
+ $ git switch topic
+ $ git merge master
+ $ git reset --hard HEAD^ ;# rewind the test merge
+ $ ... work on both topic and master branches
+ $ git switch master
+ $ git merge topic
+
+ o---*---o-------o---o topic
+ / \
+ o---o---o---*---o---o---o---o---+ master
+------------
+
+This would leave only one merge commit when your topic branch is
+finally ready and merged into the master branch. This merge
+would require you to resolve the conflict, introduced by the
+commits marked with `*`. However, this conflict is often the
+same conflict you resolved when you created the test merge you
+blew away. 'git rerere' helps you resolve this final
+conflicted merge using the information from your earlier hand
+resolve.
+
+Running the 'git rerere' command immediately after a conflicted
+automerge records the conflicted working tree files, with the
+usual conflict markers `<<<<<<<`, `=======`, and `>>>>>>>` in
+them. Later, after you are done resolving the conflicts,
+running 'git rerere' again will record the resolved state of these
+files. Suppose you did this when you created the test merge of
+master into the topic branch.
+
+Next time, after seeing the same conflicted automerge,
+running 'git rerere' will perform a three-way merge between the
+earlier conflicted automerge, the earlier manual resolution, and
+the current conflicted automerge.
+If this three-way merge resolves cleanly, the result is written
+out to your working tree file, so you do not have to manually
+resolve it. Note that 'git rerere' leaves the index file alone,
+so you still need to do the final sanity checks with `git diff`
+(or `git diff -c`) and 'git add' when you are satisfied.
+
+As a convenience measure, 'git merge' automatically invokes
+'git rerere' upon exiting with a failed automerge and 'git rerere'
+records the hand resolve when it is a new conflict, or reuses the earlier hand
+resolve when it is not. 'git commit' also invokes 'git rerere'
+when committing a merge result. What this means is that you do
+not have to do anything special yourself (besides enabling
+the rerere.enabled config variable).
+
+In our example, when you do the test merge, the manual
+resolution is recorded, and it will be reused when you do the
+actual merge later with the updated master and topic branch, as long
+as the recorded resolution is still applicable.
+
+The information 'git rerere' records is also used when running
+'git rebase'. After blowing away the test merge and continuing
+development on the topic branch:
+
+------------
+ o---*---o-------o---o topic
+ /
+ o---o---o---*---o---o---o---o master
+
+ $ git rebase master topic
+
+ o---*---o-------o---o topic
+ /
+ o---o---o---*---o---o---o---o master
+------------
+
+you could run `git rebase master topic`, to bring yourself
+up to date before your topic is ready to be sent upstream.
+This would result in falling back to a three-way merge, and it
+would conflict the same way as the test merge you resolved earlier.
+'git rerere' will be run by 'git rebase' to help you resolve this
+conflict.
+
+[NOTE] 'git rerere' relies on the conflict markers in the file to
+detect the conflict. If the file already contains lines that look the
+same as lines with conflict markers, 'git rerere' may fail to record a
+conflict resolution. To work around this, the `conflict-marker-size`
+setting in linkgit:gitattributes[5] can be used.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-reset.adoc b/git-reset.adoc
new file mode 100644
index 0000000..79ad564
--- /dev/null
+++ b/git-reset.adoc
@@ -0,0 +1,506 @@
+git-reset(1)
+============
+
+NAME
+----
+git-reset - Reset current HEAD to the specified state
+
+SYNOPSIS
+--------
+[verse]
+'git reset' [-q] [<tree-ish>] [--] <pathspec>...
+'git reset' [-q] [--pathspec-from-file=<file> [--pathspec-file-nul]] [<tree-ish>]
+'git reset' (--patch | -p) [<tree-ish>] [--] [<pathspec>...]
+'git reset' [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] [<commit>]
+
+DESCRIPTION
+-----------
+In the first three forms, copy entries from `<tree-ish>` to the index.
+In the last form, set the current branch head (`HEAD`) to `<commit>`,
+optionally modifying index and working tree to match.
+The `<tree-ish>`/`<commit>` defaults to `HEAD` in all forms.
+
+'git reset' [-q] [<tree-ish>] [--] <pathspec>...::
+'git reset' [-q] [--pathspec-from-file=<file> [--pathspec-file-nul]] [<tree-ish>]::
+ These forms reset the index entries for all paths that match the
+ `<pathspec>` to their state at `<tree-ish>`. (It does not affect
+ the working tree or the current branch.)
++
+This means that `git reset <pathspec>` is the opposite of `git add
+<pathspec>`. This command is equivalent to
+`git restore [--source=<tree-ish>] --staged <pathspec>...`.
++
+After running `git reset <pathspec>` to update the index entry, you can
+use linkgit:git-restore[1] to check the contents out of the index to
+the working tree. Alternatively, using linkgit:git-restore[1]
+and specifying a commit with `--source`, you
+can copy the contents of a path out of a commit to the index and to the
+working tree in one go.
+
+'git reset' (--patch | -p) [<tree-ish>] [--] [<pathspec>...]::
+ Interactively select hunks in the difference between the index
+ and `<tree-ish>` (defaults to `HEAD`). The chosen hunks are applied
+ in reverse to the index.
++
+This means that `git reset -p` is the opposite of `git add -p`, i.e.
+you can use it to selectively reset hunks. See the ``Interactive Mode''
+section of linkgit:git-add[1] to learn how to operate the `--patch` mode.
+
+'git reset' [<mode>] [<commit>]::
+ This form resets the current branch head to `<commit>` and
+ possibly updates the index (resetting it to the tree of `<commit>`) and
+ the working tree depending on `<mode>`. Before the operation, `ORIG_HEAD`
+ is set to the tip of the current branch. If `<mode>` is omitted,
+ defaults to `--mixed`. The `<mode>` must be one of the following:
++
+--
+--soft::
+ Does not touch the index file or the working tree at all (but
+ resets the head to `<commit>`, just like all modes do). This leaves
+ all your changed files "Changes to be committed", as `git status`
+ would put it.
+
+--mixed::
+ Resets the index but not the working tree (i.e., the changed files
+ are preserved but not marked for commit) and reports what has not
+ been updated. This is the default action.
++
+If `-N` is specified, removed paths are marked as intent-to-add (see
+linkgit:git-add[1]).
+
+--hard::
+ Resets the index and working tree. Any changes to tracked files in the
+ working tree since `<commit>` are discarded. Any untracked files or
+ directories in the way of writing any tracked files are simply deleted.
+
+--merge::
+ Resets the index and updates the files in the working tree that are
+ different between `<commit>` and `HEAD`, but keeps those which are
+ different between the index and working tree (i.e. which have changes
+ which have not been added).
+ If a file that is different between `<commit>` and the index has
+ unstaged changes, reset is aborted.
++
+In other words, `--merge` does something like a `git read-tree -u -m <commit>`,
+but carries forward unmerged index entries.
+
+--keep::
+ Resets index entries and updates files in the working tree that are
+ different between `<commit>` and `HEAD`.
+ If a file that is different between `<commit>` and `HEAD` has local
+ changes, reset is aborted.
+
+--[no-]recurse-submodules::
+ When the working tree is updated, using --recurse-submodules will
+ also recursively reset the working tree of all active submodules
+ according to the commit recorded in the superproject, also setting
+ the submodules' HEAD to be detached at that commit.
+--
+
+See "Reset, restore and revert" in linkgit:git[1] for the differences
+between the three commands.
+
+
+OPTIONS
+-------
+
+-q::
+--quiet::
+ Be quiet, only report errors.
+
+--refresh::
+--no-refresh::
+ Refresh the index after a mixed reset. Enabled by default.
+
+--pathspec-from-file=<file>::
+ Pathspec is passed in `<file>` instead of commandline args. If
+ `<file>` is exactly `-` then standard input is used. Pathspec
+ elements are separated by LF or CR/LF. Pathspec elements can be
+ quoted as explained for the configuration variable `core.quotePath`
+ (see linkgit:git-config[1]). See also `--pathspec-file-nul` and
+ global `--literal-pathspecs`.
+
+--pathspec-file-nul::
+ Only meaningful with `--pathspec-from-file`. Pathspec elements are
+ separated with NUL character and all other characters are taken
+ literally (including newlines and quotes).
+
+\--::
+ Do not interpret any more arguments as options.
+
+<pathspec>...::
+ Limits the paths affected by the operation.
++
+For more details, see the 'pathspec' entry in linkgit:gitglossary[7].
+
+EXAMPLES
+--------
+
+Undo add::
++
+------------
+$ edit <1>
+$ git add frotz.c filfre.c
+$ mailx <2>
+$ git reset <3>
+$ git pull git://info.example.com/ nitfol <4>
+------------
++
+<1> You are happily working on something, and find the changes
+ in these files are in good order. You do not want to see them
+ when you run `git diff`, because you plan to work on other files
+ and changes with these files are distracting.
+<2> Somebody asks you to pull, and the changes sound worthy of merging.
+<3> However, you already dirtied the index (i.e. your index does
+ not match the `HEAD` commit). But you know the pull you are going
+ to make does not affect `frotz.c` or `filfre.c`, so you revert the
+ index changes for these two files. Your changes in working tree
+ remain there.
+<4> Then you can pull and merge, leaving `frotz.c` and `filfre.c`
+ changes still in the working tree.
+
+Undo a commit and redo::
++
+------------
+$ git commit ...
+$ git reset --soft HEAD^ <1>
+$ edit <2>
+$ git commit -a -c ORIG_HEAD <3>
+------------
++
+<1> This is most often done when you remembered what you
+ just committed is incomplete, or you misspelled your commit
+ message, or both. Leaves working tree as it was before "reset".
+<2> Make corrections to working tree files.
+<3> "reset" copies the old head to `.git/ORIG_HEAD`; redo the
+ commit by starting with its log message. If you do not need to
+ edit the message further, you can give `-C` option instead.
++
+See also the `--amend` option to linkgit:git-commit[1].
+
+Undo a commit, making it a topic branch::
++
+------------
+$ git branch topic/wip <1>
+$ git reset --hard HEAD~3 <2>
+$ git switch topic/wip <3>
+------------
++
+<1> You have made some commits, but realize they were premature
+ to be in the `master` branch. You want to continue polishing
+ them in a topic branch, so create `topic/wip` branch off of the
+ current `HEAD`.
+<2> Rewind the master branch to get rid of those three commits.
+<3> Switch to `topic/wip` branch and keep working.
+
+Undo commits permanently::
++
+------------
+$ git commit ...
+$ git reset --hard HEAD~3 <1>
+------------
++
+<1> The last three commits (`HEAD`, `HEAD^`, and `HEAD~2`) were bad
+ and you do not want to ever see them again. Do *not* do this if
+ you have already given these commits to somebody else. (See the
+ "RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1]
+ for the implications of doing so.)
+
+Undo a merge or pull::
++
+------------
+$ git pull <1>
+Auto-merging nitfol
+CONFLICT (content): Merge conflict in nitfol
+Automatic merge failed; fix conflicts and then commit the result.
+$ git reset --hard <2>
+$ git pull . topic/branch <3>
+Updating from 41223... to 13134...
+Fast-forward
+$ git reset --hard ORIG_HEAD <4>
+------------
++
+<1> Try to update from the upstream resulted in a lot of
+ conflicts; you were not ready to spend a lot of time merging
+ right now, so you decide to do that later.
+<2> "pull" has not made merge commit, so `git reset --hard`
+ which is a synonym for `git reset --hard HEAD` clears the mess
+ from the index file and the working tree.
+<3> Merge a topic branch into the current branch, which resulted
+ in a fast-forward.
+<4> But you decided that the topic branch is not ready for public
+ consumption yet. "pull" or "merge" always leaves the original
+ tip of the current branch in `ORIG_HEAD`, so resetting hard to it
+ brings your index file and the working tree back to that state,
+ and resets the tip of the branch to that commit.
+
+Undo a merge or pull inside a dirty working tree::
++
+------------
+$ git pull <1>
+Auto-merging nitfol
+Merge made by recursive.
+ nitfol | 20 +++++----
+ ...
+$ git reset --merge ORIG_HEAD <2>
+------------
++
+<1> Even if you may have local modifications in your
+ working tree, you can safely say `git pull` when you know
+ that the change in the other branch does not overlap with
+ them.
+<2> After inspecting the result of the merge, you may find
+ that the change in the other branch is unsatisfactory. Running
+ `git reset --hard ORIG_HEAD` will let you go back to where you
+ were, but it will discard your local changes, which you do not
+ want. `git reset --merge` keeps your local changes.
+
+
+Interrupted workflow::
++
+Suppose you are interrupted by an urgent fix request while you
+are in the middle of a large change. The files in your
+working tree are not in any shape to be committed yet, but you
+need to get to the other branch for a quick bugfix.
++
+------------
+$ git switch feature ;# you were working in "feature" branch and
+$ work work work ;# got interrupted
+$ git commit -a -m "snapshot WIP" <1>
+$ git switch master
+$ fix fix fix
+$ git commit ;# commit with real log
+$ git switch feature
+$ git reset --soft HEAD^ ;# go back to WIP state <2>
+$ git reset <3>
+------------
++
+<1> This commit will get blown away so a throw-away log message is OK.
+<2> This removes the 'WIP' commit from the commit history, and sets
+ your working tree to the state just before you made that snapshot.
+<3> At this point the index file still has all the WIP changes you
+ committed as 'snapshot WIP'. This updates the index to show your
+ WIP files as uncommitted.
++
+See also linkgit:git-stash[1].
+
+Reset a single file in the index::
++
+Suppose you have added a file to your index, but later decide you do not
+want to add it to your commit. You can remove the file from the index
+while keeping your changes with git reset.
++
+------------
+$ git reset -- frotz.c <1>
+$ git commit -m "Commit files in index" <2>
+$ git add frotz.c <3>
+------------
++
+<1> This removes the file from the index while keeping it in the working
+ directory.
+<2> This commits all other changes in the index.
+<3> Adds the file to the index again.
+
+Keep changes in working tree while discarding some previous commits::
++
+Suppose you are working on something and you commit it, and then you
+continue working a bit more, but now you think that what you have in
+your working tree should be in another branch that has nothing to do
+with what you committed previously. You can start a new branch and
+reset it while keeping the changes in your working tree.
++
+------------
+$ git tag start
+$ git switch -c branch1
+$ edit
+$ git commit ... <1>
+$ edit
+$ git switch -c branch2 <2>
+$ git reset --keep start <3>
+------------
++
+<1> This commits your first edits in `branch1`.
+<2> In the ideal world, you could have realized that the earlier
+ commit did not belong to the new topic when you created and switched
+ to `branch2` (i.e. `git switch -c branch2 start`), but nobody is
+ perfect.
+<3> But you can use `reset --keep` to remove the unwanted commit after
+ you switched to `branch2`.
+
+Split a commit apart into a sequence of commits::
++
+Suppose that you have created lots of logically separate changes and committed
+them together. Then, later you decide that it might be better to have each
+logical chunk associated with its own commit. You can use git reset to rewind
+history without changing the contents of your local files, and then successively
+use `git add -p` to interactively select which hunks to include into each commit,
+using `git commit -c` to pre-populate the commit message.
++
+------------
+$ git reset -N HEAD^ <1>
+$ git add -p <2>
+$ git diff --cached <3>
+$ git commit -c HEAD@{1} <4>
+... <5>
+$ git add ... <6>
+$ git diff --cached <7>
+$ git commit ... <8>
+------------
++
+<1> First, reset the history back one commit so that we remove the original
+ commit, but leave the working tree with all the changes. The -N ensures
+ that any new files added with `HEAD` are still marked so that `git add -p`
+ will find them.
+<2> Next, we interactively select diff hunks to add using the `git add -p`
+ facility. This will ask you about each diff hunk in sequence and you can
+ use simple commands such as "yes, include this", "No don't include this"
+ or even the very powerful "edit" facility.
+<3> Once satisfied with the hunks you want to include, you should verify what
+ has been prepared for the first commit by using `git diff --cached`. This
+ shows all the changes that have been moved into the index and are about
+ to be committed.
+<4> Next, commit the changes stored in the index. The `-c` option specifies to
+ pre-populate the commit message from the original message that you started
+ with in the first commit. This is helpful to avoid retyping it. The
+ `HEAD@{1}` is a special notation for the commit that `HEAD` used to be at
+ prior to the original reset commit (1 change ago).
+ See linkgit:git-reflog[1] for more details. You may also use any other
+ valid commit reference.
+<5> You can repeat steps 2-4 multiple times to break the original code into
+ any number of commits.
+<6> Now you've split out many of the changes into their own commits, and might
+ no longer use the patch mode of `git add`, in order to select all remaining
+ uncommitted changes.
+<7> Once again, check to verify that you've included what you want to. You may
+ also wish to verify that git diff doesn't show any remaining changes to be
+ committed later.
+<8> And finally create the final commit.
+
+
+DISCUSSION
+----------
+
+The tables below show what happens when running:
+
+----------
+git reset --option target
+----------
+
+to reset the `HEAD` to another commit (`target`) with the different
+reset options depending on the state of the files.
+
+In these tables, `A`, `B`, `C` and `D` are some different states of a
+file. For example, the first line of the first table means that if a
+file is in state `A` in the working tree, in state `B` in the index, in
+state `C` in `HEAD` and in state `D` in the target, then `git reset --soft
+target` will leave the file in the working tree in state `A` and in the
+index in state `B`. It resets (i.e. moves) the `HEAD` (i.e. the tip of
+the current branch, if you are on one) to `target` (which has the file
+in state `D`).
+
+....
+working index HEAD target working index HEAD
+----------------------------------------------------
+ A B C D --soft A B D
+ --mixed A D D
+ --hard D D D
+ --merge (disallowed)
+ --keep (disallowed)
+....
+
+....
+working index HEAD target working index HEAD
+----------------------------------------------------
+ A B C C --soft A B C
+ --mixed A C C
+ --hard C C C
+ --merge (disallowed)
+ --keep A C C
+....
+
+....
+working index HEAD target working index HEAD
+----------------------------------------------------
+ B B C D --soft B B D
+ --mixed B D D
+ --hard D D D
+ --merge D D D
+ --keep (disallowed)
+....
+
+....
+working index HEAD target working index HEAD
+----------------------------------------------------
+ B B C C --soft B B C
+ --mixed B C C
+ --hard C C C
+ --merge C C C
+ --keep B C C
+....
+
+....
+working index HEAD target working index HEAD
+----------------------------------------------------
+ B C C D --soft B C D
+ --mixed B D D
+ --hard D D D
+ --merge (disallowed)
+ --keep (disallowed)
+....
+
+....
+working index HEAD target working index HEAD
+----------------------------------------------------
+ B C C C --soft B C C
+ --mixed B C C
+ --hard C C C
+ --merge B C C
+ --keep B C C
+....
+
+`reset --merge` is meant to be used when resetting out of a conflicted
+merge. Any mergy operation guarantees that the working tree file that is
+involved in the merge does not have a local change with respect to the index
+before it starts, and that it writes the result out to the working tree. So if
+we see some difference between the index and the target and also
+between the index and the working tree, then it means that we are not
+resetting out from a state that a mergy operation left after failing
+with a conflict. That is why we disallow `--merge` option in this case.
+
+`reset --keep` is meant to be used when removing some of the last
+commits in the current branch while keeping changes in the working
+tree. If there could be conflicts between the changes in the commit we
+want to remove and the changes in the working tree we want to keep,
+the reset is disallowed. That's why it is disallowed if there are both
+changes between the working tree and `HEAD`, and between `HEAD` and the
+target. To be safe, it is also disallowed when there are unmerged
+entries.
+
+The following tables show what happens when there are unmerged
+entries:
+
+....
+working index HEAD target working index HEAD
+----------------------------------------------------
+ X U A B --soft (disallowed)
+ --mixed X B B
+ --hard B B B
+ --merge B B B
+ --keep (disallowed)
+....
+
+....
+working index HEAD target working index HEAD
+----------------------------------------------------
+ X U A A --soft (disallowed)
+ --mixed X A A
+ --hard A A A
+ --merge A A A
+ --keep (disallowed)
+....
+
+`X` means any state and `U` means an unmerged index.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-restore.adoc b/git-restore.adoc
new file mode 100644
index 0000000..751f01b
--- /dev/null
+++ b/git-restore.adoc
@@ -0,0 +1,222 @@
+git-restore(1)
+==============
+
+NAME
+----
+git-restore - Restore working tree files
+
+SYNOPSIS
+--------
+[synopsis]
+git restore [<options>] [--source=<tree>] [--staged] [--worktree] [--] <pathspec>...
+git restore [<options>] [--source=<tree>] [--staged] [--worktree] --pathspec-from-file=<file> [--pathspec-file-nul]
+git restore (-p|--patch) [<options>] [--source=<tree>] [--staged] [--worktree] [--] [<pathspec>...]
+
+DESCRIPTION
+-----------
+Restore specified paths in the working tree with some contents from a
+restore source. If a path is tracked but does not exist in the restore
+source, it will be removed to match the source.
+
+The command can also be used to restore the content in the index with
+`--staged`, or restore both the working tree and the index with
+`--staged --worktree`.
+
+By default, if `--staged` is given, the contents are restored from `HEAD`,
+otherwise from the index. Use `--source` to restore from a different commit.
+
+See "Reset, restore and revert" in linkgit:git[1] for the differences
+between the three commands.
+
+THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
+
+OPTIONS
+-------
+`-s <tree>`::
+`--source=<tree>`::
+ Restore the working tree files with the content from the given
+ tree. It is common to specify the source tree by naming a
+ commit, branch or tag associated with it.
++
+If not specified, the contents are restored from `HEAD` if `--staged` is
+given, otherwise from the index.
++
+As a special case, you may use `"<rev-A>...<rev-B>"` as a shortcut for the
+merge base of _<rev-A>_ and _<rev-B>_ if there is exactly one merge base. You can
+leave out at most one of _<rev-A>__ and _<rev-B>_, in which case it defaults to `HEAD`.
+
+`-p`::
+`--patch`::
+ Interactively select hunks in the difference between the
+ restore source and the restore location. See the "Interactive
+ Mode" section of linkgit:git-add[1] to learn how to operate
+ the `--patch` mode.
++
+Note that `--patch` can accept no pathspec and will prompt to restore
+all modified paths.
+
+`-W`::
+`--worktree`::
+`-S`::
+`--staged`::
+ Specify the restore location. If neither option is specified,
+ by default the working tree is restored. Specifying `--staged`
+ will only restore the index. Specifying both restores both.
+
+`-q`::
+`--quiet`::
+ Quiet, suppress feedback messages. Implies `--no-progress`.
+
+`--progress`::
+`--no-progress`::
+ Progress status is reported on the standard error stream
+ by default when it is attached to a terminal, unless `--quiet`
+ is specified. This flag enables progress reporting even if not
+ attached to a terminal, regardless of `--quiet`.
+
+`--ours`::
+`--theirs`::
+ When restoring files in the working tree from the index, use
+ stage #2 (`ours`) or #3 (`theirs`) for unmerged paths.
+ This option cannot be used when checking out paths from a
+ tree-ish (i.e. with the `--source` option).
++
+Note that during `git rebase` and `git pull --rebase`, `ours` and
+`theirs` may appear swapped. See the explanation of the same options
+in linkgit:git-checkout[1] for details.
+
+`-m`::
+`--merge`::
+ When restoring files on the working tree from the index,
+ recreate the conflicted merge in the unmerged paths.
+ This option cannot be used when checking out paths from a
+ tree-ish (i.e. with the `--source` option).
+
+`--conflict=<style>`::
+ The same as `--merge` option above, but changes the way the
+ conflicting hunks are presented, overriding the
+ `merge.conflictStyle` configuration variable. Possible values
+ are `merge` (default), `diff3`, and `zdiff3`.
+
+`--ignore-unmerged`::
+ When restoring files on the working tree from the index, do
+ not abort the operation if there are unmerged entries and
+ neither `--ours`, `--theirs`, `--merge` or `--conflict` is
+ specified. Unmerged paths on the working tree are left alone.
+
+`--ignore-skip-worktree-bits`::
+ In sparse checkout mode, the default is to only update entries
+ matched by _<pathspec>_ and sparse patterns in
+ `$GIT_DIR/info/sparse-checkout`. This option ignores the sparse
+ patterns and unconditionally restores any files in
+ _<pathspec>_.
+
+`--recurse-submodules`::
+`--no-recurse-submodules`::
+ If _<pathspec>_ names an active submodule and the restore location
+ includes the working tree, the submodule will only be updated if
+ this option is given, in which case its working tree will be
+ restored to the commit recorded in the superproject, and any local
+ modifications overwritten. If nothing (or
+ `--no-recurse-submodules`) is used, submodules working trees will
+ not be updated. Just like linkgit:git-checkout[1], this will detach
+ `HEAD` of the submodule.
+
+`--overlay`::
+`--no-overlay`::
+ In overlay mode, never remove files when restoring. In no-overlay mode,
+ remove tracked files that do not appear in the _<tree>_ of
+ `--source=<tree>`, to make them match _<tree>_ exactly. The default
+ is no-overlay mode.
+
+`--pathspec-from-file=<file>`::
+ Pathspec is passed in _<file>_ instead of commandline args. If
+ _<file>_ is exactly `-` then standard input is used. Pathspec
+ elements are separated by _LF_ or _CR_/_LF_. Pathspec elements can be
+ quoted as explained for the configuration variable `core.quotePath`
+ (see linkgit:git-config[1]). See also `--pathspec-file-nul` and
+ global `--literal-pathspecs`.
+
+`--pathspec-file-nul`::
+ Only meaningful with `--pathspec-from-file`. Pathspec elements are
+ separated with _NUL_ character and all other characters are taken
+ literally (including newlines and quotes).
+
+`--`::
+ Do not interpret any more arguments as options.
+
+`<pathspec>...`::
+ Limits the paths affected by the operation.
++
+For more details, see the 'pathspec' entry in linkgit:gitglossary[7].
+
+EXAMPLES
+--------
+
+The following sequence switches to the `master` branch, reverts the
+`Makefile` to two revisions back, deletes `hello.c` by mistake, and gets
+it back from the index.
+
+------------
+$ git switch master
+$ git restore --source master~2 Makefile <1>
+$ rm -f hello.c
+$ git restore hello.c <2>
+------------
+
+<1> take a file out of another commit
+<2> restore `hello.c` from the index
+
+If you want to restore _all_ C source files to match the version in
+the index, you can say
+
+------------
+$ git restore '*.c'
+------------
+
+Note the quotes around `*.c`. The file `hello.c` will also be
+restored, even though it is no longer in the working tree, because the
+file globbing is used to match entries in the index (not in the
+working tree by the shell).
+
+To restore all files in the current directory
+
+------------
+$ git restore .
+------------
+
+or to restore all working tree files with 'top' pathspec magic (see
+linkgit:gitglossary[7])
+
+------------
+$ git restore :/
+------------
+
+To restore a file in the index to match the version in `HEAD` (this is
+the same as using linkgit:git-reset[1])
+
+------------
+$ git restore --staged hello.c
+------------
+
+or you can restore both the index and the working tree (this is the same
+as using linkgit:git-checkout[1])
+
+------------
+$ git restore --source=HEAD --staged --worktree hello.c
+------------
+
+or the short form which is more practical but less readable:
+
+------------
+$ git restore -s@ -SW hello.c
+------------
+
+SEE ALSO
+--------
+linkgit:git-checkout[1],
+linkgit:git-reset[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-rev-list.adoc b/git-rev-list.adoc
new file mode 100644
index 0000000..f582491
--- /dev/null
+++ b/git-rev-list.adoc
@@ -0,0 +1,129 @@
+git-rev-list(1)
+===============
+
+NAME
+----
+git-rev-list - Lists commit objects in reverse chronological order
+
+
+SYNOPSIS
+--------
+[verse]
+'git rev-list' [<options>] <commit>... [--] [<path>...]
+
+DESCRIPTION
+-----------
+
+:git-rev-list: 1
+include::rev-list-description.adoc[]
+
+'rev-list' is an essential Git command, since it
+provides the ability to build and traverse commit ancestry graphs. For
+this reason, it has a lot of different options that enable it to be
+used by commands as different as 'git bisect' and
+'git repack'.
+
+OPTIONS
+-------
+
+:git-rev-list: 1
+include::rev-list-options.adoc[]
+
+include::pretty-formats.adoc[]
+
+EXAMPLES
+--------
+
+* Print the list of commits reachable from the current branch.
++
+----------
+git rev-list HEAD
+----------
+
+* Print the list of commits on this branch, but not present in the
+ upstream branch.
++
+----------
+git rev-list @{upstream}..HEAD
+----------
+
+* Format commits with their author and commit message (see also the
+ porcelain linkgit:git-log[1]).
++
+----------
+git rev-list --format=medium HEAD
+----------
+
+* Format commits along with their diffs (see also the porcelain
+ linkgit:git-log[1], which can do this in a single process).
++
+----------
+git rev-list HEAD |
+git diff-tree --stdin --format=medium -p
+----------
+
+* Print the list of commits on the current branch that touched any
+ file in the `Documentation` directory.
++
+----------
+git rev-list HEAD -- Documentation/
+----------
+
+* Print the list of commits authored by you in the past year, on
+ any branch, tag, or other ref.
++
+----------
+git rev-list --author=you@example.com --since=1.year.ago --all
+----------
+
+* Print the list of objects reachable from the current branch (i.e., all
+ commits and the blobs and trees they contain).
++
+----------
+git rev-list --objects HEAD
+----------
+
+* Compare the disk size of all reachable objects, versus those
+ reachable from reflogs, versus the total packed size. This can tell
+ you whether running `git repack -ad` might reduce the repository size
+ (by dropping unreachable objects), and whether expiring reflogs might
+ help.
++
+----------
+# reachable objects
+git rev-list --disk-usage --objects --all
+# plus reflogs
+git rev-list --disk-usage --objects --all --reflog
+# total disk size used
+du -c .git/objects/pack/*.pack .git/objects/??/*
+# alternative to du: add up "size" and "size-pack" fields
+git count-objects -v
+----------
+
+* Report the disk size of each branch, not including objects used by the
+ current branch. This can find outliers that are contributing to a
+ bloated repository size (e.g., because somebody accidentally committed
+ large build artifacts).
++
+----------
+git for-each-ref --format='%(refname)' |
+while read branch
+do
+ size=$(git rev-list --disk-usage --objects HEAD..$branch)
+ echo "$size $branch"
+done |
+sort -n
+----------
+
+* Compare the on-disk size of branches in one group of refs, excluding
+ another. If you co-mingle objects from multiple remotes in a single
+ repository, this can show which remotes are contributing to the
+ repository size (taking the size of `origin` as a baseline).
++
+----------
+git rev-list --disk-usage --objects --remotes=$suspect --not --remotes=origin
+----------
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-rev-parse.adoc b/git-rev-parse.adoc
new file mode 100644
index 0000000..cc32b4b
--- /dev/null
+++ b/git-rev-parse.adoc
@@ -0,0 +1,516 @@
+git-rev-parse(1)
+================
+
+NAME
+----
+git-rev-parse - Pick out and massage parameters
+
+
+SYNOPSIS
+--------
+[verse]
+'git rev-parse' [<options>] <arg>...
+
+DESCRIPTION
+-----------
+
+Many Git porcelainish commands take a mixture of flags
+(i.e. parameters that begin with a dash '-') and parameters
+meant for the underlying 'git rev-list' command they use internally
+and flags and parameters for the other commands they use
+downstream of 'git rev-list'. The primary purpose of this command
+is to allow calling programs to distinguish between them. There are
+a few other operation modes that have nothing to do with the above
+"help parse command line options".
+
+Unless otherwise specified, most of the options and operation modes
+require you to run this command inside a git repository or a working
+tree that is under the control of a git repository, and will give you
+a fatal error otherwise.
+
+
+OPTIONS
+-------
+
+Operation Modes
+~~~~~~~~~~~~~~~
+
+Each of these options must appear first on the command line.
+
+--parseopt::
+ Use 'git rev-parse' in option parsing mode (see PARSEOPT section below).
+ The command in this mode can be used outside a repository or
+ a working tree controlled by a repository.
+
+--sq-quote::
+ Use 'git rev-parse' in shell quoting mode (see SQ-QUOTE
+ section below). In contrast to the `--sq` option below, this
+ mode only does quoting. Nothing else is done to command input.
+ The command in this mode can be used outside a repository or
+ a working tree controlled by a repository.
+
+Options for --parseopt
+~~~~~~~~~~~~~~~~~~~~~~
+
+--keep-dashdash::
+ Only meaningful in `--parseopt` mode. Tells the option parser to echo
+ out the first `--` met instead of skipping it.
+
+--stop-at-non-option::
+ Only meaningful in `--parseopt` mode. Lets the option parser stop at
+ the first non-option argument. This can be used to parse sub-commands
+ that take options themselves.
+
+--stuck-long::
+ Only meaningful in `--parseopt` mode. Output the options in their
+ long form if available, and with their arguments stuck.
+
+Options for Filtering
+~~~~~~~~~~~~~~~~~~~~~
+
+--revs-only::
+ Do not output flags and parameters not meant for
+ 'git rev-list' command.
+
+--no-revs::
+ Do not output flags and parameters meant for
+ 'git rev-list' command.
+
+--flags::
+ Do not output non-flag parameters.
+
+--no-flags::
+ Do not output flag parameters.
+
+Options for Output
+~~~~~~~~~~~~~~~~~~
+
+--default <arg>::
+ If there is no parameter given by the user, use `<arg>`
+ instead.
+
+--prefix <arg>::
+ Behave as if 'git rev-parse' was invoked from the `<arg>`
+ subdirectory of the working tree. Any relative filenames are
+ resolved as if they are prefixed by `<arg>` and will be printed
+ in that form.
++
+This can be used to convert arguments to a command run in a subdirectory
+so that they can still be used after moving to the top-level of the
+repository. For example:
++
+----
+prefix=$(git rev-parse --show-prefix)
+cd "$(git rev-parse --show-toplevel)"
+# rev-parse provides the -- needed for 'set'
+eval "set $(git rev-parse --sq --prefix "$prefix" -- "$@")"
+----
+
+--verify::
+ Verify that exactly one parameter is provided, and that it
+ can be turned into a raw 20-byte SHA-1 that can be used to
+ access the object database. If so, emit it to the standard
+ output; otherwise, error out.
++
+If you want to make sure that the output actually names an object in
+your object database and/or can be used as a specific type of object
+you require, you can add the `^{type}` peeling operator to the parameter.
+For example, `git rev-parse "$VAR^{commit}"` will make sure `$VAR`
+names an existing object that is a commit-ish (i.e. a commit, or an
+annotated tag that points at a commit). To make sure that `$VAR`
+names an existing object of any type, `git rev-parse "$VAR^{object}"`
+can be used.
++
+Note that if you are verifying a name from an untrusted source, it is
+wise to use `--end-of-options` so that the name argument is not mistaken
+for another option.
+
+-q::
+--quiet::
+ Only meaningful in `--verify` mode. Do not output an error
+ message if the first argument is not a valid object name;
+ instead exit with non-zero status silently.
+ SHA-1s for valid object names are printed to stdout on success.
+
+--sq::
+ Usually the output is made one line per flag and
+ parameter. This option makes output a single line,
+ properly quoted for consumption by shell. Useful when
+ you expect your parameter to contain whitespaces and
+ newlines (e.g. when using pickaxe `-S` with
+ 'git diff-{asterisk}'). In contrast to the `--sq-quote` option,
+ the command input is still interpreted as usual.
+
+--short[=<length>]::
+ Same as `--verify` but shortens the object name to a unique
+ prefix with at least `length` characters. The minimum length
+ is 4, the default is the effective value of the `core.abbrev`
+ configuration variable (see linkgit:git-config[1]).
+
+--not::
+ When showing object names, prefix them with '{caret}' and
+ strip '{caret}' prefix from the object names that already have
+ one.
+
+--abbrev-ref[=(strict|loose)]::
+ A non-ambiguous short name of the objects name.
+ The option core.warnAmbiguousRefs is used to select the strict
+ abbreviation mode.
+
+--symbolic::
+ Usually the object names are output in SHA-1 form (with
+ possible '{caret}' prefix); this option makes them output in a
+ form as close to the original input as possible.
+
+--symbolic-full-name::
+ This is similar to --symbolic, but it omits input that
+ are not refs (i.e. branch or tag names; or more
+ explicitly disambiguating "heads/master" form, when you
+ want to name the "master" branch when there is an
+ unfortunately named tag "master"), and shows them as full
+ refnames (e.g. "refs/heads/master").
+
+--output-object-format=(sha1|sha256|storage)::
+
+ Allow oids to be input from any object format that the current
+ repository supports.
+
+ Specifying "sha1" translates if necessary and returns a sha1 oid.
+
+ Specifying "sha256" translates if necessary and returns a sha256 oid.
+
+ Specifying "storage" translates if necessary and returns an oid in
+ encoded in the storage hash algorithm.
+
+Options for Objects
+~~~~~~~~~~~~~~~~~~~
+
+--all::
+ Show all refs found in `refs/`.
+
+--branches[=<pattern>]::
+--tags[=<pattern>]::
+--remotes[=<pattern>]::
+ Show all branches, tags, or remote-tracking branches,
+ respectively (i.e., refs found in `refs/heads`,
+ `refs/tags`, or `refs/remotes`, respectively).
++
+If a `pattern` is given, only refs matching the given shell glob are
+shown. If the pattern does not contain a globbing character (`?`,
+`*`, or `[`), it is turned into a prefix match by appending `/*`.
+
+--glob=<pattern>::
+ Show all refs matching the shell glob pattern `pattern`. If
+ the pattern does not start with `refs/`, this is automatically
+ prepended. If the pattern does not contain a globbing
+ character (`?`, `*`, or `[`), it is turned into a prefix
+ match by appending `/*`.
+
+--exclude=<glob-pattern>::
+ Do not include refs matching '<glob-pattern>' that the next `--all`,
+ `--branches`, `--tags`, `--remotes`, or `--glob` would otherwise
+ consider. Repetitions of this option accumulate exclusion patterns
+ up to the next `--all`, `--branches`, `--tags`, `--remotes`, or
+ `--glob` option (other options or arguments do not clear
+ accumulated patterns).
++
+The patterns given should not begin with `refs/heads`, `refs/tags`, or
+`refs/remotes` when applied to `--branches`, `--tags`, or `--remotes`,
+respectively, and they must begin with `refs/` when applied to `--glob`
+or `--all`. If a trailing '/{asterisk}' is intended, it must be given
+explicitly.
+
+--exclude-hidden=(fetch|receive|uploadpack)::
+ Do not include refs that would be hidden by `git-fetch`,
+ `git-receive-pack` or `git-upload-pack` by consulting the appropriate
+ `fetch.hideRefs`, `receive.hideRefs` or `uploadpack.hideRefs`
+ configuration along with `transfer.hideRefs` (see
+ linkgit:git-config[1]). This option affects the next pseudo-ref option
+ `--all` or `--glob` and is cleared after processing them.
+
+--disambiguate=<prefix>::
+ Show every object whose name begins with the given prefix.
+ The <prefix> must be at least 4 hexadecimal digits long to
+ avoid listing each and every object in the repository by
+ mistake.
+
+Options for Files
+~~~~~~~~~~~~~~~~~
+
+--local-env-vars::
+ List the GIT_* environment variables that are local to the
+ repository (e.g. GIT_DIR or GIT_WORK_TREE, but not GIT_EDITOR).
+ Only the names of the variables are listed, not their value,
+ even if they are set.
+
+--path-format=(absolute|relative)::
+ Controls the behavior of certain other options. If specified as absolute, the
+ paths printed by those options will be absolute and canonical. If specified as
+ relative, the paths will be relative to the current working directory if that
+ is possible. The default is option specific.
++
+This option may be specified multiple times and affects only the arguments that
+follow it on the command line, either to the end of the command line or the next
+instance of this option.
+
+The following options are modified by `--path-format`:
+
+--git-dir::
+ Show `$GIT_DIR` if defined. Otherwise show the path to
+ the .git directory. The path shown, when relative, is
+ relative to the current working directory.
++
+If `$GIT_DIR` is not defined and the current directory
+is not detected to lie in a Git repository or work tree
+print a message to stderr and exit with nonzero status.
+
+--git-common-dir::
+ Show `$GIT_COMMON_DIR` if defined, else `$GIT_DIR`.
+
+--resolve-git-dir <path>::
+ Check if <path> is a valid repository or a gitfile that
+ points at a valid repository, and print the location of the
+ repository. If <path> is a gitfile then the resolved path
+ to the real repository is printed.
+
+--git-path <path>::
+ Resolve "$GIT_DIR/<path>" and takes other path relocation
+ variables such as $GIT_OBJECT_DIRECTORY,
+ $GIT_INDEX_FILE... into account. For example, if
+ $GIT_OBJECT_DIRECTORY is set to /foo/bar then "git rev-parse
+ --git-path objects/abc" returns /foo/bar/abc.
+
+--show-toplevel::
+ Show the (by default, absolute) path of the top-level directory
+ of the working tree. If there is no working tree, report an error.
+
+--show-superproject-working-tree::
+ Show the absolute path of the root of the superproject's
+ working tree (if exists) that uses the current repository as
+ its submodule. Outputs nothing if the current repository is
+ not used as a submodule by any project.
+
+--shared-index-path::
+ Show the path to the shared index file in split index mode, or
+ empty if not in split-index mode.
+
+The following options are unaffected by `--path-format`:
+
+--absolute-git-dir::
+ Like `--git-dir`, but its output is always the canonicalized
+ absolute path.
+
+--is-inside-git-dir::
+ When the current working directory is below the repository
+ directory print "true", otherwise "false".
+
+--is-inside-work-tree::
+ When the current working directory is inside the work tree of the
+ repository print "true", otherwise "false".
+
+--is-bare-repository::
+ When the repository is bare print "true", otherwise "false".
+
+--is-shallow-repository::
+ When the repository is shallow print "true", otherwise "false".
+
+--show-cdup::
+ When the command is invoked from a subdirectory, show the
+ path of the top-level directory relative to the current
+ directory (typically a sequence of "../", or an empty string).
+
+--show-prefix::
+ When the command is invoked from a subdirectory, show the
+ path of the current directory relative to the top-level
+ directory.
+
+--show-object-format[=(storage|input|output)]::
+ Show the object format (hash algorithm) used for the repository
+ for storage inside the `.git` directory, input, or output. For
+ input, multiple algorithms may be printed, space-separated.
+ If not specified, the default is "storage".
+
+--show-ref-format::
+ Show the reference storage format used for the repository.
+
+
+Other Options
+~~~~~~~~~~~~~
+
+--since=<datestring>::
+--after=<datestring>::
+ Parse the date string, and output the corresponding
+ --max-age= parameter for 'git rev-list'.
+
+--until=<datestring>::
+--before=<datestring>::
+ Parse the date string, and output the corresponding
+ --min-age= parameter for 'git rev-list'.
+
+<arg>...::
+ Flags and parameters to be parsed.
+
+
+include::revisions.adoc[]
+
+PARSEOPT
+--------
+
+In `--parseopt` mode, 'git rev-parse' helps massaging options to bring to shell
+scripts the same facilities C builtins have. It works as an option normalizer
+(e.g. splits single switches aggregate values), a bit like `getopt(1)` does.
+
+It takes on the standard input the specification of the options to parse and
+understand, and echoes on the standard output a string suitable for `sh(1)` `eval`
+to replace the arguments with normalized ones. In case of error, it outputs
+usage on the standard error stream, and exits with code 129.
+
+Note: Make sure you quote the result when passing it to `eval`. See
+below for an example.
+
+Input Format
+~~~~~~~~~~~~
+
+'git rev-parse --parseopt' input format is fully text based. It has two parts,
+separated by a line that contains only `--`. The lines before the separator
+(should be one or more) are used for the usage.
+The lines after the separator describe the options.
+
+Each line of options has this format:
+
+------------
+<opt-spec><flags>*<arg-hint>? SP+ help LF
+------------
+
+`<opt-spec>`::
+ its format is the short option character, then the long option name
+ separated by a comma. Both parts are not required, though at least one
+ is necessary. May not contain any of the `<flags>` characters.
+ `h,help`, `dry-run` and `f` are examples of correct `<opt-spec>`.
+
+`<flags>`::
+ `<flags>` are of `*`, `=`, `?` or `!`.
+ * Use `=` if the option takes an argument.
+
+ * Use `?` to mean that the option takes an optional argument. You
+ probably want to use the `--stuck-long` mode to be able to
+ unambiguously parse the optional argument.
+
+ * Use `*` to mean that this option should not be listed in the usage
+ generated for the `-h` argument. It's shown for `--help-all` as
+ documented in linkgit:gitcli[7].
+
+ * Use `!` to not make the corresponding negated long option available.
+
+`<arg-hint>`::
+ `<arg-hint>`, if specified, is used as a name of the argument in the
+ help output, for options that take arguments. `<arg-hint>` is
+ terminated by the first whitespace. It is customary to use a
+ dash to separate words in a multi-word argument hint.
+
+The remainder of the line, after stripping the spaces, is used
+as the help associated with the option.
+
+Blank lines are ignored, and lines that don't match this specification are used
+as option group headers (start the line with a space to create such
+lines on purpose).
+
+Example
+~~~~~~~
+
+------------
+OPTS_SPEC="\
+some-command [<options>] <args>...
+
+some-command does foo and bar!
+--
+h,help! show the help
+
+foo some nifty option --foo
+bar= some cool option --bar with an argument
+baz=arg another cool option --baz with a named argument
+qux?path qux may take a path argument but has meaning by itself
+
+ An option group Header
+C? option C with an optional argument"
+
+eval "$(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)"
+------------
+
+
+Usage text
+~~~~~~~~~~
+
+When `"$@"` is `-h` or `--help` in the above example, the following
+usage text would be shown:
+
+------------
+usage: some-command [<options>] <args>...
+
+ some-command does foo and bar!
+
+ -h, --help show the help
+ --[no-]foo some nifty option --foo
+ --[no-]bar ... some cool option --bar with an argument
+ --[no-]baz <arg> another cool option --baz with a named argument
+ --[no-]qux[=<path>] qux may take a path argument but has meaning by itself
+
+An option group Header
+ -C[...] option C with an optional argument
+------------
+
+SQ-QUOTE
+--------
+
+In `--sq-quote` mode, 'git rev-parse' echoes on the standard output a
+single line suitable for `sh(1)` `eval`. This line is made by
+normalizing the arguments following `--sq-quote`. Nothing other than
+quoting the arguments is done.
+
+If you want command input to still be interpreted as usual by
+'git rev-parse' before the output is shell quoted, see the `--sq`
+option.
+
+Example
+~~~~~~~
+
+------------
+$ cat >your-git-script.sh <<\EOF
+#!/bin/sh
+args=$(git rev-parse --sq-quote "$@") # quote user-supplied arguments
+command="git frotz -n24 $args" # and use it inside a handcrafted
+ # command line
+eval "$command"
+EOF
+
+$ sh your-git-script.sh "a b'c"
+------------
+
+EXAMPLES
+--------
+
+* Print the object name of the current commit:
++
+------------
+$ git rev-parse --verify HEAD
+------------
+
+* Print the commit object name from the revision in the $REV shell variable:
++
+------------
+$ git rev-parse --verify --end-of-options $REV^{commit}
+------------
++
+This will error out if $REV is empty or not a valid revision.
+
+* Similar to above:
++
+------------
+$ git rev-parse --default master --verify --end-of-options $REV
+------------
++
+but if $REV is empty, the commit object name from master will be printed.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-revert.adoc b/git-revert.adoc
new file mode 100644
index 0000000..ffba365
--- /dev/null
+++ b/git-revert.adoc
@@ -0,0 +1,168 @@
+git-revert(1)
+=============
+
+NAME
+----
+git-revert - Revert some existing commits
+
+SYNOPSIS
+--------
+[verse]
+'git revert' [--[no-]edit] [-n] [-m <parent-number>] [-s] [-S[<keyid>]] <commit>...
+'git revert' (--continue | --skip | --abort | --quit)
+
+DESCRIPTION
+-----------
+
+Given one or more existing commits, revert the changes that the
+related patches introduce, and record some new commits that record
+them. This requires your working tree to be clean (no modifications
+from the HEAD commit).
+
+Note: 'git revert' is used to record some new commits to reverse the
+effect of some earlier commits (often only a faulty one). If you want to
+throw away all uncommitted changes in your working directory, you
+should see linkgit:git-reset[1], particularly the `--hard` option. If
+you want to extract specific files as they were in another commit, you
+should see linkgit:git-restore[1], specifically the `--source`
+option. Take care with these alternatives as
+both will discard uncommitted changes in your working directory.
+
+See "Reset, restore and revert" in linkgit:git[1] for the differences
+between the three commands.
+
+OPTIONS
+-------
+<commit>...::
+ Commits to revert.
+ For a more complete list of ways to spell commit names, see
+ linkgit:gitrevisions[7].
+ Sets of commits can also be given but no traversal is done by
+ default, see linkgit:git-rev-list[1] and its `--no-walk`
+ option.
+
+-e::
+--edit::
+ With this option, 'git revert' will let you edit the commit
+ message prior to committing the revert. This is the default if
+ you run the command from a terminal.
+
+-m parent-number::
+--mainline parent-number::
+ Usually you cannot revert a merge because you do not know which
+ side of the merge should be considered the mainline. This
+ option specifies the parent number (starting from 1) of
+ the mainline and allows revert to reverse the change
+ relative to the specified parent.
++
+Reverting a merge commit declares that you will never want the tree changes
+brought in by the merge. As a result, later merges will only bring in tree
+changes introduced by commits that are not ancestors of the previously
+reverted merge. This may or may not be what you want.
++
+See the link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for
+more details.
+
+--no-edit::
+ With this option, 'git revert' will not start the commit
+ message editor.
+
+--cleanup=<mode>::
+ This option determines how the commit message will be cleaned up before
+ being passed on to the commit machinery. See linkgit:git-commit[1] for more
+ details. In particular, if the '<mode>' is given a value of `scissors`,
+ scissors will be appended to `MERGE_MSG` before being passed on in the case
+ of a conflict.
+
+-n::
+--no-commit::
+ Usually the command automatically creates some commits with
+ commit log messages stating which commits were
+ reverted. This flag applies the changes necessary
+ to revert the named commits to your working tree
+ and the index, but does not make the commits. In addition,
+ when this option is used, your index does not have to match
+ the HEAD commit. The revert is done against the
+ beginning state of your index.
++
+This is useful when reverting more than one commits'
+effect to your index in a row.
+
+-S[<keyid>]::
+--gpg-sign[=<keyid>]::
+--no-gpg-sign::
+ GPG-sign commits. The `keyid` argument is optional and
+ defaults to the committer identity; if specified, it must be
+ stuck to the option without a space. `--no-gpg-sign` is useful to
+ countermand both `commit.gpgSign` configuration variable, and
+ earlier `--gpg-sign`.
+
+-s::
+--signoff::
+ Add a `Signed-off-by` trailer at the end of the commit message.
+ See the signoff option in linkgit:git-commit[1] for more information.
+
+--strategy=<strategy>::
+ Use the given merge strategy. Should only be used once.
+ See the MERGE STRATEGIES section in linkgit:git-merge[1]
+ for details.
+
+-X<option>::
+--strategy-option=<option>::
+ Pass the merge strategy-specific option through to the
+ merge strategy. See linkgit:git-merge[1] for details.
+
+include::rerere-options.adoc[]
+
+--reference::
+ Instead of starting the body of the log message with "This
+ reverts <full-object-name-of-the-commit-being-reverted>.",
+ refer to the commit using "--pretty=reference" format
+ (cf. linkgit:git-log[1]). The `revert.reference`
+ configuration variable can be used to enable this option by
+ default.
+
+
+SEQUENCER SUBCOMMANDS
+---------------------
+include::sequencer.adoc[]
+
+EXAMPLES
+--------
+`git revert HEAD~3`::
+
+ Revert the changes specified by the fourth last commit in HEAD
+ and create a new commit with the reverted changes.
+
+`git revert -n master~5..master~2`::
+
+ Revert the changes done by commits from the fifth last commit
+ in master (included) to the third last commit in master
+ (included), but do not create any commit with the reverted
+ changes. The revert only modifies the working tree and the
+ index.
+
+DISCUSSION
+----------
+
+While git creates a basic commit message automatically, it is
+_strongly_ recommended to explain why the original commit is being
+reverted.
+In addition, repeatedly reverting reverts will result in increasingly
+unwieldy subject lines, for example 'Reapply "Reapply "<original-subject>""'.
+Please consider rewording these to be shorter and more unique.
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/revert.adoc[]
+
+SEE ALSO
+--------
+linkgit:git-cherry-pick[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-rm.adoc b/git-rm.adoc
new file mode 100644
index 0000000..363a269
--- /dev/null
+++ b/git-rm.adoc
@@ -0,0 +1,204 @@
+git-rm(1)
+=========
+
+NAME
+----
+git-rm - Remove files from the working tree and from the index
+
+SYNOPSIS
+--------
+[verse]
+'git rm' [-f | --force] [-n] [-r] [--cached] [--ignore-unmatch]
+ [--quiet] [--pathspec-from-file=<file> [--pathspec-file-nul]]
+ [--] [<pathspec>...]
+
+DESCRIPTION
+-----------
+Remove files matching pathspec from the index, or from the working tree
+and the index. `git rm` will not remove a file from just your working
+directory. (There is no option to remove a file only from the working
+tree and yet keep it in the index; use `/bin/rm` if you want to do
+that.) The files being removed have to be identical to the tip of the
+branch, and no updates to their contents can be staged in the index,
+though that default behavior can be overridden with the `-f` option.
+When `--cached` is given, the staged content has to
+match either the tip of the branch or the file on disk,
+allowing the file to be removed from just the index. When
+sparse-checkouts are in use (see linkgit:git-sparse-checkout[1]),
+`git rm` will only remove paths within the sparse-checkout patterns.
+
+
+OPTIONS
+-------
+<pathspec>...::
+ Files to remove. A leading directory name (e.g. `dir` to remove
+ `dir/file1` and `dir/file2`) can be given to remove all files in
+ the directory, and recursively all sub-directories, but this
+ requires the `-r` option to be explicitly given.
++
+The command removes only the paths that are known to Git.
++
+File globbing matches across directory boundaries. Thus, given two
+directories `d` and `d2`, there is a difference between using
+`git rm 'd*'` and `git rm 'd/*'`, as the former will also remove all
+of directory `d2`.
++
+For more details, see the 'pathspec' entry in linkgit:gitglossary[7].
+
+-f::
+--force::
+ Override the up-to-date check.
+
+-n::
+--dry-run::
+ Don't actually remove any file(s). Instead, just show
+ if they exist in the index and would otherwise be removed
+ by the command.
+
+-r::
+ Allow recursive removal when a leading directory name is
+ given.
+
+\--::
+ This option can be used to separate command-line options from
+ the list of files, (useful when filenames might be mistaken
+ for command-line options).
+
+--cached::
+ Use this option to unstage and remove paths only from the index.
+ Working tree files, whether modified or not, will be
+ left alone.
+
+--ignore-unmatch::
+ Exit with a zero status even if no files matched.
+
+--sparse::
+ Allow updating index entries outside of the sparse-checkout cone.
+ Normally, `git rm` refuses to update index entries whose paths do
+ not fit within the sparse-checkout cone. See
+ linkgit:git-sparse-checkout[1] for more.
+
+-q::
+--quiet::
+ `git rm` normally outputs one line (in the form of an `rm` command)
+ for each file removed. This option suppresses that output.
+
+--pathspec-from-file=<file>::
+ Pathspec is passed in `<file>` instead of commandline args. If
+ `<file>` is exactly `-` then standard input is used. Pathspec
+ elements are separated by LF or CR/LF. Pathspec elements can be
+ quoted as explained for the configuration variable `core.quotePath`
+ (see linkgit:git-config[1]). See also `--pathspec-file-nul` and
+ global `--literal-pathspecs`.
+
+--pathspec-file-nul::
+ Only meaningful with `--pathspec-from-file`. Pathspec elements are
+ separated with NUL character and all other characters are taken
+ literally (including newlines and quotes).
+
+
+REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM
+--------------------------------------------------------
+There is no option for `git rm` to remove from the index only
+the paths that have disappeared from the filesystem. However,
+depending on the use case, there are several ways that can be
+done.
+
+Using ``git commit -a''
+~~~~~~~~~~~~~~~~~~~~~~~
+If you intend that your next commit should record all modifications
+of tracked files in the working tree and record all removals of
+files that have been removed from the working tree with `rm`
+(as opposed to `git rm`), use `git commit -a`, as it will
+automatically notice and record all removals. You can also have a
+similar effect without committing by using `git add -u`.
+
+Using ``git add -A''
+~~~~~~~~~~~~~~~~~~~~
+When accepting a new code drop for a vendor branch, you probably
+want to record both the removal of paths and additions of new paths
+as well as modifications of existing paths.
+
+Typically you would first remove all tracked files from the working
+tree using this command:
+
+----------------
+git ls-files -z | xargs -0 rm -f
+----------------
+
+and then untar the new code in the working tree. Alternately
+you could 'rsync' the changes into the working tree.
+
+After that, the easiest way to record all removals, additions, and
+modifications in the working tree is:
+
+----------------
+git add -A
+----------------
+
+See linkgit:git-add[1].
+
+Other ways
+~~~~~~~~~~
+If all you really want to do is to remove from the index the files
+that are no longer present in the working tree (perhaps because
+your working tree is dirty so that you cannot use `git commit -a`),
+use the following command:
+
+----------------
+git diff --name-only --diff-filter=D -z | xargs -0 git rm --cached
+----------------
+
+SUBMODULES
+----------
+Only submodules using a gitfile (which means they were cloned
+with a Git version 1.7.8 or newer) will be removed from the work
+tree, as their repository lives inside the .git directory of the
+superproject. If a submodule (or one of those nested inside it)
+still uses a .git directory, `git rm` will move the submodules
+git directory into the superprojects git directory to protect
+the submodule's history. If it exists the submodule.<name> section
+in the linkgit:gitmodules[5] file will also be removed and that file
+will be staged (unless --cached or -n are used).
+
+A submodule is considered up to date when the HEAD is the same as
+recorded in the index, no tracked files are modified and no untracked
+files that aren't ignored are present in the submodule's work tree.
+Ignored files are deemed expendable and won't stop a submodule's work
+tree from being removed.
+
+If you only want to remove the local checkout of a submodule from your
+work tree without committing the removal, use linkgit:git-submodule[1] `deinit`
+instead. Also see linkgit:gitsubmodules[7] for details on submodule removal.
+
+EXAMPLES
+--------
+`git rm Documentation/\*.txt`::
+ Removes all `*.txt` files from the index that are under the
+ `Documentation` directory and any of its subdirectories.
++
+Note that the asterisk `*` is quoted from the shell in this
+example; this lets Git, and not the shell, expand the pathnames
+of files and subdirectories under the `Documentation/` directory.
+
+`git rm -f git-*.sh`::
+ Because this example lets the shell expand the asterisk
+ (i.e. you are listing the files explicitly), it
+ does not remove `subdir/git-foo.sh`.
+
+BUGS
+----
+Each time a superproject update removes a populated submodule
+(e.g. when switching between commits before and after the removal) a
+stale submodule checkout will remain in the old location. Removing the
+old directory is only safe when it uses a gitfile, as otherwise the
+history of the submodule will be deleted too. This step will be
+obsolete when recursive submodule update has been implemented.
+
+SEE ALSO
+--------
+linkgit:git-add[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-send-email.adoc b/git-send-email.adoc
new file mode 100644
index 0000000..7f223db
--- /dev/null
+++ b/git-send-email.adoc
@@ -0,0 +1,543 @@
+git-send-email(1)
+=================
+
+NAME
+----
+git-send-email - Send a collection of patches as emails
+
+
+SYNOPSIS
+--------
+[verse]
+'git send-email' [<options>] (<file>|<directory>)...
+'git send-email' [<options>] <format-patch-options>
+'git send-email' --dump-aliases
+'git send-email' --translate-aliases
+
+
+DESCRIPTION
+-----------
+Takes the patches given on the command line and emails them out.
+Patches can be specified as files, directories (which will send all
+files in the directory), or directly as a revision list. In the
+last case, any format accepted by linkgit:git-format-patch[1] can
+be passed to git send-email, as well as options understood by
+linkgit:git-format-patch[1].
+
+The header of the email is configurable via command-line options. If not
+specified on the command line, the user will be prompted with a ReadLine
+enabled interface to provide the necessary information.
+
+There are two formats accepted for patch files:
+
+1. mbox format files
++
+This is what linkgit:git-format-patch[1] generates. Most headers and MIME
+formatting are ignored.
+
+2. The original format used by Greg Kroah-Hartman's 'send_lots_of_email.pl'
+ script
++
+This format expects the first line of the file to contain the "Cc:" value
+and the "Subject:" of the message as the second line.
+
+
+OPTIONS
+-------
+
+Composing
+~~~~~~~~~
+
+--annotate::
+ Review and edit each patch you're about to send. Default is the value
+ of `sendemail.annotate`. See the CONFIGURATION section for
+ `sendemail.multiEdit`.
+
+--bcc=<address>,...::
+ Specify a "Bcc:" value for each email. Default is the value of
+ `sendemail.bcc`.
++
+This option may be specified multiple times.
+
+--cc=<address>,...::
+ Specify a starting "Cc:" value for each email.
+ Default is the value of `sendemail.cc`.
++
+This option may be specified multiple times.
+
+--compose::
+ Invoke a text editor (see GIT_EDITOR in linkgit:git-var[1])
+ to edit an introductory message for the patch series.
++
+When `--compose` is used, git send-email will use the From, To, Cc, Bcc,
+Subject, Reply-To, and In-Reply-To headers specified in the message. If
+the body of the message (what you type after the headers and a blank
+line) only contains blank (or Git: prefixed) lines, the summary won't be
+sent, but the headers mentioned above will be used unless they are
+removed.
++
+Missing From or In-Reply-To headers will be prompted for.
++
+See the CONFIGURATION section for `sendemail.multiEdit`.
+
+--from=<address>::
+ Specify the sender of the emails. If not specified on the command line,
+ the value of the `sendemail.from` configuration option is used. If
+ neither the command-line option nor `sendemail.from` are set, then the
+ user will be prompted for the value. The default for the prompt will be
+ the value of GIT_AUTHOR_IDENT, or GIT_COMMITTER_IDENT if that is not
+ set, as returned by "git var -l".
+
+--reply-to=<address>::
+ Specify the address where replies from recipients should go to.
+ Use this if replies to messages should go to another address than what
+ is specified with the --from parameter.
+
+--in-reply-to=<identifier>::
+ Make the first mail (or all the mails with `--no-thread`) appear as a
+ reply to the given Message-ID, which avoids breaking threads to
+ provide a new patch series.
+ The second and subsequent emails will be sent as replies according to
+ the `--[no-]chain-reply-to` setting.
++
+So for example when `--thread` and `--no-chain-reply-to` are specified, the
+second and subsequent patches will be replies to the first one like in the
+illustration below where `[PATCH v2 0/3]` is in reply to `[PATCH 0/2]`:
++
+ [PATCH 0/2] Here is what I did...
+ [PATCH 1/2] Clean up and tests
+ [PATCH 2/2] Implementation
+ [PATCH v2 0/3] Here is a reroll
+ [PATCH v2 1/3] Clean up
+ [PATCH v2 2/3] New tests
+ [PATCH v2 3/3] Implementation
++
+Only necessary if --compose is also set. If --compose
+is not set, this will be prompted for.
+
+--subject=<string>::
+ Specify the initial subject of the email thread.
+ Only necessary if --compose is also set. If --compose
+ is not set, this will be prompted for.
+
+--to=<address>,...::
+ Specify the primary recipient of the emails generated. Generally, this
+ will be the upstream maintainer of the project involved. Default is the
+ value of the `sendemail.to` configuration value; if that is unspecified,
+ and --to-cmd is not specified, this will be prompted for.
++
+This option may be specified multiple times.
+
+--8bit-encoding=<encoding>::
+ When encountering a non-ASCII message or subject that does not
+ declare its encoding, add headers/quoting to indicate it is
+ encoded in <encoding>. Default is the value of the
+ 'sendemail.assume8bitEncoding'; if that is unspecified, this
+ will be prompted for if any non-ASCII files are encountered.
++
+Note that no attempts whatsoever are made to validate the encoding.
+
+--compose-encoding=<encoding>::
+ Specify encoding of compose message. Default is the value of the
+ 'sendemail.composeEncoding'; if that is unspecified, UTF-8 is assumed.
+
+--transfer-encoding=(7bit|8bit|quoted-printable|base64|auto)::
+ Specify the transfer encoding to be used to send the message over SMTP.
+ 7bit will fail upon encountering a non-ASCII message. quoted-printable
+ can be useful when the repository contains files that contain carriage
+ returns, but makes the raw patch email file (as saved from a MUA) much
+ harder to inspect manually. base64 is even more fool proof, but also
+ even more opaque. auto will use 8bit when possible, and quoted-printable
+ otherwise.
++
+Default is the value of the `sendemail.transferEncoding` configuration
+value; if that is unspecified, default to `auto`.
+
+--xmailer::
+--no-xmailer::
+ Add (or prevent adding) the "X-Mailer:" header. By default,
+ the header is added, but it can be turned off by setting the
+ `sendemail.xmailer` configuration variable to `false`.
+
+Sending
+~~~~~~~
+
+--envelope-sender=<address>::
+ Specify the envelope sender used to send the emails.
+ This is useful if your default address is not the address that is
+ subscribed to a list. In order to use the 'From' address, set the
+ value to "auto". If you use the sendmail binary, you must have
+ suitable privileges for the -f parameter. Default is the value of the
+ `sendemail.envelopeSender` configuration variable; if that is
+ unspecified, choosing the envelope sender is left to your MTA.
+
+--sendmail-cmd=<command>::
+ Specify a command to run to send the email. The command should
+ be sendmail-like; specifically, it must support the `-i` option.
+ The command will be executed in the shell if necessary. Default
+ is the value of `sendemail.sendmailCmd`. If unspecified, and if
+ --smtp-server is also unspecified, git-send-email will search
+ for `sendmail` in `/usr/sbin`, `/usr/lib` and $PATH.
+
+--smtp-encryption=<encryption>::
+ Specify in what way encrypting begins for the SMTP connection.
+ Valid values are 'ssl' and 'tls'. Any other value reverts to plain
+ (unencrypted) SMTP, which defaults to port 25.
+ Despite the names, both values will use the same newer version of TLS,
+ but for historic reasons have these names. 'ssl' refers to "implicit"
+ encryption (sometimes called SMTPS), that uses port 465 by default.
+ 'tls' refers to "explicit" encryption (often known as STARTTLS),
+ that uses port 25 by default. Other ports might be used by the SMTP
+ server, which are not the default. Commonly found alternative port for
+ 'tls' and unencrypted is 587. You need to check your provider's
+ documentation or your server configuration to make sure
+ for your own case. Default is the value of `sendemail.smtpEncryption`.
+
+--smtp-domain=<FQDN>::
+ Specifies the Fully Qualified Domain Name (FQDN) used in the
+ HELO/EHLO command to the SMTP server. Some servers require the
+ FQDN to match your IP address. If not set, git send-email attempts
+ to determine your FQDN automatically. Default is the value of
+ `sendemail.smtpDomain`.
+
+--smtp-auth=<mechanisms>::
+ Whitespace-separated list of allowed SMTP-AUTH mechanisms. This setting
+ forces using only the listed mechanisms. Example:
++
+------
+$ git send-email --smtp-auth="PLAIN LOGIN GSSAPI" ...
+------
++
+If at least one of the specified mechanisms matches the ones advertised by the
+SMTP server and if it is supported by the utilized SASL library, the mechanism
+is used for authentication. If neither 'sendemail.smtpAuth' nor `--smtp-auth`
+is specified, all mechanisms supported by the SASL library can be used. The
+special value 'none' maybe specified to completely disable authentication
+independently of `--smtp-user`
+
+--smtp-pass[=<password>]::
+ Password for SMTP-AUTH. The argument is optional: If no
+ argument is specified, then the empty string is used as
+ the password. Default is the value of `sendemail.smtpPass`,
+ however `--smtp-pass` always overrides this value.
++
+Furthermore, passwords need not be specified in configuration files
+or on the command line. If a username has been specified (with
+`--smtp-user` or a `sendemail.smtpUser`), but no password has been
+specified (with `--smtp-pass` or `sendemail.smtpPass`), then
+a password is obtained using 'git-credential'.
+
+--no-smtp-auth::
+ Disable SMTP authentication. Short hand for `--smtp-auth=none`
+
+--smtp-server=<host>::
+ If set, specifies the outgoing SMTP server to use (e.g.
+ `smtp.example.com` or a raw IP address). If unspecified, and if
+ `--sendmail-cmd` is also unspecified, the default is to search
+ for `sendmail` in `/usr/sbin`, `/usr/lib` and $PATH if such a
+ program is available, falling back to `localhost` otherwise.
++
+For backward compatibility, this option can also specify a full pathname
+of a sendmail-like program instead; the program must support the `-i`
+option. This method does not support passing arguments or using plain
+command names. For those use cases, consider using `--sendmail-cmd`
+instead.
+
+--smtp-server-port=<port>::
+ Specifies a port different from the default port (SMTP
+ servers typically listen to smtp port 25, but may also listen to
+ submission port 587, or the common SSL smtp port 465);
+ symbolic port names (e.g. "submission" instead of 587)
+ are also accepted. The port can also be set with the
+ `sendemail.smtpServerPort` configuration variable.
+
+--smtp-server-option=<option>::
+ If set, specifies the outgoing SMTP server option to use.
+ Default value can be specified by the `sendemail.smtpServerOption`
+ configuration option.
++
+The --smtp-server-option option must be repeated for each option you want
+to pass to the server. Likewise, different lines in the configuration files
+must be used for each option.
+
+--smtp-ssl::
+ Legacy alias for '--smtp-encryption ssl'.
+
+--smtp-ssl-cert-path::
+ Path to a store of trusted CA certificates for SMTP SSL/TLS
+ certificate validation (either a directory that has been processed
+ by 'c_rehash', or a single file containing one or more PEM format
+ certificates concatenated together: see verify(1) -CAfile and
+ -CApath for more information on these). Set it to an empty string
+ to disable certificate verification. Defaults to the value of the
+ `sendemail.smtpSSLCertPath` configuration variable, if set, or the
+ backing SSL library's compiled-in default otherwise (which should
+ be the best choice on most platforms).
+
+--smtp-user=<user>::
+ Username for SMTP-AUTH. Default is the value of `sendemail.smtpUser`;
+ if a username is not specified (with `--smtp-user` or `sendemail.smtpUser`),
+ then authentication is not attempted.
+
+--smtp-debug=(0|1)::
+ Enable (1) or disable (0) debug output. If enabled, SMTP
+ commands and replies will be printed. Useful to debug TLS
+ connection and authentication problems.
+
+--batch-size=<num>::
+ Some email servers (e.g. smtp.163.com) limit the number emails to be
+ sent per session (connection) and this will lead to a failure when
+ sending many messages. With this option, send-email will disconnect after
+ sending $<num> messages and wait for a few seconds (see --relogin-delay)
+ and reconnect, to work around such a limit. You may want to
+ use some form of credential helper to avoid having to retype
+ your password every time this happens. Defaults to the
+ `sendemail.smtpBatchSize` configuration variable.
+
+--relogin-delay=<int>::
+ Waiting $<int> seconds before reconnecting to SMTP server. Used together
+ with --batch-size option. Defaults to the `sendemail.smtpReloginDelay`
+ configuration variable.
+
+Automating
+~~~~~~~~~~
+
+--no-to::
+--no-cc::
+--no-bcc::
+ Clears any list of "To:", "Cc:", "Bcc:" addresses previously
+ set via config.
+
+--no-identity::
+ Clears the previously read value of `sendemail.identity` set
+ via config, if any.
+
+--to-cmd=<command>::
+ Specify a command to execute once per patch file which
+ should generate patch file specific "To:" entries.
+ Output of this command must be single email address per line.
+ Default is the value of 'sendemail.toCmd' configuration value.
+
+--cc-cmd=<command>::
+ Specify a command to execute once per patch file which
+ should generate patch file specific "Cc:" entries.
+ Output of this command must be single email address per line.
+ Default is the value of `sendemail.ccCmd` configuration value.
+
+--header-cmd=<command>::
+ Specify a command that is executed once per outgoing message
+ and output RFC 2822 style header lines to be inserted into
+ them. When the `sendemail.headerCmd` configuration variable is
+ set, its value is always used. When --header-cmd is provided
+ at the command line, its value takes precedence over the
+ `sendemail.headerCmd` configuration variable.
+
+--no-header-cmd::
+ Disable any header command in use.
+
+--[no-]chain-reply-to::
+ If this is set, each email will be sent as a reply to the previous
+ email sent. If disabled with "--no-chain-reply-to", all emails after
+ the first will be sent as replies to the first email sent. When using
+ this, it is recommended that the first file given be an overview of the
+ entire patch series. Disabled by default, but the `sendemail.chainReplyTo`
+ configuration variable can be used to enable it.
+
+--identity=<identity>::
+ A configuration identity. When given, causes values in the
+ 'sendemail.<identity>' subsection to take precedence over
+ values in the 'sendemail' section. The default identity is
+ the value of `sendemail.identity`.
+
+--[no-]signed-off-by-cc::
+ If this is set, add emails found in the `Signed-off-by` trailer or Cc: lines to the
+ cc list. Default is the value of `sendemail.signedOffByCc` configuration
+ value; if that is unspecified, default to --signed-off-by-cc.
+
+--[no-]cc-cover::
+ If this is set, emails found in Cc: headers in the first patch of
+ the series (typically the cover letter) are added to the cc list
+ for each email set. Default is the value of 'sendemail.ccCover'
+ configuration value; if that is unspecified, default to --no-cc-cover.
+
+--[no-]to-cover::
+ If this is set, emails found in To: headers in the first patch of
+ the series (typically the cover letter) are added to the to list
+ for each email set. Default is the value of 'sendemail.toCover'
+ configuration value; if that is unspecified, default to --no-to-cover.
+
+--suppress-cc=<category>::
+ Specify an additional category of recipients to suppress the
+ auto-cc of:
++
+--
+- 'author' will avoid including the patch author.
+- 'self' will avoid including the sender.
+- 'cc' will avoid including anyone mentioned in Cc lines in the patch header
+ except for self (use 'self' for that).
+- 'bodycc' will avoid including anyone mentioned in Cc lines in the
+ patch body (commit message) except for self (use 'self' for that).
+- 'sob' will avoid including anyone mentioned in the Signed-off-by trailers except
+ for self (use 'self' for that).
+- 'misc-by' will avoid including anyone mentioned in Acked-by,
+ Reviewed-by, Tested-by and other "-by" lines in the patch body,
+ except Signed-off-by (use 'sob' for that).
+- 'cccmd' will avoid running the --cc-cmd.
+- 'body' is equivalent to 'sob' + 'bodycc' + 'misc-by'.
+- 'all' will suppress all auto cc values.
+--
++
+Default is the value of `sendemail.suppressCc` configuration value; if
+that is unspecified, default to 'self' if --suppress-from is
+specified, as well as 'body' if --no-signed-off-cc is specified.
+
+--[no-]suppress-from::
+ If this is set, do not add the From: address to the cc: list.
+ Default is the value of `sendemail.suppressFrom` configuration
+ value; if that is unspecified, default to --no-suppress-from.
+
+--[no-]thread::
+ If this is set, the In-Reply-To and References headers will be
+ added to each email sent. Whether each mail refers to the
+ previous email (`deep` threading per 'git format-patch'
+ wording) or to the first email (`shallow` threading) is
+ governed by "--[no-]chain-reply-to".
++
+If disabled with "--no-thread", those headers will not be added
+(unless specified with --in-reply-to). Default is the value of the
+`sendemail.thread` configuration value; if that is unspecified,
+default to --thread.
++
+It is up to the user to ensure that no In-Reply-To header already
+exists when 'git send-email' is asked to add it (especially note that
+'git format-patch' can be configured to do the threading itself).
+Failure to do so may not produce the expected result in the
+recipient's MUA.
+
+--[no-]mailmap::
+ Use the mailmap file (see linkgit:gitmailmap[5]) to map all
+ addresses to their canonical real name and email address. Additional
+ mailmap data specific to git-send-email may be provided using the
+ `sendemail.mailmap.file` or `sendemail.mailmap.blob` configuration
+ values. Defaults to `sendemail.mailmap`.
+
+Administering
+~~~~~~~~~~~~~
+
+--confirm=<mode>::
+ Confirm just before sending:
++
+--
+- 'always' will always confirm before sending
+- 'never' will never confirm before sending
+- 'cc' will confirm before sending when send-email has automatically
+ added addresses from the patch to the Cc list
+- 'compose' will confirm before sending the first message when using --compose.
+- 'auto' is equivalent to 'cc' + 'compose'
+--
++
+Default is the value of `sendemail.confirm` configuration value; if that
+is unspecified, default to 'auto' unless any of the suppress options
+have been specified, in which case default to 'compose'.
+
+--dry-run::
+ Do everything except actually send the emails.
+
+--[no-]format-patch::
+ When an argument may be understood either as a reference or as a file name,
+ choose to understand it as a format-patch argument (`--format-patch`)
+ or as a file name (`--no-format-patch`). By default, when such a conflict
+ occurs, git send-email will fail.
+
+--quiet::
+ Make git-send-email less verbose. One line per email should be
+ all that is output.
+
+--[no-]validate::
+ Perform sanity checks on patches.
+ Currently, validation means the following:
++
+--
+ * Invoke the sendemail-validate hook if present (see linkgit:githooks[5]).
+ * Warn of patches that contain lines longer than
+ 998 characters unless a suitable transfer encoding
+ ('auto', 'base64', or 'quoted-printable') is used;
+ this is due to SMTP limits as described by
+ https://www.ietf.org/rfc/rfc5322.txt.
+--
++
+Default is the value of `sendemail.validate`; if this is not set,
+default to `--validate`.
+
+--force::
+ Send emails even if safety checks would prevent it.
+
+
+Information
+~~~~~~~~~~~
+
+--dump-aliases::
+ Instead of the normal operation, dump the shorthand alias names from
+ the configured alias file(s), one per line in alphabetical order. Note
+ that this only includes the alias name and not its expanded email addresses.
+ See 'sendemail.aliasesFile' for more information about aliases.
+
+--translate-aliases::
+ Instead of the normal operation, read from standard input and
+ interpret each line as an email alias. Translate it according to the
+ configured alias file(s). Output each translated name and email
+ address to standard output, one per line. See 'sendemail.aliasFile'
+ for more information about aliases.
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/sendemail.adoc[]
+
+EXAMPLES
+--------
+Use gmail as the smtp server
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+To use 'git send-email' to send your patches through the GMail SMTP server,
+edit ~/.gitconfig to specify your account settings:
+
+----
+[sendemail]
+ smtpEncryption = tls
+ smtpServer = smtp.gmail.com
+ smtpUser = yourname@gmail.com
+ smtpServerPort = 587
+----
+
+If you have multi-factor authentication set up on your Gmail account, you can
+generate an app-specific password for use with 'git send-email'. Visit
+https://security.google.com/settings/security/apppasswords to create it.
+
+Once your commits are ready to be sent to the mailing list, run the
+following commands:
+
+ $ git format-patch --cover-letter -M origin/master -o outgoing/
+ $ edit outgoing/0000-*
+ $ git send-email outgoing/*
+
+The first time you run it, you will be prompted for your credentials. Enter the
+app-specific or your regular password as appropriate. If you have credential
+helper configured (see linkgit:git-credential[1]), the password will be saved in
+the credential store so you won't have to type it the next time.
+
+Note: the following core Perl modules that may be installed with your
+distribution of Perl are required:
+MIME::Base64, MIME::QuotedPrint, Net::Domain and Net::SMTP.
+These additional Perl modules are also required:
+Authen::SASL and Mail::Address.
+
+
+SEE ALSO
+--------
+linkgit:git-format-patch[1], linkgit:git-imap-send[1], mbox(5)
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-send-pack.adoc b/git-send-pack.adoc
new file mode 100644
index 0000000..b9e73f2
--- /dev/null
+++ b/git-send-pack.adoc
@@ -0,0 +1,157 @@
+git-send-pack(1)
+================
+
+NAME
+----
+git-send-pack - Push objects over Git protocol to another repository
+
+
+SYNOPSIS
+--------
+[verse]
+'git send-pack' [--mirror] [--dry-run] [--force]
+ [--receive-pack=<git-receive-pack>]
+ [--verbose] [--thin] [--atomic]
+ [--[no-]signed | --signed=(true|false|if-asked)]
+ [<host>:]<directory> (--all | <ref>...)
+
+DESCRIPTION
+-----------
+Usually you would want to use 'git push', which is a
+higher-level wrapper of this command, instead. See linkgit:git-push[1].
+
+Invokes 'git-receive-pack' on a possibly remote repository, and
+updates it from the current repository, sending named refs.
+
+
+OPTIONS
+-------
+--receive-pack=<git-receive-pack>::
+ Path to the 'git-receive-pack' program on the remote
+ end. Sometimes useful when pushing to a remote
+ repository over ssh, and you do not have the program in
+ a directory on the default $PATH.
+
+--exec=<git-receive-pack>::
+ Same as --receive-pack=<git-receive-pack>.
+
+--all::
+ Instead of explicitly specifying which refs to update,
+ update all heads that locally exist.
+
+--stdin::
+ Take the list of refs from stdin, one per line. If there
+ are refs specified on the command line in addition to this
+ option, then the refs from stdin are processed after those
+ on the command line.
++
+If `--stateless-rpc` is specified together with this option then
+the list of refs must be in packet format (pkt-line). Each ref must
+be in a separate packet, and the list must end with a flush packet.
+
+--dry-run::
+ Do everything except actually send the updates.
+
+--force::
+ Usually, the command refuses to update a remote ref that
+ is not an ancestor of the local ref used to overwrite it.
+ This flag disables the check. This means that
+ the remote repository can lose commits; use it with
+ care.
+
+--verbose::
+ Run verbosely.
+
+--thin::
+ Send a "thin" pack, which records objects in deltified form based
+ on objects not included in the pack to reduce network traffic.
+
+--atomic::
+ Use an atomic transaction for updating the refs. If any of the refs
+ fails to update then the entire push will fail without changing any
+ refs.
+
+--[no-]signed::
+--signed=(true|false|if-asked)::
+ GPG-sign the push request to update refs on the receiving
+ side, to allow it to be checked by the hooks and/or be
+ logged. If `false` or `--no-signed`, no signing will be
+ attempted. If `true` or `--signed`, the push will fail if the
+ server does not support signed pushes. If set to `if-asked`,
+ sign if and only if the server supports signed pushes. The push
+ will also fail if the actual call to `gpg --sign` fails. See
+ linkgit:git-receive-pack[1] for the details on the receiving end.
+
+--push-option=<string>::
+ Pass the specified string as a push option for consumption by
+ hooks on the server side. If the server doesn't support push
+ options, error out. See linkgit:git-push[1] and
+ linkgit:githooks[5] for details.
+
+<host>::
+ A remote host to house the repository. When this
+ part is specified, 'git-receive-pack' is invoked via
+ ssh.
+
+<directory>::
+ The repository to update.
+
+<ref>...::
+ The remote refs to update.
+
+
+SPECIFYING THE REFS
+-------------------
+
+There are three ways to specify which refs to update on the
+remote end.
+
+With the `--all` flag, all refs that exist locally are transferred to
+the remote side. You cannot specify any '<ref>' if you use
+this flag.
+
+Without `--all` and without any '<ref>', the heads that exist
+both on the local side and on the remote side are updated.
+
+When one or more '<ref>' are specified explicitly (whether on the
+command line or via `--stdin`), it can be either a
+single pattern, or a pair of such patterns separated by a colon
+":" (this means that a ref name cannot have a colon in it). A
+single pattern '<name>' is just shorthand for '<name>:<name>'.
+
+Each pattern pair consists of the source side (before the colon)
+and the destination side (after the colon). The ref to be
+pushed is determined by finding a match that matches the source
+side, and where it is pushed is determined by using the
+destination side. The rules used to match a ref are the same
+rules used by 'git rev-parse' to resolve a symbolic ref
+name. See linkgit:git-rev-parse[1].
+
+ - It is an error if <src> does not match exactly one of the
+ local refs.
+
+ - It is an error if <dst> matches more than one remote ref.
+
+ - If <dst> does not match any remote ref, either
+
+ * it has to start with "refs/"; <dst> is used as the
+ destination literally in this case.
+
+ * <src> == <dst> and the ref that matched the <src> must not
+ exist in the set of remote refs; the ref matched <src>
+ locally is used as the name of the destination.
+
+Without `--force`, the <src> ref is stored at the remote only if
+<dst> does not exist, or <dst> is a proper subset (i.e. an
+ancestor) of <src>. This check, known as the "fast-forward check",
+is performed to avoid accidentally overwriting the
+remote ref and losing other people's commits from there.
+
+With `--force`, the fast-forward check is disabled for all refs.
+
+Optionally, a <ref> parameter can be prefixed with a plus '+' sign
+to disable the fast-forward check only on that ref.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-sh-i18n--envsubst.adoc b/git-sh-i18n--envsubst.adoc
new file mode 100644
index 0000000..2ffaf93
--- /dev/null
+++ b/git-sh-i18n--envsubst.adoc
@@ -0,0 +1,36 @@
+git-sh-i18n{litdd}envsubst(1)
+=============================
+
+NAME
+----
+git-sh-i18n--envsubst - Git's own envsubst(1) for i18n fallbacks
+
+SYNOPSIS
+--------
+[verse]
+eval_gettext () {
+ printf "%s" "$1" | (
+ export PATH $('git sh-i18n{litdd}envsubst' --variables "$1");
+ 'git sh-i18n{litdd}envsubst' "$1"
+ )
+}
+
+DESCRIPTION
+-----------
+
+This is not a command the end user would want to run. Ever.
+This documentation is meant for people who are studying the
+plumbing scripts and/or are writing new ones.
+
+'git sh-i18n{litdd}envsubst' is Git's stripped-down copy of the GNU
+`envsubst(1)` program that comes with the GNU gettext package. It's
+used internally by linkgit:git-sh-i18n[1] to interpolate the variables
+passed to the `eval_gettext` function.
+
+No promises are made about the interface, or that this
+program won't disappear without warning in the next version
+of Git. Don't use it.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-sh-i18n.adoc b/git-sh-i18n.adoc
new file mode 100644
index 0000000..60cf49c
--- /dev/null
+++ b/git-sh-i18n.adoc
@@ -0,0 +1,43 @@
+git-sh-i18n(1)
+==============
+
+NAME
+----
+git-sh-i18n - Git's i18n setup code for shell scripts
+
+SYNOPSIS
+--------
+[verse]
+'. "$(git --exec-path)/git-sh-i18n"'
+
+DESCRIPTION
+-----------
+
+This is not a command the end user would want to run. Ever.
+This documentation is meant for people who are studying the
+Porcelain-ish scripts and/or are writing new ones.
+
+The 'git sh-i18n scriptlet is designed to be sourced (using
+`.`) by Git's porcelain programs implemented in shell
+script. It provides wrappers for the GNU `gettext` and
+`eval_gettext` functions accessible through the `gettext.sh`
+script, and provides pass-through fallbacks on systems
+without GNU gettext.
+
+FUNCTIONS
+---------
+
+gettext::
+ Currently a dummy fall-through function implemented as a wrapper
+ around `printf(1)`. Will be replaced by a real gettext
+ implementation in a later version.
+
+eval_gettext::
+ Currently a dummy fall-through function implemented as a wrapper
+ around `printf(1)` with variables expanded by the
+ linkgit:git-sh-i18n{litdd}envsubst[1] helper. Will be replaced by a
+ real gettext implementation in a later version.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-sh-setup.adoc b/git-sh-setup.adoc
new file mode 100644
index 0000000..bdaf6e5
--- /dev/null
+++ b/git-sh-setup.adoc
@@ -0,0 +1,95 @@
+git-sh-setup(1)
+===============
+
+NAME
+----
+git-sh-setup - Common Git shell script setup code
+
+SYNOPSIS
+--------
+[verse]
+'. "$(git --exec-path)/git-sh-setup"'
+
+DESCRIPTION
+-----------
+
+This is not a command the end user would want to run. Ever.
+This documentation is meant for people who are studying the
+Porcelain-ish scripts and/or are writing new ones.
+
+The 'git sh-setup' scriptlet is designed to be sourced (using
+`.`) by other shell scripts to set up some variables pointing at
+the normal Git directories and a few helper shell functions.
+
+Before sourcing it, your script should set up a few variables;
+`USAGE` (and `LONG_USAGE`, if any) is used to define the message
+given by `usage()` shell function. `SUBDIRECTORY_OK` can be set
+if the script can run from a subdirectory of the working tree
+(some commands do not).
+
+The scriptlet sets `GIT_DIR` and `GIT_OBJECT_DIRECTORY` shell
+variables, but does *not* export them to the environment.
+
+FUNCTIONS
+---------
+
+die::
+ exit after emitting the supplied error message to the
+ standard error stream.
+
+usage::
+ die with the usage message.
+
+set_reflog_action::
+ Set `GIT_REFLOG_ACTION` environment to a given string (typically
+ the name of the program) unless it is already set. Whenever
+ the script runs a `git` command that updates refs, a reflog
+ entry is created using the value of this string to leave the
+ record of what command updated the ref.
+
+git_editor::
+ runs an editor of user's choice (GIT_EDITOR, core.editor, VISUAL or
+ EDITOR) on a given file, but error out if no editor is specified
+ and the terminal is dumb.
+
+is_bare_repository::
+ outputs `true` or `false` to the standard output stream
+ to indicate if the repository is a bare repository
+ (i.e. without an associated working tree).
+
+cd_to_toplevel::
+ runs chdir to the toplevel of the working tree.
+
+require_work_tree::
+ checks if the current directory is within the working tree
+ of the repository, and otherwise dies.
+
+require_work_tree_exists::
+ checks if the working tree associated with the repository
+ exists, and otherwise dies. Often done before calling
+ cd_to_toplevel, which is impossible to do if there is no
+ working tree.
+
+require_clean_work_tree <action> [<hint>]::
+ checks that the working tree and index associated with the
+ repository have no uncommitted changes to tracked files.
+ Otherwise it emits an error message of the form `Cannot
+ <action>: <reason>. <hint>`, and dies. Example:
++
+----------------
+require_clean_work_tree rebase "Please commit or stash them."
+----------------
+
+get_author_ident_from_commit::
+ outputs code for use with eval to set the GIT_AUTHOR_NAME,
+ GIT_AUTHOR_EMAIL and GIT_AUTHOR_DATE variables for a given commit.
+
+create_virtual_base::
+ modifies the first file so only lines in common with the
+ second file remain. If there is insufficient common material,
+ then the first file is left empty. The result is suitable
+ as a virtual base input for a 3-way merge.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-shell.adoc b/git-shell.adoc
new file mode 100644
index 0000000..11361f3
--- /dev/null
+++ b/git-shell.adoc
@@ -0,0 +1,106 @@
+git-shell(1)
+============
+
+NAME
+----
+git-shell - Restricted login shell for Git-only SSH access
+
+
+SYNOPSIS
+--------
+[verse]
+'chsh' -s $(command -v git-shell) <user>
+'git clone' <user>`@localhost:/path/to/repo.git`
+'ssh' <user>`@localhost`
+
+DESCRIPTION
+-----------
+
+This is a login shell for SSH accounts to provide restricted Git access.
+It permits execution only of server-side Git commands implementing the
+pull/push functionality, plus custom commands present in a subdirectory
+named `git-shell-commands` in the user's home directory.
+
+COMMANDS
+--------
+
+'git shell' accepts the following commands after the `-c` option:
+
+'git receive-pack <argument>'::
+'git upload-pack <argument>'::
+'git upload-archive <argument>'::
+ Call the corresponding server-side command to support
+ the client's 'git push', 'git fetch', or 'git archive --remote'
+ request.
+'cvs server'::
+ Imitate a CVS server. See linkgit:git-cvsserver[1].
+
+If a `~/git-shell-commands` directory is present, 'git shell' will
+also handle other, custom commands by running
+"`git-shell-commands/<command> <arguments>`" from the user's home
+directory.
+
+INTERACTIVE USE
+---------------
+
+By default, the commands above can be executed only with the `-c`
+option; the shell is not interactive.
+
+If a `~/git-shell-commands` directory is present, 'git shell'
+can also be run interactively (with no arguments). If a `help`
+command is present in the `git-shell-commands` directory, it is
+run to provide the user with an overview of allowed actions. Then a
+"git> " prompt is presented at which one can enter any of the
+commands from the `git-shell-commands` directory, or `exit` to close
+the connection.
+
+Generally this mode is used as an administrative interface to allow
+users to list repositories they have access to, create, delete, or
+rename repositories, or change repository descriptions and
+permissions.
+
+If a `no-interactive-login` command exists, then it is run and the
+interactive shell is aborted.
+
+EXAMPLES
+--------
+
+To disable interactive logins, displaying a greeting instead:
+
+----------------
+$ chsh -s /usr/bin/git-shell
+$ mkdir $HOME/git-shell-commands
+$ cat >$HOME/git-shell-commands/no-interactive-login <<\EOF
+#!/bin/sh
+printf '%s\n' "Hi $USER! You've successfully authenticated, but I do not"
+printf '%s\n' "provide interactive shell access."
+exit 128
+EOF
+$ chmod +x $HOME/git-shell-commands/no-interactive-login
+----------------
+
+To enable git-cvsserver access (which should generally have the
+`no-interactive-login` example above as a prerequisite, as creating
+the git-shell-commands directory allows interactive logins):
+
+----------------
+$ cat >$HOME/git-shell-commands/cvs <<\EOF
+if ! test $# = 1 && test "$1" = "server"
+then
+ echo >&2 "git-cvsserver only handles \"server\""
+ exit 1
+fi
+exec git cvsserver server
+EOF
+$ chmod +x $HOME/git-shell-commands/cvs
+----------------
+
+SEE ALSO
+--------
+ssh(1),
+linkgit:git-daemon[1],
+contrib/git-shell-commands/README
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-shortlog.adoc b/git-shortlog.adoc
new file mode 100644
index 0000000..d8ab38d
--- /dev/null
+++ b/git-shortlog.adoc
@@ -0,0 +1,130 @@
+git-shortlog(1)
+===============
+
+NAME
+----
+git-shortlog - Summarize 'git log' output
+
+SYNOPSIS
+--------
+[verse]
+'git shortlog' [<options>] [<revision-range>] [[--] <path>...]
+git log --pretty=short | 'git shortlog' [<options>]
+
+DESCRIPTION
+-----------
+Summarizes 'git log' output in a format suitable for inclusion
+in release announcements. Each commit will be grouped by author and title.
+
+Additionally, "[PATCH]" will be stripped from the commit description.
+
+If no revisions are passed on the command line and either standard input
+is not a terminal or there is no current branch, 'git shortlog' will
+output a summary of the log read from standard input, without
+reference to the current repository.
+
+OPTIONS
+-------
+
+-n::
+--numbered::
+ Sort output according to the number of commits per author instead
+ of author alphabetic order.
+
+-s::
+--summary::
+ Suppress commit description and provide a commit count summary only.
+
+-e::
+--email::
+ Show the email address of each author.
+
+--format[=<format>]::
+ Instead of the commit subject, use some other information to
+ describe each commit. '<format>' can be any string accepted
+ by the `--format` option of 'git log', such as '* [%h] %s'.
+ (See the "PRETTY FORMATS" section of linkgit:git-log[1].)
+
+ Each pretty-printed commit will be rewrapped before it is shown.
+
+--date=<format>::
+ Show dates formatted according to the given date string. (See
+ the `--date` option in the "Commit Formatting" section of
+ linkgit:git-log[1]). Useful with `--group=format:<format>`.
+
+--group=<type>::
+ Group commits based on `<type>`. If no `--group` option is
+ specified, the default is `author`. `<type>` is one of:
++
+--
+ - `author`, commits are grouped by author
+ - `committer`, commits are grouped by committer (the same as `-c`)
+ - `trailer:<field>`, the `<field>` is interpreted as a case-insensitive
+ commit message trailer (see linkgit:git-interpret-trailers[1]). For
+ example, if your project uses `Reviewed-by` trailers, you might want
+ to see who has been reviewing with
+ `git shortlog -ns --group=trailer:reviewed-by`.
+ - `format:<format>`, any string accepted by the `--format` option of
+ 'git log'. (See the "PRETTY FORMATS" section of
+ linkgit:git-log[1].)
++
+Note that commits that do not include the trailer will not be counted.
+Likewise, commits with multiple trailers (e.g., multiple signoffs) may
+be counted more than once (but only once per unique trailer value in
+that commit).
++
+Shortlog will attempt to parse each trailer value as a `name <email>`
+identity. If successful, the mailmap is applied and the email is omitted
+unless the `--email` option is specified. If the value cannot be parsed
+as an identity, it will be taken literally and completely.
+--
++
+If `--group` is specified multiple times, commits are counted under each
+value (but again, only once per unique value in that commit). For
+example, `git shortlog --group=author --group=trailer:co-authored-by`
+counts both authors and co-authors.
+
+-c::
+--committer::
+ This is an alias for `--group=committer`.
+
+-w[<width>[,<indent1>[,<indent2>]]]::
+ Linewrap the output by wrapping each line at `width`. The first
+ line of each entry is indented by `indent1` spaces, and the second
+ and subsequent lines are indented by `indent2` spaces. `width`,
+ `indent1`, and `indent2` default to 76, 6 and 9 respectively.
++
+If width is `0` (zero) then indent the lines of the output without wrapping
+them.
+
+<revision-range>::
+ Show only commits in the specified revision range. When no
+ <revision-range> is specified, it defaults to `HEAD` (i.e. the
+ whole history leading to the current commit). `origin..HEAD`
+ specifies all the commits reachable from the current commit
+ (i.e. `HEAD`), but not from `origin`. For a complete list of
+ ways to spell <revision-range>, see the "Specifying Ranges"
+ section of linkgit:gitrevisions[7].
+
+[--] <path>...::
+ Consider only commits that are enough to explain how the files
+ that match the specified paths came to be.
++
+Paths may need to be prefixed with `--` to separate them from
+options or the revision range, when confusion arises.
+
+:git-shortlog: 1
+include::rev-list-options.adoc[]
+
+MAPPING AUTHORS
+---------------
+
+See linkgit:gitmailmap[5].
+
+Note that if `git shortlog` is run outside of a repository (to process
+log contents on standard input), it will look for a `.mailmap` file in
+the current directory.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-show-branch.adoc b/git-show-branch.adoc
new file mode 100644
index 0000000..7e86d54
--- /dev/null
+++ b/git-show-branch.adoc
@@ -0,0 +1,211 @@
+git-show-branch(1)
+==================
+
+NAME
+----
+git-show-branch - Show branches and their commits
+
+SYNOPSIS
+--------
+[verse]
+'git show-branch' [-a | --all] [-r | --remotes] [--topo-order | --date-order]
+ [--current] [--color[=<when>] | --no-color] [--sparse]
+ [--more=<n> | --list | --independent | --merge-base]
+ [--no-name | --sha1-name] [--topics]
+ [(<rev> | <glob>)...]
+'git show-branch' (-g | --reflog)[=<n>[,<base>]] [--list] [<ref>]
+
+DESCRIPTION
+-----------
+
+Shows the commit ancestry graph starting from the commits named
+with <rev>s or <glob>s (or all refs under refs/heads
+and/or refs/tags) semi-visually.
+
+It cannot show more than 26 branches and commits at a time.
+
+It uses `showbranch.default` multi-valued configuration items if
+no <rev> or <glob> is given on the command line.
+
+
+OPTIONS
+-------
+<rev>::
+ Arbitrary extended SHA-1 expression (see linkgit:gitrevisions[7])
+ that typically names a branch head or a tag.
+
+<glob>::
+ A glob pattern that matches branch or tag names under
+ refs/. For example, if you have many topic
+ branches under refs/heads/topic, giving
+ `topic/*` would show all of them.
+
+-r::
+--remotes::
+ Show the remote-tracking branches.
+
+-a::
+--all::
+ Show both remote-tracking branches and local branches.
+
+--current::
+ With this option, the command includes the current
+ branch in the list of revs to be shown when it is not
+ given on the command line.
+
+--topo-order::
+ By default, the branches and their commits are shown in
+ reverse chronological order. This option makes them
+ appear in topological order (i.e., descendant commits
+ are shown before their parents).
+
+--date-order::
+ This option is similar to `--topo-order` in the sense that no
+ parent comes before all of its children, but otherwise commits
+ are ordered according to their commit date.
+
+--sparse::
+ By default, the output omits merges that are reachable
+ from only one tip being shown. This option makes them
+ visible.
+
+--more=<n>::
+ Usually the command stops output upon showing the commit
+ that is the common ancestor of all the branches. This
+ flag tells the command to go <n> more common commits
+ beyond that. When <n> is negative, display only the
+ <ref>s given, without showing the commit ancestry tree.
+
+--list::
+ Synonym to `--more=-1`
+
+--merge-base::
+ Instead of showing the commit list, determine possible
+ merge bases for the specified commits. All merge bases
+ will be contained in all specified commits. This is
+ different from how linkgit:git-merge-base[1] handles
+ the case of three or more commits.
+
+--independent::
+ Among the <ref>s given, display only the ones that cannot be
+ reached from any other <ref>.
+
+--no-name::
+ Do not show naming strings for each commit.
+
+--sha1-name::
+ Instead of naming the commits using the path to reach
+ them from heads (e.g. "master~2" to mean the grandparent
+ of "master"), name them with the unique prefix of their
+ object names.
+
+--topics::
+ Shows only commits that are NOT on the first branch given.
+ This helps track topic branches by hiding any commit that
+ is already in the main line of development. When given
+ "git show-branch --topics master topic1 topic2", this
+ will show the revisions given by "git rev-list {caret}master
+ topic1 topic2"
+
+-g::
+--reflog[=<n>[,<base>]] [<ref>]::
+ Shows <n> most recent ref-log entries for the given
+ ref. If <base> is given, <n> entries going back from
+ that entry. <base> can be specified as count or date.
+ When no explicit <ref> parameter is given, it defaults to the
+ current branch (or `HEAD` if it is detached).
+
+--color[=<when>]::
+ Color the status sign (one of these: `*` `!` `+` `-`) of each commit
+ corresponding to the branch it's in.
+ The value must be always (the default), never, or auto.
+
+--no-color::
+ Turn off colored output, even when the configuration file gives the
+ default to color output.
+ Same as `--color=never`.
+
+Note that --more, --list, --independent, and --merge-base options
+are mutually exclusive.
+
+
+OUTPUT
+------
+
+Given N <ref>s, the first N lines are the one-line description from
+their commit message. The branch head that is pointed at by
+$GIT_DIR/HEAD is prefixed with an asterisk `*` character while other
+heads are prefixed with a `!` character.
+
+Following these N lines, a one-line log for each commit is
+displayed, indented N places. If a commit is on the I-th
+branch, the I-th indentation character shows a `+` sign;
+otherwise it shows a space. Merge commits are denoted by
+a `-` sign. Each commit shows a short name that
+can be used as an extended SHA-1 to name that commit.
+
+The following example shows three branches, "master", "fixes",
+and "mhf":
+
+------------------------------------------------
+$ git show-branch master fixes mhf
+* [master] Add 'git show-branch'.
+ ! [fixes] Introduce "reset type" flag to "git reset"
+ ! [mhf] Allow "+remote:local" refspec to cause --force when fetching.
+---
+ + [mhf] Allow "+remote:local" refspec to cause --force when fetching.
+ + [mhf~1] Use git-octopus when pulling more than one head.
+ + [fixes] Introduce "reset type" flag to "git reset"
+ + [mhf~2] "git fetch --force".
+ + [mhf~3] Use .git/remote/origin, not .git/branches/origin.
+ + [mhf~4] Make "git pull" and "git fetch" default to origin
+ + [mhf~5] Infamous 'octopus merge'
+ + [mhf~6] Retire git-parse-remote.
+ + [mhf~7] Multi-head fetch.
+ + [mhf~8] Start adding the $GIT_DIR/remotes/ support.
+*++ [master] Add 'git show-branch'.
+------------------------------------------------
+
+These three branches all forked from a common commit, [master],
+whose commit message is "Add \'git show-branch'".
+The "fixes" branch adds one commit "Introduce "reset type" flag to
+"git reset"". The "mhf" branch adds many other commits.
+The current branch is "master".
+
+
+EXAMPLES
+--------
+
+If you keep your primary branches immediately under
+`refs/heads`, and topic branches in subdirectories of
+it, having the following in the configuration file may help:
+
+------------
+[showbranch]
+ default = --topo-order
+ default = heads/*
+
+------------
+
+With this, `git show-branch` without extra parameters would show
+only the primary branches. In addition, if you happen to be on
+your topic branch, it is shown as well.
+
+------------
+$ git show-branch --reflog="10,1 hour ago" --list master
+------------
+
+shows 10 reflog entries going back from the tip as of 1 hour ago.
+Without `--list`, the output also shows how these tips are
+topologically related to each other.
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/showbranch.adoc[]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-show-index.adoc b/git-show-index.adoc
new file mode 100644
index 0000000..00b3a90
--- /dev/null
+++ b/git-show-index.adoc
@@ -0,0 +1,52 @@
+git-show-index(1)
+=================
+
+NAME
+----
+git-show-index - Show packed archive index
+
+
+SYNOPSIS
+--------
+[verse]
+'git show-index' [--object-format=<hash-algorithm>] < <pack-idx-file>
+
+
+DESCRIPTION
+-----------
+Read the `.idx` file for a Git packfile (created with
+linkgit:git-pack-objects[1] or linkgit:git-index-pack[1]) from the
+standard input, and dump its contents. The output consists of one object
+per line, with each line containing two or three space-separated
+columns:
+
+ - the first column is the offset in bytes of the object within the
+ corresponding packfile
+
+ - the second column is the object id of the object
+
+ - if the index version is 2 or higher, the third column contains the
+ CRC32 of the object data
+
+The objects are output in the order in which they are found in the index
+file, which should be (in a correctly constructed file) sorted by object
+id.
+
+Note that you can get more information on a packfile by calling
+linkgit:git-verify-pack[1]. However, as this command considers only the
+index file itself, it's both faster and more flexible.
+
+OPTIONS
+-------
+
+--object-format=<hash-algorithm>::
+ Specify the given object format (hash algorithm) for the index file. The
+ valid values are 'sha1' and (if enabled) 'sha256'. The default is the
+ algorithm for the current repository (set by `extensions.objectFormat`), or
+ 'sha1' if no value is set or outside a repository..
++
+include::object-format-disclaimer.adoc[]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-show-ref.adoc b/git-show-ref.adoc
new file mode 100644
index 0000000..616d919
--- /dev/null
+++ b/git-show-ref.adoc
@@ -0,0 +1,214 @@
+git-show-ref(1)
+===============
+
+NAME
+----
+git-show-ref - List references in a local repository
+
+SYNOPSIS
+--------
+[verse]
+'git show-ref' [--head] [-d | --dereference]
+ [-s | --hash[=<n>]] [--abbrev[=<n>]] [--branches] [--tags]
+ [--] [<pattern>...]
+'git show-ref' --verify [-q | --quiet] [-d | --dereference]
+ [-s | --hash[=<n>]] [--abbrev[=<n>]]
+ [--] [<ref>...]
+'git show-ref' --exclude-existing[=<pattern>]
+'git show-ref' --exists <ref>
+
+DESCRIPTION
+-----------
+
+Displays references available in a local repository along with the associated
+commit IDs. Results can be filtered using a pattern and tags can be
+dereferenced into object IDs. Additionally, it can be used to test whether a
+particular ref exists.
+
+By default, shows the tags, heads, and remote refs.
+
+The `--exclude-existing` form is a filter that does the inverse. It reads
+refs from stdin, one ref per line, and shows those that don't exist in
+the local repository.
+
+The `--exists` form can be used to check for the existence of a single
+references. This form does not verify whether the reference resolves to an
+actual object.
+
+Use of this utility is encouraged in favor of directly accessing files under
+the `.git` directory.
+
+OPTIONS
+-------
+
+--head::
+
+ Show the HEAD reference, even if it would normally be filtered out.
+
+--branches::
+--tags::
+
+ Limit to local branches and local tags, respectively. These options
+ are not mutually exclusive; when given both, references stored in
+ "refs/heads" and "refs/tags" are displayed. Note that `--heads`
+ is a deprecated synonym for `--branches` and may be removed
+ in the future.
+
+-d::
+--dereference::
+
+ Dereference tags into object IDs as well. They will be shown with `^{}`
+ appended.
+
+-s::
+--hash[=<n>]::
+
+ Only show the OID, not the reference name. When combined with
+ `--dereference`, the dereferenced tag will still be shown after the OID.
+
+--verify::
+
+ Enable stricter reference checking by requiring an exact ref path.
+ Aside from returning an error code of 1, it will also print an error
+ message if `--quiet` was not specified.
+
+--exists::
+
+ Check whether the given reference exists. Returns an exit code of 0 if
+ it does, 2 if it is missing, and 1 in case looking up the reference
+ failed with an error other than the reference being missing.
+
+--abbrev[=<n>]::
+
+ Abbreviate the object name. When using `--hash`, you do
+ not have to say `--hash --abbrev`; `--hash=n` would do.
+
+-q::
+--quiet::
+
+ Do not print any results to stdout. Can be used with `--verify` to
+ silently check if a reference exists.
+
+--exclude-existing[=<pattern>]::
+
+ Make `git show-ref` act as a filter that reads refs from stdin of the
+ form `^(?:<anything>\s)?<refname>(?:\^{})?$`
+ and performs the following actions on each:
+ (1) strip `^{}` at the end of line if any;
+ (2) ignore if pattern is provided and does not head-match refname;
+ (3) warn if refname is not a well-formed refname and skip;
+ (4) ignore if refname is a ref that exists in the local repository;
+ (5) otherwise output the line.
+
+
+<pattern>...::
+
+ Show references matching one or more patterns. Patterns are matched from
+ the end of the full name, and only complete parts are matched, e.g.
+ 'master' matches 'refs/heads/master', 'refs/remotes/origin/master',
+ 'refs/tags/jedi/master' but not 'refs/heads/mymaster' or
+ 'refs/remotes/master/jedi'.
+
+OUTPUT
+------
+
+The output is in the format:
+
+------------
+<oid> SP <ref> LF
+------------
+
+For example,
+
+-----------------------------------------------------------------------------
+$ git show-ref --head --dereference
+832e76a9899f560a90ffd62ae2ce83bbeff58f54 HEAD
+832e76a9899f560a90ffd62ae2ce83bbeff58f54 refs/heads/master
+832e76a9899f560a90ffd62ae2ce83bbeff58f54 refs/heads/origin
+3521017556c5de4159da4615a39fa4d5d2c279b5 refs/tags/v0.99.9c
+6ddc0964034342519a87fe013781abf31c6db6ad refs/tags/v0.99.9c^{}
+055e4ae3ae6eb344cbabf2a5256a49ea66040131 refs/tags/v1.0rc4
+423325a2d24638ddcc82ce47be5e40be550f4507 refs/tags/v1.0rc4^{}
+...
+-----------------------------------------------------------------------------
+
+When using `--hash` (and not `--dereference`), the output is in the format:
+
+------------
+<oid> LF
+------------
+
+For example,
+
+-----------------------------------------------------------------------------
+$ git show-ref --branches --hash
+2e3ba0114a1f52b47df29743d6915d056be13278
+185008ae97960c8d551adcd9e23565194651b5d1
+03adf42c988195b50e1a1935ba5fcbc39b2b029b
+...
+-----------------------------------------------------------------------------
+
+EXAMPLES
+--------
+
+To show all references called "master", whether tags or heads or anything
+else, and regardless of how deep in the reference naming hierarchy they are,
+use:
+
+-----------------------------------------------------------------------------
+ git show-ref master
+-----------------------------------------------------------------------------
+
+This will show "refs/heads/master" but also "refs/remote/other-repo/master",
+if such references exist.
+
+When using the `--verify` flag, the command requires an exact path:
+
+-----------------------------------------------------------------------------
+ git show-ref --verify refs/heads/master
+-----------------------------------------------------------------------------
+
+will only match the exact branch called "master".
+
+If nothing matches, `git show-ref` will return an error code of 1,
+and in the case of verification, it will show an error message.
+
+For scripting, you can ask it to be quiet with the `--quiet` flag, which
+allows you to do things like
+
+-----------------------------------------------------------------------------
+ git show-ref --quiet --verify -- "refs/heads/$headname" ||
+ echo "$headname is not a valid branch"
+-----------------------------------------------------------------------------
+
+to check whether a particular branch exists or not (notice how we don't
+actually want to show any results, and we want to use the full refname for it
+in order to not trigger the problem with ambiguous partial matches).
+
+To show only tags, or only proper branch heads, use `--tags` and/or `--branches`
+respectively (using both means that it shows tags and branches, but not other
+random references under the refs/ subdirectory).
+
+To do automatic tag object dereferencing, use the `-d` or `--dereference`
+flag, so you can do
+
+-----------------------------------------------------------------------------
+ git show-ref --tags --dereference
+-----------------------------------------------------------------------------
+
+to get a listing of all tags together with what they dereference.
+
+FILES
+-----
+`.git/refs/*`, `.git/packed-refs`
+
+SEE ALSO
+--------
+linkgit:git-for-each-ref[1],
+linkgit:git-ls-remote[1],
+linkgit:git-update-ref[1],
+linkgit:gitrepository-layout[5]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-show.adoc b/git-show.adoc
new file mode 100644
index 0000000..51044c8
--- /dev/null
+++ b/git-show.adoc
@@ -0,0 +1,90 @@
+git-show(1)
+===========
+
+NAME
+----
+git-show - Show various types of objects
+
+
+SYNOPSIS
+--------
+[verse]
+'git show' [<options>] [<object>...]
+
+DESCRIPTION
+-----------
+Shows one or more objects (blobs, trees, tags and commits).
+
+For commits it shows the log message and textual diff. It also
+presents the merge commit in a special format as produced by
+'git diff-tree --cc'.
+
+For tags, it shows the tag message and the referenced objects.
+
+For trees, it shows the names (equivalent to 'git ls-tree'
+with --name-only).
+
+For plain blobs, it shows the plain contents.
+
+Some options that 'git log' command understands can be used to
+control how the changes the commit introduces are shown.
+
+This manual page describes only the most frequently used options.
+
+
+OPTIONS
+-------
+<object>...::
+ The names of objects to show (defaults to 'HEAD').
+ For a more complete list of ways to spell object names, see
+ "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
+
+include::pretty-options.adoc[]
+
+
+include::pretty-formats.adoc[]
+
+
+DIFF FORMATTING
+---------------
+The options below can be used to change the way `git show` generates
+diff output.
+
+:git-log: 1
+:diff-merges-default: `dense-combined`
+include::diff-options.adoc[]
+
+include::diff-generate-patch.adoc[]
+
+
+EXAMPLES
+--------
+
+`git show v1.0.0`::
+ Shows the tag `v1.0.0`, along with the object the tag
+ points at.
+
+`git show v1.0.0^{tree}`::
+ Shows the tree pointed to by the tag `v1.0.0`.
+
+`git show -s --format=%s v1.0.0^{commit}`::
+ Shows the subject of the commit pointed to by the
+ tag `v1.0.0`.
+
+`git show next~10:Documentation/README`::
+ Shows the contents of the file `Documentation/README` as
+ they were current in the 10th last commit of the branch
+ `next`.
+
+`git show master:Makefile master:t/Makefile`::
+ Concatenates the contents of said Makefiles in the head
+ of the branch `master`.
+
+DISCUSSION
+----------
+
+include::i18n.adoc[]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-sparse-checkout.adoc b/git-sparse-checkout.adoc
new file mode 100644
index 0000000..529a8ed
--- /dev/null
+++ b/git-sparse-checkout.adoc
@@ -0,0 +1,483 @@
+git-sparse-checkout(1)
+======================
+
+NAME
+----
+git-sparse-checkout - Reduce your working tree to a subset of tracked files
+
+
+SYNOPSIS
+--------
+[verse]
+'git sparse-checkout' (init | list | set | add | reapply | disable | check-rules) [<options>]
+
+
+DESCRIPTION
+-----------
+
+This command is used to create sparse checkouts, which change the
+working tree from having all tracked files present to only having a
+subset of those files. It can also switch which subset of files are
+present, or undo and go back to having all tracked files present in
+the working copy.
+
+The subset of files is chosen by providing a list of directories in
+cone mode (the default), or by providing a list of patterns in
+non-cone mode.
+
+When in a sparse-checkout, other Git commands behave a bit differently.
+For example, switching branches will not update paths outside the
+sparse-checkout directories/patterns, and `git commit -a` will not record
+paths outside the sparse-checkout directories/patterns as deleted.
+
+THIS COMMAND IS EXPERIMENTAL. ITS BEHAVIOR, AND THE BEHAVIOR OF OTHER
+COMMANDS IN THE PRESENCE OF SPARSE-CHECKOUTS, WILL LIKELY CHANGE IN
+THE FUTURE.
+
+
+COMMANDS
+--------
+'list'::
+ Describe the directories or patterns in the sparse-checkout file.
+
+'set'::
+ Enable the necessary sparse-checkout config settings
+ (`core.sparseCheckout`, `core.sparseCheckoutCone`, and
+ `index.sparse`) if they are not already set to the desired values,
+ populate the sparse-checkout file from the list of arguments
+ following the 'set' subcommand, and update the working directory to
+ match.
++
+To ensure that adjusting the sparse-checkout settings within a worktree
+does not alter the sparse-checkout settings in other worktrees, the 'set'
+subcommand will upgrade your repository config to use worktree-specific
+config if not already present. The sparsity defined by the arguments to
+the 'set' subcommand are stored in the worktree-specific sparse-checkout
+file. See linkgit:git-worktree[1] and the documentation of
+`extensions.worktreeConfig` in linkgit:git-config[1] for more details.
++
+When the `--stdin` option is provided, the directories or patterns are
+read from standard in as a newline-delimited list instead of from the
+arguments.
++
+By default, the input list is considered a list of directories, matching
+the output of `git ls-tree -d --name-only`. This includes interpreting
+pathnames that begin with a double quote (") as C-style quoted strings.
+Note that all files under the specified directories (at any depth) will
+be included in the sparse checkout, as well as files that are siblings
+of either the given directory or any of its ancestors (see 'CONE PATTERN
+SET' below for more details). In the past, this was not the default,
+and `--cone` needed to be specified or `core.sparseCheckoutCone` needed
+to be enabled.
++
+When `--no-cone` is passed, the input list is considered a list of
+patterns. This mode has a number of drawbacks, including not working
+with some options like `--sparse-index`. As explained in the
+"Non-cone Problems" section below, we do not recommend using it.
++
+Use the `--[no-]sparse-index` option to use a sparse index (the
+default is to not use it). A sparse index reduces the size of the
+index to be more closely aligned with your sparse-checkout
+definition. This can have significant performance advantages for
+commands such as `git status` or `git add`. This feature is still
+experimental. Some commands might be slower with a sparse index until
+they are properly integrated with the feature.
++
+**WARNING:** Using a sparse index requires modifying the index in a way
+that is not completely understood by external tools. If you have trouble
+with this compatibility, then run `git sparse-checkout init --no-sparse-index`
+to rewrite your index to not be sparse. Older versions of Git will not
+understand the sparse directory entries index extension and may fail to
+interact with your repository until it is disabled.
+
+'add'::
+ Update the sparse-checkout file to include additional directories
+ (in cone mode) or patterns (in non-cone mode). By default, these
+ directories or patterns are read from the command-line arguments,
+ but they can be read from stdin using the `--stdin` option.
+
+'reapply'::
+ Reapply the sparsity pattern rules to paths in the working tree.
+ Commands like merge or rebase can materialize paths to do their
+ work (e.g. in order to show you a conflict), and other
+ sparse-checkout commands might fail to sparsify an individual file
+ (e.g. because it has unstaged changes or conflicts). In such
+ cases, it can make sense to run `git sparse-checkout reapply` later
+ after cleaning up affected paths (e.g. resolving conflicts, undoing
+ or committing changes, etc.).
++
+The `reapply` command can also take `--[no-]cone` and `--[no-]sparse-index`
+flags, with the same meaning as the flags from the `set` command, in order
+to change which sparsity mode you are using without needing to also respecify
+all sparsity paths.
+
+'disable'::
+ Disable the `core.sparseCheckout` config setting, and restore the
+ working directory to include all files.
+
+'init'::
+ Deprecated command that behaves like `set` with no specified paths.
+ May be removed in the future.
++
+Historically, `set` did not handle all the necessary config settings,
+which meant that both `init` and `set` had to be called. Invoking
+both meant the `init` step would first remove nearly all tracked files
+(and in cone mode, ignored files too), then the `set` step would add
+many of the tracked files (but not ignored files) back. In addition
+to the lost files, the performance and UI of this combination was
+poor.
++
+Also, historically, `init` would not actually initialize the
+sparse-checkout file if it already existed. This meant it was
+possible to return to a sparse-checkout without remembering which
+paths to pass to a subsequent 'set' or 'add' command. However,
+`--cone` and `--sparse-index` options would not be remembered across
+the disable command, so the easy restore of calling a plain `init`
+decreased in utility.
+
+'check-rules'::
+ Check whether sparsity rules match one or more paths.
++
+By default `check-rules` reads a list of paths from stdin and outputs only
+the ones that match the current sparsity rules. The input is expected to consist
+of one path per line, matching the output of `git ls-tree --name-only` including
+that pathnames that begin with a double quote (") are interpreted as C-style
+quoted strings.
++
+When called with the `--rules-file <file>` flag the input files are matched
+against the sparse checkout rules found in `<file>` instead of the current ones.
+The rules in the files are expected to be in the same form as accepted by `git
+sparse-checkout set --stdin` (in particular, they must be newline-delimited).
++
+By default, the rules passed to the `--rules-file` option are interpreted as
+cone mode directories. To pass non-cone mode patterns with `--rules-file`,
+combine the option with the `--no-cone` option.
++
+When called with the `-z` flag, the format of the paths input on stdin as well
+as the output paths are \0 terminated and not quoted. Note that this does not
+apply to the format of the rules passed with the `--rules-file` option.
+
+
+EXAMPLES
+--------
+`git sparse-checkout set MY/DIR1 SUB/DIR2`::
+
+ Change to a sparse checkout with all files (at any depth) under
+ MY/DIR1/ and SUB/DIR2/ present in the working copy (plus all
+ files immediately under MY/ and SUB/ and the toplevel
+ directory). If already in a sparse checkout, change which files
+ are present in the working copy to this new selection. Note
+ that this command will also delete all ignored files in any
+ directory that no longer has either tracked or
+ non-ignored-untracked files present.
+
+`git sparse-checkout disable`::
+
+ Repopulate the working directory with all files, disabling sparse
+ checkouts.
+
+`git sparse-checkout add SOME/DIR/ECTORY`::
+
+ Add all files under SOME/DIR/ECTORY/ (at any depth) to the
+ sparse checkout, as well as all files immediately under
+ SOME/DIR/ and immediately under SOME/. Must already be in a
+ sparse checkout before using this command.
+
+`git sparse-checkout reapply`::
+
+ It is possible for commands to update the working tree in a
+ way that does not respect the selected sparsity directories.
+ This can come from tools external to Git writing files, or
+ even affect Git commands because of either special cases (such
+ as hitting conflicts when merging/rebasing), or because some
+ commands didn't fully support sparse checkouts (e.g. the old
+ `recursive` merge backend had only limited support). This
+ command reapplies the existing sparse directory specifications
+ to make the working directory match.
+
+INTERNALS -- SPARSE CHECKOUT
+----------------------------
+
+"Sparse checkout" allows populating the working directory sparsely. It
+uses the skip-worktree bit (see linkgit:git-update-index[1]) to tell Git
+whether a file in the working directory is worth looking at. If the
+skip-worktree bit is set, and the file is not present in the working tree,
+then its absence is ignored. Git will avoid populating the contents of
+those files, which makes a sparse checkout helpful when working in a
+repository with many files, but only a few are important to the current
+user.
+
+The `$GIT_DIR/info/sparse-checkout` file is used to define the
+skip-worktree reference bitmap. When Git updates the working
+directory, it updates the skip-worktree bits in the index based
+on this file. The files matching the patterns in the file will
+appear in the working directory, and the rest will not.
+
+INTERNALS -- NON-CONE PROBLEMS
+------------------------------
+
+The `$GIT_DIR/info/sparse-checkout` file populated by the `set` and
+`add` subcommands is defined to be a bunch of patterns (one per line)
+using the same syntax as `.gitignore` files. In cone mode, these
+patterns are restricted to matching directories (and users only ever
+need supply or see directory names), while in non-cone mode any
+gitignore-style pattern is permitted. Using the full gitignore-style
+patterns in non-cone mode has a number of shortcomings:
+
+ * Fundamentally, it makes various worktree-updating processes (pull,
+ merge, rebase, switch, reset, checkout, etc.) require O(N*M) pattern
+ matches, where N is the number of patterns and M is the number of
+ paths in the index. This scales poorly.
+
+ * Avoiding the scaling issue has to be done via limiting the number
+ of patterns via specifying leading directory name or glob.
+
+ * Passing globs on the command line is error-prone as users may
+ forget to quote the glob, causing the shell to expand it into all
+ matching files and pass them all individually along to
+ sparse-checkout set/add. While this could also be a problem with
+ e.g. "git grep -- *.c", mistakes with grep/log/status appear in
+ the immediate output. With sparse-checkout, the mistake gets
+ recorded at the time the sparse-checkout command is run and might
+ not be problematic until the user later switches branches or rebases
+ or merges, thus putting a delay between the user's error and when
+ they have a chance to catch/notice it.
+
+ * Related to the previous item, sparse-checkout has an 'add'
+ subcommand but no 'remove' subcommand. Even if a 'remove'
+ subcommand were added, undoing an accidental unquoted glob runs
+ the risk of "removing too much", as it may remove entries that had
+ been included before the accidental add.
+
+ * Non-cone mode uses gitignore-style patterns to select what to
+ *include* (with the exception of negated patterns), while
+ .gitignore files use gitignore-style patterns to select what to
+ *exclude* (with the exception of negated patterns). The
+ documentation on gitignore-style patterns usually does not talk in
+ terms of matching or non-matching, but on what the user wants to
+ "exclude". This can cause confusion for users trying to learn how
+ to specify sparse-checkout patterns to get their desired behavior.
+
+ * Every other git subcommand that wants to provide "special path
+ pattern matching" of some sort uses pathspecs, but non-cone mode
+ for sparse-checkout uses gitignore patterns, which feels
+ inconsistent.
+
+ * It has edge cases where the "right" behavior is unclear. Two examples:
+
+ First, two users are in a subdirectory, and the first runs
+ git sparse-checkout set '/toplevel-dir/*.c'
+ while the second runs
+ git sparse-checkout set relative-dir
+ Should those arguments be transliterated into
+ current/subdirectory/toplevel-dir/*.c
+ and
+ current/subdirectory/relative-dir
+ before inserting into the sparse-checkout file? The user who typed
+ the first command is probably aware that arguments to set/add are
+ supposed to be patterns in non-cone mode, and probably would not be
+ happy with such a transliteration. However, many gitignore-style
+ patterns are just paths, which might be what the user who typed the
+ second command was thinking, and they'd be upset if their argument
+ wasn't transliterated.
+
+ Second, what should bash-completion complete on for set/add commands
+ for non-cone users? If it suggests paths, is it exacerbating the
+ problem above? Also, if it suggests paths, what if the user has a
+ file or directory that begins with either a '!' or '#' or has a '*',
+ '\', '?', '[', or ']' in its name? And if it suggests paths, will
+ it complete "/pro" to "/proc" (in the root filesystem) rather than to
+ "/progress.txt" in the current directory? (Note that users are
+ likely to want to start paths with a leading '/' in non-cone mode,
+ for the same reason that .gitignore files often have one.)
+ Completing on files or directories might give nasty surprises in
+ all these cases.
+
+ * The excessive flexibility made other extensions essentially
+ impractical. `--sparse-index` is likely impossible in non-cone
+ mode; even if it is somehow feasible, it would have been far more
+ work to implement and may have been too slow in practice. Some
+ ideas for adding coupling between partial clones and sparse
+ checkouts are only practical with a more restricted set of paths
+ as well.
+
+For all these reasons, non-cone mode is deprecated. Please switch to
+using cone mode.
+
+
+INTERNALS -- CONE MODE HANDLING
+-------------------------------
+
+The "cone mode", which is the default, lets you specify only what
+directories to include. For any directory specified, all paths below
+that directory will be included, and any paths immediately under
+leading directories (including the toplevel directory) will also be
+included. Thus, if you specified the directory
+ Documentation/technical/
+then your sparse checkout would contain:
+
+ * all files in the toplevel-directory
+ * all files immediately under Documentation/
+ * all files at any depth under Documentation/technical/
+
+Also, in cone mode, even if no directories are specified, then the
+files in the toplevel directory will be included.
+
+When changing the sparse-checkout patterns in cone mode, Git will inspect each
+tracked directory that is not within the sparse-checkout cone to see if it
+contains any untracked files. If all of those files are ignored due to the
+`.gitignore` patterns, then the directory will be deleted. If any of the
+untracked files within that directory is not ignored, then no deletions will
+occur within that directory and a warning message will appear. If these files
+are important, then reset your sparse-checkout definition so they are included,
+use `git add` and `git commit` to store them, then remove any remaining files
+manually to ensure Git can behave optimally.
+
+See also the "Internals -- Cone Pattern Set" section to learn how the
+directories are transformed under the hood into a subset of the
+Full Pattern Set of sparse-checkout.
+
+
+INTERNALS -- FULL PATTERN SET
+-----------------------------
+
+The full pattern set allows for arbitrary pattern matches and complicated
+inclusion/exclusion rules. These can result in O(N*M) pattern matches when
+updating the index, where N is the number of patterns and M is the number
+of paths in the index. To combat this performance issue, a more restricted
+pattern set is allowed when `core.sparseCheckoutCone` is enabled.
+
+The sparse-checkout file uses the same syntax as `.gitignore` files;
+see linkgit:gitignore[5] for details. Here, though, the patterns are
+usually being used to select which files to include rather than which
+files to exclude. (However, it can get a bit confusing since
+gitignore-style patterns have negations defined by patterns which
+begin with a '!', so you can also select files to _not_ include.)
+
+For example, to select everything, and then to remove the file
+`unwanted` (so that every file will appear in your working tree except
+the file named `unwanted`):
+
+ git sparse-checkout set --no-cone '/*' '!unwanted'
+
+These patterns are just placed into the
+`$GIT_DIR/info/sparse-checkout` as-is, so the contents of that file
+at this point would be
+
+----------------
+/*
+!unwanted
+----------------
+
+See also the "Sparse Checkout" section of linkgit:git-read-tree[1] to
+learn more about the gitignore-style patterns used in sparse
+checkouts.
+
+
+INTERNALS -- CONE PATTERN SET
+-----------------------------
+
+In cone mode, only directories are accepted, but they are translated into
+the same gitignore-style patterns used in the full pattern set. We refer
+to the particular patterns used in those mode as being of one of two types:
+
+1. *Recursive:* All paths inside a directory are included.
+
+2. *Parent:* All files immediately inside a directory are included.
+
+Since cone mode always includes files at the toplevel, when running
+`git sparse-checkout set` with no directories specified, the toplevel
+directory is added as a parent pattern. At this point, the
+sparse-checkout file contains the following patterns:
+
+----------------
+/*
+!/*/
+----------------
+
+This says "include everything immediately under the toplevel
+directory, but nothing at any level below that."
+
+When in cone mode, the `git sparse-checkout set` subcommand takes a
+list of directories. The command `git sparse-checkout set A/B/C` sets
+the directory `A/B/C` as a recursive pattern, the directories `A` and
+`A/B` are added as parent patterns. The resulting sparse-checkout file
+is now
+
+----------------
+/*
+!/*/
+/A/
+!/A/*/
+/A/B/
+!/A/B/*/
+/A/B/C/
+----------------
+
+Here, order matters, so the negative patterns are overridden by the positive
+patterns that appear lower in the file.
+
+Unless `core.sparseCheckoutCone` is explicitly set to `false`, Git will
+parse the sparse-checkout file expecting patterns of these types. Git will
+warn if the patterns do not match. If the patterns do match the expected
+format, then Git will use faster hash-based algorithms to compute inclusion
+in the sparse-checkout. If they do not match, git will behave as though
+`core.sparseCheckoutCone` was false, regardless of its setting.
+
+In the cone mode case, despite the fact that full patterns are written
+to the $GIT_DIR/info/sparse-checkout file, the `git sparse-checkout
+list` subcommand will list the directories that define the recursive
+patterns. For the example sparse-checkout file above, the output is as
+follows:
+
+--------------------------
+$ git sparse-checkout list
+A/B/C
+--------------------------
+
+If `core.ignoreCase=true`, then the pattern-matching algorithm will use a
+case-insensitive check. This corrects for case mismatched filenames in the
+'git sparse-checkout set' command to reflect the expected cone in the working
+directory.
+
+
+INTERNALS -- SUBMODULES
+-----------------------
+
+If your repository contains one or more submodules, then submodules
+are populated based on interactions with the `git submodule` command.
+Specifically, `git submodule init -- <path>` will ensure the submodule
+at `<path>` is present, while `git submodule deinit [-f] -- <path>`
+will remove the files for the submodule at `<path>` (including any
+untracked files, uncommitted changes, and unpushed history). Similar
+to how sparse-checkout removes files from the working tree but still
+leaves entries in the index, deinitialized submodules are removed from
+the working directory but still have an entry in the index.
+
+Since submodules may have unpushed changes or untracked files,
+removing them could result in data loss. Thus, changing sparse
+inclusion/exclusion rules will not cause an already checked out
+submodule to be removed from the working copy. Said another way, just
+as `checkout` will not cause submodules to be automatically removed or
+initialized even when switching between branches that remove or add
+submodules, using `sparse-checkout` to reduce or expand the scope of
+"interesting" files will not cause submodules to be automatically
+deinitialized or initialized either.
+
+Further, the above facts mean that there are multiple reasons that
+"tracked" files might not be present in the working copy: sparsity
+pattern application from sparse-checkout, and submodule initialization
+state. Thus, commands like `git grep` that work on tracked files in
+the working copy may return results that are limited by either or both
+of these restrictions.
+
+
+SEE ALSO
+--------
+
+linkgit:git-read-tree[1]
+linkgit:gitignore[5]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-stage.adoc b/git-stage.adoc
new file mode 100644
index 0000000..2f6aaa7
--- /dev/null
+++ b/git-stage.adoc
@@ -0,0 +1,23 @@
+git-stage(1)
+============
+
+NAME
+----
+git-stage - Add file contents to the staging area
+
+
+SYNOPSIS
+--------
+[verse]
+'git stage' <arg>...
+
+
+DESCRIPTION
+-----------
+
+This is a synonym for linkgit:git-add[1]. Please refer to the
+documentation of that command.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-stash.adoc b/git-stash.adoc
new file mode 100644
index 0000000..1a5177f
--- /dev/null
+++ b/git-stash.adoc
@@ -0,0 +1,406 @@
+git-stash(1)
+============
+
+NAME
+----
+git-stash - Stash the changes in a dirty working directory away
+
+SYNOPSIS
+--------
+[verse]
+'git stash' list [<log-options>]
+'git stash' show [-u | --include-untracked | --only-untracked] [<diff-options>] [<stash>]
+'git stash' drop [-q | --quiet] [<stash>]
+'git stash' pop [--index] [-q | --quiet] [<stash>]
+'git stash' apply [--index] [-q | --quiet] [<stash>]
+'git stash' branch <branchname> [<stash>]
+'git stash' [push [-p | --patch] [-S | --staged] [-k | --[no-]keep-index] [-q | --quiet]
+ [-u | --include-untracked] [-a | --all] [(-m | --message) <message>]
+ [--pathspec-from-file=<file> [--pathspec-file-nul]]
+ [--] [<pathspec>...]]
+'git stash' save [-p | --patch] [-S | --staged] [-k | --[no-]keep-index] [-q | --quiet]
+ [-u | --include-untracked] [-a | --all] [<message>]
+'git stash' clear
+'git stash' create [<message>]
+'git stash' store [(-m | --message) <message>] [-q | --quiet] <commit>
+
+DESCRIPTION
+-----------
+
+Use `git stash` when you want to record the current state of the
+working directory and the index, but want to go back to a clean
+working directory. The command saves your local modifications away
+and reverts the working directory to match the `HEAD` commit.
+
+The modifications stashed away by this command can be listed with
+`git stash list`, inspected with `git stash show`, and restored
+(potentially on top of a different commit) with `git stash apply`.
+Calling `git stash` without any arguments is equivalent to `git stash push`.
+A stash is by default listed as "WIP on 'branchname' ...", but
+you can give a more descriptive message on the command line when
+you create one.
+
+The latest stash you created is stored in `refs/stash`; older
+stashes are found in the reflog of this reference and can be named using
+the usual reflog syntax (e.g. `stash@{0}` is the most recently
+created stash, `stash@{1}` is the one before it, `stash@{2.hours.ago}`
+is also possible). Stashes may also be referenced by specifying just the
+stash index (e.g. the integer `n` is equivalent to `stash@{n}`).
+
+COMMANDS
+--------
+
+push [-p|--patch] [-S|--staged] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [(-m|--message) <message>] [--pathspec-from-file=<file> [--pathspec-file-nul]] [--] [<pathspec>...]::
+
+ Save your local modifications to a new 'stash entry' and roll them
+ back to HEAD (in the working tree and in the index).
+ The <message> part is optional and gives
+ the description along with the stashed state.
++
+For quickly making a snapshot, you can omit "push". In this mode,
+non-option arguments are not allowed to prevent a misspelled
+subcommand from making an unwanted stash entry. The two exceptions to this
+are `stash -p` which acts as alias for `stash push -p` and pathspec elements,
+which are allowed after a double hyphen `--` for disambiguation.
+
+save [-p|--patch] [-S|--staged] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [<message>]::
+
+ This option is deprecated in favour of 'git stash push'. It
+ differs from "stash push" in that it cannot take pathspec.
+ Instead, all non-option arguments are concatenated to form the stash
+ message.
+
+list [<log-options>]::
+
+ List the stash entries that you currently have. Each 'stash entry' is
+ listed with its name (e.g. `stash@{0}` is the latest entry, `stash@{1}` is
+ the one before, etc.), the name of the branch that was current when the
+ entry was made, and a short description of the commit the entry was
+ based on.
++
+----------------------------------------------------------------
+stash@{0}: WIP on submit: 6ebd0e2... Update git-stash documentation
+stash@{1}: On master: 9cc0589... Add git-stash
+----------------------------------------------------------------
++
+The command takes options applicable to the 'git log'
+command to control what is shown and how. See linkgit:git-log[1].
+
+show [-u|--include-untracked|--only-untracked] [<diff-options>] [<stash>]::
+
+ Show the changes recorded in the stash entry as a diff between the
+ stashed contents and the commit back when the stash entry was first
+ created.
+ By default, the command shows the diffstat, but it will accept any
+ format known to 'git diff' (e.g., `git stash show -p stash@{1}`
+ to view the second most recent entry in patch form).
+ If no `<diff-option>` is provided, the default behavior will be given
+ by the `stash.showStat`, and `stash.showPatch` config variables. You
+ can also use `stash.showIncludeUntracked` to set whether
+ `--include-untracked` is enabled by default.
+
+pop [--index] [-q|--quiet] [<stash>]::
+
+ Remove a single stashed state from the stash list and apply it
+ on top of the current working tree state, i.e., do the inverse
+ operation of `git stash push`. The working directory must
+ match the index.
++
+Applying the state can fail with conflicts; in this case, it is not
+removed from the stash list. You need to resolve the conflicts by hand
+and call `git stash drop` manually afterwards.
+
+apply [--index] [-q|--quiet] [<stash>]::
+
+ Like `pop`, but do not remove the state from the stash list. Unlike `pop`,
+ `<stash>` may be any commit that looks like a commit created by
+ `stash push` or `stash create`.
+
+branch <branchname> [<stash>]::
+
+ Creates and checks out a new branch named `<branchname>` starting from
+ the commit at which the `<stash>` was originally created, applies the
+ changes recorded in `<stash>` to the new working tree and index.
+ If that succeeds, and `<stash>` is a reference of the form
+ `stash@{<revision>}`, it then drops the `<stash>`.
++
+This is useful if the branch on which you ran `git stash push` has
+changed enough that `git stash apply` fails due to conflicts. Since
+the stash entry is applied on top of the commit that was HEAD at the
+time `git stash` was run, it restores the originally stashed state
+with no conflicts.
+
+clear::
+ Remove all the stash entries. Note that those entries will then
+ be subject to pruning, and may be impossible to recover (see
+ 'Examples' below for a possible strategy).
+
+drop [-q|--quiet] [<stash>]::
+
+ Remove a single stash entry from the list of stash entries.
+
+create::
+
+ Create a stash entry (which is a regular commit object) and
+ return its object name, without storing it anywhere in the ref
+ namespace.
+ This is intended to be useful for scripts. It is probably not
+ the command you want to use; see "push" above.
+
+store::
+
+ Store a given stash created via 'git stash create' (which is a
+ dangling merge commit) in the stash ref, updating the stash
+ reflog. This is intended to be useful for scripts. It is
+ probably not the command you want to use; see "push" above.
+
+OPTIONS
+-------
+-a::
+--all::
+ This option is only valid for `push` and `save` commands.
++
+All ignored and untracked files are also stashed and then cleaned
+up with `git clean`.
+
+-u::
+--include-untracked::
+--no-include-untracked::
+ When used with the `push` and `save` commands,
+ all untracked files are also stashed and then cleaned up with
+ `git clean`.
++
+When used with the `show` command, show the untracked files in the stash
+entry as part of the diff.
+
+--only-untracked::
+ This option is only valid for the `show` command.
++
+Show only the untracked files in the stash entry as part of the diff.
+
+--index::
+ This option is only valid for `pop` and `apply` commands.
++
+Tries to reinstate not only the working tree's changes, but also
+the index's ones. However, this can fail, when you have conflicts
+(which are stored in the index, where you therefore can no longer
+apply the changes as they were originally).
+
+-k::
+--keep-index::
+--no-keep-index::
+ This option is only valid for `push` and `save` commands.
++
+All changes already added to the index are left intact.
+
+-p::
+--patch::
+ This option is only valid for `push` and `save` commands.
++
+Interactively select hunks from the diff between HEAD and the
+working tree to be stashed. The stash entry is constructed such
+that its index state is the same as the index state of your
+repository, and its worktree contains only the changes you selected
+interactively. The selected changes are then rolled back from your
+worktree. See the ``Interactive Mode'' section of linkgit:git-add[1]
+to learn how to operate the `--patch` mode.
++
+The `--patch` option implies `--keep-index`. You can use
+`--no-keep-index` to override this.
+
+-S::
+--staged::
+ This option is only valid for `push` and `save` commands.
++
+Stash only the changes that are currently staged. This is similar to
+basic `git commit` except the state is committed to the stash instead
+of current branch.
++
+The `--patch` option has priority over this one.
+
+--pathspec-from-file=<file>::
+ This option is only valid for `push` command.
++
+Pathspec is passed in `<file>` instead of commandline args. If
+`<file>` is exactly `-` then standard input is used. Pathspec
+elements are separated by LF or CR/LF. Pathspec elements can be
+quoted as explained for the configuration variable `core.quotePath`
+(see linkgit:git-config[1]). See also `--pathspec-file-nul` and
+global `--literal-pathspecs`.
+
+--pathspec-file-nul::
+ This option is only valid for `push` command.
++
+Only meaningful with `--pathspec-from-file`. Pathspec elements are
+separated with NUL character and all other characters are taken
+literally (including newlines and quotes).
+
+-q::
+--quiet::
+ This option is only valid for `apply`, `drop`, `pop`, `push`,
+ `save`, `store` commands.
++
+Quiet, suppress feedback messages.
+
+\--::
+ This option is only valid for `push` command.
++
+Separates pathspec from options for disambiguation purposes.
+
+<pathspec>...::
+ This option is only valid for `push` command.
++
+The new stash entry records the modified states only for the files
+that match the pathspec. The index entries and working tree files
+are then rolled back to the state in HEAD only for these files,
+too, leaving files that do not match the pathspec intact.
++
+For more details, see the 'pathspec' entry in linkgit:gitglossary[7].
+
+<stash>::
+ This option is only valid for `apply`, `branch`, `drop`, `pop`,
+ `show` commands.
++
+A reference of the form `stash@{<revision>}`. When no `<stash>` is
+given, the latest stash is assumed (that is, `stash@{0}`).
+
+DISCUSSION
+----------
+
+A stash entry is represented as a commit whose tree records the state
+of the working directory, and its first parent is the commit at `HEAD`
+when the entry was created. The tree of the second parent records the
+state of the index when the entry is made, and it is made a child of
+the `HEAD` commit. The ancestry graph looks like this:
+
+ .----W
+ / /
+ -----H----I
+
+where `H` is the `HEAD` commit, `I` is a commit that records the state
+of the index, and `W` is a commit that records the state of the working
+tree.
+
+
+EXAMPLES
+--------
+
+Pulling into a dirty tree::
+
+When you are in the middle of something, you learn that there are
+upstream changes that are possibly relevant to what you are
+doing. When your local changes do not conflict with the changes in
+the upstream, a simple `git pull` will let you move forward.
++
+However, there are cases in which your local changes do conflict with
+the upstream changes, and `git pull` refuses to overwrite your
+changes. In such a case, you can stash your changes away,
+perform a pull, and then unstash, like this:
++
+----------------------------------------------------------------
+$ git pull
+ ...
+file foobar not up to date, cannot merge.
+$ git stash
+$ git pull
+$ git stash pop
+----------------------------------------------------------------
+
+Interrupted workflow::
+
+When you are in the middle of something, your boss comes in and
+demands that you fix something immediately. Traditionally, you would
+make a commit to a temporary branch to store your changes away, and
+return to your original branch to make the emergency fix, like this:
++
+----------------------------------------------------------------
+# ... hack hack hack ...
+$ git switch -c my_wip
+$ git commit -a -m "WIP"
+$ git switch master
+$ edit emergency fix
+$ git commit -a -m "Fix in a hurry"
+$ git switch my_wip
+$ git reset --soft HEAD^
+# ... continue hacking ...
+----------------------------------------------------------------
++
+You can use 'git stash' to simplify the above, like this:
++
+----------------------------------------------------------------
+# ... hack hack hack ...
+$ git stash
+$ edit emergency fix
+$ git commit -a -m "Fix in a hurry"
+$ git stash pop
+# ... continue hacking ...
+----------------------------------------------------------------
+
+Testing partial commits::
+
+You can use `git stash push --keep-index` when you want to make two or
+more commits out of the changes in the work tree, and you want to test
+each change before committing:
++
+----------------------------------------------------------------
+# ... hack hack hack ...
+$ git add --patch foo # add just first part to the index
+$ git stash push --keep-index # save all other changes to the stash
+$ edit/build/test first part
+$ git commit -m 'First part' # commit fully tested change
+$ git stash pop # prepare to work on all other changes
+# ... repeat above five steps until one commit remains ...
+$ edit/build/test remaining parts
+$ git commit foo -m 'Remaining parts'
+----------------------------------------------------------------
+
+Saving unrelated changes for future use::
+
+When you are in the middle of massive changes and you find some
+unrelated issue that you don't want to forget to fix, you can do the
+change(s), stage them, and use `git stash push --staged` to stash them
+out for future use. This is similar to committing the staged changes,
+only the commit ends-up being in the stash and not on the current branch.
++
+----------------------------------------------------------------
+# ... hack hack hack ...
+$ git add --patch foo # add unrelated changes to the index
+$ git stash push --staged # save these changes to the stash
+# ... hack hack hack, finish current changes ...
+$ git commit -m 'Massive' # commit fully tested changes
+$ git switch fixup-branch # switch to another branch
+$ git stash pop # to finish work on the saved changes
+----------------------------------------------------------------
+
+Recovering stash entries that were cleared/dropped erroneously::
+
+If you mistakenly drop or clear stash entries, they cannot be recovered
+through the normal safety mechanisms. However, you can try the
+following incantation to get a list of stash entries that are still in
+your repository, but not reachable any more:
++
+----------------------------------------------------------------
+git fsck --unreachable |
+grep commit | cut -d\ -f3 |
+xargs git log --merges --no-walk --grep=WIP
+----------------------------------------------------------------
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/stash.adoc[]
+
+
+SEE ALSO
+--------
+linkgit:git-checkout[1],
+linkgit:git-commit[1],
+linkgit:git-reflog[1],
+linkgit:git-reset[1],
+linkgit:git-switch[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-status.adoc b/git-status.adoc
new file mode 100644
index 0000000..9a37688
--- /dev/null
+++ b/git-status.adoc
@@ -0,0 +1,529 @@
+git-status(1)
+=============
+
+NAME
+----
+git-status - Show the working tree status
+
+
+SYNOPSIS
+--------
+[verse]
+'git status' [<options>] [--] [<pathspec>...]
+
+DESCRIPTION
+-----------
+Displays paths that have differences between the index file and the
+current HEAD commit, paths that have differences between the working
+tree and the index file, and paths in the working tree that are not
+tracked by Git (and are not ignored by linkgit:gitignore[5]). The first
+are what you _would_ commit by running `git commit`; the second and
+third are what you _could_ commit by running 'git add' before running
+`git commit`.
+
+OPTIONS
+-------
+
+-s::
+--short::
+ Give the output in the short-format.
+
+-b::
+--branch::
+ Show the branch and tracking info even in short-format.
+
+--show-stash::
+ Show the number of entries currently stashed away.
+
+--porcelain[=<version>]::
+ Give the output in an easy-to-parse format for scripts.
+ This is similar to the short output, but will remain stable
+ across Git versions and regardless of user configuration. See
+ below for details.
++
+The version parameter is used to specify the format version.
+This is optional and defaults to the original version 'v1' format.
+
+--long::
+ Give the output in the long-format. This is the default.
+
+-v::
+--verbose::
+ In addition to the names of files that have been changed, also
+ show the textual changes that are staged to be committed
+ (i.e., like the output of `git diff --cached`). If `-v` is specified
+ twice, then also show the changes in the working tree that
+ have not yet been staged (i.e., like the output of `git diff`).
+
+-u[<mode>]::
+--untracked-files[=<mode>]::
+ Show untracked files.
++
+--
+The mode parameter is used to specify the handling of untracked files.
+It is optional: it defaults to 'all', and if specified, it must be
+stuck to the option (e.g. `-uno`, but not `-u no`).
+
+The possible options are:
+
+ - 'no' - Show no untracked files.
+ - 'normal' - Shows untracked files and directories.
+ - 'all' - Also shows individual files in untracked directories.
+
+When `-u` option is not used, untracked files and directories are
+shown (i.e. the same as specifying `normal`), to help you avoid
+forgetting to add newly created files. Because it takes extra work
+to find untracked files in the filesystem, this mode may take some
+time in a large working tree.
+Consider enabling untracked cache and split index if supported (see
+`git update-index --untracked-cache` and `git update-index
+--split-index`), Otherwise you can use `no` to have `git status`
+return more quickly without showing untracked files.
+All usual spellings for Boolean value `true` are taken as `normal`
+and `false` as `no`.
+
+The default can be changed using the status.showUntrackedFiles
+configuration variable documented in linkgit:git-config[1].
+--
+
+--ignore-submodules[=<when>]::
+ Ignore changes to submodules when looking for changes. <when> can be
+ either "none", "untracked", "dirty" or "all", which is the default.
+ Using "none" will consider the submodule modified when it either contains
+ untracked or modified files or its HEAD differs from the commit recorded
+ in the superproject and can be used to override any settings of the
+ 'ignore' option in linkgit:git-config[1] or linkgit:gitmodules[5]. When
+ "untracked" is used submodules are not considered dirty when they only
+ contain untracked content (but they are still scanned for modified
+ content). Using "dirty" ignores all changes to the work tree of submodules,
+ only changes to the commits stored in the superproject are shown (this was
+ the behavior before 1.7.0). Using "all" hides all changes to submodules
+ (and suppresses the output of submodule summaries when the config option
+ `status.submoduleSummary` is set).
+
+--ignored[=<mode>]::
+ Show ignored files as well.
++
+--
+The mode parameter is used to specify the handling of ignored files.
+It is optional: it defaults to 'traditional'.
+
+The possible options are:
+
+ - 'traditional' - Shows ignored files and directories, unless
+ --untracked-files=all is specified, in which case
+ individual files in ignored directories are
+ displayed.
+ - 'no' - Show no ignored files.
+ - 'matching' - Shows ignored files and directories matching an
+ ignore pattern.
+
+When 'matching' mode is specified, paths that explicitly match an
+ignored pattern are shown. If a directory matches an ignore pattern,
+then it is shown, but not paths contained in the ignored directory. If
+a directory does not match an ignore pattern, but all contents are
+ignored, then the directory is not shown, but all contents are shown.
+--
+
+-z::
+ Terminate entries with NUL, instead of LF. This implies
+ the `--porcelain=v1` output format if no other format is given.
+
+--column[=<options>]::
+--no-column::
+ Display untracked files in columns. See configuration variable
+ `column.status` for option syntax. `--column` and `--no-column`
+ without options are equivalent to 'always' and 'never'
+ respectively.
+
+--ahead-behind::
+--no-ahead-behind::
+ Display or do not display detailed ahead/behind counts for the
+ branch relative to its upstream branch. Defaults to true.
+
+--renames::
+--no-renames::
+ Turn on/off rename detection regardless of user configuration.
+ See also linkgit:git-diff[1] `--no-renames`.
+
+--find-renames[=<n>]::
+ Turn on rename detection, optionally setting the similarity
+ threshold.
+ See also linkgit:git-diff[1] `--find-renames`.
+
+<pathspec>...::
+ See the 'pathspec' entry in linkgit:gitglossary[7].
+
+OUTPUT
+------
+The output from this command is designed to be used as a commit
+template comment.
+The default, long format, is designed to be human readable,
+verbose and descriptive. Its contents and format are subject to change
+at any time.
+
+The paths mentioned in the output, unlike many other Git commands, are
+made relative to the current directory if you are working in a
+subdirectory (this is on purpose, to help cutting and pasting). See
+the status.relativePaths config option below.
+
+Short Format
+~~~~~~~~~~~~
+
+In the short-format, the status of each path is shown as one of these
+forms
+
+ XY PATH
+ XY ORIG_PATH -> PATH
+
+where `ORIG_PATH` is where the renamed/copied contents came
+from. `ORIG_PATH` is only shown when the entry is renamed or
+copied. The `XY` is a two-letter status code.
+
+The fields (including the `->`) are separated from each other by a
+single space. If a filename contains whitespace or other nonprintable
+characters, that field will be quoted in the manner of a C string
+literal: surrounded by ASCII double quote (34) characters, and with
+interior special characters backslash-escaped.
+
+There are three different types of states that are shown using this format, and
+each one uses the `XY` syntax differently:
+
+* When a merge is occurring and the merge was successful, or outside of a merge
+ situation, `X` shows the status of the index and `Y` shows the status of the
+ working tree.
+* When a merge conflict has occurred and has not yet been resolved, `X` and `Y`
+ show the state introduced by each head of the merge, relative to the common
+ ancestor. These paths are said to be _unmerged_.
+* When a path is untracked, `X` and `Y` are always the same, since they are
+ unknown to the index. `??` is used for untracked paths. Ignored files are
+ not listed unless `--ignored` is used; if it is, ignored files are indicated
+ by `!!`.
+
+Note that the term _merge_ here also includes rebases using the default
+`--merge` strategy, cherry-picks, and anything else using the merge machinery.
+
+In the following table, these three classes are shown in separate sections, and
+these characters are used for `X` and `Y` fields for the first two sections that
+show tracked paths:
+
+* ' ' = unmodified
+* 'M' = modified
+* 'T' = file type changed (regular file, symbolic link or submodule)
+* 'A' = added
+* 'D' = deleted
+* 'R' = renamed
+* 'C' = copied (if config option status.renames is set to "copies")
+* 'U' = updated but unmerged
+
+....
+X Y Meaning
+-------------------------------------------------
+ [AMD] not updated
+M [ MTD] updated in index
+T [ MTD] type changed in index
+A [ MTD] added to index
+D deleted from index
+R [ MTD] renamed in index
+C [ MTD] copied in index
+[MTARC] index and work tree matches
+[ MTARC] M work tree changed since index
+[ MTARC] T type changed in work tree since index
+[ MTARC] D deleted in work tree
+ R renamed in work tree
+ C copied in work tree
+-------------------------------------------------
+D D unmerged, both deleted
+A U unmerged, added by us
+U D unmerged, deleted by them
+U A unmerged, added by them
+D U unmerged, deleted by us
+A A unmerged, both added
+U U unmerged, both modified
+-------------------------------------------------
+? ? untracked
+! ! ignored
+-------------------------------------------------
+....
+
+Submodules have more state and instead report
+
+* 'M' = the submodule has a different HEAD than recorded in the index
+* 'm' = the submodule has modified content
+* '?' = the submodule has untracked files
+
+This is since modified content or untracked files in a submodule cannot be added
+via `git add` in the superproject to prepare a commit.
+
+'m' and '?' are applied recursively. For example if a nested submodule
+in a submodule contains an untracked file, this is reported as '?' as well.
+
+If -b is used the short-format status is preceded by a line
+
+ ## branchname tracking info
+
+Porcelain Format Version 1
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Version 1 porcelain format is similar to the short format, but is guaranteed
+not to change in a backwards-incompatible way between Git versions or
+based on user configuration. This makes it ideal for parsing by scripts.
+The description of the short format above also describes the porcelain
+format, with a few exceptions:
+
+1. The user's color.status configuration is not respected; color will
+ always be off.
+
+2. The user's status.relativePaths configuration is not respected; paths
+ shown will always be relative to the repository root.
+
+There is also an alternate -z format recommended for machine parsing. In
+that format, the status field is the same, but some other things
+change. First, the '\->' is omitted from rename entries and the field
+order is reversed (e.g 'from \-> to' becomes 'to from'). Second, a NUL
+(ASCII 0) follows each filename, replacing space as a field separator
+and the terminating newline (but a space still separates the status
+field from the first filename). Third, filenames containing special
+characters are not specially formatted; no quoting or
+backslash-escaping is performed.
+
+Any submodule changes are reported as modified `M` instead of `m` or single `?`.
+
+Porcelain Format Version 2
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Version 2 format adds more detailed information about the state of
+the worktree and changed items. Version 2 also defines an extensible
+set of easy to parse optional headers.
+
+Header lines start with "#" and are added in response to specific
+command line arguments. Parsers should ignore headers they
+don't recognize.
+
+Branch Headers
+^^^^^^^^^^^^^^
+
+If `--branch` is given, a series of header lines are printed with
+information about the current branch.
+
+....
+Line Notes
+------------------------------------------------------------
+# branch.oid <commit> | (initial) Current commit.
+# branch.head <branch> | (detached) Current branch.
+# branch.upstream <upstream-branch> If upstream is set.
+# branch.ab +<ahead> -<behind> If upstream is set and
+ the commit is present.
+------------------------------------------------------------
+....
+
+Stash Information
+^^^^^^^^^^^^^^^^^
+
+If `--show-stash` is given, one line is printed showing the number of stash
+entries if non-zero:
+
+ # stash <N>
+
+Changed Tracked Entries
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Following the headers, a series of lines are printed for tracked
+entries. One of three different line formats may be used to describe
+an entry depending on the type of change. Tracked entries are printed
+in an undefined order; parsers should allow for a mixture of the 3
+line types in any order.
+
+Ordinary changed entries have the following format:
+
+ 1 <XY> <sub> <mH> <mI> <mW> <hH> <hI> <path>
+
+Renamed or copied entries have the following format:
+
+ 2 <XY> <sub> <mH> <mI> <mW> <hH> <hI> <X><score> <path><sep><origPath>
+
+....
+Field Meaning
+--------------------------------------------------------
+<XY> A 2 character field containing the staged and
+ unstaged XY values described in the short format,
+ with unchanged indicated by a "." rather than
+ a space.
+<sub> A 4 character field describing the submodule state.
+ "N..." when the entry is not a submodule.
+ "S<c><m><u>" when the entry is a submodule.
+ <c> is "C" if the commit changed; otherwise ".".
+ <m> is "M" if it has tracked changes; otherwise ".".
+ <u> is "U" if there are untracked changes; otherwise ".".
+<mH> The octal file mode in HEAD.
+<mI> The octal file mode in the index.
+<mW> The octal file mode in the worktree.
+<hH> The object name in HEAD.
+<hI> The object name in the index.
+<X><score> The rename or copy score (denoting the percentage
+ of similarity between the source and target of the
+ move or copy). For example "R100" or "C75".
+<path> The pathname. In a renamed/copied entry, this
+ is the target path.
+<sep> When the `-z` option is used, the 2 pathnames are separated
+ with a NUL (ASCII 0x00) byte; otherwise, a tab (ASCII 0x09)
+ byte separates them.
+<origPath> The pathname in the commit at HEAD or in the index.
+ This is only present in a renamed/copied entry, and
+ tells where the renamed/copied contents came from.
+--------------------------------------------------------
+....
+
+Unmerged entries have the following format; the first character is
+a "u" to distinguish from ordinary changed entries.
+
+ u <XY> <sub> <m1> <m2> <m3> <mW> <h1> <h2> <h3> <path>
+
+....
+Field Meaning
+--------------------------------------------------------
+<XY> A 2 character field describing the conflict type
+ as described in the short format.
+<sub> A 4 character field describing the submodule state
+ as described above.
+<m1> The octal file mode in stage 1.
+<m2> The octal file mode in stage 2.
+<m3> The octal file mode in stage 3.
+<mW> The octal file mode in the worktree.
+<h1> The object name in stage 1.
+<h2> The object name in stage 2.
+<h3> The object name in stage 3.
+<path> The pathname.
+--------------------------------------------------------
+....
+
+Other Items
+^^^^^^^^^^^
+
+Following the tracked entries (and if requested), a series of
+lines will be printed for untracked and then ignored items
+found in the worktree.
+
+Untracked items have the following format:
+
+ ? <path>
+
+Ignored items have the following format:
+
+ ! <path>
+
+Pathname Format Notes and -z
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When the `-z` option is given, pathnames are printed as is and
+without any quoting and lines are terminated with a NUL (ASCII 0x00)
+byte.
+
+Without the `-z` option, pathnames with "unusual" characters are
+quoted as explained for the configuration variable `core.quotePath`
+(see linkgit:git-config[1]).
+
+
+CONFIGURATION
+-------------
+
+The command honors `color.status` (or `status.color` -- they
+mean the same thing and the latter is kept for backward
+compatibility) and `color.status.<slot>` configuration variables
+to colorize its output.
+
+If the config variable `status.relativePaths` is set to false, then all
+paths shown are relative to the repository root, not to the current
+directory.
+
+If `status.submoduleSummary` is set to a non zero number or true (identical
+to -1 or an unlimited number), the submodule summary will be enabled for
+the long format and a summary of commits for modified submodules will be
+shown (see --summary-limit option of linkgit:git-submodule[1]). Please note
+that the summary output from the status command will be suppressed for all
+submodules when `diff.ignoreSubmodules` is set to 'all' or only for those
+submodules where `submodule.<name>.ignore=all`. To also view the summary for
+ignored submodules you can either use the --ignore-submodules=dirty command
+line option or the 'git submodule summary' command, which shows a similar
+output but does not honor these settings.
+
+BACKGROUND REFRESH
+------------------
+
+By default, `git status` will automatically refresh the index, updating
+the cached stat information from the working tree and writing out the
+result. Writing out the updated index is an optimization that isn't
+strictly necessary (`status` computes the values for itself, but writing
+them out is just to save subsequent programs from repeating our
+computation). When `status` is run in the background, the lock held
+during the write may conflict with other simultaneous processes, causing
+them to fail. Scripts running `status` in the background should consider
+using `git --no-optional-locks status` (see linkgit:git[1] for details).
+
+UNTRACKED FILES AND PERFORMANCE
+-------------------------------
+
+`git status` can be very slow in large worktrees if/when it
+needs to search for untracked files and directories. There are
+many configuration options available to speed this up by either
+avoiding the work or making use of cached results from previous
+Git commands. There is no single optimum set of settings right
+for everyone. We'll list a summary of the relevant options to help
+you, but before going into the list, you may want to run `git status`
+again, because your configuration may already be caching `git status`
+results, so it could be faster on subsequent runs.
+
+* The `--untracked-files=no` flag or the
+ `status.showUntrackedFiles=no` config (see above for both):
+ indicate that `git status` should not report untracked
+ files. This is the fastest option. `git status` will not list
+ the untracked files, so you need to be careful to remember if
+ you create any new files and manually `git add` them.
+
+* `advice.statusUoption=false` (see linkgit:git-config[1]):
+ setting this variable to `false` disables the warning message
+ given when enumerating untracked files takes more than 2
+ seconds. In a large project, it may take longer and the user
+ may have already accepted the trade off (e.g. using "-uno" may
+ not be an acceptable option for the user), in which case, there
+ is no point issuing the warning message, and in such a case,
+ disabling the warning may be the best.
+
+* `core.untrackedCache=true` (see linkgit:git-update-index[1]):
+ enable the untracked cache feature and only search directories
+ that have been modified since the previous `git status` command.
+ Git remembers the set of untracked files within each directory
+ and assumes that if a directory has not been modified, then
+ the set of untracked files within has not changed. This is much
+ faster than enumerating the contents of every directory, but still
+ not without cost, because Git still has to search for the set of
+ modified directories. The untracked cache is stored in the
+ `.git/index` file. The reduced cost of searching for untracked
+ files is offset slightly by the increased size of the index and
+ the cost of keeping it up-to-date. That reduced search time is
+ usually worth the additional size.
+
+* `core.untrackedCache=true` and `core.fsmonitor=true` or
+ `core.fsmonitor=<hook-command-pathname>` (see
+ linkgit:git-update-index[1]): enable both the untracked cache
+ and FSMonitor features and only search directories that have
+ been modified since the previous `git status` command. This
+ is faster than using just the untracked cache alone because
+ Git can also avoid searching for modified directories. Git
+ only has to enumerate the exact set of directories that have
+ changed recently. While the FSMonitor feature can be enabled
+ without the untracked cache, the benefits are greatly reduced
+ in that case.
+
+Note that after you turn on the untracked cache and/or FSMonitor
+features it may take a few `git status` commands for the various
+caches to warm up before you see improved command times. This is
+normal.
+
+SEE ALSO
+--------
+linkgit:gitignore[5]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-stripspace.adoc b/git-stripspace.adoc
new file mode 100644
index 0000000..a293327
--- /dev/null
+++ b/git-stripspace.adoc
@@ -0,0 +1,94 @@
+git-stripspace(1)
+=================
+
+NAME
+----
+git-stripspace - Remove unnecessary whitespace
+
+
+SYNOPSIS
+--------
+[verse]
+'git stripspace' [-s | --strip-comments]
+'git stripspace' [-c | --comment-lines]
+
+DESCRIPTION
+-----------
+
+Read text, such as commit messages, notes, tags and branch
+descriptions, from the standard input and clean it in the manner
+used by Git.
+
+With no arguments, this will:
+
+- remove trailing whitespace from all lines
+- collapse multiple consecutive empty lines into one empty line
+- remove empty lines from the beginning and end of the input
+- add a missing '\n' to the last line if necessary.
+
+In the case where the input consists entirely of whitespace characters, no
+output will be produced.
+
+*NOTE*: This is intended for cleaning metadata. Prefer the `--whitespace=fix`
+mode of linkgit:git-apply[1] for correcting whitespace of patches or files in
+the repository.
+
+OPTIONS
+-------
+-s::
+--strip-comments::
+ Skip and remove all lines starting with a comment character (default '#').
+
+-c::
+--comment-lines::
+ Prepend the comment character and a blank space to each line. Lines will automatically
+ be terminated with a newline. On empty lines, only the comment character
+ will be prepended.
+
+EXAMPLES
+--------
+
+Given the following noisy input with '$' indicating the end of a line:
+
+---------
+|A brief introduction $
+| $
+|$
+|A new paragraph$
+|# with a commented-out line $
+|explaining lots of stuff.$
+|$
+|# An old paragraph, also commented-out. $
+| $
+|The end.$
+| $
+---------
+
+Use 'git stripspace' with no arguments to obtain:
+
+---------
+|A brief introduction$
+|$
+|A new paragraph$
+|# with a commented-out line$
+|explaining lots of stuff.$
+|$
+|# An old paragraph, also commented-out.$
+|$
+|The end.$
+---------
+
+Use 'git stripspace --strip-comments' to obtain:
+
+---------
+|A brief introduction$
+|$
+|A new paragraph$
+|explaining lots of stuff.$
+|$
+|The end.$
+---------
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-submodule.adoc b/git-submodule.adoc
new file mode 100644
index 0000000..87d8e0f
--- /dev/null
+++ b/git-submodule.adoc
@@ -0,0 +1,473 @@
+git-submodule(1)
+================
+
+NAME
+----
+git-submodule - Initialize, update or inspect submodules
+
+
+SYNOPSIS
+--------
+[verse]
+'git submodule' [--quiet] [--cached]
+'git submodule' [--quiet] add [<options>] [--] <repository> [<path>]
+'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
+'git submodule' [--quiet] init [--] [<path>...]
+'git submodule' [--quiet] deinit [-f|--force] (--all|[--] <path>...)
+'git submodule' [--quiet] update [<options>] [--] [<path>...]
+'git submodule' [--quiet] set-branch [<options>] [--] <path>
+'git submodule' [--quiet] set-url [--] <path> <newurl>
+'git submodule' [--quiet] summary [<options>] [--] [<path>...]
+'git submodule' [--quiet] foreach [--recursive] <command>
+'git submodule' [--quiet] sync [--recursive] [--] [<path>...]
+'git submodule' [--quiet] absorbgitdirs [--] [<path>...]
+
+
+DESCRIPTION
+-----------
+Inspects, updates and manages submodules.
+
+For more information about submodules, see linkgit:gitsubmodules[7].
+
+COMMANDS
+--------
+With no arguments, shows the status of existing submodules. Several
+subcommands are available to perform operations on the submodules.
+
+add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--ref-format <format>] [--depth <depth>] [--] <repository> [<path>]::
+ Add the given repository as a submodule at the given path
+ to the changeset to be committed next to the current
+ project: the current project is termed the "superproject".
++
+<repository> is the URL of the new submodule's origin repository.
+This may be either an absolute URL, or (if it begins with ./
+or ../), the location relative to the superproject's default remote
+repository (Please note that to specify a repository 'foo.git'
+which is located right next to a superproject 'bar.git', you'll
+have to use `../foo.git` instead of `./foo.git` - as one might expect
+when following the rules for relative URLs - because the evaluation
+of relative URLs in Git is identical to that of relative directories).
++
+The default remote is the remote of the remote-tracking branch
+of the current branch. If no such remote-tracking branch exists or
+the HEAD is detached, "origin" is assumed to be the default remote.
+If the superproject doesn't have a default remote configured
+the superproject is its own authoritative upstream and the current
+working directory is used instead.
++
+The optional argument <path> is the relative location for the cloned
+submodule to exist in the superproject. If <path> is not given, the
+canonical part of the source repository is used ("repo" for
+"/path/to/repo.git" and "foo" for "host.xz:foo/.git"). If <path>
+exists and is already a valid Git repository, then it is staged
+for commit without cloning. The <path> is also used as the submodule's
+logical name in its configuration entries unless `--name` is used
+to specify a logical name.
++
+The given URL is recorded into `.gitmodules` for use by subsequent users
+cloning the superproject. If the URL is given relative to the
+superproject's repository, the presumption is the superproject and
+submodule repositories will be kept together in the same relative
+location, and only the superproject's URL needs to be provided.
+git-submodule will correctly locate the submodule using the relative
+URL in `.gitmodules`.
++
+If `--ref-format <format>` is specified, the ref storage format of newly
+cloned submodules will be set accordingly.
+
+status [--cached] [--recursive] [--] [<path>...]::
+ Show the status of the submodules. This will print the SHA-1 of the
+ currently checked out commit for each submodule, along with the
+ submodule path and the output of 'git describe' for the
+ SHA-1. Each SHA-1 will possibly be prefixed with `-` if the submodule is
+ not initialized, `+` if the currently checked out submodule commit
+ does not match the SHA-1 found in the index of the containing
+ repository and `U` if the submodule has merge conflicts.
++
+If `--cached` is specified, this command will instead print the SHA-1
+recorded in the superproject for each submodule.
++
+If `--recursive` is specified, this command will recurse into nested
+submodules, and show their status as well.
++
+If you are only interested in changes of the currently initialized
+submodules with respect to the commit recorded in the index or the HEAD,
+linkgit:git-status[1] and linkgit:git-diff[1] will provide that information
+too (and can also report changes to a submodule's work tree).
+
+init [--] [<path>...]::
+ Initialize the submodules recorded in the index (which were
+ added and committed elsewhere) by setting `submodule.$name.url`
+ in `.git/config`, using the same setting from `.gitmodules` as
+ a template. If the URL is relative, it will be resolved using
+ the default remote. If there is no default remote, the current
+ repository will be assumed to be upstream.
++
+Optional <path> arguments limit which submodules will be initialized.
+If no path is specified and submodule.active has been configured, submodules
+configured to be active will be initialized, otherwise all submodules are
+initialized.
++
+It will also copy the value of `submodule.$name.update`, if present in
+the `.gitmodules` file, to `.git/config`, but (1) this command does not
+alter existing information in `.git/config`, and (2) `submodule.$name.update`
+that is set to a custom command is *not* copied for security reasons.
++
+You can then customize the submodule clone URLs in `.git/config`
+for your local setup and proceed to `git submodule update`;
+you can also just use `git submodule update --init` without
+the explicit 'init' step if you do not intend to customize
+any submodule locations.
++
+See the add subcommand for the definition of default remote.
+
+deinit [-f|--force] (--all|[--] <path>...)::
+ Unregister the given submodules, i.e. remove the whole
+ `submodule.$name` section from .git/config together with their work
+ tree. Further calls to `git submodule update`, `git submodule foreach`
+ and `git submodule sync` will skip any unregistered submodules until
+ they are initialized again, so use this command if you don't want to
+ have a local checkout of the submodule in your working tree anymore.
++
+When the command is run without pathspec, it errors out,
+instead of deinit-ing everything, to prevent mistakes.
++
+If `--force` is specified, the submodule's working tree will
+be removed even if it contains local modifications.
++
+If you really want to remove a submodule from the repository and commit
+that use linkgit:git-rm[1] instead. See linkgit:gitsubmodules[7] for removal
+options.
+
+update [--init] [--remote] [-N|--no-fetch] [--[no-]recommend-shallow] [-f|--force] [--checkout|--rebase|--merge] [--reference <repository>] [--ref-format <format>] [--depth <depth>] [--recursive] [--jobs <n>] [--[no-]single-branch] [--filter <filter-spec>] [--] [<path>...]::
++
+--
+Update the registered submodules to match what the superproject
+expects by cloning missing submodules, fetching missing commits
+in submodules and updating the working tree of
+the submodules. The "updating" can be done in several ways depending
+on command line options and the value of `submodule.<name>.update`
+configuration variable. The command line option takes precedence over
+the configuration variable. If neither is given, a 'checkout' is performed.
+(note: what is in `.gitmodules` file is irrelevant at this point;
+see `git submodule init` above for how `.gitmodules` is used).
+The 'update' procedures supported both from the command line as well as
+through the `submodule.<name>.update` configuration are:
+
+ checkout;; the commit recorded in the superproject will be
+ checked out in the submodule on a detached HEAD.
++
+If `--force` is specified, the submodule will be checked out (using
+`git checkout --force`), even if the commit specified
+in the index of the containing repository already matches the commit
+checked out in the submodule.
+
+ rebase;; the current branch of the submodule will be rebased
+ onto the commit recorded in the superproject.
+
+ merge;; the commit recorded in the superproject will be merged
+ into the current branch in the submodule.
+
+The following update procedures have additional limitations:
+
+ custom command;; mechanism for running arbitrary commands with the
+ commit ID as an argument. Specifically, if the
+ `submodule.<name>.update` configuration variable is set to
+ `!custom command`, the object name of the commit recorded in the
+ superproject for the submodule is appended to the `custom command`
+ string and executed. Note that this mechanism is not supported in
+ the `.gitmodules` file or on the command line.
+
+ none;; the submodule is not updated. This update procedure is not
+ allowed on the command line.
+
+If the submodule is not yet initialized, and you just want to use the
+setting as stored in `.gitmodules`, you can automatically initialize the
+submodule with the `--init` option.
+
+If `--recursive` is specified, this command will recurse into the
+registered submodules, and update any nested submodules within.
+
+If `--ref-format <format>` is specified, the ref storage format of newly
+cloned submodules will be set accordingly.
+
+If `--filter <filter-spec>` is specified, the given partial clone filter will be
+applied to the submodule. See linkgit:git-rev-list[1] for details on filter
+specifications.
+--
+set-branch (-b|--branch) <branch> [--] <path>::
+set-branch (-d|--default) [--] <path>::
+ Sets the default remote tracking branch for the submodule. The
+ `--branch` option allows the remote branch to be specified. The
+ `--default` option removes the submodule.<name>.branch configuration
+ key, which causes the tracking branch to default to the remote 'HEAD'.
+
+set-url [--] <path> <newurl>::
+ Sets the URL of the specified submodule to <newurl>. Then, it will
+ automatically synchronize the submodule's new remote URL
+ configuration.
+
+summary [--cached|--files] [(-n|--summary-limit) <n>] [commit] [--] [<path>...]::
+ Show commit summary between the given commit (defaults to HEAD) and
+ working tree/index. For a submodule in question, a series of commits
+ in the submodule between the given super project commit and the
+ index or working tree (switched by `--cached`) are shown. If the option
+ `--files` is given, show the series of commits in the submodule between
+ the index of the super project and the working tree of the submodule
+ (this option doesn't allow to use the `--cached` option or to provide an
+ explicit commit).
++
+Using the `--submodule=log` option with linkgit:git-diff[1] will provide that
+information too.
+
+foreach [--recursive] <command>::
+ Evaluates an arbitrary shell command in each checked out submodule.
+ The command has access to the variables $name, $sm_path, $displaypath,
+ $sha1 and $toplevel:
+ $name is the name of the relevant submodule section in `.gitmodules`,
+ $sm_path is the path of the submodule as recorded in the immediate
+ superproject, $displaypath contains the relative path from the
+ current working directory to the submodules root directory,
+ $sha1 is the commit as recorded in the immediate
+ superproject, and $toplevel is the absolute path to the top-level
+ of the immediate superproject.
+ Note that to avoid conflicts with '$PATH' on Windows, the '$path'
+ variable is now a deprecated synonym of '$sm_path' variable.
+ Any submodules defined in the superproject but not checked out are
+ ignored by this command. Unless given `--quiet`, foreach prints the name
+ of each submodule before evaluating the command.
+ If `--recursive` is given, submodules are traversed recursively (i.e.
+ the given shell command is evaluated in nested submodules as well).
+ A non-zero return from the command in any submodule causes
+ the processing to terminate. This can be overridden by adding '|| :'
+ to the end of the command.
++
+As an example, the command below will show the path and currently
+checked out commit for each submodule:
++
+--------------
+git submodule foreach 'echo $sm_path `git rev-parse HEAD`'
+--------------
+
+sync [--recursive] [--] [<path>...]::
+ Synchronizes submodules' remote URL configuration setting
+ to the value specified in `.gitmodules`. It will only affect those
+ submodules which already have a URL entry in .git/config (that is the
+ case when they are initialized or freshly added). This is useful when
+ submodule URLs change upstream and you need to update your local
+ repositories accordingly.
++
+`git submodule sync` synchronizes all submodules while
+`git submodule sync -- A` synchronizes submodule "A" only.
++
+If `--recursive` is specified, this command will recurse into the
+registered submodules, and sync any nested submodules within.
+
+absorbgitdirs::
+ If a git directory of a submodule is inside the submodule,
+ move the git directory of the submodule into its superproject's
+ `$GIT_DIR/modules` path and then connect the git directory and
+ its working directory by setting the `core.worktree` and adding
+ a .git file pointing to the git directory embedded in the
+ superprojects git directory.
++
+A repository that was cloned independently and later added as a submodule or
+old setups have the submodules git directory inside the submodule instead of
+embedded into the superprojects git directory.
++
+This command is recursive by default.
+
+OPTIONS
+-------
+-q::
+--quiet::
+ Only print error messages.
+
+--progress::
+ This option is only valid for add and update commands.
+ Progress status is reported on the standard error stream
+ by default when it is attached to a terminal, unless -q
+ is specified. This flag forces progress status even if the
+ standard error stream is not directed to a terminal.
+
+--all::
+ This option is only valid for the deinit command. Unregister all
+ submodules in the working tree.
+
+-b <branch>::
+--branch <branch>::
+ Branch of repository to add as submodule.
+ The name of the branch is recorded as `submodule.<name>.branch` in
+ `.gitmodules` for `update --remote`. A special value of `.` is used to
+ indicate that the name of the branch in the submodule should be the
+ same name as the current branch in the current repository. If the
+ option is not specified, it defaults to the remote 'HEAD'.
+
+-f::
+--force::
+ This option is only valid for add, deinit and update commands.
+ When running add, allow adding an otherwise ignored submodule path.
+ When running deinit the submodule working trees will be removed even
+ if they contain local changes.
+ When running update (only effective with the checkout procedure),
+ throw away local changes in submodules when switching to a
+ different commit; and always run a checkout operation in the
+ submodule, even if the commit listed in the index of the
+ containing repository matches the commit checked out in the
+ submodule.
+
+--cached::
+ This option is only valid for status and summary commands. These
+ commands typically use the commit found in the submodule HEAD, but
+ with this option, the commit stored in the index is used instead.
+
+--files::
+ This option is only valid for the summary command. This command
+ compares the commit in the index with that in the submodule HEAD
+ when this option is used.
+
+-n::
+--summary-limit::
+ This option is only valid for the summary command.
+ Limit the summary size (number of commits shown in total).
+ Giving 0 will disable the summary; a negative number means unlimited
+ (the default). This limit only applies to modified submodules. The
+ size is always limited to 1 for added/deleted/typechanged submodules.
+
+--remote::
+ This option is only valid for the update command. Instead of using
+ the superproject's recorded SHA-1 to update the submodule, use the
+ status of the submodule's remote-tracking branch. The remote used
+ is branch's remote (`branch.<name>.remote`), defaulting to `origin`.
+ The remote branch used defaults to the remote `HEAD`, but the branch
+ name may be overridden by setting the `submodule.<name>.branch`
+ option in either `.gitmodules` or `.git/config` (with `.git/config`
+ taking precedence).
++
+This works for any of the supported update procedures (`--checkout`,
+`--rebase`, etc.). The only change is the source of the target SHA-1.
+For example, `submodule update --remote --merge` will merge upstream
+submodule changes into the submodules, while `submodule update
+--merge` will merge superproject gitlink changes into the submodules.
++
+In order to ensure a current tracking branch state, `update --remote`
+fetches the submodule's remote repository before calculating the
+SHA-1. If you don't want to fetch, you should use `submodule update
+--remote --no-fetch`.
++
+Use this option to integrate changes from the upstream subproject with
+your submodule's current HEAD. Alternatively, you can run `git pull`
+from the submodule, which is equivalent except for the remote branch
+name: `update --remote` uses the default upstream repository and
+`submodule.<name>.branch`, while `git pull` uses the submodule's
+`branch.<name>.merge`. Prefer `submodule.<name>.branch` if you want
+to distribute the default upstream branch with the superproject and
+`branch.<name>.merge` if you want a more native feel while working in
+the submodule itself.
+
+-N::
+--no-fetch::
+ This option is only valid for the update command.
+ Don't fetch new objects from the remote site.
+
+--checkout::
+ This option is only valid for the update command.
+ Checkout the commit recorded in the superproject on a detached HEAD
+ in the submodule. This is the default behavior, the main use of
+ this option is to override `submodule.$name.update` when set to
+ a value other than `checkout`.
+ If the key `submodule.$name.update` is either not explicitly set or
+ set to `checkout`, this option is implicit.
+
+--merge::
+ This option is only valid for the update command.
+ Merge the commit recorded in the superproject into the current branch
+ of the submodule. If this option is given, the submodule's HEAD will
+ not be detached. If a merge failure prevents this process, you will
+ have to resolve the resulting conflicts within the submodule with the
+ usual conflict resolution tools.
+ If the key `submodule.$name.update` is set to `merge`, this option is
+ implicit.
+
+--rebase::
+ This option is only valid for the update command.
+ Rebase the current branch onto the commit recorded in the
+ superproject. If this option is given, the submodule's HEAD will not
+ be detached. If a merge failure prevents this process, you will have
+ to resolve these failures with linkgit:git-rebase[1].
+ If the key `submodule.$name.update` is set to `rebase`, this option is
+ implicit.
+
+--init::
+ This option is only valid for the update command.
+ Initialize all submodules for which "git submodule init" has not been
+ called so far before updating.
+
+--name::
+ This option is only valid for the add command. It sets the submodule's
+ name to the given string instead of defaulting to its path. The name
+ must be valid as a directory name and may not end with a '/'.
+
+--reference <repository>::
+ This option is only valid for add and update commands. These
+ commands sometimes need to clone a remote repository. In this case,
+ this option will be passed to the linkgit:git-clone[1] command.
++
+*NOTE*: Do *not* use this option unless you have read the note
+for linkgit:git-clone[1]'s `--reference`, `--shared`, and `--dissociate`
+options carefully.
+
+--dissociate::
+ This option is only valid for add and update commands. These
+ commands sometimes need to clone a remote repository. In this case,
+ this option will be passed to the linkgit:git-clone[1] command.
++
+*NOTE*: see the NOTE for the `--reference` option.
+
+--recursive::
+ This option is only valid for foreach, update, status and sync commands.
+ Traverse submodules recursively. The operation is performed not
+ only in the submodules of the current repo, but also
+ in any nested submodules inside those submodules (and so on).
+
+--depth::
+ This option is valid for add and update commands. Create a 'shallow'
+ clone with a history truncated to the specified number of revisions.
+ See linkgit:git-clone[1]
+
+--[no-]recommend-shallow::
+ This option is only valid for the update command.
+ The initial clone of a submodule will use the recommended
+ `submodule.<name>.shallow` as provided by the `.gitmodules` file
+ by default. To ignore the suggestions use `--no-recommend-shallow`.
+
+-j <n>::
+--jobs <n>::
+ This option is only valid for the update command.
+ Clone new submodules in parallel with as many jobs.
+ Defaults to the `submodule.fetchJobs` option.
+
+--[no-]single-branch::
+ This option is only valid for the update command.
+ Clone only one branch during update: HEAD or one specified by --branch.
+
+<path>...::
+ Paths to submodule(s). When specified this will restrict the command
+ to only operate on the submodules found at the specified paths.
+ (This argument is required with add).
+
+FILES
+-----
+When initializing submodules, a `.gitmodules` file in the top-level directory
+of the containing repository is used to find the url of each submodule.
+This file should be formatted in the same way as `$GIT_DIR/config`. The key
+to each submodule url is "submodule.$name.url". See linkgit:gitmodules[5]
+for details.
+
+SEE ALSO
+--------
+linkgit:gitsubmodules[7], linkgit:gitmodules[5].
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-svn.adoc b/git-svn.adoc
new file mode 100644
index 0000000..bcf7d84
--- /dev/null
+++ b/git-svn.adoc
@@ -0,0 +1,1174 @@
+git-svn(1)
+==========
+
+NAME
+----
+git-svn - Bidirectional operation between a Subversion repository and Git
+
+SYNOPSIS
+--------
+[verse]
+'git svn' <command> [<options>] [<arguments>]
+
+DESCRIPTION
+-----------
+'git svn' is a simple conduit for changesets between Subversion and Git.
+It provides a bidirectional flow of changes between a Subversion and a Git
+repository.
+
+'git svn' can track a standard Subversion repository,
+following the common "trunk/branches/tags" layout, with the --stdlayout option.
+It can also follow branches and tags in any layout with the -T/-t/-b options
+(see options to 'init' below, and also the 'clone' command).
+
+Once tracking a Subversion repository (with any of the above methods), the Git
+repository can be updated from Subversion by the 'fetch' command and
+Subversion updated from Git by the 'dcommit' command.
+
+COMMANDS
+--------
+
+'init'::
+ Initializes an empty Git repository with additional
+ metadata directories for 'git svn'. The Subversion URL
+ may be specified as a command-line argument, or as full
+ URL arguments to -T/-t/-b. Optionally, the target
+ directory to operate on can be specified as a second
+ argument. Normally this command initializes the current
+ directory.
+
+-T<trunk-subdir>;;
+--trunk=<trunk-subdir>;;
+-t<tags-subdir>;;
+--tags=<tags-subdir>;;
+-b<branches-subdir>;;
+--branches=<branches-subdir>;;
+-s;;
+--stdlayout;;
+ These are optional command-line options for init. Each of
+ these flags can point to a relative repository path
+ (--tags=project/tags) or a full url
+ (--tags=https://foo.org/project/tags).
+ You can specify more than one --tags and/or --branches options, in case
+ your Subversion repository places tags or branches under multiple paths.
+ The option --stdlayout is
+ a shorthand way of setting trunk,tags,branches as the relative paths,
+ which is the Subversion default. If any of the other options are given
+ as well, they take precedence.
+--no-metadata;;
+ Set the 'noMetadata' option in the [svn-remote] config.
+ This option is not recommended, please read the 'svn.noMetadata'
+ section of this manpage before using this option.
+--use-svm-props;;
+ Set the 'useSvmProps' option in the [svn-remote] config.
+--use-svnsync-props;;
+ Set the 'useSvnsyncProps' option in the [svn-remote] config.
+--rewrite-root=<URL>;;
+ Set the 'rewriteRoot' option in the [svn-remote] config.
+--rewrite-uuid=<UUID>;;
+ Set the 'rewriteUUID' option in the [svn-remote] config.
+--username=<user>;;
+ For transports that SVN handles authentication for (http,
+ https, and plain svn), specify the username. For other
+ transports (e.g. `svn+ssh://`), you must include the username in
+ the URL, e.g. `svn+ssh://foo@svn.bar.com/project`
+--prefix=<prefix>;;
+ This allows one to specify a prefix which is prepended
+ to the names of remotes if trunk/branches/tags are
+ specified. The prefix does not automatically include a
+ trailing slash, so be sure you include one in the
+ argument if that is what you want. If --branches/-b is
+ specified, the prefix must include a trailing slash.
+ Setting a prefix (with a trailing slash) is strongly
+ encouraged in any case, as your SVN-tracking refs will
+ then be located at "refs/remotes/$prefix/*", which is
+ compatible with Git's own remote-tracking ref layout
+ (refs/remotes/$remote/*). Setting a prefix is also useful
+ if you wish to track multiple projects that share a common
+ repository.
+ By default, the prefix is set to 'origin/'.
++
+NOTE: Before Git v2.0, the default prefix was "" (no prefix). This
+meant that SVN-tracking refs were put at "refs/remotes/*", which is
+incompatible with how Git's own remote-tracking refs are organized.
+If you still want the old default, you can get it by passing
+`--prefix ""` on the command line (`--prefix=""` may not work if
+your Perl's Getopt::Long is < v2.37).
+
+--ignore-refs=<regex>;;
+ When passed to 'init' or 'clone' this regular expression will
+ be preserved as a config key. See 'fetch' for a description
+ of `--ignore-refs`.
+--ignore-paths=<regex>;;
+ When passed to 'init' or 'clone' this regular expression will
+ be preserved as a config key. See 'fetch' for a description
+ of `--ignore-paths`.
+--include-paths=<regex>;;
+ When passed to 'init' or 'clone' this regular expression will
+ be preserved as a config key. See 'fetch' for a description
+ of `--include-paths`.
+--no-minimize-url;;
+ When tracking multiple directories (using --stdlayout,
+ --branches, or --tags options), git svn will attempt to connect
+ to the root (or highest allowed level) of the Subversion
+ repository. This default allows better tracking of history if
+ entire projects are moved within a repository, but may cause
+ issues on repositories where read access restrictions are in
+ place. Passing `--no-minimize-url` will allow git svn to
+ accept URLs as-is without attempting to connect to a higher
+ level directory. This option is off by default when only
+ one URL/branch is tracked (it would do little good).
+
+'fetch'::
+ Fetch unfetched revisions from the Subversion remote we are
+ tracking. The name of the [svn-remote "..."] section in the
+ $GIT_DIR/config file may be specified as an optional
+ command-line argument.
++
+This automatically updates the rev_map if needed (see
+'$GIT_DIR/svn/\**/.rev_map.*' in the FILES section below for details).
+
+--localtime;;
+ Store Git commit times in the local time zone instead of UTC. This
+ makes 'git log' (even without --date=local) show the same times
+ that `svn log` would in the local time zone.
++
+This doesn't interfere with interoperating with the Subversion
+repository you cloned from, but if you wish for your local Git
+repository to be able to interoperate with someone else's local Git
+repository, either don't use this option or you should both use it in
+the same local time zone.
+
+--parent;;
+ Fetch only from the SVN parent of the current HEAD.
+
+--ignore-refs=<regex>;;
+ Ignore refs for branches or tags matching the Perl regular
+ expression. A "negative look-ahead assertion" like
+ `^refs/remotes/origin/(?!tags/wanted-tag|wanted-branch).*$`
+ can be used to allow only certain refs.
++
+[verse]
+config key: svn-remote.<name>.ignore-refs
++
+If the ignore-refs configuration key is set, and the command-line
+option is also given, both regular expressions will be used.
+
+--ignore-paths=<regex>;;
+ This allows one to specify a Perl regular expression that will
+ cause skipping of all matching paths from checkout from SVN.
+ The `--ignore-paths` option should match for every 'fetch'
+ (including automatic fetches due to 'clone', 'dcommit',
+ 'rebase', etc) on a given repository.
++
+[verse]
+config key: svn-remote.<name>.ignore-paths
++
+If the ignore-paths configuration key is set, and the command-line
+option is also given, both regular expressions will be used.
++
+Examples:
++
+--
+Skip "doc*" directory for every fetch;;
++
+------------------------------------------------------------------------
+--ignore-paths="^doc"
+------------------------------------------------------------------------
+
+Skip "branches" and "tags" of first level directories;;
++
+------------------------------------------------------------------------
+--ignore-paths="^[^/]+/(?:branches|tags)"
+------------------------------------------------------------------------
+--
+
+--include-paths=<regex>;;
+ This allows one to specify a Perl regular expression that will
+ cause the inclusion of only matching paths from checkout from SVN.
+ The `--include-paths` option should match for every 'fetch'
+ (including automatic fetches due to 'clone', 'dcommit',
+ 'rebase', etc) on a given repository. `--ignore-paths` takes
+ precedence over `--include-paths`.
++
+[verse]
+config key: svn-remote.<name>.include-paths
+
+--log-window-size=<n>;;
+ Fetch <n> log entries per request when scanning Subversion history.
+ The default is 100. For very large Subversion repositories, larger
+ values may be needed for 'clone'/'fetch' to complete in reasonable
+ time. But overly large values may lead to higher memory usage and
+ request timeouts.
+
+'clone'::
+ Runs 'init' and 'fetch'. It will automatically create a
+ directory based on the basename of the URL passed to it;
+ or if a second argument is passed; it will create a directory
+ and work within that. It accepts all arguments that the
+ 'init' and 'fetch' commands accept; with the exception of
+ `--fetch-all` and `--parent`. After a repository is cloned,
+ the 'fetch' command will be able to update revisions without
+ affecting the working tree; and the 'rebase' command will be
+ able to update the working tree with the latest changes.
+
+--preserve-empty-dirs;;
+ Create a placeholder file in the local Git repository for each
+ empty directory fetched from Subversion. This includes directories
+ that become empty by removing all entries in the Subversion
+ repository (but not the directory itself). The placeholder files
+ are also tracked and removed when no longer necessary.
+
+--placeholder-filename=<filename>;;
+ Set the name of placeholder files created by --preserve-empty-dirs.
+ Default: ".gitignore"
+
+'rebase'::
+ This fetches revisions from the SVN parent of the current HEAD
+ and rebases the current (uncommitted to SVN) work against it.
++
+This works similarly to `svn update` or 'git pull' except that
+it preserves linear history with 'git rebase' instead of
+'git merge' for ease of dcommitting with 'git svn'.
++
+This accepts all options that 'git svn fetch' and 'git rebase'
+accept. However, `--fetch-all` only fetches from the current
+[svn-remote], and not all [svn-remote] definitions.
++
+Like 'git rebase'; this requires that the working tree be clean
+and have no uncommitted changes.
++
+This automatically updates the rev_map if needed (see
+'$GIT_DIR/svn/\**/.rev_map.*' in the FILES section below for details).
+
+-l;;
+--local;;
+ Do not fetch remotely; only run 'git rebase' against the
+ last fetched commit from the upstream SVN.
+
+'dcommit'::
+ Commit each diff from the current branch directly to the SVN
+ repository, and then rebase or reset (depending on whether or
+ not there is a diff between SVN and head). This will create
+ a revision in SVN for each commit in Git.
++
+When an optional Git branch name (or a Git commit object name)
+is specified as an argument, the subcommand works on the specified
+branch, not on the current branch.
++
+Use of 'dcommit' is preferred to 'set-tree' (below).
++
+--no-rebase;;
+ After committing, do not rebase or reset.
+--commit-url <URL>;;
+ Commit to this SVN URL (the full path). This is intended to
+ allow existing 'git svn' repositories created with one transport
+ method (e.g. `svn://` or `http://` for anonymous read) to be
+ reused if a user is later given access to an alternate transport
+ method (e.g. `svn+ssh://` or `https://`) for commit.
++
+[verse]
+config key: svn-remote.<name>.commiturl
+config key: svn.commiturl (overwrites all svn-remote.<name>.commiturl options)
++
+Note that the SVN URL of the commiturl config key includes the SVN branch.
+If you rather want to set the commit URL for an entire SVN repository use
+svn-remote.<name>.pushurl instead.
++
+Using this option for any other purpose (don't ask) is very strongly
+discouraged.
+
+--mergeinfo=<mergeinfo>;;
+ Add the given merge information during the dcommit
+ (e.g. `--mergeinfo="/branches/foo:1-10"`). All svn server versions can
+ store this information (as a property), and svn clients starting from
+ version 1.5 can make use of it. To specify merge information from multiple
+ branches, use a single space character between the branches
+ (`--mergeinfo="/branches/foo:1-10 /branches/bar:3,5-6,8"`)
++
+[verse]
+config key: svn.pushmergeinfo
++
+This option will cause git-svn to attempt to automatically populate the
+svn:mergeinfo property in the SVN repository when possible. Currently, this can
+only be done when dcommitting non-fast-forward merges where all parents but the
+first have already been pushed into SVN.
+
+--interactive;;
+ Ask the user to confirm that a patch set should actually be sent to SVN.
+ For each patch, one may answer "yes" (accept this patch), "no" (discard this
+ patch), "all" (accept all patches), or "quit".
++
+'git svn dcommit' returns immediately if answer is "no" or "quit", without
+committing anything to SVN.
+
+'branch'::
+ Create a branch in the SVN repository.
+
+-m;;
+--message;;
+ Allows to specify the commit message.
+
+-t;;
+--tag;;
+ Create a tag by using the tags_subdir instead of the branches_subdir
+ specified during git svn init.
+
+-d<path>;;
+--destination=<path>;;
+
+ If more than one --branches (or --tags) option was given to the 'init'
+ or 'clone' command, you must provide the location of the branch (or
+ tag) you wish to create in the SVN repository. <path> specifies which
+ path to use to create the branch or tag and should match the pattern
+ on the left-hand side of one of the configured branches or tags
+ refspecs. You can see these refspecs with the commands
++
+ git config --get-all svn-remote.<name>.branches
+ git config --get-all svn-remote.<name>.tags
++
+where <name> is the name of the SVN repository as specified by the -R option to
+'init' (or "svn" by default).
+
+--username;;
+ Specify the SVN username to perform the commit as. This option overrides
+ the 'username' configuration property.
+
+--commit-url;;
+ Use the specified URL to connect to the destination Subversion
+ repository. This is useful in cases where the source SVN
+ repository is read-only. This option overrides configuration
+ property 'commiturl'.
++
+ git config --get-all svn-remote.<name>.commiturl
++
+
+--parents;;
+ Create parent folders. This parameter is equivalent to the parameter
+ --parents on svn cp commands and is useful for non-standard repository
+ layouts.
+
+'tag'::
+ Create a tag in the SVN repository. This is a shorthand for
+ 'branch -t'.
+
+'log'::
+ This should make it easy to look up svn log messages when svn
+ users refer to -r/--revision numbers.
++
+The following features from `svn log' are supported:
++
+--
+-r <n>[:<n>];;
+--revision=<n>[:<n>];;
+ is supported, non-numeric args are not:
+ HEAD, NEXT, BASE, PREV, etc ...
+-v;;
+--verbose;;
+ it's not completely compatible with the --verbose
+ output in svn log, but reasonably close.
+--limit=<n>;;
+ is NOT the same as --max-count, doesn't count
+ merged/excluded commits
+--incremental;;
+ supported
+--
++
+New features:
++
+--
+--show-commit;;
+ shows the Git commit sha1, as well
+--oneline;;
+ our version of --pretty=oneline
+--
++
+NOTE: SVN itself only stores times in UTC and nothing else. The regular svn
+client converts the UTC time to the local time (or based on the TZ=
+environment). This command has the same behaviour.
++
+Any other arguments are passed directly to 'git log'
+
+'blame'::
+ Show what revision and author last modified each line of a file. The
+ output of this mode is format-compatible with the output of
+ `svn blame' by default. Like the SVN blame command,
+ local uncommitted changes in the working tree are ignored;
+ the version of the file in the HEAD revision is annotated. Unknown
+ arguments are passed directly to 'git blame'.
++
+--git-format;;
+ Produce output in the same format as 'git blame', but with
+ SVN revision numbers instead of Git commit hashes. In this mode,
+ changes that haven't been committed to SVN (including local
+ working-copy edits) are shown as revision 0.
+
+'find-rev'::
+ When given an SVN revision number of the form 'rN', returns the
+ corresponding Git commit hash (this can optionally be followed by a
+ tree-ish to specify which branch should be searched). When given a
+ tree-ish, returns the corresponding SVN revision number.
++
+-B;;
+--before;;
+ Don't require an exact match if given an SVN revision, instead find
+ the commit corresponding to the state of the SVN repository (on the
+ current branch) at the specified revision.
++
+-A;;
+--after;;
+ Don't require an exact match if given an SVN revision; if there is
+ not an exact match return the closest match searching forward in the
+ history.
+
+'set-tree'::
+ You should consider using 'dcommit' instead of this command.
+ Commit specified commit or tree objects to SVN. This relies on
+ your imported fetch data being up to date. This makes
+ absolutely no attempts to do patching when committing to SVN, it
+ simply overwrites files with those specified in the tree or
+ commit. All merging is assumed to have taken place
+ independently of 'git svn' functions.
+
+'create-ignore'::
+ Recursively finds the svn:ignore and svn:global-ignores properties
+ on directories and creates matching .gitignore files. The resulting
+ files are staged to be committed, but are not committed. Use
+ -r/--revision to refer to a specific revision.
+
+'show-ignore'::
+ Recursively finds and lists the svn:ignore and svn:global-ignores
+ properties on directories. The output is suitable for appending to
+ the $GIT_DIR/info/exclude file.
+
+'mkdirs'::
+ Attempts to recreate empty directories that core Git cannot track
+ based on information in $GIT_DIR/svn/<refname>/unhandled.log files.
+ Empty directories are automatically recreated when using
+ "git svn clone" and "git svn rebase", so "mkdirs" is intended
+ for use after commands like "git checkout" or "git reset".
+ (See the svn-remote.<name>.automkdirs config file option for
+ more information.)
+
+'commit-diff'::
+ Commits the diff of two tree-ish arguments from the
+ command-line. This command does not rely on being inside a `git svn
+ init`-ed repository. This command takes three arguments, (a) the
+ original tree to diff against, (b) the new tree result, (c) the
+ URL of the target Subversion repository. The final argument
+ (URL) may be omitted if you are working from a 'git svn'-aware
+ repository (that has been `init`-ed with 'git svn').
+ The -r<revision> option is required for this.
++
+The commit message is supplied either directly with the `-m` or `-F`
+option, or indirectly from the tag or commit when the second tree-ish
+denotes such an object, or it is requested by invoking an editor (see
+`--edit` option below).
+
+-m <msg>;;
+--message=<msg>;;
+ Use the given `msg` as the commit message. This option
+ disables the `--edit` option.
+
+-F <filename>;;
+--file=<filename>;;
+ Take the commit message from the given file. This option
+ disables the `--edit` option.
+
+'info'::
+ Shows information about a file or directory similar to what
+ `svn info' provides. Does not currently support a -r/--revision
+ argument. Use the --url option to output only the value of the
+ 'URL:' field.
+
+'proplist'::
+ Lists the properties stored in the Subversion repository about a
+ given file or directory. Use -r/--revision to refer to a specific
+ Subversion revision.
+
+'propget'::
+ Gets the Subversion property given as the first argument, for a
+ file. A specific revision can be specified with -r/--revision.
+
+'propset'::
+ Sets the Subversion property given as the first argument, to the
+ value given as the second argument for the file given as the
+ third argument.
++
+Example:
++
+------------------------------------------------------------------------
+git svn propset svn:keywords "FreeBSD=%H" devel/py-tipper/Makefile
+------------------------------------------------------------------------
++
+This will set the property 'svn:keywords' to 'FreeBSD=%H' for the file
+'devel/py-tipper/Makefile'.
+
+'show-externals'::
+ Shows the Subversion externals. Use -r/--revision to specify a
+ specific revision.
+
+'gc'::
+ Compress $GIT_DIR/svn/<refname>/unhandled.log files and remove
+ $GIT_DIR/svn/<refname>/index files.
+
+'reset'::
+ Undoes the effects of 'fetch' back to the specified revision.
+ This allows you to re-'fetch' an SVN revision. Normally the
+ contents of an SVN revision should never change and 'reset'
+ should not be necessary. However, if SVN permissions change,
+ or if you alter your --ignore-paths option, a 'fetch' may fail
+ with "not found in commit" (file not previously visible) or
+ "checksum mismatch" (missed a modification). If the problem
+ file cannot be ignored forever (with --ignore-paths) the only
+ way to repair the repo is to use 'reset'.
++
+Only the rev_map and refs/remotes/git-svn are changed (see
+'$GIT_DIR/svn/\**/.rev_map.*' in the FILES section below for details).
+Follow 'reset' with a 'fetch' and then 'git reset' or 'git rebase' to
+move local branches onto the new tree.
+
+-r <n>;;
+--revision=<n>;;
+ Specify the most recent revision to keep. All later revisions
+ are discarded.
+-p;;
+--parent;;
+ Discard the specified revision as well, keeping the nearest
+ parent instead.
+Example:;;
+Assume you have local changes in "master", but you need to refetch "r2".
++
+------------
+ r1---r2---r3 remotes/git-svn
+ \
+ A---B master
+------------
++
+Fix the ignore-paths or SVN permissions problem that caused "r2" to
+be incomplete in the first place. Then:
++
+[verse]
+git svn reset -r2 -p
+git svn fetch
++
+------------
+ r1---r2'--r3' remotes/git-svn
+ \
+ r2---r3---A---B master
+------------
++
+Then fixup "master" with 'git rebase'.
+Do NOT use 'git merge' or your history will not be compatible with a
+future 'dcommit'!
++
+[verse]
+git rebase --onto remotes/git-svn A^ master
++
+------------
+ r1---r2'--r3' remotes/git-svn
+ \
+ A'--B' master
+------------
+
+OPTIONS
+-------
+
+--shared[=(false|true|umask|group|all|world|everybody)]::
+--template=<template-directory>::
+ Only used with the 'init' command.
+ These are passed directly to 'git init'.
+
+-r <arg>::
+--revision <arg>::
+ Used with the 'fetch' command.
++
+This allows revision ranges for partial/cauterized history
+to be supported. $NUMBER, $NUMBER1:$NUMBER2 (numeric ranges),
+$NUMBER:HEAD, and BASE:$NUMBER are all supported.
++
+This can allow you to make partial mirrors when running fetch;
+but is generally not recommended because history will be skipped
+and lost.
+
+-::
+--stdin::
+ Only used with the 'set-tree' command.
++
+Read a list of commits from stdin and commit them in reverse
+order. Only the leading sha1 is read from each line, so
+'git rev-list --pretty=oneline' output can be used.
+
+--rmdir::
+ Only used with the 'dcommit', 'set-tree' and 'commit-diff' commands.
++
+Remove directories from the SVN tree if there are no files left
+behind. SVN can version empty directories, and they are not
+removed by default if there are no files left in them. Git
+cannot version empty directories. Enabling this flag will make
+the commit to SVN act like Git.
++
+[verse]
+config key: svn.rmdir
+
+-e::
+--edit::
+ Only used with the 'dcommit', 'set-tree' and 'commit-diff' commands.
++
+Edit the commit message before committing to SVN. This is off by
+default for objects that are commits, and forced on when committing
+tree objects.
++
+[verse]
+config key: svn.edit
+
+-l<num>::
+--find-copies-harder::
+ Only used with the 'dcommit', 'set-tree' and 'commit-diff' commands.
++
+They are both passed directly to 'git diff-tree'; see
+linkgit:git-diff-tree[1] for more information.
++
+[verse]
+config key: svn.l
+config key: svn.findcopiesharder
+
+-A<filename>::
+--authors-file=<filename>::
+ Syntax is compatible with the file used by 'git cvsimport' but
+ an empty email address can be supplied with '<>':
++
+------------------------------------------------------------------------
+ loginname = Joe User <user@example.com>
+------------------------------------------------------------------------
++
+If this option is specified and 'git svn' encounters an SVN
+committer name that does not exist in the authors-file, 'git svn'
+will abort operation. The user will then have to add the
+appropriate entry. Re-running the previous 'git svn' command
+after the authors-file is modified should continue operation.
++
+[verse]
+config key: svn.authorsfile
+
+--authors-prog=<filename>::
+ If this option is specified, for each SVN committer name that
+ does not exist in the authors file, the given file is executed
+ with the committer name as the first argument. The program is
+ expected to return a single line of the form "Name <email>" or
+ "Name <>", which will be treated as if included in the authors
+ file.
++
+Due to historical reasons a relative 'filename' is first searched
+relative to the current directory for 'init' and 'clone' and relative
+to the root of the working tree for 'fetch'. If 'filename' is
+not found, it is searched like any other command in '$PATH'.
++
+[verse]
+config key: svn.authorsProg
+
+-q::
+--quiet::
+ Make 'git svn' less verbose. Specify a second time to make it
+ even less verbose.
+
+-m::
+--merge::
+-s<strategy>::
+--strategy=<strategy>::
+-p::
+--rebase-merges::
+ These are only used with the 'dcommit' and 'rebase' commands.
++
+Passed directly to 'git rebase' when using 'dcommit' if a
+'git reset' cannot be used (see 'dcommit').
+
+-n::
+--dry-run::
+ This can be used with the 'dcommit', 'rebase', 'branch' and
+ 'tag' commands.
++
+For 'dcommit', print out the series of Git arguments that would show
+which diffs would be committed to SVN.
++
+For 'rebase', display the local branch associated with the upstream svn
+repository associated with the current branch and the URL of svn
+repository that will be fetched from.
++
+For 'branch' and 'tag', display the urls that will be used for copying when
+creating the branch or tag.
+
+--use-log-author::
+ When retrieving svn commits into Git (as part of 'fetch', 'rebase', or
+ 'dcommit' operations), look for the first `From:` line or `Signed-off-by` trailer
+ in the log message and use that as the author string.
++
+[verse]
+config key: svn.useLogAuthor
+
+--add-author-from::
+ When committing to svn from Git (as part of 'set-tree' or 'dcommit'
+ operations), if the existing log message doesn't already have a
+ `From:` or `Signed-off-by` trailer, append a `From:` line based on the
+ Git commit's author string. If you use this, then `--use-log-author`
+ will retrieve a valid author string for all commits.
++
+[verse]
+config key: svn.addAuthorFrom
+
+ADVANCED OPTIONS
+----------------
+
+-i<GIT_SVN_ID>::
+--id <GIT_SVN_ID>::
+ This sets GIT_SVN_ID (instead of using the environment). This
+ allows the user to override the default refname to fetch from
+ when tracking a single URL. The 'log' and 'dcommit' commands
+ no longer require this switch as an argument.
+
+-R<remote-name>::
+--svn-remote <remote-name>::
+ Specify the [svn-remote "<remote-name>"] section to use,
+ this allows SVN multiple repositories to be tracked.
+ Default: "svn"
+
+--follow-parent::
+ This option is only relevant if we are tracking branches (using
+ one of the repository layout options --trunk, --tags,
+ --branches, --stdlayout). For each tracked branch, try to find
+ out where its revision was copied from, and set
+ a suitable parent in the first Git commit for the branch.
+ This is especially helpful when we're tracking a directory
+ that has been moved around within the repository. If this
+ feature is disabled, the branches created by 'git svn' will all
+ be linear and not share any history, meaning that there will be
+ no information on where branches were branched off or merged.
+ However, following long/convoluted histories can take a long
+ time, so disabling this feature may speed up the cloning
+ process. This feature is enabled by default, use
+ --no-follow-parent to disable it.
++
+[verse]
+config key: svn.followparent
+
+CONFIG FILE-ONLY OPTIONS
+------------------------
+
+svn.noMetadata::
+svn-remote.<name>.noMetadata::
+ This gets rid of the 'git-svn-id:' lines at the end of every commit.
++
+This option can only be used for one-shot imports as 'git svn'
+will not be able to fetch again without metadata. Additionally,
+if you lose your '$GIT_DIR/svn/\**/.rev_map.*' files, 'git svn' will not
+be able to rebuild them.
++
+The 'git svn log' command will not work on repositories using
+this, either. Using this conflicts with the 'useSvmProps'
+option for (hopefully) obvious reasons.
++
+This option is NOT recommended as it makes it difficult to track down
+old references to SVN revision numbers in existing documentation, bug
+reports, and archives. If you plan to eventually migrate from SVN to
+Git and are certain about dropping SVN history, consider
+https://github.com/newren/git-filter-repo[git-filter-repo] instead.
+filter-repo also allows reformatting of metadata for ease-of-reading
+and rewriting authorship info for non-"svn.authorsFile" users.
+
+svn.useSvmProps::
+svn-remote.<name>.useSvmProps::
+ This allows 'git svn' to re-map repository URLs and UUIDs from
+ mirrors created using SVN::Mirror (or svk) for metadata.
++
+If an SVN revision has a property, "svm:headrev", it is likely
+that the revision was created by SVN::Mirror (also used by SVK).
+The property contains a repository UUID and a revision. We want
+to make it look like we are mirroring the original URL, so
+introduce a helper function that returns the original identity
+URL and UUID, and use it when generating metadata in commit
+messages.
+
+svn.useSvnsyncProps::
+svn-remote.<name>.useSvnsyncprops::
+ Similar to the useSvmProps option; this is for users
+ of the svnsync(1) command distributed with SVN 1.4.x and
+ later.
+
+svn-remote.<name>.rewriteRoot::
+ This allows users to create repositories from alternate
+ URLs. For example, an administrator could run 'git svn' on the
+ server locally (accessing via file://) but wish to distribute
+ the repository with a public http:// or svn:// URL in the
+ metadata so users of it will see the public URL.
+
+svn-remote.<name>.rewriteUUID::
+ Similar to the useSvmProps option; this is for users who need
+ to remap the UUID manually. This may be useful in situations
+ where the original UUID is not available via either useSvmProps
+ or useSvnsyncProps.
+
+svn-remote.<name>.pushurl::
+
+ Similar to Git's `remote.<name>.pushurl`, this key is designed
+ to be used in cases where 'url' points to an SVN repository
+ via a read-only transport, to provide an alternate read/write
+ transport. It is assumed that both keys point to the same
+ repository. Unlike 'commiturl', 'pushurl' is a base path. If
+ either 'commiturl' or 'pushurl' could be used, 'commiturl'
+ takes precedence.
+
+svn.brokenSymlinkWorkaround::
+ This disables potentially expensive checks to workaround
+ broken symlinks checked into SVN by broken clients. Set this
+ option to "false" if you track a SVN repository with many
+ empty blobs that are not symlinks. This option may be changed
+ while 'git svn' is running and take effect on the next
+ revision fetched. If unset, 'git svn' assumes this option to
+ be "true".
+
+svn.pathnameencoding::
+ This instructs git svn to recode pathnames to a given encoding.
+ It can be used by windows users and by those who work in non-utf8
+ locales to avoid corrupted file names with non-ASCII characters.
+ Valid encodings are the ones supported by Perl's Encode module.
+
+svn-remote.<name>.automkdirs::
+ Normally, the "git svn clone" and "git svn rebase" commands
+ attempt to recreate empty directories that are in the
+ Subversion repository. If this option is set to "false", then
+ empty directories will only be created if the "git svn mkdirs"
+ command is run explicitly. If unset, 'git svn' assumes this
+ option to be "true".
+
+Since the noMetadata, rewriteRoot, rewriteUUID, useSvnsyncProps and useSvmProps
+options all affect the metadata generated and used by 'git svn'; they
+*must* be set in the configuration file before any history is imported
+and these settings should never be changed once they are set.
+
+Additionally, only one of these options can be used per svn-remote
+section because they affect the 'git-svn-id:' metadata line, except
+for rewriteRoot and rewriteUUID which can be used together.
+
+
+BASIC EXAMPLES
+--------------
+
+Tracking and contributing to the trunk of a Subversion-managed project
+(ignoring tags and branches):
+
+------------------------------------------------------------------------
+# Clone a repo (like git clone):
+ git svn clone http://svn.example.com/project/trunk
+# Enter the newly cloned directory:
+ cd trunk
+# You should be on master branch, double-check with 'git branch'
+ git branch
+# Do some work and commit locally to Git:
+ git commit ...
+# Something is committed to SVN, rebase your local changes against the
+# latest changes in SVN:
+ git svn rebase
+# Now commit your changes (that were committed previously using Git) to SVN,
+# as well as automatically updating your working HEAD:
+ git svn dcommit
+# Append svn:ignore and svn:global-ignores settings to the default Git exclude file:
+ git svn show-ignore >> .git/info/exclude
+------------------------------------------------------------------------
+
+Tracking and contributing to an entire Subversion-managed project
+(complete with a trunk, tags and branches):
+
+------------------------------------------------------------------------
+# Clone a repo with standard SVN directory layout (like git clone):
+ git svn clone http://svn.example.com/project --stdlayout --prefix svn/
+# Or, if the repo uses a non-standard directory layout:
+ git svn clone http://svn.example.com/project -T tr -b branch -t tag --prefix svn/
+# View all branches and tags you have cloned:
+ git branch -r
+# Create a new branch in SVN
+ git svn branch waldo
+# Reset your master to trunk (or any other branch, replacing 'trunk'
+# with the appropriate name):
+ git reset --hard svn/trunk
+# You may only dcommit to one branch/tag/trunk at a time. The usage
+# of dcommit/rebase/show-ignore should be the same as above.
+------------------------------------------------------------------------
+
+The initial 'git svn clone' can be quite time-consuming
+(especially for large Subversion repositories). If multiple
+people (or one person with multiple machines) want to use
+'git svn' to interact with the same Subversion repository, you can
+do the initial 'git svn clone' to a repository on a server and
+have each person clone that repository with 'git clone':
+
+------------------------------------------------------------------------
+# Do the initial import on a server
+ ssh server "cd /pub && git svn clone http://svn.example.com/project [options...]"
+# Clone locally - make sure the refs/remotes/ space matches the server
+ mkdir project
+ cd project
+ git init
+ git remote add origin server:/pub/project
+ git config --replace-all remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
+ git fetch
+# Prevent fetch/pull from remote Git server in the future,
+# we only want to use git svn for future updates
+ git config --remove-section remote.origin
+# Create a local branch from one of the branches just fetched
+ git checkout -b master FETCH_HEAD
+# Initialize 'git svn' locally (be sure to use the same URL and
+# --stdlayout/-T/-b/-t/--prefix options as were used on server)
+ git svn init http://svn.example.com/project [options...]
+# Pull the latest changes from Subversion
+ git svn rebase
+------------------------------------------------------------------------
+
+REBASE VS. PULL/MERGE
+---------------------
+Prefer to use 'git svn rebase' or 'git rebase', rather than
+'git pull' or 'git merge' to synchronize unintegrated commits with a 'git svn'
+branch. Doing so will keep the history of unintegrated commits linear with
+respect to the upstream SVN repository and allow the use of the preferred
+'git svn dcommit' subcommand to push unintegrated commits back into SVN.
+
+Originally, 'git svn' recommended that developers pulled or merged from
+the 'git svn' branch. This was because the author favored
+`git svn set-tree B` to commit a single head rather than the
+`git svn set-tree A..B` notation to commit multiple commits. Use of
+'git pull' or 'git merge' with `git svn set-tree A..B` will cause non-linear
+history to be flattened when committing into SVN and this can lead to merge
+commits unexpectedly reversing previous commits in SVN.
+
+MERGE TRACKING
+--------------
+While 'git svn' can track
+copy history (including branches and tags) for repositories adopting a
+standard layout, it cannot yet represent merge history that happened
+inside git back upstream to SVN users. Therefore it is advised that
+users keep history as linear as possible inside Git to ease
+compatibility with SVN (see the CAVEATS section below).
+
+HANDLING OF SVN BRANCHES
+------------------------
+If 'git svn' is configured to fetch branches (and --follow-branches
+is in effect), it sometimes creates multiple Git branches for one
+SVN branch, where the additional branches have names of the form
+'branchname@nnn' (with nnn an SVN revision number). These additional
+branches are created if 'git svn' cannot find a parent commit for the
+first commit in an SVN branch, to connect the branch to the history of
+the other branches.
+
+Normally, the first commit in an SVN branch consists
+of a copy operation. 'git svn' will read this commit to get the SVN
+revision the branch was created from. It will then try to find the
+Git commit that corresponds to this SVN revision, and use that as the
+parent of the branch. However, it is possible that there is no suitable
+Git commit to serve as parent. This will happen, among other reasons,
+if the SVN branch is a copy of a revision that was not fetched by 'git
+svn' (e.g. because it is an old revision that was skipped with
+`--revision`), or if in SVN a directory was copied that is not tracked
+by 'git svn' (such as a branch that is not tracked at all, or a
+subdirectory of a tracked branch). In these cases, 'git svn' will still
+create a Git branch, but instead of using an existing Git commit as the
+parent of the branch, it will read the SVN history of the directory the
+branch was copied from and create appropriate Git commits. This is
+indicated by the message "Initializing parent: <branchname>".
+
+Additionally, it will create a special branch named
+'<branchname>@<SVN-Revision>', where <SVN-Revision> is the SVN revision
+number the branch was copied from. This branch will point to the newly
+created parent commit of the branch. If in SVN the branch was deleted
+and later recreated from a different version, there will be multiple
+such branches with an '@'.
+
+Note that this may mean that multiple Git commits are created for a
+single SVN revision.
+
+An example: in an SVN repository with a standard
+trunk/tags/branches layout, a directory trunk/sub is created in r.100.
+In r.200, trunk/sub is branched by copying it to branches/. 'git svn
+clone -s' will then create a branch 'sub'. It will also create new Git
+commits for r.100 through r.199 and use these as the history of branch
+'sub'. Thus there will be two Git commits for each revision from r.100
+to r.199 (one containing trunk/, one containing trunk/sub/). Finally,
+it will create a branch 'sub@200' pointing to the new parent commit of
+branch 'sub' (i.e. the commit for r.200 and trunk/sub/).
+
+CAVEATS
+-------
+
+For the sake of simplicity and interoperating with Subversion,
+it is recommended that all 'git svn' users clone, fetch and dcommit
+directly from the SVN server, and avoid all 'git clone'/'pull'/'merge'/'push'
+operations between Git repositories and branches. The recommended
+method of exchanging code between Git branches and users is
+'git format-patch' and 'git am', or just 'dcommit'ing to the SVN repository.
+
+Running 'git merge' or 'git pull' is NOT recommended on a branch you
+plan to 'dcommit' from because Subversion users cannot see any
+merges you've made. Furthermore, if you merge or pull from a Git branch
+that is a mirror of an SVN branch, 'dcommit' may commit to the wrong
+branch.
+
+If you do merge, note the following rule: 'git svn dcommit' will
+attempt to commit on top of the SVN commit named in
+------------------------------------------------------------------------
+git log --grep=^git-svn-id: --first-parent -1
+------------------------------------------------------------------------
+You 'must' therefore ensure that the most recent commit of the branch
+you want to dcommit to is the 'first' parent of the merge. Chaos will
+ensue otherwise, especially if the first parent is an older commit on
+the same SVN branch.
+
+'git clone' does not clone branches under the refs/remotes/ hierarchy or
+any 'git svn' metadata, or config. So repositories created and managed with
+using 'git svn' should use 'rsync' for cloning, if cloning is to be done
+at all.
+
+Since 'dcommit' uses rebase internally, any Git branches you 'git push' to
+before 'dcommit' on will require forcing an overwrite of the existing ref
+on the remote repository. This is generally considered bad practice,
+see the linkgit:git-push[1] documentation for details.
+
+Do not use the --amend option of linkgit:git-commit[1] on a change you've
+already dcommitted. It is considered bad practice to --amend commits
+you've already pushed to a remote repository for other users, and
+dcommit with SVN is analogous to that.
+
+When cloning an SVN repository, if none of the options for describing
+the repository layout is used (--trunk, --tags, --branches,
+--stdlayout), 'git svn clone' will create a Git repository with
+completely linear history, where branches and tags appear as separate
+directories in the working copy. While this is the easiest way to get a
+copy of a complete repository, for projects with many branches it will
+lead to a working copy many times larger than just the trunk. Thus for
+projects using the standard directory structure (trunk/branches/tags),
+it is recommended to clone with option `--stdlayout`. If the project
+uses a non-standard structure, and/or if branches and tags are not
+required, it is easiest to only clone one directory (typically trunk),
+without giving any repository layout options. If the full history with
+branches and tags is required, the options `--trunk` / `--branches` /
+`--tags` must be used.
+
+When using multiple --branches or --tags, 'git svn' does not automatically
+handle name collisions (for example, if two branches from different paths have
+the same name, or if a branch and a tag have the same name). In these cases,
+use 'init' to set up your Git repository then, before your first 'fetch', edit
+the $GIT_DIR/config file so that the branches and tags are associated
+with different name spaces. For example:
+
+ branches = stable/*:refs/remotes/svn/stable/*
+ branches = debug/*:refs/remotes/svn/debug/*
+
+CONFIGURATION
+-------------
+
+'git svn' stores [svn-remote] configuration information in the
+repository $GIT_DIR/config file. It is similar the core Git
+[remote] sections except 'fetch' keys do not accept glob
+arguments; but they are instead handled by the 'branches'
+and 'tags' keys. Since some SVN repositories are oddly
+configured with multiple projects glob expansions such those
+listed below are allowed:
+
+------------------------------------------------------------------------
+[svn-remote "project-a"]
+ url = http://server.org/svn
+ fetch = trunk/project-a:refs/remotes/project-a/trunk
+ branches = branches/*/project-a:refs/remotes/project-a/branches/*
+ branches = branches/release_*:refs/remotes/project-a/branches/release_*
+ branches = branches/re*se:refs/remotes/project-a/branches/*
+ tags = tags/*/project-a:refs/remotes/project-a/tags/*
+------------------------------------------------------------------------
+
+Keep in mind that the `*` (asterisk) wildcard of the local ref
+(right of the `:`) *must* be the farthest right path component;
+however the remote wildcard may be anywhere as long as it's an
+independent path component (surrounded by `/` or EOL). This
+type of configuration is not automatically created by 'init' and
+should be manually entered with a text-editor or using 'git config'.
+
+Also note that only one asterisk is allowed per word. For example:
+
+ branches = branches/re*se:refs/remotes/project-a/branches/*
+
+will match branches 'release', 'rese', 're123se', however
+
+ branches = branches/re*s*e:refs/remotes/project-a/branches/*
+
+will produce an error.
+
+It is also possible to fetch a subset of branches or tags by using a
+comma-separated list of names within braces. For example:
+
+------------------------------------------------------------------------
+[svn-remote "huge-project"]
+ url = http://server.org/svn
+ fetch = trunk/src:refs/remotes/trunk
+ branches = branches/{red,green}/src:refs/remotes/project-a/branches/*
+ tags = tags/{1.0,2.0}/src:refs/remotes/project-a/tags/*
+------------------------------------------------------------------------
+
+Multiple fetch, branches, and tags keys are supported:
+
+------------------------------------------------------------------------
+[svn-remote "messy-repo"]
+ url = http://server.org/svn
+ fetch = trunk/project-a:refs/remotes/project-a/trunk
+ fetch = branches/demos/june-project-a-demo:refs/remotes/project-a/demos/june-demo
+ branches = branches/server/*:refs/remotes/project-a/branches/*
+ branches = branches/demos/2011/*:refs/remotes/project-a/2011-demos/*
+ tags = tags/server/*:refs/remotes/project-a/tags/*
+------------------------------------------------------------------------
+
+Creating a branch in such a configuration requires disambiguating which
+location to use using the -d or --destination flag:
+
+------------------------------------------------------------------------
+$ git svn branch -d branches/server release-2-3-0
+------------------------------------------------------------------------
+
+Note that git-svn keeps track of the highest revision in which a branch
+or tag has appeared. If the subset of branches or tags is changed after
+fetching, then $GIT_DIR/svn/.metadata must be manually edited to remove
+(or reset) branches-maxRev and/or tags-maxRev as appropriate.
+
+FILES
+-----
+$GIT_DIR/svn/\**/.rev_map.*::
+ Mapping between Subversion revision numbers and Git commit
+ names. In a repository where the noMetadata option is not set,
+ this can be rebuilt from the git-svn-id: lines that are at the
+ end of every commit (see the 'svn.noMetadata' section above for
+ details).
++
+'git svn fetch' and 'git svn rebase' automatically update the rev_map
+if it is missing or not up to date. 'git svn reset' automatically
+rewinds it.
+
+BUGS
+----
+
+We ignore all SVN properties except svn:executable. Any unhandled
+properties are logged to $GIT_DIR/svn/<refname>/unhandled.log
+
+Renamed and copied directories are not detected by Git and hence not
+tracked when committing to SVN. I do not plan on adding support for
+this as it's quite difficult and time-consuming to get working for all
+the possible corner cases (Git doesn't do it, either). Committing
+renamed and copied files is fully supported if they're similar enough
+for Git to detect them.
+
+In SVN, it is possible (though discouraged) to commit changes to a tag
+(because a tag is just a directory copy, thus technically the same as a
+branch). When cloning an SVN repository, 'git svn' cannot know if such a
+commit to a tag will happen in the future. Thus it acts conservatively
+and imports all SVN tags as branches, prefixing the tag name with 'tags/'.
+
+SEE ALSO
+--------
+linkgit:git-rebase[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-switch.adoc b/git-switch.adoc
new file mode 100644
index 0000000..f55315c
--- /dev/null
+++ b/git-switch.adoc
@@ -0,0 +1,287 @@
+git-switch(1)
+=============
+
+NAME
+----
+git-switch - Switch branches
+
+SYNOPSIS
+--------
+[verse]
+'git switch' [<options>] [--no-guess] <branch>
+'git switch' [<options>] --detach [<start-point>]
+'git switch' [<options>] (-c|-C) <new-branch> [<start-point>]
+'git switch' [<options>] --orphan <new-branch>
+
+DESCRIPTION
+-----------
+Switch to a specified branch. The working tree and the index are
+updated to match the branch. All new commits will be added to the tip
+of this branch.
+
+Optionally a new branch could be created with either `-c`, `-C`,
+automatically from a remote branch of same name (see `--guess`), or
+detach the working tree from any branch with `--detach`, along with
+switching.
+
+Switching branches does not require a clean index and working tree
+(i.e. no differences compared to `HEAD`). The operation is aborted
+however if the operation leads to loss of local changes, unless told
+otherwise with `--discard-changes` or `--merge`.
+
+THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
+
+OPTIONS
+-------
+<branch>::
+ Branch to switch to.
+
+<new-branch>::
+ Name for the new branch.
+
+<start-point>::
+ The starting point for the new branch. Specifying a
+ `<start-point>` allows you to create a branch based on some
+ other point in history than where HEAD currently points. (Or,
+ in the case of `--detach`, allows you to inspect and detach
+ from some other point.)
++
+You can use the `@{-N}` syntax to refer to the N-th last
+branch/commit switched to using "git switch" or "git checkout"
+operation. You may also specify `-` which is synonymous to `@{-1}`.
+This is often used to switch quickly between two branches, or to undo
+a branch switch by mistake.
++
+As a special case, you may use `A...B` as a shortcut for the merge
+base of `A` and `B` if there is exactly one merge base. You can leave
+out at most one of `A` and `B`, in which case it defaults to `HEAD`.
+
+-c <new-branch>::
+--create <new-branch>::
+ Create a new branch named `<new-branch>` starting at
+ `<start-point>` before switching to the branch. This is the
+ transactional equivalent of
++
+------------
+$ git branch <new-branch>
+$ git switch <new-branch>
+------------
++
+that is to say, the branch is not reset/created unless "git switch" is
+successful (e.g., when the branch is in use in another worktree, not
+just the current branch stays the same, but the branch is not reset to
+the start-point, either).
+
+-C <new-branch>::
+--force-create <new-branch>::
+ Similar to `--create` except that if `<new-branch>` already
+ exists, it will be reset to `<start-point>`. This is a
+ convenient shortcut for:
++
+------------
+$ git branch -f <new-branch>
+$ git switch <new-branch>
+------------
+
+-d::
+--detach::
+ Switch to a commit for inspection and discardable
+ experiments. See the "DETACHED HEAD" section in
+ linkgit:git-checkout[1] for details.
+
+--guess::
+--no-guess::
+ 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 switch -c <branch> --track <remote>/<branch>
+------------
++
+If the branch exists in multiple remotes and one of them is named by
+the `checkout.defaultRemote` configuration variable, we'll use that
+one for the purposes of disambiguation, even if the `<branch>` isn't
+unique across all remotes. Set it to e.g. `checkout.defaultRemote=origin`
+to always checkout remote branches from there if `<branch>` is
+ambiguous but exists on the 'origin' remote. See also
+`checkout.defaultRemote` in linkgit:git-config[1].
++
+`--guess` is the default behavior. Use `--no-guess` to disable it.
++
+The default behavior can be set via the `checkout.guess` configuration
+variable.
+
+-f::
+--force::
+ An alias for `--discard-changes`.
+
+--discard-changes::
+ Proceed even if the index or the working tree differs from
+ `HEAD`. Both the index and working tree are restored to match
+ the switching target. If `--recurse-submodules` is specified,
+ submodule content is also restored to match the switching
+ target. This is used to throw away local changes.
+
+-m::
+--merge::
+ If you have local modifications to one or more files that are
+ different between the current branch and the branch to which
+ you are switching, the command refuses to switch branches in
+ order to preserve your modifications in context. However,
+ with this option, a three-way merge between the current
+ branch, your working tree contents, and the new branch is
+ done, and you will be on the new branch.
++
+When a merge conflict happens, the index entries for conflicting
+paths are left unmerged, and you need to resolve the conflicts
+and mark the resolved paths with `git add` (or `git rm` if the merge
+should result in deletion of the path).
+
+--conflict=<style>::
+ The same as `--merge` option above, but changes the way the
+ conflicting hunks are presented, overriding the
+ `merge.conflictStyle` configuration variable. Possible values are
+ "merge" (default), "diff3", and "zdiff3".
+
+-q::
+--quiet::
+ Quiet, suppress feedback messages.
+
+--progress::
+--no-progress::
+ Progress status is reported on the standard error stream
+ by default when it is attached to a terminal, unless `--quiet`
+ is specified. This flag enables progress reporting even if not
+ attached to a terminal, regardless of `--quiet`.
+
+-t::
+--track [direct|inherit]::
+ When creating a new branch, set up "upstream" configuration.
+ `-c` is implied. See `--track` in linkgit:git-branch[1] for
+ details.
++
+If no `-c` option is given, the name of the new branch will be derived
+from the remote-tracking branch, by looking at the local part of the
+refspec configured for the corresponding remote, and then stripping
+the initial part up to the "*". This would tell us to use `hack` as
+the local branch when branching off of `origin/hack` (or
+`remotes/origin/hack`, or even `refs/remotes/origin/hack`). If the
+given name has no slash, or the above guessing results in an empty
+name, the guessing is aborted. You can explicitly give a name with
+`-c` in such a case.
+
+--no-track::
+ Do not set up "upstream" configuration, even if the
+ `branch.autoSetupMerge` configuration variable is true.
+
+--orphan <new-branch>::
+ Create a new unborn branch, named `<new-branch>`. All
+ tracked files are removed.
+
+--ignore-other-worktrees::
+ `git switch` refuses when the wanted ref is already
+ checked out by another worktree. This option makes it check
+ the ref out anyway. In other words, the ref can be held by
+ more than one worktree.
+
+--recurse-submodules::
+--no-recurse-submodules::
+ Using `--recurse-submodules` will update the content of all
+ active submodules according to the commit recorded in the
+ superproject. If nothing (or `--no-recurse-submodules`) is
+ used, submodules working trees will not be updated. Just
+ like linkgit:git-submodule[1], this will detach `HEAD` of the
+ submodules.
+
+EXAMPLES
+--------
+
+The following command switches to the "master" branch:
+
+------------
+$ git switch master
+------------
+
+After working in the wrong branch, switching to the correct branch
+would be done using:
+
+------------
+$ git switch mytopic
+------------
+
+However, your "wrong" branch and correct "mytopic" branch may differ
+in files that you have modified locally, in which case the above
+switch would fail like this:
+
+------------
+$ git switch mytopic
+error: You have local changes to 'frotz'; not switching branches.
+------------
+
+You can give the `-m` flag to the command, which would try a three-way
+merge:
+
+------------
+$ git switch -m mytopic
+Auto-merging frotz
+------------
+
+After this three-way merge, the local modifications are _not_
+registered in your index file, so `git diff` would show you what
+changes you made since the tip of the new branch.
+
+To switch back to the previous branch before we switched to mytopic
+(i.e. "master" branch):
+
+------------
+$ git switch -
+------------
+
+You can grow a new branch from any commit. For example, switch to
+"HEAD~3" and create branch "fixup":
+
+------------
+$ git switch -c fixup HEAD~3
+Switched to a new branch 'fixup'
+------------
+
+If you want to start a new branch from a remote branch of the same
+name:
+
+------------
+$ git switch new-topic
+Branch 'new-topic' set up to track remote branch 'new-topic' from 'origin'
+Switched to a new branch 'new-topic'
+------------
+
+To check out commit `HEAD~3` for temporary inspection or experiment
+without creating a new branch:
+
+------------
+$ git switch --detach HEAD~3
+HEAD is now at 9fc9555312 Merge branch 'cc/shared-index-permbits'
+------------
+
+If it turns out whatever you have done is worth keeping, you can
+always create a new name for it (without switching away):
+
+------------
+$ git switch -c good-surprises
+------------
+
+CONFIGURATION
+-------------
+
+include::includes/cmd-config-section-all.adoc[]
+
+include::config/checkout.adoc[]
+
+SEE ALSO
+--------
+linkgit:git-checkout[1],
+linkgit:git-branch[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-symbolic-ref.adoc b/git-symbolic-ref.adoc
new file mode 100644
index 0000000..33ca381
--- /dev/null
+++ b/git-symbolic-ref.adoc
@@ -0,0 +1,82 @@
+git-symbolic-ref(1)
+===================
+
+NAME
+----
+git-symbolic-ref - Read, modify and delete symbolic refs
+
+SYNOPSIS
+--------
+[verse]
+'git symbolic-ref' [-m <reason>] <name> <ref>
+'git symbolic-ref' [-q] [--short] [--no-recurse] <name>
+'git symbolic-ref' --delete [-q] <name>
+
+DESCRIPTION
+-----------
+Given one argument, reads which branch head the given symbolic
+ref refers to and outputs its path, relative to the `.git/`
+directory. Typically you would give `HEAD` as the <name>
+argument to see which branch your working tree is on.
+
+Given two arguments, creates or updates a symbolic ref <name> to
+point at the given branch <ref>.
+
+Given `--delete` and an additional argument, deletes the given
+symbolic ref.
+
+A symbolic ref is a regular file that stores a string that
+begins with `ref: refs/`. For example, your `.git/HEAD` is
+a regular file whose content is `ref: refs/heads/master`.
+
+OPTIONS
+-------
+
+-d::
+--delete::
+ Delete the symbolic ref <name>.
+
+-q::
+--quiet::
+ Do not issue an error message if the <name> is not a
+ symbolic ref but a detached HEAD; instead exit with
+ non-zero status silently.
+
+--short::
+ When showing the value of <name> as a symbolic ref, try to shorten the
+ value, e.g. from `refs/heads/master` to `master`.
+
+--recurse::
+--no-recurse::
+ When showing the value of <name> as a symbolic ref, if
+ <name> refers to another symbolic ref, follow such a chain
+ of symbolic refs until the result no longer points at a
+ symbolic ref (`--recurse`, which is the default).
+ `--no-recurse` stops after dereferencing only a single level
+ of symbolic ref.
+
+-m::
+ Update the reflog for <name> with <reason>. This is valid only
+ when creating or updating a symbolic ref.
+
+NOTES
+-----
+In the past, `.git/HEAD` was a symbolic link pointing at
+`refs/heads/master`. When we wanted to switch to another branch,
+we did `ln -sf refs/heads/newbranch .git/HEAD`, and when we wanted
+to find out which branch we are on, we did `readlink .git/HEAD`.
+But symbolic links are not entirely portable, so they are now
+deprecated and symbolic refs (as described above) are used by
+default.
+
+'git symbolic-ref' will exit with status 0 if the contents of the
+symbolic ref were printed correctly, with status 1 if the requested
+name is not a symbolic ref, or 128 if another error occurs.
+
+SEE ALSO
+--------
+linkgit:git-update-ref[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-tag.adoc b/git-tag.adoc
new file mode 100644
index 0000000..a4b1c0e
--- /dev/null
+++ b/git-tag.adoc
@@ -0,0 +1,418 @@
+git-tag(1)
+==========
+
+NAME
+----
+git-tag - Create, list, delete or verify a tag object signed with GPG
+
+
+SYNOPSIS
+--------
+[verse]
+'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] [-e]
+ [(--trailer <token>[(=|:)<value>])...]
+ <tagname> [<commit> | <object>]
+'git tag' -d <tagname>...
+'git tag' [-n[<num>]] -l [--contains <commit>] [--no-contains <commit>]
+ [--points-at <object>] [--column[=<options>] | --no-column]
+ [--create-reflog] [--sort=<key>] [--format=<format>]
+ [--merged <commit>] [--no-merged <commit>] [<pattern>...]
+'git tag' -v [--format=<format>] <tagname>...
+
+DESCRIPTION
+-----------
+
+Add a tag reference in `refs/tags/`, unless `-d/-l/-v` is given
+to delete, list or verify tags.
+
+Unless `-f` is given, the named tag must not yet exist.
+
+If one of `-a`, `-s`, or `-u <key-id>` is passed, the command
+creates a 'tag' object, and requires a tag message. Unless
+`-m <msg>` or `-F <file>` is given, an editor is started for the user to type
+in the tag message.
+
+If `-m <msg>` or `-F <file>` or `--trailer <token>[=<value>]` is given
+and `-a`, `-s`, and `-u <key-id>` are absent, `-a` is implied.
+
+Otherwise, a tag reference that points directly at the given object
+(i.e., a lightweight tag) is created.
+
+A GnuPG signed tag object will be created when `-s` or `-u
+<key-id>` is used. When `-u <key-id>` is not used, the
+committer identity for the current user is used to find the
+GnuPG key for signing. The configuration variable `gpg.program`
+is used to specify custom GnuPG binary.
+
+Tag objects (created with `-a`, `-s`, or `-u`) are called "annotated"
+tags; they contain a creation date, the tagger name and e-mail, a
+tagging message, and an optional GnuPG signature. Whereas a
+"lightweight" tag is simply a name for an object (usually a commit
+object).
+
+Annotated tags are meant for release while lightweight tags are meant
+for private or temporary object labels. For this reason, some git
+commands for naming objects (like `git describe`) will ignore
+lightweight tags by default.
+
+
+OPTIONS
+-------
+-a::
+--annotate::
+ Make an unsigned, annotated tag object
+
+-s::
+--sign::
+ Make a GPG-signed tag, using the default e-mail address's key.
+ The default behavior of tag GPG-signing is controlled by `tag.gpgSign`
+ configuration variable if it exists, or disabled otherwise.
+ See linkgit:git-config[1].
+
+--no-sign::
+ Override `tag.gpgSign` configuration variable that is
+ set to force each and every tag to be signed.
+
+-u <key-id>::
+--local-user=<key-id>::
+ Make a GPG-signed tag, using the given key.
+
+-f::
+--force::
+ Replace an existing tag with the given name (instead of failing)
+
+-d::
+--delete::
+ Delete existing tags with the given names.
+
+-v::
+--verify::
+ Verify the GPG signature of the given tag names.
+
+-n<num>::
+ <num> specifies how many lines from the annotation, if any,
+ are printed when using -l. Implies `--list`.
++
+The default is not to print any annotation lines.
+If no number is given to `-n`, only the first line is printed.
+If the tag is not annotated, the commit message is displayed instead.
+
+-l::
+--list::
+ List tags. With optional `<pattern>...`, e.g. `git tag --list
+ 'v-*'`, list only the tags that match the pattern(s).
++
+Running "git tag" without arguments also lists all tags. The pattern
+is a shell wildcard (i.e., matched using fnmatch(3)). Multiple
+patterns may be given; if any of them matches, the tag is shown.
++
+This option is implicitly supplied if any other list-like option such
+as `--contains` is provided. See the documentation for each of those
+options for details.
+
+--sort=<key>::
+ Sort based on the key given. Prefix `-` to sort in
+ descending order of the value. You may use the --sort=<key> option
+ multiple times, in which case the last key becomes the primary
+ key. Also supports "version:refname" or "v:refname" (tag
+ names are treated as versions). The "version:refname" sort
+ order can also be affected by the "versionsort.suffix"
+ configuration variable.
+ The keys supported are the same as those in `git for-each-ref`.
+ Sort order defaults to the value configured for the `tag.sort`
+ variable if it exists, or lexicographic order otherwise. See
+ linkgit:git-config[1].
+
+--color[=<when>]::
+ Respect any colors specified in the `--format` option. The
+ `<when>` field must be one of `always`, `never`, or `auto` (if
+ `<when>` is absent, behave as if `always` was given).
+
+-i::
+--ignore-case::
+ Sorting and filtering tags are case insensitive.
+
+--omit-empty::
+ Do not print a newline after formatted refs where the format expands
+ to the empty string.
+
+--column[=<options>]::
+--no-column::
+ Display tag listing in columns. See configuration variable
+ `column.tag` for option syntax. `--column` and `--no-column`
+ without options are equivalent to 'always' and 'never' respectively.
++
+This option is only applicable when listing tags without annotation lines.
+
+--contains [<commit>]::
+ Only list tags which contain the specified commit (HEAD if not
+ specified). Implies `--list`.
+
+--no-contains [<commit>]::
+ Only list tags which don't contain the specified commit (HEAD if
+ not specified). Implies `--list`.
+
+--merged [<commit>]::
+ Only list tags whose commits are reachable from the specified
+ commit (`HEAD` if not specified).
+
+--no-merged [<commit>]::
+ Only list tags whose commits are not reachable from the specified
+ commit (`HEAD` if not specified).
+
+--points-at <object>::
+ Only list tags of the given object (HEAD if not
+ specified). Implies `--list`.
+
+-m <msg>::
+--message=<msg>::
+ Use the given tag message (instead of prompting).
+ If multiple `-m` options are given, their values are
+ concatenated as separate paragraphs.
+ Implies `-a` if none of `-a`, `-s`, or `-u <key-id>`
+ is given.
+
+-F <file>::
+--file=<file>::
+ Take the tag message from the given file. Use '-' to
+ read the message from the standard input.
+ Implies `-a` if none of `-a`, `-s`, or `-u <key-id>`
+ is given.
+
+--trailer <token>[(=|:)<value>]::
+ Specify a (<token>, <value>) pair that should be applied as a
+ trailer. (e.g. `git tag --trailer "Custom-Key: value"`
+ will add a "Custom-Key" trailer to the tag message.)
+ The `trailer.*` configuration variables
+ (linkgit:git-interpret-trailers[1]) can be used to define if
+ a duplicated trailer is omitted, where in the run of trailers
+ each trailer would appear, and other details.
+ The trailers can be extracted in `git tag --list`, using
+ `--format="%(trailers)"` placeholder.
+
+-e::
+--edit::
+ The message taken from file with `-F` and command line with
+ `-m` are usually used as the tag message unmodified.
+ This option lets you further edit the message taken from these sources.
+
+--cleanup=<mode>::
+ This option sets how the tag message is cleaned up.
+ The '<mode>' can be one of 'verbatim', 'whitespace' and 'strip'. The
+ 'strip' mode is default. The 'verbatim' mode does not change message at
+ all, 'whitespace' removes just leading/trailing whitespace lines and
+ 'strip' removes both whitespace and commentary.
+
+--create-reflog::
+ Create a reflog for the tag. To globally enable reflogs for tags, see
+ `core.logAllRefUpdates` in linkgit:git-config[1].
+ The negated form `--no-create-reflog` only overrides an earlier
+ `--create-reflog`, but currently does not negate the setting of
+ `core.logAllRefUpdates`.
+
+--format=<format>::
+ A string that interpolates `%(fieldname)` from a tag ref being shown
+ and the object it points at. The format is the same as
+ that of linkgit:git-for-each-ref[1]. When unspecified,
+ defaults to `%(refname:strip=2)`.
+
+<tagname>::
+ The name of the tag to create, delete, or describe.
+ The new tag name must pass all checks defined by
+ linkgit:git-check-ref-format[1]. Some of these checks
+ may restrict the characters allowed in a tag name.
+
+<commit>::
+<object>::
+ The object that the new tag will refer to, usually a commit.
+ Defaults to HEAD.
+
+CONFIGURATION
+-------------
+By default, 'git tag' in sign-with-default mode (-s) will use your
+committer identity (of the form `Your Name <your@email.address>`) to
+find a key. If you want to use a different default key, you can specify
+it in the repository configuration as follows:
+
+-------------------------------------
+[user]
+ signingKey = <gpg-key-id>
+-------------------------------------
+
+`pager.tag` is only respected when listing tags, i.e., when `-l` is
+used or implied. The default is to use a pager.
+See linkgit:git-config[1].
+
+DISCUSSION
+----------
+
+On Re-tagging
+~~~~~~~~~~~~~
+
+What should you do when you tag a wrong commit and you would
+want to re-tag?
+
+If you never pushed anything out, just re-tag it. Use "-f" to
+replace the old one. And you're done.
+
+But if you have pushed things out (or others could just read
+your repository directly), then others will have already seen
+the old tag. In that case you can do one of two things:
+
+. The sane thing.
+ Just admit you screwed up, and use a different name. Others have
+ already seen one tag-name, and if you keep the same name, you
+ may be in the situation that two people both have "version X",
+ but they actually have 'different' "X"'s. So just call it "X.1"
+ and be done with it.
+
+. The insane thing.
+ You really want to call the new version "X" too, 'even though'
+ others have already seen the old one. So just use 'git tag -f'
+ again, as if you hadn't already published the old one.
+
+However, Git does *not* (and it should not) change tags behind
+users back. So if somebody already got the old tag, doing a
+'git pull' on your tree shouldn't just make them overwrite the old
+one.
+
+If somebody got a release tag from you, you cannot just change
+the tag for them by updating your own one. This is a big
+security issue, in that people MUST be able to trust their
+tag-names. If you really want to do the insane thing, you need
+to just fess up to it, and tell people that you messed up. You
+can do that by making a very public announcement saying:
+
+------------
+Ok, I messed up, and I pushed out an earlier version tagged as X. I
+then fixed something, and retagged the *fixed* tree as X again.
+
+If you got the wrong tag, and want the new one, please delete
+the old one and fetch the new one by doing:
+
+ git tag -d X
+ git fetch origin tag X
+
+to get my updated tag.
+
+You can test which tag you have by doing
+
+ git rev-parse X
+
+which should return 0123456789abcdef.. if you have the new version.
+
+Sorry for the inconvenience.
+------------
+
+Does this seem a bit complicated? It *should* be. There is no
+way that it would be correct to just "fix" it automatically.
+People need to know that their tags might have been changed.
+
+
+On Automatic following
+~~~~~~~~~~~~~~~~~~~~~~
+
+If you are following somebody else's tree, you are most likely
+using remote-tracking branches (eg. `refs/remotes/origin/master`).
+You usually want the tags from the other end.
+
+On the other hand, if you are fetching because you would want a
+one-shot merge from somebody else, you typically do not want to
+get tags from there. This happens more often for people near
+the toplevel but not limited to them. Mere mortals when pulling
+from each other do not necessarily want to automatically get
+private anchor point tags from the other person.
+
+Often, "please pull" messages on the mailing list just provide
+two pieces of information: a repo URL and a branch name; this
+is designed to be easily cut&pasted at the end of a 'git fetch'
+command line:
+
+------------
+Linus, please pull from
+
+ git://git..../proj.git master
+
+to get the following updates...
+------------
+
+becomes:
+
+------------
+$ git pull git://git..../proj.git master
+------------
+
+In such a case, you do not want to automatically follow the other
+person's tags.
+
+One important aspect of Git is its distributed nature, which
+largely means there is no inherent "upstream" or
+"downstream" in the system. On the face of it, the above
+example might seem to indicate that the tag namespace is owned
+by the upper echelon of people and that tags only flow downwards, but
+that is not the case. It only shows that the usage pattern
+determines who are interested in whose tags.
+
+A one-shot pull is a sign that a commit history is now crossing
+the boundary between one circle of people (e.g. "people who are
+primarily interested in the networking part of the kernel") who may
+have their own set of tags (e.g. "this is the third release
+candidate from the networking group to be proposed for general
+consumption with 2.6.21 release") to another circle of people
+(e.g. "people who integrate various subsystem improvements").
+The latter are usually not interested in the detailed tags used
+internally in the former group (that is what "internal" means).
+That is why it is desirable not to follow tags automatically in
+this case.
+
+It may well be that among networking people, they may want to
+exchange the tags internal to their group, but in that workflow
+they are most likely tracking each other's progress by
+having remote-tracking branches. Again, the heuristic to automatically
+follow such tags is a good thing.
+
+
+On Backdating Tags
+~~~~~~~~~~~~~~~~~~
+
+If you have imported some changes from another VCS and would like
+to add tags for major releases of your work, it is useful to be able
+to specify the date to embed inside of the tag object; such data in
+the tag object affects, for example, the ordering of tags in the
+gitweb interface.
+
+To set the date used in future tag objects, set the environment
+variable GIT_COMMITTER_DATE (see the later discussion of possible
+values; the most common form is "YYYY-MM-DD HH:MM").
+
+For example:
+
+------------
+$ GIT_COMMITTER_DATE="2006-10-02 10:31" git tag -s v1.0.1
+------------
+
+include::date-formats.adoc[]
+
+FILES
+-----
+
+`$GIT_DIR/TAG_EDITMSG`::
+ This file contains the message of an in-progress annotated
+ tag. If `git tag` exits due to an error before creating an
+ annotated tag then the tag message that has been provided by the
+ user in an editor session will be available in this file, but
+ may be overwritten by the next invocation of `git tag`.
+
+NOTES
+-----
+
+include::ref-reachability-filters.adoc[]
+
+SEE ALSO
+--------
+linkgit:git-check-ref-format[1].
+linkgit:git-config[1].
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-tools.adoc b/git-tools.adoc
new file mode 100644
index 0000000..d0fec4c
--- /dev/null
+++ b/git-tools.adoc
@@ -0,0 +1,10 @@
+Git Tools
+=========
+
+When Git was young, people looking for third-party Git-related tools came
+to the Git project itself to find them, thus a list of such tools was
+maintained here. These days, however, search engines fill that role much
+more efficiently, so this manually-maintained list has been retired.
+
+See also the `contrib/` area, and the Git wiki:
+https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools
diff --git a/git-unpack-file.adoc b/git-unpack-file.adoc
new file mode 100644
index 0000000..e9f148a
--- /dev/null
+++ b/git-unpack-file.adoc
@@ -0,0 +1,28 @@
+git-unpack-file(1)
+==================
+
+NAME
+----
+git-unpack-file - Creates a temporary file with a blob's contents
+
+
+
+SYNOPSIS
+--------
+[verse]
+'git unpack-file' <blob>
+
+DESCRIPTION
+-----------
+Creates a file holding the contents of the blob specified by sha1. It
+returns the name of the temporary file in the following format:
+ .merge_file_XXXXX
+
+OPTIONS
+-------
+<blob>::
+ Must be a blob id
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-unpack-objects.adoc b/git-unpack-objects.adoc
new file mode 100644
index 0000000..b3de50d
--- /dev/null
+++ b/git-unpack-objects.adoc
@@ -0,0 +1,52 @@
+git-unpack-objects(1)
+=====================
+
+NAME
+----
+git-unpack-objects - Unpack objects from a packed archive
+
+
+SYNOPSIS
+--------
+[verse]
+'git unpack-objects' [-n] [-q] [-r] [--strict]
+
+
+DESCRIPTION
+-----------
+Read a packed archive (.pack) from the standard input, expanding
+the objects contained within and writing them into the repository in
+"loose" (one object per file) format.
+
+Objects that already exist in the repository will *not* be unpacked
+from the packfile. Therefore, nothing will be unpacked if you use
+this command on a packfile that exists within the target repository.
+
+See linkgit:git-repack[1] for options to generate
+new packs and replace existing ones.
+
+OPTIONS
+-------
+-n::
+ Dry run. Check the pack file without actually unpacking
+ the objects.
+
+-q::
+ The command usually shows percentage progress. This
+ flag suppresses it.
+
+-r::
+ When unpacking a corrupt packfile, the command dies at
+ the first corruption. This flag tells it to keep going
+ and make the best effort to recover as many objects as
+ possible.
+
+--strict::
+ Don't write objects with broken content or links.
+
+--max-input-size=<size>::
+ Die, if the pack is larger than <size>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-update-index.adoc b/git-update-index.adoc
new file mode 100644
index 0000000..7128aed
--- /dev/null
+++ b/git-update-index.adoc
@@ -0,0 +1,613 @@
+git-update-index(1)
+===================
+
+NAME
+----
+git-update-index - Register file contents in the working tree to the index
+
+
+SYNOPSIS
+--------
+[verse]
+'git update-index'
+ [--add] [--remove | --force-remove] [--replace]
+ [--refresh] [-q] [--unmerged] [--ignore-missing]
+ [(--cacheinfo <mode>,<object>,<file>)...]
+ [--chmod=(+|-)x]
+ [--[no-]assume-unchanged]
+ [--[no-]skip-worktree]
+ [--[no-]ignore-skip-worktree-entries]
+ [--[no-]fsmonitor-valid]
+ [--ignore-submodules]
+ [--[no-]split-index]
+ [--[no-|test-|force-]untracked-cache]
+ [--[no-]fsmonitor]
+ [--really-refresh] [--unresolve] [--again | -g]
+ [--info-only] [--index-info]
+ [-z] [--stdin] [--index-version <n>]
+ [--show-index-version]
+ [--verbose]
+ [--] [<file>...]
+
+DESCRIPTION
+-----------
+Modifies the index. Each file mentioned is updated into the index and
+any 'unmerged' or 'needs updating' state is cleared.
+
+See also linkgit:git-add[1] for a more user-friendly way to do some of
+the most common operations on the index.
+
+The way 'git update-index' handles files it is told about can be modified
+using the various options:
+
+OPTIONS
+-------
+--add::
+ If a specified file isn't in the index already then it's
+ added.
+ Default behaviour is to ignore new files.
+
+--remove::
+ If a specified file is in the index but is missing then it's
+ removed.
+ Default behavior is to ignore removed files.
+
+--refresh::
+ Looks at the current index and checks to see if merges or
+ updates are needed by checking stat() information.
+
+-q::
+ Quiet. If --refresh finds that the index needs an update, the
+ default behavior is to error out. This option makes
+ 'git update-index' continue anyway.
+
+--ignore-submodules::
+ Do not try to update submodules. This option is only respected
+ when passed before --refresh.
+
+--unmerged::
+ If --refresh finds unmerged changes in the index, the default
+ behavior is to error out. This option makes 'git update-index'
+ continue anyway.
+
+--ignore-missing::
+ Ignores missing files during a --refresh
+
+--cacheinfo <mode>,<object>,<path>::
+--cacheinfo <mode> <object> <path>::
+ Directly insert the specified info into the index. For
+ backward compatibility, you can also give these three
+ arguments as three separate parameters, but new users are
+ encouraged to use a single-parameter form.
+
+--index-info::
+ Read index information from stdin.
+
+--chmod=(+|-)x::
+ Set the execute permissions on the updated files.
+
+--[no-]assume-unchanged::
+ When this flag is specified, the object names recorded
+ for the paths are not updated. Instead, this option
+ sets/unsets the "assume unchanged" bit for the
+ paths. When the "assume unchanged" bit is on, the user
+ promises not to change the file and allows Git to assume
+ that the working tree file matches what is recorded in
+ the index. If you want to change the working tree file,
+ you need to unset the bit to tell Git. This is
+ sometimes helpful when working with a big project on a
+ filesystem that has a very slow lstat(2) system call
+ (e.g. cifs).
++
+Git will fail (gracefully) in case it needs to modify this file
+in the index e.g. when merging in a commit;
+thus, in case the assumed-untracked file is changed upstream,
+you will need to handle the situation manually.
+
+--really-refresh::
+ Like `--refresh`, but checks stat information unconditionally,
+ without regard to the "assume unchanged" setting.
+
+--[no-]skip-worktree::
+ When one of these flags is specified, the object names recorded
+ for the paths are not updated. Instead, these options
+ set and unset the "skip-worktree" bit for the paths. See
+ section "Skip-worktree bit" below for more information.
+
+
+--[no-]ignore-skip-worktree-entries::
+ Do not remove skip-worktree (AKA "index-only") entries even when
+ the `--remove` option was specified.
+
+--[no-]fsmonitor-valid::
+ When one of these flags is specified, the object names recorded
+ for the paths are not updated. Instead, these options
+ set and unset the "fsmonitor valid" bit for the paths. See
+ section "File System Monitor" below for more information.
+
+-g::
+--again::
+ Runs 'git update-index' itself on the paths whose index
+ entries are different from those of the `HEAD` commit.
+
+--unresolve::
+ Restores the 'unmerged' or 'needs updating' state of a
+ file during a merge if it was cleared by accident.
+
+--info-only::
+ Do not create objects in the object database for all
+ <file> arguments that follow this flag; just insert
+ their object IDs into the index.
+
+--force-remove::
+ Remove the file from the index even when the working directory
+ still has such a file. (Implies --remove.)
+
+--replace::
+ By default, when a file `path` exists in the index,
+ 'git update-index' refuses an attempt to add `path/file`.
+ Similarly if a file `path/file` exists, a file `path`
+ cannot be added. With --replace flag, existing entries
+ that conflict with the entry being added are
+ automatically removed with warning messages.
+
+--stdin::
+ Instead of taking a list of paths from the command line,
+ read a list of paths from the standard input. Paths are
+ separated by LF (i.e. one path per line) by default.
+
+--verbose::
+ Report what is being added and removed from the index.
+
+--index-version <n>::
+ Write the resulting index out in the named on-disk format version.
+ Supported versions are 2, 3, and 4. The current default version is 2
+ or 3, depending on whether extra features are used, such as
+ `git add -N`. With `--verbose`, also report the version the index
+ file uses before and after this command.
++
+Version 4 performs a simple pathname compression that reduces index
+size by 30%-50% on large repositories, which results in faster load
+time. Git supports it since version 1.8.0, released in October 2012,
+and support for it was added to libgit2 in 2016 and to JGit in 2020.
+Older versions of this manual page called it "relatively young", but
+it should be considered mature technology these days.
+
+--show-index-version::
+ Report the index format version used by the on-disk index file.
+ See `--index-version` above.
+
+-z::
+ Only meaningful with `--stdin` or `--index-info`; paths are
+ separated with NUL character instead of LF.
+
+--split-index::
+--no-split-index::
+ Enable or disable split index mode. If split-index mode is
+ already enabled and `--split-index` is given again, all
+ changes in $GIT_DIR/index are pushed back to the shared index
+ file.
++
+These options take effect whatever the value of the `core.splitIndex`
+configuration variable (see linkgit:git-config[1]). But a warning is
+emitted when the change goes against the configured value, as the
+configured value will take effect next time the index is read and this
+will remove the intended effect of the option.
+
+--untracked-cache::
+--no-untracked-cache::
+ Enable or disable untracked cache feature. Please use
+ `--test-untracked-cache` before enabling it.
++
+These options take effect whatever the value of the `core.untrackedCache`
+configuration variable (see linkgit:git-config[1]). But a warning is
+emitted when the change goes against the configured value, as the
+configured value will take effect next time the index is read and this
+will remove the intended effect of the option.
+
+--test-untracked-cache::
+ Only perform tests on the working directory to make sure
+ untracked cache can be used. You have to manually enable
+ untracked cache using `--untracked-cache` or
+ `--force-untracked-cache` or the `core.untrackedCache`
+ configuration variable afterwards if you really want to use
+ it. If a test fails the exit code is 1 and a message
+ explains what is not working as needed, otherwise the exit
+ code is 0 and OK is printed.
+
+--force-untracked-cache::
+ Same as `--untracked-cache`. Provided for backwards
+ compatibility with older versions of Git where
+ `--untracked-cache` used to imply `--test-untracked-cache` but
+ this option would enable the extension unconditionally.
+
+--fsmonitor::
+--no-fsmonitor::
+ Enable or disable files system monitor feature. These options
+ take effect whatever the value of the `core.fsmonitor`
+ configuration variable (see linkgit:git-config[1]). But a warning
+ is emitted when the change goes against the configured value, as
+ the configured value will take effect next time the index is
+ read and this will remove the intended effect of the option.
+
+\--::
+ Do not interpret any more arguments as options.
+
+<file>::
+ Files to act on.
+ Note that files beginning with '.' are discarded. This includes
+ `./file` and `dir/./file`. If you don't want this, then use
+ cleaner names.
+ The same applies to directories ending '/' and paths with '//'
+
+USING --REFRESH
+---------------
+`--refresh` does not calculate a new sha1 file or bring the index
+up to date for mode/content changes. But what it *does* do is to
+"re-match" the stat information of a file with the index, so that you
+can refresh the index for a file that hasn't been changed but where
+the stat entry is out of date.
+
+For example, you'd want to do this after doing a 'git read-tree', to link
+up the stat index details with the proper files.
+
+USING --CACHEINFO OR --INFO-ONLY
+--------------------------------
+`--cacheinfo` is used to register a file that is not in the
+current working directory. This is useful for minimum-checkout
+merging.
+
+To pretend you have a file at path with mode and sha1, say:
+
+----------------
+$ git update-index --add --cacheinfo <mode>,<sha1>,<path>
+----------------
+
+`--info-only` is used to register files without placing them in the object
+database. This is useful for status-only repositories.
+
+Both `--cacheinfo` and `--info-only` behave similarly: the index is updated
+but the object database isn't. `--cacheinfo` is useful when the object is
+in the database but the file isn't available locally. `--info-only` is
+useful when the file is available, but you do not wish to update the
+object database.
+
+
+USING --INDEX-INFO
+------------------
+
+`--index-info` is a more powerful mechanism that lets you feed
+multiple entry definitions from the standard input, and designed
+specifically for scripts. It can take inputs of three formats:
+
+ . mode SP type SP sha1 TAB path
++
+This format is to stuff `git ls-tree` output into the index.
+
+ . mode SP sha1 SP stage TAB path
++
+This format is to put higher order stages into the
+index file and matches 'git ls-files --stage' output.
+
+ . mode SP sha1 TAB path
++
+This format is no longer produced by any Git command, but is
+and will continue to be supported by `update-index --index-info`.
+
+To place a higher stage entry to the index, the path should
+first be removed by feeding a mode=0 entry for the path, and
+then feeding necessary input lines in the third format.
+
+For example, starting with this index:
+
+------------
+$ git ls-files -s
+100644 8a1218a1024a212bb3db30becd860315f9f3ac52 0 frotz
+------------
+
+you can feed the following input to `--index-info`:
+
+------------
+$ git update-index --index-info
+0 0000000000000000000000000000000000000000 frotz
+100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1 frotz
+100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2 frotz
+------------
+
+The first line of the input feeds 0 as the mode to remove the
+path; the SHA-1 does not matter as long as it is well formatted.
+Then the second and third line feeds stage 1 and stage 2 entries
+for that path. After the above, we would end up with this:
+
+------------
+$ git ls-files -s
+100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1 frotz
+100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2 frotz
+------------
+
+
+USING ``ASSUME UNCHANGED'' BIT
+------------------------------
+
+Many operations in Git depend on your filesystem to have an
+efficient `lstat(2)` implementation, so that `st_mtime`
+information for working tree files can be cheaply checked to see
+if the file contents have changed from the version recorded in
+the index file. Unfortunately, some filesystems have
+inefficient `lstat(2)`. If your filesystem is one of them, you
+can set "assume unchanged" bit to paths you have not changed to
+cause Git not to do this check. Note that setting this bit on a
+path does not mean Git will check the contents of the file to
+see if it has changed -- it makes Git to omit any checking and
+assume it has *not* changed. When you make changes to working
+tree files, you have to explicitly tell Git about it by dropping
+"assume unchanged" bit, either before or after you modify them.
+
+In order to set "assume unchanged" bit, use `--assume-unchanged`
+option. To unset, use `--no-assume-unchanged`. To see which files
+have the "assume unchanged" bit set, use `git ls-files -v`
+(see linkgit:git-ls-files[1]).
+
+The command looks at `core.ignorestat` configuration variable. When
+this is true, paths updated with `git update-index paths...` and
+paths updated with other Git commands that update both index and
+working tree (e.g. 'git apply --index', 'git checkout-index -u',
+and 'git read-tree -u') are automatically marked as "assume
+unchanged". Note that "assume unchanged" bit is *not* set if
+`git update-index --refresh` finds the working tree file matches
+the index (use `git update-index --really-refresh` if you want
+to mark them as "assume unchanged").
+
+Sometimes users confuse the assume-unchanged bit with the
+skip-worktree bit. See the final paragraph in the "Skip-worktree bit"
+section below for an explanation of the differences.
+
+
+EXAMPLES
+--------
+To update and refresh only the files already checked out:
+
+----------------
+$ git checkout-index -n -f -a && git update-index --ignore-missing --refresh
+----------------
+
+On an inefficient filesystem with `core.ignorestat` set::
++
+------------
+$ git update-index --really-refresh <1>
+$ git update-index --no-assume-unchanged foo.c <2>
+$ git diff --name-only <3>
+$ edit foo.c
+$ git diff --name-only <4>
+M foo.c
+$ git update-index foo.c <5>
+$ git diff --name-only <6>
+$ edit foo.c
+$ git diff --name-only <7>
+$ git update-index --no-assume-unchanged foo.c <8>
+$ git diff --name-only <9>
+M foo.c
+------------
++
+<1> forces lstat(2) to set "assume unchanged" bits for paths that match index.
+<2> mark the path to be edited.
+<3> this does lstat(2) and finds index matches the path.
+<4> this does lstat(2) and finds index does *not* match the path.
+<5> registering the new version to index sets "assume unchanged" bit.
+<6> and it is assumed unchanged.
+<7> even after you edit it.
+<8> you can tell about the change after the fact.
+<9> now it checks with lstat(2) and finds it has been changed.
+
+
+SKIP-WORKTREE BIT
+-----------------
+
+Skip-worktree bit can be defined in one (long) sentence: Tell git to
+avoid writing the file to the working directory when reasonably
+possible, and treat the file as unchanged when it is not
+present in the working directory.
+
+Note that not all git commands will pay attention to this bit, and
+some only partially support it.
+
+The update-index flags and the read-tree capabilities relating to the
+skip-worktree bit predated the introduction of the
+linkgit:git-sparse-checkout[1] command, which provides a much easier
+way to configure and handle the skip-worktree bits. If you want to
+reduce your working tree to only deal with a subset of the files in
+the repository, we strongly encourage the use of
+linkgit:git-sparse-checkout[1] in preference to the low-level
+update-index and read-tree primitives.
+
+The primary purpose of the skip-worktree bit is to enable sparse
+checkouts, i.e. to have working directories with only a subset of
+paths present. When the skip-worktree bit is set, Git commands (such
+as `switch`, `pull`, `merge`) will avoid writing these files.
+However, these commands will sometimes write these files anyway in
+important cases such as conflicts during a merge or rebase. Git
+commands will also avoid treating the lack of such files as an
+intentional deletion; for example `git add -u` will not stage a
+deletion for these files and `git commit -a` will not make a commit
+deleting them either.
+
+Although this bit looks similar to assume-unchanged bit, its goal is
+different. The assume-unchanged bit is for leaving the file in the
+working tree but having Git omit checking it for changes and presuming
+that the file has not been changed (though if it can determine without
+stat'ing the file that it has changed, it is free to record the
+changes). skip-worktree tells Git to ignore the absence of the file,
+avoid updating it when possible with commands that normally update
+much of the working directory (e.g. `checkout`, `switch`, `pull`,
+etc.), and not have its absence be recorded in commits. Note that in
+sparse checkouts (setup by `git sparse-checkout` or by configuring
+core.sparseCheckout to true), if a file is marked as skip-worktree in
+the index but is found in the working tree, Git will clear the
+skip-worktree bit for that file.
+
+SPLIT INDEX
+-----------
+
+This mode is designed for repositories with very large indexes, and
+aims at reducing the time it takes to repeatedly write these indexes.
+
+In this mode, the index is split into two files, $GIT_DIR/index and
+$GIT_DIR/sharedindex.<SHA-1>. Changes are accumulated in
+$GIT_DIR/index, the split index, while the shared index file contains
+all index entries and stays unchanged.
+
+All changes in the split index are pushed back to the shared index
+file when the number of entries in the split index reaches a level
+specified by the splitIndex.maxPercentChange config variable (see
+linkgit:git-config[1]).
+
+Each time a new shared index file is created, the old shared index
+files are deleted if their modification time is older than what is
+specified by the splitIndex.sharedIndexExpire config variable (see
+linkgit:git-config[1]).
+
+To avoid deleting a shared index file that is still used, its
+modification time is updated to the current time every time a new split
+index based on the shared index file is either created or read from.
+
+UNTRACKED CACHE
+---------------
+
+This cache is meant to speed up commands that involve determining
+untracked files such as `git status`.
+
+This feature works by recording the mtime of the working tree
+directories and then omitting reading directories and stat calls
+against files in those directories whose mtime hasn't changed. For
+this to work the underlying operating system and file system must
+change the `st_mtime` field of directories if files in the directory
+are added, modified or deleted.
+
+You can test whether the filesystem supports that with the
+`--test-untracked-cache` option. The `--untracked-cache` option used
+to implicitly perform that test in older versions of Git, but that's
+no longer the case.
+
+If you want to enable (or disable) this feature, it is easier to use
+the `core.untrackedCache` configuration variable (see
+linkgit:git-config[1]) than using the `--untracked-cache` option to
+`git update-index` in each repository, especially if you want to do so
+across all repositories you use, because you can set the configuration
+variable to `true` (or `false`) in your `$HOME/.gitconfig` just once
+and have it affect all repositories you touch.
+
+When the `core.untrackedCache` configuration variable is changed, the
+untracked cache is added to or removed from the index the next time a
+command reads the index; while when `--[no-|force-]untracked-cache`
+are used, the untracked cache is immediately added to or removed from
+the index.
+
+Before 2.17, the untracked cache had a bug where replacing a directory
+with a symlink to another directory could cause it to incorrectly show
+files tracked by git as untracked. See the "status: add a failing test
+showing a core.untrackedCache bug" commit to git.git. A workaround for
+that is (and this might work for other undiscovered bugs in the
+future):
+
+----------------
+$ git -c core.untrackedCache=false status
+----------------
+
+This bug has also been shown to affect non-symlink cases of replacing
+a directory with a file when it comes to the internal structures of
+the untracked cache, but no case has been reported where this resulted in
+wrong "git status" output.
+
+There are also cases where existing indexes written by git versions
+before 2.17 will reference directories that don't exist anymore,
+potentially causing many "could not open directory" warnings to be
+printed on "git status". These are new warnings for existing issues
+that were previously silently discarded.
+
+As with the bug described above the solution is to one-off do a "git
+status" run with `core.untrackedCache=false` to flush out the leftover
+bad data.
+
+FILE SYSTEM MONITOR
+-------------------
+
+This feature is intended to speed up git operations for repos that have
+large working directories.
+
+It enables git to work together with a file system monitor (see
+linkgit:git-fsmonitor{litdd}daemon[1]
+and the
+"fsmonitor-watchman" section of linkgit:githooks[5]) that can
+inform it as to what files have been modified. This enables git to avoid
+having to lstat() every file to find modified files.
+
+When used in conjunction with the untracked cache, it can further improve
+performance by avoiding the cost of scanning the entire working directory
+looking for new files.
+
+If you want to enable (or disable) this feature, it is easier to use
+the `core.fsmonitor` configuration variable (see
+linkgit:git-config[1]) than using the `--fsmonitor` option to `git
+update-index` in each repository, especially if you want to do so
+across all repositories you use, because you can set the configuration
+variable in your `$HOME/.gitconfig` just once and have it affect all
+repositories you touch.
+
+When the `core.fsmonitor` configuration variable is changed, the
+file system monitor is added to or removed from the index the next time
+a command reads the index. When `--[no-]fsmonitor` are used, the file
+system monitor is immediately added to or removed from the index.
+
+CONFIGURATION
+-------------
+
+The command honors `core.filemode` configuration variable. If
+your repository is on a filesystem whose executable bits are
+unreliable, this should be set to 'false' (see linkgit:git-config[1]).
+This causes the command to ignore differences in file modes recorded
+in the index and the file mode on the filesystem if they differ only on
+executable bit. On such an unfortunate filesystem, you may
+need to use 'git update-index --chmod='.
+
+Quite similarly, if `core.symlinks` configuration variable is set
+to 'false' (see linkgit:git-config[1]), symbolic links are checked out
+as plain files, and this command does not modify a recorded file mode
+from symbolic link to regular file.
+
+The command looks at `core.ignorestat` configuration variable. See
+'Using "assume unchanged" bit' section above.
+
+The command also looks at `core.trustctime` configuration variable.
+It can be useful when the inode change time is regularly modified by
+something outside Git (file system crawlers and backup systems use
+ctime for marking files processed) (see linkgit:git-config[1]).
+
+The untracked cache extension can be enabled by the
+`core.untrackedCache` configuration variable (see
+linkgit:git-config[1]).
+
+NOTES
+-----
+
+Users often try to use the assume-unchanged and skip-worktree bits
+to tell Git to ignore changes to files that are tracked. This does not
+work as expected, since Git may still check working tree files against
+the index when performing certain operations. In general, Git does not
+provide a way to ignore changes to tracked files, so alternate solutions
+are recommended.
+
+For example, if the file you want to change is some sort of config file,
+the repository can include a sample config file that can then be copied
+into the ignored name and modified. The repository can even include a
+script to treat the sample file as a template, modifying and copying it
+automatically.
+
+SEE ALSO
+--------
+linkgit:git-config[1],
+linkgit:git-add[1],
+linkgit:git-ls-files[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-update-ref.adoc b/git-update-ref.adoc
new file mode 100644
index 0000000..9e6935d
--- /dev/null
+++ b/git-update-ref.adoc
@@ -0,0 +1,199 @@
+git-update-ref(1)
+=================
+
+NAME
+----
+git-update-ref - Update the object name stored in a ref safely
+
+SYNOPSIS
+--------
+[verse]
+'git update-ref' [-m <reason>] [--no-deref] (-d <ref> [<old-oid>] | [--create-reflog] <ref> <new-oid> [<old-oid>] | --stdin [-z])
+
+DESCRIPTION
+-----------
+Given two arguments, stores the <new-oid> in the <ref>, possibly
+dereferencing the symbolic refs. E.g. `git update-ref HEAD
+<new-oid>` updates the current branch head to the new object.
+
+Given three arguments, stores the <new-oid> in the <ref>,
+possibly dereferencing the symbolic refs, after verifying that
+the current value of the <ref> matches <old-oid>.
+E.g. `git update-ref refs/heads/master <new-oid> <old-oid>`
+updates the master branch head to <new-oid> only if its current
+value is <old-oid>. You can specify 40 "0" or an empty string
+as <old-oid> to make sure that the ref you are creating does
+not exist.
+
+The final arguments are object names; this command without any options
+does not support updating a symbolic ref to point to another ref (see
+linkgit:git-symbolic-ref[1]). But `git update-ref --stdin` does have
+the `symref-*` commands so that regular refs and symbolic refs can be
+committed in the same transaction.
+
+If --no-deref is given, <ref> itself is overwritten, rather than
+the result of following the symbolic pointers.
+
+With `-d`, it deletes the named <ref> after verifying that it
+still contains <old-oid>.
+
+With `--stdin`, update-ref reads instructions from standard input and
+performs all modifications together. Specify commands of the form:
+
+ update SP <ref> SP <new-oid> [SP <old-oid>] LF
+ create SP <ref> SP <new-oid> LF
+ delete SP <ref> [SP <old-oid>] LF
+ verify SP <ref> [SP <old-oid>] LF
+ symref-update SP <ref> SP <new-target> [SP (ref SP <old-target> | oid SP <old-oid>)] LF
+ symref-create SP <ref> SP <new-target> LF
+ symref-delete SP <ref> [SP <old-target>] LF
+ symref-verify SP <ref> [SP <old-target>] LF
+ option SP <opt> LF
+ start LF
+ prepare LF
+ commit LF
+ abort LF
+
+With `--create-reflog`, update-ref will create a reflog for each ref
+even if one would not ordinarily be created.
+
+Quote fields containing whitespace as if they were strings in C source
+code; i.e., surrounded by double-quotes and with backslash escapes.
+Use 40 "0" characters or the empty string to specify a zero value. To
+specify a missing value, omit the value and its preceding SP entirely.
+
+Alternatively, use `-z` to specify in NUL-terminated format, without
+quoting:
+
+ update SP <ref> NUL <new-oid> NUL [<old-oid>] NUL
+ create SP <ref> NUL <new-oid> NUL
+ delete SP <ref> NUL [<old-oid>] NUL
+ verify SP <ref> NUL [<old-oid>] NUL
+ symref-update SP <ref> NUL <new-target> [NUL (ref NUL <old-target> | oid NUL <old-oid>)] NUL
+ symref-create SP <ref> NUL <new-target> NUL
+ symref-delete SP <ref> [NUL <old-target>] NUL
+ symref-verify SP <ref> [NUL <old-target>] NUL
+ option SP <opt> NUL
+ start NUL
+ prepare NUL
+ commit NUL
+ abort NUL
+
+In this format, use 40 "0" to specify a zero value, and use the empty
+string to specify a missing value.
+
+In either format, values can be specified in any form that Git
+recognizes as an object name. Commands in any other format or a
+repeated <ref> produce an error. Command meanings are:
+
+update::
+ Set <ref> to <new-oid> after verifying <old-oid>, if given.
+ Specify a zero <new-oid> to ensure the ref does not exist
+ after the update and/or a zero <old-oid> to make sure the
+ ref does not exist before the update.
+
+create::
+ Create <ref> with <new-oid> after verifying that it does not
+ exist. The given <new-oid> may not be zero.
+
+delete::
+ Delete <ref> after verifying that it exists with <old-oid>, if
+ given. If given, <old-oid> may not be zero.
+
+symref-update::
+ Set <ref> to <new-target> after verifying <old-target> or <old-oid>,
+ if given. Specify a zero <old-oid> to ensure that the ref does not
+ exist before the update.
+
+verify::
+ Verify <ref> against <old-oid> but do not change it. If
+ <old-oid> is zero or missing, the ref must not exist.
+
+symref-create:
+ Create symbolic ref <ref> with <new-target> after verifying that
+ it does not exist.
+
+symref-delete::
+ Delete <ref> after verifying that it exists with <old-target>, if given.
+
+symref-verify::
+ Verify symbolic <ref> against <old-target> but do not change it.
+ If <old-target> is missing, the ref must not exist. Can only be
+ used in `no-deref` mode.
+
+option::
+ Modify the behavior of the next command naming a <ref>.
+ The only valid option is `no-deref` to avoid dereferencing
+ a symbolic ref.
+
+start::
+ Start a transaction. In contrast to a non-transactional session, a
+ transaction will automatically abort if the session ends without an
+ explicit commit. This command may create a new empty transaction when
+ the current one has been committed or aborted already.
+
+prepare::
+ Prepare to commit the transaction. This will create lock files for all
+ queued reference updates. If one reference could not be locked, the
+ transaction will be aborted.
+
+commit::
+ Commit all reference updates queued for the transaction, ending the
+ transaction.
+
+abort::
+ Abort the transaction, releasing all locks if the transaction is in
+ prepared state.
+
+If all <ref>s can be locked with matching <old-oid>s
+simultaneously, all modifications are performed. Otherwise, no
+modifications are performed. Note that while each individual
+<ref> is updated or deleted atomically, a concurrent reader may
+still see a subset of the modifications.
+
+LOGGING UPDATES
+---------------
+If config parameter "core.logAllRefUpdates" is true and the ref is one
+under "refs/heads/", "refs/remotes/", "refs/notes/", or a pseudoref
+like HEAD or ORIG_HEAD; or the file "$GIT_DIR/logs/<ref>" exists then
+`git update-ref` will append a line to the log file
+"$GIT_DIR/logs/<ref>" (dereferencing all symbolic refs before creating
+the log name) describing the change in ref value. Log lines are
+formatted as:
+
+ oldsha1 SP newsha1 SP committer LF
+
+Where "oldsha1" is the 40 character hexadecimal value previously
+stored in <ref>, "newsha1" is the 40 character hexadecimal value of
+<new-oid> and "committer" is the committer's name, email address
+and date in the standard Git committer ident format.
+
+Optionally with -m:
+
+ oldsha1 SP newsha1 SP committer TAB message LF
+
+Where all fields are as described above and "message" is the
+value supplied to the -m option.
+
+An update will fail (without changing <ref>) if the current user is
+unable to create a new log file, append to the existing log file
+or does not have committer information available.
+
+NOTES
+-----
+
+Symbolic refs were initially implemented using symbolic links. This is
+now deprecated since not all filesystems support symbolic links.
+
+This command follows *real* symlinks only if they start with "refs/":
+otherwise it will just try to read them and update them as a regular
+file (i.e. it will allow the filesystem to follow them, but will
+overwrite such a symlink to somewhere else with a regular filename).
+
+SEE ALSO
+--------
+linkgit:git-symbolic-ref[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-update-server-info.adoc b/git-update-server-info.adoc
new file mode 100644
index 0000000..6bc9b50
--- /dev/null
+++ b/git-update-server-info.adoc
@@ -0,0 +1,41 @@
+git-update-server-info(1)
+=========================
+
+NAME
+----
+git-update-server-info - Update auxiliary info file to help dumb servers
+
+
+SYNOPSIS
+--------
+[verse]
+'git update-server-info' [-f | --force]
+
+DESCRIPTION
+-----------
+A dumb server that does not do on-the-fly pack generations must
+have some auxiliary information files in $GIT_DIR/info and
+$GIT_OBJECT_DIRECTORY/info directories to help clients discover
+what references and packs the server has. This command
+generates such auxiliary files.
+
+OPTIONS
+-------
+-f::
+--force::
+ Update the info files from scratch.
+
+OUTPUT
+------
+
+Currently the command updates the following files. Please see
+linkgit:gitrepository-layout[5] for a description of
+what they are for:
+
+* objects/info/packs
+
+* info/refs
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-upload-archive.adoc b/git-upload-archive.adoc
new file mode 100644
index 0000000..e8eb10b
--- /dev/null
+++ b/git-upload-archive.adoc
@@ -0,0 +1,62 @@
+git-upload-archive(1)
+=====================
+
+NAME
+----
+git-upload-archive - Send archive back to git-archive
+
+
+SYNOPSIS
+--------
+[verse]
+'git upload-archive' <repository>
+
+DESCRIPTION
+-----------
+Invoked by 'git archive --remote' and sends a generated archive to the
+other end over the Git protocol.
+
+This command is usually not invoked directly by the end user. The UI
+for the protocol is on the 'git archive' side, and the program pair
+is meant to be used to get an archive from a remote repository.
+
+SECURITY
+--------
+
+In order to protect the privacy of objects that have been removed from
+history but may not yet have been pruned, `git-upload-archive` avoids
+serving archives for commits and trees that are not reachable from the
+repository's refs. However, because calculating object reachability is
+computationally expensive, `git-upload-archive` implements a stricter
+but easier-to-check set of rules:
+
+ 1. Clients may request a commit or tree that is pointed to directly by
+ a ref. E.g., `git archive --remote=origin v1.0`.
+
+ 2. Clients may request a sub-tree within a commit or tree using the
+ `ref:path` syntax. E.g., `git archive --remote=origin v1.0:Documentation`.
+
+ 3. Clients may _not_ use other sha1 expressions, even if the end
+ result is reachable. E.g., neither a relative commit like `master^`
+ nor a literal sha1 like `abcd1234` is allowed, even if the result
+ is reachable from the refs.
+
+Note that rule 3 disallows many cases that do not have any privacy
+implications. These rules are subject to change in future versions of
+git, and the server accessed by `git archive --remote` may or may not
+follow these exact rules.
+
+If the config option `uploadArchive.allowUnreachable` is true, these
+rules are ignored, and clients may use arbitrary sha1 expressions.
+This is useful if you do not care about the privacy of unreachable
+objects, or if your object database is already publicly available for
+access via non-smart-http.
+
+OPTIONS
+-------
+<repository>::
+ The repository to get a tar archive from.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-upload-pack.adoc b/git-upload-pack.adoc
new file mode 100644
index 0000000..516d163
--- /dev/null
+++ b/git-upload-pack.adoc
@@ -0,0 +1,95 @@
+git-upload-pack(1)
+==================
+
+NAME
+----
+git-upload-pack - Send objects packed back to git-fetch-pack
+
+
+SYNOPSIS
+--------
+[verse]
+'git-upload-pack' [--[no-]strict] [--timeout=<n>] [--stateless-rpc]
+ [--advertise-refs] <directory>
+
+DESCRIPTION
+-----------
+Invoked by 'git fetch-pack', learns what
+objects the other side is missing, and sends them after packing.
+
+This command is usually not invoked directly by the end user.
+The UI for the protocol is on the 'git fetch-pack' side, and the
+program pair is meant to be used to pull updates from a remote
+repository. For push operations, see 'git send-pack'.
+
+OPTIONS
+-------
+
+--[no-]strict::
+ Do not try <directory>/.git/ if <directory> is not a Git directory.
+
+--timeout=<n>::
+ Interrupt transfer after <n> seconds of inactivity.
+
+--stateless-rpc::
+ Perform only a single read-write cycle with stdin and stdout.
+ This fits with the HTTP POST request processing model where
+ a program may read the request, write a response, and must exit.
+
+--http-backend-info-refs::
+ Used by linkgit:git-http-backend[1] to serve up
+ `$GIT_URL/info/refs?service=git-upload-pack` requests. See
+ "Smart Clients" in linkgit:gitprotocol-http[5] and "HTTP
+ Transport" in the linkgit:gitprotocol-v2[5]
+ documentation. Also understood by
+ linkgit:git-receive-pack[1].
+
+<directory>::
+ The repository to sync from.
+
+ENVIRONMENT
+-----------
+
+`GIT_PROTOCOL`::
+ Internal variable used for handshaking the wire protocol. Server
+ admins may need to configure some transports to allow this
+ variable to be passed. See the discussion in linkgit:git[1].
+
+`GIT_NO_LAZY_FETCH`::
+ When cloning or fetching from a partial repository (i.e., one
+ itself cloned with `--filter`), the server-side `upload-pack`
+ may need to fetch extra objects from its upstream in order to
+ complete the request. By default, `upload-pack` will refuse to
+ perform such a lazy fetch, because `git fetch` may run arbitrary
+ commands specified in configuration and hooks of the source
+ repository (and `upload-pack` tries to be safe to run even in
+ untrusted `.git` directories).
++
+This is implemented by having `upload-pack` internally set the
+`GIT_NO_LAZY_FETCH` variable to `1`. If you want to override it
+(because you are fetching from a partial clone, and you are sure
+you trust it), you can explicitly set `GIT_NO_LAZY_FETCH` to
+`0`.
+
+SECURITY
+--------
+
+Most Git commands should not be run in an untrusted `.git` directory
+(see the section `SECURITY` in linkgit:git[1]). `upload-pack` tries to
+avoid any dangerous configuration options or hooks from the repository
+it's serving, making it safe to clone an untrusted directory and run
+commands on the resulting clone.
+
+For an extra level of safety, you may be able to run `upload-pack` as an
+alternate user. The details will be platform dependent, but on many
+systems you can run:
+
+ git clone --no-local --upload-pack='sudo -u nobody git-upload-pack' ...
+
+SEE ALSO
+--------
+linkgit:gitnamespaces[7]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-var.adoc b/git-var.adoc
new file mode 100644
index 0000000..0680568
--- /dev/null
+++ b/git-var.adoc
@@ -0,0 +1,105 @@
+git-var(1)
+==========
+
+NAME
+----
+git-var - Show a Git logical variable
+
+
+SYNOPSIS
+--------
+[verse]
+'git var' (-l | <variable>)
+
+DESCRIPTION
+-----------
+Prints a Git logical variable. Exits with code 1 if the variable has
+no value.
+
+OPTIONS
+-------
+-l::
+ Display the logical variables. In addition, all the
+ variables of the Git configuration file .git/config are listed
+ as well. (However, the configuration variables listing functionality
+ is deprecated in favor of `git config -l`.)
+
+EXAMPLES
+--------
+ $ git var GIT_AUTHOR_IDENT
+ Eric W. Biederman <ebiederm@lnxi.com> 1121223278 -0600
+
+
+VARIABLES
+---------
+GIT_AUTHOR_IDENT::
+ The author of a piece of code.
+
+GIT_COMMITTER_IDENT::
+ The person who put a piece of code into Git.
+
+GIT_EDITOR::
+ Text editor for use by Git commands. The value is meant to be
+ interpreted by the shell when it is used. Examples: `~/bin/vi`,
+ `$SOME_ENVIRONMENT_VARIABLE`, `"C:\Program Files\Vim\gvim.exe"
+ --nofork`. The order of preference is the `$GIT_EDITOR`
+ environment variable, then `core.editor` configuration, then
+ `$VISUAL`, then `$EDITOR`, and then the default chosen at compile
+ time, which is usually 'vi'.
+ifdef::git-default-editor[]
+ The build you are using chose '{git-default-editor}' as the default.
+endif::git-default-editor[]
+
+GIT_SEQUENCE_EDITOR::
+ Text editor used to edit the 'todo' file while running `git rebase
+ -i`. Like `GIT_EDITOR`, the value is meant to be interpreted by
+ the shell when it is used. The order of preference is the
+ `$GIT_SEQUENCE_EDITOR` environment variable, then
+ `sequence.editor` configuration, and then the value of `git var
+ GIT_EDITOR`.
+
+GIT_PAGER::
+ Text viewer for use by Git commands (e.g., 'less'). The value
+ is meant to be interpreted by the shell. The order of preference
+ is the `$GIT_PAGER` environment variable, then `core.pager`
+ configuration, then `$PAGER`, and then the default chosen at
+ compile time (usually 'less').
+ifdef::git-default-pager[]
+ The build you are using chose '{git-default-pager}' as the default.
+endif::git-default-pager[]
+
+GIT_DEFAULT_BRANCH::
+ The name of the first branch created in newly initialized repositories.
+
+GIT_SHELL_PATH::
+ The path of the binary providing the POSIX shell for commands which use the shell.
+
+GIT_ATTR_SYSTEM::
+ The path to the system linkgit:gitattributes[5] file, if one is enabled.
+
+GIT_ATTR_GLOBAL::
+ The path to the global (per-user) linkgit:gitattributes[5] file.
+
+GIT_CONFIG_SYSTEM::
+ The path to the system configuration file, if one is enabled.
+
+GIT_CONFIG_GLOBAL::
+ The path to the global (per-user) configuration files, if any.
+
+Most path values contain only one value. However, some can contain multiple
+values, which are separated by newlines, and are listed in order from highest to
+lowest priority. Callers should be prepared for any such path value to contain
+multiple items.
+
+Note that paths are printed even if they do not exist, but not if they are
+disabled by other environment variables.
+
+SEE ALSO
+--------
+linkgit:git-commit-tree[1]
+linkgit:git-tag[1]
+linkgit:git-config[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-verify-commit.adoc b/git-verify-commit.adoc
new file mode 100644
index 0000000..aee4c40
--- /dev/null
+++ b/git-verify-commit.adoc
@@ -0,0 +1,32 @@
+git-verify-commit(1)
+====================
+
+NAME
+----
+git-verify-commit - Check the GPG signature of commits
+
+SYNOPSIS
+--------
+[verse]
+'git verify-commit' [-v | --verbose] [--raw] <commit>...
+
+DESCRIPTION
+-----------
+Validates the GPG signature created by 'git commit -S'.
+
+OPTIONS
+-------
+--raw::
+ Print the raw gpg status output to standard error instead of the normal
+ human-readable output.
+
+-v::
+--verbose::
+ Print the contents of the commit object before validating it.
+
+<commit>...::
+ SHA-1 identifiers of Git commit objects.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-verify-pack.adoc b/git-verify-pack.adoc
new file mode 100644
index 0000000..d7e8869
--- /dev/null
+++ b/git-verify-pack.adoc
@@ -0,0 +1,53 @@
+git-verify-pack(1)
+==================
+
+NAME
+----
+git-verify-pack - Validate packed Git archive files
+
+
+SYNOPSIS
+--------
+[verse]
+'git verify-pack' [-v | --verbose] [-s | --stat-only] [--] <pack>.idx...
+
+
+DESCRIPTION
+-----------
+Reads given idx file for packed Git archive created with the
+'git pack-objects' command and verifies the idx file and the
+corresponding pack file.
+
+OPTIONS
+-------
+<pack>.idx ...::
+ The idx files to verify.
+
+-v::
+--verbose::
+ After verifying the pack, show the list of objects contained
+ in the pack and a histogram of delta chain length.
+
+-s::
+--stat-only::
+ Do not verify the pack contents; only show the histogram of delta
+ chain length. With `--verbose`, the list of objects is also shown.
+
+\--::
+ Do not interpret any more arguments as options.
+
+OUTPUT FORMAT
+-------------
+When specifying the -v option the format used is:
+
+ SHA-1 type size size-in-packfile offset-in-packfile
+
+for objects that are not deltified in the pack, and
+
+ SHA-1 type size size-in-packfile offset-in-packfile depth base-SHA-1
+
+for objects that are deltified.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-verify-tag.adoc b/git-verify-tag.adoc
new file mode 100644
index 0000000..81d50ec
--- /dev/null
+++ b/git-verify-tag.adoc
@@ -0,0 +1,32 @@
+git-verify-tag(1)
+=================
+
+NAME
+----
+git-verify-tag - Check the GPG signature of tags
+
+SYNOPSIS
+--------
+[verse]
+'git verify-tag' [-v | --verbose] [--format=<format>] [--raw] <tag>...
+
+DESCRIPTION
+-----------
+Validates the gpg signature created by 'git tag'.
+
+OPTIONS
+-------
+--raw::
+ Print the raw gpg status output to standard error instead of the normal
+ human-readable output.
+
+-v::
+--verbose::
+ Print the contents of the tag object before validating it.
+
+<tag>...::
+ SHA-1 identifiers of Git tag objects.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-version.adoc b/git-version.adoc
new file mode 100644
index 0000000..80fa775
--- /dev/null
+++ b/git-version.adoc
@@ -0,0 +1,28 @@
+git-version(1)
+==============
+
+NAME
+----
+git-version - Display version information about Git
+
+SYNOPSIS
+--------
+[verse]
+'git version' [--build-options]
+
+DESCRIPTION
+-----------
+With no options given, the version of 'git' is printed on the standard output.
+
+Note that `git --version` is identical to `git version` because the
+former is internally converted into the latter.
+
+OPTIONS
+-------
+--build-options::
+ Include additional information about how git was built for diagnostic
+ purposes.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-web--browse.adoc b/git-web--browse.adoc
new file mode 100644
index 0000000..f2f996c
--- /dev/null
+++ b/git-web--browse.adoc
@@ -0,0 +1,124 @@
+git-web{litdd}browse(1)
+=======================
+
+NAME
+----
+git-web--browse - Git helper script to launch a web browser
+
+SYNOPSIS
+--------
+[verse]
+'git web{litdd}browse' [<options>] (<URL>|<file>)...
+
+DESCRIPTION
+-----------
+
+This script tries, as much as possible, to display the URLs and FILEs
+that are passed as arguments, as HTML pages in new tabs on an already
+opened web browser.
+
+The following browsers (or commands) are currently supported:
+
+* firefox (this is the default under X Window when not using KDE)
+* iceweasel
+* seamonkey
+* iceape
+* chromium (also supported as chromium-browser)
+* google-chrome (also supported as chrome)
+* konqueror (this is the default under KDE, see 'Note about konqueror' below)
+* opera
+* w3m (this is the default outside graphical environments)
+* elinks
+* links
+* lynx
+* dillo
+* open (this is the default under Mac OS X GUI)
+* start (this is the default under MinGW)
+* cygstart (this is the default under Cygwin)
+* xdg-open
+
+Custom commands may also be specified.
+
+OPTIONS
+-------
+-b <browser>::
+--browser=<browser>::
+ Use the specified browser. It must be in the list of supported
+ browsers.
+
+-t <browser>::
+--tool=<browser>::
+ Same as above.
+
+-c <conf.var>::
+--config=<conf.var>::
+ CONF.VAR is looked up in the Git config files. If it's set,
+ then its value specifies the browser that should be used.
+
+CONFIGURATION VARIABLES
+-----------------------
+
+CONF.VAR (from -c option) and web.browser
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The web browser can be specified using a configuration variable passed
+with the -c (or --config) command-line option, or the `web.browser`
+configuration variable if the former is not used.
+
+browser.<tool>.path
+~~~~~~~~~~~~~~~~~~~
+
+You can explicitly provide a full path to your preferred browser by
+setting the configuration variable `browser.<tool>.path`. For example,
+you can configure the absolute path to firefox by setting
+'browser.firefox.path'. Otherwise, 'git web{litdd}browse' assumes the tool
+is available in PATH.
+
+browser.<tool>.cmd
+~~~~~~~~~~~~~~~~~~
+
+When the browser, specified by options or configuration variables, is
+not among the supported ones, then the corresponding
+`browser.<tool>.cmd` configuration variable will be looked up. If this
+variable exists then 'git web{litdd}browse' will treat the specified tool
+as a custom command and will use a shell eval to run the command with
+the URLs passed as arguments.
+
+NOTE ABOUT KONQUEROR
+--------------------
+
+When 'konqueror' is specified by a command-line option or a
+configuration variable, we launch 'kfmclient' to try to open the HTML
+man page on an already opened konqueror in a new tab if possible.
+
+For consistency, we also try such a trick if 'browser.konqueror.path' is
+set to something like `A_PATH_TO/konqueror`. That means we will try to
+launch `A_PATH_TO/kfmclient` instead.
+
+If you really want to use 'konqueror', then you can use something like
+the following:
+
+------------------------------------------------
+ [web]
+ browser = konq
+
+ [browser "konq"]
+ cmd = A_PATH_TO/konqueror
+------------------------------------------------
+
+Note about git-config --global
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Note that these configuration variables should probably be set using
+the `--global` flag, for example like this:
+
+------------------------------------------------
+$ git config --global web.browser firefox
+------------------------------------------------
+
+as they are probably more user specific than repository specific.
+See linkgit:git-config[1] for more information about this.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-whatchanged.adoc b/git-whatchanged.adoc
new file mode 100644
index 0000000..8e55e0b
--- /dev/null
+++ b/git-whatchanged.adoc
@@ -0,0 +1,43 @@
+git-whatchanged(1)
+==================
+
+NAME
+----
+git-whatchanged - Show logs with differences each commit introduces
+
+
+SYNOPSIS
+--------
+[verse]
+'git whatchanged' <option>...
+
+DESCRIPTION
+-----------
+
+Shows commit logs and diff output each commit introduces.
+
+New users are encouraged to use linkgit:git-log[1] instead. The
+`whatchanged` command is essentially the same as linkgit:git-log[1]
+but defaults to showing the raw format diff output and skipping merges.
+
+The command is primarily kept for historical reasons; fingers of
+many people who learned Git long before `git log` was invented by
+reading the Linux kernel mailing list are trained to type it.
+
+
+Examples
+--------
+`git whatchanged -p v2.6.12.. include/scsi drivers/scsi`::
+
+ Show as patches the commits since version 'v2.6.12' that changed
+ any file in the include/scsi or drivers/scsi subdirectories
+
+`git whatchanged --since="2 weeks ago" -- gitk`::
+
+ Show the changes during the last two weeks to the file 'gitk'.
+ The "--" is necessary to avoid confusion with the *branch* named
+ 'gitk'
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-worktree.adoc b/git-worktree.adoc
new file mode 100644
index 0000000..8340b7f
--- /dev/null
+++ b/git-worktree.adoc
@@ -0,0 +1,529 @@
+git-worktree(1)
+===============
+
+NAME
+----
+git-worktree - Manage multiple working trees
+
+
+SYNOPSIS
+--------
+[verse]
+'git worktree add' [-f] [--detach] [--checkout] [--lock [--reason <string>]]
+ [--orphan] [(-b | -B) <new-branch>] <path> [<commit-ish>]
+'git worktree list' [-v | --porcelain [-z]]
+'git worktree lock' [--reason <string>] <worktree>
+'git worktree move' <worktree> <new-path>
+'git worktree prune' [-n] [-v] [--expire <expire>]
+'git worktree remove' [-f] <worktree>
+'git worktree repair' [<path>...]
+'git worktree unlock' <worktree>
+
+DESCRIPTION
+-----------
+
+Manage multiple working trees attached to the same repository.
+
+A git repository can support multiple working trees, allowing you to check
+out more than one branch at a time. With `git worktree add` a new working
+tree is associated with the repository, along with additional metadata
+that differentiates that working tree from others in the same repository.
+The working tree, along with this metadata, is called a "worktree".
+
+This new worktree is called a "linked worktree" as opposed to the "main
+worktree" prepared by linkgit:git-init[1] or linkgit:git-clone[1].
+A repository has one main worktree (if it's not a bare repository) and
+zero or more linked worktrees. When you are done with a linked worktree,
+remove it with `git worktree remove`.
+
+In its simplest form, `git worktree add <path>` automatically creates a
+new branch whose name is the final component of `<path>`, which is
+convenient if you plan to work on a new topic. For instance, `git
+worktree add ../hotfix` creates new branch `hotfix` and checks it out at
+path `../hotfix`. To instead work on an existing branch in a new worktree,
+use `git worktree add <path> <branch>`. On the other hand, if you just
+plan to make some experimental changes or do testing without disturbing
+existing development, it is often convenient to create a 'throwaway'
+worktree not associated with any branch. For instance,
+`git worktree add -d <path>` creates a new worktree with a detached `HEAD`
+at the same commit as the current branch.
+
+If a working tree is deleted without using `git worktree remove`, then
+its associated administrative files, which reside in the repository
+(see "DETAILS" below), will eventually be removed automatically (see
+`gc.worktreePruneExpire` in linkgit:git-config[1]), or you can run
+`git worktree prune` in the main or any linked worktree to clean up any
+stale administrative files.
+
+If the working tree for a linked worktree is stored on a portable device
+or network share which is not always mounted, you can prevent its
+administrative files from being pruned by issuing the `git worktree lock`
+command, optionally specifying `--reason` to explain why the worktree is
+locked.
+
+COMMANDS
+--------
+add <path> [<commit-ish>]::
+
+Create a worktree at `<path>` and checkout `<commit-ish>` into it. The new worktree
+is linked to the current repository, sharing everything except per-worktree
+files such as `HEAD`, `index`, etc. As a convenience, `<commit-ish>` may
+be a bare "`-`", which is synonymous with `@{-1}`.
++
+If `<commit-ish>` is a branch name (call it `<branch>`) and is not found,
+and neither `-b` nor `-B` nor `--detach` are used, but there does
+exist a tracking branch in exactly one remote (call it `<remote>`)
+with a matching name, treat as equivalent to:
++
+------------
+$ git worktree add --track -b <branch> <path> <remote>/<branch>
+------------
++
+If the branch exists in multiple remotes and one of them is named by
+the `checkout.defaultRemote` configuration variable, we'll use that
+one for the purposes of disambiguation, even if the `<branch>` isn't
+unique across all remotes. Set it to
+e.g. `checkout.defaultRemote=origin` to always checkout remote
+branches from there if `<branch>` is ambiguous but exists on the
+`origin` remote. See also `checkout.defaultRemote` in
+linkgit:git-config[1].
++
+If `<commit-ish>` is omitted and neither `-b` nor `-B` nor `--detach` used,
+then, as a convenience, the new worktree is associated with a branch (call
+it `<branch>`) named after `$(basename <path>)`. If `<branch>` doesn't
+exist, a new branch based on `HEAD` is automatically created as if
+`-b <branch>` was given. If `<branch>` does exist, it will be checked out
+in the new worktree, if it's not checked out anywhere else, otherwise the
+command will refuse to create the worktree (unless `--force` is used).
++
+If `<commit-ish>` is omitted, neither `--detach`, or `--orphan` is
+used, and there are no valid local branches (or remote branches if
+`--guess-remote` is specified) then, as a convenience, the new worktree is
+associated with a new unborn branch named `<branch>` (after
+`$(basename <path>)` if neither `-b` or `-B` is used) as if `--orphan` was
+passed to the command. In the event the repository has a remote and
+`--guess-remote` is used, but no remote or local branches exist, then the
+command fails with a warning reminding the user to fetch from their remote
+first (or override by using `-f/--force`).
+
+list::
+
+List details of each worktree. The main worktree is listed first,
+followed by each of the linked worktrees. The output details include
+whether the worktree is bare, the revision currently checked out, the
+branch currently checked out (or "detached HEAD" if none), "locked" if
+the worktree is locked, "prunable" if the worktree can be pruned by the
+`prune` command.
+
+lock::
+
+If a worktree is on a portable device or network share which is not always
+mounted, lock it to prevent its administrative files from being pruned
+automatically. This also prevents it from being moved or deleted.
+Optionally, specify a reason for the lock with `--reason`.
+
+move::
+
+Move a worktree to a new location. Note that the main worktree or linked
+worktrees containing submodules cannot be moved with this command. (The
+`git worktree repair` command, however, can reestablish the connection
+with linked worktrees if you move the main worktree manually.)
+
+prune::
+
+Prune worktree information in `$GIT_DIR/worktrees`.
+
+remove::
+
+Remove a worktree. Only clean worktrees (no untracked files and no
+modification in tracked files) can be removed. Unclean worktrees or ones
+with submodules can be removed with `--force`. The main worktree cannot be
+removed.
+
+repair [<path>...]::
+
+Repair worktree administrative files, if possible, if they have become
+corrupted or outdated due to external factors.
++
+For instance, if the main worktree (or bare repository) is moved, linked
+worktrees will be unable to locate it. Running `repair` in the main
+worktree will reestablish the connection from linked worktrees back to the
+main worktree.
++
+Similarly, if the working tree for a linked worktree is moved without
+using `git worktree move`, the main worktree (or bare repository) will be
+unable to locate it. Running `repair` within the recently-moved worktree
+will reestablish the connection. If multiple linked worktrees are moved,
+running `repair` from any worktree with each tree's new `<path>` as an
+argument, will reestablish the connection to all the specified paths.
++
+If both the main worktree and linked worktrees have been moved or copied manually,
+then running `repair` in the main worktree and specifying the new `<path>`
+of each linked worktree will reestablish all connections in both
+directions.
+
+unlock::
+
+Unlock a worktree, allowing it to be pruned, moved or deleted.
+
+OPTIONS
+-------
+
+-f::
+--force::
+ By default, `add` refuses to create a new worktree when
+ `<commit-ish>` is a branch name and is already checked out by
+ another worktree, or if `<path>` is already assigned to some
+ worktree but is missing (for instance, if `<path>` was deleted
+ manually). This option overrides these safeguards. To add a missing but
+ locked worktree path, specify `--force` twice.
++
+`move` refuses to move a locked worktree unless `--force` is specified
+twice. If the destination is already assigned to some other worktree but is
+missing (for instance, if `<new-path>` was deleted manually), then `--force`
+allows the move to proceed; use `--force` twice if the destination is locked.
++
+`remove` refuses to remove an unclean worktree unless `--force` is used.
+To remove a locked worktree, specify `--force` twice.
+
+-b <new-branch>::
+-B <new-branch>::
+ With `add`, create a new branch named `<new-branch>` starting at
+ `<commit-ish>`, and check out `<new-branch>` into the new worktree.
+ If `<commit-ish>` is omitted, it defaults to `HEAD`.
+ By default, `-b` refuses to create a new branch if it already
+ exists. `-B` overrides this safeguard, resetting `<new-branch>` to
+ `<commit-ish>`.
+
+-d::
+--detach::
+ With `add`, detach `HEAD` in the new worktree. See "DETACHED HEAD"
+ in linkgit:git-checkout[1].
+
+--[no-]checkout::
+ By default, `add` checks out `<commit-ish>`, however, `--no-checkout` can
+ be used to suppress checkout in order to make customizations,
+ such as configuring sparse-checkout. See "Sparse checkout"
+ in linkgit:git-read-tree[1].
+
+--[no-]guess-remote::
+ With `worktree add <path>`, without `<commit-ish>`, instead
+ of creating a new branch from `HEAD`, if there exists a tracking
+ branch in exactly one remote matching the basename of `<path>`,
+ base the new branch on the remote-tracking branch, and mark
+ the remote-tracking branch as "upstream" from the new branch.
++
+This can also be set up as the default behaviour by using the
+`worktree.guessRemote` config option.
+
+--[no-]relative-paths::
+ Link worktrees using relative paths or absolute paths (default).
+ Overrides the `worktree.useRelativePaths` config option, see
+ linkgit:git-config[1].
++
+With `repair`, the linking files will be updated if there's an absolute/relative
+mismatch, even if the links are correct.
+
+--[no-]track::
+ When creating a new branch, if `<commit-ish>` is a branch,
+ mark it as "upstream" from the new branch. This is the
+ default if `<commit-ish>` is a remote-tracking branch. See
+ `--track` in linkgit:git-branch[1] for details.
+
+--lock::
+ Keep the worktree locked after creation. This is the
+ equivalent of `git worktree lock` after `git worktree add`,
+ but without a race condition.
+
+-n::
+--dry-run::
+ With `prune`, do not remove anything; just report what it would
+ remove.
+
+--orphan::
+ With `add`, make the new worktree and index empty, associating
+ the worktree with a new unborn branch named `<new-branch>`.
+
+--porcelain::
+ With `list`, output in an easy-to-parse format for scripts.
+ This format will remain stable across Git versions and regardless of user
+ configuration. It is recommended to combine this with `-z`.
+ See below for details.
+
+-z::
+ Terminate each line with a NUL rather than a newline when
+ `--porcelain` is specified with `list`. This makes it possible
+ to parse the output when a worktree path contains a newline
+ character.
+
+-q::
+--quiet::
+ With `add`, suppress feedback messages.
+
+-v::
+--verbose::
+ With `prune`, report all removals.
++
+With `list`, output additional information about worktrees (see below).
+
+--expire <time>::
+ With `prune`, only expire unused worktrees older than `<time>`.
++
+With `list`, annotate missing worktrees as prunable if they are older than
+`<time>`.
+
+--reason <string>::
+ With `lock` or with `add --lock`, an explanation why the worktree
+ is locked.
+
+<worktree>::
+ Worktrees can be identified by path, either relative or absolute.
++
+If the last path components in the worktree's path is unique among
+worktrees, it can be used to identify a worktree. For example if you only
+have two worktrees, at `/abc/def/ghi` and `/abc/def/ggg`, then `ghi` or
+`def/ghi` is enough to point to the former worktree.
+
+REFS
+----
+When using multiple worktrees, some refs are shared between all worktrees,
+but others are specific to an individual worktree. One example is `HEAD`,
+which is different for each worktree. This section is about the sharing
+rules and how to access refs of one worktree from another.
+
+In general, all pseudo refs are per-worktree and all refs starting with
+`refs/` are shared. Pseudo refs are ones like `HEAD` which are directly
+under `$GIT_DIR` instead of inside `$GIT_DIR/refs`. There are exceptions,
+however: refs inside `refs/bisect`, `refs/worktree` and `refs/rewritten` are
+not shared.
+
+Refs that are per-worktree can still be accessed from another worktree via
+two special paths, `main-worktree` and `worktrees`. The former gives
+access to per-worktree refs of the main worktree, while the latter to all
+linked worktrees.
+
+For example, `main-worktree/HEAD` or `main-worktree/refs/bisect/good`
+resolve to the same value as the main worktree's `HEAD` and
+`refs/bisect/good` respectively. Similarly, `worktrees/foo/HEAD` or
+`worktrees/bar/refs/bisect/bad` are the same as
+`$GIT_COMMON_DIR/worktrees/foo/HEAD` and
+`$GIT_COMMON_DIR/worktrees/bar/refs/bisect/bad`.
+
+To access refs, it's best not to look inside `$GIT_DIR` directly. Instead
+use commands such as linkgit:git-rev-parse[1] or linkgit:git-update-ref[1]
+which will handle refs correctly.
+
+CONFIGURATION FILE
+------------------
+By default, the repository `config` file is shared across all worktrees.
+If the config variables `core.bare` or `core.worktree` are present in the
+common config file and `extensions.worktreeConfig` is disabled, then they
+will be applied to the main worktree only.
+
+In order to have worktree-specific configuration, you can turn on the
+`worktreeConfig` extension, e.g.:
+
+------------
+$ git config extensions.worktreeConfig true
+------------
+
+In this mode, specific configuration stays in the path pointed by `git
+rev-parse --git-path config.worktree`. You can add or update
+configuration in this file with `git config --worktree`. Older Git
+versions will refuse to access repositories with this extension.
+
+Note that in this file, the exception for `core.bare` and `core.worktree`
+is gone. If they exist in `$GIT_DIR/config`, you must move
+them to the `config.worktree` of the main worktree. You may also take this
+opportunity to review and move other configuration that you do not want to
+share to all worktrees:
+
+ - `core.worktree` should never be shared.
+
+ - `core.bare` should not be shared if the value is `core.bare=true`.
+
+ - `core.sparseCheckout` should not be shared, unless you are sure you
+ always use sparse checkout for all worktrees.
+
+See the documentation of `extensions.worktreeConfig` in
+linkgit:git-config[1] for more details.
+
+DETAILS
+-------
+Each linked worktree has a private sub-directory in the repository's
+`$GIT_DIR/worktrees` directory. The private sub-directory's name is usually
+the base name of the linked worktree's path, possibly appended with a
+number to make it unique. For example, when `$GIT_DIR=/path/main/.git` the
+command `git worktree add /path/other/test-next next` creates the linked
+worktree in `/path/other/test-next` and also creates a
+`$GIT_DIR/worktrees/test-next` directory (or `$GIT_DIR/worktrees/test-next1`
+if `test-next` is already taken).
+
+Within a linked worktree, `$GIT_DIR` is set to point to this private
+directory (e.g. `/path/main/.git/worktrees/test-next` in the example) and
+`$GIT_COMMON_DIR` is set to point back to the main worktree's `$GIT_DIR`
+(e.g. `/path/main/.git`). These settings are made in a `.git` file located at
+the top directory of the linked worktree.
+
+Path resolution via `git rev-parse --git-path` uses either
+`$GIT_DIR` or `$GIT_COMMON_DIR` depending on the path. For example, in the
+linked worktree `git rev-parse --git-path HEAD` returns
+`/path/main/.git/worktrees/test-next/HEAD` (not
+`/path/other/test-next/.git/HEAD` or `/path/main/.git/HEAD`) while `git
+rev-parse --git-path refs/heads/master` uses
+`$GIT_COMMON_DIR` and returns `/path/main/.git/refs/heads/master`,
+since refs are shared across all worktrees, except `refs/bisect`,
+`refs/worktree` and `refs/rewritten`.
+
+See linkgit:gitrepository-layout[5] for more information. The rule of
+thumb is do not make any assumption about whether a path belongs to
+`$GIT_DIR` or `$GIT_COMMON_DIR` when you need to directly access something
+inside `$GIT_DIR`. Use `git rev-parse --git-path` to get the final path.
+
+If you manually move a linked worktree, you need to update the `gitdir` file
+in the entry's directory. For example, if a linked worktree is moved
+to `/newpath/test-next` and its `.git` file points to
+`/path/main/.git/worktrees/test-next`, then update
+`/path/main/.git/worktrees/test-next/gitdir` to reference `/newpath/test-next`
+instead. Better yet, run `git worktree repair` to reestablish the connection
+automatically.
+
+To prevent a `$GIT_DIR/worktrees` entry from being pruned (which
+can be useful in some situations, such as when the
+entry's worktree is stored on a portable device), use the
+`git worktree lock` command, which adds a file named
+`locked` to the entry's directory. The file contains the reason in
+plain text. For example, if a linked worktree's `.git` file points
+to `/path/main/.git/worktrees/test-next` then a file named
+`/path/main/.git/worktrees/test-next/locked` will prevent the
+`test-next` entry from being pruned. See
+linkgit:gitrepository-layout[5] for details.
+
+When `extensions.worktreeConfig` is enabled, the config file
+`.git/worktrees/<id>/config.worktree` is read after `.git/config` is.
+
+LIST OUTPUT FORMAT
+------------------
+The `worktree list` command has two output formats. The default format shows the
+details on a single line with columns. For example:
+
+------------
+$ git worktree list
+/path/to/bare-source (bare)
+/path/to/linked-worktree abcd1234 [master]
+/path/to/other-linked-worktree 1234abc (detached HEAD)
+------------
+
+The command also shows annotations for each worktree, according to its state.
+These annotations are:
+
+ * `locked`, if the worktree is locked.
+ * `prunable`, if the worktree can be pruned via `git worktree prune`.
+
+------------
+$ git worktree list
+/path/to/linked-worktree abcd1234 [master]
+/path/to/locked-worktree acbd5678 (brancha) locked
+/path/to/prunable-worktree 5678abc (detached HEAD) prunable
+------------
+
+For these annotations, a reason might also be available and this can be
+seen using the verbose mode. The annotation is then moved to the next line
+indented followed by the additional information.
+
+------------
+$ git worktree list --verbose
+/path/to/linked-worktree abcd1234 [master]
+/path/to/locked-worktree-no-reason abcd5678 (detached HEAD) locked
+/path/to/locked-worktree-with-reason 1234abcd (brancha)
+ locked: worktree path is mounted on a portable device
+/path/to/prunable-worktree 5678abc1 (detached HEAD)
+ prunable: gitdir file points to non-existent location
+------------
+
+Note that the annotation is moved to the next line if the additional
+information is available, otherwise it stays on the same line as the
+worktree itself.
+
+Porcelain Format
+~~~~~~~~~~~~~~~~
+The porcelain format has a line per attribute. If `-z` is given then the lines
+are terminated with NUL rather than a newline. Attributes are listed with a
+label and value separated by a single space. Boolean attributes (like `bare`
+and `detached`) are listed as a label only, and are present only
+if the value is true. Some attributes (like `locked`) can be listed as a label
+only or with a value depending upon whether a reason is available. The first
+attribute of a worktree is always `worktree`, an empty line indicates the
+end of the record. For example:
+
+------------
+$ git worktree list --porcelain
+worktree /path/to/bare-source
+bare
+
+worktree /path/to/linked-worktree
+HEAD abcd1234abcd1234abcd1234abcd1234abcd1234
+branch refs/heads/master
+
+worktree /path/to/other-linked-worktree
+HEAD 1234abc1234abc1234abc1234abc1234abc1234a
+detached
+
+worktree /path/to/linked-worktree-locked-no-reason
+HEAD 5678abc5678abc5678abc5678abc5678abc5678c
+branch refs/heads/locked-no-reason
+locked
+
+worktree /path/to/linked-worktree-locked-with-reason
+HEAD 3456def3456def3456def3456def3456def3456b
+branch refs/heads/locked-with-reason
+locked reason why is locked
+
+worktree /path/to/linked-worktree-prunable
+HEAD 1233def1234def1234def1234def1234def1234b
+detached
+prunable gitdir file points to non-existent location
+
+------------
+
+Unless `-z` is used any "unusual" characters in the lock reason such as newlines
+are escaped and the entire reason is quoted as explained for the
+configuration variable `core.quotePath` (see linkgit:git-config[1]).
+For Example:
+
+------------
+$ git worktree list --porcelain
+...
+locked "reason\nwhy is locked"
+...
+------------
+
+EXAMPLES
+--------
+You are in the middle of a refactoring session and your boss comes in and
+demands that you fix something immediately. You might typically use
+linkgit:git-stash[1] to store your changes away temporarily, however, your
+working tree is in such a state of disarray (with new, moved, and removed
+files, and other bits and pieces strewn around) that you don't want to risk
+disturbing any of it. Instead, you create a temporary linked worktree to
+make the emergency fix, remove it when done, and then resume your earlier
+refactoring session.
+
+------------
+$ git worktree add -b emergency-fix ../temp master
+$ pushd ../temp
+# ... hack hack hack ...
+$ git commit -a -m 'emergency fix for boss'
+$ popd
+$ git worktree remove ../temp
+------------
+
+BUGS
+----
+Multiple checkout in general is still experimental, and the support
+for submodules is incomplete. It is NOT recommended to make multiple
+checkouts of a superproject.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git-write-tree.adoc b/git-write-tree.adoc
new file mode 100644
index 0000000..f22041a
--- /dev/null
+++ b/git-write-tree.adoc
@@ -0,0 +1,42 @@
+git-write-tree(1)
+=================
+
+NAME
+----
+git-write-tree - Create a tree object from the current index
+
+
+SYNOPSIS
+--------
+[verse]
+'git write-tree' [--missing-ok] [--prefix=<prefix>/]
+
+DESCRIPTION
+-----------
+Creates a tree object using the current index. The name of the new
+tree object is printed to standard output.
+
+The index must be in a fully merged state.
+
+Conceptually, 'git write-tree' sync()s the current index contents
+into a set of tree files.
+In order to have that match what is actually in your directory right
+now, you need to have done a 'git update-index' phase before you did the
+'git write-tree'.
+
+
+OPTIONS
+-------
+--missing-ok::
+ Normally 'git write-tree' ensures that the objects referenced by the
+ directory exist in the object database. This option disables this
+ check.
+
+--prefix=<prefix>/::
+ Writes a tree object that represents a subdirectory
+ `<prefix>`. This can be used to write the tree object
+ for a subproject that is in the named subdirectory.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/git.adoc b/git.adoc
new file mode 100644
index 0000000..a9c1183
--- /dev/null
+++ b/git.adoc
@@ -0,0 +1,1190 @@
+git(1)
+======
+
+NAME
+----
+git - the stupid content tracker
+
+
+SYNOPSIS
+--------
+[verse]
+'git' [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>]
+ [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
+ [-p | --paginate | -P | --no-pager] [--no-replace-objects] [--no-lazy-fetch]
+ [--no-optional-locks] [--no-advice] [--bare] [--git-dir=<path>]
+ [--work-tree=<path>] [--namespace=<name>] [--config-env=<name>=<envvar>]
+ <command> [<args>]
+
+DESCRIPTION
+-----------
+Git is a fast, scalable, distributed revision control system with an
+unusually rich command set that provides both high-level operations
+and full access to internals.
+
+See linkgit:gittutorial[7] to get started, then see
+linkgit:giteveryday[7] for a useful minimum set of
+commands. The link:user-manual.html[Git User's Manual] has a more
+in-depth introduction.
+
+After you mastered the basic concepts, you can come back to this
+page to learn what commands Git offers. You can learn more about
+individual Git commands with "git help command". linkgit:gitcli[7]
+manual page gives you an overview of the command-line command syntax.
+
+A formatted and hyperlinked copy of the latest Git documentation
+can be viewed at https://git.github.io/htmldocs/git.html
+or https://git-scm.com/docs.
+
+
+OPTIONS
+-------
+-v::
+--version::
+ Prints the Git suite version that the 'git' program came from.
++
+This option is internally converted to `git version ...` and accepts
+the same options as the linkgit:git-version[1] command. If `--help` is
+also given, it takes precedence over `--version`.
+
+-h::
+--help::
+ Prints the synopsis and a list of the most commonly used
+ commands. If the option `--all` or `-a` is given then all
+ available commands are printed. If a Git command is named this
+ option will bring up the manual page for that command.
++
+Other options are available to control how the manual page is
+displayed. See linkgit:git-help[1] for more information,
+because `git --help ...` is converted internally into `git
+help ...`.
+
+-C <path>::
+ Run as if git was started in '<path>' instead of the current working
+ directory. When multiple `-C` options are given, each subsequent
+ non-absolute `-C <path>` is interpreted relative to the preceding `-C
+ <path>`. If '<path>' is present but empty, e.g. `-C ""`, then the
+ current working directory is left unchanged.
++
+This option affects options that expect path name like `--git-dir` and
+`--work-tree` in that their interpretations of the path names would be
+made relative to the working directory caused by the `-C` option. For
+example the following invocations are equivalent:
+
+ git --git-dir=a.git --work-tree=b -C c status
+ git --git-dir=c/a.git --work-tree=c/b status
+
+-c <name>=<value>::
+ Pass a configuration parameter to the command. The value
+ given will override values from configuration files.
+ The <name> is expected in the same format as listed by
+ 'git config' (subkeys separated by dots).
++
+Note that omitting the `=` in `git -c foo.bar ...` is allowed and sets
+`foo.bar` to the boolean true value (just like `[foo]bar` would in a
+config file). Including the equals but with an empty value (like `git -c
+foo.bar= ...`) sets `foo.bar` to the empty string which `git config
+--type=bool` will convert to `false`.
+
+--config-env=<name>=<envvar>::
+ Like `-c <name>=<value>`, give configuration variable
+ '<name>' a value, where <envvar> is the name of an
+ environment variable from which to retrieve the value. Unlike
+ `-c` there is no shortcut for directly setting the value to an
+ empty string, instead the environment variable itself must be
+ set to the empty string. It is an error if the `<envvar>` does not exist
+ in the environment. `<envvar>` may not contain an equals sign
+ to avoid ambiguity with `<name>` containing one.
++
+This is useful for cases where you want to pass transitory
+configuration options to git, but are doing so on operating systems
+where other processes might be able to read your command line
+(e.g. `/proc/self/cmdline`), but not your environment
+(e.g. `/proc/self/environ`). That behavior is the default on
+Linux, but may not be on your system.
++
+Note that this might add security for variables such as
+`http.extraHeader` where the sensitive information is part of
+the value, but not e.g. `url.<base>.insteadOf` where the
+sensitive information can be part of the key.
+
+--exec-path[=<path>]::
+ Path to wherever your core Git programs are installed.
+ This can also be controlled by setting the GIT_EXEC_PATH
+ environment variable. If no path is given, 'git' will print
+ the current setting and then exit.
+
+--html-path::
+ Print the path, without trailing slash, where Git's HTML
+ documentation is installed and exit.
+
+--man-path::
+ Print the manpath (see `man(1)`) for the man pages for
+ this version of Git and exit.
+
+--info-path::
+ Print the path where the Info files documenting this
+ version of Git are installed and exit.
+
+-p::
+--paginate::
+ Pipe all output into 'less' (or if set, $PAGER) if standard
+ output is a terminal. This overrides the `pager.<cmd>`
+ configuration options (see the "Configuration Mechanism" section
+ below).
+
+-P::
+--no-pager::
+ Do not pipe Git output into a pager.
+
+--git-dir=<path>::
+ Set the path to the repository (".git" directory). This can also be
+ controlled by setting the `GIT_DIR` environment variable. It can be
+ an absolute path or relative path to current working directory.
++
+Specifying the location of the ".git" directory using this
+option (or `GIT_DIR` environment variable) turns off the
+repository discovery that tries to find a directory with
+".git" subdirectory (which is how the repository and the
+top-level of the working tree are discovered), and tells Git
+that you are at the top level of the working tree. If you
+are not at the top-level directory of the working tree, you
+should tell Git where the top-level of the working tree is,
+with the `--work-tree=<path>` option (or `GIT_WORK_TREE`
+environment variable)
++
+If you just want to run git as if it was started in `<path>` then use
+`git -C <path>`.
+
+--work-tree=<path>::
+ Set the path to the working tree. It can be an absolute path
+ or a path relative to the current working directory.
+ This can also be controlled by setting the GIT_WORK_TREE
+ environment variable and the core.worktree configuration
+ variable (see core.worktree in linkgit:git-config[1] for a
+ more detailed discussion).
+
+--namespace=<path>::
+ Set the Git namespace. See linkgit:gitnamespaces[7] for more
+ details. Equivalent to setting the `GIT_NAMESPACE` environment
+ variable.
+
+--bare::
+ Treat the repository as a bare repository. If GIT_DIR
+ environment is not set, it is set to the current working
+ directory.
+
+--no-replace-objects::
+ Do not use replacement refs to replace Git objects.
+ This is equivalent to exporting the `GIT_NO_REPLACE_OBJECTS`
+ environment variable with any value.
+ See linkgit:git-replace[1] for more information.
+
+--no-lazy-fetch::
+ Do not fetch missing objects from the promisor remote on
+ demand. Useful together with `git cat-file -e <object>` to
+ see if the object is locally available.
+ This is equivalent to setting the `GIT_NO_LAZY_FETCH`
+ environment variable to `1`.
+
+--no-optional-locks::
+ Do not perform optional operations that require locks. This is
+ equivalent to setting the `GIT_OPTIONAL_LOCKS` to `0`.
+
+--no-advice::
+ Disable all advice hints from being printed.
+
+--literal-pathspecs::
+ Treat pathspecs literally (i.e. no globbing, no pathspec magic).
+ This is equivalent to setting the `GIT_LITERAL_PATHSPECS` environment
+ variable to `1`.
+
+--glob-pathspecs::
+ Add "glob" magic to all pathspec. This is equivalent to setting
+ the `GIT_GLOB_PATHSPECS` environment variable to `1`. Disabling
+ globbing on individual pathspecs can be done using pathspec
+ magic ":(literal)"
+
+--noglob-pathspecs::
+ Add "literal" magic to all pathspec. This is equivalent to setting
+ the `GIT_NOGLOB_PATHSPECS` environment variable to `1`. Enabling
+ globbing on individual pathspecs can be done using pathspec
+ magic ":(glob)"
+
+--icase-pathspecs::
+ Add "icase" magic to all pathspec. This is equivalent to setting
+ the `GIT_ICASE_PATHSPECS` environment variable to `1`.
+
+--list-cmds=<group>[,<group>...]::
+ List commands by group. This is an internal/experimental
+ option and may change or be removed in the future. Supported
+ groups are: builtins, parseopt (builtin commands that use
+ parse-options), main (all commands in libexec directory),
+ others (all other commands in `$PATH` that have git- prefix),
+ list-<category> (see categories in command-list.txt),
+ nohelpers (exclude helper commands), alias and config
+ (retrieve command list from config variable completion.commands)
+
+--attr-source=<tree-ish>::
+ Read gitattributes from <tree-ish> instead of the worktree. See
+ linkgit:gitattributes[5]. This is equivalent to setting the
+ `GIT_ATTR_SOURCE` environment variable.
+
+GIT COMMANDS
+------------
+
+We divide Git into high level ("porcelain") commands and low level
+("plumbing") commands.
+
+High-level commands (porcelain)
+-------------------------------
+
+We separate the porcelain commands into the main commands and some
+ancillary user utilities.
+
+Main porcelain commands
+~~~~~~~~~~~~~~~~~~~~~~~
+
+include::{build_dir}/cmds-mainporcelain.adoc[]
+
+Ancillary Commands
+~~~~~~~~~~~~~~~~~~
+Manipulators:
+
+include::{build_dir}/cmds-ancillarymanipulators.adoc[]
+
+Interrogators:
+
+include::{build_dir}/cmds-ancillaryinterrogators.adoc[]
+
+
+Interacting with Others
+~~~~~~~~~~~~~~~~~~~~~~~
+
+These commands are to interact with foreign SCM and with other
+people via patch over e-mail.
+
+include::{build_dir}/cmds-foreignscminterface.adoc[]
+
+Reset, restore and revert
+~~~~~~~~~~~~~~~~~~~~~~~~~
+There are three commands with similar names: `git reset`,
+`git restore` and `git revert`.
+
+* linkgit:git-revert[1] is about making a new commit that reverts the
+ changes made by other commits.
+
+* linkgit:git-restore[1] is about restoring files in the working tree
+ from either the index or another commit. This command does not
+ update your branch. The command can also be used to restore files in
+ the index from another commit.
+
+* linkgit:git-reset[1] is about updating your branch, moving the tip
+ in order to add or remove commits from the branch. This operation
+ changes the commit history.
++
+`git reset` can also be used to restore the index, overlapping with
+`git restore`.
+
+
+Low-level commands (plumbing)
+-----------------------------
+
+Although Git includes its
+own porcelain layer, its low-level commands are sufficient to support
+development of alternative porcelains. Developers of such porcelains
+might start by reading about linkgit:git-update-index[1] and
+linkgit:git-read-tree[1].
+
+The interface (input, output, set of options and the semantics)
+to these low-level commands are meant to be a lot more stable
+than Porcelain level commands, because these commands are
+primarily for scripted use. The interface to Porcelain commands
+on the other hand are subject to change in order to improve the
+end user experience.
+
+The following description divides
+the low-level commands into commands that manipulate objects (in
+the repository, index, and working tree), commands that interrogate and
+compare objects, and commands that move objects and references between
+repositories.
+
+
+Manipulation commands
+~~~~~~~~~~~~~~~~~~~~~
+
+include::{build_dir}/cmds-plumbingmanipulators.adoc[]
+
+
+Interrogation commands
+~~~~~~~~~~~~~~~~~~~~~~
+
+include::{build_dir}/cmds-plumbinginterrogators.adoc[]
+
+In general, the interrogate commands do not touch the files in
+the working tree.
+
+
+Syncing repositories
+~~~~~~~~~~~~~~~~~~~~
+
+include::{build_dir}/cmds-synchingrepositories.adoc[]
+
+The following are helper commands used by the above; end users
+typically do not use them directly.
+
+include::{build_dir}/cmds-synchelpers.adoc[]
+
+
+Internal helper commands
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+These are internal helper commands used by other commands; end
+users typically do not use them directly.
+
+include::{build_dir}/cmds-purehelpers.adoc[]
+
+Guides
+------
+
+The following documentation pages are guides about Git concepts.
+
+include::{build_dir}/cmds-guide.adoc[]
+
+Repository, command and file interfaces
+---------------------------------------
+
+This documentation discusses repository and command interfaces which
+users are expected to interact with directly. See `--user-formats` in
+linkgit:git-help[1] for more details on the criteria.
+
+include::{build_dir}/cmds-userinterfaces.adoc[]
+
+File formats, protocols and other developer interfaces
+------------------------------------------------------
+
+This documentation discusses file formats, over-the-wire protocols and
+other git developer interfaces. See `--developer-interfaces` in
+linkgit:git-help[1].
+
+include::{build_dir}/cmds-developerinterfaces.adoc[]
+
+Configuration Mechanism
+-----------------------
+
+Git uses a simple text format to store customizations that are per
+repository and are per user. Such a configuration file may look
+like this:
+
+------------
+#
+# A '#' or ';' character indicates a comment.
+#
+
+; core variables
+[core]
+ ; Don't trust file modes
+ filemode = false
+
+; user identity
+[user]
+ name = "Junio C Hamano"
+ email = "gitster@pobox.com"
+
+------------
+
+Various commands read from the configuration file and adjust
+their operation accordingly. See linkgit:git-config[1] for a
+list and more details about the configuration mechanism.
+
+
+Identifier Terminology
+----------------------
+<object>::
+ Indicates the object name for any type of object.
+
+<blob>::
+ Indicates a blob object name.
+
+<tree>::
+ Indicates a tree object name.
+
+<commit>::
+ Indicates a commit object name.
+
+<tree-ish>::
+ Indicates a tree, commit or tag object name. A
+ command that takes a <tree-ish> argument ultimately wants to
+ operate on a <tree> object but automatically dereferences
+ <commit> and <tag> objects that point at a <tree>.
+
+<commit-ish>::
+ Indicates a commit or tag object name. A
+ command that takes a <commit-ish> argument ultimately wants to
+ operate on a <commit> object but automatically dereferences
+ <tag> objects that point at a <commit>.
+
+<type>::
+ Indicates that an object type is required.
+ Currently one of: `blob`, `tree`, `commit`, or `tag`.
+
+<file>::
+ Indicates a filename - almost always relative to the
+ root of the tree structure `GIT_INDEX_FILE` describes.
+
+Symbolic Identifiers
+--------------------
+Any Git command accepting any <object> can also use the following
+symbolic notation:
+
+HEAD::
+ indicates the head of the current branch.
+
+<tag>::
+ a valid tag 'name'
+ (i.e. a `refs/tags/<tag>` reference).
+
+<head>::
+ a valid head 'name'
+ (i.e. a `refs/heads/<head>` reference).
+
+For a more complete list of ways to spell object names, see
+"SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
+
+
+File/Directory Structure
+------------------------
+
+Please see the linkgit:gitrepository-layout[5] document.
+
+Read linkgit:githooks[5] for more details about each hook.
+
+Higher level SCMs may provide and manage additional information in the
+`$GIT_DIR`.
+
+
+Terminology
+-----------
+Please see linkgit:gitglossary[7].
+
+
+Environment Variables
+---------------------
+Various Git commands pay attention to environment variables and change
+their behavior. The environment variables marked as "Boolean" take
+their values the same way as Boolean valued configuration variables, e.g.
+"true", "yes", "on" and positive numbers are taken as "yes".
+
+Here are the variables:
+
+System
+~~~~~~
+`HOME`::
+ Specifies the path to the user's home directory. On Windows, if
+ unset, Git will set a process environment variable equal to:
+ `$HOMEDRIVE$HOMEPATH` if both `$HOMEDRIVE` and `$HOMEPATH` exist;
+ otherwise `$USERPROFILE` if `$USERPROFILE` exists.
+
+The Git Repository
+~~~~~~~~~~~~~~~~~~
+These environment variables apply to 'all' core Git commands. Nb: it
+is worth noting that they may be used/overridden by SCMS sitting above
+Git so take care if using a foreign front-end.
+
+`GIT_INDEX_FILE`::
+ This environment variable specifies an alternate
+ index file. If not specified, the default of `$GIT_DIR/index`
+ is used.
+
+`GIT_INDEX_VERSION`::
+ This environment variable specifies what index version is used
+ when writing the index file out. It won't affect existing index
+ files. By default index file version 2 or 3 is used. See
+ linkgit:git-update-index[1] for more information.
+
+`GIT_OBJECT_DIRECTORY`::
+ If the object storage directory is specified via this
+ environment variable then the sha1 directories are created
+ underneath - otherwise the default `$GIT_DIR/objects`
+ directory is used.
+
+`GIT_ALTERNATE_OBJECT_DIRECTORIES`::
+ Due to the immutable nature of Git objects, old objects can be
+ archived into shared, read-only directories. This variable
+ specifies a ":" separated (on Windows ";" separated) list
+ of Git object directories which can be used to search for Git
+ objects. New objects will not be written to these directories.
++
+Entries that begin with `"` (double-quote) will be interpreted
+as C-style quoted paths, removing leading and trailing
+double-quotes and respecting backslash escapes. E.g., the value
+`"path-with-\"-and-:-in-it":vanilla-path` has two paths:
+`path-with-"-and-:-in-it` and `vanilla-path`.
+
+`GIT_DIR`::
+ If the `GIT_DIR` environment variable is set then it
+ specifies a path to use instead of the default `.git`
+ for the base of the repository.
+ The `--git-dir` command-line option also sets this value.
+
+`GIT_WORK_TREE`::
+ Set the path to the root of the working tree.
+ This can also be controlled by the `--work-tree` command-line
+ option and the core.worktree configuration variable.
+
+`GIT_NAMESPACE`::
+ Set the Git namespace; see linkgit:gitnamespaces[7] for details.
+ The `--namespace` command-line option also sets this value.
+
+`GIT_CEILING_DIRECTORIES`::
+ This should be a colon-separated list of absolute paths. If
+ set, it is a list of directories that Git should not chdir up
+ into while looking for a repository directory (useful for
+ excluding slow-loading network directories). It will not
+ exclude the current working directory or a GIT_DIR set on the
+ command line or in the environment. Normally, Git has to read
+ the entries in this list and resolve any symlink that
+ might be present in order to compare them with the current
+ directory. However, if even this access is slow, you
+ can add an empty entry to the list to tell Git that the
+ subsequent entries are not symlinks and needn't be resolved;
+ e.g.,
+ `GIT_CEILING_DIRECTORIES=/maybe/symlink::/very/slow/non/symlink`.
+
+`GIT_DISCOVERY_ACROSS_FILESYSTEM`::
+ When run in a directory that does not have ".git" repository
+ directory, Git tries to find such a directory in the parent
+ directories to find the top of the working tree, but by default it
+ does not cross filesystem boundaries. This Boolean environment variable
+ can be set to true to tell Git not to stop at filesystem
+ boundaries. Like `GIT_CEILING_DIRECTORIES`, this will not affect
+ an explicit repository directory set via `GIT_DIR` or on the
+ command line.
+
+`GIT_COMMON_DIR`::
+ If this variable is set to a path, non-worktree files that are
+ normally in $GIT_DIR will be taken from this path
+ instead. Worktree-specific files such as HEAD or index are
+ taken from $GIT_DIR. See linkgit:gitrepository-layout[5] and
+ linkgit:git-worktree[1] for
+ details. This variable has lower precedence than other path
+ variables such as GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY...
+
+`GIT_DEFAULT_HASH`::
+ If this variable is set, the default hash algorithm for new
+ repositories will be set to this value. This value is
+ ignored when cloning and the setting of the remote repository
+ is always used. The default is "sha1".
+ See `--object-format` in linkgit:git-init[1].
+
+`GIT_DEFAULT_REF_FORMAT`::
+ If this variable is set, the default reference backend format for new
+ repositories will be set to this value. The default is "files".
+ See `--ref-format` in linkgit:git-init[1].
+
+Git Commits
+~~~~~~~~~~~
+`GIT_AUTHOR_NAME`::
+ The human-readable name used in the author identity when creating commit or
+ tag objects, or when writing reflogs. Overrides the `user.name` and
+ `author.name` configuration settings.
+
+`GIT_AUTHOR_EMAIL`::
+ The email address used in the author identity when creating commit or
+ tag objects, or when writing reflogs. Overrides the `user.email` and
+ `author.email` configuration settings.
+
+`GIT_AUTHOR_DATE`::
+ The date used for the author identity when creating commit or tag objects, or
+ when writing reflogs. See linkgit:git-commit[1] for valid formats.
+
+`GIT_COMMITTER_NAME`::
+ The human-readable name used in the committer identity when creating commit or
+ tag objects, or when writing reflogs. Overrides the `user.name` and
+ `committer.name` configuration settings.
+
+`GIT_COMMITTER_EMAIL`::
+ The email address used in the author identity when creating commit or
+ tag objects, or when writing reflogs. Overrides the `user.email` and
+ `committer.email` configuration settings.
+
+`GIT_COMMITTER_DATE`::
+ The date used for the committer identity when creating commit or tag objects, or
+ when writing reflogs. See linkgit:git-commit[1] for valid formats.
+
+`EMAIL`::
+ The email address used in the author and committer identities if no other
+ relevant environment variable or configuration setting has been set.
+
+Git Diffs
+~~~~~~~~~
+`GIT_DIFF_OPTS`::
+ Only valid setting is "--unified=??" or "-u??" to set the
+ number of context lines shown when a unified diff is created.
+ This takes precedence over any "-U" or "--unified" option
+ value passed on the Git diff command line.
+
+`GIT_EXTERNAL_DIFF`::
+ When the environment variable `GIT_EXTERNAL_DIFF` is set, the
+ program named by it is called to generate diffs, and Git
+ does not use its builtin diff machinery.
+ For a path that is added, removed, or modified,
+ `GIT_EXTERNAL_DIFF` is called with 7 parameters:
+
+ path old-file old-hex old-mode new-file new-hex new-mode
++
+where:
+
+ <old|new>-file:: are files GIT_EXTERNAL_DIFF can use to read the
+ contents of <old|new>,
+ <old|new>-hex:: are the 40-hexdigit SHA-1 hashes,
+ <old|new>-mode:: are the octal representation of the file modes.
++
+The file parameters can point at the user's working file
+(e.g. `new-file` in "git-diff-files"), `/dev/null` (e.g. `old-file`
+when a new file is added), or a temporary file (e.g. `old-file` in the
+index). `GIT_EXTERNAL_DIFF` should not worry about unlinking the
+temporary file -- it is removed when `GIT_EXTERNAL_DIFF` exits.
++
+For a path that is unmerged, `GIT_EXTERNAL_DIFF` is called with 1
+parameter, <path>.
++
+For each path `GIT_EXTERNAL_DIFF` is called, two environment variables,
+`GIT_DIFF_PATH_COUNTER` and `GIT_DIFF_PATH_TOTAL` are set.
+
+`GIT_EXTERNAL_DIFF_TRUST_EXIT_CODE`::
+ If this Boolean environment variable is set to true then the
+ `GIT_EXTERNAL_DIFF` command is expected to return exit code
+ 0 if it considers the input files to be equal or 1 if it
+ considers them to be different, like `diff(1)`.
+ If it is set to false, which is the default, then the command
+ is expected to return exit code 0 regardless of equality.
+ Any other exit code causes Git to report a fatal error.
+
+
+`GIT_DIFF_PATH_COUNTER`::
+ A 1-based counter incremented by one for every path.
+
+`GIT_DIFF_PATH_TOTAL`::
+ The total number of paths.
+
+other
+~~~~~
+`GIT_MERGE_VERBOSITY`::
+ A number controlling the amount of output shown by
+ the recursive merge strategy. Overrides merge.verbosity.
+ See linkgit:git-merge[1]
+
+`GIT_PAGER`::
+ This environment variable overrides `$PAGER`. If it is set
+ to an empty string or to the value "cat", Git will not launch
+ a pager. See also the `core.pager` option in
+ linkgit:git-config[1].
+
+`GIT_PROGRESS_DELAY`::
+ A number controlling how many seconds to delay before showing
+ optional progress indicators. Defaults to 2.
+
+`GIT_EDITOR`::
+ This environment variable overrides `$EDITOR` and `$VISUAL`.
+ It is used by several Git commands when, on interactive mode,
+ an editor is to be launched. See also linkgit:git-var[1]
+ and the `core.editor` option in linkgit:git-config[1].
+
+`GIT_SEQUENCE_EDITOR`::
+ This environment variable overrides the configured Git editor
+ when editing the todo list of an interactive rebase. See also
+ linkgit:git-rebase[1] and the `sequence.editor` option in
+ linkgit:git-config[1].
+
+`GIT_SSH`::
+`GIT_SSH_COMMAND`::
+ If either of these environment variables is set then 'git fetch'
+ and 'git push' will use the specified command instead of 'ssh'
+ when they need to connect to a remote system.
+ The command-line parameters passed to the configured command are
+ determined by the ssh variant. See `ssh.variant` option in
+ linkgit:git-config[1] for details.
++
+`$GIT_SSH_COMMAND` takes precedence over `$GIT_SSH`, and is interpreted
+by the shell, which allows additional arguments to be included.
+`$GIT_SSH` on the other hand must be just the path to a program
+(which can be a wrapper shell script, if additional arguments are
+needed).
++
+Usually it is easier to configure any desired options through your
+personal `.ssh/config` file. Please consult your ssh documentation
+for further details.
+
+`GIT_SSH_VARIANT`::
+ If this environment variable is set, it overrides Git's autodetection
+ whether `GIT_SSH`/`GIT_SSH_COMMAND`/`core.sshCommand` refer to OpenSSH,
+ plink or tortoiseplink. This variable overrides the config setting
+ `ssh.variant` that serves the same purpose.
+
+`GIT_SSL_NO_VERIFY`::
+ Setting and exporting this environment variable to any value
+ tells Git not to verify the SSL certificate when fetching or
+ pushing over HTTPS.
+
+`GIT_ATTR_SOURCE`::
+ Sets the treeish that gitattributes will be read from.
+
+`GIT_ASKPASS`::
+ If this environment variable is set, then Git commands which need to
+ acquire passwords or passphrases (e.g. for HTTP or IMAP authentication)
+ will call this program with a suitable prompt as command-line argument
+ and read the password from its STDOUT. See also the `core.askPass`
+ option in linkgit:git-config[1].
+
+`GIT_TERMINAL_PROMPT`::
+ If this Boolean environment variable is set to false, git will not prompt
+ on the terminal (e.g., when asking for HTTP authentication).
+
+`GIT_CONFIG_GLOBAL`::
+`GIT_CONFIG_SYSTEM`::
+ Take the configuration from the given files instead from global or
+ system-level configuration files. If `GIT_CONFIG_SYSTEM` is set, the
+ system config file defined at build time (usually `/etc/gitconfig`)
+ will not be read. Likewise, if `GIT_CONFIG_GLOBAL` is set, neither
+ `$HOME/.gitconfig` nor `$XDG_CONFIG_HOME/git/config` will be read. Can
+ be set to `/dev/null` to skip reading configuration files of the
+ respective level.
+
+`GIT_CONFIG_NOSYSTEM`::
+ Whether to skip reading settings from the system-wide
+ `$(prefix)/etc/gitconfig` file. This Boolean environment variable can
+ be used along with `$HOME` and `$XDG_CONFIG_HOME` to create a
+ predictable environment for a picky script, or you can set it
+ to true to temporarily avoid using a buggy `/etc/gitconfig` file while
+ waiting for someone with sufficient permissions to fix it.
+
+`GIT_FLUSH`::
+ If this Boolean environment variable is set to true, then commands such
+ as 'git blame' (in incremental mode), 'git rev-list', 'git log',
+ 'git check-attr' and 'git check-ignore' will
+ force a flush of the output stream after each record have been
+ flushed. If this
+ variable is set to false, the output of these commands will be done
+ using completely buffered I/O. If this environment variable is
+ not set, Git will choose buffered or record-oriented flushing
+ based on whether stdout appears to be redirected to a file or not.
+
+`GIT_TRACE`::
+ Enables general trace messages, e.g. alias expansion, built-in
+ command execution and external command execution.
++
+If this variable is set to "1", "2" or "true" (comparison
+is case insensitive), trace messages will be printed to
+stderr.
++
+If the variable is set to an integer value greater than 2
+and lower than 10 (strictly) then Git will interpret this
+value as an open file descriptor and will try to write the
+trace messages into this file descriptor.
++
+Alternatively, if the variable is set to an absolute path
+(starting with a '/' character), Git will interpret this
+as a file path and will try to append the trace messages
+to it.
++
+Unsetting the variable, or setting it to empty, "0" or
+"false" (case insensitive) disables trace messages.
+
+`GIT_TRACE_FSMONITOR`::
+ Enables trace messages for the filesystem monitor extension.
+ See `GIT_TRACE` for available trace output options.
+
+`GIT_TRACE_PACK_ACCESS`::
+ Enables trace messages for all accesses to any packs. For each
+ access, the pack file name and an offset in the pack is
+ recorded. This may be helpful for troubleshooting some
+ pack-related performance problems.
+ See `GIT_TRACE` for available trace output options.
+
+`GIT_TRACE_PACKET`::
+ Enables trace messages for all packets coming in or out of a
+ given program. This can help with debugging object negotiation
+ or other protocol issues. Tracing is turned off at a packet
+ starting with "PACK" (but see `GIT_TRACE_PACKFILE` below).
+ See `GIT_TRACE` for available trace output options.
+
+`GIT_TRACE_PACKFILE`::
+ Enables tracing of packfiles sent or received by a
+ given program. Unlike other trace output, this trace is
+ verbatim: no headers, and no quoting of binary data. You almost
+ certainly want to direct into a file (e.g.,
+ `GIT_TRACE_PACKFILE=/tmp/my.pack`) rather than displaying it on
+ the terminal or mixing it with other trace output.
++
+Note that this is currently only implemented for the client side
+of clones and fetches.
+
+`GIT_TRACE_PERFORMANCE`::
+ Enables performance related trace messages, e.g. total execution
+ time of each Git command.
+ See `GIT_TRACE` for available trace output options.
+
+`GIT_TRACE_REFS`::
+ Enables trace messages for operations on the ref database.
+ See `GIT_TRACE` for available trace output options.
+
+`GIT_TRACE_SETUP`::
+ Enables trace messages printing the .git, working tree and current
+ working directory after Git has completed its setup phase.
+ See `GIT_TRACE` for available trace output options.
+
+`GIT_TRACE_SHALLOW`::
+ Enables trace messages that can help debugging fetching /
+ cloning of shallow repositories.
+ See `GIT_TRACE` for available trace output options.
+
+`GIT_TRACE_CURL`::
+ Enables a curl full trace dump of all incoming and outgoing data,
+ including descriptive information, of the git transport protocol.
+ This is similar to doing curl `--trace-ascii` on the command line.
+ See `GIT_TRACE` for available trace output options.
+
+`GIT_TRACE_CURL_NO_DATA`::
+ When a curl trace is enabled (see `GIT_TRACE_CURL` above), do not dump
+ data (that is, only dump info lines and headers).
+
+`GIT_TRACE2`::
+ Enables more detailed trace messages from the "trace2" library.
+ Output from `GIT_TRACE2` is a simple text-based format for human
+ readability.
++
+If this variable is set to "1", "2" or "true" (comparison
+is case insensitive), trace messages will be printed to
+stderr.
++
+If the variable is set to an integer value greater than 2
+and lower than 10 (strictly) then Git will interpret this
+value as an open file descriptor and will try to write the
+trace messages into this file descriptor.
++
+Alternatively, if the variable is set to an absolute path
+(starting with a '/' character), Git will interpret this
+as a file path and will try to append the trace messages
+to it. If the path already exists and is a directory, the
+trace messages will be written to files (one per process)
+in that directory, named according to the last component
+of the SID and an optional counter (to avoid filename
+collisions).
++
+In addition, if the variable is set to
+`af_unix:[<socket-type>:]<absolute-pathname>`, Git will try
+to open the path as a Unix Domain Socket. The socket type
+can be either `stream` or `dgram`.
++
+Unsetting the variable, or setting it to empty, "0" or
+"false" (case insensitive) disables trace messages.
++
+See link:technical/api-trace2.html[Trace2 documentation]
+for full details.
+
+
+`GIT_TRACE2_EVENT`::
+ This setting writes a JSON-based format that is suited for machine
+ interpretation.
+ See `GIT_TRACE2` for available trace output options and
+ link:technical/api-trace2.html[Trace2 documentation] for full details.
+
+`GIT_TRACE2_PERF`::
+ In addition to the text-based messages available in `GIT_TRACE2`, this
+ setting writes a column-based format for understanding nesting
+ regions.
+ See `GIT_TRACE2` for available trace output options and
+ link:technical/api-trace2.html[Trace2 documentation] for full details.
+
+`GIT_TRACE_REDACT`::
+ By default, when tracing is activated, Git redacts the values of
+ cookies, the "Authorization:" header, the "Proxy-Authorization:"
+ header and packfile URIs. Set this Boolean environment variable to false to prevent this
+ redaction.
+
+`GIT_NO_REPLACE_OBJECTS`::
+ Setting and exporting this environment variable tells Git to
+ ignore replacement refs and do not replace Git objects.
+
+`GIT_LITERAL_PATHSPECS`::
+ Setting this Boolean environment variable to true will cause Git to treat all
+ pathspecs literally, rather than as glob patterns. For example,
+ running `GIT_LITERAL_PATHSPECS=1 git log -- '*.c'` will search
+ for commits that touch the path `*.c`, not any paths that the
+ glob `*.c` matches. You might want this if you are feeding
+ literal paths to Git (e.g., paths previously given to you by
+ `git ls-tree`, `--raw` diff output, etc).
+
+`GIT_GLOB_PATHSPECS`::
+ Setting this Boolean environment variable to true will cause Git to treat all
+ pathspecs as glob patterns (aka "glob" magic).
+
+`GIT_NOGLOB_PATHSPECS`::
+ Setting this Boolean environment variable to true will cause Git to treat all
+ pathspecs as literal (aka "literal" magic).
+
+`GIT_ICASE_PATHSPECS`::
+ Setting this Boolean environment variable to true will cause Git to treat all
+ pathspecs as case-insensitive.
+
+`GIT_NO_LAZY_FETCH`::
+ Setting this Boolean environment variable to true tells Git
+ not to lazily fetch missing objects from the promisor remote
+ on demand.
+
+`GIT_REFLOG_ACTION`::
+ When a ref is updated, reflog entries are created to keep
+ track of the reason why the ref was updated (which is
+ typically the name of the high-level command that updated
+ the ref), in addition to the old and new values of the ref.
+ A scripted Porcelain command can use set_reflog_action
+ helper function in `git-sh-setup` to set its name to this
+ variable when it is invoked as the top level command by the
+ end user, to be recorded in the body of the reflog.
+
+`GIT_REF_PARANOIA`::
+ If this Boolean environment variable is set to false, ignore broken or badly named refs when iterating
+ over lists of refs. Normally Git will try to include any such
+ refs, which may cause some operations to fail. This is usually
+ preferable, as potentially destructive operations (e.g.,
+ linkgit:git-prune[1]) are better off aborting rather than
+ ignoring broken refs (and thus considering the history they
+ point to as not worth saving). The default value is `1` (i.e.,
+ be paranoid about detecting and aborting all operations). You
+ should not normally need to set this to `0`, but it may be
+ useful when trying to salvage data from a corrupted repository.
+
+`GIT_COMMIT_GRAPH_PARANOIA`::
+ When loading a commit object from the commit-graph, Git performs an
+ existence check on the object in the object database. This is done to
+ avoid issues with stale commit-graphs that contain references to
+ already-deleted commits, but comes with a performance penalty.
++
+The default is "false", which disables the aforementioned behavior.
+Setting this to "true" enables the existence check so that stale commits
+will never be returned from the commit-graph at the cost of performance.
+
+`GIT_ALLOW_PROTOCOL`::
+ If set to a colon-separated list of protocols, behave as if
+ `protocol.allow` is set to `never`, and each of the listed
+ protocols has `protocol.<name>.allow` set to `always`
+ (overriding any existing configuration). See the description of
+ `protocol.allow` in linkgit:git-config[1] for more details.
+
+`GIT_PROTOCOL_FROM_USER`::
+ Set this Boolean environment variable to false to prevent protocols used by fetch/push/clone which are
+ configured to the `user` state. This is useful to restrict recursive
+ submodule initialization from an untrusted repository or for programs
+ which feed potentially-untrusted URLS to git commands. See
+ linkgit:git-config[1] for more details.
+
+`GIT_PROTOCOL`::
+ For internal use only. Used in handshaking the wire protocol.
+ Contains a colon ':' separated list of keys with optional values
+ '<key>[=<value>]'. Presence of unknown keys and values must be
+ ignored.
++
+Note that servers may need to be configured to allow this variable to
+pass over some transports. It will be propagated automatically when
+accessing local repositories (i.e., `file://` or a filesystem path), as
+well as over the `git://` protocol. For git-over-http, it should work
+automatically in most configurations, but see the discussion in
+linkgit:git-http-backend[1]. For git-over-ssh, the ssh server may need
+to be configured to allow clients to pass this variable (e.g., by using
+`AcceptEnv GIT_PROTOCOL` with OpenSSH).
++
+This configuration is optional. If the variable is not propagated, then
+clients will fall back to the original "v0" protocol (but may miss out
+on some performance improvements or features). This variable currently
+only affects clones and fetches; it is not yet used for pushes (but may
+be in the future).
+
+`GIT_OPTIONAL_LOCKS`::
+ If this Boolean environment variable is set to false, Git will complete any requested operation without
+ performing any optional sub-operations that require taking a lock.
+ For example, this will prevent `git status` from refreshing the
+ index as a side effect. This is useful for processes running in
+ the background which do not want to cause lock contention with
+ other operations on the repository. Defaults to `1`.
+
+`GIT_REDIRECT_STDIN`::
+`GIT_REDIRECT_STDOUT`::
+`GIT_REDIRECT_STDERR`::
+ Windows-only: allow redirecting the standard input/output/error
+ handles to paths specified by the environment variables. This is
+ particularly useful in multi-threaded applications where the
+ canonical way to pass standard handles via `CreateProcess()` is
+ not an option because it would require the handles to be marked
+ inheritable (and consequently *every* spawned process would
+ inherit them, possibly blocking regular Git operations). The
+ primary intended use case is to use named pipes for communication
+ (e.g. `\\.\pipe\my-git-stdin-123`).
++
+Two special values are supported: `off` will simply close the
+corresponding standard handle, and if `GIT_REDIRECT_STDERR` is
+`2>&1`, standard error will be redirected to the same handle as
+standard output.
+
+`GIT_PRINT_SHA1_ELLIPSIS` (deprecated)::
+ If set to `yes`, print an ellipsis following an
+ (abbreviated) SHA-1 value. This affects indications of
+ detached HEADs (linkgit:git-checkout[1]) and the raw
+ diff output (linkgit:git-diff[1]). Printing an
+ ellipsis in the cases mentioned is no longer considered
+ adequate and support for it is likely to be removed in the
+ foreseeable future (along with the variable).
+
+`GIT_ADVICE`::
+ If set to `0`, then disable all advice messages. These messages are
+ intended to provide hints to human users that may help them get out of
+ problematic situations or take advantage of new features. Users can
+ disable individual messages using the `advice.*` config keys. These
+ messages may be disruptive to tools that execute Git processes, so this
+ variable is available to disable the messages. (The `--no-advice`
+ global option is also available, but old Git versions may fail when
+ this option is not understood. The environment variable will be ignored
+ by Git versions that do not understand it.)
+
+Discussion[[Discussion]]
+------------------------
+
+More detail on the following is available from the
+link:user-manual.html#git-concepts[Git concepts chapter of the
+user-manual] and linkgit:gitcore-tutorial[7].
+
+A Git project normally consists of a working directory with a ".git"
+subdirectory at the top level. The .git directory contains, among other
+things, a compressed object database representing the complete history
+of the project, an "index" file which links that history to the current
+contents of the working tree, and named pointers into that history such
+as tags and branch heads.
+
+The object database contains objects of three main types: blobs, which
+hold file data; trees, which point to blobs and other trees to build up
+directory hierarchies; and commits, which each reference a single tree
+and some number of parent commits.
+
+The commit, equivalent to what other systems call a "changeset" or
+"version", represents a step in the project's history, and each parent
+represents an immediately preceding step. Commits with more than one
+parent represent merges of independent lines of development.
+
+All objects are named by the SHA-1 hash of their contents, normally
+written as a string of 40 hex digits. Such names are globally unique.
+The entire history leading up to a commit can be vouched for by signing
+just that commit. A fourth object type, the tag, is provided for this
+purpose.
+
+When first created, objects are stored in individual files, but for
+efficiency may later be compressed together into "pack files".
+
+Named pointers called refs mark interesting points in history. A ref
+may contain the SHA-1 name of an object or the name of another ref (the
+latter is called a "symbolic ref").
+Refs with names beginning `refs/head/` contain the SHA-1 name of the most
+recent commit (or "head") of a branch under development. SHA-1 names of
+tags of interest are stored under `refs/tags/`. A symbolic ref named
+`HEAD` contains the name of the currently checked-out branch.
+
+The index file is initialized with a list of all paths and, for each
+path, a blob object and a set of attributes. The blob object represents
+the contents of the file as of the head of the current branch. The
+attributes (last modified time, size, etc.) are taken from the
+corresponding file in the working tree. Subsequent changes to the
+working tree can be found by comparing these attributes. The index may
+be updated with new content, and new commits may be created from the
+content stored in the index.
+
+The index is also capable of storing multiple entries (called "stages")
+for a given pathname. These stages are used to hold the various
+unmerged version of a file when a merge is in progress.
+
+SECURITY
+--------
+
+Some configuration options and hook files may cause Git to run arbitrary
+shell commands. Because configuration and hooks are not copied using
+`git clone`, it is generally safe to clone remote repositories with
+untrusted content, inspect them with `git log`, and so on.
+
+However, it is not safe to run Git commands in a `.git` directory (or
+the working tree that surrounds it) when that `.git` directory itself
+comes from an untrusted source. The commands in its config and hooks
+are executed in the usual way.
+
+By default, Git will refuse to run when the repository is owned by
+someone other than the user running the command. See the entry for
+`safe.directory` in linkgit:git-config[1]. While this can help protect
+you in a multi-user environment, note that you can also acquire
+untrusted repositories that are owned by you (for example, if you
+extract a zip file or tarball from an untrusted source). In such cases,
+you'd need to "sanitize" the untrusted repository first.
+
+If you have an untrusted `.git` directory, you should first clone it
+with `git clone --no-local` to obtain a clean copy. Git does restrict
+the set of options and hooks that will be run by `upload-pack`, which
+handles the server side of a clone or fetch, but beware that the
+surface area for attack against `upload-pack` is large, so this does
+carry some risk. The safest thing is to serve the repository as an
+unprivileged user (either via linkgit:git-daemon[1], ssh, or using
+other tools to change user ids). See the discussion in the `SECURITY`
+section of linkgit:git-upload-pack[1].
+
+FURTHER DOCUMENTATION
+---------------------
+
+See the references in the "description" section to get started
+using Git. The following is probably more detail than necessary
+for a first-time user.
+
+The link:user-manual.html#git-concepts[Git concepts chapter of the
+user-manual] and linkgit:gitcore-tutorial[7] both provide
+introductions to the underlying Git architecture.
+
+See linkgit:gitworkflows[7] for an overview of recommended workflows.
+
+See also the link:howto-index.html[howto] documents for some useful
+examples.
+
+The internals are documented in the
+link:technical/api-index.html[Git API documentation].
+
+Users migrating from CVS may also want to
+read linkgit:gitcvs-migration[7].
+
+
+Authors
+-------
+Git was started by Linus Torvalds, and is currently maintained by Junio
+C Hamano. Numerous contributions have come from the Git mailing list
+<git@vger.kernel.org>. https://openhub.net/p/git/contributors/summary
+gives you a more complete list of contributors.
+
+If you have a clone of git.git itself, the
+output of linkgit:git-shortlog[1] and linkgit:git-blame[1] can show you
+the authors for specific parts of the project.
+
+Reporting Bugs
+--------------
+
+Report bugs to the Git mailing list <git@vger.kernel.org> where the
+development and maintenance is primarily done. You do not have to be
+subscribed to the list to send a message there. See the list archive
+at https://lore.kernel.org/git for previous bug reports and other
+discussions.
+
+Issues which are security relevant should be disclosed privately to
+the Git Security mailing list <git-security@googlegroups.com>.
+
+SEE ALSO
+--------
+linkgit:gittutorial[7], linkgit:gittutorial-2[7],
+linkgit:giteveryday[7], linkgit:gitcvs-migration[7],
+linkgit:gitglossary[7], linkgit:gitcore-tutorial[7],
+linkgit:gitcli[7], link:user-manual.html[The Git User's Manual],
+linkgit:gitworkflows[7]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitattributes.adoc b/gitattributes.adoc
new file mode 100644
index 0000000..5d12b78
--- /dev/null
+++ b/gitattributes.adoc
@@ -0,0 +1,1374 @@
+gitattributes(5)
+================
+
+NAME
+----
+gitattributes - Defining attributes per path
+
+SYNOPSIS
+--------
+$GIT_DIR/info/attributes, .gitattributes
+
+
+DESCRIPTION
+-----------
+
+A `gitattributes` file is a simple text file that gives
+`attributes` to pathnames.
+
+Each line in `gitattributes` file is of form:
+
+ pattern attr1 attr2 ...
+
+That is, a pattern followed by an attributes list,
+separated by whitespaces. Leading and trailing whitespaces are
+ignored. Lines that begin with '#' are ignored. Patterns
+that begin with a double quote are quoted in C style.
+When the pattern matches the path in question, the attributes
+listed on the line are given to the path.
+
+Each attribute can be in one of these states for a given path:
+
+Set::
+
+ The path has the attribute with special value "true";
+ this is specified by listing only the name of the
+ attribute in the attribute list.
+
+Unset::
+
+ The path has the attribute with special value "false";
+ this is specified by listing the name of the attribute
+ prefixed with a dash `-` in the attribute list.
+
+Set to a value::
+
+ The path has the attribute with specified string value;
+ this is specified by listing the name of the attribute
+ followed by an equal sign `=` and its value in the
+ attribute list.
+
+Unspecified::
+
+ No pattern matches the path, and nothing says if
+ the path has or does not have the attribute, the
+ attribute for the path is said to be Unspecified.
+
+When more than one pattern matches the path, a later line
+overrides an earlier line. This overriding is done per
+attribute.
+
+The rules by which the pattern matches paths are the same as in
+`.gitignore` files (see linkgit:gitignore[5]), with a few exceptions:
+
+ - negative patterns are forbidden
+
+ - patterns that match a directory do not recursively match paths
+ inside that directory (so using the trailing-slash `path/` syntax is
+ pointless in an attributes file; use `path/**` instead)
+
+When deciding what attributes are assigned to a path, Git
+consults `$GIT_DIR/info/attributes` file (which has the highest
+precedence), `.gitattributes` file in the same directory as the
+path in question, and its parent directories up to the toplevel of the
+work tree (the further the directory that contains `.gitattributes`
+is from the path in question, the lower its precedence). Finally
+global and system-wide files are considered (they have the lowest
+precedence).
+
+When the `.gitattributes` file is missing from the work tree, the
+path in the index is used as a fall-back. During checkout process,
+`.gitattributes` in the index is used and then the file in the
+working tree is used as a fall-back.
+
+If you wish to affect only a single repository (i.e., to assign
+attributes to files that are particular to
+one user's workflow for that repository), then
+attributes should be placed in the `$GIT_DIR/info/attributes` file.
+Attributes which should be version-controlled and distributed to other
+repositories (i.e., attributes of interest to all users) should go into
+`.gitattributes` files. Attributes that should affect all repositories
+for a single user should be placed in a file specified by the
+`core.attributesFile` configuration option (see linkgit:git-config[1]).
+Its default value is $XDG_CONFIG_HOME/git/attributes. If $XDG_CONFIG_HOME
+is either not set or empty, $HOME/.config/git/attributes is used instead.
+Attributes for all users on a system should be placed in the
+`$(prefix)/etc/gitattributes` file.
+
+Sometimes you would need to override a setting of an attribute
+for a path to `Unspecified` state. This can be done by listing
+the name of the attribute prefixed with an exclamation point `!`.
+
+
+RESERVED BUILTIN_* ATTRIBUTES
+-----------------------------
+
+builtin_* is a reserved namespace for builtin attribute values. Any
+user defined attributes under this namespace will be ignored and
+trigger a warning.
+
+`builtin_objectmode`
+~~~~~~~~~~~~~~~~~~~~
+This attribute is for filtering files by their file bit modes (40000,
+120000, 160000, 100755, 100644). e.g. ':(attr:builtin_objectmode=160000)'.
+You may also check these values with `git check-attr builtin_objectmode -- <file>`.
+If the object is not in the index `git check-attr --cached` will return unspecified.
+
+
+EFFECTS
+-------
+
+Certain operations by Git can be influenced by assigning
+particular attributes to a path. Currently, the following
+operations are attributes-aware.
+
+Checking-out and checking-in
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+These attributes affect how the contents stored in the
+repository are copied to the working tree files when commands
+such as 'git switch', 'git checkout' and 'git merge' run.
+They also affect how
+Git stores the contents you prepare in the working tree in the
+repository upon 'git add' and 'git commit'.
+
+`text`
+^^^^^^
+
+This attribute marks the path as a text file, which enables end-of-line
+conversion: When a matching file is added to the index, the file's line
+endings are normalized to LF in the index. Conversely, when the file is
+copied from the index to the working directory, its line endings may be
+converted from LF to CRLF depending on the `eol` attribute, the Git
+config, and the platform (see explanation of `eol` below).
+
+Set::
+
+ Setting the `text` attribute on a path enables end-of-line
+ conversion on checkin and checkout as described above. Line endings
+ are normalized to LF in the index every time the file is checked in,
+ even if the file was previously added to Git with CRLF line endings.
+
+Unset::
+
+ Unsetting the `text` attribute on a path tells Git not to
+ attempt any end-of-line conversion upon checkin or checkout.
+
+Set to string value "auto"::
+
+ When `text` is set to "auto", Git decides by itself whether the file
+ is text or binary. If it is text and the file was not already in
+ Git with CRLF endings, line endings are converted on checkin and
+ checkout as described above. Otherwise, no conversion is done on
+ checkin or checkout.
+
+Unspecified::
+
+ If the `text` attribute is unspecified, Git uses the
+ `core.autocrlf` configuration variable to determine if the
+ file should be converted.
+
+Any other value causes Git to act as if `text` has been left
+unspecified.
+
+`eol`
+^^^^^
+
+This attribute marks a path to use a specific line-ending style in the
+working tree when it is checked out. It has effect only if `text` or
+`text=auto` is set (see above), but specifying `eol` automatically sets
+`text` if `text` was left unspecified.
+
+Set to string value "crlf"::
+
+ This setting converts the file's line endings in the working
+ directory to CRLF when the file is checked out.
+
+Set to string value "lf"::
+
+ This setting uses the same line endings in the working directory as
+ in the index when the file is checked out.
+
+Unspecified::
+
+ If the `eol` attribute is unspecified for a file, its line endings
+ in the working directory are determined by the `core.autocrlf` or
+ `core.eol` configuration variable (see the definitions of those
+ options in linkgit:git-config[1]). If `text` is set but neither of
+ those variables is, the default is `eol=crlf` on Windows and
+ `eol=lf` on all other platforms.
+
+Backwards compatibility with `crlf` attribute
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+For backwards compatibility, the `crlf` attribute is interpreted as
+follows:
+
+------------------------
+crlf text
+-crlf -text
+crlf=input eol=lf
+------------------------
+
+End-of-line conversion
+^^^^^^^^^^^^^^^^^^^^^^
+
+While Git normally leaves file contents alone, it can be configured to
+normalize line endings to LF in the repository and, optionally, to
+convert them to CRLF when files are checked out.
+
+If you simply want to have CRLF line endings in your working directory
+regardless of the repository you are working with, you can set the
+config variable "core.autocrlf" without using any attributes.
+
+------------------------
+[core]
+ autocrlf = true
+------------------------
+
+This does not force normalization of text files, but does ensure
+that text files that you introduce to the repository have their line
+endings normalized to LF when they are added, and that files that are
+already normalized in the repository stay normalized.
+
+If you want to ensure that text files that any contributor introduces to
+the repository have their line endings normalized, you can set the
+`text` attribute to "auto" for _all_ files.
+
+------------------------
+* text=auto
+------------------------
+
+The attributes allow a fine-grained control, how the line endings
+are converted.
+Here is an example that will make Git normalize .txt, .vcproj and .sh
+files, ensure that .vcproj files have CRLF and .sh files have LF in
+the working directory, and prevent .jpg files from being normalized
+regardless of their content.
+
+------------------------
+* text=auto
+*.txt text
+*.vcproj text eol=crlf
+*.sh text eol=lf
+*.jpg -text
+------------------------
+
+NOTE: When `text=auto` conversion is enabled in a cross-platform
+project using push and pull to a central repository the text files
+containing CRLFs should be normalized.
+
+From a clean working directory:
+
+-------------------------------------------------
+$ echo "* text=auto" >.gitattributes
+$ git add --renormalize .
+$ git status # Show files that will be normalized
+$ git commit -m "Introduce end-of-line normalization"
+-------------------------------------------------
+
+If any files that should not be normalized show up in 'git status',
+unset their `text` attribute before running 'git add -u'.
+
+------------------------
+manual.pdf -text
+------------------------
+
+Conversely, text files that Git does not detect can have normalization
+enabled manually.
+
+------------------------
+weirdchars.txt text
+------------------------
+
+If `core.safecrlf` is set to "true" or "warn", Git verifies if
+the conversion is reversible for the current setting of
+`core.autocrlf`. For "true", Git rejects irreversible
+conversions; for "warn", Git only prints a warning but accepts
+an irreversible conversion. The safety triggers to prevent such
+a conversion done to the files in the work tree, but there are a
+few exceptions. Even though...
+
+- 'git add' itself does not touch the files in the work tree, the
+ next checkout would, so the safety triggers;
+
+- 'git apply' to update a text file with a patch does touch the files
+ in the work tree, but the operation is about text files and CRLF
+ conversion is about fixing the line ending inconsistencies, so the
+ safety does not trigger;
+
+- 'git diff' itself does not touch the files in the work tree, it is
+ often run to inspect the changes you intend to next 'git add'. To
+ catch potential problems early, safety triggers.
+
+
+`working-tree-encoding`
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Git recognizes files encoded in ASCII or one of its supersets (e.g.
+UTF-8, ISO-8859-1, ...) as text files. Files encoded in certain other
+encodings (e.g. UTF-16) are interpreted as binary and consequently
+built-in Git text processing tools (e.g. 'git diff') as well as most Git
+web front ends do not visualize the contents of these files by default.
+
+In these cases you can tell Git the encoding of a file in the working
+directory with the `working-tree-encoding` attribute. If a file with this
+attribute is added to Git, then Git re-encodes the content from the
+specified encoding to UTF-8. Finally, Git stores the UTF-8 encoded
+content in its internal data structure (called "the index"). On checkout
+the content is re-encoded back to the specified encoding.
+
+Please note that using the `working-tree-encoding` attribute may have a
+number of pitfalls:
+
+- Alternative Git implementations (e.g. JGit or libgit2) and older Git
+ versions (as of March 2018) do not support the `working-tree-encoding`
+ attribute. If you decide to use the `working-tree-encoding` attribute
+ in your repository, then it is strongly recommended to ensure that all
+ clients working with the repository support it.
++
+For example, Microsoft Visual Studio resources files (`*.rc`) or
+PowerShell script files (`*.ps1`) are sometimes encoded in UTF-16.
+If you declare `*.ps1` as files as UTF-16 and you add `foo.ps1` with
+a `working-tree-encoding` enabled Git client, then `foo.ps1` will be
+stored as UTF-8 internally. A client without `working-tree-encoding`
+support will checkout `foo.ps1` as UTF-8 encoded file. This will
+typically cause trouble for the users of this file.
++
+If a Git client that does not support the `working-tree-encoding`
+attribute adds a new file `bar.ps1`, then `bar.ps1` will be
+stored "as-is" internally (in this example probably as UTF-16).
+A client with `working-tree-encoding` support will interpret the
+internal contents as UTF-8 and try to convert it to UTF-16 on checkout.
+That operation will fail and cause an error.
+
+- Reencoding content to non-UTF encodings can cause errors as the
+ conversion might not be UTF-8 round trip safe. If you suspect your
+ encoding to not be round trip safe, then add it to
+ `core.checkRoundtripEncoding` to make Git check the round trip
+ encoding (see linkgit:git-config[1]). SHIFT-JIS (Japanese character
+ set) is known to have round trip issues with UTF-8 and is checked by
+ default.
+
+- Reencoding content requires resources that might slow down certain
+ Git operations (e.g 'git checkout' or 'git add').
+
+Use the `working-tree-encoding` attribute only if you cannot store a file
+in UTF-8 encoding and if you want Git to be able to process the content
+as text.
+
+As an example, use the following attributes if your '*.ps1' files are
+UTF-16 encoded with byte order mark (BOM) and you want Git to perform
+automatic line ending conversion based on your platform.
+
+------------------------
+*.ps1 text working-tree-encoding=UTF-16
+------------------------
+
+Use the following attributes if your '*.ps1' files are UTF-16 little
+endian encoded without BOM and you want Git to use Windows line endings
+in the working directory (use `UTF-16LE-BOM` instead of `UTF-16LE` if
+you want UTF-16 little endian with BOM).
+Please note, it is highly recommended to
+explicitly define the line endings with `eol` if the `working-tree-encoding`
+attribute is used to avoid ambiguity.
+
+------------------------
+*.ps1 text working-tree-encoding=UTF-16LE eol=crlf
+------------------------
+
+You can get a list of all available encodings on your platform with the
+following command:
+
+------------------------
+iconv --list
+------------------------
+
+If you do not know the encoding of a file, then you can use the `file`
+command to guess the encoding:
+
+------------------------
+file foo.ps1
+------------------------
+
+
+`ident`
+^^^^^^^
+
+When the attribute `ident` is set for a path, Git replaces
+`$Id$` in the blob object with `$Id:`, followed by the
+40-character hexadecimal blob object name, followed by a dollar
+sign `$` upon checkout. Any byte sequence that begins with
+`$Id:` and ends with `$` in the worktree file is replaced
+with `$Id$` upon check-in.
+
+
+`filter`
+^^^^^^^^
+
+A `filter` attribute can be set to a string value that names a
+filter driver specified in the configuration.
+
+A filter driver consists of a `clean` command and a `smudge`
+command, either of which can be left unspecified. Upon
+checkout, when the `smudge` command is specified, the command is
+fed the blob object from its standard input, and its standard
+output is used to update the worktree file. Similarly, the
+`clean` command is used to convert the contents of worktree file
+upon checkin. By default these commands process only a single
+blob and terminate. If a long running `process` filter is used
+in place of `clean` and/or `smudge` filters, then Git can process
+all blobs with a single filter command invocation for the entire
+life of a single Git command, for example `git add --all`. If a
+long running `process` filter is configured then it always takes
+precedence over a configured single blob filter. See section
+below for the description of the protocol used to communicate with
+a `process` filter.
+
+One use of the content filtering is to massage the content into a shape
+that is more convenient for the platform, filesystem, and the user to use.
+For this mode of operation, the key phrase here is "more convenient" and
+not "turning something unusable into usable". In other words, the intent
+is that if someone unsets the filter driver definition, or does not have
+the appropriate filter program, the project should still be usable.
+
+Another use of the content filtering is to store the content that cannot
+be directly used in the repository (e.g. a UUID that refers to the true
+content stored outside Git, or an encrypted content) and turn it into a
+usable form upon checkout (e.g. download the external content, or decrypt
+the encrypted content).
+
+These two filters behave differently, and by default, a filter is taken as
+the former, massaging the contents into more convenient shape. A missing
+filter driver definition in the config, or a filter driver that exits with
+a non-zero status, is not an error but makes the filter a no-op passthru.
+
+You can declare that a filter turns a content that by itself is unusable
+into a usable content by setting the filter.<driver>.required configuration
+variable to `true`.
+
+Note: Whenever the clean filter is changed, the repo should be renormalized:
+$ git add --renormalize .
+
+For example, in .gitattributes, you would assign the `filter`
+attribute for paths.
+
+------------------------
+*.c filter=indent
+------------------------
+
+Then you would define a "filter.indent.clean" and "filter.indent.smudge"
+configuration in your .git/config to specify a pair of commands to
+modify the contents of C programs when the source files are checked
+in ("clean" is run) and checked out (no change is made because the
+command is "cat").
+
+------------------------
+[filter "indent"]
+ clean = indent
+ smudge = cat
+------------------------
+
+For best results, `clean` should not alter its output further if it is
+run twice ("clean->clean" should be equivalent to "clean"), and
+multiple `smudge` commands should not alter `clean`'s output
+("smudge->smudge->clean" should be equivalent to "clean"). See the
+section on merging below.
+
+The "indent" filter is well-behaved in this regard: it will not modify
+input that is already correctly indented. In this case, the lack of a
+smudge filter means that the clean filter _must_ accept its own output
+without modifying it.
+
+If a filter _must_ succeed in order to make the stored contents usable,
+you can declare that the filter is `required`, in the configuration:
+
+------------------------
+[filter "crypt"]
+ clean = openssl enc ...
+ smudge = openssl enc -d ...
+ required
+------------------------
+
+Sequence "%f" on the filter command line is replaced with the name of
+the file the filter is working on. A filter might use this in keyword
+substitution. For example:
+
+------------------------
+[filter "p4"]
+ clean = git-p4-filter --clean %f
+ smudge = git-p4-filter --smudge %f
+------------------------
+
+Note that "%f" is the name of the path that is being worked on. Depending
+on the version that is being filtered, the corresponding file on disk may
+not exist, or may have different contents. So, smudge and clean commands
+should not try to access the file on disk, but only act as filters on the
+content provided to them on standard input.
+
+Long Running Filter Process
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+If the filter command (a string value) is defined via
+`filter.<driver>.process` then Git can process all blobs with a
+single filter invocation for the entire life of a single Git
+command. This is achieved by using the long-running process protocol
+(described in technical/long-running-process-protocol.txt).
+
+When Git encounters the first file that needs to be cleaned or smudged,
+it starts the filter and performs the handshake. In the handshake, the
+welcome message sent by Git is "git-filter-client", only version 2 is
+supported, and the supported capabilities are "clean", "smudge", and
+"delay".
+
+Afterwards Git sends a list of "key=value" pairs terminated with
+a flush packet. The list will contain at least the filter command
+(based on the supported capabilities) and the pathname of the file
+to filter relative to the repository root. Right after the flush packet
+Git sends the content split in zero or more pkt-line packets and a
+flush packet to terminate content. Please note, that the filter
+must not send any response before it received the content and the
+final flush packet. Also note that the "value" of a "key=value" pair
+can contain the "=" character whereas the key would never contain
+that character.
+------------------------
+packet: git> command=smudge
+packet: git> pathname=path/testfile.dat
+packet: git> 0000
+packet: git> CONTENT
+packet: git> 0000
+------------------------
+
+The filter is expected to respond with a list of "key=value" pairs
+terminated with a flush packet. If the filter does not experience
+problems then the list must contain a "success" status. Right after
+these packets the filter is expected to send the content in zero
+or more pkt-line packets and a flush packet at the end. Finally, a
+second list of "key=value" pairs terminated with a flush packet
+is expected. The filter can change the status in the second list
+or keep the status as is with an empty list. Please note that the
+empty list must be terminated with a flush packet regardless.
+
+------------------------
+packet: git< status=success
+packet: git< 0000
+packet: git< SMUDGED_CONTENT
+packet: git< 0000
+packet: git< 0000 # empty list, keep "status=success" unchanged!
+------------------------
+
+If the result content is empty then the filter is expected to respond
+with a "success" status and a flush packet to signal the empty content.
+------------------------
+packet: git< status=success
+packet: git< 0000
+packet: git< 0000 # empty content!
+packet: git< 0000 # empty list, keep "status=success" unchanged!
+------------------------
+
+In case the filter cannot or does not want to process the content,
+it is expected to respond with an "error" status.
+------------------------
+packet: git< status=error
+packet: git< 0000
+------------------------
+
+If the filter experiences an error during processing, then it can
+send the status "error" after the content was (partially or
+completely) sent.
+------------------------
+packet: git< status=success
+packet: git< 0000
+packet: git< HALF_WRITTEN_ERRONEOUS_CONTENT
+packet: git< 0000
+packet: git< status=error
+packet: git< 0000
+------------------------
+
+In case the filter cannot or does not want to process the content
+as well as any future content for the lifetime of the Git process,
+then it is expected to respond with an "abort" status at any point
+in the protocol.
+------------------------
+packet: git< status=abort
+packet: git< 0000
+------------------------
+
+Git neither stops nor restarts the filter process in case the
+"error"/"abort" status is set. However, Git sets its exit code
+according to the `filter.<driver>.required` flag, mimicking the
+behavior of the `filter.<driver>.clean` / `filter.<driver>.smudge`
+mechanism.
+
+If the filter dies during the communication or does not adhere to
+the protocol then Git will stop the filter process and restart it
+with the next file that needs to be processed. Depending on the
+`filter.<driver>.required` flag Git will interpret that as error.
+
+Delay
+^^^^^
+
+If the filter supports the "delay" capability, then Git can send the
+flag "can-delay" after the filter command and pathname. This flag
+denotes that the filter can delay filtering the current blob (e.g. to
+compensate network latencies) by responding with no content but with
+the status "delayed" and a flush packet.
+------------------------
+packet: git> command=smudge
+packet: git> pathname=path/testfile.dat
+packet: git> can-delay=1
+packet: git> 0000
+packet: git> CONTENT
+packet: git> 0000
+packet: git< status=delayed
+packet: git< 0000
+------------------------
+
+If the filter supports the "delay" capability then it must support the
+"list_available_blobs" command. If Git sends this command, then the
+filter is expected to return a list of pathnames representing blobs
+that have been delayed earlier and are now available.
+The list must be terminated with a flush packet followed
+by a "success" status that is also terminated with a flush packet. If
+no blobs for the delayed paths are available, yet, then the filter is
+expected to block the response until at least one blob becomes
+available. The filter can tell Git that it has no more delayed blobs
+by sending an empty list. As soon as the filter responds with an empty
+list, Git stops asking. All blobs that Git has not received at this
+point are considered missing and will result in an error.
+
+------------------------
+packet: git> command=list_available_blobs
+packet: git> 0000
+packet: git< pathname=path/testfile.dat
+packet: git< pathname=path/otherfile.dat
+packet: git< 0000
+packet: git< status=success
+packet: git< 0000
+------------------------
+
+After Git received the pathnames, it will request the corresponding
+blobs again. These requests contain a pathname and an empty content
+section. The filter is expected to respond with the smudged content
+in the usual way as explained above.
+------------------------
+packet: git> command=smudge
+packet: git> pathname=path/testfile.dat
+packet: git> 0000
+packet: git> 0000 # empty content!
+packet: git< status=success
+packet: git< 0000
+packet: git< SMUDGED_CONTENT
+packet: git< 0000
+packet: git< 0000 # empty list, keep "status=success" unchanged!
+------------------------
+
+Example
+^^^^^^^
+
+A long running filter demo implementation can be found in
+`contrib/long-running-filter/example.pl` located in the Git
+core repository. If you develop your own long running filter
+process then the `GIT_TRACE_PACKET` environment variables can be
+very helpful for debugging (see linkgit:git[1]).
+
+Please note that you cannot use an existing `filter.<driver>.clean`
+or `filter.<driver>.smudge` command with `filter.<driver>.process`
+because the former two use a different inter process communication
+protocol than the latter one.
+
+
+Interaction between checkin/checkout attributes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In the check-in codepath, the worktree file is first converted
+with `filter` driver (if specified and corresponding driver
+defined), then the result is processed with `ident` (if
+specified), and then finally with `text` (again, if specified
+and applicable).
+
+In the check-out codepath, the blob content is first converted
+with `text`, and then `ident` and fed to `filter`.
+
+
+Merging branches with differing checkin/checkout attributes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+If you have added attributes to a file that cause the canonical
+repository format for that file to change, such as adding a
+clean/smudge filter or text/eol/ident attributes, merging anything
+where the attribute is not in place would normally cause merge
+conflicts.
+
+To prevent these unnecessary merge conflicts, Git can be told to run a
+virtual check-out and check-in of all three stages of a file when
+resolving a three-way merge by setting the `merge.renormalize`
+configuration variable. This prevents changes caused by check-in
+conversion from causing spurious merge conflicts when a converted file
+is merged with an unconverted file.
+
+As long as a "smudge->clean" results in the same output as a "clean"
+even on files that are already smudged, this strategy will
+automatically resolve all filter-related conflicts. Filters that do
+not act in this way may cause additional merge conflicts that must be
+resolved manually.
+
+
+Generating diff text
+~~~~~~~~~~~~~~~~~~~~
+
+`diff`
+^^^^^^
+
+The attribute `diff` affects how Git generates diffs for particular
+files. It can tell Git whether to generate a textual patch for the path
+or to treat the path as a binary file. It can also affect what line is
+shown on the hunk header `@@ -k,l +n,m @@` line, tell Git to use an
+external command to generate the diff, or ask Git to convert binary
+files to a text format before generating the diff.
+
+Set::
+
+ A path to which the `diff` attribute is set is treated
+ as text, even when they contain byte values that
+ normally never appear in text files, such as NUL.
+
+Unset::
+
+ A path to which the `diff` attribute is unset will
+ generate `Binary files differ` (or a binary patch, if
+ binary patches are enabled).
+
+Unspecified::
+
+ A path to which the `diff` attribute is unspecified
+ first gets its contents inspected, and if it looks like
+ text and is smaller than core.bigFileThreshold, it is treated
+ as text. Otherwise it would generate `Binary files differ`.
+
+String::
+
+ Diff is shown using the specified diff driver. Each driver may
+ specify one or more options, as described in the following
+ section. The options for the diff driver "foo" are defined
+ by the configuration variables in the "diff.foo" section of the
+ Git config file.
+
+
+Defining an external diff driver
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The definition of a diff driver is done in `gitconfig`, not
+`gitattributes` file, so strictly speaking this manual page is a
+wrong place to talk about it. However...
+
+To define an external diff driver `jcdiff`, add a section to your
+`$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this:
+
+----------------------------------------------------------------
+[diff "jcdiff"]
+ command = j-c-diff
+----------------------------------------------------------------
+
+When Git needs to show you a diff for the path with `diff`
+attribute set to `jcdiff`, it calls the command you specified
+with the above configuration, i.e. `j-c-diff`, with 7
+parameters, just like `GIT_EXTERNAL_DIFF` program is called.
+See linkgit:git[1] for details.
+
+If the program is able to ignore certain changes (similar to
+`git diff --ignore-space-change`), then also set the option
+`trustExitCode` to true. It is then expected to return exit code 1 if
+it finds significant changes and 0 if it doesn't.
+
+Setting the internal diff algorithm
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The diff algorithm can be set through the `diff.algorithm` config key, but
+sometimes it may be helpful to set the diff algorithm per path. For example,
+one may want to use the `minimal` diff algorithm for .json files, and the
+`histogram` for .c files, and so on without having to pass in the algorithm
+through the command line each time.
+
+First, in `.gitattributes`, assign the `diff` attribute for paths.
+
+------------------------
+*.json diff=<name>
+------------------------
+
+Then, define a "diff.<name>.algorithm" configuration to specify the diff
+algorithm, choosing from `myers`, `patience`, `minimal`, or `histogram`.
+
+----------------------------------------------------------------
+[diff "<name>"]
+ algorithm = histogram
+----------------------------------------------------------------
+
+This diff algorithm applies to user facing diff output like git-diff(1),
+git-show(1) and is used for the `--stat` output as well. The merge machinery
+will not use the diff algorithm set through this method.
+
+NOTE: If `diff.<name>.command` is defined for path with the
+`diff=<name>` attribute, it is executed as an external diff driver
+(see above), and adding `diff.<name>.algorithm` has no effect, as the
+algorithm is not passed to the external diff driver.
+
+Defining a custom hunk-header
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Each group of changes (called a "hunk") in the textual diff output
+is prefixed with a line of the form:
+
+ @@ -k,l +n,m @@ TEXT
+
+This is called a 'hunk header'. The "TEXT" portion is by default a line
+that begins with an alphabet, an underscore or a dollar sign; this
+matches what GNU 'diff -p' output uses. This default selection however
+is not suited for some contents, and you can use a customized pattern
+to make a selection.
+
+First, in .gitattributes, you would assign the `diff` attribute
+for paths.
+
+------------------------
+*.tex diff=tex
+------------------------
+
+Then, you would define a "diff.tex.xfuncname" configuration to
+specify a regular expression that matches a line that you would
+want to appear as the hunk header "TEXT". Add a section to your
+`$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this:
+
+------------------------
+[diff "tex"]
+ xfuncname = "^(\\\\(sub)*section\\{.*)$"
+------------------------
+
+Note. A single level of backslashes are eaten by the
+configuration file parser, so you would need to double the
+backslashes; the pattern above picks a line that begins with a
+backslash, and zero or more occurrences of `sub` followed by
+`section` followed by open brace, to the end of line.
+
+There are a few built-in patterns to make this easier, and `tex`
+is one of them, so you do not have to write the above in your
+configuration file (you still need to enable this with the
+attribute mechanism, via `.gitattributes`). The following built in
+patterns are available:
+
+- `ada` suitable for source code in the Ada language.
+
+- `bash` suitable for source code in the Bourne-Again SHell language.
+ Covers a superset of POSIX shell function definitions.
+
+- `bibtex` suitable for files with BibTeX coded references.
+
+- `cpp` suitable for source code in the C and C++ languages.
+
+- `csharp` suitable for source code in the C# language.
+
+- `css` suitable for cascading style sheets.
+
+- `dts` suitable for devicetree (DTS) files.
+
+- `elixir` suitable for source code in the Elixir language.
+
+- `fortran` suitable for source code in the Fortran language.
+
+- `fountain` suitable for Fountain documents.
+
+- `golang` suitable for source code in the Go language.
+
+- `html` suitable for HTML/XHTML documents.
+
+- `java` suitable for source code in the Java language.
+
+- `kotlin` suitable for source code in the Kotlin language.
+
+- `markdown` suitable for Markdown documents.
+
+- `matlab` suitable for source code in the MATLAB and Octave languages.
+
+- `objc` suitable for source code in the Objective-C language.
+
+- `pascal` suitable for source code in the Pascal/Delphi language.
+
+- `perl` suitable for source code in the Perl language.
+
+- `php` suitable for source code in the PHP language.
+
+- `python` suitable for source code in the Python language.
+
+- `ruby` suitable for source code in the Ruby language.
+
+- `rust` suitable for source code in the Rust language.
+
+- `scheme` suitable for source code in the Scheme language.
+
+- `tex` suitable for source code for LaTeX documents.
+
+
+Customizing word diff
+^^^^^^^^^^^^^^^^^^^^^
+
+You can customize the rules that `git diff --word-diff` uses to
+split words in a line, by specifying an appropriate regular expression
+in the "diff.*.wordRegex" configuration variable. For example, in TeX
+a backslash followed by a sequence of letters forms a command, but
+several such commands can be run together without intervening
+whitespace. To separate them, use a regular expression in your
+`$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this:
+
+------------------------
+[diff "tex"]
+ wordRegex = "\\\\[a-zA-Z]+|[{}]|\\\\.|[^\\{}[:space:]]+"
+------------------------
+
+A built-in pattern is provided for all languages listed in the
+previous section.
+
+
+Performing text diffs of binary files
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Sometimes it is desirable to see the diff of a text-converted
+version of some binary files. For example, a word processor
+document can be converted to an ASCII text representation, and
+the diff of the text shown. Even though this conversion loses
+some information, the resulting diff is useful for human
+viewing (but cannot be applied directly).
+
+The `textconv` config option is used to define a program for
+performing such a conversion. The program should take a single
+argument, the name of a file to convert, and produce the
+resulting text on stdout.
+
+For example, to show the diff of the exif information of a
+file instead of the binary information (assuming you have the
+exif tool installed), add the following section to your
+`$GIT_DIR/config` file (or `$HOME/.gitconfig` file):
+
+------------------------
+[diff "jpg"]
+ textconv = exif
+------------------------
+
+NOTE: The text conversion is generally a one-way conversion;
+in this example, we lose the actual image contents and focus
+just on the text data. This means that diffs generated by
+textconv are _not_ suitable for applying. For this reason,
+only `git diff` and the `git log` family of commands (i.e.,
+log, whatchanged, show) will perform text conversion. `git
+format-patch` will never generate this output. If you want to
+send somebody a text-converted diff of a binary file (e.g.,
+because it quickly conveys the changes you have made), you
+should generate it separately and send it as a comment _in
+addition to_ the usual binary diff that you might send.
+
+Because text conversion can be slow, especially when doing a
+large number of them with `git log -p`, Git provides a mechanism
+to cache the output and use it in future diffs. To enable
+caching, set the "cachetextconv" variable in your diff driver's
+config. For example:
+
+------------------------
+[diff "jpg"]
+ textconv = exif
+ cachetextconv = true
+------------------------
+
+This will cache the result of running "exif" on each blob
+indefinitely. If you change the textconv config variable for a
+diff driver, Git will automatically invalidate the cache entries
+and re-run the textconv filter. If you want to invalidate the
+cache manually (e.g., because your version of "exif" was updated
+and now produces better output), you can remove the cache
+manually with `git update-ref -d refs/notes/textconv/jpg` (where
+"jpg" is the name of the diff driver, as in the example above).
+
+Choosing textconv versus external diff
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+If you want to show differences between binary or specially-formatted
+blobs in your repository, you can choose to use either an external diff
+command, or to use textconv to convert them to a diff-able text format.
+Which method you choose depends on your exact situation.
+
+The advantage of using an external diff command is flexibility. You are
+not bound to find line-oriented changes, nor is it necessary for the
+output to resemble unified diff. You are free to locate and report
+changes in the most appropriate way for your data format.
+
+A textconv, by comparison, is much more limiting. You provide a
+transformation of the data into a line-oriented text format, and Git
+uses its regular diff tools to generate the output. There are several
+advantages to choosing this method:
+
+1. Ease of use. It is often much simpler to write a binary to text
+ transformation than it is to perform your own diff. In many cases,
+ existing programs can be used as textconv filters (e.g., exif,
+ odt2txt).
+
+2. Git diff features. By performing only the transformation step
+ yourself, you can still utilize many of Git's diff features,
+ including colorization, word-diff, and combined diffs for merges.
+
+3. Caching. Textconv caching can speed up repeated diffs, such as those
+ you might trigger by running `git log -p`.
+
+
+Marking files as binary
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Git usually guesses correctly whether a blob contains text or binary
+data by examining the beginning of the contents. However, sometimes you
+may want to override its decision, either because a blob contains binary
+data later in the file, or because the content, while technically
+composed of text characters, is opaque to a human reader. For example,
+many postscript files contain only ASCII characters, but produce noisy
+and meaningless diffs.
+
+The simplest way to mark a file as binary is to unset the diff
+attribute in the `.gitattributes` file:
+
+------------------------
+*.ps -diff
+------------------------
+
+This will cause Git to generate `Binary files differ` (or a binary
+patch, if binary patches are enabled) instead of a regular diff.
+
+However, one may also want to specify other diff driver attributes. For
+example, you might want to use `textconv` to convert postscript files to
+an ASCII representation for human viewing, but otherwise treat them as
+binary files. You cannot specify both `-diff` and `diff=ps` attributes.
+The solution is to use the `diff.*.binary` config option:
+
+------------------------
+[diff "ps"]
+ textconv = ps2ascii
+ binary = true
+------------------------
+
+Performing a three-way merge
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+`merge`
+^^^^^^^
+
+The attribute `merge` affects how three versions of a file are
+merged when a file-level merge is necessary during `git merge`,
+and other commands such as `git revert` and `git cherry-pick`.
+
+Set::
+
+ Built-in 3-way merge driver is used to merge the
+ contents in a way similar to 'merge' command of `RCS`
+ suite. This is suitable for ordinary text files.
+
+Unset::
+
+ Take the version from the current branch as the
+ tentative merge result, and declare that the merge has
+ conflicts. This is suitable for binary files that do
+ not have a well-defined merge semantics.
+
+Unspecified::
+
+ By default, this uses the same built-in 3-way merge
+ driver as is the case when the `merge` attribute is set.
+ However, the `merge.default` configuration variable can name
+ different merge driver to be used with paths for which the
+ `merge` attribute is unspecified.
+
+String::
+
+ 3-way merge is performed using the specified custom
+ merge driver. The built-in 3-way merge driver can be
+ explicitly specified by asking for "text" driver; the
+ built-in "take the current branch" driver can be
+ requested with "binary".
+
+
+Built-in merge drivers
+^^^^^^^^^^^^^^^^^^^^^^
+
+There are a few built-in low-level merge drivers defined that
+can be asked for via the `merge` attribute.
+
+text::
+
+ Usual 3-way file level merge for text files. Conflicted
+ regions are marked with conflict markers `<<<<<<<`,
+ `=======` and `>>>>>>>`. The version from your branch
+ appears before the `=======` marker, and the version
+ from the merged branch appears after the `=======`
+ marker.
+
+binary::
+
+ Keep the version from your branch in the work tree, but
+ leave the path in the conflicted state for the user to
+ sort out.
+
+union::
+
+ Run 3-way file level merge for text files, but take
+ lines from both versions, instead of leaving conflict
+ markers. This tends to leave the added lines in the
+ resulting file in random order and the user should
+ verify the result. Do not use this if you do not
+ understand the implications.
+
+
+Defining a custom merge driver
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The definition of a merge driver is done in the `.git/config`
+file, not in the `gitattributes` file, so strictly speaking this
+manual page is a wrong place to talk about it. However...
+
+To define a custom merge driver `filfre`, add a section to your
+`$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this:
+
+----------------------------------------------------------------
+[merge "filfre"]
+ name = feel-free merge driver
+ driver = filfre %O %A %B %L %P
+ recursive = binary
+----------------------------------------------------------------
+
+The `merge.*.name` variable gives the driver a human-readable
+name.
+
+The `merge.*.driver` variable's value is used to construct a
+command to run to common ancestor's version (`%O`), current
+version (`%A`) and the other branches' version (`%B`). These
+three tokens are replaced with the names of temporary files that
+hold the contents of these versions when the command line is
+built. Additionally, `%L` will be replaced with the conflict marker
+size (see below).
+
+The merge driver is expected to leave the result of the merge in
+the file named with `%A` by overwriting it, and exit with zero
+status if it managed to merge them cleanly, or non-zero if there
+were conflicts. When the driver crashes (e.g. killed by SEGV),
+it is expected to exit with non-zero status that are higher than
+128, and in such a case, the merge results in a failure (which is
+different from producing a conflict).
+
+The `merge.*.recursive` variable specifies what other merge
+driver to use when the merge driver is called for an internal
+merge between common ancestors, when there are more than one.
+When left unspecified, the driver itself is used for both
+internal merge and the final merge.
+
+The merge driver can learn the pathname in which the merged result
+will be stored via placeholder `%P`. The conflict labels to be used
+for the common ancestor, local head and other head can be passed by
+using `%S`, `%X` and `%Y` respectively.
+
+`conflict-marker-size`
+^^^^^^^^^^^^^^^^^^^^^^
+
+This attribute controls the length of conflict markers left in
+the work tree file during a conflicted merge. Only a positive
+integer has a meaningful effect.
+
+For example, this line in `.gitattributes` can be used to tell the merge
+machinery to leave much longer (instead of the usual 7-character-long)
+conflict markers when merging the file `Documentation/git-merge.txt`
+results in a conflict.
+
+------------------------
+Documentation/git-merge.txt conflict-marker-size=32
+------------------------
+
+
+Checking whitespace errors
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+`whitespace`
+^^^^^^^^^^^^
+
+The `core.whitespace` configuration variable allows you to define what
+'diff' and 'apply' should consider whitespace errors for all paths in
+the project (See linkgit:git-config[1]). This attribute gives you finer
+control per path.
+
+Set::
+
+ Notice all types of potential whitespace errors known to Git.
+ The tab width is taken from the value of the `core.whitespace`
+ configuration variable.
+
+Unset::
+
+ Do not notice anything as error.
+
+Unspecified::
+
+ Use the value of the `core.whitespace` configuration variable to
+ decide what to notice as error.
+
+String::
+
+ Specify a comma separated list of common whitespace problems to
+ notice in the same format as the `core.whitespace` configuration
+ variable.
+
+
+Creating an archive
+~~~~~~~~~~~~~~~~~~~
+
+`export-ignore`
+^^^^^^^^^^^^^^^
+
+Files and directories with the attribute `export-ignore` won't be added to
+archive files.
+
+`export-subst`
+^^^^^^^^^^^^^^
+
+If the attribute `export-subst` is set for a file then Git will expand
+several placeholders when adding this file to an archive. The
+expansion depends on the availability of a commit ID, i.e., if
+linkgit:git-archive[1] has been given a tree instead of a commit or a
+tag then no replacement will be done. The placeholders are the same
+as those for the option `--pretty=format:` of linkgit:git-log[1],
+except that they need to be wrapped like this: `$Format:PLACEHOLDERS$`
+in the file. E.g. the string `$Format:%H$` will be replaced by the
+commit hash. However, only one `%(describe)` placeholder is expanded
+per archive to avoid denial-of-service attacks.
+
+
+Packing objects
+~~~~~~~~~~~~~~~
+
+`delta`
+^^^^^^^
+
+Delta compression will not be attempted for blobs for paths with the
+attribute `delta` set to false.
+
+
+Viewing files in GUI tools
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+`encoding`
+^^^^^^^^^^
+
+The value of this attribute specifies the character encoding that should
+be used by GUI tools (e.g. linkgit:gitk[1] and linkgit:git-gui[1]) to
+display the contents of the relevant file. Note that due to performance
+considerations linkgit:gitk[1] does not use this attribute unless you
+manually enable per-file encodings in its options.
+
+If this attribute is not set or has an invalid value, the value of the
+`gui.encoding` configuration variable is used instead
+(See linkgit:git-config[1]).
+
+
+USING MACRO ATTRIBUTES
+----------------------
+
+You do not want any end-of-line conversions applied to, nor textual diffs
+produced for, any binary file you track. You would need to specify e.g.
+
+------------
+*.jpg -text -diff
+------------
+
+but that may become cumbersome, when you have many attributes. Using
+macro attributes, you can define an attribute that, when set, also
+sets or unsets a number of other attributes at the same time. The
+system knows a built-in macro attribute, `binary`:
+
+------------
+*.jpg binary
+------------
+
+Setting the "binary" attribute also unsets the "text" and "diff"
+attributes as above. Note that macro attributes can only be "Set",
+though setting one might have the effect of setting or unsetting other
+attributes or even returning other attributes to the "Unspecified"
+state.
+
+
+DEFINING MACRO ATTRIBUTES
+-------------------------
+
+Custom macro attributes can be defined only in top-level gitattributes
+files (`$GIT_DIR/info/attributes`, the `.gitattributes` file at the
+top level of the working tree, or the global or system-wide
+gitattributes files), not in `.gitattributes` files in working tree
+subdirectories. The built-in macro attribute "binary" is equivalent
+to:
+
+------------
+[attr]binary -diff -merge -text
+------------
+
+NOTES
+-----
+
+Git does not follow symbolic links when accessing a `.gitattributes`
+file in the working tree. This keeps behavior consistent when the file
+is accessed from the index or a tree versus from the filesystem.
+
+EXAMPLES
+--------
+
+If you have these three `gitattributes` file:
+
+----------------------------------------------------------------
+(in $GIT_DIR/info/attributes)
+
+a* foo !bar -baz
+
+(in .gitattributes)
+abc foo bar baz
+
+(in t/.gitattributes)
+ab* merge=filfre
+abc -foo -bar
+*.c frotz
+----------------------------------------------------------------
+
+the attributes given to path `t/abc` are computed as follows:
+
+1. By examining `t/.gitattributes` (which is in the same
+ directory as the path in question), Git finds that the first
+ line matches. `merge` attribute is set. It also finds that
+ the second line matches, and attributes `foo` and `bar`
+ are unset.
+
+2. Then it examines `.gitattributes` (which is in the parent
+ directory), and finds that the first line matches, but
+ `t/.gitattributes` file already decided how `merge`, `foo`
+ and `bar` attributes should be given to this path, so it
+ leaves `foo` and `bar` unset. Attribute `baz` is set.
+
+3. Finally it examines `$GIT_DIR/info/attributes`. This file
+ is used to override the in-tree settings. The first line is
+ a match, and `foo` is set, `bar` is reverted to unspecified
+ state, and `baz` is unset.
+
+As the result, the attributes assignment to `t/abc` becomes:
+
+----------------------------------------------------------------
+foo set to true
+bar unspecified
+baz set to false
+merge set to string value "filfre"
+frotz unspecified
+----------------------------------------------------------------
+
+
+SEE ALSO
+--------
+linkgit:git-check-attr[1].
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitcli.adoc b/gitcli.adoc
new file mode 100644
index 0000000..04193ec
--- /dev/null
+++ b/gitcli.adoc
@@ -0,0 +1,269 @@
+gitcli(7)
+=========
+
+NAME
+----
+gitcli - Git command-line interface and conventions
+
+SYNOPSIS
+--------
+gitcli
+
+
+DESCRIPTION
+-----------
+
+This manual describes the convention used throughout Git CLI.
+
+Many commands take revisions (most often "commits", but sometimes
+"tree-ish", depending on the context and command) and paths as their
+arguments. Here are the rules:
+
+ * Options come first and then args.
+ A subcommand may take dashed options (which may take their own
+ arguments, e.g. "--max-parents 2") and arguments. You SHOULD
+ give dashed options first and then arguments. Some commands may
+ accept dashed options after you have already given non-option
+ arguments (which may make the command ambiguous), but you should
+ not rely on it (because eventually we may find a way to fix
+ these ambiguities by enforcing the "options then args" rule).
+
+ * Revisions come first and then paths.
+ E.g. in `git diff v1.0 v2.0 arch/x86 include/asm-x86`,
+ `v1.0` and `v2.0` are revisions and `arch/x86` and `include/asm-x86`
+ are paths.
+
+ * When an argument can be misunderstood as either a revision or a path,
+ they can be disambiguated by placing `--` between them.
+ E.g. `git diff -- HEAD` is, "I have a file called HEAD in my work
+ tree. Please show changes between the version I staged in the index
+ and what I have in the work tree for that file", not "show the difference
+ between the HEAD commit and the work tree as a whole". You can say
+ `git diff HEAD --` to ask for the latter.
+
+ * Without disambiguating `--`, Git makes a reasonable guess, but errors
+ out and asks you to disambiguate when ambiguous. E.g. if you have a
+ file called HEAD in your work tree, `git diff HEAD` is ambiguous, and
+ you have to say either `git diff HEAD --` or `git diff -- HEAD` to
+ disambiguate.
+
+ * Because `--` disambiguates revisions and paths in some commands, it
+ cannot be used for those commands to separate options and revisions.
+ You can use `--end-of-options` for this (it also works for commands
+ that do not distinguish between revisions in paths, in which case it
+ is simply an alias for `--`).
++
+When writing a script that is expected to handle random user-input, it is
+a good practice to make it explicit which arguments are which by placing
+disambiguating `--` at appropriate places.
+
+ * Many commands allow wildcards in paths, but you need to protect
+ them from getting globbed by the shell. These two mean different
+ things:
++
+--------------------------------
+$ git restore *.c
+$ git restore \*.c
+--------------------------------
++
+The former lets your shell expand the fileglob, and you are asking
+the dot-C files in your working tree to be overwritten with the version
+in the index. The latter passes the `*.c` to Git, and you are asking
+the paths in the index that match the pattern to be checked out to your
+working tree. After running `git add hello.c; rm hello.c`, you will _not_
+see `hello.c` in your working tree with the former, but with the latter
+you will.
+
+ * Just as the filesystem '.' (period) refers to the current directory,
+ using a '.' as a repository name in Git (a dot-repository) is a relative
+ path and means your current repository.
+
+Here are the rules regarding the "flags" that you should follow when you are
+scripting Git:
+
+ * Splitting short options to separate words (prefer `git foo -a -b`
+ to `git foo -ab`, the latter may not even work).
+
+ * When a command-line option takes an argument, use the 'stuck' form. In
+ other words, write `git foo -oArg` instead of `git foo -o Arg` for short
+ options, and `git foo --long-opt=Arg` instead of `git foo --long-opt Arg`
+ for long options. An option that takes optional option-argument must be
+ written in the 'stuck' form.
+
+ * Despite the above suggestion, when Arg is a path relative to the
+ home directory of a user, e.g. `~/directory/file` or `~u/d/f`, you
+ may want to use the separate form, e.g. `git foo --file ~/mine`,
+ not `git foo --file=~/mine`. The shell will expand `~/` in the
+ former to your home directory, but most shells keep the tilde in
+ the latter. Some of our commands know how to tilde-expand the
+ option value even when given in the stuck form, but not all of
+ them do.
+
+ * When you give a revision parameter to a command, make sure the parameter is
+ not ambiguous with a name of a file in the work tree. E.g. do not write
+ `git log -1 HEAD` but write `git log -1 HEAD --`; the former will not work
+ if you happen to have a file called `HEAD` in the work tree.
+
+ * Many commands allow a long option `--option` to be abbreviated
+ only to their unique prefix (e.g. if there is no other option
+ whose name begins with `opt`, you may be able to spell `--opt` to
+ invoke the `--option` flag), but you should fully spell them out
+ when writing your scripts; later versions of Git may introduce a
+ new option whose name shares the same prefix, e.g. `--optimize`,
+ to make a short prefix that used to be unique no longer unique.
+
+
+ENHANCED OPTION PARSER
+----------------------
+From the Git 1.5.4 series and further, many Git commands (not all of them at the
+time of the writing though) come with an enhanced option parser.
+
+Here is a list of the facilities provided by this option parser.
+
+
+Magic Options
+~~~~~~~~~~~~~
+Commands which have the enhanced option parser activated all understand a
+couple of magic command-line options:
+
+-h::
+ gives a pretty printed usage of the command.
++
+---------------------------------------------
+$ git describe -h
+usage: git describe [<options>] <commit-ish>*
+ or: git describe [<options>] --dirty
+
+ --contains find the tag that comes after the commit
+ --debug debug search strategy on stderr
+ --all use any ref
+ --tags use any tag, even unannotated
+ --long always use long format
+ --abbrev[=<n>] use <n> digits to display SHA-1s
+---------------------------------------------
++
+Note that some subcommand (e.g. `git grep`) may behave differently
+when there are things on the command line other than `-h`, but `git
+subcmd -h` without anything else on the command line is meant to
+consistently give the usage.
+
+--help-all::
+ Some Git commands take options that are only used for plumbing or that
+ are deprecated, and such options are hidden from the default usage. This
+ option gives the full list of options.
+
+
+Negating options
+~~~~~~~~~~~~~~~~
+Options with long option names can be negated by prefixing `--no-`. For
+example, `git branch` has the option `--track` which is 'on' by default. You
+can use `--no-track` to override that behaviour. The same goes for `--color`
+and `--no-color`.
+
+
+Options trump configuration and environment
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When there is a configuration variable or an environment variable
+that tweak the behaviour of an aspect of a Git command, and also a
+command line option that tweaks the same, the command line option
+overrides what the configuration and/or environment variable say.
+
+For example, the `user.name` configuration variable is used to
+specify the human-readable name used by the `git commit` command to
+record the author and the committer name in a newly created commit.
+The `GIT_AUTHOR_NAME` environment variable, if set, takes precedence
+when deciding what author name to record. The `--author=<author>`
+command line option of the `git commit` command, when given, takes
+precedence over these two sources of information.
+
+
+Aggregating short options
+~~~~~~~~~~~~~~~~~~~~~~~~~
+Commands that support the enhanced option parser allow you to aggregate short
+options. This means that you can for example use `git rm -rf` or
+`git clean -fdx`.
+
+
+Abbreviating long options
+~~~~~~~~~~~~~~~~~~~~~~~~~
+Commands that support the enhanced option parser accepts unique
+prefix of a long option as if it is fully spelled out, but use this
+with a caution. For example, `git commit --amen` behaves as if you
+typed `git commit --amend`, but that is true only until a later version
+of Git introduces another option that shares the same prefix,
+e.g. `git commit --amenity` option.
+
+
+Separating argument from the option
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+You can write the mandatory option parameter to an option as a separate
+word on the command line. That means that all the following uses work:
+
+----------------------------
+$ git foo --long-opt=Arg
+$ git foo --long-opt Arg
+$ git foo -oArg
+$ git foo -o Arg
+----------------------------
+
+However, this is *NOT* allowed for switches with an optional value, where the
+'stuck' form must be used:
+----------------------------
+$ git describe --abbrev HEAD # correct
+$ git describe --abbrev=10 HEAD # correct
+$ git describe --abbrev 10 HEAD # NOT WHAT YOU MEANT
+----------------------------
+
+
+NOTES ON FREQUENTLY CONFUSED OPTIONS
+------------------------------------
+
+Many commands that can work on files in the working tree
+and/or in the index can take `--cached` and/or `--index`
+options. Sometimes people incorrectly think that, because
+the index was originally called cache, these two are
+synonyms. They are *not* -- these two options mean very
+different things.
+
+ * The `--cached` option is used to ask a command that
+ usually works on files in the working tree to *only* work
+ with the index. For example, `git grep`, when used
+ without a commit to specify from which commit to look for
+ strings in, usually works on files in the working tree,
+ but with the `--cached` option, it looks for strings in
+ the index.
+
+ * The `--index` option is used to ask a command that
+ usually works on files in the working tree to *also*
+ affect the index. For example, `git stash apply` usually
+ merges changes recorded in a stash entry to the working tree,
+ but with the `--index` option, it also merges changes to
+ the index as well.
+
+`git apply` command can be used with `--cached` and
+`--index` (but not at the same time). Usually the command
+only affects the files in the working tree, but with
+`--index`, it patches both the files and their index
+entries, and with `--cached`, it modifies only the index
+entries.
+
+See also https://lore.kernel.org/git/7v64clg5u9.fsf@assigned-by-dhcp.cox.net/ and
+https://lore.kernel.org/git/7vy7ej9g38.fsf@gitster.siamese.dyndns.org/ for further
+information.
+
+Some other commands that also work on files in the working tree and/or
+in the index can take `--staged` and/or `--worktree`.
+
+* `--staged` is exactly like `--cached`, which is used to ask a
+ command to only work on the index, not the working tree.
+
+* `--worktree` is the opposite, to ask a command to work on the
+ working tree only, not the index.
+
+* The two options can be specified together to ask a command to work
+ on both the index and the working tree.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitcore-tutorial.adoc b/gitcore-tutorial.adoc
new file mode 100644
index 0000000..2122aeb
--- /dev/null
+++ b/gitcore-tutorial.adoc
@@ -0,0 +1,1660 @@
+gitcore-tutorial(7)
+===================
+
+NAME
+----
+gitcore-tutorial - A Git core tutorial for developers
+
+SYNOPSIS
+--------
+git *
+
+DESCRIPTION
+-----------
+
+This tutorial explains how to use the "core" Git commands to set up and
+work with a Git repository.
+
+If you just need to use Git as a revision control system you may prefer
+to start with "A Tutorial Introduction to Git" (linkgit:gittutorial[7]) or
+link:user-manual.html[the Git User Manual].
+
+However, an understanding of these low-level tools can be helpful if
+you want to understand Git's internals.
+
+The core Git is often called "plumbing", with the prettier user
+interfaces on top of it called "porcelain". You may not want to use the
+plumbing directly very often, but it can be good to know what the
+plumbing does when the porcelain isn't flushing.
+
+Back when this document was originally written, many porcelain
+commands were shell scripts. For simplicity, it still uses them as
+examples to illustrate how plumbing is fit together to form the
+porcelain commands. The source tree includes some of these scripts in
+contrib/examples/ for reference. Although these are not implemented as
+shell scripts anymore, the description of what the plumbing layer
+commands do is still valid.
+
+[NOTE]
+Deeper technical details are often marked as Notes, which you can
+skip on your first reading.
+
+
+Creating a Git repository
+-------------------------
+
+Creating a new Git repository couldn't be easier: all Git repositories start
+out empty, and the only thing you need to do is find yourself a
+subdirectory that you want to use as a working tree - either an empty
+one for a totally new project, or an existing working tree that you want
+to import into Git.
+
+For our first example, we're going to start a totally new repository from
+scratch, with no pre-existing files, and we'll call it 'git-tutorial'.
+To start up, create a subdirectory for it, change into that
+subdirectory, and initialize the Git infrastructure with 'git init':
+
+------------------------------------------------
+$ mkdir git-tutorial
+$ cd git-tutorial
+$ git init
+------------------------------------------------
+
+to which Git will reply
+
+----------------
+Initialized empty Git repository in .git/
+----------------
+
+which is just Git's way of saying that you haven't been doing anything
+strange, and that it will have created a local `.git` directory setup for
+your new project. You will now have a `.git` directory, and you can
+inspect that with 'ls'. For your new empty project, it should show you
+three entries, among other things:
+
+ - a file called `HEAD`, that has `ref: refs/heads/master` in it.
+ This is similar to a symbolic link and points at
+ `refs/heads/master` relative to the `HEAD` file.
++
+Don't worry about the fact that the file that the `HEAD` link points to
+doesn't even exist yet -- you haven't created the commit that will
+start your `HEAD` development branch yet.
+
+ - a subdirectory called `objects`, which will contain all the
+ objects of your project. You should never have any real reason to
+ look at the objects directly, but you might want to know that these
+ objects are what contains all the real 'data' in your repository.
+
+ - a subdirectory called `refs`, which contains references to objects.
+
+In particular, the `refs` subdirectory will contain two other
+subdirectories, named `heads` and `tags` respectively. They do
+exactly what their names imply: they contain references to any number
+of different 'heads' of development (aka 'branches'), and to any
+'tags' that you have created to name specific versions in your
+repository.
+
+One note: the special `master` head is the default branch, which is
+why the `.git/HEAD` file was created points to it even if it
+doesn't yet exist. Basically, the `HEAD` link is supposed to always
+point to the branch you are working on right now, and you always
+start out expecting to work on the `master` branch.
+
+However, this is only a convention, and you can name your branches
+anything you want, and don't have to ever even 'have' a `master`
+branch. A number of the Git tools will assume that `.git/HEAD` is
+valid, though.
+
+[NOTE]
+An 'object' is identified by its 160-bit SHA-1 hash, aka 'object name',
+and a reference to an object is always the 40-byte hex
+representation of that SHA-1 name. The files in the `refs`
+subdirectory are expected to contain these hex references
+(usually with a final `\n` at the end), and you should thus
+expect to see a number of 41-byte files containing these
+references in these `refs` subdirectories when you actually start
+populating your tree.
+
+[NOTE]
+An advanced user may want to take a look at linkgit:gitrepository-layout[5]
+after finishing this tutorial.
+
+You have now created your first Git repository. Of course, since it's
+empty, that's not very useful, so let's start populating it with data.
+
+
+Populating a Git repository
+---------------------------
+
+We'll keep this simple and stupid, so we'll start off with populating a
+few trivial files just to get a feel for it.
+
+Start off with just creating any random files that you want to maintain
+in your Git repository. We'll start off with a few bad examples, just to
+get a feel for how this works:
+
+------------------------------------------------
+$ echo "Hello World" >hello
+$ echo "Silly example" >example
+------------------------------------------------
+
+you have now created two files in your working tree (aka 'working directory'),
+but to actually check in your hard work, you will have to go through two steps:
+
+ - fill in the 'index' file (aka 'cache') with the information about your
+ working tree state.
+
+ - commit that index file as an object.
+
+The first step is trivial: when you want to tell Git about any changes
+to your working tree, you use the 'git update-index' program. That
+program normally just takes a list of filenames you want to update, but
+to avoid trivial mistakes, it refuses to add new entries to the index
+(or remove existing ones) unless you explicitly tell it that you're
+adding a new entry with the `--add` flag (or removing an entry with the
+`--remove`) flag.
+
+So to populate the index with the two files you just created, you can do
+
+------------------------------------------------
+$ git update-index --add hello example
+------------------------------------------------
+
+and you have now told Git to track those two files.
+
+In fact, as you did that, if you now look into your object directory,
+you'll notice that Git will have added two new objects to the object
+database. If you did exactly the steps above, you should now be able to do
+
+
+----------------
+$ ls .git/objects/??/*
+----------------
+
+and see two files:
+
+----------------
+.git/objects/55/7db03de997c86a4a028e1ebd3a1ceb225be238
+.git/objects/f2/4c74a2e500f5ee1332c86b94199f52b1d1d962
+----------------
+
+which correspond with the objects with names of `557db...` and
+`f24c7...` respectively.
+
+If you want to, you can use 'git cat-file' to look at those objects, but
+you'll have to use the object name, not the filename of the object:
+
+----------------
+$ git cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238
+----------------
+
+where the `-t` tells 'git cat-file' to tell you what the "type" of the
+object is. Git will tell you that you have a "blob" object (i.e., just a
+regular file), and you can see the contents with
+
+----------------
+$ git cat-file blob 557db03
+----------------
+
+which will print out "Hello World". The object `557db03` is nothing
+more than the contents of your file `hello`.
+
+[NOTE]
+Don't confuse that object with the file `hello` itself. The
+object is literally just those specific *contents* of the file, and
+however much you later change the contents in file `hello`, the object
+we just looked at will never change. Objects are immutable.
+
+[NOTE]
+The second example demonstrates that you can
+abbreviate the object name to only the first several
+hexadecimal digits in most places.
+
+Anyway, as we mentioned previously, you normally never actually take a
+look at the objects themselves, and typing long 40-character hex
+names is not something you'd normally want to do. The above digression
+was just to show that 'git update-index' did something magical, and
+actually saved away the contents of your files into the Git object
+database.
+
+Updating the index did something else too: it created a `.git/index`
+file. This is the index that describes your current working tree, and
+something you should be very aware of. Again, you normally never worry
+about the index file itself, but you should be aware of the fact that
+you have not actually really "checked in" your files into Git so far,
+you've only *told* Git about them.
+
+However, since Git knows about them, you can now start using some of the
+most basic Git commands to manipulate the files or look at their status.
+
+In particular, let's not even check in the two files into Git yet, we'll
+start off by adding another line to `hello` first:
+
+------------------------------------------------
+$ echo "It's a new day for git" >>hello
+------------------------------------------------
+
+and you can now, since you told Git about the previous state of `hello`, ask
+Git what has changed in the tree compared to your old index, using the
+'git diff-files' command:
+
+------------
+$ git diff-files
+------------
+
+Oops. That wasn't very readable. It just spit out its own internal
+version of a 'diff', but that internal version really just tells you
+that it has noticed that "hello" has been modified, and that the old object
+contents it had have been replaced with something else.
+
+To make it readable, we can tell 'git diff-files' to output the
+differences as a patch, using the `-p` flag:
+
+------------
+$ git diff-files -p
+diff --git a/hello b/hello
+index 557db03..263414f 100644
+--- a/hello
++++ b/hello
+@@ -1 +1,2 @@
+ Hello World
++It's a new day for git
+------------
+
+i.e. the diff of the change we caused by adding another line to `hello`.
+
+In other words, 'git diff-files' always shows us the difference between
+what is recorded in the index, and what is currently in the working
+tree. That's very useful.
+
+A common shorthand for `git diff-files -p` is to just write `git
+diff`, which will do the same thing.
+
+------------
+$ git diff
+diff --git a/hello b/hello
+index 557db03..263414f 100644
+--- a/hello
++++ b/hello
+@@ -1 +1,2 @@
+ Hello World
++It's a new day for git
+------------
+
+
+Committing Git state
+--------------------
+
+Now, we want to go to the next stage in Git, which is to take the files
+that Git knows about in the index, and commit them as a real tree. We do
+that in two phases: creating a 'tree' object, and committing that 'tree'
+object as a 'commit' object together with an explanation of what the
+tree was all about, along with information of how we came to that state.
+
+Creating a tree object is trivial, and is done with 'git write-tree'.
+There are no options or other input: `git write-tree` will take the
+current index state, and write an object that describes that whole
+index. In other words, we're now tying together all the different
+filenames with their contents (and their permissions), and we're
+creating the equivalent of a Git "directory" object:
+
+------------------------------------------------
+$ git write-tree
+------------------------------------------------
+
+and this will just output the name of the resulting tree, in this case
+(if you have done exactly as I've described) it should be
+
+----------------
+8988da15d077d4829fc51d8544c097def6644dbb
+----------------
+
+which is another incomprehensible object name. Again, if you want to,
+you can use `git cat-file -t 8988d...` to see that this time the object
+is not a "blob" object, but a "tree" object (you can also use
+`git cat-file` to actually output the raw object contents, but you'll see
+mainly a binary mess, so that's less interesting).
+
+However -- normally you'd never use 'git write-tree' on its own, because
+normally you always commit a tree into a commit object using the
+'git commit-tree' command. In fact, it's easier to not actually use
+'git write-tree' on its own at all, but to just pass its result in as an
+argument to 'git commit-tree'.
+
+'git commit-tree' normally takes several arguments -- it wants to know
+what the 'parent' of a commit was, but since this is the first commit
+ever in this new repository, and it has no parents, we only need to pass in
+the object name of the tree. However, 'git commit-tree' also wants to get a
+commit message on its standard input, and it will write out the resulting
+object name for the commit to its standard output.
+
+And this is where we create the `.git/refs/heads/master` file
+which is pointed at by `HEAD`. This file is supposed to contain
+the reference to the top-of-tree of the master branch, and since
+that's exactly what 'git commit-tree' spits out, we can do this
+all with a sequence of simple shell commands:
+
+------------------------------------------------
+$ tree=$(git write-tree)
+$ commit=$(echo 'Initial commit' | git commit-tree $tree)
+$ git update-ref HEAD $commit
+------------------------------------------------
+
+In this case this creates a totally new commit that is not related to
+anything else. Normally you do this only *once* for a project ever, and
+all later commits will be parented on top of an earlier commit.
+
+Again, normally you'd never actually do this by hand. There is a
+helpful script called `git commit` that will do all of this for you. So
+you could have just written `git commit`
+instead, and it would have done the above magic scripting for you.
+
+
+Making a change
+---------------
+
+Remember how we did the 'git update-index' on file `hello` and then we
+changed `hello` afterward, and could compare the new state of `hello` with the
+state we saved in the index file?
+
+Further, remember how I said that 'git write-tree' writes the contents
+of the *index* file to the tree, and thus what we just committed was in
+fact the *original* contents of the file `hello`, not the new ones. We did
+that on purpose, to show the difference between the index state, and the
+state in the working tree, and how they don't have to match, even
+when we commit things.
+
+As before, if we do `git diff-files -p` in our git-tutorial project,
+we'll still see the same difference we saw last time: the index file
+hasn't changed by the act of committing anything. However, now that we
+have committed something, we can also learn to use a new command:
+'git diff-index'.
+
+Unlike 'git diff-files', which showed the difference between the index
+file and the working tree, 'git diff-index' shows the differences
+between a committed *tree* and either the index file or the working
+tree. In other words, 'git diff-index' wants a tree to be diffed
+against, and before we did the commit, we couldn't do that, because we
+didn't have anything to diff against.
+
+But now we can do
+
+----------------
+$ git diff-index -p HEAD
+----------------
+
+(where `-p` has the same meaning as it did in 'git diff-files'), and it
+will show us the same difference, but for a totally different reason.
+Now we're comparing the working tree not against the index file,
+but against the tree we just wrote. It just so happens that those two
+are obviously the same, so we get the same result.
+
+Again, because this is a common operation, you can also just shorthand
+it with
+
+----------------
+$ git diff HEAD
+----------------
+
+which ends up doing the above for you.
+
+In other words, 'git diff-index' normally compares a tree against the
+working tree, but when given the `--cached` flag, it is told to
+instead compare against just the index cache contents, and ignore the
+current working tree state entirely. Since we just wrote the index
+file to HEAD, doing `git diff-index --cached -p HEAD` should thus return
+an empty set of differences, and that's exactly what it does.
+
+[NOTE]
+================
+'git diff-index' really always uses the index for its
+comparisons, and saying that it compares a tree against the working
+tree is thus not strictly accurate. In particular, the list of
+files to compare (the "meta-data") *always* comes from the index file,
+regardless of whether the `--cached` flag is used or not. The `--cached`
+flag really only determines whether the file *contents* to be compared
+come from the working tree or not.
+
+This is not hard to understand, as soon as you realize that Git simply
+never knows (or cares) about files that it is not told about
+explicitly. Git will never go *looking* for files to compare, it
+expects you to tell it what the files are, and that's what the index
+is there for.
+================
+
+However, our next step is to commit the *change* we did, and again, to
+understand what's going on, keep in mind the difference between "working
+tree contents", "index file" and "committed tree". We have changes
+in the working tree that we want to commit, and we always have to
+work through the index file, so the first thing we need to do is to
+update the index cache:
+
+------------------------------------------------
+$ git update-index hello
+------------------------------------------------
+
+(note how we didn't need the `--add` flag this time, since Git knew
+about the file already).
+
+Note what happens to the different 'git diff-{asterisk}' versions here.
+After we've updated `hello` in the index, `git diff-files -p` now shows no
+differences, but `git diff-index -p HEAD` still *does* show that the
+current state is different from the state we committed. In fact, now
+'git diff-index' shows the same difference whether we use the `--cached`
+flag or not, since now the index is coherent with the working tree.
+
+Now, since we've updated `hello` in the index, we can commit the new
+version. We could do it by writing the tree by hand again, and
+committing the tree (this time we'd have to use the `-p HEAD` flag to
+tell commit that the HEAD was the *parent* of the new commit, and that
+this wasn't an initial commit any more), but you've done that once
+already, so let's just use the helpful script this time:
+
+------------------------------------------------
+$ git commit
+------------------------------------------------
+
+which starts an editor for you to write the commit message and tells you
+a bit about what you have done.
+
+Write whatever message you want, and all the lines that start with '#'
+will be pruned out, and the rest will be used as the commit message for
+the change. If you decide you don't want to commit anything after all at
+this point (you can continue to edit things and update the index), you
+can just leave an empty message. Otherwise `git commit` will commit
+the change for you.
+
+You've now made your first real Git commit. And if you're interested in
+looking at what `git commit` really does, feel free to investigate:
+it's a few very simple shell scripts to generate the helpful (?) commit
+message headers, and a few one-liners that actually do the
+commit itself ('git commit').
+
+
+Inspecting Changes
+------------------
+
+While creating changes is useful, it's even more useful if you can tell
+later what changed. The most useful command for this is another of the
+'diff' family, namely 'git diff-tree'.
+
+'git diff-tree' can be given two arbitrary trees, and it will tell you the
+differences between them. Perhaps even more commonly, though, you can
+give it just a single commit object, and it will figure out the parent
+of that commit itself, and show the difference directly. Thus, to get
+the same diff that we've already seen several times, we can now do
+
+----------------
+$ git diff-tree -p HEAD
+----------------
+
+(again, `-p` means to show the difference as a human-readable patch),
+and it will show what the last commit (in `HEAD`) actually changed.
+
+[NOTE]
+============
+Here is an ASCII art by Jon Loeliger that illustrates how
+various 'diff-{asterisk}' commands compare things.
+
+ diff-tree
+ +----+
+ | |
+ | |
+ V V
+ +-----------+
+ | Object DB |
+ | Backing |
+ | Store |
+ +-----------+
+ ^ ^
+ | |
+ | | diff-index --cached
+ | |
+ diff-index | V
+ | +-----------+
+ | | Index |
+ | | "cache" |
+ | +-----------+
+ | ^
+ | |
+ | | diff-files
+ | |
+ V V
+ +-----------+
+ | Working |
+ | Directory |
+ +-----------+
+============
+
+More interestingly, you can also give 'git diff-tree' the `--pretty` flag,
+which tells it to also show the commit message and author and date of the
+commit, and you can tell it to show a whole series of diffs.
+Alternatively, you can tell it to be "silent", and not show the diffs at
+all, but just show the actual commit message.
+
+In fact, together with the 'git rev-list' program (which generates a
+list of revisions), 'git diff-tree' ends up being a veritable fount of
+changes. You can emulate `git log`, `git log -p`, etc. with a trivial
+script that pipes the output of `git rev-list` to `git diff-tree --stdin`,
+which was exactly how early versions of `git log` were implemented.
+
+
+Tagging a version
+-----------------
+
+In Git, there are two kinds of tags, a "light" one, and an "annotated tag".
+
+A "light" tag is technically nothing more than a branch, except we put
+it in the `.git/refs/tags/` subdirectory instead of calling it a `head`.
+So the simplest form of tag involves nothing more than
+
+------------------------------------------------
+$ git tag my-first-tag
+------------------------------------------------
+
+which just writes the current `HEAD` into the `.git/refs/tags/my-first-tag`
+file, after which point you can then use this symbolic name for that
+particular state. You can, for example, do
+
+----------------
+$ git diff my-first-tag
+----------------
+
+to diff your current state against that tag which at this point will
+obviously be an empty diff, but if you continue to develop and commit
+stuff, you can use your tag as an "anchor-point" to see what has changed
+since you tagged it.
+
+An "annotated tag" is actually a real Git object, and contains not only a
+pointer to the state you want to tag, but also a small tag name and
+message, along with optionally a PGP signature that says that yes,
+you really did
+that tag. You create these annotated tags with either the `-a` or
+`-s` flag to 'git tag':
+
+----------------
+$ git tag -s <tagname>
+----------------
+
+which will sign the current `HEAD` (but you can also give it another
+argument that specifies the thing to tag, e.g., you could have tagged the
+current `mybranch` point by using `git tag <tagname> mybranch`).
+
+You normally only do signed tags for major releases or things
+like that, while the light-weight tags are useful for any marking you
+want to do -- any time you decide that you want to remember a certain
+point, just create a private tag for it, and you have a nice symbolic
+name for the state at that point.
+
+
+Copying repositories
+--------------------
+
+Git repositories are normally totally self-sufficient and relocatable.
+Unlike CVS, for example, there is no separate notion of
+"repository" and "working tree". A Git repository normally *is* the
+working tree, with the local Git information hidden in the `.git`
+subdirectory. There is nothing else. What you see is what you got.
+
+[NOTE]
+You can tell Git to split the Git internal information from
+the directory that it tracks, but we'll ignore that for now: it's not
+how normal projects work, and it's really only meant for special uses.
+So the mental model of "the Git information is always tied directly to
+the working tree that it describes" may not be technically 100%
+accurate, but it's a good model for all normal use.
+
+This has two implications:
+
+ - if you grow bored with the tutorial repository you created (or you've
+ made a mistake and want to start all over), you can just do simple
++
+----------------
+$ rm -rf git-tutorial
+----------------
++
+and it will be gone. There's no external repository, and there's no
+history outside the project you created.
+
+ - if you want to move or duplicate a Git repository, you can do so. There
+ is 'git clone' command, but if all you want to do is just to
+ create a copy of your repository (with all the full history that
+ went along with it), you can do so with a regular
+ `cp -a git-tutorial new-git-tutorial`.
++
+Note that when you've moved or copied a Git repository, your Git index
+file (which caches various information, notably some of the "stat"
+information for the files involved) will likely need to be refreshed.
+So after you do a `cp -a` to create a new copy, you'll want to do
++
+----------------
+$ git update-index --refresh
+----------------
++
+in the new repository to make sure that the index file is up to date.
+
+Note that the second point is true even across machines. You can
+duplicate a remote Git repository with *any* regular copy mechanism, be it
+'scp', 'rsync' or 'wget'.
+
+When copying a remote repository, you'll want to at a minimum update the
+index cache when you do this, and especially with other peoples'
+repositories you often want to make sure that the index cache is in some
+known state (you don't know *what* they've done and not yet checked in),
+so usually you'll precede the 'git update-index' with a
+
+----------------
+$ git read-tree --reset HEAD
+$ git update-index --refresh
+----------------
+
+which will force a total index re-build from the tree pointed to by `HEAD`.
+It resets the index contents to `HEAD`, and then the 'git update-index'
+makes sure to match up all index entries with the checked-out files.
+If the original repository had uncommitted changes in its
+working tree, `git update-index --refresh` notices them and
+tells you they need to be updated.
+
+The above can also be written as simply
+
+----------------
+$ git reset
+----------------
+
+and in fact a lot of the common Git command combinations can be scripted
+with the `git xyz` interfaces. You can learn things by just looking
+at what the various git scripts do. For example, `git reset` used to be
+the above two lines implemented in 'git reset', but some things like
+'git status' and 'git commit' are slightly more complex scripts around
+the basic Git commands.
+
+Many (most?) public remote repositories will not contain any of
+the checked out files or even an index file, and will *only* contain the
+actual core Git files. Such a repository usually doesn't even have the
+`.git` subdirectory, but has all the Git files directly in the
+repository.
+
+To create your own local live copy of such a "raw" Git repository, you'd
+first create your own subdirectory for the project, and then copy the
+raw repository contents into the `.git` directory. For example, to
+create your own copy of the Git repository, you'd do the following
+
+----------------
+$ mkdir my-git
+$ cd my-git
+$ rsync -rL rsync://rsync.kernel.org/pub/scm/git/git.git/ .git
+----------------
+
+followed by
+
+----------------
+$ git read-tree HEAD
+----------------
+
+to populate the index. However, now you have populated the index, and
+you have all the Git internal files, but you will notice that you don't
+actually have any of the working tree files to work on. To get
+those, you'd check them out with
+
+----------------
+$ git checkout-index -u -a
+----------------
+
+where the `-u` flag means that you want the checkout to keep the index
+up to date (so that you don't have to refresh it afterward), and the
+`-a` flag means "check out all files" (if you have a stale copy or an
+older version of a checked out tree you may also need to add the `-f`
+flag first, to tell 'git checkout-index' to *force* overwriting of any old
+files).
+
+Again, this can all be simplified with
+
+----------------
+$ git clone git://git.kernel.org/pub/scm/git/git.git/ my-git
+$ cd my-git
+$ git checkout
+----------------
+
+which will end up doing all of the above for you.
+
+You have now successfully copied somebody else's (mine) remote
+repository, and checked it out.
+
+
+Creating a new branch
+---------------------
+
+Branches in Git are really nothing more than pointers into the Git
+object database from within the `.git/refs/` subdirectory, and as we
+already discussed, the `HEAD` branch is nothing but a symlink to one of
+these object pointers.
+
+You can at any time create a new branch by just picking an arbitrary
+point in the project history, and just writing the SHA-1 name of that
+object into a file under `.git/refs/heads/`. You can use any filename you
+want (and indeed, subdirectories), but the convention is that the
+"normal" branch is called `master`. That's just a convention, though,
+and nothing enforces it.
+
+To show that as an example, let's go back to the git-tutorial repository we
+used earlier, and create a branch in it. You do that by simply just
+saying that you want to check out a new branch:
+
+------------
+$ git switch -c mybranch
+------------
+
+will create a new branch based at the current `HEAD` position, and switch
+to it.
+
+[NOTE]
+================================================
+If you make the decision to start your new branch at some
+other point in the history than the current `HEAD`, you can do so by
+just telling 'git switch' what the base of the checkout would be.
+In other words, if you have an earlier tag or branch, you'd just do
+
+------------
+$ git switch -c mybranch earlier-commit
+------------
+
+and it would create the new branch `mybranch` at the earlier commit,
+and check out the state at that time.
+================================================
+
+You can always just jump back to your original `master` branch by doing
+
+------------
+$ git switch master
+------------
+
+(or any other branch-name, for that matter) and if you forget which
+branch you happen to be on, a simple
+
+------------
+$ cat .git/HEAD
+------------
+
+will tell you where it's pointing. To get the list of branches
+you have, you can say
+
+------------
+$ git branch
+------------
+
+which used to be nothing more than a simple script around `ls .git/refs/heads`.
+There will be an asterisk in front of the branch you are currently on.
+
+Sometimes you may wish to create a new branch _without_ actually
+checking it out and switching to it. If so, just use the command
+
+------------
+$ git branch <branchname> [startingpoint]
+------------
+
+which will simply _create_ the branch, but will not do anything further.
+You can then later -- once you decide that you want to actually develop
+on that branch -- switch to that branch with a regular 'git switch'
+with the branchname as the argument.
+
+
+Merging two branches
+--------------------
+
+One of the ideas of having a branch is that you do some (possibly
+experimental) work in it, and eventually merge it back to the main
+branch. So assuming you created the above `mybranch` that started out
+being the same as the original `master` branch, let's make sure we're in
+that branch, and do some work there.
+
+------------------------------------------------
+$ git switch mybranch
+$ echo "Work, work, work" >>hello
+$ git commit -m "Some work." -i hello
+------------------------------------------------
+
+Here, we just added another line to `hello`, and we used a shorthand for
+doing both `git update-index hello` and `git commit` by just giving the
+filename directly to `git commit`, with an `-i` flag (it tells
+Git to 'include' that file in addition to what you have done to
+the index file so far when making the commit). The `-m` flag is to give the
+commit log message from the command line.
+
+Now, to make it a bit more interesting, let's assume that somebody else
+does some work in the original branch, and simulate that by going back
+to the master branch, and editing the same file differently there:
+
+------------
+$ git switch master
+------------
+
+Here, take a moment to look at the contents of `hello`, and notice how they
+don't contain the work we just did in `mybranch` -- because that work
+hasn't happened in the `master` branch at all. Then do
+
+------------
+$ echo "Play, play, play" >>hello
+$ echo "Lots of fun" >>example
+$ git commit -m "Some fun." -i hello example
+------------
+
+since the master branch is obviously in a much better mood.
+
+Now, you've got two branches, and you decide that you want to merge the
+work done. Before we do that, let's introduce a cool graphical tool that
+helps you view what's going on:
+
+----------------
+$ gitk --all
+----------------
+
+will show you graphically both of your branches (that's what the `--all`
+means: normally it will just show you your current `HEAD`) and their
+histories. You can also see exactly how they came to be from a common
+source.
+
+Anyway, let's exit 'gitk' (`^Q` or the File menu), and decide that we want
+to merge the work we did on the `mybranch` branch into the `master`
+branch (which is currently our `HEAD` too). To do that, there's a nice
+script called 'git merge', which wants to know which branches you want
+to resolve and what the merge is all about:
+
+------------
+$ git merge -m "Merge work in mybranch" mybranch
+------------
+
+where the first argument is going to be used as the commit message if
+the merge can be resolved automatically.
+
+Now, in this case we've intentionally created a situation where the
+merge will need to be fixed up by hand, though, so Git will do as much
+of it as it can automatically (which in this case is just merge the `example`
+file, which had no differences in the `mybranch` branch), and say:
+
+----------------
+ Auto-merging hello
+ CONFLICT (content): Merge conflict in hello
+ Automatic merge failed; fix conflicts and then commit the result.
+----------------
+
+It tells you that it did an "Automatic merge", which
+failed due to conflicts in `hello`.
+
+Not to worry. It left the (trivial) conflict in `hello` in the same form you
+should already be well used to if you've ever used CVS, so let's just
+open `hello` in our editor (whatever that may be), and fix it up somehow.
+I'd suggest just making it so that `hello` contains all four lines:
+
+------------
+Hello World
+It's a new day for git
+Play, play, play
+Work, work, work
+------------
+
+and once you're happy with your manual merge, just do a
+
+------------
+$ git commit -i hello
+------------
+
+which will very loudly warn you that you're now committing a merge
+(which is correct, so never mind), and you can write a small merge
+message about your adventures in 'git merge'-land.
+
+After you're done, start up `gitk --all` to see graphically what the
+history looks like. Notice that `mybranch` still exists, and you can
+switch to it, and continue to work with it if you want to. The
+`mybranch` branch will not contain the merge, but next time you merge it
+from the `master` branch, Git will know how you merged it, so you'll not
+have to do _that_ merge again.
+
+Another useful tool, especially if you do not always work in X-Window
+environment, is `git show-branch`.
+
+------------------------------------------------
+$ git show-branch --topo-order --more=1 master mybranch
+* [master] Merge work in mybranch
+ ! [mybranch] Some work.
+--
+- [master] Merge work in mybranch
+*+ [mybranch] Some work.
+* [master^] Some fun.
+------------------------------------------------
+
+The first two lines indicate that it is showing the two branches
+with the titles of their top-of-the-tree commits, you are currently on
+`master` branch (notice the asterisk `*` character), and the first
+column for the later output lines is used to show commits contained in the
+`master` branch, and the second column for the `mybranch`
+branch. Three commits are shown along with their titles.
+All of them have non blank characters in the first column (`*`
+shows an ordinary commit on the current branch, `-` is a merge commit), which
+means they are now part of the `master` branch. Only the "Some
+work" commit has the plus `+` character in the second column,
+because `mybranch` has not been merged to incorporate these
+commits from the master branch. The string inside brackets
+before the commit log message is a short name you can use to
+name the commit. In the above example, 'master' and 'mybranch'
+are branch heads. 'master^' is the first parent of 'master'
+branch head. Please see linkgit:gitrevisions[7] if you want to
+see more complex cases.
+
+[NOTE]
+Without the '--more=1' option, 'git show-branch' would not output the
+'[master^]' commit, as '[mybranch]' commit is a common ancestor of
+both 'master' and 'mybranch' tips. Please see linkgit:git-show-branch[1]
+for details.
+
+[NOTE]
+If there were more commits on the 'master' branch after the merge, the
+merge commit itself would not be shown by 'git show-branch' by
+default. You would need to provide `--sparse` option to make the
+merge commit visible in this case.
+
+Now, let's pretend you are the one who did all the work in
+`mybranch`, and the fruit of your hard work has finally been merged
+to the `master` branch. Let's go back to `mybranch`, and run
+'git merge' to get the "upstream changes" back to your branch.
+
+------------
+$ git switch mybranch
+$ git merge -m "Merge upstream changes." master
+------------
+
+This outputs something like this (the actual commit object names
+would be different)
+
+----------------
+Updating from ae3a2da... to a80b4aa....
+Fast-forward (no commit created; -m option ignored)
+ example | 1 +
+ hello | 1 +
+ 2 files changed, 2 insertions(+)
+----------------
+
+Because your branch did not contain anything more than what had
+already been merged into the `master` branch, the merge operation did
+not actually do a merge. Instead, it just updated the top of
+the tree of your branch to that of the `master` branch. This is
+often called 'fast-forward' merge.
+
+You can run `gitk --all` again to see how the commit ancestry
+looks like, or run 'show-branch', which tells you this.
+
+------------------------------------------------
+$ git show-branch master mybranch
+! [master] Merge work in mybranch
+ * [mybranch] Merge work in mybranch
+--
+-- [master] Merge work in mybranch
+------------------------------------------------
+
+
+Merging external work
+---------------------
+
+It's usually much more common that you merge with somebody else than
+merging with your own branches, so it's worth pointing out that Git
+makes that very easy too, and in fact, it's not that different from
+doing a 'git merge'. In fact, a remote merge ends up being nothing
+more than "fetch the work from a remote repository into a temporary tag"
+followed by a 'git merge'.
+
+Fetching from a remote repository is done by, unsurprisingly,
+'git fetch':
+
+----------------
+$ git fetch <remote-repository>
+----------------
+
+One of the following transports can be used to name the
+repository to download from:
+
+SSH::
+ `remote.machine:/path/to/repo.git/` or
++
+`ssh://remote.machine/path/to/repo.git/`
++
+This transport can be used for both uploading and downloading,
+and requires you to have a log-in privilege over `ssh` to the
+remote machine. It finds out the set of objects the other side
+lacks by exchanging the head commits both ends have and
+transfers (close to) minimum set of objects. It is by far the
+most efficient way to exchange Git objects between repositories.
+
+Local directory::
+ `/path/to/repo.git/`
++
+This transport is the same as SSH transport but uses 'sh' to run
+both ends on the local machine instead of running other end on
+the remote machine via 'ssh'.
+
+Git Native::
+ `git://remote.machine/path/to/repo.git/`
++
+This transport was designed for anonymous downloading. Like SSH
+transport, it finds out the set of objects the downstream side
+lacks and transfers (close to) minimum set of objects.
+
+HTTP(S)::
+ `http://remote.machine/path/to/repo.git/`
++
+Downloader from http and https URL
+first obtains the topmost commit object name from the remote site
+by looking at the specified refname under `repo.git/refs/` directory,
+and then tries to obtain the
+commit object by downloading from `repo.git/objects/xx/xxx...`
+using the object name of that commit object. Then it reads the
+commit object to find out its parent commits and the associate
+tree object; it repeats this process until it gets all the
+necessary objects. Because of this behavior, they are
+sometimes also called 'commit walkers'.
++
+The 'commit walkers' are sometimes also called 'dumb
+transports', because they do not require any Git aware smart
+server like Git Native transport does. Any stock HTTP server
+that does not even support directory index would suffice. But
+you must prepare your repository with 'git update-server-info'
+to help dumb transport downloaders.
+
+Once you fetch from the remote repository, you `merge` that
+with your current branch.
+
+However -- it's such a common thing to `fetch` and then
+immediately `merge`, that it's called `git pull`, and you can
+simply do
+
+----------------
+$ git pull <remote-repository>
+----------------
+
+and optionally give a branch-name for the remote end as a second
+argument.
+
+[NOTE]
+You could do without using any branches at all, by
+keeping as many local repositories as you would like to have
+branches, and merging between them with 'git pull', just like
+you merge between branches. The advantage of this approach is
+that it lets you keep a set of files for each `branch` checked
+out and you may find it easier to switch back and forth if you
+juggle multiple lines of development simultaneously. Of
+course, you will pay the price of more disk usage to hold
+multiple working trees, but disk space is cheap these days.
+
+It is likely that you will be pulling from the same remote
+repository from time to time. As a short hand, you can store
+the remote repository URL in the local repository's config file
+like this:
+
+------------------------------------------------
+$ git config remote.linus.url https://git.kernel.org/pub/scm/git/git.git/
+------------------------------------------------
+
+and use the "linus" keyword with 'git pull' instead of the full URL.
+
+Examples.
+
+. `git pull linus`
+. `git pull linus tag v0.99.1`
+
+the above are equivalent to:
+
+. `git pull http://www.kernel.org/pub/scm/git/git.git/ HEAD`
+. `git pull http://www.kernel.org/pub/scm/git/git.git/ tag v0.99.1`
+
+
+How does the merge work?
+------------------------
+
+We said this tutorial shows what plumbing does to help you cope
+with the porcelain that isn't flushing, but we so far did not
+talk about how the merge really works. If you are following
+this tutorial the first time, I'd suggest to skip to "Publishing
+your work" section and come back here later.
+
+OK, still with me? To give us an example to look at, let's go
+back to the earlier repository with "hello" and "example" file,
+and bring ourselves back to the pre-merge state:
+
+------------
+$ git show-branch --more=2 master mybranch
+! [master] Merge work in mybranch
+ * [mybranch] Merge work in mybranch
+--
+-- [master] Merge work in mybranch
++* [master^2] Some work.
++* [master^] Some fun.
+------------
+
+Remember, before running 'git merge', our `master` head was at
+"Some fun." commit, while our `mybranch` head was at "Some
+work." commit.
+
+------------
+$ git switch -C mybranch master^2
+$ git switch master
+$ git reset --hard master^
+------------
+
+After rewinding, the commit structure should look like this:
+
+------------
+$ git show-branch
+* [master] Some fun.
+ ! [mybranch] Some work.
+--
+* [master] Some fun.
+ + [mybranch] Some work.
+*+ [master^] Initial commit
+------------
+
+Now we are ready to experiment with the merge by hand.
+
+`git merge` command, when merging two branches, uses 3-way merge
+algorithm. First, it finds the common ancestor between them.
+The command it uses is 'git merge-base':
+
+------------
+$ mb=$(git merge-base HEAD mybranch)
+------------
+
+The command writes the commit object name of the common ancestor
+to the standard output, so we captured its output to a variable,
+because we will be using it in the next step. By the way, the common
+ancestor commit is the "Initial commit" commit in this case. You can
+tell it by:
+
+------------
+$ git name-rev --name-only --tags $mb
+my-first-tag
+------------
+
+After finding out a common ancestor commit, the second step is
+this:
+
+------------
+$ git read-tree -m -u $mb HEAD mybranch
+------------
+
+This is the same 'git read-tree' command we have already seen,
+but it takes three trees, unlike previous examples. This reads
+the contents of each tree into different 'stage' in the index
+file (the first tree goes to stage 1, the second to stage 2,
+etc.). After reading three trees into three stages, the paths
+that are the same in all three stages are 'collapsed' into stage
+0. Also paths that are the same in two of three stages are
+collapsed into stage 0, taking the SHA-1 from either stage 2 or
+stage 3, whichever is different from stage 1 (i.e. only one side
+changed from the common ancestor).
+
+After 'collapsing' operation, paths that are different in three
+trees are left in non-zero stages. At this point, you can
+inspect the index file with this command:
+
+------------
+$ git ls-files --stage
+100644 7f8b141b65fdcee47321e399a2598a235a032422 0 example
+100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1 hello
+100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello
+100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello
+------------
+
+In our example of only two files, we did not have unchanged
+files so only 'example' resulted in collapsing. But in real-life
+large projects, when only a small number of files change in one commit,
+this 'collapsing' tends to trivially merge most of the paths
+fairly quickly, leaving only a handful of real changes in non-zero
+stages.
+
+To look at only non-zero stages, use `--unmerged` flag:
+
+------------
+$ git ls-files --unmerged
+100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1 hello
+100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello
+100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello
+------------
+
+The next step of merging is to merge these three versions of the
+file, using 3-way merge. This is done by giving
+'git merge-one-file' command as one of the arguments to
+'git merge-index' command:
+
+------------
+$ git merge-index git-merge-one-file hello
+Auto-merging hello
+ERROR: Merge conflict in hello
+fatal: merge program failed
+------------
+
+'git merge-one-file' script is called with parameters to
+describe those three versions, and is responsible to leave the
+merge results in the working tree.
+It is a fairly straightforward shell script, and
+eventually calls 'merge' program from RCS suite to perform a
+file-level 3-way merge. In this case, 'merge' detects
+conflicts, and the merge result with conflict marks is left in
+the working tree.. This can be seen if you run `ls-files
+--stage` again at this point:
+
+------------
+$ git ls-files --stage
+100644 7f8b141b65fdcee47321e399a2598a235a032422 0 example
+100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1 hello
+100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello
+100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello
+------------
+
+This is the state of the index file and the working file after
+'git merge' returns control back to you, leaving the conflicting
+merge for you to resolve. Notice that the path `hello` is still
+unmerged, and what you see with 'git diff' at this point is
+differences since stage 2 (i.e. your version).
+
+
+Publishing your work
+--------------------
+
+So, we can use somebody else's work from a remote repository, but
+how can *you* prepare a repository to let other people pull from
+it?
+
+You do your real work in your working tree that has your
+primary repository hanging under it as its `.git` subdirectory.
+You *could* make that repository accessible remotely and ask
+people to pull from it, but in practice that is not the way
+things are usually done. A recommended way is to have a public
+repository, make it reachable by other people, and when the
+changes you made in your primary working tree are in good shape,
+update the public repository from it. This is often called
+'pushing'.
+
+[NOTE]
+This public repository could further be mirrored, and that is
+how Git repositories at `kernel.org` are managed.
+
+Publishing the changes from your local (private) repository to
+your remote (public) repository requires a write privilege on
+the remote machine. You need to have an SSH account there to
+run a single command, 'git-receive-pack'.
+
+First, you need to create an empty repository on the remote
+machine that will house your public repository. This empty
+repository will be populated and be kept up to date by pushing
+into it later. Obviously, this repository creation needs to be
+done only once.
+
+[NOTE]
+'git push' uses a pair of commands,
+'git send-pack' on your local machine, and 'git-receive-pack'
+on the remote machine. The communication between the two over
+the network internally uses an SSH connection.
+
+Your private repository's Git directory is usually `.git`, but
+your public repository is often named after the project name,
+i.e. `<project>.git`. Let's create such a public repository for
+project `my-git`. After logging into the remote machine, create
+an empty directory:
+
+------------
+$ mkdir my-git.git
+------------
+
+Then, make that directory into a Git repository by running
+'git init', but this time, since its name is not the usual
+`.git`, we do things slightly differently:
+
+------------
+$ GIT_DIR=my-git.git git init
+------------
+
+Make sure this directory is available for others you want your
+changes to be pulled via the transport of your choice. Also
+you need to make sure that you have the 'git-receive-pack'
+program on the `$PATH`.
+
+[NOTE]
+Many installations of sshd do not invoke your shell as the login
+shell when you directly run programs; what this means is that if
+your login shell is 'bash', only `.bashrc` is read and not
+`.bash_profile`. As a workaround, make sure `.bashrc` sets up
+`$PATH` so that you can run 'git-receive-pack' program.
+
+[NOTE]
+If you plan to publish this repository to be accessed over http,
+you should do `mv my-git.git/hooks/post-update.sample
+my-git.git/hooks/post-update` at this point.
+This makes sure that every time you push into this
+repository, `git update-server-info` is run.
+
+Your "public repository" is now ready to accept your changes.
+Come back to the machine you have your private repository. From
+there, run this command:
+
+------------
+$ git push <public-host>:/path/to/my-git.git master
+------------
+
+This synchronizes your public repository to match the named
+branch head (i.e. `master` in this case) and objects reachable
+from them in your current repository.
+
+As a real example, this is how I update my public Git
+repository. Kernel.org mirror network takes care of the
+propagation to other publicly visible machines:
+
+------------
+$ git push master.kernel.org:/pub/scm/git/git.git/
+------------
+
+
+Packing your repository
+-----------------------
+
+Earlier, we saw that one file under `.git/objects/??/` directory
+is stored for each Git object you create. This representation
+is efficient to create atomically and safely, but
+not so convenient to transport over the network. Since Git objects are
+immutable once they are created, there is a way to optimize the
+storage by "packing them together". The command
+
+------------
+$ git repack
+------------
+
+will do it for you. If you followed the tutorial examples, you
+would have accumulated about 17 objects in `.git/objects/??/`
+directories by now. 'git repack' tells you how many objects it
+packed, and stores the packed file in the `.git/objects/pack`
+directory.
+
+[NOTE]
+You will see two files, `pack-*.pack` and `pack-*.idx`,
+in `.git/objects/pack` directory. They are closely related to
+each other, and if you ever copy them by hand to a different
+repository for whatever reason, you should make sure you copy
+them together. The former holds all the data from the objects
+in the pack, and the latter holds the index for random
+access.
+
+If you are paranoid, running 'git verify-pack' command would
+detect if you have a corrupt pack, but do not worry too much.
+Our programs are always perfect ;-).
+
+Once you have packed objects, you do not need to leave the
+unpacked objects that are contained in the pack file anymore.
+
+------------
+$ git prune-packed
+------------
+
+would remove them for you.
+
+You can try running `find .git/objects -type f` before and after
+you run `git prune-packed` if you are curious. Also `git
+count-objects` would tell you how many unpacked objects are in
+your repository and how much space they are consuming.
+
+[NOTE]
+`git pull` is slightly cumbersome for HTTP transport, as a
+packed repository may contain relatively few objects in a
+relatively large pack. If you expect many HTTP pulls from your
+public repository you might want to repack & prune often, or
+never.
+
+If you run `git repack` again at this point, it will say
+"Nothing new to pack.". Once you continue your development and
+accumulate the changes, running `git repack` again will create a
+new pack, that contains objects created since you packed your
+repository the last time. We recommend that you pack your project
+soon after the initial import (unless you are starting your
+project from scratch), and then run `git repack` every once in a
+while, depending on how active your project is.
+
+When a repository is synchronized via `git push` and `git pull`
+objects packed in the source repository are usually stored
+unpacked in the destination.
+While this allows you to use different packing strategies on
+both ends, it also means you may need to repack both
+repositories every once in a while.
+
+
+Working with Others
+-------------------
+
+Although Git is a truly distributed system, it is often
+convenient to organize your project with an informal hierarchy
+of developers. Linux kernel development is run this way. There
+is a nice illustration (page 17, "Merges to Mainline") in
+https://web.archive.org/web/20120915203609/http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf[Randy Dunlap's presentation].
+
+It should be stressed that this hierarchy is purely *informal*.
+There is nothing fundamental in Git that enforces the "chain of
+patch flow" this hierarchy implies. You do not have to pull
+from only one remote repository.
+
+A recommended workflow for a "project lead" goes like this:
+
+1. Prepare your primary repository on your local machine. Your
+ work is done there.
+
+2. Prepare a public repository accessible to others.
++
+If other people are pulling from your repository over dumb
+transport protocols (HTTP), you need to keep this repository
+'dumb transport friendly'. After `git init`,
+`$GIT_DIR/hooks/post-update.sample` copied from the standard templates
+would contain a call to 'git update-server-info'
+but you need to manually enable the hook with
+`mv post-update.sample post-update`. This makes sure
+'git update-server-info' keeps the necessary files up to date.
+
+3. Push into the public repository from your primary
+ repository.
+
+4. 'git repack' the public repository. This establishes a big
+ pack that contains the initial set of objects as the
+ baseline, and possibly 'git prune' if the transport
+ used for pulling from your repository supports packed
+ repositories.
+
+5. Keep working in your primary repository. Your changes
+ include modifications of your own, patches you receive via
+ e-mails, and merges resulting from pulling the "public"
+ repositories of your "subsystem maintainers".
++
+You can repack this private repository whenever you feel like.
+
+6. Push your changes to the public repository, and announce it
+ to the public.
+
+7. Every once in a while, 'git repack' the public repository.
+ Go back to step 5. and continue working.
+
+
+A recommended work cycle for a "subsystem maintainer" who works
+on that project and has an own "public repository" goes like this:
+
+1. Prepare your work repository, by running 'git clone' on the public
+ repository of the "project lead". The URL used for the
+ initial cloning is stored in the remote.origin.url
+ configuration variable.
+
+2. Prepare a public repository accessible to others, just like
+ the "project lead" person does.
+
+3. Copy over the packed files from "project lead" public
+ repository to your public repository, unless the "project
+ lead" repository lives on the same machine as yours. In the
+ latter case, you can use `objects/info/alternates` file to
+ point at the repository you are borrowing from.
+
+4. Push into the public repository from your primary
+ repository. Run 'git repack', and possibly 'git prune' if the
+ transport used for pulling from your repository supports
+ packed repositories.
+
+5. Keep working in your primary repository. Your changes
+ include modifications of your own, patches you receive via
+ e-mails, and merges resulting from pulling the "public"
+ repositories of your "project lead" and possibly your
+ "sub-subsystem maintainers".
++
+You can repack this private repository whenever you feel
+like.
+
+6. Push your changes to your public repository, and ask your
+ "project lead" and possibly your "sub-subsystem
+ maintainers" to pull from it.
+
+7. Every once in a while, 'git repack' the public repository.
+ Go back to step 5. and continue working.
+
+
+A recommended work cycle for an "individual developer" who does
+not have a "public" repository is somewhat different. It goes
+like this:
+
+1. Prepare your work repository, by 'git clone' the public
+ repository of the "project lead" (or a "subsystem
+ maintainer", if you work on a subsystem). The URL used for
+ the initial cloning is stored in the remote.origin.url
+ configuration variable.
+
+2. Do your work in your repository on 'master' branch.
+
+3. Run `git fetch origin` from the public repository of your
+ upstream every once in a while. This does only the first
+ half of `git pull` but does not merge. The head of the
+ public repository is stored in `.git/refs/remotes/origin/master`.
+
+4. Use `git cherry origin` to see which ones of your patches
+ were accepted, and/or use `git rebase origin` to port your
+ unmerged changes forward to the updated upstream.
+
+5. Use `git format-patch origin` to prepare patches for e-mail
+ submission to your upstream and send it out. Go back to
+ step 2. and continue.
+
+
+Working with Others, Shared Repository Style
+--------------------------------------------
+
+If you are coming from a CVS background, the style of cooperation
+suggested in the previous section may be new to you. You do not
+have to worry. Git supports the "shared public repository" style of
+cooperation you are probably more familiar with as well.
+
+See linkgit:gitcvs-migration[7] for the details.
+
+Bundling your work together
+---------------------------
+
+It is likely that you will be working on more than one thing at
+a time. It is easy to manage those more-or-less independent tasks
+using branches with Git.
+
+We have already seen how branches work previously,
+with "fun and work" example using two branches. The idea is the
+same if there are more than two branches. Let's say you started
+out from "master" head, and have some new code in the "master"
+branch, and two independent fixes in the "commit-fix" and
+"diff-fix" branches:
+
+------------
+$ git show-branch
+! [commit-fix] Fix commit message normalization.
+ ! [diff-fix] Fix rename detection.
+ * [master] Release candidate #1
+---
+ + [diff-fix] Fix rename detection.
+ + [diff-fix~1] Better common substring algorithm.
++ [commit-fix] Fix commit message normalization.
+ * [master] Release candidate #1
+++* [diff-fix~2] Pretty-print messages.
+------------
+
+Both fixes are tested well, and at this point, you want to merge
+in both of them. You could merge in 'diff-fix' first and then
+'commit-fix' next, like this:
+
+------------
+$ git merge -m "Merge fix in diff-fix" diff-fix
+$ git merge -m "Merge fix in commit-fix" commit-fix
+------------
+
+Which would result in:
+
+------------
+$ git show-branch
+! [commit-fix] Fix commit message normalization.
+ ! [diff-fix] Fix rename detection.
+ * [master] Merge fix in commit-fix
+---
+ - [master] Merge fix in commit-fix
++ * [commit-fix] Fix commit message normalization.
+ - [master~1] Merge fix in diff-fix
+ +* [diff-fix] Fix rename detection.
+ +* [diff-fix~1] Better common substring algorithm.
+ * [master~2] Release candidate #1
+++* [master~3] Pretty-print messages.
+------------
+
+However, there is no particular reason to merge in one branch
+first and the other next, when what you have are a set of truly
+independent changes (if the order mattered, then they are not
+independent by definition). You could instead merge those two
+branches into the current branch at once. First let's undo what
+we just did and start over. We would want to get the master
+branch before these two merges by resetting it to 'master~2':
+
+------------
+$ git reset --hard master~2
+------------
+
+You can make sure `git show-branch` matches the state before
+those two 'git merge' you just did. Then, instead of running
+two 'git merge' commands in a row, you would merge these two
+branch heads (this is known as 'making an Octopus'):
+
+------------
+$ git merge commit-fix diff-fix
+$ git show-branch
+! [commit-fix] Fix commit message normalization.
+ ! [diff-fix] Fix rename detection.
+ * [master] Octopus merge of branches 'diff-fix' and 'commit-fix'
+---
+ - [master] Octopus merge of branches 'diff-fix' and 'commit-fix'
++ * [commit-fix] Fix commit message normalization.
+ +* [diff-fix] Fix rename detection.
+ +* [diff-fix~1] Better common substring algorithm.
+ * [master~1] Release candidate #1
+++* [master~2] Pretty-print messages.
+------------
+
+Note that you should not do Octopus just because you can. An octopus
+is a valid thing to do and often makes it easier to view the
+commit history if you are merging more than two independent
+changes at the same time. However, if you have merge conflicts
+with any of the branches you are merging in and need to hand
+resolve, that is an indication that the development happened in
+those branches were not independent after all, and you should
+merge two at a time, documenting how you resolved the conflicts,
+and the reason why you preferred changes made in one side over
+the other. Otherwise it would make the project history harder
+to follow, not easier.
+
+SEE ALSO
+--------
+linkgit:gittutorial[7],
+linkgit:gittutorial-2[7],
+linkgit:gitcvs-migration[7],
+linkgit:git-help[1],
+linkgit:giteveryday[7],
+link:user-manual.html[The Git User's Manual]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitcredentials.adoc b/gitcredentials.adoc
new file mode 100644
index 0000000..3337bb4
--- /dev/null
+++ b/gitcredentials.adoc
@@ -0,0 +1,336 @@
+gitcredentials(7)
+=================
+
+NAME
+----
+gitcredentials - Providing usernames and passwords to Git
+
+SYNOPSIS
+--------
+------------------
+git config credential.https://example.com.username myusername
+git config credential.helper "$helper $options"
+------------------
+
+DESCRIPTION
+-----------
+
+Git will sometimes need credentials from the user in order to perform
+operations; for example, it may need to ask for a username and password
+in order to access a remote repository over HTTP. Some remotes accept
+a personal access token or OAuth access token as a password. This
+manual describes the mechanisms Git uses to request these credentials,
+as well as some features to avoid inputting these credentials repeatedly.
+
+REQUESTING CREDENTIALS
+----------------------
+
+Without any credential helpers defined, Git will try the following
+strategies to ask the user for usernames and passwords:
+
+1. If the `GIT_ASKPASS` environment variable is set, the program
+ specified by the variable is invoked. A suitable prompt is provided
+ to the program on the command line, and the user's input is read
+ from its standard output.
+
+2. Otherwise, if the `core.askPass` configuration variable is set, its
+ value is used as above.
+
+3. Otherwise, if the `SSH_ASKPASS` environment variable is set, its
+ value is used as above.
+
+4. Otherwise, the user is prompted on the terminal.
+
+AVOIDING REPETITION
+-------------------
+
+It can be cumbersome to input the same credentials over and over. Git
+provides two methods to reduce this annoyance:
+
+1. Static configuration of usernames for a given authentication context.
+
+2. Credential helpers to cache or store passwords, or to interact with
+ a system password wallet or keychain.
+
+The first is simple and appropriate if you do not have secure storage available
+for a password. It is generally configured by adding this to your config:
+
+---------------------------------------
+[credential "https://example.com"]
+ username = me
+---------------------------------------
+
+Credential helpers, on the other hand, are external programs from which Git can
+request both usernames and passwords; they typically interface with secure
+storage provided by the OS or other programs. Alternatively, a
+credential-generating helper might generate credentials for certain servers via
+some API.
+
+To use a helper, you must first select one to use (see below for a list).
+
+You may also have third-party helpers installed; search for
+`credential-*` in the output of `git help -a`, and consult the
+documentation of individual helpers. Once you have selected a helper,
+you can tell Git to use it by putting its name into the
+credential.helper variable.
+
+1. Find a helper.
++
+-------------------------------------------
+$ git help -a | grep credential-
+credential-foo
+-------------------------------------------
+
+2. Read its description.
++
+-------------------------------------------
+$ git help credential-foo
+-------------------------------------------
+
+3. Tell Git to use it.
++
+-------------------------------------------
+$ git config --global credential.helper foo
+-------------------------------------------
+
+=== Available helpers
+
+Git currently includes the following helpers:
+
+cache::
+
+ Cache credentials in memory for a short period of time. See
+ linkgit:git-credential-cache[1] for details.
+
+store::
+
+ Store credentials indefinitely on disk. See
+ linkgit:git-credential-store[1] for details.
+
+Popular helpers with secure persistent storage include:
+
+ - git-credential-libsecret (Linux)
+
+ - git-credential-osxkeychain (macOS)
+
+ - git-credential-wincred (Windows)
+
+ - https://github.com/git-ecosystem/git-credential-manager[Git Credential Manager] (cross platform, included in Git for Windows)
+
+The community maintains a comprehensive list of Git credential helpers at
+https://git-scm.com/doc/credential-helpers.
+
+=== OAuth
+
+An alternative to inputting passwords or personal access tokens is to use an
+OAuth credential helper. Initial authentication opens a browser window to the
+host. Subsequent authentication happens in the background. Many popular Git
+hosts support OAuth.
+
+Popular helpers with OAuth support include:
+
+ - https://github.com/git-ecosystem/git-credential-manager[Git Credential Manager] (cross platform, included in Git for Windows)
+
+ - https://github.com/hickford/git-credential-oauth[git-credential-oauth] (cross platform, included in many Linux distributions)
+
+CREDENTIAL CONTEXTS
+-------------------
+
+Git considers each credential to have a context defined by a URL. This context
+is used to look up context-specific configuration, and is passed to any
+helpers, which may use it as an index into secure storage.
+
+For instance, imagine we are accessing `https://example.com/foo.git`. When Git
+looks into a config file to see if a section matches this context, it will
+consider the two a match if the context is a more-specific subset of the
+pattern in the config file. For example, if you have this in your config file:
+
+--------------------------------------
+[credential "https://example.com"]
+ username = foo
+--------------------------------------
+
+then we will match: both protocols are the same, both hosts are the same, and
+the "pattern" URL does not care about the path component at all. However, this
+context would not match:
+
+--------------------------------------
+[credential "https://kernel.org"]
+ username = foo
+--------------------------------------
+
+because the hostnames differ. Nor would it match `foo.example.com`; Git
+compares hostnames exactly, without considering whether two hosts are part of
+the same domain. Likewise, a config entry for `http://example.com` would not
+match: Git compares the protocols exactly. However, you may use wildcards in
+the domain name and other pattern matching techniques as with the `http.<URL>.*`
+options.
+
+If the "pattern" URL does include a path component, then this too must match
+exactly: the context `https://example.com/bar/baz.git` will match a config
+entry for `https://example.com/bar/baz.git` (in addition to matching the config
+entry for `https://example.com`) but will not match a config entry for
+`https://example.com/bar`.
+
+
+CONFIGURATION OPTIONS
+---------------------
+
+Options for a credential context can be configured either in
+`credential.*` (which applies to all credentials), or
+`credential.<URL>.*`, where <URL> matches the context as described
+above.
+
+The following options are available in either location:
+
+helper::
+
+ The name of an external credential helper, and any associated options.
+ If the helper name is not an absolute path, then the string `git
+ credential-` is prepended. The resulting string is executed by the
+ shell (so, for example, setting this to `foo --option=bar` will execute
+ `git credential-foo --option=bar` via the shell. See the manual of
+ specific helpers for examples of their use.
++
+If there are multiple instances of the `credential.helper` configuration
+variable, each helper will be tried in turn, and may provide a username,
+password, or nothing. Once Git has acquired both a username and a
+non-expired password, no more helpers will be tried.
++
+If `credential.helper` is configured to the empty string, this resets
+the helper list to empty (so you may override a helper set by a
+lower-priority config file by configuring the empty-string helper,
+followed by whatever set of helpers you would like).
+
+username::
+
+ A default username, if one is not provided in the URL.
+
+useHttpPath::
+
+ By default, Git does not consider the "path" component of an http URL
+ to be worth matching via external helpers. This means that a credential
+ stored for `https://example.com/foo.git` will also be used for
+ `https://example.com/bar.git`. If you do want to distinguish these
+ cases, set this option to `true`.
+
+
+CUSTOM HELPERS
+--------------
+
+You can write your own custom helpers to interface with any system in
+which you keep credentials.
+
+Credential helpers are programs executed by Git to fetch or save
+credentials from and to long-term storage (where "long-term" is simply
+longer than a single Git process; e.g., credentials may be stored
+in-memory for a few minutes, or indefinitely on disk).
+
+Each helper is specified by a single string in the configuration
+variable `credential.helper` (and others, see linkgit:git-config[1]).
+The string is transformed by Git into a command to be executed using
+these rules:
+
+ 1. If the helper string begins with "!", it is considered a shell
+ snippet, and everything after the "!" becomes the command.
+
+ 2. Otherwise, if the helper string begins with an absolute path, the
+ verbatim helper string becomes the command.
+
+ 3. Otherwise, the string "git credential-" is prepended to the helper
+ string, and the result becomes the command.
+
+The resulting command then has an "operation" argument appended to it
+(see below for details), and the result is executed by the shell.
+
+Here are some example specifications:
+
+----------------------------------------------------
+# run "git credential-foo"
+[credential]
+ helper = foo
+
+# same as above, but pass an argument to the helper
+[credential]
+ helper = "foo --bar=baz"
+
+# the arguments are parsed by the shell, so use shell
+# quoting if necessary
+[credential]
+ helper = "foo --bar='whitespace arg'"
+
+# store helper (discouraged) with custom location for the db file;
+# use `--file ~/.git-secret.txt`, rather than `--file=~/.git-secret.txt`,
+# to allow the shell to expand tilde to the home directory.
+[credential]
+ helper = "store --file ~/.git-secret.txt"
+
+# you can also use an absolute path, which will not use the git wrapper
+[credential]
+ helper = "/path/to/my/helper --with-arguments"
+
+# or you can specify your own shell snippet
+[credential "https://example.com"]
+ username = your_user
+ helper = "!f() { test \"$1\" = get && echo \"password=$(cat $HOME/.secret)\"; }; f"
+----------------------------------------------------
+
+Generally speaking, rule (3) above is the simplest for users to specify.
+Authors of credential helpers should make an effort to assist their
+users by naming their program "git-credential-$NAME", and putting it in
+the `$PATH` or `$GIT_EXEC_PATH` during installation, which will allow a
+user to enable it with `git config credential.helper $NAME`.
+
+When a helper is executed, it will have one "operation" argument
+appended to its command line, which is one of:
+
+`get`::
+
+ Return a matching credential, if any exists.
+
+`store`::
+
+ Store the credential, if applicable to the helper.
+
+`erase`::
+
+ Remove matching credentials, if any, from the helper's storage.
+
+The details of the credential will be provided on the helper's stdin
+stream. The exact format is the same as the input/output format of the
+`git credential` plumbing command (see the section `INPUT/OUTPUT
+FORMAT` in linkgit:git-credential[1] for a detailed specification).
+
+For a `get` operation, the helper should produce a list of attributes on
+stdout in the same format (see linkgit:git-credential[1] for common
+attributes). A helper is free to produce a subset, or even no values at
+all if it has nothing useful to provide. Any provided attributes will
+overwrite those already known about by Git's credential subsystem.
+Unrecognised attributes are silently discarded.
+
+While it is possible to override all attributes, well behaving helpers
+should refrain from doing so for any attribute other than username and
+password.
+
+If a helper outputs a `quit` attribute with a value of `true` or `1`,
+no further helpers will be consulted, nor will the user be prompted
+(if no credential has been provided, the operation will then fail).
+
+Similarly, no more helpers will be consulted once both username and
+password had been provided.
+
+For a `store` or `erase` operation, the helper's output is ignored.
+
+If a helper fails to perform the requested operation or needs to notify
+the user of a potential issue, it may write to stderr.
+
+If it does not support the requested operation (e.g., a read-only store
+or generator), it should silently ignore the request.
+
+If a helper receives any other operation, it should silently ignore the
+request. This leaves room for future operations to be added (older
+helpers will just ignore the new requests).
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitcvs-migration.adoc b/gitcvs-migration.adoc
new file mode 100644
index 0000000..1cd1283
--- /dev/null
+++ b/gitcvs-migration.adoc
@@ -0,0 +1,206 @@
+gitcvs-migration(7)
+===================
+
+NAME
+----
+gitcvs-migration - Git for CVS users
+
+SYNOPSIS
+--------
+[verse]
+'git cvsimport' *
+
+DESCRIPTION
+-----------
+
+Git differs from CVS in that every working tree contains a repository with
+a full copy of the project history, and no repository is inherently more
+important than any other. However, you can emulate the CVS model by
+designating a single shared repository which people can synchronize with;
+this document explains how to do that.
+
+Some basic familiarity with Git is required. Having gone through
+linkgit:gittutorial[7] and
+linkgit:gitglossary[7] should be sufficient.
+
+Developing against a shared repository
+--------------------------------------
+
+Suppose a shared repository is set up in /pub/repo.git on the host
+foo.com. Then as an individual committer you can clone the shared
+repository over ssh with:
+
+------------------------------------------------
+$ git clone foo.com:/pub/repo.git/ my-project
+$ cd my-project
+------------------------------------------------
+
+and hack away. The equivalent of 'cvs update' is
+
+------------------------------------------------
+$ git pull origin
+------------------------------------------------
+
+which merges in any work that others might have done since the clone
+operation. If there are uncommitted changes in your working tree, commit
+them first before running git pull.
+
+[NOTE]
+================================
+The 'pull' command knows where to get updates from because of certain
+configuration variables that were set by the first 'git clone'
+command; see `git config -l` and the linkgit:git-config[1] man
+page for details.
+================================
+
+You can update the shared repository with your changes by first committing
+your changes, and then using the 'git push' command:
+
+------------------------------------------------
+$ git push origin master
+------------------------------------------------
+
+to "push" those commits to the shared repository. If someone else has
+updated the repository more recently, 'git push', like 'cvs commit', will
+complain, in which case you must pull any changes before attempting the
+push again.
+
+In the 'git push' command above we specify the name of the remote branch
+to update (`master`). If we leave that out, 'git push' tries to update
+any branches in the remote repository that have the same name as a branch
+in the local repository. So the last 'push' can be done with either of:
+
+------------
+$ git push origin
+$ git push foo.com:/pub/project.git/
+------------
+
+as long as the shared repository does not have any branches
+other than `master`.
+
+Setting Up a Shared Repository
+------------------------------
+
+We assume you have already created a Git repository for your project,
+possibly created from scratch or from a tarball (see
+linkgit:gittutorial[7]), or imported from an already existing CVS
+repository (see the next section).
+
+Assume your existing repo is at /home/alice/myproject. Create a new "bare"
+repository (a repository without a working tree) and fetch your project into
+it:
+
+------------------------------------------------
+$ mkdir /pub/my-repo.git
+$ cd /pub/my-repo.git
+$ git --bare init --shared
+$ git --bare fetch /home/alice/myproject master:master
+------------------------------------------------
+
+Next, give every team member read/write access to this repository. One
+easy way to do this is to give all the team members ssh access to the
+machine where the repository is hosted. If you don't want to give them a
+full shell on the machine, there is a restricted shell which only allows
+users to do Git pushes and pulls; see linkgit:git-shell[1].
+
+Put all the committers in the same group, and make the repository
+writable by that group:
+
+------------------------------------------------
+$ chgrp -R $group /pub/my-repo.git
+------------------------------------------------
+
+Make sure committers have a umask of at most 027, so that the directories
+they create are writable and searchable by other group members.
+
+Importing a CVS archive
+-----------------------
+
+NOTE: These instructions use the `git-cvsimport` script which ships with
+git, but other importers may provide better results. See the note in
+linkgit:git-cvsimport[1] for other options.
+
+First, install version 2.1 or higher of cvsps from
+https://github.com/andreyvit/cvsps[https://github.com/andreyvit/cvsps] and make
+sure it is in your path. Then cd to a checked out CVS working directory
+of the project you are interested in and run linkgit:git-cvsimport[1]:
+
+-------------------------------------------
+$ git cvsimport -C <destination> <module>
+-------------------------------------------
+
+This puts a Git archive of the named CVS module in the directory
+<destination>, which will be created if necessary.
+
+The import checks out from CVS every revision of every file. Reportedly
+cvsimport can average some twenty revisions per second, so for a
+medium-sized project this should not take more than a couple of minutes.
+Larger projects or remote repositories may take longer.
+
+The main trunk is stored in the Git branch named `origin`, and additional
+CVS branches are stored in Git branches with the same names. The most
+recent version of the main trunk is also left checked out on the `master`
+branch, so you can start adding your own changes right away.
+
+The import is incremental, so if you call it again next month it will
+fetch any CVS updates that have been made in the meantime. For this to
+work, you must not modify the imported branches; instead, create new
+branches for your own changes, and merge in the imported branches as
+necessary.
+
+If you want a shared repository, you will need to make a bare clone
+of the imported directory, as described above. Then treat the imported
+directory as another development clone for purposes of merging
+incremental imports.
+
+Advanced Shared Repository Management
+-------------------------------------
+
+Git allows you to specify scripts called "hooks" to be run at certain
+points. You can use these, for example, to send all commits to the shared
+repository to a mailing list. See linkgit:githooks[5].
+
+You can enforce finer grained permissions using update hooks. See
+link:howto/update-hook-example.html[Controlling access to branches using
+update hooks].
+
+Providing CVS Access to a Git Repository
+----------------------------------------
+
+It is also possible to provide true CVS access to a Git repository, so
+that developers can still use CVS; see linkgit:git-cvsserver[1] for
+details.
+
+Alternative Development Models
+------------------------------
+
+CVS users are accustomed to giving a group of developers commit access to
+a common repository. As we've seen, this is also possible with Git.
+However, the distributed nature of Git allows other development models,
+and you may want to first consider whether one of them might be a better
+fit for your project.
+
+For example, you can choose a single person to maintain the project's
+primary public repository. Other developers then clone this repository
+and each work in their own clone. When they have a series of changes that
+they're happy with, they ask the maintainer to pull from the branch
+containing the changes. The maintainer reviews their changes and pulls
+them into the primary repository, which other developers pull from as
+necessary to stay coordinated. The Linux kernel and other projects use
+variants of this model.
+
+With a small group, developers may just pull changes from each other's
+repositories without the need for a central maintainer.
+
+SEE ALSO
+--------
+linkgit:gittutorial[7],
+linkgit:gittutorial-2[7],
+linkgit:gitcore-tutorial[7],
+linkgit:gitglossary[7],
+linkgit:giteveryday[7],
+link:user-manual.html[The Git User's Manual]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitdiffcore.adoc b/gitdiffcore.adoc
new file mode 100644
index 0000000..642c512
--- /dev/null
+++ b/gitdiffcore.adoc
@@ -0,0 +1,333 @@
+gitdiffcore(7)
+==============
+
+NAME
+----
+gitdiffcore - Tweaking diff output
+
+SYNOPSIS
+--------
+[verse]
+'git diff' *
+
+DESCRIPTION
+-----------
+
+The diff commands 'git diff-index', 'git diff-files', and 'git diff-tree'
+can be told to manipulate differences they find in
+unconventional ways before showing 'diff' output. The manipulation
+is collectively called "diffcore transformation". This short note
+describes what they are and how to use them to produce 'diff' output
+that is easier to understand than the conventional kind.
+
+
+The chain of operation
+----------------------
+
+The 'git diff-{asterisk}' family works by first comparing two sets of
+files:
+
+ - 'git diff-index' compares contents of a "tree" object and the
+ working directory (when `--cached` flag is not used) or a
+ "tree" object and the index file (when `--cached` flag is
+ used);
+
+ - 'git diff-files' compares contents of the index file and the
+ working directory;
+
+ - 'git diff-tree' compares contents of two "tree" objects;
+
+In all of these cases, the commands themselves first optionally limit
+the two sets of files by any pathspecs given on their command-lines,
+and compare corresponding paths in the two resulting sets of files.
+
+The pathspecs are used to limit the world diff operates in. They remove
+the filepairs outside the specified sets of pathnames. E.g. If the
+input set of filepairs included:
+
+------------------------------------------------
+:100644 100644 bcd1234... 0123456... M junkfile
+------------------------------------------------
+
+but the command invocation was `git diff-files myfile`, then the
+junkfile entry would be removed from the list because only "myfile"
+is under consideration.
+
+The result of comparison is passed from these commands to what is
+internally called "diffcore", in a format similar to what is output
+when the -p option is not used. E.g.
+
+------------------------------------------------
+in-place edit :100644 100644 bcd1234... 0123456... M file0
+create :000000 100644 0000000... 1234567... A file4
+delete :100644 000000 1234567... 0000000... D file5
+unmerged :000000 000000 0000000... 0000000... U file6
+------------------------------------------------
+
+The diffcore mechanism is fed a list of such comparison results
+(each of which is called "filepair", although at this point each
+of them talks about a single file), and transforms such a list
+into another list. There are currently 5 such transformations:
+
+- diffcore-break
+- diffcore-rename
+- diffcore-merge-broken
+- diffcore-pickaxe
+- diffcore-order
+- diffcore-rotate
+
+These are applied in sequence. The set of filepairs 'git diff-{asterisk}'
+commands find are used as the input to diffcore-break, and
+the output from diffcore-break is used as the input to the
+next transformation. The final result is then passed to the
+output routine and generates either diff-raw format (see Output
+format sections of the manual for 'git diff-{asterisk}' commands) or
+diff-patch format.
+
+
+diffcore-break: For Splitting Up Complete Rewrites
+--------------------------------------------------
+
+The second transformation in the chain is diffcore-break, and is
+controlled by the -B option to the 'git diff-{asterisk}' commands. This is
+used to detect a filepair that represents "complete rewrite" and
+break such filepair into two filepairs that represent delete and
+create. E.g. If the input contained this filepair:
+
+------------------------------------------------
+:100644 100644 bcd1234... 0123456... M file0
+------------------------------------------------
+
+and if it detects that the file "file0" is completely rewritten,
+it changes it to:
+
+------------------------------------------------
+:100644 000000 bcd1234... 0000000... D file0
+:000000 100644 0000000... 0123456... A file0
+------------------------------------------------
+
+For the purpose of breaking a filepair, diffcore-break examines
+the extent of changes between the contents of the files before
+and after modification (i.e. the contents that have "bcd1234..."
+and "0123456..." as their SHA-1 content ID, in the above
+example). The amount of deletion of original contents and
+insertion of new material are added together, and if it exceeds
+the "break score", the filepair is broken into two. The break
+score defaults to 50% of the size of the smaller of the original
+and the result (i.e. if the edit shrinks the file, the size of
+the result is used; if the edit lengthens the file, the size of
+the original is used), and can be customized by giving a number
+after "-B" option (e.g. "-B75" to tell it to use 75%).
+
+
+diffcore-rename: For Detecting Renames and Copies
+-------------------------------------------------
+
+This transformation is used to detect renames and copies, and is
+controlled by the -M option (to detect renames) and the -C option
+(to detect copies as well) to the 'git diff-{asterisk}' commands. If the
+input contained these filepairs:
+
+------------------------------------------------
+:100644 000000 0123456... 0000000... D fileX
+:000000 100644 0000000... 0123456... A file0
+------------------------------------------------
+
+and the contents of the deleted file fileX is similar enough to
+the contents of the created file file0, then rename detection
+merges these filepairs and creates:
+
+------------------------------------------------
+:100644 100644 0123456... 0123456... R100 fileX file0
+------------------------------------------------
+
+When the "-C" option is used, the original contents of modified files,
+and deleted files (and also unmodified files, if the
+"--find-copies-harder" option is used) are considered as candidates
+of the source files in rename/copy operation. If the input were like
+these filepairs, that talk about a modified file fileY and a newly
+created file file0:
+
+------------------------------------------------
+:100644 100644 0123456... 1234567... M fileY
+:000000 100644 0000000... bcd3456... A file0
+------------------------------------------------
+
+the original contents of fileY and the resulting contents of
+file0 are compared, and if they are similar enough, they are
+changed to:
+
+------------------------------------------------
+:100644 100644 0123456... 1234567... M fileY
+:100644 100644 0123456... bcd3456... C100 fileY file0
+------------------------------------------------
+
+In both rename and copy detection, the same "extent of changes"
+algorithm used in diffcore-break is used to determine if two
+files are "similar enough", and can be customized to use
+a similarity score different from the default of 50% by giving a
+number after the "-M" or "-C" option (e.g. "-M8" to tell it to use
+8/10 = 80%).
+
+Note that when rename detection is on but both copy and break
+detection are off, rename detection adds a preliminary step that first
+checks if files are moved across directories while keeping their
+filename the same. If there is a file added to a directory whose
+contents are sufficiently similar to a file with the same name that got
+deleted from a different directory, it will mark them as renames and
+exclude them from the later quadratic step (the one that pairwise
+compares all unmatched files to find the "best" matches, determined by
+the highest content similarity). So, for example, if a deleted
+docs/ext.txt and an added docs/config/ext.txt are similar enough, they
+will be marked as a rename and prevent an added docs/ext.md that may
+be even more similar to the deleted docs/ext.txt from being considered
+as the rename destination in the later step. For this reason, the
+preliminary "match same filename" step uses a bit higher threshold to
+mark a file pair as a rename and stop considering other candidates for
+better matches. At most, one comparison is done per file in this
+preliminary pass; so if there are several remaining ext.txt files
+throughout the directory hierarchy after exact rename detection, this
+preliminary step may be skipped for those files.
+
+Note. When the "-C" option is used with `--find-copies-harder`
+option, 'git diff-{asterisk}' commands feed unmodified filepairs to
+diffcore mechanism as well as modified ones. This lets the copy
+detector consider unmodified files as copy source candidates at
+the expense of making it slower. Without `--find-copies-harder`,
+'git diff-{asterisk}' commands can detect copies only if the file that was
+copied happened to have been modified in the same changeset.
+
+
+diffcore-merge-broken: For Putting Complete Rewrites Back Together
+------------------------------------------------------------------
+
+This transformation is used to merge filepairs broken by
+diffcore-break, and not transformed into rename/copy by
+diffcore-rename, back into a single modification. This always
+runs when diffcore-break is used.
+
+For the purpose of merging broken filepairs back, it uses a
+different "extent of changes" computation from the ones used by
+diffcore-break and diffcore-rename. It counts only the deletion
+from the original, and does not count insertion. If you removed
+only 10 lines from a 100-line document, even if you added 910
+new lines to make a new 1000-line document, you did not do a
+complete rewrite. diffcore-break breaks such a case in order to
+help diffcore-rename to consider such filepairs as a candidate of
+rename/copy detection, but if filepairs broken that way were not
+matched with other filepairs to create rename/copy, then this
+transformation merges them back into the original
+"modification".
+
+The "extent of changes" parameter can be tweaked from the
+default 80% (that is, unless more than 80% of the original
+material is deleted, the broken pairs are merged back into a
+single modification) by giving a second number to -B option,
+like these:
+
+* -B50/60 (give 50% "break score" to diffcore-break, use 60%
+ for diffcore-merge-broken).
+
+* -B/60 (the same as above, since diffcore-break defaults to 50%).
+
+Note that earlier implementation left a broken pair as separate
+creation and deletion patches. This was an unnecessary hack, and
+the latest implementation always merges all the broken pairs
+back into modifications, but the resulting patch output is
+formatted differently for easier review in case of such
+a complete rewrite by showing the entire contents of the old version
+prefixed with '-', followed by the entire contents of the new
+version prefixed with '+'.
+
+
+diffcore-pickaxe: For Detecting Addition/Deletion of Specified String
+---------------------------------------------------------------------
+
+This transformation limits the set of filepairs to those that change
+specified strings between the preimage and the postimage in a certain
+way. -S<block-of-text> and -G<regular-expression> options are used to
+specify different ways these strings are sought.
+
+"-S<block-of-text>" detects filepairs whose preimage and postimage
+have different number of occurrences of the specified block of text.
+By definition, it will not detect in-file moves. Also, when a
+changeset moves a file wholesale without affecting the interesting
+string, diffcore-rename kicks in as usual, and `-S` omits the filepair
+(since the number of occurrences of that string didn't change in that
+rename-detected filepair). When used with `--pickaxe-regex`, treat
+the <block-of-text> as an extended POSIX regular expression to match,
+instead of a literal string.
+
+"-G<regular-expression>" (mnemonic: grep) detects filepairs whose
+textual diff has an added or a deleted line that matches the given
+regular expression. This means that it will detect in-file (or what
+rename-detection considers the same file) moves, which is noise. The
+implementation runs diff twice and greps, and this can be quite
+expensive. To speed things up, binary files without textconv filters
+will be ignored.
+
+When `-S` or `-G` are used without `--pickaxe-all`, only filepairs
+that match their respective criterion are kept in the output. When
+`--pickaxe-all` is used, if even one filepair matches their respective
+criterion in a changeset, the entire changeset is kept. This behavior
+is designed to make reviewing changes in the context of the whole
+changeset easier.
+
+diffcore-order: For Sorting the Output Based on Filenames
+---------------------------------------------------------
+
+This is used to reorder the filepairs according to the user's
+(or project's) taste, and is controlled by the -O option to the
+'git diff-{asterisk}' commands.
+
+This takes a text file each of whose lines is a shell glob
+pattern. Filepairs that match a glob pattern on an earlier line
+in the file are output before ones that match a later line, and
+filepairs that do not match any glob pattern are output last.
+
+As an example, a typical orderfile for the core Git probably
+would look like this:
+
+------------------------------------------------
+README
+Makefile
+Documentation
+*.h
+*.c
+t
+------------------------------------------------
+
+diffcore-rotate: For Changing At Which Path Output Starts
+---------------------------------------------------------
+
+This transformation takes one pathname, and rotates the set of
+filepairs so that the filepair for the given pathname comes first,
+optionally discarding the paths that come before it. This is used
+to implement the `--skip-to` and the `--rotate-to` options. It is
+an error when the specified pathname is not in the set of filepairs,
+but it is not useful to error out when used with "git log" family of
+commands, because it is unreasonable to expect that a given path
+would be modified by each and every commit shown by the "git log"
+command. For this reason, when used with "git log", the filepair
+that sorts the same as, or the first one that sorts after, the given
+pathname is where the output starts.
+
+Use of this transformation combined with diffcore-order will produce
+unexpected results, as the input to this transformation is likely
+not sorted when diffcore-order is in effect.
+
+
+SEE ALSO
+--------
+linkgit:git-diff[1],
+linkgit:git-diff-files[1],
+linkgit:git-diff-index[1],
+linkgit:git-diff-tree[1],
+linkgit:git-format-patch[1],
+linkgit:git-log[1],
+linkgit:gitglossary[7],
+link:user-manual.html[The Git User's Manual]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/giteveryday.adoc b/giteveryday.adoc
new file mode 100644
index 0000000..6cfdd0e
--- /dev/null
+++ b/giteveryday.adoc
@@ -0,0 +1,455 @@
+giteveryday(7)
+==============
+
+NAME
+----
+giteveryday - A useful minimum set of commands for Everyday Git
+
+SYNOPSIS
+--------
+
+Everyday Git With 20 Commands Or So
+
+DESCRIPTION
+-----------
+
+Git users can broadly be grouped into four categories for the purposes of
+describing here a small set of useful commands for everyday Git.
+
+* <<STANDALONE,Individual Developer (Standalone)>> commands are essential
+ for anybody who makes a commit, even for somebody who works alone.
+
+* If you work with other people, you will need commands listed in
+ the <<PARTICIPANT,Individual Developer (Participant)>> section as well.
+
+* People who play the <<INTEGRATOR,Integrator>> role need to learn some
+ more commands in addition to the above.
+
+* <<ADMINISTRATION,Repository Administration>> commands are for system
+ administrators who are responsible for the care and feeding
+ of Git repositories.
+
+
+Individual Developer (Standalone)[[STANDALONE]]
+-----------------------------------------------
+
+A standalone individual developer does not exchange patches with
+other people, and works alone in a single repository, using the
+following commands.
+
+ * linkgit:git-init[1] to create a new repository.
+
+ * linkgit:git-log[1] to see what happened.
+
+ * linkgit:git-switch[1] and linkgit:git-branch[1] to switch
+ branches.
+
+ * linkgit:git-add[1] to manage the index file.
+
+ * linkgit:git-diff[1] and linkgit:git-status[1] to see what
+ you are in the middle of doing.
+
+ * linkgit:git-commit[1] to advance the current branch.
+
+ * linkgit:git-restore[1] to undo changes.
+
+ * linkgit:git-merge[1] to merge between local branches.
+
+ * linkgit:git-rebase[1] to maintain topic branches.
+
+ * linkgit:git-tag[1] to mark a known point.
+
+Examples
+~~~~~~~~
+
+Use a tarball as a starting point for a new repository.::
++
+------------
+$ tar zxf frotz.tar.gz
+$ cd frotz
+$ git init
+$ git add . <1>
+$ git commit -m "import of frotz source tree."
+$ git tag v2.43 <2>
+------------
++
+<1> add everything under the current directory.
+<2> make a lightweight, unannotated tag.
+
+Create a topic branch and develop.::
++
+------------
+$ git switch -c alsa-audio <1>
+$ edit/compile/test
+$ git restore curses/ux_audio_oss.c <2>
+$ git add curses/ux_audio_alsa.c <3>
+$ edit/compile/test
+$ git diff HEAD <4>
+$ git commit -a -s <5>
+$ edit/compile/test
+$ git diff HEAD^ <6>
+$ git commit -a --amend <7>
+$ git switch master <8>
+$ git merge alsa-audio <9>
+$ git log --since='3 days ago' <10>
+$ git log v2.43.. curses/ <11>
+------------
++
+<1> create a new topic branch.
+<2> revert your botched changes in `curses/ux_audio_oss.c`.
+<3> you need to tell Git if you added a new file; removal and
+modification will be caught if you do `git commit -a` later.
+<4> to see what changes you are committing.
+<5> commit everything, as you have tested, with your sign-off.
+<6> look at all your changes including the previous commit.
+<7> amend the previous commit, adding all your new changes,
+using your original message.
+<8> switch to the master branch.
+<9> merge a topic branch into your master branch.
+<10> review commit logs; other forms to limit output can be
+combined and include `-10` (to show up to 10 commits),
+`--until=2005-12-10`, etc.
+<11> view only the changes that touch what's in `curses/`
+directory, since `v2.43` tag.
+
+
+Individual Developer (Participant)[[PARTICIPANT]]
+-------------------------------------------------
+
+A developer working as a participant in a group project needs to
+learn how to communicate with others, and uses these commands in
+addition to the ones needed by a standalone developer.
+
+ * linkgit:git-clone[1] from the upstream to prime your local
+ repository.
+
+ * linkgit:git-pull[1] and linkgit:git-fetch[1] from "origin"
+ to keep up-to-date with the upstream.
+
+ * linkgit:git-push[1] to shared repository, if you adopt CVS
+ style shared repository workflow.
+
+ * linkgit:git-format-patch[1] to prepare e-mail submission, if
+ you adopt Linux kernel-style public forum workflow.
+
+ * linkgit:git-send-email[1] to send your e-mail submission without
+ corruption by your MUA.
+
+ * linkgit:git-request-pull[1] to create a summary of changes
+ for your upstream to pull.
+
+
+Examples
+~~~~~~~~
+
+Clone the upstream and work on it. Feed changes to upstream.::
++
+------------
+$ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6
+$ cd my2.6
+$ git switch -c mine master <1>
+$ edit/compile/test; git commit -a -s <2>
+$ git format-patch master <3>
+$ git send-email --to="person <email@example.com>" 00*.patch <4>
+$ git switch master <5>
+$ git pull <6>
+$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <7>
+$ git ls-remote --heads http://git.kernel.org/.../jgarzik/libata-dev.git <8>
+$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <9>
+$ git reset --hard ORIG_HEAD <10>
+$ git gc <11>
+------------
++
+<1> checkout a new branch `mine` from master.
+<2> repeat as needed.
+<3> extract patches from your branch, relative to master,
+<4> and email them.
+<5> return to `master`, ready to see what's new
+<6> `git pull` fetches from `origin` by default and merges into the
+current branch.
+<7> immediately after pulling, look at the changes done upstream
+since last time we checked, only in the
+area we are interested in.
+<8> check the branch names in an external repository (if not known).
+<9> fetch from a specific branch `ALL` from a specific repository
+and merge it.
+<10> revert the pull.
+<11> garbage collect leftover objects from reverted pull.
+
+
+Push into another repository.::
++
+------------
+satellite$ git clone mothership:frotz frotz <1>
+satellite$ cd frotz
+satellite$ git config --get-regexp '^(remote|branch)\.' <2>
+remote.origin.url mothership:frotz
+remote.origin.fetch refs/heads/*:refs/remotes/origin/*
+branch.master.remote origin
+branch.master.merge refs/heads/master
+satellite$ git config remote.origin.push \
+ +refs/heads/*:refs/remotes/satellite/* <3>
+satellite$ edit/compile/test/commit
+satellite$ git push origin <4>
+
+mothership$ cd frotz
+mothership$ git switch master
+mothership$ git merge satellite/master <5>
+------------
++
+<1> mothership machine has a frotz repository under your home
+directory; clone from it to start a repository on the satellite
+machine.
+<2> clone sets these configuration variables by default.
+It arranges `git pull` to fetch and store the branches of mothership
+machine to local `remotes/origin/*` remote-tracking branches.
+<3> arrange `git push` to push all local branches to
+their corresponding branch of the mothership machine.
+<4> push will stash all our work away on `remotes/satellite/*`
+remote-tracking branches on the mothership machine. You could use this
+as a back-up method. Likewise, you can pretend that mothership
+"fetched" from you (useful when access is one sided).
+<5> on mothership machine, merge the work done on the satellite
+machine into the master branch.
+
+Branch off of a specific tag.::
++
+------------
+$ git switch -c private2.6.14 v2.6.14 <1>
+$ edit/compile/test; git commit -a
+$ git checkout master
+$ git cherry-pick v2.6.14..private2.6.14 <2>
+------------
++
+<1> create a private branch based on a well known (but somewhat behind)
+tag.
+<2> forward port all changes in `private2.6.14` branch to `master` branch
+without a formal "merging". Or longhand +
+`git format-patch -k -m --stdout v2.6.14..private2.6.14 |
+ git am -3 -k`
+
+An alternate participant submission mechanism is using the
+`git request-pull` or pull-request mechanisms (e.g. as used on
+GitHub (www.github.com) to notify your upstream of your
+contribution.
+
+Integrator[[INTEGRATOR]]
+------------------------
+
+A fairly central person acting as the integrator in a group
+project receives changes made by others, reviews and integrates
+them and publishes the result for others to use, using these
+commands in addition to the ones needed by participants.
+
+This section can also be used by those who respond to `git
+request-pull` or pull-request on GitHub (www.github.com) to
+integrate the work of others into their history. A sub-area
+lieutenant for a repository will act both as a participant and
+as an integrator.
+
+
+ * linkgit:git-am[1] to apply patches e-mailed in from your
+ contributors.
+
+ * linkgit:git-pull[1] to merge from your trusted lieutenants.
+
+ * linkgit:git-format-patch[1] to prepare and send suggested
+ alternative to contributors.
+
+ * linkgit:git-revert[1] to undo botched commits.
+
+ * linkgit:git-push[1] to publish the bleeding edge.
+
+
+Examples
+~~~~~~~~
+
+A typical integrator's Git day.::
++
+------------
+$ git status <1>
+$ git branch --no-merged master <2>
+$ mailx <3>
+& s 2 3 4 5 ./+to-apply
+& s 7 8 ./+hold-linus
+& q
+$ git switch -c topic/one master
+$ git am -3 -i -s ./+to-apply <4>
+$ compile/test
+$ git switch -c hold/linus && git am -3 -i -s ./+hold-linus <5>
+$ git switch topic/one && git rebase master <6>
+$ git switch -C seen next <7>
+$ git merge topic/one topic/two && git merge hold/linus <8>
+$ git switch maint
+$ git cherry-pick master~4 <9>
+$ compile/test
+$ git tag -s -m "GIT 0.99.9x" v0.99.9x <10>
+$ git fetch ko && for branch in master maint next seen <11>
+ do
+ git show-branch ko/$branch $branch <12>
+ done
+$ git push --follow-tags ko <13>
+------------
++
+<1> see what you were in the middle of doing, if anything.
+<2> see which branches haven't been merged into `master` yet.
+Likewise for any other integration branches e.g. `maint`, `next`
+and `seen`.
+<3> read mails, save ones that are applicable, and save others
+that are not quite ready (other mail readers are available).
+<4> apply them, interactively, with your sign-offs.
+<5> create topic branch as needed and apply, again with sign-offs.
+<6> rebase internal topic branch that has not been merged to the
+master or exposed as a part of a stable branch.
+<7> restart `seen` every time from the next.
+<8> and bundle topic branches still cooking.
+<9> backport a critical fix.
+<10> create a signed tag.
+<11> make sure master was not accidentally rewound beyond that
+already pushed out.
+<12> In the output from `git show-branch`, `master` should have
+everything `ko/master` has, and `next` should have
+everything `ko/next` has, etc.
+<13> push out the bleeding edge, together with new tags that point
+into the pushed history.
+
+In this example, the `ko` shorthand points at the Git maintainer's
+repository at kernel.org, and looks like this:
+
+------------
+(in .git/config)
+[remote "ko"]
+ url = kernel.org:/pub/scm/git/git.git
+ fetch = refs/heads/*:refs/remotes/ko/*
+ push = refs/heads/master
+ push = refs/heads/next
+ push = +refs/heads/seen
+ push = refs/heads/maint
+------------
+
+
+Repository Administration[[ADMINISTRATION]]
+-------------------------------------------
+
+A repository administrator uses the following tools to set up
+and maintain access to the repository by developers.
+
+ * linkgit:git-daemon[1] to allow anonymous download from
+ repository.
+
+ * linkgit:git-shell[1] can be used as a 'restricted login shell'
+ for shared central repository users.
+
+ * linkgit:git-http-backend[1] provides a server side implementation
+ of Git-over-HTTP ("Smart http") allowing both fetch and push services.
+
+ * linkgit:gitweb[1] provides a web front-end to Git repositories,
+ which can be set-up using the linkgit:git-instaweb[1] script.
+
+link:howto/update-hook-example.html[update hook howto] has a good
+example of managing a shared central repository.
+
+In addition there are a number of other widely deployed hosting, browsing
+and reviewing solutions such as:
+
+ * gitolite, gerrit code review, cgit and others.
+
+Examples
+~~~~~~~~
+We assume the following in /etc/services::
++
+------------
+$ grep 9418 /etc/services
+git 9418/tcp # Git Version Control System
+------------
+
+Run git-daemon to serve /pub/scm from inetd.::
++
+------------
+$ grep git /etc/inetd.conf
+git stream tcp nowait nobody \
+ /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm
+------------
++
+The actual configuration line should be on one line.
+
+Run git-daemon to serve /pub/scm from xinetd.::
++
+------------
+$ cat /etc/xinetd.d/git-daemon
+# default: off
+# description: The Git server offers access to Git repositories
+service git
+{
+ disable = no
+ type = UNLISTED
+ port = 9418
+ socket_type = stream
+ wait = no
+ user = nobody
+ server = /usr/bin/git-daemon
+ server_args = --inetd --export-all --base-path=/pub/scm
+ log_on_failure += USERID
+}
+------------
++
+Check your xinetd(8) documentation and setup, this is from a Fedora system.
+Others might be different.
+
+Give push/pull only access to developers using git-over-ssh.::
+
+e.g. those using:
+`$ git push/pull ssh://host.xz/pub/scm/project`
++
+------------
+$ grep git /etc/passwd <1>
+alice:x:1000:1000::/home/alice:/usr/bin/git-shell
+bob:x:1001:1001::/home/bob:/usr/bin/git-shell
+cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell
+david:x:1003:1003::/home/david:/usr/bin/git-shell
+$ grep git /etc/shells <2>
+/usr/bin/git-shell
+------------
++
+<1> log-in shell is set to /usr/bin/git-shell, which does not
+allow anything but `git push` and `git pull`. The users require
+ssh access to the machine.
+<2> in many distributions /etc/shells needs to list what is used
+as the login shell.
+
+CVS-style shared repository.::
++
+------------
+$ grep git /etc/group <1>
+git:x:9418:alice,bob,cindy,david
+$ cd /home/devo.git
+$ ls -l <2>
+ lrwxrwxrwx 1 david git 17 Dec 4 22:40 HEAD -> refs/heads/master
+ drwxrwsr-x 2 david git 4096 Dec 4 22:40 branches
+ -rw-rw-r-- 1 david git 84 Dec 4 22:40 config
+ -rw-rw-r-- 1 david git 58 Dec 4 22:40 description
+ drwxrwsr-x 2 david git 4096 Dec 4 22:40 hooks
+ -rw-rw-r-- 1 david git 37504 Dec 4 22:40 index
+ drwxrwsr-x 2 david git 4096 Dec 4 22:40 info
+ drwxrwsr-x 4 david git 4096 Dec 4 22:40 objects
+ drwxrwsr-x 4 david git 4096 Nov 7 14:58 refs
+ drwxrwsr-x 2 david git 4096 Dec 4 22:40 remotes
+$ ls -l hooks/update <3>
+ -r-xr-xr-x 1 david git 3536 Dec 4 22:40 update
+$ cat info/allowed-users <4>
+refs/heads/master alice\|cindy
+refs/heads/doc-update bob
+refs/tags/v[0-9]* david
+------------
++
+<1> place the developers into the same git group.
+<2> and make the shared repository writable by the group.
+<3> use update-hook example by Carl from Documentation/howto/
+for branch policy control.
+<4> alice and cindy can push into master, only bob can push into doc-update.
+david is the release manager and is the only person who can
+create and push version tags.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitfaq.adoc b/gitfaq.adoc
new file mode 100644
index 0000000..f2917d1
--- /dev/null
+++ b/gitfaq.adoc
@@ -0,0 +1,542 @@
+gitfaq(7)
+=========
+
+NAME
+----
+gitfaq - Frequently asked questions about using Git
+
+SYNOPSIS
+--------
+gitfaq
+
+DESCRIPTION
+-----------
+
+The examples in this FAQ assume a standard POSIX shell, like `bash` or `dash`,
+and a user, A U Thor, who has the account `author` on the hosting provider
+`git.example.org`.
+
+Configuration
+-------------
+
+[[user-name]]
+What should I put in `user.name`?::
+ You should put your personal name, generally a form using a given name
+ and family name. For example, the current maintainer of Git uses "Junio
+ C Hamano". This will be the name portion that is stored in every commit
+ you make.
++
+This configuration doesn't have any effect on authenticating to remote services;
+for that, see `credential.username` in linkgit:git-config[1].
+
+[[http-postbuffer]]
+What does `http.postBuffer` really do?::
+ This option changes the size of the buffer that Git uses when pushing
+ data to a remote over HTTP or HTTPS. If the data is larger than this
+ size, libcurl, which handles the HTTP support for Git, will use chunked
+ transfer encoding since it isn't known ahead of time what the size of
+ the pushed data will be.
++
+Leaving this value at the default size is fine unless you know that either the
+remote server or a proxy in the middle doesn't support HTTP/1.1 (which
+introduced the chunked transfer encoding) or is known to be broken with chunked
+data. This is often (erroneously) suggested as a solution for generic push
+problems, but since almost every server and proxy supports at least HTTP/1.1,
+raising this value usually doesn't solve most push problems. A server or proxy
+that didn't correctly support HTTP/1.1 and chunked transfer encoding wouldn't be
+that useful on the Internet today, since it would break lots of traffic.
++
+Note that increasing this value will increase the memory used on every relevant
+push that Git does over HTTP or HTTPS, since the entire buffer is allocated
+regardless of whether or not it is all used. Thus, it's best to leave it at the
+default unless you are sure you need a different value.
+
+[[configure-editor]]
+How do I configure a different editor?::
+ If you haven't specified an editor specifically for Git, it will by default
+ use the editor you've configured using the `VISUAL` or `EDITOR` environment
+ variables, or if neither is specified, the system default (which is usually
+ `vi`). Since some people find `vi` difficult to use or prefer a different
+ editor, it may be desirable to change the editor used.
++
+If you want to configure a general editor for most programs which need one, you
+can edit your shell configuration (e.g., `~/.bashrc` or `~/.zshenv`) to contain
+a line setting the `EDITOR` or `VISUAL` environment variable to an appropriate
+value. For example, if you prefer the editor `nano`, then you could write the
+following:
++
+----
+export VISUAL=nano
+----
++
+If you want to configure an editor specifically for Git, you can either set the
+`core.editor` configuration value or the `GIT_EDITOR` environment variable. You
+can see linkgit:git-var[1] for details on the order in which these options are
+consulted.
++
+Note that in all cases, the editor value will be passed to the shell, so any
+arguments containing spaces should be appropriately quoted. Additionally, if
+your editor normally detaches from the terminal when invoked, you should specify
+it with an argument that makes it not do that, or else Git will not see any
+changes. An example of a configuration addressing both of these issues on
+Windows would be the configuration `"C:\Program Files\Vim\gvim.exe" --nofork`,
+which quotes the filename with spaces and specifies the `--nofork` option to
+avoid backgrounding the process.
+
+Credentials
+-----------
+
+[[http-credentials]]
+How do I specify my credentials when pushing over HTTP?::
+ The easiest way to do this is to use a credential helper via the
+ `credential.helper` configuration. Most systems provide a standard
+ choice to integrate with the system credential manager. For example,
+ Git for Windows provides the `wincred` credential manager, macOS has the
+ `osxkeychain` credential manager, and Unix systems with a standard
+ desktop environment can use the `libsecret` credential manager. All of
+ these store credentials in an encrypted store to keep your passwords or
+ tokens secure.
++
+In addition, you can use the `store` credential manager which stores in a file
+in your home directory, or the `cache` credential manager, which does not
+permanently store your credentials, but does prevent you from being prompted for
+them for a certain period of time.
++
+You can also just enter your password when prompted. While it is possible to
+place the password (which must be percent-encoded) in the URL, this is not
+particularly secure and can lead to accidental exposure of credentials, so it is
+not recommended.
+
+[[http-credentials-environment]]
+How do I read a password or token from an environment variable?::
+ The `credential.helper` configuration option can also take an arbitrary
+ shell command that produces the credential protocol on standard output.
+ This is useful when passing credentials into a container, for example.
++
+Such a shell command can be specified by starting the option value with an
+exclamation point. If your password or token were stored in the `GIT_TOKEN`,
+you could run the following command to set your credential helper:
++
+----
+$ git config credential.helper \
+ '!f() { echo username=author; echo "password=$GIT_TOKEN"; };f'
+----
+
+[[http-reset-credentials]]
+How do I change the password or token I've saved in my credential manager?::
+ Usually, if the password or token is invalid, Git will erase it and
+ prompt for a new one. However, there are times when this doesn't always
+ happen. To change the password or token, you can erase the existing
+ credentials and then Git will prompt for new ones. To erase
+ credentials, use a syntax like the following (substituting your username
+ and the hostname):
++
+----
+$ echo url=https://author@git.example.org | git credential reject
+----
+
+[[multiple-accounts-http]]
+How do I use multiple accounts with the same hosting provider using HTTP?::
+ Usually the easiest way to distinguish between these accounts is to use
+ the username in the URL. For example, if you have the accounts `author`
+ and `committer` on `git.example.org`, you can use the URLs
+ https://author@git.example.org/org1/project1.git and
+ https://committer@git.example.org/org2/project2.git. This way, when you
+ use a credential helper, it will automatically try to look up the
+ correct credentials for your account. If you already have a remote set
+ up, you can change the URL with something like `git remote set-url
+ origin https://author@git.example.org/org1/project1.git` (see
+ linkgit:git-remote[1] for details).
+
+[[multiple-accounts-ssh]]
+How do I use multiple accounts with the same hosting provider using SSH?::
+ With most hosting providers that support SSH, a single key pair uniquely
+ identifies a user. Therefore, to use multiple accounts, it's necessary
+ to create a key pair for each account. If you're using a reasonably
+ modern OpenSSH version, you can create a new key pair with something
+ like `ssh-keygen -t ed25519 -f ~/.ssh/id_committer`. You can then
+ register the public key (in this case, `~/.ssh/id_committer.pub`; note
+ the `.pub`) with the hosting provider.
++
+Most hosting providers use a single SSH account for pushing; that is, all users
+push to the `git` account (e.g., `git@git.example.org`). If that's the case for
+your provider, you can set up multiple aliases in SSH to make it clear which key
+pair to use. For example, you could write something like the following in
+`~/.ssh/config`, substituting the proper private key file:
++
+----
+# This is the account for author on git.example.org.
+Host example_author
+ HostName git.example.org
+ User git
+ # This is the key pair registered for author with git.example.org.
+ IdentityFile ~/.ssh/id_author
+ IdentitiesOnly yes
+# This is the account for committer on git.example.org.
+Host example_committer
+ HostName git.example.org
+ User git
+ # This is the key pair registered for committer with git.example.org.
+ IdentityFile ~/.ssh/id_committer
+ IdentitiesOnly yes
+----
++
+Then, you can adjust your push URL to use `git@example_author` or
+`git@example_committer` instead of `git@example.org` (e.g., `git remote set-url
+git@example_author:org1/project1.git`).
+
+Transfers
+---------
+
+[[sync-working-tree]]
+How do I sync a working tree across systems?::
+ First, decide whether you want to do this at all. Git works best when you
+ push or pull your work using the typical `git push` and `git fetch` commands
+ and isn't designed to share a working tree across systems. This is
+ potentially risky and in some cases can cause repository corruption or data
+ loss.
++
+Usually, doing so will cause `git status` to need to re-read every file in the
+working tree. Additionally, Git's security model does not permit sharing a
+working tree across untrusted users, so it is only safe to sync a working tree
+if it will only be used by a single user across all machines.
++
+It is important not to use a cloud syncing service to sync any portion of a Git
+repository, since this can cause corruption, such as missing objects, changed
+or added files, broken refs, and a wide variety of other problems. These
+services tend to sync file by file on a continuous basis and don't understand
+the structure of a Git repository. This is especially bad if they sync the
+repository in the middle of it being updated, since that is very likely to
+cause incomplete or partial updates and therefore data loss.
++
+An example of the kind of corruption that can occur is conflicts over the state
+of refs, such that both sides end up with different commits on a branch that
+the other doesn't have. This can result in important objects becoming
+unreferenced and possibly pruned by `git gc`, causing data loss.
++
+Therefore, it's better to push your work to either the other system or a central
+server using the normal push and pull mechanism. However, this doesn't always
+preserve important data, like stashes, so some people prefer to share a working
+tree across systems.
++
+If you do this, the recommended approach is to use `rsync -a --delete-after`
+(ideally with an encrypted connection such as with `ssh`) on the root of
+repository. You should ensure several things when you do this:
++
+* If you have additional worktrees or a separate Git directory, they must be
+ synced at the same time as the main working tree and repository.
+* You are comfortable with the destination directory being an exact copy of the
+ source directory, _deleting any data that is already there_.
+* The repository (including all worktrees and the Git directory) is in a
+ quiescent state for the duration of the transfer (that is, no operations of
+ any sort are taking place on it, including background operations like `git
+ gc` and operations invoked by your editor).
++
+Be aware that even with these recommendations, syncing in this way has some risk
+since it bypasses Git's normal integrity checking for repositories, so having
+backups is advised. You may also wish to do a `git fsck` to verify the
+integrity of your data on the destination system after syncing.
+
+Common Issues
+-------------
+
+[[last-commit-amend]]
+I've made a mistake in the last commit. How do I change it?::
+ You can make the appropriate change to your working tree, run `git add
+ <file>` or `git rm <file>`, as appropriate, to stage it, and then `git
+ commit --amend`. Your change will be included in the commit, and you'll
+ be prompted to edit the commit message again; if you wish to use the
+ original message verbatim, you can use the `--no-edit` option to `git
+ commit` in addition, or just save and quit when your editor opens.
+
+[[undo-previous-change]]
+I've made a change with a bug and it's been included in the main branch. How should I undo it?::
+ The usual way to deal with this is to use `git revert`. This preserves
+ the history that the original change was made and was a valuable
+ contribution, but also introduces a new commit that undoes those changes
+ because the original had a problem. The commit message of the revert
+ indicates the commit which was reverted and is usually edited to include
+ an explanation as to why the revert was made.
+
+[[ignore-tracked-files]]
+How do I ignore changes to a tracked file?::
+ Git doesn't provide a way to do this. The reason is that if Git needs
+ to overwrite this file, such as during a checkout, it doesn't know
+ whether the changes to the file are precious and should be kept, or
+ whether they are irrelevant and can safely be destroyed. Therefore, it
+ has to take the safe route and always preserve them.
++
+It's tempting to try to use certain features of `git update-index`, namely the
+assume-unchanged and skip-worktree bits, but these don't work properly for this
+purpose and shouldn't be used this way.
++
+If your goal is to modify a configuration file, it can often be helpful to have
+a file checked into the repository which is a template or set of defaults which
+can then be copied alongside and modified as appropriate. This second, modified
+file is usually ignored to prevent accidentally committing it.
+
+[[files-in-gitignore-are-tracked]]
+I asked Git to ignore various files, yet they are still tracked::
+ A `gitignore` file ensures that certain file(s) which are not
+ tracked by Git remain untracked. However, sometimes particular
+ file(s) may have been tracked before adding them into the
+ `.gitignore`, hence they still remain tracked. To untrack and
+ ignore files/patterns, use `git rm --cached <file/pattern>`
+ and add a pattern to `.gitignore` that matches the <file>.
+ See linkgit:gitignore[5] for details.
+
+[[fetching-and-pulling]]
+How do I know if I want to do a fetch or a pull?::
+ A fetch stores a copy of the latest changes from the remote
+ repository, without modifying the working tree or current branch.
+ You can then at your leisure inspect, merge, rebase on top of, or
+ ignore the upstream changes. A pull consists of a fetch followed
+ immediately by either a merge or rebase. See linkgit:git-pull[1].
+
+[[proxy]]
+Can I use a proxy with Git?::
+ Yes, Git supports the use of proxies. Git honors the standard `http_proxy`,
+ `https_proxy`, and `no_proxy` environment variables commonly used on Unix, and
+ it also can be configured with `http.proxy` and similar options for HTTPS (see
+ linkgit:git-config[1]). The `http.proxy` and related options can be
+ customized on a per-URL pattern basis. In addition, Git can in theory
+ function normally with transparent proxies that exist on the network.
++
+For SSH, Git can support a proxy using OpenSSH's `ProxyCommand`. Commonly used
+tools include `netcat` and `socat`. However, they must be configured not to
+exit when seeing EOF on standard input, which usually means that `netcat` will
+require `-q` and `socat` will require a timeout with something like `-t 10`.
+This is required because the way the Git SSH server knows that no more requests
+will be made is an EOF on standard input, but when that happens, the server may
+not have yet processed the final request, so dropping the connection at that
+point would interrupt that request.
++
+An example configuration entry in `~/.ssh/config` with an HTTP proxy might look
+like this:
++
+----
+Host git.example.org
+ User git
+ ProxyCommand socat -t 10 - PROXY:proxy.example.org:%h:%p,proxyport=8080
+----
++
+Note that in all cases, for Git to work properly, the proxy must be completely
+transparent. The proxy cannot modify, tamper with, or buffer the connection in
+any way, or Git will almost certainly fail to work. Note that many proxies,
+including many TLS middleboxes, Windows antivirus and firewall programs other
+than Windows Defender and Windows Firewall, and filtering proxies fail to meet
+this standard, and as a result end up breaking Git. Because of the many
+reports of problems and their poor security history, we recommend against the
+use of these classes of software and devices.
+
+Merging and Rebasing
+--------------------
+
+[[long-running-squash-merge]]
+What kinds of problems can occur when merging long-lived branches with squash merges?::
+ In general, there are a variety of problems that can occur when using squash
+ merges to merge two branches multiple times. These can include seeing extra
+ commits in `git log` output, with a GUI, or when using the `...` notation to
+ express a range, as well as the possibility of needing to re-resolve conflicts
+ again and again.
++
+When Git does a normal merge between two branches, it considers exactly three
+points: the two branches and a third commit, called the _merge base_, which is
+usually the common ancestor of the commits. The result of the merge is the sum
+of the changes between the merge base and each head. When you merge two
+branches with a regular merge commit, this results in a new commit which will
+end up as a merge base when they're merged again, because there is now a new
+common ancestor. Git doesn't have to consider changes that occurred before the
+merge base, so you don't have to re-resolve any conflicts you resolved before.
++
+When you perform a squash merge, a merge commit isn't created; instead, the
+changes from one side are applied as a regular commit to the other side. This
+means that the merge base for these branches won't have changed, and so when Git
+goes to perform its next merge, it considers all of the changes that it
+considered the last time plus the new changes. That means any conflicts may
+need to be re-resolved. Similarly, anything using the `...` notation in `git
+diff`, `git log`, or a GUI will result in showing all of the changes since the
+original merge base.
++
+As a consequence, if you want to merge two long-lived branches repeatedly, it's
+best to always use a regular merge commit.
+
+[[merge-two-revert-one]]
+If I make a change on two branches but revert it on one, why does the merge of those branches include the change?::
+ By default, when Git does a merge, it uses a strategy called the `ort`
+ strategy, which does a fancy three-way merge. In such a case, when Git
+ performs the merge, it considers exactly three points: the two heads and a
+ third point, called the _merge base_, which is usually the common ancestor of
+ those commits. Git does not consider the history or the individual commits
+ that have happened on those branches at all.
++
+As a result, if both sides have a change and one side has reverted that change,
+the result is to include the change. This is because the code has changed on
+one side and there is no net change on the other, and in this scenario, Git
+adopts the change.
++
+If this is a problem for you, you can do a rebase instead, rebasing the branch
+with the revert onto the other branch. A rebase in this scenario will revert
+the change, because a rebase applies each individual commit, including the
+revert. Note that rebases rewrite history, so you should avoid rebasing
+published branches unless you're sure you're comfortable with that. See the
+NOTES section in linkgit:git-rebase[1] for more details.
+
+Hooks
+-----
+
+[[restrict-with-hooks]]
+How do I use hooks to prevent users from making certain changes?::
+ The only safe place to make these changes is on the remote repository
+ (i.e., the Git server), usually in the `pre-receive` hook or in a
+ continuous integration (CI) system. These are the locations in which
+ policy can be enforced effectively.
++
+It's common to try to use `pre-commit` hooks (or, for commit messages,
+`commit-msg` hooks) to check these things, which is great if you're working as a
+solo developer and want the tooling to help you. However, using hooks on a
+developer machine is not effective as a policy control because a user can bypass
+these hooks with `--no-verify` without being noticed (among various other ways).
+Git assumes that the user is in control of their local repositories and doesn't
+try to prevent this or tattle on the user.
++
+In addition, some advanced users find `pre-commit` hooks to be an impediment to
+workflows that use temporary commits to stage work in progress or that create
+fixup commits, so it's better to push these kinds of checks to the server
+anyway.
+
+Cross-Platform Issues
+---------------------
+
+[[windows-text-binary]]
+I'm on Windows and my text files are detected as binary.::
+ Git works best when you store text files as UTF-8. Many programs on
+ Windows support UTF-8, but some do not and only use the little-endian
+ UTF-16 format, which Git detects as binary. If you can't use UTF-8 with
+ your programs, you can specify a working tree encoding that indicates
+ which encoding your files should be checked out with, while still
+ storing these files as UTF-8 in the repository. This allows tools like
+ linkgit:git-diff[1] to work as expected, while still allowing your tools
+ to work.
++
+To do so, you can specify a linkgit:gitattributes[5] pattern with the
+`working-tree-encoding` attribute. For example, the following pattern sets all
+C files to use UTF-16LE-BOM, which is a common encoding on Windows:
++
+----
+*.c working-tree-encoding=UTF-16LE-BOM
+----
++
+You will need to run `git add --renormalize` to have this take effect. Note
+that if you are making these changes on a project that is used across platforms,
+you'll probably want to make it in a per-user configuration file or in the one
+in `$GIT_DIR/info/attributes`, since making it in a `.gitattributes` file in the
+repository will apply to all users of the repository.
++
+See the following entry for information about normalizing line endings as well,
+and see linkgit:gitattributes[5] for more information about attribute files.
+
+[[windows-diff-control-m]]
+I'm on Windows and git diff shows my files as having a `^M` at the end.::
+ By default, Git expects files to be stored with Unix line endings. As such,
+ the carriage return (`^M`) that is part of a Windows line ending is shown
+ because it is considered to be trailing whitespace. Git defaults to showing
+ trailing whitespace only on new lines, not existing ones.
++
+You can store the files in the repository with Unix line endings and convert
+them automatically to your platform's line endings. To do that, set the
+configuration option `core.eol` to `native` and see
+<<recommended-storage-settings,the question on recommended storage settings>>
+for information about how to configure files as text or binary.
++
+You can also control this behavior with the `core.whitespace` setting if you
+don't wish to remove the carriage returns from your line endings.
+
+[[always-modified-files-case]]
+Why do I have a file that's always modified?::
+ Internally, Git always stores file names as sequences of bytes and doesn't
+ perform any encoding or case folding. However, Windows and macOS by default
+ both perform case folding on file names. As a result, it's possible to end up
+ with multiple files or directories whose names differ only in case. Git can
+ handle this just fine, but the file system can store only one of these files,
+ so when Git reads the other file to see its contents, it looks modified.
++
+It's best to remove one of the files such that you only have one file. You can
+do this with commands like the following (assuming two files `AFile.txt` and
+`afile.txt`) on an otherwise clean working tree:
++
+----
+$ git rm --cached AFile.txt
+$ git commit -m 'Remove files conflicting in case'
+$ git checkout .
+----
++
+This avoids touching the disk, but removes the additional file. Your project
+may prefer to adopt a naming convention, such as all-lowercase names, to avoid
+this problem from occurring again; such a convention can be checked using a
+`pre-receive` hook or as part of a continuous integration (CI) system.
++
+It is also possible for perpetually modified files to occur on any platform if a
+smudge or clean filter is in use on your system but a file was previously
+committed without running the smudge or clean filter. To fix this, run the
+following on an otherwise clean working tree:
++
+----
+$ git add --renormalize .
+----
+
+[[recommended-storage-settings]]
+What's the recommended way to store files in Git?::
+ While Git can store and handle any file of any type, there are some
+ settings that work better than others. In general, we recommend that
+ text files be stored in UTF-8 without a byte-order mark (BOM) with LF
+ (Unix-style) endings. We also recommend the use of UTF-8 (again,
+ without BOM) in commit messages. These are the settings that work best
+ across platforms and with tools such as `git diff` and `git merge`.
++
+Additionally, if you have a choice between storage formats that are text based
+or non-text based, we recommend storing files in the text format and, if
+necessary, transforming them into the other format. For example, a text-based
+SQL dump with one record per line will work much better for diffing and merging
+than an actual database file. Similarly, text-based formats such as Markdown
+and AsciiDoc will work better than binary formats such as Microsoft Word and
+PDF.
++
+Similarly, storing binary dependencies (e.g., shared libraries or JAR files) or
+build products in the repository is generally not recommended. Dependencies and
+build products are best stored on an artifact or package server with only
+references, URLs, and hashes stored in the repository.
++
+We also recommend setting a linkgit:gitattributes[5] file to explicitly mark
+which files are text and which are binary. If you want Git to guess, you can
+set the attribute `text=auto`.
++
+With text files, Git will generally ensure that LF endings are used in the
+repository. The `core.autocrlf` and `core.eol` configuration variables specify
+what line-ending convention is followed when any text file is checked out. You
+can also use the `eol` attribute (e.g., `eol=crlf`) to override which files get
+what line-ending treatment.
++
+For example, generally shell files must have LF endings and batch files must
+have CRLF endings, so the following might be appropriate in some projects:
++
+----
+# By default, guess.
+* text=auto
+# Mark all C files as text.
+*.c text
+# Ensure all shell files have LF endings and all batch files have CRLF
+# endings in the working tree and both have LF in the repo.
+*.sh text eol=lf
+*.bat text eol=crlf
+# Mark all JPEG files as binary.
+*.jpg binary
+----
++
+These settings help tools pick the right format for output such as patches and
+result in files being checked out in the appropriate line ending for the
+platform.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitformat-bundle.adoc b/gitformat-bundle.adoc
new file mode 100644
index 0000000..1b75cf7
--- /dev/null
+++ b/gitformat-bundle.adoc
@@ -0,0 +1,111 @@
+gitformat-bundle(5)
+===================
+
+NAME
+----
+gitformat-bundle - The bundle file format
+
+
+SYNOPSIS
+--------
+[verse]
+*.bundle
+*.bdl
+
+DESCRIPTION
+-----------
+
+The Git bundle format is a format that represents both refs and Git
+objects. A bundle is a header in a format similar to
+linkgit:git-show-ref[1] followed by a pack in *.pack format.
+
+The format is created and read by the linkgit:git-bundle[1] command,
+and supported by e.g. linkgit:git-fetch[1] and linkgit:git-clone[1].
+
+
+FORMAT
+------
+
+We will use ABNF notation to define the Git bundle format. See
+linkgit:gitprotocol-common[5] for the details.
+
+A v2 bundle looks like this:
+
+----
+bundle = signature *prerequisite *reference LF pack
+signature = "# v2 git bundle" LF
+
+prerequisite = "-" obj-id SP comment LF
+comment = *CHAR
+reference = obj-id SP refname LF
+
+pack = ... ; packfile
+----
+
+A v3 bundle looks like this:
+
+----
+bundle = signature *capability *prerequisite *reference LF pack
+signature = "# v3 git bundle" LF
+
+capability = "@" key ["=" value] LF
+prerequisite = "-" obj-id SP comment LF
+comment = *CHAR
+reference = obj-id SP refname LF
+key = 1*(ALPHA / DIGIT / "-")
+value = *(%01-09 / %0b-FF)
+
+pack = ... ; packfile
+----
+
+
+SEMANTICS
+---------
+
+A Git bundle consists of several parts.
+
+* "Capabilities", which are only in the v3 format, indicate functionality that
+ the bundle requires to be read properly.
+
+* "Prerequisites" list the objects that are NOT included in the bundle and the
+ reader of the bundle MUST already have, in order to use the data in the
+ bundle. The objects stored in the bundle may refer to prerequisite objects and
+ anything reachable from them (e.g. a tree object in the bundle can reference
+ a blob that is reachable from a prerequisite) and/or expressed as a delta
+ against prerequisite objects.
+
+* "References" record the tips of the history graph, iow, what the reader of the
+ bundle CAN "git fetch" from it.
+
+* "Pack" is the pack data stream "git fetch" would send, if you fetch from a
+ repository that has the references recorded in the "References" above into a
+ repository that has references pointing at the objects listed in
+ "Prerequisites" above.
+
+In the bundle format, there can be a comment following a prerequisite obj-id.
+This is a comment and it has no specific meaning. The writer of the bundle MAY
+put any string here. The reader of the bundle MUST ignore the comment.
+
+Note on shallow clones and Git bundles
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Note that the prerequisites do not represent a shallow-clone boundary. The
+semantics of the prerequisites and the shallow-clone boundaries are different,
+and the Git bundle v2 format cannot represent a shallow clone repository.
+
+CAPABILITIES
+------------
+
+Because there is no opportunity for negotiation, unknown capabilities cause 'git
+bundle' to abort.
+
+* `object-format` specifies the hash algorithm in use, and can take the same
+ values as the `extensions.objectFormat` configuration value.
+
+* `filter` specifies an object filter as in the `--filter` option in
+ linkgit:git-rev-list[1]. The resulting pack-file must be marked as a
+ `.promisor` pack-file after it is unbundled.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitformat-chunk.adoc b/gitformat-chunk.adoc
new file mode 100644
index 0000000..3315df6
--- /dev/null
+++ b/gitformat-chunk.adoc
@@ -0,0 +1,133 @@
+gitformat-chunk(5)
+==================
+
+NAME
+----
+gitformat-chunk - Chunk-based file formats
+
+SYNOPSIS
+--------
+
+Used by linkgit:gitformat-commit-graph[5] and the "MIDX" format (see
+the pack format documentation in linkgit:gitformat-pack[5]).
+
+DESCRIPTION
+-----------
+
+Some file formats in Git use a common concept of "chunks" to describe
+sections of the file. This allows structured access to a large file by
+scanning a small "table of contents" for the remaining data. This common
+format is used by the `commit-graph` and `multi-pack-index` files. See
+the `multi-pack-index` format in linkgit:gitformat-pack[5] and
+the `commit-graph` format in linkgit:gitformat-commit-graph[5] for
+how they use the chunks to describe structured data.
+
+A chunk-based file format begins with some header information custom to
+that format. That header should include enough information to identify
+the file type, format version, and number of chunks in the file. From this
+information, that file can determine the start of the chunk-based region.
+
+The chunk-based region starts with a table of contents describing where
+each chunk starts and ends. This consists of (C+1) rows of 12 bytes each,
+where C is the number of chunks. Consider the following table:
+
+ | Chunk ID (4 bytes) | Chunk Offset (8 bytes) |
+ |--------------------|------------------------|
+ | ID[0] | OFFSET[0] |
+ | ... | ... |
+ | ID[C] | OFFSET[C] |
+ | 0x0000 | OFFSET[C+1] |
+
+Each row consists of a 4-byte chunk identifier (ID) and an 8-byte offset.
+Each integer is stored in network-byte order.
+
+The chunk identifier `ID[i]` is a label for the data stored within this
+file from `OFFSET[i]` (inclusive) to `OFFSET[i+1]` (exclusive). Thus, the
+size of the `i`th chunk is equal to the difference between `OFFSET[i+1]`
+and `OFFSET[i]`. This requires that the chunk data appears contiguously
+in the same order as the table of contents.
+
+The final entry in the table of contents must be four zero bytes. This
+confirms that the table of contents is ending and provides the offset for
+the end of the chunk-based data.
+
+Note: The chunk-based format expects that the file contains _at least_ a
+trailing hash after `OFFSET[C+1]`.
+
+Functions for working with chunk-based file formats are declared in
+`chunk-format.h`. Using these methods provide extra checks that assist
+developers when creating new file formats.
+
+Writing chunk-based file formats
+--------------------------------
+
+To write a chunk-based file format, create a `struct chunkfile` by
+calling `init_chunkfile()` and pass a `struct hashfile` pointer. The
+caller is responsible for opening the `hashfile` and writing header
+information so the file format is identifiable before the chunk-based
+format begins.
+
+Then, call `add_chunk()` for each chunk that is intended for writing. This
+populates the `chunkfile` with information about the order and size of
+each chunk to write. Provide a `chunk_write_fn` function pointer to
+perform the write of the chunk data upon request.
+
+Call `write_chunkfile()` to write the table of contents to the `hashfile`
+followed by each of the chunks. This will verify that each chunk wrote
+the expected amount of data so the table of contents is correct.
+
+Finally, call `free_chunkfile()` to clear the `struct chunkfile` data. The
+caller is responsible for finalizing the `hashfile` by writing the trailing
+hash and closing the file.
+
+Reading chunk-based file formats
+--------------------------------
+
+To read a chunk-based file format, the file must be opened as a
+memory-mapped region. The chunk-format API expects that the entire file
+is mapped as a contiguous memory region.
+
+Initialize a `struct chunkfile` pointer with `init_chunkfile(NULL)`.
+
+After reading the header information from the beginning of the file,
+including the chunk count, call `read_table_of_contents()` to populate
+the `struct chunkfile` with the list of chunks, their offsets, and their
+sizes.
+
+Extract the data information for each chunk using `pair_chunk()` or
+`read_chunk()`:
+
+* `pair_chunk()` assigns a given pointer with the location inside the
+ memory-mapped file corresponding to that chunk's offset. If the chunk
+ does not exist, then the pointer is not modified.
+
+* `read_chunk()` takes a `chunk_read_fn` function pointer and calls it
+ with the appropriate initial pointer and size information. The function
+ is not called if the chunk does not exist. Use this method to read chunks
+ if you need to perform immediate parsing or if you need to execute logic
+ based on the size of the chunk.
+
+After calling these methods, call `free_chunkfile()` to clear the
+`struct chunkfile` data. This will not close the memory-mapped region.
+Callers are expected to own that data for the timeframe the pointers into
+the region are needed.
+
+Examples
+--------
+
+These file formats use the chunk-format API, and can be used as examples
+for future formats:
+
+* *commit-graph:* see `write_commit_graph_file()` and `parse_commit_graph()`
+ in `commit-graph.c` for how the chunk-format API is used to write and
+ parse the commit-graph file format documented in
+ the commit-graph file format in linkgit:gitformat-commit-graph[5].
+
+* *multi-pack-index:* see `write_midx_internal()` and `load_multi_pack_index()`
+ in `midx.c` for how the chunk-format API is used to write and
+ parse the multi-pack-index file format documented in
+ the multi-pack-index file format section of linkgit:gitformat-pack[5].
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitformat-commit-graph.adoc b/gitformat-commit-graph.adoc
new file mode 100644
index 0000000..14d1631
--- /dev/null
+++ b/gitformat-commit-graph.adoc
@@ -0,0 +1,186 @@
+gitformat-commit-graph(5)
+=========================
+
+NAME
+----
+gitformat-commit-graph - Git commit-graph format
+
+SYNOPSIS
+--------
+[verse]
+$GIT_DIR/objects/info/commit-graph
+$GIT_DIR/objects/info/commit-graphs/*
+
+DESCRIPTION
+-----------
+
+The Git commit-graph stores a list of commit OIDs and some associated
+metadata, including:
+
+- The generation number of the commit.
+
+- The root tree OID.
+
+- The commit date.
+
+- The parents of the commit, stored using positional references within
+ the graph file.
+
+- The Bloom filter of the commit carrying the paths that were changed between
+ the commit and its first parent, if requested.
+
+These positional references are stored as unsigned 32-bit integers
+corresponding to the array position within the list of commit OIDs. Due
+to some special constants we use to track parents, we can store at most
+(1 << 30) + (1 << 29) + (1 << 28) - 1 (around 1.8 billion) commits.
+
+== Commit-graph files have the following format:
+
+In order to allow extensions that add extra data to the graph, we organize
+the body into "chunks" and provide a binary lookup table at the beginning
+of the body. The header includes certain values, such as number of chunks
+and hash type.
+
+All multi-byte numbers are in network byte order.
+
+=== HEADER:
+
+ 4-byte signature:
+ The signature is: {'C', 'G', 'P', 'H'}
+
+ 1-byte version number:
+ Currently, the only valid version is 1.
+
+ 1-byte Hash Version
+ We infer the hash length (H) from this value:
+ 1 => SHA-1
+ 2 => SHA-256
+ If the hash type does not match the repository's hash algorithm, the
+ commit-graph file should be ignored with a warning presented to the
+ user.
+
+ 1-byte number (C) of "chunks"
+
+ 1-byte number (B) of base commit-graphs
+ We infer the length (H*B) of the Base Graphs chunk
+ from this value.
+
+=== CHUNK LOOKUP:
+
+ (C + 1) * 12 bytes listing the table of contents for the chunks:
+ First 4 bytes describe the chunk id. Value 0 is a terminating label.
+ Other 8 bytes provide the byte-offset in current file for chunk to
+ start. (Chunks are ordered contiguously in the file, so you can infer
+ the length using the next chunk position if necessary.) Each chunk
+ ID appears at most once.
+
+ The CHUNK LOOKUP matches the table of contents from
+ the chunk-based file format, see linkgit:gitformat-chunk[5]
+
+ The remaining data in the body is described one chunk at a time, and
+ these chunks may be given in any order. Chunks are required unless
+ otherwise specified.
+
+=== CHUNK DATA:
+
+==== OID Fanout (ID: {'O', 'I', 'D', 'F'}) (256 * 4 bytes)
+ The ith entry, F[i], stores the number of OIDs with first
+ byte at most i. Thus F[255] stores the total
+ number of commits (N).
+
+==== OID Lookup (ID: {'O', 'I', 'D', 'L'}) (N * H bytes)
+ The OIDs for all commits in the graph, sorted in ascending order.
+
+==== Commit Data (ID: {'C', 'D', 'A', 'T' }) (N * (H + 16) bytes)
+ * The first H bytes are for the OID of the root tree.
+ * The next 8 bytes are for the positions of the first two parents
+ of the ith commit. Stores value 0x70000000 if no parent in that
+ position. If there are more than two parents, the second value
+ has its most-significant bit on and the other bits store an array
+ position into the Extra Edge List chunk.
+ * The next 8 bytes store the topological level (generation number v1)
+ of the commit and
+ the commit time in seconds since EPOCH. The generation number
+ uses the higher 30 bits of the first 4 bytes, while the commit
+ time uses the 32 bits of the second 4 bytes, along with the lowest
+ 2 bits of the lowest byte, storing the 33rd and 34th bit of the
+ commit time.
+
+==== Generation Data (ID: {'G', 'D', 'A', '2' }) (N * 4 bytes) [Optional]
+ * This list of 4-byte values store corrected commit date offsets for the
+ commits, arranged in the same order as commit data chunk.
+ * If the corrected commit date offset cannot be stored within 31 bits,
+ the value has its most-significant bit on and the other bits store
+ the position of corrected commit date into the Generation Data Overflow
+ chunk.
+ * Generation Data chunk is present only when commit-graph file is written
+ by compatible versions of Git and in case of split commit-graph chains,
+ the topmost layer also has Generation Data chunk.
+
+==== Generation Data Overflow (ID: {'G', 'D', 'O', '2' }) [Optional]
+ * This list of 8-byte values stores the corrected commit date offsets
+ for commits with corrected commit date offsets that cannot be
+ stored within 31 bits.
+ * Generation Data Overflow chunk is present only when Generation Data
+ chunk is present and at least one corrected commit date offset cannot
+ be stored within 31 bits.
+
+==== Extra Edge List (ID: {'E', 'D', 'G', 'E'}) [Optional]
+ This list of 4-byte values store the second through nth parents for
+ all octopus merges. The second parent value in the commit data stores
+ an array position within this list along with the most-significant bit
+ on. Starting at that array position, iterate through this list of commit
+ positions for the parents until reaching a value with the most-significant
+ bit on. The other bits correspond to the position of the last parent.
+
+==== Bloom Filter Index (ID: {'B', 'I', 'D', 'X'}) (N * 4 bytes) [Optional]
+ * The ith entry, BIDX[i], stores the number of bytes in all Bloom filters
+ from commit 0 to commit i (inclusive) in lexicographic order. The Bloom
+ filter for the i-th commit spans from BIDX[i-1] to BIDX[i] (plus header
+ length), where BIDX[-1] is 0.
+ * The BIDX chunk is ignored if the BDAT chunk is not present.
+
+==== Bloom Filter Data (ID: {'B', 'D', 'A', 'T'}) [Optional]
+ * It starts with header consisting of three unsigned 32-bit integers:
+ - Version of the hash algorithm being used. We currently support
+ value 2 which corresponds to the 32-bit version of the murmur3 hash
+ implemented exactly as described in
+ https://en.wikipedia.org/wiki/MurmurHash#Algorithm and the double
+ hashing technique using seed values 0x293ae76f and 0x7e646e2 as
+ described in https://doi.org/10.1007/978-3-540-30494-4_26 "Bloom Filters
+ in Probabilistic Verification". Version 1 Bloom filters have a bug that appears
+ when char is signed and the repository has path names that have characters >=
+ 0x80; Git supports reading and writing them, but this ability will be removed
+ in a future version of Git.
+ - The number of times a path is hashed and hence the number of bit positions
+ that cumulatively determine whether a file is present in the commit.
+ - The minimum number of bits 'b' per entry in the Bloom filter. If the filter
+ contains 'n' entries, then the filter size is the minimum number of 64-bit
+ words that contain n*b bits.
+ * The rest of the chunk is the concatenation of all the computed Bloom
+ filters for the commits in lexicographic order.
+ * Note: Commits with no changes or more than 512 changes have Bloom filters
+ of length one, with either all bits set to zero or one respectively.
+ * The BDAT chunk is present if and only if BIDX is present.
+
+==== Base Graphs List (ID: {'B', 'A', 'S', 'E'}) [Optional]
+ This list of H-byte hashes describe a set of B commit-graph files that
+ form a commit-graph chain. The graph position for the ith commit in this
+ file's OID Lookup chunk is equal to i plus the number of commits in all
+ base graphs. If B is non-zero, this chunk must exist.
+
+=== TRAILER:
+
+ H-byte HASH-checksum of all of the above.
+
+== Historical Notes:
+
+The Generation Data (GDA2) and Generation Data Overflow (GDO2) chunks have
+the number '2' in their chunk IDs because a previous version of Git wrote
+possibly erroneous data in these chunks with the IDs "GDAT" and "GDOV". By
+changing the IDs, newer versions of Git will silently ignore those older
+chunks and write the new information without trusting the incorrect data.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitformat-index.adoc b/gitformat-index.adoc
new file mode 100644
index 0000000..145cace
--- /dev/null
+++ b/gitformat-index.adoc
@@ -0,0 +1,424 @@
+gitformat-index(5)
+==================
+
+NAME
+----
+gitformat-index - Git index format
+
+SYNOPSIS
+--------
+[verse]
+$GIT_DIR/index
+
+DESCRIPTION
+-----------
+
+Git index format
+
+== The Git index file has the following format
+
+ All binary numbers are in network byte order.
+ In a repository using the traditional SHA-1, checksums and object IDs
+ (object names) mentioned below are all computed using SHA-1. Similarly,
+ in SHA-256 repositories, these values are computed using SHA-256.
+ Version 2 is described here unless stated otherwise.
+
+ - A 12-byte header consisting of
+
+ 4-byte signature:
+ The signature is { 'D', 'I', 'R', 'C' } (stands for "dircache")
+
+ 4-byte version number:
+ The current supported versions are 2, 3 and 4.
+
+ 32-bit number of index entries.
+
+ - A number of sorted index entries (see below).
+
+ - Extensions
+
+ Extensions are identified by signature. Optional extensions can
+ be ignored if Git does not understand them.
+
+ 4-byte extension signature. If the first byte is 'A'..'Z' the
+ extension is optional and can be ignored.
+
+ 32-bit size of the extension
+
+ Extension data
+
+ - Hash checksum over the content of the index file before this checksum.
+
+== Index entry
+
+ Index entries are sorted in ascending order on the name field,
+ interpreted as a string of unsigned bytes (i.e. memcmp() order, no
+ localization, no special casing of directory separator '/'). Entries
+ with the same name are sorted by their stage field.
+
+ An index entry typically represents a file. However, if sparse-checkout
+ is enabled in cone mode (`core.sparseCheckoutCone` is enabled) and the
+ `extensions.sparseIndex` extension is enabled, then the index may
+ contain entries for directories outside of the sparse-checkout definition.
+ These entries have mode `040000`, include the `SKIP_WORKTREE` bit, and
+ the path ends in a directory separator.
+
+ 32-bit ctime seconds, the last time a file's metadata changed
+ this is stat(2) data
+
+ 32-bit ctime nanosecond fractions
+ this is stat(2) data
+
+ 32-bit mtime seconds, the last time a file's data changed
+ this is stat(2) data
+
+ 32-bit mtime nanosecond fractions
+ this is stat(2) data
+
+ 32-bit dev
+ this is stat(2) data
+
+ 32-bit ino
+ this is stat(2) data
+
+ 32-bit mode, split into (high to low bits)
+
+ 16-bit unused, must be zero
+
+ 4-bit object type
+ valid values in binary are 1000 (regular file), 1010 (symbolic link)
+ and 1110 (gitlink)
+
+ 3-bit unused, must be zero
+
+ 9-bit unix permission. Only 0755 and 0644 are valid for regular files.
+ Symbolic links and gitlinks have value 0 in this field.
+
+ 32-bit uid
+ this is stat(2) data
+
+ 32-bit gid
+ this is stat(2) data
+
+ 32-bit file size
+ This is the on-disk size from stat(2), truncated to 32-bit.
+
+ Object name for the represented object
+
+ A 16-bit 'flags' field split into (high to low bits)
+
+ 1-bit assume-valid flag
+
+ 1-bit extended flag (must be zero in version 2)
+
+ 2-bit stage (during merge)
+
+ 12-bit name length if the length is less than 0xFFF; otherwise 0xFFF
+ is stored in this field.
+
+ (Version 3 or later) A 16-bit field, only applicable if the
+ "extended flag" above is 1, split into (high to low bits).
+
+ 1-bit reserved for future
+
+ 1-bit skip-worktree flag (used by sparse checkout)
+
+ 1-bit intent-to-add flag (used by "git add -N")
+
+ 13-bit unused, must be zero
+
+ Entry path name (variable length) relative to top level directory
+ (without leading slash). '/' is used as path separator. The special
+ path components ".", ".." and ".git" (without quotes) are disallowed.
+ Trailing slash is also disallowed.
+
+ The exact encoding is undefined, but the '.' and '/' characters
+ are encoded in 7-bit ASCII and the encoding cannot contain a NUL
+ byte (iow, this is a UNIX pathname).
+
+ (Version 4) In version 4, the entry path name is prefix-compressed
+ relative to the path name for the previous entry (the very first
+ entry is encoded as if the path name for the previous entry is an
+ empty string). At the beginning of an entry, an integer N in the
+ variable width encoding (the same encoding as the offset is encoded
+ for OFS_DELTA pack entries; see linkgit:gitformat-pack[5]) is stored, followed
+ by a NUL-terminated string S. Removing N bytes from the end of the
+ path name for the previous entry, and replacing it with the string S
+ yields the path name for this entry.
+
+ 1-8 nul bytes as necessary to pad the entry to a multiple of eight bytes
+ while keeping the name NUL-terminated.
+
+ (Version 4) In version 4, the padding after the pathname does not
+ exist.
+
+ Interpretation of index entries in split index mode is completely
+ different. See below for details.
+
+== Extensions
+
+=== Cache tree
+
+ Since the index does not record entries for directories, the cache
+ entries cannot describe tree objects that already exist in the object
+ database for regions of the index that are unchanged from an existing
+ commit. The cache tree extension stores a recursive tree structure that
+ describes the trees that already exist and completely match sections of
+ the cache entries. This speeds up tree object generation from the index
+ for a new commit by only computing the trees that are "new" to that
+ commit. It also assists when comparing the index to another tree, such
+ as `HEAD^{tree}`, since sections of the index can be skipped when a tree
+ comparison demonstrates equality.
+
+ The recursive tree structure uses nodes that store a number of cache
+ entries, a list of subnodes, and an object ID (OID). The OID references
+ the existing tree for that node, if it is known to exist. The subnodes
+ correspond to subdirectories that themselves have cache tree nodes. The
+ number of cache entries corresponds to the number of cache entries in
+ the index that describe paths within that tree's directory.
+
+ The extension tracks the full directory structure in the cache tree
+ extension, but this is generally smaller than the full cache entry list.
+
+ When a path is updated in index, Git invalidates all nodes of the
+ recursive cache tree corresponding to the parent directories of that
+ path. We store these tree nodes as being "invalid" by using "-1" as the
+ number of cache entries. Invalid nodes still store a span of index
+ entries, allowing Git to focus its efforts when reconstructing a full
+ cache tree.
+
+ The signature for this extension is { 'T', 'R', 'E', 'E' }.
+
+ A series of entries fill the entire extension; each of which
+ consists of:
+
+ - NUL-terminated path component (relative to its parent directory);
+
+ - ASCII decimal number of entries in the index that is covered by the
+ tree this entry represents (entry_count);
+
+ - A space (ASCII 32);
+
+ - ASCII decimal number that represents the number of subtrees this
+ tree has;
+
+ - A newline (ASCII 10); and
+
+ - Object name for the object that would result from writing this span
+ of index as a tree.
+
+ An entry can be in an invalidated state and is represented by having
+ 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
+ first subtree--let's call this A--of the root level (with its name
+ relative to the root level), followed by the first subtree of A (with
+ its name relative to A), and so on. The specified number of subtrees
+ indicates when the current level of the recursive stack is complete.
+
+=== Resolve undo
+
+ A conflict is represented in the index as a set of higher stage entries.
+ When a conflict is resolved (e.g. with "git add path"), these higher
+ stage entries will be removed and a stage-0 entry with proper resolution
+ is added.
+
+ When these higher stage entries are removed, they are saved in the
+ resolve undo extension, so that conflicts can be recreated (e.g. with
+ "git checkout -m"), in case users want to redo a conflict resolution
+ from scratch.
+
+ The signature for this extension is { 'R', 'E', 'U', 'C' }.
+
+ A series of entries fill the entire extension; each of which
+ consists of:
+
+ - NUL-terminated pathname the entry describes (relative to the root of
+ the repository, i.e. full pathname);
+
+ - Three NUL-terminated ASCII octal numbers, entry mode of entries in
+ stage 1 to 3 (a missing stage is represented by "0" in this field);
+ and
+
+ - At most three object names of the entry in stages from 1 to 3
+ (nothing is written for a missing stage).
+
+=== Split index
+
+ In split index mode, the majority of index entries could be stored
+ in a separate file. This extension records the changes to be made on
+ top of that to produce the final index.
+
+ The signature for this extension is { 'l', 'i', 'n', 'k' }.
+
+ The extension consists of:
+
+ - Hash of the shared index file. The shared index file path
+ is $GIT_DIR/sharedindex.<hash>. If all bits are zero, the
+ index does not require a shared index file.
+
+ - An ewah-encoded delete bitmap, each bit represents an entry in the
+ shared index. If a bit is set, its corresponding entry in the
+ shared index will be removed from the final index. Note, because
+ a delete operation changes index entry positions, but we do need
+ original positions in replace phase, it's best to just mark
+ entries for removal, then do a mass deletion after replacement.
+
+ - An ewah-encoded replace bitmap, each bit represents an entry in
+ the shared index. If a bit is set, its corresponding entry in the
+ shared index will be replaced with an entry in this index
+ file. All replaced entries are stored in sorted order in this
+ index. The first "1" bit in the replace bitmap corresponds to the
+ first index entry, the second "1" bit to the second entry and so
+ on. Replaced entries may have empty path names to save space.
+
+ The remaining index entries after replaced ones will be added to the
+ final index. These added entries are also sorted by entry name then
+ stage.
+
+== Untracked cache
+
+ Untracked cache saves the untracked file list and necessary data to
+ verify the cache. The signature for this extension is { 'U', 'N',
+ 'T', 'R' }.
+
+ The extension starts with
+
+ - A sequence of NUL-terminated strings, preceded by the size of the
+ sequence in variable width encoding. Each string describes the
+ environment where the cache can be used.
+
+ - Stat data of $GIT_DIR/info/exclude. See "Index entry" section from
+ ctime field until "file size".
+
+ - Stat data of core.excludesFile
+
+ - 32-bit dir_flags (see struct dir_struct)
+
+ - Hash of $GIT_DIR/info/exclude. A null hash means the file
+ does not exist.
+
+ - Hash of core.excludesFile. A null hash means the file does
+ not exist.
+
+ - NUL-terminated string of per-dir exclude file name. This usually
+ is ".gitignore".
+
+ - The number of following directory blocks, variable width
+ encoding. If this number is zero, the extension ends here with a
+ following NUL.
+
+ - A number of directory blocks in depth-first-search order, each
+ consists of
+
+ - The number of untracked entries, variable width encoding.
+
+ - The number of sub-directory blocks, variable width encoding.
+
+ - The directory name terminated by NUL.
+
+ - A number of untracked file/dir names terminated by NUL.
+
+The remaining data of each directory block is grouped by type:
+
+ - An ewah bitmap, the n-th bit marks whether the n-th directory has
+ valid untracked cache entries.
+
+ - An ewah bitmap, the n-th bit records "check-only" bit of
+ read_directory_recursive() for the n-th directory.
+
+ - An ewah bitmap, the n-th bit indicates whether hash and stat data
+ is valid for the n-th directory and exists in the next data.
+
+ - An array of stat data. The n-th data corresponds with the n-th
+ "one" bit in the previous ewah bitmap.
+
+ - An array of hashes. The n-th hash corresponds with the n-th "one" bit
+ in the previous ewah bitmap.
+
+ - One NUL.
+
+== File System Monitor cache
+
+ The file system monitor cache tracks files for which the core.fsmonitor
+ hook has told us about changes. The signature for this extension is
+ { 'F', 'S', 'M', 'N' }.
+
+ The extension starts with
+
+ - 32-bit version number: the current supported versions are 1 and 2.
+
+ - (Version 1)
+ 64-bit time: the extension data reflects all changes through the given
+ time which is stored as the nanoseconds elapsed since midnight,
+ January 1, 1970.
+
+ - (Version 2)
+ A null terminated string: an opaque token defined by the file system
+ monitor application. The extension data reflects all changes relative
+ to that token.
+
+ - 32-bit bitmap size: the size of the CE_FSMONITOR_VALID bitmap.
+
+ - An ewah bitmap, the n-th bit indicates whether the n-th index entry
+ is not CE_FSMONITOR_VALID.
+
+== End of Index Entry
+
+ The End of Index Entry (EOIE) is used to locate the end of the variable
+ length index entries and the beginning of the extensions. Code can take
+ advantage of this to quickly locate the index extensions without having
+ to parse through all of the index entries.
+
+ Because it must be able to be loaded before the variable length cache
+ entries and other index extensions, this extension must be written last.
+ The signature for this extension is { 'E', 'O', 'I', 'E' }.
+
+ The extension consists of:
+
+ - 32-bit offset to the end of the index entries
+
+ - Hash over the extension types and their sizes (but not
+ their contents). E.g. if we have "TREE" extension that is N-bytes
+ long, "REUC" extension that is M-bytes long, followed by "EOIE",
+ then the hash would be:
+
+ Hash("TREE" + <binary-representation-of-N> +
+ "REUC" + <binary-representation-of-M>)
+
+== Index Entry Offset Table
+
+ The Index Entry Offset Table (IEOT) is used to help address the CPU
+ cost of loading the index by enabling multi-threading the process of
+ converting cache entries from the on-disk format to the in-memory format.
+ The signature for this extension is { 'I', 'E', 'O', 'T' }.
+
+ The extension consists of:
+
+ - 32-bit version (currently 1)
+
+ - A number of index offset entries each consisting of:
+
+ - 32-bit offset from the beginning of the file to the first cache entry
+ in this block of entries.
+
+ - 32-bit count of cache entries in this block
+
+== Sparse Directory Entries
+
+ When using sparse-checkout in cone mode, some entire directories within
+ the index can be summarized by pointing to a tree object instead of the
+ entire expanded list of paths within that tree. An index containing such
+ entries is a "sparse index". Index format versions 4 and less were not
+ implemented with such entries in mind. Thus, for these versions, an
+ index containing sparse directory entries will include this extension
+ with signature { 's', 'd', 'i', 'r' }. Like the split-index extension,
+ tools should avoid interacting with a sparse index unless they understand
+ this extension.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitformat-pack.adoc b/gitformat-pack.adoc
new file mode 100644
index 0000000..d6ae229
--- /dev/null
+++ b/gitformat-pack.adoc
@@ -0,0 +1,681 @@
+gitformat-pack(5)
+=================
+
+NAME
+----
+gitformat-pack - Git pack format
+
+
+SYNOPSIS
+--------
+[verse]
+$GIT_DIR/objects/pack/pack-*.{pack,idx}
+$GIT_DIR/objects/pack/pack-*.rev
+$GIT_DIR/objects/pack/pack-*.mtimes
+$GIT_DIR/objects/pack/multi-pack-index
+
+DESCRIPTION
+-----------
+
+The Git pack format is how Git stores most of its primary repository
+data. Over the lifetime of a repository, loose objects (if any) and
+smaller packs are consolidated into larger pack(s). See
+linkgit:git-gc[1] and linkgit:git-pack-objects[1].
+
+The pack format is also used over-the-wire, see
+e.g. linkgit:gitprotocol-v2[5], as well as being a part of
+other container formats in the case of linkgit:gitformat-bundle[5].
+
+== Checksums and object IDs
+
+In a repository using the traditional SHA-1, pack checksums, index checksums,
+and object IDs (object names) mentioned below are all computed using SHA-1.
+Similarly, in SHA-256 repositories, these values are computed using SHA-256.
+
+== pack-*.pack files have the following format:
+
+ - A header appears at the beginning and consists of the following:
+
+ 4-byte signature:
+ The signature is: {'P', 'A', 'C', 'K'}
+
+ 4-byte version number (network byte order):
+ Git currently accepts version number 2 or 3 but
+ generates version 2 only.
+
+ 4-byte number of objects contained in the pack (network byte order)
+
+ Observation: we cannot have more than 4G versions ;-) and
+ more than 4G objects in a pack.
+
+ - The header is followed by a number of object entries, each of
+ which looks like this:
+
+ (undeltified representation)
+ n-byte type and length (3-bit type, (n-1)*7+4-bit length)
+ compressed data
+
+ (deltified representation)
+ n-byte type and length (3-bit type, (n-1)*7+4-bit length)
+ base object name if OBJ_REF_DELTA or a negative relative
+ offset from the delta object's position in the pack if this
+ is an OBJ_OFS_DELTA object
+ compressed delta data
+
+ Observation: the length of each object is encoded in a variable
+ length format and is not constrained to 32-bit or anything.
+
+ - The trailer records a pack checksum of all of the above.
+
+=== Object types
+
+Valid object types are:
+
+- OBJ_COMMIT (1)
+- OBJ_TREE (2)
+- OBJ_BLOB (3)
+- OBJ_TAG (4)
+- OBJ_OFS_DELTA (6)
+- OBJ_REF_DELTA (7)
+
+Type 5 is reserved for future expansion. Type 0 is invalid.
+
+=== Size encoding
+
+This document uses the following "size encoding" of non-negative
+integers: From each byte, the seven least significant bits are
+used to form the resulting integer. As long as the most significant
+bit is 1, this process continues; the byte with MSB 0 provides the
+last seven bits. The seven-bit chunks are concatenated. Later
+values are more significant.
+
+This size encoding should not be confused with the "offset encoding",
+which is also used in this document.
+
+=== Deltified representation
+
+Conceptually there are only four object types: commit, tree, tag and
+blob. However to save space, an object could be stored as a "delta" of
+another "base" object. These representations are assigned new types
+ofs-delta and ref-delta, which is only valid in a pack file.
+
+Both ofs-delta and ref-delta store the "delta" to be applied to
+another object (called 'base object') to reconstruct the object. The
+difference between them is, ref-delta directly encodes base object
+name. If the base object is in the same pack, ofs-delta encodes
+the offset of the base object in the pack instead.
+
+The base object could also be deltified if it's in the same pack.
+Ref-delta can also refer to an object outside the pack (i.e. the
+so-called "thin pack"). When stored on disk however, the pack should
+be self contained to avoid cyclic dependency.
+
+The delta data starts with the size of the base object and the
+size of the object to be reconstructed. These sizes are
+encoded using the size encoding from above. The remainder of
+the delta data is a sequence of instructions to reconstruct the object
+from the base object. If the base object is deltified, it must be
+converted to canonical form first. Each instruction appends more and
+more data to the target object until it's complete. There are two
+supported instructions so far: one for copying a byte range from the
+source object and one for inserting new data embedded in the
+instruction itself.
+
+Each instruction has variable length. Instruction type is determined
+by the seventh bit of the first octet. The following diagrams follow
+the convention in RFC 1951 (Deflate compressed data format).
+
+==== Instruction to copy from base object
+
+ +----------+---------+---------+---------+---------+-------+-------+-------+
+ | 1xxxxxxx | offset1 | offset2 | offset3 | offset4 | size1 | size2 | size3 |
+ +----------+---------+---------+---------+---------+-------+-------+-------+
+
+This is the instruction format to copy a byte range from the source
+object. It encodes the offset to copy from and the number of bytes to
+copy. Offset and size are in little-endian order.
+
+All offset and size bytes are optional. This is to reduce the
+instruction size when encoding small offsets or sizes. The first seven
+bits in the first octet determine which of the next seven octets is
+present. If bit zero is set, offset1 is present. If bit one is set
+offset2 is present and so on.
+
+Note that a more compact instruction does not change offset and size
+encoding. For example, if only offset2 is omitted like below, offset3
+still contains bits 16-23. It does not become offset2 and contains
+bits 8-15 even if it's right next to offset1.
+
+ +----------+---------+---------+
+ | 10000101 | offset1 | offset3 |
+ +----------+---------+---------+
+
+In its most compact form, this instruction only takes up one byte
+(0x80) with both offset and size omitted, which will have default
+values zero. There is another exception: size zero is automatically
+converted to 0x10000.
+
+==== Instruction to add new data
+
+ +----------+============+
+ | 0xxxxxxx | data |
+ +----------+============+
+
+This is the instruction to construct the target object without the base
+object. The following data is appended to the target object. The first
+seven bits of the first octet determine the size of data in
+bytes. The size must be non-zero.
+
+==== Reserved instruction
+
+ +----------+============
+ | 00000000 |
+ +----------+============
+
+This is the instruction reserved for future expansion.
+
+== 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
+ objects in the corresponding pack, the first byte of whose
+ object name is less than or equal to N. This is called the
+ 'first-level fan-out' table.
+
+ - The header is followed by sorted 24-byte entries, one entry
+ per object in the pack. Each entry is:
+
+ 4-byte network byte order integer, recording where the
+ object is stored in the packfile as the offset from the
+ beginning.
+
+ one object name of the appropriate size.
+
+ - The file is concluded with a trailer:
+
+ A copy of the pack checksum at the end of the corresponding
+ packfile.
+
+ Index checksum of all of the above.
+
+Pack Idx file:
+
+ -- +--------------------------------+
+fanout | fanout[0] = 2 (for example) |-.
+table +--------------------------------+ |
+ | fanout[1] | |
+ +--------------------------------+ |
+ | fanout[2] | |
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
+ | fanout[255] = total objects |---.
+ -- +--------------------------------+ | |
+main | offset | | |
+index | object name 00XXXXXXXXXXXXXXXX | | |
+table +--------------------------------+ | |
+ | offset | | |
+ | object name 00XXXXXXXXXXXXXXXX | | |
+ +--------------------------------+<+ |
+ .-| offset | |
+ | | object name 01XXXXXXXXXXXXXXXX | |
+ | +--------------------------------+ |
+ | | offset | |
+ | | object name 01XXXXXXXXXXXXXXXX | |
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
+ | | offset | |
+ | | object name FFXXXXXXXXXXXXXXXX | |
+ --| +--------------------------------+<--+
+trailer | | packfile checksum |
+ | +--------------------------------+
+ | | idxfile checksum |
+ | +--------------------------------+
+ .-------.
+ |
+Pack file entry: <+
+
+ packed object header:
+ 1-byte size extension bit (MSB)
+ type (next 3 bit)
+ size0 (lower 4-bit)
+ n-byte sizeN (as long as MSB is set, each 7-bit)
+ size0..sizeN form 4+7+7+..+7 bit integer, size0
+ is the least significant part, and sizeN is the
+ most significant part.
+ packed object data:
+ If it is not DELTA, then deflated bytes (the size above
+ is the size before compression).
+ If it is REF_DELTA, then
+ base object name (the size above is the
+ size of the delta data that follows).
+ delta data, deflated.
+ If it is OFS_DELTA, then
+ n-byte offset (see below) interpreted as a negative
+ offset from the type-byte of the header of the
+ ofs-delta entry (the size above is the size of
+ the delta data that follows).
+ delta data, deflated.
+
+ offset encoding:
+ n bytes with MSB set in all but the last one.
+ The offset is then the number constructed by
+ concatenating the lower 7 bit of each byte, and
+ for n >= 2 adding 2^7 + 2^14 + ... + 2^(7*(n-1))
+ to the result.
+
+
+
+== 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.
+
+ - A 4-byte version number (= 2)
+
+ - A 256-entry fan-out table just like v1.
+
+ - A table of sorted object names. These are packed together
+ without offset values to reduce the cache footprint of the
+ binary search for a specific object name.
+
+ - A table of 4-byte CRC32 values of the packed object data.
+ This is new in v2 so compressed data can be copied directly
+ from pack to pack during repacking without undetected
+ data corruption.
+
+ - A table of 4-byte offset values (in network byte order).
+ These are usually 31-bit pack file offsets, but large
+ offsets are encoded as an index into the next table with
+ the msbit set.
+
+ - A table of 8-byte offset entries (empty for pack files less
+ than 2 GiB). Pack files are organized with heavily used
+ objects toward the front, so most object references should
+ not need to refer to this table.
+
+ - The same trailer as a v1 pack file:
+
+ A copy of the pack checksum at the end of the
+ corresponding packfile.
+
+ Index checksum of all of the above.
+
+== pack-*.rev files have the format:
+
+ - A 4-byte magic number '0x52494458' ('RIDX').
+
+ - A 4-byte version identifier (= 1).
+
+ - A 4-byte hash function identifier (= 1 for SHA-1, 2 for SHA-256).
+
+ - A table of index positions (one per packed object, num_objects in
+ total, each a 4-byte unsigned integer in network order), sorted by
+ their corresponding offsets in the packfile.
+
+ - A trailer, containing a:
+
+ checksum of the corresponding packfile, and
+
+ a checksum of all of the above.
+
+All 4-byte numbers are in network order.
+
+== pack-*.mtimes files have the format:
+
+All 4-byte numbers are in network byte order.
+
+ - A 4-byte magic number '0x4d544d45' ('MTME').
+
+ - A 4-byte version identifier (= 1).
+
+ - A 4-byte hash function identifier (= 1 for SHA-1, 2 for SHA-256).
+
+ - A table of 4-byte unsigned integers. The ith value is the
+ modification time (mtime) of the ith object in the corresponding
+ pack by lexicographic (index) order. The mtimes count standard
+ epoch seconds.
+
+ - A trailer, containing a checksum of the corresponding packfile,
+ and a checksum of all of the above (each having length according
+ to the specified hash function).
+
+== multi-pack-index (MIDX) files have the following format:
+
+The multi-pack-index files refer to multiple pack-files and loose objects.
+
+In order to allow extensions that add extra data to the MIDX, we organize
+the body into "chunks" and provide a lookup table at the beginning of the
+body. The header includes certain length values, such as the number of packs,
+the number of base MIDX files, hash lengths and types.
+
+All 4-byte numbers are in network order.
+
+HEADER:
+
+ 4-byte signature:
+ The signature is: {'M', 'I', 'D', 'X'}
+
+ 1-byte version number:
+ Git only writes or recognizes version 1.
+
+ 1-byte Object Id Version
+ We infer the length of object IDs (OIDs) from this value:
+ 1 => SHA-1
+ 2 => SHA-256
+ If the hash type does not match the repository's hash algorithm,
+ the multi-pack-index file should be ignored with a warning
+ presented to the user.
+
+ 1-byte number of "chunks"
+
+ 1-byte number of base multi-pack-index files:
+ This value is currently always zero.
+
+ 4-byte number of pack files
+
+CHUNK LOOKUP:
+
+ (C + 1) * 12 bytes providing the chunk offsets:
+ First 4 bytes describe chunk id. Value 0 is a terminating label.
+ Other 8 bytes provide offset in current file for chunk to start.
+ (Chunks are provided in file-order, so you can infer the length
+ using the next chunk position if necessary.)
+
+ The CHUNK LOOKUP matches the table of contents from
+ the chunk-based file format, see linkgit:gitformat-chunk[5].
+
+ The remaining data in the body is described one chunk at a time, and
+ these chunks may be given in any order. Chunks are required unless
+ otherwise specified.
+
+CHUNK DATA:
+
+ Packfile Names (ID: {'P', 'N', 'A', 'M'})
+ Store the names of packfiles as a sequence of NUL-terminated
+ strings. There is no extra padding between the filenames,
+ and they are listed in lexicographic order. The chunk itself
+ is padded at the end with between 0 and 3 NUL bytes to make the
+ chunk size a multiple of 4 bytes.
+
+ Bitmapped Packfiles (ID: {'B', 'T', 'M', 'P'})
+ Stores a table of two 4-byte unsigned integers in network order.
+ Each table entry corresponds to a single pack (in the order that
+ they appear above in the `PNAM` chunk). The values for each table
+ entry are as follows:
+ - The first bit position (in pseudo-pack order, see below) to
+ contain an object from that pack.
+ - The number of bits whose objects are selected from that pack.
+
+ OID Fanout (ID: {'O', 'I', 'D', 'F'})
+ The ith entry, F[i], stores the number of OIDs with first
+ byte at most i. Thus F[255] stores the total
+ number of objects.
+
+ OID Lookup (ID: {'O', 'I', 'D', 'L'})
+ The OIDs for all objects in the MIDX are stored in lexicographic
+ order in this chunk.
+
+ Object Offsets (ID: {'O', 'O', 'F', 'F'})
+ Stores two 4-byte values for every object.
+ 1: The pack-int-id for the pack storing this object.
+ 2: The offset within the pack.
+ If all offsets are less than 2^32, then the large offset chunk
+ will not exist and offsets are stored as in IDX v1.
+ If there is at least one offset value larger than 2^32-1, then
+ the large offset chunk must exist, and offsets larger than
+ 2^31-1 must be stored in it instead. If the large offset chunk
+ exists and the 31st bit is on, then removing that bit reveals
+ the row in the large offsets containing the 8-byte offset of
+ this object.
+
+ [Optional] Object Large Offsets (ID: {'L', 'O', 'F', 'F'})
+ 8-byte offsets into large packfiles.
+
+ [Optional] Bitmap pack order (ID: {'R', 'I', 'D', 'X'})
+ A list of MIDX positions (one per object in the MIDX, num_objects in
+ total, each a 4-byte unsigned integer in network byte order), sorted
+ according to their relative bitmap/pseudo-pack positions.
+
+TRAILER:
+
+ Index checksum of the above contents.
+
+== multi-pack-index reverse indexes
+
+Similar to the pack-based reverse index, the multi-pack index can also
+be used to generate a reverse index.
+
+Instead of mapping between offset, pack-, and index position, this
+reverse index maps between an object's position within the MIDX, and
+that object's position within a pseudo-pack that the MIDX describes
+(i.e., the ith entry of the multi-pack reverse index holds the MIDX
+position of ith object in pseudo-pack order).
+
+To clarify the difference between these orderings, consider a multi-pack
+reachability bitmap (which does not yet exist, but is what we are
+building towards here). Each bit needs to correspond to an object in the
+MIDX, and so we need an efficient mapping from bit position to MIDX
+position.
+
+One solution is to let bits occupy the same position in the oid-sorted
+index stored by the MIDX. But because oids are effectively random, their
+resulting reachability bitmaps would have no locality, and thus compress
+poorly. (This is the reason that single-pack bitmaps use the pack
+ordering, and not the .idx ordering, for the same purpose.)
+
+So we'd like to define an ordering for the whole MIDX based around
+pack ordering, which has far better locality (and thus compresses more
+efficiently). We can think of a pseudo-pack created by the concatenation
+of all of the packs in the MIDX. E.g., if we had a MIDX with three packs
+(a, b, c), with 10, 15, and 20 objects respectively, we can imagine an
+ordering of the objects like:
+
+ |a,0|a,1|...|a,9|b,0|b,1|...|b,14|c,0|c,1|...|c,19|
+
+where the ordering of the packs is defined by the MIDX's pack list,
+and then the ordering of objects within each pack is the same as the
+order in the actual packfile.
+
+Given the list of packs and their counts of objects, you can
+naïvely reconstruct that pseudo-pack ordering (e.g., the object at
+position 27 must be (c,1) because packs "a" and "b" consumed 25 of the
+slots). But there's a catch. Objects may be duplicated between packs, in
+which case the MIDX only stores one pointer to the object (and thus we'd
+want only one slot in the bitmap).
+
+Callers could handle duplicates themselves by reading objects in order
+of their bit-position, but that's linear in the number of objects, and
+much too expensive for ordinary bitmap lookups. Building a reverse index
+solves this, since it is the logical inverse of the index, and that
+index has already removed duplicates. But, building a reverse index on
+the fly can be expensive. Since we already have an on-disk format for
+pack-based reverse indexes, let's reuse it for the MIDX's pseudo-pack,
+too.
+
+Objects from the MIDX are ordered as follows to string together the
+pseudo-pack. Let `pack(o)` return the pack from which `o` was selected
+by the MIDX, and define an ordering of packs based on their numeric ID
+(as stored by the MIDX). Let `offset(o)` return the object offset of `o`
+within `pack(o)`. Then, compare `o1` and `o2` as follows:
+
+ - If one of `pack(o1)` and `pack(o2)` is preferred and the other
+ is not, then the preferred one sorts first.
++
+(This is a detail that allows the MIDX bitmap to determine which
+pack should be used by the pack-reuse mechanism, since it can ask
+the MIDX for the pack containing the object at bit position 0).
+
+ - If `pack(o1) ≠ pack(o2)`, then sort the two objects in descending
+ order based on the pack ID.
+
+ - Otherwise, `pack(o1) = pack(o2)`, and the objects are sorted in
+ pack-order (i.e., `o1` sorts ahead of `o2` exactly when `offset(o1)
+ < offset(o2)`).
+
+In short, a MIDX's pseudo-pack is the de-duplicated concatenation of
+objects in packs stored by the MIDX, laid out in pack order, and the
+packs arranged in MIDX order (with the preferred pack coming first).
+
+The MIDX's reverse index is stored in the optional 'RIDX' chunk within
+the MIDX itself.
+
+=== `BTMP` chunk
+
+The Bitmapped Packfiles (`BTMP`) chunk encodes additional information
+about the objects in the multi-pack index's reachability bitmap. Recall
+that objects from the MIDX are arranged in "pseudo-pack" order (see
+above) for reachability bitmaps.
+
+From the example above, suppose we have packs "a", "b", and "c", with
+10, 15, and 20 objects, respectively. In pseudo-pack order, those would
+be arranged as follows:
+
+ |a,0|a,1|...|a,9|b,0|b,1|...|b,14|c,0|c,1|...|c,19|
+
+When working with single-pack bitmaps (or, equivalently, multi-pack
+reachability bitmaps with a preferred pack), linkgit:git-pack-objects[1]
+performs ``verbatim'' reuse, attempting to reuse chunks of the bitmapped
+or preferred packfile instead of adding objects to the packing list.
+
+When a chunk of bytes is reused from an existing pack, any objects
+contained therein do not need to be added to the packing list, saving
+memory and CPU time. But a chunk from an existing packfile can only be
+reused when the following conditions are met:
+
+ - The chunk contains only objects which were requested by the caller
+ (i.e. does not contain any objects which the caller didn't ask for
+ explicitly or implicitly).
+
+ - All objects stored in non-thin packs as offset- or reference-deltas
+ also include their base object in the resulting pack.
+
+The `BTMP` chunk encodes the necessary information in order to implement
+multi-pack reuse over a set of packfiles as described above.
+Specifically, the `BTMP` chunk encodes three pieces of information (all
+32-bit unsigned integers in network byte-order) for each packfile `p`
+that is stored in the MIDX, as follows:
+
+`bitmap_pos`:: The first bit position (in pseudo-pack order) in the
+ multi-pack index's reachability bitmap occupied by an object from `p`.
+
+`bitmap_nr`:: The number of bit positions (including the one at
+ `bitmap_pos`) that encode objects from that pack `p`.
+
+For example, the `BTMP` chunk corresponding to the above example (with
+packs ``a'', ``b'', and ``c'') would look like:
+
+[cols="1,2,2"]
+|===
+| |`bitmap_pos` |`bitmap_nr`
+
+|packfile ``a''
+|`0`
+|`10`
+
+|packfile ``b''
+|`10`
+|`15`
+
+|packfile ``c''
+|`25`
+|`20`
+|===
+
+With this information in place, we can treat each packfile as
+individually reusable in the same fashion as verbatim pack reuse is
+performed on individual packs prior to the implementation of the `BTMP`
+chunk.
+
+== cruft packs
+
+The cruft packs feature offer an alternative to Git's traditional mechanism of
+removing unreachable objects. This document provides an overview of Git's
+pruning mechanism, and how a cruft pack can be used instead to accomplish the
+same.
+
+=== Background
+
+To remove unreachable objects from your repository, Git offers `git repack -Ad`
+(see linkgit:git-repack[1]). Quoting from the documentation:
+
+----
+[...] unreachable objects in a previous pack become loose, unpacked objects,
+instead of being left in the old pack. [...] loose unreachable objects will be
+pruned according to normal expiry rules with the next 'git gc' invocation.
+----
+
+Unreachable objects aren't removed immediately, since doing so could race with
+an incoming push which may reference an object which is about to be deleted.
+Instead, those unreachable objects are stored as loose objects and stay that way
+until they are older than the expiration window, at which point they are removed
+by linkgit:git-prune[1].
+
+Git must store these unreachable objects loose in order to keep track of their
+per-object mtimes. If these unreachable objects were written into one big pack,
+then either freshening that pack (because an object contained within it was
+re-written) or creating a new pack of unreachable objects would cause the pack's
+mtime to get updated, and the objects within it would never leave the expiration
+window. Instead, objects are stored loose in order to keep track of the
+individual object mtimes and avoid a situation where all cruft objects are
+freshened at once.
+
+This can lead to undesirable situations when a repository contains many
+unreachable objects which have not yet left the grace period. Having large
+directories in the shards of `.git/objects` can lead to decreased performance in
+the repository. But given enough unreachable objects, this can lead to inode
+starvation and degrade the performance of the whole system. Since we
+can never pack those objects, these repositories often take up a large amount of
+disk space, since we can only zlib compress them, but not store them in delta
+chains.
+
+=== Cruft packs
+
+A cruft pack eliminates the need for storing unreachable objects in a loose
+state by including the per-object mtimes in a separate file alongside a single
+pack containing all loose objects.
+
+A cruft pack is written by `git repack --cruft` when generating a new pack.
+linkgit:git-pack-objects[1]'s `--cruft` option. Note that `git repack --cruft`
+is a classic all-into-one repack, meaning that everything in the resulting pack is
+reachable, and everything else is unreachable. Once written, the `--cruft`
+option instructs `git repack` to generate another pack containing only objects
+not packed in the previous step (which equates to packing all unreachable
+objects together). This progresses as follows:
+
+ 1. Enumerate every object, marking any object which is (a) not contained in a
+ kept-pack, and (b) whose mtime is within the grace period as a traversal
+ tip.
+
+ 2. Perform a reachability traversal based on the tips gathered in the previous
+ step, adding every object along the way to the pack.
+
+ 3. Write the pack out, along with a `.mtimes` file that records the per-object
+ timestamps.
+
+This mode is invoked internally by linkgit:git-repack[1] when instructed to
+write a cruft pack. Crucially, the set of in-core kept packs is exactly the set
+of packs which will not be deleted by the repack; in other words, they contain
+all of the repository's reachable objects.
+
+When a repository already has a cruft pack, `git repack --cruft` typically only
+adds objects to it. An exception to this is when `git repack` is given the
+`--cruft-expiration` option, which allows the generated cruft pack to omit
+expired objects instead of waiting for linkgit:git-gc[1] to expire those objects
+later on.
+
+It is linkgit:git-gc[1] that is typically responsible for removing expired
+unreachable objects.
+
+=== Alternatives
+
+Notable alternatives to this design include:
+
+ - The location of the per-object mtime data.
+
+On the location of mtime data, a new auxiliary file tied to the pack was chosen
+to avoid complicating the `.idx` format. If the `.idx` format were ever to gain
+support for optional chunks of data, it may make sense to consolidate the
+`.mtimes` format into the `.idx` itself.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitformat-signature.adoc b/gitformat-signature.adoc
new file mode 100644
index 0000000..d4d3a31
--- /dev/null
+++ b/gitformat-signature.adoc
@@ -0,0 +1,229 @@
+gitformat-signature(5)
+======================
+
+NAME
+----
+gitformat-signature - Git cryptographic signature formats
+
+SYNOPSIS
+--------
+[verse]
+<[tag|commit] object header(s)>
+<over-the-wire protocol>
+
+DESCRIPTION
+-----------
+
+Git uses cryptographic signatures in various places, currently objects (tags,
+commits, mergetags) and transactions (pushes). In every case, the command which
+is about to create an object or transaction determines a payload from that,
+calls an external program to obtain a detached signature for the payload
+(`gpg -bsa` in the case of PGP signatures), and embeds the signature into the
+object or transaction.
+
+Signatures begin with an "ASCII Armor" header line and end with a tail line,
+which differ depending on signature type (as selected by `gpg.format`, see
+linkgit:git-config[1]). These are, for `gpg.format` values:
+
+`gpg` (PGP)::
+ `-----BEGIN PGP SIGNATURE-----` and `-----END PGP SIGNATURE-----`.
+ Or, if gpg is told to produce RFC1991 signatures,
+ `-----BEGIN PGP MESSAGE-----` and `-----END PGP MESSAGE-----`
+
+`ssh` (SSH)::
+ `-----BEGIN SSH SIGNATURE-----` and `-----END SSH SIGNATURE-----`
+
+`x509` (X.509)::
+ `-----BEGIN SIGNED MESSAGE-----` and `-----END SIGNED MESSAGE-----`
+
+Signatures sometimes appear as a part of the normal payload
+(e.g. a signed tag has the signature block appended after the payload
+that the signature applies to), and sometimes appear in the value of
+an object header (e.g. a merge commit that merged a signed tag would
+have the entire tag contents on its "mergetag" header). In the case
+of the latter, the usual multi-line formatting rule for object
+headers applies. I.e. the second and subsequent lines are prefixed
+with a SP to signal that the line is continued from the previous
+line.
+
+This is even true for an originally empty line. In the following
+examples, the end of line that ends with a whitespace letter is
+highlighted with a `$` sign; if you are trying to recreate these
+example by hand, do not cut and paste them--they are there
+primarily to highlight extra whitespace at the end of some lines.
+
+The signed payload and the way the signature is embedded depends
+on the type of the object resp. transaction.
+
+== Tag signatures
+
+- created by: `git tag -s`
+- payload: annotated tag object
+- embedding: append the signature to the unsigned tag object
+- example: tag `signedtag` with subject `signed tag`
+
+----
+object 04b871796dc0420f8e7561a895b52484b701d51a
+type commit
+tag signedtag
+tagger C O Mitter <committer@example.com> 1465981006 +0000
+
+signed tag
+
+signed tag message body
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1
+
+iQEcBAABAgAGBQJXYRhOAAoJEGEJLoW3InGJklkIAIcnhL7RwEb/+QeX9enkXhxn
+rxfdqrvWd1K80sl2TOt8Bg/NYwrUBw/RWJ+sg/hhHp4WtvE1HDGHlkEz3y11Lkuh
+8tSxS3qKTxXUGozyPGuE90sJfExhZlW4knIQ1wt/yWqM+33E9pN4hzPqLwyrdods
+q8FWEqPPUbSJXoMbRPw04S5jrLtZSsUWbRYjmJCHzlhSfFWW4eFd37uquIaLUBS0
+rkC3Jrx7420jkIpgFcTI2s60uhSQLzgcCwdA2ukSYIRnjg/zDkj8+3h/GaROJ72x
+lZyI6HWixKJkWw8lE9aAOD9TmTW9sFJwcVAzmAuFX2kUreDUKMZduGcoRYGpD7E=
+=jpXa
+-----END PGP SIGNATURE-----
+----
+
+- verify with: `git verify-tag [-v]` or `git tag -v`
+
+----
+gpg: Signature made Wed Jun 15 10:56:46 2016 CEST using RSA key ID B7227189
+gpg: Good signature from "Eris Discordia <discord@example.net>"
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg: There is no indication that the signature belongs to the owner.
+Primary key fingerprint: D4BE 2231 1AD3 131E 5EDA 29A4 6109 2E85 B722 7189
+object 04b871796dc0420f8e7561a895b52484b701d51a
+type commit
+tag signedtag
+tagger C O Mitter <committer@example.com> 1465981006 +0000
+
+signed tag
+
+signed tag message body
+----
+
+== Commit signatures
+
+- created by: `git commit -S`
+- payload: commit object
+- embedding: header entry `gpgsig`
+ (content is preceded by a space)
+- example: commit with subject `signed commit`
+
+----
+tree eebfed94e75e7760540d1485c740902590a00332
+parent 04b871796dc0420f8e7561a895b52484b701d51a
+author A U Thor <author@example.com> 1465981137 +0000
+committer C O Mitter <committer@example.com> 1465981137 +0000
+gpgsig -----BEGIN PGP SIGNATURE-----
+ Version: GnuPG v1
+ $
+ iQEcBAABAgAGBQJXYRjRAAoJEGEJLoW3InGJ3IwIAIY4SA6GxY3BjL60YyvsJPh/
+ HRCJwH+w7wt3Yc/9/bW2F+gF72kdHOOs2jfv+OZhq0q4OAN6fvVSczISY/82LpS7
+ DVdMQj2/YcHDT4xrDNBnXnviDO9G7am/9OE77kEbXrp7QPxvhjkicHNwy2rEflAA
+ zn075rtEERDHr8nRYiDh8eVrefSO7D+bdQ7gv+7GsYMsd2auJWi1dHOSfTr9HIF4
+ HJhWXT9d2f8W+diRYXGh4X0wYiGg6na/soXc+vdtDYBzIxanRqjg8jCAeo1eOTk1
+ EdTwhcTZlI0x5pvJ3H0+4hA2jtldVtmPM4OTB0cTrEWBad7XV6YgiyuII73Ve3I=
+ =jKHM
+ -----END PGP SIGNATURE-----
+
+signed commit
+
+signed commit message body
+----
+
+- verify with: `git verify-commit [-v]` (or `git show --show-signature`)
+
+----
+gpg: Signature made Wed Jun 15 10:58:57 2016 CEST using RSA key ID B7227189
+gpg: Good signature from "Eris Discordia <discord@example.net>"
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg: There is no indication that the signature belongs to the owner.
+Primary key fingerprint: D4BE 2231 1AD3 131E 5EDA 29A4 6109 2E85 B722 7189
+tree eebfed94e75e7760540d1485c740902590a00332
+parent 04b871796dc0420f8e7561a895b52484b701d51a
+author A U Thor <author@example.com> 1465981137 +0000
+committer C O Mitter <committer@example.com> 1465981137 +0000
+
+signed commit
+
+signed commit message body
+----
+
+== Mergetag signatures
+
+- created by: `git merge` on signed tag
+- payload/embedding: the whole signed tag object is embedded into
+ the (merge) commit object as header entry `mergetag`
+- example: merge of the signed tag `signedtag` as above
+
+----
+tree c7b1cff039a93f3600a1d18b82d26688668c7dea
+parent c33429be94b5f2d3ee9b0adad223f877f174b05d
+parent 04b871796dc0420f8e7561a895b52484b701d51a
+author A U Thor <author@example.com> 1465982009 +0000
+committer C O Mitter <committer@example.com> 1465982009 +0000
+mergetag object 04b871796dc0420f8e7561a895b52484b701d51a
+ type commit
+ tag signedtag
+ tagger C O Mitter <committer@example.com> 1465981006 +0000
+ $
+ signed tag
+ $
+ signed tag message body
+ -----BEGIN PGP SIGNATURE-----
+ Version: GnuPG v1
+ $
+ iQEcBAABAgAGBQJXYRhOAAoJEGEJLoW3InGJklkIAIcnhL7RwEb/+QeX9enkXhxn
+ rxfdqrvWd1K80sl2TOt8Bg/NYwrUBw/RWJ+sg/hhHp4WtvE1HDGHlkEz3y11Lkuh
+ 8tSxS3qKTxXUGozyPGuE90sJfExhZlW4knIQ1wt/yWqM+33E9pN4hzPqLwyrdods
+ q8FWEqPPUbSJXoMbRPw04S5jrLtZSsUWbRYjmJCHzlhSfFWW4eFd37uquIaLUBS0
+ rkC3Jrx7420jkIpgFcTI2s60uhSQLzgcCwdA2ukSYIRnjg/zDkj8+3h/GaROJ72x
+ lZyI6HWixKJkWw8lE9aAOD9TmTW9sFJwcVAzmAuFX2kUreDUKMZduGcoRYGpD7E=
+ =jpXa
+ -----END PGP SIGNATURE-----
+
+Merge tag 'signedtag' into downstream
+
+signed tag
+
+signed tag message body
+
+# gpg: Signature made Wed Jun 15 08:56:46 2016 UTC using RSA key ID B7227189
+# gpg: Good signature from "Eris Discordia <discord@example.net>"
+# gpg: WARNING: This key is not certified with a trusted signature!
+# gpg: There is no indication that the signature belongs to the owner.
+# Primary key fingerprint: D4BE 2231 1AD3 131E 5EDA 29A4 6109 2E85 B722 7189
+----
+
+- verify with: verification is embedded in merge commit message by default,
+ alternatively with `git show --show-signature`:
+
+----
+commit 9863f0c76ff78712b6800e199a46aa56afbcbd49
+merged tag 'signedtag'
+gpg: Signature made Wed Jun 15 10:56:46 2016 CEST using RSA key ID B7227189
+gpg: Good signature from "Eris Discordia <discord@example.net>"
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg: There is no indication that the signature belongs to the owner.
+Primary key fingerprint: D4BE 2231 1AD3 131E 5EDA 29A4 6109 2E85 B722 7189
+Merge: c33429b 04b8717
+Author: A U Thor <author@example.com>
+Date: Wed Jun 15 09:13:29 2016 +0000
+
+ Merge tag 'signedtag' into downstream
+
+ signed tag
+
+ signed tag message body
+
+ # gpg: Signature made Wed Jun 15 08:56:46 2016 UTC using RSA key ID B7227189
+ # gpg: Good signature from "Eris Discordia <discord@example.net>"
+ # gpg: WARNING: This key is not certified with a trusted signature!
+ # gpg: There is no indication that the signature belongs to the owner.
+ # Primary key fingerprint: D4BE 2231 1AD3 131E 5EDA 29A4 6109 2E85 B722 7189
+----
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitglossary.adoc b/gitglossary.adoc
new file mode 100644
index 0000000..0e85be4
--- /dev/null
+++ b/gitglossary.adoc
@@ -0,0 +1,27 @@
+gitglossary(7)
+==============
+
+NAME
+----
+gitglossary - A Git Glossary
+
+SYNOPSIS
+--------
+*
+
+DESCRIPTION
+-----------
+
+include::glossary-content.adoc[]
+
+SEE ALSO
+--------
+linkgit:gittutorial[7],
+linkgit:gittutorial-2[7],
+linkgit:gitcvs-migration[7],
+linkgit:giteveryday[7],
+link:user-manual.html[The Git User's Manual]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/githooks.adoc b/githooks.adoc
new file mode 100644
index 0000000..0397dec
--- /dev/null
+++ b/githooks.adoc
@@ -0,0 +1,767 @@
+githooks(5)
+===========
+
+NAME
+----
+githooks - Hooks used by Git
+
+SYNOPSIS
+--------
+$GIT_DIR/hooks/* (or \`git config core.hooksPath`/*)
+
+
+DESCRIPTION
+-----------
+
+Hooks are programs you can place in a hooks directory to trigger
+actions at certain points in git's execution. Hooks that don't have
+the executable bit set are ignored.
+
+By default the hooks directory is `$GIT_DIR/hooks`, but that can be
+changed via the `core.hooksPath` configuration variable (see
+linkgit:git-config[1]).
+
+Before Git invokes a hook, it changes its working directory to either
+$GIT_DIR in a bare repository or the root of the working tree in a non-bare
+repository. An exception are hooks triggered during a push ('pre-receive',
+'update', 'post-receive', 'post-update', 'push-to-checkout') which are always
+executed in $GIT_DIR.
+
+Environment variables, such as `GIT_DIR`, `GIT_WORK_TREE`, etc., are exported
+so that Git commands run by the hook can correctly locate the repository. If
+your hook needs to invoke Git commands in a foreign repository or in a
+different working tree of the same repository, then it should clear these
+environment variables so they do not interfere with Git operations at the
+foreign location. For example:
+
+------------
+local_desc=$(git describe)
+foreign_desc=$(unset $(git rev-parse --local-env-vars); git -C ../foreign-repo describe)
+------------
+
+Hooks can get their arguments via the environment, command-line
+arguments, and stdin. See the documentation for each hook below for
+details.
+
+`git init` may copy hooks to the new repository, depending on its
+configuration. See the "TEMPLATE DIRECTORY" section in
+linkgit:git-init[1] for details. When the rest of this document refers
+to "default hooks" it's talking about the default template shipped
+with Git.
+
+The currently supported hooks are described below.
+
+HOOKS
+-----
+
+applypatch-msg
+~~~~~~~~~~~~~~
+
+This hook is invoked by linkgit:git-am[1]. It takes a single
+parameter, the name of the file that holds the proposed commit
+log message. Exiting with a non-zero status causes `git am` to abort
+before applying the patch.
+
+The hook is allowed to edit the message file in place, and can
+be used to normalize the message into some project standard
+format. It can also be used to refuse the commit after inspecting
+the message file.
+
+The default 'applypatch-msg' hook, when enabled, runs the
+'commit-msg' hook, if the latter is enabled.
+
+pre-applypatch
+~~~~~~~~~~~~~~
+
+This hook is invoked by linkgit:git-am[1]. It takes no parameter, and is
+invoked after the patch is applied, but before a commit is made.
+
+If it exits with non-zero status, then the working tree will not be
+committed after applying the patch.
+
+It can be used to inspect the current working tree and refuse to
+make a commit if it does not pass certain tests.
+
+The default 'pre-applypatch' hook, when enabled, runs the
+'pre-commit' hook, if the latter is enabled.
+
+post-applypatch
+~~~~~~~~~~~~~~~
+
+This hook is invoked by linkgit:git-am[1]. It takes no parameter,
+and is invoked after the patch is applied and a commit is made.
+
+This hook is meant primarily for notification, and cannot affect
+the outcome of `git am`.
+
+pre-commit
+~~~~~~~~~~
+
+This hook is invoked by linkgit:git-commit[1], and can be bypassed
+with the `--no-verify` option. It takes no parameters, and is
+invoked before obtaining the proposed commit log message and
+making a commit. Exiting with a non-zero status from this script
+causes the `git commit` command to abort before creating a commit.
+
+The default 'pre-commit' hook, when enabled, catches introduction
+of lines with trailing whitespaces and aborts the commit when
+such a line is found.
+
+All the `git commit` hooks are invoked with the environment
+variable `GIT_EDITOR=:` if the command will not bring up an editor
+to modify the commit message.
+
+The default 'pre-commit' hook, when enabled--and with the
+`hooks.allownonascii` config option unset or set to false--prevents
+the use of non-ASCII filenames.
+
+pre-merge-commit
+~~~~~~~~~~~~~~~~
+
+This hook is invoked by linkgit:git-merge[1], and can be bypassed
+with the `--no-verify` option. It takes no parameters, and is
+invoked after the merge has been carried out successfully and before
+obtaining the proposed commit log message to
+make a commit. Exiting with a non-zero status from this script
+causes the `git merge` command to abort before creating a commit.
+
+The default 'pre-merge-commit' hook, when enabled, runs the
+'pre-commit' hook, if the latter is enabled.
+
+This hook is invoked with the environment variable
+`GIT_EDITOR=:` if the command will not bring up an editor
+to modify the commit message.
+
+If the merge cannot be carried out automatically, the conflicts
+need to be resolved and the result committed separately (see
+linkgit:git-merge[1]). At that point, this hook will not be executed,
+but the 'pre-commit' hook will, if it is enabled.
+
+prepare-commit-msg
+~~~~~~~~~~~~~~~~~~
+
+This hook is invoked by linkgit:git-commit[1] right after preparing the
+default log message, and before the editor is started.
+
+It takes one to three parameters. The first is the name of the file
+that contains the commit log message. The second is the source of the commit
+message, and can be: `message` (if a `-m` or `-F` option was
+given); `template` (if a `-t` option was given or the
+configuration option `commit.template` is set); `merge` (if the
+commit is a merge or a `.git/MERGE_MSG` file exists); `squash`
+(if a `.git/SQUASH_MSG` file exists); or `commit`, followed by
+a commit object name (if a `-c`, `-C` or `--amend` option was given).
+
+If the exit status is non-zero, `git commit` will abort.
+
+The purpose of the hook is to edit the message file in place, and
+it is not suppressed by the `--no-verify` option. A non-zero exit
+means a failure of the hook and aborts the commit. It should not
+be used as a replacement for the pre-commit hook.
+
+The sample `prepare-commit-msg` hook that comes with Git removes the
+help message found in the commented portion of the commit template.
+
+commit-msg
+~~~~~~~~~~
+
+This hook is invoked by linkgit:git-commit[1] and linkgit:git-merge[1], and can be
+bypassed with the `--no-verify` option. It takes a single parameter,
+the name of the file that holds the proposed commit log message.
+Exiting with a non-zero status causes the command to abort.
+
+The hook is allowed to edit the message file in place, and can be used
+to normalize the message into some project standard format. It
+can also be used to refuse the commit after inspecting the message
+file.
+
+The default 'commit-msg' hook, when enabled, detects duplicate
+`Signed-off-by` trailers, and aborts the commit if one is found.
+
+post-commit
+~~~~~~~~~~~
+
+This hook is invoked by linkgit:git-commit[1]. It takes no parameters, and is
+invoked after a commit is made.
+
+This hook is meant primarily for notification, and cannot affect
+the outcome of `git commit`.
+
+pre-rebase
+~~~~~~~~~~
+
+This hook is called by linkgit:git-rebase[1] and can be used to prevent a
+branch from getting rebased. The hook may be called with one or
+two parameters. The first parameter is the upstream from which
+the series was forked. The second parameter is the branch being
+rebased, and is not set when rebasing the current branch.
+
+post-checkout
+~~~~~~~~~~~~~
+
+This hook is invoked when a linkgit:git-checkout[1] or
+linkgit:git-switch[1] is run after having updated the
+worktree. The hook is given three parameters: the ref of the previous HEAD,
+the ref of the new HEAD (which may or may not have changed), and a flag
+indicating whether the checkout was a branch checkout (changing branches,
+flag=1) or a file checkout (retrieving a file from the index, flag=0).
+This hook cannot affect the outcome of `git switch` or `git checkout`,
+other than that the hook's exit status becomes the exit status of
+these two commands.
+
+It is also run after linkgit:git-clone[1], unless the `--no-checkout` (`-n`) option is
+used. The first parameter given to the hook is the null-ref, the second the
+ref of the new HEAD and the flag is always 1. Likewise for `git worktree add`
+unless `--no-checkout` is used.
+
+This hook can be used to perform repository validity checks, auto-display
+differences from the previous HEAD if different, or set working dir metadata
+properties.
+
+post-merge
+~~~~~~~~~~
+
+This hook is invoked by linkgit:git-merge[1], which happens when a `git pull`
+is done on a local repository. The hook takes a single parameter, a status
+flag specifying whether or not the merge being done was a squash merge.
+This hook cannot affect the outcome of `git merge` and is not executed,
+if the merge failed due to conflicts.
+
+This hook can be used in conjunction with a corresponding pre-commit hook to
+save and restore any form of metadata associated with the working tree
+(e.g.: permissions/ownership, ACLS, etc). See contrib/hooks/setgitperms.perl
+for an example of how to do this.
+
+pre-push
+~~~~~~~~
+
+This hook is called by linkgit:git-push[1] and can be used to prevent
+a push from taking place. The hook is called with two parameters
+which provide the name and location of the destination remote, if a
+named remote is not being used both values will be the same.
+
+Information about what is to be pushed is provided on the hook's standard
+input with lines of the form:
+
+ <local-ref> SP <local-object-name> SP <remote-ref> SP <remote-object-name> LF
+
+For instance, if the command +git push origin master:foreign+ were run the
+hook would receive a line like the following:
+
+ refs/heads/master 67890 refs/heads/foreign 12345
+
+although the full object name would be supplied. If the foreign ref does not
+yet exist the `<remote-object-name>` will be the all-zeroes object name. If a
+ref is to be deleted, the `<local-ref>` will be supplied as `(delete)` and the
+`<local-object-name>` will be the all-zeroes object name. If the local commit
+was specified by something other than a name which could be expanded (such as
+`HEAD~`, or an object name) it will be supplied as it was originally given.
+
+If this hook exits with a non-zero status, `git push` will abort without
+pushing anything. Information about why the push is rejected may be sent
+to the user by writing to standard error.
+
+[[pre-receive]]
+pre-receive
+~~~~~~~~~~~
+
+This hook is invoked by linkgit:git-receive-pack[1] when it reacts to
+`git push` and updates reference(s) in its repository.
+Just before starting to update refs on the remote repository, the
+pre-receive hook is invoked. Its exit status determines the success
+or failure of the update.
+
+This hook executes once for the receive operation. It takes no
+arguments, but for each ref to be updated it receives on standard
+input a line of the format:
+
+ <old-oid> SP <new-oid> SP <ref-name> LF
+
+where `<old-oid>` is the old object name stored in the ref,
+`<new-oid>` is the new object name to be stored in the ref and
+`<ref-name>` is the full name of the ref.
+When creating a new ref, `<old-oid>` is the all-zeroes object name.
+
+If the hook exits with non-zero status, none of the refs will be
+updated. If the hook exits with zero, updating of individual refs can
+still be prevented by the <<update,'update'>> hook.
+
+Both standard output and standard error output are forwarded to
+`git send-pack` on the other end, so you can simply `echo` messages
+for the user.
+
+The number of push options given on the command line of
+`git push --push-option=...` can be read from the environment
+variable `GIT_PUSH_OPTION_COUNT`, and the options themselves are
+found in `GIT_PUSH_OPTION_0`, `GIT_PUSH_OPTION_1`,...
+If it is negotiated to not use the push options phase, the
+environment variables will not be set. If the client selects
+to use push options, but doesn't transmit any, the count variable
+will be set to zero, `GIT_PUSH_OPTION_COUNT=0`.
+
+See the section on "Quarantine Environment" in
+linkgit:git-receive-pack[1] for some caveats.
+
+[[update]]
+update
+~~~~~~
+
+This hook is invoked by linkgit:git-receive-pack[1] when it reacts to
+`git push` and updates reference(s) in its repository.
+Just before updating the ref on the remote repository, the update hook
+is invoked. Its exit status determines the success or failure of
+the ref update.
+
+The hook executes once for each ref to be updated, and takes
+three parameters:
+
+ - the name of the ref being updated,
+ - the old object name stored in the ref,
+ - and the new object name to be stored in the ref.
+
+A zero exit from the update hook allows the ref to be updated.
+Exiting with a non-zero status prevents `git receive-pack`
+from updating that ref.
+
+This hook can be used to prevent 'forced' update on certain refs by
+making sure that the object name is a commit object that is a
+descendant of the commit object named by the old object name.
+That is, to enforce a "fast-forward only" policy.
+
+It could also be used to log the old..new status. However, it
+does not know the entire set of branches, so it would end up
+firing one e-mail per ref when used naively, though. The
+<<post-receive,'post-receive'>> hook is more suited to that.
+
+In an environment that restricts the users' access only to git
+commands over the wire, this hook can be used to implement access
+control without relying on filesystem ownership and group
+membership. See linkgit:git-shell[1] for how you might use the login
+shell to restrict the user's access to only git commands.
+
+Both standard output and standard error output are forwarded to
+`git send-pack` on the other end, so you can simply `echo` messages
+for the user.
+
+The default 'update' hook, when enabled--and with
+`hooks.allowunannotated` config option unset or set to false--prevents
+unannotated tags from being pushed.
+
+[[proc-receive]]
+proc-receive
+~~~~~~~~~~~~
+
+This hook is invoked by linkgit:git-receive-pack[1]. If the server has
+set the multi-valued config variable `receive.procReceiveRefs`, and the
+commands sent to 'receive-pack' have matching reference names, these
+commands will be executed by this hook, instead of by the internal
+`execute_commands()` function. This hook is responsible for updating
+the relevant references and reporting the results back to 'receive-pack'.
+
+This hook executes once for the receive operation. It takes no
+arguments, but uses a pkt-line format protocol to communicate with
+'receive-pack' to read commands, push-options and send results. In the
+following example for the protocol, the letter 'S' stands for
+'receive-pack' and the letter 'H' stands for this hook.
+
+ # Version and features negotiation.
+ S: PKT-LINE(version=1\0push-options atomic...)
+ S: flush-pkt
+ H: PKT-LINE(version=1\0push-options...)
+ H: flush-pkt
+
+ # Send commands from server to the hook.
+ S: PKT-LINE(<old-oid> <new-oid> <ref>)
+ S: ... ...
+ S: flush-pkt
+ # Send push-options only if the 'push-options' feature is enabled.
+ S: PKT-LINE(push-option)
+ S: ... ...
+ S: flush-pkt
+
+ # Receive results from the hook.
+ # OK, run this command successfully.
+ H: PKT-LINE(ok <ref>)
+ # NO, I reject it.
+ H: PKT-LINE(ng <ref> <reason>)
+ # Fall through, let 'receive-pack' execute it.
+ H: PKT-LINE(ok <ref>)
+ H: PKT-LINE(option fall-through)
+ # OK, but has an alternate reference. The alternate reference name
+ # and other status can be given in option directives.
+ H: PKT-LINE(ok <ref>)
+ H: PKT-LINE(option refname <refname>)
+ H: PKT-LINE(option old-oid <old-oid>)
+ H: PKT-LINE(option new-oid <new-oid>)
+ H: PKT-LINE(option forced-update)
+ H: ... ...
+ H: flush-pkt
+
+Each command for the 'proc-receive' hook may point to a pseudo-reference
+and always has a zero-old as its old-oid, while the 'proc-receive' hook
+may update an alternate reference and the alternate reference may exist
+already with a non-zero old-oid. For this case, this hook will use
+"option" directives to report extended attributes for the reference given
+by the leading "ok" directive.
+
+The report of the commands of this hook should have the same order as
+the input. The exit status of the 'proc-receive' hook only determines
+the success or failure of the group of commands sent to it, unless
+atomic push is in use.
+
+[[post-receive]]
+post-receive
+~~~~~~~~~~~~
+
+This hook is invoked by linkgit:git-receive-pack[1] when it reacts to
+`git push` and updates reference(s) in its repository.
+The hook executes on the remote repository once after all the proposed
+ref updates are processed and if at least one ref is updated as the
+result.
+
+The hook takes no arguments. It receives one line on standard input for
+each ref that is successfully updated following the same format as the
+<<pre-receive,'pre-receive'>> hook.
+
+This hook does not affect the outcome of `git receive-pack`, as it
+is called after the real work is done.
+
+This supersedes the <<post-update,'post-update'>> hook in that it gets
+both old and new values of all the refs in addition to their
+names.
+
+Both standard output and standard error output are forwarded to
+`git send-pack` on the other end, so you can simply `echo` messages
+for the user.
+
+The default 'post-receive' hook is empty, but there is
+a sample script `post-receive-email` provided in the `contrib/hooks`
+directory in Git distribution, which implements sending commit
+emails.
+
+The number of push options given on the command line of
+`git push --push-option=...` can be read from the environment
+variable `GIT_PUSH_OPTION_COUNT`, and the options themselves are
+found in `GIT_PUSH_OPTION_0`, `GIT_PUSH_OPTION_1`,...
+If it is negotiated to not use the push options phase, the
+environment variables will not be set. If the client selects
+to use push options, but doesn't transmit any, the count variable
+will be set to zero, `GIT_PUSH_OPTION_COUNT=0`.
+
+See the "post-receive" section in linkgit:git-receive-pack[1] for
+additional details.
+
+[[post-update]]
+post-update
+~~~~~~~~~~~
+
+This hook is invoked by linkgit:git-receive-pack[1] when it reacts to
+`git push` and updates reference(s) in its repository.
+It executes on the remote repository once after all the refs have
+been updated.
+
+It takes a variable number of parameters, each of which is the
+name of ref that was actually updated.
+
+This hook is meant primarily for notification, and cannot affect
+the outcome of `git receive-pack`.
+
+The 'post-update' hook can tell what are the heads that were pushed,
+but it does not know what their original and updated values are,
+so it is a poor place to do log old..new. The
+<<post-receive,'post-receive'>> hook does get both original and
+updated values of the refs. You might consider it instead if you need
+them.
+
+When enabled, the default 'post-update' hook runs
+`git update-server-info` to keep the information used by dumb
+transports (e.g., HTTP) up to date. If you are publishing
+a Git repository that is accessible via HTTP, you should
+probably enable this hook.
+
+Both standard output and standard error output are forwarded to
+`git send-pack` on the other end, so you can simply `echo` messages
+for the user.
+
+reference-transaction
+~~~~~~~~~~~~~~~~~~~~~
+
+This hook is invoked by any Git command that performs reference
+updates. It executes whenever a reference transaction is prepared,
+committed or aborted and may thus get called multiple times. The hook
+also supports symbolic reference updates.
+
+The hook takes exactly one argument, which is the current state the
+given reference transaction is in:
+
+ - "prepared": All reference updates have been queued to the
+ transaction and references were locked on disk.
+
+ - "committed": The reference transaction was committed and all
+ references now have their respective new value.
+
+ - "aborted": The reference transaction was aborted, no changes
+ were performed and the locks have been released.
+
+For each reference update that was added to the transaction, the hook
+receives on standard input a line of the format:
+
+ <old-value> SP <new-value> SP <ref-name> LF
+
+where `<old-value>` is the old object name passed into the reference
+transaction, `<new-value>` is the new object name to be stored in the
+ref and `<ref-name>` is the full name of the ref. When force updating
+the reference regardless of its current value or when the reference is
+to be created anew, `<old-value>` is the all-zeroes object name. To
+distinguish these cases, you can inspect the current value of
+`<ref-name>` via `git rev-parse`.
+
+For symbolic reference updates the `<old_value>` and `<new-value>`
+fields could denote references instead of objects. A reference will be
+denoted with a 'ref:' prefix, like `ref:<ref-target>`.
+
+The exit status of the hook is ignored for any state except for the
+"prepared" state. In the "prepared" state, a non-zero exit status will
+cause the transaction to be aborted. The hook will not be called with
+"aborted" state in that case.
+
+push-to-checkout
+~~~~~~~~~~~~~~~~
+
+This hook is invoked by linkgit:git-receive-pack[1] when it reacts to
+`git push` and updates reference(s) in its repository, and when
+the push tries to update the branch that is currently checked out
+and the `receive.denyCurrentBranch` configuration variable is set to
+`updateInstead`. Such a push by default is refused if the working
+tree and the index of the remote repository has any difference from
+the currently checked out commit; when both the working tree and the
+index match the current commit, they are updated to match the newly
+pushed tip of the branch. This hook is to be used to override the
+default behaviour.
+
+The hook receives the commit with which the tip of the current
+branch is going to be updated. It can exit with a non-zero status
+to refuse the push (when it does so, it must not modify the index or
+the working tree). Or it can make any necessary changes to the
+working tree and to the index to bring them to the desired state
+when the tip of the current branch is updated to the new commit, and
+exit with a zero status.
+
+For example, the hook can simply run `git read-tree -u -m HEAD "$1"`
+in order to emulate `git fetch` that is run in the reverse direction
+with `git push`, as the two-tree form of `git read-tree -u -m` is
+essentially the same as `git switch` or `git checkout`
+that switches branches while
+keeping the local changes in the working tree that do not interfere
+with the difference between the branches.
+
+
+pre-auto-gc
+~~~~~~~~~~~
+
+This hook is invoked by `git gc --auto` (see linkgit:git-gc[1]). It
+takes no parameter, and exiting with non-zero status from this script
+causes the `git gc --auto` to abort.
+
+post-rewrite
+~~~~~~~~~~~~
+
+This hook is invoked by commands that rewrite commits
+(linkgit:git-commit[1] when called with `--amend` and
+linkgit:git-rebase[1]; however, full-history (re)writing tools like
+linkgit:git-fast-import[1] or
+https://github.com/newren/git-filter-repo[git-filter-repo] typically
+do not call it!). Its first argument denotes the command it was
+invoked by: currently one of `amend` or `rebase`. Further
+command-dependent arguments may be passed in the future.
+
+The hook receives a list of the rewritten commits on stdin, in the
+format
+
+ <old-object-name> SP <new-object-name> [ SP <extra-info> ] LF
+
+The 'extra-info' is again command-dependent. If it is empty, the
+preceding SP is also omitted. Currently, no commands pass any
+'extra-info'.
+
+The hook always runs after the automatic note copying (see
+"notes.rewrite.<command>" in linkgit:git-config[1]) has happened, and
+thus has access to these notes.
+
+The following command-specific comments apply:
+
+rebase::
+ For the 'squash' and 'fixup' operation, all commits that were
+ squashed are listed as being rewritten to the squashed commit.
+ This means that there will be several lines sharing the same
+ 'new-object-name'.
++
+The commits are guaranteed to be listed in the order that they were
+processed by rebase.
+
+sendemail-validate
+~~~~~~~~~~~~~~~~~~
+
+This hook is invoked by linkgit:git-send-email[1].
+
+It takes these command line arguments. They are,
+1. the name of the file which holds the contents of the email to be sent.
+2. The name of the file which holds the SMTP headers of the email.
+
+The SMTP headers are passed in the exact same way as they are passed to the
+user's Mail Transport Agent (MTA). In effect, the email given to the user's
+MTA, is the contents of $2 followed by the contents of $1.
+
+An example of a few common headers is shown below. Take notice of the
+capitalization and multi-line tab structure.
+
+ From: Example <from@example.com>
+ To: to@example.com
+ Cc: cc@example.com,
+ A <author@example.com>,
+ One <one@example.com>,
+ two@example.com
+ Subject: PATCH-STRING
+
+Exiting with a non-zero status causes `git send-email` to abort
+before sending any e-mails.
+
+The following environment variables are set when executing the hook.
+
+`GIT_SENDEMAIL_FILE_COUNTER`::
+ A 1-based counter incremented by one for every file holding an e-mail
+ to be sent (excluding any FIFOs). This counter does not follow the
+ patch series counter scheme. It will always start at 1 and will end at
+ GIT_SENDEMAIL_FILE_TOTAL.
+
+`GIT_SENDEMAIL_FILE_TOTAL`::
+ The total number of files that will be sent (excluding any FIFOs). This
+ counter does not follow the patch series counter scheme. It will always
+ be equal to the number of files being sent, whether there is a cover
+ letter or not.
+
+These variables may for instance be used to validate patch series.
+
+The sample `sendemail-validate` hook that comes with Git checks that all sent
+patches (excluding the cover letter) can be applied on top of the upstream
+repository default branch without conflicts. Some placeholders are left for
+additional validation steps to be performed after all patches of a given series
+have been applied.
+
+fsmonitor-watchman
+~~~~~~~~~~~~~~~~~~
+
+This hook is invoked when the configuration option `core.fsmonitor` is
+set to `.git/hooks/fsmonitor-watchman` or `.git/hooks/fsmonitor-watchmanv2`
+depending on the version of the hook to use.
+
+Version 1 takes two arguments, a version (1) and the time in elapsed
+nanoseconds since midnight, January 1, 1970.
+
+Version 2 takes two arguments, a version (2) and a token that is used
+for identifying changes since the token. For watchman this would be
+a clock id. This version must output to stdout the new token followed
+by a NUL before the list of files.
+
+The hook should output to stdout the list of all files in the working
+directory that may have changed since the requested time. The logic
+should be inclusive so that it does not miss any potential changes.
+The paths should be relative to the root of the working directory
+and be separated by a single NUL.
+
+It is OK to include files which have not actually changed. All changes
+including newly-created and deleted files should be included. When
+files are renamed, both the old and the new name should be included.
+
+Git will limit what files it checks for changes as well as which
+directories are checked for untracked files based on the path names
+given.
+
+An optimized way to tell git "all files have changed" is to return
+the filename `/`.
+
+The exit status determines whether git will use the data from the
+hook to limit its search. On error, it will fall back to verifying
+all files and folders.
+
+p4-changelist
+~~~~~~~~~~~~~
+
+This hook is invoked by `git-p4 submit`.
+
+The `p4-changelist` hook is executed after the changelist
+message has been edited by the user. It can be bypassed with the
+`--no-verify` option. It takes a single parameter, the name
+of the file that holds the proposed changelist text. Exiting
+with a non-zero status causes the command to abort.
+
+The hook is allowed to edit the changelist file and can be used
+to normalize the text into some project standard format. It can
+also be used to refuse the Submit after inspect the message file.
+
+Run `git-p4 submit --help` for details.
+
+p4-prepare-changelist
+~~~~~~~~~~~~~~~~~~~~~
+
+This hook is invoked by `git-p4 submit`.
+
+The `p4-prepare-changelist` hook is executed right after preparing
+the default changelist message and before the editor is started.
+It takes one parameter, the name of the file that contains the
+changelist text. Exiting with a non-zero status from the script
+will abort the process.
+
+The purpose of the hook is to edit the message file in place,
+and it is not suppressed by the `--no-verify` option. This hook
+is called even if `--prepare-p4-only` is set.
+
+Run `git-p4 submit --help` for details.
+
+p4-post-changelist
+~~~~~~~~~~~~~~~~~~
+
+This hook is invoked by `git-p4 submit`.
+
+The `p4-post-changelist` hook is invoked after the submit has
+successfully occurred in P4. It takes no parameters and is meant
+primarily for notification and cannot affect the outcome of the
+git p4 submit action.
+
+Run `git-p4 submit --help` for details.
+
+p4-pre-submit
+~~~~~~~~~~~~~
+
+This hook is invoked by `git-p4 submit`. It takes no parameters and nothing
+from standard input. Exiting with non-zero status from this script prevent
+`git-p4 submit` from launching. It can be bypassed with the `--no-verify`
+command line option. Run `git-p4 submit --help` for details.
+
+
+
+post-index-change
+~~~~~~~~~~~~~~~~~
+
+This hook is invoked when the index is written in read-cache.c
+do_write_locked_index.
+
+The first parameter passed to the hook is the indicator for the
+working directory being updated. "1" meaning working directory
+was updated or "0" when the working directory was not updated.
+
+The second parameter passed to the hook is the indicator for whether
+or not the index was updated and the skip-worktree bit could have
+changed. "1" meaning skip-worktree bits could have been updated
+and "0" meaning they were not.
+
+Only one parameter should be set to "1" when the hook runs. The hook
+running passing "1", "1" should not be possible.
+
+SEE ALSO
+--------
+linkgit:git-hook[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitignore.adoc b/gitignore.adoc
new file mode 100644
index 0000000..5e0964e
--- /dev/null
+++ b/gitignore.adoc
@@ -0,0 +1,243 @@
+gitignore(5)
+============
+
+NAME
+----
+gitignore - Specifies intentionally untracked files to ignore
+
+SYNOPSIS
+--------
+$XDG_CONFIG_HOME/git/ignore, $GIT_DIR/info/exclude, .gitignore
+
+DESCRIPTION
+-----------
+
+A `gitignore` file specifies intentionally untracked files that
+Git should ignore.
+Files already tracked by Git are not affected; see the NOTES
+below for details.
+
+Each line in a `gitignore` file specifies a pattern.
+When deciding whether to ignore a path, Git normally checks
+`gitignore` patterns from multiple sources, with the following
+order of precedence, from highest to lowest (within one level of
+precedence, the last matching pattern decides the outcome):
+
+ * Patterns read from the command line for those commands that support
+ them.
+
+ * Patterns read from a `.gitignore` file in the same directory
+ as the path, or in any parent directory (up to the top-level of the working
+ tree), with patterns in the higher level files being overridden by those in
+ lower level files down to the directory containing the file. These patterns
+ match relative to the location of the `.gitignore` file. A project normally
+ includes such `.gitignore` files in its repository, containing patterns for
+ files generated as part of the project build.
+
+ * Patterns read from `$GIT_DIR/info/exclude`.
+
+ * Patterns read from the file specified by the configuration
+ variable `core.excludesFile`.
+
+Which file to place a pattern in depends on how the pattern is meant to
+be used.
+
+ * Patterns which should be version-controlled and distributed to
+ other repositories via clone (i.e., files that all developers will want
+ to ignore) should go into a `.gitignore` file.
+
+ * Patterns which are
+ specific to a particular repository but which do not need to be shared
+ with other related repositories (e.g., auxiliary files that live inside
+ the repository but are specific to one user's workflow) should go into
+ the `$GIT_DIR/info/exclude` file.
+
+ * Patterns which a user wants Git to
+ ignore in all situations (e.g., backup or temporary files generated by
+ the user's editor of choice) generally go into a file specified by
+ `core.excludesFile` in the user's `~/.gitconfig`. Its default value is
+ $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or
+ empty, $HOME/.config/git/ignore is used instead.
+
+The underlying Git plumbing tools, such as
+'git ls-files' and 'git read-tree', read
+`gitignore` patterns specified by command-line options, or from
+files specified by command-line options. Higher-level Git
+tools, such as 'git status' and 'git add',
+use patterns from the sources specified above.
+
+PATTERN FORMAT
+--------------
+
+ - A blank line matches no files, so it can serve as a separator
+ for readability.
+
+ - A line starting with # serves as a comment.
+ Put a backslash ("`\`") in front of the first hash for patterns
+ that begin with a hash.
+
+ - Trailing spaces are ignored unless they are quoted with backslash
+ ("`\`").
+
+ - An optional prefix "`!`" which negates the pattern; any
+ matching file excluded by a previous pattern will become
+ included again. It is not possible to re-include a file if a parent
+ directory of that file is excluded. Git doesn't list excluded
+ directories for performance reasons, so any patterns on contained
+ files have no effect, no matter where they are defined.
+ Put a backslash ("`\`") in front of the first "`!`" for patterns
+ that begin with a literal "`!`", for example, "`\!important!.txt`".
+
+ - The slash "`/`" is used as the directory separator. Separators may
+ occur at the beginning, middle or end of the `.gitignore` search pattern.
+
+ - If there is a separator at the beginning or middle (or both) of the
+ pattern, then the pattern is relative to the directory level of the
+ particular `.gitignore` file itself. Otherwise the pattern may also
+ match at any level below the `.gitignore` level.
+
+ - If there is a separator at the end of the pattern then the pattern
+ will only match directories, otherwise the pattern can match both
+ files and directories.
+
+ - For example, a pattern `doc/frotz/` matches `doc/frotz` directory,
+ but not `a/doc/frotz` directory; however `frotz/` matches `frotz`
+ and `a/frotz` that is a directory (all paths are relative from
+ the `.gitignore` file).
+
+ - An asterisk "`*`" matches anything except a slash.
+ The character "`?`" matches any one character except "`/`".
+ The range notation, e.g. `[a-zA-Z]`, can be used to match
+ one of the characters in a range. See fnmatch(3) and the
+ FNM_PATHNAME flag for a more detailed description.
+
+Two consecutive asterisks ("`**`") in patterns matched against
+full pathname may have special meaning:
+
+ - A leading "`**`" followed by a slash means match in all
+ directories. For example, "`**/foo`" matches file or directory
+ "`foo`" anywhere, the same as pattern "`foo`". "`**/foo/bar`"
+ matches file or directory "`bar`" anywhere that is directly
+ under directory "`foo`".
+
+ - A trailing "`/**`" matches everything inside. For example,
+ "`abc/**`" matches all files inside directory "`abc`", relative
+ to the location of the `.gitignore` file, with infinite depth.
+
+ - A slash followed by two consecutive asterisks then a slash
+ matches zero or more directories. For example, "`a/**/b`"
+ matches "`a/b`", "`a/x/b`", "`a/x/y/b`" and so on.
+
+ - Other consecutive asterisks are considered regular asterisks and
+ will match according to the previous rules.
+
+CONFIGURATION
+-------------
+
+The optional configuration variable `core.excludesFile` indicates a path to a
+file containing patterns of file names to exclude, similar to
+`$GIT_DIR/info/exclude`. Patterns in the exclude file are used in addition to
+those in `$GIT_DIR/info/exclude`.
+
+NOTES
+-----
+
+The purpose of gitignore files is to ensure that certain files
+not tracked by Git remain untracked.
+
+To stop tracking a file that is currently tracked, use
+'git rm --cached' to remove the file from the index. The filename
+can then be added to the `.gitignore` file to stop the file from
+being reintroduced in later commits.
+
+Git does not follow symbolic links when accessing a `.gitignore` file in
+the working tree. This keeps behavior consistent when the file is
+accessed from the index or a tree versus from the filesystem.
+
+EXAMPLES
+--------
+
+ - The pattern `hello.*` matches any file or directory
+ whose name begins with `hello.`. If one wants to restrict
+ this only to the directory and not in its subdirectories,
+ one can prepend the pattern with a slash, i.e. `/hello.*`;
+ the pattern now matches `hello.txt`, `hello.c` but not
+ `a/hello.java`.
+
+ - The pattern `foo/` will match a directory `foo` and
+ paths underneath it, but will not match a regular file
+ or a symbolic link `foo` (this is consistent with the
+ way how pathspec works in general in Git)
+
+ - The pattern `doc/frotz` and `/doc/frotz` have the same effect
+ in any `.gitignore` file. In other words, a leading slash
+ is not relevant if there is already a middle slash in
+ the pattern.
+
+ - The pattern `foo/*`, matches `foo/test.json`
+ (a regular file), `foo/bar` (a directory), but it does not match
+ `foo/bar/hello.c` (a regular file), as the asterisk in the
+ pattern does not match `bar/hello.c` which has a slash in it.
+
+--------------------------------------------------------------
+ $ git status
+ [...]
+ # Untracked files:
+ [...]
+ # Documentation/foo.html
+ # Documentation/gitignore.html
+ # file.o
+ # lib.a
+ # src/internal.o
+ [...]
+ $ cat .git/info/exclude
+ # ignore objects and archives, anywhere in the tree.
+ *.[oa]
+ $ cat Documentation/.gitignore
+ # ignore generated html files,
+ *.html
+ # except foo.html which is maintained by hand
+ !foo.html
+ $ git status
+ [...]
+ # Untracked files:
+ [...]
+ # Documentation/foo.html
+ [...]
+--------------------------------------------------------------
+
+Another example:
+
+--------------------------------------------------------------
+ $ cat .gitignore
+ vmlinux*
+ $ ls arch/foo/kernel/vm*
+ arch/foo/kernel/vmlinux.lds.S
+ $ echo '!/vmlinux*' >arch/foo/kernel/.gitignore
+--------------------------------------------------------------
+
+The second .gitignore prevents Git from ignoring
+`arch/foo/kernel/vmlinux.lds.S`.
+
+Example to exclude everything except a specific directory `foo/bar`
+(note the `/*` - without the slash, the wildcard would also exclude
+everything within `foo/bar`):
+
+--------------------------------------------------------------
+ $ cat .gitignore
+ # exclude everything except directory foo/bar
+ /*
+ !/foo
+ /foo/*
+ !/foo/bar
+--------------------------------------------------------------
+
+SEE ALSO
+--------
+linkgit:git-rm[1],
+linkgit:gitrepository-layout[5],
+linkgit:git-check-ignore[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitk.adoc b/gitk.adoc
new file mode 100644
index 0000000..58ce40d
--- /dev/null
+++ b/gitk.adoc
@@ -0,0 +1,188 @@
+gitk(1)
+=======
+
+NAME
+----
+gitk - The Git repository browser
+
+SYNOPSIS
+--------
+[verse]
+'gitk' [<options>] [<revision-range>] [--] [<path>...]
+
+DESCRIPTION
+-----------
+Displays changes in a repository or a selected set of commits. This includes
+visualizing the commit graph, showing information related to each commit, and
+the files in the trees of each revision.
+
+OPTIONS
+-------
+
+To control which revisions to show, gitk supports most options
+applicable to the 'git rev-list' command. It also supports a few
+options applicable to the 'git diff-*' commands to control how the
+changes each commit introduces are shown. Finally, it supports some
+gitk-specific options.
+
+gitk generally only understands options with arguments in the
+'stuck' form (see linkgit:gitcli[7]) due to limitations in the
+command-line parser.
+
+rev-list options and arguments
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This manual page describes only the most frequently used options. See
+linkgit:git-rev-list[1] for a complete list.
+
+--all::
+
+ Show all refs (branches, tags, etc.).
+
+--branches[=<pattern>]::
+--tags[=<pattern>]::
+--remotes[=<pattern>]::
+
+ Pretend as if all the branches (tags, remote branches, resp.)
+ are listed on the command line as '<commit>'. If '<pattern>'
+ is given, limit refs to ones matching given shell glob. If
+ pattern lacks '?', '{asterisk}', or '[', '/{asterisk}' at the
+ end is implied.
+
+--since=<date>::
+
+ Show commits more recent than a specific date.
+
+--until=<date>::
+
+ Show commits older than a specific date.
+
+--date-order::
+
+ Sort commits by date when possible.
+
+--merge::
+
+ After an attempt to merge stops with conflicts, show the commits on
+ the history between two branches (i.e. the HEAD and the MERGE_HEAD)
+ that modify the conflicted files and do not exist on all the heads
+ being merged.
+
+--left-right::
+
+ Mark which side of a symmetric difference a commit is reachable
+ from. Commits from the left side are prefixed with a `<`
+ symbol and those from the right with a `>` symbol.
+
+--full-history::
+
+ When filtering history with '<path>...', does not prune some
+ history. (See "History simplification" in linkgit:git-log[1]
+ for a more detailed explanation.)
+
+--simplify-merges::
+
+ Additional option to `--full-history` to remove some needless
+ merges from the resulting history, as there are no selected
+ commits contributing to this merge. (See "History
+ simplification" in linkgit:git-log[1] for a more detailed
+ explanation.)
+
+--ancestry-path::
+
+ When given a range of commits to display
+ (e.g. 'commit1..commit2' or 'commit2 {caret}commit1'), only
+ display commits that exist directly on the ancestry chain
+ between the 'commit1' and 'commit2', i.e. commits that are
+ both descendants of 'commit1', and ancestors of 'commit2'.
+ (See "History simplification" in linkgit:git-log[1] for a more
+ detailed explanation.)
+
+include::line-range-options.adoc[]
+
+<revision range>::
+
+ Limit the revisions to show. This can be either a single revision
+ meaning show from the given revision and back, or it can be a range in
+ the form "'<from>'..'<to>'" to show all revisions between '<from>' and
+ back to '<to>'. Note, more advanced revision selection can be applied.
+ For a more complete list of ways to spell object names, see
+ linkgit:gitrevisions[7].
+
+<path>...::
+
+ Limit commits to the ones touching files in the given paths. Note, to
+ avoid ambiguity with respect to revision names use "--" to separate the paths
+ from any preceding options.
+
+gitk-specific options
+~~~~~~~~~~~~~~~~~~~~~
+
+--argscmd=<command>::
+
+ Command to be run each time gitk has to determine the revision
+ range to show. The command is expected to print on its
+ standard output a list of additional revisions to be shown,
+ one per line. Use this instead of explicitly specifying a
+ '<revision-range>' if the set of commits to show may vary
+ between refreshes.
+
+--select-commit=<ref>::
+
+ Select the specified commit after loading the graph.
+ Default behavior is equivalent to specifying '--select-commit=HEAD'.
+
+Examples
+--------
+gitk v2.6.12.. include/scsi drivers/scsi::
+
+ Show the changes since version 'v2.6.12' that changed any
+ file in the include/scsi or drivers/scsi subdirectories
+
+gitk --since="2 weeks ago" \-- gitk::
+
+ Show the changes during the last two weeks to the file 'gitk'.
+ The "--" is necessary to avoid confusion with the *branch* named
+ 'gitk'
+
+gitk --max-count=100 --all \-- Makefile::
+
+ Show at most 100 changes made to the file 'Makefile'. Instead of only
+ looking for changes in the current branch look in all branches.
+
+Files
+-----
+User configuration and preferences are stored at:
+
+* `$XDG_CONFIG_HOME/git/gitk` if it exists, otherwise
+* `$HOME/.gitk` if it exists
+
+If neither of the above exist then `$XDG_CONFIG_HOME/git/gitk` is created and
+used by default. If '$XDG_CONFIG_HOME' is not set it defaults to
+`$HOME/.config` in all cases.
+
+History
+-------
+Gitk was the first graphical repository browser. It's written in
+tcl/tk.
+
+'gitk' is actually maintained as an independent project, but stable
+versions are distributed as part of the Git suite for the convenience
+of end users.
+
+gitk-git/ comes from Paul Mackerras's gitk project:
+
+ git://ozlabs.org/~paulus/gitk
+
+SEE ALSO
+--------
+'qgit(1)'::
+ A repository browser written in C++ using Qt.
+
+'tig(1)'::
+ A minimal repository browser and Git tool output highlighter written
+ in C using Ncurses.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitmailmap.adoc b/gitmailmap.adoc
new file mode 100644
index 0000000..06f4af9
--- /dev/null
+++ b/gitmailmap.adoc
@@ -0,0 +1,130 @@
+gitmailmap(5)
+=============
+
+NAME
+----
+gitmailmap - Map author/committer names and/or E-Mail addresses
+
+SYNOPSIS
+--------
+$GIT_WORK_TREE/.mailmap
+
+
+DESCRIPTION
+-----------
+
+If the file `.mailmap` exists at the toplevel of the repository, or at
+the location pointed to by the `mailmap.file` or `mailmap.blob`
+configuration options (see linkgit:git-config[1]), it
+is used to map author and committer names and email addresses to
+canonical real names and email addresses.
+
+
+SYNTAX
+------
+
+The '#' character begins a comment to the end of line, blank lines
+are ignored.
+
+In the simple form, each line in the file consists of the canonical
+real name of an author, whitespace, and an email address used in the
+commit (enclosed by '<' and '>') to map to the name. For example:
+--
+ Proper Name <commit@email.xx>
+--
+
+The more complex forms are:
+--
+ <proper@email.xx> <commit@email.xx>
+--
+which allows mailmap to replace only the email part of a commit, and:
+--
+ Proper Name <proper@email.xx> <commit@email.xx>
+--
+which allows mailmap to replace both the name and the email of a
+commit matching the specified commit email address, and:
+--
+ Proper Name <proper@email.xx> Commit Name <commit@email.xx>
+--
+which allows mailmap to replace both the name and the email of a
+commit matching both the specified commit name and email address.
+
+Both E-Mails and names are matched case-insensitively. For example
+this would also match the 'Commit Name <commit@email.xx>' above:
+--
+ Proper Name <proper@email.xx> CoMmIt NaMe <CoMmIt@EmAiL.xX>
+--
+
+NOTES
+-----
+
+Git does not follow symbolic links when accessing a `.mailmap` file in
+the working tree. This keeps behavior consistent when the file is
+accessed from the index or a tree versus from the filesystem.
+
+EXAMPLES
+--------
+
+Your history contains commits by two authors, Jane
+and Joe, whose names appear in the repository under several forms:
+
+------------
+Joe Developer <joe@example.com>
+Joe R. Developer <joe@example.com>
+Jane Doe <jane@example.com>
+Jane Doe <jane@laptop.(none)>
+Jane D. <jane@desktop.(none)>
+------------
+
+Now suppose that Joe wants his middle name initial used, and Jane
+prefers her family name fully spelled out. A `.mailmap` file to
+correct the names would look like:
+
+------------
+Joe R. Developer <joe@example.com>
+Jane Doe <jane@example.com>
+Jane Doe <jane@desktop.(none)>
+------------
+
+Note that there's no need to map the name for '<jane@laptop.(none)>' to
+only correct the names. However, leaving the obviously broken
+'<jane@laptop.(none)>' and '<jane@desktop.(none)>' E-Mails as-is is
+usually not what you want. A `.mailmap` file which also corrects those
+is:
+
+------------
+Joe R. Developer <joe@example.com>
+Jane Doe <jane@example.com> <jane@laptop.(none)>
+Jane Doe <jane@example.com> <jane@desktop.(none)>
+------------
+
+Finally, let's say that Joe and Jane shared an E-Mail address, but not
+a name, e.g. by having these two commits in the history generated by a
+bug reporting system. I.e. names appearing in history as:
+
+------------
+Joe <bugs@example.com>
+Jane <bugs@example.com>
+------------
+
+A full `.mailmap` file which also handles those cases (an addition of
+two lines to the above example) would be:
+
+------------
+Joe R. Developer <joe@example.com>
+Jane Doe <jane@example.com> <jane@laptop.(none)>
+Jane Doe <jane@example.com> <jane@desktop.(none)>
+Joe R. Developer <joe@example.com> Joe <bugs@example.com>
+Jane Doe <jane@example.com> Jane <bugs@example.com>
+------------
+
+
+
+SEE ALSO
+--------
+linkgit:git-check-mailmap[1]
+
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitmodules.adoc b/gitmodules.adoc
new file mode 100644
index 0000000..d9bec8b
--- /dev/null
+++ b/gitmodules.adoc
@@ -0,0 +1,135 @@
+gitmodules(5)
+=============
+
+NAME
+----
+gitmodules - Defining submodule properties
+
+SYNOPSIS
+--------
+$GIT_WORK_TREE/.gitmodules
+
+
+DESCRIPTION
+-----------
+
+The `.gitmodules` file, located in the top-level directory of a Git
+working tree, is a text file with a syntax matching the requirements
+of linkgit:git-config[1].
+
+The file contains one subsection per submodule, and the subsection value
+is the name of the submodule. The name is set to the path where the
+submodule has been added unless it was customized with the `--name`
+option of 'git submodule add'. Each submodule section also contains the
+following required keys:
+
+submodule.<name>.path::
+ Defines the path, relative to the top-level directory of the Git
+ working tree, where the submodule is expected to be checked out.
+ The path name must not end with a `/`. All submodule paths must
+ be unique within the `.gitmodules` file.
+
+submodule.<name>.url::
+ Defines a URL from which the submodule repository can be cloned.
+ This may be either an absolute URL ready to be passed to
+ linkgit:git-clone[1] or (if it begins with `./` or `../`) a location
+ relative to the superproject's origin repository.
+
+In addition, there are a number of optional keys:
+
+submodule.<name>.update::
+ Defines the default update procedure for the named submodule,
+ i.e. how the submodule is updated by the `git submodule update`
+ command in the superproject. This is only used by `git
+ submodule init` to initialize the configuration variable of
+ the same name. Allowed values here are 'checkout', 'rebase',
+ 'merge' or 'none', but not '!command' (for security reasons).
+ See the description of the 'update' command in
+ linkgit:git-submodule[1] for more details.
+
+submodule.<name>.branch::
+ A remote branch name for tracking updates in the upstream submodule.
+ If the option is not specified, it defaults to the remote `HEAD`.
+ A special value of `.` is used to indicate that the name of the branch
+ in the submodule should be the same name as the current branch in the
+ current repository. See the `--remote` documentation in
+ linkgit:git-submodule[1] for details.
+
+submodule.<name>.fetchRecurseSubmodules::
+ This option can be used to control recursive fetching of this
+ submodule. If this option is also present in the submodule's entry in
+ `.git/config` of the superproject, the setting there will override the
+ one found in `.gitmodules`.
+ Both settings can be overridden on the command line by using the
+ `--[no-]recurse-submodules` option to `git fetch` and `git pull`.
+
+submodule.<name>.ignore::
+ Defines under what circumstances `git status` and the diff family show
+ a submodule as modified. The following values are supported:
++
+--
+ all;; The submodule will never be considered modified (but will
+ nonetheless show up in the output of status and commit when it has
+ been staged).
+
+ dirty;; All changes to the submodule's work tree will be ignored, only
+ committed differences between the `HEAD` of the submodule and its
+ recorded state in the superproject are taken into account.
+
+ untracked;; Only untracked files in submodules will be ignored.
+ Committed differences and modifications to tracked files will show
+ up.
+
+ none;; No modifications to submodules are ignored, all of committed
+ differences, and modifications to tracked and untracked files are
+ shown. This is the default option.
+
+If this option is also present in the submodule's entry in `.git/config`
+of the superproject, the setting there will override the one found in
+`.gitmodules`.
+
+Both settings can be overridden on the command line by using the
+`--ignore-submodules` option. The `git submodule` commands are not
+affected by this setting.
+--
+
+submodule.<name>.shallow::
+ When set to true, a clone of this submodule will be performed as a
+ shallow clone (with a history depth of 1) unless the user explicitly
+ asks for a non-shallow clone.
+
+NOTES
+-----
+
+Git does not allow the `.gitmodules` file within a working tree to be a
+symbolic link, and will refuse to check out such a tree entry. This
+keeps behavior consistent when the file is accessed from the index or a
+tree versus from the filesystem, and helps Git reliably enforce security
+checks of the file contents.
+
+EXAMPLES
+--------
+
+Consider the following `.gitmodules` file:
+
+----
+[submodule "libfoo"]
+ path = include/foo
+ url = git://foo.com/git/lib.git
+
+[submodule "libbar"]
+ path = include/bar
+ url = git://bar.com/git/lib.git
+----
+
+This defines two submodules, `libfoo` and `libbar`. These are expected to
+be checked out in the paths `include/foo` and `include/bar`, and for both
+submodules a URL is specified which can be used for cloning the submodules.
+
+SEE ALSO
+--------
+linkgit:git-submodule[1], linkgit:gitsubmodules[7], linkgit:git-config[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitnamespaces.adoc b/gitnamespaces.adoc
new file mode 100644
index 0000000..06f4d37
--- /dev/null
+++ b/gitnamespaces.adoc
@@ -0,0 +1,68 @@
+gitnamespaces(7)
+================
+
+NAME
+----
+gitnamespaces - Git namespaces
+
+SYNOPSIS
+--------
+[verse]
+GIT_NAMESPACE=<namespace> 'git upload-pack'
+GIT_NAMESPACE=<namespace> 'git receive-pack'
+
+
+DESCRIPTION
+-----------
+
+Git supports dividing the refs of a single repository into multiple
+namespaces, each of which has its own branches, tags, and HEAD. Git can
+expose each namespace as an independent repository to pull from and push
+to, while sharing the object store, and exposing all the refs to
+operations such as linkgit:git-gc[1].
+
+Storing multiple repositories as namespaces of a single repository
+avoids storing duplicate copies of the same objects, such as when
+storing multiple branches of the same source. The alternates mechanism
+provides similar support for avoiding duplicates, but alternates do not
+prevent duplication between new objects added to the repositories
+without ongoing maintenance, while namespaces do.
+
+To specify a namespace, set the `GIT_NAMESPACE` environment variable to
+the namespace. For each ref namespace, Git stores the corresponding
+refs in a directory under `refs/namespaces/`. For example,
+`GIT_NAMESPACE=foo` will store refs under `refs/namespaces/foo/`. You
+can also specify namespaces via the `--namespace` option to
+linkgit:git[1].
+
+Note that namespaces which include a `/` will expand to a hierarchy of
+namespaces; for example, `GIT_NAMESPACE=foo/bar` will store refs under
+`refs/namespaces/foo/refs/namespaces/bar/`. This makes paths in
+`GIT_NAMESPACE` behave hierarchically, so that cloning with
+`GIT_NAMESPACE=foo/bar` produces the same result as cloning with
+`GIT_NAMESPACE=foo` and cloning from that repo with `GIT_NAMESPACE=bar`. It
+also avoids ambiguity with strange namespace paths such as `foo/refs/heads/`,
+which could otherwise generate directory/file conflicts within the `refs`
+directory.
+
+linkgit:git-upload-pack[1] and linkgit:git-receive-pack[1] rewrite the
+names of refs as specified by `GIT_NAMESPACE`. git-upload-pack and
+git-receive-pack will ignore all references outside the specified
+namespace.
+
+The smart HTTP server, linkgit:git-http-backend[1], will pass
+GIT_NAMESPACE through to the backend programs; see
+linkgit:git-http-backend[1] for sample configuration to expose
+repository namespaces as repositories.
+
+For a simple local test, you can use linkgit:git-remote-ext[1]:
+
+----------
+git clone ext::'git --namespace=foo %s /tmp/prefixed.git'
+----------
+
+include::transfer-data-leaks.adoc[]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitpacking.adoc b/gitpacking.adoc
new file mode 100644
index 0000000..a56596e
--- /dev/null
+++ b/gitpacking.adoc
@@ -0,0 +1,195 @@
+gitpacking(7)
+=============
+
+NAME
+----
+gitpacking - Advanced concepts related to packing in Git
+
+SYNOPSIS
+--------
+gitpacking
+
+DESCRIPTION
+-----------
+
+This document aims to describe some advanced concepts related to packing
+in Git.
+
+Many concepts are currently described scattered between manual pages of
+various Git commands, including linkgit:git-pack-objects[1],
+linkgit:git-repack[1], and others, as well as linkgit:gitformat-pack[5],
+and parts of the `Documentation/technical` tree.
+
+There are many aspects of packing in Git that are not covered in this
+document that instead live in the aforementioned areas. Over time, those
+scattered bits may coalesce into this document.
+
+== Pseudo-merge bitmaps
+
+NOTE: Pseudo-merge bitmaps are considered an experimental feature, so
+the configuration and many of the ideas are subject to change.
+
+=== Background
+
+Reachability bitmaps are most efficient when we have on-disk stored
+bitmaps for one or more of the starting points of a traversal. For this
+reason, Git prefers storing bitmaps for commits at the tips of refs,
+because traversals tend to start with those points.
+
+But if you have a large number of refs, it's not feasible to store a
+bitmap for _every_ ref tip. It takes up space, and just OR-ing all of
+those bitmaps together is expensive.
+
+One way we can deal with that is to create bitmaps that represent
+_groups_ of refs. When a traversal asks about the entire group, then we
+can use this single bitmap instead of considering each ref individually.
+Because these bitmaps represent the set of objects which would be
+reachable in a hypothetical merge of all of the commits, we call them
+pseudo-merge bitmaps.
+
+=== Overview
+
+A "pseudo-merge bitmap" is used to refer to a pair of bitmaps, as
+follows:
+
+Commit bitmap::
+
+ A bitmap whose set bits describe the set of commits included in the
+ pseudo-merge's "merge" bitmap (as below).
+
+Merge bitmap::
+
+ A bitmap whose set bits describe the reachability closure over the set
+ of commits in the pseudo-merge's "commits" bitmap (as above). An
+ identical bitmap would be generated for an octopus merge with the same
+ set of parents as described in the commits bitmap.
+
+Pseudo-merge bitmaps can accelerate bitmap traversals when all commits
+for a given pseudo-merge are listed on either side of the traversal,
+either directly (by explicitly asking for them as part of the `HAVES`
+or `WANTS`) or indirectly (by encountering them during a fill-in
+traversal).
+
+=== Use-cases
+
+For example, suppose there exists a pseudo-merge bitmap with a large
+number of commits, all of which are listed in the `WANTS` section of
+some bitmap traversal query. When pseudo-merge bitmaps are enabled, the
+bitmap machinery can quickly determine there is a pseudo-merge which
+satisfies some subset of the wanted objects on either side of the query.
+Then, we can inflate the EWAH-compressed bitmap, and `OR` it in to the
+resulting bitmap. By contrast, without pseudo-merge bitmaps, we would
+have to repeat the decompression and `OR`-ing step over a potentially
+large number of individual bitmaps, which can take proportionally more
+time.
+
+Another benefit of pseudo-merges arises when there is some combination
+of (a) a large number of references, with (b) poor bitmap coverage, and
+(c) deep, nested trees, making fill-in traversal relatively expensive.
+For example, suppose that there are a large enough number of tags where
+bitmapping each of the tags individually is infeasible. Without
+pseudo-merge bitmaps, computing the result of, say, `git rev-list
+--use-bitmap-index --count --objects --tags` would likely require a
+large amount of fill-in traversal. But when a large quantity of those
+tags are stored together in a pseudo-merge bitmap, the bitmap machinery
+can take advantage of the fact that we only care about the union of
+objects reachable from all of those tags, and answer the query much
+faster.
+
+=== Configuration
+
+Reference tips are grouped into different pseudo-merge groups according
+to two criteria. A reference name matches one or more of the defined
+pseudo-merge patterns, and optionally one or more capture groups within
+that pattern which further partition the group.
+
+Within a group, commits may be considered "stable", or "unstable"
+depending on their age. These are adjusted by setting the
+`bitmapPseudoMerge.<name>.stableThreshold` and
+`bitmapPseudoMerge.<name>.threshold` configuration values, respectively.
+
+All stable commits are grouped into pseudo-merges of equal size
+(`bitmapPseudoMerge.<name>.stableSize`). If the `stableSize`
+configuration is set to, say, 100, then the first 100 commits (ordered
+by committer date) which are older than the `stableThreshold` value will
+form one group, the next 100 commits will form another group, and so on.
+
+Among unstable commits, the pseudo-merge machinery will attempt to
+combine older commits into large groups as opposed to newer commits
+which will appear in smaller groups. This is based on the heuristic that
+references whose tip commit is older are less likely to be modified to
+point at a different commit than a reference whose tip commit is newer.
+
+The size of groups is determined by a power-law decay function, and the
+decay parameter roughly corresponds to "k" in `f(n) = C*n^(-k/100)`,
+where `f(n)` describes the size of the `n`-th pseudo-merge group. The
+sample rate controls what percentage of eligible commits are considered
+as candidates. The threshold parameter indicates the minimum age (so as
+to avoid including too-recent commits in a pseudo-merge group, making it
+less likely to be valid). The "maxMerges" parameter sets an upper-bound
+on the number of pseudo-merge commits an individual group
+
+The "stable"-related parameters control "stable" pseudo-merge groups,
+comprised of a fixed number of commits which are older than the
+configured "stable threshold" value and may be grouped together in
+chunks of "stableSize" in order of age.
+
+The exact configuration for pseudo-merges is as follows:
+
+include::config/bitmap-pseudo-merge.adoc[]
+
+=== Examples
+
+Suppose that you have a repository with a large number of references,
+and you want a bare-bones configuration of pseudo-merge bitmaps that
+will enhance bitmap coverage of the `refs/` namespace. You may start
+with a configuration like so:
+
+----
+[bitmapPseudoMerge "all"]
+ pattern = "refs/"
+ threshold = now
+ stableThreshold = never
+ sampleRate = 100
+ maxMerges = 64
+----
+
+This will create pseudo-merge bitmaps for all references, regardless of
+their age, and group them into 64 pseudo-merge commits.
+
+If you wanted to separate tags from branches when generating
+pseudo-merge commits, you would instead define the pattern with a
+capture group, like so:
+
+----
+[bitmapPseudoMerge "all"]
+ pattern = "refs/(heads/tags)/"
+----
+
+Suppose instead that you are working in a fork-network repository, with
+each fork specified by some numeric ID, and whose refs reside in
+`refs/virtual/NNN/` (where `NNN` is the numeric ID corresponding to some
+fork) in the network. In this instance, you may instead write something
+like:
+
+----
+[bitmapPseudoMerge "all"]
+ pattern = "refs/virtual/([0-9]+)/(heads|tags)/"
+ threshold = now
+ stableThreshold = never
+ sampleRate = 100
+ maxMerges = 64
+----
+
+Which would generate pseudo-merge group identifiers like "1234-heads",
+and "5678-tags" (for branches in fork "1234", and tags in remote "5678",
+respectively).
+
+SEE ALSO
+--------
+linkgit:git-pack-objects[1]
+linkgit:git-repack[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitprotocol-capabilities.adoc b/gitprotocol-capabilities.adoc
new file mode 100644
index 0000000..2cf7735
--- /dev/null
+++ b/gitprotocol-capabilities.adoc
@@ -0,0 +1,396 @@
+gitprotocol-capabilities(5)
+===========================
+
+NAME
+----
+gitprotocol-capabilities - Protocol v0 and v1 capabilities
+
+SYNOPSIS
+--------
+[verse]
+<over-the-wire-protocol>
+
+DESCRIPTION
+-----------
+
+NOTE: this document describes capabilities for versions 0 and 1 of the pack
+protocol. For version 2, please refer to the linkgit:gitprotocol-v2[5]
+doc.
+
+Servers SHOULD support all capabilities defined in this document.
+
+On the very first line of the initial server response of either
+receive-pack and upload-pack the first reference is followed by
+a NUL byte and then a list of space delimited server capabilities.
+These allow the server to declare what it can and cannot support
+to the client.
+
+Client will then send a space separated list of capabilities it wants
+to be in effect. The client MUST NOT ask for capabilities the server
+did not say it supports.
+
+Server MUST diagnose and abort if capabilities it does not understand
+were sent. Server MUST NOT ignore capabilities that client requested
+and server advertised. As a consequence of these rules, server MUST
+NOT advertise capabilities it does not understand.
+
+The 'atomic', 'report-status', 'report-status-v2', 'delete-refs', 'quiet',
+and 'push-cert' capabilities are sent and recognized by the receive-pack
+(push to server) process.
+
+The 'ofs-delta' and 'side-band-64k' capabilities are sent and recognized
+by both upload-pack and receive-pack protocols. The 'agent' and 'session-id'
+capabilities may optionally be sent in both protocols.
+
+All other capabilities are only recognized by the upload-pack (fetch
+from server) process.
+
+multi_ack
+---------
+
+The 'multi_ack' capability allows the server to return "ACK obj-id
+continue" as soon as it finds a commit that it can use as a common
+base, between the client's wants and the client's have set.
+
+By sending this early, the server can potentially head off the client
+from walking any further down that particular branch of the client's
+repository history. The client may still need to walk down other
+branches, sending have lines for those, until the server has a
+complete cut across the DAG, or the client has said "done".
+
+Without multi_ack, a client sends have lines in --date-order until
+the server has found a common base. That means the client will send
+have lines that are already known by the server to be common, because
+they overlap in time with another branch on which the server hasn't found
+a common base yet.
+
+For example suppose the client has commits in caps that the server
+doesn't and the server has commits in lower case that the client
+doesn't, as in the following diagram:
+
+ +---- u ---------------------- x
+ / +----- y
+ / /
+ a -- b -- c -- d -- E -- F
+ \
+ +--- Q -- R -- S
+
+If the client wants x,y and starts out by saying have F,S, the server
+doesn't know what F,S is. Eventually the client says "have d" and
+the server sends "ACK d continue" to let the client know to stop
+walking down that line (so don't send c-b-a), but it's not done yet,
+it needs a base for x. The client keeps going with S-R-Q, until a
+gets reached, at which point the server has a clear base and it all
+ends.
+
+Without multi_ack the client would have sent that c-b-a chain anyway,
+interleaved with S-R-Q.
+
+multi_ack_detailed
+------------------
+This is an extension of multi_ack that permits the client to better
+understand the server's in-memory state. See linkgit:gitprotocol-pack[5],
+section "Packfile Negotiation" for more information.
+
+no-done
+-------
+This capability should only be used with the smart HTTP protocol. If
+multi_ack_detailed and no-done are both present, then the sender is
+free to immediately send a pack following its first "ACK obj-id ready"
+message.
+
+Without no-done in the smart HTTP protocol, the server session would
+end and the client has to make another trip to send "done" before
+the server can send the pack. no-done removes the last round and
+thus slightly reduces latency.
+
+thin-pack
+---------
+
+A thin pack is one with deltas which reference base objects not
+contained within the pack (but are known to exist at the receiving
+end). This can reduce the network traffic significantly, but it
+requires the receiving end to know how to "thicken" these packs by
+adding the missing bases to the pack.
+
+The upload-pack server advertises 'thin-pack' when it can generate
+and send a thin pack. A client requests the 'thin-pack' capability
+when it understands how to "thicken" it, notifying the server that
+it can receive such a pack. A client MUST NOT request the
+'thin-pack' capability if it cannot turn a thin pack into a
+self-contained pack.
+
+Receive-pack, on the other hand, is assumed by default to be able to
+handle thin packs, but can ask the client not to use the feature by
+advertising the 'no-thin' capability. A client MUST NOT send a thin
+pack if the server advertises the 'no-thin' capability.
+
+The reasons for this asymmetry are historical. The receive-pack
+program did not exist until after the invention of thin packs, so
+historically the reference implementation of receive-pack always
+understood thin packs. Adding 'no-thin' later allowed receive-pack
+to disable the feature in a backwards-compatible manner.
+
+
+side-band, side-band-64k
+------------------------
+
+This capability means that the server can send, and the client can understand, multiplexed
+progress reports and error info interleaved with the packfile itself.
+
+These two options are mutually exclusive. A modern client always
+favors 'side-band-64k'.
+
+Either mode indicates that the packfile data will be streamed broken
+up into packets of up to either 1000 bytes in the case of 'side_band',
+or 65520 bytes in the case of 'side_band_64k'. Each packet is made up
+of a leading 4-byte pkt-line length of how much data is in the packet,
+followed by a 1-byte stream code, followed by the actual data.
+
+The stream code can be one of:
+
+ 1 - pack data
+ 2 - progress messages
+ 3 - fatal error message just before stream aborts
+
+The "side-band-64k" capability came about as a way for newer clients
+that can handle much larger packets to request packets that are
+actually crammed nearly full, while maintaining backward compatibility
+for the older clients.
+
+Further, with side-band and its up to 1000-byte messages, it's actually
+999 bytes of payload and 1 byte for the stream code. With side-band-64k,
+same deal, you have up to 65519 bytes of data and 1 byte for the stream
+code.
+
+The client MUST send only one of "side-band" and "side-
+band-64k". The server MUST diagnose it as an error if client requests
+both.
+
+ofs-delta
+---------
+
+The server can send, and the client can understand, PACKv2 with delta referring to
+its base by position in pack rather than by an obj-id. That is, they can
+send/read OBJ_OFS_DELTA (aka type 6) in a packfile.
+
+agent
+-----
+
+The server may optionally send a capability of the form `agent=X` to
+notify the client that the server is running version `X`. The client may
+optionally return its own agent string by responding with an `agent=Y`
+capability (but it MUST NOT do so if the server did not mention the
+agent capability). The `X` and `Y` strings may contain any printable
+ASCII characters except space (i.e., the byte range 32 < x < 127), and
+are typically of the form "package/version" (e.g., "git/1.8.3.1"). The
+agent strings are purely informative for statistics and debugging
+purposes, and MUST NOT be used to programmatically assume the presence
+or absence of particular features.
+
+object-format
+-------------
+
+This capability, which takes a hash algorithm as an argument, indicates
+that the server supports the given hash algorithms. It may be sent
+multiple times; if so, the first one given is the one used in the ref
+advertisement.
+
+When provided by the client, this indicates that it intends to use the
+given hash algorithm to communicate. The algorithm provided must be one
+that the server supports.
+
+If this capability is not provided, it is assumed that the only
+supported algorithm is SHA-1.
+
+symref
+------
+
+This parameterized capability is used to inform the receiver which symbolic ref
+points to which ref; for example, "symref=HEAD:refs/heads/master" tells the
+receiver that HEAD points to master. This capability can be repeated to
+represent multiple symrefs.
+
+Servers SHOULD include this capability for the HEAD symref if it is one of the
+refs being sent.
+
+Clients MAY use the parameters from this capability to select the proper initial
+branch when cloning a repository.
+
+shallow
+-------
+
+This capability adds "deepen", "shallow" and "unshallow" commands to
+the fetch-pack/upload-pack protocol so clients can request shallow
+clones.
+
+deepen-since
+------------
+
+This capability adds "deepen-since" command to fetch-pack/upload-pack
+protocol so the client can request shallow clones that are cut at a
+specific time, instead of depth. Internally it's equivalent of doing
+"rev-list --max-age=<timestamp>" on the server side. "deepen-since"
+cannot be used with "deepen".
+
+deepen-not
+----------
+
+This capability adds "deepen-not" command to fetch-pack/upload-pack
+protocol so the client can request shallow clones that are cut at a
+specific revision, instead of depth. Internally it's equivalent of
+doing "rev-list --not <rev>" on the server side. "deepen-not"
+cannot be used with "deepen", but can be used with "deepen-since".
+
+deepen-relative
+---------------
+
+If this capability is requested by the client, the semantics of
+"deepen" command is changed. The "depth" argument is the depth from
+the current shallow boundary, instead of the depth from remote refs.
+
+no-progress
+-----------
+
+The client was started with "git clone -q" or something similar, and doesn't
+want that side band 2. Basically the client just says "I do not
+wish to receive stream 2 on sideband, so do not send it to me, and if
+you did, I will drop it on the floor anyway". However, the sideband
+channel 3 is still used for error responses.
+
+include-tag
+-----------
+
+The 'include-tag' capability is about sending annotated tags if we are
+sending objects they point to. If we pack an object to the client, and
+a tag object points exactly at that object, we pack the tag object too.
+In general this allows a client to get all new annotated tags when it
+fetches a branch, in a single network connection.
+
+Clients MAY always send include-tag, hardcoding it into a request when
+the server advertises this capability. The decision for a client to
+request include-tag only has to do with the client's desires for tag
+data, whether or not a server had advertised objects in the
+refs/tags/* namespace.
+
+Servers MUST pack the tags if their referent is packed and the client
+has requested include-tags.
+
+Clients MUST be prepared for the case where a server has ignored
+include-tag and has not actually sent tags in the pack. In such
+cases the client SHOULD issue a subsequent fetch to acquire the tags
+that include-tag would have otherwise given the client.
+
+The server SHOULD send include-tag, if it supports it, regardless
+of whether or not there are tags available.
+
+report-status
+-------------
+
+The receive-pack process can receive a 'report-status' capability,
+which tells it that the client wants a report of what happened after
+a packfile upload and reference update. If the pushing client requests
+this capability, after unpacking and updating references the server
+will respond with whether the packfile unpacked successfully and if
+each reference was updated successfully. If any of those were not
+successful, it will send back an error message. See linkgit:gitprotocol-pack[5]
+for example messages.
+
+report-status-v2
+----------------
+
+Capability 'report-status-v2' extends capability 'report-status' by
+adding new "option" directives in order to support reference rewritten by
+the "proc-receive" hook. The "proc-receive" hook may handle a command
+for a pseudo-reference which may create or update a reference with
+different name, new-oid, and old-oid. While the capability
+'report-status' cannot report for such case. See linkgit:gitprotocol-pack[5]
+for details.
+
+delete-refs
+-----------
+
+If the server sends back the 'delete-refs' capability, it means that
+it is capable of accepting a zero-id value as the target
+value of a reference update. It is not sent back by the client, it
+simply informs the client that it can be sent zero-id values
+to delete references.
+
+quiet
+-----
+
+If the receive-pack server advertises the 'quiet' capability, it is
+capable of silencing human-readable progress output which otherwise may
+be shown when processing the received pack. A send-pack client should
+respond with the 'quiet' capability to suppress server-side progress
+reporting if the local progress reporting is also being suppressed
+(e.g., via `push -q`, or if stderr does not go to a tty).
+
+atomic
+------
+
+If the server sends the 'atomic' capability it is capable of accepting
+atomic pushes. If the pushing client requests this capability, the server
+will update the refs in one atomic transaction. Either all refs are
+updated or none.
+
+push-options
+------------
+
+If the server sends the 'push-options' capability it is able to accept
+push options after the update commands have been sent, but before the
+packfile is streamed. If the pushing client requests this capability,
+the server will pass the options to the pre- and post- receive hooks
+that process this push request.
+
+allow-tip-sha1-in-want
+----------------------
+
+If the upload-pack server advertises this capability, fetch-pack may
+send "want" lines with object names that exist at the server but are not
+advertised by upload-pack. For historical reasons, the name of this
+capability contains "sha1". Object names are always given using the
+object format negotiated through the 'object-format' capability.
+
+allow-reachable-sha1-in-want
+----------------------------
+
+If the upload-pack server advertises this capability, fetch-pack may
+send "want" lines with object names that exist at the server but are not
+advertised by upload-pack. For historical reasons, the name of this
+capability contains "sha1". Object names are always given using the
+object format negotiated through the 'object-format' capability.
+
+push-cert=<nonce>
+-----------------
+
+The receive-pack server that advertises this capability is willing
+to accept a signed push certificate, and asks the <nonce> to be
+included in the push certificate. A send-pack client MUST NOT
+send a push-cert packet unless the receive-pack server advertises
+this capability.
+
+filter
+------
+
+If the upload-pack server advertises the 'filter' capability,
+fetch-pack may send "filter" commands to request a partial clone
+or partial fetch and request that the server omit various objects
+from the packfile.
+
+session-id=<session-id>
+-----------------------
+
+The server may advertise a session ID that can be used to identify this process
+across multiple requests. The client may advertise its own session ID back to
+the server as well.
+
+Session IDs should be unique to a given process. They must fit within a
+packet-line, and must not contain non-printable or whitespace characters. The
+current implementation uses trace2 session IDs (see
+link:technical/api-trace2.html[api-trace2] for details), but this may change
+and users of the session ID should not rely on this fact.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitprotocol-common.adoc b/gitprotocol-common.adoc
new file mode 100644
index 0000000..cdc9d6e
--- /dev/null
+++ b/gitprotocol-common.adoc
@@ -0,0 +1,118 @@
+gitprotocol-common(5)
+=====================
+
+NAME
+----
+gitprotocol-common - Things common to various protocols
+
+SYNOPSIS
+--------
+[verse]
+<over-the-wire-protocol>
+
+DESCRIPTION
+-----------
+
+This document defines things common to various over-the-wire
+protocols and file formats used in Git.
+
+ABNF Notation
+-------------
+
+ABNF notation as described by RFC 5234 is used within the protocol documents,
+except the following replacement core rules are used:
+----
+ HEXDIG = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
+----
+
+We also define the following common rules:
+----
+ NUL = %x00
+ zero-id = 40*"0"
+ obj-id = 40*(HEXDIGIT)
+
+ refname = "HEAD"
+ refname /= "refs/" <see discussion below>
+----
+
+A refname is a hierarchical octet string beginning with "refs/" and
+not violating the 'git-check-ref-format' command's validation rules.
+More specifically, they:
+
+. They can include slash `/` for hierarchical (directory)
+ grouping, but no slash-separated component can begin with a
+ dot `.`.
+
+. They must contain at least one `/`. This enforces the presence of a
+ category like `heads/`, `tags/` etc. but the actual names are not
+ restricted.
+
+. They cannot have two consecutive dots `..` anywhere.
+
+. They cannot have ASCII control characters (i.e. bytes whose
+ values are lower than \040, or \177 `DEL`), space, tilde `~`,
+ caret `^`, colon `:`, question-mark `?`, asterisk `*`,
+ or open bracket `[` anywhere.
+
+. They cannot end with a slash `/` or a dot `.`.
+
+. They cannot end with the sequence `.lock`.
+
+. They cannot contain a sequence `@{`.
+
+. They cannot contain a `\\`.
+
+
+pkt-line Format
+---------------
+
+Much (but not all) of the payload is described around pkt-lines.
+
+A pkt-line is a variable length binary string. The first four bytes
+of the line, the pkt-len, indicates the total length of the line,
+in hexadecimal. The pkt-len includes the 4 bytes used to contain
+the length's hexadecimal representation.
+
+A pkt-line MAY contain binary data, so implementors MUST ensure
+pkt-line parsing/formatting routines are 8-bit clean.
+
+A non-binary line SHOULD BE terminated by an LF, which if present
+MUST be included in the total length. Receivers MUST treat pkt-lines
+with non-binary data the same whether or not they contain the trailing
+LF (stripping the LF if present, and not complaining when it is
+missing).
+
+The maximum length of a pkt-line's data component is 65516 bytes.
+Implementations MUST NOT send pkt-line whose length exceeds 65520
+(65516 bytes of payload + 4 bytes of length data).
+
+Implementations SHOULD NOT send an empty pkt-line ("0004").
+
+A pkt-line with a length field of 0 ("0000"), called a flush-pkt,
+is a special case and MUST be handled differently than an empty
+pkt-line ("0004").
+
+----
+ pkt-line = data-pkt / flush-pkt
+
+ data-pkt = pkt-len pkt-payload
+ pkt-len = 4*(HEXDIG)
+ pkt-payload = (pkt-len - 4)*(OCTET)
+
+ flush-pkt = "0000"
+----
+
+Examples (as C-style strings):
+
+----
+ pkt-line actual value
+ ---------------------------------
+ "0006a\n" "a\n"
+ "0005a" "a"
+ "000bfoobar\n" "foobar\n"
+ "0004" ""
+----
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitprotocol-http.adoc b/gitprotocol-http.adoc
new file mode 100644
index 0000000..ec40a55
--- /dev/null
+++ b/gitprotocol-http.adoc
@@ -0,0 +1,543 @@
+gitprotocol-http(5)
+===================
+
+NAME
+----
+gitprotocol-http - Git HTTP-based protocols
+
+
+SYNOPSIS
+--------
+[verse]
+<over-the-wire-protocol>
+
+
+DESCRIPTION
+-----------
+
+Git supports two HTTP based transfer protocols. A "dumb" protocol
+which requires only a standard HTTP server on the server end of the
+connection, and a "smart" protocol which requires a Git aware CGI
+(or server module). This document describes both protocols.
+
+As a design feature smart clients can automatically upgrade "dumb"
+protocol URLs to smart URLs. This permits all users to have the
+same published URL, and the peers automatically select the most
+efficient transport available to them.
+
+
+URL Format
+----------
+
+URLs for Git repositories accessed by HTTP use the standard HTTP
+URL syntax documented by RFC 1738, so they are of the form:
+
+ http://<host>:<port>/<path>?<searchpart>
+
+Within this documentation the placeholder `$GIT_URL` will stand for
+the http:// repository URL entered by the end-user.
+
+Servers SHOULD handle all requests to locations matching `$GIT_URL`, as
+both the "smart" and "dumb" HTTP protocols used by Git operate
+by appending additional path components onto the end of the user
+supplied `$GIT_URL` string.
+
+An example of a dumb client requesting a loose object:
+
+ $GIT_URL: http://example.com:8080/git/repo.git
+ URL request: http://example.com:8080/git/repo.git/objects/d0/49f6c27a2244e12041955e262a404c7faba355
+
+An example of a smart request to a catch-all gateway:
+
+ $GIT_URL: http://example.com/daemon.cgi?svc=git&q=
+ URL request: http://example.com/daemon.cgi?svc=git&q=/info/refs&service=git-receive-pack
+
+An example of a request to a submodule:
+
+ $GIT_URL: http://example.com/git/repo.git/path/submodule.git
+ URL request: http://example.com/git/repo.git/path/submodule.git/info/refs
+
+Clients MUST strip a trailing `/`, if present, from the user supplied
+`$GIT_URL` string to prevent empty path tokens (`//`) from appearing
+in any URL sent to a server. Compatible clients MUST expand
+`$GIT_URL/info/refs` as `foo/info/refs` and not `foo//info/refs`.
+
+
+Authentication
+--------------
+
+Standard HTTP authentication is used if authentication is required
+to access a repository, and MAY be configured and enforced by the
+HTTP server software.
+
+Because Git repositories are accessed by standard path components
+server administrators MAY use directory based permissions within
+their HTTP server to control repository access.
+
+Clients SHOULD support Basic authentication as described by RFC 2617.
+Servers SHOULD support Basic authentication by relying upon the
+HTTP server placed in front of the Git server software.
+
+Servers SHOULD NOT require HTTP cookies for the purposes of
+authentication or access control.
+
+Clients and servers MAY support other common forms of HTTP based
+authentication, such as Digest authentication.
+
+
+SSL
+---
+
+Clients and servers SHOULD support SSL, particularly to protect
+passwords when relying on Basic HTTP authentication.
+
+
+Session State
+-------------
+
+The Git over HTTP protocol (much like HTTP itself) is stateless
+from the perspective of the HTTP server side. All state MUST be
+retained and managed by the client process. This permits simple
+round-robin load-balancing on the server side, without needing to
+worry about state management.
+
+Clients MUST NOT require state management on the server side in
+order to function correctly.
+
+Servers MUST NOT require HTTP cookies in order to function correctly.
+Clients MAY store and forward HTTP cookies during request processing
+as described by RFC 2616 (HTTP/1.1). Servers SHOULD ignore any
+cookies sent by a client.
+
+
+General Request Processing
+--------------------------
+
+Except where noted, all standard HTTP behavior SHOULD be assumed
+by both client and server. This includes (but is not necessarily
+limited to):
+
+If there is no repository at `$GIT_URL`, or the resource pointed to by a
+location matching `$GIT_URL` does not exist, the server MUST NOT respond
+with `200 OK` response. A server SHOULD respond with
+`404 Not Found`, `410 Gone`, or any other suitable HTTP status code
+which does not imply the resource exists as requested.
+
+If there is a repository at `$GIT_URL`, but access is not currently
+permitted, the server MUST respond with the `403 Forbidden` HTTP
+status code.
+
+Servers SHOULD support both HTTP 1.0 and HTTP 1.1.
+Servers SHOULD support chunked encoding for both request and response
+bodies.
+
+Clients SHOULD support both HTTP 1.0 and HTTP 1.1.
+Clients SHOULD support chunked encoding for both request and response
+bodies.
+
+Servers MAY return ETag and/or Last-Modified headers.
+
+Clients MAY revalidate cached entities by including If-Modified-Since
+and/or If-None-Match request headers.
+
+Servers MAY return `304 Not Modified` if the relevant headers appear
+in the request and the entity has not changed. Clients MUST treat
+`304 Not Modified` identical to `200 OK` by reusing the cached entity.
+
+Clients MAY reuse a cached entity without revalidation if the
+Cache-Control and/or Expires header permits caching. Clients and
+servers MUST follow RFC 2616 for cache controls.
+
+
+Discovering References
+----------------------
+
+All HTTP clients MUST begin either a fetch or a push exchange by
+discovering the references available on the remote repository.
+
+Dumb Clients
+~~~~~~~~~~~~
+
+HTTP clients that only support the "dumb" protocol MUST discover
+references by making a request for the special info/refs file of
+the repository.
+
+Dumb HTTP clients MUST make a `GET` request to `$GIT_URL/info/refs`,
+without any search/query parameters.
+
+ C: GET $GIT_URL/info/refs HTTP/1.0
+
+ S: 200 OK
+ S:
+ S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint
+ S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
+ S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0
+ S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}
+
+The Content-Type of the returned info/refs entity SHOULD be
+`text/plain; charset=utf-8`, but MAY be any content type.
+Clients MUST NOT attempt to validate the returned Content-Type.
+Dumb servers MUST NOT return a return type starting with
+`application/x-git-`.
+
+Cache-Control headers MAY be returned to disable caching of the
+returned entity.
+
+When examining the response clients SHOULD only examine the HTTP
+status code. Valid responses are `200 OK`, or `304 Not Modified`.
+
+The returned content is a UNIX formatted text file describing
+each ref and its known value. The file SHOULD be sorted by name
+according to the C locale ordering. The file SHOULD NOT include
+the default ref named `HEAD`.
+
+ info_refs = *( ref_record )
+ ref_record = any_ref / peeled_ref
+
+ any_ref = obj-id HTAB refname LF
+ peeled_ref = obj-id HTAB refname LF
+ obj-id HTAB refname "^{}" LF
+
+Smart Clients
+~~~~~~~~~~~~~
+
+HTTP clients that support the "smart" protocol (or both the
+"smart" and "dumb" protocols) MUST discover references by making
+a parameterized request for the info/refs file of the repository.
+
+The request MUST contain exactly one query parameter,
+`service=$servicename`, where `$servicename` MUST be the service
+name the client wishes to contact to complete the operation.
+The request MUST NOT contain additional query parameters.
+
+ C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0
+
+dumb server reply:
+
+ S: 200 OK
+ S:
+ S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint
+ S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
+ S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0
+ S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}
+
+smart server reply:
+
+ S: 200 OK
+ S: Content-Type: application/x-git-upload-pack-advertisement
+ S: Cache-Control: no-cache
+ S:
+ S: 001e# service=git-upload-pack\n
+ S: 0000
+ S: 004895dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint\0multi_ack\n
+ S: 003fd049f6c27a2244e12041955e262a404c7faba355 refs/heads/master\n
+ S: 003c2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0\n
+ S: 003fa3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}\n
+ S: 0000
+
+The client may send Extra Parameters (see
+linkgit:gitprotocol-pack[5]) as a colon-separated string
+in the Git-Protocol HTTP header.
+
+Uses the `--http-backend-info-refs` option to
+linkgit:git-upload-pack[1].
+
+Dumb Server Response
+^^^^^^^^^^^^^^^^^^^^
+Dumb servers MUST respond with the dumb server reply format.
+
+See the prior section under dumb clients for a more detailed
+description of the dumb server response.
+
+Smart Server Response
+^^^^^^^^^^^^^^^^^^^^^
+If the server does not recognize the requested service name, or the
+requested service name has been disabled by the server administrator,
+the server MUST respond with the `403 Forbidden` HTTP status code.
+
+Otherwise, smart servers MUST respond with the smart server reply
+format for the requested service name.
+
+Cache-Control headers SHOULD be used to disable caching of the
+returned entity.
+
+The Content-Type MUST be `application/x-$servicename-advertisement`.
+Clients SHOULD fall back to the dumb protocol if another content
+type is returned. When falling back to the dumb protocol clients
+SHOULD NOT make an additional request to `$GIT_URL/info/refs`, but
+instead SHOULD use the response already in hand. Clients MUST NOT
+continue if they do not support the dumb protocol.
+
+Clients MUST validate the status code is either `200 OK` or
+`304 Not Modified`.
+
+Clients MUST validate the first five bytes of the response entity
+matches the regex `^[0-9a-f]{4}#`. If this test fails, clients
+MUST NOT continue.
+
+Clients MUST parse the entire response as a sequence of pkt-line
+records.
+
+Clients MUST verify the first pkt-line is `# service=$servicename`.
+Servers MUST set $servicename to be the request parameter value.
+Servers SHOULD include an LF at the end of this line.
+Clients MUST ignore an LF at the end of the line.
+
+Servers MUST terminate the response with the magic `0000` end
+pkt-line marker.
+
+The returned response is a pkt-line stream describing each ref and
+its known value. The stream SHOULD be sorted by name according to
+the C locale ordering. The stream SHOULD include the default ref
+named `HEAD` as the first ref. The stream MUST include capability
+declarations behind a NUL on the first ref.
+
+The returned response contains "version 1" if "version=1" was sent as an
+Extra Parameter.
+
+ smart_reply = PKT-LINE("# service=$servicename" LF)
+ "0000"
+ *1("version 1")
+ ref_list
+ "0000"
+ ref_list = empty_list / non_empty_list
+
+ empty_list = PKT-LINE(zero-id SP "capabilities^{}" NUL cap-list LF)
+
+ non_empty_list = PKT-LINE(obj-id SP name NUL cap_list LF)
+ *ref_record
+
+ cap-list = capability *(SP capability)
+ capability = 1*(LC_ALPHA / DIGIT / "-" / "_")
+ LC_ALPHA = %x61-7A
+
+ ref_record = any_ref / peeled_ref
+ any_ref = PKT-LINE(obj-id SP name LF)
+ peeled_ref = PKT-LINE(obj-id SP name LF)
+ PKT-LINE(obj-id SP name "^{}" LF
+
+
+Smart Service git-upload-pack
+------------------------------
+This service reads from the repository pointed to by `$GIT_URL`.
+
+Clients MUST first perform ref discovery with
+`$GIT_URL/info/refs?service=git-upload-pack`.
+
+ C: POST $GIT_URL/git-upload-pack HTTP/1.0
+ C: Content-Type: application/x-git-upload-pack-request
+ C:
+ C: 0032want 0a53e9ddeaddad63ad106860237bbf53411d11a7\n
+ C: 0032have 441b40d833fdfa93eb2908e52742248faf0ee993\n
+ C: 0000
+
+ S: 200 OK
+ S: Content-Type: application/x-git-upload-pack-result
+ S: Cache-Control: no-cache
+ S:
+ S: ....ACK %s, continue
+ S: ....NAK
+
+Clients MUST NOT reuse or revalidate a cached response.
+Servers MUST include sufficient Cache-Control headers
+to prevent caching of the response.
+
+Servers SHOULD support all capabilities defined here.
+
+Clients MUST send at least one "want" command in the request body.
+Clients MUST NOT reference an id in a "want" command which did not
+appear in the response obtained through ref discovery unless the
+server advertises capability `allow-tip-sha1-in-want` or
+`allow-reachable-sha1-in-want`.
+
+ compute_request = want_list
+ have_list
+ request_end
+ request_end = "0000" / "done"
+
+ want_list = PKT-LINE(want SP cap_list LF)
+ *(want_pkt)
+ want_pkt = PKT-LINE(want LF)
+ want = "want" SP id
+ cap_list = capability *(SP capability)
+
+ have_list = *PKT-LINE("have" SP id LF)
+
+TODO: Document this further.
+
+The Negotiation Algorithm
+~~~~~~~~~~~~~~~~~~~~~~~~~
+The computation to select the minimal pack proceeds as follows
+(C = client, S = server):
+
+'init step:'
+
+C: Use ref discovery to obtain the advertised refs.
+
+C: Place any object seen into set `advertised`.
+
+C: Build an empty set, `common`, to hold the objects that are later
+ determined to be on both ends.
+
+C: Build a set, `want`, of the objects from `advertised` that the client
+ wants to fetch, based on what it saw during ref discovery.
+
+C: Start a queue, `c_pending`, ordered by commit time (popping newest
+ first). Add all client refs. When a commit is popped from
+ the queue its parents SHOULD be automatically inserted back.
+ Commits MUST only enter the queue once.
+
+'one compute step:'
+
+C: Send one `$GIT_URL/git-upload-pack` request:
+
+ C: 0032want <want-#1>...............................
+ C: 0032want <want-#2>...............................
+ ....
+ C: 0032have <common-#1>.............................
+ C: 0032have <common-#2>.............................
+ ....
+ C: 0032have <have-#1>...............................
+ C: 0032have <have-#2>...............................
+ ....
+ C: 0000
+
+The stream is organized into "commands", with each command
+appearing by itself in a pkt-line. Within a command line,
+the text leading up to the first space is the command name,
+and the remainder of the line to the first LF is the value.
+Command lines are terminated with an LF as the last byte of
+the pkt-line value.
+
+Commands MUST appear in the following order, if they appear
+at all in the request stream:
+
+* "want"
+* "have"
+
+The stream is terminated by a pkt-line flush (`0000`).
+
+A single "want" or "have" command MUST have one hex formatted
+object name as its value. Multiple object names MUST be sent by sending
+multiple commands. Object names MUST be given using the object format
+negotiated through the `object-format` capability (default SHA-1).
+
+The `have` list is created by popping the first 32 commits
+from `c_pending`. Fewer can be supplied if `c_pending` empties.
+
+If the client has sent 256 "have" commits and has not yet
+received one of those back from `s_common`, or the client has
+emptied `c_pending` it SHOULD include a "done" command to let
+the server know it won't proceed:
+
+ C: 0009done
+
+S: Parse the git-upload-pack request:
+
+Verify all objects in `want` are directly reachable from refs.
+
+The server MAY walk backwards through history or through
+the reflog to permit slightly stale requests.
+
+If no "want" objects are received, send an error:
+TODO: Define error if no "want" lines are requested.
+
+If any "want" object is not reachable, send an error:
+TODO: Define error if an invalid "want" is requested.
+
+Create an empty list, `s_common`.
+
+If "have" was sent:
+
+Loop through the objects in the order supplied by the client.
+
+For each object, if the server has the object reachable from
+a ref, add it to `s_common`. If a commit is added to `s_common`,
+do not add any ancestors, even if they also appear in `have`.
+
+S: Send the git-upload-pack response:
+
+If the server has found a closed set of objects to pack or the
+request ends with "done", it replies with the pack.
+TODO: Document the pack based response
+
+ S: PACK...
+
+The returned stream is the side-band-64k protocol supported
+by the git-upload-pack service, and the pack is embedded into
+stream 1. Progress messages from the server side MAY appear
+in stream 2.
+
+Here a "closed set of objects" is defined to have at least
+one path from every "want" to at least one "common" object.
+
+If the server needs more information, it replies with a
+status continue response:
+TODO: Document the non-pack response
+
+C: Parse the upload-pack response:
+ TODO: Document parsing response
+
+'Do another compute step.'
+
+
+Smart Service git-receive-pack
+------------------------------
+This service reads from the repository pointed to by `$GIT_URL`.
+
+Clients MUST first perform ref discovery with
+`$GIT_URL/info/refs?service=git-receive-pack`.
+
+ C: POST $GIT_URL/git-receive-pack HTTP/1.0
+ C: Content-Type: application/x-git-receive-pack-request
+ C:
+ C: ....0a53e9ddeaddad63ad106860237bbf53411d11a7 441b40d833fdfa93eb2908e52742248faf0ee993 refs/heads/maint\0 report-status
+ C: 0000
+ C: PACK....
+
+ S: 200 OK
+ S: Content-Type: application/x-git-receive-pack-result
+ S: Cache-Control: no-cache
+ S:
+ S: ....
+
+Clients MUST NOT reuse or revalidate a cached response.
+Servers MUST include sufficient Cache-Control headers
+to prevent caching of the response.
+
+Servers SHOULD support all capabilities defined here.
+
+Clients MUST send at least one command in the request body.
+Within the command portion of the request body clients SHOULD send
+the id obtained through ref discovery as old_id.
+
+ update_request = command_list
+ "PACK" <binary-data>
+
+ command_list = PKT-LINE(command NUL cap_list LF)
+ *(command_pkt)
+ command_pkt = PKT-LINE(command LF)
+ cap_list = *(SP capability) SP
+
+ command = create / delete / update
+ create = zero-id SP new_id SP name
+ delete = old_id SP zero-id SP name
+ update = old_id SP new_id SP name
+
+TODO: Document this further.
+
+REFERENCES
+----------
+
+https://www.ietf.org/rfc/rfc1738.txt[RFC 1738: Uniform Resource Locators (URL)]
+https://www.ietf.org/rfc/rfc2616.txt[RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1]
+
+SEE ALSO
+--------
+
+linkgit:gitprotocol-pack[5]
+linkgit:gitprotocol-capabilities[5]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitprotocol-pack.adoc b/gitprotocol-pack.adoc
new file mode 100644
index 0000000..837b691
--- /dev/null
+++ b/gitprotocol-pack.adoc
@@ -0,0 +1,725 @@
+gitprotocol-pack(5)
+===================
+
+NAME
+----
+gitprotocol-pack - How packs are transferred over-the-wire
+
+SYNOPSIS
+--------
+[verse]
+<over-the-wire-protocol>
+
+DESCRIPTION
+-----------
+
+Git supports transferring data in packfiles over the ssh://, git://, http:// and
+file:// transports. There exist two sets of protocols, one for pushing
+data from a client to a server and another for fetching data from a
+server to a client. The three transports (ssh, git, file) use the same
+protocol to transfer data. http is documented in linkgit:gitprotocol-http[5].
+
+The processes invoked in the canonical Git implementation are 'upload-pack'
+on the server side and 'fetch-pack' on the client side for fetching data;
+then 'receive-pack' on the server and 'send-pack' on the client for pushing
+data. The protocol functions to have a server tell a client what is
+currently on the server, then for the two to negotiate the smallest amount
+of data to send in order to fully update one or the other.
+
+pkt-line Format
+---------------
+
+The descriptions below build on the pkt-line format described in
+linkgit:gitprotocol-common[5]. When the grammar indicates `PKT-LINE(...)`, unless
+otherwise noted the usual pkt-line LF rules apply: the sender SHOULD
+include a LF, but the receiver MUST NOT complain if it is not present.
+
+An error packet is a special pkt-line that contains an error string.
+
+----
+ error-line = PKT-LINE("ERR" SP explanation-text)
+----
+
+Throughout the protocol, where `PKT-LINE(...)` is expected, an error packet MAY
+be sent. Once this packet is sent by a client or a server, the data transfer
+process defined in this protocol is terminated.
+
+Transports
+----------
+There are three transports over which the packfile protocol is
+initiated. The Git transport is a simple, unauthenticated server that
+takes the command (almost always 'upload-pack', though Git
+servers can be configured to be globally writable, in which 'receive-
+pack' initiation is also allowed) with which the client wishes to
+communicate and executes it and connects it to the requesting
+process.
+
+In the SSH transport, the client just runs the 'upload-pack'
+or 'receive-pack' process on the server over the SSH protocol and then
+communicates with that invoked process over the SSH connection.
+
+The file:// transport runs the 'upload-pack' or 'receive-pack'
+process locally and communicates with it over a pipe.
+
+Extra Parameters
+----------------
+
+The protocol provides a mechanism in which clients can send additional
+information in its first message to the server. These are called "Extra
+Parameters", and are supported by the Git, SSH, and HTTP protocols.
+
+Each Extra Parameter takes the form of `<key>=<value>` or `<key>`.
+
+Servers that receive any such Extra Parameters MUST ignore all
+unrecognized keys. Currently, the only Extra Parameter recognized is
+"version" with a value of '1' or '2'. See linkgit:gitprotocol-v2[5] for more
+information on protocol version 2.
+
+Git Transport
+-------------
+
+The Git transport starts off by sending the command and repository
+on the wire using the pkt-line format, followed by a NUL byte and a
+hostname parameter, terminated by a NUL byte.
+
+ 0033git-upload-pack /project.git\0host=myserver.com\0
+
+The transport may send Extra Parameters by adding an additional NUL
+byte, and then adding one or more NUL-terminated strings:
+
+ 003egit-upload-pack /project.git\0host=myserver.com\0\0version=1\0
+
+--
+ git-proto-request = request-command SP pathname NUL
+ [ host-parameter NUL ] [ NUL extra-parameters ]
+ request-command = "git-upload-pack" / "git-receive-pack" /
+ "git-upload-archive" ; case sensitive
+ pathname = *( %x01-ff ) ; exclude NUL
+ host-parameter = "host=" hostname [ ":" port ]
+ extra-parameters = 1*extra-parameter
+ extra-parameter = 1*( %x01-ff ) NUL
+--
+
+host-parameter is used for the
+git-daemon name based virtual hosting. See --interpolated-path
+option to git daemon, with the %H/%CH format characters.
+
+Basically what the Git client is doing to connect to an 'upload-pack'
+process on the server side over the Git protocol is this:
+
+ $ echo -e -n \
+ "003agit-upload-pack /schacon/gitbook.git\0host=example.com\0" |
+ nc -v example.com 9418
+
+
+SSH Transport
+-------------
+
+Initiating the upload-pack or receive-pack processes over SSH is
+executing the binary on the server via SSH remote execution.
+It is basically equivalent to running this:
+
+ $ ssh git.example.com "git-upload-pack '/project.git'"
+
+For a server to support Git pushing and pulling for a given user over
+SSH, that user needs to be able to execute one or both of those
+commands via the SSH shell that they are provided on login. On some
+systems, that shell access is limited to only being able to run those
+two commands, or even just one of them.
+
+In an ssh:// format URI, it's absolute in the URI, so the '/' after
+the host name (or port number) is sent as an argument, which is then
+read by the remote git-upload-pack exactly as is, so it's effectively
+an absolute path in the remote filesystem.
+
+ git clone ssh://user@example.com/project.git
+ |
+ v
+ ssh user@example.com "git-upload-pack '/project.git'"
+
+In a "user@host:path" format URI, it's relative to the user's home
+directory, because the Git client will run:
+
+ git clone user@example.com:project.git
+ |
+ v
+ ssh user@example.com "git-upload-pack 'project.git'"
+
+The exception is if a '~' is used, in which case
+we execute it without the leading '/'.
+
+ ssh://user@example.com/~alice/project.git,
+ |
+ v
+ ssh user@example.com "git-upload-pack '~alice/project.git'"
+
+Depending on the value of the `protocol.version` configuration variable,
+Git may attempt to send Extra Parameters as a colon-separated string in
+the GIT_PROTOCOL environment variable. This is done only if
+the `ssh.variant` configuration variable indicates that the ssh command
+supports passing environment variables as an argument.
+
+A few things to remember here:
+
+- The "command name" is spelled with dash (e.g. git-upload-pack), but
+ this can be overridden by the client;
+
+- 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
+what data the server has that the client does not then streams that
+data down to the client in packfile format.
+
+
+Reference Discovery
+-------------------
+
+When the client initially connects the server will immediately respond
+with a version number (if "version=1" is sent as an Extra Parameter),
+and a listing of each reference it has (all branches and tags) along
+with the object name that each reference currently points to.
+
+ $ echo -e -n "0045git-upload-pack /schacon/gitbook.git\0host=example.com\0\0version=1\0" |
+ nc -v example.com 9418
+ 000eversion 1
+ 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
+ 003c525128480b96c89e6418b1e40909bf6c5b2d580f refs/tags/v1.0
+ 003fe92df48743b7bc7d26bcaabfddde0a1e20cae47c refs/tags/v1.0^{}
+ 0000
+
+The returned response is a pkt-line stream describing each ref and
+its current value. The stream MUST be sorted by name according to
+the C locale ordering.
+
+If HEAD is a valid ref, HEAD MUST appear as the first advertised
+ref. If HEAD is not a valid ref, HEAD MUST NOT appear in the
+advertisement list at all, but other refs may still appear.
+
+The stream MUST include capability declarations behind a NUL on the
+first ref. The peeled value of a ref (that is "ref^{}") MUST be
+immediately after the ref itself, if presented. A conforming server
+MUST peel the ref if it's an annotated tag.
+
+----
+ advertised-refs = *1("version 1")
+ (no-refs / list-of-refs)
+ *shallow
+ flush-pkt
+
+ no-refs = PKT-LINE(zero-id SP "capabilities^{}"
+ NUL capability-list)
+
+ list-of-refs = first-ref *other-ref
+ first-ref = PKT-LINE(obj-id SP refname
+ NUL capability-list)
+
+ other-ref = PKT-LINE(other-tip / other-peeled)
+ other-tip = obj-id SP refname
+ other-peeled = obj-id SP refname "^{}"
+
+ shallow = PKT-LINE("shallow" SP obj-id)
+
+ capability-list = capability *(SP capability)
+ capability = 1*(LC_ALPHA / DIGIT / "-" / "_")
+ LC_ALPHA = %x61-7A
+----
+
+Server and client MUST use lowercase for obj-id, both MUST treat obj-id
+as case-insensitive.
+
+See protocol-capabilities.txt for a list of allowed server capabilities
+and descriptions.
+
+Packfile Negotiation
+--------------------
+After reference and capabilities discovery, the client can decide to
+terminate the connection by sending a flush-pkt, telling the server it can
+now gracefully terminate, and disconnect, when it does not need any pack
+data. This can happen with the ls-remote command, and also can happen when
+the client already is up to date.
+
+Otherwise, it enters the negotiation phase, where the client and
+server determine what the minimal packfile necessary for transport is,
+by telling the server what objects it wants, its shallow objects
+(if any), and the maximum commit depth it wants (if any). The client
+will also send a list of the capabilities it wants to be in effect,
+out of what the server said it could do with the first 'want' line.
+
+----
+ upload-request = want-list
+ *shallow-line
+ *1depth-request
+ [filter-request]
+ flush-pkt
+
+ want-list = first-want
+ *additional-want
+
+ shallow-line = PKT-LINE("shallow" SP obj-id)
+
+ depth-request = PKT-LINE("deepen" SP depth) /
+ PKT-LINE("deepen-since" SP timestamp) /
+ PKT-LINE("deepen-not" SP ref)
+
+ first-want = PKT-LINE("want" SP obj-id SP capability-list)
+ additional-want = PKT-LINE("want" SP obj-id)
+
+ depth = 1*DIGIT
+
+ filter-request = PKT-LINE("filter" SP filter-spec)
+----
+
+Clients MUST send all the obj-ids it wants from the reference
+discovery phase as 'want' lines. Clients MUST send at least one
+'want' command in the request body. Clients MUST NOT mention an
+obj-id in a 'want' command which did not appear in the response
+obtained through ref discovery.
+
+The client MUST write all obj-ids which it only has shallow copies
+of (meaning that it does not have the parents of a commit) as
+'shallow' lines so that the server is aware of the limitations of
+the client's history.
+
+The client now sends the maximum commit history depth it wants for
+this transaction, which is the number of commits it wants from the
+tip of the history, if any, as a 'deepen' line. A depth of 0 is the
+same as not making a depth request. The client does not want to receive
+any commits beyond this depth, nor does it want objects needed only to
+complete those commits. Commits whose parents are not received as a
+result are defined as shallow and marked as such in the server. This
+information is sent back to the client in the next step.
+
+The client can optionally request that pack-objects omit various
+objects from the packfile using one of several filtering techniques.
+These are intended for use with partial clone and partial fetch
+operations. An object that does not meet a filter-spec value is
+omitted unless explicitly requested in a 'want' line. See `rev-list`
+for possible filter-spec values.
+
+Once all the 'want's and 'shallow's (and optional 'deepen') are
+transferred, clients MUST send a flush-pkt, to tell the server side
+that it is done sending the list.
+
+Otherwise, if the client sent a positive depth request, the server
+will determine which commits will and will not be shallow and
+send this information to the client. If the client did not request
+a positive depth, this step is skipped.
+
+----
+ shallow-update = *shallow-line
+ *unshallow-line
+ flush-pkt
+
+ shallow-line = PKT-LINE("shallow" SP obj-id)
+
+ unshallow-line = PKT-LINE("unshallow" SP obj-id)
+----
+
+If the client has requested a positive depth, the server will compute
+the set of commits which are no deeper than the desired depth. The set
+of commits starts at the client's wants.
+
+The server writes 'shallow' lines for each
+commit whose parents will not be sent as a result. The server writes
+an 'unshallow' line for each commit which the client has indicated is
+shallow, but is no longer shallow at the currently requested depth
+(that is, its parents will now be sent). The server MUST NOT mark
+as unshallow anything which the client has not indicated was shallow.
+
+Now the client will send a list of the obj-ids it has using 'have'
+lines, so the server can make a packfile that only contains the objects
+that the client needs. In multi_ack mode, the canonical implementation
+will send up to 32 of these at a time, then will send a flush-pkt. The
+canonical implementation will skip ahead and send the next 32 immediately,
+so that there is always a block of 32 "in-flight on the wire" at a time.
+
+----
+ upload-haves = have-list
+ compute-end
+
+ have-list = *have-line
+ have-line = PKT-LINE("have" SP obj-id)
+ compute-end = flush-pkt / PKT-LINE("done")
+----
+
+If the server reads 'have' lines, it then will respond by ACKing any
+of the obj-ids the client said it had that the server also has. The
+server will ACK obj-ids differently depending on which ack mode is
+chosen by the client.
+
+In multi_ack mode:
+
+ * the server will respond with 'ACK obj-id continue' for any common
+ commits.
+
+ * once the server has found an acceptable common base commit and is
+ ready to make a packfile, it will blindly ACK all 'have' obj-ids
+ back to the client.
+
+ * the server will then send a 'NAK' and then wait for another response
+ from the client - either a 'done' or another list of 'have' lines.
+
+In multi_ack_detailed mode:
+
+ * the server will differentiate the ACKs where it is signaling
+ that it is ready to send data with 'ACK obj-id ready' lines, and
+ signals the identified common commits with 'ACK obj-id common' lines.
+
+Without either multi_ack or multi_ack_detailed:
+
+ * upload-pack sends "ACK obj-id" on the first common object it finds.
+ After that it says nothing until the client gives it a "done".
+
+ * upload-pack sends "NAK" on a flush-pkt if no common object
+ has been found yet. If one has been found, and thus an ACK
+ was already sent, it's silent on the flush-pkt.
+
+After the client has gotten enough ACK responses that it can determine
+that the server has enough information to send an efficient packfile
+(in the canonical implementation, this is determined when it has received
+enough ACKs that it can color everything left in the --date-order queue
+as common with the server, or the --date-order queue is empty), or the
+client determines that it wants to give up (in the canonical implementation,
+this is determined when the client sends 256 'have' lines without getting
+any of them ACKed by the server - meaning there is nothing in common and
+the server should just send all of its objects), then the client will send
+a 'done' command. The 'done' command signals to the server that the client
+is ready to receive its packfile data.
+
+However, the 256 limit *only* turns on in the canonical client
+implementation if we have received at least one "ACK %s continue"
+during a prior round. This helps to ensure that at least one common
+ancestor is found before we give up entirely.
+
+Once the 'done' line is read from the client, the server will either
+send a final 'ACK obj-id' or it will send a 'NAK'. 'obj-id' is the object
+name of the last commit determined to be common. The server only sends
+ACK after 'done' if there is at least one common base and multi_ack or
+multi_ack_detailed is enabled. The server always sends NAK after 'done'
+if there is no common base found.
+
+Instead of 'ACK' or 'NAK', the server may send an error message (for
+example, if it does not recognize an object in a 'want' line received
+from the client).
+
+Then the server will start sending its packfile data.
+
+----
+ server-response = *ack_multi ack / nak
+ ack_multi = PKT-LINE("ACK" SP obj-id ack_status)
+ ack_status = "continue" / "common" / "ready"
+ ack = PKT-LINE("ACK" SP obj-id)
+ nak = PKT-LINE("NAK")
+----
+
+A simple clone may look like this (with no 'have' lines):
+
+----
+ C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d multi_ack \
+ side-band-64k ofs-delta\n
+ C: 0032want 7d1665144a3a975c05f1f43902ddaf084e784dbe\n
+ C: 0032want 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a\n
+ C: 0032want 7e47fe2bd8d01d481f44d7af0531bd93d3b21c01\n
+ C: 0032want 74730d410fcb6603ace96f1dc55ea6196122532d\n
+ C: 0000
+ C: 0009done\n
+
+ S: 0008NAK\n
+ S: [PACKFILE]
+----
+
+An incremental update (fetch) response might look like this:
+
+----
+ C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d multi_ack \
+ side-band-64k ofs-delta\n
+ C: 0032want 7d1665144a3a975c05f1f43902ddaf084e784dbe\n
+ C: 0032want 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a\n
+ C: 0000
+ C: 0032have 7e47fe2bd8d01d481f44d7af0531bd93d3b21c01\n
+ C: [30 more have lines]
+ C: 0032have 74730d410fcb6603ace96f1dc55ea6196122532d\n
+ C: 0000
+
+ S: 003aACK 7e47fe2bd8d01d481f44d7af0531bd93d3b21c01 continue\n
+ S: 003aACK 74730d410fcb6603ace96f1dc55ea6196122532d continue\n
+ S: 0008NAK\n
+
+ C: 0009done\n
+
+ S: 0031ACK 74730d410fcb6603ace96f1dc55ea6196122532d\n
+ S: [PACKFILE]
+----
+
+
+Packfile Data
+-------------
+
+Now that the client and server have finished negotiation about what
+the minimal amount of data that needs to be sent to the client is, the server
+will construct and send the required data in packfile format.
+
+See linkgit:gitformat-pack[5] for what the packfile itself actually looks like.
+
+If 'side-band' or 'side-band-64k' capabilities have been specified by
+the client, the server will send the packfile data multiplexed.
+
+Each packet starting with the packet-line length of the amount of data
+that follows, followed by a single byte specifying the sideband the
+following data is coming in on.
+
+In 'side-band' mode, it will send up to 999 data bytes plus 1 control
+code, for a total of up to 1000 bytes in a pkt-line. In 'side-band-64k'
+mode it will send up to 65519 data bytes plus 1 control code, for a
+total of up to 65520 bytes in a pkt-line.
+
+The sideband byte will be a '1', '2' or a '3'. Sideband '1' will contain
+packfile data, sideband '2' will be used for progress information that the
+client will generally print to stderr and sideband '3' is used for error
+information.
+
+If no 'side-band' capability was specified, the server will stream the
+entire packfile without multiplexing.
+
+
+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
+update and then send all the data the server will need for those new
+references to be complete. Once all the data is received and validated,
+the server will then update its references to what the client specified.
+
+Authentication
+--------------
+
+The protocol itself contains no authentication mechanisms. That is to be
+handled by the transport, such as SSH, before the 'receive-pack' process is
+invoked. If 'receive-pack' is configured over the Git transport, those
+repositories will be writable by anyone who can access that port (9418) as
+that transport is unauthenticated.
+
+Reference Discovery
+-------------------
+
+The reference discovery phase is done nearly the same way as it is in the
+fetching protocol. Each reference obj-id and name on the server is sent
+in packet-line format to the client, followed by a flush-pkt. The only
+real difference is that the capability listing is different - the only
+possible values are 'report-status', 'report-status-v2', 'delete-refs',
+'ofs-delta', 'atomic' and 'push-options'.
+
+Reference Update Request and Packfile Transfer
+----------------------------------------------
+
+Once the client knows what references the server is at, it can send a
+list of reference update requests. For each reference on the server
+that it wants to update, it sends a line listing the obj-id currently on
+the server, the obj-id the client would like to update it to and the name
+of the reference.
+
+This list is followed by a flush-pkt.
+
+----
+ update-requests = *shallow ( command-list | push-cert )
+
+ shallow = PKT-LINE("shallow" SP obj-id)
+
+ command-list = PKT-LINE(command NUL capability-list)
+ *PKT-LINE(command)
+ flush-pkt
+
+ command = create / delete / update
+ create = zero-id SP new-id SP name
+ delete = old-id SP zero-id SP name
+ update = old-id SP new-id SP name
+
+ old-id = obj-id
+ new-id = obj-id
+
+ push-cert = PKT-LINE("push-cert" NUL capability-list LF)
+ PKT-LINE("certificate version 0.1" LF)
+ PKT-LINE("pusher" SP ident LF)
+ PKT-LINE("pushee" SP url LF)
+ PKT-LINE("nonce" SP nonce LF)
+ *PKT-LINE("push-option" SP push-option LF)
+ PKT-LINE(LF)
+ *PKT-LINE(command LF)
+ *PKT-LINE(gpg-signature-lines LF)
+ PKT-LINE("push-cert-end" LF)
+
+ push-option = 1*( VCHAR | SP )
+----
+
+If the server has advertised the 'push-options' capability and the client has
+specified 'push-options' as part of the capability list above, the client then
+sends its push options followed by a flush-pkt.
+
+----
+ push-options = *PKT-LINE(push-option) flush-pkt
+----
+
+For backwards compatibility with older Git servers, if the client sends a push
+cert and push options, it MUST send its push options both embedded within the
+push cert and after the push cert. (Note that the push options within the cert
+are prefixed, but the push options after the cert are not.) Both these lists
+MUST be the same, modulo the prefix.
+
+After that the packfile that
+should contain all the objects that the server will need to complete the new
+references will be sent.
+
+----
+ packfile = "PACK" 28*(OCTET)
+----
+
+If the receiving end does not support delete-refs, the sending end MUST
+NOT ask for delete command.
+
+If the receiving end does not support push-cert, the sending end
+MUST NOT send a push-cert command. When a push-cert command is
+sent, command-list MUST NOT be sent; the commands recorded in the
+push certificate is used instead.
+
+The packfile MUST NOT be sent if the only command used is 'delete'.
+
+A packfile MUST be sent if either create or update command is used,
+even if the server already has all the necessary objects. In this
+case the client MUST send an empty packfile. The only time this
+is likely to happen is if the client is creating
+a new branch or a tag that points to an existing obj-id.
+
+The server will receive the packfile, unpack it, then validate each
+reference that is being updated that it hasn't changed while the request
+was being processed (the obj-id is still the same as the old-id), and
+it will run any update hooks to make sure that the update is acceptable.
+If all of that is fine, the server will then update the references.
+
+Push Certificate
+----------------
+
+A push certificate begins with a set of header lines. After the
+header and an empty line, the protocol commands follow, one per
+line. Note that the trailing LF in push-cert PKT-LINEs is _not_
+optional; it must be present.
+
+Currently, the following header fields are defined:
+
+`pusher` ident::
+ Identify the GPG key in "Human Readable Name <email@address>"
+ format.
+
+`pushee` url::
+ The repository URL (anonymized, if the URL contains
+ authentication material) the user who ran `git push`
+ intended to push into.
+
+`nonce` nonce::
+ The 'nonce' string the receiving repository asked the
+ pushing user to include in the certificate, to prevent
+ replay attacks.
+
+The GPG signature lines are a detached signature for the contents
+recorded in the push certificate before the signature block begins.
+The detached signature is used to certify that the commands were
+given by the pusher, who must be the signer.
+
+Report Status
+-------------
+
+After receiving the pack data from the sender, the receiver sends a
+report if 'report-status' or 'report-status-v2' capability is in effect.
+It is a short listing of what happened in that update. It will first
+list the status of the packfile unpacking as either 'unpack ok' or
+'unpack [error]'. Then it will list the status for each of the references
+that it tried to update. Each line is either 'ok [refname]' if the
+update was successful, or 'ng [refname] [error]' if the update was not.
+
+----
+ report-status = unpack-status
+ 1*(command-status)
+ flush-pkt
+
+ unpack-status = PKT-LINE("unpack" SP unpack-result)
+ unpack-result = "ok" / error-msg
+
+ command-status = command-ok / command-fail
+ command-ok = PKT-LINE("ok" SP refname)
+ command-fail = PKT-LINE("ng" SP refname SP error-msg)
+
+ error-msg = 1*(OCTET) ; where not "ok"
+----
+
+The 'report-status-v2' capability extends the protocol by adding new option
+lines in order to support reporting of reference rewritten by the
+'proc-receive' hook. The 'proc-receive' hook may handle a command for a
+pseudo-reference which may create or update one or more references, and each
+reference may have different name, different new-oid, and different old-oid.
+
+----
+ report-status-v2 = unpack-status
+ 1*(command-status-v2)
+ flush-pkt
+
+ unpack-status = PKT-LINE("unpack" SP unpack-result)
+ unpack-result = "ok" / error-msg
+
+ command-status-v2 = command-ok-v2 / command-fail
+ command-ok-v2 = command-ok
+ *option-line
+
+ command-ok = PKT-LINE("ok" SP refname)
+ command-fail = PKT-LINE("ng" SP refname SP error-msg)
+
+ error-msg = 1*(OCTET) ; where not "ok"
+
+ option-line = *1(option-refname)
+ *1(option-old-oid)
+ *1(option-new-oid)
+ *1(option-forced-update)
+
+ option-refname = PKT-LINE("option" SP "refname" SP refname)
+ option-old-oid = PKT-LINE("option" SP "old-oid" SP obj-id)
+ option-new-oid = PKT-LINE("option" SP "new-oid" SP obj-id)
+ option-force = PKT-LINE("option" SP "forced-update")
+
+----
+
+Updates can be unsuccessful for a number of reasons. The reference can have
+changed since the reference discovery phase was originally sent, meaning
+someone pushed in the meantime. The reference being pushed could be a
+non-fast-forward reference and the update hooks or configuration could be
+set to not allow that, etc. Also, some references can be updated while others
+can be rejected.
+
+An example client/server communication might look like this:
+
+----
+ S: 006274730d410fcb6603ace96f1dc55ea6196122532d refs/heads/local\0report-status delete-refs ofs-delta\n
+ S: 003e7d1665144a3a975c05f1f43902ddaf084e784dbe refs/heads/debug\n
+ S: 003f74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/master\n
+ S: 003d74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/team\n
+ S: 0000
+
+ C: 00677d1665144a3a975c05f1f43902ddaf084e784dbe 74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/debug\n
+ C: 006874730d410fcb6603ace96f1dc55ea6196122532d 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a refs/heads/master\n
+ C: 0000
+ C: [PACKDATA]
+
+ S: 000eunpack ok\n
+ S: 0018ok refs/heads/debug\n
+ S: 002ang refs/heads/master non-fast-forward\n
+----
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitprotocol-v2.adoc b/gitprotocol-v2.adoc
new file mode 100644
index 0000000..1652fef
--- /dev/null
+++ b/gitprotocol-v2.adoc
@@ -0,0 +1,786 @@
+gitprotocol-v2(5)
+=================
+
+NAME
+----
+gitprotocol-v2 - Git Wire Protocol, Version 2
+
+SYNOPSIS
+--------
+[verse]
+<over-the-wire-protocol>
+
+DESCRIPTION
+-----------
+
+This document presents a specification for a version 2 of Git's wire
+protocol. Protocol v2 will improve upon v1 in the following ways:
+
+ * Instead of multiple service names, multiple commands will be
+ supported by a single service
+ * Easily extendable as capabilities are moved into their own section
+ of the protocol, no longer being hidden behind a NUL byte and
+ limited by the size of a pkt-line
+ * Separate out other information hidden behind NUL bytes (e.g. agent
+ string as a capability and symrefs can be requested using 'ls-refs')
+ * Reference advertisement will be omitted unless explicitly requested
+ * ls-refs command to explicitly request some refs
+ * Designed with http and stateless-rpc in mind. With clear flush
+ semantics the http remote helper can simply act as a proxy
+
+In protocol v2 communication is command oriented. When first contacting a
+server a list of capabilities will be advertised. Some of these capabilities
+will be commands which a client can request be executed. Once a command
+has completed, a client can reuse the connection and request that other
+commands be executed.
+
+Packet-Line Framing
+-------------------
+
+All communication is done using packet-line framing, just as in v1. See
+linkgit:gitprotocol-pack[5] and linkgit:gitprotocol-common[5] for more information.
+
+In protocol v2 these special packets will have the following semantics:
+
+ * '0000' Flush Packet (flush-pkt) - indicates the end of a message
+ * '0001' Delimiter Packet (delim-pkt) - separates sections of a message
+ * '0002' Response End Packet (response-end-pkt) - indicates the end of a
+ response for stateless connections
+
+Initial Client Request
+----------------------
+
+In general a client can request to speak protocol v2 by sending
+`version=2` through the respective side-channel for the transport being
+used which inevitably sets `GIT_PROTOCOL`. More information can be
+found in linkgit:gitprotocol-pack[5] and linkgit:gitprotocol-http[5], as well as the
+`GIT_PROTOCOL` definition in `git.txt`. In all cases the
+response from the server is the capability advertisement.
+
+Git Transport
+~~~~~~~~~~~~~
+
+When using the git:// transport, you can request to use protocol v2 by
+sending "version=2" as an extra parameter:
+
+ 003egit-upload-pack /project.git\0host=myserver.com\0\0version=2\0
+
+SSH and File Transport
+~~~~~~~~~~~~~~~~~~~~~~
+
+When using either the ssh:// or file:// transport, the GIT_PROTOCOL
+environment variable must be set explicitly to include "version=2".
+The server may need to be configured to allow this environment variable
+to pass.
+
+HTTP Transport
+~~~~~~~~~~~~~~
+
+When using the http:// or https:// transport a client makes a "smart"
+info/refs request as described in linkgit:gitprotocol-http[5] and requests that
+v2 be used by supplying "version=2" in the `Git-Protocol` header.
+
+ C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0
+ C: Git-Protocol: version=2
+
+A v2 server would reply:
+
+ S: 200 OK
+ S: <Some headers>
+ S: ...
+ S:
+ S: 000eversion 2\n
+ S: <capability-advertisement>
+
+Subsequent requests are then made directly to the service
+`$GIT_URL/git-upload-pack`. (This works the same for git-receive-pack).
+
+Uses the `--http-backend-info-refs` option to
+linkgit:git-upload-pack[1].
+
+The server may need to be configured to pass this header's contents via
+the `GIT_PROTOCOL` variable. See the discussion in `git-http-backend.txt`.
+
+Capability Advertisement
+------------------------
+
+A server which decides to communicate (based on a request from a client)
+using protocol version 2, notifies the client by sending a version string
+in its initial response followed by an advertisement of its capabilities.
+Each capability is a key with an optional value. Clients must ignore all
+unknown keys. Semantics of unknown values are left to the definition of
+each key. Some capabilities will describe commands which can be requested
+to be executed by the client.
+
+ capability-advertisement = protocol-version
+ capability-list
+ flush-pkt
+
+ protocol-version = PKT-LINE("version 2" LF)
+ capability-list = *capability
+ capability = PKT-LINE(key[=value] LF)
+
+ key = 1*(ALPHA | DIGIT | "-_")
+ value = 1*(ALPHA | DIGIT | " -_.,?\/{}[]()<>!@#$%^&*+=:;")
+
+Command Request
+---------------
+
+After receiving the capability advertisement, a client can then issue a
+request to select the command it wants with any particular capabilities
+or arguments. There is then an optional section where the client can
+provide any command specific parameters or queries. Only a single
+command can be requested at a time.
+
+ request = empty-request | command-request
+ empty-request = flush-pkt
+ command-request = command
+ capability-list
+ delim-pkt
+ command-args
+ flush-pkt
+ command = PKT-LINE("command=" key LF)
+ command-args = *command-specific-arg
+
+ command-specific-args are packet line framed arguments defined by
+ each individual command.
+
+The server will then check to ensure that the client's request is
+comprised of a valid command as well as valid capabilities which were
+advertised. If the request is valid the server will then execute the
+command. A server MUST wait till it has received the client's entire
+request before issuing a response. The format of the response is
+determined by the command being executed, but in all cases a flush-pkt
+indicates the end of the response.
+
+When a command has finished, and the client has received the entire
+response from the server, a client can either request that another
+command be executed or can terminate the connection. A client may
+optionally send an empty request consisting of just a flush-pkt to
+indicate that no more requests will be made.
+
+Capabilities
+------------
+
+There are two different types of capabilities: normal capabilities,
+which can be used to convey information or alter the behavior of a
+request, and commands, which are the core actions that a client wants to
+perform (fetch, push, etc).
+
+Protocol version 2 is stateless by default. This means that all commands
+must only last a single round and be stateless from the perspective of the
+server side, unless the client has requested a capability indicating that
+state should be maintained by the server. Clients MUST NOT require state
+management on the server side in order to function correctly. This
+permits simple round-robin load-balancing on the server side, without
+needing to worry about state management.
+
+agent
+~~~~~
+
+The server can advertise the `agent` capability with a value `X` (in the
+form `agent=X`) to notify the client that the server is running version
+`X`. The client may optionally send its own agent string by including
+the `agent` capability with a value `Y` (in the form `agent=Y`) in its
+request to the server (but it MUST NOT do so if the server did not
+advertise the agent capability). The `X` and `Y` strings may contain any
+printable ASCII characters except space (i.e., the byte range 32 < x <
+127), and are typically of the form "package/version" (e.g.,
+"git/1.8.3.1"). The agent strings are purely informative for statistics
+and debugging purposes, and MUST NOT be used to programmatically assume
+the presence or absence of particular features.
+
+ls-refs
+~~~~~~~
+
+`ls-refs` is the command used to request a reference advertisement in v2.
+Unlike the current reference advertisement, ls-refs takes in arguments
+which can be used to limit the refs sent from the server.
+
+Additional features not supported in the base command will be advertised
+as the value of the command in the capability advertisement in the form
+of a space separated list of features: "<command>=<feature-1> <feature-2>"
+
+ls-refs takes in the following arguments:
+
+ symrefs
+ In addition to the object pointed by it, show the underlying ref
+ pointed by it when showing a symbolic ref.
+ peel
+ Show peeled tags.
+ ref-prefix <prefix>
+ When specified, only references having a prefix matching one of
+ the provided prefixes are displayed. Multiple instances may be
+ given, in which case references matching any prefix will be
+ shown. Note that this is purely for optimization; a server MAY
+ show refs not matching the prefix if it chooses, and clients
+ should filter the result themselves.
+
+If the 'unborn' feature is advertised the following argument can be
+included in the client's request.
+
+ unborn
+ The server will send information about HEAD even if it is a symref
+ pointing to an unborn branch in the form "unborn HEAD
+ symref-target:<target>".
+
+The output of ls-refs is as follows:
+
+ output = *ref
+ flush-pkt
+ obj-id-or-unborn = (obj-id | "unborn")
+ ref = PKT-LINE(obj-id-or-unborn SP refname *(SP ref-attribute) LF)
+ ref-attribute = (symref | peeled)
+ symref = "symref-target:" symref-target
+ peeled = "peeled:" obj-id
+
+fetch
+~~~~~
+
+`fetch` is the command used to fetch a packfile in v2. It can be looked
+at as a modified version of the v1 fetch where the ref-advertisement is
+stripped out (since the `ls-refs` command fills that role) and the
+message format is tweaked to eliminate redundancies and permit easy
+addition of future extensions.
+
+Additional features not supported in the base command will be advertised
+as the value of the command in the capability advertisement in the form
+of a space separated list of features: "<command>=<feature-1> <feature-2>"
+
+A `fetch` request can take the following arguments:
+
+ want <oid>
+ Indicates to the server an object which the client wants to
+ retrieve. Wants can be anything and are not limited to
+ advertised objects.
+
+ have <oid>
+ Indicates to the server an object which the client has locally.
+ This allows the server to make a packfile which only contains
+ the objects that the client needs. Multiple 'have' lines can be
+ supplied.
+
+ done
+ Indicates to the server that negotiation should terminate (or
+ not even begin if performing a clone) and that the server should
+ use the information supplied in the request to construct the
+ packfile.
+
+ thin-pack
+ Request that a thin pack be sent, which is a pack with deltas
+ which reference base objects not contained within the pack (but
+ are known to exist at the receiving end). This can reduce the
+ network traffic significantly, but it requires the receiving end
+ to know how to "thicken" these packs by adding the missing bases
+ to the pack.
+
+ no-progress
+ Request that progress information that would normally be sent on
+ side-band channel 2, during the packfile transfer, should not be
+ sent. However, the side-band channel 3 is still used for error
+ responses.
+
+ include-tag
+ Request that annotated tags should be sent if the objects they
+ point to are being sent.
+
+ ofs-delta
+ Indicate that the client understands PACKv2 with delta referring
+ to its base by position in pack rather than by an oid. That is,
+ they can read OBJ_OFS_DELTA (aka type 6) in a packfile.
+
+If the 'shallow' feature is advertised the following arguments can be
+included in the clients request as well as the potential addition of the
+'shallow-info' section in the server's response as explained below.
+
+ shallow <oid>
+ A client must notify the server of all commits for which it only
+ has shallow copies (meaning that it doesn't have the parents of
+ a commit) by supplying a 'shallow <oid>' line for each such
+ object so that the server is aware of the limitations of the
+ client's history. This is so that the server is aware that the
+ client may not have all objects reachable from such commits.
+
+ deepen <depth>
+ Requests that the fetch/clone should be shallow having a commit
+ depth of <depth> relative to the remote side.
+
+ deepen-relative
+ Requests that the semantics of the "deepen" command be changed
+ to indicate that the depth requested is relative to the client's
+ current shallow boundary, instead of relative to the requested
+ commits.
+
+ deepen-since <timestamp>
+ Requests that the shallow clone/fetch should be cut at a
+ specific time, instead of depth. Internally it's equivalent to
+ doing "git rev-list --max-age=<timestamp>". Cannot be used with
+ "deepen".
+
+ deepen-not <rev>
+ Requests that the shallow clone/fetch should be cut at a
+ specific revision specified by '<rev>', instead of a depth.
+ Internally it's equivalent of doing "git rev-list --not <rev>".
+ Cannot be used with "deepen", but can be used with
+ "deepen-since".
+
+If the 'filter' feature is advertised, the following argument can be
+included in the client's request:
+
+ filter <filter-spec>
+ Request that various objects from the packfile be omitted
+ using one of several filtering techniques. These are intended
+ for use with partial clone and partial fetch operations. See
+ `rev-list` for possible "filter-spec" values. When communicating
+ with other processes, senders SHOULD translate scaled integers
+ (e.g. "1k") into a fully-expanded form (e.g. "1024") to aid
+ interoperability with older receivers that may not understand
+ newly-invented scaling suffixes. However, receivers SHOULD
+ accept the following suffixes: 'k', 'm', and 'g' for 1024,
+ 1048576, and 1073741824, respectively.
+
+If the 'ref-in-want' feature is advertised, the following argument can
+be included in the client's request as well as the potential addition of
+the 'wanted-refs' section in the server's response as explained below.
+
+ want-ref <ref>
+ Indicates to the server that the client wants to retrieve a
+ particular ref, where <ref> is the full name of a ref on the
+ server. It is a protocol error to send want-ref for the
+ same ref more than once.
+
+If the 'sideband-all' feature is advertised, the following argument can be
+included in the client's request:
+
+ sideband-all
+ Instruct the server to send the whole response multiplexed, not just
+ the packfile section. All non-flush and non-delim PKT-LINE in the
+ response (not only in the packfile section) will then start with a byte
+ indicating its sideband (1, 2, or 3), and the server may send "0005\2"
+ (a PKT-LINE of sideband 2 with no payload) as a keepalive packet.
+
+If the 'packfile-uris' feature is advertised, the following argument
+can be included in the client's request as well as the potential
+addition of the 'packfile-uris' section in the server's response as
+explained below. Note that at most one `packfile-uris` line can be sent
+to the server.
+
+ packfile-uris <comma-separated-list-of-protocols>
+ Indicates to the server that the client is willing to receive
+ URIs of any of the given protocols in place of objects in the
+ sent packfile. Before performing the connectivity check, the
+ client should download from all given URIs. Currently, the
+ protocols supported are "http" and "https".
+
+If the 'wait-for-done' feature is advertised, the following argument
+can be included in the client's request.
+
+ wait-for-done
+ Indicates to the server that it should never send "ready", but
+ should wait for the client to say "done" before sending the
+ packfile.
+
+The response of `fetch` is broken into a number of sections separated by
+delimiter packets (0001), with each section beginning with its section
+header. Most sections are sent only when the packfile is sent.
+
+ output = acknowledgements flush-pkt |
+ [acknowledgments delim-pkt] [shallow-info delim-pkt]
+ [wanted-refs delim-pkt] [packfile-uris delim-pkt]
+ packfile flush-pkt
+
+ acknowledgments = PKT-LINE("acknowledgments" LF)
+ (nak | *ack)
+ (ready)
+ ready = PKT-LINE("ready" LF)
+ nak = PKT-LINE("NAK" LF)
+ ack = PKT-LINE("ACK" SP obj-id LF)
+
+ shallow-info = PKT-LINE("shallow-info" LF)
+ *PKT-LINE((shallow | unshallow) LF)
+ shallow = "shallow" SP obj-id
+ unshallow = "unshallow" SP obj-id
+
+ wanted-refs = PKT-LINE("wanted-refs" LF)
+ *PKT-LINE(wanted-ref LF)
+ wanted-ref = obj-id SP refname
+
+ packfile-uris = PKT-LINE("packfile-uris" LF) *packfile-uri
+ packfile-uri = PKT-LINE(40*(HEXDIGIT) SP *%x20-ff LF)
+
+ packfile = PKT-LINE("packfile" LF)
+ *PKT-LINE(%x01-03 *%x00-ff)
+
+ acknowledgments section
+ * If the client determines that it is finished with negotiations by
+ sending a "done" line (thus requiring the server to send a packfile),
+ the acknowledgments sections MUST be omitted from the server's
+ response.
+
+ * Always begins with the section header "acknowledgments"
+
+ * The server will respond with "NAK" if none of the object ids sent
+ as have lines were common.
+
+ * The server will respond with "ACK obj-id" for all of the
+ object ids sent as have lines which are common.
+
+ * A response cannot have both "ACK" lines as well as a "NAK"
+ line.
+
+ * The server will respond with a "ready" line indicating that
+ the server has found an acceptable common base and is ready to
+ make and send a packfile (which will be found in the packfile
+ section of the same response)
+
+ * If the server has found a suitable cut point and has decided
+ to send a "ready" line, then the server can decide to (as an
+ optimization) omit any "ACK" lines it would have sent during
+ its response. This is because the server will have already
+ determined the objects it plans to send to the client and no
+ further negotiation is needed.
+
+ shallow-info section
+ * If the client has requested a shallow fetch/clone, a shallow
+ client requests a fetch or the server is shallow then the
+ server's response may include a shallow-info section. The
+ shallow-info section will be included if (due to one of the
+ above conditions) the server needs to inform the client of any
+ shallow boundaries or adjustments to the clients already
+ existing shallow boundaries.
+
+ * Always begins with the section header "shallow-info"
+
+ * If a positive depth is requested, the server will compute the
+ set of commits which are no deeper than the desired depth.
+
+ * The server sends a "shallow obj-id" line for each commit whose
+ parents will not be sent in the following packfile.
+
+ * The server sends an "unshallow obj-id" line for each commit
+ which the client has indicated is shallow, but is no longer
+ shallow as a result of the fetch (due to its parents being
+ sent in the following packfile).
+
+ * The server MUST NOT send any "unshallow" lines for anything
+ which the client has not indicated was shallow as a part of
+ its request.
+
+ wanted-refs section
+ * This section is only included if the client has requested a
+ ref using a 'want-ref' line and if a packfile section is also
+ included in the response.
+
+ * Always begins with the section header "wanted-refs".
+
+ * The server will send a ref listing ("<oid> <refname>") for
+ each reference requested using 'want-ref' lines.
+
+ * The server MUST NOT send any refs which were not requested
+ using 'want-ref' lines.
+
+ packfile-uris section
+ * This section is only included if the client sent
+ 'packfile-uris' and the server has at least one such URI to
+ send.
+
+ * Always begins with the section header "packfile-uris".
+
+ * For each URI the server sends, it sends a hash of the pack's
+ contents (as output by git index-pack) followed by the URI.
+
+ * The hashes are 40 hex characters long. When Git upgrades to a new
+ hash algorithm, this might need to be updated. (It should match
+ whatever index-pack outputs after "pack\t" or "keep\t".
+
+ packfile section
+ * This section is only included if the client has sent 'want'
+ lines in its request and either requested that no more
+ negotiation be done by sending 'done' or if the server has
+ decided it has found a sufficient cut point to produce a
+ packfile.
+
+ * Always begins with the section header "packfile"
+
+ * The transmission of the packfile begins immediately after the
+ section header
+
+ * The data transfer of the packfile is always multiplexed, using
+ the same semantics of the 'side-band-64k' capability from
+ protocol version 1. This means that each packet, during the
+ packfile data stream, is made up of a leading 4-byte pkt-line
+ length (typical of the pkt-line format), followed by a 1-byte
+ stream code, followed by the actual data.
+
+ The stream code can be one of:
+ 1 - pack data
+ 2 - progress messages
+ 3 - fatal error message just before stream aborts
+
+server-option
+~~~~~~~~~~~~~
+
+If advertised, indicates that any number of server specific options can be
+included in a request. This is done by sending each option as a
+"server-option=<option>" capability line in the capability-list section of
+a request.
+
+The provided options must not contain a NUL or LF character.
+
+object-format
+~~~~~~~~~~~~~
+
+The server can advertise the `object-format` capability with a value `X` (in the
+form `object-format=X`) to notify the client that the server is able to deal
+with objects using hash algorithm X. If not specified, the server is assumed to
+only handle SHA-1. If the client would like to use a hash algorithm other than
+SHA-1, it should specify its object-format string.
+
+session-id=<session-id>
+~~~~~~~~~~~~~~~~~~~~~~~
+
+The server may advertise a session ID that can be used to identify this process
+across multiple requests. The client may advertise its own session ID back to
+the server as well.
+
+Session IDs should be unique to a given process. They must fit within a
+packet-line, and must not contain non-printable or whitespace characters. The
+current implementation uses trace2 session IDs (see
+link:technical/api-trace2.html[api-trace2] for details), but this may change
+and users of the session ID should not rely on this fact.
+
+object-info
+~~~~~~~~~~~
+
+`object-info` is the command to retrieve information about one or more objects.
+Its main purpose is to allow a client to make decisions based on this
+information without having to fully fetch objects. Object size is the only
+information that is currently supported.
+
+An `object-info` request takes the following arguments:
+
+ size
+ Requests size information to be returned for each listed object id.
+
+ oid <oid>
+ Indicates to the server an object which the client wants to obtain
+ information for.
+
+The response of `object-info` is a list of the requested object ids
+and associated requested information, each separated by a single space.
+
+ output = info flush-pkt
+
+ info = PKT-LINE(attrs) LF)
+ *PKT-LINE(obj-info LF)
+
+ attrs = attr | attrs SP attrs
+
+ attr = "size"
+
+ obj-info = obj-id SP obj-size
+
+bundle-uri
+~~~~~~~~~~
+
+If the 'bundle-uri' capability is advertised, the server supports the
+`bundle-uri' command.
+
+The capability is currently advertised with no value (i.e. not
+"bundle-uri=somevalue"), a value may be added in the future for
+supporting command-wide extensions. Clients MUST ignore any unknown
+capability values and proceed with the 'bundle-uri` dialog they
+support.
+
+The 'bundle-uri' command is intended to be issued before `fetch` to
+get URIs to bundle files (see linkgit:git-bundle[1]) to "seed" and
+inform the subsequent `fetch` command.
+
+The client CAN issue `bundle-uri` before or after any other valid
+command. To be useful to clients it's expected that it'll be issued
+after an `ls-refs` and before `fetch`, but CAN be issued at any time
+in the dialog.
+
+DISCUSSION of bundle-uri
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+The intent of the feature is optimize for server resource consumption
+in the common case by changing the common case of fetching a very
+large PACK during linkgit:git-clone[1] into a smaller incremental
+fetch.
+
+It also allows servers to achieve better caching in combination with
+an `uploadpack.packObjectsHook` (see linkgit:git-config[1]).
+
+By having new clones or fetches be a more predictable and common
+negotiation against the tips of recently produces *.bundle file(s).
+Servers might even pre-generate the results of such negotiations for
+the `uploadpack.packObjectsHook` as new pushes come in.
+
+One way that servers could take advantage of these bundles is that the
+server would anticipate that fresh clones will download a known bundle,
+followed by catching up to the current state of the repository using ref
+tips found in that bundle (or bundles).
+
+PROTOCOL for bundle-uri
+^^^^^^^^^^^^^^^^^^^^^^^
+
+A `bundle-uri` request takes no arguments, and as noted above does not
+currently advertise a capability value. Both may be added in the
+future.
+
+When the client issues a `command=bundle-uri` request, the response is a
+list of key-value pairs provided as packet lines with value
+`<key>=<value>`. Each `<key>` should be interpreted as a config key from
+the `bundle.*` namespace to construct a list of bundles. These keys are
+grouped by a `bundle.<id>.` subsection, where each key corresponding to a
+given `<id>` contributes attributes to the bundle defined by that `<id>`.
+See linkgit:git-config[1] for the specific details of these keys and how
+the Git client will interpret their values.
+
+Clients MUST parse the line according to the above format, lines that do
+not conform to the format SHOULD be discarded. The user MAY be warned in
+such a case.
+
+bundle-uri CLIENT AND SERVER EXPECTATIONS
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+URI CONTENTS::
+The content at the advertised URIs MUST be one of two types.
++
+The advertised URI may contain a bundle file that `git bundle verify`
+would accept. I.e. they MUST contain one or more reference tips for
+use by the client, MUST indicate prerequisites (in any) with standard
+"-" prefixes, and MUST indicate their "object-format", if
+applicable.
++
+The advertised URI may alternatively contain a plaintext file that `git
+config --list` would accept (with the `--file` option). The key-value
+pairs in this list are in the `bundle.*` namespace (see
+linkgit:git-config[1]).
+
+bundle-uri CLIENT ERROR RECOVERY::
+A client MUST above all gracefully degrade on errors, whether that
+error is because of bad missing/data in the bundle URI(s), because
+that client is too dumb to e.g. understand and fully parse out bundle
+headers and their prerequisite relationships, or something else.
++
+Server operators should feel confident in turning on "bundle-uri" and
+not worry if e.g. their CDN goes down that clones or fetches will run
+into hard failures. Even if the server bundle(s) are
+incomplete, or bad in some way the client should still end up with a
+functioning repository, just as if it had chosen not to use this
+protocol extension.
++
+All subsequent discussion on client and server interaction MUST keep
+this in mind.
+
+bundle-uri SERVER TO CLIENT::
+The ordering of the returned bundle uris is not significant. Clients
+MUST parse their headers to discover their contained OIDS and
+prerequisites. A client MUST consider the content of the bundle(s)
+themselves and their header as the ultimate source of truth.
++
+A server MAY even return bundle(s) that don't have any direct
+relationship to the repository being cloned (either through accident,
+or intentional "clever" configuration), and expect a client to sort
+out what data they'd like from the bundle(s), if any.
+
+bundle-uri CLIENT TO SERVER::
+The client SHOULD provide reference tips found in the bundle header(s)
+as 'have' lines in any subsequent `fetch` request. A client MAY also
+ignore the bundle(s) entirely if doing so is deemed worse for some
+reason, e.g. if the bundles can't be downloaded, it doesn't like the
+tips it finds etc.
+
+WHEN ADVERTISED BUNDLE(S) REQUIRE NO FURTHER NEGOTIATION::
+If after issuing `bundle-uri` and `ls-refs`, and getting the header(s)
+of the bundle(s) the client finds that the ref tips it wants can be
+retrieved entirely from advertised bundle(s), the client MAY disconnect
+from the Git server. The results of such a 'clone' or 'fetch' should be
+indistinguishable from the state attained without using bundle-uri.
+
+EARLY CLIENT DISCONNECTIONS AND ERROR RECOVERY::
+A client MAY perform an early disconnect while still downloading the
+bundle(s) (having streamed and parsed their headers). In such a case
+the client MUST gracefully recover from any errors related to
+finishing the download and validation of the bundle(s).
++
+I.e. a client might need to re-connect and issue a 'fetch' command,
+and possibly fall back to not making use of 'bundle-uri' at all.
++
+This "MAY" behavior is specified as such (and not a "SHOULD") on the
+assumption that a server advertising bundle uris is more likely than
+not to be serving up a relatively large repository, and to be pointing
+to URIs that have a good chance of being in working order. A client
+MAY e.g. look at the payload size of the bundles as a heuristic to see
+if an early disconnect is worth it, should falling back on a full
+"fetch" dialog be necessary.
+
+WHEN ADVERTISED BUNDLE(S) REQUIRE FURTHER NEGOTIATION::
+A client SHOULD commence a negotiation of a PACK from the server via
+the "fetch" command using the OID tips found in advertised bundles,
+even if's still in the process of downloading those bundle(s).
++
+This allows for aggressive early disconnects from any interactive
+server dialog. The client blindly trusts that the advertised OID tips
+are relevant, and issues them as 'have' lines, it then requests any
+tips it would like (usually from the "ls-refs" advertisement) via
+'want' lines. The server will then compute a (hopefully small) PACK
+with the expected difference between the tips from the bundle(s) and
+the data requested.
++
+The only connection the client then needs to keep active is to the
+concurrently downloading static bundle(s), when those and the
+incremental PACK are retrieved they should be inflated and
+validated. Any errors at this point should be gracefully recovered
+from, see above.
+
+bundle-uri PROTOCOL FEATURES
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The client constructs a bundle list from the `<key>=<value>` pairs
+provided by the server. These pairs are part of the `bundle.*` namespace
+as documented in linkgit:git-config[1]. In this section, we discuss some
+of these keys and describe the actions the client will do in response to
+this information.
+
+In particular, the `bundle.version` key specifies an integer value. The
+only accepted value at the moment is `1`, but if the client sees an
+unexpected value here then the client MUST ignore the bundle list.
+
+As long as `bundle.version` is understood, all other unknown keys MAY be
+ignored by the client. The server will guarantee compatibility with older
+clients, though newer clients may be better able to use the extra keys to
+minimize downloads.
+
+Any backwards-incompatible addition of pre-URI key-value will be
+guarded by a new `bundle.version` value or values in 'bundle-uri'
+capability advertisement itself, and/or by new future `bundle-uri`
+request arguments.
+
+Some example key-value pairs that are not currently implemented but could
+be implemented in the future include:
+
+ * Add a "hash=<val>" or "size=<bytes>" advertise the expected hash or
+ size of the bundle file.
+
+ * Advertise that one or more bundle files are the same (to e.g. have
+ clients round-robin or otherwise choose one of N possible files).
+
+ * A "oid=<OID>" shortcut and "prerequisite=<OID>" shortcut. For
+ expressing the common case of a bundle with one tip and no
+ prerequisites, or one tip and one prerequisite.
++
+This would allow for optimizing the common case of servers who'd like
+to provide one "big bundle" containing only their "main" branch,
+and/or incremental updates thereof.
++
+A client receiving such a response MAY assume that they can skip
+retrieving the header from a bundle at the indicated URI, and thus
+save themselves and the server(s) the request(s) needed to inspect the
+headers of that bundle or bundles.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitremote-helpers.adoc b/gitremote-helpers.adoc
new file mode 100644
index 0000000..d0be008
--- /dev/null
+++ b/gitremote-helpers.adoc
@@ -0,0 +1,562 @@
+gitremote-helpers(7)
+====================
+
+NAME
+----
+gitremote-helpers - Helper programs to interact with remote repositories
+
+SYNOPSIS
+--------
+[verse]
+'git remote-<transport>' <repository> [<URL>]
+
+DESCRIPTION
+-----------
+
+Remote helper programs are normally not used directly by end users,
+but they are invoked by Git when it needs to interact with remote
+repositories Git does not support natively. A given helper will
+implement a subset of the capabilities documented here. When Git
+needs to interact with a repository using a remote helper, it spawns
+the helper as an independent process, sends commands to the helper's
+standard input, and expects results from the helper's standard
+output. Because a remote helper runs as an independent process from
+Git, there is no need to re-link Git to add a new helper, nor any
+need to link the helper with the implementation of Git.
+
+Every helper must support the "capabilities" command, which Git
+uses to determine what other commands the helper will accept. Those
+other commands can be used to discover and update remote refs,
+transport objects between the object database and the remote repository,
+and update the local object store.
+
+Git comes with a "curl" family of remote helpers, that handle various
+transport protocols, such as 'git-remote-http', 'git-remote-https',
+'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities
+'fetch', 'option', and 'push'.
+
+INVOCATION
+----------
+
+Remote helper programs are invoked with one or (optionally) two
+arguments. The first argument specifies a remote repository as in Git;
+it is either the name of a configured remote or a URL. The second
+argument specifies a URL; it is usually of the form
+'<transport>://<address>', but any arbitrary string is possible.
+The `GIT_DIR` environment variable is set up for the remote helper
+and can be used to determine where to store additional data or from
+which directory to invoke auxiliary Git commands.
+
+When Git encounters a URL of the form '<transport>://<address>', where
+'<transport>' is a protocol that it cannot handle natively, it
+automatically invokes 'git remote-<transport>' with the full URL as
+the second argument. If such a URL is encountered directly on the
+command line, the first argument is the same as the second, and if it
+is encountered in a configured remote, the first argument is the name
+of that remote.
+
+A URL of the form '<transport>::<address>' explicitly instructs Git to
+invoke 'git remote-<transport>' with '<address>' as the second
+argument. If such a URL is encountered directly on the command line,
+the first argument is '<address>', and if it is encountered in a
+configured remote, the first argument is the name of that remote.
+
+Additionally, when a configured remote has `remote.<name>.vcs` set to
+'<transport>', Git explicitly invokes 'git remote-<transport>' with
+'<name>' as the first argument. If set, the second argument is
+`remote.<name>.url`; otherwise, the second argument is omitted.
+
+INPUT FORMAT
+------------
+
+Git sends the remote helper a list of commands on standard input, one
+per line. The first command is always the 'capabilities' command, in
+response to which the remote helper must print a list of the
+capabilities it supports (see below) followed by a blank line. The
+response to the capabilities command determines what commands Git uses
+in the remainder of the command stream.
+
+The command stream is terminated by a blank line. In some cases
+(indicated in the documentation of the relevant commands), this blank
+line is followed by a payload in some other protocol (e.g., the pack
+protocol), while in others it indicates the end of input.
+
+Capabilities
+~~~~~~~~~~~~
+
+Each remote helper is expected to support only a subset of commands.
+The operations a helper supports are declared to Git in the response
+to the `capabilities` command (see COMMANDS, below).
+
+In the following, we list all defined capabilities and for
+each we list which commands a helper with that capability
+must provide.
+
+Capabilities for Pushing
+^^^^^^^^^^^^^^^^^^^^^^^^
+'connect'::
+ Can attempt to connect to 'git receive-pack' (for pushing),
+ 'git upload-pack', etc for communication using
+ git's native packfile protocol. This
+ requires a bidirectional, full-duplex connection.
++
+Supported commands: 'connect'.
+
+'stateless-connect'::
+ Experimental; for internal use only.
+ Can attempt to connect to a remote server for communication
+ using git's wire-protocol version 2. See the documentation
+ for the stateless-connect command for more information.
++
+Supported commands: 'stateless-connect'.
+
+'push'::
+ Can discover remote refs and push local commits and the
+ history leading up to them to new or existing remote refs.
++
+Supported commands: 'list for-push', 'push'.
+
+'export'::
+ Can discover remote refs and push specified objects from a
+ fast-import stream to remote refs.
++
+Supported commands: 'list for-push', 'export'.
+
+If a helper advertises 'connect', Git will use it if possible and
+fall back to another capability if the helper requests so when
+connecting (see the 'connect' command under COMMANDS).
+When choosing between 'push' and 'export', Git prefers 'push'.
+Other frontends may have some other order of preference.
+
+'no-private-update'::
+ When using the 'refspec' capability, git normally updates the
+ private ref on successful push. This update is disabled when
+ the remote-helper declares the capability 'no-private-update'.
+
+
+Capabilities for Fetching
+^^^^^^^^^^^^^^^^^^^^^^^^^
+'connect'::
+ Can try to connect to 'git upload-pack' (for fetching),
+ 'git receive-pack', etc for communication using the
+ Git's native packfile protocol. This
+ requires a bidirectional, full-duplex connection.
++
+Supported commands: 'connect'.
+
+'stateless-connect'::
+ Experimental; for internal use only.
+ Can attempt to connect to a remote server for communication
+ using git's wire-protocol version 2. See the documentation
+ for the stateless-connect command for more information.
++
+Supported commands: 'stateless-connect'.
+
+'fetch'::
+ Can discover remote refs and transfer objects reachable from
+ them to the local object store.
++
+Supported commands: 'list', 'fetch'.
+
+'import'::
+ Can discover remote refs and output objects reachable from
+ them as a stream in fast-import format.
++
+Supported commands: 'list', 'import'.
+
+'check-connectivity'::
+ Can guarantee that when a clone is requested, the received
+ pack is self contained and is connected.
+
+'get'::
+ Can use the 'get' command to download a file from a given URI.
+
+If a helper advertises 'connect', Git will use it if possible and
+fall back to another capability if the helper requests so when
+connecting (see the 'connect' command under COMMANDS).
+When choosing between 'fetch' and 'import', Git prefers 'fetch'.
+Other frontends may have some other order of preference.
+
+Miscellaneous capabilities
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+'option'::
+ For specifying settings like `verbosity` (how much output to
+ write to stderr) and `depth` (how much history is wanted in the
+ case of a shallow clone) that affect how other commands are
+ carried out.
+
+'refspec' <refspec>::
+ For remote helpers that implement 'import' or 'export', this capability
+ allows the refs to be constrained to a private namespace, instead of
+ writing to refs/heads or refs/remotes directly.
+ It is recommended that all importers providing the 'import'
+ capability use this. It's mandatory for 'export'.
++
+A helper advertising the capability
+`refspec refs/heads/*:refs/svn/origin/branches/*`
+is saying that, when it is asked to `import refs/heads/topic`, the
+stream it outputs will update the `refs/svn/origin/branches/topic`
+ref.
++
+This capability can be advertised multiple times. The first
+applicable refspec takes precedence. The left-hand of refspecs
+advertised with this capability must cover all refs reported by
+the list command. If no 'refspec' capability is advertised,
+there is an implied `refspec *:*`.
++
+When writing remote-helpers for decentralized version control
+systems, it is advised to keep a local copy of the repository to
+interact with, and to let the private namespace refs point to this
+local repository, while the refs/remotes namespace is used to track
+the remote repository.
+
+'bidi-import'::
+ This modifies the 'import' capability.
+ The fast-import commands 'cat-blob' and 'ls' can be used by remote-helpers
+ to retrieve information about blobs and trees that already exist in
+ fast-import's memory. This requires a channel from fast-import to the
+ remote-helper.
+ If it is advertised in addition to "import", Git establishes a pipe from
+ fast-import to the remote-helper's stdin.
+ It follows that Git and fast-import are both connected to the
+ remote-helper's stdin. Because Git can send multiple commands to
+ the remote-helper it is required that helpers that use 'bidi-import'
+ buffer all 'import' commands of a batch before sending data to fast-import.
+ This is to prevent mixing commands and fast-import responses on the
+ helper's stdin.
+
+'export-marks' <file>::
+ This modifies the 'export' capability, instructing Git to dump the
+ internal marks table to <file> when complete. For details,
+ read up on `--export-marks=<file>` in linkgit:git-fast-export[1].
+
+'import-marks' <file>::
+ This modifies the 'export' capability, instructing Git to load the
+ marks specified in <file> before processing any input. For details,
+ read up on `--import-marks=<file>` in linkgit:git-fast-export[1].
+
+'signed-tags'::
+ This modifies the 'export' capability, instructing Git to pass
+ `--signed-tags=verbatim` to linkgit:git-fast-export[1]. In the
+ absence of this capability, Git will use `--signed-tags=warn-strip`.
+
+'object-format'::
+ This indicates that the helper is able to interact with the remote
+ side using an explicit hash algorithm extension.
+
+
+COMMANDS
+--------
+
+Commands are given by the caller on the helper's standard input, one per line.
+
+'capabilities'::
+ Lists the capabilities of the helper, one per line, ending
+ with a blank line. Each capability may be preceded with '*',
+ which marks them mandatory for Git versions using the remote
+ helper to understand. Any unknown mandatory capability is a
+ fatal error.
++
+Support for this command is mandatory.
+
+'list'::
+ Lists the refs, one per line, in the format "<value> <name>
+ [<attr> ...]". The value may be a hex sha1 hash, "@<dest>" for
+ a symref, ":<keyword> <value>" for a key-value pair, or
+ "?" to indicate that the helper could not get the value of the
+ ref. A space-separated list of attributes follows the name;
+ unrecognized attributes are ignored. The list ends with a
+ blank line.
++
+See REF LIST ATTRIBUTES for a list of currently defined attributes.
+See REF LIST KEYWORDS for a list of currently defined keywords.
++
+Supported if the helper has the "fetch" or "import" capability.
+
+'list for-push'::
+ Similar to 'list', except that it is used if and only if
+ the caller wants to the resulting ref list to prepare
+ push commands.
+ A helper supporting both push and fetch can use this
+ to distinguish for which operation the output of 'list'
+ is going to be used, possibly reducing the amount
+ of work that needs to be performed.
++
+Supported if the helper has the "push" or "export" capability.
+
+'option' <name> <value>::
+ Sets the transport helper option <name> to <value>. Outputs a
+ single line containing one of 'ok' (option successfully set),
+ 'unsupported' (option not recognized) or 'error <msg>'
+ (option <name> is supported but <value> is not valid
+ for it). Options should be set before other commands,
+ and may influence the behavior of those commands.
++
+See OPTIONS for a list of currently defined options.
++
+Supported if the helper has the "option" capability.
+
+'fetch' <sha1> <name>::
+ Fetches the given object, writing the necessary objects
+ to the database. Fetch commands are sent in a batch, one
+ per line, terminated with a blank line.
+ Outputs a single blank line when all fetch commands in the
+ same batch are complete. Only objects which were reported
+ in the output of 'list' with a sha1 may be fetched this way.
++
+Optionally may output a 'lock <file>' line indicating the full path of
+a file under `$GIT_DIR/objects/pack` which is keeping a pack until
+refs can be suitably updated. The path must end with `.keep`. This is
+a mechanism to name a <pack,idx,keep> tuple by giving only the keep
+component. The kept pack will not be deleted by a concurrent repack,
+even though its objects may not be referenced until the fetch completes.
+The `.keep` file will be deleted at the conclusion of the fetch.
++
+If option 'check-connectivity' is requested, the helper must output
+'connectivity-ok' if the clone is self-contained and connected.
++
+Supported if the helper has the "fetch" capability.
+
+'push' +<src>:<dst>::
+ Pushes the given local <src> commit or branch to the
+ remote branch described by <dst>. A batch sequence of
+ one or more 'push' commands is terminated with a blank line
+ (if there is only one reference to push, a single 'push' command
+ is followed by a blank line). For example, the following would
+ be two batches of 'push', the first asking the remote-helper
+ to push the local ref 'master' to the remote ref 'master' and
+ the local `HEAD` to the remote 'branch', and the second
+ asking to push ref 'foo' to ref 'bar' (forced update requested
+ by the '+').
++
+------------
+push refs/heads/master:refs/heads/master
+push HEAD:refs/heads/branch
+\n
+push +refs/heads/foo:refs/heads/bar
+\n
+------------
++
+Zero or more protocol options may be entered after the last 'push'
+command, before the batch's terminating blank line.
++
+When the push is complete, outputs one or more 'ok <dst>' or
+'error <dst> <why>?' lines to indicate success or failure of
+each pushed ref. The status report output is terminated by
+a blank line. The option field <why> may be quoted in a C
+style string if it contains an LF.
++
+Supported if the helper has the "push" capability.
+
+'import' <name>::
+ Produces a fast-import stream which imports the current value
+ of the named ref. It may additionally import other refs as
+ needed to construct the history efficiently. The script writes
+ to a helper-specific private namespace. The value of the named
+ ref should be written to a location in this namespace derived
+ by applying the refspecs from the "refspec" capability to the
+ name of the ref.
++
+Especially useful for interoperability with a foreign versioning
+system.
++
+Just like 'push', a batch sequence of one or more 'import' is
+terminated with a blank line. For each batch of 'import', the remote
+helper should produce a fast-import stream terminated by a 'done'
+command.
++
+Note that if the 'bidi-import' capability is used the complete batch
+sequence has to be buffered before starting to send data to fast-import
+to prevent mixing of commands and fast-import responses on the helper's
+stdin.
++
+Supported if the helper has the "import" capability.
+
+'export'::
+ Instructs the remote helper that any subsequent input is
+ part of a fast-import stream (generated by 'git fast-export')
+ containing objects which should be pushed to the remote.
++
+Especially useful for interoperability with a foreign versioning
+system.
++
+The 'export-marks' and 'import-marks' capabilities, if specified,
+affect this command in so far as they are passed on to 'git
+fast-export', which then will load/store a table of marks for
+local objects. This can be used to implement for incremental
+operations.
++
+Supported if the helper has the "export" capability.
+
+'connect' <service>::
+ Connects to given service. Standard input and standard output
+ of helper are connected to specified service (git prefix is
+ included in service name so e.g. fetching uses 'git-upload-pack'
+ as service) on remote side. Valid replies to this command are
+ empty line (connection established), 'fallback' (no smart
+ transport support, fall back to dumb transports) and just
+ exiting with error message printed (can't connect, don't
+ bother trying to fall back). After line feed terminating the
+ positive (empty) response, the output of service starts. After
+ the connection ends, the remote helper exits.
++
+Supported if the helper has the "connect" capability.
+
+'stateless-connect' <service>::
+ Experimental; for internal use only.
+ Connects to the given remote service for communication using
+ git's wire-protocol version 2. Valid replies to this command
+ are empty line (connection established), 'fallback' (no smart
+ transport support, fall back to dumb transports) and just
+ exiting with error message printed (can't connect, don't bother
+ trying to fall back). After line feed terminating the positive
+ (empty) response, the output of the service starts. Messages
+ (both request and response) must consist of zero or more
+ PKT-LINEs, terminating in a flush packet. Response messages will
+ then have a response end packet after the flush packet to
+ indicate the end of a response. The client must not
+ expect the server to store any state in between request-response
+ pairs. After the connection ends, the remote helper exits.
++
+Supported if the helper has the "stateless-connect" capability.
+
+'get' <uri> <path>::
+ Downloads the file from the given `<uri>` to the given `<path>`. If
+ `<path>.temp` exists, then Git assumes that the `.temp` file is a
+ partial download from a previous attempt and will resume the
+ download from that position.
+
+If a fatal error occurs, the program writes the error message to
+stderr and exits. The caller should expect that a suitable error
+message has been printed if the child closes the connection without
+completing a valid response for the current command.
+
+Additional commands may be supported, as may be determined from
+capabilities reported by the helper.
+
+REF LIST ATTRIBUTES
+-------------------
+
+The 'list' command produces a list of refs in which each ref
+may be followed by a list of attributes. The following ref list
+attributes are defined.
+
+'unchanged'::
+ This ref is unchanged since the last import or fetch, although
+ the helper cannot necessarily determine what value that produced.
+
+REF LIST KEYWORDS
+-----------------
+
+The 'list' command may produce a list of key-value pairs.
+The following keys are defined.
+
+'object-format'::
+ The refs are using the given hash algorithm. This keyword is only
+ used if the server and client both support the object-format
+ extension.
+
+
+OPTIONS
+-------
+
+The following options are defined and (under suitable circumstances)
+set by Git if the remote helper has the 'option' capability.
+
+'option verbosity' <n>::
+ Changes the verbosity of messages displayed by the helper.
+ A value of 0 for <n> means that processes operate
+ quietly, and the helper produces only error output.
+ 1 is the default level of verbosity, and higher values
+ of <n> correspond to the number of -v flags passed on the
+ command line.
+
+'option progress' {'true'|'false'}::
+ Enables (or disables) progress messages displayed by the
+ transport helper during a command.
+
+'option depth' <depth>::
+ Deepens the history of a shallow repository.
+
+'option deepen-since' <timestamp>::
+ Deepens the history of a shallow repository based on time.
+
+'option deepen-not' <ref>::
+ Deepens the history of a shallow repository excluding ref.
+ Multiple options add up.
+
+'option deepen-relative' {'true'|'false'}::
+ Deepens the history of a shallow repository relative to
+ current boundary. Only valid when used with "option depth".
+
+'option followtags' {'true'|'false'}::
+ If enabled the helper should automatically fetch annotated
+ tag objects if the object the tag points at was transferred
+ during the fetch command. If the tag is not fetched by
+ the helper a second fetch command will usually be sent to
+ ask for the tag specifically. Some helpers may be able to
+ use this option to avoid a second network connection.
+
+'option dry-run' {'true'|'false'}:
+ If true, pretend the operation completed successfully,
+ but don't actually change any repository data. For most
+ helpers this only applies to the 'push', if supported.
+
+'option servpath <c-style-quoted-path>'::
+ Sets service path (--upload-pack, --receive-pack etc.) for
+ next connect. Remote helper may support this option, but
+ must not rely on this option being set before
+ connect request occurs.
+
+'option check-connectivity' {'true'|'false'}::
+ Request the helper to check connectivity of a clone.
+
+'option force' {'true'|'false'}::
+ Request the helper to perform a force update. Defaults to
+ 'false'.
+
+'option cloning' {'true'|'false'}::
+ Notify the helper this is a clone request (i.e. the current
+ repository is guaranteed empty).
+
+'option update-shallow' {'true'|'false'}::
+ Allow to extend .git/shallow if the new refs require it.
+
+'option pushcert' {'true'|'false'}::
+ GPG sign pushes.
+
+'option push-option' <string>::
+ Transmit <string> as a push option. As the push option
+ must not contain LF or NUL characters, the string is not encoded.
+
+'option from-promisor' {'true'|'false'}::
+ Indicate that these objects are being fetched from a promisor.
+
+'option no-dependents' {'true'|'false'}::
+ Indicate that only the objects wanted need to be fetched, not
+ their dependents.
+
+'option atomic' {'true'|'false'}::
+ When pushing, request the remote server to update refs in a single atomic
+ transaction. If successful, all refs will be updated, or none will. If the
+ remote side does not support this capability, the push will fail.
+
+'option object-format true'::
+ Indicate that the caller wants hash algorithm information
+ to be passed back from the remote. This mode is used when fetching
+ refs.
+
+SEE ALSO
+--------
+linkgit:git-remote[1]
+
+linkgit:git-remote-ext[1]
+
+linkgit:git-remote-fd[1]
+
+linkgit:git-fast-import[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitrepository-layout.adoc b/gitrepository-layout.adoc
new file mode 100644
index 0000000..6348ef1
--- /dev/null
+++ b/gitrepository-layout.adoc
@@ -0,0 +1,314 @@
+gitrepository-layout(5)
+=======================
+
+NAME
+----
+gitrepository-layout - Git Repository Layout
+
+SYNOPSIS
+--------
+$GIT_DIR/*
+
+DESCRIPTION
+-----------
+
+A Git repository comes in two different flavours:
+
+ * a `.git` directory at the root of the working tree;
+
+ * a `<project>.git` directory that is a 'bare' repository
+ (i.e. without its own working tree), that is typically used for
+ exchanging histories with others by pushing into it and fetching
+ from it.
+
+*Note*: Also you can have a plain text file `.git` at the root of
+your working tree, containing `gitdir: <path>` to point at the real
+directory that has the repository.
+This mechanism is called a 'gitfile' and is usually managed via the
+`git submodule` and `git worktree` commands. It is often used for
+a working tree of a submodule checkout, to allow you in the
+containing superproject to `git checkout` a branch that does not
+have the submodule. The `checkout` has to remove the entire
+submodule working tree, without losing the submodule repository.
+
+These things may exist in a Git repository.
+
+objects::
+ Object store associated with this repository. Usually
+ an object store is self sufficient (i.e. all the objects
+ that are referred to by an object found in it are also
+ found in it), but there are a few ways to violate it.
++
+. You could have an incomplete but locally usable repository
+by creating a shallow clone. See linkgit:git-clone[1].
+. You could be using the `objects/info/alternates` or
+`$GIT_ALTERNATE_OBJECT_DIRECTORIES` mechanisms to 'borrow'
+objects from other object stores. A repository with this kind
+of incomplete object store is not suitable to be published for
+use with dumb transports but otherwise is OK as long as
+`objects/info/alternates` points at the object stores it
+borrows from.
++
+This directory is ignored if $GIT_COMMON_DIR is set and
+"$GIT_COMMON_DIR/objects" will be used instead.
+
+objects/[0-9a-f][0-9a-f]::
+ A newly created object is stored in its own file.
+ The objects are splayed over 256 subdirectories using
+ the first two characters of the sha1 object name to
+ keep the number of directory entries in `objects`
+ itself to a manageable number. Objects found
+ here are often called 'unpacked' (or 'loose') objects.
+
+objects/pack::
+ Packs (files that store many objects in compressed form,
+ along with index files to allow them to be randomly
+ accessed) are found in this directory.
+
+objects/info::
+ Additional information about the object store is
+ recorded in this directory.
+
+objects/info/packs::
+ This file is to help dumb transports discover what packs
+ are available in this object store. Whenever a pack is
+ added or removed, `git update-server-info` should be run
+ to keep this file up to date if the repository is
+ published for dumb transports. 'git repack' does this
+ by default.
+
+objects/info/alternates::
+ This file records paths to alternate object stores that
+ this object store borrows objects from, one pathname per
+ line. Note that not only native Git tools use it locally,
+ but the HTTP fetcher also tries to use it remotely; this
+ will usually work if you have relative paths (relative
+ to the object database, not to the repository!) in your
+ alternates file, but it will not work if you use absolute
+ paths unless the absolute path in filesystem and web URL
+ is the same. See also `objects/info/http-alternates`.
+
+objects/info/http-alternates::
+ This file records URLs to alternate object stores that
+ this object store borrows objects from, to be used when
+ the repository is fetched over HTTP.
+
+refs::
+ References are stored in subdirectories of this
+ directory. The 'git prune' command knows to preserve
+ objects reachable from refs found in this directory and
+ its subdirectories.
+ This directory is ignored (except refs/bisect,
+ refs/rewritten and refs/worktree) if $GIT_COMMON_DIR is
+ set and "$GIT_COMMON_DIR/refs" will be used instead.
+
+refs/heads/`name`::
+ records tip-of-the-tree commit objects of branch `name`
+
+refs/tags/`name`::
+ records any object name (not necessarily a commit
+ object, or a tag object that points at a commit object).
+
+refs/remotes/`name`::
+ records tip-of-the-tree commit objects of branches copied
+ from a remote repository.
+
+refs/replace/`<obj-sha1>`::
+ records the SHA-1 of the object that replaces `<obj-sha1>`.
+ This is similar to info/grafts and is internally used and
+ maintained by linkgit:git-replace[1]. Such refs can be exchanged
+ between repositories while grafts are not.
+
+packed-refs::
+ records the same information as refs/heads/, refs/tags/,
+ and friends record in a more efficient way. See
+ linkgit:git-pack-refs[1]. This file is ignored if $GIT_COMMON_DIR
+ is set and "$GIT_COMMON_DIR/packed-refs" will be used instead.
+
+HEAD::
+ A symref (see glossary) to the `refs/heads/` namespace
+ describing the currently active branch. It does not mean
+ much if the repository is not associated with any working tree
+ (i.e. a 'bare' repository), but a valid Git repository
+ *must* have the HEAD file; some porcelains may use it to
+ guess the designated "default" branch of the repository
+ (usually 'master'). It is legal if the named branch
+ 'name' does not (yet) exist. In some legacy setups, it is
+ a symbolic link instead of a symref that points at the current
+ branch.
++
+HEAD can also record a specific commit directly, instead of
+being a symref to point at the current branch. Such a state
+is often called 'detached HEAD.' See linkgit:git-checkout[1]
+for details.
+
+config::
+ Repository specific configuration file. This file is ignored
+ if $GIT_COMMON_DIR is set and "$GIT_COMMON_DIR/config" will be
+ used instead.
+
+config.worktree::
+ Working directory specific configuration file for the main
+ working directory in multiple working directory setup (see
+ linkgit:git-worktree[1]).
+
+branches::
+ A deprecated way to store shorthands to be used
+ to specify a URL to 'git fetch', 'git pull' and 'git push'.
+ A file can be stored as `branches/<name>` and then
+ 'name' can be given to these commands in place of
+ 'repository' argument. See the REMOTES section in
+ linkgit:git-fetch[1] for details. This mechanism is legacy
+ and not likely to be found in modern repositories. This
+ directory is ignored if $GIT_COMMON_DIR is set and
+ "$GIT_COMMON_DIR/branches" will be used instead.
++
+Git will stop reading remotes from this directory in Git 3.0.
+
+hooks::
+ Hooks are customization scripts used by various Git
+ commands. A handful of sample hooks are installed when
+ 'git init' is run, but all of them are disabled by
+ default. To enable, the `.sample` suffix has to be
+ removed from the filename by renaming.
+ Read linkgit:githooks[5] for more details about
+ each hook. This directory is ignored if $GIT_COMMON_DIR is set
+ and "$GIT_COMMON_DIR/hooks" will be used instead.
+
+common::
+ When multiple working trees are used, most of files in
+ $GIT_DIR are per-worktree with a few known exceptions. All
+ files under 'common' however will be shared between all
+ working trees.
+
+index::
+ The current index file for the repository. It is
+ usually not found in a bare repository.
+
+sharedindex.<SHA-1>::
+ The shared index part, to be referenced by $GIT_DIR/index and
+ other temporary index files. Only valid in split index mode.
+
+info::
+ Additional information about the repository is recorded
+ in this directory. This directory is ignored if $GIT_COMMON_DIR
+ is set and "$GIT_COMMON_DIR/info" will be used instead.
+
+info/refs::
+ This file helps dumb transports discover what refs are
+ available in this repository. If the repository is
+ published for dumb transports, this file should be
+ regenerated by 'git update-server-info' every time a tag
+ or branch is created or modified. This is normally done
+ from the `hooks/update` hook, which is run by the
+ 'git-receive-pack' command when you 'git push' into the
+ repository.
+
+info/grafts::
+ This file records fake commit ancestry information, to
+ pretend the set of parents a commit has is different
+ from how the commit was actually created. One record
+ per line describes a commit and its fake parents by
+ listing their 40-byte hexadecimal object names separated
+ by a space and terminated by a newline.
++
+Note that the grafts mechanism is outdated and can lead to problems
+transferring objects between repositories; see linkgit:git-replace[1]
+for a more flexible and robust system to do the same thing.
+
+info/exclude::
+ This file, by convention among Porcelains, stores the
+ exclude pattern list. `.gitignore` is the per-directory
+ ignore file. 'git status', 'git add', 'git rm' and
+ 'git clean' look at it but the core Git commands do not look
+ at it. See also: linkgit:gitignore[5].
+
+info/attributes::
+ Defines which attributes to assign to a path, similar to per-directory
+ `.gitattributes` files. See also: linkgit:gitattributes[5].
+
+info/sparse-checkout::
+ This file stores sparse checkout patterns.
+ See also: linkgit:git-read-tree[1].
+
+remotes::
+ Stores shorthands for URL and default refnames for use
+ when interacting with remote repositories via 'git fetch',
+ 'git pull' and 'git push' commands. See the REMOTES section
+ in linkgit:git-fetch[1] for details. This mechanism is legacy
+ and not likely to be found in modern repositories. This
+ directory is ignored if $GIT_COMMON_DIR is set and
+ "$GIT_COMMON_DIR/remotes" will be used instead.
++
+Git will stop reading remotes from this directory in Git 3.0.
+
+logs::
+ Records of changes made to refs are stored in this directory.
+ See linkgit:git-update-ref[1] for more information. This
+ directory is ignored (except logs/HEAD) if $GIT_COMMON_DIR is
+ set and "$GIT_COMMON_DIR/logs" will be used instead.
+
+logs/refs/heads/`name`::
+ Records all changes made to the branch tip named `name`.
+
+logs/refs/tags/`name`::
+ Records all changes made to the tag named `name`.
+
+shallow::
+ This is similar to `info/grafts` but is internally used
+ and maintained by shallow clone mechanism. See `--depth`
+ option to linkgit:git-clone[1] and linkgit:git-fetch[1]. This
+ file is ignored if $GIT_COMMON_DIR is set and
+ "$GIT_COMMON_DIR/shallow" will be used instead.
+
+commondir::
+ If this file exists, $GIT_COMMON_DIR (see linkgit:git[1]) will
+ be set to the path specified in this file if it is not
+ explicitly set. If the specified path is relative, it is
+ relative to $GIT_DIR. The repository with commondir is
+ incomplete without the repository pointed by "commondir".
+
+modules::
+ Contains the git-repositories of the submodules.
+
+worktrees::
+ Contains administrative data for linked
+ working trees. Each subdirectory contains the working tree-related
+ part of a linked working tree. This directory is ignored if
+ $GIT_COMMON_DIR is set, in which case
+ "$GIT_COMMON_DIR/worktrees" will be used instead.
+
+worktrees/<id>/gitdir::
+ A text file containing the absolute path back to the .git file
+ that points to here. This is used to check if the linked
+ repository has been manually removed and there is no need to
+ keep this directory any more. The mtime of this file should be
+ updated every time the linked repository is accessed.
+
+worktrees/<id>/locked::
+ If this file exists, the linked working tree may be on a
+ portable device and not available. The presence of this file
+ prevents `worktrees/<id>` from being pruned either automatically
+ or manually by `git worktree prune`. The file may contain a string
+ explaining why the repository is locked.
+
+worktrees/<id>/config.worktree::
+ Working directory specific configuration file.
+
+include::technical/repository-version.adoc[]
+
+SEE ALSO
+--------
+linkgit:git-init[1],
+linkgit:git-clone[1],
+linkgit:git-config[1],
+linkgit:git-fetch[1],
+linkgit:git-pack-refs[1],
+linkgit:git-gc[1],
+linkgit:git-checkout[1],
+linkgit:gitglossary[7],
+link:user-manual.html[The Git User's Manual]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitrevisions.adoc b/gitrevisions.adoc
new file mode 100644
index 0000000..7146117
--- /dev/null
+++ b/gitrevisions.adoc
@@ -0,0 +1,36 @@
+gitrevisions(7)
+===============
+
+NAME
+----
+gitrevisions - Specifying revisions and ranges for Git
+
+SYNOPSIS
+--------
+gitrevisions
+
+
+DESCRIPTION
+-----------
+
+Many Git commands take revision parameters as arguments. Depending on
+the command, they denote a specific commit or, for commands which
+walk the revision graph (such as linkgit:git-log[1]), all commits which are
+reachable from that commit. For commands that walk the revision graph one can
+also specify a range of revisions explicitly.
+
+In addition, some Git commands (such as linkgit:git-show[1] and
+linkgit:git-push[1]) can also take revision parameters which denote
+other objects than commits, e.g. blobs ("files") or trees
+("directories of files").
+
+include::revisions.adoc[]
+
+
+SEE ALSO
+--------
+linkgit:git-rev-parse[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitsubmodules.adoc b/gitsubmodules.adoc
new file mode 100644
index 0000000..f7b5a25
--- /dev/null
+++ b/gitsubmodules.adoc
@@ -0,0 +1,287 @@
+gitsubmodules(7)
+================
+
+NAME
+----
+gitsubmodules - Mounting one repository inside another
+
+SYNOPSIS
+--------
+ .gitmodules, $GIT_DIR/config
+------------------
+git submodule
+git <command> --recurse-submodules
+------------------
+
+DESCRIPTION
+-----------
+
+A submodule is a repository embedded inside another repository.
+The submodule has its own history; the repository it is embedded
+in is called a superproject.
+
+On the filesystem, a submodule usually (but not always - see FORMS below)
+consists of (i) a Git directory located under the `$GIT_DIR/modules/`
+directory of its superproject, (ii) a working directory inside the
+superproject's working directory, and a `.git` file at the root of
+the submodule's working directory pointing to (i).
+
+Assuming the submodule has a Git directory at `$GIT_DIR/modules/foo/`
+and a working directory at `path/to/bar/`, the superproject tracks the
+submodule via a `gitlink` entry in the tree at `path/to/bar` and an entry
+in its `.gitmodules` file (see linkgit:gitmodules[5]) of the form
+`submodule.foo.path = path/to/bar`.
+
+The `gitlink` entry contains the object name of the commit that the
+superproject expects the submodule's working directory to be at.
+
+The section `submodule.foo.*` in the `.gitmodules` file gives additional
+hints to Git's porcelain layer. For example, the `submodule.foo.url`
+setting specifies where to obtain the submodule.
+
+Submodules can be used for at least two different use cases:
+
+1. Using another project while maintaining independent history.
+ Submodules allow you to contain the working tree of another project
+ within your own working tree while keeping the history of both
+ projects separate. Also, since submodules are fixed to an arbitrary
+ version, the other project can be independently developed without
+ affecting the superproject, allowing the superproject project to
+ fix itself to new versions only when desired.
+
+2. Splitting a (logically single) project into multiple
+ repositories and tying them back together. This can be used to
+ overcome current limitations of Git's implementation to have
+ finer grained access:
+
+ * Size of the Git repository:
+ In its current form Git scales up poorly for large repositories containing
+ content that is not compressed by delta computation between trees.
+ For example, you can use submodules to hold large binary assets
+ and these repositories can be shallowly cloned such that you do not
+ have a large history locally.
+ * Transfer size:
+ In its current form Git requires the whole working tree present. It
+ does not allow partial trees to be transferred in fetch or clone.
+ If the project you work on consists of multiple repositories tied
+ together as submodules in a superproject, you can avoid fetching the
+ working trees of the repositories you are not interested in.
+ * Access control:
+ By restricting user access to submodules, this can be used to implement
+ read/write policies for different users.
+
+The configuration of submodules
+-------------------------------
+
+Submodule operations can be configured using the following mechanisms
+(from highest to lowest precedence):
+
+ * The command line for those commands that support taking submodules
+ as part of their pathspecs. Most commands have a boolean flag
+ `--recurse-submodules` which specifies whether to recurse into submodules.
+ Examples are `grep` and `checkout`.
+ Some commands take enums, such as `fetch` and `push`, where you can
+ specify how submodules are affected.
+
+ * The configuration inside the submodule. This includes `$GIT_DIR/config`
+ in the submodule, but also settings in the tree such as a `.gitattributes`
+ or `.gitignore` files that specify behavior of commands inside the
+ submodule.
++
+For example an effect from the submodule's `.gitignore` file
+would be observed when you run `git status --ignore-submodules=none` in
+the superproject. This collects information from the submodule's working
+directory by running `status` in the submodule while paying attention
+to the `.gitignore` file of the submodule.
++
+The submodule's `$GIT_DIR/config` file would come into play when running
+`git push --recurse-submodules=check` in the superproject, as this would
+check if the submodule has any changes not published to any remote. The
+remotes are configured in the submodule as usual in the `$GIT_DIR/config`
+file.
+
+ * The configuration file `$GIT_DIR/config` in the superproject.
+ Git only recurses into active submodules (see "ACTIVE SUBMODULES"
+ section below).
++
+If the submodule is not yet initialized, then the configuration
+inside the submodule does not exist yet, so where to
+obtain the submodule from is configured here for example.
+
+ * The `.gitmodules` file inside the superproject. A project usually
+ uses this file to suggest defaults for the upstream collection
+ of repositories for the mapping that is required between a
+ submodule's name and its path.
++
+This file mainly serves as the mapping between the name and path of submodules
+in the superproject, such that the submodule's Git directory can be
+located.
++
+If the submodule has never been initialized, this is the only place
+where submodule configuration is found. It serves as the last fallback
+to specify where to obtain the submodule from.
+
+FORMS
+-----
+
+Submodules can take the following forms:
+
+ * The basic form described in DESCRIPTION with a Git directory,
+a working directory, a `gitlink`, and a `.gitmodules` entry.
+
+ * "Old-form" submodule: A working directory with an embedded
+`.git` directory, and the tracking `gitlink` and `.gitmodules` entry in
+the superproject. This is typically found in repositories generated
+using older versions of Git.
++
+It is possible to construct these old form repositories manually.
++
+When deinitialized or deleted (see below), the submodule's Git
+directory is automatically moved to `$GIT_DIR/modules/<name>/`
+of the superproject.
+
+ * Deinitialized submodule: A `gitlink`, and a `.gitmodules` entry,
+but no submodule working directory. The submodule's Git directory
+may be there as after deinitializing the Git directory is kept around.
+The directory which is supposed to be the working directory is empty instead.
++
+A submodule can be deinitialized by running `git submodule deinit`.
+Besides emptying the working directory, this command only modifies
+the superproject's `$GIT_DIR/config` file, so the superproject's history
+is not affected. This can be undone using `git submodule init`.
+
+ * Deleted submodule: A submodule can be deleted by running
+`git rm <submodule-path> && git commit`. This can be undone
+using `git revert`.
++
+The deletion removes the superproject's tracking data, which are
+both the `gitlink` entry and the section in the `.gitmodules` file.
+The submodule's working directory is removed from the file
+system, but the Git directory is kept around as it to make it
+possible to checkout past commits without requiring fetching
+from another repository.
++
+To completely remove a submodule, manually delete
+`$GIT_DIR/modules/<name>/`.
+
+ACTIVE SUBMODULES
+-----------------
+
+A submodule is considered active,
+
+ 1. if `submodule.<name>.active` is set to `true`
++
+or
+
+ 2. if the submodule's path matches the pathspec in `submodule.active`
++
+or
+
+ 3. if `submodule.<name>.url` is set.
+
+and these are evaluated in this order.
+
+For example:
+
+ [submodule "foo"]
+ active = false
+ url = https://example.org/foo
+ [submodule "bar"]
+ active = true
+ url = https://example.org/bar
+ [submodule "baz"]
+ url = https://example.org/baz
+
+In the above config only the submodules 'bar' and 'baz' are active,
+'bar' due to (1) and 'baz' due to (3). 'foo' is inactive because
+(1) takes precedence over (3)
+
+Note that (3) is a historical artefact and will be ignored if the
+(1) and (2) specify that the submodule is not active. In other words,
+if we have a `submodule.<name>.active` set to `false` or if the
+submodule's path is excluded in the pathspec in `submodule.active`, the
+url doesn't matter whether it is present or not. This is illustrated in
+the example that follows.
+
+ [submodule "foo"]
+ active = true
+ url = https://example.org/foo
+ [submodule "bar"]
+ url = https://example.org/bar
+ [submodule "baz"]
+ url = https://example.org/baz
+ [submodule "bob"]
+ ignore = true
+ [submodule]
+ active = b*
+ active = :(exclude) baz
+
+In here all submodules except 'baz' (foo, bar, bob) are active.
+'foo' due to its own active flag and all the others due to the
+submodule active pathspec, which specifies that any submodule
+starting with 'b' except 'baz' are also active, regardless of the
+presence of the .url field.
+
+Workflow for a third party library
+----------------------------------
+
+ # Add a submodule
+ git submodule add <URL> <path>
+
+ # Occasionally update the submodule to a new version:
+ git -C <path> checkout <new-version>
+ git add <path>
+ git commit -m "update submodule to new version"
+
+ # See the list of submodules in a superproject
+ git submodule status
+
+ # See FORMS on removing submodules
+
+
+Workflow for an artificially split repo
+--------------------------------------
+
+ # Enable recursion for relevant commands, such that
+ # regular commands recurse into submodules by default
+ git config --global submodule.recurse true
+
+ # Unlike most other commands below, clone still needs
+ # its own recurse flag:
+ git clone --recurse <URL> <directory>
+ cd <directory>
+
+ # Get to know the code:
+ git grep foo
+ git ls-files --recurse-submodules
+
+[NOTE]
+`git ls-files` also requires its own `--recurse-submodules` flag.
+
+ # Get new code
+ git fetch
+ git pull --rebase
+
+ # Change worktree
+ git checkout
+ git reset
+
+Implementation details
+----------------------
+
+When cloning or pulling a repository containing submodules the submodules
+will not be checked out by default; you can instruct `clone` to recurse
+into submodules. The `init` and `update` subcommands of `git submodule`
+will maintain submodules checked out and at an appropriate revision in
+your working tree. Alternatively you can set `submodule.recurse` to have
+`checkout` recurse into submodules (note that `submodule.recurse` also
+affects other Git commands, see linkgit:git-config[1] for a complete list).
+
+
+SEE ALSO
+--------
+linkgit:git-submodule[1], linkgit:gitmodules[5].
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gittutorial-2.adoc b/gittutorial-2.adoc
new file mode 100644
index 0000000..8bdb7d0
--- /dev/null
+++ b/gittutorial-2.adoc
@@ -0,0 +1,436 @@
+gittutorial-2(7)
+================
+
+NAME
+----
+gittutorial-2 - A tutorial introduction to Git: part two
+
+SYNOPSIS
+--------
+[verse]
+git *
+
+DESCRIPTION
+-----------
+
+You should work through linkgit:gittutorial[7] before reading this tutorial.
+
+The goal of this tutorial is to introduce two fundamental pieces of
+Git's architecture--the object database and the index file--and to
+provide the reader with everything necessary to understand the rest
+of the Git documentation.
+
+The Git object database
+-----------------------
+
+Let's start a new project and create a small amount of history:
+
+------------------------------------------------
+$ mkdir test-project
+$ cd test-project
+$ git init
+Initialized empty Git repository in .git/
+$ echo 'hello world' > file.txt
+$ git add .
+$ git commit -a -m "initial commit"
+[master (root-commit) 54196cc] initial commit
+ 1 file changed, 1 insertion(+)
+ create mode 100644 file.txt
+$ echo 'hello world!' >file.txt
+$ git commit -a -m "add emphasis"
+[master c4d59f3] add emphasis
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+------------------------------------------------
+
+What are the 7 digits of hex that Git responded to the commit with?
+
+We saw in part one of the tutorial that commits have names like this.
+It turns out that every object in the Git history is stored under
+a 40-digit hex name. That name is the SHA-1 hash of the object's
+contents; among other things, this ensures that Git will never store
+the same data twice (since identical data is given an identical SHA-1
+name), and that the contents of a Git object will never change (since
+that would change the object's name as well). The 7 char hex strings
+here are simply the abbreviation of such 40 character long strings.
+Abbreviations can be used everywhere where the 40 character strings
+can be used, so long as they are unambiguous.
+
+It is expected that the content of the commit object you created while
+following the example above generates a different SHA-1 hash than
+the one shown above because the commit object records the time when
+it was created and the name of the person performing the commit.
+
+We can ask Git about this particular object with the `cat-file`
+command. Don't copy the 40 hex digits from this example but use those
+from your own version. Note that you can shorten it to only a few
+characters to save yourself typing all 40 hex digits:
+
+------------------------------------------------
+$ git cat-file -t 54196cc2
+commit
+$ git cat-file commit 54196cc2
+tree 92b8b694ffb1675e5975148e1121810081dbdffe
+author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
+committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
+
+initial commit
+------------------------------------------------
+
+A tree can refer to one or more "blob" objects, each corresponding to
+a file. In addition, a tree can also refer to other tree objects,
+thus creating a directory hierarchy. You can examine the contents of
+any tree using ls-tree (remember that a long enough initial portion
+of the SHA-1 will also work):
+
+------------------------------------------------
+$ git ls-tree 92b8b694
+100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad file.txt
+------------------------------------------------
+
+Thus we see that this tree has one file in it. The SHA-1 hash is a
+reference to that file's data:
+
+------------------------------------------------
+$ git cat-file -t 3b18e512
+blob
+------------------------------------------------
+
+A "blob" is just file data, which we can also examine with cat-file:
+
+------------------------------------------------
+$ git cat-file blob 3b18e512
+hello world
+------------------------------------------------
+
+Note that this is the old file data; so the object that Git named in
+its response to the initial tree was a tree with a snapshot of the
+directory state that was recorded by the first commit.
+
+All of these objects are stored under their SHA-1 names inside the Git
+directory:
+
+------------------------------------------------
+$ find .git/objects/
+.git/objects/
+.git/objects/pack
+.git/objects/info
+.git/objects/3b
+.git/objects/3b/18e512dba79e4c8300dd08aeb37f8e728b8dad
+.git/objects/92
+.git/objects/92/b8b694ffb1675e5975148e1121810081dbdffe
+.git/objects/54
+.git/objects/54/196cc2703dc165cbd373a65a4dcf22d50ae7f7
+.git/objects/a0
+.git/objects/a0/423896973644771497bdc03eb99d5281615b51
+.git/objects/d0
+.git/objects/d0/492b368b66bdabf2ac1fd8c92b39d3db916e59
+.git/objects/c4
+.git/objects/c4/d59f390b9cfd4318117afde11d601c1085f241
+------------------------------------------------
+
+and the contents of these files is just the compressed data plus a
+header identifying their length and their type. The type is either a
+blob, a tree, a commit, or a tag.
+
+The simplest commit to find is the HEAD commit, which we can find
+from .git/HEAD:
+
+------------------------------------------------
+$ cat .git/HEAD
+ref: refs/heads/master
+------------------------------------------------
+
+As you can see, this tells us which branch we're currently on, and it
+tells us this by naming a file under the .git directory, which itself
+contains a SHA-1 name referring to a commit object, which we can
+examine with cat-file:
+
+------------------------------------------------
+$ cat .git/refs/heads/master
+c4d59f390b9cfd4318117afde11d601c1085f241
+$ git cat-file -t c4d59f39
+commit
+$ git cat-file commit c4d59f39
+tree d0492b368b66bdabf2ac1fd8c92b39d3db916e59
+parent 54196cc2703dc165cbd373a65a4dcf22d50ae7f7
+author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143418702 -0500
+committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143418702 -0500
+
+add emphasis
+------------------------------------------------
+
+The "tree" object here refers to the new state of the tree:
+
+------------------------------------------------
+$ git ls-tree d0492b36
+100644 blob a0423896973644771497bdc03eb99d5281615b51 file.txt
+$ git cat-file blob a0423896
+hello world!
+------------------------------------------------
+
+and the "parent" object refers to the previous commit:
+
+------------------------------------------------
+$ git cat-file commit 54196cc2
+tree 92b8b694ffb1675e5975148e1121810081dbdffe
+author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
+committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
+
+initial commit
+------------------------------------------------
+
+The tree object is the tree we examined first, and this commit is
+unusual in that it lacks any parent.
+
+Most commits have only one parent, but it is also common for a commit
+to have multiple parents. In that case the commit represents a
+merge, with the parent references pointing to the heads of the merged
+branches.
+
+Besides blobs, trees, and commits, the only remaining type of object
+is a "tag", which we won't discuss here; refer to linkgit:git-tag[1]
+for details.
+
+So now we know how Git uses the object database to represent a
+project's history:
+
+ * "commit" objects refer to "tree" objects representing the
+ snapshot of a directory tree at a particular point in the
+ history, and refer to "parent" commits to show how they're
+ connected into the project history.
+ * "tree" objects represent the state of a single directory,
+ associating directory names to "blob" objects containing file
+ data and "tree" objects containing subdirectory information.
+ * "blob" objects contain file data without any other structure.
+ * References to commit objects at the head of each branch are
+ stored in files under .git/refs/heads/.
+ * The name of the current branch is stored in .git/HEAD.
+
+Note, by the way, that lots of commands take a tree as an argument.
+But as we can see above, a tree can be referred to in many different
+ways--by the SHA-1 name for that tree, by the name of a commit that
+refers to the tree, by the name of a branch whose head refers to that
+tree, etc.--and most such commands can accept any of these names.
+
+In command synopses, the word "tree-ish" is sometimes used to
+designate such an argument.
+
+The index file
+--------------
+
+The primary tool we've been using to create commits is `git-commit
+-a`, which creates a commit including every change you've made to
+your working tree. But what if you want to commit changes only to
+certain files? Or only certain changes to certain files?
+
+If we look at the way commits are created under the cover, we'll see
+that there are more flexible ways creating commits.
+
+Continuing with our test-project, let's modify file.txt again:
+
+------------------------------------------------
+$ echo "hello world, again" >>file.txt
+------------------------------------------------
+
+but this time instead of immediately making the commit, let's take an
+intermediate step, and ask for diffs along the way to keep track of
+what's happening:
+
+------------------------------------------------
+$ git diff
+--- a/file.txt
++++ b/file.txt
+@@ -1 +1,2 @@
+ hello world!
++hello world, again
+$ git add file.txt
+$ git diff
+------------------------------------------------
+
+The last diff is empty, but no new commits have been made, and the
+head still doesn't contain the new line:
+
+------------------------------------------------
+$ git diff HEAD
+diff --git a/file.txt b/file.txt
+index a042389..513feba 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1 +1,2 @@
+ hello world!
++hello world, again
+------------------------------------------------
+
+So 'git diff' is comparing against something other than the head.
+The thing that it's comparing against is actually the index file,
+which is stored in .git/index in a binary format, but whose contents
+we can examine with ls-files:
+
+------------------------------------------------
+$ git ls-files --stage
+100644 513feba2e53ebbd2532419ded848ba19de88ba00 0 file.txt
+$ git cat-file -t 513feba2
+blob
+$ git cat-file blob 513feba2
+hello world!
+hello world, again
+------------------------------------------------
+
+So what our 'git add' did was store a new blob and then put
+a reference to it in the index file. If we modify the file again,
+we'll see that the new modifications are reflected in the 'git diff'
+output:
+
+------------------------------------------------
+$ echo 'again?' >>file.txt
+$ git diff
+index 513feba..ba3da7b 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1,2 +1,3 @@
+ hello world!
+ hello world, again
++again?
+------------------------------------------------
+
+With the right arguments, 'git diff' can also show us the difference
+between the working directory and the last commit, or between the
+index and the last commit:
+
+------------------------------------------------
+$ git diff HEAD
+diff --git a/file.txt b/file.txt
+index a042389..ba3da7b 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1 +1,3 @@
+ hello world!
++hello world, again
++again?
+$ git diff --cached
+diff --git a/file.txt b/file.txt
+index a042389..513feba 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1 +1,2 @@
+ hello world!
++hello world, again
+------------------------------------------------
+
+At any time, we can create a new commit using 'git commit' (without
+the "-a" option), and verify that the state committed only includes the
+changes stored in the index file, not the additional change that is
+still only in our working tree:
+
+------------------------------------------------
+$ git commit -m "repeat"
+$ git diff HEAD
+diff --git a/file.txt b/file.txt
+index 513feba..ba3da7b 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1,2 +1,3 @@
+ hello world!
+ hello world, again
++again?
+------------------------------------------------
+
+So by default 'git commit' uses the index to create the commit, not
+the working tree; the "-a" option to commit tells it to first update
+the index with all changes in the working tree.
+
+Finally, it's worth looking at the effect of 'git add' on the index
+file:
+
+------------------------------------------------
+$ echo "goodbye, world" >closing.txt
+$ git add closing.txt
+------------------------------------------------
+
+The effect of the 'git add' was to add one entry to the index file:
+
+------------------------------------------------
+$ git ls-files --stage
+100644 8b9743b20d4b15be3955fc8d5cd2b09cd2336138 0 closing.txt
+100644 513feba2e53ebbd2532419ded848ba19de88ba00 0 file.txt
+------------------------------------------------
+
+And, as you can see with cat-file, this new entry refers to the
+current contents of the file:
+
+------------------------------------------------
+$ git cat-file blob 8b9743b2
+goodbye, world
+------------------------------------------------
+
+The "status" command is a useful way to get a quick summary of the
+situation:
+
+------------------------------------------------
+$ git status
+On branch master
+Changes to be committed:
+ (use "git restore --staged <file>..." to unstage)
+
+ new file: closing.txt
+
+Changes not staged for commit:
+ (use "git add <file>..." to update what will be committed)
+ (use "git restore <file>..." to discard changes in working directory)
+
+ modified: file.txt
+
+------------------------------------------------
+
+Since the current state of closing.txt is cached in the index file,
+it is listed as "Changes to be committed". Since file.txt has
+changes in the working directory that aren't reflected in the index,
+it is marked "changed but not updated". At this point, running "git
+commit" would create a commit that added closing.txt (with its new
+contents), but that didn't modify file.txt.
+
+Also, note that a bare `git diff` shows the changes to file.txt, but
+not the addition of closing.txt, because the version of closing.txt
+in the index file is identical to the one in the working directory.
+
+In addition to being the staging area for new commits, the index file
+is also populated from the object database when checking out a
+branch, and is used to hold the trees involved in a merge operation.
+See linkgit:gitcore-tutorial[7] and the relevant man
+pages for details.
+
+What next?
+----------
+
+At this point you should know everything necessary to read the man
+pages for any of the git commands; one good place to start would be
+with the commands mentioned in linkgit:giteveryday[7]. You
+should be able to find any unknown jargon in linkgit:gitglossary[7].
+
+The link:user-manual.html[Git User's Manual] provides a more
+comprehensive introduction to Git.
+
+linkgit:gitcvs-migration[7] explains how to
+import a CVS repository into Git, and shows how to use Git in a
+CVS-like way.
+
+For some interesting examples of Git use, see the
+link:howto-index.html[howtos].
+
+For Git developers, linkgit:gitcore-tutorial[7] goes
+into detail on the lower-level Git mechanisms involved in, for
+example, creating a new commit.
+
+SEE ALSO
+--------
+linkgit:gittutorial[7],
+linkgit:gitcvs-migration[7],
+linkgit:gitcore-tutorial[7],
+linkgit:gitglossary[7],
+linkgit:git-help[1],
+linkgit:giteveryday[7],
+link:user-manual.html[The Git User's Manual]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gittutorial.adoc b/gittutorial.adoc
new file mode 100644
index 0000000..f89ad30
--- /dev/null
+++ b/gittutorial.adoc
@@ -0,0 +1,676 @@
+gittutorial(7)
+==============
+
+NAME
+----
+gittutorial - A tutorial introduction to Git
+
+SYNOPSIS
+--------
+[verse]
+git *
+
+DESCRIPTION
+-----------
+
+This tutorial explains how to import a new project into Git, make
+changes to it, and share changes with other developers.
+
+If you are instead primarily interested in using Git to fetch a project,
+for example, to test the latest version, you may prefer to start with
+the first two chapters of link:user-manual.html[The Git User's Manual].
+
+First, note that you can get documentation for a command such as
+`git log --graph` with:
+
+------------------------------------------------
+$ man git-log
+------------------------------------------------
+
+or:
+
+------------------------------------------------
+$ git help log
+------------------------------------------------
+
+With the latter, you can use the manual viewer of your choice; see
+linkgit:git-help[1] for more information.
+
+It is a good idea to introduce yourself to Git with your name and
+public email address before doing any operation. The easiest
+way to do so is:
+
+------------------------------------------------
+$ git config --global user.name "Your Name Comes Here"
+$ git config --global user.email you@yourdomain.example.com
+------------------------------------------------
+
+
+Importing a new project
+-----------------------
+
+Assume you have a tarball `project.tar.gz` with your initial work. You
+can place it under Git revision control as follows.
+
+------------------------------------------------
+$ tar xzf project.tar.gz
+$ cd project
+$ git init
+------------------------------------------------
+
+Git will reply
+
+------------------------------------------------
+Initialized empty Git repository in .git/
+------------------------------------------------
+
+You've now initialized the working directory--you may notice a new
+directory created, named `.git`.
+
+Next, tell Git to take a snapshot of the contents of all files under the
+current directory (note the `.`), with `git add`:
+
+------------------------------------------------
+$ git add .
+------------------------------------------------
+
+This snapshot is now stored in a temporary staging area which Git calls
+the "index". You can permanently store the contents of the index in the
+repository with `git commit`:
+
+------------------------------------------------
+$ git commit
+------------------------------------------------
+
+This will prompt you for a commit message. You've now stored the first
+version of your project in Git.
+
+Making changes
+--------------
+
+Modify some files, then add their updated contents to the index:
+
+------------------------------------------------
+$ git add file1 file2 file3
+------------------------------------------------
+
+You are now ready to commit. You can see what is about to be committed
+using `git diff` with the `--cached` option:
+
+------------------------------------------------
+$ git diff --cached
+------------------------------------------------
+
+(Without `--cached`, `git diff` will show you any changes that
+you've made but not yet added to the index.) You can also get a brief
+summary of the situation with `git status`:
+
+------------------------------------------------
+$ git status
+On branch master
+Changes to be committed:
+ (use "git restore --staged <file>..." to unstage)
+
+ modified: file1
+ modified: file2
+ modified: file3
+
+------------------------------------------------
+
+If you need to make any further adjustments, do so now, and then add any
+newly modified content to the index. Finally, commit your changes with:
+
+------------------------------------------------
+$ git commit
+------------------------------------------------
+
+This will again prompt you for a message describing the change, and then
+record a new version of the project.
+
+Alternatively, instead of running `git add` beforehand, you can use
+
+------------------------------------------------
+$ git commit -a
+------------------------------------------------
+
+which will automatically notice any modified (but not new) files, add
+them to the index, and commit, all in one step.
+
+A note on commit messages: Though not required, it's a good idea to
+begin the commit message with a single short (no more than 50
+characters) line summarizing the change, followed by a blank line and
+then a more thorough description. The text up to the first blank line in
+a commit message is treated as the commit title, and that title is used
+throughout Git. For example, linkgit:git-format-patch[1] turns a
+commit into email, and it uses the title on the Subject line and the
+rest of the commit in the body.
+
+Git tracks content not files
+----------------------------
+
+Many revision control systems provide an `add` command that tells the
+system to start tracking changes to a new file. Git's `add` command
+does something simpler and more powerful: `git add` is used both for new
+and newly modified files, and in both cases it takes a snapshot of the
+given files and stages that content in the index, ready for inclusion in
+the next commit.
+
+Viewing project history
+-----------------------
+
+At any point you can view the history of your changes using
+
+------------------------------------------------
+$ git log
+------------------------------------------------
+
+If you also want to see complete diffs at each step, use
+
+------------------------------------------------
+$ git log -p
+------------------------------------------------
+
+Often the overview of the change is useful to get a feel of
+each step
+
+------------------------------------------------
+$ git log --stat --summary
+------------------------------------------------
+
+Managing branches
+-----------------
+
+A single Git repository can maintain multiple branches of
+development. To create a new branch named `experimental`, use
+
+------------------------------------------------
+$ git branch experimental
+------------------------------------------------
+
+If you now run
+
+------------------------------------------------
+$ git branch
+------------------------------------------------
+
+you'll get a list of all existing branches:
+
+------------------------------------------------
+ experimental
+* master
+------------------------------------------------
+
+The `experimental` branch is the one you just created, and the
+`master` branch is a default branch that was created for you
+automatically. The asterisk marks the branch you are currently on;
+type
+
+------------------------------------------------
+$ git switch experimental
+------------------------------------------------
+
+to switch to the `experimental` branch. Now edit a file, commit the
+change, and switch back to the `master` branch:
+
+------------------------------------------------
+(edit file)
+$ git commit -a
+$ git switch master
+------------------------------------------------
+
+Check that the change you made is no longer visible, since it was
+made on the `experimental` branch and you're back on the `master` branch.
+
+You can make a different change on the `master` branch:
+
+------------------------------------------------
+(edit file)
+$ git commit -a
+------------------------------------------------
+
+at this point the two branches have diverged, with different changes
+made in each. To merge the changes made in `experimental` into `master`, run
+
+------------------------------------------------
+$ git merge experimental
+------------------------------------------------
+
+If the changes don't conflict, you're done. If there are conflicts,
+markers will be left in the problematic files showing the conflict;
+
+------------------------------------------------
+$ git diff
+------------------------------------------------
+
+will show this. Once you've edited the files to resolve the
+conflicts,
+
+------------------------------------------------
+$ git commit -a
+------------------------------------------------
+
+will commit the result of the merge. Finally,
+
+------------------------------------------------
+$ gitk
+------------------------------------------------
+
+will show a nice graphical representation of the resulting history.
+
+At this point you could delete the `experimental` branch with
+
+------------------------------------------------
+$ git branch -d experimental
+------------------------------------------------
+
+This command ensures that the changes in the `experimental` branch are
+already in the current branch.
+
+If you develop on a branch `crazy-idea`, then regret it, you can always
+delete the branch with
+
+-------------------------------------
+$ git branch -D crazy-idea
+-------------------------------------
+
+Branches are cheap and easy, so this is a good way to try something
+out.
+
+Using Git for collaboration
+---------------------------
+
+Suppose that Alice has started a new project with a Git repository in
+`/home/alice/project`, and that Bob, who has a home directory on the
+same machine, wants to contribute.
+
+Bob begins with:
+
+------------------------------------------------
+bob$ git clone /home/alice/project myrepo
+------------------------------------------------
+
+This creates a new directory `myrepo` containing a clone of Alice's
+repository. The clone is on an equal footing with the original
+project, possessing its own copy of the original project's history.
+
+Bob then makes some changes and commits them:
+
+------------------------------------------------
+(edit files)
+bob$ git commit -a
+(repeat as necessary)
+------------------------------------------------
+
+When he's ready, he tells Alice to pull changes from the repository
+at `/home/bob/myrepo`. She does this with:
+
+------------------------------------------------
+alice$ cd /home/alice/project
+alice$ git pull /home/bob/myrepo master
+------------------------------------------------
+
+This merges the changes from Bob's `master` branch into Alice's
+current branch. If Alice has made her own changes in the meantime,
+then she may need to manually fix any conflicts.
+
+The `pull` command thus performs two operations: it fetches changes
+from a remote branch, then merges them into the current branch.
+
+Note that in general, Alice would want her local changes committed before
+initiating this `pull`. If Bob's work conflicts with what Alice did since
+their histories forked, Alice will use her working tree and the index to
+resolve conflicts, and existing local changes will interfere with the
+conflict resolution process (Git will still perform the fetch but will
+refuse to merge -- Alice will have to get rid of her local changes in
+some way and pull again when this happens).
+
+Alice can peek at what Bob did without merging first, using the `fetch`
+command; this allows Alice to inspect what Bob did, using a special
+symbol `FETCH_HEAD`, in order to determine if he has anything worth
+pulling, like this:
+
+------------------------------------------------
+alice$ git fetch /home/bob/myrepo master
+alice$ git log -p HEAD..FETCH_HEAD
+------------------------------------------------
+
+This operation is safe even if Alice has uncommitted local changes.
+The range notation `HEAD..FETCH_HEAD` means "show everything that is reachable
+from the `FETCH_HEAD` but exclude anything that is reachable from `HEAD`".
+Alice already knows everything that leads to her current state (`HEAD`),
+and reviews what Bob has in his state (`FETCH_HEAD`) that she has not
+seen with this command.
+
+If Alice wants to visualize what Bob did since their histories forked
+she can issue the following command:
+
+------------------------------------------------
+$ gitk HEAD..FETCH_HEAD
+------------------------------------------------
+
+This uses the same two-dot range notation we saw earlier with `git log`.
+
+Alice may want to view what both of them did since they forked.
+She can use three-dot form instead of the two-dot form:
+
+------------------------------------------------
+$ gitk HEAD...FETCH_HEAD
+------------------------------------------------
+
+This means "show everything that is reachable from either one, but
+exclude anything that is reachable from both of them".
+
+Please note that these range notations can be used with both `gitk`
+and `git log`.
+
+After inspecting what Bob did, if there is nothing urgent, Alice may
+decide to continue working without pulling from Bob. If Bob's history
+does have something Alice would immediately need, Alice may choose to
+stash her work-in-progress first, do a `pull`, and then finally unstash
+her work-in-progress on top of the resulting history.
+
+When you are working in a small closely knit group, it is not
+unusual to interact with the same repository over and over
+again. By defining 'remote' repository shorthand, you can make
+it easier:
+
+------------------------------------------------
+alice$ git remote add bob /home/bob/myrepo
+------------------------------------------------
+
+With this, Alice can perform the first part of the `pull` operation
+alone using the `git fetch` command without merging them with her own
+branch, using:
+
+-------------------------------------
+alice$ git fetch bob
+-------------------------------------
+
+Unlike the longhand form, when Alice fetches from Bob using a
+remote repository shorthand set up with `git remote`, what was
+fetched is stored in a remote-tracking branch, in this case
+`bob/master`. So after this:
+
+-------------------------------------
+alice$ git log -p master..bob/master
+-------------------------------------
+
+shows a list of all the changes that Bob made since he branched from
+Alice's `master` branch.
+
+After examining those changes, Alice
+could merge the changes into her `master` branch:
+
+-------------------------------------
+alice$ git merge bob/master
+-------------------------------------
+
+This `merge` can also be done by 'pulling from her own remote-tracking
+branch', like this:
+
+-------------------------------------
+alice$ git pull . remotes/bob/master
+-------------------------------------
+
+Note that git pull always merges into the current branch,
+regardless of what else is given on the command line.
+
+Later, Bob can update his repo with Alice's latest changes using
+
+-------------------------------------
+bob$ git pull
+-------------------------------------
+
+Note that he doesn't need to give the path to Alice's repository;
+when Bob cloned Alice's repository, Git stored the location of her
+repository in the repository configuration, and that location is
+used for pulls:
+
+-------------------------------------
+bob$ git config --get remote.origin.url
+/home/alice/project
+-------------------------------------
+
+(The complete configuration created by `git clone` is visible using
+`git config -l`, and the linkgit:git-config[1] man page
+explains the meaning of each option.)
+
+Git also keeps a pristine copy of Alice's `master` branch under the
+name `origin/master`:
+
+-------------------------------------
+bob$ git branch -r
+ origin/master
+-------------------------------------
+
+If Bob later decides to work from a different host, he can still
+perform clones and pulls using the ssh protocol:
+
+-------------------------------------
+bob$ git clone alice.org:/home/alice/project myrepo
+-------------------------------------
+
+Alternatively, Git has a native protocol, or can use http;
+see linkgit:git-pull[1] for details.
+
+Git can also be used in a CVS-like mode, with a central repository
+that various users push changes to; see linkgit:git-push[1] and
+linkgit:gitcvs-migration[7].
+
+Exploring history
+-----------------
+
+Git history is represented as a series of interrelated commits. We
+have already seen that the `git log` command can list those commits.
+Note that first line of each `git log` entry also gives a name for the
+commit:
+
+-------------------------------------
+$ git log
+commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
+Author: Junio C Hamano <junkio@cox.net>
+Date: Tue May 16 17:18:22 2006 -0700
+
+ merge-base: Clarify the comments on post processing.
+-------------------------------------
+
+We can give this name to `git show` to see the details about this
+commit.
+
+-------------------------------------
+$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
+-------------------------------------
+
+But there are other ways to refer to commits. You can use any initial
+part of the name that is long enough to uniquely identify the commit:
+
+-------------------------------------
+$ git show c82a22c39c # the first few characters of the name are
+ # usually enough
+$ git show HEAD # the tip of the current branch
+$ git show experimental # the tip of the "experimental" branch
+-------------------------------------
+
+Every commit usually has one "parent" commit
+which points to the previous state of the project:
+
+-------------------------------------
+$ git show HEAD^ # to see the parent of HEAD
+$ git show HEAD^^ # to see the grandparent of HEAD
+$ git show HEAD~4 # to see the great-great grandparent of HEAD
+-------------------------------------
+
+Note that merge commits may have more than one parent:
+
+-------------------------------------
+$ git show HEAD^1 # show the first parent of HEAD (same as HEAD^)
+$ git show HEAD^2 # show the second parent of HEAD
+-------------------------------------
+
+You can also give commits names of your own; after running
+
+-------------------------------------
+$ git tag v2.5 1b2e1d63ff
+-------------------------------------
+
+you can refer to `1b2e1d63ff` by the name `v2.5`. If you intend to
+share this name with other people (for example, to identify a release
+version), you should create a "tag" object, and perhaps sign it; see
+linkgit:git-tag[1] for details.
+
+Any Git command that needs to know a commit can take any of these
+names. For example:
+
+-------------------------------------
+$ git diff v2.5 HEAD # compare the current HEAD to v2.5
+$ git branch stable v2.5 # start a new branch named "stable" based
+ # at v2.5
+$ git reset --hard HEAD^ # reset your current branch and working
+ # directory to its state at HEAD^
+-------------------------------------
+
+Be careful with that last command: in addition to losing any changes
+in the working directory, it will also remove all later commits from
+this branch. If this branch is the only branch containing those
+commits, they will be lost. Also, don't use `git reset` on a
+publicly-visible branch that other developers pull from, as it will
+force needless merges on other developers to clean up the history.
+If you need to undo changes that you have pushed, use `git revert`
+instead.
+
+The `git grep` command can search for strings in any version of your
+project, so
+
+-------------------------------------
+$ git grep "hello" v2.5
+-------------------------------------
+
+searches for all occurrences of "hello" in `v2.5`.
+
+If you leave out the commit name, `git grep` will search any of the
+files it manages in your current directory. So
+
+-------------------------------------
+$ git grep "hello"
+-------------------------------------
+
+is a quick way to search just the files that are tracked by Git.
+
+Many Git commands also take sets of commits, which can be specified
+in a number of ways. Here are some examples with `git log`:
+
+-------------------------------------
+$ git log v2.5..v2.6 # commits between v2.5 and v2.6
+$ git log v2.5.. # commits since v2.5
+$ git log --since="2 weeks ago" # commits from the last 2 weeks
+$ git log v2.5.. Makefile # commits since v2.5 which modify
+ # Makefile
+-------------------------------------
+
+You can also give `git log` a "range" of commits where the first is not
+necessarily an ancestor of the second; for example, if the tips of
+the branches `stable` and `master` diverged from a common
+commit some time ago, then
+
+-------------------------------------
+$ git log stable..master
+-------------------------------------
+
+will list commits made in the `master` branch but not in the
+stable branch, while
+
+-------------------------------------
+$ git log master..stable
+-------------------------------------
+
+will show the list of commits made on the stable branch but not
+the `master` branch.
+
+The `git log` command has a weakness: it must present commits in a
+list. When the history has lines of development that diverged and
+then merged back together, the order in which `git log` presents
+those commits is meaningless.
+
+Most projects with multiple contributors (such as the Linux kernel,
+or Git itself) have frequent merges, and `gitk` does a better job of
+visualizing their history. For example,
+
+-------------------------------------
+$ gitk --since="2 weeks ago" drivers/
+-------------------------------------
+
+allows you to browse any commits from the last 2 weeks of commits
+that modified files under the `drivers` directory. (Note: you can
+adjust gitk's fonts by holding down the control key while pressing
+"-" or "+".)
+
+Finally, most commands that take filenames will optionally allow you
+to precede any filename by a commit, to specify a particular version
+of the file:
+
+-------------------------------------
+$ git diff v2.5:Makefile HEAD:Makefile.in
+-------------------------------------
+
+You can also use `git show` to see any such file:
+
+-------------------------------------
+$ git show v2.5:Makefile
+-------------------------------------
+
+Next Steps
+----------
+
+This tutorial should be enough to perform basic distributed revision
+control for your projects. However, to fully understand the depth
+and power of Git you need to understand two simple ideas on which it
+is based:
+
+ * The object database is the rather elegant system used to
+ store the history of your project--files, directories, and
+ commits.
+
+ * The index file is a cache of the state of a directory tree,
+ used to create commits, check out working directories, and
+ hold the various trees involved in a merge.
+
+Part two of this tutorial explains the object
+database, the index file, and a few other odds and ends that you'll
+need to make the most of Git. You can find it at linkgit:gittutorial-2[7].
+
+If you don't want to continue with that right away, a few other
+digressions that may be interesting at this point are:
+
+ * linkgit:git-format-patch[1], linkgit:git-am[1]: These convert
+ series of git commits into emailed patches, and vice versa,
+ useful for projects such as the Linux kernel which rely heavily
+ on emailed patches.
+
+ * linkgit:git-bisect[1]: When there is a regression in your
+ project, one way to track down the bug is by searching through
+ the history to find the exact commit that's to blame. `git bisect`
+ can help you perform a binary search for that commit. It is
+ smart enough to perform a close-to-optimal search even in the
+ case of complex non-linear history with lots of merged branches.
+
+ * linkgit:gitworkflows[7]: Gives an overview of recommended
+ workflows.
+
+ * linkgit:giteveryday[7]: Everyday Git with 20 Commands Or So.
+
+ * linkgit:gitcvs-migration[7]: Git for CVS users.
+
+SEE ALSO
+--------
+linkgit:gittutorial-2[7],
+linkgit:gitcvs-migration[7],
+linkgit:gitcore-tutorial[7],
+linkgit:gitglossary[7],
+linkgit:git-help[1],
+linkgit:gitworkflows[7],
+linkgit:giteveryday[7],
+link:user-manual.html[The Git User's Manual]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitweb.adoc b/gitweb.adoc
new file mode 100644
index 0000000..5e2b491
--- /dev/null
+++ b/gitweb.adoc
@@ -0,0 +1,703 @@
+gitweb(1)
+=========
+
+NAME
+----
+gitweb - Git web interface (web frontend to Git repositories)
+
+SYNOPSIS
+--------
+To get started with gitweb, run linkgit:git-instaweb[1] from a Git repository.
+This will configure and start your web server, and run a web browser pointing to
+gitweb.
+
+
+DESCRIPTION
+-----------
+Gitweb provides a web interface to Git repositories. Its features include:
+
+* Viewing multiple Git repositories with common root.
+* Browsing every revision of the repository.
+* Viewing the contents of files in the repository at any revision.
+* Viewing the revision log of branches, history of files and directories,
+ seeing what was changed, when, and by whom.
+* Viewing the blame/annotation details of any file (if enabled).
+* Generating RSS and Atom feeds of commits, for any branch.
+ The feeds are auto-discoverable in modern web browsers.
+* Viewing everything that was changed in a revision, and stepping through
+ revisions one at a time, viewing the history of the repository.
+* Finding commits whose commit messages match a given search term.
+
+See https://repo.or.cz/w/git.git/tree/HEAD:/gitweb/[] for gitweb source code,
+browsed using gitweb itself.
+
+
+CONFIGURATION
+-------------
+Various aspects of gitweb's behavior can be controlled through the configuration
+file `gitweb_config.perl` or `/etc/gitweb.conf`. See the linkgit:gitweb.conf[5]
+for details.
+
+Repositories
+~~~~~~~~~~~~
+Gitweb can show information from one or more Git repositories. These
+repositories have to be all on local filesystem, and have to share a common
+repository root, i.e. be all under a single parent repository (but see also
+the "Advanced web server setup" section, "Webserver configuration with multiple
+projects' root" subsection).
+
+-----------------------------------------------------------------------
+our $projectroot = '/path/to/parent/directory';
+-----------------------------------------------------------------------
+
+The default value for `$projectroot` is `/pub/git`. You can change it during
+building gitweb via the `GITWEB_PROJECTROOT` build configuration variable.
+
+By default all Git repositories under `$projectroot` are visible and available
+to gitweb. The list of projects is generated by default by scanning the
+`$projectroot` directory for Git repositories (for object databases to be
+more exact; gitweb is not interested in a working area, and is best suited
+to showing "bare" repositories).
+
+The name of the repository in gitweb is the path to its `$GIT_DIR` (its object
+database) relative to `$projectroot`. Therefore the repository $repo can be
+found at "$projectroot/$repo".
+
+
+Projects list file format
+~~~~~~~~~~~~~~~~~~~~~~~~~
+Instead of having gitweb find repositories by scanning the filesystem
+starting from $projectroot, you can provide a pre-generated list of
+visible projects by setting `$projects_list` to point to a plain text
+file with a list of projects (with some additional info).
+
+This file uses the following format:
+
+* One record (for project / repository) per line; does not support line
+continuation (newline escaping).
+
+* Leading and trailing whitespace are ignored.
+
+* Whitespace separated fields; any run of whitespace can be used as field
+separator (rules for Perl's "`split(" ", $line)`").
+
+* Fields use modified URI encoding, defined in RFC 3986, section 2.1
+(Percent-Encoding), or rather "Query string encoding" (see
+https://en.wikipedia.org/wiki/Query_string#URL_encoding[]), the difference
+being that SP (" ") can be encoded as "{plus}" (and therefore "{plus}" has to be
+also percent-encoded).
++
+Reserved characters are: "%" (used for encoding), "{plus}" (can be used to
+encode SPACE), all whitespace characters as defined in Perl, including SP,
+TAB and LF, (used to separate fields in a record).
+
+* Currently recognized fields are:
+<repository path>::
+ path to repository GIT_DIR, relative to `$projectroot`
+<repository owner>::
+ displayed as repository owner, preferably full name, or email,
+ or both
+
+You can generate the projects list index file using the project_index action
+(the 'TXT' link on projects list page) directly from gitweb; see also
+"Generating projects list using gitweb" section below.
+
+Example contents:
+-----------------------------------------------------------------------
+foo.git Joe+R+Hacker+<joe@example.com>
+foo/bar.git O+W+Ner+<owner@example.org>
+-----------------------------------------------------------------------
+
+
+By default this file controls only which projects are *visible* on projects
+list page (note that entries that do not point to correctly recognized Git
+repositories won't be displayed by gitweb). Even if a project is not
+visible on projects list page, you can view it nevertheless by hand-crafting
+a gitweb URL. By setting `$strict_export` configuration variable (see
+linkgit:gitweb.conf[5]) to true value you can allow viewing only of
+repositories also shown on the overview page (i.e. only projects explicitly
+listed in projects list file will be accessible).
+
+
+Generating projects list using gitweb
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+We assume that GITWEB_CONFIG has its default Makefile value, namely
+'gitweb_config.perl'. Put the following in 'gitweb_make_index.perl' file:
+----------------------------------------------------------------------------
+read_config_file("gitweb_config.perl");
+$projects_list = $projectroot;
+----------------------------------------------------------------------------
+
+Then create the following script to get list of project in the format
+suitable for GITWEB_LIST build configuration variable (or
+`$projects_list` variable in gitweb config):
+
+----------------------------------------------------------------------------
+#!/bin/sh
+
+export GITWEB_CONFIG="gitweb_make_index.perl"
+export GATEWAY_INTERFACE="CGI/1.1"
+export HTTP_ACCEPT="*/*"
+export REQUEST_METHOD="GET"
+export QUERY_STRING="a=project_index"
+
+perl -- /var/www/cgi-bin/gitweb.cgi
+----------------------------------------------------------------------------
+
+Run this script and save its output to a file. This file could then be used
+as projects list file, which means that you can set `$projects_list` to its
+filename.
+
+
+Controlling access to Git repositories
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+By default all Git repositories under `$projectroot` are visible and
+available to gitweb. You can however configure how gitweb controls access
+to repositories.
+
+* As described in "Projects list file format" section, you can control which
+projects are *visible* by selectively including repositories in projects
+list file, and setting `$projects_list` gitweb configuration variable to
+point to it. With `$strict_export` set, projects list file can be used to
+control which repositories are *available* as well.
+
+* You can configure gitweb to only list and allow viewing of the explicitly
+exported repositories, via `$export_ok` variable in gitweb config file; see
+linkgit:gitweb.conf[5] manpage. If it evaluates to true, gitweb shows
+repositories only if this file named by `$export_ok` exists in its object
+database (if directory has the magic file named `$export_ok`).
++
+For example linkgit:git-daemon[1] by default (unless `--export-all` option
+is used) allows pulling only for those repositories that have
+'git-daemon-export-ok' file. Adding
++
+--------------------------------------------------------------------------
+our $export_ok = "git-daemon-export-ok";
+--------------------------------------------------------------------------
++
+makes gitweb show and allow access only to those repositories that can be
+fetched from via `git://` protocol.
+
+* Finally, it is possible to specify an arbitrary perl subroutine that will
+be called for each repository to determine if it can be exported. The
+subroutine receives an absolute path to the project (repository) as its only
+parameter (i.e. "$projectroot/$project").
++
+For example, if you use mod_perl to run the script, and have dumb
+HTTP protocol authentication configured for your repositories, you
+can use the following hook to allow access only if the user is
+authorized to read the files:
++
+--------------------------------------------------------------------------
+$export_auth_hook = sub {
+ use Apache2::SubRequest ();
+ use Apache2::Const -compile => qw(HTTP_OK);
+ my $path = "$_[0]/HEAD";
+ my $r = Apache2::RequestUtil->request;
+ my $sub = $r->lookup_file($path);
+ return $sub->filename eq $path
+ && $sub->status == Apache2::Const::HTTP_OK;
+};
+--------------------------------------------------------------------------
+
+
+Per-repository gitweb configuration
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+You can configure individual repositories shown in gitweb by creating file
+in the `GIT_DIR` of Git repository, or by setting some repo configuration
+variable (in `GIT_DIR/config`, see linkgit:git-config[1]).
+
+You can use the following files in repository:
+
+README.html::
+ A html file (HTML fragment) which is included on the gitweb project
+ "summary" page inside `<div>` block element. You can use it for longer
+ description of a project, to provide links (for example to project's
+ homepage), etc. This is recognized only if XSS prevention is off
+ (`$prevent_xss` is false, see linkgit:gitweb.conf[5]); a way to include
+ a README safely when XSS prevention is on may be worked out in the
+ future.
+
+description (or `gitweb.description`)::
+ Short (shortened to `$projects_list_description_width` in the projects
+ list page, which is 25 characters by default; see
+ linkgit:gitweb.conf[5]) single line description of a project (of a
+ repository). Plain text file; HTML will be escaped. By default set to
++
+-------------------------------------------------------------------------------
+Unnamed repository; edit this file to name it for gitweb.
+-------------------------------------------------------------------------------
++
+from the template during repository creation, usually installed in
+`/usr/share/git-core/templates/`. You can use the `gitweb.description` repo
+configuration variable, but the file takes precedence.
+
+category (or `gitweb.category`)::
+ Single line category of a project, used to group projects if
+ `$projects_list_group_categories` is enabled. By default (file and
+ configuration variable absent), uncategorized projects are put in the
+ `$project_list_default_category` category. You can use the
+ `gitweb.category` repo configuration variable, but the file takes
+ precedence.
++
+The configuration variables `$projects_list_group_categories` and
+`$project_list_default_category` are described in linkgit:gitweb.conf[5]
+
+cloneurl (or multiple-valued `gitweb.url`)::
+ File with repository URL (used for clone and fetch), one per line.
+ Displayed in the project summary page. You can use multiple-valued
+ `gitweb.url` repository configuration variable for that, but the file
+ takes precedence.
++
+This is per-repository enhancement / version of global prefix-based
+`@git_base_url_list` gitweb configuration variable (see
+linkgit:gitweb.conf[5]).
+
+gitweb.owner::
+ You can use the `gitweb.owner` repository configuration variable to set
+ repository's owner. It is displayed in the project list and summary
+ page.
++
+If it's not set, filesystem directory's owner is used (via GECOS field,
+i.e. real name field from *getpwuid*(3)) if `$projects_list` is unset
+(gitweb scans `$projectroot` for repositories); if `$projects_list`
+points to file with list of repositories, then project owner defaults to
+value from this file for given repository.
+
+various `gitweb.*` config variables (in config)::
+ Read description of `%feature` hash for detailed list, and descriptions.
+ See also "Configuring gitweb features" section in linkgit:gitweb.conf[5]
+
+
+ACTIONS, AND URLS
+-----------------
+Gitweb can use path_info (component) based URLs, or it can pass all necessary
+information via query parameters. The typical gitweb URLs are broken down in to
+five components:
+
+-----------------------------------------------------------------------
+.../gitweb.cgi/<repo>/<action>/<revision>:/<path>?<arguments>
+-----------------------------------------------------------------------
+
+repo::
+ The repository the action will be performed on.
++
+All actions except for those that list all available projects,
+in whatever form, require this parameter.
+
+action::
+ The action that will be run. Defaults to 'projects_list' if repo
+ is not set, and to 'summary' otherwise.
+
+revision::
+ Revision shown. Defaults to HEAD.
+
+path::
+ The path within the <repository> that the action is performed on,
+ for those actions that require it.
+
+arguments::
+ Any arguments that control the behaviour of the action.
+
+Some actions require or allow to specify two revisions, and sometimes even two
+pathnames. In most general form such path_info (component) based gitweb URL
+looks like this:
+
+-----------------------------------------------------------------------
+.../gitweb.cgi/<repo>/<action>/<revision-from>:/<path-from>..<revision-to>:/<path-to>?<arguments>
+-----------------------------------------------------------------------
+
+
+Each action is implemented as a subroutine, and must be present in %actions
+hash. Some actions are disabled by default, and must be turned on via feature
+mechanism. For example to enable 'blame' view add the following to gitweb
+configuration file:
+
+-----------------------------------------------------------------------
+$feature{'blame'}{'default'} = [1];
+-----------------------------------------------------------------------
+
+
+Actions:
+~~~~~~~~
+The standard actions are:
+
+project_list::
+ Lists the available Git repositories. This is the default command if no
+ repository is specified in the URL.
+
+summary::
+ Displays summary about given repository. This is the default command if
+ no action is specified in URL, and only repository is specified.
+
+heads::
+remotes::
+ Lists all local or all remote-tracking branches in given repository.
++
+The latter is not available by default, unless configured.
+
+tags::
+ List all tags (lightweight and annotated) in given repository.
+
+blob::
+tree::
+ Shows the files and directories in a given repository path, at given
+ revision. This is default command if no action is specified in the URL,
+ and path is given.
+
+blob_plain::
+ Returns the raw data for the file in given repository, at given path and
+ revision. Links to this action are marked 'raw'.
+
+blobdiff::
+ Shows the difference between two revisions of the same file.
+
+blame::
+blame_incremental::
+ Shows the blame (also called annotation) information for a file. On a
+ per line basis it shows the revision in which that line was last changed
+ and the user that committed the change. The incremental version (which
+ if configured is used automatically when JavaScript is enabled) uses
+ Ajax to incrementally add blame info to the contents of given file.
++
+This action is disabled by default for performance reasons.
+
+commit::
+commitdiff::
+ Shows information about a specific commit in a repository. The 'commit'
+ view shows information about commit in more detail, the 'commitdiff'
+ action shows changeset for given commit.
+
+patch::
+ Returns the commit in plain text mail format, suitable for applying with
+ linkgit:git-am[1].
+
+tag::
+ Display specific annotated tag (tag object).
+
+log::
+shortlog::
+ Shows log information (commit message or just commit subject) for a
+ given branch (starting from given revision).
++
+The 'shortlog' view is more compact; it shows one commit per line.
+
+history::
+ Shows history of the file or directory in a given repository path,
+ starting from given revision (defaults to HEAD, i.e. default branch).
++
+This view is similar to 'shortlog' view.
+
+rss::
+atom::
+ Generates an RSS (or Atom) feed of changes to repository.
+
+
+WEBSERVER CONFIGURATION
+-----------------------
+This section explains how to configure some common webservers to run gitweb. In
+all cases, `/path/to/gitweb` in the examples is the directory you ran installed
+gitweb in, and contains `gitweb_config.perl`.
+
+If you've configured a web server that isn't listed here for gitweb, please send
+in the instructions so they can be included in a future release.
+
+Apache as CGI
+~~~~~~~~~~~~~
+Apache must be configured to support CGI scripts in the directory in
+which gitweb is installed. Let's assume that it is `/var/www/cgi-bin`
+directory.
+
+-----------------------------------------------------------------------
+ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
+
+<Directory "/var/www/cgi-bin">
+ Options Indexes FollowSymlinks ExecCGI
+ AllowOverride None
+ Order allow,deny
+ Allow from all
+</Directory>
+-----------------------------------------------------------------------
+
+With that configuration the full path to browse repositories would be:
+
+ http://server/cgi-bin/gitweb.cgi
+
+Apache with mod_perl, via ModPerl::Registry
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+You can use mod_perl with gitweb. You must install Apache::Registry
+(for mod_perl 1.x) or ModPerl::Registry (for mod_perl 2.x) to enable
+this support.
+
+Assuming that gitweb is installed to `/var/www/perl`, the following
+Apache configuration (for mod_perl 2.x) is suitable.
+
+-----------------------------------------------------------------------
+Alias /perl "/var/www/perl"
+
+<Directory "/var/www/perl">
+ SetHandler perl-script
+ PerlResponseHandler ModPerl::Registry
+ PerlOptions +ParseHeaders
+ Options Indexes FollowSymlinks +ExecCGI
+ AllowOverride None
+ Order allow,deny
+ Allow from all
+</Directory>
+-----------------------------------------------------------------------
+
+With that configuration the full path to browse repositories would be:
+
+ http://server/perl/gitweb.cgi
+
+Apache with FastCGI
+~~~~~~~~~~~~~~~~~~~
+Gitweb works with Apache and FastCGI. First you need to rename, copy
+or symlink gitweb.cgi to gitweb.fcgi. Let's assume that gitweb is
+installed in `/usr/share/gitweb` directory. The following Apache
+configuration is suitable (UNTESTED!)
+
+-----------------------------------------------------------------------
+FastCgiServer /usr/share/gitweb/gitweb.cgi
+ScriptAlias /gitweb /usr/share/gitweb/gitweb.cgi
+
+Alias /gitweb/static /usr/share/gitweb/static
+<Directory /usr/share/gitweb/static>
+ SetHandler default-handler
+</Directory>
+-----------------------------------------------------------------------
+
+With that configuration the full path to browse repositories would be:
+
+ http://server/gitweb
+
+
+ADVANCED WEB SERVER SETUP
+-------------------------
+All of those examples use request rewriting, and need `mod_rewrite`
+(or equivalent; examples below are written for Apache).
+
+Single URL for gitweb and for fetching
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+If you want to have one URL for both gitweb and your `http://`
+repositories, you can configure Apache like this:
+
+-----------------------------------------------------------------------
+<VirtualHost *:80>
+ ServerName git.example.org
+ DocumentRoot /pub/git
+ SetEnv GITWEB_CONFIG /etc/gitweb.conf
+
+ # turning on mod rewrite
+ RewriteEngine on
+
+ # make the front page an internal rewrite to the gitweb script
+ RewriteRule ^/$ /cgi-bin/gitweb.cgi
+
+ # make access for "dumb clients" work
+ RewriteRule ^/(.*\.git/(?!/?(HEAD|info|objects|refs)).*)?$ \
+ /cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT]
+</VirtualHost>
+-----------------------------------------------------------------------
+
+The above configuration expects your public repositories to live under
+`/pub/git` and will serve them as `http://git.domain.org/dir-under-pub-git`,
+both as clonable Git URL and as browsable gitweb interface. If you then
+start your linkgit:git-daemon[1] with `--base-path=/pub/git --export-all`
+then you can even use the `git://` URL with exactly the same path.
+
+Setting the environment variable `GITWEB_CONFIG` will tell gitweb to use the
+named file (i.e. in this example `/etc/gitweb.conf`) as a configuration for
+gitweb. You don't really need it in above example; it is required only if
+your configuration file is in different place than built-in (during
+compiling gitweb) 'gitweb_config.perl' or `/etc/gitweb.conf`. See
+linkgit:gitweb.conf[5] for details, especially information about precedence
+rules.
+
+If you use the rewrite rules from the example you *might* also need
+something like the following in your gitweb configuration file
+(`/etc/gitweb.conf` following example):
+----------------------------------------------------------------------------
+@stylesheets = ("/some/absolute/path/gitweb.css");
+$my_uri = "/";
+$home_link = "/";
+$per_request_config = 1;
+----------------------------------------------------------------------------
+Nowadays though gitweb should create HTML base tag when needed (to set base
+URI for relative links), so it should work automatically.
+
+
+Webserver configuration with multiple projects' root
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+If you want to use gitweb with several project roots you can edit your
+Apache virtual host and gitweb configuration files in the following way.
+
+The virtual host configuration (in Apache configuration file) should look
+like this:
+--------------------------------------------------------------------------
+<VirtualHost *:80>
+ ServerName git.example.org
+ DocumentRoot /pub/git
+ SetEnv GITWEB_CONFIG /etc/gitweb.conf
+
+ # turning on mod rewrite
+ RewriteEngine on
+
+ # make the front page an internal rewrite to the gitweb script
+ RewriteRule ^/$ /cgi-bin/gitweb.cgi [QSA,L,PT]
+
+ # look for a public_git directory in unix users' home
+ # http://git.example.org/~<user>/
+ RewriteRule ^/\~([^\/]+)(/|/gitweb.cgi)?$ /cgi-bin/gitweb.cgi \
+ [QSA,E=GITWEB_PROJECTROOT:/home/$1/public_git/,L,PT]
+
+ # http://git.example.org/+<user>/
+ #RewriteRule ^/\+([^\/]+)(/|/gitweb.cgi)?$ /cgi-bin/gitweb.cgi \
+ [QSA,E=GITWEB_PROJECTROOT:/home/$1/public_git/,L,PT]
+
+ # http://git.example.org/user/<user>/
+ #RewriteRule ^/user/([^\/]+)/(gitweb.cgi)?$ /cgi-bin/gitweb.cgi \
+ [QSA,E=GITWEB_PROJECTROOT:/home/$1/public_git/,L,PT]
+
+ # defined list of project roots
+ RewriteRule ^/scm(/|/gitweb.cgi)?$ /cgi-bin/gitweb.cgi \
+ [QSA,E=GITWEB_PROJECTROOT:/pub/scm/,L,PT]
+ RewriteRule ^/var(/|/gitweb.cgi)?$ /cgi-bin/gitweb.cgi \
+ [QSA,E=GITWEB_PROJECTROOT:/var/git/,L,PT]
+
+ # make access for "dumb clients" work
+ RewriteRule ^/(.*\.git/(?!/?(HEAD|info|objects|refs)).*)?$ \
+ /cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT]
+</VirtualHost>
+--------------------------------------------------------------------------
+
+Here actual project root is passed to gitweb via `GITWEB_PROJECT_ROOT`
+environment variable from a web server, so you need to put the following
+line in gitweb configuration file (`/etc/gitweb.conf` in above example):
+--------------------------------------------------------------------------
+$projectroot = $ENV{'GITWEB_PROJECTROOT'} || "/pub/git";
+--------------------------------------------------------------------------
+*Note* that this requires to be set for each request, so either
+`$per_request_config` must be false, or the above must be put in code
+referenced by `$per_request_config`;
+
+These configurations enable two things. First, each unix user (`<user>`) of
+the server will be able to browse through gitweb Git repositories found in
+`~/public_git/` with the following url:
+
+ http://git.example.org/~<user>/
+
+If you do not want this feature on your server just remove the second
+rewrite rule.
+
+If you already use `mod_userdir` in your virtual host or you don't want to
+use the \'~' as first character, just comment or remove the second rewrite
+rule, and uncomment one of the following according to what you want.
+
+Second, repositories found in `/pub/scm/` and `/var/git/` will be accessible
+through `http://git.example.org/scm/` and `http://git.example.org/var/`.
+You can add as many project roots as you want by adding rewrite rules like
+the third and the fourth.
+
+
+PATH_INFO usage
+~~~~~~~~~~~~~~~
+If you enable PATH_INFO usage in gitweb by putting
+----------------------------------------------------------------------------
+$feature{'pathinfo'}{'default'} = [1];
+----------------------------------------------------------------------------
+in your gitweb configuration file, it is possible to set up your server so
+that it consumes and produces URLs in the form
+
+ http://git.example.com/project.git/shortlog/sometag
+
+i.e. without 'gitweb.cgi' part, by using a configuration such as the
+following. This configuration assumes that `/var/www/gitweb` is the
+DocumentRoot of your webserver, contains the gitweb.cgi script and
+complementary static files (stylesheet, favicon, JavaScript):
+
+----------------------------------------------------------------------------
+<VirtualHost *:80>
+ ServerAlias git.example.com
+
+ DocumentRoot /var/www/gitweb
+
+ <Directory /var/www/gitweb>
+ Options ExecCGI
+ AddHandler cgi-script cgi
+
+ DirectoryIndex gitweb.cgi
+
+ RewriteEngine On
+ RewriteCond %{REQUEST_FILENAME} !-f
+ RewriteCond %{REQUEST_FILENAME} !-d
+ RewriteRule ^.* /gitweb.cgi/$0 [L,PT]
+ </Directory>
+</VirtualHost>
+----------------------------------------------------------------------------
+The rewrite rule guarantees that existing static files will be properly
+served, whereas any other URL will be passed to gitweb as PATH_INFO
+parameter.
+
+*Notice* that in this case you don't need special settings for
+`@stylesheets`, `$my_uri` and `$home_link`, but you lose "dumb client"
+access to your project .git dirs (described in "Single URL for gitweb and
+for fetching" section). A possible workaround for the latter is the
+following: in your project root dir (e.g. `/pub/git`) have the projects
+named *without* a .git extension (e.g. `/pub/git/project` instead of
+`/pub/git/project.git`) and configure Apache as follows:
+----------------------------------------------------------------------------
+<VirtualHost *:80>
+ ServerAlias git.example.com
+
+ DocumentRoot /var/www/gitweb
+
+ AliasMatch ^(/.*?)(\.git)(/.*)?$ /pub/git$1$3
+ <Directory /var/www/gitweb>
+ Options ExecCGI
+ AddHandler cgi-script cgi
+
+ DirectoryIndex gitweb.cgi
+
+ RewriteEngine On
+ RewriteCond %{REQUEST_FILENAME} !-f
+ RewriteCond %{REQUEST_FILENAME} !-d
+ RewriteRule ^.* /gitweb.cgi/$0 [L,PT]
+ </Directory>
+</VirtualHost>
+----------------------------------------------------------------------------
+
+The additional AliasMatch makes it so that
+
+ http://git.example.com/project.git
+
+will give raw access to the project's Git dir (so that the project can be
+cloned), while
+
+ http://git.example.com/project
+
+will provide human-friendly gitweb access.
+
+This solution is not 100% bulletproof, in the sense that if some project has
+a named ref (branch, tag) starting with `git/`, then paths such as
+
+ http://git.example.com/project/command/abranch..git/abranch
+
+will fail with a 404 error.
+
+
+BUGS
+----
+Please report any bugs or feature requests to git@vger.kernel.org,
+putting "gitweb" in the subject of email.
+
+SEE ALSO
+--------
+linkgit:gitweb.conf[5], linkgit:git-instaweb[1]
+
+`gitweb/README`, `gitweb/INSTALL`
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitweb.conf.adoc b/gitweb.conf.adoc
new file mode 100644
index 0000000..8598358
--- /dev/null
+++ b/gitweb.conf.adoc
@@ -0,0 +1,981 @@
+gitweb.conf(5)
+==============
+
+NAME
+----
+gitweb.conf - Gitweb (Git web interface) configuration file
+
+SYNOPSIS
+--------
+/etc/gitweb.conf, /etc/gitweb-common.conf, $GITWEBDIR/gitweb_config.perl
+
+DESCRIPTION
+-----------
+
+The gitweb CGI script for viewing Git repositories over the web uses a
+perl script fragment as its configuration file. You can set variables
+using "`our $variable = value`"; text from a "#" character until the
+end of a line is ignored. See *perlsyn*(1) for details.
+
+An example:
+
+------------------------------------------------
+# gitweb configuration file for http://git.example.org
+#
+our $projectroot = "/srv/git"; # FHS recommendation
+our $site_name = 'Example.org >> Repos';
+------------------------------------------------
+
+
+The configuration file is used to override the default settings that
+were built into gitweb at the time the 'gitweb.cgi' script was generated.
+
+While one could just alter the configuration settings in the gitweb
+CGI itself, those changes would be lost upon upgrade. Configuration
+settings might also be placed into a file in the same directory as the
+CGI script with the default name 'gitweb_config.perl' -- allowing
+one to have multiple gitweb instances with different configurations by
+the use of symlinks.
+
+Note that some configuration can be controlled on per-repository rather than
+gitweb-wide basis: see "Per-repository gitweb configuration" subsection on
+linkgit:gitweb[1] manpage.
+
+
+DISCUSSION
+----------
+Gitweb reads configuration data from the following sources in the
+following order:
+
+ * built-in values (some set during build stage),
+
+ * common system-wide configuration file (defaults to
+ `/etc/gitweb-common.conf`),
+
+ * either per-instance configuration file (defaults to 'gitweb_config.perl'
+ in the same directory as the installed gitweb), or if it does not exist
+ then fallback system-wide configuration file (defaults to `/etc/gitweb.conf`).
+
+Values obtained in later configuration files override values obtained earlier
+in the above sequence.
+
+Locations of the common system-wide configuration file, the fallback
+system-wide configuration file and the per-instance configuration file
+are defined at compile time using build-time Makefile configuration
+variables, respectively `GITWEB_CONFIG_COMMON`, `GITWEB_CONFIG_SYSTEM`
+and `GITWEB_CONFIG`.
+
+You can also override locations of gitweb configuration files during
+runtime by setting the following environment variables:
+`GITWEB_CONFIG_COMMON`, `GITWEB_CONFIG_SYSTEM` and `GITWEB_CONFIG`
+to a non-empty value.
+
+
+The syntax of the configuration files is that of Perl, since these files are
+handled by sourcing them as fragments of Perl code (the language that
+gitweb itself is written in). Variables are typically set using the
+`our` qualifier (as in "`our $variable = <value>;`") to avoid syntax
+errors if a new version of gitweb no longer uses a variable and therefore
+stops declaring it.
+
+You can include other configuration file using read_config_file()
+subroutine. For example, one might want to put gitweb configuration
+related to access control for viewing repositories via Gitolite (one
+of Git repository management tools) in a separate file, e.g. in
+`/etc/gitweb-gitolite.conf`. To include it, put
+
+--------------------------------------------------
+read_config_file("/etc/gitweb-gitolite.conf");
+--------------------------------------------------
+
+somewhere in gitweb configuration file used, e.g. in per-installation
+gitweb configuration file. Note that read_config_file() checks itself
+that the file it reads exists, and does nothing if it is not found.
+It also handles errors in included file.
+
+
+The default configuration with no configuration file at all may work
+perfectly well for some installations. Still, a configuration file is
+useful for customizing or tweaking the behavior of gitweb in many ways, and
+some optional features will not be present unless explicitly enabled using
+the configurable `%features` variable (see also "Configuring gitweb
+features" section below).
+
+
+CONFIGURATION VARIABLES
+-----------------------
+Some configuration variables have their default values (embedded in the CGI
+script) set during building gitweb -- if that is the case, this fact is put
+in their description. See gitweb's 'INSTALL' file for instructions on building
+and installing gitweb.
+
+
+Location of repositories
+~~~~~~~~~~~~~~~~~~~~~~~~
+The configuration variables described below control how gitweb finds
+Git repositories, and how repositories are displayed and accessed.
+
+See also "Repositories" and later subsections in linkgit:gitweb[1] manpage.
+
+$projectroot::
+ Absolute filesystem path which will be prepended to project path;
+ the path to repository is `$projectroot/$project`. Set to
+ `$GITWEB_PROJECTROOT` during installation. This variable has to be
+ set correctly for gitweb to find repositories.
++
+For example, if `$projectroot` is set to "/srv/git" by putting the following
+in gitweb config file:
++
+----------------------------------------------------------------------------
+our $projectroot = "/srv/git";
+----------------------------------------------------------------------------
++
+then
++
+------------------------------------------------
+http://git.example.com/gitweb.cgi?p=foo/bar.git
+------------------------------------------------
++
+and its path_info based equivalent
++
+------------------------------------------------
+http://git.example.com/gitweb.cgi/foo/bar.git
+------------------------------------------------
++
+will map to the path `/srv/git/foo/bar.git` on the filesystem.
+
+$projects_list::
+ Name of a plain text file listing projects, or a name of directory
+ to be scanned for projects.
++
+Project list files should list one project per line, with each line
+having the following format
++
+-----------------------------------------------------------------------------
+<URI-encoded filesystem path to repository> SP <URI-encoded repository owner>
+-----------------------------------------------------------------------------
++
+The default value of this variable is determined by the `GITWEB_LIST`
+makefile variable at installation time. If this variable is empty, gitweb
+will fall back to scanning the `$projectroot` directory for repositories.
+
+$project_maxdepth::
+ If `$projects_list` variable is unset, gitweb will recursively
+ scan filesystem for Git repositories. The `$project_maxdepth`
+ is used to limit traversing depth, relative to `$projectroot`
+ (starting point); it means that directories which are further
+ from `$projectroot` than `$project_maxdepth` will be skipped.
++
+It is purely performance optimization, originally intended for MacOS X,
+where recursive directory traversal is slow. Gitweb follows symbolic
+links, but it detects cycles, ignoring any duplicate files and directories.
++
+The default value of this variable is determined by the build-time
+configuration variable `GITWEB_PROJECT_MAXDEPTH`, which defaults to
+2007.
+
+$export_ok::
+ Show repository only if this file exists (in repository). Only
+ effective if this variable evaluates to true. Can be set when
+ building gitweb by setting `GITWEB_EXPORT_OK`. This path is
+ relative to `GIT_DIR`. git-daemon[1] uses 'git-daemon-export-ok',
+ unless started with `--export-all`. By default this variable is
+ not set, which means that this feature is turned off.
+
+$export_auth_hook::
+ Function used to determine which repositories should be shown.
+ This subroutine should take one parameter, the full path to
+ a project, and if it returns true, that project will be included
+ in the projects list and can be accessed through gitweb as long
+ as it fulfills the other requirements described by $export_ok,
+ $projects_list, and $projects_maxdepth. Example:
++
+----------------------------------------------------------------------------
+our $export_auth_hook = sub { return -e "$_[0]/git-daemon-export-ok"; };
+----------------------------------------------------------------------------
++
+though the above might be done by using `$export_ok` instead
++
+----------------------------------------------------------------------------
+our $export_ok = "git-daemon-export-ok";
+----------------------------------------------------------------------------
++
+If not set (default), it means that this feature is disabled.
++
+See also more involved example in "Controlling access to Git repositories"
+subsection on linkgit:gitweb[1] manpage.
+
+$strict_export::
+ Only allow viewing of repositories also shown on the overview page.
+ This for example makes `$export_ok` file decide if repository is
+ available and not only if it is shown. If `$projects_list` points to
+ file with list of project, only those repositories listed would be
+ available for gitweb. Can be set during building gitweb via
+ `GITWEB_STRICT_EXPORT`. By default this variable is not set, which
+ means that you can directly access those repositories that are hidden
+ from projects list page (e.g. the are not listed in the $projects_list
+ file).
+
+
+Finding files
+~~~~~~~~~~~~~
+The following configuration variables tell gitweb where to find files.
+The values of these variables are paths on the filesystem.
+
+$GIT::
+ Core git executable to use. By default set to `$GIT_BINDIR/git`, which
+ in turn is by default set to `$(bindir)/git`. If you use Git installed
+ from a binary package, you should usually set this to "/usr/bin/git".
+ This can just be "git" if your web server has a sensible PATH; from
+ security point of view it is better to use absolute path to git binary.
+ If you have multiple Git versions installed it can be used to choose
+ which one to use. Must be (correctly) set for gitweb to be able to
+ work.
+
+$mimetypes_file::
+ File to use for (filename extension based) guessing of MIME types before
+ trying `/etc/mime.types`. *NOTE* that this path, if relative, is taken
+ as relative to the current Git repository, not to CGI script. If unset,
+ only `/etc/mime.types` is used (if present on filesystem). If no mimetypes
+ file is found, mimetype guessing based on extension of file is disabled.
+ Unset by default.
+
+$highlight_bin::
+ Path to the highlight executable to use (it must be the one from
+ http://andre-simon.de/zip/download.php[] due to assumptions about parameters and output).
+ By default set to 'highlight'; set it to full path to highlight
+ executable if it is not installed on your web server's PATH.
+ Note that 'highlight' feature must be set for gitweb to actually
+ use syntax highlighting.
++
+*NOTE*: for a file to be highlighted, its syntax type must be detected
+and that syntax must be supported by "highlight". The default syntax
+detection is minimal, and there are many supported syntax types with no
+detection by default. There are three options for adding syntax
+detection. The first and second priority are `%highlight_basename` and
+`%highlight_ext`, which detect based on basename (the full filename, for
+example "Makefile") and extension (for example "sh"). The keys of these
+hashes are the basename and extension, respectively, and the value for a
+given key is the name of the syntax to be passed via `--syntax <syntax>`
+to "highlight". The last priority is the "highlight" configuration of
+`Shebang` regular expressions to detect the language based on the first
+line in the file, (for example, matching the line "#!/bin/bash"). See
+the highlight documentation and the default config at
+/etc/highlight/filetypes.conf for more details.
++
+For example if repositories you are hosting use "phtml" extension for
+PHP files, and you want to have correct syntax-highlighting for those
+files, you can add the following to gitweb configuration:
++
+---------------------------------------------------------
+our %highlight_ext;
+$highlight_ext{'phtml'} = 'php';
+---------------------------------------------------------
+
+
+Links and their targets
+~~~~~~~~~~~~~~~~~~~~~~~
+The configuration variables described below configure some of gitweb links:
+their target and their look (text or image), and where to find page
+prerequisites (stylesheet, favicon, images, scripts). Usually they are left
+at their default values, with the possible exception of `@stylesheets`
+variable.
+
+@stylesheets::
+ List of URIs of stylesheets (relative to the base URI of a page). You
+ might specify more than one stylesheet, for example to use "gitweb.css"
+ as base with site specific modifications in a separate stylesheet
+ to make it easier to upgrade gitweb. For example, you can add
+ a `site` stylesheet by putting
++
+----------------------------------------------------------------------------
+push @stylesheets, "gitweb-site.css";
+----------------------------------------------------------------------------
++
+in the gitweb config file. Those values that are relative paths are
+relative to base URI of gitweb.
++
+This list should contain the URI of gitweb's standard stylesheet. The default
+URI of gitweb stylesheet can be set at build time using the `GITWEB_CSS`
+makefile variable. Its default value is `static/gitweb.css`
+(or `static/gitweb.min.css` if the `CSSMIN` variable is defined,
+i.e. if CSS minifier is used during build).
++
+*Note*: there is also a legacy `$stylesheet` configuration variable, which was
+used by older gitweb. If `$stylesheet` variable is defined, only CSS stylesheet
+given by this variable is used by gitweb.
+
+$logo::
+ Points to the location where you put 'git-logo.png' on your web
+ server, or to be more the generic URI of logo, 72x27 size). This image
+ is displayed in the top right corner of each gitweb page and used as
+ a logo for the Atom feed. Relative to the base URI of gitweb (as a path).
+ Can be adjusted when building gitweb using `GITWEB_LOGO` variable
+ By default set to `static/git-logo.png`.
+
+$favicon::
+ Points to the location where you put 'git-favicon.png' on your web
+ server, or to be more the generic URI of favicon, which will be served
+ as "image/png" type. Web browsers that support favicons (website icons)
+ may display them in the browser's URL bar and next to the site name in
+ bookmarks. Relative to the base URI of gitweb. Can be adjusted at
+ build time using `GITWEB_FAVICON` variable.
+ By default set to `static/git-favicon.png`.
+
+$javascript::
+ Points to the location where you put 'gitweb.js' on your web server,
+ or to be more generic the URI of JavaScript code used by gitweb.
+ Relative to the base URI of gitweb. Can be set at build time using
+ the `GITWEB_JS` build-time configuration variable.
++
+The default value is either `static/gitweb.js`, or `static/gitweb.min.js` if
+the `JSMIN` build variable was defined, i.e. if JavaScript minifier was used
+at build time. *Note* that this single file is generated from multiple
+individual JavaScript "modules".
+
+$home_link::
+ Target of the home link on the top of all pages (the first part of view
+ "breadcrumbs"). By default it is set to the absolute URI of a current page
+ (to the value of `$my_uri` variable, or to "/" if `$my_uri` is undefined
+ or is an empty string).
+
+$home_link_str::
+ Label for the "home link" at the top of all pages, leading to `$home_link`
+ (usually the main gitweb page, which contains the projects list). It is
+ used as the first component of gitweb's "breadcrumb trail":
+ `<home-link> / <project> / <action>`. Can be set at build time using
+ the `GITWEB_HOME_LINK_STR` variable. By default it is set to "projects",
+ as this link leads to the list of projects. Another popular choice is to
+ set it to the name of site. Note that it is treated as raw HTML so it
+ should not be set from untrusted sources.
+
+@extra_breadcrumbs::
+ Additional links to be added to the start of the breadcrumb trail before
+ the home link, to pages that are logically "above" the gitweb projects
+ list, such as the organization and department which host the gitweb
+ server. Each element of the list is a reference to an array, in which
+ element 0 is the link text (equivalent to `$home_link_str`) and element
+ 1 is the target URL (equivalent to `$home_link`).
++
+For example, the following setting produces a breadcrumb trail like
+"home / dev / projects / ..." where "projects" is the home link.
++
+----------------------------------------------------------------------------
+ our @extra_breadcrumbs = (
+ [ 'home' => 'https://www.example.org/' ],
+ [ 'dev' => 'https://dev.example.org/' ],
+ );
+----------------------------------------------------------------------------
+
+$logo_url::
+$logo_label::
+ URI and label (title) for the Git logo link (or your site logo,
+ if you chose to use different logo image). By default, these both
+ refer to Git homepage, https://git-scm.com[]; in the past, they pointed
+ to Git documentation at https://www.kernel.org[].
+
+
+Changing gitweb's look
+~~~~~~~~~~~~~~~~~~~~~~
+You can adjust how pages generated by gitweb look using the variables described
+below. You can change the site name, add common headers and footers for all
+pages, and add a description of this gitweb installation on its main page
+(which is the projects list page), etc.
+
+$site_name::
+ Name of your site or organization, to appear in page titles. Set it
+ to something descriptive for clearer bookmarks etc. If this variable
+ is not set or is, then gitweb uses the value of the `SERVER_NAME`
+ `CGI` environment variable, setting site name to "$SERVER_NAME Git",
+ or "Untitled Git" if this variable is not set (e.g. if running gitweb
+ as standalone script).
++
+Can be set using the `GITWEB_SITENAME` at build time. Unset by default.
+
+$site_html_head_string::
+ HTML snippet to be included in the <head> section of each page.
+ Can be set using `GITWEB_SITE_HTML_HEAD_STRING` at build time.
+ No default value.
+
+$site_header::
+ Name of a file with HTML to be included at the top of each page.
+ Relative to the directory containing the 'gitweb.cgi' script.
+ Can be set using `GITWEB_SITE_HEADER` at build time. No default
+ value.
+
+$site_footer::
+ Name of a file with HTML to be included at the bottom of each page.
+ Relative to the directory containing the 'gitweb.cgi' script.
+ Can be set using `GITWEB_SITE_FOOTER` at build time. No default
+ value.
+
+$home_text::
+ Name of a HTML file which, if it exists, is included on the
+ gitweb projects overview page ("projects_list" view). Relative to
+ the directory containing the gitweb.cgi script. Default value
+ can be adjusted during build time using `GITWEB_HOMETEXT` variable.
+ By default set to 'indextext.html'.
+
+$projects_list_description_width::
+ The width (in characters) of the "Description" column of the projects list.
+ Longer descriptions will be truncated (trying to cut at word boundary);
+ the full description is available in the 'title' attribute (usually shown on
+ mouseover). The default is 25, which might be too small if you
+ use long project descriptions.
+
+$default_projects_order::
+ Default value of ordering of projects on projects list page, which
+ means the ordering used if you don't explicitly sort projects list
+ (if there is no "o" CGI query parameter in the URL). Valid values
+ are "none" (unsorted), "project" (projects are by project name,
+ i.e. path to repository relative to `$projectroot`), "descr"
+ (project description), "owner", and "age" (by date of most current
+ commit).
++
+Default value is "project". Unknown value means unsorted.
+
+
+Changing gitweb's behavior
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+These configuration variables control _internal_ gitweb behavior.
+
+$default_blob_plain_mimetype::
+ Default mimetype for the blob_plain (raw) view, if mimetype checking
+ doesn't result in some other type; by default "text/plain".
+ Gitweb guesses mimetype of a file to display based on extension
+ of its filename, using `$mimetypes_file` (if set and file exists)
+ and `/etc/mime.types` files (see *mime.types*(5) manpage; only
+ filename extension rules are supported by gitweb).
+
+$default_text_plain_charset::
+ Default charset for text files. If this is not set, the web server
+ configuration will be used. Unset by default.
+
+$fallback_encoding::
+ Gitweb assumes this charset when a line contains non-UTF-8 characters.
+ The fallback decoding is used without error checking, so it can be even
+ "utf-8". The value must be a valid encoding; see the *Encoding::Supported*(3pm)
+ man page for a list. The default is "latin1", aka. "iso-8859-1".
+
+@diff_opts::
+ Rename detection options for git-diff and git-diff-tree. The default is
+ (\'-M'); set it to (\'-C') or (\'-C', \'-C') to also detect copies,
+ or set it to () i.e. empty list if you don't want to have renames
+ detection.
++
+*Note* that rename and especially copy detection can be quite
+CPU-intensive. Note also that non Git tools can have problems with
+patches generated with options mentioned above, especially when they
+involve file copies (\'-C') or criss-cross renames (\'-B').
+
+
+Some optional features and policies
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Most of features are configured via `%feature` hash; however some of extra
+gitweb features can be turned on and configured using variables described
+below. This list beside configuration variables that control how gitweb
+looks does contain variables configuring administrative side of gitweb
+(e.g. cross-site scripting prevention; admittedly this as side effect
+affects how "summary" pages look like, or load limiting).
+
+@git_base_url_list::
+ List of Git base URLs. These URLs are used to generate URLs
+ describing from where to fetch a project, which are shown on
+ project summary page. The full fetch URL is "`$git_base_url/$project`",
+ for each element of this list. You can set up multiple base URLs
+ (for example one for `git://` protocol, and one for `http://`
+ protocol).
++
+Note that per repository configuration can be set in `$GIT_DIR/cloneurl`
+file, or as values of multi-value `gitweb.url` configuration variable in
+project config. Per-repository configuration takes precedence over value
+composed from `@git_base_url_list` elements and project name.
++
+You can setup one single value (single entry/item in this list) at build
+time by setting the `GITWEB_BASE_URL` build-time configuration variable.
+By default it is set to (), i.e. an empty list. This means that gitweb
+would not try to create project URL (to fetch) from project name.
+
+$projects_list_group_categories::
+ Whether to enable the grouping of projects by category on the project
+ list page. The category of a project is determined by the
+ `$GIT_DIR/category` file or the `gitweb.category` variable in each
+ repository's configuration. Disabled by default (set to 0).
+
+$project_list_default_category::
+ Default category for projects for which none is specified. If this is
+ set to the empty string, such projects will remain uncategorized and
+ listed at the top, above categorized projects. Used only if project
+ categories are enabled, which means if `$projects_list_group_categories`
+ is true. By default set to "" (empty string).
+
+$prevent_xss::
+ If true, some gitweb features are disabled to prevent content in
+ repositories from launching cross-site scripting (XSS) attacks. Set this
+ to true if you don't trust the content of your repositories.
+ False by default (set to 0).
+
+$maxload::
+ Used to set the maximum load that we will still respond to gitweb queries.
+ If the server load exceeds this value then gitweb will return
+ "503 Service Unavailable" error. The server load is taken to be 0
+ if gitweb cannot determine its value. Currently it works only on Linux,
+ where it uses `/proc/loadavg`; the load there is the number of active
+ tasks on the system -- processes that are actually running -- averaged
+ over the last minute.
++
+Set `$maxload` to undefined value (`undef`) to turn this feature off.
+The default value is 300.
+
+$omit_age_column::
+ If true, omit the column with date of the most current commit on the
+ projects list page. It can save a bit of I/O and a fork per repository.
+
+$omit_owner::
+ If true prevents displaying information about repository owner.
+
+$per_request_config::
+ If this is set to code reference, it will be run once for each request.
+ You can set parts of configuration that change per session this way.
+ For example, one might use the following code in a gitweb configuration
+ file
++
+--------------------------------------------------------------------------------
+our $per_request_config = sub {
+ $ENV{GL_USER} = $cgi->remote_user || "gitweb";
+};
+--------------------------------------------------------------------------------
++
+If `$per_request_config` is not a code reference, it is interpreted as boolean
+value. If it is true gitweb will process config files once per request,
+and if it is false gitweb will process config files only once, each time it
+is executed. True by default (set to 1).
++
+*NOTE*: `$my_url`, `$my_uri`, and `$base_url` are overwritten with their default
+values before every request, so if you want to change them, be sure to set
+this variable to true or a code reference effecting the desired changes.
++
+This variable matters only when using persistent web environments that
+serve multiple requests using single gitweb instance, like mod_perl,
+FastCGI or Plackup.
+
+
+Other variables
+~~~~~~~~~~~~~~~
+Usually you should not need to change (adjust) any of configuration
+variables described below; they should be automatically set by gitweb to
+correct value.
+
+
+$version::
+ Gitweb version, set automatically when creating gitweb.cgi from
+ gitweb.perl. You might want to modify it if you are running modified
+ gitweb, for example
++
+---------------------------------------------------
+our $version .= " with caching";
+---------------------------------------------------
++
+if you run modified version of gitweb with caching support. This variable
+is purely informational, used e.g. in the "generator" meta header in HTML
+header.
+
+$my_url::
+$my_uri::
+ Full URL and absolute URL of the gitweb script;
+ in earlier versions of gitweb you might have need to set those
+ variables, but now there should be no need to do it. See
+ `$per_request_config` if you need to set them still.
+
+$base_url::
+ Base URL for relative URLs in pages generated by gitweb,
+ (e.g. `$logo`, `$favicon`, `@stylesheets` if they are relative URLs),
+ needed and used '<base href="$base_url">' only for URLs with nonempty
+ PATH_INFO. Usually gitweb sets its value correctly,
+ and there is no need to set this variable, e.g. to $my_uri or "/".
+ See `$per_request_config` if you need to override it anyway.
+
+
+CONFIGURING GITWEB FEATURES
+---------------------------
+Many gitweb features can be enabled (or disabled) and configured using the
+`%feature` hash. Names of gitweb features are keys of this hash.
+
+Each `%feature` hash element is a hash reference and has the following
+structure:
+----------------------------------------------------------------------
+"<feature-name>" => {
+ "sub" => <feature-sub-(subroutine)>,
+ "override" => <allow-override-(boolean)>,
+ "default" => [ <options>... ]
+},
+----------------------------------------------------------------------
+Some features cannot be overridden per project. For those
+features the structure of appropriate `%feature` hash element has a simpler
+form:
+----------------------------------------------------------------------
+"<feature-name>" => {
+ "override" => 0,
+ "default" => [ <options>... ]
+},
+----------------------------------------------------------------------
+As one can see it lacks the \'sub' element.
+
+The meaning of each part of feature configuration is described
+below:
+
+default::
+ List (array reference) of feature parameters (if there are any),
+ used also to toggle (enable or disable) given feature.
++
+Note that it is currently *always* an array reference, even if
+feature doesn't accept any configuration parameters, and \'default'
+is used only to turn it on or off. In such case you turn feature on
+by setting this element to `[1]`, and torn it off by setting it to
+`[0]`. See also the passage about the "blame" feature in the "Examples"
+section.
++
+To disable features that accept parameters (are configurable), you
+need to set this element to empty list i.e. `[]`.
+
+override::
+ If this field has a true value then the given feature is
+ overridable, which means that it can be configured
+ (or enabled/disabled) on a per-repository basis.
++
+Usually given "<feature>" is configurable via the `gitweb.<feature>`
+config variable in the per-repository Git configuration file.
++
+*Note* that no feature is overridable by default.
+
+sub::
+ Internal detail of implementation. What is important is that
+ if this field is not present then per-repository override for
+ given feature is not supported.
++
+You wouldn't need to ever change it in gitweb config file.
+
+
+Features in `%feature`
+~~~~~~~~~~~~~~~~~~~~~~
+The gitweb features that are configurable via `%feature` hash are listed
+below. This should be a complete list, but ultimately the authoritative
+and complete list is in gitweb.cgi source code, with features described
+in the comments.
+
+blame::
+ Enable the "blame" and "blame_incremental" blob views, showing for
+ each line the last commit that modified it; see linkgit:git-blame[1].
+ This can be very CPU-intensive and is therefore disabled by default.
++
+This feature can be configured on a per-repository basis via
+repository's `gitweb.blame` configuration variable (boolean).
+
+snapshot::
+ Enable and configure the "snapshot" action, which allows user to
+ download a compressed archive of any tree or commit, as produced
+ by linkgit:git-archive[1] and possibly additionally compressed.
+ This can potentially generate high traffic if you have large project.
++
+The value of \'default' is a list of names of snapshot formats,
+defined in `%known_snapshot_formats` hash, that you wish to offer.
+Supported formats include "tgz", "tbz2", "txz" (gzip/bzip2/xz
+compressed tar archive) and "zip"; please consult gitweb sources for
+a definitive list. By default only "tgz" is offered.
++
+This feature can be configured on a per-repository basis via
+repository's `gitweb.snapshot` configuration variable, which contains
+a comma separated list of formats or "none" to disable snapshots.
+Unknown values are ignored.
+
+grep::
+ Enable grep search, which lists the files in currently selected
+ tree (directory) containing the given string; see linkgit:git-grep[1].
+ This can be potentially CPU-intensive, of course. Enabled by default.
++
+This feature can be configured on a per-repository basis via
+repository's `gitweb.grep` configuration variable (boolean).
+
+pickaxe::
+ Enable the so called pickaxe search, which will list the commits
+ that introduced or removed a given string in a file. This can be
+ practical and quite faster alternative to "blame" action, but it is
+ still potentially CPU-intensive. Enabled by default.
++
+The pickaxe search is described in linkgit:git-log[1] (the
+description of `-S<string>` option, which refers to pickaxe entry in
+linkgit:gitdiffcore[7] for more details).
++
+This feature can be configured on a per-repository basis by setting
+repository's `gitweb.pickaxe` configuration variable (boolean).
+
+show-sizes::
+ Enable showing size of blobs (ordinary files) in a "tree" view, in a
+ separate column, similar to what `ls -l` does; see description of
+ `-l` option in linkgit:git-ls-tree[1] manpage. This costs a bit of
+ I/O. Enabled by default.
++
+This feature can be configured on a per-repository basis via
+repository's `gitweb.showSizes` configuration variable (boolean).
+
+patches::
+ Enable and configure "patches" view, which displays list of commits in email
+ (plain text) output format; see also linkgit:git-format-patch[1].
+ The value is the maximum number of patches in a patchset generated
+ in "patches" view. Set the 'default' field to a list containing single
+ item of or to an empty list to disable patch view, or to a list
+ containing a single negative number to remove any limit.
+ Default value is 16.
++
+This feature can be configured on a per-repository basis via
+repository's `gitweb.patches` configuration variable (integer).
+
+avatar::
+ Avatar support. When this feature is enabled, views such as
+ "shortlog" or "commit" will display an avatar associated with
+ the email of each committer and author.
++
+Currently available providers are *"gravatar"* and *"picon"*.
+Only one provider at a time can be selected ('default' is one element list).
+If an unknown provider is specified, the feature is disabled.
+*Note* that some providers might require extra Perl packages to be
+installed; see `gitweb/INSTALL` for more details.
++
+This feature can be configured on a per-repository basis via
+repository's `gitweb.avatar` configuration variable.
++
+See also `%avatar_size` with pixel sizes for icons and avatars
+("default" is used for one-line like "log" and "shortlog", "double"
+is used for two-line like "commit", "commitdiff" or "tag"). If the
+default font sizes or lineheights are changed (e.g. via adding extra
+CSS stylesheet in `@stylesheets`), it may be appropriate to change
+these values.
+
+email-privacy::
+ Redact e-mail addresses from the generated HTML, etc. content.
+ This obscures e-mail addresses retrieved from the author/committer
+ and comment sections of the Git log.
+ It is meant to hinder web crawlers that harvest and abuse addresses.
+ Such crawlers may not respect robots.txt.
+ Note that users and user tools also see the addresses as redacted.
+ If Gitweb is not the final step in a workflow then subsequent steps
+ may misbehave because of the redacted information they receive.
+ Disabled by default.
+
+highlight::
+ Server-side syntax highlight support in "blob" view. It requires
+ `$highlight_bin` program to be available (see the description of
+ this variable in the "Configuration variables" section above),
+ and therefore is disabled by default.
++
+This feature can be configured on a per-repository basis via
+repository's `gitweb.highlight` configuration variable (boolean).
+
+remote_heads::
+ Enable displaying remote heads (remote-tracking branches) in the "heads"
+ list. In most cases the list of remote-tracking branches is an
+ unnecessary internal private detail, and this feature is therefore
+ disabled by default. linkgit:git-instaweb[1], which is usually used
+ to browse local repositories, enables and uses this feature.
++
+This feature can be configured on a per-repository basis via
+repository's `gitweb.remote_heads` configuration variable (boolean).
+
+
+The remaining features cannot be overridden on a per project basis.
+
+search::
+ Enable text search, which will list the commits which match author,
+ committer or commit text to a given string; see the description of
+ `--author`, `--committer` and `--grep` options in linkgit:git-log[1]
+ manpage. Enabled by default.
++
+Project specific override is not supported.
+
+forks::
+ If this feature is enabled, gitweb considers projects in
+ subdirectories of project root (basename) to be forks of existing
+ projects. For each project +$projname.git+, projects in the
+ +$projname/+ directory and its subdirectories will not be
+ shown in the main projects list. Instead, a \'+' mark is shown
+ next to `$projname`, which links to a "forks" view that lists all
+ the forks (all projects in `$projname/` subdirectory). Additionally
+ a "forks" view for a project is linked from project summary page.
++
+If the project list is taken from a file (+$projects_list+ points to a
+file), forks are only recognized if they are listed after the main project
+in that file.
++
+Project specific override is not supported.
+
+actions::
+ Insert custom links to the action bar of all project pages. This
+ allows you to link to third-party scripts integrating into gitweb.
++
+The "default" value consists of a list of triplets in the form
+`("<label>", "<link>", "<position>")` where "position" is the label
+after which to insert the link, "link" is a format string where `%n`
+expands to the project name, `%f` to the project path within the
+filesystem (i.e. "$projectroot/$project"), `%h` to the current hash
+(\'h' gitweb parameter) and `%b` to the current hash base
+(\'hb' gitweb parameter); `%%` expands to \'%'.
++
+For example, at the time this page was written, the https://repo.or.cz[]
+Git hosting site set it to the following to enable graphical log
+(using the third party tool *git-browser*):
++
+----------------------------------------------------------------------
+$feature{'actions'}{'default'} =
+ [ ('graphiclog', '/git-browser/by-commit.html?r=%n', 'summary')];
+----------------------------------------------------------------------
++
+This adds a link titled "graphiclog" after the "summary" link, leading to
+`git-browser` script, passing `r=<project>` as a query parameter.
++
+Project specific override is not supported.
+
+timed::
+ Enable displaying how much time and how many Git commands it took to
+ generate and display each page in the page footer (at the bottom of
+ page). For example the footer might contain: "This page took 6.53325
+ seconds and 13 Git commands to generate." Disabled by default.
++
+Project specific override is not supported.
+
+javascript-timezone::
+ Enable and configure the ability to change a common time zone for dates
+ in gitweb output via JavaScript. Dates in gitweb output include
+ authordate and committerdate in "commit", "commitdiff" and "log"
+ views, and taggerdate in "tag" view. Enabled by default.
++
+The value is a list of three values: a default time zone (for if the client
+hasn't selected some other time zone and saved it in a cookie), a name of cookie
+where to store selected time zone, and a CSS class used to mark up
+dates for manipulation. If you want to turn this feature off, set "default"
+to empty list: `[]`.
++
+Typical gitweb config files will only change starting (default) time zone,
+and leave other elements at their default values:
++
+---------------------------------------------------------------------------
+$feature{'javascript-timezone'}{'default'}[0] = "utc";
+---------------------------------------------------------------------------
++
+The example configuration presented here is guaranteed to be backwards
+and forward compatible.
++
+Time zone values can be "local" (for local time zone that browser uses), "utc"
+(what gitweb uses when JavaScript or this feature is disabled), or numerical
+time zones in the form of "+/-HHMM", such as "+0200".
++
+Project specific override is not supported.
+
+extra-branch-refs::
+ List of additional directories under "refs" which are going to
+ be used as branch refs. For example if you have a gerrit setup
+ where all branches under refs/heads/ are official,
+ push-after-review ones and branches under refs/sandbox/,
+ refs/wip and refs/other are user ones where permissions are
+ much wider, then you might want to set this variable as
+ follows:
++
+--------------------------------------------------------------------------------
+$feature{'extra-branch-refs'}{'default'} =
+ ['sandbox', 'wip', 'other'];
+--------------------------------------------------------------------------------
++
+This feature can be configured on per-repository basis after setting
+$feature{'extra-branch-refs'}{'override'} to true, via repository's
+`gitweb.extraBranchRefs` configuration variable, which contains a
+space separated list of refs. An example:
++
+--------------------------------------------------------------------------------
+[gitweb]
+ extraBranchRefs = sandbox wip other
+--------------------------------------------------------------------------------
++
+The gitweb.extraBranchRefs is actually a multi-valued configuration
+variable, so following example is also correct and the result is the
+same as of the snippet above:
++
+--------------------------------------------------------------------------------
+[gitweb]
+ extraBranchRefs = sandbox
+ extraBranchRefs = wip other
+--------------------------------------------------------------------------------
++
+It is an error to specify a ref that does not pass "git check-ref-format"
+scrutiny. Duplicated values are filtered.
+
+
+EXAMPLES
+--------
+
+To enable blame, pickaxe search, and snapshot support (allowing "tar.gz" and
+"zip" snapshots), while allowing individual projects to turn them off, put
+the following in your GITWEB_CONFIG file:
+
+--------------------------------------------------------------------------------
+$feature{'blame'}{'default'} = [1];
+$feature{'blame'}{'override'} = 1;
+
+$feature{'pickaxe'}{'default'} = [1];
+$feature{'pickaxe'}{'override'} = 1;
+
+$feature{'snapshot'}{'default'} = ['zip', 'tgz'];
+$feature{'snapshot'}{'override'} = 1;
+--------------------------------------------------------------------------------
+
+If you allow overriding for the snapshot feature, you can specify which
+snapshot formats are globally disabled. You can also add any command-line
+options you want (such as setting the compression level). For instance, you
+can disable Zip compressed snapshots and set *gzip*(1) to run at level 6 by
+adding the following lines to your gitweb configuration file:
+
+ $known_snapshot_formats{'zip'}{'disabled'} = 1;
+ $known_snapshot_formats{'tgz'}{'compressor'} = ['gzip','-6'];
+
+BUGS
+----
+Debugging would be easier if the fallback configuration file
+(`/etc/gitweb.conf`) and environment variable to override its location
+('GITWEB_CONFIG_SYSTEM') had names reflecting their "fallback" role.
+The current names are kept to avoid breaking working setups.
+
+ENVIRONMENT
+-----------
+The location of per-instance and system-wide configuration files can be
+overridden using the following environment variables:
+
+GITWEB_CONFIG::
+ Sets location of per-instance configuration file.
+GITWEB_CONFIG_SYSTEM::
+ Sets location of fallback system-wide configuration file.
+ This file is read only if per-instance one does not exist.
+GITWEB_CONFIG_COMMON::
+ Sets location of common system-wide configuration file.
+
+
+FILES
+-----
+gitweb_config.perl::
+ This is default name of per-instance configuration file. The
+ format of this file is described above.
+/etc/gitweb.conf::
+ This is default name of fallback system-wide configuration
+ file. This file is used only if per-instance configuration
+ variable is not found.
+/etc/gitweb-common.conf::
+ This is default name of common system-wide configuration
+ file.
+
+
+SEE ALSO
+--------
+linkgit:gitweb[1], linkgit:git-instaweb[1]
+
+'gitweb/README', 'gitweb/INSTALL'
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/gitworkflows.adoc b/gitworkflows.adoc
new file mode 100644
index 0000000..5930526
--- /dev/null
+++ b/gitworkflows.adoc
@@ -0,0 +1,479 @@
+gitworkflows(7)
+===============
+
+NAME
+----
+gitworkflows - An overview of recommended workflows with Git
+
+SYNOPSIS
+--------
+[verse]
+git *
+
+
+DESCRIPTION
+-----------
+
+This document attempts to write down and motivate some of the workflow
+elements used for `git.git` itself. Many ideas apply in general,
+though the full workflow is rarely required for smaller projects with
+fewer people involved.
+
+We formulate a set of 'rules' for quick reference, while the prose
+tries to motivate each of them. Do not always take them literally;
+you should value good reasons for your actions higher than manpages
+such as this one.
+
+
+SEPARATE CHANGES
+----------------
+
+As a general rule, you should try to split your changes into small
+logical steps, and commit each of them. They should be consistent,
+working independently of any later commits, pass the test suite, etc.
+This makes the review process much easier, and the history much more
+useful for later inspection and analysis, for example with
+linkgit:git-blame[1] and linkgit:git-bisect[1].
+
+To achieve this, try to split your work into small steps from the very
+beginning. It is always easier to squash a few commits together than
+to split one big commit into several. Don't be afraid of making too
+small or imperfect steps along the way. You can always go back later
+and edit the commits with `git rebase --interactive` before you
+publish them. You can use `git stash push --keep-index` to run the
+test suite independent of other uncommitted changes; see the EXAMPLES
+section of linkgit:git-stash[1].
+
+
+MANAGING BRANCHES
+-----------------
+
+There are two main tools that can be used to include changes from one
+branch on another: linkgit:git-merge[1] and
+linkgit:git-cherry-pick[1].
+
+Merges have many advantages, so we try to solve as many problems as
+possible with merges alone. Cherry-picking is still occasionally
+useful; see "Merging upwards" below for an example.
+
+Most importantly, merging works at the branch level, while
+cherry-picking works at the commit level. This means that a merge can
+carry over the changes from 1, 10, or 1000 commits with equal ease,
+which in turn means the workflow scales much better to a large number
+of contributors (and contributions). Merges are also easier to
+understand because a merge commit is a "promise" that all changes from
+all its parents are now included.
+
+There is a tradeoff of course: merges require a more careful branch
+management. The following subsections discuss the important points.
+
+
+Graduation
+~~~~~~~~~~
+
+As a given feature goes from experimental to stable, it also
+"graduates" between the corresponding branches of the software.
+`git.git` uses the following 'integration branches':
+
+* 'maint' tracks the commits that should go into the next "maintenance
+ release", i.e., update of the last released stable version;
+
+* 'master' tracks the commits that should go into the next release;
+
+* 'next' is intended as a testing branch for topics being tested for
+ stability for master.
+
+There is a fourth official branch that is used slightly differently:
+
+* 'seen' (patches seen by the maintainer) is an integration branch for
+ things that are not quite ready for inclusion yet (see "Integration
+ Branches" below).
+
+Each of the four branches is usually a direct descendant of the one
+above it.
+
+Conceptually, the feature enters at an unstable branch (usually 'next'
+or 'seen'), and "graduates" to 'master' for the next release once it is
+considered stable enough.
+
+
+Merging upwards
+~~~~~~~~~~~~~~~
+
+The "downwards graduation" discussed above cannot be done by actually
+merging downwards, however, since that would merge 'all' changes on
+the unstable branch into the stable one. Hence the following:
+
+.Merge upwards
+[caption="Rule: "]
+=====================================
+Always commit your fixes to the oldest supported branch that requires
+them. Then (periodically) merge the integration branches upwards into each
+other.
+=====================================
+
+This gives a very controlled flow of fixes. If you notice that you
+have applied a fix to e.g. 'master' that is also required in 'maint',
+you will need to cherry-pick it (using linkgit:git-cherry-pick[1])
+downwards. This will happen a few times and is nothing to worry about
+unless you do it very frequently.
+
+
+Topic branches
+~~~~~~~~~~~~~~
+
+Any nontrivial feature will require several patches to implement, and
+may get extra bugfixes or improvements during its lifetime.
+
+Committing everything directly on the integration branches leads to many
+problems: Bad commits cannot be undone, so they must be reverted one
+by one, which creates confusing histories and further error potential
+when you forget to revert part of a group of changes. Working in
+parallel mixes up the changes, creating further confusion.
+
+Use of "topic branches" solves these problems. The name is pretty
+self explanatory, with a caveat that comes from the "merge upwards"
+rule above:
+
+.Topic branches
+[caption="Rule: "]
+=====================================
+Make a side branch for every topic (feature, bugfix, ...). Fork it off
+at the oldest integration branch that you will eventually want to merge it
+into.
+=====================================
+
+Many things can then be done very naturally:
+
+* To get the feature/bugfix into an integration branch, simply merge
+ it. If the topic has evolved further in the meantime, merge again.
+ (Note that you do not necessarily have to merge it to the oldest
+ integration branch first. For example, you can first merge a bugfix
+ to 'next', give it some testing time, and merge to 'maint' when you
+ know it is stable.)
+
+* If you find you need new features from the branch 'other' to continue
+ working on your topic, merge 'other' to 'topic'. (However, do not
+ do this "just habitually", see below.)
+
+* If you find you forked off the wrong branch and want to move it
+ "back in time", use linkgit:git-rebase[1].
+
+Note that the last point clashes with the other two: a topic that has
+been merged elsewhere should not be rebased. See the section on
+RECOVERING FROM UPSTREAM REBASE in linkgit:git-rebase[1].
+
+We should point out that "habitually" (regularly for no real reason)
+merging an integration branch into your topics -- and by extension,
+merging anything upstream into anything downstream on a regular basis
+-- is frowned upon:
+
+.Merge to downstream only at well-defined points
+[caption="Rule: "]
+=====================================
+Do not merge to downstream except with a good reason: upstream API
+changes affect your branch; your branch no longer merges to upstream
+cleanly; etc.
+=====================================
+
+Otherwise, the topic that was merged to suddenly contains more than a
+single (well-separated) change. The many resulting small merges will
+greatly clutter up history. Anyone who later investigates the history
+of a file will have to find out whether that merge affected the topic
+in development. An upstream might even inadvertently be merged into a
+"more stable" branch. And so on.
+
+
+Throw-away integration
+~~~~~~~~~~~~~~~~~~~~~~
+
+If you followed the last paragraph, you will now have many small topic
+branches, and occasionally wonder how they interact. Perhaps the
+result of merging them does not even work? But on the other hand, we
+want to avoid merging them anywhere "stable" because such merges
+cannot easily be undone.
+
+The solution, of course, is to make a merge that we can undo: merge
+into a throw-away branch.
+
+.Throw-away integration branches
+[caption="Rule: "]
+=====================================
+To test the interaction of several topics, merge them into a
+throw-away branch. You must never base any work on such a branch!
+=====================================
+
+If you make it (very) clear that this branch is going to be deleted
+right after the testing, you can even publish this branch, for example
+to give the testers a chance to work with it, or other developers a
+chance to see if their in-progress work will be compatible. `git.git`
+has such an official throw-away integration branch called 'seen'.
+
+
+Branch management for a release
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Assuming you are using the merge approach discussed above, when you
+are releasing your project you will need to do some additional branch
+management work.
+
+A feature release is created from the 'master' branch, since 'master'
+tracks the commits that should go into the next feature release.
+
+The 'master' branch is supposed to be a superset of 'maint'. If this
+condition does not hold, then 'maint' contains some commits that
+are not included on 'master'. The fixes represented by those commits
+will therefore not be included in your feature release.
+
+To verify that 'master' is indeed a superset of 'maint', use git log:
+
+.Verify 'master' is a superset of 'maint'
+[caption="Recipe: "]
+=====================================
+`git log master..maint`
+=====================================
+
+This command should not list any commits. Otherwise, check out
+'master' and merge 'maint' into it.
+
+Now you can proceed with the creation of the feature release. Apply a
+tag to the tip of 'master' indicating the release version:
+
+.Release tagging
+[caption="Recipe: "]
+=====================================
+`git tag -s -m "Git X.Y.Z" vX.Y.Z master`
+=====================================
+
+You need to push the new tag to a public Git server (see
+"DISTRIBUTED WORKFLOWS" below). This makes the tag available to
+others tracking your project. The push could also trigger a
+post-update hook to perform release-related items such as building
+release tarballs and preformatted documentation pages.
+
+Similarly, for a maintenance release, 'maint' is tracking the commits
+to be released. Therefore, in the steps above simply tag and push
+'maint' rather than 'master'.
+
+
+Maintenance branch management after a feature release
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+After a feature release, you need to manage your maintenance branches.
+
+First, if you wish to continue to release maintenance fixes for the
+feature release made before the recent one, then you must create
+another branch to track commits for that previous release.
+
+To do this, the current maintenance branch is copied to another branch
+named with the previous release version number (e.g. maint-X.Y.(Z-1)
+where X.Y.Z is the current release).
+
+.Copy maint
+[caption="Recipe: "]
+=====================================
+`git branch maint-X.Y.(Z-1) maint`
+=====================================
+
+The 'maint' branch should now be fast-forwarded to the newly released
+code so that maintenance fixes can be tracked for the current release:
+
+.Update maint to new release
+[caption="Recipe: "]
+=====================================
+* `git checkout maint`
+* `git merge --ff-only master`
+=====================================
+
+If the merge fails because it is not a fast-forward, then it is
+possible some fixes on 'maint' were missed in the feature release.
+This will not happen if the content of the branches was verified as
+described in the previous section.
+
+
+Branch management for next and seen after a feature release
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+After a feature release, the integration branch 'next' may optionally be
+rewound and rebuilt from the tip of 'master' using the surviving
+topics on 'next':
+
+.Rewind and rebuild next
+[caption="Recipe: "]
+=====================================
+* `git switch -C next master`
+* `git merge ai/topic_in_next1`
+* `git merge ai/topic_in_next2`
+* ...
+=====================================
+
+The advantage of doing this is that the history of 'next' will be
+clean. For example, some topics merged into 'next' may have initially
+looked promising, but were later found to be undesirable or premature.
+In such a case, the topic is reverted out of 'next' but the fact
+remains in the history that it was once merged and reverted. By
+recreating 'next', you give another incarnation of such topics a clean
+slate to retry, and a feature release is a good point in history to do
+so.
+
+If you do this, then you should make a public announcement indicating
+that 'next' was rewound and rebuilt.
+
+The same rewind and rebuild process may be followed for 'seen'. A public
+announcement is not necessary since 'seen' is a throw-away branch, as
+described above.
+
+
+DISTRIBUTED WORKFLOWS
+---------------------
+
+After the last section, you should know how to manage topics. In
+general, you will not be the only person working on the project, so
+you will have to share your work.
+
+Roughly speaking, there are two important workflows: merge and patch.
+The important difference is that the merge workflow can propagate full
+history, including merges, while patches cannot. Both workflows can
+be used in parallel: in `git.git`, only subsystem maintainers use
+the merge workflow, while everyone else sends patches.
+
+Note that the maintainer(s) may impose restrictions, such as
+"Signed-off-by" requirements, that all commits/patches submitted for
+inclusion must adhere to. Consult your project's documentation for
+more information.
+
+
+Merge workflow
+~~~~~~~~~~~~~~
+
+The merge workflow works by copying branches between upstream and
+downstream. Upstream can merge contributions into the official
+history; downstream base their work on the official history.
+
+There are three main tools that can be used for this:
+
+* linkgit:git-push[1] copies your branches to a remote repository,
+ usually to one that can be read by all involved parties;
+
+* linkgit:git-fetch[1] that copies remote branches to your repository;
+ and
+
+* linkgit:git-pull[1] that does fetch and merge in one go.
+
+Note the last point. Do 'not' use 'git pull' unless you actually want
+to merge the remote branch.
+
+Getting changes out is easy:
+
+.Push/pull: Publishing branches/topics
+[caption="Recipe: "]
+=====================================
+`git push <remote> <branch>` and tell everyone where they can fetch
+from.
+=====================================
+
+You will still have to tell people by other means, such as mail. (Git
+provides the linkgit:git-request-pull[1] to send preformatted pull
+requests to upstream maintainers to simplify this task.)
+
+If you just want to get the newest copies of the integration branches,
+staying up to date is easy too:
+
+.Push/pull: Staying up to date
+[caption="Recipe: "]
+=====================================
+Use `git fetch <remote>` or `git remote update` to stay up to date.
+=====================================
+
+Then simply fork your topic branches from the stable remotes as
+explained earlier.
+
+If you are a maintainer and would like to merge other people's topic
+branches to the integration branches, they will typically send a
+request to do so by mail. Such a request looks like
+
+-------------------------------------
+Please pull from
+ <URL> <branch>
+-------------------------------------
+
+In that case, 'git pull' can do the fetch and merge in one go, as
+follows.
+
+.Push/pull: Merging remote topics
+[caption="Recipe: "]
+=====================================
+`git pull <URL> <branch>`
+=====================================
+
+Occasionally, the maintainer may get merge conflicts when they try to
+pull changes from downstream. In this case, they can ask downstream to
+do the merge and resolve the conflicts themselves (perhaps they will
+know better how to resolve them). It is one of the rare cases where
+downstream 'should' merge from upstream.
+
+
+Patch workflow
+~~~~~~~~~~~~~~
+
+If you are a contributor that sends changes upstream in the form of
+emails, you should use topic branches as usual (see above). Then use
+linkgit:git-format-patch[1] to generate the corresponding emails
+(highly recommended over manually formatting them because it makes the
+maintainer's life easier).
+
+.format-patch/am: Publishing branches/topics
+[caption="Recipe: "]
+=====================================
+* `git format-patch -M upstream..topic` to turn them into preformatted
+ patch files
+* `git send-email --to=<recipient> <patches>`
+=====================================
+
+See the linkgit:git-format-patch[1] and linkgit:git-send-email[1]
+manpages for further usage notes.
+
+If the maintainer tells you that your patch no longer applies to the
+current upstream, you will have to rebase your topic (you cannot use a
+merge because you cannot format-patch merges):
+
+.format-patch/am: Keeping topics up to date
+[caption="Recipe: "]
+=====================================
+`git pull --rebase <URL> <branch>`
+=====================================
+
+You can then fix the conflicts during the rebase. Presumably you have
+not published your topic other than by mail, so rebasing it is not a
+problem.
+
+If you receive such a patch series (as maintainer, or perhaps as a
+reader of the mailing list it was sent to), save the mails to files,
+create a new topic branch and use 'git am' to import the commits:
+
+.format-patch/am: Importing patches
+[caption="Recipe: "]
+=====================================
+`git am < patch`
+=====================================
+
+One feature worth pointing out is the three-way merge, which can help
+if you get conflicts: `git am -3` will use index information contained
+in patches to figure out the merge base. See linkgit:git-am[1] for
+other options.
+
+
+SEE ALSO
+--------
+linkgit:gittutorial[7],
+linkgit:git-push[1],
+linkgit:git-pull[1],
+linkgit:git-merge[1],
+linkgit:git-rebase[1],
+linkgit:git-format-patch[1],
+linkgit:git-send-email[1],
+linkgit:git-am[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/glossary-content.adoc b/glossary-content.adoc
new file mode 100644
index 0000000..575c18f
--- /dev/null
+++ b/glossary-content.adoc
@@ -0,0 +1,766 @@
+[[def_alternate_object_database]]alternate object database::
+ Via the alternates mechanism, a <<def_repository,repository>>
+ can inherit part of its <<def_object_database,object database>>
+ from another object database, which is called an "alternate".
+
+[[def_bare_repository]]bare repository::
+ A bare repository is normally an appropriately
+ named <<def_directory,directory>> with a `.git` suffix that does not
+ have a locally checked-out copy of any of the files under
+ revision control. That is, all of the Git
+ administrative and control files that would normally be present in the
+ hidden `.git` sub-directory are directly present in the
+ `repository.git` directory instead,
+ and no other files are present and checked out. Usually publishers of
+ public repositories make bare repositories available.
+
+[[def_blob_object]]blob object::
+ Untyped <<def_object,object>>, e.g. the contents of a file.
+
+[[def_branch]]branch::
+ A "branch" is a line of development. The most recent
+ <<def_commit,commit>> on a branch is referred to as the tip of
+ that branch. The tip of the branch is <<def_ref,referenced>> by a branch
+ <<def_head,head>>, which moves forward as additional development
+ is done on the branch. A single Git
+ <<def_repository,repository>> can track an arbitrary number of
+ branches, but your <<def_working_tree,working tree>> is
+ associated with just one of them (the "current" or "checked out"
+ branch), and <<def_HEAD,HEAD>> points to that branch.
+
+[[def_cache]]cache::
+ Obsolete for: <<def_index,index>>.
+
+[[def_chain]]chain::
+ A list of objects, where each <<def_object,object>> in the list contains
+ a reference to its successor (for example, the successor of a
+ <<def_commit,commit>> could be one of its <<def_parent,parents>>).
+
+[[def_changeset]]changeset::
+ BitKeeper/cvsps speak for "<<def_commit,commit>>". Since Git does not
+ store changes, but states, it really does not make sense to use the term
+ "changesets" with Git.
+
+[[def_checkout]]checkout::
+ The action of updating all or part of the
+ <<def_working_tree,working tree>> with a <<def_tree_object,tree object>>
+ or <<def_blob_object,blob>> from the
+ <<def_object_database,object database>>, and updating the
+ <<def_index,index>> and <<def_HEAD,HEAD>> if the whole working tree has
+ been pointed at a new <<def_branch,branch>>.
+
+[[def_cherry-picking]]cherry-picking::
+ In <<def_SCM,SCM>> jargon, "cherry pick" means to choose a subset of
+ changes out of a series of changes (typically commits) and record them
+ as a new series of changes on top of a different codebase. In Git, this is
+ performed by the "git cherry-pick" command to extract the change introduced
+ by an existing <<def_commit,commit>> and to record it based on the tip
+ of the current <<def_branch,branch>> as a new commit.
+
+[[def_clean]]clean::
+ A <<def_working_tree,working tree>> is clean, if it
+ corresponds to the <<def_revision,revision>> referenced by the current
+ <<def_head,head>>. Also see "<<def_dirty,dirty>>".
+
+[[def_commit]]commit::
+ As a noun: A single point in the
+ Git history; the entire history of a project is represented as a
+ set of interrelated commits. The word "commit" is often
+ used by Git in the same places other revision control systems
+ use the words "revision" or "version". Also used as a short
+ hand for <<def_commit_object,commit object>>.
++
+As a verb: The action of storing a new snapshot of the project's
+state in the Git history, by creating a new commit representing the current
+state of the <<def_index,index>> and advancing <<def_HEAD,HEAD>>
+to point at the new commit.
+
+[[def_commit_graph_general]]commit graph concept, representations and usage::
+ A synonym for the <<def_DAG,DAG>> structure formed by the commits
+ in the object database, <<def_ref,referenced>> by branch tips,
+ using their <<def_chain,chain>> of linked commits.
+ This structure is the definitive commit graph. The
+ graph can be represented in other ways, e.g. the
+ <<def_commit_graph_file,"commit-graph" file>>.
+
+[[def_commit_graph_file]]commit-graph file::
+ The "commit-graph" (normally hyphenated) file is a supplemental
+ representation of the <<def_commit_graph_general,commit graph>>
+ which accelerates commit graph walks. The "commit-graph" file is
+ stored either in the .git/objects/info directory or in the info
+ directory of an alternate object database.
+
+[[def_commit_object]]commit object::
+ An <<def_object,object>> which contains the information about a
+ particular <<def_revision,revision>>, such as <<def_parent,parents>>, committer,
+ author, date and the <<def_tree_object,tree object>> which corresponds
+ to the top <<def_directory,directory>> of the stored
+ revision.
+
+[[def_commit-ish]]commit-ish (also committish)::
+ A <<def_commit_object,commit object>> or an <<def_object,object>> that
+ can be recursively <<def_dereference,dereferenced>> to a commit object.
+ The following are all commit-ishes:
+ a commit object,
+ a <<def_tag_object,tag object>> that points to a commit
+ object,
+ a tag object that points to a tag object that points to a
+ commit object,
+ etc.
+
+[[def_core_git]]core Git::
+ Fundamental data structures and utilities of Git. Exposes only limited
+ source code management tools.
+
+[[def_DAG]]DAG::
+ Directed acyclic graph. The <<def_commit_object,commit objects>> form a
+ directed acyclic graph, because they have parents (directed), and the
+ graph of commit objects is acyclic (there is no <<def_chain,chain>>
+ which begins and ends with the same <<def_object,object>>).
+
+[[def_dangling_object]]dangling object::
+ An <<def_unreachable_object,unreachable object>> which is not
+ <<def_reachable,reachable>> even from other unreachable objects; a
+ dangling object has no references to it from any
+ reference or <<def_object,object>> in the <<def_repository,repository>>.
+
+[[def_dereference]]dereference::
+ Referring to a <<def_symref,symbolic ref>>: the action of accessing the
+ <<def_ref,reference>> pointed at by a symbolic ref. Recursive
+ dereferencing involves repeating the aforementioned process on the
+ resulting ref until a non-symbolic reference is found.
++
+Referring to a <<def_tag_object,tag object>>: the action of accessing the
+<<def_object,object>> a tag points at. Tags are recursively dereferenced by
+repeating the operation on the result object until the result has either a
+specified <<def_object_type,object type>> (where applicable) or any non-"tag"
+object type. A synonym for "recursive dereference" in the context of tags is
+"<<def_peel,peel>>".
++
+Referring to a <<def_commit_object,commit object>>: the action of accessing
+the commit's tree object. Commits cannot be dereferenced recursively.
++
+Unless otherwise specified, "dereferencing" as it used in the context of Git
+commands or protocols is implicitly recursive.
+
+[[def_detached_HEAD]]detached HEAD::
+ Normally the <<def_HEAD,HEAD>> stores the name of a
+ <<def_branch,branch>>, and commands that operate on the
+ history HEAD represents operate on the history leading to the
+ tip of the branch the HEAD points at. However, Git also
+ allows you to <<def_checkout,check out>> an arbitrary
+ <<def_commit,commit>> that isn't necessarily the tip of any
+ particular branch. The HEAD in such a state is called
+ "detached".
++
+Note that commands that operate on the history of the current branch
+(e.g. `git commit` to build a new history on top of it) still work
+while the HEAD is detached. They update the HEAD to point at the tip
+of the updated history without affecting any branch. Commands that
+update or inquire information _about_ the current branch (e.g. `git
+branch --set-upstream-to` that sets what remote-tracking branch the
+current branch integrates with) obviously do not work, as there is no
+(real) current branch to ask about in this state.
+
+[[def_directory]]directory::
+ The list you get with "ls" :-)
+
+[[def_dirty]]dirty::
+ A <<def_working_tree,working tree>> is said to be "dirty" if
+ it contains modifications which have not been <<def_commit,committed>> to the current
+ <<def_branch,branch>>.
+
+[[def_evil_merge]]evil merge::
+ An evil merge is a <<def_merge,merge>> that introduces changes that
+ do not appear in any <<def_parent,parent>>.
+
+[[def_fast_forward]]fast-forward::
+ A fast-forward is a special type of <<def_merge,merge>> where you have a
+ <<def_revision,revision>> and you are "merging" another
+ <<def_branch,branch>>'s changes that happen to be a descendant of what
+ you have. In such a case, you do not make a new <<def_merge,merge>>
+ <<def_commit,commit>> but instead just update your branch to point at the same
+ revision as the branch you are merging. This will happen frequently on a
+ <<def_remote_tracking_branch,remote-tracking branch>> of a remote
+ <<def_repository,repository>>.
+
+[[def_fetch]]fetch::
+ Fetching a <<def_branch,branch>> means to get the
+ branch's <<def_head_ref,head ref>> from a remote
+ <<def_repository,repository>>, to find out which objects are
+ missing from the local <<def_object_database,object database>>,
+ and to get them, too. See also linkgit:git-fetch[1].
+
+[[def_file_system]]file system::
+ Linus Torvalds originally designed Git to be a user space file system,
+ i.e. the infrastructure to hold files and directories. That ensured the
+ efficiency and speed of Git.
+
+[[def_git_archive]]Git archive::
+ Synonym for <<def_repository,repository>> (for arch people).
+
+[[def_gitfile]]gitfile::
+ A plain file `.git` at the root of a working tree that
+ points at the directory that is the real repository.
+ For proper use see linkgit:git-worktree[1] or linkgit:git-submodule[1].
+ For syntax see linkgit:gitrepository-layout[5].
+
+[[def_grafts]]grafts::
+ Grafts enable two otherwise different lines of development to be joined
+ together by recording fake ancestry information for commits. This way
+ you can make Git pretend the set of <<def_parent,parents>> a <<def_commit,commit>> has
+ is different from what was recorded when the commit was
+ created. Configured via the `.git/info/grafts` file.
++
+Note that the grafts mechanism is outdated and can lead to problems
+transferring objects between repositories; see linkgit:git-replace[1]
+for a more flexible and robust system to do the same thing.
+
+[[def_hash]]hash::
+ In Git's context, synonym for <<def_object_name,object name>>.
+
+[[def_head]]head::
+ A <<def_ref,named reference>> to the <<def_commit,commit>> at the tip of a
+ <<def_branch,branch>>. Heads are stored in a file in
+ `$GIT_DIR/refs/heads/` directory, except when using packed refs. (See
+ linkgit:git-pack-refs[1].)
+
+[[def_HEAD]]HEAD::
+ The current <<def_branch,branch>>. In more detail: Your <<def_working_tree,
+ working tree>> is normally derived from the state of the tree
+ referred to by HEAD. HEAD is a reference to one of the
+ <<def_head,heads>> in your repository, except when using a
+ <<def_detached_HEAD,detached HEAD>>, in which case it directly
+ references an arbitrary commit.
+
+[[def_head_ref]]head ref::
+ A synonym for <<def_head,head>>.
+
+[[def_hook]]hook::
+ During the normal execution of several Git commands, call-outs are made
+ to optional scripts that allow a developer to add functionality or
+ checking. Typically, the hooks allow for a command to be pre-verified
+ and potentially aborted, and allow for a post-notification after the
+ operation is done. The hook scripts are found in the
+ `$GIT_DIR/hooks/` directory, and are enabled by simply
+ removing the `.sample` suffix from the filename. In earlier versions
+ of Git you had to make them executable.
+
+[[def_index]]index::
+ A collection of files with stat information, whose contents are stored
+ as objects. The index is a stored version of your
+ <<def_working_tree,working tree>>. Truth be told, it can also contain a second, and even
+ a third version of a working tree, which are used
+ when <<def_merge,merging>>.
+
+[[def_index_entry]]index entry::
+ The information regarding a particular file, stored in the
+ <<def_index,index>>. An index entry can be unmerged, if a
+ <<def_merge,merge>> was started, but not yet finished (i.e. if
+ the index contains multiple versions of that file).
+
+[[def_master]]master::
+ The default development <<def_branch,branch>>. Whenever you
+ create a Git <<def_repository,repository>>, a branch named
+ "master" is created, and becomes the active branch. In most
+ cases, this contains the local development, though that is
+ purely by convention and is not required.
+
+[[def_merge]]merge::
+ As a verb: To bring the contents of another
+ <<def_branch,branch>> (possibly from an external
+ <<def_repository,repository>>) into the current branch. In the
+ case where the merged-in branch is from a different repository,
+ this is done by first <<def_fetch,fetching>> the remote branch
+ and then merging the result into the current branch. This
+ combination of fetch and merge operations is called a
+ <<def_pull,pull>>. Merging is performed by an automatic process
+ that identifies changes made since the branches diverged, and
+ then applies all those changes together. In cases where changes
+ conflict, manual intervention may be required to complete the
+ merge.
++
+As a noun: unless it is a <<def_fast_forward,fast-forward>>, a
+successful merge results in the creation of a new <<def_commit,commit>>
+representing the result of the merge, and having as
+<<def_parent,parents>> the tips of the merged <<def_branch,branches>>.
+This commit is referred to as a "merge commit", or sometimes just a
+"merge".
+
+[[def_object]]object::
+ The unit of storage in Git. It is uniquely identified by the
+ <<def_SHA1,SHA-1>> of its contents. Consequently, an
+ object cannot be changed.
+
+[[def_object_database]]object database::
+ Stores a set of "objects", and an individual <<def_object,object>> is
+ identified by its <<def_object_name,object name>>. The objects usually
+ live in `$GIT_DIR/objects/`.
+
+[[def_object_identifier]]object identifier (oid)::
+ Synonym for <<def_object_name,object name>>.
+
+[[def_object_name]]object name::
+ The unique identifier of an <<def_object,object>>. The
+ object name is usually represented by a 40 character
+ hexadecimal string. Also colloquially called <<def_SHA1,SHA-1>>.
+
+[[def_object_type]]object type::
+ One of the identifiers "<<def_commit_object,commit>>",
+ "<<def_tree_object,tree>>", "<<def_tag_object,tag>>" or
+ "<<def_blob_object,blob>>" describing the type of an
+ <<def_object,object>>.
+
+[[def_octopus]]octopus::
+ To <<def_merge,merge>> more than two <<def_branch,branches>>.
+
+[[def_orphan]]orphan::
+ The act of getting on a <<def_branch,branch>> that does not
+ exist yet (i.e., an <<def_unborn,unborn>> branch). After
+ such an operation, the commit first created becomes a commit
+ without a parent, starting a new history.
+
+[[def_origin]]origin::
+ The default upstream <<def_repository,repository>>. Most projects have
+ at least one upstream project which they track. By default
+ 'origin' is used for that purpose. New upstream updates
+ will be fetched into <<def_remote_tracking_branch,remote-tracking branches>> named
+ origin/name-of-upstream-branch, which you can see using
+ `git branch -r`.
+
+[[def_overlay]]overlay::
+ Only update and add files to the working directory, but don't
+ delete them, similar to how 'cp -R' would update the contents
+ in the destination directory. This is the default mode in a
+ <<def_checkout,checkout>> when checking out files from the
+ <<def_index,index>> or a <<def_tree-ish,tree-ish>>. In
+ contrast, no-overlay mode also deletes tracked files not
+ present in the source, similar to 'rsync --delete'.
+
+[[def_pack]]pack::
+ A set of objects which have been compressed into one file (to save space
+ or to transmit them efficiently).
+
+[[def_pack_index]]pack index::
+ The list of identifiers, and other information, of the objects in a
+ <<def_pack,pack>>, to assist in efficiently accessing the contents of a
+ pack.
+
+[[def_pathspec]]pathspec::
+ Pattern used to limit paths in Git commands.
++
+Pathspecs are used on the command line of "git ls-files", "git
+ls-tree", "git add", "git grep", "git diff", "git checkout",
+and many other commands to
+limit the scope of operations to some subset of the tree or
+working tree. See the documentation of each command for whether
+paths are relative to the current directory or toplevel. The
+pathspec syntax is as follows:
++
+--
+
+* any path matches itself
+* the pathspec up to the last slash represents a
+ directory prefix. The scope of that pathspec is
+ limited to that subtree.
+* the rest of the pathspec is a pattern for the remainder
+ of the pathname. Paths relative to the directory
+ prefix will be matched against that pattern using fnmatch(3);
+ in particular, '*' and '?' _can_ match directory separators.
+
+--
++
+For example, Documentation/*.jpg will match all .jpg files
+in the Documentation subtree,
+including Documentation/chapter_1/figure_1.jpg.
++
+A pathspec that begins with a colon `:` has special meaning. In the
+short form, the leading colon `:` is followed by zero or more "magic
+signature" letters (which optionally is terminated by another colon `:`),
+and the remainder is the pattern to match against the path.
+The "magic signature" consists of ASCII symbols that are neither
+alphanumeric, glob, regex special characters nor colon.
+The optional colon that terminates the "magic signature" can be
+omitted if the pattern begins with a character that does not belong to
+"magic signature" symbol set and is not a colon.
++
+In the long form, the leading colon `:` is followed by an open
+parenthesis `(`, a comma-separated list of zero or more "magic words",
+and a close parentheses `)`, and the remainder is the pattern to match
+against the path.
++
+A pathspec with only a colon means "there is no pathspec". This form
+should not be combined with other pathspec.
++
+--
+top;;
+ The magic word `top` (magic signature: `/`) makes the pattern
+ match from the root of the working tree, even when you are
+ running the command from inside a subdirectory.
+
+literal;;
+ Wildcards in the pattern such as `*` or `?` are treated
+ as literal characters.
+
+icase;;
+ Case insensitive match.
+
+glob;;
+ Git treats the pattern as a shell glob suitable for
+ consumption by fnmatch(3) with the FNM_PATHNAME flag:
+ wildcards in the pattern will not match a / in the pathname.
+ For example, "Documentation/{asterisk}.html" matches
+ "Documentation/git.html" but not "Documentation/ppc/ppc.html"
+ or "tools/perf/Documentation/perf.html".
++
+Two consecutive asterisks ("`**`") in patterns matched against
+full pathname may have special meaning:
+
+ - A leading "`**`" followed by a slash means match in all
+ directories. For example, "`**/foo`" matches file or directory
+ "`foo`" anywhere, the same as pattern "`foo`". "`**/foo/bar`"
+ matches file or directory "`bar`" anywhere that is directly
+ under directory "`foo`".
+
+ - A trailing "`/**`" matches everything inside. For example,
+ "`abc/**`" matches all files inside directory "abc", relative
+ to the location of the `.gitignore` file, with infinite depth.
+
+ - A slash followed by two consecutive asterisks then a slash
+ matches zero or more directories. For example, "`a/**/b`"
+ matches "`a/b`", "`a/x/b`", "`a/x/y/b`" and so on.
+
+ - Other consecutive asterisks are considered invalid.
++
+Glob magic is incompatible with literal magic.
+
+attr;;
+After `attr:` comes a space separated list of "attribute
+requirements", all of which must be met in order for the
+path to be considered a match; this is in addition to the
+usual non-magic pathspec pattern matching.
+See linkgit:gitattributes[5].
++
+Each of the attribute requirements for the path takes one of
+these forms:
+
+- "`ATTR`" requires that the attribute `ATTR` be set.
+
+- "`-ATTR`" requires that the attribute `ATTR` be unset.
+
+- "`ATTR=VALUE`" requires that the attribute `ATTR` be
+ set to the string `VALUE`.
+
+- "`!ATTR`" requires that the attribute `ATTR` be
+ unspecified.
++
+Note that when matching against a tree object, attributes are still
+obtained from working tree, not from the given tree object.
+
+exclude;;
+ After a path matches any non-exclude pathspec, it will be run
+ through all exclude pathspecs (magic signature: `!` or its
+ synonym `^`). If it matches, the path is ignored. When there
+ is no non-exclude pathspec, the exclusion is applied to the
+ result set as if invoked without any pathspec.
+--
+
+[[def_parent]]parent::
+ A <<def_commit_object,commit object>> contains a (possibly empty) list
+ of the logical predecessor(s) in the line of development, i.e. its
+ parents.
+
+[[def_peel]]peel::
+ The action of recursively <<def_dereference,dereferencing>> a
+ <<def_tag_object,tag object>>.
+
+[[def_pickaxe]]pickaxe::
+ The term <<def_pickaxe,pickaxe>> refers to an option to the diffcore
+ routines that help select changes that add or delete a given text
+ string. With the `--pickaxe-all` option, it can be used to view the full
+ <<def_changeset,changeset>> that introduced or removed, say, a
+ particular line of text. See linkgit:git-diff[1].
+
+[[def_plumbing]]plumbing::
+ Cute name for <<def_core_git,core Git>>.
+
+[[def_porcelain]]porcelain::
+ Cute name for programs and program suites depending on
+ <<def_core_git,core Git>>, presenting a high level access to
+ core Git. Porcelains expose more of a <<def_SCM,SCM>>
+ interface than the <<def_plumbing,plumbing>>.
+
+[[def_per_worktree_ref]]per-worktree ref::
+ Refs that are per-<<def_worktree,worktree>>, rather than
+ global. This is presently only <<def_HEAD,HEAD>> and any refs
+ that start with `refs/bisect/`, but might later include other
+ unusual refs.
+
+[[def_pseudoref]]pseudoref::
+ A ref that has different semantics than normal refs. These refs can be
+ read via normal Git commands, but cannot be written to by commands like
+ linkgit:git-update-ref[1].
++
+The following pseudorefs are known to Git:
+
+ - `FETCH_HEAD` is written by linkgit:git-fetch[1] or linkgit:git-pull[1]. It
+ may refer to multiple object IDs. Each object ID is annotated with metadata
+ indicating where it was fetched from and its fetch status.
+
+ - `MERGE_HEAD` is written by linkgit:git-merge[1] when resolving merge
+ conflicts. It contains all commit IDs which are being merged.
+
+[[def_pull]]pull::
+ Pulling a <<def_branch,branch>> means to <<def_fetch,fetch>> it and
+ <<def_merge,merge>> it. See also linkgit:git-pull[1].
+
+[[def_push]]push::
+ Pushing a <<def_branch,branch>> means to get the branch's
+ <<def_head_ref,head ref>> from a remote <<def_repository,repository>>,
+ find out if it is an ancestor to the branch's local
+ head ref, and in that case, putting all
+ objects, which are <<def_reachable,reachable>> from the local
+ head ref, and which are missing from the remote
+ repository, into the remote
+ <<def_object_database,object database>>, and updating the remote
+ head ref. If the remote <<def_head,head>> is not an
+ ancestor to the local head, the push fails.
+
+[[def_reachable]]reachable::
+ All of the ancestors of a given <<def_commit,commit>> are said to be
+ "reachable" from that commit. More
+ generally, one <<def_object,object>> is reachable from
+ another if we can reach the one from the other by a <<def_chain,chain>>
+ that follows <<def_tag,tags>> to whatever they tag,
+ <<def_commit_object,commits>> to their parents or trees, and
+ <<def_tree_object,trees>> to the trees or <<def_blob_object,blobs>>
+ that they contain.
+
+[[def_reachability_bitmap]]reachability bitmaps::
+ Reachability bitmaps store information about the
+ <<def_reachable,reachability>> of a selected set of commits in
+ a packfile, or a multi-pack index (MIDX), to speed up object search.
+ The bitmaps are stored in a ".bitmap" file. A repository may have at
+ most one bitmap file in use. The bitmap file may belong to either one
+ pack, or the repository's multi-pack index (if it exists).
+
+[[def_rebase]]rebase::
+ To reapply a series of changes from a <<def_branch,branch>> to a
+ different base, and reset the <<def_head,head>> of that branch
+ to the result.
+
+[[def_ref]]ref::
+ A name that points to an <<def_object_name,object name>> or
+ another ref (the latter is called a <<def_symref,symbolic ref>>).
+ For convenience, a ref can sometimes be abbreviated when used
+ as an argument to a Git command; see linkgit:gitrevisions[7]
+ for details.
+ Refs are stored in the <<def_repository,repository>>.
++
+The ref namespace is hierarchical.
+Ref names must either start with `refs/` or be located in the root of
+the hierarchy. For the latter, their name must follow these rules:
++
+ - The name consists of only upper-case characters or underscores.
+
+ - The name ends with "`_HEAD`" or is equal to "`HEAD`".
++
+There are some irregular refs in the root of the hierarchy that do not
+match these rules. The following list is exhaustive and shall not be
+extended in the future:
++
+ - `AUTO_MERGE`
+
+ - `BISECT_EXPECTED_REV`
+
+ - `NOTES_MERGE_PARTIAL`
+
+ - `NOTES_MERGE_REF`
+
+ - `MERGE_AUTOSTASH`
++
+Different subhierarchies are used for different purposes. For example,
+the `refs/heads/` hierarchy is used to represent local branches whereas
+the `refs/tags/` hierarchy is used to represent local tags..
+
+[[def_reflog]]reflog::
+ A reflog shows the local "history" of a ref. In other words,
+ it can tell you what the 3rd last revision in _this_ repository
+ was, and what was the current state in _this_ repository,
+ yesterday 9:14pm. See linkgit:git-reflog[1] for details.
+
+[[def_refspec]]refspec::
+ A "refspec" is used by <<def_fetch,fetch>> and
+ <<def_push,push>> to describe the mapping between remote
+ <<def_ref,ref>> and local ref. See linkgit:git-fetch[1] or
+ linkgit:git-push[1] for details.
+
+[[def_remote]]remote repository::
+ A <<def_repository,repository>> which is used to track the same
+ project but resides somewhere else. To communicate with remotes,
+ see <<def_fetch,fetch>> or <<def_push,push>>.
+
+[[def_remote_tracking_branch]]remote-tracking branch::
+ A <<def_ref,ref>> that is used to follow changes from another
+ <<def_repository,repository>>. It typically looks like
+ 'refs/remotes/foo/bar' (indicating that it tracks a branch named
+ 'bar' in a remote named 'foo'), and matches the right-hand-side of
+ a configured fetch <<def_refspec,refspec>>. A remote-tracking
+ branch should not contain direct modifications or have local
+ commits made to it.
+
+[[def_repository]]repository::
+ A collection of <<def_ref,refs>> together with an
+ <<def_object_database,object database>> containing all objects
+ which are <<def_reachable,reachable>> from the refs, possibly
+ accompanied by meta data from one or more <<def_porcelain,porcelains>>. A
+ repository can share an object database with other repositories
+ via <<def_alternate_object_database,alternates mechanism>>.
+
+[[def_resolve]]resolve::
+ The action of fixing up manually what a failed automatic
+ <<def_merge,merge>> left behind.
+
+[[def_revision]]revision::
+ Synonym for <<def_commit,commit>> (the noun).
+
+[[def_rewind]]rewind::
+ To throw away part of the development, i.e. to assign the
+ <<def_head,head>> to an earlier <<def_revision,revision>>.
+
+[[def_SCM]]SCM::
+ Source code management (tool).
+
+[[def_SHA1]]SHA-1::
+ "Secure Hash Algorithm 1"; a cryptographic hash function.
+ In the context of Git used as a synonym for <<def_object_name,object name>>.
+
+[[def_shallow_clone]]shallow clone::
+ Mostly a synonym to <<def_shallow_repository,shallow repository>>
+ but the phrase makes it more explicit that it was created by
+ running `git clone --depth=...` command.
+
+[[def_shallow_repository]]shallow repository::
+ A shallow <<def_repository,repository>> has an incomplete
+ history some of whose <<def_commit,commits>> have <<def_parent,parents>> cauterized away (in other
+ words, Git is told to pretend that these commits do not have the
+ parents, even though they are recorded in the <<def_commit_object,commit
+ object>>). This is sometimes useful when you are interested only in the
+ recent history of a project even though the real history recorded in the
+ upstream is much larger. A shallow repository
+ is created by giving the `--depth` option to linkgit:git-clone[1], and
+ its history can be later deepened with linkgit:git-fetch[1].
+
+[[def_stash]]stash entry::
+ An <<def_object,object>> used to temporarily store the contents of a
+ <<def_dirty,dirty>> working directory and the index for future reuse.
+
+[[def_submodule]]submodule::
+ A <<def_repository,repository>> that holds the history of a
+ separate project inside another repository (the latter of
+ which is called <<def_superproject, superproject>>).
+
+[[def_superproject]]superproject::
+ A <<def_repository,repository>> that references repositories
+ of other projects in its working tree as <<def_submodule,submodules>>.
+ The superproject knows about the names of (but does not hold
+ copies of) commit objects of the contained submodules.
+
+[[def_symref]]symref::
+ Symbolic reference: instead of containing the <<def_SHA1,SHA-1>> id
+ itself, it is of the format 'ref: refs/some/thing' and when referenced,
+ it recursively <<def_dereference,dereferences>> to this reference.
+ '<<def_HEAD,HEAD>>' is a prime example of a symref. Symbolic references
+ are manipulated with the linkgit:git-symbolic-ref[1] command.
+
+[[def_tag]]tag::
+ A <<def_ref,ref>> under `refs/tags/` namespace that points to an
+ object of an arbitrary type (typically a tag points to either a
+ <<def_tag_object,tag>> or a <<def_commit_object,commit object>>).
+ In contrast to a <<def_head,head>>, a tag is not updated by
+ the `commit` command. A Git tag has nothing to do with a Lisp
+ tag (which would be called an <<def_object_type,object type>>
+ in Git's context). A tag is most typically used to mark a particular
+ point in the commit ancestry <<def_chain,chain>>.
+
+[[def_tag_object]]tag object::
+ An <<def_object,object>> containing a <<def_ref,ref>> pointing to
+ another object, which can contain a message just like a
+ <<def_commit_object,commit object>>. It can also contain a (PGP)
+ signature, in which case it is called a "signed tag object".
+
+[[def_topic_branch]]topic branch::
+ A regular Git <<def_branch,branch>> that is used by a developer to
+ identify a conceptual line of development. Since branches are very easy
+ and inexpensive, it is often desirable to have several small branches
+ that each contain very well defined concepts or small incremental yet
+ related changes.
+
+[[def_trailer]]trailer::
+ Key-value metadata. Trailers are optionally found at the end of
+ a commit message. Might be called "footers" or "tags" in other
+ communities. See linkgit:git-interpret-trailers[1].
+
+[[def_tree]]tree::
+ Either a <<def_working_tree,working tree>>, or a <<def_tree_object,tree
+ object>> together with the dependent <<def_blob_object,blob>> and tree objects
+ (i.e. a stored representation of a working tree).
+
+[[def_tree_object]]tree object::
+ An <<def_object,object>> containing a list of file names and modes along
+ with refs to the associated blob and/or tree objects. A
+ <<def_tree,tree>> is equivalent to a <<def_directory,directory>>.
+
+[[def_tree-ish]]tree-ish (also treeish)::
+ A <<def_tree_object,tree object>> or an <<def_object,object>> that can
+ be recursively <<def_dereference,dereferenced>> to a tree object.
+ Dereferencing a <<def_commit_object,commit object>> yields the tree
+ object corresponding to the <<def_revision,revision>>'s top
+ <<def_directory,directory>>.
+ The following are all tree-ishes:
+ a <<def_commit-ish,commit-ish>>,
+ a tree object,
+ a <<def_tag_object,tag object>> that points to a tree object,
+ a tag object that points to a tag object that points to a tree
+ object,
+ etc.
+
+[[def_unborn]]unborn::
+ The <<def_HEAD,HEAD>> can point at a <<def_branch,branch>>
+ that does not yet exist and that does not have any commit on
+ it yet, and such a branch is called an unborn branch. The
+ most typical way users encounter an unborn branch is by
+ creating a repository anew without cloning from elsewhere.
+ The HEAD would point at the 'main' (or 'master', depending
+ on your configuration) branch that is yet to be born. Also
+ some operations can get you on an unborn branch with their
+ <<def_orphan,orphan>> option.
+
+
+[[def_unmerged_index]]unmerged index::
+ An <<def_index,index>> which contains unmerged
+ <<def_index_entry,index entries>>.
+
+[[def_unreachable_object]]unreachable object::
+ An <<def_object,object>> which is not <<def_reachable,reachable>> from a
+ <<def_branch,branch>>, <<def_tag,tag>>, or any other reference.
+
+[[def_upstream_branch]]upstream branch::
+ The default <<def_branch,branch>> that is merged into the branch in
+ question (or the branch in question is rebased onto). It is configured
+ via branch.<name>.remote and branch.<name>.merge. If the upstream branch
+ of 'A' is 'origin/B' sometimes we say "'A' is tracking 'origin/B'".
+
+[[def_working_tree]]working tree::
+ The tree of actual checked out files. The working tree normally
+ contains the contents of the <<def_HEAD,HEAD>> commit's tree,
+ plus any local changes that you have made but not yet committed.
+
+[[def_worktree]]worktree::
+ A repository can have zero (i.e. bare repository) or one or
+ more worktrees attached to it. One "worktree" consists of a
+ "working tree" and repository metadata, most of which are
+ shared among other worktrees of a single repository, and
+ some of which are maintained separately per worktree
+ (e.g. the index, HEAD and pseudorefs like MERGE_HEAD,
+ per-worktree refs and per-worktree configuration file).
diff --git a/howto-index.adoc b/howto-index.adoc
new file mode 100644
index 0000000..def9ddb
--- /dev/null
+++ b/howto-index.adoc
@@ -0,0 +1,109 @@
+Git Howto Index
+===============
+
+Here is a collection of mailing list postings made by various
+people describing how they use Git in their workflow.
+
+* link:howto/.html[]
+
+When a vulnerability is reported, we follow these guidelines to
+assess the vulnerability, create and review a fix, and coordinate embargoed
+security releases.
+
+
+* link:howto/.html[] by Junio C Hamano <gitster@pobox.com>
+
+This how-to explains a method for keeping a
+project's history correct when using git pull.
+
+
+* link:howto/.html[] by Junio C Hamano <gitster@pobox.com>
+
+Imagine that Git development is racing along as usual, when our friendly
+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.
+
+
+* link:howto/.html[] by Eric S. Raymond <esr@thyrsus.com>
+
+This is how-to documentation for people who want to add extension
+commands to Git. It should be read alongside builtin.h.
+
+
+* link:howto/.html[] by Junio C Hamano <gitster@pobox.com>
+
+In this article, JC talks about how he rebases the
+public "seen" branch using the core Git tools when he updates
+the "master" branch, and how "rebase" works. Also discussed
+is how this applies to individual developers who sends patches
+upstream.
+
+
+* link:howto/.html[] by Junio C Hamano <gitster@pobox.com>
+
+In this how-to article, JC talks about how he
+uses the post-update hook to automate Git documentation page
+shown at https://www.kernel.org/pub/software/scm/git/docs/.
+
+
+* link:howto/.html[] by Linus Torvalds <torvalds@linux-foundation.org>
+
+Some tricks to reconstruct blob objects in order to fix
+a corrupted repository.
+
+
+* link:howto/.html[] by Jeff King <peff@peff.net>
+
+Recovering a corrupted object when no good copy is available.
+
+
+* link:howto/.html[] by Linus Torvalds <torvalds@linux-foundation.org>, Junio C Hamano <gitster@pobox.com>
+
+Sometimes a branch that was already merged to the mainline
+is later found to be faulty. Linus and Junio give guidance on
+recovering from such a premature merge and continuing development
+after the offending branch is fixed.
+
+
+* link:howto/.html[] by Junio C Hamano <gitster@pobox.com>
+
+In this article, JC gives a small real-life example of using
+'git revert' command, and using a temporary branch and tag for safety
+and easier sanity checking.
+
+
+* link:howto/.html[] by Junio C Hamano <gitster@pobox.com>
+
+In this article, JC describes how to separate topic branches.
+
+
+* link:howto/.html[] by Rutger Nijlunsing <rutger@nospam.com>
+
+
+
+* link:howto/.html[] by Junio C Hamano <gitster@pobox.com> and Carl Baldwin <cnb@fc.hp.com>
+
+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.
+
+
+* link:howto/.html[]
+
+
+
+* link:howto/.html[] by Sean <seanlkml@sympatico.ca>
+
+In this article, Sean demonstrates how one can use the subtree merge
+strategy.
+
+
+* link:howto/.html[] by Junio C Hamano <gitster@pobox.com>
+
+Beginning v1.7.9, a contributor can push a signed tag to her
+publishing repository and ask her integrator to pull it. This assures the
+integrator that the pulled history is authentic and allows others to
+later validate it.
+
+
diff --git a/howto-index.html b/howto-index.html
index 1971c06..54a12da 100644
--- a/howto-index.html
+++ b/howto-index.html
@@ -450,7 +450,7 @@
<div class="ulist">
<ul>
<li>
-<p><a href="howto/coordinate-embargoed-releases.html">coordinate-embargoed-releases</a></p>
+<p><a href="howto/.html" class="bare">howto/.html</a></p>
</li>
</ul>
</div>
@@ -462,7 +462,7 @@
<div class="ulist">
<ul>
<li>
-<p><a href="howto/keep-canonical-history-correct.html">keep-canonical-history-correct</a> by Junio C Hamano <<a href="mailto:gitster@pobox.com">gitster@pobox.com</a>></p>
+<p><a href="howto/.html" class="bare">howto/.html</a> by Junio C Hamano <<a href="mailto:gitster@pobox.com">gitster@pobox.com</a>></p>
</li>
</ul>
</div>
@@ -473,7 +473,7 @@
<div class="ulist">
<ul>
<li>
-<p><a href="howto/maintain-git.html">maintain-git</a> by Junio C Hamano <<a href="mailto:gitster@pobox.com">gitster@pobox.com</a>></p>
+<p><a href="howto/.html" class="bare">howto/.html</a> by Junio C Hamano <<a href="mailto:gitster@pobox.com">gitster@pobox.com</a>></p>
</li>
</ul>
</div>
@@ -486,7 +486,7 @@
<div class="ulist">
<ul>
<li>
-<p><a href="howto/new-command.html">new-command</a> by Eric S. Raymond <<a href="mailto:esr@thyrsus.com">esr@thyrsus.com</a>></p>
+<p><a href="howto/.html" class="bare">howto/.html</a> by Eric S. Raymond <<a href="mailto:esr@thyrsus.com">esr@thyrsus.com</a>></p>
</li>
</ul>
</div>
@@ -497,7 +497,7 @@
<div class="ulist">
<ul>
<li>
-<p><a href="howto/rebase-from-internal-branch.html">rebase-from-internal-branch</a> by Junio C Hamano <<a href="mailto:gitster@pobox.com">gitster@pobox.com</a>></p>
+<p><a href="howto/.html" class="bare">howto/.html</a> by Junio C Hamano <<a href="mailto:gitster@pobox.com">gitster@pobox.com</a>></p>
</li>
</ul>
</div>
@@ -511,7 +511,7 @@
<div class="ulist">
<ul>
<li>
-<p><a href="howto/rebuild-from-update-hook.html">rebuild-from-update-hook</a> by Junio C Hamano <<a href="mailto:gitster@pobox.com">gitster@pobox.com</a>></p>
+<p><a href="howto/.html" class="bare">howto/.html</a> by Junio C Hamano <<a href="mailto:gitster@pobox.com">gitster@pobox.com</a>></p>
</li>
</ul>
</div>
@@ -523,7 +523,7 @@
<div class="ulist">
<ul>
<li>
-<p><a href="howto/recover-corrupted-blob-object.html">recover-corrupted-blob-object</a> by Linus Torvalds <<a href="mailto:torvalds@linux-foundation.org">torvalds@linux-foundation.org</a>></p>
+<p><a href="howto/.html" class="bare">howto/.html</a> by Linus Torvalds <<a href="mailto:torvalds@linux-foundation.org">torvalds@linux-foundation.org</a>></p>
</li>
</ul>
</div>
@@ -534,7 +534,7 @@
<div class="ulist">
<ul>
<li>
-<p><a href="howto/recover-corrupted-object-harder.html">recover-corrupted-object-harder</a> by Jeff King <<a href="mailto:peff@peff.net">peff@peff.net</a>></p>
+<p><a href="howto/.html" class="bare">howto/.html</a> by Jeff King <<a href="mailto:peff@peff.net">peff@peff.net</a>></p>
</li>
</ul>
</div>
@@ -544,7 +544,7 @@
<div class="ulist">
<ul>
<li>
-<p><a href="howto/revert-a-faulty-merge.html">revert-a-faulty-merge</a> by Linus Torvalds <<a href="mailto:torvalds@linux-foundation.org">torvalds@linux-foundation.org</a>>, Junio C Hamano <<a href="mailto:gitster@pobox.com">gitster@pobox.com</a>></p>
+<p><a href="howto/.html" class="bare">howto/.html</a> by Linus Torvalds <<a href="mailto:torvalds@linux-foundation.org">torvalds@linux-foundation.org</a>>, Junio C Hamano <<a href="mailto:gitster@pobox.com">gitster@pobox.com</a>></p>
</li>
</ul>
</div>
@@ -557,7 +557,7 @@
<div class="ulist">
<ul>
<li>
-<p><a href="howto/revert-branch-rebase.html">revert-branch-rebase</a> by Junio C Hamano <<a href="mailto:gitster@pobox.com">gitster@pobox.com</a>></p>
+<p><a href="howto/.html" class="bare">howto/.html</a> by Junio C Hamano <<a href="mailto:gitster@pobox.com">gitster@pobox.com</a>></p>
</li>
</ul>
</div>
@@ -569,7 +569,7 @@
<div class="ulist">
<ul>
<li>
-<p><a href="howto/separating-topic-branches.html">separating-topic-branches</a> by Junio C Hamano <<a href="mailto:gitster@pobox.com">gitster@pobox.com</a>></p>
+<p><a href="howto/.html" class="bare">howto/.html</a> by Junio C Hamano <<a href="mailto:gitster@pobox.com">gitster@pobox.com</a>></p>
</li>
</ul>
</div>
@@ -579,10 +579,10 @@
<div class="ulist">
<ul>
<li>
-<p><a href="howto/setup-git-server-over-http.html">setup-git-server-over-http</a> by Rutger Nijlunsing <<a href="mailto:rutger@nospam.com">rutger@nospam.com</a>></p>
+<p><a href="howto/.html" class="bare">howto/.html</a> by Rutger Nijlunsing <<a href="mailto:rutger@nospam.com">rutger@nospam.com</a>></p>
</li>
<li>
-<p><a href="howto/update-hook-example.html">update-hook-example</a> by Junio C Hamano <<a href="mailto:gitster@pobox.com">gitster@pobox.com</a>> and Carl Baldwin <<a href="mailto:cnb@fc.hp.com">cnb@fc.hp.com</a>></p>
+<p><a href="howto/.html" class="bare">howto/.html</a> by Junio C Hamano <<a href="mailto:gitster@pobox.com">gitster@pobox.com</a>> and Carl Baldwin <<a href="mailto:cnb@fc.hp.com">cnb@fc.hp.com</a>></p>
</li>
</ul>
</div>
@@ -594,10 +594,10 @@
<div class="ulist">
<ul>
<li>
-<p><a href="howto/use-git-daemon.html">use-git-daemon</a></p>
+<p><a href="howto/.html" class="bare">howto/.html</a></p>
</li>
<li>
-<p><a href="howto/using-merge-subtree.html">using-merge-subtree</a> by Sean <<a href="mailto:seanlkml@sympatico.ca">seanlkml@sympatico.ca</a>></p>
+<p><a href="howto/.html" class="bare">howto/.html</a> by Sean <<a href="mailto:seanlkml@sympatico.ca">seanlkml@sympatico.ca</a>></p>
</li>
</ul>
</div>
@@ -608,7 +608,7 @@
<div class="ulist">
<ul>
<li>
-<p><a href="howto/using-signed-tag-in-pull-request.html">using-signed-tag-in-pull-request</a> by Junio C Hamano <<a href="mailto:gitster@pobox.com">gitster@pobox.com</a>></p>
+<p><a href="howto/.html" class="bare">howto/.html</a> by Junio C Hamano <<a href="mailto:gitster@pobox.com">gitster@pobox.com</a>></p>
</li>
</ul>
</div>
@@ -621,7 +621,7 @@
</div>
<div id="footer">
<div id="footer-text">
-Last updated 2025-01-10 09:39:58 -0800
+Last updated 2025-02-14 21:38:16 -0800
</div>
</div>
</body>
diff --git a/howto/coordinate-embargoed-releases.adoc b/howto/coordinate-embargoed-releases.adoc
new file mode 100644
index 0000000..b9cb95e
--- /dev/null
+++ b/howto/coordinate-embargoed-releases.adoc
@@ -0,0 +1,246 @@
+Content-type: text/asciidoc
+Abstract: When a vulnerability is reported, we follow these guidelines to
+ assess the vulnerability, create and review a fix, and coordinate embargoed
+ security releases.
+
+How we coordinate embargoed releases
+------------------------------------
+
+To protect Git users from critical vulnerabilities, we do not just release
+fixed versions like regular maintenance releases. Instead, we coordinate
+releases with packagers, keeping the fixes under an embargo until the release
+date. That way, users will have a chance to upgrade on that date, no matter
+what Operating System or distribution they run.
+
+The `git-security` mailing list
+-------------------------------
+
+Responsible disclosures of vulnerabilities, analysis, proposed fixes as
+well as the orchestration of coordinated embargoed releases all happen on the
+`git-security` mailing list at <git-security@googlegroups.com>.
+
+In this context, the term "embargo" refers to the time period that information
+about a vulnerability is kept under wraps and only shared on a need-to-know
+basis. This is necessary to protect Git's users from bad actors who would
+otherwise be made aware of attack vectors that could be exploited. "Lifting the
+embargo" refers to publishing the version that fixes the vulnerabilities.
+
+Audience of the `git-security` mailing list
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Anybody may contact the `git-security` mailing list by sending an email
+to <git-security@googlegroups.com>, though the archive is closed to the
+public and only accessible to subscribed members.
+
+There are a few dozen subscribed members: core Git developers who are trusted
+with addressing vulnerabilities, and stakeholders (i.e. owners of products
+affected by security vulnerabilities in Git).
+
+Most of the discussions revolve around assessing the severity of the reported
+issue (including the decision whether the report is security-relevant or can be
+redirected to the public mailing list), how to remediate the issue, determining
+the timeline of the disclosure as well as aligning priorities and
+requirements.
+
+Communications
+~~~~~~~~~~~~~~
+
+If you are a stakeholder, it is a good idea to pay close attention to the
+discussions, as pertinent information may be buried in the middle of a lively
+conversation that might not look relevant to your interests. For example, the
+tentative timeline might be agreed upon in the middle of discussing code
+comment formatting in one of the patches and whether or not to combine fixes
+for multiple, separate vulnerabilities into the same embargoed release. Most
+mail threads are not usually structured specifically to communicate
+agreements, assessments or timelines.
+
+Typical timeline
+----------------
+
+- A potential vulnerability is reported to the `git-security` mailing list.
+
+- The members of the git-security list start a discussion to give an initial
+ assessment of the severity of the reported potential vulnerability.
+ We aspire to do so within a few days.
+
+- After discussion, if consensus is reached that it is not critical enough
+ to warrant any embargo, the reporter is redirected to the public Git mailing
+ list. This ends the reporter's interaction with the `git-security` list.
+
+- If it is deemed critical enough for an embargo, ideas are presented on how to
+ address the vulnerability.
+
+- Usually around that time, the Git maintainer or their delegate(s) open a draft
+ security advisory in the `git/git` repository on GitHub (see below for more
+ details).
+
+- Code review can take place in a variety of different locations,
+ depending on context. These are: patches sent inline on the git-security list,
+ a private fork on GitHub associated with the draft security advisory, or the
+ git/cabal repository.
+
+- Contributors working on a fix should consider beginning by sending
+ patches to the git-security list (inline with the original thread), since they
+ are accessible to all subscribers, along with the original reporter.
+
+- Once the review has settled and everyone involved in the review agrees that
+ the patches are nearing the finish line, the Git maintainer, and others
+ determine a release date as well as the release trains that are serviced. The
+ decision regarding which versions need a backported fix is based on input from
+ the reporter, the contributor who worked on the patches, and from
+ stakeholders. Operators of hosting sites who may want to analyze whether the
+ given issue is exploited via any of the repositories they host, and binary
+ packagers who want to make sure their product gets patched adequately against
+ the vulnerability, for example, may want to give their input at this stage.
+
+- While the Git community does its best to accommodate the specific timeline
+ requests of the various binary packagers, the nature of the issue may preclude
+ a prolonged release schedule. For fixes deemed urgent, it may be in the best
+ interest of the Git users community to shorten the disclosure and release
+ timeline, and packagers may need to adapt accordingly.
+
+- Subsequently, branches with the fixes are pushed to the git/cabal repository.
+
+- The tags are created by the Git maintainer and pushed to the same repository.
+
+- The Git for Windows, Git for macOS, BSD, Debian, etc. maintainers prepare the
+ corresponding release artifacts, based on the tags created that have been
+ prepared by the Git maintainer.
+
+- The release artifacts prepared by various binary packagers can be
+ made available to stakeholders under embargo via a mail to the
+ `git-security` list.
+
+- Less than a week before the release, a mail with the relevant information is
+ sent to <distros@vs.openwall.org> (see below), a list used to pre-announce
+ embargoed releases of open source projects to the stakeholders of all major
+ distributions of Linux as well as other OSes.
+
+- Public communication is then prepared in advance of the release date. This
+ includes blog posts and mails to the Git and Git for Windows mailing lists.
+
+- On the day of the release, at around 10am Pacific Time, the Git maintainer
+ pushes the tag and the `master` branch to the public repository, then sends
+ out an announcement mail.
+
+- Once the tag is pushed, the Git for Windows maintainer publishes the
+ corresponding tag and creates a GitHub Release with the associated release
+ artifacts (Git for Windows installer, Portable Git, MinGit, etc).
+
+- Git for Windows release is then announced via a mail to the public Git and
+ Git for Windows mailing lists as well as via a tweet.
+
+- Ditto for distribution packagers for Linux and other platforms:
+ their releases are announced via their preferred channels.
+
+- A mail to <oss-security@lists.openwall.org> (see below for details) is sent
+ as a follow-up to the <distros@vs.openwall.org> one, describing the
+ vulnerability in detail, often including a proof of concept of an exploit.
+
+Note: The Git project makes no guarantees about timelines, but aims to keep
+embargoes reasonably short in the interest of keeping Git's users safe.
+
+Opening a Security Advisory draft
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The first step is to https://github.com/git/git/security/advisories/new[open
+an advisory]. Technically, this is not necessary. However, it is the most
+convenient way to obtain the CVE number and it gives us a private repository
+associated with it that can be used to collaborate on a fix.
+
+Notifying the Linux distributions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+At most two weeks before release date, we need to send a notification to
+<distros@vs.openwall.org>, preferably less than 7 days before the release date.
+This will reach most (all?) Linux distributions. See an example below, and the
+guidelines for this mailing list at
+https://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists[here].
+
+Once the version has been published, we send a note about that to oss-security.
+As an example, see https://www.openwall.com/lists/oss-security/2019/12/13/1[the
+v2.24.1 mail];
+https://oss-security.openwall.org/wiki/mailing-lists/oss-security[Here] are
+their guidelines.
+
+The mail to oss-security should also describe the exploit, and give credit to
+the reporter(s): security researchers still receive too little respect for the
+invaluable service they provide, and public credit goes a long way to keep them
+paid by their respective organizations.
+
+Technically, describing any exploit can be delayed up to 7 days, but we usually
+refrain from doing that, including it right away.
+
+As a courtesy we typically attach a Git bundle (as `.tar.xz` because the list
+will drop `.bundle` attachments) in the mail to distros@ so that the involved
+parties can take care of integrating/backporting them. This bundle is typically
+created using a command like this:
+
+ git bundle create cve-xxx.bundle ^origin/master vA.B.C vD.E.F
+ tar cJvf cve-xxx.bundle.tar.xz cve-xxx.bundle
+
+Example mail to distros@vs.openwall.org
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+....
+To: distros@vs.openwall.org
+Cc: git-security@googlegroups.com, <other people involved in the report/fix>
+Subject: [vs] Upcoming Git security fix release
+
+Team,
+
+The Git project will release new versions on <date> at 10am Pacific Time or
+soon thereafter. I have attached a Git bundle (embedded in a `.tar.xz` to avoid
+it being dropped) which you can fetch into a clone of
+https://github.com/git/git via `git fetch --tags /path/to/cve-xxx.bundle`,
+containing the tags for versions <versions>.
+
+You can verify with `git tag -v <tag>` that the versions were signed by
+the Git maintainer, using the same GPG key as e.g. v2.24.0.
+
+Please use these tags to prepare `git` packages for your various
+distributions, using the appropriate tagged versions. The added test cases
+help verify the correctness.
+
+The addressed issues are:
+
+<list of CVEs with a short description, typically copy/pasted from Git's
+release notes, usually demo exploit(s), too>
+
+Credit for finding the vulnerability goes to <reporter>, credit for fixing
+it goes to <developer>.
+
+Thanks,
+<name>
+
+....
+
+Example mail to oss-security@lists.openwall.com
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+....
+To: oss-security@lists.openwall.com
+Cc: git-security@googlegroups.com, <other people involved in the report/fix>
+Subject: git: <copy from security advisory>
+
+Team,
+
+The Git project released new versions on <date>, addressing <CVE>.
+
+All supported platforms are affected in one way or another, and all Git
+versions all the way back to <version> are affected. The fixed versions are:
+<versions>.
+
+Link to the announcement: <link to lore.kernel.org/git>
+
+We highly recommend to upgrade.
+
+The addressed issues are:
+* <list of CVEs and their explanations, along with demo exploits>
+
+Credit for finding the vulnerability goes to <reporter>, credit for fixing
+it goes to <developer>.
+
+Thanks,
+<name>
+....
\ No newline at end of file
diff --git a/howto/keep-canonical-history-correct.adoc b/howto/keep-canonical-history-correct.adoc
new file mode 100644
index 0000000..e98f032
--- /dev/null
+++ b/howto/keep-canonical-history-correct.adoc
@@ -0,0 +1,216 @@
+From: Junio C Hamano <gitster@pobox.com>
+Date: Wed, 07 May 2014 13:15:39 -0700
+Subject: Beginner question on "Pull is mostly evil"
+Abstract: This how-to explains a method for keeping a
+ project's history correct when using git pull.
+Content-type: text/asciidoc
+
+Keep authoritative canonical history correct with git pull
+==========================================================
+
+Sometimes a new project integrator will end up with project history
+that appears to be "backwards" from what other project developers
+expect. This howto presents a suggested integration workflow for
+maintaining a central repository.
+
+Suppose that the central repository has this history:
+
+------------
+ ---o---o---A
+------------
+
+which ends at commit `A` (time flows from left to right and each node
+in the graph is a commit, lines between them indicating parent-child
+relationship).
+
+Then you clone it and work on your own commits, which leads you to
+have this history in *your* repository:
+
+------------
+ ---o---o---A---B---C
+------------
+
+Imagine your coworker did the same and built on top of `A` in *his*
+repository in the meantime, and then pushed it to the
+central repository:
+
+------------
+ ---o---o---A---X---Y---Z
+------------
+
+Now, if you `git push` at this point, because your history that leads
+to `C` lacks `X`, `Y` and `Z`, it will fail. You need to somehow make
+the tip of your history a descendant of `Z`.
+
+One suggested way to solve the problem is "fetch and then merge", aka
+`git pull`. When you fetch, your repository will have a history like
+this:
+
+------------
+ ---o---o---A---B---C
+ \
+ X---Y---Z
+------------
+
+Once you run merge after that, while still on *your* branch, i.e. `C`,
+you will create a merge `M` and make the history look like this:
+
+------------
+ ---o---o---A---B---C---M
+ \ /
+ X---Y---Z
+------------
+
+`M` is a descendant of `Z`, so you can push to update the central
+repository. Such a merge `M` does not lose any commit in both
+histories, so in that sense it may not be wrong, but when people want
+to talk about "the authoritative canonical history that is shared
+among the project participants", i.e. "the trunk", they often view
+it as "commits you see by following the first-parent chain", and use
+this command to view it:
+
+------------
+ $ git log --first-parent
+------------
+
+For all other people who observed the central repository after your
+coworker pushed `Z` but before you pushed `M`, the commit on the trunk
+used to be `o-o-A-X-Y-Z`. But because you made `M` while you were on
+`C`, `M`'s first parent is `C`, so by pushing `M` to advance the
+central repository, you made `X-Y-Z` a side branch, not on the trunk.
+
+You would rather want to have a history of this shape:
+
+------------
+ ---o---o---A---X---Y---Z---M'
+ \ /
+ B-----------C
+------------
+
+so that in the first-parent chain, it is clear that the project first
+did `X` and then `Y` and then `Z` and merged a change that consists of
+two commits `B` and `C` that achieves a single goal. You may have
+worked on fixing the bug #12345 with these two patches, and the merge
+`M'` with swapped parents can say in its log message "Merge
+fix-bug-12345". Having a way to tell `git pull` to create a merge
+but record the parents in reverse order may be a way to do so.
+
+Note that I said "achieves a single goal" above, because this is
+important. "Swapping the merge order" only covers a special case
+where the project does not care too much about having unrelated
+things done on a single merge but cares a lot about first-parent
+chain.
+
+There are multiple schools of thought about the "trunk" management.
+
+ 1. Some projects want to keep a completely linear history without any
+ merges. Obviously, swapping the merge order would not match their
+ taste. You would need to flatten your history on top of the
+ updated upstream to result in a history of this shape instead:
++
+------------
+ ---o---o---A---X---Y---Z---B---C
+------------
++
+with `git pull --rebase` or something.
+
+ 2. Some projects tolerate merges in their history, but do not worry
+ too much about the first-parent order, and allow fast-forward
+ merges. To them, swapping the merge order does not hurt, but
+ it is unnecessary.
+
+ 3. Some projects want each commit on the "trunk" to do one single
+ thing. The output of `git log --first-parent` in such a project
+ would show either a merge of a side branch that completes a single
+ theme, or a single commit that completes a single theme by itself.
+ If your two commits `B` and `C` (or they may even be two groups of
+ commits) were solving two independent issues, then the merge `M'`
+ we made in the earlier example by swapping the merge order is
+ still not up to the project standard. It merges two unrelated
+ efforts `B` and `C` at the same time.
+
+For projects in the last category (Git itself is one of them),
+individual developers would want to prepare a history more like
+this:
+
+------------
+ C0--C1--C2 topic-c
+ /
+ ---o---o---A master
+ \
+ B0--B1--B2 topic-b
+------------
+
+That is, keeping separate topics on separate branches, perhaps like
+so:
+
+------------
+ $ git clone $URL work && cd work
+ $ git checkout -b topic-b master
+ $ ... work to create B0, B1 and B2 to complete one theme
+ $ git checkout -b topic-c master
+ $ ... same for the theme of topic-c
+------------
+
+And then
+
+------------
+ $ git checkout master
+ $ git pull --ff-only
+------------
+
+would grab `X`, `Y` and `Z` from the upstream and advance your master
+branch:
+
+------------
+ C0--C1--C2 topic-c
+ /
+ ---o---o---A---X---Y---Z master
+ \
+ B0--B1--B2 topic-b
+------------
+
+And then you would merge these two branches separately:
+
+------------
+ $ git merge topic-b
+ $ git merge topic-c
+------------
+
+to result in
+
+------------
+ C0--C1---------C2
+ / \
+ ---o---o---A---X---Y---Z---M---N
+ \ /
+ B0--B1-----B2
+------------
+
+and push it back to the central repository.
+
+It is very much possible that while you are merging topic-b and
+topic-c, somebody again advanced the history in the central repository
+to put `W` on top of `Z`, and make your `git push` fail.
+
+In such a case, you would rewind to discard `M` and `N`, update the
+tip of your 'master' again and redo the two merges:
+
+------------
+ $ git reset --hard origin/master
+ $ git pull --ff-only
+ $ git merge topic-b
+ $ git merge topic-c
+------------
+
+The procedure will result in a history that looks like this:
+
+------------
+ C0--C1--------------C2
+ / \
+ ---o---o---A---X---Y---Z---W---M'--N'
+ \ /
+ B0--B1---------B2
+------------
+
+See also https://git-blame.blogspot.com/2013/09/fun-with-first-parent-history.html
diff --git a/howto/maintain-git.adoc b/howto/maintain-git.adoc
new file mode 100644
index 0000000..45e2599
--- /dev/null
+++ b/howto/maintain-git.adoc
@@ -0,0 +1,595 @@
+From: Junio C Hamano <gitster@pobox.com>
+Date: Wed, 21 Nov 2007 16:32:55 -0800
+Subject: Addendum to "MaintNotes"
+Abstract: Imagine that Git development is racing along as usual, when our friendly
+ 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
+===================
+
+Activities
+----------
+
+The maintainer's Git time is spent on three activities.
+
+ - Communication (45%)
+
+ Mailing list discussions on general design, fielding user
+ questions, diagnosing bug reports; reviewing, commenting on,
+ suggesting alternatives to, and rejecting patches.
+
+ - Integration (50%)
+
+ Applying new patches from the contributors while spotting and
+ correcting minor mistakes, shuffling the integration and
+ testing branches, pushing the results out, cutting the
+ releases, and making announcements.
+
+ - Own development (5%)
+
+ Scratching my own itch and sending proposed patch series out.
+
+The Policy
+----------
+
+The policy on Integration is informally mentioned in "A Note
+from the maintainer" message, which is periodically posted to
+the mailing list after each feature release is made:
+
+ - Feature releases are numbered as vX.Y.0 and are meant to
+ contain bugfixes and enhancements in any area, including
+ functionality, performance and usability, without regression.
+
+ - Maintenance releases are numbered as vX.Y.Z (0 < Z) and are meant
+ to contain only bugfixes for the corresponding vX.Y.0 feature
+ release and earlier maintenance releases vX.Y.W (W < Z).
+
+ - The 'master' branch is used to prepare for the next feature
+ release. In other words, at some point, the tip of 'master'
+ branch is tagged as vX.(Y+1).0, when vX.Y.0 is the latest
+ feature release.
+
+ - 'maint' branch is used to prepare for the next maintenance
+ release. After the feature release vX.Y.0 is made, the tip
+ of 'maint' branch is set to that release, and bugfixes will
+ accumulate on the branch, and at some point, the tip of the
+ branch is tagged with vX.Y.1, vX.Y.2, and so on.
+
+ - 'next' branch is used to publish changes (both enhancements
+ and fixes) that (1) have worthwhile goal, (2) are in a fairly
+ good shape suitable for everyday use, (3) but have not yet
+ demonstrated to be regression free. Reviews from contributors on
+ the mailing list help to make the determination. After a topic
+ is merged to 'next', it is tested for at least 7 calendar days
+ before getting merged to 'master'.
+
+ - 'seen' branch is used to publish other proposed changes that do
+ not yet pass the criteria set for 'next' (see above), but there
+ is no promise that 'seen' will contain everything. A topic that
+ had no reviewer reaction may not be picked up.
+
+ - A new topic will first get merged to 'seen', unless it is
+ trivially correct and clearly urgent, in which case it may be
+ directly merged to 'next' or even to 'master'.
+
+ - If a topic that was picked up to 'seen' becomes and stays
+ inactive for 3 calendar weeks without having seen a clear
+ consensus that it is good enough to be moved to 'next', the
+ topic may be discarded from 'seen'. Interested parties are
+ still free to revive the topic. For the purpose of this
+ guideline, the definition of being "inactive" is that nobody
+ has discussed the topic, no new iteration of the topic was
+ posted, and no responses to the review comments were given.
+
+ - The tips of 'master' and 'maint' branches will not be rewound to
+ allow people to build their own customization on top of them.
+ Early in a new development cycle, 'next' is rewound to the tip of
+ 'master' once, but otherwise it will not be rewound until the end
+ of the cycle.
+
+ - Usually 'master' contains all of 'maint' and 'next' contains all
+ of 'master'. 'seen' contains all the topics merged to 'next', but
+ is rebuilt directly on 'master'.
+
+ - The tip of 'master' is meant to be more stable than any
+ tagged releases, and the users are encouraged to follow it.
+
+ - The 'next' branch is where new action takes place, and the
+ users are encouraged to test it so that regressions and bugs
+ are found before new topics are merged to 'master'.
+
+ - When a problem is found in a topic in 'next', the topic is marked
+ not to be merged to 'master'. Follow-up patches are discussed on
+ the mailing list and applied to the topic after being reviewed and
+ then the topic is merged (again) to 'next'. After going through
+ the usual testing in 'next', the entire (fixed) topic is merged
+ to 'master'.
+
+ - One release cycle for a feature release is expected to last for
+ eight to ten weeks. A few "release candidate" releases are
+ expected to be tagged about a week apart before the final
+ release, and a "preview" release is tagged about a week before
+ the first release candidate gets tagged.
+
+ - After the preview release is tagged, topics that were well
+ reviewed may be merged to 'master' before spending the usual 7
+ calendar days in 'next', with the expectation that any bugs in
+ them can be caught and fixed in the release candidates before
+ the final release.
+
+ - After the first release candidate is tagged, the contributors are
+ strongly encouraged to focus on finding and fixing new regressions
+ introduced during the cycle, over addressing old bugs and any new
+ features. Topics stop getting merged down from 'next' to 'master',
+ and new topics stop getting merged to 'next'. Unless they are fixes
+ to new regressions in the cycle, that is.
+
+ - Soon after a feature release is made, the tip of 'maint' gets
+ fast-forwarded to point at the release. Topics that have been
+ kept in 'next' are merged down to 'master' and a new development
+ cycle starts.
+
+
+Note that before v1.9.0 release, the version numbers used to be
+structured slightly differently. vX.Y.Z were feature releases while
+vX.Y.Z.W were maintenance releases for vX.Y.Z.
+
+Because most of the lines of code in Git are written by individual
+contributors, and contributions come in the form of e-mailed patches
+published on the mailing list, the project maintains a mapping from
+individual commits to the Message-Id of the e-mail that resulted in
+the commit, to help tracking the origin of the changes. The notes
+in "refs/notes/amlog" are used for this purpose, and are published
+along with the broken-out branches to the maintainer's repository.
+
+A Typical Git Day
+-----------------
+
+A typical Git day for the maintainer implements the above policy
+by doing the following:
+
+ - Scan mailing list. Respond with review comments, suggestions
+ etc. Kibitz. Collect potentially usable patches from the
+ mailing list. Patches about a single topic go to one mailbox (I
+ read my mail in Gnus, and type \C-o to save/append messages in
+ files in mbox format).
+
+ - Write his own patches to address issues raised on the list but
+ nobody has stepped up to solve. Send it out just like other
+ contributors do, and pick them up just like patches from other
+ contributors (see above).
+
+ - Review the patches in the saved mailboxes. Edit proposed log
+ message for typofixes and clarifications, and add Acks
+ collected from the list. Edit patch to incorporate "Oops,
+ that should have been like this" fixes from the discussion.
+
+ - Classify the collected patches and handle 'master' and
+ 'maint' updates:
+
+ - Obviously correct fixes that pertain to the tip of 'maint'
+ are directly applied to 'maint'.
+
+ - Obviously correct fixes that pertain to the tip of 'master'
+ are directly applied to 'master'.
+
+ - Other topics are not handled in this step.
+
+ This step is done with "git am".
+
+ $ git checkout master ;# or "git checkout maint"
+ $ git am -sc3 mailbox
+ $ make test
+
+ In practice, almost no patch directly goes to 'master' or
+ 'maint'.
+
+ Applying the e-mailed patches using "git am" automatically records
+ the mappings from 'Message-Id' to the applied commit in the "amlog"
+ notes. Periodically check that this is working with "git show -s
+ --notes=amlog $commit".
+
+ This mapping is maintained with the aid of the "post-applypatch"
+ hook found in the 'todo' branch. That hook should be installed
+ before applying patches. It is also helpful to carry forward any
+ relevant amlog entries when rebasing, so the following config may
+ be useful:
+
+ [notes]
+ rewriteRef = refs/notes/amlog
+
+ Avoid "cherry-pick", as it does not propagate notes by design. Use
+ either "git commit --amend" or "git rebase" to make corrections to
+ an existing commit, even for a single-patch topic.
+
+ Make sure that a push refspec for 'refs/notes/amlog' is in the
+ remote configuration for publishing repositories. A few sample
+ configurations look like the following:
+
+ [remote "github"]
+ url = https://github.com/gitster/git
+ pushurl = github.com:gitster/git.git
+ mirror
+
+ [remote "github2"]
+ url = https://github.com/git/git
+ fetch = +refs/heads/*:refs/remotes/github2/*
+ pushurl = github.com:git/git.git
+ push = refs/heads/maint:refs/heads/maint
+ push = refs/heads/master:refs/heads/master
+ push = refs/heads/next:refs/heads/next
+ push = +refs/heads/seen:refs/heads/seen
+ push = +refs/notes/amlog
+
+ - Review the last issue of "What's cooking" message, review the
+ topics ready for merging (topic->master and topic->maint). Use
+ "Meta/cook -w" script (where Meta/ contains a checkout of the
+ 'todo' branch) to aid this step.
+
+ And perform the merge. Use "Meta/Reintegrate -e" script (see
+ later) to aid this step.
+
+ $ Meta/cook -w last-issue-of-whats-cooking.mbox
+
+ $ git checkout master ;# or "git checkout maint"
+ $ echo ai/topic | Meta/Reintegrate -e ;# "git merge ai/topic"
+ $ git log -p ORIG_HEAD.. ;# final review
+ $ git diff ORIG_HEAD.. ;# final review
+ $ make test ;# final review
+
+ If the tip of 'master' is updated, also generate the preformatted
+ documentation and push the out result to git-htmldocs and
+ git-manpages repositories.
+
+ - Handle the remaining patches:
+
+ - Anything unobvious that is applicable to 'master' (in other
+ words, does not depend on anything that is still in 'next'
+ and not in 'master') is applied to a new topic branch that
+ is forked from the tip of 'master' (or the last feature release,
+ which is a bit older than 'master'). This includes both
+ enhancements and unobvious fixes to 'master'. A topic
+ branch is named as ai/topic where "ai" is two-letter string
+ named after author's initial and "topic" is a descriptive name
+ of the topic (in other words, "what's the series is about").
+
+ - An unobvious fix meant for 'maint' is applied to a new
+ topic branch that is forked from the tip of 'maint' (or the
+ oldest and still relevant maintenance branch). The
+ topic may be named as ai/maint-topic.
+
+ - Changes that pertain to an existing topic are applied to
+ the branch, but:
+
+ - obviously correct ones are applied first;
+
+ - questionable ones are discarded or applied to near the tip;
+
+ - Replacement patches to an existing topic are accepted only
+ for commits not in 'next'.
+
+ The initial round is done with:
+
+ $ git checkout ai/topic ;# or "git checkout -b ai/topic master"
+ $ git am -sc3 --whitespace=warn mailbox
+
+ and replacing an existing topic with subsequent round is done with:
+
+ $ git checkout master...ai/topic ;# try to reapply to the same base
+ $ git am -sc3 --whitespace=warn mailbox
+
+ to prepare the new round on a detached HEAD, and then
+
+ $ git range-diff @{-1}...
+ $ git diff @{-1}
+
+ to double check what changed since the last round, and finally
+
+ $ git checkout -B @{-1}
+
+ to conclude (the last step is why a topic already in 'next' is
+ not replaced but updated incrementally).
+
+ Whether it is the initial round or a subsequent round, the topic
+ may not build even in isolation, or may break the build when
+ merged to integration branches due to bugs. There may already
+ be obvious and trivial improvements suggested on the list. The
+ maintainer often adds an extra commit, with "SQUASH???" in its
+ title, to fix things up, before publishing the integration
+ branches to make it usable by other developers for testing.
+ These changes are what the maintainer is not 100% committed to
+ (trivial typofixes etc. are often squashed directly into the
+ patches that need fixing, without being applied as a separate
+ "SQUASH???" commit), so that they can be removed easily as needed.
+ The expectation is that the original author will make corrections
+ in a reroll.
+
+ - By now, new topic branches are created and existing topic
+ branches are updated. The integration branches 'next', 'jch',
+ and 'seen' need to be updated to contain them.
+
+ - If there are topics that have been merged to 'master' and should
+ be merged to 'maint', merge them to 'maint', and update the
+ release notes to the next maintenance release.
+
+ - Review the latest issue of "What's cooking" again. Are topics
+ that have been sufficiently long in 'next' ready to be merged to
+ 'master'? Are topics we saw earlier and are in 'seen' now got
+ positive reviews and are ready to be merged to 'next'?
+
+ - If there are topics that have been cooking in 'next' long enough
+ and should be merged to 'master', merge them to 'master', and
+ update the release notes to the next feature release.
+
+ - If there were patches directly made on 'maint', merge 'maint' to
+ 'master'; make sure that the result is what you want.
+
+ $ git checkout master
+ $ git merge -m "Sync with 'maint'" --no-log maint
+ $ git log -p --first-parent ORIG_HEAD..
+ $ make test
+
+ - Prepare to update the 'jch' branch, which is used to represent
+ somewhere between 'master' and 'seen' and often is slightly ahead
+ of 'next', and the 'seen' branch, which is used to hold the rest.
+
+ $ Meta/Reintegrate master..jch >Meta/redo-jch.sh
+
+ The result is a script that lists topics to be merged in order to
+ rebuild the current 'jch'. Do the same for 'seen'.
+
+ - Review the Meta/redo-jch.sh and Meta/redo-seen.sh scripts. The
+ former should have a line '### match next'---the idea is that
+ merging the topics listed before the line on top of 'master'
+ should result in a tree identical to that of 'next'.
+
+ - As newly created topics are usually merged near the tip of
+ 'seen', add them to the end of the Meta/redo-seen.sh script.
+ Among the topics that were in 'seen', there may be ones that
+ are not quite ready for 'next' but are getting there. Move
+ them from Meta/redo-seen.sh to the end of Meta/redo-jch.sh.
+ The expectation is that you'd use 'jch' as your daily driver
+ as the first guinea pig, so you should choose carefully.
+
+ - Now we are ready to start rebuilding 'jch' and merging topics to
+ 'next'. For each branch whose tip is not merged to 'next', one
+ of three things can happen:
+
+ - The commits are all next-worthy; merge the topic to next;
+ - The new parts are of mixed quality, but earlier ones are
+ next-worthy; merge the early parts to next;
+ - Nothing is next-worthy; do not do anything.
+
+ This step is aided with Meta/redo-jch.sh script created earlier.
+ If a topic that was already in 'next' gained a patch, the script
+ would list it as "ai/topic~1". To include the new patch to the
+ updated 'next', drop the "~1" part; to keep it excluded, do not
+ touch the line.
+
+ If a topic that was not in 'next' should be merged to 'next', add
+ it before the '### match next' line. Then:
+
+ $ git checkout --detach master
+ $ sh Meta/redo-jch.sh -c1
+
+ to rebuild the 'jch' branch from scratch. "-c1" tells the script
+ to stop merging at the first line that begins with '###'
+ (i.e. the "### match next" line you added earlier).
+
+ At this point, build-test the result. It may reveal semantic
+ conflicts (e.g. a topic renamed a variable, another added a new
+ reference to the variable under its old name), in which case
+ prepare an appropriate merge-fix first (see appendix), and
+ rebuild the 'jch' branch from scratch, starting at the tip of
+ 'master', this time without using "-c1" to merge all topics.
+
+ Then do the same to 'next'.
+
+ $ git checkout next
+ $ sh Meta/redo-jch.sh -c1 -e
+
+ The "-e" option allows the merge message that comes from the
+ history of the topic and the comments in the "What's cooking" to
+ be edited. The resulting tree should match 'jch^{/^### match next'}'
+ as the same set of topics are merged on 'master'; otherwise there
+ is a mismerge. Investigate why and do not proceed until the mismerge
+ is found and rectified.
+
+ If 'master' was updated before you started redoing 'next', then
+
+ $ git diff 'jch^{/^### match next}' next
+
+ would show differences that went into 'master' (which 'jch' has,
+ but 'next' does not yet---often it is updates to the release
+ notes). Merge 'master' back to 'next' if that is the case.
+
+ $ git merge -m "Sync with 'master'" --no-log master
+
+ When all is well, clean up the redo-jch.sh script with
+
+ $ sh Meta/redo-jch.sh -u
+
+ This removes topics listed in the script that have already been
+ merged to 'master'. This may lose '### match next' marker;
+ add it again to the appropriate place when it happens.
+
+ - Rebuild 'seen' on top of 'jch'.
+
+ $ git checkout -B seen jch
+ $ sh Meta/redo-seen.sh
+
+ When all is well, clean up the redo-seen.sh script with
+
+ $ sh Meta/redo-seen.sh -u
+
+ Double check by running
+
+ $ git branch --no-merged seen '??/*'
+
+ to see there is no unexpected leftover topics.
+
+ At this point, build-test the result for semantic conflicts, and
+ if there are, prepare an appropriate merge-fix first (see
+ appendix), and rebuild the 'seen' branch from scratch, starting at
+ the tip of 'jch'.
+
+ - Update "What's cooking" message to review the updates to
+ existing topics, newly added topics and graduated topics.
+
+ This step is helped with Meta/cook script.
+
+ $ Meta/cook
+
+ This script inspects the history between master..seen, finds tips
+ of topic branches, compares what it found with the current
+ contents in Meta/whats-cooking.txt, and updates that file.
+ Topics not listed in the file but are found in master..seen are
+ added to the "New topics" section, topics listed in the file that
+ are no longer found in master..seen are moved to the "Graduated to
+ master" section, and topics whose commits changed their states
+ (e.g. used to be only in 'seen', now merged to 'next') are updated
+ with change markers "<<" and ">>".
+
+ Look for lines enclosed in "<<" and ">>"; they hold contents from
+ old file that are replaced by this integration round. After
+ verifying them, remove the old part. Review the description for
+ each topic and update its doneness and plan as needed. To review
+ the updated plan, run
+
+ $ Meta/cook -w
+
+ which will pick up comments given to the topics, such as "Will
+ merge to 'next'", etc. (see Meta/cook script to learn what kind
+ of phrases are supported).
+
+ - Compile, test and install all four (five) integration branches;
+ Meta/Dothem script may aid this step.
+
+ - Format documentation if the 'master' branch was updated;
+ Meta/dodoc.sh script may aid this step.
+
+ - Push the integration branches out to public places; Meta/pushall
+ script may aid this step.
+
+Observations
+------------
+
+Some observations to be made.
+
+ * Each topic is tested individually, and also together with other
+ topics cooking first in 'seen', then in 'jch' and then in 'next'.
+ Until it matures, no part of it is merged to 'master'.
+
+ * A topic already in 'next' can get fixes while still in
+ 'next'. Such a topic will have many merges to 'next' (in
+ other words, "git log --first-parent next" will show many
+ "Merge branch 'ai/topic' to next" for the same topic.
+
+ * An unobvious fix for 'maint' is cooked in 'next' and then
+ merged to 'master' to make extra sure it is Ok and then
+ merged to 'maint'.
+
+ * Even when 'next' becomes empty (in other words, all topics
+ prove stable and are merged to 'master' and "git diff master
+ next" shows empty), it has tons of merge commits that will
+ never be in 'master'.
+
+ * In principle, "git log --first-parent master..next" should
+ show nothing but merges (in practice, there are fixup commits
+ and reverts that are not merges).
+
+ * Commits near the tip of a topic branch that are not in 'next'
+ are fair game to be discarded, replaced or rewritten.
+ Commits already merged to 'next' will not be.
+
+ * Being in the 'next' branch is not a guarantee for a topic to
+ be included in the next feature release. Being in the
+ 'master' branch typically is.
+
+ * Due to the nature of "SQUASH???" fix-ups, if the original author
+ agrees with the suggested changes, it is OK to squash them to
+ appropriate patches in the next round (when the suggested change
+ is small enough, the author should not even bother with
+ "Helped-by"). It is also OK to drop them from the next round
+ when the original author does not agree with the suggestion, but
+ the author is expected to say why somewhere in the discussion.
+
+
+Appendix
+--------
+
+Preparing a "merge-fix"
+~~~~~~~~~~~~~~~~~~~~~~~
+
+A merge of two topics may not textually conflict but still have
+conflict at the semantic level. A classic example is for one topic
+to rename a variable and all its uses, while another topic adds a
+new use of the variable under its old name. When these two topics
+are merged together, the reference to the variable newly added by
+the latter topic will still use the old name in the result.
+
+The Meta/Reintegrate script that is used by redo-jch and redo-seen
+scripts implements a crude but usable way to work around this issue.
+When the script merges branch $X, it checks if "refs/merge-fix/$X"
+exists, and if so, the effect of it is squashed into the result of
+the mechanical merge. In other words,
+
+ $ echo $X | Meta/Reintegrate
+
+is roughly equivalent to this sequence:
+
+ $ git merge --rerere-autoupdate $X
+ $ git commit
+ $ git cherry-pick -n refs/merge-fix/$X
+ $ git commit --amend
+
+The goal of this "prepare a merge-fix" step is to come up with a
+commit that can be squashed into a result of mechanical merge to
+correct semantic conflicts.
+
+After finding that the result of merging branch "ai/topic" to an
+integration branch had such a semantic conflict, say seen~4, check the
+problematic merge out on a detached HEAD, edit the working tree to
+fix the semantic conflict, and make a separate commit to record the
+fix-up:
+
+ $ git checkout seen~4
+ $ git show -s --pretty=%s ;# double check
+ Merge branch 'ai/topic' to seen
+ $ edit
+ $ git commit -m 'merge-fix/ai/topic' -a
+
+Then make a reference "refs/merge-fix/ai/topic" to point at this
+result:
+
+ $ git update-ref refs/merge-fix/ai/topic HEAD
+
+Then double check the result by asking Meta/Reintegrate to redo the
+merge:
+
+ $ git checkout seen~5 ;# the parent of the problem merge
+ $ echo ai/topic | Meta/Reintegrate
+ $ git diff seen~4
+
+This time, because you prepared refs/merge-fix/ai/topic, the
+resulting merge should have been tweaked to include the fix for the
+semantic conflict.
+
+Note that this assumes that the order in which conflicting branches
+are merged does not change. If the reason why merging ai/topic
+branch needs this merge-fix is because another branch merged earlier
+to the integration branch changed the underlying assumption ai/topic
+branch made (e.g. ai/topic branch added a site to refer to a
+variable, while the other branch renamed that variable and adjusted
+existing use sites), and if you changed redo-jch (or redo-seen) script
+to merge ai/topic branch before the other branch, then the above
+merge-fix should not be applied while merging ai/topic, but should
+instead be applied while merging the other branch. You would need
+to move the fix to apply to the other branch, perhaps like this:
+
+ $ mf=refs/merge-fix
+ $ git update-ref $mf/$the_other_branch $mf/ai/topic
+ $ git update-ref -d $mf/ai/topic
diff --git a/howto/new-command.adoc b/howto/new-command.adoc
new file mode 100644
index 0000000..880c511
--- /dev/null
+++ b/howto/new-command.adoc
@@ -0,0 +1,106 @@
+From: Eric S. Raymond <esr@thyrsus.com>
+Abstract: This is how-to documentation for people who want to add extension
+ commands to Git. It should be read alongside builtin.h.
+Content-type: text/asciidoc
+
+How to integrate new subcommands
+================================
+
+This is how-to documentation for people who want to add extension
+commands to Git. It should be read alongside builtin.h.
+
+Runtime environment
+-------------------
+
+Git subcommands are standalone executables that live in the Git exec
+path, normally /usr/lib/git-core. The git executable itself is a
+thin wrapper that knows where the subcommands live, and runs them by
+passing command-line arguments to them.
+
+(If "git foo" is not found in the Git exec path, the wrapper
+will look in the rest of your $PATH for it. Thus, it's possible
+to write local Git extensions that don't live in system space.)
+
+Implementation languages
+------------------------
+
+Most subcommands are written in C or shell. A few are written in
+Perl.
+
+While we strongly encourage coding in portable C for portability,
+these specific scripting languages are also acceptable. We won't
+accept more without a very strong technical case, as we don't want
+to broaden the Git suite's required dependencies. Import utilities,
+surgical tools, remote helpers and other code at the edges of the
+Git suite are more lenient and we allow Python (and even Tcl/tk),
+but they should not be used for core functions.
+
+This may change in the future. Especially Python is not allowed in
+core because we need better Python integration in the Git Windows
+installer before we can be confident people in that environment
+won't experience an unacceptably large loss of capability.
+
+C commands are normally written as single modules, named after the
+command, that link a collection of functions called libgit. Thus,
+your command 'git-foo' would normally be implemented as a single
+"git-foo.c" (or "builtin/foo.c" if it is to be linked to the main
+binary); this organization makes it easy for people reading the code
+to find things.
+
+See the CodingGuidelines document for other guidance on what we consider
+good practice in C and shell, and api-builtin.txt for the support
+functions available to built-in commands written in C.
+
+What every extension command needs
+----------------------------------
+
+You must have a man page, written in asciidoc (this is what Git help
+followed by your subcommand name will display). Be aware that there is
+a local asciidoc configuration and macros which you should use. It's
+often helpful to start by cloning an existing page and replacing the
+text content.
+
+You must have a test, written to report in TAP (Test Anything Protocol).
+Tests are executables (usually shell scripts) that live in the 't'
+subdirectory of the tree. Each test name begins with 't' and a sequence
+number that controls where in the test sequence it will be executed;
+conventionally the rest of the name stem is that of the command
+being tested.
+
+Read the file t/README to learn more about the conventions to be used
+in writing tests, and the test support library.
+
+Integrating a command
+---------------------
+
+Here are the things you need to do when you want to merge a new
+subcommand into the Git tree.
+
+1. Don't forget to sign off your patch!
+
+2. Append your command name to one of the variables BUILTIN_OBJS,
+EXTRA_PROGRAMS, SCRIPT_SH, SCRIPT_PERL or SCRIPT_PYTHON.
+
+3. Drop its test in the t directory.
+
+4. If your command is implemented in an interpreted language with a
+p-code intermediate form, make sure .gitignore in the main directory
+includes a pattern entry that ignores such files. Python .pyc and
+.pyo files will already be covered.
+
+5. If your command has any dependency on a particular version of
+your language, document it in the INSTALL file.
+
+6. There is a file command-list.txt in the distribution main directory
+that categorizes commands by type, so they can be listed in appropriate
+subsections in the documentation's summary command list. Add an entry
+for yours. To understand the categories, look at command-list.txt
+in the main directory. If the new command is part of the typical Git
+workflow and you believe it common enough to be mentioned in 'git help',
+map this command to a common group in the column [common].
+
+7. Give the maintainer one paragraph to include in the RelNotes file
+to describe the new feature; a good place to do so is in the cover
+letter [PATCH 0/n].
+
+That's all there is to it.
diff --git a/howto/rebase-from-internal-branch.adoc b/howto/rebase-from-internal-branch.adoc
new file mode 100644
index 0000000..f2e10a7
--- /dev/null
+++ b/howto/rebase-from-internal-branch.adoc
@@ -0,0 +1,164 @@
+From: Junio C Hamano <gitster@pobox.com>
+To: git@vger.kernel.org
+Cc: Petr Baudis <pasky@suse.cz>, Linus Torvalds <torvalds@osdl.org>
+Subject: Re: sending changesets from the middle of a git tree
+Date: Sun, 14 Aug 2005 18:37:39 -0700
+Abstract: In this article, JC talks about how he rebases the
+ public "seen" branch using the core Git tools when he updates
+ 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
+> where Junio C Hamano <junkio@cox.net> told me that...
+>> Linus Torvalds <torvalds@osdl.org> writes:
+>>
+>> > Junio, maybe you want to talk about how you move patches from your
+>> > "seen" 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 kind of task StGIT is designed to do.
+
+I just have done a simpler one, this time using only the core
+Git tools.
+
+I had a handful of commits that were ahead of master in 'seen', and I
+wanted to add some documentation bypassing my usual habit of
+placing new things in 'seen' first. At the beginning, the commit
+ancestry graph looked like this:
+
+ *"seen" head
+ master --> #1 --> #2 --> #3
+
+So I started from master, made a bunch of edits, and committed:
+
+ $ git checkout master
+ $ cd Documentation; ed git.txt ...
+ $ cd ..; git add Documentation/*.txt
+ $ git commit -s
+
+After the commit, the ancestry graph would look like this:
+
+ *"seen" head
+ master^ --> #1 --> #2 --> #3
+ \
+ \---> master
+
+The old master is now master^ (the first parent of the master).
+The new master commit holds my documentation updates.
+
+Now I have to deal with "seen" branch.
+
+This is the kind of situation I used to have all the time when
+Linus was the maintainer and I was a contributor, when you look
+at "master" branch being the "maintainer" branch, and "seen"
+branch being the "contributor" branch. Your work started at the
+tip of the "maintainer" branch some time ago, you made a lot of
+progress in the meantime, and now the maintainer branch has some
+other commits you do not have yet. And "git rebase" was written
+with the explicit purpose of helping to maintain branches like
+"seen". You _could_ merge master to 'seen' and keep going, but if you
+eventually want to cherrypick and merge some but not necessarily
+all changes back to the master branch, it often makes later
+operations for _you_ easier if you rebase (i.e. carry forward
+your changes) "seen" rather than merge. So I ran "git rebase":
+
+ $ git checkout seen
+ $ git rebase master seen
+
+What this does is to pick all the commits since the current
+branch (note that I now am on "seen" branch) forked from the
+master branch, and forward port these changes.
+
+ master^ --> #1 --> #2 --> #3
+ \ *"seen" head
+ \---> master --> #1' --> #2' --> #3'
+
+The diff between master^ and #1 is applied to master and
+committed to create #1' commit with the commit information (log,
+author and date) taken from commit #1. On top of that #2' and #3'
+commits are made similarly out of #2 and #3 commits.
+
+Old #3 is not recorded in any of the .git/refs/heads/ file
+anymore, so after doing this you will have dangling commit if
+you ran fsck-cache, which is normal. After testing "seen", you
+can run "git prune" to get rid of those original three commits.
+
+While I am talking about "git rebase", I should talk about how
+to do cherrypicking using only the core Git tools.
+
+Let's go back to the earlier picture, with different labels.
+
+You, as an individual developer, cloned upstream repository and
+made a couple of commits on top of it.
+
+ *your "master" head
+ upstream --> #1 --> #2 --> #3
+
+You would want changes #2 and #3 incorporated in the upstream,
+while you feel that #1 may need further improvements. So you
+prepare #2 and #3 for e-mail submission.
+
+ $ git format-patch master^^ master
+
+This creates two files, 0001-XXXX.patch and 0002-XXXX.patch. Send
+them out "To: " your project maintainer and "Cc: " your mailing
+list. You could use contributed script git-send-email if
+your host has necessary perl modules for this, but your usual
+MUA would do as long as it does not corrupt whitespaces in the
+patch.
+
+Then you would wait, and you find out that the upstream picked
+up your changes, along with other changes.
+
+ where *your "master" head
+ upstream --> #1 --> #2 --> #3
+ used \
+ to be \--> #A --> #2' --> #3' --> #B --> #C
+ *upstream head
+
+The two commits #2' and #3' in the above picture record the same
+changes your e-mail submission for #2 and #3 contained, but
+probably with the new sign-off line added by the upstream
+maintainer and definitely with different committer and ancestry
+information, they are different objects from #2 and #3 commits.
+
+You fetch from upstream, but not merge.
+
+ $ git fetch upstream
+
+This leaves the updated upstream head in .git/FETCH_HEAD but
+does not touch your .git/HEAD or .git/refs/heads/master.
+You run "git rebase" now.
+
+ $ git rebase FETCH_HEAD master
+
+Earlier, I said that rebase applies all the commits from your
+branch on top of the upstream head. Well, I lied. "git rebase"
+is a bit smarter than that and notices that #2 and #3 need not
+be applied, so it only applies #1. The commit ancestry graph
+becomes something like this:
+
+ where *your old "master" head
+ upstream --> #1 --> #2 --> #3
+ used \ your new "master" head*
+ to be \--> #A --> #2' --> #3' --> #B --> #C --> #1'
+ *upstream
+ head
+
+Again, "git prune" would discard the disused commits #1-#3 and
+you continue on starting from the new "master" head, which is
+the #1' commit.
+
+-jc
diff --git a/howto/rebuild-from-update-hook.adoc b/howto/rebuild-from-update-hook.adoc
new file mode 100644
index 0000000..db219f5
--- /dev/null
+++ b/howto/rebuild-from-update-hook.adoc
@@ -0,0 +1,90 @@
+Subject: [HOWTO] Using post-update hook
+Message-ID: <7vy86o6usx.fsf@assigned-by-dhcp.cox.net>
+From: Junio C Hamano <gitster@pobox.com>
+Date: Fri, 26 Aug 2005 18:19:10 -0700
+Abstract: In this how-to article, JC talks about how he
+ uses the post-update hook to automate Git documentation page
+ shown at https://www.kernel.org/pub/software/scm/git/docs/.
+Content-type: text/asciidoc
+
+How to rebuild from update hook
+===============================
+
+The pages under https://www.kernel.org/pub/software/scm/git/docs/
+are built from Documentation/ directory of the git.git project
+and needed to be kept up-to-date. The www.kernel.org/ servers
+are mirrored and I was told that the origin of the mirror is on
+the machine $some.kernel.org, on which I was given an account
+when I took over Git maintainership from Linus.
+
+The directories relevant to this how-to are these two:
+
+ /pub/scm/git/git.git/ The public Git repository.
+ /pub/software/scm/git/docs/ The HTML documentation page.
+
+So I made a repository to generate the documentation under my
+home directory over there.
+
+ $ cd
+ $ mkdir doc-git && cd doc-git
+ $ git clone /pub/scm/git/git.git/ docgen
+
+What needs to happen is to update the $HOME/doc-git/docgen/
+working tree, build HTML docs there and install the result in
+/pub/software/scm/git/docs/ directory. So I wrote a little
+script:
+
+ $ cat >dododoc.sh <<\EOF
+ #!/bin/sh
+ cd $HOME/doc-git/docgen || exit
+
+ unset GIT_DIR
+
+ git pull /pub/scm/git/git.git/ master &&
+ cd Documentation &&
+ make install-webdoc
+ EOF
+
+Initially I used to run this by hand whenever I push into the
+public Git repository. Then I did a cron job that ran twice a
+day. The current round uses the post-update hook mechanism,
+like this:
+
+ $ cat >/pub/scm/git/git.git/hooks/post-update <<\EOF
+ #!/bin/sh
+ #
+ # An example hook script to prepare a packed repository for use over
+ # dumb transports.
+ #
+ # To enable this hook, make this file executable by "chmod +x post-update".
+
+ case " $* " in
+ *' refs/heads/master '*)
+ echo $HOME/doc-git/dododoc.sh | at now
+ ;;
+ esac
+ exec git-update-server-info
+ EOF
+ $ chmod +x /pub/scm/git/git.git/hooks/post-update
+
+There are four things worth mentioning:
+
+ - The update-hook is run after the repository accepts a "git
+ push", under my user privilege. It is given the full names
+ of refs that have been updated as arguments. My post-update
+ runs the dododoc.sh script only when the master head is
+ updated.
+
+ - When update-hook is run, GIT_DIR is set to '.' by the calling
+ receive-pack. This is inherited by the dododoc.sh run via
+ the "at" command, and needs to be unset; otherwise, "git
+ pull" it does into $HOME/doc-git/docgen/ repository would not
+ work correctly.
+
+ - The stdout of update hook script is not connected to git
+ push; I run the heavy part of the command inside "at", to
+ receive the execution report via e-mail.
+
+ - This is still crude and does not protect against simultaneous
+ make invocations stomping on each other. I would need to add
+ some locking mechanism for this.
diff --git a/howto/recover-corrupted-blob-object.adoc b/howto/recover-corrupted-blob-object.adoc
new file mode 100644
index 0000000..1b3b188
--- /dev/null
+++ b/howto/recover-corrupted-blob-object.adoc
@@ -0,0 +1,144 @@
+Date: Fri, 9 Nov 2007 08:28:38 -0800 (PST)
+From: Linus Torvalds <torvalds@linux-foundation.org>
+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 SHA-1 hash is cryptographically secure, the hash
+itself doesn't actually tell you anything, in order to fix a corrupt
+object you basically have to find the "original source" for it.
+
+The easiest way to do that is almost always to have backups, and find the
+same object somewhere else. Backups really are a good idea, and Git makes
+it pretty easy (if nothing else, just clone the repository somewhere else,
+and make sure that you do *not* use a hard-linked clone, and preferably
+not the same disk/machine).
+
+But since you don't seem to have backups right now, the good news is that
+especially with a single blob being corrupt, these things *are* somewhat
+debuggable.
+
+First off, move the corrupt object away, and *save* it. The most common
+cause of corruption so far has been memory corruption, but even so, there
+are people who would be interested in seeing the corruption - but it's
+basically impossible to judge the corruption until we can also see the
+original object, so right now the corrupt object is useless, but it's very
+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 SHA-1 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
+at all interesting. But what remains is still very useful. In particular,
+we now know which tree points to it!
+
+Now you can do
+
+ git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
+
+which will show something like
+
+ 100644 blob 8d14531846b95bfa3564b58ccfb7913a034323b8 .gitignore
+ 100644 blob ebf9bf84da0aab5ed944264a5db2a65fe3a3e883 .mailmap
+ 100644 blob ca442d313d86dc67e0a2e5d584b465bd382cbf5c COPYING
+ 100644 blob ee909f2cc49e54f0799a4739d24c4cb9151ae453 CREDITS
+ 040000 tree 0f5f709c17ad89e72bdbbef6ea221c69807009f6 Documentation
+ 100644 blob 1570d248ad9237e4fa6e4d079336b9da62d9ba32 Kbuild
+ 100644 blob 1c7c229a092665b11cd46a25dbd40feeb31661d9 MAINTAINERS
+ ...
+
+and you should now have a line that looks like
+
+ 10064 blob 4b9458b3786228369c63936db65827de3cc06200 my-magic-file
+
+in the output. This already tells you a *lot* it tells you what file the
+corrupt blob came from!
+
+Now, it doesn't tell you quite enough, though: it doesn't tell what
+*version* of the file didn't get correctly written! You might be really
+lucky, and it may be the version that you already have checked out in your
+working tree, in which case fixing this problem is really simple, just do
+
+ git hash-object -w my-magic-file
+
+again, and if it outputs the missing SHA-1 (4b945..) you're now all done!
+
+But that's the really lucky case, so let's assume that it was some older
+version that was broken. How do you tell which version it was?
+
+The easiest way to do it is to do
+
+ git log --raw --all --full-history -- subdirectory/my-magic-file
+
+and that will show you the whole log for that file (please realize that
+the tree you had may not be the top-level tree, so you need to figure out
+which subdirectory it was in on your own), and because you're asking for
+raw output, you'll now get something like
+
+ commit abc
+ Author:
+ Date:
+ ..
+ :100644 100644 4b9458b... newsha... M somedirectory/my-magic-file
+
+
+ commit xyz
+ Author:
+ Date:
+
+ ..
+ :100644 100644 oldsha... 4b9458b... M somedirectory/my-magic-file
+
+and this actually tells you what the *previous* and *subsequent* versions
+of that file were! So now you can look at those ("oldsha" and "newsha"
+respectively), and hopefully you have done commits often, and can
+re-create the missing my-magic-file version by looking at those older and
+newer versions!
+
+If you can do that, you can now recreate the missing object with
+
+ git hash-object -w <recreated-file>
+
+and your repository is good again!
+
+(Btw, you could have ignored the fsck, and started with doing a
+
+ git log --raw --all
+
+and just looked for the sha of the missing object (4b9458b..) in that
+whole thing. It's up to you - Git does *have* a lot of information, it is
+just missing one particular blob version.
+
+Trying to recreate trees and especially commits is *much* harder. So you
+were lucky that it's a blob. It's quite possible that you can recreate the
+thing.
+
+ Linus
diff --git a/howto/recover-corrupted-object-harder.adoc b/howto/recover-corrupted-object-harder.adoc
new file mode 100644
index 0000000..5efb4fe
--- /dev/null
+++ b/howto/recover-corrupted-object-harder.adoc
@@ -0,0 +1,479 @@
+Date: Wed, 16 Oct 2013 04:34:01 -0400
+From: Jeff King <peff@peff.net>
+Subject: pack corruption post-mortem
+Abstract: Recovering a corrupted object when no good copy is available.
+Content-type: text/asciidoc
+
+How to recover an object from scratch
+=====================================
+
+I was recently presented with a repository with a corrupted packfile,
+and was asked if the data was recoverable. This post-mortem describes
+the steps I took to investigate and fix the problem. I thought others
+might find the process interesting, and it might help somebody in the
+same situation.
+
+********************************
+Note: In this case, no good copy of the repository was available. For
+the much easier case where you can get the corrupted object from
+elsewhere, see link:recover-corrupted-blob-object.html[this howto].
+********************************
+
+I started with an fsck, which found a problem with exactly one object
+(I've used $pack and $obj below to keep the output readable, and also
+because I'll refer to them later):
+
+-----------
+ $ git fsck
+ error: $pack SHA1 checksum mismatch
+ error: index CRC mismatch for object $obj from $pack at offset 51653873
+ error: inflate: data stream error (incorrect data check)
+ error: cannot unpack $obj from $pack at offset 51653873
+-----------
+
+The pack checksum failing means a byte is munged somewhere, and it is
+presumably in the object mentioned (since both the index checksum and
+zlib were failing).
+
+Reading the zlib source code, I found that "incorrect data check" means
+that the adler-32 checksum at the end of the zlib data did not match the
+inflated data. So stepping the data through zlib would not help, as it
+did not fail until the very end, when we realize the CRC does not match.
+The problematic bytes could be anywhere in the object data.
+
+The first thing I did was pull the broken data out of the packfile. I
+needed to know how big the object was, which I found out with:
+
+------------
+ $ git show-index <$idx | cut -d' ' -f1 | sort -n | grep -A1 51653873
+ 51653873
+ 51664736
+------------
+
+Show-index gives us the list of objects and their offsets. We throw away
+everything but the offsets, and then sort them so that our interesting
+offset (which we got from the fsck output above) is followed immediately
+by the offset of the next object. Now we know that the object data is
+10863 bytes long, and we can grab it with:
+
+------------
+ dd if=$pack of=object bs=1 skip=51653873 count=10863
+------------
+
+I inspected a hexdump of the data, looking for any obvious bogosity
+(e.g., a 4K run of zeroes would be a good sign of filesystem
+corruption). But everything looked pretty reasonable.
+
+Note that the "object" file isn't fit for feeding straight to zlib; it
+has the git packed object header, which is variable-length. We want to
+strip that off so we can start playing with the zlib data directly. You
+can either work your way through it manually (the format is described in
+linkgit:gitformat-pack[5]),
+or you can walk through it in a debugger. I did the latter, creating a
+valid pack like:
+
+------------
+ # pack magic and version
+ printf 'PACK\0\0\0\2' >tmp.pack
+ # pack has one object
+ printf '\0\0\0\1' >>tmp.pack
+ # now add our object data
+ cat object >>tmp.pack
+ # and then append the pack trailer
+ /path/to/git.git/t/helper/test-tool sha1 -b <tmp.pack >trailer
+ cat trailer >>tmp.pack
+------------
+
+and then running "git index-pack tmp.pack" in the debugger (stop at
+unpack_raw_entry). Doing this, I found that there were 3 bytes of header
+(and the header itself had a sane type and size). So I stripped those
+off with:
+
+------------
+ dd if=object of=zlib bs=1 skip=3
+------------
+
+I ran the result through zlib's inflate using a custom C program. And
+while it did report the error, I did get the right number of output
+bytes (i.e., it matched git's size header that we decoded above). But
+feeding the result back to "git hash-object" didn't produce the same
+sha1. So there were some wrong bytes, but I didn't know which. The file
+happened to be C source code, so I hoped I could notice something
+obviously wrong with it, but I didn't. I even got it to compile!
+
+I also tried comparing it to other versions of the same path in the
+repository, hoping that there would be some part of the diff that didn't
+make sense. Unfortunately, this happened to be the only revision of this
+particular file in the repository, so I had nothing to compare against.
+
+So I took a different approach. Working under the guess that the
+corruption was limited to a single byte, I wrote a program to munge each
+byte individually, and try inflating the result. Since the object was
+only 10K compressed, that worked out to about 2.5M attempts, which took
+a few minutes.
+
+The program I used is here:
+
+----------------------------------------------
+#include <stdio.h>
+#include <unistd.h>
+#include <string.h>
+#include <signal.h>
+#include <zlib.h>
+
+static int try_zlib(unsigned char *buf, int len)
+{
+ /* make this absurdly large so we don't have to loop */
+ static unsigned char out[1024*1024];
+ z_stream z;
+ int ret;
+
+ memset(&z, 0, sizeof(z));
+ inflateInit(&z);
+
+ z.next_in = buf;
+ z.avail_in = len;
+ z.next_out = out;
+ z.avail_out = sizeof(out);
+
+ ret = inflate(&z, 0);
+ inflateEnd(&z);
+ return ret >= 0;
+}
+
+/* eye candy */
+static int counter = 0;
+static void progress(int sig)
+{
+ fprintf(stderr, "\r%d", counter);
+ alarm(1);
+}
+
+int main(void)
+{
+ /* oversized so we can read the whole buffer in */
+ unsigned char buf[1024*1024];
+ int len;
+ unsigned i, j;
+
+ signal(SIGALRM, progress);
+ alarm(1);
+
+ len = read(0, buf, sizeof(buf));
+ for (i = 0; i < len; i++) {
+ unsigned char c = buf[i];
+ for (j = 0; j <= 0xff; j++) {
+ buf[i] = j;
+
+ counter++;
+ if (try_zlib(buf, len))
+ printf("i=%d, j=%x\n", i, j);
+ }
+ buf[i] = c;
+ }
+
+ alarm(0);
+ fprintf(stderr, "\n");
+ return 0;
+}
+----------------------------------------------
+
+I compiled and ran with:
+
+-------
+ gcc -Wall -Werror -O3 munge.c -o munge -lz
+ ./munge <zlib
+-------
+
+
+There were a few false positives early on (if you write "no data" in the
+zlib header, zlib thinks it's just fine :) ). But I got a hit about
+halfway through:
+
+-------
+ i=5642, j=c7
+-------
+
+I let it run to completion, and got a few more hits at the end (where it
+was munging the CRC to match our broken data). So there was a good
+chance this middle hit was the source of the problem.
+
+I confirmed by tweaking the byte in a hex editor, zlib inflating the
+result (no errors!), and then piping the output into "git hash-object",
+which reported the sha1 of the broken object. Success!
+
+I fixed the packfile itself with:
+
+-------
+ chmod +w $pack
+ printf '\xc7' | dd of=$pack bs=1 seek=51659518 conv=notrunc
+ chmod -w $pack
+-------
+
+The `\xc7` comes from the replacement byte our "munge" program found.
+The offset 51659518 is derived by taking the original object offset
+(51653873), adding the replacement offset found by "munge" (5642), and
+then adding back in the 3 bytes of git header we stripped.
+
+After that, "git fsck" ran clean.
+
+As for the corruption itself, I was lucky that it was indeed a single
+byte. In fact, it turned out to be a single bit. The byte 0xc7 was
+corrupted to 0xc5. So presumably it was caused by faulty hardware, or a
+cosmic ray.
+
+And the aborted attempt to look at the inflated output to see what was
+wrong? I could have looked forever and never found it. Here's the diff
+between what the corrupted data inflates to, versus the real data:
+
+--------------
+ - cp = strtok (arg, "+");
+ + cp = strtok (arg, ".");
+--------------
+
+It tweaked one byte and still ended up as valid, readable C that just
+happened to do something totally different! One takeaway is that on a
+less unlucky day, looking at the zlib output might have actually been
+helpful, as most random changes would actually break the C code.
+
+But more importantly, git's hashing and checksumming noticed a problem
+that easily could have gone undetected in another system. The result
+still compiled, but would have caused an interesting bug (that would
+have been blamed on some random commit).
+
+
+The adventure continues...
+--------------------------
+
+I ended up doing this again! Same entity, new hardware. The assumption
+at this point is that the old disk corrupted the packfile, and then the
+corruption was migrated to the new hardware (because it was done by
+rsync or similar, and no fsck was done at the time of migration).
+
+This time, the affected blob was over 20 megabytes, which was far too
+large to do a brute-force on. I followed the instructions above to
+create the `zlib` file. I then used the `inflate` program below to pull
+the corrupted data from that. Examining that output gave me a hint about
+where in the file the corruption was. But now I was working with the
+file itself, not the zlib contents. So knowing the sha1 of the object
+and the approximate area of the corruption, I used the `sha1-munge`
+program below to brute-force the correct byte.
+
+Here's the inflate program (it's essentially `gunzip` but without the
+`.gz` header processing):
+
+--------------------------
+#include <stdio.h>
+#include <string.h>
+#include <zlib.h>
+#include <stdlib.h>
+
+int main(int argc, char **argv)
+{
+ /*
+ * oversized so we can read the whole buffer in;
+ * this could actually be switched to streaming
+ * to avoid any memory limitations
+ */
+ static unsigned char buf[25 * 1024 * 1024];
+ static unsigned char out[25 * 1024 * 1024];
+ int len;
+ z_stream z;
+ int ret;
+
+ len = read(0, buf, sizeof(buf));
+ memset(&z, 0, sizeof(z));
+ inflateInit(&z);
+
+ z.next_in = buf;
+ z.avail_in = len;
+ z.next_out = out;
+ z.avail_out = sizeof(out);
+
+ ret = inflate(&z, 0);
+ if (ret != Z_OK && ret != Z_STREAM_END)
+ fprintf(stderr, "initial inflate failed (%d)\n", ret);
+
+ fprintf(stderr, "outputting %lu bytes", z.total_out);
+ fwrite(out, 1, z.total_out, stdout);
+ return 0;
+}
+--------------------------
+
+And here is the `sha1-munge` program:
+
+--------------------------
+#include <stdio.h>
+#include <unistd.h>
+#include <string.h>
+#include <signal.h>
+#include <openssl/sha.h>
+#include <stdlib.h>
+
+/* eye candy */
+static int counter = 0;
+static void progress(int sig)
+{
+ fprintf(stderr, "\r%d", counter);
+ alarm(1);
+}
+
+static const signed char hexval_table[256] = {
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 00-07 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 08-0f */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 10-17 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 18-1f */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 20-27 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 28-2f */
+ 0, 1, 2, 3, 4, 5, 6, 7, /* 30-37 */
+ 8, 9, -1, -1, -1, -1, -1, -1, /* 38-3f */
+ -1, 10, 11, 12, 13, 14, 15, -1, /* 40-47 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 48-4f */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 50-57 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 58-5f */
+ -1, 10, 11, 12, 13, 14, 15, -1, /* 60-67 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 68-67 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 70-77 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 78-7f */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 80-87 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 88-8f */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 90-97 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 98-9f */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* a0-a7 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* a8-af */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* b0-b7 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* b8-bf */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* c0-c7 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* c8-cf */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* d0-d7 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* d8-df */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* e0-e7 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* e8-ef */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* f0-f7 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* f8-ff */
+};
+
+static inline unsigned int hexval(unsigned char c)
+{
+return hexval_table[c];
+}
+
+static int get_sha1_hex(const char *hex, unsigned char *sha1)
+{
+ int i;
+ for (i = 0; i < 20; i++) {
+ unsigned int val;
+ /*
+ * hex[1]=='\0' is caught when val is checked below,
+ * but if hex[0] is NUL we have to avoid reading
+ * past the end of the string:
+ */
+ if (!hex[0])
+ return -1;
+ val = (hexval(hex[0]) << 4) | hexval(hex[1]);
+ if (val & ~0xff)
+ return -1;
+ *sha1++ = val;
+ hex += 2;
+ }
+ return 0;
+}
+
+int main(int argc, char **argv)
+{
+ /* oversized so we can read the whole buffer in */
+ static unsigned char buf[25 * 1024 * 1024];
+ char header[32];
+ int header_len;
+ unsigned char have[20], want[20];
+ int start, len;
+ SHA_CTX orig;
+ unsigned i, j;
+
+ if (!argv[1] || get_sha1_hex(argv[1], want)) {
+ fprintf(stderr, "usage: sha1-munge <sha1> [start] <file.in\n");
+ return 1;
+ }
+
+ if (argv[2])
+ start = atoi(argv[2]);
+ else
+ start = 0;
+
+ len = read(0, buf, sizeof(buf));
+ header_len = sprintf(header, "blob %d", len) + 1;
+ fprintf(stderr, "using header: %s\n", header);
+
+ /*
+ * We keep a running sha1 so that if you are munging
+ * near the end of the file, we do not have to re-sha1
+ * the unchanged earlier bytes
+ */
+ SHA1_Init(&orig);
+ SHA1_Update(&orig, header, header_len);
+ if (start)
+ SHA1_Update(&orig, buf, start);
+
+ signal(SIGALRM, progress);
+ alarm(1);
+
+ for (i = start; i < len; i++) {
+ unsigned char c;
+ SHA_CTX x;
+
+#if 0
+ /*
+ * deletion -- this would not actually work in practice,
+ * I think, because we've already committed to a
+ * particular size in the header. Ditto for addition
+ * below. In those cases, you'd have to do the whole
+ * sha1 from scratch, or possibly keep three running
+ * "orig" sha1 computations going.
+ */
+ memcpy(&x, &orig, sizeof(x));
+ SHA1_Update(&x, buf + i + 1, len - i - 1);
+ SHA1_Final(have, &x);
+ if (!memcmp(have, want, 20))
+ printf("i=%d, deletion\n", i);
+#endif
+
+ /*
+ * replacement -- note that this tries each of the 256
+ * possible bytes. If you suspect a single-bit flip,
+ * it would be much shorter to just try the 8
+ * bit-flipped variants.
+ */
+ c = buf[i];
+ for (j = 0; j <= 0xff; j++) {
+ buf[i] = j;
+
+ memcpy(&x, &orig, sizeof(x));
+ SHA1_Update(&x, buf + i, len - i);
+ SHA1_Final(have, &x);
+ if (!memcmp(have, want, 20))
+ printf("i=%d, j=%02x\n", i, j);
+ }
+ buf[i] = c;
+
+#if 0
+ /* addition */
+ for (j = 0; j <= 0xff; j++) {
+ unsigned char extra = j;
+ memcpy(&x, &orig, sizeof(x));
+ SHA1_Update(&x, &extra, 1);
+ SHA1_Update(&x, buf + i, len - i);
+ SHA1_Final(have, &x);
+ if (!memcmp(have, want, 20))
+ printf("i=%d, addition=%02x", i, j);
+ }
+#endif
+
+ SHA1_Update(&orig, buf + i, 1);
+ counter++;
+ }
+
+ alarm(0);
+ fprintf(stderr, "\r%d\n", counter);
+ return 0;
+}
+--------------------------
diff --git a/howto/revert-a-faulty-merge.adoc b/howto/revert-a-faulty-merge.adoc
new file mode 100644
index 0000000..19f59cc
--- /dev/null
+++ b/howto/revert-a-faulty-merge.adoc
@@ -0,0 +1,273 @@
+Date: Fri, 19 Dec 2008 00:45:19 -0800
+From: Linus Torvalds <torvalds@linux-foundation.org>, Junio C Hamano <gitster@pobox.com>
+Subject: Re: Odd merge behaviour involving reverts
+Abstract: Sometimes a branch that was already merged to the mainline
+ is later found to be faulty. Linus and Junio give guidance on
+ recovering from such a premature merge and continuing development
+ 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:
+
+ I have a master branch. We have a branch off of that that some
+ developers are doing work on. They claim it is ready. We merge it
+ into the master branch. It breaks something so we revert the merge.
+ They make changes to the code. they get it to a point where they say
+ it is ok and we merge again.
+
+ When examined, we find that code changes made before the revert are
+ not in the master branch, but code changes after are in the master
+ branch.
+
+and asked for help recovering from this situation.
+
+The history immediately after the "revert of the merge" would look like
+this:
+
+ ---o---o---o---M---x---x---W
+ /
+ ---A---B
+
+where A and B are on the side development that was not so good, M is the
+merge that brings these premature changes into the mainline, x are changes
+unrelated to what the side branch did and already made on the mainline,
+and W is the "revert of the merge M" (doesn't W look M upside down?).
+IOW, `"diff W^..W"` is similar to `"diff -R M^..M"`.
+
+Such a "revert" of a merge can be made with:
+
+ $ git revert -m 1 M
+
+After the developers of the side branch fix their mistakes, the history
+may look like this:
+
+ ---o---o---o---M---x---x---W---x
+ /
+ ---A---B-------------------C---D
+
+where C and D are to fix what was broken in A and B, and you may already
+have some other changes on the mainline after W.
+
+If you merge the updated side branch (with D at its tip), none of the
+changes made in A or B will be in the result, because they were reverted
+by W. That is what Alan saw.
+
+Linus explains the situation:
+
+ Reverting a regular commit just effectively undoes what that commit
+ did, and is fairly straightforward. But reverting a merge commit also
+ undoes the _data_ that the commit changed, but it does absolutely
+ nothing to the effects on _history_ that the merge had.
+
+ So the merge will still exist, and it will still be seen as joining
+ the two branches together, and future merges will see that merge as
+ the last shared state - and the revert that reverted the merge brought
+ in will not affect that at all.
+
+ So a "revert" undoes the data changes, but it's very much _not_ an
+ "undo" in the sense that it doesn't undo the effects of a commit on
+ the repository history.
+
+ So if you think of "revert" as "undo", then you're going to always
+ miss this part of reverts. Yes, it undoes the data, but no, it doesn't
+ undo history.
+
+In such a situation, you would want to first revert the previous revert,
+which would make the history look like this:
+
+ ---o---o---o---M---x---x---W---x---Y
+ /
+ ---A---B-------------------C---D
+
+where Y is the revert of W. Such a "revert of the revert" can be done
+with:
+
+ $ git revert W
+
+This history would (ignoring possible conflicts between what W and W..Y
+changed) be equivalent to not having W or Y at all in the history:
+
+ ---o---o---o---M---x---x-------x----
+ /
+ ---A---B-------------------C---D
+
+and merging the side branch again will not have conflict arising from an
+earlier revert and revert of the revert.
+
+ ---o---o---o---M---x---x-------x-------*
+ / /
+ ---A---B-------------------C---D
+
+Of course the changes made in C and D still can conflict with what was
+done by any of the x, but that is just a normal merge conflict.
+
+On the other hand, if the developers of the side branch discarded their
+faulty A and B, and redone the changes on top of the updated mainline
+after the revert, the history would have looked like this:
+
+ ---o---o---o---M---x---x---W---x---x
+ / \
+ ---A---B A'--B'--C'
+
+If you reverted the revert in such a case as in the previous example:
+
+ ---o---o---o---M---x---x---W---x---x---Y---*
+ / \ /
+ ---A---B A'--B'--C'
+
+where Y is the revert of W, A' and B' are rerolled A and B, and there may
+also be a further fix-up C' on the side branch. `"diff Y^..Y"` is similar
+to `"diff -R W^..W"` (which in turn means it is similar to `"diff M^..M"`),
+and `"diff A'^..C'"` by definition would be similar but different from that,
+because it is a rerolled series of the earlier change. There will be a
+lot of overlapping changes that result in conflicts. So do not do "revert
+of revert" blindly without thinking..
+
+ ---o---o---o---M---x---x---W---x---x
+ / \
+ ---A---B A'--B'--C'
+
+In the history with rebased side branch, W (and M) are behind the merge
+base of the updated branch and the tip of the mainline, and they should
+merge without the past faulty merge and its revert getting in the way.
+
+To recap, these are two very different scenarios, and they want two very
+different resolution strategies:
+
+ - If the faulty side branch was fixed by adding corrections on top, then
+ doing a revert of the previous revert would be the right thing to do.
+
+ - If the faulty side branch whose effects were discarded by an earlier
+ revert of a merge was rebuilt from scratch (i.e. rebasing and fixing,
+ as you seem to have interpreted), then re-merging the result without
+ doing anything else fancy would be the right thing to do.
+ (See the ADDENDUM below for how to rebuild a branch from scratch
+ without changing its original branching-off point.)
+
+However, there are things to keep in mind when reverting a merge (and
+reverting such a revert).
+
+For example, think about what reverting a merge (and then reverting the
+revert) does to bisectability. Ignore the fact that the revert of a revert
+is undoing it - just think of it as a "single commit that does a lot".
+Because that is what it does.
+
+When you have a problem you are chasing down, and you hit a "revert this
+merge", what you're hitting is essentially a single commit that contains
+all the changes (but obviously in reverse) of all the commits that got
+merged. So it's debugging hell, because now you don't have lots of small
+changes that you can try to pinpoint which _part_ of it changes.
+
+But does it all work? Sure it does. You can revert a merge, and from a
+purely technical angle, Git did it very naturally and had no real
+troubles. It just considered it a change from "state before merge" to
+"state after merge", and that was it. Nothing complicated, nothing odd,
+nothing really dangerous. Git will do it without even thinking about it.
+
+So from a technical angle, there's nothing wrong with reverting a merge,
+but from a workflow angle it's something that you generally should try to
+avoid.
+
+If at all possible, for example, if you find a problem that got merged
+into the main tree, rather than revert the merge, try _really_ hard to
+bisect the problem down into the branch you merged, and just fix it, or
+try to revert the individual commit that caused it.
+
+Yes, it's more complex, and no, it's not always going to work (sometimes
+the answer is: "oops, I really shouldn't have merged it, because it wasn't
+ready yet, and I really need to undo _all_ of the merge"). So then you
+really should revert the merge, but when you want to re-do the merge, you
+now need to do it by reverting the revert.
+
+ADDENDUM
+
+Sometimes you have to rewrite one of a topic branch's commits *and* you can't
+change the topic's branching-off point. Consider the following situation:
+
+ P---o---o---M---x---x---W---x
+ \ /
+ A---B---C
+
+where commit W reverted commit M because it turned out that commit B was wrong
+and needs to be rewritten, but you need the rewritten topic to still branch
+from commit P (perhaps P is a branching-off point for yet another branch, and
+you want be able to merge the topic into both branches).
+
+The natural thing to do in this case is to checkout the A-B-C branch and use
+"rebase -i P" to change commit B. However this does not rewrite commit A,
+because "rebase -i" by default fast-forwards over any initial commits selected
+with the "pick" command. So you end up with this:
+
+ P---o---o---M---x---x---W---x
+ \ /
+ A---B---C <-- old branch
+ \
+ B'---C' <-- naively rewritten branch
+
+To merge A-B'-C' into the mainline branch you would still have to first revert
+commit W in order to pick up the changes in A, but then it's likely that the
+changes in B' will conflict with the original B changes re-introduced by the
+reversion of W.
+
+However, you can avoid these problems if you recreate the entire branch,
+including commit A:
+
+ A'---B'---C' <-- completely rewritten branch
+ /
+ P---o---o---M---x---x---W---x
+ \ /
+ A---B---C
+
+You can merge A'-B'-C' into the mainline branch without worrying about first
+reverting W. Mainline's history would look like this:
+
+ A'---B'---C'------------------
+ / \
+ P---o---o---M---x---x---W---x---M2
+ \ /
+ A---B---C
+
+But if you don't actually need to change commit A, then you need some way to
+recreate it as a new commit with the same changes in it. The rebase command's
+--no-ff option provides a way to do this:
+
+ $ git rebase [-i] --no-ff P
+
+The --no-ff option creates a new branch A'-B'-C' with all-new commits (all the
+SHA IDs will be different) even if in the interactive case you only actually
+modify commit B. You can then merge this new branch directly into the mainline
+branch and be sure you'll get all of the branch's changes.
+
+You can also use --no-ff in cases where you just add extra commits to the topic
+to fix it up. Let's revisit the situation discussed at the start of this howto:
+
+ P---o---o---M---x---x---W---x
+ \ /
+ A---B---C----------------D---E <-- fixed-up topic branch
+
+At this point, you can use --no-ff to recreate the topic branch:
+
+ $ git checkout E
+ $ git rebase --no-ff P
+
+yielding
+
+ A'---B'---C'------------D'---E' <-- recreated topic branch
+ /
+ P---o---o---M---x---x---W---x
+ \ /
+ A---B---C----------------D---E
+
+You can merge the recreated branch into the mainline without reverting commit W,
+and mainline's history will look like this:
+
+ A'---B'---C'------------D'---E'
+ / \
+ P---o---o---M---x---x---W---x---M2
+ \ /
+ A---B---C
diff --git a/howto/revert-branch-rebase.adoc b/howto/revert-branch-rebase.adoc
new file mode 100644
index 0000000..a3e5595
--- /dev/null
+++ b/howto/revert-branch-rebase.adoc
@@ -0,0 +1,187 @@
+From: Junio C Hamano <gitster@pobox.com>
+To: git@vger.kernel.org
+Subject: [HOWTO] Reverting an existing commit
+Abstract: In this article, JC gives a small real-life example of using
+ 'git revert' command, and using a temporary branch and tag for safety
+ and easier sanity checking.
+Date: Mon, 29 Aug 2005 21:39:02 -0700
+Content-type: text/asciidoc
+Message-ID: <7voe7g3uop.fsf@assigned-by-dhcp.cox.net>
+
+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
+portability fixes, keeping things working with gcc-2.95 was also
+important. Here is what I did to revert the change in the 'master'
+branch and to adjust the 'seen' branch, using core Git tools and
+barebone Porcelain.
+
+First, prepare a throw-away branch in case I screw things up.
+
+------------------------------------------------
+$ git checkout -b revert-c99 master
+------------------------------------------------
+
+Now I am on the 'revert-c99' branch. Let's figure out which commit to
+revert. I happen to know that the top of the 'master' branch is a
+merge, and its second parent (i.e. foreign commit I merged from) has
+the change I would want to undo. Further I happen to know that that
+merge introduced 5 commits or so:
+
+------------------------------------------------
+$ git show-branch --more=4 master master^2 | head
+* [master] Merge refs/heads/portable from http://www.cs.berkeley....
+ ! [master^2] Replace C99 array initializers with code.
+--
+- [master] Merge refs/heads/portable from http://www.cs.berkeley....
+*+ [master^2] Replace C99 array initializers with code.
+*+ [master^2~1] Replace unsetenv() and setenv() with older putenv().
+*+ [master^2~2] Include sys/time.h in daemon.c.
+*+ [master^2~3] Fix ?: statements.
+*+ [master^2~4] Replace zero-length array decls with [].
+* [master~1] tutorial note about git branch
+------------------------------------------------
+
+The '--more=4' above means "after we reach the merge base of refs,
+show until we display four more common commits". That last commit
+would have been where the "portable" branch was forked from the main
+git.git repository, so this would show everything on both branches
+since then. I just limited the output to the first handful using
+'head'.
+
+Now I know 'master^2~4' (pronounce it as "find the second parent of
+the 'master', and then go four generations back following the first
+parent") is the one I would want to revert. Since I also want to say
+why I am reverting it, the '-n' flag is given to 'git revert'. This
+prevents it from actually making a commit, and instead 'git revert'
+leaves the commit log message it wanted to use in '.msg' file:
+
+------------------------------------------------
+$ git revert -n master^2~4
+$ cat .msg
+Revert "Replace zero-length array decls with []."
+
+This reverts 6c5f9baa3bc0d63e141e0afc23110205379905a4 commit.
+$ git diff HEAD ;# to make sure what we are reverting makes sense.
+$ make CC=gcc-2.95 clean test ;# make sure it fixed the breakage.
+$ make clean test ;# make sure it did not cause other breakage.
+------------------------------------------------
+
+The reverted change makes sense (from reading the 'diff' output), does
+fix the problem (from 'make CC=gcc-2.95' test), and does not cause new
+breakage (from the last 'make test'). I'm ready to commit:
+
+------------------------------------------------
+$ git commit -a -s ;# read .msg into the log,
+ # and explain why I am reverting.
+------------------------------------------------
+
+I could have screwed up in any of the above steps, but in the worst
+case I could just have done 'git checkout master' to start over.
+Fortunately I did not have to; what I have in the current branch
+'revert-c99' is what I want. So merge that back into 'master':
+
+------------------------------------------------
+$ git checkout master
+$ git merge revert-c99 ;# this should be a fast-forward
+Updating from 10d781b9caa4f71495c7b34963bef137216f86a8 to e3a693c...
+ cache.h | 8 ++++----
+ commit.c | 2 +-
+ ls-files.c | 2 +-
+ receive-pack.c | 2 +-
+ server-info.c | 2 +-
+ 5 files changed, 8 insertions(+), 8 deletions(-)
+------------------------------------------------
+
+There is no need to redo the test at this point. We fast-forwarded
+and we know 'master' matches 'revert-c99' exactly. In fact:
+
+------------------------------------------------
+$ git diff master..revert-c99
+------------------------------------------------
+
+says nothing.
+
+Then we rebase the 'seen' branch as usual.
+
+------------------------------------------------
+$ git checkout seen
+$ git tag seen-anchor seen
+$ git rebase master
+* Applying: Redo "revert" using three-way merge machinery.
+First trying simple merge strategy to cherry-pick.
+* Applying: Remove git-apply-patch-script.
+First trying simple merge strategy to cherry-pick.
+Simple cherry-pick fails; trying Automatic cherry-pick.
+Removing Documentation/git-apply-patch-script.txt
+Removing git-apply-patch-script
+* Applying: Document "git cherry-pick" and "git revert"
+First trying simple merge strategy to cherry-pick.
+* Applying: mailinfo and applymbox updates
+First trying simple merge strategy to cherry-pick.
+* Applying: Show commits in topo order and name all commits.
+First trying simple merge strategy to cherry-pick.
+* Applying: More documentation updates.
+First trying simple merge strategy to cherry-pick.
+------------------------------------------------
+
+The temporary tag 'seen-anchor' is me just being careful, in case 'git
+rebase' screws up. After this, I can do these for sanity check:
+
+------------------------------------------------
+$ git diff seen-anchor..seen ;# make sure we got the master fix.
+$ make CC=gcc-2.95 clean test ;# make sure it fixed the breakage.
+$ make clean test ;# make sure it did not cause other breakage.
+------------------------------------------------
+
+Everything is in the good order. I do not need the temporary branch
+or tag anymore, so remove them:
+
+------------------------------------------------
+$ rm -f .git/refs/tags/seen-anchor
+$ git branch -d revert-c99
+------------------------------------------------
+
+It was an emergency fix, so we might as well merge it into the
+'release candidate' branch, although I expect the next release would
+be some days off:
+
+------------------------------------------------
+$ git checkout rc
+$ git pull . master
+Packing 0 objects
+Unpacking 0 objects
+
+* commit-ish: e3a693c... refs/heads/master from .
+Trying to merge e3a693c... into 8c1f5f0... using 10d781b...
+Committed merge 7fb9b7262a1d1e0a47bbfdcbbcf50ce0635d3f8f
+ cache.h | 8 ++++----
+ commit.c | 2 +-
+ ls-files.c | 2 +-
+ receive-pack.c | 2 +-
+ server-info.c | 2 +-
+ 5 files changed, 8 insertions(+), 8 deletions(-)
+------------------------------------------------
+
+And the final repository status looks like this:
+
+------------------------------------------------
+$ git show-branch --more=1 master seen rc
+! [master] Revert "Replace zero-length array decls with []."
+ ! [seen] git-repack: Add option to repack all objects.
+ * [rc] Merge refs/heads/master from .
+---
+ + [seen] git-repack: Add option to repack all objects.
+ + [seen~1] More documentation updates.
+ + [seen~2] Show commits in topo order and name all commits.
+ + [seen~3] mailinfo and applymbox updates
+ + [seen~4] Document "git cherry-pick" and "git revert"
+ + [seen~5] Remove git-apply-patch-script.
+ + [seen~6] Redo "revert" using three-way merge machinery.
+ - [rc] Merge refs/heads/master from .
+++* [master] Revert "Replace zero-length array decls with []."
+ - [rc~1] Merge refs/heads/master from .
+... [master~1] Merge refs/heads/portable from http://www.cs.berkeley....
+------------------------------------------------
diff --git a/howto/separating-topic-branches.adoc b/howto/separating-topic-branches.adoc
new file mode 100644
index 0000000..81be0d6
--- /dev/null
+++ b/howto/separating-topic-branches.adoc
@@ -0,0 +1,94 @@
+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.
+
+Often I find myself doing that [running diff against something other
+than HEAD] while rewriting messy development history. For example, I
+start doing some work without knowing exactly where it leads, and end
+up with a history like this:
+
+ "master"
+ o---o
+ \ "topic"
+ o---o---o---o---o---o
+
+At this point, "topic" contains something I know I want, but it
+contains two concepts that turned out to be completely independent.
+And often, one topic component is larger than the other. It may
+contain more than two topics.
+
+In order to rewrite this mess to be more manageable, I would first do
+"diff master..topic", to extract the changes into a single patch, start
+picking pieces from it to get logically self-contained units, and
+start building on top of "master":
+
+ $ git diff master..topic >P.diff
+ $ git checkout -b topicA master
+ ... pick and apply pieces from P.diff to build
+ ... commits on topicA branch.
+
+ o---o---o
+ / "topicA"
+ o---o"master"
+ \ "topic"
+ o---o---o---o---o---o
+
+Before doing each commit on "topicA" HEAD, I run "diff HEAD"
+before update-index the affected paths, or "diff --cached HEAD"
+after. Also I would run "diff --cached master" to make sure
+that the changes are only the ones related to "topicA". Usually
+I do this for smaller topics first.
+
+After that, I'd do the remainder of the original "topic", but
+for that, I do not start from the patchfile I extracted by
+comparing "master" and "topic" I used initially. Still on
+"topicA", I extract "diff topic", and use it to rebuild the
+other topic:
+
+ $ git diff -R topic >P.diff ;# --cached also would work fine
+ $ git checkout -b topicB master
+ ... pick and apply pieces from P.diff to build
+ ... commits on topicB branch.
+
+ "topicB"
+ o---o---o---o---o
+ /
+ /o---o---o
+ |/ "topicA"
+ o---o"master"
+ \ "topic"
+ o---o---o---o---o---o
+
+After I am done, I'd try a pretend-merge between "topicA" and
+"topicB" in order to make sure I have not missed anything:
+
+ $ git pull . topicA ;# merge it into current "topicB"
+ $ git diff topic
+ "topicB"
+ o---o---o---o---o---* (pretend merge)
+ / /
+ /o---o---o----------'
+ |/ "topicA"
+ o---o"master"
+ \ "topic"
+ o---o---o---o---o---o
+
+The last diff better not to show anything other than cleanups
+for cruft. Then I can finally clean things up:
+
+ $ git branch -D topic
+ $ git reset --hard HEAD^ ;# nuke pretend merge
+
+ "topicB"
+ o---o---o---o---o
+ /
+ /o---o---o
+ |/ "topicA"
+ o---o"master"
diff --git a/howto/setup-git-server-over-http.adoc b/howto/setup-git-server-over-http.adoc
new file mode 100644
index 0000000..bfe6f9b
--- /dev/null
+++ b/howto/setup-git-server-over-http.adoc
@@ -0,0 +1,285 @@
+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
+=================================
+
+NOTE: This document is from 2006. A lot has happened since then, and this
+document is now relevant mainly if your web host is not CGI capable.
+Almost everyone else should instead look at linkgit:git-http-backend[1].
+
+Since Apache is one of those packages people like to compile
+themselves while others prefer the bureaucrat's dream Debian, it is
+impossible to give guidelines which will work for everyone. Just send
+some feedback to the mailing list at git@vger.kernel.org to get this
+document tailored to your favorite distro.
+
+
+What's needed:
+
+- Have an Apache web-server
+
+ On Debian:
+ $ apt-get install apache2
+ To get apache2 by default started,
+ edit /etc/default/apache2 and set NO_START=0
+
+- can edit the configuration of it.
+
+ This could be found under /etc/httpd, or refer to your Apache documentation.
+
+ On Debian: this means being able to edit files under /etc/apache2
+
+- can restart it.
+
+ 'apachectl --graceful' might do. If it doesn't, just stop and
+ restart apache. Be warning that active connections to your server
+ might be aborted by this.
+
+ On Debian:
+ $ /etc/init.d/apache2 restart
+ or
+ $ /etc/init.d/apache2 force-reload
+ (which seems to do the same)
+ This adds symlinks from the /etc/apache2/mods-enabled to
+ /etc/apache2/mods-available.
+
+- have permissions to chown a directory
+
+- have Git installed on the client, and
+
+- either have Git installed on the server or have a webdav client on
+ the client.
+
+In effect, this means you're going to be root, or that you're using a
+preconfigured WebDAV server.
+
+
+Step 1: setup a bare Git repository
+-----------------------------------
+
+At the time of writing, git-http-push cannot remotely create a Git
+repository. So we have to do that at the server side with Git. Another
+option is to generate an empty bare repository at the client and copy
+it to the server with a WebDAV client (which is the only option if Git
+is not installed on the server).
+
+Create the directory under the DocumentRoot of the directories served
+by Apache. As an example we take /usr/local/apache2, but try "grep
+DocumentRoot /where/ever/httpd.conf" to find your root:
+
+ $ cd /usr/local/apache/htdocs
+ $ mkdir my-new-repo.git
+
+ On Debian:
+
+ $ cd /var/www
+ $ mkdir my-new-repo.git
+
+
+Initialize a bare repository
+
+ $ cd my-new-repo.git
+ $ git --bare init
+
+
+Change the ownership to your web-server's credentials. Use `"grep ^User
+httpd.conf"` and `"grep ^Group httpd.conf"` to find out:
+
+ $ chown -R www.www .
+
+ On Debian:
+
+ $ chown -R www-data.www-data .
+
+
+If you do not know which user Apache runs as, you can alternatively do
+a "chmod -R a+w .", inspect the files which are created later on, and
+set the permissions appropriately.
+
+Restart apache2, and check whether http://server/my-new-repo.git gives
+a directory listing. If not, check whether apache started up
+successfully.
+
+
+Step 2: enable DAV on this repository
+-------------------------------------
+
+First make sure the dav_module is loaded. For this, insert in httpd.conf:
+
+ LoadModule dav_module libexec/httpd/libdav.so
+ AddModule mod_dav.c
+
+Also make sure that this line exists which is the file used for
+locking DAV operations:
+
+ DAVLockDB "/usr/local/apache2/temp/DAV.lock"
+
+ On Debian these steps can be performed with:
+
+ Enable the dav and dav_fs modules of apache:
+ $ a2enmod dav_fs
+ (just to be sure. dav_fs might be unneeded, I don't know)
+ $ a2enmod dav
+ The DAV lock is located in /etc/apache2/mods-available/dav_fs.conf:
+ DAVLockDB /var/lock/apache2/DAVLock
+
+Of course, it can point somewhere else, but the string is actually just a
+prefix in some Apache configurations, and therefore the _directory_ has to
+be writable by the user Apache runs as.
+
+Then, add something like this to your httpd.conf
+
+ <Location /my-new-repo.git>
+ DAV on
+ AuthType Basic
+ AuthName "Git"
+ AuthUserFile /usr/local/apache2/conf/passwd.git
+ Require valid-user
+ </Location>
+
+ On Debian:
+ Create (or add to) /etc/apache2/conf.d/git.conf :
+
+ <Location /my-new-repo.git>
+ DAV on
+ AuthType Basic
+ AuthName "Git"
+ AuthUserFile /etc/apache2/passwd.git
+ Require valid-user
+ </Location>
+
+ Debian automatically reads all files under /etc/apache2/conf.d.
+
+The password file can be somewhere else, but it has to be readable by
+Apache and preferably not readable by the world.
+
+Create this file by
+ $ htpasswd -c /usr/local/apache2/conf/passwd.git <user>
+
+ On Debian:
+ $ htpasswd -c /etc/apache2/passwd.git <user>
+
+You will be asked a password, and the file is created. Subsequent calls
+to htpasswd should omit the '-c' option, since you want to append to the
+existing file.
+
+You need to restart Apache.
+
+Now go to http://<username>@<servername>/my-new-repo.git in your
+browser to check whether it asks for a password and accepts the right
+password.
+
+On Debian:
+
+ To test the WebDAV part, do:
+
+ $ apt-get install litmus
+ $ litmus http://<servername>/my-new-repo.git <username> <password>
+
+ Most tests should pass.
+
+A command-line tool to test WebDAV is cadaver. If you prefer GUIs, for
+example, konqueror can open WebDAV URLs as "webdav://..." or
+"webdavs://...".
+
+If you're into Windows, from XP onwards Internet Explorer supports
+WebDAV. For this, do Internet Explorer -> Open Location ->
+http://<servername>/my-new-repo.git [x] Open as webfolder -> login .
+
+
+Step 3: setup the client
+------------------------
+
+Make sure that you have HTTP support, i.e. your Git was built with
+libcurl (version more recent than 7.10). The command 'git http-push' with
+no argument should display a usage message.
+
+Then, add the following to your $HOME/.netrc (you can do without, but will be
+asked to input your password a _lot_ of times):
+
+ machine <servername>
+ login <username>
+ password <password>
+
+...and set permissions:
+ chmod 600 ~/.netrc
+
+If you want to access the web-server by its IP, you have to type that in,
+instead of the server name.
+
+To check whether all is OK, do:
+
+ curl --netrc --location -v http://<username>@<servername>/my-new-repo.git/HEAD
+
+...this should give something like 'ref: refs/heads/master', which is
+the content of the file HEAD on the server.
+
+Now, add the remote in your existing repository which contains the project
+you want to export:
+
+ $ git-config remote.upload.url \
+ http://<username>@<servername>/my-new-repo.git/
+
+It is important to put the last '/'; Without it, the server will send
+a redirect which git-http-push does not (yet) understand, and git-http-push
+will repeat the request infinitely.
+
+
+Step 4: make the initial push
+-----------------------------
+
+From your client repository, do
+
+ $ git push upload master
+
+This pushes branch 'master' (which is assumed to be the branch you
+want to export) to repository called 'upload', which we previously
+defined with git-config.
+
+
+Using a proxy:
+--------------
+
+If you have to access the WebDAV server from behind an HTTP(S) proxy,
+set the variable 'all_proxy' to `http://proxy-host.com:port`, or
+`http://login-on-proxy:passwd-on-proxy@proxy-host.com:port`. See 'man
+curl' for details.
+
+
+Troubleshooting:
+----------------
+
+If git-http-push says
+
+ Error: no DAV locking support on remote repo http://...
+
+then it means the web-server did not accept your authentication. Make sure
+that the user name and password matches in httpd.conf, .netrc and the URL
+you are uploading to.
+
+If git-http-push shows you an error (22/502) when trying to MOVE a blob,
+it means that your web-server somehow does not recognize its name in the
+request; This can happen when you start Apache, but then disable the
+network interface. A simple restart of Apache helps.
+
+Errors like (22/502) are of format (curl error code/http error
+code). So (22/404) means something like 'not found' at the server.
+
+Reading /usr/local/apache2/logs/error_log is often helpful.
+
+ On Debian: Read /var/log/apache2/error.log instead.
+
+If you access HTTPS locations, Git may fail verifying the SSL
+certificate (this is return code 60). Setting http.sslVerify=false can
+help diagnosing the problem, but removes security checks.
+
+
+Debian References: http://www.debian-administration.org/articles/285
+
+Authors
+ Johannes Schindelin <Johannes.Schindelin@gmx.de>
+ Rutger Nijlunsing <git@wingding.demon.nl>
+ Matthieu Moy <Matthieu.Moy@imag.fr>
diff --git a/howto/update-hook-example.adoc b/howto/update-hook-example.adoc
new file mode 100644
index 0000000..4e727de
--- /dev/null
+++ b/howto/update-hook-example.adoc
@@ -0,0 +1,192 @@
+From: Junio C Hamano <gitster@pobox.com> and Carl Baldwin <cnb@fc.hp.com>
+Subject: control access to branches.
+Date: Thu, 17 Nov 2005 23:55:32 -0800
+Message-ID: <7vfypumlu3.fsf@assigned-by-dhcp.cox.net>
+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
+developer, so is hooks/update script. Quoting from the relevant
+section of the documentation:
+
+ Before each ref is updated, if $GIT_DIR/hooks/update file exists
+ and executable, it is called with three parameters:
+
+ $GIT_DIR/hooks/update refname sha1-old sha1-new
+
+ The refname parameter is relative to $GIT_DIR; e.g. for the
+ master head this is "refs/heads/master". Two sha1 are the
+ object names for the refname before and after the update. Note
+ that the hook is called before the refname is updated, so either
+ sha1-old is 0{40} (meaning there is no such ref yet), or it
+ should match what is recorded in refname.
+
+So if your policy is (1) always require fast-forward push
+(i.e. never allow "git-push repo +branch:branch"), (2) you
+have a list of users allowed to update each branch, and (3) you
+do not let tags to be overwritten, then you can use something
+like this as your hooks/update script.
+
+[jc: editorial note. This is a much improved version by Carl
+since I posted the original outline]
+
+----------------------------------------------------
+#!/bin/bash
+
+umask 002
+
+# If you are having trouble with this access control hook script
+# you can try setting this to true. It will tell you exactly
+# why a user is being allowed/denied access.
+
+verbose=false
+
+# Default shell globbing messes things up downstream
+GLOBIGNORE=*
+
+function grant {
+ $verbose && echo >&2 "-Grant- $1"
+ echo grant
+ exit 0
+}
+
+function deny {
+ $verbose && echo >&2 "-Deny- $1"
+ echo deny
+ exit 1
+}
+
+function info {
+ $verbose && echo >&2 "-Info- $1"
+}
+
+# Implement generic branch and tag policies.
+# - Tags should not be updated once created.
+# - Branches should only be fast-forwarded unless their pattern starts with '+'
+case "$1" in
+ refs/tags/*)
+ git rev-parse --verify -q "$1" &&
+ deny >/dev/null "You can't overwrite an existing tag"
+ ;;
+ refs/heads/*)
+ # No rebasing or rewinding
+ if expr "$2" : '0*$' >/dev/null; then
+ info "The branch '$1' is new..."
+ else
+ # updating -- make sure it is a fast-forward
+ mb=$(git merge-base "$2" "$3")
+ case "$mb,$2" in
+ "$2,$mb") info "Update is fast-forward" ;;
+ *) noff=y; info "This is not a fast-forward update.";;
+ esac
+ fi
+ ;;
+ *)
+ deny >/dev/null \
+ "Branch is not under refs/heads or refs/tags. What are you trying to do?"
+ ;;
+esac
+
+# Implement per-branch controls based on username
+allowed_users_file=$GIT_DIR/info/allowed-users
+username=$(id -u -n)
+info "The user is: '$username'"
+
+if test -f "$allowed_users_file"
+then
+ rc=$(grep -Ev '^(#|$)' $allowed_users_file |
+ while read heads user_patterns
+ do
+ # does this rule apply to us?
+ head_pattern=${heads#+}
+ matchlen=$(expr "$1" : "${head_pattern#+}")
+ test "$matchlen" = ${#1} || continue
+
+ # if non-ff, $heads must be with the '+' prefix
+ test -n "$noff" &&
+ test "$head_pattern" = "$heads" && continue
+
+ 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
+ done
+ deny "The user is not in the access list for this branch"
+ done
+ )
+ case "$rc" in
+ grant) grant >/dev/null "Granting access based on $allowed_users_file" ;;
+ deny) deny >/dev/null "Denying access based on $allowed_users_file" ;;
+ *) ;;
+ esac
+fi
+
+allowed_groups_file=$GIT_DIR/info/allowed-groups
+groups=$(id -G -n)
+info "The user belongs to the following groups:"
+info "'$groups'"
+
+if test -f "$allowed_groups_file"
+then
+ rc=$(grep -Ev '^(#|$)' $allowed_groups_file |
+ while read heads group_patterns
+ do
+ # does this rule apply to us?
+ head_pattern=${heads#+}
+ matchlen=$(expr "$1" : "${head_pattern#+}")
+ test "$matchlen" = ${#1} || continue
+
+ # if non-ff, $heads must be with the '+' prefix
+ test -n "$noff" &&
+ test "$head_pattern" = "$heads" && continue
+
+ 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
+ done
+ done
+ deny "None of the user's groups are in the access list for this branch"
+ done
+ )
+ case "$rc" in
+ grant) grant >/dev/null "Granting access based on $allowed_groups_file" ;;
+ deny) deny >/dev/null "Denying access based on $allowed_groups_file" ;;
+ *) ;;
+ esac
+fi
+
+deny >/dev/null "There are no more rules to check. Denying access"
+----------------------------------------------------
+
+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/seen 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 "seen" branches and make versioned tags. And anybody
+can do tmp/blah branches. The '+' sign at the "seen" record means
+that JC can make non-fast-forward pushes on it.
diff --git a/howto/use-git-daemon.adoc b/howto/use-git-daemon.adoc
new file mode 100644
index 0000000..2cad9b3
--- /dev/null
+++ b/howto/use-git-daemon.adoc
@@ -0,0 +1,54 @@
+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
+to let a coworker pull from you, and therefore need to set up a Git server
+real quick, right?
+
+Note that git-daemon is not really chatty at the moment, especially when
+things do not go according to plan (e.g. a socket could not be bound).
+
+Another word of warning: if you run
+
+ $ git ls-remote git://127.0.0.1/rule-the-world.git
+
+and you see a message like
+
+ fatal: The remote end hung up unexpectedly
+
+it only means that _something_ went wrong. To find out _what_ went wrong,
+you have to ask the server. (Git refuses to be more precise for your
+security only. Take off your shoes now. You have any coins in your pockets?
+Sorry, not allowed -- who knows what you planned to do with them?)
+
+With these two caveats, let's see an example:
+
+ $ git daemon --reuseaddr --verbose --base-path=/home/gitte/git \
+ --export-all -- /home/gitte/git/rule-the-world.git
+
+(Of course, unless your user name is `gitte` _and_ your repository is in
+~/rule-the-world.git, you have to adjust the paths. If your repository is
+not bare, be aware that you have to type the path to the .git directory!)
+
+This invocation tries to reuse the address if it is already taken
+(this can save you some debugging, because otherwise killing and restarting
+git-daemon could just silently fail to bind to a socket).
+
+Also, it is (relatively) verbose when somebody actually connects to it.
+It also sets the base path, which means that all the projects which can be
+accessed using this daemon have to reside in or under that path.
+
+The option `--export-all` just means that you _don't_ have to create a
+file named `git-daemon-export-ok` in each exported repository. (Otherwise,
+git-daemon would complain loudly, and refuse to cooperate.)
+
+Last of all, the repository which should be exported is specified. It is
+a good practice to put the paths after a "--" separator.
+
+Now, test your daemon with
+
+ $ git ls-remote git://127.0.0.1/rule-the-world.git
+
+If this does not work, find out why, and submit a patch to this document.
diff --git a/howto/using-merge-subtree.adoc b/howto/using-merge-subtree.adoc
new file mode 100644
index 0000000..3bd581a
--- /dev/null
+++ b/howto/using-merge-subtree.adoc
@@ -0,0 +1,75 @@
+Date: Sat, 5 Jan 2008 20:17:40 -0500
+From: Sean <seanlkml@sympatico.ca>
+To: Miklos Vajna <vmiklos@frugalware.org>
+Cc: git@vger.kernel.org
+Subject: how to use git merge -s subtree?
+Abstract: In this article, Sean demonstrates how one can use the subtree merge
+ strategy.
+Content-type: text/asciidoc
+Message-ID: <BAYC1-PASMTP12374B54BA370A1E1C6E78AE4E0@CEZ.ICE>
+
+How to use the subtree merge strategy
+=====================================
+
+There are situations where you want to include content in your project
+from an independently developed project. You can just pull from the
+other project as long as there are no conflicting paths.
+
+The problematic case is when there are conflicting files. Potential
+candidates are Makefiles and other standard filenames. You could merge
+these files but probably you do not want to. A better solution for this
+problem can be to merge the project as its own subdirectory. This is not
+supported by the 'recursive' merge strategy, so just pulling won't work.
+
+What you want is the 'subtree' merge strategy, which helps you in such a
+situation.
+
+In this example, let's say you have the repository at `/path/to/B` (but
+it can be a URL as well, if you want). You want to merge the 'master'
+branch of that repository to the `dir-B` subdirectory in your current
+branch.
+
+Here is the command sequence you need:
+
+----------------
+$ git remote add -f Bproject /path/to/B <1>
+$ git merge -s ours --no-commit --allow-unrelated-histories Bproject/master <2>
+$ git read-tree --prefix=dir-B/ -u Bproject/master <3>
+$ git commit -m "Merge B project as our subdirectory" <4>
+
+$ git pull -s subtree Bproject master <5>
+----------------
+<1> name the other project "Bproject", and fetch.
+<2> prepare for the later step to record the result as a merge.
+<3> read "master" branch of Bproject to the subdirectory "dir-B".
+<4> record the merge result.
+<5> maintain the result with subsequent merges using "subtree"
+
+The first four commands are used for the initial merge, while the last
+one is to merge updates from 'B project'.
+
+Comparing 'subtree' merge with submodules
+-----------------------------------------
+
+- The benefit of using subtree merge is that it requires less
+ administrative burden from the users of your repository. It works with
+ older (before Git v1.5.2) clients and you have the code right after
+ clone.
+
+- However if you use submodules then you can choose not to transfer the
+ submodule objects. This may be a problem with the subtree merge.
+
+- Also, in case you make changes to the other project, it is easier to
+ submit changes if you just use submodules.
+
+Additional tips
+---------------
+
+- If you made changes to the other project in your repository, they may
+ want to merge from your project. This is possible using subtree -- it
+ can shift up the paths in your tree and then they can merge only the
+ relevant parts of your tree.
+
+- Please note that if the other project merges from you, then it will
+ connect its history to yours, which can be something they don't want
+ to.
diff --git a/howto/using-signed-tag-in-pull-request.adoc b/howto/using-signed-tag-in-pull-request.adoc
new file mode 100644
index 0000000..bbf040e
--- /dev/null
+++ b/howto/using-signed-tag-in-pull-request.adoc
@@ -0,0 +1,217 @@
+From: Junio C Hamano <gitster@pobox.com>
+Date: Tue, 17 Jan 2011 13:00:00 -0800
+Subject: Using signed tag in pull requests
+Abstract: Beginning v1.7.9, a contributor can push a signed tag to her
+ publishing repository and ask her integrator to pull it. This assures the
+ integrator that the pulled history is authentic and allows others to
+ later validate it.
+Content-type: text/asciidoc
+
+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
+the "upstream" person (often the owner of the project where she forked
+from) to pull from her public repository. Requesting such a "pull" is made
+easy by the `git request-pull` command.
+
+Earlier, a typical pull request may have started like this:
+
+------------
+ The following changes since commit 406da78032179...:
+
+ Froboz 3.2 (2011-09-30 14:20:57 -0700)
+
+ are available in the Git repository at:
+
+ example.com:/git/froboz.git for-xyzzy
+------------
+
+followed by a shortlog of the changes and a diffstat.
+
+The request was for a branch name (e.g. `for-xyzzy`) in the public
+repository of the contributor, and even though it stated where the
+contributor forked her work from, the message did not say anything about
+the commit to expect at the tip of the for-xyzzy branch. If the site that
+hosts the public repository of the contributor cannot be fully trusted, it
+was unnecessarily hard to make sure what was pulled by the integrator was
+genuinely what the contributor had produced for the project. Also there
+was no easy way for third-party auditors to later verify the resulting
+history.
+
+Starting from Git release v1.7.9, a contributor can add a signed tag to
+the commit at the tip of the history and ask the integrator to pull that
+signed tag. When the integrator runs `git pull`, the signed tag is
+automatically verified to assure that the history is not tampered with.
+In addition, the resulting merge commit records the content of the signed
+tag, so that other people can verify that the branch merged by the
+integrator was signed by the contributor, without fetching the signed tag
+used to validate the pull request separately and keeping it in the refs
+namespace.
+
+This document describes the workflow between the contributor and the
+integrator, using Git v1.7.9 or later.
+
+
+A contributor or a lieutenant
+-----------------------------
+
+After preparing her work to be pulled, the contributor uses `git tag -s`
+to create a signed tag:
+
+------------
+ $ git checkout work
+ $ ... "git pull" from sublieutenants, "git commit" your own work ...
+ $ git tag -s -m "Completed frotz feature" frotz-for-xyzzy work
+------------
+
+Note that this example uses the `-m` option to create a signed tag with
+just a one-liner message, but this is for illustration purposes only. It
+is advisable to compose a well-written explanation of what the topic does
+to justify why it is worthwhile for the integrator to pull it, as this
+message will eventually become part of the final history after the
+integrator responds to the pull request (as we will see later).
+
+Then she pushes the tag out to her public repository:
+
+------------
+ $ git push example.com:/git/froboz.git/ +frotz-for-xyzzy
+------------
+
+There is no need to push the `work` branch or anything else.
+
+Note that the above command line used a plus sign at the beginning of
+`+frotz-for-xyzzy` to allow forcing the update of a tag, as the same
+contributor may want to reuse a signed tag with the same name after the
+previous pull request has already been responded to.
+
+The contributor then prepares a message to request a "pull":
+
+------------
+ $ git request-pull v3.2 example.com:/git/froboz.git/ frotz-for-xyzzy >msg.txt
+------------
+
+The arguments are:
+
+. the version of the integrator's commit the contributor based her work on;
+. the URL of the repository, to which the contributor has pushed what she
+ wants to get pulled; and
+. the name of the tag the contributor wants to get pulled (earlier, she could
+ write only a branch name here).
+
+The resulting msg.txt file begins like so:
+
+------------
+ The following changes since commit 406da78032179...:
+
+ Froboz 3.2 (2011-09-30 14:20:57 -0700)
+
+ are available in the Git repository at:
+
+ example.com:/git/froboz.git tags/frotz-for-xyzzy
+
+ for you to fetch changes up to 703f05ad5835c...:
+
+ Add tests and documentation for frotz (2011-12-02 10:02:52 -0800)
+
+ -----------------------------------------------
+ Completed frotz feature
+ -----------------------------------------------
+------------
+
+followed by a shortlog of the changes and a diffstat. Comparing this with
+the earlier illustration of the output from the traditional `git request-pull`
+command, the reader should notice that:
+
+. The tip commit to expect is shown to the integrator; and
+. The signed tag message is shown prominently between the dashed lines
+ before the shortlog.
+
+The latter is why the contributor would want to justify why pulling her
+work is worthwhile when creating the signed tag. The contributor then
+opens her favorite MUA, reads msg.txt, edits and sends it to her upstream
+integrator.
+
+
+Integrator
+----------
+
+After receiving such a pull request message, the integrator fetches and
+integrates the tag named in the request, with:
+
+------------
+ $ git pull example.com:/git/froboz.git/ tags/frotz-for-xyzzy
+------------
+
+This operation will always open an editor to allow the integrator to fine
+tune the commit log message when merging a signed tag. Also, pulling a
+signed tag will always create a merge commit even when the integrator does
+not have any new commit since the contributor's work forked (i.e. 'fast
+forward'), so that the integrator can properly explain what the merge is
+about and why it was made.
+
+In the editor, the integrator will see something like this:
+
+------------
+ Merge tag 'frotz-for-xyzzy' of example.com:/git/froboz.git/
+
+ Completed frotz feature
+ # gpg: Signature made Fri 02 Dec 2011 10:03:01 AM PST using RSA key ID 96AFE6CB
+ # gpg: Good signature from "Con Tributor <nitfol@example.com>"
+------------
+
+Notice that the message recorded in the signed tag "Completed frotz
+feature" appears here, and again that is why it is important for the
+contributor to explain her work well when creating the signed tag.
+
+As usual, the lines commented with `#` are stripped out. The resulting
+commit records the signed tag used for this validation in a hidden field
+so that it can later be used by others to audit the history. There is no
+need for the integrator to keep a separate copy of the tag in his
+repository (i.e. `git tag -l` won't list the `frotz-for-xyzzy` tag in the
+above example), and there is no need to publish the tag to his public
+repository, either.
+
+After the integrator responds to the pull request and her work becomes
+part of the permanent history, the contributor can remove the tag from
+her public repository, if she chooses, in order to keep the tag namespace
+of her public repository clean, with:
+
+------------
+ $ git push example.com:/git/froboz.git :frotz-for-xyzzy
+------------
+
+
+Auditors
+--------
+
+The `--show-signature` option can be given to `git log` or `git show` and
+shows the verification status of the embedded signed tag in merge commits
+created when the integrator responded to a pull request of a signed tag.
+
+A typical output from `git show --show-signature` may look like this:
+
+------------
+ $ git show --show-signature
+ commit 02306ef6a3498a39118aef9df7975bdb50091585
+ merged tag 'frotz-for-xyzzy'
+ gpg: Signature made Fri 06 Jan 2012 12:41:49 PM PST using RSA key ID 96AFE6CB
+ gpg: Good signature from "Con Tributor <nitfol@example.com>"
+ Merge: 406da78 703f05a
+ Author: Inte Grator <xyzzy@example.com>
+ Date: Tue Jan 17 13:49:41 2012 -0800
+
+ Merge tag 'frotz-for-xyzzy' of example.com:/git/froboz.git/
+
+ Completed frotz feature
+
+ * tag 'frotz-for-xyzzy' (100 commits)
+ Add tests and documentation for frotz
+ ...
+------------
+
+There is no need for the auditor to explicitly fetch the contributor's
+signature, or to even be aware of what tag(s) the contributor and integrator
+used to communicate the signature. All the required information is recorded
+as part of the merge commit.
diff --git a/i18n.adoc b/i18n.adoc
new file mode 100644
index 0000000..baff780
--- /dev/null
+++ b/i18n.adoc
@@ -0,0 +1,70 @@
+Git is to some extent character encoding agnostic.
+
+ - The contents of the blob objects are uninterpreted sequences
+ of bytes. There is no encoding translation at the core
+ level.
+
+ - Path names are encoded in UTF-8 normalization form C. This
+ applies to tree objects, the index file, ref names, as well as
+ path names in command line arguments, environment variables
+ and config files (`.git/config` (see linkgit:git-config[1]),
+ linkgit:gitignore[5], linkgit:gitattributes[5] and
+ linkgit:gitmodules[5]).
++
+Note that Git at the core level treats path names simply as
+sequences of non-NUL bytes, there are no path name encoding
+conversions (except on Mac and Windows). Therefore, using
+non-ASCII path names will mostly work even on platforms and file
+systems that use legacy extended ASCII encodings. However,
+repositories created on such systems will not work properly on
+UTF-8-based systems (e.g. Linux, Mac, Windows) and vice versa.
+Additionally, many Git-based tools simply assume path names to
+be UTF-8 and will fail to display other encodings correctly.
+
+ - Commit log messages are typically encoded in UTF-8, but other
+ extended ASCII encodings are also supported. This includes
+ ISO-8859-x, CP125x and many others, but _not_ UTF-16/32,
+ EBCDIC and CJK multi-byte encodings (GBK, Shift-JIS, Big5,
+ EUC-x, CP9xx etc.).
+
+Although we encourage that the commit log messages are encoded
+in UTF-8, both the core and Git Porcelain are designed not to
+force UTF-8 on projects. If all participants of a particular
+project find it more convenient to use legacy encodings, Git
+does not forbid it. However, there are a few things to keep in
+mind.
+
+. `git commit` and `git commit-tree` issue
+ a warning if the commit log message given to it does not look
+ like a valid UTF-8 string, unless you explicitly say your
+ project uses a legacy encoding. The way to say this is to
+ have `i18n.commitEncoding` in `.git/config` file, like this:
++
+------------
+[i18n]
+ commitEncoding = ISO-8859-1
+------------
++
+Commit objects created with the above setting record the value
+of `i18n.commitEncoding` in their `encoding` header. This is to
+help other people who look at them later. Lack of this header
+implies that the commit log message is encoded in UTF-8.
+
+. `git log`, `git show`, `git blame` and friends look at the
+ `encoding` header of a commit object, and try to re-code the
+ log message into UTF-8 unless otherwise specified. You can
+ specify the desired output encoding with
+ `i18n.logOutputEncoding` in `.git/config` file, like this:
++
+------------
+[i18n]
+ logOutputEncoding = ISO-8859-1
+------------
++
+If you do not have this configuration variable, the value of
+`i18n.commitEncoding` is used instead.
+
+Note that we deliberately chose not to re-code the commit log
+message when a commit is made to force UTF-8 at the commit
+object level, because re-coding to UTF-8 is not necessarily a
+reversible operation.
diff --git a/line-range-format.adoc b/line-range-format.adoc
new file mode 100644
index 0000000..9b51e9f
--- /dev/null
+++ b/line-range-format.adoc
@@ -0,0 +1,32 @@
+'<start>' and '<end>' can take one of these forms:
+
+- number
++
+If '<start>' or '<end>' is a number, it specifies an
+absolute line number (lines count from 1).
++
+
+- `/regex/`
++
+This form will use the first line matching the given
+POSIX regex. If '<start>' is a regex, it will search from the end of
+the previous `-L` range, if any, otherwise from the start of file.
+If '<start>' is `^/regex/`, it will search from the start of file.
+If '<end>' is a regex, it will search
+starting at the line given by '<start>'.
++
+
+- +offset or -offset
++
+This is only valid for '<end>' and will specify a number
+of lines before or after the line given by '<start>'.
+
++
+If `:<funcname>` is given in place of '<start>' and '<end>', it is a
+regular expression that denotes the range from the first funcname line
+that matches '<funcname>', up to the next funcname line. `:<funcname>`
+searches from the end of the previous `-L` range, if any, otherwise
+from the start of file. `^:<funcname>` searches from the start of
+file. The function names are determined in the same way as `git diff`
+works out patch hunk headers (see 'Defining a custom hunk-header'
+in linkgit:gitattributes[5]).
diff --git a/line-range-options.adoc b/line-range-options.adoc
new file mode 100644
index 0000000..f275df3
--- /dev/null
+++ b/line-range-options.adoc
@@ -0,0 +1,15 @@
+-L<start>,<end>:<file>::
+-L:<funcname>:<file>::
+
+ Trace the evolution of the line range given by '<start>,<end>',
+ or by the function name regex '<funcname>', within the '<file>'. You may
+ not give any pathspec limiters. This is currently limited to
+ a walk starting from a single revision, i.e., you may only
+ give zero or one positive revision arguments, and
+ '<start>' and '<end>' (or '<funcname>') must exist in the starting revision.
+ You can specify this option more than once. Implies `--patch`.
+ Patch output can be suppressed using `--no-patch`, but other diff formats
+ (namely `--raw`, `--numstat`, `--shortstat`, `--dirstat`, `--summary`,
+ `--name-only`, `--name-status`, `--check`) are not currently implemented.
++
+include::line-range-format.adoc[]
diff --git a/merge-options.adoc b/merge-options.adoc
new file mode 100644
index 0000000..0022185
--- /dev/null
+++ b/merge-options.adoc
@@ -0,0 +1,210 @@
+--commit::
+--no-commit::
+ Perform the merge and commit the result. This option can
+ be used to override --no-commit.
+ifdef::git-pull[]
+ Only useful when merging.
+endif::git-pull[]
++
+With --no-commit perform the merge and stop just before creating
+a merge commit, to give the user a chance to inspect and further
+tweak the merge result before committing.
++
+Note that fast-forward updates do not create a merge commit and
+therefore there is no way to stop those merges with --no-commit.
+Thus, if you want to ensure your branch is not changed or updated
+by the merge command, use --no-ff with --no-commit.
+
+--edit::
+-e::
+--no-edit::
+ Invoke an editor before committing successful mechanical merge to
+ further edit the auto-generated merge message, so that the user
+ can explain and justify the merge. The `--no-edit` option can be
+ used to accept the auto-generated message (this is generally
+ discouraged).
+ifndef::git-pull[]
+The `--edit` (or `-e`) option is still useful if you are
+giving a draft message with the `-m` option from the command line
+and want to edit it in the editor.
+endif::git-pull[]
++
+Older scripts may depend on the historical behaviour of not allowing the
+user to edit the merge log message. They will see an editor opened when
+they run `git merge`. To make it easier to adjust such scripts to the
+updated behaviour, the environment variable `GIT_MERGE_AUTOEDIT` can be
+set to `no` at the beginning of them.
+
+--cleanup=<mode>::
+ This option determines how the merge message will be cleaned up before
+ committing. See linkgit:git-commit[1] for more details. In addition, if
+ the '<mode>' is given a value of `scissors`, scissors will be appended
+ to `MERGE_MSG` before being passed on to the commit machinery in the
+ case of a merge conflict.
+
+ifdef::git-merge[]
+--ff::
+--no-ff::
+--ff-only::
+ Specifies how a merge is handled when the merged-in history is
+ already a descendant of the current history. `--ff` is the
+ default unless merging an annotated (and possibly signed) tag
+ that is not stored in its natural place in the `refs/tags/`
+ hierarchy, in which case `--no-ff` is assumed.
+endif::git-merge[]
+ifdef::git-pull[]
+--ff-only::
+ Only update to the new history if there is no divergent local
+ history. This is the default when no method for reconciling
+ divergent histories is provided (via the --rebase=* flags).
+
+--ff::
+--no-ff::
+ When merging rather than rebasing, specifies how a merge is
+ handled when the merged-in history is already a descendant of
+ the current history. If merging is requested, `--ff` is the
+ default unless merging an annotated (and possibly signed) tag
+ that is not stored in its natural place in the `refs/tags/`
+ hierarchy, in which case `--no-ff` is assumed.
+endif::git-pull[]
++
+With `--ff`, when possible resolve the merge as a fast-forward (only
+update the branch pointer to match the merged branch; do not create a
+merge commit). When not possible (when the merged-in history is not a
+descendant of the current history), create a merge commit.
++
+With `--no-ff`, create a merge commit in all cases, even when the merge
+could instead be resolved as a fast-forward.
+ifdef::git-merge[]
++
+With `--ff-only`, resolve the merge as a fast-forward when possible.
+When not possible, refuse to merge and exit with a non-zero status.
+endif::git-merge[]
+
+-S[<keyid>]::
+--gpg-sign[=<keyid>]::
+--no-gpg-sign::
+ GPG-sign the resulting merge commit. The `keyid` argument is
+ optional and defaults to the committer identity; if specified,
+ it must be stuck to the option without a space. `--no-gpg-sign`
+ is useful to countermand both `commit.gpgSign` configuration variable,
+ and earlier `--gpg-sign`.
+
+--log[=<n>]::
+--no-log::
+ In addition to branch names, populate the log message with
+ one-line descriptions from at most <n> actual commits that are being
+ merged. See also linkgit:git-fmt-merge-msg[1].
+ifdef::git-pull[]
+ Only useful when merging.
+endif::git-pull[]
++
+With --no-log do not list one-line descriptions from the
+actual commits being merged.
+
+include::signoff-option.adoc[]
+
+--stat::
+-n::
+--no-stat::
+ Show a diffstat at the end of the merge. The diffstat is also
+ controlled by the configuration option merge.stat.
++
+With -n or --no-stat do not show a diffstat at the end of the
+merge.
+
+--squash::
+--no-squash::
+ Produce the working tree and index state as if a real merge
+ happened (except for the merge information), but do not actually
+ make a commit, move the `HEAD`, or record `$GIT_DIR/MERGE_HEAD`
+ (to cause the next `git commit` command to create a merge
+ commit). This allows you to create a single commit on top of
+ the current branch whose effect is the same as merging another
+ branch (or more in case of an octopus).
++
+With --no-squash perform the merge and commit the result. This
+option can be used to override --squash.
++
+With --squash, --commit is not allowed, and will fail.
+ifdef::git-pull[]
++
+Only useful when merging.
+endif::git-pull[]
+
+--[no-]verify::
+ By default, the pre-merge and commit-msg hooks are run.
+ When `--no-verify` is given, these are bypassed.
+ See also linkgit:githooks[5].
+ifdef::git-pull[]
+ Only useful when merging.
+endif::git-pull[]
+
+-s <strategy>::
+--strategy=<strategy>::
+ Use the given merge strategy; can be supplied more than
+ once to specify them in the order they should be tried.
+ If there is no `-s` option, a built-in list of strategies
+ is used instead (`ort` when merging a single head,
+ `octopus` otherwise).
+
+-X <option>::
+--strategy-option=<option>::
+ Pass merge strategy specific option through to the merge
+ strategy.
+
+--verify-signatures::
+--no-verify-signatures::
+ Verify that the tip commit of the side branch being merged is
+ signed with a valid key, i.e. a key that has a valid uid: in the
+ default trust model, this means the signing key has been signed by
+ a trusted key. If the tip commit of the side branch is not signed
+ with a valid key, the merge is aborted.
+ifdef::git-pull[]
++
+Only useful when merging.
+endif::git-pull[]
+
+--summary::
+--no-summary::
+ Synonyms to --stat and --no-stat; these are deprecated and will be
+ removed in the future.
+
+ifndef::git-pull[]
+-q::
+--quiet::
+ Operate quietly. Implies --no-progress.
+
+-v::
+--verbose::
+ Be verbose.
+
+--progress::
+--no-progress::
+ Turn progress on/off explicitly. If neither is specified,
+ progress is shown if standard error is connected to a terminal.
+ Note that not all merge strategies may support progress
+ reporting.
+
+endif::git-pull[]
+
+--autostash::
+--no-autostash::
+ Automatically create a temporary stash entry before the operation
+ begins, record it in the ref `MERGE_AUTOSTASH`
+ and apply it after the operation ends. This means
+ that you can run the operation on a dirty worktree. However, use
+ with care: the final stash application after a successful
+ merge might result in non-trivial conflicts.
+
+--allow-unrelated-histories::
+ By default, `git merge` command refuses to merge histories
+ that do not share a common ancestor. This option can be
+ used to override this safety when merging histories of two
+ projects that started their lives independently. As that is
+ a very rare occasion, no configuration variable to enable
+ this by default exists and will not be added.
+ifdef::git-pull[]
++
+Only useful when merging.
+endif::git-pull[]
diff --git a/merge-strategies.adoc b/merge-strategies.adoc
new file mode 100644
index 0000000..5fc54ec
--- /dev/null
+++ b/merge-strategies.adoc
@@ -0,0 +1,153 @@
+MERGE STRATEGIES
+----------------
+
+The merge mechanism (`git merge` and `git pull` commands) allows the
+backend 'merge strategies' to be chosen with `-s` option. Some strategies
+can also take their own options, which can be passed by giving `-X<option>`
+arguments to `git merge` and/or `git pull`.
+
+ort::
+ This is the default merge strategy when pulling or merging one
+ branch. This strategy can only resolve two heads using a
+ 3-way merge algorithm. When there is more than one common
+ ancestor that can be used for 3-way merge, it creates a merged
+ tree of the common ancestors and uses that as the reference
+ tree for the 3-way merge. This has been reported to result in
+ fewer merge conflicts without causing mismerges by tests done
+ on actual merge commits taken from Linux 2.6 kernel
+ development history. Additionally this strategy can detect
+ and handle merges involving renames. It does not make use of
+ detected copies. The name for this algorithm is an acronym
+ ("Ostensibly Recursive's Twin") and came from the fact that it
+ was written as a replacement for the previous default
+ algorithm, `recursive`.
++
+The 'ort' strategy can take the following options:
+
+ours;;
+ This option forces conflicting hunks to be auto-resolved cleanly by
+ favoring 'our' version. Changes from the other tree that do not
+ conflict with our side are reflected in the merge result.
+ For a binary file, the entire contents are taken from our side.
++
+This should not be confused with the 'ours' merge strategy, which does not
+even look at what the other tree contains at all. It discards everything
+the other tree did, declaring 'our' history contains all that happened in it.
+
+theirs;;
+ This is the opposite of 'ours'; note that, unlike 'ours', there is
+ no 'theirs' merge strategy to confuse this merge option with.
+
+ignore-space-change;;
+ignore-all-space;;
+ignore-space-at-eol;;
+ignore-cr-at-eol;;
+ Treats lines with the indicated type of whitespace change as
+ unchanged for the sake of a three-way merge. Whitespace
+ changes mixed with other changes to a line are not ignored.
+ See also linkgit:git-diff[1] `-b`, `-w`,
+ `--ignore-space-at-eol`, and `--ignore-cr-at-eol`.
++
+* If 'their' version only introduces whitespace changes to a line,
+ 'our' version is used;
+* If 'our' version introduces whitespace changes but 'their'
+ version includes a substantial change, 'their' version is used;
+* Otherwise, the merge proceeds in the usual way.
+
+renormalize;;
+ This runs a virtual check-out and check-in of all three stages
+ of a file when resolving a three-way merge. This option is
+ meant to be used when merging branches with different clean
+ filters or end-of-line normalization rules. See "Merging
+ branches with differing checkin/checkout attributes" in
+ linkgit:gitattributes[5] for details.
+
+no-renormalize;;
+ Disables the `renormalize` option. This overrides the
+ `merge.renormalize` configuration variable.
+
+find-renames[=<n>];;
+ Turn on rename detection, optionally setting the similarity
+ threshold. This is the default. This overrides the
+ 'merge.renames' configuration variable.
+ See also linkgit:git-diff[1] `--find-renames`.
+
+rename-threshold=<n>;;
+ Deprecated synonym for `find-renames=<n>`.
+
+subtree[=<path>];;
+ This option is a more advanced form of 'subtree' strategy, where
+ the strategy makes a guess on how two trees must be shifted to
+ match with each other when merging. Instead, the specified path
+ is prefixed (or stripped from the beginning) to make the shape of
+ two trees to match.
+
+recursive::
+ This can only resolve two heads using a 3-way merge
+ algorithm. When there is more than one common
+ ancestor that can be used for 3-way merge, it creates a
+ merged tree of the common ancestors and uses that as
+ the reference tree for the 3-way merge. This has been
+ reported to result in fewer merge conflicts without
+ causing mismerges by tests done on actual merge commits
+ taken from Linux 2.6 kernel development history.
+ Additionally this can detect and handle merges involving
+ renames. It does not make use of detected copies. This was
+ the default strategy for resolving two heads from Git v0.99.9k
+ until v2.33.0.
++
+The 'recursive' strategy takes the same options as 'ort'. However,
+there are three additional options that 'ort' ignores (not documented
+above) that are potentially useful with the 'recursive' strategy:
+
+patience;;
+ Deprecated synonym for `diff-algorithm=patience`.
+
+diff-algorithm=[patience|minimal|histogram|myers];;
+ Use a different diff algorithm while merging, which can help
+ avoid mismerges that occur due to unimportant matching lines
+ (such as braces from distinct functions). See also
+ linkgit:git-diff[1] `--diff-algorithm`. Note that `ort`
+ specifically uses `diff-algorithm=histogram`, while `recursive`
+ defaults to the `diff.algorithm` config setting.
+
+no-renames;;
+ Turn off rename detection. This overrides the `merge.renames`
+ configuration variable.
+ See also linkgit:git-diff[1] `--no-renames`.
+
+resolve::
+ This can only resolve two heads (i.e. the current branch
+ and another branch you pulled from) using a 3-way merge
+ algorithm. It tries to carefully detect criss-cross
+ merge ambiguities. It does not handle renames.
+
+octopus::
+ This resolves cases with more than two heads, but refuses to do
+ a complex merge that needs manual resolution. It is
+ primarily meant to be used for bundling topic branch
+ heads together. This is the default merge strategy when
+ pulling or merging more than one branch.
+
+ours::
+ This resolves any number of heads, but the resulting tree of the
+ merge is always that of the current branch head, effectively
+ ignoring all changes from all other branches. It is meant to
+ be used to supersede old development history of side
+ branches. Note that this is different from the -Xours option to
+ the 'recursive' merge strategy.
+
+subtree::
+ This is a modified `ort` strategy. When merging trees A and
+ B, if B corresponds to a subtree of A, B is first adjusted to
+ match the tree structure of A, instead of reading the trees at
+ the same level. This adjustment is also done to the common
+ ancestor tree.
+
+With the strategies that use 3-way merge (including the default, 'ort'),
+if a change is made on both branches, but later reverted on one of the
+branches, that change will be present in the merged result; some people find
+this behavior confusing. It occurs because only the heads and the merge base
+are considered when performing a merge, not the individual commits. The merge
+algorithm therefore considers the reverted change as no change at all, and
+substitutes the changed version instead.
diff --git a/mergetools-diff.adoc b/mergetools-diff.adoc
new file mode 100644
index 0000000..3e8a24c
--- /dev/null
+++ b/mergetools-diff.adoc
@@ -0,0 +1,25 @@
+`araxis`;; Use Araxis Merge (requires a graphical session)
+`bc`;; Use Beyond Compare (requires a graphical session)
+`bc3`;; Use Beyond Compare (requires a graphical session)
+`bc4`;; Use Beyond Compare (requires a graphical session)
+`codecompare`;; Use Code Compare (requires a graphical session)
+`deltawalker`;; Use DeltaWalker (requires a graphical session)
+`diffmerge`;; Use DiffMerge (requires a graphical session)
+`diffuse`;; Use Diffuse (requires a graphical session)
+`ecmerge`;; Use ECMerge (requires a graphical session)
+`emerge`;; Use Emacs' Emerge
+`examdiff`;; Use ExamDiff Pro (requires a graphical session)
+`guiffy`;; Use Guiffy's Diff Tool (requires a graphical session)
+`gvimdiff`;; Use gVim (requires a graphical session)
+`kdiff3`;; Use KDiff3 (requires a graphical session)
+`kompare`;; Use Kompare (requires a graphical session)
+`meld`;; Use Meld (requires a graphical session)
+`nvimdiff`;; Use Neovim
+`opendiff`;; Use FileMerge (requires a graphical session)
+`p4merge`;; Use HelixCore P4Merge (requires a graphical session)
+`smerge`;; Use Sublime Merge (requires a graphical session)
+`tkdiff`;; Use TkDiff (requires a graphical session)
+`vimdiff`;; Use Vim
+`vscode`;; Use Visual Studio Code (requires a graphical session)
+`winmerge`;; Use WinMerge (requires a graphical session)
+`xxdiff`;; Use xxdiff (requires a graphical session)
diff --git a/mergetools-merge.adoc b/mergetools-merge.adoc
new file mode 100644
index 0000000..f8b9740
--- /dev/null
+++ b/mergetools-merge.adoc
@@ -0,0 +1,34 @@
+`araxis`;; Use Araxis Merge (requires a graphical session)
+`bc`;; Use Beyond Compare (requires a graphical session)
+`bc3`;; Use Beyond Compare (requires a graphical session)
+`bc4`;; Use Beyond Compare (requires a graphical session)
+`codecompare`;; Use Code Compare (requires a graphical session)
+`deltawalker`;; Use DeltaWalker (requires a graphical session)
+`diffmerge`;; Use DiffMerge (requires a graphical session)
+`diffuse`;; Use Diffuse (requires a graphical session)
+`ecmerge`;; Use ECMerge (requires a graphical session)
+`emerge`;; Use Emacs' Emerge
+`examdiff`;; Use ExamDiff Pro (requires a graphical session)
+`guiffy`;; Use Guiffy's Diff Tool (requires a graphical session)
+`gvimdiff`;; Use gVim (requires a graphical session) with a custom layout (see `git help mergetool`'s `BACKEND SPECIFIC HINTS` section)
+`gvimdiff1`;; Use gVim (requires a graphical session) with a 2 panes layout (LOCAL and REMOTE)
+`gvimdiff2`;; Use gVim (requires a graphical session) with a 3 panes layout (LOCAL, MERGED and REMOTE)
+`gvimdiff3`;; Use gVim (requires a graphical session) where only the MERGED file is shown
+`kdiff3`;; Use KDiff3 (requires a graphical session)
+`meld`;; Use Meld (requires a graphical session) with optional `auto merge` (see `git help mergetool`'s `CONFIGURATION` section)
+`nvimdiff`;; Use Neovim with a custom layout (see `git help mergetool`'s `BACKEND SPECIFIC HINTS` section)
+`nvimdiff1`;; Use Neovim with a 2 panes layout (LOCAL and REMOTE)
+`nvimdiff2`;; Use Neovim with a 3 panes layout (LOCAL, MERGED and REMOTE)
+`nvimdiff3`;; Use Neovim where only the MERGED file is shown
+`opendiff`;; Use FileMerge (requires a graphical session)
+`p4merge`;; Use HelixCore P4Merge (requires a graphical session)
+`smerge`;; Use Sublime Merge (requires a graphical session)
+`tkdiff`;; Use TkDiff (requires a graphical session)
+`tortoisemerge`;; Use TortoiseMerge (requires a graphical session)
+`vimdiff`;; Use Vim with a custom layout (see `git help mergetool`'s `BACKEND SPECIFIC HINTS` section)
+`vimdiff1`;; Use Vim with a 2 panes layout (LOCAL and REMOTE)
+`vimdiff2`;; Use Vim with a 3 panes layout (LOCAL, MERGED and REMOTE)
+`vimdiff3`;; Use Vim where only the MERGED file is shown
+`vscode`;; Use Visual Studio Code (requires a graphical session)
+`winmerge`;; Use WinMerge (requires a graphical session)
+`xxdiff`;; Use xxdiff (requires a graphical session)
diff --git a/object-format-disclaimer.adoc b/object-format-disclaimer.adoc
new file mode 100644
index 0000000..e561e66
--- /dev/null
+++ b/object-format-disclaimer.adoc
@@ -0,0 +1,9 @@
+Note: At present, there is no interoperability between SHA-256
+repositories and SHA-1 repositories.
+
+Historically, we warned that SHA-256 repositories may later need
+backward incompatible changes when we introduce such interoperability
+features. Today, we only expect compatible changes. Furthermore, if such
+changes prove to be necessary, it can be expected that SHA-256 repositories
+created with today's Git will be usable by future versions of Git
+without data loss.
diff --git a/pretty-formats.adoc b/pretty-formats.adoc
new file mode 100644
index 0000000..8ee940b
--- /dev/null
+++ b/pretty-formats.adoc
@@ -0,0 +1,388 @@
+PRETTY FORMATS
+--------------
+
+If the commit is a merge, and if the pretty-format
+is not 'oneline', 'email' or 'raw', an additional line is
+inserted before the 'Author:' line. This line begins with
+"Merge: " and the hashes of ancestral commits are printed,
+separated by spaces. Note that the listed commits may not
+necessarily be the list of the *direct* parent commits if you
+have limited your view of history: for example, if you are
+only interested in changes related to a certain directory or
+file.
+
+There are several built-in formats, and you can define
+additional formats by setting a pretty.<name>
+config option to either another format name, or a
+'format:' string, as described below (see
+linkgit:git-config[1]). Here are the details of the
+built-in formats:
+
+* 'oneline'
+
+ <hash> <title-line>
++
+This is designed to be as compact as possible.
+
+* 'short'
+
+ commit <hash>
+ Author: <author>
+
+ <title-line>
+
+* 'medium'
+
+ commit <hash>
+ Author: <author>
+ Date: <author-date>
+
+ <title-line>
+
+ <full-commit-message>
+
+* 'full'
+
+ commit <hash>
+ Author: <author>
+ Commit: <committer>
+
+ <title-line>
+
+ <full-commit-message>
+
+* 'fuller'
+
+ commit <hash>
+ Author: <author>
+ AuthorDate: <author-date>
+ Commit: <committer>
+ CommitDate: <committer-date>
+
+ <title-line>
+
+ <full-commit-message>
+
+* 'reference'
+
+ <abbrev-hash> (<title-line>, <short-author-date>)
++
+This format is used to refer to another commit in a commit message and
+is the same as `--pretty='format:%C(auto)%h (%s, %ad)'`. By default,
+the date is formatted with `--date=short` unless another `--date` option
+is explicitly specified. As with any `format:` with format
+placeholders, its output is not affected by other options like
+`--decorate` and `--walk-reflogs`.
+
+* 'email'
+
+ From <hash> <date>
+ From: <author>
+ Date: <author-date>
+ Subject: [PATCH] <title-line>
+
+ <full-commit-message>
+
+* 'mboxrd'
++
+Like 'email', but lines in the commit message starting with "From "
+(preceded by zero or more ">") are quoted with ">" so they aren't
+confused as starting a new commit.
+
+* 'raw'
++
+The 'raw' format shows the entire commit exactly as
+stored in the commit object. Notably, the hashes are
+displayed in full, regardless of whether --abbrev or
+--no-abbrev are used, and 'parents' information show the
+true parent commits, without taking grafts or history
+simplification into account. Note that this format affects the way
+commits are displayed, but not the way the diff is shown e.g. with
+`git log --raw`. To get full object names in a raw diff format,
+use `--no-abbrev`.
+
+* 'format:<format-string>'
++
+The 'format:<format-string>' format allows you to specify which information
+you want to show. It works a little bit like printf format,
+with the notable exception that you get a newline with '%n'
+instead of '\n'.
++
+E.g, 'format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"'
+would show something like this:
++
+-------
+The author of fe6e0ee was Junio C Hamano, 23 hours ago
+The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
+
+-------
++
+The placeholders are:
+
+- Placeholders that expand to a single literal character:
+'%n':: newline
+'%%':: a raw '%'
+'%x00':: '%x' followed by two hexadecimal digits is replaced with a
+ byte with the hexadecimal digits' value (we will call this
+ "literal formatting code" in the rest of this document).
+
+- Placeholders that affect formatting of later placeholders:
+'%Cred':: switch color to red
+'%Cgreen':: switch color to green
+'%Cblue':: switch color to blue
+'%Creset':: reset color
+'%C(...)':: color specification, as described under Values in the
+ "CONFIGURATION FILE" section of linkgit:git-config[1]. By
+ default, colors are shown only when enabled for log output
+ (by `color.diff`, `color.ui`, or `--color`, and respecting
+ the `auto` settings of the former if we are going to a
+ terminal). `%C(auto,...)` is accepted as a historical
+ synonym for the default (e.g., `%C(auto,red)`). Specifying
+ `%C(always,...)` will show the colors even when color is
+ not otherwise enabled (though consider just using
+ `--color=always` to enable color for the whole output,
+ including this format and anything else git might color).
+ `auto` alone (i.e. `%C(auto)`) will turn on auto coloring
+ on the next placeholders until the color is switched
+ again.
+'%m':: left (`<`), right (`>`) or boundary (`-`) mark
+'%w([<w>[,<i1>[,<i2>]]])':: switch line wrapping, like the -w option of
+ linkgit:git-shortlog[1].
+'%<( <N> [,trunc|ltrunc|mtrunc])':: make the next placeholder take at
+ least N column widths, padding spaces on
+ the right if necessary. Optionally
+ truncate (with ellipsis '..') at the left (ltrunc) `..ft`,
+ the middle (mtrunc) `mi..le`, or the end
+ (trunc) `rig..`, if the output is longer than
+ N columns.
+ Note 1: that truncating
+ only works correctly with N >= 2.
+ Note 2: spaces around the N and M (see below)
+ values are optional.
+ Note 3: Emojis and other wide characters
+ will take two display columns, which may
+ over-run column boundaries.
+ Note 4: decomposed character combining marks
+ may be misplaced at padding boundaries.
+'%<|( <M> )':: make the next placeholder take at least until Mth
+ display column, padding spaces on the right if necessary.
+ Use negative M values for column positions measured
+ from the right hand edge of the terminal window.
+'%>( <N> )', '%>|( <M> )':: similar to '%<( <N> )', '%<|( <M> )' respectively,
+ but padding spaces on the left
+'%>>( <N> )', '%>>|( <M> )':: similar to '%>( <N> )', '%>|( <M> )'
+ respectively, except that if the next
+ placeholder takes more spaces than given and
+ there are spaces on its left, use those
+ spaces
+'%><( <N> )', '%><|( <M> )':: similar to '%<( <N> )', '%<|( <M> )'
+ respectively, but padding both sides
+ (i.e. the text is centered)
+
+- Placeholders that expand to information extracted from the commit:
+'%H':: commit hash
+'%h':: abbreviated commit hash
+'%T':: tree hash
+'%t':: abbreviated tree hash
+'%P':: parent hashes
+'%p':: abbreviated parent hashes
+'%an':: author name
+'%aN':: author name (respecting .mailmap, see linkgit:git-shortlog[1]
+ or linkgit:git-blame[1])
+'%ae':: author email
+'%aE':: author email (respecting .mailmap, see linkgit:git-shortlog[1]
+ or linkgit:git-blame[1])
+'%al':: author email local-part (the part before the '@' sign)
+'%aL':: author local-part (see '%al') respecting .mailmap, see
+ linkgit:git-shortlog[1] or linkgit:git-blame[1])
+'%ad':: author date (format respects --date= option)
+'%aD':: author date, RFC2822 style
+'%ar':: author date, relative
+'%at':: author date, UNIX timestamp
+'%ai':: author date, ISO 8601-like format
+'%aI':: author date, strict ISO 8601 format
+'%as':: author date, short format (`YYYY-MM-DD`)
+'%ah':: author date, human style (like the `--date=human` option of
+ linkgit:git-rev-list[1])
+'%cn':: committer name
+'%cN':: committer name (respecting .mailmap, see
+ linkgit:git-shortlog[1] or linkgit:git-blame[1])
+'%ce':: committer email
+'%cE':: committer email (respecting .mailmap, see
+ linkgit:git-shortlog[1] or linkgit:git-blame[1])
+'%cl':: committer email local-part (the part before the '@' sign)
+'%cL':: committer local-part (see '%cl') respecting .mailmap, see
+ linkgit:git-shortlog[1] or linkgit:git-blame[1])
+'%cd':: committer date (format respects --date= option)
+'%cD':: committer date, RFC2822 style
+'%cr':: committer date, relative
+'%ct':: committer date, UNIX timestamp
+'%ci':: committer date, ISO 8601-like format
+'%cI':: committer date, strict ISO 8601 format
+'%cs':: committer date, short format (`YYYY-MM-DD`)
+'%ch':: committer date, human style (like the `--date=human` option of
+ linkgit:git-rev-list[1])
+'%d':: ref names, like the --decorate option of linkgit:git-log[1]
+'%D':: ref names without the " (", ")" wrapping.
+'%(decorate[:<options>])'::
+ref names with custom decorations. The `decorate` string may be followed by a
+colon and zero or more comma-separated options. Option values may contain
+literal formatting codes. These must be used for commas (`%x2C`) and closing
+parentheses (`%x29`), due to their role in the option syntax.
++
+** 'prefix=<value>': Shown before the list of ref names. Defaults to "{nbsp}`(`".
+** 'suffix=<value>': Shown after the list of ref names. Defaults to "`)`".
+** 'separator=<value>': Shown between ref names. Defaults to "`,`{nbsp}".
+** 'pointer=<value>': Shown between HEAD and the branch it points to, if any.
+ Defaults to "{nbsp}`->`{nbsp}".
+** 'tag=<value>': Shown before tag names. Defaults to "`tag:`{nbsp}".
+
++
+For example, to produce decorations with no wrapping
+or tag annotations, and spaces as separators:
++
+`%(decorate:prefix=,suffix=,tag=,separator= )`
+
+'%(describe[:<options>])'::
+human-readable name, like linkgit:git-describe[1]; empty string for
+undescribable commits. The `describe` string may be followed by a colon and
+zero or more comma-separated options. Descriptions can be inconsistent when
+tags are added or removed at the same time.
++
+** 'tags[=<bool-value>]': Instead of only considering annotated tags,
+ consider lightweight tags as well.
+** 'abbrev=<number>': Instead of using the default number of hexadecimal digits
+ (which will vary according to the number of objects in the repository with a
+ default of 7) of the abbreviated object name, use <number> digits, or as many
+ digits as needed to form a unique object name.
+** 'match=<pattern>': Only consider tags matching the given
+ `glob(7)` pattern, excluding the "refs/tags/" prefix.
+** 'exclude=<pattern>': Do not consider tags matching the given
+ `glob(7)` pattern, excluding the "refs/tags/" prefix.
+
+'%S':: ref name given on the command line by which the commit was reached
+ (like `git log --source`), only works with `git log`
+'%e':: encoding
+'%s':: subject
+'%f':: sanitized subject line, suitable for a filename
+'%b':: body
+'%B':: raw body (unwrapped subject and body)
+ifndef::git-rev-list[]
+'%N':: commit notes
+endif::git-rev-list[]
+'%GG':: raw verification message from GPG for a signed commit
+'%G?':: show "G" for a good (valid) signature,
+ "B" for a bad signature,
+ "U" for a good signature with unknown validity,
+ "X" for a good signature that has expired,
+ "Y" for a good signature made by an expired key,
+ "R" for a good signature made by a revoked key,
+ "E" if the signature cannot be checked (e.g. missing key)
+ and "N" for no signature
+'%GS':: show the name of the signer for a signed commit
+'%GK':: show the key used to sign a signed commit
+'%GF':: show the fingerprint of the key used to sign a signed commit
+'%GP':: show the fingerprint of the primary key whose subkey was used
+ to sign a signed commit
+'%GT':: show the trust level for the key used to sign a signed commit
+'%gD':: reflog selector, e.g., `refs/stash@{1}` or `refs/stash@{2
+ minutes ago}`; the format follows the rules described for the
+ `-g` option. The portion before the `@` is the refname as
+ given on the command line (so `git log -g refs/heads/master`
+ would yield `refs/heads/master@{0}`).
+'%gd':: shortened reflog selector; same as `%gD`, but the refname
+ portion is shortened for human readability (so
+ `refs/heads/master` becomes just `master`).
+'%gn':: reflog identity name
+'%gN':: reflog identity name (respecting .mailmap, see
+ linkgit:git-shortlog[1] or linkgit:git-blame[1])
+'%ge':: reflog identity email
+'%gE':: reflog identity email (respecting .mailmap, see
+ linkgit:git-shortlog[1] or linkgit:git-blame[1])
+'%gs':: reflog subject
+'%(trailers[:<options>])'::
+display the trailers of the body as interpreted by
+linkgit:git-interpret-trailers[1]. The `trailers` string may be followed by
+a colon and zero or more comma-separated options. If any option is provided
+multiple times, the last occurrence wins.
++
+** 'key=<key>': only show trailers with specified <key>. Matching is done
+ case-insensitively and trailing colon is optional. If option is
+ given multiple times trailer lines matching any of the keys are
+ shown. This option automatically enables the `only` option so that
+ non-trailer lines in the trailer block are hidden. If that is not
+ desired it can be disabled with `only=false`. E.g.,
+ `%(trailers:key=Reviewed-by)` shows trailer lines with key
+ `Reviewed-by`.
+** 'only[=<bool>]': select whether non-trailer lines from the trailer
+ block should be included.
+** 'separator=<sep>': specify the separator inserted between trailer
+ lines. Defaults to a line feed character. The string <sep> may contain
+ the literal formatting codes described above. To use comma as
+ separator one must use `%x2C` as it would otherwise be parsed as
+ next option. E.g., `%(trailers:key=Ticket,separator=%x2C )`
+ shows all trailer lines whose key is "Ticket" separated by a comma
+ and a space.
+** 'unfold[=<bool>]': make it behave as if interpret-trailer's `--unfold`
+ option was given. E.g.,
+ `%(trailers:only,unfold=true)` unfolds and shows all trailer lines.
+** 'keyonly[=<bool>]': only show the key part of the trailer.
+** 'valueonly[=<bool>]': only show the value part of the trailer.
+** 'key_value_separator=<sep>': specify the separator inserted between
+ the key and value of each trailer. Defaults to ": ". Otherwise it
+ shares the same semantics as 'separator=<sep>' above.
+
+NOTE: Some placeholders may depend on other options given to the
+revision traversal engine. For example, the `%g*` reflog options will
+insert an empty string unless we are traversing reflog entries (e.g., by
+`git log -g`). The `%d` and `%D` placeholders will use the "short"
+decoration format if `--decorate` was not already provided on the command
+line.
+
+The boolean options accept an optional value `[=<bool-value>]`. The values
+`true`, `false`, `on`, `off` etc. are all accepted. See the "boolean"
+sub-section in "EXAMPLES" in linkgit:git-config[1]. If a boolean
+option is given with no value, it's enabled.
+
+If you add a `+` (plus sign) after '%' of a placeholder, a line-feed
+is inserted immediately before the expansion if and only if the
+placeholder expands to a non-empty string.
+
+If you add a `-` (minus sign) after '%' of a placeholder, all consecutive
+line-feeds immediately preceding the expansion are deleted if and only if the
+placeholder expands to an empty string.
+
+If you add a ` ` (space) after '%' of a placeholder, a space
+is inserted immediately before the expansion if and only if the
+placeholder expands to a non-empty string.
+
+* 'tformat:'
++
+The 'tformat:' format works exactly like 'format:', except that it
+provides "terminator" semantics instead of "separator" semantics. In
+other words, each commit has the message terminator character (usually a
+newline) appended, rather than a separator placed between entries.
+This means that the final entry of a single-line format will be properly
+terminated with a new line, just as the "oneline" format does.
+For example:
++
+---------------------
+$ git log -2 --pretty=format:%h 4da45bef \
+ | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
+4da45be
+7134973 -- NO NEWLINE
+
+$ git log -2 --pretty=tformat:%h 4da45bef \
+ | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
+4da45be
+7134973
+---------------------
++
+In addition, any unrecognized string that has a `%` in it is interpreted
+as if it has `tformat:` in front of it. For example, these two are
+equivalent:
++
+---------------------
+$ git log -2 --pretty=tformat:%h 4da45bef
+$ git log -2 --pretty=%h 4da45bef
+---------------------
diff --git a/pretty-options.adoc b/pretty-options.adoc
new file mode 100644
index 0000000..23888cd
--- /dev/null
+++ b/pretty-options.adoc
@@ -0,0 +1,102 @@
+--pretty[=<format>]::
+--format=<format>::
+
+ Pretty-print the contents of the commit logs in a given format,
+ where '<format>' can be one of 'oneline', 'short', 'medium',
+ 'full', 'fuller', 'reference', 'email', 'raw', 'format:<string>'
+ and 'tformat:<string>'. When '<format>' is none of the above,
+ and has '%placeholder' in it, it acts as if
+ '--pretty=tformat:<format>' were given.
++
+See the "PRETTY FORMATS" section for some additional details for each
+format. When '=<format>' part is omitted, it defaults to 'medium'.
++
+Note: you can specify the default pretty format in the repository
+configuration (see linkgit:git-config[1]).
+
+--abbrev-commit::
+ Instead of showing the full 40-byte hexadecimal commit object
+ name, show a prefix that names the object uniquely.
+ "--abbrev=<n>" (which also modifies diff output, if it is displayed)
+ option can be used to specify the minimum length of the prefix.
++
+This should make "--pretty=oneline" a whole lot more readable for
+people using 80-column terminals.
+
+--no-abbrev-commit::
+ Show the full 40-byte hexadecimal commit object name. This negates
+ `--abbrev-commit`, either explicit or implied by other options such
+ as "--oneline". It also overrides the `log.abbrevCommit` variable.
+
+--oneline::
+ This is a shorthand for "--pretty=oneline --abbrev-commit"
+ used together.
+
+--encoding=<encoding>::
+ Commit objects record the character encoding used for the log message
+ in their encoding header; this option can be used to tell the
+ command to re-code the commit log message in the encoding
+ preferred by the user. For non plumbing commands this
+ defaults to UTF-8. Note that if an object claims to be encoded
+ in `X` and we are outputting in `X`, we will output the object
+ verbatim; this means that invalid sequences in the original
+ commit may be copied to the output. Likewise, if iconv(3) fails
+ to convert the commit, we will quietly output the original
+ object verbatim.
+
+--expand-tabs=<n>::
+--expand-tabs::
+--no-expand-tabs::
+ Perform a tab expansion (replace each tab with enough spaces
+ to fill to the next display column that is a multiple of '<n>')
+ in the log message before showing it in the output.
+ `--expand-tabs` is a short-hand for `--expand-tabs=8`, and
+ `--no-expand-tabs` is a short-hand for `--expand-tabs=0`,
+ which disables tab expansion.
++
+By default, tabs are expanded in pretty formats that indent the log
+message by 4 spaces (i.e. 'medium', which is the default, 'full',
+and 'fuller').
+
+ifndef::git-rev-list[]
+--notes[=<ref>]::
+ Show the notes (see linkgit:git-notes[1]) that annotate the
+ commit, when showing the commit log message. This is the default
+ for `git log`, `git show` and `git whatchanged` commands when
+ there is no `--pretty`, `--format`, or `--oneline` option given
+ on the command line.
++
+By default, the notes shown are from the notes refs listed in the
+`core.notesRef` and `notes.displayRef` variables (or corresponding
+environment overrides). See linkgit:git-config[1] for more details.
++
+With an optional '<ref>' argument, use the ref to find the notes
+to display. The ref can specify the full refname when it begins
+with `refs/notes/`; when it begins with `notes/`, `refs/` and otherwise
+`refs/notes/` is prefixed to form the full name of the ref.
++
+Multiple --notes options can be combined to control which notes are
+being displayed. Examples: "--notes=foo" will show only notes from
+"refs/notes/foo"; "--notes=foo --notes" will show both notes from
+"refs/notes/foo" and from the default notes ref(s).
+
+--no-notes::
+ Do not show notes. This negates the above `--notes` option, by
+ resetting the list of notes refs from which notes are shown.
+ Options are parsed in the order given on the command line, so e.g.
+ "--notes --notes=foo --no-notes --notes=bar" will only show notes
+ from "refs/notes/bar".
+
+--show-notes-by-default::
+ Show the default notes unless options for displaying specific
+ notes are given.
+
+--show-notes[=<ref>]::
+--[no-]standard-notes::
+ These options are deprecated. Use the above --notes/--no-notes
+ options instead.
+endif::git-rev-list[]
+
+--show-signature::
+ Check the validity of a signed commit object by passing the signature
+ to `gpg --verify` and show the output.
diff --git a/pull-fetch-param.adoc b/pull-fetch-param.adoc
new file mode 100644
index 0000000..d79d2f6
--- /dev/null
+++ b/pull-fetch-param.adoc
@@ -0,0 +1,120 @@
+<repository>::
+ The "remote" repository that is the source of a fetch
+ or pull operation. This parameter can be either a URL
+ (see the section <<URLS,GIT URLS>> below) or the name
+ of a remote (see the section <<REMOTES,REMOTES>> below).
+
+ifndef::git-pull[]
+<group>::
+ A name referring to a list of repositories as the value
+ of remotes.<group> in the configuration file.
+ (See linkgit:git-config[1]).
+endif::git-pull[]
+
+<refspec>::
+ Specifies which refs to fetch and which local refs to update.
+ When no <refspec>s appear on the command line, the refs to fetch
+ are read from `remote.<repository>.fetch` variables instead
+ifndef::git-pull[]
+ (see <<CRTB,CONFIGURED REMOTE-TRACKING BRANCHES>> below).
+endif::git-pull[]
+ifdef::git-pull[]
+ (see the section "CONFIGURED REMOTE-TRACKING BRANCHES"
+ in linkgit:git-fetch[1]).
+endif::git-pull[]
++
+The format of a <refspec> parameter is an optional plus
+`+`, followed by the source <src>, followed
+by a colon `:`, followed by the destination <dst>.
+The colon can be omitted when <dst> is empty. <src> is
+typically a ref, or a glob pattern with a single `*` that is used
+to match a set of refs, but it can also be a fully spelled hex object
+name.
++
+A <refspec> may contain a `*` in its <src> to indicate a simple pattern
+match. Such a refspec functions like a glob that matches any ref with the
+pattern. A pattern <refspec> must have one and only one `*` in both the <src> and
+<dst>. It will map refs to the destination by replacing the `*` with the
+contents matched from the source.
++
+If a refspec is prefixed by `^`, it will be interpreted as a negative
+refspec. Rather than specifying which refs to fetch or which local refs to
+update, such a refspec will instead specify refs to exclude. A ref will be
+considered to match if it matches at least one positive refspec, and does
+not match any negative refspec. Negative refspecs can be useful to restrict
+the scope of a pattern refspec so that it will not include specific refs.
+Negative refspecs can themselves be pattern refspecs. However, they may only
+contain a <src> and do not specify a <dst>. Fully spelled out hex object
+names are also not supported.
++
+`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`;
+it requests fetching everything up to the given tag.
++
+The remote ref that matches <src>
+is fetched, and if <dst> is not an empty string, an attempt
+is made to update the local ref that matches it.
++
+Whether that update is allowed without `--force` depends on the ref
+namespace it's being fetched to, the type of object being fetched, and
+whether the update is considered to be a fast-forward. Generally, the
+same rules apply for fetching as when pushing, see the `<refspec>...`
+section of linkgit:git-push[1] for what those are. Exceptions to those
+rules particular to 'git fetch' are noted below.
++
+Until Git version 2.20, and unlike when pushing with
+linkgit:git-push[1], any updates to `refs/tags/*` would be accepted
+without `+` in the refspec (or `--force`). When fetching, we promiscuously
+considered all tag updates from a remote to be forced fetches. Since
+Git version 2.20, fetching to update `refs/tags/*` works the same way
+as when pushing. I.e. any updates will be rejected without `+` in the
+refspec (or `--force`).
++
+Unlike when pushing with linkgit:git-push[1], any updates outside of
+`refs/{tags,heads}/*` will be accepted without `+` in the refspec (or
+`--force`), whether that's swapping e.g. a tree object for a blob, or
+a commit for another commit that doesn't have the previous commit as
+an ancestor etc.
++
+Unlike when pushing with linkgit:git-push[1], there is no
+configuration which'll amend these rules, and nothing like a
+`pre-fetch` hook analogous to the `pre-receive` hook.
++
+As with pushing with linkgit:git-push[1], all of the rules described
+above about what's not allowed as an update can be overridden by
+adding an optional leading `+` to a refspec (or using the `--force`
+command line option). The only exception to this is that no amount of
+forcing will make the `refs/heads/*` namespace accept a non-commit
+object.
++
+[NOTE]
+When the remote branch you want to fetch is known to
+be rewound and rebased regularly, it is expected that
+its new tip will not be a descendant of its previous tip
+(as stored in your remote-tracking branch the last time
+you fetched). You would want
+to use the `+` sign to indicate non-fast-forward updates
+will be needed for such branches. There is no way to
+determine or declare that a branch will be made available
+in a repository with this behavior; the pulling user simply
+must know this is the expected usage pattern for a branch.
+ifdef::git-pull[]
++
+[NOTE]
+There is a difference between listing multiple <refspec>
+directly on 'git pull' command line and having multiple
+`remote.<repository>.fetch` entries in your configuration
+for a <repository> and running a
+'git pull' command without any explicit <refspec> parameters.
+<refspec>s listed explicitly on the command line are always
+merged into the current branch after fetching. In other words,
+if you list more than one remote ref, 'git pull' will create
+an Octopus merge. On the other hand, if you do not list any
+explicit <refspec> parameter on the command line, 'git pull'
+will fetch all the <refspec>s it finds in the
+`remote.<repository>.fetch` configuration and merge
+only the first <refspec> found into the current branch.
+This is because making an
+Octopus from remote refs is rarely done, while keeping track
+of multiple remote heads in one-go by fetching more than one
+is often useful.
+endif::git-pull[]
diff --git a/ref-reachability-filters.adoc b/ref-reachability-filters.adoc
new file mode 100644
index 0000000..9bae46d
--- /dev/null
+++ b/ref-reachability-filters.adoc
@@ -0,0 +1,7 @@
+When combining multiple `--contains` and `--no-contains` filters, only
+references that contain at least one of the `--contains` commits and
+contain none of the `--no-contains` commits are shown.
+
+When combining multiple `--merged` and `--no-merged` filters, only
+references that are reachable from at least one of the `--merged`
+commits and from none of the `--no-merged` commits are shown.
diff --git a/ref-storage-format.adoc b/ref-storage-format.adoc
new file mode 100644
index 0000000..14fff8a
--- /dev/null
+++ b/ref-storage-format.adoc
@@ -0,0 +1,3 @@
+* `files` for loose files with packed-refs. This is the default.
+* `reftable` for the reftable format. This format is experimental and its
+ internals are subject to change.
diff --git a/rerere-options.adoc b/rerere-options.adoc
new file mode 100644
index 0000000..c3321dd
--- /dev/null
+++ b/rerere-options.adoc
@@ -0,0 +1,9 @@
+--rerere-autoupdate::
+--no-rerere-autoupdate::
+ After the rerere mechanism reuses a recorded resolution on
+ the current conflict to update the files in the working
+ tree, allow it to also update the index with the result of
+ resolution. `--no-rerere-autoupdate` is a good way to
+ double-check what `rerere` did and catch potential
+ mismerges, before committing the result to the index with a
+ separate `git add`.
diff --git a/rev-list-description.adoc b/rev-list-description.adoc
new file mode 100644
index 0000000..a9efa7f
--- /dev/null
+++ b/rev-list-description.adoc
@@ -0,0 +1,61 @@
+List commits that are reachable by following the `parent` links from the
+given commit(s), but exclude commits that are reachable from the one(s)
+given with a '{caret}' in front of them. The output is given in reverse
+chronological order by default.
+
+You can think of this as a set operation. Commits reachable from any of
+the commits given on the command line form a set, and then commits reachable
+from any of the ones given with '{caret}' in front are subtracted from that
+set. The remaining commits are what comes out in the command's output.
+Various other options and paths parameters can be used to further limit the
+result.
+
+Thus, the following command:
+
+ifdef::git-rev-list[]
+-----------------------------------------------------------------------
+$ git rev-list foo bar ^baz
+-----------------------------------------------------------------------
+endif::git-rev-list[]
+ifdef::git-log[]
+-----------------------------------------------------------------------
+$ git log foo bar ^baz
+-----------------------------------------------------------------------
+endif::git-log[]
+
+means "list all the commits which are reachable from 'foo' or 'bar', but
+not from 'baz'".
+
+A special notation "'<commit1>'..'<commit2>'" can be used as a
+short-hand for "^'<commit1>' '<commit2>'". For example, either of
+the following may be used interchangeably:
+
+ifdef::git-rev-list[]
+-----------------------------------------------------------------------
+$ git rev-list origin..HEAD
+$ git rev-list HEAD ^origin
+-----------------------------------------------------------------------
+endif::git-rev-list[]
+ifdef::git-log[]
+-----------------------------------------------------------------------
+$ git log origin..HEAD
+$ git log HEAD ^origin
+-----------------------------------------------------------------------
+endif::git-log[]
+
+Another special notation is "'<commit1>'...'<commit2>'" which is useful
+for merges. The resulting set of commits is the symmetric difference
+between the two operands. The following two commands are equivalent:
+
+ifdef::git-rev-list[]
+-----------------------------------------------------------------------
+$ git rev-list A B --not $(git merge-base --all A B)
+$ git rev-list A...B
+-----------------------------------------------------------------------
+endif::git-rev-list[]
+ifdef::git-log[]
+-----------------------------------------------------------------------
+$ git log A B --not $(git merge-base --all A B)
+$ git log A...B
+-----------------------------------------------------------------------
+endif::git-log[]
diff --git a/rev-list-options.adoc b/rev-list-options.adoc
new file mode 100644
index 0000000..196b278
--- /dev/null
+++ b/rev-list-options.adoc
@@ -0,0 +1,1216 @@
+Commit Limiting
+~~~~~~~~~~~~~~~
+
+Besides specifying a range of commits that should be listed using the
+special notations explained in the description, additional commit
+limiting may be applied.
+
+Using more options generally further limits the output (e.g.
+`--since=<date1>` limits to commits newer than `<date1>`, and using it
+with `--grep=<pattern>` further limits to commits whose log message
+has a line that matches `<pattern>`), unless otherwise noted.
+
+Note that these are applied before commit
+ordering and formatting options, such as `--reverse`.
+
+-<number>::
+-n <number>::
+--max-count=<number>::
+ Limit the number of commits to output.
+
+--skip=<number>::
+ Skip 'number' commits before starting to show the commit output.
+
+--since=<date>::
+--after=<date>::
+ Show commits more recent than a specific date.
+
+--since-as-filter=<date>::
+ Show all commits more recent than a specific date. This visits
+ all commits in the range, rather than stopping at the first commit which
+ is older than a specific date.
+
+--until=<date>::
+--before=<date>::
+ Show commits older than a specific date.
+
+ifdef::git-rev-list[]
+--max-age=<timestamp>::
+--min-age=<timestamp>::
+ Limit the commits output to specified time range.
+endif::git-rev-list[]
+
+--author=<pattern>::
+--committer=<pattern>::
+ Limit the commits output to ones with author/committer
+ header lines that match the specified pattern (regular
+ expression). With more than one `--author=<pattern>`,
+ commits whose author matches any of the given patterns are
+ chosen (similarly for multiple `--committer=<pattern>`).
+
+--grep-reflog=<pattern>::
+ Limit the commits output to ones with reflog entries that
+ match the specified pattern (regular expression). With
+ more than one `--grep-reflog`, commits whose reflog message
+ matches any of the given patterns are chosen. It is an
+ error to use this option unless `--walk-reflogs` is in use.
+
+--grep=<pattern>::
+ Limit the commits output to ones with a log message that
+ matches the specified pattern (regular expression). With
+ more than one `--grep=<pattern>`, commits whose message
+ matches any of the given patterns are chosen (but see
+ `--all-match`).
+ifndef::git-rev-list[]
++
+When `--notes` is in effect, the message from the notes is
+matched as if it were part of the log message.
+endif::git-rev-list[]
+
+--all-match::
+ Limit the commits output to ones that match all given `--grep`,
+ instead of ones that match at least one.
+
+--invert-grep::
+ Limit the commits output to ones with a log message that do not
+ match the pattern specified with `--grep=<pattern>`.
+
+-i::
+--regexp-ignore-case::
+ Match the regular expression limiting patterns without regard to letter
+ case.
+
+--basic-regexp::
+ Consider the limiting patterns to be basic regular expressions;
+ this is the default.
+
+-E::
+--extended-regexp::
+ Consider the limiting patterns to be extended regular expressions
+ instead of the default basic regular expressions.
+
+-F::
+--fixed-strings::
+ Consider the limiting patterns to be fixed strings (don't interpret
+ pattern as a regular expression).
+
+-P::
+--perl-regexp::
+ Consider the limiting patterns to be Perl-compatible regular
+ expressions.
++
+Support for these types of regular expressions is an optional
+compile-time dependency. If Git wasn't compiled with support for them
+providing this option will cause it to die.
+
+--remove-empty::
+ Stop when a given path disappears from the tree.
+
+--merges::
+ Print only merge commits. This is exactly the same as `--min-parents=2`.
+
+--no-merges::
+ Do not print commits with more than one parent. This is
+ exactly the same as `--max-parents=1`.
+
+--min-parents=<number>::
+--max-parents=<number>::
+--no-min-parents::
+--no-max-parents::
+ Show only commits which have at least (or at most) that many parent
+ commits. In particular, `--max-parents=1` is the same as `--no-merges`,
+ `--min-parents=2` is the same as `--merges`. `--max-parents=0`
+ gives all root commits and `--min-parents=3` all octopus merges.
++
+`--no-min-parents` and `--no-max-parents` reset these limits (to no limit)
+again. Equivalent forms are `--min-parents=0` (any commit has 0 or more
+parents) and `--max-parents=-1` (negative numbers denote no upper limit).
+
+--first-parent::
+ When finding commits to include, follow only the first
+ parent commit upon seeing a merge commit. This option
+ can give a better overview when viewing the evolution of
+ a particular topic branch, because merges into a topic
+ branch tend to be only about adjusting to updated upstream
+ from time to time, and this option allows you to ignore
+ the individual commits brought in to your history by such
+ a merge.
+ifdef::git-log[]
++
+This option also changes default diff format for merge commits
+to `first-parent`, see `--diff-merges=first-parent` for details.
+endif::git-log[]
+
+--exclude-first-parent-only::
+ When finding commits to exclude (with a '{caret}'), follow only
+ the first parent commit upon seeing a merge commit.
+ This can be used to find the set of changes in a topic branch
+ from the point where it diverged from the remote branch, given
+ that arbitrary merges can be valid topic branch changes.
+
+--not::
+ Reverses the meaning of the '{caret}' prefix (or lack thereof)
+ for all following revision specifiers, up to the next `--not`.
+ When used on the command line before --stdin, the revisions passed
+ through stdin will not be affected by it. Conversely, when passed
+ via standard input, the revisions passed on the command line will
+ not be affected by it.
+
+--all::
+ Pretend as if all the refs in `refs/`, along with `HEAD`, are
+ listed on the command line as '<commit>'.
+
+--branches[=<pattern>]::
+ Pretend as if all the refs in `refs/heads` are listed
+ on the command line as '<commit>'. If '<pattern>' is given, limit
+ branches to ones matching given shell glob. If pattern lacks '?',
+ '{asterisk}', or '[', '/{asterisk}' at the end is implied.
+
+--tags[=<pattern>]::
+ Pretend as if all the refs in `refs/tags` are listed
+ on the command line as '<commit>'. If '<pattern>' is given, limit
+ tags to ones matching given shell glob. If pattern lacks '?', '{asterisk}',
+ or '[', '/{asterisk}' at the end is implied.
+
+--remotes[=<pattern>]::
+ Pretend as if all the refs in `refs/remotes` are listed
+ on the command line as '<commit>'. If '<pattern>' is given, limit
+ remote-tracking branches to ones matching given shell glob.
+ If pattern lacks '?', '{asterisk}', or '[', '/{asterisk}' at the end is implied.
+
+--glob=<glob-pattern>::
+ Pretend as if all the refs matching shell glob '<glob-pattern>'
+ are listed on the command line as '<commit>'. Leading 'refs/',
+ is automatically prepended if missing. If pattern lacks '?', '{asterisk}',
+ or '[', '/{asterisk}' at the end is implied.
+
+--exclude=<glob-pattern>::
+
+ Do not include refs matching '<glob-pattern>' that the next `--all`,
+ `--branches`, `--tags`, `--remotes`, or `--glob` would otherwise
+ consider. Repetitions of this option accumulate exclusion patterns
+ up to the next `--all`, `--branches`, `--tags`, `--remotes`, or
+ `--glob` option (other options or arguments do not clear
+ accumulated patterns).
++
+The patterns given should not begin with `refs/heads`, `refs/tags`, or
+`refs/remotes` when applied to `--branches`, `--tags`, or `--remotes`,
+respectively, and they must begin with `refs/` when applied to `--glob`
+or `--all`. If a trailing '/{asterisk}' is intended, it must be given
+explicitly.
+
+--exclude-hidden=[fetch|receive|uploadpack]::
+ Do not include refs that would be hidden by `git-fetch`,
+ `git-receive-pack` or `git-upload-pack` by consulting the appropriate
+ `fetch.hideRefs`, `receive.hideRefs` or `uploadpack.hideRefs`
+ configuration along with `transfer.hideRefs` (see
+ linkgit:git-config[1]). This option affects the next pseudo-ref option
+ `--all` or `--glob` and is cleared after processing them.
+
+--reflog::
+ Pretend as if all objects mentioned by reflogs are listed on the
+ command line as `<commit>`.
+
+--alternate-refs::
+ Pretend as if all objects mentioned as ref tips of alternate
+ repositories were listed on the command line. An alternate
+ repository is any repository whose object directory is specified
+ in `objects/info/alternates`. The set of included objects may
+ be modified by `core.alternateRefsCommand`, etc. See
+ linkgit:git-config[1].
+
+--single-worktree::
+ By default, all working trees will be examined by the
+ following options when there are more than one (see
+ linkgit:git-worktree[1]): `--all`, `--reflog` and
+ `--indexed-objects`.
+ This option forces them to examine the current working tree
+ only.
+
+--ignore-missing::
+ Upon seeing an invalid object name in the input, pretend as if
+ the bad input was not given.
+
+ifndef::git-rev-list[]
+--bisect::
+ Pretend as if the bad bisection ref `refs/bisect/bad`
+ was listed and as if it was followed by `--not` and the good
+ bisection refs `refs/bisect/good-*` on the command
+ line.
+endif::git-rev-list[]
+
+--stdin::
+ In addition to getting arguments from the command line, read
+ them from standard input as well. This accepts commits and
+ pseudo-options like `--all` and `--glob=`. When a `--` separator
+ is seen, the following input is treated as paths and used to
+ limit the result. Flags like `--not` which are read via standard input
+ are only respected for arguments passed in the same way and will not
+ influence any subsequent command line arguments.
+
+ifdef::git-rev-list[]
+--quiet::
+ Don't print anything to standard output. This form
+ is primarily meant to allow the caller to
+ test the exit status to see if a range of objects is fully
+ connected (or not). It is faster than redirecting stdout
+ to `/dev/null` as the output does not have to be formatted.
+
+--disk-usage::
+--disk-usage=human::
+ Suppress normal output; instead, print the sum of the bytes used
+ for on-disk storage by the selected commits or objects. This is
+ equivalent to piping the output into `git cat-file
+ --batch-check='%(objectsize:disk)'`, except that it runs much
+ faster (especially with `--use-bitmap-index`). See the `CAVEATS`
+ section in linkgit:git-cat-file[1] for the limitations of what
+ "on-disk storage" means.
+ With the optional value `human`, on-disk storage size is shown
+ in human-readable string(e.g. 12.24 Kib, 3.50 Mib).
+endif::git-rev-list[]
+
+--cherry-mark::
+ Like `--cherry-pick` (see below) but mark equivalent commits
+ with `=` rather than omitting them, and inequivalent ones with `+`.
+
+--cherry-pick::
+ Omit any commit that introduces the same change as
+ another commit on the ``other side'' when the set of
+ commits are limited with symmetric difference.
++
+For example, if you have two branches, `A` and `B`, a usual way
+to list all commits on only one side of them is with
+`--left-right` (see the example below in the description of
+the `--left-right` option). However, it shows the commits that were
+cherry-picked from the other branch (for example, ``3rd on b'' may be
+cherry-picked from branch A). With this option, such pairs of commits are
+excluded from the output.
+
+--left-only::
+--right-only::
+ List only commits on the respective side of a symmetric difference,
+ i.e. only those which would be marked `<` resp. `>` by
+ `--left-right`.
++
+For example, `--cherry-pick --right-only A...B` omits those
+commits from `B` which are in `A` or are patch-equivalent to a commit in
+`A`. In other words, this lists the `+` commits from `git cherry A B`.
+More precisely, `--cherry-pick --right-only --no-merges` gives the exact
+list.
+
+--cherry::
+ A synonym for `--right-only --cherry-mark --no-merges`; useful to
+ limit the output to the commits on our side and mark those that
+ have been applied to the other side of a forked history with
+ `git log --cherry upstream...mybranch`, similar to
+ `git cherry upstream mybranch`.
+
+-g::
+--walk-reflogs::
+ Instead of walking the commit ancestry chain, walk
+ reflog entries from the most recent one to older ones.
+ When this option is used you cannot specify commits to
+ exclude (that is, '{caret}commit', 'commit1..commit2',
+ and 'commit1\...commit2' notations cannot be used).
++
+With `--pretty` format other than `oneline` and `reference` (for obvious reasons),
+this causes the output to have two extra lines of information
+taken from the reflog. The reflog designator in the output may be shown
+as `ref@{<Nth>}` (where _<Nth>_ is the reverse-chronological index in the
+reflog) or as `ref@{<timestamp>}` (with the _<timestamp>_ for that entry),
+depending on a few rules:
++
+--
+1. If the starting point is specified as `ref@{<Nth>}`, show the index
+ format.
++
+2. If the starting point was specified as `ref@{now}`, show the
+ timestamp format.
++
+3. If neither was used, but `--date` was given on the command line, show
+ the timestamp in the format requested by `--date`.
++
+4. Otherwise, show the index format.
+--
++
+Under `--pretty=oneline`, the commit message is
+prefixed with this information on the same line.
+This option cannot be combined with `--reverse`.
+See also linkgit:git-reflog[1].
++
+Under `--pretty=reference`, this information will not be shown at all.
+
+--merge::
+ Show commits touching conflicted paths in the range `HEAD...<other>`,
+ where `<other>` is the first existing pseudoref in `MERGE_HEAD`,
+ `CHERRY_PICK_HEAD`, `REVERT_HEAD` or `REBASE_HEAD`. Only works
+ when the index has unmerged entries. This option can be used to show
+ relevant commits when resolving conflicts from a 3-way merge.
+
+--boundary::
+ Output excluded boundary commits. Boundary commits are
+ prefixed with `-`.
+
+ifdef::git-rev-list[]
+--use-bitmap-index::
+
+ Try to speed up the traversal using the pack bitmap index (if
+ one is available). Note that when traversing with `--objects`,
+ trees and blobs will not have their associated path printed.
+
+--progress=<header>::
+ Show progress reports on stderr as objects are considered. The
+ `<header>` text will be printed with each progress update.
+endif::git-rev-list[]
+
+History Simplification
+~~~~~~~~~~~~~~~~~~~~~~
+
+Sometimes you are only interested in parts of the history, for example the
+commits modifying a particular <path>. But there are two parts of
+'History Simplification', one part is selecting the commits and the other
+is how to do it, as there are various strategies to simplify the history.
+
+The following options select the commits to be shown:
+
+<paths>::
+ Commits modifying the given <paths> are selected.
+
+--simplify-by-decoration::
+ Commits that are referred by some branch or tag are selected.
+
+Note that extra commits can be shown to give a meaningful history.
+
+The following options affect the way the simplification is performed:
+
+Default mode::
+ Simplifies the history to the simplest history explaining the
+ final state of the tree. Simplest because it prunes some side
+ branches if the end result is the same (i.e. merging branches
+ with the same content)
+
+--show-pulls::
+ Include all commits from the default mode, but also any merge
+ commits that are not TREESAME to the first parent but are
+ TREESAME to a later parent. This mode is helpful for showing
+ the merge commits that "first introduced" a change to a branch.
+
+--full-history::
+ Same as the default mode, but does not prune some history.
+
+--dense::
+ Only the selected commits are shown, plus some to have a
+ meaningful history.
+
+--sparse::
+ All commits in the simplified history are shown.
+
+--simplify-merges::
+ Additional option to `--full-history` to remove some needless
+ merges from the resulting history, as there are no selected
+ commits contributing to this merge.
+
+--ancestry-path[=<commit>]::
+ When given a range of commits to display (e.g. 'commit1..commit2'
+ or 'commit2 {caret}commit1'), and a commit <commit> in that range,
+ only display commits in that range
+ that are ancestors of <commit>, descendants of <commit>, or
+ <commit> itself. If no commit is specified, use 'commit1' (the
+ excluded part of the range) as <commit>. Can be passed multiple
+ times; if so, a commit is included if it is any of the commits
+ given or if it is an ancestor or descendant of one of them.
+
+A more detailed explanation follows.
+
+Suppose you specified `foo` as the <paths>. We shall call commits
+that modify `foo` !TREESAME, and the rest TREESAME. (In a diff
+filtered for `foo`, they look different and equal, respectively.)
+
+In the following, we will always refer to the same example history to
+illustrate the differences between simplification settings. We assume
+that you are filtering for a file `foo` in this commit graph:
+-----------------------------------------------------------------------
+ .-A---M---N---O---P---Q
+ / / / / / /
+ I B C D E Y
+ \ / / / / /
+ `-------------' X
+-----------------------------------------------------------------------
+The horizontal line of history A---Q is taken to be the first parent of
+each merge. The commits are:
+
+* `I` is the initial commit, in which `foo` exists with contents
+ ``asdf'', and a file `quux` exists with contents ``quux''. Initial
+ commits are compared to an empty tree, so `I` is !TREESAME.
+
+* In `A`, `foo` contains just ``foo''.
+
+* `B` contains the same change as `A`. Its merge `M` is trivial and
+ hence TREESAME to all parents.
+
+* `C` does not change `foo`, but its merge `N` changes it to ``foobar'',
+ so it is not TREESAME to any parent.
+
+* `D` sets `foo` to ``baz''. Its merge `O` combines the strings from
+ `N` and `D` to ``foobarbaz''; i.e., it is not TREESAME to any parent.
+
+* `E` changes `quux` to ``xyzzy'', and its merge `P` combines the
+ strings to ``quux xyzzy''. `P` is TREESAME to `O`, but not to `E`.
+
+* `X` is an independent root commit that added a new file `side`, and `Y`
+ modified it. `Y` is TREESAME to `X`. Its merge `Q` added `side` to `P`, and
+ `Q` is TREESAME to `P`, but not to `Y`.
+
+`rev-list` walks backwards through history, including or excluding
+commits based on whether `--full-history` and/or parent rewriting
+(via `--parents` or `--children`) are used. The following settings
+are available.
+
+Default mode::
+ Commits are included if they are not TREESAME to any parent
+ (though this can be changed, see `--sparse` below). If the
+ commit was a merge, and it was TREESAME to one parent, follow
+ only that parent. (Even if there are several TREESAME
+ parents, follow only one of them.) Otherwise, follow all
+ parents.
++
+This results in:
++
+-----------------------------------------------------------------------
+ .-A---N---O
+ / / /
+ I---------D
+-----------------------------------------------------------------------
++
+Note how the rule to only follow the TREESAME parent, if one is
+available, removed `B` from consideration entirely. `C` was
+considered via `N`, but is TREESAME. Root commits are compared to an
+empty tree, so `I` is !TREESAME.
++
+Parent/child relations are only visible with `--parents`, but that does
+not affect the commits selected in default mode, so we have shown the
+parent lines.
+
+--full-history without parent rewriting::
+ This mode differs from the default in one point: always follow
+ all parents of a merge, even if it is TREESAME to one of them.
+ Even if more than one side of the merge has commits that are
+ included, this does not imply that the merge itself is! In
+ the example, we get
++
+-----------------------------------------------------------------------
+ I A B N D O P Q
+-----------------------------------------------------------------------
++
+`M` was excluded because it is TREESAME to both parents. `E`,
+`C` and `B` were all walked, but only `B` was !TREESAME, so the others
+do not appear.
++
+Note that without parent rewriting, it is not really possible to talk
+about the parent/child relationships between the commits, so we show
+them disconnected.
+
+--full-history with parent rewriting::
+ Ordinary commits are only included if they are !TREESAME
+ (though this can be changed, see `--sparse` below).
++
+Merges are always included. However, their parent list is rewritten:
+Along each parent, prune away commits that are not included
+themselves. This results in
++
+-----------------------------------------------------------------------
+ .-A---M---N---O---P---Q
+ / / / / /
+ I B / D /
+ \ / / / /
+ `-------------'
+-----------------------------------------------------------------------
++
+Compare to `--full-history` without rewriting above. Note that `E`
+was pruned away because it is TREESAME, but the parent list of P was
+rewritten to contain `E`'s parent `I`. The same happened for `C` and
+`N`, and `X`, `Y` and `Q`.
+
+In addition to the above settings, you can change whether TREESAME
+affects inclusion:
+
+--dense::
+ Commits that are walked are included if they are not TREESAME
+ to any parent.
+
+--sparse::
+ All commits that are walked are included.
++
+Note that without `--full-history`, this still simplifies merges: if
+one of the parents is TREESAME, we follow only that one, so the other
+sides of the merge are never walked.
+
+--simplify-merges::
+ First, build a history graph in the same way that
+ `--full-history` with parent rewriting does (see above).
++
+Then simplify each commit `C` to its replacement `C'` in the final
+history according to the following rules:
++
+--
+* Set `C'` to `C`.
++
+* Replace each parent `P` of `C'` with its simplification `P'`. In
+ the process, drop parents that are ancestors of other parents or that are
+ root commits TREESAME to an empty tree, and remove duplicates, but take care
+ to never drop all parents that we are TREESAME to.
++
+* If after this parent rewriting, `C'` is a root or merge commit (has
+ zero or >1 parents), a boundary commit, or !TREESAME, it remains.
+ Otherwise, it is replaced with its only parent.
+--
++
+The effect of this is best shown by way of comparing to
+`--full-history` with parent rewriting. The example turns into:
++
+-----------------------------------------------------------------------
+ .-A---M---N---O
+ / / /
+ I B D
+ \ / /
+ `---------'
+-----------------------------------------------------------------------
++
+Note the major differences in `N`, `P`, and `Q` over `--full-history`:
++
+--
+* `N`'s parent list had `I` removed, because it is an ancestor of the
+ other parent `M`. Still, `N` remained because it is !TREESAME.
++
+* `P`'s parent list similarly had `I` removed. `P` was then
+ removed completely, because it had one parent and is TREESAME.
++
+* `Q`'s parent list had `Y` simplified to `X`. `X` was then removed, because it
+ was a TREESAME root. `Q` was then removed completely, because it had one
+ parent and is TREESAME.
+--
+
+There is another simplification mode available:
+
+--ancestry-path[=<commit>]::
+ Limit the displayed commits to those which are an ancestor of
+ <commit>, or which are a descendant of <commit>, or are <commit>
+ itself.
++
+As an example use case, consider the following commit history:
++
+-----------------------------------------------------------------------
+ D---E-------F
+ / \ \
+ B---C---G---H---I---J
+ / \
+ A-------K---------------L--M
+-----------------------------------------------------------------------
++
+A regular 'D..M' computes the set of commits that are ancestors of `M`,
+but excludes the ones that are ancestors of `D`. This is useful to see
+what happened to the history leading to `M` since `D`, in the sense
+that ``what does `M` have that did not exist in `D`''. The result in this
+example would be all the commits, except `A` and `B` (and `D` itself,
+of course).
++
+When we want to find out what commits in `M` are contaminated with the
+bug introduced by `D` and need fixing, however, we might want to view
+only the subset of 'D..M' that are actually descendants of `D`, i.e.
+excluding `C` and `K`. This is exactly what the `--ancestry-path`
+option does. Applied to the 'D..M' range, it results in:
++
+-----------------------------------------------------------------------
+ E-------F
+ \ \
+ G---H---I---J
+ \
+ L--M
+-----------------------------------------------------------------------
++
+We can also use `--ancestry-path=D` instead of `--ancestry-path` which
+means the same thing when applied to the 'D..M' range but is just more
+explicit.
++
+If we instead are interested in a given topic within this range, and all
+commits affected by that topic, we may only want to view the subset of
+`D..M` which contain that topic in their ancestry path. So, using
+`--ancestry-path=H D..M` for example would result in:
++
+-----------------------------------------------------------------------
+ E
+ \
+ G---H---I---J
+ \
+ L--M
+-----------------------------------------------------------------------
++
+Whereas `--ancestry-path=K D..M` would result in
++
+-----------------------------------------------------------------------
+ K---------------L--M
+-----------------------------------------------------------------------
+
+Before discussing another option, `--show-pulls`, we need to
+create a new example history.
+
+A common problem users face when looking at simplified history is that a
+commit they know changed a file somehow does not appear in the file's
+simplified history. Let's demonstrate a new example and show how options
+such as `--full-history` and `--simplify-merges` works in that case:
+
+-----------------------------------------------------------------------
+ .-A---M-----C--N---O---P
+ / / \ \ \/ / /
+ I B \ R-'`-Z' /
+ \ / \/ /
+ \ / /\ /
+ `---X--' `---Y--'
+-----------------------------------------------------------------------
+
+For this example, suppose `I` created `file.txt` which was modified by
+`A`, `B`, and `X` in different ways. The single-parent commits `C`, `Z`,
+and `Y` do not change `file.txt`. The merge commit `M` was created by
+resolving the merge conflict to include both changes from `A` and `B`
+and hence is not TREESAME to either. The merge commit `R`, however, was
+created by ignoring the contents of `file.txt` at `M` and taking only
+the contents of `file.txt` at `X`. Hence, `R` is TREESAME to `X` but not
+`M`. Finally, the natural merge resolution to create `N` is to take the
+contents of `file.txt` at `R`, so `N` is TREESAME to `R` but not `C`.
+The merge commits `O` and `P` are TREESAME to their first parents, but
+not to their second parents, `Z` and `Y` respectively.
+
+When using the default mode, `N` and `R` both have a TREESAME parent, so
+those edges are walked and the others are ignored. The resulting history
+graph is:
+
+-----------------------------------------------------------------------
+ I---X
+-----------------------------------------------------------------------
+
+When using `--full-history`, Git walks every edge. This will discover
+the commits `A` and `B` and the merge `M`, but also will reveal the
+merge commits `O` and `P`. With parent rewriting, the resulting graph is:
+
+-----------------------------------------------------------------------
+ .-A---M--------N---O---P
+ / / \ \ \/ / /
+ I B \ R-'`--' /
+ \ / \/ /
+ \ / /\ /
+ `---X--' `------'
+-----------------------------------------------------------------------
+
+Here, the merge commits `O` and `P` contribute extra noise, as they did
+not actually contribute a change to `file.txt`. They only merged a topic
+that was based on an older version of `file.txt`. This is a common
+issue in repositories using a workflow where many contributors work in
+parallel and merge their topic branches along a single trunk: many
+unrelated merges appear in the `--full-history` results.
+
+When using the `--simplify-merges` option, the commits `O` and `P`
+disappear from the results. This is because the rewritten second parents
+of `O` and `P` are reachable from their first parents. Those edges are
+removed and then the commits look like single-parent commits that are
+TREESAME to their parent. This also happens to the commit `N`, resulting
+in a history view as follows:
+
+-----------------------------------------------------------------------
+ .-A---M--.
+ / / \
+ I B R
+ \ / /
+ \ / /
+ `---X--'
+-----------------------------------------------------------------------
+
+In this view, we see all of the important single-parent changes from
+`A`, `B`, and `X`. We also see the carefully-resolved merge `M` and the
+not-so-carefully-resolved merge `R`. This is usually enough information
+to determine why the commits `A` and `B` "disappeared" from history in
+the default view. However, there are a few issues with this approach.
+
+The first issue is performance. Unlike any previous option, the
+`--simplify-merges` option requires walking the entire commit history
+before returning a single result. This can make the option difficult to
+use for very large repositories.
+
+The second issue is one of auditing. When many contributors are working
+on the same repository, it is important which merge commits introduced
+a change into an important branch. The problematic merge `R` above is
+not likely to be the merge commit that was used to merge into an
+important branch. Instead, the merge `N` was used to merge `R` and `X`
+into the important branch. This commit may have information about why
+the change `X` came to override the changes from `A` and `B` in its
+commit message.
+
+--show-pulls::
+ In addition to the commits shown in the default history, show
+ each merge commit that is not TREESAME to its first parent but
+ is TREESAME to a later parent.
++
+When a merge commit is included by `--show-pulls`, the merge is
+treated as if it "pulled" the change from another branch. When using
+`--show-pulls` on this example (and no other options) the resulting
+graph is:
++
+-----------------------------------------------------------------------
+ I---X---R---N
+-----------------------------------------------------------------------
++
+Here, the merge commits `R` and `N` are included because they pulled
+the commits `X` and `R` into the base branch, respectively. These
+merges are the reason the commits `A` and `B` do not appear in the
+default history.
++
+When `--show-pulls` is paired with `--simplify-merges`, the
+graph includes all of the necessary information:
++
+-----------------------------------------------------------------------
+ .-A---M--. N
+ / / \ /
+ I B R
+ \ / /
+ \ / /
+ `---X--'
+-----------------------------------------------------------------------
++
+Notice that since `M` is reachable from `R`, the edge from `N` to `M`
+was simplified away. However, `N` still appears in the history as an
+important commit because it "pulled" the change `R` into the main
+branch.
+
+The `--simplify-by-decoration` option allows you to view only the
+big picture of the topology of the history, by omitting commits
+that are not referenced by tags. Commits are marked as !TREESAME
+(in other words, kept after history simplification rules described
+above) if (1) they are referenced by tags, or (2) they change the
+contents of the paths given on the command line. All other
+commits are marked as TREESAME (subject to be simplified away).
+
+ifndef::git-shortlog[]
+ifdef::git-rev-list[]
+Bisection Helpers
+~~~~~~~~~~~~~~~~~
+
+--bisect::
+ Limit output to the one commit object which is roughly halfway between
+ included and excluded commits. Note that the bad bisection ref
+ `refs/bisect/bad` is added to the included commits (if it
+ exists) and the good bisection refs `refs/bisect/good-*` are
+ added to the excluded commits (if they exist). Thus, supposing there
+ are no refs in `refs/bisect/`, if
++
+-----------------------------------------------------------------------
+ $ git rev-list --bisect foo ^bar ^baz
+-----------------------------------------------------------------------
++
+outputs 'midpoint', the output of the two commands
++
+-----------------------------------------------------------------------
+ $ git rev-list foo ^midpoint
+ $ git rev-list midpoint ^bar ^baz
+-----------------------------------------------------------------------
++
+would be of roughly the same length. Finding the change which
+introduces a regression is thus reduced to a binary search: repeatedly
+generate and test new 'midpoint's until the commit chain is of length
+one.
+
+--bisect-vars::
+ This calculates the same as `--bisect`, except that refs in
+ `refs/bisect/` are not used, and except that this outputs
+ text ready to be eval'ed by the shell. These lines will assign the
+ name of the midpoint revision to the variable `bisect_rev`, and the
+ expected number of commits to be tested after `bisect_rev` is tested
+ to `bisect_nr`, the expected number of commits to be tested if
+ `bisect_rev` turns out to be good to `bisect_good`, the expected
+ number of commits to be tested if `bisect_rev` turns out to be bad to
+ `bisect_bad`, and the number of commits we are bisecting right now to
+ `bisect_all`.
+
+--bisect-all::
+ This outputs all the commit objects between the included and excluded
+ commits, ordered by their distance to the included and excluded
+ commits. Refs in `refs/bisect/` are not used. The farthest
+ from them is displayed first. (This is the only one displayed by
+ `--bisect`.)
++
+This is useful because it makes it easy to choose a good commit to
+test when you want to avoid to test some of them for some reason (they
+may not compile for example).
++
+This option can be used along with `--bisect-vars`, in this case,
+after all the sorted commit objects, there will be the same text as if
+`--bisect-vars` had been used alone.
+endif::git-rev-list[]
+endif::git-shortlog[]
+
+ifndef::git-shortlog[]
+Commit Ordering
+~~~~~~~~~~~~~~~
+
+By default, the commits are shown in reverse chronological order.
+
+--date-order::
+ Show no parents before all of its children are shown, but
+ otherwise show commits in the commit timestamp order.
+
+--author-date-order::
+ Show no parents before all of its children are shown, but
+ otherwise show commits in the author timestamp order.
+
+--topo-order::
+ Show no parents before all of its children are shown, and
+ avoid showing commits on multiple lines of history
+ intermixed.
++
+For example, in a commit history like this:
++
+----------------------------------------------------------------
+
+ ---1----2----4----7
+ \ \
+ 3----5----6----8---
+
+----------------------------------------------------------------
++
+where the numbers denote the order of commit timestamps, `git
+rev-list` and friends with `--date-order` show the commits in the
+timestamp order: 8 7 6 5 4 3 2 1.
++
+With `--topo-order`, they would show 8 6 5 3 7 4 2 1 (or 8 7 4 2 6 5
+3 1); some older commits are shown before newer ones in order to
+avoid showing the commits from two parallel development track mixed
+together.
+
+--reverse::
+ Output the commits chosen to be shown (see Commit Limiting
+ section above) in reverse order. Cannot be combined with
+ `--walk-reflogs`.
+endif::git-shortlog[]
+
+ifndef::git-shortlog[]
+Object Traversal
+~~~~~~~~~~~~~~~~
+
+These options are mostly targeted for packing of Git repositories.
+
+ifdef::git-rev-list[]
+--objects::
+ Print the object IDs of any object referenced by the listed
+ commits. `--objects foo ^bar` thus means ``send me
+ all object IDs which I need to download if I have the commit
+ object _bar_ but not _foo_''. See also `--object-names` below.
+
+--in-commit-order::
+ Print tree and blob ids in order of the commits. The tree
+ and blob ids are printed after they are first referenced
+ by a commit.
+
+--objects-edge::
+ Similar to `--objects`, but also print the IDs of excluded
+ commits prefixed with a ``-'' character. This is used by
+ linkgit:git-pack-objects[1] to build a ``thin'' pack, which records
+ objects in deltified form based on objects contained in these
+ excluded commits to reduce network traffic.
+
+--objects-edge-aggressive::
+ Similar to `--objects-edge`, but it tries harder to find excluded
+ commits at the cost of increased time. This is used instead of
+ `--objects-edge` to build ``thin'' packs for shallow repositories.
+
+--indexed-objects::
+ Pretend as if all trees and blobs used by the index are listed
+ on the command line. Note that you probably want to use
+ `--objects`, too.
+
+--unpacked::
+ Only useful with `--objects`; print the object IDs that are not
+ in packs.
+
+--object-names::
+ Only useful with `--objects`; print the names of the object IDs
+ that are found. This is the default behavior. Note that the
+ "name" of each object is ambiguous, and mostly intended as a
+ hint for packing objects. In particular: no distinction is made between
+ the names of tags, trees, and blobs; path names may be modified
+ to remove newlines; and if an object would appear multiple times
+ with different names, only one name is shown.
+
+--no-object-names::
+ Only useful with `--objects`; does not print the names of the object
+ IDs that are found. This inverts `--object-names`. This flag allows
+ the output to be more easily parsed by commands such as
+ linkgit:git-cat-file[1].
+
+--filter=<filter-spec>::
+ Only useful with one of the `--objects*`; omits objects (usually
+ blobs) from the list of printed objects. The '<filter-spec>'
+ may be one of the following:
++
+The form '--filter=blob:none' omits all blobs.
++
+The form '--filter=blob:limit=<n>[kmg]' omits blobs of size at least n
+bytes or units. n may be zero. The suffixes k, m, and g can be used
+to name units in KiB, MiB, or GiB. For example, 'blob:limit=1k'
+is the same as 'blob:limit=1024'.
++
+The form '--filter=object:type=(tag|commit|tree|blob)' omits all objects
+which are not of the requested type.
++
+The form '--filter=sparse:oid=<blob-ish>' uses a sparse-checkout
+specification contained in the blob (or blob-expression) '<blob-ish>'
+to omit blobs that would not be required for a sparse checkout on
+the requested refs.
++
+The form '--filter=tree:<depth>' omits all blobs and trees whose depth
+from the root tree is >= <depth> (minimum depth if an object is located
+at multiple depths in the commits traversed). <depth>=0 will not include
+any trees or blobs unless included explicitly in the command-line (or
+standard input when --stdin is used). <depth>=1 will include only the
+tree and blobs which are referenced directly by a commit reachable from
+<commit> or an explicitly-given object. <depth>=2 is like <depth>=1
+while also including trees and blobs one more level removed from an
+explicitly-given commit or tree.
++
+Note that the form '--filter=sparse:path=<path>' that wants to read
+from an arbitrary path on the filesystem has been dropped for security
+reasons.
++
+Multiple '--filter=' flags can be specified to combine filters. Only
+objects which are accepted by every filter are included.
++
+The form '--filter=combine:<filter1>+<filter2>+...<filterN>' can also be
+used to combined several filters, but this is harder than just repeating
+the '--filter' flag and is usually not necessary. Filters are joined by
+'{plus}' and individual filters are %-encoded (i.e. URL-encoded).
+Besides the '{plus}' and '%' characters, the following characters are
+reserved and also must be encoded: `~!@#$^&*()[]{}\;",<>?`+'`+
+as well as all characters with ASCII code <= `0x20`, which includes
+space and newline.
++
+Other arbitrary characters can also be encoded. For instance,
+'combine:tree:3+blob:none' and 'combine:tree%3A3+blob%3Anone' are
+equivalent.
+
+--no-filter::
+ Turn off any previous `--filter=` argument.
+
+--filter-provided-objects::
+ Filter the list of explicitly provided objects, which would otherwise
+ always be printed even if they did not match any of the filters. Only
+ useful with `--filter=`.
+
+--filter-print-omitted::
+ Only useful with `--filter=`; prints a list of the objects omitted
+ by the filter. Object IDs are prefixed with a ``~'' character.
+
+--missing=<missing-action>::
+ A debug option to help with future "partial clone" development.
+ This option specifies how missing objects are handled.
++
+The form '--missing=error' requests that rev-list stop with an error if
+a missing object is encountered. This is the default action.
++
+The form '--missing=allow-any' will allow object traversal to continue
+if a missing object is encountered. Missing objects will silently be
+omitted from the results.
++
+The form '--missing=allow-promisor' is like 'allow-any', but will only
+allow object traversal to continue for EXPECTED promisor missing objects.
+Unexpected missing objects will raise an error.
++
+The form '--missing=print' is like 'allow-any', but will also print a
+list of the missing objects. Object IDs are prefixed with a ``?'' character.
++
+If some tips passed to the traversal are missing, they will be
+considered as missing too, and the traversal will ignore them. In case
+we cannot get their Object ID though, an error will be raised.
+
+--exclude-promisor-objects::
+ (For internal use only.) Prefilter object traversal at
+ promisor boundary. This is used with partial clone. This is
+ stronger than `--missing=allow-promisor` because it limits the
+ traversal, rather than just silencing errors about missing
+ objects.
+endif::git-rev-list[]
+
+--no-walk[=(sorted|unsorted)]::
+ Only show the given commits, but do not traverse their ancestors.
+ This has no effect if a range is specified. If the argument
+ `unsorted` is given, the commits are shown in the order they were
+ given on the command line. Otherwise (if `sorted` or no argument
+ was given), the commits are shown in reverse chronological order
+ by commit time.
+ Cannot be combined with `--graph`.
+
+--do-walk::
+ Overrides a previous `--no-walk`.
+endif::git-shortlog[]
+
+ifndef::git-shortlog[]
+Commit Formatting
+~~~~~~~~~~~~~~~~~
+
+ifdef::git-rev-list[]
+Using these options, linkgit:git-rev-list[1] will act similar to the
+more specialized family of commit log tools: linkgit:git-log[1],
+linkgit:git-show[1], and linkgit:git-whatchanged[1]
+endif::git-rev-list[]
+
+include::pretty-options.adoc[]
+
+--relative-date::
+ Synonym for `--date=relative`.
+
+--date=<format>::
+ Only takes effect for dates shown in human-readable format, such
+ as when using `--pretty`. `log.date` config variable sets a default
+ value for the log command's `--date` option. By default, dates
+ are shown in the original time zone (either committer's or
+ author's). If `-local` is appended to the format (e.g.,
+ `iso-local`), the user's local time zone is used instead.
++
+--
+`--date=relative` shows dates relative to the current time,
+e.g. ``2 hours ago''. The `-local` option has no effect for
+`--date=relative`.
+
+`--date=local` is an alias for `--date=default-local`.
+
+`--date=iso` (or `--date=iso8601`) shows timestamps in a ISO 8601-like format.
+The differences to the strict ISO 8601 format are:
+
+ - a space instead of the `T` date/time delimiter
+ - a space between time and time zone
+ - no colon between hours and minutes of the time zone
+
+`--date=iso-strict` (or `--date=iso8601-strict`) shows timestamps in strict
+ISO 8601 format.
+
+`--date=rfc` (or `--date=rfc2822`) shows timestamps in RFC 2822
+format, often found in email messages.
+
+`--date=short` shows only the date, but not the time, in `YYYY-MM-DD` format.
+
+`--date=raw` shows the date as seconds since the epoch (1970-01-01
+00:00:00 UTC), followed by a space, and then the timezone as an offset
+from UTC (a `+` or `-` with four digits; the first two are hours, and
+the second two are minutes). I.e., as if the timestamp were formatted
+with `strftime("%s %z")`).
+Note that the `-local` option does not affect the seconds-since-epoch
+value (which is always measured in UTC), but does switch the accompanying
+timezone value.
+
+`--date=human` shows the timezone if the timezone does not match the
+current time-zone, and doesn't print the whole date if that matches
+(ie skip printing year for dates that are "this year", but also skip
+the whole date itself if it's in the last few days and we can just say
+what weekday it was). For older dates the hour and minute is also
+omitted.
+
+`--date=unix` shows the date as a Unix epoch timestamp (seconds since
+1970). As with `--raw`, this is always in UTC and therefore `-local`
+has no effect.
+
+`--date=format:...` feeds the format `...` to your system `strftime`,
+except for %s, %z, and %Z, which are handled internally.
+Use `--date=format:%c` to show the date in your system locale's
+preferred format. See the `strftime` manual for a complete list of
+format placeholders. When using `-local`, the correct syntax is
+`--date=format-local:...`.
+
+`--date=default` is the default format, and is based on ctime(3)
+output. It shows a single line with three-letter day of the week,
+three-letter month, day-of-month, hour-minute-seconds in "HH:MM:SS"
+format, followed by 4-digit year, plus timezone information, unless
+the local time zone is used, e.g. `Thu Jan 1 00:00:00 1970 +0000`.
+--
+
+ifdef::git-rev-list[]
+--header::
+ Print the contents of the commit in raw-format; each record is
+ separated with a NUL character.
+
+--no-commit-header::
+ Suppress the header line containing "commit" and the object ID printed before
+ the specified format. This has no effect on the built-in formats; only custom
+ formats are affected.
+
+--commit-header::
+ Overrides a previous `--no-commit-header`.
+endif::git-rev-list[]
+
+--parents::
+ Print also the parents of the commit (in the form "commit parent...").
+ Also enables parent rewriting, see 'History Simplification' above.
+
+--children::
+ Print also the children of the commit (in the form "commit child...").
+ Also enables parent rewriting, see 'History Simplification' above.
+
+ifdef::git-rev-list[]
+--timestamp::
+ Print the raw commit timestamp.
+endif::git-rev-list[]
+
+--left-right::
+ Mark which side of a symmetric difference a commit is reachable from.
+ Commits from the left side are prefixed with `<` and those from
+ the right with `>`. If combined with `--boundary`, those
+ commits are prefixed with `-`.
++
+For example, if you have this topology:
++
+-----------------------------------------------------------------------
+ y---b---b branch B
+ / \ /
+ / .
+ / / \
+ o---x---a---a branch A
+-----------------------------------------------------------------------
++
+you would get an output like this:
++
+-----------------------------------------------------------------------
+ $ git rev-list --left-right --boundary --pretty=oneline A...B
+
+ >bbbbbbb... 3rd on b
+ >bbbbbbb... 2nd on b
+ <aaaaaaa... 3rd on a
+ <aaaaaaa... 2nd on a
+ -yyyyyyy... 1st on b
+ -xxxxxxx... 1st on a
+-----------------------------------------------------------------------
+
+--graph::
+ Draw a text-based graphical representation of the commit history
+ on the left hand side of the output. This may cause extra lines
+ to be printed in between commits, in order for the graph history
+ to be drawn properly.
+ Cannot be combined with `--no-walk`.
++
+This enables parent rewriting, see 'History Simplification' above.
++
+This implies the `--topo-order` option by default, but the
+`--date-order` option may also be specified.
+
+--show-linear-break[=<barrier>]::
+ When --graph is not used, all history branches are flattened
+ which can make it hard to see that the two consecutive commits
+ do not belong to a linear branch. This option puts a barrier
+ in between them in that case. If `<barrier>` is specified, it
+ is the string that will be shown instead of the default one.
+
+ifdef::git-rev-list[]
+--count::
+ Print a number stating how many commits would have been
+ listed, and suppress all other output. When used together
+ with `--left-right`, instead print the counts for left and
+ right commits, separated by a tab. When used together with
+ `--cherry-mark`, omit patch equivalent commits from these
+ counts and print the count for equivalent commits separated
+ by a tab.
+endif::git-rev-list[]
+endif::git-shortlog[]
diff --git a/revisions.adoc b/revisions.adoc
new file mode 100644
index 0000000..6ea6c7c
--- /dev/null
+++ b/revisions.adoc
@@ -0,0 +1,421 @@
+SPECIFYING REVISIONS
+--------------------
+
+A revision parameter '<rev>' typically, but not necessarily, names a
+commit object. It uses what is called an 'extended SHA-1'
+syntax. Here are various ways to spell object names. The
+ones listed near the end of this list name trees and
+blobs contained in a commit.
+
+NOTE: This document shows the "raw" syntax as seen by git. The shell
+and other UIs might require additional quoting to protect special
+characters and to avoid word splitting.
+
+'<sha1>', e.g. 'dae86e1950b1277e545cee180551750029cfe735', 'dae86e'::
+ The full SHA-1 object name (40-byte hexadecimal string), or
+ a leading substring that is unique within the repository.
+ E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both
+ name the same commit object if there is no other object in
+ your repository whose object name starts with dae86e.
+
+'<describeOutput>', e.g. 'v1.7.4.2-679-g3bee7fb'::
+ Output from `git describe`; i.e. a closest tag, optionally
+ followed by a dash and a number of commits, followed by a dash, a
+ 'g', and an abbreviated object name.
+
+'<refname>', e.g. 'master', 'heads/master', 'refs/heads/master'::
+ A symbolic ref name. E.g. 'master' typically means the commit
+ object referenced by 'refs/heads/master'. If you
+ happen to have both 'heads/master' and 'tags/master', you can
+ explicitly say 'heads/master' to tell Git which one you mean.
+ When ambiguous, a '<refname>' is disambiguated by taking the
+ first match in the following rules:
++
+ . If '$GIT_DIR/<refname>' exists, that is what you mean (this is usually
+ useful only for `HEAD`, `FETCH_HEAD`, `ORIG_HEAD`, `MERGE_HEAD`,
+ `REBASE_HEAD`, `REVERT_HEAD`, `CHERRY_PICK_HEAD`, `BISECT_HEAD`
+ and `AUTO_MERGE`);
+
+ . otherwise, 'refs/<refname>' if it exists;
+
+ . otherwise, 'refs/tags/<refname>' if it exists;
+
+ . otherwise, 'refs/heads/<refname>' if it exists;
+
+ . otherwise, 'refs/remotes/<refname>' if it exists;
+
+ . otherwise, 'refs/remotes/<refname>/HEAD' if it exists.
+
++
+ `HEAD`:::
+ names the commit on which you based the changes in the working tree.
+ `FETCH_HEAD`:::
+ records the branch which you fetched from a remote repository with
+ your last `git fetch` invocation.
+ `ORIG_HEAD`:::
+ is created by commands that move your `HEAD` in a drastic way (`git
+ am`, `git merge`, `git rebase`, `git reset`), to record the position
+ of the `HEAD` before their operation, so that you can easily change
+ the tip of the branch back to the state before you ran them.
+ `MERGE_HEAD`:::
+ records the commit(s) which you are merging into your branch when you
+ run `git merge`.
+ `REBASE_HEAD`:::
+ during a rebase, records the commit at which the operation is
+ currently stopped, either because of conflicts or an `edit` command in
+ an interactive rebase.
+ `REVERT_HEAD`:::
+ records the commit which you are reverting when you run `git revert`.
+ `CHERRY_PICK_HEAD`:::
+ records the commit which you are cherry-picking when you run `git
+ cherry-pick`.
+ `BISECT_HEAD`:::
+ records the current commit to be tested when you run `git bisect
+ --no-checkout`.
+ `AUTO_MERGE`:::
+ records a tree object corresponding to the state the
+ 'ort' merge strategy wrote to the working tree when a merge operation
+ resulted in conflicts.
+
++
+Note that any of the 'refs/*' cases above may come either from
+the `$GIT_DIR/refs` directory or from the `$GIT_DIR/packed-refs` file.
+While the ref name encoding is unspecified, UTF-8 is preferred as
+some output processing may assume ref names in UTF-8.
+
+'@'::
+ '@' alone is a shortcut for `HEAD`.
+
+'[<refname>]@{<date>}', e.g. 'master@\{yesterday\}', 'HEAD@{5 minutes ago}'::
+ A ref followed by the suffix '@' with a date specification
+ enclosed in a brace
+ pair (e.g. '\{yesterday\}', '{1 month 2 weeks 3 days 1 hour 1
+ second ago}' or '{1979-02-26 18:30:00}') specifies the value
+ of the ref at a prior point in time. This suffix may only be
+ used immediately following a ref name and the ref must have an
+ existing log ('$GIT_DIR/logs/<ref>'). Note that this looks up the state
+ of your *local* ref at a given time; e.g., what was in your local
+ 'master' branch last week. If you want to look at commits made during
+ certain times, see `--since` and `--until`.
+
+'<refname>@{<n>}', e.g. 'master@\{1\}'::
+ A ref followed by the suffix '@' with an ordinal specification
+ enclosed in a brace pair (e.g. '\{1\}', '\{15\}') specifies
+ the n-th prior value of that ref. For example 'master@\{1\}'
+ is the immediate prior value of 'master' while 'master@\{5\}'
+ is the 5th prior value of 'master'. This suffix may only be used
+ immediately following a ref name and the ref must have an existing
+ log ('$GIT_DIR/logs/<refname>').
+
+'@{<n>}', e.g. '@\{1\}'::
+ You can use the '@' construct with an empty ref part to get at a
+ reflog entry of the current branch. For example, if you are on
+ branch 'blabla' then '@\{1\}' means the same as 'blabla@\{1\}'.
+
+'@{-<n>}', e.g. '@{-1}'::
+ The construct '@{-<n>}' means the <n>th branch/commit checked out
+ before the current one.
+
+'[<branchname>]@\{upstream\}', e.g. 'master@\{upstream\}', '@\{u\}'::
+ A branch B may be set up to build on top of a branch X (configured with
+ `branch.<name>.merge`) at a remote R (configured with
+ `branch.<name>.remote`). B@{u} refers to the remote-tracking branch for
+ the branch X taken from remote R, typically found at `refs/remotes/R/X`.
+
+'[<branchname>]@\{push\}', e.g. 'master@\{push\}', '@\{push\}'::
+ The suffix '@\{push}' reports the branch "where we would push to" if
+ `git push` were run while `branchname` was checked out (or the current
+ `HEAD` if no branchname is specified). Like for '@\{upstream\}', we report
+ the remote-tracking branch that corresponds to that branch at the remote.
++
+Here's an example to make it more clear:
++
+------------------------------
+$ git config push.default current
+$ git config remote.pushdefault myfork
+$ git switch -c mybranch origin/master
+
+$ git rev-parse --symbolic-full-name @{upstream}
+refs/remotes/origin/master
+
+$ git rev-parse --symbolic-full-name @{push}
+refs/remotes/myfork/mybranch
+------------------------------
++
+Note in the example that we set up a triangular workflow, where we pull
+from one location and push to another. In a non-triangular workflow,
+'@\{push}' is the same as '@\{upstream}', and there is no need for it.
++
+This suffix is also accepted when spelled in uppercase, and means the same
+thing no matter the case.
+
+'<rev>{caret}[<n>]', e.g. 'HEAD{caret}, v1.5.1{caret}0'::
+ A suffix '{caret}' to a revision parameter means the first parent of
+ that commit object. '{caret}<n>' means the <n>th parent (i.e.
+ '<rev>{caret}'
+ is equivalent to '<rev>{caret}1'). As a special rule,
+ '<rev>{caret}0' means the commit itself and is used when '<rev>' is the
+ object name of a tag object that refers to a commit object.
+
+'<rev>{tilde}[<n>]', e.g. 'HEAD{tilde}, master{tilde}3'::
+ A suffix '{tilde}' to a revision parameter means the first parent of
+ that commit object.
+ A suffix '{tilde}<n>' to a revision parameter means the commit
+ object that is the <n>th generation ancestor of the named
+ commit object, following only the first parents. I.e. '<rev>{tilde}3' is
+ equivalent to '<rev>{caret}{caret}{caret}' which is equivalent to
+ '<rev>{caret}1{caret}1{caret}1'. See below for an illustration of
+ the usage of this form.
+
+'<rev>{caret}{<type>}', e.g. 'v0.99.8{caret}\{commit\}'::
+ A suffix '{caret}' followed by an object type name enclosed in
+ brace pair means dereference the object at '<rev>' recursively until
+ an object of type '<type>' is found or the object cannot be
+ dereferenced anymore (in which case, barf).
+ For example, if '<rev>' is a commit-ish, '<rev>{caret}\{commit\}'
+ describes the corresponding commit object.
+ Similarly, if '<rev>' is a tree-ish, '<rev>{caret}\{tree\}'
+ describes the corresponding tree object.
+ '<rev>{caret}0'
+ is a short-hand for '<rev>{caret}\{commit\}'.
++
+'<rev>{caret}\{object\}' can be used to make sure '<rev>' names an
+object that exists, without requiring '<rev>' to be a tag, and
+without dereferencing '<rev>'; because a tag is already an object,
+it does not have to be dereferenced even once to get to an object.
++
+'<rev>{caret}\{tag\}' can be used to ensure that '<rev>' identifies an
+existing tag object.
+
+'<rev>{caret}{}', e.g. 'v0.99.8{caret}{}'::
+ A suffix '{caret}' followed by an empty brace pair
+ means the object could be a tag,
+ and dereference the tag recursively until a non-tag object is
+ found.
+
+'<rev>{caret}{/<text>}', e.g. 'HEAD^{/fix nasty bug}'::
+ A suffix '{caret}' to a revision parameter, followed by a brace
+ pair that contains a text led by a slash,
+ is the same as the ':/fix nasty bug' syntax below except that
+ it returns the youngest matching commit which is reachable from
+ the '<rev>' before '{caret}'.
+
+':/<text>', e.g. ':/fix nasty bug'::
+ A colon, followed by a slash, followed by a text, names
+ a commit whose commit message matches the specified regular expression.
+ This name returns the youngest matching commit which is
+ reachable from any ref, including HEAD.
+ The regular expression can match any part of the
+ commit message. To match messages starting with a string, one can use
+ e.g. ':/^foo'. The special sequence ':/!' is reserved for modifiers to what
+ is matched. ':/!-foo' performs a negative match, while ':/!!foo' matches a
+ literal '!' character, followed by 'foo'. Any other sequence beginning with
+ ':/!' is reserved for now.
+ Depending on the given text, the shell's word splitting rules might
+ require additional quoting.
+
+'<rev>:<path>', e.g. 'HEAD:README', 'master:./README'::
+ A suffix ':' followed by a path names the blob or tree
+ at the given path in the tree-ish object named by the part
+ before the colon.
+ A path starting with './' or '../' is relative to the current working directory.
+ The given path will be converted to be relative to the working tree's root directory.
+ This is most useful to address a blob or tree from a commit or tree that has
+ the same tree structure as the working tree.
+
+':[<n>:]<path>', e.g. ':0:README', ':README'::
+ A colon, optionally followed by a stage number (0 to 3) and a
+ colon, followed by a path, names a blob object in the
+ index at the given path. A missing stage number (and the colon
+ that follows it) names a stage 0 entry. During a merge, stage
+ 1 is the common ancestor, stage 2 is the target branch's version
+ (typically the current branch), and stage 3 is the version from
+ the branch which is being merged.
+
+Here is an illustration, by Jon Loeliger. Both commit nodes B
+and C are parents of commit node A. Parent commits are ordered
+left-to-right.
+
+........................................
+G H I J
+ \ / \ /
+ D E F
+ \ | / \
+ \ | / |
+ \|/ |
+ B C
+ \ /
+ \ /
+ A
+........................................
+
+ A = = A^0
+ B = A^ = A^1 = A~1
+ C = = A^2
+ D = A^^ = A^1^1 = A~2
+ E = B^2 = A^^2
+ F = B^3 = A^^3
+ G = A^^^ = A^1^1^1 = A~3
+ H = D^2 = B^^2 = A^^^2 = A~2^2
+ I = F^ = B^3^ = A^^3^
+ J = F^2 = B^3^2 = A^^3^2
+
+
+SPECIFYING RANGES
+-----------------
+
+History traversing commands such as `git log` operate on a set
+of commits, not just a single commit.
+
+For these commands,
+specifying a single revision, using the notation described in the
+previous section, means the set of commits `reachable` from the given
+commit.
+
+Specifying several revisions means the set of commits reachable from
+any of the given commits.
+
+A commit's reachable set is the commit itself and the commits in
+its ancestry chain.
+
+There are several notations to specify a set of connected commits
+(called a "revision range"), illustrated below.
+
+
+Commit Exclusions
+~~~~~~~~~~~~~~~~~
+
+'{caret}<rev>' (caret) Notation::
+ To exclude commits reachable from a commit, a prefix '{caret}'
+ notation is used. E.g. '{caret}r1 r2' means commits reachable
+ from 'r2' but exclude the ones reachable from 'r1' (i.e. 'r1' and
+ its ancestors).
+
+Dotted Range Notations
+~~~~~~~~~~~~~~~~~~~~~~
+
+The '..' (two-dot) Range Notation::
+ The '{caret}r1 r2' set operation appears so often that there is a shorthand
+ for it. When you have two commits 'r1' and 'r2' (named according
+ to the syntax explained in SPECIFYING REVISIONS above), you can ask
+ for commits that are reachable from r2 excluding those that are reachable
+ from r1 by '{caret}r1 r2' and it can be written as 'r1..r2'.
+
+The '\...' (three-dot) Symmetric Difference Notation::
+ A similar notation 'r1\...r2' is called symmetric difference
+ of 'r1' and 'r2' and is defined as
+ 'r1 r2 --not $(git merge-base --all r1 r2)'.
+ It is the set of commits that are reachable from either one of
+ 'r1' (left side) or 'r2' (right side) but not from both.
+
+In these two shorthand notations, you can omit one end and let it default to HEAD.
+For example, 'origin..' is a shorthand for 'origin..HEAD' and asks "What
+did I do since I forked from the origin branch?" Similarly, '..origin'
+is a shorthand for 'HEAD..origin' and asks "What did the origin do since
+I forked from them?" Note that '..' would mean 'HEAD..HEAD' which is an
+empty range that is both reachable and unreachable from HEAD.
+
+Commands that are specifically designed to take two distinct ranges
+(e.g. "git range-diff R1 R2" to compare two ranges) do exist, but
+they are exceptions. Unless otherwise noted, all "git" commands
+that operate on a set of commits work on a single revision range.
+In other words, writing two "two-dot range notation" next to each
+other, e.g.
+
+ $ git log A..B C..D
+
+does *not* specify two revision ranges for most commands. Instead
+it will name a single connected set of commits, i.e. those that are
+reachable from either B or D but are reachable from neither A or C.
+In a linear history like this:
+
+ ---A---B---o---o---C---D
+
+because A and B are reachable from C, the revision range specified
+by these two dotted ranges is a single commit D.
+
+
+Other <rev>{caret} Parent Shorthand Notations
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Three other shorthands exist, particularly useful for merge commits,
+for naming a set that is formed by a commit and its parent commits.
+
+The 'r1{caret}@' notation means all parents of 'r1'.
+
+The 'r1{caret}!' notation includes commit 'r1' but excludes all of its parents.
+By itself, this notation denotes the single commit 'r1'.
+
+The '<rev>{caret}-[<n>]' notation includes '<rev>' but excludes the <n>th
+parent (i.e. a shorthand for '<rev>{caret}<n>..<rev>'), with '<n>' = 1 if
+not given. This is typically useful for merge commits where you
+can just pass '<commit>{caret}-' to get all the commits in the branch
+that was merged in merge commit '<commit>' (including '<commit>'
+itself).
+
+While '<rev>{caret}<n>' was about specifying a single commit parent, these
+three notations also consider its parents. For example you can say
+'HEAD{caret}2{caret}@', however you cannot say 'HEAD{caret}@{caret}2'.
+
+Revision Range Summary
+----------------------
+
+'<rev>'::
+ Include commits that are reachable from <rev> (i.e. <rev> and its
+ ancestors).
+
+'{caret}<rev>'::
+ Exclude commits that are reachable from <rev> (i.e. <rev> and its
+ ancestors).
+
+'<rev1>..<rev2>'::
+ Include commits that are reachable from <rev2> but exclude
+ those that are reachable from <rev1>. When either <rev1> or
+ <rev2> is omitted, it defaults to `HEAD`.
+
+'<rev1>\...<rev2>'::
+ Include commits that are reachable from either <rev1> or
+ <rev2> but exclude those that are reachable from both. When
+ either <rev1> or <rev2> is omitted, it defaults to `HEAD`.
+
+'<rev>{caret}@', e.g. 'HEAD{caret}@'::
+ A suffix '{caret}' followed by an at sign is the same as listing
+ all parents of '<rev>' (meaning, include anything reachable from
+ its parents, but not the commit itself).
+
+'<rev>{caret}!', e.g. 'HEAD{caret}!'::
+ A suffix '{caret}' followed by an exclamation mark is the same
+ as giving commit '<rev>' and all its parents prefixed with
+ '{caret}' to exclude them (and their ancestors).
+
+'<rev>{caret}-<n>', e.g. 'HEAD{caret}-, HEAD{caret}-2'::
+ Equivalent to '<rev>{caret}<n>..<rev>', with '<n>' = 1 if not
+ given.
+
+Here are a handful of examples using the Loeliger illustration above,
+with each step in the notation's expansion and selection carefully
+spelt out:
+
+....
+ Args Expanded arguments Selected commits
+ D G H D
+ D F G H I J D F
+ ^G D H D
+ ^D B E I J F B
+ ^D B C E I J F B C
+ C I J F C
+ B..C = ^B C C
+ B...C = B ^F C G H D E B C
+ B^- = B^..B
+ = ^B^1 B E I J F B
+ C^@ = C^1
+ = F I J F
+ B^@ = B^1 B^2 B^3
+ = D E F D G H E F I J
+ C^! = C ^C^@
+ = C ^C^1
+ = C ^F C
+ B^! = B ^B^@
+ = B ^B^1 ^B^2 ^B^3
+ = B ^D ^E ^F B
+ F^! D = F ^I ^J D G H D F
+....
diff --git a/scalar.adoc b/scalar.adoc
new file mode 100644
index 0000000..7e4259c
--- /dev/null
+++ b/scalar.adoc
@@ -0,0 +1,179 @@
+scalar(1)
+=========
+
+NAME
+----
+scalar - A tool for managing large Git repositories
+
+SYNOPSIS
+--------
+[verse]
+scalar clone [--single-branch] [--branch <main-branch>] [--full-clone]
+ [--[no-]src] <url> [<enlistment>]
+scalar list
+scalar register [<enlistment>]
+scalar unregister [<enlistment>]
+scalar run ( all | config | commit-graph | fetch | loose-objects | pack-files ) [<enlistment>]
+scalar reconfigure [ --all | <enlistment> ]
+scalar diagnose [<enlistment>]
+scalar delete <enlistment>
+
+DESCRIPTION
+-----------
+
+Scalar is a repository management tool that optimizes Git for use in large
+repositories. Scalar improves performance by configuring advanced Git settings,
+maintaining repositories in the background, and helping to reduce data sent
+across the network.
+
+An important Scalar concept is the enlistment: this is the top-level directory
+of the project. It usually contains the subdirectory `src/` which is a Git
+worktree. This encourages the separation between tracked files (inside `src/`)
+and untracked files, such as build artifacts (outside `src/`). When registering
+an existing Git worktree with Scalar whose name is not `src`, the enlistment
+will be identical to the worktree.
+
+The `scalar` command implements various subcommands, and different options
+depending on the subcommand. With the exception of `clone`, `list` and
+`reconfigure --all`, all subcommands expect to be run in an enlistment.
+
+The following options can be specified _before_ the subcommand:
+
+-C <directory>::
+ Before running the subcommand, change the working directory. This
+ option imitates the same option of linkgit:git[1].
+
+-c <key>=<value>::
+ For the duration of running the specified subcommand, configure this
+ setting. This option imitates the same option of linkgit:git[1].
+
+COMMANDS
+--------
+
+Clone
+~~~~~
+
+clone [<options>] <url> [<enlistment>]::
+ Clones the specified repository, similar to linkgit:git-clone[1]. By
+ default, only commit and tree objects are cloned. Once finished, the
+ worktree is located at `<enlistment>/src`.
++
+The sparse-checkout feature is enabled (except when run with `--full-clone`)
+and the only files present are those in the top-level directory. Use
+`git sparse-checkout set` to expand the set of directories you want to see,
+or `git sparse-checkout disable` to expand to all files (see
+linkgit:git-sparse-checkout[1] for more details). You can explore the
+subdirectories outside your sparse-checkout by using `git ls-tree
+HEAD[:<directory>]`.
+
+-b <name>::
+--branch <name>::
+ Instead of checking out the branch pointed to by the cloned
+ repository's HEAD, check out the `<name>` branch instead.
+
+--[no-]single-branch::
+ Clone only the history leading to the tip of a single branch, either
+ specified by the `--branch` option or the primary branch remote's
+ `HEAD` points at.
++
+Further fetches into the resulting repository will only update the
+remote-tracking branch for the branch this option was used for the initial
+cloning. If the HEAD at the remote did not point at any branch when
+`--single-branch` clone was made, no remote-tracking branch is created.
+
+--[no-]src::
+ By default, `scalar clone` places the cloned repository within a
+ `<entlistment>/src` directory. Use `--no-src` to place the cloned
+ repository directly in the `<enlistment>` directory.
+
+--[no-]tags::
+ By default, `scalar clone` will fetch the tag objects advertised by
+ the remote and future `git fetch` commands will do the same. Use
+ `--no-tags` to avoid fetching tags in `scalar clone` and to configure
+ the repository to avoid fetching tags in the future. To fetch tags after
+ cloning with `--no-tags`, run `git fetch --tags`.
+
+--[no-]full-clone::
+ A sparse-checkout is initialized by default. This behavior can be
+ turned off via `--full-clone`.
+
+List
+~~~~
+
+list::
+ List enlistments that are currently registered by Scalar. This
+ subcommand does not need to be run inside an enlistment.
+
+Register
+~~~~~~~~
+
+register [<enlistment>]::
+ Adds the enlistment's repository to the list of registered repositories
+ and starts background maintenance. If `<enlistment>` is not provided,
+ then the enlistment associated with the current working directory is
+ registered.
++
+Note: when this subcommand is called in a worktree that is called `src/`, its
+parent directory is considered to be the Scalar enlistment. If the worktree is
+_not_ called `src/`, it itself will be considered to be the Scalar enlistment.
+
+Unregister
+~~~~~~~~~~
+
+unregister [<enlistment>]::
+ Remove the specified repository from the list of repositories
+ registered with Scalar and stop the scheduled background maintenance.
+
+Run
+~~~
+
+scalar run ( all | config | commit-graph | fetch | loose-objects | pack-files ) [<enlistment>]::
+ Run the given maintenance task (or all tasks, if `all` was specified).
+ Except for `all` and `config`, this subcommand simply hands off to
+ linkgit:git-maintenance[1] (mapping `fetch` to `prefetch` and
+ `pack-files` to `incremental-repack`).
++
+These tasks are run automatically as part of the scheduled maintenance,
+as soon as the repository is registered with Scalar. It should therefore
+not be necessary to run this subcommand manually.
++
+The `config` task is specific to Scalar and configures all those
+opinionated default settings that make Git work more efficiently with
+large repositories. As this task is run as part of `scalar clone`
+automatically, explicit invocations of this task are rarely needed.
+
+Reconfigure
+~~~~~~~~~~~
+
+After a Scalar upgrade, or when the configuration of a Scalar enlistment
+was somehow corrupted or changed by mistake, this subcommand allows to
+reconfigure the enlistment.
+
+With the `--all` option, all enlistments currently registered with Scalar
+will be reconfigured. Use this option after each Scalar upgrade.
+
+Diagnose
+~~~~~~~~
+
+diagnose [<enlistment>]::
+ When reporting issues with Scalar, it is often helpful to provide the
+ information gathered by this command, including logs and certain
+ statistics describing the data shape of the current enlistment.
++
+The output of this command is a `.zip` file that is written into
+a directory adjacent to the worktree in the `src` directory.
+
+Delete
+~~~~~~
+
+delete <enlistment>::
+ This subcommand lets you delete an existing Scalar enlistment from your
+ local file system, unregistering the repository.
+
+SEE ALSO
+--------
+linkgit:git-clone[1], linkgit:git-maintenance[1].
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/sequencer.adoc b/sequencer.adoc
new file mode 100644
index 0000000..3bceb56
--- /dev/null
+++ b/sequencer.adoc
@@ -0,0 +1,16 @@
+--continue::
+ Continue the operation in progress using the information in
+ `.git/sequencer`. Can be used to continue after resolving
+ conflicts in a failed cherry-pick or revert.
+
+--skip::
+ Skip the current commit and continue with the rest of the
+ sequence.
+
+--quit::
+ Forget about the current operation in progress. Can be used
+ to clear the sequencer state after a failed cherry-pick or
+ revert.
+
+--abort::
+ Cancel the operation and return to the pre-sequence state.
diff --git a/signoff-option.adoc b/signoff-option.adoc
new file mode 100644
index 0000000..cddfb22
--- /dev/null
+++ b/signoff-option.adoc
@@ -0,0 +1,18 @@
+ifdef::git-commit[]
+`-s`::
+endif::git-commit[]
+`--signoff`::
+`--no-signoff`::
+ Add a `Signed-off-by` trailer by the committer at the end of the commit
+ log message. The meaning of a signoff depends on the project
+ to which you're committing. For example, it may certify that
+ the committer has the rights to submit the work under the
+ project's license or agrees to some contributor representation,
+ such as a Developer Certificate of Origin.
+ (See https://developercertificate.org for the one used by the
+ Linux kernel and Git projects.) Consult the documentation or
+ leadership of the project to which you're contributing to
+ understand how the signoffs are used in that project.
++
+The `--no-signoff` option can be used to countermand an earlier `--signoff`
+option on the command line.
diff --git a/technical/api-error-handling.adoc b/technical/api-error-handling.adoc
new file mode 100644
index 0000000..665c496
--- /dev/null
+++ b/technical/api-error-handling.adoc
@@ -0,0 +1,103 @@
+Error reporting in git
+======================
+
+`BUG`, `bug`, `die`, `usage`, `error`, and `warning` report errors of
+various kinds.
+
+- `BUG` is for failed internal assertions that should never happen,
+ i.e. a bug in git itself.
+
+- `bug` (lower-case, not `BUG`) is supposed to be used like `BUG` but
+ prints a "BUG" message instead of calling `abort()`.
++
+A call to `bug()` will then result in a "real" call to the `BUG()`
+function, either explicitly by invoking `BUG_if_bug()` after call(s)
+to `bug()`, or implicitly at `exit()` time where we'll check if we
+encountered any outstanding `bug()` invocations.
++
+If there were no prior calls to `bug()` before invoking `BUG_if_bug()`
+the latter is a NOOP. The `BUG_if_bug()` function takes the same
+arguments as `BUG()` itself. Calling `BUG_if_bug()` explicitly isn't
+necessary, but ensures that we die as soon as possible.
++
+If you know you had prior calls to `bug()` then calling `BUG()` itself
+is equivalent to calling `BUG_if_bug()`, the latter being a wrapper
+calling `BUG()` if we've set a flag indicating that we've called
+`bug()`.
++
+This is for the convenience of APIs who'd like to potentially report
+more than one "bug", such as the optbug() validation in
+parse-options.c.
+
+- `die` is for fatal application errors. It prints a message to
+ the user and exits with status 128.
+
+- `usage` is for errors in command line usage. After printing its
+ message, it exits with status 129. (See also `usage_with_options`
+ in the link:api-parse-options.html[parse-options API].)
+
+- `error` is for non-fatal library errors. It prints a message
+ to the user and returns -1 for convenience in signaling the error
+ to the caller.
+
+- `warning` is for reporting situations that probably should not
+ occur but which the user (and Git) can continue to work around
+ without running into too many problems. Like `error`, it
+ returns -1 after reporting the situation to the caller.
+
+These reports will be logged via the trace2 facility. See the "error"
+event in link:api-trace2.html[trace2 API].
+
+Customizable error handlers
+---------------------------
+
+The default behavior of `die` and `error` is to write a message to
+stderr and then exit or return as appropriate. This behavior can be
+overridden using `set_die_routine` and `set_error_routine`. For
+example, "git daemon" uses set_die_routine to write the reason `die`
+was called to syslog before exiting.
+
+Library errors
+--------------
+
+Functions return a negative integer on error. Details beyond that
+vary from function to function:
+
+- Some functions return -1 for all errors. Others return a more
+ specific value depending on how the caller might want to react
+ to the error.
+
+- Some functions report the error to stderr with `error`,
+ while others leave that for the caller to do.
+
+- errno is not meaningful on return from most functions (except
+ for thin wrappers for system calls).
+
+Check the function's API documentation to be sure.
+
+Caller-handled errors
+---------------------
+
+An increasing number of functions take a parameter 'struct strbuf *err'.
+On error, such functions append a message about what went wrong to the
+'err' strbuf. The message is meant to be complete enough to be passed
+to `die` or `error` as-is. For example:
+
+ if (ref_transaction_commit(transaction, &err))
+ die("%s", err.buf);
+
+The 'err' parameter will be untouched if no error occurred, so multiple
+function calls can be chained:
+
+ t = ref_transaction_begin(&err);
+ if (!t ||
+ ref_transaction_update(t, "HEAD", ..., &err) ||
+ ret_transaction_commit(t, &err))
+ die("%s", err.buf);
+
+The 'err' parameter must be a pointer to a valid strbuf. To silence
+a message, pass a strbuf that is explicitly ignored:
+
+ if (thing_that_can_fail_in_an_ignorable_way(..., &err))
+ /* This failure is okay. */
+ strbuf_reset(&err);
diff --git a/technical/api-index-skel.adoc b/technical/api-index-skel.adoc
new file mode 100644
index 0000000..7780a76
--- /dev/null
+++ b/technical/api-index-skel.adoc
@@ -0,0 +1,13 @@
+Git API Documents
+=================
+
+Git has grown a set of internal APIs over time. This collection
+documents them.
+
+////////////////////////////////////////////////////////////////
+// table of contents begin
+////////////////////////////////////////////////////////////////
+
+////////////////////////////////////////////////////////////////
+// table of contents end
+////////////////////////////////////////////////////////////////
diff --git a/technical/api-index.adoc b/technical/api-index.adoc
new file mode 100644
index 0000000..7d88cd0
--- /dev/null
+++ b/technical/api-index.adoc
@@ -0,0 +1,18 @@
+Git API Documents
+=================
+
+Git has grown a set of internal APIs over time. This collection
+documents them.
+
+////////////////////////////////////////////////////////////////
+// table of contents begin
+////////////////////////////////////////////////////////////////
+* link:api-error-handling.html[Error reporting in git]
+* link:api-merge.html[merge API]
+* link:api-parse-options.html[parse-options API]
+* link:api-path-walk.html[Path-Walk API]
+* link:api-simple-ipc.html[Simple-IPC API]
+* link:api-trace2.html[= Trace2 API]
+////////////////////////////////////////////////////////////////
+// table of contents end
+////////////////////////////////////////////////////////////////
diff --git a/technical/api-merge.adoc b/technical/api-merge.adoc
new file mode 100644
index 0000000..c2ba018
--- /dev/null
+++ b/technical/api-merge.adoc
@@ -0,0 +1,36 @@
+merge API
+=========
+
+The merge API helps a program to reconcile two competing sets of
+improvements to some files (e.g., unregistered changes from the work
+tree versus changes involved in switching to a new branch), reporting
+conflicts if found. The library called through this API is
+responsible for a few things.
+
+ * determining which trees to merge (recursive ancestor consolidation);
+
+ * lining up corresponding files in the trees to be merged (rename
+ detection, subtree shifting), reporting edge cases like add/add
+ and rename/rename conflicts to the user;
+
+ * performing a three-way merge of corresponding files, taking
+ path-specific merge drivers (specified in `.gitattributes`)
+ into account.
+
+Data structures
+---------------
+
+* `mmbuffer_t`, `mmfile_t`
+
+These store data usable for use by the xdiff backend, for writing and
+for reading, respectively. See `xdiff/xdiff.h` for the definitions
+and `diff.c` for examples.
+
+* `struct ll_merge_options`
+
+Check merge-ll.h for details.
+
+Low-level (single file) merge
+-----------------------------
+
+Check merge-ll.h for details.
diff --git a/technical/api-parse-options.adoc b/technical/api-parse-options.adoc
new file mode 100644
index 0000000..61fa6ee
--- /dev/null
+++ b/technical/api-parse-options.adoc
@@ -0,0 +1,349 @@
+parse-options API
+=================
+
+The parse-options API is used to parse and massage options in Git
+and to provide a usage help with consistent look.
+
+Basics
+------
+
+The argument vector `argv[]` may usually contain mandatory or optional
+'non-option arguments', e.g. a filename or a branch, 'options', and
+'subcommands'.
+Options are optional arguments that start with a dash and
+that allow to change the behavior of a command.
+
+* There are basically three types of options:
+ 'boolean' options,
+ options with (mandatory) 'arguments' and
+ options with 'optional arguments'
+ (i.e. a boolean option that can be adjusted).
+
+* There are basically two forms of options:
+ 'Short options' consist of one dash (`-`) and one alphanumeric
+ character.
+ 'Long options' begin with two dashes (`--`) and some
+ alphanumeric characters.
+
+* Options are case-sensitive.
+ Please define 'lower-case long options' only.
+
+The parse-options API allows:
+
+* 'stuck' and 'separate form' of options with arguments.
+ `-oArg` is stuck, `-o Arg` is separate form.
+ `--option=Arg` is stuck, `--option Arg` is separate form.
+
+* Long options may be 'abbreviated', as long as the abbreviation
+ is unambiguous.
+
+* Short options may be bundled, e.g. `-a -b` can be specified as `-ab`.
+
+* Boolean long options can be 'negated' (or 'unset') by prepending
+ `no-`, e.g. `--no-abbrev` instead of `--abbrev`. Conversely,
+ options that begin with `no-` can be 'negated' by removing it.
+ Other long options can be unset (e.g., set string to NULL, set
+ integer to 0) by prepending `no-`.
+
+* Options and non-option arguments can clearly be separated using the `--`
+ option, e.g. `-a -b --option -- --this-is-a-file` indicates that
+ `--this-is-a-file` must not be processed as an option.
+
+Subcommands are special in a couple of ways:
+
+* Subcommands only have long form, and they have no double dash prefix, no
+ negated form, and no description, and they don't take any arguments, and
+ can't be abbreviated.
+
+* There must be exactly one subcommand among the arguments, or zero if the
+ command has a default operation mode.
+
+* All arguments following the subcommand are considered to be arguments of
+ the subcommand, and, conversely, arguments meant for the subcommand may
+ not precede the subcommand.
+
+Therefore, if the options array contains at least one subcommand and
+`parse_options()` encounters the first dashless argument, it will either:
+
+* stop and return, if that dashless argument is a known subcommand, setting
+ `value` to the function pointer associated with that subcommand, storing
+ the name of the subcommand in argv[0], and leaving the rest of the
+ arguments unprocessed, or
+
+* stop and return, if it was invoked with the `PARSE_OPT_SUBCOMMAND_OPTIONAL`
+ flag and that dashless argument doesn't match any subcommands, leaving
+ `value` unchanged and the rest of the arguments unprocessed, or
+
+* show error and usage, and abort.
+
+Steps to parse options
+----------------------
+
+. `#include "parse-options.h"`
+
+. define a NULL-terminated
+ `static const char * const builtin_foo_usage[]` array
+ containing alternative usage strings
+
+. define `builtin_foo_options` array as described below
+ in section 'Data Structure'.
+
+. in `cmd_foo(int argc, const char **argv, const char *prefix)`
+ call
+
+ argc = parse_options(argc, argv, prefix, builtin_foo_options, builtin_foo_usage, flags);
++
+`parse_options()` will filter out the processed options of `argv[]` and leave the
+non-option arguments in `argv[]`.
+`argc` is updated appropriately because of the assignment.
++
+You can also pass NULL instead of a usage array as the fifth parameter of
+parse_options(), to avoid displaying a help screen with usage info and
+option list. This should only be done if necessary, e.g. to implement
+a limited parser for only a subset of the options that needs to be run
+before the full parser, which in turn shows the full help message.
++
+Flags are the bitwise-or of:
+
+`PARSE_OPT_KEEP_DASHDASH`::
+ Keep the `--` that usually separates options from
+ non-option arguments.
+
+`PARSE_OPT_STOP_AT_NON_OPTION`::
+ Usually the whole argument vector is massaged and reordered.
+ Using this flag, processing is stopped at the first non-option
+ argument.
+
+`PARSE_OPT_KEEP_ARGV0`::
+ Keep the first argument, which contains the program name. It's
+ removed from argv[] by default.
+
+`PARSE_OPT_KEEP_UNKNOWN_OPT`::
+ Keep unknown options instead of erroring out. This doesn't
+ work for all combinations of arguments as users might expect
+ it to do. E.g. if the first argument in `--unknown --known`
+ takes a value (which we can't know), the second one is
+ mistakenly interpreted as a known option. Similarly, if
+ `PARSE_OPT_STOP_AT_NON_OPTION` is set, the second argument in
+ `--unknown value` will be mistakenly interpreted as a
+ non-option, not as a value belonging to the unknown option,
+ the parser early. That's why parse_options() errors out if
+ both options are set.
+ Note that non-option arguments are always kept, even without
+ this flag.
+
+`PARSE_OPT_NO_INTERNAL_HELP`::
+ By default, parse_options() handles `-h`, `--help` and
+ `--help-all` internally, by showing a help screen. This option
+ turns it off and allows one to add custom handlers for these
+ options, or to just leave them unknown.
+
+`PARSE_OPT_SUBCOMMAND_OPTIONAL`::
+ Don't error out when no subcommand is specified.
+
+Note that `PARSE_OPT_STOP_AT_NON_OPTION` is incompatible with subcommands;
+while `PARSE_OPT_KEEP_DASHDASH` and `PARSE_OPT_KEEP_UNKNOWN_OPT` can only be
+used with subcommands when combined with `PARSE_OPT_SUBCOMMAND_OPTIONAL`.
+
+Data Structure
+--------------
+
+The main data structure is an array of the `option` struct,
+say `static struct option builtin_add_options[]`.
+There are some macros to easily define options:
+
+`OPT__ABBREV(&int_var)`::
+ Add `--abbrev[=<n>]`.
+
+`OPT__COLOR(&int_var, description)`::
+ Add `--color[=<when>]` and `--no-color`.
+
+`OPT__DRY_RUN(&int_var, description)`::
+ Add `-n, --dry-run`.
+
+`OPT__FORCE(&int_var, description)`::
+ Add `-f, --force`.
+
+`OPT__QUIET(&int_var, description)`::
+ Add `-q, --quiet`.
+
+`OPT__VERBOSE(&int_var, description)`::
+ Add `-v, --verbose`.
+
+`OPT_GROUP(description)`::
+ Start an option group. `description` is a short string that
+ describes the group or an empty string.
+ Start the description with an upper-case letter.
+
+`OPT_BOOL(short, long, &int_var, description)`::
+ Introduce a boolean option. `int_var` is set to one with
+ `--option` and set to zero with `--no-option`.
+
+`OPT_COUNTUP(short, long, &int_var, description)`::
+ Introduce a count-up option.
+ Each use of `--option` increments `int_var`, starting from zero
+ (even if initially negative), and `--no-option` resets it to
+ zero. To determine if `--option` or `--no-option` was encountered at
+ all, initialize `int_var` to a negative value, and if it is still
+ negative after parse_options(), then neither `--option` nor
+ `--no-option` was seen.
+
+`OPT_BIT(short, long, &int_var, description, mask)`::
+ Introduce a boolean option.
+ If used, `int_var` is bitwise-ored with `mask`.
+
+`OPT_NEGBIT(short, long, &int_var, description, mask)`::
+ Introduce a boolean option.
+ If used, `int_var` is bitwise-anded with the inverted `mask`.
+
+`OPT_SET_INT(short, long, &int_var, description, integer)`::
+ Introduce an integer option.
+ `int_var` is set to `integer` with `--option`, and
+ reset to zero with `--no-option`.
+
+`OPT_STRING(short, long, &str_var, arg_str, description)`::
+ Introduce an option with string argument.
+ The string argument is put into `str_var`.
+
+`OPT_STRING_LIST(short, long, &struct string_list, arg_str, description)`::
+ Introduce an option with string argument.
+ The string argument is stored as an element in `string_list`.
+ Use of `--no-option` will clear the list of preceding values.
+
+`OPT_INTEGER(short, long, &int_var, description)`::
+ Introduce an option with integer argument.
+ The integer is put into `int_var`.
+
+`OPT_MAGNITUDE(short, long, &unsigned_long_var, description)`::
+ Introduce an option with a size argument. The argument must be a
+ non-negative integer and may include a suffix of 'k', 'm' or 'g' to
+ scale the provided value by 1024, 1024^2 or 1024^3 respectively.
+ The scaled value is put into `unsigned_long_var`.
+
+`OPT_EXPIRY_DATE(short, long, ×tamp_t_var, description)`::
+ Introduce an option with expiry date argument, see `parse_expiry_date()`.
+ The timestamp is put into `timestamp_t_var`.
+
+`OPT_CALLBACK(short, long, &var, arg_str, description, func_ptr)`::
+ Introduce an option with argument.
+ The argument will be fed into the function given by `func_ptr`
+ and the result will be put into `var`.
+ See 'Option Callbacks' below for a more elaborate description.
+
+`OPT_FILENAME(short, long, &var, description)`::
+ Introduce an option with a filename argument.
+ The filename will be prefixed by passing the filename along with
+ the prefix argument of `parse_options()` to `prefix_filename()`.
+
+`OPT_NUMBER_CALLBACK(&var, description, func_ptr)`::
+ Recognize numerical options like -123 and feed the integer as
+ if it was an argument to the function given by `func_ptr`.
+ The result will be put into `var`. There can be only one such
+ option definition. It cannot be negated and it takes no
+ arguments. Short options that happen to be digits take
+ precedence over it.
+
+`OPT_COLOR_FLAG(short, long, &int_var, description)`::
+ Introduce an option that takes an optional argument that can
+ have one of three values: "always", "never", or "auto". If the
+ argument is not given, it defaults to "always". The `--no-` form
+ works like `--long=never`; it cannot take an argument. If
+ "always", set `int_var` to 1; if "never", set `int_var` to 0; if
+ "auto", set `int_var` to 1 if stdout is a tty or a pager,
+ 0 otherwise.
+
+`OPT_NOOP_NOARG(short, long)`::
+ Introduce an option that has no effect and takes no arguments.
+ Use it to hide deprecated options that are still to be recognized
+ and ignored silently.
+
+`OPT_PASSTHRU(short, long, &char_var, arg_str, description, flags)`::
+ Introduce an option that will be reconstructed into a char* string,
+ which must be initialized to NULL. This is useful when you need to
+ pass the command-line option to another command. Any previous value
+ will be overwritten, so this should only be used for options where
+ the last one specified on the command line wins.
+
+`OPT_PASSTHRU_ARGV(short, long, &strvec_var, arg_str, description, flags)`::
+ Introduce an option where all instances of it on the command-line will
+ be reconstructed into a strvec. This is useful when you need to
+ pass the command-line option, which can be specified multiple times,
+ to another command.
+
+`OPT_CMDMODE(short, long, &int_var, description, enum_val)`::
+ Define an "operation mode" option, only one of which in the same
+ group of "operating mode" options that share the same `int_var`
+ can be given by the user. `int_var` is set to `enum_val` when the
+ option is used, but an error is reported if other "operating mode"
+ option has already set its value to the same `int_var`.
+ In new commands consider using subcommands instead.
+
+`OPT_SUBCOMMAND(long, &fn_ptr, subcommand_fn)`::
+ Define a subcommand. `subcommand_fn` is put into `fn_ptr` when
+ this subcommand is used.
+
+The last element of the array must be `OPT_END()`.
+
+If not stated otherwise, interpret the arguments as follows:
+
+* `short` is a character for the short option
+ (e.g. `'e'` for `-e`, use `0` to omit),
+
+* `long` is a string for the long option
+ (e.g. `"example"` for `--example`, use `NULL` to omit),
+
+* `int_var` is an integer variable,
+
+* `str_var` is a string variable (`char *`),
+
+* `arg_str` is the string that is shown as argument
+ (e.g. `"branch"` will result in `<branch>`).
+ If set to `NULL`, three dots (`...`) will be displayed.
+
+* `description` is a short string to describe the effect of the option.
+ It shall begin with a lower-case letter and a full stop (`.`) shall be
+ omitted at the end.
+
+Option Callbacks
+----------------
+
+The function must be defined in this form:
+
+ int func(const struct option *opt, const char *arg, int unset)
+
+The callback mechanism is as follows:
+
+* Inside `func`, the only interesting member of the structure
+ given by `opt` is the void pointer `opt->value`.
+ `*opt->value` will be the value that is saved into `var`, if you
+ use `OPT_CALLBACK()`.
+ For example, do `*(unsigned long *)opt->value = 42;` to get 42
+ into an `unsigned long` variable.
+
+* Return value `0` indicates success and non-zero return
+ value will invoke `usage_with_options()` and, thus, die.
+
+* If the user negates the option, `arg` is `NULL` and `unset` is 1.
+
+Sophisticated option parsing
+----------------------------
+
+If you need, for example, option callbacks with optional arguments
+or without arguments at all, or if you need other special cases,
+that are not handled by the macros above, you need to specify the
+members of the `option` structure manually.
+
+This is not covered in this document, but well documented
+in `parse-options.h` itself.
+
+Examples
+--------
+
+See `test-parse-options.c` and
+`builtin/add.c`,
+`builtin/clone.c`,
+`builtin/commit.c`,
+`builtin/fetch.c`,
+`builtin/fsck.c`,
+`builtin/rm.c`
+for real-world examples.
diff --git a/technical/api-path-walk.adoc b/technical/api-path-walk.adoc
new file mode 100644
index 0000000..7075d0d
--- /dev/null
+++ b/technical/api-path-walk.adoc
@@ -0,0 +1,63 @@
+Path-Walk API
+=============
+
+The path-walk API is used to walk reachable objects, but to visit objects
+in batches based on a common path they appear in, or by type.
+
+For example, all reachable commits are visited in a group. All tags are
+visited in a group. Then, all root trees are visited. At some point, all
+blobs reachable via a path `my/dir/to/A` are visited. When there are
+multiple paths possible to reach the same object, then only one of those
+paths is used to visit the object.
+
+Basics
+------
+
+To use the path-walk API, include `path-walk.h` and call
+`walk_objects_by_path()` with a customized `path_walk_info` struct. The
+struct is used to set all of the options for how the walk should proceed.
+Let's dig into the different options and their use.
+
+`path_fn` and `path_fn_data`::
+ The most important option is the `path_fn` option, which is a
+ function pointer to the callback that can execute logic on the
+ object IDs for objects grouped by type and path. This function
+ also receives a `data` value that corresponds to the
+ `path_fn_data` member, for providing custom data structures to
+ this callback function.
+
+`revs`::
+ To configure the exact details of the reachable set of objects,
+ use the `revs` member and initialize it using the revision
+ machinery in `revision.h`. Initialize `revs` using calls such as
+ `setup_revisions()` or `parse_revision_opt()`. Do not call
+ `prepare_revision_walk()`, as that will be called within
+ `walk_objects_by_path()`.
++
+It is also important that you do not specify the `--objects` flag for the
+`revs` struct. The revision walk should only be used to walk commits, and
+the objects will be walked in a separate way based on those starting
+commits.
+
+`commits`, `blobs`, `trees`, `tags`::
+ By default, these members are enabled and signal that the path-walk
+ API should call the `path_fn` on objects of these types. Specialized
+ applications could disable some options to make it simpler to walk
+ the objects or to have fewer calls to `path_fn`.
++
+While it is possible to walk only commits in this way, consumers would be
+better off using the revision walk API instead.
+
+`prune_all_uninteresting`::
+ By default, all reachable paths are emitted by the path-walk API.
+ This option allows consumers to declare that they are not
+ interested in paths where all included objects are marked with the
+ `UNINTERESTING` flag. This requires using the `boundary` option in
+ the revision walk so that the walk emits commits marked with the
+ `UNINTERESTING` flag.
+
+Examples
+--------
+
+See example usages in:
+ `t/helper/test-path-walk.c`
diff --git a/technical/api-simple-ipc.adoc b/technical/api-simple-ipc.adoc
new file mode 100644
index 0000000..c4fb152
--- /dev/null
+++ b/technical/api-simple-ipc.adoc
@@ -0,0 +1,105 @@
+Simple-IPC API
+==============
+
+The Simple-IPC API is a collection of `ipc_` prefixed library routines
+and a basic communication protocol that allows an IPC-client process to
+send an application-specific IPC-request message to an IPC-server
+process and receive an application-specific IPC-response message.
+
+Communication occurs over a named pipe on Windows and a Unix domain
+socket on other platforms. IPC-clients and IPC-servers rendezvous at
+a previously agreed-to application-specific pathname (which is outside
+the scope of this design) that is local to the computer system.
+
+The IPC-server routines within the server application process create a
+thread pool to listen for connections and receive request messages
+from multiple concurrent IPC-clients. When received, these messages
+are dispatched up to the server application callbacks for handling.
+IPC-server routines then incrementally relay responses back to the
+IPC-client.
+
+The IPC-client routines within a client application process connect
+to the IPC-server and send a request message and wait for a response.
+When received, the response is returned back to the caller.
+
+For example, the `fsmonitor--daemon` feature will be built as a server
+application on top of the IPC-server library routines. It will have
+threads watching for file system events and a thread pool waiting for
+client connections. Clients, such as `git status`, will request a list
+of file system events since a point in time and the server will
+respond with a list of changed files and directories. The formats of
+the request and response are application-specific; the IPC-client and
+IPC-server routines treat them as opaque byte streams.
+
+
+Comparison with sub-process model
+---------------------------------
+
+The Simple-IPC mechanism differs from the existing `sub-process.c`
+model (Documentation/technical/long-running-process-protocol.txt) and
+used by applications like Git-LFS. In the LFS-style sub-process model,
+the helper is started by the foreground process, communication happens
+via a pair of file descriptors bound to the stdin/stdout of the
+sub-process, the sub-process only serves the current foreground
+process, and the sub-process exits when the foreground process
+terminates.
+
+In the Simple-IPC model the server is a very long-running service. It
+can service many clients at the same time and has a private socket or
+named pipe connection to each active client. It might be started
+(on-demand) by the current client process or it might have been
+started by a previous client or by the OS at boot time. The server
+process is not associated with a terminal and it persists after
+clients terminate. Clients do not have access to the stdin/stdout of
+the server process and therefore must communicate over sockets or
+named pipes.
+
+
+Server startup and shutdown
+---------------------------
+
+How an application server based upon IPC-server is started is also
+outside the scope of the Simple-IPC design and is a property of the
+application using it. For example, the server might be started or
+restarted during routine maintenance operations, or it might be
+started as a system service during the system boot-up sequence, or it
+might be started on-demand by a foreground Git command when needed.
+
+Similarly, server shutdown is a property of the application using
+the simple-ipc routines. For example, the server might decide to
+shutdown when idle or only upon explicit request.
+
+
+Simple-IPC protocol
+-------------------
+
+The Simple-IPC protocol consists of a single request message from the
+client and an optional response message from the server. Both the
+client and server messages are unlimited in length and are terminated
+with a flush packet.
+
+The pkt-line routines (linkgit:gitprotocol-common[5])
+are used to simplify buffer management during message generation,
+transmission, and reception. A flush packet is used to mark the end
+of the message. This allows the sender to incrementally generate and
+transmit the message. It allows the receiver to incrementally receive
+the message in chunks and to know when they have received the entire
+message.
+
+The actual byte format of the client request and server response
+messages are application specific. The IPC layer transmits and
+receives them as opaque byte buffers without any concern for the
+content within. It is the job of the calling application layer to
+understand the contents of the request and response messages.
+
+
+Summary
+-------
+
+Conceptually, the Simple-IPC protocol is similar to an HTTP REST
+request. Clients connect, make an application-specific and
+stateless request, receive an application-specific
+response, and disconnect. It is a one round trip facility for
+querying the server. The Simple-IPC routines hide the socket,
+named pipe, and thread pool details and allow the application
+layer to focus on the task at hand.
diff --git a/technical/api-trace2.adoc b/technical/api-trace2.adoc
new file mode 100644
index 0000000..cf493da
--- /dev/null
+++ b/technical/api-trace2.adoc
@@ -0,0 +1,1352 @@
+= Trace2 API
+
+The Trace2 API can be used to print debug, performance, and telemetry
+information to stderr or a file. The Trace2 feature is inactive unless
+explicitly enabled by enabling one or more Trace2 Targets.
+
+The Trace2 API is intended to replace the existing (Trace1)
+`printf()`-style tracing provided by the existing `GIT_TRACE` and
+`GIT_TRACE_PERFORMANCE` facilities. During initial implementation,
+Trace2 and Trace1 may operate in parallel.
+
+The Trace2 API defines a set of high-level messages with known fields,
+such as (`start`: `argv`) and (`exit`: {`exit-code`, `elapsed-time`}).
+
+Trace2 instrumentation throughout the Git code base sends Trace2
+messages to the enabled Trace2 Targets. Targets transform these
+messages content into purpose-specific formats and write events to
+their data streams. In this manner, the Trace2 API can drive
+many different types of analysis.
+
+Targets are defined using a VTable allowing easy extension to other
+formats in the future. This might be used to define a binary format,
+for example.
+
+Trace2 is controlled using `trace2.*` config values in the system and
+global config files and `GIT_TRACE2*` environment variables. Trace2 does
+not read from repo local or worktree config files, nor does it respect
+`-c` command line config settings.
+
+== Trace2 Targets
+
+Trace2 defines the following set of Trace2 Targets.
+Format details are given in a later section.
+
+=== The Normal Format Target
+
+The normal format target is a traditional `printf()` format and similar
+to the `GIT_TRACE` format. This format is enabled with the `GIT_TRACE2`
+environment variable or the `trace2.normalTarget` system or global
+config setting.
+
+For example
+
+------------
+$ export GIT_TRACE2=~/log.normal
+$ git version
+git version 2.20.1.155.g426c96fcdb
+------------
+
+or
+
+------------
+$ git config --global trace2.normalTarget ~/log.normal
+$ git version
+git version 2.20.1.155.g426c96fcdb
+------------
+
+yields
+
+------------
+$ cat ~/log.normal
+12:28:42.620009 common-main.c:38 version 2.20.1.155.g426c96fcdb
+12:28:42.620989 common-main.c:39 start git version
+12:28:42.621101 git.c:432 cmd_name version (version)
+12:28:42.621215 git.c:662 exit elapsed:0.001227 code:0
+12:28:42.621250 trace2/tr2_tgt_normal.c:124 atexit elapsed:0.001265 code:0
+------------
+
+=== The Performance Format Target
+
+The performance format target (PERF) is a column-based format to
+replace `GIT_TRACE_PERFORMANCE` and is suitable for development and
+testing, possibly to complement tools like `gprof`. This format is
+enabled with the `GIT_TRACE2_PERF` environment variable or the
+`trace2.perfTarget` system or global config setting.
+
+For example
+
+------------
+$ export GIT_TRACE2_PERF=~/log.perf
+$ git version
+git version 2.20.1.155.g426c96fcdb
+------------
+
+or
+
+------------
+$ git config --global trace2.perfTarget ~/log.perf
+$ git version
+git version 2.20.1.155.g426c96fcdb
+------------
+
+yields
+
+------------
+$ cat ~/log.perf
+12:28:42.620675 common-main.c:38 | d0 | main | version | | | | | 2.20.1.155.g426c96fcdb
+12:28:42.621001 common-main.c:39 | d0 | main | start | | 0.001173 | | | git version
+12:28:42.621111 git.c:432 | d0 | main | cmd_name | | | | | version (version)
+12:28:42.621225 git.c:662 | d0 | main | exit | | 0.001227 | | | code:0
+12:28:42.621259 trace2/tr2_tgt_perf.c:211 | d0 | main | atexit | | 0.001265 | | | code:0
+------------
+
+=== The Event Format Target
+
+The event format target is a JSON-based format of event data suitable
+for telemetry analysis. This format is enabled with the `GIT_TRACE2_EVENT`
+environment variable or the `trace2.eventTarget` system or global config
+setting.
+
+For example
+
+------------
+$ export GIT_TRACE2_EVENT=~/log.event
+$ git version
+git version 2.20.1.155.g426c96fcdb
+------------
+
+or
+
+------------
+$ git config --global trace2.eventTarget ~/log.event
+$ git version
+git version 2.20.1.155.g426c96fcdb
+------------
+
+yields
+
+------------
+$ cat ~/log.event
+{"event":"version","sid":"20190408T191610.507018Z-H9b68c35f-P000059a8","thread":"main","time":"2019-01-16T17:28:42.620713Z","file":"common-main.c","line":38,"evt":"4","exe":"2.20.1.155.g426c96fcdb"}
+{"event":"start","sid":"20190408T191610.507018Z-H9b68c35f-P000059a8","thread":"main","time":"2019-01-16T17:28:42.621027Z","file":"common-main.c","line":39,"t_abs":0.001173,"argv":["git","version"]}
+{"event":"cmd_name","sid":"20190408T191610.507018Z-H9b68c35f-P000059a8","thread":"main","time":"2019-01-16T17:28:42.621122Z","file":"git.c","line":432,"name":"version","hierarchy":"version"}
+{"event":"exit","sid":"20190408T191610.507018Z-H9b68c35f-P000059a8","thread":"main","time":"2019-01-16T17:28:42.621236Z","file":"git.c","line":662,"t_abs":0.001227,"code":0}
+{"event":"atexit","sid":"20190408T191610.507018Z-H9b68c35f-P000059a8","thread":"main","time":"2019-01-16T17:28:42.621268Z","file":"trace2/tr2_tgt_event.c","line":163,"t_abs":0.001265,"code":0}
+------------
+
+=== Enabling a Target
+
+To enable a target, set the corresponding environment variable or
+system or global config value to one of the following:
+
+include::../trace2-target-values.adoc[]
+
+When trace files are written to a target directory, they will be named according
+to the last component of the SID (optionally followed by a counter to avoid
+filename collisions).
+
+== Trace2 API
+
+The Trace2 public API is defined and documented in `trace2.h`; refer to it for
+more information. All public functions and macros are prefixed
+with `trace2_` and are implemented in `trace2.c`.
+
+There are no public Trace2 data structures.
+
+The Trace2 code also defines a set of private functions and data types
+in the `trace2/` directory. These symbols are prefixed with `tr2_`
+and should only be used by functions in `trace2.c` (or other private
+source files in `trace2/`).
+
+=== Conventions for Public Functions and Macros
+
+Some functions have a `_fl()` suffix to indicate that they take `file`
+and `line-number` arguments.
+
+Some functions have a `_va_fl()` suffix to indicate that they also
+take a `va_list` argument.
+
+Some functions have a `_printf_fl()` suffix to indicate that they also
+take a `printf()` style format with a variable number of arguments.
+
+CPP wrapper macros are defined to hide most of these details.
+
+== Trace2 Target Formats
+
+=== NORMAL Format
+
+Events are written as lines of the form:
+
+------------
+[<time> SP <filename>:<line> SP+] <event-name> [[SP] <event-message>] LF
+------------
+
+`<event-name>`::
+
+ is the event name.
+
+`<event-message>`::
+ is a free-form `printf()` message intended for human consumption.
++
+Note that this may contain embedded LF or CRLF characters that are
+not escaped, so the event may spill across multiple lines.
+
+If `GIT_TRACE2_BRIEF` or `trace2.normalBrief` is true, the `time`, `filename`,
+and `line` fields are omitted.
+
+This target is intended to be more of a summary (like GIT_TRACE) and
+less detailed than the other targets. It ignores thread, region, and
+data messages, for example.
+
+=== PERF Format
+
+Events are written as lines of the form:
+
+------------
+[<time> SP <filename>:<line> SP+
+ BAR SP] d<depth> SP
+ BAR SP <thread-name> SP+
+ BAR SP <event-name> SP+
+ BAR SP [r<repo-id>] SP+
+ BAR SP [<t_abs>] SP+
+ BAR SP [<t_rel>] SP+
+ BAR SP [<category>] SP+
+ BAR SP DOTS* <perf-event-message>
+ LF
+------------
+
+`<depth>`::
+ is the git process depth. This is the number of parent
+ git processes. A top-level git command has depth value "d0".
+ A child of it has depth value "d1". A second level child
+ has depth value "d2" and so on.
+
+`<thread-name>`::
+ is a unique name for the thread. The primary thread
+ is called "main". Other thread names are of the form "th%d:%s"
+ and include a unique number and the name of the thread-proc.
+
+`<event-name>`::
+ is the event name.
+
+`<repo-id>`::
+ when present, is a number indicating the repository
+ in use. A `def_repo` event is emitted when a repository is
+ opened. This defines the repo-id and associated worktree.
+ Subsequent repo-specific events will reference this repo-id.
++
+Currently, this is always "r1" for the main repository.
+This field is in anticipation of in-proc submodules in the future.
+
+`<t_abs>`::
+ when present, is the absolute time in seconds since the
+ program started.
+
+`<t_rel>`::
+ when present, is time in seconds relative to the start of
+ the current region. For a thread-exit event, it is the elapsed
+ time of the thread.
+
+`<category>`::
+ is present on region and data events and is used to
+ indicate a broad category, such as "index" or "status".
+
+`<perf-event-message>`::
+ is a free-form `printf()` message intended for human consumption.
+
+------------
+15:33:33.532712 wt-status.c:2310 | d0 | main | region_enter | r1 | 0.126064 | | status | label:print
+15:33:33.532712 wt-status.c:2331 | d0 | main | region_leave | r1 | 0.127568 | 0.001504 | status | label:print
+------------
+
+If `GIT_TRACE2_PERF_BRIEF` or `trace2.perfBrief` is true, the `time`, `file`,
+and `line` fields are omitted.
+
+------------
+d0 | main | region_leave | r1 | 0.011717 | 0.009122 | index | label:preload
+------------
+
+The PERF target is intended for interactive performance analysis
+during development and is quite noisy.
+
+=== EVENT Format
+
+Each event is a JSON-object containing multiple key/value pairs
+written as a single line and followed by a LF.
+
+------------
+'{' <key> ':' <value> [',' <key> ':' <value>]* '}' LF
+------------
+
+Some key/value pairs are common to all events and some are
+event-specific.
+
+==== Common Key/Value Pairs
+
+The following key/value pairs are common to all events:
+
+------------
+{
+ "event":"version",
+ "sid":"20190408T191827.272759Z-H9b68c35f-P00003510",
+ "thread":"main",
+ "time":"2019-04-08T19:18:27.282761Z",
+ "file":"common-main.c",
+ "line":42,
+ ...
+}
+------------
+
+`"event":<event>`::
+ is the event name.
+
+`"sid":<sid>`::
+ is the session-id. This is a unique string to identify the
+ process instance to allow all events emitted by a process to
+ be identified. A session-id is used instead of a PID because
+ PIDs are recycled by the OS. For child git processes, the
+ session-id is prepended with the session-id of the parent git
+ process to allow parent-child relationships to be identified
+ during post-processing.
+
+`"thread":<thread>`::
+ is the thread name.
+
+`"time":<time>`::
+ is the UTC time of the event.
+
+`"file":<filename>`::
+ is source file generating the event.
+
+`"line":<line-number>`::
+ is the integer source line number generating the event.
+
+`"repo":<repo-id>`::
+ when present, is the integer repo-id as described previously.
+
+If `GIT_TRACE2_EVENT_BRIEF` or `trace2.eventBrief` is true, the `file`
+and `line` fields are omitted from all events and the `time` field is
+only present on the "start" and "atexit" events.
+
+==== Event-Specific Key/Value Pairs
+
+`"version"`::
+ This event gives the version of the executable and the EVENT format. It
+ should always be the first event in a trace session. The EVENT format
+ version will be incremented if new event types are added, if existing
+ fields are removed, or if there are significant changes in
+ interpretation of existing events or fields. Smaller changes, such as
+ adding a new field to an existing event, will not require an increment
+ to the EVENT format version.
++
+------------
+{
+ "event":"version",
+ ...
+ "evt":"4", # EVENT format version
+ "exe":"2.20.1.155.g426c96fcdb" # git version
+}
+------------
+
+`"too_many_files"`::
+ This event is written to the git-trace2-discard sentinel file if there
+ are too many files in the target trace directory (see the
+ trace2.maxFiles config option).
++
+------------
+{
+ "event":"too_many_files",
+ ...
+}
+------------
+
+`"start"`::
+ This event contains the complete argv received by main().
++
+------------
+{
+ "event":"start",
+ ...
+ "t_abs":0.001227, # elapsed time in seconds
+ "argv":["git","version"]
+}
+------------
+
+`"exit"`::
+ This event is emitted when git calls `exit()`.
++
+------------
+{
+ "event":"exit",
+ ...
+ "t_abs":0.001227, # elapsed time in seconds
+ "code":0 # exit code
+}
+------------
+
+`"atexit"`::
+ This event is emitted by the Trace2 `atexit` routine during
+ final shutdown. It should be the last event emitted by the
+ process.
++
+(The elapsed time reported here is greater than the time reported in
+the "exit" event because it runs after all other atexit tasks have
+completed.)
++
+------------
+{
+ "event":"atexit",
+ ...
+ "t_abs":0.001227, # elapsed time in seconds
+ "code":0 # exit code
+}
+------------
+
+`"signal"`::
+ This event is emitted when the program is terminated by a user
+ signal. Depending on the platform, the signal event may
+ prevent the "atexit" event from being generated.
++
+------------
+{
+ "event":"signal",
+ ...
+ "t_abs":0.001227, # elapsed time in seconds
+ "signo":13 # SIGTERM, SIGINT, etc.
+}
+------------
+
+`"error"`::
+ This event is emitted when one of the `BUG()`, `bug()`, `error()`,
+ `die()`, `warning()`, or `usage()` functions are called.
++
+------------
+{
+ "event":"error",
+ ...
+ "msg":"invalid option: --cahced", # formatted error message
+ "fmt":"invalid option: %s" # error format string
+}
+------------
++
+The error event may be emitted more than once. The format string
+allows post-processors to group errors by type without worrying
+about specific error arguments.
+
+`"cmd_path"`::
+ This event contains the discovered full path of the git
+ executable (on platforms that are configured to resolve it).
++
+------------
+{
+ "event":"cmd_path",
+ ...
+ "path":"C:/work/gfw/git.exe"
+}
+------------
+
+`"cmd_ancestry"`::
+ This event contains the text command name for the parent (and earlier
+ generations of parents) of the current process, in an array ordered from
+ nearest parent to furthest great-grandparent. It may not be implemented
+ on all platforms.
++
+------------
+{
+ "event":"cmd_ancestry",
+ ...
+ "ancestry":["bash","tmux: server","systemd"]
+}
+------------
+
+`"cmd_name"`::
+ This event contains the command name for this git process
+ and the hierarchy of commands from parent git processes.
++
+------------
+{
+ "event":"cmd_name",
+ ...
+ "name":"pack-objects",
+ "hierarchy":"push/pack-objects"
+}
+------------
++
+Normally, the "name" field contains the canonical name of the
+command. When a canonical name is not available, one of
+these special values are used:
++
+------------
+"_query_" # "git --html-path"
+"_run_dashed_" # when "git foo" tries to run "git-foo"
+"_run_shell_alias_" # alias expansion to a shell command
+"_run_git_alias_" # alias expansion to a git command
+"_usage_" # usage error
+------------
+
+`"cmd_mode"`::
+ This event, when present, describes the command variant. This
+ event may be emitted more than once.
++
+------------
+{
+ "event":"cmd_mode",
+ ...
+ "name":"branch"
+}
+------------
++
+The "name" field is an arbitrary string to describe the command mode.
+For example, checkout can checkout a branch or an individual file.
+And these variations typically have different performance
+characteristics that are not comparable.
+
+`"alias"`::
+ This event is present when an alias is expanded.
++
+------------
+{
+ "event":"alias",
+ ...
+ "alias":"l", # registered alias
+ "argv":["log","--graph"] # alias expansion
+}
+------------
+
+`"child_start"`::
+ This event describes a child process that is about to be
+ spawned.
++
+------------
+{
+ "event":"child_start",
+ ...
+ "child_id":2,
+ "child_class":"?",
+ "use_shell":false,
+ "argv":["git","rev-list","--objects","--stdin","--not","--all","--quiet"]
+
+ "hook_name":"<hook_name>" # present when child_class is "hook"
+ "cd":"<path>" # present when cd is required
+}
+------------
++
+The "child_id" field can be used to match this child_start with the
+corresponding child_exit event.
++
+The "child_class" field is a rough classification, such as "editor",
+"pager", "transport/*", and "hook". Unclassified children are classified
+with "?".
+
+`"child_exit"`::
+ This event is generated after the current process has returned
+ from the `waitpid()` and collected the exit information from the
+ child.
++
+------------
+{
+ "event":"child_exit",
+ ...
+ "child_id":2,
+ "pid":14708, # child PID
+ "code":0, # child exit-code
+ "t_rel":0.110605 # observed run-time of child process
+}
+------------
++
+Note that the session-id of the child process is not available to
+the current/spawning process, so the child's PID is reported here as
+a hint for post-processing. (But it is only a hint because the child
+process may be a shell script which doesn't have a session-id.)
++
+Note that the `t_rel` field contains the observed run time in seconds
+for the child process (starting before the fork/exec/spawn and
+stopping after the `waitpid()` and includes OS process creation overhead).
+So this time will be slightly larger than the atexit time reported by
+the child process itself.
+
+`"child_ready"`::
+ This event is generated after the current process has started
+ a background process and released all handles to it.
++
+------------
+{
+ "event":"child_ready",
+ ...
+ "child_id":2,
+ "pid":14708, # child PID
+ "ready":"ready", # child ready state
+ "t_rel":0.110605 # observed run-time of child process
+}
+------------
++
+Note that the session-id of the child process is not available to
+the current/spawning process, so the child's PID is reported here as
+a hint for post-processing. (But it is only a hint because the child
+process may be a shell script which doesn't have a session-id.)
++
+This event is generated after the child is started in the background
+and given a little time to boot up and start working. If the child
+starts up normally while the parent is still waiting, the "ready"
+field will have the value "ready".
+If the child is too slow to start and the parent times out, the field
+will have the value "timeout".
+If the child starts but the parent is unable to probe it, the field
+will have the value "error".
++
+After the parent process emits this event, it will release all of its
+handles to the child process and treat the child as a background
+daemon. So even if the child does eventually finish booting up,
+the parent will not emit an updated event.
++
+Note that the `t_rel` field contains the observed run time in seconds
+when the parent released the child process into the background.
+The child is assumed to be a long-running daemon process and may
+outlive the parent process. So the parent's child event times should
+not be compared to the child's atexit times.
+
+`"exec"`::
+ This event is generated before git attempts to `exec()`
+ another command rather than starting a child process.
++
+------------
+{
+ "event":"exec",
+ ...
+ "exec_id":0,
+ "exe":"git",
+ "argv":["foo", "bar"]
+}
+------------
++
+The "exec_id" field is a command-unique id and is only useful if the
+`exec()` fails and a corresponding exec_result event is generated.
+
+`"exec_result"`::
+ This event is generated if the `exec()` fails and control
+ returns to the current git command.
++
+------------
+{
+ "event":"exec_result",
+ ...
+ "exec_id":0,
+ "code":1 # error code (errno) from exec()
+}
+------------
+
+`"thread_start"`::
+ This event is generated when a thread is started. It is
+ generated from *within* the new thread's thread-proc (because
+ it needs to access data in the thread's thread-local storage).
++
+------------
+{
+ "event":"thread_start",
+ ...
+ "thread":"th02:preload_thread" # thread name
+}
+------------
+
+`"thread_exit"`::
+ This event is generated when a thread exits. It is generated
+ from *within* the thread's thread-proc.
++
+------------
+{
+ "event":"thread_exit",
+ ...
+ "thread":"th02:preload_thread", # thread name
+ "t_rel":0.007328 # thread elapsed time
+}
+------------
+
+`"def_param"`::
+ This event is generated to log a global parameter, such as a config
+ setting, command-line flag, or environment variable.
++
+------------
+{
+ "event":"def_param",
+ ...
+ "scope":"global",
+ "param":"core.abbrev",
+ "value":"7"
+}
+------------
+
+`"def_repo"`::
+ This event defines a repo-id and associates it with the root
+ of the worktree.
++
+------------
+{
+ "event":"def_repo",
+ ...
+ "repo":1,
+ "worktree":"/Users/jeffhost/work/gfw"
+}
+------------
++
+As stated earlier, the repo-id is currently always 1, so there will
+only be one def_repo event. Later, if in-proc submodules are
+supported, a def_repo event should be emitted for each submodule
+visited.
+
+`"region_enter"`::
+ This event is generated when entering a region.
++
+------------
+{
+ "event":"region_enter",
+ ...
+ "repo":1, # optional
+ "nesting":1, # current region stack depth
+ "category":"index", # optional
+ "label":"do_read_index", # optional
+ "msg":".git/index" # optional
+}
+------------
++
+The `category` field may be used in a future enhancement to
+do category-based filtering.
++
+`GIT_TRACE2_EVENT_NESTING` or `trace2.eventNesting` can be used to
+filter deeply nested regions and data events. It defaults to "2".
+
+`"region_leave"`::
+ This event is generated when leaving a region.
++
+------------
+{
+ "event":"region_leave",
+ ...
+ "repo":1, # optional
+ "t_rel":0.002876, # time spent in region in seconds
+ "nesting":1, # region stack depth
+ "category":"index", # optional
+ "label":"do_read_index", # optional
+ "msg":".git/index" # optional
+}
+------------
+
+`"data"`::
+ This event is generated to log a thread- and region-local
+ key/value pair.
++
+------------
+{
+ "event":"data",
+ ...
+ "repo":1, # optional
+ "t_abs":0.024107, # absolute elapsed time
+ "t_rel":0.001031, # elapsed time in region/thread
+ "nesting":2, # region stack depth
+ "category":"index",
+ "key":"read/cache_nr",
+ "value":"3552"
+}
+------------
++
+The "value" field may be an integer or a string.
+
+`"data-json"`::
+ This event is generated to log a pre-formatted JSON string
+ containing structured data.
++
+------------
+{
+ "event":"data_json",
+ ...
+ "repo":1, # optional
+ "t_abs":0.015905,
+ "t_rel":0.015905,
+ "nesting":1,
+ "category":"process",
+ "key":"windows/ancestry",
+ "value":["bash.exe","bash.exe"]
+}
+------------
+
+`"th_timer"`::
+ This event logs the amount of time that a stopwatch timer was
+ running in the thread. This event is generated when a thread
+ exits for timers that requested per-thread events.
++
+------------
+{
+ "event":"th_timer",
+ ...
+ "category":"my_category",
+ "name":"my_timer",
+ "intervals":5, # number of time it was started/stopped
+ "t_total":0.052741, # total time in seconds it was running
+ "t_min":0.010061, # shortest interval
+ "t_max":0.011648 # longest interval
+}
+------------
+
+`"timer"`::
+ This event logs the amount of time that a stopwatch timer was
+ running aggregated across all threads. This event is generated
+ when the process exits.
++
+------------
+{
+ "event":"timer",
+ ...
+ "category":"my_category",
+ "name":"my_timer",
+ "intervals":5, # number of time it was started/stopped
+ "t_total":0.052741, # total time in seconds it was running
+ "t_min":0.010061, # shortest interval
+ "t_max":0.011648 # longest interval
+}
+------------
+
+`"th_counter"`::
+ This event logs the value of a counter variable in a thread.
+ This event is generated when a thread exits for counters that
+ requested per-thread events.
++
+------------
+{
+ "event":"th_counter",
+ ...
+ "category":"my_category",
+ "name":"my_counter",
+ "count":23
+}
+------------
+
+`"counter"`::
+ This event logs the value of a counter variable across all threads.
+ This event is generated when the process exits. The total value
+ reported here is the sum across all threads.
++
+------------
+{
+ "event":"counter",
+ ...
+ "category":"my_category",
+ "name":"my_counter",
+ "count":23
+}
+------------
+
+`"printf"`::
+ This event logs a human-readable message with no particular formatting
+ guidelines.
++
+------------
+{
+ "event":"printf",
+ ...
+ "t_abs":0.015905, # elapsed time in seconds
+ "msg":"Hello world" # optional
+}
+------------
+
+
+== Example Trace2 API Usage
+
+Here is a hypothetical usage of the Trace2 API showing the intended
+usage (without worrying about the actual Git details).
+
+Initialization::
+
+ Initialization happens in `main()`. Behind the scenes, an
+ `atexit` and `signal` handler are registered.
++
+----------------
+int main(int argc, const char **argv)
+{
+ int exit_code;
+
+ trace2_initialize();
+ trace2_cmd_start(argv);
+
+ exit_code = cmd_main(argc, argv);
+
+ trace2_cmd_exit(exit_code);
+
+ return exit_code;
+}
+----------------
+
+Command Details::
+
+ After the basics are established, additional command
+ information can be sent to Trace2 as it is discovered.
++
+----------------
+int cmd_checkout(int argc, const char **argv)
+{
+ trace2_cmd_name("checkout");
+ trace2_cmd_mode("branch");
+ trace2_def_repo(the_repository);
+
+ // emit "def_param" messages for "interesting" config settings.
+ trace2_cmd_list_config();
+
+ if (do_something())
+ trace2_cmd_error("Path '%s': cannot do something", path);
+
+ return 0;
+}
+----------------
+
+Child Processes::
+
+ Wrap code spawning child processes.
++
+----------------
+void run_child(...)
+{
+ int child_exit_code;
+ struct child_process cmd = CHILD_PROCESS_INIT;
+ ...
+ cmd.trace2_child_class = "editor";
+
+ trace2_child_start(&cmd);
+ child_exit_code = spawn_child_and_wait_for_it();
+ trace2_child_exit(&cmd, child_exit_code);
+}
+----------------
++
+For example, the following fetch command spawned ssh, index-pack,
+rev-list, and gc. This example also shows that fetch took
+5.199 seconds and of that 4.932 was in ssh.
++
+----------------
+$ export GIT_TRACE2_BRIEF=1
+$ export GIT_TRACE2=~/log.normal
+$ git fetch origin
+...
+----------------
++
+----------------
+$ cat ~/log.normal
+version 2.20.1.vfs.1.1.47.g534dbe1ad1
+start git fetch origin
+worktree /Users/jeffhost/work/gfw
+cmd_name fetch (fetch)
+child_start[0] ssh git@github.com ...
+child_start[1] git index-pack ...
+... (Trace2 events from child processes omitted)
+child_exit[1] pid:14707 code:0 elapsed:0.076353
+child_exit[0] pid:14706 code:0 elapsed:4.931869
+child_start[2] git rev-list ...
+... (Trace2 events from child process omitted)
+child_exit[2] pid:14708 code:0 elapsed:0.110605
+child_start[3] git gc --auto
+... (Trace2 events from child process omitted)
+child_exit[3] pid:14709 code:0 elapsed:0.006240
+exit elapsed:5.198503 code:0
+atexit elapsed:5.198541 code:0
+----------------
++
+When a git process is a (direct or indirect) child of another
+git process, it inherits Trace2 context information. This
+allows the child to print the command hierarchy. This example
+shows gc as child[3] of fetch. When the gc process reports
+its name as "gc", it also reports the hierarchy as "fetch/gc".
+(In this example, trace2 messages from the child process is
+indented for clarity.)
++
+----------------
+$ export GIT_TRACE2_BRIEF=1
+$ export GIT_TRACE2=~/log.normal
+$ git fetch origin
+...
+----------------
++
+----------------
+$ cat ~/log.normal
+version 2.20.1.160.g5676107ecd.dirty
+start git fetch official
+worktree /Users/jeffhost/work/gfw
+cmd_name fetch (fetch)
+...
+child_start[3] git gc --auto
+ version 2.20.1.160.g5676107ecd.dirty
+ start /Users/jeffhost/work/gfw/git gc --auto
+ worktree /Users/jeffhost/work/gfw
+ cmd_name gc (fetch/gc)
+ exit elapsed:0.001959 code:0
+ atexit elapsed:0.001997 code:0
+child_exit[3] pid:20303 code:0 elapsed:0.007564
+exit elapsed:3.868938 code:0
+atexit elapsed:3.868970 code:0
+----------------
+
+Regions::
+
+ Regions can be used to time an interesting section of code.
++
+----------------
+void wt_status_collect(struct wt_status *s)
+{
+ trace2_region_enter("status", "worktrees", s->repo);
+ wt_status_collect_changes_worktree(s);
+ trace2_region_leave("status", "worktrees", s->repo);
+
+ trace2_region_enter("status", "index", s->repo);
+ wt_status_collect_changes_index(s);
+ trace2_region_leave("status", "index", s->repo);
+
+ trace2_region_enter("status", "untracked", s->repo);
+ wt_status_collect_untracked(s);
+ trace2_region_leave("status", "untracked", s->repo);
+}
+
+void wt_status_print(struct wt_status *s)
+{
+ trace2_region_enter("status", "print", s->repo);
+ switch (s->status_format) {
+ ...
+ }
+ trace2_region_leave("status", "print", s->repo);
+}
+----------------
++
+In this example, scanning for untracked files ran from +0.012568 to
++0.027149 (since the process started) and took 0.014581 seconds.
++
+----------------
+$ export GIT_TRACE2_PERF_BRIEF=1
+$ export GIT_TRACE2_PERF=~/log.perf
+$ git status
+...
+
+$ cat ~/log.perf
+d0 | main | version | | | | | 2.20.1.160.g5676107ecd.dirty
+d0 | main | start | | 0.001173 | | | git status
+d0 | main | def_repo | r1 | | | | worktree:/Users/jeffhost/work/gfw
+d0 | main | cmd_name | | | | | status (status)
+...
+d0 | main | region_enter | r1 | 0.010988 | | status | label:worktrees
+d0 | main | region_leave | r1 | 0.011236 | 0.000248 | status | label:worktrees
+d0 | main | region_enter | r1 | 0.011260 | | status | label:index
+d0 | main | region_leave | r1 | 0.012542 | 0.001282 | status | label:index
+d0 | main | region_enter | r1 | 0.012568 | | status | label:untracked
+d0 | main | region_leave | r1 | 0.027149 | 0.014581 | status | label:untracked
+d0 | main | region_enter | r1 | 0.027411 | | status | label:print
+d0 | main | region_leave | r1 | 0.028741 | 0.001330 | status | label:print
+d0 | main | exit | | 0.028778 | | | code:0
+d0 | main | atexit | | 0.028809 | | | code:0
+----------------
++
+Regions may be nested. This causes messages to be indented in the
+PERF target, for example.
+Elapsed times are relative to the start of the corresponding nesting
+level as expected. For example, if we add region message to:
++
+----------------
+static enum path_treatment read_directory_recursive(struct dir_struct *dir,
+ struct index_state *istate, const char *base, int baselen,
+ struct untracked_cache_dir *untracked, int check_only,
+ int stop_at_first_file, const struct pathspec *pathspec)
+{
+ enum path_treatment state, subdir_state, dir_state = path_none;
+
+ trace2_region_enter_printf("dir", "read_recursive", NULL, "%.*s", baselen, base);
+ ...
+ trace2_region_leave_printf("dir", "read_recursive", NULL, "%.*s", baselen, base);
+ return dir_state;
+}
+----------------
++
+We can further investigate the time spent scanning for untracked files.
++
+----------------
+$ export GIT_TRACE2_PERF_BRIEF=1
+$ export GIT_TRACE2_PERF=~/log.perf
+$ git status
+...
+$ cat ~/log.perf
+d0 | main | version | | | | | 2.20.1.162.gb4ccea44db.dirty
+d0 | main | start | | 0.001173 | | | git status
+d0 | main | def_repo | r1 | | | | worktree:/Users/jeffhost/work/gfw
+d0 | main | cmd_name | | | | | status (status)
+...
+d0 | main | region_enter | r1 | 0.015047 | | status | label:untracked
+d0 | main | region_enter | | 0.015132 | | dir | ..label:read_recursive
+d0 | main | region_enter | | 0.016341 | | dir | ....label:read_recursive vcs-svn/
+d0 | main | region_leave | | 0.016422 | 0.000081 | dir | ....label:read_recursive vcs-svn/
+d0 | main | region_enter | | 0.016446 | | dir | ....label:read_recursive xdiff/
+d0 | main | region_leave | | 0.016522 | 0.000076 | dir | ....label:read_recursive xdiff/
+d0 | main | region_enter | | 0.016612 | | dir | ....label:read_recursive git-gui/
+d0 | main | region_enter | | 0.016698 | | dir | ......label:read_recursive git-gui/po/
+d0 | main | region_enter | | 0.016810 | | dir | ........label:read_recursive git-gui/po/glossary/
+d0 | main | region_leave | | 0.016863 | 0.000053 | dir | ........label:read_recursive git-gui/po/glossary/
+...
+d0 | main | region_enter | | 0.031876 | | dir | ....label:read_recursive builtin/
+d0 | main | region_leave | | 0.032270 | 0.000394 | dir | ....label:read_recursive builtin/
+d0 | main | region_leave | | 0.032414 | 0.017282 | dir | ..label:read_recursive
+d0 | main | region_leave | r1 | 0.032454 | 0.017407 | status | label:untracked
+...
+d0 | main | exit | | 0.034279 | | | code:0
+d0 | main | atexit | | 0.034322 | | | code:0
+----------------
++
+Trace2 regions are similar to the existing trace_performance_enter()
+and trace_performance_leave() routines, but are thread safe and
+maintain per-thread stacks of timers.
+
+Data Messages::
+
+ Data messages added to a region.
++
+----------------
+int read_index_from(struct index_state *istate, const char *path,
+ const char *gitdir)
+{
+ trace2_region_enter_printf("index", "do_read_index", the_repository, "%s", path);
+
+ ...
+
+ trace2_data_intmax("index", the_repository, "read/version", istate->version);
+ trace2_data_intmax("index", the_repository, "read/cache_nr", istate->cache_nr);
+
+ trace2_region_leave_printf("index", "do_read_index", the_repository, "%s", path);
+}
+----------------
++
+This example shows that the index contained 3552 entries.
++
+----------------
+$ export GIT_TRACE2_PERF_BRIEF=1
+$ export GIT_TRACE2_PERF=~/log.perf
+$ git status
+...
+$ cat ~/log.perf
+d0 | main | version | | | | | 2.20.1.156.gf9916ae094.dirty
+d0 | main | start | | 0.001173 | | | git status
+d0 | main | def_repo | r1 | | | | worktree:/Users/jeffhost/work/gfw
+d0 | main | cmd_name | | | | | status (status)
+d0 | main | region_enter | r1 | 0.001791 | | index | label:do_read_index .git/index
+d0 | main | data | r1 | 0.002494 | 0.000703 | index | ..read/version:2
+d0 | main | data | r1 | 0.002520 | 0.000729 | index | ..read/cache_nr:3552
+d0 | main | region_leave | r1 | 0.002539 | 0.000748 | index | label:do_read_index .git/index
+...
+----------------
+
+Thread Events::
+
+ Thread messages added to a thread-proc.
++
+For example, the multi-threaded preload-index code can be
+instrumented with a region around the thread pool and then
+per-thread start and exit events within the thread-proc.
++
+----------------
+static void *preload_thread(void *_data)
+{
+ // start the per-thread clock and emit a message.
+ trace2_thread_start("preload_thread");
+
+ // report which chunk of the array this thread was assigned.
+ trace2_data_intmax("index", the_repository, "offset", p->offset);
+ trace2_data_intmax("index", the_repository, "count", nr);
+
+ do {
+ ...
+ } while (--nr > 0);
+ ...
+
+ // report elapsed time taken by this thread.
+ trace2_thread_exit();
+ return NULL;
+}
+
+void preload_index(struct index_state *index,
+ const struct pathspec *pathspec,
+ unsigned int refresh_flags)
+{
+ trace2_region_enter("index", "preload", the_repository);
+
+ for (i = 0; i < threads; i++) {
+ ... /* create thread */
+ }
+
+ for (i = 0; i < threads; i++) {
+ ... /* join thread */
+ }
+
+ trace2_region_leave("index", "preload", the_repository);
+}
+----------------
++
+In this example preload_index() was executed by the `main` thread
+and started the `preload` region. Seven threads, named
+`th01:preload_thread` through `th07:preload_thread`, were started.
+Events from each thread are atomically appended to the shared target
+stream as they occur so they may appear in random order with respect
+other threads. Finally, the main thread waits for the threads to
+finish and leaves the region.
++
+Data events are tagged with the active thread name. They are used
+to report the per-thread parameters.
++
+----------------
+$ export GIT_TRACE2_PERF_BRIEF=1
+$ export GIT_TRACE2_PERF=~/log.perf
+$ git status
+...
+$ cat ~/log.perf
+...
+d0 | main | region_enter | r1 | 0.002595 | | index | label:preload
+d0 | th01:preload_thread | thread_start | | 0.002699 | | |
+d0 | th02:preload_thread | thread_start | | 0.002721 | | |
+d0 | th01:preload_thread | data | r1 | 0.002736 | 0.000037 | index | offset:0
+d0 | th02:preload_thread | data | r1 | 0.002751 | 0.000030 | index | offset:2032
+d0 | th03:preload_thread | thread_start | | 0.002711 | | |
+d0 | th06:preload_thread | thread_start | | 0.002739 | | |
+d0 | th01:preload_thread | data | r1 | 0.002766 | 0.000067 | index | count:508
+d0 | th06:preload_thread | data | r1 | 0.002856 | 0.000117 | index | offset:2540
+d0 | th03:preload_thread | data | r1 | 0.002824 | 0.000113 | index | offset:1016
+d0 | th04:preload_thread | thread_start | | 0.002710 | | |
+d0 | th02:preload_thread | data | r1 | 0.002779 | 0.000058 | index | count:508
+d0 | th06:preload_thread | data | r1 | 0.002966 | 0.000227 | index | count:508
+d0 | th07:preload_thread | thread_start | | 0.002741 | | |
+d0 | th07:preload_thread | data | r1 | 0.003017 | 0.000276 | index | offset:3048
+d0 | th05:preload_thread | thread_start | | 0.002712 | | |
+d0 | th05:preload_thread | data | r1 | 0.003067 | 0.000355 | index | offset:1524
+d0 | th05:preload_thread | data | r1 | 0.003090 | 0.000378 | index | count:508
+d0 | th07:preload_thread | data | r1 | 0.003037 | 0.000296 | index | count:504
+d0 | th03:preload_thread | data | r1 | 0.002971 | 0.000260 | index | count:508
+d0 | th04:preload_thread | data | r1 | 0.002983 | 0.000273 | index | offset:508
+d0 | th04:preload_thread | data | r1 | 0.007311 | 0.004601 | index | count:508
+d0 | th05:preload_thread | thread_exit | | 0.008781 | 0.006069 | |
+d0 | th01:preload_thread | thread_exit | | 0.009561 | 0.006862 | |
+d0 | th03:preload_thread | thread_exit | | 0.009742 | 0.007031 | |
+d0 | th06:preload_thread | thread_exit | | 0.009820 | 0.007081 | |
+d0 | th02:preload_thread | thread_exit | | 0.010274 | 0.007553 | |
+d0 | th07:preload_thread | thread_exit | | 0.010477 | 0.007736 | |
+d0 | th04:preload_thread | thread_exit | | 0.011657 | 0.008947 | |
+d0 | main | region_leave | r1 | 0.011717 | 0.009122 | index | label:preload
+...
+d0 | main | exit | | 0.029996 | | | code:0
+d0 | main | atexit | | 0.030027 | | | code:0
+----------------
++
+In this example, the preload region took 0.009122 seconds. The 7 threads
+took between 0.006069 and 0.008947 seconds to work on their portion of
+the index. Thread "th01" worked on 508 items at offset 0. Thread "th02"
+worked on 508 items at offset 2032. Thread "th04" worked on 508 items
+at offset 508.
++
+This example also shows that thread names are assigned in a racy manner
+as each thread starts.
+
+Config (def param) Events::
+
+ Dump "interesting" config values to trace2 log.
++
+We can optionally emit configuration events, see
+`trace2.configparams` in linkgit:git-config[1] for how to enable
+it.
++
+----------------
+$ git config --system color.ui never
+$ git config --global color.ui always
+$ git config --local color.ui auto
+$ git config --list --show-scope | grep 'color.ui'
+system color.ui=never
+global color.ui=always
+local color.ui=auto
+----------------
++
+Then, mark the config `color.ui` as "interesting" config with
+`GIT_TRACE2_CONFIG_PARAMS`:
++
+----------------
+$ export GIT_TRACE2_PERF_BRIEF=1
+$ export GIT_TRACE2_PERF=~/log.perf
+$ export GIT_TRACE2_CONFIG_PARAMS=color.ui
+$ git version
+...
+$ cat ~/log.perf
+d0 | main | version | | | | | ...
+d0 | main | start | | 0.001642 | | | /usr/local/bin/git version
+d0 | main | cmd_name | | | | | version (version)
+d0 | main | def_param | | | | scope:system | color.ui:never
+d0 | main | def_param | | | | scope:global | color.ui:always
+d0 | main | def_param | | | | scope:local | color.ui:auto
+d0 | main | data | r0 | 0.002100 | 0.002100 | fsync | fsync/writeout-only:0
+d0 | main | data | r0 | 0.002126 | 0.002126 | fsync | fsync/hardware-flush:0
+d0 | main | exit | | 0.000470 | | | code:0
+d0 | main | atexit | | 0.000477 | | | code:0
+----------------
+
+Stopwatch Timer Events::
+
+ Measure the time spent in a function call or span of code
+ that might be called from many places within the code
+ throughout the life of the process.
++
+----------------
+static void expensive_function(void)
+{
+ trace2_timer_start(TRACE2_TIMER_ID_TEST1);
+ ...
+ sleep_millisec(1000); // Do something expensive
+ ...
+ trace2_timer_stop(TRACE2_TIMER_ID_TEST1);
+}
+
+static int ut_100timer(int argc, const char **argv)
+{
+ ...
+
+ expensive_function();
+
+ // Do something else 1...
+
+ expensive_function();
+
+ // Do something else 2...
+
+ expensive_function();
+
+ return 0;
+}
+----------------
++
+In this example, we measure the total time spent in
+`expensive_function()` regardless of when it is called
+in the overall flow of the program.
++
+----------------
+$ export GIT_TRACE2_PERF_BRIEF=1
+$ export GIT_TRACE2_PERF=~/log.perf
+$ t/helper/test-tool trace2 100timer 3 1000
+...
+$ cat ~/log.perf
+d0 | main | version | | | | | ...
+d0 | main | start | | 0.001453 | | | t/helper/test-tool trace2 100timer 3 1000
+d0 | main | cmd_name | | | | | trace2 (trace2)
+d0 | main | exit | | 3.003667 | | | code:0
+d0 | main | timer | | | | test | name:test1 intervals:3 total:3.001686 min:1.000254 max:1.000929
+d0 | main | atexit | | 3.003796 | | | code:0
+----------------
+
+
+== Future Work
+
+=== Relationship to the Existing Trace Api (api-trace.txt)
+
+There are a few issues to resolve before we can completely
+switch to Trace2.
+
+* Updating existing tests that assume `GIT_TRACE` format messages.
+
+* How to best handle custom `GIT_TRACE_<key>` messages?
+
+** The `GIT_TRACE_<key>` mechanism allows each <key> to write to a
+different file (in addition to just stderr).
+
+** Do we want to maintain that ability or simply write to the existing
+Trace2 targets (and convert <key> to a "category").
diff --git a/technical/bitmap-format.adoc b/technical/bitmap-format.adoc
new file mode 100644
index 0000000..bfb0ec7
--- /dev/null
+++ b/technical/bitmap-format.adoc
@@ -0,0 +1,398 @@
+GIT bitmap v1 format
+====================
+
+== Pack and multi-pack bitmaps
+
+Bitmaps store reachability information about the set of objects in a packfile,
+or a multi-pack index (MIDX). The former is defined obviously, and the latter is
+defined as the union of objects in packs contained in the MIDX.
+
+A bitmap may belong to either one pack, or the repository's multi-pack index (if
+it exists). A repository may have at most one bitmap.
+
+An object is uniquely described by its bit position within a bitmap:
+
+ - If the bitmap belongs to a packfile, the __n__th bit corresponds to
+ the __n__th object in pack order. For a function `offset` which maps
+ objects to their byte offset within a pack, pack order is defined as
+ follows:
+
+ o1 <= o2 <==> offset(o1) <= offset(o2)
+
+ - If the bitmap belongs to a MIDX, the __n__th bit corresponds to the
+ __n__th object in MIDX order. With an additional function `pack` which
+ maps objects to the pack they were selected from by the MIDX, MIDX order
+ is defined as follows:
+
+ o1 <= o2 <==> pack(o1) <= pack(o2) /\ offset(o1) <= offset(o2)
++
+The ordering between packs is done according to the MIDX's .rev file.
+Notably, the preferred pack sorts ahead of all other packs.
+
+The on-disk representation (described below) of a bitmap is the same regardless
+of whether or not that bitmap belongs to a packfile or a MIDX. The only
+difference is the interpretation of the bits, which is described above.
+
+Certain bitmap extensions are supported (see: Appendix B). No extensions are
+required for bitmaps corresponding to packfiles. For bitmaps that correspond to
+MIDXs, both the bit-cache and rev-cache extensions are required.
+
+== On-disk format
+
+ * A header appears at the beginning:
+
+ 4-byte signature: :: {'B', 'I', 'T', 'M'}
+
+ 2-byte version number (network byte order): ::
+
+ The current implementation only supports version 1
+ of the bitmap index (the same one as JGit).
+
+ 2-byte flags (network byte order): ::
+
+ The following flags are supported:
+
+ ** {empty}
+ BITMAP_OPT_FULL_DAG (0x1) REQUIRED: :::
+
+ This flag must always be present. It implies that the
+ bitmap index has been generated for a packfile or
+ multi-pack index (MIDX) with full closure (i.e. where
+ every single object in the packfile/MIDX can find its
+ parent links inside the same packfile/MIDX). This is a
+ requirement for the bitmap index format, also present in
+ JGit, that greatly reduces the complexity of the
+ implementation.
+
+ ** {empty}
+ BITMAP_OPT_HASH_CACHE (0x4): :::
+
+ If present, the end of the bitmap file contains
+ `N` 32-bit name-hash values, one per object in the
+ pack/MIDX. The format and meaning of the name-hash is
+ described below.
+
+ ** {empty}
+ BITMAP_OPT_LOOKUP_TABLE (0x10): :::
+ If present, the end of the bitmap file contains a table
+ containing a list of `N` <commit_pos, offset, xor_row>
+ triplets. The format and meaning of the table is described
+ below.
++
+NOTE: Unlike the xor_offset used to compress an individual bitmap,
+`xor_row` stores an *absolute* index into the lookup table, not a location
+relative to the current entry.
+
+ 4-byte entry count (network byte order): ::
+ The total count of entries (bitmapped commits) in this bitmap index.
+
+ 20-byte checksum: ::
+ The SHA1 checksum of the pack/MIDX this bitmap index
+ belongs to.
+
+ * 4 EWAH bitmaps that act as type indexes
++
+Type indexes are serialized after the hash cache in the shape
+of four EWAH bitmaps stored consecutively (see Appendix A for
+the serialization format of an EWAH bitmap).
++
+There is a bitmap for each Git object type, stored in the following
+order:
++
+ - Commits
+ - Trees
+ - Blobs
+ - Tags
+
++
+In each bitmap, the `n`th bit is set to true if the `n`th object
+in the packfile or multi-pack index is of that type.
++
+The obvious consequence is that the OR of all 4 bitmaps will result
+in a full set (all bits set), and the AND of all 4 bitmaps will
+result in an empty bitmap (no bits set).
+
+ * N entries with compressed bitmaps, one for each indexed commit
++
+Where `N` is the total number of entries in this bitmap index.
+Each entry contains the following:
+
+ ** {empty}
+ 4-byte object position (network byte order): ::
+ The position **in the index for the packfile or
+ multi-pack index** where the bitmap for this commit is
+ found.
+
+ ** {empty}
+ 1-byte XOR-offset: ::
+ The xor offset used to compress this bitmap. For an entry
+ in position `x`, an XOR offset of `y` means that the actual
+ bitmap representing this commit is composed by XORing the
+ bitmap for this entry with the bitmap in entry `x-y` (i.e.
+ the bitmap `y` entries before this one).
++
+NOTE: This compression can be recursive. In order to
+XOR this entry with a previous one, the previous entry needs
+to be decompressed first, and so on.
++
+The hard-limit for this offset is 160 (an entry can only be
+xor'ed against one of the 160 entries preceding it). This
+number is always positive, and hence entries are always xor'ed
+with **previous** bitmaps, not bitmaps that will come afterwards
+in the index.
+
+ ** {empty}
+ 1-byte flags for this bitmap: ::
+ At the moment the only available flag is `0x1`, which hints
+ that this bitmap can be re-used when rebuilding bitmap indexes
+ for the repository.
+
+ ** The compressed bitmap itself, see Appendix A.
+
+ * {empty}
+ TRAILER: ::
+ Trailing checksum of the preceding contents.
+
+== Appendix A: Serialization format for an EWAH bitmap
+
+Ewah bitmaps are serialized in the same protocol as the JAVAEWAH
+library, making them backwards compatible with the JGit
+implementation:
+
+ - 4-byte number of bits of the resulting UNCOMPRESSED bitmap
+
+ - 4-byte number of words of the COMPRESSED bitmap, when stored
+
+ - N x 8-byte words, as specified by the previous field
++
+This is the actual content of the compressed bitmap.
+
+ - 4-byte position of the current RLW for the compressed
+ bitmap
+
+All words are stored in network byte order for their corresponding
+sizes.
+
+The compressed bitmap is stored in a form of run-length encoding, as
+follows. It consists of a concatenation of an arbitrary number of
+chunks. Each chunk consists of one or more 64-bit words
+
+ H L_1 L_2 L_3 .... L_M
+
+H is called RLW (run length word). It consists of (from lower to higher
+order bits):
+
+ - 1 bit: the repeated bit B
+
+ - 32 bits: repetition count K (unsigned)
+
+ - 31 bits: literal word count M (unsigned)
+
+The bitstream represented by the above chunk is then:
+
+ - K repetitions of B
+
+ - The bits stored in `L_1` through `L_M`. Within a word, bits at
+ lower order come earlier in the stream than those at higher
+ order.
+
+The next word after `L_M` (if any) must again be a RLW, for the next
+chunk. For efficient appending to the bitstream, the EWAH stores a
+pointer to the last RLW in the stream.
+
+
+== Appendix B: Optional Bitmap Sections
+
+These sections may or may not be present in the `.bitmap` file; their
+presence is indicated by the header flags section described above.
+
+Name-hash cache
+---------------
+
+If the BITMAP_OPT_HASH_CACHE flag is set, the end of the bitmap contains
+a cache of 32-bit values, one per object in the pack/MIDX. The value at
+position `i` is the hash of the pathname at which the `i`th object
+(counting in index or multi-pack index order) in the pack/MIDX can be found.
+This can be fed into the delta heuristics to compare objects with similar
+pathnames.
+
+The hash algorithm used is:
+
+ hash = 0;
+ while ((c = *name++))
+ if (!isspace(c))
+ hash = (hash >> 2) + (c << 24);
+
+Note that this hashing scheme is tied to the BITMAP_OPT_HASH_CACHE flag.
+If implementations want to choose a different hashing scheme, they are
+free to do so, but MUST allocate a new header flag (because comparing
+hashes made under two different schemes would be pointless).
+
+Commit lookup table
+-------------------
+
+If the BITMAP_OPT_LOOKUP_TABLE flag is set, the last `N * (4 + 8 + 4)`
+bytes (preceding the name-hash cache and trailing hash) of the `.bitmap`
+file contains a lookup table specifying the information needed to get
+the desired bitmap from the entries without parsing previous unnecessary
+bitmaps.
+
+For a `.bitmap` containing `nr_entries` reachability bitmaps, the table
+contains a list of `nr_entries` <commit_pos, offset, xor_row> triplets
+(sorted in the ascending order of `commit_pos`). The content of the i'th
+triplet is -
+
+ * {empty}
+ commit_pos (4 byte integer, network byte order): ::
+ It stores the object position of a commit (in the midx or pack
+ index).
+
+ * {empty}
+ offset (8 byte integer, network byte order): ::
+ The offset from which that commit's bitmap can be read.
+
+ * {empty}
+ xor_row (4 byte integer, network byte order): ::
+ The position of the triplet whose bitmap is used to compress
+ this one, or `0xffffffff` if no such bitmap exists.
+
+Pseudo-merge bitmaps
+--------------------
+
+If the `BITMAP_OPT_PSEUDO_MERGES` flag is set, a variable number of
+bytes (preceding the name-hash cache, commit lookup table, and trailing
+checksum) of the `.bitmap` file is used to store pseudo-merge bitmaps.
+
+For more information on what pseudo-merges are, why they are useful, and
+how to configure them, see the information in linkgit:gitpacking[7].
+
+=== File format
+
+If enabled, pseudo-merge bitmaps are stored in an optional section at
+the end of a `.bitmap` file. The format is as follows:
+
+....
++-------------------------------------------+
+| .bitmap File |
++-------------------------------------------+
+| |
+| Pseudo-merge bitmaps (Variable Length) |
+| +---------------------------+ |
+| | commits_bitmap (EWAH) | |
+| +---------------------------+ |
+| | merge_bitmap (EWAH) | |
+| +---------------------------+ |
+| |
++-------------------------------------------+
+| |
+| Lookup Table |
+| +---------------------------+ |
+| | commit_pos (4 bytes) | |
+| +---------------------------+ |
+| | offset (8 bytes) | |
+| +------------+--------------+ |
+| |
+| Offset Cases: |
+| ------------- |
+| |
+| 1. MSB Unset: single pseudo-merge bitmap |
+| + offset to pseudo-merge bitmap |
+| |
+| 2. MSB Set: multiple pseudo-merges |
+| + offset to extended lookup table |
+| |
++-------------------------------------------+
+| |
+| Extended Lookup Table (Optional) |
+| +----+----------+----------+----------+ |
+| | N | Offset 1 | .... | Offset N | |
+| +----+----------+----------+----------+ |
+| | | 8 bytes | .... | 8 bytes | |
+| +----+----------+----------+----------+ |
+| |
++-------------------------------------------+
+| |
+| Pseudo-merge position table |
+| +----+----------+----------+----------+ |
+| | N | Offset 1 | .... | Offset N | |
+| +----+----------+----------+----------+ |
+| | | 8 bytes | .... | 8 bytes | |
+| +----+----------+----------+----------+ |
+| |
++-------------------------------------------+
+| |
+| Pseudo-merge Metadata |
+| +-----------------------------------+ |
+| | # pseudo-merges (4 bytes) | |
+| +-----------------------------------+ |
+| | # commits (4 bytes) | |
+| +-----------------------------------+ |
+| | Lookup offset (8 bytes) | |
+| +-----------------------------------+ |
+| | Extension size (8 bytes) | |
+| +-----------------------------------+ |
+| |
++-------------------------------------------+
+....
+
+* One or more pseudo-merge bitmaps, each containing:
+
+ ** `commits_bitmap`, an EWAH-compressed bitmap describing the set of
+ commits included in the this psuedo-merge.
+
+ ** `merge_bitmap`, an EWAH-compressed bitmap describing the union of
+ the set of objects reachable from all commits listed in the
+ `commits_bitmap`.
+
+* A lookup table, mapping pseudo-merged commits to the pseudo-merges
+ they belong to. Entries appear in increasing order of each commit's
+ bit position. Each entry is 12 bytes wide, and is comprised of the
+ following:
+
+ ** `commit_pos`, a 4-byte unsigned value (in network byte-order)
+ containing the bit position for this commit.
+
+ ** `offset`, an 8-byte unsigned value (also in network byte-order)
+ containing either one of two possible offsets, depending on whether or
+ not the most-significant bit is set.
+
+ *** If unset (i.e. `offset & ((uint64_t)1<<63) == 0`), the offset
+ (relative to the beginning of the `.bitmap` file) at which the
+ pseudo-merge bitmap for this commit can be read. This indicates
+ only a single pseudo-merge bitmap contains this commit.
+
+ *** If set (i.e. `offset & ((uint64_t)1<<63) != 0`), the offset
+ (again relative to the beginning of the `.bitmap` file) at which
+ the extended offset table can be located describing the set of
+ pseudo-merge bitmaps which contain this commit. This indicates
+ that multiple pseudo-merge bitmaps contain this commit.
+
+* An (optional) extended lookup table (written if and only if there is
+ at least one commit which appears in more than one pseudo-merge).
+ There are as many entries as commits which appear in multiple
+ pseudo-merges. Each entry contains the following:
+
+ ** `N`, a 4-byte unsigned value equal to the number of pseudo-merges
+ which contain a given commit.
+
+ ** An array of `N` 8-byte unsigned values, each of which is
+ interpreted as an offset (relative to the beginning of the
+ `.bitmap` file) at which a pseudo-merge bitmap for this commit can
+ be read. These values occur in no particular order.
+
+* Positions for all pseudo-merges, each stored as an 8-byte unsigned
+ value (in network byte-order) containing the offset (relative to the
+ beginning of the `.bitmap` file) of each consecutive pseudo-merge.
+
+* A 4-byte unsigned value (in network byte-order) equal to the number of
+ pseudo-merges.
+
+* A 4-byte unsigned value (in network byte-order) equal to the number of
+ unique commits which appear in any pseudo-merge.
+
+* An 8-byte unsigned value (in network byte-order) equal to the number
+ of bytes between the start of the pseudo-merge section and the
+ beginning of the lookup table.
+
+* An 8-byte unsigned value (in network byte-order) equal to the number
+ of bytes in the pseudo-merge section (including this field).
diff --git a/technical/build-systems.adoc b/technical/build-systems.adoc
new file mode 100644
index 0000000..d9dafb4
--- /dev/null
+++ b/technical/build-systems.adoc
@@ -0,0 +1,224 @@
+= Build Systems
+
+The build system is the primary way for both developers and system integrators
+to interact with the Git project. As such, being easy to use and extend for
+those who are not directly developing Git itself is just as important as other
+requirements we have on any potential build system.
+
+This document outlines the different requirements that we have for the build
+system and then compares available build systems using these criteria.
+
+== Requirements
+
+The following subsections present a list of requirements that we have for any
+potential build system. Sections are sorted by decreasing priority.
+
+=== Platform support
+
+The build system must have support for all of our platforms that we continually
+test against as outlined by our platform support policy. These platforms are:
+
+ - Linux
+ - Windows
+ - macOS
+
+Furthermore, the build system should have support for the following platforms
+that generally have somebody running test pipelines against regularly:
+
+ - AIX
+ - FreeBSD
+ - NetBSD
+ - NonStop
+ - OpenBSD
+
+The platforms which must be supported by the tool should be aligned with our
+[platform support policy](platform-support.txt).
+
+=== Auto-detection of supported features
+
+The build system must support auto-detection of features which are or aren't
+available on the current platform. Platform maintainers should not be required
+to manually configure the complete build.
+
+Auto-detection of the following items is considered to be important:
+
+ - Check for the existence of headers.
+ - Check for the existence of libraries.
+ - Check for the existence of exectuables.
+ - Check for the runtime behavior of specific functions.
+ - Check for specific link order requirements when multiple libraries are
+ involved.
+
+=== Ease of use
+
+The build system should be both easy to use and easy to extend. While this is
+naturally a subjective metric it is likely not controversial to say that some
+build systems are considerably harder to use than others.
+
+=== IDE support
+
+The build system should integrate with well-known IDEs. Well-known IDEs include:
+
+ - Microsoft Visual Studio
+ - Visual Studio Code
+ - Xcode
+
+There are four levels of support:
+
+ - Native integration into the IDE.
+ - Integration into the IDE via a plugin.
+ - Integration into the IDE via generating a project description with the build
+ system.
+ - No integration.
+
+Native integration is preferable, but integration via either a plugin or by
+generating a project description via the build system are considered feasible
+alternatives.
+
+Another important distinction is the level of integration. There are two
+features that one generally wants to have:
+
+ - Integration of build targets.
+ - Automatic setup of features like code completion with detected build
+ dependencies.
+
+The first bullet point is the bare minimum, but is not sufficient to be
+considered proper integration.
+
+=== Out-of-tree builds
+
+The build system should support out-of-tree builds. Out-of-tree builds allow a
+developer to configure multiple different build directories with different
+configuration, e.g. one "debug" build and one "release" build.
+
+=== Cross-platform builds
+
+The build system should support cross-platform builds, e.g. building for arm on
+an x86-64 host.
+
+=== Language support
+
+The following languages and toolchains are of relevance and should be supported
+by the build system:
+
+ - C: the primary compiled language used by Git, must be supported. Relevant
+ toolchains are GCC, Clang and MSVC.
+ - Rust: candidate as a second compiled lanugage, should be supported. Relevant
+ toolchains is the LLVM-based rustc.
+
+Built-in support for the respective languages is preferred over support that
+needs to be wired up manually to avoid unnecessary complexity. Native support
+includes the following features:
+
+ - Compiling objects.
+ - Dependency tracking.
+ - Detection of available features.
+ - Discovery of relevant toolchains.
+ - Linking libraries and executables.
+ - Templating placeholders in scripts.
+
+=== Test integration
+
+It should be possible to integrate tests into the build system such that it is
+possible to build and test Git within the build system. Features which are nice
+to have:
+
+ - Track build-time dependencies for respective tests. Unit tests have
+ different requirements than integration tests.
+ - Allow filtering of which tests to run.
+ - Allow running tests such that utilities like `test_pause` or `debug` work.
+
+== Comparison
+
+The following list of build systems are considered:
+
+- GNU Make
+- autoconf
+- CMake
+- Meson
+
+=== GNU Make
+
+- Platform support: ubitquitous on all platforms, but not well-integrated into Windows.
+- Auto-detection: no built-in support for auto-detection of features.
+- Ease of use: easy to use, but discovering available options is hard. Makefile
+ rules can quickly get out of hand once reaching a certain scope.
+- IDE support: execution of Makefile targets is supported by many IDEs
+- Out-of-tree builds: supported in theory, not wired up in practice.
+- Cross-platform builds: supported in theory, not wired up in practice.
+- Language support:
+ - C: Limited built-in support, many parts need to be wired up manually.
+ - Rust: No built-in support, needs to be wired up manually.
+- Test integration: partially supported, many parts need to be wired up
+ manually.
+
+=== autoconf
+
+- Platform support: ubiquitous on all platforms, but not well-integrated into Windows.
+- Auto-detection: supported.
+- Ease of use: easy to use, discovering available options is comparatively
+ easy. The autoconf syntax is prohibitively hard to extend though due to its
+ complex set of interacting files and the hard-to-understand M4 language.
+- IDE support: no integration into IDEs at generation time. The generated
+ Makefiles have the same level of support as GNU Make.
+- Out-of-tree builds: supported in theory, not wired up in practice.
+- Cross-platform builds: supported.
+- Language support:
+ - C: Limited built-in support, many parts need to be wired up manually.
+ - Rust: No built-in support, needs to be wired up manually.
+- Test integration: partially supported, many parts need to be wired up
+ manually.
+
+=== CMake
+
+- Platform support: not as extensive as GNU Make or autoconf, but all major
+ platforms are supported.
+ - AIX
+ - Cygwin
+ - FreeBSD
+ - Linux
+ - OpenBSD
+ - Solaris
+ - Windows
+ - macOS
+- Ease of use: easy to use, discovering available options is not always
+ trivial. The scripting language used by CMake is somewhat cumbersome to use,
+ but extending CMake build instructions is doable.
+- IDE support: natively integrated into Microsoft Visual Studio. Can generate
+ project descriptions for Xcode. An extension is available for Visual Studio
+ Code. Many other IDEs have plugins for CMake.
+- Out-of-tree builds: supported.
+- Cross-platform builds: supported.
+- Language support:
+ - C: Supported for GCC, Clang, MSVC and other toolchains.
+ - Rust: No built-in support, needs to be wired up manually.
+- Test integration: supported, even though test dependencies are a bit
+ cumbersome to use via "test fixtures". Interactive test runs are not
+ supported.
+
+=== Meson
+
+- Platform: not as extensive as GNU Make or autoconf, but all major platforms
+ and some smaller ones are supported.
+ - AIX
+ - Cygwin
+ - DragonflyBSD
+ - FreeBSD
+ - Haiku
+ - Linux
+ - NetBSD
+ - OpenBSD
+ - Solaris
+ - Windows
+ - macOS
+- Ease of use: easy to use, discovering available options is easy. The
+ scripting language is straight-forward to use.
+- IDE support: Supports generating build instructions for Xcode and Microsoft
+ Visual Studio, a plugin exists for Visual Studio Code.
+- Out-of-tree builds: supported.
+- Cross-platform builds: supported.
+- Language support:
+ - C: Supported for GCC, Clang, MSVC and other toolchains.
+ - Rust: Supported for rustc.
+- Test integration: supported. Interactive tests are supported starting with
+ Meson 1.5.0 via the `--interactive` flag.
diff --git a/technical/bundle-uri.adoc b/technical/bundle-uri.adoc
new file mode 100644
index 0000000..91d3a13
--- /dev/null
+++ b/technical/bundle-uri.adoc
@@ -0,0 +1,572 @@
+Bundle URIs
+===========
+
+Git bundles are files that store a pack-file along with some extra metadata,
+including a set of refs and a (possibly empty) set of necessary commits. See
+linkgit:git-bundle[1] and linkgit:gitformat-bundle[5] for more information.
+
+Bundle URIs are locations where Git can download one or more bundles in
+order to bootstrap the object database in advance of fetching the remaining
+objects from a remote.
+
+One goal is to speed up clones and fetches for users with poor network
+connectivity to the origin server. Another benefit is to allow heavy users,
+such as CI build farms, to use local resources for the majority of Git data
+and thereby reducing the load on the origin server.
+
+To enable the bundle URI feature, users can specify a bundle URI using
+command-line options or the origin server can advertise one or more URIs
+via a protocol v2 capability.
+
+Design Goals
+------------
+
+The bundle URI standard aims to be flexible enough to satisfy multiple
+workloads. The bundle provider and the Git client have several choices in
+how they create and consume bundle URIs.
+
+* Bundles can have whatever name the server desires. This name could refer
+ to immutable data by using a hash of the bundle contents. However, this
+ means that a new URI will be needed after every update of the content.
+ This might be acceptable if the server is advertising the URI (and the
+ server is aware of new bundles being generated) but would not be
+ ergonomic for users using the command line option.
+
+* The bundles could be organized specifically for bootstrapping full
+ clones, but could also be organized with the intention of bootstrapping
+ incremental fetches. The bundle provider must decide on one of several
+ organization schemes to minimize client downloads during incremental
+ fetches, but the Git client can also choose whether to use bundles for
+ either of these operations.
+
+* The bundle provider can choose to support full clones, partial clones,
+ or both. The client can detect which bundles are appropriate for the
+ repository's partial clone filter, if any.
+
+* The bundle provider can use a single bundle (for clones only), or a
+ list of bundles. When using a list of bundles, the provider can specify
+ whether or not the client needs _all_ of the bundle URIs for a full
+ clone, or if _any_ one of the bundle URIs is sufficient. This allows the
+ bundle provider to use different URIs for different geographies.
+
+* The bundle provider can organize the bundles using heuristics, such as
+ creation tokens, to help the client prevent downloading bundles it does
+ not need. When the bundle provider does not provide these heuristics,
+ the client can use optimizations to minimize how much of the data is
+ downloaded.
+
+* The bundle provider does not need to be associated with the Git server.
+ The client can choose to use the bundle provider without it being
+ advertised by the Git server.
+
+* The client can choose to discover bundle providers that are advertised
+ by the Git server. This could happen during `git clone`, during
+ `git fetch`, both, or neither. The user can choose which combination
+ works best for them.
+
+* The client can choose to configure a bundle provider manually at any
+ time. The client can also choose to specify a bundle provider manually
+ as a command-line option to `git clone`.
+
+Each repository is different and every Git server has different needs.
+Hopefully the bundle URI feature is flexible enough to satisfy all needs.
+If not, then the feature can be extended through its versioning mechanism.
+
+Server requirements
+-------------------
+
+To provide a server-side implementation of bundle servers, no other parts
+of the Git protocol are required. This allows server maintainers to use
+static content solutions such as CDNs in order to serve the bundle files.
+
+At the current scope of the bundle URI feature, all URIs are expected to
+be HTTP(S) URLs where content is downloaded to a local file using a `GET`
+request to that URL. The server could include authentication requirements
+to those requests with the aim of triggering the configured credential
+helper for secure access. (Future extensions could use "file://" URIs or
+SSH URIs.)
+
+Assuming a `200 OK` response from the server, the content at the URL is
+inspected. First, Git attempts to parse the file as a bundle file of
+version 2 or higher. If the file is not a bundle, then the file is parsed
+as a plain-text file using Git's config parser. The key-value pairs in
+that config file are expected to describe a list of bundle URIs. If
+neither of these parse attempts succeed, then Git will report an error to
+the user that the bundle URI provided erroneous data.
+
+Any other data provided by the server is considered erroneous.
+
+Bundle Lists
+------------
+
+The Git server can advertise bundle URIs using a set of `key=value` pairs.
+A bundle URI can also serve a plain-text file in the Git config format
+containing these same `key=value` pairs. In both cases, we consider this
+to be a _bundle list_. The pairs specify information about the bundles
+that the client can use to make decisions for which bundles to download
+and which to ignore.
+
+A few keys focus on properties of the list itself.
+
+bundle.version::
+ (Required) This value provides a version number for the bundle
+ list. If a future Git change enables a feature that needs the Git
+ client to react to a new key in the bundle list file, then this version
+ will increment. The only current version number is 1, and if any other
+ value is specified then Git will fail to use this file.
+
+bundle.mode::
+ (Required) This value has one of two values: `all` and `any`. When `all`
+ is specified, then the client should expect to need all of the listed
+ bundle URIs that match their repository's requirements. When `any` is
+ specified, then the client should expect that any one of the bundle URIs
+ that match their repository's requirements will suffice. Typically, the
+ `any` option is used to list a number of different bundle servers
+ located in different geographies.
+
+bundle.heuristic::
+ If this string-valued key exists, then the bundle list is designed to
+ work well with incremental `git fetch` commands. The heuristic signals
+ that there are additional keys available for each bundle that help
+ determine which subset of bundles the client should download. The only
+ heuristic currently planned is `creationToken`.
+
+The remaining keys include an `<id>` segment which is a server-designated
+name for each available bundle. The `<id>` must contain only alphanumeric
+and `-` characters.
+
+bundle.<id>.uri::
+ (Required) This string value is the URI for downloading bundle `<id>`.
+ If the URI begins with a protocol (`http://` or `https://`) then the URI
+ is absolute. Otherwise, the URI is interpreted as relative to the URI
+ used for the bundle list. If the URI begins with `/`, then that relative
+ path is relative to the domain name used for the bundle list. (This use
+ of relative paths is intended to make it easier to distribute a set of
+ bundles across a large number of servers or CDNs with different domain
+ names.)
+
+bundle.<id>.filter::
+ This string value represents an object filter that should also appear in
+ the header of this bundle. The server uses this value to differentiate
+ different kinds of bundles from which the client can choose those that
+ match their object filters.
+
+bundle.<id>.creationToken::
+ This value is a nonnegative 64-bit integer used for sorting the bundles
+ list. This is used to download a subset of bundles during a fetch when
+ `bundle.heuristic=creationToken`.
+
+bundle.<id>.location::
+ This string value advertises a real-world location from where the bundle
+ URI is served. This can be used to present the user with an option for
+ which bundle URI to use or simply as an informative indicator of which
+ bundle URI was selected by Git. This is only valuable when
+ `bundle.mode` is `any`.
+
+Here is an example bundle list using the Git config format:
+
+ [bundle]
+ version = 1
+ mode = all
+ heuristic = creationToken
+
+ [bundle "2022-02-09-1644442601-daily"]
+ uri = https://bundles.example.com/git/git/2022-02-09-1644442601-daily.bundle
+ creationToken = 1644442601
+
+ [bundle "2022-02-02-1643842562"]
+ uri = https://bundles.example.com/git/git/2022-02-02-1643842562.bundle
+ creationToken = 1643842562
+
+ [bundle "2022-02-09-1644442631-daily-blobless"]
+ uri = 2022-02-09-1644442631-daily-blobless.bundle
+ creationToken = 1644442631
+ filter = blob:none
+
+ [bundle "2022-02-02-1643842568-blobless"]
+ uri = /git/git/2022-02-02-1643842568-blobless.bundle
+ creationToken = 1643842568
+ filter = blob:none
+
+This example uses `bundle.mode=all` as well as the
+`bundle.<id>.creationToken` heuristic. It also uses the `bundle.<id>.filter`
+options to present two parallel sets of bundles: one for full clones and
+another for blobless partial clones.
+
+Suppose that this bundle list was found at the URI
+`https://bundles.example.com/git/git/` and so the two blobless bundles have
+the following fully-expanded URIs:
+
+* `https://bundles.example.com/git/git/2022-02-09-1644442631-daily-blobless.bundle`
+* `https://bundles.example.com/git/git/2022-02-02-1643842568-blobless.bundle`
+
+Advertising Bundle URIs
+-----------------------
+
+If a user knows a bundle URI for the repository they are cloning, then
+they can specify that URI manually through a command-line option. However,
+a Git host may want to advertise bundle URIs during the clone operation,
+helping users unaware of the feature.
+
+The only thing required for this feature is that the server can advertise
+one or more bundle URIs. This advertisement takes the form of a new
+protocol v2 capability specifically for discovering bundle URIs.
+
+The client could choose an arbitrary bundle URI as an option _or_ select
+the URI with best performance by some exploratory checks. It is up to the
+bundle provider to decide if having multiple URIs is preferable to a
+single URI that is geodistributed through server-side infrastructure.
+
+Cloning with Bundle URIs
+------------------------
+
+The primary need for bundle URIs is to speed up clones. The Git client
+will interact with bundle URIs according to the following flow:
+
+1. The user specifies a bundle URI with the `--bundle-uri` command-line
+ option _or_ the client discovers a bundle list advertised by the
+ Git server.
+
+2. If the downloaded data from a bundle URI is a bundle, then the client
+ inspects the bundle headers to check that the prerequisite commit OIDs
+ are present in the client repository. If some are missing, then the
+ client delays unbundling until other bundles have been unbundled,
+ making those OIDs present. When all required OIDs are present, the
+ client unbundles that data using a refspec. The default refspec is
+ `+refs/heads/*:refs/bundles/*`, but this can be configured. These refs
+ are stored so that later `git fetch` negotiations can communicate each
+ bundled ref as a `have`, reducing the size of the fetch over the Git
+ protocol. To allow pruning refs from this ref namespace, Git may
+ introduce a numbered namespace (such as `refs/bundles/<i>/*`) such that
+ stale bundle refs can be deleted.
+
+3. If the file is instead a bundle list, then the client inspects the
+ `bundle.mode` to see if the list is of the `all` or `any` form.
+
+ a. If `bundle.mode=all`, then the client considers all bundle
+ URIs. The list is reduced based on the `bundle.<id>.filter` options
+ matching the client repository's partial clone filter. Then, all
+ bundle URIs are requested. If the `bundle.<id>.creationToken`
+ heuristic is provided, then the bundles are downloaded in decreasing
+ order by the creation token, stopping when a bundle has all required
+ OIDs. The bundles can then be unbundled in increasing creation token
+ order. The client stores the latest creation token as a heuristic
+ for avoiding future downloads if the bundle list does not advertise
+ bundles with larger creation tokens.
+
+ b. If `bundle.mode=any`, then the client can choose any one of the
+ bundle URIs to inspect. The client can use a variety of ways to
+ choose among these URIs. The client can also fallback to another URI
+ if the initial choice fails to return a result.
+
+Note that during a clone we expect that all bundles will be required, and
+heuristics such as `bundle.<uri>.creationToken` can be used to download
+bundles in chronological order or in parallel.
+
+If a given bundle URI is a bundle list with a `bundle.heuristic`
+value, then the client can choose to store that URI as its chosen bundle
+URI. The client can then navigate directly to that URI during later `git
+fetch` calls.
+
+When downloading bundle URIs, the client can choose to inspect the initial
+content before committing to downloading the entire content. This may
+provide enough information to determine if the URI is a bundle list or
+a bundle. In the case of a bundle, the client may inspect the bundle
+header to determine that all advertised tips are already in the client
+repository and cancel the remaining download.
+
+Fetching with Bundle URIs
+-------------------------
+
+When the client fetches new data, it can decide to fetch from bundle
+servers before fetching from the origin remote. This could be done via a
+command-line option, but it is more likely useful to use a config value
+such as the one specified during the clone.
+
+The fetch operation follows the same procedure to download bundles from a
+bundle list (although we do _not_ want to use parallel downloads here). We
+expect that the process will end when all prerequisite commit OIDs in a
+thin bundle are already in the object database.
+
+When using the `creationToken` heuristic, the client can avoid downloading
+any bundles if their creation tokens are not larger than the stored
+creation token. After fetching new bundles, Git updates this local
+creation token.
+
+If the bundle provider does not provide a heuristic, then the client
+should attempt to inspect the bundle headers before downloading the full
+bundle data in case the bundle tips already exist in the client
+repository.
+
+Error Conditions
+----------------
+
+If the Git client discovers something unexpected while downloading
+information according to a bundle URI or the bundle list found at that
+location, then Git can ignore that data and continue as if it was not
+given a bundle URI. The remote Git server is the ultimate source of truth,
+not the bundle URI.
+
+Here are a few example error conditions:
+
+* The client fails to connect with a server at the given URI or a connection
+ is lost without any chance to recover.
+
+* The client receives a 400-level response (such as `404 Not Found` or
+ `401 Not Authorized`). The client should use the credential helper to
+ find and provide a credential for the URI, but match the semantics of
+ Git's other HTTP protocols in terms of handling specific 400-level
+ errors.
+
+* The server reports any other failure response.
+
+* The client receives data that is not parsable as a bundle or bundle list.
+
+* A bundle includes a filter that does not match expectations.
+
+* The client cannot unbundle the bundles because the prerequisite commit OIDs
+ are not in the object database and there are no more bundles to download.
+
+There are also situations that could be seen as wasteful, but are not
+error conditions:
+
+* The downloaded bundles contain more information than is requested by
+ the clone or fetch request. A primary example is if the user requests
+ a clone with `--single-branch` but downloads bundles that store every
+ reachable commit from all `refs/heads/*` references. This might be
+ initially wasteful, but perhaps these objects will become reachable by
+ a later ref update that the client cares about.
+
+* A bundle download during a `git fetch` contains objects already in the
+ object database. This is probably unavoidable if we are using bundles
+ for fetches, since the client will almost always be slightly ahead of
+ the bundle servers after performing its "catch-up" fetch to the remote
+ server. This extra work is most wasteful when the client is fetching
+ much more frequently than the server is computing bundles, such as if
+ the client is using hourly prefetches with background maintenance, but
+ the server is computing bundles weekly. For this reason, the client
+ should not use bundle URIs for fetch unless the server has explicitly
+ recommended it through a `bundle.heuristic` value.
+
+Example Bundle Provider organization
+------------------------------------
+
+The bundle URI feature is intentionally designed to be flexible to
+different ways a bundle provider wants to organize the object data.
+However, it can be helpful to have a complete organization model described
+here so providers can start from that base.
+
+This example organization is a simplified model of what is used by the
+GVFS Cache Servers (see section near the end of this document) which have
+been beneficial in speeding up clones and fetches for very large
+repositories, although using extra software outside of Git.
+
+The bundle provider deploys servers across multiple geographies. Each
+server manages its own bundle set. The server can track a number of Git
+repositories, but provides a bundle list for each based on a pattern. For
+example, when mirroring a repository at `https://<domain>/<org>/<repo>`
+the bundle server could have its bundle list available at
+`https://<server-url>/<domain>/<org>/<repo>`. The origin Git server can
+list all of these servers under the "any" mode:
+
+ [bundle]
+ version = 1
+ mode = any
+
+ [bundle "eastus"]
+ uri = https://eastus.example.com/<domain>/<org>/<repo>
+
+ [bundle "europe"]
+ uri = https://europe.example.com/<domain>/<org>/<repo>
+
+ [bundle "apac"]
+ uri = https://apac.example.com/<domain>/<org>/<repo>
+
+This "list of lists" is static and only changes if a bundle server is
+added or removed.
+
+Each bundle server manages its own set of bundles. The initial bundle list
+contains only a single bundle, containing all of the objects received from
+cloning the repository from the origin server. The list uses the
+`creationToken` heuristic and a `creationToken` is made for the bundle
+based on the server's timestamp.
+
+The bundle server runs regularly-scheduled updates for the bundle list,
+such as once a day. During this task, the server fetches the latest
+contents from the origin server and generates a bundle containing the
+objects reachable from the latest origin refs, but not contained in a
+previously-computed bundle. This bundle is added to the list, with care
+that the `creationToken` is strictly greater than the previous maximum
+`creationToken`.
+
+When the bundle list grows too large, say more than 30 bundles, then the
+oldest "_N_ minus 30" bundles are combined into a single bundle. This
+bundle's `creationToken` is equal to the maximum `creationToken` among the
+merged bundles.
+
+An example bundle list is provided here, although it only has two daily
+bundles and not a full list of 30:
+
+ [bundle]
+ version = 1
+ mode = all
+ heuristic = creationToken
+
+ [bundle "2022-02-13-1644770820-daily"]
+ uri = https://eastus.example.com/<domain>/<org>/<repo>/2022-02-09-1644770820-daily.bundle
+ creationToken = 1644770820
+
+ [bundle "2022-02-09-1644442601-daily"]
+ uri = https://eastus.example.com/<domain>/<org>/<repo>/2022-02-09-1644442601-daily.bundle
+ creationToken = 1644442601
+
+ [bundle "2022-02-02-1643842562"]
+ uri = https://eastus.example.com/<domain>/<org>/<repo>/2022-02-02-1643842562.bundle
+ creationToken = 1643842562
+
+To avoid storing and serving object data in perpetuity despite becoming
+unreachable in the origin server, this bundle merge can be more careful.
+Instead of taking an absolute union of the old bundles, instead the bundle
+can be created by looking at the newer bundles and ensuring that their
+necessary commits are all available in this merged bundle (or in another
+one of the newer bundles). This allows "expiring" object data that is not
+being used by new commits in this window of time. That data could be
+reintroduced by a later push.
+
+The intention of this data organization has two main goals. First, initial
+clones of the repository become faster by downloading precomputed object
+data from a closer source. Second, `git fetch` commands can be faster,
+especially if the client has not fetched for a few days. However, if a
+client does not fetch for 30 days, then the bundle list organization would
+cause redownloading a large amount of object data.
+
+One way to make this organization more useful to users who fetch frequently
+is to have more frequent bundle creation. For example, bundles could be
+created every hour, and then once a day those "hourly" bundles could be
+merged into a "daily" bundle. The daily bundles are merged into the
+oldest bundle after 30 days.
+
+It is recommended that this bundle strategy is repeated with the `blob:none`
+filter if clients of this repository are expecting to use blobless partial
+clones. This list of blobless bundles stays in the same list as the full
+bundles, but uses the `bundle.<id>.filter` key to separate the two groups.
+For very large repositories, the bundle provider may want to _only_ provide
+blobless bundles.
+
+Implementation Plan
+-------------------
+
+This design document is being submitted on its own as an aspirational
+document, with the goal of implementing all of the mentioned client
+features over the course of several patch series. Here is a potential
+outline for submitting these features:
+
+1. Integrate bundle URIs into `git clone` with a `--bundle-uri` option.
+ This will include a new `git fetch --bundle-uri` mode for use as the
+ implementation underneath `git clone`. The initial version here will
+ expect a single bundle at the given URI.
+
+2. Implement the ability to parse a bundle list from a bundle URI and
+ update the `git fetch --bundle-uri` logic to properly distinguish
+ between `bundle.mode` options. Specifically design the feature so
+ that the config format parsing feeds a list of key-value pairs into the
+ bundle list logic.
+
+3. Create the `bundle-uri` protocol v2 command so Git servers can advertise
+ bundle URIs using the key-value pairs. Plug into the existing key-value
+ input to the bundle list logic. Allow `git clone` to discover these
+ bundle URIs and bootstrap the client repository from the bundle data.
+ (This choice is an opt-in via a config option and a command-line
+ option.)
+
+4. Allow the client to understand the `bundle.heuristic` configuration key
+ and the `bundle.<id>.creationToken` heuristic. When `git clone`
+ discovers a bundle URI with `bundle.heuristic`, it configures the client
+ repository to check that bundle URI during later `git fetch <remote>`
+ commands.
+
+5. Allow clients to discover bundle URIs during `git fetch` and configure
+ a bundle URI for later fetches if `bundle.heuristic` is set.
+
+6. Implement the "inspect headers" heuristic to reduce data downloads when
+ the `bundle.<id>.creationToken` heuristic is not available.
+
+As these features are reviewed, this plan might be updated. We also expect
+that new designs will be discovered and implemented as this feature
+matures and becomes used in real-world scenarios.
+
+Related Work: Packfile URIs
+---------------------------
+
+The Git protocol already has a capability where the Git server can list
+a set of URLs along with the packfile response when serving a client
+request. The client is then expected to download the packfiles at those
+locations in order to have a complete understanding of the response.
+
+This mechanism is used by the Gerrit server (implemented with JGit) and
+has been effective at reducing CPU load and improving user performance for
+clones.
+
+A major downside to this mechanism is that the origin server needs to know
+_exactly_ what is in those packfiles, and the packfiles need to be available
+to the user for some time after the server has responded. This coupling
+between the origin and the packfile data is difficult to manage.
+
+Further, this implementation is extremely hard to make work with fetches.
+
+Related Work: GVFS Cache Servers
+--------------------------------
+
+The GVFS Protocol [2] is a set of HTTP endpoints designed independently of
+the Git project before Git's partial clone was created. One feature of this
+protocol is the idea of a "cache server" which can be colocated with build
+machines or developer offices to transfer Git data without overloading the
+central server.
+
+The endpoint that VFS for Git is famous for is the `GET /gvfs/objects/{oid}`
+endpoint, which allows downloading an object on-demand. This is a critical
+piece of the filesystem virtualization of that product.
+
+However, a more subtle need is the `GET /gvfs/prefetch?lastPackTimestamp=<t>`
+endpoint. Given an optional timestamp, the cache server responds with a list
+of precomputed packfiles containing the commits and trees that were introduced
+in those time intervals.
+
+The cache server computes these "prefetch" packfiles using the following
+strategy:
+
+1. Every hour, an "hourly" pack is generated with a given timestamp.
+2. Nightly, the previous 24 hourly packs are rolled up into a "daily" pack.
+3. Nightly, all prefetch packs more than 30 days old are rolled up into
+ one pack.
+
+When a user runs `gvfs clone` or `scalar clone` against a repo with cache
+servers, the client requests all prefetch packfiles, which is at most
+`24 + 30 + 1` packfiles downloading only commits and trees. The client
+then follows with a request to the origin server for the references, and
+attempts to checkout that tip reference. (There is an extra endpoint that
+helps get all reachable trees from a given commit, in case that commit
+was not already in a prefetch packfile.)
+
+During a `git fetch`, a hook requests the prefetch endpoint using the
+most-recent timestamp from a previously-downloaded prefetch packfile.
+Only the list of packfiles with later timestamps are downloaded. Most
+users fetch hourly, so they get at most one hourly prefetch pack. Users
+whose machines have been off or otherwise have not fetched in over 30 days
+might redownload all prefetch packfiles. This is rare.
+
+It is important to note that the clients always contact the origin server
+for the refs advertisement, so the refs are frequently "ahead" of the
+prefetched pack data. The missing objects are downloaded on-demand using
+the `GET gvfs/objects/{oid}` requests, when needed by a command such as
+`git checkout` or `git log`. Some Git optimizations disable checks that
+would cause these on-demand downloads to be too aggressive.
+
+See Also
+--------
+
+[1] https://lore.kernel.org/git/RFC-cover-00.13-0000000000-20210805T150534Z-avarab@gmail.com/
+ An earlier RFC for a bundle URI feature.
+
+[2] https://github.com/microsoft/VFSForGit/blob/master/Protocol.md
+ The GVFS Protocol
diff --git a/technical/commit-graph.adoc b/technical/commit-graph.adoc
new file mode 100644
index 0000000..2c26e95
--- /dev/null
+++ b/technical/commit-graph.adoc
@@ -0,0 +1,401 @@
+Git Commit-Graph Design Notes
+=============================
+
+Git walks the commit graph for many reasons, including:
+
+1. Listing and filtering commit history.
+2. Computing merge bases.
+
+These operations can become slow as the commit count grows. The merge
+base calculation shows up in many user-facing commands, such as 'merge-base'
+or 'status' and can take minutes to compute depending on history shape.
+
+There are two main costs here:
+
+1. Decompressing and parsing commits.
+2. Walking the entire graph to satisfy topological order constraints.
+
+The commit-graph file is a supplemental data structure that accelerates
+commit graph walks. If a user downgrades or disables the 'core.commitGraph'
+config setting, then the existing object database is sufficient. The file is stored
+as "commit-graph" either in the .git/objects/info directory or in the info
+directory of an alternate.
+
+The commit-graph file stores the commit graph structure along with some
+extra metadata to speed up graph walks. By listing commit OIDs in
+lexicographic order, we can identify an integer position for each commit
+and refer to the parents of a commit using those integer positions. We
+use binary search to find initial commits and then use the integer
+positions for fast lookups during the walk.
+
+A consumer may load the following info for a commit from the graph:
+
+1. The commit OID.
+2. The list of parents, along with their integer position.
+3. The commit date.
+4. The root tree OID.
+5. The generation number (see definition below).
+
+Values 1-4 satisfy the requirements of parse_commit_gently().
+
+There are two definitions of generation number:
+1. Corrected committer dates (generation number v2)
+2. Topological levels (generation number v1)
+
+Define "corrected committer date" of a commit recursively as follows:
+
+ * A commit with no parents (a root commit) has corrected committer date
+ equal to its committer date.
+
+ * A commit with at least one parent has corrected committer date equal to
+ the maximum of its committer date and one more than the largest corrected
+ committer date among its parents.
+
+ * As a special case, a root commit with timestamp zero has corrected commit
+ date of 1, to be able to distinguish it from GENERATION_NUMBER_ZERO
+ (that is, an uncomputed corrected commit date).
+
+Define the "topological level" of a commit recursively as follows:
+
+ * A commit with no parents (a root commit) has topological level of one.
+
+ * A commit with at least one parent has topological level one more than
+ the largest topological level among its parents.
+
+Equivalently, the topological level of a commit A is one more than the
+length of a longest path from A to a root commit. The recursive definition
+is easier to use for computation and observing the following property:
+
+ If A and B are commits with generation numbers N and M, respectively,
+ and N <= M, then A cannot reach B. That is, we know without searching
+ that B is not an ancestor of A because it is further from a root commit
+ than A.
+
+ Conversely, when checking if A is an ancestor of B, then we only need
+ to walk commits until all commits on the walk boundary have generation
+ number at most N. If we walk commits using a priority queue seeded by
+ generation numbers, then we always expand the boundary commit with highest
+ generation number and can easily detect the stopping condition.
+
+The property applies to both versions of generation number, that is both
+corrected committer dates and topological levels.
+
+This property can be used to significantly reduce the time it takes to
+walk commits and determine topological relationships. Without generation
+numbers, the general heuristic is the following:
+
+ If A and B are commits with commit time X and Y, respectively, and
+ X < Y, then A _probably_ cannot reach B.
+
+In absence of corrected commit dates (for example, old versions of Git or
+mixed generation graph chains),
+this heuristic is currently used whenever the computation is allowed to
+violate topological relationships due to clock skew (such as "git log"
+with default order), but is not used when the topological order is
+required (such as merge base calculations, "git log --graph").
+
+In practice, we expect some commits to be created recently and not stored
+in the commit-graph. We can treat these commits as having "infinite"
+generation number and walk until reaching commits with known generation
+number.
+
+We use the macro GENERATION_NUMBER_INFINITY to mark commits not
+in the commit-graph file. If a commit-graph file was written by a version
+of Git that did not compute generation numbers, then those commits will
+have generation number represented by the macro GENERATION_NUMBER_ZERO = 0.
+
+Since the commit-graph file is closed under reachability, we can guarantee
+the following weaker condition on all commits:
+
+ If A and B are commits with generation numbers N and M, respectively,
+ and N < M, then A cannot reach B.
+
+Note how the strict inequality differs from the inequality when we have
+fully-computed generation numbers. Using strict inequality may result in
+walking a few extra commits, but the simplicity in dealing with commits
+with generation number *_INFINITY or *_ZERO is valuable.
+
+We use the macro GENERATION_NUMBER_V1_MAX = 0x3FFFFFFF for commits whose
+topological levels (generation number v1) are computed to be at least
+this value. We limit at this value since it is the largest value that
+can be stored in the commit-graph file using the 30 bits available
+to topological levels. This presents another case where a commit can
+have generation number equal to that of a parent.
+
+Design Details
+--------------
+
+- The commit-graph file is stored in a file named 'commit-graph' in the
+ .git/objects/info directory. This could be stored in the info directory
+ of an alternate.
+
+- The core.commitGraph config setting must be on to consume graph files.
+
+- The file format includes parameters for the object ID hash function,
+ so a future change of hash algorithm does not require a change in format.
+
+- Commit grafts and replace objects can change the shape of the commit
+ history. The latter can also be enabled/disabled on the fly using
+ `--no-replace-objects`. This leads to difficulty storing both possible
+ interpretations of a commit id, especially when computing generation
+ numbers. The commit-graph will not be read or written when
+ replace-objects or grafts are present.
+
+- Shallow clones create grafts of commits by dropping their parents. This
+ leads the commit-graph to think those commits have generation number 1.
+ If and when those commits are made unshallow, those generation numbers
+ become invalid. Since shallow clones are intended to restrict the commit
+ history to a very small set of commits, the commit-graph feature is less
+ helpful for these clones, anyway. The commit-graph will not be read or
+ written when shallow commits are present.
+
+Commit-Graphs Chains
+--------------------
+
+Typically, repos grow with near-constant velocity (commits per day). Over time,
+the number of commits added by a fetch operation is much smaller than the
+number of commits in the full history. By creating a "chain" of commit-graphs,
+we enable fast writes of new commit data without rewriting the entire commit
+history -- at least, most of the time.
+
+## File Layout
+
+A commit-graph chain uses multiple files, and we use a fixed naming convention
+to organize these files. Each commit-graph file has a name
+`$OBJDIR/info/commit-graphs/graph-{hash}.graph` where `{hash}` is the hex-
+valued hash stored in the footer of that file (which is a hash of the file's
+contents before that hash). For a chain of commit-graph files, a plain-text
+file at `$OBJDIR/info/commit-graphs/commit-graph-chain` contains the
+hashes for the files in order from "lowest" to "highest".
+
+For example, if the `commit-graph-chain` file contains the lines
+
+```
+ {hash0}
+ {hash1}
+ {hash2}
+```
+
+then the commit-graph chain looks like the following diagram:
+
+ +-----------------------+
+ | graph-{hash2}.graph |
+ +-----------------------+
+ |
+ +-----------------------+
+ | |
+ | graph-{hash1}.graph |
+ | |
+ +-----------------------+
+ |
+ +-----------------------+
+ | |
+ | |
+ | |
+ | graph-{hash0}.graph |
+ | |
+ | |
+ | |
+ +-----------------------+
+
+Let X0 be the number of commits in `graph-{hash0}.graph`, X1 be the number of
+commits in `graph-{hash1}.graph`, and X2 be the number of commits in
+`graph-{hash2}.graph`. If a commit appears in position i in `graph-{hash2}.graph`,
+then we interpret this as being the commit in position (X0 + X1 + i), and that
+will be used as its "graph position". The commits in `graph-{hash2}.graph` use these
+positions to refer to their parents, which may be in `graph-{hash1}.graph` or
+`graph-{hash0}.graph`. We can navigate to an arbitrary commit in position j by checking
+its containment in the intervals [0, X0), [X0, X0 + X1), [X0 + X1, X0 + X1 +
+X2).
+
+Each commit-graph file (except the base, `graph-{hash0}.graph`) contains data
+specifying the hashes of all files in the lower layers. In the above example,
+`graph-{hash1}.graph` contains `{hash0}` while `graph-{hash2}.graph` contains
+`{hash0}` and `{hash1}`.
+
+## Merging commit-graph files
+
+If we only added a new commit-graph file on every write, we would run into a
+linear search problem through many commit-graph files. Instead, we use a merge
+strategy to decide when the stack should collapse some number of levels.
+
+The diagram below shows such a collapse. As a set of new commits are added, it
+is determined by the merge strategy that the files should collapse to
+`graph-{hash1}`. Thus, the new commits, the commits in `graph-{hash2}` and
+the commits in `graph-{hash1}` should be combined into a new `graph-{hash3}`
+file.
+
+ +---------------------+
+ | |
+ | (new commits) |
+ | |
+ +---------------------+
+ | |
+ +-----------------------+ +---------------------+
+ | graph-{hash2} |->| |
+ +-----------------------+ +---------------------+
+ | | |
+ +-----------------------+ +---------------------+
+ | | | |
+ | graph-{hash1} |->| |
+ | | | |
+ +-----------------------+ +---------------------+
+ | tmp_graphXXX
+ +-----------------------+
+ | |
+ | |
+ | |
+ | graph-{hash0} |
+ | |
+ | |
+ | |
+ +-----------------------+
+
+During this process, the commits to write are combined, sorted and we write the
+contents to a temporary file, all while holding a `commit-graph-chain.lock`
+lock-file. When the file is flushed, we rename it to `graph-{hash3}`
+according to the computed `{hash3}`. Finally, we write the new chain data to
+`commit-graph-chain.lock`:
+
+```
+ {hash3}
+ {hash0}
+```
+
+We then close the lock-file.
+
+## Merge Strategy
+
+When writing a set of commits that do not exist in the commit-graph stack of
+height N, we default to creating a new file at level N + 1. We then decide to
+merge with the Nth level if one of two conditions hold:
+
+ 1. `--size-multiple=<X>` is specified or X = 2, and the number of commits in
+ level N is less than X times the number of commits in level N + 1.
+
+ 2. `--max-commits=<C>` is specified with non-zero C and the number of commits
+ in level N + 1 is more than C commits.
+
+This decision cascades down the levels: when we merge a level we create a new
+set of commits that then compares to the next level.
+
+The first condition bounds the number of levels to be logarithmic in the total
+number of commits. The second condition bounds the total number of commits in
+a `graph-{hashN}` file and not in the `commit-graph` file, preventing
+significant performance issues when the stack merges and another process only
+partially reads the previous stack.
+
+The merge strategy values (2 for the size multiple, 64,000 for the maximum
+number of commits) could be extracted into config settings for full
+flexibility.
+
+## Handling Mixed Generation Number Chains
+
+With the introduction of generation number v2 and generation data chunk, the
+following scenario is possible:
+
+1. "New" Git writes a commit-graph with the corrected commit dates.
+2. "Old" Git writes a split commit-graph on top without corrected commit dates.
+
+A naive approach of using the newest available generation number from
+each layer would lead to violated expectations: the lower layer would
+use corrected commit dates which are much larger than the topological
+levels of the higher layer. For this reason, Git inspects the topmost
+layer to see if the layer is missing corrected commit dates. In such a case
+Git only uses topological level for generation numbers.
+
+When writing a new layer in split commit-graph, we write corrected commit
+dates if the topmost layer has corrected commit dates written. This
+guarantees that if a layer has corrected commit dates, all lower layers
+must have corrected commit dates as well.
+
+When merging layers, we do not consider whether the merged layers had corrected
+commit dates. Instead, the new layer will have corrected commit dates if the
+layer below the new layer has corrected commit dates.
+
+While writing or merging layers, if the new layer is the only layer, it will
+have corrected commit dates when written by compatible versions of Git. Thus,
+rewriting split commit-graph as a single file (`--split=replace`) creates a
+single layer with corrected commit dates.
+
+## Deleting graph-{hash} files
+
+After a new tip file is written, some `graph-{hash}` files may no longer
+be part of a chain. It is important to remove these files from disk, eventually.
+The main reason to delay removal is that another process could read the
+`commit-graph-chain` file before it is rewritten, but then look for the
+`graph-{hash}` files after they are deleted.
+
+To allow holding old split commit-graphs for a while after they are unreferenced,
+we update the modified times of the files when they become unreferenced. Then,
+we scan the `$OBJDIR/info/commit-graphs/` directory for `graph-{hash}`
+files whose modified times are older than a given expiry window. This window
+defaults to zero, but can be changed using command-line arguments or a config
+setting.
+
+## Chains across multiple object directories
+
+In a repo with alternates, we look for the `commit-graph-chain` file starting
+in the local object directory and then in each alternate. The first file that
+exists defines our chain. As we look for the `graph-{hash}` files for
+each `{hash}` in the chain file, we follow the same pattern for the host
+directories.
+
+This allows commit-graphs to be split across multiple forks in a fork network.
+The typical case is a large "base" repo with many smaller forks.
+
+As the base repo advances, it will likely update and merge its commit-graph
+chain more frequently than the forks. If a fork updates their commit-graph after
+the base repo, then it should "reparent" the commit-graph chain onto the new
+chain in the base repo. When reading each `graph-{hash}` file, we track
+the object directory containing it. During a write of a new commit-graph file,
+we check for any changes in the source object directory and read the
+`commit-graph-chain` file for that source and create a new file based on those
+files. During this "reparent" operation, we necessarily need to collapse all
+levels in the fork, as all of the files are invalid against the new base file.
+
+It is crucial to be careful when cleaning up "unreferenced" `graph-{hash}.graph`
+files in this scenario. It falls to the user to define the proper settings for
+their custom environment:
+
+ 1. When merging levels in the base repo, the unreferenced files may still be
+ referenced by chains from fork repos.
+
+ 2. The expiry time should be set to a length of time such that every fork has
+ time to recompute their commit-graph chain to "reparent" onto the new base
+ file(s).
+
+ 3. If the commit-graph chain is updated in the base, the fork will not have
+ access to the new chain until its chain is updated to reference those files.
+ (This may change in the future [5].)
+
+Related Links
+-------------
+[0] https://bugs.chromium.org/p/git/issues/detail?id=8
+ Chromium work item for: Serialized Commit Graph
+
+[1] https://lore.kernel.org/git/20110713070517.GC18566@sigill.intra.peff.net/
+ An abandoned patch that introduced generation numbers.
+
+[2] https://lore.kernel.org/git/20170908033403.q7e6dj7benasrjes@sigill.intra.peff.net/
+ Discussion about generation numbers on commits and how they interact
+ with fsck.
+
+[3] https://lore.kernel.org/git/20170908034739.4op3w4f2ma5s65ku@sigill.intra.peff.net/
+ More discussion about generation numbers and not storing them inside
+ commit objects. A valuable quote:
+
+ "I think we should be moving more in the direction of keeping
+ repo-local caches for optimizations. Reachability bitmaps have been
+ a big performance win. I think we should be doing the same with our
+ properties of commits. Not just generation numbers, but making it
+ cheap to access the graph structure without zlib-inflating whole
+ commit objects (i.e., packv4 or something like the "metapacks" I
+ proposed a few years ago)."
+
+[4] https://lore.kernel.org/git/20180108154822.54829-1-git@jeffhostetler.com/T/#u
+ A patch to remove the ahead-behind calculation from 'status'.
+
+[5] https://lore.kernel.org/git/f27db281-abad-5043-6d71-cbb083b1c877@gmail.com/
+ A discussion of a "two-dimensional graph position" that can allow reading
+ multiple commit-graph chains at the same time.
diff --git a/technical/directory-rename-detection.adoc b/technical/directory-rename-detection.adoc
new file mode 100644
index 0000000..029ee2c
--- /dev/null
+++ b/technical/directory-rename-detection.adoc
@@ -0,0 +1,118 @@
+Directory rename detection
+==========================
+
+Rename detection logic in diffcore-rename that checks for renames of
+individual files is also aggregated there and then analyzed in either
+merge-ort or merge-recursive for cases where combinations of renames
+indicate that a full directory has been renamed.
+
+Scope of abilities
+------------------
+
+It is perhaps easiest to start with an example:
+
+ * When all of x/a, x/b and x/c have moved to z/a, z/b and z/c, it is
+ likely that x/d added in the meantime would also want to move to z/d by
+ taking the hint that the entire directory 'x' moved to 'z'.
+
+More interesting possibilities exist, though, such as:
+
+ * one side of history renames x -> z, and the other renames some file to
+ x/e, causing the need for the merge to do a transitive rename so that
+ the rename ends up at z/e.
+
+ * one side of history renames x -> z, but also renames all files within x.
+ For example, x/a -> z/alpha, x/b -> z/bravo, etc.
+
+ * both 'x' and 'y' being merged into a single directory 'z', with a
+ directory rename being detected for both x->z and y->z.
+
+ * not all files in a directory being renamed to the same location;
+ i.e. perhaps most the files in 'x' are now found under 'z', but a few
+ are found under 'w'.
+
+ * a directory being renamed, which also contained a subdirectory that was
+ renamed to some entirely different location. (And perhaps the inner
+ directory itself contained inner directories that were renamed to yet
+ other locations).
+
+ * combinations of the above; see t/t6423-merge-rename-directories.sh for
+ various interesting cases.
+
+Limitations -- applicability of directory renames
+-------------------------------------------------
+
+In order to prevent edge and corner cases resulting in either conflicts
+that cannot be represented in the index or which might be too complex for
+users to try to understand and resolve, a couple basic rules limit when
+directory rename detection applies:
+
+ 1) If a given directory still exists on both sides of a merge, we do
+ not consider it to have been renamed.
+
+ 2) If a subset of to-be-renamed files have a file or directory in the
+ way (or would be in the way of each other), "turn off" the directory
+ rename for those specific sub-paths and report the conflict to the
+ user.
+
+ 3) If the other side of history did a directory rename to a path that
+ your side of history renamed away, then ignore that particular
+ rename from the other side of history for any implicit directory
+ renames (but warn the user).
+
+Limitations -- detailed rules and testcases
+-------------------------------------------
+
+t/t6423-merge-rename-directories.sh contains extensive tests and commentary
+which generate and explore the rules listed above. It also lists a few
+additional rules:
+
+ a) If renames split a directory into two or more others, the directory
+ with the most renames, "wins".
+
+ b) Only apply implicit directory renames to directories if the other side
+ of history is the one doing the renaming.
+
+ c) Do not perform directory rename detection for directories which had no
+ new paths added to them.
+
+Limitations -- support in different commands
+--------------------------------------------
+
+Directory rename detection is supported by 'merge' and 'cherry-pick'.
+Other git commands which users might be surprised to see limited or no
+directory rename detection support in:
+
+ * diff
+
+ Folks have requested in the past that `git diff` detect directory
+ renames and somehow simplify its output. It is not clear whether this
+ would be desirable or how the output should be simplified, so this was
+ simply not implemented. Also, while diffcore-rename has most of the
+ logic for detecting directory renames, some of the logic is still found
+ within merge-ort and merge-recursive. Fully supporting directory
+ rename detection in diffs would require copying or moving the remaining
+ bits of logic to the diff machinery.
+
+ * am
+
+ git-am tries to avoid a full three way merge, instead calling
+ git-apply. That prevents us from detecting renames at all, which may
+ defeat the directory rename detection. There is a fallback, though; if
+ the initial git-apply fails and the user has specified the -3 option,
+ git-am will fall back to a three way merge. However, git-am lacks the
+ necessary information to do a "real" three way merge. Instead, it has
+ to use build_fake_ancestor() to get a merge base that is missing files
+ whose rename may have been important to detect for directory rename
+ detection to function.
+
+ * rebase
+
+ Since am-based rebases work by first generating a bunch of patches
+ (which no longer record what the original commits were and thus don't
+ have the necessary info from which we can find a real merge-base), and
+ then calling git-am, this implies that am-based rebases will not always
+ successfully detect directory renames either (see the 'am' section
+ above). merged-based rebases (rebase -m) and cherry-pick-based rebases
+ (rebase -i) are not affected by this shortcoming, and fully support
+ directory rename detection.
diff --git a/technical/hash-function-transition.adoc b/technical/hash-function-transition.adoc
new file mode 100644
index 0000000..7102c7c
--- /dev/null
+++ b/technical/hash-function-transition.adoc
@@ -0,0 +1,830 @@
+Git hash function transition
+============================
+
+Objective
+---------
+Migrate Git from SHA-1 to a stronger hash function.
+
+Background
+----------
+At its core, the Git version control system is a content addressable
+filesystem. It uses the SHA-1 hash function to name content. For
+example, files, directories, and revisions are referred to by hash
+values unlike in other traditional version control systems where files
+or versions are referred to via sequential numbers. The use of a hash
+function to address its content delivers a few advantages:
+
+* Integrity checking is easy. Bit flips, for example, are easily
+ detected, as the hash of corrupted content does not match its name.
+* Lookup of objects is fast.
+
+Using a cryptographically secure hash function brings additional
+advantages:
+
+* Object names can be signed and third parties can trust the hash to
+ address the signed object and all objects it references.
+* Communication using Git protocol and out of band communication
+ methods have a short reliable string that can be used to reliably
+ address stored content.
+
+Over time some flaws in SHA-1 have been discovered by security
+researchers. On 23 February 2017 the SHAttered attack
+(https://shattered.io) demonstrated a practical SHA-1 hash collision.
+
+Git v2.13.0 and later subsequently moved to a hardened SHA-1
+implementation by default, which isn't vulnerable to the SHAttered
+attack, but SHA-1 is still weak.
+
+Thus it's considered prudent to move past any variant of SHA-1
+to a new hash. There's no guarantee that future attacks on SHA-1 won't
+be published in the future, and those attacks may not have viable
+mitigations.
+
+If SHA-1 and its variants were to be truly broken, Git's hash function
+could not be considered cryptographically secure any more. This would
+impact the communication of hash values because we could not trust
+that a given hash value represented the known good version of content
+that the speaker intended.
+
+SHA-1 still possesses the other properties such as fast object lookup
+and safe error checking, but other hash functions are equally suitable
+that are believed to be cryptographically secure.
+
+Choice of Hash
+--------------
+The hash to replace the hardened SHA-1 should be stronger than SHA-1
+was: we would like it to be trustworthy and useful in practice for at
+least 10 years.
+
+Some other relevant properties:
+
+1. A 256-bit hash (long enough to match common security practice; not
+ excessively long to hurt performance and disk usage).
+
+2. High quality implementations should be widely available (e.g., in
+ OpenSSL and Apple CommonCrypto).
+
+3. The hash function's properties should match Git's needs (e.g. Git
+ requires collision and 2nd preimage resistance and does not require
+ length extension resistance).
+
+4. As a tiebreaker, the hash should be fast to compute (fortunately
+ many contenders are faster than SHA-1).
+
+There were several contenders for a successor hash to SHA-1, including
+SHA-256, SHA-512/256, SHA-256x16, K12, and BLAKE2bp-256.
+
+In late 2018 the project picked SHA-256 as its successor hash.
+
+See 0ed8d8da374 (doc hash-function-transition: pick SHA-256 as
+NewHash, 2018-08-04) and numerous mailing list threads at the time,
+particularly the one starting at
+https://lore.kernel.org/git/20180609224913.GC38834@genre.crustytoothpaste.net/
+for more information.
+
+Goals
+-----
+1. The transition to SHA-256 can be done one local repository at a time.
+ a. Requiring no action by any other party.
+ b. A SHA-256 repository can communicate with SHA-1 Git servers
+ (push/fetch).
+ c. Users can use SHA-1 and SHA-256 identifiers for objects
+ interchangeably (see "Object names on the command line", below).
+ d. New signed objects make use of a stronger hash function than
+ SHA-1 for their security guarantees.
+2. Allow a complete transition away from SHA-1.
+ a. Local metadata for SHA-1 compatibility can be removed from a
+ repository if compatibility with SHA-1 is no longer needed.
+3. Maintainability throughout the process.
+ a. The object format is kept simple and consistent.
+ b. Creation of a generalized repository conversion tool.
+
+Non-Goals
+---------
+1. Add SHA-256 support to Git protocol. This is valuable and the
+ logical next step but it is out of scope for this initial design.
+2. Transparently improving the security of existing SHA-1 signed
+ objects.
+3. Intermixing objects using multiple hash functions in a single
+ repository.
+4. Taking the opportunity to fix other bugs in Git's formats and
+ protocols.
+5. Shallow clones and fetches into a SHA-256 repository. (This will
+ change when we add SHA-256 support to Git protocol.)
+6. Skip fetching some submodules of a project into a SHA-256
+ repository. (This also depends on SHA-256 support in Git
+ protocol.)
+
+Overview
+--------
+We introduce a new repository format extension. Repositories with this
+extension enabled use SHA-256 instead of SHA-1 to name their objects.
+This affects both object names and object content -- both the names
+of objects and all references to other objects within an object are
+switched to the new hash function.
+
+SHA-256 repositories cannot be read by older versions of Git.
+
+Alongside the packfile, a SHA-256 repository stores a bidirectional
+mapping between SHA-256 and SHA-1 object names. The mapping is generated
+locally and can be verified using "git fsck". Object lookups use this
+mapping to allow naming objects using either their SHA-1 and SHA-256 names
+interchangeably.
+
+"git cat-file" and "git hash-object" gain options to display an object
+in its SHA-1 form and write an object given its SHA-1 form. This
+requires all objects referenced by that object to be present in the
+object database so that they can be named using the appropriate name
+(using the bidirectional hash mapping).
+
+Fetches from a SHA-1 based server convert the fetched objects into
+SHA-256 form and record the mapping in the bidirectional mapping table
+(see below for details). Pushes to a SHA-1 based server convert the
+objects being pushed into SHA-1 form so the server does not have to be
+aware of the hash function the client is using.
+
+Detailed Design
+---------------
+Repository format extension
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+A SHA-256 repository uses repository format version `1` (see
+linkgit:gitrepository-layout[5]) with `extensions.objectFormat` and
+`extensions.compatObjectFormat` (see linkgit:git-config[1]) set to:
+
+ [core]
+ repositoryFormatVersion = 1
+ [extensions]
+ objectFormat = sha256
+ compatObjectFormat = sha1
+
+The combination of setting `core.repositoryFormatVersion=1` and
+populating `extensions.*` ensures that all versions of Git later than
+`v0.99.9l` will die instead of trying to operate on the SHA-256
+repository, instead producing an error message.
+
+ # Between v0.99.9l and v2.7.0
+ $ git status
+ fatal: Expected git repo version <= 0, found 1
+ # After v2.7.0
+ $ git status
+ fatal: unknown repository extensions found:
+ objectformat
+ compatobjectformat
+
+See the "Transition plan" section below for more details on these
+repository extensions.
+
+Object names
+~~~~~~~~~~~~
+Objects can be named by their 40 hexadecimal digit SHA-1 name or 64
+hexadecimal digit SHA-256 name, plus names derived from those (see
+gitrevisions(7)).
+
+The SHA-1 name of an object is the SHA-1 of the concatenation of its
+type, length, a nul byte, and the object's SHA-1 content. This is the
+traditional <sha1> used in Git to name objects.
+
+The SHA-256 name of an object is the SHA-256 of the concatenation of its
+type, length, a nul byte, and the object's SHA-256 content.
+
+Object format
+~~~~~~~~~~~~~
+The content as a byte sequence of a tag, commit, or tree object named
+by SHA-1 and SHA-256 differ because an object named by SHA-256 name refers to
+other objects by their SHA-256 names and an object named by SHA-1 name
+refers to other objects by their SHA-1 names.
+
+The SHA-256 content of an object is the same as its SHA-1 content, except
+that objects referenced by the object are named using their SHA-256 names
+instead of SHA-1 names. Because a blob object does not refer to any
+other object, its SHA-1 content and SHA-256 content are the same.
+
+The format allows round-trip conversion between SHA-256 content and
+SHA-1 content.
+
+Object storage
+~~~~~~~~~~~~~~
+Loose objects use zlib compression and packed objects use the packed
+format described in linkgit:gitformat-pack[5], just like
+today. The content that is compressed and stored uses SHA-256 content
+instead of SHA-1 content.
+
+Pack index
+~~~~~~~~~~
+Pack index (.idx) files use a new v3 format that supports multiple
+hash functions. They have the following format (all integers are in
+network byte order):
+
+- A header appears at the beginning and consists of the following:
+ * The 4-byte pack index signature: '\377t0c'
+ * 4-byte version number: 3
+ * 4-byte length of the header section, including the signature and
+ version number
+ * 4-byte number of objects contained in the pack
+ * 4-byte number of object formats in this pack index: 2
+ * For each object format:
+ ** 4-byte format identifier (e.g., 'sha1' for SHA-1)
+ ** 4-byte length in bytes of shortened object names. This is the
+ shortest possible length needed to make names in the shortened
+ object name table unambiguous.
+ ** 4-byte integer, recording where tables relating to this format
+ are stored in this index file, as an offset from the beginning.
+ * 4-byte offset to the trailer from the beginning of this file.
+ * Zero or more additional key/value pairs (4-byte key, 4-byte
+ value). Only one key is supported: 'PSRC'. See the "Loose objects
+ and unreachable objects" section for supported values and how this
+ is used. All other keys are reserved. Readers must ignore
+ unrecognized keys.
+- Zero or more NUL bytes. This can optionally be used to improve the
+ alignment of the full object name table below.
+- Tables for the first object format:
+ * A sorted table of shortened object names. These are prefixes of
+ the names of all objects in this pack file, packed together
+ without offset values to reduce the cache footprint of the binary
+ search for a specific object name.
+
+ * A table of full object names in pack order. This allows resolving
+ a reference to "the nth object in the pack file" (from a
+ reachability bitmap or from the next table of another object
+ format) to its object name.
+
+ * A table of 4-byte values mapping object name order to pack order.
+ For an object in the table of sorted shortened object names, the
+ value at the corresponding index in this table is the index in the
+ previous table for that same object.
+ This can be used to look up the object in reachability bitmaps or
+ to look up its name in another object format.
+
+ * A table of 4-byte CRC32 values of the packed object data, in the
+ order that the objects appear in the pack file. This is to allow
+ compressed data to be copied directly from pack to pack during
+ repacking without undetected data corruption.
+
+ * A table of 4-byte offset values. For an object in the table of
+ sorted shortened object names, the value at the corresponding
+ index in this table indicates where that object can be found in
+ the pack file. These are usually 31-bit pack file offsets, but
+ large offsets are encoded as an index into the next table with the
+ most significant bit set.
+
+ * A table of 8-byte offset entries (empty for pack files less than
+ 2 GiB). Pack files are organized with heavily used objects toward
+ the front, so most object references should not need to refer to
+ this table.
+- Zero or more NUL bytes.
+- Tables for the second object format, with the same layout as above,
+ up to and not including the table of CRC32 values.
+- Zero or more NUL bytes.
+- The trailer consists of the following:
+ * A copy of the 20-byte SHA-256 checksum at the end of the
+ corresponding packfile.
+
+ * 20-byte SHA-256 checksum of all of the above.
+
+Loose object index
+~~~~~~~~~~~~~~~~~~
+A new file $GIT_OBJECT_DIR/loose-object-idx contains information about
+all loose objects. Its format is
+
+ # loose-object-idx
+ (sha256-name SP sha1-name LF)*
+
+where the object names are in hexadecimal format. The file is not
+sorted.
+
+The loose object index is protected against concurrent writes by a
+lock file $GIT_OBJECT_DIR/loose-object-idx.lock. To add a new loose
+object:
+
+1. Write the loose object to a temporary file, like today.
+2. Open loose-object-idx.lock with O_CREAT | O_EXCL to acquire the lock.
+3. Rename the loose object into place.
+4. Open loose-object-idx with O_APPEND and write the new object
+5. Unlink loose-object-idx.lock to release the lock.
+
+To remove entries (e.g. in "git pack-refs" or "git-prune"):
+
+1. Open loose-object-idx.lock with O_CREAT | O_EXCL to acquire the
+ lock.
+2. Write the new content to loose-object-idx.lock.
+3. Unlink any loose objects being removed.
+4. Rename to replace loose-object-idx, releasing the lock.
+
+Translation table
+~~~~~~~~~~~~~~~~~
+The index files support a bidirectional mapping between SHA-1 names
+and SHA-256 names. The lookup proceeds similarly to ordinary object
+lookups. For example, to convert a SHA-1 name to a SHA-256 name:
+
+ 1. Look for the object in idx files. If a match is present in the
+ idx's sorted list of truncated SHA-1 names, then:
+ a. Read the corresponding entry in the SHA-1 name order to pack
+ name order mapping.
+ b. Read the corresponding entry in the full SHA-1 name table to
+ verify we found the right object. If it is, then
+ c. Read the corresponding entry in the full SHA-256 name table.
+ That is the object's SHA-256 name.
+ 2. Check for a loose object. Read lines from loose-object-idx until
+ we find a match.
+
+Step (1) takes the same amount of time as an ordinary object lookup:
+O(number of packs * log(objects per pack)). Step (2) takes O(number of
+loose objects) time. To maintain good performance it will be necessary
+to keep the number of loose objects low. See the "Loose objects and
+unreachable objects" section below for more details.
+
+Since all operations that make new objects (e.g., "git commit") add
+the new objects to the corresponding index, this mapping is possible
+for all objects in the object store.
+
+Reading an object's SHA-1 content
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The SHA-1 content of an object can be read by converting all SHA-256 names
+of its SHA-256 content references to SHA-1 names using the translation table.
+
+Fetch
+~~~~~
+Fetching from a SHA-1 based server requires translating between SHA-1
+and SHA-256 based representations on the fly.
+
+SHA-1s named in the ref advertisement that are present on the client
+can be translated to SHA-256 and looked up as local objects using the
+translation table.
+
+Negotiation proceeds as today. Any "have"s generated locally are
+converted to SHA-1 before being sent to the server, and SHA-1s
+mentioned by the server are converted to SHA-256 when looking them up
+locally.
+
+After negotiation, the server sends a packfile containing the
+requested objects. We convert the packfile to SHA-256 format using
+the following steps:
+
+1. index-pack: inflate each object in the packfile and compute its
+ SHA-1. Objects can contain deltas in OBJ_REF_DELTA format against
+ objects the client has locally. These objects can be looked up
+ using the translation table and their SHA-1 content read as
+ described above to resolve the deltas.
+2. topological sort: starting at the "want"s from the negotiation
+ phase, walk through objects in the pack and emit a list of them,
+ excluding blobs, in reverse topologically sorted order, with each
+ object coming later in the list than all objects it references.
+ (This list only contains objects reachable from the "wants". If the
+ pack from the server contained additional extraneous objects, then
+ they will be discarded.)
+3. convert to SHA-256: open a new SHA-256 packfile. Read the topologically
+ sorted list just generated. For each object, inflate its
+ SHA-1 content, convert to SHA-256 content, and write it to the SHA-256
+ pack. Record the new SHA-1<-->SHA-256 mapping entry for use in the idx.
+4. sort: reorder entries in the new pack to match the order of objects
+ in the pack the server generated and include blobs. Write a SHA-256 idx
+ file
+5. clean up: remove the SHA-1 based pack file, index, and
+ topologically sorted list obtained from the server in steps 1
+ and 2.
+
+Step 3 requires every object referenced by the new object to be in the
+translation table. This is why the topological sort step is necessary.
+
+As an optimization, step 1 could write a file describing what non-blob
+objects each object it has inflated from the packfile references. This
+makes the topological sort in step 2 possible without inflating the
+objects in the packfile for a second time. The objects need to be
+inflated again in step 3, for a total of two inflations.
+
+Step 4 is probably necessary for good read-time performance. "git
+pack-objects" on the server optimizes the pack file for good data
+locality (see Documentation/technical/pack-heuristics.txt).
+
+Details of this process are likely to change. It will take some
+experimenting to get this to perform well.
+
+Push
+~~~~
+Push is simpler than fetch because the objects referenced by the
+pushed objects are already in the translation table. The SHA-1 content
+of each object being pushed can be read as described in the "Reading
+an object's SHA-1 content" section to generate the pack written by git
+send-pack.
+
+Signed Commits
+~~~~~~~~~~~~~~
+We add a new field "gpgsig-sha256" to the commit object format to allow
+signing commits without relying on SHA-1. It is similar to the
+existing "gpgsig" field. Its signed payload is the SHA-256 content of the
+commit object with any "gpgsig" and "gpgsig-sha256" fields removed.
+
+This means commits can be signed
+
+1. using SHA-1 only, as in existing signed commit objects
+2. using both SHA-1 and SHA-256, by using both gpgsig-sha256 and gpgsig
+ fields.
+3. using only SHA-256, by only using the gpgsig-sha256 field.
+
+Old versions of "git verify-commit" can verify the gpgsig signature in
+cases (1) and (2) without modifications and view case (3) as an
+ordinary unsigned commit.
+
+Signed Tags
+~~~~~~~~~~~
+We add a new field "gpgsig-sha256" to the tag object format to allow
+signing tags without relying on SHA-1. Its signed payload is the
+SHA-256 content of the tag with its gpgsig-sha256 field and "-----BEGIN PGP
+SIGNATURE-----" delimited in-body signature removed.
+
+This means tags can be signed
+
+1. using SHA-1 only, as in existing signed tag objects
+2. using both SHA-1 and SHA-256, by using gpgsig-sha256 and an in-body
+ signature.
+3. using only SHA-256, by only using the gpgsig-sha256 field.
+
+Mergetag embedding
+~~~~~~~~~~~~~~~~~~
+The mergetag field in the SHA-1 content of a commit contains the
+SHA-1 content of a tag that was merged by that commit.
+
+The mergetag field in the SHA-256 content of the same commit contains the
+SHA-256 content of the same tag.
+
+Submodules
+~~~~~~~~~~
+To convert recorded submodule pointers, you need to have the converted
+submodule repository in place. The translation table of the submodule
+can be used to look up the new hash.
+
+Loose objects and unreachable objects
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Fast lookups in the loose-object-idx require that the number of loose
+objects not grow too high.
+
+"git gc --auto" currently waits for there to be 6700 loose objects
+present before consolidating them into a packfile. We will need to
+measure to find a more appropriate threshold for it to use.
+
+"git gc --auto" currently waits for there to be 50 packs present
+before combining packfiles. Packing loose objects more aggressively
+may cause the number of pack files to grow too quickly. This can be
+mitigated by using a strategy similar to Martin Fick's exponential
+rolling garbage collection script:
+https://gerrit-review.googlesource.com/c/gerrit/+/35215
+
+"git gc" currently expels any unreachable objects it encounters in
+pack files to loose objects in an attempt to prevent a race when
+pruning them (in case another process is simultaneously writing a new
+object that refers to the about-to-be-deleted object). This leads to
+an explosion in the number of loose objects present and disk space
+usage due to the objects in delta form being replaced with independent
+loose objects. Worse, the race is still present for loose objects.
+
+Instead, "git gc" will need to move unreachable objects to a new
+packfile marked as UNREACHABLE_GARBAGE (using the PSRC field; see
+below). To avoid the race when writing new objects referring to an
+about-to-be-deleted object, code paths that write new objects will
+need to copy any objects from UNREACHABLE_GARBAGE packs that they
+refer to new, non-UNREACHABLE_GARBAGE packs (or loose objects).
+UNREACHABLE_GARBAGE are then safe to delete if their creation time (as
+indicated by the file's mtime) is long enough ago.
+
+To avoid a proliferation of UNREACHABLE_GARBAGE packs, they can be
+combined under certain circumstances. If "gc.garbageTtl" is set to
+greater than one day, then packs created within a single calendar day,
+UTC, can be coalesced together. The resulting packfile would have an
+mtime before midnight on that day, so this makes the effective maximum
+ttl the garbageTtl + 1 day. If "gc.garbageTtl" is less than one day,
+then we divide the calendar day into intervals one-third of that ttl
+in duration. Packs created within the same interval can be coalesced
+together. The resulting packfile would have an mtime before the end of
+the interval, so this makes the effective maximum ttl equal to the
+garbageTtl * 4/3.
+
+This rule comes from Thirumala Reddy Mutchukota's JGit change
+https://git.eclipse.org/r/90465.
+
+The UNREACHABLE_GARBAGE setting goes in the PSRC field of the pack
+index. More generally, that field indicates where a pack came from:
+
+ - 1 (PACK_SOURCE_RECEIVE) for a pack received over the network
+ - 2 (PACK_SOURCE_AUTO) for a pack created by a lightweight
+ "gc --auto" operation
+ - 3 (PACK_SOURCE_GC) for a pack created by a full gc
+ - 4 (PACK_SOURCE_UNREACHABLE_GARBAGE) for potential garbage
+ discovered by gc
+ - 5 (PACK_SOURCE_INSERT) for locally created objects that were
+ written directly to a pack file, e.g. from "git add ."
+
+This information can be useful for debugging and for "gc --auto" to
+make appropriate choices about which packs to coalesce.
+
+Caveats
+-------
+Invalid objects
+~~~~~~~~~~~~~~~
+The conversion from SHA-1 content to SHA-256 content retains any
+brokenness in the original object (e.g., tree entry modes encoded with
+leading 0, tree objects whose paths are not sorted correctly, and
+commit objects without an author or committer). This is a deliberate
+feature of the design to allow the conversion to round-trip.
+
+More profoundly broken objects (e.g., a commit with a truncated "tree"
+header line) cannot be converted but were not usable by current Git
+anyway.
+
+Shallow clone and submodules
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Because it requires all referenced objects to be available in the
+locally generated translation table, this design does not support
+shallow clone or unfetched submodules. Protocol improvements might
+allow lifting this restriction.
+
+Alternates
+~~~~~~~~~~
+For the same reason, a SHA-256 repository cannot borrow objects from a
+SHA-1 repository using objects/info/alternates or
+$GIT_ALTERNATE_OBJECT_REPOSITORIES.
+
+git notes
+~~~~~~~~~
+The "git notes" tool annotates objects using their SHA-1 name as key.
+This design does not describe a way to migrate notes trees to use
+SHA-256 names. That migration is expected to happen separately (for
+example using a file at the root of the notes tree to describe which
+hash it uses).
+
+Server-side cost
+~~~~~~~~~~~~~~~~
+Until Git protocol gains SHA-256 support, using SHA-256 based storage
+on public-facing Git servers is strongly discouraged. Once Git
+protocol gains SHA-256 support, SHA-256 based servers are likely not
+to support SHA-1 compatibility, to avoid what may be a very expensive
+hash re-encode during clone and to encourage peers to modernize.
+
+The design described here allows fetches by SHA-1 clients of a
+personal SHA-256 repository because it's not much more difficult than
+allowing pushes from that repository. This support needs to be guarded
+by a configuration option -- servers like git.kernel.org that serve a
+large number of clients would not be expected to bear that cost.
+
+Meaning of signatures
+~~~~~~~~~~~~~~~~~~~~~
+The signed payload for signed commits and tags does not explicitly
+name the hash used to identify objects. If some day Git adopts a new
+hash function with the same length as the current SHA-1 (40
+hexadecimal digit) or SHA-256 (64 hexadecimal digit) objects then the
+intent behind the PGP signed payload in an object signature is
+unclear:
+
+ object e7e07d5a4fcc2a203d9873968ad3e6bd4d7419d7
+ type commit
+ tag v2.12.0
+ tagger Junio C Hamano <gitster@pobox.com> 1487962205 -0800
+
+ Git 2.12
+
+Does this mean Git v2.12.0 is the commit with SHA-1 name
+e7e07d5a4fcc2a203d9873968ad3e6bd4d7419d7 or the commit with
+new-40-digit-hash-name e7e07d5a4fcc2a203d9873968ad3e6bd4d7419d7?
+
+Fortunately SHA-256 and SHA-1 have different lengths. If Git starts
+using another hash with the same length to name objects, then it will
+need to change the format of signed payloads using that hash to
+address this issue.
+
+Object names on the command line
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+To support the transition (see Transition plan below), this design
+supports four different modes of operation:
+
+ 1. ("dark launch") Treat object names input by the user as SHA-1 and
+ convert any object names written to output to SHA-1, but store
+ objects using SHA-256. This allows users to test the code with no
+ visible behavior change except for performance. This allows
+ running even tests that assume the SHA-1 hash function, to
+ sanity-check the behavior of the new mode.
+
+ 2. ("early transition") Allow both SHA-1 and SHA-256 object names in
+ input. Any object names written to output use SHA-1. This allows
+ users to continue to make use of SHA-1 to communicate with peers
+ (e.g. by email) that have not migrated yet and prepares for mode 3.
+
+ 3. ("late transition") Allow both SHA-1 and SHA-256 object names in
+ input. Any object names written to output use SHA-256. In this
+ mode, users are using a more secure object naming method by
+ default. The disruption is minimal as long as most of their peers
+ are in mode 2 or mode 3.
+
+ 4. ("post-transition") Treat object names input by the user as
+ SHA-256 and write output using SHA-256. This is safer than mode 3
+ because there is less risk that input is incorrectly interpreted
+ using the wrong hash function.
+
+The mode is specified in configuration.
+
+The user can also explicitly specify which format to use for a
+particular revision specifier and for output, overriding the mode. For
+example:
+
+ git --output-format=sha1 log abac87a^{sha1}..f787cac^{sha256}
+
+Transition plan
+---------------
+Some initial steps can be implemented independently of one another:
+
+- adding a hash function API (vtable)
+- teaching fsck to tolerate the gpgsig-sha256 field
+- excluding gpgsig-* from the fields copied by "git commit --amend"
+- annotating tests that depend on SHA-1 values with a SHA1 test
+ prerequisite
+- using "struct object_id", GIT_MAX_RAWSZ, and GIT_MAX_HEXSZ
+ consistently instead of "unsigned char *" and the hardcoded
+ constants 20 and 40.
+- introducing index v3
+- adding support for the PSRC field and safer object pruning
+
+The first user-visible change is the introduction of the objectFormat
+extension (without compatObjectFormat). This requires:
+
+- teaching fsck about this mode of operation
+- using the hash function API (vtable) when computing object names
+- signing objects and verifying signatures
+- rejecting attempts to fetch from or push to an incompatible
+ repository
+
+Next comes introduction of compatObjectFormat:
+
+- implementing the loose-object-idx
+- translating object names between object formats
+- translating object content between object formats
+- generating and verifying signatures in the compat format
+- adding appropriate index entries when adding a new object to the
+ object store
+- --output-format option
+- ^{sha1} and ^{sha256} revision notation
+- configuration to specify default input and output format (see
+ "Object names on the command line" above)
+
+The next step is supporting fetches and pushes to SHA-1 repositories:
+
+- allow pushes to a repository using the compat format
+- generate a topologically sorted list of the SHA-1 names of fetched
+ objects
+- convert the fetched packfile to SHA-256 format and generate an idx
+ file
+- re-sort to match the order of objects in the fetched packfile
+
+The infrastructure supporting fetch also allows converting an existing
+repository. In converted repositories and new clones, end users can
+gain support for the new hash function without any visible change in
+behavior (see "dark launch" in the "Object names on the command line"
+section). In particular this allows users to verify SHA-256 signatures
+on objects in the repository, and it should ensure the transition code
+is stable in production in preparation for using it more widely.
+
+Over time projects would encourage their users to adopt the "early
+transition" and then "late transition" modes to take advantage of the
+new, more futureproof SHA-256 object names.
+
+When objectFormat and compatObjectFormat are both set, commands
+generating signatures would generate both SHA-1 and SHA-256 signatures
+by default to support both new and old users.
+
+In projects using SHA-256 heavily, users could be encouraged to adopt
+the "post-transition" mode to avoid accidentally making implicit use
+of SHA-1 object names.
+
+Once a critical mass of users have upgraded to a version of Git that
+can verify SHA-256 signatures and have converted their existing
+repositories to support verifying them, we can add support for a
+setting to generate only SHA-256 signatures. This is expected to be at
+least a year later.
+
+That is also a good moment to advertise the ability to convert
+repositories to use SHA-256 only, stripping out all SHA-1 related
+metadata. This improves performance by eliminating translation
+overhead and security by avoiding the possibility of accidentally
+relying on the safety of SHA-1.
+
+Updating Git's protocols to allow a server to specify which hash
+functions it supports is also an important part of this transition. It
+is not discussed in detail in this document but this transition plan
+assumes it happens. :)
+
+Alternatives considered
+-----------------------
+Upgrading everyone working on a particular project on a flag day
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Projects like the Linux kernel are large and complex enough that
+flipping the switch for all projects based on the repository at once
+is infeasible.
+
+Not only would all developers and server operators supporting
+developers have to switch on the same flag day, but supporting tooling
+(continuous integration, code review, bug trackers, etc) would have to
+be adapted as well. This also makes it difficult to get early feedback
+from some project participants testing before it is time for mass
+adoption.
+
+Using hash functions in parallel
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+(e.g. https://lore.kernel.org/git/22708.8913.864049.452252@chiark.greenend.org.uk/ )
+Objects newly created would be addressed by the new hash, but inside
+such an object (e.g. commit) it is still possible to address objects
+using the old hash function.
+
+* You cannot trust its history (needed for bisectability) in the
+ future without further work
+* Maintenance burden as the number of supported hash functions grows
+ (they will never go away, so they accumulate). In this proposal, by
+ comparison, converted objects lose all references to SHA-1.
+
+Signed objects with multiple hashes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Instead of introducing the gpgsig-sha256 field in commit and tag objects
+for SHA-256 content based signatures, an earlier version of this design
+added "hash sha256 <SHA-256 name>" fields to strengthen the existing
+SHA-1 content based signatures.
+
+In other words, a single signature was used to attest to the object
+content using both hash functions. This had some advantages:
+
+* Using one signature instead of two speeds up the signing process.
+* Having one signed payload with both hashes allows the signer to
+ attest to the SHA-1 name and SHA-256 name referring to the same object.
+* All users consume the same signature. Broken signatures are likely
+ to be detected quickly using current versions of git.
+
+However, it also came with disadvantages:
+
+* Verifying a signed object requires access to the SHA-1 names of all
+ objects it references, even after the transition is complete and
+ translation table is no longer needed for anything else. To support
+ this, the design added fields such as "hash sha1 tree <SHA-1 name>"
+ and "hash sha1 parent <SHA-1 name>" to the SHA-256 content of a signed
+ commit, complicating the conversion process.
+* Allowing signed objects without a SHA-1 (for after the transition is
+ complete) complicated the design further, requiring a "nohash sha1"
+ field to suppress including "hash sha1" fields in the SHA-256 content
+ and signed payload.
+
+Lazily populated translation table
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Some of the work of building the translation table could be deferred to
+push time, but that would significantly complicate and slow down pushes.
+Calculating the SHA-1 name at object creation time at the same time it is
+being streamed to disk and having its SHA-256 name calculated should be
+an acceptable cost.
+
+Document History
+----------------
+
+2017-03-03
+bmwill@google.com, jonathantanmy@google.com, jrnieder@gmail.com,
+sbeller@google.com
+
+* Initial version sent to https://lore.kernel.org/git/20170304011251.GA26789@aiede.mtv.corp.google.com
+
+2017-03-03 jrnieder@gmail.com
+Incorporated suggestions from jonathantanmy and sbeller:
+
+* Describe purpose of signed objects with each hash type
+* Redefine signed object verification using object content under the
+ first hash function
+
+2017-03-06 jrnieder@gmail.com
+
+* Use SHA3-256 instead of SHA2 (thanks, Linus and brian m. carlson).[1][2]
+* Make SHA3-based signatures a separate field, avoiding the need for
+ "hash" and "nohash" fields (thanks to peff[3]).
+* Add a sorting phase to fetch (thanks to Junio for noticing the need
+ for this).
+* Omit blobs from the topological sort during fetch (thanks to peff).
+* Discuss alternates, git notes, and git servers in the caveats
+ section (thanks to Junio Hamano, brian m. carlson[4], and Shawn
+ Pearce).
+* Clarify language throughout (thanks to various commenters,
+ especially Junio).
+
+2017-09-27 jrnieder@gmail.com, sbeller@google.com
+
+* Use placeholder NewHash instead of SHA3-256
+* Describe criteria for picking a hash function.
+* Include a transition plan (thanks especially to Brandon Williams
+ for fleshing these ideas out)
+* Define the translation table (thanks, Shawn Pearce[5], Jonathan
+ Tan, and Masaya Suzuki)
+* Avoid loose object overhead by packing more aggressively in
+ "git gc --auto"
+
+Later history:
+
+* See the history of this file in git.git for the history of subsequent
+ edits. This document history is no longer being maintained as it
+ would now be superfluous to the commit log
+
+References:
+
+ [1] https://lore.kernel.org/git/CA+55aFzJtejiCjV0e43+9oR3QuJK2PiFiLQemytoLpyJWe6P9w@mail.gmail.com/
+ [2] https://lore.kernel.org/git/CA+55aFz+gkAsDZ24zmePQuEs1XPS9BP_s8O7Q4wQ7LV7X5-oDA@mail.gmail.com/
+ [3] https://lore.kernel.org/git/20170306084353.nrns455dvkdsfgo5@sigill.intra.peff.net/
+ [4] https://lore.kernel.org/git/20170304224936.rqqtkdvfjgyezsht@genre.crustytoothpaste.net
+ [5] https://lore.kernel.org/git/CAJo=hJtoX9=AyLHHpUJS7fueV9ciZ_MNpnEPHUz8Whui6g9F0A@mail.gmail.com/
diff --git a/technical/long-running-process-protocol.adoc b/technical/long-running-process-protocol.adoc
new file mode 100644
index 0000000..6f33654
--- /dev/null
+++ b/technical/long-running-process-protocol.adoc
@@ -0,0 +1,50 @@
+Long-running process protocol
+=============================
+
+This protocol is used when Git needs to communicate with an external
+process throughout the entire life of a single Git command. All
+communication is in pkt-line format (see linkgit:gitprotocol-common[5])
+over standard input and standard output.
+
+Handshake
+---------
+
+Git starts by sending a welcome message (for example,
+"git-filter-client"), a list of supported protocol version numbers, and
+a flush packet. Git expects to read the welcome message with "server"
+instead of "client" (for example, "git-filter-server"), exactly one
+protocol version number from the previously sent list, and a flush
+packet. All further communication will be based on the selected version.
+The remaining protocol description below documents "version=2". Please
+note that "version=42" in the example below does not exist and is only
+there to illustrate how the protocol would look like with more than one
+version.
+
+After the version negotiation Git sends a list of all capabilities that
+it supports and a flush packet. Git expects to read a list of desired
+capabilities, which must be a subset of the supported capabilities list,
+and a flush packet as response:
+------------------------
+packet: git> git-filter-client
+packet: git> version=2
+packet: git> version=42
+packet: git> 0000
+packet: git< git-filter-server
+packet: git< version=2
+packet: git< 0000
+packet: git> capability=clean
+packet: git> capability=smudge
+packet: git> capability=not-yet-invented
+packet: git> 0000
+packet: git< capability=clean
+packet: git< capability=smudge
+packet: git< 0000
+------------------------
+
+Shutdown
+--------
+
+Git will close
+the command pipe on exit. The filter is expected to detect EOF
+and exit gracefully on its own. Git will wait until the filter
+process has stopped.
diff --git a/technical/multi-pack-index.adoc b/technical/multi-pack-index.adoc
new file mode 100644
index 0000000..cc063b3
--- /dev/null
+++ b/technical/multi-pack-index.adoc
@@ -0,0 +1,203 @@
+Multi-Pack-Index (MIDX) Design Notes
+====================================
+
+The Git object directory contains a 'pack' directory containing
+packfiles (with suffix ".pack") and pack-indexes (with suffix
+".idx"). The pack-indexes provide a way to lookup objects and
+navigate to their offset within the pack, but these must come
+in pairs with the packfiles. This pairing depends on the file
+names, as the pack-index differs only in suffix with its pack-
+file. While the pack-indexes provide fast lookup per packfile,
+this performance degrades as the number of packfiles increases,
+because abbreviations need to inspect every packfile and we are
+more likely to have a miss on our most-recently-used packfile.
+For some large repositories, repacking into a single packfile
+is not feasible due to storage space or excessive repack times.
+
+The multi-pack-index (MIDX for short) stores a list of objects
+and their offsets into multiple packfiles. It contains:
+
+* A list of packfile names.
+* A sorted list of object IDs.
+* A list of metadata for the ith object ID including:
+** A value j referring to the jth packfile.
+** An offset within the jth packfile for the object.
+* If large offsets are required, we use another list of large
+ offsets similar to version 2 pack-indexes.
+- An optional list of objects in pseudo-pack order (used with MIDX bitmaps).
+
+Thus, we can provide O(log N) lookup time for any number
+of packfiles.
+
+Design Details
+--------------
+
+- The MIDX is stored in a file named 'multi-pack-index' in the
+ .git/objects/pack directory. This could be stored in the pack
+ directory of an alternate. It refers only to packfiles in that
+ same directory.
+
+- The core.multiPackIndex config setting must be on (which is the
+ default) to consume MIDX files. Setting it to `false` prevents
+ Git from reading a MIDX file, even if one exists.
+
+- The file format includes parameters for the object ID hash
+ function, so a future change of hash algorithm does not require
+ a change in format.
+
+- The MIDX keeps only one record per object ID. If an object appears
+ in multiple packfiles, then the MIDX selects the copy in the
+ preferred packfile, otherwise selecting from the most-recently
+ modified packfile.
+
+- If there exist packfiles in the pack directory not registered in
+ the MIDX, then those packfiles are loaded into the `packed_git`
+ list and `packed_git_mru` cache.
+
+- The pack-indexes (.idx files) remain in the pack directory so we
+ can delete the MIDX file, set core.midx to false, or downgrade
+ without any loss of information.
+
+- The MIDX file format uses a chunk-based approach (similar to the
+ commit-graph file) that allows optional data to be added.
+
+Incremental multi-pack indexes
+------------------------------
+
+As repositories grow in size, it becomes more expensive to write a
+multi-pack index (MIDX) that includes all packfiles. To accommodate
+this, the "incremental multi-pack indexes" feature allows for combining
+a "chain" of multi-pack indexes.
+
+Each individual component of the chain need only contain a small number
+of packfiles. Appending to the chain does not invalidate earlier parts
+of the chain, so repositories can control how much time is spent
+updating the MIDX chain by determining the number of packs in each layer
+of the MIDX chain.
+
+=== Design state
+
+At present, the incremental multi-pack indexes feature is missing two
+important components:
+
+ - The ability to rewrite earlier portions of the MIDX chain (i.e., to
+ "compact" some collection of adjacent MIDX layers into a single
+ MIDX). At present the only supported way of shrinking a MIDX chain
+ is to rewrite the entire chain from scratch without the `--split`
+ flag.
++
+There are no fundamental limitations that stand in the way of being able
+to implement this feature. It is omitted from the initial implementation
+in order to reduce the complexity, but will be added later.
+
+ - Support for reachability bitmaps. The classic single MIDX
+ implementation does support reachability bitmaps (see the section
+ titled "multi-pack-index reverse indexes" in
+ linkgit:gitformat-pack[5] for more details).
++
+As above, there are no fundamental limitations that stand in the way of
+extending the incremental MIDX format to support reachability bitmaps.
+The design below specifically takes this into account, and support for
+reachability bitmaps will be added in a future patch series. It is
+omitted from the current implementation for the same reason as above.
++
+In brief, to support reachability bitmaps with the incremental MIDX
+feature, the concept of the pseudo-pack order is extended across each
+layer of the incremental MIDX chain to form a concatenated pseudo-pack
+order. This concatenation takes place in the same order as the chain
+itself (in other words, the concatenated pseudo-pack order for a chain
+`{$H1, $H2, $H3}` would be the pseudo-pack order for `$H1`, followed by
+the pseudo-pack order for `$H2`, followed by the pseudo-pack order for
+`$H3`).
++
+The layout will then be extended so that each layer of the incremental
+MIDX chain can write a `*.bitmap`. The objects in each layer's bitmap
+are offset by the number of objects in the previous layers of the chain.
+
+=== File layout
+
+Instead of storing a single `multi-pack-index` file (with an optional
+`.rev` and `.bitmap` extension) in `$GIT_DIR/objects/pack`, incremental
+MIDXs are stored in the following layout:
+
+----
+$GIT_DIR/objects/pack/multi-pack-index.d/
+$GIT_DIR/objects/pack/multi-pack-index.d/multi-pack-index-chain
+$GIT_DIR/objects/pack/multi-pack-index.d/multi-pack-index-$H1.midx
+$GIT_DIR/objects/pack/multi-pack-index.d/multi-pack-index-$H2.midx
+$GIT_DIR/objects/pack/multi-pack-index.d/multi-pack-index-$H3.midx
+----
+
+The `multi-pack-index-chain` file contains a list of the incremental
+MIDX files in the chain, in order. The above example shows a chain whose
+`multi-pack-index-chain` file would contain the following lines:
+
+----
+$H1
+$H2
+$H3
+----
+
+The `multi-pack-index-$H1.midx` file contains the first layer of the
+multi-pack-index chain. The `multi-pack-index-$H2.midx` file contains
+the second layer of the chain, and so on.
+
+When both an incremental- and non-incremental MIDX are present, the
+non-incremental MIDX is always read first.
+
+=== Object positions for incremental MIDXs
+
+In the original multi-pack-index design, we refer to objects via their
+lexicographic position (by object IDs) within the repository's singular
+multi-pack-index. In the incremental multi-pack-index design, we refer
+to objects via their index into a concatenated lexicographic ordering
+among each component in the MIDX chain.
+
+If `objects_nr()` is a function that returns the number of objects in a
+given MIDX layer, then the index of an object at lexicographic position
+`i` within, say, $H3 is defined as:
+
+----
+objects_nr($H2) + objects_nr($H1) + i
+----
+
+(in the C implementation, this is often computed as `i +
+m->num_objects_in_base`).
+
+Future Work
+-----------
+
+- The multi-pack-index allows many packfiles, especially in a context
+ where repacking is expensive (such as a very large repo), or
+ unexpected maintenance time is unacceptable (such as a high-demand
+ build machine). However, the multi-pack-index needs to be rewritten
+ in full every time. We can extend the format to be incremental, so
+ writes are fast. By storing a small "tip" multi-pack-index that
+ points to large "base" MIDX files, we can keep writes fast while
+ still reducing the number of binary searches required for object
+ lookups.
+
+- If the multi-pack-index is extended to store a "stable object order"
+ (a function Order(hash) = integer that is constant for a given hash,
+ even as the multi-pack-index is updated) then MIDX bitmaps could be
+ updated independently of the MIDX.
+
+- Packfiles can be marked as "special" using empty files that share
+ the initial name but replace ".pack" with ".keep" or ".promisor".
+ We can add an optional chunk of data to the multi-pack-index that
+ records flags of information about the packfiles. This allows new
+ states, such as 'repacked' or 'redeltified', that can help with
+ pack maintenance in a multi-pack environment. It may also be
+ helpful to organize packfiles by object type (commit, tree, blob,
+ etc.) and use this metadata to help that maintenance.
+
+Related Links
+-------------
+[0] https://bugs.chromium.org/p/git/issues/detail?id=6
+ Chromium work item for: Multi-Pack Index (MIDX)
+
+[1] https://lore.kernel.org/git/20180107181459.222909-1-dstolee@microsoft.com/
+ An earlier RFC for the multi-pack-index feature
+
+[2] https://lore.kernel.org/git/alpine.DEB.2.20.1803091557510.23109@alexmv-linux/
+ Git Merge 2018 Contributor's summit notes (includes discussion of MIDX)
diff --git a/technical/pack-heuristics.adoc b/technical/pack-heuristics.adoc
new file mode 100644
index 0000000..95a07db
--- /dev/null
+++ b/technical/pack-heuristics.adoc
@@ -0,0 +1,460 @@
+Concerning Git's Packing Heuristics
+===================================
+
+ Oh, here's a really stupid question:
+
+ Where do I go
+ to learn the details
+ of Git's packing heuristics?
+
+Be careful what you ask!
+
+Followers of the Git, please open the Git IRC Log and turn to
+February 10, 2006.
+
+It's a rare occasion, and we are joined by the King Git Himself,
+Linus Torvalds (linus). Nathaniel Smith, (njs`), has the floor
+and seeks enlightenment. Others are present, but silent.
+
+Let's listen in!
+
+ <njs`> Oh, here's a really stupid question -- where do I go to
+ learn the details of Git's packing heuristics? google avails
+ me not, reading the source didn't help a lot, and wading
+ through the whole mailing list seems less efficient than any
+ of that.
+
+It is a bold start! A plea for help combined with a simultaneous
+tri-part attack on some of the tried and true mainstays in the quest
+for enlightenment. Brash accusations of google being useless. Hubris!
+Maligning the source. Heresy! Disdain for the mailing list archives.
+Woe.
+
+ <pasky> yes, the packing-related delta stuff is somewhat
+ mysterious even for me ;)
+
+Ah! Modesty after all.
+
+ <linus> njs, I don't think the docs exist. That's something where
+ I don't think anybody else than me even really got involved.
+ Most of the rest of Git others have been busy with (especially
+ Junio), but packing nobody touched after I did it.
+
+It's cryptic, yet vague. Linus in style for sure. Wise men
+interpret this as an apology. A few argue it is merely a
+statement of fact.
+
+ <njs`> I guess the next step is "read the source again", but I
+ have to build up a certain level of gumption first :-)
+
+Indeed! On both points.
+
+ <linus> The packing heuristic is actually really really simple.
+
+Bait...
+
+ <linus> But strange.
+
+And switch. That ought to do it!
+
+ <linus> Remember: Git really doesn't follow files. So what it does is
+ - generate a list of all objects
+ - sort the list according to magic heuristics
+ - walk the list, using a sliding window, seeing if an object
+ can be diffed against another object in the window
+ - write out the list in recency order
+
+The traditional understatement:
+
+ <njs`> I suspect that what I'm missing is the precise definition of
+ the word "magic"
+
+The traditional insight:
+
+ <pasky> yes
+
+And Babel-like confusion flowed.
+
+ <njs`> oh, hmm, and I'm not sure what this sliding window means either
+
+ <pasky> iirc, it appeared to me to be just the sha1 of the object
+ when reading the code casually ...
+
+ ... which simply doesn't sound as a very good heuristics, though ;)
+
+ <njs`> .....and recency order. okay, I think it's clear I didn't
+ even realize how much I wasn't realizing :-)
+
+Ah, grasshopper! And thus the enlightenment begins anew.
+
+ <linus> The "magic" is actually in theory totally arbitrary.
+ ANY order will give you a working pack, but no, it's not
+ ordered by SHA-1.
+
+ Before talking about the ordering for the sliding delta
+ window, let's talk about the recency order. That's more
+ important in one way.
+
+ <njs`> Right, but if all you want is a working way to pack things
+ together, you could just use cat and save yourself some
+ trouble...
+
+Waaait for it....
+
+ <linus> The recency ordering (which is basically: put objects
+ _physically_ into the pack in the order that they are
+ "reachable" from the head) is important.
+
+ <njs`> okay
+
+ <linus> It's important because that's the thing that gives packs
+ good locality. It keeps the objects close to the head (whether
+ they are old or new, but they are _reachable_ from the head)
+ at the head of the pack. So packs actually have absolutely
+ _wonderful_ IO patterns.
+
+Read that again, because it is important.
+
+ <linus> But recency ordering is totally useless for deciding how
+ to actually generate the deltas, so the delta ordering is
+ something else.
+
+ The delta ordering is (wait for it):
+ - first sort by the "basename" of the object, as defined by
+ the name the object was _first_ reached through when
+ generating the object list
+ - within the same basename, sort by size of the object
+ - but always sort different types separately (commits first).
+
+ That's not exactly it, but it's very close.
+
+ <njs`> The "_first_ reached" thing is not too important, just you
+ need some way to break ties since the same objects may be
+ reachable many ways, yes?
+
+And as if to clarify:
+
+ <linus> The point is that it's all really just any random
+ heuristic, and the ordering is totally unimportant for
+ correctness, but it helps a lot if the heuristic gives
+ "clumping" for things that are likely to delta well against
+ each other.
+
+It is an important point, so secretly, I did my own research and have
+included my results below. To be fair, it has changed some over time.
+And through the magic of Revisionistic History, I draw upon this entry
+from The Git IRC Logs on my father's birthday, March 1:
+
+ <gitster> The quote from the above linus should be rewritten a
+ bit (wait for it):
+ - first sort by type. Different objects never delta with
+ each other.
+ - then sort by filename/dirname. hash of the basename
+ occupies the top BITS_PER_INT-DIR_BITS bits, and bottom
+ DIR_BITS are for the hash of leading path elements.
+ - then if we are doing "thin" pack, the objects we are _not_
+ going to pack but we know about are sorted earlier than
+ other objects.
+ - and finally sort by size, larger to smaller.
+
+In one swell-foop, clarification and obscurification! Nonetheless,
+authoritative. Cryptic, yet concise. It even solicits notions of
+quotes from The Source Code. Clearly, more study is needed.
+
+ <gitster> That's the sort order. What this means is:
+ - we do not delta different object types.
+ - we prefer to delta the objects with the same full path, but
+ allow files with the same name from different directories.
+ - we always prefer to delta against objects we are not going
+ to send, if there are some.
+ - we prefer to delta against larger objects, so that we have
+ lots of removals.
+
+ The penultimate rule is for "thin" packs. It is used when
+ the other side is known to have such objects.
+
+There it is again. "Thin" packs. I'm thinking to myself, "What
+is a 'thin' pack?" So I ask:
+
+ <jdl> What is a "thin" pack?
+
+ <gitster> Use of --objects-edge to rev-list as the upstream of
+ pack-objects. The pack transfer protocol negotiates that.
+
+Woo hoo! Cleared that _right_ up!
+
+ <gitster> There are two directions - push and fetch.
+
+There! Did you see it? It is not '"push" and "pull"'! How often the
+confusion has started here. So casually mentioned, too!
+
+ <gitster> For push, git-send-pack invokes git-receive-pack on the
+ other end. The receive-pack says "I have up to these commits".
+ send-pack looks at them, and computes what are missing from
+ the other end. So "thin" could be the default there.
+
+ In the other direction, fetch, git-fetch-pack and
+ git-clone-pack invokes git-upload-pack on the other end
+ (via ssh or by talking to the daemon).
+
+ There are two cases: fetch-pack with -k and clone-pack is one,
+ fetch-pack without -k is the other. clone-pack and fetch-pack
+ with -k will keep the downloaded packfile without expanded, so
+ we do not use thin pack transfer. Otherwise, the generated
+ pack will have delta without base object in the same pack.
+
+ But fetch-pack without -k will explode the received pack into
+ individual objects, so we automatically ask upload-pack to
+ give us a thin pack if upload-pack supports it.
+
+OK then.
+
+Uh.
+
+Let's return to the previous conversation still in progress.
+
+ <njs`> and "basename" means something like "the tail of end of
+ path of file objects and dir objects, as per basename(3), and
+ we just declare all commit and tag objects to have the same
+ basename" or something?
+
+Luckily, that too is a point that gitster clarified for us!
+
+If I might add, the trick is to make files that _might_ be similar be
+located close to each other in the hash buckets based on their file
+names. It used to be that "foo/Makefile", "bar/baz/quux/Makefile" and
+"Makefile" all landed in the same bucket due to their common basename,
+"Makefile". However, now they land in "close" buckets.
+
+The algorithm allows not just for the _same_ bucket, but for _close_
+buckets to be considered delta candidates. The rationale is
+essentially that files, like Makefiles, often have very similar
+content no matter what directory they live in.
+
+ <linus> I played around with different delta algorithms, and with
+ making the "delta window" bigger, but having too big of a
+ sliding window makes it very expensive to generate the pack:
+ you need to compare every object with a _ton_ of other objects.
+
+ There are a number of other trivial heuristics too, which
+ basically boil down to "don't bother even trying to delta this
+ pair" if we can tell before-hand that the delta isn't worth it
+ (due to size differences, where we can take a previous delta
+ result into account to decide that "ok, no point in trying
+ that one, it will be worse").
+
+ End result: packing is actually very size efficient. It's
+ somewhat CPU-wasteful, but on the other hand, since you're
+ really only supposed to do it maybe once a month (and you can
+ do it during the night), nobody really seems to care.
+
+Nice Engineering Touch, there. Find when it doesn't matter, and
+proclaim it a non-issue. Good style too!
+
+ <njs`> So, just to repeat to see if I'm following, we start by
+ getting a list of the objects we want to pack, we sort it by
+ this heuristic (basically lexicographically on the tuple
+ (type, basename, size)).
+
+ Then we walk through this list, and calculate a delta of
+ each object against the last n (tunable parameter) objects,
+ and pick the smallest of these deltas.
+
+Vastly simplified, but the essence is there!
+
+ <linus> Correct.
+
+ <njs`> And then once we have picked a delta or fulltext to
+ represent each object, we re-sort by recency, and write them
+ out in that order.
+
+ <linus> Yup. Some other small details:
+
+And of course there is the "Other Shoe" Factor too.
+
+ <linus> - We limit the delta depth to another magic value (right
+ now both the window and delta depth magic values are just "10")
+
+ <njs`> Hrm, my intuition is that you'd end up with really _bad_ IO
+ patterns, because the things you want are near by, but to
+ actually reconstruct them you may have to jump all over in
+ random ways.
+
+ <linus> - When we write out a delta, and we haven't yet written
+ out the object it is a delta against, we write out the base
+ object first. And no, when we reconstruct them, we actually
+ get nice IO patterns, because:
+ - larger objects tend to be "more recent" (Linus' law: files grow)
+ - we actively try to generate deltas from a larger object to a
+ smaller one
+ - this means that the top-of-tree very seldom has deltas
+ (i.e. deltas in _practice_ are "backwards deltas")
+
+Again, we should reread that whole paragraph. Not just because
+Linus has slipped Linus's Law in there on us, but because it is
+important. Let's make sure we clarify some of the points here:
+
+ <njs`> So the point is just that in practice, delta order and
+ recency order match each other quite well.
+
+ <linus> Yes. There's another nice side to this (and yes, it was
+ designed that way ;):
+ - the reason we generate deltas against the larger object is
+ actually a big space saver too!
+
+ <njs`> Hmm, but your last comment (if "we haven't yet written out
+ the object it is a delta against, we write out the base object
+ first"), seems like it would make these facts mostly
+ irrelevant because even if in practice you would not have to
+ wander around much, in fact you just brute-force say that in
+ the cases where you might have to wander, don't do that :-)
+
+ <linus> Yes and no. Notice the rule: we only write out the base
+ object first if the delta against it was more recent. That
+ means that you can actually have deltas that refer to a base
+ object that is _not_ close to the delta object, but that only
+ happens when the delta is needed to generate an _old_ object.
+
+ <linus> See?
+
+Yeah, no. I missed that on the first two or three readings myself.
+
+ <linus> This keeps the front of the pack dense. The front of the
+ pack never contains data that isn't relevant to a "recent"
+ object. The size optimization comes from our use of xdelta
+ (but is true for many other delta algorithms): removing data
+ is cheaper (in size) than adding data.
+
+ When you remove data, you only need to say "copy bytes n--m".
+ In contrast, in a delta that _adds_ data, you have to say "add
+ these bytes: 'actual data goes here'"
+
+ *** njs` has quit: Read error: 104 (Connection reset by peer)
+
+ <linus> Uhhuh. I hope I didn't blow njs` mind.
+
+ *** njs` has joined channel #git
+
+ <pasky> :)
+
+The silent observers are amused. Of course.
+
+And as if njs` was expected to be omniscient:
+
+ <linus> njs - did you miss anything?
+
+OK, I'll spell it out. That's Geek Humor. If njs` was not actually
+connected for a little bit there, how would he know if missed anything
+while he was disconnected? He's a benevolent dictator with a sense of
+humor! Well noted!
+
+ <njs`> Stupid router. Or gremlins, or whatever.
+
+It's a cheap shot at Cisco. Take 'em when you can.
+
+ <njs`> Yes and no. Notice the rule: we only write out the base
+ object first if the delta against it was more recent.
+
+ I'm getting lost in all these orders, let me re-read :-)
+ So the write-out order is from most recent to least recent?
+ (Conceivably it could be the opposite way too, I'm not sure if
+ we've said) though my connection back at home is logging, so I
+ can just read what you said there :-)
+
+And for those of you paying attention, the Omniscient Trick has just
+been detailed!
+
+ <linus> Yes, we always write out most recent first
+
+ <njs`> And, yeah, I got the part about deeper-in-history stuff
+ having worse IO characteristics, one sort of doesn't care.
+
+ <linus> With the caveat that if the "most recent" needs an older
+ object to delta against (hey, shrinking sometimes does
+ happen), we write out the old object with the delta.
+
+ <njs`> (if only it happened more...)
+
+ <linus> Anyway, the pack-file could easily be denser still, but
+ because it's used both for streaming (the Git protocol) and
+ for on-disk, it has a few pessimizations.
+
+Actually, it is a made-up word. But it is a made-up word being
+used as setup for a later optimization, which is a real word:
+
+ <linus> In particular, while the pack-file is then compressed,
+ it's compressed just one object at a time, so the actual
+ compression factor is less than it could be in theory. But it
+ means that it's all nice random-access with a simple index to
+ do "object name->location in packfile" translation.
+
+ <njs`> I'm assuming the real win for delta-ing large->small is
+ more homogeneous statistics for gzip to run over?
+
+ (You have to put the bytes in one place or another, but
+ putting them in a larger blob wins on compression)
+
+ Actually, what is the compression strategy -- each delta
+ individually gzipped, the whole file gzipped, somewhere in
+ between, no compression at all, ....?
+
+ Right.
+
+Reality IRC sets in. For example:
+
+ <pasky> I'll read the rest in the morning, I really have to go
+ sleep or there's no hope whatsoever for me at the today's
+ exam... g'nite all.
+
+Heh.
+
+ <linus> pasky: g'nite
+
+ <njs`> pasky: 'luck
+
+ <linus> Right: large->small matters exactly because of compression
+ behaviour. If it was non-compressed, it probably wouldn't make
+ any difference.
+
+ <njs`> yeah
+
+ <linus> Anyway: I'm not even trying to claim that the pack-files
+ are perfect, but they do tend to have a nice balance of
+ density vs ease-of use.
+
+Gasp! OK, saved. That's a fair Engineering trade off. Close call!
+In fact, Linus reflects on some Basic Engineering Fundamentals,
+design options, etc.
+
+ <linus> More importantly, they allow Git to still _conceptually_
+ never deal with deltas at all, and be a "whole object" store.
+
+ Which has some problems (we discussed bad huge-file
+ behaviour on the Git lists the other day), but it does mean
+ that the basic Git concepts are really really simple and
+ straightforward.
+
+ It's all been quite stable.
+
+ Which I think is very much a result of having very simple
+ basic ideas, so that there's never any confusion about what's
+ going on.
+
+ Bugs happen, but they are "simple" bugs. And bugs that
+ actually get some object store detail wrong are almost always
+ so obvious that they never go anywhere.
+
+ <njs`> Yeah.
+
+Nuff said.
+
+ <linus> Anyway. I'm off for bed. It's not 6AM here, but I've got
+ three kids, and have to get up early in the morning to send
+ them off. I need my beauty sleep.
+
+ <njs`> :-)
+
+ <njs`> appreciate the infodump, I really was failing to find the
+ details on Git packs :-)
+
+And now you know the rest of the story.
diff --git a/technical/packfile-uri.adoc b/technical/packfile-uri.adoc
new file mode 100644
index 0000000..9d453d4
--- /dev/null
+++ b/technical/packfile-uri.adoc
@@ -0,0 +1,82 @@
+Packfile URIs
+=============
+
+This feature allows servers to serve part of their packfile response as URIs.
+This allows server designs that improve scalability in bandwidth and CPU usage
+(for example, by serving some data through a CDN), and (in the future) provides
+some measure of resumability to clients.
+
+This feature is available only in protocol version 2.
+
+Protocol
+--------
+
+The server advertises the `packfile-uris` capability.
+
+If the client then communicates which protocols (HTTPS, etc.) it supports with
+a `packfile-uris` argument, the server MAY send a `packfile-uris` section
+directly before the `packfile` section (right after `wanted-refs` if it is
+sent) containing URIs of any of the given protocols. The URIs point to
+packfiles that use only features that the client has declared that it supports
+(e.g. ofs-delta and thin-pack). See linkgit:gitprotocol-v2[5] for the documentation of
+this section.
+
+Clients should then download and index all the given URIs (in addition to
+downloading and indexing the packfile given in the `packfile` section of the
+response) before performing the connectivity check.
+
+Server design
+-------------
+
+The server can be trivially made compatible with the proposed protocol by
+having it advertise `packfile-uris`, tolerating the client sending
+`packfile-uris`, and never sending any `packfile-uris` section. But we should
+include some sort of non-trivial implementation in the Minimum Viable Product,
+at least so that we can test the client.
+
+This is the implementation: a feature, marked experimental, that allows the
+server to be configured by one or more `uploadpack.blobPackfileUri=
+<object-hash> <pack-hash> <uri>` entries. Whenever the list of objects to be
+sent is assembled, all such blobs are excluded, replaced with URIs. As noted
+in "Future work" below, the server can evolve in the future to support
+excluding other objects (or other implementations of servers could be made
+that support excluding other objects) without needing a protocol change, so
+clients should not expect that packfiles downloaded in this way only contain
+single blobs.
+
+Client design
+-------------
+
+The client has a config variable `fetch.uriprotocols` that determines which
+protocols the end user is willing to use. By default, this is empty.
+
+When the client downloads the given URIs, it should store them with "keep"
+files, just like it does with the packfile in the `packfile` section. These
+additional "keep" files can only be removed after the refs have been updated -
+just like the "keep" file for the packfile in the `packfile` section.
+
+The division of work (initial fetch + additional URIs) introduces convenient
+points for resumption of an interrupted clone - such resumption can be done
+after the Minimum Viable Product (see "Future work").
+
+Future work
+-----------
+
+The protocol design allows some evolution of the server and client without any
+need for protocol changes, so only a small-scoped design is included here to
+form the MVP. For example, the following can be done:
+
+ * On the server, more sophisticated means of excluding objects (e.g. by
+ specifying a commit to represent that commit and all objects that it
+ references).
+ * On the client, resumption of clone. If a clone is interrupted, information
+ could be recorded in the repository's config and a "clone-resume" command
+ can resume the clone in progress. (Resumption of subsequent fetches is more
+ difficult because that must deal with the user wanting to use the repository
+ even after the fetch was interrupted.)
+
+There are some possible features that will require a change in protocol:
+
+ * Additional HTTP headers (e.g. authentication)
+ * Byte range support
+ * Different file formats referenced by URIs (e.g. raw object)
diff --git a/technical/parallel-checkout.adoc b/technical/parallel-checkout.adoc
new file mode 100644
index 0000000..b4a144e
--- /dev/null
+++ b/technical/parallel-checkout.adoc
@@ -0,0 +1,270 @@
+Parallel Checkout Design Notes
+==============================
+
+The "Parallel Checkout" feature attempts to use multiple processes to
+parallelize the work of uncompressing the blobs, applying in-core
+filters, and writing the resulting contents to the working tree during a
+checkout operation. It can be used by all checkout-related commands,
+such as `clone`, `checkout`, `reset`, `sparse-checkout`, and others.
+
+These commands share the following basic structure:
+
+* Step 1: Read the current index file into memory.
+
+* Step 2: Modify the in-memory index based upon the command, and
+ temporarily mark all cache entries that need to be updated.
+
+* Step 3: Populate the working tree to match the new candidate index.
+ This includes iterating over all of the to-be-updated cache entries
+ and delete, create, or overwrite the associated files in the working
+ tree.
+
+* Step 4: Write the new index to disk.
+
+Step 3 is the focus of the "parallel checkout" effort described here.
+
+Sequential Implementation
+-------------------------
+
+For the purposes of discussion here, the current sequential
+implementation of Step 3 is divided in 3 parts, each one implemented in
+its own function:
+
+* Step 3a: `unpack-trees.c:check_updates()` contains a series of
+ sequential loops iterating over the `cache_entry`'s array. The main
+ loop in this function calls the Step 3b function for each of the
+ to-be-updated entries.
+
+* Step 3b: `entry.c:checkout_entry()` examines the existing working tree
+ for file conflicts, collisions, and unsaved changes. It removes files
+ and creates leading directories as necessary. It calls the Step 3c
+ function for each entry to be written.
+
+* Step 3c: `entry.c:write_entry()` loads the blob into memory, smudges
+ it if necessary, creates the file in the working tree, writes the
+ smudged contents, calls `fstat()` or `lstat()`, and updates the
+ associated `cache_entry` struct with the stat information gathered.
+
+It wouldn't be safe to perform Step 3b in parallel, as there could be
+race conditions between file creations and removals. Instead, the
+parallel checkout framework lets the sequential code handle Step 3b,
+and uses parallel workers to replace the sequential
+`entry.c:write_entry()` calls from Step 3c.
+
+Rejected Multi-Threaded Solution
+--------------------------------
+
+The most "straightforward" implementation would be to spread the set of
+to-be-updated cache entries across multiple threads. But due to the
+thread-unsafe functions in the object database code, we would have to use locks to
+coordinate the parallel operation. An early prototype of this solution
+showed that the multi-threaded checkout would bring performance
+improvements over the sequential code, but there was still too much lock
+contention. A `perf` profiling indicated that around 20% of the runtime
+during a local Linux clone (on an SSD) was spent in locking functions.
+For this reason this approach was rejected in favor of using multiple
+child processes, which led to better performance.
+
+Multi-Process Solution
+----------------------
+
+Parallel checkout alters the aforementioned Step 3 to use multiple
+`checkout--worker` background processes to distribute the work. The
+long-running worker processes are controlled by the foreground Git
+command using the existing run-command API.
+
+Overview
+~~~~~~~~
+
+Step 3b is only slightly altered; for each entry to be checked out, the
+main process performs the following steps:
+
+* M1: Check whether there is any untracked or unclean file in the
+ working tree which would be overwritten by this entry, and decide
+ whether to proceed (removing the file(s)) or not.
+
+* M2: Create the leading directories.
+
+* M3: Load the conversion attributes for the entry's path.
+
+* M4: Check, based on the entry's type and conversion attributes,
+ whether the entry is eligible for parallel checkout (more on this
+ later). If it is eligible, enqueue the entry and the loaded
+ attributes to later write the entry in parallel. If not, write the
+ entry right away, using the default sequential code.
+
+Note: we save the conversion attributes associated with each entry
+because the workers don't have access to the main process' index state,
+so they can't load the attributes by themselves (and the attributes are
+needed to properly smudge the entry). Additionally, this has a positive
+impact on performance as (1) we don't need to load the attributes twice
+and (2) the attributes machinery is optimized to handle paths in
+sequential order.
+
+After all entries have passed through the above steps, the main process
+checks if the number of enqueued entries is sufficient to spread among
+the workers. If not, it just writes them sequentially. Otherwise, it
+spawns the workers and distributes the queued entries uniformly in
+continuous chunks. This aims to minimize the chances of two workers
+writing to the same directory simultaneously, which could increase lock
+contention in the kernel.
+
+Then, for each assigned item, each worker:
+
+* W1: Checks if there is any non-directory file in the leading part of
+ the entry's path or if there already exists a file at the entry' path.
+ If so, mark the entry with `PC_ITEM_COLLIDED` and skip it (more on
+ this later).
+
+* W2: Creates the file (with O_CREAT and O_EXCL).
+
+* W3: Loads the blob into memory (inflating and delta reconstructing
+ it).
+
+* W4: Applies any required in-process filter, like end-of-line
+ conversion and re-encoding.
+
+* W5: Writes the result to the file descriptor opened at W2.
+
+* W6: Calls `fstat()` or `lstat()` on the just-written path, and sends
+ the result back to the main process, together with the end status of
+ the operation and the item's identification number.
+
+Note that, when possible, steps W3 to W5 are delegated to the streaming
+machinery, removing the need to keep the entire blob in memory.
+
+If the worker fails to read the blob or to write it to the working tree,
+it removes the created file to avoid leaving empty files behind. This is
+the *only* time a worker is allowed to remove a file.
+
+As mentioned earlier, it is the responsibility of the main process to
+remove any file that blocks the checkout operation (or abort if the
+removal(s) would cause data loss and the user didn't ask to `--force`).
+This is crucial to avoid race conditions and also to properly detect
+path collisions at Step W1.
+
+After the workers finish writing the items and sending back the required
+information, the main process handles the results in two steps:
+
+- First, it updates the in-memory index with the `lstat()` information
+ sent by the workers. (This must be done first as this information
+ might be required in the following step.)
+
+- Then it writes the items which collided on disk (i.e. items marked
+ with `PC_ITEM_COLLIDED`). More on this below.
+
+Path Collisions
+---------------
+
+Path collisions happen when two different paths correspond to the same
+entry in the file system. E.g. the paths 'a' and 'A' would collide in a
+case-insensitive file system.
+
+The sequential checkout deals with collisions in the same way that it
+deals with files that were already present in the working tree before
+checkout. Basically, it checks if the path that it wants to write
+already exists on disk, makes sure the existing file doesn't have
+unsaved data, and then overwrites it. (To be more pedantic: it deletes
+the existing file and creates the new one.) So, if there are multiple
+colliding files to be checked out, the sequential code will write each
+one of them but only the last will actually survive on disk.
+
+Parallel checkout aims to reproduce the same behavior. However, we
+cannot let the workers racily write to the same file on disk. Instead,
+the workers detect when the entry that they want to check out would
+collide with an existing file, and mark it with `PC_ITEM_COLLIDED`.
+Later, the main process can sequentially feed these entries back to
+`checkout_entry()` without the risk of race conditions. On clone, this
+also has the effect of marking the colliding entries to later emit a
+warning for the user, like the classic sequential checkout does.
+
+The workers are able to detect both collisions among the entries being
+concurrently written and collisions between a parallel-eligible entry
+and an ineligible entry. The general idea for collision detection is
+quite straightforward: for each parallel-eligible entry, the main
+process must remove all files that prevent this entry from being written
+(before enqueueing it). This includes any non-directory file in the
+leading path of the entry. Later, when a worker gets assigned the entry,
+it looks again for the non-directory files and for an already existing
+file at the entry's path. If any of these checks finds something, the
+worker knows that there was a path collision.
+
+Because parallel checkout can distinguish path collisions from the case
+where the file was already present in the working tree before checkout,
+we could alternatively choose to skip the checkout of colliding entries.
+However, each entry that doesn't get written would have NULL `lstat()`
+fields on the index. This could cause performance penalties for
+subsequent commands that need to refresh the index, as they would have
+to go to the file system to see if the entry is dirty. Thus, if we have
+N entries in a colliding group and we decide to write and `lstat()` only
+one of them, every subsequent `git-status` will have to read, convert,
+and hash the written file N - 1 times. By checking out all colliding
+entries (like the sequential code does), we only pay the overhead once,
+during checkout.
+
+Eligible Entries for Parallel Checkout
+--------------------------------------
+
+As previously mentioned, not all entries passed to `checkout_entry()`
+will be considered eligible for parallel checkout. More specifically, we
+exclude:
+
+- Symbolic links; to avoid race conditions that, in combination with
+ path collisions, could cause workers to write files at the wrong
+ place. For example, if we were to concurrently check out a symlink
+ 'a' -> 'b' and a regular file 'A/f' in a case-insensitive file system,
+ we could potentially end up writing the file 'A/f' at 'a/f', due to a
+ race condition.
+
+- Regular files that require external filters (either "one shot" filters
+ or long-running process filters). These filters are black-boxes to Git
+ and may have their own internal locking or non-concurrent assumptions.
+ So it might not be safe to run multiple instances in parallel.
++
+Besides, long-running filters may use the delayed checkout feature to
+postpone the return of some filtered blobs. The delayed checkout queue
+and the parallel checkout queue are not compatible and should remain
+separate.
++
+Note: regular files that only require internal filters, like end-of-line
+conversion and re-encoding, are eligible for parallel checkout.
+
+Ineligible entries are checked out by the classic sequential codepath
+*before* spawning workers.
+
+Note: submodules' files are also eligible for parallel checkout (as
+long as they don't fall into any of the excluding categories mentioned
+above). But since each submodule is checked out in its own child
+process, we don't mix the superproject's and the submodules' files in
+the same parallel checkout process or queue.
+
+The API
+-------
+
+The parallel checkout API was designed with the goal of minimizing
+changes to the current users of the checkout machinery. This means that
+they don't have to call a different function for sequential or parallel
+checkout. As already mentioned, `checkout_entry()` will automatically
+insert the given entry in the parallel checkout queue when this feature
+is enabled and the entry is eligible; otherwise, it will just write the
+entry right away, using the sequential code. In general, callers of the
+parallel checkout API should look similar to this:
+
+----------------------------------------------
+int pc_workers, pc_threshold, err = 0;
+struct checkout state;
+
+get_parallel_checkout_configs(&pc_workers, &pc_threshold);
+
+/*
+ * This check is not strictly required, but it
+ * should save some time in sequential mode.
+ */
+if (pc_workers > 1)
+ init_parallel_checkout();
+
+for (each cache_entry ce to-be-updated)
+ err |= checkout_entry(ce, &state, NULL, NULL);
+
+err |= run_parallel_checkout(&state, pc_workers, pc_threshold, NULL, NULL);
+----------------------------------------------
diff --git a/technical/partial-clone.adoc b/technical/partial-clone.adoc
new file mode 100644
index 0000000..bf5ec5c
--- /dev/null
+++ b/technical/partial-clone.adoc
@@ -0,0 +1,367 @@
+Partial Clone Design Notes
+==========================
+
+The "Partial Clone" feature is a performance optimization for Git that
+allows Git to function without having a complete copy of the repository.
+The goal of this work is to allow Git to better handle extremely large
+repositories.
+
+During clone and fetch operations, Git downloads the complete contents
+and history of the repository. This includes all commits, trees, and
+blobs for the complete life of the repository. For extremely large
+repositories, clones can take hours (or days) and consume 100+GiB of disk
+space.
+
+Often in these repositories there are many blobs and trees that the user
+does not need such as:
+
+ 1. files outside of the user's work area in the tree. For example, in
+ a repository with 500K directories and 3.5M files in every commit,
+ we can avoid downloading many objects if the user only needs a
+ narrow "cone" of the source tree.
+
+ 2. large binary assets. For example, in a repository where large build
+ artifacts are checked into the tree, we can avoid downloading all
+ previous versions of these non-mergeable binary assets and only
+ download versions that are actually referenced.
+
+Partial clone allows us to avoid downloading such unneeded objects *in
+advance* during clone and fetch operations and thereby reduce download
+times and disk usage. Missing objects can later be "demand fetched"
+if/when needed.
+
+A remote that can later provide the missing objects is called a
+promisor remote, as it promises to send the objects when
+requested. Initially Git supported only one promisor remote, the origin
+remote from which the user cloned and that was configured in the
+"extensions.partialClone" config option. Later support for more than
+one promisor remote has been implemented.
+
+Use of partial clone requires that the user be online and the origin
+remote or other promisor remotes be available for on-demand fetching
+of missing objects. This may or may not be problematic for the user.
+For example, if the user can stay within the pre-selected subset of
+the source tree, they may not encounter any missing objects.
+Alternatively, the user could try to pre-fetch various objects if they
+know that they are going offline.
+
+
+Non-Goals
+---------
+
+Partial clone is a mechanism to limit the number of blobs and trees downloaded
+*within* a given range of commits -- and is therefore independent of and not
+intended to conflict with existing DAG-level mechanisms to limit the set of
+requested commits (i.e. shallow clone, single branch, or fetch '<refspec>').
+
+
+Design Overview
+---------------
+
+Partial clone logically consists of the following parts:
+
+- A mechanism for the client to describe unneeded or unwanted objects to
+ the server.
+
+- A mechanism for the server to omit such unwanted objects from packfiles
+ sent to the client.
+
+- A mechanism for the client to gracefully handle missing objects (that
+ were previously omitted by the server).
+
+- A mechanism for the client to backfill missing objects as needed.
+
+
+Design Details
+--------------
+
+- A new pack-protocol capability "filter" is added to the fetch-pack and
+ upload-pack negotiation.
++
+This uses the existing capability discovery mechanism.
+See "filter" in linkgit:gitprotocol-pack[5].
+
+- Clients pass a "filter-spec" to clone and fetch which is passed to the
+ server to request filtering during packfile construction.
++
+There are various filters available to accommodate different situations.
+See "--filter=<filter-spec>" in Documentation/rev-list-options.txt.
+
+- On the server pack-objects applies the requested filter-spec as it
+ creates "filtered" packfiles for the client.
++
+These filtered packfiles are *incomplete* in the traditional sense because
+they may contain objects that reference objects not contained in the
+packfile and that the client doesn't already have. For example, the
+filtered packfile may contain trees or tags that reference missing blobs
+or commits that reference missing trees.
+
+- On the client these incomplete packfiles are marked as "promisor packfiles"
+ and treated differently by various commands.
+
+- On the client a repository extension is added to the local config to
+ prevent older versions of git from failing mid-operation because of
+ missing objects that they cannot handle.
+ See `extensions.partialClone` in linkgit:git-config[1].
+
+
+Handling Missing Objects
+------------------------
+
+- An object may be missing due to a partial clone or fetch, or missing
+ due to repository corruption. To differentiate these cases, the
+ local repository specially indicates such filtered packfiles
+ obtained from promisor remotes as "promisor packfiles".
++
+These promisor packfiles consist of a "<name>.promisor" file with
+arbitrary contents (like the "<name>.keep" files), in addition to
+their "<name>.pack" and "<name>.idx" files.
+
+- The local repository considers a "promisor object" to be an object that
+ it knows (to the best of its ability) that promisor remotes have promised
+ that they have, either because the local repository has that object in one of
+ its promisor packfiles, or because another promisor object refers to it.
++
+When Git encounters a missing object, Git can see if it is a promisor object
+and handle it appropriately. If not, Git can report a corruption.
++
+This means that there is no need for the client to explicitly maintain an
+expensive-to-modify list of missing objects.[a]
+
+- Since almost all Git code currently expects any referenced object to be
+ present locally and because we do not want to force every command to do
+ a dry-run first, a fallback mechanism is added to allow Git to attempt
+ to dynamically fetch missing objects from promisor remotes.
++
+When the normal object lookup fails to find an object, Git invokes
+promisor_remote_get_direct() to try to get the object from a promisor
+remote and then retry the object lookup. This allows objects to be
+"faulted in" without complicated prediction algorithms.
++
+For efficiency reasons, no check as to whether the missing object is
+actually a promisor object is performed.
++
+Dynamic object fetching tends to be slow as objects are fetched one at
+a time.
+
+- `checkout` (and any other command using `unpack-trees`) has been taught
+ to bulk pre-fetch all required missing blobs in a single batch.
+
+- `rev-list` has been taught to print missing objects.
++
+This can be used by other commands to bulk prefetch objects.
+For example, a "git log -p A..B" may internally want to first do
+something like "git rev-list --objects --quiet --missing=print A..B"
+and prefetch those objects in bulk.
+
+- `fsck` has been updated to be fully aware of promisor objects.
+
+- `repack` in GC has been updated to not touch promisor packfiles at all,
+ and to only repack other objects.
+
+- The global variable "fetch_if_missing" is used to control whether an
+ object lookup will attempt to dynamically fetch a missing object or
+ report an error.
++
+We are not happy with this global variable and would like to remove it,
+but that requires significant refactoring of the object code to pass an
+additional flag.
+
+
+Fetching Missing Objects
+------------------------
+
+- Fetching of objects is done by invoking a "git fetch" subprocess.
+
+- The local repository sends a request with the hashes of all requested
+ objects, and does not perform any packfile negotiation.
+ It then receives a packfile.
+
+- Because we are reusing the existing fetch mechanism, fetching
+ currently fetches all objects referred to by the requested objects, even
+ though they are not necessary.
+
+- Fetching with `--refetch` will request a complete new filtered packfile from
+ the remote, which can be used to change a filter without needing to
+ dynamically fetch missing objects.
+
+Using many promisor remotes
+---------------------------
+
+Many promisor remotes can be configured and used.
+
+This allows for example a user to have multiple geographically-close
+cache servers for fetching missing blobs while continuing to do
+filtered `git-fetch` commands from the central server.
+
+When fetching objects, promisor remotes are tried one after the other
+until all the objects have been fetched.
+
+Remotes that are considered "promisor" remotes are those specified by
+the following configuration variables:
+
+- `extensions.partialClone = <name>`
+
+- `remote.<name>.promisor = true`
+
+- `remote.<name>.partialCloneFilter = ...`
+
+Only one promisor remote can be configured using the
+`extensions.partialClone` config variable. This promisor remote will
+be the last one tried when fetching objects.
+
+We decided to make it the last one we try, because it is likely that
+someone using many promisor remotes is doing so because the other
+promisor remotes are better for some reason (maybe they are closer or
+faster for some kind of objects) than the origin, and the origin is
+likely to be the remote specified by extensions.partialClone.
+
+This justification is not very strong, but one choice had to be made,
+and anyway the long term plan should be to make the order somehow
+fully configurable.
+
+For now though the other promisor remotes will be tried in the order
+they appear in the config file.
+
+Current Limitations
+-------------------
+
+- It is not possible to specify the order in which the promisor
+ remotes are tried in other ways than the order in which they appear
+ in the config file.
++
+It is also not possible to specify an order to be used when fetching
+from one remote and a different order when fetching from another
+remote.
+
+- It is not possible to push only specific objects to a promisor
+ remote.
++
+It is not possible to push at the same time to multiple promisor
+remote in a specific order.
+
+- Dynamic object fetching will only ask promisor remotes for missing
+ objects. We assume that promisor remotes have a complete view of the
+ repository and can satisfy all such requests.
+
+- Repack essentially treats promisor and non-promisor packfiles as 2
+ distinct partitions and does not mix them.
+
+- Dynamic object fetching invokes fetch-pack once *for each item*
+ because most algorithms stumble upon a missing object and need to have
+ it resolved before continuing their work. This may incur significant
+ overhead -- and multiple authentication requests -- if many objects are
+ needed.
+
+- Dynamic object fetching currently uses the existing pack protocol V0
+ which means that each object is requested via fetch-pack. The server
+ will send a full set of info/refs when the connection is established.
+ If there are a large number of refs, this may incur significant overhead.
+
+
+Future Work
+-----------
+
+- Improve the way to specify the order in which promisor remotes are
+ tried.
++
+For example this could allow specifying explicitly something like:
+"When fetching from this remote, I want to use these promisor remotes
+in this order, though, when pushing or fetching to that remote, I want
+to use those promisor remotes in that order."
+
+- Allow pushing to promisor remotes.
++
+The user might want to work in a triangular work flow with multiple
+promisor remotes that each have an incomplete view of the repository.
+
+- Allow non-pathname-based filters to make use of packfile bitmaps (when
+ present). This was just an omission during the initial implementation.
+
+- Investigate use of a long-running process to dynamically fetch a series
+ of objects, such as proposed in [5,6] to reduce process startup and
+ overhead costs.
++
+It would be nice if pack protocol V2 could allow that long-running
+process to make a series of requests over a single long-running
+connection.
+
+- Investigate pack protocol V2 to avoid the info/refs broadcast on
+ each connection with the server to dynamically fetch missing objects.
+
+- Investigate the need to handle loose promisor objects.
++
+Objects in promisor packfiles are allowed to reference missing objects
+that can be dynamically fetched from the server. An assumption was
+made that loose objects are only created locally and therefore should
+not reference a missing object. We may need to revisit that assumption
+if, for example, we dynamically fetch a missing tree and store it as a
+loose object rather than a single object packfile.
++
+This does not necessarily mean we need to mark loose objects as promisor;
+it may be sufficient to relax the object lookup or is-promisor functions.
+
+
+Non-Tasks
+---------
+
+- Every time the subject of "demand loading blobs" comes up it seems
+ that someone suggests that the server be allowed to "guess" and send
+ additional objects that may be related to the requested objects.
++
+No work has gone into actually doing that; we're just documenting that
+it is a common suggestion. We're not sure how it would work and have
+no plans to work on it.
++
+It is valid for the server to send more objects than requested (even
+for a dynamic object fetch), but we are not building on that.
+
+
+Footnotes
+---------
+
+[a] expensive-to-modify list of missing objects: Earlier in the design of
+ partial clone we discussed the need for a single list of missing objects.
+ This would essentially be a sorted linear list of OIDs that were
+ omitted by the server during a clone or subsequent fetches.
+
+This file would need to be loaded into memory on every object lookup.
+It would need to be read, updated, and re-written (like the .git/index)
+on every explicit "git fetch" command *and* on any dynamic object fetch.
+
+The cost to read, update, and write this file could add significant
+overhead to every command if there are many missing objects. For example,
+if there are 100M missing blobs, this file would be at least 2GiB on disk.
+
+With the "promisor" concept, we *infer* a missing object based upon the
+type of packfile that references it.
+
+
+Related Links
+-------------
+[0] https://crbug.com/git/2
+ Bug#2: Partial Clone
+
+[1] https://lore.kernel.org/git/20170113155253.1644-1-benpeart@microsoft.com/ +
+ Subject: [RFC] Add support for downloading blobs on demand +
+ Date: Fri, 13 Jan 2017 10:52:53 -0500
+
+[2] https://lore.kernel.org/git/cover.1506714999.git.jonathantanmy@google.com/ +
+ Subject: [PATCH 00/18] Partial clone (from clone to lazy fetch in 18 patches) +
+ Date: Fri, 29 Sep 2017 13:11:36 -0700
+
+[3] https://lore.kernel.org/git/20170426221346.25337-1-jonathantanmy@google.com/ +
+ Subject: Proposal for missing blob support in Git repos +
+ Date: Wed, 26 Apr 2017 15:13:46 -0700
+
+[4] https://lore.kernel.org/git/1488999039-37631-1-git-send-email-git@jeffhostetler.com/ +
+ Subject: [PATCH 00/10] RFC Partial Clone and Fetch +
+ Date: Wed, 8 Mar 2017 18:50:29 +0000
+
+[5] https://lore.kernel.org/git/20170505152802.6724-1-benpeart@microsoft.com/ +
+ Subject: [PATCH v7 00/10] refactor the filter process code into a reusable module +
+ Date: Fri, 5 May 2017 11:27:52 -0400
+
+[6] https://lore.kernel.org/git/20170714132651.170708-1-benpeart@microsoft.com/ +
+ Subject: [RFC/PATCH v2 0/1] Add support for downloading blobs on demand +
+ Date: Fri, 14 Jul 2017 09:26:50 -0400
diff --git a/technical/platform-support.adoc b/technical/platform-support.adoc
new file mode 100644
index 0000000..0a2fb28
--- /dev/null
+++ b/technical/platform-support.adoc
@@ -0,0 +1,190 @@
+Platform Support Policy
+=======================
+
+Git has a history of providing broad "support" for exotic platforms and older
+platforms, without an explicit commitment. Stakeholders of these platforms may
+want a more predictable support commitment. This is only possible when platform
+stakeholders supply Git developers with adequate tooling, so we can test for
+compatibility or develop workarounds for platform-specific quirks on our own.
+Various levels of platform-specific tooling will allow us to make more solid
+commitments around Git's compatibility with that platform.
+
+Note that this document is about maintaining existing support for a platform
+that has generally worked in the past; for adding support to a platform which
+doesn't generally work with Git, the stakeholders for that platform are expected
+to do the bulk of that work themselves. We will consider such patches if they
+don't make life harder for other supported platforms or for Git contributors.
+Some contributors may volunteer to help with the initial or continued support,
+but that's not a given. Support work which is too intrusive or difficult for the
+project to maintain may still not be accepted.
+
+Minimum Requirements
+--------------------
+
+The rest of this doc describes best practices for platforms to make themselves
+easy to support. However, before considering support at all, platforms need to
+meet the following minimum requirements:
+
+* Has C99 or C11
+
+* Uses versions of dependencies which are generally accepted as stable and
+ supportable, e.g., in line with the version used by other long-term-support
+ distributions
+
+* Has active security support (taking security releases of dependencies, etc)
+
+These requirements are a starting point, and not sufficient on their own for the
+Git community to be enthusiastic about supporting your platform. Maintainers of
+platforms which do meet these requirements can follow the steps below to make it
+more likely that Git updates will respect the platform's needs.
+
+Compatible by next release
+--------------------------
+
+To increase probability that compatibility issues introduced in a release
+will be fixed in a later release:
+
+* You should send a bug report as soon as you notice the breakage on your
+ platform. The sooner you notice, the better; watching `seen` means you can
+ notice problems before they are considered "done with review"; whereas
+ watching `master` means the stable branch could break for your platform, but
+ you have a decent chance of avoiding a tagged release breaking you. See "The
+ Policy" in link:../howto/maintain-git.html["How to maintain Git"] for an
+ overview of which branches are used in the Git project, and how.
+
+* The bug report should include information about what platform you are using.
+
+* You should also use linkgit:git-bisect[1] and determine which commit
+ introduced the breakage.
+
+* Please include any information you have about the nature of the breakage: is
+ it a memory alignment issue? Is an underlying library missing or broken for
+ your platform? Is there some quirk about your platform which means typical
+ practices (like malloc) behave strangely?
+
+* If possible, build Git from the exact same source both for your platform and
+ for a mainstream platform, to see if the problem you noticed appears only
+ on your platform. If the problem appears in both, then it's not a
+ compatibility issue, but we of course appreciate hearing about it in a bug
+ report anyway, to benefit users of every platform. If it appears only on your
+ platform, mention clearly that it is a compatibility issue in your report.
+
+* Once we begin to fix the issue, please work closely with the contributor
+ working on it to test the proposed fix against your platform.
+
+Example: NonStop
+https://lore.kernel.org/git/01bd01da681a$b8d70a70$2a851f50$@nexbridge.com/[reports
+problems] when they're noticed.
+
+Compatible on `master` and releases
+-----------------------------------
+
+To make sure all stable builds and regular releases work for your platform the
+first time, help us avoid breaking `master` for your platform:
+
+* You should run regular tests against the `next` branch and
+ publish breakage reports to the mailing list immediately when they happen.
+
+** Ideally, these tests should run daily. They must run more often than
+ weekly, as topics generally spend at least 7 days in `next` before graduating
+ to `master`, and it takes time to put the brakes on a patch once it lands in
+ `next`.
+
+** You may want to ask to join the mailto:git-security@googlegroups.com[security
+ mailing list] in order to run tests against the fixes proposed there, too.
+
+* It may make sense to automate these; if you do, make sure they are not noisy
+ (you don't need to send a report when everything works, only when something
+ breaks; you don't need to send repeated reports for the same breakage night
+ after night).
+
+* Breakage reports should be actionable - include clear error messages that can
+ help developers who may not have access to test directly on your platform.
+
+* You should use git-bisect and determine which commit introduced the breakage;
+ if you can't do this with automation, you should do this yourself manually as
+ soon as you notice a breakage report was sent.
+
+* You should either:
+
+** Provide on-demand access to your platform to a trusted developer working to
+ fix the issue, so they can test their fix, OR
+
+** Work closely with the developer fixing the issue; the turnaround to check
+ that their proposed fix works for your platform should be fast enough that it
+ doesn't hinder the developer working on that fix. Slow testing turnarounds
+ may cause the fix to miss the next release, or the developer may lose
+ interest in working on the fix at all.
+
+Example:
+https://lore.kernel.org/git/CAHd-oW6X4cwD_yLNFONPnXXUAFPxgDoccv2SOdpeLrqmHCJB4Q@mail.gmail.com/[AIX]
+provides a build farm and runs tests against release candidates.
+
+Compatible on `next`
+--------------------
+
+To avoid reactive debugging and fixing when changes hit a release or stable, you
+can aim to ensure `next` always works for your platform. (See "The Policy" in
+link:../howto/maintain-git.html["How to maintain Git"] for an overview of how
+`next` is used in the Git project.) To do that:
+
+* You should add a runner for your platform to the GitHub Actions or GitLab CI
+ suite. This suite is run when any Git developer proposes a new patch, and
+ having a runner for your platform/configuration means every developer will
+ know if they break you, immediately.
+
+** If adding it to an existing CI suite is infeasible (due to architecture
+ constraints or for performance reasons), any other method which runs as
+ automatically and quickly as possible works, too. For example, a service
+ which snoops on the mailing list and automatically runs tests on new [PATCH]
+ emails, replying to the author with the results, would also be within the
+ spirit of this requirement.
+
+* If you rely on Git avoiding a specific pattern that doesn't work well with
+ your platform (like a certain malloc pattern), raise it on the mailing list.
+ We'll work case-by-case to look for a solution that doesn't unnecessarily
+ constrain other platforms to keep compatibility with yours.
+
+* If you rely on some configuration or behavior, add a test for it. Untested
+ behavior is subject to breakage at any time.
+
+** Clearly label these tests as necessary for platform compatibility. Add them
+ to an isolated compatibility-related test suite, like a new t* file or unit
+ test suite, so that they're easy to remove when compatibility is no longer
+ required. If the specific compatibility need is gated behind an issue with
+ another project, link to documentation of that issue (like a bug or email
+ thread) to make it easier to tell when that compatibility need goes away.
+
+** Include a comment with an expiration date for these tests no more than 1 year
+ from now. You can update the expiration date if your platform still needs
+ that assurance down the road, but we need to know you still care about that
+ compatibility case and are working to make it unnecessary.
+
+Example: We run our
+https://git.kernel.org/pub/scm/git/git.git/tree/.github/workflows/main.yml[CI
+suite] on Windows, Ubuntu, Mac, and others.
+
+Getting help writing platform support patches
+---------------------------------------------
+
+In general, when sending patches to fix platform support problems, follow
+these guidelines to make sure the patch is reviewed with the appropriate level
+of urgency:
+
+* Clearly state in the commit message that you are fixing a platform breakage,
+ and for which platform.
+
+* Use the CI and test suite to ensure that the fix for your platform doesn't
+ break other platforms.
+
+* If possible, add a test ensuring this regression doesn't happen again. If
+ it's not possible to add a test, explain why in the commit message.
+
+Platform Maintainers
+--------------------
+
+If you maintain a platform, or Git for that platform, and intend to work with
+the Git project to ensure compatibility, please send a patch to add yourself to
+this list.
+
+NonStop: Randall S. Becker <rsbecker@nexbridge.com>
diff --git a/technical/racy-git.adoc b/technical/racy-git.adoc
new file mode 100644
index 0000000..59bea66
--- /dev/null
+++ b/technical/racy-git.adoc
@@ -0,0 +1,201 @@
+Use of index and Racy Git problem
+=================================
+
+Background
+----------
+
+The index is one of the most important data structures in Git.
+It represents a virtual working tree state by recording list of
+paths and their object names and serves as a staging area to
+write out the next tree object to be committed. The state is
+"virtual" in the sense that it does not necessarily have to, and
+often does not, match the files in the working tree.
+
+There are cases where Git needs to examine the differences between the
+virtual working tree state in the index and the files in the
+working tree. The most obvious case is when the user asks `git
+diff` (or its low level implementation, `git diff-files`) or
+`git-ls-files --modified`. In addition, Git internally checks
+if the files in the working tree are different from what are
+recorded in the index to avoid stomping on local changes in them
+during patch application, switching branches, and merging.
+
+In order to speed up this comparison between the files in the
+working tree and the index entries, the index entries record the
+information obtained from the filesystem via `lstat(2)` system
+call when they were last updated. When checking if they differ,
+Git first runs `lstat(2)` on the files and compares the result
+with this information (this is what was originally done by the
+`ce_match_stat()` function, but the current code does it in
+`ce_match_stat_basic()` function). If some of these "cached
+stat information" fields do not match, Git can tell that the
+files are modified without even looking at their contents.
+
+Note: not all members in `struct stat` obtained via `lstat(2)`
+are used for this comparison. For example, `st_atime` obviously
+is not useful. Currently, Git compares the file type (regular
+files vs symbolic links) and executable bits (only for regular
+files) from `st_mode` member, `st_mtime` and `st_ctime`
+timestamps, `st_uid`, `st_gid`, `st_ino`, and `st_size` members.
+With a `USE_STDEV` compile-time option, `st_dev` is also
+compared, but this is not enabled by default because this member
+is not stable on network filesystems. With `USE_NSEC`
+compile-time option, `st_mtim.tv_nsec` and `st_ctim.tv_nsec`
+members are also compared. On Linux, this is not enabled by default
+because in-core timestamps can have finer granularity than
+on-disk timestamps, resulting in meaningless changes when an
+inode is evicted from the inode cache. See commit 8ce13b0
+of git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
+([PATCH] Sync in core time granularity with filesystems,
+2005-01-04). This patch is included in kernel 2.6.11 and newer, but
+only fixes the issue for file systems with exactly 1 ns or 1 s
+resolution. Other file systems are still broken in current Linux
+kernels (e.g. CEPH, CIFS, NTFS, UDF), see
+https://lore.kernel.org/lkml/5577240D.7020309@gmail.com/
+
+Racy Git
+--------
+
+There is one slight problem with the optimization based on the
+cached stat information. Consider this sequence:
+
+ : modify 'foo'
+ $ git update-index 'foo'
+ : modify 'foo' again, in-place, without changing its size
+
+The first `update-index` computes the object name of the
+contents of file `foo` and updates the index entry for `foo`
+along with the `struct stat` information. If the modification
+that follows it happens very fast so that the file's `st_mtime`
+timestamp does not change, after this sequence, the cached stat
+information the index entry records still exactly match what you
+would see in the filesystem, even though the file `foo` is now
+different.
+This way, Git can incorrectly think files in the working tree
+are unmodified even though they actually are. This is called
+the "racy Git" problem (discovered by Pasky), and the entries
+that appear clean when they may not be because of this problem
+are called "racily clean".
+
+To avoid this problem, Git does two things:
+
+. When the cached stat information says the file has not been
+ modified, and the `st_mtime` is the same as (or newer than)
+ the timestamp of the index file itself (which is the time `git
+ update-index foo` finished running in the above example), it
+ also compares the contents with the object registered in the
+ index entry to make sure they match.
+
+. When the index file is updated that contains racily clean
+ entries, cached `st_size` information is truncated to zero
+ before writing a new version of the index file.
+
+Because the index file itself is written after collecting all
+the stat information from updated paths, `st_mtime` timestamp of
+it is usually the same as or newer than any of the paths the
+index contains. And no matter how quick the modification that
+follows `git update-index foo` finishes, the resulting
+`st_mtime` timestamp on `foo` cannot get a value earlier
+than the index file. Therefore, index entries that can be
+racily clean are limited to the ones that have the same
+timestamp as the index file itself.
+
+The callers that want to check if an index entry matches the
+corresponding file in the working tree continue to call
+`ce_match_stat()`, but with this change, `ce_match_stat()` uses
+`ce_modified_check_fs()` to see if racily clean ones are
+actually clean after comparing the cached stat information using
+`ce_match_stat_basic()`.
+
+The problem the latter solves is this sequence:
+
+ $ git update-index 'foo'
+ : modify 'foo' in-place without changing its size
+ : wait for enough time
+ $ git update-index 'bar'
+
+Without the latter, the timestamp of the index file gets a newer
+value, and falsely clean entry `foo` would not be caught by the
+timestamp comparison check done with the former logic anymore.
+The latter makes sure that the cached stat information for `foo`
+would never match with the file in the working tree, so later
+checks by `ce_match_stat_basic()` would report that the index entry
+does not match the file and Git does not have to fall back on more
+expensive `ce_modified_check_fs()`.
+
+
+Runtime penalty
+---------------
+
+The runtime penalty of falling back to `ce_modified_check_fs()`
+from `ce_match_stat()` can be very expensive when there are many
+racily clean entries. An obvious way to artificially create
+this situation is to give the same timestamp to all the files in
+the working tree in a large project, run `git update-index` on
+them, and give the same timestamp to the index file:
+
+ $ date >.datestamp
+ $ git ls-files | xargs touch -r .datestamp
+ $ git ls-files | git update-index --stdin
+ $ touch -r .datestamp .git/index
+
+This will make all index entries racily clean. The linux project, for
+example, there are over 20,000 files in the working tree. On my
+Athlon 64 X2 3800+, after the above:
+
+ $ /usr/bin/time git diff-files
+ 1.68user 0.54system 0:02.22elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
+ 0inputs+0outputs (0major+67111minor)pagefaults 0swaps
+ $ git update-index MAINTAINERS
+ $ /usr/bin/time git diff-files
+ 0.02user 0.12system 0:00.14elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
+ 0inputs+0outputs (0major+935minor)pagefaults 0swaps
+
+Running `git update-index` in the middle checked the racily
+clean entries, and left the cached `st_mtime` for all the paths
+intact because they were actually clean (so this step took about
+the same amount of time as the first `git diff-files`). After
+that, they are not racily clean anymore but are truly clean, so
+the second invocation of `git diff-files` fully took advantage
+of the cached stat information.
+
+
+Avoiding runtime penalty
+------------------------
+
+In order to avoid the above runtime penalty, post 1.4.2 Git used
+to have a code that made sure the index file
+got a timestamp newer than the youngest files in the index when
+there were many young files with the same timestamp as the
+resulting index file otherwise would have by waiting
+before finishing writing the index file out.
+
+I suspected that in practice the situation where many paths in the
+index are all racily clean was quite rare. The only code paths
+that can record recent timestamp for large number of paths are:
+
+. Initial `git add .` of a large project.
+
+. `git checkout` of a large project from an empty index into an
+ unpopulated working tree.
+
+Note: switching branches with `git checkout` keeps the cached
+stat information of existing working tree files that are the
+same between the current branch and the new branch, which are
+all older than the resulting index file, and they will not
+become racily clean. Only the files that are actually checked
+out can become racily clean.
+
+In a large project where raciness avoidance cost really matters,
+however, the initial computation of all object names in the
+index takes more than one second, and the index file is written
+out after all that happens. Therefore the timestamp of the
+index file will be more than one second later than the
+youngest file in the working tree. This means that in these
+cases there actually will not be any racily clean entry in
+the resulting index.
+
+Based on this discussion, the current code does not use the
+"workaround" to avoid the runtime penalty that does not exist in
+practice anymore. This was done with commit 0fc82cff on Aug 15,
+2006.
diff --git a/technical/reftable.adoc b/technical/reftable.adoc
new file mode 100644
index 0000000..dd0b37c
--- /dev/null
+++ b/technical/reftable.adoc
@@ -0,0 +1,1098 @@
+reftable
+--------
+
+Overview
+~~~~~~~~
+
+Problem statement
+^^^^^^^^^^^^^^^^^
+
+Some repositories contain a lot of references (e.g. android at 866k,
+rails at 31k). The existing packed-refs format takes up a lot of space
+(e.g. 62M), and does not scale with additional references. Lookup of a
+single reference requires linearly scanning the file.
+
+Atomic pushes modifying multiple references require copying the entire
+packed-refs file, which can be a considerable amount of data moved
+(e.g. 62M in, 62M out) for even small transactions (2 refs modified).
+
+Repositories with many loose references occupy a large number of disk
+blocks from the local file system, as each reference is its own file
+storing 41 bytes (and another file for the corresponding reflog). This
+negatively affects the number of inodes available when a large number of
+repositories are stored on the same filesystem. Readers can be penalized
+due to the larger number of syscalls required to traverse and read the
+`$GIT_DIR/refs` directory.
+
+
+Objectives
+^^^^^^^^^^
+
+* Near constant time lookup for any single reference, even when the
+repository is cold and not in process or kernel cache.
+* Near constant time verification if an object name is referred to by at least
+one reference (for allow-tip-sha1-in-want).
+* Efficient enumeration of an entire namespace, such as `refs/tags/`.
+* Support atomic push with `O(size_of_update)` operations.
+* Combine reflog storage with ref storage for small transactions.
+* Separate reflog storage for base refs and historical logs.
+
+Description
+^^^^^^^^^^^
+
+A reftable file is a portable binary file format customized for
+reference storage. References are sorted, enabling linear scans, binary
+search lookup, and range scans.
+
+Storage in the file is organized into variable sized blocks. Prefix
+compression is used within a single block to reduce disk space. Block
+size and alignment are tunable by the writer.
+
+Performance
+^^^^^^^^^^^
+
+Space used, packed-refs vs. reftable:
+
+[cols=",>,>,>,>,>",options="header",]
+|===============================================================
+|repository |packed-refs |reftable |% original |avg ref |avg obj
+|android |62.2 M |36.1 M |58.0% |33 bytes |5 bytes
+|rails |1.8 M |1.1 M |57.7% |29 bytes |4 bytes
+|git |78.7 K |48.1 K |61.0% |50 bytes |4 bytes
+|git (heads) |332 b |269 b |81.0% |33 bytes |0 bytes
+|===============================================================
+
+Scan (read 866k refs), by reference name lookup (single ref from 866k
+refs), and by SHA-1 lookup (refs with that SHA-1, from 866k refs):
+
+[cols=",>,>,>,>",options="header",]
+|=========================================================
+|format |cache |scan |by name |by SHA-1
+|packed-refs |cold |402 ms |409,660.1 usec |412,535.8 usec
+|packed-refs |hot | |6,844.6 usec |20,110.1 usec
+|reftable |cold |112 ms |33.9 usec |323.2 usec
+|reftable |hot | |20.2 usec |320.8 usec
+|=========================================================
+
+Space used for 149,932 log entries for 43,061 refs, reflog vs. reftable:
+
+[cols=",>,>",options="header",]
+|================================
+|format |size |avg entry
+|$GIT_DIR/logs |173 M |1209 bytes
+|reftable |5 M |37 bytes
+|================================
+
+Details
+~~~~~~~
+
+Peeling
+^^^^^^^
+
+References stored in a reftable are peeled, a record for an annotated
+(or signed) tag records both the tag object, and the object it refers
+to. This is analogous to storage in the packed-refs format.
+
+Reference name encoding
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Reference names are an uninterpreted sequence of bytes that must pass
+linkgit:git-check-ref-format[1] as a valid reference name.
+
+Key unicity
+^^^^^^^^^^^
+
+Each entry must have a unique key; repeated keys are disallowed.
+
+Network byte order
+^^^^^^^^^^^^^^^^^^
+
+All multi-byte, fixed width fields are in network byte order.
+
+Varint encoding
+^^^^^^^^^^^^^^^
+
+Varint encoding is identical to the ofs-delta encoding method used
+within pack files.
+
+Decoder works as follows:
+
+....
+val = buf[ptr] & 0x7f
+while (buf[ptr] & 0x80) {
+ ptr++
+ val = ((val + 1) << 7) | (buf[ptr] & 0x7f)
+}
+....
+
+Ordering
+^^^^^^^^
+
+Blocks are lexicographically ordered by their first reference.
+
+Directory/file conflicts
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+The reftable format accepts both `refs/heads/foo` and
+`refs/heads/foo/bar` as distinct references.
+
+This property is useful for retaining log records in reftable, but may
+confuse versions of Git using `$GIT_DIR/refs` directory tree to maintain
+references. Users of reftable may choose to continue to reject `foo` and
+`foo/bar` type conflicts to prevent problems for peers.
+
+File format
+~~~~~~~~~~~
+
+Structure
+^^^^^^^^^
+
+A reftable file has the following high-level structure:
+
+....
+first_block {
+ header
+ first_ref_block
+}
+ref_block*
+ref_index*
+obj_block*
+obj_index*
+log_block*
+log_index*
+footer
+....
+
+A log-only file omits the `ref_block`, `ref_index`, `obj_block` and
+`obj_index` sections, containing only the file header and log block:
+
+....
+first_block {
+ header
+}
+log_block*
+log_index*
+footer
+....
+
+In a log-only file, the first log block immediately follows the file
+header, without padding to block alignment.
+
+Block size
+^^^^^^^^^^
+
+The file's block size is arbitrarily determined by the writer, and does
+not have to be a power of 2. The block size must be larger than the
+longest reference name or log entry used in the repository, as
+references cannot span blocks.
+
+Powers of two that are friendly to the virtual memory system or
+filesystem (such as 4k or 8k) are recommended. Larger sizes (64k) can
+yield better compression, with a possible increased cost incurred by
+readers during access.
+
+The largest block size is `16777215` bytes (15.99 MiB).
+
+Block alignment
+^^^^^^^^^^^^^^^
+
+Writers may choose to align blocks at multiples of the block size by
+including `padding` filled with NUL bytes at the end of a block to round
+out to the chosen alignment. When alignment is used, writers must
+specify the alignment with the file header's `block_size` field.
+
+Block alignment is not required by the file format. Unaligned files must
+set `block_size = 0` in the file header, and omit `padding`. Unaligned
+files with more than one ref block must include the link:#Ref-index[ref
+index] to support fast lookup. Readers must be able to read both aligned
+and non-aligned files.
+
+Very small files (e.g. a single ref block) may omit `padding` and the ref
+index to reduce total file size.
+
+Header (version 1)
+^^^^^^^^^^^^^^^^^^
+
+A 24-byte header appears at the beginning of the file:
+
+....
+'REFT'
+uint8( version_number = 1 )
+uint24( block_size )
+uint64( min_update_index )
+uint64( max_update_index )
+....
+
+Aligned files must specify `block_size` to configure readers with the
+expected block alignment. Unaligned files must set `block_size = 0`.
+
+The `min_update_index` and `max_update_index` describe bounds for the
+`update_index` field of all log records in this file. When reftables are
+used in a stack for link:#Update-transactions[transactions], these
+fields can order the files such that the prior file's
+`max_update_index + 1` is the next file's `min_update_index`.
+
+Header (version 2)
+^^^^^^^^^^^^^^^^^^
+
+A 28-byte header appears at the beginning of the file:
+
+....
+'REFT'
+uint8( version_number = 2 )
+uint24( block_size )
+uint64( min_update_index )
+uint64( max_update_index )
+uint32( hash_id )
+....
+
+The header is identical to `version_number=1`, with the 4-byte hash ID
+("sha1" for SHA1 and "s256" for SHA-256) appended to the header.
+
+For maximum backward compatibility, it is recommended to use version 1 when
+writing SHA1 reftables.
+
+First ref block
+^^^^^^^^^^^^^^^
+
+The first ref block shares the same block as the file header, and is 24
+bytes smaller than all other blocks in the file. The first block
+immediately begins after the file header, at position 24.
+
+If the first block is a log block (a log-only file), its block header
+begins immediately at position 24.
+
+Ref block format
+^^^^^^^^^^^^^^^^
+
+A ref block is written as:
+
+....
+'r'
+uint24( block_len )
+ref_record+
+uint24( restart_offset )+
+uint16( restart_count )
+
+padding?
+....
+
+Blocks begin with `block_type = 'r'` and a 3-byte `block_len` which
+encodes the number of bytes in the block up to, but not including the
+optional `padding`. This is always less than or equal to the file's
+block size. In the first ref block, `block_len` includes 24 bytes for
+the file header.
+
+The 2-byte `restart_count` stores the number of entries in the
+`restart_offset` list, which must not be empty. Readers can use
+`restart_count` to binary search between restarts before starting a
+linear scan.
+
+Exactly `restart_count` 3-byte `restart_offset` values precede the
+`restart_count`. Offsets are relative to the start of the block and
+refer to the first byte of any `ref_record` whose name has not been
+prefix compressed. Entries in the `restart_offset` list must be sorted,
+ascending. Readers can start linear scans from any of these records.
+
+A variable number of `ref_record` fill the middle of the block,
+describing reference names and values. The format is described below.
+
+As the first ref block shares the first file block with the file header,
+all `restart_offset` in the first block are relative to the start of the
+file (position 0), and include the file header. This forces the first
+`restart_offset` to be `28`.
+
+ref record
+++++++++++
+
+A `ref_record` describes a single reference, storing both the name and
+its value(s). Records are formatted as:
+
+....
+varint( prefix_length )
+varint( (suffix_length << 3) | value_type )
+suffix
+varint( update_index_delta )
+value?
+....
+
+The `prefix_length` field specifies how many leading bytes of the prior
+reference record's name should be copied to obtain this reference's
+name. This must be 0 for the first reference in any block, and also must
+be 0 for any `ref_record` whose offset is listed in the `restart_offset`
+table at the end of the block.
+
+Recovering a reference name from any `ref_record` is a simple concat:
+
+....
+this_name = prior_name[0..prefix_length] + suffix
+....
+
+The `suffix_length` value provides the number of bytes available in
+`suffix` to copy from `suffix` to complete the reference name.
+
+The `update_index` that last modified the reference can be obtained by
+adding `update_index_delta` to the `min_update_index` from the file
+header: `min_update_index + update_index_delta`.
+
+The `value` follows. Its format is determined by `value_type`, one of
+the following:
+
+* `0x0`: deletion; no value data (see transactions, below)
+* `0x1`: one object name; value of the ref
+* `0x2`: two object names; value of the ref, peeled target
+* `0x3`: symbolic reference: `varint( target_len ) target`
+
+Symbolic references use `0x3`, followed by the complete name of the
+reference target. No compression is applied to the target name.
+
+Types `0x4..0x7` are reserved for future use.
+
+Ref index
+^^^^^^^^^
+
+The ref index stores the name of the last reference from every ref block
+in the file, enabling reduced disk seeks for lookups. Any reference can
+be found by searching the index, identifying the containing block, and
+searching within that block.
+
+The index may be organized into a multi-level index, where the 1st level
+index block points to additional ref index blocks (2nd level), which may
+in turn point to either additional index blocks (e.g. 3rd level) or ref
+blocks (leaf level). Disk reads required to access a ref go up with
+higher index levels. Multi-level indexes may be required to ensure no
+single index block exceeds the file format's max block size of
+`16777215` bytes (15.99 MiB). To achieve constant O(1) disk seeks for
+lookups the index must be a single level, which is permitted to exceed
+the file's configured block size, but not the format's max block size of
+15.99 MiB.
+
+If present, the ref index block(s) appears after the last ref block.
+
+If there are at least 4 ref blocks, a ref index block should be written
+to improve lookup times. Cold reads using the index require 2 disk reads
+(read index, read block), and binary searching < 4 blocks also requires
+<= 2 reads. Omitting the index block from smaller files saves space.
+
+If the file is unaligned and contains more than one ref block, the ref
+index must be written.
+
+Index block format:
+
+....
+'i'
+uint24( block_len )
+index_record+
+uint24( restart_offset )+
+uint16( restart_count )
+
+padding?
+....
+
+The index blocks begin with `block_type = 'i'` and a 3-byte `block_len`
+which encodes the number of bytes in the block, up to but not including
+the optional `padding`.
+
+The `restart_offset` and `restart_count` fields are identical in format,
+meaning and usage as in ref blocks.
+
+To reduce the number of reads required for random access in very large
+files the index block may be larger than other blocks. However, readers
+must hold the entire index in memory to benefit from this, so it's a
+time-space tradeoff in both file size and reader memory.
+
+Increasing the file's block size decreases the index size. Alternatively
+a multi-level index may be used, keeping index blocks within the file's
+block size, but increasing the number of blocks that need to be
+accessed.
+
+index record
+++++++++++++
+
+An index record describes the last entry in another block. Index records
+are written as:
+
+....
+varint( prefix_length )
+varint( (suffix_length << 3) | 0 )
+suffix
+varint( block_position )
+....
+
+Index records use prefix compression exactly like `ref_record`.
+
+Index records store `block_position` after the suffix, specifying the
+absolute position in bytes (from the start of the file) of the block
+that ends with this reference. Readers can seek to `block_position` to
+begin reading the block header.
+
+Readers must examine the block header at `block_position` to determine
+if the next block is another level index block, or the leaf-level ref
+block.
+
+Reading the index
++++++++++++++++++
+
+Readers loading the ref index must first read the footer (below) to
+obtain `ref_index_position`. If not present, the position will be 0. The
+`ref_index_position` is for the 1st level root of the ref index.
+
+Obj block format
+^^^^^^^^^^^^^^^^
+
+Object blocks are optional. Writers may choose to omit object blocks,
+especially if readers will not use the object name to ref mapping.
+
+Object blocks use unique, abbreviated 2-31 byte object name keys, mapping to
+ref blocks containing references pointing to that object directly, or as
+the peeled value of an annotated tag. Like ref blocks, object blocks use
+the file's standard block size. The abbreviation length is available in
+the footer as `obj_id_len`.
+
+To save space in small files, object blocks may be omitted if the ref
+index is not present, as brute force search will only need to read a few
+ref blocks. When missing, readers should brute force a linear search of
+all references to lookup by object name.
+
+An object block is written as:
+
+....
+'o'
+uint24( block_len )
+obj_record+
+uint24( restart_offset )+
+uint16( restart_count )
+
+padding?
+....
+
+Fields are identical to ref block. Binary search using the restart table
+works the same as in reference blocks.
+
+Because object names are abbreviated by writers to the shortest unique
+abbreviation within the reftable, obj key lengths have a variable length. Their
+length must be at least 2 bytes. Readers must compare only for common prefix
+match within an obj block or obj index.
+
+obj record
+++++++++++
+
+An `obj_record` describes a single object abbreviation, and the blocks
+containing references using that unique abbreviation:
+
+....
+varint( prefix_length )
+varint( (suffix_length << 3) | cnt_3 )
+suffix
+varint( cnt_large )?
+varint( position_delta )*
+....
+
+Like in reference blocks, abbreviations are prefix compressed within an
+obj block. On large reftables with many unique objects, higher block
+sizes (64k), and higher restart interval (128), a `prefix_length` of 2
+or 3 and `suffix_length` of 3 may be common in obj records (unique
+abbreviation of 5-6 raw bytes, 10-12 hex digits).
+
+Each record contains `position_count` number of positions for matching
+ref blocks. For 1-7 positions the count is stored in `cnt_3`. When
+`cnt_3 = 0` the actual count follows in a varint, `cnt_large`.
+
+The use of `cnt_3` bets most objects are pointed to by only a single
+reference, some may be pointed to by a couple of references, and very
+few (if any) are pointed to by more than 7 references.
+
+A special case exists when `cnt_3 = 0` and `cnt_large = 0`: there are no
+`position_delta`, but at least one reference starts with this
+abbreviation. A reader that needs exact reference names must scan all
+references to find which specific references have the desired object.
+Writers should use this format when the `position_delta` list would have
+overflowed the file's block size due to a high number of references
+pointing to the same object.
+
+The first `position_delta` is the position from the start of the file.
+Additional `position_delta` entries are sorted ascending and relative to
+the prior entry, e.g. a reader would perform:
+
+....
+pos = position_delta[0]
+prior = pos
+for (j = 1; j < position_count; j++) {
+ pos = prior + position_delta[j]
+ prior = pos
+}
+....
+
+With a position in hand, a reader must linearly scan the ref block,
+starting from the first `ref_record`, testing each reference's object names
+(for `value_type = 0x1` or `0x2`) for full equality. Faster searching by
+object name within a single ref block is not supported by the reftable format.
+Smaller block sizes reduce the number of candidates this step must
+consider.
+
+Obj index
+^^^^^^^^^
+
+The obj index stores the abbreviation from the last entry for every obj
+block in the file, enabling reduced disk seeks for all lookups. It is
+formatted exactly the same as the ref index, but refers to obj blocks.
+
+The obj index should be present if obj blocks are present, as obj blocks
+should only be written in larger files.
+
+Readers loading the obj index must first read the footer (below) to
+obtain `obj_index_position`. If not present, the position will be 0.
+
+Log block format
+^^^^^^^^^^^^^^^^
+
+Unlike ref and obj blocks, log blocks are always unaligned.
+
+Log blocks are variable in size, and do not match the `block_size`
+specified in the file header or footer. Writers should choose an
+appropriate buffer size to prepare a log block for deflation, such as
+`2 * block_size`.
+
+A log block is written as:
+
+....
+'g'
+uint24( block_len )
+zlib_deflate {
+ log_record+
+ uint24( restart_offset )+
+ uint16( restart_count )
+}
+....
+
+Log blocks look similar to ref blocks, except `block_type = 'g'`.
+
+The 4-byte block header is followed by the deflated block contents using
+zlib deflate. The `block_len` in the header is the inflated size
+(including 4-byte block header), and should be used by readers to
+preallocate the inflation output buffer. A log block's `block_len` may
+exceed the file's block size.
+
+Offsets within the log block (e.g. `restart_offset`) still include the
+4-byte header. Readers may prefer prefixing the inflation output buffer
+with the 4-byte header.
+
+Within the deflate container, a variable number of `log_record` describe
+reference changes. The log record format is described below. See ref
+block format (above) for a description of `restart_offset` and
+`restart_count`.
+
+Because log blocks have no alignment or padding between blocks, readers
+must keep track of the bytes consumed by the inflater to know where the
+next log block begins.
+
+log record
+++++++++++
+
+Log record keys are structured as:
+
+....
+ref_name '\0' reverse_int64( update_index )
+....
+
+where `update_index` is the unique transaction identifier. The
+`update_index` field must be unique within the scope of a `ref_name`.
+See the update transactions section below for further details.
+
+The `reverse_int64` function inverses the value so lexicographical
+ordering the network byte order encoding sorts the more recent records
+with higher `update_index` values first:
+
+....
+reverse_int64(int64 t) {
+ return 0xffffffffffffffff - t;
+}
+....
+
+Log records have a similar starting structure to ref and index records,
+utilizing the same prefix compression scheme applied to the log record
+key described above.
+
+....
+ varint( prefix_length )
+ varint( (suffix_length << 3) | log_type )
+ suffix
+ log_data {
+ old_id
+ new_id
+ varint( name_length ) name
+ varint( email_length ) email
+ varint( time_seconds )
+ sint16( tz_offset )
+ varint( message_length ) message
+ }?
+....
+
+Log record entries use `log_type` to indicate what follows:
+
+* `0x0`: deletion; no log data.
+* `0x1`: standard git reflog data using `log_data` above.
+
+The `log_type = 0x0` is mostly useful for `git stash drop`, removing an
+entry from the reflog of `refs/stash` in a transaction file (below),
+without needing to rewrite larger files. Readers reading a stack of
+reflogs must treat this as a deletion.
+
+For `log_type = 0x1`, the `log_data` section follows
+linkgit:git-update-ref[1] logging and includes:
+
+* two object names (old id, new id)
+* varint string of committer's name
+* varint string of committer's email
+* varint time in seconds since epoch (Jan 1, 1970)
+* 2-byte timezone offset in minutes (signed)
+* varint string of message
+
+`tz_offset` is the absolute number of minutes from GMT the committer was
+at the time of the update. For example `GMT-0800` is encoded in reftable
+as `sint16(-480)` and `GMT+0230` is `sint16(150)`.
+
+The committer email does not contain `<` or `>`, it's the value normally
+found between the `<>` in a git commit object header.
+
+The `message_length` may be 0, in which case there was no message
+supplied for the update.
+
+Contrary to traditional reflog (which is a file), renames are encoded as
+a combination of ref deletion and ref creation. A deletion is a log
+record with a zero new_id, and a creation is a log record with a zero old_id.
+
+Reading the log
++++++++++++++++
+
+Readers accessing the log must first read the footer (below) to
+determine the `log_position`. The first block of the log begins at
+`log_position` bytes since the start of the file. The `log_position` is
+not block aligned.
+
+Importing logs
+++++++++++++++
+
+When importing from `$GIT_DIR/logs` writers should globally order all
+log records roughly by timestamp while preserving file order, and assign
+unique, increasing `update_index` values for each log line. Newer log
+records get higher `update_index` values.
+
+Although an import may write only a single reftable file, the reftable
+file must span many unique `update_index`, as each log line requires its
+own `update_index` to preserve semantics.
+
+Log index
+^^^^^^^^^
+
+The log index stores the log key
+(`refname \0 reverse_int64(update_index)`) for the last log record of
+every log block in the file, supporting bounded-time lookup.
+
+A log index block must be written if 2 or more log blocks are written to
+the file. If present, the log index appears after the last log block.
+There is no padding used to align the log index to block alignment.
+
+Log index format is identical to ref index, except the keys are 9 bytes
+longer to include `'\0'` and the 8-byte `reverse_int64(update_index)`.
+Records use `block_position` to refer to the start of a log block.
+
+Reading the index
++++++++++++++++++
+
+Readers loading the log index must first read the footer (below) to
+obtain `log_index_position`. If not present, the position will be 0.
+
+Footer
+^^^^^^
+
+After the last block of the file, a file footer is written. It begins
+like the file header, but is extended with additional data.
+
+....
+ HEADER
+
+ uint64( ref_index_position )
+ uint64( (obj_position << 5) | obj_id_len )
+ uint64( obj_index_position )
+
+ uint64( log_position )
+ uint64( log_index_position )
+
+ uint32( CRC-32 of above )
+....
+
+If a section is missing (e.g. ref index) the corresponding position
+field (e.g. `ref_index_position`) will be 0.
+
+* `obj_position`: byte position for the first obj block.
+* `obj_id_len`: number of bytes used to abbreviate object names in
+obj blocks.
+* `log_position`: byte position for the first log block.
+* `ref_index_position`: byte position for the start of the ref index.
+* `obj_index_position`: byte position for the start of the obj index.
+* `log_index_position`: byte position for the start of the log index.
+
+The size of the footer is 68 bytes for version 1, and 72 bytes for
+version 2.
+
+Reading the footer
+++++++++++++++++++
+
+Readers must first read the file start to determine the version
+number. Then they seek to `file_length - FOOTER_LENGTH` to access the
+footer. A trusted external source (such as `stat(2)`) is necessary to
+obtain `file_length`. When reading the footer, readers must verify:
+
+* 4-byte magic is correct
+* 1-byte version number is recognized
+* 4-byte CRC-32 matches the other 64 bytes (including magic, and
+version)
+
+Once verified, the other fields of the footer can be accessed.
+
+Empty tables
+++++++++++++
+
+A reftable may be empty. In this case, the file starts with a header
+and is immediately followed by a footer.
+
+Binary search
+^^^^^^^^^^^^^
+
+Binary search within a block is supported by the `restart_offset` fields
+at the end of the block. Readers can binary search through the restart
+table to locate between which two restart points the sought reference or
+key should appear.
+
+Each record identified by a `restart_offset` stores the complete key in
+the `suffix` field of the record, making the compare operation during
+binary search straightforward.
+
+Once a restart point lexicographically before the sought reference has
+been identified, readers can linearly scan through the following record
+entries to locate the sought record, terminating if the current record
+sorts after (and therefore the sought key is not present).
+
+Restart point selection
++++++++++++++++++++++++
+
+Writers determine the restart points at file creation. The process is
+arbitrary, but every 16 or 64 records is recommended. Every 16 may be
+more suitable for smaller block sizes (4k or 8k), every 64 for larger
+block sizes (64k).
+
+More frequent restart points reduces prefix compression and increases
+space consumed by the restart table, both of which increase file size.
+
+Less frequent restart points makes prefix compression more effective,
+decreasing overall file size, with increased penalties for readers
+walking through more records after the binary search step.
+
+A maximum of `65535` restart points per block is supported.
+
+Considerations
+~~~~~~~~~~~~~~
+
+Lightweight refs dominate
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The reftable format assumes the vast majority of references are single
+object names valued with common prefixes, such as Gerrit Code Review's
+`refs/changes/` namespace, GitHub's `refs/pulls/` namespace, or many
+lightweight tags in the `refs/tags/` namespace.
+
+Annotated tags storing the peeled object cost an additional object name per
+reference.
+
+Low overhead
+^^^^^^^^^^^^
+
+A reftable with very few references (e.g. git.git with 5 heads) is 269
+bytes for reftable, vs. 332 bytes for packed-refs. This supports
+reftable scaling down for transaction logs (below).
+
+Block size
+^^^^^^^^^^
+
+For a Gerrit Code Review type repository with many change refs, larger
+block sizes (64 KiB) and less frequent restart points (every 64) yield
+better compression due to more references within the block compressing
+against the prior reference.
+
+Larger block sizes reduce the index size, as the reftable will require
+fewer blocks to store the same number of references.
+
+Minimal disk seeks
+^^^^^^^^^^^^^^^^^^
+
+Assuming the index block has been loaded into memory, binary searching
+for any single reference requires exactly 1 disk seek to load the
+containing block.
+
+Scans and lookups dominate
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Scanning all references and lookup by name (or namespace such as
+`refs/heads/`) are the most common activities performed on repositories.
+Object names are stored directly with references to optimize this use case.
+
+Logs are infrequently read
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Logs are infrequently accessed, but can be large. Deflating log blocks
+saves disk space, with some increased penalty at read time.
+
+Logs are stored in an isolated section from refs, reducing the burden on
+reference readers that want to ignore logs. Further, historical logs can
+be isolated into log-only files.
+
+Logs are read backwards
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Logs are frequently accessed backwards (most recent N records for master
+to answer `master@{4}`), so log records are grouped by reference, and
+sorted descending by update index.
+
+Repository format
+~~~~~~~~~~~~~~~~~
+
+Version 1
+^^^^^^^^^
+
+A repository must set its `$GIT_DIR/config` to configure reftable:
+
+....
+[core]
+ repositoryformatversion = 1
+[extensions]
+ refStorage = reftable
+....
+
+Layout
+^^^^^^
+
+A collection of reftable files are stored in the `$GIT_DIR/reftable/` directory.
+Their names should have a random element, such that each filename is globally
+unique; this helps avoid spurious failures on Windows, where open files cannot
+be removed or overwritten. It suggested to use
+`${min_update_index}-${max_update_index}-${random}.ref` as a naming convention.
+
+Log-only files use the `.log` extension, while ref-only and mixed ref
+and log files use `.ref`. extension.
+
+The stack ordering file is `$GIT_DIR/reftable/tables.list` and lists the
+current files, one per line, in order, from oldest (base) to newest
+(most recent):
+
+....
+$ cat .git/reftable/tables.list
+00000001-00000001-RANDOM1.log
+00000002-00000002-RANDOM2.ref
+00000003-00000003-RANDOM3.ref
+....
+
+Readers must read `$GIT_DIR/reftable/tables.list` to determine which
+files are relevant right now, and search through the stack in reverse
+order (last reftable is examined first).
+
+Reftable files not listed in `tables.list` may be new (and about to be
+added to the stack by the active writer), or ancient and ready to be
+pruned.
+
+Backward compatibility
+^^^^^^^^^^^^^^^^^^^^^^
+
+Older clients should continue to recognize the directory as a git
+repository so they don't look for an enclosing repository in parent
+directories. To this end, a reftable-enabled repository must contain the
+following dummy files
+
+* `.git/HEAD`, a regular file containing `ref: refs/heads/.invalid`.
+* `.git/refs/`, a directory
+* `.git/refs/heads`, a regular file
+
+Readers
+^^^^^^^
+
+Readers can obtain a consistent snapshot of the reference space by
+following:
+
+1. Open and read the `tables.list` file.
+2. Open each of the reftable files that it mentions.
+3. If any of the files is missing, goto 1.
+4. Read from the now-open files as long as necessary.
+
+Update transactions
+^^^^^^^^^^^^^^^^^^^
+
+Although reftables are immutable, mutations are supported by writing a
+new reftable and atomically appending it to the stack:
+
+1. Acquire `tables.list.lock`.
+2. Read `tables.list` to determine current reftables.
+3. Select `update_index` to be most recent file's
+`max_update_index + 1`.
+4. Prepare temp reftable `tmp_XXXXXX`, including log entries.
+5. Rename `tmp_XXXXXX` to `${update_index}-${update_index}-${random}.ref`.
+6. Copy `tables.list` to `tables.list.lock`, appending file from (5).
+7. Rename `tables.list.lock` to `tables.list`.
+
+During step 4 the new file's `min_update_index` and `max_update_index`
+are both set to the `update_index` selected by step 3. All log records
+for the transaction use the same `update_index` in their keys. This
+enables later correlation of which references were updated by the same
+transaction.
+
+Because a single `tables.list.lock` file is used to manage locking, the
+repository is single-threaded for writers. Writers may have to busy-spin
+(with backoff) around creating `tables.list.lock`, for up to an
+acceptable wait period, aborting if the repository is too busy to
+mutate. Application servers wrapped around repositories (e.g. Gerrit
+Code Review) can layer their own lock/wait queue to improve fairness to
+writers.
+
+Reference deletions
+^^^^^^^^^^^^^^^^^^^
+
+Deletion of any reference can be explicitly stored by setting the `type`
+to `0x0` and omitting the `value` field of the `ref_record`. This serves
+as a tombstone, overriding any assertions about the existence of the
+reference from earlier files in the stack.
+
+Compaction
+^^^^^^^^^^
+
+A partial stack of reftables can be compacted by merging references
+using a straightforward merge join across reftables, selecting the most
+recent value for output, and omitting deleted references that do not
+appear in remaining, lower reftables.
+
+A compacted reftable should set its `min_update_index` to the smallest
+of the input files' `min_update_index`, and its `max_update_index`
+likewise to the largest input `max_update_index`.
+
+For sake of illustration, assume the stack currently consists of
+reftable files (from oldest to newest): A, B, C, and D. The compactor is
+going to compact B and C, leaving A and D alone.
+
+1. Obtain lock `tables.list.lock` and read the `tables.list` file.
+2. Obtain locks `B.lock` and `C.lock`. Ownership of these locks
+prevents other processes from trying to compact these files.
+3. Release `tables.list.lock`.
+4. Compact `B` and `C` into a temp file
+`${min_update_index}-${max_update_index}_XXXXXX`.
+5. Reacquire lock `tables.list.lock`.
+6. Verify that `B` and `C` are still in the stack, in that order. This
+should always be the case, assuming that other processes are adhering to
+the locking protocol.
+7. Rename `${min_update_index}-${max_update_index}_XXXXXX` to
+`${min_update_index}-${max_update_index}-${random}.ref`.
+8. Write the new stack to `tables.list.lock`, replacing `B` and `C`
+with the file from (4).
+9. Rename `tables.list.lock` to `tables.list`.
+10. Delete `B` and `C`, perhaps after a short sleep to avoid forcing
+readers to backtrack.
+
+This strategy permits compactions to proceed independently of updates.
+
+Each reftable (compacted or not) is uniquely identified by its name, so
+open reftables can be cached by their name.
+
+Windows
+^^^^^^^
+
+On windows, and other systems that do not allow deleting or renaming to open
+files, compaction may succeed, but other readers may prevent obsolete tables
+from being deleted.
+
+On these platforms, the following strategy can be followed: on closing a
+reftable stack, reload `tables.list`, and delete any tables no longer mentioned
+in `tables.list`.
+
+Irregular program exit may still leave about unused files. In this case, a
+cleanup operation should proceed as follows:
+
+* take a lock `tables.list.lock` to prevent concurrent modifications
+* refresh the reftable stack, by reading `tables.list`
+* for each `*.ref` file, remove it if
+** it is not mentioned in `tables.list`, and
+** its max update_index is not beyond the max update_index of the stack
+
+
+Alternatives considered
+~~~~~~~~~~~~~~~~~~~~~~~
+
+bzip packed-refs
+^^^^^^^^^^^^^^^^
+
+`bzip2` can significantly shrink a large packed-refs file (e.g. 62 MiB
+compresses to 23 MiB, 37%). However the bzip format does not support
+random access to a single reference. Readers must inflate and discard
+while performing a linear scan.
+
+Breaking packed-refs into chunks (individually compressing each chunk)
+would reduce the amount of data a reader must inflate, but still leaves
+the problem of indexing chunks to support readers efficiently locating
+the correct chunk.
+
+Given the compression achieved by reftable's encoding, it does not seem
+necessary to add the complexity of bzip/gzip/zlib.
+
+Michael Haggerty's alternate format
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Michael Haggerty proposed
+link:https://lore.kernel.org/git/CAMy9T_HCnyc1g8XWOOWhe7nN0aEFyyBskV2aOMb_fe%2BwGvEJ7A%40mail.gmail.com/[an
+alternate] format to reftable on the Git mailing list. This format uses
+smaller chunks, without the restart table, and avoids block alignment
+with padding. Reflog entries immediately follow each ref, and are thus
+interleaved between refs.
+
+Performance testing indicates reftable is faster for lookups (51%
+faster, 11.2 usec vs. 5.4 usec), although reftable produces a slightly
+larger file (+ ~3.2%, 28.3M vs 29.2M):
+
+[cols=">,>,>,>",options="header",]
+|=====================================
+|format |size |seek cold |seek hot
+|mh-alt |28.3 M |23.4 usec |11.2 usec
+|reftable |29.2 M |19.9 usec |5.4 usec
+|=====================================
+
+JGit Ketch RefTree
+^^^^^^^^^^^^^^^^^^
+
+https://dev.eclipse.org/mhonarc/lists/jgit-dev/msg03073.html[JGit Ketch]
+proposed
+link:https://lore.kernel.org/git/CAJo%3DhJvnAPNAdDcAAwAvU9C4RVeQdoS3Ev9WTguHx4fD0V_nOg%40mail.gmail.com/[RefTree],
+an encoding of references inside Git tree objects stored as part of the
+repository's object database.
+
+The RefTree format adds additional load on the object database storage
+layer (more loose objects, more objects in packs), and relies heavily on
+the packer's delta compression to save space. Namespaces which are flat
+(e.g. thousands of tags in refs/tags) initially create very large loose
+objects, and so RefTree does not address the problem of copying many
+references to modify a handful.
+
+Flat namespaces are not efficiently searchable in RefTree, as tree
+objects in canonical formatting cannot be binary searched. This fails
+the need to handle a large number of references in a single namespace,
+such as GitHub's `refs/pulls`, or a project with many tags.
+
+LMDB
+^^^^
+
+David Turner proposed
+https://lore.kernel.org/git/1455772670-21142-26-git-send-email-dturner@twopensource.com/[using
+LMDB], as LMDB is lightweight (64k of runtime code) and GPL-compatible
+license.
+
+A downside of LMDB is its reliance on a single C implementation. This
+makes embedding inside JGit (a popular reimplementation of Git)
+difficult, and hoisting onto virtual storage (for JGit DFS) virtually
+impossible.
+
+A common format that can be supported by all major Git implementations
+(git-core, JGit, libgit2) is strongly preferred.
diff --git a/technical/remembering-renames.adoc b/technical/remembering-renames.adoc
new file mode 100644
index 0000000..73f4176
--- /dev/null
+++ b/technical/remembering-renames.adoc
@@ -0,0 +1,671 @@
+Rebases and cherry-picks involve a sequence of merges whose results are
+recorded as new single-parent commits. The first parent side of those
+merges represent the "upstream" side, and often include a far larger set of
+changes than the second parent side. Traditionally, the renames on the
+first-parent side of that sequence of merges were repeatedly re-detected
+for every merge. This file explains why it is safe and effective during
+rebases and cherry-picks to remember renames on the upstream side of
+history as an optimization, assuming all merges are automatic and clean
+(i.e. no conflicts and not interrupted for user input or editing).
+
+Outline:
+
+ 0. Assumptions
+
+ 1. How rebasing and cherry-picking work
+
+ 2. Why the renames on MERGE_SIDE1 in any given pick are *always* a
+ superset of the renames on MERGE_SIDE1 for the next pick.
+
+ 3. Why any rename on MERGE_SIDE1 in any given pick is _almost_ always also
+ a rename on MERGE_SIDE1 for the next pick
+
+ 4. A detailed description of the counter-examples to #3.
+
+ 5. Why the special cases in #4 are still fully reasonable to use to pair
+ up files for three-way content merging in the merge machinery, and why
+ they do not affect the correctness of the merge.
+
+ 6. Interaction with skipping of "irrelevant" renames
+
+ 7. Additional items that need to be cached
+
+ 8. How directory rename detection interacts with the above and why this
+ optimization is still safe even if merge.directoryRenames is set to
+ "true".
+
+
+=== 0. Assumptions ===
+
+There are two assumptions that will hold throughout this document:
+
+ * The upstream side where commits are transplanted to is treated as the
+ first parent side when rebase/cherry-pick call the merge machinery
+
+ * All merges are fully automatic
+
+and a third that will hold in sections 2-5 for simplicity, that I'll later
+address in section 8:
+
+ * No directory renames occur
+
+
+Let me explain more about each assumption and why I include it:
+
+
+The first assumption is merely for the purposes of making this document
+clearer; the optimization implementation does not actually depend upon it.
+However, the assumption does hold in all cases because it reflects the way
+that both rebase and cherry-pick were implemented; and the implementation
+of cherry-pick and rebase are not readily changeable for backwards
+compatibility reasons (see for example the discussion of the --ours and
+--theirs flag in the documentation of `git checkout`, particularly the
+comments about how they behave with rebase). The optimization avoids
+checking first-parent-ness, though. It checks the conditions that make the
+optimization valid instead, so it would still continue working if someone
+changed the parent ordering that cherry-pick and rebase use. But making
+this assumption does make this document much clearer and prevents me from
+having to repeat every example twice.
+
+If the second assumption is violated, then the optimization simply is
+turned off and thus isn't relevant to consider. The second assumption can
+also be stated as "there is no interruption for a user to resolve conflicts
+or to just further edit or tweak files". While real rebases and
+cherry-picks are often interrupted (either because it's an interactive
+rebase where the user requested to stop and edit, or because there were
+conflicts that the user needs to resolve), the cache of renames is not
+stored on disk, and thus is thrown away as soon as the rebase or cherry
+pick stops for the user to resolve the operation.
+
+The third assumption makes sections 2-5 simpler, and allows people to
+understand the basics of why this optimization is safe and effective, and
+then I can go back and address the specifics in section 8. It is probably
+also worth noting that if directory renames do occur, then the default of
+merge.directoryRenames being set to "conflict" means that the operation
+will stop for users to resolve the conflicts and the cache will be thrown
+away, and thus that there won't be an optimization to apply. So, the only
+reason we need to address directory renames specifically, is that some
+users will have set merge.directoryRenames to "true" to allow the merges to
+continue to proceed automatically. The optimization is still safe with
+this config setting, but we have to discuss a few more cases to show why;
+this discussion is deferred until section 8.
+
+
+=== 1. How rebasing and cherry-picking work ===
+
+Consider the following setup (from the git-rebase manpage):
+
+ A---B---C topic
+ /
+ D---E---F---G main
+
+After rebasing or cherry-picking topic onto main, this will appear as:
+
+ A'--B'--C' topic
+ /
+ D---E---F---G main
+
+The way the commits A', B', and C' are created is through a series of
+merges, where rebase or cherry-pick sequentially uses each of the three
+A-B-C commits in a special merge operation. Let's label the three commits
+in the merge operation as MERGE_BASE, MERGE_SIDE1, and MERGE_SIDE2. For
+this picture, the three commits for each of the three merges would be:
+
+To create A':
+ MERGE_BASE: E
+ MERGE_SIDE1: G
+ MERGE_SIDE2: A
+
+To create B':
+ MERGE_BASE: A
+ MERGE_SIDE1: A'
+ MERGE_SIDE2: B
+
+To create C':
+ MERGE_BASE: B
+ MERGE_SIDE1: B'
+ MERGE_SIDE2: C
+
+Sometimes, folks are surprised that these three-way merges are done. It
+can be useful in understanding these three-way merges to view them in a
+slightly different light. For example, in creating C', you can view it as
+either:
+
+ * Apply the changes between B & C to B'
+ * Apply the changes between B & B' to C
+
+Conceptually the two statements above are the same as a three-way merge of
+B, B', and C, at least the parts before you decide to record a commit.
+
+
+=== 2. Why the renames on MERGE_SIDE1 in any given pick are always a ===
+=== superset of the renames on MERGE_SIDE1 for the next pick. ===
+
+The merge machinery uses the filenames it is fed from MERGE_BASE,
+MERGE_SIDE1, and MERGE_SIDE2. It will only move content to a different
+filename under one of three conditions:
+
+ * To make both pieces of a conflict available to a user during conflict
+ resolution (examples: directory/file conflict, add/add type conflict
+ such as symlink vs. regular file)
+
+ * When MERGE_SIDE1 renames the file.
+
+ * When MERGE_SIDE2 renames the file.
+
+First, let's remember what commits are involved in the first and second
+picks of the cherry-pick or rebase sequence:
+
+To create A':
+ MERGE_BASE: E
+ MERGE_SIDE1: G
+ MERGE_SIDE2: A
+
+To create B':
+ MERGE_BASE: A
+ MERGE_SIDE1: A'
+ MERGE_SIDE2: B
+
+So, in particular, we need to show that the renames between E and G are a
+superset of those between A and A'.
+
+A' is created by the first merge. A' will only have renames for one of the
+three reasons listed above. The first case, a conflict, results in a
+situation where the cache is dropped and thus this optimization doesn't
+take effect, so we need not consider that case. The third case, a rename
+on MERGE_SIDE2 (i.e. from G to A), will show up in A' but it also shows up
+in A -- therefore when diffing A and A' that path does not show up as a
+rename. The only remaining way for renames to show up in A' is for the
+rename to come from MERGE_SIDE1. Therefore, all renames between A and A'
+are a subset of those between E and G. Equivalently, all renames between E
+and G are a superset of those between A and A'.
+
+
+=== 3. Why any rename on MERGE_SIDE1 in any given pick is _almost_ ===
+=== always also a rename on MERGE_SIDE1 for the next pick. ===
+
+Let's again look at the first two picks:
+
+To create A':
+ MERGE_BASE: E
+ MERGE_SIDE1: G
+ MERGE_SIDE2: A
+
+To create B':
+ MERGE_BASE: A
+ MERGE_SIDE1: A'
+ MERGE_SIDE2: B
+
+Now let's look at any given rename from MERGE_SIDE1 of the first pick, i.e.
+any given rename from E to G. Let's use the filenames 'oldfile' and
+'newfile' for demonstration purposes. That first pick will function as
+follows; when the rename is detected, the merge machinery will do a
+three-way content merge of the following:
+ E:oldfile
+ G:newfile
+ A:oldfile
+and produce a new result:
+ A':newfile
+
+Note above that I've assumed that E->A did not rename oldfile. If that
+side did rename, then we most likely have a rename/rename(1to2) conflict
+that will cause the rebase or cherry-pick operation to halt and drop the
+in-memory cache of renames and thus doesn't need to be considered further.
+In the special case that E->A does rename the file but also renames it to
+newfile, then there is no conflict from the renaming and the merge can
+succeed. In this special case, the rename is not valid to cache because
+the second merge will find A:newfile in the MERGE_BASE (see also the new
+testcases in t6429 with "rename same file identically" in their
+description). So a rename/rename(1to1) needs to be specially handled by
+pruning renames from the cache and decrementing the dir_rename_counts in
+the current and leading directories associated with those renames. Or,
+since these are really rare, one could just take the easy way out and
+disable the remembering renames optimization when a rename/rename(1to1)
+happens.
+
+The previous paragraph handled the cases for E->A renaming oldfile, let's
+continue assuming that oldfile is not renamed in A.
+
+As per the diagram for creating B', MERGE_SIDE1 involves the changes from A
+to A'. So, we are curious whether A:oldfile and A':newfile will be viewed
+as renames. Note that:
+
+ * There will be no A':oldfile (because there could not have been a
+ G:oldfile as we do not do break detection in the merge machinery and
+ G:newfile was detected as a rename, and by the construction of the
+ rename above that merged cleanly, the merge machinery will ensure there
+ is no 'oldfile' in the result).
+
+ * There will be no A:newfile (if there had been, we would have had a
+ rename/add conflict).
+
+ * Clearly A:oldfile and A':newfile are "related" (A':newfile came from a
+ clean three-way content merge involving A:oldfile).
+
+We can also expound on the third point above, by noting that three-way
+content merges can also be viewed as applying the differences between the
+base and one side to the other side. Thus we can view A':newfile as
+having been created by taking the changes between E:oldfile and G:newfile
+(which were detected as being related, i.e. <50% changed) to A:oldfile.
+
+Thus A:oldfile and A':newfile are just as related as E:oldfile and
+G:newfile are -- they have exactly identical differences. Since the latter
+were detected as renames, A:oldfile and A':newfile should also be
+detectable as renames almost always.
+
+
+=== 4. A detailed description of the counter-examples to #3. ===
+
+We already noted in section 3 that rename/rename(1to1) (i.e. both sides
+renaming a file the same way) was one counter-example. The more
+interesting bit, though, is why did we need to use the "almost" qualifier
+when stating that A:oldfile and A':newfile are "almost" always detectable
+as renames?
+
+Let's repeat an earlier point that section 3 made:
+
+ A':newfile was created by applying the changes between E:oldfile and
+ G:newfile to A:oldfile. The changes between E:oldfile and G:newfile were
+ <50% of the size of E:oldfile.
+
+If those changes that were <50% of the size of E:oldfile are also <50% of
+the size of A:oldfile, then A:oldfile and A':newfile will be detectable as
+renames. However, if there is a dramatic size reduction between E:oldfile
+and A:oldfile (but the changes between E:oldfile, G:newfile, and A:oldfile
+still somehow merge cleanly), then traditional rename detection would not
+detect A:oldfile and A':newfile as renames.
+
+Here's an example where that can happen:
+ * E:oldfile had 20 lines
+ * G:newfile added 10 new lines at the beginning of the file
+ * A:oldfile kept the first 3 lines of the file, and deleted all the rest
+then
+ => A':newfile would have 13 lines, 3 of which matches those in A:oldfile.
+E:oldfile -> G:newfile would be detected as a rename, but A:oldfile and
+A':newfile would not be.
+
+
+=== 5. Why the special cases in #4 are still fully reasonable to use to ===
+=== pair up files for three-way content merging in the merge machinery, ===
+=== and why they do not affect the correctness of the merge. ===
+
+In the rename/rename(1to1) case, A:newfile and A':newfile are not renames
+since they use the *same* filename. However, files with the same filename
+are obviously fine to pair up for three-way content merging (the merge
+machinery has never employed break detection). The interesting
+counter-example case is thus not the rename/rename(1to1) case, but the case
+where A did not rename oldfile. That was the case that we spent most of
+the time discussing in sections 3 and 4. The remainder of this section
+will be devoted to that case as well.
+
+So, even if A:oldfile and A':newfile aren't detectable as renames, why is
+it still reasonable to pair them up for three-way content merging in the
+merge machinery? There are multiple reasons:
+
+ * As noted in sections 3 and 4, the diff between A:oldfile and A':newfile
+ is *exactly* the same as the diff between E:oldfile and G:newfile. The
+ latter pair were detected as renames, so it seems unlikely to surprise
+ users for us to treat A:oldfile and A':newfile as renames.
+
+ * In fact, "oldfile" and "newfile" were at one point detected as renames
+ due to how they were constructed in the E..G chain. And we used that
+ information once already in this rebase/cherry-pick. I think users
+ would be unlikely to be surprised at us continuing to treat the files
+ as renames and would quickly understand why we had done so.
+
+ * Marking or declaring files as renames is *not* the end goal for merges.
+ Merges use renames to determine which files make sense to be paired up
+ for three-way content merges.
+
+ * A:oldfile and A':newfile were _already_ paired up in a three-way
+ content merge; that is how A':newfile was created. In fact, that
+ three-way content merge was clean. So using them again in a later
+ three-way content merge seems very reasonable.
+
+However, the above is focusing on the common scenarios. Let's try to look
+at all possible unusual scenarios and compare without the optimization to
+with the optimization. Consider the following theoretical cases; we will
+then dive into each to determine which of them are possible,
+and if so, what they mean:
+
+ 1. Without the optimization, the second merge results in a conflict.
+ With the optimization, the second merge also results in a conflict.
+ Questions: Are the conflicts confusingly different? Better in one case?
+
+ 2. Without the optimization, the second merge results in NO conflict.
+ With the optimization, the second merge also results in NO conflict.
+ Questions: Are the merges the same?
+
+ 3. Without the optimization, the second merge results in a conflict.
+ With the optimization, the second merge results in NO conflict.
+ Questions: Possible? Bug, bugfix, or something else?
+
+ 4. Without the optimization, the second merge results in NO conflict.
+ With the optimization, the second merge results in a conflict.
+ Questions: Possible? Bug, bugfix, or something else?
+
+I'll consider all four cases, but out of order.
+
+The fourth case is impossible. For the code without the remembering
+renames optimization to not get a conflict, B:oldfile would need to exactly
+match A:oldfile -- if it doesn't, there would be a modify/delete conflict.
+If A:oldfile matches B:oldfile exactly, then a three-way content merge
+between A:oldfile, A':newfile, and B:oldfile would have no conflict and
+just give us the version of newfile from A' as the result.
+
+From the same logic as the above paragraph, the second case would indeed
+result in identical merges. When A:oldfile exactly matches B:oldfile, an
+undetected rename would say, "Oh, I see one side didn't modify 'oldfile'
+and the other side deleted it. I'll delete it. And I see you have this
+brand new file named 'newfile' in A', so I'll keep it." That gives the
+same results as three-way content merging A:oldfile, A':newfile, and
+B:oldfile -- a removal of oldfile with the version of newfile from A'
+showing up in the result.
+
+The third case is interesting. It means that A:oldfile and A':newfile were
+not just similar enough, but that the changes between them did not conflict
+with the changes between A:oldfile and B:oldfile. This would validate our
+hunch that the files were similar enough to be used in a three-way content
+merge, and thus seems entirely correct for us to have used them that way.
+(Sidenote: One particular example here may be enlightening. Let's say that
+B was an immediate revert of A. B clearly would have been a clean revert
+of A, since A was B's immediate parent. One would assume that if you can
+pick a commit, you should also be able to cherry-pick its immediate revert.
+However, this is one of those funny corner cases; without this
+optimization, we just successfully picked a commit cleanly, but we are
+unable to cherry-pick its immediate revert due to the size differences
+between E:oldfile and A:oldfile.)
+
+That leaves only the first case to consider -- when we get conflicts both
+with or without the optimization. Without the optimization, we'll have a
+modify/delete conflict, where both A':newfile and B:oldfile are left in the
+tree for the user to deal with and no hints about the potential similarity
+between the two. With the optimization, we'll have a three-way content
+merged A:oldfile, A':newfile, and B:oldfile with conflict markers
+suggesting we thought the files were related but giving the user the chance
+to resolve. As noted above, I don't think users will find us treating
+'oldfile' and 'newfile' as related as a surprise since they were between E
+and G. In any event, though, this case shouldn't be concerning since we
+hit a conflict in both cases, told the user what we know, and asked them to
+resolve it.
+
+So, in summary, case 4 is impossible, case 2 yields the same behavior, and
+cases 1 and 3 seem to provide as good or better behavior with the
+optimization than without.
+
+
+=== 6. Interaction with skipping of "irrelevant" renames ===
+
+Previous optimizations involved skipping rename detection for paths
+considered to be "irrelevant". See for example the following commits:
+
+ * 32a56dfb99 ("merge-ort: precompute subset of sources for which we
+ need rename detection", 2021-03-11)
+ * 2fd9eda462 ("merge-ort: precompute whether directory rename
+ detection is needed", 2021-03-11)
+ * 9bd342137e ("diffcore-rename: determine which relevant_sources are
+ no longer relevant", 2021-03-13)
+
+Relevance is always determined by what the _other_ side of history has
+done, in terms of modifying a file that our side renamed, or adding a
+file to a directory which our side renamed. This means that a path
+that is "irrelevant" when picking the first commit of a series in a
+rebase or cherry-pick, may suddenly become "relevant" when picking the
+next commit.
+
+The upshot of this is that we can only cache rename detection results
+for relevant paths, and need to re-check relevance in subsequent
+commits. If those subsequent commits have additional paths that are
+relevant for rename detection, then we will need to redo rename
+detection -- though we can limit it to the paths for which we have not
+already detected renames.
+
+
+=== 7. Additional items that need to be cached ===
+
+It turns out we have to cache more than just renames; we also cache:
+
+ A) non-renames (i.e. unpaired deletes)
+ B) counts of renames within directories
+ C) sources that were marked as RELEVANT_LOCATION, but which were
+ downgraded to RELEVANT_NO_MORE
+ D) the toplevel trees involved in the merge
+
+These are all stored in struct rename_info, and respectively appear in
+ * cached_pairs (along side actual renames, just with a value of NULL)
+ * dir_rename_counts
+ * cached_irrelevant
+ * merge_trees
+
+The reason for (A) comes from the irrelevant renames skipping
+optimization discussed in section 6. The fact that irrelevant renames
+are skipped means we only get a subset of the potential renames
+detected and subsequent commits may need to run rename detection on
+the upstream side on a subset of the remaining renames (to get the
+renames that are relevant for that later commit). Since unpaired
+deletes are involved in rename detection too, we don't want to
+repeatedly check that those paths remain unpaired on the upstream side
+with every commit we are transplanting.
+
+The reason for (B) is that diffcore_rename_extended() is what
+generates the counts of renames by directory which is needed in
+directory rename detection, and if we don't run
+diffcore_rename_extended() again then we need to have the output from
+it, including dir_rename_counts, from the previous run.
+
+The reason for (C) is that merge-ort's tree traversal will again think
+those paths are relevant (marking them as RELEVANT_LOCATION), but the
+fact that they were downgraded to RELEVANT_NO_MORE means that
+dir_rename_counts already has the information we need for directory
+rename detection. (A path which becomes RELEVANT_CONTENT in a
+subsequent commit will be removed from cached_irrelevant.)
+
+The reason for (D) is that is how we determine whether the remember
+renames optimization can be used. In particular, remembering that our
+sequence of merges looks like:
+
+ Merge 1:
+ MERGE_BASE: E
+ MERGE_SIDE1: G
+ MERGE_SIDE2: A
+ => Creates A'
+
+ Merge 2:
+ MERGE_BASE: A
+ MERGE_SIDE1: A'
+ MERGE_SIDE2: B
+ => Creates B'
+
+It is the fact that the trees A and A' appear both in Merge 1 and in
+Merge 2, with A as a parent of A' that allows this optimization. So
+we store the trees to compare with what we are asked to merge next
+time.
+
+
+=== 8. How directory rename detection interacts with the above and ===
+=== why this optimization is still safe even if ===
+=== merge.directoryRenames is set to "true". ===
+
+As noted in the assumptions section:
+
+ """
+ ...if directory renames do occur, then the default of
+ merge.directoryRenames being set to "conflict" means that the operation
+ will stop for users to resolve the conflicts and the cache will be
+ thrown away, and thus that there won't be an optimization to apply.
+ So, the only reason we need to address directory renames specifically,
+ is that some users will have set merge.directoryRenames to "true" to
+ allow the merges to continue to proceed automatically.
+ """
+
+Let's remember that we need to look at how any given pick affects the next
+one. So let's again use the first two picks from the diagram in section
+one:
+
+ First pick does this three-way merge:
+ MERGE_BASE: E
+ MERGE_SIDE1: G
+ MERGE_SIDE2: A
+ => creates A'
+
+ Second pick does this three-way merge:
+ MERGE_BASE: A
+ MERGE_SIDE1: A'
+ MERGE_SIDE2: B
+ => creates B'
+
+Now, directory rename detection exists so that if one side of history
+renames a directory, and the other side adds a new file to the old
+directory, then the merge (with merge.directoryRenames=true) can move the
+file into the new directory. There are two qualitatively different ways to
+add a new file to an old directory: create a new file, or rename a file
+into that directory. Also, directory renames can be done on either side of
+history, so there are four cases to consider:
+
+ * MERGE_SIDE1 renames old dir, MERGE_SIDE2 adds new file to old dir
+ * MERGE_SIDE1 renames old dir, MERGE_SIDE2 renames file into old dir
+ * MERGE_SIDE1 adds new file to old dir, MERGE_SIDE2 renames old dir
+ * MERGE_SIDE1 renames file into old dir, MERGE_SIDE2 renames old dir
+
+One last note before we consider these four cases: There are some
+important properties about how we implement this optimization with
+respect to directory rename detection that we need to bear in mind
+while considering all of these cases:
+
+ * rename caching occurs *after* applying directory renames
+
+ * a rename created by directory rename detection is recorded for the side
+ of history that did the directory rename.
+
+ * dir_rename_counts, the nested map of
+ {oldname => {newname => count}},
+ is cached between runs as well. This basically means that directory
+ rename detection is also cached, though only on the side of history
+ that we cache renames for (MERGE_SIDE1 as far as this document is
+ concerned; see the assumptions section). Two interesting sub-notes
+ about these counts:
+
+ * If we need to perform rename-detection again on the given side (e.g.
+ some paths are relevant for rename detection that weren't before),
+ then we clear dir_rename_counts and recompute it, making use of
+ cached_pairs. The reason it is important to do this is optimizations
+ around RELEVANT_LOCATION exist to prevent us from computing
+ unnecessary renames for directory rename detection and from computing
+ dir_rename_counts for irrelevant directories; but those same renames
+ or directories may become necessary for subsequent merges. The
+ easiest way to "fix up" dir_rename_counts in such cases is to just
+ recompute it.
+
+ * If we prune rename/rename(1to1) entries from the cache, then we also
+ need to update dir_rename_counts to decrement the counts for the
+ involved directory and any relevant parent directories (to undo what
+ update_dir_rename_counts() in diffcore-rename.c incremented when the
+ rename was initially found). If we instead just disable the
+ remembering renames optimization when the exceedingly rare
+ rename/rename(1to1) cases occur, then dir_rename_counts will get
+ re-computed the next time rename detection occurs, as noted above.
+
+ * the side with multiple commits to pick, is the side of history that we
+ do NOT cache renames for. Thus, there are no additional commits to
+ change the number of renames in a directory, except for those done by
+ directory rename detection (which always pad the majority).
+
+ * the "renames" we cache are modified slightly by any directory rename,
+ as noted below.
+
+Now, with those notes out of the way, let's go through the four cases
+in order:
+
+Case 1: MERGE_SIDE1 renames old dir, MERGE_SIDE2 adds new file to old dir
+
+ This case looks like this:
+
+ MERGE_BASE: E, Has olddir/
+ MERGE_SIDE1: G, Renames olddir/ -> newdir/
+ MERGE_SIDE2: A, Adds olddir/newfile
+ => creates A', With newdir/newfile
+
+ MERGE_BASE: A, Has olddir/newfile
+ MERGE_SIDE1: A', Has newdir/newfile
+ MERGE_SIDE2: B, Modifies olddir/newfile
+ => expected B', with threeway-merged newdir/newfile from above
+
+ In this case, with the optimization, note that after the first commit:
+ * MERGE_SIDE1 remembers olddir/ -> newdir/
+ * MERGE_SIDE1 has cached olddir/newfile -> newdir/newfile
+ Given the cached rename noted above, the second merge can proceed as
+ expected without needing to perform rename detection from A -> A'.
+
+Case 2: MERGE_SIDE1 renames old dir, MERGE_SIDE2 renames file into old dir
+
+ This case looks like this:
+ MERGE_BASE: E oldfile, olddir/
+ MERGE_SIDE1: G oldfile, olddir/ -> newdir/
+ MERGE_SIDE2: A oldfile -> olddir/newfile
+ => creates A', With newdir/newfile representing original oldfile
+
+ MERGE_BASE: A olddir/newfile
+ MERGE_SIDE1: A' newdir/newfile
+ MERGE_SIDE2: B modify olddir/newfile
+ => expected B', with threeway-merged newdir/newfile from above
+
+ In this case, with the optimization, note that after the first commit:
+ * MERGE_SIDE1 remembers olddir/ -> newdir/
+ * MERGE_SIDE1 has cached olddir/newfile -> newdir/newfile
+ (NOT oldfile -> newdir/newfile; compare to case with
+ (p->status == 'R' && new_path) in possibly_cache_new_pair())
+
+ Given the cached rename noted above, the second merge can proceed as
+ expected without needing to perform rename detection from A -> A'.
+
+Case 3: MERGE_SIDE1 adds new file to old dir, MERGE_SIDE2 renames old dir
+
+ This case looks like this:
+
+ MERGE_BASE: E, Has olddir/
+ MERGE_SIDE1: G, Adds olddir/newfile
+ MERGE_SIDE2: A, Renames olddir/ -> newdir/
+ => creates A', With newdir/newfile
+
+ MERGE_BASE: A, Has newdir/, but no notion of newdir/newfile
+ MERGE_SIDE1: A', Has newdir/newfile
+ MERGE_SIDE2: B, Has newdir/, but no notion of newdir/newfile
+ => expected B', with newdir/newfile from A'
+
+ In this case, with the optimization, note that after the first commit there
+ were no renames on MERGE_SIDE1, and any renames on MERGE_SIDE2 are tossed.
+ But the second merge didn't need any renames so this is fine.
+
+Case 4: MERGE_SIDE1 renames file into old dir, MERGE_SIDE2 renames old dir
+
+ This case looks like this:
+
+ MERGE_BASE: E, Has olddir/
+ MERGE_SIDE1: G, Renames oldfile -> olddir/newfile
+ MERGE_SIDE2: A, Renames olddir/ -> newdir/
+ => creates A', With newdir/newfile representing original oldfile
+
+ MERGE_BASE: A, Has oldfile
+ MERGE_SIDE1: A', Has newdir/newfile
+ MERGE_SIDE2: B, Modifies oldfile
+ => expected B', with threeway-merged newdir/newfile from above
+
+ In this case, with the optimization, note that after the first commit:
+ * MERGE_SIDE1 remembers oldfile -> newdir/newfile
+ (NOT oldfile -> olddir/newfile; compare to case of second
+ block under p->status == 'R' in possibly_cache_new_pair())
+ * MERGE_SIDE2 renames are tossed because only MERGE_SIDE1 is remembered
+
+ Given the cached rename noted above, the second merge can proceed as
+ expected without needing to perform rename detection from A -> A'.
+
+Finally, I'll just note here that interactions with the
+skip-irrelevant-renames optimization means we sometimes don't detect
+renames for any files within a directory that was renamed, in which
+case we will not have been able to detect any rename for the directory
+itself. In such a case, we do not know whether the directory was
+renamed; we want to be careful to avoid caching some kind of "this
+directory was not renamed" statement. If we did, then a subsequent
+commit being rebased could add a file to the old directory, and the
+user would expect it to end up in the correct directory -- something
+our erroneous "this directory was not renamed" cache would preclude.
diff --git a/technical/repository-version.adoc b/technical/repository-version.adoc
new file mode 100644
index 0000000..b9bb81a
--- /dev/null
+++ b/technical/repository-version.adoc
@@ -0,0 +1,70 @@
+== Git Repository Format Versions
+
+Every git repository is marked with a numeric version in the
+`core.repositoryformatversion` key of its `config` file. This version
+specifies the rules for operating on the on-disk repository data. An
+implementation of git which does not understand a particular version
+advertised by an on-disk repository MUST NOT operate on that repository;
+doing so risks not only producing wrong results, but actually losing
+data.
+
+Because of this rule, version bumps should be kept to an absolute
+minimum. Instead, we generally prefer these strategies:
+
+ - bumping format version numbers of individual data files (e.g.,
+ index, packfiles, etc). This restricts the incompatibilities only to
+ those files.
+
+ - introducing new data that gracefully degrades when used by older
+ clients (e.g., pack bitmap files are ignored by older clients, which
+ simply do not take advantage of the optimization they provide).
+
+A whole-repository format version bump should only be part of a change
+that cannot be independently versioned. For instance, if one were to
+change the reachability rules for objects, or the rules for locking
+refs, that would require a bump of the repository format version.
+
+Note that this applies only to accessing the repository's disk contents
+directly. An older client which understands only format `0` may still
+connect via `git://` to a repository using format `1`, as long as the
+server process understands format `1`.
+
+The preferred strategy for rolling out a version bump (whether whole
+repository or for a single file) is to teach git to read the new format,
+and allow writing the new format with a config switch or command line
+option (for experimentation or for those who do not care about backwards
+compatibility with older gits). Then after a long period to allow the
+reading capability to become common, we may switch to writing the new
+format by default.
+
+The currently defined format versions are:
+
+=== Version `0`
+
+This is the format defined by the initial version of git, including but
+not limited to the format of the repository directory, the repository
+configuration file, and the object and ref storage. Specifying the
+complete behavior of git is beyond the scope of this document.
+
+=== Version `1`
+
+This format is identical to version `0`, with the following exceptions:
+
+ 1. When reading the `core.repositoryformatversion` variable, a git
+ implementation which supports version 1 MUST also read any
+ configuration keys found in the `extensions` section of the
+ configuration file.
+
+ 2. If a version-1 repository specifies any `extensions.*` keys that
+ the running git has not implemented, the operation MUST NOT
+ proceed. Similarly, if the value of any known key is not understood
+ by the implementation, the operation MUST NOT proceed.
+
+Note that if no extensions are specified in the config file, then
+`core.repositoryformatversion` SHOULD be set to `0` (setting it to `1`
+provides no benefit, and makes the repository incompatible with older
+implementations of git).
+
+The defined extensions are given in the `extensions.*` section of
+linkgit:git-config[1]. Any implementation wishing to define a new
+extension should make a note of it there, in order to claim the name.
diff --git a/technical/rerere.adoc b/technical/rerere.adoc
new file mode 100644
index 0000000..580f233
--- /dev/null
+++ b/technical/rerere.adoc
@@ -0,0 +1,186 @@
+Rerere
+======
+
+This document describes the rerere logic.
+
+Conflict normalization
+----------------------
+
+To ensure recorded conflict resolutions can be looked up in the rerere
+database, even when branches are merged in a different order,
+different branches are merged that result in the same conflict, or
+when different conflict style settings are used, rerere normalizes the
+conflicts before writing them to the rerere database.
+
+Different conflict styles and branch names are normalized by stripping
+the labels from the conflict markers, and removing the common ancestor
+version from the `diff3` or `zdiff3` conflict styles. Branches that
+are merged in different order are normalized by sorting the conflict
+hunks. More on each of those steps in the following sections.
+
+Once these two normalization operations are applied, a conflict ID is
+calculated based on the normalized conflict, which is later used by
+rerere to look up the conflict in the rerere database.
+
+Removing the common ancestor version
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Say we have three branches AB, AC and AC2. The common ancestor of
+these branches has a file with a line containing the string "A" (for
+brevity this is called "line A" in the rest of the document). In
+branch AB this line is changed to "B", in AC, this line is changed to
+"C", and branch AC2 is forked off of AC, after the line was changed to
+"C".
+
+Forking a branch ABAC off of branch AB and then merging AC into it, we
+get a conflict like the following:
+
+ <<<<<<< HEAD
+ B
+ =======
+ C
+ >>>>>>> AC
+
+Doing the analogous with AC2 (forking a branch ABAC2 off of branch AB
+and then merging branch AC2 into it), using the diff3 or zdiff3
+conflict style, we get a conflict like the following:
+
+ <<<<<<< HEAD
+ B
+ ||||||| merged common ancestors
+ A
+ =======
+ C
+ >>>>>>> AC2
+
+By resolving this conflict, to leave line D, the user declares:
+
+ After examining what branches AB and AC did, I believe that making
+ line A into line D is the best thing to do that is compatible with
+ what AB and AC wanted to do.
+
+As branch AC2 refers to the same commit as AC, the above implies that
+this is also compatible with what AB and AC2 wanted to do.
+
+By extension, this means that rerere should recognize that the above
+conflicts are the same. To do this, the labels on the conflict
+markers are stripped, and the common ancestor version is removed. The above
+examples would both result in the following normalized conflict:
+
+ <<<<<<<
+ B
+ =======
+ C
+ >>>>>>>
+
+Sorting hunks
+~~~~~~~~~~~~~
+
+As before, let's imagine that a common ancestor had a file with line A
+its early part, and line X in its late part. And then four branches
+are forked that do these things:
+
+ - AB: changes A to B
+ - AC: changes A to C
+ - XY: changes X to Y
+ - XZ: changes X to Z
+
+Now, forking a branch ABAC off of branch AB and then merging AC into
+it, and forking a branch ACAB off of branch AC and then merging AB
+into it, would yield the conflict in a different order. The former
+would say "A became B or C, what now?" while the latter would say "A
+became C or B, what now?"
+
+As a reminder, the act of merging AC into ABAC and resolving the
+conflict to leave line D means that the user declares:
+
+ After examining what branches AB and AC did, I believe that
+ making line A into line D is the best thing to do that is
+ compatible with what AB and AC wanted to do.
+
+So the conflict we would see when merging AB into ACAB should be
+resolved the same way--it is the resolution that is in line with that
+declaration.
+
+Imagine that similarly previously a branch XYXZ was forked from XY,
+and XZ was merged into it, and resolved "X became Y or Z" into "X
+became W".
+
+Now, if a branch ABXY was forked from AB and then merged XY, then ABXY
+would have line B in its early part and line Y in its later part.
+Such a merge would be quite clean. We can construct 4 combinations
+using these four branches ((AB, AC) x (XY, XZ)).
+
+Merging ABXY and ACXZ would make "an early A became B or C, a late X
+became Y or Z" conflict, while merging ACXY and ABXZ would make "an
+early A became C or B, a late X became Y or Z". We can see there are
+4 combinations of ("B or C", "C or B") x ("X or Y", "Y or X").
+
+By sorting, the conflict is given its canonical name, namely, "an
+early part became B or C, a late part became X or Y", and whenever
+any of these four patterns appear, and we can get to the same conflict
+and resolution that we saw earlier.
+
+Without the sorting, we'd have to somehow find a previous resolution
+from combinatorial explosion.
+
+Conflict ID calculation
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Once the conflict normalization is done, the conflict ID is calculated
+as the sha1 hash of the conflict hunks appended to each other,
+separated by <NUL> characters. The conflict markers are stripped out
+before the sha1 is calculated. So in the example above, where we
+merge branch AC which changes line A to line C, into branch AB, which
+changes line A to line C, the conflict ID would be
+SHA1('B<NUL>C<NUL>').
+
+If there are multiple conflicts in one file, the sha1 is calculated
+the same way with all hunks appended to each other, in the order in
+which they appear in the file, separated by a <NUL> character.
+
+Nested conflicts
+~~~~~~~~~~~~~~~~
+
+Nested conflicts are handled very similarly to "simple" conflicts.
+Similar to simple conflicts, the conflict is first normalized by
+stripping the labels from conflict markers, stripping the common ancestor
+version, and sorting the conflict hunks, both for the outer and the
+inner conflict. This is done recursively, so any number of nested
+conflicts can be handled.
+
+Note that this only works for conflict markers that "cleanly nest". If
+there are any unmatched conflict markers, rerere will fail to handle
+the conflict and record a conflict resolution.
+
+The only difference is in how the conflict ID is calculated. For the
+inner conflict, the conflict markers themselves are not stripped out
+before calculating the sha1.
+
+Say we have the following conflict for example:
+
+ <<<<<<< HEAD
+ 1
+ =======
+ <<<<<<< HEAD
+ 3
+ =======
+ 2
+ >>>>>>> branch-2
+ >>>>>>> branch-3~
+
+After stripping out the labels of the conflict markers, and sorting
+the hunks, the conflict would look as follows:
+
+ <<<<<<<
+ 1
+ =======
+ <<<<<<<
+ 2
+ =======
+ 3
+ >>>>>>>
+ >>>>>>>
+
+and finally the conflict ID would be calculated as:
+`sha1('1<NUL><<<<<<<\n3\n=======\n2\n>>>>>>><NUL>')`
diff --git a/technical/scalar.adoc b/technical/scalar.adoc
new file mode 100644
index 0000000..921cb10
--- /dev/null
+++ b/technical/scalar.adoc
@@ -0,0 +1,66 @@
+Scalar
+======
+
+Scalar is a repository management tool that optimizes Git for use in large
+repositories. It accomplishes this by helping users to take advantage of
+advanced performance features in Git. Unlike most other Git built-in commands,
+Scalar is not executed as a subcommand of 'git'; rather, it is built as a
+separate executable containing its own series of subcommands.
+
+Background
+----------
+
+Scalar was originally designed as an add-on to Git and implemented as a .NET
+Core application. It was created based on the learnings from the VFS for Git
+project (another application aimed at improving the experience of working with
+large repositories). As part of its initial implementation, Scalar relied on
+custom features in the Microsoft fork of Git that have since been integrated
+into core Git:
+
+* partial clone,
+* commit graphs,
+* multi-pack index,
+* sparse checkout (cone mode),
+* scheduled background maintenance,
+* etc
+
+With the requisite Git functionality in place and a desire to bring the benefits
+of Scalar to the larger Git community, the Scalar application itself was ported
+from C# to C and integrated upstream.
+
+Features
+--------
+
+Scalar is comprised of two major pieces of functionality: automatically
+configuring built-in Git performance features and managing repository
+enlistments.
+
+The Git performance features configured by Scalar (see "Background" for
+examples) confer substantial performance benefits to large repositories, but are
+either too experimental to enable for all of Git yet, or only benefit large
+repositories. As new features are introduced, Scalar should be updated
+accordingly to incorporate them. This will prevent the tool from becoming stale
+while also providing a path for more easily bringing features to the appropriate
+users.
+
+Enlistments are how Scalar knows which repositories on a user's system should
+utilize Scalar-configured features. This allows it to update performance
+settings when new ones are added to the tool, as well as centrally manage
+repository maintenance. The enlistment structure - a root directory with a
+`src/` subdirectory containing the cloned repository itself - is designed to
+encourage users to route build outputs outside of the repository to avoid the
+performance-limiting overhead of ignoring those files in Git.
+
+Design
+------
+
+Scalar is implemented in C and interacts with Git via a mix of child process
+invocations of Git and direct usage of `libgit.a`. Internally, it is structured
+much like other built-ins with subcommands (e.g., `git stash`), containing a
+`cmd_<subcommand>()` function for each subcommand, routed through a `cmd_main()`
+function. Most options are unique to each subcommand, with `scalar` respecting
+some "global" `git` options (e.g., `-c` and `-C`).
+
+Because `scalar` is not invoked as a Git subcommand (like `git scalar`), it is
+built and installed as its own executable in the `bin/` directory, alongside
+`git`, `git-gui`, etc.
diff --git a/technical/send-pack-pipeline.adoc b/technical/send-pack-pipeline.adoc
new file mode 100644
index 0000000..9b5a0bc
--- /dev/null
+++ b/technical/send-pack-pipeline.adoc
@@ -0,0 +1,63 @@
+Git-send-pack internals
+=======================
+
+Overall operation
+-----------------
+
+. Connects to the remote side and invokes git-receive-pack.
+
+. Learns what refs the remote has and what commit they point at.
+ Matches them to the refspecs we are pushing.
+
+. Checks if there are non-fast-forwards. Unlike fetch-pack,
+ the repository send-pack runs in is supposed to be a superset
+ of the recipient in fast-forward cases, so there is no need
+ for want/have exchanges, and fast-forward check can be done
+ locally. Tell the result to the other end.
+
+. Calls pack_objects() which generates a packfile and sends it
+ over to the other end.
+
+. If the remote side is new enough (v1.1.0 or later), wait for
+ the unpack and hook status from the other end.
+
+. Exit with appropriate error codes.
+
+
+Pack_objects pipeline
+---------------------
+
+This function gets one file descriptor (`fd`) which is either a
+socket (over the network) or a pipe (local). What's written to
+this fd goes to git-receive-pack to be unpacked.
+
+ send-pack ---> fd ---> receive-pack
+
+The function pack_objects creates a pipe and then forks. The
+forked child execs pack-objects with --revs to receive revision
+parameters from its standard input. This process will write the
+packfile to the other end.
+
+ send-pack
+ |
+ pack_objects() ---> fd ---> receive-pack
+ | ^ (pipe)
+ v |
+ (child)
+
+The child dup2's to arrange its standard output to go back to
+the other end, and read its standard input to come from the
+pipe. After that it exec's pack-objects. On the other hand,
+the parent process, before starting to feed the child pipeline,
+closes the reading side of the pipe and fd to receive-pack.
+
+ send-pack
+ |
+ pack_objects(parent)
+ |
+ v [0]
+ pack-objects [0] ---> receive-pack
+
+
+[jc: the pipeline was much more complex and needed documentation before
+ I understood an earlier bug, but now it is trivial and straightforward.]
diff --git a/technical/shallow.adoc b/technical/shallow.adoc
new file mode 100644
index 0000000..f3738ba
--- /dev/null
+++ b/technical/shallow.adoc
@@ -0,0 +1,60 @@
+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.
+*********************************************************
+
+$GIT_DIR/shallow lists commit object names and tells Git to
+pretend as if they are root commits (e.g. "git log" traversal
+stops after showing them; "git fsck" does not complain saying
+the commits listed on their "parent" lines do not exist).
+
+Each line contains exactly one object name. When read, a commit_graft
+will be constructed, which has nr_parent < 0 to make it easier
+to discern from user provided grafts.
+
+Note that the shallow feature could not be changed easily to
+use replace refs: a commit containing a `mergetag` is not allowed
+to be replaced, not even by a root commit. Such a commit can be
+made shallow, though. Also, having a `shallow` file explicitly
+listing all the commits made shallow makes it a *lot* easier to
+do shallow-specific things such as to deepen the history.
+
+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.
+
+The special depth 2147483647 (or 0x7fffffff, the largest positive
+number a signed 32-bit integer can contain) means infinite depth.
diff --git a/technical/sparse-checkout.adoc b/technical/sparse-checkout.adoc
new file mode 100644
index 0000000..d968659
--- /dev/null
+++ b/technical/sparse-checkout.adoc
@@ -0,0 +1,1103 @@
+Table of contents:
+
+ * Terminology
+ * Purpose of sparse-checkouts
+ * Usecases of primary concern
+ * Oversimplified mental models ("Cliff Notes" for this document!)
+ * Desired behavior
+ * Behavior classes
+ * Subcommand-dependent defaults
+ * Sparse specification vs. sparsity patterns
+ * Implementation Questions
+ * Implementation Goals/Plans
+ * Known bugs
+ * Reference Emails
+
+
+=== Terminology ===
+
+cone mode: one of two modes for specifying the desired subset of files
+ in a sparse-checkout. In cone-mode, the user specifies
+ directories (getting both everything under that directory as
+ well as everything in leading directories), while in non-cone
+ mode, the user specifies gitignore-style patterns. Controlled
+ by the --[no-]cone option to sparse-checkout init|set.
+
+SKIP_WORKTREE: When tracked files do not match the sparse specification and
+ are removed from the working tree, the file in the index is marked
+ with a SKIP_WORKTREE bit. Note that if a tracked file has the
+ SKIP_WORKTREE bit set but the file is later written by the user to
+ the working tree anyway, the SKIP_WORKTREE bit will be cleared at
+ the beginning of any subsequent Git operation.
+
+ Most sparse checkout users are unaware of this implementation
+ detail, and the term should generally be avoided in user-facing
+ descriptions and command flags. Unfortunately, prior to the
+ `sparse-checkout` subcommand this low-level detail was exposed,
+ and as of time of writing, is still exposed in various places.
+
+sparse-checkout: a subcommand in git used to reduce the files present in
+ the working tree to a subset of all tracked files. Also, the
+ name of the file in the $GIT_DIR/info directory used to track
+ the sparsity patterns corresponding to the user's desired
+ subset.
+
+sparse cone: see cone mode
+
+sparse directory: An entry in the index corresponding to a directory, which
+ appears in the index instead of all the files under that directory
+ that would normally appear. See also sparse-index. Something that
+ can cause confusion is that the "sparse directory" does NOT match
+ the sparse specification, i.e. the directory is NOT present in the
+ working tree. May be renamed in the future (e.g. to "skipped
+ directory").
+
+sparse index: A special mode for sparse-checkout that also makes the
+ index sparse by recording a directory entry in lieu of all the
+ files underneath that directory (thus making that a "skipped
+ directory" which unfortunately has also been called a "sparse
+ directory"), and does this for potentially multiple
+ directories. Controlled by the --[no-]sparse-index option to
+ init|set|reapply.
+
+sparsity patterns: patterns from $GIT_DIR/info/sparse-checkout used to
+ define the set of files of interest. A warning: It is easy to
+ over-use this term (or the shortened "patterns" term), for two
+ reasons: (1) users in cone mode specify directories rather than
+ patterns (their directories are transformed into patterns, but
+ users may think you are talking about non-cone mode if you use the
+ word "patterns"), and (b) the sparse specification might
+ transiently differ in the working tree or index from the sparsity
+ patterns (see "Sparse specification vs. sparsity patterns").
+
+sparse specification: The set of paths in the user's area of focus. This
+ is typically just the tracked files that match the sparsity
+ patterns, but the sparse specification can temporarily differ and
+ include additional files. (See also "Sparse specification
+ vs. sparsity patterns")
+
+ * When working with history, the sparse specification is exactly
+ the set of files matching the sparsity patterns.
+ * When interacting with the working tree, the sparse specification
+ is the set of tracked files with a clear SKIP_WORKTREE bit or
+ tracked files present in the working copy.
+ * When modifying or showing results from the index, the sparse
+ specification is the set of files with a clear SKIP_WORKTREE bit
+ or that differ in the index from HEAD.
+ * If working with the index and the working copy, the sparse
+ specification is the union of the paths from above.
+
+vivifying: When a command restores a tracked file to the working tree (and
+ hopefully also clears the SKIP_WORKTREE bit in the index for that
+ file), this is referred to as "vivifying" the file.
+
+
+=== Purpose of sparse-checkouts ===
+
+sparse-checkouts exist to allow users to work with a subset of their
+files.
+
+You can think of sparse-checkouts as subdividing "tracked" files into two
+categories -- a sparse subset, and all the rest. Implementationally, we
+mark "all the rest" in the index with a SKIP_WORKTREE bit and leave them
+out of the working tree. The SKIP_WORKTREE files are still tracked, just
+not present in the working tree.
+
+In the past, sparse-checkouts were defined by "SKIP_WORKTREE means the file
+is missing from the working tree but pretend the file contents match HEAD".
+That was not only bogus (it actually meant the file missing from the
+working tree matched the index rather than HEAD), but it was also a
+low-level detail which only provided decent behavior for a few commands.
+There were a surprising number of ways in which that guiding principle gave
+command results that violated user expectations, and as such was a bad
+mental model. However, it persisted for many years and may still be found
+in some corners of the code base.
+
+Anyway, the idea of "working with a subset of files" is simple enough, but
+there are multiple different high-level usecases which affect how some Git
+subcommands should behave. Further, even if we only considered one of
+those usecases, sparse-checkouts can modify different subcommands in over a
+half dozen different ways. Let's start by considering the high level
+usecases:
+
+ A) Users are _only_ interested in the sparse portion of the repo
+
+ A*) Users are _only_ interested in the sparse portion of the repo
+ that they have downloaded so far
+
+ B) Users want a sparse working tree, but are working in a larger whole
+
+ C) sparse-checkout is a behind-the-scenes implementation detail allowing
+ Git to work with a specially crafted in-house virtual file system;
+ users are actually working with a "full" working tree that is
+ lazily populated, and sparse-checkout helps with the lazy population
+ piece.
+
+It may be worth explaining each of these in a bit more detail:
+
+
+ (Behavior A) Users are _only_ interested in the sparse portion of the repo
+
+These folks might know there are other things in the repository, but
+don't care. They are uninterested in other parts of the repository, and
+only want to know about changes within their area of interest. Showing
+them other files from history (e.g. from diff/log/grep/etc.) is a
+usability annoyance, potentially a huge one since other changes in
+history may dwarf the changes they are interested in.
+
+Some of these users also arrive at this usecase from wanting to use partial
+clones together with sparse checkouts (in a way where they have downloaded
+blobs within the sparse specification) and do disconnected development.
+Not only do these users generally not care about other parts of the
+repository, but consider it a blocker for Git commands to try to operate on
+those. If commands attempt to access paths in history outside the sparsity
+specification, then the partial clone will attempt to download additional
+blobs on demand, fail, and then fail the user's command. (This may be
+unavoidable in some cases, e.g. when `git merge` has non-trivial changes to
+reconcile outside the sparse specification, but we should limit how often
+users are forced to connect to the network.)
+
+Also, even for users using partial clones that do not mind being
+always connected to the network, the need to download blobs as
+side-effects of various other commands (such as the printed diffstat
+after a merge or pull) can lead to worries about local repository size
+growing unnecessarily[10].
+
+ (Behavior A*) Users are _only_ interested in the sparse portion of the repo
+ that they have downloaded so far (a variant on the first usecase)
+
+This variant is driven by folks who using partial clones together with
+sparse checkouts and do disconnected development (so far sounding like a
+subset of behavior A users) and doing so on very large repositories. The
+reason for yet another variant is that downloading even just the blobs
+through history within their sparse specification may be too much, so they
+only download some. They would still like operations to succeed without
+network connectivity, though, so things like `git log -S${SEARCH_TERM} -p`
+or `git grep ${SEARCH_TERM} OLDREV ` would need to be prepared to provide
+partial results that depend on what happens to have been downloaded.
+
+This variant could be viewed as Behavior A with the sparse specification
+for history querying operations modified from "sparsity patterns" to
+"sparsity patterns limited to the blobs we have already downloaded".
+
+ (Behavior B) Users want a sparse working tree, but are working in a
+ larger whole
+
+Stolee described this usecase this way[11]:
+
+"I'm also focused on users that know that they are a part of a larger
+whole. They know they are operating on a large repository but focus on
+what they need to contribute their part. I expect multiple "roles" to
+use very different, almost disjoint parts of the codebase. Some other
+"architect" users operate across the entire tree or hop between different
+sections of the codebase as necessary. In this situation, I'm wary of
+scoping too many features to the sparse-checkout definition, especially
+"git log," as it can be too confusing to have their view of the codebase
+depend on your "point of view."
+
+People might also end up wanting behavior B due to complex inter-project
+dependencies. The initial attempts to use sparse-checkouts usually involve
+the directories you are directly interested in plus what those directories
+depend upon within your repository. But there's a monkey wrench here: if
+you have integration tests, they invert the hierarchy: to run integration
+tests, you need not only what you are interested in and its in-tree
+dependencies, you also need everything that depends upon what you are
+interested in or that depends upon one of your dependencies...AND you need
+all the in-tree dependencies of that expanded group. That can easily
+change your sparse-checkout into a nearly dense one.
+
+Naturally, that tends to kill the benefits of sparse-checkouts. There are
+a couple solutions to this conundrum: either avoid grabbing in-repo
+dependencies (maybe have built versions of your in-repo dependencies pulled
+from a CI cache somewhere), or say that users shouldn't run integration
+tests directly and instead do it on the CI server when they submit a code
+review. Or do both. Regardless of whether you stub out your in-repo
+dependencies or stub out the things that depend upon you, there is
+certainly a reason to want to query and be aware of those other stubbed-out
+parts of the repository, particularly when the dependencies are complex or
+change relatively frequently. Thus, for such uses, sparse-checkouts can be
+used to limit what you directly build and modify, but these users do not
+necessarily want their sparse checkout paths to limit their queries of
+versions in history.
+
+Some people may also be interested in behavior B over behavior A simply as
+a performance workaround: if they are using non-cone mode, then they have
+to deal with its inherent quadratic performance problems. In that mode,
+every operation that checks whether paths match the sparsity specification
+can be expensive. As such, these users may only be willing to pay for
+those expensive checks when interacting with the working copy, and may
+prefer getting "unrelated" results from their history queries over having
+slow commands.
+
+ (Behavior C) sparse-checkout is an implementational detail supporting a
+ special VFS.
+
+This usecase goes slightly against the traditional definition of
+sparse-checkout in that it actually tries to present a full or dense
+checkout to the user. However, this usecase utilizes the same underlying
+technical underpinnings in a new way which does provide some performance
+advantages to users. The basic idea is that a company can have an in-house
+Git-aware Virtual File System which pretends all files are present in the
+working tree, by intercepting all file system accesses and using those to
+fetch and write accessed files on demand via partial clones. The VFS uses
+sparse-checkout to prevent Git from writing or paying attention to many
+files, and manually updates the sparse checkout patterns itself based on
+user access and modification of files in the working tree. See commit
+ecc7c8841d ("repo_read_index: add config to expect files outside sparse
+patterns", 2022-02-25) and the link at [17] for a more detailed description
+of such a VFS.
+
+The biggest difference here is that users are completely unaware that the
+sparse-checkout machinery is even in use. The sparse patterns are not
+specified by the user but rather are under the complete control of the VFS
+(and the patterns are updated frequently and dynamically by it). The user
+will perceive the checkout as dense, and commands should thus behave as if
+all files are present.
+
+
+=== Usecases of primary concern ===
+
+Most of the rest of this document will focus on Behavior A and Behavior
+B. Some notes about the other two cases and why we are not focusing on
+them:
+
+ (Behavior A*)
+
+Supporting this usecase is estimated to be difficult and a lot of work.
+There are no plans to implement it currently, but it may be a potential
+future alternative. Knowing about the existence of additional alternatives
+may affect our choice of command line flags (e.g. if we need tri-state or
+quad-state flags rather than just binary flags), so it was still important
+to at least note.
+
+Further, I believe the descriptions below for Behavior A are probably still
+valid for this usecase, with the only exception being that it redefines the
+sparse specification to restrict it to already-downloaded blobs. The hard
+part is in making commands capable of respecting that modified definition.
+
+ (Behavior C)
+
+This usecase violates some of the early sparse-checkout documented
+assumptions (since files marked as SKIP_WORKTREE will be displayed to users
+as present in the working tree). That violation may mean various
+sparse-checkout related behaviors are not well suited to this usecase and
+we may need tweaks -- to both documentation and code -- to handle it.
+However, this usecase is also perhaps the simplest model to support in that
+everything behaves like a dense checkout with a few exceptions (e.g. branch
+checkouts and switches write fewer things, knowing the VFS will lazily
+write the rest on an as-needed basis).
+
+Since there is no publicly available VFS-related code for folks to try,
+the number of folks who can test such a usecase is limited.
+
+The primary reason to note the Behavior C usecase is that as we fix things
+to better support Behaviors A and B, there may be additional places where
+we need to make tweaks allowing folks in this usecase to get the original
+non-sparse treatment. For an example, see ecc7c8841d ("repo_read_index:
+add config to expect files outside sparse patterns", 2022-02-25). The
+secondary reason to note Behavior C, is so that folks taking advantage of
+Behavior C do not assume they are part of the Behavior B camp and propose
+patches that break things for the real Behavior B folks.
+
+
+=== Oversimplified mental models ===
+
+An oversimplification of the differences in the above behaviors is:
+
+ Behavior A: Restrict worktree and history operations to sparse specification
+ Behavior B: Restrict worktree operations to sparse specification; have any
+ history operations work across all files
+ Behavior C: Do not restrict either worktree or history operations to the
+ sparse specification...with the exception of branch checkouts or
+ switches which avoid writing files that will match the index so
+ they can later lazily be populated instead.
+
+
+=== Desired behavior ===
+
+As noted previously, despite the simple idea of just working with a subset
+of files, there are a range of different behavioral changes that need to be
+made to different subcommands to work well with such a feature. See
+[1,2,3,4,5,6,7,8,9,10] for various examples. In particular, at [2], we saw
+that mere composition of other commands that individually worked correctly
+in a sparse-checkout context did not imply that the higher level command
+would work correctly; it sometimes requires further tweaks. So,
+understanding these differences can be beneficial.
+
+* Commands behaving the same regardless of high-level use-case
+
+ * commands that only look at files within the sparsity specification
+
+ * diff (without --cached or REVISION arguments)
+ * grep (without --cached or REVISION arguments)
+ * diff-files
+
+ * commands that restore files to the working tree that match sparsity
+ patterns, and remove unmodified files that don't match those
+ patterns:
+
+ * switch
+ * checkout (the switch-like half)
+ * read-tree
+ * reset --hard
+
+ * commands that write conflicted files to the working tree, but otherwise
+ will omit writing files to the working tree that do not match the
+ sparsity patterns:
+
+ * merge
+ * rebase
+ * cherry-pick
+ * revert
+
+ * `am` and `apply --cached` should probably be in this section but
+ are buggy (see the "Known bugs" section below)
+
+ The behavior for these commands somewhat depends upon the merge
+ strategy being used:
+ * `ort` behaves as described above
+ * `recursive` tries to not vivify files unnecessarily, but does sometimes
+ vivify files without conflicts.
+ * `octopus` and `resolve` will always vivify any file changed in the merge
+ relative to the first parent, which is rather suboptimal.
+
+ It is also important to note that these commands WILL update the index
+ outside the sparse specification relative to when the operation began,
+ BUT these commands often make a commit just before or after such that
+ by the end of the operation there is no change to the index outside the
+ sparse specification. Of course, if the operation hits conflicts or
+ does not make a commit, then these operations clearly can modify the
+ index outside the sparse specification.
+
+ Finally, it is important to note that at least the first four of these
+ commands also try to remove differences between the sparse
+ specification and the sparsity patterns (much like the commands in the
+ previous section).
+
+ * commands that always ignore sparsity since commits must be full-tree
+
+ * archive
+ * bundle
+ * commit
+ * format-patch
+ * fast-export
+ * fast-import
+ * commit-tree
+
+ * commands that write any modified file to the working tree (conflicted
+ or not, and whether those paths match sparsity patterns or not):
+
+ * stash
+ * apply (without `--index` or `--cached`)
+
+* Commands that may slightly differ for behavior A vs. behavior B:
+
+ Commands in this category behave mostly the same between the two
+ behaviors, but may differ in verbosity and types of warning and error
+ messages.
+
+ * commands that make modifications to which files are tracked:
+ * add
+ * rm
+ * mv
+ * update-index
+
+ The fact that files can move between the 'tracked' and 'untracked'
+ categories means some commands will have to treat untracked files
+ differently. But if we have to treat untracked files differently,
+ then additional commands may also need changes:
+
+ * status
+ * clean
+
+ In particular, `status` may need to report any untracked files outside
+ the sparsity specification as an erroneous condition (especially to
+ avoid the user trying to `git add` them, forcing `git add` to display
+ an error).
+
+ It's not clear to me exactly how (or even if) `clean` would change,
+ but it's the other command that also affects untracked files.
+
+ `update-index` may be slightly special. Its --[no-]skip-worktree flag
+ may need to ignore the sparse specification by its nature. Also, its
+ current --[no-]ignore-skip-worktree-entries default is totally bogus.
+
+ * commands for manually tweaking paths in both the index and the working tree
+ * `restore`
+ * the restore-like half of `checkout`
+
+ These commands should be similar to add/rm/mv in that they should
+ only operate on the sparse specification by default, and require a
+ special flag to operate on all files.
+
+ Also, note that these commands currently have a number of issues (see
+ the "Known bugs" section below)
+
+* Commands that significantly differ for behavior A vs. behavior B:
+
+ * commands that query history
+ * diff (with --cached or REVISION arguments)
+ * grep (with --cached or REVISION arguments)
+ * show (when given commit arguments)
+ * blame (only matters when one or more -C flags are passed)
+ * and annotate
+ * log
+ * whatchanged
+ * ls-files
+ * diff-index
+ * diff-tree
+ * ls-tree
+
+ Note: for log and whatchanged, revision walking logic is unaffected
+ but displaying of patches is affected by scoping the command to the
+ sparse-checkout. (The fact that revision walking is unaffected is
+ why rev-list, shortlog, show-branch, and bisect are not in this
+ list.)
+
+ ls-files may be slightly special in that e.g. `git ls-files -t` is
+ often used to see what is sparse and what is not. Perhaps -t should
+ always work on the full tree?
+
+* Commands I don't know how to classify
+
+ * range-diff
+
+ Is this like `log` or `format-patch`?
+
+ * cherry
+
+ See range-diff
+
+* Commands unaffected by sparse-checkouts
+
+ * shortlog
+ * show-branch
+ * rev-list
+ * bisect
+
+ * branch
+ * describe
+ * fetch
+ * gc
+ * init
+ * maintenance
+ * notes
+ * pull (merge & rebase have the necessary changes)
+ * push
+ * submodule
+ * tag
+
+ * config
+ * filter-branch (works in separate checkout without sparse-checkout setup)
+ * pack-refs
+ * prune
+ * remote
+ * repack
+ * replace
+
+ * bugreport
+ * count-objects
+ * fsck
+ * gitweb
+ * help
+ * instaweb
+ * merge-tree (doesn't touch worktree or index, and merges always compute full-tree)
+ * rerere
+ * verify-commit
+ * verify-tag
+
+ * commit-graph
+ * hash-object
+ * index-pack
+ * mktag
+ * mktree
+ * multi-pack-index
+ * pack-objects
+ * prune-packed
+ * symbolic-ref
+ * unpack-objects
+ * update-ref
+ * write-tree (operates on index, possibly optimized to use sparse dir entries)
+
+ * for-each-ref
+ * get-tar-commit-id
+ * ls-remote
+ * merge-base (merges are computed full tree, so merge base should be too)
+ * name-rev
+ * pack-redundant
+ * rev-parse
+ * show-index
+ * show-ref
+ * unpack-file
+ * var
+ * verify-pack
+
+ * <Everything under 'Interacting with Others' in 'git help --all'>
+ * <Everything under 'Low-level...Syncing' in 'git help --all'>
+ * <Everything under 'Low-level...Internal Helpers' in 'git help --all'>
+ * <Everything under 'External commands' in 'git help --all'>
+
+* Commands that might be affected, but who cares?
+
+ * merge-file
+ * merge-index
+ * gitk?
+
+
+=== Behavior classes ===
+
+From the above there are a few classes of behavior:
+
+ * "restrict"
+
+ Commands in this class only read or write files in the working tree
+ within the sparse specification.
+
+ When moving to a new commit (e.g. switch, reset --hard), these commands
+ may update index files outside the sparse specification as of the start
+ of the operation, but by the end of the operation those index files
+ will match HEAD again and thus those files will again be outside the
+ sparse specification.
+
+ When paths are explicitly specified, these paths are intersected with
+ the sparse specification and will only operate on such paths.
+ (e.g. `git restore [--staged] -- '*.png'`, `git reset -p -- '*.md'`)
+
+ Some of these commands may also attempt, at the end of their operation,
+ to cull transient differences between the sparse specification and the
+ sparsity patterns (see "Sparse specification vs. sparsity patterns" for
+ details, but this basically means either removing unmodified files not
+ matching the sparsity patterns and marking those files as
+ SKIP_WORKTREE, or vivifying files that match the sparsity patterns and
+ marking those files as !SKIP_WORKTREE).
+
+ * "restrict modulo conflicts"
+
+ Commands in this class generally behave like the "restrict" class,
+ except that:
+ (1) they will ignore the sparse specification and write files with
+ conflicts to the working tree (thus temporarily expanding the
+ sparse specification to include such files.)
+ (2) they are grouped with commands which move to a new commit, since
+ they often create a commit and then move to it, even though we
+ know there are many exceptions to moving to the new commit. (For
+ example, the user may rebase a commit that becomes empty, or have
+ a cherry-pick which conflicts, or a user could run `merge
+ --no-commit`, and we also view `apply --index` kind of like `am
+ --no-commit`.) As such, these commands can make changes to index
+ files outside the sparse specification, though they'll mark such
+ files with SKIP_WORKTREE.
+
+ * "restrict also specially applied to untracked files"
+
+ Commands in this class generally behave like the "restrict" class,
+ except that they have to handle untracked files differently too, often
+ because these commands are dealing with files changing state between
+ 'tracked' and 'untracked'. Often, this may mean printing an error
+ message if the command had nothing to do, but the arguments may have
+ referred to files whose tracked-ness state could have changed were it
+ not for the sparsity patterns excluding them.
+
+ * "no restrict"
+
+ Commands in this class ignore the sparse specification entirely.
+
+ * "restrict or no restrict dependent upon behavior A vs. behavior B"
+
+ Commands in this class behave like "no restrict" for folks in the
+ behavior B camp, and like "restrict" for folks in the behavior A camp.
+ However, when behaving like "restrict" a warning of some sort might be
+ provided that history queries have been limited by the sparse-checkout
+ specification.
+
+
+=== Subcommand-dependent defaults ===
+
+Note that we have different defaults depending on the command for the
+desired behavior :
+
+ * Commands defaulting to "restrict":
+ * diff-files
+ * diff (without --cached or REVISION arguments)
+ * grep (without --cached or REVISION arguments)
+ * switch
+ * checkout (the switch-like half)
+ * reset (<commit>)
+
+ * restore
+ * checkout (the restore-like half)
+ * checkout-index
+ * reset (with pathspec)
+
+ This behavior makes sense; these interact with the working tree.
+
+ * Commands defaulting to "restrict modulo conflicts":
+ * merge
+ * rebase
+ * cherry-pick
+ * revert
+
+ * am
+ * apply --index (which is kind of like an `am --no-commit`)
+
+ * read-tree (especially with -m or -u; is kind of like a --no-commit merge)
+ * reset (<tree-ish>, due to similarity to read-tree)
+
+ These also interact with the working tree, but require slightly
+ different behavior either so that (a) conflicts can be resolved or (b)
+ because they are kind of like a merge-without-commit operation.
+
+ (See also the "Known bugs" section below regarding `am` and `apply`)
+
+ * Commands defaulting to "no restrict":
+ * archive
+ * bundle
+ * commit
+ * format-patch
+ * fast-export
+ * fast-import
+ * commit-tree
+
+ * stash
+ * apply (without `--index`)
+
+ These have completely different defaults and perhaps deserve the most
+ detailed explanation:
+
+ In the case of commands in the first group (format-patch,
+ fast-export, bundle, archive, etc.), these are commands for
+ communicating history, which will be broken if they restrict to a
+ subset of the repository. As such, they operate on full paths and
+ have no `--restrict` option for overriding. Some of these commands may
+ take paths for manually restricting what is exported, but it needs to
+ be very explicit.
+
+ In the case of stash, it needs to vivify files to avoid losing the
+ user's changes.
+
+ In the case of apply without `--index`, that command needs to update
+ the working tree without the index (or the index without the working
+ tree if `--cached` is passed), and if we restrict those updates to the
+ sparse specification then we'll lose changes from the user.
+
+ * Commands defaulting to "restrict also specially applied to untracked files":
+ * add
+ * rm
+ * mv
+ * update-index
+ * status
+ * clean (?)
+
+ Our original implementation for the first three of these commands was
+ "no restrict", but it had some severe usability issues:
+ * `git add <somefile>` if honored and outside the sparse
+ specification, can result in the file randomly disappearing later
+ when some subsequent command is run (since various commands
+ automatically clean up unmodified files outside the sparse
+ specification).
+ * `git rm '*.jpg'` could very negatively surprise users if it deletes
+ files outside the range of the user's interest.
+ * `git mv` has similar surprises when moving into or out of the cone,
+ so best to restrict by default
+
+ So, we switched `add` and `rm` to default to "restrict", which made
+ usability problems much less severe and less frequent, but we still got
+ complaints because commands like:
+ git add <file-outside-sparse-specification>
+ git rm <file-outside-sparse-specification>
+ would silently do nothing. We should instead print an error in those
+ cases to get usability right.
+
+ update-index needs to be updated to match, and status and maybe clean
+ also need to be updated to specially handle untracked paths.
+
+ There may be a difference in here between behavior A and behavior B in
+ terms of verboseness of errors or additional warnings.
+
+ * Commands falling under "restrict or no restrict dependent upon behavior
+ A vs. behavior B"
+
+ * diff (with --cached or REVISION arguments)
+ * grep (with --cached or REVISION arguments)
+ * show (when given commit arguments)
+ * blame (only matters when one or more -C flags passed)
+ * and annotate
+ * log
+ * and variants: shortlog, gitk, show-branch, whatchanged, rev-list
+ * ls-files
+ * diff-index
+ * diff-tree
+ * ls-tree
+
+ For now, we default to behavior B for these, which want a default of
+ "no restrict".
+
+ Note that two of these commands -- diff and grep -- also appeared in a
+ different list with a default of "restrict", but only when limited to
+ searching the working tree. The working tree vs. history distinction
+ is fundamental in how behavior B operates, so this is expected. Note,
+ though, that for diff and grep with --cached, when doing "restrict"
+ behavior, the difference between sparse specification and sparsity
+ patterns is important to handle.
+
+ "restrict" may make more sense as the long term default for these[12].
+ Also, supporting "restrict" for these commands might be a fair amount
+ of work to implement, meaning it might be implemented over multiple
+ releases. If that behavior were the default in the commands that
+ supported it, that would force behavior B users to need to learn to
+ slowly add additional flags to their commands, depending on git
+ version, to get the behavior they want. That gradual switchover would
+ be painful, so we should avoid it at least until it's fully
+ implemented.
+
+
+=== Sparse specification vs. sparsity patterns ===
+
+In a well-behaved situation, the sparse specification is given directly
+by the $GIT_DIR/info/sparse-checkout file. However, it can transiently
+diverge for a few reasons:
+
+ * needing to resolve conflicts (merging will vivify conflicted files)
+ * running Git commands that implicitly vivify files (e.g. "git stash apply")
+ * running Git commands that explicitly vivify files (e.g. "git checkout
+ --ignore-skip-worktree-bits FILENAME")
+ * other commands that write to these files (perhaps a user copies it
+ from elsewhere)
+
+For the last item, note that we do automatically clear the SKIP_WORKTREE
+bit for files that are present in the working tree. This has been true
+since 82386b4496 ("Merge branch 'en/present-despite-skipped'",
+2022-03-09)
+
+However, such a situation is transient because:
+
+ * Such transient differences can and will be automatically removed as
+ a side-effect of commands which call unpack_trees() (checkout,
+ merge, reset, etc.).
+ * Users can also request such transient differences be corrected via
+ running `git sparse-checkout reapply`. Various places recommend
+ running that command.
+ * Additional commands are also welcome to implicitly fix these
+ differences; we may add more in the future.
+
+While we avoid dropping unstaged changes or files which have conflicts,
+we otherwise aggressively try to fix these transient differences. If
+users want these differences to persist, they should run the `set` or
+`add` subcommands of `git sparse-checkout` to reflect their intended
+sparse specification.
+
+However, when we need to do a query on history restricted to the
+"relevant subset of files" such a transiently expanded sparse
+specification is ignored. There are a couple reasons for this:
+
+ * The behavior wanted when doing something like
+ git grep expression REVISION
+ is roughly what the users would expect from
+ git checkout REVISION && git grep expression
+ (modulo a "REVISION:" prefix), which has a couple ramifications:
+
+ * REVISION may have paths not in the current index, so there is no
+ path we can consult for a SKIP_WORKTREE setting for those paths.
+
+ * Since `checkout` is one of those commands that tries to remove
+ transient differences in the sparse specification, it makes sense
+ to use the corrected sparse specification
+ (i.e. $GIT_DIR/info/sparse-checkout) rather than attempting to
+ consult SKIP_WORKTREE anyway.
+
+So, a transiently expanded (or restricted) sparse specification applies to
+the working tree, but not to history queries where we always use the
+sparsity patterns. (See [16] for an early discussion of this.)
+
+Similar to a transiently expanded sparse specification of the working tree
+based on additional files being present in the working tree, we also need
+to consider additional files being modified in the index. In particular,
+if the user has staged changes to files (relative to HEAD) that do not
+match the sparsity patterns, and the file is not present in the working
+tree, we still want to consider the file part of the sparse specification
+if we are specifically performing a query related to the index (e.g. git
+diff --cached [REVISION], git diff-index [REVISION], git restore --staged
+--source=REVISION -- PATHS, etc.) Note that a transiently expanded sparse
+specification for the index usually only matters under behavior A, since
+under behavior B index operations are lumped with history and tend to
+operate full-tree.
+
+
+=== Implementation Questions ===
+
+ * Do the options --scope={sparse,all} sound good to others? Are there better
+ options?
+ * Names in use, or appearing in patches, or previously suggested:
+ * --sparse/--dense
+ * --ignore-skip-worktree-bits
+ * --ignore-skip-worktree-entries
+ * --ignore-sparsity
+ * --[no-]restrict-to-sparse-paths
+ * --full-tree/--sparse-tree
+ * --[no-]restrict
+ * --scope={sparse,all}
+ * --focus/--unfocus
+ * --limit/--unlimited
+ * Rationale making me lean slightly towards --scope={sparse,all}:
+ * We want a name that works for many commands, so we need a name that
+ does not conflict
+ * We know that we have more than two possible usecases, so it is best
+ to avoid a flag that appears to be binary.
+ * --scope={sparse,all} isn't overly long and seems relatively
+ explanatory
+ * `--sparse`, as used in add/rm/mv, is totally backwards for
+ grep/log/etc. Changing the meaning of `--sparse` for these
+ commands would fix the backwardness, but possibly break existing
+ scripts. Using a new name pairing would allow us to treat
+ `--sparse` in these commands as a deprecated alias.
+ * There is a different `--sparse`/`--dense` pair for commands using
+ revision machinery, so using that naming might cause confusion
+ * There is also a `--sparse` in both pack-objects and show-branch, which
+ don't conflict but do suggest that `--sparse` is overloaded
+ * The name --ignore-skip-worktree-bits is a double negative, is
+ quite a mouthful, refers to an implementation detail that many
+ users may not be familiar with, and we'd need a negation for it
+ which would probably be even more ridiculously long. (But we
+ can make --ignore-skip-worktree-bits a deprecated alias for
+ --no-restrict.)
+
+ * If a config option is added (sparse.scope?) what should the values and
+ description be? "sparse" (behavior A), "worktree-sparse-history-dense"
+ (behavior B), "dense" (behavior C)? There's a risk of confusion,
+ because even for Behaviors A and B we want some commands to be
+ full-tree and others to operate sparsely, so the wording may need to be
+ more tied to the usecases and somehow explain that. Also, right now,
+ the primary difference we are focusing is just the history-querying
+ commands (log/diff/grep). Previous config suggestion here: [13]
+
+ * Is `--no-expand` a good alias for ls-files's `--sparse` option?
+ (`--sparse` does not map to either `--scope=sparse` or `--scope=all`,
+ because in non-cone mode it does nothing and in cone-mode it shows the
+ sparse directory entries which are technically outside the sparse
+ specification)
+
+ * Under Behavior A:
+ * Does ls-files' `--no-expand` override the default `--scope=all`, or
+ does it need an extra flag?
+ * Does ls-files' `-t` option imply `--scope=all`?
+ * Does update-index's `--[no-]skip-worktree` option imply `--scope=all`?
+
+ * sparse-checkout: once behavior A is fully implemented, should we take
+ an interim measure to ease people into switching the default? Namely,
+ if folks are not already in a sparse checkout, then require
+ `sparse-checkout init/set` to take a
+ `--set-scope=(sparse|worktree-sparse-history-dense|dense)` flag (which
+ would set sparse.scope according to the setting given), and throw an
+ error if the flag is not provided? That error would be a great place
+ to warn folks that the default may change in the future, and get them
+ used to specifying what they want so that the eventual default switch
+ is seamless for them.
+
+
+=== Implementation Goals/Plans ===
+
+ * Get buy-in on this document in general.
+
+ * Figure out answers to the 'Implementation Questions' sections (above)
+
+ * Fix bugs in the 'Known bugs' section (below)
+
+ * Provide some kind of method for backfilling the blobs within the sparse
+ specification in a partial clone
+
+ [Below here is kind of spitballing since the first two haven't been resolved]
+
+ * update-index: flip the default to --no-ignore-skip-worktree-entries,
+ nuke this stupid "Oh, there's a bug? Let me add a flag to let users
+ request that they not trigger this bug." flag
+
+ * Flags & Config
+ * Make `--sparse` in add/rm/mv a deprecated alias for `--scope=all`
+ * Make `--ignore-skip-worktree-bits` in checkout-index/checkout/restore
+ a deprecated aliases for `--scope=all`
+ * Create config option (sparse.scope?), tie it to the "Cliff notes"
+ overview
+
+ * Add --scope=sparse (and --scope=all) flag to each of the history querying
+ commands. IMPORTANT: make sure diff machinery changes don't mess with
+ format-patch, fast-export, etc.
+
+=== Known bugs ===
+
+This list used to be a lot longer (see e.g. [1,2,3,4,5,6,7,8,9]), but we've
+been working on it.
+
+0. Behavior A is not well supported in Git. (Behavior B didn't used to
+ be either, but was the easier of the two to implement.)
+
+1. am and apply:
+
+ apply, without `--index` or `--cached`, relies on files being present
+ in the working copy, and also writes to them unconditionally. As
+ such, it should first check for the files' presence, and if found to
+ be SKIP_WORKTREE, then clear the bit and vivify the paths, then do
+ its work. Currently, it just throws an error.
+
+ apply, with either `--cached` or `--index`, will not preserve the
+ SKIP_WORKTREE bit. This is fine if the file has conflicts, but
+ otherwise SKIP_WORKTREE bits should be preserved for --cached and
+ probably also for --index.
+
+ am, if there are no conflicts, will vivify files and fail to preserve
+ the SKIP_WORKTREE bit. If there are conflicts and `-3` is not
+ specified, it will vivify files and then complain the patch doesn't
+ apply. If there are conflicts and `-3` is specified, it will vivify
+ files and then complain that those vivified files would be
+ overwritten by merge.
+
+2. reset --hard:
+
+ reset --hard provides confusing error message (works correctly, but
+ misleads the user into believing it didn't):
+
+ $ touch addme
+ $ git add addme
+ $ git ls-files -t
+ H addme
+ H tracked
+ S tracked-but-maybe-skipped
+ $ git reset --hard # usually works great
+ error: Path 'addme' not uptodate; will not remove from working tree.
+ HEAD is now at bdbbb6f third
+ $ git ls-files -t
+ H tracked
+ S tracked-but-maybe-skipped
+ $ ls -1
+ tracked
+
+ `git reset --hard` DID remove addme from the index and the working tree, contrary
+ to the error message, but in line with how reset --hard should behave.
+
+3. read-tree
+
+ `read-tree` doesn't apply the 'SKIP_WORKTREE' bit to *any* of the
+ entries it reads into the index, resulting in all your files suddenly
+ appearing to be "deleted".
+
+4. Checkout, restore:
+
+ These command do not handle path & revision arguments appropriately:
+
+ $ ls
+ tracked
+ $ git ls-files -t
+ H tracked
+ S tracked-but-maybe-skipped
+ $ git status --porcelain
+ $ git checkout -- '*skipped'
+ error: pathspec '*skipped' did not match any file(s) known to git
+ $ git ls-files -- '*skipped'
+ tracked-but-maybe-skipped
+ $ git checkout HEAD -- '*skipped'
+ error: pathspec '*skipped' did not match any file(s) known to git
+ $ git ls-tree HEAD | grep skipped
+ 100644 blob 276f5a64354b791b13840f02047738c77ad0584f tracked-but-maybe-skipped
+ $ git status --porcelain
+ $ git checkout HEAD~1 -- '*skipped'
+ $ git ls-files -t
+ H tracked
+ H tracked-but-maybe-skipped
+ $ git status --porcelain
+ M tracked-but-maybe-skipped
+ $ git checkout HEAD -- '*skipped'
+ $ git status --porcelain
+ $
+
+ Note that checkout without a revision (or restore --staged) fails to
+ find a file to restore from the index, even though ls-files shows
+ such a file certainly exists.
+
+ Similar issues occur with HEAD (--source=HEAD in restore's case),
+ but suddenly works when HEAD~1 is specified. And then after that it
+ will work with HEAD specified, even though it didn't before.
+
+ Directories are also an issue:
+
+ $ git sparse-checkout set nomatches
+ $ git status
+ On branch main
+ You are in a sparse checkout with 0% of tracked files present.
+
+ nothing to commit, working tree clean
+ $ git checkout .
+ error: pathspec '.' did not match any file(s) known to git
+ $ git checkout HEAD~1 .
+ Updated 1 path from 58916d9
+ $ git ls-files -t
+ S tracked
+ H tracked-but-maybe-skipped
+
+5. checkout and restore --staged, continued:
+
+ These commands do not correctly scope operations to the sparse
+ specification, and make it worse by not setting important SKIP_WORKTREE
+ bits:
+
+ $ git restore --source OLDREV --staged outside-sparse-cone/
+ $ git status --porcelain
+ MD outside-sparse-cone/file1
+ MD outside-sparse-cone/file2
+ MD outside-sparse-cone/file3
+
+ We can add a --scope=all mode to `git restore` to let it operate outside
+ the sparse specification, but then it will be important to set the
+ SKIP_WORKTREE bits appropriately.
+
+6. Performance issues; see:
+ https://lore.kernel.org/git/CABPp-BEkJQoKZsQGCYioyga_uoDQ6iBeW+FKr8JhyuuTMK1RDw@mail.gmail.com/
+
+
+=== Reference Emails ===
+
+Emails that detail various bugs we've had in sparse-checkout:
+
+[1] (Original descriptions of behavior A & behavior B)
+ https://lore.kernel.org/git/CABPp-BGJ_Nvi5TmgriD9Bh6eNXE2EDq2f8e8QKXAeYG3BxZafA@mail.gmail.com/
+[2] (Fix stash applications in sparse checkouts; bugs from behavioral differences)
+ https://lore.kernel.org/git/ccfedc7140dbf63ba26a15f93bd3885180b26517.1606861519.git.gitgitgadget@gmail.com/
+[3] (Present-despite-skipped entries)
+ https://lore.kernel.org/git/11d46a399d26c913787b704d2b7169cafc28d639.1642175983.git.gitgitgadget@gmail.com/
+[4] (Clone --no-checkout interaction)
+ https://lore.kernel.org/git/pull.801.v2.git.git.1591324899170.gitgitgadget@gmail.com/ (clone --no-checkout)
+[5] (The need for update_sparsity() and avoiding `read-tree -mu HEAD`)
+ https://lore.kernel.org/git/3a1f084641eb47515b5a41ed4409a36128913309.1585270142.git.gitgitgadget@gmail.com/
+[6] (SKIP_WORKTREE is advisory, not mandatory)
+ https://lore.kernel.org/git/844306c3e86ef67591cc086decb2b760e7d710a3.1585270142.git.gitgitgadget@gmail.com/
+[7] (`worktree add` should copy sparsity settings from current worktree)
+ https://lore.kernel.org/git/c51cb3714e7b1d2f8c9370fe87eca9984ff4859f.1644269584.git.gitgitgadget@gmail.com/
+[8] (Avoid negative surprises in add, rm, and mv)
+ https://lore.kernel.org/git/cover.1617914011.git.matheus.bernardino@usp.br/
+ https://lore.kernel.org/git/pull.1018.v4.git.1632497954.gitgitgadget@gmail.com/
+[9] (Move from out-of-cone to in-cone)
+ https://lore.kernel.org/git/20220630023737.473690-6-shaoxuan.yuan02@gmail.com/
+ https://lore.kernel.org/git/20220630023737.473690-4-shaoxuan.yuan02@gmail.com/
+[10] (Unnecessarily downloading objects outside sparse specification)
+ https://lore.kernel.org/git/CAOLTT8QfwOi9yx_qZZgyGa8iL8kHWutEED7ok_jxwTcYT_hf9Q@mail.gmail.com/
+
+[11] (Stolee's comments on high-level usecases)
+ https://lore.kernel.org/git/1a1e33f6-3514-9afc-0a28-5a6b85bd8014@gmail.com/
+
+[12] Others commenting on eventually switching default to behavior A:
+ * https://lore.kernel.org/git/xmqqh719pcoo.fsf@gitster.g/
+ * https://lore.kernel.org/git/xmqqzgeqw0sy.fsf@gitster.g/
+ * https://lore.kernel.org/git/a86af661-cf58-a4e5-0214-a67d3a794d7e@github.com/
+
+[13] Previous config name suggestion and description
+ * https://lore.kernel.org/git/CABPp-BE6zW0nJSStcVU=_DoDBnPgLqOR8pkTXK3dW11=T01OhA@mail.gmail.com/
+
+[14] Tangential issue: switch to cone mode as default sparse specification mechanism:
+ https://lore.kernel.org/git/a1b68fd6126eb341ef3637bb93fedad4309b36d0.1650594746.git.gitgitgadget@gmail.com/
+
+[15] Lengthy email on grep behavior, covering what should be searched:
+ * https://lore.kernel.org/git/CABPp-BGVO3QdbfE84uF_3QDF0-y2iHHh6G5FAFzNRfeRitkuHw@mail.gmail.com/
+
+[16] Email explaining sparsity patterns vs. SKIP_WORKTREE and history operations,
+ search for the parenthetical comment starting "We do not check".
+ https://lore.kernel.org/git/CABPp-BFsCPPNOZ92JQRJeGyNd0e-TCW-LcLyr0i_+VSQJP+GCg@mail.gmail.com/
+
+[17] https://lore.kernel.org/git/20220207190320.2960362-1-jonathantanmy@google.com/
diff --git a/technical/sparse-index.adoc b/technical/sparse-index.adoc
new file mode 100644
index 0000000..3b24c1a
--- /dev/null
+++ b/technical/sparse-index.adoc
@@ -0,0 +1,208 @@
+Git Sparse-Index Design Document
+================================
+
+The sparse-checkout feature allows users to focus a working directory on
+a subset of the files at HEAD. The cone mode patterns, enabled by
+`core.sparseCheckoutCone`, allow for very fast pattern matching to
+discover which files at HEAD belong in the sparse-checkout cone.
+
+Three important scale dimensions for a Git working directory are:
+
+* `HEAD`: How many files are present at `HEAD`?
+
+* Populated: How many files are within the sparse-checkout cone.
+
+* Modified: How many files has the user modified in the working directory?
+
+We will use big-O notation -- O(X) -- to denote how expensive certain
+operations are in terms of these dimensions.
+
+These dimensions are ordered by their magnitude: users (typically) modify
+fewer files than are populated, and we can only populate files at `HEAD`.
+
+Problems occur if there is an extreme imbalance in these dimensions. For
+example, if `HEAD` contains millions of paths but the populated set has
+only tens of thousands, then commands like `git status` and `git add` can
+be dominated by operations that require O(`HEAD`) operations instead of
+O(Populated). Primarily, the cost is in parsing and rewriting the index,
+which is filled primarily with files at `HEAD` that are marked with the
+`SKIP_WORKTREE` bit.
+
+The sparse-index intends to take these commands that read and modify the
+index from O(`HEAD`) to O(Populated). To do this, we need to modify the
+index format in a significant way: add "sparse directory" entries.
+
+With cone mode patterns, it is possible to detect when an entire
+directory will have its contents outside of the sparse-checkout definition.
+Instead of listing all of the files it contains as individual entries, a
+sparse-index contains an entry with the directory name, referencing the
+object ID of the tree at `HEAD` and marked with the `SKIP_WORKTREE` bit.
+If we need to discover the details for paths within that directory, we
+can parse trees to find that list.
+
+At time of writing, sparse-directory entries violate expectations about the
+index format and its in-memory data structure. There are many consumers in
+the codebase that expect to iterate through all of the index entries and
+see only files. In fact, these loops expect to see a reference to every
+staged file. One way to handle this is to parse trees to replace a
+sparse-directory entry with all of the files within that tree as the index
+is loaded. However, parsing trees is slower than parsing the index format,
+so that is a slower operation than if we left the index alone. The plan is
+to make all of these integrations "sparse aware" so this expansion through
+tree parsing is unnecessary and they use fewer resources than when using a
+full index.
+
+The implementation plan below follows four phases to slowly integrate with
+the sparse-index. The intention is to incrementally update Git commands to
+interact safely with the sparse-index without significant slowdowns. This
+may not always be possible, but the hope is that the primary commands that
+users need in their daily work are dramatically improved.
+
+Phase I: Format and initial speedups
+------------------------------------
+
+During this phase, Git learns to enable the sparse-index and safely parse
+one. Protections are put in place so that every consumer of the in-memory
+data structure can operate with its current assumption of every file at
+`HEAD`.
+
+At first, every index parse will call a helper method,
+`ensure_full_index()`, which scans the index for sparse-directory entries
+(pointing to trees) and replaces them with the full list of paths (with
+blob contents) by parsing tree objects. This will be slower in all cases.
+The only noticeable change in behavior will be that the serialized index
+file contains sparse-directory entries.
+
+To start, we use a new required index extension, `sdir`, to allow
+inserting sparse-directory entries into indexes with file format
+versions 2, 3, and 4. This prevents Git versions that do not understand
+the sparse-index from operating on one, while allowing tools that do not
+understand the sparse-index to operate on repositories as long as they do
+not interact with the index. A new format, index v5, will be introduced
+that includes sparse-directory entries by default. It might also
+introduce other features that have been considered for improving the
+index, as well.
+
+Next, consumers of the index will be guarded against operating on a
+sparse-index by inserting calls to `ensure_full_index()` or
+`expand_index_to_path()`. If a specific path is requested, then those will
+be protected from within the `index_file_exists()` and `index_name_pos()`
+API calls: they will call `ensure_full_index()` if necessary. The
+intention here is to preserve existing behavior when interacting with a
+sparse-checkout. We don't want a change to happen by accident, without
+tests. Many of these locations may not need any change before removing the
+guards, but we should not do so without tests to ensure the expected
+behavior happens.
+
+It may be desirable to _change_ the behavior of some commands in the
+presence of a sparse index or more generally in any sparse-checkout
+scenario. In such cases, these should be carefully communicated and
+tested. No such behavior changes are intended during this phase.
+
+During a scan of the codebase, not every iteration of the cache entries
+needs an `ensure_full_index()` check. The basic reasons include:
+
+1. The loop is scanning for entries with non-zero stage. These entries
+ are not collapsed into a sparse-directory entry.
+
+2. The loop is scanning for submodules. These entries are not collapsed
+ into a sparse-directory entry.
+
+3. The loop is part of the index API, especially around reading or
+ writing the format.
+
+4. The loop is checking for correct order of cache entries and that is
+ correct if and only if the sparse-directory entries are in the correct
+ location.
+
+5. The loop ignores entries with the `SKIP_WORKTREE` bit set, or is
+ otherwise already aware of sparse directory entries.
+
+6. The sparse-index is disabled at this point when using the split-index
+ feature, so no effort is made to protect the split-index API.
+
+Even after inserting these guards, we will keep expanding sparse-indexes
+for most Git commands using the `command_requires_full_index` repository
+setting. This setting will be on by default and disabled one builtin at a
+time until we have sufficient confidence that all of the index operations
+are properly guarded.
+
+To complete this phase, the commands `git status` and `git add` will be
+integrated with the sparse-index so that they operate with O(Populated)
+performance. They will be carefully tested for operations within and
+outside the sparse-checkout definition.
+
+Phase II: Careful integrations
+------------------------------
+
+This phase focuses on ensuring that all index extensions and APIs work
+well with a sparse-index. This requires significant increases to our test
+coverage, especially for operations that interact with the working
+directory outside of the sparse-checkout definition. Some of these
+behaviors may not be the desirable ones, such as some tests already
+marked for failure in `t1092-sparse-checkout-compatibility.sh`.
+
+The index extensions that may require special integrations are:
+
+* FS Monitor
+* Untracked cache
+
+While integrating with these features, we should look for patterns that
+might lead to better APIs for interacting with the index. Coalescing
+common usage patterns into an API call can reduce the number of places
+where sparse-directories need to be handled carefully.
+
+Phase III: Important command speedups
+-------------------------------------
+
+At this point, the patterns for testing and implementing sparse-directory
+logic should be relatively stable. This phase focuses on updating some of
+the most common builtins that use the index to operate as O(Populated).
+Here is a potential list of commands that could be valuable to integrate
+at this point:
+
+* `git commit`
+* `git checkout`
+* `git merge`
+* `git rebase`
+
+Hopefully, commands such as `git merge` and `git rebase` can benefit
+instead from merge algorithms that do not use the index as a data
+structure, such as the merge-ORT strategy. As these topics mature, we
+may enable the ORT strategy by default for repositories using the
+sparse-index feature.
+
+Along with `git status` and `git add`, these commands cover the majority
+of users' interactions with the working directory. In addition, we can
+integrate with these commands:
+
+* `git grep`
+* `git rm`
+
+These have been proposed as some whose behavior could change when in a
+repo with a sparse-checkout definition. It would be good to include this
+behavior automatically when using a sparse-index. Some clarity is needed
+to make the behavior switch clear to the user.
+
+This phase is the first where parallel work might be possible without too
+much conflicts between topics.
+
+Phase IV: The long tail
+-----------------------
+
+This last phase is less a "phase" and more "the new normal" after all of
+the previous work.
+
+To start, the `command_requires_full_index` option could be removed in
+favor of expanding only when hitting an API guard.
+
+There are many Git commands that could use special attention to operate as
+O(Populated), while some might be so rare that it is acceptable to leave
+them with additional overhead when a sparse-index is present.
+
+Here are some commands that might be useful to update:
+
+* `git sparse-checkout set`
+* `git am`
+* `git clean`
+* `git stash`
diff --git a/technical/trivial-merge.adoc b/technical/trivial-merge.adoc
new file mode 100644
index 0000000..1f1c33d
--- /dev/null
+++ b/technical/trivial-merge.adoc
@@ -0,0 +1,121 @@
+Trivial merge rules
+===================
+
+This document describes the outcomes of the trivial merge logic in read-tree.
+
+One-way merge
+-------------
+
+This replaces the index with a different tree, keeping the stat info
+for entries that don't change, and allowing -u to make the minimum
+required changes to the working tree to have it match.
+
+Entries marked '+' have stat information. Spaces marked '*' don't
+affect the result.
+
+ index tree result
+ -----------------------
+ * (empty) (empty)
+ (empty) tree tree
+ index+ tree tree
+ index+ index index+
+
+Two-way merge
+-------------
+
+It is permitted for the index to lack an entry; this does not prevent
+any case from applying.
+
+If the index exists, it is an error for it not to match either the old
+or the result.
+
+If multiple cases apply, the one used is listed first.
+
+A result which changes the index is an error if the index is not empty
+and not up to date.
+
+Entries marked '+' have stat information. Spaces marked '*' don't
+affect the result.
+
+ case index old new result
+ -------------------------------------
+ 0/2 (empty) * (empty) (empty)
+ 1/3 (empty) * new new
+ 4/5 index+ (empty) (empty) index+
+ 6/7 index+ (empty) index index+
+ 10 index+ index (empty) (empty)
+ 14/15 index+ old old index+
+ 18/19 index+ old index index+
+ 20 index+ index new new
+
+Three-way merge
+---------------
+
+It is permitted for the index to lack an entry; this does not prevent
+any case from applying.
+
+If the index exists, it is an error for it not to match either the
+head or (if the merge is trivial) the result.
+
+If multiple cases apply, the one used is listed first.
+
+A result of "no merge" means that index is left in stage 0, ancest in
+stage 1, head in stage 2, and remote in stage 3 (if any of these are
+empty, no entry is left for that stage). Otherwise, the given entry is
+left in stage 0, and there are no other entries.
+
+A result of "no merge" is an error if the index is not empty and not
+up to date.
+
+*empty* means that the tree must not have a directory-file conflict
+ with the entry.
+
+For multiple ancestors, a '+' means that this case applies even if
+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
+
+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
+allow directory-file conflicts between things in different stages
+after the trivial merge.
+
+A possible alternative for #6 is (empty), which would make it like
+#1. This is not used, due to the likelihood that it arises due to
+moving the file to multiple different locations or moving and deleting
+it in different branches.
+
+Case #1 is included for completeness, and also in case we decide to
+put on '+' markings; any path that is never mentioned at all isn't
+handled.
+
+Note that #16 is when both #13 and #14 apply; in this case, we refuse
+the trivial merge, because we can't tell from this data which is
+right. This is a case of a reverted patch (in some direction, maybe
+multiple times), and the right answer depends on looking at crossings
+of history or common ancestors of the ancestors.
+
+Note that, between #6, #7, #9, and #11, all cases not otherwise
+covered are handled in this table.
+
+For #8 and #10, there is alternative behavior, not currently
+implemented, where the result is (empty). As currently implemented,
+the automatic merge will generally give this effect.
diff --git a/technical/unit-tests.adoc b/technical/unit-tests.adoc
new file mode 100644
index 0000000..5a432b7
--- /dev/null
+++ b/technical/unit-tests.adoc
@@ -0,0 +1,242 @@
+= Unit Testing
+
+In our current testing environment, we spend a significant amount of effort
+crafting end-to-end tests for error conditions that could easily be captured by
+unit tests (or we simply forgo some hard-to-setup and rare error conditions).
+Unit tests additionally provide stability to the codebase and can simplify
+debugging through isolation. Writing unit tests in pure C, rather than with our
+current shell/test-tool helper setup, simplifies test setup, simplifies passing
+data around (no shell-isms required), and reduces testing runtime by not
+spawning a separate process for every test invocation.
+
+We believe that a large body of unit tests, living alongside the existing test
+suite, will improve code quality for the Git project.
+
+== Definitions
+
+For the purposes of this document, we'll use *test framework* to refer to
+projects that support writing test cases and running tests within the context
+of a single executable. *Test harness* will refer to projects that manage
+running multiple executables (each of which may contain multiple test cases) and
+aggregating their results.
+
+In reality, these terms are not strictly defined, and many of the projects
+discussed below contain features from both categories.
+
+For now, we will evaluate projects solely on their framework features. Since we
+are relying on having TAP output (see below), we can assume that any framework
+can be made to work with a harness that we can choose later.
+
+
+== Summary
+
+We believe the best way forward is to implement a custom TAP framework for the
+Git project. We use a version of the framework originally proposed in
+https://lore.kernel.org/git/c902a166-98ce-afba-93f2-ea6027557176@gmail.com/[1].
+
+See the <<framework-selection,Framework Selection>> section below for the
+rationale behind this decision.
+
+
+== Choosing a test harness
+
+During upstream discussion, it was occasionally noted that `prove` provides many
+convenient features, such as scheduling slower tests first, or re-running
+previously failed tests.
+
+While we already support the use of `prove` as a test harness for the shell
+tests, it is not strictly required. The t/Makefile allows running shell tests
+directly (though with interleaved output if parallelism is enabled). Git
+developers who wish to use `prove` as a more advanced harness can do so by
+setting DEFAULT_TEST_TARGET=prove in their config.mak.
+
+We will follow a similar approach for unit tests: by default the test
+executables will be run directly from the t/Makefile, but `prove` can be
+configured with DEFAULT_UNIT_TEST_TARGET=prove.
+
+
+[[framework-selection]]
+== Framework selection
+
+There are a variety of features we can use to rank the candidate frameworks, and
+those features have different priorities:
+
+* Critical features: we probably won't consider a framework without these
+** Can we legally / easily use the project?
+*** <<license,License>>
+*** <<vendorable-or-ubiquitous,Vendorable or ubiquitous>>
+*** <<maintainable-extensible,Maintainable / extensible>>
+*** <<major-platform-support,Major platform support>>
+** Does the project support our bare-minimum needs?
+*** <<tap-support,TAP support>>
+*** <<diagnostic-output,Diagnostic output>>
+*** <<runtime-skippable-tests,Runtime-skippable tests>>
+* Nice-to-have features:
+** <<parallel-execution,Parallel execution>>
+** <<mock-support,Mock support>>
+** <<signal-error-handling,Signal & error-handling>>
+* Tie-breaker stats
+** <<project-kloc,Project KLOC>>
+** <<adoption,Adoption>>
+
+[[license]]
+=== License
+
+We must be able to legally use the framework in connection with Git. As Git is
+licensed only under GPLv2, we must eliminate any LGPLv3, GPLv3, or Apache 2.0
+projects.
+
+[[vendorable-or-ubiquitous]]
+=== Vendorable or ubiquitous
+
+We want to avoid forcing Git developers to install new tools just to run unit
+tests. Any prospective frameworks and harnesses must either be vendorable
+(meaning, we can copy their source directly into Git's repository), or so
+ubiquitous that it is reasonable to expect that most developers will have the
+tools installed already.
+
+[[maintainable-extensible]]
+=== Maintainable / extensible
+
+It is unlikely that any pre-existing project perfectly fits our needs, so any
+project we select will need to be actively maintained and open to accepting
+changes. Alternatively, assuming we are vendoring the source into our repo, it
+must be simple enough that Git developers can feel comfortable making changes as
+needed to our version.
+
+In the comparison table below, "True" means that the framework seems to have
+active developers, that it is simple enough that Git developers can make changes
+to it, and that the project seems open to accepting external contributions (or
+that it is vendorable). "Partial" means that at least one of the above
+conditions holds.
+
+[[major-platform-support]]
+=== Major platform support
+
+At a bare minimum, unit-testing must work on Linux, MacOS, and Windows.
+
+In the comparison table below, "True" means that it works on all three major
+platforms with no issues. "Partial" means that there may be annoyances on one or
+more platforms, but it is still usable in principle.
+
+[[tap-support]]
+=== TAP support
+
+The https://testanything.org/[Test Anything Protocol] is a text-based interface
+that allows tests to communicate with a test harness. It is already used by
+Git's integration test suite. Supporting TAP output is a mandatory feature for
+any prospective test framework.
+
+In the comparison table below, "True" means this is natively supported.
+"Partial" means TAP output must be generated by post-processing the native
+output.
+
+Frameworks that do not have at least Partial support will not be evaluated
+further.
+
+[[diagnostic-output]]
+=== Diagnostic output
+
+When a test case fails, the framework must generate enough diagnostic output to
+help developers find the appropriate test case in source code in order to debug
+the failure.
+
+[[runtime-skippable-tests]]
+=== Runtime-skippable tests
+
+Test authors may wish to skip certain test cases based on runtime circumstances,
+so the framework should support this.
+
+[[parallel-execution]]
+=== Parallel execution
+
+Ideally, we will build up a significant collection of unit test cases, most
+likely split across multiple executables. It will be necessary to run these
+tests in parallel to enable fast develop-test-debug cycles.
+
+In the comparison table below, "True" means that individual test cases within a
+single test executable can be run in parallel. We assume that executable-level
+parallelism can be handled by the test harness.
+
+[[mock-support]]
+=== Mock support
+
+Unit test authors may wish to test code that interacts with objects that may be
+inconvenient to handle in a test (e.g. interacting with a network service).
+Mocking allows test authors to provide a fake implementation of these objects
+for more convenient tests.
+
+[[signal-error-handling]]
+=== Signal & error handling
+
+The test framework should fail gracefully when test cases are themselves buggy
+or when they are interrupted by signals during runtime.
+
+[[project-kloc]]
+=== Project KLOC
+
+The size of the project, in thousands of lines of code as measured by
+https://dwheeler.com/sloccount/[sloccount] (rounded up to the next multiple of
+1,000). As a tie-breaker, we probably prefer a project with fewer LOC.
+
+[[adoption]]
+=== Adoption
+
+As a tie-breaker, we prefer a more widely-used project. We use the number of
+GitHub / GitLab stars to estimate this.
+
+
+=== Comparison
+
+:true: [lime-background]#True#
+:false: [red-background]#False#
+:partial: [yellow-background]#Partial#
+
+:gpl: [lime-background]#GPL v2#
+:isc: [lime-background]#ISC#
+:mit: [lime-background]#MIT#
+:expat: [lime-background]#Expat#
+:lgpl: [lime-background]#LGPL v2.1#
+
+:custom-impl: https://lore.kernel.org/git/c902a166-98ce-afba-93f2-ea6027557176@gmail.com/[Custom Git impl.]
+:greatest: https://github.com/silentbicycle/greatest[Greatest]
+:criterion: https://github.com/Snaipe/Criterion[Criterion]
+:c-tap: https://github.com/rra/c-tap-harness/[C TAP]
+:check: https://libcheck.github.io/check/[Check]
+:clar: https://github.com/clar-test/clar[Clar]
+
+[format="csv",options="header",width="33%",subs="specialcharacters,attributes,quotes,macros"]
+|=====
+Framework,"<<license,License>>","<<vendorable-or-ubiquitous,Vendorable or ubiquitous>>","<<maintainable-extensible,Maintainable / extensible>>","<<major-platform-support,Major platform support>>","<<tap-support,TAP support>>","<<diagnostic-output,Diagnostic output>>","<<runtime--skippable-tests,Runtime- skippable tests>>","<<parallel-execution,Parallel execution>>","<<mock-support,Mock support>>","<<signal-error-handling,Signal & error handling>>","<<project-kloc,Project KLOC>>","<<adoption,Adoption>>"
+{custom-impl},{gpl},{true},{true},{true},{true},{true},{true},{false},{false},{false},1,0
+{greatest},{isc},{true},{partial},{true},{partial},{true},{true},{false},{false},{false},3,1400
+{criterion},{mit},{false},{partial},{true},{true},{true},{true},{true},{false},{true},19,1800
+{c-tap},{expat},{true},{partial},{partial},{true},{false},{true},{false},{false},{false},4,33
+{check},{lgpl},{false},{partial},{true},{true},{true},{false},{false},{false},{true},17,973
+{clar},{isc},{false},{partial},{true},{true},{true},{true},{false},{false},{true},1,192
+|=====
+
+=== Additional framework candidates
+
+Several suggested frameworks have been eliminated from consideration:
+
+* Incompatible licenses:
+** https://github.com/zorgnax/libtap[libtap] (LGPL v3)
+** https://cmocka.org/[cmocka] (Apache 2.0)
+* Missing source: https://www.kindahl.net/mytap/doc/index.html[MyTap]
+* No TAP support:
+** https://nemequ.github.io/munit/[µnit]
+** https://github.com/google/cmockery[cmockery]
+** https://github.com/lpabon/cmockery2[cmockery2]
+** https://github.com/ThrowTheSwitch/Unity[Unity]
+** https://github.com/siu/minunit[minunit]
+** https://cunit.sourceforge.net/[CUnit]
+
+
+== Milestones
+
+* Add useful tests of library-like code
+* Integrate with
+ https://lore.kernel.org/git/20230502211454.1673000-1-calvinwan@google.com/[stdlib
+ work]
+* Run alongside regular `make test` target
diff --git a/trace2-target-values.adoc b/trace2-target-values.adoc
new file mode 100644
index 0000000..06f1953
--- /dev/null
+++ b/trace2-target-values.adoc
@@ -0,0 +1,12 @@
+--
+* `0` or `false` - Disables the target.
+* `1` or `true` - Writes to `STDERR`.
+* `[2-9]` - Writes to the already opened file descriptor.
+* `<absolute-pathname>` - Writes to the file in append mode. If the target
+already exists and is a directory, the traces will be written to files (one
+per process) underneath the given directory.
+* `af_unix:[<socket-type>:]<absolute-pathname>` - Write to a
+Unix DomainSocket (on platforms that support them). Socket
+type can be either `stream` or `dgram`; if omitted Git will
+try both.
+--
diff --git a/transfer-data-leaks.adoc b/transfer-data-leaks.adoc
new file mode 100644
index 0000000..914bacc
--- /dev/null
+++ b/transfer-data-leaks.adoc
@@ -0,0 +1,30 @@
+SECURITY
+--------
+The fetch and push protocols are not designed to prevent one side from
+stealing data from the other repository that was not intended to be
+shared. If you have private data that you need to protect from a malicious
+peer, your best option is to store it in another repository. This applies
+to both clients and servers. In particular, namespaces on a server are not
+effective for read access control; you should only grant read access to a
+namespace to clients that you would trust with read access to the entire
+repository.
+
+The known attack vectors are as follows:
+
+. The victim sends "have" lines advertising the IDs of objects it has that
+ are not explicitly intended to be shared but can be used to optimize the
+ transfer if the peer also has them. The attacker chooses an object ID X
+ to steal and sends a ref to X, but isn't required to send the content of
+ X because the victim already has it. Now the victim believes that the
+ attacker has X, and it sends the content of X back to the attacker
+ later. (This attack is most straightforward for a client to perform on a
+ server, by creating a ref to X in the namespace the client has access
+ to and then fetching it. The most likely way for a server to perform it
+ on a client is to "merge" X into a public branch and hope that the user
+ does additional work on this branch and pushes it back to the server
+ without noticing the merge.)
+
+. As in #1, the attacker chooses an object ID X to steal. The victim sends
+ an object Y that the attacker already has, and the attacker falsely
+ claims to have X and not Y, so the victim sends Y as a delta against X.
+ The delta reveals regions of X that are similar to Y to the attacker.
diff --git a/urls-remotes.adoc b/urls-remotes.adoc
new file mode 100644
index 0000000..9b10151
--- /dev/null
+++ b/urls-remotes.adoc
@@ -0,0 +1,96 @@
+include::urls.adoc[]
+
+REMOTES[[REMOTES]]
+------------------
+
+The name of one of the following can be used instead
+of a URL as `<repository>` argument:
+
+* a remote in the Git configuration file: `$GIT_DIR/config`,
+* a file in the `$GIT_DIR/remotes` directory, or
+* a file in the `$GIT_DIR/branches` directory.
+
+All of these also allow you to omit the refspec from the command line
+because they each contain a refspec which git will use by default.
+
+Named remote in configuration file
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can choose to provide the name of a remote which you had previously
+configured using linkgit:git-remote[1], linkgit:git-config[1]
+or even by a manual edit to the `$GIT_DIR/config` file. The URL of
+this remote will be used to access the repository. The refspec
+of this remote will be used by default when you do
+not provide a refspec on the command line. The entry in the
+config file would appear like this:
+
+------------
+ [remote "<name>"]
+ url = <URL>
+ pushurl = <pushurl>
+ push = <refspec>
+ fetch = <refspec>
+------------
+
+The `<pushurl>` is used for pushes only. It is optional and defaults
+to `<URL>`. Pushing to a remote affects all defined pushurls or all
+defined urls if no pushurls are defined. Fetch, however, will only
+fetch from the first defined url if multiple urls are defined.
+
+Named file in `$GIT_DIR/remotes`
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can choose to provide the name of a
+file in `$GIT_DIR/remotes`. The URL
+in this file will be used to access the repository. The refspec
+in this file will be used as default when you do not
+provide a refspec on the command line. This file should have the
+following format:
+
+------------
+ URL: one of the above URL formats
+ Push: <refspec>
+ Pull: <refspec>
+
+------------
+
+`Push:` lines are used by 'git push' and
+`Pull:` lines are used by 'git pull' and 'git fetch'.
+Multiple `Push:` and `Pull:` lines may
+be specified for additional branch mappings.
+
+Named file in `$GIT_DIR/branches`
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can choose to provide the name of a
+file in `$GIT_DIR/branches`.
+The URL in this file will be used to access the repository.
+This file should have the following format:
+
+
+------------
+ <URL>#<head>
+------------
+
+`<URL>` is required; `#<head>` is optional.
+
+Depending on the operation, git will use one of the following
+refspecs, if you don't provide one on the command line.
+`<branch>` is the name of this file in `$GIT_DIR/branches` and
+`<head>` defaults to `master`.
+
+git fetch uses:
+
+------------
+ refs/heads/<head>:refs/heads/<branch>
+------------
+
+git push uses:
+
+------------
+ HEAD:refs/heads/<head>
+------------
+
+
+
+
diff --git a/urls.adoc b/urls.adoc
new file mode 100644
index 0000000..9c871e7
--- /dev/null
+++ b/urls.adoc
@@ -0,0 +1,110 @@
+GIT URLS[[URLS]]
+----------------
+
+In general, URLs contain information about the transport protocol, the
+address of the remote server, and the path to the repository.
+Depending on the transport protocol, some of this information may be
+absent.
+
+Git supports ssh, git, http, and https protocols (in addition, ftp
+and ftps can be used for fetching, but this is inefficient and
+deprecated; do not use them).
+
+The native transport (i.e. `git://` URL) does no authentication and
+should be used with caution on unsecured networks.
+
+The following syntaxes may be used with them:
+
+- `ssh://[<user>@]<host>[:<port>]/<path-to-git-repo>`
+- `git://<host>[:<port>]/<path-to-git-repo>`
+- `http[s]://<host>[:<port>]/<path-to-git-repo>`
+- `ftp[s]://<host>[:<port>]/<path-to-git-repo>`
+
+An alternative scp-like syntax may also be used with the ssh protocol:
+
+- `[<user>@]<host>:/<path-to-git-repo>`
+
+This syntax is only recognized if there are no slashes before the
+first colon. This helps differentiate a local path that contains a
+colon. For example the local path `foo:bar` could be specified as an
+absolute path or `./foo:bar` to avoid being misinterpreted as an ssh
+url.
+
+The ssh and git protocols additionally support `~<username>` expansion:
+
+- `ssh://[<user>@]<host>[:<port>]/~<user>/<path-to-git-repo>`
+- `git://<host>[:<port>]/~<user>/<path-to-git-repo>`
+- `[<user>@]<host>:~<user>/<path-to-git-repo>`
+
+For local repositories, also supported by Git natively, the following
+syntaxes may be used:
+
+- `/path/to/repo.git/`
+- `file:///path/to/repo.git/`
+
+ifndef::git-clone[]
+These two syntaxes are mostly equivalent, except when cloning, when
+the former implies `--local` option. See linkgit:git-clone[1] for
+details.
+endif::git-clone[]
+
+ifdef::git-clone[]
+These two syntaxes are mostly equivalent, except the former implies
+`--local` option.
+endif::git-clone[]
+
+`git clone`, `git fetch` and `git pull`, but not `git push`, will also
+accept a suitable bundle file. See linkgit:git-bundle[1].
+
+When Git doesn't know how to handle a certain transport protocol, it
+attempts to use the `remote-<transport>` remote helper, if one
+exists. To explicitly request a remote helper, the following syntax
+may be used:
+
+- `<transport>::<address>`
+
+where _<address>_ may be a path, a server and path, or an arbitrary
+URL-like string recognized by the specific remote helper being
+invoked. See linkgit:gitremote-helpers[7] for details.
+
+If there are a large number of similarly-named remote repositories and
+you want to use a different format for them (such that the URLs you
+use will be rewritten into URLs that work), you can create a
+configuration section of the form:
+
+[verse]
+--
+ [url "__<actual-url-base>__"]
+ insteadOf = _<other-url-base>_
+--
+
+For example, with this:
+
+------------
+ [url "git://git.host.xz/"]
+ insteadOf = host.xz:/path/to/
+ insteadOf = work:
+------------
+
+a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be
+rewritten in any context that takes a URL to be "git://git.host.xz/repo.git".
+
+If you want to rewrite URLs for push only, you can create a
+configuration section of the form:
+
+[verse]
+--
+ [url "__<actual-url-base>__"]
+ pushInsteadOf = _<other-url-base>_
+--
+
+For example, with this:
+
+------------
+ [url "ssh://example.org/"]
+ pushInsteadOf = git://example.org/
+------------
+
+a URL like "git://example.org/path/to/repo.git" will be rewritten to
+"ssh://example.org/path/to/repo.git" for pushes, but pulls will still
+use the original URL.
diff --git a/user-manual.adoc b/user-manual.adoc
new file mode 100644
index 0000000..d2b478a
--- /dev/null
+++ b/user-manual.adoc
@@ -0,0 +1,4638 @@
+= Git User Manual
+
+[preface]
+== Introduction
+
+Git is a fast distributed revision control system.
+
+This manual is designed to be readable by someone with basic UNIX
+command-line skills, but no previous knowledge of Git.
+
+<<repositories-and-branches>> and <<exploring-git-history>> explain how
+to fetch and study a project using git--read these chapters to learn how
+to build and test a particular version of a software project, search for
+regressions, and so on.
+
+People needing to do actual development will also want to read
+<<Developing-With-git>> and <<sharing-development>>.
+
+Further chapters cover more specialized topics.
+
+Comprehensive reference documentation is available through the man
+pages, or linkgit:git-help[1] command. For example, for the command
+`git clone <repo>`, you can either use:
+
+------------------------------------------------
+$ man git-clone
+------------------------------------------------
+
+or:
+
+------------------------------------------------
+$ git help clone
+------------------------------------------------
+
+With the latter, you can use the manual viewer of your choice; see
+linkgit:git-help[1] for more information.
+
+See also <<git-quick-start>> for a brief overview of Git commands,
+without any explanation.
+
+Finally, see <<todo>> for ways that you can help make this manual more
+complete.
+
+
+[[repositories-and-branches]]
+== Repositories and Branches
+
+[[how-to-get-a-git-repository]]
+=== 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 linkgit:git-clone[1] command to
+download a copy of an existing repository. If you don't already have a
+project in mind, here are some interesting examples:
+
+------------------------------------------------
+ # Git itself (approx. 40MB download):
+$ git clone git://git.kernel.org/pub/scm/git/git.git
+ # the Linux kernel (approx. 640MB download):
+$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.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` in the examples above). After you cd into this
+directory, you will see that it contains a copy of the project files,
+called the <<def_working_tree,working tree>>, together with a special
+top-level directory named `.git`, which contains all the information
+about the history of the project.
+
+[[how-to-check-out]]
+=== How to check out a different version of a project
+
+Git is best thought of as a tool for storing the history of a collection
+of files. It stores the history as a compressed collection of
+interrelated snapshots of the project's contents. In Git each such
+version is called a <<def_commit,commit>>.
+
+Those snapshots aren't necessarily all arranged in a single line from
+oldest to newest; instead, work may simultaneously proceed along
+parallel lines of development, called <<def_branch,branches>>, which may
+merge and diverge.
+
+A single Git repository can track development on multiple branches. It
+does this by keeping a list of <<def_head,heads>> which reference the
+latest commit on each branch; the linkgit:git-branch[1] command shows
+you the list of branch heads:
+
+------------------------------------------------
+$ git branch
+* master
+------------------------------------------------
+
+A freshly cloned repository contains a single branch head, by default
+named "master", with the working directory initialized to the state of
+the project referred to by that branch head.
+
+Most projects also use <<def_tag,tags>>. Tags, like heads, are
+references into the project's history, and can be listed using the
+linkgit: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 heads are expected to advance as development progresses.
+
+Create a new branch head pointing to one of these versions and check it
+out using linkgit:git-switch[1]:
+
+------------------------------------------------
+$ git switch -c new v2.6.13
+------------------------------------------------
+
+The working directory then reflects the contents that the project had
+when it was tagged v2.6.13, and linkgit: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 head 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-commits]]
+=== Understanding History: Commits
+
+Every change in the history of a project is represented by a commit.
+The linkgit:git-show[1] command shows the most recent commit on the
+current branch:
+
+------------------------------------------------
+$ git show
+commit 17cf781661e6d38f737f15f53ab552f1e95960d7
+Author: Linus Torvalds <torvalds@ppc970.osdl.org.(none)>
+Date: Tue Apr 19 14:11:06 2005 -0700
+
+ Remove duplicate getenv(DB_ENVIRONMENT) call
+
+ Noted by Tony Luck.
+
+diff --git a/init-db.c b/init-db.c
+index 65898fa..b002dc6 100644
+--- a/init-db.c
++++ b/init-db.c
+@@ -7,7 +7,7 @@
+
+ int main(int argc, char **argv)
+ {
+- char *sha1_dir = getenv(DB_ENVIRONMENT), *path;
++ char *sha1_dir, *path;
+ int len, i;
+
+ if (mkdir(".git", 0755) < 0) {
+------------------------------------------------
+
+As you can see, a commit shows who made the latest change, what they
+did, and why.
+
+Every commit has a 40-hexdigit id, sometimes called the "object name" or the
+"SHA-1 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 it does in yours (assuming their repository
+has that commit at all). Since the object name is computed as a hash over the
+contents of the commit, you are guaranteed that the commit can never change
+without its name also changing.
+
+In fact, in <<git-concepts>> we shall see that everything stored in Git
+history, including file data and directory contents, is stored in an object
+with a name that is a hash of its contents.
+
+[[understanding-reachability]]
+==== 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 linkgit:gitk[1]
+command; running gitk now on a Git repository and looking for merge
+commits will help understand how 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 descendant of X, or that there is a chain of parents
+leading from commit Y to commit X.
+
+[[history-diagrams]]
+==== Understanding 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.
+
+[[what-is-a-branch]]
+==== Understanding history: What is a branch?
+
+When we need to be precise, we will use the word "branch" to mean a line
+of development, and "branch head" (or just "head") to mean a reference
+to the most recent commit on a branch. In the example above, the branch
+head named "A" is a pointer to one particular commit, but we refer to
+the line of three commits leading up to that point as all being part of
+"branch A".
+
+However, when no confusion will result, we often just use the term
+"branch" both for branches and for branch heads.
+
+[[manipulating-branches]]
+=== 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 <branch>`::
+ create a new branch named `<branch>`, referencing the same
+ point in history as the current branch.
+`git branch <branch> <start-point>`::
+ create a new branch named `<branch>`, referencing
+ `<start-point>`, which may be specified any way you like,
+ including using a branch name or a tag name.
+`git branch -d <branch>`::
+ delete the branch `<branch>`; if the branch is not fully
+ merged in its upstream branch or contained in the current branch,
+ this command will fail with a warning.
+`git branch -D <branch>`::
+ delete the branch `<branch>` irrespective of its merged status.
+`git switch <branch>`::
+ make the current branch `<branch>`, updating the working
+ directory to reflect the version referenced by `<branch>`.
+`git switch -c <new> <start-point>`::
+ create a new branch `<new>` referencing `<start-point>`, and
+ check it out.
+
+The special symbol "HEAD" can always be used to refer to the current
+branch. In fact, Git uses a file named `HEAD` in the `.git` directory
+to remember which branch is current:
+
+------------------------------------------------
+$ cat .git/HEAD
+ref: refs/heads/master
+------------------------------------------------
+
+[[detached-head]]
+=== Examining an old version without creating a new branch
+
+The `git switch` command normally expects a branch head, but will also
+accept an arbitrary commit when invoked with --detach; for example,
+you can check out the commit referenced by a tag:
+
+------------------------------------------------
+$ git switch --detach v2.6.17
+Note: checking out 'v2.6.17'.
+
+You are in 'detached HEAD' state. You can look around, make experimental
+changes and commit them, and you can discard any commits you make in this
+state without impacting any branches by performing another switch.
+
+If you want to create a new branch to retain commits you create, you may
+do so (now or later) by using -c with the switch command again. Example:
+
+ git switch -c new_branch_name
+
+HEAD is now at 427abfa Linux v2.6.17
+------------------------------------------------
+
+The HEAD then refers to the SHA-1 of the commit instead of to a branch,
+and git branch shows that you are no longer on a branch:
+
+------------------------------------------------
+$ cat .git/HEAD
+427abfa28afedffadfca9dd8b067eb6d36bac53f
+$ git branch
+* (detached from v2.6.17)
+ master
+------------------------------------------------
+
+In this case we say that the HEAD is "detached".
+
+This is an easy way to check out a particular version without having to
+make up a name for the new branch. You can still create a new branch
+(or tag) for this version later if you decide to.
+
+[[examining-remote-branches]]
+=== 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, called
+remote-tracking branches, which you
+can view using the `-r` option to linkgit:git-branch[1]:
+
+------------------------------------------------
+$ git branch -r
+ origin/HEAD
+ origin/html
+ origin/maint
+ origin/man
+ origin/master
+ origin/next
+ origin/seen
+ origin/todo
+------------------------------------------------
+
+In this example, "origin" is called a remote repository, or "remote"
+for short. The branches of this repository are called "remote
+branches" from our point of view. The remote-tracking branches listed
+above were created based on the remote branches at clone time and will
+be updated by `git fetch` (hence `git pull`) and `git push`. See
+<<Updating-a-repository-With-git-fetch>> for details.
+
+You might want to build on one of these remote-tracking branches
+on a branch of your own, just as you would for a tag:
+
+------------------------------------------------
+$ git switch -c my-todo-copy origin/todo
+------------------------------------------------
+
+You can also check out `origin/todo` directly to examine it or
+write a one-off patch. See <<detached-head,detached head>>.
+
+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.
+
+(Newly created refs are actually stored in the `.git/refs` directory,
+under the path given by their name. However, for efficiency reasons
+they may also be packed together in a single file; see
+linkgit:git-pack-refs[1]).
+
+As another useful shortcut, the "HEAD" of a repository can be referred
+to just using the name of that repository. So, for example, "origin"
+is usually a shortcut for the HEAD branch in the repository "origin".
+
+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 linkgit:gitrevisions[7].
+
+[[Updating-a-repository-With-git-fetch]]
+=== Updating a repository with git fetch
+
+After you clone a repository and commit a few changes of your own, you
+may wish to check the original repository for updates.
+
+The `git-fetch` command, with no arguments, will update all of the
+remote-tracking branches to the latest version found in the original
+repository. It will not touch any of your own branches--not even the
+"master" branch that was created for you on clone.
+
+[[fetching-branches]]
+=== Fetching branches from other repositories
+
+You can also track branches from repositories other than the one you
+cloned from, using linkgit:git-remote[1]:
+
+-------------------------------------------------
+$ git remote add staging git://git.kernel.org/.../gregkh/staging.git
+$ git fetch staging
+...
+From git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
+ * [new branch] master -> staging/master
+ * [new branch] staging-linus -> staging/staging-linus
+ * [new branch] staging-next -> staging/staging-next
+-------------------------------------------------
+
+New remote-tracking branches will be stored under the shorthand name
+that you gave `git remote add`, in this case `staging`:
+
+-------------------------------------------------
+$ git branch -r
+ origin/HEAD -> origin/master
+ origin/master
+ staging/master
+ staging/staging-linus
+ staging/staging-next
+-------------------------------------------------
+
+If you run `git fetch <remote>` later, the remote-tracking branches
+for the named `<remote>` will be updated.
+
+If you examine the file `.git/config`, you will see that Git has added
+a new stanza:
+
+-------------------------------------------------
+$ cat .git/config
+...
+[remote "staging"]
+ url = git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
+ fetch = +refs/heads/*:refs/remotes/staging/*
+...
+-------------------------------------------------
+
+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
+linkgit:git-config[1] for details.)
+
+[[exploring-git-history]]
+== 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 hierarchy, 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 that is useful for finding the
+commit that introduced a bug into a project.
+
+[[using-bisect]]
+=== 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
+linkgit: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 in "(no branch)". HEAD is now detached from any
+branch and points directly to a commit (with commit id 65934) that
+is reachable from "master" 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
+linkgit: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.
+
+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". Choose a safe-looking commit nearby, note its commit
+id, and check it out with:
+
+-------------------------------------------------
+$ git reset --hard fb47ddb2db
+-------------------------------------------------
+
+then test, run `bisect good` or `bisect bad` as appropriate, and
+continue.
+
+Instead of `git bisect visualize` and then `git reset --hard
+fb47ddb2db`, you might just want to tell Git that you want to skip
+the current commit:
+
+-------------------------------------------------
+$ git bisect skip
+-------------------------------------------------
+
+In this case, though, Git may not eventually be able to tell the first
+bad one between some first skipped commits and a later bad commit.
+
+There are also ways to automate the bisecting process if you have a
+test script that can tell a good from a bad commit. See
+linkgit:git-bisect[1] for more information about this and other `git
+bisect` features.
+
+[[naming-commits]]
+=== 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
+ <<how-git-stores-references,references>>).
+ - HEAD: refers to the head of the current branch
+
+There are many more; see the "SPECIFYING REVISIONS" section of the
+linkgit:gitrevisions[7] 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 linkgit: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]]
+=== 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 you would also like to include a
+comment with the tag, and possibly sign it cryptographically, then you
+should create a tag object instead; see the linkgit:git-tag[1] man page
+for details.
+
+[[browsing-revisions]]
+=== Browsing revisions
+
+The linkgit: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 linkgit: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 independent lines of development, the particular order that
+commits are listed in may be somewhat arbitrary.
+
+[[generating-diffs]]
+=== Generating diffs
+
+You can generate diffs between any two versions using
+linkgit:git-diff[1]:
+
+-------------------------------------------------
+$ git diff master..test
+-------------------------------------------------
+
+That will produce the diff between the tips of the two branches. If
+you'd prefer to find the diff from their common ancestor to test, you
+can use three dots instead of two:
+
+-------------------------------------------------
+$ git diff master...test
+-------------------------------------------------
+
+Sometimes what you want instead is a set of patches; for this you can
+use linkgit:git-format-patch[1]:
+
+-------------------------------------------------
+$ git format-patch master..test
+-------------------------------------------------
+
+will generate a file with a patch for each commit reachable from test
+but not from master.
+
+[[viewing-old-file-versions]]
+=== 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.
+
+[[history-examples]]
+=== Examples
+
+[[counting-commits-on-a-branch]]
+==== Counting the number of commits on a branch
+
+Suppose you want to know how many commits you've made on `mybranch`
+since it diverged from `origin`:
+
+-------------------------------------------------
+$ git log --pretty=oneline origin..mybranch | wc -l
+-------------------------------------------------
+
+Alternatively, you may often see this sort of thing done with the
+lower-level command linkgit:git-rev-list[1], which just lists the SHA-1's
+of all the given commits:
+
+-------------------------------------------------
+$ git rev-list origin..mybranch | wc -l
+-------------------------------------------------
+
+[[checking-for-equal-branches]]
+==== 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
+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.
+
+[[finding-tagged-descendants]]
+==== 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 linkgit: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 --tags e05db0fd
+e05db0fd tags/v1.5.0-rc1^0~23
+-------------------------------------------------
+
+The linkgit: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-260-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 linkgit: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 linkgit: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, if you 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 a line like
+
+-------------------------------------------------
++ ++ [e05db0fd] Fix warnings in sha1_file.c - use C99 printf format if
+available
+-------------------------------------------------
+
+shows that e05db0fd is reachable from itself, from v1.5.0-rc1,
+and from v1.5.0-rc2, and not from v1.5.0-rc0.
+
+[[showing-commits-unique-to-a-branch]]
+==== Showing commits unique to a given branch
+
+Suppose you would like to see all the commits reachable from the branch
+head named `master` but not from any other head in your repository.
+
+We can list all the heads in this repository with
+linkgit:git-show-ref[1]:
+
+-------------------------------------------------
+$ git show-ref --heads
+bf62196b5e363d73353a9dcf094c59595f3153b7 refs/heads/core-tutorial
+db768d5504c1bb46f63ee9d6e1772bd047e05bf9 refs/heads/maint
+a07157ac624b2524a059a3414e99f6f44bebc1e7 refs/heads/master
+24dbc180ea14dc1aebe09f14c8ecf32010690627 refs/heads/tutorial-2
+1e87486ae06626c2f31eaa63d26fc0fd646c8af2 refs/heads/tutorial-fixes
+-------------------------------------------------
+
+We can get just the branch-head names, and remove `master`, with
+the help of the standard utilities cut and grep:
+
+-------------------------------------------------
+$ git show-ref --heads | cut -d' ' -f2 | grep -v '^refs/heads/master'
+refs/heads/core-tutorial
+refs/heads/maint
+refs/heads/tutorial-2
+refs/heads/tutorial-fixes
+-------------------------------------------------
+
+And then we can ask to see all the commits reachable from master
+but not from these other heads:
+
+-------------------------------------------------
+$ gitk master --not $( git show-ref --heads | cut -d' ' -f2 |
+ grep -v '^refs/heads/master' )
+-------------------------------------------------
+
+Obviously, endless variations are possible; for example, to see all
+commits reachable from some head but not from any tag in the repository:
+
+-------------------------------------------------
+$ gitk $( git show-ref --heads ) --not $( git show-ref --tags )
+-------------------------------------------------
+
+(See linkgit:gitrevisions[7] for explanations of commit-selecting
+syntax such as `--not`.)
+
+[[making-a-release]]
+==== Creating a changelog and tarball for a software release
+
+The linkgit:git-archive[1] command can create a tar or zip archive from
+any version of a project; for example:
+
+-------------------------------------------------
+$ git archive -o latest.tar.gz --prefix=project/ HEAD
+-------------------------------------------------
+
+will use HEAD to produce a gzipped tar archive in which each filename
+is preceded by `project/`. The output file format is inferred from
+the output file extension if possible, see linkgit:git-archive[1] for
+details.
+
+Versions of Git older than 1.7.7 don't know about the `tar.gz` format,
+you'll need to use gzip explicitly:
+
+-------------------------------------------------
+$ git archive --format=tar --prefix=project/ HEAD | gzip >latest.tar.gz
+-------------------------------------------------
+
+If you're releasing a new version of a software project, you may want
+to simultaneously make a changelog to include in the release
+announcement.
+
+Linus Torvalds, for example, makes new kernel releases by tagging them,
+then running:
+
+-------------------------------------------------
+$ release-script 2.6.12 2.6.13-rc6 2.6.13-rc7
+-------------------------------------------------
+
+where release-script is a shell script that looks like:
+
+-------------------------------------------------
+#!/bin/sh
+stable="$1"
+last="$2"
+new="$3"
+echo "# git tag v$new"
+echo "git archive --prefix=linux-$new/ v$new | gzip -9 > ../linux-$new.tar.gz"
+echo "git diff v$stable v$new | gzip -9 > ../patch-$new.gz"
+echo "git log --no-merges v$new ^v$last > ../ChangeLog-$new"
+echo "git shortlog --no-merges v$new ^v$last > ../ShortLog"
+echo "git diff --stat --summary -M v$last v$new > ../diffstat-$new"
+-------------------------------------------------
+
+and then he just cut-and-pastes the output commands after verifying that
+they look OK.
+
+[[Finding-commits-With-given-Content]]
+==== Finding commits referencing a file with given content
+
+Somebody hands you a copy of a file, and asks which commits modified a
+file such that it contained the given content either before or after the
+commit. You can find out with this:
+
+-------------------------------------------------
+$ git log --raw --abbrev=40 --pretty=oneline |
+ grep -B 1 `git hash-object filename`
+-------------------------------------------------
+
+Figuring out why this works is left as an exercise to the (advanced)
+student. The linkgit:git-log[1], linkgit:git-diff-tree[1], and
+linkgit:git-hash-object[1] man pages may prove helpful.
+
+[[Developing-With-git]]
+== Developing with Git
+
+[[telling-git-your-name]]
+=== Telling Git your name
+
+Before creating any commits, you should introduce yourself to Git.
+The easiest way to do so is to use linkgit:git-config[1]:
+
+------------------------------------------------
+$ git config --global user.name 'Your Name Comes Here'
+$ git config --global user.email 'you@yourdomain.example.com'
+------------------------------------------------
+
+Which will add the following to a file named `.gitconfig` in your
+home directory:
+
+------------------------------------------------
+[user]
+ name = Your Name Comes Here
+ email = you@yourdomain.example.com
+------------------------------------------------
+
+See the "CONFIGURATION FILE" section of linkgit:git-config[1] for
+details on the configuration file. The file is plain text, so you can
+also edit it with your favorite editor.
+
+
+[[creating-a-new-repository]]
+=== 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 contents of a new or modified file, use
+
+-------------------------------------------------
+$ git add path/to/file
+-------------------------------------------------
+
+To remove a file from the index and from the working tree, use
+
+-------------------------------------------------
+$ 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
+commit. 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 committed 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 diff HEAD # difference between HEAD and working tree; what
+ # would be committed if you ran "commit -a" now.
+$ git status # a brief per-file summary of the above.
+-------------------------------------------------
+
+You can also use linkgit:git-gui[1] to create commits, view changes in
+the index and the working tree files, and individually select diff hunks
+for inclusion in the index (by right-clicking on the diff hunk and
+choosing "Stage Hunk For Commit").
+
+[[creating-good-commit-messages]]
+=== Creating good commit messages
+
+Though not required, it's a good idea to begin the commit message
+with a single short (no more than 50 characters) line summarizing the
+change, followed by a blank line and then a more thorough
+description. The text up to the first blank line in a commit
+message is treated as the commit title, and that title is used
+throughout Git. For example, linkgit:git-format-patch[1] turns a
+commit into email, and it uses the title on the Subject line and the
+rest of the commit in the body.
+
+
+[[ignoring-files]]
+=== Ignoring files
+
+A project will often generate files that you do 'not' want to track with Git.
+This typically includes files generated by a build process or temporary
+backup files made by your editor. Of course, 'not' tracking files with Git
+is just a matter of 'not' calling `git add` on them. But it quickly becomes
+annoying to have these untracked files lying around; e.g. they make
+`git add .` practically useless, and they keep showing up in the output of
+`git status`.
+
+You can tell Git to ignore certain files by creating a file called
+`.gitignore` in the top level of your working directory, with contents
+such as:
+
+-------------------------------------------------
+# Lines starting with '#' are considered comments.
+# Ignore any file named foo.txt.
+foo.txt
+# Ignore (generated) html files,
+*.html
+# except foo.html which is maintained by hand.
+!foo.html
+# Ignore objects and archives.
+*.[oa]
+-------------------------------------------------
+
+See linkgit:gitignore[5] for a detailed explanation of the syntax. You can
+also place .gitignore files in other directories in your working tree, and they
+will apply to those directories and their subdirectories. The `.gitignore`
+files can be added to your repository like any other files (just run `git add
+.gitignore` and `git commit`, as usual), which is convenient when the exclude
+patterns (such as patterns matching build output files) would also make sense
+for other users who clone your repository.
+
+If you wish the exclude patterns to affect only certain repositories
+(instead of every repository for a given project), you may instead put
+them in a file in your repository named `.git/info/exclude`, or in any
+file specified by the `core.excludesFile` configuration variable.
+Some Git commands can also take exclude patterns directly on the
+command line. See linkgit:gitignore[5] for the details.
+
+[[how-to-merge]]
+=== How to merge
+
+You can rejoin two diverging branches of development using
+linkgit:git-merge[1]:
+
+-------------------------------------------------
+$ git merge branchname
+-------------------------------------------------
+
+merges the development in the branch `branchname` into the current
+branch.
+
+A merge is made by combining the changes made in `branchname` and the
+changes made up to the latest commit in your current branch since
+their histories forked. The work tree is overwritten by the result of
+the merge when this combining is done cleanly, or overwritten by a
+half-merged results when this combining results in conflicts.
+Therefore, if you have uncommitted changes touching the same files as
+the ones impacted by the merge, Git will refuse to proceed. Most of
+the time, you will want to commit your changes before you can merge,
+and if you don't, then linkgit:git-stash[1] can take these changes
+away while you're doing the merge, and reapply them afterwards.
+
+If the changes are independent enough, Git will automatically complete
+the merge and commit the result (or reuse an existing commit in case
+of <<fast-forwards,fast-forward>>, see below). On the other hand,
+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 merge next
+ 100% (4/4) done
+Auto-merged 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.
+
+[[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, linkgit:git-commit[1] will
+fail:
+
+-------------------------------------------------
+$ git commit
+file.txt: needs merge
+-------------------------------------------------
+
+Also, linkgit:git-status[1] will list those files as "unmerged", and the
+files with conflicts will have conflict markers added, like this:
+
+-------------------------------------------------
+<<<<<<< HEAD:file.txt
+Hello world
+=======
+Goodbye
+>>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt
+-------------------------------------------------
+
+All you need to do is edit the files to resolve the conflicts, and then
+
+-------------------------------------------------
+$ 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.
+
+The above is all you need to know to resolve a simple merge. But Git
+also provides more information to help resolve conflicts:
+
+[[conflict-resolution]]
+==== Getting conflict-resolution help during a merge
+
+All of the changes that Git was able to merge automatically are
+already added to the index file, so linkgit:git-diff[1] shows only
+the conflicts. It uses an 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 committed 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.
+
+During the merge, the index holds three versions of each file. Each of
+these three "file stages" represents a different version of the file:
+
+-------------------------------------------------
+$ git show :1:file.txt # the file in a common ancestor of both branches
+$ git show :2:file.txt # the version from HEAD.
+$ git show :3:file.txt # the version from MERGE_HEAD.
+-------------------------------------------------
+
+When you ask linkgit:git-diff[1] to show the conflicts, it runs a
+three-way diff between the conflicted merge results in the work tree with
+stages 2 and 3 to show only hunks whose contents come from both sides,
+mixed (in other words, when a hunk's merge results come only from stage 2,
+that part is not conflicting and is not shown. Same for stage 3).
+
+The diff above shows the differences between the working-tree version of
+file.txt and the stage 2 and stage 3 versions. 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. (See the "COMBINED DIFF FORMAT" section
+of linkgit:git-diff-files[1] for a details of the format.)
+
+After resolving the conflict in the obvious way (but before updating the
+index), 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.
+
+Some special diff options allow diffing the working directory against
+any of these stages:
+
+-------------------------------------------------
+$ git diff -1 file.txt # diff against stage 1
+$ git diff --base file.txt # same as the above
+$ git diff -2 file.txt # diff against stage 2
+$ git diff --ours file.txt # same as the above
+$ git diff -3 file.txt # diff against stage 3
+$ git diff --theirs file.txt # same as the above.
+-------------------------------------------------
+
+When using the 'ort' merge strategy (the default), before updating the working
+tree with the result of the merge, Git writes a ref named AUTO_MERGE
+reflecting the state of the tree it is about to write. Conflicted paths with
+textual conflicts that could not be automatically merged are written to this
+tree with conflict markers, just as in the working tree. AUTO_MERGE can thus be
+used with linkgit:git-diff[1] to show the changes you've made so far to resolve
+conflicts. Using the same example as above, after resolving the conflict we
+get:
+
+-------------------------------------------------
+$ git diff AUTO_MERGE
+diff --git a/file.txt b/file.txt
+index cd10406..8bf5ae7 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1,5 +1 @@
+-<<<<<<< HEAD:file.txt
+-Hello world
+-=======
+-Goodbye
+->>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt
++Goodbye world
+-------------------------------------------------
+
+Notice that the diff shows we deleted the conflict markers and both versions of
+the content line, and wrote "Goodbye world" instead.
+
+The linkgit:git-log[1] and linkgit:gitk[1] commands also provide special help
+for merges:
+
+-------------------------------------------------
+$ git log --merge
+$ gitk --merge
+-------------------------------------------------
+
+These will display all commits which exist only on HEAD or on
+MERGE_HEAD, and which touch an unmerged file.
+
+You may also use linkgit:git-mergetool[1], which lets you merge the
+unmerged files using external tools such as Emacs or kdiff3.
+
+Each time you resolve the conflicts in a file and update the index:
+
+-------------------------------------------------
+$ git add file.txt
+-------------------------------------------------
+
+the different stages of that file will be "collapsed", after which
+`git diff` will (by default) no longer show diffs for that file.
+
+[[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 merge --abort
+-------------------------------------------------
+
+Or, if you've already committed the merge that you want to throw away,
+
+-------------------------------------------------
+$ git reset --hard ORIG_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-forwards]]
+=== 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 the current branch is an ancestor of the other--so every commit
+present in the current branch is already contained in the other branch--then Git
+just performs a "fast-forward"; 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]]
+=== 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 restore --staged --worktree :/
+-------------------------------------------------
+
+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 old 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.
+
+[[reverting-a-commit]]
+==== Fixing a mistake with a new commit
+
+Creating a new commit that reverts an earlier change is very easy;
+just pass the linkgit: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 <<resolving-a-merge,
+resolving a merge>>.
+
+[[fixing-a-mistake-by-rewriting-history]]
+==== Fixing a mistake by rewriting history
+
+If the problematic commit is the most recent commit, and you have not
+yet made that commit public, then you may just
+<<undoing-a-merge,destroy it using `git reset`>>.
+
+Alternatively, you
+can edit the working directory and update the index to fix your
+mistake, just as if you were going to <<how-to-make-a-commit,create a
+new commit>>, 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 linkgit:git-revert[1] instead in
+that case.
+
+It is also possible to replace commits further back in the history, but
+this is an advanced topic to be left for
+<<cleaning-up-history,another chapter>>.
+
+[[checkout-of-path]]
+==== 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
+linkgit:git-restore[1]. The command
+
+-------------------------------------------------
+$ git restore --source=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
+linkgit:git-show[1]:
+
+-------------------------------------------------
+$ git show HEAD^:path/to/file
+-------------------------------------------------
+
+which will display the given version of the file.
+
+[[interrupted-work]]
+==== Temporarily setting aside work in progress
+
+While you are in the middle of working on something complicated, you
+find an unrelated but obvious and trivial bug. You would like to fix it
+before continuing. You can use linkgit:git-stash[1] to save the current
+state of your work, and after fixing the bug (or, optionally after doing
+so on a different branch and then coming back), unstash the
+work-in-progress changes.
+
+------------------------------------------------
+$ git stash push -m "work in progress for foo feature"
+------------------------------------------------
+
+This command will save your changes away to the `stash`, and
+reset your working tree and the index to match the tip of your
+current branch. Then you can make your fix as usual.
+
+------------------------------------------------
+... edit and test ...
+$ git commit -a -m "blorpl: typofix"
+------------------------------------------------
+
+After that, you can go back to what you were working on with
+`git stash pop`:
+
+------------------------------------------------
+$ git stash pop
+------------------------------------------------
+
+
+[[ensuring-good-performance]]
+=== Ensuring good performance
+
+On large repositories, Git depends on compression to keep the history
+information from taking up too much space on disk or in memory. Some
+Git commands may automatically run linkgit:git-gc[1], so you don't
+have to worry about running it manually. However, compressing a large
+repository may take a while, so you may want to call `gc` explicitly
+to avoid automatic compression kicking in when it is not convenient.
+
+
+[[ensuring-reliability]]
+=== Ensuring reliability
+
+[[checking-for-corruption]]
+==== Checking the repository for corruption
+
+The linkgit:git-fsck[1] command runs a number of self-consistency checks
+on the repository, and reports on any problems. This may take some
+time.
+
+-------------------------------------------------
+$ 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
+...
+-------------------------------------------------
+
+You will see informational messages on dangling objects. They are objects
+that still exist in the repository but are no longer referenced by any of
+your branches, and can (and will) be removed after a while with `gc`.
+You can run `git fsck --no-dangling` to suppress these messages, and still
+view real errors.
+
+[[recovering-lost-changes]]
+==== Recovering lost changes
+
+[[reflogs]]
+===== Reflogs
+
+Say you modify a branch with <<fixing-mistakes,`git reset --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
+`master` branch head. This syntax can be used 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
+$ git log --walk-reflogs master # show reflog entries for master
+-------------------------------------------------
+
+A separate reflog is kept for the HEAD, so
+
+-------------------------------------------------
+$ git show HEAD@{"1 week ago"}
+-------------------------------------------------
+
+will show what HEAD pointed to one week ago, not what the current branch
+pointed to one week ago. This allows you to see the history of what
+you've checked out.
+
+The reflogs are kept by default for 30 days, after which they may be
+pruned. See linkgit:git-reflog[1] and linkgit:git-gc[1] to learn
+how to control this pruning, and see the "SPECIFYING REVISIONS"
+section of linkgit:gitrevisions[7] 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.
+
+[[dangling-object-recovery]]
+===== 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
+contained. 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 in the dangling objects that `git fsck` reports. See
+<<dangling-objects>> for the details.
+
+-------------------------------------------------
+$ git fsck
+dangling commit 7281251ddd2a61e38657c827739c57015671a6b3
+dangling commit 2706a059f258c6b245f298dc4ff2ccd30ec21a63
+dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5
+...
+-------------------------------------------------
+
+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 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
+------------------------------------------------
+
+Other types of dangling objects (blobs and trees) are also possible, and
+dangling objects can arise in other situations.
+
+
+[[sharing-development]]
+== Sharing development with others
+
+[[getting-updates-With-git-pull]]
+=== Getting updates with git pull
+
+After you clone a repository and commit 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 <<Updating-a-repository-With-git-fetch,how to
+keep remote-tracking branches up to date>> with linkgit: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 linkgit:git-pull[1] command provides a way to do this in
+one step:
+
+-------------------------------------------------
+$ git pull origin master
+-------------------------------------------------
+
+In fact, if you have `master` checked out, then this branch has been
+configured by `git clone` to get changes from the HEAD branch of the
+origin repository. So often you can
+accomplish the above with just a simple
+
+-------------------------------------------------
+$ git pull
+-------------------------------------------------
+
+This command will fetch changes from the remote branches to your
+remote-tracking branches `origin/*`, and merge the default branch into
+the current branch.
+
+More generally, a branch that is created from a remote-tracking branch
+will pull
+by default from that branch. See the descriptions of the
+`branch.<name>.remote` and `branch.<name>.merge` options in
+linkgit:git-config[1], and the discussion of the `--track` option in
+linkgit:git-checkout[1], to learn how to control these defaults.
+
+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
+<<fast-forwards,fast-forward>>; 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.
+
+[[submitting-patches]]
+=== 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 linkgit: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`.
+
+`git format-patch` can include an initial "cover letter". You can insert
+commentary on individual patches after the three dash line which
+`format-patch` places after the commit message but before the patch
+itself. If you use `git notes` to track your cover letter material,
+`git format-patch --notes` will include the commit's notes in a similar
+manner.
+
+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 linkgit:git-send-email[1] script to automate the process.
+Consult the mailing list for your project first to determine
+their requirements for submitting patches.
+
+[[importing-patches]]
+=== Importing patches to a project
+
+Git also provides a tool called linkgit: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
+"<<resolving-a-merge,Resolving a merge>>". (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 --continue
+-------------------------------------------------
+
+and Git will create the commit for you and continue applying the
+remaining patches from the mailbox.
+
+The final result will be a series of commits, one for each patch in
+the original mailbox, with authorship and commit log message each
+taken from the message containing each patch.
+
+[[public-repositories]]
+=== Public Git repositories
+
+Another way to submit changes to a project is to tell the maintainer
+of that project to pull the changes from your repository using
+linkgit:git-pull[1]. In the section "<<getting-updates-With-git-pull,
+Getting updates with `git pull`>>" we described this as a way to get
+updates from the "main" repository, but it works just as well in the
+other direction.
+
+If you and the maintainer both have accounts on the same machine, then
+you can just pull changes from each other's repositories directly;
+commands that accept repository URLs as arguments will also accept a
+local directory name:
+
+-------------------------------------------------
+$ git clone /path/to/repository
+$ git pull /path/to/other/repository
+-------------------------------------------------
+
+or an ssh URL:
+
+-------------------------------------------------
+$ git clone ssh://yourhost/~you/repository
+-------------------------------------------------
+
+For projects with few developers, or for synchronizing a few private
+repositories, this may be all you need.
+
+However, the more common way to do this is to maintain a separate public
+repository (usually on a different host) for others to pull changes
+from. This is usually more convenient, and 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
+....
+
+We explain how to do this in the following sections.
+
+[[setting-up-a-public-repository]]
+==== Setting up a public repository
+
+Assume your personal repository is in the directory `~/proj`. We
+first create a new clone of the repository and tell `git daemon` that it
+is meant to be public:
+
+-------------------------------------------------
+$ git clone --bare ~/proj proj.git
+$ touch proj.git/git-daemon-export-ok
+-------------------------------------------------
+
+The resulting directory proj.git contains a "bare" git repository--it is
+just the contents of the `.git` directory, without any files checked out
+around it.
+
+Next, copy `proj.git` to the server where you plan to host the
+public repository. You can use scp, rsync, or whatever is most
+convenient.
+
+[[exporting-via-git]]
+==== Exporting a Git repository via the Git protocol
+
+This is the preferred method.
+
+If someone else administers the server, they should tell you what
+directory to put the repository in, and what `git://` URL it will
+appear at. You can then skip to the section
+"<<pushing-changes-to-a-public-repository,Pushing changes to a public
+repository>>", below.
+
+Otherwise, all you need to do is start linkgit:git-daemon[1]; it will
+listen on port 9418. By default, it will allow access to any directory
+that looks like a Git directory and contains the magic file
+git-daemon-export-ok. Passing some directory paths as `git daemon`
+arguments will further restrict the exports to those paths.
+
+You can also run `git daemon` as an inetd service; see the
+linkgit:git-daemon[1] man page for details. (See especially the
+examples section.)
+
+[[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 --bare update-server-info
+$ mv hooks/post-update.sample hooks/post-update
+-------------------------------------------------
+
+(For an explanation of the last two lines, see
+linkgit:git-update-server-info[1] and linkgit:githooks[5].)
+
+Advertise the URL of `proj.git`. Anybody else should then be able to
+clone or pull from that URL, for example with a command line like:
+
+-------------------------------------------------
+$ git clone http://yourserver.com/~you/proj.git
+-------------------------------------------------
+
+(See also
+link:howto/setup-git-server-over-http.html[setup-git-server-over-http]
+for a slightly more sophisticated setup using WebDAV which also
+allows pushing over HTTP.)
+
+[[pushing-changes-to-a-public-repository]]
+==== Pushing changes to a public repository
+
+Note that the two techniques outlined above (exporting via
+<<exporting-via-http,http>> or <<exporting-via-git,git>>) 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 linkgit: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
+<<fast-forwards,fast-forward>>; see the following section for details on
+handling this case.
+
+Note that the target of a `push` is normally a
+<<def_bare_repository,bare>> repository. You can also push to a
+repository that has a checked-out working tree, but a push to update the
+currently checked-out branch is denied by default to prevent confusion.
+See the description of the receive.denyCurrentBranch option
+in linkgit:git-config[1] for details.
+
+As with `git fetch`, you may also set up configuration options to
+save typing; so, for example:
+
+-------------------------------------------------
+$ git remote add public-repo ssh://yourserver.com/~you/proj.git
+-------------------------------------------------
+
+adds the following to `.git/config`:
+
+-------------------------------------------------
+[remote "public-repo"]
+ url = yourserver.com:proj.git
+ fetch = +refs/heads/*:refs/remotes/example/*
+-------------------------------------------------
+
+which lets you do the same push with just
+
+-------------------------------------------------
+$ git push public-repo master
+-------------------------------------------------
+
+See the explanations of the `remote.<name>.url`,
+`branch.<name>.remote`, and `remote.<name>.push` options in
+linkgit:git-config[1] for details.
+
+[[forcing-push]]
+==== What to do when a push fails
+
+If a push would not result in a <<fast-forwards,fast-forward>> of the
+remote branch, then it will fail with an error like:
+
+-------------------------------------------------
+ ! [rejected] master -> master (non-fast-forward)
+error: failed to push some refs to '...'
+hint: Updates were rejected because the tip of your current branch is behind
+hint: its remote counterpart. Integrate the remote changes (e.g.
+hint: 'git pull ...') before pushing again.
+hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+-------------------------------------------------
+
+This can happen, for example, if you:
+
+ - use `git reset --hard` to remove already-published commits, or
+ - use `git commit --amend` to replace already-published commits
+ (as in <<fixing-a-mistake-by-rewriting-history>>), or
+ - use `git rebase` to rebase any already-published commits (as
+ in <<using-git-rebase>>).
+
+You may force `git push` to perform the update anyway by preceding the
+branch name with a plus sign:
+
+-------------------------------------------------
+$ git push ssh://yourserver.com/~you/proj.git +master
+-------------------------------------------------
+
+Note the addition of the `+` sign. Alternatively, you can use the
+`-f` flag to force the remote update, as in:
+
+-------------------------------------------------
+$ git push -f ssh://yourserver.com/~you/proj.git master
+-------------------------------------------------
+
+Normally whenever a branch head in a public repository is modified, it
+is modified to point to a descendant of the commit that it pointed to
+before. By forcing a push in this situation, you break that convention.
+(See <<problems-With-rewriting-history>>.)
+
+Nevertheless, this is a common practice for people that need a simple
+way to publish a work-in-progress patch series, and it is an acceptable
+compromise as long as you warn other developers that this is how you
+intend to manage the branch.
+
+It's also possible for a push to fail in this way when other people have
+the right to push to the same repository. In that case, the correct
+solution is to retry the push after first updating your work: either by a
+pull, or by a fetch followed by a rebase; see the
+<<setting-up-a-shared-repository,next section>> and
+linkgit:gitcvs-migration[7] for more.
+
+[[setting-up-a-shared-repository]]
+==== 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
+linkgit:gitcvs-migration[7] for instructions on how to
+set this up.
+
+However, while there is nothing wrong with Git's support for shared
+repositories, this mode of operation is not generally recommended,
+simply because the mode of collaboration that Git supports--by
+exchanging patches and pulling from public repositories--has so many
+advantages over the central shared repository:
+
+ - Git's ability to quickly import and merge patches allows a
+ single maintainer to process incoming changes even at very
+ high rates. And when that becomes too much, `git pull` provides
+ an easy way for that maintainer to delegate this job to other
+ maintainers while still allowing optional review of incoming
+ changes.
+ - Since every developer's repository has the same complete copy
+ of the project history, no repository is special, and it is
+ trivial for another developer to take over maintenance of a
+ project, either by mutual agreement, or because a maintainer
+ becomes unresponsive or difficult to work with.
+ - The lack of a central group of "committers" means there is
+ less need for formal decisions about who is "in" and who is
+ "out".
+
+[[setting-up-gitweb]]
+==== Allowing web browsing of a repository
+
+The gitweb cgi script provides users an easy way to browse your
+project's revisions, file contents and logs without having to install
+Git. Features like RSS/Atom feeds and blame/annotation details may
+optionally be enabled.
+
+The linkgit:git-instaweb[1] command provides a simple way to start
+browsing the repository using gitweb. The default server when using
+instaweb is lighttpd.
+
+See the file gitweb/INSTALL in the Git source tree and
+linkgit:gitweb[1] for instructions on details setting up a permanent
+installation with a CGI or Perl capable server.
+
+[[how-to-get-a-git-repository-with-minimal-history]]
+=== How to get a Git repository with minimal history
+
+A <<def_shallow_clone,shallow clone>>, with its truncated
+history, is useful when one is interested only in recent history
+of a project and getting full history from the upstream is
+expensive.
+
+A <<def_shallow_clone,shallow clone>> is created by specifying
+the linkgit:git-clone[1] `--depth` switch. The depth can later be
+changed with the linkgit:git-fetch[1] `--depth` switch, or full
+history restored with `--unshallow`.
+
+Merging inside a <<def_shallow_clone,shallow clone>> will work as long
+as a merge base is in the recent history.
+Otherwise, it will be like merging unrelated histories and may
+have to result in huge conflicts. This limitation may make such
+a repository unsuitable to be used in merge based workflows.
+
+[[sharing-development-examples]]
+=== Examples
+
+[[maintaining-topic-branches]]
+==== Maintaining topic branches for a Linux subsystem maintainer
+
+This describes how Tony Luck uses Git in his role as maintainer of the
+IA64 architecture for the Linux kernel.
+
+He uses two public branches:
+
+ - A "test" tree into which patches are initially placed so that they
+ can get some exposure when integrated with other ongoing development.
+ This tree is available to Andrew for pulling into -mm whenever he
+ wants.
+
+ - A "release" tree into which tested patches are moved for final sanity
+ checking, and as a vehicle to send them upstream to Linus (by sending
+ him a "please pull" request.)
+
+He also uses a set of temporary branches ("topic branches"), each
+containing a logical grouping of patches.
+
+To set this up, first create your work tree by cloning Linus's public
+tree:
+
+-------------------------------------------------
+$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git work
+$ cd work
+-------------------------------------------------
+
+Linus's tree will be stored in the remote-tracking branch named origin/master,
+and can be updated using linkgit:git-fetch[1]; you can track other
+public trees using linkgit:git-remote[1] to set up a "remote" and
+linkgit:git-fetch[1] to keep them up to date; see
+<<repositories-and-branches>>.
+
+Now create the branches in which you are going to work; these start out
+at the current tip of origin/master branch, and should be set up (using
+the `--track` option to linkgit:git-branch[1]) to merge changes in from
+Linus by default.
+
+-------------------------------------------------
+$ git branch --track test origin/master
+$ git branch --track release origin/master
+-------------------------------------------------
+
+These can be easily kept up to date using linkgit:git-pull[1].
+
+-------------------------------------------------
+$ git switch test && git pull
+$ git switch release && git pull
+-------------------------------------------------
+
+Important note! If you have any local changes in these branches, then
+this merge will create a commit object in the history (with no local
+changes Git will simply do a "fast-forward" merge). Many people dislike
+the "noise" that this creates in the Linux history, so you should avoid
+doing this capriciously in the `release` branch, as these noisy commits
+will become part of the permanent history when you ask Linus to pull
+from the release branch.
+
+A few configuration variables (see linkgit:git-config[1]) can
+make it easy to push both branches to your public tree. (See
+<<setting-up-a-public-repository>>.)
+
+-------------------------------------------------
+$ cat >> .git/config <<EOF
+[remote "mytree"]
+ url = master.kernel.org:/pub/scm/linux/kernel/git/aegl/linux.git
+ push = release
+ push = test
+EOF
+-------------------------------------------------
+
+Then you can push both the test and release trees using
+linkgit:git-push[1]:
+
+-------------------------------------------------
+$ git push mytree
+-------------------------------------------------
+
+or push just one of the test and release branches using:
+
+-------------------------------------------------
+$ git push mytree test
+-------------------------------------------------
+
+or
+
+-------------------------------------------------
+$ git push mytree release
+-------------------------------------------------
+
+Now to apply some patches from the community. Think of a short
+snappy name for a branch to hold this patch (or related group of
+patches), and create a new branch from a recent stable tag of
+Linus's branch. Picking a stable base for your branch will:
+1) help you: by avoiding inclusion of unrelated and perhaps lightly
+tested changes
+2) help future bug hunters that use `git bisect` to find problems
+
+-------------------------------------------------
+$ git switch -c speed-up-spinlocks v2.6.35
+-------------------------------------------------
+
+Now you apply the patch(es), run some tests, and commit the change(s). If
+the patch is a multi-part series, then you should apply each as a separate
+commit to this branch.
+
+-------------------------------------------------
+$ ... patch ... test ... commit [ ... patch ... test ... commit ]*
+-------------------------------------------------
+
+When you are happy with the state of this change, you can merge it into the
+"test" branch in preparation to make it public:
+
+-------------------------------------------------
+$ git switch test && git merge speed-up-spinlocks
+-------------------------------------------------
+
+It is unlikely that you would have any conflicts here ... but you might if you
+spent a while on this step and had also pulled new versions from upstream.
+
+Sometime later when enough time has passed and testing done, you can pull the
+same branch into the `release` tree ready to go upstream. This is where you
+see the value of keeping each patch (or patch series) in its own branch. It
+means that the patches can be moved into the `release` tree in any order.
+
+-------------------------------------------------
+$ git switch release && git merge speed-up-spinlocks
+-------------------------------------------------
+
+After a while, you will have a number of branches, and despite the
+well chosen names you picked for each of them, you may forget what
+they are for, or what status they are in. To get a reminder of what
+changes are in a specific branch, use:
+
+-------------------------------------------------
+$ git log linux..branchname | git shortlog
+-------------------------------------------------
+
+To see whether it has already been merged into the test or release branches,
+use:
+
+-------------------------------------------------
+$ git log test..branchname
+-------------------------------------------------
+
+or
+
+-------------------------------------------------
+$ git log release..branchname
+-------------------------------------------------
+
+(If this branch has not yet been merged, you will see some log entries.
+If it has been merged, then there will be no output.)
+
+Once a patch completes the great cycle (moving from test to release,
+then pulled by Linus, and finally coming back into your local
+`origin/master` branch), the branch for this change is no longer needed.
+You detect this when the output from:
+
+-------------------------------------------------
+$ git log origin..branchname
+-------------------------------------------------
+
+is empty. At this point the branch can be deleted:
+
+-------------------------------------------------
+$ git branch -d branchname
+-------------------------------------------------
+
+Some changes are so trivial that it is not necessary to create a separate
+branch and then merge into each of the test and release branches. For
+these changes, just apply directly to the `release` branch, and then
+merge that into the `test` branch.
+
+After pushing your work to `mytree`, you can use
+linkgit:git-request-pull[1] to prepare a "please pull" request message
+to send to Linus:
+
+-------------------------------------------------
+$ git push mytree
+$ git request-pull origin mytree release
+-------------------------------------------------
+
+Here are some of the scripts that simplify all this even further.
+
+-------------------------------------------------
+==== update script ====
+# Update a branch in my Git tree. If the branch to be updated
+# is origin, then pull from kernel.org. Otherwise merge
+# origin/master branch into test|release branch
+
+case "$1" in
+test|release)
+ git checkout $1 && git pull . origin
+ ;;
+origin)
+ before=$(git rev-parse refs/remotes/origin/master)
+ git fetch origin
+ after=$(git rev-parse refs/remotes/origin/master)
+ if [ $before != $after ]
+ then
+ git log $before..$after | git shortlog
+ fi
+ ;;
+*)
+ echo "usage: $0 origin|test|release" 1>&2
+ exit 1
+ ;;
+esac
+-------------------------------------------------
+
+-------------------------------------------------
+==== merge script ====
+# Merge a branch into either the test or release branch
+
+pname=$0
+
+usage()
+{
+ echo "usage: $pname branch test|release" 1>&2
+ exit 1
+}
+
+git show-ref -q --verify -- refs/heads/"$1" || {
+ echo "Can't see branch <$1>" 1>&2
+ usage
+}
+
+case "$2" in
+test|release)
+ if [ $(git log $2..$1 | wc -c) -eq 0 ]
+ then
+ echo $1 already merged into $2 1>&2
+ exit 1
+ fi
+ git checkout $2 && git pull . $1
+ ;;
+*)
+ usage
+ ;;
+esac
+-------------------------------------------------
+
+-------------------------------------------------
+==== status script ====
+# report on status of my ia64 Git tree
+
+gb=$(tput setab 2)
+rb=$(tput setab 1)
+restore=$(tput setab 9)
+
+if [ `git rev-list test..release | wc -c` -gt 0 ]
+then
+ echo $rb Warning: commits in release that are not in test $restore
+ git log test..release
+fi
+
+for branch in `git show-ref --heads | sed 's|^.*/||'`
+do
+ if [ $branch = test -o $branch = release ]
+ then
+ continue
+ fi
+
+ echo -n $gb ======= $branch ====== $restore " "
+ status=
+ for ref in test release origin/master
+ do
+ if [ `git rev-list $ref..$branch | wc -c` -gt 0 ]
+ then
+ status=$status${ref:0:1}
+ fi
+ done
+ case $status in
+ trl)
+ echo $rb Need to pull into test $restore
+ ;;
+ rl)
+ echo "In test"
+ ;;
+ l)
+ echo "Waiting for linus"
+ ;;
+ "")
+ echo $rb All done $restore
+ ;;
+ *)
+ echo $rb "<$status>" $restore
+ ;;
+ esac
+ git log origin/master..$branch | git shortlog
+done
+-------------------------------------------------
+
+
+[[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.
+
+[[patch-series]]
+=== 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 that 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.
+
+[[using-git-rebase]]
+=== Keeping a patch series up to date using git rebase
+
+Suppose that you create a branch `mywork` on a remote-tracking branch
+`origin`, and create some commits on top of it:
+
+-------------------------------------------------
+$ git switch -c 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
+ \
+ a--b--c <-- 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
+linkgit:git-rebase[1]:
+
+-------------------------------------------------
+$ git switch mywork
+$ git rebase origin
+-------------------------------------------------
+
+This will remove each of your commits from mywork, temporarily saving
+them as patches (in a directory named `.git/rebase-apply`), 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
+-------------------------------------------------
+
+If you need to reorder or edit a number of commits in a branch, it may
+be easier to use `git rebase -i`, which allows you to reorder and
+squash commits, as well as marking them for individual editing during
+the rebase. See <<interactive-rebase>> for details, and
+<<reordering-patch-series>> for alternatives.
+
+[[rewriting-one-commit]]
+=== Rewriting a single commit
+
+We saw in <<fixing-a-mistake-by-rewriting-history>> that you can replace the
+most recent commit using
+
+-------------------------------------------------
+$ 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.
+This is useful for fixing typos in your last commit, or for adjusting
+the patch contents of a poorly staged commit.
+
+If you need to amend commits from deeper in your history, you can
+use <<interactive-rebase,interactive rebase's `edit` instruction>>.
+
+[[reordering-patch-series]]
+=== Reordering or selecting from a patch series
+
+Sometimes you want to edit a commit deeper in your history. One
+approach is to use `git format-patch` to create a series of patches
+and then reset the state to before the patches:
+
+-------------------------------------------------
+$ git format-patch origin
+$ git reset --hard origin
+-------------------------------------------------
+
+Then modify, reorder, or eliminate patches as needed before applying
+them again with linkgit:git-am[1]:
+
+-------------------------------------------------
+$ git am *.patch
+-------------------------------------------------
+
+[[interactive-rebase]]
+=== Using interactive rebases
+
+You can also edit a patch series with an interactive rebase. This is
+the same as <<reordering-patch-series,reordering a patch series using
+`format-patch`>>, so use whichever interface you like best.
+
+Rebase your current HEAD on the last commit you want to retain as-is.
+For example, if you want to reorder the last 5 commits, use:
+
+-------------------------------------------------
+$ git rebase -i HEAD~5
+-------------------------------------------------
+
+This will open your editor with a list of steps to be taken to perform
+your rebase.
+
+-------------------------------------------------
+pick deadbee The oneline of this commit
+pick fa1afe1 The oneline of the next commit
+...
+
+# Rebase c0ffeee..deadbee onto c0ffeee
+#
+# Commands:
+# p, pick = use commit
+# r, reword = use commit, but edit the commit message
+# e, edit = use commit, but stop for amending
+# s, squash = use commit, but meld into previous commit
+# f, fixup = like "squash", but discard this commit's log message
+# x, exec = run command (the rest of the line) using shell
+#
+# These lines can be re-ordered; they are executed from top to bottom.
+#
+# If you remove a line here THAT COMMIT WILL BE LOST.
+#
+# However, if you remove everything, the rebase will be aborted.
+#
+# Note that empty commits are commented out
+-------------------------------------------------
+
+As explained in the comments, you can reorder commits, squash them
+together, edit commit messages, etc. by editing the list. Once you
+are satisfied, save the list and close your editor, and the rebase
+will begin.
+
+The rebase will stop where `pick` has been replaced with `edit` or
+when a step in the list fails to mechanically resolve conflicts and
+needs your help. When you are done editing and/or resolving conflicts
+you can continue with `git rebase --continue`. If you decide that
+things are getting too hairy, you can always bail out with `git rebase
+--abort`. Even after the rebase is complete, you can still recover
+the original branch by using the <<reflogs,reflog>>.
+
+For a more detailed discussion of the procedure and additional tips,
+see the "INTERACTIVE MODE" section of linkgit:git-rebase[1].
+
+[[patch-series-tools]]
+=== Other tools
+
+There are numerous other tools, such as StGit, which exist for the
+purpose of maintaining a patch series. These are outside of the scope of
+this manual.
+
+[[problems-With-rewriting-history]]
+=== 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.
+
+[[bisect-merges]]
+=== Why bisecting merge commits can be harder than bisecting linear history
+
+The linkgit:git-bisect[1] command correctly handles history that
+includes merge commits. However, when the commit that it finds is a
+merge commit, the user may need to work harder than usual to figure out
+why that commit introduced a problem.
+
+Imagine this history:
+
+................................................
+ ---Z---o---X---...---o---A---C---D
+ \ /
+ o---o---Y---...---o---B
+................................................
+
+Suppose that on the upper line of development, the meaning of one
+of the functions that exists at Z is changed at commit X. The
+commits from Z leading to A change both the function's
+implementation and all calling sites that exist at Z, as well
+as new calling sites they add, to be consistent. There is no
+bug at A.
+
+Suppose that in the meantime on the lower line of development somebody
+adds a new calling site for that function at commit Y. The
+commits from Z leading to B all assume the old semantics of that
+function and the callers and the callee are consistent with each
+other. There is no bug at B, either.
+
+Suppose further that the two development lines merge cleanly at C,
+so no conflict resolution is required.
+
+Nevertheless, the code at C is broken, because the callers added
+on the lower line of development have not been converted to the new
+semantics introduced on the upper line of development. So if all
+you know is that D is bad, that Z is good, and that
+linkgit:git-bisect[1] identifies C as the culprit, how will you
+figure out that the problem is due to this change in semantics?
+
+When the result of a `git bisect` is a non-merge commit, you should
+normally be able to discover the problem by examining just that commit.
+Developers can make this easy by breaking their changes into small
+self-contained commits. That won't help in the case above, however,
+because the problem isn't obvious from examination of any single
+commit; instead, a global view of the development is required. To
+make matters worse, the change in semantics in the problematic
+function may be just one small part of the changes in the upper
+line of development.
+
+On the other hand, if instead of merging at C you had rebased the
+history between Z to B on top of A, you would have gotten this
+linear history:
+
+................................................................
+ ---Z---o---X--...---o---A---o---o---Y*--...---o---B*--D*
+................................................................
+
+Bisecting between Z and D* would hit a single culprit commit Y*,
+and understanding why Y* was broken would probably be easier.
+
+Partly for this reason, many experienced Git users, even when
+working on an otherwise merge-heavy project, keep the history
+linear by rebasing against the latest upstream version before
+publishing.
+
+[[advanced-branch-management]]
+== Advanced branch management
+
+[[fetching-individual-branches]]
+=== Fetching individual branches
+
+Instead of using linkgit: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-forwards,fast-forward>> to the commit given by example.com's
+master branch. In more detail:
+
+[[fetch-fast-forwards]]
+=== git fetch and 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-forwards,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 a serious mistake was made 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-fetch]]
+=== 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. Alternatively, you can use the `-f`
+flag to force updates of all the fetched branches, as in:
+
+-------------------------------------------------
+$ git fetch -f origin
+-------------------------------------------------
+
+Be aware that commits that the old version of example/master pointed at
+may be lost, as we saw in the previous section.
+
+[[remote-branch-configuration]]
+=== Configuring remote-tracking branches
+
+We saw above that `origin` is just a shortcut to refer to the
+repository that you originally cloned from. This information is
+stored in Git configuration variables, which you can see using
+linkgit: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,
+
+-------------------------------------------------
+$ git remote add example git://example.com/proj.git
+-------------------------------------------------
+
+adds the following to `.git/config`:
+
+-------------------------------------------------
+[remote "example"]
+ url = git://example.com/proj.git
+ fetch = +refs/heads/*:refs/remotes/example/*
+-------------------------------------------------
+
+Also note that the above configuration can be performed by directly
+editing the file `.git/config` instead of using linkgit:git-remote[1].
+
+After configuring the remote, the following three commands will do the
+same thing:
+
+-------------------------------------------------
+$ git fetch git://example.com/proj.git +refs/heads/*:refs/remotes/example/*
+$ git fetch example +refs/heads/*:refs/remotes/example/*
+$ git fetch example
+-------------------------------------------------
+
+See linkgit:git-config[1] for more details on the configuration
+options mentioned above and linkgit:git-fetch[1] for more details on
+the refspec syntax.
+
+
+[[git-concepts]]
+== Git concepts
+
+Git is built on a small number of simple but powerful ideas. While it
+is possible to get things done without understanding them, you will find
+Git much more intuitive if you do.
+
+We start with the most important, the <<def_object_database,object
+database>> and the <<def_index,index>>.
+
+[[the-object-database]]
+=== The Object Database
+
+
+We already saw in <<understanding-commits>> that all commits are stored
+under a 40-digit "object name". In fact, all the information needed to
+represent the history of a project is stored in objects with such names.
+In each case the name is calculated by taking the SHA-1 hash of the
+contents of the object. The SHA-1 hash is a cryptographic hash function.
+What that means to us is that it is impossible to find two different
+objects with the same name. This has a number of advantages; among
+others:
+
+- Git can quickly determine whether two objects are identical or not,
+ just by comparing names.
+- Since object names are computed the same way in every repository, the
+ same content stored in two repositories will always be stored under
+ the same name.
+- Git can detect errors when it reads an object, by checking that the
+ object's name is still the SHA-1 hash of its contents.
+
+(See <<object-details>> for the details of the object formatting and
+SHA-1 calculation.)
+
+There are four different types of objects: "blob", "tree", "commit", and
+"tag".
+
+- A <<def_blob_object,"blob" object>> is used to store file data.
+- A <<def_tree_object,"tree" object>> ties one or more
+ "blob" objects into a directory structure. In addition, a tree object
+ can refer to other tree objects, thus creating a directory hierarchy.
+- A <<def_commit_object,"commit" object>> ties such directory hierarchies
+ together into a <<def_DAG,directed acyclic graph>> of revisions--each
+ commit contains the object name of exactly one tree designating the
+ directory hierarchy at the time of the commit. In addition, a commit
+ refers to "parent" commit objects that describe the history of how we
+ arrived at that directory hierarchy.
+- A <<def_tag_object,"tag" object>> symbolically identifies and can be
+ used to sign other objects. It contains the object name and type of
+ another object, a symbolic name (of course!) and, optionally, a
+ signature.
+
+The object types in some more detail:
+
+[[commit-object]]
+==== Commit Object
+
+The "commit" object links a physical state of a tree with a description
+of how we got there and why. Use the `--pretty=raw` option to
+linkgit:git-show[1] or linkgit:git-log[1] to examine your favorite
+commit:
+
+------------------------------------------------
+$ git show -s --pretty=raw 2be7fcb476
+commit 2be7fcb4764f2dbcee52635b91fedb1b3dcf7ab4
+tree fb3a8bdd0ceddd019615af4d57a53f43d8cee2bf
+parent 257a84d9d02e90447b149af58b271c19405edb6a
+author Dave Watson <dwatson@mimvista.com> 1187576872 -0400
+committer Junio C Hamano <gitster@pobox.com> 1187591163 -0700
+
+ Fix misspelling of 'suppress' in docs
+
+ Signed-off-by: Junio C Hamano <gitster@pobox.com>
+------------------------------------------------
+
+As you can see, a commit is defined by:
+
+- a tree: The SHA-1 name of a tree object (as defined below), representing
+ the contents of a directory at a certain point in time.
+- parent(s): The SHA-1 name(s) of some number of commits which represent the
+ immediately previous step(s) in the history of the project. The
+ example above has one parent; merge commits may have more than
+ one. A commit with no parents is called a "root" commit, and
+ represents the initial revision of a project. Each project must have
+ at least one root. A project can also have multiple roots, though
+ that isn't common (or necessarily a good idea).
+- an author: The name of the person responsible for this change, together
+ with its date.
+- a committer: The name of the person who actually created the commit,
+ with the date it was done. This may be different from the author, for
+ example, if the author was someone who wrote a patch and emailed it
+ to the person who used it to create the commit.
+- a comment describing this commit.
+
+Note that a commit does not itself contain any information about what
+actually changed; all changes are calculated by comparing the contents
+of the tree referred to by this commit with the trees associated with
+its parents. In particular, Git does not attempt to record file renames
+explicitly, though it can identify cases where the existence of the same
+file data at changing paths suggests a rename. (See, for example, the
+`-M` option to linkgit:git-diff[1]).
+
+A commit is usually created by linkgit:git-commit[1], which creates a
+commit whose parent is normally the current HEAD, and whose tree is
+taken from the content currently stored in the index.
+
+[[tree-object]]
+==== Tree Object
+
+The ever-versatile linkgit:git-show[1] command can also be used to
+examine tree objects, but linkgit:git-ls-tree[1] will give you more
+details:
+
+------------------------------------------------
+$ git ls-tree fb3a8bdd0ce
+100644 blob 63c918c667fa005ff12ad89437f2fdc80926e21c .gitignore
+100644 blob 5529b198e8d14decbe4ad99db3f7fb632de0439d .mailmap
+100644 blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3 COPYING
+040000 tree 2fb783e477100ce076f6bf57e4a6f026013dc745 Documentation
+100755 blob 3c0032cec592a765692234f1cba47dfdcc3a9200 GIT-VERSION-GEN
+100644 blob 289b046a443c0647624607d471289b2c7dcd470b INSTALL
+100644 blob 4eb463797adc693dc168b926b6932ff53f17d0b1 Makefile
+100644 blob 548142c327a6790ff8821d67c2ee1eff7a656b52 README
+...
+------------------------------------------------
+
+As you can see, a tree object contains a list of entries, each with a
+mode, object type, SHA-1 name, and name, sorted by name. It represents
+the contents of a single directory tree.
+
+The object type may be a blob, representing the contents of a file, or
+another tree, representing the contents of a subdirectory. Since trees
+and blobs, like all other objects, are named by the SHA-1 hash of their
+contents, two trees have the same SHA-1 name if and only if their
+contents (including, recursively, the contents of all subdirectories)
+are identical. This allows Git to quickly determine the differences
+between two related tree objects, since it can ignore any entries with
+identical object names.
+
+(Note: in the presence of submodules, trees may also have commits as
+entries. See <<submodules>> for documentation.)
+
+Note that the files all have mode 644 or 755: Git actually only pays
+attention to the executable bit.
+
+[[blob-object]]
+==== Blob Object
+
+You can use linkgit:git-show[1] to examine the contents of a blob; take,
+for example, the blob in the entry for `COPYING` from the tree above:
+
+------------------------------------------------
+$ git show 6ff87c4664
+
+ Note that the only valid version of the GPL as far as this project
+ is concerned is _this_ particular version of the license (ie v2, not
+ v2.2 or v3.x or whatever), unless explicitly otherwise stated.
+...
+------------------------------------------------
+
+A "blob" object is nothing but a binary blob of data. It doesn't refer
+to anything else or have attributes of any kind.
+
+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.
+
+Note that any tree or blob object can be examined using
+linkgit:git-show[1] with the <revision>:<path> syntax. This can
+sometimes be useful for browsing the contents of a tree that is not
+currently checked out.
+
+[[trust]]
+==== Trust
+
+If you receive the SHA-1 name of a blob from one source, and its contents
+from another (possibly untrusted) source, you can still trust that those
+contents are correct as long as the SHA-1 name agrees. This is because
+the SHA-1 is designed so that it is infeasible to find different contents
+that produce the same hash.
+
+Similarly, you need only trust the SHA-1 name of a top-level tree object
+to trust the contents of the entire directory that it refers to, and if
+you receive the SHA-1 name of a commit from a trusted source, then you
+can easily verify the entire history of commits reachable through
+parents of that commit, and all of those contents of the trees referred
+to by those commits.
+
+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 (SHA-1 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]]
+==== Tag Object
+
+A tag object contains an object, object type, tag name, the name of the
+person ("tagger") who created the tag, and a message, which may contain
+a signature, as can be seen using linkgit:git-cat-file[1]:
+
+------------------------------------------------
+$ git cat-file tag v1.5.0
+object 437b1b20df4b356c9342dac8d38849f24ef44f27
+type commit
+tag v1.5.0
+tagger Junio C Hamano <junkio@cox.net> 1171411200 +0000
+
+GIT 1.5.0
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.6 (GNU/Linux)
+
+iD8DBQBF0lGqwMbZpPMRm5oRAuRiAJ9ohBLd7s2kqjkKlq1qqC57SbnmzQCdG4ui
+nLE/L9aUXdWeTFPron96DLA=
+=2E+0
+-----END PGP SIGNATURE-----
+------------------------------------------------
+
+See the linkgit:git-tag[1] command to learn how to create and verify tag
+objects. (Note that linkgit:git-tag[1] can also be used to create
+"lightweight tags", which are not tag objects at all, but just simple
+references whose names begin with `refs/tags/`).
+
+[[pack-files]]
+==== How Git stores objects efficiently: pack files
+
+Newly created objects are initially created in a file named after the
+object's SHA-1 hash (stored in `.git/objects`).
+
+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 linkgit:gitformat-pack[5].
+
+To put the loose objects into a pack, just run git repack:
+
+------------------------------------------------
+$ git repack
+Counting objects: 6020, done.
+Delta compression using up to 4 threads.
+Compressing objects: 100% (6020/6020), done.
+Writing objects: 100% (6020/6020), done.
+Total 6020 (delta 4070), reused 0 (delta 0)
+------------------------------------------------
+
+This creates a single "pack file" in .git/objects/pack/
+containing all currently unpacked objects. 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 linkgit: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 linkgit: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
+<<cleaning-up-history>>. In that case, the old head of the original
+branch still exists, as does everything it pointed to. The branch
+pointer itself just doesn't, since you replaced it with another one.
+
+There are also other situations 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 "ort" 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, you can just use:
+
+------------------------------------------------
+$ gitk <dangling-commit-sha-goes-here> --not --all
+------------------------------------------------
+
+This asks for all the history reachable from the given commit but not
+from any branch, tag, or other reference. If you decide it's something
+you want, you can always create a new reference to it, e.g.,
+
+------------------------------------------------
+$ git branch recovered-branch <dangling-commit-sha-goes-here>
+------------------------------------------------
+
+For blobs and trees, you can't do the same, but you can still examine
+them. You can just do
+
+------------------------------------------------
+$ git show <dangling-blob/tree-sha-goes-here>
+------------------------------------------------
+
+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. (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.
+`git prune` is designed not to cause any harm in such cases of concurrent
+accesses to a repository but you might receive confusing or scary messages.)
+
+[[recovering-from-repository-corruption]]
+==== Recovering from repository corruption
+
+By design, Git treats data trusted to it with caution. However, even in
+the absence of bugs in Git itself, it is still possible that hardware or
+operating system errors could corrupt data.
+
+The first defense against such problems is backups. You can back up a
+Git directory using clone, or just using cp, tar, or any other backup
+mechanism.
+
+As a last resort, you can search for the corrupted objects and attempt
+to replace them by hand. Back up your repository before attempting this
+in case you corrupt things even more in the process.
+
+We'll assume that the problem is a single missing or corrupted blob,
+which is sometimes a solvable problem. (Recovering missing trees and
+especially commits is *much* harder).
+
+Before starting, verify that there is corruption, and figure out where
+it is with linkgit:git-fsck[1]; this may be time-consuming.
+
+Assume the output looks like this:
+
+------------------------------------------------
+$ git fsck --full --no-dangling
+broken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
+ to blob 4b9458b3786228369c63936db65827de3cc06200
+missing blob 4b9458b3786228369c63936db65827de3cc06200
+------------------------------------------------
+
+Now you know that blob 4b9458b3 is missing, and that the tree 2d9263c6
+points to it. If you could find just one copy of that missing blob
+object, possibly in some other repository, you could move it into
+`.git/objects/4b/9458b3...` and be done. Suppose you can't. You can
+still examine the tree that pointed to it with linkgit:git-ls-tree[1],
+which might output something like:
+
+------------------------------------------------
+$ git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
+100644 blob 8d14531846b95bfa3564b58ccfb7913a034323b8 .gitignore
+100644 blob ebf9bf84da0aab5ed944264a5db2a65fe3a3e883 .mailmap
+100644 blob ca442d313d86dc67e0a2e5d584b465bd382cbf5c COPYING
+...
+100644 blob 4b9458b3786228369c63936db65827de3cc06200 myfile
+...
+------------------------------------------------
+
+So now you know that the missing blob was the data for a file named
+`myfile`. And chances are you can also identify the directory--let's
+say it's in `somedirectory`. If you're lucky the missing copy might be
+the same as the copy you have checked out in your working tree at
+`somedirectory/myfile`; you can test whether that's right with
+linkgit:git-hash-object[1]:
+
+------------------------------------------------
+$ git hash-object -w somedirectory/myfile
+------------------------------------------------
+
+which will create and store a blob object with the contents of
+somedirectory/myfile, and output the SHA-1 of that object. if you're
+extremely lucky it might be 4b9458b3786228369c63936db65827de3cc06200, in
+which case you've guessed right, and the corruption is fixed!
+
+Otherwise, you need more information. How do you tell which version of
+the file has been lost?
+
+The easiest way to do this is with:
+
+------------------------------------------------
+$ git log --raw --all --full-history -- somedirectory/myfile
+------------------------------------------------
+
+Because you're asking for raw output, you'll now get something like
+
+------------------------------------------------
+commit abc
+Author:
+Date:
+...
+:100644 100644 4b9458b newsha M somedirectory/myfile
+
+
+commit xyz
+Author:
+Date:
+
+...
+:100644 100644 oldsha 4b9458b M somedirectory/myfile
+------------------------------------------------
+
+This tells you that the immediately following version of the file was
+"newsha", and that the immediately preceding version was "oldsha".
+You also know the commit messages that went with the change from oldsha
+to 4b9458b and with the change from 4b9458b to newsha.
+
+If you've been committing small enough changes, you may now have a good
+shot at reconstructing the contents of the in-between state 4b9458b.
+
+If you can do that, you can now recreate the missing object with
+
+------------------------------------------------
+$ git hash-object -w <recreated-file>
+------------------------------------------------
+
+and your repository is good again!
+
+(Btw, you could have ignored the `fsck`, and started with doing a
+
+------------------------------------------------
+$ git log --raw --all
+------------------------------------------------
+
+and just looked for the sha of the missing object (4b9458b) in that
+whole thing. It's up to you--Git does *have* a lot of information, it is
+just missing one particular blob version.
+
+[[the-index]]
+=== The index
+
+The index is a binary file (generally kept in `.git/index`) containing a
+sorted list of path names, each with permissions and the SHA-1 of a blob
+object; linkgit:git-ls-files[1] can show you the contents of the index:
+
+-------------------------------------------------
+$ git ls-files --stage
+100644 63c918c667fa005ff12ad89437f2fdc80926e21c 0 .gitignore
+100644 5529b198e8d14decbe4ad99db3f7fb632de0439d 0 .mailmap
+100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3 0 COPYING
+100644 a37b2152bd26be2c2289e1f57a292534a51a93c7 0 Documentation/.gitignore
+100644 fbefe9a45b00a54b58d94d06eca48b03d40a50e0 0 Documentation/Makefile
+...
+100644 2511aef8d89ab52be5ec6a5e46236b4b6bcd07ea 0 xdiff/xtypes.h
+100644 2ade97b2574a9f77e7ae4002a4e07a6a38e46d07 0 xdiff/xutils.c
+100644 d5de8292e05e7c36c4b68857c1cf9855e3d2f70a 0 xdiff/xutils.h
+-------------------------------------------------
+
+Note that in older documentation you may see the index called the
+"current directory cache" or just the "cache". It has three important
+properties:
+
+1. The index contains all the information necessary to generate a single
+(uniquely determined) tree object.
++
+For example, running linkgit:git-commit[1] generates this tree object
+from the index, stores it in the object database, and uses it as the
+tree object associated with the new commit.
+
+2. The index enables fast comparisons between the tree object it defines
+and the working tree.
++
+It does this by storing some additional data for each entry (such as
+the last modified time). This data is not displayed above, and is not
+stored in the created tree object, but it can be used to determine
+quickly which files in the working directory differ from what was
+stored in the index, and thus save Git from having to read all of the
+data from such files to look for changes.
+
+3. It can 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.
++
+We saw in <<conflict-resolution>> that during a merge the index can
+store multiple versions of a single file (called "stages"). The third
+column in the linkgit:git-ls-files[1] output above is the stage
+number, and will take on values other than 0 for files with merge
+conflicts.
+
+The index is thus a sort of temporary staging area, which is filled with
+a tree which you are in the process of working on.
+
+If you blow the index away entirely, you generally haven't lost any
+information as long as you have the name of the tree that it described.
+
+[[submodules]]
+== Submodules
+
+Large projects are often composed of smaller, self-contained modules. For
+example, an embedded Linux distribution's source tree would include every
+piece of software in the distribution with some local modifications; a movie
+player might need to build against a specific, known-working version of a
+decompression library; several independent programs might all share the same
+build scripts.
+
+With centralized revision control systems this is often accomplished by
+including every module in one single repository. Developers can check out
+all modules or only the modules they need to work with. They can even modify
+files across several modules in a single commit while moving things around
+or updating APIs and translations.
+
+Git does not allow partial checkouts, so duplicating this approach in Git
+would force developers to keep a local copy of modules they are not
+interested in touching. Commits in an enormous checkout would be slower
+than you'd expect as Git would have to scan every directory for changes.
+If modules have a lot of local history, clones would take forever.
+
+On the plus side, distributed revision control systems can much better
+integrate with external sources. In a centralized model, a single arbitrary
+snapshot of the external project is exported from its own revision control
+and then imported into the local revision control on a vendor branch. All
+the history is hidden. With distributed revision control you can clone the
+entire external history and much more easily follow development and re-merge
+local changes.
+
+Git's submodule support allows a repository to contain, as a subdirectory, a
+checkout of an external project. Submodules maintain their own identity;
+the submodule support just stores the submodule repository location and
+commit ID, so other developers who clone the containing project
+("superproject") can easily clone all the submodules at the same revision.
+Partial checkouts of the superproject are possible: you can tell Git to
+clone none, some or all of the submodules.
+
+The linkgit:git-submodule[1] command is available since Git 1.5.3. Users
+with Git 1.5.2 can look up the submodule commits in the repository and
+manually check them out; earlier versions won't recognize the submodules at
+all.
+
+To see how submodule support works, create four example
+repositories that can be used later as a submodule:
+
+-------------------------------------------------
+$ mkdir ~/git
+$ cd ~/git
+$ for i in a b c d
+do
+ mkdir $i
+ cd $i
+ git init
+ echo "module $i" > $i.txt
+ git add $i.txt
+ git commit -m "Initial commit, submodule $i"
+ cd ..
+done
+-------------------------------------------------
+
+Now create the superproject and add all the submodules:
+
+-------------------------------------------------
+$ mkdir super
+$ cd super
+$ git init
+$ for i in a b c d
+do
+ git submodule add ~/git/$i $i
+done
+-------------------------------------------------
+
+NOTE: Do not use local URLs here if you plan to publish your superproject!
+
+See what files `git submodule` created:
+
+-------------------------------------------------
+$ ls -a
+. .. .git .gitmodules a b c d
+-------------------------------------------------
+
+The `git submodule add <repo> <path>` command does a couple of things:
+
+- It clones the submodule from `<repo>` to the given `<path>` under the
+ current directory and by default checks out the master branch.
+- It adds the submodule's clone path to the linkgit:gitmodules[5] file and
+ adds this file to the index, ready to be committed.
+- It adds the submodule's current commit ID to the index, ready to be
+ committed.
+
+Commit the superproject:
+
+-------------------------------------------------
+$ git commit -m "Add submodules a, b, c and d."
+-------------------------------------------------
+
+Now clone the superproject:
+
+-------------------------------------------------
+$ cd ..
+$ git clone super cloned
+$ cd cloned
+-------------------------------------------------
+
+The submodule directories are there, but they're empty:
+
+-------------------------------------------------
+$ ls -a a
+. ..
+$ git submodule status
+-d266b9873ad50488163457f025db7cdd9683d88b a
+-e81d457da15309b4fef4249aba9b50187999670d b
+-c1536a972b9affea0f16e0680ba87332dc059146 c
+-d96249ff5d57de5de093e6baff9e0aafa5276a74 d
+-------------------------------------------------
+
+NOTE: The commit object names shown above would be different for you, but they
+should match the HEAD commit object names of your repositories. You can check
+it by running `git ls-remote ../a`.
+
+Pulling down the submodules is a two-step process. First run `git submodule
+init` to add the submodule repository URLs to `.git/config`:
+
+-------------------------------------------------
+$ git submodule init
+-------------------------------------------------
+
+Now use `git submodule update` to clone the repositories and check out the
+commits specified in the superproject:
+
+-------------------------------------------------
+$ git submodule update
+$ cd a
+$ ls -a
+. .. .git a.txt
+-------------------------------------------------
+
+One major difference between `git submodule update` and `git submodule add` is
+that `git submodule update` checks out a specific commit, rather than the tip
+of a branch. It's like checking out a tag: the head is detached, so you're not
+working on a branch.
+
+-------------------------------------------------
+$ git branch
+* (detached from d266b98)
+ master
+-------------------------------------------------
+
+If you want to make a change within a submodule and you have a detached head,
+then you should create or checkout a branch, make your changes, publish the
+change within the submodule, and then update the superproject to reference the
+new commit:
+
+-------------------------------------------------
+$ git switch master
+-------------------------------------------------
+
+or
+
+-------------------------------------------------
+$ git switch -c fix-up
+-------------------------------------------------
+
+then
+
+-------------------------------------------------
+$ echo "adding a line again" >> a.txt
+$ git commit -a -m "Updated the submodule from within the superproject."
+$ git push
+$ cd ..
+$ git diff
+diff --git a/a b/a
+index d266b98..261dfac 160000
+--- a/a
++++ b/a
+@@ -1 +1 @@
+-Subproject commit d266b9873ad50488163457f025db7cdd9683d88b
++Subproject commit 261dfac35cb99d380eb966e102c1197139f7fa24
+$ git add a
+$ git commit -m "Updated submodule a."
+$ git push
+-------------------------------------------------
+
+You have to run `git submodule update` after `git pull` if you want to update
+submodules, too.
+
+[[pitfalls-with-submodules]]
+=== Pitfalls with submodules
+
+Always publish the submodule change before publishing the change to the
+superproject that references it. If you forget to publish the submodule change,
+others won't be able to clone the repository:
+
+-------------------------------------------------
+$ cd ~/git/super/a
+$ echo i added another line to this file >> a.txt
+$ git commit -a -m "doing it wrong this time"
+$ cd ..
+$ git add a
+$ git commit -m "Updated submodule a again."
+$ git push
+$ cd ~/git/cloned
+$ git pull
+$ git submodule update
+error: pathspec '261dfac35cb99d380eb966e102c1197139f7fa24' did not match any file(s) known to git.
+Did you forget to 'git add'?
+Unable to checkout '261dfac35cb99d380eb966e102c1197139f7fa24' in submodule path 'a'
+-------------------------------------------------
+
+In older Git versions it could be easily forgotten to commit new or modified
+files in a submodule, which silently leads to similar problems as not pushing
+the submodule changes. Starting with Git 1.7.0 both `git status` and `git diff`
+in the superproject show submodules as modified when they contain new or
+modified files to protect against accidentally committing such a state. `git
+diff` will also add a `-dirty` to the work tree side when generating patch
+output or used with the `--submodule` option:
+
+-------------------------------------------------
+$ git diff
+diff --git a/sub b/sub
+--- a/sub
++++ b/sub
+@@ -1 +1 @@
+-Subproject commit 3f356705649b5d566d97ff843cf193359229a453
++Subproject commit 3f356705649b5d566d97ff843cf193359229a453-dirty
+$ git diff --submodule
+Submodule sub 3f35670..3f35670-dirty:
+-------------------------------------------------
+
+You also should not rewind branches in a submodule beyond commits that were
+ever recorded in any superproject.
+
+It's not safe to run `git submodule update` if you've made and committed
+changes within a submodule without checking out a branch first. They will be
+silently overwritten:
+
+-------------------------------------------------
+$ cat a.txt
+module a
+$ echo line added from private2 >> a.txt
+$ git commit -a -m "line added inside private2"
+$ cd ..
+$ git submodule update
+Submodule path 'a': checked out 'd266b9873ad50488163457f025db7cdd9683d88b'
+$ cd a
+$ cat a.txt
+module a
+-------------------------------------------------
+
+NOTE: The changes are still visible in the submodule's reflog.
+
+If you have uncommitted changes in your submodule working tree, `git
+submodule update` will not overwrite them. Instead, you get the usual
+warning about not being able switch from a dirty branch.
+
+[[low-level-operations]]
+== Low-level Git operations
+
+Many of the higher-level commands were originally implemented as shell
+scripts using a smaller core of low-level Git commands. These can still
+be useful when doing unusual things with Git, or just as a way to
+understand its inner workings.
+
+[[object-manipulation]]
+=== Object access and manipulation
+
+The linkgit:git-cat-file[1] command can show the contents of any object,
+though the higher-level linkgit:git-show[1] is usually more useful.
+
+The linkgit:git-commit-tree[1] command allows constructing commits with
+arbitrary parents and trees.
+
+A tree can be created with linkgit:git-write-tree[1] and its data can be
+accessed by linkgit:git-ls-tree[1]. Two trees can be compared with
+linkgit:git-diff-tree[1].
+
+A tag is created with linkgit:git-mktag[1], and the signature can be
+verified by linkgit:git-verify-tag[1], though it is normally simpler to
+use linkgit:git-tag[1] for both.
+
+[[the-workflow]]
+=== The Workflow
+
+High-level operations such as linkgit:git-commit[1] and
+linkgit:git-restore[1] work by moving data
+between the working tree, the index, and the object database. Git
+provides low-level operations which perform each of these steps
+individually.
+
+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 between the index file and either
+the database or the working directory. Thus there are four main
+combinations:
+
+[[working-directory-to-index]]
+==== working directory -> index
+
+The linkgit:git-update-index[1] command updates the index with
+information from the working directory. 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-index 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.
+
+The previously introduced linkgit:git-add[1] is just a wrapper for
+linkgit:git-update-index[1].
+
+[[index-to-object-database]]
+==== 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-to-index]]
+==== 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 <SHA-1 of 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-to-working-directory]]
+==== 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]]
+==== 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 <tree> -p <parent> [(-p <parent2>)...]
+-------------------------------------------------
+
+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 a picture 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]]
+=== 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
+linkgit:git-cat-file[1] to examine details about the
+object:
+
+-------------------------------------------------
+$ git cat-file -t <objectname>
+-------------------------------------------------
+
+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 <objectname>
+-------------------------------------------------
+
+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]]
+=== Merging multiple trees
+
+Git can help you perform a three-way merge, which can in turn be
+used for a many-way merge by repeating the merge procedure several
+times. The usual situation is that you only do one three-way merge
+(reconciling two lines of history) and commit the result, but if
+you like to, you can merge several branches in one go.
+
+To perform a three-way merge, you start with the two commits you
+want to merge, find their closest common parent (a third commit),
+and compare the trees corresponding to these three commits.
+
+To get the "base" for the merge, look up the common parent of two
+commits:
+
+-------------------------------------------------
+$ git merge-base <commit1> <commit2>
+-------------------------------------------------
+
+This prints the name of a commit they are both based on. You should
+now look up the tree objects of those commits, which you can easily
+do with
+
+-------------------------------------------------
+$ git cat-file commit <commitname> | 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 tree, 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 <origtree> <yourtree> <targettree>
+-------------------------------------------------
+
+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-2]]
+=== 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 SHA-1, 'stage number', and the
+filename. The 'stage number' is Git's way to say which tree it
+came from: stage 1 corresponds to the `$orig` tree, stage 2 to
+the `HEAD` tree, and stage 3 to the `$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` or `$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`, `merge`, or Git's own merge-file, 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
+$ git merge-file 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 the "unmerged" state, running `git update-index` for
+that path tells Git to mark the path resolved.
+
+The above is the description of a Git merge at the lowest level,
+to help you understand what conceptually happens under the hood.
+In practice, nobody, not even Git itself, runs `git cat-file` three times
+for this. There is a `git merge-index` program that extracts the
+stages to temporary files and calls a "merge" script on it:
+
+-------------------------------------------------
+$ git merge-index git-merge-one-file hello.c
+-------------------------------------------------
+
+and that is what higher level `git merge -s resolve` is implemented with.
+
+[[hacking-git]]
+== Hacking Git
+
+This chapter covers internal details of the Git implementation which
+probably only Git developers need to understand.
+
+[[object-details]]
+=== Object storage format
+
+All objects have a statically determined "type" which identifies the
+format of the object (i.e. how it is used, and how it can refer to other
+objects). There are currently four different object types: "blob",
+"tree", "commit", and "tag".
+
+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 SHA-1 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' (the earliest versions of Git hashed slightly differently
+but the conclusion is still the same).
+
+The following is a short example that demonstrates how these hashes
+can be generated manually:
+
+Let's assume a small text file with some simple content:
+
+-------------------------------------------------
+$ echo "Hello world" >hello.txt
+-------------------------------------------------
+
+We can now manually generate the hash Git would use for this file:
+
+- The object we want the hash for is of type "blob" and its size is
+ 12 bytes.
+
+- Prepend the object header to the file content and feed this to
+ `sha1sum`:
+
+-------------------------------------------------
+$ { printf "blob 12\0"; cat hello.txt; } | sha1sum
+802992c4220de19a90767f3000a79a31b98d0df7 -
+-------------------------------------------------
+
+This manually constructed hash can be verified using `git hash-object`
+which of course hides the addition of the header:
+
+-------------------------------------------------
+$ git hash-object hello.txt
+802992c4220de19a90767f3000a79a31b98d0df7
+-------------------------------------------------
+
+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
+`<ascii-type-without-space> + <space> + <ascii-decimal-size> +
+<byte\0> + <binary-object-data>`.
+
+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).
+
+[[birdview-on-the-source-code]]
+=== A birds-eye view of Git's source code
+
+It is not always easy for new developers to find their way through Git's
+source code. This section gives you a little guidance to show where to
+start.
+
+A good place to start is with the contents of the initial commit, with:
+
+----------------------------------------------------
+$ git switch --detach e83c5163
+----------------------------------------------------
+
+The initial revision lays the foundation for almost everything Git has
+today (even though details may differ in a few places), but is small
+enough to read in one sitting.
+
+Note that terminology has changed since that revision. For example, the
+README in that revision uses the word "changeset" to describe what we
+now call a <<def_commit_object,commit>>.
+
+Also, we do not call it "cache" any more, but rather "index"; however,
+the file is still called `read-cache.h`.
+
+If you grasp the ideas in that initial commit, you should check out a
+more recent version and skim `read-cache-ll.h`, `object.h` and `commit.h`.
+
+In the early days, Git (in the tradition of UNIX) was a bunch of programs
+which were extremely simple, and which you used in scripts, piping the
+output of one into another. This turned out to be good for initial
+development, since it was easier to test new things. However, recently
+many of these parts have become builtins, and some of the core has been
+"libified", i.e. put into libgit.a for performance, portability reasons,
+and to avoid code duplication.
+
+By now, you know what the index is (and find the corresponding data
+structures in `read-cache-ll.h`), and that there are just a couple of
+object types (blobs, trees, commits and tags) which inherit their
+common structure from `struct object`, which is their first member
+(and thus, you can cast e.g. `(struct object *)commit` to achieve the
+_same_ as `&commit->object`, i.e. get at the object name and flags).
+
+Now is a good point to take a break to let this information sink in.
+
+Next step: get familiar with the object naming. Read <<naming-commits>>.
+There are quite a few ways to name an object (and not only revisions!).
+All of these are handled in `sha1_name.c`. Just have a quick look at
+the function `get_sha1()`. A lot of the special handling is done by
+functions like `get_sha1_basic()` or the likes.
+
+This is just to get you into the groove for the most libified part of Git:
+the revision walker.
+
+Basically, the initial version of `git log` was a shell script:
+
+----------------------------------------------------------------
+$ git-rev-list --pretty $(git-rev-parse --default HEAD "$@") | \
+ LESS=-S ${PAGER:-less}
+----------------------------------------------------------------
+
+What does this mean?
+
+`git rev-list` is the original version of the revision walker, which
+_always_ printed a list of revisions to stdout. It is still functional,
+and needs to, since most new Git commands start out as scripts using
+`git rev-list`.
+
+`git rev-parse` is not as important any more; it was only used to filter out
+options that were relevant for the different plumbing commands that were
+called by the script.
+
+Most of what `git rev-list` did is contained in `revision.c` and
+`revision.h`. It wraps the options in a struct named `rev_info`, which
+controls how and what revisions are walked, and more.
+
+The original job of `git rev-parse` is now taken by the function
+`setup_revisions()`, which parses the revisions and the common command-line
+options for the revision walker. This information is stored in the struct
+`rev_info` for later consumption. You can do your own command-line option
+parsing after calling `setup_revisions()`. After that, you have to call
+`prepare_revision_walk()` for initialization, and then you can get the
+commits one by one with the function `get_revision()`.
+
+If you are interested in more details of the revision walking process,
+just have a look at the first implementation of `cmd_log()`; call
+`git show v1.3.0~155^2~4` and scroll down to that function (note that you
+no longer need to call `setup_pager()` directly).
+
+Nowadays, `git log` is a builtin, which means that it is _contained_ in the
+command `git`. The source side of a builtin is
+
+- a function called `cmd_<bla>`, typically defined in `builtin/<bla.c>`
+ (note that older versions of Git used to have it in `builtin-<bla>.c`
+ instead), and declared in `builtin.h`.
+
+- an entry in the `commands[]` array in `git.c`, and
+
+- an entry in `BUILTIN_OBJECTS` in the `Makefile`.
+
+Sometimes, more than one builtin is contained in one source file. For
+example, `cmd_whatchanged()` and `cmd_log()` both reside in `builtin/log.c`,
+since they share quite a bit of code. In that case, the commands which are
+_not_ named like the `.c` file in which they live have to be listed in
+`BUILT_INS` in the `Makefile`.
+
+`git log` looks more complicated in C than it does in the original script,
+but that allows for a much greater flexibility and performance.
+
+Here again it is a good point to take a pause.
+
+Lesson three is: study the code. Really, it is the best way to learn about
+the organization of Git (after you know the basic concepts).
+
+So, think about something which you are interested in, say, "how can I
+access a blob just knowing the object name of it?". The first step is to
+find a Git command with which you can do it. In this example, it is either
+`git show` or `git cat-file`.
+
+For the sake of clarity, let's stay with `git cat-file`, because it
+
+- is plumbing, and
+
+- was around even in the initial commit (it literally went only through
+ some 20 revisions as `cat-file.c`, was renamed to `builtin/cat-file.c`
+ when made a builtin, and then saw less than 10 versions).
+
+So, look into `builtin/cat-file.c`, search for `cmd_cat_file()` and look what
+it does.
+
+------------------------------------------------------------------
+ git_config(git_default_config);
+ if (argc != 3)
+ usage("git cat-file [-t|-s|-e|-p|<type>] <sha1>");
+ if (get_sha1(argv[2], sha1))
+ die("Not a valid object name %s", argv[2]);
+------------------------------------------------------------------
+
+Let's skip over the obvious details; the only really interesting part
+here is the call to `get_sha1()`. It tries to interpret `argv[2]` as an
+object name, and if it refers to an object which is present in the current
+repository, it writes the resulting SHA-1 into the variable `sha1`.
+
+Two things are interesting here:
+
+- `get_sha1()` returns 0 on _success_. This might surprise some new
+ Git hackers, but there is a long tradition in UNIX to return different
+ negative numbers in case of different errors--and 0 on success.
+
+- the variable `sha1` in the function signature of `get_sha1()` is `unsigned
+ char *`, but is actually expected to be a pointer to `unsigned
+ char[20]`. This variable will contain the 160-bit SHA-1 of the given
+ commit. Note that whenever a SHA-1 is passed as `unsigned char *`, it
+ is the binary representation, as opposed to the ASCII representation in
+ hex characters, which is passed as `char *`.
+
+You will see both of these things throughout the code.
+
+Now, for the meat:
+
+-----------------------------------------------------------------------------
+ case 0:
+ buf = read_object_with_reference(sha1, argv[1], &size, NULL);
+-----------------------------------------------------------------------------
+
+This is how you read a blob (actually, not only a blob, but any type of
+object). To know how the function `read_object_with_reference()` actually
+works, find the source code for it (something like `git grep
+read_object_with | grep ":[a-z]"` in the Git repository), and read
+the source.
+
+To find out how the result can be used, just read on in `cmd_cat_file()`:
+
+-----------------------------------
+ write_or_die(1, buf, size);
+-----------------------------------
+
+Sometimes, you do not know where to look for a feature. In many such cases,
+it helps to search through the output of `git log`, and then `git show` the
+corresponding commit.
+
+Example: If you know that there was some test case for `git bundle`, but
+do not remember where it was (yes, you _could_ `git grep bundle t/`, but that
+does not illustrate the point!):
+
+------------------------
+$ git log --no-merges t/
+------------------------
+
+In the pager (`less`), just search for "bundle", go a few lines back,
+and see that it is in commit 18449ab0. Now just copy this object name,
+and paste it into the command line
+
+-------------------
+$ git show 18449ab0
+-------------------
+
+Voila.
+
+Another example: Find out what to do in order to make some script a
+builtin:
+
+-------------------------------------------------
+$ git log --no-merges --diff-filter=A builtin/*.c
+-------------------------------------------------
+
+You see, Git is actually the best tool to find out about the source of Git
+itself!
+
+[[glossary]]
+== Git Glossary
+
+[[git-explained]]
+=== Git explained
+
+include::glossary-content.adoc[]
+
+[[git-quick-start]]
+[appendix]
+== Git Quick Reference
+
+This is a quick summary of the major commands; the previous chapters
+explain how these work in more detail.
+
+[[quick-creating-a-new-repository]]
+=== 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]]
+=== Managing branches
+
+-----------------------------------------------
+$ git branch # list all local branches in this repo
+$ git switch 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 a 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 switch -c 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 switch -c 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]]
+=== 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]]
+=== 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]]
+=== 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]]
+=== 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]]
+=== Repository maintenance
+
+Check for corruption:
+
+-----------------------------------------------
+$ git fsck
+-----------------------------------------------
+
+Recompress, remove unused cruft:
+
+-----------------------------------------------
+$ git gc
+-----------------------------------------------
+
+
+[[todo]]
+[appendix]
+== Notes and todo list for this manual
+
+[[todo-list]]
+=== Todo list
+
+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 command line, 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 linkgit:git[1]
+
+Scan email archives for other stuff left out
+
+Scan man pages to see if any assume more background than this manual
+provides.
+
+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.
+
+Add a section on working with other version control systems, including
+CVS, Subversion, and just imports of series of release tarballs.
+
+Write a chapter on using plumbing and writing scripts.
+
+Alternates, clone -reference, etc.
+
+More on recovery from repository corruption. See:
+ https://lore.kernel.org/git/Pine.LNX.4.64.0702272039540.12485@woody.linux-foundation.org/
+ https://lore.kernel.org/git/Pine.LNX.4.64.0702141033400.3604@woody.linux-foundation.org/
