diff --git a/RelNotes/2.53.0.adoc b/RelNotes/2.53.0.adoc index 997ae7476..7882bc59e 100644 --- a/RelNotes/2.53.0.adoc +++ b/RelNotes/2.53.0.adoc @@ -7,6 +7,10 @@ UI, Workflows & Features * "git maintenance" command learned "is-needed" subcommand to tell if it is necessary to perform various maintenance tasks. + * "git replay" (experimental) learned to perform ref updates itself + in a transaction by default, instead of emitting where each refs + should point at and leaving the actual update to another command. + Performance, Internal Implementation, Development Support etc. -------------------------------------------------------------- @@ -22,10 +26,37 @@ Performance, Internal Implementation, Development Support etc. changes, disable rename/copy detection to skip more expensive processing whose result will be discarded anyway. + * A part of code paths that deals with loose objects has been cleaned + up. + -Fixes since v2.51 +Fixes since v2.52 ----------------- * Ever since we added whitespace rules for this project, we misspelt an entry, which has been corrected. (merge 358e94dc70 jc/gitattributes-whitespace-no-indent-fix later to maint). + + * The code to expand attribute macros has been rewritten to avoid + recursion to avoid running out of stack space in an uncontrolled + way. + (merge 42ed046866 jk/attr-macroexpand-wo-recursion later to maint). + + * Adding a repository that uses a different hash function is a no-no, + but "git submodule add" did nt prevent it, which has been corrected. + (merge 6fe288bfbc bc/submodule-force-same-hash later to maint). + + * An earlier check added to osx keychain credential helper to avoid + storing the credential itself supplied was overeager and rejected + credential material supplied by other helper backends that it would + have wanted to store, which has been corrected. + (merge 4580bcd235 kn/osxkeychain-idempotent-store-fix later to maint). + + * The "git repo structure" subcommand tried to align its output but + mixed up byte count and display column width, which has been + corrected. + (merge 7a03a10a3a jx/repo-struct-utf8width-fix later to maint). + + * Other code cleanup, docfix, build fix, etc. + (merge 46207a54cc qj/doc-http-bad-want-response later to maint). + (merge df90eccd93 kh/doc-commit-extra-references later to maint). diff --git a/git-commit.adoc b/git-commit.adoc index 54c207ad4..8329c1034 100644 --- a/git-commit.adoc +++ b/git-commit.adoc @@ -146,7 +146,8 @@ See linkgit:git-rebase[1] for details. linkgit:git-status[1] for details. Implies `--dry-run`. `--branch`:: - Show the branch and tracking info even in short-format. + 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 @@ -154,12 +155,13 @@ See linkgit:git-rebase[1] for details. `--dry-run`. `--long`:: - When doing a dry-run, give the output in the long-format. - Implies `--dry-run`. + 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` status output, print the + 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 diff --git a/git-commit.html b/git-commit.html index 9fe457fce..a002dd93d 100644 --- a/git-commit.html +++ b/git-commit.html @@ -633,7 +633,8 @@

OPTIONS

--branch
-

Show the branch and tracking info even in short-format.

+

Show the branch and tracking info even in short-format. See +git-status(1) for details.

--porcelain
@@ -643,13 +644,14 @@

OPTIONS

--long
-

When doing a dry-run, give the output in the long-format. -Implies --dry-run.

+

When doing a dry-run, give the output in the long-format. This +is the default output of git-status(1). Implies +--dry-run.

-z
--null
-

When showing short or porcelain status output, print the +

When showing short or porcelain 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 @@ -1421,7 +1423,7 @@

GIT

diff --git a/git-replay.adoc b/git-replay.adoc index 0b12bf8aa..dcb26e8a8 100644 --- a/git-replay.adoc +++ b/git-replay.adoc @@ -9,15 +9,16 @@ git-replay - EXPERIMENTAL: Replay commits on a new base, works with bare repos t SYNOPSIS -------- [verse] -(EXPERIMENTAL!) 'git replay' ([--contained] --onto | --advance ) ... +(EXPERIMENTAL!) 'git replay' ([--contained] --onto | --advance ) [--ref-action[=]] ... DESCRIPTION ----------- Takes ranges of commits and replays them onto a new location. Leaves -the working tree and the index untouched, and updates no references. -The output of this command is meant to be used as input to -`git update-ref --stdin`, which would update the relevant branches +the working tree and the index untouched. By default, updates the +relevant references using an atomic transaction (all refs update or +none). Use `--ref-action=print` to avoid automatic ref updates and +instead get update commands that can be piped to `git update-ref --stdin` (see the OUTPUT section below). THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE. @@ -29,18 +30,29 @@ OPTIONS Starting point at which to create the new commits. May be any valid commit, and not just an existing branch name. + -When `--onto` is specified, the update-ref command(s) in the output will -update the branch(es) in the revision range to point at the new -commits, similar to the way how `git rebase --update-refs` updates -multiple branches in the affected range. +When `--onto` is specified, the branch(es) in the revision range will be +updated to point at the new commits, similar to the way `git rebase --update-refs` +updates multiple branches in the affected range. --advance :: Starting point at which to create the new commits; must be a branch name. + -When `--advance` is specified, the update-ref command(s) in the output -will update the branch passed as an argument to `--advance` to point at -the new commits (in other words, this mimics a cherry-pick operation). +The history is replayed on top of the and is updated to +point at the tip of the resulting history. This is different from `--onto`, +which uses the target only as a starting point without updating it. + +--ref-action[=]:: + Control how references are updated. The mode can be: ++ +-- + * `update` (default): Update refs directly using an atomic transaction. + All refs are updated or none are (all-or-nothing behavior). + * `print`: Output update-ref commands for pipeline use. This is the + traditional behavior where output can be piped to `git update-ref --stdin`. +-- ++ +The default mode can be configured via the `replay.refAction` configuration variable. :: Range of commits to replay. More than one can @@ -54,8 +66,11 @@ include::rev-list-options.adoc[] OUTPUT ------ -When there are no conflicts, the output of this command is usable as -input to `git update-ref --stdin`. It is of the form: +By default, or with `--ref-action=update`, this command produces no output on +success, as refs are updated directly using an atomic transaction. + +When using `--ref-action=print`, the output is usable as input to +`git update-ref --stdin`. It is of the form: update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH} update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH} @@ -81,6 +96,14 @@ To simply rebase `mybranch` onto `target`: ------------ $ git replay --onto target origin/main..mybranch +------------ + +The refs are updated atomically and no output is produced on success. + +To see what would be updated without actually updating: + +------------ +$ git replay --ref-action=print --onto target origin/main..mybranch update refs/heads/mybranch ${NEW_mybranch_HASH} ${OLD_mybranch_HASH} ------------ @@ -88,33 +111,29 @@ To cherry-pick the commits from mybranch onto target: ------------ $ git replay --advance target origin/main..mybranch -update refs/heads/target ${NEW_target_HASH} ${OLD_target_HASH} ------------ Note that the first two examples replay the exact same commits and on top of the exact same new base, they only differ in that the first -provides instructions to make mybranch point at the new commits and -the second provides instructions to make target point at them. +updates mybranch to point at the new commits and the second updates +target to point at them. What if you have a stack of branches, one depending upon another, and you'd really like to rebase the whole set? ------------ $ git replay --contained --onto origin/main origin/main..tipbranch -update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH} -update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH} -update refs/heads/tipbranch ${NEW_tipbranch_HASH} ${OLD_tipbranch_HASH} ------------ +All three branches (`branch1`, `branch2`, and `tipbranch`) are updated +atomically. + When calling `git replay`, one does not need to specify a range of commits to replay using the syntax `A..B`; any range expression will do: ------------ $ git replay --onto origin/main ^base branch1 branch2 branch3 -update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH} -update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH} -update refs/heads/branch3 ${NEW_branch3_HASH} ${OLD_branch3_HASH} ------------ This will simultaneously rebase `branch1`, `branch2`, and `branch3`, diff --git a/git-replay.html b/git-replay.html index eabf2801f..48bee4978 100644 --- a/git-replay.html +++ b/git-replay.html @@ -452,7 +452,7 @@

NAME

SYNOPSIS

-
(EXPERIMENTAL!) git replay ([--contained] --onto <newbase> | --advance <branch>) <revision-range>…​
+
(EXPERIMENTAL!) git replay ([--contained] --onto <newbase> | --advance <branch>) [--ref-action[=<mode>]] <revision-range>…​
@@ -461,9 +461,10 @@

DESCRIPTION

Takes ranges of commits and replays them onto a new location. Leaves -the working tree and the index untouched, and updates no references. -The output of this command is meant to be used as input to -git update-ref --stdin, which would update the relevant branches +the working tree and the index untouched. By default, updates the +relevant references using an atomic transaction (all refs update or +none). Use --ref-action=print to avoid automatic ref updates and +instead get update commands that can be piped to git update-ref --stdin (see the OUTPUT section below).

@@ -481,10 +482,9 @@

OPTIONS

Starting point at which to create the new commits. May be any valid commit, and not just an existing branch name.

-

When --onto is specified, the update-ref command(s) in the output will -update the branch(es) in the revision range to point at the new -commits, similar to the way how git rebase --update-refs updates -multiple branches in the affected range.

+

When --onto is specified, the branch(es) in the revision range will be +updated to point at the new commits, similar to the way git rebase --update-refs +updates multiple branches in the affected range.

--advance <branch>
@@ -492,9 +492,32 @@

OPTIONS

Starting point at which to create the new commits; must be a branch name.

-

When --advance is specified, the update-ref command(s) in the output -will update the branch passed as an argument to --advance to point at -the new commits (in other words, this mimics a cherry-pick operation).

+

The history is replayed on top of the <branch> and <branch> is updated to +point at the tip of the resulting history. This is different from --onto, +which uses the target only as a starting point without updating it.

+
+ +
--ref-action[=<mode>]
+
+

Control how references are updated. The mode can be:

+
+
+
+
    +
  • +

    update (default): Update refs directly using an atomic transaction. +All refs are updated or none are (all-or-nothing behavior).

    +
    • +
  • +

    print: Output update-ref commands for pipeline use. This is the +traditional behavior where output can be piped to git update-ref --stdin.

    +
    • +
+
+
+
+
+

The default mode can be configured via the replay.refAction configuration variable.

<revision-range>
@@ -1822,8 +1845,12 @@

Commit Formatting

OUTPUT

-

When there are no conflicts, the output of this command is usable as -input to git update-ref --stdin. It is of the form:

+

By default, or with --ref-action=update, this command produces no output on +success, as refs are updated directly using an atomic transaction.

+
+
+

When using --ref-action=print, the output is usable as input to +git update-ref --stdin. It is of the form:

@@ -1859,7 +1886,18 @@

EXAMPLES

-
$ git replay --onto target origin/main..mybranch
+
$ git replay --onto target origin/main..mybranch

+
+
+
+

The refs are updated atomically and no output is produced on success.

+
+
+

To see what would be updated without actually updating:

+
+
+
+
$ git replay --ref-action=print --onto target origin/main..mybranch
 update refs/heads/mybranch ${NEW_mybranch_HASH} ${OLD_mybranch_HASH}
@@ -1868,15 +1906,14 @@

EXAMPLES

-
$ git replay --advance target origin/main..mybranch
-update refs/heads/target ${NEW_target_HASH} ${OLD_target_HASH}
+
$ git replay --advance target origin/main..mybranch

Note that the first two examples replay the exact same commits and on top of the exact same new base, they only differ in that the first -provides instructions to make mybranch point at the new commits and -the second provides instructions to make target point at them.

+updates mybranch to point at the new commits and the second updates +target to point at them.

What if you have a stack of branches, one depending upon another, and @@ -1884,23 +1921,21 @@

EXAMPLES

-
$ git replay --contained --onto origin/main origin/main..tipbranch
-update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH}
-update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH}
-update refs/heads/tipbranch ${NEW_tipbranch_HASH} ${OLD_tipbranch_HASH}
+
$ git replay --contained --onto origin/main origin/main..tipbranch
+

All three branches (branch1, branch2, and tipbranch) are updated +atomically.

+
+

When calling git replay, one does not need to specify a range of commits to replay using the syntax A..B; any range expression will do:

-
$ git replay --onto origin/main ^base branch1 branch2 branch3
-update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH}
-update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH}
-update refs/heads/branch3 ${NEW_branch3_HASH} ${OLD_branch3_HASH}
+
$ git replay --onto origin/main ^base branch1 branch2 branch3
@@ -1922,7 +1957,7 @@

GIT

diff --git a/gitprotocol-http.adoc b/gitprotocol-http.adoc index d02401041..e2ef7f045 100644 --- a/gitprotocol-http.adoc +++ b/gitprotocol-http.adoc @@ -443,7 +443,8 @@ If no "want" objects are received, send an error: TODO: Define error if no "want" lines are requested. If any "want" object is not reachable, send an error: -TODO: Define error if an invalid "want" is requested. +When a Git server receives an invalid or malformed `want` line, it +responds with an error message that includes the offending object name. Create an empty list, `s_common`. diff --git a/gitprotocol-http.html b/gitprotocol-http.html index f24925f74..661353444 100644 --- a/gitprotocol-http.html +++ b/gitprotocol-http.html @@ -1052,7 +1052,8 @@

The Negotiation Algorithm

If any "want" object is not reachable, send an error: -TODO: Define error if an invalid "want" is requested.

+When a Git server receives an invalid or malformed want line, it +responds with an error message that includes the offending object name.

Create an empty list, s_common.

@@ -1204,7 +1205,7 @@

GIT