Makefile: link osxkeychain helper against Rust by kiranani · Pull Request #2288 · git/git

kiranani · 2026-05-05T05:11:16Z

This series improves macOS build reliability, automated CI verification, and distribution support when Rust is enabled in the Git build system. It addresses three distinct challenges: a parallel build race condition in git-credential-osxkeychain, support for macOS Universal Binaries (multi-architecture distribution), and missing automated CI test wiring for macOS contrib utilities.

Why This Series is Needed

Parallel Build Race Condition (make -j):
While commit 522ea8e ("osxkeychain: fix build with Rust") updated the link command for git-credential-osxkeychain to pass $(LIBS), it omitted $(RUST_LIB) from the target prerequisite list. When running a parallel build (make -j) from a clean working tree, Make can attempt to link git-credential-osxkeychain before Cargo has finished compiling libgitcore.a, causing linker failures.
macOS Universal Binary (lipo) Support:
On macOS, Universal Binaries bundle native executable code for multiple architectures (Intel x86_64 and Apple Silicon arm64) into a single file. This is standard practice for macOS distribution and CI packaging (such as Burrito, Homebrew, and Git's macOS CI runners), allowing a single artifact to run natively across all Macs without Rosetta translation.

While Apple's C compiler (clang) natively supports universal builds by passing -arch x86_64 -arch arm64 in CFLAGS and LDFLAGS, Cargo and rustc do not support multiple -arch flags in a single invocation. Instead, Cargo must be invoked separately for each target triple (--target x86_64-apple-darwin and --target aarch64-apple-darwin). This series bridges that gap.

Automated CI Verification for Contrib on macOS:
When running make test with TEST_CONTRIB_TOO=yes (default in macOS CI workflows), $(MAKE) -C contrib/ test is invoked. However, contrib/Makefile only invoked tests for diff-highlight and subtree, meaning git-credential-osxkeychain was never compiled or verified during standard CI test runs.

Overview of Patches

Patch 1: Makefile: add $(RUST_LIB) prerequisite to osxkeychain
Adds $(RUST_LIB) as a prerequisite dependency to the osxkeychain target, eliminating the parallel build race condition. Additionally, wraps the definitions of $(RUST_LIB) and the rust build target in ifndef NO_RUST so that disabling Rust cleanly makes the dependency a no-op.
Patch 2: Makefile: support universal macOS builds via RUST_TARGETS
Allows users to specify space-separated target triples in RUST_TARGETS. Introduces declarative pattern rules (target/%/...) to compile each target slice via Cargo, and uses lipo (part of the mandatory Xcode Command Line Tools) to combine the resulting static archives into a universal library at target/release/libgitcore.a. Uses mkdir_p_parent_template to guarantee directory creation before lipo.
- Patch 3: contrib: wire up osxkeychain in contrib/Makefile on macOS
  Adds a test target to contrib/credential/osxkeychain/Makefile that depends on building git-credential-osxkeychain. Introduces a generic OS_CONTRIB variable in contrib/Makefile to conditionally wire credential/osxkeychain into all, test, and clean whenever running on macOS (Darwin). This guarantees that standard CI test runs on macOS automatically compile and link the helper, preventing build regressions.

Changes since v7:

Added inclusion of ../config.mak.uname to the top of contrib/Makefile in the canonical order. This guarantees that $(uname_S) is correctly defined on the shell, preventing the OS_CONTRIB additions from being silently ignored.

Changes since v5:

Reverted Patch 1 to depend explicitly on $(LIB_FILE) $(RUST_LIB) rather than $(GITLIBS). Unlike Git builtins or scalar (which define cmd_main()), git-credential-osxkeychain.c defines its own standalone main(), meaning $(GITLIBS) caused a duplicate symbol error for _main during linking.
Added Patch 3 ("contrib: wire up osxkeychain in contrib/Makefile on macOS") using a scalable OS_CONTRIB variable so that running make test with TEST_CONTRIB_TOO=yes in macOS CI workflows automatically verifies compilation and linking integrity.

Changes since v4:

Changed the osxkeychain prerequisite dependency from $(LIB_FILE) $(RUST_LIB) to $(GITLIBS) to match the canonical prerequisite pattern used by all other core Git targets linking $(LIBS).

Changes since v3:

Removed leading @ from $(call mkdir_p_parent_template) so it relies on the built-in $(QUIET_MKDIR_P_PARENT) behavior, matching existing Makefile conventions.
Replaced if [ with if test in Bourne shell recipe snippets to strictly adhere to the project's CodingGuidelines.

Changes since v2:

Split the original combined commit into a two-patch series to separate prerequisite bug fixes from Universal Binary features.
Added $(call mkdir_p_parent_template) prior to invoking lipo to guarantee that parent target directories exist.

cc: "Kristoffer Haugsbakk" kristofferhaugsbakk@fastmail.com
cc: "Shardul Natu" snatu@google.com
cc: "Koji Nakamaru" koji.nakamaru@gree.net
cc: Patrick Steinhardt ps@pks.im
cc: Shardul Natu shardul.27591@gmail.com
cc: Ben Knoble ben.knoble@gmail.com

gitgitgadget-git · 2026-05-05T05:11:48Z

Welcome to GitGitGadget

Hi @kiranani, and welcome to GitGitGadget, the GitHub App to send patch series to the Git mailing list from GitHub Pull Requests.

Please make sure that either:

Your Pull Request has a good description, if it consists of multiple commits, as it will be used as cover letter.
Your Pull Request description is empty, if it consists of a single commit, as the commit message should be descriptive enough by itself.

You can CC potential reviewers by adding a footer to the PR description with the following syntax:

CC: Revi Ewer <revi.ewer@example.com>, Ill Takalook <ill.takalook@example.net>

NOTE: DO NOT copy/paste your CC list from a previous GGG PR's description,
because it will result in a malformed CC list on the mailing list. See
example.

Also, it is a good idea to review the commit messages one last time, as the Git project expects them in a quite specific form:

the lines should not exceed 76 columns,
the first line should be like a header and typically start with a prefix like "tests:" or "revisions:" to state which subsystem the change is about, and
the commit messages' body should be describing the "why?" of the change.
Finally, the commit messages should end in a Signed-off-by: line matching the commits' author.

It is in general a good idea to await the automated test ("Checks") in this Pull Request before contributing the patches, e.g. to avoid trivial issues such as unportable code.

Contributing the patches

Before you can contribute the patches, your GitHub username needs to be added to the list of permitted users. Any already-permitted user can do that, by adding a comment to your PR of the form /allow. A good way to find other contributors is to locate recent pull requests where someone has been /allowed:

Search: is:pr is:open "/allow"

Both the person who commented /allow and the PR author are able to /allow you.

An alternative is the channel #git-devel on the Libera Chat IRC network:

<newcontributor> I've just created my first PR, could someone please /allow me? https://github.com/gitgitgadget/git/pull/12345
<veteran> newcontributor: it is done
<newcontributor> thanks!

Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment /submit.

If you want to see what email(s) would be sent for a /submit request, add a PR comment /preview to have the email(s) sent to you. You must have a public GitHub email address for this. Note that any reviewers CC'd via the list in the PR description will not actually be sent emails.

After you submit, GitGitGadget will respond with another comment that contains the link to the cover letter mail in the Git mailing list archive. Please make sure to monitor the discussion in that thread and to address comments and suggestions (while the comments and suggestions will be mirrored into the PR by GitGitGadget, you will still want to reply via mail).

If you do not want to subscribe to the Git mailing list just to be able to respond to a mail, you can download the mbox from the Git mailing list archive (click the (raw) link), then import it into your mail program. If you use GMail, you can do this via:

curl -g --user "<EMailAddress>:<Password>" \
    --url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txt

To iterate on your change, i.e. send a revised patch or patch series, you will first want to (force-)push to the same branch. You probably also want to modify your Pull Request description (or title). It is a good idea to summarize the revision by adding something like this to the cover letter (read: by editing the first comment on the PR, i.e. the PR description):

Changes since v1:
- Fixed a typo in the commit message (found by ...)
- Added a code comment to ... as suggested by ...
...

To send a new iteration, just add another PR comment with the contents: /submit.

Need help?

New contributors who want advice are encouraged to join git-mentoring@googlegroups.com, where volunteers who regularly contribute to Git are willing to answer newbie questions, give advice, or otherwise provide mentoring to interested contributors. You must join in order to post or view messages, but anyone can join.

You may also be able to find help in real time in the developer IRC channel, #git-devel on Libera Chat. Remember that IRC does not support offline messaging, so if you send someone a private message and log out, they cannot respond to you. The scrollback of #git-devel is archived, though.

dscho · 2026-05-05T09:36:09Z

/allow

gitgitgadget-git · 2026-05-05T09:36:53Z

User kiranani is now allowed to use GitGitGadget.

WARNING: kiranani has no public email address set on GitHub; GitGitGadget needs an email address to Cc: you on your contribution, so that you receive any feedback on the Git mailing list. Go to https://github.com/settings/profile to make your preferred email public to let GitGitGadget know which email address to use.

kiranani · 2026-05-05T17:25:07Z

/submit

gitgitgadget-git · 2026-05-05T17:26:34Z

Submitted as pull.2288.git.git.1778001976709.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-git-2288/kiranani/next-v1

To fetch this version to local tag pr-git-2288/kiranani/next-v1:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-git-2288/kiranani/next-v1

WARNING: kiranani has no public email address set on GitHub; GitGitGadget needs an email address to Cc: you on your contribution, so that you receive any feedback on the Git mailing list. Go to https://github.com/settings/profile to make your preferred email public to let GitGitGadget know which email address to use.

gitgitgadget-git · 2026-05-05T19:54:58Z

"Kristoffer Haugsbakk" wrote on the Git mailing list (how to reply to this email):

On Tue, May 5, 2026, at 19:26, Shardul Natu via GitGitGadget wrote:
> From: Shnatu <snatu@google.com>
>
> When Rust is enabled, ensure that the git-credential-osxkeychain
> helper is linked with the necessary Rust libraries.
>
> Introduce the RUST_LIBS variable inside ifndef NO_RUST block
> to hold the Rust library dependency, and use it in the helper's
> build target. This cleanly handles cases where Rust is disabled,
> making it a no-op and avoiding any build failures on systems
> without Cargo.
>
> This addresses reviewer feedback from internal CL 910223487
> by simplifying the variables and avoiding confusing "LINK"
> terminology.

This pararagraph is meaningless to those outside internal.

>
> Signed-off-by: Shnatu <snatu@google.com>
> ---
>[snip]

gitgitgadget-git · 2026-05-05T19:55:00Z

User "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> has been added to the cc: list.

gitgitgadget-git · 2026-05-06T23:54:52Z

There are issues in commit fde105f:
Makefile: link osxkeychain & support universal Rust

Commit not signed off
Lines in the body of the commit messages should be wrapped between 60 and 76 characters.
Indented lines, and lines without whitespace, are exempt

kiranani · 2026-05-06T23:57:44Z

"Kristoffer Haugsbakk" wrote on the Git mailing list (how to reply to this email):

On Tue, May 5, 2026, at 19:26, Shardul Natu via GitGitGadget wrote:
> From: Shnatu <snatu@google.com>
>
> When Rust is enabled, ensure that the git-credential-osxkeychain
> helper is linked with the necessary Rust libraries.
>
> Introduce the RUST_LIBS variable inside ifndef NO_RUST block
> to hold the Rust library dependency, and use it in the helper's
> build target. This cleanly handles cases where Rust is disabled,
> making it a no-op and avoiding any build failures on systems
> without Cargo.
>
> This addresses reviewer feedback from internal CL 910223487
> by simplifying the variables and avoiding confusing "LINK"
> terminology.

This pararagraph is meaningless to those outside internal.

>
> Signed-off-by: Shnatu <snatu@google.com>
> ---
>[snip]

Updated the description to remove that paragraph too

dscho · 2026-05-07T00:02:24Z

"Kristoffer Haugsbakk" wrote on the Git mailing list (how to reply to this email):

On Tue, May 5, 2026, at 19:26, Shardul Natu via GitGitGadget wrote:
> From: Shnatu <snatu@google.com>
>
> When Rust is enabled, ensure that the git-credential-osxkeychain
> helper is linked with the necessary Rust libraries.
>
> Introduce the RUST_LIBS variable inside ifndef NO_RUST block
> to hold the Rust library dependency, and use it in the helper's
> build target. This cleanly handles cases where Rust is disabled,
> making it a no-op and avoiding any build failures on systems
> without Cargo.
>
> This addresses reviewer feedback from internal CL 910223487
> by simplifying the variables and avoiding confusing "LINK"
> terminology.

This pararagraph is meaningless to those outside internal.

>
> Signed-off-by: Shnatu <snatu@google.com>
> ---
>[snip]

Updated the description to remove that paragraph too

@kiranani Please note that your reply is not going to reach the Git mailing list because the mirroring performed by GitGitGadget is only one way from the Git mailing list to this PR. You will have to follow the instructions under the label "reply to this" to make your answer reach Kristoffer.

gitgitgadget-git · 2026-05-07T01:18:41Z

Shnatu wrote on the Git mailing list (how to reply to this email):

I have remove the Google specific paragraph, in addition to updating the description

gitgitgadget-git · 2026-05-07T01:18:43Z

User Shnatu <snatu@google.com> has been added to the cc: list.

gitgitgadget-git · 2026-05-08T03:52:06Z

Junio C Hamano wrote on the Git mailing list (how to reply to this email):

"Shardul Natu via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Shnatu <snatu@google.com>

If your name is "Shardul Natu", we'd prefer (not 'require', but
'prefer') that the patches authored by you also identify with that
name, both on "From:" and "Signed-off-by:"..

> When Rust is enabled, ensure that the git-credential-osxkeychain
> helper is linked with the necessary Rust libraries.
>
> Introduce the RUST_LIBS variable inside ifndef NO_RUST block
> to hold the Rust library dependency, and use it in the helper's
> build target. This cleanly handles cases where Rust is disabled,
> making it a no-op and avoiding any build failures on systems
> without Cargo.
>
> This addresses reviewer feedback from internal CL 910223487
> by simplifying the variables and avoiding confusing "LINK"
> terminology.
>
> Signed-off-by: Shnatu <snatu@google.com>
> ---
>     Makefile: link osxkeychain helper against Rust

Thanks.  I've added to CC: a few folks who may be more clueful in
the affected area than I am.  It somehow feels strange that we have
to have RUST_LIB and RUST_LIBS separately, and apparently with the
new definition the latter is expected to be a superset of the
former, and it is unclear what are the things that should be added
to the latter without getting added to the former.

> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2288%2Fkiranani%2Fnext-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2288/kiranani/next-v1
> Pull-Request: https://github.com/git/git/pull/2288
>
>  Makefile | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index f86173f93a..a17dca22b1 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1593,6 +1593,7 @@ ALL_LDFLAGS = $(LDFLAGS) $(LDFLAGS_APPEND)
>  ifndef NO_RUST
>  BASIC_CFLAGS += -DWITH_RUST
>  GITLIBS += $(RUST_LIB)
> +RUST_LIBS = $(RUST_LIB)
>  ifeq ($(uname_S),Windows)
>  EXTLIBS += -luserenv
>  endif
> @@ -4082,9 +4083,9 @@ $(LIBGIT_HIDDEN_EXPORT): $(LIBGIT_PARTIAL_EXPORT)
>  contrib/libgit-sys/libgitpub.a: $(LIBGIT_HIDDEN_EXPORT)
>  	$(AR) $(ARFLAGS) $@ $^
>  
> -contrib/credential/osxkeychain/git-credential-osxkeychain: contrib/credential/osxkeychain/git-credential-osxkeychain.o $(LIB_FILE) GIT-LDFLAGS
> +contrib/credential/osxkeychain/git-credential-osxkeychain: contrib/credential/osxkeychain/git-credential-osxkeychain.o $(LIB_FILE) $(RUST_LIBS) GIT-LDFLAGS
>  	$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) \
> -		$(filter %.o,$^) $(LIB_FILE) $(EXTLIBS) -framework Security -framework CoreFoundation
> +		$(filter %.o,$^) $(LIB_FILE) $(RUST_LIBS) $(EXTLIBS) -framework Security -framework CoreFoundation
>  
>  contrib/credential/osxkeychain/git-credential-osxkeychain.o: contrib/credential/osxkeychain/git-credential-osxkeychain.c GIT-CFLAGS
>  	$(QUIET_LINK)$(CC) -o $@ -c $(dep_args) $(compdb_args) $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) $<
>
> base-commit: 4f69b47b940100b02630f745a52f9d9850f122b2

gitgitgadget-git · 2026-05-08T10:13:00Z

Koji Nakamaru wrote on the Git mailing list (how to reply to this email):

On Fri, May 8, 2026 at 11:54 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> "Shardul Natu via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > From: Shnatu <snatu@google.com>
>
> If your name is "Shardul Natu", we'd prefer (not 'require', but
> 'prefer') that the patches authored by you also identify with that
> name, both on "From:" and "Signed-off-by:"..
>
> > When Rust is enabled, ensure that the git-credential-osxkeychain
> > helper is linked with the necessary Rust libraries.
> >
> > Introduce the RUST_LIBS variable inside ifndef NO_RUST block
> > to hold the Rust library dependency, and use it in the helper's
> > build target. This cleanly handles cases where Rust is disabled,
> > making it a no-op and avoiding any build failures on systems
> > without Cargo.
> >
> > This addresses reviewer feedback from internal CL 910223487
> > by simplifying the variables and avoiding confusing "LINK"
> > terminology.
> >
> > Signed-off-by: Shnatu <snatu@google.com>
> > ---
> >     Makefile: link osxkeychain helper against Rust
>
> Thanks.  I've added to CC: a few folks who may be more clueful in
> the affected area than I am.  It somehow feels strange that we have
> to have RUST_LIB and RUST_LIBS separately, and apparently with the
> new definition the latter is expected to be a superset of the
> former, and it is unclear what are the things that should be added
> to the latter without getting added to the former.
>
> > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2288%2Fkiranani%2Fnext-v1
> > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2288/kiranani/next-v1
> > Pull-Request: https://github.com/git/git/pull/2288
> >
> >  Makefile | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index f86173f93a..a17dca22b1 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1593,6 +1593,7 @@ ALL_LDFLAGS = $(LDFLAGS) $(LDFLAGS_APPEND)
> >  ifndef NO_RUST
> >  BASIC_CFLAGS += -DWITH_RUST
> >  GITLIBS += $(RUST_LIB)
> > +RUST_LIBS = $(RUST_LIB)
> >  ifeq ($(uname_S),Windows)
> >  EXTLIBS += -luserenv
> >  endif
> > @@ -4082,9 +4083,9 @@ $(LIBGIT_HIDDEN_EXPORT): $(LIBGIT_PARTIAL_EXPORT)
> >  contrib/libgit-sys/libgitpub.a: $(LIBGIT_HIDDEN_EXPORT)
> >       $(AR) $(ARFLAGS) $@ $^
> >
> > -contrib/credential/osxkeychain/git-credential-osxkeychain: contrib/credential/osxkeychain/git-credential-osxkeychain.o $(LIB_FILE) GIT-LDFLAGS
> > +contrib/credential/osxkeychain/git-credential-osxkeychain: contrib/credential/osxkeychain/git-credential-osxkeychain.o $(LIB_FILE) $(RUST_LIBS) GIT-LDFLAGS
> >       $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) \
> > -             $(filter %.o,$^) $(LIB_FILE) $(EXTLIBS) -framework Security -framework CoreFoundation
> > +             $(filter %.o,$^) $(LIB_FILE) $(RUST_LIBS) $(EXTLIBS) -framework Security -framework CoreFoundation
> >
> >  contrib/credential/osxkeychain/git-credential-osxkeychain.o: contrib/credential/osxkeychain/git-credential-osxkeychain.c GIT-CFLAGS
> >       $(QUIET_LINK)$(CC) -o $@ -c $(dep_args) $(compdb_args) $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) $<
> >
> > base-commit: 4f69b47b940100b02630f745a52f9d9850f122b2

How about simply wrapping the RUST_LIB-related sections in ifndef
NO_RUST, as shown below? This way, we can avoid defining
RUST_LIBS.

diff --git a/Makefile b/Makefile
index f86173f93a..daa1691950 100644
--- a/Makefile
+++ b/Makefile
@@ -947,11 +947,13 @@ else
 RUST_TARGET_DIR = target/release
 endif

+ifndef NO_RUST
 ifeq ($(uname_S),Windows)
 RUST_LIB = $(RUST_TARGET_DIR)/gitcore.lib
 else
 RUST_LIB = $(RUST_TARGET_DIR)/libgitcore.a
 endif
+endif

 GITLIBS = common-main.o $(LIB_FILE)
 EXTLIBS =
@@ -3027,11 +3029,13 @@ scalar$X: scalar.o GIT-LDFLAGS $(GITLIBS)
 $(LIB_FILE): $(LIB_OBJS)
        $(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^

+ifndef NO_RUST
 $(RUST_LIB): Cargo.toml $(RUST_SOURCES) $(LIB_FILE)
        $(QUIET_CARGO)cargo build $(CARGO_ARGS)

 .PHONY: rust
 rust: $(RUST_LIB)
+endif

 export DEFAULT_EDITOR DEFAULT_PAGER

@@ -4082,9 +4086,9 @@ $(LIBGIT_HIDDEN_EXPORT): $(LIBGIT_PARTIAL_EXPORT)
 contrib/libgit-sys/libgitpub.a: $(LIBGIT_HIDDEN_EXPORT)
        $(AR) $(ARFLAGS) $@ $^

-contrib/credential/osxkeychain/git-credential-osxkeychain:
contrib/credential/osxkeychain/git-credential-osxkeychain.o
$(LIB_FILE) GIT-LDFLAGS
+contrib/credential/osxkeychain/git-credential-osxkeychain:
contrib/credential/osxkeychain/git-credential-osxkeychain.o
$(LIB_FILE) $(RUST_LIB) GIT-LDFLAGS
        $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) \
-               $(filter %.o,$^) $(LIB_FILE) $(EXTLIBS) -framework
Security -framework CoreFoundation
+               $(filter %.o,$^) $(LIB_FILE) $(RUST_LIB) $(EXTLIBS)
-framework Security -framework CoreFoundation

 contrib/credential/osxkeychain/git-credential-osxkeychain.o:
contrib/credential/osxkeychain/git-credential-osxkeychain.c GIT-CFLAGS
        $(QUIET_LINK)$(CC) -o $@ -c $(dep_args) $(compdb_args)
$(ALL_CFLAGS) $(EXTRA_CPPFLAGS) $<

gitgitgadget-git · 2026-05-08T10:13:03Z

User Koji Nakamaru <koji.nakamaru@gree.net> has been added to the cc: list.

kiranani · 2026-05-08T17:46:52Z

Thank you for the suggestion! This is indeed a much cleaner approach. By wrapping `RUST_LIB` and the rust targets in `ifndef NO_RUST`, we can link `git-credential-osxkeychain` directly against `$(RUST_LIB)` without needing to introduce an intermediate `RUST_LIBS` variable. When `NO_RUST` is defined, `$(RUST_LIB)` evaluates to empty, and Make naturally links it as a pure C binary without any Rust dependencies. To integrate this with the universal build support (`RUST_TARGETS`/`lipo`) introduced in this PR, I have updated the changes to: - Wrap the `RUST_LIB` definition block (which resolves target-specific paths for universal builds) in ifndef `NO_RUST`. - Wrap the entire universal compilation and lipo combining block in ifndef `NO_RUST`. - Remove the `RUST_LIBS` helper variable and use `$(RUST_LIB)` directly in `git-credential-osxkeychain`. On Fri, May 8, 2026 at 3:13 AM gitgitgadget-git[bot] < ***@***.***> wrote:

…

*gitgitgadget-git[bot]* left a comment (git/git#2288) <#2288 (comment)> *Koji Nakamaru* wrote on the Git mailing list ***@***.***> (how to reply to this email <https://gitgitgadget.github.io/reply-to-this> ): On Fri, May 8, 2026 at 11:54 AM Junio C Hamano ***@***.***> wrote:>> "Shardul Natu via GitGitGadget" ***@***.***> writes:>> > From: Shnatu ***@***.***>>> If your name is "Shardul Natu", we'd prefer (not 'require', but> 'prefer') that the patches authored by you also identify with that> name, both on "From:" and "Signed-off-by:"..>> > When Rust is enabled, ensure that the git-credential-osxkeychain> > helper is linked with the necessary Rust libraries.> >> > Introduce the RUST_LIBS variable inside ifndef NO_RUST block> > to hold the Rust library dependency, and use it in the helper's> > build target. This cleanly handles cases where Rust is disabled,> > making it a no-op and avoiding any build failures on systems> > without Cargo.> >> > This addresses reviewer feedback from internal CL 910223487> > by simplifying the variables and avoiding confusing "LINK"> > terminology.> >> > Signed-off-by: Shnatu ***@***.***>> > ---> > Makefile: link osxkeychain helper against Rust>> Thanks. I've added to CC: a few folks who may be more clueful in> the affected area than I am. It somehow feels strange that we have> to have RUST_LIB and RUST_LIBS separately, and apparently with the> new definition the latter is expected to be a superset of the> former, and it is unclear what are the things that should be added> to the latter without getting added to the former.>> > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2288%2Fkiranani%2Fnext-v1> > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2288/kiranani/next-v1> > Pull-Request: #2288> >> > Makefile | 5 +++--> > 1 file changed, 3 insertions(+), 2 deletions(-)> >> > diff --git a/Makefile b/Makefile> > index f86173f93a..a17dca22b1 100644> > --- a/Makefile> > +++ b/Makefile> > @@ -1593,6 +1593,7 @@ ALL_LDFLAGS = $(LDFLAGS) $(LDFLAGS_APPEND)> > ifndef NO_RUST> > BASIC_CFLAGS += -DWITH_RUST> > GITLIBS += $(RUST_LIB)> > +RUST_LIBS = $(RUST_LIB)> > ifeq ($(uname_S),Windows)> > EXTLIBS += -luserenv> > endif> > @@ -4082,9 +4083,9 @@ $(LIBGIT_HIDDEN_EXPORT): $(LIBGIT_PARTIAL_EXPORT)> > contrib/libgit-sys/libgitpub.a: $(LIBGIT_HIDDEN_EXPORT)> > $(AR) $(ARFLAGS) $@ $^> >> > -contrib/credential/osxkeychain/git-credential-osxkeychain: contrib/credential/osxkeychain/git-credential-osxkeychain.o $(LIB_FILE) GIT-LDFLAGS> > +contrib/credential/osxkeychain/git-credential-osxkeychain: contrib/credential/osxkeychain/git-credential-osxkeychain.o $(LIB_FILE) $(RUST_LIBS) GIT-LDFLAGS> > $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) \> > - $(filter %.o,$^) $(LIB_FILE) $(EXTLIBS) -framework Security -framework CoreFoundation> > + $(filter %.o,$^) $(LIB_FILE) $(RUST_LIBS) $(EXTLIBS) -framework Security -framework CoreFoundation> >> > contrib/credential/osxkeychain/git-credential-osxkeychain.o: contrib/credential/osxkeychain/git-credential-osxkeychain.c GIT-CFLAGS> > $(QUIET_LINK)$(CC) -o $@ -c $(dep_args) $(compdb_args) $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) $<> >> > base-commit: 4f69b47 How about simply wrapping the RUST_LIB-related sections in ifndef NO_RUST, as shown below? This way, we can avoid defining RUST_LIBS. diff --git a/Makefile b/Makefile index f86173f93a..daa1691950 100644--- a/Makefile +++ b/Makefile @@ -947,11 +947,13 @@ else RUST_TARGET_DIR = target/release endif +ifndef NO_RUST ifeq ($(uname_S),Windows) RUST_LIB = $(RUST_TARGET_DIR)/gitcore.lib else RUST_LIB = $(RUST_TARGET_DIR)/libgitcore.a endif +endif GITLIBS = common-main.o $(LIB_FILE) EXTLIBS = @@ -3027,11 +3029,13 @@ scalar$X: scalar.o GIT-LDFLAGS $(GITLIBS) $(LIB_FILE): $(LIB_OBJS) $(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^ +ifndef NO_RUST $(RUST_LIB): Cargo.toml $(RUST_SOURCES) $(LIB_FILE) $(QUIET_CARGO)cargo build $(CARGO_ARGS) .PHONY: rust rust: $(RUST_LIB) +endif export DEFAULT_EDITOR DEFAULT_PAGER @@ -4082,9 +4086,9 @@ $(LIBGIT_HIDDEN_EXPORT): $(LIBGIT_PARTIAL_EXPORT) contrib/libgit-sys/libgitpub.a: $(LIBGIT_HIDDEN_EXPORT) $(AR) $(ARFLAGS) $@ $^ -contrib/credential/osxkeychain/git-credential-osxkeychain: contrib/credential/osxkeychain/git-credential-osxkeychain.o $(LIB_FILE) GIT-LDFLAGS +contrib/credential/osxkeychain/git-credential-osxkeychain: contrib/credential/osxkeychain/git-credential-osxkeychain.o $(LIB_FILE) $(RUST_LIB) GIT-LDFLAGS $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) \ - $(filter %.o,$^) $(LIB_FILE) $(EXTLIBS) -framework Security -framework CoreFoundation + $(filter %.o,$^) $(LIB_FILE) $(RUST_LIB) $(EXTLIBS) -framework Security -framework CoreFoundation contrib/credential/osxkeychain/git-credential-osxkeychain.o: contrib/credential/osxkeychain/git-credential-osxkeychain.c GIT-CFLAGS $(QUIET_LINK)$(CC) -o $@ -c $(dep_args) $(compdb_args) $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) $< — Reply to this email directly, view it on GitHub <#2288 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKLJEVXT4YS6K2JYCE3UCKD4ZWXMJAVCNFSM6AAAAACYRCBHB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DIMBVGU4TOMRQGA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

gitgitgadget-git · 2026-05-08T17:51:46Z

Shnatu wrote on the Git mailing list (how to reply to this email):

Thank you for the suggestion! This is indeed a much cleaner approach.

By wrapping `RUST_LIB` and the rust targets in `ifndef NO_RUST`, we can link `git-credential-osxkeychain` directly against `$(RUST_LIB)` without needing to introduce an intermediate `RUST_LIBS` variable. When `NO_RUST` is defined, `$(RUST_LIB)` evaluates to empty, and Make naturally links it as a pure C binary without any Rust dependencies.

To integrate this with the universal build support (`RUST_TARGETS`/`lipo`) introduced in this PR, I have updated the changes to:

- Wrap the `RUST_LIB` definition block (which resolves target-specific paths for universal builds) in ifndef `NO_RUST`.
- Wrap the entire universal compilation and lipo combining block in ifndef `NO_RUST`.
- Remove the `RUST_LIBS` helper variable and use `$(RUST_LIB)` directly in `git-credential-osxkeychain`.

gitgitgadget-git · 2026-05-13T21:28:35Z

Invalid author email in f7d9a4b: "43422294+kiranani@users.noreply.github.com"

gitgitgadget-git · 2026-05-13T21:28:36Z

There is a merge commit in this Pull Request:

f7d9a4b003ad181dec830c3248b358b16407a701

Please rebase the branch and force-push.

KojiNakamaru · 2026-05-21T00:12:17Z

@kiranani You will need to resubmit this for the next iteration.

kiranani · 2026-07-06T22:23:09Z

Sorry if I am mistaken, but as far as I can see, $(GITLIBS) includes common-main.o (and it being .o, not .a, it is always included in the result), and git-credential-osxkeychain.c comes with its own main() function. Using a list of things to link that contains common-main.o does not sound like a right thing to do; in other words, linking too many is just as bad as linking too little.

You are completely right, and I missed that altogether!! In v6, I have reverted Patch 1 back to depending explicitly on $(LIB_FILE) $(RUST_LIB) rather than $(GITLIBS) so that common-main.o is excluded from the link step. To ensure that linking errors in osxkeychain are caught automatically in future CI runs, I have also added a third patch to the series: "contrib: wire up osxkeychain in contrib/Makefile on macOS". This adds a "test" target to contrib/credential/osxkeychain/Makefile and wires it into contrib/Makefile under "all", "test", and "clean" whenever running on macOS (Darwin). Now, when CI runs "make test" with TEST_CONTRIB_TOO=yes on macOS runners, osxkeychain will always be compiled and linked.

…

On Mon, Jul 6, 2026 at 2:03 PM gitgitgadget-git[bot] ***@***.***> wrote: @gitgitgadget-git[bot] commented on this pull request. ________________________________ In Makefile: > @@ -939,6 +939,7 @@ TEST_SHELL_PATH = $(SHELL_PATH) Junio C Hamano wrote on the Git mailing list (how to reply to this email): "Shardul Natu via GitGitGadget" ***@***.***> writes: > From: Shardul Natu ***@***.***> > > When Rust is enabled, the git-credential-osxkeychain helper depends on > Rust symbols compiled into $(RUST_LIB). While commit 522ea8e > ("osxkeychain: fix build with Rust") updated the linker command line to > use $(LIBS), it omitted $(RUST_LIB) from the target prerequisite list. > Without this prerequisite, running a parallel build ("make -j") from a > clean working tree can fail because Make does not know to invoke Cargo > to build libgitcore.a before linking git-credential-osxkeychain. > > All other core Git targets that link $(LIBS) already depend on > $(GITLIBS), which bundles common-main.o, $(LIB_FILE), and $(RUST_LIB) > when Rust is enabled. Add $(GITLIBS) as a prerequisite dependency to the > git-credential-osxkeychain target to make it consistent with the rest of > the codebase. I do not work with macOS but doesn't this change introduce a build/link failure? Sorry if I am mistaken, but as far as I can see, $(GITLIBS) includes common-main.o (and it being .o, not .a, it is always included in the result), and git-credential-osxkeychain.c comes with its own main() function. Using a list of things to link that contains common-main.o does not sound like a right thing to do; in other words, linking too many is just as bad as linking too little. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

kiranani · 2026-07-06T22:50:53Z

/submit

gitgitgadget-git · 2026-07-06T22:52:38Z

Submitted as pull.2288.v6.git.git.1783378333.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-git-2288/kiranani/next-v6

To fetch this version to local tag pr-git-2288/kiranani/next-v6:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-git-2288/kiranani/next-v6

WARNING: kiranani has no public email address set on GitHub; GitGitGadget needs an email address to Cc: you on your contribution, so that you receive any feedback on the Git mailing list. Go to https://github.com/settings/profile to make your preferred email public to let GitGitGadget know which email address to use.

dscho · 2026-07-07T06:26:05Z

Sorry if I am mistaken, but as far as I can see, $(GITLIBS) includes common-main.o (and it being .o, not .a, it is always included in the result), and git-credential-osxkeychain.c comes with its own main() function. Using a list of things to link that contains common-main.o does not sound like a right thing to do; in other words, linking too many is just as bad as linking too little.

You are completely right, and I missed that altogether!! In v6, I have reverted Patch 1 back to depending explicitly on $(LIB_FILE) $(RUST_LIB) rather than $(GITLIBS) so that common-main.o is excluded from the link step. To ensure that linking errors in osxkeychain are caught automatically in future CI runs, I have also added a third patch to the series: "contrib: wire up osxkeychain in contrib/Makefile on macOS". This adds a "test" target to contrib/credential/osxkeychain/Makefile and wires it into contrib/Makefile under "all", "test", and "clean" whenever running on macOS (Darwin). Now, when CI runs "make test" with TEST_CONTRIB_TOO=yes on macOS runners, osxkeychain will always be compiled and linked.
[…]

@kiranani contrary to your expectation, this email reached only this PR, and not the Git mailing list, let alone Junio. You will need to follow the instructions provided in every PR comment that mirrors an email from the Git mailing list, to reply to the email itself, not to the PR comment. In this particular instance, you will need to re-reply to this email (which was helpfully linked under the label "on the Git mailing list" in the PR comment).

I know that things are inconvenient in the Git project, that's why I wrote GitGitGadget, but it can only go so far, and you will have to accommodate for the Git maintainer's insistence on using a mailing list for running the project.

gitgitgadget-git · 2026-07-07T16:33:00Z

The pull request has 700 commits. The max allowed is 30. Please split the patch series into multiple pull requests. Also consider squashing related commits.

gitgitgadget-git · 2026-07-07T16:33:02Z

There are merge commits in this Pull Request:

d3d6ef5197f72271e7baac02a8a46856f6d761ac
fb95f091ccdd9122a9dcb7831393204563ddede7
7a70817efa3735665c323d2a970584bff018b33d
7339897c7cd7bc48e037247725cf7a460ceeae71
eaeac8ef83491e77f95ff77760b5e67993f37d8d
66d5323bbc44eb35dc937110f5cd0e9539e24623
ad8abe7a5a178e340f8d36535f9667a4af368033
6b423ab8ba2ea005e6f94f8fd8aeeb0d1243e555
bb1d6268023a5bb05d672018569d0c9aed159d0f
ed6aa0e448037b01eca069771b981a4e1637ef0a
0fbf48f4d677e51545ea17db7c7063932ee42087
779546e6a3b2a8118685b3f23ce09e180fb45496
75896fcff766bb9e05db46f0a273f96d75e1f522
2246c42fe06977a9e20382c94a40e61af4c164a1

Please rebase the branch and force-push.

When Rust is enabled, the git-credential-osxkeychain helper depends on Rust symbols compiled into $(RUST_LIB). While commit 522ea8e ("osxkeychain: fix build with Rust") updated the linker command line to use $(LIBS), it omitted $(RUST_LIB) from the target prerequisite list. Without this prerequisite, running a parallel build ("make -j") from a clean working tree can fail because Make does not know to invoke Cargo to build libgitcore.a before linking git-credential-osxkeychain. Note that we depend explicitly on $(LIB_FILE) and $(RUST_LIB) rather than $(GITLIBS). Unlike standard Git builtins and programs like scalar (which define cmd_main() and rely on common-main.o to supply main()), git-credential-osxkeychain.c defines its own standalone int main(). If $(GITLIBS) were used, $(filter %.o,$^) in the link recipe would match both git-credential-osxkeychain.o and common-main.o, causing a duplicate symbol linking error for _main on macOS. Additionally, wrap the definitions of $(RUST_LIB) and the "rust" build target in "ifndef NO_RUST". This ensures that when NO_RUST=1 is specified, $(RUST_LIB) evaluates to empty, making the Rust dependency a clean no-op without needing intermediate variables. Signed-off-by: Shardul Natu <snatu@google.com>

On macOS, Universal Binaries contain native executable code for multiple architectures (such as Intel x86_64 and Apple Silicon arm64) bundled into a single file. This is standard practice for macOS distribution and CI packaging (such as internal distribution packages or tooling like Burrito/Homebrew), allowing a single build artifact to run natively across all Macs without Rosetta emulation or maintaining separate packages. When building Git C code for multiple architectures on macOS, the Apple toolchain (clang) natively supports universal builds via CFLAGS/LDFLAGS. When "-arch x86_64 -arch arm64" is passed, clang automatically compiles and links universal binaries for all C object files and executables out of the box. Cargo and rustc, however, do not support multiple "-arch" flags or emitting universal binaries in a single invocation. Instead, Cargo requires invoking each target triple independently (e.g., passing "--target x86_64-apple-darwin" and "--target aarch64-apple-darwin"). To bridge this gap when Rust is enabled: 1. Allow specifying space-separated target triples in RUST_TARGETS. 2. Introduce declarative pattern rules (target/%/...) to compile each target-specific library slice via Cargo. 3. On macOS, if multiple targets are specified, use "lipo" (part of the mandatory Xcode Command Line Tools) to combine the resulting static libraries into target/release/libgitcore.a. Once $(RUST_LIB) is compiled into a universal static archive, the standard C linker seamlessly links it with the C object files to produce universal Git executables. Signed-off-by: Shardul Natu <snatu@google.com>

kiranani · 2026-07-07T17:01:17Z

/submit

gitgitgadget-git · 2026-07-07T17:03:16Z

Submitted as pull.2288.v7.git.git.1783443745.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-git-2288/kiranani/next-v7

To fetch this version to local tag pr-git-2288/kiranani/next-v7:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-git-2288/kiranani/next-v7

WARNING: kiranani has no public email address set on GitHub; GitGitGadget needs an email address to Cc: you on your contribution, so that you receive any feedback on the Git mailing list. Go to https://github.com/settings/profile to make your preferred email public to let GitGitGadget know which email address to use.

gitgitgadget-git · 2026-07-07T18:10:45Z

There was a status update in the "Cooking" section about the branch sn/osxkeychain-rust-universal on the Git mailing list:

The build system has been updated to support building universal macOS
binaries when 'Rust' is enabled, by compiling separate static archives
for each target triple listed in 'RUST_TARGETS' and combining them
using the macOS 'lipo' tool. Additionally, the 'git-credential-
osxkeychain' helper has been updated to link against '$(RUST_LIB)'
when 'Rust' is enabled.

Needs review.
source: <pull.2288.v6.git.git.1783378333.gitgitgadget@gmail.com>

gitgitgadget-git · 2026-07-07T20:10:49Z

Junio C Hamano wrote on the Git mailing list (how to reply to this email):

"Shardul Natu via GitGitGadget" <gitgitgadget@gmail.com> writes:

> This series improves macOS build reliability, automated CI verification, and
> distribution support when Rust is enabled in the Git build system. It
> addresses three distinct challenges: a parallel build race condition in
> git-credential-osxkeychain, support for macOS Universal Binaries
> (multi-architecture distribution), and missing automated CI test wiring for
> macOS contrib utilities.
> ...
> Range-diff vs v6:
>
>  1:  0d215139406 = 1:  8f2bd4b14a3 Makefile: add $(RUST_LIB) prerequisite to osxkeychain
>  2:  21dedb91f09 = 2:  a999be69392 Makefile: support universal macOS builds via RUST_TARGETS
>  3:  8455e449f38 = 3:  32af2c51a89 contrib: wire up osxkeychain in contrib/Makefile on macOS

Did an automation go wrong, or something?  I have v6 queued already
so I'd skip this round that is identical for now.

When running "make test" with TEST_CONTRIB_TOO=yes (which is default in macOS CI workflows), $(MAKE) -C contrib/ test is invoked. However, contrib/Makefile only invoked tests for diff-highlight and subtree, meaning git-credential-osxkeychain was never built or verified during standard CI test runs. Add a "test" target to contrib/credential/osxkeychain/Makefile that depends on building git-credential-osxkeychain. Additionally, wire up credential/osxkeychain in contrib/Makefile under "all", "test", and "clean" whenever running on macOS (Darwin). This ensures that running "make test" or "make all" in contrib on macOS automatically builds and links git-credential-osxkeychain, preventing future build or symbol linking regressions from slipping through CI. Signed-off-by: Shardul Natu <snatu@google.com>

kiranani · 2026-07-08T03:20:14Z

/submit

gitgitgadget-git · 2026-07-08T03:21:35Z

Submitted as pull.2288.v8.git.git.1783480879.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-git-2288/kiranani/next-v8

To fetch this version to local tag pr-git-2288/kiranani/next-v8:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-git-2288/kiranani/next-v8

WARNING: kiranani has no public email address set on GitHub; GitGitGadget needs an email address to Cc: you on your contribution, so that you receive any feedback on the Git mailing list. Go to https://github.com/settings/profile to make your preferred email public to let GitGitGadget know which email address to use.

gitgitgadget-git · 2026-07-08T20:50:49Z

Junio C Hamano wrote on the Git mailing list (how to reply to this email):

"Shardul Natu via GitGitGadget" <gitgitgadget@gmail.com> writes:

> Changes since v7:
>
>  * Added inclusion of ../config.mak.uname to the top of contrib/Makefile in
>    the canonical order. This guarantees that $(uname_S) is correctly defined
>    on the shell, preventing the OS_CONTRIB additions from being silently
>    ignored.

This round of patches looked good to me (even though I am not a
macOS user, so my review only goes on the surface without actual
testing).

gitgitgadget-git · 2026-07-08T22:05:19Z

This patch series is no longer integrated into seen.

gitgitgadget-git · 2026-07-09T21:55:42Z

This patch series was integrated into seen via 1dafc41.

gitgitgadget-git · 2026-07-10T01:26:27Z

There was a status update in the "Cooking" section about the branch sn/osxkeychain-rust-universal on the Git mailing list:

The build system has been updated to support building universal macOS
binaries when 'Rust' is enabled, by compiling separate static archives
for each target triple listed in 'RUST_TARGETS' and combining them
using the macOS 'lipo' tool. The 'git-credential-osxkeychain' helper
has been updated to link against '$(RUST_LIB)' when 'Rust' is enabled.

Will merge to 'next'?
cf. <xmqq4ii9teym.fsf@gitster.g>
source: <pull.2288.v8.git.git.1783480879.gitgitgadget@gmail.com>

gitgitgadget-git · 2026-07-10T17:03:00Z

This patch series was integrated into next via fe82b5d.

gitgitgadget-git · 2026-07-13T07:53:59Z

There was a status update in the "Cooking" section about the branch sn/osxkeychain-rust-universal on the Git mailing list:

The build system has been updated to support building universal macOS
binaries when 'Rust' is enabled, by compiling separate static archives
for each target triple listed in 'RUST_TARGETS' and combining them
using the macOS 'lipo' tool. The 'git-credential-osxkeychain' helper
has been updated to link against '$(RUST_LIB)' when 'Rust' is enabled.

Will merge to 'master'.
cf. <xmqq4ii9teym.fsf@gitster.g>
source: <pull.2288.v8.git.git.1783480879.gitgitgadget@gmail.com>

gitgitgadget-git · 2026-07-15T00:02:06Z

There was a status update in the "Cooking" section about the branch sn/osxkeychain-rust-universal on the Git mailing list:

The build system has been updated to support building universal macOS
binaries when 'Rust' is enabled, by compiling separate static archives
for each target triple listed in 'RUST_TARGETS' and combining them
using the macOS 'lipo' tool.  The 'git-credential-osxkeychain' helper
has been updated to link against '$(RUST_LIB)' when 'Rust' is enabled.

Will merge to 'master'.
cf. <xmqq4ii9teym.fsf@gitster.g>
source: <pull.2288.v8.git.git.1783480879.gitgitgadget@gmail.com>

github-project-automation Bot added this to Op-Amp Frequency Response and Applications Suite May 5, 2026

github-project-automation Bot moved this to Todo in Op-Amp Frequency Response and Applications Suite May 5, 2026

gitgitgadget-git Bot added the new user label May 5, 2026

kiranani force-pushed the next branch from 57046d2 to fde105f Compare May 6, 2026 23:54

kiranani force-pushed the next branch from fde105f to 5fddcfe Compare May 6, 2026 23:59

kiranani force-pushed the next branch 2 times, most recently from a9ce4c1 to 4c8e9ab Compare May 8, 2026 17:37

kiranani force-pushed the next branch from f7d9a4b to 7491bbc Compare May 13, 2026 22:11

kiranani force-pushed the next branch 2 times, most recently from 0402e1b to 6b817cd Compare June 23, 2026 04:42

kiranani force-pushed the next branch from 6c51f0c to 8455e44 Compare July 6, 2026 22:14

gitster force-pushed the next branch from c42f454 to 00534a2 Compare July 7, 2026 02:34

Shardul Natu added 2 commits July 7, 2026 09:38

kiranani force-pushed the next branch from 810eabd to 32af2c5 Compare July 7, 2026 16:39

gitgitgadget-git Bot reviewed Jul 8, 2026

View reviewed changes

Comment thread contrib/Makefile

kiranani force-pushed the next branch from 32af2c5 to 5659709 Compare July 8, 2026 03:12

gitgitgadget-git Bot removed the seen label Jul 8, 2026

gitgitgadget-git Bot added the seen label Jul 9, 2026

gitgitgadget-git Bot added the next label Jul 10, 2026

Uh oh!

Conversation

kiranani commented May 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why This Series is Needed

Overview of Patches

Uh oh!

gitgitgadget-git Bot commented May 5, 2026

Welcome to GitGitGadget

Contributing the patches

Need help?

Uh oh!

dscho commented May 5, 2026

Uh oh!

gitgitgadget-git Bot commented May 5, 2026

Uh oh!

kiranani commented May 5, 2026

Uh oh!

gitgitgadget-git Bot commented May 5, 2026

Uh oh!

gitgitgadget-git Bot commented May 5, 2026

Uh oh!

gitgitgadget-git Bot commented May 5, 2026

Uh oh!

gitgitgadget-git Bot commented May 6, 2026

Uh oh!

kiranani commented May 6, 2026

Uh oh!

dscho commented May 7, 2026

Uh oh!

gitgitgadget-git Bot commented May 7, 2026

Uh oh!

gitgitgadget-git Bot commented May 7, 2026

Uh oh!

gitgitgadget-git Bot commented May 8, 2026

Uh oh!

gitgitgadget-git Bot commented May 8, 2026

Uh oh!

gitgitgadget-git Bot commented May 8, 2026

Uh oh!

kiranani commented May 8, 2026 via email

Uh oh!

gitgitgadget-git Bot commented May 8, 2026

Uh oh!

gitgitgadget-git Bot commented May 13, 2026

Uh oh!

gitgitgadget-git Bot commented May 13, 2026

Uh oh!

KojiNakamaru commented May 21, 2026

Uh oh!

kiranani commented Jul 6, 2026 via email

Uh oh!

kiranani commented Jul 6, 2026

Uh oh!

gitgitgadget-git Bot commented Jul 6, 2026

Uh oh!

dscho commented Jul 7, 2026

Uh oh!

gitgitgadget-git Bot commented Jul 7, 2026

Uh oh!

gitgitgadget-git Bot commented Jul 7, 2026

Uh oh!

kiranani commented Jul 7, 2026

Uh oh!

gitgitgadget-git Bot commented Jul 7, 2026

Uh oh!

gitgitgadget-git Bot commented Jul 7, 2026

Uh oh!

gitgitgadget-git Bot commented Jul 7, 2026

Uh oh!

Uh oh!

kiranani commented Jul 8, 2026

Uh oh!

gitgitgadget-git Bot commented Jul 8, 2026

Uh oh!

gitgitgadget-git Bot commented Jul 8, 2026

Uh oh!

gitgitgadget-git Bot commented Jul 8, 2026

Uh oh!

gitgitgadget-git Bot commented Jul 9, 2026

kiranani commented May 5, 2026 •

edited

Loading