* [PATCH 6/8] t7900: fix `pfx` dependency
From: Kristoffer Haugsbakk @ 2023-10-14 21:45 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, stolee
In-Reply-To: <cover.1697319294.git.code@khaugsbakk.name>
Test `start and stop when several schedulers are available` depends on
`pfx` from `start and stop macOS maintenance`.
Duplicate the behavior.
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
t/t7900-maintenance.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh
index ebde3e8a212..15a8653b583 100755
--- a/t/t7900-maintenance.sh
+++ b/t/t7900-maintenance.sh
@@ -794,6 +794,7 @@ test_expect_success 'start and stop Linux/systemd maintenance' '
'
test_expect_success 'start and stop when several schedulers are available' '
+ pfx=$(cd "$HOME" && pwd) &&
write_script print-args <<-\EOF &&
printf "%s\n" "$*" | sed "s:gui/[0-9][0-9]*:gui/[UID]:; s:\(schtasks /create .* /xml\).*:\1:;" >>args
EOF
--
2.42.0.2.g879ad04204
^ permalink raw reply related
* [PATCH 5/8] t7900: factor out common schedule setup
From: Kristoffer Haugsbakk @ 2023-10-14 21:45 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, stolee
In-Reply-To: <cover.1697319294.git.code@khaugsbakk.name>
Tests `magic markers are correct` and `stop preserves surrounding
schedule` depend on some setup in `start preserves existing schedule`.
Factor out the setup code.
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
t/t7900-maintenance.sh | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh
index 6e3ee365ccd..ebde3e8a212 100755
--- a/t/t7900-maintenance.sh
+++ b/t/t7900-maintenance.sh
@@ -637,9 +637,12 @@ test_expect_success 'stop from existing schedule' '
test_must_be_empty cron.txt
'
-test_expect_success 'start preserves existing schedule' '
+test_expect_success 'setup important information for schedule' '
echo "Important information!" >cron.txt &&
- GIT_TEST_MAINT_SCHEDULER="crontab:test-tool crontab cron.txt" git maintenance start --scheduler=crontab &&
+ GIT_TEST_MAINT_SCHEDULER="crontab:test-tool crontab cron.txt" git maintenance start --scheduler=crontab
+'
+
+test_expect_success 'start preserves existing schedule' '
grep "Important information!" cron.txt
'
--
2.42.0.2.g879ad04204
^ permalink raw reply related
* [PATCH 4/8] t7900: factor out inheritance test dependency
From: Kristoffer Haugsbakk @ 2023-10-14 21:45 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, stolee
In-Reply-To: <cover.1697319294.git.code@khaugsbakk.name>
Factor out the dependency that test `maintenance.strategy inheritance` has
on test `--schedule inheritance weekly -> daily -> hourly`.
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
t/t7900-maintenance.sh | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh
index 4bfb4ec5cf6..6e3ee365ccd 100755
--- a/t/t7900-maintenance.sh
+++ b/t/t7900-maintenance.sh
@@ -408,14 +408,16 @@ test_expect_success 'invalid --schedule value' '
test_i18ngrep "unrecognized --schedule" err
'
-test_expect_success '--schedule inheritance weekly -> daily -> hourly' '
+test_expect_success 'setup for inheritance' '
git config maintenance.loose-objects.enabled true &&
git config maintenance.loose-objects.schedule hourly &&
git config maintenance.commit-graph.enabled true &&
git config maintenance.commit-graph.schedule daily &&
git config maintenance.incremental-repack.enabled true &&
- git config maintenance.incremental-repack.schedule weekly &&
+ git config maintenance.incremental-repack.schedule weekly
+'
+test_expect_success '--schedule inheritance weekly -> daily -> hourly' '
GIT_TRACE2_EVENT="$(pwd)/hourly.txt" \
git maintenance run --schedule=hourly 2>/dev/null &&
test_subcommand git prune-packed --quiet <hourly.txt &&
--
2.42.0.2.g879ad04204
^ permalink raw reply related
* [PATCH 3/8] t7900: create commit so that branch is born
From: Kristoffer Haugsbakk @ 2023-10-14 21:45 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, stolee
In-Reply-To: <cover.1697319294.git.code@khaugsbakk.name>
`pack-refs task` cannot be run in isolation but does pass if
`maintenance.auto config option` is run first.
Create a commit so that `HEAD` does not point to an unborn branch.
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
t/t7900-maintenance.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh
index ebc207f1a58..4bfb4ec5cf6 100755
--- a/t/t7900-maintenance.sh
+++ b/t/t7900-maintenance.sh
@@ -388,6 +388,7 @@ test_expect_success 'maintenance.incremental-repack.auto (when config is unset)'
'
test_expect_success 'pack-refs task' '
+ test_commit message &&
for n in $(test_seq 1 5)
do
git branch -f to-pack/$n HEAD || return 1
--
2.42.0.2.g879ad04204
^ permalink raw reply related
* [PATCH 2/8] t7900: setup and tear down clones
From: Kristoffer Haugsbakk @ 2023-10-14 21:45 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, stolee
In-Reply-To: <cover.1697319294.git.code@khaugsbakk.name>
Test `loose-objects task` depends on the two clones setup in `prefetch
multiple remotes`.
Reuse the two clones setup and tear down the clones afterwards in both
tests.
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
t/t7900-maintenance.sh | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh
index ca86b2ba687..ebc207f1a58 100755
--- a/t/t7900-maintenance.sh
+++ b/t/t7900-maintenance.sh
@@ -145,6 +145,12 @@ test_expect_success 'run --task=prefetch with no remotes' '
'
test_expect_success 'prefetch multiple remotes' '
+ test_when_finished rm -r clone1 &&
+ test_when_finished rm -r clone2 &&
+ test_when_finished git remote remove remote1 &&
+ test_when_finished git remote remove remote2 &&
+ test_when_finished git tag --delete one &&
+ test_when_finished git tag --delete two &&
git clone . clone1 &&
git clone . clone2 &&
git remote add remote1 "file://$(pwd)/clone1" &&
@@ -175,6 +181,22 @@ test_expect_success 'prefetch multiple remotes' '
'
test_expect_success 'loose-objects task' '
+ test_when_finished rm -r clone1 &&
+ test_when_finished rm -r clone2 &&
+ test_when_finished git remote remove remote1 &&
+ test_when_finished git remote remove remote2 &&
+ test_when_finished git tag --delete one &&
+ test_when_finished git tag --delete two &&
+ git clone . clone1 &&
+ git clone . clone2 &&
+ git remote add remote1 "file://$(pwd)/clone1" &&
+ git remote add remote2 "file://$(pwd)/clone2" &&
+ git -C clone1 switch -c one &&
+ git -C clone2 switch -c two &&
+ test_commit -C clone1 one &&
+ test_commit -C clone2 two &&
+ git fetch --all &&
+
# Repack everything so we know the state of the object dir
git repack -adk &&
--
2.42.0.2.g879ad04204
^ permalink raw reply related
* [PATCH 1/8] t7900: remove register dependency
From: Kristoffer Haugsbakk @ 2023-10-14 21:45 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, stolee
In-Reply-To: <cover.1697319294.git.code@khaugsbakk.name>
`stop from existing schedule` depends on the preceding test `start from
empty cron table` because the preceding test registers the
repository. Without it, the “stop” test fails because `config` fails to
get the repository:
git config --get --global --fixed-value maintenance.repo "$(pwd)"
Remove this dependency by setting up the state and tearing it down
independently.
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
t/t7900-maintenance.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh
index 487e326b3fa..ca86b2ba687 100755
--- a/t/t7900-maintenance.sh
+++ b/t/t7900-maintenance.sh
@@ -588,6 +588,7 @@ test_expect_success 'start --scheduler=<scheduler>' '
'
test_expect_success 'start from empty cron table' '
+ test_when_finished git maintenance unregister &&
GIT_TEST_MAINT_SCHEDULER="crontab:test-tool crontab cron.txt" git maintenance start --scheduler=crontab &&
# start registers the repo
@@ -599,6 +600,8 @@ test_expect_success 'start from empty cron table' '
'
test_expect_success 'stop from existing schedule' '
+ test_when_finished git maintenance unregister &&
+ git maintenance register &&
GIT_TEST_MAINT_SCHEDULER="crontab:test-tool crontab cron.txt" git maintenance stop &&
# stop does not unregister the repo
--
2.42.0.2.g879ad04204
^ permalink raw reply related
* [PATCH 0/8] t7900: untangle test dependencies
From: Kristoffer Haugsbakk @ 2023-10-14 21:45 UTC (permalink / raw)
To: git; +Cc: Kristoffer Haugsbakk, stolee
Untangle test dependencies so that all tests only need setup tests to have
been run.
For example:
```
./t7900-maintenance.sh --run=setup,31
```
Test with:
```
#!/bin/sh
cd t
# Every test run together with `setup` should pass
for i in $(seq 1 42)
do
./t7900-maintenance.sh --quiet --run=setup,$i || return 1
done &&
# Whole test suite should pass
./t7900-maintenance.sh --quiet &&
# The tests that used to depend on each other should still pass
# when run together
./t7900-maintenance.sh --quiet --run=setup,30,31 &&
./t7900-maintenance.sh --quiet --run=setup,11,12 &&
./t7900-maintenance.sh --quiet --run=setup,3,19 &&
./t7900-maintenance.sh --quiet --run=setup,23,24 &&
./t7900-maintenance.sh --quiet --run=setup,33,34,35 &&
./t7900-maintenance.sh --quiet --run=setup,36,40 &&
./t7900-maintenance.sh --quiet --run=setup,36,40 &&
./t7900-maintenance.sh --quiet --run=setup,36,37 &&
./t7900-maintenance.sh --quiet --run=setup,15,23,24 &&
printf "\nAll passed\n" ||
printf '\n***Failed***\n'
```
§ CI
The CI failed but it didn't look relevant.
https://github.com/LemmingAvalanche/git/actions/runs/6518415327/job/17703822606
Cheers
Kristoffer Haugsbakk (8):
t7900: remove register dependency
t7900: setup and tear down clones
t7900: create commit so that branch is born
t7900: factor out inheritance test dependency
t7900: factor out common schedule setup
t7900: fix `pfx` dependency
t7900: fix `print-args` dependency
t7900: factor out packfile dependency
t/t7900-maintenance.sh | 49 ++++++++++++++++++++++++++++++++++++------
1 file changed, 43 insertions(+), 6 deletions(-)
base-commit: 43c8a30d150ecede9709c1f2527c8fba92c65f40
--
2.42.0.2.g879ad04204
^ permalink raw reply
* [PATCH] grep: die gracefully when outside repository
From: Kristoffer Haugsbakk @ 2023-10-14 21:02 UTC (permalink / raw)
To: code; +Cc: git, ks1322
In-Reply-To: <6bb48aac-460c-4d7f-9057-40c3df0c807d@app.fastmail.com>
Die gracefully when `git grep --no-index` is run outside of a Git
repository and the path is outside the directory tree.
If you are not in a Git repository and say:
git grep --no-index search ..
You trigger a `BUG`:
BUG: environment.c:213: git environment hasn't been setup
Aborted (core dumped)
Because `..` is a valid path which is treated as a pathspec. Then
`pathspec` figures out that it is not in the current directory tree. The
`BUG` is triggered when `pathspec` tries to advice the user about the path
to the (non-existing) repository.
Reported-by: ks1322 ks1322 <ks1322@gmail.com>
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---
pathspec.c | 3 +++
t/t7810-grep.sh | 13 +++++++++++++
2 files changed, 16 insertions(+)
diff --git a/pathspec.c b/pathspec.c
index 3a3a5724c44..e115832f17a 100644
--- a/pathspec.c
+++ b/pathspec.c
@@ -468,6 +468,9 @@ static void init_pathspec_item(struct pathspec_item *item, unsigned flags,
&prefixlen, copyfrom);
if (!match) {
const char *hint_path = get_git_work_tree();
+ if (!have_git_dir())
+ die(_("'%s' is outside the directory tree"),
+ copyfrom);
if (!hint_path)
hint_path = get_git_dir();
die(_("%s: '%s' is outside repository at '%s'"), elt,
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index 39d6d713ecb..b976f81a166 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -1234,6 +1234,19 @@ test_expect_success 'outside of git repository with fallbackToNoIndex' '
)
'
+test_expect_success 'outside of git repository with pathspec outside the directory tree' '
+ test_when_finished rm -fr non &&
+ rm -fr non &&
+ mkdir -p non/git/sub &&
+ (
+ GIT_CEILING_DIRECTORIES="$(pwd)/non" &&
+ export GIT_CEILING_DIRECTORIES &&
+ cd non/git &&
+ test_expect_code 128 git grep --no-index search .. 2>error &&
+ grep "is outside the directory tree" error
+ )
+'
+
test_expect_success 'inside git repository but with --no-index' '
rm -fr is &&
mkdir -p is/git/sub &&
base-commit: 43c8a30d150ecede9709c1f2527c8fba92c65f40
--
2.42.0.2.g879ad04204
^ permalink raw reply related
* What's cooking in git.git (Oct 2023, #06; Fri, 13)
From: Junio C Hamano @ 2023-10-14 20:12 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).
There are too many topics marked with "Needs review" label. I can
help reviewing some of them myself, but obviously it will not scale.
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/
--------------------------------------------------
[Graduated to 'master']
* ar/diff-index-merge-base-fix (2023-10-02) 1 commit
(merged to 'next' on 2023-10-06 at 0ff4dfc0e1)
+ diff: fix --merge-base with annotated tags
"git diff --merge-base X other args..." insisted that X must be a
commit and errored out when given an annotated tag that peels to a
commit, but we only need it to be a committish. This has been
corrected.
source: <20231001151845.3621551-1-hi@alyssa.is>
* ds/mailmap-entry-update (2023-10-12) 1 commit
(merged to 'next' on 2023-10-12 at 3de300ac62)
+ mailmap: change primary address for Derrick Stolee
Update mailmap entry for Derrick.
Will merge to 'master' immediately.
source: <pull.1592.git.1697131834003.gitgitgadget@gmail.com>
* jk/commit-graph-leak-fixes (2023-10-03) 10 commits
(merged to 'next' on 2023-10-06 at 5d202ef8b9)
+ commit-graph: clear oidset after finishing write
+ commit-graph: free write-context base_graph_name during cleanup
+ commit-graph: free write-context entries before overwriting
+ commit-graph: free graph struct that was not added to chain
+ commit-graph: delay base_graph assignment in add_graph_to_chain()
+ commit-graph: free all elements of graph chain
+ commit-graph: move slab-clearing to close_commit_graph()
+ merge: free result of repo_get_merge_bases()
+ commit-reach: free temporary list in get_octopus_merge_bases()
+ t6700: mark test as leak-free
Leakfix.
source: <20231003202504.GA7697@coredump.intra.peff.net>
* jk/decoration-and-other-leak-fixes (2023-10-05) 3 commits
(merged to 'next' on 2023-10-06 at 5fc05c94dc)
+ daemon: free listen_addr before returning
+ revision: clear decoration structs during release_revisions()
+ decorate: add clear_decoration() function
Leakfix.
source: <20231005212802.GA982892@coredump.intra.peff.net>
* js/submodule-fix-misuse-of-path-and-name (2023-10-03) 6 commits
(merged to 'next' on 2023-10-06 at 1054b6e752)
+ t7420: test that we correctly handle renamed submodules
+ t7419: test that we correctly handle renamed submodules
+ t7419, t7420: use test_cmp_config instead of grepping .gitmodules
+ t7419: actually test the branch switching
+ submodule--helper: return error from set-url when modifying failed
+ submodule--helper: use submodule_from_path in set-{url,branch}
In .gitmodules files, submodules are keyed by their names, and the
path to the submodule whose name is $name is specified by the
submodule.$name.path variable. There were a few codepaths that
mixed the name and path up when consulting the submodule database,
which have been corrected. It took long for these bugs to be found
as the name of a submodule initially is the same as its path, and
the problem does not surface until it is moved to a different path,
which apparently happens very rarely.
source: <0a0a157f88321d25fdb0be771a454b3410a449f3.camel@archlinux.org>
* la/trailer-test-and-doc-updates (2023-09-07) 13 commits
(merged to 'next' on 2023-10-06 at 69fef35819)
+ 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>
--------------------------------------------------
[New Topics]
* tb/format-pack-doc-update (2023-10-12) 2 commits
- Documentation/gitformat-pack.txt: fix incorrect MIDX documentation
- Documentation/gitformat-pack.txt: fix typo
Doc update.
Expecting a reroll.
cf. <xmqq5y3b4id2.fsf@gitster.g>
source: <cover.1697144959.git.me@ttaylorr.com>
* ps/do-not-trust-commit-graph-blindly-for-existence (2023-10-13) 1 commit
- commit: detect commits that exist in commit-graph but not in the ODB
(this branch is used by kn/rev-list-missing-fix.)
The codepath to traverse the commit-graph learned to notice that a
commit is missing (e.g., corrupt repository lost an object), even
though it knows something about the commit (like its parents) from
what is in commit-graph.
Comments?
source: <b0bf576c51a706367a758b8e30eca37edb9c2734.1697200576.git.ps@pks.im>
* tb/pair-chunk-expect-size (2023-10-13) 8 commits
- midx: read `OOFF` chunk with `pair_chunk_expect()`
- midx: read `OIDL` chunk with `pair_chunk_expect()`
- midx: read `OIDF` chunk with `pair_chunk_expect()`
- commit-graph: read `BIDX` chunk with `pair_chunk_expect()`
- commit-graph: read `GDAT` chunk with `pair_chunk_expect()`
- commit-graph: read `CDAT` chunk with `pair_chunk_expect()`
- commit-graph: read `OIDF` chunk with `pair_chunk_expect()`
- chunk-format: introduce `pair_chunk_expect()` helper
(this branch uses jk/chunk-bounds.)
Code clean-up for jk/chunk-bounds topic.
Comments?
source: <45cac29403e63483951f7766c6da3c022c68d9f0.1697225110.git.me@ttaylorr.com>
source: <cover.1697225110.git.me@ttaylorr.com>
--------------------------------------------------
[Stalled]
* 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.
Expecting a reroll.
cf. <12c956ea-330d-4441-937f-7885ab519e26@gmail.com>
source: <pull.1581.git.1694080982621.gitgitgadget@gmail.com>
* 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>
* jc/diff-cached-fsmonitor-fix (2023-09-15) 3 commits
- diff-lib: fix check_removed() when fsmonitor is active
- Merge branch 'jc/fake-lstat' into jc/diff-cached-fsmonitor-fix
- Merge branch 'js/diff-cached-fsmonitor-fix' into jc/diff-cached-fsmonitor-fix
(this branch uses jc/fake-lstat.)
The optimization based on fsmonitor in the "diff --cached"
codepath is resurrected with the "fake-lstat" introduced earlier.
It is unknown if the optimization is worth resurrecting, but in case...
source: <xmqqr0n0h0tw.fsf@gitster.g>
--------------------------------------------------
[Cooking]
* jc/fail-stash-to-store-non-stash (2023-10-11) 1 commit
- stash: be careful what we store
Feeding "git stash store" with a random commit that was not created
by "git stash create" now errors out.
Will merge to 'next'?
source: <xmqqbkd4lwj0.fsf_-_@gitster.g>
* jc/doc-unit-tests-fixup (2023-10-11) 1 commit
- SQUASH???
(this branch uses js/doc-unit-tests and js/doc-unit-tests-with-cmake.)
Quick fix for jc/doc-unit-tests topic to unbreak CI running on 'seen'.
source: <xmqqwmvskf8t.fsf@gitster.g>
* bc/racy-4gb-files (2023-10-13) 2 commits
- Prevent git from rehashing 4GiB files
- t: add a test helper to truncate files
The index file has room only for lower 32-bit of the file size in
the cached stat information, which means cached stat information
will have 0 in its sd_size member for a file whose size is multiple
of 4GiB. This is mistaken for a racily clean path. Avoid it by
storing a bogus sd_size value instead for such files.
Will merge to 'next'?
source: <20231012160930.330618-1-sandals@crustytoothpaste.net>
* jc/grep-f-relative-to-cwd (2023-10-12) 1 commit
- grep: -f <path> is relative to $cwd
"cd sub && git grep -f patterns" tried to read "patterns" file at
the top level of the working tree; it has been corrected to read
"sub/patterns" instead.
Needs review.
source: <xmqqedhzg37z.fsf@gitster.g>
* tb/path-filter-fix (2023-10-10) 17 commits
- bloom: introduce `deinit_bloom_filters()`
- commit-graph: reuse existing Bloom filters where possible
- object.h: fix mis-aligned flag bits table
- commit-graph: drop unnecessary `graph_read_bloom_data_context`
- commit-graph.c: unconditionally load Bloom filters
- bloom: prepare to discard incompatible Bloom filters
- bloom: annotate filters with hash version
- commit-graph: new filter ver. that fixes murmur3
- repo-settings: introduce commitgraph.changedPathsVersion
- t4216: test changed path filters with high bit paths
- t/helper/test-read-graph: implement `bloom-filters` mode
- bloom.h: make `load_bloom_filter_from_graph()` public
- t/helper/test-read-graph.c: extract `dump_graph_info()`
- gitformat-commit-graph: describe version 2 of BDAT
- commit-graph: ensure Bloom filters are read with consistent settings
- revision.c: consult Bloom filters for root commits
- t/t4216-log-bloom.sh: harden `test_bloom_filters_not_used()`
The Bloom filter used for path limited history traversal was broken
on systems whose "char" is unsigned; update the implementation and
bump the format version to 2.
Needs (hopefully final and quick) review.
source: <cover.1696969994.git.me@ttaylorr.com>
* ak/pretty-decorate-more-fix (2023-10-09) 1 commit
(merged to 'next' on 2023-10-12 at 3cbb4c2268)
+ pretty: fix ref filtering for %(decorate) formats
Unlike "git log --pretty=%D", "git log --pretty="%(decorate)" did
not auto-initialize the decoration subsystem, which has been
corrected.
Will merge to 'master'.
source: <20231008202307.1568477-1-andy.koppe@gmail.com>
* en/docfixes (2023-10-09) 25 commits
- documentation: add missing parenthesis
- documentation: add missing quotes
- documentation: add missing fullstops
- documentation: add some commas where they are helpful
- documentation: fix whitespace issues
- documentation: fix capitalization
- documentation: fix punctuation
- documentation: use clearer prepositions
- documentation: add missing hyphens
- documentation: remove unnecessary hyphens
- documentation: add missing article
- documentation: fix choice of article
- documentation: whitespace is already generally plural
- documentation: fix singular vs. plural
- documentation: fix verb vs. noun
- documentation: fix adjective vs. noun
- documentation: fix verb tense
- documentation: employ consistent verb tense for a list
- documentation: fix subject/verb agreement
- documentation: remove extraneous words
- documentation: add missing words
- documentation: fix apostrophe usage
- documentation: fix typos
- documentation: fix small error
- documentation: wording improvements
Documentation typo and grammo fixes.
Needs review.
source: <pull.1595.git.1696747527.gitgitgadget@gmail.com>
* kn/rev-list-missing-fix (2023-10-13) 4 commits
- rev-list: add commit object support in `--missing` option
- rev-list: move `show_commit()` to the bottom
- revision: rename bit to `do_not_die_on_missing_objects`
- Merge branch 'ps/do-not-trust-commit-graph-blindly-for-existence' into kn/rev-list-missing-fix
(this branch uses ps/do-not-trust-commit-graph-blindly-for-existence.)
"git rev-list --missing" did not work for missing commit objects,
which has been corrected.
Needs review.
source: <20231009105528.17777-1-karthik.188@gmail.com>
* sn/cat-file-doc-update (2023-10-09) 1 commit
(merged to 'next' on 2023-10-10 at 6719ba7bd4)
+ doc/cat-file: make synopsis and description less confusing
"git cat-file" documentation updates.
Will merge to 'master'.
source: <20231009175604.2361700-1-stepnem@smrk.net>
* xz/commit-title-soft-limit-doc (2023-10-09) 1 commit
(merged to 'next' on 2023-10-10 at 0bf3d9ed51)
+ doc: correct the 50 characters soft limit (+)
Doc update.
Will merge to 'master'.
source: <pull.1585.v2.git.git.1696778367151.gitgitgadget@gmail.com>
* jk/chunk-bounds (2023-10-09) 20 commits
(merged to 'next' on 2023-10-10 at 21139603ce)
+ chunk-format: drop pair_chunk_unsafe()
+ commit-graph: detect out-of-order BIDX offsets
+ commit-graph: check bounds when accessing BIDX chunk
+ commit-graph: check bounds when accessing BDAT chunk
+ commit-graph: bounds-check generation overflow chunk
+ commit-graph: check size of generations chunk
+ commit-graph: bounds-check base graphs chunk
+ commit-graph: detect out-of-bounds extra-edges pointers
+ commit-graph: check size of commit data chunk
+ midx: check size of revindex chunk
+ midx: bounds-check large offset chunk
+ midx: check size of object offset chunk
+ midx: enforce chunk alignment on reading
+ midx: check size of pack names chunk
+ commit-graph: check consistency of fanout table
+ midx: check size of oid lookup chunk
+ commit-graph: check size of oid fanout chunk
+ midx: stop ignoring malformed oid fanout chunk
+ t: add library for munging chunk-format files
+ chunk-format: note that pair_chunk() is unsafe
(this branch is used by tb/pair-chunk-expect-size.)
The codepaths that read "chunk" formatted files have been corrected
to pay attention to the chunk size and notice broken files.
Will merge to 'master'.
source: <20231009205544.GA3281950@coredump.intra.peff.net>
* ps/rewritten-is-per-worktree-doc (2023-10-10) 1 commit
(merged to 'next' on 2023-10-12 at 501b960e8c)
+ doc/git-worktree: mention "refs/rewritten" as per-worktree refs
Doc update.
Will merge to 'master'.
source: <985ac850eb6e60ae76601acc8bfbcd56f99348b4.1696935657.git.ps@pks.im>
* jc/merge-ort-attr-index-fix (2023-10-09) 1 commit
(merged to 'next' on 2023-10-10 at b139b87502)
+ merge-ort: initialize repo in index state
Fix "git merge-tree" to stop segfaulting when the --attr-source
option is used.
Will merge to 'master'.
source: <pull.1583.v3.git.git.1696857660374.gitgitgadget@gmail.com>
* sn/typo-grammo-phraso-fixes (2023-10-05) 5 commits
- t/README: fix multi-prerequisite example
- doc/gitk: s/sticked/stuck/
- git-jump: admit to passing merge mode args to ls-files
- doc/diff-options: improve wording of the log.diffMerges mention
- doc: fix some typos, grammar and wording issues
Many typos, ungrammatical sentences and wrong phrasing have been
fixed.
Needs review.
source: <20231003082107.3002173-1-stepnem@smrk.net>
* so/diff-merges-dd (2023-10-09) 3 commits
- completion: complete '--dd'
- diff-merges: introduce '--dd' option
- diff-merges: improve --diff-merges documentation
"git log" and friends learned "--dd" that is a short-hand for
"--diff-merges=first-parent -p".
Will merge to 'next'?
source: <20231009160535.236523-1-sorganov@gmail.com>
* vd/loose-ref-iteration-optimization (2023-10-09) 4 commits
(merged to 'next' on 2023-10-12 at 99e2f83855)
+ files-backend.c: avoid stat in 'loose_fill_ref_dir'
+ dir.[ch]: add 'follow_symlink' arg to 'get_dtype'
+ dir.[ch]: expose 'get_dtype'
+ ref-cache.c: fix prefix matching in ref iteration
The code to iterate over loose references have been optimized to
reduce the number of lstat() system calls.
Will merge to 'master'.
source: <pull.1594.v2.git.1696888736.gitgitgadget@gmail.com>
* jc/update-list-references-to-lore (2023-10-06) 1 commit
- doc: update list archive reference to use lore.kernel.org
Doc update.
Needs review.
source: <xmqq7cnz741s.fsf@gitster.g>
* cc/git-replay (2023-10-10) 14 commits
- replay: stop assuming replayed branches do not diverge
- replay: add --contained to rebase contained branches
- replay: add --advance or 'cherry-pick' mode
- 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: change rev walking options
- 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
Introduce "git replay", a tool meant on the server side without
working tree to recreate a history.
Needs (hopefully final and quick) review.
source: <20231010123847.2777056-1-christian.couder@gmail.com>
* tb/repack-max-cruft-size (2023-10-09) 5 commits
(merged to 'next' on 2023-10-09 at 38f039e880)
+ repack: free existing_cruft array after use
(merged to 'next' on 2023-10-06 at b3ca6df3b9)
+ builtin/repack.c: avoid making cruft packs preferred
+ builtin/repack.c: implement support for `--max-cruft-size`
+ builtin/repack.c: parse `--max-pack-size` with OPT_MAGNITUDE
+ t7700: split cruft-related tests to t7704
"git repack" learned "--max-cruft-size" to prevent cruft packs from
growing without bounds.
Will merge to 'master'.
source: <cover.1696293862.git.me@ttaylorr.com>
source: <20231007172031.GA1524950@coredump.intra.peff.net>
source: <035393935108d02aaf8927189b05102f4f74f340.1696370003.git.me@ttaylorr.com>
* ak/color-decorate-symbols (2023-10-03) 1 commit
- decorate: add color.decorate.symbols config option
A new config for coloring.
Needs review.
source: <20231003205442.22963-1-andy.koppe@gmail.com>
* jc/attr-tree-config (2023-10-13) 2 commits
- attr: add attr.tree for setting the treeish to read attributes from
- attr: read attributes from HEAD when bare repo
The attribute subsystem learned to honor `attr.tree` configuration
that specifies which tree to read the .gitattributes files from.
Will merge to 'next'?
source: <pull.1577.v5.git.git.1697218770.gitgitgadget@gmail.com>
* js/update-urls-in-doc-and-comment (2023-09-26) 4 commits
- doc: refer to internet archive
- doc: update links for andre-simon.de
- doc: update links to current pages
- doc: switch links to https
Stale URLs have been updated to their current counterparts (or
archive.org) and HTTP links are replaced with working HTTPS links.
Needs review.
source: <pull.1589.v2.git.1695553041.gitgitgadget@gmail.com>
* la/trailer-cleanups (2023-09-26) 4 commits
- trailer: only use trailer_block_* variables if trailers were found
- trailer: use offsets for trailer_start/trailer_end
- trailer: find the end of the log message
- commit: ignore_non_trailer computes number of bytes to ignore
Code clean-up.
Needs review.
source: <pull.1563.v4.git.1695709372.gitgitgadget@gmail.com>
* eb/hash-transition (2023-10-02) 30 commits
- t1016-compatObjectFormat: add tests to verify the conversion between objects
- t1006: test oid compatibility with cat-file
- t1006: rename sha1 to oid
- test-lib: compute the compatibility hash so tests may use it
- builtin/ls-tree: let the oid determine the output algorithm
- object-file: handle compat objects in check_object_signature
- tree-walk: init_tree_desc take an oid to get the hash algorithm
- builtin/cat-file: let the oid determine the output algorithm
- rev-parse: add an --output-object-format parameter
- repository: implement extensions.compatObjectFormat
- object-file: update object_info_extended to reencode objects
- object-file-convert: convert commits that embed signed tags
- object-file-convert: convert commit objects when writing
- object-file-convert: don't leak when converting tag objects
- object-file-convert: convert tag objects when writing
- object-file-convert: add a function to convert trees between algorithms
- object: factor out parse_mode out of fast-import and tree-walk into in object.h
- cache: add a function to read an OID of a specific algorithm
- tag: sign both hashes
- commit: export add_header_signature to support handling signatures on tags
- commit: convert mergetag before computing the signature of a commit
- commit: write commits for both hashes
- object-file: add a compat_oid_in parameter to write_object_file_flags
- object-file: update the loose object map when writing loose objects
- loose: compatibilty short name support
- loose: add a mapping between SHA-1 and SHA-256 for loose objects
- repository: add a compatibility hash algorithm
- object-names: support input of oids in any supported hash
- oid-array: teach oid-array to handle multiple kinds of oids
- object-file-convert: stubs for converting from one object format to another
Teach a repository to work with both SHA-1 and SHA-256 hash algorithms.
Needs review.
source: <878r8l929e.fsf@gmail.froward.int.ebiederm.org>
* jx/remote-archive-over-smart-http (2023-10-04) 4 commits
- archive: support remote archive from stateless transport
- transport-helper: call do_take_over() in connect_helper
- transport-helper: call do_take_over() in process_connect
- transport-helper: no connection restriction in connect_helper
"git archive --remote=<remote>" learned to talk over the smart
http (aka stateless) transport.
Needs review.
source: <cover.1696432593.git.zhiyou.jx@alibaba-inc.com>
* jx/sideband-chomp-newline-fix (2023-10-04) 3 commits
- pkt-line: do not chomp newlines for sideband messages
- pkt-line: memorize sideband fragment in reader
- test-pkt-line: add option parser for unpack-sideband
Sideband demultiplexer fixes.
Needs review.
source: <cover.1696425168.git.zhiyou.jx@alibaba-inc.com>
* ty/merge-tree-strategy-options (2023-10-11) 2 commits
(merged to 'next' on 2023-10-12 at 9b873601df)
+ merge: introduce {copy|clear}_merge_options()
(merged to 'next' on 2023-09-29 at aa65b54416)
+ merge-tree: add -X strategy option
"git merge-tree" learned to take strategy backend specific options
via the "-X" option, like "git merge" does.
Will merge to 'master'.
source: <pull.1565.v6.git.1695522222723.gitgitgadget@gmail.com>
* js/config-parse (2023-09-21) 5 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 do_event() into start and flush operations
- config: split out config_parse_options
The parsing routines for the configuration files have been split
into a separate file.
Needs review.
source: <cover.1695330852.git.steadmon@google.com>
* jc/fake-lstat (2023-09-15) 1 commit
- cache: add fake_lstat()
(this branch is used by jc/diff-cached-fsmonitor-fix.)
A new helper to let us pretend that we called lstat() when we know
our cache_entry is up-to-date via fsmonitor.
Needs review.
source: <xmqqcyykig1l.fsf@gitster.g>
* rs/parse-options-value-int (2023-09-18) 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.
Not ready yet.
cf. <4014e490-c6c1-453d-b0ed-645220e3e614@web.de>
source: <e6d8a291-03de-cfd3-3813-747fc2cad145@web.de>
* js/doc-unit-tests (2023-10-09) 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 jc/doc-unit-tests-fixup and js/doc-unit-tests-with-cmake.)
Process to add some form of low-level unit tests has started.
Expecting a reroll to address CI breakage.
source: <cover.1696889529.git.steadmon@google.com>
* js/doc-unit-tests-with-cmake (2023-10-09) 7 commits
- cmake: handle also unit tests
- cmake: use test names instead of full paths
- cmake: fix typo in variable name
- 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 is used by jc/doc-unit-tests-fixup; uses js/doc-unit-tests.)
Update the base topic to work with CMake builds.
Needs review.
source: <pull.1579.v3.git.1695640836.gitgitgadget@gmail.com>
* jc/rerere-cleanup (2023-08-25) 4 commits
- rerere: modernize use of empty strbuf
- rerere: try_merge() should use LL_MERGE_ERROR when it means an error
- rerere: fix comment on handle_file() helper
- rerere: simplify check_one_conflict() helper function
Code clean-up.
Not ready to be reviewed yet.
source: <20230824205456.1231371-1-gitster@pobox.com>
* 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>
--------------------------------------------------
[Discarded]
* tb/ci-coverity (2023-09-21) 1 commit
. .github/workflows: add coverity action
GitHub CI workflow has learned to trigger Coverity check.
Superseded by the js/ci-coverity topic.
source: <b23951c569660e1891a7fb3ad2c2ea1952897bd7.1695332105.git.me@ttaylorr.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.
Superseded by the cw/prelim-cleanup topic.
cf. <xmqqy1hfrk6p.fsf@gitster.g>
cf. <20230915183927.1597414-1-jonathantanmy@google.com>
source: <20230908174134.1026823-1-calvinwan@google.com>
* so/diff-merges-d (2023-09-11) 2 commits
- diff-merges: introduce '-d' option
- diff-merges: improve --diff-merges documentation
Superseded by the so/diff-merges-dd topic.
source: <20230909125446.142715-1-sorganov@gmail.com>
* kn/rev-list-ignore-missing-links (2023-09-20) 1 commit
. revision: add `--ignore-missing-links` user option
Surface the .ignore_missing_links bit that stops the revision
traversal from stopping and dying when encountering a missing
object to a new command line option of "git rev-list", so that the
objects that are required but are missing can be enumerated.
Superseded by kn/rev-list-missing-fix
source: <20230920104507.21664-1-karthik.188@gmail.com>
^ permalink raw reply
* Re: [PATCH 21/20] t5319: make corrupted large-offset test more robust
From: Junio C Hamano @ 2023-10-14 19:42 UTC (permalink / raw)
To: Jeff King; +Cc: git, Taylor Blau
In-Reply-To: <20231014004348.GA43880@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> 4b. But sometimes we hit a different error. If another object points
> to X as a delta base, then trying to find the type of that object
> requires walking the delta chain to the base entry (since only the
> base has the concrete type; deltas themselves are either OFS_DELTA
> or REF_DELTA).
>
> Normally this would not require separate offset lookups at all, as
> deltas are usually stored as OFS_DELTA, specifying the relative
> offset to the base. But the corrupt idx created in step 1 is done
> directly with "git pack-objects" and does not pass the
> --delta-base-offset option, meaning we have REF_DELTA entries!
> Those do have to consult an index to find the location of the base
> object, and they use the pack .idx to do this. The same pack .idx
> that we know is corrupted from step 1!
Tricky.
> The set of objects created in the test is deterministic. But the delta
> selection seems not to be (which is not too surprising, as it is
> multi-threaded).
So, the offsets of the objects are also not deterministic?
> I have seen the failure in Windows CI but haven't
> reproduced it locally (not even with --stress). Re-running a failed
> Windows CI job tends to work. But when I download and examine the trash
> directory from a failed run, it shows a different set of deltas than I
> get locally. But the exact source of non-determinism isn't that
> important; our test should be robust against any order.
Yeah, thanks for digging this tricky situation through.
> b. The "objects64" setup could use --delta-base-offset. This would fix
> our problem, but earlier tests have many hard-coded offsets. Using
> OFS_DELTA would change the locations of objects in the pack (this
> might even be OK because I think most of the offsets are within the
> .idx file, but it seems brittle and I'm afraid to touch it).
I am not sure I follow, as it does not sound a solution to anything
if the offsets are not deterministic (and "earlier tests" that have
hard coded offsets are broken no matter what, which is not a problem
this patch introduces). Puzzled, but not curious enough to think
about it further, as you have already rejected this approach ;-)
> d. We could ask directly about object X, rather than enumerating all
> of them. But that requires further hard-coding of the oid (both
> sha1 and sha256) of object X. I'd prefer not to introduce more
> brittleness.
Right.
> e. We can use a --batch-check format that looks at the pack data, but
> doesn't have to chase deltas. The problem in this case is
> %(objecttype), which has to walk to the base. But %(objectsize)
> does not; we can get the value directly from the delta itself.
> Another option would be %(deltabase), where we report the REF_DELTA
> name but don't look at its data.
>
> I've gone with option (e) here. It's kind of subtle, but it's simple and
> has no side effects.
Nice.
> @@ -1129,8 +1129,10 @@ test_expect_success 'reader bounds-checks large offset table' '
> git multi-pack-index --object-dir=../objects64 write &&
> midx=../objects64/pack/multi-pack-index &&
> corrupt_chunk_file $midx LOFF clear &&
> - test_must_fail git cat-file \
> - --batch-check --batch-all-objects 2>err &&
> + # using only %(objectsize) is important here; see the commit
> + # message for more details
> + test_must_fail git cat-file --batch-all-objects \
> + --batch-check="%(objectsize)" 2>err &&
A rather unfriendly message to readers, as it is unclear which
commit you are talking about, and a fun thing is that you cannot
say which one.
Will queue. Thanks.
^ permalink raw reply
* Re: Bug: git grep --no-index 123 /dev/stdin crashes with SIGABRT
From: Kristoffer Haugsbakk @ 2023-10-14 19:37 UTC (permalink / raw)
To: Kristoffer Haugsbakk; +Cc: git, ks1322 ks1322
In-Reply-To: <2d8eca81-0415-43bf-b3c4-f1163713422b@app.fastmail.com>
On Sat, Oct 14, 2023, at 20:12, Kristoffer Haugsbakk wrote:
> It looks like `setup.c:verify_filename` fails to deny paths that are not
> transitive children (or whatever the term) of the directory that git(1) is
> running in:
No, that's not it. I don't think that's the responsibility of that
function. Compare to a successful run, that is when run in a Git
repository:
$ git grep --no-index dfddf /home
fatal: /home: '/home' is outside repository at '/home/kristoffer/programming/git'
And that error happens at `pathspec.c:473`.
So going down into that file is not wrong.
^ permalink raw reply
* Re: Bug: git grep --no-index 123 /dev/stdin crashes with SIGABRT
From: Kristoffer Haugsbakk @ 2023-10-14 18:12 UTC (permalink / raw)
To: ks1322 ks1322; +Cc: git
In-Reply-To: <CAKFQ_Q_P4HvCMHsg4=6ycb8r44qprhRCGSmLQf7B3_-zy28_oQ@mail.gmail.com>
Hi ks1322
On Sat, Oct 14, 2023, at 17:42, ks1322 ks1322 wrote:
> 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)
> `git grep --no-index 123 /dev/stdin` outside of git repository
>
> What did you expect to happen? (Expected behavior)
> Ability to grep input from stdin
>
> What happened instead? (Actual behavior)
> `git grep` crashed with SIGABRT
>
> $ git grep --no-index 123 /dev/stdin
> BUG: environment.c:215: git environment hasn't been setup
> Aborted (core dumped)
>
> What's different between what you expected and what actually happened?
> Crash, no grep result
It looks like `setup.c:verify_filename` fails to deny paths that are not
transitive children (or whatever the term) of the directory that git(1) is
running in:
$ git -C ~/IdeaProjects/ grep --no-index dfddf ~
BUG: environment.c:213: git environment hasn't been setup
Aborted (core dumped)
So `builtin/grep.c` goes past that check, into
`pathspec.c:init_pathspec_item` and dies at line 472 since that function
assumes that we are in a Git repository.
--
Kristoffer Haugsbakk
^ permalink raw reply
* Re: [PATCH] bugreport: add 'seconds' to default outfile name
From: Dragan Simic @ 2023-10-14 17:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jacob Stopak, git
In-Reply-To: <xmqqa5slt7wa.fsf@gitster.g>
On 2023-10-14 19:45, Junio C Hamano wrote:
> Dragan Simic <dsimic@manjaro.org> writes:
>
>> How about making the filename a bit shorter first, to make room for
>> the additional two digits, so the example mentioned above would end up
>> being named "git-bugreport-20231014-092037.txt"?
>
> The reason I stated not to unconditionally add two more digits is
> *not* that I wanted to keep things shorter. I wanted to keep names
> stable and in the same shape as before for sensible people who spend
> more than 60 seconds---only those who produce more than one within
> the same minute will be affected.
>
> What is your reason to want to make the filename shoter first?
> It would break everybody, wouldn't it?
Please note that I haven't researched in detail what else depends on the
current filename format, which presumably is a whole bunch of stuff, I
just suggested this filename compaction because I understood that the
filename length was becoming an issue.
Speaking in general, I somehow find "20220712" a bit more readable than
"2022-07-12" as part of a filename, but that's of course just my
personal preference.
^ permalink raw reply
* Re: [PATCH] bugreport: add 'seconds' to default outfile name
From: Junio C Hamano @ 2023-10-14 17:45 UTC (permalink / raw)
To: Dragan Simic; +Cc: Jacob Stopak, git
In-Reply-To: <833da2d05d4b1dfa8e561aa638a927b0@manjaro.org>
Dragan Simic <dsimic@manjaro.org> writes:
> How about making the filename a bit shorter first, to make room for
> the additional two digits, so the example mentioned above would end up
> being named "git-bugreport-20231014-092037.txt"?
The reason I stated not to unconditionally add two more digits is
*not* that I wanted to keep things shorter. I wanted to keep names
stable and in the same shape as before for sensible people who spend
more than 60 seconds---only those who produce more than one within
the same minute will be affected.
What is your reason to want to make the filename shoter first?
It would break everybody, wouldn't it?
^ permalink raw reply
* Re: [RFC] Define "precious" attribute and support it in `git clean`
From: Junio C Hamano @ 2023-10-14 17:41 UTC (permalink / raw)
To: Josh Triplett; +Cc: Sebastian Thiel, git
In-Reply-To: <ZSouSI_zPusOefsv@localhost>
Josh Triplett <josh@joshtriplett.org> writes:
> On Tue, Oct 10, 2023 at 10:02:20AM -0700, Junio C Hamano wrote:
>> Sebastian Thiel <sebastian.thiel@icloud.com> writes:
>>
>> > I'd like to propose adding a new standard gitattribute "precious".
>>
>> ;-).
>>
>> Over the years, I've seen many times scenarios that would have been
>> helped if we had not just "tracked? ignored? unignored?" but also
>> the fourth kind [*]. The word "ignored" (or "excluded") has always
>> meant "not tracked, not to be tracked, and expendable" to Git, and
>> "ignored but unexpendable" class was missing. I even used the term
>> "precious" myself in those discussions. At the concept level, I
>> support the effort 100%, but as always, the devil will be in the
>> details.
>
> "I've already wanted this for years" is, honestly, the best response we
> could *possibly* have hoped for.
Yeah, but that is not what I gave here.
It is something I saw people want from time to time over the years;
I am not at all talking about my desire, or lack thereof, to add it
to the system ;-)
>> In previous discussions, nobody was disturbed that "git clean" was
>> unaware of the "precious" class, but if we were to have the
>> "precious" class in addition to "ignored" aka "expendable", I would
>> not oppose to teach "git clean" about it, too.
>>
>> There was an early and rough design draft there in
>>
>> https://lore.kernel.org/git/7vipsnar23.fsf@alter.siamese.dyndns.org/
>>
>> which probably is worth a read, too.
The project can say something like
# force older git to ignore
.config
# older git unignores "$.config" without touching ".config"
# but newer git applies the "last one wins" rule as usual
# to mark ".config" as precious.
!$.config
if our syntax were to retrofit '!' prefix, and even more simply
#:(precious)
.config
if we adopt Phillip's "comment abuse" idea, where older Git will
treat it as saying ".config" is not to be added but is expendable,
while newer Git will treat it as saying ".config" is not to be added
and not to be clobbered.
^ permalink raw reply
* Re: Bug: git diagnose crashes with Segmentation fault outside of git repository
From: Christian Couder @ 2023-10-14 17:22 UTC (permalink / raw)
To: ks1322 ks1322; +Cc: git, Victoria Dye
In-Reply-To: <CAKFQ_Q9WjF9i-Rx2jdCw-adPVQrWNfNKrDY-em8Rpa5RNLXz4A@mail.gmail.com>
On Sat, Oct 14, 2023 at 2:00 PM ks1322 ks1322 <ks1322@gmail.com> wrote:
>
> 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)
> Run `git diagnose` outside of any git repository
>
> What did you expect to happen? (Expected behavior)
> No crash, reasonable diagnose output
>
> What happened instead? (Actual behavior)
> `git diagnose` crashed with Segmentation fault
>
> $ git diagnose
> Collecting diagnostic info
>
> git version 2.41.0
> cpu: x86_64
> no commit associated with this build
> sizeof-long: 8
> sizeof-size_t: 8
> shell-path: /bin/sh
> Repository root: (null)
> Available space on '/tmp': 7.75 GiB (mount flags 0x6)
> Segmentation fault (core dumped)
Yeah, this is a valid bug report that I can reproduce. It looks like
such bugs have existed in this command since it was created last year.
Best,
Christian.
^ permalink raw reply
* Re: [PATCH] diagnose: require repository
From: Junio C Hamano @ 2023-10-14 17:15 UTC (permalink / raw)
To: Martin Ågren; +Cc: ks1322 ks1322, git, Victoria Dye
In-Reply-To: <20231014135302.13095-1-martin.agren@gmail.com>
Martin Ågren <martin.agren@gmail.com> writes:
> When `git diagnose` is run from outside a repo, it begins collecting
> various information before eventually hitting a segmentation fault,
> leaving an incomplete zip file behind.
>
> Switch from the gentle setup to requiring a git directory. Without a git
> repo, there isn't really much to diagnose.
>
> We could possibly do a best-effort collection of information about the
> machine and then give up. That would roughly be today's behavior but
> with a controlled exit rather than a segfault. However, the purpose of
> this tool is largely to create a zip archive. Rather than creating an
> empty zip file or no zip file at all, and having to explain that
> behavior, it seems more helpful to bail out clearly and early with a
> succinct error message.
Without having thought things through, offhand I agree with your "no
repository? there is nothing worth tarring up then" assessment.
Because "git bugreport --diag" unconditionally spawns "git
diagnose", the former may also want to be extra careful, perhaps
like the attached patch.
builtin/bugreport.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git c/builtin/bugreport.c w/builtin/bugreport.c
index d2ae5c305d..ac9e05fcf7 100644
--- c/builtin/bugreport.c
+++ w/builtin/bugreport.c
@@ -146,6 +146,11 @@ int cmd_bugreport(int argc, const char **argv, const char *prefix)
report_path.buf);
}
+ if (!startup_info->have_repository && diagnose != DIAGNOSE_NONE) {
+ warning(_("no repository--diagnostic output disabled"));
+ diagnose = DIAGNOSE_NONE;
+ }
+
/* Prepare diagnostics, if requested */
if (diagnose != DIAGNOSE_NONE) {
struct strbuf zip_path = STRBUF_INIT;
^ permalink raw reply related
* Re: [Outreachy Applicant]
From: Christian Couder @ 2023-10-14 16:41 UTC (permalink / raw)
To: estherugbiedah@gmail.com; +Cc: git@vger.kernel.org
In-Reply-To: <355182457.15373219.1697222676128@mail.yahoo.com>
Hi,
On Fri, Oct 13, 2023 at 8:44 PM estherugbiedah@gmail.com
<estherugbiedah@gmail.com> wrote:
>
> Hello Git Community,
>
> I am an Outreachy applicant for the 2023 cohort and I am thrilled to contribute to the Git project.
Thanks for your interest in Git and welcome to the Git community!
> Having reviewed the available projects, I am particularly interested in this project. I believe that contributing to this project will not only enhance my skills but also allow me to make a meaningful impact.
>
> I am ready and excited to immerse myself in the project and make valuable contributions.
Great, please take a look at the documentation we have on
https://git.github.io/, especially the pages and sections I mention
below.
First, we require that applicants make a small code contribution (we
call that a micro-project) to the Git project. This is explained here:
https://git.github.io/General-Microproject-Information/
and there is information about how to find micro-project ideas.
Now we have recently added a "Thoroughly check your eligibility in the
program" sub-section to that page. Please read it, check your
eligibility and confirm that you meet all the requirements soon.
Then there are links to tutorials and a number of other useful link
for Git developers on this page:
https://git.github.io/Hacking-Git/
Also the following page is useful as it contains more general
information about how to apply:
https://git.github.io/General-Application-Information/
Best,
Christian.
^ permalink raw reply
* Re: [PATCH] bugreport: add 'seconds' to default outfile name
From: Dragan Simic @ 2023-10-14 16:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jacob Stopak, git
In-Reply-To: <xmqq4jitw4nk.fsf@gitster.g>
On 2023-10-14 18:27, Junio C Hamano wrote:
> Jacob Stopak <jacob@initialcommit.io> writes:
>> If a user runs the bugreport command more than once within a calendar
>> minute, a filename conflict with an existing file occurs and the
>> program
>> errors, since the new output filename was already used for the
>> previous
>> file.
>
> This is totally expected and you made an excellent observation.
>
> I personally do not think it is a problem, simply because a quality
> bug report that would capture information necessary to diagnose any
> issue concisely in a readable fashion would take at least 90 seconds
> or more to produce, though.
>
> Instead of lengthening the filename for all files by 2 digits, the
> command can retry by adding say "+1", "+2", etc. after the failed
> filename to find a unique suffix within the same minute. It would
> mean that after writing git-bugreport-2023-10-14-0920.txt and you
> start another one without spending enough time, the new one may
> become git-bugreport-2023-10-14-0920+1.txt or something unique.
How about making the filename a bit shorter first, to make room for the
additional two digits, so the example mentioned above would end up being
named "git-bugreport-20231014-092037.txt"?
^ permalink raw reply
* Re: [PATCH] bugreport: add 'seconds' to default outfile name
From: Junio C Hamano @ 2023-10-14 16:27 UTC (permalink / raw)
To: Jacob Stopak; +Cc: git
In-Reply-To: <20231014040101.8333-1-jacob@initialcommit.io>
Jacob Stopak <jacob@initialcommit.io> writes:
> Currently, git bugreport postfixes the default bugreport filename (and
> diagnostics zip filename if --diagnose is supplied) with the current
> calendar hour and minute values, assuming the -s flag is absent.
Is "postfix" a verb that is commonly understood? I would say
"append" would be understood by more readers. Also, is "calendar"
hour different from other kinds of hours, perhaps stopwatch hours
and microwave-oven hours?
> If a user runs the bugreport command more than once within a calendar
> minute, a filename conflict with an existing file occurs and the program
> errors, since the new output filename was already used for the previous
> file.
This is totally expected and you made an excellent observation.
I personally do not think it is a problem, simply because a quality
bug report that would capture information necessary to diagnose any
issue concisely in a readable fashion would take at least 90 seconds
or more to produce, though.
Instead of lengthening the filename for all files by 2 digits, the
command can retry by adding say "+1", "+2", etc. after the failed
filename to find a unique suffix within the same minute. It would
mean that after writing git-bugreport-2023-10-14-0920.txt and you
start another one without spending enough time, the new one may
become git-bugreport-2023-10-14-0920+1.txt or something unique. It
would be really unlikely that you would run out after failing to
find a vacant single digit suffix nine times, i.e. trying "+9". It
would also help preserve existing user's workflow, e.g. they may
have written automation that assumes the down-to-minute format and
it would keep working on their bug reports without breaking.
^ permalink raw reply
* Re: [RFC] Define "precious" attribute and support it in `git clean`
From: Junio C Hamano @ 2023-10-14 16:10 UTC (permalink / raw)
To: Phillip Wood; +Cc: Sebastian Thiel, git, Josh Triplett, Kristoffer Haugsbakk
In-Reply-To: <0deee2bc-1775-4459-906d-1d44b3103499@gmail.com>
Phillip Wood <phillip.wood123@gmail.com> writes:
> One thought I had was that we could abuse the comment syntax to
> annotate paths something like
>
> #(keep)
> /my-precious-file
>
> would prevent /my-precious-file from being deleted by git clean (and
> hopefully unpack-trees()[1]). It means that older versions of git
> would treat the file as ignored. If we ever want more than one
> annotation per path we could separate them with commas
>
> #(keep,something-else)
> /my-file
>
> Strictly speaking it is a backward incompatible change but I doubt
> there are many people using comments like that.
;-)
If "#(" feels a bit too generic, that part can be bikeshed.
I might find some example use cases why we shouldn't later, but
offhand, the idea of (ab)using the comment is a very good idea.
^ permalink raw reply
* Re: [PATCH 5/8] commit-graph: read `BIDX` chunk with `pair_chunk_expect()`
From: Junio C Hamano @ 2023-10-14 16:10 UTC (permalink / raw)
To: Taylor Blau; +Cc: git, Jeff King
In-Reply-To: <45cac29403e63483951f7766c6da3c022c68d9f0.1697225110.git.me@ttaylorr.com>
Taylor Blau <me@ttaylorr.com> writes:
> -static int graph_read_bloom_index(const unsigned char *chunk_start,
> - size_t chunk_size, void *data)
> -{
> - struct commit_graph *g = data;
> - if (chunk_size != g->num_commits * 4) {
> - warning("commit-graph changed-path index chunk is too small");
> - return -1;
> - }
> ...
> @@ -461,8 +449,10 @@ struct commit_graph *parse_commit_graph(struct repo_settings *s,
> }
>
> if (s->commit_graph_read_changed_paths) {
> + if (pair_chunk_expect(cf, GRAPH_CHUNKID_BLOOMINDEXES,
> + &graph->chunk_bloom_indexes,
> + st_mult(graph->num_commits, 4)) == -1)
> + warning(_("commit-graph changed-path index chunk is too small (%d)"), graph->num_commits * 4);
> read_chunk(cf, GRAPH_CHUNKID_BLOOMDATA,
> graph_read_bloom_data, graph);
> }
Overall the series looked sane, but the need for each caller to
supply error messages, when the helper perfectly well knows how many
bytes the caller expected and how many bytes there are avaiable, was
a bit disturbing, as the level of detail given per each caller will
inevitably become uneven. Even now, some give an error() while
others give a warning(), even though I suspect all of them should be
data errors.
I wonder if it makes sense to stuff the message template in the
pair_chunk_data structure and do
static int pair_chunk_expect_fn(const unsigned char *chunk_start,
size_t chunk_size,
void *data)
{
struct pair_chunk_data *pcd = data;
if (pcd->expected_size != chunk_size)
return error(_(pcd->message), pcd->expected_size, chunk_size);
*pcd->p = chunk_start;
return 0;
}
^ permalink raw reply
* Bug: git grep --no-index 123 /dev/stdin crashes with SIGABRT
From: ks1322 ks1322 @ 2023-10-14 15:42 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)
`git grep --no-index 123 /dev/stdin` outside of git repository
What did you expect to happen? (Expected behavior)
Ability to grep input from stdin
What happened instead? (Actual behavior)
`git grep` crashed with SIGABRT
$ git grep --no-index 123 /dev/stdin
BUG: environment.c:215: git environment hasn't been setup
Aborted (core dumped)
What's different between what you expected and what actually happened?
Crash, no grep result
Anything else you want to add:
Plain grep can do that, so I suppose `git grep` could also:
$ echo -e "123\n456\n789" | grep 456 /dev/stdin
456
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.41.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 6.5.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Oct 6
19:02:35 UTC 2023 x86_64
compiler info: gnuc: 13.1
libc info: glibc: 2.37
$SHELL (typically, interactive shell): /bin/bash
[Enabled Hooks]
not run from a git repository - no hooks to show
^ permalink raw reply
* Re: [PATCH] diagnose: require repository
From: Kristoffer Haugsbakk @ 2023-10-14 14:56 UTC (permalink / raw)
To: Martin Ågren; +Cc: git, Victoria Dye, ks1322 ks1322
In-Reply-To: <20231014135302.13095-1-martin.agren@gmail.com>
On Sat, Oct 14, 2023, at 15:53, Martin Ågren wrote:
> Switch from the gentle setup to requiring a git directory. Without a git
> repo, there isn't really much to diagnose.
This patch works for me. Thanks.
--
Kristoffer Haugsbakk
^ permalink raw reply
* [PATCH] diagnose: require repository
From: Martin Ågren @ 2023-10-14 13:53 UTC (permalink / raw)
To: ks1322 ks1322; +Cc: git, Victoria Dye
In-Reply-To: <CAKFQ_Q9WjF9i-Rx2jdCw-adPVQrWNfNKrDY-em8Rpa5RNLXz4A@mail.gmail.com>
When `git diagnose` is run from outside a repo, it begins collecting
various information before eventually hitting a segmentation fault,
leaving an incomplete zip file behind.
Switch from the gentle setup to requiring a git directory. Without a git
repo, there isn't really much to diagnose.
We could possibly do a best-effort collection of information about the
machine and then give up. That would roughly be today's behavior but
with a controlled exit rather than a segfault. However, the purpose of
this tool is largely to create a zip archive. Rather than creating an
empty zip file or no zip file at all, and having to explain that
behavior, it seems more helpful to bail out clearly and early with a
succinct error message.
Reported-by: ks1322 ks1322 <ks1322@gmail.com>
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
---
Thanks for the report. This could be one way of fixing this.
I haven't found anything in the original submission [1] discussing this
"_GENTLY". I didn't see anything in the implementation or the tests
suggesting that it was intentional to run outside a git repo.
[1] https://lore.kernel.org/git/xmqqzgg1nz6v.fsf@gitster.g/t/#mc66904caab6bc79e57eaf5063df268b2725b6fcc
t/t0092-diagnose.sh | 5 +++++
git.c | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/t/t0092-diagnose.sh b/t/t0092-diagnose.sh
index 133e5747d6..49671d35a2 100755
--- a/t/t0092-diagnose.sh
+++ b/t/t0092-diagnose.sh
@@ -5,6 +5,11 @@ test_description='git diagnose'
TEST_PASSES_SANITIZE_LEAK=true
. ./test-lib.sh
+test_expect_success 'nothing to diagnose without repo' '
+ nongit test_must_fail git diagnose 2>err &&
+ grep "not a git repository" err
+'
+
test_expect_success UNZIP 'creates diagnostics zip archive' '
test_when_finished rm -rf report &&
diff --git a/git.c b/git.c
index c67e44dd82..ff04a74bbd 100644
--- a/git.c
+++ b/git.c
@@ -525,7 +525,7 @@ static struct cmd_struct commands[] = {
{ "credential-cache--daemon", cmd_credential_cache_daemon },
{ "credential-store", cmd_credential_store },
{ "describe", cmd_describe, RUN_SETUP },
- { "diagnose", cmd_diagnose, RUN_SETUP_GENTLY },
+ { "diagnose", cmd_diagnose, RUN_SETUP },
{ "diff", cmd_diff, NO_PARSEOPT },
{ "diff-files", cmd_diff_files, RUN_SETUP | NEED_WORK_TREE | NO_PARSEOPT },
{ "diff-index", cmd_diff_index, RUN_SETUP | NO_PARSEOPT },
--
2.42.0.399.g85a82e71e0
^ 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