* Re: [PATCH v2] sequencer: remove unreachable exit condition in pick_commits()
From: Junio C Hamano @ 2023-09-13 0:32 UTC (permalink / raw)
To: Phillip Wood; +Cc: Oswald Buddenhagen, git, Johannes Schindelin
In-Reply-To: <7ede7c26-9029-4e4b-81a3-f992eff74124@gmail.com>
Phillip Wood <phillip.wood123@gmail.com> writes:
> On 12/09/2023 11:55, Oswald Buddenhagen wrote:
>> This was introduced by 56dc3ab04 ("sequencer (rebase -i): implement the
>> 'edit' command", 2017-01-02), and was pointless from the get-go: all
>> early exits from the loop above are returns, so todo_list->current ==
>> todo_list->nr is an invariant after the loop.
>> Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
>
> Thanks for updating the commit message, I think it is clearer now
Thanks, both. Queued.
^ permalink raw reply
* Re: [PATCH 1/1] git-grep: improve the --show-function behaviour
From: Junio C Hamano @ 2023-09-13 0:31 UTC (permalink / raw)
To: René Scharfe
Cc: Oleg Nesterov, Ævar Arnfjörð Bjarmason, Calvin Wan,
Carlo Marcelo Arenas Belón, Elijah Newren, Jeff King,
Linus Torvalds, Mathias Krause, Taylor Blau, git, Alexey Gladkov
In-Reply-To: <df05f761-c498-6930-bfd8-265f7e23d8ee@web.de>
René Scharfe <l.s.r@web.de> writes:
>>> To me, this behaviour looks as
>>>
>>> Show the preceding line that contains the function name of
>>> the match, unless the _PREVIOUS_ matching line is a function
>>> name itself.
>
> To me it looks like:
>
> Show the preceding line that contains the function name of
> the match.
>
> ("Show" meaning "show once", not "show for each match again and again".)
>
> Or:
>
> Show the preceding line that contains the function name of
> the match, unless it is already shown for a different
> reason, e.g. as a match or as the function line of a
> previous match.
Wow, that was a mouthful, but matches my understanding. I naïvely
thought "when showing a hit, we may add the line that matches the
function header pattern before the hit even that header line does
not hit the grep pattern. But if the header line does hit the grep
pattern, we do not bother show the same thing twice." was a
reasonable goal to have.
> Indeed that matches the letter of the documentation.
>
>> $ ./git grep --untracked -pn xxx TEST2.c
>> TEST2.c:1:void func(xxx)
>> TEST2.c=1=void func(xxx)
>> TEST2.c:3: use(xxx);
>
> That one as well.
>
>> Or I am totally confused?
>
> No, I think the documentation is wrong. I'd simply remove the part
> after the comma, but there are probably better options.
Documentation may not match the behaviour, but do we know what the
behaviour we want is? To me, the last example that shows the same
line twice (one as a real hit, the other because of "-p") looks a
bit counter-intuitive for the purpose of "help me locate where the
grep hits are". I dunno.
^ permalink raw reply
* Re: [PATCH v2] t3404-rebase-interactive.sh: fix typos in title of a rewording test
From: Junio C Hamano @ 2023-09-13 0:25 UTC (permalink / raw)
To: Phillip Wood; +Cc: Oswald Buddenhagen, git, Phillip Wood
In-Reply-To: <76c36744-b821-450b-9817-e0cd8811de65@gmail.com>
Phillip Wood <phillip.wood123@gmail.com> writes:
> On 12/09/2023 11:42, Oswald Buddenhagen wrote:
>> This test was introduced by commit 0c164ae7a ("rebase -i: add another
>> reword test", 2021-08-20). I didn't quite get what it was meant to do,
>> so here's an explanation from Phillip:
>> The purpose of the test is to ensure that
>> (i) There are no uncommited changes when the editor runs. I.e.,
>> we
>> commit without running the editor and then reword by amending
>> that commit. This ensures that we have the same user experience
>> whether or not the commit was fast-forwarded [1].
>> (ii) That the todo list is re-read after the commit has been
>> reworded.
>> This is to allow the user to update the todo list while the rebase
>> is paused for editing the commit message.
>> [1] https://lore.kernel.org/git/20190812175046.GM20404@szeder.dev/
>> Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
>
> This looks good to me, Thanks
>
> Phillip
Thanks, both. Will queue.
^ permalink raw reply
* Re: [PATCH 1/2] diff-merges: improve --diff-merges documentation
From: Junio C Hamano @ 2023-09-13 0:22 UTC (permalink / raw)
To: Sergey Organov; +Cc: git
In-Reply-To: <87ttrzhmfu.fsf@osv.gnss.ru>
Sergey Organov <sorganov@gmail.com> writes:
>> It is more like that `-p` does not imply `-m` (which used to mean
>> "consider showing the comparison between parent(s) and the child,
>> even for merge commits"), even though newer options like `-c`,
>> `--cc` and others do imply `-m` (simply because they do not make
>> much sense if they are not allowed to work on merges) that may make
>> new people confused.
>
> No, neither --cc nor -c imply -m.
I was only trying to help you polish the text you added to explain
what you called the "legacy feature" to reflect the reason behind
that legacy. As you obviously were not there back then when I made
"--cc" imply "-m" while keeping "-p" not to imply "-m".
Our "git log [--diff-output-options]" logic was (and still is) not
to show the comparison between parents and the child by default for
merge commits even with -p/--raw/--stat (these were what existed and
were common back then) and "git log --raw/--stat/-p" showed the
raw/diffstat/patch after the log message for one-parent commits but
only the log message for merges.
The reason behind that design choice is that Linus (and I and
others) did not find that the patches for merges are as useful as
patches for regular commits. We made "git log -p" to omit
patches for merges that tend to become large.
Side note: the first-parent patch is sort of readable, but
if you are not doing the "--first-parent" traversal (which
is a much later invention, so it wasn't even an option), you
are showing individual commits and their patches while
traversing the side branch, then the first-parent patch of a
merge amounts to the squash of individual changes on the
side branch that got merged. It was deemed redundant
presentation that is just wasteful and harder to grok than
reading individual commits. Worse, the patch against second
and later parent(s) have no real value (it shows how behind
the fork point of the side branch was relative to the tip of
the trunk, which is rarely useful).
But we also wanted to have a mode of "git log -p" that spews
everything to the output that could be used to reconstruct the
history, hence we added "-m" to tell "git log":
By default, you are designed not to show comparison between
parents and the child for merge commit. But when "-m" is
given, do show the comparison for merge commit in the format
that other options given to you, like --raw, --patch,
specifies.
We however didn't have a good idea how to represent such a
comparison between parents and the child, so we chose the most
redundant, verbose, and obvious, which is N pairwise patches with
each of N parents to the child (for a N-parent patch).
Later "--cc" and "-c" came as an alternative way to represent
comparison between parents and the child.
Given that I, together with Linus, invented "--cc" and "-c", taking
inspiration from how Paul Mackerras showed a merge in his 'gitk'
tool, and made the design decision not to require "-m" to get the
output in the format they specify when the "git log" traversal shows
merge commits, I do not know what to say when you repeat that "--cc"
does not imply "-m". It simply is not true.
I think this is the second time you claimed the above after I
explained the same to you, if I am not mistaken. If you do not want
to be corrected, that is fine, and I'll stop wasting my time trying
to correct you.
But I still have to make sure that you (or anybody else) do not
spread misinformation to other users by writing incorrect statements
in documentation patches.
^ permalink raw reply
* Re: [RFC][PATCH 0/32] SHA256 and SHA1 interoperability
From: Eric W. Biederman @ 2023-09-12 21:19 UTC (permalink / raw)
To: brian m. carlson; +Cc: Junio C Hamano, git
In-Reply-To: <ZP+PKa3N1N1PXROM@tapette.crustytoothpaste.net>
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> On 2023-09-11 at 16:13:27, Eric W. Biederman wrote:
>> Junio, brian for the very warm reception of this, it is very
>> encouraging.
>>
>> I am not worried about what it will take time to get the changes I
>> posted into the integration. I had only envisioned them as good enough
>> to get the technical ideas across, and had never envisioned them as
>> being accepted as is.
>>
>> What I am envisioning as my future directions are:
>>
>> - Post non controversial cleanups, so they can be merged.
>> (I can only see about 4 of them the most significant is:
>> bulk-checkin: Only accept blobs)
>>
>> - Sort out the configuration options
>>
>> - Post the smallest patchset I can that will allow testing the code in
>> object-file-convert.c. Unfortunately for that I need configuration
>> options to enable the mapping.
>>
>> In starting to write the tests I have already found a bug in
>> the conversion of tags (an extra newline is added), and I haven't
>> even gotten to testing the tricky bits with signatures.
>
> I wonder if unit tests are a possibility here now that we're starting to
> use them. They're not obligatory, of course, but it may be more
> convenient for you if they turn out to be a suitable option. If not, no
> big deal.
I believe you mean using test-tool and making a very narrow focused test
on just the functionality.
If the number of patches I have to go through before I can test anything
becomes a problem I might go there. Unfortunately it would take some
refactoring to make object-file-convert independent of the object
mapping layer, and that is extra work and is likely to introduces bugs
as anything.
I have managed to get a set of tests working. I am just going through
now and plugging the holes.
My big strategy for testing convert_object_file is to build two
repositories one sha1 and the other sha256 both with compatibility
support enabled. I add a series of objects to those repositories and
compare them to ensure the objects are identical.
It is working well and is finding bugs not just in convert_object_file
but in code such as commit and tag that perform interesting work with
signed commits.
I discovered I had bungled the placement of hash_object_file for
the compatibility hash in commit.
I found that git tag did not yet support building tags with both
hash algorithms.
Right now I am looking at commits with mergetag lines. It is not fun.
The mergetag instead of pointing to the tag objects they include the
body of the tag objects in the commit object. So I have convert
the embedded tag objects from one hash function to another.
Which given the presence of preceding space on every line of
the embedded tag object makes it doubly interesting. Perhaps
someone has already written code to extract the embedded tag.
Or in short everything is moving along steadily.
Eric
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2023, #04; Tue, 12)
From: Philippe Blain @ 2023-09-12 21:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqq34zjnqi8.fsf@gitster.g>
> Le 12 sept. 2023 à 15:25, Junio C Hamano <gitster@pobox.com> a écrit :
>
>>> * pb/complete-commit-trailers (2023-09-07) 1 commit
>>> (merged to 'next' on 2023-09-08 at 842587016d)
>>> + completion: commit: complete configured trailer tokens
>>>
>>> The command-line complation support (in contrib/) learned to
>>> complete "git commit --trailer=" for possible trailer keys.
>>>
>>> Will merge to 'master'.
>>> source: <pull.1583.git.1694108551683.gitgitgadget@gmail.com>
>>>
>>
>> I've incorporate Martin's suggestions so let's wait to merge my v2
>> instead:
>> <pull.1583.v2.git.1694539827.gitgitgadget@gmail.com>
>
> It is too late for a replacement v2 once it is in 'next', though.
Yes of course, this v2 has a second commit on top of top of v1 since v1 was already in next. Maybe my wording was unclear ?
Or do you prefer a new thread for such fix ups ?
Thanks,
Philippe.
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2023, #04; Tue, 12)
From: Junio C Hamano @ 2023-09-12 19:34 UTC (permalink / raw)
To: Phillip Wood; +Cc: git
In-Reply-To: <12c956ea-330d-4441-937f-7885ab519e26@gmail.com>
Phillip Wood <phillip.wood123@gmail.com> writes:
> On 12/09/2023 17:57, Junio C Hamano wrote:
>> * pw/rebase-sigint (2023-09-07) 1 commit
>> - rebase -i: ignore signals when forking subprocesses
>> If the commit log editor or other external programs (spawned via
>> "exec" insn in the todo list) receive internactive signal during
>> "git rebase -i", it caused not just the spawned program but the
>> "Git" process that spawned them, which is often not what the end
>> user intended. "git" learned to ignore SIGINT and SIGQUIT while
>> waiting for these subprocesses.
>> Will merge to 'next'?
>> source: <pull.1581.git.1694080982621.gitgitgadget@gmail.com>
>
> This needs a re-roll to stop it ignoring signals in the child
> c.f. <376d3ea0-a3eb-4b25-8bf2-ca40c4699e26@gmail.com>
Yeah, you're right.
Thanks.
^ permalink raw reply
* [PATCH v3 3/3] test-tool: retire "index-version"
From: Junio C Hamano @ 2023-09-12 19:32 UTC (permalink / raw)
To: git
In-Reply-To: <20230912193235.776292-1-gitster@pobox.com>
As "git update-index --show-index-version" can do the same thing,
the 'index-version' subcommand in the test-tool lost its reason to
exist. Remove it and replace its use with the end-user facing
'git update-index --show-index-version'.
Helped-by: Linus Arver <linusa@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Makefile | 1 -
t/helper/test-index-version.c | 15 ---------------
t/helper/test-tool.c | 1 -
t/helper/test-tool.h | 1 -
t/t1600-index.sh | 2 +-
t/t1700-split-index.sh | 2 +-
t/t2104-update-index-skip-worktree.sh | 6 +++---
7 files changed, 5 insertions(+), 23 deletions(-)
delete mode 100644 t/helper/test-index-version.c
diff --git a/Makefile b/Makefile
index e440728c24..5323c76aa0 100644
--- a/Makefile
+++ b/Makefile
@@ -808,7 +808,6 @@ TEST_BUILTINS_OBJS += test-hash-speed.o
TEST_BUILTINS_OBJS += test-hash.o
TEST_BUILTINS_OBJS += test-hashmap.o
TEST_BUILTINS_OBJS += test-hexdump.o
-TEST_BUILTINS_OBJS += test-index-version.o
TEST_BUILTINS_OBJS += test-json-writer.o
TEST_BUILTINS_OBJS += test-lazy-init-name-hash.o
TEST_BUILTINS_OBJS += test-match-trees.o
diff --git a/t/helper/test-index-version.c b/t/helper/test-index-version.c
deleted file mode 100644
index a06c45c1f8..0000000000
--- a/t/helper/test-index-version.c
+++ /dev/null
@@ -1,15 +0,0 @@
-#include "test-tool.h"
-#include "cache.h"
-
-int cmd__index_version(int argc UNUSED, const char **argv UNUSED)
-{
- struct cache_header hdr;
- int version;
-
- memset(&hdr,0,sizeof(hdr));
- if (read(0, &hdr, sizeof(hdr)) != sizeof(hdr))
- return 0;
- version = ntohl(hdr.hdr_version);
- printf("%d\n", version);
- return 0;
-}
diff --git a/t/helper/test-tool.c b/t/helper/test-tool.c
index abe8a785eb..621ac3dd10 100644
--- a/t/helper/test-tool.c
+++ b/t/helper/test-tool.c
@@ -38,7 +38,6 @@ static struct test_cmd cmds[] = {
{ "hashmap", cmd__hashmap },
{ "hash-speed", cmd__hash_speed },
{ "hexdump", cmd__hexdump },
- { "index-version", cmd__index_version },
{ "json-writer", cmd__json_writer },
{ "lazy-init-name-hash", cmd__lazy_init_name_hash },
{ "match-trees", cmd__match_trees },
diff --git a/t/helper/test-tool.h b/t/helper/test-tool.h
index ea2672436c..a641c3a81d 100644
--- a/t/helper/test-tool.h
+++ b/t/helper/test-tool.h
@@ -32,7 +32,6 @@ int cmd__getcwd(int argc, const char **argv);
int cmd__hashmap(int argc, const char **argv);
int cmd__hash_speed(int argc, const char **argv);
int cmd__hexdump(int argc, const char **argv);
-int cmd__index_version(int argc, const char **argv);
int cmd__json_writer(int argc, const char **argv);
int cmd__lazy_init_name_hash(int argc, const char **argv);
int cmd__match_trees(int argc, const char **argv);
diff --git a/t/t1600-index.sh b/t/t1600-index.sh
index 9368d82f7d..62e7fd1596 100755
--- a/t/t1600-index.sh
+++ b/t/t1600-index.sh
@@ -118,7 +118,7 @@ test_index_version () {
fi &&
git add a &&
echo $EXPECTED_OUTPUT_VERSION >expect &&
- test-tool index-version <.git/index >actual &&
+ git update-index --show-index-version >actual &&
test_cmp expect actual
)
}
diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh
index b4ab166369..a7b7263b35 100755
--- a/t/t1700-split-index.sh
+++ b/t/t1700-split-index.sh
@@ -43,7 +43,7 @@ test_expect_success 'enable split index' '
git config splitIndex.maxPercentChange 100 &&
git update-index --split-index &&
test-tool dump-split-index .git/index >actual &&
- indexversion=$(test-tool index-version <.git/index) &&
+ indexversion=$(git update-index --show-index-version) &&
# NEEDSWORK: Stop hard-coding checksums.
if test "$indexversion" = "4"
diff --git a/t/t2104-update-index-skip-worktree.sh b/t/t2104-update-index-skip-worktree.sh
index b8686aabd3..0bab134d71 100755
--- a/t/t2104-update-index-skip-worktree.sh
+++ b/t/t2104-update-index-skip-worktree.sh
@@ -39,7 +39,7 @@ test_expect_success 'setup' '
'
test_expect_success 'index is at version 2' '
- test "$(test-tool index-version < .git/index)" = 2
+ test "$(git update-index --show-index-version)" = 2
'
test_expect_success 'update-index --skip-worktree' '
@@ -48,7 +48,7 @@ test_expect_success 'update-index --skip-worktree' '
'
test_expect_success 'index is at version 3 after having some skip-worktree entries' '
- test "$(test-tool index-version < .git/index)" = 3
+ test "$(git update-index --show-index-version)" = 3
'
test_expect_success 'ls-files -t' '
@@ -61,7 +61,7 @@ test_expect_success 'update-index --no-skip-worktree' '
'
test_expect_success 'index version is back to 2 when there is no skip-worktree entry' '
- test "$(test-tool index-version < .git/index)" = 2
+ test "$(git update-index --show-index-version)" = 2
'
test_done
--
2.42.0-158-g94e83dcf5b
^ permalink raw reply related
* [PATCH v3 2/3] update-index: add --show-index-version
From: Junio C Hamano @ 2023-09-12 19:32 UTC (permalink / raw)
To: git
In-Reply-To: <20230912193235.776292-1-gitster@pobox.com>
"git update-index --index-version N" is used to set the index format
version to a specific version, but there was no way to query the
current version used in the on-disk index file.
Teach the command a new "--show-index-version" option, and also
teach the "--index-version N" option to report what the version was
when run with the "--verbose" option.
Helped-by: Linus Arver <linusa@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-update-index.txt | 6 +++++-
builtin/update-index.c | 19 ++++++++++++------
t/t2107-update-index-basic.sh | 31 ++++++++++++++++++++++++++++++
3 files changed, 49 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index 71d6ef9457..1271486ae9 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -162,7 +162,8 @@ you will need to handle the situation manually.
Write the resulting index out in the named on-disk format version.
Supported versions are 2, 3 and 4. The current default version is 2
or 3, depending on whether extra features are used, such as
- `git add -N`.
+ `git add -N`. With `--verbose`, also report the version the index
+ file uses before and after this command.
+
Version 4 performs a simple pathname compression that reduces index
size by 30%-50% on large repositories, which results in faster load
@@ -171,6 +172,9 @@ and support for it was added to libgit2 in 2016 and to JGit in 2020.
Older versions of this manual page called it "relatively young", but
it should be considered mature technology these days.
+--show-index-version::
+ Report the index format version used by the on-disk index file.
+ See `--index-version` above.
-z::
Only meaningful with `--stdin` or `--index-info`; paths are
diff --git a/builtin/update-index.c b/builtin/update-index.c
index 5fab9ad2ec..8c3454c1c1 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -1089,6 +1089,8 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
resolve_undo_clear_callback),
OPT_INTEGER(0, "index-version", &preferred_index_format,
N_("write index in this format")),
+ OPT_SET_INT(0, "show-index-version", &preferred_index_format,
+ N_("report on-disk index format version"), -1),
OPT_BOOL(0, "split-index", &split_index,
N_("enable or disable split index")),
OPT_BOOL(0, "untracked-cache", &untracked_cache,
@@ -1181,15 +1183,20 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
getline_fn = nul_term_line ? strbuf_getline_nul : strbuf_getline_lf;
if (preferred_index_format) {
- if (preferred_index_format < INDEX_FORMAT_LB ||
- INDEX_FORMAT_UB < preferred_index_format)
+ if (preferred_index_format < 0) {
+ printf(_("%d\n"), the_index.version);
+ } else if (preferred_index_format < INDEX_FORMAT_LB ||
+ INDEX_FORMAT_UB < preferred_index_format) {
die("index-version %d not in range: %d..%d",
preferred_index_format,
INDEX_FORMAT_LB, INDEX_FORMAT_UB);
-
- if (the_index.version != preferred_index_format)
- the_index.cache_changed |= SOMETHING_CHANGED;
- the_index.version = preferred_index_format;
+ } else {
+ if (the_index.version != preferred_index_format)
+ the_index.cache_changed |= SOMETHING_CHANGED;
+ report(_("index-version: was %d, set to %d"),
+ the_index.version, preferred_index_format);
+ the_index.version = preferred_index_format;
+ }
}
if (read_from_stdin) {
diff --git a/t/t2107-update-index-basic.sh b/t/t2107-update-index-basic.sh
index 89b285fa3a..22f4c92399 100755
--- a/t/t2107-update-index-basic.sh
+++ b/t/t2107-update-index-basic.sh
@@ -111,4 +111,35 @@ test_expect_success '--chmod=+x and chmod=-x in the same argument list' '
test_cmp expect actual
'
+test_expect_success '--index-version' '
+ git commit --allow-empty -m snap &&
+ git reset --hard &&
+ git rm -f -r --cached . &&
+
+ # The default index version is 2 --- update this test
+ # when you change it in the code
+ git update-index --show-index-version >actual &&
+ echo 2 >expect &&
+ test_cmp expect actual &&
+
+ # The next test wants us to be using version 2
+ git update-index --index-version 2 &&
+
+ git update-index --index-version 4 --verbose >actual &&
+ echo "index-version: was 2, set to 4" >expect &&
+ test_cmp expect actual &&
+
+ git update-index --index-version 4 --verbose >actual &&
+ echo "index-version: was 4, set to 4" >expect &&
+ test_cmp expect actual &&
+
+ git update-index --index-version 2 --verbose >actual &&
+ echo "index-version: was 4, set to 2" >expect &&
+ test_cmp expect actual &&
+
+ # non-verbose should be silent
+ git update-index --index-version 4 >actual &&
+ test_must_be_empty actual
+'
+
test_done
--
2.42.0-158-g94e83dcf5b
^ permalink raw reply related
* [PATCH v3 1/3] update-index doc: v4 is OK with JGit and libgit2
From: Junio C Hamano @ 2023-09-12 19:32 UTC (permalink / raw)
To: git
In-Reply-To: <20230912193235.776292-1-gitster@pobox.com>
Being invented in late 2012 no longer makes the index v4 format
"relatively young".
The support for the index version 4 was added to libgit2 with their
5625d86b (index: support index v4, 2016-05-17) and to JGit with
their e9cb0a8e (DirCache: support index V4, 2020-08-10).
Let's update the paragraph that discouraged its use for folks overly
cautious about cross-tool compatibility.
Helped-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Helped-by: Linus Arver <linusa@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-update-index.txt | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index f4bb9c5daf..71d6ef9457 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -166,9 +166,11 @@ you will need to handle the situation manually.
+
Version 4 performs a simple pathname compression that reduces index
size by 30%-50% on large repositories, which results in faster load
-time. Version 4 is relatively young (first released in 1.8.0 in
-October 2012). Other Git implementations such as JGit and libgit2
-may not support it yet.
+time. Git supports it since version 1.8.0, released in October 2012,
+and support for it was added to libgit2 in 2016 and to JGit in 2020.
+Older versions of this manual page called it "relatively young", but
+it should be considered mature technology these days.
+
-z::
Only meaningful with `--stdin` or `--index-info`; paths are
--
2.42.0-158-g94e83dcf5b
^ permalink raw reply related
* [PATCH v3 0/3] "update-index --show-index-version"
From: Junio C Hamano @ 2023-09-12 19:32 UTC (permalink / raw)
To: git
In-Reply-To: <20230818233729.2766281-1-gitster@pobox.com>
Even though there is "test-tool index-version", there wasn't an
officially supported way for end-users to inspect the index version
of an on-disk index. Let's have one.
This iteration takes suggestions by Linus Arver; the tests added by
[2/3] have been clarified.
Junio C Hamano (3):
update-index doc: v4 is OK with JGit and libgit2
update-index: add --show-index-version
test-tool: retire "index-version"
Documentation/git-update-index.txt | 14 ++++++++----
Makefile | 1 -
builtin/update-index.c | 19 ++++++++++------
t/helper/test-index-version.c | 15 -------------
t/helper/test-tool.c | 1 -
t/helper/test-tool.h | 1 -
t/t1600-index.sh | 2 +-
t/t1700-split-index.sh | 2 +-
t/t2104-update-index-skip-worktree.sh | 6 +++---
t/t2107-update-index-basic.sh | 31 +++++++++++++++++++++++++++
10 files changed, 59 insertions(+), 33 deletions(-)
delete mode 100644 t/helper/test-index-version.c
Range-diff against v2:
1: 7bc7f7877d ! 1: 224a72529a update-index doc: v4 is OK with JGit and libgit2
@@ Commit message
cautious about cross-tool compatibility.
Helped-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
+ Helped-by: Linus Arver <linusa@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
## Documentation/git-update-index.txt ##
@@ Documentation/git-update-index.txt: you will need to handle the situation manual
-may not support it yet.
+time. Git supports it since version 1.8.0, released in October 2012,
+and support for it was added to libgit2 in 2016 and to JGit in 2020.
-+Older editions of this manual page called it "relatively young", but
++Older versions of this manual page called it "relatively young", but
+it should be considered mature technology these days.
+
2: 33c924f893 ! 2: bd3fc76b3f update-index: add --show-index-version
@@ Metadata
## Commit message ##
update-index: add --show-index-version
- "git update-index --version N" is used to set the index format
+ "git update-index --index-version N" is used to set the index format
version to a specific version, but there was no way to query the
current version used in the on-disk index file.
@@ Commit message
teach the "--index-version N" option to report what the version was
when run with the "--verbose" option.
+ Helped-by: Linus Arver <linusa@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
## Documentation/git-update-index.txt ##
@@ Documentation/git-update-index.txt: you will need to handle the situation manual
Supported versions are 2, 3 and 4. The current default version is 2
or 3, depending on whether extra features are used, such as
- `git add -N`.
-+ `git add -N`. With `--verbose` option, also reports the
-+ version the index file uses before and after this command.
++ `git add -N`. With `--verbose`, also report the version the index
++ file uses before and after this command.
+
Version 4 performs a simple pathname compression that reduces index
size by 30%-50% on large repositories, which results in faster load
@@ Documentation/git-update-index.txt: and support for it was added to libgit2 in 2016 and to JGit in 2020.
- Older editions of this manual page called it "relatively young", but
+ Older versions of this manual page called it "relatively young", but
it should be considered mature technology these days.
+--show-index-version::
@@ builtin/update-index.c: int cmd_update_index(int argc, const char **argv, const
OPT_INTEGER(0, "index-version", &preferred_index_format,
N_("write index in this format")),
+ OPT_SET_INT(0, "show-index-version", &preferred_index_format,
-+ N_("show index format version"), -1),
++ N_("report on-disk index format version"), -1),
OPT_BOOL(0, "split-index", &split_index,
N_("enable or disable split index")),
OPT_BOOL(0, "untracked-cache", &untracked_cache,
@@ t/t2107-update-index-basic.sh: test_expect_success '--chmod=+x and chmod=-x in t
+test_expect_success '--index-version' '
+ git commit --allow-empty -m snap &&
+ git reset --hard &&
++ git rm -f -r --cached . &&
+
-+ git update-index --index-version 2 >actual &&
-+ test_must_be_empty actual &&
-+
++ # The default index version is 2 --- update this test
++ # when you change it in the code
+ git update-index --show-index-version >actual &&
+ echo 2 >expect &&
+ test_cmp expect actual &&
+
++ # The next test wants us to be using version 2
++ git update-index --index-version 2 &&
++
+ git update-index --index-version 4 --verbose >actual &&
+ echo "index-version: was 2, set to 4" >expect &&
-+ test_cmp expect actual
++ test_cmp expect actual &&
++
++ git update-index --index-version 4 --verbose >actual &&
++ echo "index-version: was 4, set to 4" >expect &&
++ test_cmp expect actual &&
++
++ git update-index --index-version 2 --verbose >actual &&
++ echo "index-version: was 4, set to 2" >expect &&
++ test_cmp expect actual &&
++
++ # non-verbose should be silent
++ git update-index --index-version 4 >actual &&
++ test_must_be_empty actual
+'
+
test_done
3: 137ec82973 ! 3: d1144a8240 test-tool: retire "index-version"
@@ Commit message
test-tool: retire "index-version"
As "git update-index --show-index-version" can do the same thing,
- the test-tool lost its reason to exist.
+ the 'index-version' subcommand in the test-tool lost its reason to
+ exist. Remove it and replace its use with the end-user facing
+ 'git update-index --show-index-version'.
+ Helped-by: Linus Arver <linusa@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
## Makefile ##
--
2.42.0-158-g94e83dcf5b
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2023, #04; Tue, 12)
From: Junio C Hamano @ 2023-09-12 19:25 UTC (permalink / raw)
To: Philippe Blain; +Cc: git
In-Reply-To: <2579735c-d0cd-d159-8cdb-3348c808b9ef@gmail.com>
Philippe Blain <levraiphilippeblain@gmail.com> writes:
> Hi Junio,
>
> Le 2023-09-12 à 12:57, Junio C Hamano a écrit :
>
>> * pb/completion-aliases-doc (2023-09-11) 1 commit
>> - completion: improve doc for complex aliases
>>
>> Clarify how "alias.foo = : git cmd ; aliased-command-string" should
>> be spelled with necessary whitespaces around punctuation marks to
>> work.
>>
>> Will merge to 'next'.
>> source: <pull.1585.git.1694274592854.gitgitgadget@gmail.com>
>
> Thanks, I just sent a v2 so let's make sure this is what you merge:
> <pull.1585.v2.git.1694538135853.gitgitgadget@gmail.com>
OK. Thanks for a heads-up _before_ it hits 'next'.
>> * pb/complete-commit-trailers (2023-09-07) 1 commit
>> (merged to 'next' on 2023-09-08 at 842587016d)
>> + completion: commit: complete configured trailer tokens
>>
>> The command-line complation support (in contrib/) learned to
>> complete "git commit --trailer=" for possible trailer keys.
>>
>> Will merge to 'master'.
>> source: <pull.1583.git.1694108551683.gitgitgadget@gmail.com>
>>
>
> I've incorporate Martin's suggestions so let's wait to merge my v2
> instead:
> <pull.1583.v2.git.1694539827.gitgitgadget@gmail.com>
It is too late for a replacement v2 once it is in 'next', though.
^ permalink raw reply
* Re: [PATCH v2 2/3] update-index: add --show-index-version
From: Junio C Hamano @ 2023-09-12 19:01 UTC (permalink / raw)
To: Linus Arver; +Cc: git
In-Reply-To: <owlybke8kkcf.fsf@fine.c.googlers.com>
Linus Arver <linusa@google.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> "git update-index --version N" is used to set the index format
>
> s/--version/--index-version
Good eyes.
>> + `git add -N`. With `--verbose` option, also reports the
>
> How about
>
> `git add -N`. With `--verbose`, also report the
Yup, that is much better.
>> OPT_INTEGER(0, "index-version", &preferred_index_format,
>> N_("write index in this format")),
>> + OPT_SET_INT(0, "show-index-version", &preferred_index_format,
>> + N_("show index format version"), -1),
>
> How about
>
> "show on-disk index format version"
OK. The entry before that says "write" and it makes it clear enough
that it is talking about the "on-disk" thing, hence "write index" is
sufficient. The readers, who do not know the "format version"
matters only on-disk and does not matter once the index data gets
slurped into memory, would benefit with "on-disk index" here. I
will also take your "show" -> "report" suggestion.
>> diff --git a/t/t2107-update-index-basic.sh b/t/t2107-update-index-basic.sh
>> index 89b285fa3a..c78d1e9396 100755
>> --- a/t/t2107-update-index-basic.sh
>> +++ b/t/t2107-update-index-basic.sh
>> @@ -111,4 +111,20 @@ test_expect_success '--chmod=+x and chmod=-x in the same argument list' '
>> test_cmp expect actual
>> '
>>
>> +test_expect_success '--index-version' '
>> + git commit --allow-empty -m snap &&
>> + git reset --hard &&
>
> Not sure why this "git reset --hard" is needed here --- is it to clear
> out state from previous test cases? If so, perhaps it's better to run
> this as the very first command in this test case?
>
> But this also makes me wonder why "git commit --allow-empty -m snap" is
> even necessary (if we already have a git repo)?
There is no commit yet in this repository at this point, which means
that "reset --hard [HEAD]" cannot be the first command. There are
newly added paths in the index, some of which are further modified
in the working tree. Creating a snapshot commit will record what is
in the index, and a hard reset will make the contents of the working
tree match exactly what was in the index, reverting the modification
made to some paths in the working tree.
Having said that, we may further want to tighten these "clean the
slate" steps for later tests (read on).
>> + git update-index --index-version 2 >actual &&
>> + test_must_be_empty actual &&
>
> Before we do "--index-version 2", it may be desirable to run the
> "--show-index-version" flag first to see what we have before modifying
> it with "2".
That was what I specifically wanted to avoid. I am not interested
in testing what the default version of the day is. The only thing
this invocation cares about is to (try to) use the version 2; it
will be detected as a failure if the next show-index-version
reported something else ...
>> + git update-index --show-index-version >actual &&
>> + echo 2 >expect &&
>> + test_cmp expect actual &&
... which is checked here.
>> + git update-index --index-version 4 --verbose >actual &&
>> + echo "index-version: was 2, set to 4" >expect &&
>> + test_cmp expect actual
And how a transition is reported with --verbose is tested here.
>> +'
>
> How about adding this check below to check what happens if the newly-set
> version is the same as the existing version?
>
> git update-index --index-version 4 --verbose >actual &&
> echo "index-version: was 4, set to 4" >expect &&
> test_cmp expect actual
>
> And also how about a similar check, but for downgrading from a higher
> version number to a lower one?
>
> git update-index --index-version 2 --verbose >actual &&
> echo "index-version: was 4, set to 2" >expect &&
> test_cmp expect actual
I assumed that the flipping between versions without --verbose had
adequate coverage and the tests this patch adds were solely about
reporting with the "--verbose" option. It seems there is no such
test coverage, so these may want to be added. Perhaps we should
flip from 2 to 4 _without_ verbose and make sure we are still silent
as well.
Testing downgrading an index with unspecified [*] contents from 3
(or higher) to 2 would be unwise, as such a conversion may or may
not work depending on the contents. I will tighten the "clean the
slate" steps and add downgrades to the list, as the initial "try to
set to 2" may not even work with unknown contents in the index.
Thanks.
[Footnote]
* This is in a very late part of the test script and the state
previous tests left us will change over time.
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2023, #04; Tue, 12)
From: Phillip Wood @ 2023-09-12 18:30 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <xmqqpm2npbwy.fsf@gitster.g>
On 12/09/2023 17:57, Junio C Hamano wrote:
> * pw/rebase-sigint (2023-09-07) 1 commit
> - rebase -i: ignore signals when forking subprocesses
>
> If the commit log editor or other external programs (spawned via
> "exec" insn in the todo list) receive internactive signal during
> "git rebase -i", it caused not just the spawned program but the
> "Git" process that spawned them, which is often not what the end
> user intended. "git" learned to ignore SIGINT and SIGQUIT while
> waiting for these subprocesses.
>
> Will merge to 'next'?
> source: <pull.1581.git.1694080982621.gitgitgadget@gmail.com>
This needs a re-roll to stop it ignoring signals in the child c.f.
<376d3ea0-a3eb-4b25-8bf2-ca40c4699e26@gmail.com>
Thanks
Phillip
^ permalink raw reply
* Re: [PATCH 1/1] git-grep: improve the --show-function behaviour
From: René Scharfe @ 2023-09-12 18:07 UTC (permalink / raw)
To: Oleg Nesterov, Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Calvin Wan,
Carlo Marcelo Arenas Belón, Elijah Newren, Jeff King,
Linus Torvalds, Mathias Krause, Taylor Blau, git, Alexey Gladkov
In-Reply-To: <20230912135124.GA11315@redhat.com>
Am 12.09.23 um 15:51 schrieb Oleg Nesterov:
> On 09/12, Oleg Nesterov wrote:
>>
>> René, Junio,
>>
>> I don't like the fact we can't understand each other ;) Could you
>> please explain why do you think this patch should update the docs?
Good thinking! And thank you for the examples and you patience!
>> Please forget about my patch for the moment. Lets start from the very
>> beginning:
>>
>> -p::
>> --show-function::
>> Show the preceding line that contains the function name of
>> the match, unless the matching line is a function name itself.
>>
>> and in my opinion, it is the current behaviour that doesn't match the
>> documentation.>>
>> -------------------------------------------------------------------------
>>
>> $ cat TEST1.c
>> void func1()
>> {
>> }
>> void func2()
>> {
>> }
>>
>> $ git grep --untracked -pn func2 TEST1.c
>> TEST1.c=1=void func1()
>> TEST1.c:4:void func2()
>>
>> in this case the matching line is "void func2()" and it is also a function
>> name itself, in this case git-grep should not show "=void func1()" which is
>> "the preceding line that contains the function name of the match.
Makes sense.
>> But it does.
Drat! ;)
The option -p came from diff(1). I thought diff change lines equivalent
to grep match lines and hunk headers to the new = lines. What does diff
do with the example file?
$ diff -U0 -p TEST1.c <(sed s/2/3/ TEST1.c)
--- TEST1.c 2023-09-12 17:59:04
+++ /dev/fd/11 2023-09-12 18:54:03
@@ -4 +4 @@ void func1()
-void func2()
+void func3()
It shows func1 in the hunk header, i.e. the next function line before
the changed line. So that is at least consistent between git grep and
the original -p.
The analogy breaks when it comes to how often a function line is shown:
hunk headers for multiple changes in the same function show the same
function line, but git grep doesn't repeat function lines. I did that
on purpose, possibly because doesn't have an equivalent of hunk headers
and only allows selecting and showing a subset of the lines of a file.
Except it actually does have the -- lines for separating match contexts,
which are kind of similar. That looks a bit weird currently:
$ git grep --untracked -C1 -np func2 TEST1.c
TEST1.c=1=void func1()
--
TEST1.c-3-}
TEST1.c:4:void func2()
TEST1.c-5-{
The function line is separated from the match plus context, but you
could argue that they belong together.
>> So perhaps git-grep needs another change, something like
>>
>> if (match_funcname(opt, gs, bol, end_of_line(...)))
>> return;
>>
>> at the start of show_funcname_line(), but my patch does not change this
>> behaviour.
Yes, to make it match the documentation it would need something like
that. (Though I'd add a match_funcname() call before the
show_funcname_line() call in grep_source_1() instead, as it already has
the eol value.)
>>
>> --------------------------------------------------------------------------
>>
>> $ cat TEST2.c
>> void func(xxx)
>> {
>> use(xxx);
>> }
>>
>> $ git grep --untracked -pn xxx TEST2.c
>> TEST2.c:1:void func(xxx)
>> TEST2.c:3: use(xxx)
>>
>> the 2nd match is use(xxx) and it is not a function name itself, in this
>> case git-grep should "Show the preceding line that contains the function
>> name of the match.
>>
>> But it doesn't.
The corresponding function line (line 1) is shown, as a match (with a
colon). No function line is shown for the first match because it
doesn't have any, being the first line of the file. So this matches the
documentation at least.
>> To me, this behaviour looks as
>>
>> Show the preceding line that contains the function name of
>> the match, unless the _PREVIOUS_ matching line is a function
>> name itself.
To me it looks like:
Show the preceding line that contains the function name of
the match.
("Show" meaning "show once", not "show for each match again and again".)
Or:
Show the preceding line that contains the function name of
the match, unless it is already shown for a different
reason, e.g. as a match or as the function line of a
previous match.
>> Now, with my patch we have
>>
>> $ ./git grep --untracked -pn xxx TEST2.c
>> TEST2.c:1:void func(xxx)
>> TEST2.c=1=void func(xxx)
>> TEST2.c:3: use(xxx);
>>
>> and unless I am totatlly confused this does match the documentation.
>
> So, just in case, please see V2 below. In my opinion it _fixes_ the
> current behaviour. With this patch
>
> $ ./git grep --untracked -pn func2 TEST1.c
> TEST1.c:4:void func2()
Indeed that matches the letter of the documentation.
> $ ./git grep --untracked -pn xxx TEST2.c
> TEST2.c:1:void func(xxx)
> TEST2.c=1=void func(xxx)
> TEST2.c:3: use(xxx);
That one as well.
> Or I am totally confused?
No, I think the documentation is wrong. I'd simply remove the part
after the comma, but there are probably better options.
René
^ permalink raw reply
* Re: [PATCH] diff --stat: add config option to limit filename width
From: Dragan Simic @ 2023-09-12 17:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqbke7pb8z.fsf@gitster.g>
On 2023-09-12 19:11, Junio C Hamano wrote:
> Dragan Simic <dsimic@manjaro.org> writes:
>
>>> Someday, as a follow-up after the dust from this topic settles, we
>>> would probably want to look at how these rev.diffopt.* members are
>>> initialized and refactor the common code out to a helper. It would
>>> allow us to instead of doing this ...
>>
>> Another good point. If you agree, I'd prefer to have my patch
>> accepted and merged as-is, ...
>
> That is exactly what I meant by "follow-up after the dust settles".
>
> All of the "we should probably do this and that in the future" are
> called #leftoverbits comments. Food for thought, something people
> can use to find inspiration for areas they may want to work on, that
> has no impact to how "complete" the current patch being discussed
> is.
Sounds great, thank you. I already have a couple of code cleanups to
work on, which I'll do in the following days and send the patches.
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2023, #04; Tue, 12)
From: Philippe Blain @ 2023-09-12 17:32 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <xmqqpm2npbwy.fsf@gitster.g>
Hi Junio,
Le 2023-09-12 à 12:57, Junio C Hamano a écrit :
> * pb/completion-aliases-doc (2023-09-11) 1 commit
> - completion: improve doc for complex aliases
>
> Clarify how "alias.foo = : git cmd ; aliased-command-string" should
> be spelled with necessary whitespaces around punctuation marks to
> work.
>
> Will merge to 'next'.
> source: <pull.1585.git.1694274592854.gitgitgadget@gmail.com>
Thanks, I just sent a v2 so let's make sure this is what you merge:
<pull.1585.v2.git.1694538135853.gitgitgadget@gmail.com>
> * pb/complete-commit-trailers (2023-09-07) 1 commit
> (merged to 'next' on 2023-09-08 at 842587016d)
> + completion: commit: complete configured trailer tokens
>
> The command-line complation support (in contrib/) learned to
> complete "git commit --trailer=" for possible trailer keys.
>
> Will merge to 'master'.
> source: <pull.1583.git.1694108551683.gitgitgadget@gmail.com>
>
I've incorporate Martin's suggestions so let's wait to merge my v2
instead:
<pull.1583.v2.git.1694539827.gitgitgadget@gmail.com>
^ permalink raw reply
* [PATCH v2 2/2] completion: commit: complete trailers tokens more robustly
From: Philippe Blain via GitGitGadget @ 2023-09-12 17:30 UTC (permalink / raw)
To: git
Cc: ZheNing Hu, Martin Ågren, Philippe Blain, Philippe Blain,
Philippe Blain
In-Reply-To: <pull.1583.v2.git.1694539827.gitgitgadget@gmail.com>
From: Philippe Blain <levraiphilippeblain@gmail.com>
In the previous commit, we added support for completing configured
trailer tokens in 'git commit --trailer'.
Make the implementation more robust by:
- using '__git' instead of plain 'git', as the rest of the completion
script does
- using a stricter pattern for --get-regexp to avoid false hits
- using 'cut' and 'rev' instead of 'awk' to account for tokens including
dots.
Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index b5eb75aadc5..c23465886e0 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1679,7 +1679,7 @@ __git_untracked_file_modes="all no normal"
__git_trailer_tokens ()
{
- git config --name-only --get-regexp trailer.\*.key | awk -F. '{print $2}'
+ __git config --name-only --get-regexp '^trailer\..*\.key$' | cut -d. -f 2- | rev | cut -d. -f2- | rev
}
_git_commit ()
--
gitgitgadget
^ permalink raw reply related
* [PATCH v2 0/2] completion: commit: complete configured trailer tokens
From: Philippe Blain via GitGitGadget @ 2023-09-12 17:30 UTC (permalink / raw)
To: git; +Cc: ZheNing Hu, Martin Ågren, Philippe Blain, Philippe Blain
In-Reply-To: <pull.1583.git.1694108551683.gitgitgadget@gmail.com>
v2: This series adds support for completing configured trailer tokens in
'git commit --trailer'.
Changes since v1:
* added all Martin's suggestions as an additional commit on top since
pb/complete-commit-trailer is already in next.
Philippe Blain (2):
completion: commit: complete configured trailer tokens
completion: commit: complete trailers tokens more robustly
contrib/completion/git-completion.bash | 9 +++++++++
1 file changed, 9 insertions(+)
base-commit: 1fc548b2d6a3596f3e1c1f8b1930d8dbd1e30bf3
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1583%2Fphil-blain%2Fcompletion-commit-trailers-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1583/phil-blain/completion-commit-trailers-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/1583
Range-diff vs v1:
1: a31d7a29af9 = 1: a31d7a29af9 completion: commit: complete configured trailer tokens
-: ----------- > 2: 9cb33c20294 completion: commit: complete trailers tokens more robustly
--
gitgitgadget
^ permalink raw reply
* [PATCH v2 1/2] completion: commit: complete configured trailer tokens
From: Philippe Blain via GitGitGadget @ 2023-09-12 17:30 UTC (permalink / raw)
To: git
Cc: ZheNing Hu, Martin Ågren, Philippe Blain, Philippe Blain,
Philippe Blain
In-Reply-To: <pull.1583.v2.git.1694539827.gitgitgadget@gmail.com>
From: Philippe Blain <levraiphilippeblain@gmail.com>
Since 2daae3d1d1 (commit: add --trailer option, 2021-03-23), 'git
commit' can add trailers to commit messages. To make that feature more
pleasant to use at the command line, update the Bash completion code to
offer configured trailer tokens.
Add a __git_trailer_tokens function to list the configured trailers
tokens, and use it in _git_commit to suggest the configured tokens,
suffixing the completion words with ':' so that the user only has to add
the trailer value.
Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
---
contrib/completion/git-completion.bash | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 133ec92bfae..b5eb75aadc5 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1677,6 +1677,11 @@ _git_clone ()
__git_untracked_file_modes="all no normal"
+__git_trailer_tokens ()
+{
+ git config --name-only --get-regexp trailer.\*.key | awk -F. '{print $2}'
+}
+
_git_commit ()
{
case "$prev" in
@@ -1701,6 +1706,10 @@ _git_commit ()
__gitcomp "$__git_untracked_file_modes" "" "${cur##--untracked-files=}"
return
;;
+ --trailer=*)
+ __gitcomp_nl "$(__git_trailer_tokens)" "" "${cur##--trailer=}" ":"
+ return
+ ;;
--*)
__gitcomp_builtin commit
return
--
gitgitgadget
^ permalink raw reply related
* Re: [PATCH v2 1/3] update-index doc: v4 is OK with JGit and libgit2
From: Junio C Hamano @ 2023-09-12 17:14 UTC (permalink / raw)
To: Linus Arver; +Cc: git
In-Reply-To: <owlyfs3kkmzd.fsf@fine.c.googlers.com>
Linus Arver <linusa@google.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
> ...
>> +Older editions of this manual page called it "relatively young", but
>
> Nit: s/editions/versions because typically "edition" means a version of
> physically published text (such as books).
This text belonging to the manual, that was exactly the reason why I
used that word, but ...
> Also I don't think we use the
> word "edition" anywhere else in our codebase.
... I think "version" is just fine. Will fix.
Thanks.
^ permalink raw reply
* Re: [PATCH] diff --stat: add config option to limit filename width
From: Junio C Hamano @ 2023-09-12 17:11 UTC (permalink / raw)
To: Dragan Simic; +Cc: git
In-Reply-To: <487bd30e5a4cdcea8697393eb36ce3f3@manjaro.org>
Dragan Simic <dsimic@manjaro.org> writes:
>> Someday, as a follow-up after the dust from this topic settles, we
>> would probably want to look at how these rev.diffopt.* members are
>> initialized and refactor the common code out to a helper. It would
>> allow us to instead of doing this ...
>
> Another good point. If you agree, I'd prefer to have my patch
> accepted and merged as-is, ...
That is exactly what I meant by "follow-up after the dust settles".
All of the "we should probably do this and that in the future" are
called #leftoverbits comments. Food for thought, something people
can use to find inspiration for areas they may want to work on, that
has no impact to how "complete" the current patch being discussed
is.
^ permalink raw reply
* Re: [PATCH v2] revision: add `--ignore-missing-links` user option
From: Taylor Blau @ 2023-09-12 17:07 UTC (permalink / raw)
To: Karthik Nayak; +Cc: git, gitster
In-Reply-To: <20230912155820.136111-1-karthik.188@gmail.com>
On Tue, Sep 12, 2023 at 05:58:20PM +0200, Karthik Nayak wrote:
> The revision backend is used by multiple porcelain commands such as
> git-rev-list(1) and git-log(1). The backend currently supports ignoring
> missing links by setting the `ignore_missing_links` bit. This allows the
> revision walk to skip any objects links which are missing. Expose this
> bit via an `--ignore-missing-links` user option.
>
> A scenario where this option would be used is to find the boundary
> objects between different object directories. Consider a repository with
> a main object directory (GIT_OBJECT_DIRECTORY) and one or more alternate
> object directories (GIT_ALTERNATE_OBJECT_DIRECTORIES). In such a
> repository, enabling this option along with the `--boundary` option for
> while disabling the alternate object directory allows us to find the
> boundary objects between the main and alternate object directory.
>
> Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
> ---
>
> Changes from v1:
> 1. Changes in the commit message and option description to be more specific
> and list why and what the changes are.
> 2. Ensure the new option also works with the existing `--objects` options.
> 3. More specific testing for boundary commit.
>
> Range diff against v1:
>
> 1: c0a4dca9b0 ! 1: e3f4d85732 revision: add `--ignore-missing-links` user option
> @@ Commit message
> The revision backend is used by multiple porcelain commands such as
> git-rev-list(1) and git-log(1). The backend currently supports ignoring
> missing links by setting the `ignore_missing_links` bit. This allows the
> - revision walk to skip any objects links which are missing.
> + revision walk to skip any objects links which are missing. Expose this
> + bit via an `--ignore-missing-links` user option.
>
> - Currently there is no way to use git-rev-list(1) to traverse the objects
> - of the main object directory (GIT_OBJECT_DIRECTORY) and print the
> - boundary objects when moving from the main object directory to the
> - alternate object directories (GIT_ALTERNATE_OBJECT_DIRECTORIES).
> -
> - By exposing this new flag `--ignore-missing-links`, users can set the
> - required env variables (GIT_OBJECT_DIRECTORY and
> - GIT_ALTERNATE_OBJECT_DIRECTORIES) along with the `--boundary` flag to
> - find the boundary objects between object directories.
> + A scenario where this option would be used is to find the boundary
> + objects between different object directories. Consider a repository with
> + a main object directory (GIT_OBJECT_DIRECTORY) and one or more alternate
> + object directories (GIT_ALTERNATE_OBJECT_DIRECTORIES). In such a
> + repository, enabling this option along with the `--boundary` option for
> + while disabling the alternate object directory allows us to find the
> + boundary objects between the main and alternate object directory.
>
> Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
>
> @@ Documentation/rev-list-options.txt: explicitly.
> the bad input was not given.
>
> +--ignore-missing-links::
> -+ When an object points to another object that is missing, pretend as if the
> -+ link did not exist. These missing links are not written to stdout unless
> -+ the --boundary flag is passed.
> ++ During traversal, if an object that is referenced does not
> ++ exist, instead of dying of a repository corruption, pretend as
> ++ if the reference itself does not exist. Running the command
> ++ with the `--boundary` option makes these missing commits,
> ++ together with the commits on the edge of revision ranges
> ++ (i.e. true boundary objects), appear on the output, prefixed
> ++ with '-'.
> +
> ifndef::git-rev-list[]
> --bisect::
> Pretend as if the bad bisection ref `refs/bisect/bad`
>
> + ## builtin/rev-list.c ##
> +@@ builtin/rev-list.c: static int finish_object(struct object *obj, const char *name UNUSED,
> + {
> + struct rev_list_info *info = cb_data;
> + if (oid_object_info_extended(the_repository, &obj->oid, NULL, 0) < 0) {
> +- finish_object__ma(obj);
> ++ if (!info->revs->ignore_missing_links)
> ++ finish_object__ma(obj);
> + return 1;
> + }
> + if (info->revs->verify_objects && !obj->parsed && obj->type != OBJ_COMMIT)
> +
> ## revision.c ##
> @@ revision.c: static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
> revs->limited = 1;
> @@ t/t6022-rev-list-alternates.sh (new)
> +test_expect_success 'create repository and alternate directory' '
> + git init main &&
> + test_commit_bulk -C main 5 &&
> ++ BOUNDARY_COMMIT=$(git -C main rev-parse HEAD) &&
> + mkdir alt &&
> + mv main/.git/objects/* alt &&
> + GIT_ALTERNATE_OBJECT_DIRECTORIES=$PWD/alt test_commit_bulk --start=6 -C main 5
> +'
> +
> -+# When the alternate odb is provided, all commits are listed.
> ++# when the alternate odb is provided, all commits are listed along with the boundary
> ++# commit.
> +test_expect_success 'rev-list passes with alternate object directory' '
> -+ GIT_ALTERNATE_OBJECT_DIRECTORIES=$PWD/alt test_stdout_line_count = 10 git -C main rev-list HEAD
> ++ GIT_ALTERNATE_OBJECT_DIRECTORIES=$PWD/alt git -C main rev-list HEAD >actual &&
> ++ test_stdout_line_count = 10 cat actual &&
> ++ grep $BOUNDARY_COMMIT actual
> +'
> +
> +# When the alternate odb is not provided, rev-list fails since the 5th commit's
> @@ t/t6022-rev-list-alternates.sh (new)
> +'
> +
> +# With `--ignore-missing-links`, we stop the traversal when we encounter a
> -+# missing link.
> ++# missing link. The boundary commit is not listed as we haven't used the
> ++# `--boundary` options.
> +test_expect_success 'rev-list only prints main odb commits with --ignore-missing-links' '
> -+ test_stdout_line_count = 5 git -C main rev-list --ignore-missing-links HEAD
> ++ git -C main rev-list --ignore-missing-links HEAD >actual &&
> ++ test_stdout_line_count = 5 cat actual &&
> ++ ! grep -$BOUNDARY_COMMIT actual
> +'
> +
> +# With `--ignore-missing-links` and `--boundary`, we can even print those boundary
> +# commits.
> +test_expect_success 'rev-list prints boundary commit with --ignore-missing-links' '
> -+ git -C main rev-list --ignore-missing-links --boundary HEAD >list-output &&
> -+ test_stdout_line_count = 6 cat list-output &&
> -+ test_stdout_line_count = 1 cat list-output | grep "^-"
> ++ git -C main rev-list --ignore-missing-links --boundary HEAD >actual &&
> ++ test_stdout_line_count = 6 cat actual &&
> ++ grep -$BOUNDARY_COMMIT actual
> ++'
> ++
> ++# The `--ignore-missing-links` option should ensure that git-rev-list(1) doesn't
> ++# fail when used alongside `--objects` when a tree is missing.
> ++test_expect_success 'rev-list --ignore-missing-links works with missing tree' '
> ++ echo "foo" >main/file &&
> ++ git -C main add file &&
> ++ GIT_ALTERNATE_OBJECT_DIRECTORIES=$PWD/alt git -C main commit -m"commit 11" &&
> ++ TREE_OID=$(git -C main rev-parse HEAD^{tree}) &&
> ++ mkdir alt/${TREE_OID:0:2} &&
> ++ mv main/.git/objects/${TREE_OID:0:2}/${TREE_OID:2} alt/${TREE_OID:0:2}/ &&
> ++ git -C main rev-list --ignore-missing-links --objects HEAD >actual &&
> ++ ! grep $TREE_OID actual
> ++'
> ++
> ++# Similar to above, it should also work when a blob is missing.
> ++test_expect_success 'rev-list --ignore-missing-links works with missing blob' '
> ++ echo "bar" >main/file &&
> ++ git -C main add file &&
> ++ GIT_ALTERNATE_OBJECT_DIRECTORIES=$PWD/alt git -C main commit -m"commit 12" &&
> ++ BLOB_OID=$(git -C main rev-parse HEAD:file) &&
> ++ mkdir alt/${BLOB_OID:0:2} &&
> ++ mv main/.git/objects/${BLOB_OID:0:2}/${BLOB_OID:2} alt/${BLOB_OID:0:2}/ &&
> ++ git -C main rev-list --ignore-missing-links --objects HEAD >actual &&
> ++ ! grep $BLOB_OID actual
> +'
> +
> +test_done
>
>
> Documentation/rev-list-options.txt | 9 ++++
> builtin/rev-list.c | 3 +-
> revision.c | 2 +
> t/t6022-rev-list-alternates.sh | 75 ++++++++++++++++++++++++++++++
> 4 files changed, 88 insertions(+), 1 deletion(-)
> create mode 100755 t/t6022-rev-list-alternates.sh
>
> diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
> index a4a0cb93b2..8ee713db3d 100644
> --- a/Documentation/rev-list-options.txt
> +++ b/Documentation/rev-list-options.txt
> @@ -227,6 +227,15 @@ explicitly.
> Upon seeing an invalid object name in the input, pretend as if
> the bad input was not given.
>
> +--ignore-missing-links::
> + During traversal, if an object that is referenced does not
> + exist, instead of dying of a repository corruption, pretend as
> + if the reference itself does not exist. Running the command
> + with the `--boundary` option makes these missing commits,
> + together with the commits on the edge of revision ranges
> + (i.e. true boundary objects), appear on the output, prefixed
> + with '-'.
> +
> ifndef::git-rev-list[]
> --bisect::
> Pretend as if the bad bisection ref `refs/bisect/bad`
> diff --git a/builtin/rev-list.c b/builtin/rev-list.c
> index ff715d6918..5239d83c76 100644
> --- a/builtin/rev-list.c
> +++ b/builtin/rev-list.c
> @@ -266,7 +266,8 @@ static int finish_object(struct object *obj, const char *name UNUSED,
> {
> struct rev_list_info *info = cb_data;
> if (oid_object_info_extended(the_repository, &obj->oid, NULL, 0) < 0) {
> - finish_object__ma(obj);
> + if (!info->revs->ignore_missing_links)
> + finish_object__ma(obj);
> return 1;
> }
> if (info->revs->verify_objects && !obj->parsed && obj->type != OBJ_COMMIT)
> diff --git a/t/t6022-rev-list-alternates.sh b/t/t6022-rev-list-alternates.sh
> new file mode 100755
> index 0000000000..08d9ffde5f
> --- /dev/null
> +++ b/t/t6022-rev-list-alternates.sh
> @@ -0,0 +1,75 @@
> +#!/bin/sh
> +
> +test_description='handling of alternates in rev-list'
> +
> +TEST_PASSES_SANITIZE_LEAK=true
> +. ./test-lib.sh
> +
> +# We create 5 commits and move them to the alt directory and
> +# create 5 more commits which will stay in the main odb.
> +test_expect_success 'create repository and alternate directory' '
> + git init main &&
We don't necessarily have to initialize a repository, as the test suite
already does so for us. So we may want to write this instead as:
test_commit_bulk 5 &&
git clone --reference=. --shared . alt &&
test_commit_bulk -C alt --start=6 5
> +# when the alternate odb is provided, all commits are listed along with the boundary
> +# commit.
> +test_expect_success 'rev-list passes with alternate object directory' '
> + GIT_ALTERNATE_OBJECT_DIRECTORIES=$PWD/alt git -C main rev-list HEAD >actual &&
> + test_stdout_line_count = 10 cat actual &&
> + grep $BOUNDARY_COMMIT actual
> +'
Here, I think we'd want to make sure that we have not just 10 lines of
output, but that they are the 10 that we expect, like so:
git -C alt rev-list --all --objects --no-object-names >actual.raw &&
{
git rev-list --all --objects --no-object-names &&
git -C alt rev-list --all --objects --no-object-names --not \
--alternate-refs
} >expect.raw &&
sort actual.raw >actual &&
sort expect.raw >expect &&
test_cmp expect actual
When reviewing this and tweaking some of the tests locally, I found it
useful to have some convenience functions like "hide_alternates" and
"show_alternates" to control whether or not "alt" could see its
alternate or not.
From my review locally, the resulting changes (which can be applied
directly on top of your patch here look like):
--- 8< ---
diff --git a/t/t6022-rev-list-alternates.sh b/t/t6022-rev-list-alternates.sh
index 08d9ffde5f..ef4231b2de 100755
--- a/t/t6022-rev-list-alternates.sh
+++ b/t/t6022-rev-list-alternates.sh
@@ -8,68 +8,86 @@ TEST_PASSES_SANITIZE_LEAK=true
# We create 5 commits and move them to the alt directory and
# create 5 more commits which will stay in the main odb.
test_expect_success 'create repository and alternate directory' '
- git init main &&
- test_commit_bulk -C main 5 &&
- BOUNDARY_COMMIT=$(git -C main rev-parse HEAD) &&
- mkdir alt &&
- mv main/.git/objects/* alt &&
- GIT_ALTERNATE_OBJECT_DIRECTORIES=$PWD/alt test_commit_bulk --start=6 -C main 5
+ test_commit_bulk 5 &&
+ git clone --reference=. --shared . alt &&
+ test_commit_bulk --start=6 -C alt 5
'
# when the alternate odb is provided, all commits are listed along with the boundary
# commit.
test_expect_success 'rev-list passes with alternate object directory' '
- GIT_ALTERNATE_OBJECT_DIRECTORIES=$PWD/alt git -C main rev-list HEAD >actual &&
- test_stdout_line_count = 10 cat actual &&
- grep $BOUNDARY_COMMIT actual
+ git -C alt rev-list --all --objects --no-object-names >actual.raw &&
+ {
+ git rev-list --all --objects --no-object-names &&
+ git -C alt rev-list --all --objects --no-object-names --not \
+ --alternate-refs
+ } >expect.raw &&
+ sort actual.raw >actual &&
+ sort expect.raw >expect &&
+ test_cmp expect actual
'
+alt=alt/.git/objects/info/alternates
+
+hide_alternates () {
+ test -f "$alt.bak" || mv "$alt" "$alt.bak"
+}
+
+show_alternates () {
+ test -f "$alt" || mv "$alt.bak" "$alt"
+}
+
# When the alternate odb is not provided, rev-list fails since the 5th commit's
# parent is not present in the main odb.
test_expect_success 'rev-list fails without alternate object directory' '
- test_must_fail git -C main rev-list HEAD
+ hide_alternates &&
+ test_must_fail git -C alt rev-list HEAD
'
# With `--ignore-missing-links`, we stop the traversal when we encounter a
# missing link. The boundary commit is not listed as we haven't used the
# `--boundary` options.
test_expect_success 'rev-list only prints main odb commits with --ignore-missing-links' '
- git -C main rev-list --ignore-missing-links HEAD >actual &&
- test_stdout_line_count = 5 cat actual &&
- ! grep -$BOUNDARY_COMMIT actual
+ hide_alternates &&
+
+ git -C alt rev-list --objects --no-object-names \
+ --ignore-missing-links HEAD >actual.raw &&
+ git -C alt cat-file --batch-check="%(objectname)" \
+ --batch-all-objects >expect.raw &&
+
+ sort actual.raw >actual &&
+ sort expect.raw >expect &&
+ test_cmp expect actual
'
# With `--ignore-missing-links` and `--boundary`, we can even print those boundary
# commits.
test_expect_success 'rev-list prints boundary commit with --ignore-missing-links' '
- git -C main rev-list --ignore-missing-links --boundary HEAD >actual &&
- test_stdout_line_count = 6 cat actual &&
- grep -$BOUNDARY_COMMIT actual
+ git -C alt rev-list --ignore-missing-links --boundary HEAD >got &&
+ grep "^-$(git rev-parse HEAD)" got
'
-# The `--ignore-missing-links` option should ensure that git-rev-list(1) doesn't
-# fail when used alongside `--objects` when a tree is missing.
-test_expect_success 'rev-list --ignore-missing-links works with missing tree' '
- echo "foo" >main/file &&
- git -C main add file &&
- GIT_ALTERNATE_OBJECT_DIRECTORIES=$PWD/alt git -C main commit -m"commit 11" &&
- TREE_OID=$(git -C main rev-parse HEAD^{tree}) &&
- mkdir alt/${TREE_OID:0:2} &&
- mv main/.git/objects/${TREE_OID:0:2}/${TREE_OID:2} alt/${TREE_OID:0:2}/ &&
- git -C main rev-list --ignore-missing-links --objects HEAD >actual &&
- ! grep $TREE_OID actual
+test_expect_success "setup for rev-list --ignore-missing-links with missing objects" '
+ show_alternates &&
+ test_commit -C alt 11
'
-# Similar to above, it should also work when a blob is missing.
-test_expect_success 'rev-list --ignore-missing-links works with missing blob' '
- echo "bar" >main/file &&
- git -C main add file &&
- GIT_ALTERNATE_OBJECT_DIRECTORIES=$PWD/alt git -C main commit -m"commit 12" &&
- BLOB_OID=$(git -C main rev-parse HEAD:file) &&
- mkdir alt/${BLOB_OID:0:2} &&
- mv main/.git/objects/${BLOB_OID:0:2}/${BLOB_OID:2} alt/${BLOB_OID:0:2}/ &&
- git -C main rev-list --ignore-missing-links --objects HEAD >actual &&
- ! grep $BLOB_OID actual
-'
+for obj in "HEAD^{tree}" "HEAD:11.t"
+do
+ # The `--ignore-missing-links` option should ensure that git-rev-list(1)
+ # doesn't fail when used alongside `--objects` when a tree/blob is
+ # missing.
+ test_expect_success "rev-list --ignore-missing-links with missing $type" '
+ oid="$(git -C alt rev-parse $obj)" &&
+ path="alt/.git/objects/$(test_oid_to_path $oid)" &&
+
+ mv "$path" "$path.hidden" &&
+ test_when_finished "mv $path.hidden $path" &&
+
+ git -C alt rev-list --ignore-missing-links --objects HEAD \
+ >actual &&
+ ! grep $oid actual
+ '
+done
test_done
--- >8 ---
Thanks,
Taylor
^ permalink raw reply related
* Re: [PATCH v3] diff-lib: Fix check_removed when fsmonitor is on
From: Junio C Hamano @ 2023-09-12 17:07 UTC (permalink / raw)
To: Josip Sokcevic; +Cc: jonathantanmy, git, git
In-Reply-To: <CAJiyOijMvqK184wFgoXFyX5kmURkX3k2OmuiBpArikj26iHpMA@mail.gmail.com>
Josip Sokcevic <sokcevic@google.com> writes:
> Yes, I agree we should optimize this in a follow up. One thing I'm not
> sure about is if we should try to construct `struct stat` using
> `cache_index`, or we should check for `CE_FSMONITOR_VALID` in a way
> that `stat` would no longer be needed for those code paths.
Good point.
It seems to be entirely doable, even though the stench from the
abstraction layer violation may be horrible.
ie_match_stat(), which is called by match_stat_with_submodule(),
does pay attention to CE_FSMONITOR_VALID bit, so none of the members
of struct stat matters when the bit is set. But the bit is not set,
all members that fill_stat_data() and ce_match_stat_basic() care
about do matter. Other code that follows callers of check_removed()
do care about at least .st_mode member, and I suspect that in the
current code .st_mode is the only member that gets looked at.
So after all, I think your original "fix" was correct, but it took
us some time to figure out why it was, which means we would want to
explain it in the log message for developers who would want to touch
the same area in the future.
Thanks.
^ permalink raw reply
* What's cooking in git.git (Sep 2023, #04; Tue, 12)
From: Junio C Hamano @ 2023-09-12 17:07 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]
* js/systemd-timers-wsl-fix (2023-09-11) 1 commit
- maintenance(systemd): support the Windows Subsystem for Linux
Update "git maintainance" timers' implementation based on systemd
timers to work with WSL.
Will merge to 'next'.
source: <pull.1586.git.1694334620260.gitgitgadget@gmail.com>
* kh/range-diff-notes (2023-09-11) 1 commit
- range-diff: treat notes like `log`
"git range-diff --notes=foo" compared "log --notes=foo --notes" of
the two ranges, instead of using just the specified notes tree.
source: <a37dfb3748e23b4f5081bc9a3c80a5c546101f1d.1694383248.git.code@khaugsbakk.name>
* pw/diff-no-index-from-named-pipes (2023-09-11) 1 commit
- diff --no-index: fix -R with stdin
"git diff --no-index -R <(one) <(two)" did not work correctly,
which has been corrected.
Will merge to 'next'.
source: <22fdfa3b-f90e-afcc-667c-705fb7670245@web.de>
* rs/parse-options-value-int (2023-09-11) 2 commits
- parse-options: use and require int pointer for OPT_CMDMODE
- parse-options: add int value pointer to struct option
A bit of type safety for the "value" pointer used in the
parse-options API.
source: <e6d8a291-03de-cfd3-3813-747fc2cad145@web.de>
* so/diff-merges-d (2023-09-11) 2 commits
- diff-merges: introduce '-d' option
- diff-merges: improve --diff-merges documentation
Teach a new "-d" option that shows the patch against the first
parent for merge commits (which is "--diff-merges=first-parent -p").
source: <20230909125446.142715-1-sorganov@gmail.com>
* js/diff-cached-fsmonitor-fix (2023-09-11) 1 commit
- diff-lib: fix check_removed when fsmonitor is on
"git diff --cached" codepath did not fill the necessary stat
information for a file when fsmonitor knows it is clean and ended
up behaving as if it is not clean, which has been corrected.
Will merge to 'next'.
source: <20230911170901.49050-2-sokcevic@google.com>
* pb/completion-aliases-doc (2023-09-11) 1 commit
- completion: improve doc for complex aliases
Clarify how "alias.foo = : git cmd ; aliased-command-string" should
be spelled with necessary whitespaces around punctuation marks to
work.
Will merge to 'next'.
source: <pull.1585.git.1694274592854.gitgitgadget@gmail.com>
--------------------------------------------------
[Stalled]
* tk/cherry-pick-sequence-requires-clean-worktree (2023-06-01) 1 commit
- cherry-pick: refuse cherry-pick sequence if index is dirty
"git cherry-pick A" that replays a single commit stopped before
clobbering local modification, but "git cherry-pick A..B" did not,
which has been corrected.
Expecting a reroll.
cf. <999f12b2-38d6-f446-e763-4985116ad37d@gmail.com>
source: <pull.1535.v2.git.1685264889088.gitgitgadget@gmail.com>
--------------------------------------------------
[Cooking]
* cc/repack-sift-filtered-objects-to-separate-pack (2023-09-11) 9 commits
. gc: add `gc.repackFilterTo` config option
. repack: implement `--filter-to` for storing filtered out objects
. gc: add `gc.repackFilter` config option
. repack: add `--filter=<filter-spec>` option
. pack-bitmap-write: rebuild using new bitmap when remapping
. repack: refactor finding pack prefix
. repack: refactor finishing pack-objects command
. t/helper: add 'find-pack' test-tool
. pack-objects: allow `--filter` without `--stdout`
"git repack" machinery learns to pay attention to the "--filter="
option.
May need to wait until tb/repack-existing-packs-cleanup stablizes.
source: <20230911150618.129737-1-christian.couder@gmail.com>
* la/trailer-cleanups (2023-09-11) 6 commits
- trailer: use offsets for trailer_start/trailer_end
- trailer: rename *_DEFAULT enums to *_UNSPECIFIED
- trailer: teach find_patch_start about --no-divider
- trailer: split process_command_line_args into separate functions
- trailer: split process_input_file into separate pieces
- trailer: separate public from internal portion of trailer_iterator
Code clean-up.
Will merge to 'next'.
source: <pull.1563.v2.git.1694240177.gitgitgadget@gmail.com>
* so/diff-doc-for-patch-update (2023-09-06) 1 commit
(merged to 'next' on 2023-09-07 at 6da5e9defd)
+ doc/diff-options: fix link to generating patch section
References from description of the `--patch` option in various
manual pages have been simplified and improved.
Will merge to 'master'.
source: <87msxzpybo.fsf_-_@osv.gnss.ru>
* tb/repack-existing-packs-cleanup (2023-09-06) 8 commits
- builtin/repack.c: extract common cruft pack loop
- builtin/repack.c: drop `DELETE_PACK` macro
- builtin/repack.c: store existing cruft packs separately
- builtin/repack.c: extract `has_existing_non_kept_packs()`
- builtin/repack.c: extract redundant pack cleanup for existing packs
- builtin/repack.c: extract redundant pack cleanup for --geometric
- builtin/repack.c: extract marking packs for deletion
- builtin/repack.c: extract structure to store existing packs
The code to keep track of existing packs in the repository while
repacking has been refactored.
Will merge to 'next'?
source: <cover.1693946195.git.me@ttaylorr.com>
* pb/complete-commit-trailers (2023-09-07) 1 commit
(merged to 'next' on 2023-09-08 at 842587016d)
+ completion: commit: complete configured trailer tokens
The command-line complation support (in contrib/) learned to
complete "git commit --trailer=" for possible trailer keys.
Will merge to 'master'.
source: <pull.1583.git.1694108551683.gitgitgadget@gmail.com>
* pw/rebase-sigint (2023-09-07) 1 commit
- rebase -i: ignore signals when forking subprocesses
If the commit log editor or other external programs (spawned via
"exec" insn in the todo list) receive internactive signal during
"git rebase -i", it caused not just the spawned program but the
"Git" process that spawned them, which is often not what the end
user intended. "git" learned to ignore SIGINT and SIGQUIT while
waiting for these subprocesses.
Will merge to 'next'?
source: <pull.1581.git.1694080982621.gitgitgadget@gmail.com>
* rs/grep-no-no-or (2023-09-07) 1 commit
(merged to 'next' on 2023-09-08 at 33849032bc)
+ grep: reject --no-or
"git grep -e A --no-or -e B" is accepted, even though the negation
of "or" did not mean anything, which has been tightened.
Will merge to 'master'.
source: <6aeb0ebe-0fea-ccd3-089a-ee0b5b5baf10@web.de>
* js/complete-checkout-t (2023-09-08) 1 commit
(merged to 'next' on 2023-09-08 at 461bb28fbd)
+ completion(switch/checkout): treat --track and -t the same
The completion script (in contrib/) has been taught to treat the
"-t" option to "git checkout" and "git switch" just like the
"--track" option, to complete remote-tracking branches.
Will merge to 'master'.
source: <pull.1584.git.1694176123471.gitgitgadget@gmail.com>
* cw/git-std-lib (2023-09-11) 7 commits
- SQUASH???
- git-std-lib: add test file to call git-std-lib.a functions
- git-std-lib: introduce git standard library
- parse: create new library for parsing strings and env values
- config: correct bad boolean env value error message
- wrapper: remove dependency to Git-specific internal file
- hex-ll: split out functionality from hex
Another libification effort.
Needs more work.
cf. <xmqqy1hfrk6p.fsf@gitster.g>
source: <20230908174134.1026823-1-calvinwan@google.com>
* cc/git-replay (2023-09-07) 15 commits
- replay: stop assuming replayed branches do not diverge
- replay: add --contained to rebase contained branches
- replay: add --advance or 'cherry-pick' mode
- replay: disallow revision specific options and pathspecs
- replay: use standard revision ranges
- replay: make it a minimal server side command
- replay: remove HEAD related sanity check
- replay: remove progress and info output
- replay: add an important FIXME comment about gpg signing
- replay: don't simplify history
- replay: introduce pick_regular_commit()
- replay: die() instead of failing assert()
- replay: start using parse_options API
- replay: introduce new builtin
- t6429: remove switching aspects of fast-rebase
source: <20230907092521.733746-1-christian.couder@gmail.com>
* la/trailer-test-and-doc-updates (2023-09-07) 13 commits
- trailer doc: <token> is a <key> or <keyAlias>, not both
- trailer doc: separator within key suppresses default separator
- trailer doc: emphasize the effect of configuration variables
- trailer --unfold help: prefer "reformat" over "join"
- trailer --parse docs: add explanation for its usefulness
- trailer --only-input: prefer "configuration variables" over "rules"
- trailer --parse help: expose aliased options
- trailer --no-divider help: describe usual "---" meaning
- trailer: trailer location is a place, not an action
- trailer doc: narrow down scope of --where and related flags
- trailer: add tests to check defaulting behavior with --no-* flags
- trailer test description: this tests --where=after, not --where=before
- trailer tests: make test cases self-contained
Test coverage for trailers has been improved.
source: <pull.1564.v3.git.1694125209.gitgitgadget@gmail.com>
* ak/pretty-decorate-more (2023-08-21) 8 commits
(merged to 'next' on 2023-09-07 at 6f5e14cef2)
+ decorate: use commit color for HEAD arrow
+ pretty: add pointer and tag options to %(decorate)
+ pretty: add %(decorate[:<options>]) format
+ decorate: color each token separately
+ decorate: avoid some unnecessary color overhead
+ decorate: refactor format_decorations()
+ pretty-formats: enclose options in angle brackets
+ pretty-formats: define "literal formatting code"
"git log --format" has been taught the %(decorate) placeholder.
Will merge to 'master'.
source: <20230820185009.20095-1-andy.koppe@gmail.com>
* bc/more-git-var (2023-09-05) 1 commit
(merged to 'next' on 2023-09-06 at d8af32874c)
+ var: avoid a segmentation fault when `HOME` is unset
Fix-up for a topic that already has graduated.
Will merge to 'master'.
source: <pull.1580.git.1693808487058.gitgitgadget@gmail.com>
* ks/ref-filter-sort-numerically (2023-09-05) 1 commit
(merged to 'next' on 2023-09-06 at aa4d156366)
+ ref-filter: sort numerically when ":size" is used
"git for-each-ref --sort='contents:size'" sorts the refs according
to size numerically, giving a ref that points at a blob twelve-byte
(12) long before showing a blob hundred-byte (100) long.
Will merge to 'master'.
source: <20230902090155.8978-1-five231003@gmail.com>
* ob/sequencer-reword-error-message (2023-09-05) 1 commit
(merged to 'next' on 2023-09-06 at c5154b7aa2)
+ sequencer: fix error message on failure to copy SQUASH_MSG
Update an error message (which would probably never been seen).
Will merge to 'master'.
source: <20230903151132.739136-1-oswald.buddenhagen@gmx.de>
* rs/grep-parseopt-simplify (2023-09-05) 1 commit
(merged to 'next' on 2023-09-06 at 249b69cfd2)
+ grep: use OPT_INTEGER_F for --max-depth
Simplify use of parse-options API a bit.
Will merge to 'master'.
source: <4d2eb736-4f34-18f8-2eb7-20e7f7b8c2f8@web.de>
* rs/name-rev-use-opt-hidden-bool (2023-09-05) 1 commit
(merged to 'next' on 2023-09-06 at 9b251a5392)
+ name-rev: use OPT_HIDDEN_BOOL for --peel-tag
Simplify use of parse-options API a bit.
Will merge to 'master'.
source: <5a86c8f8-fcdc-fee9-8af5-aa5ecb036d2e@web.de>
* jk/unused-post-2.42-part2 (2023-09-05) 10 commits
(merged to 'next' on 2023-09-05 at 308ca3a052)
+ parse-options: mark unused parameters in noop callback
+ interpret-trailers: mark unused "unset" parameters in option callbacks
+ parse-options: add more BUG_ON() annotations
+ merge: do not pass unused opt->value parameter
+ parse-options: mark unused "opt" parameter in callbacks
+ parse-options: prefer opt->value to globals in callbacks
+ checkout-index: delay automatic setting of to_tempfile
+ format-patch: use OPT_STRING_LIST for to/cc options
+ merge: simplify parsing of "-n" option
+ merge: make xopts a strvec
Unused parameters to functions are marked as such, and/or removed,
in order to bring us closer to -Wunused-parameter clean.
Will merge to 'master'.
source: <20230831211637.GA949188@coredump.intra.peff.net>
* jk/tree-name-and-depth-limit (2023-08-31) 10 commits
(merged to 'next' on 2023-09-07 at 7ad767ab0d)
+ lower core.maxTreeDepth default to 2048
+ tree-diff: respect max_allowed_tree_depth
+ list-objects: respect max_allowed_tree_depth
+ read_tree(): respect max_allowed_tree_depth
+ traverse_trees(): respect max_allowed_tree_depth
+ add core.maxTreeDepth config
+ fsck: detect very large tree pathnames
+ tree-walk: rename "error" variable
+ tree-walk: drop MAX_TRAVERSE_TREES macro
+ tree-walk: reduce stack size for recursive functions
We now limit depth of the tree objects and maximum length of
pathnames recorded in tree objects.
Will merge to 'master'.
source: <20230831061735.GA2702156@coredump.intra.peff.net>
* js/doc-unit-tests (2023-08-17) 3 commits
- ci: run unit tests in CI
- unit tests: add TAP unit test framework
- unit tests: Add a project plan document
(this branch is used by js/doc-unit-tests-with-cmake.)
Process to add some form of low-level unit tests has started.
Comments?
source: <cover.1692297001.git.steadmon@google.com>
* js/doc-unit-tests-with-cmake (2023-08-31) 4 commits
- artifacts-tar: when including `.dll` files, don't forget the unit-tests
- unit-tests: do show relative file paths
- unit-tests: do not mistake `.pdb` files for being executable
- cmake: also build unit tests
(this branch uses js/doc-unit-tests.)
Update the base topic to work with CMake builds.
source: <pull.1579.git.1693462532.gitgitgadget@gmail.com>
* ew/hash-with-openssl-evp (2023-08-31) 1 commit
(merged to 'next' on 2023-09-05 at 1ddc0078c8)
+ treewide: fix various bugs w/ OpenSSL 3+ EVP API
Fix-up new-ish code to support OpenSSL EVP API.
Will merge to 'master'.
source: <20230901020928.M610756@dcvr>
* tb/path-filter-fix (2023-08-30) 15 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
- t/t4216-log-bloom.sh: harden `test_bloom_filters_not_used()`
- 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
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.
Needs more work?
cf. <20230830200218.GA5147@szeder.dev>
source: <cover.1693413637.git.jonathantanmy@google.com>
* js/config-parse (2023-08-23) 4 commits
- config-parse: split library out of config.[c|h]
- config.c: accept config_parse_options in git_config_from_stdin
- config: report config parse errors using cb
- config: split out config_parse_options
The parsing routines for the configuration files have been split
into a separate file.
Needs review.
source: <cover.1692827403.git.steadmon@google.com>
* jc/update-index-show-index-version (2023-08-18) 3 commits
- test-tool: retire "index-version"
- update-index: add --show-index-version
- update-index doc: v4 is OK with JGit and libgit2
"git update-index" learns "--show-index-version" to inspect
the index format version used by the on-disk index file.
Needs review.
source: <20230818233729.2766281-1-gitster@pobox.com>
* ob/revert-of-revert-is-reapply (2023-09-02) 2 commits
(merged to 'next' on 2023-09-07 at 9a54f66511)
+ git-revert.txt: add discussion
+ sequencer: beautify subject of reverts of reverts
The default log message created by "git revert", when reverting a
commit that records a revert, has been tweaked.
Will merge to 'master'.
source: <20230821170720.577850-1-oswald.buddenhagen@gmx.de>
source: <20230902072035.652549-1-oswald.buddenhagen@gmx.de>
* 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
(this branch uses jc/unresolve-removal.)
Code clean-up.
Not ready to be reviewed yet.
source: <20230731224409.4181277-1-gitster@pobox.com>
* pw/rebase-i-after-failure (2023-09-06) 7 commits
(merged to 'next' on 2023-09-07 at 3cbc3c4d63)
+ rebase -i: fix adding failed command to the todo list
+ rebase --continue: refuse to commit after failed command
+ rebase: fix rewritten list for failed pick
+ sequencer: factor out part of pick_commits()
+ sequencer: use rebase_path_message()
+ rebase -i: remove patch file after conflict resolution
+ rebase -i: move unlink() calls
Various fixes to the behaviour of "rebase -i" when the command got
interrupted by conflicting changes.
Will merge to 'master'.
cf. <6b927687-cf6e-d73e-78fb-bd4f46736928@gmx.de>
source: <pull.1492.v4.git.1694013771.gitgitgadget@gmail.com>
* jc/unresolve-removal (2023-07-31) 7 commits
- checkout: allow "checkout -m path" to unmerge removed paths
- checkout/restore: add basic tests for --merge
- checkout/restore: refuse unmerging paths unless checking out of the index
- update-index: remove stale fallback code for "--unresolve"
- update-index: use unmerge_index_entry() to support removal
- resolve-undo: allow resurrecting conflicted state that resolved to deletion
- update-index: do not read HEAD and MERGE_HEAD unconditionally
(this branch is used by jc/rerere-cleanup.)
"checkout --merge -- path" and "update-index --unresolve path" did
not resurrect conflicted state that was resolved to remove path,
but now they do.
Needs review.
source: <20230731224409.4181277-1-gitster@pobox.com>
* rj/status-bisect-while-rebase (2023-08-01) 1 commit
- status: fix branch shown when not only bisecting
"git status" is taught to show both the branch being bisected and
being rebased when both are in effect at the same time.
Needs review.
cf. <xmqqtttia3vn.fsf@gitster.g>
source: <48745298-f12b-8efb-4e48-90d2c22a8349@gmail.com>
^ 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