undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Git 2.25-rc0

Browse Source 
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEE4fA2sf7nIh/HeOzvsLXohpav5ssFAl4DuEkACgkQsLXohpav
 5stohQ//c62eS6Z0JxBnJ6Ti0YE4mGGMdGdw6DgMU3M/Nc6k+1dL0JtqySM9UsT0
 ZJRAWafP0rvvs90jTR6N4HT3s67O4n42imRW1Co3eFXuogeOgUcerhrOY8BJw8j3
 +2lm65EXmbTnfyYSUZ/nCxy6xoG9HR4jT5omMmZcLzngxaXuyx/BfWXC5kPB8mcs
 qsp5X7569tdYkpI2TUjqc1gO6x1GfWYabIOEK+okc4OpX7HBBtXvmecZxIwRoaFt
 J/ljHiCqsNl0m0AQZksD0lUtR+o2xnnoKrucRCMA90DBArsATeKkQbbLTE7uRdkz
 S7uUySSCuEvKpdty2PS/NoAqBd4JbnF/hqqrOS7AMZH8HYijS6ZMdoxjC5TXAuky
 ZSaii24LL8RTHrHaPvu9CkHsru1S8zTI5jxBc5WJUZFnmBYHBMIafYAQD+F+2mdG
 wwGvH4hFLPBV3cBM5aVx+dPtdnZZD++3AaqtO8ff8i/h3W/zza+0xLeY4Mtlagw3
 ZTTCizQuAwpowaDtBnw3cHK34ZAHmAtUq5Auacns+rJawpFJwfL5GkawxkUph2Bm
 zIXz2FThOKTQRgj01XVYCUIu6eVMl/ODzEd6i7fjX+o5o+7TZ92lDvkEZat7ycjY
 PMHZECtT1gbVqyodUC6CtoSjwwueFQR1w/rG+myyS5dNGJ3wB1I=
 =tPgc
 -----END PGP SIGNATURE-----

Merge tag 'v2.25.0-rc0' into git-po-master

Git 2.25-rc0

* tag 'v2.25.0-rc0': (531 commits)
  Git 2.25-rc0
  sparse-checkout: improve OS ls compatibility
  dir.c: use st_add3() for allocation size
  dir: consolidate similar code in treat_directory()
  dir: synchronize treat_leading_path() and read_directory_recursive()
  dir: fix checks on common prefix directory
  t4015: improve coverage of function context test
  commit: forbid --pathspec-from-file --all
  t3434: mark successful test as such
  notes.h: fix typos in comment
  t6030: don't create unused file
  t5580: don't create unused file
  t3501: don't create unused file
  bisect--helper: convert `*_warning` char pointers to char arrays.
  The sixth batch
  fix-typo: consecutive-word duplications
  Makefile: drop GEN_HDRS
  built-in add -p: show helpful hint when nothing can be staged
  built-in add -p: only show the applicable parts of the help text
  built-in add -p: implement the 'q' ("quit") command
  ...
This commit is contained in:
Jiang Xin 2019-12-30 08:47:27 +08:00
commit 173fff68da
518 changed files with 17379 additions and 6604 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.gitignore vendored
View File

@ -158,6 +158,7 @@
/git-show-branch /git-show-branch
/git-show-index /git-show-index
/git-show-ref /git-show-ref
/git-sparse-checkout
/git-stage /git-stage
/git-stash /git-stash
/git-status /git-status

4
Documentation/CodingGuidelines
View File

@ -75,7 +75,7 @@ For shell scripts specifically (not exhaustive):
- If you want to find out if a command is available on the user's - If you want to find out if a command is available on the user's
$PATH, you should use 'type <command>', instead of 'which <command>'. $PATH, you should use 'type <command>', instead of 'which <command>'.
The output of 'which' is not machine parseable and its exit code The output of 'which' is not machine parsable and its exit code
is not reliable across platforms. is not reliable across platforms.
- We use POSIX compliant parameter substitutions and avoid bashisms; - We use POSIX compliant parameter substitutions and avoid bashisms;
@ -203,7 +203,7 @@ For C programs:
. since early 2012 with e1327023ea, we have been using an enum . since early 2012 with e1327023ea, we have been using an enum
definition whose last element is followed by a comma. This, like definition whose last element is followed by a comma. This, like
an array initializer that ends with a trailing comma, can be used an array initializer that ends with a trailing comma, can be used
to reduce the patch noise when adding a new identifer at the end. to reduce the patch noise when adding a new identifier at the end.
. since mid 2017 with cbc0f81d, we have been using designated . since mid 2017 with cbc0f81d, we have been using designated
initializers for struct (e.g. "struct t v = { .val = 'a' };"). initializers for struct (e.g. "struct t v = { .val = 'a' };").

1
Documentation/Makefile
View File

@ -77,6 +77,7 @@ API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technica
SP_ARTICLES += $(API_DOCS) SP_ARTICLES += $(API_DOCS)
TECH_DOCS += MyFirstContribution TECH_DOCS += MyFirstContribution
TECH_DOCS += MyFirstObjectWalk
TECH_DOCS += SubmittingPatches TECH_DOCS += SubmittingPatches
TECH_DOCS += technical/hash-function-transition TECH_DOCS += technical/hash-function-transition
TECH_DOCS += technical/http-protocol TECH_DOCS += technical/http-protocol

55
Documentation/MyFirstContribution.txt
View File

@ -38,6 +38,26 @@ $ git clone https://github.com/git/git git
$ cd 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]]
=== Identify Problem to Solve === Identify Problem to Solve
@ -138,9 +158,6 @@ 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 `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. it off, but it's a good idea to mention the problem to the mailing list.
NOTE: The Git build is parallelizable. `-j#` is not included above but you can
use it as you prefer, here and elsewhere.
Great, now your new command builds happily on its own. But nobody invokes it. Great, now your new command builds happily on its own. But nobody invokes it.
Let's change that. Let's change that.
@ -534,6 +551,28 @@ 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 a flag.) `parse_options()` will terminate parsing when it reaches `--` and give
you the rest of the options afterwards, untouched. 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 Build again. Now, when you run with `-h`, you should see your usage printed and
your command terminated before anything else interesting happens. Great! your command terminated before anything else interesting happens. Great!
@ -746,6 +785,14 @@ 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 but you will not be able to `/submit` your changes until someone allows you to
use the tool. 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://webchat.freenode.net/#git-devel[#git-devel] IRC channel on Freenode
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 If the CI fails, you can update your changes with `git rebase -i` and push your
branch again: branch again:
@ -970,7 +1017,7 @@ 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 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 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 send-email`, or you can look it up on the
https://public-inbox.org/git[mailing list]. Find your cover letter in 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 archives, click on it, then click "permalink" or "raw" to reveal the Message-Id
header. It should match: header. It should match:

905
Documentation/MyFirstObjectWalk.txt Normal file
View File

@ -0,0 +1,905 @@
= 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"
int cmd_walken(int argc, const char **argv, const char *prefix)
{
trace_printf(_("cmd_walken incoming...\n"));
return 0;
}
----
NOTE: `trace_printf()` 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).
----
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 `cache.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.
For our first example within `git walken`, we don't intend to use any other
components within Git, and we don't have any configuration to do. However, we
may want to add some later, so for now, we can add an empty placeholder. Create
a new function in `builtin/walken.c`:
----
static void init_walken_defaults(void)
{
/*
* We don't actually need the same components `git log` does; leave this
* empty for now.
*/
}
----
Make sure to add a line invoking it inside of `cmd_walken()`.
----
int cmd_walken(int argc, const char **argv, const char *prefix)
{
init_walken_defaults();
}
----
==== 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`:
----
static int git_walken_config(const char *var, const char *value, void *cb)
{
/*
* For now, we don't have any custom configuration, so fall back to
* the default config.
*/
return git_default_config(var, value, 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:
----
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()`:
----
static void walken_commit_walk(struct rev_info *rev)
{
struct commit *commit;
struct strbuf prettybuf = STRBUF_INIT;
...
while ((commit = get_revision(rev))) {
if (!commit)
continue;
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 `init_grep_defaults()` to `init_walken_defaults()` and add
`grep_config()` to `git_walken_config()`:
----
static void init_walken_defaults(void)
{
init_grep_defaults(the_repository);
}
...
static int git_walken_config(const char *var, const char *value, void *cb)
{
grep_config(var, value, cb);
return git_default_config(var, value, 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 `builtins/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_filtered()`, which are a superset of the
arguments to the unfiltered version.
- `struct list_objects_filter_options *filter_options`: This is a struct which
stores a filter-spec as outlined in `Documentation/rev-list-options.txt`.
- `struct rev_info *revs`: This is the `rev_info` used for the walk.
- `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`.
- `struct oidset *omitted`: A linked-list of object IDs which the provided
filter caused to be omitted.
It looks like this `traverse_commit_list_filtered()` uses 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()`:
----
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.)
First, we'll need to `#include "list-objects-filter-options.h`" and set up the
`struct list_objects_filter_options` at the top of the function.
----
static void walken_object_walk(struct rev_info *rev)
{
struct list_objects_filter_options filter_options = {};
...
----
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. Replace 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"));
traverse_commit_list(rev, walken_show_commit,
walken_show_object, NULL);
} else {
trace_printf(
_("Filtered object walk with filterspec 'tree:1'.\n"));
parse_list_objects_filter(&filter_options, "tree:1");
traverse_commit_list_filtered(&filter_options, rev,
walken_show_commit, walken_show_object, NULL, NULL);
}
----
`struct list_objects_filter_options` 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`. Asking
`traverse_commit_list_filtered()` to populate the `omitted` list means that our
object walk does not perform any better than an unfiltered object walk; all
reachable objects are walked in order to populate the list.
First, add the `struct oidset` and related items we will use to iterate it:
----
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);
...
----
Modify the call to `traverse_commit_list_filtered()` to include your `omitted`
object:
----
...
traverse_commit_list_filtered(&filter_options, 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:
----
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 | 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 | 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

4
Documentation/RelNotes/1.5.0.txt
View File

@ -251,7 +251,7 @@ Updates in v1.5.0 since v1.4.4 series
the repository when that happens. the repository when that happens.
* Crufts removal * Cruft removal
- We used to say "old commits are retrievable using reflog and - We used to say "old commits are retrievable using reflog and
'master@{yesterday}' syntax as long as you haven't run 'master@{yesterday}' syntax as long as you haven't run
@ -379,7 +379,7 @@ Updates in v1.5.0 since v1.4.4 series
- The value of i18n.commitencoding in the originating - The value of i18n.commitencoding in the originating
repository is recorded in the commit object on the "encoding" repository is recorded in the commit object on the "encoding"
header, if it is not UTF-8. git-log and friends notice this, header, if it is not UTF-8. git-log and friends notice this,
and reencodes the message to the log output encoding when and re-encodes the message to the log output encoding when
displaying, if they are different. The log output encoding displaying, if they are different. The log output encoding
is determined by "git log --encoding=<encoding>", is determined by "git log --encoding=<encoding>",
i18n.logoutputencoding configuration, or i18n.commitencoding i18n.logoutputencoding configuration, or i18n.commitencoding

2
Documentation/RelNotes/1.6.2.txt
View File

@ -11,7 +11,7 @@ push running this release will issue a big warning when the
configuration variable is missing. Please refer to: configuration variable is missing. Please refer to:
http://git.or.cz/gitwiki/GitFaq#non-bare http://git.or.cz/gitwiki/GitFaq#non-bare
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007 https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/
for more details on the reason why this change is needed and the for more details on the reason why this change is needed and the
transition plan. transition plan.

2
Documentation/RelNotes/1.6.3.txt
View File

@ -11,7 +11,7 @@ push running this release will issue a big warning when the
configuration variable is missing. Please refer to: configuration variable is missing. Please refer to:
http://git.or.cz/gitwiki/GitFaq#non-bare http://git.or.cz/gitwiki/GitFaq#non-bare
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007 https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/
for more details on the reason why this change is needed and the for more details on the reason why this change is needed and the
transition plan. transition plan.

2
Documentation/RelNotes/1.6.4.txt
View File

@ -11,7 +11,7 @@ push running this release will issue a big warning when the
configuration variable is missing. Please refer to: configuration variable is missing. Please refer to:
http://git.or.cz/gitwiki/GitFaq#non-bare http://git.or.cz/gitwiki/GitFaq#non-bare
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007 https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/
for more details on the reason why this change is needed and the for more details on the reason why this change is needed and the
transition plan. transition plan.

2
Documentation/RelNotes/1.6.5.4.txt
View File

@ -10,7 +10,7 @@ Fixes since v1.6.5.3
* "git prune-packed" gave progress output even when its standard error is * "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 not connected to a terminal; this caused cron jobs that run it to
produce crufts. produce cruft.
* "git pack-objects --all-progress" is an option to ask progress output * "git pack-objects --all-progress" is an option to ask progress output
from write-object phase _if_ progress output were to be produced, and from write-object phase _if_ progress output were to be produced, and

2
Documentation/RelNotes/1.6.5.txt
View File

@ -22,7 +22,7 @@ push running this release will issue a big warning when the
configuration variable is missing. Please refer to: configuration variable is missing. Please refer to:
http://git.or.cz/gitwiki/GitFaq#non-bare http://git.or.cz/gitwiki/GitFaq#non-bare
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007 https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/
for more details on the reason why this change is needed and the for more details on the reason why this change is needed and the
transition plan. transition plan.

2
Documentation/RelNotes/1.6.6.txt
View File

@ -64,7 +64,7 @@ users will fare this time.
Please refer to: Please refer to:
http://git.or.cz/gitwiki/GitFaq#non-bare http://git.or.cz/gitwiki/GitFaq#non-bare
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007 https://lore.kernel.org/git/7vbptlsuyv.fsf@gitster.siamese.dyndns.org/
for more details on the reason why this change is needed and the for more details on the reason why this change is needed and the
transition process that already took place so far. transition process that already took place so far.

2
Documentation/RelNotes/1.7.0.2.txt
View File

@ -34,7 +34,7 @@ Fixes since v1.7.0.1
* "git status" in 1.7.0 lacked the optimization we used to have in 1.6.X series * "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. to speed up scanning of large working tree.
* "gitweb" did not diagnose parsing errors properly while reading tis configuration * "gitweb" did not diagnose parsing errors properly while reading its configuration
file. file.
And other minor fixes and documentation updates. And other minor fixes and documentation updates.

2
Documentation/RelNotes/1.7.10.4.txt
View File

@ -7,7 +7,7 @@ Fixes since v1.7.10.3
* The message file for Swedish translation has been updated a bit. * The message file for Swedish translation has been updated a bit.
* A name taken from mailmap was copied into an internal buffer * A name taken from mailmap was copied into an internal buffer
incorrectly and could overun the buffer if it is too long. incorrectly and could overrun the buffer if it is too long.
* A malformed commit object that has a header line chomped in the * A malformed commit object that has a header line chomped in the
middle could kill git with a NULL pointer dereference. middle could kill git with a NULL pointer dereference.

2
Documentation/RelNotes/1.7.12.3.txt
View File

@ -25,7 +25,7 @@ Fixes since v1.7.12.2
its Accept-Encoding header. its Accept-Encoding header.
* "git receive-pack" (the counterpart to "git push") did not give * "git receive-pack" (the counterpart to "git push") did not give
progress output while processing objects it received to the puser progress output while processing objects it received to the user
when run over the smart-http protocol. when run over the smart-http protocol.
* "git status" honored the ignore=dirty settings in .gitmodules but * "git status" honored the ignore=dirty settings in .gitmodules but

2
Documentation/RelNotes/1.7.5.3.txt
View File

@ -22,7 +22,7 @@ Fixes since v1.7.5.2
* "git log --stdin path" with an input that has additional pathspec * "git log --stdin path" with an input that has additional pathspec
used to corrupt memory. used to corrupt memory.
* "git send-pack" (hence "git push") over smalt-HTTP protocol could * "git send-pack" (hence "git push") over smart-HTTP protocol could
deadlock when the client side pack-object died early. deadlock when the client side pack-object died early.
* Compressed tarball gitweb generates used to be made with the timestamp * Compressed tarball gitweb generates used to be made with the timestamp

2
Documentation/RelNotes/1.8.0.txt
View File

@ -233,7 +233,7 @@ to them for details).
together, misdetected branches. together, misdetected branches.
* "git receive-pack" (the counterpart to "git push") did not give * "git receive-pack" (the counterpart to "git push") did not give
progress output while processing objects it received to the puser progress output while processing objects it received to the user
when run over the smart-http protocol. when run over the smart-http protocol.
* When you misspell the command name you give to the "exec" action in * When you misspell the command name you give to the "exec" action in

2
Documentation/RelNotes/1.8.4.1.txt
View File

@ -15,7 +15,7 @@ Fixes since v1.8.4
in 1.8.4-rc1). in 1.8.4-rc1).
* "git rebase -i" and other scripted commands were feeding a * "git rebase -i" and other scripted commands were feeding a
random, data dependant error message to 'echo' and expecting it random, data dependent error message to 'echo' and expecting it
to come out literally. to come out literally.
* Setting the "submodule.<name>.path" variable to the empty * Setting the "submodule.<name>.path" variable to the empty

2
Documentation/RelNotes/1.8.4.txt
View File

@ -58,7 +58,7 @@ Foreign interfaces, subsystems and ports.
credential helper interface from Git.pm. credential helper interface from Git.pm.
* Update build for Cygwin 1.[57]. Torsten Bögershausen reports that * Update build for Cygwin 1.[57]. Torsten Bögershausen reports that
this is fine with Cygwin 1.7 ($gmane/225824) so let's try moving it this is fine with Cygwin 1.7 (cf. <51A606A0.5060101@web.de>) so let's try moving it
ahead. ahead.
* The credential helper to talk to keychain on OS X (in contrib/) has * The credential helper to talk to keychain on OS X (in contrib/) has

2
Documentation/RelNotes/2.1.3.txt
View File

@ -13,7 +13,7 @@ Git v2.1.3 Release Notes
they are new enough to support the `--output` option. they are new enough to support the `--output` option.
* "git pack-objects" forgot to disable the codepath to generate * "git pack-objects" forgot to disable the codepath to generate
object recheability bitmap when it needs to split the resulting object reachability bitmap when it needs to split the resulting
pack. pack.
* "gitweb" used deprecated CGI::startfrom, which was removed from * "gitweb" used deprecated CGI::startfrom, which was removed from

2
Documentation/RelNotes/2.10.0.txt
View File

@ -478,7 +478,7 @@ notes for details).
* One part of "git am" had an oddball helper function that called * One part of "git am" had an oddball helper function that called
stuff from outside "his" as opposed to calling what we have "ours", stuff from outside "his" as opposed to calling what we have "ours",
which was not gender-neutral and also inconsistent with the rest of which was not gender-neutral and also inconsistent with the rest of
the system where outside stuff is usuall called "theirs" in the system where outside stuff is usually called "theirs" in
contrast to "ours". contrast to "ours".
* "git blame file" allowed the lineage of lines in the uncommitted, * "git blame file" allowed the lineage of lines in the uncommitted,

2
Documentation/RelNotes/2.10.2.txt
View File

@ -86,7 +86,7 @@ Fixes since v2.10.1
by refusing to check out a branch that is already checked out in by refusing to check out a branch that is already checked out in
another worktree. However, this also prevented checking out a another worktree. However, this also prevented checking out a
branch, which is designated as the primary branch of a bare branch, which is designated as the primary branch of a bare
reopsitory, in a worktree that is connected to the bare repository, in a worktree that is connected to the bare
repository. The check has been corrected to allow it. repository. The check has been corrected to allow it.
* "git rebase" immediately after "git clone" failed to find the fork * "git rebase" immediately after "git clone" failed to find the fork

2
Documentation/RelNotes/2.11.1.txt
View File

@ -104,7 +104,7 @@ Fixes since v2.11
"git difftool --dir-diff" from a subdirectory never worked. This "git difftool --dir-diff" from a subdirectory never worked. This
has been fixed. has been fixed.
* "git p4" that tracks multile p4 paths imported a single changelist * "git p4" that tracks multiple p4 paths imported a single changelist
that touches files in these multiple paths as one commit, followed that touches files in these multiple paths as one commit, followed
by many empty commits. This has been fixed. by many empty commits. This has been fixed.

2
Documentation/RelNotes/2.12.0.txt
View File

@ -315,7 +315,7 @@ notes for details).
"git difftool --dir-diff" from a subdirectory never worked. This "git difftool --dir-diff" from a subdirectory never worked. This
has been fixed. has been fixed.
* "git p4" that tracks multile p4 paths imported a single changelist * "git p4" that tracks multiple p4 paths imported a single changelist
that touches files in these multiple paths as one commit, followed that touches files in these multiple paths as one commit, followed
by many empty commits. This has been fixed. by many empty commits. This has been fixed.

2
Documentation/RelNotes/2.13.0.txt
View File

@ -177,7 +177,7 @@ UI, Workflows & Features
been changed to enable "--decorate". been changed to enable "--decorate".
* The output from "git status --short" has been extended to show * The output from "git status --short" has been extended to show
various kinds of dirtyness in submodules differently; instead of to various kinds of dirtiness in submodules differently; instead of to
"M" for modified, 'm' and '?' can be shown to signal changes only "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 to the working tree of the submodule but not the commit that is
checked out. checked out.

4
Documentation/RelNotes/2.13.3.txt
View File

@ -25,7 +25,7 @@ Fixes since v2.13.2
* The code to pick up and execute command alias definition from the * The code to pick up and execute command alias definition from the
configuration used to switch to the top of the working tree and configuration used to switch to the top of the working tree and
then come back when the expanded alias was executed, which was then come back when the expanded alias was executed, which was
unnecessarilyl complex. Attempt to simplify the logic by using the unnecessarily complex. Attempt to simplify the logic by using the
early-config mechanism that does not chdir around. early-config mechanism that does not chdir around.
* "git add -p" were updated in 2.12 timeframe to cope with custom * "git add -p" were updated in 2.12 timeframe to cope with custom
@ -35,7 +35,7 @@ Fixes since v2.13.2
* Fix a recent regression to "git rebase -i" and add tests that would * Fix a recent regression to "git rebase -i" and add tests that would
have caught it and others. have caught it and others.
* An unaligned 32-bit access in pack-bitmap code ahs been corrected. * An unaligned 32-bit access in pack-bitmap code has been corrected.
* Tighten error checks for invalid "git apply" input. * Tighten error checks for invalid "git apply" input.

4
Documentation/RelNotes/2.14.0.txt
View File

@ -141,7 +141,7 @@ Performance, Internal Implementation, Development Support etc.
* Some platforms have ulong that is smaller than time_t, and our * Some platforms have ulong that is smaller than time_t, and our
historical use of ulong for timestamp would mean they cannot historical use of ulong for timestamp would mean they cannot
represent some timestamp that the platform allows. Invent a represent some timestamp that the platform allows. Invent a
separate and dedicated timestamp_t (so that we can distingiuish separate and dedicated timestamp_t (so that we can distinguish
timestamps and a vanilla ulongs, which along is already a good 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 move), and then declare uintmax_t is the type to be used as the
timestamp_t. timestamp_t.
@ -442,7 +442,7 @@ notes for details).
* The code to pick up and execute command alias definition from the * The code to pick up and execute command alias definition from the
configuration used to switch to the top of the working tree and configuration used to switch to the top of the working tree and
then come back when the expanded alias was executed, which was then come back when the expanded alias was executed, which was
unnecessarilyl complex. Attempt to simplify the logic by using the unnecessarily complex. Attempt to simplify the logic by using the
early-config mechanism that does not chdir around. early-config mechanism that does not chdir around.
* Fix configuration codepath to pay proper attention to commondir * Fix configuration codepath to pay proper attention to commondir

54
Documentation/RelNotes/2.14.6.txt Normal file
View File

@ -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.

11
Documentation/RelNotes/2.15.4.txt Normal file
View File

@ -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`.

2
Documentation/RelNotes/2.16.0.txt
View File

@ -407,7 +407,7 @@ Fixes since v2.15
(merge eef3df5a93 bw/pathspec-match-submodule-boundary later to maint). (merge eef3df5a93 bw/pathspec-match-submodule-boundary later to maint).
* Amending commits in git-gui broke the author name that is non-ascii * Amending commits in git-gui broke the author name that is non-ascii
due to incorrect enconding conversion. due to incorrect encoding conversion.
* Recent update to the submodule configuration code broke "diff-tree" * Recent update to the submodule configuration code broke "diff-tree"
by accidentally stopping to read from the index upfront. by accidentally stopping to read from the index upfront.

2
Documentation/RelNotes/2.16.3.txt
View File

@ -24,7 +24,7 @@ Fixes since v2.16.2
* The http tracing code, often used to debug connection issues, * The http tracing code, often used to debug connection issues,
learned to redact potentially sensitive information from its output learned to redact potentially sensitive information from its output
so that it can be more safely sharable. so that it can be more safely shareable.
* Crash fix for a corner case where an error codepath tried to unlock * Crash fix for a corner case where an error codepath tried to unlock
what it did not acquire lock on. what it did not acquire lock on.

8
Documentation/RelNotes/2.16.6.txt Normal file
View File

@ -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.

2
Documentation/RelNotes/2.17.0.txt
View File

@ -216,7 +216,7 @@ Fixes since v2.16
* The http tracing code, often used to debug connection issues, * The http tracing code, often used to debug connection issues,
learned to redact potentially sensitive information from its output learned to redact potentially sensitive information from its output
so that it can be more safely sharable. so that it can be more safely shareable.
(merge 8ba18e6fa4 jt/http-redact-cookies later to maint). (merge 8ba18e6fa4 jt/http-redact-cookies later to maint).
* Crash fix for a corner case where an error codepath tried to unlock * Crash fix for a corner case where an error codepath tried to unlock

12
Documentation/RelNotes/2.17.3.txt Normal file
View File

@ -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.

2
Documentation/RelNotes/2.18.0.txt
View File

@ -179,7 +179,7 @@ Performance, Internal Implementation, Development Support etc.
(merge 00a3da2a13 nd/remove-ignore-env-field later to maint). (merge 00a3da2a13 nd/remove-ignore-env-field later to maint).
* Code to find the length to uniquely abbreviate object names based * Code to find the length to uniquely abbreviate object names based
on packfile content, which is a relatively recent addtion, has been on packfile content, which is a relatively recent addition, has been
optimized to use the same fan-out table. optimized to use the same fan-out table.
* The mechanism to use parse-options API to automate the command line * The mechanism to use parse-options API to automate the command line

8
Documentation/RelNotes/2.18.2.txt Normal file
View File

@ -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.

2
Documentation/RelNotes/2.19.0.txt
View File

@ -106,7 +106,7 @@ Performance, Internal Implementation, Development Support etc.
* The conversion to pass "the_repository" and then "a_repository" * The conversion to pass "the_repository" and then "a_repository"
throughout the object access API continues. throughout the object access API continues.
* Continuing with the idea to programatically enumerate various * Continuing with the idea to programmatically enumerate various
pieces of data required for command line completion, teach the pieces of data required for command line completion, teach the
codebase to report the list of configuration variables codebase to report the list of configuration variables
subcommands care about to help complete them. subcommands care about to help complete them.

8
Documentation/RelNotes/2.19.3.txt Normal file
View File

@ -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.

2
Documentation/RelNotes/2.20.0.txt
View File

@ -119,7 +119,7 @@ UI, Workflows & Features
alias expansion. alias expansion.
* The documentation of "git gc" has been updated to mention that it * The documentation of "git gc" has been updated to mention that it
is no longer limited to "pruning away crufts" but also updates is no longer limited to "pruning away cruft" but also updates
ancillary files like commit-graph as a part of repository ancillary files like commit-graph as a part of repository
optimization. optimization.

18
Documentation/RelNotes/2.20.2.txt Normal file
View File

@ -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.

12
Documentation/RelNotes/2.21.1.txt Normal file
View File

@ -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.

8
Documentation/RelNotes/2.22.2.txt Normal file
View File

@ -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.

8
Documentation/RelNotes/2.23.1.txt Normal file
View File

@ -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.

8
Documentation/RelNotes/2.24.1.txt Normal file
View File

@ -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.

340
Documentation/RelNotes/2.25.0.txt Normal file
View File

@ -0,0 +1,340 @@
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 rebase -i" learned a few options that are known by "git
rebase" proper.
* "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.
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.
* The effort to reimplement "git add -i" in C continues.
* 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.
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).
* 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).

2
Documentation/RelNotes/2.3.3.txt
View File

@ -12,7 +12,7 @@ Fixes since v2.3.2
* Description given by "grep -h" for its --exclude-standard option * Description given by "grep -h" for its --exclude-standard option
was phrased poorly. was phrased poorly.
* Documentaton for "git remote add" mentioned "--tags" and * Documentation for "git remote add" mentioned "--tags" and
"--no-tags" and it was not clear that fetch from the remote in "--no-tags" and it was not clear that fetch from the remote in
the future will use the default behaviour when neither is given the future will use the default behaviour when neither is given
to override it. to override it.

2
Documentation/RelNotes/2.3.7.txt
View File

@ -4,7 +4,7 @@ Git v2.3.7 Release Notes
Fixes since v2.3.6 Fixes since v2.3.6
------------------ ------------------
* An earlier update to the parser that disects a URL broke an * An earlier update to the parser that dissects a URL broke an
address, followed by a colon, followed by an empty string (instead address, followed by a colon, followed by an empty string (instead
of the port number), e.g. ssh://example.com:/path/to/repo. of the port number), e.g. ssh://example.com:/path/to/repo.

2
Documentation/RelNotes/2.4.3.txt
View File

@ -66,7 +66,7 @@ Fixes since v2.4.3
* Some time ago, "git blame" (incorrectly) lost the convert_to_git() * Some time ago, "git blame" (incorrectly) lost the convert_to_git()
call when synthesizing a fake "tip" commit that represents the call when synthesizing a fake "tip" commit that represents the
state in the working tree, which broke folks who record the history state in the working tree, which broke folks who record the history
with LF line ending to make their project portabile across with LF line ending to make their project portable across
platforms while terminating lines in their working tree files with platforms while terminating lines in their working tree files with
CRLF for their platform. CRLF for their platform.

3
Documentation/RelNotes/2.5.0.txt
View File

@ -172,7 +172,8 @@ Performance, Internal Implementation, Development Support etc.
incorrect patch text to "git apply". Add tests to demonstrate incorrect patch text to "git apply". Add tests to demonstrate
this. this.
I have a slight suspicion that this may be $gmane/87202 coming back 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 and biting us (I seem to have said "let's run with this and see
what happens" back then). what happens" back then).

2
Documentation/RelNotes/2.7.0.txt
View File

@ -40,7 +40,7 @@ UI, Workflows & Features
* "git interpret-trailers" can now run outside of a Git repository. * "git interpret-trailers" can now run outside of a Git repository.
* "git p4" learned to reencode the pathname it uses to communicate * "git p4" learned to re-encode the pathname it uses to communicate
with the p4 depot with a new option. with the p4 depot with a new option.
* Give progress meter to "git filter-branch". * Give progress meter to "git filter-branch".

2
Documentation/RelNotes/2.7.3.txt
View File

@ -20,7 +20,7 @@ Fixes since v2.7.2
tests. tests.
* "git show 'HEAD:Foo[BAR]Baz'" did not interpret the argument as a * "git show 'HEAD:Foo[BAR]Baz'" did not interpret the argument as a
rev, i.e. the object named by the the pathname with wildcard rev, i.e. the object named by the pathname with wildcard
characters in a tree object. characters in a tree object.
* "git rev-parse --git-common-dir" used in the worktree feature * "git rev-parse --git-common-dir" used in the worktree feature

2
Documentation/RelNotes/2.8.0.txt
View File

@ -189,7 +189,7 @@ Performance, Internal Implementation, Development Support etc.
* Some calls to strcpy(3) triggers a false warning from static * Some calls to strcpy(3) triggers a false warning from static
analyzers that are less intelligent than humans, and reducing the analyzers that are less intelligent than humans, and reducing the
number of these false hits helps us notice real issues. A few number of these false hits helps us notice real issues. A few
calls to strcpy(3) in a couple of protrams that are already safe calls to strcpy(3) in a couple of programs that are already safe
has been rewritten to avoid false warnings. has been rewritten to avoid false warnings.
* The "name_path" API was an attempt to reduce the need to construct * The "name_path" API was an attempt to reduce the need to construct

4
Documentation/RelNotes/2.8.3.txt
View File

@ -55,8 +55,8 @@ Fixes since v2.8.2
This is necessary to use Git on Windows shared directories, and is This is necessary to use Git on Windows shared directories, and is
already enabled for the MinGW and plain Windows builds. It also already enabled for the MinGW and plain Windows builds. It also
has been used in Cygwin packaged versions of Git for quite a while. has been used in Cygwin packaged versions of Git for quite a while.
See http://thread.gmane.org/gmane.comp.version-control.git/291853 See https://lore.kernel.org/git/20160419091055.GF2345@dinwoodie.org/
and http://thread.gmane.org/gmane.comp.version-control.git/275680. and https://lore.kernel.org/git/20150811100527.GW14466@dinwoodie.org/.
* "git replace -e" did not honour "core.editor" configuration. * "git replace -e" did not honour "core.editor" configuration.

2
Documentation/RelNotes/2.9.0.txt
View File

@ -368,7 +368,7 @@ notes for details).
This is necessary to use Git on Windows shared directories, and is This is necessary to use Git on Windows shared directories, and is
already enabled for the MinGW and plain Windows builds. It also already enabled for the MinGW and plain Windows builds. It also
has been used in Cygwin packaged versions of Git for quite a while. has been used in Cygwin packaged versions of Git for quite a while.
See http://thread.gmane.org/gmane.comp.version-control.git/291853 See https://lore.kernel.org/git/20160419091055.GF2345@dinwoodie.org/
* "merge-octopus" strategy did not ensure that the index is clean * "merge-octopus" strategy did not ensure that the index is clean
when merge begins. when merge begins.

2
Documentation/RelNotes/2.9.3.txt
View File

@ -36,7 +36,7 @@ Fixes since v2.9.2
* One part of "git am" had an oddball helper function that called * One part of "git am" had an oddball helper function that called
stuff from outside "his" as opposed to calling what we have "ours", stuff from outside "his" as opposed to calling what we have "ours",
which was not gender-neutral and also inconsistent with the rest of which was not gender-neutral and also inconsistent with the rest of
the system where outside stuff is usuall called "theirs" in the system where outside stuff is usually called "theirs" in
contrast to "ours". contrast to "ours".
* The test framework learned a new helper test_match_signal to * The test framework learned a new helper test_match_signal to

16
Documentation/SubmittingPatches
View File

@ -142,19 +142,25 @@ archive, summarize the relevant points of the discussion.
[[commit-reference]] [[commit-reference]]
If you want to reference a previous commit in the history of a stable If you want to reference a previous commit in the history of a stable
branch, use the format "abbreviated sha1 (subject, date)", branch, use the format "abbreviated hash (subject, date)", like this:
with the subject enclosed in a pair of double-quotes, like this:
.... ....
Commit f86a374 ("pack-bitmap.c: fix a memleak", 2015-03-30) Commit f86a374 (pack-bitmap.c: fix a memleak, 2015-03-30)
noticed that ... noticed that ...
.... ....
The "Copy commit summary" command of gitk can be used to obtain this The "Copy commit summary" command of gitk can be used to obtain this
format, or this invocation of `git show`: format (with the subject enclosed in a pair of double-quotes), or this
invocation of `git show`:
.... ....
git show -s --date=short --pretty='format:%h ("%s", %ad)' <commit> 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>
.... ....
[[git-tools]] [[git-tools]]

2
Documentation/config.txt
View File

@ -142,7 +142,7 @@ refer to linkgit:gitignore[5] for details. For convenience:
`gitdir/i`:: `gitdir/i`::
This is the same as `gitdir` except that matching is done This is the same as `gitdir` except that matching is done
case-insensitively (e.g. on case-insensitive file sytems) case-insensitively (e.g. on case-insensitive file systems)
`onbranch`:: `onbranch`::
The data that follows the keyword `onbranch:` is taken to be a The data that follows the keyword `onbranch:` is taken to be a

5
Documentation/config/add.txt
View File

@ -5,3 +5,8 @@ add.ignore-errors (deprecated)::
option of linkgit:git-add[1]. `add.ignore-errors` is deprecated, option of linkgit:git-add[1]. `add.ignore-errors` is deprecated,
as it does not follow the usual naming convention for configuration as it does not follow the usual naming convention for configuration
variables. variables.
add.interactive.useBuiltin::
[EXPERIMENTAL] Set to `true` to use the experimental built-in
implementation of the interactive version of linkgit:git-add[1]
instead of the Perl script version. Is `false` by default.

3
Documentation/config/advice.txt
View File

@ -107,4 +107,7 @@ advice.*::
editor input from the user. editor input from the user.
nestedTag:: nestedTag::
Advice shown if a user attempts to recursively tag a tag object. Advice shown if a user attempts to recursively tag a tag object.
submoduleAlternateErrorStrategyDie:
Advice shown when a submodule.alternateErrorStrategy option
configured to "die" causes a fatal error.
-- --

16
Documentation/config/core.txt
View File

@ -559,6 +559,12 @@ core.unsetenvvars::
Defaults to `PERL5LIB` to account for the fact that Git for Defaults to `PERL5LIB` to account for the fact that Git for
Windows insists on using its own Perl interpreter. Windows insists on using its own Perl interpreter.
core.restrictinheritedhandles::
Windows-only: override whether spawned processes inherit only standard
file handles (`stdin`, `stdout` and `stderr`) or all handles. Can be
`auto`, `true` or `false`. Defaults to `auto`, which means `true` on
Windows 7 and later, and `false` on older Windows versions.
core.createObject:: core.createObject::
You can set this to 'link', in which case a hardlink followed by You can set this to 'link', in which case a hardlink followed by
a delete of the source are used to make sure that object creation a delete of the source are used to make sure that object creation
@ -593,8 +599,14 @@ core.multiPackIndex::
multi-pack-index design document]. multi-pack-index design document].
core.sparseCheckout:: core.sparseCheckout::
Enable "sparse checkout" feature. See section "Sparse checkout" in Enable "sparse checkout" feature. See linkgit:git-sparse-checkout[1]
linkgit:git-read-tree[1] for more information. for more information.
core.sparseCheckoutCone::
Enables the "cone mode" of the sparse checkout feature. When the
sparse-checkout file contains a limited set of patterns, then this
mode provides significant performance advantages. See
linkgit:git-sparse-checkout[1] for more information.
core.abbrev:: core.abbrev::
Set the length object names are abbreviated to. If Set the length object names are abbreviated to. If

24
Documentation/config/format.txt
View File

@ -36,6 +36,12 @@ format.subjectPrefix::
The default for format-patch is to output files with the '[PATCH]' The default for format-patch is to output files with the '[PATCH]'
subject prefix. Use this variable to change that prefix. subject prefix. Use this variable to change that prefix.
format.coverFromDescription::
The default mode for format-patch to determine which parts of
the cover letter will be populated using the branch's
description. See the `--cover-from-description` option in
linkgit:git-format-patch[1].
format.signature:: format.signature::
The default for format-patch is to output a signature containing The default for format-patch is to output a signature containing
the Git version number. Use this variable to change that default. the Git version number. Use this variable to change that default.
@ -100,4 +106,20 @@ If one wishes to use the ref `ref/notes/true`, please use that literal
instead. instead.
+ +
This configuration can be specified multiple times in order to allow This configuration can be specified multiple times in order to allow
multiple notes refs to be included. multiple notes refs to be included. In that case, it will behave
similarly to multiple `--[no-]notes[=]` options passed in. That is, a
value of `true` will show the default notes, a value of `<ref>` will
also show notes from that notes ref and a value of `false` will negate
previous configurations and not show notes.
+
For example,
+
------------
[format]
notes = true
notes = foo
notes = false
notes = bar
------------
+
will only show notes from `refs/notes/bar`.

4
Documentation/config/submodule.txt
View File

@ -79,4 +79,6 @@ submodule.alternateLocation::
submodule.alternateErrorStrategy:: submodule.alternateErrorStrategy::
Specifies how to treat errors with the alternates for a submodule Specifies how to treat errors with the alternates for a submodule
as computed via `submodule.alternateLocation`. Possible values are as computed via `submodule.alternateLocation`. Possible values are
`ignore`, `info`, `die`. Default is `die`. `ignore`, `info`, `die`. Default is `die`. Note that if set to `ignore`
or `info`, and if there is an error with the computed alternate, the
clone proceeds as if no alternate was specified.

2
Documentation/config/tag.txt
View File

@ -13,7 +13,7 @@ tag.gpgSign::
Use of this option when running in an automated script can Use of this option when running in an automated script can
result in a large number of tags being signed. It is therefore result in a large number of tags being signed. It is therefore
convenient to use an agent to avoid typing your gpg passphrase convenient to use an agent to avoid typing your gpg passphrase
several times. Note that this option doesn't affects tag signing several times. Note that this option doesn't affect tag signing
behavior enabled by "-u <keyid>" or "--local-user=<keyid>" options. behavior enabled by "-u <keyid>" or "--local-user=<keyid>" options.
tar.umask:: tar.umask::

2
Documentation/diff-format.txt
View File

@ -61,7 +61,7 @@ Possible status letters are:
- R: renaming of a file - R: renaming of a file
- T: change in the type of the file - T: change in the type of the file
- U: file is unmerged (you must complete the merge before it can - U: file is unmerged (you must complete the merge before it can
be committed) be committed)
- X: "unknown" change type (most probably a bug, please report it) - X: "unknown" change type (most probably a bug, please report it)
Status letters C and R are always followed by a score (denoting the Status letters C and R are always followed by a score (denoting the

4
Documentation/fetch-options.txt
View File

@ -92,6 +92,10 @@ ifndef::git-pull[]
Run `git gc --auto` at the end to perform garbage collection Run `git gc --auto` at the end to perform garbage collection
if needed. This is enabled by default. if needed. This is enabled by default.
--[no-]write-commit-graph::
Write a commit-graph after fetching. This overrides the config
setting `fetch.writeCommitGraph`.
-p:: -p::
--prune:: --prune::
Before fetching, remove any remote-tracking references that no Before fetching, remove any remote-tracking references that no

16
Documentation/git-add.txt
View File

@ -11,7 +11,8 @@ SYNOPSIS
'git add' [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p] 'git add' [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p]
[--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]] [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]]
[--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--renormalize] [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--renormalize]
[--chmod=(+|-)x] [--] [<pathspec>...] [--chmod=(+|-)x] [--pathspec-from-file=<file> [--pathspec-file-nul]]
[--] [<pathspec>...]
DESCRIPTION DESCRIPTION
----------- -----------
@ -187,6 +188,19 @@ for "git add --no-all <pathspec>...", i.e. ignored removed files.
bit is only changed in the index, the files on disk are left bit is only changed in the index, the files on disk are left
unchanged. 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 This option can be used to separate command-line options from
the list of files, (useful when filenames might be mistaken the list of files, (useful when filenames might be mistaken

2
Documentation/git-am.txt
View File

@ -177,7 +177,7 @@ default. You can use `--no-utf8` to override this.
untouched. untouched.
--show-current-patch:: --show-current-patch::
Show the patch being applied when "git am" is stopped because Show the entire e-mail message "git am" has stopped at, because
of conflicts. of conflicts.
DISCUSSION DISCUSSION

6
Documentation/git-bisect-lk2009.txt
View File

@ -158,7 +158,7 @@ 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 supposed to be used so that all the tests are checked after each
commit. This means that they are not very efficient, because many commit. This means that they are not very efficient, because many
tests are run for no interesting result, and they suffer from tests are run for no interesting result, and they suffer from
combinational explosion. combinatorial explosion.
In fact the problem is that big software often has many different In fact the problem is that big software often has many different
configuration options and that each test case should pass for each configuration options and that each test case should pass for each
@ -1350,9 +1350,9 @@ References
- [[[1]]] https://www.nist.gov/sites/default/files/documents/director/planning/report02-3.pdf['The Economic Impacts of Inadequate Infratructure for Software Testing'. Nist Planning Report 02-3], see Executive Summary and Chapter 8. - [[[1]]] https://www.nist.gov/sites/default/files/documents/director/planning/report02-3.pdf['The Economic Impacts of Inadequate Infratructure for Software Testing'. Nist Planning Report 02-3], see Executive Summary and Chapter 8.
- [[[2]]] http://www.oracle.com/technetwork/java/codeconvtoc-136057.html['Code Conventions for the Java Programming Language'. Sun Microsystems.] - [[[2]]] http://www.oracle.com/technetwork/java/codeconvtoc-136057.html['Code Conventions for the Java Programming Language'. Sun Microsystems.]
- [[[3]]] https://en.wikipedia.org/wiki/Software_maintenance['Software maintenance'. Wikipedia.] - [[[3]]] https://en.wikipedia.org/wiki/Software_maintenance['Software maintenance'. Wikipedia.]
- [[[4]]] https://public-inbox.org/git/7vps5xsbwp.fsf_-_@assigned-by-dhcp.cox.net/[Junio C Hamano. 'Automated bisect success story'.] - [[[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.] - [[[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.] - [[[6]]] https://lwn.net/Articles/277872/[Jonathan Corbet. 'Bisection divides users and developers'. LWN.net.]
- [[[7]]] http://marc.info/?l=linux-kernel&m=119702753411680&w=2[Ingo Molnar. 'Re: BUG 2.6.23-rc3 can't see sd partitions on Alpha'. Linux-kernel mailing list.] - [[[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.] - [[[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.] - [[[9]]] https://github.com/Ealdwulf/bbchop[Ealdwulf. 'bbchop'. GitHub.]

2
Documentation/git-bisect.txt
View File

@ -413,7 +413,7 @@ $ cat ~/test.sh
# tweak the working tree by merging the hot-fix branch # tweak the working tree by merging the hot-fix branch
# and then attempt a build # and then attempt a build
if git merge --no-commit hot-fix && if git merge --no-commit --no-ff hot-fix &&
make make
then then
# run project specific test and report its status # run project specific test and report its status

58
Documentation/git-bundle.txt
View File

@ -9,8 +9,8 @@ git-bundle - Move objects and refs by archive
SYNOPSIS SYNOPSIS
-------- --------
[verse] [verse]
'git bundle' create <file> <git-rev-list-args> 'git bundle' create [-q | --quiet | --progress | --all-progress] [--all-progress-implied] <file> <git-rev-list-args>
'git bundle' verify <file> 'git bundle' verify [-q | --quiet] <file>
'git bundle' list-heads <file> [<refname>...] 'git bundle' list-heads <file> [<refname>...]
'git bundle' unbundle <file> [<refname>...] 'git bundle' unbundle <file> [<refname>...]
@ -20,11 +20,14 @@ DESCRIPTION
Some workflows require that one or more branches of development on one Some workflows require that one or more branches of development on one
machine be replicated on another machine, but the two machines cannot machine be replicated on another machine, but the two machines cannot
be directly connected, and therefore the interactive Git protocols (git, be directly connected, and therefore the interactive Git protocols (git,
ssh, http) cannot be used. This command provides support for ssh, http) cannot be used.
'git fetch' and 'git pull' to operate by packaging objects and references
in an archive at the originating machine, then importing those into The 'git bundle' command packages objects and references in an archive
another repository using 'git fetch' and 'git pull' at the originating machine, which can then be imported into another
after moving the archive by some means (e.g., by sneakernet). As no repository using 'git fetch', 'git pull', or 'git clone',
after moving the archive by some means (e.g., by sneakernet).
As no
direct connection between the repositories exists, the user must specify a direct connection between the repositories exists, the user must specify a
basis for the bundle that is held by the destination repository: the basis for the bundle that is held by the destination repository: the
bundle assumes that all objects in the basis are already in the bundle assumes that all objects in the basis are already in the
@ -33,9 +36,11 @@ destination repository.
OPTIONS OPTIONS
------- -------
create <file>:: create [options] <file> <git-rev-list-args>::
Used to create a bundle named 'file'. This requires the Used to create a bundle named 'file'. This requires the
'git-rev-list-args' arguments to define the bundle contents. '<git-rev-list-args>' arguments to define the bundle contents.
'options' contains the options specific to the 'git bundle create'
subcommand.
verify <file>:: verify <file>::
Used to check that a bundle file is valid and will apply Used to check that a bundle file is valid and will apply
@ -75,6 +80,33 @@ unbundle <file>::
necessarily everything in the pack (in this case, 'git bundle' acts necessarily everything in the pack (in this case, 'git bundle' acts
like 'git fetch-pack'). 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.
--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::
--quiet::
This flag makes the command not to report its progress
on the standard error stream.
SPECIFYING REFERENCES SPECIFYING REFERENCES
--------------------- ---------------------
@ -92,6 +124,14 @@ 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 to contain objects already in the destination, as these are ignored
when unpacking at the destination. when unpacking at the destination.
`git clone` can use any bundle created without negative refspecs
(e.g., `new`, but not `old..new`).
If you want to match `git clone --mirror`, which would include your
refs such as `refs/remotes/*`, use `--all`.
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>`.
EXAMPLES EXAMPLES
-------- --------

2
Documentation/git-check-attr.txt
View File

@ -32,7 +32,7 @@ OPTIONS
instead of from the command-line. instead of from the command-line.
-z:: -z::
The output format is modified to be machine-parseable. The output format is modified to be machine-parsable.
If `--stdin` is also given, input paths are separated If `--stdin` is also given, input paths are separated
with a NUL character instead of a linefeed character. with a NUL character instead of a linefeed character.

2
Documentation/git-check-ignore.txt
View File

@ -39,7 +39,7 @@ OPTIONS
instead of from the command-line. instead of from the command-line.
-z:: -z::
The output format is modified to be machine-parseable (see The output format is modified to be machine-parsable (see
below). If `--stdin` is also given, input paths are separated below). If `--stdin` is also given, input paths are separated
with a NUL character instead of a linefeed character. with a NUL character instead of a linefeed character.

50
Documentation/git-checkout.txt
View File

@ -12,14 +12,14 @@ SYNOPSIS
'git checkout' [-q] [-f] [-m] --detach [<branch>] 'git checkout' [-q] [-f] [-m] --detach [<branch>]
'git checkout' [-q] [-f] [-m] [--detach] <commit> 'git checkout' [-q] [-f] [-m] [--detach] <commit>
'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>] 'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>... 'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <pathspec>...
'git checkout' [<tree-ish>] [--] <pathspec>... 'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] --pathspec-from-file=<file> [--pathspec-file-nul]
'git checkout' (-p|--patch) [<tree-ish>] [--] [<paths>...] 'git checkout' (-p|--patch) [<tree-ish>] [--] [<pathspec>...]
DESCRIPTION DESCRIPTION
----------- -----------
Updates files in the working tree to match the version in the index Updates files in the working tree to match the version in the index
or the specified tree. If no paths are given, 'git checkout' will or the specified tree. If no pathspec was given, 'git checkout' will
also update `HEAD` to set the specified branch as the current also update `HEAD` to set the specified branch as the current
branch. branch.
@ -79,13 +79,14 @@ be used to detach `HEAD` at the tip of the branch (`git checkout
+ +
Omitting `<branch>` detaches `HEAD` at the tip of the current branch. Omitting `<branch>` detaches `HEAD` at the tip of the current branch.
'git checkout' [<tree-ish>] [--] <pathspec>...:: '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 paths in the working tree by replacing with the Overwrite the contents of the files that match the pathspec.
contents in the index or in the `<tree-ish>` (most often a When the `<tree-ish>` (most often a commit) is not given,
commit). When a `<tree-ish>` is given, the paths that overwrite working tree with the contents in the index.
match the `<pathspec>` are updated both in the index and in When the `<tree-ish>` is given, overwrite both the index and
the working tree. the working tree with the contents at the `<tree-ish>`.
+ +
The index may contain unmerged entries because of a previous failed merge. 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 By default, if you try to check out such an entry from the index, the
@ -96,12 +97,10 @@ using `--ours` or `--theirs`. With `-m`, changes made to the working tree
file can be discarded to re-create the original conflicted merge result. file can be discarded to re-create the original conflicted merge result.
'git checkout' (-p|--patch) [<tree-ish>] [--] [<pathspec>...]:: 'git checkout' (-p|--patch) [<tree-ish>] [--] [<pathspec>...]::
This is similar to the "check out paths to the working tree This is similar to the previous mode, but lets you use the
from either the index or from a tree-ish" mode described interactive interface to show the "diff" output and choose which
above, but lets you use the interactive interface to show hunks to use in the result. See below for the description of
the "diff" output and choose which hunks to use in the `--patch` option.
result. See below for the description of `--patch` option.
OPTIONS OPTIONS
------- -------
@ -309,6 +308,19 @@ Note that this option uses the no overlay mode by default (see also
working tree, but not in `<tree-ish>` are removed, to make them working tree, but not in `<tree-ish>` are removed, to make them
match `<tree-ish>` exactly. 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>::
Branch to checkout; if it refers to a branch (i.e., a name that, 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 when prepended with "refs/heads/", is a valid ref), then that
@ -339,7 +351,13 @@ leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.
Tree to checkout from (when paths are given). If not specified, Tree to checkout from (when paths are given). If not specified,
the index will be used. the index will be used.
\--::
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 DETACHED HEAD
------------- -------------

12
Documentation/git-clone.txt
View File

@ -15,7 +15,7 @@ SYNOPSIS
[--dissociate] [--separate-git-dir <git dir>] [--dissociate] [--separate-git-dir <git dir>]
[--depth <depth>] [--[no-]single-branch] [--no-tags] [--depth <depth>] [--[no-]single-branch] [--no-tags]
[--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules] [--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules]
[--[no-]remote-submodules] [--jobs <n>] [--] <repository> [--[no-]remote-submodules] [--jobs <n>] [--sparse] [--] <repository>
[<directory>] [<directory>]
DESCRIPTION DESCRIPTION
@ -156,6 +156,12 @@ objects from the source repository into a pack in the cloned repository.
used, neither remote-tracking branches nor the related used, neither remote-tracking branches nor the related
configuration variables are created. configuration variables are created.
--sparse::
Initialize the sparse-checkout file so the working
directory starts with only the files in the root
of the repository. The sparse-checkout file can be
modified to grow the working directory as needed.
--mirror:: --mirror::
Set up a mirror of the source repository. This implies `--bare`. Set up a mirror of the source repository. This implies `--bare`.
Compared to `--bare`, `--mirror` not only maps local branches of the Compared to `--bare`, `--mirror` not only maps local branches of the
@ -262,9 +268,9 @@ or `--mirror` is given)
All submodules which are cloned will be shallow with a depth of 1. All submodules which are cloned will be shallow with a depth of 1.
--[no-]remote-submodules:: --[no-]remote-submodules::
All submodules which are cloned will use the status of the submodule’s All submodules which are cloned will use the status of the submodule's
remote-tracking branch to update the submodule, rather than the remote-tracking branch to update the submodule, rather than the
superproject’s recorded SHA-1. Equivalent to passing `--remote` to superproject's recorded SHA-1. Equivalent to passing `--remote` to
`git submodule update`. `git submodule update`.
--separate-git-dir=<git dir>:: --separate-git-dir=<git dir>::

12
Documentation/git-commit-graph.txt
View File

@ -9,7 +9,6 @@ git-commit-graph - Write and verify Git commit-graph files
SYNOPSIS SYNOPSIS
-------- --------
[verse] [verse]
'git commit-graph read' [--object-dir <dir>]
'git commit-graph verify' [--object-dir <dir>] [--shallow] [--[no-]progress] 'git commit-graph verify' [--object-dir <dir>] [--shallow] [--[no-]progress]
'git commit-graph write' <options> [--object-dir <dir>] [--[no-]progress] 'git commit-graph write' <options> [--object-dir <dir>] [--[no-]progress]
@ -74,11 +73,6 @@ Finally, if `--expire-time=<datetime>` is not specified, let `datetime`
be the current time. After writing the split commit-graph, delete all be the current time. After writing the split commit-graph, delete all
unused commit-graph whose modified times are older than `datetime`. unused commit-graph whose modified times are older than `datetime`.
'read'::
Read the commit-graph file and output basic details about it.
Used for debugging purposes.
'verify':: 'verify'::
Read the commit-graph file and verify its contents against the object Read the commit-graph file and verify its contents against the object
@ -118,12 +112,6 @@ $ git show-ref -s | git commit-graph write --stdin-commits
$ git rev-parse HEAD | git commit-graph write --stdin-commits --append $ git rev-parse HEAD | git commit-graph write --stdin-commits --append
------------------------------------------------ ------------------------------------------------
* Read basic information from the commit-graph file.
+
------------------------------------------------
$ git commit-graph read
------------------------------------------------
GIT GIT
--- ---

29
Documentation/git-commit.txt
View File

@ -13,7 +13,8 @@ SYNOPSIS
[-F <file> | -m <msg>] [--reset-author] [--allow-empty] [-F <file> | -m <msg>] [--reset-author] [--allow-empty]
[--allow-empty-message] [--no-verify] [-e] [--author=<author>] [--allow-empty-message] [--no-verify] [-e] [--author=<author>]
[--date=<date>] [--cleanup=<mode>] [--[no-]status] [--date=<date>] [--cleanup=<mode>] [--[no-]status]
[-i | -o] [-S[<keyid>]] [--] [<file>...] [-i | -o] [--pathspec-from-file=<file> [--pathspec-file-nul]]
[-S[<keyid>]] [--] [<pathspec>...]
DESCRIPTION DESCRIPTION
----------- -----------
@ -278,6 +279,19 @@ FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
already been staged. If used together with `--allow-empty` already been staged. If used together with `--allow-empty`
paths are also not required, and an empty commit will be created. paths are also not required, and an empty commit will be created.
--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).
-u[<mode>]:: -u[<mode>]::
--untracked-files[=<mode>]:: --untracked-files[=<mode>]::
Show untracked files. Show untracked files.
@ -345,12 +359,13 @@ changes to tracked files.
\--:: \--::
Do not interpret any more arguments as options. Do not interpret any more arguments as options.
<file>...:: <pathspec>...::
When files are given on the command line, the command When pathspec is given on the command line, commit the contents of
commits the contents of the named files, without the files that match the pathspec without recording the changes
recording the changes already staged. The contents of already added to the index. The contents of these files are also
these files are also staged for the next commit on top staged for the next commit on top of what have been staged before.
of what have been staged before. +
For more details, see the 'pathspec' entry in linkgit:gitglossary[7].
:git-commit: 1 :git-commit: 1
include::date-formats.txt[] include::date-formats.txt[]

3
Documentation/git-credential.txt
View File

@ -19,8 +19,7 @@ from system-specific helpers, as well as prompting the user for
usernames and passwords. The git-credential command exposes this usernames and passwords. The git-credential command exposes this
interface to scripts which may want to retrieve, store, or prompt for interface to scripts which may want to retrieve, store, or prompt for
credentials in the same manner as Git. The design of this scriptable credentials in the same manner as Git. The design of this scriptable
interface models the internal C API; see interface models the internal C API; see credential.h for more
link:technical/api-credentials.html[the Git credential API] for more
background on the concepts. background on the concepts.
git-credential takes an "action" option on the command-line (one of git-credential takes an "action" option on the command-line (one of

2
Documentation/git-cvsserver.txt
View File

@ -294,7 +294,7 @@ In `dbDriver` and `dbUser` you can use the following variables:
Git directory name Git directory name
%g:: %g::
Git directory name, where all characters except for Git directory name, where all characters except for
alpha-numeric ones, `.`, and `-` are replaced with alphanumeric ones, `.`, and `-` are replaced with
`_` (this should make it easier to use the directory `_` (this should make it easier to use the directory
name in a filename if wanted) name in a filename if wanted)
%m:: %m::

2
Documentation/git-diff.txt
View File

@ -36,7 +36,7 @@ two blob objects, or changes between two files on disk.
running the command in a working tree controlled by Git and running the command in a working tree controlled by Git and
at least one of the paths points outside the working tree, at least one of the paths points outside the working tree,
or when running the command outside a working tree or when running the command outside a working tree
controlled by Git. controlled by Git. This form implies `--exit-code`.
'git diff' [<options>] --cached [<commit>] [--] [<path>...]:: 'git diff' [<options>] --cached [<commit>] [--] [<path>...]::

2
Documentation/git-fast-export.txt
View File

@ -142,7 +142,7 @@ by keeping the marks the same across runs.
Specify how to handle `encoding` header in commit objects. When Specify how to handle `encoding` header in commit objects. When
asking to 'abort' (which is the default), this program will die asking to 'abort' (which is the default), this program will die
when encountering such a commit object. With 'yes', the commit when encountering such a commit object. With 'yes', the commit
message will be reencoded into UTF-8. With 'no', the original message will be re-encoded into UTF-8. With 'no', the original
encoding will be preserved. encoding will be preserved.
--refspec:: --refspec::

15
Documentation/git-fast-import.txt
View File

@ -51,6 +51,21 @@ OPTIONS
memory used by fast-import during this run. Showing this output memory used by fast-import during this run. Showing this output
is currently the default, but can be disabled with --quiet. 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 Options for Frontends
~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~

251
Documentation/git-filter-branch.txt
View File

@ -466,13 +466,13 @@ The performance of git-filter-branch is glacially slow; its design makes it
impossible for a backward-compatible implementation to ever be fast: impossible for a backward-compatible implementation to ever be fast:
* In editing files, git-filter-branch by design checks out each and * 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 every commit as it existed in the original repo. If your repo has
files and 10\^5 commits, but each commit only modifies 5 files, then 10\^5 files and 10\^5 commits, but each commit only modifies 5
git-filter-branch will make you do 10\^10 modifications, despite only files, then git-filter-branch will make you do 10\^10 modifications,
having (at most) 5*10^5 unique blobs. 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 * If you try and cheat and try to make git-filter-branch only work on
files modified in a commit, then two things happen files modified in a commit, then two things happen
** you run into problems with deletions whenever the user is simply ** you run into problems with deletions whenever the user is simply
trying to rename files (because attempting to delete files that trying to rename files (because attempting to delete files that
@ -481,39 +481,41 @@ files modified in a commit, then two things happen
user-provided shell) user-provided shell)
** even if you succeed at the map-deletes-for-renames chicanery, you ** even if you succeed at the map-deletes-for-renames chicanery, you
still technically violate backward compatibility because users are still technically violate backward compatibility because users
allowed to filter files in ways that depend upon topology of are allowed to filter files in ways that depend upon topology of
commits instead of filtering solely based on file contents or names commits instead of filtering solely based on file contents or
(though this has not been observed in the wild). 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 * 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 remove some and thus can avoid checking out each file (i.e. you can
--index-filter), you still are passing shell snippets for your filters. use --index-filter), you still are passing shell snippets for your
This means that for every commit, you have to have a prepared git repo filters. This means that for every commit, you have to have a
where those filters can be run. That's a significant setup. 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 * Further, several additional files are created or updated per commit
git-filter-branch. Some of these are for supporting the convenience by git-filter-branch. Some of these are for supporting the
functions provided by git-filter-branch (such as map()), while others convenience functions provided by git-filter-branch (such as map()),
are for keeping track of internal state (but could have also been while others are for keeping track of internal state (but could have
accessed by user filters; one of git-filter-branch's regression tests also been accessed by user filters; one of git-filter-branch's
does so). This essentially amounts to using the filesystem as an IPC regression tests does so). This essentially amounts to using the
mechanism between git-filter-branch and the user-provided filters. filesystem as an IPC mechanism between git-filter-branch and the
Disks tend to be a slow IPC mechanism, and writing these files also user-provided filters. Disks tend to be a slow IPC mechanism, and
effectively represents a forced synchronization point between separate writing these files also effectively represents a forced
processes that we hit with every commit. synchronization point between separate processes that we hit with
every commit.
* The user-provided shell commands will likely involve a pipeline of * The user-provided shell commands will likely involve a pipeline of
commands, resulting in the creation of many processes per commit. commands, resulting in the creation of many processes per commit.
Creating and running another process takes a widely varying amount of Creating and running another process takes a widely varying amount
time between operating systems, but on any platform it is very slow of time between operating systems, but on any platform it is very
relative to invoking a function. slow relative to invoking a function.
* git-filter-branch itself is written in shell, which is kind of slow. * git-filter-branch itself is written in shell, which is kind of slow.
This is the one performance issue that could be backward-compatibly This is the one performance issue that could be backward-compatibly
fixed, but compared to the above problems that are intrinsic to the 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 design of git-filter-branch, the language of the tool itself is a
relatively minor issue. relatively minor issue.
** Side note: Unfortunately, people tend to fixate on the ** Side note: Unfortunately, people tend to fixate on the
written-in-shell aspect and periodically ask if git-filter-branch written-in-shell aspect and periodically ask if git-filter-branch
@ -534,7 +536,7 @@ repo-filter' also provides
https://github.com/newren/git-filter-repo/blob/master/contrib/filter-repo-demos/filter-lamely[filter-lamely], 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 a drop-in git-filter-branch replacement (with a few caveats). While
filter-lamely suffers from all the same safety issues as filter-lamely suffers from all the same safety issues as
git-filter-branch, it at least ameloriates the performance issues a git-filter-branch, it at least ameliorates the performance issues a
little. little.
[[SAFETY]] [[SAFETY]]
@ -546,51 +548,55 @@ easily corrupt repos or end up with a mess worse than what you started
with: with:
* Someone can have a set of "working and tested filters" which they * 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 document or provide to a coworker, who then runs them on a different
where the same commands are not working/tested (some examples in the OS where the same commands are not working/tested (some examples in
git-filter-branch manpage are also affected by this). BSD vs. GNU the git-filter-branch manpage are also affected by this).
userland differences can really bite. If lucky, error messages are BSD vs. GNU userland differences can really bite. If lucky, error
spewed. But just as likely, the commands either don't do the filtering messages are spewed. But just as likely, the commands either don't
requested, or silently corrupt by making some unwanted change. The do the filtering requested, or silently corrupt by making some
unwanted change may only affect a few commits, so it's not necessarily unwanted change. The unwanted change may only affect a few commits,
obvious either. (The fact that problems won't necessarily be obvious so it's not necessarily obvious either. (The fact that problems
means they are likely to go unnoticed until the rewritten history is in won't necessarily be obvious means they are likely to go unnoticed
use for quite a while, at which point it's really hard to justify until the rewritten history is in use for quite a while, at which
another flag-day for another rewrite.) point it's really hard to justify another flag-day for another
rewrite.)
* Filenames with spaces are often mishandled by shell snippets since * Filenames with spaces are often mishandled by shell snippets since
they cause problems for shell pipelines. Not everyone is familiar with they cause problems for shell pipelines. Not everyone is familiar
find -print0, xargs -0, git-ls-files -z, etc. Even people who are with find -print0, xargs -0, git-ls-files -z, etc. Even people who
familiar with these may assume such flags are not relevant because are familiar with these may assume such flags are not relevant
someone else renamed any such files in their repo back before the person because someone else renamed any such files in their repo back
doing the filtering joined the project. And often, even those familiar before the person doing the filtering joined the project. And
with handling arguments with spaces may not do so just because they often, even those familiar with handling arguments with spaces may
aren't in the mindset of thinking about everything that could possibly not do so just because they aren't in the mindset of thinking about
go wrong. everything that could possibly go wrong.
* Non-ascii filenames can be silently removed despite being in a desired * Non-ascii filenames can be silently removed despite being in a
directory. Keeping only wanted paths is often done using pipelines like desired directory. Keeping only wanted paths is often done using
`git ls-files | grep -v ^WANTED_DIR/ | xargs git rm`. ls-files will pipelines like `git ls-files | grep -v ^WANTED_DIR/ | xargs git rm`.
only quote filenames if needed, so folks may not notice that one of the ls-files will only quote filenames if needed, so folks may not
files didn't match the regex (at least not until it's much too late). notice that one of the files didn't match the regex (at least not
Yes, someone who knows about core.quotePath can avoid this (unless they until it's much too late). Yes, someone who knows about
have other special characters like \t, \n, or "), and people who use core.quotePath can avoid this (unless they have other special
ls-files -z with something other than grep can avoid this, but that characters like \t, \n, or "), and people who use ls-files -z with
doesn't mean they will. 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 * Similarly, when moving files around, one can find that filenames
non-ascii or special characters end up in a different directory, one with non-ascii or special characters end up in a different
that includes a double quote character. (This is technically the same directory, one that includes a double quote character. (This is
issue as above with quoting, but perhaps an interesting different way technically the same issue as above with quoting, but perhaps an
that it can and has manifested as a problem.) 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 * 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. still possible with any tool, but git-filter-branch almost
If lucky, the only downside is users getting frustrated that they don't invites it. If lucky, the only downside is users getting frustrated
know how to shrink their repo and remove the old stuff. If unlucky, that they don't know how to shrink their repo and remove the old
they merge old and new history and end up with multiple "copies" of each stuff. If unlucky, they merge old and new history and end up with
commit, some of which have unwanted or sensitive files and others which multiple "copies" of each commit, some of which have unwanted or
don't. This comes about in multiple different ways: 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 to only doing a partial history rewrite ('--all' is not
the default and few examples show it) the default and few examples show it)
@ -609,8 +615,8 @@ don't. This comes about in multiple different ways:
"DISCUSSION" section of the git filter-repo manual page for more "DISCUSSION" section of the git filter-repo manual page for more
details. details.
* Annotated tags can be accidentally converted to lightweight tags, due * Annotated tags can be accidentally converted to lightweight tags,
to either of two issues: due to either of two issues:
** Someone can do a history rewrite, realize they messed up, restore ** Someone can do a history rewrite, realize they messed up, restore
from the backups in refs/original/, and then redo their from the backups in refs/original/, and then redo their
@ -623,71 +629,74 @@ to either of two issues:
restored from refs/original/ in a previously botched rewrite). restored from refs/original/ in a previously botched rewrite).
* Any commit messages that specify an encoding will become corrupted * Any commit messages that specify an encoding will become corrupted
by the rewrite; git-filter-branch ignores the encoding, takes the original by the rewrite; git-filter-branch ignores the encoding, takes the
bytes, and feeds it to commit-tree without telling it the proper original bytes, and feeds it to commit-tree without telling it the
encoding. (This happens whether or not --msg-filter is used.) proper encoding. (This happens whether or not --msg-filter is
used.)
* Commit messages (even if they are all UTF-8) by default become * Commit messages (even if they are all UTF-8) by default become
corrupted due to not being updated -- any references to other commit corrupted due to not being updated -- any references to other commit
hashes in commit messages will now refer to no-longer-extant commits. hashes in commit messages will now refer to no-longer-extant
commits.
* There are no facilities for helping users find what unwanted crud they * There are no facilities for helping users find what unwanted crud
should delete, which means they are much more likely to have incomplete they should delete, which means they are much more likely to have
or partial cleanups that sometimes result in confusion and people incomplete or partial cleanups that sometimes result in confusion
wasting time trying to understand. (For example, folks tend to just and people wasting time trying to understand. (For example, folks
look for big files to delete instead of big directories or extensions, tend to just look for big files to delete instead of big directories
and once they do so, then sometime later folks using the new repository or extensions, and once they do so, then sometime later folks using
who are going through history will notice a build artifact directory the new repository who are going through history will notice a build
that has some files but not others, or a cache of dependencies artifact directory that has some files but not others, or a cache of
(node_modules or similar) which couldn't have ever been functional since dependencies (node_modules or similar) which couldn't have ever been
it's missing some files.) functional since it's missing some files.)
* If --prune-empty isn't specified, then the filtering process can * If --prune-empty isn't specified, then the filtering process can
create hoards of confusing empty commits create hoards of confusing empty commits
* If --prune-empty is specified, then intentionally placed empty * If --prune-empty is specified, then intentionally placed empty
commits from before the filtering operation are also pruned instead of commits from before the filtering operation are also pruned instead
just pruning commits that became empty due to filtering rules. of just pruning commits that became empty due to filtering rules.
* If --prune empty is specified, sometimes empty commits are missed * If --prune-empty is specified, sometimes empty commits are missed
and left around anyway (a somewhat rare bug, but it happens...) 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 * 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 emails in a repository may be led to --env-filter which will only
authors and committers, missing taggers. update authors and committers, missing taggers.
* If the user provides a --tag-name-filter that maps multiple tags to * 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 the same name, no warning or error is provided; git-filter-branch
overwrites each tag in some undocumented pre-defined order resulting in simply overwrites each tag in some undocumented pre-defined order
only one tag at the end. (A git-filter-branch regression test requires resulting in only one tag at the end. (A git-filter-branch
this surprising behavior.) regression test requires this surprising behavior.)
Also, the poor performance of git-filter-branch often leads to safety Also, the poor performance of git-filter-branch often leads to safety
issues: issues:
* Coming up with the correct shell snippet to do the filtering you want * Coming up with the correct shell snippet to do the filtering you
is sometimes difficult unless you're just doing a trivial modification want is sometimes difficult unless you're just doing a trivial
such as deleting a couple files. Unfortunately, people often learn if modification such as deleting a couple files. Unfortunately, people
the snippet is right or wrong by trying it out, but the rightness or often learn if the snippet is right or wrong by trying it out, but
wrongness can vary depending on special circumstances (spaces in the rightness or wrongness can vary depending on special
filenames, non-ascii filenames, funny author names or emails, invalid circumstances (spaces in filenames, non-ascii filenames, funny
timezones, presence of grafts or replace objects, etc.), meaning they author names or emails, invalid timezones, presence of grafts or
may have to wait a long time, hit an error, then restart. The replace objects, etc.), meaning they may have to wait a long time,
performance of git-filter-branch is so bad that this cycle is painful, hit an error, then restart. The performance of git-filter-branch is
reducing the time available to carefully re-check (to say nothing about so bad that this cycle is painful, reducing the time available to
what it does to the patience of the person doing the rewrite even if carefully re-check (to say nothing about what it does to the
they do technically have more time available). This problem is extra patience of the person doing the rewrite even if they do technically
compounded because errors from broken filters may not be shown for a have more time available). This problem is extra compounded because
long time and/or get lost in a sea of output. Even worse, broken errors from broken filters may not be shown for a long time and/or
filters often just result in silent incorrect rewrites. 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 * To top it all off, even when users finally find working commands,
naturally want to share them. But they may be unaware that their repo they naturally want to share them. But they may be unaware that
didn't have some special cases that someone else's does. So, when their repo didn't have some special cases that someone else's does.
someone else with a different repository runs the same commands, they So, when someone else with a different repository runs the same
get hit by the problems above. Or, the user just runs commands that commands, they get hit by the problems above. Or, the user just
really were vetted for special cases, but they run it on a different OS runs commands that really were vetted for special cases, but they
where it doesn't work, as noted above. run it on a different OS where it doesn't work, as noted above.
GIT GIT
--- ---

27
Documentation/git-format-patch.txt
View File

@ -19,6 +19,7 @@ SYNOPSIS
[--start-number <n>] [--numbered-files] [--start-number <n>] [--numbered-files]
[--in-reply-to=<message id>] [--suffix=.<sfx>] [--in-reply-to=<message id>] [--suffix=.<sfx>]
[--ignore-if-in-upstream] [--ignore-if-in-upstream]
[--cover-from-description=<mode>]
[--rfc] [--subject-prefix=<subject prefix>] [--rfc] [--subject-prefix=<subject prefix>]
[(--reroll-count|-v) <n>] [(--reroll-count|-v) <n>]
[--to=<email>] [--cc=<email>] [--to=<email>] [--cc=<email>]
@ -172,6 +173,26 @@ will want to ensure that threading is disabled for `git send-email`.
patches being generated, and any patch that matches is patches being generated, and any patch that matches is
ignored. ignored.
--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.
--subject-prefix=<subject prefix>:: --subject-prefix=<subject prefix>::
Instead of the standard '[PATCH]' prefix in the subject Instead of the standard '[PATCH]' prefix in the subject
line, instead use '[<subject prefix>]'. This line, instead use '[<subject prefix>]'. This
@ -312,11 +333,12 @@ you can use `--suffix=-patch` to get `0001-description-of-my-change-patch`.
Output an all-zero hash in each patch's From header instead Output an all-zero hash in each patch's From header instead
of the hash of the commit. of the hash of the commit.
--base=<commit>:: --[no-]base[=<commit>]::
Record the base tree information to identify the state the Record the base tree information to identify the state the
patch series applies to. See the BASE TREE INFORMATION section patch series applies to. See the BASE TREE INFORMATION section
below for details. If <commit> is "auto", a base commit is below for details. If <commit> is "auto", a base commit is
automatically chosen. automatically chosen. The `--no-base` option overrides a
`format.useAutoBase` configuration.
--root:: --root::
Treat the revision argument as a <revision range>, even if it Treat the revision argument as a <revision range>, even if it
@ -348,6 +370,7 @@ with configuration variables.
signOff = true signOff = true
outputDirectory = <directory> outputDirectory = <directory>
coverLetter = auto coverLetter = auto
coverFromDescription = auto
------------ ------------

6
Documentation/git-multi-pack-index.txt
View File

@ -9,7 +9,7 @@ git-multi-pack-index - Write and verify multi-pack-indexes
SYNOPSIS SYNOPSIS
-------- --------
[verse] [verse]
'git multi-pack-index' [--object-dir=<dir>] <subcommand> 'git multi-pack-index' [--object-dir=<dir>] [--[no-]progress] <subcommand>
DESCRIPTION DESCRIPTION
----------- -----------
@ -23,6 +23,10 @@ OPTIONS
`<dir>/packs/multi-pack-index` for the current MIDX file, and `<dir>/packs/multi-pack-index` for the current MIDX file, and
`<dir>/packs` for the pack-files to index. `<dir>/packs` for the pack-files to index.
--[no-]progress::
Turn progress on/off explicitly. If neither is specified, progress is
shown if standard error is connected to a terminal.
The following subcommands are available: The following subcommands are available:
write:: write::

6
Documentation/git-notes.txt
View File

@ -10,7 +10,7 @@ SYNOPSIS
[verse] [verse]
'git notes' [list [<object>]] 'git notes' [list [<object>]]
'git notes' add [-f] [--allow-empty] [-F <file> | -m <msg> | (-c | -C) <object>] [<object>] 'git notes' add [-f] [--allow-empty] [-F <file> | -m <msg> | (-c | -C) <object>] [<object>]
'git notes' copy [-f] ( --stdin | <from-object> <to-object> ) 'git notes' copy [-f] ( --stdin | <from-object> [<to-object>] )
'git notes' append [--allow-empty] [-F <file> | -m <msg> | (-c | -C) <object>] [<object>] 'git notes' append [--allow-empty] [-F <file> | -m <msg> | (-c | -C) <object>] [<object>]
'git notes' edit [--allow-empty] [<object>] 'git notes' edit [--allow-empty] [<object>]
'git notes' show [<object>] 'git notes' show [<object>]
@ -68,8 +68,8 @@ add::
subcommand). subcommand).
copy:: copy::
Copy the notes for the first object onto the second object. Copy the notes for the first object onto the second object (defaults to
Abort if the second object already has notes, or if the first HEAD). Abort if the second object already has notes, or if the first
object has none (use -f to overwrite existing notes to the object has none (use -f to overwrite existing notes to the
second object). This subcommand is equivalent to: second object). This subcommand is equivalent to:
`git notes add [-f] -C $(git notes list <from-object>) <to-object>` `git notes add [-f] -C $(git notes list <from-object>) <to-object>`

8
Documentation/git-range-diff.txt
View File

@ -57,6 +57,10 @@ to revert to color all lines according to the outer diff markers
See the ``Algorithm`` section below for an explanation why this is See the ``Algorithm`` section below for an explanation why this is
needed. needed.
--[no-]notes[=<ref>]::
This flag is passed to the `git log` program
(see linkgit:git-log[1]) that generates the patches.
<range1> <range2>:: <range1> <range2>::
Compare the commits specified by the two ranges, where Compare the commits specified by the two ranges, where
`<range1>` is considered an older version of `<range2>`. `<range1>` is considered an older version of `<range2>`.
@ -75,7 +79,7 @@ to revert to color all lines according to the outer diff markers
linkgit:git-diff[1]), most notably the `--color=[<when>]` and linkgit:git-diff[1]), most notably the `--color=[<when>]` and
`--no-color` options. These options are used when generating the "diff `--no-color` options. These options are used when generating the "diff
between patches", i.e. to compare the author, commit message and diff of between patches", i.e. to compare the author, commit message and diff of
corresponding old/new commits. There is currently no means to tweak the corresponding old/new commits. There is currently no means to tweak most of the
diff options passed to `git log` when generating those patches. diff options passed to `git log` when generating those patches.
OUTPUT STABILITY OUTPUT STABILITY
@ -242,7 +246,7 @@ corresponding.
The overall time needed to compute this algorithm is the time needed to 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 compute n+m commit diffs and then n*m diffs of patches, plus the time
needed to compute the least-cost assigment between n and m diffs. Git needed to compute the least-cost assignment between n and m diffs. Git
uses an implementation of the Jonker-Volgenant algorithm to solve the uses an implementation of the Jonker-Volgenant algorithm to solve the
assignment problem, which has cubic runtime complexity. The matching assignment problem, which has cubic runtime complexity. The matching
found in this case will look like this: found in this case will look like this:

2
Documentation/git-read-tree.txt
View File

@ -436,7 +436,7 @@ support.
SEE ALSO SEE ALSO
-------- --------
linkgit:git-write-tree[1]; linkgit:git-ls-files[1]; linkgit:git-write-tree[1]; linkgit:git-ls-files[1];
linkgit:gitignore[5] linkgit:gitignore[5]; linkgit:git-sparse-checkout[1];
GIT GIT
--- ---

31
Documentation/git-rebase.txt
View File

@ -393,16 +393,31 @@ your branch contains commits which were dropped, this option can be used
with `--keep-base` in order to drop those commits from your branch. with `--keep-base` in order to drop those commits from your branch.
--ignore-whitespace:: --ignore-whitespace::
Behaves differently depending on which backend is selected.
+
'am' backend: When applying a patch, ignore changes in whitespace in
context lines if necessary.
+
'interactive' backend: Treat lines with only whitespace changes as
unchanged for the sake of a three-way merge.
--whitespace=<option>:: --whitespace=<option>::
These flag are passed to the 'git apply' program This flag is passed to the 'git apply' program
(see linkgit:git-apply[1]) that applies the patch. (see linkgit:git-apply[1]) that applies the patch.
+ +
See also INCOMPATIBLE OPTIONS below. See also INCOMPATIBLE OPTIONS below.
--committer-date-is-author-date:: --committer-date-is-author-date::
Instead of recording the time the rebased commits are
created as the committer date, reuse the author date
as the committer date. This implies --force-rebase.
--ignore-date:: --ignore-date::
These flags are passed to 'git am' to easily change the dates --reset-author-date::
of the rebased commits (see linkgit:git-am[1]). By default, the author date of the original commit is used
as the author date for the resulting commit. This option
tells Git to use the current timestamp instead and implies
`--force-rebase`.
+ +
See also INCOMPATIBLE OPTIONS below. See also INCOMPATIBLE OPTIONS below.
@ -443,8 +458,8 @@ the `rebase-cousins` mode is turned on, such commits are instead rebased
onto `<upstream>` (or `<onto>`, if specified). onto `<upstream>` (or `<onto>`, if specified).
+ +
The `--rebase-merges` mode is similar in spirit to the deprecated The `--rebase-merges` mode is similar in spirit to the deprecated
`--preserve-merges`, but in contrast to that option works well in interactive `--preserve-merges` but works with interactive rebases,
rebases: commits can be reordered, inserted and dropped at will. where commits can be reordered, inserted and dropped at will.
+ +
It is currently only possible to recreate the merge commits using the It is currently only possible to recreate the merge commits using the
`recursive` merge strategy; Different merge strategies can be used only via `recursive` merge strategy; Different merge strategies can be used only via
@ -539,10 +554,7 @@ INCOMPATIBLE OPTIONS
The following options: The following options:
* --committer-date-is-author-date
* --ignore-date
* --whitespace * --whitespace
* --ignore-whitespace
* -C * -C
are incompatible with the following options: are incompatible with the following options:
@ -565,6 +577,9 @@ In addition, the following pairs of options are incompatible:
* --preserve-merges and --interactive * --preserve-merges and --interactive
* --preserve-merges and --signoff * --preserve-merges and --signoff
* --preserve-merges and --rebase-merges * --preserve-merges and --rebase-merges
* --preserve-merges and --ignore-whitespace
* --preserve-merges and --committer-date-is-author-date
* --preserve-merges and --ignore-date
* --keep-base and --onto * --keep-base and --onto
* --keep-base and --root * --keep-base and --root

48
Documentation/git-reset.txt
View File

@ -8,34 +8,36 @@ git-reset - Reset current HEAD to the specified state
SYNOPSIS SYNOPSIS
-------- --------
[verse] [verse]
'git reset' [-q] [<tree-ish>] [--] <paths>... 'git reset' [-q] [<tree-ish>] [--] <pathspec>...
'git reset' (--patch | -p) [<tree-ish>] [--] [<paths>...] '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>] 'git reset' [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] [<commit>]
DESCRIPTION DESCRIPTION
----------- -----------
In the first and second form, copy entries from `<tree-ish>` to the index. In the first three forms, copy entries from `<tree-ish>` to the index.
In the third form, set the current branch head (`HEAD`) to `<commit>`, In the last form, set the current branch head (`HEAD`) to `<commit>`,
optionally modifying index and working tree to match. optionally modifying index and working tree to match.
The `<tree-ish>`/`<commit>` defaults to `HEAD` in all forms. The `<tree-ish>`/`<commit>` defaults to `HEAD` in all forms.
'git reset' [-q] [<tree-ish>] [--] <paths>...:: 'git reset' [-q] [<tree-ish>] [--] <pathspec>...::
This form resets the index entries for all `<paths>` to their 'git reset' [-q] [--pathspec-from-file=<file> [--pathspec-file-nul]] [<tree-ish>]::
state at `<tree-ish>`. (It does not affect the working tree or These forms reset the index entries for all paths that match the
the current branch.) `<pathspec>` to their state at `<tree-ish>`. (It does not affect
the working tree or the current branch.)
+ +
This means that `git reset <paths>` is the opposite of `git add This means that `git reset <pathspec>` is the opposite of `git add
<paths>`. This command is equivalent to <pathspec>`. This command is equivalent to
`git restore [--source=<tree-ish>] --staged <paths>...`. `git restore [--source=<tree-ish>] --staged <pathspec>...`.
+ +
After running `git reset <paths>` to update the index entry, you can 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 use linkgit:git-restore[1] to check the contents out of the index to
the working tree. Alternatively, using linkgit:git-restore[1] the working tree. Alternatively, using linkgit:git-restore[1]
and specifying a commit with `--source`, you and specifying a commit with `--source`, you
can copy the contents of a path out of a commit to the index and to the can copy the contents of a path out of a commit to the index and to the
working tree in one go. working tree in one go.
'git reset' (--patch | -p) [<tree-ish>] [--] [<paths>...]:: 'git reset' (--patch | -p) [<tree-ish>] [--] [<pathspec>...]::
Interactively select hunks in the difference between the index Interactively select hunks in the difference between the index
and `<tree-ish>` (defaults to `HEAD`). The chosen hunks are applied and `<tree-ish>` (defaults to `HEAD`). The chosen hunks are applied
in reverse to the index. in reverse to the index.
@ -101,6 +103,26 @@ OPTIONS
`reset.quiet` config option. `--quiet` and `--no-quiet` will `reset.quiet` config option. `--quiet` and `--no-quiet` will
override the default behavior. override the default behavior.
--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 EXAMPLES
-------- --------

26
Documentation/git-restore.txt
View File

@ -8,8 +8,9 @@ git-restore - Restore working tree files
SYNOPSIS SYNOPSIS
-------- --------
[verse] [verse]
'git restore' [<options>] [--source=<tree>] [--staged] [--worktree] <pathspec>... 'git restore' [<options>] [--source=<tree>] [--staged] [--worktree] [--] <pathspec>...
'git restore' (-p|--patch) [<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 DESCRIPTION
----------- -----------
@ -113,6 +114,27 @@ in linkgit:git-checkout[1] for details.
appear in the `--source` tree are removed, to make them match appear in the `--source` tree are removed, to make them match
`<tree>` exactly. The default is no-overlay mode. `<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 EXAMPLES
-------- --------

10
Documentation/git-rev-parse.txt
View File

@ -262,7 +262,8 @@ print a message to stderr and exit with nonzero status.
directory. directory.
--show-toplevel:: --show-toplevel::
Show the absolute path of the top-level directory. Show the 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-superproject-working-tree::
Show the absolute path of the root of the superproject's Show the absolute path of the root of the superproject's
@ -274,6 +275,13 @@ print a message to stderr and exit with nonzero status.
Show the path to the shared index file in split index mode, or Show the path to the shared index file in split index mode, or
empty if not in split-index mode. empty if not in split-index mode.
--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".
Other Options Other Options
~~~~~~~~~~~~~ ~~~~~~~~~~~~~

3
Documentation/git-shortlog.txt
View File

@ -76,6 +76,9 @@ them.
Paths may need to be prefixed with `--` to separate them from Paths may need to be prefixed with `--` to separate them from
options or the revision range, when confusion arises. options or the revision range, when confusion arises.
:git-shortlog: 1
include::rev-list-options.txt[]
MAPPING AUTHORS MAPPING AUTHORS
--------------- ---------------

166
Documentation/git-sparse-checkout.txt Normal file
View File

@ -0,0 +1,166 @@
git-sparse-checkout(1)
======================
NAME
----
git-sparse-checkout - Initialize and modify the sparse-checkout
configuration, which reduces the checkout to a set of paths
given by a list of atterns.
SYNOPSIS
--------
[verse]
'git sparse-checkout <subcommand> [options]'
DESCRIPTION
-----------
Initialize and modify the sparse-checkout configuration, which reduces
the checkout to a set of paths given by a list of patterns.
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'::
Provide a list of the contents in the sparse-checkout file.
'init'::
Enable the `core.sparseCheckout` setting. If the
sparse-checkout file does not exist, then populate it with
patterns that match every file in the root directory and
no other directories, then will remove all directories tracked
by Git. Add patterns to the sparse-checkout file to
repopulate the working directory.
+
To avoid interfering with other worktrees, it first enables the
`extensions.worktreeConfig` setting and makes sure to set the
`core.sparseCheckout` setting in the worktree-specific config file.
'set'::
Write a set of patterns to the sparse-checkout file, as given as
a list of arguments following the 'set' subcommand. Update the
working directory to match the new patterns. Enable the
core.sparseCheckout config setting if it is not already enabled.
+
When the `--stdin` option is provided, the patterns are read from
standard in as a newline-delimited list instead of from the arguments.
'disable'::
Disable the `core.sparseCheckout` config setting, and restore the
working directory to include all files. Leaves the sparse-checkout
file intact so a later 'git sparse-checkout init' command may
return the working directory to the same state.
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, then the file is ignored in the working
directory. Git will not populate 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.
To enable the sparse-checkout feature, run `git sparse-checkout init` to
initialize a simple sparse-checkout file and enable the `core.sparseCheckout`
config setting. Then, run `git sparse-checkout set` to modify the patterns in
the sparse-checkout file.
To repopulate the working directory with all files, use the
`git sparse-checkout disable` command.
FULL PATTERN SET
----------------
By default, the sparse-checkout file uses the same syntax as `.gitignore`
files.
While `$GIT_DIR/info/sparse-checkout` is usually used to specify what
files are included, you can also specify what files are _not_ included,
using negative patterns. For example, to remove the file `unwanted`:
----------------
/*
!unwanted
----------------
CONE 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.spareCheckoutCone` is enabled.
The accepted patterns in the cone pattern set are:
1. *Recursive:* All paths inside a directory are included.
2. *Parent:* All files immediately inside a directory are included.
In addition to the above two patterns, we also expect that all files in the
root directory are included. If a recursive pattern is added, then all
leading directories are added as parent patterns.
By default, when running `git sparse-checkout init`, the root directory is
added as a parent pattern. At this point, the sparse-checkout file contains
the following patterns:
----------------
/*
!/*/
----------------
This says "include everything in root, but nothing two levels below root."
If we then add the folder `A/B/C` as a recursive pattern, the folders `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.
If `core.sparseCheckoutCone=true`, then 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 `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.
SEE ALSO
--------
linkgit:git-read-tree[1]
linkgit:gitignore[5]
GIT
---
Part of the linkgit:git[1] suite

12
Documentation/git-submodule.txt
View File

@ -16,6 +16,7 @@ SYNOPSIS
'git submodule' [--quiet] deinit [-f|--force] (--all|[--] <path>...) 'git submodule' [--quiet] deinit [-f|--force] (--all|[--] <path>...)
'git submodule' [--quiet] update [<options>] [--] [<path>...] 'git submodule' [--quiet] update [<options>] [--] [<path>...]
'git submodule' [--quiet] set-branch [<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] summary [<options>] [--] [<path>...]
'git submodule' [--quiet] foreach [--recursive] <command> 'git submodule' [--quiet] foreach [--recursive] <command>
'git submodule' [--quiet] sync [--recursive] [--] [<path>...] 'git submodule' [--quiet] sync [--recursive] [--] [<path>...]
@ -80,6 +81,9 @@ status [--cached] [--recursive] [--] [<path>...]::
does not match the SHA-1 found in the index of the containing does not match the SHA-1 found in the index of the containing
repository and `U` if the submodule has merge conflicts. 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 If `--recursive` is specified, this command will recurse into nested
submodules, and show their status as well. submodules, and show their status as well.
+ +
@ -133,7 +137,8 @@ update [--init] [--remote] [-N|--no-fetch] [--[no-]recommend-shallow] [-f|--forc
+ +
-- --
Update the registered submodules to match what the superproject Update the registered submodules to match what the superproject
expects by cloning missing submodules and updating the working tree of 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 the submodules. The "updating" can be done in several ways depending
on command line options and the value of `submodule.<name>.update` on command line options and the value of `submodule.<name>.update`
configuration variable. The command line option takes precedence over configuration variable. The command line option takes precedence over
@ -180,6 +185,11 @@ set-branch (-d|--default) [--] <path>::
`--default` option removes the submodule.<name>.branch configuration `--default` option removes the submodule.<name>.branch configuration
key, which causes the tracking branch to default to 'master'. key, which causes the tracking branch to default to 'master'.
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>...]:: summary [--cached|--files] [(-n|--summary-limit) <n>] [commit] [--] [<path>...]::
Show commit summary between the given commit (defaults to HEAD) and Show commit summary between the given commit (defaults to HEAD) and
working tree/index. For a submodule in question, a series of commits working tree/index. For a submodule in question, a series of commits

3
Documentation/git-svn.txt
View File

@ -677,7 +677,8 @@ config key: svn.authorsProg
-s<strategy>:: -s<strategy>::
--strategy=<strategy>:: --strategy=<strategy>::
-p:: -p::
--preserve-merges:: --rebase-merges::
--preserve-merges (DEPRECATED)::
These are only used with the 'dcommit' and 'rebase' commands. These are only used with the 'dcommit' and 'rebase' commands.
+ +
Passed directly to 'git rebase' when using 'dcommit' if a Passed directly to 'git rebase' when using 'dcommit' if a

2
Documentation/git-tag.txt
View File

@ -65,7 +65,7 @@ OPTIONS
--sign:: --sign::
Make a GPG-signed tag, using the default e-mail address's key. 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` The default behavior of tag GPG-signing is controlled by `tag.gpgSign`
configuration variable if it exists, or disabled oder otherwise. configuration variable if it exists, or disabled otherwise.
See linkgit:git-config[1]. See linkgit:git-config[1].
--no-sign:: --no-sign::

8
Documentation/git-update-index.txt
View File

@ -16,6 +16,7 @@ SYNOPSIS
[--chmod=(+|-)x] [--chmod=(+|-)x]
[--[no-]assume-unchanged] [--[no-]assume-unchanged]
[--[no-]skip-worktree] [--[no-]skip-worktree]
[--[no-]ignore-skip-worktree-entries]
[--[no-]fsmonitor-valid] [--[no-]fsmonitor-valid]
[--ignore-submodules] [--ignore-submodules]
[--[no-]split-index] [--[no-]split-index]
@ -113,6 +114,11 @@ you will need to handle the situation manually.
set and unset the "skip-worktree" bit for the paths. See set and unset the "skip-worktree" bit for the paths. See
section "Skip-worktree bit" below for more information. 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:: --[no-]fsmonitor-valid::
When one of these flags is specified, the object name recorded When one of these flags is specified, the object name recorded
for the paths are not updated. Instead, these options for the paths are not updated. Instead, these options
@ -426,7 +432,7 @@ specified by the splitIndex.sharedIndexExpire config variable (see
linkgit:git-config[1]). linkgit:git-config[1]).
To avoid deleting a shared index file that is still used, its To avoid deleting a shared index file that is still used, its
modification time is updated to the current time everytime a new split 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. index based on the shared index file is either created or read from.
UNTRACKED CACHE UNTRACKED CACHE

10
Documentation/git.txt
View File

@ -271,8 +271,8 @@ In general, the interrogate commands do not touch the files in
the working tree. the working tree.
Synching repositories Syncing repositories
~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
include::cmds-synchingrepositories.txt[] include::cmds-synchingrepositories.txt[]
@ -544,6 +544,10 @@ other
a pager. See also the `core.pager` option in a pager. See also the `core.pager` option in
linkgit:git-config[1]. 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`:: `GIT_EDITOR`::
This environment variable overrides `$EDITOR` and `$VISUAL`. This environment variable overrides `$EDITOR` and `$VISUAL`.
It is used by several Git commands when, on interactive mode, It is used by several Git commands when, on interactive mode,
@ -928,7 +932,7 @@ Reporting Bugs
Report bugs to the Git mailing list <git@vger.kernel.org> where the 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 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 subscribed to the list to send a message there. See the list archive
at https://public-inbox.org/git for previous bug reports and other at https://lore.kernel.org/git for previous bug reports and other
discussions. discussions.
Issues which are security relevant should be disclosed privately to Issues which are security relevant should be disclosed privately to

8
Documentation/gitattributes.txt
View File

@ -293,10 +293,10 @@ 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 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 directory with the `working-tree-encoding` attribute. If a file with this
attribute is added to Git, then Git reencodes the content from the 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 specified encoding to UTF-8. Finally, Git stores the UTF-8 encoded
content in its internal data structure (called "the index"). On checkout content in its internal data structure (called "the index"). On checkout
the content is reencoded back to the specified encoding. the content is re-encoded back to the specified encoding.
Please note that using the `working-tree-encoding` attribute may have a Please note that using the `working-tree-encoding` attribute may have a
number of pitfalls: number of pitfalls:
@ -498,7 +498,7 @@ command. This is achieved by using the long-running process protocol
When Git encounters the first file that needs to be cleaned or smudged, 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 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 welcome message sent by Git is "git-filter-client", only version 2 is
suppported, and the supported capabilities are "clean", "smudge", and supported, and the supported capabilities are "clean", "smudge", and
"delay". "delay".
Afterwards Git sends a list of "key=value" pairs terminated with Afterwards Git sends a list of "key=value" pairs terminated with
@ -812,6 +812,8 @@ patterns are available:
- `dts` suitable for devicetree (DTS) files. - `dts` suitable for devicetree (DTS) files.
- `elixir` suitable for source code in the Elixir language.
- `fortran` suitable for source code in the Fortran language. - `fortran` suitable for source code in the Fortran language.
- `fountain` suitable for Fountain documents. - `fountain` suitable for Fountain documents.

4
Documentation/gitcli.txt
View File

@ -211,8 +211,8 @@ only affects the files in the working tree, but with
entries, and with `--cached`, it modifies only the index entries, and with `--cached`, it modifies only the index
entries. entries.
See also http://marc.info/?l=git&m=116563135620359 and See also https://lore.kernel.org/git/7v64clg5u9.fsf@assigned-by-dhcp.cox.net/ and
http://marc.info/?l=git&m=119150393620273 for further https://lore.kernel.org/git/7vy7ej9g38.fsf@gitster.siamese.dyndns.org/ for further
information. information.
Some other commands that also work on files in the working tree and/or Some other commands that also work on files in the working tree and/or

Some files were not shown because too many files have changed in this diff Show More