diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/Makefile | 1 | ||||
| -rw-r--r-- | Documentation/RelNotes/2.19.2.txt | 108 | ||||
| -rw-r--r-- | Documentation/RelNotes/2.20.0.txt | 104 | ||||
| -rw-r--r-- | Documentation/config.txt | 7 | ||||
| -rw-r--r-- | Documentation/config/index.txt | 16 | ||||
| -rw-r--r-- | Documentation/config/rebase.txt | 14 | ||||
| -rw-r--r-- | Documentation/git-format-patch.txt | 5 | ||||
| -rw-r--r-- | Documentation/git-range-diff.txt | 17 | ||||
| -rw-r--r-- | Documentation/git-reset.txt | 277 | ||||
| -rw-r--r-- | Documentation/gitrepository-layout.txt | 2 | ||||
| -rw-r--r-- | Documentation/technical/api-parse-options.txt | 4 | ||||
| -rw-r--r-- | Documentation/technical/repository-version.txt | 26 |
12 files changed, 424 insertions, 157 deletions
diff --git a/Documentation/Makefile b/Documentation/Makefile index 48d261dc2c..d5d936e6a7 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -73,6 +73,7 @@ TECH_DOCS += technical/hash-function-transition TECH_DOCS += technical/http-protocol TECH_DOCS += technical/index-format TECH_DOCS += technical/long-running-process-protocol +TECH_DOCS += technical/multi-pack-index TECH_DOCS += technical/pack-format TECH_DOCS += technical/pack-heuristics TECH_DOCS += technical/pack-protocol diff --git a/Documentation/RelNotes/2.19.2.txt b/Documentation/RelNotes/2.19.2.txt new file mode 100644 index 0000000000..759e6ca957 --- /dev/null +++ b/Documentation/RelNotes/2.19.2.txt @@ -0,0 +1,108 @@ +Git v2.19.2 Release Notes +========================= + +Fixes since v2.19.1 +------------------- + + * "git interpret-trailers" and its underlying machinery had a buggy + code that attempted to ignore patch text after commit log message, + which triggered in various codepaths that will always get the log + message alone and never get such an input. + + * "git rebase -i" did not clear the state files correctly when a run + of "squash/fixup" is aborted and then the user manually amended the + commit instead, which has been corrected. + + * When fsmonitor is in use, after operation on submodules updates + .gitmodules, we lost track of the fact that we did so and relied on + stale fsmonitor data. + + * Fix for a long-standing bug that leaves the index file corrupt when + it shrinks during a partial commit. + + * Further fix for O_APPEND emulation on Windows + + * A corner case bugfix in "git rerere" code. + + * "git add ':(attr:foo)'" is not supported and is supposed to be + rejected while the command line arguments are parsed, but we fail + to reject such a command line upfront. + + * "git rebase" etc. in Git 2.19 fails to abort when given an empty + commit log message as result of editing, which has been corrected. + + * The code to backfill objects in lazily cloned repository did not + work correctly, which has been corrected. + + * Update error messages given by "git remote" and make them consistent. + + * "git update-ref" learned to make both "--no-deref" and "--stdin" + work at the same time. + + * Recently added "range-diff" had a corner-case bug to cause it + segfault, which has been corrected. + + * The recently introduced commit-graph auxiliary data is incompatible + with mechanisms such as replace & grafts that "breaks" immutable + nature of the object reference relationship. Disable optimizations + based on its use (and updating existing commit-graph) when these + incompatible features are in use in the repository. + + * The mailmap file update. + + * The code in "git status" sometimes hit an assertion failure. This + was caused by a structure that was reused without cleaning the data + used for the first run, which has been corrected. + + * A corner-case bugfix. + + * A partial clone that is configured to lazily fetch missing objects + will on-demand issue a "git fetch" request to the originating + repository to fill not-yet-obtained objects. The request has been + optimized for requesting a tree object (and not the leaf blob + objects contained in it) by telling the originating repository that + no blobs are needed. + + * The codepath to support the experimental split-index mode had + remaining "racily clean" issues fixed. + + * "git log --graph" showing an octopus merge sometimes miscounted the + number of display columns it is consuming to show the merge and its + parent commits, which has been corrected. + + * The implementation of run_command() API on the UNIX platforms had a + bug that caused a command not on $PATH to be found in the current + directory. + + * A mutex used in "git pack-objects" were not correctly initialized + and this caused "git repack" to dump core on Windows. + + * Under certain circumstances, "git diff D:/a/b/c D:/a/b/d" on + Windows would strip initial parts from the paths because they + were not recognized as absolute, which has been corrected. + + * The receive.denyCurrentBranch=updateInstead codepath kicked in even + when the push should have been rejected due to other reasons, such + as it does not fast-forward or the update-hook rejects it, which + has been corrected. + + * "git repack" in a shallow clone did not correctly update the + shallow points in the repository, leading to a repository that + does not pass fsck. + + * Operations on promisor objects make sense in the context of only a + small subset of the commands that internally use the revisions + machinery, but the "--exclude-promisor-objects" option were taken + and led to nonsense results by commands like "log", to which it + didn't make much sense. This has been corrected. + + * The "container" mode of TravisCI is going away. Our .travis.yml + file is getting prepared for the transition. + + * Our test scripts can now take the '-V' option as a synonym for the + '--verbose-log' option. + + * A regression in Git 2.12 era made "git fsck" fall into an infinite + loop while processing truncated loose objects. + +Also contains various documentation updates and code clean-ups. diff --git a/Documentation/RelNotes/2.20.0.txt b/Documentation/RelNotes/2.20.0.txt index 519c89407c..8e266647f0 100644 --- a/Documentation/RelNotes/2.20.0.txt +++ b/Documentation/RelNotes/2.20.0.txt @@ -1,5 +1,5 @@ -Git Release Notes -================= +Git 2.20 Release Notes +====================== Backward Compatibility Notes ---------------------------- @@ -173,6 +173,15 @@ UI, Workflows & Features each other. (merge e5bbe09e88 nd/wildmatch-double-asterisk later to maint). + * The "--no-patch" option, which can be used to get a high-level + overview without the actual line-by-line patch difference shown, of + the "range-diff" command was earlier broken, which has been + corrected. + + * The recently merged "rebase in C" has an escape hatch to use the + scripted version when necessary, but it hasn't been documented, + which has been corrected. + Performance, Internal Implementation, Development Support etc. @@ -249,8 +258,8 @@ Performance, Internal Implementation, Development Support etc. used during tests are getting renamed for consistency. (merge 4231d1ba99 bp/rename-test-env-var later to maint). - * A new extension to the index file has been introduced, which allows - the index file to be read in parallel for performance. + * A pair of new extensions to the index file have been introduced. + They allow the index file to be read in parallel for performance. * The oidset API was built on top of the oidmap API which in turn is on the hashmap API. Replace the implementation to build on top of @@ -332,6 +341,52 @@ Performance, Internal Implementation, Development Support etc. * The support for format-patch (and send-email) by the command-line completion script (in contrib/) has been simplified a bit. + * The revision walker machinery learned to take advantage of the + commit generation numbers stored in the commit-graph file. + + * The codebase has been cleaned up to reduce "#ifndef NO_PTHREADS". + + * The way -lcurl library gets linked has been simplified by taking + advantage of the fact that we can just ask curl-config command how. + + * Various functions have been audited for "-Wunused-parameter" warnings + and bugs in them got fixed. + + * A sanity check for start-up sequence has been added in the config + API codepath. + + * The build procedure to link for fuzzing test has been made + customizable with a new Makefile variable. + + * The way "git rebase" parses and forwards the command line options + meant for underlying "git am" has been revamped, which fixed for + options with parameters that were not passed correctly. + + * Our testing framework uses a special i18n "poisoned localization" + feature to find messages that ought to stay constant but are + incorrectly marked to be translated. This feature has been made + into a runtime option (it used to be a compile-time option). + + * "git push" used to check ambiguities between object-names and + refnames while processing the list of refs' old and new values, + which was unnecessary (as it knew that it is feeding raw object + names). This has been optimized out. + + * The xcurl_off_t() helper function is used to cast size_t to + curl_off_t, but some compilers gave warnings against the code to + ensure the casting is done without wraparound, when size_t is + narrower than curl_off_t. This warning has been squelched. + + * Code preparation to replace ulong vars with size_t vars where + appropriate continues. + + * The "test installed Git" mode of our test suite has been updated to + work better. + + * A coding convention around the Coccinelle semantic patches to have + two classes to ease code migration process has been proposed and + its support has been added to the Makefile. + Fixes since v2.19 ----------------- @@ -544,6 +599,46 @@ Fixes since v2.19 pathspec elements were involved, which has been fixed. (merge b7845cebc0 nd/tree-walk-path-exclusion later to maint). + * "git merge" and "git pull" that merges into an unborn branch used + to completely ignore "--verify-signatures", which has been + corrected. + (merge 01a31f3bca jk/verify-sig-merge-into-void later to maint). + + * "git rebase --autostash" did not correctly re-attach the HEAD at times. + + * "rev-parse --exclude=<pattern> --branches=<pattern>" etc. did not + quite work, which has been corrected. + (merge 9ab9b5df0e ra/rev-parse-exclude-glob later to maint). + + * When editing a patch in a "git add -i" session, a hunk could be + made to no-op. The "git apply" program used to reject a patch with + such a no-op hunk to catch user mistakes, but it is now updated to + explicitly allow a no-op hunk in an edited patch. + (merge 22cb3835b9 js/apply-recount-allow-noop later to maint). + + * The URL to an MSDN page in a comment has been updated. + (merge 2ef2ae2917 js/mingw-msdn-url later to maint). + + * "git ls-remote --sort=<thing>" can feed an object that is not yet + available into the comparison machinery and segfault, which has + been corrected to check such a request upfront and reject it. + + * When "git bundle" aborts due to an empty commit ranges + (i.e. resulting in an empty pack), it left a file descriptor to an + lockfile open, which resulted in leftover lockfile on Windows where + you cannot remove a file with an open file descriptor. This has + been corrected. + (merge 2c8ee1f53c jk/close-duped-fd-before-unlock-for-bundle later to maint). + + * "git format-patch --stat=<width>" can be used to specify the width + used by the diffstat (shown in the cover letter). + (merge 284aeb7e60 nd/format-patch-cover-letter-stat-width later to maint). + + * The way .git/index and .git/sharedindex* files were initially + created gave these files different perm bits until they were + adjusted for shared repository settings. This was made consistent. + (merge c9d6c78870 cc/shared-index-permbits later to maint). + * Code cleanup, docfix, build fix, etc. (merge 96a7501aad ts/doc-build-manpage-xsl-quietly later to maint). (merge b9b07efdb2 tg/conflict-marker-size later to maint). @@ -583,3 +678,4 @@ Fixes since v2.19 (merge 3063477445 tb/char-may-be-unsigned later to maint). (merge 8c64bc9420 sg/test-rebase-editor-fix later to maint). (merge 71571cd7d6 ma/sequencer-do-reset-saner-loop-termination later to maint). + (merge 9a4cb8781e cb/notes-freeing-always-null-fix later to maint). diff --git a/Documentation/config.txt b/Documentation/config.txt index 3e735f1a9a..d87846faa6 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -292,13 +292,6 @@ include::config/advice.txt[] include::config/core.txt[] -extensions.worktreeConfig:: - If set, by default "git config" reads from both "config" and - "config.worktree" file from GIT_DIR in that order. In - multiple working directory mode, "config" file is shared while - "config.worktree" is per-working directory (i.e., it's in - GIT_COMMON_DIR/worktrees/<id>/config.worktree) - include::config/add.txt[] include::config/alias.txt[] diff --git a/Documentation/config/index.txt b/Documentation/config/index.txt index 4b94b6bedc..f181503041 100644 --- a/Documentation/config/index.txt +++ b/Documentation/config/index.txt @@ -1,3 +1,19 @@ +index.recordEndOfIndexEntries:: + Specifies whether the index file should include an "End Of Index + Entry" section. This reduces index load time on multiprocessor + machines but produces a message "ignoring EOIE extension" when + reading the index using Git versions before 2.20. Defaults to + 'true' if index.threads has been explicitly enabled, 'false' + otherwise. + +index.recordOffsetTable:: + Specifies whether the index file should include an "Index Entry + Offset Table" section. This reduces index load time on + multiprocessor machines but produces a message "ignoring IEOT + extension" when reading the index using Git versions before 2.20. + Defaults to 'true' if index.threads has been explicitly enabled, + 'false' otherwise. + index.threads:: Specifies the number of threads to spawn when loading the index. This is meant to reduce index load time on multiprocessor machines. diff --git a/Documentation/config/rebase.txt b/Documentation/config/rebase.txt index 42e1ba7575..f079bf6b7e 100644 --- a/Documentation/config/rebase.txt +++ b/Documentation/config/rebase.txt @@ -1,3 +1,17 @@ +rebase.useBuiltin:: + Set to `false` to use the legacy shellscript implementation of + linkgit:git-rebase[1]. Is `true` by default, which means use + the built-in rewrite of it in C. ++ +The C rewrite is first included with Git version 2.20. This option +serves an an escape hatch to re-enable the legacy version in case any +bugs are found in the rewrite. This option and the shellscript version +of linkgit:git-rebase[1] will be removed in some future release. ++ +If you find some reason to set this option to `false` other than +one-off testing you should report the behavior difference as a bug in +git. + rebase.stat:: Whether to show a diffstat of what changed upstream since the last rebase. False by default. diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index aba4c5febe..27304428a1 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -250,6 +250,11 @@ feeding the result to `git send-email`. 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 diff --git a/Documentation/git-range-diff.txt b/Documentation/git-range-diff.txt index f693930fdb..8a6ea2c6c5 100644 --- a/Documentation/git-range-diff.txt +++ b/Documentation/git-range-diff.txt @@ -78,6 +78,23 @@ between patches", i.e. to compare the author, commit message and diff of corresponding old/new commits. There is currently no means to tweak the diff options passed to `git log` when generating those patches. +OUTPUT STABILITY +---------------- + +The output of the `range-diff` command is subject to change. It is +intended to be human-readable porcelain output, not something that can +be used across versions of Git to get a textually stable `range-diff` +(as opposed to something like the `--stable` option to +linkgit:git-patch-id[1]). There's also no equivalent of +linkgit:git-apply[1] for `range-diff`, the output is not intended to +be machine-readable. + +This is particularly true when passing in diff options. Currently some +options like `--stat` can, as an emergent effect, produce output +that's quite useless in the context of `range-diff`. Future versions +of `range-diff` may learn to interpret such options in a manner +specific to `range-diff` (e.g. for `--stat` producing human-readable +output which summarizes how the diffstat changed). CONFIGURATION ------------- diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt index 2dac95c71a..9f69ae8b69 100644 --- a/Documentation/git-reset.txt +++ b/Documentation/git-reset.txt @@ -14,14 +14,14 @@ SYNOPSIS DESCRIPTION ----------- -In the first and second form, copy entries from <tree-ish> to the index. -In the third form, set the current branch head (HEAD) to <commit>, optionally -modifying index and working tree to match. The <tree-ish>/<commit> defaults -to HEAD in all forms. +In the first and second form, copy entries from `<tree-ish>` to the index. +In the third form, set the current branch head (`HEAD`) to `<commit>`, +optionally modifying index and working tree to match. +The `<tree-ish>`/`<commit>` defaults to `HEAD` in all forms. 'git reset' [-q] [<tree-ish>] [--] <paths>...:: - This form resets the index entries for all <paths> to their - state at <tree-ish>. (It does not affect the working tree or + This form resets the index entries for all `<paths>` to their + state at `<tree-ish>`. (It does not affect the working tree or the current branch.) + This means that `git reset <paths>` is the opposite of `git add @@ -36,7 +36,7 @@ working tree in one go. 'git reset' (--patch | -p) [<tree-ish>] [--] [<paths>...]:: Interactively select hunks in the difference between the index - and <tree-ish> (defaults to HEAD). The chosen hunks are applied + and `<tree-ish>` (defaults to `HEAD`). The chosen hunks are applied in reverse to the index. + This means that `git reset -p` is the opposite of `git add -p`, i.e. @@ -44,16 +44,16 @@ you can use it to selectively reset hunks. See the ``Interactive Mode'' section of linkgit:git-add[1] to learn how to operate the `--patch` mode. 'git reset' [<mode>] [<commit>]:: - This form resets the current branch head to <commit> and - possibly updates the index (resetting it to the tree of <commit>) and - the working tree depending on <mode>. If <mode> is omitted, - defaults to "--mixed". The <mode> must be one of the following: + This form resets the current branch head to `<commit>` and + possibly updates the index (resetting it to the tree of `<commit>`) and + the working tree depending on `<mode>`. If `<mode>` is omitted, + defaults to `--mixed`. The `<mode>` must be one of the following: + -- --soft:: Does not touch the index file or the working tree at all (but - resets the head to <commit>, just like all modes do). This leaves - all your changed files "Changes to be committed", as 'git status' + resets the head to `<commit>`, just like all modes do). This leaves + all your changed files "Changes to be committed", as `git status` would put it. --mixed:: @@ -66,24 +66,24 @@ linkgit:git-add[1]). --hard:: Resets the index and working tree. Any changes to tracked files in the - working tree since <commit> are discarded. + working tree since `<commit>` are discarded. --merge:: Resets the index and updates the files in the working tree that are - different between <commit> and HEAD, but keeps those which are + different between `<commit>` and `HEAD`, but keeps those which are different between the index and working tree (i.e. which have changes which have not been added). - If a file that is different between <commit> and the index has unstaged - changes, reset is aborted. + If a file that is different between `<commit>` and the index has + unstaged changes, reset is aborted. + -In other words, --merge does something like a 'git read-tree -u -m <commit>', +In other words, `--merge` does something like a `git read-tree -u -m <commit>`, but carries forward unmerged index entries. --keep:: Resets index entries and updates files in the working tree that are - different between <commit> and HEAD. - If a file that is different between <commit> and HEAD has local changes, - reset is aborted. + different between `<commit>` and `HEAD`. + If a file that is different between `<commit>` and `HEAD` has local + changes, reset is aborted. -- If you want to undo a commit other than the latest on a branch, @@ -116,15 +116,15 @@ $ git pull git://info.example.com/ nitfol <4> + <1> You are happily working on something, and find the changes in these files are in good order. You do not want to see them -when you run "git diff", because you plan to work on other files +when you run `git diff`, because you plan to work on other files and changes with these files are distracting. <2> Somebody asks you to pull, and the changes sound worthy of merging. <3> However, you already dirtied the index (i.e. your index does -not match the HEAD commit). But you know the pull you are going -to make does not affect frotz.c or filfre.c, so you revert the +not match the `HEAD` commit). But you know the pull you are going +to make does not affect `frotz.c` or `filfre.c`, so you revert the index changes for these two files. Your changes in working tree remain there. -<4> Then you can pull and merge, leaving frotz.c and filfre.c +<4> Then you can pull and merge, leaving `frotz.c` and `filfre.c` changes still in the working tree. Undo a commit and redo:: @@ -140,11 +140,11 @@ $ git commit -a -c ORIG_HEAD <3> just committed is incomplete, or you misspelled your commit message, or both. Leaves working tree as it was before "reset". <2> Make corrections to working tree files. -<3> "reset" copies the old head to .git/ORIG_HEAD; redo the +<3> "reset" copies the old head to `.git/ORIG_HEAD`; redo the commit by starting with its log message. If you do not need to -edit the message further, you can give -C option instead. +edit the message further, you can give `-C` option instead. + -See also the --amend option to linkgit:git-commit[1]. +See also the `--amend` option to linkgit:git-commit[1]. Undo a commit, making it a topic branch:: + @@ -155,11 +155,11 @@ $ git checkout topic/wip <3> ------------ + <1> You have made some commits, but realize they were premature -to be in the "master" branch. You want to continue polishing -them in a topic branch, so create "topic/wip" branch off of the -current HEAD. +to be in the `master` branch. You want to continue polishing +them in a topic branch, so create `topic/wip` branch off of the +current `HEAD`. <2> Rewind the master branch to get rid of those three commits. -<3> Switch to "topic/wip" branch and keep working. +<3> Switch to `topic/wip` branch and keep working. Undo commits permanently:: + @@ -168,7 +168,7 @@ $ git commit ... $ git reset --hard HEAD~3 <1> ------------ + -<1> The last three commits (HEAD, HEAD^, and HEAD~2) were bad +<1> The last three commits (`HEAD`, `HEAD^`, and `HEAD~2`) were bad and you do not want to ever see them again. Do *not* do this if you have already given these commits to somebody else. (See the "RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1] for @@ -191,14 +191,14 @@ $ git reset --hard ORIG_HEAD <4> <1> Try to update from the upstream resulted in a lot of conflicts; you were not ready to spend a lot of time merging right now, so you decide to do that later. -<2> "pull" has not made merge commit, so "git reset --hard" -which is a synonym for "git reset --hard HEAD" clears the mess +<2> "pull" has not made merge commit, so `git reset --hard` +which is a synonym for `git reset --hard HEAD` clears the mess from the index file and the working tree. <3> Merge a topic branch into the current branch, which resulted in a fast-forward. <4> But you decided that the topic branch is not ready for public consumption yet. "pull" or "merge" always leaves the original -tip of the current branch in ORIG_HEAD, so resetting hard to it +tip of the current branch in `ORIG_HEAD`, so resetting hard to it brings your index file and the working tree back to that state, and resets the tip of the branch to that commit. @@ -214,14 +214,14 @@ $ git reset --merge ORIG_HEAD <2> ------------ + <1> Even if you may have local modifications in your -working tree, you can safely say "git pull" when you know +working tree, you can safely say `git pull` when you know that the change in the other branch does not overlap with them. <2> After inspecting the result of the merge, you may find that the change in the other branch is unsatisfactory. Running -"git reset --hard ORIG_HEAD" will let you go back to where you +`git reset --hard ORIG_HEAD` will let you go back to where you were, but it will discard your local changes, which you do not -want. "git reset --merge" keeps your local changes. +want. `git reset --merge` keeps your local changes. Interrupted workflow:: @@ -287,13 +287,13 @@ $ git checkout -b branch2 <2> $ git reset --keep start <3> ------------ + -<1> This commits your first edits in branch1. +<1> This commits your first edits in `branch1`. <2> In the ideal world, you could have realized that the earlier commit did not belong to the new topic when you created and switched - to branch2 (i.e. "git checkout -b branch2 start"), but nobody is + to `branch2` (i.e. `git checkout -b branch2 start`), but nobody is perfect. -<3> But you can use "reset --keep" to remove the unwanted commit after - you switched to "branch2". +<3> But you can use `reset --keep` to remove the unwanted commit after + you switched to `branch2`. Split a commit apart into a sequence of commits:: + @@ -317,26 +317,27 @@ $ git commit ... <8> + <1> First, reset the history back one commit so that we remove the original commit, but leave the working tree with all the changes. The -N ensures - that any new files added with HEAD are still marked so that git add -p + that any new files added with `HEAD` are still marked so that `git add -p` will find them. -<2> Next, we interactively select diff hunks to add using the git add -p +<2> Next, we interactively select diff hunks to add using the `git add -p` facility. This will ask you about each diff hunk in sequence and you can use simple commands such as "yes, include this", "No don't include this" or even the very powerful "edit" facility. <3> Once satisfied with the hunks you want to include, you should verify what - has been prepared for the first commit by using git diff --cached. This + has been prepared for the first commit by using `git diff --cached`. This shows all the changes that have been moved into the index and are about to be committed. -<4> Next, commit the changes stored in the index. The -c option specifies to +<4> Next, commit the changes stored in the index. The `-c` option specifies to pre-populate the commit message from the original message that you started - with in the first commit. This is helpful to avoid retyping it. The HEAD@{1} - is a special notation for the commit that HEAD used to be at prior to the - original reset commit (1 change ago). See linkgit:git-reflog[1] for more - details. You may also use any other valid commit reference. + with in the first commit. This is helpful to avoid retyping it. The + `HEAD@{1}` is a special notation for the commit that `HEAD` used to be at + prior to the original reset commit (1 change ago). + See linkgit:git-reflog[1] for more details. You may also use any other + valid commit reference. <5> You can repeat steps 2-4 multiple times to break the original code into any number of commits. <6> Now you've split out many of the changes into their own commits, and might - no longer use the patch mode of git add, in order to select all remaining + no longer use the patch mode of `git add`, in order to select all remaining uncommitted changes. <7> Once again, check to verify that you've included what you want to. You may also wish to verify that git diff doesn't show any remaining changes to be @@ -353,104 +354,120 @@ The tables below show what happens when running: git reset --option target ---------- -to reset the HEAD to another commit (`target`) with the different +to reset the `HEAD` to another commit (`target`) with the different reset options depending on the state of the files. -In these tables, A, B, C and D are some different states of a +In these tables, `A`, `B`, `C` and `D` are some different states of a file. For example, the first line of the first table means that if a -file is in state A in the working tree, in state B in the index, in -state C in HEAD and in state D in the target, then "git reset --soft -target" will leave the file in the working tree in state A and in the -index in state B. It resets (i.e. moves) the HEAD (i.e. the tip of -the current branch, if you are on one) to "target" (which has the file -in state D). - - working index HEAD target working index HEAD - ---------------------------------------------------- - A B C D --soft A B D - --mixed A D D - --hard D D D - --merge (disallowed) - --keep (disallowed) - - working index HEAD target working index HEAD - ---------------------------------------------------- - A B C C --soft A B C - --mixed A C C - --hard C C C - --merge (disallowed) - --keep A C C - - working index HEAD target working index HEAD - ---------------------------------------------------- - B B C D --soft B B D - --mixed B D D - --hard D D D - --merge D D D - --keep (disallowed) - - working index HEAD target working index HEAD - ---------------------------------------------------- - B B C C --soft B B C - --mixed B C C - --hard C C C - --merge C C C - --keep B C C - - working index HEAD target working index HEAD - ---------------------------------------------------- - B C C D --soft B C D - --mixed B D D - --hard D D D - --merge (disallowed) - --keep (disallowed) - - working index HEAD target working index HEAD - ---------------------------------------------------- - B C C C --soft B C C - --mixed B C C - --hard C C C - --merge B C C - --keep B C C - -"reset --merge" is meant to be used when resetting out of a conflicted +file is in state `A` in the working tree, in state `B` in the index, in +state `C` in `HEAD` and in state `D` in the target, then `git reset --soft +target` will leave the file in the working tree in state `A` and in the +index in state `B`. It resets (i.e. moves) the `HEAD` (i.e. the tip of +the current branch, if you are on one) to `target` (which has the file +in state `D`). + +.... +working index HEAD target working index HEAD +---------------------------------------------------- + A B C D --soft A B D + --mixed A D D + --hard D D D + --merge (disallowed) + --keep (disallowed) +.... + +.... +working index HEAD target working index HEAD +---------------------------------------------------- + A B C C --soft A B C + --mixed A C C + --hard C C C + --merge (disallowed) + --keep A C C +.... + +.... +working index HEAD target working index HEAD +---------------------------------------------------- + B B C D --soft B B D + --mixed B D D + --hard D D D + --merge D D D + --keep (disallowed) +.... + +.... +working index HEAD target working index HEAD +---------------------------------------------------- + B B C C --soft B B C + --mixed B C C + --hard C C C + --merge C C C + --keep B C C +.... + +.... +working index HEAD target working index HEAD +---------------------------------------------------- + B C C D --soft B C D + --mixed B D D + --hard D D D + --merge (disallowed) + --keep (disallowed) +.... + +.... +working index HEAD target working index HEAD +---------------------------------------------------- + B C C C --soft B C C + --mixed B C C + --hard C C C + --merge B C C + --keep B C C +.... + +`reset --merge` is meant to be used when resetting out of a conflicted merge. Any mergy operation guarantees that the working tree file that is involved in the merge does not have local change wrt the index before it starts, and that it writes the result out to the working tree. So if we see some difference between the index and the target and also between the index and the working tree, then it means that we are not resetting out from a state that a mergy operation left after failing -with a conflict. That is why we disallow --merge option in this case. +with a conflict. That is why we disallow `--merge` option in this case. -"reset --keep" is meant to be used when removing some of the last +`reset --keep` is meant to be used when removing some of the last commits in the current branch while keeping changes in the working tree. If there could be conflicts between the changes in the commit we want to remove and the changes in the working tree we want to keep, the reset is disallowed. That's why it is disallowed if there are both -changes between the working tree and HEAD, and between HEAD and the +changes between the working tree and `HEAD`, and between `HEAD` and the target. To be safe, it is also disallowed when there are unmerged entries. The following tables show what happens when there are unmerged entries: - working index HEAD target working index HEAD - ---------------------------------------------------- - X U A B --soft (disallowed) - --mixed X B B - --hard B B B - --merge B B B - --keep (disallowed) - - working index HEAD target working index HEAD - ---------------------------------------------------- - X U A A --soft (disallowed) - --mixed X A A - --hard A A A - --merge A A A - --keep (disallowed) - -X means any state and U means an unmerged index. +.... +working index HEAD target working index HEAD +---------------------------------------------------- + X U A B --soft (disallowed) + --mixed X B B + --hard B B B + --merge B B B + --keep (disallowed) +.... + +.... +working index HEAD target working index HEAD +---------------------------------------------------- + X U A A --soft (disallowed) + --mixed X A A + --hard A A A + --merge A A A + --keep (disallowed) +.... + +`X` means any state and `U` means an unmerged index. GIT --- diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt index d501af9d77..366dee238c 100644 --- a/Documentation/gitrepository-layout.txt +++ b/Documentation/gitrepository-layout.txt @@ -290,6 +290,8 @@ worktrees/<id>/locked:: worktrees/<id>/config.worktree:: Working directory specific configuration file. +include::technical/repository-version.txt[] + SEE ALSO -------- linkgit:git-init[1], diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt index 829b558110..2b036d7838 100644 --- a/Documentation/technical/api-parse-options.txt +++ b/Documentation/technical/api-parse-options.txt @@ -183,10 +183,6 @@ There are some macros to easily define options: scale the provided value by 1024, 1024^2 or 1024^3 respectively. The scaled value is put into `unsigned_long_var`. -`OPT_DATE(short, long, ×tamp_t_var, description)`:: - Introduce an option with date argument, see `approxidate()`. - The timestamp is put into `timestamp_t_var`. - `OPT_EXPIRY_DATE(short, long, ×tamp_t_var, description)`:: Introduce an option with expiry date argument, see `parse_expiry_date()`. The timestamp is put into `timestamp_t_var`. diff --git a/Documentation/technical/repository-version.txt b/Documentation/technical/repository-version.txt index e03eaccebc..7844ef30ff 100644 --- a/Documentation/technical/repository-version.txt +++ b/Documentation/technical/repository-version.txt @@ -1,5 +1,4 @@ -Git Repository Format Versions -============================== +== Git Repository Format Versions Every git repository is marked with a numeric version in the `core.repositoryformatversion` key of its `config` file. This version @@ -40,16 +39,14 @@ format by default. The currently defined format versions are: -Version `0` ------------ +=== Version `0` This is the format defined by the initial version of git, including but not limited to the format of the repository directory, the repository configuration file, and the object and ref storage. Specifying the complete behavior of git is beyond the scope of this document. -Version `1` ------------ +=== Version `1` This format is identical to version `0`, with the following exceptions: @@ -74,21 +71,18 @@ it here, in order to claim the name. The defined extensions are: -`noop` -~~~~~~ +==== `noop` This extension does not change git's behavior at all. It is useful only for testing format-1 compatibility. -`preciousObjects` -~~~~~~~~~~~~~~~~~ +==== `preciousObjects` When the config key `extensions.preciousObjects` is set to `true`, objects in the repository MUST NOT be deleted (e.g., by `git-prune` or `git repack -d`). -`partialclone` -~~~~~~~~~~~~~~ +==== `partialclone` When the config key `extensions.partialclone` is set, it indicates that the repo was created with a partial clone (or later performed @@ -98,3 +92,11 @@ and it promises that all such omitted objects can be fetched from it in the future. The value of this key is the name of the promisor remote. + +==== `worktreeConfig` + +If set, by default "git config" reads from both "config" and +"config.worktree" file from GIT_DIR in that order. In +multiple working directory mode, "config" file is shared while +"config.worktree" is per-working directory (i.e., it's in +GIT_COMMON_DIR/worktrees/<id>/config.worktree) |