* [PATCH 7/7] reftable/merged: transfer ownership of records when iterating
From: Patrick Steinhardt @ 2023-12-20 9:17 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1703063544.git.ps@pks.im>
[-- Attachment #1: Type: text/plain, Size: 2155 bytes --]
When iterating over recods with the merged iterator we put the records
into a priority queue before yielding them to the caller. This means
that we need to allocate the contents of these records before we can
pass them over to the caller.
The handover to the caller is quite inefficient though because we first
deallocate the record passed in by the caller and then copy over the new
record, which requires us to reallocate memory.
Refactor the code to instead transfer ownership of the new record to the
caller. So instead of reallocating all contents, we now release the old
record and then copy contents of the new record into place.
The following benchmark of `git show-ref --quiet` in a repository with
around 350k refs shows a clear improvement. Before:
HEAP SUMMARY:
in use at exit: 21,163 bytes in 193 blocks
total heap usage: 708,058 allocs, 707,865 frees, 36,783,255 bytes allocated
After:
HEAP SUMMARY:
in use at exit: 21,163 bytes in 193 blocks
total heap usage: 357,007 allocs, 356,814 frees, 24,193,602 bytes allocated
This shows that we now have roundabout a single allocation per record
that we're yielding from the iterator. Ideally, we'd also get rid of
this allocation so that the number of allocations doesn't scale with the
number of refs anymore. This would require some larger surgery though
because the memory is owned by the priority queue before transferring it
over to the caller.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
reftable/merged.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/reftable/merged.c b/reftable/merged.c
index a28bb99aaf..a52914d667 100644
--- a/reftable/merged.c
+++ b/reftable/merged.c
@@ -124,10 +124,12 @@ static int merged_iter_next_entry(struct merged_iter *mi,
reftable_record_release(&top.rec);
}
- reftable_record_copy_from(rec, &entry.rec, hash_size(mi->hash_id));
+ reftable_record_release(rec);
+ *rec = entry.rec;
done:
- reftable_record_release(&entry.rec);
+ if (err)
+ reftable_record_release(&entry.rec);
return err;
}
--
2.43.GIT
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related
* Re: [PATCH 4/7] reftable/record: store "val1" hashes as static arrays
From: Patrick Steinhardt @ 2023-12-20 9:25 UTC (permalink / raw)
To: git
In-Reply-To: <06c9eab67802ba933b44d32f5c8d11fddc216c26.1703063544.git.ps@pks.im>
[-- Attachment #1: Type: text/plain, Size: 1852 bytes --]
On Wed, Dec 20, 2023 at 10:17:17AM +0100, Patrick Steinhardt wrote:
> When reading ref records of type "val1" we store its object ID in an
> allocated array. This results in an additional allocation for every
> single ref record we read, which is rather inefficient especially when
> iterating over refs.
>
> Refactor the code to instead use a static array of `GIT_MAX_RAWSZ`
> bytes. While this means that `struct ref_record` is bigger now, we
> typically do not store all refs in an array anyway and instead only
> handle a limited number of records at the same point in time.
>
> Using `git show-ref --quiet` in a repository with ~350k refs this leads
> to a significant drop in allocations. Before:
>
> HEAP SUMMARY:
> in use at exit: 21,098 bytes in 192 blocks
> total heap usage: 2,116,683 allocs, 2,116,491 frees, 76,098,060 bytes allocated
>
> After:
>
> HEAP SUMMARY:
> in use at exit: 21,098 bytes in 192 blocks
> total heap usage: 1,419,031 allocs, 1,418,839 frees, 62,145,036 bytes allocated
>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
I screwed up the rebase. The following diff is required on top:
diff --git a/reftable/readwrite_test.c b/reftable/readwrite_test.c
index 56c0b4db5d..87b238105c 100644
--- a/reftable/readwrite_test.c
+++ b/reftable/readwrite_test.c
@@ -809,11 +809,10 @@ static void test_write_multiple_indices(void)
writer = reftable_new_writer(&strbuf_add_void, &writer_buf, &opts);
reftable_writer_set_limits(writer, 1, 1);
for (i = 0; i < 100; i++) {
- unsigned char hash[GIT_SHA1_RAWSZ] = {i};
struct reftable_ref_record ref = {
.update_index = 1,
.value_type = REFTABLE_REF_VAL1,
- .value.val1 = hash,
+ .value.val1 = {i},
};
strbuf_reset(&buf);
Will fix in v2 of this series.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related
* [PATCH v3] Teach git apply to respect core.fileMode settings
From: Chandra Pratap via GitGitGadget @ 2023-12-20 10:08 UTC (permalink / raw)
To: git; +Cc: Torsten Bögershausen, Chandra Pratap, Chandra Pratap
In-Reply-To: <pull.1620.v2.git.1703010646036.gitgitgadget@gmail.com>
From: Chandra Pratap <chandrapratap3519@gmail.com>
When applying a patch that adds an executable file, git apply
ignores the core.fileMode setting (core.fileMode in git config
specifies whether the executable bit on files in the working tree
should be honored or not) resulting in warnings like:
warning: script.sh has type 100644, expected 100755
even when core.fileMode is set to false, which is undesired. This
is extra true for systems like Windows.
Fix this by inferring the correct file mode from the existing
index entry when core.filemode is set to false. Add a test case
that verifies the change and prevents future regression.
Signed-off-by: Chandra Pratap <chandrapratap3519@gmail.com>
---
apply: make git apply respect core.fileMode settings
Regarding this:
> I am wondering if we want to be more strict about hiding error return
> code from "git ls-files" and "git ls-tree" behind pipes like these.
> Usually we encourage using a temporary file, e.g., ... git ls-files -s
> script.sh >ls-files-output && test_grep "^100755" ls-files-output &&
> ...
I have modified the patch so that the output of git ls-files and git
ls-tree are stored in a temporary file instead of being directly piped
to grep but also noticed similar working in other test cases in the same
test file. For example,
test_expect_success FILEMODE 'same mode (index only)' ' .... .... ....
git ls-files -s file | grep "^100755"
and
test_expect_success FILEMODE 'mode update (index only)' ' ... ... ...
git ls-files -s file | grep "^100755"
Would we want to modify these scripts as well so they follow the same
convention as above or is it okay to let them be as is?
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1620%2FChand-ra%2Fdevel-v3
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1620/Chand-ra/devel-v3
Pull-Request: https://github.com/gitgitgadget/git/pull/1620
Range-diff vs v2:
1: 29c8c6d120e ! 1: 9a3623edfd2 Teach git apply to respect core.fileMode settings
@@ Commit message
warning: script.sh has type 100644, expected 100755
even when core.fileMode is set to false, which is undesired. This
- is extra true for systems like Windows, which don't rely on "lsat()".
+ is extra true for systems like Windows.
Fix this by inferring the correct file mode from the existing
- index entry when core.filemode is set to false. The added
- test case helps verify the change and prevents future regression.
+ index entry when core.filemode is set to false. Add a test case
+ that verifies the change and prevents future regression.
- Reviewed-by: Johannes Schindelin <johannes.schindelin@gmail.com>
Signed-off-by: Chandra Pratap <chandrapratap3519@gmail.com>
## apply.c ##
@@ t/t4129-apply-samemode.sh: test_expect_success POSIXPERM 'do not use core.shared
)
'
-+test_expect_success 'ensure git apply respects core.fileMode' '
++test_expect_success 'git apply respects core.fileMode' '
+ test_config core.fileMode false &&
+ echo true >script.sh &&
+ git add --chmod=+x script.sh &&
-+ git ls-files -s script.sh | grep "^100755" &&
++ git ls-files -s script.sh > ls-files-output &&
++ test_grep "^100755" ls-files-output &&
+ test_tick && git commit -m "Add script" &&
-+ git ls-tree -r HEAD script.sh | grep "^100755" &&
++ git ls-tree -r HEAD script.sh > ls-tree-output &&
++ test_grep "^100755" ls-tree-output &&
+
+ echo true >>script.sh &&
+ test_tick && git commit -m "Modify script" script.sh &&
+ git format-patch -1 --stdout >patch &&
-+ grep "index.*100755" patch &&
++ test_grep "^index.*100755$" patch &&
+
+ git switch -c branch HEAD^ &&
+ git apply --index patch 2>err &&
-+ ! grep "has type 100644, expected 100755" err &&
-+ git restore -S script.sh && git restore script.sh &&
++ test_grep ! "has type 100644, expected 100755" err &&
++ git reset --hard &&
+
+ git apply patch 2>err &&
-+ ! grep "has type 100644, expected 100755" err &&
++ test_grep ! "has type 100644, expected 100755" err &&
+
+ git apply --cached patch 2>err &&
-+ ! grep "has type 100644, expected 100755" err
++ test_grep ! "has type 100644, expected 100755" err
+'
+
test_done
apply.c | 8 ++++++--
t/t4129-apply-samemode.sh | 27 +++++++++++++++++++++++++++
2 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/apply.c b/apply.c
index 3d69fec836d..58f26c40413 100644
--- a/apply.c
+++ b/apply.c
@@ -3778,8 +3778,12 @@ static int check_preimage(struct apply_state *state,
return error_errno("%s", old_name);
}
- if (!state->cached && !previous)
- st_mode = ce_mode_from_stat(*ce, st->st_mode);
+ if (!state->cached && !previous) {
+ if (!trust_executable_bit)
+ st_mode = *ce ? (*ce)->ce_mode : patch->old_mode;
+ else
+ st_mode = ce_mode_from_stat(*ce, st->st_mode);
+ }
if (patch->is_new < 0)
patch->is_new = 0;
diff --git a/t/t4129-apply-samemode.sh b/t/t4129-apply-samemode.sh
index e7a7295f1b6..ff0c1602fd5 100755
--- a/t/t4129-apply-samemode.sh
+++ b/t/t4129-apply-samemode.sh
@@ -101,4 +101,31 @@ test_expect_success POSIXPERM 'do not use core.sharedRepository for working tree
)
'
+test_expect_success 'git apply respects core.fileMode' '
+ test_config core.fileMode false &&
+ echo true >script.sh &&
+ git add --chmod=+x script.sh &&
+ git ls-files -s script.sh > ls-files-output &&
+ test_grep "^100755" ls-files-output &&
+ test_tick && git commit -m "Add script" &&
+ git ls-tree -r HEAD script.sh > ls-tree-output &&
+ test_grep "^100755" ls-tree-output &&
+
+ echo true >>script.sh &&
+ test_tick && git commit -m "Modify script" script.sh &&
+ git format-patch -1 --stdout >patch &&
+ test_grep "^index.*100755$" patch &&
+
+ git switch -c branch HEAD^ &&
+ git apply --index patch 2>err &&
+ test_grep ! "has type 100644, expected 100755" err &&
+ git reset --hard &&
+
+ git apply patch 2>err &&
+ test_grep ! "has type 100644, expected 100755" err &&
+
+ git apply --cached patch 2>err &&
+ test_grep ! "has type 100644, expected 100755" err
+'
+
test_done
base-commit: 1a87c842ece327d03d08096395969aca5e0a6996
--
gitgitgadget
^ permalink raw reply related
* [PATCH 00/12] Introduce `refStorage` extension
From: Patrick Steinhardt @ 2023-12-20 10:54 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 4087 bytes --]
Hi,
this patch series introduces a new `refStorage` extension and related
tooling. While there is only a single user-visible ref backend for now,
this extension will eventually allow us to determine which backend shall
be used for a repository. Furthermore, the series introduces tooling so
that the ref storage format becomes more accessible.
The series is structured as follows:
- Patches 1 - 3: preliminary refactorings that prepare for the
introduction of the ref storage format.
- Patches 4 - 6: wire up the ref format when setting up the repository
and creating a new one.
- Patches 7 - 8: introduction of envvars to control the ref format
globally.
- Patches 9 - 11: amend our tooling to know how to access and set the
ref storage format.
- Patch 12: small patch for t9500 to make it handle ref storage
extensions in the future.
I've been kind of torn regarding how to name this in the user-facing
parts. Even though the extension is called "refStorage", I rather opted
to use "ref format" in the user-facing parts, which is similar in nature
to the "object format". Changing the extension to be called "refFormat"
would cause issues for JGit though, so it's likely not an option to
change it now.
Anyway, I'd appreciate your thoughts and proposals and am happy to
rename the user-facing parts if we get to a preferable agreement.
This series depends on 18c9cb7524 (builtin/clone: create the refdb with
the correct object format, 2023-12-12) because it relies on the more
careful setup of the repository's refdb during clones.
Thanks!
Patrick
Patrick Steinhardt (12):
t: introduce DEFAULT_REPO_FORMAT prereq
worktree: skip reading HEAD when repairing worktrees
refs: refactor logic to look up storage backends
setup: start tracking ref storage format when
setup: set repository's formats on init
setup: introduce "extensions.refStorage" extension
setup: introduce GIT_DEFAULT_REF_FORMAT envvar
t: introduce GIT_TEST_DEFAULT_REF_FORMAT envvar
builtin/rev-parse: introduce `--show-ref-format` flag
builtin/init: introduce `--ref-format=` value flag
builtin/clone: introduce `--ref-format=` value flag
t9500: write "extensions.refstorage" into config
Documentation/config/extensions.txt | 11 +++
Documentation/git-clone.txt | 6 ++
Documentation/git-init.txt | 7 ++
Documentation/git-rev-parse.txt | 3 +
Documentation/git.txt | 5 ++
Documentation/ref-storage-format.txt | 1 +
.../technical/repository-version.txt | 5 ++
builtin/clone.c | 17 ++++-
builtin/init-db.c | 15 +++-
builtin/rev-parse.c | 4 ++
refs.c | 34 ++++++---
refs.h | 4 ++
refs/debug.c | 1 -
refs/files-backend.c | 1 -
refs/packed-backend.c | 1 -
refs/refs-internal.h | 1 -
repository.c | 1 +
repository.h | 6 ++
setup.c | 63 +++++++++++++++--
setup.h | 9 ++-
t/README | 3 +
t/t0001-init.sh | 70 +++++++++++++++++++
t/t1500-rev-parse.sh | 17 +++++
t/t3200-branch.sh | 2 +-
t/t5601-clone.sh | 17 +++++
t/t9500-gitweb-standalone-no-errors.sh | 5 ++
t/test-lib-functions.sh | 5 ++
t/test-lib.sh | 15 +++-
worktree.c | 24 ++++---
29 files changed, 318 insertions(+), 35 deletions(-)
create mode 100644 Documentation/ref-storage-format.txt
--
2.43.GIT
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH 01/12] t: introduce DEFAULT_REPO_FORMAT prereq
From: Patrick Steinhardt @ 2023-12-20 10:54 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1703067989.git.ps@pks.im>
[-- Attachment #1: Type: text/plain, Size: 1588 bytes --]
A limited number of tests require repositories to have the default
repository format or otherwise they would fail to run, e.g. because they
fail to detect the correct hash function. While the hash function is the
only extension right now that creates problems like this, we are about
to add a second extensions for the ref format.
Introduce a new DEFAULT_REPO_FORMAT prereq that can easily be amended
whenever we add new format extensions. Next to making any such changes
easier on us, the prerequisite's name should also help to clarify the
intent better.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
t/t3200-branch.sh | 2 +-
t/test-lib.sh | 4 ++++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 6a316f081e..de7d3014e4 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -519,7 +519,7 @@ EOF
mv .git/config .git/config-saved
-test_expect_success SHA1 'git branch -m q q2 without config should succeed' '
+test_expect_success DEFAULT_REPO_FORMAT 'git branch -m q q2 without config should succeed' '
git branch -m q q2 &&
git branch -m q2 q
'
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 876b99562a..dc03f06b8e 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -1936,6 +1936,10 @@ test_lazy_prereq SHA1 '
esac
'
+test_lazy_prereq DEFAULT_REPO_FORMAT '
+ test_have_prereq SHA1
+'
+
# Ensure that no test accidentally triggers a Git command
# that runs the actual maintenance scheduler, affecting a user's
# system permanently.
--
2.43.GIT
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related
* [PATCH 02/12] worktree: skip reading HEAD when repairing worktrees
From: Patrick Steinhardt @ 2023-12-20 10:54 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1703067989.git.ps@pks.im>
[-- Attachment #1: Type: text/plain, Size: 4307 bytes --]
When calling `git init --separate-git-dir=<new-path>` on a preexisting
repository, then we move the Git directory of that repository to the new
path specified by the user. If there are worktrees present in the Git
repository, we need to repair the worktrees so that their gitlinks point
to the new location of the repository.
This repair logic will load repositories via `get_worktrees()`, which
will enumerate up and initialize all worktrees. Part of initialization
is logic that we resolve their respective worktree HEADs, even though
that information may not actually be needed in the end by all callers.
In the context of git-init(1) this is about to become a problem, because
we do not have a repository that was set up via `setup_git_directory()`
or friends. Consequentially, it is not yet fully initialized at the time
of calling `repair_worktrees()`, and properly setting up all parts of
the repository in `init_db()` before we repair worktrees is not an easy
thing to do. While this is okay right now where we only have a single
reference backend in Git, once we gain a second one we would be trying
to look up the worktree HEADs before we have figured out the reference
format, which does not work.
We do not require the worktree HEADs at all to repair worktrees. So
let's fix issue this by skipping over the step that reads them.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
worktree.c | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/worktree.c b/worktree.c
index a56a6c2a3d..9702ed0308 100644
--- a/worktree.c
+++ b/worktree.c
@@ -51,7 +51,7 @@ static void add_head_info(struct worktree *wt)
/**
* get the main worktree
*/
-static struct worktree *get_main_worktree(void)
+static struct worktree *get_main_worktree(int skip_reading_head)
{
struct worktree *worktree = NULL;
struct strbuf worktree_path = STRBUF_INIT;
@@ -70,11 +70,13 @@ static struct worktree *get_main_worktree(void)
*/
worktree->is_bare = (is_bare_repository_cfg == 1) ||
is_bare_repository();
- add_head_info(worktree);
+ if (!skip_reading_head)
+ add_head_info(worktree);
return worktree;
}
-static struct worktree *get_linked_worktree(const char *id)
+static struct worktree *get_linked_worktree(const char *id,
+ int skip_reading_head)
{
struct worktree *worktree = NULL;
struct strbuf path = STRBUF_INIT;
@@ -93,7 +95,8 @@ static struct worktree *get_linked_worktree(const char *id)
CALLOC_ARRAY(worktree, 1);
worktree->path = strbuf_detach(&worktree_path, NULL);
worktree->id = xstrdup(id);
- add_head_info(worktree);
+ if (!skip_reading_head)
+ add_head_info(worktree);
done:
strbuf_release(&path);
@@ -118,7 +121,7 @@ static void mark_current_worktree(struct worktree **worktrees)
free(git_dir);
}
-struct worktree **get_worktrees(void)
+static struct worktree **get_worktrees_internal(int skip_reading_head)
{
struct worktree **list = NULL;
struct strbuf path = STRBUF_INIT;
@@ -128,7 +131,7 @@ struct worktree **get_worktrees(void)
ALLOC_ARRAY(list, alloc);
- list[counter++] = get_main_worktree();
+ list[counter++] = get_main_worktree(skip_reading_head);
strbuf_addf(&path, "%s/worktrees", get_git_common_dir());
dir = opendir(path.buf);
@@ -137,7 +140,7 @@ struct worktree **get_worktrees(void)
while ((d = readdir_skip_dot_and_dotdot(dir)) != NULL) {
struct worktree *linked = NULL;
- if ((linked = get_linked_worktree(d->d_name))) {
+ if ((linked = get_linked_worktree(d->d_name, skip_reading_head))) {
ALLOC_GROW(list, counter + 1, alloc);
list[counter++] = linked;
}
@@ -151,6 +154,11 @@ struct worktree **get_worktrees(void)
return list;
}
+struct worktree **get_worktrees(void)
+{
+ return get_worktrees_internal(0);
+}
+
const char *get_worktree_git_dir(const struct worktree *wt)
{
if (!wt)
@@ -591,7 +599,7 @@ static void repair_noop(int iserr UNUSED,
void repair_worktrees(worktree_repair_fn fn, void *cb_data)
{
- struct worktree **worktrees = get_worktrees();
+ struct worktree **worktrees = get_worktrees_internal(1);
struct worktree **wt = worktrees + 1; /* +1 skips main worktree */
if (!fn)
--
2.43.GIT
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related
* [PATCH 03/12] refs: refactor logic to look up storage backends
From: Patrick Steinhardt @ 2023-12-20 10:55 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1703067989.git.ps@pks.im>
[-- Attachment #1: Type: text/plain, Size: 5190 bytes --]
In order to look up ref storage backends, we're currently using a linked
list of backends, where each backend is expected to set up its `next`
pointer to the next ref storage backend. This is kind of a weird setup
as backends need to be aware of other backends without much of a reason.
Refactor the code so that the array of backends is centrally defined in
"refs.c", where each backend is now identified by an integer constant.
Expose functions to translate from those integer constants to the name
and vice versa, which will be required by subsequent patches.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
refs.c | 34 +++++++++++++++++++++++++---------
refs.h | 3 +++
refs/debug.c | 1 -
refs/files-backend.c | 1 -
refs/packed-backend.c | 1 -
refs/refs-internal.h | 1 -
repository.h | 3 +++
7 files changed, 31 insertions(+), 13 deletions(-)
diff --git a/refs.c b/refs.c
index 16bfa21df7..e87c85897d 100644
--- a/refs.c
+++ b/refs.c
@@ -33,17 +33,33 @@
/*
* List of all available backends
*/
-static struct ref_storage_be *refs_backends = &refs_be_files;
+static const struct ref_storage_be *refs_backends[] = {
+ [REF_STORAGE_FORMAT_FILES] = &refs_be_files,
+};
-static struct ref_storage_be *find_ref_storage_backend(const char *name)
+static const struct ref_storage_be *find_ref_storage_backend(int ref_storage_format)
{
- struct ref_storage_be *be;
- for (be = refs_backends; be; be = be->next)
- if (!strcmp(be->name, name))
- return be;
+ if (ref_storage_format && ref_storage_format < ARRAY_SIZE(refs_backends))
+ return refs_backends[ref_storage_format];
return NULL;
}
+int ref_storage_format_by_name(const char *name)
+{
+ for (int i = 0; i < ARRAY_SIZE(refs_backends); i++)
+ if (refs_backends[i] && !strcmp(refs_backends[i]->name, name))
+ return i;
+ return REF_STORAGE_FORMAT_UNKNOWN;
+}
+
+const char *ref_storage_format_to_name(int ref_storage_format)
+{
+ const struct ref_storage_be *be = find_ref_storage_backend(ref_storage_format);
+ if (!be)
+ return "unknown";
+ return be->name;
+}
+
/*
* How to handle various characters in refnames:
* 0: An acceptable character for refs
@@ -2029,12 +2045,12 @@ static struct ref_store *ref_store_init(struct repository *repo,
const char *gitdir,
unsigned int flags)
{
- const char *be_name = "files";
- struct ref_storage_be *be = find_ref_storage_backend(be_name);
+ int format = REF_STORAGE_FORMAT_FILES;
+ const struct ref_storage_be *be = find_ref_storage_backend(format);
struct ref_store *refs;
if (!be)
- BUG("reference backend %s is unknown", be_name);
+ BUG("reference backend %s is unknown", ref_storage_format_to_name(format));
refs = be->init(repo, gitdir, flags);
return refs;
diff --git a/refs.h b/refs.h
index 23211a5ea1..c6571bcf6c 100644
--- a/refs.h
+++ b/refs.h
@@ -11,6 +11,9 @@ struct string_list;
struct string_list_item;
struct worktree;
+int ref_storage_format_by_name(const char *name);
+const char *ref_storage_format_to_name(int ref_storage_format);
+
/*
* Resolve a reference, recursively following symbolic refererences.
*
diff --git a/refs/debug.c b/refs/debug.c
index 83b7a0ba65..b9775f2c37 100644
--- a/refs/debug.c
+++ b/refs/debug.c
@@ -426,7 +426,6 @@ static int debug_reflog_expire(struct ref_store *ref_store, const char *refname,
}
struct ref_storage_be refs_be_debug = {
- .next = NULL,
.name = "debug",
.init = NULL,
.init_db = debug_init_db,
diff --git a/refs/files-backend.c b/refs/files-backend.c
index ad8b1d143f..43fd0ac760 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -3241,7 +3241,6 @@ static int files_init_db(struct ref_store *ref_store, struct strbuf *err UNUSED)
}
struct ref_storage_be refs_be_files = {
- .next = NULL,
.name = "files",
.init = files_ref_store_create,
.init_db = files_init_db,
diff --git a/refs/packed-backend.c b/refs/packed-backend.c
index b9fa097a29..8d1090e284 100644
--- a/refs/packed-backend.c
+++ b/refs/packed-backend.c
@@ -1705,7 +1705,6 @@ static struct ref_iterator *packed_reflog_iterator_begin(struct ref_store *ref_s
}
struct ref_storage_be refs_be_packed = {
- .next = NULL,
.name = "packed",
.init = packed_ref_store_create,
.init_db = packed_init_db,
diff --git a/refs/refs-internal.h b/refs/refs-internal.h
index 4af83bf9a5..8e9f04cc67 100644
--- a/refs/refs-internal.h
+++ b/refs/refs-internal.h
@@ -663,7 +663,6 @@ typedef int read_symbolic_ref_fn(struct ref_store *ref_store, const char *refnam
struct strbuf *referent);
struct ref_storage_be {
- struct ref_storage_be *next;
const char *name;
ref_store_init_fn *init;
ref_init_db_fn *init_db;
diff --git a/repository.h b/repository.h
index 5f18486f64..ea4c488b81 100644
--- a/repository.h
+++ b/repository.h
@@ -24,6 +24,9 @@ enum fetch_negotiation_setting {
FETCH_NEGOTIATION_NOOP,
};
+#define REF_STORAGE_FORMAT_UNKNOWN 0
+#define REF_STORAGE_FORMAT_FILES 1
+
struct repo_settings {
int initialized;
--
2.43.GIT
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related
* [PATCH 04/12] setup: start tracking ref storage format when
From: Patrick Steinhardt @ 2023-12-20 10:55 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1703067989.git.ps@pks.im>
[-- Attachment #1: Type: text/plain, Size: 9599 bytes --]
In order to discern which ref storage format a repository is supposed to
use we need to start setting up and/or discovering the format. This
needs to happen in two separate code paths.
- The first path is when we create a repository via `init_db()`. When
we are re-initializing a preexisting repository we need to retain
the previously used ref storage format -- if the user asked for a
different format then this indicates an erorr and we error out.
Otherwise we either initialize the repository with the format asked
for by the user or the default format, which currently is the
"files" backend.
- The second path is when discovering repositories, where we need to
read the config of that repository. There is not yet any way to
configure something other than the "files" backend, so we can just
blindly set the ref storage format to this backend.
Wire up this logic so that we have the ref storage format always readily
available when needed. As there is only a single backend and because it
is not configurable we cannot yet verify that this tracking works as
expected via tests, but tests will be added in subsequent commits. To
countermand this ommission now though, raise a BUG() in case the ref
storage format is not set up properly in `ref_store_init()`.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
builtin/clone.c | 5 +++--
builtin/init-db.c | 4 +++-
refs.c | 6 +++---
refs.h | 1 +
repository.c | 1 +
repository.h | 3 +++
setup.c | 26 +++++++++++++++++++++++---
setup.h | 6 +++++-
8 files changed, 42 insertions(+), 10 deletions(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index 339af10c10..6840064b59 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -1105,7 +1105,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
* repository, and reference backends may persist that information into
* their on-disk data structures.
*/
- init_db(git_dir, real_git_dir, option_template, GIT_HASH_UNKNOWN, NULL,
+ init_db(git_dir, real_git_dir, option_template, GIT_HASH_UNKNOWN,
+ REF_STORAGE_FORMAT_UNKNOWN, NULL,
do_not_override_repo_unix_permissions, INIT_DB_QUIET | INIT_DB_SKIP_REFDB);
if (real_git_dir) {
@@ -1290,7 +1291,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
hash_algo = hash_algo_by_ptr(transport_get_hash_algo(transport));
initialize_repository_version(hash_algo, 1);
repo_set_hash_algo(the_repository, hash_algo);
- create_reference_database(NULL, 1);
+ create_reference_database(the_repository->ref_storage_format, NULL, 1);
/*
* Before fetching from the remote, download and install bundle
diff --git a/builtin/init-db.c b/builtin/init-db.c
index cb727c826f..b6e80feab6 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -11,6 +11,7 @@
#include "object-file.h"
#include "parse-options.h"
#include "path.h"
+#include "refs.h"
#include "setup.h"
#include "strbuf.h"
@@ -236,5 +237,6 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
flags |= INIT_DB_EXIST_OK;
return init_db(git_dir, real_git_dir, template_dir, hash_algo,
- initial_branch, init_shared_repository, flags);
+ REF_STORAGE_FORMAT_UNKNOWN, initial_branch,
+ init_shared_repository, flags);
}
diff --git a/refs.c b/refs.c
index e87c85897d..d289a5e175 100644
--- a/refs.c
+++ b/refs.c
@@ -2045,12 +2045,12 @@ static struct ref_store *ref_store_init(struct repository *repo,
const char *gitdir,
unsigned int flags)
{
- int format = REF_STORAGE_FORMAT_FILES;
- const struct ref_storage_be *be = find_ref_storage_backend(format);
+ const struct ref_storage_be *be;
struct ref_store *refs;
+ be = find_ref_storage_backend(repo->ref_storage_format);
if (!be)
- BUG("reference backend %s is unknown", ref_storage_format_to_name(format));
+ BUG("reference backend is unknown");
refs = be->init(repo, gitdir, flags);
return refs;
diff --git a/refs.h b/refs.h
index c6571bcf6c..944a67ac1b 100644
--- a/refs.h
+++ b/refs.h
@@ -11,6 +11,7 @@ struct string_list;
struct string_list_item;
struct worktree;
+int default_ref_storage_format(void);
int ref_storage_format_by_name(const char *name);
const char *ref_storage_format_to_name(int ref_storage_format);
diff --git a/repository.c b/repository.c
index a7679ceeaa..a75c1598b0 100644
--- a/repository.c
+++ b/repository.c
@@ -184,6 +184,7 @@ int repo_init(struct repository *repo,
goto error;
repo_set_hash_algo(repo, format.hash_algo);
+ repo->ref_storage_format = format.ref_storage_format;
repo->repository_format_worktree_config = format.worktree_config;
/* take ownership of format.partial_clone */
diff --git a/repository.h b/repository.h
index ea4c488b81..22c30cdbc9 100644
--- a/repository.h
+++ b/repository.h
@@ -163,6 +163,9 @@ struct repository {
/* Repository's current hash algorithm, as serialized on disk. */
const struct git_hash_algo *hash_algo;
+ /* Repository's reference storage format, as serialized on disk. */
+ int ref_storage_format;
+
/* A unique-id for tracing purposes. */
int trace2_repo_id;
diff --git a/setup.c b/setup.c
index 155fe13f70..c1bf106379 100644
--- a/setup.c
+++ b/setup.c
@@ -1564,6 +1564,8 @@ const char *setup_git_directory_gently(int *nongit_ok)
}
if (startup_info->have_repository) {
repo_set_hash_algo(the_repository, repo_fmt.hash_algo);
+ the_repository->ref_storage_format =
+ repo_fmt.ref_storage_format;
the_repository->repository_format_worktree_config =
repo_fmt.worktree_config;
/* take ownership of repo_fmt.partial_clone */
@@ -1657,6 +1659,8 @@ void check_repository_format(struct repository_format *fmt)
check_repository_format_gently(get_git_dir(), fmt, NULL);
startup_info->have_repository = 1;
repo_set_hash_algo(the_repository, fmt->hash_algo);
+ the_repository->ref_storage_format =
+ fmt->ref_storage_format;
the_repository->repository_format_worktree_config =
fmt->worktree_config;
the_repository->repository_format_partial_clone =
@@ -1897,7 +1901,8 @@ static int is_reinit(void)
return ret;
}
-void create_reference_database(const char *initial_branch, int quiet)
+void create_reference_database(int ref_storage_format,
+ const char *initial_branch, int quiet)
{
struct strbuf err = STRBUF_INIT;
int reinit = is_reinit();
@@ -1917,6 +1922,7 @@ void create_reference_database(const char *initial_branch, int quiet)
safe_create_dir(git_path("refs"), 1);
adjust_shared_perm(git_path("refs"));
+ the_repository->ref_storage_format = ref_storage_format;
if (refs_init_db(&err))
die("failed to set up refs db: %s", err.buf);
@@ -2135,8 +2141,20 @@ static void validate_hash_algorithm(struct repository_format *repo_fmt, int hash
}
}
+static void validate_ref_storage_format(struct repository_format *repo_fmt, int format)
+{
+ if (repo_fmt->version >= 0 &&
+ format != REF_STORAGE_FORMAT_UNKNOWN &&
+ format != repo_fmt->ref_storage_format) {
+ die(_("attempt to reinitialize repository with different reference storage format"));
+ } else if (format != REF_STORAGE_FORMAT_UNKNOWN) {
+ repo_fmt->ref_storage_format = format;
+ }
+}
+
int init_db(const char *git_dir, const char *real_git_dir,
- const char *template_dir, int hash, const char *initial_branch,
+ const char *template_dir, int hash,
+ int ref_storage_format, const char *initial_branch,
int init_shared_repository, unsigned int flags)
{
int reinit;
@@ -2179,13 +2197,15 @@ int init_db(const char *git_dir, const char *real_git_dir,
check_repository_format(&repo_fmt);
validate_hash_algorithm(&repo_fmt, hash);
+ validate_ref_storage_format(&repo_fmt, ref_storage_format);
reinit = create_default_files(template_dir, original_git_dir,
&repo_fmt, prev_bare_repository,
init_shared_repository);
if (!(flags & INIT_DB_SKIP_REFDB))
- create_reference_database(initial_branch, flags & INIT_DB_QUIET);
+ create_reference_database(repo_fmt.ref_storage_format,
+ initial_branch, flags & INIT_DB_QUIET);
create_object_directory();
if (get_shared_repository()) {
diff --git a/setup.h b/setup.h
index 3f0f17c351..4927abf2cf 100644
--- a/setup.h
+++ b/setup.h
@@ -115,6 +115,7 @@ struct repository_format {
int worktree_config;
int is_bare;
int hash_algo;
+ int ref_storage_format;
int sparse_index;
char *work_tree;
struct string_list unknown_extensions;
@@ -131,6 +132,7 @@ struct repository_format {
.version = -1, \
.is_bare = -1, \
.hash_algo = GIT_HASH_SHA1, \
+ .ref_storage_format = REF_STORAGE_FORMAT_FILES, \
.unknown_extensions = STRING_LIST_INIT_DUP, \
.v1_only_extensions = STRING_LIST_INIT_DUP, \
}
@@ -175,10 +177,12 @@ void check_repository_format(struct repository_format *fmt);
int init_db(const char *git_dir, const char *real_git_dir,
const char *template_dir, int hash_algo,
+ int ref_storage_format,
const char *initial_branch, int init_shared_repository,
unsigned int flags);
void initialize_repository_version(int hash_algo, int reinit);
-void create_reference_database(const char *initial_branch, int quiet);
+void create_reference_database(int ref_storage_format,
+ const char *initial_branch, int quiet);
/*
* NOTE NOTE NOTE!!
--
2.43.GIT
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related
* [PATCH 05/12] setup: set repository's formats on init
From: Patrick Steinhardt @ 2023-12-20 10:55 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1703067989.git.ps@pks.im>
[-- Attachment #1: Type: text/plain, Size: 2228 bytes --]
The proper hash algorithm and ref storage format that will be used for a
newly initialized repository will be figured out in `init_db()` via
`validate_hash_algorithm()` and `validate_ref_storage_format()`. Until
now though, we never set up the hash algorithm or ref storage format of
`the_repository` accordingly.
There are only two callsites of `init_db()`, one in git-init(1) and one
in git-clone(1). The former function doesn't care for the formats to be
set up properly because it never access the repository after calling the
function in the first place.
For git-clone(1) it's a different story though, as we call `init_db()`
before listing remote refs. While we do indeed have the wrong hash
function in `the_repository` when `init_db()` sets up a non-default
object format for the repository, it never mattered because we adjust
the hash after learning about the remote's hash function via the listed
refs.
So the current state is correct for the hash algo, but it's not for the
ref storage format because git-clone(1) wouldn't know to set it up
properly. But instead of adjusting only the `ref_storage_format`, set
both the hash algo and the ref storage format so that `the_repository`
is in the correct state when `init_db()` exits. This is fine as we will
adjust the hash later on anyway and makes it easier to reason about the
end state of `the_repository`.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
setup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/setup.c b/setup.c
index c1bf106379..5dffea6e2f 100644
--- a/setup.c
+++ b/setup.c
@@ -2203,6 +2203,13 @@ int init_db(const char *git_dir, const char *real_git_dir,
&repo_fmt, prev_bare_repository,
init_shared_repository);
+ /*
+ * Now that we have set up both the hash algorithm and the ref storage
+ * format we can update the repository's settings accordingly.
+ */
+ the_repository->hash_algo = &hash_algos[repo_fmt.hash_algo];
+ the_repository->ref_storage_format = repo_fmt.ref_storage_format;
+
if (!(flags & INIT_DB_SKIP_REFDB))
create_reference_database(repo_fmt.ref_storage_format,
initial_branch, flags & INIT_DB_QUIET);
--
2.43.GIT
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related
* [PATCH 06/12] setup: introduce "extensions.refStorage" extension
From: Patrick Steinhardt @ 2023-12-20 10:55 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1703067989.git.ps@pks.im>
[-- Attachment #1: Type: text/plain, Size: 9372 bytes --]
Introduce a new "extensions.refStorage" extension that allows us to
specify the ref storage format used by a repository. For now, the only
supported format is the "files" format, but this list will likely soon
be extended to also support the upcoming "reftable" format.
There have been discussions on the Git mailing list in the past around
how exactly this extension should look like. One alternative [1] that
was discussed was whether it would make sense to model the extension in
such a way that backends are arbitrarily stackable. This would allow for
a combined value of e.g. "loose,packed-refs" or "loose,reftable", which
indicates that new refs would be written via "loose" files backend and
compressed into "packed-refs" or "reftable" backends, respectively.
It is arguable though whether this flexibility and the complexity that
it brings with it is really required for now. It is not foreseeable that
there will be a proliferation of backends in the near-term future, and
the current set of existing formats and formats which are on the horizon
can easily be configured with the much simpler proposal where we have a
single value, only.
Furthermore, if we ever see that we indeed want to gain the ability to
arbitrarily stack the ref formats, then we can adapt the current
extension rather easily. Given that Git clients will refuse any unknown
value for the "extensions.refStorage" extension they would also know to
ignore a stacked "loose,packed-refs" in the future.
So let's stick with the easy proposal for the time being and wire up the
extension.
[1]: <pull.1408.git.1667846164.gitgitgadget@gmail.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
Documentation/config/extensions.txt | 11 ++++++++
Documentation/ref-storage-format.txt | 1 +
.../technical/repository-version.txt | 5 ++++
builtin/clone.c | 2 +-
setup.c | 23 +++++++++++++---
setup.h | 3 ++-
t/t0001-init.sh | 26 +++++++++++++++++++
t/test-lib.sh | 2 +-
8 files changed, 67 insertions(+), 6 deletions(-)
create mode 100644 Documentation/ref-storage-format.txt
diff --git a/Documentation/config/extensions.txt b/Documentation/config/extensions.txt
index bccaec7a96..66db0e15da 100644
--- a/Documentation/config/extensions.txt
+++ b/Documentation/config/extensions.txt
@@ -7,6 +7,17 @@ Note that this setting should only be set by linkgit:git-init[1] or
linkgit:git-clone[1]. Trying to change it after initialization will not
work and will produce hard-to-diagnose issues.
+extensions.refStorage::
+ Specify the ref storage format to use. The acceptable values are:
++
+include::../ref-storage-format.txt[]
++
+It is an error to specify this key unless `core.repositoryFormatVersion` is 1.
++
+Note that this setting should only be set by linkgit:git-init[1] or
+linkgit:git-clone[1]. Trying to change it after initialization will not
+work and will produce hard-to-diagnose issues.
+
extensions.worktreeConfig::
If enabled, then worktrees will load config settings from the
`$GIT_DIR/config.worktree` file in addition to the
diff --git a/Documentation/ref-storage-format.txt b/Documentation/ref-storage-format.txt
new file mode 100644
index 0000000000..1a65cac468
--- /dev/null
+++ b/Documentation/ref-storage-format.txt
@@ -0,0 +1 @@
+* `files` for loose files with packed-refs. This is the default.
diff --git a/Documentation/technical/repository-version.txt b/Documentation/technical/repository-version.txt
index 045a76756f..27be3741e6 100644
--- a/Documentation/technical/repository-version.txt
+++ b/Documentation/technical/repository-version.txt
@@ -100,3 +100,8 @@ If set, by default "git config" reads from both "config" and
multiple working directory mode, "config" file is shared while
"config.worktree" is per-working directory (i.e., it's in
GIT_COMMON_DIR/worktrees/<id>/config.worktree)
+
+==== `refStorage`
+
+Specifies the file format for the ref database. The only valid value
+is `files` (loose references with a packed-refs file).
diff --git a/builtin/clone.c b/builtin/clone.c
index 6840064b59..20c161e94a 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -1289,7 +1289,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
* ours to the same thing.
*/
hash_algo = hash_algo_by_ptr(transport_get_hash_algo(transport));
- initialize_repository_version(hash_algo, 1);
+ initialize_repository_version(hash_algo, the_repository->ref_storage_format, 1);
repo_set_hash_algo(the_repository, hash_algo);
create_reference_database(the_repository->ref_storage_format, NULL, 1);
diff --git a/setup.c b/setup.c
index 5dffea6e2f..7eb4ae8ea0 100644
--- a/setup.c
+++ b/setup.c
@@ -590,6 +590,17 @@ static enum extension_result handle_extension(const char *var,
"extensions.objectformat", value);
data->hash_algo = format;
return EXTENSION_OK;
+ } else if (!strcmp(ext, "refstorage")) {
+ int format;
+
+ if (!value)
+ return config_error_nonbool(var);
+ format = ref_storage_format_by_name(value);
+ if (format == REF_STORAGE_FORMAT_UNKNOWN)
+ return error(_("invalid value for '%s': '%s'"),
+ "extensions.refstorage", value);
+ data->ref_storage_format = format;
+ return EXTENSION_OK;
}
return EXTENSION_UNKNOWN;
}
@@ -1869,12 +1880,14 @@ static int needs_work_tree_config(const char *git_dir, const char *work_tree)
return 1;
}
-void initialize_repository_version(int hash_algo, int reinit)
+void initialize_repository_version(int hash_algo, int ref_storage_format,
+ int reinit)
{
char repo_version_string[10];
int repo_version = GIT_REPO_VERSION;
- if (hash_algo != GIT_HASH_SHA1)
+ if (hash_algo != GIT_HASH_SHA1 ||
+ ref_storage_format != REF_STORAGE_FORMAT_FILES)
repo_version = GIT_REPO_VERSION_READ;
/* This forces creation of new config file */
@@ -1887,6 +1900,10 @@ void initialize_repository_version(int hash_algo, int reinit)
hash_algos[hash_algo].name);
else if (reinit)
git_config_set_gently("extensions.objectformat", NULL);
+
+ if (ref_storage_format != REF_STORAGE_FORMAT_FILES)
+ git_config_set("extensions.refstorage",
+ ref_storage_format_to_name(ref_storage_format));
}
static int is_reinit(void)
@@ -2028,7 +2045,7 @@ static int create_default_files(const char *template_path,
adjust_shared_perm(get_git_dir());
}
- initialize_repository_version(fmt->hash_algo, 0);
+ initialize_repository_version(fmt->hash_algo, fmt->ref_storage_format, 0);
/* Check filemode trustability */
path = git_path_buf(&buf, "config");
diff --git a/setup.h b/setup.h
index 4927abf2cf..89033ae1d9 100644
--- a/setup.h
+++ b/setup.h
@@ -180,7 +180,8 @@ int init_db(const char *git_dir, const char *real_git_dir,
int ref_storage_format,
const char *initial_branch, int init_shared_repository,
unsigned int flags);
-void initialize_repository_version(int hash_algo, int reinit);
+void initialize_repository_version(int hash_algo, int ref_storage_format,
+ int reinit);
void create_reference_database(int ref_storage_format,
const char *initial_branch, int quiet);
diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index 2b78e3be47..38b3e4c39e 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -532,6 +532,32 @@ test_expect_success 'init rejects attempts to initialize with different hash' '
test_must_fail git -C sha256 init --object-format=sha1
'
+test_expect_success DEFAULT_REPO_FORMAT 'extensions.refStorage is not allowed with repo version 0' '
+ test_when_finished "rm -rf refstorage" &&
+ git init refstorage &&
+ git -C refstorage config extensions.refStorage files &&
+ test_must_fail git -C refstorage rev-parse 2>err &&
+ grep "repo version is 0, but v1-only extension found" err
+'
+
+test_expect_success DEFAULT_REPO_FORMAT 'extensions.refStorage with files backend' '
+ test_when_finished "rm -rf refstorage" &&
+ git init refstorage &&
+ git -C refstorage config core.repositoryformatversion 1 &&
+ git -C refstorage config extensions.refStorage files &&
+ test_commit -C refstorage A &&
+ git -C refstorage rev-parse --verify HEAD
+'
+
+test_expect_success DEFAULT_REPO_FORMAT 'extensions.refStorage with unknown backend' '
+ test_when_finished "rm -rf refstorage" &&
+ git init refstorage &&
+ git -C refstorage config core.repositoryformatversion 1 &&
+ git -C refstorage config extensions.refStorage garbage &&
+ test_must_fail git -C refstorage rev-parse 2>err &&
+ grep "invalid value for ${SQ}extensions.refstorage${SQ}: ${SQ}garbage${SQ}" err
+'
+
test_expect_success MINGW 'core.hidedotfiles = false' '
git config --global core.hidedotfiles false &&
rm -rf newdir &&
diff --git a/t/test-lib.sh b/t/test-lib.sh
index dc03f06b8e..4685cc3d48 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -1937,7 +1937,7 @@ test_lazy_prereq SHA1 '
'
test_lazy_prereq DEFAULT_REPO_FORMAT '
- test_have_prereq SHA1
+ test_have_prereq SHA1,REFFILES
'
# Ensure that no test accidentally triggers a Git command
--
2.43.GIT
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related
* [PATCH 07/12] setup: introduce GIT_DEFAULT_REF_FORMAT envvar
From: Patrick Steinhardt @ 2023-12-20 10:55 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1703067989.git.ps@pks.im>
[-- Attachment #1: Type: text/plain, Size: 3130 bytes --]
Introduce a new GIT_DEFAULT_REF_FORMAT environment variable that lets
users control the default ref format used by both git-init(1) and
git-clone(1). This is modeled after GIT_DEFAULT_OBJECT_FORMAT, which
does the same thing for the repository's object format.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
Documentation/git.txt | 5 +++++
setup.c | 7 +++++++
t/t0001-init.sh | 18 ++++++++++++++++++
3 files changed, 30 insertions(+)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 4698d7a42b..0ab19eef3b 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -556,6 +556,11 @@ double-quotes and respecting backslash escapes. E.g., the value
is always used. The default is "sha1".
See `--object-format` in linkgit:git-init[1].
+`GIT_DEFAULT_REF_FORMAT`::
+ If this variable is set, the default reference backend format for new
+ repositories will be set to this value. The default is "files".
+ See `--ref-format` in linkgit:git-init[1].
+
Git Commits
~~~~~~~~~~~
`GIT_AUTHOR_NAME`::
diff --git a/setup.c b/setup.c
index 7eb4ae8ea0..8913e30974 100644
--- a/setup.c
+++ b/setup.c
@@ -2160,12 +2160,19 @@ static void validate_hash_algorithm(struct repository_format *repo_fmt, int hash
static void validate_ref_storage_format(struct repository_format *repo_fmt, int format)
{
+ const char *name = getenv("GIT_DEFAULT_REF_FORMAT");
+
if (repo_fmt->version >= 0 &&
format != REF_STORAGE_FORMAT_UNKNOWN &&
format != repo_fmt->ref_storage_format) {
die(_("attempt to reinitialize repository with different reference storage format"));
} else if (format != REF_STORAGE_FORMAT_UNKNOWN) {
repo_fmt->ref_storage_format = format;
+ } else if (name) {
+ format = ref_storage_format_by_name(name);
+ if (format == REF_STORAGE_FORMAT_UNKNOWN)
+ die(_("unknown ref storage format '%s'"), name);
+ repo_fmt->ref_storage_format = format;
}
}
diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index 38b3e4c39e..30ce752cc1 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -558,6 +558,24 @@ test_expect_success DEFAULT_REPO_FORMAT 'extensions.refStorage with unknown back
grep "invalid value for ${SQ}extensions.refstorage${SQ}: ${SQ}garbage${SQ}" err
'
+test_expect_success DEFAULT_REPO_FORMAT 'init with GIT_DEFAULT_REF_FORMAT=files' '
+ test_when_finished "rm -rf refformat" &&
+ GIT_DEFAULT_REF_FORMAT=files git init refformat &&
+ echo 0 >expect &&
+ git -C refformat config core.repositoryformatversion >actual &&
+ test_cmp expect actual &&
+ test_must_fail git -C refformat config extensions.refstorage
+'
+
+test_expect_success 'init with GIT_DEFAULT_REF_FORMAT=garbage' '
+ test_when_finished "rm -rf refformat" &&
+ cat >expect <<-EOF &&
+ fatal: unknown ref storage format ${SQ}garbage${SQ}
+ EOF
+ test_must_fail env GIT_DEFAULT_REF_FORMAT=garbage git init refformat 2>err &&
+ test_cmp expect err
+'
+
test_expect_success MINGW 'core.hidedotfiles = false' '
git config --global core.hidedotfiles false &&
rm -rf newdir &&
--
2.43.GIT
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related
* [PATCH 08/12] t: introduce GIT_TEST_DEFAULT_REF_FORMAT envvar
From: Patrick Steinhardt @ 2023-12-20 10:55 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1703067989.git.ps@pks.im>
[-- Attachment #1: Type: text/plain, Size: 2531 bytes --]
Introduce a new GIT_TEST_DEFAULT_REF_FORMAT environment variable that
lets developers run the test suite with a different default ref format
without impacting the ref format used by non-test Git invocations. This
is modeled after GIT_TEST_DEFAULT_OBJECT_FORMAT, which does the same
thing for the repository's object format.
Adapt the setup of the `REFFILES` test prerequisite to be conditionally
set based on the default ref format.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
t/README | 3 +++
t/test-lib-functions.sh | 5 +++++
t/test-lib.sh | 11 ++++++++++-
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/t/README b/t/README
index 36463d0742..621d3b8c09 100644
--- a/t/README
+++ b/t/README
@@ -479,6 +479,9 @@ GIT_TEST_DEFAULT_HASH=<hash-algo> specifies which hash algorithm to
use in the test scripts. Recognized values for <hash-algo> are "sha1"
and "sha256".
+GIT_TEST_DEFAULT_REF_FORMAT=<format> specifies which ref storage format
+to use in the test scripts. Recognized values for <format> are "files".
+
GIT_TEST_NO_WRITE_REV_INDEX=<boolean>, when true disables the
'pack.writeReverseIndex' setting.
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 03292602fb..61871b2a3b 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -1659,6 +1659,11 @@ test_detect_hash () {
test_hash_algo="${GIT_TEST_DEFAULT_HASH:-sha1}"
}
+# Detect the hash algorithm in use.
+test_detect_ref_format () {
+ echo "${GIT_TEST_DEFAULT_REF_FORMAT:-files}"
+}
+
# Load common hash metadata and common placeholder object IDs for use with
# test_oid.
test_oid_init () {
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 4685cc3d48..fc93aa57e6 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -542,6 +542,8 @@ export EDITOR
GIT_DEFAULT_HASH="${GIT_TEST_DEFAULT_HASH:-sha1}"
export GIT_DEFAULT_HASH
+GIT_DEFAULT_REF_FORMAT="${GIT_TEST_DEFAULT_REF_FORMAT:-files}"
+export GIT_DEFAULT_REF_FORMAT
GIT_TEST_MERGE_ALGORITHM="${GIT_TEST_MERGE_ALGORITHM:-ort}"
export GIT_TEST_MERGE_ALGORITHM
@@ -1745,7 +1747,14 @@ parisc* | hppa*)
;;
esac
-test_set_prereq REFFILES
+case "$GIT_DEFAULT_REF_FORMAT" in
+files)
+ test_set_prereq REFFILES;;
+*)
+ echo 2>&1 "error: unknown ref format $GIT_DEFAULT_REF_FORMAT"
+ exit 1
+ ;;
+esac
( COLUMNS=1 && test $COLUMNS = 1 ) && test_set_prereq COLUMNS_CAN_BE_1
test -z "$NO_CURL" && test_set_prereq LIBCURL
--
2.43.GIT
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related
* [PATCH 09/12] builtin/rev-parse: introduce `--show-ref-format` flag
From: Patrick Steinhardt @ 2023-12-20 10:55 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1703067989.git.ps@pks.im>
[-- Attachment #1: Type: text/plain, Size: 2428 bytes --]
Introduce a new `--show-ref-format` to git-rev-parse(1) that causes it
to print the ref format used by a repository.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
Documentation/git-rev-parse.txt | 3 +++
builtin/rev-parse.c | 4 ++++
t/t1500-rev-parse.sh | 17 +++++++++++++++++
3 files changed, 24 insertions(+)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 912fab9f5e..546faf9017 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -307,6 +307,9 @@ The following options are unaffected by `--path-format`:
input, multiple algorithms may be printed, space-separated.
If not specified, the default is "storage".
+--show-ref-format::
+ Show the reference storage format used for the repository.
+
Other Options
~~~~~~~~~~~~~
diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index fde8861ca4..99725a6ff1 100644
--- a/builtin/rev-parse.c
+++ b/builtin/rev-parse.c
@@ -1059,6 +1059,10 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
puts(the_hash_algo->name);
continue;
}
+ if (!strcmp(arg, "--show-ref-format")) {
+ puts(ref_storage_format_to_name(the_repository->ref_storage_format));
+ continue;
+ }
if (!strcmp(arg, "--end-of-options")) {
seen_end_of_options = 1;
if (filter & (DO_FLAGS | DO_REVS))
diff --git a/t/t1500-rev-parse.sh b/t/t1500-rev-parse.sh
index 3f9e7f62e4..a669e592f1 100755
--- a/t/t1500-rev-parse.sh
+++ b/t/t1500-rev-parse.sh
@@ -208,6 +208,23 @@ test_expect_success 'rev-parse --show-object-format in repo' '
grep "unknown mode for --show-object-format: squeamish-ossifrage" err
'
+test_expect_success 'rev-parse --show-ref-format' '
+ test_detect_ref_format >expect &&
+ git rev-parse --show-ref-format >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'rev-parse --show-ref-format with invalid storage' '
+ test_when_finished "rm -rf repo" &&
+ git init repo &&
+ (
+ cd repo &&
+ git config extensions.refstorage broken &&
+ test_must_fail git rev-parse --show-ref-format 2>err &&
+ grep "error: invalid value for ${SQ}extensions.refstorage${SQ}: ${SQ}broken${SQ}" err
+ )
+'
+
test_expect_success '--show-toplevel from subdir of working tree' '
pwd >expect &&
git -C sub/dir rev-parse --show-toplevel >actual &&
--
2.43.GIT
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related
* [PATCH 10/12] builtin/init: introduce `--ref-format=` value flag
From: Patrick Steinhardt @ 2023-12-20 10:55 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1703067989.git.ps@pks.im>
[-- Attachment #1: Type: text/plain, Size: 4852 bytes --]
Introduce a new `--ref-format` value flag for git-init(1) that allows
the user to specify the ref format that is to be used for a newly
initialized repository.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
Documentation/git-init.txt | 7 +++++++
builtin/init-db.c | 13 ++++++++++++-
t/t0001-init.sh | 26 ++++++++++++++++++++++++++
3 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index 6f0d2973bf..e8dc645bb5 100644
--- a/Documentation/git-init.txt
+++ b/Documentation/git-init.txt
@@ -11,6 +11,7 @@ SYNOPSIS
[verse]
'git init' [-q | --quiet] [--bare] [--template=<template-directory>]
[--separate-git-dir <git-dir>] [--object-format=<format>]
+ [--ref-format=<format>]
[-b <branch-name> | --initial-branch=<branch-name>]
[--shared[=<permissions>]] [<directory>]
@@ -57,6 +58,12 @@ values are 'sha1' and (if enabled) 'sha256'. 'sha1' is the default.
+
include::object-format-disclaimer.txt[]
+--ref-format=<format>::
+
+Specify the given ref storage format for the repository. The valid values are:
++
+include::ref-storage-format.txt[]
+
--template=<template-directory>::
Specify the directory from which templates will be used. (See the "TEMPLATE
diff --git a/builtin/init-db.c b/builtin/init-db.c
index b6e80feab6..770b2822fe 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -58,6 +58,7 @@ static int shared_callback(const struct option *opt, const char *arg, int unset)
static const char *const init_db_usage[] = {
N_("git init [-q | --quiet] [--bare] [--template=<template-directory>]\n"
" [--separate-git-dir <git-dir>] [--object-format=<format>]\n"
+ " [--ref-format=<format>]\n"
" [-b <branch-name> | --initial-branch=<branch-name>]\n"
" [--shared[=<permissions>]] [<directory>]"),
NULL
@@ -77,8 +78,10 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
const char *template_dir = NULL;
unsigned int flags = 0;
const char *object_format = NULL;
+ const char *ref_format = NULL;
const char *initial_branch = NULL;
int hash_algo = GIT_HASH_UNKNOWN;
+ int ref_storage_format = REF_STORAGE_FORMAT_UNKNOWN;
int init_shared_repository = -1;
const struct option init_db_options[] = {
OPT_STRING(0, "template", &template_dir, N_("template-directory"),
@@ -96,6 +99,8 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
N_("override the name of the initial branch")),
OPT_STRING(0, "object-format", &object_format, N_("hash"),
N_("specify the hash algorithm to use")),
+ OPT_STRING(0, "ref-format", &ref_format, N_("format"),
+ N_("specify the reference format to use")),
OPT_END()
};
@@ -159,6 +164,12 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
die(_("unknown hash algorithm '%s'"), object_format);
}
+ if (ref_format) {
+ ref_storage_format = ref_storage_format_by_name(ref_format);
+ if (ref_storage_format == REF_STORAGE_FORMAT_UNKNOWN)
+ die(_("unknown ref storage format '%s'"), ref_format);
+ }
+
if (init_shared_repository != -1)
set_shared_repository(init_shared_repository);
@@ -237,6 +248,6 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
flags |= INIT_DB_EXIST_OK;
return init_db(git_dir, real_git_dir, template_dir, hash_algo,
- REF_STORAGE_FORMAT_UNKNOWN, initial_branch,
+ ref_storage_format, initial_branch,
init_shared_repository, flags);
}
diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index 30ce752cc1..b131d665db 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -576,6 +576,32 @@ test_expect_success 'init with GIT_DEFAULT_REF_FORMAT=garbage' '
test_cmp expect err
'
+test_expect_success 'init with --ref-format=files' '
+ test_when_finished "rm -rf refformat" &&
+ git init --ref-format=files refformat &&
+ echo files >expect &&
+ git -C refformat rev-parse --show-ref-format >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 're-init with same format' '
+ test_when_finished "rm -rf refformat" &&
+ git init --ref-format=files refformat &&
+ git init --ref-format=files refformat &&
+ echo files >expect &&
+ git -C refformat rev-parse --show-ref-format >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'init with --ref-format=garbage' '
+ test_when_finished "rm -rf refformat" &&
+ cat >expect <<-EOF &&
+ fatal: unknown ref storage format ${SQ}garbage${SQ}
+ EOF
+ test_must_fail git init --ref-format=garbage refformat 2>err &&
+ test_cmp expect err
+'
+
test_expect_success MINGW 'core.hidedotfiles = false' '
git config --global core.hidedotfiles false &&
rm -rf newdir &&
--
2.43.GIT
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related
* [PATCH 11/12] builtin/clone: introduce `--ref-format=` value flag
From: Patrick Steinhardt @ 2023-12-20 10:55 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1703067989.git.ps@pks.im>
[-- Attachment #1: Type: text/plain, Size: 3995 bytes --]
Introduce a new `--ref-format` value flag for git-clone(1) that allows
the user to specify the ref format that is to be used for a newly
initialized repository.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
Documentation/git-clone.txt | 6 ++++++
builtin/clone.c | 12 +++++++++++-
t/t5601-clone.sh | 17 +++++++++++++++++
3 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index c37c4a37f7..6e43eb9c20 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -311,6 +311,12 @@ or `--mirror` is given)
The result is Git repository can be separated from working
tree.
+--ref-format=<ref-format::
+
+Specify the given ref storage format for the repository. The valid values are:
++
+include::ref-storage-format.txt[]
+
-j <n>::
--jobs <n>::
The number of submodules fetched at the same time.
diff --git a/builtin/clone.c b/builtin/clone.c
index 20c161e94a..b635bbcb43 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -72,6 +72,7 @@ static char *remote_name = NULL;
static char *option_branch = NULL;
static struct string_list option_not = STRING_LIST_INIT_NODUP;
static const char *real_git_dir;
+static const char *ref_format;
static char *option_upload_pack = "git-upload-pack";
static int option_verbosity;
static int option_progress = -1;
@@ -157,6 +158,8 @@ static struct option builtin_clone_options[] = {
N_("any cloned submodules will be shallow")),
OPT_STRING(0, "separate-git-dir", &real_git_dir, N_("gitdir"),
N_("separate git dir from working tree")),
+ OPT_STRING(0, "ref-format", &ref_format, N_("format"),
+ N_("specify the reference format to use")),
OPT_STRING_LIST('c', "config", &option_config, N_("key=value"),
N_("set config inside the new repository")),
OPT_STRING_LIST(0, "server-option", &server_options,
@@ -930,6 +933,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
int submodule_progress;
int filter_submodules = 0;
int hash_algo;
+ int ref_storage_format = REF_STORAGE_FORMAT_UNKNOWN;
const int do_not_override_repo_unix_permissions = -1;
struct transport_ls_refs_options transport_ls_refs_options =
@@ -955,6 +959,12 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
if (option_single_branch == -1)
option_single_branch = deepen ? 1 : 0;
+ if (ref_format) {
+ ref_storage_format = ref_storage_format_by_name(ref_format);
+ if (ref_storage_format == REF_STORAGE_FORMAT_UNKNOWN)
+ die(_("unknown ref storage format '%s'"), ref_format);
+ }
+
if (option_mirror)
option_bare = 1;
@@ -1106,7 +1116,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
* their on-disk data structures.
*/
init_db(git_dir, real_git_dir, option_template, GIT_HASH_UNKNOWN,
- REF_STORAGE_FORMAT_UNKNOWN, NULL,
+ ref_storage_format, NULL,
do_not_override_repo_unix_permissions, INIT_DB_QUIET | INIT_DB_SKIP_REFDB);
if (real_git_dir) {
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 47eae641f0..fb1b9c686d 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -157,6 +157,23 @@ test_expect_success 'clone --mirror does not repeat tags' '
'
+test_expect_success 'clone with files ref format' '
+ test_when_finished "rm -rf ref-storage" &&
+ git clone --ref-format=files --mirror src ref-storage &&
+ echo files >expect &&
+ git -C ref-storage rev-parse --show-ref-format >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'clone with garbage ref format' '
+ cat >expect <<-EOF &&
+ fatal: unknown ref storage format ${SQ}garbage${SQ}
+ EOF
+ test_must_fail git clone --ref-format=garbage --mirror src ref-storage 2>err &&
+ test_cmp expect err &&
+ test_path_is_missing ref-storage
+'
+
test_expect_success 'clone to destination with trailing /' '
git clone src target-1/ &&
--
2.43.GIT
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related
* [PATCH 12/12] t9500: write "extensions.refstorage" into config
From: Patrick Steinhardt @ 2023-12-20 10:55 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1703067989.git.ps@pks.im>
[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]
In t9500 we're writing a custom configuration that sets up gitweb. This
requires us manually ensure that the repository format is configured as
required, including both the repository format version and extensions.
With the introduction of the "extensions.refStorage" extension we need
to update the test to also write this new one.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
t/t9500-gitweb-standalone-no-errors.sh | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-standalone-no-errors.sh
index 0333065d4d..7679780fb8 100755
--- a/t/t9500-gitweb-standalone-no-errors.sh
+++ b/t/t9500-gitweb-standalone-no-errors.sh
@@ -627,6 +627,7 @@ test_expect_success \
test_expect_success 'setup' '
version=$(git config core.repositoryformatversion) &&
algo=$(test_might_fail git config extensions.objectformat) &&
+ refstorage=$(test_might_fail git config extensions.refstorage) &&
cat >.git/config <<-\EOF &&
# testing noval and alternate separator
[gitweb]
@@ -637,6 +638,10 @@ test_expect_success 'setup' '
if test -n "$algo"
then
git config extensions.objectformat "$algo"
+ fi &&
+ if test -n "$refstorage"
+ then
+ git config extensions.refstorage "$refstorage"
fi
'
--
2.43.GIT
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related
* Re: [PATCH 4/8] SubmittingPatches: update extra tags list
From: Phillip Wood @ 2023-12-20 15:18 UTC (permalink / raw)
To: Josh Soref via GitGitGadget, git; +Cc: Elijah Newren, Josh Soref
In-Reply-To: <e5c7f29af439c48f59b2f35af93a7972e66a5b6b.1702975320.git.gitgitgadget@gmail.com>
Hi Josh
On 19/12/2023 08:41, Josh Soref via GitGitGadget wrote:
> From: Josh Soref <jsoref@gmail.com>
>
> Add items with at least 100 uses:
> - Co-authored-by
> - Helped-by
> - Mentored-by
> - Suggested-by
Thanks for adding these, they are widely used and should be documented.
The patch also adds a mention for "Noticed-by:" - I'm less convinced by
the need for that as I explain below.
> Updating the create suggestion to something less commonly used.
I'm not quite sure I understand what you mean by this sentence.
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index 32e90238777..694a7bafb68 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -348,6 +348,8 @@ If you like, you can put extra tags at the end:
>
> . `Reported-by:` is used to credit someone who found the bug that
> the patch attempts to fix.
> +. `Noticed-by:` liked `Reported-by:` indicates someone who noticed
> + the item being fixed.
I wonder if we really need a separate "Noticed-by" footer in addition to
"Reported-by". Personally I use the latter to acknowledge the person who
reported the issue being fix regards of weather I'm fixing a bug or some
other issue.
> . `Acked-by:` says that the person who is more familiar with the area
> the patch attempts to modify liked the patch.
> . `Reviewed-by:`, unlike the other tags, can only be offered by the
> @@ -355,9 +357,17 @@ If you like, you can put extra tags at the end:
> patch after a detailed analysis.
> . `Tested-by:` is used to indicate that the person applied the patch
> and found it to have the desired effect.
> +. `Co-authored-by:` is used to indicate that multiple people
> + contributed to the work of a patch.
Junio's comments in [1] may be helpful here
If co-authors closely worked together (possibly but not necessarily
outside the public view), exchanging drafts and agreeing on the
final version before sending it to the list, by one approving the
other's final draft, Co-authored-by may be appropriate.
I would prefer to see more use of Helped-by when suggestions for
improvements were made, possibly but not necessarily in a concrete
"squashable patch" form, the original author accepted before
sending the new version out, and the party who made suggestions saw
the updated version at the same time as the general public.
So I think we should be clear that "Co-authored-by:" means that multiple
authors worked closely together on the patch, rather than just
contributed to it.
[1] https://lore.kernel.org/git/xmqqmth8wwcf.fsf@gitster.g/
> +. `Helped-by:` is used to credit someone with helping develop a
> + patch.
> +. `Mentored-by:` is used to credit someone with helping develop a
> + patch.
I think we use "Montored-by:" specifically to credit the mentor on
patches written by GSoC or Outreachy interns and "Helped-by:" for the
general case of someone helping the patch author.
> +. `Suggested-by:` is used to credit someone with suggesting the idea
> + for a patch.
>
> You can also create your own tag or use one that's in common usage
> -such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:".
> +such as "Thanks-to:", "Based-on-patch-by:", or "Improved-by:".
What's the difference between "Improved-by:" and "Helped-by:"? In
general I'd prefer for us not to encourage new trailers where we already
have a suitable one in use.
Thanks for working on this, it will be good to have better descriptions
of our common trailers.
Best Wishes
Phillip
^ permalink raw reply
* Re: [PATCH 7/8] SubmittingPatches: clarify GitHub artifact format
From: Elijah Newren @ 2023-12-20 15:21 UTC (permalink / raw)
To: Josh Soref via GitGitGadget; +Cc: git, Josh Soref
In-Reply-To: <cdab65a425944e9d10f6aa6be378162cd5450c81.1702975320.git.gitgitgadget@gmail.com>
On Tue, Dec 19, 2023 at 12:42 AM Josh Soref via GitGitGadget
<gitgitgadget@gmail.com> wrote:
>
> From: Josh Soref <jsoref@gmail.com>
>
> GitHub wraps artifacts generated by workflows in a .zip file.
>
> Internally workflows can package anything they like in them.
s/Internally/Internal/?
>
> A recently generated failure artifact had the form:
>
> windows-artifacts.zip
> Length Date Time Name
> --------- ---------- ----- ----
> 76001695 12-19-2023 01:35 artifacts.tar.gz
> 11005650 12-19-2023 01:35 tracked.tar.gz
> --------- -------
> 87007345 2 files
>
> Signed-off-by: Josh Soref <jsoref@gmail.com>
> ---
> Documentation/SubmittingPatches | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index 8e19c7f82e4..b4fa52ae348 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -606,7 +606,8 @@ branches here: `https://github.com/<Your GitHub handle>/git/actions/workflows/ma
> If a branch did not pass all test cases then it is marked with a red
> +x+. In that case you can click on the failing job and navigate to
> "ci/run-build-and-tests.sh" and/or "ci/print-test-failures.sh". You
> -can also download "Artifacts" which are tarred (or zipped) archives
> +can also download "Artifacts" which are zip archives containing
> +tarred (or zipped) archives
> with test data relevant for debugging.
>
> Then fix the problem and push your fix to your GitHub fork. This will
> --
> gitgitgadget
>
^ permalink raw reply
* Re: [PATCH v6] subtree: fix split processing with multiple subtrees present
From: Christian Couder @ 2023-12-20 15:25 UTC (permalink / raw)
To: Zach FettersMoore; +Cc: Zach FettersMoore via GitGitGadget, git
In-Reply-To: <CAP8UFD19phFz54d8fDM=MBRMSD9Rz4R0_463KgptN8eeFs7MnQ@mail.gmail.com>
On Tue, Dec 12, 2023 at 5:06 PM Christian Couder
<christian.couder@gmail.com> wrote:
>
> On Mon, Dec 11, 2023 at 4:39 PM Zach FettersMoore
> <zach.fetters@apollographql.com> wrote:
> >
> > >>
> > >> From: Zach FettersMoore <zach.fetters@apollographql.com>
>
> > >> To see this in practice you can use the open source GitHub repo
> > >> 'apollo-ios-dev' and do the following in order:
> > >>
> > >> -Make a changes to a file in 'apollo-ios' and 'apollo-ios-codegen'
> > >> directories
> > >> -Create a commit containing these changes
> > >> -Do a split on apollo-ios-codegen
> > >> - Do a fetch on the subtree repo
> > >> - git fetch git@github.com:apollographql/apollo-ios-codegen.git
> > >> - git subtree split --prefix=apollo-ios-codegen --squash --rejoin
> >
> > > Now I get the following without your patch at this step:
> > >
> > > $ git subtree split --prefix=apollo-ios-codegen --squash --rejoin
> > > [...]/libexec/git-core/git-subtree: 318: Maximum function recursion
> > > depth (1000) reached
> > >
> > > Line 318 in git-subtree.sh contains the following:
> > >
> > > missed=$(cache_miss "$@") || exit $?
> > >
> > > With your patch it seems to work:
> > >
> > > $ git subtree split --prefix=apollo-ios-codegen --squash --rejoin
> > > Merge made by the 'ort' strategy.
> > > e274aed3ba6d0659fb4cc014587cf31c1e8df7f4
> >
> > Looking into this some it looks like it could be a bash config
> > difference? My machine always runs it all the way through vs
> > failing for recursion depth. Although that would also be an issue
> > which is solved by this fix.
>
> I use Ubuntu where /bin/sh is dash so my current guess is that dash
> might have a smaller recursion limit than bash.
>
> I just found https://stackoverflow.com/questions/69493528/git-subtree-maximum-function-recursion-depth
> which seems to agree.
>
> I will try to test using bash soon.
Sorry, to not have tried earlier before with bash.
Now I have tried it and yeah it works fine with you patch, while
without it the last step of the reproduction recipe takes a lot of
time and results in a core dump:
/home/christian/libexec/git-core/git-subtree: line 924: 857920 Done
eval "$grl"
857921 Segmentation fault (core dumped) | while read rev parents; do
process_split_commit "$rev" "$parents";
done
So overall I think your patch is great! Thanks!
^ permalink raw reply
* Re: [PATCH 4/8] SubmittingPatches: update extra tags list
From: Elijah Newren @ 2023-12-20 15:30 UTC (permalink / raw)
To: phillip.wood; +Cc: Josh Soref via GitGitGadget, git, Josh Soref
In-Reply-To: <35fc350d-018a-49cf-a28e-e5ce21fe7dec@gmail.com>
To add to what Phillip said...
On Wed, Dec 20, 2023 at 7:18 AM Phillip Wood <phillip.wood123@gmail.com> wrote:
>
> Hi Josh
>
> On 19/12/2023 08:41, Josh Soref via GitGitGadget wrote:
> > From: Josh Soref <jsoref@gmail.com>
> >
> > Add items with at least 100 uses:
> > - Co-authored-by
> > - Helped-by
> > - Mentored-by
> > - Suggested-by
>
> Thanks for adding these, they are widely used and should be documented.
> The patch also adds a mention for "Noticed-by:" - I'm less convinced by
> the need for that as I explain below.
>
> > Updating the create suggestion to something less commonly used.
>
> I'm not quite sure I understand what you mean by this sentence.
Same.
> > diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> > index 32e90238777..694a7bafb68 100644
> > --- a/Documentation/SubmittingPatches
> > +++ b/Documentation/SubmittingPatches
> > @@ -348,6 +348,8 @@ If you like, you can put extra tags at the end:
> >
> > . `Reported-by:` is used to credit someone who found the bug that
> > the patch attempts to fix.
> > +. `Noticed-by:` liked `Reported-by:` indicates someone who noticed
> > + the item being fixed.
>
> I wonder if we really need a separate "Noticed-by" footer in addition to
> "Reported-by". Personally I use the latter to acknowledge the person who
> reported the issue being fix regards of weather I'm fixing a bug or some
> other issue.
I'm not sure I'd mention both either; feels like we're making it hard
for users to choose. Also, I think there's a minor distinction
between them, but it's hard to convey simply: To me, Reported-by
suggests someone sent a mail to the list specifically about the bug or
issue in question. Also, to me, Noticed-by suggests that during a
back-and-forth discussion of some sort on another topic, a fellow Git
contributor noticed an issue and mentioned it as an aside. But,
that's how _I_ would have used them, I didn't do any digging to find
out if that's really how they are used.
Either way, if we're going to define them as synonyms, I'd rather we
just left the less common one out. If there's a distinction, and it's
not a pain to describe, then maybe it'd be worth adding both.
If we do add both, though, we at least need to fix "liked" to "like"
in your description.
> > . `Acked-by:` says that the person who is more familiar with the area
> > the patch attempts to modify liked the patch.
> > . `Reviewed-by:`, unlike the other tags, can only be offered by the
> > @@ -355,9 +357,17 @@ If you like, you can put extra tags at the end:
> > patch after a detailed analysis.
> > . `Tested-by:` is used to indicate that the person applied the patch
> > and found it to have the desired effect.
> > +. `Co-authored-by:` is used to indicate that multiple people
> > + contributed to the work of a patch.
>
> Junio's comments in [1] may be helpful here
>
> If co-authors closely worked together (possibly but not necessarily
> outside the public view), exchanging drafts and agreeing on the
> final version before sending it to the list, by one approving the
> other's final draft, Co-authored-by may be appropriate.
>
> I would prefer to see more use of Helped-by when suggestions for
> improvements were made, possibly but not necessarily in a concrete
> "squashable patch" form, the original author accepted before
> sending the new version out, and the party who made suggestions saw
> the updated version at the same time as the general public.
>
> So I think we should be clear that "Co-authored-by:" means that multiple
> authors worked closely together on the patch, rather than just
> contributed to it.
>
> [1] https://lore.kernel.org/git/xmqqmth8wwcf.fsf@gitster.g/
>
> > +. `Helped-by:` is used to credit someone with helping develop a
> > + patch.
> > +. `Mentored-by:` is used to credit someone with helping develop a
> > + patch.
>
> I think we use "Montored-by:" specifically to credit the mentor on
> patches written by GSoC or Outreachy interns and "Helped-by:" for the
> general case of someone helping the patch author.
Yes; I'd like for these to be distinguished in this way or something similar.
> > +. `Suggested-by:` is used to credit someone with suggesting the idea
> > + for a patch.
> >
> > You can also create your own tag or use one that's in common usage
> > -such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:".
> > +such as "Thanks-to:", "Based-on-patch-by:", or "Improved-by:".
>
> What's the difference between "Improved-by:" and "Helped-by:"? In
> general I'd prefer for us not to encourage new trailers where we already
> have a suitable one in use.
Agreed.
> Thanks for working on this, it will be good to have better descriptions
> of our common trailers.
Agreed here as well; thanks for the work, Josh.
^ permalink raw reply
* Re: [PATCH 6/8] SubmittingPatches: clarify GitHub visual
From: Elijah Newren @ 2023-12-20 15:40 UTC (permalink / raw)
To: René Scharfe; +Cc: Josh Soref via GitGitGadget, git, Josh Soref
In-Reply-To: <e788cf7b-56c7-48c2-ad4f-65d9c9e73ad5@web.de>
On Tue, Dec 19, 2023 at 6:44 AM René Scharfe <l.s.r@web.de> wrote:
>
> Am 19.12.23 um 09:41 schrieb Josh Soref via GitGitGadget:
> > From: Josh Soref <jsoref@gmail.com>
> >
> > Some people would expect a cross to be upright, and potentially have
> > unequal lengths...
>
> There are lots of types of crosses. And while looking them up on
> Wikipedia I learned today that an x-cross is called "saltire" in
> English. I only knew it as St. Andrew's cross before.
>
> > GitHub uses a white x overlaying a solid red circle to indicate failure.
>
> They call it "x-circle-fill"
> (https://primer.github.io/octicons/x-circle-fill-16).
>
> >
> > Signed-off-by: Josh Soref <jsoref@gmail.com>
> > ---
> > Documentation/SubmittingPatches | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> > index d7a84f59478..8e19c7f82e4 100644
> > --- a/Documentation/SubmittingPatches
> > +++ b/Documentation/SubmittingPatches
> > @@ -604,7 +604,7 @@ to your fork of Git on GitHub. You can monitor the test state of all your
> > branches here: `https://github.com/<Your GitHub handle>/git/actions/workflows/main.yml`
> >
> > If a branch did not pass all test cases then it is marked with a red
> > -cross. In that case you can click on the failing job and navigate to
> > ++x+. In that case you can click on the failing job and navigate to
>
> In the commit message you say the x is white, here it's red, so what is
> it? IIUC the circle is red and the x-cross inside is the same color as
> the background, i.e. white in light mode and black in dark mode. No
> idea how to express that in one word. Perhaps "red circle containing
> and x-cross"?
There's an "and" vs "an" typo there, I think. I'm tempted to just
oversimplify ("...marked with red."), but am slightly concerned about
red/green color-blind folks. I suspect they'd figure it out anyway by
comparing the checkmarks (within green) to the x's (within red), but
if we want to be more detailed, perhaps we drop the "cross" altogether
and just describe it literally: "...marked with a red circle
containing a white x."?
^ permalink raw reply
* Re: [PATCH] Documentation/git-merge.txt: fix reference to synopsys
From: René Scharfe @ 2023-12-20 15:43 UTC (permalink / raw)
To: Michael Lohmann, git; +Cc: Michael Lohmann
In-Reply-To: <20231220070528.8049-1-mi.al.lohmann@gmail.com>
Am 20.12.23 um 08:05 schrieb Michael Lohmann:
Thank you for this patch and sorry for the nitpicking below!
> 437591a9d738 changed the synopsys from two separate lines for `--abort`
"Synopsys" is a software company. A "synopsis" is a brief outline.
> and `--continue` to a single line (and it also simultaneously added
> `--quit`). That way the "enumeration" of the syntax for `--continue` is
> no longer valid. Since `--quit` is now also part of the same syntax
> line, a general statement cannot be made any more. Instead of trying to
> enumerate the synopsys, be explicit in the limitations of when
> respective actions are valid.
Had to think a moment before I understood that "enumeration" refers to
"The second syntax" and "The third syntax", which have been combined
into this line:
git merge (--continue | --abort | --quit)
And it does make sense that we can no longer say "second syntax" and
only refer to "git merge --abort", or "third syntax" and mean "git
merge --continue". In other words: References by number are no longer
valid after a merge of some of the synopses.
> This change also groups `--abort` and `--continue` together when
> explaining the circumstances under which they can be run in order to
> avoid duplication.
>
> Signed-off-by: Michael Lohmann <mi.al.lohmann@gmail.com>
> ---
> Documentation/git-merge.txt | 19 +++++++++----------
> 1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
> index e8ab340319..d8863cc943 100644
> --- a/Documentation/git-merge.txt
> +++ b/Documentation/git-merge.txt
> @@ -46,21 +46,20 @@ a log message from the user describing the changes. Before the operation,
> D---E---F---G---H master
> ------------
>
> -The second syntax ("`git merge --abort`") can only be run after the
> -merge has resulted in conflicts. 'git merge --abort' will abort the
> -merge process and try to reconstruct the pre-merge state. However,
> -if there were uncommitted changes when the merge started (and
> -especially if those changes were further modified after the merge
> -was started), 'git merge --abort' will in some cases be unable to
> -reconstruct the original (pre-merge) changes. Therefore:
> +It is possible that a merge failure will prevent this process from being
> +completely automatic. "`git merge --continue`" and "`git merge --abort`"
^^^^^^^^^
automatically
> +can only be run after the merge has resulted in conflicts.
The connection between these two sentences feels weak to me. Are "merge
failure" and "conflicts" the same? Perhaps something like this:
A merge stops if there's a conflict that cannot be resolved
automatically. At that point you can run `git merge --abort` or
`git merge --continue`.
> +
> +'git merge --abort' will abort the merge process and try to reconstruct
> +the pre-merge state. However, if there were uncommitted changes when the
> +merge started (and especially if those changes were further modified
> +after the merge was started), 'git merge --abort' will in some cases be
> +unable to reconstruct the original (pre-merge) changes. Therefore:
>
> *Warning*: Running 'git merge' with non-trivial uncommitted changes is
> discouraged: while possible, it may leave you in a state that is hard to
> back out of in the case of a conflict.
>
> -The third syntax ("`git merge --continue`") can only be run after the
> -merge has resulted in conflicts.
What's with the quoting? It was inconsistent before, but I wonder what
would be correct here. Switching between straight single quotes ('')
and curved double quotes ("``") seems a bit arbitrary.
And I'm not even sure if these quotes really are what I think they are
based on https://docs.asciidoctor.org/asciidoc/latest/subs/quotes/. On
https://git-scm.com/docs/git-merge single quotes get rendered as <em>,
backticks as <code> (which makes sense) and curved double quotes as
<code> surrounded by straight double quotes (which looks weird).
The only guidance I found is this paragraph from CodingGuidelines:
Literal examples (e.g. use of command-line options, command names,
branch names, URLs, pathnames (files and directories), configuration and
environment variables) must be typeset in monospace (i.e. wrapped with
backticks)
So shouldn't we wrap all commands in backticks and nothing more?
Probably worth a separate patch.
> -
> OPTIONS
> -------
> :git-merge: 1
^ permalink raw reply
* Re: [PATCH 0/8] Minor improvements to CodingGuidelines and SubmittingPatches
From: Elijah Newren @ 2023-12-20 15:43 UTC (permalink / raw)
To: Josh Soref via GitGitGadget; +Cc: git, Josh Soref
In-Reply-To: <pull.1623.git.1702975319.gitgitgadget@gmail.com>
On Tue, Dec 19, 2023 at 12:42 AM Josh Soref via GitGitGadget
<gitgitgadget@gmail.com> wrote:
>
> These are a bunch of things I've run into over my past couple of attempts to
> contribute to Git.
>
> * Incremental punctuation/grammatical improvements
> * Update extra tags suggestions based on common usage
> * drop reference to an article that was discontinued over a decade ago
> * update GitHub references
> * harmonize non-ASCII while I'm here
I commented on patches 4, 6, and 7 suggesting some changes. Patch 1
is "meh" to me, but it doesn't hurt anything. The other four all look
like good cleanups to me.
^ permalink raw reply
* Re: [PATCH] rebase: use strvec_pushf() for format-patch revisions
From: Junio C Hamano @ 2023-12-20 15:57 UTC (permalink / raw)
To: René Scharfe; +Cc: Git List
In-Reply-To: <47089803-c45b-4f33-b542-146c313f0902@web.de>
René Scharfe <l.s.r@web.de> writes:
> Am 19.12.23 um 18:12 schrieb Junio C Hamano:
>> René Scharfe <l.s.r@web.de> writes:
>>
>>> In run_am(), a strbuf is used to create a revision argument that is then
>>> added to the argument list for git format-patch using strvec_push().
>>> Use strvec_pushf() to add it directly instead, simplifying the code.
>>>
>>> Signed-off-by: René Scharfe <l.s.r@web.de>
>>> ---
>>
>> Makes sense. Between the location of the original strbuf_addf()
>> call and the new strvec_pushf() call, nobody mucks with *opts so
>> this change won't affect the correctness. We no longer use the
>> extra strbuf, and upon failing to open the rebased-patches file,
>> we no longer leak the contents of it. Good.
>
> Ha! I didn't even notice that leak on error. Perhaps the two release
> calls at the end gave me the illusion of cleanliness? Or more likely
> the opportunity to use strvec_pushf() grabbed my full attention (tunnel
> vision).
Perhaps I'll amend the end of the log message, like so, before
merging it down to 'next', then.
..., simplifying the code and plugging a small leak on the error
codepath.
Thanks.
^ permalink raw reply
* Re: [PATCH 4/8] SubmittingPatches: update extra tags list
From: Josh Soref @ 2023-12-20 16:09 UTC (permalink / raw)
To: git; +Cc: phillip.wood, Elijah Newren
In-Reply-To: <CABPp-BH_iP2KjPi-5kW8ROQWfy8XoUmbGhyT-Y1dZGtCtZXQGQ@mail.gmail.com>
On Wed, Dec 20, 2023 at 10:30 AM Elijah Newren <newren@gmail.com> wrote:
> On Wed, Dec 20, 2023 at 7:18 AM Phillip Wood <phillip.wood123@gmail.com> wrote:
> > Thanks for adding these, they are widely used and should be documented.
> > The patch also adds a mention for "Noticed-by:" - I'm less convinced by
> > the need for that as I explain below.
> >
> > > Updating the create suggestion to something less commonly used.
> >
> > I'm not quite sure I understand what you mean by this sentence.
Tentatively rewritten as:
Updating the "create your own tag" suggestion as 'Mentored-by' has been
promoted.
This commit is adding bulleted items including promoting 'Mentored-by',
which means that the suggestion of "invent your own" would really need
a new suggestion.
Personally I'm not a fan of "invent your own", but I'm trying to
follow "when in Rome" (which is a big thing in the Git process
documentation covered by the two files subject to this series). More
on this later.
> > > diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> > > index 32e90238777..694a7bafb68 100644
> > > @@ -348,6 +348,8 @@ If you like, you can put extra tags at the end:
> > >
> > > . `Reported-by:` is used to credit someone who found the bug that
> > > the patch attempts to fix.
> > > +. `Noticed-by:` liked `Reported-by:` indicates someone who noticed
> > > + the item being fixed.
> >
> > I wonder if we really need a separate "Noticed-by" footer in addition to
> > "Reported-by". Personally I use the latter to acknowledge the person who
> > reported the issue being fix regards of weather I'm fixing a bug or some
> > other issue.
>
> I'm not sure I'd mention both either; feels like we're making it hard
> for users to choose. Also, I think there's a minor distinction
> between them, but it's hard to convey simply: To me, Reported-by
> suggests someone sent a mail to the list specifically about the bug or
> issue in question. Also, to me, Noticed-by suggests that during a
> back-and-forth discussion of some sort on another topic, a fellow Git
> contributor noticed an issue and mentioned it as an aside. But,
> that's how _I_ would have used them, I didn't do any digging to find
> out if that's really how they are used.
Given that Noticed-by is more common than Co-authored-by, I have a
hard time arguing that it shouldn't be included.
You could see that I struggled with it based on my lousy first drafts [1].
Anyway, tentatively:
. `Noticed-by:` like `Reported-by:` indicates a Git contributor who
called the item (being fixed) out as an aside.
Here, I'm struggling with the tension between "noticed-by probably
hints that something is being fixed" and "noticed-by is addressing who
suggested it and why we're attributing it to them"
"as an aside" is itself an ellipsis for something like "as an aside to
some unrelated discussion and didn't really circle back to it as a top
level discussion point, but here we're closing the loop" -- but this
is obviously way too long-winded to be the written form.
> Either way, if we're going to define them as synonyms, I'd rather we
> just left the less common one out. If there's a distinction, and it's
> not a pain to describe, then maybe it'd be worth adding both.
>
> If we do add both, though, we at least need to fix "liked" to "like"
> in your description.
Right, it's a "first draft" [1]...
> > > +. `Co-authored-by:` is used to indicate that multiple people
> > > + contributed to the work of a patch.
> >
> > Junio's comments in [1] may be helpful here
> >
> > If co-authors closely worked together (possibly but not necessarily
> > outside the public view), exchanging drafts and agreeing on the
> > final version before sending it to the list, by one approving the
> > other's final draft, Co-authored-by may be appropriate.
> >
> > I would prefer to see more use of Helped-by when suggestions for
> > improvements were made, possibly but not necessarily in a concrete
> > "squashable patch" form, the original author accepted before
> > sending the new version out, and the party who made suggestions saw
> > the updated version at the same time as the general public.
> >
> > So I think we should be clear that "Co-authored-by:" means that multiple
> > authors worked closely together on the patch, rather than just
> > contributed to it.
Tentatively:
. `Co-authored-by:` is used to indicate that people exchanged drafts
of a patch before submitting it.
Note that I'm dropping `multiple` -- people implies that.
. `Helped-by:` is used to credit someone who suggested ideas for
changes without providing the precise changes in patch form.
> > I think we use "Montored-by:" specifically to credit the mentor on
> > patches written by GSoC or Outreachy interns and "Helped-by:" for the
> > general case of someone helping the patch author.
>
> Yes; I'd like for these to be distinguished in this way or something similar.
. `Mentored-by:` is used to credit someone with helping develop a
patch as part of a mentorship program (e.g., GSoC or Outreachy).
> > > You can also create your own tag or use one that's in common usage
> > > -such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:".
> > > +such as "Thanks-to:", "Based-on-patch-by:", or "Improved-by:".
> >
> > What's the difference between "Improved-by:" and "Helped-by:"?
I dunno. This entire section (as I called out at the beginning) is
frustrating...
Anyway, see all of us struggle with it below:
> > In
> > general I'd prefer for us not to encourage new trailers where we already
> > have a suitable one in use.
If this text needs to survive without being drastically changed, it
needs a warning saying "don't create a new tag if there's an already
used tag that seems like it'll cover what you're trying to say --
here's how to review them...". Note that I'd argue the cost being
asked of someone to do this research far exceeds what is reasonable to
ask of a new contributor, which is why I'd rather say that new
contributors shouldn't be inventing tags.
> Agreed.
I personally agree. I think encouraging non-core contributors to
invent their own is not a good idea. It leads to various things
(including inconsistently cased items because users fail to review the
current set / understand them/their-construction).
Saying that it's ok for core contributors to suggest a new tag and
that if a core contributor suggests a new tag that the person writing
the current series should just accept the tag and trust that it'll be
ok.
Note: I'm not going to draft wording to this effect on my own, and if
I were to provide such a change, it'd be its own commit prior to the
one here, because it's a significant process change as opposed to
clarifying the list of recommended tags.
> > Thanks for working on this, it will be good to have better descriptions
> > of our common trailers.
>
> Agreed here as well; thanks for the work, Josh.
[1] The Late Show With Stephen Colbert has a running segment called
First Drafts which showcases lousy first drafts of greeting cards,
they've https://www.cbsstore.com/products/the-late-show-with-stephen-colbert-first-drafts-greeting-card-pack-sc1193
^ 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