Skip to content

Commit 390fadc

Browse files
committed
Autogenerated HTML docs for v2.52.0-84-g6ab38b7
1 parent f8072aa commit 390fadc

File tree

7 files changed

+153
-62
lines changed

7 files changed

+153
-62
lines changed

‎RelNotes/2.53.0.adoc‎

Lines changed: 32 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -7,6 +7,10 @@ UI, Workflows & Features
77
* "git maintenance" command learned "is-needed" subcommand to tell if
88
it is necessary to perform various maintenance tasks.
99

10+
* "git replay" (experimental) learned to perform ref updates itself
11+
in a transaction by default, instead of emitting where each refs
12+
should point at and leaving the actual update to another command.
13+
1014

1115
Performance, Internal Implementation, Development Support etc.
1216
--------------------------------------------------------------
@@ -22,10 +26,37 @@ Performance, Internal Implementation, Development Support etc.
2226
changes, disable rename/copy detection to skip more expensive
2327
processing whose result will be discarded anyway.
2428
29+
* A part of code paths that deals with loose objects has been cleaned
30+
up.
31+
2532
26-
Fixes since v2.51
33+
Fixes since v2.52
2734
-----------------
2835

2936
* Ever since we added whitespace rules for this project, we misspelt
3037
an entry, which has been corrected.
3138
(merge 358e94dc70 jc/gitattributes-whitespace-no-indent-fix later to maint).
39+
40+
* The code to expand attribute macros has been rewritten to avoid
41+
recursion to avoid running out of stack space in an uncontrolled
42+
way.
43+
(merge 42ed046866 jk/attr-macroexpand-wo-recursion later to maint).
44+
45+
* Adding a repository that uses a different hash function is a no-no,
46+
but "git submodule add" did nt prevent it, which has been corrected.
47+
(merge 6fe288bfbc bc/submodule-force-same-hash later to maint).
48+
49+
* An earlier check added to osx keychain credential helper to avoid
50+
storing the credential itself supplied was overeager and rejected
51+
credential material supplied by other helper backends that it would
52+
have wanted to store, which has been corrected.
53+
(merge 4580bcd235 kn/osxkeychain-idempotent-store-fix later to maint).
54+
55+
* The "git repo structure" subcommand tried to align its output but
56+
mixed up byte count and display column width, which has been
57+
corrected.
58+
(merge 7a03a10a3a jx/repo-struct-utf8width-fix later to maint).
59+
60+
* Other code cleanup, docfix, build fix, etc.
61+
(merge 46207a54cc qj/doc-http-bad-want-response later to maint).
62+
(merge df90eccd93 kh/doc-commit-extra-references later to maint).

‎git-commit.adoc‎

Lines changed: 6 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -146,20 +146,22 @@ See linkgit:git-rebase[1] for details.
146146
linkgit:git-status[1] for details. Implies `--dry-run`.
147147

148148
`--branch`::
149-
Show the branch and tracking info even in short-format.
149+
Show the branch and tracking info even in short-format. See
150+
linkgit:git-status[1] for details.
150151

151152
`--porcelain`::
152153
When doing a dry-run, give the output in a porcelain-ready
153154
format. See linkgit:git-status[1] for details. Implies
154155
`--dry-run`.
155156

156157
`--long`::
157-
When doing a dry-run, give the output in the long-format.
158-
Implies `--dry-run`.
158+
When doing a dry-run, give the output in the long-format. This
159+
is the default output of linkgit:git-status[1]. Implies
160+
`--dry-run`.
159161

160162
`-z`::
161163
`--null`::
162-
When showing `short` or `porcelain` status output, print the
164+
When showing `short` or `porcelain`linkgit:git-status[1] output, print the
163165
filename verbatim and terminate the entries with _NUL_, instead of _LF_.
164166
If no format is given, implies the `--porcelain` output format.
165167
Without the `-z` option, filenames with "unusual" characters are

‎git-commit.html‎

Lines changed: 7 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -633,7 +633,8 @@ <h2 id="_options">OPTIONS</h2>
633633
</dd>
634634
<dtclass="hdlist1"><code>--branch</code></dt>
635635
<dd>
636-
<p>Show the branch and tracking info even in short-format.</p>
636+
<p>Show the branch and tracking info even in short-format. See
637+
<ahref="git-status.html">git-status(1)</a> for details.</p>
637638
</dd>
638639
<dtclass="hdlist1"><code>--porcelain</code></dt>
639640
<dd>
@@ -643,13 +644,14 @@ <h2 id="_options">OPTIONS</h2>
643644
</dd>
644645
<dtclass="hdlist1"><code>--long</code></dt>
645646
<dd>
646-
<p>When doing a dry-run, give the output in the long-format.
647-
Implies <code>--dry-run</code>.</p>
647+
<p>When doing a dry-run, give the output in the long-format. This
648+
is the default output of <ahref="git-status.html">git-status(1)</a>. Implies
649+
<code>--dry-run</code>.</p>
648650
</dd>
649651
<dtclass="hdlist1"><code>-z</code></dt>
650652
<dtclass="hdlist1"><code>--null</code></dt>
651653
<dd>
652-
<p>When showing <code>short</code> or <code>porcelain</code> status output, print the
654+
<p>When showing <code>short</code> or <code>porcelain</code><ahref="git-status.html">git-status(1)</a> output, print the
653655
filename verbatim and terminate the entries with <em>NUL</em>, instead of <em>LF</em>.
654656
If no format is given, implies the <code>--porcelain</code> output format.
655657
Without the <code>-z</code> option, filenames with "unusual" characters are
@@ -1421,7 +1423,7 @@ <h2 id="_git">GIT</h2>
14211423
</div>
14221424
<divid="footer">
14231425
<divid="footer-text">
1424-
Last updated 2025-08-25 14:46:08 -0700
1426+
Last updated 2025-11-24 16:03:54 -0800
14251427
</div>
14261428
</div>
14271429
</body>

‎git-replay.adoc‎

Lines changed: 41 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -9,15 +9,16 @@ git-replay - EXPERIMENTAL: Replay commits on a new base, works with bare repos t
99
SYNOPSIS
1010
--------
1111
[verse]
12-
(EXPERIMENTAL!) 'git replay' ([--contained] --onto <newbase> | --advance <branch>) <revision-range>...
12+
(EXPERIMENTAL!) 'git replay' ([--contained] --onto <newbase> | --advance <branch>) [--ref-action[=<mode>]] <revision-range>...
1313

1414
DESCRIPTION
1515
-----------
1616

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

2324
THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
@@ -29,18 +30,29 @@ OPTIONS
2930
Starting point at which to create the new commits. May be any
3031
valid commit, and not just an existing branch name.
3132
+
32-
When `--onto` is specified, the update-ref command(s) in the output will
33-
update the branch(es) in the revision range to point at the new
34-
commits, similar to the way how `git rebase --update-refs` updates
35-
multiple branches in the affected range.
33+
When `--onto` is specified, the branch(es) in the revision range will be
34+
updated to point at the new commits, similar to the way `git rebase --update-refs`
35+
updates multiple branches in the affected range.
3636

3737
--advance <branch>::
3838
Starting point at which to create the new commits; must be a
3939
branch name.
4040
+
41-
When `--advance` is specified, the update-ref command(s) in the output
42-
will update the branch passed as an argument to `--advance` to point at
43-
the new commits (in other words, this mimics a cherry-pick operation).
41+
The history is replayed on top of the <branch> and <branch> is updated to
42+
point at the tip of the resulting history. This is different from `--onto`,
43+
which uses the target only as a starting point without updating it.
44+
45+
--ref-action[=<mode>]::
46+
Control how references are updated. The mode can be:
47+
+
48+
--
49+
* `update` (default): Update refs directly using an atomic transaction.
50+
All refs are updated or none are (all-or-nothing behavior).
51+
* `print`: Output update-ref commands for pipeline use. This is the
52+
traditional behavior where output can be piped to `git update-ref --stdin`.
53+
--
54+
+
55+
The default mode can be configured via the `replay.refAction` configuration variable.
4456

4557
<revision-range>::
4658
Range of commits to replay. More than one <revision-range> can
@@ -54,8 +66,11 @@ include::rev-list-options.adoc[]
5466
OUTPUT
5567
------
5668

57-
When there are no conflicts, the output of this command is usable as
58-
input to `git update-ref --stdin`. It is of the form:
69+
By default, or with `--ref-action=update`, this command produces no output on
70+
success, as refs are updated directly using an atomic transaction.
71+
72+
When using `--ref-action=print`, the output is usable as input to
73+
`git update-ref --stdin`. It is of the form:
5974

6075
update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH}
6176
update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH}
@@ -81,40 +96,44 @@ To simply rebase `mybranch` onto `target`:
8196

8297
------------
8398
$ git replay --onto target origin/main..mybranch
99+
------------
100+
101+
The refs are updated atomically and no output is produced on success.
102+
103+
To see what would be updated without actually updating:
104+
105+
------------
106+
$ git replay --ref-action=print --onto target origin/main..mybranch
84107
update refs/heads/mybranch ${NEW_mybranch_HASH} ${OLD_mybranch_HASH}
85108
------------
86109

87110
To cherry-pick the commits from mybranch onto target:
88111

89112
------------
90113
$ git replay --advance target origin/main..mybranch
91-
update refs/heads/target ${NEW_target_HASH} ${OLD_target_HASH}
92114
------------
93115

94116
Note that the first two examples replay the exact same commits and on
95117
top of the exact same new base, they only differ in that the first
96-
provides instructions to make mybranch point at the new commits and
97-
the second provides instructions to make target point at them.
118+
updates mybranch to point at the new commits and the second updates
119+
target to point at them.
98120

99121
What if you have a stack of branches, one depending upon another, and
100122
you'd really like to rebase the whole set?
101123

102124
------------
103125
$ git replay --contained --onto origin/main origin/main..tipbranch
104-
update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH}
105-
update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH}
106-
update refs/heads/tipbranch ${NEW_tipbranch_HASH} ${OLD_tipbranch_HASH}
107126
------------
108127

128+
All three branches (`branch1`, `branch2`, and `tipbranch`) are updated
129+
atomically.
130+
109131
When calling `git replay`, one does not need to specify a range of
110132
commits to replay using the syntax `A..B`; any range expression will
111133
do:
112134

113135
------------
114136
$ git replay --onto origin/main ^base branch1 branch2 branch3
115-
update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH}
116-
update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH}
117-
update refs/heads/branch3 ${NEW_branch3_HASH} ${OLD_branch3_HASH}
118137
------------
119138

120139
This will simultaneously rebase `branch1`, `branch2`, and `branch3`,

0 commit comments

Comments
(0)