joe/Githug-Android
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Require native Git runtime and bundle full manpages

Browse Source 
- Remove the app fallback path when native Git is unavailable and show a startup blocker instead
- Fix native level setup for staged file counting and cherry-pick parity
- Improve manpage loading/search and bundle full Git documentation assets
- Integrate Git cross-compilation into AndroidProjectTooling.sh and remove debug AAB support
This commit is contained in:
Joe Tretter
2026-05-08 17:43:46 -05:00
parent 64743ff4a9
commit 4fab442939
219 changed files with 58133 additions and 129 deletions
Download Patch File Download Diff File Expand all files Collapse all files

154
AndroidProjectTooling.sh
View File

@@ -16,6 +16,11 @@ CMDLINE_TOOLS_LATEST_DIR="$CMDLINE_TOOLS_DIR/latest"
WRAPPER_JAR_PATH="$PROJECT_DIR/gradle/wrapper/gradle-wrapper.jar"
LOCAL_PROPERTIES_PATH="$PROJECT_DIR/local.properties"
HOST_GIT_BINARY="$PROJECT_DIR/build/host-git/libgit.so"
GIT_SRC_DIR="$TMP_DIR/git-src"
HOST_GIT_DIR="$PROJECT_DIR/build/host-git"
ANDROID_JNI_DIR="$PROJECT_DIR/app/src/main/jniLibs"
ANDROID_ASSET_MANPAGE_DIR="$PROJECT_DIR/app/src/main/assets/manpages"
ANDROID_API=24
ANDROID_CMDLINE_TOOLS_URL="https://dl.google.com/android/repository/commandlinetools-linux-11076708_latest.zip"
GRADLE_DIST_URL="https://services.gradle.org/distributions/gradle-8.7-bin.zip"
@@ -24,6 +29,7 @@ ANDROID_NDK_PACKAGE="ndk;27.2.12479018"
ANDROID_CMAKE_PACKAGE="cmake;3.22.1"
ANDROID_NDK_DIR="$SDK_DIR/ndk/27.2.12479018"
ANDROID_CMAKE_DIR="$SDK_DIR/cmake/3.22.1"
ANDROID_TOOLBIN="$ANDROID_NDK_DIR/toolchains/llvm/prebuilt/linux-x86_64/bin"
STATE_TTL_SECONDS=86400
log() {
@@ -252,6 +258,128 @@ setup_env() {
export GRADLE_USER_HOME="$GRADLE_USER_HOME_DIR"
}
require_path() {
if [ ! -e "$1" ]; then
echo "Required path not found: $1" >&2
exit 1
fi
}
ensure_git_source() {
mkdir -p "$TMP_DIR"
if [ ! -d "$GIT_SRC_DIR/.git" ]; then
log "Cloning Git source"
git clone --depth 1 https://github.com/git/git.git "$GIT_SRC_DIR"
else
log "Using existing Git source checkout"
fi
}
common_git_make_args() {
printf '%s\n' \
NO_OPENSSL=YesPlease \
NO_CURL=YesPlease \
NO_EXPAT=YesPlease \
NO_GETTEXT=YesPlease \
NO_TCLTK=YesPlease \
NO_PERL=YesPlease \
NO_PYTHON=YesPlease \
NO_INSTALL_HARDLINKS=YesPlease \
NO_ICONV=YesPlease \
NO_REGEX=NeedsStartEnd \
HAVE_ALLOCA_H=YesPlease \
HAVE_PATHS_H=YesPlease \
HAVE_CLOCK_GETTIME=YesPlease \
HAVE_CLOCK_MONOTONIC=YesPlease \
HAVE_GETDELIM=YesPlease \
FREAD_READS_DIRECTORIES=UnfortunatelyYes \
CSPRNG_METHOD=
}
bundle_git_manpages() {
require_path "$GIT_SRC_DIR/Documentation"
log "Bundling full Git manpage sources"
mkdir -p "$ANDROID_ASSET_MANPAGE_DIR"
find "$ANDROID_ASSET_MANPAGE_DIR" -type f -name '*.txt' -delete
while IFS= read -r manpage_source; do
local manpage_name
manpage_name="$(basename "$manpage_source")"
cp "$manpage_source" "$ANDROID_ASSET_MANPAGE_DIR/${manpage_name%.*}.txt"
done < <(find "$GIT_SRC_DIR/Documentation" -maxdepth 1 -type f \( -name 'git*.txt' -o -name 'git*.adoc' -o -name 'gitignore.txt' -o -name 'gitignore.adoc' \))
}
build_host_git() {
ensure_git_source
bundle_git_manpages
log "Building Git for development host"
cd "$GIT_SRC_DIR"
make clean >/dev/null 2>&1 || true
mapfile -t make_args < <(common_git_make_args)
make -j"$(nproc 2>/dev/null || printf 4)" "${make_args[@]}" git
mkdir -p "$HOST_GIT_DIR"
cp git "$HOST_GIT_BINARY"
chmod 755 "$HOST_GIT_BINARY"
log "Host test Git binary: $HOST_GIT_BINARY"
"$HOST_GIT_BINARY" --version
cd "$PROJECT_DIR"
}
build_android_git_for_abi() {
local abi="$1"
local cc="$2"
local output_dir="$ANDROID_JNI_DIR/$abi"
require_path "$ANDROID_TOOLBIN/$cc"
log "Building Git for Android $abi"
cd "$GIT_SRC_DIR"
make clean >/dev/null 2>&1 || true
mapfile -t make_args < <(common_git_make_args)
make -j"$(nproc 2>/dev/null || printf 4)" \
uname_S=Android \
uname_O=Android \
NO_PTHREADS=YesPlease \
NO_LIBGEN_H=YesPlease \
HAVE_DEV_TTY=YesPlease \
CC="$cc" \
AR=llvm-ar \
RANLIB=llvm-ranlib \
STRIP=llvm-strip \
"${make_args[@]}" \
git
log "Validating Android $abi binary"
file git
readelf -h git | sed -n '1,12p'
mkdir -p "$output_dir"
llvm-strip -s git -o "$output_dir/libgit.so"
chmod 755 "$output_dir/libgit.so"
ls -lh "$output_dir/libgit.so"
cd "$PROJECT_DIR"
}
build_android_git() {
ensure_git_source
bundle_git_manpages
require_path "$ANDROID_NDK_DIR"
export PATH="$ANDROID_TOOLBIN:$PATH"
build_android_git_for_abi "arm64-v8a" "aarch64-linux-android${ANDROID_API}-clang"
build_android_git_for_abi "armeabi-v7a" "armv7a-linux-androideabi${ANDROID_API}-clang"
build_android_git_for_abi "x86" "i686-linux-android${ANDROID_API}-clang"
build_android_git_for_abi "x86_64" "x86_64-linux-android${ANDROID_API}-clang"
}
build_all_git_targets() {
build_host_git
build_android_git
}
ensure_sdk_packages() {
setup_env
@@ -302,6 +430,7 @@ maybe_run_operation() {
local should_bump_version="false"
local should_auto_commit="false"
local should_compile_host_git="false"
local should_bundle_manpages="false"
case "$mode" in
--build)
@@ -311,14 +440,7 @@ maybe_run_operation() {
artifact_target="$PROJECT_DIR/app/build/outputs/apk/debug/githug-android-debug.apk"
should_bump_version="true"
should_auto_commit="true"
;;
--build-aab)
gradle_task="bundleDebug"
artifact_label="debug AAB"
artifact_source="$PROJECT_DIR/app/build/outputs/bundle/debug/app-debug.aab"
artifact_target="$PROJECT_DIR/app/build/outputs/bundle/debug/githug-android-debug.aab"
should_bump_version="true"
should_auto_commit="true"
should_bundle_manpages="true"
;;
--build-release-aab)
gradle_task="bundleRelease"
@@ -327,6 +449,7 @@ maybe_run_operation() {
artifact_target="$PROJECT_DIR/app/build/outputs/bundle/release/githug-android-release.aab"
should_bump_version="true"
should_auto_commit="true"
should_bundle_manpages="true"
;;
--test)
gradle_task="testDebugUnitTest"
@@ -334,7 +457,7 @@ maybe_run_operation() {
should_compile_host_git="true"
;;
--compile-git)
"$PROJECT_DIR/CompileGitForAllTargetPlatforms.sh" --all
build_all_git_targets
return
;;
*)
@@ -347,9 +470,13 @@ maybe_run_operation() {
bump_android_version
fi
if [ "$should_compile_host_git" = "true" ]; then
"$PROJECT_DIR/CompileGitForAllTargetPlatforms.sh" --host
build_host_git
export GITHUG_TEST_GIT_BINARY="$HOST_GIT_BINARY"
fi
if [ "$should_bundle_manpages" = "true" ]; then
ensure_git_source
bundle_git_manpages
fi
log "Running $artifact_label with --no-daemon"
"$PROJECT_DIR/gradlew" --no-daemon "$gradle_task"
@@ -371,10 +498,9 @@ maybe_run_operation() {
print_usage() {
cat <<EOF_USAGE
Usage: bash ./AndroidProjectTooling.sh [--build | --build-aab | --build-release-aab | --test | --compile-git]
Usage: bash ./AndroidProjectTooling.sh [--build | --build-release-aab | --test | --compile-git]
--build Set up the environment and build the debug APK
--build-aab Set up the environment and build the debug Android App Bundle (AAB)
--build-release-aab Set up the environment and build a release Android App Bundle (AAB)
--test Set up the environment, compile host Git, and run the debug JVM unit tests with it
--compile-git Compile Git for the development host and all Android target ABIs
@@ -383,7 +509,7 @@ EOF_USAGE
validate_args() {
case "${1:-}" in
""|--build|--build-aab|--build-release-aab|--test|--compile-git)
""|--build|--build-release-aab|--test|--compile-git)
;;
*)
echo "Unknown argument: $1" >&2
@@ -405,6 +531,7 @@ main() {
require_tool clang
require_tool pkg-config
require_tool readelf
require_tool file
ensure_dir "$TMP_DIR"
ensure_dir "$SDK_DIR"
@@ -426,7 +553,6 @@ main() {
log "To compile Git for host and Android ABIs: bash ./AndroidProjectTooling.sh --compile-git"
log "To build without a background Gradle daemon: ./gradlew --no-daemon assembleDebug"
log "To set up and build in one step: bash ./AndroidProjectTooling.sh --build"
log "To set up and build a debug AAB in one step: bash ./AndroidProjectTooling.sh --build-aab"
log "To set up and build a release AAB in one step: bash ./AndroidProjectTooling.sh --build-release-aab"
log "To set up and run unit tests with compiled host Git: bash ./AndroidProjectTooling.sh --test"
}

33
README.md
View File

@@ -11,7 +11,7 @@ The app is organized around GitHug parity rather than simplified command quizzes
- Each level file documents the intended repository setup, evaluation strategy, hints, command suggestions, and embedded solution scenarios.
- Validators prefer repository state and Git objects over raw command text. Direct command-answer validation is reserved for upstream answer-style levels such as identifying a hash, filename, remote URL, author, or count.
- Shared tests execute the embedded solution scenarios for every level and assert that the Android catalog still matches the upstream level order.
- The runtime prepares an isolated sandbox per level. When a bundled native Git binary is present, Git commands run against real repository directories; otherwise the Kotlin fallback engine keeps development and tests deterministic.
- The runtime prepares an isolated sandbox per level and requires a bundled native Git binary for the device ABI. If no native Git binary is available, the app shows an unavailable-build message instead of starting a playable session.
The UI supports a terminal-centered workflow with optional inspection panes:
@@ -46,7 +46,6 @@ Available commands:
| `bash ./AndroidProjectTooling.sh` | Provision or refresh the local Android/JDK toolchain only. | Toolchain under `./jdk` and `./android-sdk` |
| `bash ./AndroidProjectTooling.sh --test` | Compile host Git, set `GITHUG_TEST_GIT_BINARY`, and run JVM unit tests. | Test reports under `app/build/reports/` |
| `bash ./AndroidProjectTooling.sh --build` | Build the debug APK. | `app/build/outputs/apk/debug/githug-android-debug.apk` |
| `bash ./AndroidProjectTooling.sh --build-aab` | Build the debug Android App Bundle. | `app/build/outputs/bundle/debug/githug-android-debug.aab` |
| `bash ./AndroidProjectTooling.sh --build-release-aab` | Build the release Android App Bundle. | `app/build/outputs/bundle/release/githug-android-release.aab` |
| `bash ./AndroidProjectTooling.sh --compile-git` | Compile Git for the development host and all Android target ABIs. | Host and Android `libgit.so` binaries |
@@ -60,7 +59,6 @@ To build installable/debuggable artifacts:
```bash
bash ./AndroidProjectTooling.sh --build
bash ./AndroidProjectTooling.sh --build-aab
```
To build the release AAB intended for Play Store style distribution work:
@@ -77,34 +75,33 @@ To avoid repeated expensive SDK verification, the script writes a small state fi
If all required components were verified successfully, the script will skip SDK verification/reinstallation for the next **24 hours** unless required directories are missing.
When `--build`, `--build-aab`, or `--build-release-aab` is used, the script also:
When `--build` or `--build-release-aab` is used, the script also:
- increments `versionCode` by 1
- increments the patch component of `versionName`, for example `0.1.0` to `0.1.1`
- bundles full Git manpage source files from Git's `Documentation/` directory into app assets
- renames the generated artifact to a stable `githug-android-*` filename
- attempts to create a git commit after a successful build if there are source changes
The build commands currently run these Gradle tasks:
- `--build`: `assembleDebug`
- `--build-aab`: `bundleDebug`
- `--build-release-aab`: `bundleRelease`
## Git Binary Compilation
Native Git is compiled with:
Native Git compilation is integrated into the root tooling script:
```bash
bash ./CompileGitForAllTargetPlatforms.sh [--host | --android | --all]
bash ./AndroidProjectTooling.sh --compile-git
```
Options:
| Command | Purpose | Output |
| --- | --- | --- |
| `bash ./CompileGitForAllTargetPlatforms.sh --host` | Compile Git for the development machine. | `build/host-git/libgit.so` |
| `bash ./CompileGitForAllTargetPlatforms.sh --android` | Cross-compile Git for Android ABIs served by Google Play. | `app/src/main/jniLibs/<abi>/libgit.so` |
| `bash ./CompileGitForAllTargetPlatforms.sh --all` | Compile both host and Android targets. This is the default. | Host and Android outputs |
| `bash ./AndroidProjectTooling.sh --test` | Compile Git for the development machine, then run tests with it. | `build/host-git/libgit.so` and test reports |
| `bash ./AndroidProjectTooling.sh --compile-git` | Compile host Git and cross-compile Android ABIs served by Google Play. | Host and Android outputs |
Android ABI outputs:
@@ -113,22 +110,17 @@ Android ABI outputs:
- `app/src/main/jniLibs/x86/libgit.so`
- `app/src/main/jniLibs/x86_64/libgit.so`
The `--test` tooling command automatically runs `CompileGitForAllTargetPlatforms.sh --host` first and exports `GITHUG_TEST_GIT_BINARY=build/host-git/libgit.so`. This keeps JVM tests on the same `GitRepositoryRuntime` path as the app, including the packaged-runtime helper resolution behavior.
The `--test` tooling command automatically builds host Git first and exports `GITHUG_TEST_GIT_BINARY=build/host-git/libgit.so`. This keeps JVM tests on the same `GitRepositoryRuntime` path as the app, including the packaged-runtime helper resolution behavior.
The `--compile-git` tooling command is a convenience wrapper for:
```bash
bash ./CompileGitForAllTargetPlatforms.sh --all
```
Git manpage assets are also refreshed from the checked-out Git source whenever Git is compiled or an app artifact is built.
## Runtime Architecture
The command engine has two execution paths behind one app-facing runtime:
The command engine has one app-facing runtime:
- **Native Git path**: if the packaged executable is present for the device ABI, Git commands execute in a real per-level repository sandbox in app-private storage.
- **Kotlin fallback path**: the in-memory sandbox engine mirrors the same observable repository facts for development, JVM tests, and environments without a bundled native Git binary.
- **Native Git path**: the packaged executable for the device ABI runs Git commands in a real per-level repository sandbox in app-private storage.
Both paths expose the same `RepoState` surface to validators. In addition to files, commits, branches, tags, remotes, and config, the model tracks learning-relevant effects such as stashes, fetched remote refs, pushed branches/tags, submodules, and repository maintenance actions.
The runtime exposes a `RepoState` surface to validators. In addition to files, commits, branches, tags, remotes, and config, the model tracks learning-relevant effects such as stashes, fetched remote refs, pushed branches/tags, submodules, and repository maintenance actions.
Helper shell-like commands (`ls`, `pwd`, `cat`, `touch`, `mkdir`, `rm`, `echo`, `cd`) remain implemented in Kotlin so the mobile terminal behaves consistently across devices.
@@ -149,5 +141,4 @@ Current work is focused on:
- improving parity with upstream Ruby Githug setup and validation semantics
- expanding native-Git-backed behavior across complex repository workflows
- preserving robust fallback tests for every level
- improving onboarding, accessibility, UI polish, icons, and Play Store readiness

4
app/build.gradle.kts
View File

@@ -19,8 +19,8 @@ android {
applicationId = "solutions.tretter.githugandroid"
minSdk = 26
targetSdk = 35
versionCode = 128
versionName = "0.1.127"
versionCode = 129
versionName = "0.1.128"
testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
vectorDrawables.useSupportLibrary = true

460
app/src/main/assets/manpages/git-add.txt Normal file
View File

@@ -0,0 +1,460 @@
git-add(1)
==========
NAME
----
git-add - Add file contents to the index
SYNOPSIS
--------
[synopsis]
git add [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p]
[--edit | -e] [--[no-]all | -A | --[no-]ignore-removal | [--update | -u]] [--sparse]
[--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--renormalize]
[--chmod=(+|-)x] [--pathspec-from-file=<file> [--pathspec-file-nul]]
[--] [<pathspec>...]
DESCRIPTION
-----------
Add contents of new or changed files to the index. The "index" (also
known as the "staging area") is what you use to prepare the contents of
the next commit.
When you run `git commit` without any other arguments, it will only
commit staged changes. For example, if you've edited `file.c` and want
to commit your changes to that file, you can run:
git add file.c
git commit
You can also add only part of your changes to a file with `git add -p`.
This command can be performed multiple times before a commit. It only
adds the content of the specified file(s) at the time the add command is
run; if you want subsequent changes included in the next commit, then
you must run `git add` again to add the new content to the index.
The `git status` command can be used to obtain a summary of which
files have changes that are staged for the next commit.
The `git add` command will not add ignored files by default. You can
use the `--force` option to add ignored files. If you specify the exact
filename of an ignored file, `git add` will fail with a list of ignored
files. Otherwise it will silently ignore the file.
Please see linkgit:git-commit[1] for alternative ways to add content to a
commit.
OPTIONS
-------
`<pathspec>...`::
Files to add content from. Fileglobs (e.g. `*.c`) can
be given to add all matching files. Also a
leading directory name (e.g. `dir` to add `dir/file1`
and `dir/file2`) can be given to update the index to
match the current state of the directory as a whole (e.g.
specifying `dir` will record not just a file `dir/file1`
modified in the working tree, a file `dir/file2` added to
the working tree, but also a file `dir/file3` removed from
the working tree). Note that older versions of Git used
to ignore removed files; use `--no-all` option if you want
to add modified or new files but ignore removed ones.
+
For more details about the _<pathspec>_ syntax, see the 'pathspec' entry
in linkgit:gitglossary[7].
`-n`::
`--dry-run`::
Don't actually add the file(s), just show if they exist and/or will
be ignored.
`-v`::
`--verbose`::
Be verbose.
`-f`::
`--force`::
Allow adding otherwise ignored files. The option is also used when
`submodule.<name>.ignore=all` is set, but you want to stage an
update of the submodule. The `path` to the submodule must be explicitly
specified.
`--sparse`::
Allow updating index entries outside of the sparse-checkout cone.
Normally, `git add` refuses to update index entries whose paths do
not fit within the sparse-checkout cone, since those files might
be removed from the working tree without warning. See
linkgit:git-sparse-checkout[1] for more details.
`-i`::
`--interactive`::
Add modified contents in the working tree interactively to
the index. Optional path arguments may be supplied to limit
operation to a subset of the working tree. See ``Interactive
mode'' for details.
`-p`::
`--patch`::
Interactively choose hunks of patch between the index and the
work tree and add them to the index. This gives the user a chance
to review the difference before adding modified contents to the
index.
+
This effectively runs `add --interactive`, but bypasses the
initial command menu and directly jumps to the `patch` subcommand.
See ``Interactive mode'' for details.
include::diff-context-options.adoc[]
`-e`::
`--edit`::
Open the diff vs. the index in an editor and let the user
edit it. After the editor was closed, adjust the hunk headers
and apply the patch to the index.
+
The intent of this option is to pick and choose lines of the patch to
apply, or even to modify the contents of lines to be staged. This can be
quicker and more flexible than using the interactive hunk selector.
However, it is easy to confuse oneself and create a patch that does not
apply to the index. See EDITING PATCHES below.
`-u`::
`--update`::
Update the index just where it already has an entry matching
_<pathspec>_. This removes as well as modifies index entries to
match the working tree, but adds no new files.
+
If no _<pathspec>_ is given when `-u` option is used, all
tracked files in the entire working tree are updated (old versions
of Git used to limit the update to the current directory and its
subdirectories).
`-A`::
`--all`::
`--no-ignore-removal`::
Update the index not only where the working tree has a file
matching _<pathspec>_ but also where the index already has an
entry. This adds, modifies, and removes index entries to
match the working tree.
+
If no _<pathspec>_ is given when `-A` option is used, all
files in the entire working tree are updated (old versions
of Git used to limit the update to the current directory and its
subdirectories).
`--no-all`::
`--ignore-removal`::
Update the index by adding new files that are unknown to the
index and files modified in the working tree, but ignore
files that have been removed from the working tree. This
option is a no-op when no _<pathspec>_ is used.
+
This option is primarily to help users who are used to older
versions of Git, whose `git add <pathspec>...` was a synonym
for `git add --no-all <pathspec>...`, i.e. ignored removed files.
`-N`::
`--intent-to-add`::
Record only the fact that the path will be added later. An entry
for the path is placed in the index with no content. This is
useful for, among other things, showing the unstaged content of
such files with `git diff` and committing them with `git commit
-a`.
`--refresh`::
Don't add the file(s), but only refresh their stat()
information in the index.
`--ignore-errors`::
If some files could not be added because of errors indexing
them, do not abort the operation, but continue adding the
others. The command shall still exit with non-zero status.
The configuration variable `add.ignoreErrors` can be set to
true to make this the default behaviour.
`--ignore-missing`::
This option can only be used together with `--dry-run`. By using
this option the user can check if any of the given files would
be ignored, no matter if they are already present in the work
tree or not.
`--no-warn-embedded-repo`::
By default, `git add` will warn when adding an embedded
repository to the index without using `git submodule add` to
create an entry in `.gitmodules`. This option will suppress the
warning (e.g., if you are manually performing operations on
submodules).
`--renormalize`::
Apply the "clean" process freshly to all tracked files to
forcibly add them again to the index. This is useful after
changing `core.autocrlf` configuration or the `text` attribute
in order to correct files added with wrong _CRLF/LF_ line endings.
This option implies `-u`. Lone CR characters are untouched, thus
while a _CRLF_ cleans to _LF_, a _CRCRLF_ sequence is only partially
cleaned to _CRLF_.
`--chmod=(+|-)x`::
Override the executable bit of the added files. The executable
bit is only changed in the index, the files on disk are left
unchanged.
`--pathspec-from-file=<file>`::
Pathspec is passed in _<file>_ instead of commandline args. If
_<file>_ is exactly `-` then standard input is used. Pathspec
elements are separated by _LF_ or _CR/LF_. Pathspec elements can be
quoted as explained for the configuration variable `core.quotePath`
(see linkgit:git-config[1]). See also `--pathspec-file-nul` and
global `--literal-pathspecs`.
`--pathspec-file-nul`::
Only meaningful with `--pathspec-from-file`. Pathspec elements are
separated with _NUL_ character and all other characters are taken
literally (including newlines and quotes).
`--`::
This option can be used to separate command-line options from
the list of files, (useful when filenames might be mistaken
for command-line options).
EXAMPLES
--------
* Adds content from all ++*.txt++ files under `Documentation` directory
and its subdirectories:
+
------------
$ git add Documentation/\*.txt
------------
+
Note that the asterisk ++*++ is quoted from the shell in this
example; this lets the command include the files from
subdirectories of `Documentation/` directory.
* Considers adding content from all ++git-*.sh++ scripts:
+
------------
$ git add git-*.sh
------------
+
Because this example lets the shell expand the asterisk (i.e. you are
listing the files explicitly), it does not consider
`subdir/git-foo.sh`.
INTERACTIVE MODE
----------------
When the command enters the interactive mode, it shows the
output of the 'status' subcommand, and then goes into its
interactive command loop.
The command loop shows the list of subcommands available, and
gives a prompt "What now> ". In general, when the prompt ends
with a single '>', you can pick only one of the choices given
and type return, like this:
------------
*** Commands ***
1: status 2: update 3: revert 4: add untracked
5: patch 6: diff 7: quit 8: help
What now> 1
------------
You also could say `s` or `sta` or `status` above as long as the
choice is unique.
The main command loop has 6 subcommands (plus help and quit).
status::
This shows the change between `HEAD` and index (i.e. what will be
committed if you say `git commit`), and between index and
working tree files (i.e. what you could stage further before
`git commit` using `git add`) for each path. A sample output
looks like this:
+
------------
staged unstaged path
1: binary nothing foo.png
2: +403/-35 +1/-1 add-interactive.c
------------
+
It shows that `foo.png` has differences from `HEAD` (but that is
binary so line count cannot be shown) and there is no
difference between indexed copy and the working tree
version (if the working tree version were also different,
'binary' would have been shown in place of 'nothing'). The
other file, `add-interactive.c`, has 403 lines added
and 35 lines deleted if you commit what is in the index, but
working tree file has further modifications (one addition and
one deletion).
update::
This shows the status information and issues an "Update>>"
prompt. When the prompt ends with double '>>', you can
make more than one selection, concatenated with whitespace or
comma. Also you can say ranges. E.g. "2-5 7,9" to choose
2,3,4,5,7,9 from the list. If the second number in a range is
omitted, all remaining patches are taken. E.g. "7-" to choose
7,8,9 from the list. You can say '*' to choose everything.
+
What you chose are then highlighted with '*',
like this:
+
------------
staged unstaged path
1: binary nothing foo.png
* 2: +403/-35 +1/-1 add-interactive.c
------------
+
To remove selection, prefix the input with `-`
like this:
+
------------
Update>> -2
------------
+
After making the selection, answer with an empty line to stage the
contents of working tree files for selected paths in the index.
revert::
This has a very similar UI to 'update', and the staged
information for selected paths are reverted to that of the
HEAD version. Reverting new paths makes them untracked.
add untracked::
This has a very similar UI to 'update' and
'revert', and lets you add untracked paths to the index.
patch::
This lets you choose one path out of a 'status' like selection.
After choosing the path, it presents the diff between the index
and the working tree file and asks you if you want to stage
the change of each hunk. You can select one of the following
options and type return:
y - stage this hunk
n - do not stage this hunk
q - quit; do not stage this hunk or any of the remaining ones
a - stage this hunk and all later hunks in the file
d - do not stage this hunk or any of the later hunks in the file
g - select a hunk to go to
/ - search for a hunk matching the given regex
j - go to the next undecided hunk, roll over at the bottom
J - go to the next hunk, roll over at the bottom
k - go to the previous undecided hunk, roll over at the top
K - go to the previous hunk, roll over at the top
s - split the current hunk into smaller hunks
e - manually edit the current hunk
p - print the current hunk
P - print the current hunk using the pager
? - print help
+
After deciding the fate for all hunks, if there is any hunk
that was chosen, the index is updated with the selected hunks.
+
You can omit having to type return here, by setting the configuration
variable `interactive.singleKey` to `true`.
diff::
This lets you review what will be committed (i.e. between
`HEAD` and index).
EDITING PATCHES
---------------
Invoking `git add -e` or selecting `e` from the interactive hunk
selector will open a patch in your editor; after the editor exits, the
result is applied to the index. You are free to make arbitrary changes
to the patch, but note that some changes may have confusing results, or
even result in a patch that cannot be applied. If you want to abort the
operation entirely (i.e., stage nothing new in the index), simply delete
all lines of the patch. The list below describes some common things you
may see in a patch, and which editing operations make sense on them.
--
added content::
Added content is represented by lines beginning with "{plus}". You can
prevent staging any addition lines by deleting them.
removed content::
Removed content is represented by lines beginning with "-". You can
prevent staging their removal by converting the "-" to a " " (space).
modified content::
Modified content is represented by "-" lines (removing the old content)
followed by "{plus}" lines (adding the replacement content). You can
prevent staging the modification by converting "-" lines to " ", and
removing "{plus}" lines. Beware that modifying only half of the pair is
likely to introduce confusing changes to the index.
--
There are also more complex operations that can be performed. But beware
that because the patch is applied only to the index and not the working
tree, the working tree will appear to "undo" the change in the index.
For example, introducing a new line into the index that is in neither
the `HEAD` nor the working tree will stage the new line for commit, but
the line will appear to be reverted in the working tree.
Avoid using these constructs, or do so with extreme caution.
--
removing untouched content::
Content which does not differ between the index and working tree may be
shown on context lines, beginning with a " " (space). You can stage
context lines for removal by converting the space to a "-". The
resulting working tree file will appear to re-add the content.
modifying existing content::
One can also modify context lines by staging them for removal (by
converting " " to "-") and adding a "{plus}" line with the new content.
Similarly, one can modify "{plus}" lines for existing additions or
modifications. In all cases, the new modification will appear reverted
in the working tree.
new content::
You may also add new content that does not exist in the patch; simply
add new lines, each starting with "{plus}". The addition will appear
reverted in the working tree.
--
There are also several operations which should be avoided entirely, as
they will make the patch impossible to apply:
* adding context (" ") or removal ("-") lines
* deleting context or removal lines
* modifying the contents of context or removal lines
CONFIGURATION
-------------
include::includes/cmd-config-section-all.adoc[]
:git-add: 1
include::config/add.adoc[]
SEE ALSO
--------
linkgit:git-status[1]
linkgit:git-rm[1]
linkgit:git-reset[1]
linkgit:git-mv[1]
linkgit:git-commit[1]
linkgit:git-update-index[1]
GIT
---
Part of the linkgit:git[1] suite

316
app/src/main/assets/manpages/git-am.txt Normal file
View File

@@ -0,0 +1,316 @@
git-am(1)
=========
NAME
----
git-am - Apply a series of patches from a mailbox
SYNOPSIS
--------
[verse]
'git am' [--signoff] [--keep] [--[no-]keep-cr] [--[no-]utf8] [--[no-]verify]
[--[no-]3way] [--interactive] [--committer-date-is-author-date]
[--ignore-date] [--ignore-space-change | --ignore-whitespace]
[--whitespace=<action>] [-C<n>] [-p<n>] [--directory=<dir>]
[--exclude=<path>] [--include=<path>] [--reject] [-q | --quiet]
[--[no-]scissors] [-S[<keyid>]] [--patch-format=<format>]
[--quoted-cr=<action>]
[--empty=(stop|drop|keep)]
[(<mbox> | <Maildir>)...]
'git am' (--continue | --skip | --abort | --quit | --retry | --show-current-patch[=(diff|raw)] | --allow-empty)
DESCRIPTION
-----------
Splits mail messages in a mailbox into commit log messages,
authorship information, and patches, and applies them to the
current branch. You could think of it as a reverse operation
of linkgit:git-format-patch[1] run on a branch with a straight
history without merges.
OPTIONS
-------
(<mbox>|<Maildir>)...::
The list of mailbox files to read patches from. If you do not
supply this argument, the command reads from the standard input.
If you supply directories, they will be treated as Maildirs.
-s::
--signoff::
Add a `Signed-off-by` trailer to the commit message (see
linkgit:git-interpret-trailers[1]), using the committer identity
of yourself. See the signoff option in linkgit:git-commit[1]
for more information.
-k::
--keep::
Pass `-k` flag to linkgit:git-mailinfo[1].
--keep-non-patch::
Pass `-b` flag to linkgit:git-mailinfo[1].
--keep-cr::
--no-keep-cr::
With `--keep-cr`, call linkgit:git-mailsplit[1]
with the same option, to prevent it from stripping CR at the end of
lines. `am.keepcr` configuration variable can be used to specify the
default behaviour. `--no-keep-cr` is useful to override `am.keepcr`.
-c::
--scissors::
Remove everything in body before a scissors line (see
linkgit:git-mailinfo[1]). Can be activated by default using
the `mailinfo.scissors` configuration variable.
--no-scissors::
Ignore scissors lines (see linkgit:git-mailinfo[1]).
--quoted-cr=<action>::
This flag will be passed down to linkgit:git-mailinfo[1].
--empty=(drop|keep|stop)::
How to handle an e-mail message lacking a patch:
+
--
`drop`;;
The e-mail message will be skipped.
`keep`;;
An empty commit will be created, with the contents of the e-mail
message as its log.
`stop`;;
The command will fail, stopping in the middle of the current `am`
session. This is the default behavior.
--
-m::
--message-id::
Pass the `-m` flag to linkgit:git-mailinfo[1],
so that the `Message-ID` header is added to the commit message.
The `am.messageid` configuration variable can be used to specify
the default behaviour.
--no-message-id::
Do not add the Message-ID header to the commit message.
`--no-message-id` is useful to override `am.messageid`.
-q::
--quiet::
Be quiet. Only print error messages.
-u::
--utf8::
Pass `-u` flag to linkgit:git-mailinfo[1].
The proposed commit log message taken from the e-mail
is re-coded into UTF-8 encoding (configuration variable
`i18n.commitEncoding` can be used to specify the project's
preferred encoding if it is not UTF-8).
+
This was optional in prior versions of git, but now it is the
default. You can use `--no-utf8` to override this.
--no-utf8::
Pass `-n` flag to linkgit:git-mailinfo[1].
-3::
--3way::
--no-3way::
When the patch does not apply cleanly, fall back on
3-way merge if the patch records the identity of blobs
it is supposed to apply to and we have those blobs
available locally. `--no-3way` can be used to override
am.threeWay configuration variable. For more information,
see am.threeWay in linkgit:git-config[1].
include::rerere-options.adoc[]
--ignore-space-change::
--ignore-whitespace::
--whitespace=<action>::
-C<n>::
-p<n>::
--directory=<dir>::
--exclude=<path>::
--include=<path>::
--reject::
These flags are passed to the linkgit:git-apply[1] program that
applies the patch.
+
Valid <action> for the `--whitespace` option are:
`nowarn`, `warn`, `fix`, `error`, and `error-all`.
--patch-format::
By default the command will try to detect the patch format
automatically. This option allows the user to bypass the automatic
detection and specify the patch format that the patch(es) should be
interpreted as. Valid formats are mbox, mboxrd,
stgit, stgit-series, and hg.
-i::
--interactive::
Run interactively.
--verify::
-n::
--no-verify::
Run the `pre-applypatch` and `applypatch-msg` hooks. This is the
default. Skip these hooks with `-n` or `--no-verify`. See also
linkgit:githooks[5].
+
Note that `post-applypatch` cannot be skipped.
--committer-date-is-author-date::
By default the command records the date from the e-mail
message as the commit author date, and uses the time of
commit creation as the committer date. This allows the
user to lie about the committer date by using the same
value as the author date.
+
WARNING: The history walking machinery assumes that commits have
non-decreasing commit timestamps. You should consider if you really need
to use this option. Then you should only use this option to override the
committer date when applying commits on top of a base which commit is
older (in terms of the commit date) than the oldest patch you are
applying.
--ignore-date::
By default the command records the date from the e-mail
message as the commit author date, and uses the time of
commit creation as the committer date. This allows the
user to lie about the author date by using the same
value as the committer date.
--skip::
Skip the current patch. This is only meaningful when
restarting an aborted patch.
-S[<keyid>]::
--gpg-sign[=<keyid>]::
--no-gpg-sign::
GPG-sign commits. The `keyid` argument is optional and
defaults to the committer identity; if specified, it must be
stuck to the option without a space. `--no-gpg-sign` is useful to
countermand both `commit.gpgSign` configuration variable, and
earlier `--gpg-sign`.
--continue::
-r::
--resolved::
After a patch failure (e.g. attempting to apply
conflicting patch), the user has applied it by hand and
the index file stores the result of the application.
Make a commit using the authorship and commit log
extracted from the e-mail message and the current index
file, and continue.
--resolvemsg=<msg>::
When a patch failure occurs, <msg> will be printed
to the screen before exiting. This overrides the
standard message informing you to use `--continue`
or `--skip` to handle the failure. This is solely
for internal use between linkgit:git-rebase[1] and
linkgit:git-am[1].
--abort::
Restore the original branch and abort the patching operation.
Revert the contents of files involved in the am operation to their
pre-am state.
--quit::
Abort the patching operation but keep HEAD and the index
untouched.
--retry::
Try to apply the last conflicting patch again. This is generally
only useful for passing extra options to the retry attempt
(e.g., `--3way`), since otherwise you'll just see the same
failure again.
--show-current-patch[=(diff|raw)]::
Show the message at which linkgit:git-am[1] has stopped due to
conflicts. If `raw` is specified, show the raw contents of
the e-mail message; if `diff`, show the diff portion only.
Defaults to `raw`.
--allow-empty::
After a patch failure on an input e-mail message lacking a patch,
create an empty commit with the contents of the e-mail message
as its log message.
[[discussion]]
DISCUSSION
----------
The commit author name is taken from the "From: " line of the
message, and commit author date is taken from the "Date: " line
of the message. The "Subject: " line is used as the title of
the commit, after stripping common prefix "[PATCH <anything>]".
The "Subject: " line is supposed to concisely describe what the
commit is about in one line of text.
"From: ", "Date: ", and "Subject: " lines starting the body override the
respective commit author name and title values taken from the headers.
The commit message is formed by the title taken from the
"Subject: ", a blank line and the body of the message up to
where the patch begins. Excess whitespace at the end of each
line is automatically stripped.
The patch is expected to be inline, directly following the
message.
include::format-patch-end-of-commit-message.adoc[]
This means that the contents of the commit message can inadvertently
interrupt the processing (see the <<caveats,CAVEATS>> section below).
When initially invoking linkgit:git-am[1], you give it the names of the mailboxes
to process. Upon seeing the first patch that does not apply, it
aborts in the middle. You can recover from this in one of two ways:
. skip the current patch by re-running the command with the `--skip`
option.
. hand resolve the conflict in the working directory, and update
the index file to bring it into a state that the patch should
have produced. Then run the command with the `--continue` option.
The command refuses to process new mailboxes until the current
operation is finished, so if you decide to start over from scratch,
run `git am --abort` before running the command with mailbox
names.
Before any patches are applied, ORIG_HEAD is set to the tip of the
current branch. This is useful if you have problems with multiple
commits, like running linkgit:git-am[1] on the wrong branch or an error
in the commits that is more easily fixed by changing the mailbox (e.g.
errors in the "From:" lines).
[[caveats]]
CAVEATS
-------
:git-am: 1
include::format-patch-caveats.adoc[]
HOOKS
-----
This command can run `applypatch-msg`, `pre-applypatch`,
and `post-applypatch` hooks. See linkgit:githooks[5] for more
information.
See the `--verify`/`-n`/`--no-verify` options.
CONFIGURATION
-------------
include::includes/cmd-config-section-all.adoc[]
include::config/am.adoc[]
SEE ALSO
--------
linkgit:git-apply[1],
linkgit:git-format-patch[1].
GIT
---
Part of the linkgit:git[1] suite

33
app/src/main/assets/manpages/git-annotate.txt Normal file
View File

@@ -0,0 +1,33 @@
git-annotate(1)
===============
NAME
----
git-annotate - Annotate file lines with commit information
SYNOPSIS
--------
[verse]
'git annotate' [<options>] [<rev-opts>] [<rev>] [--] <file>
DESCRIPTION
-----------
Annotates each line in the given file with information from the commit
which introduced the line. Optionally annotates from a given revision.
The only difference between this command and linkgit:git-blame[1] is that
they use slightly different output formats, and this command exists only
for backward compatibility to support existing scripts, and provide a more
familiar command name for people coming from other SCM systems.
OPTIONS
-------
include::blame-options.adoc[]
SEE ALSO
--------
linkgit:git-blame[1]
GIT
---
Part of the linkgit:git[1] suite

299
app/src/main/assets/manpages/git-apply.txt Normal file
View File

@@ -0,0 +1,299 @@
git-apply(1)
============
NAME
----
git-apply - Apply a patch to files and/or to the index
SYNOPSIS
--------
[verse]
'git apply' [--stat] [--numstat] [--summary] [--check]
[--index | --intent-to-add] [--3way] [--ours | --theirs | --union]
[--apply] [--no-add] [--build-fake-ancestor=<file>] [-R | --reverse]
[--allow-binary-replacement | --binary] [--reject] [-z]
[-p<n>] [-C<n>] [--inaccurate-eof] [--recount] [--cached]
[--ignore-space-change | --ignore-whitespace]
[--whitespace=(nowarn|warn|fix|error|error-all)]
[--exclude=<path>] [--include=<path>] [--directory=<root>]
[--verbose | --quiet] [--unsafe-paths] [--allow-empty] [<patch>...]
DESCRIPTION
-----------
Reads the supplied diff output (i.e. "a patch") and applies it to files.
When running from a subdirectory in a repository, patched paths
outside the directory are ignored.
With the `--index` option, the patch is also applied to the index, and
with the `--cached` option, the patch is only applied to the index.
Without these options, the command applies the patch only to files,
and does not require them to be in a Git repository.
This command applies the patch but does not create a commit. Use
linkgit:git-am[1] to create commits from patches generated by
linkgit:git-format-patch[1] and/or received by email.
OPTIONS
-------
<patch>...::
The files to read the patch from. '-' can be used to read
from the standard input.
--stat::
Instead of applying the patch, output diffstat for the
input. Turns off "apply".
--numstat::
Similar to `--stat`, but shows the number of added and
deleted lines in decimal notation and the pathname without
abbreviation, to make it more machine friendly. For
binary files, outputs two `-` instead of saying
`0 0`. Turns off "apply".
--summary::
Instead of applying the patch, output a condensed
summary of information obtained from git diff extended
headers, such as creations, renames, and mode changes.
Turns off "apply".
--check::
Instead of applying the patch, see if the patch is
applicable to the current working tree and/or the index
file and detects errors. Turns off "apply".
--index::
Apply the patch to both the index and the working tree (or
merely check that it would apply cleanly to both if `--check` is
in effect). Note that `--index` expects index entries and
working tree copies for relevant paths to be identical (their
contents and metadata such as file mode must match), and will
raise an error if they are not, even if the patch would apply
cleanly to both the index and the working tree in isolation.
--cached::
Apply the patch to just the index, without touching the working
tree. If `--check` is in effect, merely check that it would
apply cleanly to the index entry.
-N::
--intent-to-add::
When applying the patch only to the working tree, mark new
files to be added to the index later (see `--intent-to-add`
option in linkgit:git-add[1]). This option is ignored if
`--index` or `--cached` are used, and has no effect outside a Git
repository. Note that `--index` could be implied by other options
such as `--3way`.
-3::
--3way::
Attempt 3-way merge if the patch records the identity of blobs it is supposed
to apply to and we have those blobs available locally, possibly leaving the
conflict markers in the files in the working tree for the user to
resolve. This option implies the `--index` option unless the
`--cached` option is used, and is incompatible with the `--reject` option.
When used with the `--cached` option, any conflicts are left at higher stages
in the cache.
--ours::
--theirs::
--union::
Instead of leaving conflicts in the file, resolve conflicts favouring
our (or their or both) side of the lines. Requires --3way.
--build-fake-ancestor=<file>::
Newer 'git diff' output has embedded 'index information'
for each blob to help identify the original version that
the patch applies to. When this flag is given, and if
the original versions of the blobs are available locally,
builds a temporary index containing those blobs.
+
When a pure mode change is encountered (which has no index information),
the information is read from the current index instead.
-R::
--reverse::
Apply the patch in reverse.
--reject::
For atomicity, 'git apply' by default fails the whole patch and
does not touch the working tree when some of the hunks
do not apply. This option makes it apply
the parts of the patch that are applicable, and leave the
rejected hunks in corresponding *.rej files.
-z::
When `--numstat` has been given, do not munge pathnames,
but use a NUL-terminated machine-readable format.
+
Without this option, pathnames with "unusual" characters are quoted as
explained for the configuration variable `core.quotePath` (see
linkgit:git-config[1]).
-p<n>::
Remove <n> leading path components (separated by slashes) from
traditional diff paths. E.g., with `-p2`, a patch against
`a/dir/file` will be applied directly to `file`. The default is
1.
-C<n>::
Ensure at least <n> lines of surrounding context match before
and after each change. When fewer lines of surrounding
context exist they all must match. By default no context is
ever ignored.
--unidiff-zero::
By default, 'git apply' expects that the patch being
applied is a unified diff with at least one line of context.
This provides good safety measures, but breaks down when
applying a diff generated with `--unified=0`. To bypass these
checks use `--unidiff-zero`.
+
Note, for the reasons stated above, the usage of context-free patches is
discouraged.
--apply::
If you use any of the options marked "Turns off
'apply'" above, 'git apply' reads and outputs the
requested information without actually applying the
patch. Give this flag after those flags to also apply
the patch.
--no-add::
When applying a patch, ignore additions made by the
patch. This can be used to extract the common part between
two files by first running 'diff' on them and applying
the result with this option, which would apply the
deletion part but not the addition part.
--allow-binary-replacement::
--binary::
Historically we did not allow binary patch application
without an explicit permission from the user, and this
flag was the way to do so. Currently, we always allow binary
patch application, so this is a no-op.
--exclude=<path-pattern>::
Don't apply changes to files matching the given path pattern. This can
be useful when importing patchsets, where you want to exclude certain
files or directories.
--include=<path-pattern>::
Apply changes to files matching the given path pattern. This can
be useful when importing patchsets, where you want to include certain
files or directories.
+
When `--exclude` and `--include` patterns are used, they are examined in the
order they appear on the command line, and the first match determines if a
patch to each path is used. A patch to a path that does not match any
include/exclude pattern is used by default if there is no include pattern
on the command line, and ignored if there is any include pattern.
--ignore-space-change::
--ignore-whitespace::
When applying a patch, ignore changes in whitespace in context
lines if necessary.
Context lines will preserve their whitespace, and they will not
undergo whitespace fixing regardless of the value of the
`--whitespace` option. New lines will still be fixed, though.
--whitespace=<action>::
When applying a patch, detect a new or modified line that has
whitespace errors. What are considered whitespace errors is
controlled by `core.whitespace` configuration. By default,
trailing whitespaces (including lines that solely consist of
whitespaces) and a space character that is immediately followed
by a tab character inside the initial indent of the line are
considered whitespace errors.
+
By default, the command outputs warning messages but applies the patch.
When `git-apply` is used for statistics and not applying a
patch, it defaults to `nowarn`.
+
You can use different `<action>` values to control this
behavior:
+
* `nowarn` turns off the trailing whitespace warning.
* `warn` outputs warnings for a few such errors, but applies the
patch as-is (default).
* `fix` outputs warnings for a few such errors, and applies the
patch after fixing them (`strip` is a synonym -- the tool
used to consider only trailing whitespace characters as errors, and the
fix involved 'stripping' them, but modern Gits do more).
* `error` outputs warnings for a few such errors, and refuses
to apply the patch.
* `error-all` is similar to `error` but shows all errors.
--inaccurate-eof::
Under certain circumstances, some versions of 'diff' do not correctly
detect a missing new-line at the end of the file. As a result, patches
created by such 'diff' programs do not record incomplete lines
correctly. This option adds support for applying such patches by
working around this bug.
-v::
--verbose::
Report progress to stderr. By default, only a message about the
current patch being applied will be printed. This option will cause
additional information to be reported.
-q::
--quiet::
Suppress stderr output. Messages about patch status and progress
will not be printed.
--recount::
Do not trust the line counts in the hunk headers, but infer them
by inspecting the patch (e.g. after editing the patch without
adjusting the hunk headers appropriately).
--directory=<root>::
Prepend <root> to all filenames. If a "-p" argument was also passed,
it is applied before prepending the new root.
+
For example, a patch that talks about updating `a/git-gui.sh` to `b/git-gui.sh`
can be applied to the file in the working tree `modules/git-gui/git-gui.sh` by
running `git apply --directory=modules/git-gui`.
--unsafe-paths::
By default, a patch that affects outside the working area
(either a Git controlled working tree, or the current working
directory when "git apply" is used as a replacement of GNU
patch) is rejected as a mistake (or a mischief).
+
When `git apply` is used as a "better GNU patch", the user can pass
the `--unsafe-paths` option to override this safety check. This option
has no effect when `--index` or `--cached` is in use.
--allow-empty::
Don't return an error for patches containing no diff. This includes
empty patches and patches with commit text only.
CONFIGURATION
-------------
include::includes/cmd-config-section-all.adoc[]
include::config/apply.adoc[]
SUBMODULES
----------
If the patch contains any changes to submodules then 'git apply'
treats these changes as follows.
If `--index` is specified (explicitly or implicitly), then the submodule
commits must match the index exactly for the patch to apply. If any
of the submodules are checked-out, then these check-outs are completely
ignored, i.e., they are not required to be up to date or clean and they
are not updated.
If `--index` is not specified, then the submodule commits in the patch
are ignored and only the absence or presence of the corresponding
subdirectory is checked and (if possible) updated.
SEE ALSO
--------
linkgit:git-am[1].
GIT
---
Part of the linkgit:git[1] suite

113
app/src/main/assets/manpages/git-archimport.txt Normal file
View File

@@ -0,0 +1,113 @@
git-archimport(1)
=================
NAME
----
git-archimport - Import a GNU Arch repository into Git
SYNOPSIS
--------
[verse]
'git archimport' [-h] [-v] [-o] [-a] [-f] [-T] [-D <depth>] [-t <tempdir>]
<archive>/<branch>[:<git-branch>]...
DESCRIPTION
-----------
Imports a project from one or more GNU Arch repositories.
It will follow branches
and repositories within the namespaces defined by the <archive>/<branch>
parameters supplied. If it cannot find the remote branch a merge comes from
it will just import it as a regular commit. If it can find it, it will mark it
as a merge whenever possible (see discussion below).
The script expects you to provide the key roots where it can start the import
from an 'initial import' or 'tag' type of Arch commit. It will follow and
import new branches within the provided roots.
It expects to be dealing with one project only. If it sees
branches that have different roots, it will refuse to run. In that case,
edit your <archive>/<branch> parameters to define clearly the scope of the
import.
'git archimport' uses `tla` extensively in the background to access the
Arch repository.
Make sure you have a recent version of `tla` available in the path. `tla` must
know about the repositories you pass to 'git archimport'.
For the initial import, 'git archimport' expects to find itself in an empty
directory. To follow the development of a project that uses Arch, rerun
'git archimport' with the same parameters as the initial import to perform
incremental imports.
While 'git archimport' will try to create sensible branch names for the
archives that it imports, it is also possible to specify Git branch names
manually. To do so, write a Git branch name after each <archive>/<branch>
parameter, separated by a colon. This way, you can shorten the Arch
branch names and convert Arch jargon to Git jargon, for example mapping a
"PROJECT{litdd}devo{litdd}VERSION" branch to "master".
Associating multiple Arch branches to one Git branch is possible; the
result will make the most sense only if no commits are made to the first
branch, after the second branch is created. Still, this is useful to
convert Arch repositories that had been rotated periodically.
MERGES
------
Patch merge data from Arch is used to mark merges in Git as well. Git
does not care much about tracking patches, and only considers a merge when a
branch incorporates all the commits since the point they forked. The end result
is that Git will have a good idea of how far branches have diverged. So the
import process does lose some patch-trading metadata.
Fortunately, when you try and merge branches imported from Arch,
Git will find a good merge base, and it has a good chance of identifying
patches that have been traded out-of-sequence between the branches.
OPTIONS
-------
-h::
Display usage.
-v::
Verbose output.
-T::
Many tags. Will create a tag for every commit, reflecting the commit
name in the Arch repository.
-f::
Use the fast patchset import strategy. This can be significantly
faster for large trees, but cannot handle directory renames or
permissions changes. The default strategy is slow and safe.
-o::
Use this for compatibility with old-style branch names used by
earlier versions of 'git archimport'. Old-style branch names
were category{litdd}branch, whereas new-style branch names are
archive,category{litdd}branch{litdd}version. In both cases, names given
on the command-line will override the automatically-generated
ones.
-D <depth>::
Follow merge ancestry and attempt to import trees that have been
merged from. Specify a depth greater than 1 if patch logs have been
pruned.
-a::
Attempt to auto-register archives at `http://mirrors.sourcecontrol.net`
This is particularly useful with the -D option.
-t <tmpdir>::
Override the default tempdir.
<archive>/<branch>::
<archive>/<branch> identifier in a format that `tla log` understands.
GIT
---
Part of the linkgit:git[1] suite

248
app/src/main/assets/manpages/git-archive.txt Normal file
View File

@@ -0,0 +1,248 @@
git-archive(1)
==============
NAME
----
git-archive - Create an archive of files from a named tree
SYNOPSIS
--------
[verse]
'git archive' [--format=<fmt>] [--list] [--prefix=<prefix>/] [<extra>]
[-o <file> | --output=<file>] [--worktree-attributes]
[--remote=<repo> [--exec=<git-upload-archive>]] <tree-ish>
[<path>...]
DESCRIPTION
-----------
Creates an archive of the specified format containing the tree
structure for the named tree, and writes it out to the standard
output. If <prefix> is specified it is
prepended to the filenames in the archive.
'git archive' behaves differently when given a tree ID as opposed to a
commit ID or tag ID. When a tree ID is provided, the current time is
used as the modification time of each file in the archive. On the
other hand, when a commit ID or tag ID is provided, the commit time as
recorded in the referenced commit object is used instead.
Additionally the commit ID is stored in a global extended pax header
if the tar format is used; it can be extracted using 'git
get-tar-commit-id'. In ZIP files it is stored as a file comment.
OPTIONS
-------
--format=<fmt>::
Format of the resulting archive. Possible values are `tar`,
`zip`, `tar.gz`, `tgz`, and any format defined using the
configuration option `tar.<format>.command`. If `--format`
is not given, and the output file is specified, the format is
inferred from the filename if possible (e.g. writing to `foo.zip`
makes the output to be in the `zip` format). Otherwise the output
format is `tar`.
-l::
--list::
Show all available formats.
-v::
--verbose::
Report progress to stderr.
--prefix=<prefix>/::
Prepend <prefix>/ to paths in the archive. Can be repeated; its
rightmost value is used for all tracked files. See below which
value gets used by `--add-file`.
+
The <prefix> is used as given and is not normalized. It may
include leading slashes or parent directory components (e.g.,
`../`). Some archive consumers may treat such paths as
potentially unsafe and adjust or warn during extraction.
-o <file>::
--output=<file>::
Write the archive to <file> instead of stdout.
--add-file=<file>::
Add a non-tracked file to the archive. Can be repeated to add
multiple files. The path of the file in the archive is built by
concatenating the value of the last `--prefix` option (if any)
before this `--add-file` and the basename of <file>.
--add-virtual-file=<path>:<content>::
Add the specified contents to the archive. Can be repeated to add
multiple files.
+
The `<path>` argument can start and end with a literal double-quote
character; the contained file name is interpreted as a C-style string,
i.e. the backslash is interpreted as escape character. The path must
be quoted if it contains a colon, to avoid the colon from being
misinterpreted as the separator between the path and the contents, or
if the path begins or ends with a double-quote character.
+
The file mode is limited to a regular file, and the option may be
subject to platform-dependent command-line limits. For non-trivial
cases, write an untracked file and use `--add-file` instead.
+
Note that unlike `--add-file` the path created in the archive is not
affected by the `--prefix` option, as a full `<path>` can be given as
the value of the option.
--worktree-attributes::
Look for attributes in .gitattributes files in the working tree
as well (see <<ATTRIBUTES>>).
--mtime=<time>::
Set modification time of archive entries. Without this option
the committer time is used if `<tree-ish>` is a commit or tag,
and the current time if it is a tree.
<extra>::
This can be any options that the archiver backend understands.
See next section.
--remote=<repo>::
Instead of making a tar archive from the local repository,
retrieve a tar archive from a remote repository. Note that the
remote repository may place restrictions on which sha1
expressions may be allowed in `<tree-ish>`. See
linkgit:git-upload-archive[1] for details.
--exec=<git-upload-archive>::
Used with --remote to specify the path to the
'git-upload-archive' on the remote side.
<tree-ish>::
The tree or commit to produce an archive for.
<path>::
Without an optional path parameter, all files and subdirectories
of the current working directory are included in the archive.
If one or more paths are specified, only these are included.
BACKEND EXTRA OPTIONS
---------------------
zip
~~~
-<digit>::
Specify compression level. Larger values allow the command
to spend more time to compress to smaller size. Supported
values are from `-0` (store-only) to `-9` (best ratio).
Default is `-6` if not given.
tar
~~~
-<number>::
Specify compression level. The value will be passed to the
compression command configured in `tar.<format>.command`. See
manual page of the configured command for the list of supported
levels and the default level if this option isn't specified.
CONFIGURATION
-------------
tar.umask::
This variable can be used to restrict the permission bits of
tar archive entries. The default is 0002, which turns off the
world write bit. The special value "user" indicates that the
archiving user's umask will be used instead. See umask(2) for
details. If `--remote` is used then only the configuration of
the remote repository takes effect.
tar.<format>.command::
This variable specifies a shell command through which the tar
output generated by `git archive` should be piped. The command
is executed using the shell with the generated tar file on its
standard input, and should produce the final output on its
standard output. Any compression-level options will be passed
to the command (e.g., `-9`).
+
The `tar.gz` and `tgz` formats are defined automatically and use the
magic command `git archive gzip` by default, which invokes an internal
implementation of gzip.
tar.<format>.remote::
If true, enable the format for use by remote clients via
linkgit:git-upload-archive[1]. Defaults to false for
user-defined formats, but true for the `tar.gz` and `tgz`
formats.
[[ATTRIBUTES]]
ATTRIBUTES
----------
export-ignore::
Files and directories with the attribute export-ignore won't be
added to archive files. See linkgit:gitattributes[5] for details.
export-subst::
If the attribute export-subst is set for a file then Git will
expand several placeholders when adding this file to an archive.
See linkgit:gitattributes[5] for details.
Note that attributes are by default taken from the `.gitattributes` files
in the tree that is being archived. If you want to tweak the way the
output is generated after the fact (e.g. you committed without adding an
appropriate export-ignore in its `.gitattributes`), adjust the checked out
`.gitattributes` file as necessary and use `--worktree-attributes`
option. Alternatively you can keep necessary attributes that should apply
while archiving any tree in your `$GIT_DIR/info/attributes` file.
EXAMPLES
--------
`git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -)`::
Create a tar archive that contains the contents of the
latest commit on the current branch, and extract it in the
`/var/tmp/junk` directory.
`git archive --format=tar --prefix=git-1.4.0/ v1.4.0 | gzip >git-1.4.0.tar.gz`::
Create a compressed tarball for v1.4.0 release.
`git archive --format=tar.gz --prefix=git-1.4.0/ v1.4.0 >git-1.4.0.tar.gz`::
Same as above, but using the builtin tar.gz handling.
`git archive --prefix=git-1.4.0/ -o git-1.4.0.tar.gz v1.4.0`::
Same as above, but the format is inferred from the output file.
`git archive --format=tar --prefix=git-1.4.0/ v1.4.0^{tree} | gzip >git-1.4.0.tar.gz`::
Create a compressed tarball for v1.4.0 release, but without a
global extended pax header.
`git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ > git-1.4.0-docs.zip`::
Put everything in the current head's Documentation/ directory
into 'git-1.4.0-docs.zip', with the prefix 'git-docs/'.
`git archive -o latest.zip HEAD`::
Create a Zip archive that contains the contents of the latest
commit on the current branch. Note that the output format is
inferred by the extension of the output file.
`git archive -o latest.tar --prefix=build/ --add-file=configure --prefix= HEAD`::
Creates a tar archive that contains the contents of the latest
commit on the current branch with no prefix and the untracked
file 'configure' with the prefix 'build/'.
`git config tar.tar.xz.command "xz -c"`::
Configure a "tar.xz" format for making LZMA-compressed tarfiles.
You can use it specifying `--format=tar.xz`, or by creating an
output file like `-o foo.tar.xz`.
SEE ALSO
--------
linkgit:gitattributes[5]
GIT
---
Part of the linkgit:git[1] suite

75
app/src/main/assets/manpages/git-backfill.txt Normal file
View File

@@ -0,0 +1,75 @@
git-backfill(1)
===============
NAME
----
git-backfill - Download missing objects in a partial clone
SYNOPSIS
--------
[synopsis]
git backfill [--min-batch-size=<n>] [--[no-]sparse]
DESCRIPTION
-----------
Blobless partial clones are created using `git clone --filter=blob:none`
and then configure the local repository such that the Git client avoids
downloading blob objects unless they are required for a local operation.
This initially means that the clone and later fetches download reachable
commits and trees but no blobs. Later operations that change the `HEAD`
pointer, such as `git checkout` or `git merge`, may need to download
missing blobs in order to complete their operation.
In the worst cases, commands that compute blob diffs, such as `git blame`,
become very slow as they download the missing blobs in single-blob
requests to satisfy the missing object as the Git command needs it. This
leads to multiple download requests and no ability for the Git server to
provide delta compression across those objects.
The `git backfill` command provides a way for the user to request that
Git downloads the missing blobs (with optional filters) such that the
missing blobs representing historical versions of files can be downloaded
in batches. The `backfill` command attempts to optimize the request by
grouping blobs that appear at the same path, hopefully leading to good
delta compression in the packfile sent by the server.
In this way, `git backfill` provides a mechanism to break a large clone
into smaller chunks. Starting with a blobless partial clone with `git
clone --filter=blob:none` and then running `git backfill` in the local
repository provides a way to download all reachable objects in several
smaller network calls than downloading the entire repository at clone
time.
By default, `git backfill` downloads all blobs reachable from the `HEAD`
commit. This set can be restricted or expanded using various options.
THIS COMMAND IS EXPERIMENTAL. ITS BEHAVIOR MAY CHANGE IN THE FUTURE.
OPTIONS
-------
`--min-batch-size=<n>`::
Specify a minimum size for a batch of missing objects to request
from the server. This size may be exceeded by the last set of
blobs seen at a given path. The default minimum batch size is
50,000.
`--sparse`::
`--no-sparse`::
Only download objects if they appear at a path that matches the
current sparse-checkout. If the sparse-checkout feature is enabled,
then `--sparse` is assumed and can be disabled with `--no-sparse`.
You may also specify the commit limiting options from linkgit:git-rev-list[1].
SEE ALSO
--------
linkgit:git-clone[1],
linkgit:git-rev-list[1]
GIT
---
Part of the linkgit:git[1] suite

1358
app/src/main/assets/manpages/git-bisect-lk2009.txt Normal file
View File

File diff suppressed because it is too large Load Diff

527
app/src/main/assets/manpages/git-bisect.txt Normal file
View File

@@ -0,0 +1,527 @@
git-bisect(1)
=============
NAME
----
git-bisect - Use binary search to find the commit that introduced a bug
SYNOPSIS
--------
[verse]
'git bisect' start [--term-(bad|new)=<term-new> --term-(good|old)=<term-old>]
[--no-checkout] [--first-parent] [<bad> [<good>...]] [--] [<pathspec>...]
'git bisect' (bad|new|<term-new>) [<rev>]
'git bisect' (good|old|<term-old>) [<rev>...]
'git bisect' terms [--term-(good|old) | --term-(bad|new)]
'git bisect' skip [(<rev>|<range>)...]
'git bisect' next
'git bisect' reset [<commit>]
'git bisect' (visualize|view)
'git bisect' replay <logfile>
'git bisect' log
'git bisect' run <cmd> [<arg>...]
'git bisect' help
DESCRIPTION
-----------
This command uses a binary search algorithm to find which commit in
your project's history introduced a bug. You use it by first telling
it a "bad" commit that is known to contain the bug, and a "good"
commit that is known to be before the bug was introduced. Then `git
bisect` picks a commit between those two endpoints and asks you
whether the selected commit is "good" or "bad". It continues narrowing
down the range until it finds the exact commit that introduced the
change.
In fact, `git bisect` can be used to find the commit that changed
*any* property of your project; e.g., the commit that fixed a bug, or
the commit that caused a benchmark's performance to improve. To
support this more general usage, the terms "old" and "new" can be used
in place of "good" and "bad", or you can choose your own terms. See
section "Alternate terms" below for more information.
Basic bisect commands: start, bad, good
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As an example, suppose you are trying to find the commit that broke a
feature that was known to work in version `v2.6.13-rc2` of your
project. You start a bisect session as follows:
------------------------------------------------
$ git bisect start
$ git bisect bad # Current version is bad
$ git bisect good v2.6.13-rc2 # v2.6.13-rc2 is known to be good
------------------------------------------------
Once you have specified at least one bad and one good commit, `git
bisect` selects a commit in the middle of that range of history,
checks it out, and outputs something similar to the following:
------------------------------------------------
Bisecting: 675 revisions left to test after this (roughly 10 steps)
------------------------------------------------
You should now compile the checked-out version and test it. If that
version works correctly, type
------------------------------------------------
$ git bisect good
------------------------------------------------
If that version is broken, type
------------------------------------------------
$ git bisect bad
------------------------------------------------
Then `git bisect` will respond with something like
------------------------------------------------
Bisecting: 337 revisions left to test after this (roughly 9 steps)
------------------------------------------------
Keep repeating the process: compile the tree, test it, and depending
on whether it is good or bad run `git bisect good` or `git bisect bad`
to ask for the next commit that needs testing.
Eventually there will be no more revisions left to inspect, and the
command will print out a description of the first bad commit. The
reference `refs/bisect/bad` will be left pointing at that commit.
Bisect reset
~~~~~~~~~~~~
After a bisect session, to clean up the bisection state and return to
the original HEAD, issue the following command:
------------------------------------------------
$ git bisect reset
------------------------------------------------
By default, this will return your tree to the commit that was checked
out before `git bisect start`. (A new `git bisect start` will also do
that, as it cleans up the old bisection state.)
With an optional argument, you can return to a different commit
instead:
------------------------------------------------
$ git bisect reset <commit>
------------------------------------------------
For example, `git bisect reset bisect/bad` will check out the first
bad revision, while `git bisect reset HEAD` will leave you on the
current bisection commit and avoid switching commits at all.
Alternate terms
~~~~~~~~~~~~~~~
Sometimes you are not looking for the commit that introduced a
breakage, but rather for a commit that caused a change between some
other "old" state and "new" state. For example, you might be looking
for the commit that introduced a particular fix. Or you might be
looking for the first commit in which the source-code filenames were
finally all converted to your company's naming standard. Or whatever.
In such cases it can be very confusing to use the terms "good" and
"bad" to refer to "the state before the change" and "the state after
the change". So instead, you can use the terms "old" and "new",
respectively, in place of "good" and "bad". (But note that you cannot
mix "good" and "bad" with "old" and "new" in a single session.)
In this more general usage, you provide `git bisect` with a "new"
commit that has some property and an "old" commit that doesn't have that
property. Each time `git bisect` checks out a commit, you test if that
commit has the property. If it does, mark the commit as "new";
otherwise, mark it as "old". When the bisection is done, `git bisect`
will report which commit introduced the property.
To use "old" and "new" instead of "good" and bad, you must run `git
bisect start` without commits as argument and then run the following
commands to add the commits:
------------------------------------------------
git bisect old [<rev>]
------------------------------------------------
to indicate that a commit was before the sought change, or
------------------------------------------------
git bisect new [<rev>...]
------------------------------------------------
to indicate that it was after.
To get a reminder of the currently used terms, use
------------------------------------------------
git bisect terms
------------------------------------------------
You can get just the old term with `git bisect terms --term-old`
or `git bisect terms --term-good`; `git bisect terms --term-new`
and `git bisect terms --term-bad` can be used to learn how to call
the commits more recent than the sought change.
If you would like to use your own terms instead of "bad"/"good" or
"new"/"old", you can choose any names you like (except existing bisect
subcommands like `reset`, `start`, ...) by starting the
bisection using
------------------------------------------------
git bisect start --term-old <term-old> --term-new <term-new>
------------------------------------------------
For example, if you are looking for a commit that introduced a
performance regression, you might use
------------------------------------------------
git bisect start --term-old fast --term-new slow
------------------------------------------------
Or if you are looking for the commit that fixed a bug, you might use
------------------------------------------------
git bisect start --term-new fixed --term-old broken
------------------------------------------------
Then, use `git bisect <term-old>` and `git bisect <term-new>` instead
of `git bisect good` and `git bisect bad` to mark commits.
Bisect visualize/view
~~~~~~~~~~~~~~~~~~~~~
To see the currently remaining suspects in 'gitk', issue the following
command during the bisection process (the subcommand `view` can be used
as an alternative to `visualize`):
------------
$ git bisect visualize
------------
Git detects a graphical environment through various environment variables:
`DISPLAY`, which is set in X Window System environments on Unix systems.
`SESSIONNAME`, which is set under Cygwin in interactive desktop sessions.
`MSYSTEM`, which is set under Msys2 and Git for Windows.
`SECURITYSESSIONID`, which may be set on macOS in interactive desktop sessions.
If none of these environment variables is set, 'git log' is used instead.
You can also give command-line options such as `-p` and `--stat`.
------------
$ git bisect visualize --stat
------------
Bisect log and bisect replay
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
After having marked revisions as good or bad, issue the following
command to show what has been done so far:
------------
$ git bisect log
------------
If you discover that you made a mistake in specifying the status of a
revision, you can save the output of this command to a file, edit it to
remove the incorrect entries, and then issue the following commands to
return to a corrected state:
------------
$ git bisect reset
$ git bisect replay that-file
------------
Avoiding testing a commit
~~~~~~~~~~~~~~~~~~~~~~~~~
If, in the middle of a bisect session, you know that the suggested
revision is not a good one to test (e.g. it fails to build and you
know that the failure does not have anything to do with the bug you
are chasing), you can manually select a nearby commit and test that
one instead.
For example:
------------
$ git bisect good/bad # previous round was good or bad.
Bisecting: 337 revisions left to test after this (roughly 9 steps)
$ git bisect visualize # oops, that is uninteresting.
$ git reset --hard HEAD~3 # try 3 revisions before what
# was suggested
------------
Then compile and test the chosen revision, and afterwards mark
the revision as good or bad in the usual manner.
Bisect skip
~~~~~~~~~~~
Instead of choosing a nearby commit by yourself, you can ask Git to do
it for you by issuing the command:
------------
$ git bisect skip # Current version cannot be tested
------------
However, if you skip a commit adjacent to the one you are looking for,
Git will be unable to tell exactly which of those commits was the
first bad one.
You can also skip a range of commits, instead of just one commit,
using range notation. For example:
------------
$ git bisect skip v2.5..v2.6
------------
This tells the bisect process that no commit after `v2.5`, up to and
including `v2.6`, should be tested.
Note that if you also want to skip the first commit of the range you
would issue the command:
------------
$ git bisect skip v2.5 v2.5..v2.6
------------
This tells the bisect process that the commits between `v2.5` and
`v2.6` (inclusive) should be skipped.
Bisect next
~~~~~~~~~~~
Normally, after marking a revision as good or bad, Git automatically
computes and checks out the next revision to test. However, if you need to
explicitly request the next bisection step, you can use:
------------
$ git bisect next
------------
You might use this to resume the bisection process after interrupting it
by checking out a different revision.
Cutting down bisection by giving more parameters to bisect start
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can further cut down the number of trials, if you know what part of
the tree is involved in the problem you are tracking down, by specifying
pathspec parameters when issuing the `bisect start` command:
------------
$ git bisect start -- arch/i386 include/asm-i386
------------
If you know beforehand more than one good commit, you can narrow the
bisect space down by specifying all of the good commits immediately after
the bad commit when issuing the `bisect start` command:
------------
$ git bisect start v2.6.20-rc6 v2.6.20-rc4 v2.6.20-rc1 --
# v2.6.20-rc6 is bad
# v2.6.20-rc4 and v2.6.20-rc1 are good
------------
Bisect run
~~~~~~~~~~
If you have a script that can tell if the current source code is good
or bad, you can bisect by issuing the command:
------------
$ git bisect run my_script arguments
------------
Note that the script (`my_script` in the above example) should exit
with code 0 if the current source code is good/old, and exit with a
code between 1 and 127 (inclusive), except 125, if the current source
code is bad/new.
Any other exit code will abort the bisect process. It should be noted
that a program that terminates via `exit(-1)` leaves $? = 255, (see the
exit(3) manual page), as the value is chopped with `& 0377`.
The special exit code 125 should be used when the current source code
cannot be tested. If the script exits with this code, the current
revision will be skipped (see `git bisect skip` above). 125 was chosen
as the highest sensible value to use for this purpose, because 126 and 127
are used by POSIX shells to signal specific error status (127 is for
command not found, 126 is for command found but not executable--these
details do not matter, as they are normal errors in the script, as far as
`bisect run` is concerned).
You may often find that during a bisect session you want to have
temporary modifications (e.g. s/#define DEBUG 0/#define DEBUG 1/ in a
header file, or "revision that does not have this commit needs this
patch applied to work around another problem this bisection is not
interested in") applied to the revision being tested.
To cope with such a situation, after the inner 'git bisect' finds the
next revision to test, the script can apply the patch
before compiling, run the real test, and afterwards decide if the
revision (possibly with the needed patch) passed the test and then
rewind the tree to the pristine state. Finally the script should exit
with the status of the real test to let the `git bisect run` command loop
determine the eventual outcome of the bisect session.
OPTIONS
-------
--no-checkout::
+
Do not checkout the new working tree at each iteration of the bisection
process. Instead just update the reference named `BISECT_HEAD` to make
it point to the commit that should be tested.
+
This option may be useful when the test you would perform in each step
does not require a checked out tree.
+
If the repository is bare, `--no-checkout` is assumed.
--first-parent::
+
Follow only the first parent commit upon seeing a merge commit.
+
In detecting regressions introduced through the merging of a branch, the merge
commit will be identified as introduction of the bug and its ancestors will be
ignored.
+
This option is particularly useful in avoiding false positives when a merged
branch contained broken or non-buildable commits, but the merge itself was OK.
EXAMPLES
--------
* Automatically bisect a broken build between v1.2 and HEAD:
+
------------
$ git bisect start HEAD v1.2 -- # HEAD is bad, v1.2 is good
$ git bisect run make # "make" builds the app
$ git bisect reset # quit the bisect session
------------
* Automatically bisect a test failure between origin and HEAD:
+
------------
$ git bisect start HEAD origin -- # HEAD is bad, origin is good
$ git bisect run make test # "make test" builds and tests
$ git bisect reset # quit the bisect session
------------
* Automatically bisect a broken test case:
+
------------
$ cat ~/test.sh
#!/bin/sh
make || exit 125 # this skips broken builds
~/check_test_case.sh # does the test case pass?
$ git bisect start HEAD HEAD~10 -- # culprit is among the last 10
$ git bisect run ~/test.sh
$ git bisect reset # quit the bisect session
------------
+
Here we use a `test.sh` custom script. In this script, if `make`
fails, we skip the current commit.
`check_test_case.sh` should `exit 0` if the test case passes,
and `exit 1` otherwise.
+
It is safer if both `test.sh` and `check_test_case.sh` are
outside the repository to prevent interactions between the bisect,
make and test processes and the scripts.
* Automatically bisect with temporary modifications (hot-fix):
+
------------
$ cat ~/test.sh
#!/bin/sh
# tweak the working tree by merging the hot-fix branch
# and then attempt a build
if git merge --no-commit --no-ff hot-fix &&
make
then
# run project specific test and report its status
~/check_test_case.sh
status=$?
else
# tell the caller this is untestable
status=125
fi
# undo the tweak to allow clean flipping to the next commit
git reset --hard
# return control
exit $status
------------
+
This applies modifications from a hot-fix branch before each test run,
e.g. in case your build or test environment changed so that older
revisions may need a fix which newer ones have already. (Make sure the
hot-fix branch is based off a commit which is contained in all revisions
which you are bisecting, so that the merge does not pull in too much, or
use `git cherry-pick` instead of `git merge`.)
* Automatically bisect a broken test case:
+
------------
$ git bisect start HEAD HEAD~10 -- # culprit is among the last 10
$ git bisect run sh -c "make || exit 125; ~/check_test_case.sh"
$ git bisect reset # quit the bisect session
------------
+
This shows that you can do without a run script if you write the test
on a single line.
* Locate a good region of the object graph in a damaged repository
+
------------
$ git bisect start HEAD <known-good-commit> [ <boundary-commit> ... ] --no-checkout
$ git bisect run sh -c '
GOOD=$(git for-each-ref "--format=%(objectname)" refs/bisect/good-*) &&
git rev-list --objects BISECT_HEAD --not $GOOD >tmp.$$ &&
git pack-objects --stdout >/dev/null <tmp.$$
rc=$?
rm -f tmp.$$
test $rc = 0'
$ git bisect reset # quit the bisect session
------------
+
In this case, when 'git bisect run' finishes, bisect/bad will refer to a commit that
has at least one parent whose reachable graph is fully traversable in the sense
required by 'git pack objects'.
* Look for a fix instead of a regression in the code
+
------------
$ git bisect start
$ git bisect new HEAD # current commit is marked as new
$ git bisect old HEAD~10 # the tenth commit from now is marked as old
------------
+
or:
+
------------
$ git bisect start --term-old broken --term-new fixed
$ git bisect fixed
$ git bisect broken HEAD~10
------------
Getting help
~~~~~~~~~~~~
Use `git bisect` to get a short usage description, and `git bisect
help` or `git bisect -h` to get a long usage description.
SEE ALSO
--------
link:git-bisect-lk2009.html[Fighting regressions with git bisect],
linkgit:git-blame[1].
GIT
---
Part of the linkgit:git[1] suite

262
app/src/main/assets/manpages/git-blame.txt Normal file
View File

@@ -0,0 +1,262 @@
git-blame(1)
============
NAME
----
git-blame - Show what revision and author last modified each line of a file
SYNOPSIS
--------
[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>]
[ --contents <file> ] [<rev> | --reverse <rev>..<rev>] [--] <file>
DESCRIPTION
-----------
Annotates each line in the given file with information from the revision which
last modified the line. Optionally, start annotating from the given revision.
When specified one or more times, `-L` restricts annotation to the requested
lines.
The origin of lines is automatically followed across whole-file
renames (currently there is no option to turn the rename-following
off). To follow lines moved from one file to another, or to follow
lines that were copied and pasted from another file, etc., see the
`-C` and `-M` options.
The report does not tell you anything about lines which have been deleted or
replaced; you need to use a tool such as `git diff` or the "pickaxe"
interface briefly mentioned in the following paragraph.
Apart from supporting file annotation, Git also supports searching the
development history for when a code snippet occurred in a change. This makes it
possible to track when a code snippet was added to a file, moved or copied
between files, and eventually deleted or replaced. It works by searching for
a text string in the diff. A small example of the pickaxe interface
that searches for `blame_usage`:
-----------------------------------------------------------------------------
$ git log --pretty=oneline -S'blame_usage'
5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file>
ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output
-----------------------------------------------------------------------------
OPTIONS
-------
include::blame-options.adoc[]
`-c`::
Use the same output mode as linkgit:git-annotate[1] (Default: off).
`--score-debug`::
Include debugging information related to the movement of
lines between files (see `-C`) and lines moved within a
file (see `-M`). The first number listed is the score.
This is the number of alphanumeric characters detected
as having been moved between or within files. This must be above
a certain threshold for `git blame` to consider those lines
of code to have been moved.
`-f`::
`--show-name`::
Show the filename in the original commit. By default
the filename is shown if there is any line that came from a
file with a different name, due to rename detection.
`-n`::
`--show-number`::
Show the line number in the original commit (Default: off).
`-s`::
Suppress the author name and timestamp from the output.
`-e`::
`--show-email`::
Show the author email instead of the author name (Default: off).
This can also be controlled via the `blame.showEmail` config
option.
`-w`::
Ignore whitespace when comparing the parent's version and
the child's to find where the lines came from.
include::diff-algorithm-option.adoc[]
`--abbrev=<n>`::
Instead of using the default _7+1_ hexadecimal digits as the
abbreviated object name, use _<m>+1_ digits, where _<m>_ is at
least _<n>_ but ensures the commit object names are unique.
Note that 1 column
is used for a caret to mark the boundary commit.
THE DEFAULT FORMAT
------------------
When neither `--porcelain` nor `--incremental` option is specified,
`git blame` will output annotation for each line with:
- abbreviated object name for the commit the line came from;
- author ident (by default the author name and date, unless `-s` or `-e`
is specified); and
- line number
before the line contents.
THE PORCELAIN FORMAT
--------------------
In this format, each line is output after a header; the
header at the minimum has the first line which has:
- 40-byte SHA-1 of the commit the line is attributed to;
- the line number of the line in the original file;
- the line number of the line in the final file;
- on a line that starts a group of lines from a different
commit than the previous one, the number of lines in this
group. On subsequent lines this field is absent.
This header line is followed by the following information
at least once for each commit:
- the author name (`author`), email (`author-mail`), time
(`author-time`), and time zone (`author-tz`); similarly
for committer.
- the filename in the commit that the line is attributed to.
- the first line of the commit log message (`summary`).
The contents of the actual line are output after the above
header, prefixed by a _TAB_. This is to allow adding more
header elements later.
The porcelain format generally suppresses commit information that has
already been seen. For example, two lines that are blamed to the same
commit will both be shown, but the details for that commit will be shown
only once. Information which is specific to individual lines will not be
grouped together, like revs to be marked `ignored` or `unblamable`. This
is more efficient, but may require more state be kept by the reader. The
`--line-porcelain` option can be used to output full commit information
for each line, allowing simpler (but less efficient) usage like:
# count the number of lines attributed to each author
git blame --line-porcelain file |
sed -n 's/^author //p' |
sort | uniq -c | sort -rn
SPECIFYING RANGES
-----------------
Unlike `git blame` and `git annotate` in older versions of git, the extent
of the annotation can be limited to both line ranges and revision
ranges. The `-L` option, which limits annotation to a range of lines, may be
specified multiple times.
When you are interested in finding the origin for
lines 40-60 for file `foo`, you can use the `-L` option like so
(they mean the same thing -- both ask for 21 lines starting at
line 40):
git blame -L 40,60 foo
git blame -L 40,+21 foo
Also you can use a regular expression to specify the line range:
git blame -L '/^sub hello {/,/^}$/' foo
which limits the annotation to the body of the `hello` subroutine.
When you are not interested in changes older than version
v2.6.18, or changes older than 3 weeks, you can use revision
range specifiers similar to `git rev-list`:
git blame v2.6.18.. -- foo
git blame --since=3.weeks -- foo
When revision range specifiers are used to limit the annotation,
lines that have not changed since the range boundary (either the
commit v2.6.18 or the most recent commit that is more than 3
weeks old in the above example) are blamed for that range
boundary commit.
A particularly useful way is to see if an added file has lines
created by copy-and-paste from existing files. Sometimes this
indicates that the developer was being sloppy and did not
refactor the code properly. You can first find the commit that
introduced the file with:
git log --diff-filter=A --pretty=short -- foo
and then annotate the change between the commit and its
parents, using `commit^!` notation:
git blame -C -C -f $commit^! -- foo
INCREMENTAL OUTPUT
------------------
When called with `--incremental` option, the command outputs the
result as it is built. The output generally will talk about
lines touched by more recent commits first (i.e. the lines will
be annotated out of order) and is meant to be used by
interactive viewers.
The output format is similar to the Porcelain format, but it
does not contain the actual lines from the file that is being
annotated.
. Each blame entry always starts with a line of:
+
[synopsis]
<40-byte-hex-sha1> <sourceline> <resultline> <num-lines>
+
Line numbers count from 1.
. The first time that a commit shows up in the stream, it has various
other information about it printed out with a one-word tag at the
beginning of each line describing the extra commit information (author,
email, committer, dates, summary, etc.).
. Unlike the Porcelain format, the filename information is always
given and terminates the entry:
+
[synopsis]
filename <whitespace-quoted-filename-goes-here>
+
and thus it is really quite easy to parse for some line- and word-oriented
parser (which should be quite natural for most scripting languages).
+
[NOTE]
For people who do parsing: to make it more robust, just ignore any
lines between the first and last one (_<40-byte-hex-sha1>_ and `filename`
lines) where you do not recognize the tag words (or care about that particular
one) at the beginning of the "extended information" lines. That way, if
there is ever added information (like the commit encoding or extended
commit commentary), a blame viewer will not care.
MAPPING AUTHORS
---------------
See linkgit:gitmailmap[5].
CONFIGURATION
-------------
include::includes/cmd-config-section-all.adoc[]
include::config/blame.adoc[]
SEE ALSO
--------
linkgit:git-annotate[1]
GIT
---
Part of the linkgit:git[1] suite

429
app/src/main/assets/manpages/git-branch.txt Normal file
View File

@@ -0,0 +1,429 @@
git-branch(1)
=============
NAME
----
git-branch - List, create, or delete branches
SYNOPSIS
--------
[synopsis]
git branch [--color[=<when>] | --no-color] [--show-current]
[-v [--abbrev=<n> | --no-abbrev]]
[--column[=<options>] | --no-column] [--sort=<key>]
[--merged [<commit>]] [--no-merged [<commit>]]
[--contains [<commit>]] [--no-contains [<commit>]]
[--points-at <object>] [--format=<format>]
[(-r|--remotes) | (-a|--all)]
[--list] [<pattern>...]
git branch [--track[=(direct|inherit)] | --no-track] [-f]
[--recurse-submodules] <branch-name> [<start-point>]
git branch (--set-upstream-to=<upstream>|-u <upstream>) [<branch-name>]
git branch --unset-upstream [<branch-name>]
git branch (-m|-M) [<old-branch>] <new-branch>
git branch (-c|-C) [<old-branch>] <new-branch>
git branch (-d|-D) [-r] <branch-name>...
git branch --edit-description [<branch-name>]
DESCRIPTION
-----------
If `--list` is given, or if there are no non-option arguments, existing
branches are listed; the current branch will be highlighted in green and
marked with an asterisk. Any branches checked out in linked worktrees will
be highlighted in cyan and marked with a plus sign. Option `-r` causes the
remote-tracking branches to be listed,
and option `-a` shows both local and remote branches.
If a `<pattern>`
is given, it is used as a shell wildcard to restrict the output to
matching branches. If multiple patterns are given, a branch is shown if
it matches any of the patterns.
Note that when providing a
`<pattern>`, you must use `--list`; otherwise the command may be interpreted
as branch creation.
With `--contains`, shows only the branches that contain the named commit
(in other words, the branches whose tip commits are descendants of the
named commit), `--no-contains` inverts it. With `--merged`, only branches
merged into the named commit (i.e. the branches whose tip commits are
reachable from the named commit) will be listed. With `--no-merged` only
branches not merged into the named commit will be listed. If the _<commit>_
argument is missing it defaults to `HEAD` (i.e. the tip of the current
branch).
The command's second form creates a new branch head named _<branch-name>_
which points to the current `HEAD`, or _<start-point>_ if given. As a
special case, for _<start-point>_, you may use `<rev-A>...<rev-B>` as a
shortcut for the merge base of _<rev-A>_ and _<rev-B>_ if there is exactly
one merge base. You can leave out at most one of _<rev-A>_ and _<rev-B>_,
in which case it defaults to `HEAD`.
Note that this will create the new branch, but it will not switch the
working tree to it; use `git switch <new-branch>` to switch to the
new branch.
When a local branch is started off a remote-tracking branch, Git sets up the
branch (specifically the `branch.<name>.remote` and `branch.<name>.merge`
configuration entries) so that `git pull` will appropriately merge from
the remote-tracking branch. This behavior may be changed via the global
`branch.autoSetupMerge` configuration flag. That setting can be
overridden by using the `--track` and `--no-track` options, and
changed later using `git branch --set-upstream-to`.
With a `-m` or `-M` option, _<old-branch>_ will be renamed to _<new-branch>_.
If _<old-branch>_ had a corresponding reflog, it is renamed to match
_<new-branch>_, and a reflog entry is created to remember the branch
renaming. If _<new-branch>_ exists, `-M` must be used to force the rename
to happen.
The `-c` and `-C` options have the exact same semantics as `-m` and
`-M`, except instead of the branch being renamed, it will be copied to a
new name, along with its config and reflog.
With a `-d` or `-D` option, _<branch-name>_ will be deleted. You may
specify more than one branch for deletion. If the branch currently
has a reflog then the reflog will also be deleted.
Use `-r` together with `-d` to delete remote-tracking branches. Note, that it
only makes sense to delete remote-tracking branches if they no longer exist
in the remote repository or if `git fetch` was configured not to fetch
them again. See also the `prune` subcommand of linkgit:git-remote[1] for a
way to clean up all obsolete remote-tracking branches.
OPTIONS
-------
`-d`::
`--delete`::
Delete a branch. The branch must be fully merged in its
upstream branch, or in `HEAD` if no upstream was set with
`--track` or `--set-upstream-to`.
`-D`::
Shortcut for `--delete --force`.
`--create-reflog`::
Create the branch's reflog. This activates recording of
all changes made to the branch ref, enabling use of date
based sha1 expressions such as `<branch-name>@{yesterday}`.
Note that in non-bare repositories, reflogs are usually
enabled by default by the `core.logAllRefUpdates` config option.
The negated form `--no-create-reflog` only overrides an earlier
`--create-reflog`, but currently does not negate the setting of
`core.logAllRefUpdates`.
`-f`::
`--force`::
Reset _<branch-name>_ to _<start-point>_, even if _<branch-name>_ exists
already. Without `-f`, `git branch` refuses to change an existing branch.
In combination with `-d` (or `--delete`), allow deleting the
branch irrespective of its merged status, or whether it even
points to a valid commit. In combination with
`-m` (or `--move`), allow renaming the branch even if the new
branch name already exists, the same applies for `-c` (or `--copy`).
+
Note that `git branch -f <branch-name> [<start-point>]`, even with `-f`,
refuses to change an existing branch _<branch-name>_ that is checked out
in another worktree linked to the same repository.
`-m`::
`--move`::
Move/rename a branch, together with its config and reflog.
`-M`::
Shortcut for `--move --force`.
`-c`::
`--copy`::
Copy a branch, together with its config and reflog.
`-C`::
Shortcut for `--copy --force`.
`--color[=<when>]`::
Color branches to highlight current, local, and
remote-tracking branches.
The value must be `always` (the default), `never`, or `auto`.
`--no-color`::
Turn off branch colors, even when the configuration file gives the
default to color output.
Same as `--color=never`.
`-i`::
`--ignore-case`::
Sorting and filtering branches are case insensitive.
`--omit-empty`::
Do not print a newline after formatted refs where the format expands
to the empty string.
`--column[=<options>]`::
`--no-column`::
Display branch listing in columns. See configuration variable
`column.branch` for option syntax. `--column` and `--no-column`
without options are equivalent to `always` and `never` respectively.
+
This option is only applicable in non-verbose mode.
`--sort=<key>`::
Sort based on _<key>_. Prefix `-` to sort in descending
order of the value. You may use the `--sort=<key>` option
multiple times, in which case the last key becomes the primary
key. The keys supported are the same as those in linkgit:git-for-each-ref[1].
Sort order defaults to the value configured for the
`branch.sort` variable if it exists, or to sorting based on the
full refname (including `refs/...` prefix). This lists
detached `HEAD` (if present) first, then local branches and
finally remote-tracking branches. See linkgit:git-config[1].
`-r`::
`--remotes`::
List or delete (if used with `-d`) the remote-tracking branches.
Combine with `--list` to match the optional pattern(s).
`-a`::
`--all`::
List both remote-tracking branches and local branches.
Combine with `--list` to match optional pattern(s).
`-l`::
`--list`::
List branches. With optional `<pattern>...`, e.g. `git
branch --list 'maint-*'`, list only the branches that match
the pattern(s).
`--show-current`::
Print the name of the current branch. In detached `HEAD` state,
nothing is printed.
`-v`::
`-vv`::
`--verbose`::
When in list mode,
show sha1 and commit subject line for each head, along with
relationship to upstream branch (if any). If given twice, print
the path of the linked worktree (if any) and the name of the upstream
branch, as well (see also `git remote show <remote>`). Note that the
current worktree's `HEAD` will not have its path printed (it will always
be your current directory).
`-q`::
`--quiet`::
Be more quiet when creating or deleting a branch, suppressing
non-error messages.
`--abbrev=<n>`::
In the verbose listing that show the commit object name,
show the shortest prefix that is at least _<n>_ hexdigits
long that uniquely refers the object.
The default value is 7 and can be overridden by the `core.abbrev`
config option.
`--no-abbrev`::
Display the full sha1s in the output listing rather than abbreviating them.
`-t`::
`--track[=(direct|inherit)]`::
When creating a new branch, set up `branch.<name>.remote` and
`branch.<name>.merge` configuration entries to set "upstream" tracking
configuration for the new branch. This
configuration will tell git to show the relationship between the
two branches in `git status` and `git branch -v`. Furthermore,
it directs `git pull` without arguments to pull from the
upstream when the new branch is checked out.
+
The exact upstream branch is chosen depending on the optional argument:
`-t`, `--track`, or `--track=direct` means to use the start-point branch
itself as the upstream; `--track=inherit` means to copy the upstream
configuration of the start-point branch.
+
The `branch.autoSetupMerge` configuration variable specifies how `git switch`,
`git checkout` and `git branch` should behave when neither `--track` nor
`--no-track` are specified:
+
The default option, `true`, behaves as though `--track=direct`
were given whenever the start-point is a remote-tracking branch.
`false` behaves as if `--no-track` were given. `always` behaves as though
`--track=direct` were given. `inherit` behaves as though `--track=inherit`
were given. `simple` behaves as though `--track=direct` were given only when
the _<start-point>_ is a remote-tracking branch and the new branch has the same
name as the remote branch.
+
See linkgit:git-pull[1] and linkgit:git-config[1] for additional discussion on
how the `branch.<name>.remote` and `branch.<name>.merge` options are used.
`--no-track`::
Do not set up "upstream" configuration, even if the
`branch.autoSetupMerge` configuration variable is set.
`--recurse-submodules`::
THIS OPTION IS EXPERIMENTAL! Cause the current command to
recurse into submodules if `submodule.propagateBranches` is
enabled. See `submodule.propagateBranches` in
linkgit:git-config[1]. Currently, only branch creation is
supported.
+
When used in branch creation, a new branch _<branch-name>_ will be created
in the superproject and all of the submodules in the superproject's
_<start-point>_. In submodules, the branch will point to the submodule
commit in the superproject's _<start-point>_ but the branch's tracking
information will be set up based on the submodule's branches and remotes
e.g. `git branch --recurse-submodules topic origin/main` will create the
submodule branch "topic" that points to the submodule commit in the
superproject's "origin/main", but tracks the submodule's "origin/main".
`--set-upstream`::
As this option had confusing syntax, it is no longer supported.
Please use `--track` or `--set-upstream-to` instead.
`-u <upstream>`::
`--set-upstream-to=<upstream>`::
Set up _<branch-name>_'s tracking information so _<upstream>_ is
considered _<branch-name>_'s upstream branch. If no _<branch-name>_
is specified, then it defaults to the current branch.
`--unset-upstream`::
Remove the upstream information for _<branch-name>_. If no branch
is specified it defaults to the current branch.
`--edit-description`::
Open an editor and edit the text to explain what the branch is
for, to be used by various other commands (e.g. `format-patch`,
`request-pull`, and `merge` (if enabled)). Multi-line explanations
may be used.
`--contains [<commit>]`::
Only list branches which contain _<commit>_ (`HEAD`
if not specified). Implies `--list`.
`--no-contains [<commit>]`::
Only list branches which don't contain _<commit>_
(`HEAD` if not specified). Implies `--list`.
`--merged [<commit>]`::
Only list branches whose tips are reachable from
_<commit>_ (`HEAD` if not specified). Implies `--list`.
`--no-merged [<commit>]`::
Only list branches whose tips are not reachable from
_<commit>_ (`HEAD` if not specified). Implies `--list`.
`--points-at <object>`::
Only list branches of _<object>_.
`--format <format>`::
A string that interpolates `%(fieldname)` from a branch ref being shown
and the object it points at. _<format>_ is the same as
that of linkgit:git-for-each-ref[1].
_<branch-name>_::
The name of the branch to create or delete.
The new branch name must pass all checks defined by
linkgit:git-check-ref-format[1]. Some of these checks
may restrict the characters allowed in a branch name.
_<start-point>_::
The new branch head will point to this commit. It may be
given as a branch name, a commit-id, or a tag. If this
option is omitted, the current `HEAD` will be used instead.
_<old-branch>_::
The name of an existing branch. If this option is omitted,
the name of the current branch will be used instead.
_<new-branch>_::
The new name for an existing branch. The same restrictions as for
_<branch-name>_ apply.
CONFIGURATION
-------------
`pager.branch` is only respected when listing branches, i.e., when
`--list` is used or implied. The default is to use a pager.
See linkgit:git-config[1].
include::includes/cmd-config-section-rest.adoc[]
include::config/branch.adoc[]
EXAMPLES
--------
Start development from a known tag::
+
------------
$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
$ cd my2.6
$ git branch my2.6.14 v2.6.14 <1>
$ git switch my2.6.14
------------
+
<1> This step and the next one could be combined into a single step with
"checkout -b my2.6.14 v2.6.14".
Delete an unneeded branch::
+
------------
$ git clone git://git.kernel.org/.../git.git my.git
$ cd my.git
$ git branch -d -r origin/todo origin/html origin/man <1>
$ git branch -D test <2>
------------
+
<1> Delete the remote-tracking branches "todo", "html" and "man". The next
`git fetch` or `git pull` will create them again unless you configure them not to.
See linkgit:git-fetch[1].
<2> Delete the "test" branch even if the "master" branch (or whichever branch
is currently checked out) does not have all commits from the test branch.
Listing branches from a specific remote::
+
------------
$ git branch -r -l '<remote>/<pattern>' <1>
$ git for-each-ref 'refs/remotes/<remote>/<pattern>' <2>
------------
+
<1> Using `-a` would conflate _<remote>_ with any local branches you happen to
have been prefixed with the same _<remote>_ pattern.
<2> `for-each-ref` can take a wide range of options. See linkgit:git-for-each-ref[1]
Patterns will normally need quoting.
NOTES
-----
If you are creating a branch that you want to switch to immediately,
it is easier to use the `git switch` command with its `-c` option to
do the same thing with a single command.
The options `--contains`, `--no-contains`, `--merged` and `--no-merged`
serve four related but different purposes:
- `--contains <commit>` is used to find all branches which will need
special attention if _<commit>_ were to be rebased or amended, since those
branches contain the specified _<commit>_.
- `--no-contains <commit>` is the inverse of that, i.e. branches that don't
contain the specified _<commit>_.
- `--merged` is used to find all branches which can be safely deleted,
since those branches are fully contained by `HEAD`.
- `--no-merged` is used to find branches which are candidates for merging
into `HEAD`, since those branches are not fully contained by `HEAD`.
include::ref-reachability-filters.adoc[]
SEE ALSO
--------
linkgit:git-check-ref-format[1],
linkgit:git-fetch[1],
linkgit:git-remote[1],
link:user-manual.html#what-is-a-branch["Understanding history: What is
a branch?"] in the Git User's Manual.
GIT
---
Part of the linkgit:git[1] suite

77
app/src/main/assets/manpages/git-bugreport.txt Normal file
View File

@@ -0,0 +1,77 @@
git-bugreport(1)
================
NAME
----
git-bugreport - Collect information for user to file a bug report
SYNOPSIS
--------
[verse]
'git bugreport' [(-o | --output-directory) <path>]
[(-s | --suffix) <format> | --no-suffix]
[--diagnose[=<mode>]]
DESCRIPTION
-----------
Collects information about the user's machine, Git client, and repository
state, in addition to a form requesting information about the behavior the
user observed, and stores it in a single text file which the user can then
share, for example to the Git mailing list, in order to report an observed
bug.
The following information is requested from the user:
- Reproduction steps
- Expected behavior
- Actual behavior
The following information is captured automatically:
- 'git version --build-options'
- uname sysname, release, version, and machine strings
- Compiler-specific info string
- A list of enabled hooks
- $SHELL
Additional information may be gathered into a separate zip archive using the
`--diagnose` option, and can be attached alongside the bugreport document to
provide additional context to readers.
This tool is invoked via the typical Git setup process, which means that in some
cases, it might not be able to launch - for example, if a relevant config file
is unreadable. In this kind of scenario, it may be helpful to manually gather
the kind of information listed above when manually asking for help.
OPTIONS
-------
-o <path>::
--output-directory <path>::
Place the resulting bug report file in `<path>` instead of the current
directory.
-s <format>::
--suffix <format>::
--no-suffix::
Specify an alternate suffix for the bugreport name, to create a file
named 'git-bugreport-<formatted-suffix>'. This should take the form of a
strftime(3) format string; the current local time will be used.
`--no-suffix` disables the suffix and the file is just named
`git-bugreport` without any disambiguation measure.
--no-diagnose::
--diagnose[=<mode>]::
Create a zip archive of supplemental information about the user's
machine, Git client, and repository state. The archive is written to the
same output directory as the bug report and is named
'git-diagnostics-<formatted-suffix>'.
+
Without `mode` specified, the diagnostic archive will contain the default set of
statistics reported by `git diagnose`. An optional `mode` value may be specified
to change which information is included in the archive. See
linkgit:git-diagnose[1] for the list of valid values for `mode` and details
about their usage.
GIT
---
Part of the linkgit:git[1] suite

372
app/src/main/assets/manpages/git-bundle.txt Normal file
View File

@@ -0,0 +1,372 @@
git-bundle(1)
=============
NAME
----
git-bundle - Move objects and refs by archive
SYNOPSIS
--------
[verse]
'git bundle' create [-q | --quiet | --progress]
[--version=<version>] <file> <git-rev-list-args>
'git bundle' verify [-q | --quiet] <file>
'git bundle' list-heads <file> [<refname>...]
'git bundle' unbundle [--progress] <file> [<refname>...]
DESCRIPTION
-----------
Create, unpack, and manipulate "bundle" files. Bundles are used for
the "offline" transfer of Git objects without an active "server"
sitting on the other side of the network connection.
They can be used to create both incremental and full backups of a
repository (see the "full backup" example in "EXAMPLES"), and to relay
the state of the references in one repository to another (see the second
example).
Git commands that fetch or otherwise "read" via protocols such as
`ssh://` and `https://` can also operate on bundle files. It is
possible linkgit:git-clone[1] a new repository from a bundle, to use
linkgit:git-fetch[1] to fetch from one, and to list the references
contained within it with linkgit:git-ls-remote[1]. There's no
corresponding "write" support, i.e. a 'git push' into a bundle is not
supported.
BUNDLE FORMAT
-------------
Bundles are `.pack` files (see linkgit:git-pack-objects[1]) with a
header indicating what references are contained within the bundle.
Like the packed archive format itself bundles can either be
self-contained, or be created using exclusions.
See the "OBJECT PREREQUISITES" section below.
Bundles created using revision exclusions are "thin packs" created
using the `--thin` option to linkgit:git-pack-objects[1], and
unbundled using the `--fix-thin` option to linkgit:git-index-pack[1].
There is no option to create a "thick pack" when using revision
exclusions, and users should not be concerned about the difference. By
using "thin packs", bundles created using exclusions are smaller in
size. That they're "thin" under the hood is merely noted here as a
curiosity, and as a reference to other documentation.
See linkgit:gitformat-bundle[5] for more details and the discussion of
"thin pack" in linkgit:gitformat-pack[5] for further details.
OPTIONS
-------
create [options] <file> <git-rev-list-args>::
Used to create a bundle named 'file'. This requires the
'<git-rev-list-args>' arguments to define the bundle contents.
'options' contains the options specific to the 'git bundle create'
subcommand. If 'file' is `-`, the bundle is written to stdout.
verify <file>::
Used to check that a bundle file is valid and will apply
cleanly to the current repository. This includes checks on the
bundle format itself as well as checking that the prerequisite
commits exist and are fully linked in the current repository.
Then, 'git bundle' prints a list of missing commits, if any.
Finally, information about additional capabilities, such as "object
filter", is printed. See "Capabilities" in linkgit:gitformat-bundle[5]
for more information. The exit code is zero for success, but will
be nonzero if the bundle file is invalid. If 'file' is `-`, the
bundle is read from stdin.
list-heads <file>::
Lists the references defined in the bundle. If followed by a
list of references, only references matching those given are
printed out. If 'file' is `-`, the bundle is read from stdin.
unbundle <file>::
Passes the objects in the bundle to 'git index-pack'
for storage in the repository, then prints the names of all
defined references. If a list of references is given, only
references matching those in the list are printed. This command is
really plumbing, intended to be called only by 'git fetch'.
If 'file' is `-`, the bundle is read from stdin.
<git-rev-list-args>::
A list of arguments, acceptable to 'git rev-parse' and
'git rev-list' (and containing a named ref, see SPECIFYING REFERENCES
below), that specifies the specific objects and references
to transport. For example, `master~10..master` causes the
current master reference to be packaged along with all objects
added since its 10th ancestor commit. There is no explicit
limit to the number of references and objects that may be
packaged.
[<refname>...]::
A list of references used to limit the references reported as
available. This is principally of use to 'git fetch', which
expects to receive only those references asked for and not
necessarily everything in the pack (in this case, 'git bundle' acts
like 'git fetch-pack').
--progress::
Progress status is reported on the standard error stream
by default when it is attached to a terminal, unless -q
is specified. This flag forces progress status even if
the standard error stream is not directed to a terminal.
--version=<version>::
Specify the bundle version. Version 2 is the older format and can only be
used with SHA-1 repositories; the newer version 3 contains capabilities that
permit extensions. The default is the oldest supported format, based on the
hash algorithm in use.
-q::
--quiet::
This flag makes the command not to report its progress
on the standard error stream.
SPECIFYING REFERENCES
---------------------
Revisions must be accompanied by reference names to be packaged in a
bundle. Alternatively `--all` can be used to package all refs.
More than one reference may be packaged, and more than one set of prerequisite objects can
be specified. The objects packaged are those not contained in the
union of the prerequisites.
The 'git bundle create' command resolves the reference names for you
using the same rules as `git rev-parse --abbrev-ref=loose`. Each
prerequisite can be specified explicitly (e.g. `^master~10`), or implicitly
(e.g. `master~10..master`, `--since=10.days.ago master`).
All of these simple cases are OK (assuming we have a "master" and
"next" branch):
----------------
$ git bundle create master.bundle master
$ echo master | git bundle create master.bundle --stdin
$ git bundle create master-and-next.bundle master next
$ (echo master; echo next) | git bundle create master-and-next.bundle --stdin
----------------
And so are these (and the same but omitted `--stdin` examples):
----------------
$ git bundle create recent-master.bundle master~10..master
$ git bundle create recent-updates.bundle master~10..master next~5..next
----------------
A revision name or a range whose right-hand-side cannot be resolved to
a reference is not accepted:
----------------
$ git bundle create HEAD.bundle $(git rev-parse HEAD)
fatal: Refusing to create empty bundle.
$ git bundle create master-yesterday.bundle master~10..master~5
fatal: Refusing to create empty bundle.
----------------
OBJECT PREREQUISITES
--------------------
When creating bundles it is possible to create a self-contained bundle
that can be unbundled in a repository with no common history, as well
as providing negative revisions to exclude objects needed in the
earlier parts of the history.
Feeding a revision such as `new` to `git bundle create` will create a
bundle file that contains all the objects reachable from the revision
`new`. That bundle can be unbundled in any repository to obtain a full
history that leads to the revision `new`:
----------------
$ git bundle create full.bundle new
----------------
A revision range such as `old..new` will produce a bundle file that
will require the revision `old` (and any objects reachable from it)
to exist for the bundle to be "unbundle"-able:
----------------
$ git bundle create full.bundle old..new
----------------
A self-contained bundle without any prerequisites can be extracted
into anywhere, even into an empty repository, or be cloned from
(i.e., `new`, but not `old..new`).
It is okay to err on the side of caution, causing the bundle file
to contain objects already in the destination, as these are ignored
when unpacking at the destination.
If you want to provide the same set of refs that a clone directly
from the source repository would get, use `--branches --tags` for
the `<git-rev-list-args>`.
The 'git bundle verify' command can be used to check whether your
recipient repository has the required prerequisite commits for a
bundle.
EXAMPLES
--------
We'll discuss two cases:
1. Taking a full backup of a repository
2. Transferring the history of a repository to another machine when the
two machines have no direct connection
First let's consider a full backup of the repository. The following
command will take a full backup of the repository in the sense that all
refs are included in the bundle:
----------------
$ git bundle create backup.bundle --all
----------------
But note again that this is only for the refs, i.e. you will only
include refs and commits reachable from those refs. You will not
include other local state, such as the contents of the index, working
tree, the stash, per-repository configuration, hooks, etc.
You can later recover that repository by using for example
linkgit:git-clone[1]:
----------------
$ git clone backup.bundle <new directory>
----------------
For the next example, assume you want to transfer the history from a
repository R1 on machine A to another repository R2 on machine B.
For whatever reason, direct connection between A and B is not allowed,
but we can move data from A to B via some mechanism (CD, email, etc.).
We want to update R2 with development made on the branch master in R1.
To bootstrap the process, you can first create a bundle that does not have
any prerequisites. You can use a tag to remember up to what commit you last
processed, in order to make it easy to later update the other repository
with an incremental bundle:
----------------
machineA$ cd R1
machineA$ git bundle create file.bundle master
machineA$ git tag -f lastR2bundle master
----------------
Then you transfer file.bundle to the target machine B. Because this
bundle does not require any existing object to be extracted, you can
create a new repository on machine B by cloning from it:
----------------
machineB$ git clone -b master /home/me/tmp/file.bundle R2
----------------
This will define a remote called "origin" in the resulting repository that
lets you fetch and pull from the bundle. The $GIT_DIR/config file in R2 will
have an entry like this:
------------------------
[remote "origin"]
url = /home/me/tmp/file.bundle
fetch = refs/heads/*:refs/remotes/origin/*
------------------------
To update the resulting mine.git repository, you can fetch or pull after
replacing the bundle stored at /home/me/tmp/file.bundle with incremental
updates.
After working some more in the original repository, you can create an
incremental bundle to update the other repository:
----------------
machineA$ cd R1
machineA$ git bundle create file.bundle lastR2bundle..master
machineA$ git tag -f lastR2bundle master
----------------
You then transfer the bundle to the other machine to replace
/home/me/tmp/file.bundle, and pull from it.
----------------
machineB$ cd R2
machineB$ git pull
----------------
If you know up to what commit the intended recipient repository should
have the necessary objects, you can use that knowledge to specify the
prerequisites, giving a cut-off point to limit the revisions and objects that go
in the resulting bundle. The previous example used the lastR2bundle tag
for this purpose, but you can use any other options that you would give to
the linkgit:git-log[1] command. Here are more examples:
You can use a tag that is present in both:
----------------
$ git bundle create mybundle v1.0.0..master
----------------
You can use a prerequisite based on time:
----------------
$ git bundle create mybundle --since=10.days master
----------------
You can use the number of commits:
----------------
$ git bundle create mybundle -10 master
----------------
You can run `git-bundle verify` to see if you can extract from a bundle
that was created with a prerequisite:
----------------
$ git bundle verify mybundle
----------------
This will list what commits you must have in order to extract from the
bundle and will error out if you do not have them.
A bundle from a recipient repository's point of view is just like a
regular repository which it fetches or pulls from. You can, for example, map
references when fetching:
----------------
$ git fetch mybundle master:localRef
----------------
You can also see what references it offers:
----------------
$ git ls-remote mybundle
----------------
DISCUSSION
----------
A naive way to make a full backup of a repository is to use something to
the effect of `cp -r <repo> <destination>`. This is discouraged since
the repository could be written to during the copy operation. In turn
some files at `<destination>` could be corrupted.
This is why it is recommended to use Git tooling for making repository
backups, either with this command or with e.g. linkgit:git-clone[1].
But keep in mind that these tools will not help you backup state other
than refs and commits. In other words they will not help you backup
contents of the index, working tree, the stash, per-repository
configuration, hooks, etc.
See also linkgit:gitfaq[7], section "TRANSFERS" for a discussion of the
problems associated with file syncing across systems.
FILE FORMAT
-----------
See linkgit:gitformat-bundle[5].
GIT
---
Part of the linkgit:git[1] suite

449
app/src/main/assets/manpages/git-cat-file.txt Normal file
View File

@@ -0,0 +1,449 @@
git-cat-file(1)
===============
NAME
----
git-cat-file - Provide contents or details of repository objects
SYNOPSIS
--------
[verse]
'git cat-file' <type> <object>
'git cat-file' (-e | -p | -t | -s) <object>
'git cat-file' (--textconv | --filters)
[<rev>:<path|tree-ish> | --path=<path|tree-ish> <rev>]
'git cat-file' (--batch | --batch-check | --batch-command) [--batch-all-objects]
[--buffer] [--follow-symlinks] [--unordered]
[--textconv | --filters] [-Z]
DESCRIPTION
-----------
Output the contents or other properties such as size, type or delta
information of one or more objects.
This command can operate in two modes, depending on whether an option
from the `--batch` family is specified.
In non-batch mode, the command provides information on an object
named on the command line.
In batch mode, arguments are read from standard input.
OPTIONS
-------
<object>::
The name of the object to show.
For a more complete list of ways to spell object names, see
the "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
-t::
Instead of the content, show the object type identified by
`<object>`.
-s::
Instead of the content, show the object size identified by
`<object>`. If used with `--use-mailmap` option, will show
the size of updated object after replacing idents using the
mailmap mechanism.
-e::
Exit with zero status if `<object>` exists and is a valid
object. If `<object>` is of an invalid format, exit with non-zero
status and emit an error on stderr.
-p::
Pretty-print the contents of `<object>` based on its type.
<type>::
Typically this matches the real type of `<object>` but asking
for a type that can trivially be dereferenced from the given
`<object>` is also permitted. An example is to ask for a
"tree" with `<object>` being a commit object that contains it,
or to ask for a "blob" with `<object>` being a tag object that
points at it.
--mailmap::
--no-mailmap::
--use-mailmap::
--no-use-mailmap::
Use mailmap file to map author, committer and tagger names
and email addresses to canonical real names and email addresses.
See linkgit:git-shortlog[1].
--textconv::
Show the content as transformed by a textconv filter. In this case,
`<object>` has to be of the form `<tree-ish>:<path>`, or `:<path>` in
order to apply the filter to the content recorded in the index at
`<path>`.
--filters::
Show the content as converted by the filters configured in
the current working tree for the given `<path>` (i.e. smudge filters,
end-of-line conversion, etc). In this case, `<object>` has to be of
the form `<tree-ish>:<path>`, or `:<path>`.
--filter=<filter-spec>::
--no-filter::
Omit objects from the list of printed objects. This can only be used in
combination with one of the batched modes. Excluded objects that have
been explicitly requested via any of the batch modes that read objects
via standard input (`--batch`, `--batch-check`) will be reported as
"filtered". Excluded objects in `--batch-all-objects` mode will not be
printed at all. The '<filter-spec>' may be one of the following:
+
The form '--filter=blob:none' omits all blobs.
+
The form '--filter=blob:limit=<n>[kmg]' omits blobs of size at least n
bytes or units. n may be zero. The suffixes k, m, and g can be used to name
units in KiB, MiB, or GiB. For example, 'blob:limit=1k' is the same as
'blob:limit=1024'.
+
The form '--filter=object:type=(tag|commit|tree|blob)' omits all objects which
are not of the requested type.
--path=<path>::
For use with `--textconv` or `--filters`, to allow specifying an object
name and a path separately, e.g. when it is difficult to figure out
the revision from which the blob came.
--batch::
--batch=<format>::
Print object information and contents for each object provided
on stdin. May not be combined with any other options or arguments
except `--textconv`, `--filters`, or `--use-mailmap`.
+
--
* When used with `--textconv` or `--filters`, the input lines
must specify the path, separated by whitespace. See the section
`BATCH OUTPUT` below for details.
* When used with `--use-mailmap`, for commit and tag objects, the
contents part of the output shows the identities replaced using the
mailmap mechanism, while the information part of the output shows
the size of the object as if it actually recorded the replacement
identities.
--
--batch-check::
--batch-check=<format>::
Print object information for each object provided on stdin. May not be
combined with any other options or arguments except `--textconv`, `--filters`
or `--use-mailmap`.
+
--
* When used with `--textconv` or `--filters`, the input lines must
specify the path, separated by whitespace. See the section
`BATCH OUTPUT` below for details.
* When used with `--use-mailmap`, for commit and tag objects, the
printed object information shows the size of the object as if the
identities recorded in it were replaced by the mailmap mechanism.
--
--batch-command::
--batch-command=<format>::
Enter a command mode that reads commands and arguments from stdin. May
only be combined with `--buffer`, `--textconv`, `--use-mailmap` or
`--filters`.
+
--
* When used with `--textconv` or `--filters`, the input lines must
specify the path, separated by whitespace. See the section
`BATCH OUTPUT` below for details.
* When used with `--use-mailmap`, for commit and tag objects, the
`contents` command shows the identities replaced using the
mailmap mechanism, while the `info` command shows the size
of the object as if it actually recorded the replacement
identities.
--
+
`--batch-command` recognizes the following commands:
+
--
contents <object>::
Print object contents for object reference `<object>`. This corresponds to
the output of `--batch`.
info <object>::
Print object info for object reference `<object>`. This corresponds to the
output of `--batch-check`.
flush::
Used with `--buffer` to execute all preceding commands that were issued
since the beginning or since the last flush was issued. When `--buffer`
is used, no output will come until a `flush` is issued. When `--buffer`
is not used, commands are flushed each time without issuing `flush`.
--
+
--batch-all-objects::
Instead of reading a list of objects on stdin, perform the
requested batch operation on all objects in the repository and
any alternate object stores (not just reachable objects).
Requires `--batch` or `--batch-check` be specified. By default,
the objects are visited in order sorted by their hashes; see
also `--unordered` below. Objects are presented as-is, without
respecting the "replace" mechanism of linkgit:git-replace[1].
--buffer::
Normally batch output is flushed after each object is output, so
that a process can interactively read and write from
`cat-file`. With this option, the output uses normal stdio
buffering; this is much more efficient when invoking
`--batch-check` or `--batch-command` on a large number of objects.
--unordered::
When `--batch-all-objects` is in use, visit objects in an
order which may be more efficient for accessing the object
contents than hash order. The exact details of the order are
unspecified, but if you do not require a specific order, this
should generally result in faster output, especially with
`--batch`. Note that `cat-file` will still show each object
only once, even if it is stored multiple times in the
repository.
--follow-symlinks::
With `--batch` or `--batch-check`, follow symlinks inside the
repository when requesting objects with extended SHA-1
expressions of the form tree-ish:path-in-tree. Instead of
providing output about the link itself, provide output about
the linked-to object. If a symlink points outside the
tree-ish (e.g. a link to `/foo` or a root-level link to `../foo`),
the portion of the link which is outside the tree will be
printed.
+
This option does not (currently) work correctly when an object in the
index is specified (e.g. `:link` instead of `HEAD:link`) rather than
one in the tree.
+
This option cannot (currently) be used unless `--batch` or
`--batch-check` is used.
+
For example, consider a git repository containing:
+
--
f: a file containing "hello\n"
link: a symlink to f
dir/link: a symlink to ../f
plink: a symlink to ../f
alink: a symlink to /etc/passwd
--
+
For a regular file `f`, `echo HEAD:f | git cat-file --batch` would print
+
--
ce013625030ba8dba906f756967f9e9ca394464a blob 6
--
+
And `echo HEAD:link | git cat-file --batch --follow-symlinks` would
print the same thing, as would `HEAD:dir/link`, as they both point at
`HEAD:f`.
+
Without `--follow-symlinks`, these would print data about the symlink
itself. In the case of `HEAD:link`, you would see
+
--
4d1ae35ba2c8ec712fa2a379db44ad639ca277bd blob 1
--
+
Both `plink` and `alink` point outside the tree, so they would
respectively print:
+
--
symlink 4
../f
symlink 11
/etc/passwd
--
-Z::
Only meaningful with `--batch`, `--batch-check`, or
`--batch-command`; input and output is NUL-delimited instead of
newline-delimited.
-z::
Only meaningful with `--batch`, `--batch-check`, or
`--batch-command`; input is NUL-delimited instead of
newline-delimited. This option is deprecated in favor of
`-Z` as the output can otherwise be ambiguous.
OUTPUT
------
If `-t` is specified, one of the `<type>`.
If `-s` is specified, the size of the `<object>` in bytes.
If `-e` is specified, no output, unless the `<object>` is malformed.
If `-p` is specified, the contents of `<object>` are pretty-printed.
If `<type>` is specified, the raw (though uncompressed) contents of the `<object>`
will be returned.
BATCH OUTPUT
------------
If `--batch` or `--batch-check` is given, `cat-file` will read objects
from stdin, one per line, and print information about them in the same
order as they have been read. By default, the whole line is
considered as an object, as if it were fed to linkgit:git-rev-parse[1].
When `--batch-command` is given, `cat-file` will read commands from stdin,
one per line, and print information based on the command given. With
`--batch-command`, the `info` command followed by an object will print
information about the object the same way `--batch-check` would, and the
`contents` command followed by an object prints contents in the same way
`--batch` would.
You can specify the information shown for each object by using a custom
`<format>`. The `<format>` is copied literally to stdout for each
object, with placeholders of the form `%(atom)` expanded, followed by a
newline. The available atoms are:
`objectname`::
The full hex representation of the object name.
`objecttype`::
The type of the object (the same as `cat-file -t` reports).
`objectmode`::
If the specified object has mode information (such as a tree or
index entry), the mode expressed as an octal integer. Otherwise,
empty string.
`objectsize`::
The size, in bytes, of the object (the same as `cat-file -s`
reports).
`objectsize:disk`::
The size, in bytes, that the object takes up on disk. See the
note about on-disk sizes in the `CAVEATS` section below.
`deltabase`::
If the object is stored as a delta on-disk, this expands to the
full hex representation of the delta base object name.
Otherwise, expands to the null OID (all zeroes). See `CAVEATS`
below.
`rest`::
If this atom is used in the output string, input lines are split
at the first whitespace boundary. All characters before that
whitespace are considered to be the object name; characters
after that first run of whitespace (i.e., the "rest" of the
line) are output in place of the `%(rest)` atom.
If no format is specified, the default format is `%(objectname)
%(objecttype) %(objectsize)`.
If `--batch` is specified, or if `--batch-command` is used with the `contents`
command, the object information is followed by the object contents (consisting
of `%(objectsize)` bytes), followed by a newline.
For example, `--batch` without a custom format would produce:
-----------
<oid> SP <type> SP <size> LF
<contents> LF
-----------
Whereas `--batch-check='%(objectname) %(objecttype)'` would produce:
------------
<oid> SP <type> LF
------------
If a name is specified on stdin that cannot be resolved to an object in
the repository, then `cat-file` will ignore any custom format and print:
------------
<object> SP missing LF
------------
If a name is specified on stdin that is filtered out via `--filter=`,
then `cat-file` will ignore any custom format and print:
------------
<object> SP excluded LF
------------
If a name is specified that might refer to more than one object (an ambiguous short sha), then `cat-file` will ignore any custom format and print:
------------
<object> SP ambiguous LF
------------
If a name is specified that refers to a submodule entry in a tree and the
target object does not exist in the repository, then `cat-file` will ignore
any custom format and print (with the object ID of the submodule):
------------
<oid> SP submodule LF
------------
If `--follow-symlinks` is used, and a symlink in the repository points
outside the repository, then `cat-file` will ignore any custom format
and print:
------------
symlink SP <size> LF
<symlink> LF
------------
The symlink will either be absolute (beginning with a `/`), or relative
to the tree root. For instance, if dir/link points to `../../foo`, then
`<symlink>` will be `../foo`. `<size>` is the size of the symlink in bytes.
If `--follow-symlinks` is used, the following error messages will be
displayed:
------------
<object> SP missing LF
------------
is printed when the initial symlink requested does not exist.
------------
dangling SP <size> LF
<object> LF
------------
is printed when the initial symlink exists, but something that
it (transitive-of) points to does not.
------------
loop SP <size> LF
<object> LF
------------
is printed for symlink loops (or any symlinks that
require more than 40 link resolutions to resolve).
------------
notdir SP <size> LF
<object> LF
------------
is printed when, during symlink resolution, a file is used as a
directory name.
Alternatively, when `-Z` is passed, the line feeds in any of the above examples
are replaced with NUL terminators. This ensures that output will be parsable if
the output itself would contain a linefeed and is thus recommended for
scripting purposes.
CAVEATS
-------
Note that the sizes of objects on disk are reported accurately, but care
should be taken in drawing conclusions about which refs or objects are
responsible for disk usage. The size of a packed non-delta object may be
much larger than the size of objects which delta against it, but the
choice of which object is the base and which is the delta is arbitrary
and is subject to change during a repack.
Note also that multiple copies of an object may be present in the object
database; in this case, it is undefined which copy's size or delta base
will be reported.
GIT
---
Part of the linkgit:git[1] suite

132
app/src/main/assets/manpages/git-check-attr.txt Normal file
View File

@@ -0,0 +1,132 @@
git-check-attr(1)
=================
NAME
----
git-check-attr - Display gitattributes information
SYNOPSIS
--------
[verse]
'git check-attr' [--source <tree-ish>] [-a | --all | <attr>...] [--] <pathname>...
'git check-attr' --stdin [-z] [--source <tree-ish>] [-a | --all | <attr>...]
DESCRIPTION
-----------
For every pathname, this command will list if each attribute is 'unspecified',
'set', or 'unset' as a gitattribute on that pathname.
OPTIONS
-------
-a::
--all::
List all attributes that are associated with the specified
paths. If this option is used, then 'unspecified' attributes
will not be included in the output.
--cached::
Consider `.gitattributes` in the index only, ignoring the working tree.
--stdin::
Read pathnames from the standard input, one per line,
instead of from the command line.
-z::
The output format is modified to be machine-parsable.
If `--stdin` is also given, input paths are separated
with a NUL character instead of a linefeed character.
--source=<tree-ish>::
Check attributes against the specified tree-ish. It is common to
specify the source tree by naming a commit, branch, or tag associated
with it.
\--::
Interpret all preceding arguments as attributes and all following
arguments as path names.
If none of `--stdin`, `--all`, or `--` is used, the first argument
will be treated as an attribute and the rest of the arguments as
pathnames.
OUTPUT
------
The output is of the form:
<path> COLON SP <attribute> COLON SP <info> LF
unless `-z` is in effect, in which case NUL is used as delimiter:
<path> NUL <attribute> NUL <info> NUL
<path> is the path of a file being queried, <attribute> is an attribute
being queried, and <info> can be either:
'unspecified';; when the attribute is not defined for the path.
'unset';; when the attribute is defined as false.
'set';; when the attribute is defined as true.
<value>;; when a value has been assigned to the attribute.
Buffering happens as documented under the `GIT_FLUSH` option in
linkgit:git[1]. The caller is responsible for avoiding deadlocks
caused by overfilling an input buffer or reading from an empty output
buffer.
EXAMPLES
--------
In the examples, the following '.gitattributes' file is used:
---------------
*.java diff=java -crlf myAttr
NoMyAttr.java !myAttr
README caveat=unspecified
---------------
* Listing a single attribute:
+
---------------
$ git check-attr diff org/example/MyClass.java
org/example/MyClass.java: diff: java
---------------
* Listing multiple attributes for a file:
+
---------------
$ git check-attr crlf diff myAttr -- org/example/MyClass.java
org/example/MyClass.java: crlf: unset
org/example/MyClass.java: diff: java
org/example/MyClass.java: myAttr: set
---------------
* Listing all attributes for a file:
+
---------------
$ git check-attr --all -- org/example/MyClass.java
org/example/MyClass.java: diff: java
org/example/MyClass.java: myAttr: set
---------------
* Listing an attribute for multiple files:
+
---------------
$ git check-attr myAttr -- org/example/MyClass.java org/example/NoMyAttr.java
org/example/MyClass.java: myAttr: set
org/example/NoMyAttr.java: myAttr: unspecified
---------------
* Not all values are equally unambiguous:
+
---------------
$ git check-attr caveat README
README: caveat: unspecified
---------------
SEE ALSO
--------
linkgit:gitattributes[5].
GIT
---
Part of the linkgit:git[1] suite

129
app/src/main/assets/manpages/git-check-ignore.txt Normal file
View File

@@ -0,0 +1,129 @@
git-check-ignore(1)
===================
NAME
----
git-check-ignore - Debug gitignore / exclude files
SYNOPSIS
--------
[verse]
'git check-ignore' [<options>] <pathname>...
'git check-ignore' [<options>] --stdin
DESCRIPTION
-----------
For each pathname given via the command-line or from a file via
`--stdin`, check whether the file is excluded by .gitignore (or other
input files to the exclude mechanism) and output the path if it is
excluded.
By default, tracked files are not shown at all since they are not
subject to exclude rules; but see `--no-index'.
OPTIONS
-------
-q::
--quiet::
Don't output anything, just set exit status. This is only
valid with a single pathname.
-v::
--verbose::
Instead of printing the paths that are excluded, for each path
that matches an exclude pattern, print the exclude pattern
together with the path. (Matching an exclude pattern usually
means the path is excluded, but if the pattern begins with "`!`"
then it is a negated pattern and matching it means the path is
NOT excluded.)
+
For precedence rules within and between exclude sources, see
linkgit:gitignore[5].
--stdin::
Read pathnames from the standard input, one per line,
instead of from the command-line.
-z::
The output format is modified to be machine-parsable (see
below). If `--stdin` is also given, input paths are separated
with a NUL character instead of a linefeed character.
-n::
--non-matching::
Show given paths which don't match any pattern. This only
makes sense when `--verbose` is enabled, otherwise it would
not be possible to distinguish between paths which match a
pattern and those which don't.
--no-index::
Don't look in the index when undertaking the checks. This can
be used to debug why a path became tracked by e.g. `git add .`
and was not ignored by the rules as expected by the user or when
developing patterns including negation to match a path previously
added with `git add -f`.
OUTPUT
------
By default, any of the given pathnames which match an ignore pattern
will be output, one per line. If no pattern matches a given path,
nothing will be output for that path; this means that path will not be
ignored.
If `--verbose` is specified, the output is a series of lines of the form:
<source> <COLON> <linenum> <COLON> <pattern> <HT> <pathname>
<pathname> is the path of a file being queried, <pattern> is the
matching pattern, <source> is the pattern's source file, and <linenum>
is the line number of the pattern within that source. If the pattern
contained a "`!`" prefix or "`/`" suffix, it will be preserved in the
output. <source> will be an absolute path when referring to the file
configured by `core.excludesFile`, or relative to the repository root
when referring to `.git/info/exclude` or a per-directory exclude file.
If `-z` is specified, the pathnames in the output are delimited by the
null character; if `--verbose` is also specified then null characters
are also used instead of colons and hard tabs:
<source> <NULL> <linenum> <NULL> <pattern> <NULL> <pathname> <NULL>
If `-n` or `--non-matching` are specified, non-matching pathnames will
also be output, in which case all fields in each output record except
for <pathname> will be empty. This can be useful when running
non-interactively, so that files can be incrementally streamed to
STDIN of a long-running check-ignore process, and for each of these
files, STDOUT will indicate whether that file matched a pattern or
not. (Without this option, it would be impossible to tell whether the
absence of output for a given file meant that it didn't match any
pattern, or that the output hadn't been generated yet.)
Buffering happens as documented under the `GIT_FLUSH` option in
linkgit:git[1]. The caller is responsible for avoiding deadlocks
caused by overfilling an input buffer or reading from an empty output
buffer.
EXIT STATUS
-----------
0::
One or more of the provided paths is ignored.
1::
None of the provided paths are ignored.
128::
A fatal error was encountered.
SEE ALSO
--------
linkgit:gitignore[5]
linkgit:git-config[1]
linkgit:git-ls-files[1]
GIT
---
Part of the linkgit:git[1] suite

64
app/src/main/assets/manpages/git-check-mailmap.txt Normal file
View File

@@ -0,0 +1,64 @@
git-check-mailmap(1)
====================
NAME
----
git-check-mailmap - Show canonical names and email addresses of contacts
SYNOPSIS
--------
[verse]
'git check-mailmap' [<options>] <contact>...
DESCRIPTION
-----------
For each ``Name $$<user@host>$$'', ``$$<user@host>$$'', or ``$$user@host$$''
from the command-line or standard input (when using `--stdin`), look up the
person's canonical name and email address (see "Mapping Authors" below). If
found, print them; otherwise print the input as-is.
OPTIONS
-------
--stdin::
Read contacts, one per line, from the standard input after exhausting
contacts provided on the command-line.
--mailmap-file=<file>::
In addition to any configured mailmap files, read the specified
mailmap file. Entries in this file take precedence over entries in
either the default mailmap file or any configured mailmap file.
--mailmap-blob=<blob>::
Like `--mailmap-file`, but consider the value as a reference to a
blob in the repository. If both `--mailmap-file` and
`--mailmap-blob` are specified, entries in `--mailmap-file` will
take precedence.
OUTPUT
------
For each contact, a single line is output, terminated by a newline. If the
name is provided or known to the 'mailmap', ``Name $$<user@host>$$'' is
printed; otherwise only ``$$<user@host>$$'' is printed.
CONFIGURATION
-------------
See `mailmap.file` and `mailmap.blob` in linkgit:git-config[1] for how
to specify a custom `.mailmap` target file or object.
MAPPING AUTHORS
---------------
See linkgit:gitmailmap[5].
GIT
---
Part of the linkgit:git[1] suite

141
app/src/main/assets/manpages/git-check-ref-format.txt Normal file
View File

@@ -0,0 +1,141 @@
git-check-ref-format(1)
=======================
NAME
----
git-check-ref-format - Ensures that a reference name is well formed
SYNOPSIS
--------
[verse]
'git check-ref-format' [--normalize]
[--[no-]allow-onelevel] [--refspec-pattern]
<refname>
'git check-ref-format' --branch <branchname-shorthand>
DESCRIPTION
-----------
Checks if a given 'refname' is acceptable, and exits with a non-zero
status if it is not.
A reference is used in Git to specify branches and tags. A
branch head is stored in the `refs/heads` hierarchy, while
a tag is stored in the `refs/tags` hierarchy of the ref namespace
(typically in `$GIT_DIR/refs/heads` and `$GIT_DIR/refs/tags`
directories or, as entries in file `$GIT_DIR/packed-refs`
if refs are packed by `git gc`).
Git imposes the following rules on how references are named:
. They can include slash `/` for hierarchical (directory)
grouping, but no slash-separated component can begin with a
dot `.` or end with the sequence `.lock`.
. They must contain at least one `/`. This enforces the presence of a
category like `heads/`, `tags/` etc. but the actual names are not
restricted. If the `--allow-onelevel` option is used, this rule
is waived.
. They cannot have two consecutive dots `..` anywhere.
. They cannot have ASCII control characters (i.e. bytes whose
values are lower than \040, or \177 `DEL`), space, tilde `~`,
caret `^`, or colon `:` anywhere.
. They cannot have question-mark `?`, asterisk `*`, or open
bracket `[` anywhere. See the `--refspec-pattern` option below for
an exception to this rule.
. They cannot begin or end with a slash `/` or contain multiple
consecutive slashes (see the `--normalize` option below for an
exception to this rule).
. They cannot end with a dot `.`.
. They cannot contain a sequence `@{`.
. They cannot be the single character `@`.
. They cannot contain a `\`.
These rules make it easy for shell script based tools to parse
reference names, pathname expansion by the shell when a reference name is used
unquoted (by mistake), and also avoid ambiguities in certain
reference name expressions (see linkgit:gitrevisions[7]):
. A double-dot `..` is often used as in `ref1..ref2`, and in some
contexts this notation means `^ref1 ref2` (i.e. not in
`ref1` and in `ref2`).
. A tilde `~` and caret `^` are used to introduce the postfix
'nth parent' and 'peel onion' operation.
. A colon `:` is used as in `srcref:dstref` to mean "use srcref\'s
value and store it in dstref" in fetch and push operations.
It may also be used to select a specific object such as with
'git cat-file': "git cat-file blob v1.3.3:refs.c".
. at-open-brace `@{` is used as a notation to access a reflog entry.
With the `--branch` option, the command takes a name and checks if
it can be used as a valid branch name (e.g. when creating a new
branch). But be cautious when using the
previous checkout syntax that may refer to a detached HEAD state.
The rule `git check-ref-format --branch $name` implements
may be stricter than what `git check-ref-format refs/heads/$name`
says (e.g. a dash may appear at the beginning of a ref component,
but it is explicitly forbidden at the beginning of a branch name).
When run with the `--branch` option in a repository, the input is first
expanded for the ``previous checkout syntax''
`@{-n}`. For example, `@{-1}` is a way to refer the last thing that
was checked out using "git switch" or "git checkout" operation.
This option should be
used by porcelains to accept this syntax anywhere a branch name is
expected, so they can act as if you typed the branch name. As an
exception note that, the ``previous checkout operation'' might result
in a commit object name when the N-th last thing checked out was not
a branch.
OPTIONS
-------
--allow-onelevel::
--no-allow-onelevel::
Controls whether one-level refnames are accepted (i.e.,
refnames that do not contain multiple `/`-separated
components). The default is `--no-allow-onelevel`.
--refspec-pattern::
Interpret <refname> as a reference name pattern for a refspec
(as used with remote repositories). If this option is
enabled, <refname> is allowed to contain a single `*`
in the refspec (e.g., `foo/bar*/baz` or `foo/bar*baz/`
but not `foo/bar*/baz*`).
--normalize::
Normalize 'refname' by removing any leading slash (`/`)
characters and collapsing runs of adjacent slashes between
name components into a single slash. If the normalized
refname is valid then print it to standard output and exit
with a status of 0, otherwise exit with a non-zero status.
(`--print` is a deprecated way to spell `--normalize`.)
EXAMPLES
--------
* Print the name of the previous thing checked out:
+
------------
$ git check-ref-format --branch @{-1}
------------
* Determine the reference name to use for a new branch:
+
------------
$ ref=$(git check-ref-format --normalize "refs/heads/$newbranch")||
{ echo "we do not like '$newbranch' as a branch name." >&2 ; exit 1 ; }
------------
GIT
---
Part of the linkgit:git[1] suite

183
app/src/main/assets/manpages/git-checkout-index.txt Normal file
View File

@@ -0,0 +1,183 @@
git-checkout-index(1)
=====================
NAME
----
git-checkout-index - Copy files from the index to the working tree
SYNOPSIS
--------
[verse]
'git checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
[--stage=<number>|all]
[--temp]
[--ignore-skip-worktree-bits]
[-z] [--stdin]
[--] [<file>...]
DESCRIPTION
-----------
Copies all listed files from the index to the working directory
(not overwriting existing files).
OPTIONS
-------
-u::
--index::
update stat information for the checked out entries in
the index file.
-q::
--quiet::
be quiet if files exist or are not in the index
-f::
--force::
forces overwrite of existing files
-a::
--all::
checks out all files in the index except for those with the
skip-worktree bit set (see `--ignore-skip-worktree-bits`).
Cannot be used together with explicit filenames.
-n::
--no-create::
Don't checkout new files, only refresh files already checked
out.
--prefix=<string>::
When creating files, prepend <string> (usually a directory
including a trailing /)
--stage=<number>|all::
Instead of checking out unmerged entries, copy out the
files from the named stage. <number> must be between 1 and 3.
Note: --stage=all automatically implies --temp.
--temp::
Instead of copying the files to the working directory,
write the content to temporary files. The temporary name
associations will be written to stdout.
--ignore-skip-worktree-bits::
Check out all files, including those with the skip-worktree bit
set.
--stdin::
Instead of taking a list of paths from the command line,
read the list of paths from the standard input. Paths are
separated by LF (i.e. one path per line) by default.
-z::
Only meaningful with `--stdin`; paths are separated with
NUL character instead of LF.
\--::
Do not interpret any more arguments as options.
The order of the flags used to matter, but not anymore.
Just doing `git checkout-index` does nothing. You probably meant
`git checkout-index -a`. And if you want to force it, you want
`git checkout-index -f -a`.
Intuitiveness is not the goal here. Repeatability is. The reason for
the "no arguments means no work" behavior is that from scripts you are
supposed to be able to do:
----------------
$ find . -name '*.h' -print0 | xargs -0 git checkout-index -f --
----------------
which will force all existing `*.h` files to be replaced with their
cached copies. If an empty command line implied "all", then this would
force-refresh everything in the index, which was not the point. But
since 'git checkout-index' accepts --stdin it would be faster to use:
----------------
$ find . -name '*.h' -print0 | git checkout-index -f -z --stdin
----------------
The `--` is just a good idea when you know the rest will be filenames;
it will prevent problems with a filename of, for example, `-a`.
Using `--` is probably a good policy in scripts.
Using --temp or --stage=all
---------------------------
When `--temp` is used (or implied by `--stage=all`)
'git checkout-index' will create a temporary file for each index
entry being checked out. The index will not be updated with stat
information. These options can be useful if the caller needs all
stages of all unmerged entries so that the unmerged files can be
processed by an external merge tool.
A listing will be written to stdout providing the association of
temporary file names to tracked path names. The listing format
has two variations:
. tempname TAB path RS
+
The first format is what gets used when `--stage` is omitted or
is not `--stage=all`. The field tempname is the temporary file
name holding the file content and path is the tracked path name in
the index. Only the requested entries are output.
. stage1temp SP stage2temp SP stage3tmp TAB path RS
+
The second format is what gets used when `--stage=all`. The three
stage temporary fields (stage1temp, stage2temp, stage3temp) list the
name of the temporary file if there is a stage entry in the index
or `.` if there is no stage entry. Paths which only have a stage 0
entry will always be omitted from the output.
In both formats RS (the record separator) is newline by default
but will be the null byte if -z was passed on the command line.
The temporary file names are always safe strings; they will never
contain directory separators or whitespace characters. The path
field is always relative to the current directory and the temporary
file names are always relative to the top level directory.
If the object being copied out to a temporary file is a symbolic
link the content of the link will be written to a normal file. It is
up to the end-user or the Porcelain to make use of this information.
EXAMPLES
--------
To update and refresh only the files already checked out::
+
----------------
$ git checkout-index -n -f -a && git update-index --ignore-missing --refresh
----------------
Using 'git checkout-index' to "export an entire tree"::
The prefix ability basically makes it trivial to use
'git checkout-index' as an "export as tree" function.
Just read the desired tree into the index, and do:
+
----------------
$ git checkout-index --prefix=git-export-dir/ -a
----------------
+
`git checkout-index` will "export" the index into the specified
directory.
+
The final "/" is important. The exported name is literally just
prefixed with the specified string. Contrast this with the
following example.
Export files with a prefix::
+
----------------
$ git checkout-index --prefix=.merged- Makefile
----------------
+
This will check out the currently cached copy of `Makefile`
into the file `.merged-Makefile`.
GIT
---
Part of the linkgit:git[1] suite

629
app/src/main/assets/manpages/git-checkout.txt Normal file
View File

@@ -0,0 +1,629 @@
git-checkout(1)
===============
NAME
----
git-checkout - Switch branches or restore working tree files
SYNOPSIS
--------
[synopsis]
git checkout [-q] [-f] [-m] [<branch>]
git checkout [-q] [-f] [-m] --detach [<branch>]
git checkout [-q] [-f] [-m] [--detach] <commit>
git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <new-branch>] [<start-point>]
git checkout <tree-ish> [--] <pathspec>...
git checkout <tree-ish> --pathspec-from-file=<file> [--pathspec-file-nul]
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [--] <pathspec>...
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] --pathspec-from-file=<file> [--pathspec-file-nul]
git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>...]
DESCRIPTION
-----------
`git checkout` has two main modes:
1. **Switch branches**, with `git checkout <branch>`
2. **Restore a different version of a file**, for example with
`git checkout <commit> <filename>` or `git checkout <filename>`
See ARGUMENT DISAMBIGUATION below for how Git decides which one to do.
`git checkout [<branch>]`::
Switch to _<branch>_. This sets the current branch to _<branch>_ and
updates the files in your working directory. The checkout will fail
if there are uncommitted changes to any files where _<branch>_ and
your current commit have different content. Uncommitted changes will
otherwise be kept.
+
If _<branch>_ is not found but there does exist a tracking branch in
exactly one remote (call it _<remote>_) with a matching name and
`--no-guess` is not specified, treat as equivalent to
+
------------
$ git checkout -b <branch> --track <remote>/<branch>
------------
+
Running `git checkout` without specifying a branch has no effect except
to print out the tracking information for the current branch.
`git checkout -b <new-branch> [<start-point>]`::
Create a new branch named _<new-branch>_, start it at _<start-point>_
(defaults to the current commit), and check out the new branch.
You can use the `--track` or `--no-track` options to set the branch's
upstream tracking information.
+
This will fail if there's an error checking out _<new-branch>_, for
example if checking out the `<start-point>` commit would overwrite your
uncommitted changes.
`git checkout -B <branch> [<start-point>]`::
The same as `-b`, except that if the branch already exists it
resets _<branch>_ to the start point instead of failing.
`git checkout --detach [<branch>]`::
`git checkout [--detach] <commit>`::
The same as `git checkout <branch>`, except that instead of pointing
`HEAD` at the branch, it points `HEAD` at the commit ID.
See the "DETACHED HEAD" section below for more.
+
Omitting _<branch>_ detaches `HEAD` at the tip of the current branch.
`git checkout <tree-ish> [--] <pathspec>...`::
`git checkout <tree-ish> --pathspec-from-file=<file> [--pathspec-file-nul]`::
Replace the specified files and/or directories with the version from
the given commit or tree and add them to the index
(also known as "staging area").
+
For example, `git checkout main file.txt` will replace `file.txt`
with the version from `main`.
`git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [--] <pathspec>...`::
`git checkout [-f|--ours|--theirs|-m|--conflict=<style>] --pathspec-from-file=<file> [--pathspec-file-nul]`::
Replace the specified files and/or directories with the version from
the index.
+
For example, if you check out a commit, edit `file.txt`, and then
decide those changes were a mistake, `git checkout file.txt` will
discard any unstaged changes to `file.txt`.
+
This will fail if the file has a merge conflict and you haven't yet run
`git add file.txt` (or something equivalent) to mark it as resolved.
You can use `-f` to ignore the unmerged files instead of failing, use
`--ours` or `--theirs` to replace them with the version from a specific
side of the merge, or use `-m` to replace them with the original
conflicted merge result.
`git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>...]`::
This is similar to the previous two modes, but lets you use the
interactive interface to show the "diff" output and choose which
hunks to use in the result. See below for the description of
`--patch` option.
OPTIONS
-------
`-q`::
`--quiet`::
Quiet, suppress feedback messages.
`--progress`::
`--no-progress`::
Progress status is reported on the standard error stream
by default when it is attached to a terminal, unless `--quiet`
is specified. This flag enables progress reporting even if not
attached to a terminal, regardless of `--quiet`.
`-f`::
`--force`::
When switching branches, proceed even if the index or the
working tree differs from `HEAD`, and even if there are untracked
files in the way. This is used to throw away local changes and
any untracked files or directories that are in the way.
+
When checking out paths from the index, do not fail upon unmerged
entries; instead, unmerged entries are ignored.
`--ours`::
`--theirs`::
When checking out paths from the index, check out stage #2
(`ours`) or #3 (`theirs`) for unmerged paths.
+
Note that during `git rebase` and `git pull --rebase`, `ours` and
`theirs` may appear swapped; `--ours` gives the version from the
branch the changes are rebased onto, while `--theirs` gives the
version from the branch that holds your work that is being rebased.
+
This is because `rebase` is used in a workflow that treats the
history at the remote as the shared canonical one, and treats the
work done on the branch you are rebasing as the third-party work to
be integrated, and you are temporarily assuming the role of the
keeper of the canonical history during the rebase. As the keeper of
the canonical history, you need to view the history from the remote
as `ours` (i.e. "our shared canonical history"), while what you did
on your side branch as `theirs` (i.e. "one contributor's work on top
of it").
`-b <new-branch>`::
Create a new branch named _<new-branch>_, start it at
_<start-point>_, and check the resulting branch out;
see linkgit:git-branch[1] for details.
`-B <new-branch>`::
The same as `-b`, except that if the branch already exists it
resets _<branch>_ to the start point instead of failing.
`-t`::
`--track[=(direct|inherit)]`::
When creating a new branch, set up "upstream" configuration. See
`--track` in linkgit:git-branch[1] for details. As a convenience,
--track without -b implies branch creation.
+
If no `-b` option is given, the name of the new branch will be
derived from the remote-tracking branch, by looking at the local part of
the refspec configured for the corresponding remote, and then stripping
the initial part up to the "*".
This would tell us to use `hack` as the local branch when branching
off of `origin/hack` (or `remotes/origin/hack`, or even
`refs/remotes/origin/hack`). If the given name has no slash, or the above
guessing results in an empty name, the guessing is aborted. You can
explicitly give a name with `-b` in such a case.
`--no-track`::
Do not set up "upstream" configuration, even if the
`branch.autoSetupMerge` configuration variable is true.
`--guess`::
`--no-guess`::
If _<branch>_ is not found but there does exist a tracking
branch in exactly one remote (call it _<remote>_) with a
matching name, treat as equivalent to
+
------------
$ git checkout -b <branch> --track <remote>/<branch>
------------
+
If the branch exists in multiple remotes and one of them is named by
the `checkout.defaultRemote` configuration variable, we'll use that
one for the purposes of disambiguation, even if the _<branch>_ isn't
unique across all remotes. Set it to
e.g. `checkout.defaultRemote=origin` to always checkout remote
branches from there if _<branch>_ is ambiguous but exists on the
'origin' remote. See also `checkout.defaultRemote` in
linkgit:git-config[1].
+
`--guess` is the default behavior. Use `--no-guess` to disable it.
+
The default behavior can be set via the `checkout.guess` configuration
variable.
`-l`::
Create the new branch's reflog; see linkgit:git-branch[1] for
details.
`-d`::
`--detach`::
Rather than checking out a branch to work on it, check out a
commit for inspection and discardable experiments.
This is the default behavior of `git checkout <commit>` when
_<commit>_ is not a branch name. See the "DETACHED HEAD" section
below for details.
`--orphan <new-branch>`::
Create a new unborn branch, named _<new-branch>_, started from
_<start-point>_ and switch to it. The first commit made on this
new branch will have no parents and it will be the root of a new
history totally disconnected from all the other branches and
commits.
+
The index and the working tree are adjusted as if you had previously run
`git checkout <start-point>`. This allows you to start a new history
that records a set of paths similar to _<start-point>_ by easily running
`git commit -a` to make the root commit.
+
This can be useful when you want to publish the tree from a commit
without exposing its full history. You might want to do this to publish
an open source branch of a project whose current tree is "clean", but
whose full history contains proprietary or otherwise encumbered bits of
code.
+
If you want to start a disconnected history that records a set of paths
that is totally different from the one of _<start-point>_, then you should
clear the index and the working tree right after creating the orphan
branch by running `git rm -rf .` from the top level of the working tree.
Afterwards you will be ready to prepare your new files, repopulating the
working tree, by copying them from elsewhere, extracting a tarball, etc.
`--ignore-skip-worktree-bits`::
In sparse checkout mode, `git checkout -- <path>...` would
update only entries matched by _<paths>_ and sparse patterns
in `$GIT_DIR/info/sparse-checkout`. This option ignores
the sparse patterns and adds back any files in `<path>...`.
`-m`::
`--merge`::
When switching branches,
if you have local modifications to one or more files that
are different between the current branch and the branch to
which you are switching, the command refuses to switch
branches in order to preserve your modifications in context.
However, with this option, a three-way merge between the current
branch, your working tree contents, and the new branch
is done, and you will be on the new branch.
+
When a merge conflict happens, the index entries for conflicting
paths are left unmerged, and you need to resolve the conflicts
and mark the resolved paths with `git add` (or `git rm` if the merge
should result in deletion of the path).
+
When checking out paths from the index, this option lets you recreate
the conflicted merge in the specified paths. This option cannot be
used when checking out paths from a tree-ish.
+
When switching branches with `--merge`, staged changes may be lost.
`--conflict=<style>`::
The same as `--merge` option above, but changes the way the
conflicting hunks are presented, overriding the
`merge.conflictStyle` configuration variable. Possible values are
`merge` (default), `diff3`, and `zdiff3`.
`-p`::
`--patch`::
Interactively select hunks in the difference between the
_<tree-ish>_ (or the index, if unspecified) and the working
tree. The chosen hunks are then applied in reverse to the
working tree (and if a _<tree-ish>_ was specified, the index).
+
This means that you can use `git checkout -p` to selectively discard
edits from your current working tree. See the "Interactive Mode"
section of linkgit:git-add[1] to learn how to operate the `--patch` mode.
+
Note that this option uses the no overlay mode by default (see also
`--overlay`), and currently doesn't support overlay mode.
include::diff-context-options.adoc[]
`--ignore-other-worktrees`::
`git checkout` refuses when the wanted branch is already checked
out or otherwise in use by another worktree. This option makes
it check the branch out anyway. In other words, the branch can
be in use by more than one worktree.
`--overwrite-ignore`::
`--no-overwrite-ignore`::
Silently overwrite ignored files when switching branches. This
is the default behavior. Use `--no-overwrite-ignore` to abort
the operation when the new branch contains ignored files.
`--recurse-submodules`::
`--no-recurse-submodules`::
Using `--recurse-submodules` will update the content of all active
submodules according to the commit recorded in the superproject. If
local modifications in a submodule would be overwritten the checkout
will fail unless `-f` is used. If nothing (or `--no-recurse-submodules`)
is used, submodules working trees will not be updated.
Just like linkgit:git-submodule[1], this will detach `HEAD` of the
submodule.
`--overlay`::
`--no-overlay`::
In the default overlay mode, `git checkout` never
removes files from the index or the working tree. When
specifying `--no-overlay`, files that appear in the index and
working tree, but not in _<tree-ish>_ are removed, to make them
match _<tree-ish>_ exactly.
`--pathspec-from-file=<file>`::
Pathspec is passed in _<file>_ instead of commandline args. If
_<file>_ is exactly `-` then standard input is used. Pathspec
elements are separated by _LF_ or _CR_/_LF_. Pathspec elements can be
quoted as explained for the configuration variable `core.quotePath`
(see linkgit:git-config[1]). See also `--pathspec-file-nul` and
global `--literal-pathspecs`.
`--pathspec-file-nul`::
Only meaningful with `--pathspec-from-file`. Pathspec elements are
separated with _NUL_ character and all other characters are taken
literally (including newlines and quotes).
`<branch>`::
Branch to checkout; if it refers to a branch (i.e., a name that,
when prepended with "refs/heads/", is a valid ref), then that
branch is checked out. Otherwise, if it refers to a valid
commit, your `HEAD` becomes "detached" and you are no longer on
any branch (see below for details).
+
You can use the `@{-N}` syntax to refer to the N-th last
branch/commit checked out using "git checkout" operation. You may
also specify `-` which is synonymous to `@{-1}`.
+
As a special case, you may use `<rev-a>...<rev-b>` as a shortcut for the
merge base of _<rev-a>_ and _<rev-b>_ if there is exactly one merge base. You can
leave out at most one of _<rev-a>_ and _<rev-b>_, in which case it defaults to `HEAD`.
_<new-branch>_::
Name for the new branch.
_<start-point>_::
The name of a commit at which to start the new branch; see
linkgit:git-branch[1] for details. Defaults to `HEAD`.
+
As a special case, you may use `<rev-a>...<rev-b>` as a shortcut for the
merge base of _<rev-a>_ and _<rev-b>_ if there is exactly one merge base. You can
leave out at most one of _<rev-a>_ and _<rev-b>_, in which case it defaults to `HEAD`.
_<tree-ish>_::
Tree to checkout from (when paths are given). If not specified,
the index will be used.
+
As a special case, you may use `<rev-a>...<rev-b>` as a shortcut for the
merge base of _<rev-a>_ and _<rev-b>_ if there is exactly one merge base. You can
leave out at most one of _<rev-a>_ and _<rev-b>_, in which case it defaults to `HEAD`.
`--`::
Do not interpret any more arguments as options.
`<pathspec>...`::
Limits the paths affected by the operation.
+
For more details, see the 'pathspec' entry in linkgit:gitglossary[7].
DETACHED HEAD
-------------
`HEAD` normally refers to a named branch (e.g. `master`). Meanwhile, each
branch refers to a specific commit. Let's look at a repo with three
commits, one of them tagged, and with branch `master` checked out:
------------
HEAD (refers to branch 'master')
|
v
a---b---c branch 'master' (refers to commit 'c')
^
|
tag 'v2.0' (refers to commit 'b')
------------
When a commit is created in this state, the branch is updated to refer to
the new commit. Specifically, `git commit` creates a new commit `d`, whose
parent is commit `c`, and then updates branch `master` to refer to new
commit `d`. `HEAD` still refers to branch `master` and so indirectly now refers
to commit `d`:
------------
$ edit; git add; git commit
HEAD (refers to branch 'master')
|
v
a---b---c---d branch 'master' (refers to commit 'd')
^
|
tag 'v2.0' (refers to commit 'b')
------------
It is sometimes useful to be able to checkout a commit that is not at
the tip of any named branch, or even to create a new commit that is not
referenced by a named branch. Let's look at what happens when we
checkout commit `b` (here we show two ways this may be done):
------------
$ git checkout v2.0 # or
$ git checkout master^^
HEAD (refers to commit 'b')
|
v
a---b---c---d branch 'master' (refers to commit 'd')
^
|
tag 'v2.0' (refers to commit 'b')
------------
Notice that regardless of which checkout command we use, `HEAD` now refers
directly to commit `b`. This is known as being in detached `HEAD` state.
It means simply that `HEAD` refers to a specific commit, as opposed to
referring to a named branch. Let's see what happens when we create a commit:
------------
$ edit; git add; git commit
HEAD (refers to commit 'e')
|
v
e
/
a---b---c---d branch 'master' (refers to commit 'd')
^
|
tag 'v2.0' (refers to commit 'b')
------------
There is now a new commit `e`, but it is referenced only by `HEAD`. We can
of course add yet another commit in this state:
------------
$ edit; git add; git commit
HEAD (refers to commit 'f')
|
v
e---f
/
a---b---c---d branch 'master' (refers to commit 'd')
^
|
tag 'v2.0' (refers to commit 'b')
------------
In fact, we can perform all the normal Git operations. But, let's look
at what happens when we then checkout `master`:
------------
$ git checkout master
HEAD (refers to branch 'master')
e---f |
/ v
a---b---c---d branch 'master' (refers to commit 'd')
^
|
tag 'v2.0' (refers to commit 'b')
------------
It is important to realize that at this point nothing refers to commit
`f`. Eventually commit `f` (and by extension commit `e`) will be deleted
by the routine Git garbage collection process, unless we create a reference
before that happens. If we have not yet moved away from commit `f`,
any of these will create a reference to it:
------------
$ git checkout -b foo # or "git switch -c foo" <1>
$ git branch foo <2>
$ git tag foo <3>
------------
<1> creates a new branch `foo`, which refers to commit `f`, and then
updates `HEAD` to refer to branch `foo`. In other words, we'll no longer
be in detached `HEAD` state after this command.
<2> similarly creates a new branch `foo`, which refers to commit `f`,
but leaves `HEAD` detached.
<3> creates a new tag `foo`, which refers to commit `f`,
leaving `HEAD` detached.
If we have moved away from commit `f`, then we must first recover its object
name (typically by using git reflog), and then we can create a reference to
it. For example, to see the last two commits to which `HEAD` referred, we
can use either of these commands:
------------
$ git reflog -2 HEAD # or
$ git log -g -2 HEAD
------------
ARGUMENT DISAMBIGUATION
-----------------------
When you run `git checkout <something>`, Git tries to guess whether
_<something>_ is intended to be a branch, a commit, or a set of file(s),
and then either switches to that branch or commit, or restores the
specified files.
If there's any ambiguity, Git will treat `<something>` as a branch or
commit, but you can use the double dash `--` to force Git to treat the
parameter as a list of files and/or directories, like this:
----------
git checkout -- file.txt
----------
EXAMPLES
--------
=== 1. Paths
The following sequence checks out the `master` branch, reverts
the `Makefile` to two revisions back, deletes `hello.c` by
mistake, and gets it back from the index.
------------
$ git checkout master <1>
$ git checkout master~2 Makefile <2>
$ rm -f hello.c
$ git checkout hello.c <3>
------------
<1> switch branch
<2> take a file out of another commit
<3> restore `hello.c` from the index
If you want to check out _all_ C source files out of the index,
you can say
------------
$ git checkout -- '*.c'
------------
Note the quotes around `*.c`. The file `hello.c` will also be
checked out, even though it is no longer in the working tree,
because the file globbing is used to match entries in the index
(not in the working tree by the shell).
If you have an unfortunate branch that is named `hello.c`, this
step would be confused as an instruction to switch to that branch.
You should instead write:
------------
$ git checkout -- hello.c
------------
=== 2. Merge
After working in the wrong branch, switching to the correct
branch would be done using:
------------
$ git checkout mytopic
------------
However, your "wrong" branch and correct `mytopic` branch may
differ in files that you have modified locally, in which case
the above checkout would fail like this:
------------
$ git checkout mytopic
error: You have local changes to 'frotz'; not switching branches.
------------
You can give the `-m` flag to the command, which would try a
three-way merge:
------------
$ git checkout -m mytopic
Auto-merging frotz
------------
After this three-way merge, the local modifications are _not_
registered in your index file, so `git diff` would show you what
changes you made since the tip of the new branch.
=== 3. Merge conflict
When a merge conflict happens during switching branches with
the `-m` option, you would see something like this:
------------
$ git checkout -m mytopic
Auto-merging frotz
ERROR: Merge conflict in frotz
fatal: merge program failed
------------
At this point, `git diff` shows the changes cleanly merged as in
the previous example, as well as the changes in the conflicted
files. Edit and resolve the conflict and mark it resolved with
`git add` as usual:
------------
$ edit frotz
$ git add frotz
------------
CONFIGURATION
-------------
include::includes/cmd-config-section-all.adoc[]
include::config/checkout.adoc[]
SEE ALSO
--------
linkgit:git-switch[1],
linkgit:git-restore[1]
GIT
---
Part of the linkgit:git[1] suite

259
app/src/main/assets/manpages/git-cherry-pick.txt Normal file
View File

@@ -0,0 +1,259 @@
git-cherry-pick(1)
==================
NAME
----
git-cherry-pick - Apply the changes introduced by some existing commits
SYNOPSIS
--------
[verse]
'git cherry-pick' [--edit] [-n] [-m <parent-number>] [-s] [-x] [--ff]
[-S[<keyid>]] <commit>...
'git cherry-pick' (--continue | --skip | --abort | --quit)
DESCRIPTION
-----------
Given one or more existing commits, apply the change each one
introduces, recording a new commit for each. This requires your
working tree to be clean (no modifications from the HEAD commit).
When it is not obvious how to apply a change, the following
happens:
1. The current branch and `HEAD` pointer stay at the last commit
successfully made.
2. The `CHERRY_PICK_HEAD` ref is set to point at the commit that
introduced the change that is difficult to apply.
3. Paths in which the change applied cleanly are updated both
in the index file and in your working tree.
4. For conflicting paths, the index file records up to three
versions, as described in the "TRUE MERGE" section of
linkgit:git-merge[1]. The working tree files will include
a description of the conflict bracketed by the usual
conflict markers `<<<<<<<` and `>>>>>>>`.
5. No other modifications are made.
See linkgit:git-merge[1] for some hints on resolving such
conflicts.
OPTIONS
-------
<commit>...::
Commits to cherry-pick.
For a more complete list of ways to spell commits, see
linkgit:gitrevisions[7].
Sets of commits can be passed but no traversal is done by
default, as if the `--no-walk` option was specified, see
linkgit:git-rev-list[1]. Note that specifying a range will
feed all <commit>... arguments to a single revision walk
(see a later example that uses 'maint master..next').
-e::
--edit::
With this option, 'git cherry-pick' will let you edit the commit
message prior to committing.
--cleanup=<mode>::
This option determines how the commit message will be cleaned up before
being passed on to the commit machinery. See linkgit:git-commit[1] for more
details. In particular, if the '<mode>' is given a value of `scissors`,
scissors will be appended to `MERGE_MSG` before being passed on in the case
of a conflict.
-x::
When recording the commit, append a line that says
"(cherry picked from commit ...)" to the original commit
message in order to indicate which commit this change was
cherry-picked from. This is done only for cherry
picks without conflicts. Do not use this option if
you are cherry-picking from your private branch because
the information is useless to the recipient. If on the
other hand you are cherry-picking between two publicly
visible branches (e.g. backporting a fix to a
maintenance branch for an older release from a
development branch), adding this information can be
useful.
-r::
It used to be that the command defaulted to do `-x`
described above, and `-r` was to disable it. Now the
default is not to do `-x` so this option is a no-op.
-m <parent-number>::
--mainline <parent-number>::
Usually you cannot cherry-pick a merge because you do not know which
side of the merge should be considered the mainline. This
option specifies the parent number (starting from 1) of
the mainline and allows cherry-pick to replay the change
relative to the specified parent.
-n::
--no-commit::
Usually the command automatically creates a sequence of commits.
This flag applies the changes necessary to cherry-pick
each named commit to your working tree and the index,
without making any commit. In addition, when this
option is used, your index does not have to match the
HEAD commit. The cherry-pick is done against the
beginning state of your index.
+
This is useful when cherry-picking more than one commits'
effect to your index in a row.
-s::
--signoff::
Add a `Signed-off-by` trailer at the end of the commit message.
See the signoff option in linkgit:git-commit[1] for more information.
-S[<keyid>]::
--gpg-sign[=<keyid>]::
--no-gpg-sign::
GPG-sign commits. The `keyid` argument is optional and
defaults to the committer identity; if specified, it must be
stuck to the option without a space. `--no-gpg-sign` is useful to
countermand both `commit.gpgSign` configuration variable, and
earlier `--gpg-sign`.
--ff::
If the current HEAD is the same as the parent of the
cherry-pick'ed commit, then a fast forward to this commit will
be performed.
--allow-empty::
By default, cherry-picking an empty commit will fail,
indicating that an explicit invocation of `git commit
--allow-empty` is required. This option overrides that
behavior, allowing empty commits to be preserved automatically
in a cherry-pick. Note that when "--ff" is in effect, empty
commits that meet the "fast-forward" requirement will be kept
even without this option. Note also, that use of this option only
keeps commits that were initially empty (i.e. the commit recorded the
same tree as its parent). Commits which are made empty due to a
previous commit will cause the cherry-pick to fail. To force the
inclusion of those commits, use `--empty=keep`.
--allow-empty-message::
By default, cherry-picking a commit with an empty message will fail.
This option overrides that behavior, allowing commits with empty
messages to be cherry picked.
--empty=(drop|keep|stop)::
How to handle commits being cherry-picked that are redundant with
changes already in the current history.
+
--
`drop`;;
The commit will be dropped.
`keep`;;
The commit will be kept. Implies `--allow-empty`.
`stop`;;
The cherry-pick will stop when the commit is applied, allowing
you to examine the commit. This is the default behavior.
--
+
Note that `--empty=drop` and `--empty=stop` only specify how to handle a
commit that was not initially empty, but rather became empty due to a previous
commit. Commits that were initially empty will still cause the cherry-pick to
fail unless one of `--empty=keep` or `--allow-empty` are specified.
+
--keep-redundant-commits::
Deprecated synonym for `--empty=keep`.
--strategy=<strategy>::
Use the given merge strategy. Should only be used once.
See the MERGE STRATEGIES section in linkgit:git-merge[1]
for details.
-X<option>::
--strategy-option=<option>::
Pass the merge strategy-specific option through to the
merge strategy. See linkgit:git-merge[1] for details.
include::rerere-options.adoc[]
SEQUENCER SUBCOMMANDS
---------------------
include::sequencer.adoc[]
EXAMPLES
--------
`git cherry-pick master`::
Apply the change introduced by the commit at the tip of the
master branch and create a new commit with this change.
`git cherry-pick ..master`::
`git cherry-pick ^HEAD master`::
Apply the changes introduced by all commits that are ancestors
of master but not of HEAD to produce new commits.
`git cherry-pick maint next ^master`::
`git cherry-pick maint master..next`::
Apply the changes introduced by all commits that are
ancestors of maint or next, but not master or any of its
ancestors. Note that the latter does not mean `maint` and
everything between `master` and `next`; specifically,
`maint` will not be used if it is included in `master`.
`git cherry-pick master~4 master~2`::
Apply the changes introduced by the fifth and third last
commits pointed to by master and create 2 new commits with
these changes.
`git cherry-pick -n master~1 next`::
Apply to the working tree and the index the changes introduced
by the second last commit pointed to by master and by the last
commit pointed to by next, but do not create any commit with
these changes.
`git cherry-pick --ff ..next`::
If history is linear and HEAD is an ancestor of next, update
the working tree and advance the HEAD pointer to match next.
Otherwise, apply the changes introduced by those commits that
are in next but not HEAD to the current branch, creating a new
commit for each new change.
`git rev-list --reverse master -- README | git cherry-pick -n --stdin`::
Apply the changes introduced by all commits on the master
branch that touched README to the working tree and index,
so the result can be inspected and made into a single new
commit if suitable.
The following sequence attempts to backport a patch, bails out because
the code the patch applies to has changed too much, and then tries
again, this time exercising more care about matching up context lines.
------------
$ git cherry-pick topic^ <1>
$ git diff <2>
$ git cherry-pick --abort <3>
$ git cherry-pick -Xpatience topic^ <4>
------------
<1> apply the change that would be shown by `git show topic^`.
In this example, the patch does not apply cleanly, so
information about the conflict is written to the index and
working tree and no new commit results.
<2> summarize changes to be reconciled
<3> cancel the cherry-pick. In other words, return to the
pre-cherry-pick state, preserving any local modifications
you had in the working tree.
<4> try to apply the change introduced by `topic^` again,
spending extra time to avoid mistakes based on incorrectly
matching context lines.
SEE ALSO
--------
linkgit:git-revert[1]
GIT
---
Part of the linkgit:git[1] suite

145
app/src/main/assets/manpages/git-cherry.txt Normal file
View File

@@ -0,0 +1,145 @@
git-cherry(1)
=============
NAME
----
git-cherry - Find commits yet to be applied to upstream
SYNOPSIS
--------
[verse]
'git cherry' [-v] [<upstream> [<head> [<limit>]]]
DESCRIPTION
-----------
Determine whether there are commits in `<head>..<upstream>` that are
equivalent to those in the range `<limit>..<head>`.
The equivalence test is based on the diff, after removing whitespace
and line numbers. git-cherry therefore detects when commits have been
"copied" by means of linkgit:git-cherry-pick[1], linkgit:git-am[1] or
linkgit:git-rebase[1].
Outputs the SHA1 of every commit in `<limit>..<head>`, prefixed with
`-` for commits that have an equivalent in <upstream>, and `+` for
commits that do not.
OPTIONS
-------
-v::
Show the commit subjects next to the SHA1s.
<upstream>::
Upstream branch to search for equivalent commits.
Defaults to the upstream branch of HEAD.
<head>::
Working branch; defaults to HEAD.
<limit>::
Do not report commits up to (and including) limit.
EXAMPLES
--------
Patch workflows
~~~~~~~~~~~~~~~
git-cherry is frequently used in patch-based workflows (see
linkgit:gitworkflows[7]) to determine if a series of patches has been
applied by the upstream maintainer. In such a workflow you might
create and send a topic branch like this:
------------
$ git checkout -b topic origin/master
# work and create some commits
$ git format-patch origin/master
$ git send-email ... 00*
------------
Later, you can see whether your changes have been applied by saying
(still on `topic`):
------------
$ git fetch # update your notion of origin/master
$ git cherry -v
------------
Concrete example
~~~~~~~~~~~~~~~~
In a situation where topic consisted of three commits, and the
maintainer applied two of them, the situation might look like:
------------
$ git log --graph --oneline --decorate --boundary origin/master...topic
* 7654321 (origin/master) upstream tip commit
[... snip some other commits ...]
* cccc111 cherry-pick of C
* aaaa111 cherry-pick of A
[... snip a lot more that has happened ...]
| * cccc000 (topic) commit C
| * bbbb000 commit B
| * aaaa000 commit A
|/
o 1234567 branch point
------------
In such cases, git-cherry shows a concise summary of what has yet to
be applied:
------------
$ git cherry origin/master topic
- cccc000... commit C
+ bbbb000... commit B
- aaaa000... commit A
------------
Here, we see that the commits A and C (marked with `-`) can be
dropped from your `topic` branch when you rebase it on top of
`origin/master`, while the commit B (marked with `+`) still needs to
be kept so that it will be sent to be applied to `origin/master`.
Using a limit
~~~~~~~~~~~~~
The optional <limit> is useful in cases where your topic is based on
other work that is not in upstream. Expanding on the previous
example, this might look like:
------------
$ git log --graph --oneline --decorate --boundary origin/master...topic
* 7654321 (origin/master) upstream tip commit
[... snip some other commits ...]
* cccc111 cherry-pick of C
* aaaa111 cherry-pick of A
[... snip a lot more that has happened ...]
| * cccc000 (topic) commit C
| * bbbb000 commit B
| * aaaa000 commit A
| * 0000fff (base) unpublished stuff F
[... snip ...]
| * 0000aaa unpublished stuff A
|/
o 1234567 merge-base between upstream and topic
------------
By specifying `base` as the limit, you can avoid listing commits
between `base` and `topic`:
------------
$ git cherry origin/master topic base
- cccc000... commit C
+ bbbb000... commit B
- aaaa000... commit A
------------
SEE ALSO
--------
linkgit:git-patch-id[1]
GIT
---
Part of the linkgit:git[1] suite

25
app/src/main/assets/manpages/git-citool.txt Normal file
View File

@@ -0,0 +1,25 @@
git-citool(1)
=============
NAME
----
git-citool - Graphical alternative to git-commit
SYNOPSIS
--------
[verse]
'git citool'
DESCRIPTION
-----------
A Tcl/Tk based graphical interface to review modified files, stage
them into the index, enter a commit message and record the new
commit onto the current branch. This interface is an alternative
to the less interactive 'git commit' program.
'git citool' is actually a standard alias for `git gui citool`.
See linkgit:git-gui[1] for more details.
GIT
---
Part of the linkgit:git[1] suite

153
app/src/main/assets/manpages/git-clean.txt Normal file
View File

@@ -0,0 +1,153 @@
git-clean(1)
============
NAME
----
git-clean - Remove untracked files from the working tree
SYNOPSIS
--------
[verse]
'git clean' [-d] [-f] [-i] [-n] [-q] [-e <pattern>] [-x | -X] [--] [<pathspec>...]
DESCRIPTION
-----------
Cleans the working tree by recursively removing files that are not
under version control, starting from the current directory.
Normally, only files unknown to Git are removed, but if the `-x`
option is specified, ignored files are also removed. This can, for
example, be useful to remove all build products.
If any optional `<pathspec>...` arguments are given, only those paths
that match the pathspec are affected.
OPTIONS
-------
-d::
Normally, when no <pathspec> is specified, git clean will not
recurse into untracked directories to avoid removing too much.
Specify -d to have it recurse into such directories as well.
If a <pathspec> is specified, -d is irrelevant; all untracked
files matching the specified paths (with exceptions for nested
git directories mentioned under `--force`) will be removed.
-f::
--force::
If the Git configuration variable clean.requireForce is not set
to false, 'git clean' will refuse to delete files or directories
unless given -f. Git will refuse to modify untracked
nested git repositories (directories with a .git subdirectory)
unless a second -f is given.
-i::
--interactive::
Show what would be done and clean files interactively. See
``Interactive mode'' for details.
Configuration variable `clean.requireForce` is ignored, as
this mode gives its own safety protection by going interactive.
-n::
--dry-run::
Don't actually remove anything, just show what would be done.
Configuration variable `clean.requireForce` is ignored, as
nothing will be deleted anyway.
-q::
--quiet::
Be quiet, only report errors, but not the files that are
successfully removed.
-e <pattern>::
--exclude=<pattern>::
Use the given exclude pattern in addition to the standard ignore rules
(see linkgit:gitignore[5]).
-x::
Don't use the standard ignore rules (see linkgit:gitignore[5]), but
still use the ignore rules given with `-e` options from the command
line. This allows removing all untracked
files, including build products. This can be used (possibly in
conjunction with 'git restore' or 'git reset') to create a pristine
working directory to test a clean build.
-X::
Remove only files ignored by Git. This may be useful to rebuild
everything from scratch, but keep manually created files.
Interactive mode
----------------
When the command enters the interactive mode, it shows the
files and directories to be cleaned, and goes into its
interactive command loop.
The command loop shows the list of subcommands available, and
gives a prompt "What now> ". In general, when the prompt ends
with a single '>', you can pick only one of the choices given
and type return, like this:
------------
*** Commands ***
1: clean 2: filter by pattern 3: select by numbers
4: ask each 5: quit 6: help
What now> 1
------------
You also could say `c` or `clean` above as long as the choice is unique.
The main command loop has 6 subcommands.
clean::
Start cleaning files and directories, and then quit.
filter by pattern::
This shows the files and directories to be deleted and issues an
"Input ignore patterns>>" prompt. You can input space-separated
patterns to exclude files and directories from deletion.
E.g. "*.c *.h" will exclude files ending with ".c" and ".h" from
deletion. When you are satisfied with the filtered result, press
ENTER (empty) back to the main menu.
select by numbers::
This shows the files and directories to be deleted and issues an
"Select items to delete>>" prompt. When the prompt ends with double
'>>' like this, you can make more than one selection, concatenated
with whitespace or comma. Also you can say ranges. E.g. "2-5 7,9"
to choose 2,3,4,5,7,9 from the list. If the second number in a
range is omitted, all remaining items are selected. E.g. "7-" to
choose 7,8,9 from the list. You can say '*' to choose everything.
Also when you are satisfied with the filtered result, press ENTER
(empty) back to the main menu.
ask each::
This will start to clean, and you must confirm one by one in order
to delete items. Please note that this action is not as efficient
as the above two actions.
quit::
This lets you quit without doing any cleaning.
help::
Show brief usage of interactive git-clean.
CONFIGURATION
-------------
include::includes/cmd-config-section-all.adoc[]
include::config/clean.adoc[]
SEE ALSO
--------
linkgit:gitignore[5]
GIT
---
Part of the linkgit:git[1] suite

439
app/src/main/assets/manpages/git-clone.txt Normal file
View File

@@ -0,0 +1,439 @@
git-clone(1)
============
NAME
----
git-clone - Clone a repository into a new directory
SYNOPSIS
--------
[synopsis]
git clone [--template=<template-directory>]
[-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
[-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>]
[--dissociate] [--separate-git-dir <git-dir>]
[--depth <depth>] [--[no-]single-branch] [--[no-]tags]
[--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules]
[--[no-]remote-submodules] [--jobs <n>] [--sparse] [--[no-]reject-shallow]
[--filter=<filter-spec> [--also-filter-submodules]] [--] <repository>
[<directory>]
DESCRIPTION
-----------
Clones a repository into a newly created directory, creates
remote-tracking branches for each branch in the cloned repository
(visible using `git branch --remotes`), and creates and checks out an
initial branch that is forked from the cloned repository's
currently active branch.
After the clone, a plain `git fetch` without arguments will update
all the remote-tracking branches, and a `git pull` without
arguments will in addition merge the remote master branch into the
current master branch, if any (this is untrue when `--single-branch`
is given; see below).
This default configuration is achieved by creating references to
the remote branch heads under `refs/remotes/origin` and
by initializing `remote.origin.url` and `remote.origin.fetch`
configuration variables.
OPTIONS
-------
`-l`::
`--local`::
When the repository to clone from is on a local machine,
this flag bypasses the normal "Git aware" transport
mechanism and clones the repository by making a copy of
`HEAD` and everything under objects and refs directories.
The files under `.git/objects/` directory are hardlinked
to save space when possible.
+
If the repository is specified as a local path (e.g., `/path/to/repo`),
this is the default, and `--local` is essentially a no-op. If the
repository is specified as a URL, then this flag is ignored (and we
never use the local optimizations). Specifying `--no-local` will
override the default when `/path/to/repo` is given, using the regular
Git transport instead.
+
If the repository's `$GIT_DIR/objects` has symbolic links or is a
symbolic link, the clone will fail. This is a security measure to
prevent the unintentional copying of files by dereferencing the symbolic
links.
+
This option does not work with repositories owned by other users for security
reasons, and `--no-local` must be specified for the clone to succeed.
+
*NOTE*: this operation can race with concurrent modification to the
source repository, similar to running `cp -r <src> <dst>` while modifying
_<src>_.
`--no-hardlinks`::
Force the cloning process from a repository on a local
filesystem to copy the files under the `.git/objects`
directory instead of using hardlinks. This may be desirable
if you are trying to make a back-up of your repository.
`-s`::
`--shared`::
When the repository to clone is on the local machine,
instead of using hard links, automatically setup
`.git/objects/info/alternates` to share the objects
with the source repository. The resulting repository
starts out without any object of its own.
+
NOTE: this is a possibly dangerous operation; do *not* use
it unless you understand what it does. If you clone your
repository using this option and then delete branches (or use any
other Git command that makes any existing commit unreferenced) in the
source repository, some objects may become unreferenced (or dangling).
These objects may be removed by normal Git operations (such as `git commit`)
which automatically call `git maintenance run --auto`. (See
linkgit:git-maintenance[1].) If these objects are removed and were referenced
by the cloned repository, then the cloned repository will become corrupt.
+
Note that running `git repack` without the `--local` option in a repository
cloned with `--shared` will copy objects from the source repository into a pack
in the cloned repository, removing the disk space savings of `clone --shared`.
It is safe, however, to run `git gc`, which uses the `--local` option by
default.
+
If you want to break the dependency of a repository cloned with `--shared` on
its source repository, you can simply run `git repack -a` to copy all
objects from the source repository into a pack in the cloned repository.
`--reference=<repository>`::
`--reference-if-able=<repository>`::
If the reference _<repository>_ is on the local machine,
automatically setup `.git/objects/info/alternates` to
obtain objects from the reference _<repository>_. Using
an already existing repository as an alternate will
require fewer objects to be copied from the repository
being cloned, reducing network and local storage costs.
When using the `--reference-if-able`, a non existing
directory is skipped with a warning instead of aborting
the clone.
+
NOTE: see the NOTE for the `--shared` option, and also the
`--dissociate` option.
`--dissociate`::
Borrow the objects from reference repositories specified
with the `--reference` options only to reduce network
transfer, and stop borrowing from them after a clone is made
by making necessary local copies of borrowed objects. This
option can also be used when cloning locally from a
repository that already borrows objects from another
repository--the new repository will borrow objects from the
same repository, and this option can be used to stop the
borrowing.
`-q`::
`--quiet`::
Operate quietly. Progress is not reported to the standard
error stream.
`-v`::
`--verbose`::
Run verbosely. Does not affect the reporting of progress status
to the standard error stream.
`--progress`::
Report progress status on the standard error stream
by default when attached to a terminal, unless `--quiet`
is specified. This flag forces progress status even if the
standard error stream is not directed to a terminal.
`--server-option=<option>`::
Transmit the given string to the server when communicating using
protocol version 2. The given string must not contain a _NUL_ or _LF_
character. The server's handling of server options, including
unknown ones, is server-specific.
When multiple `--server-option=<option>` are given, they are all
sent to the other side in the order listed on the command line.
When no `--server-option=<option>` is given from the command
line, the values of configuration variable `remote.<name>.serverOption`
are used instead.
`-n`::
`--no-checkout`::
Do not checkout `HEAD` after the clone is complete.
`--no-reject-shallow`::
`--reject-shallow`::
Fail if the source repository is a shallow repository.
The `clone.rejectShallow` configuration variable can be used to
specify the default.
`--bare`::
Make a 'bare' Git repository. That is, instead of
creating _<directory>_ and placing the administrative
files in `<directory>/.git`, make the _<directory>_
itself the `$GIT_DIR`. This obviously implies the `--no-checkout`
because there is nowhere to check out the working tree.
Also the branch heads at the remote are copied directly
to corresponding local branch heads, without mapping
them to `refs/remotes/origin/`. When this option is
used, neither remote-tracking branches nor the related
configuration variables are created.
`--sparse`::
Employ a sparse-checkout, with only files in the toplevel
directory initially being present. The
linkgit:git-sparse-checkout[1] command can be used to grow the
working directory as needed.
`--filter=<filter-spec>`::
Use the partial clone feature and request that the server sends
a subset of reachable objects according to a given object filter.
When using `--filter`, the supplied _<filter-spec>_ is used for
the partial clone filter.
+
If `--filter=auto` is used the filter specification is determined
automatically through the 'promisor-remote' protocol (see
linkgit:gitprotocol-v2[5]) by combining the filter specifications
advertised by the server for the promisor remotes that the client
accepts (see the `promisor.acceptFromServer` configuration option in
linkgit:git-config[1]). This allows the server to suggest the optimal
filter for the available promisor remotes.
+
As with other filter specifications, the "auto" value is persisted in
the configuration. This ensures that future fetches will continue to
adapt to the server's current recommendation.
+
For details on all other available filter specifications, see the
`--filter=<filter-spec>` option in linkgit:git-rev-list[1].
+
For example, `--filter=blob:none` will filter out all blobs (file
contents) until needed by Git. Also, `--filter=blob:limit=<size>` will
filter out all blobs of size at least _<size>_.
`--also-filter-submodules`::
Also apply the partial clone filter to any submodules in the repository.
Requires `--filter` and `--recurse-submodules`. This can be turned on by
default by setting the `clone.filterSubmodules` config option.
`--mirror`::
Set up a mirror of the source repository. This implies `--bare`.
Compared to `--bare`, `--mirror` not only maps local branches of the
source to local branches of the target, it maps all refs (including
remote-tracking branches, notes etc.) and sets up a refspec configuration such
that all these refs are overwritten by a `git remote update` in the
target repository.
`-o<name>`::
`--origin=<name>`::
Instead of using the remote name `origin` to keep track of the upstream
repository, use _<name>_. Overrides `clone.defaultRemoteName` from the
config.
`-b<name>`::
`--branch=<name>`::
Point the newly created `HEAD` to _<name>_ branch instead of the branch
pointed to by the cloned repository's `HEAD`. In a non-bare repository,
this is the branch that will be checked out.
`--branch` can also take tags and detaches the `HEAD` at that commit
in the resulting repository.
`--revision=<rev>`::
Create a new repository, and fetch the history leading to the given
revision _<rev>_ (and nothing else), without making any remote-tracking
branch, and without making any local branch, and detach `HEAD` to
_<rev>_. The argument can be a ref name (e.g. `refs/heads/main` or
`refs/tags/v1.0`) that peels down to a commit, or a hexadecimal object
name.
This option is incompatible with `--branch` and `--mirror`.
`-u<upload-pack>`::
`--upload-pack=<upload-pack>`::
Specify a non-default path for the command run on the other end when the
repository to clone from is accessed via ssh.
`--template=<template-directory>`::
Specify the directory from which templates will be used;
(See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].)
`-c<key>=<value>`::
`--config=<key>=<value>`::
Set a configuration variable in the newly-created repository;
this takes effect immediately after the repository is
initialized, but before the remote history is fetched or any
files checked out. The _<key>_ is in the same format as expected by
linkgit:git-config[1] (e.g., `core.eol=true`). If multiple
values are given for the same key, each value will be written to
the config file. This makes it safe, for example, to add
additional fetch refspecs to the origin remote.
+
Due to limitations of the current implementation, some configuration
variables do not take effect until after the initial fetch and checkout.
Configuration variables known to not take effect are:
`remote.<name>.mirror` and `remote.<name>.tagOpt`. Use the
corresponding `--mirror` and `--no-tags` options instead.
`--depth=<depth>`::
Create a 'shallow' clone with a history truncated to the
specified number of commits. Implies `--single-branch` unless
`--no-single-branch` is given to fetch the histories near the
tips of all branches. If you want to clone submodules shallowly,
also pass `--shallow-submodules`.
`--shallow-since=<date>`::
Create a shallow clone with a history after the specified time.
`--shallow-exclude=<ref>`::
Create a shallow clone with a history, excluding commits
reachable from a specified remote branch or tag. This option
can be specified multiple times.
`--single-branch`::
`--no-single-branch`::
Clone only the history leading to the tip of a single branch,
either specified by the `--branch` option or the primary
branch remote's `HEAD` points at.
Further fetches into the resulting repository will only update the
remote-tracking branch for the branch this option was used for the
initial cloning. If the `HEAD` at the remote did not point at any
branch when `--single-branch` clone was made, no remote-tracking
branch is created.
`--tags`::
`--no-tags`::
Control whether or not tags will be cloned. When `--no-tags` is
given, the option will be become permanent by setting the
`remote.<remote>.tagOpt=--no-tags` configuration. This ensures that
future `git pull` and `git fetch` won't follow any tags. Subsequent
explicit tag fetches will still work (see linkgit:git-fetch[1]).
+
By default, tags are cloned and passing `--tags` is thus typically a
no-op, unless it cancels out a previous `--no-tags`.
+
Can be used in conjunction with `--single-branch` to clone and
maintain a branch with no references other than a single cloned
branch. This is useful e.g. to maintain minimal clones of the default
branch of some repository for search indexing.
`--recurse-submodules[=<pathspec>]`::
After the clone is created, initialize and clone submodules
within based on the provided _<pathspec>_. If no `=<pathspec>` is
provided, all submodules are initialized and cloned.
This option can be given multiple times for pathspecs consisting
of multiple entries. The resulting clone has `submodule.active` set to
the provided pathspec, or "`.`" (meaning all submodules) if no
pathspec is provided.
+
Submodules are initialized and cloned using their default settings. This is
equivalent to running
`git submodule update --init --recursive <pathspec>` immediately after
the clone is finished. This option is ignored if the cloned repository does
not have a worktree/checkout (i.e. if any of `--no-checkout`/`-n`, `--bare`,
or `--mirror` is given)
`--shallow-submodules`::
`--no-shallow-submodules`::
All submodules which are cloned will be shallow with a depth of 1.
`--remote-submodules`::
`--no-remote-submodules`::
All submodules which are cloned will use the status of the submodule's
remote-tracking branch to update the submodule, rather than the
superproject's recorded SHA-1. Equivalent to passing `--remote` to
`git submodule update`.
`--separate-git-dir=<git-dir>`::
Instead of placing the cloned repository where it is supposed
to be, place the cloned repository at the specified directory,
then make a filesystem-agnostic Git symbolic link to there.
The result is Git repository can be separated from working
tree.
`--ref-format=<ref-format>`::
Specify the given ref storage format for the repository. The valid values are:
+
include::ref-storage-format.adoc[]
`-j<n>`::
`--jobs=<n>`::
The number of submodules fetched at the same time.
Defaults to the `submodule.fetchJobs` option.
_<repository>_::
The (possibly remote) _<repository>_ to clone from. See the
<<URLS,GIT URLS>> section below for more information on specifying
repositories.
_<directory>_::
The name of a new directory to clone into. The "humanish"
part of the source repository is used if no _<directory>_ is
explicitly given (`repo` for `/path/to/repo.git` and `foo`
for `host.xz:foo/.git`). Cloning into an existing directory
is only allowed if the directory is empty.
`--bundle-uri=<uri>`::
Before fetching from the remote, fetch a bundle from the given
_<uri>_ and unbundle the data into the local repository. The refs
in the bundle will be stored under the hidden `refs/bundle/*`
namespace. This option is incompatible with `--depth`,
`--shallow-since`, and `--shallow-exclude`.
:git-clone: 1
include::urls.adoc[]
EXAMPLES
--------
* Clone from upstream:
+
------------
$ git clone git://git.kernel.org/pub/scm/.../linux.git my-linux
$ cd my-linux
$ make
------------
* Make a local clone that borrows from the current directory, without checking things out:
+
------------
$ git clone -l -s -n . ../copy
$ cd ../copy
$ git show-branch
------------
* Clone from upstream while borrowing from an existing local directory:
+
------------
$ git clone --reference /git/linux.git \
git://git.kernel.org/pub/scm/.../linux.git \
my-linux
$ cd my-linux
------------
* Create a bare repository to publish your changes to the public:
+
------------
$ git clone --bare -l /home/proj/.git /pub/scm/proj.git
------------
* Clone a local repository from a different user:
+
------------
$ git clone --no-local /home/otheruser/proj.git /pub/scm/proj.git
------------
CONFIGURATION
-------------
include::includes/cmd-config-section-all.adoc[]
include::config/init.adoc[]
include::config/clone.adoc[]
GIT
---
Part of the linkgit:git[1] suite

89
app/src/main/assets/manpages/git-column.txt Normal file
View File

@@ -0,0 +1,89 @@
git-column(1)
=============
NAME
----
git-column - Display data in columns
SYNOPSIS
--------
[verse]
'git column' [--command=<name>] [--[raw-]mode=<mode>] [--width=<width>]
[--indent=<string>] [--nl=<string>] [--padding=<n>]
DESCRIPTION
-----------
This command formats the lines of its standard input into a table with
multiple columns. Each input line occupies one cell of the table. It
is used internally by other git commands to format output into
columns.
OPTIONS
-------
--command=<name>::
Look up layout mode using configuration variable column.<name> and
column.ui.
--mode=<mode>::
Specify layout mode. See configuration variable column.ui for option
syntax in linkgit:git-config[1].
--raw-mode=<n>::
Same as --mode but take mode encoded as a number. This is mainly used
by other commands that have already parsed layout mode.
--width=<width>::
Specify the terminal width. By default 'git column' will detect the
terminal width, or fall back to 80 if it is unable to do so.
--indent=<string>::
String to be printed at the beginning of each line.
--nl=<string>::
String to be printed at the end of each line,
including newline character.
--padding=<N>::
The number of spaces between columns. One space by default.
EXAMPLES
--------
Format data by columns:
------------
$ seq 1 24 | git column --mode=column --padding=5
1 4 7 10 13 16 19 22
2 5 8 11 14 17 20 23
3 6 9 12 15 18 21 24
------------
Format data by rows:
------------
$ seq 1 21 | git column --mode=row --padding=5
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
------------
List some tags in a table with unequal column widths:
------------
$ git tag --list 'v2.4.*' --column=row,dense
v2.4.0 v2.4.0-rc0 v2.4.0-rc1 v2.4.0-rc2 v2.4.0-rc3
v2.4.1 v2.4.10 v2.4.11 v2.4.12 v2.4.2
v2.4.3 v2.4.4 v2.4.5 v2.4.6 v2.4.7
v2.4.8 v2.4.9
------------
CONFIGURATION
-------------
include::includes/cmd-config-section-all.adoc[]
include::config/column.adoc[]
GIT
---
Part of the linkgit:git[1] suite

164
app/src/main/assets/manpages/git-commit-graph.txt Normal file
View File

@@ -0,0 +1,164 @@
git-commit-graph(1)
===================
NAME
----
git-commit-graph - Write and verify Git commit-graph files
SYNOPSIS
--------
[verse]
'git commit-graph verify' [--object-dir <dir>] [--shallow] [--[no-]progress]
'git commit-graph write' [--object-dir <dir>] [--append]
[--split[=<strategy>]] [--reachable | --stdin-packs | --stdin-commits]
[--changed-paths] [--[no-]max-new-filters <n>] [--[no-]progress]
<split-options>
DESCRIPTION
-----------
Manage the serialized commit-graph file.
OPTIONS
-------
--object-dir::
Use given directory for the location of packfiles and commit-graph
file. This parameter exists to specify the location of an alternate
that only has the objects directory, not a full `.git` directory. The
commit-graph file is expected to be in the `<dir>/info` directory and
the packfiles are expected to be in `<dir>/pack`. If the directory
could not be made into an absolute path, or does not match any known
object directory, `git commit-graph ...` will exit with non-zero
status.
--progress::
--no-progress::
Turn progress on/off explicitly. If neither is specified, progress is
shown if standard error is connected to a terminal.
COMMANDS
--------
'write'::
Write a commit-graph file based on the commits found in packfiles. If
the config option `core.commitGraph` is disabled, then this command will
output a warning, then return success without writing a commit-graph file.
+
With the `--stdin-packs` option, generate the new commit graph by
walking objects only in the specified pack-indexes. (Cannot be combined
with `--stdin-commits` or `--reachable`.)
+
With the `--stdin-commits` option, generate the new commit graph by
walking commits starting at the commits specified in stdin as a list
of OIDs in hex, one OID per line. OIDs that resolve to non-commits
(either directly, or by peeling tags) are silently ignored. OIDs that
are malformed, or do not exist generate an error. (Cannot be combined
with `--stdin-packs` or `--reachable`.)
+
With the `--reachable` option, generate the new commit graph by walking
commits starting at all refs. (Cannot be combined with `--stdin-commits`
or `--stdin-packs`.)
+
With the `--append` option, include all commits that are present in the
existing commit-graph file.
+
With the `--changed-paths` option, compute and write information about the
paths changed between a commit and its first parent. This operation can
take a while on large repositories. It provides significant performance gains
for getting history of a directory or a file with `git log -- <path>`. If
this option is given, future commit-graph writes will automatically assume
that this option was intended. Use `--no-changed-paths` to stop storing this
data. `--changed-paths` is implied by config `commitGraph.changedPaths=true`.
+
With the `--max-new-filters=<n>` option, generate at most `n` new Bloom
filters (if `--changed-paths` is specified). If `n` is `-1`, no limit is
enforced. Only commits present in the new layer count against this
limit. To retroactively compute Bloom filters over earlier layers, it is
advised to use `--split=replace`. Overrides the `commitGraph.maxNewFilters`
configuration.
+
With the `--split[=<strategy>]` option, write the commit-graph as a
chain of multiple commit-graph files stored in
`<dir>/info/commit-graphs`. Commit-graph layers are merged based on the
strategy and other splitting options. The new commits not already in the
commit-graph are added in a new "tip" file. This file is merged with the
existing file if the following merge conditions are met:
+
* If `--split=no-merge` is specified, a merge is never performed, and
the remaining options are ignored. `--split=replace` overwrites the
existing chain with a new one. A bare `--split` defers to the remaining
options. (Note that merging a chain of commit graphs replaces the
existing chain with a length-1 chain where the first and only
incremental holds the entire graph).
+
* If `--size-multiple=<X>` is not specified, let `X` equal 2. If the new
tip file would have `N` commits and the previous tip has `M` commits and
`X` times `N` is greater than `M`, instead merge the two files into a
single file.
+
* If `--max-commits=<M>` is specified with `M` a positive integer, and the
new tip file would have more than `M` commits, then instead merge the new
tip with the previous tip.
+
Finally, if `--expire-time=<datetime>` is not specified, let `datetime`
be the current time. After writing the split commit-graph, delete all
unused commit-graph whose modified times are older than `datetime`.
'verify'::
Read the commit-graph file and verify its contents against the object
database. Used to check for corrupted data.
+
With the `--shallow` option, only check the tip commit-graph file in
a chain of split commit-graphs.
EXAMPLES
--------
* Write a commit-graph file for the packed commits in your local `.git`
directory.
+
------------------------------------------------
$ git commit-graph write
------------------------------------------------
* Write a commit-graph file, extending the current commit-graph file
using commits in `<pack-index>`.
+
------------------------------------------------
$ echo <pack-index> | git commit-graph write --stdin-packs
------------------------------------------------
* Write a commit-graph file containing all reachable commits.
+
------------------------------------------------
$ git show-ref -s | git commit-graph write --stdin-commits
------------------------------------------------
* Write a commit-graph file containing all commits in the current
commit-graph file along with those reachable from `HEAD`.
+
------------------------------------------------
$ git rev-parse HEAD | git commit-graph write --stdin-commits --append
------------------------------------------------
CONFIGURATION
-------------
include::includes/cmd-config-section-all.adoc[]
include::config/commitgraph.adoc[]
FILE FORMAT
-----------
see linkgit:gitformat-commit-graph[5].
GIT
---
Part of the linkgit:git[1] suite

101
app/src/main/assets/manpages/git-commit-tree.txt Normal file
View File

@@ -0,0 +1,101 @@
git-commit-tree(1)
==================
NAME
----
git-commit-tree - Create a new commit object
SYNOPSIS
--------
[verse]
'git commit-tree' <tree> [(-p <parent>)...]
'git commit-tree' [(-p <parent>)...] [-S[<keyid>]] [(-m <message>)...]
[(-F <file>)...] <tree>
DESCRIPTION
-----------
This is usually not what an end user wants to run directly. See
linkgit:git-commit[1] instead.
Creates a new commit object based on the provided tree object and
emits the new commit object id on stdout. The log message is read
from the standard input, unless `-m` or `-F` options are given.
The `-m` and `-F` options can be given any number of times, in any
order. The commit log message will be composed in the order in which
the options are given.
A commit object may have any number of parents. With exactly one
parent, it is an ordinary commit. Having more than one parent makes
the commit a merge between several lines of history. Initial (root)
commits have no parents.
While a tree represents a particular directory state of a working
directory, a commit represents that state in "time", and explains how
to get there.
Normally a commit would identify a new "HEAD" state, and while Git
doesn't care where you save the note about that state, in practice we
tend to just write the result to the file that is pointed at by
`.git/HEAD`, so that we can always see what the last committed
state was.
OPTIONS
-------
<tree>::
An existing tree object.
-p <parent>::
Each `-p` indicates the id of a parent commit object.
-m <message>::
A paragraph in the commit log message. This can be given more than
once and each <message> becomes its own paragraph.
-F <file>::
Read the commit log message from the given file. Use `-` to read
from the standard input. This can be given more than once and the
content of each file becomes its own paragraph.
-S[<keyid>]::
--gpg-sign[=<keyid>]::
--no-gpg-sign::
GPG-sign commits. The `keyid` argument is optional and
defaults to the committer identity; if specified, it must be
stuck to the option without a space. `--no-gpg-sign` is useful to
countermand a `--gpg-sign` option given earlier on the command line.
Commit Information
------------------
A commit encapsulates:
- all parent object ids
- author name, email and date
- committer name and email and the commit time.
A commit comment is read from stdin. If a changelog
entry is not provided via "<" redirection, 'git commit-tree' will just wait
for one to be entered and terminated with ^D.
include::date-formats.adoc[]
Discussion
----------
include::i18n.adoc[]
FILES
-----
/etc/mailname
SEE ALSO
--------
linkgit:git-write-tree[1]
linkgit:git-commit[1]
GIT
---
Part of the linkgit:git[1] suite

595
app/src/main/assets/manpages/git-commit.txt Normal file
View File

@@ -0,0 +1,595 @@
git-commit(1)
=============
NAME
----
git-commit - Record changes to the repository
SYNOPSIS
--------
[synopsis]
git commit [-a | --interactive | --patch] [-s] [-v] [-u[<mode>]] [--amend]
[--dry-run] [(-c | -C | --squash) <commit> | --fixup [(amend|reword):]<commit>]
[-F <file> | -m <msg>] [--reset-author] [--allow-empty]
[--allow-empty-message] [--no-verify] [-e] [--author=<author>]
[--date=<date>] [--cleanup=<mode>] [--[no-]status]
[-i | -o] [--pathspec-from-file=<file> [--pathspec-file-nul]]
[(--trailer <token>[(=|:)<value>])...] [-S[<keyid>]]
[--] [<pathspec>...]
DESCRIPTION
-----------
Create a new commit containing the current contents of the index and
the given log message describing the changes. The new commit is a
direct child of HEAD, usually the tip of the current branch, and the
branch is updated to point to it (unless no branch is associated with
the working tree, in which case `HEAD` is "detached" as described in
linkgit:git-checkout[1]).
The content to be committed can be specified in several ways:
1. by using linkgit:git-add[1] to incrementally "add" changes to the
index before using the `commit` command (Note: even modified files
must be "added");
2. by using linkgit:git-rm[1] to remove files from the working tree
and the index, again before using the `commit` command;
3. by listing files as arguments to the `commit` command
(without `--interactive` or `--patch` switch), in which
case the commit will ignore changes staged in the index, and instead
record the current content of the listed files (which must already
be known to Git);
4. by using the `-a` switch with the `commit` command to automatically
"add" changes from all known files (i.e. all files that are already
listed in the index) and to automatically "rm" files in the index
that have been removed from the working tree, and then perform the
actual commit;
5. by using the `--interactive` or `--patch` switches with the `commit` command
to decide one by one which files or hunks should be part of the commit
in addition to contents in the index,
before finalizing the operation. See the ``Interactive Mode'' section of
linkgit:git-add[1] to learn how to operate these modes.
The `--dry-run` option can be used to obtain a
summary of what is included by any of the above for the next
commit by giving the same set of parameters (options and paths).
If you make a commit and then find a mistake immediately after
that, you can recover from it with `git reset`.
:git-commit: 1
OPTIONS
-------
`-a`::
`--all`::
Automatically stage files that have
been modified and deleted, but new files you have not
told Git about are not affected.
`-p`::
`--patch`::
Use the interactive patch selection interface to choose
which changes to commit. See linkgit:git-add[1] for
details.
include::diff-context-options.adoc[]
`-C <commit>`::
`--reuse-message=<commit>`::
Take an existing _<commit>_ object, and reuse the log message
and the authorship information (including the timestamp)
when creating the commit.
`-c <commit>`::
`--reedit-message=<commit>`::
Like `-C`, but with `-c` the editor is invoked, so that
the user can further edit the commit message.
`--fixup=[(amend|reword):]<commit>`::
Create a new commit which "fixes up" _<commit>_ when applied with
`git rebase --autosquash`. Plain `--fixup=<commit>` creates a
"fixup!" commit which changes the content of _<commit>_ but leaves
its log message untouched. `--fixup=amend:<commit>` is similar but
creates an "amend!" commit which also replaces the log message of
_<commit>_ with the log message of the "amend!" commit.
`--fixup=reword:<commit>` creates an "amend!" commit which
replaces the log message of _<commit>_ with its own log message
but makes no changes to the content of _<commit>_.
+
The commit created by plain `--fixup=<commit>` has a title
composed of "fixup!" followed by the title of _<commit>_,
and is recognized specially by `git rebase --autosquash`. The `-m`
option may be used to supplement the log message of the created
commit, but the additional commentary will be thrown away once the
"fixup!" commit is squashed into _<commit>_ by
`git rebase --autosquash`.
+
The commit created by `--fixup=amend:<commit>` is similar but its
title is instead prefixed with "amend!". The log message of
_<commit>_ is copied into the log message of the "amend!" commit and
opened in an editor so it can be refined. When `git rebase
--autosquash` squashes the "amend!" commit into _<commit>_, the
log message of _<commit>_ is replaced by the refined log message
from the "amend!" commit. It is an error for the "amend!" commit's
log message to be empty unless `--allow-empty-message` is
specified.
+
`--fixup=reword:<commit>` is shorthand for `--fixup=amend:<commit>
--only`. It creates an "amend!" commit with only a log message
(ignoring any changes staged in the index). When squashed by `git
rebase --autosquash`, it replaces the log message of _<commit>_
without making any other changes.
+
Neither "fixup!" nor "amend!" commits change authorship of
_<commit>_ when applied by `git rebase --autosquash`.
See linkgit:git-rebase[1] for details.
`--squash=<commit>`::
Construct a commit message for use with `git rebase --autosquash`.
The commit message title is taken from the specified
commit with a prefix of "squash! ". Can be used with additional
commit message options (`-m`/`-c`/`-C`/`-F`). See
linkgit:git-rebase[1] for details.
`--reset-author`::
When used with `-C`/`-c`/`--amend` options, or when committing after a
conflicting cherry-pick, declare that the authorship of the
resulting commit now belongs to the committer. This also renews
the author timestamp.
`--short`::
When doing a dry-run, give the output in the short-format. See
linkgit:git-status[1] for details. Implies `--dry-run`.
`--branch`::
Show the branch and tracking info even in short-format. See
linkgit:git-status[1] for details.
`--porcelain`::
When doing a dry-run, give the output in a porcelain-ready
format. See linkgit:git-status[1] for details. Implies
`--dry-run`.
`--long`::
When doing a dry-run, give the output in the long-format. This
is the default output of linkgit:git-status[1]. Implies
`--dry-run`.
`-z`::
`--null`::
When showing `short` or `porcelain` linkgit:git-status[1] output, print the
filename verbatim and terminate the entries with _NUL_, instead of _LF_.
If no format is given, implies the `--porcelain` output format.
Without the `-z` option, filenames with "unusual" characters are
quoted as explained for the configuration variable `core.quotePath`
(see linkgit:git-config[1]).
`-F <file>`::
`--file=<file>`::
Take the commit message from _<file>_. Use '-' to
read the message from the standard input.
`--author=<author>`::
Override the commit author. Specify an explicit author using the
standard `A U Thor <author@example.com>` format. Otherwise _<author>_
is assumed to be a pattern and is used to search for an existing
commit by that author (i.e. `git rev-list --all -i --author=<author>`);
the commit author is then copied from the first such commit found.
`--date=<date>`::
Override the author date used in the commit.
`-m <msg>`::
`--message=<msg>`::
Use _<msg>_ as the commit message.
If multiple `-m` options are given, their values are
concatenated as separate paragraphs.
+
The `-m` option is mutually exclusive with `-c`, `-C`, and `-F`.
`-t <file>`::
`--template=<file>`::
When editing the commit message, start the editor with the
contents in _<file>_. The `commit.template` configuration
variable is often used to give this option implicitly to the
command. This mechanism can be used by projects that want to
guide participants with some hints on what to write in the message
in what order. If the user exits the editor without editing the
message, the commit is aborted. This has no effect when a message
is given by other means, e.g. with the `-m` or `-F` options.
include::signoff-option.adoc[]
`--trailer <token>[(=|:)<value>]`::
Specify a (_<token>_, _<value>_) pair that should be applied as a
trailer. (e.g. `git commit --trailer "Signed-off-by:C O Mitter \
<committer@example.com>" --trailer "Helped-by:C O Mitter \
<committer@example.com>"` will add the `Signed-off-by` trailer
and the `Helped-by` trailer to the commit message.)
The `trailer.*` configuration variables
(linkgit:git-interpret-trailers[1]) can be used to define if
a duplicated trailer is omitted, where in the run of trailers
each trailer would appear, and other details.
`-n`::
`--verify`::
`--no-verify`::
Bypass the `pre-commit` and `commit-msg` hooks.
See also linkgit:githooks[5].
`--allow-empty`::
Usually recording a commit that has the exact same tree as its
sole parent commit is a mistake, and the command prevents you
from making such a commit. This option bypasses the safety, and
is primarily for use by foreign SCM interface scripts.
`--allow-empty-message`::
Create a commit with an empty commit message without using plumbing
commands like linkgit:git-commit-tree[1]. Like `--allow-empty`, this
command is primarily for use by foreign SCM interface scripts.
`--cleanup=<mode>`::
Determine how the supplied commit message should be
cleaned up before committing. The '<mode>' can be `strip`,
`whitespace`, `verbatim`, `scissors` or `default`.
+
--
`strip`::
Strip leading and trailing empty lines, trailing whitespace,
commentary and collapse consecutive empty lines.
`whitespace`::
Same as `strip` except #commentary is not removed.
`verbatim`::
Do not change the message at all.
`scissors`::
Same as `whitespace` except that everything from (and including)
the line found below is truncated, if the message is to be edited.
"`#`" can be customized with `core.commentChar`.
# ------------------------ >8 ------------------------
`default`::
Same as `strip` if the message is to be edited.
Otherwise `whitespace`.
--
+
The default can be changed by the `commit.cleanup` configuration
variable (see linkgit:git-config[1]).
`-e`::
`--edit`::
Let the user further edit the message taken from _<file>_
with `-F <file>`, command line with `-m <message>`, and
from _<commit>_ with `-C <commit>`.
`--no-edit`::
Use the selected commit message without launching an editor.
For example, `git commit --amend --no-edit` amends a commit
without changing its commit message.
`--amend`::
Replace the tip of the current branch by creating a new
commit. The recorded tree is prepared as usual (including
the effect of the `-i` and `-o` options and explicit
pathspec), and the message from the original commit is used
as the starting point, instead of an empty message, when no
other message is specified from the command line via options
such as `-m`, `-F`, `-c`, etc. The new commit has the same
parents and author as the current one (the `--reset-author`
option can countermand this).
+
--
It is a rough equivalent for:
------
$ git reset --soft HEAD^
$ ... do something else to come up with the right tree ...
$ git commit -c ORIG_HEAD
------
but can be used to amend a merge commit.
--
+
You should understand the implications of rewriting history if you
amend a commit that has already been published. (See the "RECOVERING
FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
`--no-post-rewrite`::
Bypass the `post-rewrite` hook.
`-i`::
`--include`::
Before making a commit out of staged contents so far,
stage the contents of paths given on the command line
as well. This is usually not what you want unless you
are concluding a conflicted merge.
`-o`::
`--only`::
Make a commit by taking the updated working tree contents
of the paths specified on the
command line, disregarding any contents that have been
staged for other paths. This is the default mode of operation of
`git commit` if any paths are given on the command line,
in which case this option can be omitted.
If this option is specified together with `--amend`, then
no paths need to be specified, which can be used to amend
the last commit without committing changes that have
already been staged. If used together with `--allow-empty`
paths are also not required, and an empty commit will be created.
`--pathspec-from-file=<file>`::
Pass pathspec in _<file>_ instead of commandline args. If
_<file>_ is exactly `-` then standard input is used. Pathspec
elements are separated by _LF_ or _CR_/_LF_. Pathspec elements can be
quoted as explained for the configuration variable `core.quotePath`
(see linkgit:git-config[1]). See also `--pathspec-file-nul` and
global `--literal-pathspecs`.
`--pathspec-file-nul`::
Only meaningful with `--pathspec-from-file`. Pathspec elements are
separated with _NUL_ character and all other characters are taken
literally (including newlines and quotes).
`-u[<mode>]`::
`--untracked-files[=<mode>]`::
Show untracked files.
+
--
The _<mode>_ parameter is optional (defaults to `all`), and is used to
specify the handling of untracked files; when `-u` is not used, the
default is `normal`, i.e. show untracked files and directories.
The possible options are:
`no`:: Show no untracked files
`normal`:: Shows untracked files and directories
`all`:: Also shows individual files in untracked directories.
All usual spellings for Boolean value `true` are taken as `normal`
and `false` as `no`.
The default can be changed using the `status.showUntrackedFiles`
configuration variable documented in linkgit:git-config[1].
--
`-v`::
`--verbose`::
Show unified diff between the `HEAD` commit and what
would be committed at the bottom of the commit message
template to help the user describe the commit by reminding
what changes the commit has.
Note that this diff output doesn't have its
lines prefixed with `#`. This diff will not be a part
of the commit message. See the `commit.verbose` configuration
variable in linkgit:git-config[1].
+
If specified twice, show in addition the unified diff between
what would be committed and the worktree files, i.e. the unstaged
changes to tracked files.
`-q`::
`--quiet`::
Suppress commit summary message.
`--dry-run`::
Do not create a commit, but show a list of paths that are
to be committed, paths with local changes that will be left
uncommitted and paths that are untracked.
`--status`::
Include the output of linkgit:git-status[1] in the commit
message template when using an editor to prepare the commit
message. Defaults to on, but can be used to override
configuration variable `commit.status`.
`--no-status`::
Do not include the output of linkgit:git-status[1] in the
commit message template when using an editor to prepare the
default commit message.
`-S[<key-id>]`::
`--gpg-sign[=<key-id>]`::
`--no-gpg-sign`::
GPG-sign commits. The _<key-id>_ is optional and
defaults to the committer identity; if specified, it must be
stuck to the option without a space. `--no-gpg-sign` is useful to
countermand both `commit.gpgSign` configuration variable, and
earlier `--gpg-sign`.
`--`::
Do not interpret any more arguments as options.
`<pathspec>...`::
When _<pathspec>_ is given on the command line, commit the contents of
the files that match the pathspec without recording the changes
already added to the index. The contents of these files are also
staged for the next commit on top of what have been staged before.
+
For more details, see the 'pathspec' entry in linkgit:gitglossary[7].
EXAMPLES
--------
When recording your own work, the contents of modified files in
your working tree are temporarily stored to a staging area
called the "index" with `git add`. A file can be
reverted back, only in the index but not in the working tree,
to that of the last commit with `git restore --staged <file>`,
which effectively reverts `git add` and prevents the changes to
this file from participating in the next commit. After building
the state to be committed incrementally with these commands,
`git commit` (without any pathname parameter) is used to record what
has been staged so far. This is the most basic form of the
command. An example:
------------
$ edit hello.c
$ git rm goodbye.c
$ git add hello.c
$ git commit
------------
Instead of staging files after each individual change, you can
tell `git commit` to notice the changes to the files whose
contents are tracked in
your working tree and do corresponding `git add` and `git rm`
for you. That is, this example does the same as the earlier
example if there is no other change in your working tree:
------------
$ edit hello.c
$ rm goodbye.c
$ git commit -a
------------
The command `git commit -a` first looks at your working tree,
notices that you have modified `hello.c` and removed `goodbye.c`,
and performs necessary `git add` and `git rm` for you.
After staging changes to many files, you can alter the order the
changes are recorded in, by giving pathnames to `git commit`.
When pathnames are given, the command makes a commit that
only records the changes made to the named paths:
------------
$ edit hello.c hello.h
$ git add hello.c hello.h
$ edit Makefile
$ git commit Makefile
------------
This makes a commit that records the modification to `Makefile`.
The changes staged for `hello.c` and `hello.h` are not included
in the resulting commit. However, their changes are not lost --
they are still staged and merely held back. After the above
sequence, if you do:
------------
$ git commit
------------
this second commit would record the changes to `hello.c` and
`hello.h` as expected.
After a merge (initiated by `git merge` or `git pull`) stops
because of conflicts, cleanly merged
paths are already staged to be committed for you, and paths that
conflicted are left in unmerged state. You would have to first
check which paths are conflicting with `git status`
and after fixing them manually in your working tree, you would
stage the result as usual with `git add`:
------------
$ git status | grep unmerged
unmerged: hello.c
$ edit hello.c
$ git add hello.c
------------
After resolving conflicts and staging the result, `git ls-files -u`
would stop mentioning the conflicted path. When you are done,
run `git commit` to finally record the merge:
------------
$ git commit
------------
As with the case to record your own changes, you can use `-a`
option to save typing. One difference is that during a merge
resolution, you cannot use `git commit` with pathnames to
alter the order the changes are committed, because the merge
should be recorded as a single commit. In fact, the command
refuses to run when given pathnames (but see `-i` option).
COMMIT INFORMATION
------------------
Author and committer information is taken from the following environment
variables, if set:
* `GIT_AUTHOR_NAME`
* `GIT_AUTHOR_EMAIL`
* `GIT_AUTHOR_DATE`
* `GIT_COMMITTER_NAME`
* `GIT_COMMITTER_EMAIL`
* `GIT_COMMITTER_DATE`
(nb "<", ">" and "\n"s are stripped)
The author and committer names are by convention some form of a personal name
(that is, the name by which other humans refer to you), although Git does not
enforce or require any particular form. Arbitrary Unicode may be used, subject
to the constraints listed above. This name has no effect on authentication; for
that, see the `credential.username` variable in linkgit:git-config[1].
In case (some of) these environment variables are not set, the information
is taken from the configuration items `user.name` and `user.email`, or, if not
present, the environment variable `EMAIL`, or, if that is not set,
system user name and the hostname used for outgoing mail (taken
from `/etc/mailname` and falling back to the fully qualified hostname when
that file does not exist).
The `author.name` and `committer.name` and their corresponding email options
override `user.name` and `user.email` if set and are overridden themselves by
the environment variables.
The typical usage is to set just the `user.name` and `user.email` variables;
the other options are provided for more complex use cases.
:git-commit: 1
include::date-formats.adoc[]
DISCUSSION
----------
Though not required, it's a good idea to begin the commit message
with a single short (no more than 50 characters) line summarizing the
change, followed by a blank line and then a more thorough description.
The text up to the first blank line in a commit message is treated
as the commit title, and that title is used throughout Git.
For example, linkgit:git-format-patch[1] turns a commit into email, and it uses
the title on the Subject line and the rest of the commit in the body.
include::i18n.adoc[]
ENVIRONMENT AND CONFIGURATION VARIABLES
---------------------------------------
The editor used to edit the commit log message will be chosen from the
`GIT_EDITOR` environment variable, the `core.editor` configuration variable, the
`VISUAL` environment variable, or the `EDITOR` environment variable (in that
order). See linkgit:git-var[1] for details.
include::includes/cmd-config-section-rest.adoc[]
include::config/commit.adoc[]
HOOKS
-----
This command can run `commit-msg`, `prepare-commit-msg`, `pre-commit`,
`post-commit` and `post-rewrite` hooks. See linkgit:githooks[5] for more
information.
FILES
-----
`$GIT_DIR/COMMIT_EDITMSG`::
This file contains the commit message of a commit in progress.
If `git commit` exits due to an error before creating a commit,
any commit message that has been provided by the user (e.g., in
an editor session) will be available in this file, but will be
overwritten by the next invocation of `git commit`.
SEE ALSO
--------
linkgit:git-add[1],
linkgit:git-rm[1],
linkgit:git-mv[1],
linkgit:git-merge[1],
linkgit:git-commit-tree[1]
GIT
---
Part of the linkgit:git[1] suite

658
app/src/main/assets/manpages/git-config.txt Normal file
View File

@@ -0,0 +1,658 @@
git-config(1)
=============
NAME
----
git-config - Get and set repository or global options
SYNOPSIS
--------
[verse]
'git config list' [<file-option>] [<display-option>] [--includes]
'git config get' [<file-option>] [<display-option>] [--includes] [--all] [--regexp] [--value=<pattern>] [--fixed-value] [--default=<default>] [--url=<url>] <name>
'git config set' [<file-option>] [--type=<type>] [--all] [--value=<pattern>] [--fixed-value] <name> <value>
'git config unset' [<file-option>] [--all] [--value=<pattern>] [--fixed-value] <name>
'git config rename-section' [<file-option>] <old-name> <new-name>
'git config remove-section' [<file-option>] <name>
'git config edit' [<file-option>]
'git config' [<file-option>] --get-colorbool <name> [<stdout-is-tty>]
DESCRIPTION
-----------
You can query/set/replace/unset options with this command. The name is
actually the section and the key separated by a dot, and the value will be
escaped.
Multiple lines can be added to an option by using the `--append` option.
If you want to update or unset an option which can occur on multiple
lines, `--value=<pattern>` (which is an extended regular expression,
unless the `--fixed-value` option is given) needs to be given. Only the
existing values that match the pattern are updated or unset. If
you want to handle the lines that do *not* match the pattern, just
prepend a single exclamation mark in front (see also <<EXAMPLES>>),
but note that this only works when the `--fixed-value` option is not
in use.
The `--type=<type>` option instructs 'git config' to ensure that incoming and
outgoing values are canonicalize-able under the given <type>. If no
`--type=<type>` is given, no canonicalization will be performed. Callers may
unset an existing `--type` specifier with `--no-type`.
When reading, the values are read from the system, global and
repository local configuration files by default, and options
`--system`, `--global`, `--local`, `--worktree` and
`--file <filename>` can be used to tell the command to read from only
that location (see <<FILES>>).
When writing, the new value is written to the repository local
configuration file by default, and options `--system`, `--global`,
`--worktree`, `--file <filename>` can be used to tell the command to
write to that location (you can say `--local` but that is the
default).
This command will fail with non-zero status upon error. Some exit
codes are:
- The section or key is invalid (ret=1),
- no section or name was provided (ret=2),
- the config file is invalid (ret=3),
- the config file cannot be written (ret=4),
- you try to unset an option which does not exist (ret=5),
- you try to unset/set an option for which multiple lines match (ret=5), or
- you try to use an invalid regexp (ret=6).
On success, the command returns the exit code 0.
A list of all available configuration variables can be obtained using the
`git help --config` command.
COMMANDS
--------
list::
List all variables set in config file, along with their values.
get::
Emits the value of the specified key. If key is present multiple times
in the configuration, emits the last value. If `--all` is specified,
emits all values associated with key. Returns error code 1 if key is
not present.
set::
Set value for one or more config options. By default, this command
refuses to write multi-valued config options. Passing `--all` will
replace all multi-valued config options with the new value, whereas
`--value=` will replace all config options whose values match the given
pattern.
unset::
Unset value for one or more config options. By default, this command
refuses to unset multi-valued keys. Passing `--all` will unset all
multi-valued config options, whereas `--value` will unset all config
options whose values match the given pattern.
rename-section::
Rename the given section to a new name.
remove-section::
Remove the given section from the configuration file.
edit::
Opens an editor to modify the specified config file; either
`--system`, `--global`, `--local` (default), `--worktree`, or
`--file <config-file>`.
[[OPTIONS]]
OPTIONS
-------
--replace-all::
Default behavior is to replace at most one line. This replaces
all lines matching the key (and optionally `--value=<pattern>`).
--append::
Adds a new line to the option without altering any existing
values. This is the same as providing '--value=^$' in `set`.
--comment <message>::
Append a comment at the end of new or modified lines.
+
If _<message>_ begins with one or more whitespaces followed
by "#", it is used as-is. If it begins with "#", a space is
prepended before it is used. Otherwise, a string " # " (a
space followed by a hash followed by a space) is prepended
to it. And the resulting string is placed immediately after
the value defined for the variable. The _<message>_ must
not contain linefeed characters (no multi-line comments are
permitted).
--all::
With `get`, return all values for a multi-valued key.
--regexp::
With `get`, interpret the name as a regular expression. Regular
expression matching is currently case-sensitive and done against a
canonicalized version of the key in which section and variable names
are lowercased, but subsection names are not.
--url=<URL>::
When given a two-part <name> as <section>.<key>, the value for
<section>.<URL>.<key> whose <URL> part matches the best to the
given URL is returned (if no such key exists, the value for
<section>.<key> is used as a fallback). When given just the
<section> as name, do so for all the keys in the section and
list them. Returns error code 1 if no value is found.
--global::
For writing options: write to global `~/.gitconfig` file
rather than the repository `.git/config`, write to
`$XDG_CONFIG_HOME/git/config` file if this file exists and the
`~/.gitconfig` file doesn't.
+
For reading options: read only from global `~/.gitconfig` and from
`$XDG_CONFIG_HOME/git/config` rather than from all available files.
+
See also <<FILES>>.
--system::
For writing options: write to system-wide
`$(prefix)/etc/gitconfig` rather than the repository
`.git/config`.
+
For reading options: read only from system-wide `$(prefix)/etc/gitconfig`
rather than from all available files.
+
See also <<FILES>>.
--local::
For writing options: write to the repository `.git/config` file.
This is the default behavior.
+
For reading options: read only from the repository `.git/config` rather than
from all available files.
+
See also <<FILES>>.
--worktree::
Similar to `--local` except that `$GIT_DIR/config.worktree` is
read from or written to if `extensions.worktreeConfig` is
enabled. If not it's the same as `--local`. Note that `$GIT_DIR`
is equal to `$GIT_COMMON_DIR` for the main working tree, but is of
the form `$GIT_DIR/worktrees/<id>/` for other working trees. See
linkgit:git-worktree[1] to learn how to enable
`extensions.worktreeConfig`.
-f <config-file>::
--file <config-file>::
For writing options: write to the specified file rather than the
repository `.git/config`.
+
For reading options: read only from the specified file rather than from all
available files.
+
See also <<FILES>>.
--blob <blob>::
Similar to `--file` but use the given blob instead of a file. E.g.
you can use 'master:.gitmodules' to read values from the file
'.gitmodules' in the master branch. See "SPECIFYING REVISIONS"
section in linkgit:gitrevisions[7] for a more complete list of
ways to spell blob names.
`--value=<pattern>`::
`--no-value`::
With `get`, `set`, and `unset`, match only against
_<pattern>_. The pattern is an extended regular expression unless
`--fixed-value` is given.
+
Use `--no-value` to unset _<pattern>_.
--fixed-value::
When used with `--value=<pattern>`, treat _<pattern>_ as
an exact string instead of a regular expression. This will restrict
the name/value pairs that are matched to only those where the value
is exactly equal to _<pattern>_.
--type <type>::
'git config' will ensure that any input or output is valid under the given
type constraint(s), and will canonicalize outgoing values in `<type>`'s
canonical form.
+
Valid `<type>`'s include:
+
- 'bool': canonicalize values `true`, `yes`, `on`, and positive
numbers as "true", and values `false`, `no`, `off` and `0` as
"false".
- 'int': canonicalize values as simple decimal numbers. An optional suffix of
'k', 'm', or 'g' will cause the value to be multiplied by 1024, 1048576, or
1073741824 upon input.
- 'bool-or-int': canonicalize according to either 'bool' or 'int', as described
above.
- 'path': canonicalize by expanding a leading `~` to the value of `$HOME` and
`~user` to the home directory for the specified user. This specifier has no
effect when setting the value (but you can use `git config section.variable
~/` from the command line to let your shell do the expansion.)
- 'expiry-date': canonicalize by converting from a fixed or relative date-string
to a timestamp. This specifier has no effect when setting the value.
- 'color': When getting a value, canonicalize by converting to an ANSI color
escape sequence. When setting a value, a sanity-check is performed to ensure
that the given value is canonicalize-able as an ANSI color, but it is written
as-is.
+
If the command is in `list` mode, then the `--type <type>` argument will apply
to each listed config value. If the value does not successfully parse in that
format, then it will be omitted from the list.
--bool::
--int::
--bool-or-int::
--path::
--expiry-date::
Historical options for selecting a type specifier. Prefer instead `--type`
(see above).
--no-type::
Un-sets the previously set type specifier (if one was previously set). This
option requests that 'git config' not canonicalize the retrieved variable.
`--no-type` has no effect without `--type=<type>` or `--<type>`.
-z::
--null::
For all options that output values and/or keys, always
end values with the null character (instead of a
newline). Use newline instead as a delimiter between
key and value. This allows for secure parsing of the
output without getting confused e.g. by values that
contain line breaks.
--name-only::
Output only the names of config variables for `list` or
`get`.
`--show-names`::
`--no-show-names`::
With `get`, show config keys in addition to their values. The
default is `--no-show-names` unless `--url` is given and there
are no subsections in _<name>_.
--show-origin::
Augment the output of all queried config options with the
origin type (file, standard input, blob, command line) and
the actual origin (config file path, ref, or blob id if
applicable).
--show-scope::
Similar to `--show-origin` in that it augments the output of
all queried config options with the scope of that value
(worktree, local, global, system, command).
--get-colorbool <name> [<stdout-is-tty>]::
Find the color setting for `<name>` (e.g. `color.diff`) and output
"true" or "false". `<stdout-is-tty>` should be either "true" or
"false", and is taken into account when configuration says
"auto". If `<stdout-is-tty>` is missing, then checks the standard
output of the command itself, and exits with status 0 if color
is to be used, or exits with status 1 otherwise.
When the color setting for `name` is undefined, the command uses
`color.ui` as fallback.
--includes::
--no-includes::
Respect `include.*` directives in config files when looking up
values. Defaults to `off` when a specific file is given (e.g.,
using `--file`, `--global`, etc) and `on` when searching all
config files.
--default <value>::
When using `get`, and the requested variable is not found, behave as if
<value> were the value assigned to that variable.
DEPRECATED MODES
----------------
The following modes have been deprecated in favor of subcommands. It is
recommended to migrate to the new syntax.
'git config <name>'::
Replaced by `git config get <name>`.
'git config <name> <value> [<value-pattern>]'::
Replaced by `git config set [--value=<pattern>] <name> <value>`.
-l::
--list::
Replaced by `git config list`.
--get <name> [<value-pattern>]::
Replaced by `git config get [--value=<pattern>] <name>`.
--get-all <name> [<value-pattern>]::
Replaced by `git config get [--value=<pattern>] --all <name>`.
--get-regexp <name-regexp>::
Replaced by `git config get --all --show-names --regexp <name-regexp>`.
--get-urlmatch <name> <URL>::
Replaced by `git config get --url=<URL> <name>`.
--get-color <name> [<default>]::
Replaced by `git config get --type=color [--default=<default>] <name>`.
--add <name> <value>::
Replaced by `git config set --append <name> <value>`.
--unset <name> [<value-pattern>]::
Replaced by `git config unset [--value=<pattern>] <name>`.
--unset-all <name> [<value-pattern>]::
Replaced by `git config unset [--value=<pattern>] --all <name>`.
--rename-section <old-name> <new-name>::
Replaced by `git config rename-section <old-name> <new-name>`.
--remove-section <name>::
Replaced by `git config remove-section <name>`.
-e::
--edit::
Replaced by `git config edit`.
CONFIGURATION
-------------
`pager.config` is only respected when listing configuration, i.e., when
using `list` or `get` which may return multiple results. The default is to use
a pager.
[[FILES]]
FILES
-----
By default, 'git config' will read configuration options from multiple
files:
$(prefix)/etc/gitconfig::
System-wide configuration file.
$XDG_CONFIG_HOME/git/config::
~/.gitconfig::
User-specific configuration files. When the XDG_CONFIG_HOME environment
variable is not set or empty, $HOME/.config/ is used as
$XDG_CONFIG_HOME.
+
These are also called "global" configuration files. If both files exist, both
files are read in the order given above.
$GIT_DIR/config::
Repository specific configuration file.
$GIT_DIR/config.worktree::
This is optional and is only searched when
`extensions.worktreeConfig` is present in $GIT_DIR/config.
You may also provide additional configuration parameters when running any
git command by using the `-c` option. See linkgit:git[1] for details.
Options will be read from all of these files that are available. If the
global or the system-wide configuration files are missing or unreadable they
will be ignored. If the repository configuration file is missing or unreadable,
'git config' will exit with a non-zero error code. An error message is produced
if the file is unreadable, but not if it is missing.
The files are read in the order given above, with last value found taking
precedence over values read earlier. When multiple values are taken then all
values of a key from all files will be used.
By default, options are only written to the repository specific
configuration file. Note that this also affects options like `set`
and `unset`. *'git config' will only ever change one file at a time*.
You can limit which configuration sources are read from or written to by
specifying the path of a file with the `--file` option, or by specifying a
configuration scope with `--system`, `--global`, `--local`, or `--worktree`.
For more, see <<OPTIONS>> above.
[[SCOPES]]
SCOPES
------
Each configuration source falls within a configuration scope. The scopes
are:
system::
$(prefix)/etc/gitconfig
global::
$XDG_CONFIG_HOME/git/config
+
~/.gitconfig
local::
$GIT_DIR/config
worktree::
$GIT_DIR/config.worktree
command::
GIT_CONFIG_{COUNT,KEY,VALUE} environment variables (see <<ENVIRONMENT>>
below)
+
the `-c` option
With the exception of 'command', each scope corresponds to a command line
option: `--system`, `--global`, `--local`, `--worktree`.
When reading options, specifying a scope will only read options from the
files within that scope. When writing options, specifying a scope will write
to the files within that scope (instead of the repository specific
configuration file). See <<OPTIONS>> above for a complete description.
Most configuration options are respected regardless of the scope it is
defined in, but some options are only respected in certain scopes. See the
respective option's documentation for the full details.
Protected configuration
~~~~~~~~~~~~~~~~~~~~~~~
Protected configuration refers to the 'system', 'global', and 'command' scopes.
For security reasons, certain options are only respected when they are
specified in protected configuration, and ignored otherwise.
Git treats these scopes as if they are controlled by the user or a trusted
administrator. This is because an attacker who controls these scopes can do
substantial harm without using Git, so it is assumed that the user's environment
protects these scopes against attackers.
[[ENVIRONMENT]]
ENVIRONMENT
-----------
GIT_CONFIG_GLOBAL::
GIT_CONFIG_SYSTEM::
Take the configuration from the given files instead from global or
system-level configuration. See linkgit:git[1] for details.
GIT_CONFIG_NOSYSTEM::
Whether to skip reading settings from the system-wide
$(prefix)/etc/gitconfig file. See linkgit:git[1] for details.
See also <<FILES>>.
GIT_CONFIG_COUNT::
GIT_CONFIG_KEY_<n>::
GIT_CONFIG_VALUE_<n>::
If GIT_CONFIG_COUNT is set to a positive number, all environment pairs
GIT_CONFIG_KEY_<n> and GIT_CONFIG_VALUE_<n> up to that number will be
added to the process's runtime configuration. The config pairs are
zero-indexed. Any missing key or value is treated as an error. An empty
GIT_CONFIG_COUNT is treated the same as GIT_CONFIG_COUNT=0, namely no
pairs are processed. These environment variables will override values
in configuration files, but will be overridden by any explicit options
passed via `git -c`.
+
This is useful for cases where you want to spawn multiple git commands
with a common configuration but cannot depend on a configuration file,
for example when writing scripts.
GIT_CONFIG::
If no `--file` option is provided to `git config`, use the file
given by `GIT_CONFIG` as if it were provided via `--file`. This
variable has no effect on other Git commands, and is mostly for
historical compatibility; there is generally no reason to use it
instead of the `--file` option.
[[EXAMPLES]]
EXAMPLES
--------
Given a .git/config like this:
------------
#
# This is the config file, and
# a '#' or ';' character indicates
# a comment
#
; core variables
[core]
; Don't trust file modes
filemode = false
; Our diff algorithm
[diff]
external = /usr/local/bin/diff-wrapper
renames = true
; Proxy settings
[core]
gitproxy=proxy-command for kernel.org
gitproxy=default-proxy ; for all the rest
; HTTP
[http]
sslVerify
[http "https://weak.example.com"]
sslVerify = false
cookieFile = /tmp/cookie.txt
------------
you can set the filemode to true with
------------
% git config set core.filemode true
------------
The hypothetical proxy command entries actually have a postfix to discern
what URL they apply to. Here is how to change the entry for kernel.org
to "ssh".
------------
% git config set --value='for kernel.org$' core.gitproxy '"ssh" for kernel.org'
------------
This makes sure that only the key/value pair for kernel.org is replaced.
To delete the entry for renames, do
------------
% git config unset diff.renames
------------
If you want to delete an entry for a multivar (like core.gitproxy above),
you have to provide a regex matching the value of exactly one line.
To query the value for a given key, do
------------
% git config get core.filemode
------------
or, to query a multivar:
------------
% git config get --value="for kernel.org$" core.gitproxy
------------
If you want to know all the values for a multivar, do:
------------
% git config get --all --show-names core.gitproxy
------------
If you like to live dangerously, you can replace *all* core.gitproxy by a
new one with
------------
% git config set --all core.gitproxy ssh
------------
However, if you really only want to replace the line for the default proxy,
i.e. the one without a "for ..." postfix, do something like this:
------------
% git config set --value='! for ' core.gitproxy ssh
------------
To actually match only values with an exclamation mark, you have to
------------
% git config set --value='[!]' section.key value
------------
To add a new proxy, without altering any of the existing ones, use
------------
% git config set --append core.gitproxy '"proxy-command" for example.com'
------------
An example to use customized color from the configuration in your
script:
------------
#!/bin/sh
WS=$(git config get --type=color --default="blue reverse" color.diff.whitespace)
RESET=$(git config get --type=color --default="reset" "")
echo "${WS}your whitespace color or blue reverse${RESET}"
------------
For URLs in `https://weak.example.com`, `http.sslVerify` is set to
false, while it is set to `true` for all others:
------------
% git config get --type=bool --url=https://good.example.com http.sslverify
true
% git config get --type=bool --url=https://weak.example.com http.sslverify
false
% git config get --url=https://weak.example.com http
http.cookieFile /tmp/cookie.txt
http.sslverify false
------------
include::config.adoc[]
BUGS
----
When using the deprecated `[section.subsection]` syntax, changing a value
will result in adding a multi-line key instead of a change, if the subsection
is given with at least one uppercase character. For example when the config
looks like
--------
[section.subsection]
key = value1
--------
and running `git config section.Subsection.key value2` will result in
--------
[section.subsection]
key = value1
key = value2
--------
GIT
---
Part of the linkgit:git[1] suite

56
app/src/main/assets/manpages/git-count-objects.txt Normal file
View File

@@ -0,0 +1,56 @@
git-count-objects(1)
====================
NAME
----
git-count-objects - Count unpacked number of objects and their disk consumption
SYNOPSIS
--------
[verse]
'git count-objects' [-v] [-H | --human-readable]
DESCRIPTION
-----------
Counts the number of unpacked object files and disk space consumed by
them, to help you decide when it is a good time to repack.
OPTIONS
-------
-v::
--verbose::
Provide more detailed reports:
+
count: the number of loose objects
+
size: disk space consumed by loose objects, in KiB (unless -H is specified)
+
in-pack: the number of in-pack objects
+
packs: the number of pack files
+
size-pack: disk space consumed by the packs, in KiB (unless -H is specified)
+
prune-packable: the number of loose objects that are also present in
the packs. These objects could be pruned using `git prune-packed`.
+
garbage: the number of files in the object database that are neither valid loose
objects nor valid packs
+
size-garbage: disk space consumed by garbage files, in KiB (unless -H is
specified)
+
alternate: absolute path of alternate object databases; may appear
multiple times, one line per path. Note that if the path contains
non-printable characters, it may be surrounded by double-quotes and
contain C-style backslashed escape sequences.
-H::
--human-readable::
Print sizes in human readable format
GIT
---
Part of the linkgit:git[1] suite

30
app/src/main/assets/manpages/git-credential-cache--daemon.txt Normal file
View File

@@ -0,0 +1,30 @@
git-credential-cache{litdd}daemon(1)
====================================
NAME
----
git-credential-cache--daemon - Temporarily store user credentials in memory
SYNOPSIS
--------
[verse]
'git credential-cache{litdd}daemon' [--debug] <socket-path>
DESCRIPTION
-----------
NOTE: You probably don't want to invoke this command yourself; it is
started automatically when you use linkgit:git-credential-cache[1].
This command listens on the Unix domain socket specified by `<socket-path>`
for `git-credential-cache` clients. Clients may store and retrieve
credentials. Each credential is held for a timeout specified by the
client; once no credentials are held, the daemon exits.
If the `--debug` option is specified, the daemon does not close its
stderr stream, and may output extra diagnostics to it even after it has
begun listening for clients.
GIT
---
Part of the linkgit:git[1] suite

100
app/src/main/assets/manpages/git-credential-cache.txt Normal file
View File

@@ -0,0 +1,100 @@
git-credential-cache(1)
=======================
NAME
----
git-credential-cache - Helper to temporarily store passwords in memory
SYNOPSIS
--------
-----------------------------
git config credential.helper 'cache [<options>]'
-----------------------------
DESCRIPTION
-----------
This command caches credentials for use by future Git programs.
The stored credentials are kept in memory of the cache-daemon
process (instead of being written to a file) and are forgotten after a
configurable timeout. Credentials are forgotten sooner if the
cache-daemon dies, for example if the system restarts. The cache
is accessible over a Unix domain socket, restricted to the current
user by filesystem permissions.
You probably don't want to invoke this command directly; it is meant to
be used as a credential helper by other parts of Git. See
linkgit:gitcredentials[7] or `EXAMPLES` below.
OPTIONS
-------
--timeout <seconds>::
Number of seconds to cache credentials (default: 900).
--socket <path>::
Use `<path>` to contact a running cache daemon (or start a new
cache daemon if one is not started).
Defaults to `$XDG_CACHE_HOME/git/credential/socket` unless
`~/.git-credential-cache/` exists in which case
`~/.git-credential-cache/socket` is used instead.
If your home directory is on a network-mounted filesystem, you
may need to change this to a local filesystem. You must specify
an absolute path.
CONTROLLING THE DAEMON
----------------------
If you would like the daemon to exit early, forgetting all cached
credentials before their timeout, you can issue an `exit` action:
--------------------------------------
git credential-cache exit
--------------------------------------
EXAMPLES
--------
The point of this helper is to reduce the number of times you must type
your username or password. For example:
------------------------------------
$ git config credential.helper cache
$ git push http://example.com/repo.git
Username: <type your username>
Password: <type your password>
[work for 5 more minutes]
$ git push http://example.com/repo.git
[your credentials are used automatically]
------------------------------------
You can provide options via the credential.helper configuration
variable (this example increases the cache time to 1 hour):
-------------------------------------------------------
$ git config credential.helper 'cache --timeout=3600'
-------------------------------------------------------
PERSONAL ACCESS TOKENS
----------------------
Some remotes accept personal access tokens, which are randomly
generated and hard to memorise. They typically have a lifetime of weeks
or months.
git-credential-cache is inherently unsuitable for persistent storage of
personal access tokens. The credential will be forgotten after the cache
timeout. Even if you configure a long timeout, credentials will be
forgotten if the daemon dies.
To avoid frequently regenerating personal access tokens, configure a
credential helper with persistent storage. Alternatively, configure an
OAuth credential helper to generate credentials automatically. See
linkgit:gitcredentials[7], sections "Available helpers" and "OAuth".
GIT
---
Part of the linkgit:git[1] suite

110
app/src/main/assets/manpages/git-credential-store.txt Normal file
View File

@@ -0,0 +1,110 @@
git-credential-store(1)
=======================
NAME
----
git-credential-store - Helper to store credentials on disk
SYNOPSIS
--------
-------------------
git config credential.helper 'store [<options>]'
-------------------
DESCRIPTION
-----------
NOTE: Using this helper will store your passwords unencrypted on disk,
protected only by filesystem permissions. If this is not an acceptable
security tradeoff, try linkgit:git-credential-cache[1], or find a helper
that integrates with secure storage provided by your operating system.
This command stores credentials indefinitely on disk for use by future
Git programs.
You probably don't want to invoke this command directly; it is meant to
be used as a credential helper by other parts of git. See
linkgit:gitcredentials[7] or `EXAMPLES` below.
OPTIONS
-------
--file=<path>::
Use `<path>` to lookup and store credentials. The file will have its
filesystem permissions set to prevent other users on the system
from reading it, but it will not be encrypted or otherwise
protected. If not specified, credentials will be searched for from
`~/.git-credentials` and `$XDG_CONFIG_HOME/git/credentials`, and
credentials will be written to `~/.git-credentials` if it exists, or
`$XDG_CONFIG_HOME/git/credentials` if it exists and the former does
not. See also <<FILES>>.
[[FILES]]
FILES
-----
If not set explicitly with `--file`, there are two files where
git-credential-store will search for credentials in order of precedence:
~/.git-credentials::
User-specific credentials file.
$XDG_CONFIG_HOME/git/credentials::
Second user-specific credentials file. If '$XDG_CONFIG_HOME' is not set
or empty, `$HOME/.config/git/credentials` will be used. Any credentials
stored in this file will not be used if `~/.git-credentials` has a
matching credential as well. It is a good idea not to create this file
if you sometimes use older versions of Git that do not support it.
For credential lookups, the files are read in the order given above, with the
first matching credential found taking precedence over credentials found in
files further down the list.
Credential storage will by default write to the first existing file in the
list. If none of these files exist, `~/.git-credentials` will be created and
written to.
When erasing credentials, matching credentials will be erased from all files.
EXAMPLES
--------
The point of this helper is to reduce the number of times you must type
your username or password. For example:
------------------------------------------
$ git config credential.helper store
$ git push http://example.com/repo.git
Username: <type your username>
Password: <type your password>
[several days later]
$ git push http://example.com/repo.git
[your credentials are used automatically]
------------------------------------------
STORAGE FORMAT
--------------
The `.git-credentials` file is stored in plaintext. Each credential is
stored on its own line as a URL like:
------------------------------
https://user:pass@example.com
------------------------------
No other kinds of lines (e.g. empty lines or comment lines) are
allowed in the file, even though some may be silently ignored. Do
not view or edit the file with editors.
When Git needs authentication for a particular URL context,
credential-store will consider that context a pattern to match against
each entry in the credentials file. If the protocol, hostname, and
username (if we already have one) match, then the password is returned
to Git. See the discussion of configuration in linkgit:gitcredentials[7]
for more information.
GIT
---
Part of the linkgit:git[1] suite

294
app/src/main/assets/manpages/git-credential.txt Normal file
View File

@@ -0,0 +1,294 @@
git-credential(1)
=================
NAME
----
git-credential - Retrieve and store user credentials
SYNOPSIS
--------
------------------
'git credential' (fill|approve|reject|capability)
------------------
DESCRIPTION
-----------
Git has an internal interface for storing and retrieving credentials
from system-specific helpers, as well as prompting the user for
usernames and passwords. The git-credential command exposes this
interface to scripts which may want to retrieve, store, or prompt for
credentials in the same manner as Git. The design of this scriptable
interface models the internal C API; see credential.h for more
background on the concepts.
git-credential takes an "action" option on the command-line (one of
`fill`, `approve`, or `reject`) and reads a credential description
on stdin (see <<IOFMT,INPUT/OUTPUT FORMAT>>).
If the action is `fill`, git-credential will attempt to add "username"
and "password" attributes to the description by reading config files,
by contacting any configured credential helpers, or by prompting the
user. The username and password attributes of the credential
description are then printed to stdout together with the attributes
already provided.
If the action is `approve`, git-credential will send the description
to any configured credential helpers, which may store the credential
for later use.
If the action is `reject`, git-credential will send the description to
any configured credential helpers, which may erase any stored
credentials matching the description.
If the action is `capability`, git-credential will announce any capabilities
it supports to standard output.
If the action is `approve` or `reject`, no output should be emitted.
TYPICAL USE OF GIT CREDENTIAL
-----------------------------
An application using git-credential will typically use `git
credential` following these steps:
1. Generate a credential description based on the context.
+
For example, if we want a password for
`https://example.com/foo.git`, we might generate the following
credential description (don't forget the blank line at the end; it
tells `git credential` that the application finished feeding all the
information it has):
protocol=https
host=example.com
path=foo.git
2. Ask git-credential to give us a username and password for this
description. This is done by running `git credential fill`,
feeding the description from step (1) to its standard input. The complete
credential description (including the credential per se, i.e. the
login and password) will be produced on standard output, like:
protocol=https
host=example.com
username=bob
password=secr3t
+
In most cases, this means the attributes given in the input will be
repeated in the output, but Git may also modify the credential
description, for example by removing the `path` attribute when the
protocol is HTTP(s) and `credential.useHttpPath` is false.
+
If the `git credential` knew about the password, this step may
not have involved the user actually typing this password (the
user may have typed a password to unlock the keychain instead,
or no user interaction was done if the keychain was already
unlocked) before it returned `password=secr3t`.
3. Use the credential (e.g., access the URL with the username and
password from step (2)), and see if it's accepted.
4. Report on the success or failure of the password. If the
credential allowed the operation to complete successfully, then
it can be marked with an "approve" action to tell `git
credential` to reuse it in its next invocation. If the credential
was rejected during the operation, use the "reject" action so
that `git credential` will ask for a new password in its next
invocation. In either case, `git credential` should be fed with
the credential description obtained from step (2) (which also
contains the fields provided in step (1)).
[[IOFMT]]
INPUT/OUTPUT FORMAT
-------------------
`git credential` reads and/or writes (depending on the action used)
credential information in its standard input/output. This information
can correspond either to keys for which `git credential` will obtain
the login information (e.g. host, protocol, path), or to the actual
credential data to be obtained (username/password).
The credential is split into a set of named attributes, with one
attribute per line. Each attribute is specified by a key-value pair,
separated by an `=` (equals) sign, followed by a newline.
The key may contain any bytes except `=`, newline, or NUL. The value may
contain any bytes except newline or NUL. A line, including the trailing
newline, may not exceed 65535 bytes in order to allow implementations to
parse efficiently.
Attributes with keys that end with C-style array brackets `[]` can have
multiple values. Each instance of a multi-valued attribute forms an
ordered list of values - the order of the repeated attributes defines
the order of the values. An empty multi-valued attribute (`key[]=\n`)
acts to clear any previous entries and reset the list.
In all cases, all bytes are treated as-is (i.e., there is no quoting,
and one cannot transmit a value with newline or NUL in it). The list of
attributes is terminated by a blank line or end-of-file.
Git understands the following attributes:
`protocol`::
The protocol over which the credential will be used (e.g.,
`https`).
`host`::
The remote hostname for a network credential. This includes
the port number if one was specified (e.g., "example.com:8088").
`path`::
The path with which the credential will be used. E.g., for
accessing a remote https repository, this will be the
repository's path on the server.
`username`::
The credential's username, if we already have one (e.g., from a
URL, the configuration, the user, or from a previously run helper).
`password`::
The credential's password, if we are asking it to be stored.
`password_expiry_utc`::
Generated passwords such as an OAuth access token may have an expiry date.
When reading credentials from helpers, `git credential fill` ignores expired
passwords. Represented as Unix time UTC, seconds since 1970.
`oauth_refresh_token`::
An OAuth refresh token may accompany a password that is an OAuth access
token. Helpers must treat this attribute as confidential like the password
attribute. Git itself has no special behaviour for this attribute.
`url`::
When this special attribute is read by `git credential`, the
value is parsed as a URL and treated as if its constituent parts
were read (e.g., `url=https://example.com` would behave as if
`protocol=https` and `host=example.com` had been provided). This
can help callers avoid parsing URLs themselves.
+
Note that specifying a protocol is mandatory and if the URL
doesn't specify a hostname (e.g., "cert:///path/to/file") the
credential will contain a hostname attribute whose value is an
empty string.
+
Components which are missing from the URL (e.g., there is no
username in the example above) will be left unset.
`authtype`::
This indicates that the authentication scheme in question should be used.
Common values for HTTP and HTTPS include `basic`, `bearer`, and `digest`,
although the latter is insecure and should not be used. If `credential`
is used, this may be set to an arbitrary string suitable for the protocol in
question (usually HTTP).
+
This value should not be sent unless the appropriate capability (see below) is
provided on input.
`credential`::
The pre-encoded credential, suitable for the protocol in question (usually
HTTP). If this key is sent, `authtype` is mandatory, and `username` and
`password` are not used. For HTTP, Git concatenates the `authtype` value and
this value with a single space to determine the `Authorization` header.
+
This value should not be sent unless the appropriate capability (see below) is
provided on input.
`ephemeral`::
This boolean value indicates, if true, that the value in the `credential`
field should not be saved by the credential helper because its usefulness is
limited in time. For example, an HTTP Digest `credential` value is computed
using a nonce and reusing it will not result in successful authentication.
This may also be used for situations with short duration (e.g., 24-hour)
credentials. The default value is false.
+
The credential helper will still be invoked with `store` or `erase` so that it
can determine whether the operation was successful.
+
This value should not be sent unless the appropriate capability (see below) is
provided on input.
`state[]`::
This value provides an opaque state that will be passed back to this helper
if it is called again. Each different credential helper may specify this
once. The value should include a prefix unique to the credential helper and
should ignore values that don't match its prefix.
+
This value should not be sent unless the appropriate capability (see below) is
provided on input.
`continue`::
This is a boolean value, which, if enabled, indicates that this
authentication is a non-final part of a multistage authentication step. This
is common in protocols such as NTLM and Kerberos, where two rounds of client
authentication are required, and setting this flag allows the credential
helper to implement the multistage authentication step. This flag should
only be sent if a further stage is required; that is, if another round of
authentication is expected.
+
This value should not be sent unless the appropriate capability (see below) is
provided on input. This attribute is 'one-way' from a credential helper to
pass information to Git (or other programs invoking `git credential`).
`wwwauth[]`::
When an HTTP response is received by Git that includes one or more
'WWW-Authenticate' authentication headers, these will be passed by Git
to credential helpers.
+
Each 'WWW-Authenticate' header value is passed as a multi-valued
attribute 'wwwauth[]', where the order of the attributes is the same as
they appear in the HTTP response. This attribute is 'one-way' from Git
to pass additional information to credential helpers.
`capability[]`::
This signals that Git, or the helper, as appropriate, supports the capability
in question. This can be used to provide better, more specific data as part
of the protocol. A `capability[]` directive must precede any value depending
on it and these directives _should_ be the first item announced in the
protocol.
+
There are two currently supported capabilities. The first is `authtype`, which
indicates that the `authtype`, `credential`, and `ephemeral` values are
understood. The second is `state`, which indicates that the `state[]` and
`continue` values are understood.
+
It is not obligatory to use the additional features just because the capability
is supported, but they should not be provided without the capability.
Unrecognised attributes and capabilities are silently discarded.
[[CAPA-IOFMT]]
CAPABILITY INPUT/OUTPUT FORMAT
------------------------------
For `git credential capability`, the format is slightly different. First, a
`version 0` announcement is made to indicate the current version of the
protocol, and then each capability is announced with a line like `capability
authtype`. Credential helpers may also implement this format, again with the
`capability` argument. Additional lines may be added in the future; callers
should ignore lines which they don't understand.
Because this is a new part of the credential helper protocol, older versions of
Git, as well as some credential helpers, may not support it. If a non-zero
exit status is received, or if the first line doesn't start with the word
`version` and a space, callers should assume that no capabilities are supported.
The intention of this format is to differentiate it from the credential output
in an unambiguous way. It is possible to use very simple credential helpers
(e.g., inline shell scripts) which always produce identical output. Using a
distinct format allows users to continue to use this syntax without having to
worry about correctly implementing capability advertisements or accidentally
confusing callers querying for capabilities.
GIT
---
Part of the linkgit:git[1] suite

118
app/src/main/assets/manpages/git-cvsexportcommit.txt Normal file
View File

@@ -0,0 +1,118 @@
git-cvsexportcommit(1)
======================
NAME
----
git-cvsexportcommit - Export a single commit to a CVS checkout
SYNOPSIS
--------
[verse]
'git cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d <cvsroot>]
[-w <cvs-workdir>] [-W] [-f] [-m <msgprefix>] [<parent-commit>] <commit-id>
DESCRIPTION
-----------
Exports a commit from Git to a CVS checkout, making it easier
to merge patches from a Git repository into a CVS repository.
Specify the name of a CVS checkout using the -w switch or execute it
from the root of the CVS working copy. In the latter case GIT_DIR must
be defined. See examples below.
It does its best to do the safe thing, it will check that the files are
unchanged and up to date in the CVS checkout, and it will not autocommit
by default.
Supports file additions, removals, and commits that affect binary files.
If the commit is a merge commit, you must tell 'git cvsexportcommit' what
parent the changeset should be done against.
OPTIONS
-------
-c::
Commit automatically if the patch applied cleanly. It will not
commit if any hunks fail to apply or there were other problems.
-p::
Be pedantic (paranoid) when applying patches. Invokes patch with
--fuzz=0
-a::
Add authorship information. Adds Author line, and Committer (if
different from Author) to the message.
-d::
Set an alternative CVSROOT to use. This corresponds to the CVS
-d parameter. Usually users will not want to set this, except
if using CVS in an asymmetric fashion.
-f::
Force the merge even if the files are not up to date.
-P::
Force the parent commit, even if it is not a direct parent.
-m::
Prepend the commit message with the provided prefix.
Useful for patch series and the like.
-u::
Update affected files from CVS repository before attempting export.
-k::
Reverse CVS keyword expansion (e.g. $Revision: 1.2.3.4$
becomes $Revision$) in working CVS checkout before applying patch.
-w::
Specify the location of the CVS checkout to use for the export. This
option does not require GIT_DIR to be set before execution if the
current directory is within a Git repository. The default is the
value of 'cvsexportcommit.cvsdir'.
-W::
Tell cvsexportcommit that the current working directory is not only
a Git checkout, but also the CVS checkout. Therefore, Git will
reset the working directory to the parent commit before proceeding.
-v::
Verbose.
CONFIGURATION
-------------
cvsexportcommit.cvsdir::
The default location of the CVS checkout to use for the export.
EXAMPLES
--------
Merge one patch into CVS::
+
------------
$ export GIT_DIR=~/project/.git
$ cd ~/project_cvs_checkout
$ git cvsexportcommit -v <commit-sha1>
$ cvs commit -F .msg <files>
------------
Merge one patch into CVS (-c and -w options). The working directory is within the Git Repo::
+
------------
$ git cvsexportcommit -v -c -w ~/project_cvs_checkout <commit-sha1>
------------
Merge pending patches into CVS automatically -- only if you really know what you are doing::
+
------------
$ export GIT_DIR=~/project/.git
$ cd ~/project_cvs_checkout
$ git cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git cvsexportcommit -c -p -v
------------
GIT
---
Part of the linkgit:git[1] suite

228
app/src/main/assets/manpages/git-cvsimport.txt Normal file
View File

@@ -0,0 +1,228 @@
git-cvsimport(1)
================
NAME
----
git-cvsimport - Salvage your data out of another SCM people love to hate
SYNOPSIS
--------
[verse]
'git cvsimport' [-o <branch-for-HEAD>] [-h] [-v] [-d <CVSROOT>]
[-A <author-conv-file>] [-p <options-for-cvsps>] [-P <file>]
[-C <git-repository>] [-z <fuzz>] [-i] [-k] [-u] [-s <subst>]
[-a] [-m] [-M <regex>] [-S <regex>] [-L <commit-limit>]
[-r <remote>] [-R] [<CVS-module>]
DESCRIPTION
-----------
*WARNING:* `git cvsimport` uses cvsps version 2, which is considered
deprecated; it does not work with cvsps version 3 and later. If you are
performing a one-shot import of a CVS repository consider using
http://cvs2svn.tigris.org/cvs2git.html[cvs2git] or
https://gitlab.com/esr/cvs-fast-export[cvs-fast-export].
Imports a CVS repository into Git. It will either create a new
repository, or incrementally import into an existing one.
Splitting the CVS log into patch sets is done by 'cvsps'.
At least version 2.1 is required.
*WARNING:* for certain situations the import leads to incorrect results.
Please see the section <<issues,ISSUES>> for further reference.
You should *never* do any work of your own on the branches that are
created by 'git cvsimport'. By default initial import will create and populate a
"master" branch from the CVS repository's main branch which you're free
to work with; after that, you need to 'git merge' incremental imports, or
any CVS branches, yourself. It is advisable to specify a named remote via
-r to separate and protect the incoming branches.
If you intend to set up a shared public repository that all developers can
read/write, or if you want to use linkgit:git-cvsserver[1], then you
probably want to make a bare clone of the imported repository,
and use the clone as the shared repository.
See linkgit:gitcvs-migration[7].
OPTIONS
-------
-v::
Verbosity: let 'cvsimport' report what it is doing.
-d <CVSROOT>::
The root of the CVS archive. May be local (a simple path) or remote;
currently, only the :local:, :ext: and :pserver: access methods
are supported. If not given, 'git cvsimport' will try to read it
from `CVS/Root`. If no such file exists, it checks for the
`CVSROOT` environment variable.
<CVS-module>::
The CVS module you want to import. Relative to <CVSROOT>.
If not given, 'git cvsimport' tries to read it from
`CVS/Repository`.
-C <target-dir>::
The Git repository to import to. If the directory doesn't
exist, it will be created. Default is the current directory.
-r <remote>::
The Git remote to import this CVS repository into.
Moves all CVS branches into remotes/<remote>/<branch>
akin to the way 'git clone' uses 'origin' by default.
-o <branch-for-HEAD>::
When no remote is specified (via -r) the `HEAD` branch
from CVS is imported to the 'origin' branch within the Git
repository, as `HEAD` already has a special meaning for Git.
When a remote is specified the `HEAD` branch is named
remotes/<remote>/master mirroring 'git clone' behaviour.
Use this option if you want to import into a different
branch.
+
Use '-o master' for continuing an import that was initially done by
the old cvs2git tool.
-i::
Import-only: don't perform a checkout after importing. This option
ensures the working directory and index remain untouched and will
not create them if they do not exist.
-k::
Kill keywords: will extract files with '-kk' from the CVS archive
to avoid noisy changesets. Highly recommended, but off by default
to preserve compatibility with early imported trees.
-u::
Convert underscores in tag and branch names to dots.
-s <subst>::
Substitute the character "/" in branch names with <subst>
-p <options-for-cvsps>::
Additional options for cvsps.
The options `-u` and '-A' are implicit and should not be used here.
+
If you need to pass multiple options, separate them with a comma.
-z <fuzz>::
Pass the timestamp fuzz factor to cvsps, in seconds. If unset,
cvsps defaults to 300s.
-P <cvsps-output-file>::
Instead of calling cvsps, read the provided cvsps output file. Useful
for debugging or when cvsps is being handled outside cvsimport.
-m::
Attempt to detect merges based on the commit message. This option
will enable default regexes that try to capture the source
branch name from the commit message.
-M <regex>::
Attempt to detect merges based on the commit message with a custom
regex. It can be used with `-m` to enable the default regexes
as well. You must escape forward slashes.
+
The regex must capture the source branch name in $1.
+
This option can be used several times to provide several detection regexes.
-S <regex>::
Skip paths matching the regex.
-a::
Import all commits, including recent ones. cvsimport by default
skips commits that have a timestamp less than 10 minutes ago.
-L <limit>::
Limit the number of commits imported. Workaround for cases where
cvsimport leaks memory.
-A <author-conv-file>::
CVS by default uses the Unix username when writing its
commit logs. Using this option and an author-conv-file
maps the name recorded in CVS to author name, e-mail and
optional time zone:
+
---------
exon=Andreas Ericsson <ae@op5.se>
spawn=Simon Pawn <spawn@frog-pond.org> America/Chicago
---------
+
'git cvsimport' will make it appear as those authors had
their GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL set properly
all along. If a time zone is specified, GIT_AUTHOR_DATE will
have the corresponding offset applied.
+
For convenience, this data is saved to `$GIT_DIR/cvs-authors`
each time the '-A' option is provided and read from that same
file each time 'git cvsimport' is run.
+
It is not recommended to use this feature if you intend to
export changes back to CVS again later with
'git cvsexportcommit'.
-R::
Generate a `$GIT_DIR/cvs-revisions` file containing a mapping from CVS
revision numbers to newly-created Git commit IDs. The generated file
will contain one line for each (filename, revision) pair imported;
each line will look like
+
---------
src/widget.c 1.1 1d862f173cdc7325b6fa6d2ae1cfd61fd1b512b7
---------
+
The revision data is appended to the file if it already exists, for use when
doing incremental imports.
+
This option may be useful if you have CVS revision numbers stored in commit
messages, bug-tracking systems, email archives, and the like.
-h::
Print a short usage message and exit.
OUTPUT
------
If `-v` is specified, the script reports what it is doing.
Otherwise, success is indicated the Unix way, i.e. by simply exiting with
a zero exit status.
[[issues]]
ISSUES
------
Problems related to timestamps:
* If timestamps of commits in the CVS repository are not stable enough
to be used for ordering commits changes may show up in the wrong
order.
* If any files were ever "cvs import"ed more than once (e.g., import of
more than one vendor release) the HEAD contains the wrong content.
* If the timestamp order of different files cross the revision order
within the commit matching time window the order of commits may be
wrong.
Problems related to branches:
* Branches on which no commits have been made are not imported.
* All files from the branching point are added to a branch even if
never added in CVS.
* This applies to files added to the source branch *after* a daughter
branch was created: if previously no commit was made on the daughter
branch they will erroneously be added to the daughter branch in git.
Problems related to tags:
* Multiple tags on the same revision are not imported.
If you suspect that any of these issues may apply to the repository you
want to import, consider using cvs2git:
* cvs2git (part of cvs2svn), `https://subversion.apache.org/`
GIT
---
Part of the linkgit:git[1] suite

437
app/src/main/assets/manpages/git-cvsserver.txt Normal file
View File

@@ -0,0 +1,437 @@
git-cvsserver(1)
================
NAME
----
git-cvsserver - A CVS server emulator for Git
SYNOPSIS
--------
SSH:
[verse]
export CVS_SERVER="git cvsserver"
'cvs' -d :ext:user@server/path/repo.git co <HEAD_name>
pserver (/etc/inetd.conf):
[verse]
cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver
Usage:
[verse]
'git-cvsserver' [<options>] [pserver|server] [<directory> ...]
DESCRIPTION
-----------
This application is a CVS emulation layer for Git.
It is highly functional. However, not all methods are implemented,
and for those methods that are implemented,
not all switches are implemented.
Testing has been done using both the CLI CVS client, and the Eclipse CVS
plugin. Most functionality works fine with both of these clients.
OPTIONS
-------
All these options obviously only make sense if enforced by the server side.
They have been implemented to resemble the linkgit:git-daemon[1] options as
closely as possible.
--base-path <path>::
Prepend 'path' to requested CVSROOT
--strict-paths::
Don't allow recursing into subdirectories
--export-all::
Don't check for `gitcvs.enabled` in config. You also have to specify a list
of allowed directories (see below) if you want to use this option.
-V::
--version::
Print version information and exit
-h::
-H::
--help::
Print usage information and exit
<directory>::
The remaining arguments provide a list of directories. If no directories
are given, then all are allowed. Repositories within these directories
still require the `gitcvs.enabled` config option, unless `--export-all`
is specified.
LIMITATIONS
-----------
CVS clients cannot tag, branch or perform Git merges.
'git-cvsserver' maps Git branches to CVS modules. This is very different
from what most CVS users would expect since in CVS modules usually represent
one or more directories.
INSTALLATION
------------
1. If you are going to offer CVS access via pserver, add a line in
/etc/inetd.conf like
+
--
------
cvspserver stream tcp nowait nobody git-cvsserver pserver
------
Note: Some inetd servers let you specify the name of the executable
independently of the value of argv[0] (i.e. the name the program assumes
it was executed with). In this case the correct line in /etc/inetd.conf
looks like
------
cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver
------
Only anonymous access is provided by pserver by default. To commit you
will have to create pserver accounts, simply add a gitcvs.authdb
setting in the config file of the repositories you want the cvsserver
to allow writes to, for example:
------
[gitcvs]
authdb = /etc/cvsserver/passwd
------
The format of these files is username followed by the encrypted password,
for example:
------
myuser:sqkNi8zPf01HI
myuser:$1$9K7FzU28$VfF6EoPYCJEYcVQwATgOP/
myuser:$5$.NqmNH1vwfzGpV8B$znZIcumu1tNLATgV2l6e1/mY8RzhUDHMOaVOeL1cxV3
------
You can use the 'htpasswd' facility that comes with Apache to make these
files, but only with the -d option (or -B if your system supports it).
Preferably use the system specific utility that manages password hash
creation in your platform (e.g. mkpasswd in Linux, encrypt in OpenBSD or
pwhash in NetBSD) and paste it in the right location.
Then provide your password via the pserver method, for example:
------
cvs -d:pserver:someuser:somepassword@server:/path/repo.git co <HEAD_name>
------
No special setup is needed for SSH access, other than having Git tools
in the PATH. If you have clients that do not accept the CVS_SERVER
environment variable, you can rename 'git-cvsserver' to `cvs`.
Note: Newer CVS versions (>= 1.12.11) also support specifying
CVS_SERVER directly in CVSROOT like
------
cvs -d ":ext;CVS_SERVER=git cvsserver:user@server/path/repo.git" co <HEAD_name>
------
This has the advantage that it will be saved in your 'CVS/Root' files and
you don't need to worry about always setting the correct environment
variable. SSH users restricted to 'git-shell' don't need to override the default
with CVS_SERVER (and shouldn't) as 'git-shell' understands `cvs` to mean
'git-cvsserver' and pretends that the other end runs the real 'cvs' better.
--
2. For each repo that you want accessible from CVS you need to edit config in
the repo and add the following section.
+
--
------
[gitcvs]
enabled=1
# optional for debugging
logFile=/path/to/logfile
------
Note: you need to ensure each user that is going to invoke 'git-cvsserver' has
write access to the log file and to the database (see
<<dbbackend,Database Backend>>. If you want to offer write access over
SSH, the users of course also need write access to the Git repository itself.
You also need to ensure that each repository is "bare" (without a Git index
file) for `cvs commit` to work. See linkgit:gitcvs-migration[7].
[[configaccessmethod]]
All configuration variables can also be overridden for a specific method of
access. Valid method names are "ext" (for SSH access) and "pserver". The
following example configuration would disable pserver access while still
allowing access over SSH.
------
[gitcvs]
enabled=0
[gitcvs "ext"]
enabled=1
------
--
3. If you didn't specify the CVSROOT/CVS_SERVER directly in the checkout command,
automatically saving it in your 'CVS/Root' files, then you need to set them
explicitly in your environment. CVSROOT should be set as per normal, but the
directory should point at the appropriate Git repo. As above, for SSH clients
_not_ restricted to 'git-shell', CVS_SERVER should be set to 'git-cvsserver'.
+
--
------
export CVSROOT=:ext:user@server:/var/git/project.git
export CVS_SERVER="git cvsserver"
------
--
4. For SSH clients that will make commits, make sure their server-side
.ssh/environment files (or .bashrc, etc., according to their specific shell)
export appropriate values for GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL,
GIT_COMMITTER_NAME, and GIT_COMMITTER_EMAIL. For SSH clients whose login
shell is bash, .bashrc may be a reasonable alternative.
5. Clients should now be able to check out the project. Use the CVS 'module'
name to indicate what Git 'head' you want to check out. This also sets the
name of your newly checked-out directory, unless you tell it otherwise with
`-d <dir-name>`. For example, this checks out 'master' branch to the
`project-master` directory:
+
------
cvs co -d project-master master
------
[[dbbackend]]
DATABASE BACKEND
----------------
'git-cvsserver' uses one database per Git head (i.e. CVS module) to
store information about the repository to maintain consistent
CVS revision numbers. The database needs to be
updated (i.e. written to) after every commit.
If the commit is done directly by using `git` (as opposed to
using 'git-cvsserver') the update will need to happen on the
next repository access by 'git-cvsserver', independent of
access method and requested operation.
That means that even if you offer only read access (e.g. by using
the pserver method), 'git-cvsserver' should have write access to
the database to work reliably (otherwise you need to make sure
that the database is up to date any time 'git-cvsserver' is executed).
By default it uses SQLite databases in the Git directory, named
`gitcvs.<module-name>.sqlite`. Note that the SQLite backend creates
temporary files in the same directory as the database file on
write so it might not be enough to grant the users using
'git-cvsserver' write access to the database file without granting
them write access to the directory, too.
The database cannot be reliably regenerated in a
consistent form after the branch it is tracking has changed.
Example: For merged branches, 'git-cvsserver' only tracks
one branch of development, and after a 'git merge' an
incrementally updated database may track a different branch
than a database regenerated from scratch, causing inconsistent
CVS revision numbers. `git-cvsserver` has no way of knowing which
branch it would have picked if it had been run incrementally
pre-merge. So if you have to fully or partially (from old
backup) regenerate the database, you should be suspicious
of pre-existing CVS sandboxes.
You can configure the database backend with the following
configuration variables:
Configuring database backend
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
'git-cvsserver' uses the Perl DBI module. Please also read
its documentation if changing these variables, especially
about `DBI->connect()`.
gitcvs.dbName::
Database name. The exact meaning depends on the
selected database driver, for SQLite this is a filename.
Supports variable substitution (see below). May
not contain semicolons (`;`).
Default: '%Ggitcvs.%m.sqlite'
gitcvs.dbDriver::
Used DBI driver. You can specify any available driver
for this here, but it might not work. cvsserver is tested
with 'DBD::SQLite', reported to work with
'DBD::Pg', and reported *not* to work with 'DBD::mysql'.
Please regard this as an experimental feature. May not
contain colons (`:`).
Default: 'SQLite'
gitcvs.dbuser::
Database user. Only useful if setting `dbDriver`, since
SQLite has no concept of database users. Supports variable
substitution (see below).
gitcvs.dbPass::
Database password. Only useful if setting `dbDriver`, since
SQLite has no concept of database passwords.
gitcvs.dbTableNamePrefix::
Database table name prefix. Supports variable substitution
(see below). Any non-alphabetic characters will be replaced
with underscores.
All variables can also be set per access method, see <<configaccessmethod,above>>.
Variable substitution
^^^^^^^^^^^^^^^^^^^^^
In `dbDriver` and `dbUser` you can use the following variables:
%G::
Git directory name
%g::
Git directory name, where all characters except for
alphanumeric ones, `.`, and `-` are replaced with
`_` (this should make it easier to use the directory
name in a filename if wanted)
%m::
CVS module/Git head name
%a::
access method (one of "ext" or "pserver")
%u::
Name of the user running 'git-cvsserver'.
If no name can be determined, the
numeric uid is used.
ENVIRONMENT
-----------
These variables obviate the need for command-line options in some
circumstances, allowing easier restricted usage through git-shell.
GIT_CVSSERVER_BASE_PATH::
This variable replaces the argument to --base-path.
GIT_CVSSERVER_ROOT::
This variable specifies a single directory, replacing the
`<directory>...` argument list. The repository still requires the
`gitcvs.enabled` config option, unless `--export-all` is specified.
When these environment variables are set, the corresponding
command-line arguments may not be used.
ECLIPSE CVS CLIENT NOTES
------------------------
To get a checkout with the Eclipse CVS client:
1. Select "Create a new project -> From CVS checkout"
2. Create a new location. See the notes below for details on how to choose the
right protocol.
3. Browse the 'modules' available. It will give you a list of the heads in
the repository. You will not be able to browse the tree from there. Only
the heads.
4. Pick `HEAD` when it asks what branch/tag to check out. Untick the
"launch commit wizard" to avoid committing the .project file.
Protocol notes: If you are using anonymous access via pserver, just select that.
Those using SSH access should choose the 'ext' protocol, and configure 'ext'
access on the Preferences->Team->CVS->ExtConnection pane. Set CVS_SERVER to
"`git cvsserver`". Note that password support is not good when using 'ext',
you will definitely want to have SSH keys setup.
Alternatively, you can just use the non-standard extssh protocol that Eclipse
offer. In that case CVS_SERVER is ignored, and you will have to replace
the cvs utility on the server with 'git-cvsserver' or manipulate your `.bashrc`
so that calling 'cvs' effectively calls 'git-cvsserver'.
CLIENTS KNOWN TO WORK
---------------------
- CVS 1.12.9 on Debian
- CVS 1.11.17 on MacOSX (from Fink package)
- Eclipse 3.0, 3.1.2 on MacOSX (see Eclipse CVS Client Notes)
- TortoiseCVS
OPERATIONS SUPPORTED
--------------------
All the operations required for normal use are supported, including
checkout, diff, status, update, log, add, remove, commit.
Most CVS command arguments that read CVS tags or revision numbers
(typically -r) work, and also support any git refspec
(tag, branch, commit ID, etc).
However, CVS revision numbers for non-default branches are not well
emulated, and cvs log does not show tags or branches at
all. (Non-main-branch CVS revision numbers superficially resemble CVS
revision numbers, but they actually encode a git commit ID directly,
rather than represent the number of revisions since the branch point.)
Note that there are two ways to checkout a particular branch.
As described elsewhere on this page, the "module" parameter
of cvs checkout is interpreted as a branch name, and it becomes
the main branch. It remains the main branch for a given sandbox
even if you temporarily make another branch sticky with
cvs update -r. Alternatively, the -r argument can indicate
some other branch to actually checkout, even though the module
is still the "main" branch. Tradeoffs (as currently
implemented): Each new "module" creates a new database on disk with
a history for the given module, and after the database is created,
operations against that main branch are fast. Or alternatively,
-r doesn't take any extra disk space, but may be significantly slower for
many operations, like cvs update.
If you want to refer to a git refspec that has characters that are
not allowed by CVS, you have two options. First, it may just work
to supply the git refspec directly to the appropriate CVS -r argument;
some CVS clients don't seem to do much sanity checking of the argument.
Second, if that fails, you can use a special character escape mechanism
that only uses characters that are valid in CVS tags. A sequence
of 4 or 5 characters of the form (underscore (`"_"`), dash (`"-"`),
one or two characters, and dash (`"-"`)) can encode various characters based
on the one or two letters: `"s"` for slash (`"/"`), `"p"` for
period (`"."`), `"u"` for underscore (`"_"`), or two hexadecimal digits
for any byte value at all (typically an ASCII number, or perhaps a part
of a UTF-8 encoded character).
Legacy monitoring operations are not supported (edit, watch and related).
Exports and tagging (tags and branches) are not supported at this stage.
CRLF Line Ending Conversions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
By default the server leaves the `-k` mode blank for all files,
which causes the CVS client to treat them as a text files, subject
to end-of-line conversion on some platforms.
You can make the server use the end-of-line conversion attributes to
set the `-k` modes for files by setting the `gitcvs.usecrlfattr`
config variable. See linkgit:gitattributes[5] for more information
about end-of-line conversion.
Alternatively, if `gitcvs.usecrlfattr` config is not enabled
or the attributes do not allow automatic detection for a filename, then
the server uses the `gitcvs.allBinary` config for the default setting.
If `gitcvs.allBinary` is set, then file not otherwise
specified will default to '-kb' mode. Otherwise the `-k` mode
is left blank. But if `gitcvs.allBinary` is set to "guess", then
the correct `-k` mode will be guessed based on the contents of
the file.
For best consistency with 'cvs', it is probably best to override the
defaults by setting `gitcvs.usecrlfattr` to true,
and `gitcvs.allBinary` to "guess".
DEPENDENCIES
------------
'git-cvsserver' depends on DBD::SQLite.
GIT
---
Part of the linkgit:git[1] suite

342
app/src/main/assets/manpages/git-daemon.txt Normal file
View File

@@ -0,0 +1,342 @@
git-daemon(1)
=============
NAME
----
git-daemon - A really simple server for Git repositories
SYNOPSIS
--------
[synopsis]
git daemon [--verbose] [--syslog] [--export-all]
[--timeout=<n>] [--init-timeout=<n>] [--max-connections=<n>]
[--strict-paths] [--base-path=<path>] [--base-path-relaxed]
[--user-path | --user-path=<path>]
[--interpolated-path=<pathtemplate>]
[--reuseaddr] [--detach] [--pid-file=<file>]
[--enable=<service>] [--disable=<service>]
[--allow-override=<service>] [--forbid-override=<service>]
[--access-hook=<path>] [--[no-]informative-errors]
[--inetd |
[--listen=<host-or-ipaddr>] [--port=<n>]
[--user=<user> [--group=<group>]]]
[--log-destination=(stderr|syslog|none)]
[<directory>...]
DESCRIPTION
-----------
A really simple TCP Git daemon that normally listens on port "DEFAULT_GIT_PORT"
aka 9418. It waits for a connection asking for a service, and will serve
that service if it is enabled.
It verifies that the directory has the magic file "git-daemon-export-ok", and
it will refuse to export any Git directory that hasn't explicitly been marked
for export this way (unless the `--export-all` parameter is specified). If you
pass some directory paths as `git daemon` arguments, the offers are limited to
repositories within those directories.
By default, only `upload-pack` service is enabled, which serves
`git fetch-pack` and `git ls-remote` clients, which are invoked
from `git fetch`, `git pull`, and `git clone`.
This is ideally suited for read-only updates, i.e., pulling from
Git repositories.
An `upload-archive` also exists to serve `git archive`.
OPTIONS
-------
`--strict-paths`::
Match paths exactly (i.e. don't allow "/foo/repo" when the real path is
"/foo/repo.git" or "/foo/repo/.git") and don't do user-relative paths.
`git daemon` will refuse to start when this option is enabled and no
directory arguments are provided.
`--base-path=<path>`::
Remap all the path requests as relative to the given path.
This is sort of "Git root" - if you run `git daemon` with
`--base-path=/srv/git` on `example.com`, then if you later try
to pull from `git://example.com/hello.git`, `git daemon` will
interpret the path as `/srv/git/hello.git`.
`--base-path-relaxed`::
If `--base-path` is enabled and repo lookup fails, with this option
`git daemon` will attempt to lookup without prefixing the base path.
This is useful for switching to `--base-path` usage, while still
allowing the old paths.
`--interpolated-path=<pathtemplate>`::
To support virtual hosting, an interpolated path template can be
used to dynamically construct alternate paths. The template
supports `%H` for the target hostname as supplied by the client but
converted to all lowercase, `%CH` for the canonical hostname,
`%IP` for the server's IP address, `%P` for the port number,
and `%D` for the absolute path of the named repository.
After interpolation, the path is validated against the directory
list.
`--export-all`::
Allow pulling from all directories that look like Git repositories
(have the 'objects' and 'refs' subdirectories), even if they
do not have the `git-daemon-export-ok` file.
`--inetd`::
Have the server run as an inetd service. Implies `--syslog` (may
be overridden with `--log-destination=`).
Incompatible with `--detach`, `--port`, `--listen`, `--user` and
`--group` options.
`--listen=<host-or-ipaddr>`::
Listen on a specific IP address or hostname. IP addresses can
be either an IPv4 address or an IPv6 address if supported. If IPv6
is not supported, then `--listen=<hostname>` is also not supported
and `--listen` must be given an IPv4 address.
Can be given more than once.
Incompatible with `--inetd` option.
`--port=<n>`::
Listen on an alternative port. Incompatible with `--inetd` option.
`--init-timeout=<n>`::
Timeout (in seconds) between the moment the connection is established
and the client request is received (typically a rather low value, since
that should be basically immediate).
`--timeout=<n>`::
Timeout (in seconds) for specific client sub-requests. This includes
the time it takes for the server to process the sub-request and the
time spent waiting for the next client's request.
`--max-connections=<n>`::
Maximum number of concurrent clients, defaults to 32. Set it to
zero for no limit.
`--syslog`::
Short for `--log-destination=syslog`.
`--log-destination=<destination>`::
Send log messages to the specified destination.
Note that this option does not imply `--verbose`,
thus by default only error conditions will be logged.
The _<destination>_ must be one of:
+
--
`stderr`::
Write to standard error.
Note that if `--detach` is specified,
the process disconnects from the real standard error,
making this destination effectively equivalent to `none`.
`syslog`::
Write to syslog, using the `git-daemon` identifier.
`none`::
Disable all logging.
--
+
The default destination is `syslog` if `--inetd` or `--detach` is specified,
otherwise `stderr`.
`--user-path`::
`--user-path=<path>`::
Allow {tilde}user notation to be used in requests. When
specified with no parameter, a request to
git://host/{tilde}alice/foo is taken as a request to access
'foo' repository in the home directory of user `alice`.
If `--user-path=<path>` is specified, the same request is
taken as a request to access `<path>/foo` repository in
the home directory of user `alice`.
`--verbose`::
Log details about the incoming connections and requested files.
`--reuseaddr`::
Use `SO_REUSEADDR` when binding the listening socket.
This allows the server to restart without waiting for
old connections to time out.
`--detach`::
Detach from the shell. Implies `--syslog`.
`--pid-file=<file>`::
Save the process id in _<file>_. Ignored when the daemon
is run under `--inetd`.
`--user=<user>`::
`--group=<group>`::
Change daemon's uid and gid before entering the service loop.
When only `--user` is given without `--group`, the
primary group ID for the user is used. The values of
the option are given to `getpwnam(3)` and `getgrnam(3)`
and numeric IDs are not supported.
+
Giving these options is an error when used with `--inetd`; use
the facility of inet daemon to achieve the same before spawning
`git daemon` if needed.
+
Like many programs that switch user id, the daemon does not reset
environment variables such as `HOME` when it runs git programs,
e.g. `upload-pack` and `receive-pack`. When using this option, you
may also want to set and export `HOME` to point at the home
directory of _<user>_ before starting the daemon, and make sure any
Git configuration files in that directory are readable by _<user>_.
`--enable=<service>`::
`--disable=<service>`::
Enable/disable the service site-wide per default. Note
that a service disabled site-wide can still be enabled
per repository if it is marked overridable and the
repository enables the service with a configuration
item.
`--allow-override=<service>`::
`--forbid-override=<service>`::
Allow/forbid overriding the site-wide default with per
repository configuration. By default, all the services
may be overridden.
`--informative-errors`::
`--no-informative-errors`::
When informative errors are turned on, git-daemon will report
more verbose errors to the client, differentiating conditions
like "no such repository" from "repository not exported". This
is more convenient for clients, but may leak information about
the existence of unexported repositories. When informative
errors are not enabled, all errors report "access denied" to the
client. The default is `--no-informative-errors`.
`--access-hook=<path>`::
Every time a client connects, first run an external command
specified by the <path> with service name (e.g. "upload-pack"),
path to the repository, hostname (`%H`), canonical hostname
(`%CH`), IP address (`%IP`), and TCP port (`%P`) as its command-line
arguments. The external command can decide to decline the
service by exiting with a non-zero status (or to allow it by
exiting with a zero status). It can also look at the $REMOTE_ADDR
and `$REMOTE_PORT` environment variables to learn about the
requestor when making this decision.
+
The external command can optionally write a single line to its
standard output to be sent to the requestor as an error message when
it declines the service.
_<directory>_::
The remaining arguments provide a list of directories. If any
directories are specified, then the `git-daemon` process will
serve a requested directory only if it is contained in one of
these directories. If `--strict-paths` is specified, then the
requested directory must match one of these directories exactly.
SERVICES
--------
These services can be globally enabled/disabled using the
command-line options of this command. If finer-grained
control is desired (e.g. to allow `git archive` to be run
against only in a few selected repositories the daemon serves),
the per-repository configuration file can be used to enable or
disable them.
upload-pack::
This serves `git fetch-pack` and `git ls-remote`
clients. It is enabled by default, but a repository can
disable it by setting `daemon.uploadpack` configuration
item to `false`.
upload-archive::
This serves `git archive --remote`. It is disabled by
default, but a repository can enable it by setting
`daemon.uploadarch` configuration item to `true`.
receive-pack::
This serves `git send-pack` clients, allowing anonymous
push. It is disabled by default, as there is _no_
authentication in the protocol (in other words, anybody
can push anything into the repository, including removal
of refs). This is solely meant for a closed LAN setting
where everybody is friendly. This service can be
enabled by setting `daemon.receivepack` configuration item to
`true`.
EXAMPLES
--------
We assume the following in /etc/services::
+
------------
$ grep 9418 /etc/services
git 9418/tcp # Git Version Control System
------------
'git daemon' as inetd server::
To set up 'git daemon' as an inetd service that handles any
repository within `/pub/foo` or `/pub/bar`, place an entry like
the following into `/etc/inetd` all on one line:
+
------------------------------------------------
git stream tcp nowait nobody /usr/bin/git
git daemon --inetd --verbose --export-all
/pub/foo /pub/bar
------------------------------------------------
'git daemon' as inetd server for virtual hosts::
To set up 'git daemon' as an inetd service that handles
repositories for different virtual hosts, `www.example.com`
and `www.example.org`, place an entry like the following into
`/etc/inetd` all on one line:
+
------------------------------------------------
git stream tcp nowait nobody /usr/bin/git
git daemon --inetd --verbose --export-all
--interpolated-path=/pub/%H%D
/pub/www.example.org/software
/pub/www.example.com/software
/software
------------------------------------------------
+
In this example, the root-level directory `/pub` will contain
a subdirectory for each virtual host name supported.
Further, both hosts advertise repositories simply as
`git://www.example.com/software/repo.git`. For pre-1.4.0
clients, a symlink from `/software` into the appropriate
default repository could be made as well.
'git daemon' as regular daemon for virtual hosts::
To set up `git daemon` as a regular, non-inetd service that
handles repositories for multiple virtual hosts based on
their IP addresses, start the daemon like this:
+
------------------------------------------------
git daemon --verbose --export-all
--interpolated-path=/pub/%IP/%D
/pub/192.168.1.200/software
/pub/10.10.220.23/software
------------------------------------------------
+
In this example, the root-level directory `/pub` will contain
a subdirectory for each virtual host IP address supported.
Repositories can still be accessed by hostname though, assuming
they correspond to these IP addresses.
selectively enable/disable services per repository::
To enable `git archive --remote` and disable `git fetch` against
a repository, have the following in the configuration file in the
repository (that is the file 'config' next to `HEAD`, 'refs' and
'objects').
+
----------------------------------------------------------------
[daemon]
uploadpack = false
uploadarch = true
----------------------------------------------------------------
ENVIRONMENT
-----------
`git daemon` will set `REMOTE_ADDR` to the IP address of the client
that connected to it, if the IP address is available. `REMOTE_ADDR` will
be available in the environment of hooks called when
services are performed.
GIT
---
Part of the linkgit:git[1] suite

211
app/src/main/assets/manpages/git-describe.txt Normal file
View File

@@ -0,0 +1,211 @@
git-describe(1)
===============
NAME
----
git-describe - Give an object a human readable name based on an available ref
SYNOPSIS
--------
[verse]
'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] [<commit-ish>...]
'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] --dirty[=<mark>]
'git describe' <blob>
DESCRIPTION
-----------
The command finds the most recent tag that is reachable from a
commit. If the tag points to the commit, then only the tag is
shown. Otherwise, it suffixes the tag name with the number of
additional commits on top of the tagged object and the
abbreviated object name of the most recent commit. The result
is a "human-readable" object name which can also be used to
identify the commit to other git commands.
By default (without --all or --tags) `git describe` only shows
annotated tags. For more information about creating annotated tags
see the -a and -s options to linkgit:git-tag[1].
If the given object refers to a blob, it will be described
as `<commit-ish>:<path>`, such that the blob can be found
at `<path>` in the `<commit-ish>`, which itself describes the
first commit in which this blob occurs in a reverse revision walk
from HEAD.
OPTIONS
-------
<commit-ish>...::
Commit-ish object names to describe. Defaults to HEAD if omitted.
--dirty[=<mark>]::
--broken[=<mark>]::
Describe the state of the working tree. When the working
tree matches HEAD, the output is the same as "git describe
HEAD". If the working tree has local modification "-dirty"
is appended to it. If a repository is corrupt and Git
cannot determine if there is local modification, Git will
error out, unless `--broken' is given, which appends
the suffix "-broken" instead.
--all::
Instead of using only the annotated tags, use any ref
found in `refs/` namespace. This option enables matching
any known branch, remote-tracking branch, or lightweight tag.
--tags::
Instead of using only the annotated tags, use any tag
found in `refs/tags` namespace. This option enables matching
a lightweight (non-annotated) tag.
--contains::
Instead of finding the tag that predates the commit, find
the tag that comes after the commit, and thus contains it.
Automatically implies --tags.
--abbrev=<n>::
Instead of using the default number of hexadecimal digits (which
will vary according to the number of objects in the repository with
a default of 7) of the abbreviated object name, use <n> digits, or
as many digits as needed to form a unique object name. An <n> of 0
will suppress long format, only showing the closest tag.
--candidates=<n>::
Instead of considering only the 10 most recent tags as
candidates to describe the input commit-ish consider
up to <n> candidates. Increasing <n> above 10 will take
slightly longer but may produce a more accurate result.
An <n> of 0 will cause only exact matches to be output.
--exact-match::
Only output exact matches (a tag directly references the
supplied commit). This is a synonym for --candidates=0.
--debug::
Verbosely display information about the searching strategy
being employed to standard error. The tag name will still
be printed to standard out.
--long::
Always output the long format (the tag, the number of commits
and the abbreviated commit name) even when it matches a tag.
This is useful when you want to see parts of the commit object name
in "describe" output, even when the commit in question happens to be
a tagged version. Instead of just emitting the tag name, it will
describe such a commit as v1.2-0-gdeadbee (0th commit since tag v1.2
that points at object deadbee....).
--match <pattern>::
Only consider tags matching the given `glob(7)` pattern,
excluding the "refs/tags/" prefix. If used with `--all`, it also
considers local branches and remote-tracking references matching the
pattern, excluding respectively "refs/heads/" and "refs/remotes/"
prefix; references of other types are never considered. If given
multiple times, a list of patterns will be accumulated, and tags
matching any of the patterns will be considered. Use `--no-match` to
clear and reset the list of patterns.
--exclude <pattern>::
Do not consider tags matching the given `glob(7)` pattern, excluding
the "refs/tags/" prefix. If used with `--all`, it also does not consider
local branches and remote-tracking references matching the pattern,
excluding respectively "refs/heads/" and "refs/remotes/" prefix;
references of other types are never considered. If given multiple times,
a list of patterns will be accumulated and tags matching any of the
patterns will be excluded. When combined with --match a tag will be
considered when it matches at least one --match pattern and does not
match any of the --exclude patterns. Use `--no-exclude` to clear and
reset the list of patterns.
--always::
Show uniquely abbreviated commit object as fallback.
--first-parent::
Follow only the first parent commit upon seeing a merge commit.
This is useful when you wish to not match tags on branches merged
in the history of the target commit.
EXAMPLES
--------
With something like git.git current tree, I get:
[torvalds@g5 git]$ git describe parent
v1.0.4-14-g2414721
i.e. the current head of my "parent" branch is based on v1.0.4,
but since it has a few commits on top of that,
describe has added the number of additional commits ("14") and
an abbreviated object name for the commit itself ("2414721")
at the end.
The number of additional commits is the number
of commits which would be displayed by "git log v1.0.4..parent".
The hash suffix is "-g" + an unambiguous abbreviation for the tip commit
of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`). The
length of the abbreviation scales as the repository grows, using the
approximate number of objects in the repository and a bit of math
around the birthday paradox, and defaults to a minimum of 7.
The "g" prefix stands for "git" and is used to allow describing the version of
a software depending on the SCM the software is managed with. This is useful
in an environment where people may use different SCMs.
Doing a 'git describe' on a tag-name will just show the tag name:
[torvalds@g5 git]$ git describe v1.0.4
v1.0.4
With --all, the command can use branch heads as references, so
the output shows the reference path as well:
[torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5^2
tags/v1.0.0-21-g975b
[torvalds@g5 git]$ git describe --all --abbrev=4 HEAD^
heads/lt/describe-7-g975b
With --abbrev set to 0, the command can be used to find the
closest tagname without any suffix:
[torvalds@g5 git]$ git describe --abbrev=0 v1.0.5^2
tags/v1.0.0
Note that the suffix you get if you type these commands today may be
longer than what Linus saw above when he ran these commands, as your
Git repository may have new commits whose object names begin with
975b that did not exist back then, and "-g975b" suffix alone may not
be sufficient to disambiguate these commits.
SEARCH STRATEGY
---------------
For each commit-ish supplied, 'git describe' will first look for
a tag which tags exactly that commit. Annotated tags will always
be preferred over lightweight tags, and tags with newer dates will
always be preferred over tags with older dates. If an exact match
is found, its name will be output and searching will stop.
If an exact match was not found, 'git describe' will walk back
through the commit history to locate an ancestor commit which
has been tagged. The ancestor's tag will be output along with an
abbreviation of the input commit-ish's SHA-1. If `--first-parent` was
specified then the walk will only consider the first parent of each
commit.
If multiple tags were found during the walk then the tag which
has the fewest commits different from the input commit-ish will be
selected and output. Here fewest commits different is defined as
the number of commits which would be shown by `git log tag..input`
will be the smallest number of commits possible.
BUGS
----
Tree objects as well as tag objects not pointing at commits, cannot be described.
When describing blobs, the lightweight tags pointing at blobs are ignored,
but the blob is still described as <commit-ish>:<path> despite the lightweight
tag being favorable.
GIT
---
Part of the linkgit:git[1] suite

65
app/src/main/assets/manpages/git-diagnose.txt Normal file
View File

@@ -0,0 +1,65 @@
git-diagnose(1)
================
NAME
----
git-diagnose - Generate a zip archive of diagnostic information
SYNOPSIS
--------
[verse]
'git diagnose' [(-o | --output-directory) <path>] [(-s | --suffix) <format>]
[--mode=<mode>]
DESCRIPTION
-----------
Collects detailed information about the user's machine, Git client, and
repository state and packages that information into a zip archive. The
generated archive can then, for example, be shared with the Git mailing list to
help debug an issue or serve as a reference for independent debugging.
By default, the following information is captured in the archive:
* 'git version --build-options'
* The path to the repository root
* The available disk space on the filesystem
* The name and size of each packfile, including those in alternate object
stores
* The total count of loose objects, as well as counts broken down by
`.git/objects` subdirectory
Additional information can be collected by selecting a different diagnostic mode
using the `--mode` option.
This tool differs from linkgit:git-bugreport[1] in that it collects much more
detailed information with a greater focus on reporting the size and data shape
of repository contents.
OPTIONS
-------
-o <path>::
--output-directory <path>::
Place the resulting diagnostics archive in `<path>` instead of the
current directory.
-s <format>::
--suffix <format>::
Specify an alternate suffix for the diagnostics archive name, to create
a file named 'git-diagnostics-<formatted-suffix>'. This should take the
form of a strftime(3) format string; the current local time will be
used.
--mode=(stats|all)::
Specify the type of diagnostics that should be collected. The default behavior
of 'git diagnose' is equivalent to `--mode=stats`.
+
The `--mode=all` option collects everything included in `--mode=stats`, as well
as copies of `.git`, `.git/hooks`, `.git/info`, `.git/logs`, and
`.git/objects/info` directories. This additional information may be sensitive,
as it can be used to reconstruct the full contents of the diagnosed repository.
Users should exercise caution when sharing an archive generated with
`--mode=all`.
GIT
---
Part of the linkgit:git[1] suite

52
app/src/main/assets/manpages/git-diff-files.txt Normal file
View File

@@ -0,0 +1,52 @@
git-diff-files(1)
=================
NAME
----
git-diff-files - Compares files in the working tree and the index
SYNOPSIS
--------
[verse]
'git diff-files' [-q] [-0 | -1 | -2 | -3 | -c | --cc] [<common-diff-options>] [<path>...]
DESCRIPTION
-----------
Compares the files in the working tree and the index. When paths
are specified, compares only those named paths. Otherwise all
entries in the index are compared. The output format is the
same as for 'git diff-index' and 'git diff-tree'.
OPTIONS
-------
include::diff-options.adoc[]
-1 --base::
-2 --ours::
-3 --theirs::
-0::
Diff against the "base" version, "our branch", or "their
branch" respectively. With these options, diffs for
merged entries are not shown.
+
The default is to diff against our branch (-2) and the
cleanly resolved paths. The option -0 can be given to
omit diff output for unmerged entries and just show "Unmerged".
-c::
--cc::
This compares stage 2 (our branch), stage 3 (their
branch), and the working tree file and outputs a combined
diff, similar to the way 'diff-tree' shows a merge
commit with these flags.
-q::
Remain silent even for nonexistent files
include::diff-format.adoc[]
GIT
---
Part of the linkgit:git[1] suite

127
app/src/main/assets/manpages/git-diff-index.txt Normal file
View File

@@ -0,0 +1,127 @@
git-diff-index(1)
=================
NAME
----
git-diff-index - Compare a tree to the working tree or index
SYNOPSIS
--------
[verse]
'git diff-index' [-m] [--cached] [--merge-base] [<common-diff-options>] <tree-ish> [<path>...]
DESCRIPTION
-----------
Compare the content and mode of the blobs found in a tree object
with the corresponding tracked files in the working tree, or with the
corresponding paths in the index. When <path> arguments are present,
compare only paths matching those patterns. Otherwise all tracked
files are compared.
OPTIONS
-------
include::diff-options.adoc[]
<tree-ish>::
The id of a tree object to diff against.
--cached::
Do not consider the on-disk file at all.
--merge-base::
Instead of comparing <tree-ish> directly, use the merge base
between <tree-ish> and HEAD instead. <tree-ish> must be a
commit.
-m::
By default, files recorded in the index but not checked
out are reported as deleted. This flag makes
'git diff-index' say that all non-checked-out files are up
to date.
include::diff-format.adoc[]
OPERATING MODES
---------------
You can choose whether you want to trust the index file entirely
(using the `--cached` flag) or ask the diff logic to show any files
that don't match the stat state as being "tentatively changed". Both
of these operations are very useful indeed.
CACHED MODE
-----------
If `--cached` is specified, it allows you to ask:
show me the differences between HEAD and the current index
contents (the ones I'd write using 'git write-tree')
For example, let's say that you have worked on your working directory, updated
some files in the index and are ready to commit. You want to see exactly
*what* you are going to commit, without having to write a new tree
object and compare it that way, and to do that, you just do
git diff-index --cached HEAD
Example: let's say I had renamed `commit.c` to `git-commit.c`, and I had
done an `update-index` to make that effective in the index file.
`git diff-files` wouldn't show anything at all, since the index file
matches my working directory. But doing a 'git diff-index' does:
torvalds@ppc970:~/git> git diff-index --cached HEAD
:100644 000000 4161aecc6700a2eb579e842af0b7f22b98443f74 0000000000000000000000000000000000000000 D commit.c
:000000 100644 0000000000000000000000000000000000000000 4161aecc6700a2eb579e842af0b7f22b98443f74 A git-commit.c
You can see easily that the above is a rename.
In fact, `git diff-index --cached` *should* always be entirely equivalent to
actually doing a 'git write-tree' and comparing that. Except this one is much
nicer for the case where you just want to check where you are.
So doing a `git diff-index --cached` is basically very useful when you are
asking yourself "what have I already marked for being committed, and
what's the difference to a previous tree".
NON-CACHED MODE
---------------
The "non-cached" mode takes a different approach, and is potentially
the more useful of the two in that what it does can't be emulated with
a 'git write-tree' + 'git diff-tree'. Thus that's the default mode.
The non-cached version asks the question:
show me the differences between HEAD and the currently checked out
tree - index contents _and_ files that aren't up to date
which is obviously a very useful question too, since that tells you what
you *could* commit. Again, the output matches the 'git diff-tree -r'
output to a tee, but with a twist.
The twist is that if some file doesn't match the index, we don't have
a backing store thing for it, and we use the magic "all-zero" sha1 to
show that. So let's say that you have edited `kernel/sched.c`, but
have not actually done a 'git update-index' on it yet - there is no
"object" associated with the new state, and you get:
torvalds@ppc970:~/v2.6/linux> git diff-index --abbrev HEAD
:100644 100644 7476bb5ba 000000000 M kernel/sched.c
i.e., it shows that the tree has changed, and that `kernel/sched.c` is
not up to date and may contain new stuff. The all-zero sha1 means that to
get the real diff, you need to look at the object in the working directory
directly rather than do an object-to-object diff.
NOTE: As with other commands of this type, 'git diff-index' does not
actually look at the contents of the file at all. So maybe
`kernel/sched.c` hasn't actually changed, and it's just that you
touched it. In either case, it's a note that you need to
'git update-index' it to make the index be in sync.
NOTE: You can have a mixture of files show up as "has been updated"
and "is still dirty in the working directory" together. You can always
tell which file is in which state, since the "has been updated" ones
show a valid sha1, and the "not in sync with the index" ones will
always have the special all-zero sha1.
GIT
---
Part of the linkgit:git[1] suite

60
app/src/main/assets/manpages/git-diff-pairs.txt Normal file
View File

@@ -0,0 +1,60 @@
git-diff-pairs(1)
=================
NAME
----
git-diff-pairs - Compare the content and mode of provided blob pairs
SYNOPSIS
--------
[synopsis]
git diff-pairs -z [<diff-options>]
DESCRIPTION
-----------
Show changes for file pairs provided on stdin. Input for this command must be
in the NUL-terminated raw output format as generated by commands such as `git
diff-tree -z -r --raw`. By default, the outputted diffs are computed and shown
in the patch format when stdin closes.
A single NUL byte may be written to stdin between raw input lines to compute
file pair diffs up to that point instead of waiting for stdin to close. A NUL
byte is also written to the output to delimit between these batches of diffs.
Usage of this command enables the traditional diff pipeline to be broken up
into separate stages where `diff-pairs` acts as the output phase. Other
commands, such as `diff-tree`, may serve as a frontend to compute the raw
diff format used as input.
Instead of computing diffs via `git diff-tree -p -M` in one step, `diff-tree`
can compute the file pairs and rename information without the blob diffs. This
output can be fed to `diff-pairs` to generate the underlying blob diffs as done
in the following example:
-----------------------------
git diff-tree -z -r -M $a $b |
git diff-pairs -z
-----------------------------
Computing the tree diff upfront with rename information allows patch output
from `diff-pairs` to be progressively computed over the course of potentially
multiple invocations.
Pathspecs are not currently supported by `diff-pairs`. Pathspec limiting should
be performed by the upstream command generating the raw diffs used as input.
Tree objects are not currently supported as input and are rejected.
Abbreviated object IDs in the `diff-pairs` input are not supported. Outputted
object IDs can be abbreviated using the `--abbrev` option.
OPTIONS
-------
include::diff-options.adoc[]
include::diff-generate-patch.adoc[]
GIT
---
Part of the linkgit:git[1] suite

131
app/src/main/assets/manpages/git-diff-tree.txt Normal file
View File

@@ -0,0 +1,131 @@
git-diff-tree(1)
================
NAME
----
git-diff-tree - Compares the content and mode of blobs found via two tree objects
SYNOPSIS
--------
[verse]
'git diff-tree' [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty]
[-t] [-r] [-c | --cc] [--combined-all-paths] [--root] [--merge-base]
[<common-diff-options>] <tree-ish> [<tree-ish>] [<path>...]
DESCRIPTION
-----------
Compare the content and mode of blobs found via two tree objects.
If there is only one <tree-ish> given, the commit is compared with its parents
(see --stdin below).
Note that 'git diff-tree' can use the tree encapsulated in a commit object.
OPTIONS
-------
include::diff-options.adoc[]
<tree-ish>::
The id of a tree object.
<path>...::
If provided, the results are limited to a subset of files
matching one of the provided pathspecs.
-r::
Recurse into sub-trees.
-t::
Show tree entry itself as well as subtrees. Implies -r.
--root::
When `--root` is specified the initial commit will be shown as a big
creation event. This is equivalent to a diff against the NULL tree.
--merge-base::
Instead of comparing the <tree-ish>s directly, use the merge
base between the two <tree-ish>s as the "before" side. There
must be two <tree-ish>s given and they must both be commits.
--stdin::
When `--stdin` is specified, the command does not take
<tree-ish> arguments from the command line. Instead, it
reads lines containing either two <tree>, one <commit>, or a
list of <commit> from its standard input. (Use a single space
as separator.)
+
When two trees are given, it compares the first tree with the second.
When a single commit is given, it compares the commit with its
parents. The remaining commits, when given, are used as if they are
parents of the first commit.
+
When comparing two trees, the ID of both trees (separated by a space
and terminated by a newline) is printed before the difference. When
comparing commits, the ID of the first (or only) commit, followed by a
newline, is printed.
+
The following flags further affect the behavior when comparing
commits (but not trees).
-m::
By default, 'git diff-tree --stdin' does not show
differences for merge commits. With this flag, it shows
differences to that commit from all of its parents. See
also `-c`.
-s::
By default, 'git diff-tree --stdin' shows differences,
either in machine-readable form (without `-p`) or in patch
form (with `-p`). This output can be suppressed. It is
only useful with the `-v` flag.
-v::
This flag causes 'git diff-tree --stdin' to also show
the commit message before the differences.
include::pretty-options.adoc[]
--no-commit-id::
'git diff-tree' outputs a line with the commit ID when
applicable. This flag suppresses the commit ID output.
-c::
This flag changes the way a merge commit is displayed
(which means it is useful only when the command is given
one <tree-ish>, or `--stdin`). It shows the differences
from each of the parents to the merge result simultaneously
instead of showing pairwise diff between a parent and the
result one at a time (which is what the `-m` option does).
Furthermore, it lists only files which were modified
from all parents.
--cc::
This flag changes the way a merge commit patch is displayed,
in a similar way to the `-c` option. It implies the `-c`
and `-p` options and further compresses the patch output
by omitting uninteresting hunks whose contents in the parents
have only two variants and the merge result picks one of them
without modification. When all hunks are uninteresting, the commit
itself and the commit log message are not shown, just like in any other
"empty diff" case.
--combined-all-paths::
This flag causes combined diffs (used for merge commits) to
list the name of the file from all parents. It thus only has
effect when -c or --cc are specified, and is likely only
useful if filename changes are detected (i.e. when either
rename or copy detection have been requested).
--always::
Show the commit itself and the commit log message even
if the diff itself is empty.
include::pretty-formats.adoc[]
include::diff-format.adoc[]
GIT
---
Part of the linkgit:git[1] suite

256
app/src/main/assets/manpages/git-diff.txt Normal file
View File

@@ -0,0 +1,256 @@
git-diff(1)
===========
NAME
----
git-diff - Show changes between commits, commit and working tree, etc
SYNOPSIS
--------
[synopsis]
git diff [<options>] [<commit>] [--] [<path>...]
git diff [<options>] --cached [--merge-base] [<commit>] [--] [<path>...]
git diff [<options>] [--merge-base] <commit> [<commit>...] <commit> [--] [<path>...]
git diff [<options>] <commit>...<commit> [--] [<path>...]
git diff [<options>] <blob> <blob>
git diff [<options>] --no-index [--] <path> <path> [<pathspec>...]
DESCRIPTION
-----------
Show changes between the working tree and the index or a tree, changes
between the index and a tree, changes between two trees, changes resulting
from a merge, changes between two blob objects, or changes between two
files on disk.
`git diff [<options>] [--] [<path>...]`::
This form is to view the changes you made relative to
the index (staging area for the next commit). In other
words, the differences are what you _could_ tell Git to
further add to the index but you still haven't. You can
stage these changes by using linkgit:git-add[1].
`git diff [<options>] --no-index [--] <path> <path> [<pathspec>...]`::
This form is to compare the given two paths on the
filesystem. You can omit the `--no-index` option when
running the command in a working tree controlled by Git and
at least one of the paths points outside the working tree,
or when running the command outside a working tree
controlled by Git. This form implies `--exit-code`. If both
paths point to directories, additional pathspecs may be
provided. These will limit the files included in the
difference. All such pathspecs must be relative as they
apply to both sides of the diff.
`git diff [<options>] --cached [--merge-base] [<commit>] [--] [<path>...]`::
This form is to view the changes you staged for the next
commit relative to the named _<commit>_. Typically you
would want comparison with the latest commit, so if you
do not give _<commit>_, it defaults to `HEAD`.
If `HEAD` does not exist (e.g. unborn branches) and
_<commit>_ is not given, it shows all staged changes.
`--staged` is a synonym of `--cached`.
+
If `--merge-base` is given, instead of using _<commit>_, use the merge base
of _<commit>_ and `HEAD`. `git diff --cached --merge-base A` is equivalent to
`git diff --cached $(git merge-base A HEAD)`.
`git diff [<options>] [--merge-base] <commit> [--] [<path>...]`::
This form is to view the changes you have in your
working tree relative to the named _<commit>_. You can
use `HEAD` to compare it with the latest commit, or a
branch name to compare with the tip of a different
branch.
+
If `--merge-base` is given, instead of using _<commit>_, use the merge base
of _<commit>_ and `HEAD`. `git diff --merge-base A` is equivalent to
`git diff $(git merge-base A HEAD)`.
`git diff [<options>] [--merge-base] <commit> <commit> [--] [<path>...]`::
This is to view the changes between two arbitrary
_<commit>_.
+
If `--merge-base` is given, use the merge base of the two commits for the
"before" side. `git diff --merge-base A B` is equivalent to
`git diff $(git merge-base A B) B`.
`git diff [<options>] <commit> <commit>...<commit> [--] [<path>...]`::
This form is to view the results of a merge commit. The first
listed _<commit>_ must be the merge itself; the remaining two or
more commits should be its parents. Convenient ways to produce
the desired set of revisions are to use the suffixes `@` and
`^!`. If `A` is a merge commit, then `git diff A A^@`,
`git diff A^!` and `git show A` all give the same combined diff.
`git diff [<options>] <commit>..<commit> [--] [<path>...]`::
This is synonymous to the earlier form (without the `..`) for
viewing the changes between two arbitrary _<commit>_. If _<commit>_ on
one side is omitted, it will have the same effect as
using `HEAD` instead.
`git diff [<options>] <commit>...<commit> [--] [<path>...]`::
This form is to view the changes on the branch containing
and up to the second _<commit>_, starting at a common ancestor
of both _<commit>_. `git diff A...B` is equivalent to
`git diff $(git merge-base A B) B`. You can omit any one
of _<commit>_, which has the same effect as using `HEAD` instead.
Just in case you are doing something exotic, it should be
noted that all of the _<commit>_ in the above description, except
in the `--merge-base` case and in the last two forms that use `..`
notations, can be any _<tree>_. A tree of interest is the one pointed to
by the ref named `AUTO_MERGE`, which is written by the `ort` merge
strategy upon hitting merge conflicts (see linkgit:git-merge[1]).
Comparing the working tree with `AUTO_MERGE` shows changes you've made
so far to resolve textual conflicts (see the examples below).
For a more complete list of ways to spell _<commit>_, see
"SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
However, `diff` is about comparing two _endpoints_, not ranges,
and the range notations (`<commit>..<commit>` and `<commit>...<commit>`)
do not mean a range as defined in the
"SPECIFYING RANGES" section in linkgit:gitrevisions[7].
`git diff [<options>] <blob> <blob>`::
This form is to view the differences between the raw
contents of two blob objects.
OPTIONS
-------
:git-diff: 1
include::diff-options.adoc[]
`-1`::
`--base`::
`-2`::
`--ours`::
`-3`::
`--theirs`::
Compare the working tree with
+
--
* the "base" version (stage #1) when using `-1` or `--base`,
* "our branch" (stage #2) when using `-2` or `--ours`, or
* "their branch" (stage #3) when using `-3` or `--theirs`.
--
+
The index contains these stages only for unmerged entries i.e.
while resolving conflicts. See linkgit:git-read-tree[1]
section "3-Way Merge" for detailed information.
`-0`::
Omit diff output for unmerged entries and just show
"Unmerged". Can be used only when comparing the working tree
with the index.
`<path>...`::
The _<path>_ parameters, when given, are used to limit
the diff to the named paths (you can give directory
names and get diff for all files under them).
include::diff-format.adoc[]
EXAMPLES
--------
Various ways to check your working tree::
+
------------
$ git diff <1>
$ git diff --cached <2>
$ git diff HEAD <3>
$ git diff AUTO_MERGE <4>
------------
+
<1> Changes in the working tree not yet staged for the next commit.
<2> Changes between the index and your last commit; what you
would be committing if you run `git commit` without `-a` option.
<3> Changes in the working tree since your last commit; what you
would be committing if you run `git commit -a`
<4> Changes in the working tree you've made to resolve textual
conflicts so far.
Comparing with arbitrary commits::
+
------------
$ git diff test <1>
$ git diff HEAD -- ./test <2>
$ git diff HEAD^ HEAD <3>
------------
+
<1> Instead of using the tip of the current branch, compare with the
tip of "test" branch.
<2> Instead of comparing with the tip of "test" branch, compare with
the tip of the current branch, but limit the comparison to the
file "test".
<3> Compare the version before the last commit and the last commit.
Comparing branches::
+
------------
$ git diff topic master <1>
$ git diff topic..master <2>
$ git diff topic...master <3>
------------
+
<1> Changes between the tips of the topic and the master branches.
<2> Same as above.
<3> Changes that occurred on the master branch since when the topic
branch was started off it.
Limiting the diff output::
+
------------
$ git diff --diff-filter=MRC <1>
$ git diff --name-status <2>
$ git diff arch/i386 include/asm-i386 <3>
------------
+
<1> Show only modification, rename, and copy, but not addition
or deletion.
<2> Show only names and the nature of change, but not actual
diff output.
<3> Limit diff output to named subtrees.
Munging the diff output::
+
------------
$ git diff --find-copies-harder -B -C <1>
$ git diff -R <2>
------------
+
<1> Spend extra cycles to find renames, copies and complete
rewrites (very expensive).
<2> Output diff in reverse.
CONFIGURATION
-------------
include::includes/cmd-config-section-all.adoc[]
:git-diff: 1
include::config/diff.adoc[]
SEE ALSO
--------
`diff`(1),
linkgit:git-difftool[1],
linkgit:git-log[1],
linkgit:gitdiffcore[7],
linkgit:git-format-patch[1],
linkgit:git-apply[1],
linkgit:git-show[1]
GIT
---
Part of the linkgit:git[1] suite

142
app/src/main/assets/manpages/git-difftool.txt Normal file
View File

@@ -0,0 +1,142 @@
git-difftool(1)
===============
NAME
----
git-difftool - Show changes using common diff tools
SYNOPSIS
--------
[verse]
'git difftool' [<options>] [<commit> [<commit>]] [--] [<path>...]
DESCRIPTION
-----------
'git difftool' is a Git command that allows you to compare and edit files
between revisions using common diff tools. 'git difftool' is a frontend
to 'git diff' and accepts the same options and arguments. See
linkgit:git-diff[1].
OPTIONS
-------
-d::
--dir-diff::
Copy the modified files to a temporary location and perform
a directory diff on them. This mode never prompts before
launching the diff tool.
-y::
--no-prompt::
Do not prompt before launching a diff tool.
--prompt::
Prompt before each invocation of the diff tool.
This is the default behaviour; the option is provided to
override any configuration settings.
--rotate-to=<file>::
Start showing the diff for the given path,
the paths before it will move to the end and output.
--skip-to=<file>::
Start showing the diff for the given path, skipping all
the paths before it.
-t <tool>::
--tool=<tool>::
Use the diff tool specified by <tool>. Valid values include
emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help`
for the list of valid <tool> settings.
+
If a diff tool is not specified, 'git difftool'
will use the configuration variable `diff.tool`. If the
configuration variable `diff.tool` is not set, 'git difftool'
will pick a suitable default.
+
You can explicitly provide a full path to the tool by setting the
configuration variable `difftool.<tool>.path`. For example, you
can configure the absolute path to kdiff3 by setting
`difftool.kdiff3.path`. Otherwise, 'git difftool' assumes the
tool is available in PATH.
+
Instead of running one of the known diff tools,
'git difftool' can be customized to run an alternative program
by specifying the command line to invoke in a configuration
variable `difftool.<tool>.cmd`.
+
When 'git difftool' is invoked with this tool (either through the
`-t` or `--tool` option or the `diff.tool` configuration variable)
the configured command line will be invoked with the following
variables available: `$LOCAL` is set to the name of the temporary
file containing the contents of the diff pre-image and `$REMOTE`
is set to the name of the temporary file containing the contents
of the diff post-image. `$MERGED` is the name of the file which is
being compared. `$BASE` is provided for compatibility
with custom merge tool commands and has the same value as `$MERGED`.
--tool-help::
Print a list of diff tools that may be used with `--tool`.
--symlinks::
--no-symlinks::
'git difftool''s default behavior is to create symlinks to the
working tree when run in `--dir-diff` mode and the right-hand
side of the comparison yields the same content as the file in
the working tree.
+
Specifying `--no-symlinks` instructs 'git difftool' to create copies
instead. `--no-symlinks` is the default on Windows.
-x <command>::
--extcmd=<command>::
Specify a custom command for viewing diffs.
'git-difftool' ignores the configured defaults and runs
`<command> $LOCAL $REMOTE` when this option is specified.
Additionally, `$BASE` is set in the environment.
-g::
--gui::
--no-gui::
When 'git-difftool' is invoked with the `-g` or `--gui` option
the default diff tool will be read from the configured
`diff.guitool` variable instead of `diff.tool`. This may be
selected automatically using the configuration variable
`difftool.guiDefault`. The `--no-gui` option can be used to
override these settings. If `diff.guitool` is not set, we will
fallback in the order of `merge.guitool`, `diff.tool`,
`merge.tool` until a tool is found.
--trust-exit-code::
--no-trust-exit-code::
Errors reported by the diff tool are ignored by default.
Use `--trust-exit-code` to make 'git-difftool' exit when an
invoked diff tool returns a non-zero exit code.
+
'git-difftool' will forward the exit code of the invoked tool when
`--trust-exit-code` is used.
See linkgit:git-diff[1] for the full list of supported options.
CONFIGURATION
-------------
'git difftool' falls back to 'git mergetool' config variables when the
difftool equivalents have not been defined.
include::includes/cmd-config-section-rest.adoc[]
include::config/difftool.adoc[]
SEE ALSO
--------
linkgit:git-diff[1]::
Show changes between commits, commit and working tree, etc
linkgit:git-mergetool[1]::
Run merge conflict resolution tools to resolve merge conflicts
linkgit:git-config[1]::
Get and set repository or global options
GIT
---
Part of the linkgit:git[1] suite

315
app/src/main/assets/manpages/git-fast-export.txt Normal file
View File

@@ -0,0 +1,315 @@
git-fast-export(1)
==================
NAME
----
git-fast-export - Git data exporter
SYNOPSIS
--------
[verse]
'git fast-export' [<options>] | 'git fast-import'
DESCRIPTION
-----------
This program dumps the given revisions in a form suitable to be piped
into 'git fast-import'.
You can use it as a human-readable bundle replacement (see
linkgit:git-bundle[1]), or as a format that can be edited before being
fed to 'git fast-import' in order to do history rewrites (an ability
relied on by tools like 'git filter-repo').
OPTIONS
-------
--progress=<n>::
Insert 'progress' statements every <n> objects, to be shown by
'git fast-import' during import.
--signed-tags=(verbatim|warn-verbatim|warn-strip|strip|abort)::
Specify how to handle signed tags. Since any transformation
after the export (or during the export, such as excluding
revisions) can change the hashes being signed, the signatures
may become invalid.
+
When asking to 'abort' (which is the default), this program will die
when encountering a signed tag. With 'strip', the tags will silently
be made unsigned, with 'warn-strip' they will be made unsigned but a
warning will be displayed, with 'verbatim', they will be silently
exported and with 'warn-verbatim' (or 'warn', a deprecated synonym),
they will be exported, but you will see a warning. 'verbatim' and
'warn-verbatim' should only be used if you know that no transformation
affecting tags or any commit in their history will be performed by you
or by fast-export or fast-import, or if you do not care that the
resulting tag will have an invalid signature.
--signed-commits=(verbatim|warn-verbatim|warn-strip|strip|abort)::
Specify how to handle signed commits. Behaves exactly as
'--signed-tags', but for commits. Default is 'strip', which
is the same as how earlier versions of this command without
this option behaved.
+
When exported, a signature starts with:
+
gpgsig <git-hash-algo> <signature-format>
+
where <git-hash-algo> is the Git object hash so either "sha1" or
"sha256", and <signature-format> is the signature type, so "openpgp",
"x509", "ssh" or "unknown".
+
For example, an OpenPGP signature on a SHA-1 commit starts with
`gpgsig sha1 openpgp`, while an SSH signature on a SHA-256 commit
starts with `gpgsig sha256 ssh`.
+
While all the signatures of a commit are exported, an importer may
choose to accept only some of them. For example
linkgit:git-fast-import[1] currently stores at most one signature per
Git hash algorithm in each commit.
+
NOTE: This is highly experimental and the format of the data stream may
change in the future without compatibility guarantees.
--tag-of-filtered-object=(abort|drop|rewrite)::
Specify how to handle tags whose tagged object is filtered out.
Since revisions and files to export can be limited by path,
tagged objects may be filtered completely.
+
When asking to 'abort' (which is the default), this program will die
when encountering such a tag. With 'drop' it will omit such tags from
the output. With 'rewrite', if the tagged object is a commit, it will
rewrite the tag to tag an ancestor commit (via parent rewriting; see
linkgit:git-rev-list[1]).
-M::
-C::
Perform move and/or copy detection, as described in the
linkgit:git-diff[1] manual page, and use it to generate
rename and copy commands in the output dump.
+
Note that earlier versions of this command did not complain and
produced incorrect results if you gave these options.
--export-marks=<file>::
Dumps the internal marks table to <file> when complete.
Marks are written one per line as `:markid SHA-1`. Only marks
for revisions are dumped; marks for blobs are ignored.
Backends can use this file to validate imports after they
have been completed, or to save the marks table across
incremental runs. As <file> is only opened and truncated
at completion, the same path can also be safely given to
--import-marks.
The file will not be written if no new object has been
marked/exported.
--import-marks=<file>::
Before processing any input, load the marks specified in
<file>. The input file must exist, must be readable, and
must use the same format as produced by --export-marks.
--mark-tags::
In addition to labelling blobs and commits with mark ids, also
label tags. This is useful in conjunction with
`--export-marks` and `--import-marks`, and is also useful (and
necessary) for exporting of nested tags. It does not hurt
other cases and would be the default, but many fast-import
frontends are not prepared to accept tags with mark
identifiers.
+
Any commits (or tags) that have already been marked will not be
exported again. If the backend uses a similar --import-marks file,
this allows for incremental bidirectional exporting of the repository
by keeping the marks the same across runs.
--fake-missing-tagger::
Some old repositories have tags without a tagger. The
fast-import protocol was pretty strict about that, and did not
allow that. So fake a tagger to be able to fast-import the
output.
--use-done-feature::
Start the stream with a 'feature done' stanza, and terminate
it with a 'done' command.
--no-data::
Skip output of blob objects and instead refer to blobs via
their original SHA-1 hash. This is useful when rewriting the
directory structure or history of a repository without
touching the contents of individual files. Note that the
resulting stream can only be used by a repository which
already contains the necessary objects.
--full-tree::
This option will cause fast-export to issue a "deleteall"
directive for each commit followed by a full list of all files
in the commit (as opposed to just listing the files which are
different from the commit's first parent).
--anonymize::
Anonymize the contents of the repository while still retaining
the shape of the history and stored tree. See the section on
`ANONYMIZING` below.
--anonymize-map=<from>[:<to>]::
Convert token `<from>` to `<to>` in the anonymized output. If
`<to>` is omitted, map `<from>` to itself (i.e., do not
anonymize it). See the section on `ANONYMIZING` below.
--reference-excluded-parents::
By default, running a command such as `git fast-export
master~5..master` will not include the commit master{tilde}5
and will make master{tilde}4 no longer have master{tilde}5 as
a parent (though both the old master{tilde}4 and new
master{tilde}4 will have all the same files). Use
--reference-excluded-parents to instead have the stream
refer to commits in the excluded range of history by their
sha1sum. Note that the resulting stream can only be used by a
repository which already contains the necessary parent
commits.
--show-original-ids::
Add an extra directive to the output for commits and blobs,
`original-oid <SHA1SUM>`. While such directives will likely be
ignored by importers such as git-fast-import, it may be useful
for intermediary filters (e.g. for rewriting commit messages
which refer to older commits, or for stripping blobs by id).
--reencode=(yes|no|abort)::
Specify how to handle `encoding` header in commit objects. When
asking to 'abort' (which is the default), this program will die
when encountering such a commit object. With 'yes', the commit
message will be re-encoded into UTF-8. With 'no', the original
encoding will be preserved.
--refspec::
Apply the specified refspec to each ref exported. Multiple of them can
be specified.
[<git-rev-list-args>...]::
A list of arguments, acceptable to 'git rev-parse' and
'git rev-list', that specifies the specific objects and references
to export. For example, `master~10..master` causes the
current master reference to be exported along with all objects
added since its 10th ancestor commit and (unless the
--reference-excluded-parents option is specified) all files
common to master{tilde}9 and master{tilde}10.
EXAMPLES
--------
-------------------------------------------------------------------
$ git fast-export --all | (cd /empty/repository && git fast-import)
-------------------------------------------------------------------
This will export the whole repository and import it into the existing
empty repository. Except for reencoding commits that are not in
UTF-8, it would be a one-to-one mirror.
-----------------------------------------------------
$ git fast-export master~5..master |
sed "s|refs/heads/master|refs/heads/other|" |
git fast-import
-----------------------------------------------------
This makes a new branch called 'other' from 'master~5..master'
(i.e. if 'master' has linear history, it will take the last 5 commits).
Note that this assumes that none of the blobs and commit messages
referenced by that revision range contains the string
'refs/heads/master'.
ANONYMIZING
-----------
If the `--anonymize` option is given, git will attempt to remove all
identifying information from the repository while still retaining enough
of the original tree and history patterns to reproduce some bugs. The
goal is that a git bug which is found on a private repository will
persist in the anonymized repository, and the latter can be shared with
git developers to help solve the bug.
With this option, git will replace all refnames, paths, blob contents,
commit and tag messages, names, and email addresses in the output with
anonymized data. Two instances of the same string will be replaced
equivalently (e.g., two commits with the same author will have the same
anonymized author in the output, but bear no resemblance to the original
author string). The relationship between commits, branches, and tags is
retained, as well as the commit timestamps (but the commit messages and
refnames bear no resemblance to the originals). The relative makeup of
the tree is retained (e.g., if you have a root tree with 10 files and 3
trees, so will the output), but their names and the contents of the
files will be replaced.
If you think you have found a git bug, you can start by exporting an
anonymized stream of the whole repository:
---------------------------------------------------
$ git fast-export --anonymize --all >anon-stream
---------------------------------------------------
Then confirm that the bug persists in a repository created from that
stream (many bugs will not, as they really do depend on the exact
repository contents):
---------------------------------------------------
$ git init anon-repo
$ cd anon-repo
$ git fast-import <../anon-stream
$ ... test your bug ...
---------------------------------------------------
If the anonymized repository shows the bug, it may be worth sharing
`anon-stream` along with a regular bug report. Note that the anonymized
stream compresses very well, so gzipping it is encouraged. If you want
to examine the stream to see that it does not contain any private data,
you can peruse it directly before sending. You may also want to try:
---------------------------------------------------
$ perl -pe 's/\d+/X/g' <anon-stream | sort -u | less
---------------------------------------------------
which shows all of the unique lines (with numbers converted to "X", to
collapse "User 0", "User 1", etc into "User X"). This produces a much
smaller output, and it is usually easy to quickly confirm that there is
no private data in the stream.
Reproducing some bugs may require referencing particular commits or
paths, which becomes challenging after refnames and paths have been
anonymized. You can ask for a particular token to be left as-is or
mapped to a new value. For example, if you have a bug which reproduces
with `git rev-list sensitive -- secret.c`, you can run:
---------------------------------------------------
$ git fast-export --anonymize --all \
--anonymize-map=sensitive:foo \
--anonymize-map=secret.c:bar.c \
>stream
---------------------------------------------------
After importing the stream, you can then run `git rev-list foo -- bar.c`
in the anonymized repository.
Note that paths and refnames are split into tokens at slash boundaries.
The command above would anonymize `subdir/secret.c` as something like
`path123/bar.c`; you could then search for `bar.c` in the anonymized
repository to determine the final pathname.
To make referencing the final pathname simpler, you can map each path
component; so if you also anonymize `subdir` to `publicdir`, then the
final pathname would be `publicdir/bar.c`.
LIMITATIONS
-----------
Since 'git fast-import' cannot tag trees, you will not be
able to export the linux.git repository completely, as it contains
a tag referencing a tree instead of a commit.
SEE ALSO
--------
linkgit:git-fast-import[1]
GIT
---
Part of the linkgit:git[1] suite

1667
app/src/main/assets/manpages/git-fast-import.txt Normal file
View File

File diff suppressed because it is too large Load Diff

136
app/src/main/assets/manpages/git-fetch-pack.txt Normal file
View File

@@ -0,0 +1,136 @@
git-fetch-pack(1)
=================
NAME
----
git-fetch-pack - Receive missing objects from another repository
SYNOPSIS
--------
[verse]
'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag]
[--upload-pack=<git-upload-pack>]
[--depth=<n>] [--no-progress]
[-v] <repository> [<refs>...]
DESCRIPTION
-----------
Usually you would want to use 'git fetch', which is a
higher level wrapper of this command, instead.
Invokes 'git-upload-pack' on a possibly remote repository
and asks it to send objects missing from this repository, to
update the named heads. The list of commits available locally
is found out by scanning the local refs/ hierarchy and sent to
'git-upload-pack' running on the other end.
This command degenerates to download everything to complete the
asked refs from the remote side when the local side does not
have a common ancestor commit.
OPTIONS
-------
--all::
Fetch all remote refs.
--stdin::
Take the list of refs from stdin, one per line. If there
are refs specified on the command line in addition to this
option, then the refs from stdin are processed after those
on the command line.
+
If `--stateless-rpc` is specified together with this option then
the list of refs must be in packet format (pkt-line). Each ref must
be in a separate packet, and the list must end with a flush packet.
-q::
--quiet::
Pass `-q` flag to 'git unpack-objects'; this makes the
cloning process less verbose.
-k::
--keep::
Do not invoke 'git unpack-objects' on received data, but
create a single packfile out of it instead, and store it
in the object database. If provided twice then the pack is
locked against repacking.
--thin::
Fetch a "thin" pack, which records objects in deltified form based
on objects not included in the pack to reduce network traffic.
--include-tag::
If the remote side supports it, annotated tags objects will
be downloaded on the same connection as the other objects if
the object the tag references is downloaded. The caller must
otherwise determine the tags this option made available.
--upload-pack=<git-upload-pack>::
Use this to specify the path to 'git-upload-pack' on the
remote side, if it is not found on your $PATH.
Installations of sshd ignores the user's environment
setup scripts for login shells (e.g. .bash_profile) and
your privately installed git may not be found on the system
default $PATH. Another workaround suggested is to set
up your $PATH in ".bashrc", but this flag is for people
who do not want to pay the overhead for non-interactive
shells by having a lean .bashrc file (they set most of
the things up in .bash_profile).
--exec=<git-upload-pack>::
Same as --upload-pack=<git-upload-pack>.
--depth=<n>::
Limit fetching to ancestor-chains not longer than n.
'git-upload-pack' treats the special depth 2147483647 as
infinite even if there is an ancestor-chain that long.
--shallow-since=<date>::
Deepen or shorten the history of a shallow repository to
include all reachable commits after <date>.
--shallow-exclude=<ref>::
Deepen or shorten the history of a shallow repository to
exclude commits reachable from a specified remote branch or tag.
This option can be specified multiple times.
--deepen-relative::
Argument --depth specifies the number of commits from the
current shallow boundary instead of from the tip of each
remote branch history.
--refetch::
Skips negotiating commits with the server in order to fetch all matching
objects. Use to reapply a new partial clone blob/tree filter.
--no-progress::
Do not show the progress.
--check-self-contained-and-connected::
Output "connectivity-ok" if the received pack is
self-contained and connected.
-v::
Run verbosely.
<repository>::
The URL to the remote repository.
<refs>...::
The remote heads to update from. This is relative to
$GIT_DIR (e.g. "HEAD", "refs/heads/master"). When
unspecified, update from all heads the remote side has.
+
If the remote has enabled the options `uploadpack.allowTipSHA1InWant`,
`uploadpack.allowReachableSHA1InWant`, or `uploadpack.allowAnySHA1InWant`,
they may alternatively be 40-hex sha1s present on the remote.
SEE ALSO
--------
linkgit:git-fetch[1]
GIT
---
Part of the linkgit:git[1] suite

317
app/src/main/assets/manpages/git-fetch.txt Normal file
View File

@@ -0,0 +1,317 @@
git-fetch(1)
============
NAME
----
git-fetch - Download objects and refs from another repository
SYNOPSIS
--------
[synopsis]
git fetch [<options>] [<repository> [<refspec>...]]
git fetch [<options>] <group>
git fetch --multiple [<options>] [(<repository>|<group>)...]
git fetch --all [<options>]
DESCRIPTION
-----------
Fetch branches and/or tags (collectively, "refs") from one or more
other repositories, along with the objects necessary to complete their
histories. Remote-tracking branches are updated (see the description
of _<refspec>_ below for ways to control this behavior).
By default, any tag that points into the histories being fetched is
also fetched; the effect is to fetch tags that
point at branches that you are interested in. This default behavior
can be changed by using the `--tags` or `--no-tags` options or by
configuring `remote.<name>.tagOpt`. By using a refspec that fetches tags
explicitly, you can fetch tags that do not point into branches you
are interested in as well.
`git fetch` can fetch from either a single named repository or URL,
or from several repositories at once if _<group>_ is given and
there is a `remotes.<group>` entry in the configuration file.
(See linkgit:git-config[1]).
When no remote is specified, by default the `origin` remote will be used,
unless there's an upstream branch configured for the current branch.
The names of refs that are fetched, together with the object names
they point at, are written to `.git/FETCH_HEAD`. This information
may be used by scripts or other git commands, such as linkgit:git-pull[1].
OPTIONS
-------
include::fetch-options.adoc[]
include::pull-fetch-param.adoc[]
`--stdin`::
Read refspecs, one per line, from stdin in addition to those provided
as arguments. The "tag _<name>_" format is not supported.
include::urls-remotes.adoc[]
[[CRTB]]
CONFIGURED REMOTE-TRACKING BRANCHES
-----------------------------------
You often interact with the same remote repository by
regularly and repeatedly fetching from it. In order to keep track
of the progress of such a remote repository, `git fetch` allows you
to configure `remote.<repository>.fetch` configuration variables.
Typically such a variable may look like this:
------------------------------------------------
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
------------------------------------------------
This configuration is used in two ways:
* When `git fetch` is run without specifying what branches
and/or tags to fetch on the command line, e.g. `git fetch origin`
or `git fetch`, `remote.<repository>.fetch` values are used as
the refspecs--they specify which refs to fetch and which local refs
to update. The example above will fetch
all branches that exist in the `origin` (i.e. any ref that matches
the left-hand side of the value, `refs/heads/*`) and update the
corresponding remote-tracking branches in the `refs/remotes/origin/*`
hierarchy.
* When `git fetch` is run with explicit branches and/or tags
to fetch on the command line, e.g. `git fetch origin master`, the
_<refspec>s_ given on the command line determine what are to be
fetched (e.g. `master` in the example,
which is a short-hand for `master:`, which in turn means
"fetch the `master` branch but I do not explicitly say what
remote-tracking branch to update with it from the command line"),
and the example command will
fetch _only_ the `master` branch. The `remote.<repository>.fetch`
values determine which
remote-tracking branch, if any, is updated. When used in this
way, the `remote.<repository>.fetch` values do not have any
effect in deciding _what_ gets fetched (i.e. the values are not
used as refspecs when the command-line lists refspecs); they are
only used to decide _where_ the refs that are fetched are stored
by acting as a mapping.
The latter use of the `remote.<repository>.fetch` values can be
overridden by giving the `--refmap=<refspec>` parameter(s) on the
command line.
PRUNING
-------
Git has a default disposition of keeping data unless it's explicitly
thrown away; this extends to holding onto local references to branches
on remotes that have themselves deleted those branches.
If left to accumulate, these stale references might make performance
worse on big and busy repos that have a lot of branch churn, and
e.g. make the output of commands like `git branch -a --contains
<commit>` needlessly verbose, as well as impacting anything else
that'll work with the complete set of known references.
These remote-tracking references can be deleted as a one-off with
either of:
------------------------------------------------
# While fetching
$ git fetch --prune <name>
# Only prune, don't fetch
$ git remote prune <name>
------------------------------------------------
To prune references as part of your normal workflow without needing to
remember to run that, set `fetch.prune` globally, or
`remote.<name>.prune` per-remote in the config. See
linkgit:git-config[1].
Here's where things get tricky and more specific. The pruning feature
doesn't actually care about branches, instead it'll prune local <-->
remote-references as a function of the refspec of the remote (see
`<refspec>` and <<CRTB,CONFIGURED REMOTE-TRACKING BRANCHES>> above).
Therefore if the refspec for the remote includes
e.g. `refs/tags/*:refs/tags/*`, or you manually run e.g. `git fetch
--prune <name> "refs/tags/*:refs/tags/*"` it won't be stale remote
tracking branches that are deleted, but any local tag that doesn't
exist on the remote.
This might not be what you expect, i.e. you want to prune remote
_<name>_, but also explicitly fetch tags from it, so when you fetch
from it you delete all your local tags, most of which may not have
come from the _<name>_ remote in the first place.
So be careful when using this with a refspec like
`refs/tags/*:refs/tags/*`, or any other refspec which might map
references from multiple remotes to the same local namespace.
Since keeping up-to-date with both branches and tags on the remote is
a common use-case the `--prune-tags` option can be supplied along with
`--prune` to prune local tags that don't exist on the remote, and
force-update those tags that differ. Tag pruning can also be enabled
with `fetch.pruneTags` or `remote.<name>.pruneTags` in the config. See
linkgit:git-config[1].
The `--prune-tags` option is equivalent to having
`refs/tags/*:refs/tags/*` declared in the refspecs of the remote. This
can lead to some seemingly strange interactions:
------------------------------------------------
# These both fetch tags
$ git fetch --no-tags origin 'refs/tags/*:refs/tags/*'
$ git fetch --no-tags --prune-tags origin
------------------------------------------------
The reason it doesn't error out when provided without `--prune` or its
config versions is for flexibility of the configured versions, and to
maintain a 1=1 mapping between what the command line flags do, and
what the configuration versions do.
It's reasonable to e.g. configure `fetch.pruneTags=true` in
`~/.gitconfig` to have tags pruned whenever `git fetch --prune` is
run, without making every invocation of `git fetch` without `--prune`
an error.
Pruning tags with `--prune-tags` also works when fetching a URL
instead of a named remote. These will all prune tags not found on
origin:
------------------------------------------------
$ git fetch origin --prune --prune-tags
$ git fetch origin --prune 'refs/tags/*:refs/tags/*'
$ git fetch <url-of-origin> --prune --prune-tags
$ git fetch <url-of-origin> --prune 'refs/tags/*:refs/tags/*'
------------------------------------------------
OUTPUT
------
The output of "git fetch" depends on the transport method used; this
section describes the output when fetching over the Git protocol
(either locally or via ssh) and Smart HTTP protocol.
The status of the fetch is output in tabular form, with each line
representing the status of a single ref. Each line is of the form:
-------------------------------
<flag> <summary> <from> -> <to> [<reason>]
-------------------------------
When using `--porcelain`, the output format is intended to be
machine-parseable. In contrast to the human-readable output formats it
thus prints to standard output instead of standard error. Each line is
of the form:
-------------------------------
<flag> <old-object-id> <new-object-id> <local-reference>
-------------------------------
The status of up-to-date refs is shown only if the `--verbose` option is
used.
In compact output mode, specified with configuration variable
fetch.output, if either entire _<from>_ or _<to>_ is found in the
other string, it will be substituted with `*` in the other string. For
example, `master -> origin/master` becomes `master -> origin/*`.
flag::
A single character indicating the status of the ref:
(space);; for a successfully fetched fast-forward;
`+`;; for a successful forced update;
`-`;; for a successfully pruned ref;
`t`;; for a successful tag update;
`*`;; for a successfully fetched new ref;
`!`;; for a ref that was rejected or failed to update; and
`=`;; for a ref that was up to date and did not need fetching.
summary::
For a successfully fetched ref, the summary shows the old and new
values of the ref in a form suitable for using as an argument to
`git log` (this is `<old>..<new>` in most cases, and
`<old>...<new>` for forced non-fast-forward updates).
from::
The name of the remote ref being fetched from, minus its
`refs/<type>/` prefix. In the case of deletion, the name of
the remote ref is "(none)".
to::
The name of the local ref being updated, minus its
`refs/<type>/` prefix.
reason::
A human-readable explanation. In the case of successfully fetched
refs, no explanation is needed. For a failed ref, the reason for
failure is described.
EXAMPLES
--------
* Update the remote-tracking branches:
+
------------------------------------------------
$ git fetch origin
------------------------------------------------
+
The above command copies all branches from the remote `refs/heads/`
namespace and stores them to the local `refs/remotes/origin/` namespace,
unless the `remote.<repository>.fetch` option is used to specify a
non-default refspec.
* Using refspecs explicitly:
+
------------------------------------------------
$ git fetch origin +seen:seen maint:tmp
------------------------------------------------
+
This updates (or creates, as necessary) branches `seen` and `tmp` in
the local repository by fetching from the branches (respectively)
`seen` and `maint` from the remote repository.
+
The `seen` branch will be updated even if it does not fast-forward,
because it is prefixed with a plus sign; `tmp` will not be.
* Peek at a remote's branch, without configuring the remote in your local
repository:
+
------------------------------------------------
$ git fetch git://git.kernel.org/pub/scm/git/git.git maint
$ git log FETCH_HEAD
------------------------------------------------
+
The first command fetches the `maint` branch from the repository at
`git://git.kernel.org/pub/scm/git/git.git` and the second command uses
`FETCH_HEAD` to examine the branch with linkgit:git-log[1]. The fetched
objects will eventually be removed by git's built-in housekeeping (see
linkgit:git-gc[1]).
include::transfer-data-leaks.adoc[]
CONFIGURATION
-------------
include::includes/cmd-config-section-all.adoc[]
include::config/fetch.adoc[]
BUGS
----
Using `--recurse-submodules` can only fetch new commits in submodules that are
present locally e.g. in `$GIT_DIR/modules/`. If the upstream adds a new
submodule, that submodule cannot be fetched until it is cloned e.g. by `git
submodule update`. This is expected to be fixed in a future Git version.
SEE ALSO
--------
linkgit:git-pull[1]
GIT
---
Part of the linkgit:git[1] suite

703
app/src/main/assets/manpages/git-filter-branch.txt Normal file
View File

@@ -0,0 +1,703 @@
git-filter-branch(1)
====================
NAME
----
git-filter-branch - Rewrite branches
SYNOPSIS
--------
[verse]
'git filter-branch' [--setup <command>] [--subdirectory-filter <directory>]
[--env-filter <command>] [--tree-filter <command>]
[--index-filter <command>] [--parent-filter <command>]
[--msg-filter <command>] [--commit-filter <command>]
[--tag-name-filter <command>] [--prune-empty]
[--original <namespace>] [-d <directory>] [-f | --force]
[--state-branch <branch>] [--] [<rev-list-options>...]
WARNING
-------
'git filter-branch' has a plethora of pitfalls that can produce non-obvious
manglings of the intended history rewrite (and can leave you with little
time to investigate such problems since it has such abysmal performance).
These safety and performance issues cannot be backward compatibly fixed and
as such, its use is not recommended. Please use an alternative history
filtering tool such as https://github.com/newren/git-filter-repo/[git
filter-repo]. If you still need to use 'git filter-branch', please
carefully read <<SAFETY>> (and <<PERFORMANCE>>) to learn about the land
mines of filter-branch, and then vigilantly avoid as many of the hazards
listed there as reasonably possible.
DESCRIPTION
-----------
Lets you rewrite Git revision history by rewriting the branches mentioned
in the <rev-list-options>, applying custom filters on each revision.
Those filters can modify each tree (e.g. removing a file or running
a perl rewrite on all files) or information about each commit.
Otherwise, all information (including original commit times or merge
information) will be preserved.
The command will only rewrite the _positive_ refs mentioned in the
command line (e.g. if you pass 'a..b', only 'b' will be rewritten).
If you specify no filters, the commits will be recommitted without any
changes, which would normally have no effect. Nevertheless, this may be
useful in the future for compensating for some Git bugs or such,
therefore such a usage is permitted.
*NOTE*: This command honors `.git/info/grafts` file and refs in
the `refs/replace/` namespace.
If you have any grafts or replacement refs defined, running this command
will make them permanent.
*WARNING*! The rewritten history will have different object names for all
the objects and will not converge with the original branch. You will not
be able to easily push and distribute the rewritten branch on top of the
original branch. Please do not use this command if you do not know the
full implications, and avoid using it anyway, if a simple single commit
would suffice to fix your problem. (See the "RECOVERING FROM UPSTREAM
REBASE" section in linkgit:git-rebase[1] for further information about
rewriting published history.)
Always verify that the rewritten version is correct: The original refs,
if different from the rewritten ones, will be stored in the namespace
'refs/original/'.
Note that since this operation is very I/O expensive, it might
be a good idea to redirect the temporary directory off-disk with the
`-d` option, e.g. on tmpfs. Reportedly the speedup is very noticeable.
Filters
~~~~~~~
The filters are applied in the order as listed below. The <command>
argument is always evaluated in the shell context using the 'eval' command
(with the notable exception of the commit filter, for technical reasons).
Prior to that, the `$GIT_COMMIT` environment variable will be set to contain
the id of the commit being rewritten. Also, GIT_AUTHOR_NAME,
GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE, GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL,
and GIT_COMMITTER_DATE are taken from the current commit and exported to
the environment, in order to affect the author and committer identities of
the replacement commit created by linkgit:git-commit-tree[1] after the
filters have run.
If any evaluation of <command> returns a non-zero exit status, the whole
operation will be aborted.
A 'map' function is available that takes an "original sha1 id" argument
and outputs a "rewritten sha1 id" if the commit has been already
rewritten, and "original sha1 id" otherwise; the 'map' function can
return several ids on separate lines if your commit filter emitted
multiple commits.
OPTIONS
-------
--setup <command>::
This is not a real filter executed for each commit but a one
time setup just before the loop. Therefore no commit-specific
variables are defined yet. Functions or variables defined here
can be used or modified in the following filter steps except
the commit filter, for technical reasons.
--subdirectory-filter <directory>::
Only look at the history which touches the given subdirectory.
The result will contain that directory (and only that) as its
project root. Implies <<Remap_to_ancestor>>.
--env-filter <command>::
This filter may be used if you only need to modify the environment
in which the commit will be performed. Specifically, you might
want to rewrite the author/committer name/email/time environment
variables (see linkgit:git-commit-tree[1] for details).
--tree-filter <command>::
This is the filter for rewriting the tree and its contents.
The argument is evaluated in shell with the working
directory set to the root of the checked out tree. The new tree
is then used as-is (new files are auto-added, disappeared files
are auto-removed - neither .gitignore files nor any other ignore
rules *HAVE ANY EFFECT*!).
--index-filter <command>::
This is the filter for rewriting the index. It is similar to the
tree filter but does not check out the tree, which makes it much
faster. Frequently used with `git rm --cached
--ignore-unmatch ...`, see EXAMPLES below. For hairy
cases, see linkgit:git-update-index[1].
--parent-filter <command>::
This is the filter for rewriting the commit's parent list.
It will receive the parent string on stdin and shall output
the new parent string on stdout. The parent string is in
the format described in linkgit:git-commit-tree[1]: empty for
the initial commit, "-p parent" for a normal commit and
"-p parent1 -p parent2 -p parent3 ..." for a merge commit.
--msg-filter <command>::
This is the filter for rewriting the commit messages.
The argument is evaluated in the shell with the original
commit message on standard input; its standard output is
used as the new commit message.
--commit-filter <command>::
This is the filter for performing the commit.
If this filter is specified, it will be called instead of the
'git commit-tree' command, with arguments of the form
"<TREE_ID> [(-p <PARENT_COMMIT_ID>)...]" and the log message on
stdin. The commit id is expected on stdout.
+
As a special extension, the commit filter may emit multiple
commit ids; in that case, the rewritten children of the original commit will
have all of them as parents.
+
You can use the 'map' convenience function in this filter, and other
convenience functions, too. For example, calling 'skip_commit "$@"'
will leave out the current commit (but not its changes! If you want
that, use 'git rebase' instead).
+
You can also use the `git_commit_non_empty_tree "$@"` instead of
`git commit-tree "$@"` if you don't wish to keep commits with a single parent
and that makes no change to the tree.
--tag-name-filter <command>::
This is the filter for rewriting tag names. When passed,
it will be called for every tag ref that points to a rewritten
object (or to a tag object which points to a rewritten object).
The original tag name is passed via standard input, and the new
tag name is expected on standard output.
+
The original tags are not deleted, but can be overwritten;
use "--tag-name-filter cat" to simply update the tags. In this
case, be very careful and make sure you have the old tags
backed up in case the conversion has run afoul.
+
Nearly proper rewriting of tag objects is supported. If the tag has
a message attached, a new tag object will be created with the same message,
author, and timestamp. If the tag has a signature attached, the
signature will be stripped. It is by definition impossible to preserve
signatures. The reason this is "nearly" proper, is because ideally if
the tag did not change (points to the same object, has the same name, etc.)
it should retain any signature. That is not the case, signatures will always
be removed, buyer beware. There is also no support for changing the
author or timestamp (or the tag message for that matter). Tags which point
to other tags will be rewritten to point to the underlying commit.
--prune-empty::
Some filters will generate empty commits that leave the tree untouched.
This option instructs git-filter-branch to remove such commits if they
have exactly one or zero non-pruned parents; merge commits will
therefore remain intact. This option cannot be used together with
`--commit-filter`, though the same effect can be achieved by using the
provided `git_commit_non_empty_tree` function in a commit filter.
--original <namespace>::
Use this option to set the namespace where the original commits
will be stored. The default value is 'refs/original'.
-d <directory>::
Use this option to set the path to the temporary directory used for
rewriting. When applying a tree filter, the command needs to
temporarily check out the tree to some directory, which may consume
considerable space in case of large projects. By default it
does this in the `.git-rewrite/` directory but you can override
that choice by this parameter.
-f::
--force::
'git filter-branch' refuses to start with an existing temporary
directory or when there are already refs starting with
'refs/original/', unless forced.
--state-branch <branch>::
This option will cause the mapping from old to new objects to
be loaded from named branch upon startup and saved as a new
commit to that branch upon exit, enabling incremental of large
trees. If '<branch>' does not exist it will be created.
<rev-list options>...::
Arguments for 'git rev-list'. All positive refs included by
these options are rewritten. You may also specify options
such as `--all`, but you must use `--` to separate them from
the 'git filter-branch' options. Implies <<Remap_to_ancestor>>.
[[Remap_to_ancestor]]
Remap to ancestor
~~~~~~~~~~~~~~~~~
By using linkgit:git-rev-list[1] arguments, e.g., path limiters, you can limit the
set of revisions which get rewritten. However, positive refs on the command
line are distinguished: we don't let them be excluded by such limiters. For
this purpose, they are instead rewritten to point at the nearest ancestor that
was not excluded.
EXIT STATUS
-----------
On success, the exit status is `0`. If the filter can't find any commits to
rewrite, the exit status is `2`. On any other error, the exit status may be
any other non-zero value.
EXAMPLES
--------
Suppose you want to remove a file (containing confidential information
or copyright violation) from all commits:
-------------------------------------------------------
git filter-branch --tree-filter 'rm filename' HEAD
-------------------------------------------------------
However, if the file is absent from the tree of some commit,
a simple `rm filename` will fail for that tree and commit.
Thus you may instead want to use `rm -f filename` as the script.
Using `--index-filter` with 'git rm' yields a significantly faster
version. Like with using `rm filename`, `git rm --cached filename`
will fail if the file is absent from the tree of a commit. If you
want to "completely forget" a file, it does not matter when it entered
history, so we also add `--ignore-unmatch`:
--------------------------------------------------------------------------
git filter-branch --index-filter 'git rm --cached --ignore-unmatch filename' HEAD
--------------------------------------------------------------------------
Now, you will get the rewritten history saved in HEAD.
To rewrite the repository to look as if `foodir/` had been its project
root, and discard all other history:
-------------------------------------------------------
git filter-branch --subdirectory-filter foodir -- --all
-------------------------------------------------------
Thus you can, e.g., turn a library subdirectory into a repository of
its own. Note the `--` that separates 'filter-branch' options from
revision options, and the `--all` to rewrite all branches and tags.
To set a commit (which typically is at the tip of another
history) to be the parent of the current initial commit, in
order to paste the other history behind the current history:
-------------------------------------------------------------------
git filter-branch --parent-filter 'sed "s/^\$/-p <graft-id>/"' HEAD
-------------------------------------------------------------------
(if the parent string is empty - which happens when we are dealing with
the initial commit - add graftcommit as a parent). Note that this assumes
history with a single root (that is, no merge without common ancestors
happened). If this is not the case, use:
--------------------------------------------------------------------------
git filter-branch --parent-filter \
'test $GIT_COMMIT = <commit-id> && echo "-p <graft-id>" || cat' HEAD
--------------------------------------------------------------------------
or even simpler:
-----------------------------------------------
git replace --graft $commit-id $graft-id
git filter-branch $graft-id..HEAD
-----------------------------------------------
To remove commits authored by "Darl McBribe" from the history:
------------------------------------------------------------------------------
git filter-branch --commit-filter '
if [ "$GIT_AUTHOR_NAME" = "Darl McBribe" ];
then
skip_commit "$@";
else
git commit-tree "$@";
fi' HEAD
------------------------------------------------------------------------------
The function 'skip_commit' is defined as follows:
--------------------------
skip_commit()
{
shift;
while [ -n "$1" ];
do
shift;
map "$1";
shift;
done;
}
--------------------------
The shift magic first throws away the tree id and then the -p
parameters. Note that this handles merges properly! In case Darl
committed a merge between P1 and P2, it will be propagated properly
and all children of the merge will become merge commits with P1,P2
as their parents instead of the merge commit.
*NOTE* the changes introduced by the commits, and which are not reverted
by subsequent commits, will still be in the rewritten branch. If you want
to throw out _changes_ together with the commits, you should use the
interactive mode of 'git rebase'.
You can rewrite the commit log messages using `--msg-filter`. For
example, 'git svn-id' strings in a repository created by 'git svn' can
be removed this way:
-------------------------------------------------------
git filter-branch --msg-filter '
sed -e "/^git-svn-id:/d"
'
-------------------------------------------------------
If you need to add 'Acked-by' lines to, say, the last 10 commits (none
of which is a merge), use this command:
--------------------------------------------------------
git filter-branch --msg-filter '
cat &&
echo "Acked-by: Bugs Bunny <bunny@bugzilla.org>"
' HEAD~10..HEAD
--------------------------------------------------------
The `--env-filter` option can be used to modify committer and/or author
identity. For example, if you found out that your commits have the wrong
identity due to a misconfigured user.email, you can make a correction,
before publishing the project, like this:
--------------------------------------------------------
git filter-branch --env-filter '
if test "$GIT_AUTHOR_EMAIL" = "root@localhost"
then
GIT_AUTHOR_EMAIL=john@example.com
fi
if test "$GIT_COMMITTER_EMAIL" = "root@localhost"
then
GIT_COMMITTER_EMAIL=john@example.com
fi
' -- --all
--------------------------------------------------------
To restrict rewriting to only part of the history, specify a revision
range in addition to the new branch name. The new branch name will
point to the top-most revision that a 'git rev-list' of this range
will print.
Consider this history:
------------------
D--E--F--G--H
/ /
A--B-----C
------------------
To rewrite only commits D,E,F,G,H, but leave A, B and C alone, use:
--------------------------------
git filter-branch ... C..H
--------------------------------
To rewrite commits E,F,G,H, use one of these:
----------------------------------------
git filter-branch ... C..H --not D
git filter-branch ... D..H --not C
----------------------------------------
To move the whole tree into a subdirectory, or remove it from there:
---------------------------------------------------------------
git filter-branch --index-filter \
'git ls-files -s | sed "s-\t\"*-&newsubdir/-" |
GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
git update-index --index-info &&
mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"' HEAD
---------------------------------------------------------------
CHECKLIST FOR SHRINKING A REPOSITORY
------------------------------------
git-filter-branch can be used to get rid of a subset of files,
usually with some combination of `--index-filter` and
`--subdirectory-filter`. People expect the resulting repository to
be smaller than the original, but you need a few more steps to
actually make it smaller, because Git tries hard not to lose your
objects until you tell it to. First make sure that:
* You really removed all variants of a filename, if a blob was moved
over its lifetime. `git log --name-only --follow --all -- filename`
can help you find renames.
* You really filtered all refs: use `--tag-name-filter cat -- --all`
when calling git-filter-branch.
Then there are two ways to get a smaller repository. A safer way is
to clone, that keeps your original intact.
* Clone it with `git clone file:///path/to/repo`. The clone
will not have the removed objects. See linkgit:git-clone[1]. (Note
that cloning with a plain path just hardlinks everything!)
If you really don't want to clone it, for whatever reasons, check the
following points instead (in this order). This is a very destructive
approach, so *make a backup* or go back to cloning it. You have been
warned.
* Remove the original refs backed up by git-filter-branch: say `git
for-each-ref --format="%(refname)" refs/original/ | xargs -n 1 git
update-ref -d`.
* Expire all reflogs with `git reflog expire --expire=now --all`.
* Garbage collect all unreferenced objects with `git gc --prune=now`
(or if your git-gc is not new enough to support arguments to
`--prune`, use `git repack -ad; git prune` instead).
[[PERFORMANCE]]
PERFORMANCE
-----------
The performance of git-filter-branch is glacially slow; its design makes it
impossible for a backward-compatible implementation to ever be fast:
* In editing files, git-filter-branch by design checks out each and
every commit as it existed in the original repo. If your repo has
`10^5` files and `10^5` commits, but each commit only modifies five
files, then git-filter-branch will make you do `10^10` modifications,
despite only having (at most) `5*10^5` unique blobs.
* If you try and cheat and try to make git-filter-branch only work on
files modified in a commit, then two things happen
** you run into problems with deletions whenever the user is simply
trying to rename files (because attempting to delete files that
don't exist looks like a no-op; it takes some chicanery to remap
deletes across file renames when the renames happen via arbitrary
user-provided shell)
** even if you succeed at the map-deletes-for-renames chicanery, you
still technically violate backward compatibility because users
are allowed to filter files in ways that depend upon topology of
commits instead of filtering solely based on file contents or
names (though this has not been observed in the wild).
* Even if you don't need to edit files but only want to e.g. rename or
remove some and thus can avoid checking out each file (i.e. you can
use --index-filter), you still are passing shell snippets for your
filters. This means that for every commit, you have to have a
prepared git repo where those filters can be run. That's a
significant setup.
* Further, several additional files are created or updated per commit
by git-filter-branch. Some of these are for supporting the
convenience functions provided by git-filter-branch (such as map()),
while others are for keeping track of internal state (but could have
also been accessed by user filters; one of git-filter-branch's
regression tests does so). This essentially amounts to using the
filesystem as an IPC mechanism between git-filter-branch and the
user-provided filters. Disks tend to be a slow IPC mechanism, and
writing these files also effectively represents a forced
synchronization point between separate processes that we hit with
every commit.
* The user-provided shell commands will likely involve a pipeline of
commands, resulting in the creation of many processes per commit.
Creating and running another process takes a widely varying amount
of time between operating systems, but on any platform it is very
slow relative to invoking a function.
* git-filter-branch itself is written in shell, which is kind of slow.
This is the one performance issue that could be backward-compatibly
fixed, but compared to the above problems that are intrinsic to the
design of git-filter-branch, the language of the tool itself is a
relatively minor issue.
** Side note: Unfortunately, people tend to fixate on the
written-in-shell aspect and periodically ask if git-filter-branch
could be rewritten in another language to fix the performance
issues. Not only does that ignore the bigger intrinsic problems
with the design, it'd help less than you'd expect: if
git-filter-branch itself were not shell, then the convenience
functions (map(), skip_commit(), etc) and the `--setup` argument
could no longer be executed once at the beginning of the program
but would instead need to be prepended to every user filter (and
thus re-executed with every commit).
The https://github.com/newren/git-filter-repo/[git filter-repo] tool is
an alternative to git-filter-branch which does not suffer from these
performance problems or the safety problems (mentioned below). For those
with existing tooling which relies upon git-filter-branch, 'git
filter-repo' also provides
https://github.com/newren/git-filter-repo/blob/master/contrib/filter-repo-demos/filter-lamely[filter-lamely],
a drop-in git-filter-branch replacement (with a few caveats). While
filter-lamely suffers from all the same safety issues as
git-filter-branch, it at least ameliorates the performance issues a
little.
[[SAFETY]]
SAFETY
------
git-filter-branch is riddled with gotchas resulting in various ways to
easily corrupt repos or end up with a mess worse than what you started
with:
* Someone can have a set of "working and tested filters" which they
document or provide to a coworker, who then runs them on a different
OS where the same commands are not working/tested (some examples in
the git-filter-branch manpage are also affected by this).
BSD vs. GNU userland differences can really bite. If lucky, error
messages are spewed. But just as likely, the commands either don't
do the filtering requested, or silently corrupt by making some
unwanted change. The unwanted change may only affect a few commits,
so it's not necessarily obvious either. (The fact that problems
won't necessarily be obvious means they are likely to go unnoticed
until the rewritten history is in use for quite a while, at which
point it's really hard to justify another flag-day for another
rewrite.)
* Filenames with spaces are often mishandled by shell snippets since
they cause problems for shell pipelines. Not everyone is familiar
with find -print0, xargs -0, git-ls-files -z, etc. Even people who
are familiar with these may assume such flags are not relevant
because someone else renamed any such files in their repo back
before the person doing the filtering joined the project. And
often, even those familiar with handling arguments with spaces may
not do so just because they aren't in the mindset of thinking about
everything that could possibly go wrong.
* Non-ascii filenames can be silently removed despite being in a
desired directory. Keeping only wanted paths is often done using
pipelines like `git ls-files | grep -v ^WANTED_DIR/ | xargs git rm`.
ls-files will only quote filenames if needed, so folks may not
notice that one of the files didn't match the regex (at least not
until it's much too late). Yes, someone who knows about
core.quotePath can avoid this (unless they have other special
characters like \t, \n, or "), and people who use ls-files -z with
something other than grep can avoid this, but that doesn't mean they
will.
* Similarly, when moving files around, one can find that filenames
with non-ascii or special characters end up in a different
directory, one that includes a double quote character. (This is
technically the same issue as above with quoting, but perhaps an
interesting different way that it can and has manifested as a
problem.)
* It's far too easy to accidentally mix up old and new history. It's
still possible with any tool, but git-filter-branch almost
invites it. If lucky, the only downside is users getting frustrated
that they don't know how to shrink their repo and remove the old
stuff. If unlucky, they merge old and new history and end up with
multiple "copies" of each commit, some of which have unwanted or
sensitive files and others which don't. This comes about in
multiple different ways:
** the default to only doing a partial history rewrite ('--all' is not
the default and few examples show it)
** the fact that there's no automatic post-run cleanup
** the fact that --tag-name-filter (when used to rename tags) doesn't
remove the old tags but just adds new ones with the new name
** the fact that little educational information is provided to inform
users of the ramifications of a rewrite and how to avoid mixing old
and new history. For example, this man page discusses how users
need to understand that they need to rebase their changes for all
their branches on top of new history (or delete and reclone), but
that's only one of multiple concerns to consider. See the
"DISCUSSION" section of the git filter-repo manual page for more
details.
* Annotated tags can be accidentally converted to lightweight tags,
due to either of two issues:
** Someone can do a history rewrite, realize they messed up, restore
from the backups in refs/original/, and then redo their
git-filter-branch command. (The backup in refs/original/ is not a
real backup; it dereferences tags first.)
** Running git-filter-branch with either --tags or --all in your
<rev-list-options>. In order to retain annotated tags as
annotated, you must use --tag-name-filter (and must not have
restored from refs/original/ in a previously botched rewrite).
* Any commit messages that specify an encoding will become corrupted
by the rewrite; git-filter-branch ignores the encoding, takes the
original bytes, and feeds it to commit-tree without telling it the
proper encoding. (This happens whether or not --msg-filter is
used.)
* Commit messages (even if they are all UTF-8) by default become
corrupted due to not being updated -- any references to other commit
hashes in commit messages will now refer to no-longer-extant
commits.
* There are no facilities for helping users find what unwanted crud
they should delete, which means they are much more likely to have
incomplete or partial cleanups that sometimes result in confusion
and people wasting time trying to understand. (For example, folks
tend to just look for big files to delete instead of big directories
or extensions, and once they do so, then sometime later folks using
the new repository who are going through history will notice a build
artifact directory that has some files but not others, or a cache of
dependencies (node_modules or similar) which couldn't have ever been
functional since it's missing some files.)
* If --prune-empty isn't specified, then the filtering process can
create hoards of confusing empty commits
* If --prune-empty is specified, then intentionally placed empty
commits from before the filtering operation are also pruned instead
of just pruning commits that became empty due to filtering rules.
* If --prune-empty is specified, sometimes empty commits are missed
and left around anyway (a somewhat rare bug, but it happens...)
* A minor issue, but users who have a goal to update all names and
emails in a repository may be led to --env-filter which will only
update authors and committers, missing taggers.
* If the user provides a --tag-name-filter that maps multiple tags to
the same name, no warning or error is provided; git-filter-branch
simply overwrites each tag in some undocumented pre-defined order
resulting in only one tag at the end. (A git-filter-branch
regression test requires this surprising behavior.)
Also, the poor performance of git-filter-branch often leads to safety
issues:
* Coming up with the correct shell snippet to do the filtering you
want is sometimes difficult unless you're just doing a trivial
modification such as deleting a couple files. Unfortunately, people
often learn if the snippet is right or wrong by trying it out, but
the rightness or wrongness can vary depending on special
circumstances (spaces in filenames, non-ascii filenames, funny
author names or emails, invalid timezones, presence of grafts or
replace objects, etc.), meaning they may have to wait a long time,
hit an error, then restart. The performance of git-filter-branch is
so bad that this cycle is painful, reducing the time available to
carefully re-check (to say nothing about what it does to the
patience of the person doing the rewrite even if they do technically
have more time available). This problem is extra compounded because
errors from broken filters may not be shown for a long time and/or
get lost in a sea of output. Even worse, broken filters often just
result in silent incorrect rewrites.
* To top it all off, even when users finally find working commands,
they naturally want to share them. But they may be unaware that
their repo didn't have some special cases that someone else's does.
So, when someone else with a different repository runs the same
commands, they get hit by the problems above. Or, the user just
runs commands that really were vetted for special cases, but they
run it on a different OS where it doesn't work, as noted above.
GIT
---
Part of the linkgit:git[1] suite

83
app/src/main/assets/manpages/git-fmt-merge-msg.txt Normal file
View File

@@ -0,0 +1,83 @@
git-fmt-merge-msg(1)
====================
NAME
----
git-fmt-merge-msg - Produce a merge commit message
SYNOPSIS
--------
[verse]
'git fmt-merge-msg' [-m <message>] [--into-name <branch>] [--log[=<n>] | --no-log]
'git fmt-merge-msg' [-m <message>] [--log[=<n>] | --no-log] -F <file>
DESCRIPTION
-----------
Takes the list of merged objects on stdin and produces a suitable
commit message to be used for the merge commit, usually to be
passed as the '<merge-message>' argument of 'git merge'.
This command is intended mostly for internal use by scripts
automatically invoking 'git merge'.
OPTIONS
-------
--log[=<n>]::
In addition to branch names, populate the log message with
one-line descriptions from the actual commits that are being
merged. At most <n> commits from each merge parent will be
used (20 if <n> is omitted). This overrides the `merge.log`
configuration variable.
--no-log::
Do not list one-line descriptions from the actual commits being
merged.
--summary::
--no-summary::
Synonyms to --log and --no-log; these are deprecated and will be
removed in the future.
-m <message>::
--message <message>::
Use <message> instead of the branch names for the first line
of the log message. For use with `--log`.
--into-name <branch>::
Prepare the merge message as if merging to the branch `<branch>`,
instead of the name of the real branch to which the merge is made.
-F <file>::
--file <file>::
Take the list of merged objects from <file> instead of
stdin.
CONFIGURATION
-------------
include::config/fmt-merge-msg.adoc[]
merge.summary::
Synonym to `merge.log`; this is deprecated and will be removed in
the future.
EXAMPLES
--------
---------
$ git fetch origin master
$ git fmt-merge-msg --log <$GIT_DIR/FETCH_HEAD
---------
Print a log message describing a merge of the "master" branch from
the "origin" remote.
SEE ALSO
--------
linkgit:git-merge[1]
GIT
---
Part of the linkgit:git[1] suite

476
app/src/main/assets/manpages/git-for-each-ref.txt Normal file
View File

@@ -0,0 +1,476 @@
git-for-each-ref(1)
===================
NAME
----
git-for-each-ref - Output information on each ref
SYNOPSIS
--------
[synopsis]
git for-each-ref [--count=<count>] [--shell|--perl|--python|--tcl]
[(--sort=<key>)...] [--format=<format>]
[--include-root-refs] [--points-at=<object>]
[--merged[=<object>]] [--no-merged[=<object>]]
[--contains[=<object>]] [--no-contains[=<object>]]
[(--exclude=<pattern>)...] [--start-after=<marker>]
[ --stdin | (<pattern>...)]
DESCRIPTION
-----------
Iterate over all refs that match _<pattern>_ and show them
according to the given _<format>_, after sorting them according
to the given set of _<key>_. If _<count>_ is given, stop after
showing that many refs. The interpolated values in _<format>_
can optionally be quoted as string literals in the specified
host language allowing their direct evaluation in that language.
OPTIONS
-------
include::for-each-ref-options.adoc[]
FIELD NAMES
-----------
Various values from structured fields in referenced objects can
be used to interpolate into the resulting output, or as sort
keys.
For all objects, the following names can be used:
`refname`::
The name of the ref (the part after `$GIT_DIR/`).
For a non-ambiguous short name of the ref append `:short`.
The option `core.warnAmbiguousRefs` is used to select the strict
abbreviation mode. If `lstrip=<n>` (`rstrip=<n>`) is appended, strip _<n>_
slash-separated path components from the front (back) of the refname
(e.g. `%(refname:lstrip=2)` turns `refs/tags/foo` into `foo` and
`%(refname:rstrip=2)` turns `refs/tags/foo` into `refs`).
If _<n>_ is a negative number, strip as many path components as
necessary from the specified end to leave `-<n>` path components
(e.g. `%(refname:lstrip=-2)` turns
`refs/tags/foo` into `tags/foo` and `%(refname:rstrip=-1)`
turns `refs/tags/foo` into `refs`). When the ref does not have
enough components, the result becomes an empty string if
stripping with positive _<n>_, or it becomes the full refname if
stripping with negative _<N>_. Neither is an error.
+
`strip` can be used as a synonym to `lstrip`.
`objecttype`::
The type of the object (`blob`, `tree`, `commit`, `tag`).
`objectsize`::
The size of the object (the same as 'git cat-file -s' reports).
Append `:disk` to get the size, in bytes, that the object takes up on
disk. See the note about on-disk sizes in the 'CAVEATS' section below.
`objectname`::
The object name (aka SHA-1).
For a non-ambiguous abbreviation of the object name append `:short`.
For an abbreviation of the object name with desired length append
`:short=<length>`, where the minimum length is `MINIMUM_ABBREV`. The
length may be exceeded to ensure unique object names.
`deltabase`::
This expands to the object name of the delta base for the
given object, if it is stored as a delta. Otherwise it
expands to the null object name (all zeroes).
`upstream`::
The name of a local ref which can be considered ``upstream''
from the displayed ref. Respects `:short`, `:lstrip` and
`:rstrip` in the same way as `refname` above. Additionally
respects `:track` to show "[ahead N, behind M]" and
`:trackshort` to show the terse version: ">" (ahead), "<"
(behind), "<>" (ahead and behind), or "=" (in sync). `:track`
also prints "[gone]" whenever unknown upstream ref is
encountered. Append `:track,nobracket` to show tracking
information without brackets (i.e "ahead N, behind M").
+
For any remote-tracking branch `%(upstream)`, `%(upstream:remotename)`
and `%(upstream:remoteref)` refer to the name of the remote and the
name of the tracked remote ref, respectively. In other words, the
remote-tracking branch can be updated explicitly and individually by
using the refspec `%(upstream:remoteref):%(upstream)` to fetch from
`%(upstream:remotename)`.
+
Has no effect if the ref does not have tracking information associated
with it. All the options apart from `nobracket` are mutually exclusive,
but if used together the last option is selected.
`push`::
The name of a local ref which represents the `@{push}`
location for the displayed ref. Respects `:short`, `:lstrip`,
`:rstrip`, `:track`, `:trackshort`, `:remotename`, and `:remoteref`
options as `upstream` does. Produces an empty string if no `@{push}`
ref is configured.
`HEAD`::
`*` if `HEAD` matches current ref (the checked out branch), ' '
otherwise.
`color`::
Change output color. Followed by `:<colorname>`, where color
names are described under Values in the "CONFIGURATION FILE"
section of linkgit:git-config[1]. For example,
`%(color:bold red)`.
`align`::
Left-, middle-, or right-align the content between
`%(align:...)` and `%(end)`. The "`align:`" is followed by
`width=<width>` and `position=<position>` in any order
separated by a comma, where the _<position>_ is either `left`,
`right` or `middle`, default being `left` and _<width>_ is the total
length of the content with alignment. For brevity, the
"width=" and/or "position=" prefixes may be omitted, and bare
_<width>_ and _<position>_ used instead. For instance,
`%(align:<width>,<position>)`. If the contents length is more
than the width then no alignment is performed. If used with
`--quote` everything in between `%(align:...)` and `%(end)` is
quoted, but if nested then only the topmost level performs
quoting.
`if`::
Used as `%(if)...%(then)...%(end)` or
`%(if)...%(then)...%(else)...%(end)`. If there is an atom with
value or string literal after the `%(if)` then everything after
the `%(then)` is printed, else if the `%(else)` atom is used, then
everything after %(else) is printed. We ignore space when
evaluating the string before `%(then)`, this is useful when we
use the `%(HEAD)` atom which prints either "`*`" or " " and we
want to apply the 'if' condition only on the `HEAD` ref.
Append "`:equals=<string>`" or "`:notequals=<string>`" to compare
the value between the `%(if:...)` and `%(then)` atoms with the
given string.
`symref`::
The ref which the given symbolic ref refers to. If not a
symbolic ref, nothing is printed. Respects the `:short`,
`:lstrip` and `:rstrip` options in the same way as `refname`
above.
`signature`::
The GPG signature of a commit.
`signature:grade`::
Show
`G`;; for a good (valid) signature
`B`;; for a bad signature
`U`;; for a good signature with unknown validity
`X`;; for a good signature that has expired
`Y`;; for a good signature made by an expired key
`R`;; for a good signature made by a revoked key
`E`;; if the signature cannot be checked (e.g. missing key)
`N`;; for no signature.
`signature:signer`::
The signer of the GPG signature of a commit.
`signature:key`::
The key of the GPG signature of a commit.
`signature:fingerprint`::
The fingerprint of the GPG signature of a commit.
`signature:primarykeyfingerprint`::
The primary key fingerprint of the GPG signature of a commit.
`signature:trustlevel`::
The trust level of the GPG signature of a commit. Possible
outputs are `ultimate`, `fully`, `marginal`, `never` and `undefined`.
`worktreepath`::
The absolute path to the worktree in which the ref is checked
out, if it is checked out in any linked worktree. Empty string
otherwise.
`ahead-behind:<commit-ish>`::
Two integers, separated by a space, demonstrating the number of
commits ahead and behind, respectively, when comparing the output
ref to the _<committish>_ specified in the format.
`is-base:<commit-ish>`::
In at most one row, `(<commit-ish>)` will appear to indicate the ref
that is most likely the ref used as a starting point for the branch
that produced _<commit-ish>_. This choice is made using a heuristic:
choose the ref that minimizes the number of commits in the
first-parent history of _<commit-ish>_ and not in the first-parent
history of the ref.
+
For example, consider the following figure of first-parent histories of
several refs:
+
----
*--*--*--*--*--* refs/heads/A
\
\
*--*--*--* refs/heads/B
\ \
\ \
* * refs/heads/C
\
\
*--* refs/heads/D
----
+
Here, if `A`, `B`, and `C` are the filtered references, and the format
string is `%(refname):%(is-base:D)`, then the output would be
+
----
refs/heads/A:
refs/heads/B:(D)
refs/heads/C:
----
+
This is because the first-parent history of `D` has its earliest
intersection with the first-parent histories of the filtered refs at a
common first-parent ancestor of `B` and `C` and ties are broken by the
earliest ref in the sorted order.
+
Note that this token will not appear if the first-parent history of
_<commit-ish>_ does not intersect the first-parent histories of the
filtered refs.
`describe[:<option>,...]`::
A human-readable name, like linkgit:git-describe[1];
empty string for undescribable commits. The `describe` string may
be followed by a colon and one or more comma-separated options.
+
--
`tags=<bool-value>`;;
Instead of only considering annotated tags, consider
lightweight tags as well; see the corresponding option in
linkgit:git-describe[1] for details.
`abbrev=<number>`;;
Use at least _<number>_ hexadecimal digits; see the corresponding
option in linkgit:git-describe[1] for details.
`match=<pattern>`;;
Only consider tags matching the `glob`(7) _<pattern>_,
excluding the `refs/tags/` prefix; see the corresponding option
in linkgit:git-describe[1] for details.
`exclude=<pattern>`;;
Do not consider tags matching the `glob`(7) _<pattern>_,
excluding the `refs/tags/` prefix; see the corresponding option
in linkgit:git-describe[1] for details.
--
In addition to the above, for commit and tag objects, the header
field names (`tree`, `parent`, `object`, `type`, and `tag`) can
be used to specify the value in the header field.
Fields `tree` and `parent` can also be used with modifier `:short` and
`:short=<length>` just like `objectname`.
For commit and tag objects, the special `creatordate` and `creator`
fields will correspond to the appropriate date or name-email-date tuple
from the `committer` or `tagger` fields depending on the object type.
These are intended for working on a mix of annotated and lightweight tags.
For tag objects, a `fieldname` prefixed with an asterisk (`*`) expands to
the `fieldname` value of the peeled object, rather than that of the tag
object itself.
Fields that have name-email-date tuple as its value (`author`,
`committer`, and `tagger`) can be suffixed with `name`, `email`,
and `date` to extract the named component. For email fields (`authoremail`,
`committeremail` and `taggeremail`), `:trim` can be appended to get the email
without angle brackets, and `:localpart` to get the part before the `@` symbol
out of the trimmed email. In addition to these, the `:mailmap` option and the
corresponding `:mailmap,trim` and `:mailmap,localpart` can be used (order does
not matter) to get values of the name and email according to the .mailmap file
or according to the file set in the mailmap.file or mailmap.blob configuration
variable (see linkgit:gitmailmap[5]).
The raw data in an object is `raw`.
`raw:size`::
The raw data size of the object.
Note that `--format=%(raw)` can not be used with `--python`, `--shell`, `--tcl`,
because such language may not support arbitrary binary data in their string
variable type.
The message in a commit or a tag object is `contents`, from which
`contents:<part>` can be used to extract various parts out of:
`contents:size`::
The size in bytes of the commit or tag message.
`contents:subject`::
The first paragraph of the message, which typically is a
single line, is taken as the "subject" of the commit or the
tag message.
Instead of `contents:subject`, field `subject` can also be used to
obtain same results. `:sanitize` can be appended to `subject` for
subject line suitable for filename.
`contents:body`::
The remainder of the commit or the tag message that follows
the "subject".
`contents:signature`::
The optional GPG signature of the tag.
`contents:lines=<n>`::
The first _<n>_ lines of the message.
Additionally, the trailers as interpreted by linkgit:git-interpret-trailers[1]
are obtained as `trailers[:<option>,...]` (or by using the historical alias
`contents:trailers[:<option>,...]`). For valid _<option>_ values see `trailers`
section of linkgit:git-log[1].
For sorting purposes, fields with numeric values sort in numeric order
(`objectsize`, `authordate`, `committerdate`, `creatordate`, `taggerdate`).
All other fields are used to sort in their byte-value order.
There is also an option to sort by versions, this can be done by using
the fieldname `version:refname` or its alias `v:refname`.
In any case, a field name that refers to a field inapplicable to
the object referred by the ref does not cause an error. It
returns an empty string instead.
As a special case for the date-type fields, you may specify a format for the
date by adding `:` followed by date format name (see the values the `--date`
option to linkgit:git-rev-list[1] takes). If this formatting is provided in
a `--sort` key, references will be sorted according to the byte-value of the
formatted string rather than the numeric value of the underlying timestamp.
Some atoms like `%(align)` and `%(if)` always require a matching `%(end)`.
We call them "opening atoms" and sometimes denote them as `%($open)`.
When a scripting language specific quoting is in effect, everything
between a top-level opening atom and its matching %(end) is evaluated
according to the semantics of the opening atom and only its result
from the top-level is quoted.
EXAMPLES
--------
An example directly producing formatted text. Show the most recent
3 tagged commits:
------------
#!/bin/sh
git for-each-ref --count=3 --sort='-*authordate' \
`--format='From: %(*authorname) %(*authoremail)
Subject: %(*subject)
Date: %(*authordate)
Ref: %(*refname)
%(*body)
' 'refs/tags'
------------
A simple example showing the use of shell eval on the output,
demonstrating the use of `--shell`. List the prefixes of all heads:
------------
#!/bin/sh
git for-each-ref --shell --format="ref=%(refname)" refs/heads | \
while read entry
do
eval "$entry"
echo `dirname $ref`
done
------------
A bit more elaborate report on tags, demonstrating that the format
may be an entire script:
------------
#!/bin/sh
fmt='
r=%(refname)
t=%(*objecttype)
T=${r#refs/tags/}
o=%(*objectname)
n=%(*authorname)
e=%(*authoremail)
s=%(*subject)
d=%(*authordate)
b=%(*body)
kind=Tag
if test "z$t" = z
then
# could be a lightweight tag
t=%(objecttype)
kind="Lightweight tag"
o=%(objectname)
n=%(authorname)
e=%(authoremail)
s=%(subject)
d=%(authordate)
b=%(body)
fi
echo "$kind $T points at a $t object $o"
if test "z$t" = zcommit
then
echo "The commit was authored by $n $e
at $d, and titled
$s
Its message reads as:
"
echo "$b" | sed -e "s/^/ /"
echo
fi
'
eval=`git for-each-ref --shell --format="$fmt" \
--sort='*objecttype' \
--sort=-taggerdate \
refs/tags`
eval "$eval"
------------
An example to show the usage of `%(if)...%(then)...%(else)...%(end)`.
This prefixes the current branch with a star.
------------
git for-each-ref --format="%(if)%(HEAD)%(then)* %(else) %(end)%(refname:short)" refs/heads/
------------
An example to show the usage of `%(if)...%(then)...%(end)`.
This prints the authorname, if present.
------------
git for-each-ref --format="%(refname)%(if)%(authorname)%(then) Authored by: %(authorname)%(end)"
------------
CAVEATS
-------
Note that the sizes of objects on disk are reported accurately, but care
should be taken in drawing conclusions about which refs or objects are
responsible for disk usage. The size of a packed non-delta object may be
much larger than the size of objects which delta against it, but the
choice of which object is the base and which is the delta is arbitrary
and is subject to change during a repack.
Note also that multiple copies of an object may be present in the object
database; in this case, it is undefined which copy's size or delta base
will be reported.
NOTES
-----
include::ref-reachability-filters.adoc[]
SEE ALSO
--------
linkgit:git-show-ref[1]
GIT
---
Part of the linkgit:git[1] suite

68
app/src/main/assets/manpages/git-for-each-repo.txt Normal file
View File

@@ -0,0 +1,68 @@
git-for-each-repo(1)
====================
NAME
----
git-for-each-repo - Run a Git command on a list of repositories
SYNOPSIS
--------
[verse]
'git for-each-repo' --config=<config> [--] <arguments>
DESCRIPTION
-----------
Run a Git command on a list of repositories. The arguments after the
known options or `--` indicator are used as the arguments for the Git
subprocess.
THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
For example, we could run maintenance on each of a list of repositories
stored in a `maintenance.repo` config variable using
-------------
git for-each-repo --config=maintenance.repo maintenance run
-------------
This will run `git -C <repo> maintenance run` for each value `<repo>`
in the multi-valued config variable `maintenance.repo`.
OPTIONS
-------
--config=<config>::
Use the given config variable as a multi-valued list storing
absolute path names. Iterate on that list of paths to run
the given arguments.
+
These config values are loaded from system, global, and local Git config,
as available. If `git for-each-repo` is run in a directory that is not a
Git repository, then only the system and global config is used.
--keep-going::
Continue with the remaining repositories if the command failed
on a repository. The exit code will still indicate that the
overall operation was not successful.
+
Note that the exact exit code of the failing command is not passed
through as the exit code of the `for-each-repo` command: If the command
failed in any of the specified repositories, the overall exit code will
be 1.
SUBPROCESS BEHAVIOR
-------------------
If any `git -C <repo> <arguments>` subprocess returns a non-zero exit code,
then the `git for-each-repo` process returns that exit code without running
more subprocesses.
Each `git -C <repo> <arguments>` subprocess inherits the standard file
descriptors `stdin`, `stdout`, and `stderr`.
GIT
---
Part of the linkgit:git[1] suite

826
app/src/main/assets/manpages/git-format-patch.txt Normal file
View File

@@ -0,0 +1,826 @@
git-format-patch(1)
===================
NAME
----
git-format-patch - Prepare patches for e-mail submission
SYNOPSIS
--------
[verse]
'git format-patch' [-k] [(-o|--output-directory) <dir> | --stdout]
[--no-thread | --thread[=<style>]]
[(--attach|--inline)[=<boundary>] | --no-attach]
[-s | --signoff]
[--signature=<signature> | --no-signature]
[--signature-file=<file>]
[-n | --numbered | -N | --no-numbered]
[--start-number <n>] [--numbered-files]
[--in-reply-to=<message-id>] [--suffix=.<sfx>]
[--ignore-if-in-upstream] [--always]
[--cover-from-description=<mode>]
[--rfc[=<rfc>]] [--subject-prefix=<subject-prefix>]
[(--reroll-count|-v) <n>]
[--to=<email>] [--cc=<email>]
[--[no-]cover-letter] [--quiet]
[--commit-list-format=<format-spec>]
[--[no-]encode-email-headers]
[--no-notes | --notes[=<ref>]]
[--interdiff=<previous>]
[--range-diff=<previous> [--creation-factor=<percent>]]
[--filename-max-length=<n>]
[--progress]
[<common-diff-options>]
[ <since> | <revision-range> ]
DESCRIPTION
-----------
Prepare each non-merge commit with its "patch" in
one "message" per commit, formatted to resemble a UNIX mailbox.
The output of this command is convenient for e-mail submission or
for use with 'git am'.
A "message" generated by the command consists of three parts:
* A brief metadata header that begins with `From <commit>`
with a fixed `Mon Sep 17 00:00:00 2001` datestamp to help programs
like "file(1)" to recognize that the file is an output from this
command, fields that record the author identity, the author date,
and the title of the change (taken from the first paragraph of the
commit log message).
* The second and subsequent paragraphs of the commit log message.
* The "patch", which is the "diff -p --stat" output (see
linkgit:git-diff[1]) between the commit and its parent.
The log message and the patch are separated by a line with a
three-dash line.
There are two ways to specify which commits to operate on.
1. A single commit, <since>, specifies that the commits leading
to the tip of the current branch that are not in the history
that leads to the <since> to be output.
2. Generic <revision-range> expression (see "SPECIFYING
REVISIONS" section in linkgit:gitrevisions[7]) means the
commits in the specified range.
The first rule takes precedence in the case of a single <commit>. To
apply the second rule, i.e., format everything since the beginning of
history up until <commit>, use the `--root` option: `git format-patch
--root <commit>`. If you want to format only <commit> itself, you
can do this with `git format-patch -1 <commit>`.
By default, each output file is numbered sequentially from 1, and uses the
first line of the commit message (massaged for pathname safety) as
the filename. With the `--numbered-files` option, the output file names
will only be numbers, without the first line of the commit appended.
The names of the output files are printed to standard
output, unless the `--stdout` option is specified.
If `-o` is specified, output files are created in <dir>. Otherwise
they are created in the current working directory. The default path
can be set with the `format.outputDirectory` configuration option.
The `-o` option takes precedence over `format.outputDirectory`.
To store patches in the current working directory even when
`format.outputDirectory` points elsewhere, use `-o .`. All directory
components will be created.
By default, the subject of a single patch is "[PATCH] " followed by
the concatenation of lines from the commit message up to the first blank
line (see the DISCUSSION section of linkgit:git-commit[1]).
When multiple patches are output, the subject prefix will instead be
"[PATCH n/m] ". To force 1/1 to be added for a single patch, use `-n`.
To omit patch numbers from the subject, use `-N`.
If given `--thread`, `git-format-patch` will generate `In-Reply-To` and
`References` headers to make the second and subsequent patch mails appear
as replies to the first mail; this also generates a `Message-ID` header to
reference.
OPTIONS
-------
:git-format-patch: 1
include::diff-options.adoc[]
-<n>::
Prepare patches from the topmost <n> commits.
-o <dir>::
--output-directory <dir>::
Use <dir> to store the resulting files, instead of the
current working directory.
-n::
--numbered::
Name output in '[PATCH n/m]' format, even with a single patch.
-N::
--no-numbered::
Name output in '[PATCH]' format.
--start-number <n>::
Start numbering the patches at <n> instead of 1.
--numbered-files::
Output file names will be a simple number sequence
without the default first line of the commit appended.
-k::
--keep-subject::
Do not strip/add '[PATCH]' from the first line of the
commit log message.
-s::
--signoff::
Add a `Signed-off-by` trailer to the commit message, using
the committer identity of yourself.
See the signoff option in linkgit:git-commit[1] for more information.
--stdout::
Print all commits to the standard output in mbox format,
instead of creating a file for each one.
--attach[=<boundary>]::
Create multipart/mixed attachment, the first part of
which is the commit message and the patch itself in the
second part, with `Content-Disposition: attachment`.
--no-attach::
Disable the creation of an attachment, overriding the
configuration setting.
--inline[=<boundary>]::
Create multipart/mixed attachment, the first part of
which is the commit message and the patch itself in the
second part, with `Content-Disposition: inline`.
--thread[=<style>]::
--no-thread::
Controls addition of `In-Reply-To` and `References` headers to
make the second and subsequent mails appear as replies to the
first. Also controls generation of the `Message-ID` header to
reference.
+
The optional <style> argument can be either `shallow` or `deep`.
'shallow' threading makes every mail a reply to the head of the
series, where the head is chosen from the cover letter, the
`--in-reply-to`, and the first patch mail, in this order. 'deep'
threading makes every mail a reply to the previous one.
+
The default is `--no-thread`, unless the `format.thread` configuration
is set. `--thread` without an argument is equivalent to `--thread=shallow`.
+
Beware that the default for 'git send-email' is to thread emails
itself. If you want `git format-patch` to take care of threading, you
will want to ensure that threading is disabled for `git send-email`.
--in-reply-to=<message-id>::
Make the first mail (or all the mails with `--no-thread`) appear as a
reply to the given <message-id>, which avoids breaking threads to
provide a new patch series.
--ignore-if-in-upstream::
Do not include a patch that matches a commit in
<until>..<since>. This will examine all patches reachable
from <since> but not from <until> and compare them with the
patches being generated, and any patch that matches is
ignored.
--always::
Include patches for commits that do not introduce any change,
which are omitted by default.
--cover-from-description=<mode>::
Controls which parts of the cover letter will be automatically
populated using the branch's description.
+
If `<mode>` is `message` or `default`, the cover letter subject will be
populated with placeholder text. The body of the cover letter will be
populated with the branch's description. This is the default mode when
no configuration nor command line option is specified.
+
If `<mode>` is `subject`, the first paragraph of the branch description will
populate the cover letter subject. The remainder of the description will
populate the body of the cover letter.
+
If `<mode>` is `auto`, if the first paragraph of the branch description
is greater than 100 bytes, then the mode will be `message`, otherwise
`subject` will be used.
+
If `<mode>` is `none`, both the cover letter subject and body will be
populated with placeholder text.
--description-file=<file>::
Use the contents of <file> instead of the branch's description
for generating the cover letter.
--subject-prefix=<subject-prefix>::
Instead of the standard '[PATCH]' prefix in the subject
line, instead use '[<subject-prefix>]'. This can be used
to name a patch series, and can be combined with the
`--numbered` option.
+
The configuration variable `format.subjectPrefix` may also be used
to configure a subject prefix to apply to a given repository for
all patches. This is often useful on mailing lists which receive
patches for several repositories and can be used to disambiguate
the patches (with a value of e.g. "PATCH my-project").
--filename-max-length=<n>::
Instead of the standard 64 bytes, chomp the generated output
filenames at around '<n>' bytes (too short a value will be
silently raised to a reasonable length). Defaults to the
value of the `format.filenameMaxLength` configuration
variable, or 64 if unconfigured.
--rfc[=<rfc>]::
Prepends the string _<rfc>_ (defaults to "RFC") to
the subject prefix. As the subject prefix defaults to
"PATCH", you'll get "RFC PATCH" by default.
+
RFC means "Request For Comments"; use this when sending
an experimental patch for discussion rather than application.
"--rfc=WIP" may also be a useful way to indicate that a patch
is not complete yet ("WIP" stands for "Work In Progress").
+
If the convention of the receiving community for a particular extra
string is to have it _after_ the subject prefix, the string _<rfc>_
can be prefixed with a dash ("`-`") to signal that the rest of
the _<rfc>_ string should be appended to the subject prefix instead,
e.g., `--rfc='-(WIP)'` results in "PATCH (WIP)".
-v <n>::
--reroll-count=<n>::
Mark the series as the <n>-th iteration of the topic. The
output filenames have `v<n>` prepended to them, and the
subject prefix ("PATCH" by default, but configurable via the
`--subject-prefix` option) has ` v<n>` appended to it. E.g.
`--reroll-count=4` may produce `v4-0001-add-makefile.patch`
file that has "Subject: [PATCH v4 1/20] Add makefile" in it.
`<n>` does not have to be an integer (e.g. "--reroll-count=4.4",
or "--reroll-count=4rev2" are allowed), but the downside of
using such a reroll-count is that the range-diff/interdiff
with the previous version does not state exactly which
version the new iteration is compared against.
--to=<email>::
Add a `To:` header to the email headers. This is in addition
to any configured headers, and may be used multiple times.
The negated form `--no-to` discards all `To:` headers added so
far (from config or command line).
--cc=<email>::
Add a `Cc:` header to the email headers. This is in addition
to any configured headers, and may be used multiple times.
The negated form `--no-cc` discards all `Cc:` headers added so
far (from config or command line).
--from::
--from=<ident>::
Use `ident` in the `From:` header of each email. In case of a
commit email, if the author ident of the commit is not textually
identical to the provided `ident`, place a `From:` header in the
body of the message with the original author. If no `ident` is
given, or if the option is not passed at all, use the ident of
the current committer.
+
Note that this option is only useful if you are actually sending the
emails and want to identify yourself as the sender, but retain the
original author (and `git am` will correctly pick up the in-body
header). Note also that `git send-email` already handles this
transformation for you, and this option should not be used if you are
feeding the result to `git send-email`.
--force-in-body-from::
--no-force-in-body-from::
With the e-mail sender specified via the `--from` option, by
default, an in-body "From:" to identify the real author of
the commit is added at the top of the commit log message if
the sender is different from the author. With this option,
the in-body "From:" is added even when the sender and the
author have the same name and address, which may help if the
mailing list software mangles the sender's identity.
Defaults to the value of the `format.forceInBodyFrom`
configuration variable.
--add-header=<header>::
Add an arbitrary header to the email headers. This is in addition
to any configured headers, and may be used multiple times.
For example, `--add-header="Organization: git-foo"`.
The negated form `--no-add-header` discards *all* (`To:`,
`Cc:`, and custom) headers added so far from config or command
line.
--cover-letter::
--no-cover-letter::
In addition to the patches, generate a cover letter file containing the
branch description, commit list and the overall diffstat. You can fill
in a description in the file before sending it out.
--commit-list-format=<format-spec>::
Specify the format in which to generate the commit list of the patch
series. The accepted values for format-spec are `shortlog`, `modern` or
a format-string prefixed with `log:`. E.g. `log: %s (%an)`.
`modern` is the same as `log:%w(72)[%(count)/%(total)] %s`.
The `log:` prefix can be omitted if the format-string has a `%` in it
(expecting that it is part of `%<placeholder>`).
Defaults to the `format.commitListFormat` configuration variable, if
set, or `shortlog`.
This option given from the command-line implies the use of
`--cover-letter` unless `--no-cover-letter` is given.
--encode-email-headers::
--no-encode-email-headers::
Encode email headers that have non-ASCII characters with
"Q-encoding" (described in RFC 2047), instead of outputting the
headers verbatim. Defaults to the value of the
`format.encodeEmailHeaders` configuration variable.
--interdiff=<previous>::
As a reviewer aid, insert an interdiff into the cover letter,
or as commentary of the lone patch of a 1-patch series, showing
the differences between the previous version of the patch series and
the series currently being formatted. `previous` is a single revision
naming the tip of the previous series which shares a common base with
the series being formatted (for example `git format-patch
--cover-letter --interdiff=feature/v1 -3 feature/v2`).
--range-diff=<previous>::
As a reviewer aid, insert a range-diff (see linkgit:git-range-diff[1])
into the cover letter, or as commentary of the lone patch of a
1-patch series, showing the differences between the previous
version of the patch series and the series currently being formatted.
`previous` can be a single revision naming the tip of the previous
series if it shares a common base with the series being formatted (for
example `git format-patch --cover-letter --range-diff=feature/v1 -3
feature/v2`), or a revision range if the two versions of the series are
disjoint (for example `git format-patch --cover-letter
--range-diff=feature/v1~3..feature/v1 -3 feature/v2`).
+
Note that diff options passed to the command affect how the primary
product of `format-patch` is generated, and they are not passed to
the underlying `range-diff` machinery used to generate the cover-letter
material (this may change in the future).
--creation-factor=<percent>::
Used with `--range-diff`, tweak the heuristic which matches up commits
between the previous and current series of patches by adjusting the
creation/deletion cost fudge factor. See linkgit:git-range-diff[1])
for details.
+
Defaults to 999 (the linkgit:git-range-diff[1] uses 60), as the use
case is to show comparison with an older iteration of the same
topic and the tool should find more correspondence between the two
sets of patches.
--notes[=<ref>]::
--no-notes::
Append the notes (see linkgit:git-notes[1]) for the commit
after the three-dash line.
+
The expected use case of this is to write supporting explanation for
the commit that does not belong to the commit log message proper,
and include it with the patch submission. While one can simply write
these explanations after `format-patch` has run but before sending,
keeping them as Git notes allows them to be maintained between versions
of the patch series (but see the discussion of the `notes.rewrite`
configuration options in linkgit:git-notes[1] to use this workflow).
+
The default is `--no-notes`, unless the `format.notes` configuration is
set.
--signature=<signature>::
--no-signature::
Add a signature to each message produced. Per RFC 3676 the signature
is separated from the body by a line with '-- ' on it. If the
signature option is omitted the signature defaults to the Git version
number.
--signature-file=<file>::
Works just like --signature except the signature is read from a file.
--suffix=.<sfx>::
Instead of using `.patch` as the suffix for generated
filenames, use specified suffix. A common alternative is
`--suffix=.txt`. Leaving this empty will remove the `.patch`
suffix.
+
Note that the leading character does not have to be a dot; for example,
you can use `--suffix=-patch` to get `0001-description-of-my-change-patch`.
-q::
--quiet::
Do not print the names of the generated files to standard output.
--no-binary::
Do not output contents of changes in binary files, instead
display a notice that those files changed. Patches generated
using this option cannot be applied properly, but they are
still useful for code review.
--zero-commit::
Output an all-zero hash in each patch's From header instead
of the hash of the commit.
--no-base::
--base[=<commit>]::
Record the base tree information to identify the state the
patch series applies to. See the BASE TREE INFORMATION section
below for details. If <commit> is "auto", a base commit is
automatically chosen. The `--no-base` option overrides a
`format.useAutoBase` configuration.
--root::
Treat the revision argument as a <revision-range>, even if it
is just a single commit (that would normally be treated as a
<since>). Note that root commits included in the specified
range are always formatted as creation patches, independently
of this flag.
--progress::
Show progress reports on stderr as patches are generated.
CONFIGURATION
-------------
You can specify extra mail header lines to be added to each message,
defaults for the subject prefix and file suffix, number patches when
outputting more than one patch, add "To:" or "Cc:" headers, configure
attachments, change the patch output directory, and sign off patches
with configuration variables.
------------
[format]
headers = "Organization: git-foo\n"
subjectPrefix = CHANGE
suffix = .txt
numbered = auto
to = <email>
cc = <email>
attach [ = mime-boundary-string ]
signOff = true
outputDirectory = <directory>
coverLetter = auto
commitListFormat = shortlog
coverFromDescription = auto
------------
DISCUSSION
----------
The patch produced by 'git format-patch' is in UNIX mailbox format,
with a fixed "magic" time stamp to indicate that the file is output
from format-patch rather than a real mailbox, like so:
------------
From 8f72bad1baf19a53459661343e21d6491c3908d3 Mon Sep 17 00:00:00 2001
From: Tony Luck <tony.luck@intel.com>
Date: Tue, 13 Jul 2010 11:42:54 -0700
Subject: [PATCH] =?UTF-8?q?[IA64]=20Put=20ia64=20config=20files=20on=20the=20?=
=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20diet?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
arch/arm config files were slimmed down using a python script
(See commit c2330e286f68f1c408b4aa6515ba49d57f05beae comment)
Do the same for ia64 so we can have sleek & trim looking
...
------------
Typically it will be placed in a MUA's drafts folder, edited to add
timely commentary that should not go in the changelog after the three
dashes, and then sent as a message whose body, in our example, starts
with "arch/arm config files were...". On the receiving end, readers
can save interesting patches in a UNIX mailbox and apply them with
linkgit:git-am[1].
When a patch is part of an ongoing discussion, the patch generated by
'git format-patch' can be tweaked to take advantage of the 'git am
--scissors' feature. After your response to the discussion comes a
line that consists solely of "`-- >8 --`" (scissors and perforation),
followed by the patch with unnecessary header fields removed:
------------
...
> So we should do such-and-such.
Makes sense to me. How about this patch?
-- >8 --
Subject: [IA64] Put ia64 config files on the Uwe Kleine-König diet
arch/arm config files were slimmed down using a python script
...
------------
When sending a patch this way, most often you are sending your own
patch, so in addition to the "`From $SHA1 $magic_timestamp`" marker you
should omit `From:` and `Date:` lines from the patch file. The patch
title is likely to be different from the subject of the discussion the
patch is in response to, so it is likely that you would want to keep
the Subject: line, like the example above.
Checking for patch corruption
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Many mailers if not set up properly will corrupt whitespace. Here are
two common types of corruption:
* Empty context lines that do not have _any_ whitespace.
* Non-empty context lines that have one extra whitespace at the
beginning.
One way to test if your MUA is set up correctly is:
* Send the patch to yourself, exactly the way you would, except
with To: and Cc: lines that do not contain the list and
maintainer address.
* Save that patch to a file in UNIX mailbox format. Call it a.patch,
say.
* Apply it:
$ git fetch <project> master:test-apply
$ git switch test-apply
$ git restore --source=HEAD --staged --worktree :/
$ git am a.patch
If it does not apply correctly, there can be various reasons.
* The patch itself does not apply cleanly. That is _bad_ but
does not have much to do with your MUA. You might want to rebase
the patch with linkgit:git-rebase[1] before regenerating it in
this case.
* The MUA corrupted your patch; "am" would complain that
the patch does not apply. Look in the .git/rebase-apply/ subdirectory and
see what 'patch' file contains and check for the common
corruption patterns mentioned above.
* While at it, check the 'info' and 'final-commit' files as well.
If what is in 'final-commit' is not exactly what you would want to
see in the commit log message, it is very likely that the
receiver would end up hand editing the log message when applying
your patch. Things like "Hi, this is my first patch.\n" in the
patch e-mail should come after the three-dash line that signals
the end of the commit message.
MUA-SPECIFIC HINTS
------------------
Here are some hints on how to successfully submit patches inline using
various mailers.
GMail
~~~~~
GMail does not have any way to turn off line wrapping in the web
interface, so it will mangle any emails that you send. You can however
use "git send-email" and send your patches through the GMail SMTP server, or
use any IMAP email client to connect to the google IMAP server and forward
the emails through that.
For hints on using 'git send-email' to send your patches through the
GMail SMTP server, see the EXAMPLE section of linkgit:git-send-email[1].
For hints on submission using the IMAP interface, see the EXAMPLE
section of linkgit:git-imap-send[1].
Thunderbird
~~~~~~~~~~~
By default, Thunderbird will both wrap emails as well as flag
them as being 'format=flowed', both of which will make the
resulting email unusable by Git.
There are three different approaches: use an add-on to turn off line wraps,
configure Thunderbird to not mangle patches, or use
an external editor to keep Thunderbird from mangling the patches.
Approach #1 (add-on)
^^^^^^^^^^^^^^^^^^^^
Install the Toggle Line Wrap add-on that is available from
https://addons.thunderbird.net/thunderbird/addon/toggle-line-wrap
It adds a button "Line Wrap" to the composer's toolbar
that you can tick off. Now you can compose the message as you otherwise do
(cut + paste, 'git format-patch' | 'git imap-send', etc), but you have to
insert line breaks manually in any text that you type.
As a bonus feature, the add-on can detect patch text in the composer
and warns when line wrapping has not yet been turned off.
The add-on requires a few tweaks of the advanced configuration
(about:config). These are listed on the download page.
Approach #2 (configuration)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Three steps:
1. Configure your mail server composition as plain text:
Edit...Account Settings...Composition & Addressing,
uncheck "Compose Messages in HTML".
2. Configure your general composition window to not wrap.
+
In Thunderbird 2:
Edit..Preferences..Composition, wrap plain text messages at 0
+
In Thunderbird 3:
Edit..Preferences..Advanced..Config Editor. Search for
"mail.wrap_long_lines".
Toggle it to make sure it is set to `false`. Also, search for
"mailnews.wraplength" and set the value to 0.
3. Disable the use of format=flowed:
Edit..Preferences..Advanced..Config Editor. Search for
"mailnews.send_plaintext_flowed".
Toggle it to make sure it is set to `false`.
After that is done, you should be able to compose email as you
otherwise would (cut + paste, 'git format-patch' | 'git imap-send', etc),
and the patches will not be mangled.
Approach #3 (external editor)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The following Thunderbird extensions are needed:
AboutConfig from https://mjg.github.io/AboutConfig/ and
External Editor from https://globs.org/articles.php?lng=en&pg=8
1. Prepare the patch as a text file using your method of choice.
2. Before opening a compose window, use Edit->Account Settings to
uncheck the "Compose messages in HTML format" setting in the
"Composition & Addressing" panel of the account to be used to
send the patch.
3. In the main Thunderbird window, 'before' you open the compose
window for the patch, use Tools->about:config to set the
following to the indicated values:
+
----------
mailnews.send_plaintext_flowed => false
mailnews.wraplength => 0
----------
4. Open a compose window and click the external editor icon.
5. In the external editor window, read in the patch file and exit
the editor normally.
Side note: it may be possible to do step 2 with
about:config and the following settings but no one's tried yet.
----------
mail.html_compose => false
mail.identity.default.compose_html => false
mail.identity.id?.compose_html => false
----------
There is a script in contrib/thunderbird-patch-inline which can help
you include patches with Thunderbird in an easy way. To use it, do the
steps above and then use the script as the external editor.
KMail
~~~~~
This should help you to submit patches inline using KMail.
1. Prepare the patch as a text file.
2. Click on New Mail.
3. Go under "Options" in the Composer window and be sure that
"Word wrap" is not set.
4. Use Message -> Insert file... and insert the patch.
5. Back in the compose window: add whatever other text you wish to the
message, complete the addressing and subject fields, and press send.
BASE TREE INFORMATION
---------------------
The base tree information block is used for maintainers or third party
testers to know the exact state the patch series applies to. It consists
of the 'base commit', which is a well-known commit that is part of the
stable part of the project history everybody else works off of, and zero
or more 'prerequisite patches', which are well-known patches in flight
that is not yet part of the 'base commit' that need to be applied on top
of 'base commit' in topological order before the patches can be applied.
The 'base commit' is shown as "base-commit: " followed by the 40-hex of
the commit object name. A 'prerequisite patch' is shown as
"prerequisite-patch-id: " followed by the 40-hex 'patch id', which can
be obtained by passing the patch through the `git patch-id --stable`
command.
Imagine that on top of the public commit P, you applied well-known
patches X, Y and Z from somebody else, and then built your three-patch
series A, B, C, the history would be like:
................................................
---P---X---Y---Z---A---B---C
................................................
With `git format-patch --base=P -3 C` (or variants thereof, e.g. with
`--cover-letter` or using `Z..C` instead of `-3 C` to specify the
range), the base tree information block is shown at the end of the
first message the command outputs (either the first patch, or the
cover letter), like this:
------------
base-commit: P
prerequisite-patch-id: X
prerequisite-patch-id: Y
prerequisite-patch-id: Z
------------
For non-linear topology, such as
................................................
---P---X---A---M---C
\ /
Y---Z---B
................................................
You can also use `git format-patch --base=P -3 C` to generate patches
for A, B and C, and the identifiers for P, X, Y, Z are appended at the
end of the first message.
If set `--base=auto` in cmdline, it will automatically compute
the base commit as the merge base of tip commit of the remote-tracking
branch and revision-range specified in cmdline.
For a local branch, you need to make it to track a remote branch by `git branch
--set-upstream-to` before using this option.
EXAMPLES
--------
* Extract commits between revisions R1 and R2, and apply them on top of
the current branch using 'git am' to cherry-pick them:
+
------------
$ git format-patch -k --stdout R1..R2 | git am -3 -k
------------
* Extract all commits which are in the current branch but not in the
origin branch:
+
------------
$ git format-patch origin
------------
+
For each commit a separate file is created in the current directory.
* Extract all commits that lead to 'origin' since the inception of the
project:
+
------------
$ git format-patch --root origin
------------
* The same as the previous one:
+
------------
$ git format-patch -M -B origin
------------
+
Additionally, it detects and handles renames and complete rewrites
intelligently to produce a renaming patch. A renaming patch reduces
the amount of text output, and generally makes it easier to review.
Note that non-Git "patch" programs won't understand renaming patches, so
use it only when you know the recipient uses Git to apply your patch.
* Extract three topmost commits from the current branch and format them
as e-mailable patches:
+
------------
$ git format-patch -3
------------
CAVEATS
-------
Note that `format-patch` will omit merge commits from the output, even
if they are part of the requested range. A simple "patch" does not
include enough information for the receiving end to reproduce the same
merge commit.
=== PATCH APPLICATION
include::format-patch-caveats.adoc[]
SEE ALSO
--------
linkgit:git-am[1], linkgit:git-send-email[1]
GIT
---
Part of the linkgit:git[1] suite

22
app/src/main/assets/manpages/git-fsck-objects.txt Normal file
View File

@@ -0,0 +1,22 @@
git-fsck-objects(1)
===================
NAME
----
git-fsck-objects - Verifies the connectivity and validity of the objects in the database
SYNOPSIS
--------
[verse]
'git fsck-objects' ...
DESCRIPTION
-----------
This is a synonym for linkgit:git-fsck[1]. Please refer to the
documentation of that command.
GIT
---
Part of the linkgit:git[1] suite

189
app/src/main/assets/manpages/git-fsck.txt Normal file
View File

@@ -0,0 +1,189 @@
git-fsck(1)
===========
NAME
----
git-fsck - Verifies the connectivity and validity of the objects in the database
SYNOPSIS
--------
[verse]
'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
[--[no-]full] [--strict] [--verbose] [--lost-found]
[--[no-]dangling] [--[no-]progress] [--connectivity-only]
[--[no-]name-objects] [--[no-]references] [<object>...]
DESCRIPTION
-----------
Verifies the connectivity and validity of the objects in the database.
OPTIONS
-------
<object>::
An object to treat as the head of an unreachability trace.
+
If no objects are given, 'git fsck' defaults to using the
index file, all SHA-1 references in the `refs` namespace, and all reflogs
(unless --no-reflogs is given) as heads.
--unreachable::
Print out objects that exist but that aren't reachable from any
of the reference nodes.
--dangling::
--no-dangling::
Print objects that exist but that are never 'directly' used (default).
`--no-dangling` can be used to omit this information from the output.
--root::
Report root nodes.
--tags::
Report tags.
--cache::
Consider any object recorded in the index also as a head node for
an unreachability trace.
--no-reflogs::
Do not consider commits that are referenced only by an
entry in a reflog to be reachable. This option is meant
only to search for commits that used to be in a ref, but
now aren't, but are still in that corresponding reflog.
--full::
Check not just objects in GIT_OBJECT_DIRECTORY
($GIT_DIR/objects), but also the ones found in alternate
object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES
or $GIT_DIR/objects/info/alternates,
and in packed Git archives found in $GIT_DIR/objects/pack
and corresponding pack subdirectories in alternate
object pools. This is now default; you can turn it off
with --no-full.
--connectivity-only::
Check only the connectivity of reachable objects, making sure
that any objects referenced by a reachable tag, commit, or tree
are present. This speeds up the operation by avoiding reading
blobs entirely (though it does still check that referenced blobs
exist). This will detect corruption in commits and trees, but
not do any semantic checks (e.g., for format errors). Corruption
in blob objects will not be detected at all.
+
Unreachable tags, commits, and trees will also be accessed to find the
tips of dangling segments of history. Use `--no-dangling` if you don't
care about this output and want to speed it up further.
--strict::
Enable more strict checking, namely to catch a file mode
recorded with g+w bit set, which was created by older
versions of Git. Existing repositories, including the
Linux kernel, Git itself, and sparse repository have old
objects that trigger this check, but it is recommended
to check new projects with this flag.
--verbose::
Be chatty.
--lost-found::
Write dangling objects into .git/lost-found/commit/ or
.git/lost-found/other/, depending on type. If the object is
a blob, the contents are written into the file, rather than
its object name.
--name-objects::
When displaying names of reachable objects, in addition to the
SHA-1 also display a name that describes *how* they are reachable,
compatible with linkgit:git-rev-parse[1], e.g.
`HEAD@{1234567890}~25^2:src/`.
--progress::
--no-progress::
Progress status is reported on the standard error stream by
default when it is attached to a terminal, unless
--no-progress or --verbose is specified. --progress forces
progress status even if the standard error stream is not
directed to a terminal.
--references::
--no-references::
Control whether to check the references database consistency
via 'git refs verify'. See linkgit:git-refs[1] for details.
The default is to check the references database.
CONFIGURATION
-------------
include::includes/cmd-config-section-all.adoc[]
include::config/fsck.adoc[]
DISCUSSION
----------
git-fsck tests SHA-1 and general object sanity, and it does full tracking
of the resulting reachability and everything else. It prints out any
corruption it finds (missing or bad objects), and if you use the
`--unreachable` flag it will also print out objects that exist but that
aren't reachable from any of the specified head nodes (or the default
set, as mentioned above).
Any corrupt objects you will have to find in backups or other archives
(i.e., you can just remove them and do an 'rsync' with some other site in
the hopes that somebody else has the object you have corrupted).
If core.commitGraph is true, the commit-graph file will also be inspected
using 'git commit-graph verify'. See linkgit:git-commit-graph[1].
Extracted Diagnostics
---------------------
unreachable <type> <object>::
The <type> object <object>, isn't actually referred to directly
or indirectly in any of the trees or commits seen. This can
mean that there's another root node that you're not specifying
or that the tree is corrupt. If you haven't missed a root node
then you might as well delete unreachable nodes since they
can't be used.
missing <type> <object>::
The <type> object <object>, is referred to but isn't present in
the database.
dangling <type> <object>::
The <type> object <object>, is present in the database but never
'directly' used. A dangling commit could be a root node.
hash mismatch <object>::
The database has an object whose hash doesn't match the
object database value.
This indicates a serious data integrity problem.
FSCK MESSAGES
-------------
The following lists the types of errors `git fsck` detects and what
each error means, with their default severity. The severity of the
error, other than those that are marked as "(FATAL)", can be tweaked
by setting the corresponding `fsck.<msg-id>` configuration variable.
include::fsck-msgids.adoc[]
Environment Variables
---------------------
GIT_OBJECT_DIRECTORY::
used to specify the object database root (usually $GIT_DIR/objects)
GIT_INDEX_FILE::
used to specify the index file of the index
GIT_ALTERNATE_OBJECT_DIRECTORIES::
used to specify additional object database roots (usually unset)
GIT
---
Part of the linkgit:git[1] suite

106
app/src/main/assets/manpages/git-fsmonitor--daemon.txt Normal file
View File

@@ -0,0 +1,106 @@
git-fsmonitor{litdd}daemon(1)
=============================
NAME
----
git-fsmonitor--daemon - A Built-in Filesystem Monitor
SYNOPSIS
--------
[verse]
'git fsmonitor{litdd}daemon' start
'git fsmonitor{litdd}daemon' run
'git fsmonitor{litdd}daemon' stop
'git fsmonitor{litdd}daemon' status
DESCRIPTION
-----------
A daemon to watch the working directory for file and directory
changes using platform-specific filesystem notification facilities.
This daemon communicates directly with commands like `git status`
using the link:technical/api-simple-ipc.html[simple IPC] interface
instead of the slower linkgit:githooks[5] interface.
This daemon is built into Git so that no third-party tools are
required.
OPTIONS
-------
start::
Starts a daemon in the background.
run::
Runs a daemon in the foreground.
stop::
Stops the daemon running in the current working
directory, if present.
status::
Exits with zero status if a daemon is watching the
current working directory.
REMARKS
-------
This daemon is a long running process used to watch a single working
directory and maintain a list of the recently changed files and
directories. Performance of commands such as `git status` can be
increased if they just ask for a summary of changes to the working
directory and can avoid scanning the disk.
When `core.fsmonitor` is set to `true` (see linkgit:git-config[1])
commands, such as `git status`, will ask the daemon for changes and
automatically start it (if necessary).
For more information see the "File System Monitor" section in
linkgit:git-update-index[1].
CAVEATS
-------
The fsmonitor daemon does not currently know about submodules and does
not know to filter out filesystem events that happen within a
submodule. If fsmonitor daemon is watching a super repo and a file is
modified within the working directory of a submodule, it will report
the change (as happening against the super repo). However, the client
will properly ignore these extra events, so performance may be affected
but it will not cause an incorrect result.
By default, the fsmonitor daemon refuses to work with network-mounted
repositories; this may be overridden by setting `fsmonitor.allowRemote` to
`true`. Note, however, that the fsmonitor daemon is not guaranteed to work
correctly with all network-mounted repositories, so such use is considered
experimental.
On Mac OS, the inter-process communication (IPC) between various Git
commands and the fsmonitor daemon is done via a Unix domain socket (UDS) -- a
special type of file -- which is supported by native Mac OS filesystems,
but not on network-mounted filesystems, NTFS, or FAT32. Other filesystems
may or may not have the needed support; the fsmonitor daemon is not guaranteed
to work with these filesystems and such use is considered experimental.
By default, the socket is created in the `.git` directory. However, if the
`.git` directory is on a network-mounted filesystem, it will instead be
created at `$HOME/.git-fsmonitor-*` unless `$HOME` itself is on a
network-mounted filesystem, in which case you must set the configuration
variable `fsmonitor.socketDir` to the path of a directory on a Mac OS native
filesystem in which to create the socket file.
If none of the above directories (`.git`, `$HOME`, or `fsmonitor.socketDir`)
is on a native Mac OS file filesystem the fsmonitor daemon will report an
error that will cause the daemon and the currently running command to exit.
CONFIGURATION
-------------
include::includes/cmd-config-section-all.adoc[]
include::config/fsmonitor--daemon.adoc[]
GIT
---
Part of the linkgit:git[1] suite

187
app/src/main/assets/manpages/git-gc.txt Normal file
View File

@@ -0,0 +1,187 @@
git-gc(1)
=========
NAME
----
git-gc - Cleanup unnecessary files and optimize the local repository
SYNOPSIS
--------
[verse]
'git gc' [--aggressive] [--auto] [--[no-]detach] [--quiet] [--prune=<date> | --no-prune] [--force] [--keep-largest-pack]
DESCRIPTION
-----------
Runs a number of housekeeping tasks within the current repository,
such as compressing file revisions (to reduce disk space and increase
performance), removing unreachable objects which may have been
created from prior invocations of 'git add', packing refs, pruning
reflog, rerere metadata or stale working trees. May also update ancillary
indexes such as the commit-graph.
When common porcelain operations that create objects are run, they
will check whether the repository has grown substantially since the
last maintenance, and if so run `git gc` automatically. See `gc.auto`
below for how to disable this behavior.
Running `git gc` manually should only be needed when adding objects to
a repository without regularly running such porcelain commands, to do
a one-off repository optimization, or e.g. to clean up a suboptimal
mass-import. See the "PACKFILE OPTIMIZATION" section in
linkgit:git-fast-import[1] for more details on the import case.
OPTIONS
-------
--aggressive::
Usually 'git gc' runs very quickly while providing good disk
space utilization and performance. This option will cause
'git gc' to more aggressively optimize the repository at the expense
of taking much more time. The effects of this optimization are
mostly persistent. See the "AGGRESSIVE" section below for details.
--auto::
With this option, 'git gc' checks whether any housekeeping is
required; if not, it exits without performing any work.
+
See the `gc.auto` option in the "CONFIGURATION" section below for how
this heuristic works.
+
Once housekeeping is triggered by exceeding the limits of
configuration options such as `gc.auto` and `gc.autoPackLimit`, all
other housekeeping tasks (e.g. rerere, working trees, reflog...) will
be performed as well.
--detach::
--no-detach::
Run in the background if the system supports it. This option overrides
the `gc.autoDetach` config.
--cruft::
--no-cruft::
When expiring unreachable objects, pack them separately into a
cruft pack instead of storing them as loose objects. `--cruft`
is on by default.
--max-cruft-size=<n>::
When packing unreachable objects into a cruft pack, limit the
size of new cruft packs to be at most `<n>` bytes. Overrides any
value specified via the `gc.maxCruftSize` configuration. See
the `--max-cruft-size` option of linkgit:git-repack[1] for
more.
--expire-to=<dir>::
When packing unreachable objects into a cruft pack, write a cruft
pack containing pruned objects (if any) to the directory `<dir>`.
This option only has an effect when used together with `--cruft`.
See the `--expire-to` option of linkgit:git-repack[1] for
more information.
--prune=<date>::
Prune loose objects older than date (default is 2 weeks ago,
overridable by the config variable `gc.pruneExpire`).
--prune=now prunes loose objects regardless of their age and
increases the risk of corruption if another process is writing to
the repository concurrently; see "NOTES" below. --prune is on by
default.
--no-prune::
Do not prune any loose objects.
--quiet::
Suppress all progress reports.
--force::
Force `git gc` to run even if there may be another `git gc`
instance running on this repository.
--keep-largest-pack::
All packs except the largest non-cruft pack, any packs marked
with a `.keep` file, and any cruft pack(s) are consolidated into
a single pack. When this option is used, `gc.bigPackThreshold`
is ignored.
AGGRESSIVE
----------
When the `--aggressive` option is supplied, linkgit:git-repack[1] will
be invoked with the `-f` flag, which in turn will pass
`--no-reuse-delta` to linkgit:git-pack-objects[1]. This will throw
away any existing deltas and re-compute them, at the expense of
spending much more time on the repacking.
The effects of this are mostly persistent, e.g. when packs and loose
objects are coalesced into one another pack the existing deltas in
that pack might get re-used, but there are also various cases where we
might pick a sub-optimal delta from a newer pack instead.
Furthermore, supplying `--aggressive` will tweak the `--depth` and
`--window` options passed to linkgit:git-repack[1]. See the
`gc.aggressiveDepth` and `gc.aggressiveWindow` settings below. By
using a larger window size we're more likely to find more optimal
deltas.
It's probably not worth it to use this option on a given repository
without running tailored performance benchmarks on it. It takes a lot
more time, and the resulting space/delta optimization may or may not
be worth it. Not using this at all is the right trade-off for most
users and their repositories.
CONFIGURATION
-------------
include::includes/cmd-config-section-all.adoc[]
include::config/gc.adoc[]
NOTES
-----
'git gc' tries very hard not to delete objects that are referenced
anywhere in your repository. In particular, it will keep not only
objects referenced by your current set of branches and tags, but also
objects referenced by the index, remote-tracking branches, reflogs
(which may reference commits in branches that were later amended or
rewound), and anything else in the refs/* namespace. Note that a note
(of the kind created by 'git notes') attached to an object does not
contribute in keeping the object alive. If you are expecting some
objects to be deleted and they aren't, check all of those locations
and decide whether it makes sense in your case to remove those
references.
On the other hand, when 'git gc' runs concurrently with another process,
there is a risk of it deleting an object that the other process is using
but hasn't created a reference to. This may just cause the other process
to fail or may corrupt the repository if the other process later adds a
reference to the deleted object. Git has two features that significantly
mitigate this problem:
. Any object with modification time newer than the `--prune` date is kept,
along with everything reachable from it.
. Most operations that add an object to the database update the
modification time of the object if it is already present so that #1
applies.
However, these features fall short of a complete solution, so users who
run commands concurrently have to live with some risk of corruption (which
seems to be low in practice).
HOOKS
-----
The 'git gc --auto' command will run the 'pre-auto-gc' hook. See
linkgit:githooks[5] for more information.
SEE ALSO
--------
linkgit:git-prune[1]
linkgit:git-reflog[1]
linkgit:git-repack[1]
linkgit:git-rerere[1]
GIT
---
Part of the linkgit:git[1] suite

30
app/src/main/assets/manpages/git-get-tar-commit-id.txt Normal file
View File

@@ -0,0 +1,30 @@
git-get-tar-commit-id(1)
========================
NAME
----
git-get-tar-commit-id - Extract commit ID from an archive created using git-archive
SYNOPSIS
--------
[verse]
'git get-tar-commit-id'
DESCRIPTION
-----------
Read a tar archive created by 'git archive' from the standard input
and extract the commit ID stored in it. It reads only the first
1024 bytes of input, thus its runtime is not influenced by the size
of the tar archive very much.
If no commit ID is found, 'git get-tar-commit-id' quietly exits with a
return code of 1. This can happen if the archive had not been created
using 'git archive' or if the first parameter of 'git archive' had been
a tree ID instead of a commit ID or tag.
GIT
---
Part of the linkgit:git[1] suite

360
app/src/main/assets/manpages/git-grep.txt Normal file
View File

@@ -0,0 +1,360 @@
git-grep(1)
===========
NAME
----
git-grep - Print lines matching a pattern
SYNOPSIS
--------
[verse]
'git grep' [-a | --text] [-I] [--textconv] [-i | --ignore-case] [-w | --word-regexp]
[-v | --invert-match] [-h|-H] [--full-name]
[-E | --extended-regexp] [-G | --basic-regexp]
[-P | --perl-regexp]
[-F | --fixed-strings] [-n | --line-number] [--column]
[-l | --files-with-matches] [-L | --files-without-match]
[(-O | --open-files-in-pager) [<pager>]]
[-z | --null]
[ -o | --only-matching ] [-c | --count] [--all-match] [-q | --quiet]
[--max-depth <depth>] [--[no-]recursive]
[--color[=<when>] | --no-color]
[--break] [--heading] [-p | --show-function]
[-A <post-context>] [-B <pre-context>] [-C <context>]
[-W | --function-context]
[(-m | --max-count) <num>]
[--threads <num>]
[-f <file>] [-e] <pattern>
[--and|--or|--not|(|)|-e <pattern>...]
[--recurse-submodules] [--parent-basename <basename>]
[ [--[no-]exclude-standard] [--cached | --untracked | --no-index] | <tree>...]
[--] [<pathspec>...]
DESCRIPTION
-----------
Look for specified patterns in the tracked files in the work tree, blobs
registered in the index file, or blobs in given tree objects. Patterns
are lists of one or more search expressions separated by newline
characters. An empty string as search expression matches all lines.
OPTIONS
-------
--cached::
Instead of searching tracked files in the working tree, search
blobs registered in the index file.
--untracked::
In addition to searching in the tracked files in the working
tree, search also in untracked files.
--no-index::
Search files in the current directory that is not managed by Git,
or by ignoring that the current directory is managed by Git. This
is rather similar to running the regular `grep(1)` utility with its
`-r` option specified, but with some additional benefits, such as
using pathspec patterns to limit paths; see the 'pathspec' entry
in linkgit:gitglossary[7] for more information.
+
This option cannot be used together with `--cached` or `--untracked`.
See also `grep.fallbackToNoIndex` in 'CONFIGURATION' below.
--no-exclude-standard::
Also search in ignored files by not honoring the `.gitignore`
mechanism. Only useful with `--untracked`.
--exclude-standard::
Do not pay attention to ignored files specified via the `.gitignore`
mechanism. Only useful when searching files in the current directory
with `--no-index`.
--recurse-submodules::
Recursively search in each submodule that is active and
checked out in the repository. When used in combination with the
_<tree>_ option the prefix of all submodule output will be the name of
the parent project's _<tree>_ object. This option cannot be used together
with `--untracked`, and it has no effect if `--no-index` is specified.
-a::
--text::
Process binary files as if they were text.
--textconv::
Honor textconv filter settings.
--no-textconv::
Do not honor textconv filter settings.
This is the default.
-i::
--ignore-case::
Ignore case differences between the patterns and the
files.
-I::
Don't match the pattern in binary files.
--max-depth <depth>::
For each <pathspec> given on command line, descend at most <depth>
levels of directories. A value of -1 means no limit.
This option is ignored if <pathspec> contains active wildcards.
In other words if "a*" matches a directory named "a*",
"*" is matched literally so --max-depth is still effective.
-r::
--recursive::
Same as `--max-depth=-1`; this is the default.
--no-recursive::
Same as `--max-depth=0`.
-w::
--word-regexp::
Match the pattern only at word boundary (either begin at the
beginning of a line, or preceded by a non-word character; end at
the end of a line or followed by a non-word character).
-v::
--invert-match::
Select non-matching lines.
-h::
-H::
By default, the command shows the filename for each
match. `-h` option is used to suppress this output.
`-H` is there for completeness and does not do anything
except it overrides `-h` given earlier on the command
line.
--full-name::
When run from a subdirectory, the command usually
outputs paths relative to the current directory. This
option forces paths to be output relative to the project
top directory.
-E::
--extended-regexp::
-G::
--basic-regexp::
Use POSIX extended/basic regexp for patterns. Default
is to use basic regexp.
-P::
--perl-regexp::
Use Perl-compatible regular expressions for patterns.
+
Support for these types of regular expressions is an optional
compile-time dependency. If Git wasn't compiled with support for them
providing this option will cause it to die.
-F::
--fixed-strings::
Use fixed strings for patterns (don't interpret pattern
as a regex).
-n::
--line-number::
Prefix the line number to matching lines.
--column::
Prefix the 1-indexed byte-offset of the first match from the start of the
matching line.
-l::
--files-with-matches::
--name-only::
-L::
--files-without-match::
Instead of showing every matched line, show only the
names of files that contain (or do not contain) matches.
For better compatibility with 'git diff', `--name-only` is a
synonym for `--files-with-matches`.
-O[<pager>]::
--open-files-in-pager[=<pager>]::
Open the matching files in the pager (not the output of 'grep').
If the pager happens to be "less" or "vi", and the user
specified only one pattern, the first file is positioned at
the first match automatically. The `pager` argument is
optional; if specified, it must be stuck to the option
without a space. If `pager` is unspecified, the default pager
will be used (see `core.pager` in linkgit:git-config[1]).
-z::
--null::
Use \0 as the delimiter for pathnames in the output, and print
them verbatim. Without this option, pathnames with "unusual"
characters are quoted as explained for the configuration
variable `core.quotePath` (see linkgit:git-config[1]).
-o::
--only-matching::
Print only the matched (non-empty) parts of a matching line, with each such
part on a separate output line.
-c::
--count::
Instead of showing every matched line, show the number of
lines that match.
--color[=<when>]::
Show colored matches.
The value must be always (the default), never, or auto.
--no-color::
Turn off match highlighting, even when the configuration file
gives the default to color output.
Same as `--color=never`.
--break::
Print an empty line between matches from different files.
--heading::
Show the filename above the matches in that file instead of
at the start of each shown line.
-p::
--show-function::
Show the preceding line that contains the function name of
the match, unless the matching line is a function name itself.
The name is determined in the same way as `git diff` works out
patch hunk headers (see 'Defining a custom hunk-header' in
linkgit:gitattributes[5]).
-<num>::
-C <num>::
--context <num>::
Show <num> leading and trailing lines, and place a line
containing `--` between contiguous groups of matches.
-A <num>::
--after-context <num>::
Show <num> trailing lines, and place a line containing
`--` between contiguous groups of matches.
-B <num>::
--before-context <num>::
Show <num> leading lines, and place a line containing
`--` between contiguous groups of matches.
-W::
--function-context::
Show the surrounding text from the previous line containing a
function name up to the one before the next function name,
effectively showing the whole function in which the match was
found. The function names are determined in the same way as
`git diff` works out patch hunk headers (see 'Defining a
custom hunk-header' in linkgit:gitattributes[5]).
-m <num>::
--max-count <num>::
Limit the amount of matches per file. When using the `-v` or
`--invert-match` option, the search stops after the specified
number of non-matches. A value of -1 will return unlimited
results (the default). A value of 0 will exit immediately with
a non-zero status.
--threads <num>::
Number of `grep` worker threads to use. See 'NOTES ON THREADS'
and `grep.threads` in 'CONFIGURATION' for more information.
-f <file>::
Read patterns from <file>, one per line.
+
Passing the pattern via <file> allows for providing a search pattern
containing a \0.
+
Not all pattern types support patterns containing \0. Git will error
out if a given pattern type can't support such a pattern. The
`--perl-regexp` pattern type when compiled against the PCRE v2 backend
has the widest support for these types of patterns.
+
In versions of Git before 2.23.0 patterns containing \0 would be
silently considered fixed. This was never documented, there were also
odd and undocumented interactions between e.g. non-ASCII patterns
containing \0 and `--ignore-case`.
+
In future versions we may learn to support patterns containing \0 for
more search backends, until then we'll die when the pattern type in
question doesn't support them.
-e::
The next parameter is the pattern. This option has to be
used for patterns starting with `-` and should be used in
scripts passing user input to grep. Multiple patterns are
combined by 'or'.
--and::
--or::
--not::
( ... )::
Specify how multiple patterns are combined using Boolean
expressions. `--or` is the default operator. `--and` has
higher precedence than `--or`. `-e` has to be used for all
patterns.
--all-match::
When giving multiple pattern expressions combined with `--or`,
this flag is specified to limit the match to files that
have lines to match all of them.
-q::
--quiet::
Do not output matched lines; instead, exit with status 0 when
there is a match and with non-zero status when there isn't.
<tree>...::
Instead of searching tracked files in the working tree, search
blobs in the given trees.
\--::
Signals the end of options; the rest of the parameters
are <pathspec> limiters.
<pathspec>...::
If given, limit the search to paths matching at least one pattern.
Both leading paths match and glob(7) patterns are supported.
+
For more details about the <pathspec> syntax, see the 'pathspec' entry
in linkgit:gitglossary[7].
EXAMPLES
--------
`git grep 'time_t' -- '*.[ch]'`::
Looks for `time_t` in all tracked .c and .h files in the working
directory and its subdirectories.
`git grep -e '#define' --and \( -e MAX_PATH -e PATH_MAX \)`::
Looks for a line that has `#define` and either `MAX_PATH` or
`PATH_MAX`.
`git grep --all-match -e NODE -e Unexpected`::
Looks for a line that has `NODE` or `Unexpected` in
files that have lines that match both.
`git grep solution -- :^Documentation`::
Looks for `solution`, excluding files in `Documentation`.
NOTES ON THREADS
----------------
The `--threads` option (and the `grep.threads` configuration) will be ignored when
`--open-files-in-pager` is used, forcing a single-threaded execution.
When grepping the object store (with `--cached` or giving tree objects), running
with multiple threads might perform slower than single-threaded if `--textconv`
is given and there are too many text conversions. Thus, if low performance is
experienced in this case, it might be desirable to use `--threads=1`.
CONFIGURATION
-------------
include::includes/cmd-config-section-all.adoc[]
include::config/grep.adoc[]
GIT
---
Part of the linkgit:git[1] suite

121
app/src/main/assets/manpages/git-gui.txt Normal file
View File

@@ -0,0 +1,121 @@
git-gui(1)
==========
NAME
----
git-gui - A portable graphical interface to Git
SYNOPSIS
--------
[verse]
'git gui' [<command>] [<arguments>]
DESCRIPTION
-----------
A Tcl/Tk based graphical user interface to Git. 'git gui' focuses
on allowing users to make changes to their repository by making
new commits, amending existing ones, creating branches, performing
local merges, and fetching/pushing to remote repositories.
Unlike 'gitk', 'git gui' focuses on commit generation
and single file annotation and does not show project history.
It does however supply menu actions to start a 'gitk' session from
within 'git gui'.
'git gui' is known to work on all popular UNIX systems, Mac OS X,
and Windows (under both Cygwin and MSYS). To the extent possible
OS specific user interface guidelines are followed, making 'git gui'
a fairly native interface for users.
COMMANDS
--------
blame::
Start a blame viewer on the specified file on the given
version (or working directory if not specified).
browser::
Start a tree browser showing all files in the specified
commit. Files selected through the
browser are opened in the blame viewer.
citool::
Start 'git gui' and arrange to make exactly one commit before
exiting and returning to the shell. The interface is limited
to only commit actions, slightly reducing the application's
startup time and simplifying the menubar.
version::
Display the currently running version of 'git gui'.
Examples
--------
`git gui blame Makefile`::
Show the contents of the file 'Makefile' in the current
working directory, and provide annotations for both the
original author of each line, and who moved the line to its
current location. The uncommitted file is annotated, and
uncommitted changes (if any) are explicitly attributed to
'Not Yet Committed'.
`git gui blame v0.99.8 Makefile`::
Show the contents of 'Makefile' in revision 'v0.99.8'
and provide annotations for each line. Unlike the above
example the file is read from the object database and not
the working directory.
`git gui blame --line=100 Makefile`::
Loads annotations as described above and automatically
scrolls the view to center on line '100'.
`git gui citool`::
Make one commit and return to the shell when it is complete.
This command returns a non-zero exit code if the window was
closed in any way other than by making a commit.
`git gui citool --amend`::
Automatically enter the 'Amend Last Commit' mode of
the interface.
`git gui citool --nocommit`::
Behave as normal citool, but instead of making a commit
simply terminate with a zero exit code. It still checks
that the index does not contain any unmerged entries, so
you can use it as a GUI version of linkgit:git-mergetool[1]
`git citool`::
Same as `git gui citool` (above).
`git gui browser maint`::
Show a browser for the tree of the 'maint' branch. Files
selected in the browser can be viewed with the internal
blame viewer.
SEE ALSO
--------
linkgit:gitk[1]::
The Git repository browser. Shows branches, commit history
and file differences. gitk is the utility started by
'git gui''s Repository Visualize actions.
Other
-----
'git gui' is actually maintained as an independent project, but stable
versions are distributed as part of the Git suite for the convenience
of end users.
The official repository of the 'git gui' project can be found at:
https://github.com/j6t/git-gui
GIT
---
Part of the linkgit:git[1] suite

65
app/src/main/assets/manpages/git-hash-object.txt Normal file
View File

@@ -0,0 +1,65 @@
git-hash-object(1)
==================
NAME
----
git-hash-object - Compute object ID and optionally create an object from a file
SYNOPSIS
--------
[verse]
'git hash-object' [-t <type>] [-w] [--path=<file> | --no-filters]
[--stdin [--literally]] [--] <file>...
'git hash-object' [-t <type>] [-w] --stdin-paths [--no-filters]
DESCRIPTION
-----------
Computes the object ID value for an object with specified type
with the contents of the named file (which can be outside of the
work tree), and optionally writes the resulting object into the
object database. Reports its object ID to its standard output.
When <type> is not specified, it defaults to "blob".
OPTIONS
-------
-t <type>::
Specify the type of object to be created (default: "blob"). Possible
values are `commit`, `tree`, `blob`, and `tag`.
-w::
Actually write the object into the object database.
--stdin::
Read the object from standard input instead of from a file.
--stdin-paths::
Read file names from the standard input, one per line, instead
of from the command-line.
--path::
Hash object as if it were located at the given path. The location of
the file does not directly influence the hash value, but the path is
used to determine which Git filters should be applied to the object
before it can be placed in the object database. As a result of
applying filters, the actual blob put into the object database may
differ from the given file. This option is mainly useful for hashing
temporary files located outside of the working directory or files
read from stdin.
--no-filters::
Hash the contents as is, ignoring any input filter that would
have been chosen by the attributes mechanism, including the end-of-line
conversion. If the file is read from standard input then this
is always implied, unless the `--path` option is given.
--literally::
Allow `--stdin` to hash any garbage into a loose object which might not
otherwise pass standard object parsing or git-fsck checks. Useful for
stress-testing Git itself or reproducing characteristics of corrupt or
bogus objects encountered in the wild.
GIT
---
Part of the linkgit:git[1] suite

231
app/src/main/assets/manpages/git-help.txt Normal file
View File

@@ -0,0 +1,231 @@
git-help(1)
===========
NAME
----
git-help - Display help information about Git
SYNOPSIS
--------
[verse]
'git help' [-a|--all] [--[no-]verbose] [--[no-]external-commands] [--[no-]aliases]
'git help' [[-i|--info] [-m|--man] [-w|--web]] [<command>|<doc>]
'git help' [-g|--guides]
'git help' [-c|--config]
'git help' [--user-interfaces]
'git help' [--developer-interfaces]
DESCRIPTION
-----------
With no options and no '<command>' or '<doc>' given, the synopsis of the 'git'
command and a list of the most commonly used Git commands are printed
on the standard output.
If the option `--all` or `-a` is given, all available commands are
printed on the standard output.
If the option `--guides` or `-g` is given, a list of the
Git concept guides is also printed on the standard output.
If a command or other documentation is given, the relevant manual page
will be brought up. The 'man' program is used by default for this
purpose, but this can be overridden by other options or configuration
variables.
If an alias is given, git shows the definition of the alias on
standard output. To get the manual page for the aliased command, use
`git <command> --help`.
Note that `git --help ...` is identical to `git help ...` because the
former is internally converted into the latter.
To display the linkgit:git[1] man page, use `git help git`.
This page can be displayed with 'git help help' or `git help --help`.
OPTIONS
-------
-a::
--all::
Print all the available commands on the standard output.
--no-external-commands::
When used with `--all`, exclude the listing of external "git-*"
commands found in the `$PATH`.
--no-aliases::
When used with `--all`, exclude the listing of configured
aliases.
--verbose::
When used with `--all`, print description for all recognized
commands. This is the default.
-c::
--config::
List all available configuration variables. This is a short
summary of the list in linkgit:git-config[1].
-g::
--guides::
Print a list of the Git concept guides on the standard output.
--user-interfaces::
Print a list of the repository, command and file interfaces
documentation on the standard output.
+
In-repository file interfaces such as `.git/info/exclude` are
documented here (see linkgit:gitrepository-layout[5]), as well as
in-tree configuration such as `.mailmap` (see linkgit:gitmailmap[5]).
+
This section of the documentation also covers general or widespread
user-interface conventions (e.g. linkgit:gitcli[7]), and
pseudo-configuration such as the file-based `.git/hooks/*` interface
described in linkgit:githooks[5].
--developer-interfaces::
Print a list of file formats, protocols and other developer
interfaces documentation on the standard output.
-i::
--info::
Display manual page for the command in the 'info' format. The
'info' program will be used for that purpose.
-m::
--man::
Display manual page for the command in the 'man' format. This
option may be used to override a value set in the
`help.format` configuration variable.
+
By default the 'man' program will be used to display the manual page,
but the `man.viewer` configuration variable may be used to choose
other display programs (see below).
-w::
--web::
Display manual page for the command in the 'web' (HTML)
format. A web browser will be used for that purpose.
+
The web browser can be specified using the configuration variable
`help.browser`, or `web.browser` if the former is not set. If neither of
these config variables is set, the 'git web{litdd}browse' helper script
(called by 'git help') will pick a suitable default. See
linkgit:git-web{litdd}browse[1] for more information about this.
CONFIGURATION VARIABLES
-----------------------
help.format
~~~~~~~~~~~
If no command-line option is passed, the `help.format` configuration
variable will be checked. The following values are supported for this
variable; they make 'git help' behave as their corresponding command-
line option:
* "man" corresponds to '-m|--man',
* "info" corresponds to '-i|--info',
* "web" or "html" correspond to '-w|--web'.
help.browser, web.browser, and browser.<tool>.path
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The `help.browser`, `web.browser` and `browser.<tool>.path` will also
be checked if the 'web' format is chosen (either by command-line
option or configuration variable). See '-w|--web' in the OPTIONS
section above and linkgit:git-web{litdd}browse[1].
man.viewer
~~~~~~~~~~
The `man.viewer` configuration variable will be checked if the 'man'
format is chosen. The following values are currently supported:
* "man": use the 'man' program as usual,
* "woman": use 'emacsclient' to launch the "woman" mode in emacs
(this only works starting with emacsclient versions 22),
* "konqueror": use 'kfmclient' to open the man page in a new konqueror
tab (see 'Note about konqueror' below).
Values for other tools can be used if there is a corresponding
`man.<tool>.cmd` configuration entry (see below).
Multiple values may be given to the `man.viewer` configuration
variable. Their corresponding programs will be tried in the order
listed in the configuration file.
For example, this configuration:
------------------------------------------------
[man]
viewer = konqueror
viewer = woman
------------------------------------------------
will try to use konqueror first. But this may fail (for example, if
DISPLAY is not set) and in that case emacs' woman mode will be tried.
If everything fails, or if no viewer is configured, the viewer specified
in the `GIT_MAN_VIEWER` environment variable will be tried. If that
fails too, the 'man' program will be tried anyway.
man.<tool>.path
~~~~~~~~~~~~~~~
You can explicitly provide a full path to your preferred man viewer by
setting the configuration variable `man.<tool>.path`. For example, you
can configure the absolute path to konqueror by setting
'man.konqueror.path'. Otherwise, 'git help' assumes the tool is
available in PATH.
man.<tool>.cmd
~~~~~~~~~~~~~~
When the man viewer, specified by the `man.viewer` configuration
variables, is not among the supported ones, then the corresponding
`man.<tool>.cmd` configuration variable will be looked up. If this
variable exists then the specified tool will be treated as a custom
command and a shell eval will be used to run the command with the man
page passed as arguments.
Note about konqueror
~~~~~~~~~~~~~~~~~~~~
When 'konqueror' is specified in the `man.viewer` configuration
variable, we launch 'kfmclient' to try to open the man page on an
already opened konqueror in a new tab if possible.
For consistency, we also try such a trick if 'man.konqueror.path' is
set to something like `A_PATH_TO/konqueror`. That means we will try to
launch `A_PATH_TO/kfmclient` instead.
If you really want to use 'konqueror', then you can use something like
the following:
------------------------------------------------
[man]
viewer = konq
[man "konq"]
cmd = A_PATH_TO/konqueror
------------------------------------------------
Note about git config --global
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Note that all these configuration variables should probably be set
using the `--global` flag, for example like this:
------------------------------------------------
$ git config --global help.format web
$ git config --global web.browser firefox
------------------------------------------------
as they are probably more user specific than repository specific.
See linkgit:git-config[1] for more information about this.
GIT
---
Part of the linkgit:git[1] suite

139
app/src/main/assets/manpages/git-history.txt Normal file
View File

@@ -0,0 +1,139 @@
git-history(1)
==============
NAME
----
git-history - EXPERIMENTAL: Rewrite history
SYNOPSIS
--------
[synopsis]
git history reword <commit> [--dry-run] [--update-refs=(branches|head)]
git history split <commit> [--dry-run] [--update-refs=(branches|head)] [--] [<pathspec>...]
DESCRIPTION
-----------
Rewrite history by rearranging or modifying specific commits in the
history.
THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
This command is related to linkgit:git-rebase[1] in that both commands can be
used to rewrite history. There are a couple of major differences though:
* linkgit:git-history[1] can work in a bare repository as it does not need to
touch either the index or the worktree.
* linkgit:git-history[1] does not execute any linkgit:githooks[5] at the
current point in time. This may change in the future.
* linkgit:git-history[1] by default updates all branches that are descendants
of the original commit to point to the rewritten commit.
Overall, linkgit:git-history[1] aims to provide a more opinionated way to modify
your commit history that is simpler to use compared to linkgit:git-rebase[1] in
general.
Use linkgit:git-rebase[1] if you want to reapply a range of commits onto a
different base, or interactive rebases if you want to edit a range of commits
at once.
LIMITATIONS
-----------
This command does not (yet) work with histories that contain merges. You
should use linkgit:git-rebase[1] with the `--rebase-merges` flag instead.
Furthermore, the command does not support operations that can result in merge
conflicts. This limitation is by design as history rewrites are not intended to
be stateful operations. The limitation can be lifted once (if) Git learns about
first-class conflicts.
COMMANDS
--------
The following commands are available to rewrite history in different ways:
`reword <commit>`::
Rewrite the commit message of the specified commit. All the other
details of this commit remain unchanged. This command will spawn an
editor with the current message of that commit.
`split <commit> [--] [<pathspec>...]`::
Interactively split up <commit> into two commits by choosing
hunks introduced by it that will be moved into the new split-out
commit. These hunks will then be written into a new commit that
becomes the parent of the previous commit. The original commit
stays intact, except that its parent will be the newly split-out
commit.
+
The commit messages of the split-up commits will be asked for by launching
the configured editor. Authorship of the commit will be the same as for the
original commit.
+
If passed, _<pathspec>_ can be used to limit which changes shall be split out
of the original commit. Files not matching any of the pathspecs will remain
part of the original commit. For more details, see the 'pathspec' entry in
linkgit:gitglossary[7].
+
It is invalid to select either all or no hunks, as that would lead to
one of the commits becoming empty.
OPTIONS
-------
`--dry-run`::
Do not update any references, but instead print any ref updates in a
format that can be consumed by linkgit:git-update-ref[1]. Necessary new
objects will be written into the repository, so applying these printed
ref updates is generally safe.
`--update-refs=(branches|head)`::
Control which references will be updated by the command, if any. With
`branches`, all local branches that point to commits which are
descendants of the original commit will be rewritten. With `head`, only
the current `HEAD` reference will be rewritten. Defaults to `branches`.
EXAMPLES
--------
Split a commit
~~~~~~~~~~~~~~
----------
$ git log --stat --oneline
3f81232 (HEAD -> main) original
bar | 1 +
foo | 1 +
2 files changed, 2 insertions(+)
$ git history split HEAD
diff --git a/bar b/bar
new file mode 100644
index 0000000..5716ca5
--- /dev/null
+++ b/bar
@@ -0,0 +1 @@
+bar
(1/1) Stage addition [y,n,q,a,d,p,?]? y
diff --git a/foo b/foo
new file mode 100644
index 0000000..257cc56
--- /dev/null
+++ b/foo
@@ -0,0 +1 @@
+foo
(1/1) Stage addition [y,n,q,a,d,p,?]? n
$ git log --stat --oneline
7cebe64 (HEAD -> main) original
foo | 1 +
1 file changed, 1 insertion(+)
d1582f3 split-out commit
bar | 1 +
1 file changed, 1 insertion(+)
----------
GIT
---
Part of the linkgit:git[1] suite

196
app/src/main/assets/manpages/git-hook.txt Normal file
View File

@@ -0,0 +1,196 @@
git-hook(1)
===========
NAME
----
git-hook - Run git hooks
SYNOPSIS
--------
[verse]
'git hook' run [--allow-unknown-hook-name] [--ignore-missing] [--to-stdin=<path>] <hook-name> [-- <hook-args>]
'git hook' list [--allow-unknown-hook-name] [-z] [--show-scope] <hook-name>
DESCRIPTION
-----------
A command interface for running git hooks (see linkgit:githooks[5]),
for use by other scripted git commands.
This command parses the default configuration files for sets of configs like
so:
[hook "linter"]
event = pre-commit
command = ~/bin/linter --cpp20
In this example, `[hook "linter"]` represents one script - `~/bin/linter
--cpp20` - which can be shared by many repos, and even by many hook events, if
appropriate.
To add an unrelated hook which runs on a different event, for example a
spell-checker for your commit messages, you would write a configuration like so:
[hook "linter"]
event = pre-commit
command = ~/bin/linter --cpp20
[hook "spellcheck"]
event = commit-msg
command = ~/bin/spellchecker
With this config, when you run 'git commit', first `~/bin/linter --cpp20` will
have a chance to check your files to be committed (during the `pre-commit` hook
event`), and then `~/bin/spellchecker` will have a chance to check your commit
message (during the `commit-msg` hook event).
Commands are run in the order Git encounters their associated
`hook.<friendly-name>.event` configs during the configuration parse (see
linkgit:git-config[1]). Although multiple `hook.linter.event` configs can be
added, only one `hook.linter.command` event is valid - Git uses "last-one-wins"
to determine which command to run.
So if you wanted your linter to run when you commit as well as when you push,
you would configure it like so:
[hook "linter"]
event = pre-commit
event = pre-push
command = ~/bin/linter --cpp20
With this config, `~/bin/linter --cpp20` would be run by Git before a commit is
generated (during `pre-commit`) as well as before a push is performed (during
`pre-push`).
And if you wanted to run your linter as well as a secret-leak detector during
only the "pre-commit" hook event, you would configure it instead like so:
[hook "linter"]
event = pre-commit
command = ~/bin/linter --cpp20
[hook "no-leaks"]
event = pre-commit
command = ~/bin/leak-detector
With this config, before a commit is generated (during `pre-commit`), Git would
first start `~/bin/linter --cpp20` and second start `~/bin/leak-detector`. It
would evaluate the output of each when deciding whether to proceed with the
commit.
For a full list of hook events which you can set your `hook.<friendly-name>.event` to,
and how hooks are invoked during those events, see linkgit:githooks[5].
Git will ignore any `hook.<friendly-name>.event` that specifies an event it doesn't
recognize. This is intended so that tools which wrap Git can use the hook
infrastructure to run their own hooks; see "WRAPPERS" for more guidance.
In general, when instructions suggest adding a script to
`.git/hooks/<hook-event>`, you can specify it in the config instead by running:
----
git config set hook.<some-name>.command <path-to-script>
git config set --append hook.<some-name>.event <hook-event>
----
This way you can share the script between multiple repos. That is, `cp
~/my-script.sh ~/project/.git/hooks/pre-commit` would become:
----
git config set hook.my-script.command ~/my-script.sh
git config set --append hook.my-script.event pre-commit
----
SUBCOMMANDS
-----------
run::
Runs hooks configured for `<hook-name>`, in the order they are
discovered during the config parse. The default `<hook-name>` from
the hookdir is run last. See linkgit:githooks[5] for supported
hook names.
+
Any positional arguments to the hook should be passed after a
mandatory `--` (or `--end-of-options`, see linkgit:gitcli[7]). See
linkgit:githooks[5] for arguments hooks might expect (if any).
list [-z] [--show-scope]::
Print a list of hooks which will be run on `<hook-name>` event. If no
hooks are configured for that event, print a warning and return 1.
Use `-z` to terminate output lines with NUL instead of newlines.
OPTIONS
-------
--allow-unknown-hook-name::
By default `git hook run` and `git hook list` will bail out when
`<hook-name>` is not a hook event known to Git (see linkgit:githooks[5]
for the list of known hooks). This is meant to help catch typos
such as `prereceive` when `pre-receive` was intended. Pass this
flag to allow unknown hook names.
--to-stdin::
For "run"; specify a file which will be streamed into the
hook's stdin. The hook will receive the entire file from
beginning to EOF.
--ignore-missing::
Ignore any missing hook by quietly returning zero. Used for
tools that want to do a blind one-shot run of a hook that may
or may not be present.
-z::
Terminate "list" output lines with NUL instead of newlines.
--show-scope::
For "list"; prefix each configured hook's friendly name with a
tab-separated config scope (e.g. `local`, `global`, `system`),
mirroring the output style of `git config --show-scope`. Traditional
hooks from the hookdir are unaffected.
WRAPPERS
--------
`git hook run` has been designed to make it easy for tools which wrap Git to
configure and execute hooks using the Git hook infrastructure. It is possible to
provide arguments and stdin via the command line, as well as specifying parallel
or series execution if the user has provided multiple hooks.
Assuming your wrapper wants to support a hook named "mywrapper-start-tests", you
can have your users specify their hooks like so:
[hook "setup-test-dashboard"]
event = mywrapper-start-tests
command = ~/mywrapper/setup-dashboard.py --tap
Then, in your 'mywrapper' tool, you can invoke any users' configured hooks by
running:
----
git hook run --allow-unknown-hook-name mywrapper-start-tests \
# providing something to stdin
--stdin some-tempfile-123 \
# execute hooks in serial
# plus some arguments of your own...
-- \
--testname bar \
baz
----
Take care to name your wrapper's hook events in a way which is unlikely to
overlap with Git's native hooks (see linkgit:githooks[5]) - a hook event named
`mywrappertool-validate-commit` is much less likely to be added to native Git
than a hook event named `validate-commit`. If Git begins to use a hook event
named the same thing as your wrapper hook, it may invoke your users' hooks in
unintended and unsupported ways.
CONFIGURATION
-------------
include::config/hook.adoc[]
SEE ALSO
--------
linkgit:githooks[5]
GIT
---
Part of the linkgit:git[1] suite

305
app/src/main/assets/manpages/git-http-backend.txt Normal file
View File

@@ -0,0 +1,305 @@
git-http-backend(1)
===================
NAME
----
git-http-backend - Server side implementation of Git over HTTP
SYNOPSIS
--------
[verse]
'git http-backend'
DESCRIPTION
-----------
A simple CGI program to serve the contents of a Git repository to Git
clients accessing the repository over http:// and https:// protocols.
The program supports clients fetching using both the smart HTTP protocol
and the backwards-compatible dumb HTTP protocol, as well as clients
pushing using the smart HTTP protocol. It also supports Git's
more-efficient "v2" protocol if properly configured; see the
discussion of `GIT_PROTOCOL` in the ENVIRONMENT section below.
It verifies that the directory has the magic file
"git-daemon-export-ok", and it will refuse to export any Git directory
that hasn't explicitly been marked for export this way (unless the
`GIT_HTTP_EXPORT_ALL` environment variable is set).
By default, only the `upload-pack` service is enabled, which serves
'git fetch-pack' and 'git ls-remote' clients, which are invoked from
'git fetch', 'git pull', and 'git clone'. If the client is authenticated,
the `receive-pack` service is enabled, which serves 'git send-pack'
clients, which is invoked from 'git push'.
SERVICES
--------
These services can be enabled/disabled using the per-repository
configuration file:
http.getanyfile::
This serves Git clients older than version 1.6.6 that are unable to use the
upload pack service. When enabled, clients are able to read
any file within the repository, including objects that are
no longer reachable from a branch but are still present.
It is enabled by default, but a repository can disable it
by setting this configuration value to `false`.
http.uploadpack::
This serves 'git fetch-pack' and 'git ls-remote' clients.
It is enabled by default, but a repository can disable it
by setting this configuration value to `false`.
http.receivepack::
This serves 'git send-pack' clients, allowing push. It is
disabled by default for anonymous users, and enabled by
default for users authenticated by the web server. It can be
disabled by setting this item to `false`, or enabled for all
users, including anonymous users, by setting it to `true`.
http.uploadarchive::
This serves 'git archive' clients for remote archive over HTTP/HTTPS
protocols. It is disabled by default. It only works in protocol v2.
URL TRANSLATION
---------------
To determine the location of the repository on disk, 'git http-backend'
concatenates the environment variables PATH_INFO, which is set
automatically by the web server, and GIT_PROJECT_ROOT, which must be set
manually in the web server configuration. If GIT_PROJECT_ROOT is not
set, 'git http-backend' reads PATH_TRANSLATED, which is also set
automatically by the web server.
EXAMPLES
--------
All of the following examples map `http://$hostname/git/foo/bar.git`
to `/var/www/git/foo/bar.git`.
Apache 2.x::
Ensure mod_cgi, mod_alias, and mod_env are enabled, set
GIT_PROJECT_ROOT (or DocumentRoot) appropriately, and
create a ScriptAlias to the CGI:
+
----------------------------------------------------------------
SetEnv GIT_PROJECT_ROOT /var/www/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
# This is not strictly necessary using Apache and a modern version of
# git-http-backend, as the webserver will pass along the header in the
# environment as HTTP_GIT_PROTOCOL, and http-backend will copy that into
# GIT_PROTOCOL. But you may need this line (or something similar if you
# are using a different webserver), or if you want to support older Git
# versions that did not do that copying.
#
# Having the webserver set up GIT_PROTOCOL is perfectly fine even with
# modern versions (and will take precedence over HTTP_GIT_PROTOCOL,
# which means it can be used to override the client's request).
SetEnvIf Git-Protocol ".*" GIT_PROTOCOL=$0
----------------------------------------------------------------
+
To enable anonymous read access but authenticated write access,
require authorization for both the initial ref advertisement (which we
detect as a push via the service parameter in the query string), and the
receive-pack invocation itself:
+
----------------------------------------------------------------
RewriteCond %{QUERY_STRING} service=git-receive-pack [OR]
RewriteCond %{REQUEST_URI} /git-receive-pack$
RewriteRule ^/git/ - [E=AUTHREQUIRED:yes]
<LocationMatch "^/git/">
Order Deny,Allow
Deny from env=AUTHREQUIRED
AuthType Basic
AuthName "Git Access"
Require group committers
Satisfy Any
...
</LocationMatch>
----------------------------------------------------------------
+
If you do not have `mod_rewrite` available to match against the query
string, it is sufficient to just protect `git-receive-pack` itself,
like:
+
----------------------------------------------------------------
<LocationMatch "^/git/.*/git-receive-pack$">
AuthType Basic
AuthName "Git Access"
Require group committers
...
</LocationMatch>
----------------------------------------------------------------
+
In this mode, the server will not request authentication until the
client actually starts the object negotiation phase of the push, rather
than during the initial contact. For this reason, you must also enable
the `http.receivepack` config option in any repositories that should
accept a push. The default behavior, if `http.receivepack` is not set,
is to reject any pushes by unauthenticated users; the initial request
will therefore report `403 Forbidden` to the client, without even giving
an opportunity for authentication.
+
To require authentication for both reads and writes, use a Location
directive around the repository, or one of its parent directories:
+
----------------------------------------------------------------
<Location /git/private>
AuthType Basic
AuthName "Private Git Access"
Require group committers
...
</Location>
----------------------------------------------------------------
+
To serve gitweb at the same url, use a ScriptAliasMatch to only
those URLs that 'git http-backend' can handle, and forward the
rest to gitweb:
+
----------------------------------------------------------------
ScriptAliasMatch \
"(?x)^/git/(.*/(HEAD | \
info/refs | \
objects/(info/[^/]+ | \
[0-9a-f]{2}/[0-9a-f]{38} | \
pack/pack-[0-9a-f]{40}\.(pack|idx)) | \
git-(upload|receive)-pack))$" \
/usr/libexec/git-core/git-http-backend/$1
ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/
----------------------------------------------------------------
+
To serve multiple repositories from different linkgit:gitnamespaces[7] in a
single repository:
+
----------------------------------------------------------------
SetEnvIf Request_URI "^/git/([^/]*)" GIT_NAMESPACE=$1
ScriptAliasMatch ^/git/[^/]*(.*) /usr/libexec/git-core/git-http-backend/storage.git$1
----------------------------------------------------------------
Accelerated static Apache 2.x::
Similar to the above, but Apache can be used to return static
files that are stored on disk. On many systems this may
be more efficient as Apache can ask the kernel to copy the
file contents from the file system directly to the network:
+
----------------------------------------------------------------
SetEnv GIT_PROJECT_ROOT /var/www/git
AliasMatch ^/git/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$ /var/www/git/$1
AliasMatch ^/git/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /var/www/git/$1
ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
----------------------------------------------------------------
+
This can be combined with the gitweb configuration:
+
----------------------------------------------------------------
SetEnv GIT_PROJECT_ROOT /var/www/git
AliasMatch ^/git/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$ /var/www/git/$1
AliasMatch ^/git/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /var/www/git/$1
ScriptAliasMatch \
"(?x)^/git/(.*/(HEAD | \
info/refs | \
objects/info/[^/]+ | \
git-(upload|receive)-pack))$" \
/usr/libexec/git-core/git-http-backend/$1
ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/
----------------------------------------------------------------
Lighttpd::
Ensure that `mod_cgi`, `mod_alias`, `mod_auth`, `mod_setenv` are
loaded, then set `GIT_PROJECT_ROOT` appropriately and redirect
all requests to the CGI:
+
----------------------------------------------------------------
alias.url += ( "/git" => "/usr/lib/git-core/git-http-backend" )
$HTTP["url"] =~ "^/git" {
cgi.assign = ("" => "")
setenv.add-environment = (
"GIT_PROJECT_ROOT" => "/var/www/git",
"GIT_HTTP_EXPORT_ALL" => ""
)
}
----------------------------------------------------------------
+
To enable anonymous read access but authenticated write access:
+
----------------------------------------------------------------
$HTTP["querystring"] =~ "service=git-receive-pack" {
include "git-auth.conf"
}
$HTTP["url"] =~ "^/git/.*/git-receive-pack$" {
include "git-auth.conf"
}
----------------------------------------------------------------
+
where `git-auth.conf` looks something like:
+
----------------------------------------------------------------
auth.require = (
"/" => (
"method" => "basic",
"realm" => "Git Access",
"require" => "valid-user"
)
)
# ...and set up auth.backend here
----------------------------------------------------------------
+
To require authentication for both reads and writes:
+
----------------------------------------------------------------
$HTTP["url"] =~ "^/git/private" {
include "git-auth.conf"
}
----------------------------------------------------------------
ENVIRONMENT
-----------
'git http-backend' relies upon the `CGI` environment variables set
by the invoking web server, including:
* PATH_INFO (if GIT_PROJECT_ROOT is set, otherwise PATH_TRANSLATED)
* REMOTE_USER
* REMOTE_ADDR
* CONTENT_TYPE
* QUERY_STRING
* REQUEST_METHOD
The `GIT_HTTP_EXPORT_ALL` environment variable may be passed to
'git-http-backend' to bypass the check for the "git-daemon-export-ok"
file in each repository before allowing export of that repository.
The `GIT_HTTP_MAX_REQUEST_BUFFER` environment variable (or the
`http.maxRequestBuffer` config option) may be set to change the
largest ref negotiation request that git will handle during a fetch; any
fetch requiring a larger buffer will not succeed. This value should not
normally need to be changed, but may be helpful if you are fetching from
a repository with an extremely large number of refs. The value can be
specified with a unit (e.g., `100M` for 100 megabytes). The default is
10 megabytes.
Clients may probe for optional protocol capabilities (like the v2
protocol) using the `Git-Protocol` HTTP header. In order to support
these, the contents of that header must appear in the `GIT_PROTOCOL`
environment variable. Most webservers will pass this header to the CGI
via the `HTTP_GIT_PROTOCOL` variable, and `git-http-backend` will
automatically copy that to `GIT_PROTOCOL`. However, some webservers may
be more selective about which headers they'll pass, in which case they
need to be configured explicitly (see the mention of `Git-Protocol` in
the Apache config from the earlier EXAMPLES section).
The backend process sets GIT_COMMITTER_NAME to '$REMOTE_USER' and
GIT_COMMITTER_EMAIL to '$\{REMOTE_USER}@http.$\{REMOTE_ADDR\}',
ensuring that any reflogs created by 'git-receive-pack' contain some
identifying information of the remote user who performed the push.
All `CGI` environment variables are available to each of the hooks
invoked by the 'git-receive-pack'.
GIT
---
Part of the linkgit:git[1] suite

65
app/src/main/assets/manpages/git-http-fetch.txt Normal file
View File

@@ -0,0 +1,65 @@
git-http-fetch(1)
=================
NAME
----
git-http-fetch - Download from a remote Git repository via HTTP
SYNOPSIS
--------
[verse]
'git http-fetch' [-c] [-t] [-a] [-d] [-v] [-w <filename>] [--recover] [--stdin | --packfile=<hash> | <commit>] <URL>
DESCRIPTION
-----------
Downloads a remote Git repository via HTTP.
This command always gets all objects. Historically, there were three options
`-a`, `-c` and `-t` for choosing which objects to download. They are now
silently ignored.
OPTIONS
-------
commit-id::
Either the hash or the filename under [URL]/refs/ to
pull.
-a::
-c::
-t::
These options are ignored for historical reasons.
-v::
Report what is downloaded.
-w <filename>::
Writes the commit-id into the specified filename under $GIT_DIR/refs/<filename> on
the local end after the transfer is complete.
--stdin::
Instead of a commit id on the command line (which is not expected in this
case), 'git http-fetch' expects lines on stdin in the format
<commit-id>['\t'<filename-as-in--w>]
--packfile=<hash>::
For internal use only. Instead of a commit id on the command
line (which is not expected in
this case), 'git http-fetch' fetches the packfile directly at the given
URL and uses index-pack to generate corresponding .idx and .keep files.
The hash is used to determine the name of the temporary file and is
arbitrary. The output of index-pack is printed to stdout. Requires
--index-pack-args.
--index-pack-args=<args>::
For internal use only. The command to run on the contents of the
downloaded pack. Arguments are URL-encoded separated by spaces.
--recover::
Verify that everything reachable from target is fetched. Used after
an earlier fetch is interrupted.
GIT
---
Part of the linkgit:git[1] suite

96
app/src/main/assets/manpages/git-http-push.txt Normal file
View File

@@ -0,0 +1,96 @@
git-http-push(1)
================
NAME
----
git-http-push - Push objects over HTTP/DAV to another repository
SYNOPSIS
--------
[verse]
'git http-push' [--all] [--dry-run] [--force] [--verbose] <URL> <ref> [<ref>...]
DESCRIPTION
-----------
Sends missing objects to the remote repository, and updates the
remote branch.
*NOTE*: This command is temporarily disabled if your libcurl
is older than 7.16, as the combination has been reported
not to work and sometimes corrupts the repository.
OPTIONS
-------
--all::
Do not assume that the remote repository is complete in its
current state, and verify all objects in the entire local
ref's history exist in the remote repository.
--force::
Usually, the command refuses to update a remote ref that
is not an ancestor of the local ref used to overwrite it.
This flag disables the check. What this means is that
the remote repository can lose commits; use it with
care.
--dry-run::
Do everything except actually send the updates.
--verbose::
Report the list of objects being walked locally and the
list of objects successfully sent to the remote repository.
-d::
-D::
Remove <ref> from remote repository. The specified branch
cannot be the remote HEAD. If -d is specified, the following
other conditions must also be met:
- Remote HEAD must resolve to an object that exists locally
- Specified branch resolves to an object that exists locally
- Specified branch is an ancestor of the remote HEAD
<ref>...::
The remote refs to update.
SPECIFYING THE REFS
-------------------
A '<ref>' specification can be either a single pattern, or a pair
of such patterns separated by a colon ":" (this means that a ref name
cannot have a colon in it). A single pattern '<name>' is just a
shorthand for '<name>:<name>'.
Each pattern pair '<src>:<dst>' consists of the source side (before
the colon) and the destination side (after the colon). The ref to be
pushed is determined by finding a match that matches the source side,
and where it is pushed is determined by using the destination side.
- It is an error if '<src>' does not match exactly one of the
local refs.
- If '<dst>' does not match any remote ref, either
* it has to start with "refs/"; <dst> is used as the
destination literally in this case.
* <src> == <dst> and the ref that matched the <src> must not
exist in the set of remote refs; the ref matched <src>
locally is used as the name of the destination.
Without `--force`, the <src> ref is stored at the remote only if
<dst> does not exist, or <dst> is a proper subset (i.e. an
ancestor) of <src>. This check, known as "fast-forward check",
is performed to avoid accidentally overwriting the
remote ref and losing other peoples' commits from there.
With `--force`, the fast-forward check is disabled for all refs.
Optionally, a <ref> parameter can be prefixed with a plus '+' sign
to disable the fast-forward check only on that ref.
GIT
---
Part of the linkgit:git[1] suite

224
app/src/main/assets/manpages/git-imap-send.txt Normal file
View File

@@ -0,0 +1,224 @@
git-imap-send(1)
================
NAME
----
git-imap-send - Send a collection of patches from stdin to an IMAP folder
SYNOPSIS
--------
[verse]
'git imap-send' [-v] [-q] [--[no-]curl] [(--folder|-f) <folder>]
'git imap-send' --list
DESCRIPTION
-----------
This command uploads a mailbox generated with `git format-patch`
into an IMAP drafts folder. This allows patches to be sent as
other email is when using mail clients that cannot read mailbox
files directly. The command also works with any general mailbox
in which emails have the fields `From`, `Date`, and `Subject` in
that order.
Typical usage is something like:
------
$ git format-patch --signoff --stdout --attach origin | git imap-send
------
OPTIONS
-------
-v::
--verbose::
Be verbose.
-q::
--quiet::
Be quiet.
-f <folder>::
--folder=<folder>::
Specify the folder in which the emails have to saved.
For example: `--folder=[Gmail]/Drafts` or `-f INBOX/Drafts`.
--curl::
Use libcurl to communicate with the IMAP server, unless tunneling
into it. Ignored if Git was built without the USE_CURL_FOR_IMAP_SEND
option set.
--no-curl::
Talk to the IMAP server using git's own IMAP routines instead of
using libcurl. Ignored if Git was built with the NO_OPENSSL option
set.
--list::
Run the IMAP LIST command to output a list of all the folders present.
CONFIGURATION
-------------
To use the tool, `imap.folder` and either `imap.tunnel` or `imap.host` must be set
to appropriate values.
include::includes/cmd-config-section-rest.adoc[]
include::config/imap.adoc[]
GETTING A LIST OF AVAILABLE FOLDERS
-----------------------------------
In order to send an email to a specific folder, you need to know the correct name of
intended folder in your mailbox. The names like "Junk", "Trash" etc. displayed by
various email clients need not be the actual names of the folders stored in the mail
server of your email provider.
In order to get the correct folder name to be used with `git imap-send`, you can run
`git imap-send --list`. This will display a list of valid folder names. An example
of such an output when run on a Gmail account is:
.........................
* LIST (\HasNoChildren) "/" "INBOX"
* LIST (\HasChildren \Noselect) "/" "[Gmail]"
* LIST (\All \HasNoChildren) "/" "[Gmail]/All Mail"
* LIST (\Drafts \HasNoChildren) "/" "[Gmail]/Drafts"
* LIST (\HasNoChildren \Important) "/" "[Gmail]/Important"
* LIST (\HasNoChildren \Sent) "/" "[Gmail]/Sent Mail"
* LIST (\HasNoChildren \Junk) "/" "[Gmail]/Spam"
* LIST (\Flagged \HasNoChildren) "/" "[Gmail]/Starred"
* LIST (\HasNoChildren \Trash) "/" "[Gmail]/Trash"
.........................
Here, you can observe that the correct name for the "Junk" folder is `[Gmail]/Spam`
and for the "Trash" folder is `[Gmail]/Trash`. Similar logic can be used to determine
other folders as well.
EXAMPLES
--------
Using tunnel mode:
..........................
[imap]
folder = "INBOX.Drafts"
tunnel = "ssh -q -C user@example.com /usr/bin/imapd ./Maildir 2> /dev/null"
..........................
Using direct mode:
.........................
[imap]
folder = "INBOX.Drafts"
host = imap://imap.example.com
user = bob
pass = p4ssw0rd
.........................
Using direct mode with SSL:
.........................
[imap]
folder = "INBOX.Drafts"
host = imaps://imap.example.com
user = bob
pass = p4ssw0rd
port = 123
; sslVerify = false
.........................
[NOTE]
You may want to use `sslVerify=false`
while troubleshooting, if you suspect that the reason you are
having trouble connecting is because the certificate you use at
the private server `example.com` you are trying to set up (or
have set up) may not be verified correctly.
Using Gmail's IMAP interface:
---------
[imap]
folder = "[Gmail]/Drafts"
host = imaps://imap.gmail.com
user = user@gmail.com
port = 993
---------
Gmail does not allow using your regular password for `git imap-send`.
If you have multi-factor authentication set up on your Gmail account, you
can generate an app-specific password for use with `git imap-send`.
Visit https://security.google.com/settings/security/apppasswords to create
it. Alternatively, use OAuth2.0 authentication as described below.
[NOTE]
You might need to instead use: `folder = "[Google Mail]/Drafts"` if you get an error
that the "Folder doesn't exist". You can also run `git imap-send --list` to get a
list of available folders.
[NOTE]
If your Gmail account is set to another language than English, the name of the "Drafts"
folder will be localized.
If you want to use OAuth2.0 based authentication, you can specify
`OAUTHBEARER` or `XOAUTH2` mechanism in your config. It is more secure
than using app-specific passwords, and also does not enforce the need of
having multi-factor authentication. You will have to use an OAuth2.0
access token in place of your password when using this authentication.
---------
[imap]
folder = "[Gmail]/Drafts"
host = imaps://imap.gmail.com
user = user@gmail.com
port = 993
authmethod = OAUTHBEARER
---------
Using Outlook's IMAP interface:
Unlike Gmail, Outlook only supports OAuth2.0 based authentication. Also, it
supports only `XOAUTH2` as the mechanism.
---------
[imap]
folder = "Drafts"
host = imaps://outlook.office365.com
user = user@outlook.com
port = 993
authmethod = XOAUTH2
---------
Once the commits are ready to be sent, run the following command:
$ git format-patch --cover-letter -M --stdout origin/master | git imap-send
Just make sure to disable line wrapping in the email client (Gmail's web
interface will wrap lines no matter what, so you need to use a real
IMAP client).
In case you are using OAuth2.0 authentication, it is easier to use credential
helpers to generate tokens. Credential helpers suggested in
linkgit:git-send-email[1] can be used for `git imap-send` as well.
CAUTION
-------
It is still your responsibility to make sure that the email message
sent by your email program meets the standards of your project.
Many projects do not like patches to be attached. Some mail
agents will transform patches (e.g. wrap lines, send them as
format=flowed) in ways that make them fail. You will get angry
flames ridiculing you if you don't check this.
Thunderbird in particular is known to be problematic. Thunderbird
users may wish to visit this web page for more information:
https://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird#Completely_plain_email
SEE ALSO
--------
linkgit:git-format-patch[1], linkgit:git-send-email[1], mbox(5)
GIT
---
Part of the linkgit:git[1] suite

163
app/src/main/assets/manpages/git-index-pack.txt Normal file
View File

@@ -0,0 +1,163 @@
git-index-pack(1)
=================
NAME
----
git-index-pack - Build pack index file for an existing packed archive
SYNOPSIS
--------
[verse]
'git index-pack' [-v] [-o <index-file>] [--[no-]rev-index] <pack-file>
'git index-pack' --stdin [--fix-thin] [--keep] [-v] [-o <index-file>]
[--[no-]rev-index] [<pack-file>]
DESCRIPTION
-----------
Reads a packed archive (.pack) from the specified file,
builds a pack index file (.idx) for it, and optionally writes a
reverse-index (.rev) for the specified pack. The packed
archive, together with the pack index, can then be placed in
the objects/pack/ directory of a Git repository.
OPTIONS
-------
-v::
Be verbose about what is going on, including progress status.
-o <index-file>::
Write the generated pack index into the specified
file. Without this option the name of pack index
file is constructed from the name of packed archive
file by replacing .pack with .idx (and the program
fails if the name of packed archive does not end
with .pack).
--rev-index::
--no-rev-index::
When this flag is provided, generate a reverse index
(a `.rev` file) corresponding to the given pack. If
`--verify` is given, ensure that the existing
reverse index is correct. Takes precedence over
`pack.writeReverseIndex`.
--stdin::
When this flag is provided, the pack is read from stdin
instead and a copy is then written to <pack-file>. If
<pack-file> is not specified, the pack is written to
objects/pack/ directory of the current Git repository with
a default name determined from the pack content. If
<pack-file> is not specified consider using --keep to
prevent a race condition between this process and
'git repack'.
--fix-thin::
Fix a "thin" pack produced by `git pack-objects --thin` (see
linkgit:git-pack-objects[1] for details) by adding the
excluded objects the deltified objects are based on to the
pack. This option only makes sense in conjunction with --stdin.
--keep::
Before moving the index into its final destination
create an empty .keep file for the associated pack file.
This option is usually necessary with --stdin to prevent a
simultaneous 'git repack' process from deleting
the newly constructed pack and index before refs can be
updated to use objects contained in the pack.
--keep=<msg>::
Like --keep, create a .keep file before moving the index into
its final destination. However, instead of creating an empty file
place '<msg>' followed by an LF into the .keep file. The '<msg>'
message can later be searched for within all .keep files to
locate any which have outlived their usefulness.
--index-version=<version>[,<offset>]::
This is intended to be used by the test suite only. It allows
to force the version for the generated pack index, and to force
64-bit index entries on objects located above the given offset.
--strict[=<msg-id>=<severity>...]::
Die, if the pack contains broken objects or links. An optional
comma-separated list of `<msg-id>=<severity>` can be passed to change
the severity of some possible issues, e.g.,
`--strict="missingEmail=ignore,badTagName=error"`. See the entry for the
`fsck.<msg-id>` configuration options in linkgit:git-fsck[1] for more
information on the possible values of `<msg-id>` and `<severity>`.
--progress-title::
For internal use only.
+
Set the title of the progress bar. The title is "Receiving objects" by
default and "Indexing objects" when `--stdin` is specified.
--check-self-contained-and-connected::
Die if the pack contains broken links. For internal use only.
--fsck-objects[=<msg-id>=<severity>...]::
Die if the pack contains broken objects, but unlike `--strict`, don't
choke on broken links. If the pack contains a tree pointing to a
.gitmodules blob that does not exist, prints the hash of that blob
(for the caller to check) after the hash that goes into the name of the
pack/idx file (see "Notes").
+
An optional comma-separated list of `<msg-id>=<severity>` can be passed to
change the severity of some possible issues, e.g.,
`--fsck-objects="missingEmail=ignore,badTagName=ignore"`. See the entry for the
`fsck.<msg-id>` configuration options in linkgit:git-fsck[1] for more
information on the possible values of `<msg-id>` and `<severity>`.
--threads=<n>::
Specifies the number of threads to spawn when resolving
deltas. This requires that index-pack be compiled with
pthreads otherwise this option is ignored with a warning.
This is meant to reduce packing time on multiprocessor
machines. The required amount of memory for the delta search
window is however multiplied by the number of threads.
Specifying 0 will cause Git to auto-detect the number of CPU's
and use maximum 3 threads.
--max-input-size=<size>::
Die, if the pack is larger than <size>.
--object-format=<hash-algorithm>::
Specify the given object format (hash algorithm) for the pack. The valid
values are 'sha1' and (if enabled) 'sha256'. The default is the algorithm for
the current repository (set by `extensions.objectFormat`), or 'sha1' if no
value is set or outside a repository.
+
This option cannot be used with --stdin.
+
include::object-format-disclaimer.adoc[]
--promisor[=<message>]::
Before committing the pack-index, create a .promisor file for this
pack. Particularly helpful when writing a promisor pack with --fix-thin
since the name of the pack is not final until the pack has been fully
written. If a `<message>` is provided, then that content will be
written to the .promisor file for future reference. See
link:technical/partial-clone.html[partial clone] for more information.
+
Also, if there are objects in the given pack that references non-promisor
objects (in the repo), repacks those non-promisor objects into a promisor
pack. This avoids a situation in which a repo has non-promisor objects that are
accessible through promisor objects.
+
Requires <pack-file> to not be specified.
NOTES
-----
Once the index has been created, the hash that goes into the name of
the pack/idx file is printed to stdout. If --stdin was
also used then this is prefixed by either "pack\t", or "keep\t" if a
new .keep file was successfully created. This is useful to remove a
.keep file used as a lock to prevent the race with 'git repack'
mentioned above.
GIT
---
Part of the linkgit:git[1] suite

23
app/src/main/assets/manpages/git-init-db.txt Normal file
View File

@@ -0,0 +1,23 @@
git-init-db(1)
==============
NAME
----
git-init-db - Creates an empty Git repository
SYNOPSIS
--------
[verse]
'git init-db' [-q | --quiet] [--bare] [--template=<template-directory>] [--separate-git-dir <git-dir>] [--shared[=<permissions>]]
DESCRIPTION
-----------
This is a synonym for linkgit:git-init[1]. Please refer to the
documentation of that command.
GIT
---
Part of the linkgit:git[1] suite

195
app/src/main/assets/manpages/git-init.txt Normal file
View File

@@ -0,0 +1,195 @@
git-init(1)
===========
NAME
----
git-init - Create an empty Git repository or reinitialize an existing one
SYNOPSIS
--------
[synopsis]
git init [-q | --quiet] [--bare] [--template=<template-directory>]
[--separate-git-dir <git-dir>] [--object-format=<format>]
[--ref-format=<format>]
[-b <branch-name> | --initial-branch=<branch-name>]
[--shared[=<permissions>]] [<directory>]
DESCRIPTION
-----------
This command creates an empty Git repository - basically a `.git`
directory with subdirectories for `objects`, `refs/heads`,
`refs/tags`, and template files. An initial branch without any
commits will be created (see the `--initial-branch` option below
for its name).
If the `GIT_DIR` environment variable is set then it specifies a path
to use instead of `./.git` for the base of the repository.
If the object storage directory is specified via the
`GIT_OBJECT_DIRECTORY` environment variable then the sha1 directories
are created underneath; otherwise, the default `$GIT_DIR/objects`
directory is used.
Running `git init` in an existing repository is safe. It will not
overwrite things that are already there. The primary reason for
rerunning `git init` is to pick up newly added templates (or to move
the repository to another place if `--separate-git-dir` is given).
OPTIONS
-------
`-q`::
`--quiet`::
Only print error and warning messages; all other output will be suppressed.
`--bare`::
Create a bare repository. If `GIT_DIR` environment is not set, it is set to the
current working directory.
`--object-format=<format>`::
Specify the given object _<format>_ (hash algorithm) for the repository. The valid
values are `sha1` and (if enabled) `sha256`. `sha1` is the default.
+
include::object-format-disclaimer.adoc[]
`--ref-format=<format>`::
Specify the given ref storage _<format>_ for the repository. The valid values are:
+
include::ref-storage-format.adoc[]
`--template=<template-directory>`::
Specify the directory from which templates will be used. (See the "TEMPLATE
DIRECTORY" section below.)
`--separate-git-dir=<git-dir>`::
Instead of initializing the repository as a directory to either `$GIT_DIR` or
`./.git/`, create a text file there containing the path to the actual
repository. This file acts as a filesystem-agnostic Git symbolic link to the
repository.
+
If this is a reinitialization, the repository will be moved to the specified path.
`-b <branch-name>`::
`--initial-branch=<branch-name>`::
Use _<branch-name>_ for the initial branch in the newly created
repository. If not specified, fall back to the default name
ifndef::with-breaking-changes[]
(currently `master`, but this will change to `main` when Git 3.0 is released).
endif::with-breaking-changes[]
ifdef::with-breaking-changes[]
`main`.
endif::with-breaking-changes[]
The default name can be customized via the `init.defaultBranch` configuration
variable.
`--shared[=(false|true|umask|group|all|world|everybody|<perm>)]`::
Specify that the Git repository is to be shared amongst several users. This
allows users belonging to the same group to push into that
repository. When specified, the config variable `core.sharedRepository` is
set so that files and directories under `$GIT_DIR` are created with the
requested permissions. When not specified, Git will use permissions reported
by `umask`(2).
+
The option can have the following values, defaulting to `group` if no value
is given:
+
--
`umask`::
`false`::
Use permissions reported by `umask`(2). The default, when `--shared` is not
specified.
`group`::
`true`::
Make the repository group-writable, (and `g+sx`, since the git group may not be
the primary group of all users). This is used to loosen the permissions of an
otherwise safe `umask`(2) value. Note that the umask still applies to the other
permission bits (e.g. if umask is `0022`, using `group` will not remove read
privileges from other (non-group) users). See `0xxx` for how to exactly specify
the repository permissions.
`all`::
`world`::
`everybody`::
Same as `group`, but make the repository readable by all users.
_<perm>_::
_<perm>_ is a 3-digit octal number prefixed with `0` and each file
will have mode _<perm>_. _<perm>_ will override users' `umask`(2)
value (and not only loosen permissions as `group` and `all`
do). `0640` will create a repository which is group-readable, but
not group-writable or accessible to others. `0660` will create a repo
that is readable and writable to the current user and group, but
inaccessible to others (directories and executable files get their
`x` bit from the `r` bit for corresponding classes of users).
--
By default, the configuration flag `receive.denyNonFastForwards` is enabled
in shared repositories, so that you cannot force a non fast-forwarding push
into it.
If you provide a _<directory>_, the command is run inside it. If this directory
does not exist, it will be created.
TEMPLATE DIRECTORY
------------------
Files and directories in the template directory whose name do not start with a
dot will be copied to the `$GIT_DIR` after it is created.
The template directory will be one of the following (in order):
- the argument given with the `--template` option;
- the contents of the `$GIT_TEMPLATE_DIR` environment variable;
- the `init.templateDir` configuration variable; or
- the default template directory: `/usr/share/git-core/templates`.
The default template directory includes some directory structure, suggested
"exclude patterns" (see linkgit:gitignore[5]), and sample hook files.
The sample hooks are all disabled by default. To enable one of the
sample hooks rename it by removing its `.sample` suffix.
See linkgit:githooks[5] for more general info on hook execution.
EXAMPLES
--------
Start a new Git repository for an existing code base::
+
----------------
$ cd /path/to/my/codebase
$ git init <1>
$ git add . <2>
$ git commit <3>
----------------
+
<1> Create a `/path/to/my/codebase/.git` directory.
<2> Add all existing files to the index.
<3> Record the pristine state as the first commit in the history.
CONFIGURATION
-------------
include::includes/cmd-config-section-all.adoc[]
:git-init:
include::config/init.adoc[]
GIT
---
Part of the linkgit:git[1] suite

94
app/src/main/assets/manpages/git-instaweb.txt Normal file
View File

@@ -0,0 +1,94 @@
git-instaweb(1)
===============
NAME
----
git-instaweb - Instantly browse your working repository in gitweb
SYNOPSIS
--------
[verse]
'git instaweb' [--local] [--httpd=<httpd>] [--port=<port>]
[--browser=<browser>]
'git instaweb' [--start] [--stop] [--restart]
DESCRIPTION
-----------
A simple script to set up `gitweb` and a web server for browsing the local
repository.
OPTIONS
-------
-l::
--local::
Only bind the web server to the local IP (127.0.0.1).
-d::
--httpd::
The HTTP daemon command-line that will be executed.
Command-line options may be specified here, and the
configuration file will be added at the end of the command-line.
Currently apache2, lighttpd, mongoose, plackup, python and
webrick are supported.
(Default: lighttpd)
-m::
--module-path::
The module path (only needed if httpd is Apache).
(Default: /usr/lib/apache2/modules)
-p::
--port::
The port number to bind the httpd to. (Default: 1234)
-b::
--browser::
The web browser that should be used to view the gitweb
page. This will be passed to the 'git web{litdd}browse' helper
script along with the URL of the gitweb instance. See
linkgit:git-web{litdd}browse[1] for more information about this. If
the script fails, the URL will be printed to stdout.
start::
--start::
Start the httpd instance and exit. Regenerate configuration files
as necessary for spawning a new instance.
stop::
--stop::
Stop the httpd instance and exit. This does not generate
any of the configuration files for spawning a new instance,
nor does it close the browser.
restart::
--restart::
Restart the httpd instance and exit. Regenerate configuration files
as necessary for spawning a new instance.
CONFIGURATION
-------------
You may specify configuration in your .git/config
-----------------------------------------------------------------------
[instaweb]
local = true
httpd = apache2 -f
port = 4321
browser = konqueror
modulePath = /usr/lib/apache2/modules
-----------------------------------------------------------------------
If the configuration variable `instaweb.browser` is not set,
`web.browser` will be used instead if it is defined. See
linkgit:git-web{litdd}browse[1] for more information about this.
SEE ALSO
--------
linkgit:gitweb[1]
GIT
---
Part of the linkgit:git[1] suite

411
app/src/main/assets/manpages/git-interpret-trailers.txt Normal file
View File

@@ -0,0 +1,411 @@
git-interpret-trailers(1)
=========================
NAME
----
git-interpret-trailers - Add or parse structured information in commit messages
SYNOPSIS
--------
[synopsis]
git interpret-trailers [--in-place] [--trim-empty]
[(--trailer (<key>|<key-alias>)[(=|:)<value>])...]
[--parse] [<file>...]
DESCRIPTION
-----------
Add or parse _trailer_ lines that look similar to RFC 822 e-mail
headers, at the end of the otherwise free-form part of a commit
message. For example, in the following commit message
------------------------------------------------
subject
Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Signed-off-by: Alice <alice@example.com>
Signed-off-by: Bob <bob@example.com>
------------------------------------------------
the last two lines starting with `Signed-off-by` are trailers.
This command reads commit messages from either the
_<file>_ arguments or the standard input if no _<file>_ is specified.
If `--parse` is specified, the output consists of the parsed trailers
coming from the input, without influencing them with any command line
options or configuration variables.
Otherwise, this command applies `trailer.<key-alias>` configuration
variables (which could potentially add new trailers, as well as
reposition them), as well as any command line arguments that can
override configuration variables (such as `--trailer=...` which could
also add new trailers), to each input file. The result is emitted on the
standard output.
This command can also operate on the output of linkgit:git-format-patch[1],
which is more elaborate than a plain commit message. Namely, such output
includes a commit message (as above), a `---` divider line, and a patch part.
For these inputs, the divider and patch parts are not modified by
this command and are emitted as is on the output, unless
`--no-divider` is specified.
Some configuration variables control the way the `--trailer` arguments
are applied to each input and the way any existing trailer in
the input is changed. They also make it possible to
automatically add some trailers.
By default, a `<key>=<value>` or `<key>:<value>` argument given
using `--trailer` will be appended after the existing trailers only if
the last trailer has a different (_<key>_, _<value>_) pair (or if there
is no existing trailer). The _<key>_ and _<value>_ parts will be trimmed
to remove starting and trailing whitespace, and the resulting trimmed
_<key>_ and _<value>_ will appear in the output like this:
------------------------------------------------
key: value
------------------------------------------------
This means that the trimmed _<key>_ and _<value>_ will be separated by
"`:`{nbsp}" (one colon followed by one space).
For convenience, a _<key-alias>_ can be configured to make using `--trailer`
shorter to type on the command line. This can be configured using the
`trailer.<key-alias>.key` configuration variable. The _<key-alias>_ must be a prefix
of the full _<key>_ string, although case sensitivity does not matter. For
example, if you have
------------------------------------------------
trailer.sign.key "Signed-off-by: "
------------------------------------------------
in your configuration, you only need to specify `--trailer="sign: foo"`
on the command line instead of `--trailer="Signed-off-by: foo"`.
By default the new trailer will appear at the end of all the existing
trailers. If there is no existing trailer, the new trailer will appear
at the end of the input. A blank line will be added before the new
trailer if there isn't one already.
Existing trailers are extracted from the input by looking for
a group of one or more lines that (i) is all trailers, or (ii) contains at
least one Git-generated or user-configured trailer and consists of at
least 25% trailers.
The group must be preceded by one or more empty (or whitespace-only) lines.
The group must either be at the end of the input or be the last
non-whitespace lines before a line that starts with `---` (followed by a
space or the end of the line).
When reading trailers, there can be no whitespace before or inside the
_<key>_, but any number of regular space and tab characters are allowed
between the _<key>_ and the separator. There can be whitespaces before,
inside or after the _<value>_. The _<value>_ may be split over multiple lines
with each subsequent line starting with at least one whitespace, like
the "folding" in RFC 822. Example:
------------------------------------------------
key: This is a very long value, with spaces and
newlines in it.
------------------------------------------------
Note that trailers do not follow (nor are they intended to follow) many of the
rules for RFC 822 headers. For example they do not follow the encoding rule.
OPTIONS
-------
`--in-place`::
`--no-in-place`::
Edit the files in place. The default is `--no-in-place`.
`--trim-empty`::
`--no-trim-empty`::
If the _<value>_ part of any trailer contains only whitespace,
the whole trailer will be removed from the output.
This applies to existing trailers as well as new trailers.
+
The default is `--no-trim-empty`.
`--trailer=<key>[(=|:)<value>]`::
`--no-trailer`::
Specify a (_<key>_, _<value>_) pair that should be applied as a
trailer to the inputs. See the description of this command. Can
be given multiple times.
+
Use `--no-trailer` to reset the list.
`--where=<placement>`::
`--no-where`::
Specify where all new trailers will be added. A setting
provided with `--where` overrides the `trailer.where` and any
applicable `trailer.<key-alias>.where` configuration variables
and applies to all `--trailer` options until the next occurrence of
`--where` or `--no-where`. Possible placements are `after`,
`before`, `end` or `start`.
+
Use `--no-where` to clear the effect of any previous use of `--where`,
such that the relevant configuration variables are no longer overridden.
`--if-exists=<action>`::
`--no-if-exists`::
Specify what action will be performed when there is already at
least one trailer with the same _<key>_ in the input. A setting
provided with `--if-exists` overrides the `trailer.ifExists` and any
applicable `trailer.<key-alias>.ifExists` configuration variables
and applies to all `--trailer` options until the next occurrence of
`--if-exists` or `--no-if-exists`. Possible actions are `addIfDifferent`,
`addIfDifferentNeighbor`, `add`, `replace` and `doNothing`.
+
Use `--no-if-exists` to clear the effect of any previous use of
`--if-exists`, such that the relevant configuration variables are no
longer overridden.
`--if-missing=<action>`::
`--no-if-missing`::
Specify what action will be performed when there is no other
trailer with the same _<key>_ in the input. A setting
provided with `--if-missing` overrides the `trailer.ifMissing` and any
applicable `trailer.<key-alias>.ifMissing` configuration variables
and applies to all `--trailer` options until the next occurrence of
`--if-missing` or `--no-if-missing`. Possible actions are
`doNothing` or `add`.
+
Use `--no-if-missing` to clear the effect of any previous use of
`--if-missing`, such that the relevant configuration variables are no
longer overridden.
`--only-trailers`::
`--no-only-trailers`::
Output only the trailers, not any other parts of the
input. The default is `--no-only-trailers`.
`--only-input`::
`--no-only-input`::
Output only trailers that exist in the input; do not add any
from the command-line or by applying `trailer.<key-alias>` configuration
variables. The default is `--no-only-input`.
`--unfold`::
`--no-unfold`::
If a trailer has a value that runs over multiple lines (aka "folded"),
reformat the value into a single line. The default is `--no-unfold`.
`--parse`::
A convenience alias for `--only-trailers --only-input
--unfold`. This makes it easier to only see the trailers coming from the
input without influencing them with any command line options or
configuration variables, while also making the output machine-friendly with
`--unfold`.
+
There is no convenience alias to negate this alias.
`--divider`::
`--no-divider`::
Treat `---` as the end of the commit message. This is the default.
Use `--no-divider` when you know your input contains just the
commit message itself (and not an email or the output of
linkgit:git-format-patch[1]).
CONFIGURATION VARIABLES
-----------------------
include::includes/cmd-config-section-all.adoc[]
include::config/trailer.adoc[]
EXAMPLES
--------
* Configure a `sign` trailer with a `Signed-off-by` key, and then
add two of these trailers to a commit message file:
+
------------
$ git config trailer.sign.key "Signed-off-by"
$ cat msg.txt
subject
body text
$ git interpret-trailers --trailer 'sign: Alice <alice@example.com>' --trailer 'sign: Bob <bob@example.com>' <msg.txt
subject
body text
Signed-off-by: Alice <alice@example.com>
Signed-off-by: Bob <bob@example.com>
------------
* Use the `--in-place` option to edit a commit message file in place:
+
------------
$ cat msg.txt
subject
body text
Signed-off-by: Bob <bob@example.com>
$ git interpret-trailers --trailer 'Acked-by: Alice <alice@example.com>' --in-place msg.txt
$ cat msg.txt
subject
body text
Signed-off-by: Bob <bob@example.com>
Acked-by: Alice <alice@example.com>
------------
* Extract the last commit as a patch, and add a `Cc` and a
`Reviewed-by` trailer to it:
+
------------
$ git format-patch -1
0001-foo.patch
$ git interpret-trailers --trailer 'Cc: Alice <alice@example.com>' --trailer 'Reviewed-by: Bob <bob@example.com>' 0001-foo.patch >0001-bar.patch
------------
* Configure a `sign` trailer with a command to automatically add a
"`Signed-off-by:`{nbsp}" with the author information only if there is no
"`Signed-off-by:`{nbsp}" already, and show how it works:
+
------------
$ cat msg1.txt
subject
body text
$ git config trailer.sign.key "Signed-off-by: "
$ git config trailer.sign.ifmissing add
$ git config trailer.sign.ifexists doNothing
$ git config trailer.sign.cmd 'echo "$(git config user.name) <$(git config user.email)>"'
$ git interpret-trailers --trailer sign <msg1.txt
subject
body text
Signed-off-by: Bob <bob@example.com>
$ cat msg2.txt
subject
body text
Signed-off-by: Alice <alice@example.com>
$ git interpret-trailers --trailer sign <msg2.txt
subject
body text
Signed-off-by: Alice <alice@example.com>
------------
* Configure a `fix` trailer with a key that contains a `#` and no
space after this character, and show how it works:
+
------------
$ git config trailer.separators ":#"
$ git config trailer.fix.key "Fix #"
$ echo "subject" | git interpret-trailers --trailer fix=42
subject
Fix #42
------------
* Configure a `help` trailer with a cmd use a script `glog-find-author`
which search specified author identity from git log in git repository
and show how it works:
+
------------
$ cat ~/bin/glog-find-author
#!/bin/sh
test -n "$1" && git log --author="$1" --pretty="%an <%ae>" -1 || true
$ cat msg.txt
subject
body text
$ git config trailer.help.key "Helped-by: "
$ git config trailer.help.ifExists "addIfDifferentNeighbor"
$ git config trailer.help.cmd "~/bin/glog-find-author"
$ git interpret-trailers --trailer="help:Junio" --trailer="help:Couder" <msg.txt
subject
body text
Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Christian Couder <christian.couder@gmail.com>
------------
* Configure a `ref` trailer with a cmd use a script `glog-grep`
to grep last relevant commit from git log in the git repository
and show how it works:
+
------------
$ cat ~/bin/glog-grep
#!/bin/sh
test -n "$1" && git log --grep "$1" --pretty=reference -1 || true
$ cat msg.txt
subject
body text
$ git config trailer.ref.key "Reference-to: "
$ git config trailer.ref.ifExists "replace"
$ git config trailer.ref.cmd "~/bin/glog-grep"
$ git interpret-trailers --trailer="ref:Add copyright notices." <msg.txt
subject
body text
Reference-to: 8bc9a0c769 (Add copyright notices., 2005-04-07)
------------
* Configure a `see` trailer with a command to show the subject of a
commit that is related, and show how it works:
+
------------
$ cat msg.txt
subject
body text
see: HEAD~2
$ cat ~/bin/glog-ref
#!/bin/sh
git log -1 --oneline --format="%h (%s)" --abbrev-commit --abbrev=14
$ git config trailer.see.key "See-also: "
$ git config trailer.see.ifExists "replace"
$ git config trailer.see.ifMissing "doNothing"
$ git config trailer.see.cmd "glog-ref"
$ git interpret-trailers --trailer=see <msg.txt
subject
body text
See-also: fe3187489d69c4 (subject of related commit)
------------
* Configure a commit template with some trailers with empty values
(using sed to show and keep the trailing spaces at the end of the
trailers), then configure a commit-msg hook that uses
git-interpret-trailers(1) to remove trailers with empty values and to
add a `git-version` trailer:
+
------------
$ cat temp.txt
***subject***
***message***
Fixes: Z
Cc: Z
Reviewed-by: Z
Signed-off-by: Z
$ sed -e 's/ Z$/ /' temp.txt > commit_template.txt
$ git config commit.template commit_template.txt
$ cat .git/hooks/commit-msg
#!/bin/sh
git interpret-trailers --trim-empty --trailer "git-version: \$(git describe)" "\$1" > "\$1.new"
mv "\$1.new" "\$1"
$ chmod +x .git/hooks/commit-msg
------------
SEE ALSO
--------
linkgit:git-commit[1], linkgit:git-format-patch[1], linkgit:git-config[1]
GIT
---
Part of the linkgit:git[1] suite

81
app/src/main/assets/manpages/git-last-modified.txt Normal file
View File

@@ -0,0 +1,81 @@
git-last-modified(1)
====================
NAME
----
git-last-modified - EXPERIMENTAL: Show when files were last modified
SYNOPSIS
--------
[synopsis]
git last-modified [--recursive] [--show-trees] [--max-depth=<depth>] [-z]
[<revision-range>] [[--] <pathspec>...]
DESCRIPTION
-----------
Shows which commit last modified each of the relevant files and subdirectories.
A commit renaming a path, or changing it's mode is also taken into account.
THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
OPTIONS
-------
`-r`::
`--recursive`::
Recursively traverse into all subtrees. By default, the command only
shows tree entries matching the `<pathspec>`. With this option, it
descends into subtrees and displays all entries within them.
Equivalent to `--max-depth=-1`.
`-t`::
`--show-trees`::
Show tree entries even when recursing into them.
`--max-depth=<depth>`::
For each pathspec given on the command line, traverse at most `<depth>`
levels into subtrees. A negative value means no limit.
The default is 0, which shows all paths matching the pathspec
without descending into subtrees.
`-z`::
Terminate each line with a _NUL_ character rather than a newline.
`<revision-range>`::
Only traverse commits in the specified revision range. When no
`<revision-range>` is specified, it defaults to `HEAD` (i.e. the whole
history leading to the current commit). For a complete list of ways to
spell `<revision-range>`, see the 'Specifying Ranges' section of
linkgit:gitrevisions[7].
`[--] <pathspec>...`::
Show the commit that last modified each path matching _<pathspec>_.
If no _<pathspec>_ is given, all files and subdirectories are included.
See linkgit:gitglossary[7] for details on pathspec syntax.
OUTPUT
------
The output is in the format:
------------
<oid> TAB <path> LF
------------
If a path contains any special characters, the path is C-style quoted. To
avoid quoting, pass option `-z` to terminate each line with a NUL.
------------
<oid> TAB <path> NUL
------------
SEE ALSO
--------
linkgit:git-blame[1],
linkgit:git-log[1].
GIT
---
Part of the linkgit:git[1] suite

228
app/src/main/assets/manpages/git-log.txt Normal file
View File

@@ -0,0 +1,228 @@
git-log(1)
==========
NAME
----
git-log - Show commit logs
SYNOPSIS
--------
[synopsis]
git log [<options>] [<revision-range>] [[--] <path>...]
DESCRIPTION
-----------
Shows the commit logs.
:git-log: 1
include::rev-list-description.adoc[]
The command takes options applicable to the linkgit:git-rev-list[1]
command to control what is shown and how, and options applicable to
the linkgit:git-diff[1] command to control how the changes
each commit introduces are shown.
OPTIONS
-------
`--follow`::
Continue listing the history of a file beyond renames
(works only for a single file).
`--no-decorate`::
`--decorate[=(short|full|auto|no)]`::
Print out the ref names of any commits that are shown. Possible values
are:
+
----
`short`;; the ref name prefixes `refs/heads/`, `refs/tags/` and
`refs/remotes/` are not printed.
`full`;; the full ref name (including prefix) is printed.
`auto`:: if the output is going to a terminal, the ref names
are shown as if `short` were given, otherwise no ref names are
shown.
----
+
The option `--decorate` is short-hand for `--decorate=short`. Default to
configuration value of `log.decorate` if configured, otherwise, `auto`.
`--decorate-refs=<pattern>`::
`--decorate-refs-exclude=<pattern>`::
For each candidate reference, do not use it for decoration if it
matches any of the _<pattern>_ parameters given to
`--decorate-refs-exclude` or if it doesn't match any of the
_<pattern>_ parameters given to `--decorate-refs`.
The `log.excludeDecoration` config option allows excluding refs from
the decorations, but an explicit `--decorate-refs` pattern will
override a match in `log.excludeDecoration`.
+
If none of these options or config settings are given, then references are
used as decoration if they match `HEAD`, `refs/heads/`, `refs/remotes/`,
`refs/stash/`, or `refs/tags/`.
`--clear-decorations`::
When specified, this option clears all previous `--decorate-refs`
or `--decorate-refs-exclude` options and relaxes the default
decoration filter to include all references. This option is
assumed if the config value `log.initialDecorationSet` is set to
`all`.
`--source`::
Print out the ref name given on the command line by which each
commit was reached.
`--mailmap`::
`--no-mailmap`::
`--use-mailmap`::
`--no-use-mailmap`::
Use mailmap file to map author and committer names and email
addresses to canonical real names and email addresses. See
linkgit:git-shortlog[1].
`--full-diff`::
Without this flag, `git log -p <path>...` shows commits that
touch the specified paths, and diffs about the same specified
paths. With this, the full diff is shown for commits that touch
the specified paths; this means that "`<path>...`" limits only
commits, and doesn't limit diff for those commits.
+
Note that this affects all diff-based output types, e.g. those
produced by `--stat`, etc.
`--log-size`::
Include a line `log size <number>` in the output for each commit,
where _<number>_ is the length of that commit's message in bytes.
Intended to speed up tools that read log messages from `git log`
output by allowing them to allocate space in advance.
include::line-range-options.adoc[]
_<revision-range>_::
Show only commits in the specified revision range. When no
_<revision-range>_ is specified, it defaults to `HEAD` (i.e. the
whole history leading to the current commit). `origin..HEAD`
specifies all the commits reachable from the current commit
(i.e. `HEAD`), but not from `origin`. For a complete list of
ways to spell _<revision-range>_, see the 'Specifying Ranges'
section of linkgit:gitrevisions[7].
`[--] <path>...`::
Show only commits that are enough to explain how the files
that match the specified paths came to be. See 'History
Simplification' below for details and other simplification
modes.
+
Paths may need to be prefixed with `--` to separate them from
options or the revision range, when confusion arises.
include::rev-list-options.adoc[]
include::pretty-formats.adoc[]
DIFF FORMATTING
---------------
By default, `git log` does not generate any diff output. The options
below can be used to show the changes made by each commit.
Note that unless one of `--diff-merges` variants (including short
`-m`, `-c`, `--cc`, and `--dd` options) is explicitly given, merge commits
will not show a diff, even if a diff format like `--patch` is
selected, nor will they match search options like `-S`. The exception
is when `--first-parent` is in use, in which case `first-parent` is
the default format for merge commits.
:git-log: 1
:diff-merges-default: `off`
include::diff-options.adoc[]
include::diff-generate-patch.adoc[]
EXAMPLES
--------
`git log --no-merges`::
Show the whole commit history, but skip any merges
`git log v2.6.12.. include/scsi drivers/scsi`::
Show all commits since version 'v2.6.12' that changed any file
in the `include/scsi` or `drivers/scsi` subdirectories
`git log --since="2 weeks ago" -- gitk`::
Show the changes during the last two weeks to the file `gitk`.
The `--` is necessary to avoid confusion with the *branch* named
`gitk`
`git log --name-status release..test`::
Show the commits that are in the "`test`" branch but not yet
in the "`release`" branch, along with the list of paths
each commit modifies.
`git log --follow builtin/rev-list.c`::
Shows the commits that changed `builtin/rev-list.c`, including
those commits that occurred before the file was given its
present name.
`git log --branches --not --remotes=origin`::
Shows all commits that are in any of local branches but not in
any of remote-tracking branches for `origin` (what you have that
origin doesn't).
`git log master --not --remotes=*/master`::
Shows all commits that are in local master but not in any remote
repository master branches.
`git log -p -m --first-parent`::
Shows the history including change diffs, but only from the
``main branch'' perspective, skipping commits that come from merged
branches, and showing full diffs of changes introduced by the merges.
This makes sense only when following a strict policy of merging all
topic branches when staying on a single integration branch.
`git log -L '/int main/',/^}/:main.c`::
Shows how the function `main()` in the file `main.c` evolved
over time.
`git log -3`::
Limits the number of commits to show to 3.
DISCUSSION
----------
include::i18n.adoc[]
CONFIGURATION
-------------
See linkgit:git-config[1] for core variables and linkgit:git-diff[1]
for settings related to diff generation.
`format.pretty`::
Default for the `--format` option. (See 'Pretty Formats' above.)
Defaults to `medium`.
`i18n.logOutputEncoding`::
Encoding to use when displaying logs. (See 'Discussion' above.)
Defaults to the value of `i18n.commitEncoding` if set, and UTF-8
otherwise.
include::includes/cmd-config-section-rest.adoc[]
include::config/log.adoc[]
include::config/notes.adoc[]
GIT
---
Part of the linkgit:git[1] suite

344
app/src/main/assets/manpages/git-ls-files.txt Normal file
View File

@@ -0,0 +1,344 @@
git-ls-files(1)
===============
NAME
----
git-ls-files - Show information about files in the index and the working tree
SYNOPSIS
--------
[verse]
'git ls-files' [-z] [-t] [-v] [-f]
[-c|--cached] [-d|--deleted] [-o|--others] [-i|--ignored]
[-s|--stage] [-u|--unmerged] [-k|--killed] [-m|--modified]
[--resolve-undo]
[--directory [--no-empty-directory]] [--eol]
[--deduplicate]
[-x <pattern>|--exclude=<pattern>]
[-X <file>|--exclude-from=<file>]
[--exclude-per-directory=<file>]
[--exclude-standard]
[--error-unmatch] [--with-tree=<tree-ish>]
[--full-name] [--recurse-submodules]
[--abbrev[=<n>]] [--format=<format>] [--] [<file>...]
DESCRIPTION
-----------
This command merges the file listing in the index with the actual working
directory list, and shows different combinations of the two.
Several flags can be used to determine which files are
shown, and each file may be printed multiple times if there are
multiple entries in the index or if multiple statuses are applicable for
the relevant file selection options.
OPTIONS
-------
-c::
--cached::
Show all files cached in Git's index, i.e. all tracked files.
(This is the default if no -c/-s/-d/-o/-u/-k/-m/--resolve-undo
options are specified.)
-d::
--deleted::
Show files with an unstaged deletion
-m::
--modified::
Show files with an unstaged modification (note that an unstaged
deletion also counts as an unstaged modification)
-o::
--others::
Show other (i.e. untracked) files in the output
-i::
--ignored::
Show only ignored files in the output. Must be used with
either an explicit '-c' or '-o'. When showing files in the
index (i.e. when used with '-c'), print only those files
matching an exclude pattern. When showing "other" files
(i.e. when used with '-o'), show only those matched by an
exclude pattern. Standard ignore rules are not automatically
activated; therefore, at least one of the `--exclude*` options
is required.
-s::
--stage::
Show staged contents' mode bits, object name and stage number in the output.
--directory::
If a whole directory is classified as "other", show just its
name (with a trailing slash) and not its whole contents.
Has no effect without -o/--others.
--no-empty-directory::
Do not list empty directories. Has no effect without --directory.
-u::
--unmerged::
Show information about unmerged files in the output, but do
not show any other tracked files (forces --stage, overrides
--cached).
-k::
--killed::
Show untracked files on the filesystem that need to be removed
due to file/directory conflicts for tracked files to be able to
be written to the filesystem.
--resolve-undo::
Show files having resolve-undo information in the index
together with their resolve-undo information. (resolve-undo
information is what is used to implement "git checkout -m
$PATH", i.e. to recreate merge conflicts that were
accidentally resolved)
-z::
\0 line termination on output and do not quote filenames.
See OUTPUT below for more information.
--deduplicate::
When only filenames are shown, suppress duplicates that may
come from having multiple stages during a merge, or giving
`--deleted` and `--modified` option at the same time.
When any of the `-t`, `--unmerged`, or `--stage` option is
in use, this option has no effect.
-x <pattern>::
--exclude=<pattern>::
Skip untracked files matching pattern.
Note that pattern is a shell wildcard pattern. See EXCLUDE PATTERNS
below for more information.
-X <file>::
--exclude-from=<file>::
Read exclude patterns from <file>; 1 per line.
--exclude-per-directory=<file>::
Read additional exclude patterns that apply only to the
directory and its subdirectories in <file>. If you are
trying to emulate the way Porcelain commands work, using
the `--exclude-standard` option instead is easier and more
thorough.
--exclude-standard::
Add the standard Git exclusions: .git/info/exclude, .gitignore
in each directory, and the user's global exclusion file.
--error-unmatch::
If any <file> does not appear in the index, treat this as an
error (return 1).
--with-tree=<tree-ish>::
When using --error-unmatch to expand the user supplied
<file> (i.e. path pattern) arguments to paths, pretend
that paths which were removed in the index since the
named <tree-ish> are still present. Using this option
with `-s` or `-u` options does not make any sense.
-t::
Show status tags together with filenames. Note that for
scripting purposes, linkgit:git-status[1] `--porcelain` and
linkgit:git-diff-files[1] `--name-status` are almost always
superior alternatives; users should look at
linkgit:git-status[1] `--short` or linkgit:git-diff[1]
`--name-status` for more user-friendly alternatives.
+
--
This option provides a reason for showing each filename, in the form
of a status tag (which is followed by a space and then the filename).
The status tags are all single characters from the following list:
H:: tracked file that is not either unmerged or skip-worktree
S:: tracked file that is skip-worktree
M:: tracked file that is unmerged
R:: tracked file with unstaged removal/deletion
C:: tracked file with unstaged modification/change
K:: untracked paths which are part of file/directory conflicts
which prevent checking out tracked files
?:: untracked file
U:: file with resolve-undo information
--
-v::
Similar to `-t`, but use lowercase letters for files
that are marked as 'assume unchanged' (see
linkgit:git-update-index[1]).
-f::
Similar to `-t`, but use lowercase letters for files
that are marked as 'fsmonitor valid' (see
linkgit:git-update-index[1]).
--full-name::
When run from a subdirectory, the command usually
outputs paths relative to the current directory. This
option forces paths to be output relative to the project
top directory.
--recurse-submodules::
Recursively calls ls-files on each active submodule in the repository.
Currently there is only support for the --cached and --stage modes.
--abbrev[=<n>]::
Instead of showing the full 40-byte hexadecimal object
lines, show the shortest prefix that is at least '<n>'
hexdigits long that uniquely refers the object.
Non default number of digits can be specified with --abbrev=<n>.
--debug::
After each line that describes a file, add more data about its
cache entry. This is intended to show as much information as
possible for manual inspection; the exact format may change at
any time.
--eol::
Show <eolinfo> and <eolattr> of files.
<eolinfo> is the file content identification used by Git when
the "text" attribute is "auto" (or not set and core.autocrlf is not false).
<eolinfo> is either "-text", "none", "lf", "crlf", "mixed" or "".
+
"" means the file is not a regular file, it is not in the index or
not accessible in the working tree.
+
<eolattr> is the attribute that is used when checking out or committing,
it is either "", "-text", "text", "text=auto", "text eol=lf", "text eol=crlf".
Since Git 2.10 "text=auto eol=lf" and "text=auto eol=crlf" are supported.
+
Both the <eolinfo> in the index ("i/<eolinfo>")
and in the working tree ("w/<eolinfo>") are shown for regular files,
followed by the ("attr/<eolattr>").
--sparse::
If the index is sparse, show the sparse directories without expanding
to the contained files. Sparse directories will be shown with a
trailing slash, such as "x/" for a sparse directory "x".
--format=<format>::
A string that interpolates `%(fieldname)` from the result being shown.
It also interpolates `%%` to `%`, and `%xXX` where `XX` are hex digits
interpolates to character with hex code `XX`; for example `%x00`
interpolates to `\0` (NUL), `%x09` to `\t` (TAB) and %x0a to `\n` (LF).
--format cannot be combined with `-s`, `-o`, `-k`, `-t`, `--resolve-undo`
and `--eol`.
\--::
Do not interpret any more arguments as options.
<file>::
Files to show. If no files are given all files which match the other
specified criteria are shown.
OUTPUT
------
'git ls-files' just outputs the filenames unless `--stage` is specified in
which case it outputs:
[<tag> ]<mode> <object> <stage> <file>
'git ls-files --eol' will show
i/<eolinfo><SPACES>w/<eolinfo><SPACES>attr/<eolattr><SPACE*><TAB><file>
'git ls-files --unmerged' and 'git ls-files --stage' can be used to examine
detailed information on unmerged paths.
For an unmerged path, instead of recording a single mode/SHA-1 pair,
the index records up to three such pairs; one from tree O in stage
1, A in stage 2, and B in stage 3. This information can be used by
the user (or the porcelain) to see what should eventually be recorded at the
path. (see linkgit:git-read-tree[1] for more information on state)
Without the `-z` option, pathnames with "unusual" characters are
quoted as explained for the configuration variable `core.quotePath`
(see linkgit:git-config[1]). Using `-z` the filename is output
verbatim and the line is terminated by a NUL byte.
It is possible to print in a custom format by using the `--format`
option, which is able to interpolate different fields using
a `%(fieldname)` notation. For example, if you only care about the
"objectname" and "path" fields, you can execute with a specific
"--format" like
git ls-files --format='%(objectname) %(path)'
FIELD NAMES
-----------
The way each path is shown can be customized by using the
`--format=<format>` option, where the %(fieldname) in the
<format> string for various aspects of the index entry are
interpolated. The following "fieldname" are understood:
objectmode::
The mode of the file which is recorded in the index.
objecttype::
The object type of the file which is recorded in the index.
objectname::
The name of the file which is recorded in the index.
objectsize[:padded]::
The object size of the file which is recorded in the index
("-" if the object is a `commit` or `tree`).
It also supports a padded format of size with "%(objectsize:padded)".
stage::
The stage of the file which is recorded in the index.
eolinfo:index::
eolinfo:worktree::
The <eolinfo> (see the description of the `--eol` option) of
the contents in the index or in the worktree for the path.
eolattr::
The <eolattr> (see the description of the `--eol` option)
that applies to the path.
path::
The pathname of the file which is recorded in the index.
EXCLUDE PATTERNS
----------------
'git ls-files' can use a list of "exclude patterns" when
traversing the directory tree and finding files to show when the
flags --others or --ignored are specified. linkgit:gitignore[5]
specifies the format of exclude patterns.
These exclude patterns can be specified from the following places,
in order:
1. The command-line flag --exclude=<pattern> specifies a
single pattern. Patterns are ordered in the same order
they appear in the command line.
2. The command-line flag --exclude-from=<file> specifies a
file containing a list of patterns. Patterns are ordered
in the same order they appear in the file.
3. The command-line flag --exclude-per-directory=<name> specifies
a name of the file in each directory 'git ls-files'
examines, normally `.gitignore`. Files in deeper
directories take precedence. Patterns are ordered in the
same order they appear in the files.
A pattern specified on the command line with --exclude or read
from the file specified with --exclude-from is relative to the
top of the directory tree. A pattern read from a file specified
by --exclude-per-directory is relative to the directory that the
pattern file appears in.
Generally, you should be able to use `--exclude-standard` when you
want the exclude rules applied the same way as what Porcelain
commands do. To emulate what `--exclude-standard` specifies, you
can give `--exclude-per-directory=.gitignore`, and then specify:
1. The file specified by the `core.excludesfile` configuration
variable, if exists, or the `$XDG_CONFIG_HOME/git/ignore` file.
2. The `$GIT_DIR/info/exclude` file.
via the `--exclude-from=` option.
SEE ALSO
--------
linkgit:git-read-tree[1], linkgit:gitignore[5]
GIT
---
Part of the linkgit:git[1] suite

157
app/src/main/assets/manpages/git-ls-remote.txt Normal file
View File

@@ -0,0 +1,157 @@
git-ls-remote(1)
================
NAME
----
git-ls-remote - List references in a remote repository
SYNOPSIS
--------
[verse]
'git ls-remote' [--branches] [--tags] [--refs] [--upload-pack=<exec>]
[-q | --quiet] [--exit-code] [--get-url] [--sort=<key>]
[--symref] [<repository> [<patterns>...]]
DESCRIPTION
-----------
Displays references available in a remote repository along with the associated
commit IDs.
OPTIONS
-------
-b::
--branches::
-t::
--tags::
Limit to only local branches and local tags, respectively.
These options are _not_ mutually exclusive; when given
both, references stored in refs/heads and refs/tags are
displayed. Note that `--heads` and `-h` are deprecated
synonyms for `--branches` and `-b` and may be removed in
the future. Also note that `git ls-remote -h` used without
anything else on the command line gives help, consistent
with other git subcommands.
--refs::
Do not show peeled tags or pseudorefs like `HEAD` in the output.
-q::
--quiet::
Do not print remote URL to stderr.
--upload-pack=<exec>::
Specify the full path of 'git-upload-pack' on the remote
host. This allows listing references from repositories accessed via
SSH and where the SSH daemon does not use the PATH configured by the
user.
--exit-code::
Exit with status "2" when no matching refs are found in the remote
repository. Usually the command exits with status "0" to indicate
it successfully talked with the remote repository, whether it
found any matching refs.
--get-url::
Expand the URL of the given remote repository taking into account any
"url.<base>.insteadOf" config setting (See linkgit:git-config[1]) and
exit without talking to the remote.
--symref::
In addition to the object pointed by it, show the underlying
ref pointed by it when showing a symbolic ref. Currently,
upload-pack only shows the symref HEAD, so it will be the only
one shown by ls-remote.
--sort=<key>::
Sort based on the key given. Prefix `-` to sort in descending order
of the value. Supports "version:refname" or "v:refname" (tag names
are treated as versions). The "version:refname" sort order can also
be affected by the "versionsort.suffix" configuration variable.
See linkgit:git-for-each-ref[1] for more sort options, but be aware
keys like `committerdate` that require access to the objects
themselves will not work for refs whose objects have not yet been
fetched from the remote, and will give a `missing object` error.
-o <option>::
--server-option=<option>::
Transmit the given string to the server when communicating using
protocol version 2. The given string must not contain a NUL or LF
character.
When multiple `--server-option=<option>` are given, they are all
sent to the other side in the order listed on the command line.
When no `--server-option=<option>` is given from the command line,
the values of configuration variable `remote.<name>.serverOption`
are used instead.
<repository>::
The "remote" repository to query. This parameter can be
either a URL or the name of a remote (see the GIT URLS and
REMOTES sections of linkgit:git-fetch[1]).
<patterns>...::
When unspecified, all references, after filtering done
with --heads and --tags, are shown. When <patterns>... are
specified, only references matching one or more of the given
patterns are displayed. Each pattern is interpreted as a glob
(see `glob` in linkgit:gitglossary[7]) which is matched against
the "tail" of a ref, starting either from the start of the ref
(so a full name like `refs/heads/foo` matches) or from a slash
separator (so `bar` matches `refs/heads/bar` but not
`refs/heads/foobar`).
OUTPUT
------
The output is in the format:
------------
<oid> TAB <ref> LF
------------
When showing an annotated tag, unless `--refs` is given, two such
lines are shown: one with the refname for the tag itself as `<ref>`,
and another with `<ref>` followed by `^{}`. The `<oid>` on the latter
line shows the name of the object the tag points at.
EXAMPLES
--------
* List all references (including symbolics and pseudorefs), peeling
tags:
+
----
$ git ls-remote
27d43aaaf50ef0ae014b88bba294f93658016a2e HEAD
950264636c68591989456e3ba0a5442f93152c1a refs/heads/main
d9ab777d41f92a8c1684c91cfb02053d7dd1046b refs/heads/next
d4ca2e3147b409459955613c152220f4db848ee1 refs/tags/v2.40.0
73876f4861cd3d187a4682290ab75c9dccadbc56 refs/tags/v2.40.0^{}
----
* List all references matching given patterns:
+
----
$ git ls-remote http://www.kernel.org/pub/scm/git/git.git master seen rc
5fe978a5381f1fbad26a80e682ddd2a401966740 refs/heads/master
c781a84b5204fb294c9ccc79f8b3baceeb32c061 refs/heads/seen
----
* List only tags matching a given wildcard pattern:
+
----
$ git ls-remote --tags http://www.kernel.org/pub/scm/git/git.git v\*
485a869c64a68cc5795dd99689797c5900f4716d refs/tags/v2.39.2
cbf04937d5b9fcf0a76c28f69e6294e9e3ecd7e6 refs/tags/v2.39.2^{}
d4ca2e3147b409459955613c152220f4db848ee1 refs/tags/v2.40.0
73876f4861cd3d187a4682290ab75c9dccadbc56 refs/tags/v2.40.0^{}
----
SEE ALSO
--------
linkgit:git-check-ref-format[1].
GIT
---
Part of the linkgit:git[1] suite

165
app/src/main/assets/manpages/git-ls-tree.txt Normal file
View File

@@ -0,0 +1,165 @@
git-ls-tree(1)
==============
NAME
----
git-ls-tree - List the contents of a tree object
SYNOPSIS
--------
[verse]
'git ls-tree' [-d] [-r] [-t] [-l] [-z]
[--name-only] [--name-status] [--object-only] [--full-name] [--full-tree] [--abbrev[=<n>]] [--format=<format>]
<tree-ish> [<path>...]
DESCRIPTION
-----------
Lists the contents of a given tree object, like what "/bin/ls -a" does
in the current working directory. Note that:
- the behaviour is slightly different from that of "/bin/ls" in that the
'<path>' denotes just a list of patterns to match, e.g. so specifying
directory name (without `-r`) will behave differently, and order of the
arguments does not matter.
- the behaviour is similar to that of "/bin/ls" in that the '<path>' is
taken as relative to the current working directory. E.g. when you are
in a directory 'sub' that has a directory 'dir', you can run 'git
ls-tree -r HEAD dir' to list the contents of the tree (that is
`sub/dir` in `HEAD`). You don't want to give a tree that is not at the
root level (e.g. `git ls-tree -r HEAD:sub dir`) in this case, as that
would result in asking for `sub/sub/dir` in the `HEAD` commit.
However, the current working directory can be ignored by passing
--full-tree option.
OPTIONS
-------
<tree-ish>::
Id of a tree-ish.
-d::
Show only the named tree entry itself, not its children.
-r::
Recurse into sub-trees.
-t::
Show tree entries even when going to recurse them. Has no effect
if `-r` was not passed. `-d` implies `-t`.
-l::
--long::
Show object size of blob (file) entries.
-z::
\0 line termination on output and do not quote filenames.
See OUTPUT FORMAT below for more information.
--name-only::
--name-status::
List only filenames (instead of the "long" output), one per line.
Cannot be combined with `--object-only`.
--object-only::
List only names of the objects, one per line. Cannot be combined
with `--name-only` or `--name-status`.
This is equivalent to specifying `--format='%(objectname)'`, but
for both this option and that exact format the command takes a
hand-optimized codepath instead of going through the generic
formatting mechanism.
--abbrev[=<n>]::
Instead of showing the full 40-byte hexadecimal object
lines, show the shortest prefix that is at least '<n>'
hexdigits long that uniquely refers the object.
Non default number of digits can be specified with --abbrev=<n>.
--full-name::
Instead of showing the path names relative to the current working
directory, show the full path names.
--full-tree::
Do not limit the listing to the current working directory.
Implies --full-name.
--format=<format>::
A string that interpolates `%(fieldname)` from the result
being shown. It also interpolates `%%` to `%`, and
`%xNN` where `NN` are hex digits interpolates to character
with hex code `NN`; for example `%x00` interpolates to
`\0` (NUL), `%x09` to `\t` (TAB) and `%x0a` to `\n` (LF).
When specified, `--format` cannot be combined with other
format-altering options, including `--long`, `--name-only`
and `--object-only`.
[<path>...]::
When paths are given, show them (note that this isn't really raw
pathnames, but rather a list of patterns to match). Otherwise
implicitly uses the root level of the tree as the sole path argument.
Output Format
-------------
The output format of `ls-tree` is determined by either the `--format`
option, or other format-altering options such as `--name-only` etc.
(see `--format` above).
The use of certain `--format` directives is equivalent to using those
options, but invoking the full formatting machinery can be slower than
using an appropriate formatting option.
In cases where the `--format` would exactly map to an existing option
`ls-tree` will use the appropriate faster path. Thus the default format
is equivalent to:
%(objectmode) %(objecttype) %(objectname)%x09%(path)
This output format is compatible with what `--index-info --stdin` of
'git update-index' expects.
When the `-l` option is used, format changes to
%(objectmode) %(objecttype) %(objectname) %(objectsize:padded)%x09%(path)
Object size identified by <objectname> is given in bytes, and right-justified
with minimum width of 7 characters. Object size is given only for blobs
(file) entries; for other entries `-` character is used in place of size.
Without the `-z` option, pathnames with "unusual" characters are
quoted as explained for the configuration variable `core.quotePath`
(see linkgit:git-config[1]). Using `-z` the filename is output
verbatim and the line is terminated by a NUL byte.
Customized format:
It is possible to print in a custom format by using the `--format` option,
which is able to interpolate different fields using a `%(fieldname)` notation.
For example, if you only care about the "objectname" and "path" fields, you
can execute with a specific "--format" like
git ls-tree --format='%(objectname) %(path)' <tree-ish>
FIELD NAMES
-----------
Various values from structured fields can be used to interpolate
into the resulting output. For each outputting line, the following
names can be used:
objectmode::
The mode of the object.
objecttype::
The type of the object (`commit`, `blob` or `tree`).
objectname::
The name of the object.
objectsize[:padded]::
The size of a `blob` object ("-" if it's a `commit` or `tree`).
It also supports a padded format of size with "%(objectsize:padded)".
path::
The pathname of the object.
GIT
---
Part of the linkgit:git[1] suite

127
app/src/main/assets/manpages/git-mailinfo.txt Normal file
View File

@@ -0,0 +1,127 @@
git-mailinfo(1)
===============
NAME
----
git-mailinfo - Extracts patch and authorship from a single e-mail message
SYNOPSIS
--------
[verse]
'git mailinfo' [-k|-b] [-u | --encoding=<encoding> | -n]
[--[no-]scissors] [--quoted-cr=<action>]
<msg> <patch>
DESCRIPTION
-----------
Reads a single e-mail message from the standard input, and
writes the commit log message in <msg> file, and the patches in
<patch> file. The author name, e-mail and e-mail subject are
written out to the standard output to be used by 'git am'
to create a commit. It is usually not necessary to use this
command directly. See linkgit:git-am[1] instead.
OPTIONS
-------
-k::
Usually the program removes email cruft from the Subject:
header line to extract the title line for the commit log
message. This option prevents this munging, and is most
useful when used to read back 'git format-patch -k' output.
+
Specifically, the following are removed until none of them remain:
+
--
* Leading and trailing whitespace.
* Leading `Re:`, `re:`, and `:`.
* Leading bracketed strings (between `[` and `]`, usually
`[PATCH]`).
--
+
Finally, runs of whitespace are normalized to a single ASCII space
character.
-b::
When -k is not in effect, all leading strings bracketed with '['
and ']' pairs are stripped. This option limits the stripping to
only the pairs whose bracketed string contains the word "PATCH".
-u::
The commit log message, author name and author email are
taken from the e-mail, and after minimally decoding MIME
transfer encoding, re-coded in the charset specified by
`i18n.commitEncoding` (defaulting to UTF-8) by transliterating
them. This used to be optional but now it is the default.
+
Note that the patch is always used as-is without charset
conversion, even with this flag.
--encoding=<encoding>::
Similar to -u. But when re-coding, the charset specified here is
used instead of the one specified by `i18n.commitEncoding` or UTF-8.
-n::
Disable all charset re-coding of the metadata.
-m::
--message-id::
Copy the Message-ID header at the end of the commit message. This
is useful in order to associate commits with mailing list discussions.
--scissors::
Remove everything in body before a scissors line (e.g. "-- >8 --").
The line represents scissors and perforation marks, and is used to
request the reader to cut the message at that line. If that line
appears in the body of the message before the patch, everything
before it (including the scissors line itself) is ignored when
this option is used.
+
This is useful if you want to begin your message in a discussion thread
with comments and suggestions on the message you are responding to, and to
conclude it with a patch submission, separating the discussion and the
beginning of the proposed commit log message with a scissors line.
+
This can be enabled by default with the configuration option mailinfo.scissors.
--no-scissors::
Ignore scissors lines. Useful for overriding mailinfo.scissors settings.
--quoted-cr=<action>::
Action when processes email messages sent with base64 or
quoted-printable encoding, and the decoded lines end with a CRLF
instead of a simple LF.
+
The valid actions are:
+
--
* `nowarn`: Git will do nothing when such a CRLF is found.
* `warn`: Git will issue a warning for each message if such a CRLF is
found.
* `strip`: Git will convert those CRLF to LF.
--
+
The default action could be set by configuration option `mailinfo.quotedCR`.
If no such configuration option has been set, `warn` will be used.
<msg>::
The commit log message extracted from e-mail, usually
except the title line which comes from e-mail Subject.
<patch>::
The patch extracted from e-mail.
CONFIGURATION
-------------
include::includes/cmd-config-section-all.adoc[]
include::config/mailinfo.adoc[]
GIT
---
Part of the linkgit:git[1] suite

57
app/src/main/assets/manpages/git-mailsplit.txt Normal file
View File

@@ -0,0 +1,57 @@
git-mailsplit(1)
================
NAME
----
git-mailsplit - Simple UNIX mbox splitter program
SYNOPSIS
--------
[verse]
'git mailsplit' [-b] [-f<nn>] [-d<prec>] [--keep-cr] [--mboxrd]
-o<directory> [--] [(<mbox>|<Maildir>)...]
DESCRIPTION
-----------
Splits a mbox file or a Maildir into a list of files: "0001" "0002" .. in the
specified directory so you can process them further from there.
IMPORTANT: Maildir splitting relies upon filenames being sorted to output
patches in the correct order.
OPTIONS
-------
<mbox>::
Mbox file to split. If not given, the mbox is read from
the standard input.
<Maildir>::
Root of the Maildir to split. This directory should contain the cur, tmp
and new subdirectories.
-o<directory>::
Directory in which to place the individual messages.
-b::
If any file doesn't begin with a From line, assume it is a
single mail message instead of signaling an error.
-d<prec>::
Instead of the default 4 digits with leading zeros,
different precision can be specified for the generated
filenames.
-f<nn>::
Skip the first <nn> numbers, for example if -f3 is specified,
start the numbering with 0004.
--keep-cr::
Do not remove `\r` from lines ending with `\r\n`.
--mboxrd::
Input is of the "mboxrd" format and "^>+From " line escaping is
reversed.
GIT
---
Part of the linkgit:git[1] suite

448
app/src/main/assets/manpages/git-maintenance.txt Normal file
View File

@@ -0,0 +1,448 @@
git-maintenance(1)
==================
NAME
----
git-maintenance - Run tasks to optimize Git repository data
SYNOPSIS
--------
[verse]
'git maintenance' run [<options>]
'git maintenance' start [--scheduler=<scheduler>]
'git maintenance' (stop|register|unregister) [<options>]
'git maintenance' is-needed [<options>]
DESCRIPTION
-----------
Run tasks to optimize Git repository data, speeding up other Git commands
and reducing storage requirements for the repository.
Git commands that add repository data, such as `git add` or `git fetch`,
are optimized for a responsive user experience. These commands do not take
time to optimize the Git data, since such optimizations scale with the full
size of the repository while these user commands each perform a relatively
small action.
The `git maintenance` command provides flexibility for how to optimize the
Git repository.
SUBCOMMANDS
-----------
run::
Run one or more maintenance tasks. If one or more `--task` options
are specified, then those tasks are run in that order. Otherwise,
the tasks are determined by which `maintenance.<task>.enabled`
config options are true. By default, only `maintenance.gc.enabled`
is true.
start::
Start running maintenance on the current repository. This performs
the same config updates as the `register` subcommand, then updates
the background scheduler to run `git maintenance run --scheduled`
on an hourly basis.
stop::
Halt the background maintenance schedule. The current repository
is not removed from the list of maintained repositories, in case
the background maintenance is restarted later.
register::
Initialize Git config values so any scheduled maintenance will start
running on this repository. This adds the repository to the
`maintenance.repo` config variable in the current user's global config,
or the config specified by --config-file option, and enables some
recommended configuration values for `maintenance.<task>.schedule`. The
tasks that are enabled are safe for running in the background without
disrupting foreground processes.
+
The `register` subcommand will also set the `maintenance.strategy` config
value to `incremental`, if this value is not previously set. The
`incremental` strategy uses the following schedule for each maintenance
task:
+
--
* `gc`: disabled.
* `commit-graph`: hourly.
* `prefetch`: hourly.
* `loose-objects`: daily.
* `incremental-repack`: daily.
--
+
`git maintenance register` will also disable foreground maintenance by
setting `maintenance.auto = false` in the current repository. This config
setting will remain after a `git maintenance unregister` command.
unregister::
Remove the current repository from background maintenance. This
only removes the repository from the configured list. It does not
stop the background maintenance processes from running.
+
The `unregister` subcommand will report an error if the current repository
is not already registered. Use the `--force` option to return success even
when the current repository is not registered.
is-needed::
Check whether maintenance needs to be run without actually running it.
Exits with a 0 status code if maintenance needs to be run, 1 otherwise.
Ideally used with the '--auto' flag.
+
If one or more `--task` options are specified, then those tasks are checked
in that order. Otherwise, the tasks are determined by which
`maintenance.<task>.enabled` config options are true. By default, only
`maintenance.gc.enabled` is true.
TASKS
-----
commit-graph::
The `commit-graph` job updates the `commit-graph` files incrementally,
then verifies that the written data is correct. The incremental
write is safe to run alongside concurrent Git processes since it
will not expire `.graph` files that were in the previous
`commit-graph-chain` file. They will be deleted by a later run based
on the expiration delay.
prefetch::
The `prefetch` task updates the object directory with the latest
objects from all registered remotes. For each remote, a `git fetch`
command is run. The configured refspec is modified to place all
requested refs within `refs/prefetch/`. Also, tags are not updated.
+
This is done to avoid disrupting the remote-tracking branches. The end users
expect these refs to stay unmoved unless they initiate a fetch. However,
with the prefetch task, the objects necessary to complete a later real fetch
would already be obtained, making the real fetch faster. In the ideal case,
it will just become an update to a bunch of remote-tracking branches without
any object transfer.
+
The `remote.<name>.skipFetchAll` configuration can be used to
exclude a particular remote from getting prefetched.
gc::
Clean up unnecessary files and optimize the local repository. "GC"
stands for "garbage collection," but this task performs many
smaller tasks. This task can be expensive for large repositories,
as it repacks all Git objects into a single pack-file. It can also
be disruptive in some situations, as it deletes stale data. See
linkgit:git-gc[1] for more details on garbage collection in Git.
loose-objects::
The `loose-objects` job cleans up loose objects and places them into
pack-files. In order to prevent race conditions with concurrent Git
commands, it follows a two-step process. First, it deletes any loose
objects that already exist in a pack-file; concurrent Git processes
will examine the pack-file for the object data instead of the loose
object. Second, it creates a new pack-file (starting with "loose-")
containing a batch of loose objects.
+
The batch size defaults to fifty thousand objects to prevent the job from
taking too long on a repository with many loose objects. Use the
`maintenance.loose-objects.batchSize` config option to adjust this size,
including a value of `0` to remove the limit.
+
The `gc` task writes unreachable objects as loose objects to be cleaned up
by a later step only if they are not re-added to a pack-file; for this
reason it is not advisable to enable both the `loose-objects` and `gc`
tasks at the same time.
incremental-repack::
The `incremental-repack` job repacks the object directory
using the `multi-pack-index` feature. In order to prevent race
conditions with concurrent Git commands, it follows a two-step
process. First, it calls `git multi-pack-index expire` to delete
pack-files unreferenced by the `multi-pack-index` file. Second, it
calls `git multi-pack-index repack` to select several small
pack-files and repack them into a bigger one, and then update the
`multi-pack-index` entries that refer to the small pack-files to
refer to the new pack-file. This prepares those small pack-files
for deletion upon the next run of `git multi-pack-index expire`.
The selection of the small pack-files is such that the expected
size of the big pack-file is at least the batch size; see the
`--batch-size` option for the `repack` subcommand in
linkgit:git-multi-pack-index[1]. The default batch-size is zero,
which is a special case that attempts to repack all pack-files
into a single pack-file.
pack-refs::
The `pack-refs` task collects the loose reference files and
collects them into a single file. This speeds up operations that
need to iterate across many references. See linkgit:git-pack-refs[1]
for more information.
reflog-expire::
The `reflog-expire` task deletes any entries in the reflog older than the
expiry threshold. See linkgit:git-reflog[1] for more information.
rerere-gc::
The `rerere-gc` task invokes garbage collection for stale entries in
the rerere cache. See linkgit:git-rerere[1] for more information.
worktree-prune::
The `worktree-prune` task deletes stale or broken worktrees. See
linkgit:git-worktree[1] for more information.
OPTIONS
-------
--auto::
When combined with the `run` subcommand, run maintenance tasks
only if certain thresholds are met. For example, the `gc` task
runs when the number of loose objects exceeds the number stored
in the `gc.auto` config setting, or when the number of pack-files
exceeds the `gc.autoPackLimit` config setting. Not compatible with
the `--schedule` option.
When combined with the `is-needed` subcommand, check if the required
thresholds are met without actually running maintenance.
--schedule::
When combined with the `run` subcommand, run maintenance tasks
only if certain time conditions are met, as specified by the
`maintenance.<task>.schedule` config value for each `<task>`.
This config value specifies a number of seconds since the last
time that task ran, according to the `maintenance.<task>.lastRun`
config value. The tasks that are tested are those provided by
the `--task=<task>` option(s) or those with
`maintenance.<task>.enabled` set to true.
--quiet::
Do not report progress or other information over `stderr`.
--task=<task>::
If this option is specified one or more times, then only run the
specified tasks in the specified order. If no `--task=<task>`
arguments are specified, then only the tasks with
`maintenance.<task>.enabled` configured as `true` are considered.
See the 'TASKS' section for the list of accepted `<task>` values.
--scheduler=auto|crontab|systemd-timer|launchctl|schtasks::
When combined with the `start` subcommand, specify the scheduler
for running the hourly, daily and weekly executions of
`git maintenance run`.
Possible values for `<scheduler>` are `auto`, `crontab`
(POSIX), `systemd-timer` (Linux), `launchctl` (macOS), and
`schtasks` (Windows). When `auto` is specified, the
appropriate platform-specific scheduler is used; on Linux,
`systemd-timer` is used if available, otherwise
`crontab`. Default is `auto`.
TROUBLESHOOTING
---------------
The `git maintenance` command is designed to simplify the repository
maintenance patterns while minimizing user wait time during Git commands.
A variety of configuration options are available to allow customizing this
process. The default maintenance options focus on operations that complete
quickly, even on large repositories.
Users may find some cases where scheduled maintenance tasks do not run as
frequently as intended. Each `git maintenance run` command takes a lock on
the repository's object database, and this prevents other concurrent
`git maintenance run` commands from running on the same repository. Without
this safeguard, competing processes could leave the repository in an
unpredictable state.
The background maintenance schedule runs `git maintenance run` processes
on an hourly basis. Each run executes the "hourly" tasks. At midnight,
that process also executes the "daily" tasks. At midnight on the first day
of the week, that process also executes the "weekly" tasks. A single
process iterates over each registered repository, performing the scheduled
tasks for that frequency. The processes are scheduled to a random minute of
the hour per client to spread out the load that multiple clients might
generate (e.g. from prefetching). Depending on the number of registered
repositories and their sizes, this process may take longer than an hour.
In this case, multiple `git maintenance run` commands may run on the same
repository at the same time, colliding on the object database lock. This
results in one of the two tasks not running.
If you find that some maintenance windows are taking longer than one hour
to complete, then consider reducing the complexity of your maintenance
tasks. For example, the `gc` task is much slower than the
`incremental-repack` task. However, this comes at a cost of a slightly
larger object database. Consider moving more expensive tasks to be run
less frequently.
Expert users may consider scheduling their own maintenance tasks using a
different schedule than is available through `git maintenance start` and
Git configuration options. These users should be aware of the object
database lock and how concurrent `git maintenance run` commands behave.
Further, the `git gc` command should not be combined with
`git maintenance run` commands. `git gc` modifies the object database
but does not take the lock in the same way as `git maintenance run`. If
possible, use `git maintenance run --task=gc` instead of `git gc`.
The following sections describe the mechanisms put in place to run
background maintenance by `git maintenance start` and how to customize
them.
BACKGROUND MAINTENANCE ON POSIX SYSTEMS
---------------------------------------
The standard mechanism for scheduling background tasks on POSIX systems
is cron(8). This tool executes commands based on a given schedule. The
current list of user-scheduled tasks can be found by running `crontab -l`.
The schedule written by `git maintenance start` is similar to this:
-----------------------------------------------------------------------
# BEGIN GIT MAINTENANCE SCHEDULE
# The following schedule was created by Git
# Any edits made in this region might be
# replaced in the future by a Git command.
0 1-23 * * * "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=hourly
0 0 * * 1-6 "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=daily
0 0 * * 0 "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=weekly
# END GIT MAINTENANCE SCHEDULE
-----------------------------------------------------------------------
The comments are used as a region to mark the schedule as written by Git.
Any modifications within this region will be completely deleted by
`git maintenance stop` or overwritten by `git maintenance start`.
The `crontab` entry specifies the full path of the `git` executable to
ensure that the executed `git` command is the same one with which
`git maintenance start` was issued independent of `PATH`. If the same user
runs `git maintenance start` with multiple Git executables, then only the
latest executable is used.
These commands use `git for-each-repo --config=maintenance.repo` to run
`git maintenance run --schedule=<frequency>` on each repository listed in
the multi-valued `maintenance.repo` config option. These are typically
loaded from the user-specific global config. The `git maintenance` process
then determines which maintenance tasks are configured to run on each
repository with each `<frequency>` using the `maintenance.<task>.schedule`
config options. These values are loaded from the global or repository
config values.
If the config values are insufficient to achieve your desired background
maintenance schedule, then you can create your own schedule. If you run
`crontab -e`, then an editor will load with your user-specific `cron`
schedule. In that editor, you can add your own schedule lines. You could
start by adapting the default schedule listed earlier, or you could read
the crontab(5) documentation for advanced scheduling techniques. Please
do use the full path and `--exec-path` techniques from the default
schedule to ensure you are executing the correct binaries in your
schedule.
BACKGROUND MAINTENANCE ON LINUX SYSTEMD SYSTEMS
-----------------------------------------------
While Linux supports `cron`, depending on the distribution, `cron` may
be an optional package not necessarily installed. On modern Linux
distributions, systemd timers are superseding it.
If user systemd timers are available, they will be used as a replacement
of `cron`.
In this case, `git maintenance start` will create user systemd timer units
and start the timers. The current list of user-scheduled tasks can be found
by running `systemctl --user list-timers`. The timers written by `git
maintenance start` are similar to this:
-----------------------------------------------------------------------
$ systemctl --user list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Thu 2021-04-29 19:00:00 CEST 42min left Thu 2021-04-29 18:00:11 CEST 17min ago git-maintenance@hourly.timer git-maintenance@hourly.service
Fri 2021-04-30 00:00:00 CEST 5h 42min left Thu 2021-04-29 00:00:11 CEST 18h ago git-maintenance@daily.timer git-maintenance@daily.service
Mon 2021-05-03 00:00:00 CEST 3 days left Mon 2021-04-26 00:00:11 CEST 3 days ago git-maintenance@weekly.timer git-maintenance@weekly.service
-----------------------------------------------------------------------
One timer is registered for each `--schedule=<frequency>` option.
The definition of the systemd units can be inspected in the following files:
-----------------------------------------------------------------------
~/.config/systemd/user/git-maintenance@.timer
~/.config/systemd/user/git-maintenance@.service
~/.config/systemd/user/timers.target.wants/git-maintenance@hourly.timer
~/.config/systemd/user/timers.target.wants/git-maintenance@daily.timer
~/.config/systemd/user/timers.target.wants/git-maintenance@weekly.timer
-----------------------------------------------------------------------
`git maintenance start` will overwrite these files and start the timer
again with `systemctl --user`, so any customization should be done by
creating a drop-in file, i.e. a `.conf` suffixed file in the
`~/.config/systemd/user/git-maintenance@.service.d` directory.
`git maintenance stop` will stop the user systemd timers and delete
the above mentioned files.
For more details, see `systemd.timer(5)`.
BACKGROUND MAINTENANCE ON MACOS SYSTEMS
---------------------------------------
While macOS technically supports `cron`, using `crontab -e` requires
elevated privileges and the executed process does not have a full user
context. Without a full user context, Git and its credential helpers
cannot access stored credentials, so some maintenance tasks are not
functional.
Instead, `git maintenance start` interacts with the `launchctl` tool,
which is the recommended way to schedule timed jobs in macOS. Scheduling
maintenance through `git maintenance (start|stop)` requires some
`launchctl` features available only in macOS 10.11 or later.
Your user-specific scheduled tasks are stored as XML-formatted `.plist`
files in `~/Library/LaunchAgents/`. You can see the currently-registered
tasks using the following command:
-----------------------------------------------------------------------
$ ls ~/Library/LaunchAgents/org.git-scm.git*
org.git-scm.git.daily.plist
org.git-scm.git.hourly.plist
org.git-scm.git.weekly.plist
-----------------------------------------------------------------------
One task is registered for each `--schedule=<frequency>` option. To
inspect how the XML format describes each schedule, open one of these
`.plist` files in an editor and inspect the `<array>` element following
the `<key>StartCalendarInterval</key>` element.
`git maintenance start` will overwrite these files and register the
tasks again with `launchctl`, so any customizations should be done by
creating your own `.plist` files with distinct names. Similarly, the
`git maintenance stop` command will unregister the tasks with `launchctl`
and delete the `.plist` files.
To create more advanced customizations to your background tasks, see
launchctl.plist(5) for more information.
BACKGROUND MAINTENANCE ON WINDOWS SYSTEMS
-----------------------------------------
Windows does not support `cron` and instead has its own system for
scheduling background tasks. The `git maintenance start` command uses
the `schtasks` command to submit tasks to this system. You can inspect
all background tasks using the Task Scheduler application. The tasks
added by Git have names of the form `Git Maintenance (<frequency>)`.
The Task Scheduler GUI has ways to inspect these tasks, but you can also
export the tasks to XML files and view the details there.
Note that since Git is a console application, these background tasks
create a console window visible to the current user. This can be changed
manually by selecting the "Run whether user is logged in or not" option
in Task Scheduler. This change requires a password input, which is why
`git maintenance start` does not select it by default.
If you want to customize the background tasks, please rename the tasks
so future calls to `git maintenance (start|stop)` do not overwrite your
custom tasks.
CONFIGURATION
-------------
include::includes/cmd-config-section-all.adoc[]
include::config/maintenance.adoc[]
GIT
---
Part of the linkgit:git[1] suite

247
app/src/main/assets/manpages/git-merge-base.txt Normal file
View File

@@ -0,0 +1,247 @@
git-merge-base(1)
=================
NAME
----
git-merge-base - Find as good common ancestors as possible for a merge
SYNOPSIS
--------
[verse]
'git merge-base' [-a | --all] <commit> <commit>...
'git merge-base' [-a | --all] --octopus <commit>...
'git merge-base' --is-ancestor <commit> <commit>
'git merge-base' --independent <commit>...
'git merge-base' --fork-point <ref> [<commit>]
DESCRIPTION
-----------
'git merge-base' finds the best common ancestor(s) between two commits to use
in a three-way merge. One common ancestor is 'better' than another common
ancestor if the latter is an ancestor of the former. A common ancestor
that does not have any better common ancestor is a 'best common
ancestor', i.e. a 'merge base'. Note that there can be more than one
merge base for a pair of commits.
OPERATION MODES
---------------
In the most common special case, specifying only two commits on the
command line means computing the merge base between the given two commits.
More generally, among the two commits to compute the merge base from,
one is specified by the first commit argument on the command line;
the other commit is a (possibly hypothetical) commit that is a merge
across all the remaining commits on the command line.
As a consequence, the 'merge base' is not necessarily contained in each of the
commit arguments if more than two commits are specified. This is different
from linkgit:git-show-branch[1] when used with the `--merge-base` option.
--octopus::
Compute the best common ancestors of all supplied commits,
in preparation for an n-way merge. This mimics the behavior
of 'git show-branch --merge-base'.
--independent::
Instead of printing merge bases, print a minimal subset of
the supplied commits with the same ancestors. In other words,
among the commits given, list those which cannot be reached
from any other. This mimics the behavior of 'git show-branch
--independent'.
--is-ancestor::
Check if the first <commit> is an ancestor of the second <commit>,
and exit with status 0 if true, or with status 1 if not.
Errors are signaled by a non-zero status that is not 1.
--fork-point::
Find the point at which a branch (or any history that leads
to <commit>) forked from another branch (or any reference)
<ref>. This does not just look for the common ancestor of
the two commits, but also takes into account the reflog of
<ref> to see if the history leading to <commit> forked from
an earlier incarnation of the branch <ref> (see discussion
of this mode below).
OPTIONS
-------
-a::
--all::
Output all merge bases for the commits, instead of just one.
DISCUSSION
----------
Given two commits 'A' and 'B', `git merge-base A B` will output a commit
which is reachable from both 'A' and 'B' through the parent relationship.
For example, with this topology:
....
o---o---o---B
/
---o---1---o---o---o---A
....
the merge base between 'A' and 'B' is '1'.
Given three commits 'A', 'B', and 'C', `git merge-base A B C` will compute the
merge base between 'A' and a hypothetical commit 'M', which is a merge
between 'B' and 'C'. For example, with this topology:
....
o---o---o---o---C
/
/ o---o---o---B
/ /
---2---1---o---o---o---A
....
the result of `git merge-base A B C` is '1'. This is because the
equivalent topology with a merge commit 'M' between 'B' and 'C' is:
....
o---o---o---o---o
/ \
/ o---o---o---o---M
/ /
---2---1---o---o---o---A
....
and the result of `git merge-base A M` is '1'. Commit '2' is also a
common ancestor between 'A' and 'M', but '1' is a better common ancestor,
because '2' is an ancestor of '1'. Hence, '2' is not a merge base.
The result of `git merge-base --octopus A B C` is '2', because '2' is
the best common ancestor of all commits.
When the history involves criss-cross merges, there can be more than one
'best' common ancestor for two commits. For example, with this topology:
....
---1---o---A
\ /
X
/ \
---2---o---o---B
....
both '1' and '2' are merge bases of A and B. Neither one is better than
the other (both are 'best' merge bases). When the `--all` option is not given,
it is unspecified which best one is output.
A common idiom to check "fast-forward-ness" between two commits A
and B is (or at least used to be) to compute the merge base between
A and B, and check if it is the same as A, in which case, A is an
ancestor of B. You will see this idiom used often in older scripts.
....
A=$(git rev-parse --verify A)
if test "$A" = "$(git merge-base A B)"
then
... A is an ancestor of B ...
fi
....
In modern git, you can say this in a more direct way:
....
if git merge-base --is-ancestor A B
then
... A is an ancestor of B ...
fi
....
instead.
Discussion on fork-point mode
-----------------------------
After working on the `topic` branch created with `git switch -c
topic origin/master`, the history of remote-tracking branch
`origin/master` may have been rewound and rebuilt, leading to a
history of this shape:
....
o---B2
/
---o---o---B1--o---o---o---B (origin/master)
\
B0
\
D0---D1---D (topic)
....
where `origin/master` used to point at commits B0, B1, B2 and now it
points at B, and your `topic` branch was started on top of it back
when `origin/master` was at B0, and you built three commits, D0, D1,
and D, on top of it. Imagine that you now want to rebase the work
you did on the topic on top of the updated origin/master.
In such a case, `git merge-base origin/master topic` would return the
parent of B0 in the above picture, but B0^..D is *not* the range of
commits you would want to replay on top of B (it includes B0, which
is not what you wrote; it is a commit the other side discarded when
it moved its tip from B0 to B1).
`git merge-base --fork-point origin/master topic` is designed to
help in such a case. It takes not only B but also B0, B1, and B2
(i.e. old tips of the remote-tracking branches your repository's
reflog knows about) into account to see on which commit your topic
branch was built and finds B0, allowing you to replay only the
commits on your topic, excluding the commits the other side later
discarded.
Hence
$ fork_point=$(git merge-base --fork-point origin/master topic)
will find B0, and
$ git rebase --onto origin/master $fork_point topic
will replay D0, D1, and D on top of B to create a new history of this
shape:
....
o---B2
/
---o---o---B1--o---o---o---B (origin/master)
\ \
B0 D0'--D1'--D' (topic - updated)
\
D0---D1---D (topic - old)
....
A caveat is that older reflog entries in your repository may be
expired by `git gc`. If B0 no longer appears in the reflog of the
remote-tracking branch `origin/master`, the `--fork-point` mode
obviously cannot find it and fails, avoiding to give a random and
useless result (such as the parent of B0, like the same command
without the `--fork-point` option gives).
Also, the remote-tracking branch you use the `--fork-point` mode
with must be the one your topic forked from its tip. If you forked
from an older commit than the tip, this mode would not find the fork
point (imagine in the above sample history B0 did not exist,
origin/master started at B1, moved to B2 and then B, and you forked
your topic at origin/master^ when origin/master was B1; the shape of
the history would be the same as above, without B0, and the parent
of B1 is what `git merge-base origin/master topic` correctly finds,
but the `--fork-point` mode will not, because it is not one of the
commits that used to be at the tip of origin/master).
See also
--------
linkgit:git-rev-list[1],
linkgit:git-show-branch[1],
linkgit:git-merge[1]
GIT
---
Part of the linkgit:git[1] suite

125
app/src/main/assets/manpages/git-merge-file.txt Normal file
View File

@@ -0,0 +1,125 @@
git-merge-file(1)
=================
NAME
----
git-merge-file - Run a three-way file merge
SYNOPSIS
--------
[verse]
'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
[--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>]
[--[no-]diff3] [--object-id] <current> <base> <other>
DESCRIPTION
-----------
Given three files `<current>`, `<base>` and `<other>`,
'git merge-file' incorporates all changes that lead from `<base>`
to `<other>` into `<current>`. The result ordinarily goes into
`<current>`. 'git merge-file' is useful for combining separate changes
to an original. Suppose `<base>` is the original, and both
`<current>` and `<other>` are modifications of `<base>`,
then 'git merge-file' combines both changes.
A conflict occurs if both `<current>` and `<other>` have changes
in a common segment of lines. If a conflict is found, 'git merge-file'
normally outputs a warning and brackets the conflict with lines containing
<<<<<<< and >>>>>>> markers. A typical conflict will look like this:
<<<<<<< A
lines in file A
=======
lines in file B
>>>>>>> B
If there are conflicts, the user should edit the result and delete one of
the alternatives. When `--ours`, `--theirs`, or `--union` option is in effect,
however, these conflicts are resolved favouring lines from `<current>`,
lines from `<other>`, or lines from both respectively. The length of the
conflict markers can be given with the `--marker-size` option.
If `--object-id` is specified, exactly the same behavior occurs, except that
instead of specifying what to merge as files, it is specified as a list of
object IDs referring to blobs.
The exit value of this program is negative on error, and the number of
conflicts otherwise (truncated to 127 if there are more than that many
conflicts). If the merge was clean, the exit value is 0.
'git merge-file' is designed to be a minimal clone of RCS 'merge'; that is, it
implements all of RCS 'merge''s functionality which is needed by
linkgit:git[1].
OPTIONS
-------
--object-id::
Specify the contents to merge as blobs in the current repository instead of
files. In this case, the operation must take place within a valid repository.
+
If the `-p` option is specified, the merged file (including conflicts, if any)
goes to standard output as normal; otherwise, the merged file is written to the
object store and the object ID of its blob is written to standard output.
-L <label>::
This option may be given up to three times, and
specifies labels to be used in place of the
corresponding file names in conflict reports. That is,
`git merge-file -L x -L y -L z a b c` generates output that
looks like it came from files x, y and z instead of
from files a, b and c.
-p::
Send results to standard output instead of overwriting
`<current>`.
-q::
Quiet; do not warn about conflicts.
--diff3::
Show conflicts in "diff3" style.
--zdiff3::
Show conflicts in "zdiff3" style.
+
The `--diff3` and `--zdiff3` options default to the value of the
`merge.conflictStyle` configuration variable (see linkgit:git-config[1]).
--ours::
--theirs::
--union::
Instead of leaving conflicts in the file, resolve conflicts
favouring our (or their or both) side of the lines.
--diff-algorithm={patience|minimal|histogram|myers}::
Use a different diff algorithm while merging. The current default is "myers",
but selecting more recent algorithm such as "histogram" can help
avoid mismerges that occur due to unimportant matching lines
(such as braces from distinct functions). See also
linkgit:git-diff[1] `--diff-algorithm`.
EXAMPLES
--------
`git merge-file README.my README README.upstream`::
combines the changes of README.my and README.upstream since README,
tries to merge them and writes the result into README.my.
`git merge-file -L a -L b -L c tmp/a123 tmp/b234 tmp/c345`::
merges tmp/a123 and tmp/c345 with the base tmp/b234, but uses labels
`a` and `c` instead of `tmp/a123` and `tmp/c345`.
`git merge-file -p --object-id abc1234 def567 890abcd`::
combines the changes of the blob abc1234 and 890abcd since def567,
tries to merge them and writes the result to standard output
GIT
---
Part of the linkgit:git[1] suite

83
app/src/main/assets/manpages/git-merge-index.txt Normal file
View File

@@ -0,0 +1,83 @@
git-merge-index(1)
==================
NAME
----
git-merge-index - Run a merge for files needing merging
SYNOPSIS
--------
[verse]
'git merge-index' [-o] [-q] <merge-program> (-a | ( [--] <file>...) )
DESCRIPTION
-----------
This looks up the <file>(s) in the index and, if there are any merge
entries, passes the SHA-1 hash for those files as arguments 1, 2, 3 (empty
argument if no file), and <file> as argument 4. File modes for the three
files are passed as arguments 5, 6 and 7.
OPTIONS
-------
\--::
Do not interpret any more arguments as options.
-a::
Run merge against all files in the index that need merging.
-o::
Instead of stopping at the first failed merge, do all of them
in one shot - continue with merging even when previous merges
returned errors, and only return the error code after all the
merges.
-q::
Do not complain about a failed merge program (a merge program
failure usually indicates conflicts during the merge). This is for
porcelains which might want to emit custom messages.
If 'git merge-index' is called with multiple <file>s (or -a) then it
processes them in turn only stopping if merge returns a non-zero exit
code.
Typically this is run with a script calling Git's imitation of
the 'merge' command from the RCS package.
A sample script called 'git merge-one-file' is included in the
distribution.
ALERT ALERT ALERT! The Git "merge object order" is different from the
RCS 'merge' program merge object order. In the above ordering, the
original is first. But the argument order to the 3-way merge program
'merge' is to have the original in the middle. Don't ask me why.
Examples:
----
torvalds@ppc970:~/merge-test> git merge-index cat MM
This is MM from the original tree. # original
This is modified MM in the branch A. # merge1
This is modified MM in the branch B. # merge2
This is modified MM in the branch B. # current contents
----
or
----
torvalds@ppc970:~/merge-test> git merge-index cat AA MM
cat: : No such file or directory
This is added AA in the branch A.
This is added AA in the branch B.
This is added AA in the branch B.
fatal: merge program failed
----
where the latter example shows how 'git merge-index' will stop trying to
merge once anything has returned an error (i.e., `cat` returned an error
for the AA file, because it didn't exist in the original, and thus
'git merge-index' didn't even try to merge the MM thing).
GIT
---
Part of the linkgit:git[1] suite

21
app/src/main/assets/manpages/git-merge-one-file.txt Normal file
View File

@@ -0,0 +1,21 @@
git-merge-one-file(1)
=====================
NAME
----
git-merge-one-file - The standard helper program to use with git-merge-index
SYNOPSIS
--------
[verse]
'git merge-one-file'
DESCRIPTION
-----------
This is the standard helper program to use with 'git merge-index'
to resolve a merge after the trivial merge done with 'git read-tree -m'.
GIT
---
Part of the linkgit:git[1] suite

348
app/src/main/assets/manpages/git-merge-tree.txt Normal file
View File

@@ -0,0 +1,348 @@
git-merge-tree(1)
=================
NAME
----
git-merge-tree - Perform merge without touching index or working tree
SYNOPSIS
--------
[verse]
'git merge-tree' [--write-tree] [<options>] <branch1> <branch2>
'git merge-tree' [--trivial-merge] <base-tree> <branch1> <branch2> (deprecated)
[[NEWMERGE]]
DESCRIPTION
-----------
This command has a modern `--write-tree` mode and a deprecated
`--trivial-merge` mode. With the exception of the
<<DEPMERGE,DEPRECATED DESCRIPTION>> section at the end, the rest of
this documentation describes the modern `--write-tree` mode.
Performs a merge, but does not make any new commits and does not read
from or write to either the working tree or index.
The performed merge will use the same features as the "real"
linkgit:git-merge[1], including:
* three way content merges of individual files
* rename detection
* proper directory/file conflict handling
* recursive ancestor consolidation (i.e. when there is more than one
merge base, creating a virtual merge base by merging the merge bases)
* etc.
After the merge completes, a new toplevel tree object is created. See
`OUTPUT` below for details.
OPTIONS
-------
--stdin::
Read the commits to merge from the standard input rather than
the command-line. See <<INPUT,INPUT FORMAT>> below for more
information. Implies `-z`.
-z::
Do not quote filenames in the <Conflicted file info> section,
and end each filename with a NUL character rather than
newline. Also begin the messages section with a NUL character
instead of a newline. See <<OUTPUT,OUTPUT>> below for more
information.
--name-only::
In the Conflicted file info section, instead of writing a list
of (mode, oid, stage, path) tuples to output for conflicted
files, just provide a list of filenames with conflicts (and
do not list filenames multiple times if they have multiple
conflicting stages).
--messages::
--no-messages::
Write any informational messages such as "Auto-merging <path>"
or CONFLICT notices to the end of stdout. If unspecified, the
default is to include these messages if there are merge
conflicts, and to omit them otherwise.
--quiet::
Disable all output from the program. Useful when you are only
interested in the exit status. Allows merge-tree to exit
early when it finds a conflict, and allows it to avoid writing
most objects created by merges.
--allow-unrelated-histories::
merge-tree will by default error out if the two branches specified
share no common history. This flag can be given to override that
check and make the merge proceed anyway.
--merge-base=<tree-ish>::
Instead of finding the merge-bases for <branch1> and <branch2>,
specify a merge-base for the merge. This option is incompatible with
`--stdin`.
+
Specifying multiple bases is currently not supported, which means that when
merging two branches with more than one merge-base, using this option may
cause merge results to differ from what `git merge` would compute. This
can include potentially losing some changes made on one side of the history
in the resulting merge.
+
With this option, since the merge-base is provided directly, <branch1> and
<branch2> do not need to specify commits; trees are enough.
-X<option>::
--strategy-option=<option>::
Pass the merge strategy-specific option through to the merge strategy.
See linkgit:git-merge[1] for details.
[[OUTPUT]]
OUTPUT
------
For a successful merge, the output from git-merge-tree is simply one
line:
<OID of toplevel tree>
Whereas for a conflicted merge, the output is by default of the form:
<OID of toplevel tree>
<Conflicted file info>
<Informational messages>
These are discussed individually below.
However, there is an exception. If `--stdin` is passed, then there is
an extra section at the beginning, a NUL character at the end, and then
all the sections repeat for each line of input. Thus, if the first merge
is conflicted and the second is clean, the output would be of the form:
<Merge status>
<OID of toplevel tree>
<Conflicted file info>
<Informational messages>
NUL
<Merge status>
<OID of toplevel tree>
NUL
[[MS]]
Merge status
~~~~~~~~~~~~
This is an integer status followed by a NUL character. The integer status is:
0: merge had conflicts
1: merge was clean
[[OIDTLT]]
OID of toplevel tree
~~~~~~~~~~~~~~~~~~~~
This is a tree object that represents what would be checked out in the
working tree at the end of `git merge`. If there were conflicts, then
files within this tree may have embedded conflict markers. This section
is always followed by a newline (or NUL if `-z` is passed).
[[CFI]]
Conflicted file info
~~~~~~~~~~~~~~~~~~~~
This is a sequence of lines with the format
<mode> <object> <stage> <filename>
The filename will be quoted as explained for the configuration
variable `core.quotePath` (see linkgit:git-config[1]). However, if
the `--name-only` option is passed, the mode, object, and stage will
be omitted. If `-z` is passed, the "lines" are terminated by a NUL
character instead of a newline character.
[[IM]]
Informational messages
~~~~~~~~~~~~~~~~~~~~~~
This section provides informational messages, typically about
conflicts. The format of the section varies significantly depending
on whether `-z` is passed.
If `-z` is passed:
The output format is zero or more conflict informational records, each
of the form:
<list-of-paths><conflict-type>NUL<conflict-message>NUL
where <list-of-paths> is of the form
<number-of-paths>NUL<path1>NUL<path2>NUL...<pathN>NUL
and includes paths (or branch names) affected by the conflict or
informational message in <conflict-message>. Also, <conflict-type> is a
stable string explaining the type of conflict, such as
* "Auto-merging"
* "CONFLICT (rename/delete)"
* "CONFLICT (submodule lacks merge base)"
* "CONFLICT (binary)"
and <conflict-message> is a more detailed message about the conflict which often
(but not always) embeds the <stable-short-type-description> within it. These
strings may change in future Git versions. Some examples:
* "Auto-merging <file>"
* "CONFLICT (rename/delete): <oldfile> renamed...but deleted in..."
* "Failed to merge submodule <submodule> (no merge base)"
* "Warning: cannot merge binary files: <filename>"
If `-z` is NOT passed:
This section starts with a blank line to separate it from the previous
sections, and then only contains the <conflict-message> information
from the previous section (separated by newlines). These are
non-stable strings that should not be parsed by scripts, and are just
meant for human consumption. Also, note that while <conflict-message>
strings usually do not contain embedded newlines, they sometimes do.
(However, the free-form messages will never have an embedded NUL
character). So, the entire block of information is meant for human
readers as an agglomeration of all conflict messages.
EXIT STATUS
-----------
For a successful, non-conflicted merge, the exit status is 0. When the
merge has conflicts, the exit status is 1. If the merge is not able to
complete (or start) due to some kind of error, the exit status is
something other than 0 or 1 (and the output is unspecified). When
--stdin is passed, the return status is 0 for both successful and
conflicted merges, and something other than 0 or 1 if it cannot complete
all the requested merges.
USAGE NOTES
-----------
This command is intended as low-level plumbing, similar to
linkgit:git-hash-object[1], linkgit:git-mktree[1],
linkgit:git-commit-tree[1], linkgit:git-write-tree[1],
linkgit:git-update-ref[1], and linkgit:git-mktag[1]. Thus, it can be
used as a part of a series of steps such as:
vi message.txt
BRANCH1=refs/heads/test
BRANCH2=main
NEWTREE=$(git merge-tree --write-tree $BRANCH1 $BRANCH2) || {
echo "There were conflicts..." 1>&2
exit 1
}
NEWCOMMIT=$(git commit-tree $NEWTREE -F message.txt \
-p $BRANCH1 -p $BRANCH2)
git update-ref $BRANCH1 $NEWCOMMIT
Note that when the exit status is non-zero, `NEWTREE` in this sequence
will contain a lot more output than just a tree.
For conflicts, the output includes the same information that you'd get
with linkgit:git-merge[1]:
* what would be written to the working tree (the
<<OIDTLT,OID of toplevel tree>>)
* the higher order stages that would be written to the index (the
<<CFI,Conflicted file info>>)
* any messages that would have been printed to stdout (the
<<IM,Informational messages>>)
[[INPUT]]
INPUT FORMAT
------------
'git merge-tree --stdin' input format is fully text based. Each line
has this format:
[<base-commit> -- ]<branch1> <branch2>
If one line is separated by `--`, the string before the separator is
used for specifying a merge-base for the merge and the string after
the separator describes the branches to be merged.
MISTAKES TO AVOID
-----------------
Do NOT look through the resulting toplevel tree to try to find which
files conflict; parse the <<CFI,Conflicted file info>> section instead.
Not only would parsing an entire tree be horrendously slow in large
repositories, there are numerous types of conflicts not representable by
conflict markers (modify/delete, mode conflict, binary file changed on
both sides, file/directory conflicts, various rename conflict
permutations, etc.)
Do NOT interpret an empty <<CFI,Conflicted file info>> list as a clean
merge; check the exit status. A merge can have conflicts without having
individual files conflict (there are a few types of directory rename
conflicts that fall into this category, and others might also be added
in the future).
Do NOT attempt to guess or make the user guess the conflict types from
the <<CFI,Conflicted file info>> list. The information there is
insufficient to do so. For example: Rename/rename(1to2) conflicts (both
sides renamed the same file differently) will result in three different
files having higher order stages (but each only has one higher order
stage), with no way (short of the <<IM,Informational messages>> section)
to determine which three files are related. File/directory conflicts
also result in a file with exactly one higher order stage.
Possibly-involved-in-directory-rename conflicts (when
"merge.directoryRenames" is unset or set to "conflicts") also result in
a file with exactly one higher order stage. In all cases, the
<<IM,Informational messages>> section has the necessary info, though it
is not designed to be machine parseable.
Do NOT assume that each path from <<CFI,Conflicted file info>>, and
the logical conflicts in the <<IM,Informational messages>> have a
one-to-one mapping, nor that there is a one-to-many mapping, nor a
many-to-one mapping. Many-to-many mappings exist, meaning that each
path can have many logical conflict types in a single merge, and each
logical conflict type can affect many paths.
Do NOT assume all filenames listed in the <<IM,Informational messages>>
section had conflicts. Messages can be included for files that have no
conflicts, such as "Auto-merging <file>".
AVOID taking the OIDS from the <<CFI,Conflicted file info>> and
re-merging them to present the conflicts to the user. This will lose
information. Instead, look up the version of the file found within the
<<OIDTLT,OID of toplevel tree>> and show that instead. In particular,
the latter will have conflict markers annotated with the original
branch/commit being merged and, if renames were involved, the original
filename. While you could include the original branch/commit in the
conflict marker annotations when re-merging, the original filename is
not available from the <<CFI,Conflicted file info>> and thus you would
be losing information that might help the user resolve the conflict.
[[DEPMERGE]]
DEPRECATED DESCRIPTION
----------------------
Per the <<NEWMERGE,DESCRIPTION>> and unlike the rest of this
documentation, this section describes the deprecated `--trivial-merge`
mode.
Other than the optional `--trivial-merge`, this mode accepts no
options.
This mode reads three tree-ish, and outputs trivial merge results and
conflicting stages to the standard output in a semi-diff format.
Since this was designed for higher level scripts to consume and merge
the results back into the index, it omits entries that match
<branch1>. The result of this second form is similar to what
three-way 'git read-tree -m' does, but instead of storing the results
in the index, the command outputs the entries to the standard output.
This form not only has limited applicability (a trivial merge cannot
handle content merges of individual files, rename detection, proper
directory/file conflict handling, etc.), the output format is also
difficult to work with, and it will generally be less performant than
the first form even on successful merges (especially if working in
large repositories).
GIT
---
Part of the linkgit:git[1] suite

412
app/src/main/assets/manpages/git-merge.txt Normal file
View File

@@ -0,0 +1,412 @@
git-merge(1)
============
NAME
----
git-merge - Join two or more development histories together
SYNOPSIS
--------
[synopsis]
git merge [-n] [--stat] [--compact-summary] [--no-commit] [--squash] [--[no-]edit]
[--no-verify] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]]
[--[no-]allow-unrelated-histories]
[--[no-]rerere-autoupdate] [-m <msg>] [-F <file>]
[--into-name <branch>] [<commit>...]
git merge (--continue | --abort | --quit)
DESCRIPTION
-----------
Incorporates changes from the named commits (since the time their
histories diverged from the current branch) into the current
branch. This command is used by `git pull` to incorporate changes
from another repository and can be used by hand to merge changes
from one branch into another.
Assume the following history exists and the current branch is
`master`:
------------
A---B---C topic
/
D---E---F---G master
------------
Then `git merge topic` will replay the changes made on the
`topic` branch since it diverged from `master` (i.e., `E`) until
its current commit (`C`) on top of `master`, and record the result
in a new commit along with the names of the two parent commits and
a log message from the user describing the changes. Before the operation,
`ORIG_HEAD` is set to the tip of the current branch (`G`).
------------
A---B---C topic
/ \
D---E---F---G---H master
------------
A merge stops if there's a conflict that cannot be resolved
automatically or if `--no-commit` was provided when initiating the
merge. At that point you can run `git merge --abort` or `git merge
--continue`.
`git merge --abort` will abort the merge process and try to reconstruct
the pre-merge state. However, if there were uncommitted changes when the
merge started (and especially if those changes were further modified
after the merge was started), `git merge --abort` will in some cases be
unable to reconstruct the original (pre-merge) changes. Therefore:
WARNING: Running `git merge` with non-trivial uncommitted changes is
discouraged: while possible, it may leave you in a state that is hard to
back out of in the case of a conflict.
OPTIONS
-------
:git-merge: 1
include::merge-options.adoc[]
`-m <msg>`::
Set the commit message to be used for the merge commit (in
case one is created).
+
If `--log` is specified, a shortlog of the commits being merged
will be appended to the specified message.
+
The `git fmt-merge-msg` command can be
used to give a good default for automated `git merge`
invocations. The automated message can include the branch description.
`--into-name <branch>`::
Prepare the default merge message as if merging to the branch
_<branch>_, instead of the name of the real branch to which
the merge is made.
`-F <file>`::
`--file=<file>`::
Read the commit message to be used for the merge commit (in
case one is created).
+
If `--log` is specified, a shortlog of the commits being merged
will be appended to the specified message.
include::rerere-options.adoc[]
`--overwrite-ignore`::
`--no-overwrite-ignore`::
Silently overwrite ignored files from the merge result. This
is the default behavior. Use `--no-overwrite-ignore` to abort.
`--abort`::
Abort the current conflict resolution process, and
try to reconstruct the pre-merge state. If an autostash entry is
present, apply it to the worktree.
+
If there were uncommitted worktree changes present when the merge
started, `git merge --abort` will in some cases be unable to
reconstruct these changes. It is therefore recommended to always
commit or stash your changes before running `git merge`.
+
`git merge --abort` is equivalent to `git reset --merge` when
`MERGE_HEAD` is present unless `MERGE_AUTOSTASH` is also present in
which case `git merge --abort` applies the stash entry to the worktree
whereas `git reset --merge` will save the stashed changes in the stash
list.
`--quit`::
Forget about the current merge in progress. Leave the index
and the working tree as-is. If `MERGE_AUTOSTASH` is present, the
stash entry will be saved to the stash list.
`--continue`::
After a `git merge` stops due to conflicts you can conclude the
merge by running `git merge --continue` (see "HOW TO RESOLVE
CONFLICTS" section below).
`<commit>...`::
Commits, usually other branch heads, to merge into our branch.
Specifying more than one commit will create a merge with
more than two parents (affectionately called an Octopus merge).
+
If no commit is given from the command line, merge the remote-tracking
branches that the current branch is configured to use as its upstream.
See also the configuration section of this manual page.
+
When `FETCH_HEAD` (and no other commit) is specified, the branches
recorded in the `.git/FETCH_HEAD` file by the previous invocation
of `git fetch` for merging are merged to the current branch.
PRE-MERGE CHECKS
----------------
Before applying outside changes, you should get your own work in
good shape and committed locally, so it will not be clobbered if
there are conflicts. See also linkgit:git-stash[1].
`git pull` and `git merge` will stop without doing anything when
local uncommitted changes overlap with files that `git pull`/`git
merge` may need to update.
To avoid recording unrelated changes in the merge commit,
`git pull` and `git merge` will also abort if there are any changes
registered in the index relative to the `HEAD` commit. (Special
narrow exceptions to this rule may exist depending on which merge
strategy is in use, but generally, the index must match `HEAD`.)
If all named commits are already ancestors of `HEAD`, `git merge`
will exit early with the message "Already up to date."
FAST-FORWARD MERGE
------------------
Often the current branch head is an ancestor of the named commit.
This is the most common case especially when invoked from `git
pull`: you are tracking an upstream repository, you have committed
no local changes, and now you want to update to a newer upstream
revision. In this case, a new commit is not needed to store the
combined history; instead, the `HEAD` (along with the index) is
updated to point at the named commit, without creating an extra
merge commit.
This behavior can be suppressed with the `--no-ff` option.
TRUE MERGE
----------
Except in a fast-forward merge (see above), the branches to be
merged must be tied together by a merge commit that has both of them
as its parents.
A merged version reconciling the changes from all branches to be
merged is committed, and your `HEAD`, index, and working tree are
updated to it. It is possible to have modifications in the working
tree as long as they do not overlap; the update will preserve them.
When it is not obvious how to reconcile the changes, the following
happens:
1. The `HEAD` pointer stays the same.
2. The `MERGE_HEAD` ref is set to point to the other branch head.
3. Paths that merged cleanly are updated both in the index file and
in your working tree.
4. For conflicting paths, the index file records up to three
versions: stage 1 stores the version from the common ancestor,
stage 2 from `HEAD`, and stage 3 from `MERGE_HEAD` (you
can inspect the stages with `git ls-files -u`). The working
tree files contain the result of the merge operation; i.e. 3-way
merge results with familiar conflict markers +<<<+ `===` +>>>+.
5. A ref named `AUTO_MERGE` is written, pointing to a tree
corresponding to the current content of the working tree (including
conflict markers for textual conflicts). Note that this ref is only
written when the `ort` merge strategy is used (the default).
6. No other changes are made. In particular, the local
modifications you had before you started merge will stay the
same and the index entries for them stay as they were,
i.e. matching `HEAD`.
If you tried a merge which resulted in complex conflicts and
want to start over, you can recover with `git merge --abort`.
MERGING TAG
-----------
When merging an annotated (and possibly signed) tag, Git always
creates a merge commit even if a fast-forward merge is possible, and
the commit message template is prepared with the tag message.
Additionally, if the tag is signed, the signature check is reported
as a comment in the message template. See also linkgit:git-tag[1].
When you want to just integrate with the work leading to the commit
that happens to be tagged, e.g. synchronizing with an upstream
release point, you may not want to make an unnecessary merge commit.
In such a case, you can "unwrap" the tag yourself before feeding it
to `git merge`, or pass `--ff-only` when you do not have any work on
your own. e.g.
----
git fetch origin
git merge v1.2.3^0
git merge --ff-only v1.2.3
----
HOW CONFLICTS ARE PRESENTED
---------------------------
During a merge, the working tree files are updated to reflect the result
of the merge. Among the changes made to the common ancestor's version,
non-overlapping ones (that is, you changed an area of the file while the
other side left that area intact, or vice versa) are incorporated in the
final result verbatim. When both sides made changes to the same area,
however, Git cannot randomly pick one side over the other, and asks you to
resolve it by leaving what both sides did to that area.
By default, Git uses the same style as the one used by the "merge" program
from the RCS suite to present such a conflicted hunk, like this:
------------
Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed,
or cleanly resolved because both sides changed the same way.
<<<<<<< yours:sample.txt
Conflict resolution is hard;
let's go shopping.
=======
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.
------------
The area where a pair of conflicting changes happened is marked with markers
+<<<<<<<+, `=======`, and +>>>>>>>+. The part before the `=======`
is typically your side, and the part afterwards is typically their side.
The default format does not show what the original said in the conflicting
area. You cannot tell how many lines are deleted and replaced with
Barbie's remark on your side. The only thing you can tell is that your
side wants to say it is hard and you'd prefer to go shopping, while the
other side wants to claim it is easy.
An alternative style can be used by setting the `merge.conflictStyle`
configuration variable to either `diff3` or `zdiff3`. In `diff3`
style, the above conflict may look like this:
------------
Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed,
<<<<<<< yours:sample.txt
or cleanly resolved because both sides changed the same way.
Conflict resolution is hard;
let's go shopping.
||||||| base:sample.txt
or cleanly resolved because both sides changed identically.
Conflict resolution is hard.
=======
or cleanly resolved because both sides changed the same way.
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.
------------
while in `zdiff3` style, it may look like this:
------------
Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed,
or cleanly resolved because both sides changed the same way.
<<<<<<< yours:sample.txt
Conflict resolution is hard;
let's go shopping.
||||||| base:sample.txt
or cleanly resolved because both sides changed identically.
Conflict resolution is hard.
=======
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.
------------
In addition to the +<<<<<<<+, `=======`, and +>>>>>>>+ markers, it uses
another +|||||||+ marker that is followed by the original text. You can
tell that the original just stated a fact, and your side simply gave in to
that statement and gave up, while the other side tried to have a more
positive attitude. You can sometimes come up with a better resolution by
viewing the original.
HOW TO RESOLVE CONFLICTS
------------------------
After seeing a conflict, you can do two things:
* Decide not to merge. The only clean-ups you need are to reset
the index file to the `HEAD` commit to reverse 2. and to clean
up working tree changes made by 2. and 3.; `git merge --abort`
can be used for this.
* Resolve the conflicts. Git will mark the conflicts in
the working tree. Edit the files into shape and
`git add` them to the index. Use `git commit` or
`git merge --continue` to seal the deal. The latter command
checks whether there is a (interrupted) merge in progress
before calling `git commit`.
You can work through the conflict with a number of tools:
* Use a mergetool. `git mergetool` to launch a graphical
mergetool which will work through the merge with you.
* Look at the diffs. `git diff` will show a three-way diff,
highlighting changes from both the `HEAD` and `MERGE_HEAD`
versions. `git diff AUTO_MERGE` will show what changes you've
made so far to resolve textual conflicts.
* Look at the diffs from each branch. `git log --merge -p <path>`
will show diffs first for the `HEAD` version and then the
`MERGE_HEAD` version.
* Look at the originals. `git show :1:filename` shows the
common ancestor, `git show :2:filename` shows the `HEAD`
version, and `git show :3:filename` shows the `MERGE_HEAD`
version.
EXAMPLES
--------
* Merge branches `fixes` and `enhancements` on top of
the current branch, making an octopus merge:
+
------------------------------------------------
$ git merge fixes enhancements
------------------------------------------------
* Merge branch `obsolete` into the current branch, using `ours`
merge strategy:
+
------------------------------------------------
$ git merge -s ours obsolete
------------------------------------------------
* Merge branch `maint` into the current branch, but do not make
a new commit automatically:
+
------------------------------------------------
$ git merge --no-commit maint
------------------------------------------------
+
This can be used when you want to include further changes to the
merge, or want to write your own merge commit message.
+
You should refrain from abusing this option to sneak substantial
changes into a merge commit. Small fixups like bumping
release/version name would be acceptable.
include::merge-strategies.adoc[]
CONFIGURATION
-------------
`branch.<name>.mergeOptions`::
Sets default options for merging into branch _<name>_. The syntax and
supported options are the same as those of `git merge`, but option
values containing whitespace characters are currently not supported.
include::includes/cmd-config-section-rest.adoc[]
include::config/merge.adoc[]
SEE ALSO
--------
linkgit:git-fmt-merge-msg[1], linkgit:git-pull[1],
linkgit:gitattributes[5],
linkgit:git-reset[1],
linkgit:git-diff[1], linkgit:git-ls-files[1],
linkgit:git-add[1], linkgit:git-rm[1],
linkgit:git-mergetool[1]
GIT
---
Part of the linkgit:git[1] suite

53
app/src/main/assets/manpages/git-mergetool--lib.txt Normal file
View File

@@ -0,0 +1,53 @@
git-mergetool{litdd}lib(1)
==========================
NAME
----
git-mergetool--lib - Common Git merge tool shell scriptlets
SYNOPSIS
--------
[verse]
'TOOL_MODE=(diff|merge) . "$(git --exec-path)/git-mergetool{litdd}lib"'
DESCRIPTION
-----------
This is not a command the end user would want to run. Ever.
This documentation is meant for people who are studying the
Porcelain-ish scripts and/or are writing new ones.
The 'git-mergetool{litdd}lib' scriptlet is designed to be sourced (using
`.`) by other shell scripts to set up functions for working
with Git merge tools.
Before sourcing 'git-mergetool{litdd}lib', your script must set `TOOL_MODE`
to define the operation mode for the functions listed below.
'diff' and 'merge' are valid values.
FUNCTIONS
---------
get_merge_tool::
Returns a merge tool. The return code is 1 if we returned a guessed
merge tool, else 0. '$GIT_MERGETOOL_GUI' may be set to 'true' to
search for the appropriate guitool.
get_merge_tool_cmd::
Returns the custom command for a merge tool.
get_merge_tool_path::
Returns the custom path for a merge tool.
initialize_merge_tool::
Brings merge tool specific functions into scope so they can be used or
overridden.
run_merge_tool::
Launches a merge tool given the tool name and a true/false
flag to indicate whether a merge base is present.
'$MERGED', '$LOCAL', '$REMOTE', and '$BASE' must be defined
for use by the merge tool.
GIT
---
Part of the linkgit:git[1] suite

130
app/src/main/assets/manpages/git-mergetool.txt Normal file
View File

@@ -0,0 +1,130 @@
git-mergetool(1)
================
NAME
----
git-mergetool - Run merge conflict resolution tools to resolve merge conflicts
SYNOPSIS
--------
[synopsis]
git mergetool [--tool=<tool>] [-y | --[no-]prompt] [<file>...]
DESCRIPTION
-----------
Use `git mergetool` to run one of several merge utilities to resolve
merge conflicts. It is typically run after `git merge`.
If one or more <file> parameters are given, the merge tool program will
be run to resolve differences in each file (skipping those without
conflicts). Specifying a directory will include all unresolved files in
that path. If no _<file>_ names are specified, `git mergetool` will run
the merge tool program on every file with merge conflicts.
OPTIONS
-------
`-t <tool>`::
`--tool=<tool>`::
Use the merge resolution program specified by _<tool>_.
Valid values include `emerge`, `gvimdiff`, `kdiff3`,
`meld`, `vimdiff`, and `tortoisemerge`. Run `git mergetool --tool-help`
for the list of valid _<tool>_ settings.
+
If a merge resolution program is not specified, `git mergetool`
will use the configuration variable `merge.tool`. If the
configuration variable `merge.tool` is not set, `git mergetool`
will pick a suitable default.
+
You can explicitly provide a full path to the tool by setting the
configuration variable `mergetool.<tool>.path`. For example, you
can configure the absolute path to kdiff3 by setting
`mergetool.kdiff3.path`. Otherwise, `git mergetool` assumes the
tool is available in `$PATH`.
+
Instead of running one of the known merge tool programs,
`git mergetool` can be customized to run an alternative program
by specifying the command line to invoke in a configuration
variable `mergetool.<tool>.cmd`.
+
When `git mergetool` is invoked with this tool (either through the
`-t` or `--tool` option or the `merge.tool` configuration
variable), the configured command line will be invoked with `BASE`
set to the name of a temporary file containing the common base for
the merge, if available; `LOCAL` set to the name of a temporary
file containing the contents of the file on the current branch;
`REMOTE` set to the name of a temporary file containing the
contents of the file to be merged, and `MERGED` set to the name
of the file to which the merge tool should write the result of the
merge resolution.
+
If the custom merge tool correctly indicates the success of a
merge resolution with its exit code, then the configuration
variable `mergetool.<tool>.trustExitCode` can be set to `true`.
Otherwise, `git mergetool` will prompt the user to indicate the
success of the resolution after the custom tool has exited.
`--tool-help`::
Print a list of merge tools that may be used with `--tool`.
`-y`::
`--no-prompt`::
Don't prompt before each invocation of the merge resolution
program.
This is the default if the merge resolution program is
explicitly specified with the `--tool` option or with the
`merge.tool` configuration variable.
`--prompt`::
Prompt before each invocation of the merge resolution program
to give the user a chance to skip the path.
`-g`::
`--gui`::
When `git-mergetool` is invoked with the `-g` or `--gui` option,
the default merge tool will be read from the configured
`merge.guitool` variable instead of `merge.tool`. If
`merge.guitool` is not set, we will fallback to the tool
configured under `merge.tool`. This may be autoselected using
the configuration variable `mergetool.guiDefault`.
`--no-gui`::
This overrides a previous `-g` or `--gui` setting or
`mergetool.guiDefault` configuration and reads the default merge
tool from the configured `merge.tool` variable.
`-O<orderfile>`::
Process files in the order specified in the
_<orderfile>_, which has one shell glob pattern per line.
This overrides the `diff.orderFile` configuration variable
(see linkgit:git-config[1]). To cancel `diff.orderFile`,
use `-O/dev/null`.
CONFIGURATION
-------------
:git-mergetool: 1
include::includes/cmd-config-section-all.adoc[]
include::config/mergetool.adoc[]
TEMPORARY FILES
---------------
`git mergetool` creates `*.orig` backup files while resolving merges.
These are safe to remove once a file has been merged and its
`git mergetool` session has completed.
Setting the `mergetool.keepBackup` configuration variable to `false`
causes `git mergetool` to automatically remove the backup files as files
are successfully merged.
BACKEND SPECIFIC HINTS
----------------------
vimdiff
~~~~~~~
include::mergetools/vimdiff.adoc[]
GIT
---
Part of the linkgit:git[1] suite

66
app/src/main/assets/manpages/git-mktag.txt Normal file
View File

@@ -0,0 +1,66 @@
git-mktag(1)
============
NAME
----
git-mktag - Creates a tag object with extra validation
SYNOPSIS
--------
[verse]
'git mktag'
DESCRIPTION
-----------
Reads a tag's contents on standard input and creates a tag object. The
output is the new tag's <object> identifier.
This command is mostly equivalent to linkgit:git-hash-object[1]
invoked with `-t tag -w --stdin`. I.e. both of these will create and
write a tag found in `my-tag`:
git mktag <my-tag
git hash-object -t tag -w --stdin <my-tag
The difference is that mktag will die before writing the tag if the
tag doesn't pass a linkgit:git-fsck[1] check.
The "fsck" check done by mktag is stricter than what linkgit:git-fsck[1]
would run by default in that all `fsck.<msg-id>` messages are promoted
from warnings to errors (so e.g. a missing "tagger" line is an error).
Extra headers in the object are also an error under mktag, but ignored
by linkgit:git-fsck[1]. This extra check can be turned off by setting
the appropriate `fsck.<msg-id>` variable:
git -c fsck.extraHeaderEntry=ignore mktag <my-tag-with-headers
OPTIONS
-------
--strict::
By default mktag turns on the equivalent of
linkgit:git-fsck[1] `--strict` mode. Use `--no-strict` to
disable it.
Tag Format
----------
A tag signature file, to be fed to this command's standard input,
has a very simple fixed format: four lines of
object <hash>
type <typename>
tag <tagname>
tagger <tagger>
followed by some 'optional' free-form message (some tags created
by older Git may not have a `tagger` line). The message, when it
exists, is separated by a blank line from the header. The
message part may contain a signature that Git itself doesn't
care about, but that can be verified with gpg.
GIT
---
Part of the linkgit:git[1] suite

40
app/src/main/assets/manpages/git-mktree.txt Normal file
View File

@@ -0,0 +1,40 @@
git-mktree(1)
=============
NAME
----
git-mktree - Build a tree-object from ls-tree formatted text
SYNOPSIS
--------
[verse]
'git mktree' [-z] [--missing] [--batch]
DESCRIPTION
-----------
Reads standard input in non-recursive `ls-tree` output format, and creates
a tree object. The order of the tree entries is normalized by mktree so
pre-sorting the input is not required. The object name of the tree object
built is written to the standard output.
OPTIONS
-------
-z::
Read the NUL-terminated `ls-tree -z` output instead.
--missing::
Allow missing objects. The default behaviour (without this option)
is to verify that each tree entry's hash identifies an existing
object. This option has no effect on the treatment of gitlink entries
(aka "submodules") which are always allowed to be missing.
--batch::
Allow building of more than one tree object before exiting. Each
tree is separated by a single blank line. The final newline is
optional. Note - if the `-z` option is used, lines are terminated
with NUL.
GIT
---
Part of the linkgit:git[1] suite

177
app/src/main/assets/manpages/git-multi-pack-index.txt Normal file
View File

@@ -0,0 +1,177 @@
git-multi-pack-index(1)
=======================
NAME
----
git-multi-pack-index - Write and verify multi-pack-indexes
SYNOPSIS
--------
[verse]
'git multi-pack-index' [<options>] write [--preferred-pack=<pack>]
[--[no-]bitmap] [--[no-]incremental] [--[no-]stdin-packs]
[--refs-snapshot=<path>]
'git multi-pack-index' [<options>] compact [--[no-]incremental]
[--[no-]bitmap] <from> <to>
'git multi-pack-index' [<options>] verify
'git multi-pack-index' [<options>] expire
'git multi-pack-index' [<options>] repack [--batch-size=<size>]
DESCRIPTION
-----------
Write or verify a multi-pack-index (MIDX) file.
OPTIONS
-------
The following command-line options are applicable to all sub-commands:
--object-dir=<dir>::
Use given directory for the location of Git objects. We check
`<dir>/packs/multi-pack-index` for the current MIDX file, and
`<dir>/packs` for the pack-files to index.
+
`<dir>` must be an alternate of the current repository.
--progress::
--no-progress::
Turn progress on/off explicitly. If neither is specified, progress is
shown if standard error is connected to a terminal. Supported by
sub-commands `write`, `verify`, `expire`, and `repack`.
The following subcommands are available:
write::
Write a new MIDX file. The following options are available for
the `write` sub-command:
+
--
--preferred-pack=<pack>::
When specified, break ties in favor of this pack when
there are additional copies of its objects in other
packs. Ties for objects not found in the preferred
pack are always resolved in favor of the copy in the
pack with the highest mtime. If unspecified, the pack
with the lowest mtime is used by default. The
preferred pack must have at least one object.
--[no-]bitmap::
Control whether or not a multi-pack bitmap is written.
--stdin-packs::
Write a multi-pack index containing only the set of
line-delimited pack index basenames provided over stdin.
--refs-snapshot=<path>::
With `--bitmap`, optionally specify a file which
contains a "refs snapshot" taken prior to repacking.
+
A reference snapshot is composed of line-delimited OIDs corresponding to
the reference tips, usually taken by `git repack` prior to generating a
new pack. A line may optionally start with a `+` character to indicate
that the reference which corresponds to that OID is "preferred" (see
linkgit:git-config[1]'s `pack.preferBitmapTips`.)
+
The file given at `<path>` is expected to be readable, and can contain
duplicates. (If a given OID is given more than once, it is marked as
preferred if at least one instance of it begins with the special `+`
marker).
--incremental::
Write an incremental MIDX file containing only objects
and packs not present in an existing MIDX layer.
Migrates non-incremental MIDXs to incremental ones when
necessary.
--
compact::
Write a new MIDX layer containing only objects and packs present
in the range `<from>` to `<to>`, where both arguments are
checksums of existing layers in the MIDX chain.
+
--
--incremental::
Write the result to a MIDX chain instead of writing a
stand-alone MIDX.
--[no-]bitmap::
Control whether or not a multi-pack bitmap is written.
--
+
Note that the compact command requires writing a version-2 midx that
cannot be read by versions of Git prior to v2.54.
verify::
Verify the contents of the MIDX file.
expire::
Delete the pack-files that are tracked by the MIDX file, but
have no objects referenced by the MIDX (with the exception of
`.keep` packs and cruft packs). Rewrite the MIDX file afterward
to remove all references to these pack-files.
+
NOTE: this mode is incompatible with incremental MIDX files.
repack::
Create a new pack-file containing objects in small pack-files
referenced by the multi-pack-index. If the size given by the
`--batch-size=<size>` argument is zero, then create a pack
containing all objects referenced by the multi-pack-index. For
a non-zero batch size, Select the pack-files by examining packs
from oldest-to-newest, computing the "expected size" by counting
the number of objects in the pack referenced by the
multi-pack-index, then divide by the total number of objects in
the pack and multiply by the pack size. We select packs with
expected size below the batch size until the set of packs have
total expected size at least the batch size, or all pack-files
are considered. If only one pack-file is selected, then do
nothing. If a new pack-file is created, rewrite the
multi-pack-index to reference the new pack-file. A later run of
'git multi-pack-index expire' will delete the pack-files that
were part of this batch.
+
If `repack.packKeptObjects` is `false`, then any pack-files with an
associated `.keep` file will not be selected for the batch to repack.
+
NOTE: this mode is incompatible with incremental MIDX files.
EXAMPLES
--------
* Write a MIDX file for the packfiles in the current `.git` directory.
+
-----------------------------------------------
$ git multi-pack-index write
-----------------------------------------------
* Write a MIDX file for the packfiles in the current `.git` directory with a
corresponding bitmap.
+
-------------------------------------------------------------
$ git multi-pack-index write --preferred-pack=<pack> --bitmap
-------------------------------------------------------------
* Write a MIDX file for the packfiles in an alternate object store.
+
-----------------------------------------------
$ git multi-pack-index --object-dir <alt> write
-----------------------------------------------
* Verify the MIDX file for the packfiles in the current `.git` directory.
+
-----------------------------------------------
$ git multi-pack-index verify
-----------------------------------------------
SEE ALSO
--------
See link:technical/multi-pack-index.html[The Multi-Pack-Index Design
Document] and linkgit:gitformat-pack[5] for more information on the
multi-pack-index feature and its file format.
GIT
---
Part of the linkgit:git[1] suite

68
app/src/main/assets/manpages/git-mv.txt Normal file
View File

@@ -0,0 +1,68 @@
git-mv(1)
=========
NAME
----
git-mv - Move or rename a file, a directory, or a symlink
SYNOPSIS
--------
[synopsis]
git mv [-v] [-f] [-n] [-k] <source> <destination>
git mv [-v] [-f] [-n] [-k] <source>... <destination-directory>
DESCRIPTION
-----------
Move or rename a file, directory, or symlink.
In the first form, it renames _<source>_, which must exist and be either
a file, symlink or directory, to _<destination>_.
In the second form, _<destination-directory>_ has to be an existing
directory; the given sources will be moved into this directory.
The index is updated after successful completion, but the change must still be
committed.
OPTIONS
-------
`-f`::
`--force`::
Force renaming or moving of a file even if the <destination> exists.
`-k`::
Skip move or rename actions which would lead to an error
condition. An error happens when a source is neither existing nor
controlled by Git, or when it would overwrite an existing
file unless `-f` is given.
`-n`::
`--dry-run`::
Do nothing; only show what would happen
`-v`::
`--verbose`::
Report the names of files as they are moved.
SUBMODULES
----------
Moving a submodule using a gitfile (which means they were cloned
with a Git version 1.7.8 or newer) will update the gitfile and
core.worktree setting to make the submodule work in the new location.
It also will attempt to update the `submodule.<name>.path` setting in
the linkgit:gitmodules[5] file and stage that file (unless `-n` is used).
BUGS
----
Each time a superproject update moves a populated submodule (e.g. when
switching between commits before and after the move) a stale submodule
checkout will remain in the old location and an empty directory will
appear in the new location. To populate the submodule again in the new
location the user will have to run "git submodule update"
afterwards. Removing the old directory is only safe when it uses a
gitfile, as otherwise the history of the submodule will be deleted
too. Both steps will be obsolete when recursive submodule update has
been implemented.
GIT
---
Part of the linkgit:git[1] suite

112
app/src/main/assets/manpages/git-name-rev.txt Normal file
View File

@@ -0,0 +1,112 @@
git-name-rev(1)
===============
NAME
----
git-name-rev - Find symbolic names for given revs
SYNOPSIS
--------
[verse]
'git name-rev' [--tags] [--refs=<pattern>]
( --all | --annotate-stdin | <commit-ish>... )
DESCRIPTION
-----------
Finds symbolic names suitable for human digestion for revisions given in any
format parsable by 'git rev-parse'.
OPTIONS
-------
--tags::
Do not use branch names, but only tags to name the commits
--refs=<pattern>::
Only use refs whose names match a given shell pattern. The pattern
can be a branch name, a tag name, or a fully qualified ref name. If
given multiple times, use refs whose names match any of the given shell
patterns. Use `--no-refs` to clear any previous ref patterns given.
--exclude=<pattern>::
Do not use any ref whose name matches a given shell pattern. The
pattern can be one of branch name, tag name or fully qualified ref
name. If given multiple times, a ref will be excluded when it matches
any of the given patterns. When used together with --refs, a ref will
be used as a match only when it matches at least one --refs pattern and
does not match any --exclude patterns. Use `--no-exclude` to clear the
list of exclude patterns.
--all::
List all commits reachable from all refs
--annotate-stdin::
Transform stdin by substituting all the 40-character SHA-1
hexes (say $hex) with "$hex ($rev_name)". When used with
--name-only, substitute with "$rev_name", omitting $hex
altogether. This option was called `--stdin` in older versions
of Git.
+
For example:
+
-----------
$ cat sample.txt
An abbreviated revision 2ae0a9cb82 will not be substituted.
The full name after substitution is 2ae0a9cb8298185a94e5998086f380a355dd8907,
while its tree object is 70d105cc79e63b81cfdcb08a15297c23e60b07ad
$ git name-rev --annotate-stdin <sample.txt
An abbreviated revision 2ae0a9cb82 will not be substituted.
The full name after substitution is 2ae0a9cb8298185a94e5998086f380a355dd8907 (master),
while its tree object is 70d105cc79e63b81cfdcb08a15297c23e60b07ad
$ git name-rev --name-only --annotate-stdin <sample.txt
An abbreviated revision 2ae0a9cb82 will not be substituted.
The full name after substitution is master,
while its tree object is 70d105cc79e63b81cfdcb08a15297c23e60b07ad
-----------
--name-only::
Instead of printing both the SHA-1 and the name, print only
the name. If given with --tags the usual tag prefix of
"tags/" is also omitted from the name, matching the output
of `git-describe` more closely.
--no-undefined::
Die with error code != 0 when a reference is undefined,
instead of printing `undefined`.
--always::
Show uniquely abbreviated commit object as fallback.
EXAMPLES
--------
Given a commit, find out where it is relative to the local refs. Say somebody
wrote you about that fantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a.
Of course, you look into the commit, but that only tells you what happened, but
not the context.
Enter 'git name-rev':
------------
% git name-rev 33db5f4d9027a10e477ccf054b2c1ab94f74c85a
33db5f4d9027a10e477ccf054b2c1ab94f74c85a tags/v0.99~940
------------
Now you are wiser, because you know that it happened 940 revisions before v0.99.
Another nice thing you can do is:
------------
% git log | git name-rev --annotate-stdin
------------
GIT
---
Part of the linkgit:git[1] suite

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