maurice/snix
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

merge(3p/git): Merge git subtree at v2.29.2

Browse source 
This also bumps the stable nixpkgs to 20.09 as of 2020-11-21, because
there is some breakage in the git build related to the netrc
credentials helper which someone has taken care of in nixpkgs.

The stable channel is not used for anything other than git, so this
should be fine.

Change-Id: I3575a19dab09e1e9556cf8231d717de9890484fb
This commit is contained in:
Vincent Ambo 2020-11-21 19:20:35 +01:00
parent 082c006c04
commit f4609b896f
1485 changed files with 241535 additions and 109418 deletions
Download patch file Download diff file Expand all files Collapse all files

54
third_party/git/Documentation/git-fast-export.txt vendored
View file

@ -17,9 +17,9 @@ This program dumps the given revisions in a form suitable to be piped
into 'git fast-import'.
You can use it as a human-readable bundle replacement (see
linkgit:git-bundle[1]), or as a kind of an interactive
'git filter-branch'.
linkgit:git-bundle[1]), or as a format that can be edited before being
fed to 'git fast-import' in order to do history rewrites (an ability
relied on by tools like 'git filter-repo').
OPTIONS
-------
@ -75,11 +75,20 @@ produced incorrect results if you gave these options.
Before processing any input, load the marks specified in
<file>. The input file must exist, must be readable, and
must use the same format as produced by --export-marks.
--mark-tags::
In addition to labelling blobs and commits with mark ids, also
label tags. This is useful in conjunction with
`--export-marks` and `--import-marks`, and is also useful (and
necessary) for exporting of nested tags. It does not hurt
other cases and would be the default, but many fast-import
frontends are not prepared to accept tags with mark
identifiers.
+
Any commits that have already been marked will not be exported again.
If the backend uses a similar --import-marks file, this allows for
incremental bidirectional exporting of the repository by keeping the
marks the same across runs.
Any commits (or tags) that have already been marked will not be
exported again. If the backend uses a similar --import-marks file,
this allows for incremental bidirectional exporting of the repository
by keeping the marks the same across runs.
--fake-missing-tagger::
Some old repositories have tags without a tagger. The
@ -110,6 +119,11 @@ marks the same across runs.
the shape of the history and stored tree. See the section on
`ANONYMIZING` below.
--anonymize-map=<from>[:<to>]::
Convert token `<from>` to `<to>` in the anonymized output. If
`<to>` is omitted, map `<from>` to itself (i.e., do not
anonymize it). See the section on `ANONYMIZING` below.
--reference-excluded-parents::
By default, running a command such as `git fast-export
master~5..master` will not include the commit master{tilde}5
@ -133,7 +147,7 @@ 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::
@ -229,6 +243,30 @@ collapse "User 0", "User 1", etc into "User X"). This produces a much
smaller output, and it is usually easy to quickly confirm that there is
no private data in the stream.
Reproducing some bugs may require referencing particular commits or
paths, which becomes challenging after refnames and paths have been
anonymized. You can ask for a particular token to be left as-is or
mapped to a new value. For example, if you have a bug which reproduces
with `git rev-list sensitive -- secret.c`, you can run:
---------------------------------------------------
$ git fast-export --anonymize --all \
--anonymize-map=sensitive:foo \
--anonymize-map=secret.c:bar.c \
>stream
---------------------------------------------------
After importing the stream, you can then run `git rev-list foo -- bar.c`
in the anonymized repository.
Note that paths and refnames are split into tokens at slash boundaries.
The command above would anonymize `subdir/secret.c` as something like
`path123/bar.c`; you could then search for `bar.c` in the anonymized
repository to determine the final pathname.
To make referencing the final pathname simpler, you can map each path
component; so if you also anonymize `subdir` to `publicdir`, then the
final pathname would be `publicdir/bar.c`.
LIMITATIONS
-----------