* Re: [PATCH] ref-filter.c: sort formatted dates by byte value
From: Victoria Dye @ 2024-02-09 2:46 UTC (permalink / raw)
To: Junio C Hamano, Victoria Dye via GitGitGadget; +Cc: git
In-Reply-To: <xmqqzfwbps43.fsf@gitster.g>
Junio C Hamano wrote:
>> I came across a use case for 'git for-each-ref' at $DAYJOB in which I'd
>> want to sort by a portion of a formatted 'creatordate' (e.g., only the
>> time of day, sans date). When I tried to run something like 'git
>> for-each-ref --sort=creatordate:format:%H:%M:%S',
>
> Hmph, this indeed is interesting ;-)
>
> I wonder if there are other "sort by numeric but the thing could be
> stringified by the end-user" atoms offered by for-each-ref
> machinery. IOW, is the timestamp the only thing that needs this
> fix?
The only non-FIELD_STR atoms other than the date ones are "objectsize" and
"numparent". "objectsize" has an optional ":disk" modifier, but that doesn't
change formatting (just the value of the integer printed). "numparent"
doesn't have any modifiers, it just prints the integer number of parents.
Otherwise, everything is sorted by string value, so I think only the date
atoms have this kind of mismatch between formatted value and sort value.
>
> Thanks.
^ permalink raw reply
* libification: how to avoid symbol collisions?
From: Kyle Lippincott @ 2024-02-09 2:30 UTC (permalink / raw)
To: git
While thinking about libification, I was wondering what we can/need to
do about symbols (specifically functions, since our libraries will
likely have few to no extern variables) that need to escape their
translation unit (.c file) but that we don't want to risk colliding
with symbols from our "host" project.
For any header that we're offering up as an API boundary we can have
prefixed names, but there are symbols from git-compat-util.h with
simple and likely common names like `die`, `usage`, error`, etc. I'm
far from an expert on linkers, but I'm under the impression that even
though we'll only be #including git-compat-util.h in our own .c files
(so the compiler for the host project wouldn't see them), the produced
static library will still be "providing" these symbols unless we mark
them as `static` (and if we mark them as `static`, they can't be used
outside of their translation unit). This means that if the host
project has a version of `die` (or links against yet another library
that does), we run into what C++ calls a One Definition Rule (ODR)
violation: we have two providers of the symbol `die` with different
implementations, and the behavior is undefined (no error needs to be
generated as far as I know).
With dynamic libraries I believe that we have more control over what
gets exposed, but I don't know of functionality for this when linking
statically. I'm assuming there is no such functionality, as projects
like openssl (ty Randall for mentioning this) appear to have a
convention of prefixing the symbols they put in their "public" API
(i.e. in non-internal header files) with things like OSSL_, and of
prefixing the symbols they put in their "private" APIs that can't be
marked as `static` with `ossl_`. I'd love to be wrong about this. :)
If I'm right that this is an issue, does this imply that we'd need to
rename every non-static function in the git codebase that's part of a
library to have a `git_` prefix, even if it won't be used outside of
the git project's own .c files? Is there a solution that doesn't
involve making it so that we have to type `git_` a billion times a day
that's also maintainable? We could try to guess at how likely a name
collision would be and only do this for ones where it's obviously
going to collide, but if we get it wrong, I'm concerned that we'll run
into subtle ODR violations that *at best* erode confidence in our
library, and can actually cause outages, data corruption, and
security/privacy issues.
^ permalink raw reply
* Re: Supporting --no-edit for git rebase --continue
From: brian m. carlson @ 2024-02-09 1:38 UTC (permalink / raw)
To: Orgad Shaneh; +Cc: git
In-Reply-To: <CAGHpTB+mCxvzJ4LDpQrMgHmzigUzcAnRcwMewV0oYKM2HwbNXw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 892 bytes --]
On 2024-02-07 at 20:46:16, Orgad Shaneh wrote:
> Hi,
>
> Is it possible to add --no-edit for git rebase --continue, similar to
> the functionality of this flag for git cherry-pick --continue and
> similar commands?
I haven't checked whether this is actually possible, but I imagine it is
with some work. I think it would be a valuable feature to add, but I
don't think anyone's planning on working on it. Would you be willing to
send a patch? Even if many people think it's a good idea, we're all
busy, and thus it'll only be implemented if someone is willing to pick
it up.
In the meantime, you could try setting `GIT_EDITOR=:` in your
environment (for example, using an alias) like so:
[alias]
rncontinue = "!f() { GIT_EDITOR=: git rebase --continue; };f"
and that can serve as a workaround.
--
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
* Re: cloning the linxu kernel repo at a VPS with small RAM
From: Eric Wong @ 2024-02-09 1:29 UTC (permalink / raw)
To: Toralf Förster; +Cc: git
In-Reply-To: <2f773980-70ec-4ad0-a49c-3ac12c294a39@gmx.de>
Toralf Förster <toralf.foerster@gmx.de> wrote:
> I do wonder if Git could automatically try to deal with only 1.5 GiB
> available RAM?
I have to use pack.threads=1 myself on SMP machines, too.
_SC_AVPHYS_PAGES should probably be accounted for in addition
to _SC_NPROCESSORS_CONF when calculating the default pack.threads value.
Calculating good defaults is hard, though...
I've also been meaning to try the newer tombstone-free khashl
to replace khash in our tree for memory savings:
https://attractivechaos.wordpress.com/2019/12/28/deletion-from-hash-tables-without-tombstones/
Perhaps you (or someone else) can take the lead, there.
^ permalink raw reply
* [PATCH] git: --no-lazy-fetch option
From: Junio C Hamano @ 2024-02-08 23:17 UTC (permalink / raw)
To: git; +Cc: Christian Couder
Sometimes, especially during tests of low level machinery, it is
handy to have a way to disable lazy fetching of objects. This
allows us to say, for example, "git cat-file -e <object-name>", to
see if the object is locally available.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/git.c b/git.c
index 7068a184b0..fd9b0e6a9e 100644
--- a/git.c
+++ b/git.c
@@ -4,6 +4,7 @@
#include "exec-cmd.h"
#include "gettext.h"
#include "help.h"
+#include "object-file.h"
#include "pager.h"
#include "read-cache-ll.h"
#include "run-command.h"
@@ -186,6 +187,8 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)
use_pager = 0;
if (envchanged)
*envchanged = 1;
+ } else if (!strcmp(cmd, "--no-lazy-fetch")) {
+ fetch_if_missing = 0;
} else if (!strcmp(cmd, "--no-replace-objects")) {
disable_replace_refs();
setenv(NO_REPLACE_OBJECTS_ENVIRONMENT, "1", 1);
--
2.43.0-581-g5216f8f5c4
^ permalink raw reply related
* Re: [PATCH v2 0/4] rev-list: allow missing tips with --missing
From: Junio C Hamano @ 2024-02-08 23:15 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Patrick Steinhardt, John Cai, Linus Arver
In-Reply-To: <20240208135055.2705260-1-christian.couder@gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
> # Patch overview
>
> Patches 1/4 (revision: clarify a 'return NULL' in get_reference()),
> 2/4 (oidset: refactor oidset_insert_from_set()) and
> 3/4 (t6022: fix 'test' style and 'even though' typo) are very small
> preparatory cleanups.
>
> Patch 4/4 (rev-list: allow missing tips with --missing=[print|allow*])
> allows git-rev-list(1) with `--missing=<arg>` when <arg> is not
> 'error' to not fail if some tips it is passed are missing.
Thanks. There is an existing test that makes a bad assumption and
fails with these patches. We may need something like this patch as
a preliminary fix before these four patches.
----- >8 ---------- >8 ---------- >8 ---------- >8 -----
Subject: [PATCH] t9210: do not rely on lazy fetching to fail
With "rev-list --missing=print $start", where "$start" is a 40-hex
object name, the object may or may not be lazily fetched from the
promisor. Make sure it fails by forcing dereference of "$start"
at that point.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t9210-scalar.sh | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/t/t9210-scalar.sh b/t/t9210-scalar.sh
index 4432a30d10..428339e342 100755
--- a/t/t9210-scalar.sh
+++ b/t/t9210-scalar.sh
@@ -154,7 +154,14 @@ test_expect_success 'scalar clone' '
test_cmp expect actual &&
test_path_is_missing 1/2 &&
- test_must_fail git rev-list --missing=print $second &&
+
+ # This relies on the fact that the presence of "--missing"
+ # on the command line forces lazy fetching off before
+ # "$second^{blob}" gets parsed. Without "^{blob}", a
+ # bare object name "$second" is taken into the queue and
+ # the command may not fail with a fixed "rev-list --missing".
+ test_must_fail git rev-list --missing=print "$second^{blob}" -- &&
+
git rev-list $second &&
git cat-file blob $second >actual &&
echo "second" >expect &&
--
2.43.0-581-g5216f8f5c4
^ permalink raw reply related
* Re: [PATCH] commit.c: ensure strchrnul() doesn't scan beyond range
From: Junio C Hamano @ 2024-02-08 21:44 UTC (permalink / raw)
To: Jeff King
Cc: René Scharfe, Chandra Pratap via GitGitGadget, git,
Chandra Pratap, Chandra Pratap
In-Reply-To: <20240208214137.GB1090198@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> 1. It is not possible for the buf/len pair we pass to check_nonce() to
> contain a NUL. And thus there is no caller of find_header_mem()
> that can contain an embedded NUL. So switching from strchrnul() to
> just memchr() should be OK there.
Correct.
> 2. That raises the question of whether parse_signed_buffer() has a
> similar walk-too-far problem. ;) The answer is no, because we feed
> it from a strbuf. But it's not a great pattern overall.
True, too.
Thanks.
^ permalink raw reply
* Re: [PATCH] commit.c: ensure strchrnul() doesn't scan beyond range
From: Jeff King @ 2024-02-08 21:41 UTC (permalink / raw)
To: Junio C Hamano
Cc: René Scharfe, Chandra Pratap via GitGitGadget, git,
Chandra Pratap, Chandra Pratap
In-Reply-To: <xmqqil2yn3ey.fsf@gitster.g>
On Thu, Feb 08, 2024 at 11:48:05AM -0800, Junio C Hamano wrote:
> René Scharfe <l.s.r@web.de> writes:
>
> > But anyway: If NULs are of no concern and we currently end parsing when
> > we see one in all cases, why do we need a _mem function at all? The
> > original version of the function, find_commit_header(), should suffice.
> > check_nonce() could be run against the NUL-terminated sigcheck.payload
> > and check_cert_push_options() parses an entire strbuf, so there is no
> > risk of out-of-bounds access.
>
> If I recall correctly, the caller that does not pass strlen() as the
> payload length gives a length that is shorter than the buffer, i.e.
> "stop the parsing here, do not get confused into thinking the
> garbage after this point contains useful payload" was the reason why
> we have a separate "len".
Yes, check_nonce() passes in a length limited by the start of the actual
signature, as determined by parse_signed_buffer(). Though that generally
comes after a blank line, which would also stop find_header() from
parsing further.
But more interestingly: even though we pass a buf/len pair to
parse_signed_buffer(), it then calls get_format_by_sig() which takes
only a NUL-terminated string. So:
1. It is not possible for the buf/len pair we pass to check_nonce() to
contain a NUL. And thus there is no caller of find_header_mem()
that can contain an embedded NUL. So switching from strchrnul() to
just memchr() should be OK there.
2. That raises the question of whether parse_signed_buffer() has a
similar walk-too-far problem. ;) The answer is no, because we feed
it from a strbuf. But it's not a great pattern overall.
-Peff
^ permalink raw reply
* Re: [PATCH] tag: fix sign_buffer() call to create a signed tag
From: Jeff King @ 2024-02-08 21:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sergey Kosukhin
In-Reply-To: <xmqqv86zplr7.fsf@gitster.g>
On Wed, Feb 07, 2024 at 09:29:00PM -0800, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > We could do belt and suspenders by tightening the other callers to
> > only expect negative for errors (but then what should they do when
> > they receive non-zero positive? Should they BUG() out???) while
> > teaching sign_buffer_ssh() that our convention is to return negative
> > for an error, of course, but I am not sure if it that is worth it.
>
> Actually, we could loosen the caller(s) while tightening the
> callee(s), which is the more usual approach we would take in a
> situation like this. Here is what I am tempted to pile on top of
> the patch.
>
> ----- >8 --------- >8 --------- >8 --------- >8 --------- >8 -----
> Subject: [PATCH] ssh signing: signal an error with a negative return value
>
> The other backend for the sign_buffer() function followed our usual
> "an error is signalled with a negative return" convention, but the
> SSH signer did not. Even though we already fixed the caller that
> assumed only a negative return value is an error, tighten the callee
> to signal an error with a negative return as well. This way, the
> callees will be strict on what they produce, while the callers will
> be lenient in what they accept.
Yeah, I think that would possibly lead to fewer surprises and is worth
doing.
-Peff
^ permalink raw reply
* Re: [PATCH 3/3] rev-list: add --allow-missing-tips to be used with --missing=...
From: Linus Arver @ 2024-02-08 20:42 UTC (permalink / raw)
To: Christian Couder
Cc: git, Junio C Hamano, Patrick Steinhardt, John Cai,
Christian Couder
In-Reply-To: <CAP8UFD148VDVto3_NwQcCkRGFZ1qHHDtYTXVxV_=VsOjgqJcbg@mail.gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
> On Wed, Feb 7, 2024 at 9:48 PM Linus Arver <linusa@google.com> wrote:
>> Christian Couder <christian.couder@gmail.com> writes:
>
>> > It actually kind of "works" when you pass blobs or trees. It looks
>> > like the command just doesn't use them (except for checking that they
>> > actually exist) unless options like --objects, --missing=print and
>> > perhaps others are used. So yeah, the doc might need an update, but I
>> > think it could be a separate issue, as it's not new and doesn't depend
>> > on this small series.
>>
>> SG. But also, if there's a way to put invisible (developer-facing, not
>> user facing) comments inside the relevant doc file it might be easy
>> enough to add a to this series.
>
> It might seem easy to add/improve some doc, but there is sometimes
> bikeshedding. So I don't think making this series dependent on such a
> dco update is a good thing for both that doc update and this series. I
> will try to work on such a doc update soon though.
Oh, I did not mean to say you should add doc updates in this series at
all. I was just asking if you could add a comment with "NEEDSWORK" or
similar that only developers will see. Looks like asciidoc does support
such comments that are left out of the published text:
https://docs.asciidoctor.org/asciidoc/latest/comments/. I just tested
with "//" style comments (asciidoc has other styles also, not sure which
one is preferred in our codebase) and running "make" to generate the
docs confirm that we can indeed put in such developer-facing comments.
Back to this topic, you could add something like "// NEEDSWORK: rev-list
can take blob and tree objects also as arguments, not just commits".
This is why I thought it would be easy.
>> > "quarantined objects" refers to the following doc:
>> >
>> > https://www.git-scm.com/docs/git-receive-pack#_quarantine_environment
>> >
>> > So to clarify things, the above paragraph looks like the following now:
>> >
>> > "When such a command is used to find the dependencies of some objects,
>> > for example the dependencies of quarantined objects (see the
>> > "QUARANTINE ENVIRONMENT" section in the git-receive-pack(1)
>> > documentation), it would be better if the command would instead
>> > consider such missing objects, especially commits, in the same way as
>> > other missing objects."
>>
>> This reads much better, and is a good motivation to keep in the log
>> message.
>
> Ok, I have kept it in the V2 I just sent:
>
> https://lore.kernel.org/git/20240208135055.2705260-1-christian.couder@gmail.com/
>
> By the way, sorry for forgetting to use the --in-reply-to=... option
> when I sent it.
NP, thanks for the heads up. See you in the new thread.
>> Aside: it's a bit unfortunate that the meaning of "missing" becomes
>> overloaded slightly here because one could say '$tip == ""' is a
>> "missing" tip becauuse the name is not provided. Subtle. Plus there's
>> some interplay with the "if (get_oid_with_context(...))" case above
>> because we will (?) hit that path if we do pass in "" (empty string arg)
>> as a tip to rev-list. It might be worth saying in the comments in the
>> implementation, something like
>>
>> The term "missing" here means the case where we could not find the object
>> given the object_id. For example, given HEAD~1, its object id (oid)
>> could be 82335b23aa7234320d6f8055243c852e4b6a5ca3. If no real object
>> with this oid exists, it is considered missing. Providing an empty
>> string to rev-list does not touch the "missing tip" codepath.
>>
>> I wrote the above hastily so it may need further edits to make it
>> succinct. But the point is that this definition isn't spelled out in the
>> test case, which makes the "" argument for $tip that much more subtle.
>
> I think this is related to the --missing option in general (which has
> been with us for around 6 years already), not specifically to this
> series, so I think it can be done separately.
Ah, thanks for the added context. I agree.
>> >> OK so you are using this empty string to clear the expect.raw file. If
>> >> that's true then what stops us from doing this at the start of every
>> >> iteration?
>> >
>> > I am not sure what you mean. Both:
>> >
>> > git rev-list --objects --no-object-names HEAD ^$obj >expect.raw
>> >
>> > and:
>> >
>> > >expect.raw #2
>> >
>> > are clearing "expect.raw" as ">expect.raw" is used in both cases.
>> >
>> > If we did the latter at the start of every iteration, then when we do
>> > the former afterwards, we would clear "expect.raw" raw again, while
>> > there is no point in clearing it twice.
>>
>> Yes but doing it that way would separate "set up a clean environment for
>> this test case" from "find the oid of the non-missing tip" from each
>> other in the same if/else stanza, which I believe helps readability.
>
> On one hand it can help readability, but on other hand some people
> interested in test performance might see it as some waste. So I prefer
> not to do it for now.
In most situations I would agree with "let's hurt test performance by
1%, in exchange for better readability". I think this is one such
situation. And also, it's not even clear if we can measure the
performance hit from an extra ">expect.raw" call.
But as this is a small nit, I won't pursue this suggestion further.
>> Now that I have your attention (was this my plan all along? ;) ), I will
>> take this opportunity to ping you directly for a review of my own patch
>> series for the trailers subsystem:
>> https://lore.kernel.org/git/pull.1632.v4.git.1707196348.gitgitgadget@gmail.com/
>> which is in its 4th iteration after many helpful comments from Junio.
>> Please don't let the patch count (28) raise any alarms --- they used to
>> be 10 but I broke them down into smaller steps to ease the review
>> process.
>
> I will try to take a look soon. Thanks for working on improving the
> trailers subsystem!
Thanks!
^ permalink raw reply
* Re: cloning the linxu kernel repo at a VPS with small RAM
From: Dragan Simic @ 2024-02-08 20:35 UTC (permalink / raw)
To: Toralf Förster; +Cc: git
In-Reply-To: <6c4e309aa77e534cffdba9ae56032b99@manjaro.org>
On 2024-02-08 21:16, Dragan Simic wrote:
> On 2024-02-08 18:32, Toralf Förster wrote:
>> Situation:
>>
>> The command
>> git clone
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
>> fails at a virtual server with about 2 GiB RAM under a recent Debian
>> bookworm with git 2.39.2. What works for me:
>> git clone --depth=1
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable
>> cd ./linux
>> git config gc.auto 0
>> git config pack.threads 1
>> git fetch --tags
>> as seen in [1].
>>
>> Q:
>> I do wonder if Git could automatically try to deal with only 1.5 GiB
>> available RAM?
>
> Here's an excerpt from my ~/.bashrc, which sets the things up
> on my Pinebook Pro laptop with an RK3399 SoC and 4 GB of RAM,
> which is also thermally constrained:
>
> # Missing nproc(1) is handled properly
> REASONABLE_THREADS=$(nproc 2> /dev/null || echo 1)
> REASONABLE_THREADS=$((${REASONABLE_THREADS} / 2))
> ((${REASONABLE_THREADS} == 0)) && REASONABLE_THREADS=1
>
> export GIT_CONFIG_COUNT=3
> export GIT_CONFIG_KEY_0='grep.threads'
> export GIT_CONFIG_VALUE_0=${REASONABLE_THREADS}
> export GIT_CONFIG_KEY_1='index.threads'
> export GIT_CONFIG_VALUE_1=${REASONABLE_THREADS}
> export GIT_CONFIG_KEY_2='pack.threads'
> export GIT_CONFIG_VALUE_2=${REASONABLE_THREADS}
>
> export ZSTD_NBTHREADS=${REASONABLE_THREADS}
> unset REASONABLE_THREADS
>
> Obviously, this does a bit more than configuring git only.
>
> Perhaps modifying this to additionally take the amount of RAM
> into the calculation of REASONABLE_THREADS could be a solution
> for your use case?
Actually, perhaps we could provide the following files as part
of the git project, which would take the above-described approach,
and let the distributions package them:
- /etc/profile.d/git.sh
- /etc/profile.d/git.csh
If everyone agrees, I'd we willing to take a crack on these.
Of course, all suggestions and thoughts are more than welcome.
^ permalink raw reply
* Re: [PATCH] tag: fix sign_buffer() call to create a signed tag
From: Jeff King @ 2024-02-08 20:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sergey Kosukhin
In-Reply-To: <xmqq5xyzr6tm.fsf@gitster.g>
On Wed, Feb 07, 2024 at 07:08:37PM -0800, Junio C Hamano wrote:
> > FWIW, I would have gone the other way, and fixed sign_buffer_ssh(). Your
> > solution here is future-proofing the tag code against other
> > sign_buffer_*() functions behaving like ssh. But it is also leaving
> > other sign_buffer() callers to introduce the same bug.
> >
> > Your documentation change at least makes that less likely. But given how
> > much of our code uses the "negative is error" convention, I wouldn't be
> > surprised to see it happen anyway.
>
> Yeah, but other callers are prepared to honor the current return
> value convention used by gpg-interface, so "fixing" sign_buffer_ssh()
> would not give us any future-proofing.
It future-proofs against a hypothetical new sign_buffer() caller (just
like your patch future-proofs against a hypothetical new signing
backend).
> We could do belt and suspenders by tightening the other callers to
> only expect negative for errors (but then what should they do when
> they receive non-zero positive? Should they BUG() out???) while
> teaching sign_buffer_ssh() that our convention is to return negative
> for an error, of course, but I am not sure if it that is worth it.
I'm not sure that's worth it, since we'd only notice if the error
triggered (so writing a test).
-Peff
^ permalink raw reply
* Re: cloning the linxu kernel repo at a VPS with small RAM
From: Dragan Simic @ 2024-02-08 20:16 UTC (permalink / raw)
To: Toralf Förster; +Cc: git
In-Reply-To: <2f773980-70ec-4ad0-a49c-3ac12c294a39@gmx.de>
Hello Toralf,
On 2024-02-08 18:32, Toralf Förster wrote:
> Situation:
>
> The command
> git clone
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
> fails at a virtual server with about 2 GiB RAM under a recent Debian
> bookworm with git 2.39.2. What works for me:
> git clone --depth=1
> https://git.kernel.org/pub/scm/linux/kernel/git/stable
> cd ./linux
> git config gc.auto 0
> git config pack.threads 1
> git fetch --tags
> as seen in [1].
>
> Q:
> I do wonder if Git could automatically try to deal with only 1.5 GiB
> available RAM?
Here's an excerpt from my ~/.bashrc, which sets the things up
on my Pinebook Pro laptop with an RK3399 SoC and 4 GB of RAM,
which is also thermally constrained:
# Missing nproc(1) is handled properly
REASONABLE_THREADS=$(nproc 2> /dev/null || echo 1)
REASONABLE_THREADS=$((${REASONABLE_THREADS} / 2))
((${REASONABLE_THREADS} == 0)) && REASONABLE_THREADS=1
export GIT_CONFIG_COUNT=3
export GIT_CONFIG_KEY_0='grep.threads'
export GIT_CONFIG_VALUE_0=${REASONABLE_THREADS}
export GIT_CONFIG_KEY_1='index.threads'
export GIT_CONFIG_VALUE_1=${REASONABLE_THREADS}
export GIT_CONFIG_KEY_2='pack.threads'
export GIT_CONFIG_VALUE_2=${REASONABLE_THREADS}
export ZSTD_NBTHREADS=${REASONABLE_THREADS}
unset REASONABLE_THREADS
Obviously, this does a bit more than configuring git only.
Perhaps modifying this to additionally take the amount of RAM
into the calculation of REASONABLE_THREADS could be a solution
for your use case?
^ permalink raw reply
* Re: [PATCH] commit.c: ensure strchrnul() doesn't scan beyond range
From: Kyle Lippincott @ 2024-02-08 19:52 UTC (permalink / raw)
To: Junio C Hamano
Cc: René Scharfe, Jeff King, Chandra Pratap via GitGitGadget,
git, Chandra Pratap, Chandra Pratap
In-Reply-To: <xmqqil2yn3ey.fsf@gitster.g>
On Thu, Feb 8, 2024 at 11:48 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> René Scharfe <l.s.r@web.de> writes:
>
> > But anyway: If NULs are of no concern and we currently end parsing when
> > we see one in all cases, why do we need a _mem function at all? The
> > original version of the function, find_commit_header(), should suffice.
> > check_nonce() could be run against the NUL-terminated sigcheck.payload
> > and check_cert_push_options() parses an entire strbuf, so there is no
> > risk of out-of-bounds access.
>
> If I recall correctly, the caller that does not pass strlen() as the
> payload length gives a length that is shorter than the buffer, i.e.
> "stop the parsing here, do not get confused into thinking the
> garbage after this point contains useful payload" was the reason why
> we have a separate "len".
>
I just rediscovered that. I think this probably should be something
that caller (check_nonce) implements, then. Having a _mem function
implies to me (though I'm very new to this codebase) that it supports
embedded NULs, but that's not what's happening here.
^ permalink raw reply
* Re: [PATCH] commit.c: ensure strchrnul() doesn't scan beyond range
From: Junio C Hamano @ 2024-02-08 19:48 UTC (permalink / raw)
To: René Scharfe
Cc: Jeff King, Chandra Pratap via GitGitGadget, git, Chandra Pratap,
Chandra Pratap
In-Reply-To: <8313d9d6-f6bd-4fae-be9c-e7a8129768eb@web.de>
René Scharfe <l.s.r@web.de> writes:
> But anyway: If NULs are of no concern and we currently end parsing when
> we see one in all cases, why do we need a _mem function at all? The
> original version of the function, find_commit_header(), should suffice.
> check_nonce() could be run against the NUL-terminated sigcheck.payload
> and check_cert_push_options() parses an entire strbuf, so there is no
> risk of out-of-bounds access.
If I recall correctly, the caller that does not pass strlen() as the
payload length gives a length that is shorter than the buffer, i.e.
"stop the parsing here, do not get confused into thinking the
garbage after this point contains useful payload" was the reason why
we have a separate "len".
^ permalink raw reply
* git bug
From: Justin Tang @ 2024-02-08 19:32 UTC (permalink / raw)
To: git
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
add a new file to the git directory, untracked. with some path path/to/file
I wanted to use git diff on untracked files, so I added the file as an
empty file to git, with:
git add --intent-to-add path/to/file
Then I wanted to stash my changes, with:
git stash save
What did you expect to happen? (Expected behavior)
My changes to be stashed.
What happened instead? (Actual behavior)
I can't stash my changes, git stash save or git stash save --include-untracked.
I was getting this error:
error: Entry 'path/to/file' not uptodate. Cannot merge. Cannot save
the current worktree state
What's different between what you expected and what actually happened?
umm
Anything else you want to add:
Anything else you want to add:
I 'fixed' this by removing the empty file with git rm -r --cached path/to/file
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
[System Info]
git version:
git version 2.38.4
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 3.10.0-1127.13.1.el7.x86_64 #1 SMP Tue Jun 23 15:46:38
UTC 2020 x86_64
compiler info: gnuc: 10.2
libc info: glibc: 2.17
$SHELL (typically, interactive shell): /bin/bash
[Enabled Hooks]
commit-msg
post-commit
post-rewrite
pre-commit
pre-push
prepare-commit-msg
^ permalink raw reply
* Re: [PATCH] commit.c: ensure strchrnul() doesn't scan beyond range
From: René Scharfe @ 2024-02-08 18:31 UTC (permalink / raw)
To: Jeff King
Cc: Chandra Pratap via GitGitGadget, git, Chandra Pratap,
Chandra Pratap
In-Reply-To: <20240208010040.GB1059751@coredump.intra.peff.net>
Am 08.02.24 um 02:00 schrieb Jeff King:
> On Mon, Feb 05, 2024 at 08:57:46PM +0100, René Scharfe wrote:
>
>> If you want to make the code work with buffers that lack a terminating
>> NUL then you need to replace the strchrnul() call with something that
>> respects buffer lengths. You could e.g. call memchr(). Don't forget
>> to check for NUL to preserve the original behavior. Or you could roll
>> your own custom replacement, perhaps like this:
>
> I'm not sure it is worth retaining the check for NUL. The original
> function added by me in fe6eb7f2c5 (commit: provide a function to find a
> header in a buffer, 2014-08-27) just took a NUL-terminated string, so
> we certainly were not expecting embedded NULs.
>
> In cfc5cf428b (receive-pack.c: consolidate find header logic,
> 2022-01-06) we switched to taking the "len" parameter, but the new
> caller just passes strlen(msg) anyway.
>
> I guess you could argue that before that commit, receive-pack.c's
> find_header() which took a length was buggy to use strchrnul(). It gets
> fed with a push-cert buffer. I guess it's possible for there to be an
> embedded NUL there, but in practice there shouldn't be. If we are
> thinking of malformed or malicious input, it's not clear which behavior
> (finding or not finding a header past a NUL) is more harmful. So all
> things being equal, I would try to reduce the number of special cases
> here by not worrying about NULs.
>
> (Though if somebody really wants to dig, it's possible there's a clever
> dual-parser attack here where "\nfoo\0bar baz" finds the header "bar
> baz" in one parser but not in another).
Good point. A _mem function shouldn't worry about NULs. Its callers
are responsible for that -- if necessary.
No idea what an attacker could do with nonce and push-option headers
with varying visibility. Version detection? Something worse?
But anyway: If NULs are of no concern and we currently end parsing when
we see one in all cases, why do we need a _mem function at all? The
original version of the function, find_commit_header(), should suffice.
check_nonce() could be run against the NUL-terminated sigcheck.payload
and check_cert_push_options() parses an entire strbuf, so there is no
risk of out-of-bounds access.
René
^ permalink raw reply
* Re: [PATCH] prune: mark rebase autostash and orig-head as reachable
From: Junio C Hamano @ 2024-02-08 18:06 UTC (permalink / raw)
To: Phillip Wood via GitGitGadget; +Cc: git, Orgad Shaneh, Phillip Wood
In-Reply-To: <pull.1656.git.1707411636382.gitgitgadget@gmail.com>
"Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com> writes:
> Rebase records the oid of HEAD before rebasing and the commit created by
> "--autostash" in files in the rebase state directory. This means that
> the autostash commit is never reachable from any ref or reflog and when
> rebasing a detached HEAD the original HEAD can become unreachable if the
> user expires HEAD's the reflog while the rebase is running. Fix this by
> reading the relevant files when marking reachable commits.
I do not like this kind of special casing in general, but because
these are our tools' droppings, I am OK to grandfather them in, as
long as we promise ourselves that we will not add more of these
ad-hoc "text files" that record object names, loss of which affects
correctness. They should, like "git bisect", be using proper
references to protect these objects instead, of course.
I agree with you that we might want to add pseudorefs as a starting
points of reachability traversal, but I suspect it would add
unnecessary complexity we would rather not want to deal with.
For example, not GC'ing what is pointed at by lines in FETCH_HEAD is
OK. Excluding those objects that are only reachable from an object
mentioned by a pseudoref, when a new "git fetch" is negotiating with
a remote what objects need to be sent here, might be disastrous, as
the pseudoref that said "this object is here and you can safely
consider everything reachable from it is" will be short-lived and
can go away anytime, and an auto-gc kicking in at a wrong time ...
Thanks.
^ permalink raw reply
* Re: [PATCH v3 4/4] for-each-ref: avoid filtering on empty pattern
From: Junio C Hamano @ 2024-02-08 17:53 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: Karthik Nayak, Phillip Wood, phillip.wood, git
In-Reply-To: <ZcUOP_rWUwymhe5c@ncase>
Patrick Steinhardt <ps@pks.im> writes:
> That's a different problem from the one I have right now. Let's take the
> following sequence of commands:
>
> $ git init repo
> Initialized empty Git repository in /tmp/repo/.git/
> $ git -C repo commit --allow-empty --message message
> [main (root-commit) aa5eec4] message
> $ git -C repo update-ref ref/head/foo HEAD
> $ ls repo/.git/ref/head/foo
> repo/.git/ref/head/foo
>
> Now the fact that you can create "ref/head/foo" is a bug that needs to
> be fixed, no arguing there. The problem is that rectifying this problem
> with the "files" backend is easy -- you look into the repo, notice that
> there's a weird directory, and then "rm -rf" it.
OK.
> But how do you learn about this ref existing with the "reftable" backend
> in the first place? You can't without looking at the binary format --
> there doesn't exist a single command that would allow you to list all
> refs unfiltered. But that is very much required in order to learn about
> misbehaviour and fix it.
I think I have been saying that it is perfectly OK if reftable
backend, being newer and backed by more experience using Git,
rejected any attempt to create anything under "ref/" (to avoid
confusion to those who are reading from sidelines, it should allow
creating "refs/mytool/" for third-party tools to store their own
pointers).
> As I said -- this is a bug, and I agree that it shouldn't happen. But
> bugs happen, and especially with the new reftable format I expect them
> to happen. What I look for in this context is to create the tools to fix
> problems like this, but `--include-root-refs` doesn't. A flag that
> unconditionally returns all refs, regardless of whether they have a bad
> name or not, does address the issue. Think of it of more of a debugging
> tool.
OK, "--include-all-refs" would be fine. And without bugs there
should not be a difference.
Where does "all refs in this worktree" you mentioned fit in this
picture? Should a bogus "ref/foo/bar" be considered to be worktree
specific, or is it an incorrect attempt to create a ref that is
specific to 'foo' worktree that is not the current one and be
filtered out?
^ permalink raw reply
* Re: [PATCH v2 4/4] rev-list: allow missing tips with --missing=[print|allow*]
From: Junio C Hamano @ 2024-02-08 17:44 UTC (permalink / raw)
To: Christian Couder
Cc: git, Patrick Steinhardt, John Cai, Linus Arver, Christian Couder
In-Reply-To: <20240208135055.2705260-5-christian.couder@gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
> The form '--missing=print' is like 'allow-any', but will also print a
> list of the missing objects. Object IDs are prefixed with a ``?'' character.
> ++
> +If some tips passed to the traversal are missing, they will be
> +considered as missing too, and the traversal will ignore them. In case
> +we cannot get their Object ID though, an error will be raised.
Makes sense.
> diff --git a/builtin/rev-list.c b/builtin/rev-list.c
> index b3f4783858..ec9556f135 100644
> --- a/builtin/rev-list.c
> +++ b/builtin/rev-list.c
> @@ -545,6 +545,15 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
> *
> * Let "--missing" to conditionally set fetch_if_missing.
> */
> + /*
> + * NEEDSWORK: These dump loops to look for some options early
> + * are ugly. We really need setup_revisions() to have a
I would drop the "dump" and "ugly" from here. It OK to make value
judgement with such words in casual conversations on a proposed
patch, but when we make a request to future developers to fix our
mess, we should be more objective and stick to the techincal facts,
so that they have better understanding on why we think this area
needs more work.
Perhaps something like:
These loops that attempt to find presence of options without
understanding what the options they are skipping are broken
(e.g., it would not know "--grep --exclude-promisor-objects" is
not triggering "--exclude-promisor-objects" option).
Everything after "We really need" is good (modulo possible grammos),
I think. Thanks for writing it.
> + * mechanism to allow and disallow some sets of options for
> + * different commands (like rev-list, replay, etc). Such
> + * mechanism should do an early parsing of option and be able
> + * to manage the `--exclude-promisor-objects` and `--missing=...`
> + * options below.
> + */
> for (i = 1; i < argc; i++) {
> const char *arg = argv[i];
> if (!strcmp(arg, "--exclude-promisor-objects")) {
> @@ -753,8 +762,12 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
>
> if (arg_print_omitted)
> oidset_init(&omitted_objects, DEFAULT_OIDSET_SIZE);
> - if (arg_missing_action == MA_PRINT)
> + if (arg_missing_action == MA_PRINT) {
> oidset_init(&missing_objects, DEFAULT_OIDSET_SIZE);
> + /* Already add missing tips */
> + oidset_insert_from_set(&missing_objects, &revs.missing_commits);
> + oidset_clear(&revs.missing_commits);
> + }
It is unclear what "already" here refers to, at least to me.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 2/4] oidset: refactor oidset_insert_from_set()
From: Junio C Hamano @ 2024-02-08 17:33 UTC (permalink / raw)
To: Christian Couder
Cc: git, Patrick Steinhardt, John Cai, Linus Arver, Christian Couder
In-Reply-To: <20240208135055.2705260-3-christian.couder@gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
> In a following commit, we will need to add all the oids from a set into
> another set. In "list-objects-filter.c", there is already a static
> function called add_all() to do that.
>
> Let's rename this function oidset_insert_from_set() and move it into
> oidset.{c,h} to make it generally available.
>
> While at it, let's remove a useless `!= NULL`.
Makes sense.
My initial reaction was that copying underlying bits may even be
more efficient, but that was only because silly-me did not realize
that dst can be non-empty when the operation starts. The name of
the function is not "copy oidset" but "insert from set" that makes
it crystal clear what is going on. Good.
^ permalink raw reply
* cloning the linxu kernel repo at a VPS with small RAM
From: Toralf Förster @ 2024-02-08 17:32 UTC (permalink / raw)
To: git
Situation:
The command
git clone
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
fails at a virtual server with about 2 GiB RAM under a recent Debian
bookworm with git 2.39.2. What works for me:
git clone --depth=1
https://git.kernel.org/pub/scm/linux/kernel/git/stable
cd ./linux
git config gc.auto 0
git config pack.threads 1
git fetch --tags
as seen in [1].
Q:
I do wonder if Git could automatically try to deal with only 1.5 GiB
available RAM?
TIA
[1]
https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup/tasks/kernel-git.yaml#L22
--
Toralf
^ permalink raw reply
* Re: [PATCH] prune: mark rebase autostash and orig-head as reachable
From: Eric Sunshine @ 2024-02-08 17:25 UTC (permalink / raw)
To: Phillip Wood via GitGitGadget; +Cc: git, Orgad Shaneh, Phillip Wood
In-Reply-To: <pull.1656.git.1707411636382.gitgitgadget@gmail.com>
On Thu, Feb 8, 2024 at 12:00 PM Phillip Wood via GitGitGadget
<gitgitgadget@gmail.com> wrote:
> Rebase records the oid of HEAD before rebasing and the commit created by
> "--autostash" in files in the rebase state directory. This means that
> the autostash commit is never reachable from any ref or reflog and when
> rebasing a detached HEAD the original HEAD can become unreachable if the
> user expires HEAD's the reflog while the rebase is running. Fix this by
> reading the relevant files when marking reachable commits.
>
> Note that it is possible for the commit recorded in
> .git/rebase-merge/amend to be unreachable but pruning that object does
> not affect the operation of "git rebase --continue" as we're only
> interested in the object id, not in the object itself.
>
> Reported-by: Orgad Shaneh <orgads@gmail.com>
> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
> ---
> diff --git a/reachable.c b/reachable.c
> @@ -30,6 +31,53 @@ static void update_progress(struct connectivity_progress *cp)
> +static int add_one_file(const char *path, struct rev_info *revs)
> +{
> + struct strbuf buf = STRBUF_INIT;
> +
> + if (!read_oneliner(&buf, path, READ_ONELINER_SKIP_IF_EMPTY)) {
> + strbuf_release(&buf);
> + return 0;
> + }
> + strbuf_trim(&buf);
> + if (!get_oid_hex(buf.buf, &oid)) {
> + object = parse_object_or_die(&oid, buf.buf);
> + add_pending_object(revs, object, "");
> + }
> + return 0;
> +}
Is this leaking the strbuf? Should the function instead end with:
strbuf_release(&buf);
return 0;
Also, what is the significance of the return value of this function?
All code paths seem to be returning 0 unconditionally, and the caller
ignores the return value.
> +/* Mark objects recored in rebase state files as reachable. */
s/recored/recorded/
^ permalink raw reply
* Re: [PATCH v3 4/4] for-each-ref: avoid filtering on empty pattern
From: Patrick Steinhardt @ 2024-02-08 17:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Karthik Nayak, Phillip Wood, phillip.wood, git
In-Reply-To: <xmqq7cjeq43t.fsf@gitster.g>
[-- Attachment #1: Type: text/plain, Size: 3958 bytes --]
On Thu, Feb 08, 2024 at 09:04:54AM -0800, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
>
> > ```
> > if (!starts_with(iter->ref.refname, "refs/") &&
> > !(flags & INCLUDE_ROOT_REFS || is_pseudoref(iter->ref.refname)))
> > continue;
> > ```
> >
> > The problem I have is that it still wouldn't end up surfacing all refs
> > which exist in the ref backend while being computationally more
> > expensive. So the original usecase I had in mind when pitching this
> > topic isn't actually addressed.
>
> The reftable format, as a database format, may be capable of having
> "refs/heads/master" and "refs/heads/master/1" at the same time, but
> to be used as a ref backend for Git, it must refrain from surfacing
> both at the same time. I think it is the same deal that it should
> only allow "refs/*", "HEAD", and so called pseudorefs to be stored.
> So INCLUDE_ROOT_REFS should be sufficient as long as the "ref
> creation and update" side is not letting random cruft (e.g.,
> "config") in. Isn't that sufficient?
That's a different problem from the one I have right now. Let's take the
following sequence of commands:
$ git init repo
Initialized empty Git repository in /tmp/repo/.git/
$ git -C repo commit --allow-empty --message message
[main (root-commit) aa5eec4] message
$ git -C repo update-ref ref/head/foo HEAD
$ ls repo/.git/ref/head/foo
repo/.git/ref/head/foo
Now the fact that you can create "ref/head/foo" is a bug that needs to
be fixed, no arguing there. The problem is that rectifying this problem
with the "files" backend is easy -- you look into the repo, notice that
there's a weird directory, and then "rm -rf" it.
But how do you learn about this ref existing with the "reftable" backend
in the first place? You can't without looking at the binary format --
there doesn't exist a single command that would allow you to list all
refs unfiltered. But that is very much required in order to learn about
misbehaviour and fix it.
As I said -- this is a bug, and I agree that it shouldn't happen. But
bugs happen, and especially with the new reftable format I expect them
to happen. What I look for in this context is to create the tools to fix
problems like this, but `--include-root-refs` doesn't. A flag that
unconditionally returns all refs, regardless of whether they have a bad
name or not, does address the issue. Think of it of more of a debugging
tool.
Spelled out like that it brings me a different idea: maybe I'm just
trying to address this in the wrong tool. I plan to introduce ref
backend specific fsck checks, so that could be a better place to warn
about such refs with bad names. Like this we don't erode the tree-shaped
nature by somehow accepting them in some tools, and we make clear that
this is indeed something that shouldn't happen.
> > I know that in theory, the reftable backend shouldn't contain refs other
> > than "refs/" or pseudo-refs anyway. But regardless of that, I think that
> > formulating this in the form of "root refs" is too restrictive and too
> > much focussed on the "files" backend.
>
> It is not "focused on". The ref namespace of Git is tree-shaped,
> period. The shape may have originated from its first ref backend
> implementation's limitation, but as we gain other backends, we are
> not planning to lift such limitations, are we? So we may still say
> "when there is a master branch, you cannot have master/1 branch (due
> to D/F conflict)", even if there is no notion of directory or file
> in a backend implementation backed by a databasy file format. "HEAD"
> and "CHERRY_PICK_HEAD", unlike "refs/tags/v1.0", are at the "root
> level", not only when they are stored in a files backend, but always
> when they are presented to end-users, who can tell that they are not
> inside "refs/".
I agree, and I do not intend to change this.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] sequencer: unset GIT_CHERRY_PICK_HELP for 'exec' commands
From: Junio C Hamano @ 2024-02-08 17:20 UTC (permalink / raw)
To: Vegard Nossum, Phillip Wood; +Cc: Kristoffer Haugsbakk, git, Jonathan Nieder
In-Reply-To: <eaf511ff-f9e0-47ac-ae2e-3de0efa928dd@gmail.com>
Phillip Wood <phillip.wood123@gmail.com> writes:
> I think that typically for small suggestions like that we just add a
> Helped-by: trailer but feel free to add my SOB if you want.
Thanks, both. Here is what I assembled from the pieces.
----- >8 --------- >8 --------- >8 --------- >8 -----
From: Vegard Nossum <vegard.nossum@oracle.com>
Date: Fri, 2 Feb 2024 10:18:50 +0100
Subject: [PATCH] sequencer: unset GIT_CHERRY_PICK_HELP for 'exec' commands
Running "git cherry-pick" as an x-command in the rebase plan loses
the original authorship information.
To fix this, unset GIT_CHERRY_PICK_HELP for 'exec' commands.
Helped-by: Phillip Wood <phillip.wood123@gmail.com>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
sequencer.c | 1 +
t/t3404-rebase-interactive.sh | 12 ++++++++++++
2 files changed, 13 insertions(+)
diff --git a/sequencer.c b/sequencer.c
index d584cac8ed..ed30ceaf8b 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -3647,6 +3647,7 @@ static int do_exec(struct repository *r, const char *command_line)
fprintf(stderr, _("Executing: %s\n"), command_line);
cmd.use_shell = 1;
strvec_push(&cmd.args, command_line);
+ strvec_push(&cmd.env, "GIT_CHERRY_PICK_HELP");
status = run_command(&cmd);
/* force re-reading of the cache */
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index c5f30554c6..84a92d6da0 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -153,6 +153,18 @@ test_expect_success 'rebase -i with the exec command checks tree cleanness' '
git rebase --continue
'
+test_expect_success 'cherry-pick works with rebase --exec' '
+ test_when_finished "git cherry-pick --abort; \
+ git rebase --abort; \
+ git checkout primary" &&
+ echo "exec git cherry-pick G" >todo &&
+ (
+ set_replace_editor todo &&
+ test_must_fail git rebase -i D D
+ ) &&
+ test_cmp_rev G CHERRY_PICK_HEAD
+'
+
test_expect_success 'rebase -x with empty command fails' '
test_when_finished "git rebase --abort ||:" &&
test_must_fail env git rebase -x "" @ 2>actual &&
--
2.43.0-561-g235986be82
^ permalink raw reply related
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