diff --git a/MyFirstObjectWalk.html b/MyFirstObjectWalk.html index 9e90f9901..a6490133a 100644 --- a/MyFirstObjectWalk.html +++ b/MyFirstObjectWalk.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/RelNotes/2.44.0.txt b/RelNotes/2.44.0.txt index e58095fc8..020692cda 100644 --- a/RelNotes/2.44.0.txt +++ b/RelNotes/2.44.0.txt @@ -32,7 +32,11 @@ UI, Workflows & Features breaking change. "--ignore-other-worktrees" option is required to unbreak you, if you are used to the current behaviour that "-B" overrides the safety. - (merge b23285a921 jc/checkout-B-branch-in-use later to maint). + + * The builtin_objectmode attribute is populated for each path + without adding anything in .gitattributes files, which would be + useful in magic pathspec, e.g., ":(attr:builtin_objectmode=100755)" + to limit to executables. Performance, Internal Implementation, Development Support etc. @@ -64,6 +68,10 @@ Performance, Internal Implementation, Development Support etc. non-default hash function into a repository that uses the reftable backend. + * Streaming spans of packfile data used to be done only from a + single, primary, pack in a repository with multiple packfiles. It + has been extended to allow reuse from other packfiles, too. + Fixes since v2.43 ----------------- @@ -154,6 +162,11 @@ Fixes since v2.43 * "git sparse-checkout (add|set) --[no-]cone --end-of-options" did not handle "--end-of-options" correctly after a recent update. + * Unlike other environment variables that took the usual + true/false/yes/no as well as 0/1, GIT_FLUSH only understood 0/1, + which has been corrected. + (merge 556e68032f cp/git-flush-is-an-env-bool later to maint). + * Other code cleanup, docfix, build fix, etc. (merge 50f1abcff6 js/packfile-h-typofix later to maint). (merge cbf498eb53 jb/reflog-expire-delete-dry-run-options later to maint). @@ -178,3 +191,7 @@ Fixes since v2.43 (merge 63956c553d ml/doc-merge-updates later to maint). (merge d57c671a51 en/header-cleanup later to maint). (merge 5b7eec4bc5 rs/fast-import-simplify-mempool-allocation later to maint). + (merge 291873e5d6 js/contributor-docs-updates later to maint). + (merge 54d8a2531b jk/t1006-cat-file-objectsize-disk later to maint). + (merge 7033d5479b jx/sideband-chomp-newline-fix later to maint). + (merge 9cd30af991 ms/rebase-insnformat-doc-fix later to maint). diff --git a/ReviewingGuidelines.html b/ReviewingGuidelines.html index 6c1691388..69784726b 100644 --- a/ReviewingGuidelines.html +++ b/ReviewingGuidelines.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/SubmittingPatches.html b/SubmittingPatches.html index 8835e3fe3..e01b8d8e4 100644 --- a/SubmittingPatches.html +++ b/SubmittingPatches.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -1144,9 +1144,36 @@ don’t hide your real name.

and found it to have the desired effect.

+Co-authored-by: is used to indicate that people exchanged drafts + of a patch before submitting it. +

+Helped-by: is used to credit someone who suggested ideas for + changes without providing the precise changes in patch form. +

+Mentored-by: is used to credit someone with helping develop a + patch as part of a mentorship program (e.g., GSoC or Outreachy). +

+Suggested-by: is used to credit someone with suggesting the idea + for a patch. +

You can also create your own tag or use one that’s in common usage -such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:".

While you can also create your own trailer if the situation warrants it, we +encourage you to instead use one of the common trailers in this project +highlighted above.

Only capitalize the very first letter of tags, i.e. favor +"Signed-off-by" over "Signed-Off-By" and "Acked-by:" over "Acked-By".

Generate your patch using Git tools out of your commits.

@@ -1388,7 +1415,7 @@ You can use Git itself to find out when your patch is merged in

Read the Git mailing list, the maintainer regularly posts messages - entitled "What’s cooking in git.git" and "What’s in git.git" giving + entitled "What’s cooking in git.git" giving the status of various proposed changes.

@@ -1415,11 +1442,12 @@ Fork https://github.com/git/git to your

After the initial setup, CI will run whenever you push new changes to your fork of Git on GitHub. You can monitor the test state of all your branches here: https://github.com/<Your GitHub handle>/git/actions/workflows/main.yml

If a branch did not pass all test cases then it is marked with a red -cross. In that case you can click on the failing job and navigate to -"ci/run-build-and-tests.sh" and/or "ci/print-test-failures.sh". You -can also download "Artifacts" which are tarred (or zipped) archives -with test data relevant for debugging.

If a branch does not pass all test cases then it will be marked with a +red x, instead of a green check. In that case, you can click on the +failing job and navigate to "ci/run-build-and-tests.sh" and/or +"ci/print-test-failures.sh". You can also download "Artifacts" which +are zip archives containing tarred (or zipped) archives with test data +relevant for debugging.

Then fix the problem and push your fix to your GitHub fork. This will trigger a new CI build to ensure all tests pass.

@@ -1505,7 +1533,7 @@ message to an external program, and this is a handy way to drive git am. However, if the message is MIME encoded, what is piped into the program is the representation you see in your *Article* buffer after unwrapping MIME. This is often not what -you would want for two reasons. It tends to screw up non ASCII +you would want for two reasons. It tends to screw up non-ASCII characters (most notably in people’s names), and also whitespaces (fatal in patches). Running "C-u g" to display the message in raw form before using "|" to run the pipe can work @@ -1518,7 +1546,7 @@ this problem around.

diff --git a/SubmittingPatches.txt b/SubmittingPatches.txt index bce7f9781..e734a3f0f 100644 --- a/SubmittingPatches.txt +++ b/SubmittingPatches.txt @@ -355,9 +355,21 @@ If you like, you can put extra tags at the end: patch after a detailed analysis. . `Tested-by:` is used to indicate that the person applied the patch and found it to have the desired effect. - -You can also create your own tag or use one that's in common usage -such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:". +. `Co-authored-by:` is used to indicate that people exchanged drafts + of a patch before submitting it. +. `Helped-by:` is used to credit someone who suggested ideas for + changes without providing the precise changes in patch form. +. `Mentored-by:` is used to credit someone with helping develop a + patch as part of a mentorship program (e.g., GSoC or Outreachy). +. `Suggested-by:` is used to credit someone with suggesting the idea + for a patch. + +While you can also create your own trailer if the situation warrants it, we +encourage you to instead use one of the common trailers in this project +highlighted above. + +Only capitalize the very first letter of tags, i.e. favor +"Signed-off-by" over "Signed-Off-By" and "Acked-by:" over "Acked-By". [[git-tools]] === Generate your patch using Git tools out of your commits. @@ -570,7 +582,7 @@ their trees themselves. master). * Read the Git mailing list, the maintainer regularly posts messages - entitled "What's cooking in git.git" and "What's in git.git" giving + entitled "What's cooking in git.git" giving the status of various proposed changes. == GitHub CI[[GHCI]] @@ -590,11 +602,12 @@ After the initial setup, CI will run whenever you push new changes to your fork of Git on GitHub. You can monitor the test state of all your branches here: `https://github.com//git/actions/workflows/main.yml` -If a branch did not pass all test cases then it is marked with a red -cross. In that case you can click on the failing job and navigate to -"ci/run-build-and-tests.sh" and/or "ci/print-test-failures.sh". You -can also download "Artifacts" which are tarred (or zipped) archives -with test data relevant for debugging. +If a branch does not pass all test cases then it will be marked with a +red +x+, instead of a green check. In that case, you can click on the +failing job and navigate to "ci/run-build-and-tests.sh" and/or +"ci/print-test-failures.sh". You can also download "Artifacts" which +are zip archives containing tarred (or zipped) archives with test data +relevant for debugging. Then fix the problem and push your fix to your GitHub fork. This will trigger a new CI build to ensure all tests pass. @@ -686,7 +699,7 @@ message to an external program, and this is a handy way to drive `git am`. However, if the message is MIME encoded, what is piped into the program is the representation you see in your `*Article*` buffer after unwrapping MIME. This is often not what -you would want for two reasons. It tends to screw up non ASCII +you would want for two reasons. It tends to screw up non-ASCII characters (most notably in people's names), and also whitespaces (fatal in patches). Running "C-u g" to display the message in raw form before using "|" to run the pipe can work diff --git a/ToolsForGit.html b/ToolsForGit.html index 4b39d1445..ea302ec32 100644 --- a/ToolsForGit.html +++ b/ToolsForGit.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/everyday.html b/everyday.html index 5e3a5680a..e3482b8aa 100644 --- a/everyday.html +++ b/everyday.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/git-config.html b/git-config.html index 87adc6591..bcf672fec 100644 --- a/git-config.html +++ b/git-config.html @@ -8998,12 +8998,20 @@ pack.allowPackReuse

- When true, and when reachability bitmaps are enabled, - pack-objects will try to send parts of the bitmapped packfile - verbatim. This can reduce memory and CPU usage to serve fetches, - but might result in sending a slightly larger pack. Defaults to - true. + When true or "single", and when reachability bitmaps are + enabled, pack-objects will try to send parts of the bitmapped + packfile verbatim. When "multi", and when a multi-pack + reachability bitmap is available, pack-objects will try to send + parts of all packs in the MIDX.

If only a single pack bitmap is available, and
+`pack.allowPackReuse` is set to "multi", reuse parts of just the
+bitmapped packfile. This can reduce memory and CPU usage to
+serve fetches, but might result in sending a slightly larger
+pack. Defaults to true.

pack.island @@ -9707,7 +9715,7 @@ rebase.instructionFormat

A format string, as specified in git-log(1), to be used for the todo list during an interactive rebase. The format will - automatically have the long commit hash prepended to the format. + automatically have the commit hash prepended to the format.

diff --git a/git-rebase.html b/git-rebase.html index dc91f9f38..5c262155c 100644 --- a/git-rebase.html +++ b/git-rebase.html @@ -1458,7 +1458,7 @@ merge backend

The commit list format can be changed by setting the configuration option rebase.instructionFormat. A customized instruction format will automatically -have the long commit hash prepended to the format.

+have the commit hash prepended to the format.

RESERVED BUILTIN_* ATTRIBUTES

builtin_* is a reserved namespace for builtin attribute values. Any +user defined attributes under this namespace will be ignored and +trigger a warning.

`builtin_objectmode`

This attribute is for filtering files by their file bit modes (40000, +120000, 160000, 100755, 100644). e.g. :(attr:builtin_objectmode=160000). +You may also check these values with git check-attr builtin_objectmode -- <file>. +If the object is not in the index git check-attr --cached will return unspecified.

EFFECTS

Certain operations by Git can be influenced by assigning @@ -2246,7 +2261,7 @@ frotz unspecified

diff --git a/gitattributes.txt b/gitattributes.txt index 8c1793c14..201bdf5ed 100644 --- a/gitattributes.txt +++ b/gitattributes.txt @@ -100,6 +100,21 @@ for a path to `Unspecified` state. This can be done by listing the name of the attribute prefixed with an exclamation point `!`. +RESERVED BUILTIN_* ATTRIBUTES +----------------------------- + +builtin_* is a reserved namespace for builtin attribute values. Any +user defined attributes under this namespace will be ignored and +trigger a warning. + +`builtin_objectmode` +~~~~~~~~~~~~~~~~~~~~ +This attribute is for filtering files by their file bit modes (40000, +120000, 160000, 100755, 100644). e.g. ':(attr:builtin_objectmode=160000)'. +You may also check these values with `git check-attr builtin_objectmode -- `. +If the object is not in the index `git check-attr --cached` will return unspecified. + + EFFECTS ------- diff --git a/gitformat-pack.html b/gitformat-pack.html index 0ec60b5ab..b5bed832f 100644 --- a/gitformat-pack.html +++ b/gitformat-pack.html @@ -1313,6 +1313,17 @@ otherwise specified.

Bitmapped Packfiles (ID: {'B', 'T', 'M', 'P'})
+    Stores a table of two 4-byte unsigned integers in network order.
+    Each table entry corresponds to a single pack (in the order that
+    they appear above in the `PNAM` chunk). The values for each table
+    entry are as follows:
+    - The first bit position (in pseudo-pack order, see below) to
+      contain an object from that pack.
+    - The number of bits whose objects are selected from that pack.

OID Fanout (ID: {'O', 'I', 'D', 'F'})
     The ith entry, F[i], stores the number of OIDs with first
     byte at most i. Thus F[255] stores the total
@@ -1439,6 +1450,106 @@ objects in packs stored by the MIDX, laid out in pack order, and the
 packs arranged in MIDX order (with the preferred pack coming first).


 The MIDX’s reverse index is stored in the optional RIDX chunk within
 the MIDX itself.
+


+BTMP chunk
+The Bitmapped Packfiles (BTMP) chunk encodes additional information
+about the objects in the multi-pack index’s reachability bitmap. Recall
+that objects from the MIDX are arranged in "pseudo-pack" order (see
+above) for reachability bitmaps.
+From the example above, suppose we have packs "a", "b", and "c", with
+10, 15, and 20 objects, respectively. In pseudo-pack order, those would
+be arranged as follows:
+
+
+|a,0|a,1|...|a,9|b,0|b,1|...|b,14|c,0|c,1|...|c,19|
+
+When working with single-pack bitmaps (or, equivalently, multi-pack
+reachability bitmaps with a preferred pack), git-pack-objects(1)
+performs “verbatim” reuse, attempting to reuse chunks of the bitmapped
+or preferred packfile instead of adding objects to the packing list.
+When a chunk of bytes is reused from an existing pack, any objects
+contained therein do not need to be added to the packing list, saving
+memory and CPU time. But a chunk from an existing packfile can only be
+reused when the following conditions are met:
+
+
+
+The chunk contains only objects which were requested by the caller
+    (i.e. does not contain any objects which the caller didn’t ask for
+    explicitly or implicitly).
+
+
+
+
+All objects stored in non-thin packs as offset- or reference-deltas
+    also include their base object in the resulting pack.
+
+
+
+The BTMP chunk encodes the necessary information in order to implement
+multi-pack reuse over a set of packfiles as described above.
+Specifically, the BTMP chunk encodes three pieces of information (all
+32-bit unsigned integers in network byte-order) for each packfile p
+that is stored in the MIDX, as follows:
+
+
+bitmap_pos
+
+
+
+The first bit position (in pseudo-pack order) in the
+  multi-pack index’s reachability bitmap occupied by an object from p.
+
+
+
+bitmap_nr
+
+
+
+The number of bit positions (including the one at
+  bitmap_pos) that encode objects from that pack p.
+
+
+
+For example, the BTMP chunk corresponding to the above example (with
+packs “a”, “b”, and “c”) would look like:
+
+
++++
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+


bitmap_pos bitmap_nr
packfile “a” 0 10
packfile “b” 10 15
packfile “c” 25 20
+
+With this information in place, we can treat each packfile as
+individually reusable in the same fashion as verbatim pack reuse is
+performed on individual packs prior to the implementation of the BTMP
+chunk.
+


@@ -1553,7 +1664,7 @@ support for optional chunks of data, it may make sense to consolidate the
 
 
 Last updated
- 2023-11-08 09:04:31 PST
+ 2024-01-12 16:26:54 PST
 
 
 
diff --git a/gitformat-pack.txt b/gitformat-pack.txt
index 9fcb29a9c..d6ae229be 100644
--- a/gitformat-pack.txt
+++ b/gitformat-pack.txt
@@ -396,6 +396,15 @@ CHUNK DATA:
 	    is padded at the end with between 0 and 3 NUL bytes to make the
 	    chunk size a multiple of 4 bytes.
 
+	Bitmapped Packfiles (ID: {'B', 'T', 'M', 'P'})
+	    Stores a table of two 4-byte unsigned integers in network order.
+	    Each table entry corresponds to a single pack (in the order that
+	    they appear above in the `PNAM` chunk). The values for each table
+	    entry are as follows:
+	    - The first bit position (in pseudo-pack order, see below) to
+	      contain an object from that pack.
+	    - The number of bits whose objects are selected from that pack.
+
 	OID Fanout (ID: {'O', 'I', 'D', 'F'})
 	    The ith entry, F[i], stores the number of OIDs with first
 	    byte at most i. Thus F[255] stores the total
@@ -509,6 +518,73 @@ packs arranged in MIDX order (with the preferred pack coming first).
 The MIDX's reverse index is stored in the optional 'RIDX' chunk within
 the MIDX itself.
 
+=== `BTMP` chunk
+
+The Bitmapped Packfiles (`BTMP`) chunk encodes additional information
+about the objects in the multi-pack index's reachability bitmap. Recall
+that objects from the MIDX are arranged in "pseudo-pack" order (see
+above) for reachability bitmaps.
+
+From the example above, suppose we have packs "a", "b", and "c", with
+10, 15, and 20 objects, respectively. In pseudo-pack order, those would
+be arranged as follows:
+
+    |a,0|a,1|...|a,9|b,0|b,1|...|b,14|c,0|c,1|...|c,19|
+
+When working with single-pack bitmaps (or, equivalently, multi-pack
+reachability bitmaps with a preferred pack), linkgit:git-pack-objects[1]
+performs ``verbatim'' reuse, attempting to reuse chunks of the bitmapped
+or preferred packfile instead of adding objects to the packing list.
+
+When a chunk of bytes is reused from an existing pack, any objects
+contained therein do not need to be added to the packing list, saving
+memory and CPU time. But a chunk from an existing packfile can only be
+reused when the following conditions are met:
+
+  - The chunk contains only objects which were requested by the caller
+    (i.e. does not contain any objects which the caller didn't ask for
+    explicitly or implicitly).
+
+  - All objects stored in non-thin packs as offset- or reference-deltas
+    also include their base object in the resulting pack.
+
+The `BTMP` chunk encodes the necessary information in order to implement
+multi-pack reuse over a set of packfiles as described above.
+Specifically, the `BTMP` chunk encodes three pieces of information (all
+32-bit unsigned integers in network byte-order) for each packfile `p`
+that is stored in the MIDX, as follows:
+
+`bitmap_pos`:: The first bit position (in pseudo-pack order) in the
+  multi-pack index's reachability bitmap occupied by an object from `p`.
+
+`bitmap_nr`:: The number of bit positions (including the one at
+  `bitmap_pos`) that encode objects from that pack `p`.
+
+For example, the `BTMP` chunk corresponding to the above example (with
+packs ``a'', ``b'', and ``c'') would look like:
+
+[cols="1,2,2"]
+|===
+| |`bitmap_pos` |`bitmap_nr`
+
+|packfile ``a''
+|`0`
+|`10`
+
+|packfile ``b''
+|`10`
+|`15`
+
+|packfile ``c''
+|`25`
+|`20`
+|===
+
+With this information in place, we can treat each packfile as
+individually reusable in the same fashion as verbatim pack reuse is
+performed on individual packs prior to the implementation of the `BTMP`
+chunk.
+
 == cruft packs
 
 The cruft packs feature offer an alternative to Git's traditional mechanism of
diff --git a/howto/coordinate-embargoed-releases.html b/howto/coordinate-embargoed-releases.html
index 7a69d7349..47c99846b 100644
--- a/howto/coordinate-embargoed-releases.html
+++ b/howto/coordinate-embargoed-releases.html
@@ -1038,7 +1038,7 @@ Thanks,
 
 
 Last updated
- 2024-01-08 14:59:19 PST
+ 2024-01-12 16:27:46 PST
 
 
 
diff --git a/howto/keep-canonical-history-correct.html b/howto/keep-canonical-history-correct.html
index 12954df0e..6bc8a5551 100644
--- a/howto/keep-canonical-history-correct.html
+++ b/howto/keep-canonical-history-correct.html
@@ -735,7 +735,7 @@ asciidoc.install();
 
 
 Keep authoritative canonical history correct with git pull
-2024-01-08
+2024-01-12


 
@@ -939,7 +939,7 @@ tip of your master again and redo the two merges:
 
 
 Last updated
- 2024-01-08 14:59:19 PST
+ 2024-01-12 16:27:46 PST
 
 
 
diff --git a/howto/maintain-git.html b/howto/maintain-git.html
index 01be75bb0..e4b18f97f 100644
--- a/howto/maintain-git.html
+++ b/howto/maintain-git.html
@@ -735,7 +735,7 @@ asciidoc.install();
 
 
 How to maintain Git
-2024-01-08
+2024-01-12


@@ -1479,7 +1479,7 @@ $ git update-ref -d $mf/ai/topic

diff --git a/howto/new-command.html b/howto/new-command.html index 64293890e..a30667c7d 100644 --- a/howto/new-command.html +++ b/howto/new-command.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -864,7 +864,7 @@ letter [PATCH 0/n]. diff --git a/howto/rebase-from-internal-branch.html b/howto/rebase-from-internal-branch.html index 32a21ec2c..ed07382ea 100644 --- a/howto/rebase-from-internal-branch.html +++ b/howto/rebase-from-internal-branch.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -896,7 +896,7 @@ the #1' commit.

diff --git a/howto/rebuild-from-update-hook.html b/howto/rebuild-from-update-hook.html index 9fd511724..13019904a 100644 --- a/howto/rebuild-from-update-hook.html +++ b/howto/rebuild-from-update-hook.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -848,7 +848,7 @@ This is still crude and does not protect against simultaneous diff --git a/howto/recover-corrupted-blob-object.html b/howto/recover-corrupted-blob-object.html index b4bbeb5dc..ae56e41e9 100644 --- a/howto/recover-corrupted-blob-object.html +++ b/howto/recover-corrupted-blob-object.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -881,7 +881,7 @@ thing.

diff --git a/howto/recover-corrupted-object-harder.html b/howto/recover-corrupted-object-harder.html index db8fa8408..0834ae81d 100644 --- a/howto/recover-corrupted-object-harder.html +++ b/howto/recover-corrupted-object-harder.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -1190,7 +1190,7 @@ int main(int argc, char **argv) diff --git a/howto/revert-a-faulty-merge.html b/howto/revert-a-faulty-merge.html index 572fdab7c..4e223be67 100644 --- a/howto/revert-a-faulty-merge.html +++ b/howto/revert-a-faulty-merge.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -1026,7 +1026,7 @@ P---o---o---M---x---x---W---x---M2 diff --git a/howto/revert-branch-rebase.html b/howto/revert-branch-rebase.html index e947d5ffb..7c16cbbe9 100644 --- a/howto/revert-branch-rebase.html +++ b/howto/revert-branch-rebase.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -908,7 +908,7 @@ Committed merge 7fb9b7262a1d1e0a47bbfdcbbcf50ce0635d3f8f diff --git a/howto/separating-topic-branches.html b/howto/separating-topic-branches.html index 6d8f42d64..9b97ea148 100644 --- a/howto/separating-topic-branches.html +++ b/howto/separating-topic-branches.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -842,7 +842,7 @@ o---o"master" diff --git a/howto/setup-git-server-over-http.html b/howto/setup-git-server-over-http.html index e751d3126..606cc37f7 100644 --- a/howto/setup-git-server-over-http.html +++ b/howto/setup-git-server-over-http.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -1072,7 +1072,7 @@ help diagnosing the problem, but removes security checks.

diff --git a/howto/update-hook-example.html b/howto/update-hook-example.html index 23f116236..ae4518a90 100644 --- a/howto/update-hook-example.html +++ b/howto/update-hook-example.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -931,7 +931,7 @@ that JC can make non-fast-forward pushes on it.

diff --git a/howto/use-git-daemon.html b/howto/use-git-daemon.html index 6f39de962..81aa216c3 100644 --- a/howto/use-git-daemon.html +++ b/howto/use-git-daemon.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -792,7 +792,7 @@ a good practice to put the paths after a "--" separator.

diff --git a/howto/using-merge-subtree.html b/howto/using-merge-subtree.html index e7e47be05..a2957f55c 100644 --- a/howto/using-merge-subtree.html +++ b/howto/using-merge-subtree.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -849,7 +849,7 @@ Please note that if the other project merges from you, then it will diff --git a/howto/using-signed-tag-in-pull-request.html b/howto/using-signed-tag-in-pull-request.html index 8b1a0a581..f4c0276f1 100644 --- a/howto/using-signed-tag-in-pull-request.html +++ b/howto/using-signed-tag-in-pull-request.html @@ -735,7 +735,7 @@ asciidoc.install();

@@ -953,7 +953,7 @@ as part of the merge commit.

diff --git a/technical/api-error-handling.html b/technical/api-error-handling.html index b0600ece5..c13fa7727 100644 --- a/technical/api-error-handling.html +++ b/technical/api-error-handling.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/api-index.html b/technical/api-index.html index ffa024fde..df27b8b3c 100644 --- a/technical/api-index.html +++ b/technical/api-index.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/api-merge.html b/technical/api-merge.html index 2bd48b943..4d3d61919 100644 --- a/technical/api-merge.html +++ b/technical/api-merge.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/api-parse-options.html b/technical/api-parse-options.html index d0a2c61f0..4c22893aa 100644 --- a/technical/api-parse-options.html +++ b/technical/api-parse-options.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/api-simple-ipc.html b/technical/api-simple-ipc.html index 80710408e..b06db3517 100644 --- a/technical/api-simple-ipc.html +++ b/technical/api-simple-ipc.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/api-trace2.html b/technical/api-trace2.html index 684a2a5aa..98d4481a1 100644 --- a/technical/api-trace2.html +++ b/technical/api-trace2.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/bitmap-format.html b/technical/bitmap-format.html index b39d1e19d..f2d89a828 100644 --- a/technical/bitmap-format.html +++ b/technical/bitmap-format.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/bundle-uri.html b/technical/bundle-uri.html index 7313463e7..7aebcd58b 100644 --- a/technical/bundle-uri.html +++ b/technical/bundle-uri.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/hash-function-transition.html b/technical/hash-function-transition.html index 8734a3337..7d6a6457e 100644 --- a/technical/hash-function-transition.html +++ b/technical/hash-function-transition.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/long-running-process-protocol.html b/technical/long-running-process-protocol.html index 92adefcf3..90e3f779a 100644 --- a/technical/long-running-process-protocol.html +++ b/technical/long-running-process-protocol.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/multi-pack-index.html b/technical/multi-pack-index.html index 3c9c375a3..25a5838cc 100644 --- a/technical/multi-pack-index.html +++ b/technical/multi-pack-index.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/pack-heuristics.html b/technical/pack-heuristics.html index 0ddd5de9f..982f126ff 100644 --- a/technical/pack-heuristics.html +++ b/technical/pack-heuristics.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/parallel-checkout.html b/technical/parallel-checkout.html index aade7fbb5..ab9f48f98 100644 --- a/technical/parallel-checkout.html +++ b/technical/parallel-checkout.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/partial-clone.html b/technical/partial-clone.html index d583f22e9..04a96027d 100644 --- a/technical/partial-clone.html +++ b/technical/partial-clone.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/racy-git.html b/technical/racy-git.html index b61698977..76ef1d616 100644 --- a/technical/racy-git.html +++ b/technical/racy-git.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/scalar.html b/technical/scalar.html index 63dce4bb6..da3d9ff22 100644 --- a/technical/scalar.html +++ b/technical/scalar.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/send-pack-pipeline.html b/technical/send-pack-pipeline.html index 8fa0a3cdd..dde6e0a74 100644 --- a/technical/send-pack-pipeline.html +++ b/technical/send-pack-pipeline.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/shallow.html b/technical/shallow.html index 540e7724c..5fb24a4ed 100644 --- a/technical/shallow.html +++ b/technical/shallow.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/trivial-merge.html b/technical/trivial-merge.html index 31647e04b..df41036fc 100644 --- a/technical/trivial-merge.html +++ b/technical/trivial-merge.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/technical/unit-tests.html b/technical/unit-tests.html index 9edc9c072..0ed44a232 100644 --- a/technical/unit-tests.html +++ b/technical/unit-tests.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/user-manual.html b/user-manual.html index c0e387a16..ff093dc48 100644 --- a/user-manual.html +++ b/user-manual.html @@ -1,5 +1,5 @@ -Git User Manual

Git User Manual

Revision History
	2024-01-08

Table of Contents

Introduction

1. Repositories and Branches

How to get a Git repository

How to check out a different version of a project

Understanding History: Commits

Understanding history: commits, parents, and reachability
Understanding history: History diagrams
Understanding history: What is a branch?

Manipulating branches

Examining an old version without creating a new branch

Examining branches from a remote repository

Naming branches, tags, and other references

Updating a repository with git fetch

Fetching branches from other repositories

2. Exploring Git history

How to use bisect to find a regression

Naming commits

Creating tags

Browsing revisions

Generating diffs

Viewing old file versions

Examples

Counting the number of commits on a branch
Check whether two branches point at the same history
Find first tagged version including a given fix
Showing commits unique to a given branch
Creating a changelog and tarball for a software release
Finding commits referencing a file with given content

3. Developing with Git

Telling Git your name

Creating a new repository

How to make a commit

Creating good commit messages

Ignoring files

How to merge

Resolving a merge

Getting conflict-resolution help during a merge

Undoing a merge

Fast-forward merges

Fixing mistakes

Fixing a mistake with a new commit
Fixing a mistake by rewriting history
Checking out an old version of a file
Temporarily setting aside work in progress

Ensuring good performance

Ensuring reliability

Checking the repository for corruption
Recovering lost changes

4. Sharing development with others

Getting updates with git pull

Submitting patches to a project

Importing patches to a project

Public Git repositories

Setting up a public repository
Exporting a Git repository via the Git protocol
Exporting a git repository via HTTP
Pushing changes to a public repository
What to do when a push fails
Setting up a shared repository
Allowing web browsing of a repository

How to get a Git repository with minimal history

Examples

Maintaining topic branches for a Linux subsystem maintainer

5. Rewriting history and maintaining patch series

Creating the perfect patch series
Keeping a patch series up to date using git rebase
Rewriting a single commit
Reordering or selecting from a patch series
Using interactive rebases
Other tools
Problems with rewriting history
Why bisecting merge commits can be harder than bisecting linear history

6. Advanced branch management

Fetching individual branches
git fetch and fast-forwards
Forcing git fetch to do non-fast-forward updates
Configuring remote-tracking branches

7. Git concepts

The Object Database

Commit Object
Tree Object
Blob Object
Trust
Tag Object
How Git stores objects efficiently: pack files
Dangling objects
Recovering from repository corruption

The index

8. Submodules

Pitfalls with submodules

9. Low-level Git operations

Object access and manipulation

The Workflow

working directory → index
index → object database
object database → index
index → working directory
Tying it all together

Examining the data

Merging multiple trees

Merging multiple trees, continued

10. Hacking Git

Object storage format
A birds-eye view of Git’s source code

11. Git Glossary

Git explained

A. Git Quick Reference

Creating a new repository
Managing branches
Exploring history
Making changes
Merging
Sharing your changes
Repository maintenance

B. Notes and todo list for this manual

Todo list

Introduction

Git is a fast distributed revision control system.

This manual is designed to be readable by someone with basic UNIX +Git User Manual

Git User Manual

Revision History
	2024-01-12

Table of Contents

Introduction

1. Repositories and Branches

How to get a Git repository

How to check out a different version of a project

Understanding History: Commits

Understanding history: commits, parents, and reachability
Understanding history: History diagrams
Understanding history: What is a branch?

Manipulating branches

Examining an old version without creating a new branch

Examining branches from a remote repository

Naming branches, tags, and other references

Updating a repository with git fetch

Fetching branches from other repositories

2. Exploring Git history

How to use bisect to find a regression

Naming commits

Creating tags

Browsing revisions

Generating diffs

Viewing old file versions

Examples

Counting the number of commits on a branch
Check whether two branches point at the same history
Find first tagged version including a given fix
Showing commits unique to a given branch
Creating a changelog and tarball for a software release
Finding commits referencing a file with given content

3. Developing with Git

Telling Git your name

Creating a new repository

How to make a commit

Creating good commit messages

Ignoring files

How to merge

Resolving a merge

Getting conflict-resolution help during a merge

Undoing a merge

Fast-forward merges

Fixing mistakes

Fixing a mistake with a new commit
Fixing a mistake by rewriting history
Checking out an old version of a file
Temporarily setting aside work in progress

Ensuring good performance

Ensuring reliability

Checking the repository for corruption
Recovering lost changes

4. Sharing development with others

Getting updates with git pull

Submitting patches to a project

Importing patches to a project

Public Git repositories

Setting up a public repository
Exporting a Git repository via the Git protocol
Exporting a git repository via HTTP
Pushing changes to a public repository
What to do when a push fails
Setting up a shared repository
Allowing web browsing of a repository

How to get a Git repository with minimal history

Examples

Maintaining topic branches for a Linux subsystem maintainer

5. Rewriting history and maintaining patch series

Creating the perfect patch series
Keeping a patch series up to date using git rebase
Rewriting a single commit
Reordering or selecting from a patch series
Using interactive rebases
Other tools
Problems with rewriting history
Why bisecting merge commits can be harder than bisecting linear history

6. Advanced branch management

Fetching individual branches
git fetch and fast-forwards
Forcing git fetch to do non-fast-forward updates
Configuring remote-tracking branches

7. Git concepts

The Object Database

Commit Object
Tree Object
Blob Object
Trust
Tag Object
How Git stores objects efficiently: pack files
Dangling objects
Recovering from repository corruption

The index

8. Submodules

Pitfalls with submodules

9. Low-level Git operations

Object access and manipulation

The Workflow

working directory → index
index → object database
object database → index
index → working directory
Tying it all together

Examining the data

Merging multiple trees

Merging multiple trees, continued

10. Hacking Git

Object storage format
A birds-eye view of Git’s source code

11. Git Glossary

Git explained

A. Git Quick Reference

Creating a new repository
Managing branches
Exploring history
Making changes
Merging
Sharing your changes
Repository maintenance

B. Notes and todo list for this manual

Todo list

Introduction

Git is a fast distributed revision control system.

This manual is designed to be readable by someone with basic UNIX command-line skills, but no previous knowledge of Git.

Chapter 1, Repositories and Branches and Chapter 2, Exploring Git history explain how to fetch and study a project using git—read these chapters to learn how to build and test a particular version of a software project, search for -- cgit 1.2.3-korg

	`bitmap_pos`	`bitmap_nr`
packfile “a”	`0`	`10`
packfile “b”	`10`	`15`
packfile “c”	`25`	`20`

My First Contribution to the Git Project

My First Object Walk

Reviewing Patches in the Git Project

Submitting Patches

Generate your patch using Git tools out of your commits.

Tools for developing Git

Everyday Git With 20 Commands Or So

git-remote-helpers

RESERVED BUILTIN_* ATTRIBUTES

builtin_objectmode

EFFECTS

BTMP chunk

Keep authoritative canonical history correct with git pull

How to maintain Git

How to integrate new subcommands

How to rebase from an internal branch

How to rebuild from update hook

How to recover a corrupted blob object

How to recover an object from scratch

How to revert a faulty merge

How to revert an existing commit

How to separate topic branches

How to setup Git server over http

How to use the update hook

How to use git-daemon

How to use the subtree merge strategy

How to use a signed tag in pull requests

Error reporting in git

Git API Documents

merge API

parse-options API

Simple-IPC API

Trace2 API

GIT bitmap v1 format

Bundle URIs

Git hash function transition

Long-running process protocol

Multi-Pack-Index (MIDX) Design Notes

Concerning Git’s Packing Heuristics

Parallel Checkout Design Notes

Partial Clone Design Notes

Use of index and Racy Git problem

Scalar

Git-send-pack internals

Shallow commits

Trivial merge rules

Unit Testing

Git User Manual

Introduction

Git User Manual

Introduction

`builtin_objectmode`

`BTMP` chunk