* [PATCH v2] doc: clarify that --word-diff operates on line-level hunks
From: Michael Montalbo via GitGitGadget @ 2026-05-28 19:21 UTC (permalink / raw)
To: git; +Cc: Michael Montalbo, Michael Montalbo
In-Reply-To: <pull.2113.git.1778686956622.gitgitgadget@gmail.com>
From: Michael Montalbo <mmontalbo@gmail.com>
The --word-diff documentation describes the output modes and
word-regex mechanics but does not explain that word-diff operates
within the hunks produced by the line-level diff rather than
performing an independent word-stream comparison. This can
surprise users when the line-level alignment causes word-level
changes to appear even though the words in both files are
identical.
Add an implementation note explaining the two-stage relationship
and that the output may change if Git acquires a different
implementation in the future.
Signed-off-by: Michael Montalbo <mmontalbo@gmail.com>
---
doc: clarify that --word-diff operates on line-level hunks
CC: Vincent Lefevre vincent@vinc17.net, Johannes Sixt j6t@kdbg.org
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2113%2Fmmontalbo%2Fmm%2Fdoc-word-diff-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2113/mmontalbo/mm/doc-word-diff-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/2113
Range-diff vs v1:
1: 73f7b06c06 ! 1: bc5ca5a147 doc: clarify that --word-diff operates on line-level hunks
@@ Commit message
changes to appear even though the words in both files are
identical.
- Add a short note explaining the two-stage relationship.
+ Add an implementation note explaining the two-stage relationship
+ and that the output may change if Git acquires a different
+ implementation in the future.
Signed-off-by: Michael Montalbo <mmontalbo@gmail.com>
@@ Documentation/diff-options.adoc: endif::git-diff[]
Note that despite the name of the first mode, color is used to
highlight the changed parts in all modes if enabled.
++
-+Word diff works by finding word-level changes within each hunk of
-+the line-level diff. The line-level alignment determines which
-+changed lines are compared to each other, which can affect the
-+word-level output.
++The `--word-diff` option operates by taking the same line-by-line
++diff that is produced without the option and computing
++word-by-word changes within each hunk. This may produce a
++larger diff than a dedicated word-diff tool would. If Git
++acquires a different implementation in the future, the output
++may change. Note that this is similar to the `--diff-algorithm`
++option, which may also change the output.
`--word-diff-regex=<regex>`::
Use _<regex>_ to decide what a word is, instead of considering
Documentation/diff-options.adoc | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/diff-options.adoc b/Documentation/diff-options.adoc
index 8a63b5e164..c8242e2462 100644
--- a/Documentation/diff-options.adoc
+++ b/Documentation/diff-options.adoc
@@ -457,6 +457,14 @@ endif::git-diff[]
+
Note that despite the name of the first mode, color is used to
highlight the changed parts in all modes if enabled.
++
+The `--word-diff` option operates by taking the same line-by-line
+diff that is produced without the option and computing
+word-by-word changes within each hunk. This may produce a
+larger diff than a dedicated word-diff tool would. If Git
+acquires a different implementation in the future, the output
+may change. Note that this is similar to the `--diff-algorithm`
+option, which may also change the output.
`--word-diff-regex=<regex>`::
Use _<regex>_ to decide what a word is, instead of considering
base-commit: 94f057755b7941b321fd11fec1b2e3ca5313a4e0
--
gitgitgadget
^ permalink raw reply related
* Re: [PATCH v2 0/3] line-log: integrate -L with the standard log output pipeline
From: Junio C Hamano @ 2026-05-28 18:55 UTC (permalink / raw)
To: D. Ben Knoble; +Cc: Michael Montalbo via GitGitGadget, git, Michael Montalbo
In-Reply-To: <CALnO6CA5GPS2CMv_x_=wOPBgspe31FkW=h832GCBpAUbBoJNLg@mail.gmail.com>
"D. Ben Knoble" <ben.knoble@gmail.com> writes:
>> ++ ! test_grep "^diff --git" actual &&
>> ++ ! test_grep "^@@" actual
>
> I wish we had docs for all the little test helpers… in particular, I
> think this is supposed to be "test_grep !" ?
Good eyes. I wonder if we teach test-lint to catch these.
^ permalink raw reply
* Re: [PATCH] doc: fix typos via codespell
From: Kristoffer Haugsbakk @ 2026-05-28 17:53 UTC (permalink / raw)
To: Andrew Kreimer, git
In-Reply-To: <b8d57be0-b03c-461c-94e4-02340b5af77b@app.fastmail.com>
On Sun, May 10, 2026, at 00:14, Kristoffer Haugsbakk wrote:
> On Wed, May 6, 2026, at 12:15, Andrew Kreimer wrote:
>> There are some typos in the documentation, comments, etc.
>> Fix them via codespell.
>>
>> Signed-off-by: Andrew Kreimer <algonell@gmail.com>
>> ---
>>[snip]
I went through the typos in my previous message and with the exception
of `po/` they all look good. They are all either documentation typos
or typos in code comments. And they are all legitimate, in other words
not false positives.
With Junio’s email in mind, I think a second version which just drops
the `po/` and git-gui typo fixes would be good. Since they are different
projects.
^ permalink raw reply
* Re: [PATCH 0/3] pack-objects: support bitmaps and delta-islands with `--path-walk`
From: Derrick Stolee @ 2026-05-28 15:28 UTC (permalink / raw)
To: Taylor Blau, git; +Cc: Junio C Hamano, Jeff King, Elijah Newren
In-Reply-To: <cover.1779923907.git.me@ttaylorr.com>
On 5/27/26 7:18 PM, Taylor Blau wrote:
> Here is a trimmed-down reroll of my series to make `--path-walk` work
> with reachability bitmaps and delta-islands. This series was originally
> an RFC that was a companion to Stolee's recent patches to extend
> `--filter` support to `--path-walk` [1].
>
> Since the previous round, Stolee's series has graduated and incorporated
> the filter-related patches from my earlier RFC [2]. What remains are the
> three patches here that implement support for reachability bitmaps and
> delta-islands under `--path-walk`.
>
> * The first patch allows `--path-walk` to use reachability bitmaps when
> they can answer the request, falling back to path-walk enumeration
> when they cannot. It also lets bitmap writing see the same commit
> candidates that the regular traversal would have shown to the bitmap
> selector.
>
> * The second patch is preparatory, and factors the
> delta-islands-specific tree-depth recording from `show_object()` into
> a helper.
>
> * The final patch teaches the path-walk callback to perform the same
> delta-islands side effects as the regular traversal: propagating
> island marks for commits, and recording tree depths for trees. This
> gives `resolve_tree_islands()` the same input in either enumeration
> mode, so the existing island checks can be reused unchanged.
I've applied these patches locally and confirmed that each one passes the
test suite with GIT_TEST_PACK_PATH_WALK=1, which helps to confirm that
the changes are correct (all existing bitmap tests create and use the
bitmaps with --path-walk unless explicitly disabled).
Should we add GIT_TEST_PACK_PATH_WALK=1 to the test-var CI build, now
that this is going to be more commonly used?
Do you have any end-to-end performance data to demonstrate that these
changes are effective at scale? Are we still producing packfiles with the
pack-file compression and now with .bitmap files? How does this impact
the performance of a clone or fetch when using a bitmap index at read
time?
With that in mind, should we update any t/perf/ test to cover some of
these scenarios? I'm running a few with GIT_TEST_PACK_PATH_WALK=1 on
my laptop as a test, but it's taking a while. If you have stats ready
from your local testing, then that would be interesting.
Thanks,
-Stolee
^ permalink raw reply
* Re: git mv after the fact
From: Ben Knoble @ 2026-05-28 14:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Chris Torek, Frieder Hannenheim, git
In-Reply-To: <877bootp3l.fsf@gitster.g>
> Le 27 mai 2026 à 19:24, Junio C Hamano <gitster@pobox.com> a écrit :
>
> Chris Torek <chris.torek@gmail.com> writes:
>
>>> Chris Torek <chris.torek@gmail.com> writes:
>>>> A flag for "git mv" would be convenient (and slightly moreefficient ...
>>>
>>
>> On Tue, May 26, 2026 at 8:09 PM Junio C Hamano <gitster@pobox.com> wrote:
>>> May be convenient, but I do not get the "efficient" part.
>>
>> A normal `git mv` renames the index entry and the file in the working
>> tree without running `git add` on the *contents*, so there's no new hash
>> computation. Presumably a `git mv --after foo bar` would do the same: verify
>> that there is no existing `bar` in the index, that there is an existing `foo` in
>> the index, and that there is no `foo` but there is a `bar` in the working tree,
>> and then it would rename (add-and-remove, really, because of sorting)
>> the index entry, without scanning the working tree contents.
>>
>> In other words, we skip reading the 3 terabyte file, or whatever.
>
> Yup, that matches what I wrote. We do not rehash and we only write
> the index just once.
One thing I wondered: if we don’t have an exact move but assume (by not hashing), doesn’t that mean the index would differ from what’s on disk? I originally thought that might be a problem, but the more I thought the more I realized that’s a fairly typical state anyway.
Just seemed like a potential footgun to me, but perhaps not worth worrying about.
^ permalink raw reply
* Re:
From: Weijie Yuan @ 2026-05-28 14:16 UTC (permalink / raw)
To: 胡锦; +Cc: git
In-Reply-To: <tencent_124443E95FD3502A16815464@qq.com>
Hi,
I'm just a diver here, but I would like to give you some suggestions though.
* Your email doesn't have a subject line. So it seems not possible for
a true dev here to be interested in your email.
* I guess you would need a proper text editor or a proper email client,
your email doen's wrap perfectly.
As for your feature request, I believe it's even harder, as for the "online
collaborative documents". This doesn't seem like a problem that git was
designed to solve, but more like features of certain forges. Based on
discussions in recent years, this feature you are looking for is not
within the scope or schedule of discussion.
But I guess they would be more possible to discuss it if you could
attach some patches.
Thanks.
^ permalink raw reply
* Re: [PATCH] compat/mingw: Allow SIGKILL to kill in mingw_kill.
From: Johannes Schindelin @ 2026-05-28 13:11 UTC (permalink / raw)
To: Junio C Hamano
Cc: Siddh Raman Pant, Johannes Sixt, git, Kristoffer Haugsbakk,
Elijah Newren, Patrick Steinhardt
In-Reply-To: <xmqqwlwwt0mj.fsf@gitster.g>
Hi Junio & Siddh,
On Fri, 22 May 2026, Junio C Hamano wrote:
> Siddh Raman Pant <siddh.raman.pant@oracle.com> writes:
>
> > mingw_kill() only allows SIGTERM for killing a process.
> >
> > Let's also allow the natural SIGKILL for the same so that callers don't
> > have to do ifdef soup for special Windows handling.
>
> [...]
>
> The current code only handles TERM (to terminate) or 0 (to probe)
> and everything else results in EINVAL, so the updated behaviour is
> to pretend as if TERM is sent and do whatever PROCESS_TERMINATE
> does, instead of doing nothing and erroring with EINVAL. Which does
> sound like an improvement over the status quo.
>
> What I am wondering is if there are different kind of "kill" in the
> Windows land, just like there are distinction between TERM and KILL.
> For example, the program ought to be able to block TERM but not
> KILL. There are other termination-inducing signals like SIGQUIT but
> until we start using them in our code, this emulation layer does not
> have to know about them, I think.
The version that that Git for Windows carries is actually really
different. For one, it gives processes a chance to run their `atexit()`
handlers when being terminated via `SIGTERM`.
I'm afraid that the patch under discussion would severely conflict with
Git for Windows' code. Git for Windows' code, that is, that should have
been upstreamed a long time ago, but wasn't, out of time constraints.
I'll try to polish the patches and upstream them.
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCH v2] config: retry acquiring config.lock, configurable via core.configLockTimeout
From: Junio C Hamano @ 2026-05-28 12:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Joerg Thalheim, git, Patrick Steinhardt
In-Reply-To: <f449d0db-0434-f870-c69f-793f2b096816@gmx.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Footnote *1*: In general, I am quite wary of unit-less numbers in
> configurations.
Hear, hear.
I do not like unit-less names for variables that store numbers, not
just configuration but in-code variables. In the longer run we want
to clean these up. In-code variables are much easier to clean-up
than end-user facing configuration variable names, of course.
^ permalink raw reply
* Re: [PATCH v2] config: retry acquiring config.lock, configurable via core.configLockTimeout
From: Johannes Schindelin @ 2026-05-28 11:51 UTC (permalink / raw)
To: Joerg Thalheim; +Cc: git, Junio C Hamano, Patrick Steinhardt
In-Reply-To: <20260517132111.1014901-1-joerg@thalheim.io>
Hi Joerg,
On Sun, 17 May 2026, Joerg Thalheim wrote:
> I matched the core.filesRefLockTimeout naming rather than reusing
> microsoft/git's core.configWriteLockTimeoutMS, but can switch if the
> downstream compat matters more.
I see that there is quite a bit of precedent for naming a config setting
`*Timeout` and implying that it specifies milliseconds, e.g.
https://git-scm.com/docs/git-config#Documentation/git-config.txt-corefilesRefLockTimeout
In general, I am pretty wary of unit-less numbers [*1*], that's why I
chose that "MS" suffix. However, the prior art in Git is clear, and I
should not have missed it. Therefore, I have no objections against
`core.configLockTimeout` as-is; I'll take care of providing a smooth
upgrade path in Microsoft Git.
Thank you,
Johannes
Footnote *1*: In general, I am quite wary of unit-less numbers in
configurations. There's not only the precedent of Mars Climate Orbiter
https://en.wikipedia.org/wiki/Mars_Climate_Orbiter#Cause_of_failure, I
also heard a story that seemed to be entertaining only in hindsight where
a German car's software improperly interpreted a British speed limit sign
to mean km/h instead of mph.
^ permalink raw reply
* Re: Suggestion: Real-time or Conflict-Reducing Collaboration Support for Specific Directories
From: Christian Couder @ 2026-05-28 9:23 UTC (permalink / raw)
To: 胡锦; +Cc: git
In-Reply-To: <tencent_530FD5EC0E2FA9A005AB4725@qq.com>
Hi Hujin,
On Thu, May 28, 2026 at 7:16 AM 胡锦 <hujin2@sunline.cn> wrote:
>
> Dear Git Team,
>
> My name is Hujin, and I am an IT engineer from China. I have been using Git for more than 10 years.
>
> First of all, I would like to express my appreciation for Git. In my experience, Git remains one of the best and most reliable version control systems in modern software development. It has played an important role in many projects I have worked on.
Thanks.
> However, I have also encountered a recurring difficulty in daily use. For certain types of files, especially files under script directories or other frequently modified directories, conflicts happen quite often because updates are not synchronized in real time. In some project scenarios, multiple engineers may edit related scripts at the same time, and this can lead to repeated merge conflicts and extra coordination costs.
>
> I wonder whether Git could provide, in future versions, some optional features similar to online collaborative documents, or directory-level collaboration mechanisms for specific files or folders. For example, users could enable special real-time update, lock, notification, or conflict-reduction behavior for selected directories such as scripts. This could help reduce conflicts and make Git even more convenient for teams working on highly shared files.
>
> I understand that Git is designed as a distributed version control system, and such functionality may not be simple to implement. Still, I believe an optional feature in this direction could be very helpful for many engineering teams.
First I don't think it's Git's role to provide a full collaborative
editor, but you are right that it could provide mechanisms that could
help.
Then there are a number of features/mechanisms that other SCMs or
tools provide that could perhaps help:
- Jujutsu's working copy as a commit
(https://docs.jj-vcs.dev/latest/working-copy/)
It could help write a background script that constantly pushes and
rebases the current commit to a shared server as the user types,
mimicking a real-time sync.
Jujutsu's first-class conflicts could perhaps help too.
- Pijul's CRDTs and the Theory of Patches (https://pijul.org/manual/theory.html)
To seamlessly merge real-time changes without locking the file or
constantly throwing conflict errors, modern collaborative editors
abandon SCM snapshot merging entirely. Instead, they use one of two
mathematical models:
- Operational Transformation (OT): Used by Google Docs.
- Conflict-free Replicated Data Types (CRDTs): Used by newer tools
like Figma, Zed, and Apple Notes.
Pijul's underlying Rust library (libpijul) which already uses CRDTs
could be wrapped and adapted to fit a real-time context.
- Michael Haggerty’s `git-imerge`
(https://softwareswirl.blogspot.com/2013/05/git-imerge-practical-introduction.html)
I think this is the right way to simplify complex merges and rebases
as much as possible, which is useful if a lot of such operations have
to be made.
- CRDT AST (https://github.com/aaronmunsters/AST_CRDT)
- Automerge (https://automerge.org/docs/hello/)
- Yjs (https://github.com/yjs/yjs)
It would be indeed complex to implement any of these in Git.
The nice thing if someone would want to implement backend
collaborative editing features is that these days an AI could perhaps
resolve merge conflicts automatically. (But of course users should
have a way to override the AI's decisions if they think it's wrong.)
There are already a number of tools out there doing that for regular
development.
Best,
Christian.
^ permalink raw reply
* [PATCH] t3070: skip ls-files tests with backslash patterns on Windows
From: Kristofer Karlsson via GitGitGadget @ 2026-05-28 9:00 UTC (permalink / raw)
To: git; +Cc: @dscho, Kristofer Karlsson, Kristofer Karlsson
From: Kristofer Karlsson <krka@spotify.com>
On Windows (MINGW), backslashes in pathspecs are silently converted to
forward slashes (directory separators), which changes the glob semantics.
This causes 36 test failures in t3070-wildmatch when the "via ls-files"
variants test patterns containing backslash escapes (e.g. '\[ab]',
'[\-_]', '[A-\\]').
The wildmatch function itself handles these patterns correctly — only the
ls-files code path fails because pathspec parsing converts the
backslashes before they reach the glob matcher.
Skip these ls-files tests on platforms where BSLASHPSPEC is not set,
which is the existing prereq that captures exactly this semantic:
"backslashes in pathspec are not directory separators."
Signed-off-by: Kristofer Karlsson <krka@spotify.com>
---
t3070: skip ls-files tests with backslash patterns on Windows
On Windows (MINGW), backslashes in pathspecs are silently converted to
forward slashes (directory separators), which changes the glob
semantics. This causes 36 test failures in t3070-wildmatch when the "via
ls-files" variants test patterns containing backslash escapes (e.g.
\[ab], [\-_], [A-\\]).
The wildmatch function itself handles these patterns correctly — only
the ls-files code path fails because pathspec parsing converts the
backslashes before they reach the glob matcher.
Skip these ls-files tests on platforms where BSLASHPSPEC is not set,
which is the existing prereq that captures exactly this semantic:
"backslashes in pathspec are not directory separators."
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2128%2Fspkrka%2Fwildmatch-windows-fix-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2128/spkrka/wildmatch-windows-fix-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/2128
t/t3070-wildmatch.sh | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index 655bb1a0f2..3394122218 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -99,6 +99,13 @@ match_with_ls_files() {
match_function=$4
ls_files_args=$5
+ prereqs=EXPENSIVE_ON_WINDOWS
+ case "$pattern" in
+ *\\*)
+ prereqs="$prereqs,BSLASHPSPEC"
+ ;;
+ esac
+
match_stdout_stderr_cmp="
tr -d '\0' <actual.raw >actual &&
test_must_be_empty actual.err &&
@@ -108,36 +115,36 @@ match_with_ls_files() {
then
if test -e .git/created_test_file
then
- test_expect_success EXPENSIVE_ON_WINDOWS "$match_function (via ls-files): match dies on '$pattern' '$text'" "
+ test_expect_success $prereqs "$match_function (via ls-files): match dies on '$pattern' '$text'" "
printf '%s' '$text' >expect &&
test_must_fail git$ls_files_args ls-files -z -- '$pattern'
"
else
- test_expect_failure EXPENSIVE_ON_WINDOWS "$match_function (via ls-files): match skip '$pattern' '$text'" 'false'
+ test_expect_failure $prereqs "$match_function (via ls-files): match skip '$pattern' '$text'" 'false'
fi
elif test "$match_expect" = 1
then
if test -e .git/created_test_file
then
- test_expect_success EXPENSIVE_ON_WINDOWS "$match_function (via ls-files): match '$pattern' '$text'" "
+ test_expect_success $prereqs "$match_function (via ls-files): match '$pattern' '$text'" "
printf '%s' '$text' >expect &&
git$ls_files_args ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
$match_stdout_stderr_cmp
"
else
- test_expect_failure EXPENSIVE_ON_WINDOWS "$match_function (via ls-files): match skip '$pattern' '$text'" 'false'
+ test_expect_failure $prereqs "$match_function (via ls-files): match skip '$pattern' '$text'" 'false'
fi
elif test "$match_expect" = 0
then
if test -e .git/created_test_file
then
- test_expect_success EXPENSIVE_ON_WINDOWS "$match_function (via ls-files): no match '$pattern' '$text'" "
+ test_expect_success $prereqs "$match_function (via ls-files): no match '$pattern' '$text'" "
>expect &&
git$ls_files_args ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
$match_stdout_stderr_cmp
"
else
- test_expect_failure EXPENSIVE_ON_WINDOWS "$match_function (via ls-files): no match skip '$pattern' '$text'" 'false'
+ test_expect_failure $prereqs "$match_function (via ls-files): no match skip '$pattern' '$text'" 'false'
fi
else
test_expect_success "PANIC: Test framework error. Unknown matches value $match_expect" 'false'
base-commit: c69baaf57ba26cf117c2b6793802877f19738b0d
--
gitgitgadget
^ permalink raw reply related
* Re: [PATCH] pkt-line: initialize packet_buffer to avoid macOS linker warning
From: Harald Nordgren @ 2026-05-28 8:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Harald Nordgren via GitGitGadget, git
In-Reply-To: <CAHwyqnWjHTpWfbMcBHOabny5NQN7xTZmxew2yDWWu3AoosngWA@mail.gmail.com>
So maybe we can do something like this then?
```
+ # Silence Xcode 16.3+ linker warning about __DATA,__common alignment.
+ LD_MAJOR_VERSION = $(shell ld -v 2>&1 | sed -n
's/.*PROJECT:ld-\([0-9]*\).*/\1/p')
+ ifeq ($(shell test "$(LD_MAJOR_VERSION)" -ge 1167 && echo 1),1)
+ BASIC_CFLAGS += -fno-common
+ endif
```
Harald
On Thu, May 28, 2026 at 9:40 AM Harald Nordgren
<haraldnordgren@gmail.com> wrote:
>
> > According to Internet, Xcode 16.3 or newer introduced this insanity,
> > it seems. How about adding -fno-common to your CFLAGS? If it
> > solves the issue, then we can think about teaching config.mak.uname
> > to detect macOS with problematic versions of compilers and add the
> > flag as workaround.
>
> Yes, this works:
>
> ```
> make -s CFLAGS_APPEND="-fno-common"
> ```
>
>
> Harald
^ permalink raw reply
* Re: [PATCH] pkt-line: initialize packet_buffer to avoid macOS linker warning
From: Harald Nordgren @ 2026-05-28 7:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Harald Nordgren via GitGitGadget, git
In-Reply-To: <xmqqse7cjku5.fsf@gitster.g>
> According to Internet, Xcode 16.3 or newer introduced this insanity,
> it seems. How about adding -fno-common to your CFLAGS? If it
> solves the issue, then we can think about teaching config.mak.uname
> to detect macOS with problematic versions of compilers and add the
> flag as workaround.
Yes, this works:
```
make -s CFLAGS_APPEND="-fno-common"
```
Harald
^ permalink raw reply
* Re: [PATCH 2/2] rebase: skip branch symref aliases
From: Kristoffer Haugsbakk @ 2026-05-28 7:08 UTC (permalink / raw)
To: Koji Nakamaru, git; +Cc: Son Luong Ngoc
In-Reply-To: <0ab0a717441e9fc7c494da194065a948a35a7f01.1779946921.git.gitgitgadget@gmail.com>
On Thu, May 28, 2026, at 07:42, Son Luong Ngoc via GitGitGadget wrote:
>[snip]
> -test_expect_failure '--update-refs skips branch symrefs to current branch' '
> +test_expect_success '--update-refs skips branch symrefs to current branch' '
> test_when_finished "
> test_might_fail git rebase --abort &&
> git checkout primary &&
This style of fixing a bug by:
• Add failing test `test_expect_failure` in the first commit
• Fix the bug in the next commit and flip to `test_expect_success`
Is legitimate and makes it easier to verify that the test really
exercises the regression. But in this project it is preferred to
just do the bug fix + regression test in one patch.
See https://lore.kernel.org/git/xmqqfrdk3aqy.fsf@gitster.g/
> --
> gitgitgadget
^ permalink raw reply
* [PATCH v2 2/2] commit: remove deprecated functions
From: kristofferhaugsbakk @ 2026-05-28 7:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kristoffer Haugsbakk, Patrick Steinhardt, git
In-Reply-To: <V2_CV_commit.h_remove_deprecated.732@msgid.xyz>
From: Kristoffer Haugsbakk <code@khaugsbakk.name>
These functions were deprecated in a series of commits merged in
52882024 (Merge branch 'ps/commit-list-functions-renamed', 2026-02-13).
The compatibility was for in-flight topics at the time.
Acked-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
Notes (series):
v2: add ack
commit.h | 19 -------------------
1 file changed, 19 deletions(-)
diff --git a/commit.h b/commit.h
index 58150045afa..5352056f87a 100644
--- a/commit.h
+++ b/commit.h
@@ -203,25 +203,6 @@ struct commit_list *commit_list_reverse(struct commit_list *list);
void commit_list_free(struct commit_list *list);
-/*
- * Deprecated compatibility functions for `struct commit_list`, to be removed
- * once Git 2.53 is released.
- */
-static inline struct commit_list *copy_commit_list(struct commit_list *l)
-{
- return commit_list_copy(l);
-}
-
-static inline struct commit_list *reverse_commit_list(struct commit_list *l)
-{
- return commit_list_reverse(l);
-}
-
-static inline void free_commit_list(struct commit_list *l)
-{
- commit_list_free(l);
-}
-
struct rev_info; /* in revision.h, it circularly uses enum cmit_fmt */
const char *repo_logmsg_reencode(struct repository *r,
--
2.54.0.16.g8f27b399cbe
^ permalink raw reply related
* [PATCH v2 1/2] *: replace deprecated free_commit_list
From: kristofferhaugsbakk @ 2026-05-28 7:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kristoffer Haugsbakk, Patrick Steinhardt, git
In-Reply-To: <V2_CV_commit.h_remove_deprecated.732@msgid.xyz>
From: Kristoffer Haugsbakk <code@khaugsbakk.name>
Replace `free_commit_list` with `commit_list_free`. The former was
deprecated in 9f18d089 (commit: rename `free_commit_list()` to conform
to coding guidelines, 2026-01-15).
This allows us to remove all the deprecated functions in the
next commit:
• `copy_commit_list`
• `reverse_commit_list`
• `free_commit_list`
Acked-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
Notes (series):
v2: add ack
builtin/history.c | 4 ++--
replay.c | 2 +-
upload-pack.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/builtin/history.c b/builtin/history.c
index 0fc06fb2045..091465a59e2 100644
--- a/builtin/history.c
+++ b/builtin/history.c
@@ -284,7 +284,7 @@ static int setup_revwalk(struct repository *repo,
commit_list_insert(original, &from_list);
ret = repo_is_descendant_of(repo, head, from_list);
- free_commit_list(from_list);
+ commit_list_free(from_list);
if (ret < 0) {
ret = error(_("cannot determine descendance"));
@@ -892,7 +892,7 @@ static int split_commit(struct repository *repo,
if (index_file.len)
unlink(index_file.buf);
strbuf_release(&index_file);
- free_commit_list(parents);
+ commit_list_free(parents);
release_index(&index);
return ret;
}
diff --git a/replay.c b/replay.c
index 4ef8abb6077..da531d5bc68 100644
--- a/replay.c
+++ b/replay.c
@@ -120,7 +120,7 @@ static struct commit *create_commit(struct repository *repo,
out:
repo_unuse_commit_buffer(repo, based_on, message);
free_commit_extra_headers(extra);
- free_commit_list(parents);
+ commit_list_free(parents);
strbuf_release(&msg);
free(author);
return (struct commit *)obj;
diff --git a/upload-pack.c b/upload-pack.c
index 9f6d6fe48c8..2bf450ab288 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -886,7 +886,7 @@ static void deepen(struct upload_pack_data *data, int depth)
data->deepen_relative, depth,
SHALLOW, NOT_SHALLOW);
send_shallow(data, result);
- free_commit_list(result);
+ commit_list_free(result);
}
send_unshallow(data);
@@ -900,7 +900,7 @@ static void deepen_by_rev_list(struct upload_pack_data *data,
disable_commit_graph(the_repository);
result = get_shallow_commits_by_rev_list(argv, SHALLOW, NOT_SHALLOW);
send_shallow(data, result);
- free_commit_list(result);
+ commit_list_free(result);
send_unshallow(data);
}
--
2.54.0.16.g8f27b399cbe
^ permalink raw reply related
* [PATCH v2 0/2] commit: remove deprecated functions
From: kristofferhaugsbakk @ 2026-05-28 7:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kristoffer Haugsbakk, Patrick Steinhardt, git
In-Reply-To: <CV_commit.h_remove_deprecated.714@msgid.xyz>
From: Kristoffer Haugsbakk <code@khaugsbakk.name>
Topic name: kh/commit-deprecated
Topic summary: Remove deprecated comments that were slated for removal
after Git 2.53.0.
See the comment:
/*
* Deprecated compatibility functions for `struct commit_list`, to be removed
* once Git 2.53 is released.
*/
I merged in `seen` and `next` yesterday and found no new in-flight usages
of these functions.
Update Thursday: retested `seen` (commit [1]) and `next` (commit [2]).
† 1: 7821a69c (Merge branch 'za/completion-hide-dotfiles' into seen, 2026-05-27)
† 2: 2f8565e1 (Sync with 'master', 2026-05-27)
I commented on this patch but apparently it hasn’t hit any of these
integration branches yet:
Patch: replay: support replaying 2-parent merges
Link: https://lore.kernel.org/git/920cc022-8b63-4dbb-a41d-957ee01a5efd@app.fastmail.com/
§ Changes v2
Add ack by Patrick, the author of these compatibility functions.
§ Link to v1
https://lore.kernel.org/git/CV_commit.h_remove_deprecated.714@msgid.xyz/#t
[1/2] *: replace deprecated free_commit_list
[2/2] commit: remove deprecated functions
builtin/history.c | 4 ++--
commit.h | 19 -------------------
replay.c | 2 +-
upload-pack.c | 4 ++--
4 files changed, 5 insertions(+), 24 deletions(-)
Interdiff against v1:
base-commit: 56a4f3c3a221adf1df9b39da69b8a6890f803157
--
2.54.0.16.g8f27b399cbe
^ permalink raw reply
* Re: [PATCH 1/2] *: replace deprecated free_commit_list
From: Kristoffer Haugsbakk @ 2026-05-28 6:49 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Kristoffer Haugsbakk
In-Reply-To: <ahfRdFXJf9SRaz5q@pks.im>
On Thu, May 28, 2026, at 07:24, Patrick Steinhardt wrote:
> On Wed, May 27, 2026 at 03:59:25PM +0200,
>>[snip]
>> ---
>> builtin/history.c | 4 ++--
>> replay.c | 2 +-
>> upload-pack.c | 4 ++--
>> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> Heh. Funny to see that I introduced the new functions, and that I was
> also the one that continued using the old ones most :)
To be honest with you that’s the first thing I checked. “I wonder if
Patrick...” x)
^ permalink raw reply
* Re: [PATCH v3 0/4] Add support for an external command for fetching notes
From: Siddh Raman Pant @ 2026-05-28 5:59 UTC (permalink / raw)
To: git@vger.kernel.org
Cc: oswald.buddenhagen@gmx.de, gitster@pobox.com,
code@khaugsbakk.name, j6t@kdbg.org, peff@peff.net, ps@pks.im,
sandals@crustytoothpaste.net, newren@gmail.com
In-Reply-To: <cover.1779532562.git.siddh.raman.pant@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 3389 bytes --]
Hi,
Pinging since it's been almost a week (v2 was sent on Fri)...
I sent close/during the weekend, so I think this fell through.
Sorry if this bothers. Just curious as I haven't heard back like the
last time.
Thanks,
Siddh
On Sat, May 23 2026 at 16:08:08 +0530, Siddh Raman Pant wrote:
> v2: https://lore.kernel.org/git/cover.1779464886.git.siddh.raman.pant@oracle.com/
> v1: https://lore.kernel.org/git/cover.1779207350.git.siddh.raman.pant@oracle.com/
>
> <...insert text from v1 cover here...>
>
> Changes since v2:
> - Removed stale help text talking about force-killing helper process.
>
> Changes since v1:
> - Removed Documentation commit and sent as a standalone patch.
> - Removed finish_command_with_timeout addition (and thus sleep_nanosec).
> - Squashed the external notes command code, doc, and test commits.
> - Removed horizontal separators from note-external.c.
> - Removed global variables from translation unit and instead store config in
> a dedicated new struct member in struct display_notes_opt.
> - Reworded the main commit to have better explanation of the motivation.
>
> Siddh Raman Pant (4):
> notes: convert raw arg in format_display_notes() to bool
> wrapper: add support for timeout and deadline in read helpers
> t3301: cover generic displayed notes behavior
> notes: support an external command to display notes
>
> Documentation/config/notes.adoc | 59 +++
> Documentation/git-format-patch.adoc | 11 +-
> Documentation/git-range-diff.adoc | 6 +
> Documentation/pretty-options.adoc | 9 +
> Makefile | 2 +
> builtin/log.c | 17 +-
> builtin/name-rev.c | 9 +-
> builtin/range-diff.c | 2 +
> contrib/completion/git-completion.bash | 4 +-
> log-tree.c | 10 +-
> meson.build | 1 +
> notes-external.c | 414 ++++++++++++++++++
> notes-external.h | 53 +++
> notes.c | 266 +++++++++---
> notes.h | 33 +-
> revision.c | 36 +-
> strbuf.c | 26 +-
> strbuf.h | 4 +
> t/helper/meson.build | 1 +
> t/helper/test-external-notes | 64 +++
> t/helper/test-notes-external-config-reset.c | 24 ++
> t/helper/test-tool.c | 1 +
> t/helper/test-tool.h | 1 +
> t/lib-notes.sh | 19 +
> t/t3206-range-diff.sh | 68 +++
> t/t3301-notes.sh | 448 ++++++++++++++++++++
> t/t6120-describe.sh | 17 +
> wrapper.c | 139 +++++-
> wrapper.h | 23 +
> 29 files changed, 1691 insertions(+), 76 deletions(-)
> create mode 100644 notes-external.c
> create mode 100644 notes-external.h
> create mode 100755 t/helper/test-external-notes
> create mode 100644 t/helper/test-notes-external-config-reset.c
> create mode 100644 t/lib-notes.sh
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH 2/2] rebase: skip branch symref aliases
From: Son Luong Ngoc via GitGitGadget @ 2026-05-28 5:42 UTC (permalink / raw)
To: git; +Cc: Son Luong Ngoc, Son Luong Ngoc
In-Reply-To: <pull.2126.git.1779946921.gitgitgadget@gmail.com>
From: Son Luong Ngoc <sluongng@gmail.com>
rebase --update-refs records local branch decorations before replaying
commits. If a decoration is a symbolic branch such as refs/heads/main
pointing at refs/heads/master, updating it later dereferences back to
master and can fail because the normal rebase path already moved that
branch.
Resolve local branch symref decorations to their referents before
queuing update-ref commands, and skip duplicates. This keeps branch
aliases from scheduling a second update for the same underlying branch
while still using the existing old-OID check for the single queued
update.
Signed-off-by: Son Luong Ngoc <sluongng@gmail.com>
---
sequencer.c | 63 +++++++++++++++++++++++++++++------
t/t3404-rebase-interactive.sh | 2 +-
2 files changed, 53 insertions(+), 12 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 1ee4b2875b..4a83d1337c 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -6445,15 +6445,22 @@ static int add_decorations_to_list(const struct commit *commit,
struct todo_add_branch_context *ctx)
{
const struct name_decoration *decoration = get_name_decoration(&commit->object);
- const char *head_ref = refs_resolve_ref_unsafe(get_main_ref_store(the_repository),
- "HEAD",
+ struct ref_store *refs = get_main_ref_store(the_repository);
+ const char *head_ref = refs_resolve_ref_unsafe(refs, "HEAD",
RESOLVE_REF_READING,
- NULL,
- NULL);
+ NULL, NULL);
+ char *resolved_head_ref = refs_resolve_refdup(refs, "HEAD",
+ RESOLVE_REF_READING,
+ NULL, NULL);
+ struct strbuf update_ref = STRBUF_INIT;
while (decoration) {
struct todo_item *item;
const char *path;
+ const char *ref = decoration->name;
+ const char *resolved_ref;
+ int is_symref = 0;
+ int flags = 0;
size_t base_offset = ctx->buf->len;
/*
@@ -6461,12 +6468,44 @@ static int add_decorations_to_list(const struct commit *commit,
* updated by the default rebase behavior.
* Exclude it from the list of refs to update,
* as well as any non-branch decorations.
+ *
+ * Resolve branch symrefs after checking for the current HEAD so
+ * that aliases do not schedule duplicate updates for their
+ * referents.
+ *
* Non-branch decorations may be present if the pretty format
* includes "%d", which would have loaded all refs
* into the global decoration table.
*/
- if ((head_ref && !strcmp(head_ref, decoration->name)) ||
- (decoration->type != DECORATION_REF_LOCAL)) {
+ if (decoration->type != DECORATION_REF_LOCAL) {
+ decoration = decoration->next;
+ continue;
+ }
+
+ if (head_ref && !strcmp(head_ref, ref)) {
+ decoration = decoration->next;
+ continue;
+ }
+
+ strbuf_reset(&update_ref);
+ resolved_ref = refs_resolve_ref_unsafe(refs, ref,
+ RESOLVE_REF_READING |
+ RESOLVE_REF_NO_RECURSE,
+ NULL, &flags);
+ if ((flags & REF_ISSYMREF) && resolved_ref) {
+ if (!starts_with(resolved_ref, "refs/heads/")) {
+ decoration = decoration->next;
+ continue;
+ }
+
+ strbuf_addstr(&update_ref, resolved_ref);
+ ref = update_ref.buf;
+ is_symref = 1;
+ }
+
+ if ((is_symref && resolved_head_ref &&
+ !strcmp(resolved_head_ref, ref)) ||
+ string_list_has_string(&ctx->refs_to_oids, ref)) {
decoration = decoration->next;
continue;
}
@@ -6478,19 +6517,19 @@ static int add_decorations_to_list(const struct commit *commit,
memset(item, 0, sizeof(*item));
/* If the branch is checked out, then leave a comment instead. */
- if ((path = branch_checked_out(decoration->name))) {
+ if ((path = branch_checked_out(ref))) {
item->command = TODO_COMMENT;
strbuf_commented_addf(ctx->buf, comment_line_str,
"Ref %s checked out at '%s'\n",
- decoration->name, path);
+ ref, path);
} else {
struct string_list_item *sti;
item->command = TODO_UPDATE_REF;
- strbuf_addf(ctx->buf, "%s\n", decoration->name);
+ strbuf_addf(ctx->buf, "%s\n", ref);
sti = string_list_insert(&ctx->refs_to_oids,
- decoration->name);
- sti->util = init_update_ref_record(decoration->name);
+ ref);
+ sti->util = init_update_ref_record(ref);
}
item->offset_in_buf = base_offset;
@@ -6501,6 +6540,8 @@ static int add_decorations_to_list(const struct commit *commit,
decoration = decoration->next;
}
+ strbuf_release(&update_ref);
+ free(resolved_head_ref);
return 0;
}
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 42ba8cc313..29447c0fc3 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -1978,7 +1978,7 @@ test_expect_success '--update-refs ignores non-branch decorations' '
test_cmp expect actual
'
-test_expect_failure '--update-refs skips branch symrefs to current branch' '
+test_expect_success '--update-refs skips branch symrefs to current branch' '
test_when_finished "
test_might_fail git rebase --abort &&
git checkout primary &&
--
gitgitgadget
^ permalink raw reply related
* [PATCH 1/2] t3404: add failing branch symref test
From: Son Luong Ngoc via GitGitGadget @ 2026-05-28 5:42 UTC (permalink / raw)
To: git; +Cc: Son Luong Ngoc, Son Luong Ngoc
In-Reply-To: <pull.2126.git.1779946921.gitgitgadget@gmail.com>
From: Son Luong Ngoc <sluongng@gmail.com>
rebase --update-refs queues local branch decorations by their literal
refnames. When a branch such as refs/heads/main is a symbolic ref to
the current branch, the normal rebase path first updates the current
branch and the queued symref update later tries to update the same
referent with the old value it recorded before the rebase.
Add a known-breakage test that exercises this case so that the fix can
flip it to test_expect_success. The expected behavior is that the branch
symref keeps pointing at the rebased current branch.
Signed-off-by: Son Luong Ngoc <sluongng@gmail.com>
---
t/t3404-rebase-interactive.sh | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 58b3bb0c27..42ba8cc313 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -1978,6 +1978,31 @@ test_expect_success '--update-refs ignores non-branch decorations' '
test_cmp expect actual
'
+test_expect_failure '--update-refs skips branch symrefs to current branch' '
+ test_when_finished "
+ test_might_fail git rebase --abort &&
+ git checkout primary &&
+ test_might_fail git symbolic-ref -d refs/heads/update-refs-symref-alias &&
+ test_might_fail git branch -D update-refs-symref update-refs-symref-base
+ " &&
+ git checkout -B update-refs-symref-base primary &&
+ test_commit --no-tag update-refs-symref-base symref-base.t &&
+ git checkout -B update-refs-symref &&
+ test_commit --no-tag update-refs-symref-topic symref-topic.t &&
+ git checkout update-refs-symref-base &&
+ test_commit --no-tag update-refs-symref-newbase symref-newbase.t &&
+ git checkout update-refs-symref &&
+ git symbolic-ref refs/heads/update-refs-symref-alias refs/heads/update-refs-symref &&
+
+ git rebase --update-refs update-refs-symref-base 2>err &&
+
+ test_cmp_rev update-refs-symref-base update-refs-symref^ &&
+ test_cmp_rev refs/heads/update-refs-symref refs/heads/update-refs-symref-alias &&
+ test_write_lines refs/heads/update-refs-symref >expect &&
+ git symbolic-ref refs/heads/update-refs-symref-alias >actual &&
+ test_cmp expect actual
+'
+
test_expect_success '--update-refs updates refs correctly' '
git checkout -B update-refs no-conflict-branch &&
git branch -f base HEAD~4 &&
--
gitgitgadget
^ permalink raw reply related
* [PATCH 0/2] rebase: handle --update-refs branch symrefs
From: Son Luong Ngoc via GitGitGadget @ 2026-05-28 5:41 UTC (permalink / raw)
To: git; +Cc: Son Luong Ngoc
git rebase --update-refs can fail after the normal rebase path has
successfully updated the current branch when another local branch is a
symbolic ref to it.
One practical way to arrive at that setup is a default branch rename from
master to main. While the migration is in progress, a user may keep
refs/heads/main as a symbolic ref to refs/heads/master so that both names
continue to work locally.
If pull.rebase is enabled, a plain git pull can then finish the rebase of
master and still fail while trying to update the main alias. The reported
failure looked like this, with line breaks adjusted for the cover letter:
Successfully rebased and updated refs/heads/master.
error: update_ref failed for ref 'refs/heads/main':
cannot lock ref 'refs/heads/main':
is at fc2c7bd5f17abec7861ef759edcd33a1e16662a1
but expected 531cabdfb49098d6ffa502ed4bf91d1b35edfcfa
Updated the following refs with --update-refs:
Failed to update the following refs with --update-refs:
refs/heads/main
The sequencer builds its update-ref todo commands from local branch
decorations. It excludes the current branch by comparing the literal
decoration name with the resolved HEAD ref, so refs/heads/main is not
recognized as the current branch alias. The final update then dereferences
the alias back to master, but master has already moved, so the old-OID check
fails.
This series keeps that failure mode explicit by adding a known-breakage test
first, so that the behavioral expectation is clear before the fix. The fix
then resolves local branch symref decorations before queuing update-ref
commands, skips aliases of the current branch, and skips duplicate
referents. That keeps the existing old-OID protection on the single real
branch update. It also avoids teaching the final ref update step to treat
this race-looking mismatch as success.
Patch overview:
* Patch 1 records the branch-symref failure in t3404.
* Patch 2 flips the test and canonicalizes sequencer behavior.
Son Luong Ngoc (2):
t3404: add failing branch symref test
rebase: skip branch symref aliases
sequencer.c | 63 +++++++++++++++++++++++++++++------
t/t3404-rebase-interactive.sh | 25 ++++++++++++++
2 files changed, 77 insertions(+), 11 deletions(-)
base-commit: c69baaf57ba26cf117c2b6793802877f19738b0d
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2126%2Fsluongng%2Fsl%2Frebase-update-refs-symrefs-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2126/sluongng/sl/rebase-update-refs-symrefs-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/2126
--
gitgitgadget
^ permalink raw reply
* Re: [PATCH 2/2] commit: remove deprecated functions
From: Patrick Steinhardt @ 2026-05-28 5:24 UTC (permalink / raw)
To: kristofferhaugsbakk; +Cc: git, Kristoffer Haugsbakk
In-Reply-To: <commit.h_remove_deprecated.716@msgid.xyz>
On Wed, May 27, 2026 at 03:59:26PM +0200, kristofferhaugsbakk@fastmail.com wrote:
> From: Kristoffer Haugsbakk <code@khaugsbakk.name>
>
> These functions were deprecated in a series of commits merged in
> 52882024 (Merge branch 'ps/commit-list-functions-renamed', 2026-02-13).
>
> The compatibility was for in-flight topics at the time.
Yup, makes sense. Thanks for following through with the cleanup!
Patrick
^ permalink raw reply
* Re: [PATCH 1/2] *: replace deprecated free_commit_list
From: Patrick Steinhardt @ 2026-05-28 5:24 UTC (permalink / raw)
To: kristofferhaugsbakk; +Cc: git, Kristoffer Haugsbakk
In-Reply-To: <commit.h_replace_deprecated.715@msgid.xyz>
On Wed, May 27, 2026 at 03:59:25PM +0200, kristofferhaugsbakk@fastmail.com wrote:
> From: Kristoffer Haugsbakk <code@khaugsbakk.name>
>
> Replace `free_commit_list` with `commit_list_free`. The former was
> deprecated in 9f18d089 (commit: rename `free_commit_list()` to conform
> to coding guidelines, 2026-01-15).
>
> This allows us to remove all the deprecated functions in the
> next commit:
>
> • `copy_commit_list`
> • `reverse_commit_list`
> • `free_commit_list`
>
> Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
> ---
> builtin/history.c | 4 ++--
> replay.c | 2 +-
> upload-pack.c | 4 ++--
> 3 files changed, 5 insertions(+), 5 deletions(-)
Heh. Funny to see that I introduced the new functions, and that I was
also the one that continued using the old ones most :)
Patrick
^ permalink raw reply
* Suggestion: Real-time or Conflict-Reducing Collaboration Support for Specific Directories
From: 胡锦 @ 2026-05-28 5:15 UTC (permalink / raw)
To: git
Dear Git Team,
My name is Hujin, and I am an IT engineer from China. I have been using Git for more than 10 years.
First of all, I would like to express my appreciation for Git. In my experience, Git remains one of the best and most reliable version control systems in modern software development. It has played an important role in many projects I have worked on.
However, I have also encountered a recurring difficulty in daily use. For certain types of files, especially files under script directories or other frequently modified directories, conflicts happen quite often because updates are not synchronized in real time. In some project scenarios, multiple engineers may edit related scripts at the same time, and this can lead to repeated merge conflicts and extra coordination costs.
I wonder whether Git could provide, in future versions, some optional features similar to online collaborative documents, or directory-level collaboration mechanisms for specific files or folders. For example, users could enable special real-time update, lock, notification, or conflict-reduction behavior for selected directories such as scripts. This could help reduce conflicts and make Git even more convenient for teams working on highly shared files.
I understand that Git is designed as a distributed version control system, and such functionality may not be simple to implement. Still, I believe an optional feature in this direction could be very helpful for many engineering teams.
Thank you for your great work on Git. I look forward to hearing your thoughts.
Best regards,Hujin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox