Compare commits

..

27 Commits

Author SHA1 Message Date
656d9a24f6 Git 2.32.3
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-06-23 12:35:32 +02:00
fc0c773028 Sync with 2.31.4
* maint-2.31:
  Git 2.31.4
  Git 2.30.5
  setup: tighten ownership checks post CVE-2022-24765
  git-compat-util: allow root to access both SUDO_UID and root owned
  t0034: add negative tests and allow git init to mostly work under sudo
  git-compat-util: avoid failing dir ownership checks if running privileged
  t: regression git needs safe.directory when using sudo
2022-06-23 12:35:30 +02:00
5b1c746c35 Git 2.31.4
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-06-23 12:35:25 +02:00
2f8809f9a1 Sync with 2.30.5
* maint-2.30:
  Git 2.30.5
  setup: tighten ownership checks post CVE-2022-24765
  git-compat-util: allow root to access both SUDO_UID and root owned
  t0034: add negative tests and allow git init to mostly work under sudo
  git-compat-util: avoid failing dir ownership checks if running privileged
  t: regression git needs safe.directory when using sudo
2022-06-23 12:35:23 +02:00
88b7be68a4 Git 2.30.5
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-06-23 12:31:05 +02:00
3b0bf27049 setup: tighten ownership checks post CVE-2022-24765
8959555cee (setup_git_directory(): add an owner check for the top-level
directory, 2022-03-02), adds a function to check for ownership of
repositories using a directory that is representative of it, and ways to
add exempt a specific repository from said check if needed, but that
check didn't account for owership of the gitdir, or (when used) the
gitfile that points to that gitdir.

An attacker could create a git repository in a directory that they can
write into but that is owned by the victim to work around the fix that
was introduced with CVE-2022-24765 to potentially run code as the
victim.

An example that could result in privilege escalation to root in *NIX would
be to set a repository in a shared tmp directory by doing (for example):

  $ git -C /tmp init

To avoid that, extend the ensure_valid_ownership function to be able to
check for all three paths.

This will have the side effect of tripling the number of stat() calls
when a repository is detected, but the effect is expected to be likely
minimal, as it is done only once during the directory walk in which Git
looks for a repository.

Additionally make sure to resolve the gitfile (if one was used) to find
the relevant gitdir for checking.

While at it change the message printed on failure so it is clear we are
referring to the repository by its worktree (or gitdir if it is bare) and
not to a specific directory.

Helped-by: Junio C Hamano <junio@pobox.com>
Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
2022-06-23 12:31:05 +02:00
b779214eaf Merge branch 'cb/path-owner-check-with-sudo'
With a recent update to refuse access to repositories of other
people by default, "sudo make install" and "sudo git describe"
stopped working.  This series intends to loosen it while keeping
the safety.

* cb/path-owner-check-with-sudo:
  t0034: add negative tests and allow git init to mostly work under sudo
  git-compat-util: avoid failing dir ownership checks if running privileged
  t: regression git needs safe.directory when using sudo

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-06-23 12:31:04 +02:00
6b11e3d52e git-compat-util: allow root to access both SUDO_UID and root owned
Previous changes introduced a regression which will prevent root for
accessing repositories owned by thyself if using sudo because SUDO_UID
takes precedence.

Loosen that restriction by allowing root to access repositories owned
by both uid by default and without having to add a safe.directory
exception.

A previous workaround that was documented in the tests is no longer
needed so it has been removed together with its specially crafted
prerequisite.

Helped-by: Johanness Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-06-17 14:03:08 -07:00
b9063afda1 t0034: add negative tests and allow git init to mostly work under sudo
Add a support library that provides one function that can be used
to run a "scriplet" of commands through sudo and that helps invoking
sudo in the slightly awkward way that is required to ensure it doesn't
block the call (if shell was allowed as tested in the prerequisite)
and it doesn't run the command through a different shell than the one
we intended.

Add additional negative tests as suggested by Junio and that use a
new workspace that is owned by root.

Document a regression that was introduced by previous commits where
root won't be able anymore to access directories they own unless
SUDO_UID is removed from their environment.

The tests document additional ways that this new restriction could
be worked around and the documentation explains why it might be instead
considered a feature, but a "fix" is planned for a future change.

Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Phillip Wood <phillip.wood123@gmail.com>
Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-12 18:12:23 -07:00
ae9abbb63e git-compat-util: avoid failing dir ownership checks if running privileged
bdc77d1d68 (Add a function to determine whether a path is owned by the
current user, 2022-03-02) checks for the effective uid of the running
process using geteuid() but didn't account for cases where that user was
root (because git was invoked through sudo or a compatible tool) and the
original uid that repository trusted for its config was no longer known,
therefore failing the following otherwise safe call:

  guy@renard ~/Software/uncrustify $ sudo git describe --always --dirty
  [sudo] password for guy:
  fatal: unsafe repository ('/home/guy/Software/uncrustify' is owned by someone else)

Attempt to detect those cases by using the environment variables that
those tools create to keep track of the original user id, and do the
ownership check using that instead.

This assumes the environment the user is running on after going
privileged can't be tampered with, and also adds code to restrict that
the new behavior only applies if running as root, therefore keeping the
most common case, which runs unprivileged, from changing, but because of
that, it will miss cases where sudo (or an equivalent) was used to change
to another unprivileged user or where the equivalent tool used to raise
privileges didn't track the original id in a sudo compatible way.

Because of compatibility with sudo, the code assumes that uid_t is an
unsigned integer type (which is not required by the standard) but is used
that way in their codebase to generate SUDO_UID.  In systems where uid_t
is signed, sudo might be also patched to NOT be unsigned and that might
be able to trigger an edge case and a bug (as described in the code), but
it is considered unlikely to happen and even if it does, the code would
just mostly fail safely, so there was no attempt either to detect it or
prevent it by the code, which is something that might change in the future,
based on expected user feedback.

Reported-by: Guy Maurel <guy.j@maurel.de>
Helped-by: SZEDER Gábor <szeder.dev@gmail.com>
Helped-by: Randall Becker <rsbecker@nexbridge.com>
Helped-by: Phillip Wood <phillip.wood123@gmail.com>
Suggested-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-12 18:12:23 -07:00
5f1a3fec8c t: regression git needs safe.directory when using sudo
Originally reported after release of v2.35.2 (and other maint branches)
for CVE-2022-24765 and blocking otherwise harmless commands that were
done using sudo in a repository that was owned by the user.

Add a new test script with very basic support to allow running git
commands through sudo, so a reproduction could be implemented and that
uses only `git status` as a proxy of the issue reported.

Note that because of the way sudo interacts with the system, a much
more complete integration with the test framework will require a lot
more work and that was therefore intentionally punted for now.

The current implementation requires the execution of a special cleanup
function which should always be kept as the last "test" or otherwise
the standard cleanup functions will fail because they can't remove
the root owned directories that are used.  This also means that if
failures are found while running, the specifics of the failure might
not be kept for further debugging and if the test was interrupted, it
will be necessary to clean the working directory manually before
restarting by running:

  $ sudo rm -rf trash\ directory.t0034-root-safe-directory/

The test file also uses at least one initial "setup" test that creates
a parallel execution directory under the "root" sub directory, which
should be used as top level directory for all repositories that are
used in this test file.  Unlike all other tests the repository provided
by the test framework should go unused.

Special care should be taken when invoking commands through sudo, since
the environment is otherwise independent from what the test framework
setup and might have changed the values for HOME, SHELL and dropped
several relevant environment variables for your test.  Indeed `git status`
was used as a proxy because it doesn't even require commits in the
repository to work and usually doesn't require much from the environment
to run, but a future patch will add calls to `git init` and that will
fail to honor the default branch name, unless that setting is NOT
provided through an environment variable (which means even a CI run
could fail that test if enabled incorrectly).

A new SUDO prerequisite is provided that does some sanity checking
to make sure the sudo command that will be used allows for passwordless
execution as root without restrictions and doesn't mess with git's
execution path.  This matches what is provided by the macOS agents that
are used as part of GitHub actions and probably nowhere else.

Most of those characteristics make this test mostly only suitable for
CI, but it might be executed locally if special care is taken to provide
for all of them in the local configuration and maybe making use of the
sudo credential cache by first invoking sudo, entering your password if
needed, and then invoking the test with:

  $ GIT_TEST_ALLOW_SUDO=YES ./t0034-root-safe-directory.sh

If it fails to run, then it means your local setup wouldn't work for the
test because of the configuration sudo has or other system settings, and
things that might help are to comment out sudo's secure_path config, and
make sure that the account you are using has no restrictions on the
commands it can run through sudo, just like is provided for the user in
the CI.

For example (assuming a username of marta for you) something probably
similar to the following entry in your /etc/sudoers (or equivalent) file:

  marta	ALL=(ALL:ALL) NOPASSWD: ALL

Reported-by: SZEDER Gábor <szeder.dev@gmail.com>
Helped-by: Phillip Wood <phillip.wood123@gmail.com>
Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-12 18:12:23 -07:00
1530434434 Git 2.32.2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-13 15:21:26 -07:00
09f66d65f8 Git 2.31.3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-13 15:21:08 -07:00
17083c79ae Git 2.30.4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-13 13:31:29 -07:00
0f85c4a30b setup: opt-out of check with safe.directory=*
With the addition of the safe.directory in 8959555ce
(setup_git_directory(): add an owner check for the top-level directory,
2022-03-02) released in v2.35.2, we are receiving feedback from a
variety of users about the feature.

Some users have a very large list of shared repositories and find it
cumbersome to add this config for every one of them.

In a more difficult case, certain workflows involve running Git commands
within containers. The container boundary prevents any global or system
config from communicating `safe.directory` values from the host into the
container. Further, the container almost always runs as a different user
than the owner of the directory in the host.

To simplify the reactions necessary for these users, extend the
definition of the safe.directory config value to include a possible '*'
value. This value implies that all directories are safe, providing a
single setting to opt-out of this protection.

Note that an empty assignment of safe.directory clears all previous
values, and this is already the case with the "if (!value || !*value)"
condition.

Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-13 12:42:51 -07:00
bb50ec3cc3 setup: fix safe.directory key not being checked
It seems that nothing is ever checking to make sure the safe directories
in the configs actually have the key safe.directory, so some unrelated
config that has a value with a certain directory would also make it a
safe directory.

Signed-off-by: Matheus Valadares <me@m28.io>
Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-13 12:42:51 -07:00
e47363e5a8 t0033: add tests for safe.directory
It is difficult to change the ownership on a directory in our test
suite, so insert a new GIT_TEST_ASSUME_DIFFERENT_OWNER environment
variable to trick Git into thinking we are in a differently-owned
directory. This allows us to test that the config is parsed correctly.

Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-13 12:42:49 -07:00
9bcd7a8eca Git 2.32.1
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-03-24 00:31:29 +01:00
201b0c7af6 Sync with 2.31.2
* maint-2.31:
  Git 2.31.2
  Git 2.30.3
  setup_git_directory(): add an owner check for the top-level directory
  Add a function to determine whether a path is owned by the current user
2022-03-24 00:31:28 +01:00
44de39c45c Git 2.31.2
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-03-24 00:24:29 +01:00
6a2381a3e5 Sync with 2.30.3
* maint-2.30:
  Git 2.30.3
  setup_git_directory(): add an owner check for the top-level directory
  Add a function to determine whether a path is owned by the current user
2022-03-24 00:24:29 +01:00
cb95038137 Git 2.30.3
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-03-24 00:22:17 +01:00
fdcad5a53e Fix GIT_CEILING_DIRECTORIES with C:\ and the likes
When determining the length of the longest ancestor of a given path with
respect to to e.g. `GIT_CEILING_DIRECTORIES`, we special-case the root
directory by returning 0 (i.e. we pretend that the path `/` does not end
in a slash by virtually stripping it).

That is the correct behavior because when normalizing paths, the root
directory is special: all other directory paths have their trailing
slash stripped, but not the root directory's path (because it would
become the empty string, which is not a legal path).

However, this special-casing of the root directory in
`longest_ancestor_length()` completely forgets about Windows-style root
directories, e.g. `C:\`. These _also_ get normalized with a trailing
slash (because `C:` would actually refer to the current directory on
that drive, not necessarily to its root directory).

In fc56c7b34b (mingw: accomodate t0060-path-utils for MSYS2,
2016-01-27), we almost got it right. We noticed that
`longest_ancestor_length()` expects a slash _after_ the matched prefix,
and if the prefix already ends in a slash, the normalized path won't
ever match and -1 is returned.

But then that commit went astray: The correct fix is not to adjust the
_tests_ to expect an incorrect -1 when that function is fed a prefix
that ends in a slash, but instead to treat such a prefix as if the
trailing slash had been removed.

Likewise, that function needs to handle the case where it is fed a path
that ends in a slash (not only a prefix that ends in a slash): if it
matches the prefix (plus trailing slash), we still need to verify that
the path does not end there, otherwise the prefix is not actually an
ancestor of the path but identical to it (and we need to return -1 in
that case).

With these two adjustments, we no longer need to play games in t0060
where we only add `$rootoff` if the passed prefix is different from the
MSYS2 pseudo root, instead we also add it for the MSYS2 pseudo root
itself. We do have to be careful to skip that logic entirely for Windows
paths, though, because they do are not subject to that MSYS2 pseudo root
treatment.

This patch fixes the scenario where a user has set
`GIT_CEILING_DIRECTORIES=C:\`, which would be ignored otherwise.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-03-24 00:21:08 +01:00
8959555cee setup_git_directory(): add an owner check for the top-level directory
It poses a security risk to search for a git directory outside of the
directories owned by the current user.

For example, it is common e.g. in computer pools of educational
institutes to have a "scratch" space: a mounted disk with plenty of
space that is regularly swiped where any authenticated user can create
a directory to do their work. Merely navigating to such a space with a
Git-enabled `PS1` when there is a maliciously-crafted `/scratch/.git/`
can lead to a compromised account.

The same holds true in multi-user setups running Windows, as `C:\` is
writable to every authenticated user by default.

To plug this vulnerability, we stop Git from accepting top-level
directories owned by someone other than the current user. We avoid
looking at the ownership of each and every directories between the
current and the top-level one (if there are any between) to avoid
introducing a performance bottleneck.

This new default behavior is obviously incompatible with the concept of
shared repositories, where we expect the top-level directory to be owned
by only one of its legitimate users. To re-enable that use case, we add
support for adding exceptions from the new default behavior via the
config setting `safe.directory`.

The `safe.directory` config setting is only respected in the system and
global configs, not from repository configs or via the command-line, and
can have multiple values to allow for multiple shared repositories.

We are particularly careful to provide a helpful message to any user
trying to use a shared repository.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-03-21 13:16:26 +01:00
bdc77d1d68 Add a function to determine whether a path is owned by the current user
This function will be used in the next commit to prevent
`setup_git_directory()` from discovering a repository in a directory
that is owned by someone other than the current user.

Note: We cannot simply use `st.st_uid` on Windows just like we do on
Linux and other Unix-like platforms: according to
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/stat-functions
this field is always zero on Windows (because Windows' idea of a user ID
does not fit into a single numerical value). Therefore, we have to do
something a little involved to replicate the same functionality there.

Also note: On Windows, a user's home directory is not actually owned by
said user, but by the administrator. For all practical purposes, it is
under the user's control, though, therefore we pretend that it is owned
by the user.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-03-21 13:16:26 +01:00
2a9a5862e5 Merge branch 'cb/mingw-gmtime-r'
Build fix on Windows.

* cb/mingw-gmtime-r:
  mingw: avoid fallback for {local,gm}time_r()

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-03-17 12:52:12 +01:00
6e7ad1e4c2 mingw: avoid fallback for {local,gm}time_r()
mingw-w64's pthread_unistd.h had a bug that mistakenly (because there is
no support for the *lockfile() functions required[1]) defined
_POSIX_THREAD_SAFE_FUNCTIONS and that was being worked around since
3ecd153a3b (compat/mingw: support MSys2-based MinGW build, 2016-01-14).

The bug was fixed in winphtreads, but as a side effect, leaves the
reentrant functions from time.h no longer visible and therefore breaks
the build.

Since the intention all along was to avoid using the fallback functions,
formalize the use of POSIX by setting the corresponding feature flag and
compile out the implementation for the fallback functions.

[1] https://unix.org/whitepapers/reentrant.html

Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-17 12:52:12 +01:00
887 changed files with 98475 additions and 111496 deletions

View File

@ -2,15 +2,8 @@ env:
CIRRUS_CLONE_DEPTH: 1
freebsd_12_task:
env:
GIT_PROVE_OPTS: "--timer --jobs 10"
GIT_TEST_OPTS: "--no-chain-lint --no-bin-wrappers"
MAKEFLAGS: "-j4"
DEFAULT_TEST_TARGET: prove
DEVELOPER: 1
freebsd_instance:
image_family: freebsd-12-2
memory: 2G
image: freebsd-12-1-release-amd64
install_script:
pkg install -y gettext gmake perl5
create_user_script:

View File

@ -12,9 +12,15 @@ jobs:
check-whitespace:
runs-on: ubuntu-latest
steps:
- name: Set commit count
shell: bash
run: echo "COMMIT_DEPTH=$((1+$COMMITS))" >>$GITHUB_ENV
env:
COMMITS: ${{ github.event.pull_request.commits }}
- uses: actions/checkout@v2
with:
fetch-depth: 0
fetch-depth: ${{ env.COMMIT_DEPTH }}
- name: git log --check
id: check_out
@ -41,9 +47,25 @@ jobs:
echo "${dash} ${etc}"
;;
esac
done <<< $(git log --check --pretty=format:"---% h% s" ${{github.event.pull_request.base.sha}}..)
done <<< $(git log --check --pretty=format:"---% h% s" -${{github.event.pull_request.commits}})
if test -n "${log}"
then
echo "::set-output name=checkout::"${log}""
exit 2
fi
- name: Add Check Output as Comment
uses: actions/github-script@v3
id: add-comment
env:
log: ${{ steps.check_out.outputs.checkout }}
with:
script: |
await github.issues.createComment({
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.repo,
body: `Whitespace errors found in workflow ${{ github.workflow }}:\n\n\`\`\`\n${process.env.log.replace(/\\n/g, "\n")}\n\`\`\``
})
if: ${{ failure() }}

View File

@ -1,105 +0,0 @@
name: git-l10n
on: [push, pull_request_target]
jobs:
git-po-helper:
if: >-
endsWith(github.repository, '/git-po') ||
contains(github.head_ref, 'l10n') ||
contains(github.ref, 'l10n')
runs-on: ubuntu-latest
permissions:
pull-requests: write
steps:
- name: Setup base and head objects
id: setup-tips
run: |
if test "${{ github.event_name }}" = "pull_request_target"
then
base=${{ github.event.pull_request.base.sha }}
head=${{ github.event.pull_request.head.sha }}
else
base=${{ github.event.before }}
head=${{ github.event.after }}
fi
echo "::set-output name=base::$base"
echo "::set-output name=head::$head"
- name: Run partial clone
run: |
git -c init.defaultBranch=master init --bare .
git remote add \
--mirror=fetch \
origin \
https://github.com/${{ github.repository }}
# Fetch tips that may be unreachable from github.ref:
# - For a forced push, "$base" may be unreachable.
# - For a "pull_request_target" event, "$head" may be unreachable.
args=
for commit in \
${{ steps.setup-tips.outputs.base }} \
${{ steps.setup-tips.outputs.head }}
do
case $commit in
*[^0]*)
args="$args $commit"
;;
*)
# Should not fetch ZERO-OID.
;;
esac
done
git -c protocol.version=2 fetch \
--progress \
--no-tags \
--no-write-fetch-head \
--filter=blob:none \
origin \
${{ github.ref }} \
$args
- uses: actions/setup-go@v2
with:
go-version: '>=1.16'
- name: Install git-po-helper
run: go install github.com/git-l10n/git-po-helper@main
- name: Install other dependencies
run: |
sudo apt-get update -q &&
sudo apt-get install -q -y gettext
- name: Run git-po-helper
id: check-commits
run: |
exit_code=0
git-po-helper check-commits \
--github-action-event="${{ github.event_name }}" -- \
${{ steps.setup-tips.outputs.base }}..${{ steps.setup-tips.outputs.head }} \
>git-po-helper.out 2>&1 || exit_code=$?
if test $exit_code -ne 0 || grep -q WARNING git-po-helper.out
then
# Remove ANSI colors which are proper for console logs but not
# proper for PR comment.
echo "COMMENT_BODY<<EOF" >>$GITHUB_ENV
perl -pe 's/\e\[[0-9;]*m//g; s/\bEOF$//g' git-po-helper.out >>$GITHUB_ENV
echo "EOF" >>$GITHUB_ENV
fi
cat git-po-helper.out
exit $exit_code
- name: Create comment in pull request for report
uses: mshick/add-pr-comment@v1
if: >-
always() &&
github.event_name == 'pull_request_target' &&
env.COMMENT_BODY != ''
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
repo-token-user-login: 'github-actions[bot]'
message: >
${{ steps.check-commits.outcome == 'failure' && 'Errors and warnings' || 'Warnings' }}
found by [git-po-helper](https://github.com/git-l10n/git-po-helper#readme) in workflow
[#${{ github.run_number }}](${{ env.GITHUB_SERVER_URL }}/${{ github.repository }}/actions/runs/${{ github.run_id }}):
```
${{ env.COMMENT_BODY }}
```

View File

@ -81,21 +81,44 @@ jobs:
if: needs.ci-config.outputs.enabled == 'yes'
runs-on: windows-latest
steps:
- uses: actions/checkout@v2
- uses: git-for-windows/setup-git-for-windows-sdk@v1
- name: build
- uses: actions/checkout@v1
- name: download git-sdk-64-minimal
shell: bash
run: |
## Get artifact
urlbase=https://dev.azure.com/git-for-windows/git/_apis/build/builds
id=$(curl "$urlbase?definitions=22&statusFilter=completed&resultFilter=succeeded&\$top=1" |
jq -r ".value[] | .id")
download_url="$(curl "$urlbase/$id/artifacts" |
jq -r '.value[] | select(.name == "git-sdk-64-minimal").resource.downloadUrl')"
curl --connect-timeout 10 --retry 5 --retry-delay 0 --retry-max-time 240 \
-o artifacts.zip "$download_url"
## Unzip and remove the artifact
unzip artifacts.zip
rm artifacts.zip
- name: build
shell: powershell
env:
HOME: ${{runner.workspace}}
MSYSTEM: MINGW64
NO_PERL: 1
run: . /etc/profile && ci/make-test-artifacts.sh artifacts
- name: zip up tracked files
run: git archive -o artifacts/tracked.tar.gz HEAD
- name: upload tracked files and build artifacts
uses: actions/upload-artifact@v2
run: |
& .\git-sdk-64-minimal\usr\bin\bash.exe -lc @"
printf '%s\n' /git-sdk-64-minimal/ >>.git/info/exclude
ci/make-test-artifacts.sh artifacts
"@
- name: upload build artifacts
uses: actions/upload-artifact@v1
with:
name: windows-artifacts
path: artifacts
- name: upload git-sdk-64-minimal
uses: actions/upload-artifact@v1
with:
name: git-sdk-64-minimal
path: git-sdk-64-minimal
windows-test:
runs-on: windows-latest
needs: [windows-build]
@ -104,25 +127,37 @@ jobs:
matrix:
nr: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
steps:
- name: download tracked files and build artifacts
uses: actions/download-artifact@v2
- uses: actions/checkout@v1
- name: download build artifacts
uses: actions/download-artifact@v1
with:
name: windows-artifacts
path: ${{github.workspace}}
- name: extract tracked files and build artifacts
- name: extract build artifacts
shell: bash
run: tar xf artifacts.tar.gz && tar xf tracked.tar.gz
- uses: git-for-windows/setup-git-for-windows-sdk@v1
run: tar xf artifacts.tar.gz
- name: download git-sdk-64-minimal
uses: actions/download-artifact@v1
with:
name: git-sdk-64-minimal
path: ${{github.workspace}}/git-sdk-64-minimal/
- name: test
shell: bash
run: . /etc/profile && ci/run-test-slice.sh ${{matrix.nr}} 10
shell: powershell
run: |
& .\git-sdk-64-minimal\usr\bin\bash.exe -lc @"
# Let Git ignore the SDK
printf '%s\n' /git-sdk-64-minimal/ >>.git/info/exclude
ci/run-test-slice.sh ${{matrix.nr}} 10
"@
- name: ci/print-test-failures.sh
if: failure()
shell: bash
run: ci/print-test-failures.sh
shell: powershell
run: |
& .\git-sdk-64-minimal\usr\bin\bash.exe -lc ci/print-test-failures.sh
- name: Upload failed tests' directories
if: failure() && env.FAILED_TEST_ARTIFACTS != ''
uses: actions/upload-artifact@v2
uses: actions/upload-artifact@v1
with:
name: failed-tests-windows
path: ${{env.FAILED_TEST_ARTIFACTS}}
@ -130,12 +165,27 @@ jobs:
needs: ci-config
if: needs.ci-config.outputs.enabled == 'yes'
env:
MSYSTEM: MINGW64
NO_PERL: 1
GIT_CONFIG_PARAMETERS: "'user.name=CI' 'user.email=ci@git'"
runs-on: windows-latest
steps:
- uses: actions/checkout@v2
- uses: git-for-windows/setup-git-for-windows-sdk@v1
- uses: actions/checkout@v1
- name: download git-sdk-64-minimal
shell: bash
run: |
## Get artifact
urlbase=https://dev.azure.com/git-for-windows/git/_apis/build/builds
id=$(curl "$urlbase?definitions=22&statusFilter=completed&resultFilter=succeeded&\$top=1" |
jq -r ".value[] | .id")
download_url="$(curl "$urlbase/$id/artifacts" |
jq -r '.value[] | select(.name == "git-sdk-64-minimal").resource.downloadUrl')"
curl --connect-timeout 10 --retry 5 --retry-delay 0 --retry-max-time 240 \
-o artifacts.zip "$download_url"
## Unzip and remove the artifact
unzip artifacts.zip
rm artifacts.zip
- name: initialize vcpkg
uses: actions/checkout@v2
with:
@ -153,59 +203,75 @@ jobs:
- name: add msbuild to PATH
uses: microsoft/setup-msbuild@v1
- name: copy dlls to root
shell: cmd
run: compat\vcbuild\vcpkg_copy_dlls.bat release
shell: powershell
run: |
& compat\vcbuild\vcpkg_copy_dlls.bat release
if (!$?) { exit(1) }
- name: generate Visual Studio solution
shell: bash
run: |
cmake `pwd`/contrib/buildsystems/ -DCMAKE_PREFIX_PATH=`pwd`/compat/vcbuild/vcpkg/installed/x64-windows \
-DNO_GETTEXT=YesPlease -DPERL_TESTS=OFF -DPYTHON_TESTS=OFF -DCURL_NO_CURL_CMAKE=ON
-DMSGFMT_EXE=`pwd`/git-sdk-64-minimal/mingw64/bin/msgfmt.exe -DPERL_TESTS=OFF -DPYTHON_TESTS=OFF -DCURL_NO_CURL_CMAKE=ON
- name: MSBuild
run: msbuild git.sln -property:Configuration=Release -property:Platform=x64 -maxCpuCount:4 -property:PlatformToolset=v142
- name: bundle artifact tar
shell: bash
shell: powershell
env:
MSVC: 1
VCPKG_ROOT: ${{github.workspace}}\compat\vcbuild\vcpkg
run: |
mkdir -p artifacts &&
eval "$(make -n artifacts-tar INCLUDE_DLLS_IN_ARTIFACTS=YesPlease ARTIFACTS_DIRECTORY=artifacts NO_GETTEXT=YesPlease 2>&1 | grep ^tar)"
- name: zip up tracked files
run: git archive -o artifacts/tracked.tar.gz HEAD
- name: upload tracked files and build artifacts
uses: actions/upload-artifact@v2
& git-sdk-64-minimal\usr\bin\bash.exe -lc @"
mkdir -p artifacts &&
eval \"`$(make -n artifacts-tar INCLUDE_DLLS_IN_ARTIFACTS=YesPlease ARTIFACTS_DIRECTORY=artifacts 2>&1 | grep ^tar)\"
"@
- name: upload build artifacts
uses: actions/upload-artifact@v1
with:
name: vs-artifacts
path: artifacts
vs-test:
runs-on: windows-latest
needs: vs-build
needs: [vs-build, windows-build]
strategy:
fail-fast: false
matrix:
nr: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
steps:
- uses: git-for-windows/setup-git-for-windows-sdk@v1
- name: download tracked files and build artifacts
uses: actions/download-artifact@v2
- uses: actions/checkout@v1
- name: download git-sdk-64-minimal
uses: actions/download-artifact@v1
with:
name: git-sdk-64-minimal
path: ${{github.workspace}}/git-sdk-64-minimal/
- name: download build artifacts
uses: actions/download-artifact@v1
with:
name: vs-artifacts
path: ${{github.workspace}}
- name: extract tracked files and build artifacts
- name: extract build artifacts
shell: bash
run: tar xf artifacts.tar.gz && tar xf tracked.tar.gz
run: tar xf artifacts.tar.gz
- name: test
shell: bash
shell: powershell
env:
MSYSTEM: MINGW64
NO_SVN_TESTS: 1
run: . /etc/profile && ci/run-test-slice.sh ${{matrix.nr}} 10
GIT_TEST_SKIP_REBASE_P: 1
run: |
& .\git-sdk-64-minimal\usr\bin\bash.exe -lc @"
# Let Git ignore the SDK and the test-cache
printf '%s\n' /git-sdk-64-minimal/ /test-cache/ >>.git/info/exclude
ci/run-test-slice.sh ${{matrix.nr}} 10
"@
- name: ci/print-test-failures.sh
if: failure()
shell: bash
run: ci/print-test-failures.sh
shell: powershell
run: |
& .\git-sdk-64-minimal\usr\bin\bash.exe -lc ci/print-test-failures.sh
- name: Upload failed tests' directories
if: failure() && env.FAILED_TEST_ARTIFACTS != ''
uses: actions/upload-artifact@v2
uses: actions/upload-artifact@v1
with:
name: failed-tests-windows
path: ${{env.FAILED_TEST_ARTIFACTS}}
@ -231,22 +297,19 @@ jobs:
- jobname: linux-gcc-default
cc: gcc
pool: ubuntu-latest
- jobname: linux-leaks
cc: gcc
pool: ubuntu-latest
env:
CC: ${{matrix.vector.cc}}
jobname: ${{matrix.vector.jobname}}
runs-on: ${{matrix.vector.pool}}
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v1
- run: ci/install-dependencies.sh
- run: ci/run-build-and-tests.sh
- run: ci/print-test-failures.sh
if: failure()
- name: Upload failed tests' directories
if: failure() && env.FAILED_TEST_ARTIFACTS != ''
uses: actions/upload-artifact@v2
uses: actions/upload-artifact@v1
with:
name: failed-tests-${{matrix.vector.jobname}}
path: ${{env.FAILED_TEST_ARTIFACTS}}
@ -261,8 +324,6 @@ jobs:
image: alpine
- jobname: Linux32
image: daald/ubuntu32:xenial
- jobname: pedantic
image: fedora
env:
jobname: ${{matrix.vector.jobname}}
runs-on: ubuntu-latest
@ -286,29 +347,9 @@ jobs:
jobname: StaticAnalysis
runs-on: ubuntu-18.04
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v1
- run: ci/install-dependencies.sh
- run: ci/run-static-analysis.sh
sparse:
needs: ci-config
if: needs.ci-config.outputs.enabled == 'yes'
env:
jobname: sparse
runs-on: ubuntu-20.04
steps:
- name: Download a current `sparse` package
# Ubuntu's `sparse` version is too old for us
uses: git-for-windows/get-azure-pipelines-artifact@v0
with:
repository: git/git
definitionId: 10
artifact: sparse-20.04
- name: Install the current `sparse` package
run: sudo dpkg -i sparse-20.04/sparse_*.deb
- uses: actions/checkout@v2
- name: Install other dependencies
run: ci/install-dependencies.sh
- run: make sparse
documentation:
needs: ci-config
if: needs.ci-config.outputs.enabled == 'yes'
@ -316,6 +357,6 @@ jobs:
jobname: Documentation
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v1
- run: ci/install-dependencies.sh
- run: ci/test-documentation.sh

3
.gitignore vendored
View File

@ -125,6 +125,7 @@
/git-range-diff
/git-read-tree
/git-rebase
/git-rebase--preserve-merges
/git-receive-pack
/git-reflog
/git-remote
@ -189,7 +190,6 @@
/gitweb/static/gitweb.min.*
/config-list.h
/command-list.h
/hook-list.h
*.tar.gz
*.dsc
*.deb
@ -224,7 +224,6 @@
*.lib
*.res
*.sln
*.sp
*.suo
*.ncb
*.vcproj

View File

@ -14,5 +14,4 @@ manpage-base-url.xsl
SubmittingPatches.txt
tmp-doc-diff/
GIT-ASCIIDOCFLAGS
/.build/
/GIT-EXCLUDED-PROGRAMS

View File

@ -551,51 +551,6 @@ Writing Documentation:
documentation, please see the documentation-related advice in the
Documentation/SubmittingPatches file).
In order to ensure the documentation is inclusive, avoid assuming
that an unspecified example person is male or female, and think
twice before using "he", "him", "she", or "her". Here are some
tips to avoid use of gendered pronouns:
- Prefer succinctness and matter-of-factly describing functionality
in the abstract. E.g.
--short:: Emit output in the short-format.
and avoid something like these overly verbose alternatives:
--short:: Use this to emit output in the short-format.
--short:: You can use this to get output in the short-format.
--short:: A user who prefers shorter output could....
--short:: Should a person and/or program want shorter output, he
she/they/it can...
This practice often eliminates the need to involve human actors in
your description, but it is a good practice regardless of the
avoidance of gendered pronouns.
- When it becomes awkward to stick to this style, prefer "you" when
addressing the the hypothetical user, and possibly "we" when
discussing how the program might react to the user. E.g.
You can use this option instead of --xyz, but we might remove
support for it in future versions.
while keeping in mind that you can probably be less verbose, e.g.
Use this instead of --xyz. This option might be removed in future
versions.
- If you still need to refer to an example person that is
third-person singular, you may resort to "singular they" to avoid
"he/she/him/her", e.g.
A contributor asks their upstream to pull from them.
Note that this sounds ungrammatical and unnatural to those who
learned that "they" is only used for third-person plural, e.g.
those who learn English as a second language in some parts of the
world.
Every user-visible change should be reflected in the documentation.
The same general rule as for code applies -- imitate the existing
conventions.

View File

@ -90,7 +90,6 @@ SP_ARTICLES += $(API_DOCS)
TECH_DOCS += MyFirstContribution
TECH_DOCS += MyFirstObjectWalk
TECH_DOCS += SubmittingPatches
TECH_DOCS += technical/bundle-format
TECH_DOCS += technical/hash-function-transition
TECH_DOCS += technical/http-protocol
TECH_DOCS += technical/index-format
@ -140,7 +139,6 @@ ASCIIDOC_CONF = -f asciidoc.conf
ASCIIDOC_COMMON = $(ASCIIDOC) $(ASCIIDOC_EXTRA) $(ASCIIDOC_CONF) \
-amanversion=$(GIT_VERSION) \
-amanmanual='Git Manual' -amansource='Git'
ASCIIDOC_DEPS = asciidoc.conf GIT-ASCIIDOCFLAGS
TXT_TO_HTML = $(ASCIIDOC_COMMON) -b $(ASCIIDOC_HTML)
TXT_TO_XML = $(ASCIIDOC_COMMON) -b $(ASCIIDOC_DOCBOOK)
MANPAGE_XSL = manpage-normal.xsl
@ -195,7 +193,6 @@ ASCIIDOC_DOCBOOK = docbook5
ASCIIDOC_EXTRA += -acompat-mode -atabsize=8
ASCIIDOC_EXTRA += -I. -rasciidoctor-extensions
ASCIIDOC_EXTRA += -alitdd='&\#x2d;&\#x2d;'
ASCIIDOC_DEPS = asciidoctor-extensions.rb GIT-ASCIIDOCFLAGS
DBLATEX_COMMON =
XMLTO_EXTRA += --skip-validation
XMLTO_EXTRA += -x manpage.xsl
@ -226,7 +223,6 @@ endif
ifneq ($(findstring $(MAKEFLAGS),s),s)
ifndef V
QUIET = @
QUIET_ASCIIDOC = @echo ' ' ASCIIDOC $@;
QUIET_XMLTO = @echo ' ' XMLTO $@;
QUIET_DB2TEXI = @echo ' ' DB2TEXI $@;
@ -234,15 +230,11 @@ ifndef V
QUIET_DBLATEX = @echo ' ' DBLATEX $@;
QUIET_XSLTPROC = @echo ' ' XSLTPROC $@;
QUIET_GEN = @echo ' ' GEN $@;
QUIET_LINT = @echo ' ' LINT $@;
QUIET_STDERR = 2> /dev/null
QUIET_SUBDIR0 = +@subdir=
QUIET_SUBDIR1 = ;$(NO_SUBDIR) echo ' ' SUBDIR $$subdir; \
$(MAKE) $(PRINT_DIR) -C $$subdir
QUIET_LINT_GITLINK = @echo ' ' LINT GITLINK $<;
QUIET_LINT_MANSEC = @echo ' ' LINT MAN SEC $<;
QUIET_LINT_MANEND = @echo ' ' LINT MAN END $<;
export V
endif
endif
@ -290,7 +282,7 @@ install-html: html
../GIT-VERSION-FILE: FORCE
$(QUIET_SUBDIR0)../ $(QUIET_SUBDIR1) GIT-VERSION-FILE
ifneq ($(filter-out lint-docs clean,$(MAKECMDGOALS)),)
ifneq ($(MAKECMDGOALS),clean)
-include ../GIT-VERSION-FILE
endif
@ -302,7 +294,9 @@ docdep_prereqs = \
cmd-list.made $(cmds_txt)
doc.dep : $(docdep_prereqs) $(DOC_DEP_TXT) build-docdep.perl
$(QUIET_GEN)$(PERL_PATH) ./build-docdep.perl >$@ $(QUIET_STDERR)
$(QUIET_GEN)$(RM) $@+ $@ && \
$(PERL_PATH) ./build-docdep.perl >$@+ $(QUIET_STDERR) && \
mv $@+ $@
ifneq ($(MAKECMDGOALS),clean)
-include doc.dep
@ -322,7 +316,8 @@ cmds_txt = cmds-ancillaryinterrogators.txt \
$(cmds_txt): cmd-list.made
cmd-list.made: cmd-list.perl ../command-list.txt $(MAN1_TXT)
$(QUIET_GEN)$(PERL_PATH) ./cmd-list.perl ../command-list.txt $(cmds_txt) $(QUIET_STDERR) && \
$(QUIET_GEN)$(RM) $@ && \
$(PERL_PATH) ./cmd-list.perl ../command-list.txt $(cmds_txt) $(QUIET_STDERR) && \
date >$@
mergetools_txt = mergetools-diff.txt mergetools-merge.txt
@ -330,7 +325,7 @@ mergetools_txt = mergetools-diff.txt mergetools-merge.txt
$(mergetools_txt): mergetools-list.made
mergetools-list.made: ../git-mergetool--lib.sh $(wildcard ../mergetools/*)
$(QUIET_GEN) \
$(QUIET_GEN)$(RM) $@ && \
$(SHELL_PATH) -c 'MERGE_TOOLS_DIR=../mergetools && \
. ../git-mergetool--lib.sh && \
show_tool_names can_diff "* " || :' >mergetools-diff.txt && \
@ -349,7 +344,6 @@ GIT-ASCIIDOCFLAGS: FORCE
fi
clean:
$(RM) -rf .build/
$(RM) *.xml *.xml+ *.html *.html+ *.1 *.5 *.7
$(RM) *.texi *.texi+ *.texi++ git.info gitman.info
$(RM) *.pdf
@ -360,23 +354,32 @@ clean:
$(RM) manpage-base-url.xsl
$(RM) GIT-ASCIIDOCFLAGS
$(MAN_HTML): %.html : %.txt $(ASCIIDOC_DEPS)
$(QUIET_ASCIIDOC)$(TXT_TO_HTML) -d manpage -o $@ $<
$(MAN_HTML): %.html : %.txt asciidoc.conf asciidoctor-extensions.rb GIT-ASCIIDOCFLAGS
$(QUIET_ASCIIDOC)$(RM) $@+ $@ && \
$(TXT_TO_HTML) -d manpage -o $@+ $< && \
mv $@+ $@
$(OBSOLETE_HTML): %.html : %.txto $(ASCIIDOC_DEPS)
$(QUIET_ASCIIDOC)$(TXT_TO_HTML) -o $@ $<
$(OBSOLETE_HTML): %.html : %.txto asciidoc.conf asciidoctor-extensions.rb GIT-ASCIIDOCFLAGS
$(QUIET_ASCIIDOC)$(RM) $@+ $@ && \
$(TXT_TO_HTML) -o $@+ $< && \
mv $@+ $@
manpage-base-url.xsl: manpage-base-url.xsl.in
$(QUIET_GEN)sed "s|@@MAN_BASE_URL@@|$(MAN_BASE_URL)|" $< > $@
%.1 %.5 %.7 : %.xml manpage-base-url.xsl $(wildcard manpage*.xsl)
$(QUIET_XMLTO)$(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<
$(QUIET_XMLTO)$(RM) $@ && \
$(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<
%.xml : %.txt $(ASCIIDOC_DEPS)
$(QUIET_ASCIIDOC)$(TXT_TO_XML) -d manpage -o $@ $<
%.xml : %.txt asciidoc.conf asciidoctor-extensions.rb GIT-ASCIIDOCFLAGS
$(QUIET_ASCIIDOC)$(RM) $@+ $@ && \
$(TXT_TO_XML) -d manpage -o $@+ $< && \
mv $@+ $@
user-manual.xml: user-manual.txt user-manual.conf asciidoctor-extensions.rb GIT-ASCIIDOCFLAGS
$(QUIET_ASCIIDOC)$(TXT_TO_XML) -d book -o $@ $<
$(QUIET_ASCIIDOC)$(RM) $@+ $@ && \
$(TXT_TO_XML) -d book -o $@+ $< && \
mv $@+ $@
technical/api-index.txt: technical/api-index-skel.txt \
technical/api-index.sh $(patsubst %,%.txt,$(API_DOCS))
@ -397,35 +400,46 @@ XSLTOPTS += --stringparam html.stylesheet docbook-xsl.css
XSLTOPTS += --param generate.consistent.ids 1
user-manual.html: user-manual.xml $(XSLT)
$(QUIET_XSLTPROC)xsltproc $(XSLTOPTS) -o $@ $(XSLT) $<
$(QUIET_XSLTPROC)$(RM) $@+ $@ && \
xsltproc $(XSLTOPTS) -o $@+ $(XSLT) $< && \
mv $@+ $@
git.info: user-manual.texi
$(QUIET_MAKEINFO)$(MAKEINFO) --no-split -o $@ user-manual.texi
user-manual.texi: user-manual.xml
$(QUIET_DB2TEXI)$(DOCBOOK2X_TEXI) user-manual.xml --encoding=UTF-8 --to-stdout >$@+ && \
$(PERL_PATH) fix-texi.perl <$@+ >$@ && \
$(RM) $@+
$(QUIET_DB2TEXI)$(RM) $@+ $@ && \
$(DOCBOOK2X_TEXI) user-manual.xml --encoding=UTF-8 --to-stdout >$@++ && \
$(PERL_PATH) fix-texi.perl <$@++ >$@+ && \
rm $@++ && \
mv $@+ $@
user-manual.pdf: user-manual.xml
$(QUIET_DBLATEX)$(DBLATEX) -o $@ $(DBLATEX_COMMON) $<
$(QUIET_DBLATEX)$(RM) $@+ $@ && \
$(DBLATEX) -o $@+ $(DBLATEX_COMMON) $< && \
mv $@+ $@
gitman.texi: $(MAN_XML) cat-texi.perl texi.xsl
$(QUIET_DB2TEXI) \
$(QUIET_DB2TEXI)$(RM) $@+ $@ && \
($(foreach xml,$(sort $(MAN_XML)),xsltproc -o $(xml)+ texi.xsl $(xml) && \
$(DOCBOOK2X_TEXI) --encoding=UTF-8 --to-stdout $(xml)+ && \
$(RM) $(xml)+ &&) true) > $@+ && \
$(PERL_PATH) cat-texi.perl $@ <$@+ >$@ && \
$(RM) $@+
rm $(xml)+ &&) true) > $@++ && \
$(PERL_PATH) cat-texi.perl $@ <$@++ >$@+ && \
rm $@++ && \
mv $@+ $@
gitman.info: gitman.texi
$(QUIET_MAKEINFO)$(MAKEINFO) --no-split --no-validate $*.texi
$(patsubst %.txt,%.texi,$(MAN_TXT)): %.texi : %.xml
$(QUIET_DB2TEXI)$(DOCBOOK2X_TEXI) --to-stdout $*.xml >$@
$(QUIET_DB2TEXI)$(RM) $@+ $@ && \
$(DOCBOOK2X_TEXI) --to-stdout $*.xml >$@+ && \
mv $@+ $@
howto-index.txt: howto-index.sh $(HOWTO_TXT)
$(QUIET_GEN)'$(SHELL_PATH_SQ)' ./howto-index.sh $(sort $(HOWTO_TXT)) >$@
$(QUIET_GEN)$(RM) $@+ $@ && \
'$(SHELL_PATH_SQ)' ./howto-index.sh $(sort $(HOWTO_TXT)) >$@+ && \
mv $@+ $@
$(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt
$(QUIET_ASCIIDOC)$(TXT_TO_HTML) $*.txt
@ -434,9 +448,10 @@ WEBDOC_DEST = /pub/software/scm/git/docs
howto/%.html: ASCIIDOC_EXTRA += -a git-relative-html-prefix=../
$(patsubst %.txt,%.html,$(HOWTO_TXT)): %.html : %.txt GIT-ASCIIDOCFLAGS
$(QUIET_ASCIIDOC) \
$(QUIET_ASCIIDOC)$(RM) $@+ $@ && \
sed -e '1,/^$$/d' $< | \
$(TXT_TO_HTML) - >$@
$(TXT_TO_HTML) - >$@+ && \
mv $@+ $@
install-webdoc : html
'$(SHELL_PATH_SQ)' ./install-webdoc.sh $(WEBDOC_DEST)
@ -463,68 +478,18 @@ quick-install-html: require-htmlrepo
print-man1:
@for i in $(MAN1_TXT); do echo $$i; done
## Lint: Common
.build:
$(QUIET)mkdir $@
.build/lint-docs: | .build
$(QUIET)mkdir $@
## Lint: gitlink
.build/lint-docs/gitlink: | .build/lint-docs
$(QUIET)mkdir $@
.build/lint-docs/gitlink/howto: | .build/lint-docs/gitlink
$(QUIET)mkdir $@
.build/lint-docs/gitlink/config: | .build/lint-docs/gitlink
$(QUIET)mkdir $@
LINT_DOCS_GITLINK = $(patsubst %.txt,.build/lint-docs/gitlink/%.ok,$(HOWTO_TXT) $(DOC_DEP_TXT))
$(LINT_DOCS_GITLINK): | .build/lint-docs/gitlink
$(LINT_DOCS_GITLINK): | .build/lint-docs/gitlink/howto
$(LINT_DOCS_GITLINK): | .build/lint-docs/gitlink/config
$(LINT_DOCS_GITLINK): lint-gitlink.perl
$(LINT_DOCS_GITLINK): .build/lint-docs/gitlink/%.ok: %.txt
$(QUIET_LINT_GITLINK)$(PERL_PATH) lint-gitlink.perl \
$< \
lint-docs::
$(QUIET_LINT)$(PERL_PATH) lint-gitlink.perl \
$(HOWTO_TXT) $(DOC_DEP_TXT) \
--section=1 $(MAN1_TXT) \
--section=5 $(MAN5_TXT) \
--section=7 $(MAN7_TXT) >$@
.PHONY: lint-docs-gitlink
lint-docs-gitlink: $(LINT_DOCS_GITLINK)
## Lint: man-end-blurb
.build/lint-docs/man-end-blurb: | .build/lint-docs
$(QUIET)mkdir $@
LINT_DOCS_MAN_END_BLURB = $(patsubst %.txt,.build/lint-docs/man-end-blurb/%.ok,$(MAN_TXT))
$(LINT_DOCS_MAN_END_BLURB): | .build/lint-docs/man-end-blurb
$(LINT_DOCS_MAN_END_BLURB): lint-man-end-blurb.perl
$(LINT_DOCS_MAN_END_BLURB): .build/lint-docs/man-end-blurb/%.ok: %.txt
$(QUIET_LINT_MANEND)$(PERL_PATH) lint-man-end-blurb.perl $< >$@
.PHONY: lint-docs-man-end-blurb
lint-docs-man-end-blurb: $(LINT_DOCS_MAN_END_BLURB)
## Lint: man-section-order
.build/lint-docs/man-section-order: | .build/lint-docs
$(QUIET)mkdir $@
LINT_DOCS_MAN_SECTION_ORDER = $(patsubst %.txt,.build/lint-docs/man-section-order/%.ok,$(MAN_TXT))
$(LINT_DOCS_MAN_SECTION_ORDER): | .build/lint-docs/man-section-order
$(LINT_DOCS_MAN_SECTION_ORDER): lint-man-section-order.perl
$(LINT_DOCS_MAN_SECTION_ORDER): .build/lint-docs/man-section-order/%.ok: %.txt
$(QUIET_LINT_MANSEC)$(PERL_PATH) lint-man-section-order.perl $< >$@
.PHONY: lint-docs-man-section-order
lint-docs-man-section-order: $(LINT_DOCS_MAN_SECTION_ORDER)
## Lint: list of targets above
.PHONY: lint-docs
lint-docs: lint-docs-gitlink
lint-docs: lint-docs-man-end-blurb
lint-docs: lint-docs-man-section-order
--section=7 $(MAN7_TXT); \
$(PERL_PATH) lint-man-end-blurb.perl $(MAN_TXT); \
$(PERL_PATH) lint-man-section-order.perl $(MAN_TXT);
ifeq ($(wildcard po/Makefile),po/Makefile)
doc-l10n install-l10n::
$(MAKE) -C po $@
endif
# Delete the target file on error
.DELETE_ON_ERROR:
.PHONY: FORCE

View File

@ -47,7 +47,7 @@ Veteran contributors who are especially interested in helping mentor newcomers
are present on the list. In order to avoid search indexers, group membership is
required to view messages; anyone can join and no approval is required.
==== https://web.libera.chat/#git-devel[#git-devel] on Libera Chat
==== https://webchat.freenode.net/#git-devel[#git-devel] on Freenode
This IRC channel is for conversations between Git contributors. If someone is
currently online and knows the answer to your question, you can receive help
@ -827,7 +827,7 @@ either examining recent pull requests where someone has been granted `/allow`
(https://github.com/gitgitgadget/git/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+%22%2Fallow%22[Search:
is:pr is:open "/allow"]), in which case both the author and the person who
granted the `/allow` can now `/allow` you, or by inquiring on the
https://web.libera.chat/#git-devel[#git-devel] IRC channel on Libera Chat
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
@ -1029,42 +1029,22 @@ kidding - be patient!)
[[v2-git-send-email]]
=== Sending v2
This section will focus on how to send a v2 of your patchset. To learn what
should go into v2, skip ahead to <<reviewing,Responding to Reviews>> for
information on how to handle comments from reviewers.
Skip ahead to <<reviewing,Responding to Reviews>> for information on how to
handle comments from reviewers. Continue this section when your topic branch is
shaped the way you want it to look for your patchset v2.
We'll reuse our `psuh` topic branch for v2. Before we make any changes, we'll
mark the tip of our v1 branch for easy reference:
When you're ready with the next iteration of your patch, the process is fairly
similar.
First, generate your v2 patches again:
----
$ git checkout psuh
$ git branch psuh-v1
$ git format-patch -v2 --cover-letter -o psuh/ master..psuh
----
Refine your patch series by using `git rebase -i` to adjust commits based upon
reviewer comments. Once the patch series is ready for submission, generate your
patches again, but with some new flags:
----
$ git format-patch -v2 --cover-letter -o psuh/ --range-diff master..psuh-v1 master..
----
The `--range-diff master..psuh-v1` parameter tells `format-patch` to include a
range-diff between `psuh-v1` and `psuh` in the cover letter (see
linkgit:git-range-diff[1]). This helps tell reviewers about the differences
between your v1 and v2 patches.
The `-v2` parameter tells `format-patch` to output your patches
as version "2". For instance, you may notice that your v2 patches are
all named like `v2-000n-my-commit-subject.patch`. `-v2` will also format
your patches by prefixing them with "[PATCH v2]" instead of "[PATCH]",
and your range-diff will be prefaced with "Range-diff against v1".
Afer you run this command, `format-patch` will output the patches to the `psuh/`
directory, alongside the v1 patches. Using a single directory makes it easy to
refer to the old v1 patches while proofreading the v2 patches, but you will need
to be careful to send out only the v2 patches. We will use a pattern like
"psuh/v2-*.patch" (not "psuh/*.patch", which would match v1 and v2 patches).
This will add your v2 patches, all named like `v2-000n-my-commit-subject.patch`,
to the `psuh/` directory. You may notice that they are sitting alongside the v1
patches; that's fine, but be careful when you are ready to send them.
Edit your cover letter again. Now is a good time to mention what's different
between your last version and now, if it's something significant. You do not
@ -1102,7 +1082,7 @@ to the command:
----
$ git send-email --to=target@example.com
--in-reply-to="<foo.12345.author@example.com>"
psuh/v2-*.patch
psuh/v2*
----
[[single-patch]]

View File

@ -691,7 +691,7 @@ 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
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.
----
@ -779,7 +779,7 @@ Count all the objects within and modify the print statement:
while ((oid = oidset_iter_next(&oit)))
omitted_count++;
printf("commits %d\nblobs %d\ntags %d\ntrees %d\nomitted %d\n",
printf("commits %d\nblobs %d\ntags %d\ntrees%d\nomitted %d\n",
commit_count, blob_count, tag_count, tree_count, omitted_count);
----

View File

@ -50,7 +50,7 @@ Fixes since v1.6.0.2
if the working tree is currently dirty.
* "git for-each-ref --format=%(subject)" fixed for commits with no
newline in the message body.
no newline in the message body.
* "git remote" fixed to protect printf from user input.

View File

@ -365,7 +365,7 @@ details).
(merge 2fbd4f9 mh/maint-lockfile-overflow later to maint).
* Invocations of "git checkout" used internally by "git rebase" were
counted as "checkout", and affected later "git checkout -", which took
counted as "checkout", and affected later "git checkout -" to the
the user to an unexpected place.
(merge 3bed291 rr/rebase-checkout-reflog later to maint).

View File

@ -184,8 +184,8 @@ Performance, Internal Implementation, Development Support etc.
the ref backend in use, as its format is much richer than the
normal refs, and written directly by "git fetch" as a plain file..
* An unused binary has been discarded, and a bunch of commands
have been turned into built-in.
* An unused binary has been discarded, and and a bunch of commands
have been turned into into built-in.
* A handful of places in in-tree code still relied on being able to
execute the git subcommands, especially built-ins, in "git-foo"

View File

@ -0,0 +1,24 @@
Git v2.30.2 Release Notes
=========================
This release addresses the security issue CVE-2022-24765.
Fixes since v2.30.2
-------------------
* Build fix on Windows.
* Fix `GIT_CEILING_DIRECTORIES` with Windows-style root directories.
* CVE-2022-24765:
On multi-user machines, Git users might find themselves
unexpectedly in a Git worktree, e.g. when another user created a
repository in `C:\.git`, in a mounted network drive or in a
scratch space. Merely having a Git-aware prompt that runs `git
status` (or `git diff`) and navigating to a directory which is
supposedly not a Git worktree, or opening such a directory in an
editor or IDE such as VS Code or Atom, will potentially run
commands defined by that other user.
Credit for finding this vulnerability goes to 俞晨东; The fix was
authored by Johannes Schindelin.

View File

@ -0,0 +1,21 @@
Git v2.30.4 Release Notes
=========================
This release contains minor fix-ups for the changes that went into
Git 2.30.3, which was made to address CVE-2022-24765.
* The code that was meant to parse the new `safe.directory`
configuration variable was not checking what configuration
variable was being fed to it, which has been corrected.
* '*' can be used as the value for the `safe.directory` variable to
signal that the user considers that any directory is safe.
Derrick Stolee (2):
t0033: add tests for safe.directory
setup: opt-out of check with safe.directory=*
Matheus Valadares (1):
setup: fix safe.directory key not being checked

View File

@ -0,0 +1,12 @@
Git v2.30.5 Release Notes
=========================
This release contains minor fix-ups for the changes that went into
Git 2.30.3 and 2.30.4, addressing CVE-2022-29187.
* The safety check that verifies a safe ownership of the Git
worktree is now extended to also cover the ownership of the Git
directory (and the `.git` file, if there is any).
Carlo Marcelo Arenas Belón (1):
setup: tighten ownership checks post CVE-2022-24765

View File

@ -0,0 +1,6 @@
Git v2.31.2 Release Notes
=========================
This release merges up the fixes that appear in v2.30.3 to address
the security issue CVE-2022-24765; see the release notes for that
version for details.

View File

@ -0,0 +1,4 @@
Git Documentation/RelNotes/2.31.3.txt Release Notes
=========================
This release merges up the fixes that appear in v2.31.3.

View File

@ -0,0 +1,6 @@
Git v2.31.4 Release Notes
=========================
This release merges up the fixes that appear in v2.30.5 to address
the security issue CVE-2022-29187; see the release notes for that
version for details.

View File

@ -0,0 +1,6 @@
Git v2.32.1 Release Notes
=========================
This release merges up the fixes that appear in v2.30.3 and
v2.31.2 to address the security issue CVE-2022-24765; see the
release notes for these versions for details.

View File

@ -0,0 +1,4 @@
Git Documentation/RelNotes/2.32.2.txt Release Notes
=========================
This release merges up the fixes that appear in v2.32.2.

View File

@ -0,0 +1,6 @@
Git v2.32.3 Release Notes
=========================
This release merges up the fixes that appear in v2.30.5 and
v2.31.4 to address the security issue CVE-2022-29187; see the
release notes for these versions for details.

View File

@ -1,279 +0,0 @@
Git 2.33 Release Notes
======================
Updates since Git 2.32
----------------------
UI, Workflows & Features
* "git send-email" learned the "--sendmail-cmd" command line option
and the "sendemail.sendmailCmd" configuration variable, which is a
more sensible approach than the current way of repurposing the
"smtp-server" that is meant to name the server to instead name the
command to talk to the server.
* The userdiff pattern for C# learned the token "record".
* "git rev-list" learns to omit the "commit <object-name>" header
lines from the output with the `--no-commit-header` option.
* "git worktree add --lock" learned to record why the worktree is
locked with a custom message.
Performance, Internal Implementation, Development Support etc.
* The code to handle the "--format" option in "for-each-ref" and
friends made too many string comparisons on %(atom)s used in the
format string, which has been corrected by converting them into
enum when the format string is parsed.
* Use the hashfile API in the codepath that writes the index file to
reduce code duplication.
* Repeated rename detections in a sequence of mergy operations have
been optimized out for the 'ort' merge strategy.
* Preliminary clean-up of tests before the main reftable changes
hits the codebase.
* The backend for "diff -G/-S" has been updated to use pcre2 engine
when available.
* Use ".DELETE_ON_ERROR" pseudo target to simplify our Makefile.
* Code cleanup around struct_type_init() functions.
* "git send-email" optimization.
* GitHub Actions / CI update.
(merge 0dc787a9f2 js/ci-windows-update later to maint).
* Object accesses in repositories with many alternate object store
have been optimized.
* "git log" has been optimized not to waste cycles to load ref
decoration data that may not be needed.
* Many "printf"-like helper functions we have have been annotated
with __attribute__() to catch placeholder/parameter mismatches.
* Tests that cover protocol bits have been updated and helpers
used there have been consolidated.
* The CI gained a new job to run "make sparse" check.
* "git status" codepath learned to work with sparsely populated index
without hydrating it fully.
* A guideline for gender neutral documentation has been added.
* Documentation on "git diff -l<n>" and diff.renameLimit have been
updated, and the defaults for these limits have been raised.
* The completion support used to offer alternate spelling of options
that exist only for compatibility, which has been corrected.
* "TEST_OUTPUT_DIRECTORY=there make test" failed to work, which has
been corrected.
* "git bundle" gained more test coverage.
* "git read-tree" had a codepath where blobs are fetched one-by-one
from the promisor remote, which has been corrected to fetch in bulk.
* Rewrite of "git submodule" in C continues.
* "git checkout" and "git commit" learn to work without unnecessarily
expanding sparse indexes.
Fixes since v2.32
-----------------
* We historically rejected a very short string as an author name
while accepting a patch e-mail, which has been loosened.
(merge 72ee47ceeb ef/mailinfo-short-name later to maint).
* The parallel checkout codepath did not initialize object ID field
used to talk to the worker processes in a futureproof way.
* Rewrite code that triggers undefined behaviour warning.
(merge aafa5df0df jn/size-t-casted-to-off-t-fix later to maint).
* The description of "fast-forward" in the glossary has been updated.
(merge e22f2daed0 ry/clarify-fast-forward-in-glossary later to maint).
* Recent "git clone" left a temporary directory behind when the
transport layer returned an failure.
(merge 6aacb7d861 jk/clone-clean-upon-transport-error later to maint).
* "git fetch" over protocol v2 left its side of the socket open after
it finished speaking, which unnecessarily wasted the resource on
the other side.
(merge ae1a7eefff jk/fetch-pack-v2-half-close-early later to maint).
* The command line completion (in contrib/) learned that "git diff"
takes the "--anchored" option.
(merge d1e7c2cac9 tb/complete-diff-anchored later to maint).
* "git-svn" tests assumed that "locale -a", which is used to pick an
available UTF-8 locale, is available everywhere. A knob has been
introduced to allow testers to specify a suitable locale to use.
(merge 482c962de4 dd/svn-test-wo-locale-a later to maint).
* Update "git subtree" to work better on Windows.
(merge 77f37de39f js/subtree-on-windows-fix later to maint).
* Remove multimail from contrib/
(merge f74d11471f js/no-more-multimail later to maint).
* Make the codebase MSAN clean.
(merge 4dbc55e87d ah/uninitialized-reads-fix later to maint).
* Work around inefficient glob substitution in older versions of bash
by rewriting parts of a test.
(merge eb87c6f559 jx/t6020-with-older-bash later to maint).
* Avoid duplicated work while building reachability bitmaps.
(merge aa9ad6fee5 jk/bitmap-tree-optim later to maint).
* We broke "GIT_SKIP_TESTS=t?000" to skip certain tests in recent
update, which got fixed.
* The side-band demultiplexer that is used to display progress output
from the remote end did not clear the line properly when the end of
line hits at a packet boundary, which has been corrected.
* Some test scripts assumed that readlink(1) was universally
installed and available, which is not the case.
(merge 7c0afdf23c jk/test-without-readlink-1 later to maint).
* Recent update to completion script (in contrib/) broke those who
use the __git_complete helper to define completion to their custom
command.
(merge cea232194d fw/complete-cmd-idx-fix later to maint).
* Output from some of our tests were affected by the width of the
terminal that they were run in, which has been corrected by
exporting a fixed value in the COLUMNS environment.
(merge c49a177bec ab/fix-columns-to-80-during-tests later to maint).
* On Windows, mergetool has been taught to find kdiff3.exe just like
it finds winmerge.exe.
(merge 47eb4c6890 ms/mergetools-kdiff3-on-windows later to maint).
* When we cannot figure out how wide the terminal is, we use a
fallback value of 80 ourselves (which cannot be avoided), but when
we run the pager, we export it in COLUMNS, which forces the pager
to use the hardcoded value, even when the pager is perfectly
capable to figure it out itself. Stop exporting COLUMNS when we
fall back on the hardcoded default value for our own use.
(merge 9b6e2c8b98 js/stop-exporting-bogus-columns later to maint).
* "git cat-file --batch-all-objects"" misbehaved when "--batch" is in
use and did not ask for certain object traits.
(merge ee02ac6164 zh/cat-file-batch-fix later to maint).
* Some code and doc clarification around "git push".
* The "union" conflict resultion variant misbehaved when used with
binary merge driver.
(merge 382b601acd jk/union-merge-binary later to maint).
* Prevent "git p4" from failing to submit changes to binary file.
(merge 54662d5958 dc/p4-binary-submit-fix later to maint).
* "git grep --and -e foo" ought to have been diagnosed as an error
but instead segfaulted, which has been corrected.
(merge fe7fe62d8d rs/grep-parser-fix later to maint).
* The merge code had funny interactions between content based rename
detection and directory rename detection.
(merge 3585d0ea23 en/merge-dir-rename-corner-case-fix later to maint).
* When rebuilding the multi-pack index file reusing an existing one,
we used to blindly trust the existing file and ended up carrying
corrupted data into the updated file, which has been corrected.
(merge f89ecf7988 tb/midx-use-checksum later to maint).
* Update the location of system-side configuration file on Windows.
(merge e355307692 js/gfw-system-config-loc-fix later to maint).
* Code recently added to support common ancestry negotiation during
"git push" did not sanity check its arguments carefully enough.
(merge eff40457a4 ab/fetch-negotiate-segv-fix later to maint).
* Update the documentation not to assume users are of certain gender
and adds to guidelines to do so.
(merge 46a237f42f ds/gender-neutral-doc later to maint).
* "git commit --allow-empty-message" won't abort the operation upon
an empty message, but the hint shown in the editor said otherwise.
(merge 6f70f00b4f hj/commit-allow-empty-message later to maint).
* The code that gives an error message in "git multi-pack-index" when
no subcommand is given tried to print a NULL pointer as a strong,
which has been corrected.
(merge 88617d11f9 tb/reverse-midx later to maint).
* CI update.
(merge a066a90db6 js/ci-check-whitespace-updates later to maint).
* Documentation fix for "git pull --rebase=no".
(merge d3236becec fc/pull-no-rebase-merges-theirs-into-ours later to maint).
* A race between repacking and using pack bitmaps has been corrected.
(merge dc1daacdcc jk/check-pack-valid-before-opening-bitmap later to maint).
* The local changes stashed by "git merge --autostash" were lost when
the merge failed in certain ways, which has been corrected.
* Windows rmdir() equivalent behaves differently from POSIX ones in
that when used on a symbolic link that points at a directory, the
target directory gets removed, which has been corrected.
(merge 3e7d4888e5 tb/mingw-rmdir-symlink-to-directory later to maint).
* Other code cleanup, docfix, build fix, etc.
(merge bfe35a6165 ah/doc-describe later to maint).
(merge f302c1e4aa jc/clarify-revision-range later to maint).
(merge 3127ff90ea tl/fix-packfile-uri-doc later to maint).
(merge a84216c684 jk/doc-color-pager later to maint).
(merge 4e0a64a713 ab/trace2-squelch-gcc-warning later to maint).
(merge 225f7fa847 ps/rev-list-object-type-filter later to maint).
(merge 5317dfeaed dd/honor-users-tar-in-tests later to maint).
(merge ace6d8e3d6 tk/partial-clone-repack-doc later to maint).
(merge 7ba68e0cf1 js/trace2-discard-event-docfix later to maint).
(merge 8603c419d3 fc/doc-default-to-upstream-config later to maint).
(merge 1d72b604ef jk/revision-squelch-gcc-warning later to maint).
(merge abcb66c614 ar/typofix later to maint).
(merge 9853830787 ah/graph-typofix later to maint).
(merge aac578492d ab/config-hooks-path-testfix later to maint).
(merge 98c7656a18 ar/more-typofix later to maint).
(merge 6fb9195f6c jk/doc-max-pack-size later to maint).
(merge 4184cbd635 ar/mailinfo-memcmp-to-skip-prefix later to maint).
(merge 91d2347033 ar/doc-libera-chat-in-my-first-contrib later to maint).
(merge 338abb0f04 ab/cmd-foo-should-return later to maint).
(merge 546096a5cb ab/xdiff-bug-cleanup later to maint).
(merge b7b793d1e7 ab/progress-cleanup later to maint).
(merge d94f9b8e90 ba/object-info later to maint).
(merge 52ff891c03 ar/test-code-cleanup later to maint).
(merge a0538e5c8b dd/document-log-decorate-default later to maint).
(merge ce24797d38 mr/cmake later to maint).
(merge 9eb542f2ee ab/pre-auto-gc-hook-test later to maint).
(merge 9fffc38583 bk/doc-commit-typofix later to maint).
(merge 1cf823d8f0 ks/submodule-cleanup later to maint).
(merge ebbf5d2b70 js/config-mak-windows-pcre-fix later to maint).
(merge 617480d75b hn/refs-iterator-peel-returns-boolean later to maint).
(merge 6a24cc71ed ar/submodule-helper-include-cleanup later to maint).
(merge 5632e838f8 rs/khash-alloc-cleanup later to maint).
(merge b1d87fbaf1 jk/typofix later to maint).
(merge e04170697a ab/gitignore-discovery-doc later to maint).
(merge 8232a0ff48 dl/packet-read-response-end-fix later to maint).
(merge eb448631fb dl/diff-merge-base later to maint).
(merge c510928a25 hn/refs-debug-empty-prefix later to maint).
(merge ddcb189d9d tb/bitmap-type-filter-comment-fix later to maint).
(merge 878b399734 pb/submodule-recurse-doc later to maint).
(merge 734283855f jk/config-env-doc later to maint).
(merge 482e1488a9 ab/getcwd-test later to maint).
(merge f0b922473e ar/doc-markup-fix later to maint).

View File

@ -1,138 +0,0 @@
Git 2.33.1 Release Notes
========================
This primarily is to backport various fixes accumulated during the
development towards Git 2.34, the next feature release.
Fixes since v2.33
-----------------
* The unicode character width table (used for output alignment) has
been updated.
* Input validation of "git pack-objects --stdin-packs" has been
corrected.
* Bugfix for common ancestor negotiation recently introduced in "git
push" codepath.
* "git pull" had various corner cases that were not well thought out
around its --rebase backend, e.g. "git pull --ff-only" did not stop
but went ahead and rebased when the history on other side is not a
descendant of our history. The series tries to fix them up.
* "git apply" miscounted the bytes and failed to read to the end of
binary hunks.
* "git range-diff" code clean-up.
* "git commit --fixup" now works with "--edit" again, after it was
broken in v2.32.
* Use upload-artifacts v1 (instead of v2) for 32-bit linux, as the
new version has a blocker bug for that architecture.
* Checking out all the paths from HEAD during the last conflicted
step in "git rebase" and continuing would cause the step to be
skipped (which is expected), but leaves MERGE_MSG file behind in
$GIT_DIR and confuses the next "git commit", which has been
corrected.
* Various bugs in "git rebase -r" have been fixed.
* mmap() imitation used to call xmalloc() that dies upon malloc()
failure, which has been corrected to just return an error to the
caller to be handled.
* "git diff --relative" segfaulted and/or produced incorrect result
when there are unmerged paths.
* The delayed checkout code path in "git checkout" etc. were chatty
even when --quiet and/or --no-progress options were given.
* "git branch -D <branch>" used to refuse to remove a broken branch
ref that points at a missing commit, which has been corrected.
* Build update for Apple clang.
* The parser for the "--nl" option of "git column" has been
corrected.
* "git upload-pack" which runs on the other side of "git fetch"
forgot to take the ref namespaces into account when handling
want-ref requests.
* The sparse-index support can corrupt the index structure by storing
a stale and/or uninitialized data, which has been corrected.
* Buggy tests could damage repositories outside the throw-away test
area we created. We now by default export GIT_CEILING_DIRECTORIES
to limit the damage from such a stray test.
* Even when running "git send-email" without its own threaded
discussion support, a threading related header in one message is
carried over to the subsequent message to result in an unwanted
threading, which has been corrected.
* The output from "git fast-export", when its anonymization feature
is in use, showed an annotated tag incorrectly.
* Recent "diff -m" changes broke "gitk", which has been corrected.
* "git maintenance" scheduler fix for macOS.
* A pathname in an advice message has been made cut-and-paste ready.
* The "git apply -3" code path learned not to bother the lower level
merge machinery when the three-way merge can be trivially resolved
without the content level merge.
* The code that optionally creates the *.rev reverse index file has
been optimized to avoid needless computation when it is not writing
the file out.
* "git range-diff -I... <range> <range>" segfaulted, which has been
corrected.
* The order in which various files that make up a single (conceptual)
packfile has been reevaluated and straightened up. This matters in
correctness, as an incomplete set of files must not be shown to a
running Git.
* The "mode" word is useless in a call to open(2) that does not
create a new file. Such a call in the files backend of the ref
subsystem has been cleaned up.
* "git update-ref --stdin" failed to flush its output as needed,
which potentially led the conversation to a deadlock.
* When "git am --abort" fails to abort correctly, it still exited
with exit status of 0, which has been corrected.
* Correct nr and alloc members of strvec struct to be of type size_t.
* "git stash", where the tentative change involves changing a
directory to a file (or vice versa), was confused, which has been
corrected.
* "git clone" from a repository whose HEAD is unborn into a bare
repository didn't follow the branch name the other side used, which
is corrected.
* "git cvsserver" had a long-standing bug in its authentication code,
which has finally been corrected (it is unclear and is a separate
question if anybody is seriously using it, though).
* "git difftool --dir-diff" mishandled symbolic links.
* Sensitive data in the HTTP trace were supposed to be redacted, but
we failed to do so in HTTP/2 requests.
* "make clean" has been updated to remove leftover .depend/
directories, even when it is not told to use them to compute header
dependencies.
* Protocol v0 clients can get stuck parsing a malformed feature line.
Also contains various documentation updates and code clean-ups.

View File

@ -1,438 +0,0 @@
Git 2.34 Release Notes
======================
Updates since Git 2.33
----------------------
Backward compatibility notes
* The "--preserve-merges" option of "git rebase" has been removed.
UI, Workflows & Features
* Pathname expansion (like "~username/") learned a way to specify a
location relative to Git installation (e.g. its $sharedir which is
$(prefix)/share), with "%(prefix)".
* The `ort` strategy is used instead of `recursive` as the default
merge strategy.
* The userdiff pattern for "java" language has been updated.
* "git rebase" by default skips changes that are equivalent to
commits that are already in the history the branch is rebased onto;
give messages when this happens to let the users be aware of
skipped commits, and also teach them how to tell "rebase" to keep
duplicated changes.
* The advice message that "git cherry-pick" gives when it asks
conflicted replay of a commit to be resolved by the end user has
been updated.
* After "git clone --recurse-submodules", all submodules are cloned
but they are not by default recursed into by other commands. With
submodule.stickyRecursiveClone configuration set, submodule.recurse
configuration is set to true in a repository created by "clone"
with "--recurse-submodules" option.
* The logic for auto-correction of misspelt subcommands learned to go
interactive when the help.autocorrect configuration variable is set
to 'prompt'.
* "git maintenance" scheduler learned to use systemd timers as a
possible backend.
* "git diff --submodule=diff" showed failure from run_command() when
trying to run diff inside a submodule, when the user manually
removes the submodule directory.
* "git bundle unbundle" learned to show progress display.
* In cone mode, the sparse-index code path learned to remove ignored
files (like build artifacts) outside the sparse cone, allowing the
entire directory outside the sparse cone to be removed, which is
especially useful when the sparse patterns change.
* Taking advantage of the CGI interface, http-backend has been
updated to enable protocol v2 automatically when the other side
asks for it.
* The credential-cache helper has been adjusted to Windows.
* The error in "git help no-such-git-command" is handled better.
* The unicode character width table (used for output alignment) has
been updated.
* The ref iteration code used to optionally allow dangling refs to be
shown, which has been tightened up.
* "git add", "git mv", and "git rm" have been adjusted to avoid
updating paths outside of the sparse-checkout definition unless
the user specifies a "--sparse" option.
* "git repack" has been taught to generate multi-pack reachability
bitmaps.
* "git fsck" has been taught to report mismatch between expected and
actual types of an object better.
* In addition to GnuPG, ssh public crypto can be used for object and
push-cert signing. Note that this feature cannot be used with
ssh-keygen from OpenSSH 8.7, whose support for it is broken. Avoid
using it unless you update to OpenSSH 8.8.
* "git log --grep=string --author=name" learns to highlight hits just
like "git grep string" does.
Performance, Internal Implementation, Development Support etc.
* "git bisect" spawned "git show-branch" only to pretty-print the
title of the commit after checking out the next version to be
tested; this has been rewritten in C.
* "git add" can work better with the sparse index.
* Support for ancient versions of cURL library (pre 7.19.4) has been
dropped.
* A handful of tests that assumed implementation details of files
backend for refs have been cleaned up.
* trace2 logs learned to show parent process name to see in what
context Git was invoked.
* Loading of ref tips to prepare for common ancestry negotiation in
"git fetch-pack" has been optimized by taking advantage of the
commit graph when available.
* Remind developers that the userdiff patterns should be kept simple
and permissive, assuming that the contents they apply are always
syntactically correct.
* The current implementation of GIT_TEST_FAIL_PREREQS is broken in
that checking for the lack of a prerequisite would not work. Avoid
the use of "if ! test_have_prereq X" in a test script.
* The revision traversal API has been optimized by taking advantage
of the commit-graph, when available, to determine if a commit is
reachable from any of the existing refs.
* "git fetch --quiet" optimization to avoid useless computation of
info that will never be displayed.
* Callers from older advice_config[] based API has been updated to
use the newer advice_if_enabled() and advice_enabled() API.
* Teach "test_pause" and "debug" helpers to allow using the HOME and
TERM environment variables the user usually uses.
* "make INSTALL_STRIP=-s install" allows the installation step to use
"install -s" to strip the binaries as they get installed.
* Code that handles large number of refs in the "git fetch" code
path has been optimized.
* The reachability bitmap file used to be generated only for a single
pack, but now we've learned to generate bitmaps for history that
span across multiple packfiles.
* The code to make "git grep" recurse into submodules has been
updated to migrate away from the "add submodule's object store as
an alternate object store" mechanism (which is suboptimal).
* The tracing of process ancestry information has been enhanced.
* Reduce number of write(2) system calls while sending the
ref advertisement.
* Update the build procedure to use the "-pedantic" build when
DEVELOPER makefile macro is in effect.
* Large part of "git submodule add" gets rewritten in C.
* The run-command API has been updated so that the callers can easily
ask the file descriptors open for packfiles to be closed immediately
before spawning commands that may trigger auto-gc.
* An oddball OPTION_ARGUMENT feature has been removed from the
parse-options API.
* The mergesort implementation used to sort linked list has been
optimized.
* Remove external declaration of functions that no longer exist.
* "git multi-pack-index write --bitmap" learns to propagate the
hashcache from original bitmap to resulting bitmap.
* CI learns to run the leak sanitizer builds.
* "git grep --recurse-submodules" takes trees and blobs from the
submodule repository, but the textconv settings when processing a
blob from the submodule is not taken from the submodule repository.
A test is added to demonstrate the issue, without fixing it.
* Teach "git help -c" into helping the command line completion of
configuration variables.
* When "git cmd -h" shows more than one line of usage text (e.g.
the cmd subcommand may take sub-sub-command), parse-options API
learned to align these lines, even across i18n/l10n.
* Prevent "make sparse" from running for the source files that
haven't been modified.
* The code path to write a new version of .midx multi-pack index files
has learned to release the mmaped memory holding the current
version of .midx before removing them from the disk, as some
platforms do not allow removal of a file that still has mapping.
* A new feature has been added to abort early in the test framework.
Fixes since v2.33
-----------------
* Input validation of "git pack-objects --stdin-packs" has been
corrected.
* Bugfix for common ancestor negotiation recently introduced in "git
push" code path.
* "git pull" had various corner cases that were not well thought out
around its --rebase backend, e.g. "git pull --ff-only" did not stop
but went ahead and rebased when the history on other side is not a
descendant of our history. The series tries to fix them up.
* "git apply" miscounted the bytes and failed to read to the end of
binary hunks.
* "git range-diff" code clean-up.
* "git commit --fixup" now works with "--edit" again, after it was
broken in v2.32.
* Use upload-artifacts v1 (instead of v2) for 32-bit linux, as the
new version has a blocker bug for that architecture.
* Checking out all the paths from HEAD during the last conflicted
step in "git rebase" and continuing would cause the step to be
skipped (which is expected), but leaves MERGE_MSG file behind in
$GIT_DIR and confuses the next "git commit", which has been
corrected.
* Various bugs in "git rebase -r" have been fixed.
* mmap() imitation used to call xmalloc() that dies upon malloc()
failure, which has been corrected to just return an error to the
caller to be handled.
* "git diff --relative" segfaulted and/or produced incorrect result
when there are unmerged paths.
* The delayed checkout code path in "git checkout" etc. were chatty
even when --quiet and/or --no-progress options were given.
* "git branch -D <branch>" used to refuse to remove a broken branch
ref that points at a missing commit, which has been corrected.
* Build update for Apple clang.
* The parser for the "--nl" option of "git column" has been
corrected.
* "git upload-pack" which runs on the other side of "git fetch"
forgot to take the ref namespaces into account when handling
want-ref requests.
* The sparse-index support can corrupt the index structure by storing
a stale and/or uninitialized data, which has been corrected.
* Buggy tests could damage repositories outside the throw-away test
area we created. We now by default export GIT_CEILING_DIRECTORIES
to limit the damage from such a stray test.
* Even when running "git send-email" without its own threaded
discussion support, a threading related header in one message is
carried over to the subsequent message to result in an unwanted
threading, which has been corrected.
* The output from "git fast-export", when its anonymization feature
is in use, showed an annotated tag incorrectly.
* Recent "diff -m" changes broke "gitk", which has been corrected.
* The "git apply -3" code path learned not to bother the lower level
merge machinery when the three-way merge can be trivially resolved
without the content level merge. This fixes a regression caused by
recent "-3way first and fall back to direct application" change.
* The code that optionally creates the *.rev reverse index file has
been optimized to avoid needless computation when it is not writing
the file out.
* "git range-diff -I... <range> <range>" segfaulted, which has been
corrected.
* The order in which various files that make up a single (conceptual)
packfile has been reevaluated and straightened up. This matters in
correctness, as an incomplete set of files must not be shown to a
running Git.
* The "mode" word is useless in a call to open(2) that does not
create a new file. Such a call in the files backend of the ref
subsystem has been cleaned up.
* "git update-ref --stdin" failed to flush its output as needed,
which potentially led the conversation to a deadlock.
* When "git am --abort" fails to abort correctly, it still exited
with exit status of 0, which has been corrected.
* Correct nr and alloc members of strvec struct to be of type size_t.
* "git stash", where the tentative change involves changing a
directory to a file (or vice versa), was confused, which has been
corrected.
* "git clone" from a repository whose HEAD is unborn into a bare
repository didn't follow the branch name the other side used, which
is corrected.
* "git cvsserver" had a long-standing bug in its authentication code,
which has finally been corrected (it is unclear and is a separate
question if anybody is seriously using it, though).
* "git difftool --dir-diff" mishandled symbolic links.
* Sensitive data in the HTTP trace were supposed to be redacted, but
we failed to do so in HTTP/2 requests.
* "make clean" has been updated to remove leftover .depend/
directories, even when it is not told to use them to compute header
dependencies.
* Protocol v0 clients can get stuck parsing a malformed feature line.
* A few kinds of changes "git status" can show were not documented.
(merge d2a534c515 ja/doc-status-types-and-copies later to maint).
* The mergesort implementation used to sort linked list has been
optimized.
(merge c90cfc225b rs/mergesort later to maint).
* An editor session launched during a Git operation (e.g. during 'git
commit') can leave the terminal in a funny state. The code path
has updated to save the terminal state before, and restore it
after, it spawns an editor.
(merge 3d411afabc cm/save-restore-terminal later to maint).
* "git cat-file --batch" with the "--batch-all-objects" option is
supposed to iterate over all the objects found in a repository, but
it used to translate these object names using the replace mechanism,
which defeats the point of enumerating all objects in the repository.
This has been corrected.
(merge bf972896d7 jk/cat-file-batch-all-wo-replace later to maint).
* Recent sparse-index work broke safety against attempts to add paths
with trailing slashes to the index, which has been corrected.
(merge c8ad9d04c6 rs/make-verify-path-really-verify-again later to maint).
* The "--color-lines" and "--color-by-age" options of "git blame"
have been missing, which are now documented.
(merge 8c32856133 bs/doc-blame-color-lines later to maint).
* The PATH used in CI job may be too wide and let incompatible dlls
to be grabbed, which can cause the build&test to fail. Tighten it.
(merge 7491ef6198 js/windows-ci-path-fix later to maint).
* Avoid performance measurements from getting ruined by gc and other
housekeeping pauses interfering in the middle.
(merge be79131a53 rs/disable-gc-during-perf-tests later to maint).
* Stop "git add --dry-run" from creating new blob and tree objects.
(merge e578d0311d rs/add-dry-run-without-objects later to maint).
* "git commit" gave duplicated error message when the object store
was unwritable, which has been corrected.
(merge 4ef91a2d79 ab/fix-commit-error-message-upon-unwritable-object-store later to maint).
* Recent sparse-index addition, namely any use of index_name_pos(),
can expand sparse index entries and breaks any code that walks
cache-tree or existing index entries. One such instance of such a
breakage has been corrected.
* The xxdiff difftool backend can exit with status 128, which the
difftool-helper that launches the backend takes as a significant
failure, when it is not significant at all. Work it around.
(merge 571f4348dd da/mergetools-special-case-xxdiff-exit-128 later to maint).
* Improve test framework around unwritable directories.
(merge 5d22e18965 ab/test-cleanly-recreate-trash-directory later to maint).
* "git push" client talking to an HTTP server did not diagnose the
lack of the final status report from the other side correctly,
which has been corrected.
(merge c5c3486f38 jk/http-push-status-fix later to maint).
* Update "git archive" documentation and give explicit mention on the
compression level for both zip and tar.gz format.
(merge c4b208c309 bs/archive-doc-compression-level later to maint).
* Drop "git sparse-checkout" from the list of common commands.
(merge 6a9a50a8af sg/sparse-index-not-that-common-a-command later to maint).
* "git branch -c/-m new old" was not described to copy config, which
has been corrected.
(merge 8252ec300e jc/branch-copy-doc later to maint).
* Squelch over-eager warning message added during this cycle.
* Fix long-standing shell syntax error in the completion script.
(merge 46b0585286 re/completion-fix-test-equality later to maint).
* Teach "git commit-graph" command not to allow using replace objects
at all, as we do not use the commit-graph at runtime when we see
object replacement.
(merge 095d112f8c ab/ignore-replace-while-working-on-commit-graph later to maint).
* "git pull --no-verify" did not affect the underlying "git merge".
(merge 47bfdfb3fd ar/fix-git-pull-no-verify later to maint).
* One CI task based on Fedora image noticed a not-quite-kosher
construct recently, which has been corrected.
* "git pull --ff-only" and "git pull --rebase --ff-only" should make
it a no-op to attempt pulling from a remote that is behind us, but
instead the command errored out by saying it was impossible to
fast-forward, which may technically be true, but not a useful thing
to diagnose as an error. This has been corrected.
(merge 361cb52383 jc/fix-pull-ff-only-when-already-up-to-date later to maint).
* The way Cygwin emulates a unix-domain socket, on top of which the
simple-ipc mechanism is implemented, can race with the program on
the other side that wants to use the socket, and briefly make it
appear as a regular file before lstat(2) starts reporting it as a
socket. We now have a workaround on the side that connects to a
unix domain socket.
* Other code cleanup, docfix, build fix, etc.
(merge f188160be9 ab/bundle-remove-verbose-option later to maint).
(merge 8c6b4332b4 rs/close-pack-leakfix later to maint).
(merge 51b04c05b7 bs/difftool-msg-tweak later to maint).
(merge dd20e4a6db ab/make-compdb-fix later to maint).
(merge 6ffb990dc4 os/status-docfix later to maint).
(merge 100c2da2d3 rs/p3400-lose-tac later to maint).
(merge 76f3b69896 tb/aggregate-ignore-leading-whitespaces later to maint).
(merge 6e4fd8bfcd tz/doc-link-to-bundle-format-fix later to maint).
(merge f6c013dfa1 jc/doc-commit-header-continuation-line later to maint).
(merge ec9a37d69b ab/pkt-line-cleanup later to maint).
(merge 8650c6298c ab/fix-make-lint-docs later to maint).
(merge 1c720357ce ab/test-lib-diff-cleanup later to maint).
(merge 6b615dbece ks/submodule-add-message-fix later to maint).
(merge 203eb8381a jc/doc-format-patch-clarify-auto-base later to maint).
(merge 559664c792 ab/test-lib later to maint).

View File

@ -377,7 +377,7 @@ notes for details).
on that order.
* "git show 'HEAD:Foo[BAR]Baz'" did not interpret the argument as a
rev, i.e. the object named by the pathname with wildcard
rev, i.e. the object named by the the pathname with wildcard
characters in a tree object.
(merge aac4fac nd/dwim-wildcards-as-pathspecs later to maint).

View File

@ -74,9 +74,10 @@ the feature triggers the new behavior when it should, and to show the
feature does not trigger when it shouldn't. After any code change, make
sure that the entire test suite passes.
Pushing to a fork of https://github.com/git/git will use their CI
integration to test your changes on Linux, Mac and Windows. See the
<<GHCI,GitHub CI>> section for details.
If you have an account at GitHub (and you can get one for free to work
on open source projects), you can use their Travis CI integration to
test your changes on Linux, Mac (and hopefully soon Windows). See
GitHub-Travis CI hints section for details.
Do not forget to update the documentation to describe the updated
behavior and make sure that the resulting documentation set formats
@ -166,85 +167,6 @@ or, on an older version of Git without support for --pretty=reference:
git show -s --date=short --pretty='format:%h (%s, %ad)' <commit>
....
[[sign-off]]
=== Certify your work by adding your `Signed-off-by` trailer
To improve tracking of who did what, we ask you to certify that you
wrote the patch or have the right to pass it on under the same license
as ours, by "signing off" your patch. Without sign-off, we cannot
accept your patches.
If (and only if) you certify the below D-C-O:
[[dco]]
.Developer's Certificate of Origin 1.1
____
By making a contribution to this project, I certify that:
a. The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
b. The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
c. The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
d. I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
____
you add a "Signed-off-by" trailer to your commit, that looks like
this:
....
Signed-off-by: Random J Developer <random@developer.example.org>
....
This line can be added by Git if you run the git-commit command with
the -s option.
Notice that you can place your own `Signed-off-by` trailer when
forwarding somebody else's patch with the above rules for
D-C-O. Indeed you are encouraged to do so. Do not forget to
place an in-body "From: " line at the beginning to properly attribute
the change to its true author (see (2) above).
This procedure originally came from the Linux kernel project, so our
rule is quite similar to theirs, but what exactly it means to sign-off
your patch differs from project to project, so it may be different
from that of the project you are accustomed to.
[[real-name]]
Also notice that a real name is used in the `Signed-off-by` trailer. Please
don't hide your real name.
[[commit-trailers]]
If you like, you can put extra tags at the end:
. `Reported-by:` is used to credit someone who found the bug that
the patch attempts to fix.
. `Acked-by:` says that the person who is more familiar with the area
the patch attempts to modify liked the patch.
. `Reviewed-by:`, unlike the other tags, can only be offered by the
reviewers themselves when they are completely satisfied with the
patch after a detailed analysis.
. `Tested-by:` is used to indicate that the person applied the patch
and found it to have the desired effect.
You can also create your own tag or use one that's in common usage
such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:".
[[git-tools]]
=== Generate your patch using Git tools out of your commits.
@ -380,6 +302,86 @@ Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and
`Tested-by:` lines as necessary to credit people who helped your
patch, and "cc:" them when sending such a final version for inclusion.
[[sign-off]]
=== Certify your work by adding your `Signed-off-by` trailer
To improve tracking of who did what, we ask you to certify that you
wrote the patch or have the right to pass it on under the same license
as ours, by "signing off" your patch. Without sign-off, we cannot
accept your patches.
If (and only if) you certify the below D-C-O:
[[dco]]
.Developer's Certificate of Origin 1.1
____
By making a contribution to this project, I certify that:
a. The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
b. The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
c. The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
d. I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
____
you add a "Signed-off-by" trailer to your commit, that looks like
this:
....
Signed-off-by: Random J Developer <random@developer.example.org>
....
This line can be added by Git if you run the git-commit command with
the -s option.
Notice that you can place your own `Signed-off-by` trailer when
forwarding somebody else's patch with the above rules for
D-C-O. Indeed you are encouraged to do so. Do not forget to
place an in-body "From: " line at the beginning to properly attribute
the change to its true author (see (2) above).
This procedure originally came from the Linux kernel project, so our
rule is quite similar to theirs, but what exactly it means to sign-off
your patch differs from project to project, so it may be different
from that of the project you are accustomed to.
[[real-name]]
Also notice that a real name is used in the `Signed-off-by` trailer. Please
don't hide your real name.
[[commit-trailers]]
If you like, you can put extra tags at the end:
. `Reported-by:` is used to credit someone who found the bug that
the patch attempts to fix.
. `Acked-by:` says that the person who is more familiar with the area
the patch attempts to modify liked the patch.
. `Reviewed-by:`, unlike the other tags, can only be offered by the
reviewer and means that she is completely satisfied that the patch
is ready for application. It is usually offered only after a
detailed review.
. `Tested-by:` is used to indicate that the person applied the patch
and found it to have the desired effect.
You can also create your own tag or use one that's in common usage
such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:".
== Subsystems with dedicated maintainers
Some parts of the system have dedicated maintainers with their own
@ -448,12 +450,13 @@ their trees themselves.
entitled "What's cooking in git.git" and "What's in git.git" giving
the status of various proposed changes.
== GitHub CI[[GHCI]]]
[[travis]]
== GitHub-Travis CI hints
With an account at GitHub, you can use GitHub CI to test your changes
on Linux, Mac and Windows. See
https://github.com/git/git/actions/workflows/main.yml for examples of
recent CI runs.
With an account at GitHub (you can get one for free to work on open
source projects), you can use Travis CI to test your changes on Linux,
Mac (and hopefully soon Windows). You can find a successful example
test build here: https://travis-ci.org/git/git/builds/120473209
Follow these steps for the initial setup:
@ -461,18 +464,31 @@ Follow these steps for the initial setup:
You can find detailed instructions how to fork here:
https://help.github.com/articles/fork-a-repo/
After the initial setup, CI will run whenever you push new changes
. Open the Travis CI website: https://travis-ci.org
. Press the "Sign in with GitHub" button.
. Grant Travis CI permissions to access your GitHub account.
You can find more information about the required permissions here:
https://docs.travis-ci.com/user/github-oauth-scopes
. Open your Travis CI profile page: https://travis-ci.org/profile
. Enable Travis CI builds for your Git fork.
After the initial setup, Travis CI will run whenever you push new changes
to your fork of Git on GitHub. You can monitor the test state of all your
branches here: https://github.com/<Your GitHub handle>/git/actions/workflows/main.yml
branches here: https://travis-ci.org/__<Your GitHub handle>__/git/branches
If a branch did not pass all test cases then it is marked with a red
cross. In that case you can click on the failing job and navigate to
"ci/run-build-and-tests.sh" and/or "ci/print-test-failures.sh". You
can also download "Artifacts" which are tarred (or zipped) archives
with test data relevant for debugging.
cross. In that case you can click on the failing Travis CI job and
scroll all the way down in the log. Find the line "<-- Click here to see
detailed test output!" and click on the triangle next to the log line
number to expand the detailed test output. Here is such a failing
example: https://travis-ci.org/git/git/jobs/122676187
Then fix the problem and push your fix to your GitHub fork. This will
trigger a new CI build to ensure all tests pass.
Fix the problem and push your fix to your Git fork. This will trigger
a new Travis CI build to ensure all tests pass.
[[mua]]
== MUA specific hints

View File

@ -136,16 +136,5 @@ take effect.
option. An empty file name, `""`, will clear the list of revs from
previously processed files.
--color-lines::
Color line annotations in the default format differently if they come from
the same commit as the preceding line. This makes it easier to distinguish
code blocks introduced by different commits. The color defaults to cyan and
can be adjusted using the `color.blame.repeatedLines` config option.
--color-by-age::
Color line annotations depending on the age of the line in the default format.
The `color.blame.highlightRecent` config option controls what color is used for
each range of age.
-h::
Show help message.

View File

@ -298,15 +298,6 @@ pathname::
tilde expansion happens to such a string: `~/`
is expanded to the value of `$HOME`, and `~user/` to the
specified user's home directory.
+
If a path starts with `%(prefix)/`, the remainder is interpreted as a
path relative to Git's "runtime prefix", i.e. relative to the location
where Git itself was installed. For example, `%(prefix)/bin/` refers to
the directory in which the Git executable itself lives. If Git was
compiled without runtime prefix support, the compiled-in prefix will be
substituted instead. In the unlikely event that a literal path needs to
be specified that should _not_ be expanded, it needs to be prefixed by
`./`, like so: `./%(prefix)/bin`.
Variables
@ -449,6 +440,8 @@ include::config/rerere.txt[]
include::config/reset.txt[]
include::config/safe.txt[]
include::config/sendemail.txt[]
include::config/sequencer.txt[]

View File

@ -44,9 +44,6 @@ advice.*::
Shown when linkgit:git-push[1] rejects a forced update of
a branch when its remote-tracking ref has updates that we
do not have locally.
skippedCherryPicks::
Shown when linkgit:git-rebase[1] skips a commit that has already
been cherry-picked onto the upstream branch.
statusAheadBehind::
Shown when linkgit:git-status[1] computes the ahead/behind
counts for a local ref compared to its remote tracking ref,

View File

@ -27,7 +27,7 @@ blame.ignoreRevsFile::
file names will reset the list of ignored revisions. This option will
be handled before the command line option `--ignore-revs-file`.
blame.markUnblamableLines::
blame.markUnblamables::
Mark lines that were changed by an ignored revision that we could not
attribute to another commit with a '*' in the output of
linkgit:git-blame[1].

View File

@ -85,6 +85,10 @@ When `merges` (or just 'm'), pass the `--rebase-merges` option to 'git rebase'
so that the local merge commits are included in the rebase (see
linkgit:git-rebase[1] for details).
+
When `preserve` (or just 'p', deprecated in favor of `merges`), also pass
`--preserve-merges` along to 'git rebase' so that locally committed merge
commits will not be flattened by running 'git pull'.
+
When the value is `interactive` (or just 'i'), the rebase is run in interactive
mode.
+

View File

@ -9,27 +9,26 @@ color.advice.hint::
Use customized color for hints.
color.blame.highlightRecent::
Specify the line annotation color for `git blame --color-by-age`
depending upon the age of the line.
This can be used to color the metadata of a blame line depending
on age of the line.
+
This setting should be set to a comma-separated list of color and
date settings, starting and ending with a color, the dates should be
set from oldest to newest. The metadata will be colored with the
specified colors if the line was introduced before the given
timestamp, overwriting older timestamped colors.
This setting should be set to a comma-separated list of color and date settings,
starting and ending with a color, the dates should be set from oldest to newest.
The metadata will be colored given the colors if the line was introduced
before the given timestamp, overwriting older timestamped colors.
+
Instead of an absolute timestamp relative timestamps work as well,
e.g. `2.weeks.ago` is valid to address anything older than 2 weeks.
Instead of an absolute timestamp relative timestamps work as well, e.g.
2.weeks.ago is valid to address anything older than 2 weeks.
+
It defaults to `blue,12 month ago,white,1 month ago,red`, which
colors everything older than one year blue, recent changes between
one month and one year old are kept white, and lines introduced
within the last month are colored red.
It defaults to 'blue,12 month ago,white,1 month ago,red', which colors
everything older than one year blue, recent changes between one month and
one year old are kept white, and lines introduced within the last month are
colored red.
color.blame.repeatedLines::
Use the specified color to colorize line annotations for
`git blame --color-lines`, if they come from the same commit as the
preceding line. Defaults to cyan.
Use the customized color for the part of git-blame output that
is repeated meta information per line (such as commit id,
author name, date and timezone). Defaults to cyan.
color.branch::
A boolean to enable/disable color in the output of
@ -105,12 +104,9 @@ color.grep.<slot>::
`matchContext`;;
matching text in context lines
`matchSelected`;;
matching text in selected lines. Also, used to customize the following
linkgit:git-log[1] subcommands: `--grep`, `--author` and `--committer`.
matching text in selected lines
`selected`;;
non-matching text in selected lines. Also, used to customize the
following linkgit:git-log[1] subcommands: `--grep`, `--author` and
`--committer`.
non-matching text in selected lines
`separator`;;
separators between fields on a line (`:`, `-`, and `=`)
and between hunks (`--`)
@ -131,9 +127,8 @@ color.interactive.<slot>::
interactive commands.
color.pager::
A boolean to specify whether `auto` color modes should colorize
output going to the pager. Defaults to true; set this to false
if your pager does not understand ANSI color codes.
A boolean to enable/disable colored output when the pager is in
use (default is true).
color.push::
A boolean to enable/disable color in push errors. May be set to

View File

@ -118,10 +118,9 @@ diff.orderFile::
relative to the top of the working tree.
diff.renameLimit::
The number of files to consider in the exhaustive portion of
copy/rename detection; equivalent to the 'git diff' option
`-l`. If not set, the default value is currently 1000. This
setting has no effect if rename detection is turned off.
The number of files to consider when performing the copy/rename
detection; equivalent to the 'git diff' option `-l`. This setting
has no effect if rename detection is turned off.
diff.renames::
Whether and how Git detects renames. If set to "false",

View File

@ -69,8 +69,7 @@ fetch.negotiationAlgorithm::
setting defaults to "skipping".
Unknown values will cause 'git fetch' to error out.
+
See also the `--negotiate-only` and `--negotiation-tip` options to
linkgit:git-fetch[1].
See also the `--negotiation-tip` option for linkgit:git-fetch[1].
fetch.showForcedUpdates::
Set to false to enable `--no-show-forced-updates` in

View File

@ -11,13 +11,13 @@ gpg.program::
gpg.format::
Specifies which key format to use when signing with `--gpg-sign`.
Default is "openpgp". Other possible values are "x509", "ssh".
Default is "openpgp" and another possible value is "x509".
gpg.<format>.program::
Use this to customize the program used for the signing format you
chose. (see `gpg.program` and `gpg.format`) `gpg.program` can still
be used as a legacy synonym for `gpg.openpgp.program`. The default
value for `gpg.x509.program` is "gpgsm" and `gpg.ssh.program` is "ssh-keygen".
value for `gpg.x509.program` is "gpgsm".
gpg.minTrustLevel::
Specifies a minimum trust level for signature verification. If
@ -33,42 +33,3 @@ gpg.minTrustLevel::
* `marginal`
* `fully`
* `ultimate`
gpg.ssh.defaultKeyCommand:
This command that will be run when user.signingkey is not set and a ssh
signature is requested. On successful exit a valid ssh public key is
expected in the first line of its output. To automatically use the first
available key from your ssh-agent set this to "ssh-add -L".
gpg.ssh.allowedSignersFile::
A file containing ssh public keys which you are willing to trust.
The file consists of one or more lines of principals followed by an ssh
public key.
e.g.: user1@example.com,user2@example.com ssh-rsa AAAAX1...
See ssh-keygen(1) "ALLOWED SIGNERS" for details.
The principal is only used to identify the key and is available when
verifying a signature.
+
SSH has no concept of trust levels like gpg does. To be able to differentiate
between valid signatures and trusted signatures the trust level of a signature
verification is set to `fully` when the public key is present in the allowedSignersFile.
Otherwise the trust level is `undefined` and git verify-commit/tag will fail.
+
This file can be set to a location outside of the repository and every developer
maintains their own trust store. A central repository server could generate this
file automatically from ssh keys with push access to verify the code against.
In a corporate setting this file is probably generated at a global location
from automation that already handles developer ssh keys.
+
A repository that only allows signed commits can store the file
in the repository itself using a path relative to the top-level of the working tree.
This way only committers with an already valid key can add or change keys in the keyring.
+
Using a SSH CA key with the cert-authority option
(see ssh-keygen(1) "CERTIFICATES") is also valid.
gpg.ssh.revocationFile::
Either a SSH KRL or a list of revoked public keys (without the principal prefix).
See ssh-keygen(1) for details.
If a public key is found in this file then it will always be treated
as having trust level "never" and signatures will show as invalid.

View File

@ -11,7 +11,7 @@ gui.displayUntracked::
in the file list. The default is "true".
gui.encoding::
Specifies the default character encoding to use for displaying of
Specifies the default encoding to use for displaying of
file contents in linkgit:git-gui[1] and linkgit:gitk[1].
It can be overridden by setting the 'encoding' attribute
for relevant files (see linkgit:gitattributes[5]).

View File

@ -9,15 +9,13 @@ help.format::
help.autoCorrect::
If git detects typos and can identify exactly one valid command similar
to the error, git will try to suggest the correct command or even
run the suggestion automatically. Possible config values are:
- 0 (default): show the suggested command.
- positive number: run the suggested command after specified
deciseconds (0.1 sec).
- "immediate": run the suggested command immediately.
- "prompt": show the suggestion and prompt for confirmation to run
the command.
- "never": don't run or show any suggested command.
to the error, git will automatically run the intended command after
waiting a duration of time defined by this configuration value in
deciseconds (0.1 sec). If this value is 0, the suggested corrections
will be shown, but not executed. If it is a negative integer, or
"immediate", the suggested command
is run immediately. If "never", suggestions are not shown at all. The
default value is zero.
help.htmlPath::
Specify the path where the HTML documentation resides. File system paths

View File

@ -14,7 +14,7 @@ merge.defaultToUpstream::
branches at the remote named by `branch.<current branch>.remote`
are consulted, and then they are mapped via `remote.<remote>.fetch`
to their corresponding remote-tracking branches, and the tips of
these tracking branches are merged. Defaults to true.
these tracking branches are merged.
merge.ff::
By default, Git does not create an extra merge commit when merging
@ -33,12 +33,10 @@ merge.verifySignatures::
include::fmt-merge-msg.txt[]
merge.renameLimit::
The number of files to consider in the exhaustive portion of
rename detection during a merge. If not specified, defaults
to the value of diff.renameLimit. If neither
merge.renameLimit nor diff.renameLimit are specified,
currently defaults to 7000. This setting has no effect if
rename detection is turned off.
The number of files to consider when performing rename detection
during a merge; if not specified, defaults to the value of
diff.renameLimit. This setting has no effect if rename detection
is turned off.
merge.renames::
Whether Git detects renames. If set to "false", rename detection

View File

@ -99,23 +99,12 @@ pack.packSizeLimit::
packing to a file when repacking, i.e. the git:// protocol
is unaffected. It can be overridden by the `--max-pack-size`
option of linkgit:git-repack[1]. Reaching this limit results
in the creation of multiple packfiles.
+
Note that this option is rarely useful, and may result in a larger total
on-disk size (because Git will not store deltas between packs), as well
as worse runtime performance (object lookup within multiple packs is
slower than a single pack, and optimizations like reachability bitmaps
cannot cope with multiple packs).
+
If you need to actively run Git using smaller packfiles (e.g., because your
filesystem does not support large files), this option may help. But if
your goal is to transmit a packfile over a medium that supports limited
sizes (e.g., removable media that cannot store the whole repository),
you are likely better off creating a single large packfile and splitting
it using a generic multi-volume archive tool (e.g., Unix `split`).
+
The minimum size allowed is limited to 1 MiB. The default is unlimited.
Common unit suffixes of 'k', 'm', or 'g' are supported.
in the creation of multiple packfiles; which in turn prevents
bitmaps from being created.
The minimum size allowed is limited to 1 MiB.
The default is unlimited.
Common unit suffixes of 'k', 'm', or 'g' are
supported.
pack.useBitmaps::
When true, git will use pack bitmaps (if available) when packing
@ -159,10 +148,6 @@ pack.writeBitmapHashCache::
between an older, bitmapped pack and objects that have been
pushed since the last gc). The downside is that it consumes 4
bytes per object of disk space. Defaults to true.
+
When writing a multi-pack reachability bitmap, no new namehashes are
computed; instead, any namehashes stored in an existing bitmap are
permuted into their appropriate location when writing a new bitmap.
pack.writeReverseIndex::
When true, git will write a corresponding .rev file (see:

View File

@ -18,6 +18,10 @@ When `merges` (or just 'm'), pass the `--rebase-merges` option to 'git rebase'
so that the local merge commits are included in the rebase (see
linkgit:git-rebase[1] for details).
+
When `preserve` (or just 'p', deprecated in favor of `merges`), also pass
`--preserve-merges` along to 'git rebase' so that locally committed merge
commits will not be flattened by running 'git pull'.
+
When the value is `interactive` (or just 'i'), the rebase is run in interactive
mode.
+

View File

@ -24,14 +24,15 @@ push.default::
* `tracking` - This is a deprecated synonym for `upstream`.
* `simple` - pushes the current branch with the same name on the remote.
* `simple` - in centralized workflow, work like `upstream` with an
added safety to refuse to push if the upstream branch's name is
different from the local one.
+
If you are working on a centralized workflow (pushing to the same repository you
pull from, which is typically `origin`), then you need to configure an upstream
branch with the same name.
When pushing to a remote that is different from the remote you normally
pull from, work as `current`. This is the safest option and is suited
for beginners.
+
This mode is the default since Git 2.0, and is the safest option suited for
beginners.
This mode has become the default in Git 2.0.
* `matching` - push all branches having the same name on both ends.
This makes the repository you are pushing to remember the set of

View File

@ -0,0 +1,42 @@
safe.directory::
These config entries specify Git-tracked directories that are
considered safe even if they are owned by someone other than the
current user. By default, Git will refuse to even parse a Git
config of a repository owned by someone else, let alone run its
hooks, and this config setting allows users to specify exceptions,
e.g. for intentionally shared repositories (see the `--shared`
option in linkgit:git-init[1]).
+
This is a multi-valued setting, i.e. you can add more than one directory
via `git config --add`. To reset the list of safe directories (e.g. to
override any such directories specified in the system config), add a
`safe.directory` entry with an empty value.
+
This config setting is only respected when specified in a system or global
config, not when it is specified in a repository config or via the command
line option `-c safe.directory=<path>`.
+
The value of this setting is interpolated, i.e. `~/<path>` expands to a
path relative to the home directory and `%(prefix)/<path>` expands to a
path relative to Git's (runtime) prefix.
+
To completely opt-out of this security check, set `safe.directory` to the
string `*`. This will allow all repositories to be treated as if their
directory was listed in the `safe.directory` list. If `safe.directory=*`
is set in system config and you want to re-enable this protection, then
initialize your list with an empty value before listing the repositories
that you deem safe.
+
As explained, Git only allows you to access repositories owned by
yourself, i.e. the user who is running Git, by default. When Git
is running as 'root' in a non Windows platform that provides sudo,
however, git checks the SUDO_UID environment variable that sudo creates
and will allow access to the uid recorded as its value in addition to
the id from 'root'.
This is to make it easy to perform a common sequence during installation
"make && sudo make install". A git process running under 'sudo' runs as
'root' but the 'sudo' command exports the environment variable to record
which id the original user has.
If that is not what you would prefer and want git to only trust
repositories that are owned by root instead, then you can remove
the `SUDO_UID` variable from root's environment before invoking git.

View File

@ -8,6 +8,9 @@ sendemail.smtpEncryption::
See linkgit:git-send-email[1] for description. Note that this
setting is not subject to the 'identity' mechanism.
sendemail.smtpssl (deprecated)::
Deprecated alias for 'sendemail.smtpEncryption = ssl'.
sendemail.smtpsslcertpath::
Path to ca-certificates (either a directory or a single file).
Set it to an empty string to disable certificate verification.

View File

@ -58,9 +58,8 @@ submodule.active::
commands. See linkgit:gitsubmodules[7] for details.
submodule.recurse::
A boolean indicating if commands should enable the `--recurse-submodules`
option by default.
Applies to all commands that support this option
Specifies if commands recurse into submodules by default. This
applies to all commands that have a `--recurse-submodules` option
(`checkout`, `fetch`, `grep`, `pull`, `push`, `read-tree`, `reset`,
`restore` and `switch`) except `clone` and `ls-files`.
Defaults to false.

View File

@ -52,17 +52,13 @@ If you have multiple hideRefs values, later entries override earlier ones
(and entries in more-specific config files override less-specific ones).
+
If a namespace is in use, the namespace prefix is stripped from each
reference before it is matched against `transfer.hiderefs` patterns. In
order to match refs before stripping, add a `^` in front of the ref name. If
you combine `!` and `^`, `!` must be specified first.
+
reference before it is matched against `transfer.hiderefs` patterns.
For example, if `refs/heads/master` is specified in `transfer.hideRefs` and
the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master`
is omitted from the advertisements. If `uploadpack.allowRefInWant` is set,
`upload-pack` will treat `want-ref refs/heads/master` in a protocol v2
`fetch` command as if `refs/namespaces/foo/refs/heads/master` did not exist.
`receive-pack`, on the other hand, will still advertise the object id the
ref is pointing to without mentioning its name (a so-called ".have" line).
is omitted from the advertisements but `refs/heads/master` and
`refs/namespaces/bar/refs/heads/master` are still advertised as so-called
"have" lines. In order to match refs before stripping, add a `^` in front of
the ref name. If you combine `!` and `^`, `!` must be specified first.
+
Even if you hide refs, a client may still be able to steal the target
objects via the techniques described in the "SECURITY" section of the

View File

@ -36,10 +36,3 @@ user.signingKey::
commit, you can override the default selection with this variable.
This option is passed unchanged to gpg's --local-user parameter,
so you may specify a key using any method that gpg supports.
If gpg.format is set to "ssh" this can contain the literal ssh public
key (e.g.: "ssh-rsa XXXXXX identifier") or a file which contains it and
corresponds to the private key used for signing. The private key
needs to be available via ssh-agent. Alternatively it can be set to
a file containing a private key directly. If not set git will call
gpg.ssh.defaultKeyCommand (e.g.: "ssh-add -L") and try to use the first
key available.

View File

@ -59,7 +59,7 @@ Possible status letters are:
- D: deletion of a file
- M: modification of the contents or mode of a file
- R: renaming of a file
- T: change in the type of the file (regular file, symbolic link or submodule)
- T: change in the type of the file
- U: file is unmerged (you must complete the merge before it can
be committed)
- X: "unknown" change type (most probably a bug, please report it)

View File

@ -588,17 +588,11 @@ When used together with `-B`, omit also the preimage in the deletion part
of a delete/create pair.
-l<num>::
The `-M` and `-C` options involve some preliminary steps that
can detect subsets of renames/copies cheaply, followed by an
exhaustive fallback portion that compares all remaining
unpaired destinations to all relevant sources. (For renames,
only remaining unpaired sources are relevant; for copies, all
original sources are relevant.) For N sources and
destinations, this exhaustive check is O(N^2). This option
prevents the exhaustive portion of rename/copy detection from
running if the number of source/destination files involved
exceeds the specified number. Defaults to diff.renameLimit.
Note that a value of 0 is treated as unlimited.
The `-M` and `-C` options require O(n^2) processing time where n
is the number of potential rename/copy targets. This
option prevents rename/copy detection from running if
the number of rename/copy targets exceeds the specified
number.
ifndef::git-format-patch[]
--diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]::

View File

@ -62,17 +62,8 @@ The argument to this option may be a glob on ref names, a ref, or the (possibly
abbreviated) SHA-1 of a commit. Specifying a glob is equivalent to specifying
this option multiple times, one for each matching ref name.
+
See also the `fetch.negotiationAlgorithm` and `push.negotiate`
configuration variables documented in linkgit:git-config[1], and the
`--negotiate-only` option below.
--negotiate-only::
Do not fetch anything from the server, and instead print the
ancestors of the provided `--negotiation-tip=*` arguments,
which we have in common with the server.
+
Internally this is used to implement the `push.negotiate` option, see
linkgit:git-config[1].
See also the `fetch.negotiationAlgorithm` configuration variable
documented in linkgit:git-config[1].
--dry-run::
Show what would be done, without making any changes.

View File

@ -9,7 +9,7 @@ SYNOPSIS
--------
[verse]
'git add' [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p]
[--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]] [--sparse]
[--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]]
[--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--renormalize]
[--chmod=(+|-)x] [--pathspec-from-file=<file> [--pathspec-file-nul]]
[--] [<pathspec>...]
@ -79,13 +79,6 @@ in linkgit:gitglossary[7].
--force::
Allow adding otherwise ignored files.
--sparse::
Allow updating index entries outside of the sparse-checkout cone.
Normally, `git add` refuses to update index entries whose paths do
not fit within the sparse-checkout cone, since those files might
be removed from the working tree without warning. See
linkgit:git-sparse-checkout[1] for more details.
-i::
--interactive::
Add modified contents in the working tree interactively to

View File

@ -178,8 +178,6 @@ default. You can use `--no-utf8` to override this.
--abort::
Restore the original branch and abort the patching operation.
Revert contents of files involved in the am operation to their
pre-am state.
--quit::
Abort the patching operation but keep HEAD and the index

View File

@ -93,19 +93,12 @@ BACKEND EXTRA OPTIONS
zip
~~~
-<digit>::
Specify compression level. Larger values allow the command
to spend more time to compress to smaller size. Supported
values are from `-0` (store-only) to `-9` (best ratio).
Default is `-6` if not given.
-0::
Store the files instead of deflating them.
-9::
Highest and slowest compression level. You can specify any
number from 1 to 9 to adjust compression speed and ratio.
tar
~~~
-<number>::
Specify compression level. The value will be passed to the
compression command configured in `tar.<format>.command`. See
manual page of the configured command for the list of supported
levels and the default level if this option isn't specified.
CONFIGURATION
-------------

View File

@ -11,8 +11,8 @@ SYNOPSIS
'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental]
[-L <range>] [-S <revs-file>] [-M] [-C] [-C] [-C] [--since=<date>]
[--ignore-rev <rev>] [--ignore-revs-file <file>]
[--color-lines] [--color-by-age] [--progress] [--abbrev=<n>]
[<rev> | --contents <file> | --reverse <rev>..<rev>] [--] <file>
[--progress] [--abbrev=<n>] [<rev> | --contents <file> | --reverse <rev>..<rev>]
[--] <file>
DESCRIPTION
-----------
@ -93,19 +93,6 @@ include::blame-options.txt[]
is used for a caret to mark the boundary commit.
THE DEFAULT FORMAT
------------------
When neither `--porcelain` nor `--incremental` option is specified,
`git blame` will output annotation for each line with:
- abbreviated object name for the commit the line came from;
- author ident (by default author name and date, unless `-s` or `-e`
is specified); and
- line number
before the line contents.
THE PORCELAIN FORMAT
--------------------

View File

@ -118,21 +118,20 @@ OPTIONS
Reset <branchname> to <startpoint>, even if <branchname> exists
already. Without `-f`, 'git branch' refuses to change an existing branch.
In combination with `-d` (or `--delete`), allow deleting the
branch irrespective of its merged status, or whether it even
points to a valid commit. In combination with
branch irrespective of its merged status. In combination with
`-m` (or `--move`), allow renaming the branch even if the new
branch name already exists, the same applies for `-c` (or `--copy`).
-m::
--move::
Move/rename a branch, together with its config and reflog.
Move/rename a branch and the corresponding reflog.
-M::
Shortcut for `--move --force`.
-c::
--copy::
Copy a branch, together with its config and reflog.
Copy a branch and the corresponding reflog.
-C::
Shortcut for `--copy --force`.

View File

@ -40,8 +40,8 @@ OPTIONS
-------
-o <path>::
--output-directory <path>::
Place the resulting bug report file in `<path>` instead of the current
directory.
Place the resulting bug report file in `<path>` instead of the root of
the Git repository.
-s <format>::
--suffix <format>::

View File

@ -13,53 +13,26 @@ SYNOPSIS
[--version=<version>] <file> <git-rev-list-args>
'git bundle' verify [-q | --quiet] <file>
'git bundle' list-heads <file> [<refname>...]
'git bundle' unbundle [--progress] <file> [<refname>...]
'git bundle' unbundle <file> [<refname>...]
DESCRIPTION
-----------
Create, unpack, and manipulate "bundle" files. Bundles are used for
the "offline" transfer of Git objects without an active "server"
sitting on the other side of the network connection.
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.
They can be used to create both incremental and full backups of a
repository, and to relay the state of the references in one repository
to another.
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).
Git commands that fetch or otherwise "read" via protocols such as
`ssh://` and `https://` can also operate on bundle files. It is
possible linkgit:git-clone[1] a new repository from a bundle, to use
linkgit:git-fetch[1] to fetch from one, and to list the references
contained within it with linkgit:git-ls-remote[1]. There's no
corresponding "write" support, i.e.a 'git push' into a bundle is not
supported.
See the "EXAMPLES" section below for examples of how to use bundles.
BUNDLE FORMAT
-------------
Bundles are `.pack` files (see linkgit:git-pack-objects[1]) with a
header indicating what references are contained within the bundle.
Like the the packed archive format itself bundles can either be
self-contained, or be created using exclusions.
See the "OBJECT PREREQUISITES" section below.
Bundles created using revision exclusions are "thin packs" created
using the `--thin` option to linkgit:git-pack-objects[1], and
unbundled using the `--fix-thin` option to linkgit:git-index-pack[1].
There is no option to create a "thick pack" when using revision
exclusions, and users should not be concerned about the difference. By
using "thin packs", bundles created using exclusions are smaller in
size. That they're "thin" under the hood is merely noted here as a
curiosity, and as a reference to other documentation.
See link:technical/bundle-format.html[the `bundle-format`
documentation] for more details and the discussion of "thin pack" in
link:technical/pack-format.html[the pack format documentation] for
further details.
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
destination repository.
OPTIONS
-------
@ -144,88 +117,28 @@ unbundle <file>::
SPECIFYING REFERENCES
---------------------
Revisions must be accompanied by reference names to be packaged in a
bundle.
More than one reference may be packaged, and more than one set of prerequisite objects can
be specified. The objects packaged are those not contained in the
union of the prerequisites.
The 'git bundle create' command resolves the reference names for you
using the same rules as `git rev-parse --abbrev-ref=loose`. Each
prerequisite can be specified explicitly (e.g. `^master~10`), or implicitly
(e.g. `master~10..master`, `--since=10.days.ago master`).
All of these simple cases are OK (assuming we have a "master" and
"next" branch):
----------------
$ git bundle create master.bundle master
$ echo master | git bundle create master.bundle --stdin
$ git bundle create master-and-next.bundle master next
$ (echo master; echo next) | git bundle create master-and-next.bundle --stdin
----------------
And so are these (and the same but omitted `--stdin` examples):
----------------
$ git bundle create recent-master.bundle master~10..master
$ git bundle create recent-updates.bundle master~10..master next~5..next
----------------
A revision name or a range whose right-hand-side cannot be resolved to
a reference is not accepted:
----------------
$ git bundle create HEAD.bundle $(git rev-parse HEAD)
fatal: Refusing to create empty bundle.
$ git bundle create master-yesterday.bundle master~10..master~5
fatal: Refusing to create empty bundle.
----------------
OBJECT PREREQUISITES
--------------------
When creating bundles it is possible to create a self-contained bundle
that can be unbundled in a repository with no common history, as well
as providing negative revisions to exclude objects needed in the
earlier parts of the history.
Feeding a revision such as `new` to `git bundle create` will create a
bundle file that contains all the objects reachable from the revision
`new`. That bundle can be unbundled in any repository to obtain a full
history that leads to the revision `new`:
----------------
$ git bundle create full.bundle new
----------------
A revision range such as `old..new` will produce a bundle file that
will require the revision `old` (and any objects reachable from it)
to exist for the bundle to be "unbundle"-able:
----------------
$ git bundle create full.bundle old..new
----------------
A self-contained bundle without any prerequisites can be extracted
into anywhere, even into an empty repository, or be cloned from
(i.e., `new`, but not `old..new`).
'git bundle' will only package references that are shown by
'git show-ref': this includes heads, tags, and remote heads. References
such as `master~1` cannot be packaged, but are perfectly suitable for
defining the basis. More than one reference may be packaged, and more
than one basis can be specified. The objects packaged are those not
contained in the union of the given bases. Each basis can be
specified explicitly (e.g. `^master~10`), or implicitly (e.g.
`master~10..master`, `--since=10.days.ago master`).
It is very important that the basis used be held by the destination.
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>`.
The 'git bundle verify' command can be used to check whether your
recipient repository has the required prerequisite commits for a
bundle.
EXAMPLES
--------
@ -236,7 +149,7 @@ but we can move data from A to B via some mechanism (CD, email, etc.).
We want to update R2 with development made on the branch master in R1.
To bootstrap the process, you can first create a bundle that does not have
any prerequisites. You can use a tag to remember up to what commit you last
any basis. You can use a tag to remember up to what commit you last
processed, in order to make it easy to later update the other repository
with an incremental bundle:
@ -287,7 +200,7 @@ machineB$ git pull
If you know up to what commit the intended recipient repository should
have the necessary objects, you can use that knowledge to specify the
prerequisites, giving a cut-off point to limit the revisions and objects that go
basis, giving a cut-off point to limit the revisions and objects that go
in the resulting bundle. The previous example used the lastR2bundle tag
for this purpose, but you can use any other options that you would give to
the linkgit:git-log[1] command. Here are more examples:
@ -298,7 +211,7 @@ You can use a tag that is present in both:
$ git bundle create mybundle v1.0.0..master
----------------
You can use a prerequisite based on time:
You can use a basis based on time:
----------------
$ git bundle create mybundle --since=10.days master
@ -311,7 +224,7 @@ $ git bundle create mybundle -10 master
----------------
You can run `git-bundle verify` to see if you can extract from a bundle
that was created with a prerequisite:
that was created with a basis:
----------------
$ git bundle verify mybundle

View File

@ -94,10 +94,8 @@ OPTIONS
Instead of reading a list of objects on stdin, perform the
requested batch operation on all objects in the repository and
any alternate object stores (not just reachable objects).
Requires `--batch` or `--batch-check` be specified. By default,
the objects are visited in order sorted by their hashes; see
also `--unordered` below. Objects are presented as-is, without
respecting the "replace" mechanism of linkgit:git-replace[1].
Requires `--batch` or `--batch-check` be specified. Note that
the objects are visited in order sorted by their hashes.
--buffer::
Normally batch output is flushed after each object is output, so

View File

@ -118,9 +118,8 @@ OPTIONS
-f::
--force::
When switching branches, proceed even if the index or the
working tree differs from `HEAD`, and even if there are untracked
files in the way. This is used to throw away local changes and
any untracked files or directories that are in the way.
working tree differs from `HEAD`. This is used to throw away
local changes.
+
When checking out paths from the index, do not fail upon unmerged
entries; instead, unmerged entries are ignored.

View File

@ -39,7 +39,7 @@ OPTIONS
--indent=<string>::
String to be printed at the beginning of each line.
--nl=<string>::
--nl=<N>::
String to be printed at the end of each line,
including newline character.

View File

@ -72,7 +72,7 @@ OPTIONS
-p::
--patch::
Use the interactive patch selection interface to choose
Use the interactive patch selection interface to chose
which changes to commit. See linkgit:git-add[1] for
details.
@ -212,9 +212,8 @@ include::signoff-option.txt[]
each trailer would appear, and other details.
-n::
--[no-]verify::
By default, the pre-commit and commit-msg hooks are run.
When any of `--no-verify` or `-n` is given, these are bypassed.
--no-verify::
This option bypasses the pre-commit and commit-msg hooks.
See also linkgit:githooks[5].
--allow-empty::

View File

@ -71,10 +71,6 @@ codes are:
On success, the command returns the exit code 0.
A list of all available configuration variables can be obtained using the
`git help --config` command.
[[OPTIONS]]
OPTIONS
-------
@ -147,13 +143,7 @@ See also <<FILES>>.
-f config-file::
--file config-file::
For writing options: write to the specified file rather than the
repository `.git/config`.
+
For reading options: read only from the specified file rather than from all
available files.
+
See also <<FILES>>.
Use the given config file instead of the one specified by GIT_CONFIG.
--blob blob::
Similar to `--file` but use the given blob instead of a file. E.g.
@ -335,14 +325,21 @@ All writing options will per default write to the repository specific
configuration file. Note that this also affects options like `--replace-all`
and `--unset`. *'git config' will only ever change one file at a time*.
You can override these rules using the `--global`, `--system`,
`--local`, `--worktree`, and `--file` command-line options; see
<<OPTIONS>> above.
You can override these rules either by command-line options or by environment
variables. The `--global`, `--system` and `--worktree` options will limit
the file used to the global, system-wide or per-worktree file respectively.
The `GIT_CONFIG` environment variable has a similar effect, but you
can specify any filename you want.
ENVIRONMENT
-----------
GIT_CONFIG::
Take the configuration from the given file instead of .git/config.
Using the "--global" option forces this to ~/.gitconfig. Using the
"--system" option forces this to $(prefix)/etc/gitconfig.
GIT_CONFIG_GLOBAL::
GIT_CONFIG_SYSTEM::
Take the configuration from the given files instead from global or
@ -370,12 +367,6 @@ This is useful for cases where you want to spawn multiple git commands
with a common configuration but cannot depend on a configuration file,
for example when writing scripts.
GIT_CONFIG::
If no `--file` option is provided to `git config`, use the file
given by `GIT_CONFIG` as if it were provided via `--file`. This
variable has no effect on other Git commands, and is mostly for
historical compatibility; there is generally no reason to use it
instead of the `--file` option.
[[EXAMPLES]]
EXAMPLES

View File

@ -99,7 +99,7 @@ looks like
------
Only anonymous access is provided by pserver by default. To commit you
Only anonymous access is provided by pserve by default. To commit you
will have to create pserver accounts, simply add a gitcvs.authdb
setting in the config file of the repositories you want the cvsserver
to allow writes to, for example:
@ -114,20 +114,21 @@ The format of these files is username followed by the encrypted password,
for example:
------
myuser:sqkNi8zPf01HI
myuser:$1$9K7FzU28$VfF6EoPYCJEYcVQwATgOP/
myuser:$5$.NqmNH1vwfzGpV8B$znZIcumu1tNLATgV2l6e1/mY8RzhUDHMOaVOeL1cxV3
myuser:$1Oyx5r9mdGZ2
myuser:$1$BA)@$vbnMJMDym7tA32AamXrm./
------
You can use the 'htpasswd' facility that comes with Apache to make these
files, but only with the -d option (or -B if your system suports it).
files, but Apache's MD5 crypt method differs from the one used by most C
library's crypt() function, so don't use the -m option.
Preferably use the system specific utility that manages password hash
creation in your platform (e.g. mkpasswd in Linux, encrypt in OpenBSD or
pwhash in NetBSD) and paste it in the right location.
Alternatively you can produce the password with perl's crypt() operator:
-----
perl -e 'my ($user, $pass) = @ARGV; printf "%s:%s\n", $user, crypt($user, $pass)' $USER password
-----
Then provide your password via the pserver method, for example:
------
cvs -d:pserver:someuser:somepassword@server:/path/repo.git co <HEAD_name>
cvs -d:pserver:someuser:somepassword <at> server/path/repo.git co <HEAD_name>
------
No special setup is needed for SSH access, other than having Git tools
in the PATH. If you have clients that do not accept the CVS_SERVER
@ -137,7 +138,7 @@ Note: Newer CVS versions (>= 1.12.11) also support specifying
CVS_SERVER directly in CVSROOT like
------
cvs -d ":ext;CVS_SERVER=git cvsserver:user@server/path/repo.git" co <HEAD_name>
cvs -d ":ext;CVS_SERVER=git cvsserver:user@server/path/repo.git" co <HEAD_name>
------
This has the advantage that it will be saved in your 'CVS/Root' files and
you don't need to worry about always setting the correct environment
@ -185,8 +186,8 @@ allowing access over SSH.
+
--
------
export CVSROOT=:ext:user@server:/var/git/project.git
export CVS_SERVER="git cvsserver"
export CVSROOT=:ext:user@server:/var/git/project.git
export CVS_SERVER="git cvsserver"
------
--
4. For SSH clients that will make commits, make sure their server-side
@ -202,7 +203,7 @@ allowing access over SSH.
`project-master` directory:
+
------
cvs co -d project-master master
cvs co -d project-master master
------
[[dbbackend]]

View File

@ -63,10 +63,9 @@ OPTIONS
Automatically implies --tags.
--abbrev=<n>::
Instead of using the default number of hexadecimal digits (which
will vary according to the number of objects in the repository with
a default of 7) of the abbreviated object name, use <n> digits, or
as many digits as needed to form a unique object name. An <n> of 0
Instead of using the default 7 hexadecimal digits as the
abbreviated object name, use <n> digits, or as many digits
as needed to form a unique object name. An <n> of 0
will suppress long format, only showing the closest tag.
--candidates=<n>::
@ -140,11 +139,8 @@ at the end.
The number of additional commits is the number
of commits which would be displayed by "git log v1.0.4..parent".
The hash suffix is "-g" + an unambigous abbreviation for the tip commit
of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`). The
length of the abbreviation scales as the repository grows, using the
approximate number of objects in the repository and a bit of math
around the birthday paradox, and defaults to a minimum of 7.
The hash suffix is "-g" + unambiguous abbreviation for the tip commit
of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`).
The "g" prefix stands for "git" and is used to allow describing the version of
a software depending on the SCM the software is managed with. This is useful
in an environment where people may use different SCMs.

View File

@ -51,20 +51,16 @@ files on disk.
--staged is a synonym of --cached.
+
If --merge-base is given, instead of using <commit>, use the merge base
of <commit> and HEAD. `git diff --cached --merge-base A` is equivalent to
`git diff --cached $(git merge-base A HEAD)`.
of <commit> and HEAD. `git diff --merge-base A` is equivalent to
`git diff $(git merge-base A HEAD)`.
'git diff' [<options>] [--merge-base] <commit> [--] [<path>...]::
'git diff' [<options>] <commit> [--] [<path>...]::
This form is to view the changes you have in your
working tree relative to the named <commit>. You can
use HEAD to compare it with the latest commit, or a
branch name to compare with the tip of a different
branch.
+
If --merge-base is given, instead of using <commit>, use the merge base
of <commit> and HEAD. `git diff --merge-base A` is equivalent to
`git diff $(git merge-base A HEAD)`.
'git diff' [<options>] [--merge-base] <commit> <commit> [--] [<path>...]::

View File

@ -133,7 +133,7 @@ remember to run that, set `fetch.prune` globally, or
linkgit:git-config[1].
Here's where things get tricky and more specific. The pruning feature
doesn't actually care about branches, instead it'll prune local <-->
doesn't actually care about branches, instead it'll prune local <->
remote-references as a function of the refspec of the remote (see
`<refspec>` and <<CRTB,CONFIGURED REMOTE-TRACKING BRANCHES>> above).

View File

@ -235,15 +235,6 @@ and `date` to extract the named component. For email fields (`authoremail`,
without angle brackets, and `:localpart` to get the part before the `@` symbol
out of the trimmed email.
The raw data in an object is `raw`.
raw:size::
The raw data size of the object.
Note that `--format=%(raw)` can not be used with `--python`, `--shell`, `--tcl`,
because such language may not support arbitrary binary data in their string
variable type.
The message in a commit or a tag object is `contents`, from which
`contents:<part>` can be used to extract various parts out of:

View File

@ -689,10 +689,10 @@ You can also use `git format-patch --base=P -3 C` to generate patches
for A, B and C, and the identifiers for P, X, Y, Z are appended at the
end of the first message.
If set `--base=auto` in cmdline, it will automatically compute
the base commit as the merge base of tip commit of the remote-tracking
If set `--base=auto` in cmdline, it will track base commit automatically,
the base commit will be the merge base of tip commit of the remote-tracking
branch and revision-range specified in cmdline.
For a local branch, you need to make it to track a remote branch by `git branch
For a local branch, you need to track a remote branch by `git branch
--set-upstream-to` before using this option.
EXAMPLES

View File

@ -8,10 +8,8 @@ git-help - Display help information about Git
SYNOPSIS
--------
[verse]
'git help' [-a|--all [--[no-]verbose]]
[[-i|--info] [-m|--man] [-w|--web]] [COMMAND|GUIDE]
'git help' [-g|--guides]
'git help' [-c|--config]
'git help' [-a|--all [--[no-]verbose]] [-g|--guides]
[-i|--info|-m|--man|-w|--web] [COMMAND|GUIDE]
DESCRIPTION
-----------
@ -60,7 +58,8 @@ OPTIONS
-g::
--guides::
Prints a list of the Git concept guides on the standard output.
Prints a list of the Git concept guides on the standard output. This
option overrides any given command or guide name.
-i::
--info::

View File

@ -16,9 +16,7 @@ A simple CGI program to serve the contents of a Git repository to Git
clients accessing the repository over http:// and https:// protocols.
The program supports clients fetching using both the smart HTTP protocol
and the backwards-compatible dumb HTTP protocol, as well as clients
pushing using the smart HTTP protocol. It also supports Git's
more-efficient "v2" protocol if properly configured; see the
discussion of `GIT_PROTOCOL` in the ENVIRONMENT section below.
pushing using the smart HTTP protocol.
It verifies that the directory has the magic file
"git-daemon-export-ok", and it will refuse to export any Git directory
@ -79,18 +77,6 @@ Apache 2.x::
SetEnv GIT_PROJECT_ROOT /var/www/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
# This is not strictly necessary using Apache and a modern version of
# git-http-backend, as the webserver will pass along the header in the
# environment as HTTP_GIT_PROTOCOL, and http-backend will copy that into
# GIT_PROTOCOL. But you may need this line (or something similar if you
# are using a different webserver), or if you want to support older Git
# versions that did not do that copying.
#
# Having the webserver set up GIT_PROTOCOL is perfectly fine even with
# modern versions (and will take precedence over HTTP_GIT_PROTOCOL,
# which means it can be used to override the client's request).
SetEnvIf Git-Protocol ".*" GIT_PROTOCOL=$0
----------------------------------------------------------------
+
To enable anonymous read access but authenticated write access,
@ -278,16 +264,6 @@ a repository with an extremely large number of refs. The value can be
specified with a unit (e.g., `100M` for 100 megabytes). The default is
10 megabytes.
Clients may probe for optional protocol capabilities (like the v2
protocol) using the `Git-Protocol` HTTP header. In order to support
these, the contents of that header must appear in the `GIT_PROTOCOL`
environment variable. Most webservers will pass this header to the CGI
via the `HTTP_GIT_PROTOCOL` variable, and `git-http-backend` will
automatically copy that to `GIT_PROTOCOL`. However, some webservers may
be more selective about which headers they'll pass, in which case they
need to be configured explicitly (see the mention of `Git-Protocol` in
the Apache config from the earlier EXAMPLES section).
The backend process sets GIT_COMMITTER_NAME to '$REMOTE_USER' and
GIT_COMMITTER_EMAIL to '$\{REMOTE_USER}@http.$\{REMOTE_ADDR\}',
ensuring that any reflogs created by 'git-receive-pack' contain some

View File

@ -82,12 +82,6 @@ OPTIONS
--strict::
Die, if the pack contains broken objects or links.
--progress-title::
For internal use only.
+
Set the title of the progress bar. The title is "Receiving objects" by
default and "Indexing objects" when `--stdin` is specified.
--check-self-contained-and-connected::
Die if the pack contains broken links. For internal use only.

View File

@ -39,9 +39,7 @@ OPTIONS
full ref name (including prefix) will be printed. If 'auto' is
specified, then if the output is going to a terminal, the ref names
are shown as if 'short' were given, otherwise no ref names are
shown. The option `--decorate` is short-hand for `--decorate=short`.
Default to configuration value of `log.decorate` if configured,
otherwise, `auto`.
shown. The default option is 'short'.
--decorate-refs=<pattern>::
--decorate-refs-exclude=<pattern>::

View File

@ -179,17 +179,6 @@ OPTIONS
`maintenance.<task>.enabled` configured as `true` are considered.
See the 'TASKS' section for the list of accepted `<task>` values.
--scheduler=auto|crontab|systemd-timer|launchctl|schtasks::
When combined with the `start` subcommand, specify the scheduler
for running the hourly, daily and weekly executions of
`git maintenance run`.
Possible values for `<scheduler>` are `auto`, `crontab`
(POSIX), `systemd-timer` (Linux), `launchctl` (macOS), and
`schtasks` (Windows). When `auto` is specified, the
appropriate platform-specific scheduler is used; on Linux,
`systemd-timer` is used if available, otherwise
`crontab`. Default is `auto`.
TROUBLESHOOTING
---------------
@ -288,52 +277,6 @@ schedule to ensure you are executing the correct binaries in your
schedule.
BACKGROUND MAINTENANCE ON LINUX SYSTEMD SYSTEMS
-----------------------------------------------
While Linux supports `cron`, depending on the distribution, `cron` may
be an optional package not necessarily installed. On modern Linux
distributions, systemd timers are superseding it.
If user systemd timers are available, they will be used as a replacement
of `cron`.
In this case, `git maintenance start` will create user systemd timer units
and start the timers. The current list of user-scheduled tasks can be found
by running `systemctl --user list-timers`. The timers written by `git
maintenance start` are similar to this:
-----------------------------------------------------------------------
$ systemctl --user list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Thu 2021-04-29 19:00:00 CEST 42min left Thu 2021-04-29 18:00:11 CEST 17min ago git-maintenance@hourly.timer git-maintenance@hourly.service
Fri 2021-04-30 00:00:00 CEST 5h 42min left Thu 2021-04-29 00:00:11 CEST 18h ago git-maintenance@daily.timer git-maintenance@daily.service
Mon 2021-05-03 00:00:00 CEST 3 days left Mon 2021-04-26 00:00:11 CEST 3 days ago git-maintenance@weekly.timer git-maintenance@weekly.service
-----------------------------------------------------------------------
One timer is registered for each `--schedule=<frequency>` option.
The definition of the systemd units can be inspected in the following files:
-----------------------------------------------------------------------
~/.config/systemd/user/git-maintenance@.timer
~/.config/systemd/user/git-maintenance@.service
~/.config/systemd/user/timers.target.wants/git-maintenance@hourly.timer
~/.config/systemd/user/timers.target.wants/git-maintenance@daily.timer
~/.config/systemd/user/timers.target.wants/git-maintenance@weekly.timer
-----------------------------------------------------------------------
`git maintenance start` will overwrite these files and start the timer
again with `systemctl --user`, so any customization should be done by
creating a drop-in file, i.e. a `.conf` suffixed file in the
`~/.config/systemd/user/git-maintenance@.service.d` directory.
`git maintenance stop` will stop the user systemd timers and delete
the above mentioned files.
For more details, see `systemd.timer(5)`.
BACKGROUND MAINTENANCE ON MACOS SYSTEMS
---------------------------------------

View File

@ -61,8 +61,6 @@ merge has resulted in conflicts.
OPTIONS
-------
:git-merge: 1
include::merge-options.txt[]
-m <msg>::

View File

@ -9,7 +9,8 @@ git-multi-pack-index - Write and verify multi-pack-indexes
SYNOPSIS
--------
[verse]
'git multi-pack-index' [--object-dir=<dir>] [--[no-]bitmap] <sub-command>
'git multi-pack-index' [--object-dir=<dir>] [--[no-]progress]
[--preferred-pack=<pack>] <subcommand>
DESCRIPTION
-----------
@ -22,13 +23,10 @@ OPTIONS
Use given directory for the location of Git objects. We check
`<dir>/packs/multi-pack-index` for the current MIDX file, and
`<dir>/packs` for the pack-files to index.
+
`<dir>` must be an alternate of the current repository.
--[no-]progress::
Turn progress on/off explicitly. If neither is specified, progress is
shown if standard error is connected to a terminal. Supported by
sub-commands `write`, `verify`, `expire`, and `repack.
shown if standard error is connected to a terminal.
The following subcommands are available:
@ -39,31 +37,9 @@ write::
--
--preferred-pack=<pack>::
Optionally specify the tie-breaking pack used when
multiple packs contain the same object. `<pack>` must
contain at least one object. If not given, ties are
broken in favor of the pack with the lowest mtime.
--[no-]bitmap::
Control whether or not a multi-pack bitmap is written.
--stdin-packs::
Write a multi-pack index containing only the set of
line-delimited pack index basenames provided over stdin.
--refs-snapshot=<path>::
With `--bitmap`, optionally specify a file which
contains a "refs snapshot" taken prior to repacking.
+
A reference snapshot is composed of line-delimited OIDs corresponding to
the reference tips, usually taken by `git repack` prior to generating a
new pack. A line may optionally start with a `+` character to indicate
that the reference which corresponds to that OID is "preferred" (see
linkgit:git-config[1]'s `pack.preferBitmapTips`.)
+
The file given at `<path>` is expected to be readable, and can contain
duplicates. (If a given OID is given more than once, it is marked as
preferred if at least one instance of it begins with the special `+`
marker).
multiple packs contain the same object. If not given,
ties are broken in favor of the pack with the lowest
mtime.
--
verify::
@ -99,26 +75,19 @@ associated `.keep` file will not be selected for the batch to repack.
EXAMPLES
--------
* Write a MIDX file for the packfiles in the current `.git` directory.
* Write a MIDX file for the packfiles in the current .git folder.
+
-----------------------------------------------
$ git multi-pack-index write
-----------------------------------------------
* Write a MIDX file for the packfiles in the current `.git` directory with a
corresponding bitmap.
+
-------------------------------------------------------------
$ git multi-pack-index write --preferred-pack=<pack> --bitmap
-------------------------------------------------------------
* Write a MIDX file for the packfiles in an alternate object store.
+
-----------------------------------------------
$ git multi-pack-index --object-dir <alt> write
-----------------------------------------------
* Verify the MIDX file for the packfiles in the current `.git` directory.
* Verify the MIDX file for the packfiles in the current .git folder.
+
-----------------------------------------------
$ git multi-pack-index verify

View File

@ -128,10 +128,10 @@ depth is 4095.
into multiple independent packfiles, each not larger than the
given size. The size can be suffixed with
"k", "m", or "g". The minimum size allowed is limited to 1 MiB.
This option
prevents the creation of a bitmap index.
The default is unlimited, unless the config variable
`pack.packSizeLimit` is set. Note that this option may result in
a larger and slower repository; see the discussion in
`pack.packSizeLimit`.
`pack.packSizeLimit` is set.
--honor-pack-keep::
This flag causes an object already in a local pack that

View File

@ -15,17 +15,14 @@ SYNOPSIS
DESCRIPTION
-----------
Incorporates changes from a remote repository into the current branch.
If the current branch is behind the remote, then by default it will
fast-forward the current branch to match the remote. If the current
branch and the remote have diverged, the user needs to specify how to
reconcile the divergent branches with `--rebase` or `--no-rebase` (or
the corresponding configuration option in `pull.rebase`).
Incorporates changes from a remote repository into the current
branch. In its default mode, `git pull` is shorthand for
`git fetch` followed by `git merge FETCH_HEAD`.
More precisely, `git pull` runs `git fetch` with the given parameters
and then depending on configuration options or command line flags,
will call either `git rebase` or `git merge` to reconcile diverging
branches.
More precisely, 'git pull' runs 'git fetch' with the given
parameters and calls 'git merge' to merge the retrieved branch
heads into the current branch.
With `--rebase`, it runs 'git rebase' instead of 'git merge'.
<repository> should be the name of a remote repository as
passed to linkgit:git-fetch[1]. <refspec> can name an
@ -105,7 +102,7 @@ Options related to merging
include::merge-options.txt[]
-r::
--rebase[=false|true|merges|interactive]::
--rebase[=false|true|merges|preserve|interactive]::
When true, rebase the current branch on top of the upstream
branch after fetching. If there is a remote-tracking branch
corresponding to the upstream branch and the upstream branch
@ -116,7 +113,11 @@ When set to `merges`, rebase using `git rebase --rebase-merges` so that
the local merge commits are included in the rebase (see
linkgit:git-rebase[1] for details).
+
When false, merge the upstream branch into the current branch.
When set to `preserve` (deprecated in favor of `merges`), rebase with the
`--preserve-merges` option passed to `git rebase` so that locally created
merge commits will not be flattened.
+
When false, merge the current branch into the upstream branch.
+
When `interactive`, enable the interactive mode of rebase.
+
@ -131,7 +132,7 @@ published that history already. Do *not* use this option
unless you have read linkgit:git-rebase[1] carefully.
--no-rebase::
This is shorthand for --rebase=false.
Override earlier --rebase.
Options related to fetching
~~~~~~~~~~~~~~~~~~~~~~~~~~~

View File

@ -244,8 +244,8 @@ Imagine that you have to rebase what you have already published.
You will have to bypass the "must fast-forward" rule in order to
replace the history you originally published with the rebased history.
If somebody else built on top of your original history while you are
rebasing, the tip of the branch at the remote may advance with their
commit, and blindly pushing with `--force` will lose their work.
rebasing, the tip of the branch at the remote may advance with her
commit, and blindly pushing with `--force` will lose her work.
+
This option allows you to say that you expect the history you are
updating is what you rebased and want to replace. If the remote ref

View File

@ -10,7 +10,8 @@ SYNOPSIS
--------
[verse]
'git read-tree' [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>]
[-u | -i]] [--index-output=<file>] [--no-sparse-checkout]
[-u [--exclude-per-directory=<gitignore>] | -i]]
[--index-output=<file>] [--no-sparse-checkout]
(--empty | <tree-ish1> [<tree-ish2> [<tree-ish3>]])
@ -38,9 +39,8 @@ OPTIONS
--reset::
Same as -m, except that unmerged entries are discarded instead
of failing. When used with `-u`, updates leading to loss of
working tree changes or untracked files or directories will not
abort the operation.
of failing. When used with `-u`, updates leading to loss of
working tree changes will not abort the operation.
-u::
After a successful merge, update the files in the work
@ -88,6 +88,21 @@ OPTIONS
The command will refuse to overwrite entries that already
existed in the original index file.
--exclude-per-directory=<gitignore>::
When running the command with `-u` and `-m` options, the
merge result may need to overwrite paths that are not
tracked in the current branch. The command usually
refuses to proceed with the merge to avoid losing such a
path. However this safety valve sometimes gets in the
way. For example, it often happens that the other
branch added a file that used to be a generated file in
your branch, and the safety valve triggers when you try
to switch to that branch after you ran `make` but before
running `make clean` to remove the generated file. This
option tells the command to read per-directory exclude
file (usually '.gitignore') and allows such an untracked
but explicitly ignored file to be overwritten.
--index-output=<file>::
Instead of writing the results out to `$GIT_INDEX_FILE`,
write the resulting index in the named file. While the

View File

@ -79,10 +79,9 @@ remain the checked-out branch.
If the upstream branch already contains a change you have made (e.g.,
because you mailed a patch which was applied upstream), then that commit
will be skipped and warnings will be issued (if the `merge` backend is
used). For example, running `git rebase master` on the following
history (in which `A'` and `A` introduce the same set of changes, but
have different committer information):
will be skipped. For example, running `git rebase master` on the
following history (in which `A'` and `A` introduce the same set of changes,
but have different committer information):
------------
A---B---C topic
@ -313,10 +312,7 @@ See also INCOMPATIBLE OPTIONS below.
By default (or if `--no-reapply-cherry-picks` is given), these commits
will be automatically dropped. Because this necessitates reading all
upstream commits, this can be expensive in repos with a large number
of upstream commits that need to be read. When using the `merge`
backend, warnings will be issued for each dropped commit (unless
`--quiet` is given). Advice will also be issued unless
`advice.skippedCherryPicks` is set to false (see linkgit:git-config[1]).
of upstream commits that need to be read.
+
`--reapply-cherry-picks` allows rebase to forgo reading all upstream
commits, potentially improving performance.
@ -344,7 +340,9 @@ See also INCOMPATIBLE OPTIONS below.
-m::
--merge::
Using merging strategies to rebase (default).
Use merging strategies to rebase. When the recursive (default) merge
strategy is used, this allows rebase to be aware of renames on the
upstream side. This is the default.
+
Note that a rebase merge works by replaying each commit from the working
branch on top of the <upstream> branch. Because of this, when a merge
@ -356,8 +354,9 @@ See also INCOMPATIBLE OPTIONS below.
-s <strategy>::
--strategy=<strategy>::
Use the given merge strategy, instead of the default `ort`.
This implies `--merge`.
Use the given merge strategy.
If there is no `-s` option 'git merge-recursive' is used
instead. This implies --merge.
+
Because 'git rebase' replays each commit from the working branch
on top of the <upstream> branch using the given strategy, using
@ -370,7 +369,7 @@ See also INCOMPATIBLE OPTIONS below.
--strategy-option=<strategy-option>::
Pass the <strategy-option> through to the merge strategy.
This implies `--merge` and, if no strategy has been
specified, `-s ort`. Note the reversal of 'ours' and
specified, `-s recursive`. Note the reversal of 'ours' and
'theirs' as noted above for the `-m` option.
+
See also INCOMPATIBLE OPTIONS below.
@ -446,8 +445,7 @@ When --fork-point is active, 'fork_point' will be used instead of
ends up being empty, the <upstream> will be used as a fallback.
+
If <upstream> is given on the command line, then the default is
`--no-fork-point`, otherwise the default is `--fork-point`. See also
`rebase.forkpoint` in linkgit:git-config[1].
`--no-fork-point`, otherwise the default is `--fork-point`.
+
If your branch was based on <upstream> but <upstream> was rewound and
your branch contains commits which were dropped, this option can be used
@ -527,12 +525,29 @@ i.e. commits that would be excluded by linkgit:git-log[1]'s
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 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
`ort` merge strategy; different merge strategies can be used only via
`recursive` merge strategy; Different merge strategies can be used only via
explicit `exec git merge -s <strategy> [...]` commands.
+
See also REBASING MERGES and INCOMPATIBLE OPTIONS below.
-p::
--preserve-merges::
[DEPRECATED: use `--rebase-merges` instead] Recreate merge commits
instead of flattening the history by replaying commits a merge commit
introduces. Merge conflict resolutions or manual amendments to merge
commits are not preserved.
+
This uses the `--interactive` machinery internally, but combining it
with the `--interactive` option explicitly is generally not a good
idea unless you know what you are doing (see BUGS below).
+
See also INCOMPATIBLE OPTIONS below.
-x <cmd>::
--exec <cmd>::
Append "exec <cmd>" after each line creating a commit in the
@ -564,6 +579,9 @@ See also INCOMPATIBLE OPTIONS below.
the root commit(s) on a branch. When used with --onto, it
will skip changes already contained in <newbase> (instead of
<upstream>) whereas without --onto it will operate on every change.
When used together with both --onto and --preserve-merges,
'all' root commits will be rewritten to have <newbase> as parent
instead.
+
See also INCOMPATIBLE OPTIONS below.
@ -625,6 +643,7 @@ are incompatible with the following options:
* --allow-empty-message
* --[no-]autosquash
* --rebase-merges
* --preserve-merges
* --interactive
* --exec
* --no-keep-empty
@ -635,6 +654,13 @@ are incompatible with the following options:
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 --empty=
* --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
* --fork-point and --root
@ -1193,16 +1219,12 @@ successful merge so that the user can edit the message.
If a `merge` command fails for any reason other than merge conflicts (i.e.
when the merge operation did not even start), it is rescheduled immediately.
By default, the `merge` command will use the `ort` merge strategy for
regular merges, and `octopus` for octopus merges. One can specify a
default strategy for all merges using the `--strategy` argument when
invoking rebase, or can override specific merges in the interactive
list of commands by using an `exec` command to call `git merge`
explicitly with a `--strategy` argument. Note that when calling `git
merge` explicitly like this, you can make use of the fact that the
labels are worktree-local refs (the ref `refs/rewritten/onto` would
correspond to the label `onto`, for example) in order to refer to the
branches you want to merge.
At this time, the `merge` command will *always* use the `recursive`
merge strategy for regular merges, and `octopus` for octopus merges,
with no way to choose a different one. To work around
this, an `exec` command can be used to call `git merge` explicitly,
using the fact that the labels are worktree-local refs (the ref
`refs/rewritten/onto` would correspond to the label `onto`, for example).
Note: the first command (`label onto`) labels the revision onto which
the commits are rebased; The name `onto` is just a convention, as a nod
@ -1252,6 +1274,29 @@ CONFIGURATION
include::config/rebase.txt[]
include::config/sequencer.txt[]
BUGS
----
The todo list presented by the deprecated `--preserve-merges --interactive`
does not represent the topology of the revision graph (use `--rebase-merges`
instead). Editing commits and rewording their commit messages should work
fine, but attempts to reorder commits tend to produce counterintuitive results.
Use `--rebase-merges` in such scenarios instead.
For example, an attempt to rearrange
------------
1 --- 2 --- 3 --- 4 --- 5
------------
to
------------
1 --- 2 --- 4 --- 3 --- 5
------------
by moving the "pick 4" line will result in the following history:
------------
3
/
1 --- 2 --- 4 --- 5
------------
GIT
---
Part of the linkgit:git[1] suite

View File

@ -41,11 +41,6 @@ OPTIONS
<directory>::
The repository to sync into.
--http-backend-info-refs::
Used by linkgit:git-http-backend[1] to serve up
`$GIT_URL/info/refs?service=git-receive-pack` requests. See
`--http-backend-info-refs` in linkgit:git-upload-pack[1].
PRE-RECEIVE HOOK
----------------
Before any ref is updated, if $GIT_DIR/hooks/pre-receive file exists

View File

@ -9,7 +9,7 @@ git-repack - Pack unpacked objects in a repository
SYNOPSIS
--------
[verse]
'git repack' [-a] [-A] [-d] [-f] [-F] [-l] [-n] [-q] [-b] [-m] [--window=<n>] [--depth=<n>] [--threads=<n>] [--keep-pack=<pack-name>] [--write-midx]
'git repack' [-a] [-A] [-d] [-f] [-F] [-l] [-n] [-q] [-b] [--window=<n>] [--depth=<n>] [--threads=<n>] [--keep-pack=<pack-name>]
DESCRIPTION
-----------
@ -121,18 +121,15 @@ depth is 4095.
If specified, multiple packfiles may be created, which also
prevents the creation of a bitmap index.
The default is unlimited, unless the config variable
`pack.packSizeLimit` is set. Note that this option may result in
a larger and slower repository; see the discussion in
`pack.packSizeLimit`.
`pack.packSizeLimit` is set.
-b::
--write-bitmap-index::
Write a reachability bitmap index as part of the repack. This
only makes sense when used with `-a`, `-A` or `-m`, as the bitmaps
only makes sense when used with `-a` or `-A`, as the bitmaps
must be able to refer to all reachable objects. This option
overrides the setting of `repack.writeBitmaps`. This option
has no effect if multiple packfiles are created, unless writing a
MIDX (in which case a multi-pack bitmap is created).
overrides the setting of `repack.writeBitmaps`. This option
has no effect if multiple packfiles are created.
--pack-kept-objects::
Include objects in `.keep` files when repacking. Note that we
@ -190,15 +187,6 @@ this "roll-up", without respect to their reachability. This is subject
to change in the future. This option (implying a drastically different
repack mode) is not guaranteed to work with all other combinations of
option to `git repack`.
+
When writing a multi-pack bitmap, `git repack` selects the largest resulting
pack as the preferred pack for object selection by the MIDX (see
linkgit:git-multi-pack-index[1]).
-m::
--write-midx::
Write a multi-pack index (see linkgit:git-multi-pack-index[1])
containing the non-redundant packs.
CONFIGURATION
-------------

View File

@ -69,8 +69,7 @@ linkgit:git-add[1]).
--hard::
Resets the index and working tree. Any changes to tracked files in the
working tree since `<commit>` are discarded. Any untracked files or
directories in the way of writing any tracked files are simply deleted.
working tree since `<commit>` are discarded.
--merge::
Resets the index and updates the files in the working tree that are

View File

@ -72,12 +72,6 @@ For more details, see the 'pathspec' entry in linkgit:gitglossary[7].
--ignore-unmatch::
Exit with a zero status even if no files matched.
--sparse::
Allow updating index entries outside of the sparse-checkout cone.
Normally, `git rm` refuses to update index entries whose paths do
not fit within the sparse-checkout cone. See
linkgit:git-sparse-checkout[1] for more.
-q::
--quiet::
`git rm` normally outputs one line (in the form of an `rm` command)

View File

@ -167,14 +167,6 @@ Sending
`sendemail.envelopeSender` configuration variable; if that is
unspecified, choosing the envelope sender is left to your MTA.
--sendmail-cmd=<command>::
Specify a command to run to send the email. The command should
be sendmail-like; specifically, it must support the `-i` option.
The command will be executed in the shell if necessary. Default
is the value of `sendemail.sendmailcmd`. If unspecified, and if
--smtp-server is also unspecified, git-send-email will search
for `sendmail` in `/usr/sbin`, `/usr/lib` and $PATH.
--smtp-encryption=<encryption>::
Specify the encryption to use, either 'ssl' or 'tls'. Any other
value reverts to plain SMTP. Default is the value of
@ -219,16 +211,13 @@ a password is obtained using 'git-credential'.
--smtp-server=<host>::
If set, specifies the outgoing SMTP server to use (e.g.
`smtp.example.com` or a raw IP address). If unspecified, and if
`--sendmail-cmd` is also unspecified, the default is to search
for `sendmail` in `/usr/sbin`, `/usr/lib` and $PATH if such a
program is available, falling back to `localhost` otherwise.
+
For backward compatibility, this option can also specify a full pathname
of a sendmail-like program instead; the program must support the `-i`
option. This method does not support passing arguments or using plain
command names. For those use cases, consider using `--sendmail-cmd`
instead.
`smtp.example.com` or a raw IP address). Alternatively it can
specify a full pathname of a sendmail-like program instead;
the program must support the `-i` option. Default value can
be specified by the `sendemail.smtpServer` configuration
option; the built-in default is to search for `sendmail` in
`/usr/sbin`, `/usr/lib` and $PATH if such program is
available, falling back to `localhost` otherwise.
--smtp-server-port=<port>::
Specifies a port different from the default port (SMTP

View File

@ -9,10 +9,10 @@ git-send-pack - Push objects over Git protocol to another repository
SYNOPSIS
--------
[verse]
'git send-pack' [--dry-run] [--force] [--receive-pack=<git-receive-pack>]
'git send-pack' [--all] [--dry-run] [--force] [--receive-pack=<git-receive-pack>]
[--verbose] [--thin] [--atomic]
[--[no-]signed|--signed=(true|false|if-asked)]
[<host>:]<directory> (--all | <ref>...)
[<host>:]<directory> [<ref>...]
DESCRIPTION
-----------

View File

@ -210,16 +210,6 @@ 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.
When changing the sparse-checkout patterns in cone mode, Git will inspect each
tracked directory that is not within the sparse-checkout cone to see if it
contains any untracked files. If all of those files are ignored due to the
`.gitignore` patterns, then the directory will be deleted. If any of the
untracked files within that directory is not ignored, then no deletions will
occur within that directory and a warning message will appear. If these files
are important, then reset your sparse-checkout definition so they are included,
use `git add` and `git commit` to store them, then remove any remaining files
manually to ensure Git can behave optimally.
SUBMODULES
----------

View File

@ -207,29 +207,26 @@ show tracked paths:
* ' ' = unmodified
* 'M' = modified
* 'T' = file type changed (regular file, symbolic link or submodule)
* 'A' = added
* 'D' = deleted
* 'R' = renamed
* 'C' = copied (if config option status.renames is set to "copies")
* 'C' = copied
* 'U' = updated but unmerged
....
X Y Meaning
-------------------------------------------------
[AMD] not updated
M [ MTD] updated in index
T [ MTD] type changed in index
A [ MTD] added to index
M [ MD] updated in index
A [ MD] added to index
D deleted from index
R [ MTD] renamed in index
C [ MTD] copied in index
[MTARC] index and work tree matches
[ MTARC] M work tree changed since index
[ MTARC] T type changed in work tree since index
[ MTARC] D deleted in work tree
R renamed in work tree
C copied in work tree
R [ MD] renamed in index
C [ MD] copied in index
[MARC] index and work tree matches
[ MARC] M work tree changed since index
[ MARC] D deleted in work tree
[ D] R renamed in work tree
[ D] C copied in work tree
-------------------------------------------------
D D unmerged, both deleted
A U unmerged, added by us
@ -366,7 +363,7 @@ Field Meaning
Unmerged entries have the following format; the first character is
a "u" to distinguish from ordinary changed entries.
u <XY> <sub> <m1> <m2> <m3> <mW> <h1> <h2> <h3> <path>
u <xy> <sub> <m1> <m2> <m3> <mW> <h1> <h2> <h3> <path>
....
Field Meaning

View File

@ -678,6 +678,7 @@ config key: svn.authorsProg
--strategy=<strategy>::
-p::
--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

View File

@ -36,26 +36,14 @@ OPTIONS
This fits with the HTTP POST request processing model where
a program may read the request, write a response, and must exit.
--http-backend-info-refs::
Used by linkgit:git-http-backend[1] to serve up
`$GIT_URL/info/refs?service=git-upload-pack` requests. See
"Smart Clients" in link:technical/http-protocol.html[the HTTP
transfer protocols] documentation and "HTTP Transport" in
link:technical/protocol-v2.html[the Git Wire Protocol, Version
2] documentation. Also understood by
linkgit:git-receive-pack[1].
--advertise-refs::
Only the initial ref advertisement is output, and the program exits
immediately. This fits with the HTTP GET request model, where
no request content is received but a response must be produced.
<directory>::
The repository to sync from.
ENVIRONMENT
-----------
`GIT_PROTOCOL`::
Internal variable used for handshaking the wire protocol. Server
admins may need to configure some transports to allow this
variable to be passed. See the discussion in linkgit:git[1].
SEE ALSO
--------
linkgit:gitnamespaces[7]

View File

@ -1,28 +0,0 @@
git-version(1)
==============
NAME
----
git-version - Display version information about Git
SYNOPSIS
--------
[verse]
'git version' [--build-options]
DESCRIPTION
-----------
With no options given, the version of 'git' is printed on the standard output.
Note that `git --version` is identical to `git version` because the
former is internally converted into the latter.
OPTIONS
-------
--build-options::
Include additional information about how git was built for diagnostic
purposes.
GIT
---
Part of the linkgit:git[1] suite

View File

@ -9,7 +9,7 @@ git-worktree - Manage multiple working trees
SYNOPSIS
--------
[verse]
'git worktree add' [-f] [--detach] [--checkout] [--lock [--reason <string>]] [-b <new-branch>] <path> [<commit-ish>]
'git worktree add' [-f] [--detach] [--checkout] [--lock] [-b <new-branch>] <path> [<commit-ish>]
'git worktree list' [--porcelain]
'git worktree lock' [--reason <string>] <worktree>
'git worktree move' <worktree> <new-path>
@ -242,7 +242,7 @@ With `list`, annotate missing working trees as prunable if they are
older than `<time>`.
--reason <string>::
With `lock` or with `add --lock`, an explanation why the working tree is locked.
With `lock`, an explanation why the working tree is locked.
<worktree>::
Working trees can be identified by path, either relative or
@ -387,7 +387,7 @@ These annotations are:
------------
$ git worktree list
/path/to/linked-worktree abcd1234 [master]
/path/to/locked-worktree acbd5678 (brancha) locked
/path/to/locked-worktreee acbd5678 (brancha) locked
/path/to/prunable-worktree 5678abc (detached HEAD) prunable
------------

View File

@ -41,10 +41,6 @@ OPTIONS
-------
--version::
Prints the Git suite version that the 'git' program came from.
+
This option is internally converted to `git version ...` and accepts
the same options as the linkgit:git-version[1] command. If `--help` is
also given, it takes precedence over `--version`.
--help::
Prints the synopsis and a list of the most commonly used
@ -867,16 +863,15 @@ for full details.
end user, to be recorded in the body of the reflog.
`GIT_REF_PARANOIA`::
If set to `0`, ignore broken or badly named refs when iterating
over lists of refs. Normally Git will try to include any such
refs, which may cause some operations to fail. This is usually
preferable, as potentially destructive operations (e.g.,
linkgit:git-prune[1]) are better off aborting rather than
ignoring broken refs (and thus considering the history they
point to as not worth saving). The default value is `1` (i.e.,
be paranoid about detecting and aborting all operations). You
should not normally need to set this to `0`, but it may be
useful when trying to salvage data from a corrupted repository.
If set to `1`, include broken or badly named refs when iterating
over lists of refs. In a normal, non-corrupted repository, this
does nothing. However, enabling it may help git to detect and
abort some operations in the presence of broken refs. Git sets
this variable automatically when performing destructive
operations like linkgit:git-prune[1]. You should not need to set
it yourself unless you want to be paranoid about making sure
an operation has touched every ref (e.g., because you are
cloning a repository to make a backup).
`GIT_ALLOW_PROTOCOL`::
If set to a colon-separated list of protocols, behave as if
@ -899,21 +894,6 @@ for full details.
Contains a colon ':' separated list of keys with optional values
'key[=value]'. Presence of unknown keys and values must be
ignored.
+
Note that servers may need to be configured to allow this variable to
pass over some transports. It will be propagated automatically when
accessing local repositories (i.e., `file://` or a filesystem path), as
well as over the `git://` protocol. For git-over-http, it should work
automatically in most configurations, but see the discussion in
linkgit:git-http-backend[1]. For git-over-ssh, the ssh server may need
to be configured to allow clients to pass this variable (e.g., by using
`AcceptEnv GIT_PROTOCOL` with OpenSSH).
+
This configuration is optional. If the variable is not propagated, then
clients will fall back to the original "v0" protocol (but may miss out
on some performance improvements or features). This variable currently
only affects clones and fetches; it is not yet used for pushes (but may
be in the future).
`GIT_OPTIONAL_LOCKS`::
If set to `0`, Git will complete any requested operation without

View File

@ -275,7 +275,7 @@ best to always use a regular merge commit.
[[merge-two-revert-one]]
If I make a change on two branches but revert it on one, why does the merge of those branches include the change?::
By default, when Git does a merge, it uses a strategy called the `ort`
By default, when Git does a merge, it uses a strategy called the recursive
strategy, which does a fancy three-way merge. In such a case, when Git
performs the merge, it considers exactly three points: the two heads and a
third point, called the _merge base_, which is usually the common ancestor of

View File

@ -27,11 +27,12 @@ precedence, the last matching pattern decides the outcome):
them.
* Patterns read from a `.gitignore` file in the same directory
as the path, or in any parent directory (up to the top-level of the working
tree), with patterns in the higher level files being overridden by those in
lower level files down to the directory containing the file. These patterns
match relative to the location of the `.gitignore` file. A project normally
includes such `.gitignore` files in its repository, containing patterns for
as the path, or in any parent directory, with patterns in the
higher level files (up to the toplevel of the work tree) being overridden
by those in lower level files down to the directory containing the file.
These patterns match relative to the location of the
`.gitignore` file. A project normally includes such
`.gitignore` files in its repository, containing patterns for
files generated as part of the project build.
* Patterns read from `$GIT_DIR/info/exclude`.
@ -155,7 +156,7 @@ accessed from the index or a tree versus from the filesystem.
EXAMPLES
--------
- The pattern `hello.*` matches any file or directory
- The pattern `hello.*` matches any file or folder
whose name begins with `hello.`. If one wants to restrict
this only to the directory and not in its subdirectories,
one can prepend the pattern with a slash, i.e. `/hello.*`;

View File

@ -322,7 +322,7 @@ initiating this "pull". If Bob's work conflicts with what Alice did since
their histories forked, Alice will use her working tree and the index to
resolve conflicts, and existing local changes will interfere with the
conflict resolution process (Git will still perform the fetch but will
refuse to merge -- Alice will have to get rid of her local changes in
refuse to merge --- Alice will have to get rid of her local changes in
some way and pull again when this happens).
Alice can peek at what Bob did without merging first, using the "fetch"

View File

@ -547,7 +547,7 @@ like this:
# make the front page an internal rewrite to the gitweb script
RewriteRule ^/$ /cgi-bin/gitweb.cgi [QSA,L,PT]
# look for a public_git directory in unix users' home
# look for a public_git folder in unix users' home
# http://git.example.org/~<user>/
RewriteRule ^/\~([^\/]+)(/|/gitweb.cgi)?$ /cgi-bin/gitweb.cgi \
[QSA,E=GITWEB_PROJECTROOT:/home/$1/public_git/,L,PT]

View File

@ -146,8 +146,8 @@ current branch integrates with) obviously do not work, as there is no
<<def_revision,revision>> and you are "merging" another
<<def_branch,branch>>'s changes that happen to be a descendant of what
you have. In such a case, you do not make a new <<def_merge,merge>>
<<def_commit,commit>> but instead just update your branch to point at the same
revision as the branch you are merging. This will happen frequently on a
<<def_commit,commit>> but instead just update to his
revision. This will happen frequently on a
<<def_remote_tracking_branch,remote-tracking branch>> of a remote
<<def_repository,repository>>.

View File

@ -5,12 +5,11 @@ use warnings;
# Parse arguments, a simple state machine for input like:
#
# <file-to-check.txt> <valid-files-to-link-to> --section=1 git.txt git-add.txt [...] --to-lint git-add.txt a-file.txt [...]
# howto/*.txt config/*.txt --section=1 git.txt git-add.txt [...] --to-lint git-add.txt a-file.txt [...]
my %TXT;
my %SECTION;
my $section;
my $lint_these = 0;
my $to_check = shift @ARGV;
for my $arg (@ARGV) {
if (my ($sec) = $arg =~ /^--section=(\d+)$/s) {
$section = $sec;
@ -31,14 +30,13 @@ sub report {
my ($pos, $line, $target, $msg) = @_;
substr($line, $pos) = "' <-- HERE";
$line =~ s/^\s+//;
print STDERR "$ARGV:$.: error: $target: $msg, shown with 'HERE' below:\n";
print STDERR "$ARGV:$.:\t'$line\n";
print "$ARGV:$.: error: $target: $msg, shown with 'HERE' below:\n";
print "$ARGV:$.:\t'$line\n";
$exit_code = 1;
}
@ARGV = sort values %TXT;
die "BUG: No list of valid linkgit:* files given" unless @ARGV;
@ARGV = $to_check;
die "BUG: Nothing to process!" unless @ARGV;
while (<>) {
my $line = $_;
while ($line =~ m/linkgit:((.*?)\[(\d)\])/g) {

View File

@ -6,7 +6,7 @@ use warnings;
my $exit_code = 0;
sub report {
my ($target, $msg) = @_;
print STDERR "error: $target: $msg\n";
print "error: $target: $msg\n";
$exit_code = 1;
}

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