* Re: [PATCH v4 3/4] transport-helper: call do_take_over() in connect_helper
From: Linus Arver @ 2024-01-12 7:56 UTC (permalink / raw)
To: Jiang Xin, Git List, Junio C Hamano; +Cc: Jiang Xin
In-Reply-To: <af8fd2a4eb8783be4a62973bfd2135da4568570e.1702562879.git.zhiyou.jx@alibaba-inc.com>
Jiang Xin <worldhello.net@gmail.com> writes:
> From: Jiang Xin <zhiyou.jx@alibaba-inc.com>
>
> After successfully connecting to the smart transport by calling
> process_connect_service() in connect_helper(), run do_take_over() to
> replace the old vtable with a new one which has methods ready for the
> smart transport connection.
>
>
> The connect_helper() function is used as the connect method of the
> vtable in "transport-helper.c", and it is called by transport_connect()
> in "transport.c" to setup a connection. The only place that we call
> transport_connect() so far is in "builtin/archive.c". Without running
> do_take_over(), it may fail to call transport_disconnect() in
> run_remote_archiver() of "builtin/archive.c". This is because for a
> stateless connection or a service like "git-upload-pack-archive", the
There is "git-upload-pack" and "git-upload-archive". Which one did you
mean here? Or did you mean both?
> remote helper may receive a SIGPIPE signal and exit early. To have a
> graceful disconnect method by calling do_take_over() will solve this
> issue.
Are you saying that this patch fixes an existing bug? That is, is this
patch independent of the first patch (transport-helper: no connection
restriction in connect_helper) in this series?
> The subsequent commit will introduce remote archive over a stateless-rpc
> connection.
Does the next commit depend on this patch? If not, I think you can drop
this paragraph.
> Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
> ---
> transport-helper.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/transport-helper.c b/transport-helper.c
> index 51088cc03a..3b036ae1ca 100644
> --- a/transport-helper.c
> +++ b/transport-helper.c
> @@ -672,6 +672,8 @@ static int connect_helper(struct transport *transport, const char *name,
>
> fd[0] = data->helper->out;
> fd[1] = data->helper->in;
> +
> + do_take_over(transport);
> return 0;
> }
>
> --
> 2.41.0.232.g2f6f0bca4f.agit.8.0.4.dev
^ permalink raw reply
* Re: [PATCH 1/2] t1401: generalize reference locking
From: Patrick Steinhardt @ 2024-01-12 7:45 UTC (permalink / raw)
To: Jeff King; +Cc: Justin Tobler via GitGitGadget, git, Justin Tobler
In-Reply-To: <20240112070142.GD618729@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1943 bytes --]
On Fri, Jan 12, 2024 at 02:01:42AM -0500, Jeff King wrote:
> On Thu, Jan 11, 2024 at 12:08:44PM +0100, Patrick Steinhardt wrote:
>
> > > (note that you get a different error message if the refs are packed,
> > > since there we can notice the d/f conflict manually).
> >
> > If all we care for is the exit code then this would work for the
> > reftable backend, too:
> >
> > ```
> > $ git init --ref-format=reftable repo
> > Initialized empty Git repository in /tmp/repo/.git/
> > $ cd repo/
> > $ git commit --allow-empty --message message
> > [main (root-commit) c2512d3] x
> > $ git symbolic-ref refs/heads refs/heads/foo
> > $ echo $?
> > 1
> > ```
>
> Yep, exactly. That should work for both and cover what the test was
> originally trying to do.
>
> > A bit unfortunate that there is no proper error message in that case,
> > but that is a different topic.
>
> Yeah, I would call that an outright bug. It does not have to be part of
> this patch, but is worth fixing (and testing). I suspect it's not going
> to be the only place with this problem. Most of the files-backend ref
> code is very happy to spew to stdout using error(), but the reftable
> code, having been written from a more lib-conscious perspective,
> probably doesn't.
Yup, I've already fixed this bug in the reftable backend.
> The obvious quick fix is to sprinkle more error() into the reftable
> code. But in the longer term, I think the right direction is that the
> ref code should accept an error strbuf or similar mechanism to propagate
> human-readable error test to the caller.
Agreed, I think it's good that the reftable library itself does not
print error messages. In this particular case we are already able to
provide a proper error message due to the error code that the library
returns. But there are certainly going to be other cases where it might
make sense to pass in an error strbuf.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 1/4] transport-helper: no connection restriction in connect_helper
From: Linus Arver @ 2024-01-12 7:42 UTC (permalink / raw)
To: Jiang Xin, Git List, Junio C Hamano; +Cc: Jiang Xin
In-Reply-To: <d343585cb5e696f521c2ee1dd6c0f0c2d86de113.1702562879.git.zhiyou.jx@alibaba-inc.com>
Jiang Xin <worldhello.net@gmail.com> writes:
> From: Jiang Xin <zhiyou.jx@alibaba-inc.com>
>
> When commit b236752a (Support remote archive from all smart transports,
> 2009-12-09) added "remote archive" support for "smart transports", it
> was for transport that supports the ".connect" method. The
> "connect_helper()" function protected itself from getting called for a
> transport without the method before calling process_connect_service(),
OK.
> which did not work with such a transport.
How about 'which only worked with the ".connect" method.' ?
>
> Later, commit edc9caf7 (transport-helper: introduce stateless-connect,
> 2018-03-15) added a way for a transport without the ".connect" method
> to establish a "stateless" connection in protocol-v2, which
s/which/where
> process_connect_service() was taught to handle the "stateless"
> connection,
I think using 'the ".stateless_connect" method' is more consistent with
the rest of this text.
> making the old safety valve in its caller that insisted
> that ".connect" method must be defined too strict, and forgot to loosen
> it.
I think just "...making the old protection too strict. But edc9caf7
forgot to adjust this protection accordingly." is simpler to read.
> Remove the restriction in the "connect_helper()" function and give the
> function "process_connect_service()" the opportunity to establish a
> connection using ".connect" or ".stateless_connect" for protocol v2. So
> we can connect with a stateless-rpc and do something useful. E.g., in a
> later commit, implements remote archive for a repository over HTTP
> protocol.
>
> Helped-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
> ---
> transport-helper.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/transport-helper.c b/transport-helper.c
> index 49811ef176..2e127d24a5 100644
> --- a/transport-helper.c
> +++ b/transport-helper.c
> @@ -662,8 +662,6 @@ static int connect_helper(struct transport *transport, const char *name,
>
> /* Get_helper so connect is inited. */
> get_helper(transport);
> - if (!data->connect)
> - die(_("operation not supported by protocol"));
Should we still terminate early here if both data->connect and
data->stateless_connect are not truthy? It would save a few CPU cycles,
but even better, remain true to the the original intent of the code.
Maybe there was a really good reason to terminate early here that we're
not aware of?
But also, what about the case where both are enabled? Should we print an
error message? (Maybe this concern is outside the scope of this series?)
> if (!process_connect_service(transport, name, exec))
> die(_("can't connect to subservice %s"), name);
> --
> 2.41.0.232.g2f6f0bca4f.agit.8.0.4.dev
^ permalink raw reply
* Re: [PATCH] strvec: use correct member name in comments
From: Jeff King @ 2024-01-12 7:41 UTC (permalink / raw)
To: Linus Arver via GitGitGadget; +Cc: git, Linus Arver
In-Reply-To: <pull.1640.git.1705043195997.gitgitgadget@gmail.com>
On Fri, Jan 12, 2024 at 07:06:35AM +0000, Linus Arver via GitGitGadget wrote:
> From: Linus Arver <linusa@google.com>
>
> In d70a9eb611 (strvec: rename struct fields, 2020-07-28), we renamed the
> "argv" member to "v". In the same patch we also did the following rename
> in strvec.c:
>
> -void strvec_pushv(struct strvec *array, const char **argv)
> +void strvec_pushv(struct strvec *array, const char **items)
>
> and it appears that this s/argv/items operation was erroneously applied
> to strvec.h.
>
> Rename "items" to "v".
Good catch. The source of the problem is that the patch originally used
"items" in the struct, too, but after review we settled on the more
concise "v". I'd almost certainly have then flipped the name in the
struct definition and relied on the compiler to help find the fallout.
But of course it doesn't look in comments. :)
As you note, we still call use "items" for the vector passed in to
pushv. I think that is OK, and there is no real need to use the terse
"v" there (it is also purely internal; the declaration in strvec.h does
not name it at all).
So this patch looks great to me. Thanks!
-Peff
^ permalink raw reply
* Re: [RFC PATCH] `log --merge` also for rebase/cherry pick/revert
From: Johannes Sixt @ 2024-01-12 7:35 UTC (permalink / raw)
To: Michael Lohmann; +Cc: phillip.wood123, git
In-Reply-To: <20240111233311.64734-1-mi.al.lohmann@gmail.com>
Am 12.01.24 um 00:33 schrieb Michael Lohmann:
> This extends the functionality of `git log --merge` to also work with
> conflicts for rebase, cherry pick and revert.
>
> Signed-off-by: Michael Lohmann <mi.al.lohmann@gmail.com>
> ---
> Hi everybody!
>
> When Phillip Wood gave me some nice hints on his workflow concerning
> conflicts [1] (we discussed if `--show-current-patch` would make sense
> for cherry pick/revert). When I learned about `git log --merge` I was a
> bit sad to discover that those do not exist for rebase/revert/cherry
> pick since they look really valuable for getting an understanding on
> what was changed. It is basically the counterpart to
> `git show ${ACTION}_HEAD` for understanding the source of the conflict.
>
> I am curious if also other people would be interested in having an easy
> way to get a log of only the relevant commits touching conflicting files
> for said actions.
>
> With this patch I think the functionality is there, just hijacking the
> `--merge` code - maybe an alias like `git log --conflict` or similar
> might be more descriptive now?
>
> What do you think about this idea? (Or am I maybe missing an easy way to
> achieve it with the existing code as well?)
Ha! Very nice patch. For comparison, have a look at my patch to achieve
the same that I never submitted (in particular, the author date):
https://github.com/j6t/git/commit/2327526213bc2fc3c109c1d8b4b0d95032346ff0
This implementation is more complete than mine. I like it.
>
> Michael
>
>
> [1] https://lore.kernel.org/git/cfba7098-3c23-4a81-933c-b7fefdedec8a@gmail.com/
>
> revision.c | 22 ++++++++++++++++++----
> 1 file changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/revision.c b/revision.c
> index 2424c9bd67..2e5c00dabd 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -1961,23 +1961,37 @@ static void add_pending_commit_list(struct rev_info *revs,
> }
> }
>
> +static char* get_action_head_name(struct object_id* oid)
> +{
> + if (!repo_get_oid(the_repository, "MERGE_HEAD", oid)) {
> + return "MERGE_HEAD";
> + } else if (!repo_get_oid(the_repository, "REBASE_HEAD", oid)) {
> + return "REBASE_HEAD";
> + } else if (!repo_get_oid(the_repository, "CHERRY_PICK_HEAD", oid)) {
> + return "CHERRY_PICK_HEAD";
> + } else if (!repo_get_oid(the_repository, "REVERT_HEAD", oid)) {
> + return "REVERT_HEAD";
> + } else
> + die("--merge without MERGE_HEAD, REBASE_HEAD, CHERRY_PICK_HEAD or REVERT_HEAD?");
> +}
> +
> static void prepare_show_merge(struct rev_info *revs)
> {
> struct commit_list *bases;
> struct commit *head, *other;
> struct object_id oid;
> const char **prune = NULL;
> + const char *action_head_name;
> int i, prune_num = 1; /* counting terminating NULL */
> struct index_state *istate = revs->repo->index;
>
> if (repo_get_oid(the_repository, "HEAD", &oid))
> die("--merge without HEAD?");
> head = lookup_commit_or_die(&oid, "HEAD");
> - if (repo_get_oid(the_repository, "MERGE_HEAD", &oid))
> - die("--merge without MERGE_HEAD?");
> - other = lookup_commit_or_die(&oid, "MERGE_HEAD");
> + action_head_name = get_action_head_name(&oid);
> + other = lookup_commit_or_die(&oid, action_head_name);
> add_pending_object(revs, &head->object, "HEAD");
> - add_pending_object(revs, &other->object, "MERGE_HEAD");
> + add_pending_object(revs, &other->object, action_head_name);
> bases = repo_get_merge_bases(the_repository, head, other);
> add_rev_cmdline_list(revs, bases, REV_CMD_MERGE_BASE, UNINTERESTING | BOTTOM);
> add_pending_commit_list(revs, bases, UNINTERESTING | BOTTOM);
^ permalink raw reply
* Re: Help: Trying to setup triangular workflow
From: Jeff King @ 2024-01-12 7:31 UTC (permalink / raw)
To: Matthew B. Gray; +Cc: git
In-Reply-To: <b59c59f6-29e1-4d67-bace-13adcc108454@app.fastmail.com>
On Fri, Jan 12, 2024 at 03:23:58PM +1300, Matthew B. Gray wrote:
> Here's what I get from running the documented example:
>
> λ git config push.default current
> λ git config remote.pushdefault myfork
> λ git switch -c mybranch origin/main
> λ git push
> * [new branch] mybranch -> mybranch
> branch 'mybranch' set up to track 'myfork/mybranch'.
This push step is rewriting your upstream config. Do you have
push.autoSetupRemote configured? In general you wouldn't want that for a
triangular flow.
Though I think it also is only supposed to kick in if there is no
tracking configured already. Why did the "git switch" invocation not set
up tracking itself? When I run those commands it does. Do you have
branch.autoSetupMerge turned off in your config?
-Peff
^ permalink raw reply
* Re: [PATCH v3] builtin/revert.c: refactor using an enum for cmd-action
From: Jeff King @ 2024-01-12 7:24 UTC (permalink / raw)
To: Michael Lohmann; +Cc: gitster, git, phillip.wood123, phillip.wood, wanja.hentze
In-Reply-To: <20240111200627.64199-1-mi.al.lohmann@gmail.com>
On Thu, Jan 11, 2024 at 09:06:27PM +0100, Michael Lohmann wrote:
> > I agree with you why NONE is called as such. If "revert" does not
> > take "--start" (I do not remember offhand), I would think it would
> > be better to follow suit.
> My point was that yes, it might be in sync with what the user passes in
> as arguments, but when I followed the code and saw lots of references to
> ACTION_NONE I was puzzled, since my intuition of that name was that
> _no action_ should be taken (which did not make sense to me).
Just my two cents as an observer who is very familiar with the idioms of
Git's codebase: it's common for us to use NONE here to mean "an action
has not been selected", which the code then translates to a default
action. So that's what I would have chosen.
But your way of seeing it also makes sense to me. I think I just find
the "START" name jarring because we do not use that word elsewhere to
describe the action. What if you called it ACTION_DEFAULT? Then it is
both the "default" value we give it, and also the default action (which
is not otherwise named in the code).
As far as the enum vs char thing, I do not have a strong opinion (though
I do tend to like enums myself). Here are a few minor style comments
(again that are idiomatic for our code base):
> +enum action {
> + ACTION_START = 0,
> + ACTION_CONTINUE,
> + ACTION_SKIP,
> + ACTION_ABORT,
> + ACTION_QUIT,
> +};
Explicitly setting ACTION_START to 0 is good (even though it is not
strictly necessary) because it makes it clear that we expect to use its
truthiness later. But later...
> @@ -183,9 +189,7 @@ static int run_sequencer(int argc, const char **argv, const char *prefix,
> "--edit", opts->edit > 0,
> NULL);
>
> - if (cmd) {
> - opts->revs = NULL;
> - } else {
> + if (cmd == ACTION_START) {
> struct setup_revision_opt s_r_opt;
> opts->revs = xmalloc(sizeof(*opts->revs));
> repo_init_revisions(the_repository, opts->revs, NULL);
> @@ -198,6 +202,8 @@ static int run_sequencer(int argc, const char **argv, const char *prefix,
> memset(&s_r_opt, 0, sizeof(s_r_opt));
> s_r_opt.assume_dashdash = 1;
> argc = setup_revisions(argc, argv, opts->revs, &s_r_opt);
> + } else {
> + opts->revs = NULL;
We do not take advantage of that. It is still OK to do "if (cmd)" with
the enum, and that's what I'd usually expect in our code base. There is
no need for this hunk at all (which also switches the order of the
conditional, which just seems like churn to me).
> @@ -33,6 +41,17 @@ static const char * const cherry_pick_usage[] = {
> NULL
> };
>
> +static char* get_cmd_optionname(enum action cmd)
From CodingGuidelines:
When declaring pointers, the star sides with the variable name, i.e.
"char *string", not "char* string" or "char * string". This makes it
easier to understand code like "char *string, c;".
(Yes, I know there are arguments for the other way, too; but consistency
is the most important thing, I think).
> +{
> + switch (cmd) {
> + case ACTION_CONTINUE: return "--continue";
> + case ACTION_SKIP: return "--skip";
> + case ACTION_ABORT: return "--abort";
> + case ACTION_QUIT: return "--quit";
> + case ACTION_START: BUG("no commandline flag for ACTION_START");
> + }
> +}
I find this perfectly readable, and is likely the way I'd write it in a
personal project. But in this project I find we tend to stick to more
conventional formatting, like:
switch (cmd) {
case ACTION_CONTINUE:
return "--continue";
case ACTION_SKIP:
return "--skip";
...and so on...
> @@ -144,20 +163,8 @@ static int run_sequencer(int argc, const char **argv, const char *prefix,
> }
>
> /* Check for incompatible command line arguments */
> - if (cmd) {
> - char *this_operation;
> - if (cmd == 'q')
> - this_operation = "--quit";
> - else if (cmd == 'c')
> - this_operation = "--continue";
> - else if (cmd == 's')
> - this_operation = "--skip";
> - else {
> - assert(cmd == 'a');
> - this_operation = "--abort";
> - }
> -
> - verify_opt_compatible(me, this_operation,
> + if (cmd != ACTION_START)
Likewise here I'd probably leave this as "if (cmd)".
> [...]
Everything else looked pretty good to me.
-Peff
^ permalink raw reply
* [PATCH] strvec: use correct member name in comments
From: Linus Arver via GitGitGadget @ 2024-01-12 7:06 UTC (permalink / raw)
To: git; +Cc: Linus Arver, Linus Arver
From: Linus Arver <linusa@google.com>
In d70a9eb611 (strvec: rename struct fields, 2020-07-28), we renamed the
"argv" member to "v". In the same patch we also did the following rename
in strvec.c:
-void strvec_pushv(struct strvec *array, const char **argv)
+void strvec_pushv(struct strvec *array, const char **items)
and it appears that this s/argv/items operation was erroneously applied
to strvec.h.
Rename "items" to "v".
Signed-off-by: Linus Arver <linusa@google.com>
---
strvec: use correct member name in comments
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1640%2Flistx%2Ffix-strvec-typos-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1640/listx/fix-strvec-typos-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1640
strvec.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/strvec.h b/strvec.h
index 9f55c8766ba..4715d3e51f8 100644
--- a/strvec.h
+++ b/strvec.h
@@ -4,8 +4,8 @@
/**
* The strvec API allows one to dynamically build and store
* NULL-terminated arrays of strings. A strvec maintains the invariant that the
- * `items` member always points to a non-NULL array, and that the array is
- * always NULL-terminated at the element pointed to by `items[nr]`. This
+ * `v` member always points to a non-NULL array, and that the array is
+ * always NULL-terminated at the element pointed to by `v[nr]`. This
* makes the result suitable for passing to functions expecting to receive
* argv from main().
*
@@ -22,7 +22,7 @@ extern const char *empty_strvec[];
/**
* A single array. This should be initialized by assignment from
- * `STRVEC_INIT`, or by calling `strvec_init`. The `items`
+ * `STRVEC_INIT`, or by calling `strvec_init`. The `v`
* member contains the actual array; the `nr` member contains the
* number of elements in the array, not including the terminating
* NULL.
@@ -80,7 +80,7 @@ void strvec_split(struct strvec *, const char *);
void strvec_clear(struct strvec *);
/**
- * Disconnect the `items` member from the `strvec` struct and
+ * Disconnect the `v` member from the `strvec` struct and
* return it. The caller is responsible for freeing the memory used
* by the array, and by the strings it references. After detaching,
* the `strvec` is in a reinitialized state and can be pushed
base-commit: a54a84b333adbecf7bc4483c0e36ed5878cac17b
--
gitgitgadget
^ permalink raw reply related
* Re: [PATCH v2 2/2] t5541: remove lockfile creation
From: Jeff King @ 2024-01-12 7:03 UTC (permalink / raw)
To: Justin Tobler via GitGitGadget; +Cc: git, Patrick Steinhardt, Justin Tobler
In-Reply-To: <f953a668c6a7e0a57adcee77ceee2d578970065e.1705004670.git.gitgitgadget@gmail.com>
On Thu, Jan 11, 2024 at 08:24:30PM +0000, Justin Tobler via GitGitGadget wrote:
> - # the new branch should not have been created upstream
> - test_must_fail git -C "$d" show-ref --verify refs/heads/atomic &&
> -
> - # upstream should still reflect atomic2, the last thing we pushed
> - # successfully
> - git rev-parse atomic2 >expected &&
> - # ...to other.
> - git -C "$d" rev-parse refs/heads/other >actual &&
> - test_cmp expected actual &&
> -
> - # the new branch should not have been created upstream
> + # The atomic and other branches should be created upstream.
> test_must_fail git -C "$d" show-ref --verify refs/heads/atomic &&
> + test_must_fail git -C "$d" show-ref --verify refs/heads/other &&
This last comment should say "should not be created", I think?
Other than that, both patches look good to me.
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] t1401: generalize reference locking
From: Jeff King @ 2024-01-12 7:01 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: Justin Tobler via GitGitGadget, git, Justin Tobler
In-Reply-To: <ZZ_MPK2huH2j6CGd@tanuki>
On Thu, Jan 11, 2024 at 12:08:44PM +0100, Patrick Steinhardt wrote:
> > (note that you get a different error message if the refs are packed,
> > since there we can notice the d/f conflict manually).
>
> If all we care for is the exit code then this would work for the
> reftable backend, too:
>
> ```
> $ git init --ref-format=reftable repo
> Initialized empty Git repository in /tmp/repo/.git/
> $ cd repo/
> $ git commit --allow-empty --message message
> [main (root-commit) c2512d3] x
> $ git symbolic-ref refs/heads refs/heads/foo
> $ echo $?
> 1
> ```
Yep, exactly. That should work for both and cover what the test was
originally trying to do.
> A bit unfortunate that there is no proper error message in that case,
> but that is a different topic.
Yeah, I would call that an outright bug. It does not have to be part of
this patch, but is worth fixing (and testing). I suspect it's not going
to be the only place with this problem. Most of the files-backend ref
code is very happy to spew to stdout using error(), but the reftable
code, having been written from a more lib-conscious perspective,
probably doesn't.
The obvious quick fix is to sprinkle more error() into the reftable
code. But in the longer term, I think the right direction is that the
ref code should accept an error strbuf or similar mechanism to propagate
human-readable error test to the caller.
-Peff
^ permalink raw reply
* Re: [PATCH 2/3] t7450: test submodule urls
From: Jeff King @ 2024-01-12 6:57 UTC (permalink / raw)
To: Victoria Dye; +Cc: Victoria Dye via GitGitGadget, git
In-Reply-To: <d852ad72-32c4-4b0f-8f34-e8b38b7f71ad@github.com>
On Thu, Jan 11, 2024 at 08:54:47AM -0800, Victoria Dye wrote:
> > All of this is inherited from the existing check_name() code, which I
> > think has all of the same bugs. The test scripts all just use the stdin
> > mode, so they don't notice. It's not too hard to fix, but maybe it's
> > worth just ripping out the unreachable code.
>
> Thanks for pointing out those issues, I think removing the command line
> input mode is the way to go. The description of the 'check_name()' mentions
> that the stdin mode was "primarily intended for testing". But as 85321a346b5
> (submodule--helper: move "check-name" to a test-tool, 2022-09-01) pointed
> out, 'check_name()' was never used outside of tests anyway, so whatever use
> case was imagined for the command line mode never seemed to have existed.
>
> Combine that with the fact that the command line mode is so different from
> the stdin mode (non-zero exit code for invalid names, prints nothing vs.
> zero exit code, prints valid names), there don't seem to be any real
> downsides to removing the unused code.
That sounds like a good plan to me. :)
-Peff
^ permalink raw reply
* Re: Storing private config files in .git directory?
From: Jeff King @ 2024-01-12 6:56 UTC (permalink / raw)
To: Stefan Haller; +Cc: Junio C Hamano, git
In-Reply-To: <c8ad96bc-0180-42f4-b559-20b475098eca@haller-berlin.de>
On Thu, Jan 11, 2024 at 02:28:51PM +0100, Stefan Haller wrote:
> On 10.01.24 12:08, Jeff King wrote:
> > On Mon, Jan 08, 2024 at 10:20:00AM -0800, Junio C Hamano wrote:
> >
> >> An obvious alternative is to have .lazygit directory next to .git directory
> >> which would give you a bigger separation, which can cut both ways.
> >
> > Just to spell out one of those ways: unlike ".git", we will happily
> > check out ".lazygit" from an untrusted remote repository. That may be a
> > feature if you want to be able to share project-specific config, or it
> > might be a terrible security vulnerability if lazygit config files can
> > trigger arbitrary code execution.
>
> Unless you don't version it and add it to .gitignore instead, which (I
> suppose) is what most people do with their .vscode/settings.json, for
> example.
A .gitignore will help with people accidentally adding their .lazygit
directory. What I meant, though, was somebody _intentionally_ creating a
malicious repository that would then execute arbitrary code when the
victim cloned it. We prevent that from happening with .git/config
because there's special handling that refuses to check out the name
".git" (or other filesystem-equivalent names). But ".lazygit" would not
have that same protection.
-Peff
^ permalink raw reply
* Re: [PATCH 1/1] attr: add builtin objectmode values support
From: Joanna Wang @ 2024-01-12 6:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, sunshine, tboegi
In-Reply-To: <xmqq5y0ssknj.fsf@gitster.g>
(I was out all month.) Thank you for the additional fixes.
On Thu, Dec 21, 2023 at 4:07 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Junio C Hamano <gitster@pobox.com> writes:
>
> > The attached is one possible way to plug the leak; I am not sure if
> > it is the best one, though. One thing I like about the solution is
> > that the approach makes sure that the mode attributes we would ever
> > return are very tightly controlled and does not allow a buggy code
> > to come up with "mode" to be passed to this new helper function to
> > pass random and unsupported mode bits without triggering the BUG().
> >
> > attr.c | 30 +++++++++++++++++++++++++++---
> > 1 file changed, 27 insertions(+), 3 deletions(-)
>
> Anybody who want to propose a better leakfix (we cannot afford to do
> with UNLEAK() as the number of leaked mode string will be unbounded)?
>
> Otherwise, I'll squash it in to Jonanna's patch and merge it down to
> 'next'.
>
> Thanks.
>
> > diff --git c/attr.c w/attr.c
> > index b03c20f768..679e42258c 100644
> > --- c/attr.c
> > +++ w/attr.c
> > @@ -1250,10 +1250,34 @@ static struct object_id *default_attr_source(void)
> > return &attr_source;
> > }
> >
> > +static const char *interned_mode_string(unsigned int mode)
> > +{
> > + static struct {
> > + unsigned int val;
> > + char str[7];
> > + } mode_string[] = {
> > + { .val = 0040000 },
> > + { .val = 0100644 },
> > + { .val = 0100755 },
> > + { .val = 0120000 },
> > + { .val = 0160000 },
> > + };
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(mode_string); i++) {
> > + if (mode_string[i].val != mode)
> > + continue;
> > + if (!*mode_string[i].str)
> > + snprintf(mode_string[i].str, sizeof(mode_string[i].str),
> > + "%06o", mode);
> > + return mode_string[i].str;
> > + }
> > + BUG("Unsupported mode 0%o", mode);
> > +}
> > +
> > static const char *builtin_object_mode_attr(struct index_state *istate, const char *path)
> > {
> > unsigned int mode;
> > - struct strbuf sb = STRBUF_INIT;
> >
> > if (direction == GIT_ATTR_CHECKIN) {
> > struct object_id oid;
> > @@ -1287,8 +1311,8 @@ static const char *builtin_object_mode_attr(struct index_state *istate, const ch
> > else
> > return ATTR__UNSET;
> > }
> > - strbuf_addf(&sb, "%06o", mode);
> > - return strbuf_detach(&sb, NULL);
> > +
> > + return interned_mode_string(mode);
> > }
> >
> >
^ permalink raw reply
* Hello can you join me on slack
From: ross nicholas Oneil thomas @ 2024-01-12 5:25 UTC (permalink / raw)
To: git@vger.kernel.org
Ross Nicholas Oneil Thomas
ownership of:
www.github.com
www.coinbase.com
www.jsnull.com
(559-816-2950)
^ permalink raw reply
* Re: [PATCH] push: improve consistency of output when "up to date"
From: Eric Sunshine @ 2024-01-12 3:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Benji Kay via GitGitGadget, git, Benji Kay
In-Reply-To: <xmqqjzofec0e.fsf@gitster.g>
On Thu, Jan 11, 2024 at 5:33 PM Junio C Hamano <gitster@pobox.com> wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
> > Thanks. This particular change is proposed periodically...
> > ... but has not been considered desirable.
> >
> > See, for instance, this email thread explaining the rationale for
> > avoiding such a change:
> > https://lore.kernel.org/git/pull.1298.git.1658908927714.gitgitgadget@gmail.com/T/
>
> Let's do the second best thing, leave a short comment near them, to
> make it possible for those who are motivated enough to find out why
> we decided to tell them "do not modify".
> ---
> diff --git a/builtin/send-pack.c b/builtin/send-pack.c
> @@ -333,6 +333,7 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
> if (!ret && !transport_refs_pushed(remote_refs))
> + /* do not modify this string */
> fprintf(stderr, "Everything up-to-date\n");
Yes, that helps, though, we can probably be a bit more friendly to
future developers. Rather than insisting that they dig through
history, we could use a slightly less terse comment, such as:
/* stable plumbing output; do not modify or localize */
^ permalink raw reply
* Help: Trying to setup triangular workflow
From: Matthew B. Gray @ 2024-01-12 2:23 UTC (permalink / raw)
To: git
Hello
I am trying to set up a triangular workflow against a fork. The example I'm
using is documented here: https://git-scm.com/docs/gitrevisions
Here's the example:
$ git config push.default current
$ git config remote.pushdefault myfork
$ git switch -c mybranch origin/master
$ git rev-parse --symbolic-full-name @{upstream}
refs/remotes/origin/master
$ git rev-parse --symbolic-full-name @{push}
refs/remotes/myfork/mybranch
My setup looks like this:
λ git -v
git version 2.43.0
λ git remote -vv
myfork git@github.com:heymatthew/dactyl-configurator-fork (fetch)
myfork git@github.com:heymatthew/dactyl-configurator-fork (push)
origin https://github.com/rianadon/dactyl-configurator (fetch)
origin https://github.com/rianadon/dactyl-configurator (push)
Here's what I get from running the documented example:
λ git config push.default current
λ git config remote.pushdefault myfork
λ git switch -c mybranch origin/main
λ git push
* [new branch] mybranch -> mybranch
branch 'mybranch' set up to track 'myfork/mybranch'.
λ git rev-parse --symbolic-full-name @{upstream}
refs/remotes/myfork/mybranch
λ git rev-parse --symbolic-full-name @{push}
refs/remotes/myfork/mybranch
I was expecting @{upstream} to be origin/main, but it appears that @{u} and
@{p} are the same.
Am I doing something wrong?
Are there better examples someone can point me at to do this?
Thanks in advance :)
Ngā mihi,
Matthew
^ permalink raw reply
* What's cooking in git.git (Jan 2024, #04; Thu, 11)
From: Junio C Hamano @ 2024-01-12 2:00 UTC (permalink / raw)
To: git
Here are the topics that have been cooking in my tree. Commits
prefixed with '+' are in 'next' (being in 'next' is a sign that a
topic is stable enough to be used and are candidate to be in a
future release). Commits prefixed with '-' are only in 'seen', and
aren't considered "accepted" at all and may be annotated with an URL
to a message that raises issues but they are no means exhaustive. A
topic without enough support may be discarded after a long period of
no activity (of course they can be resubmit when new interests
arise).
Copies of the source code to Git live in many repositories, and the
following is a list of the ones I push into or their mirrors. Some
repositories have only a subset of branches.
With maint, master, next, seen, todo:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://kernel.googlesource.com/pub/scm/git/git/
https://github.com/git/git/
https://gitlab.com/git-vcs/git/
With all the integration branches and topics broken out:
https://github.com/gitster/git/
Even though the preformatted documentation in HTML and man format
are not sources, they are published in these repositories for
convenience (replace "htmldocs" with "manpages" for the manual
pages):
git://git.kernel.org/pub/scm/git/git-htmldocs.git/
https://github.com/gitster/git-htmldocs.git/
Release tarballs are available at:
https://www.kernel.org/pub/software/scm/git/
--------------------------------------------------
[New Topics]
* cp/t4129-pipefix (2024-01-10) 1 commit
- t4129: prevent loss of exit code due to the use of pipes
Test update.
Will merge to 'next'.
source: <pull.1636.git.1704891257544.gitgitgadget@gmail.com>
* rj/advice-delete-branch-not-fully-merged (2024-01-11) 3 commits
- branch: make the advice to force-deleting a conditional one
- advice: fix an unexpected leading space
- advice: sort the advice related lists
The error message given when "git branch -d branch" fails due to
commits unique to the branch has been split into an error and a new
conditional advice message.
Will merge to 'next'?
source: <4aedc15c-4b3f-4f5e-abea-581b501600f8@gmail.com>
* en/diffcore-delta-final-line-fix (2024-01-11) 1 commit
- diffcore-delta: avoid ignoring final 'line' of file
Rename detection logic ignored the final line of a file if it is an
incomplete line.
Expecting a reroll.
cf. <xmqqedenearc.fsf@gitster.g>
source: <pull.1637.git.1705006074626.gitgitgadget@gmail.com>
* mj/gitweb-unreadable-config-error (2024-01-10) 1 commit
- gitweb: die when a configuration file cannot be read
When given an existing but unreadable file as a configuration file,
gitweb behaved as if the file did not exist at all, but now it
errors out. This is a change that may break backward compatibility.
Will merge to 'next'?
source: <20240110225709.30168-1-marcelo.jimenez@gmail.com>
* ps/completion-with-reftable-fix (2024-01-11) 2 commits
- completion: silence pseudoref existence check
- t9902: verify that completion does not print anything
Completion update to prepare for reftable
Will merge to 'next'.
source: <cover.1704969119.git.ps@pks.im>
* ps/p4-use-ref-api (2024-01-11) 1 commit
- git-p4: stop reaching into the refdb
"git p4" update to prepare for reftable
Will merge to 'next'.
source: <33d6a062ec56be33ed50a42a420be0b023f6f4cf.1704980814.git.ps@pks.im>
--------------------------------------------------
[Cooking]
* ps/gitlab-ci-static-analysis (2024-01-08) 1 commit
(merged to 'next' on 2024-01-10 at 71af34de07)
+ ci: add job performing static analysis on GitLab CI
GitLab CI update.
Will merge to 'master'.
source: <1536a5ef07ad24dafb5d685b40099882f89e6cc5.1703761005.git.ps@pks.im>
* ps/prompt-parse-HEAD-futureproof (2024-01-08) 2 commits
(merged to 'next' on 2024-01-10 at f9515b9d89)
+ git-prompt: stop manually parsing HEAD with unknown ref formats
+ Merge branch 'ps/refstorage-extension' into ps/prompt-parse-HEAD-futureproof
(this branch uses ps/refstorage-extension.)
Futureproof command line prompt support (in contrib/).
Will merge to 'master'.
source: <ef4e36a5a40c369da138242a8fdc9e12a846613b.1704356313.git.ps@pks.im>
* ps/reftable-optimize-io (2024-01-11) 5 commits
- reftable/blocksource: use mmap to read tables
- reftable/blocksource: refactor code to match our coding style
- reftable/stack: use stat info to avoid re-reading stack list
- reftable/stack: refactor reloading to use file descriptor
- reftable/stack: refactor stack reloading to have common exit path
Low-level I/O optimization for reftable.
Will merge to 'next'.
source: <cover.1704966670.git.ps@pks.im>
* rj/clarify-branch-doc-m (2024-01-08) 1 commit
(merged to 'next' on 2024-01-10 at 432eaa2c6b)
+ branch: clarify <oldbranch> term
Doc update.
Will merge to 'master'.
source: <d38e5a18-4d85-48f3-bc8b-8ca02ea683a4@gmail.com>
* tb/fetch-all-configuration (2024-01-08) 1 commit
- fetch: add new config option fetch.all
"git fetch" learned to pay attention to "fetch.all" configuration
variable, which pretends as if "--all" was passed from the command
line when no remote parameter was given.
Will merge to 'next'.
source: <20240108211832.47362-1-dev@tb6.eu>
* rj/advice-disable-how-to-disable (2024-01-09) 3 commits
- advice: allow disabling the automatic hint in advise_if_enabled()
- t/test-tool: handle -c <name>=<value> arguments
- t/test-tool: usage description
All conditional "advice" messages show how to turn them off, which
becomes repetitive. Add a configuration variable to omit the
instruction.
Expecting a reroll.
cf. <ZZ2QafUf/JxXYZU/@nand.local>
source: <7c68392c-af2f-4999-ae64-63221bf7833a@gmail.com>
* vd/fsck-submodule-url-test (2024-01-09) 3 commits
- submodule-config.c: strengthen URL fsck check
- t7450: test submodule urls
- submodule-config.h: move check_submodule_url
Tighten URL checks fsck makes in a URL recorded for submodules.
Expecting a reroll (and review response).
cf. <20240110103812.GB16674@coredump.intra.peff.net>
cf. <ZZ46MrjSocJl-kpU@tanuki>
source: <pull.1635.git.1704822817.gitgitgadget@gmail.com>
* ms/rebase-insnformat-doc-fix (2024-01-03) 1 commit
(merged to 'next' on 2024-01-04 at d68f2be39b)
+ Documentation: fix statement about rebase.instructionFormat
Docfix.
Will merge to 'master'.
source: <pull.1629.git.git.1704305663254.gitgitgadget@gmail.com>
* cp/git-flush-is-an-env-bool (2024-01-04) 1 commit
(merged to 'next' on 2024-01-04 at b435a96ce8)
+ write-or-die: make GIT_FLUSH a Boolean environment variable
Unlike other environment variables that took the usual
true/false/yes/no as well as 0/1, GIT_FLUSH only understood 0/1,
which has been corrected.
Will merge to 'master'.
source: <pull.1628.v3.git.1704363617842.gitgitgadget@gmail.com>
* sd/negotiate-trace-fix (2024-01-03) 1 commit
- push: region_leave trace for negotiate_using_fetch
Tracing fix.
Waiting for a review response.
cf. <xmqqbka27zu9.fsf@gitster.g>
source: <20240103224054.1940209-1-delmerico@google.com>
* sk/mingw-owner-check-error-message-improvement (2024-01-10) 1 commit
- mingw: give more details about unsafe directory's ownership
In addition to (rather cryptic) Security Identifiers, show username
and domain in the error message when we barf on mismatch between
the Git directory and the current user.
Will merge to 'next'.
source: <20240108173837.20480-2-soekkle@freenet.de>
* ib/rebase-reschedule-doc (2024-01-05) 1 commit
(merged to 'next' on 2024-01-08 at d451d1f760)
+ rebase: clarify --reschedule-failed-exec default
Doc update.
Will merge to 'master'.
source: <20240105011424.1443732-2-illia.bobyr@gmail.com>
* jk/commit-graph-slab-clear-fix (2024-01-05) 1 commit
(merged to 'next' on 2024-01-08 at f78c4fc296)
+ commit-graph: retain commit slab when closing NULL commit_graph
Clearing in-core repository (happens during e.g., "git fetch
--recurse-submodules" with commit graph enabled) made in-core
commit object in an inconsistent state by discarding the necessary
data from commit-graph too early, which has been corrected.
Will merge to 'master'.
source: <20240105054142.GA2035092@coredump.intra.peff.net>
* jk/index-pack-lsan-false-positive-fix (2024-01-05) 1 commit
(merged to 'next' on 2024-01-08 at 589ed65251)
+ index-pack: spawn threads atomically
Fix false positive reported by leak sanitizer.
Will merge to 'master'.
source: <20240105085034.GA3078476@coredump.intra.peff.net>
* cp/sideband-array-index-comment-fix (2023-12-28) 1 commit
(merged to 'next' on 2024-01-08 at f906bc86f1)
+ sideband.c: remove redundant 'NEEDSWORK' tag
In-code comment fix.
Will merge to 'master'.
source: <pull.1625.v4.git.1703750460527.gitgitgadget@gmail.com>
* ps/worktree-refdb-initialization (2024-01-08) 7 commits
- builtin/worktree: create refdb via ref backend
- worktree: expose interface to look up worktree by name
- builtin/worktree: move setup of commondir file earlier
- refs/files: skip creation of "refs/{heads,tags}" for worktrees
- setup: move creation of "refs/" into the files backend
- refs: prepare `refs_init_db()` for initializing worktree refs
- Merge branch 'ps/refstorage-extension' into ps/worktree-refdb-initialization
(this branch uses ps/refstorage-extension.)
Instead of manually creating refs/ hierarchy on disk upon a
creation of a secondary worktree, which is only usable via the
files backend, use the refs API to populate it.
Needs review.
source: <cover.1704705733.git.ps@pks.im>
* cp/apply-core-filemode (2023-12-26) 3 commits
- apply: code simplification
- apply: correctly reverse patch's pre- and post-image mode bits
- apply: ignore working tree filemode when !core.filemode
"git apply" on a filesystem without filemode support have learned
to take a hint from what is in the index for the path, even when
not working with the "--index" or "--cached" option, when checking
the executable bit match what is required by the preimage in the
patch.
Needs review.
source: <20231226233218.472054-1-gitster@pobox.com>
* jk/t1006-cat-file-objectsize-disk (2024-01-03) 2 commits
(merged to 'next' on 2024-01-03 at a492c6355c)
+ t1006: prefer shell loop to awk for packed object sizes
(merged to 'next' on 2023-12-28 at d82812e636)
+ t1006: add tests for %(objectsize:disk)
Test update.
Will merge to 'master'.
source: <20231221094722.GA570888@coredump.intra.peff.net>
source: <20240103090152.GB1866508@coredump.intra.peff.net>
* js/contributor-docs-updates (2023-12-27) 9 commits
(merged to 'next' on 2024-01-02 at 0e072117cd)
+ SubmittingPatches: hyphenate non-ASCII
+ SubmittingPatches: clarify GitHub artifact format
+ SubmittingPatches: clarify GitHub visual
+ SubmittingPatches: provide tag naming advice
+ SubmittingPatches: update extra tags list
+ SubmittingPatches: discourage new trailers
+ SubmittingPatches: drop ref to "What's in git.git"
+ CodingGuidelines: write punctuation marks
+ CodingGuidelines: move period inside parentheses
Doc update.
Will merge to 'master'.
source: <pull.1623.v3.git.1703739324.gitgitgadget@gmail.com>
* al/unit-test-ctype (2024-01-05) 1 commit
- unit-tests: rewrite t/helper/test-ctype.c as a unit test
Move test-ctype helper to the unit-test framework.
Expecting a (hopefully small and final) reroll.
cf. <a087f57c-ce72-45c7-8182-f38d0aca9030@web.de>
cf. <33c81610-0958-49da-b702-ba8d96ecf1d3@gmail.com>
source: <20240105161413.10422-1-ach.lumap@gmail.com>
* bk/bisect-doc-fix (2024-01-10) 2 commits
- doc: refer to pathspec instead of path
- doc: use singular form of repeatable path arg
Synopsis fix.
Will merge to 'next'.
source: <20240103040207.661413-1-britton.kerin@gmail.com>
* ja/doc-placeholders-fix (2023-12-26) 2 commits
- doc: enforce placeholders in documentation
- doc: enforce dashes in placeholders
Docfix.
Needs review.
source: <pull.1626.git.1703539287.gitgitgadget@gmail.com>
* ps/refstorage-extension (2024-01-02) 13 commits
(merged to 'next' on 2024-01-08 at f9a034803b)
+ t9500: write "extensions.refstorage" into config
+ builtin/clone: introduce `--ref-format=` value flag
+ builtin/init: introduce `--ref-format=` value flag
+ builtin/rev-parse: introduce `--show-ref-format` flag
+ t: introduce GIT_TEST_DEFAULT_REF_FORMAT envvar
+ setup: introduce GIT_DEFAULT_REF_FORMAT envvar
+ setup: introduce "extensions.refStorage" extension
+ setup: set repository's formats on init
+ setup: start tracking ref storage format
+ refs: refactor logic to look up storage backends
+ worktree: skip reading HEAD when repairing worktrees
+ t: introduce DEFAULT_REPO_FORMAT prereq
+ Merge branch 'ps/clone-into-reftable-repository' into ps/refstorage-extension
(this branch is used by ps/prompt-parse-HEAD-futureproof and ps/worktree-refdb-initialization.)
Introduce a new extension "refstorage" so that we can mark a
repository that uses a non-default ref backend, like reftable.
Will merge to 'master'.
source: <cover.1703833818.git.ps@pks.im>
* ps/reftable-fixes-and-optims (2024-01-03) 9 commits
(merged to 'next' on 2024-01-08 at 167d7685f8)
+ reftable/merged: transfer ownership of records when iterating
+ reftable/merged: really reuse buffers to compute record keys
+ reftable/record: store "val2" hashes as static arrays
+ reftable/record: store "val1" hashes as static arrays
+ reftable/record: constify some parts of the interface
+ reftable/writer: fix index corruption when writing multiple indices
+ reftable/stack: do not auto-compact twice in `reftable_stack_add()`
+ reftable/stack: do not overwrite errors when compacting
+ Merge branch 'ps/reftable-fixes' into ps/reftable-fixes-and-optims
More fixes and optimizations to the reftable backend.
Will merge to 'master'.
source: <cover.1704262787.git.ps@pks.im>
* tb/multi-pack-verbatim-reuse (2023-12-14) 26 commits
(merged to 'next' on 2024-01-04 at 891ac0fa2c)
+ t/perf: add performance tests for multi-pack reuse
+ pack-bitmap: enable reuse from all bitmapped packs
+ pack-objects: allow setting `pack.allowPackReuse` to "single"
+ t/test-lib-functions.sh: implement `test_trace2_data` helper
+ pack-objects: add tracing for various packfile metrics
+ pack-bitmap: prepare to mark objects from multiple packs for reuse
+ pack-revindex: implement `midx_pair_to_pack_pos()`
+ pack-revindex: factor out `midx_key_to_pack_pos()` helper
+ midx: implement `midx_preferred_pack()`
+ git-compat-util.h: implement checked size_t to uint32_t conversion
+ pack-objects: include number of packs reused in output
+ pack-objects: prepare `write_reused_pack_verbatim()` for multi-pack reuse
+ pack-objects: prepare `write_reused_pack()` for multi-pack reuse
+ pack-objects: pass `bitmapped_pack`'s to pack-reuse functions
+ pack-objects: keep track of `pack_start` for each reuse pack
+ pack-objects: parameterize pack-reuse routines over a single pack
+ pack-bitmap: return multiple packs via `reuse_partial_packfile_from_bitmap()`
+ pack-bitmap: simplify `reuse_partial_packfile_from_bitmap()` signature
+ ewah: implement `bitmap_is_empty()`
+ pack-bitmap: pass `bitmapped_pack` struct to pack-reuse functions
+ midx: implement `midx_locate_pack()`
+ midx: implement `BTMP` chunk
+ midx: factor out `fill_pack_info()`
+ pack-bitmap: plug leak in find_objects()
+ pack-bitmap-write: deep-clear the `bb_commit` slab
+ pack-objects: free packing_data in more places
Streaming spans of packfile data used to be done only from a
single, primary, pack in a repository with multiple packfiles. It
has been extended to allow reuse from other packfiles, too.
Will merge to 'master'.
cf. <ZXurD1NTZ4TAs7WZ@nand.local>
source: <cover.1702592603.git.me@ttaylorr.com>
* jc/bisect-doc (2023-12-09) 1 commit
- bisect: document "terms" subcommand more fully
Doc update.
Needs review.
source: <xmqqzfyjmk02.fsf@gitster.g>
* jw/builtin-objectmode-attr (2023-12-28) 1 commit
(merged to 'next' on 2024-01-02 at 4c3784b3a1)
+ attr: add builtin objectmode values support
The builtin_objectmode attribute is populated for each path
without adding anything in .gitattributes files, which would be
useful in magic pathspec, e.g., ":(attr:builtin_objectmode=100755)"
to limit to executables.
Will merge to 'master'.
cf. <xmqq5y0ssknj.fsf@gitster.g>
source: <20231116054437.2343549-1-jojwang@google.com>
* tb/pair-chunk-expect (2023-11-10) 8 commits
- midx: read `OOFF` chunk with `pair_chunk_expect()`
- midx: read `OIDL` chunk with `pair_chunk_expect()`
- commit-graph: read `BIDX` chunk with `pair_chunk_expect()`
- commit-graph: read `GDAT` chunk with `pair_chunk_expect()`
- commit-graph: read `CDAT` chunk with `pair_chunk_expect()`
- commit-graph: read `OIDL` chunk with `pair_chunk_expect()`
- chunk-format: introduce `pair_chunk_expect()` helper
- Merge branch 'jk/chunk-bounds-more' into HEAD
Further code clean-up.
Needs review.
source: <cover.1699569246.git.me@ttaylorr.com>
* tb/path-filter-fix (2023-10-18) 17 commits
- bloom: introduce `deinit_bloom_filters()`
- commit-graph: reuse existing Bloom filters where possible
- object.h: fix mis-aligned flag bits table
- commit-graph: drop unnecessary `graph_read_bloom_data_context`
- commit-graph.c: unconditionally load Bloom filters
- bloom: prepare to discard incompatible Bloom filters
- bloom: annotate filters with hash version
- commit-graph: new filter ver. that fixes murmur3
- repo-settings: introduce commitgraph.changedPathsVersion
- t4216: test changed path filters with high bit paths
- t/helper/test-read-graph: implement `bloom-filters` mode
- bloom.h: make `load_bloom_filter_from_graph()` public
- t/helper/test-read-graph.c: extract `dump_graph_info()`
- gitformat-commit-graph: describe version 2 of BDAT
- commit-graph: ensure Bloom filters are read with consistent settings
- revision.c: consult Bloom filters for root commits
- t/t4216-log-bloom.sh: harden `test_bloom_filters_not_used()`
The Bloom filter used for path limited history traversal was broken
on systems whose "char" is unsigned; update the implementation and
bump the format version to 2.
Expecting a reroll?
cf. <20231023202212.GA5470@szeder.dev>
source: <cover.1697653929.git.me@ttaylorr.com>
* ak/color-decorate-symbols (2023-10-23) 7 commits
- log: add color.decorate.pseudoref config variable
- refs: exempt pseudorefs from pattern prefixing
- refs: add pseudorefs array and iteration functions
- log: add color.decorate.ref config variable
- log: add color.decorate.symbol config variable
- log: use designated inits for decoration_colors
- config: restructure color.decorate documentation
A new config for coloring.
Needs review.
source: <20231023221143.72489-1-andy.koppe@gmail.com>
* eb/hash-transition (2023-10-02) 30 commits
- t1016-compatObjectFormat: add tests to verify the conversion between objects
- t1006: test oid compatibility with cat-file
- t1006: rename sha1 to oid
- test-lib: compute the compatibility hash so tests may use it
- builtin/ls-tree: let the oid determine the output algorithm
- object-file: handle compat objects in check_object_signature
- tree-walk: init_tree_desc take an oid to get the hash algorithm
- builtin/cat-file: let the oid determine the output algorithm
- rev-parse: add an --output-object-format parameter
- repository: implement extensions.compatObjectFormat
- object-file: update object_info_extended to reencode objects
- object-file-convert: convert commits that embed signed tags
- object-file-convert: convert commit objects when writing
- object-file-convert: don't leak when converting tag objects
- object-file-convert: convert tag objects when writing
- object-file-convert: add a function to convert trees between algorithms
- object: factor out parse_mode out of fast-import and tree-walk into in object.h
- cache: add a function to read an OID of a specific algorithm
- tag: sign both hashes
- commit: export add_header_signature to support handling signatures on tags
- commit: convert mergetag before computing the signature of a commit
- commit: write commits for both hashes
- object-file: add a compat_oid_in parameter to write_object_file_flags
- object-file: update the loose object map when writing loose objects
- loose: compatibilty short name support
- loose: add a mapping between SHA-1 and SHA-256 for loose objects
- repository: add a compatibility hash algorithm
- object-names: support input of oids in any supported hash
- oid-array: teach oid-array to handle multiple kinds of oids
- object-file-convert: stubs for converting from one object format to another
Teach a repository to work with both SHA-1 and SHA-256 hash algorithms.
Needs review.
source: <878r8l929e.fsf@gmail.froward.int.ebiederm.org>
* jx/remote-archive-over-smart-http (2023-12-14) 4 commits
- archive: support remote archive from stateless transport
- transport-helper: call do_take_over() in connect_helper
- transport-helper: call do_take_over() in process_connect
- transport-helper: no connection restriction in connect_helper
"git archive --remote=<remote>" learned to talk over the smart
http (aka stateless) transport.
Needs review.
source: <cover.1702562879.git.zhiyou.jx@alibaba-inc.com>
* jx/sideband-chomp-newline-fix (2023-12-18) 3 commits
(merged to 'next' on 2024-01-04 at 1237898a22)
+ pkt-line: do not chomp newlines for sideband messages
+ pkt-line: memorize sideband fragment in reader
+ test-pkt-line: add option parser for unpack-sideband
Sideband demultiplexer fixes.
Will merge to 'master'.
source: <cover.1702823801.git.zhiyou.jx@alibaba-inc.com>
* jc/rerere-cleanup (2023-08-25) 4 commits
- rerere: modernize use of empty strbuf
- rerere: try_merge() should use LL_MERGE_ERROR when it means an error
- rerere: fix comment on handle_file() helper
- rerere: simplify check_one_conflict() helper function
Code clean-up.
Not ready to be reviewed yet.
source: <20230824205456.1231371-1-gitster@pobox.com>
^ permalink raw reply
* Re: [PATCH v2 2/3] advice: fix an unexpected leading space
From: Junio C Hamano @ 2024-01-12 1:21 UTC (permalink / raw)
To: Rubén Justo; +Cc: Git List
In-Reply-To: <d5fbdb05-d16a-4390-946e-22a5a7a1b56a@gmail.com>
Rubén Justo <rjusto@gmail.com> writes:
> [ ... ]
> diff --git a/advice.h b/advice.h
> index 0f584163f5..2affbe1426 100644
> --- a/advice.h
> +++ b/advice.h
> @@ -49,6 +49,7 @@ struct string_list;
> ADVICE_UPDATE_SPARSE_PATH,
> ADVICE_WAITING_FOR_EDITOR,
> ADVICE_SKIPPED_CHERRY_PICKS,
> + ADVICE_WORKTREE_ADD_ORPHAN,
> };
>
> Note the hunk header, instead of a much more expected:
>
> @@ -49,6 +49,7 @@ enum advice_type
Next time, don't include "diff" output in the proposed log message
without indenting. It makes it hard to read and parse.
The attached is what I queued in my tree.
Thanks.
------- >8 ------------- >8 ------------- >8 ------------- >8 -------
From: Rubén Justo <rjusto@gmail.com>
Subject: [PATCH] advice: fix an unexpected leading space
This space was introduced, presumably unintentionally, in b3b18d1621
(advice: revamp advise API, 2020-03-02)
I notice this space due to confuse diff outputs while doing some
changes to enum advice_type.
As a reference, a recent change we have to that enum is:
$ git show 35f0383
...
diff --git a/advice.h b/advice.h
index 0f584163f5..2affbe1426 100644
--- a/advice.h
+++ b/advice.h
@@ -49,6 +49,7 @@ struct string_list;
ADVICE_UPDATE_SPARSE_PATH,
ADVICE_WAITING_FOR_EDITOR,
ADVICE_SKIPPED_CHERRY_PICKS,
+ ADVICE_WORKTREE_ADD_ORPHAN,
};
Note the hunk header, instead of a much more expected:
@@ -49,6 +49,7 @@ enum advice_type
Signed-off-by: Rubén Justo <rjusto@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
advice.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/advice.h b/advice.h
index 9396bcdcf1..74d44d1156 100644
--- a/advice.h
+++ b/advice.h
@@ -10,7 +10,7 @@ struct string_list;
* Add the new config variable to Documentation/config/advice.txt.
* Call advise_if_enabled to print your advice.
*/
- enum advice_type {
+enum advice_type {
ADVICE_ADD_EMBEDDED_REPO,
ADVICE_ADD_EMPTY_PATHSPEC,
ADVICE_ADD_IGNORED_FILE,
--
2.43.0-283-ga54a84b333
^ permalink raw reply related
* Re: [PATCH] push: improve consistency of output when "up to date"
From: Benji Kay @ 2024-01-12 0:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Sunshine, Benji Kay via GitGitGadget, git
In-Reply-To: <CADavbxcFXpP5EQZ=UEMZt+6KKVtCsTMbgQDHEo0uinm0YfRbZA@mail.gmail.com>
If it's important these messages are not changed (under the presumption
some programs may make decisions based on the output), perhaps a test
should be written to ensure the output is as expected.
^ permalink raw reply
* Re: [PATCH v3] builtin/revert.c: refactor using an enum for cmd-action
From: Junio C Hamano @ 2024-01-12 0:40 UTC (permalink / raw)
To: Michael Lohmann; +Cc: git, phillip.wood123, phillip.wood, wanja.hentze
In-Reply-To: <20240111200627.64199-1-mi.al.lohmann@gmail.com>
Michael Lohmann <mi.al.lohmann@gmail.com> writes:
> - if (cmd == 'c')
> + case ACTION_CONTINUE:
> return sequencer_continue(the_repository, opts);
> - if (cmd == 'a')
> + case ACTION_ABORT:
> return sequencer_rollback(the_repository, opts);
> - if (cmd == 's')
> + case ACTION_SKIP:
> return sequencer_skip(the_repository, opts);
> - return sequencer_pick_revisions(the_repository, opts);
> + case ACTION_START:
> + return sequencer_pick_revisions(the_repository, opts);
> + }
> }
This change broke the build when merged to 'seen' like so ...
builtin/revert.c: In function 'run_sequencer':
builtin/revert.c:242:1: error: control reaches end of non-void function [-Werror=return-typ ]
242 | }
| ^
... so I'm discarding
it out of my tree and redoing today's integration cycle.
Different compilers are smart in different ways, and we shouldn't
overly rely on the fact that some compilers may be happy by seeing a
switch that has all the enum values and notice that one of the return
will be triggered in its case arms.
^ permalink raw reply
* Re: [RFC PATCH] `log --merge` also for rebase/cherry pick/revert
From: Junio C Hamano @ 2024-01-12 0:15 UTC (permalink / raw)
To: Michael Lohmann; +Cc: git, phillip.wood123, Elijah Newren
In-Reply-To: <20240111233311.64734-1-mi.al.lohmann@gmail.com>
Michael Lohmann <mi.al.lohmann@gmail.com> writes:
> This extends the functionality of `git log --merge` to also work with
> conflicts for rebase, cherry pick and revert.
>
> Signed-off-by: Michael Lohmann <mi.al.lohmann@gmail.com>
> ---
> ... It is basically the counterpart to
> `git show ${ACTION}_HEAD` for understanding the source of the conflict.
I do not know about the validity of that approach to use *_HEAD, but
we may want to tighten the original's use of repo_get_oid() here ...
> - if (repo_get_oid(the_repository, "MERGE_HEAD", &oid))
> - die("--merge without MERGE_HEAD?");
> - other = lookup_commit_or_die(&oid, "MERGE_HEAD");
... so that we won't be confused in a repository that has a tag
whose name happens to be MERGE_HEAD. We probably should be using
refs.c:refs_resolve_ref_unsafe() instead to
(1) ensure MERGE_HEAD is a ref,
(2) obtain the oid without any prefixing by refs.c:repo_dwim_ref(),
and optionally
(3) error out when MERGE_HEAD is a symref.
As your patch makes the problem even worse, if we were to do such a
tightening (and I do not see a reason not to), it may want to be
done before, not after, this patch.
I won't comment on the coding style violations in the patch below in
this message.
Thanks.
> diff --git a/revision.c b/revision.c
> index 2424c9bd67..2e5c00dabd 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -1961,23 +1961,37 @@ static void add_pending_commit_list(struct rev_info *revs,
> }
> }
>
> +static char* get_action_head_name(struct object_id* oid)
> +{
> + if (!repo_get_oid(the_repository, "MERGE_HEAD", oid)) {
> + return "MERGE_HEAD";
> + } else if (!repo_get_oid(the_repository, "REBASE_HEAD", oid)) {
> + return "REBASE_HEAD";
> + } else if (!repo_get_oid(the_repository, "CHERRY_PICK_HEAD", oid)) {
> + return "CHERRY_PICK_HEAD";
> + } else if (!repo_get_oid(the_repository, "REVERT_HEAD", oid)) {
> + return "REVERT_HEAD";
> + } else
> + die("--merge without MERGE_HEAD, REBASE_HEAD, CHERRY_PICK_HEAD or REVERT_HEAD?");
> +}
> +
> static void prepare_show_merge(struct rev_info *revs)
> {
> struct commit_list *bases;
> struct commit *head, *other;
> struct object_id oid;
> const char **prune = NULL;
> + const char *action_head_name;
> int i, prune_num = 1; /* counting terminating NULL */
> struct index_state *istate = revs->repo->index;
>
> if (repo_get_oid(the_repository, "HEAD", &oid))
> die("--merge without HEAD?");
> head = lookup_commit_or_die(&oid, "HEAD");
> - if (repo_get_oid(the_repository, "MERGE_HEAD", &oid))
> - die("--merge without MERGE_HEAD?");
> - other = lookup_commit_or_die(&oid, "MERGE_HEAD");
> + action_head_name = get_action_head_name(&oid);
> + other = lookup_commit_or_die(&oid, action_head_name);
> add_pending_object(revs, &head->object, "HEAD");
> - add_pending_object(revs, &other->object, "MERGE_HEAD");
> + add_pending_object(revs, &other->object, action_head_name);
> bases = repo_get_merge_bases(the_repository, head, other);
> add_rev_cmdline_list(revs, bases, REV_CMD_MERGE_BASE, UNINTERESTING | BOTTOM);
> add_pending_commit_list(revs, bases, UNINTERESTING | BOTTOM);
^ permalink raw reply
* Re: [DISCUSS] Introducing Rust into the Git project
From: Trevor Gross @ 2024-01-11 23:53 UTC (permalink / raw)
To: Taylor Blau; +Cc: git
In-Reply-To: <ZZ77NQkSuiRxRDwt@nand.local>
On Wed, Jan 10, 2024 at 3:19 PM Taylor Blau <me@ttaylorr.com> wrote:
>
> Over the holiday break at the end of last year I spent some time
> thinking on what it would take to introduce Rust into the Git project.
>
> There is significant work underway to introduce Rust into the Linux
> kernel (see [1], [2]). Among their stated goals, I think there are a few
> which could be potentially relevant to the Git project:
>
> - Lower risk of memory safety bugs, data races, memory leaks, etc.
> thanks to the language's safety guarantees.
>
> - Easier to gain confidence when refactoring or introducing new code
> in Rust (assuming little to no use of the language's `unsafe`
> feature).
>
> - Contributing to Git becomes easier and accessible to a broader group
> of programmers by relying on a more modern language.
>
> Given the allure of these benefits, I think it's at least worth
> considering and discussing how Rust might make its way into Junio's
> tree.
>
> I imagine that the transition state would involve some parts of the
> project being built in C and calling into Rust code via FFI (and perhaps
> vice-versa, with Rust code calling back into the existing C codebase).
> Luckily for us, Rust's FFI provides a zero-cost abstraction [3], meaning
> there is no performance impact when calling code from one language in
> the other.
>
> Some open questions from me, at least to get the discussion going are:
>
> 1. Platform support. The Rust compiler (rustc) does not enjoy the same
> widespread availability that C compilers do. For instance, I
> suspect that NonStop, AIX, Solaris, among others may not be
> supported.
>
> One possible alternative is to have those platforms use a Rust
> front-end for a compiler that they do support. The gccrs [4]
> project would allow us to compile Rust anywhere where GCC is
> available. The rustc_codegen_gcc [5] project uses GCC's libgccjit
> API to target GCC from rustc itself.
>
> 2. Migration. What parts of Git are easiest to convert to Rust? My
> hunch is that the answer is any stand-alone libraries, like
> strbuf.h. I'm not sure how we should identify these, though, and in
> what order we would want to move them over.
>
> 3. Interaction with the lib-ification effort. There is lots of work
> going on in an effort to lib-ify much of the Git codebase done by
> Google. I'm not sure how this would interact with that effort, but
> we should make sure that one isn't a blocker for the other.
>
> I'm curious to hear what others think about this. I think that this
> would be an exciting and worthwhile direction for the project. Let's
> see!
>
> Thanks,
> Taylor
>
> [1]: https://rust-for-linux.com/
> [2]: https://lore.kernel.org/rust-for-linux/20210414184604.23473-1-ojeda@kernel.org/
> [3]: https://blog.rust-lang.org/2015/04/24/Rust-Once-Run-Everywhere.html#c-talking-to-rust
> [4]: https://github.com/Rust-GCC/gccrs
> [5]: https://github.com/rust-lang/rustc_codegen_gcc
>
Two good reference codebases out there:
Abstractions over libgit2
Repo: https://github.com/rust-lang/git2-rs
Docs: https://docs.rs/git2/latest/git2/
gix, a WIP reimplementation of git. This is far from complete but does
a lot of threading / async to apparently get quite fast.
Repo: https://github.com/Byron/gitoxide
Docs: https://docs.rs/gix/latest/gix/
If the git project does decide to go forward with this, there is
probably a lot of completed work that can be pulled from either of
those sources.
^ permalink raw reply
* Re: [DISCUSS] Introducing Rust into the Git project
From: brian m. carlson @ 2024-01-11 23:48 UTC (permalink / raw)
To: Sam James; +Cc: me, git
In-Reply-To: <87v880m6r3.fsf@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]
On 2024-01-11 at 11:45:07, Sam James wrote:
> Something I'm a bit concerned about is that right now, neither
> rustc_codegen_gcc nor gccrs are ready for use here.
>
> We've had trouble getting things wired up for rustc_codegen_gcc
> - which is not to speak against their wonderful efforts - because
> the Rust community hasn't yet figured out how to handle things which
> pure rustc supports yet. See
> e.g. https://github.com/rust-lang/libc/pull/3032.
Is this simply library support in the libc crate? That's very easy to add.
> I think care should be taken in citing rustc_codegen_gcc and gccrs
> as options for alternative platforms for now. They will hopefully
> be great options in the future, but they aren't today, and they probably
> won't be in the next 6 months at the least.
What specifically is missing for rust_codegen_gcc? I know gccrs is not
ready at the moment, but I was under the impression that
rust_codegen_gcc was at least usable. I'm aware it requires some
patches to GCC, but distros should be able to carry those.
If rust_codegen_gcc isn't viable, then I agree we should avoid making
Rust mandatory, but I'd like to learn more.
--
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* [RFC PATCH] `log --merge` also for rebase/cherry pick/revert
From: Michael Lohmann @ 2024-01-11 23:33 UTC (permalink / raw)
To: git; +Cc: Michael Lohmann, phillip.wood123
This extends the functionality of `git log --merge` to also work with
conflicts for rebase, cherry pick and revert.
Signed-off-by: Michael Lohmann <mi.al.lohmann@gmail.com>
---
Hi everybody!
When Phillip Wood gave me some nice hints on his workflow concerning
conflicts [1] (we discussed if `--show-current-patch` would make sense
for cherry pick/revert). When I learned about `git log --merge` I was a
bit sad to discover that those do not exist for rebase/revert/cherry
pick since they look really valuable for getting an understanding on
what was changed. It is basically the counterpart to
`git show ${ACTION}_HEAD` for understanding the source of the conflict.
I am curious if also other people would be interested in having an easy
way to get a log of only the relevant commits touching conflicting files
for said actions.
With this patch I think the functionality is there, just hijacking the
`--merge` code - maybe an alias like `git log --conflict` or similar
might be more descriptive now?
What do you think about this idea? (Or am I maybe missing an easy way to
achieve it with the existing code as well?)
Michael
[1] https://lore.kernel.org/git/cfba7098-3c23-4a81-933c-b7fefdedec8a@gmail.com/
revision.c | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/revision.c b/revision.c
index 2424c9bd67..2e5c00dabd 100644
--- a/revision.c
+++ b/revision.c
@@ -1961,23 +1961,37 @@ static void add_pending_commit_list(struct rev_info *revs,
}
}
+static char* get_action_head_name(struct object_id* oid)
+{
+ if (!repo_get_oid(the_repository, "MERGE_HEAD", oid)) {
+ return "MERGE_HEAD";
+ } else if (!repo_get_oid(the_repository, "REBASE_HEAD", oid)) {
+ return "REBASE_HEAD";
+ } else if (!repo_get_oid(the_repository, "CHERRY_PICK_HEAD", oid)) {
+ return "CHERRY_PICK_HEAD";
+ } else if (!repo_get_oid(the_repository, "REVERT_HEAD", oid)) {
+ return "REVERT_HEAD";
+ } else
+ die("--merge without MERGE_HEAD, REBASE_HEAD, CHERRY_PICK_HEAD or REVERT_HEAD?");
+}
+
static void prepare_show_merge(struct rev_info *revs)
{
struct commit_list *bases;
struct commit *head, *other;
struct object_id oid;
const char **prune = NULL;
+ const char *action_head_name;
int i, prune_num = 1; /* counting terminating NULL */
struct index_state *istate = revs->repo->index;
if (repo_get_oid(the_repository, "HEAD", &oid))
die("--merge without HEAD?");
head = lookup_commit_or_die(&oid, "HEAD");
- if (repo_get_oid(the_repository, "MERGE_HEAD", &oid))
- die("--merge without MERGE_HEAD?");
- other = lookup_commit_or_die(&oid, "MERGE_HEAD");
+ action_head_name = get_action_head_name(&oid);
+ other = lookup_commit_or_die(&oid, action_head_name);
add_pending_object(revs, &head->object, "HEAD");
- add_pending_object(revs, &other->object, "MERGE_HEAD");
+ add_pending_object(revs, &other->object, action_head_name);
bases = repo_get_merge_bases(the_repository, head, other);
add_rev_cmdline_list(revs, bases, REV_CMD_MERGE_BASE, UNINTERESTING | BOTTOM);
add_pending_commit_list(revs, bases, UNINTERESTING | BOTTOM);
--
2.39.3 (Apple Git-145)
^ permalink raw reply related
* Re: [DISCUSS] Introducing Rust into the Git project
From: Trevor Gross @ 2024-01-11 23:23 UTC (permalink / raw)
To: rsbecker; +Cc: brian m. carlson, Taylor Blau, Junio C Hamano, Dragan Simic, git
In-Reply-To: <01c101da44d5$175f1100$461d3300$@nexbridge.com>
On Thu, Jan 11, 2024 at 4:28 PM <rsbecker@nexbridge.com> wrote:
>
> The usable compilers and interpreters on NonStop are c89, c99 (what we use for git), c11, perl, and python3 (for the x86 only). The perl and python do not have sufficient modules to do what would be needed by git. The compilers are invoked using a CLI and are not callable using a library. gcc is, for all intents and purposes, not possible - so anything requiring gcc (for example, Rust), cannot be built. There is no back-end pluggable component for any of the compilers.
>
Ah, no pluggable backend is unfortunate. Rust only uses GCC to build
the LLVM backend, it isn't actually needed for the language. It does
link libgcc_s for unwinding and I believe some math symbols, but
unwinding can be disabled and other symbols can come from anywhere.
If you can build mrustc (C++ program) [1] then you can use it to
transpile Rust to C. This is how rustc is bootstrapped, and would be
how you bring it up with a different backend on a new platform.
Still, this probably wouldn't be a solution for git.
[1]: https://github.com/thepowersgang/mrustc
^ 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