зеркало из https://github.com/microsoft/git.git
Git 2.25-rc0
-----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
Коммит
173fff68da
|
|
@ -158,6 +158,7 @@
|
|||
/git-show-branch
|
||||
/git-show-index
|
||||
/git-show-ref
|
||||
/git-sparse-checkout
|
||||
/git-stage
|
||||
/git-stash
|
||||
/git-status
|
||||
|
|
|
|||
|
|
@ -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
|
||||
$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.
|
||||
|
||||
- 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
|
||||
definition whose last element is followed by a comma. This, like
|
||||
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
|
||||
initializers for struct (e.g. "struct t v = { .val = 'a' };").
|
||||
|
|
|
|||
|
|
@ -77,6 +77,7 @@ API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technica
|
|||
SP_ARTICLES += $(API_DOCS)
|
||||
|
||||
TECH_DOCS += MyFirstContribution
|
||||
TECH_DOCS += MyFirstObjectWalk
|
||||
TECH_DOCS += SubmittingPatches
|
||||
TECH_DOCS += technical/hash-function-transition
|
||||
TECH_DOCS += technical/http-protocol
|
||||
|
|
|
|||
|
|
@ -38,6 +38,26 @@ $ git clone https://github.com/git/git git
|
|||
$ cd git
|
||||
----
|
||||
|
||||
[[dependencies]]
|
||||
=== Installing Dependencies
|
||||
|
||||
To build Git from source, you need to have a handful of dependencies installed
|
||||
on your system. For a hint of what's needed, you can take a look at
|
||||
`INSTALL`, paying close attention to the section about Git's dependencies on
|
||||
external programs and libraries. That document mentions a way to "test-drive"
|
||||
our freshly built Git without installing; that's the method we'll be using in
|
||||
this tutorial.
|
||||
|
||||
Make sure that your environment has everything you need by building your brand
|
||||
new clone of Git from the above step:
|
||||
|
||||
----
|
||||
$ make
|
||||
----
|
||||
|
||||
NOTE: The Git build is parallelizable. `-j#` is not included above but you can
|
||||
use it as you prefer, here and elsewhere.
|
||||
|
||||
[[identify-problem]]
|
||||
=== Identify Problem to Solve
|
||||
|
||||
|
|
@ -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
|
||||
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.
|
||||
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
|
||||
you the rest of the options afterwards, untouched.
|
||||
|
||||
Now that you have a usage hint, you can teach Git how to show it in the general
|
||||
command list shown by `git help git` or `git help -a`, which is generated from
|
||||
`command-list.txt`. Find the line for 'git-pull' so you can add your 'git-psuh'
|
||||
line above it in alphabetical order. Now, we can add some attributes about the
|
||||
command which impacts where it shows up in the aforementioned help commands. The
|
||||
top of `command-list.txt` shares some information about what each attribute
|
||||
means; in those help pages, the commands are sorted according to these
|
||||
attributes. `git psuh` is user-facing, or porcelain - so we will mark it as
|
||||
"mainporcelain". For "mainporcelain" commands, the comments at the top of
|
||||
`command-list.txt` indicate we can also optionally add an attribute from another
|
||||
list; since `git psuh` shows some information about the user's workspace but
|
||||
doesn't modify anything, let's mark it as "info". Make sure to keep your
|
||||
attributes in the same style as the rest of `command-list.txt` using spaces to
|
||||
align and delineate them:
|
||||
|
||||
----
|
||||
git-prune-packed plumbingmanipulators
|
||||
git-psuh mainporcelain info
|
||||
git-pull mainporcelain remote
|
||||
git-push mainporcelain remote
|
||||
----
|
||||
|
||||
Build again. Now, when you run with `-h`, you should see your usage printed and
|
||||
your command terminated before anything else interesting happens. Great!
|
||||
|
||||
|
|
@ -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
|
||||
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
|
||||
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 can either note it when you send the first series, from the output of `git
|
||||
send-email`, or you can look it up on the
|
||||
https://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
|
||||
header. It should match:
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -251,7 +251,7 @@ Updates in v1.5.0 since v1.4.4 series
|
|||
the repository when that happens.
|
||||
|
||||
|
||||
* Crufts removal
|
||||
* Cruft removal
|
||||
|
||||
- We used to say "old commits are retrievable using reflog and
|
||||
'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
|
||||
repository is recorded in the commit object on the "encoding"
|
||||
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
|
||||
is determined by "git log --encoding=<encoding>",
|
||||
i18n.logoutputencoding configuration, or i18n.commitencoding
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ push running this release will issue a big warning when the
|
|||
configuration variable is missing. Please refer to:
|
||||
|
||||
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
|
||||
transition plan.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ push running this release will issue a big warning when the
|
|||
configuration variable is missing. Please refer to:
|
||||
|
||||
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
|
||||
transition plan.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ push running this release will issue a big warning when the
|
|||
configuration variable is missing. Please refer to:
|
||||
|
||||
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
|
||||
transition plan.
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Fixes since v1.6.5.3
|
|||
|
||||
* "git prune-packed" gave progress output even when its standard error is
|
||||
not connected to a terminal; this caused cron jobs that run it to
|
||||
produce crufts.
|
||||
produce cruft.
|
||||
|
||||
* "git pack-objects --all-progress" is an option to ask progress output
|
||||
from write-object phase _if_ progress output were to be produced, and
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ push running this release will issue a big warning when the
|
|||
configuration variable is missing. Please refer to:
|
||||
|
||||
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
|
||||
transition plan.
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ users will fare this time.
|
|||
Please refer to:
|
||||
|
||||
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
|
||||
transition process that already took place so far.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
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.
|
||||
|
||||
And other minor fixes and documentation updates.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Fixes since v1.7.10.3
|
|||
* The message file for Swedish translation has been updated a bit.
|
||||
|
||||
* A name taken from mailmap was copied into an internal buffer
|
||||
incorrectly and could 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
|
||||
middle could kill git with a NULL pointer dereference.
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ Fixes since v1.7.12.2
|
|||
its Accept-Encoding header.
|
||||
|
||||
* "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.
|
||||
|
||||
* "git status" honored the ignore=dirty settings in .gitmodules but
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ Fixes since v1.7.5.2
|
|||
* "git log --stdin path" with an input that has additional pathspec
|
||||
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.
|
||||
|
||||
* Compressed tarball gitweb generates used to be made with the timestamp
|
||||
|
|
|
|||
|
|
@ -233,7 +233,7 @@ to them for details).
|
|||
together, misdetected branches.
|
||||
|
||||
* "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 you misspell the command name you give to the "exec" action in
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Fixes since v1.8.4
|
|||
in 1.8.4-rc1).
|
||||
|
||||
* "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.
|
||||
|
||||
* Setting the "submodule.<name>.path" variable to the empty
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ Foreign interfaces, subsystems and ports.
|
|||
credential helper interface from Git.pm.
|
||||
|
||||
* 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.
|
||||
|
||||
* The credential helper to talk to keychain on OS X (in contrib/) has
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Git v2.1.3 Release Notes
|
|||
they are new enough to support the `--output` option.
|
||||
|
||||
* "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.
|
||||
|
||||
* "gitweb" used deprecated CGI::startfrom, which was removed from
|
||||
|
|
|
|||
|
|
@ -478,7 +478,7 @@ notes for details).
|
|||
* One part of "git am" had an oddball helper function that called
|
||||
stuff from outside "his" as opposed to calling what we have "ours",
|
||||
which was not gender-neutral and also inconsistent with the rest of
|
||||
the system where outside stuff is usuall called "theirs" in
|
||||
the system where outside stuff is usually called "theirs" in
|
||||
contrast to "ours".
|
||||
|
||||
* "git blame file" allowed the lineage of lines in the uncommitted,
|
||||
|
|
|
|||
|
|
@ -86,7 +86,7 @@ Fixes since v2.10.1
|
|||
by refusing to check out a branch that is already checked out in
|
||||
another worktree. However, this also prevented checking out a
|
||||
branch, which is designated as the primary branch of a bare
|
||||
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.
|
||||
|
||||
* "git rebase" immediately after "git clone" failed to find the fork
|
||||
|
|
|
|||
|
|
@ -104,7 +104,7 @@ Fixes since v2.11
|
|||
"git difftool --dir-diff" from a subdirectory never worked. This
|
||||
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
|
||||
by many empty commits. This has been fixed.
|
||||
|
||||
|
|
|
|||
|
|
@ -315,7 +315,7 @@ notes for details).
|
|||
"git difftool --dir-diff" from a subdirectory never worked. This
|
||||
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
|
||||
by many empty commits. This has been fixed.
|
||||
|
||||
|
|
|
|||
|
|
@ -177,7 +177,7 @@ UI, Workflows & Features
|
|||
been changed to enable "--decorate".
|
||||
|
||||
* 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
|
||||
to the working tree of the submodule but not the commit that is
|
||||
checked out.
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ Fixes since v2.13.2
|
|||
* The code to pick up and execute command alias definition from the
|
||||
configuration used to switch to the top of the working tree and
|
||||
then come back when the expanded alias was executed, which was
|
||||
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.
|
||||
|
||||
* "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
|
||||
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.
|
||||
|
||||
|
|
|
|||
|
|
@ -141,7 +141,7 @@ Performance, Internal Implementation, Development Support etc.
|
|||
* Some platforms have ulong that is smaller than time_t, and our
|
||||
historical use of ulong for timestamp would mean they cannot
|
||||
represent some timestamp that the platform allows. Invent a
|
||||
separate and dedicated timestamp_t (so that we can distingiuish
|
||||
separate and dedicated timestamp_t (so that we can distinguish
|
||||
timestamps and a vanilla ulongs, which along is already a good
|
||||
move), and then declare uintmax_t is the type to be used as the
|
||||
timestamp_t.
|
||||
|
|
@ -442,7 +442,7 @@ notes for details).
|
|||
* The code to pick up and execute command alias definition from the
|
||||
configuration used to switch to the top of the working tree and
|
||||
then come back when the expanded alias was executed, which was
|
||||
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.
|
||||
|
||||
* Fix configuration codepath to pay proper attention to commondir
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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`.
|
||||
|
|
@ -407,7 +407,7 @@ Fixes since v2.15
|
|||
(merge eef3df5a93 bw/pathspec-match-submodule-boundary later to maint).
|
||||
|
||||
* Amending commits in git-gui broke the author name that is non-ascii
|
||||
due to incorrect enconding conversion.
|
||||
due to incorrect encoding conversion.
|
||||
|
||||
* Recent update to the submodule configuration code broke "diff-tree"
|
||||
by accidentally stopping to read from the index upfront.
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ Fixes since v2.16.2
|
|||
|
||||
* The http tracing code, often used to debug connection issues,
|
||||
learned to redact potentially sensitive information from its output
|
||||
so that it can be more safely sharable.
|
||||
so that it can be more safely shareable.
|
||||
|
||||
* Crash fix for a corner case where an error codepath tried to unlock
|
||||
what it did not acquire lock on.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -216,7 +216,7 @@ Fixes since v2.16
|
|||
|
||||
* The http tracing code, often used to debug connection issues,
|
||||
learned to redact potentially sensitive information from its output
|
||||
so that it can be more safely sharable.
|
||||
so that it can be more safely shareable.
|
||||
(merge 8ba18e6fa4 jt/http-redact-cookies later to maint).
|
||||
|
||||
* Crash fix for a corner case where an error codepath tried to unlock
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -179,7 +179,7 @@ Performance, Internal Implementation, Development Support etc.
|
|||
(merge 00a3da2a13 nd/remove-ignore-env-field later to maint).
|
||||
|
||||
* Code to find the length to uniquely abbreviate object names based
|
||||
on packfile content, which is a relatively recent addtion, has been
|
||||
on packfile content, which is a relatively recent addition, has been
|
||||
optimized to use the same fan-out table.
|
||||
|
||||
* The mechanism to use parse-options API to automate the command line
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -106,7 +106,7 @@ Performance, Internal Implementation, Development Support etc.
|
|||
* The conversion to pass "the_repository" and then "a_repository"
|
||||
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
|
||||
codebase to report the list of configuration variables
|
||||
subcommands care about to help complete them.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -119,7 +119,7 @@ UI, Workflows & Features
|
|||
alias expansion.
|
||||
|
||||
* 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
|
||||
optimization.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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).
|
||||
|
|
@ -12,7 +12,7 @@ Fixes since v2.3.2
|
|||
* Description given by "grep -h" for its --exclude-standard option
|
||||
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
|
||||
the future will use the default behaviour when neither is given
|
||||
to override it.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Git v2.3.7 Release Notes
|
|||
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
|
||||
of the port number), e.g. ssh://example.com:/path/to/repo.
|
||||
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ Fixes since v2.4.3
|
|||
* Some time ago, "git blame" (incorrectly) lost the convert_to_git()
|
||||
call when synthesizing a fake "tip" commit that represents the
|
||||
state in the working tree, which broke folks who record the history
|
||||
with LF line ending to make their project portabile across
|
||||
with LF line ending to make their project portable across
|
||||
platforms while terminating lines in their working tree files with
|
||||
CRLF for their platform.
|
||||
|
||||
|
|
|
|||
|
|
@ -172,7 +172,8 @@ Performance, Internal Implementation, Development Support etc.
|
|||
incorrect patch text to "git apply". Add tests to demonstrate
|
||||
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
|
||||
what happens" back then).
|
||||
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ UI, Workflows & Features
|
|||
|
||||
* "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.
|
||||
|
||||
* Give progress meter to "git filter-branch".
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Fixes since v2.7.2
|
|||
tests.
|
||||
|
||||
* "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.
|
||||
|
||||
* "git rev-parse --git-common-dir" used in the worktree feature
|
||||
|
|
|
|||
|
|
@ -189,7 +189,7 @@ Performance, Internal Implementation, Development Support etc.
|
|||
* Some calls to strcpy(3) triggers a false warning from static
|
||||
analyzers that are less intelligent than humans, and reducing the
|
||||
number of these false hits helps us notice real issues. A few
|
||||
calls to strcpy(3) in a couple of 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.
|
||||
|
||||
* The "name_path" API was an attempt to reduce the need to construct
|
||||
|
|
|
|||
|
|
@ -55,8 +55,8 @@ Fixes since v2.8.2
|
|||
This is necessary to use Git on Windows shared directories, and is
|
||||
already enabled for the MinGW and plain Windows builds. It also
|
||||
has been used in Cygwin packaged versions of Git for quite a while.
|
||||
See http://thread.gmane.org/gmane.comp.version-control.git/291853
|
||||
and http://thread.gmane.org/gmane.comp.version-control.git/275680.
|
||||
See https://lore.kernel.org/git/20160419091055.GF2345@dinwoodie.org/
|
||||
and https://lore.kernel.org/git/20150811100527.GW14466@dinwoodie.org/.
|
||||
|
||||
* "git replace -e" did not honour "core.editor" configuration.
|
||||
|
||||
|
|
|
|||
|
|
@ -368,7 +368,7 @@ notes for details).
|
|||
This is necessary to use Git on Windows shared directories, and is
|
||||
already enabled for the MinGW and plain Windows builds. It also
|
||||
has been used in Cygwin packaged versions of Git for quite a while.
|
||||
See 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
|
||||
when merge begins.
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ Fixes since v2.9.2
|
|||
* One part of "git am" had an oddball helper function that called
|
||||
stuff from outside "his" as opposed to calling what we have "ours",
|
||||
which was not gender-neutral and also inconsistent with the rest of
|
||||
the system where outside stuff is usuall called "theirs" in
|
||||
the system where outside stuff is usually called "theirs" in
|
||||
contrast to "ours".
|
||||
|
||||
* The test framework learned a new helper test_match_signal to
|
||||
|
|
|
|||
|
|
@ -142,19 +142,25 @@ archive, summarize the relevant points of the discussion.
|
|||
|
||||
[[commit-reference]]
|
||||
If you want to reference a previous commit in the history of a stable
|
||||
branch, use the format "abbreviated sha1 (subject, date)",
|
||||
with the subject enclosed in a pair of double-quotes, like this:
|
||||
branch, use the format "abbreviated hash (subject, date)", 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 ...
|
||||
....
|
||||
|
||||
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]]
|
||||
|
|
|
|||
|
|
@ -142,7 +142,7 @@ refer to linkgit:gitignore[5] for details. For convenience:
|
|||
|
||||
`gitdir/i`::
|
||||
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`::
|
||||
The data that follows the keyword `onbranch:` is taken to be a
|
||||
|
|
|
|||
|
|
@ -5,3 +5,8 @@ add.ignore-errors (deprecated)::
|
|||
option of linkgit:git-add[1]. `add.ignore-errors` is deprecated,
|
||||
as it does not follow the usual naming convention for configuration
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -107,4 +107,7 @@ advice.*::
|
|||
editor input from the user.
|
||||
nestedTag::
|
||||
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.
|
||||
--
|
||||
|
|
|
|||
|
|
@ -559,6 +559,12 @@ core.unsetenvvars::
|
|||
Defaults to `PERL5LIB` to account for the fact that Git for
|
||||
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::
|
||||
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
|
||||
|
|
@ -593,8 +599,14 @@ core.multiPackIndex::
|
|||
multi-pack-index design document].
|
||||
|
||||
core.sparseCheckout::
|
||||
Enable "sparse checkout" feature. See section "Sparse checkout" in
|
||||
linkgit:git-read-tree[1] for more information.
|
||||
Enable "sparse checkout" feature. See linkgit:git-sparse-checkout[1]
|
||||
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::
|
||||
Set the length object names are abbreviated to. If
|
||||
|
|
|
|||
|
|
@ -36,6 +36,12 @@ format.subjectPrefix::
|
|||
The default for format-patch is to output files with the '[PATCH]'
|
||||
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::
|
||||
The default for format-patch is to output a signature containing
|
||||
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.
|
||||
+
|
||||
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`.
|
||||
|
|
|
|||
|
|
@ -79,4 +79,6 @@ submodule.alternateLocation::
|
|||
submodule.alternateErrorStrategy::
|
||||
Specifies how to treat errors with the alternates for a submodule
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ tag.gpgSign::
|
|||
Use of this option when running in an automated script can
|
||||
result in a large number of tags being signed. It is therefore
|
||||
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.
|
||||
|
||||
tar.umask::
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ Possible status letters are:
|
|||
- R: renaming of a file
|
||||
- T: change in the type of the file
|
||||
- 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)
|
||||
|
||||
Status letters C and R are always followed by a score (denoting the
|
||||
|
|
|
|||
|
|
@ -92,6 +92,10 @@ ifndef::git-pull[]
|
|||
Run `git gc --auto` at the end to perform garbage collection
|
||||
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::
|
||||
--prune::
|
||||
Before fetching, remove any remote-tracking references that no
|
||||
|
|
|
|||
|
|
@ -11,7 +11,8 @@ SYNOPSIS
|
|||
'git add' [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p]
|
||||
[--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]]
|
||||
[--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--renormalize]
|
||||
[--chmod=(+|-)x] [--] [<pathspec>...]
|
||||
[--chmod=(+|-)x] [--pathspec-from-file=<file> [--pathspec-file-nul]]
|
||||
[--] [<pathspec>...]
|
||||
|
||||
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
|
||||
unchanged.
|
||||
|
||||
--pathspec-from-file=<file>::
|
||||
Pathspec is passed in `<file>` instead of commandline args. If
|
||||
`<file>` is exactly `-` then standard input is used. Pathspec
|
||||
elements are separated by LF or CR/LF. Pathspec elements can be
|
||||
quoted as explained for the configuration variable `core.quotePath`
|
||||
(see linkgit:git-config[1]). See also `--pathspec-file-nul` and
|
||||
global `--literal-pathspecs`.
|
||||
|
||||
--pathspec-file-nul::
|
||||
Only meaningful with `--pathspec-from-file`. Pathspec elements are
|
||||
separated with NUL character and all other characters are taken
|
||||
literally (including newlines and quotes).
|
||||
|
||||
\--::
|
||||
This option can be used to separate command-line options from
|
||||
the list of files, (useful when filenames might be mistaken
|
||||
|
|
|
|||
|
|
@ -177,7 +177,7 @@ default. You can use `--no-utf8` to override this.
|
|||
untouched.
|
||||
|
||||
--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.
|
||||
|
||||
DISCUSSION
|
||||
|
|
|
|||
|
|
@ -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
|
||||
commit. This means that they are not very efficient, because many
|
||||
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
|
||||
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.
|
||||
- [[[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.]
|
||||
- [[[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.]
|
||||
- [[[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.]
|
||||
- [[[9]]] https://github.com/Ealdwulf/bbchop[Ealdwulf. 'bbchop'. GitHub.]
|
||||
|
|
|
|||
|
|
@ -413,7 +413,7 @@ $ cat ~/test.sh
|
|||
|
||||
# tweak the working tree by merging the hot-fix branch
|
||||
# and then attempt a build
|
||||
if git merge --no-commit hot-fix &&
|
||||
if git merge --no-commit --no-ff hot-fix &&
|
||||
make
|
||||
then
|
||||
# run project specific test and report its status
|
||||
|
|
|
|||
|
|
@ -9,8 +9,8 @@ git-bundle - Move objects and refs by archive
|
|||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'git bundle' create <file> <git-rev-list-args>
|
||||
'git bundle' verify <file>
|
||||
'git bundle' create [-q | --quiet | --progress | --all-progress] [--all-progress-implied] <file> <git-rev-list-args>
|
||||
'git bundle' verify [-q | --quiet] <file>
|
||||
'git bundle' list-heads <file> [<refname>...]
|
||||
'git bundle' unbundle <file> [<refname>...]
|
||||
|
||||
|
|
@ -20,11 +20,14 @@ DESCRIPTION
|
|||
Some workflows require that one or more branches of development on one
|
||||
machine be replicated on another machine, but the two machines cannot
|
||||
be directly connected, and therefore the interactive Git protocols (git,
|
||||
ssh, http) cannot be used. This command provides support for
|
||||
'git fetch' and 'git pull' to operate by packaging objects and references
|
||||
in an archive at the originating machine, then importing those into
|
||||
another repository using 'git fetch' and 'git pull'
|
||||
after moving the archive by some means (e.g., by sneakernet). As no
|
||||
ssh, http) cannot be used.
|
||||
|
||||
The 'git bundle' command packages objects and references in an archive
|
||||
at the originating machine, which can then be imported into another
|
||||
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
|
||||
basis for the bundle that is held by the destination repository: the
|
||||
bundle assumes that all objects in the basis are already in the
|
||||
|
|
@ -33,9 +36,11 @@ destination repository.
|
|||
OPTIONS
|
||||
-------
|
||||
|
||||
create <file>::
|
||||
create [options] <file> <git-rev-list-args>::
|
||||
Used to create a bundle named 'file'. This requires the
|
||||
'git-rev-list-args' arguments to define the bundle contents.
|
||||
'<git-rev-list-args>' arguments to define the bundle contents.
|
||||
'options' contains the options specific to the 'git bundle create'
|
||||
subcommand.
|
||||
|
||||
verify <file>::
|
||||
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
|
||||
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
|
||||
---------------------
|
||||
|
||||
|
|
@ -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
|
||||
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
|
||||
--------
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ OPTIONS
|
|||
instead of from the command-line.
|
||||
|
||||
-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
|
||||
with a NUL character instead of a linefeed character.
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ OPTIONS
|
|||
instead of from the command-line.
|
||||
|
||||
-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
|
||||
with a NUL character instead of a linefeed character.
|
||||
|
||||
|
|
|
|||
|
|
@ -12,14 +12,14 @@ SYNOPSIS
|
|||
'git checkout' [-q] [-f] [-m] --detach [<branch>]
|
||||
'git checkout' [-q] [-f] [-m] [--detach] <commit>
|
||||
'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
|
||||
'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
|
||||
'git checkout' [<tree-ish>] [--] <pathspec>...
|
||||
'git checkout' (-p|--patch) [<tree-ish>] [--] [<paths>...]
|
||||
'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]
|
||||
'git checkout' (-p|--patch) [<tree-ish>] [--] [<pathspec>...]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Updates files in the working tree to match the version in the index
|
||||
or the specified tree. If no 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
|
||||
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.
|
||||
|
||||
'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
|
||||
contents in the index or in the `<tree-ish>` (most often a
|
||||
commit). When a `<tree-ish>` is given, the paths that
|
||||
match the `<pathspec>` are updated both in the index and in
|
||||
the working tree.
|
||||
Overwrite the contents of the files that match the pathspec.
|
||||
When the `<tree-ish>` (most often a commit) is not given,
|
||||
overwrite working tree with the contents in the index.
|
||||
When the `<tree-ish>` is given, overwrite both the index and
|
||||
the working tree with the contents at the `<tree-ish>`.
|
||||
+
|
||||
The index may contain unmerged entries because of a previous failed merge.
|
||||
By default, if you try to check out such an entry from the index, the
|
||||
|
|
@ -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.
|
||||
|
||||
'git checkout' (-p|--patch) [<tree-ish>] [--] [<pathspec>...]::
|
||||
This is similar to the "check out paths to the working tree
|
||||
from either the index or from a tree-ish" mode described
|
||||
above, but lets you use the interactive interface to show
|
||||
the "diff" output and choose which hunks to use in the
|
||||
result. See below for the description of `--patch` option.
|
||||
|
||||
This is similar to the previous mode, but lets you use the
|
||||
interactive interface to show the "diff" output and choose which
|
||||
hunks to use in the result. See below for the description of
|
||||
`--patch` option.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
|
@ -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
|
||||
match `<tree-ish>` exactly.
|
||||
|
||||
--pathspec-from-file=<file>::
|
||||
Pathspec is passed in `<file>` instead of commandline args. If
|
||||
`<file>` is exactly `-` then standard input is used. Pathspec
|
||||
elements are separated by LF or CR/LF. Pathspec elements can be
|
||||
quoted as explained for the configuration variable `core.quotePath`
|
||||
(see linkgit:git-config[1]). See also `--pathspec-file-nul` and
|
||||
global `--literal-pathspecs`.
|
||||
|
||||
--pathspec-file-nul::
|
||||
Only meaningful with `--pathspec-from-file`. Pathspec elements are
|
||||
separated with NUL character and all other characters are taken
|
||||
literally (including newlines and quotes).
|
||||
|
||||
<branch>::
|
||||
Branch to checkout; if it refers to a branch (i.e., a name that,
|
||||
when prepended with "refs/heads/", is a valid ref), then that
|
||||
|
|
@ -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,
|
||||
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
|
||||
-------------
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ SYNOPSIS
|
|||
[--dissociate] [--separate-git-dir <git dir>]
|
||||
[--depth <depth>] [--[no-]single-branch] [--no-tags]
|
||||
[--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules]
|
||||
[--[no-]remote-submodules] [--jobs <n>] [--] <repository>
|
||||
[--[no-]remote-submodules] [--jobs <n>] [--sparse] [--] <repository>
|
||||
[<directory>]
|
||||
|
||||
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
|
||||
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::
|
||||
Set up a mirror of the source repository. This implies `--bare`.
|
||||
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.
|
||||
|
||||
--[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
|
||||
superproject’s recorded SHA-1. Equivalent to passing `--remote` to
|
||||
superproject's recorded SHA-1. Equivalent to passing `--remote` to
|
||||
`git submodule update`.
|
||||
|
||||
--separate-git-dir=<git dir>::
|
||||
|
|
|
|||
|
|
@ -9,7 +9,6 @@ git-commit-graph - Write and verify Git commit-graph files
|
|||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'git commit-graph read' [--object-dir <dir>]
|
||||
'git commit-graph verify' [--object-dir <dir>] [--shallow] [--[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
|
||||
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'::
|
||||
|
||||
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
|
||||
------------------------------------------------
|
||||
|
||||
* Read basic information from the commit-graph file.
|
||||
+
|
||||
------------------------------------------------
|
||||
$ git commit-graph read
|
||||
------------------------------------------------
|
||||
|
||||
|
||||
GIT
|
||||
---
|
||||
|
|
|
|||
|
|
@ -13,7 +13,8 @@ SYNOPSIS
|
|||
[-F <file> | -m <msg>] [--reset-author] [--allow-empty]
|
||||
[--allow-empty-message] [--no-verify] [-e] [--author=<author>]
|
||||
[--date=<date>] [--cleanup=<mode>] [--[no-]status]
|
||||
[-i | -o] [-S[<keyid>]] [--] [<file>...]
|
||||
[-i | -o] [--pathspec-from-file=<file> [--pathspec-file-nul]]
|
||||
[-S[<keyid>]] [--] [<pathspec>...]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
|
@ -278,6 +279,19 @@ FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
|
|||
already been staged. If used together with `--allow-empty`
|
||||
paths are also not required, and an empty commit will be created.
|
||||
|
||||
--pathspec-from-file=<file>::
|
||||
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>]::
|
||||
--untracked-files[=<mode>]::
|
||||
Show untracked files.
|
||||
|
|
@ -345,12 +359,13 @@ changes to tracked files.
|
|||
\--::
|
||||
Do not interpret any more arguments as options.
|
||||
|
||||
<file>...::
|
||||
When files are given on the command line, the command
|
||||
commits the contents of the named files, without
|
||||
recording the changes already staged. The contents of
|
||||
these files are also staged for the next commit on top
|
||||
of what have been staged before.
|
||||
<pathspec>...::
|
||||
When pathspec is given on the command line, commit the contents of
|
||||
the files that match the pathspec without recording the changes
|
||||
already added to the index. The contents of these files are also
|
||||
staged for the next commit on top of what have been staged before.
|
||||
+
|
||||
For more details, see the 'pathspec' entry in linkgit:gitglossary[7].
|
||||
|
||||
:git-commit: 1
|
||||
include::date-formats.txt[]
|
||||
|
|
|
|||
|
|
@ -19,8 +19,7 @@ from system-specific helpers, as well as prompting the user for
|
|||
usernames and passwords. The git-credential command exposes this
|
||||
interface to scripts which may want to retrieve, store, or prompt for
|
||||
credentials in the same manner as Git. The design of this scriptable
|
||||
interface models the internal C API; see
|
||||
link:technical/api-credentials.html[the Git credential API] for more
|
||||
interface models the internal C API; see credential.h for more
|
||||
background on the concepts.
|
||||
|
||||
git-credential takes an "action" option on the command-line (one of
|
||||
|
|
|
|||
|
|
@ -294,7 +294,7 @@ In `dbDriver` and `dbUser` you can use the following variables:
|
|||
Git directory name
|
||||
%g::
|
||||
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
|
||||
name in a filename if wanted)
|
||||
%m::
|
||||
|
|
|
|||
|
|
@ -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
|
||||
at least one of the paths points outside the 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>...]::
|
||||
|
||||
|
|
|
|||
|
|
@ -142,7 +142,7 @@ by keeping the marks the same across runs.
|
|||
Specify how to handle `encoding` header in commit objects. When
|
||||
asking to 'abort' (which is the default), this program will die
|
||||
when encountering such a commit object. With 'yes', the commit
|
||||
message will be reencoded into UTF-8. With 'no', the original
|
||||
message will be re-encoded into UTF-8. With 'no', the original
|
||||
encoding will be preserved.
|
||||
|
||||
--refspec::
|
||||
|
|
|
|||
|
|
@ -51,6 +51,21 @@ OPTIONS
|
|||
memory used by fast-import during this run. Showing this output
|
||||
is currently the default, but can be disabled with --quiet.
|
||||
|
||||
--allow-unsafe-features::
|
||||
Many command-line options can be provided as part of the
|
||||
fast-import stream itself by using the `feature` or `option`
|
||||
commands. However, some of these options are unsafe (e.g.,
|
||||
allowing fast-import to access the filesystem outside of the
|
||||
repository). These options are disabled by default, but can be
|
||||
allowed by providing this option on the command line. This
|
||||
currently impacts only the `export-marks`, `import-marks`, and
|
||||
`import-marks-if-exists` feature commands.
|
||||
+
|
||||
Only enable this option if you trust the program generating the
|
||||
fast-import stream! This option is enabled automatically for
|
||||
remote-helpers that use the `import` capability, as they are
|
||||
already trusted to run their own code.
|
||||
|
||||
Options for Frontends
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
* In editing files, git-filter-branch by design checks out each and
|
||||
every commit as it existed in the original repo. If your repo has 10\^5
|
||||
files and 10\^5 commits, but each commit only modifies 5 files, then
|
||||
git-filter-branch will make you do 10\^10 modifications, despite only
|
||||
having (at most) 5*10^5 unique blobs.
|
||||
every commit as it existed in the original repo. If your repo has
|
||||
10\^5 files and 10\^5 commits, but each commit only modifies 5
|
||||
files, then git-filter-branch will make you do 10\^10 modifications,
|
||||
despite only having (at most) 5*10^5 unique blobs.
|
||||
|
||||
* If you try and cheat and try to make git-filter-branch only work on
|
||||
files modified in a commit, then two things happen
|
||||
files modified in a commit, then two things happen
|
||||
|
||||
** you run into problems with deletions whenever the user is simply
|
||||
trying to rename files (because attempting to delete files that
|
||||
|
|
@ -481,39 +481,41 @@ files modified in a commit, then two things happen
|
|||
user-provided shell)
|
||||
|
||||
** even if you succeed at the map-deletes-for-renames chicanery, you
|
||||
still technically violate backward compatibility because users are
|
||||
allowed to filter files in ways that depend upon topology of
|
||||
commits instead of filtering solely based on file contents or names
|
||||
(though this has not been observed in the wild).
|
||||
still technically violate backward compatibility because users
|
||||
are allowed to filter files in ways that depend upon topology of
|
||||
commits instead of filtering solely based on file contents or
|
||||
names (though this has not been observed in the wild).
|
||||
|
||||
* Even if you don't need to edit files but only want to e.g. rename or
|
||||
remove some and thus can avoid checking out each file (i.e. you can use
|
||||
--index-filter), you still are passing shell snippets for your filters.
|
||||
This means that for every commit, you have to have a prepared git repo
|
||||
where those filters can be run. That's a significant setup.
|
||||
remove some and thus can avoid checking out each file (i.e. you can
|
||||
use --index-filter), you still are passing shell snippets for your
|
||||
filters. This means that for every commit, you have to have a
|
||||
prepared git repo where those filters can be run. That's a
|
||||
significant setup.
|
||||
|
||||
* Further, several additional files are created or updated per commit by
|
||||
git-filter-branch. Some of these are for supporting the convenience
|
||||
functions provided by git-filter-branch (such as map()), while others
|
||||
are for keeping track of internal state (but could have also been
|
||||
accessed by user filters; one of git-filter-branch's regression tests
|
||||
does so). This essentially amounts to using the filesystem as an IPC
|
||||
mechanism between git-filter-branch and the user-provided filters.
|
||||
Disks tend to be a slow IPC mechanism, and writing these files also
|
||||
effectively represents a forced synchronization point between separate
|
||||
processes that we hit with every commit.
|
||||
* Further, several additional files are created or updated per commit
|
||||
by git-filter-branch. Some of these are for supporting the
|
||||
convenience functions provided by git-filter-branch (such as map()),
|
||||
while others are for keeping track of internal state (but could have
|
||||
also been accessed by user filters; one of git-filter-branch's
|
||||
regression tests does so). This essentially amounts to using the
|
||||
filesystem as an IPC mechanism between git-filter-branch and the
|
||||
user-provided filters. Disks tend to be a slow IPC mechanism, and
|
||||
writing these files also effectively represents a forced
|
||||
synchronization point between separate processes that we hit with
|
||||
every commit.
|
||||
|
||||
* The user-provided shell commands will likely involve a pipeline of
|
||||
commands, resulting in the creation of many processes per commit.
|
||||
Creating and running another process takes a widely varying amount of
|
||||
time between operating systems, but on any platform it is very slow
|
||||
relative to invoking a function.
|
||||
commands, resulting in the creation of many processes per commit.
|
||||
Creating and running another process takes a widely varying amount
|
||||
of time between operating systems, but on any platform it is very
|
||||
slow relative to invoking a function.
|
||||
|
||||
* git-filter-branch itself is written in shell, which is kind of slow.
|
||||
This is the one performance issue that could be backward-compatibly
|
||||
fixed, but compared to the above problems that are intrinsic to the
|
||||
design of git-filter-branch, the language of the tool itself is a
|
||||
relatively minor issue.
|
||||
This is the one performance issue that could be backward-compatibly
|
||||
fixed, but compared to the above problems that are intrinsic to the
|
||||
design of git-filter-branch, the language of the tool itself is a
|
||||
relatively minor issue.
|
||||
|
||||
** Side note: Unfortunately, people tend to fixate on the
|
||||
written-in-shell aspect and periodically ask if git-filter-branch
|
||||
|
|
@ -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],
|
||||
a drop-in git-filter-branch replacement (with a few caveats). While
|
||||
filter-lamely suffers from all the same safety issues as
|
||||
git-filter-branch, it at least ameloriates the performance issues a
|
||||
git-filter-branch, it at least ameliorates the performance issues a
|
||||
little.
|
||||
|
||||
[[SAFETY]]
|
||||
|
|
@ -546,51 +548,55 @@ easily corrupt repos or end up with a mess worse than what you started
|
|||
with:
|
||||
|
||||
* Someone can have a set of "working and tested filters" which they
|
||||
document or provide to a coworker, who then runs them on a different OS
|
||||
where the same commands are not working/tested (some examples in the
|
||||
git-filter-branch manpage are also affected by this). BSD vs. GNU
|
||||
userland differences can really bite. If lucky, error messages are
|
||||
spewed. But just as likely, the commands either don't do the filtering
|
||||
requested, or silently corrupt by making some unwanted change. The
|
||||
unwanted change may only affect a few commits, so it's not necessarily
|
||||
obvious either. (The fact that problems won't necessarily be obvious
|
||||
means they are likely to go unnoticed until the rewritten history is in
|
||||
use for quite a while, at which point it's really hard to justify
|
||||
another flag-day for another rewrite.)
|
||||
document or provide to a coworker, who then runs them on a different
|
||||
OS where the same commands are not working/tested (some examples in
|
||||
the git-filter-branch manpage are also affected by this).
|
||||
BSD vs. GNU userland differences can really bite. If lucky, error
|
||||
messages are spewed. But just as likely, the commands either don't
|
||||
do the filtering requested, or silently corrupt by making some
|
||||
unwanted change. The unwanted change may only affect a few commits,
|
||||
so it's not necessarily obvious either. (The fact that problems
|
||||
won't necessarily be obvious means they are likely to go unnoticed
|
||||
until the rewritten history is in use for quite a while, at which
|
||||
point it's really hard to justify another flag-day for another
|
||||
rewrite.)
|
||||
|
||||
* Filenames with spaces are often mishandled by shell snippets since
|
||||
they cause problems for shell pipelines. Not everyone is familiar with
|
||||
find -print0, xargs -0, git-ls-files -z, etc. Even people who are
|
||||
familiar with these may assume such flags are not relevant because
|
||||
someone else renamed any such files in their repo back before the person
|
||||
doing the filtering joined the project. And often, even those familiar
|
||||
with handling arguments with spaces may not do so just because they
|
||||
aren't in the mindset of thinking about everything that could possibly
|
||||
go wrong.
|
||||
they cause problems for shell pipelines. Not everyone is familiar
|
||||
with find -print0, xargs -0, git-ls-files -z, etc. Even people who
|
||||
are familiar with these may assume such flags are not relevant
|
||||
because someone else renamed any such files in their repo back
|
||||
before the person doing the filtering joined the project. And
|
||||
often, even those familiar with handling arguments with spaces may
|
||||
not do so just because they aren't in the mindset of thinking about
|
||||
everything that could possibly go wrong.
|
||||
|
||||
* Non-ascii filenames can be silently removed despite being in a desired
|
||||
directory. Keeping only wanted paths is often done using pipelines like
|
||||
`git ls-files | grep -v ^WANTED_DIR/ | xargs git rm`. ls-files will
|
||||
only quote filenames if needed, so folks may not notice that one of the
|
||||
files didn't match the regex (at least not until it's much too late).
|
||||
Yes, someone who knows about core.quotePath can avoid this (unless they
|
||||
have other special characters like \t, \n, or "), and people who use
|
||||
ls-files -z with something other than grep can avoid this, but that
|
||||
doesn't mean they will.
|
||||
* Non-ascii filenames can be silently removed despite being in a
|
||||
desired directory. Keeping only wanted paths is often done using
|
||||
pipelines like `git ls-files | grep -v ^WANTED_DIR/ | xargs git rm`.
|
||||
ls-files will only quote filenames if needed, so folks may not
|
||||
notice that one of the files didn't match the regex (at least not
|
||||
until it's much too late). Yes, someone who knows about
|
||||
core.quotePath can avoid this (unless they have other special
|
||||
characters like \t, \n, or "), and people who use ls-files -z with
|
||||
something other than grep can avoid this, but that doesn't mean they
|
||||
will.
|
||||
|
||||
* Similarly, when moving files around, one can find that filenames with
|
||||
non-ascii or special characters end up in a different directory, one
|
||||
that includes a double quote character. (This is technically the same
|
||||
issue as above with quoting, but perhaps an interesting different way
|
||||
that it can and has manifested as a problem.)
|
||||
* Similarly, when moving files around, one can find that filenames
|
||||
with non-ascii or special characters end up in a different
|
||||
directory, one that includes a double quote character. (This is
|
||||
technically the same issue as above with quoting, but perhaps an
|
||||
interesting different way that it can and has manifested as a
|
||||
problem.)
|
||||
|
||||
* It's far too easy to accidentally mix up old and new history. It's
|
||||
still possible with any tool, but git-filter-branch almost invites it.
|
||||
If lucky, the only downside is users getting frustrated that they don't
|
||||
know how to shrink their repo and remove the old stuff. If unlucky,
|
||||
they merge old and new history and end up with multiple "copies" of each
|
||||
commit, some of which have unwanted or sensitive files and others which
|
||||
don't. This comes about in multiple different ways:
|
||||
still possible with any tool, but git-filter-branch almost
|
||||
invites it. If lucky, the only downside is users getting frustrated
|
||||
that they don't know how to shrink their repo and remove the old
|
||||
stuff. If unlucky, they merge old and new history and end up with
|
||||
multiple "copies" of each commit, some of which have unwanted or
|
||||
sensitive files and others which don't. This comes about in
|
||||
multiple different ways:
|
||||
|
||||
** the default to only doing a partial history rewrite ('--all' is not
|
||||
the default and few examples show it)
|
||||
|
|
@ -609,8 +615,8 @@ don't. This comes about in multiple different ways:
|
|||
"DISCUSSION" section of the git filter-repo manual page for more
|
||||
details.
|
||||
|
||||
* Annotated tags can be accidentally converted to lightweight tags, due
|
||||
to either of two issues:
|
||||
* Annotated tags can be accidentally converted to lightweight tags,
|
||||
due to either of two issues:
|
||||
|
||||
** Someone can do a history rewrite, realize they messed up, restore
|
||||
from the backups in refs/original/, and then redo their
|
||||
|
|
@ -623,71 +629,74 @@ to either of two issues:
|
|||
restored from refs/original/ in a previously botched rewrite).
|
||||
|
||||
* Any commit messages that specify an encoding will become corrupted
|
||||
by the rewrite; git-filter-branch ignores the encoding, takes the original
|
||||
bytes, and feeds it to commit-tree without telling it the proper
|
||||
encoding. (This happens whether or not --msg-filter is used.)
|
||||
by the rewrite; git-filter-branch ignores the encoding, takes the
|
||||
original bytes, and feeds it to commit-tree without telling it the
|
||||
proper encoding. (This happens whether or not --msg-filter is
|
||||
used.)
|
||||
|
||||
* Commit messages (even if they are all UTF-8) by default become
|
||||
corrupted due to not being updated -- any references to other commit
|
||||
hashes in commit messages will now refer to no-longer-extant commits.
|
||||
corrupted due to not being updated -- any references to other commit
|
||||
hashes in commit messages will now refer to no-longer-extant
|
||||
commits.
|
||||
|
||||
* There are no facilities for helping users find what unwanted crud they
|
||||
should delete, which means they are much more likely to have incomplete
|
||||
or partial cleanups that sometimes result in confusion and people
|
||||
wasting time trying to understand. (For example, folks tend to just
|
||||
look for big files to delete instead of big directories or extensions,
|
||||
and once they do so, then sometime later folks using the new repository
|
||||
who are going through history will notice a build artifact directory
|
||||
that has some files but not others, or a cache of dependencies
|
||||
(node_modules or similar) which couldn't have ever been functional since
|
||||
it's missing some files.)
|
||||
* There are no facilities for helping users find what unwanted crud
|
||||
they should delete, which means they are much more likely to have
|
||||
incomplete or partial cleanups that sometimes result in confusion
|
||||
and people wasting time trying to understand. (For example, folks
|
||||
tend to just look for big files to delete instead of big directories
|
||||
or extensions, and once they do so, then sometime later folks using
|
||||
the new repository who are going through history will notice a build
|
||||
artifact directory that has some files but not others, or a cache of
|
||||
dependencies (node_modules or similar) which couldn't have ever been
|
||||
functional since it's missing some files.)
|
||||
|
||||
* If --prune-empty isn't specified, then the filtering process can
|
||||
create hoards of confusing empty commits
|
||||
create hoards of confusing empty commits
|
||||
|
||||
* If --prune-empty is specified, then intentionally placed empty
|
||||
commits from before the filtering operation are also pruned instead of
|
||||
just pruning commits that became empty due to filtering rules.
|
||||
commits from before the filtering operation are also pruned instead
|
||||
of just pruning commits that became empty due to filtering rules.
|
||||
|
||||
* If --prune empty is specified, sometimes empty commits are missed
|
||||
and left around anyway (a somewhat rare bug, but it happens...)
|
||||
* If --prune-empty is specified, sometimes empty commits are missed
|
||||
and left around anyway (a somewhat rare bug, but it happens...)
|
||||
|
||||
* A minor issue, but users who have a goal to update all names and
|
||||
emails in a repository may be led to --env-filter which will only update
|
||||
authors and committers, missing taggers.
|
||||
emails in a repository may be led to --env-filter which will only
|
||||
update authors and committers, missing taggers.
|
||||
|
||||
* If the user provides a --tag-name-filter that maps multiple tags to
|
||||
the same name, no warning or error is provided; git-filter-branch simply
|
||||
overwrites each tag in some undocumented pre-defined order resulting in
|
||||
only one tag at the end. (A git-filter-branch regression test requires
|
||||
this surprising behavior.)
|
||||
the same name, no warning or error is provided; git-filter-branch
|
||||
simply overwrites each tag in some undocumented pre-defined order
|
||||
resulting in only one tag at the end. (A git-filter-branch
|
||||
regression test requires this surprising behavior.)
|
||||
|
||||
Also, the poor performance of git-filter-branch often leads to safety
|
||||
issues:
|
||||
|
||||
* Coming up with the correct shell snippet to do the filtering you want
|
||||
is sometimes difficult unless you're just doing a trivial modification
|
||||
such as deleting a couple files. Unfortunately, people often learn if
|
||||
the snippet is right or wrong by trying it out, but the rightness or
|
||||
wrongness can vary depending on special circumstances (spaces in
|
||||
filenames, non-ascii filenames, funny author names or emails, invalid
|
||||
timezones, presence of grafts or replace objects, etc.), meaning they
|
||||
may have to wait a long time, hit an error, then restart. The
|
||||
performance of git-filter-branch is so bad that this cycle is painful,
|
||||
reducing the time available to carefully re-check (to say nothing about
|
||||
what it does to the patience of the person doing the rewrite even if
|
||||
they do technically have more time available). This problem is extra
|
||||
compounded because errors from broken filters may not be shown for a
|
||||
long time and/or get lost in a sea of output. Even worse, broken
|
||||
filters often just result in silent incorrect rewrites.
|
||||
* Coming up with the correct shell snippet to do the filtering you
|
||||
want is sometimes difficult unless you're just doing a trivial
|
||||
modification such as deleting a couple files. Unfortunately, people
|
||||
often learn if the snippet is right or wrong by trying it out, but
|
||||
the rightness or wrongness can vary depending on special
|
||||
circumstances (spaces in filenames, non-ascii filenames, funny
|
||||
author names or emails, invalid timezones, presence of grafts or
|
||||
replace objects, etc.), meaning they may have to wait a long time,
|
||||
hit an error, then restart. The performance of git-filter-branch is
|
||||
so bad that this cycle is painful, reducing the time available to
|
||||
carefully re-check (to say nothing about what it does to the
|
||||
patience of the person doing the rewrite even if they do technically
|
||||
have more time available). This problem is extra compounded because
|
||||
errors from broken filters may not be shown for a long time and/or
|
||||
get lost in a sea of output. Even worse, broken filters often just
|
||||
result in silent incorrect rewrites.
|
||||
|
||||
* To top it all off, even when users finally find working commands, they
|
||||
naturally want to share them. But they may be unaware that their repo
|
||||
didn't have some special cases that someone else's does. So, when
|
||||
someone else with a different repository runs the same commands, they
|
||||
get hit by the problems above. Or, the user just runs commands that
|
||||
really were vetted for special cases, but they run it on a different OS
|
||||
where it doesn't work, as noted above.
|
||||
* To top it all off, even when users finally find working commands,
|
||||
they naturally want to share them. But they may be unaware that
|
||||
their repo didn't have some special cases that someone else's does.
|
||||
So, when someone else with a different repository runs the same
|
||||
commands, they get hit by the problems above. Or, the user just
|
||||
runs commands that really were vetted for special cases, but they
|
||||
run it on a different OS where it doesn't work, as noted above.
|
||||
|
||||
GIT
|
||||
---
|
||||
|
|
|
|||
|
|
@ -19,6 +19,7 @@ SYNOPSIS
|
|||
[--start-number <n>] [--numbered-files]
|
||||
[--in-reply-to=<message id>] [--suffix=.<sfx>]
|
||||
[--ignore-if-in-upstream]
|
||||
[--cover-from-description=<mode>]
|
||||
[--rfc] [--subject-prefix=<subject prefix>]
|
||||
[(--reroll-count|-v) <n>]
|
||||
[--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
|
||||
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>::
|
||||
Instead of the standard '[PATCH]' prefix in the subject
|
||||
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
|
||||
of the hash of the commit.
|
||||
|
||||
--base=<commit>::
|
||||
--[no-]base[=<commit>]::
|
||||
Record the base tree information to identify the state the
|
||||
patch series applies to. See the BASE TREE INFORMATION section
|
||||
below for details. If <commit> is "auto", a base commit is
|
||||
automatically chosen.
|
||||
automatically chosen. The `--no-base` option overrides a
|
||||
`format.useAutoBase` configuration.
|
||||
|
||||
--root::
|
||||
Treat the revision argument as a <revision range>, even if it
|
||||
|
|
@ -348,6 +370,7 @@ with configuration variables.
|
|||
signOff = true
|
||||
outputDirectory = <directory>
|
||||
coverLetter = auto
|
||||
coverFromDescription = auto
|
||||
------------
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ git-multi-pack-index - Write and verify multi-pack-indexes
|
|||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'git multi-pack-index' [--object-dir=<dir>] <subcommand>
|
||||
'git multi-pack-index' [--object-dir=<dir>] [--[no-]progress] <subcommand>
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
|
@ -23,6 +23,10 @@ OPTIONS
|
|||
`<dir>/packs/multi-pack-index` for the current MIDX file, and
|
||||
`<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:
|
||||
|
||||
write::
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ SYNOPSIS
|
|||
[verse]
|
||||
'git notes' [list [<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' edit [--allow-empty] [<object>]
|
||||
'git notes' show [<object>]
|
||||
|
|
@ -68,8 +68,8 @@ add::
|
|||
subcommand).
|
||||
|
||||
copy::
|
||||
Copy the notes for the first object onto the second object.
|
||||
Abort if the second object already has notes, or if the first
|
||||
Copy the notes for the first object onto the second object (defaults to
|
||||
HEAD). Abort if the second object already has notes, or if the first
|
||||
object has none (use -f to overwrite existing notes to the
|
||||
second object). This subcommand is equivalent to:
|
||||
`git notes add [-f] -C $(git notes list <from-object>) <to-object>`
|
||||
|
|
|
|||
|
|
@ -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
|
||||
needed.
|
||||
|
||||
--[no-]notes[=<ref>]::
|
||||
This flag is passed to the `git log` program
|
||||
(see linkgit:git-log[1]) that generates the patches.
|
||||
|
||||
<range1> <range2>::
|
||||
Compare the commits specified by the two ranges, where
|
||||
`<range1>` is considered an older version of `<range2>`.
|
||||
|
|
@ -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
|
||||
`--no-color` options. These options are used when generating the "diff
|
||||
between patches", i.e. to compare the author, commit message and diff of
|
||||
corresponding old/new commits. There is currently no means to tweak 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.
|
||||
|
||||
OUTPUT STABILITY
|
||||
|
|
@ -242,7 +246,7 @@ corresponding.
|
|||
|
||||
The overall time needed to compute this algorithm is the time needed to
|
||||
compute n+m commit diffs and then n*m diffs of patches, plus the time
|
||||
needed to compute the least-cost 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
|
||||
assignment problem, which has cubic runtime complexity. The matching
|
||||
found in this case will look like this:
|
||||
|
|
|
|||
|
|
@ -436,7 +436,7 @@ support.
|
|||
SEE ALSO
|
||||
--------
|
||||
linkgit:git-write-tree[1]; linkgit:git-ls-files[1];
|
||||
linkgit:gitignore[5]
|
||||
linkgit:gitignore[5]; linkgit:git-sparse-checkout[1];
|
||||
|
||||
GIT
|
||||
---
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
--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>::
|
||||
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 also INCOMPATIBLE OPTIONS below.
|
||||
|
||||
--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::
|
||||
These flags are passed to 'git am' to easily change the dates
|
||||
of the rebased commits (see linkgit:git-am[1]).
|
||||
--reset-author-date::
|
||||
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.
|
||||
|
||||
|
|
@ -443,8 +458,8 @@ the `rebase-cousins` mode is turned on, such commits are instead rebased
|
|||
onto `<upstream>` (or `<onto>`, if specified).
|
||||
+
|
||||
The `--rebase-merges` mode is similar in spirit to the deprecated
|
||||
`--preserve-merges`, but in contrast to that option works well in interactive
|
||||
rebases: commits can be reordered, inserted and dropped at will.
|
||||
`--preserve-merges` but works with interactive rebases,
|
||||
where commits can be reordered, inserted and dropped at will.
|
||||
+
|
||||
It is currently only possible to recreate the merge commits using the
|
||||
`recursive` merge strategy; Different merge strategies can be used only via
|
||||
|
|
@ -539,10 +554,7 @@ INCOMPATIBLE OPTIONS
|
|||
|
||||
The following options:
|
||||
|
||||
* --committer-date-is-author-date
|
||||
* --ignore-date
|
||||
* --whitespace
|
||||
* --ignore-whitespace
|
||||
* -C
|
||||
|
||||
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 --signoff
|
||||
* --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 --root
|
||||
|
||||
|
|
|
|||
|
|
@ -8,34 +8,36 @@ git-reset - Reset current HEAD to the specified state
|
|||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'git reset' [-q] [<tree-ish>] [--] <paths>...
|
||||
'git reset' (--patch | -p) [<tree-ish>] [--] [<paths>...]
|
||||
'git reset' [-q] [<tree-ish>] [--] <pathspec>...
|
||||
'git reset' [-q] [--pathspec-from-file=<file> [--pathspec-file-nul]] [<tree-ish>]
|
||||
'git reset' (--patch | -p) [<tree-ish>] [--] [<pathspec>...]
|
||||
'git reset' [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] [<commit>]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
In the first and second form, copy entries from `<tree-ish>` to the index.
|
||||
In the third form, set the current branch head (`HEAD`) to `<commit>`,
|
||||
In the first three forms, copy entries from `<tree-ish>` to the index.
|
||||
In the last form, set the current branch head (`HEAD`) to `<commit>`,
|
||||
optionally modifying index and working tree to match.
|
||||
The `<tree-ish>`/`<commit>` defaults to `HEAD` in all forms.
|
||||
|
||||
'git reset' [-q] [<tree-ish>] [--] <paths>...::
|
||||
This form resets the index entries for all `<paths>` to their
|
||||
state at `<tree-ish>`. (It does not affect the working tree or
|
||||
the current branch.)
|
||||
'git reset' [-q] [<tree-ish>] [--] <pathspec>...::
|
||||
'git reset' [-q] [--pathspec-from-file=<file> [--pathspec-file-nul]] [<tree-ish>]::
|
||||
These forms reset the index entries for all paths that match the
|
||||
`<pathspec>` to their state at `<tree-ish>`. (It does not affect
|
||||
the working tree or the current branch.)
|
||||
+
|
||||
This means that `git reset <paths>` is the opposite of `git add
|
||||
<paths>`. This command is equivalent to
|
||||
`git restore [--source=<tree-ish>] --staged <paths>...`.
|
||||
This means that `git reset <pathspec>` is the opposite of `git add
|
||||
<pathspec>`. This command is equivalent to
|
||||
`git restore [--source=<tree-ish>] --staged <pathspec>...`.
|
||||
+
|
||||
After running `git reset <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
|
||||
the working tree. Alternatively, using linkgit:git-restore[1]
|
||||
and specifying a commit with `--source`, you
|
||||
can copy the contents of a path out of a commit to the index and to the
|
||||
working tree in one go.
|
||||
|
||||
'git reset' (--patch | -p) [<tree-ish>] [--] [<paths>...]::
|
||||
'git reset' (--patch | -p) [<tree-ish>] [--] [<pathspec>...]::
|
||||
Interactively select hunks in the difference between the index
|
||||
and `<tree-ish>` (defaults to `HEAD`). The chosen hunks are applied
|
||||
in reverse to the index.
|
||||
|
|
@ -101,6 +103,26 @@ OPTIONS
|
|||
`reset.quiet` config option. `--quiet` and `--no-quiet` will
|
||||
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
|
||||
--------
|
||||
|
|
|
|||
|
|
@ -8,8 +8,9 @@ git-restore - Restore working tree files
|
|||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'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>...
|
||||
'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
|
||||
-----------
|
||||
|
|
@ -113,6 +114,27 @@ in linkgit:git-checkout[1] for details.
|
|||
appear in the `--source` tree are removed, to make them match
|
||||
`<tree>` exactly. The default is no-overlay mode.
|
||||
|
||||
--pathspec-from-file=<file>::
|
||||
Pathspec is passed in `<file>` instead of commandline args. If
|
||||
`<file>` is exactly `-` then standard input is used. Pathspec
|
||||
elements are separated by LF or CR/LF. Pathspec elements can be
|
||||
quoted as explained for the configuration variable `core.quotePath`
|
||||
(see linkgit:git-config[1]). See also `--pathspec-file-nul` and
|
||||
global `--literal-pathspecs`.
|
||||
|
||||
--pathspec-file-nul::
|
||||
Only meaningful with `--pathspec-from-file`. Pathspec elements are
|
||||
separated with NUL character and all other characters are taken
|
||||
literally (including newlines and quotes).
|
||||
|
||||
\--::
|
||||
Do not interpret any more arguments as options.
|
||||
|
||||
<pathspec>...::
|
||||
Limits the paths affected by the operation.
|
||||
+
|
||||
For more details, see the 'pathspec' entry in linkgit:gitglossary[7].
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
|
|
|
|||
|
|
@ -262,7 +262,8 @@ print a message to stderr and exit with nonzero status.
|
|||
directory.
|
||||
|
||||
--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 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
|
||||
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
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
|
|
|
|||
|
|
@ -76,6 +76,9 @@ them.
|
|||
Paths may need to be prefixed with `--` to separate them from
|
||||
options or the revision range, when confusion arises.
|
||||
|
||||
:git-shortlog: 1
|
||||
include::rev-list-options.txt[]
|
||||
|
||||
MAPPING AUTHORS
|
||||
---------------
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -16,6 +16,7 @@ SYNOPSIS
|
|||
'git submodule' [--quiet] deinit [-f|--force] (--all|[--] <path>...)
|
||||
'git submodule' [--quiet] update [<options>] [--] [<path>...]
|
||||
'git submodule' [--quiet] set-branch [<options>] [--] <path>
|
||||
'git submodule' [--quiet] set-url [--] <path> <newurl>
|
||||
'git submodule' [--quiet] summary [<options>] [--] [<path>...]
|
||||
'git submodule' [--quiet] foreach [--recursive] <command>
|
||||
'git submodule' [--quiet] sync [--recursive] [--] [<path>...]
|
||||
|
|
@ -80,6 +81,9 @@ status [--cached] [--recursive] [--] [<path>...]::
|
|||
does not match the SHA-1 found in the index of the containing
|
||||
repository and `U` if the submodule has merge conflicts.
|
||||
+
|
||||
If `--cached` is specified, this command will instead print the SHA-1
|
||||
recorded in the superproject for each submodule.
|
||||
+
|
||||
If `--recursive` is specified, this command will recurse into nested
|
||||
submodules, and show their status as well.
|
||||
+
|
||||
|
|
@ -133,7 +137,8 @@ update [--init] [--remote] [-N|--no-fetch] [--[no-]recommend-shallow] [-f|--forc
|
|||
+
|
||||
--
|
||||
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
|
||||
on command line options and the value of `submodule.<name>.update`
|
||||
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
|
||||
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>...]::
|
||||
Show commit summary between the given commit (defaults to HEAD) and
|
||||
working tree/index. For a submodule in question, a series of commits
|
||||
|
|
|
|||
|
|
@ -677,7 +677,8 @@ config key: svn.authorsProg
|
|||
-s<strategy>::
|
||||
--strategy=<strategy>::
|
||||
-p::
|
||||
--preserve-merges::
|
||||
--rebase-merges::
|
||||
--preserve-merges (DEPRECATED)::
|
||||
These are only used with the 'dcommit' and 'rebase' commands.
|
||||
+
|
||||
Passed directly to 'git rebase' when using 'dcommit' if a
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ OPTIONS
|
|||
--sign::
|
||||
Make a GPG-signed tag, using the default e-mail address's key.
|
||||
The default behavior of tag GPG-signing is controlled by `tag.gpgSign`
|
||||
configuration variable if it exists, or disabled oder otherwise.
|
||||
configuration variable if it exists, or disabled otherwise.
|
||||
See linkgit:git-config[1].
|
||||
|
||||
--no-sign::
|
||||
|
|
|
|||
|
|
@ -16,6 +16,7 @@ SYNOPSIS
|
|||
[--chmod=(+|-)x]
|
||||
[--[no-]assume-unchanged]
|
||||
[--[no-]skip-worktree]
|
||||
[--[no-]ignore-skip-worktree-entries]
|
||||
[--[no-]fsmonitor-valid]
|
||||
[--ignore-submodules]
|
||||
[--[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
|
||||
section "Skip-worktree bit" below for more information.
|
||||
|
||||
|
||||
--[no-]ignore-skip-worktree-entries::
|
||||
Do not remove skip-worktree (AKA "index-only") entries even when
|
||||
the `--remove` option was specified.
|
||||
|
||||
--[no-]fsmonitor-valid::
|
||||
When one of these flags is specified, the object name recorded
|
||||
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]).
|
||||
|
||||
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.
|
||||
|
||||
UNTRACKED CACHE
|
||||
|
|
|
|||
|
|
@ -271,8 +271,8 @@ In general, the interrogate commands do not touch the files in
|
|||
the working tree.
|
||||
|
||||
|
||||
Synching repositories
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
Syncing repositories
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
include::cmds-synchingrepositories.txt[]
|
||||
|
||||
|
|
@ -544,6 +544,10 @@ other
|
|||
a pager. See also the `core.pager` option in
|
||||
linkgit:git-config[1].
|
||||
|
||||
`GIT_PROGRESS_DELAY`::
|
||||
A number controlling how many seconds to delay before showing
|
||||
optional progress indicators. Defaults to 2.
|
||||
|
||||
`GIT_EDITOR`::
|
||||
This environment variable overrides `$EDITOR` and `$VISUAL`.
|
||||
It is used by several Git commands when, on interactive mode,
|
||||
|
|
@ -928,7 +932,7 @@ Reporting Bugs
|
|||
Report bugs to the Git mailing list <git@vger.kernel.org> where the
|
||||
development and maintenance is primarily done. You do not have to be
|
||||
subscribed to the list to send a message there. See the list archive
|
||||
at https://public-inbox.org/git for previous bug reports and other
|
||||
at https://lore.kernel.org/git for previous bug reports and other
|
||||
discussions.
|
||||
|
||||
Issues which are security relevant should be disclosed privately to
|
||||
|
|
|
|||
|
|
@ -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
|
||||
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
|
||||
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
|
||||
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,
|
||||
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
|
||||
suppported, and the supported capabilities are "clean", "smudge", and
|
||||
supported, and the supported capabilities are "clean", "smudge", and
|
||||
"delay".
|
||||
|
||||
Afterwards Git sends a list of "key=value" pairs terminated with
|
||||
|
|
@ -812,6 +812,8 @@ patterns are available:
|
|||
|
||||
- `dts` suitable for devicetree (DTS) files.
|
||||
|
||||
- `elixir` suitable for source code in the Elixir language.
|
||||
|
||||
- `fortran` suitable for source code in the Fortran language.
|
||||
|
||||
- `fountain` suitable for Fountain documents.
|
||||
|
|
|
|||
|
|
@ -211,8 +211,8 @@ only affects the files in the working tree, but with
|
|||
entries, and with `--cached`, it modifies only the index
|
||||
entries.
|
||||
|
||||
See also http://marc.info/?l=git&m=116563135620359 and
|
||||
http://marc.info/?l=git&m=119150393620273 for further
|
||||
See also https://lore.kernel.org/git/7v64clg5u9.fsf@assigned-by-dhcp.cox.net/ and
|
||||
https://lore.kernel.org/git/7vy7ej9g38.fsf@gitster.siamese.dyndns.org/ for further
|
||||
information.
|
||||
|
||||
Some other commands that also work on files in the working tree and/or
|
||||
|
|
|
|||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче