* Re: [PATCH v2 1/2] attr: add attr.tree for setting the treeish to read attributes from
From: Junio C Hamano @ 2023-10-04 19:58 UTC (permalink / raw)
To: John Cai via GitGitGadget; +Cc: git, Jeff King, John Cai
In-Reply-To: <446bce03a96836f35f94e9ef8548cf4a2b041ba8.1696443502.git.gitgitgadget@gmail.com>
"John Cai via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: John Cai <johncai86@gmail.com>
>
> 44451a2e5e (attr: teach "--attr-source=<tree>" global option to "git",
> 2023-05-06) provided the ability to pass in a treeish as the attr
> source. In the context of serving Git repositories as bare repos like we
> do at GitLab however, it would be easier to point --attr-source to HEAD
> for all commands by setting it once.
>
> Add a new config attr.tree that allows this.
Hmph, I wonder if we want to go all the way to emulate how the
mailmap.blob was done, including
- Default the value of attr.tree to HEAD in a bare repository;
- Notice but ignore errors if the attr.tree does not point at a
tree object, and pretend as if attr.tree specified an empty tree;
which does not seem to be in this patch. With such a change,
probably we do not even need [2/2] of the series, perhaps?
^ permalink raw reply
* Re: [PATCH v2 3/3] pkt-line: do not chomp newlines for sideband messages
From: Junio C Hamano @ 2023-10-04 20:05 UTC (permalink / raw)
To: Jiang Xin; +Cc: Oswald Buddenhagen, Git List, Jonathan Tan, Jiang Xin
In-Reply-To: <CANYiYbHp-3YuSPHnR8gjS40UJLrJV5FPzqd_BtjyR8TAALhfRQ@mail.gmail.com>
Jiang Xin <worldhello.net@gmail.com> writes:
> On Tue, Sep 26, 2023 at 4:48 PM Oswald Buddenhagen
> <oswald.buddenhagen@gmx.de> wrote:
>>
>> >Jiang Xin <worldhello.net@gmail.com> writes:
>> >
>> >> +++ b/pkt-line.c
>> >> @@ -462,8 +462,33 @@ enum packet_read_status packet_read_with_status(int fd, char **src_buffer,
>> >> }
>> >> + case 2:
>> >> + /* fallthrough */
>> >> + case 3:
>> >
>> while not entirely unprecedented, it's unnecessary and even
>> counter-productive to annotate directly adjacent cases with fallthrough.
>
> I see in "blame.c" there are directly adjacent cases like below. I
> will remove the fallthrough statement.
>
> case 'A':
> case 'T':
> /* Did not exist in parent, or type changed */
> break;
Yeah, it is far clearer to understand if it is written without the
"fallthru" comment between the cases and instead a comment that
explains both cases after them (exactly like the example you found
in "blame.c"). When we want "fallthru" comment is if we had some
processing specific to the earlier case ('A' or '2') that is not
done in the later case ('T' or '3'), in which case we may want to
explicitly say we did not forget to "break" by adding the "fallthru"
comment. But it does not apply here.
Thanks.
^ permalink raw reply
* [PATCH v3 2/3] diff-merges: introduce '--dd' option
From: Sergey Organov @ 2023-10-04 21:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sergey Organov
In-Reply-To: <20231004214558.210339-1-sorganov@gmail.com>
This option provides a shortcut to request diff with respect to first
parent for any kind of commit, universally. It's implemented as pure
synonym for "--diff-merges=first-parent --patch".
NOTE: originally proposed as '-d', and renamed to '--dd' due to Junio
request to keep "short-and-sweet" '-d' reserved for other uses.
Signed-off-by: Sergey Organov <sorganov@gmail.com>
---
Documentation/diff-options.txt | 5 +++++
Documentation/git-log.txt | 2 +-
diff-merges.c | 3 +++
t/t4013-diff-various.sh | 8 ++++++++
4 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 8035210c1418..f80d493dd4c8 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -56,6 +56,11 @@ ifdef::git-log[]
Produce dense combined diff output for merge commits.
Shortcut for '--diff-merges=dense-combined -p'.
+--dd::
+ Produce diff with respect to first parent for both merge and
+ regular commits.
+ Shortcut for '--diff-merges=first-parent -p'.
+
--remerge-diff::
Produce diff against re-merge.
Shortcut for '--diff-merges=remerge -p'.
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 9b7ec96e767a..579682172fe4 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -120,7 +120,7 @@ By default, `git log` does not generate any diff output. The options
below can be used to show the changes made by each commit.
Note that unless one of `--diff-merges` variants (including short
-`-m`, `-c`, and `--cc` options) is explicitly given, merge commits
+`-m`, `-c`, `--cc`, and `--dd` options) is explicitly given, merge commits
will not show a diff, even if a diff format like `--patch` is
selected, nor will they match search options like `-S`. The exception
is when `--first-parent` is in use, in which case `first-parent` is
diff --git a/diff-merges.c b/diff-merges.c
index ec97616db1df..45507588a279 100644
--- a/diff-merges.c
+++ b/diff-merges.c
@@ -131,6 +131,9 @@ int diff_merges_parse_opts(struct rev_info *revs, const char **argv)
} else if (!strcmp(arg, "--cc")) {
set_dense_combined(revs);
revs->merges_imply_patch = 1;
+ } else if (!strcmp(arg, "--dd")) {
+ set_first_parent(revs);
+ revs->merges_imply_patch = 1;
} else if (!strcmp(arg, "--remerge-diff")) {
set_remerge_diff(revs);
revs->merges_imply_patch = 1;
diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
index 5de1d190759f..4b474808311e 100755
--- a/t/t4013-diff-various.sh
+++ b/t/t4013-diff-various.sh
@@ -473,6 +473,14 @@ test_expect_success 'log --diff-merges=on matches --diff-merges=separate' '
test_cmp expected actual
'
+test_expect_success 'log --dd matches --diff-merges=1 -p' '
+ git log --diff-merges=1 -p master >result &&
+ process_diffs result >expected &&
+ git log --dd master >result &&
+ process_diffs result >actual &&
+ test_cmp expected actual
+'
+
test_expect_success 'deny wrong log.diffMerges config' '
test_config log.diffMerges wrong-value &&
test_expect_code 128 git log
--
2.25.1
^ permalink raw reply related
* [PATCH v3 1/3] diff-merges: improve --diff-merges documentation
From: Sergey Organov @ 2023-10-04 21:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sergey Organov
In-Reply-To: <20231004214558.210339-1-sorganov@gmail.com>
* Put descriptions of convenience shortcuts first, so they are the
first things reader observes rather than lengthy detailed stuff.
* Get rid of very long line containing all the --diff-merges formats
by replacing them with <format>, and putting each supported format
on its own line.
Signed-off-by: Sergey Organov <sorganov@gmail.com>
---
Documentation/diff-options.txt | 98 ++++++++++++++++++----------------
Documentation/git-log.txt | 2 +-
2 files changed, 54 insertions(+), 46 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 9f33f887711d..8035210c1418 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -43,66 +43,74 @@ endif::git-diff[]
endif::git-format-patch[]
ifdef::git-log[]
---diff-merges=(off|none|on|first-parent|1|separate|m|combined|c|dense-combined|cc|remerge|r)::
+-m::
+ Show diffs for merge commits in the default format. This is
+ similar to '--diff-merges=on' (which see) except `-m` will
+ produce no output unless `-p` is given as well.
+
+-c::
+ Produce combined diff output for merge commits.
+ Shortcut for '--diff-merges=combined -p'.
+
+--cc::
+ Produce dense combined diff output for merge commits.
+ Shortcut for '--diff-merges=dense-combined -p'.
+
+--remerge-diff::
+ Produce diff against re-merge.
+ Shortcut for '--diff-merges=remerge -p'.
+
--no-diff-merges::
+ Synonym for '--diff-merges=off'.
+
+--diff-merges=<format>::
Specify diff format to be used for merge commits. Default is
- {diff-merges-default} unless `--first-parent` is in use, in which case
- `first-parent` is the default.
+ {diff-merges-default} unless `--first-parent` is in use, in
+ which case `first-parent` is the default.
+
---diff-merges=(off|none):::
---no-diff-merges:::
+The following formats are supported:
++
+--
+off, none::
Disable output of diffs for merge commits. Useful to override
implied value.
+
---diff-merges=on:::
---diff-merges=m:::
--m:::
- This option makes diff output for merge commits to be shown in
- the default format. `-m` will produce the output only if `-p`
- is given as well. The default format could be changed using
+on, m::
+ Make diff output for merge commits to be shown in the default
+ format. The default format could be changed using
`log.diffMerges` configuration parameter, which default value
is `separate`.
+
---diff-merges=first-parent:::
---diff-merges=1:::
- This option makes merge commits show the full diff with
- respect to the first parent only.
+first-parent, 1::
+ Show full diff with respect to first parent. This is the same
+ format as `--patch` produces for non-merge commits.
+
---diff-merges=separate:::
- This makes merge commits show the full diff with respect to
- each of the parents. Separate log entry and diff is generated
- for each parent.
+separate::
+ Show full diff with respect to each of parents.
+ Separate log entry and diff is generated for each parent.
+
---diff-merges=remerge:::
---diff-merges=r:::
---remerge-diff:::
- With this option, two-parent merge commits are remerged to
- create a temporary tree object -- potentially containing files
- with conflict markers and such. A diff is then shown between
- that temporary tree and the actual merge commit.
+combined, c::
+ Show differences from each of the parents to the merge
+ result simultaneously instead of showing pairwise diff between
+ a parent and the result one at a time. Furthermore, it lists
+ only files which were modified from all parents.
++
+dense-combined, cc::
+ Further compress output produced by `--diff-merges=combined`
+ by omitting uninteresting hunks whose contents in the parents
+ have only two variants and the merge result picks one of them
+ without modification.
++
+remerge, r::
+ Remerge two-parent merge commits to create a temporary tree
+ object--potentially containing files with conflict markers
+ and such. A diff is then shown between that temporary tree
+ and the actual merge commit.
+
The output emitted when this option is used is subject to change, and
so is its interaction with other options (unless explicitly
documented).
-+
---diff-merges=combined:::
---diff-merges=c:::
--c:::
- With this option, diff output for a merge commit shows the
- differences from each of the parents to the merge result
- simultaneously instead of showing pairwise diff between a
- parent and the result one at a time. Furthermore, it lists
- only files which were modified from all parents. `-c` implies
- `-p`.
-+
---diff-merges=dense-combined:::
---diff-merges=cc:::
---cc:::
- With this option the output produced by
- `--diff-merges=combined` is further compressed by omitting
- uninteresting hunks whose contents in the parents have only
- two variants and the merge result picks one of them without
- modification. `--cc` implies `-p`.
+--
--combined-all-paths::
This flag causes combined diffs (used for merge commits) to
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 2a66cf888074..9b7ec96e767a 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -124,7 +124,7 @@ Note that unless one of `--diff-merges` variants (including short
will not show a diff, even if a diff format like `--patch` is
selected, nor will they match search options like `-S`. The exception
is when `--first-parent` is in use, in which case `first-parent` is
-the default format.
+the default format for merge commits.
:git-log: 1
:diff-merges-default: `off`
--
2.25.1
^ permalink raw reply related
* [PATCH v3 3/3] completion: complete '--dd'
From: Sergey Organov @ 2023-10-04 21:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sergey Organov
In-Reply-To: <20231004214558.210339-1-sorganov@gmail.com>
'--dd' only makes sense for 'git log' and 'git show', so add it to
__git_log_show_options which is referenced in the completion for these
two commands.
Signed-off-by: Sergey Organov <sorganov@gmail.com>
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 133ec92bfae7..ca4fa39f3ff8 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2042,7 +2042,7 @@ __git_log_shortlog_options="
"
# Options accepted by log and show
__git_log_show_options="
- --diff-merges --diff-merges= --no-diff-merges --remerge-diff
+ --diff-merges --diff-merges= --no-diff-merges --dd --remerge-diff
"
__git_diff_merges_opts="off none on first-parent 1 separate m combined c dense-combined cc remerge r"
--
2.25.1
^ permalink raw reply related
* [PATCH v3 0/3] diff-merges: introduce '--dd' option
From: Sergey Organov @ 2023-10-04 21:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sergey Organov
In-Reply-To: <20230909125446.142715-1-sorganov@gmail.com>
This new convenience option requests full diff with respect to first
parent, so that
git log --dd
will output diff with respect to first parent for every commit,
universally, no matter how many parents the commit turns out to have.
'--dd' is implemented as pure synonym for "--diff-merges=first-parent
--patch".
The first commit in the series tweaks diff-merges documentation a bit,
and is valuable by itself. It's put here as '--dd' implementation
commit depends on it in its documentation part.
Note: the need for this new convenience option mostly emerged from
denial by the community of patches that modify '-m' behavior to imply
'-p' as the rest of similar options (such as --cc) do. So, basically,
'--dd' is what '-m' should have been to be more useful.
Updates in v3:
* Option renamed from '-d' to '--dd' due to Junio overpowering
request to keep short-and-sweet '-d' reserved for another (yet
unspecified) use.
* Added completion of '--dd' to git-completion.bash.
Updates in v2:
* Reordered documentation for diff-merges formats in accordance with
Junio recommendation.
* Removed clarification of surprising -m behavior due to controversy
with Junio on how exactly it should look like.
Sergey Organov (3):
diff-merges: improve --diff-merges documentation
diff-merges: introduce '--dd' option
completion: complete '--dd'
Documentation/diff-options.txt | 103 ++++++++++++++-----------
Documentation/git-log.txt | 4 +-
contrib/completion/git-completion.bash | 2 +-
diff-merges.c | 3 +
t/t4013-diff-various.sh | 8 ++
5 files changed, 72 insertions(+), 48 deletions(-)
Interdiff against v2:
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 19bb78ff6652..f80d493dd4c8 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -48,10 +48,6 @@ ifdef::git-log[]
similar to '--diff-merges=on' (which see) except `-m` will
produce no output unless `-p` is given as well.
--d::
- Produce diff with respect to first parent.
- Shortcut for '--diff-merges=first-parent -p'.
-
-c::
Produce combined diff output for merge commits.
Shortcut for '--diff-merges=combined -p'.
@@ -60,6 +56,11 @@ ifdef::git-log[]
Produce dense combined diff output for merge commits.
Shortcut for '--diff-merges=dense-combined -p'.
+--dd::
+ Produce diff with respect to first parent for both merge and
+ regular commits.
+ Shortcut for '--diff-merges=first-parent -p'.
+
--remerge-diff::
Produce diff against re-merge.
Shortcut for '--diff-merges=remerge -p'.
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 59bd74a1a596..579682172fe4 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -120,7 +120,7 @@ By default, `git log` does not generate any diff output. The options
below can be used to show the changes made by each commit.
Note that unless one of `--diff-merges` variants (including short
-`-d`, `-m`, `-c`, and `--cc` options) is explicitly given, merge commits
+`-m`, `-c`, `--cc`, and `--dd` options) is explicitly given, merge commits
will not show a diff, even if a diff format like `--patch` is
selected, nor will they match search options like `-S`. The exception
is when `--first-parent` is in use, in which case `first-parent` is
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 133ec92bfae7..ca4fa39f3ff8 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2042,7 +2042,7 @@ __git_log_shortlog_options="
"
# Options accepted by log and show
__git_log_show_options="
- --diff-merges --diff-merges= --no-diff-merges --remerge-diff
+ --diff-merges --diff-merges= --no-diff-merges --dd --remerge-diff
"
__git_diff_merges_opts="off none on first-parent 1 separate m combined c dense-combined cc remerge r"
diff --git a/diff-merges.c b/diff-merges.c
index 6eb72e6fc28a..45507588a279 100644
--- a/diff-merges.c
+++ b/diff-merges.c
@@ -125,15 +125,15 @@ int diff_merges_parse_opts(struct rev_info *revs, const char **argv)
if (!suppress_m_parsing && !strcmp(arg, "-m")) {
set_to_default(revs);
revs->merges_need_diff = 0;
- } else if (!strcmp(arg, "-d")) {
- set_first_parent(revs);
- revs->merges_imply_patch = 1;
} else if (!strcmp(arg, "-c")) {
set_combined(revs);
revs->merges_imply_patch = 1;
} else if (!strcmp(arg, "--cc")) {
set_dense_combined(revs);
revs->merges_imply_patch = 1;
+ } else if (!strcmp(arg, "--dd")) {
+ set_first_parent(revs);
+ revs->merges_imply_patch = 1;
} else if (!strcmp(arg, "--remerge-diff")) {
set_remerge_diff(revs);
revs->merges_imply_patch = 1;
diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
index a07d6eb6dd97..4b474808311e 100755
--- a/t/t4013-diff-various.sh
+++ b/t/t4013-diff-various.sh
@@ -473,10 +473,10 @@ test_expect_success 'log --diff-merges=on matches --diff-merges=separate' '
test_cmp expected actual
'
-test_expect_success 'log -d matches --diff-merges=1 -p' '
+test_expect_success 'log --dd matches --diff-merges=1 -p' '
git log --diff-merges=1 -p master >result &&
process_diffs result >expected &&
- git log -d master >result &&
+ git log --dd master >result &&
process_diffs result >actual &&
test_cmp expected actual
'
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v3 1/3] diff-merges: improve --diff-merges documentation
From: Eric Sunshine @ 2023-10-04 22:02 UTC (permalink / raw)
To: Sergey Organov; +Cc: Junio C Hamano, git
In-Reply-To: <20231004214558.210339-2-sorganov@gmail.com>
On Wed, Oct 4, 2023 at 5:51 PM Sergey Organov <sorganov@gmail.com> wrote:
> * Put descriptions of convenience shortcuts first, so they are the
> first things reader observes rather than lengthy detailed stuff.
>
> * Get rid of very long line containing all the --diff-merges formats
> by replacing them with <format>, and putting each supported format
> on its own line.
>
> Signed-off-by: Sergey Organov <sorganov@gmail.com>
> ---
> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
> @@ -43,66 +43,74 @@ endif::git-diff[]
> +-m::
> + Show diffs for merge commits in the default format. This is
> + similar to '--diff-merges=on' (which see) except `-m` will
> + produce no output unless `-p` is given as well.
I'm having difficulty grasping the parenthetical "(which see)" comment.
^ permalink raw reply
* Re: [PATCH v3 1/3] diff-merges: improve --diff-merges documentation
From: Sergey Organov @ 2023-10-04 22:13 UTC (permalink / raw)
To: Eric Sunshine; +Cc: Junio C Hamano, git
In-Reply-To: <CAPig+cT63L2+XmDRKw4Pc+iDmUL+UFcyummOcOtS+3wYaNbFvg@mail.gmail.com>
Eric Sunshine <sunshine@sunshineco.com> writes:
> On Wed, Oct 4, 2023 at 5:51 PM Sergey Organov <sorganov@gmail.com> wrote:
>> * Put descriptions of convenience shortcuts first, so they are the
>> first things reader observes rather than lengthy detailed stuff.
>>
>> * Get rid of very long line containing all the --diff-merges formats
>> by replacing them with <format>, and putting each supported format
>> on its own line.
>>
>> Signed-off-by: Sergey Organov <sorganov@gmail.com>
>> ---
>> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
>> @@ -43,66 +43,74 @@ endif::git-diff[]
>> +-m::
>> + Show diffs for merge commits in the default format. This is
>> + similar to '--diff-merges=on' (which see) except `-m` will
>> + produce no output unless `-p` is given as well.
>
> I'm having difficulty grasping the parenthetical "(which see)" comment.
I believe it's translated full form of q.v., see:
https://en.wikipedia.org/wiki/List_of_Latin_abbreviations
"q.v.
quod vide
"which see"
Imperative, used after a term or phrase that should be looked up
elsewhere in the current document or book."
HTH,
-- Sergey Organov
^ permalink raw reply
* Re: [PATCH v2 1/2] attr: add attr.tree for setting the treeish to read attributes from
From: Junio C Hamano @ 2023-10-04 23:45 UTC (permalink / raw)
To: John Cai via GitGitGadget, Jonathan Tan; +Cc: git, Jeff King, John Cai
In-Reply-To: <446bce03a96836f35f94e9ef8548cf4a2b041ba8.1696443502.git.gitgitgadget@gmail.com>
[jc: JTan CC'ed as he seems to have took over the polishing of
b1bda751 (parse: separate out parsing functions from config.h,
2023-09-29)]
"John Cai via GitGitGadget" <gitgitgadget@gmail.com> writes:
> diff --git a/attr.c b/attr.c
> index 71c84fbcf86..bb0d54eb967 100644
> --- a/attr.c
> +++ b/attr.c
> @@ -1205,6 +1205,13 @@ static void compute_default_attr_source(struct object_id *attr_source)
> if (!default_attr_source_tree_object_name)
> default_attr_source_tree_object_name = getenv(GIT_ATTR_SOURCE_ENVIRONMENT);
>
> + if (!default_attr_source_tree_object_name) {
> + char *attr_tree;
> +
> + if (!git_config_get_string("attr.tree", &attr_tree))
> + default_attr_source_tree_object_name = attr_tree;
> + }
> +
> if (!default_attr_source_tree_object_name || !is_null_oid(attr_source))
> return;
As this adds a new call to git_config_get_string(), which will only
be available by including <config.h>, a merge-fix into 'seen' of
this topic needs to revert what b1bda751 (parse: separate out
parsing functions from config.h, 2023-09-29) did, which made this
file include only <parse.h>.
As this configuration variable was invented to improve the way the
attribute source tree is supported by emulating how mailmap.blob is
done, it deserves a bit of comparison.
The way mailmap.c does this is not have any code that reads or
parses configuration in mailmap.c (which is a rather library-ish
place), and leaves it up to callers to pre-populate the global
variable git_mailmap_blob with config.c:git_default_config(). That
way, they do not need to include <config.h> (nor <parse.h>) that is
closer to the UI layer. I am wondering why we are not doing the
same, and instead making an ad-hoc call to git_config_get_string()
in this code, and if it is a good direction to move the codebase to
(in which case we may want to make sure that the same pattern is
followed in other places).
Folks interested in libification, as to the direction of that
effort, what's your plan on where to draw a line between "library"
and "userland"? Should library-ish code be allowed to call
git_config_anything()? I somehow suspect that it might be cleaner
if they didn't, and instead have the user of the "attr" module to
supply the necessary values from outside.
On the other hand, once the part we have historically called
"config" API gets a reasonably solid abstraction so that they become
pluggable and replaceable, random ad-hoc calls from library code
outside the "config" library code may not be a huge problem, as long
as we plumb the necessary object handles around (so "attr" library
would need to be told which "config" backend is in use, probably in
the form of a struct that holds the various states in to replace
the current use of globals, plus a vtable to point at
implementations of the "config" service, and git_config_get_string()
call in such a truly libified world would grab the value of the named
variable transparently from whichever "config" backend is currently
in use).
Anyway, I think I wiggled this patch into 'seen' so I'll push out
today's integration result shortly.
^ permalink raw reply
* What's cooking in git.git (Oct 2023, #02; Wed, 4)
From: Junio C Hamano @ 2023-10-04 23:45 UTC (permalink / raw)
To: git
Here are the topics that have been cooking in my tree. Commits
prefixed with '+' are in 'next' (being in 'next' is a sign that a
topic is stable enough to be used and are candidate to be in a
future release). Commits prefixed with '-' are only in 'seen', and
aren't considered "accepted" at all and may be annotated with an URL
to a message that raises issues but they are no means exhaustive. A
topic without enough support may be discarded after a long period of
no activity (of course they can be resubmit when new interests
arise).
Copies of the source code to Git live in many repositories, and the
following is a list of the ones I push into or their mirrors. Some
repositories have only a subset of branches.
With maint, master, next, seen, todo:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://kernel.googlesource.com/pub/scm/git/git/
https://github.com/git/git/
https://gitlab.com/git-vcs/git/
With all the integration branches and topics broken out:
https://github.com/gitster/git/
Even though the preformatted documentation in HTML and man format
are not sources, they are published in these repositories for
convenience (replace "htmldocs" with "manpages" for the manual
pages):
git://git.kernel.org/pub/scm/git/git-htmldocs.git/
https://github.com/gitster/git-htmldocs.git/
Release tarballs are available at:
https://www.kernel.org/pub/software/scm/git/
--------------------------------------------------
[Graduated to 'master']
* bb/unicode-width-table-15 (2023-09-25) 1 commit
(merged to 'next' on 2023-09-28 at bb76f46606)
+ unicode: update the width tables to Unicode 15.1
The display width table for unicode characters has been updated for
Unicode 15.1
source: <20230925190704.157731-1-dev+git@drbeat.li>
* jk/commit-graph-verify-fix (2023-09-28) 6 commits
(merged to 'next' on 2023-09-28 at e3ed560a2f)
+ commit-graph: report incomplete chains during verification
+ commit-graph: tighten chain size check
+ commit-graph: detect read errors when verifying graph chain
+ t5324: harmonize sha1/sha256 graph chain corruption
+ commit-graph: check mixed generation validation when loading chain file
+ commit-graph: factor out chain opening function
Various fixes to "git commit-graph verify".
source: <20230928043746.GB57926@coredump.intra.peff.net>
* ks/ref-filter-mailmap (2023-09-25) 3 commits
(merged to 'next' on 2023-09-28 at 0d3fd9959a)
+ ref-filter: add mailmap support
+ t/t6300: introduce test_bad_atom
+ t/t6300: cleanup test_atom
"git for-each-ref" and friends learn to apply mailmap to authorname
and other fields.
source: <20230925175050.3498-1-five231003@gmail.com>
* ps/revision-cmdline-stdin-not (2023-09-25) 1 commit
(merged to 'next' on 2023-09-28 at a28201e0dd)
+ revision: make pseudo-opt flags read via stdin behave consistently
"git rev-list --stdin" learned to take non-revisions (like "--not")
recently from the standard input, but the way such a "--not" was
handled was quite confusing, which has been rethought. This is
potentially a change that breaks backward compatibility.
source: <6221acd2796853144f8e84081655fbc79fdc6634.1695646898.git.ps@pks.im>
* xz/commit-title-soft-limit-doc (2023-09-28) 1 commit
(merged to 'next' on 2023-09-28 at 20df852430)
+ doc: correct the 50 characters soft limit
Doc tweak.
source: <pull.1580.git.git.1695895155985.gitgitgadget@gmail.com>
--------------------------------------------------
[New Topics]
* jk/commit-graph-leak-fixes (2023-10-03) 10 commits
- commit-graph: clear oidset after finishing write
- commit-graph: free write-context base_graph_name during cleanup
- commit-graph: free write-context entries before overwriting
- commit-graph: free graph struct that was not added to chain
- commit-graph: delay base_graph assignment in add_graph_to_chain()
- commit-graph: free all elements of graph chain
- commit-graph: move slab-clearing to close_commit_graph()
- merge: free result of repo_get_merge_bases()
- commit-reach: free temporary list in get_octopus_merge_bases()
- t6700: mark test as leak-free
Leakfix.
source: <20231003202504.GA7697@coredump.intra.peff.net>
* jm/git-status-submodule-states-docfix (2023-10-04) 1 commit
(merged to 'next' on 2023-10-04 at 520b7711a4)
+ git-status.txt: fix minor asciidoc format issue
Docfix.
Will merge to 'master'.
source: <pull.1591.v3.git.1696386165616.gitgitgadget@gmail.com>
* rs/parse-opt-ctx-cleanup (2023-10-03) 1 commit
(merged to 'next' on 2023-10-04 at d5d0a2ce3b)
+ parse-options: drop unused parse_opt_ctx_t member
Code clean-up.
Will merge to 'master'.
source: <ebcaa9e1-d306-4c93-adec-3f35d7040531@web.de>
* tb/repack-max-cruft-size (2023-10-03) 4 commits
- builtin/repack.c: avoid making cruft packs preferred
- builtin/repack.c: implement support for `--max-cruft-size`
- builtin/repack.c: parse `--max-pack-size` with OPT_MAGNITUDE
- t7700: split cruft-related tests to t7704
"git repack" learned "--max-cruft-size" to prevent cruft packs from
growing without bounds.
Will merge to 'next'?
source: <cover.1696293862.git.me@ttaylorr.com>
* ak/color-decorate-symbols (2023-10-03) 1 commit
- decorate: add color.decorate.symbols config option
A new config for coloring.
Needs review.
source: <20231003205442.22963-1-andy.koppe@gmail.com>
* jc/attr-tree-config (2023-10-04) 2 commits
- attr: add attr.allowInvalidSource config to allow invalid revision
- attr: add attr.tree for setting the treeish to read attributes from
The attribute subsystem learned to honor `attr.tree` configuration
that specifies which tree to read the .gitattributes files from.
Needs review.
source: <pull.1577.v2.git.git.1696443502.gitgitgadget@gmail.com>
* js/submodule-fix-misuse-of-path-and-name (2023-10-03) 6 commits
- t7420: test that we correctly handle renamed submodules
- t7419: test that we correctly handle renamed submodules
- t7419, t7420: use test_cmp_config instead of grepping .gitmodules
- t7419: actually test the branch switching
- submodule--helper: return error from set-url when modifying failed
- submodule--helper: use submodule_from_path in set-{url,branch}
In .gitmodules files, submodules are keyed by their names, and the
path to the submodule whose name is $name is specified by the
submodule.$name.path variable. There were a few codepaths that
mixed the name and path up when consulting the submodule database,
which have been corrected. It took long for these bugs to be found
as the name of a submodule initially is the same as its path, and
the problem does not surface until it is moved to a different path,
which apparently happens very rarely.
Will merge to 'next'?
source: <0a0a157f88321d25fdb0be771a454b3410a449f3.camel@archlinux.org>
--------------------------------------------------
[Stalled]
* tk/cherry-pick-sequence-requires-clean-worktree (2023-06-01) 1 commit
- cherry-pick: refuse cherry-pick sequence if index is dirty
"git cherry-pick A" that replays a single commit stopped before
clobbering local modification, but "git cherry-pick A..B" did not,
which has been corrected.
Expecting a reroll.
cf. <999f12b2-38d6-f446-e763-4985116ad37d@gmail.com>
source: <pull.1535.v2.git.1685264889088.gitgitgadget@gmail.com>
* jc/diff-cached-fsmonitor-fix (2023-09-15) 3 commits
- diff-lib: fix check_removed() when fsmonitor is active
- Merge branch 'jc/fake-lstat' into jc/diff-cached-fsmonitor-fix
- Merge branch 'js/diff-cached-fsmonitor-fix' into jc/diff-cached-fsmonitor-fix
(this branch uses jc/fake-lstat.)
The optimization based on fsmonitor in the "diff --cached"
codepath is resurrected with the "fake-lstat" introduced earlier.
It is unknown if the optimization is worth resurrecting, but in case...
source: <xmqqr0n0h0tw.fsf@gitster.g>
--------------------------------------------------
[Cooking]
* cw/prelim-cleanup (2023-09-29) 4 commits
(merged to 'next' on 2023-10-03 at 5985929612)
+ parse: separate out parsing functions from config.h
+ config: correct bad boolean env value error message
+ wrapper: reduce scope of remove_or_warn()
+ hex-ll: separate out non-hash-algo functions
Shuffle some bits across headers and sources to prepare for
libification effort.
Will merge to 'master'.
source: <cover.1696021277.git.jonathantanmy@google.com>
* ds/init-diffstat-width (2023-09-29) 1 commit
(merged to 'next' on 2023-10-03 at 18383ac895)
+ diff --stat: set the width defaults in a helper function
Code clean-up.
Will merge to 'master'.
source: <d45d1dac1a20699e370905b88b6fd0ec296751e7.1695441501.git.dsimic@manjaro.org>
* ar/diff-index-merge-base-fix (2023-10-02) 1 commit
- diff: fix --merge-base with annotated tags
source: <20231001151845.3621551-1-hi@alyssa.is>
* eb/limit-bulk-checkin-to-blobs (2023-09-26) 1 commit
(merged to 'next' on 2023-10-02 at 89c9c95966)
+ bulk-checkin: only support blobs in index_bulk_checkin
The "streaming" interface used for bulk-checkin codepath has been
narrowed to take only blob objects for now, with no real loss of
functionality.
Will merge to 'master'.
source: <87msx99b9o.fsf_-_@gmail.froward.int.ebiederm.org>
* js/update-urls-in-doc-and-comment (2023-09-26) 4 commits
- doc: refer to internet archive
- doc: update links for andre-simon.de
- doc: update links to current pages
- doc: switch links to https
Stale URLs have been updated to their current counterparts (or
archive.org) and HTTP links are replaced with working HTTPS links.
Needs eyeballing.
source: <pull.1589.v2.git.1695553041.gitgitgadget@gmail.com>
* la/trailer-cleanups (2023-09-26) 4 commits
- trailer: only use trailer_block_* variables if trailers were found
- trailer: use offsets for trailer_start/trailer_end
- trailer: find the end of the log message
- commit: ignore_non_trailer computes number of bytes to ignore
Code clean-up.
Needs review.
source: <pull.1563.v4.git.1695709372.gitgitgadget@gmail.com>
* eb/hash-transition (2023-10-02) 30 commits
- t1016-compatObjectFormat: add tests to verify the conversion between objects
- t1006: test oid compatibility with cat-file
- t1006: rename sha1 to oid
- test-lib: compute the compatibility hash so tests may use it
- builtin/ls-tree: let the oid determine the output algorithm
- object-file: handle compat objects in check_object_signature
- tree-walk: init_tree_desc take an oid to get the hash algorithm
- builtin/cat-file: let the oid determine the output algorithm
- rev-parse: add an --output-object-format parameter
- repository: implement extensions.compatObjectFormat
- object-file: update object_info_extended to reencode objects
- object-file-convert: convert commits that embed signed tags
- object-file-convert: convert commit objects when writing
- object-file-convert: don't leak when converting tag objects
- object-file-convert: convert tag objects when writing
- object-file-convert: add a function to convert trees between algorithms
- object: factor out parse_mode out of fast-import and tree-walk into in object.h
- cache: add a function to read an OID of a specific algorithm
- tag: sign both hashes
- commit: export add_header_signature to support handling signatures on tags
- commit: convert mergetag before computing the signature of a commit
- commit: write commits for both hashes
- object-file: add a compat_oid_in parameter to write_object_file_flags
- object-file: update the loose object map when writing loose objects
- loose: compatibilty short name support
- loose: add a mapping between SHA-1 and SHA-256 for loose objects
- repository: add a compatibility hash algorithm
- object-names: support input of oids in any supported hash
- oid-array: teach oid-array to handle multiple kinds of oids
- object-file-convert: stubs for converting from one object format to another
Teach a repository to work with both SHA-1 and SHA-256 hash algorithms.
Breaks a few CI jobs when merged to 'seen'.
cf. <xmqqbkdmjbkp.fsf@gitster.g>
source: <878r8l929e.fsf@gmail.froward.int.ebiederm.org>
* jx/remote-archive-over-smart-http (2023-10-04) 4 commits
- archive: support remote archive from stateless transport
- transport-helper: call do_take_over() in connect_helper
- transport-helper: call do_take_over() in process_connect
- transport-helper: no connection restriction in connect_helper
"git archive --remote=<remote>" learned to talk over the smart
http (aka stateless) transport.
source: <cover.1696432593.git.zhiyou.jx@alibaba-inc.com>
* jx/sideband-chomp-newline-fix (2023-10-04) 3 commits
- pkt-line: do not chomp newlines for sideband messages
- pkt-line: memorize sideband fragment in reader
- test-pkt-line: add option parser for unpack-sideband
Sideband demultiplexer fixes.
Needs review.
source: <cover.1696425168.git.zhiyou.jx@alibaba-inc.com>
* ty/merge-tree-strategy-options (2023-09-25) 1 commit
(merged to 'next' on 2023-09-29 at aa65b54416)
+ merge-tree: add -X strategy option
"git merge-tree" learned to take strategy backend specific options
via the "-X" option, like "git merge" does.
Will merge to 'master'.
source: <pull.1565.v6.git.1695522222723.gitgitgadget@gmail.com>
* js/ci-coverity (2023-09-25) 7 commits
- SQUASH???
- coverity: detect and report when the token or project is incorrect
- coverity: allow running on macOS
- coverity: support building on Windows
- coverity: allow overriding the Coverity project
- coverity: cache the Coverity Build Tool
- ci: add a GitHub workflow to submit Coverity scans
GitHub CI workflow has learned to trigger Coverity check.
Looking good.
source: <pull.1588.v2.git.1695642662.gitgitgadget@gmail.com>
* js/config-parse (2023-09-21) 5 commits
- config-parse: split library out of config.[c|h]
- config.c: accept config_parse_options in git_config_from_stdin
- config: report config parse errors using cb
- config: split do_event() into start and flush operations
- config: split out config_parse_options
The parsing routines for the configuration files have been split
into a separate file.
source: <cover.1695330852.git.steadmon@google.com>
* jc/fake-lstat (2023-09-15) 1 commit
- cache: add fake_lstat()
(this branch is used by jc/diff-cached-fsmonitor-fix.)
A new helper to let us pretend that we called lstat() when we know
our cache_entry is up-to-date via fsmonitor.
Needs review.
source: <xmqqcyykig1l.fsf@gitster.g>
* kn/rev-list-ignore-missing-links (2023-09-20) 1 commit
- revision: add `--ignore-missing-links` user option
Surface the .ignore_missing_links bit that stops the revision
traversal from stopping and dying when encountering a missing
object to a new command line option of "git rev-list", so that the
objects that are required but are missing can be enumerated.
Waiting for review response.
source: <20230920104507.21664-1-karthik.188@gmail.com>
* rs/parse-options-value-int (2023-09-18) 2 commits
- parse-options: use and require int pointer for OPT_CMDMODE
- parse-options: add int value pointer to struct option
A bit of type safety for the "value" pointer used in the
parse-options API.
Comments?
source: <e6d8a291-03de-cfd3-3813-747fc2cad145@web.de>
* so/diff-merges-d (2023-09-11) 2 commits
- diff-merges: introduce '-d' option
- diff-merges: improve --diff-merges documentation
Teach a new "-d" option that shows the patch against the first
parent for merge commits (which is "--diff-merges=first-parent -p").
Letting a less useful combination of options squat on short-and-sweet "-d" feels dubious.
source: <20230909125446.142715-1-sorganov@gmail.com>
* cc/repack-sift-filtered-objects-to-separate-pack (2023-10-02) 9 commits
(merged to 'next' on 2023-10-03 at e5a4824609)
+ gc: add `gc.repackFilterTo` config option
+ repack: implement `--filter-to` for storing filtered out objects
+ gc: add `gc.repackFilter` config option
+ repack: add `--filter=<filter-spec>` option
+ pack-bitmap-write: rebuild using new bitmap when remapping
+ repack: refactor finding pack prefix
+ repack: refactor finishing pack-objects command
+ t/helper: add 'find-pack' test-tool
+ pack-objects: allow `--filter` without `--stdout`
"git repack" machinery learns to pay attention to the "--filter="
option.
Will merge to 'master'.
cf. <ZRsknb4NxNHTR21E@nand.local>
source: <20231002165504.1325153-1-christian.couder@gmail.com>
* pw/rebase-sigint (2023-09-07) 1 commit
- rebase -i: ignore signals when forking subprocesses
If the commit log editor or other external programs (spawned via
"exec" insn in the todo list) receive internactive signal during
"git rebase -i", it caused not just the spawned program but the
"Git" process that spawned them, which is often not what the end
user intended. "git" learned to ignore SIGINT and SIGQUIT while
waiting for these subprocesses.
Expecting a reroll.
cf. <12c956ea-330d-4441-937f-7885ab519e26@gmail.com>
source: <pull.1581.git.1694080982621.gitgitgadget@gmail.com>
* cc/git-replay (2023-09-07) 15 commits
- replay: stop assuming replayed branches do not diverge
- replay: add --contained to rebase contained branches
- replay: add --advance or 'cherry-pick' mode
- replay: disallow revision specific options and pathspecs
- replay: use standard revision ranges
- replay: make it a minimal server side command
- replay: remove HEAD related sanity check
- replay: remove progress and info output
- replay: add an important FIXME comment about gpg signing
- replay: don't simplify history
- replay: introduce pick_regular_commit()
- replay: die() instead of failing assert()
- replay: start using parse_options API
- replay: introduce new builtin
- t6429: remove switching aspects of fast-rebase
Waiting for review response.
cf. <52277471-4ddd-b2e0-62ca-c2a5b59ae418@gmx.de>
cf. <58daa706-7efb-51dd-9061-202ef650b96a@gmx.de>
cf. <f0e75d47-c277-9fbb-7bcd-53e4e5686f3c@gmx.de>
May want to wait until tb/repack-existing-packs-cleanup stabilizes.
source: <20230907092521.733746-1-christian.couder@gmail.com>
* la/trailer-test-and-doc-updates (2023-09-07) 13 commits
- trailer doc: <token> is a <key> or <keyAlias>, not both
- trailer doc: separator within key suppresses default separator
- trailer doc: emphasize the effect of configuration variables
- trailer --unfold help: prefer "reformat" over "join"
- trailer --parse docs: add explanation for its usefulness
- trailer --only-input: prefer "configuration variables" over "rules"
- trailer --parse help: expose aliased options
- trailer --no-divider help: describe usual "---" meaning
- trailer: trailer location is a place, not an action
- trailer doc: narrow down scope of --where and related flags
- trailer: add tests to check defaulting behavior with --no-* flags
- trailer test description: this tests --where=after, not --where=before
- trailer tests: make test cases self-contained
Test coverage for trailers has been improved.
source: <pull.1564.v3.git.1694125209.gitgitgadget@gmail.com>
* js/doc-unit-tests (2023-08-17) 3 commits
- ci: run unit tests in CI
- unit tests: add TAP unit test framework
- unit tests: Add a project plan document
(this branch is used by js/doc-unit-tests-with-cmake.)
Process to add some form of low-level unit tests has started.
Waiting for review response.
cf. <xmqq350hw6n7.fsf@gitster.g>
source: <cover.1692297001.git.steadmon@google.com>
* js/doc-unit-tests-with-cmake (2023-09-25) 7 commits
- cmake: handle also unit tests
- cmake: use test names instead of full paths
- cmake: fix typo in variable name
- artifacts-tar: when including `.dll` files, don't forget the unit-tests
- unit-tests: do show relative file paths
- unit-tests: do not mistake `.pdb` files for being executable
- cmake: also build unit tests
(this branch uses js/doc-unit-tests.)
Update the base topic to work with CMake builds.
Waiting for the base topic to settle.
source: <pull.1579.v3.git.1695640836.gitgitgadget@gmail.com>
* tb/path-filter-fix (2023-08-30) 15 commits
- bloom: introduce `deinit_bloom_filters()`
- commit-graph: reuse existing Bloom filters where possible
- object.h: fix mis-aligned flag bits table
- commit-graph: drop unnecessary `graph_read_bloom_data_context`
- commit-graph.c: unconditionally load Bloom filters
- t/t4216-log-bloom.sh: harden `test_bloom_filters_not_used()`
- bloom: prepare to discard incompatible Bloom filters
- bloom: annotate filters with hash version
- commit-graph: new filter ver. that fixes murmur3
- repo-settings: introduce commitgraph.changedPathsVersion
- t4216: test changed path filters with high bit paths
- t/helper/test-read-graph: implement `bloom-filters` mode
- bloom.h: make `load_bloom_filter_from_graph()` public
- t/helper/test-read-graph.c: extract `dump_graph_info()`
- gitformat-commit-graph: describe version 2 of BDAT
The Bloom filter used for path limited history traversal was broken
on systems whose "char" is unsigned; update the implementation and
bump the format version to 2.
Still being discussed.
cf. <20230830200218.GA5147@szeder.dev>
cf. <20230901205616.3572722-1-jonathantanmy@google.com>
cf. <20230924195900.GA1156862@szeder.dev>
source: <cover.1693413637.git.jonathantanmy@google.com>
* jc/rerere-cleanup (2023-08-25) 4 commits
- rerere: modernize use of empty strbuf
- rerere: try_merge() should use LL_MERGE_ERROR when it means an error
- rerere: fix comment on handle_file() helper
- rerere: simplify check_one_conflict() helper function
Code clean-up.
Not ready to be reviewed yet.
source: <20230824205456.1231371-1-gitster@pobox.com>
* rj/status-bisect-while-rebase (2023-08-01) 1 commit
- status: fix branch shown when not only bisecting
"git status" is taught to show both the branch being bisected and
being rebased when both are in effect at the same time.
Needs review.
cf. <xmqqtttia3vn.fsf@gitster.g>
source: <48745298-f12b-8efb-4e48-90d2c22a8349@gmail.com>
--------------------------------------------------
[Discarded]
* tb/ci-coverity (2023-09-21) 1 commit
. .github/workflows: add coverity action
GitHub CI workflow has learned to trigger Coverity check.
Superseded by the js/ci-coverity topic.
source: <b23951c569660e1891a7fb3ad2c2ea1952897bd7.1695332105.git.me@ttaylorr.com>
* cw/git-std-lib (2023-09-11) 7 commits
. SQUASH???
. git-std-lib: add test file to call git-std-lib.a functions
. git-std-lib: introduce git standard library
. parse: create new library for parsing strings and env values
. config: correct bad boolean env value error message
. wrapper: remove dependency to Git-specific internal file
. hex-ll: split out functionality from hex
Another libification effort.
Superseded by the cw/prelim-cleanup topic.
cf. <xmqqy1hfrk6p.fsf@gitster.g>
cf. <20230915183927.1597414-1-jonathantanmy@google.com>
source: <20230908174134.1026823-1-calvinwan@google.com>
^ permalink raw reply
* [PATCH v2 5/5] t/README: fix multi-prerequisite example
From: Štěpán Němec @ 2023-10-05 9:00 UTC (permalink / raw)
To: git
In-Reply-To: <20231005090055.3097783-1-stepnem@smrk.net>
With the broken quoting the test wouldn't even parse correctly, but
there's also the '==' instead of POSIX '=' (of the shells I tested,
busybox ash, bash and ksh (93 and OpenBSD) accept '==', dash and zsh do
not), and 'print 2' from Python 2 days.
(I assume the test failing due to 3 != 4 is intentional or immaterial.)
Fixes: 93a572461386 ("test-lib: Add support for multiple test prerequisites")
Signed-off-by: Štěpán Němec <stepnem@smrk.net>
---
t/README | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/README b/t/README
index 2ef89785f831..a0ebe294848d 100644
--- a/t/README
+++ b/t/README
@@ -887,7 +887,7 @@ see test-lib-functions.sh for the full list and their options.
rare case where your test depends on more than one:
test_expect_success PERL,PYTHON 'yo dawg' \
- ' test $(perl -E 'print eval "1 +" . qx[python -c "print 2"]') == "4" '
+ ' test $(perl -E '\''print eval "1 +" . qx[python -c "print(2)"]'\'') = "4" '
- test_expect_failure [<prereq>] <message> <script>
--
2.42.0
^ permalink raw reply related
* [PATCH v2 1/5] doc: fix some typos, grammar and wording issues
From: Štěpán Němec @ 2023-10-05 9:00 UTC (permalink / raw)
To: git; +Cc: Eric Sunshine, Junio C Hamano
In-Reply-To: <20231003082107.3002173-1-stepnem@smrk.net>
Signed-off-by: Štěpán Němec <stepnem@smrk.net>
---
v2: Feedback from Eric and Junio, implement most of Eric's suggestions.
Range-diff with two inline comments follows:
1: 2ab1bdb9a999 ! 1: 6c2766f9471f Fix some typos, grammar or wording issues in the documentation
@@ Metadata
Author: Štěpán Němec <stepnem@smrk.net>
## Commit message ##
- Fix some typos, grammar or wording issues in the documentation
+ doc: fix some typos, grammar and wording issues
## Documentation/SubmittingPatches ##
@@ Documentation/SubmittingPatches: mailing list{security-ml}, instead of the public mailing list.
@@ Documentation/SubmittingPatches: help you find out who they are.
[[patch-status]]
+ ## Documentation/config/transfer.txt ##
+@@ Documentation/config/transfer.txt: exposure, e.g. because:
+ system.
+ * The git programs will pass the full URL to one another as arguments
+ on the command-line, meaning the credentials will be exposed to other
+- users on OS's or systems that allow other users to see the full
++ unprivileged users on systems that allow them to see the full
+ process list of other users. On linux the "hidepid" setting
+ documented in procfs(5) allows for configuring this behavior.
+ +
+
Another "OS's" missed in v1, plus an attempt to fix the triple "other
users" in a single sentence.
## Documentation/diff-options.txt ##
@@ Documentation/diff-options.txt: ifndef::git-format-patch[]
@@ Documentation/git.txt: foo.bar= ...`) sets `foo.bar` to the empty string which `
+
This is useful for cases where you want to pass transitory
-configuration options to git, but are doing so on OS's where
-+configuration options to git, but are doing so on OSes where
- other processes might be able to read your cmdline
- (e.g. `/proc/self/cmdline`), but not your environ
+-other processes might be able to read your cmdline
+-(e.g. `/proc/self/cmdline`), but not your environ
++configuration options to git, but are doing so on operating systems
++where other processes might be able to read your command line
++(e.g. `/proc/self/cmdline`), but not your environment
(e.g. `/proc/self/environ`). That behavior is the default on
+ Linux, but may not be on your system.
+ +
## Documentation/gitattributes.txt ##
@@ Documentation/gitattributes.txt: will be stored via placeholder `%P`.
@@ Documentation/gitattributes.txt: will be stored via placeholder `%P`.
This attribute controls the length of conflict markers left in
-the work tree file during a conflicted merge. Only setting to
-+the work tree file during a conflicted merge. Only setting
- the value to a positive integer has any meaningful effect.
+-the value to a positive integer has any meaningful effect.
++the work tree file during a conflicted merge. Only a positive
++integer has a meaningful effect.
For example, this line in `.gitattributes` can be used to tell the merge
+ machinery to leave much longer (instead of the usual 7-character-long)
## Documentation/giteveryday.txt ##
@@ Documentation/giteveryday.txt: without a formal "merging". Or longhand +
@@ Documentation/giteveryday.txt: without a formal "merging". Or longhand +
## contrib/README ##
-@@ contrib/README: lesser degree various foreign SCM interfaces, so you know the
+@@ contrib/README: This is the same way as how I have been treating gitk, and to a
+ lesser degree various foreign SCM interfaces, so you know the
drill.
- I expect that things that start their life in the contrib/ area
--to graduate out of contrib/ once they mature, either by becoming
-+graduate out of contrib/ once they mature, either by becoming
+-I expect that things that start their life in the contrib/ area
++I expect things that start their life in the contrib/ area
+ to graduate out of contrib/ once they mature, either by becoming
projects on their own, or moving to the toplevel directory. On
the other hand, I expect I'll be proposing removal of disused
- and inactive ones from time to time.
+@@ contrib/README: and inactive ones from time to time.
If you have new things to add to this area, please first propose
it on the git mailing list, and after a list discussion proves
@@ contrib/README: lesser degree various foreign SCM interfaces, so you know the
audience -- for example I do not work with projects whose
upstream is svn, so I have no use for git-svn myself, but it is
+ ## fsmonitor--daemon.h ##
+@@ fsmonitor--daemon.h: struct fsmonitor_daemon_state {
+ * to only mean an external GITDIR referenced by a ".git" file.
+ *
+ * The platform FS event backends will receive watch-specific
+- * relative paths (except for those OS's that always emit absolute
++ * relative paths (except for those OSes that always emit absolute
+ * paths). We use the following enum and routines to classify each
+ * path so that we know how to handle it. There is a slight asymmetry
+ * here because ".git/" is inside the working directory and the
+
Ended up only fixing the spelling here: expanding the abbreviation
seemed unnecessarily intrusive given the context, and I'd say the
abbreviation pragmatics is different in a header file compared to the
main user-facing docs like git.txt above.
## strbuf.h ##
@@
struct string_list;
@@ t/README: The argument for --run, <test-selector>, is a list of description
suite to include (or exclude, if negated) in the run. A range is two
-numbers separated with a dash and matches a range of tests with both
-ends been included. You may omit the first or the second number to
-+numbers separated with a dash and matches an inclusive range of tests
++numbers separated with a dash and specifies an inclusive range of tests
+to run. You may omit the first or the second number to
mean "from the first test" or "up to the very last test" respectively.
@@ t/README: This test harness library does the following things:
-Here are some recommented styles when writing test case.
- - Keep test title the same line with test helper function itself.
-+ - Keep test titles and helper function invocations on the same line.
++ - Keep the test_expect_* function call and test title on
++ the same line.
- Take test_expect_success helper for example, write it like:
+ For example, with test_expect_success, write it like:
2: 9c2c2b5f0574 = 2: 64bed10be547 doc/diff-options: improve wording of the log.diffMerges mention
3: 2636e1bf42ad = 3: fd8544c26690 git-jump: admit to passing merge mode args to ls-files
4: 5fa09b64efaf = 4: 42ee0a9b914a doc/gitk: s/sticked/stuck/
5: 530abe377ad2 = 5: 23840e0368f1 t/README: fix multi-prerequisite example
Documentation/SubmittingPatches | 10 +++++-----
Documentation/config/transfer.txt | 2 +-
Documentation/diff-options.txt | 2 +-
Documentation/git-branch.txt | 2 +-
Documentation/git-range-diff.txt | 2 +-
Documentation/git.txt | 6 +++---
Documentation/gitattributes.txt | 4 ++--
Documentation/giteveryday.txt | 2 +-
contrib/README | 4 ++--
fsmonitor--daemon.h | 2 +-
strbuf.h | 8 ++++----
t/README | 31 +++++++++++++++----------------
12 files changed, 37 insertions(+), 38 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 973d7a81d449..1259549cd488 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -393,8 +393,8 @@ mailing list{security-ml}, instead of the public mailing list.
Learn to use format-patch and send-email if possible. These commands
are optimized for the workflow of sending patches, avoiding many ways
-your existing e-mail client that is optimized for "multipart/*" mime
-type e-mails to corrupt and render your patches unusable.
+your existing e-mail client (often optimized for "multipart/*" MIME
+type e-mails) might render your patches unusable.
People on the Git mailing list need to be able to read and
comment on the changes you are submitting. It is important for
@@ -515,8 +515,8 @@ repositories.
git://git.ozlabs.org/~paulus/gitk
- Those who are interested in improve gitk can volunteer to help Paul
- in maintaining it cf. <YntxL/fTplFm8lr6@cleo>.
+ Those who are interested in improving gitk can volunteer to help Paul
+ maintain it, cf. <YntxL/fTplFm8lr6@cleo>.
- `po/` comes from the localization coordinator, Jiang Xin:
@@ -556,7 +556,7 @@ help you find out who they are.
In any time between the (2)-(3) cycle, the maintainer may pick it up
from the list and queue it to `seen`, in order to make it easier for
-people play with it without having to pick up and apply the patch to
+people to play with it without having to pick up and apply the patch to
their trees themselves.
[[patch-status]]
diff --git a/Documentation/config/transfer.txt b/Documentation/config/transfer.txt
index c3ac767d1e4d..1cbf477e5cfb 100644
--- a/Documentation/config/transfer.txt
+++ b/Documentation/config/transfer.txt
@@ -21,7 +21,7 @@ exposure, e.g. because:
system.
* The git programs will pass the full URL to one another as arguments
on the command-line, meaning the credentials will be exposed to other
- users on OS's or systems that allow other users to see the full
+ unprivileged users on systems that allow them to see the full
process list of other users. On linux the "hidepid" setting
documented in procfs(5) allows for configuring this behavior.
+
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 35fae7c87c8a..ee256ec077be 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -301,7 +301,7 @@ ifndef::git-format-patch[]
-z::
ifdef::git-log[]
- Separate the commits with NULs instead of with new newlines.
+ Separate the commits with NULs instead of newlines.
+
Also, when `--raw` or `--numstat` has been given, do not munge
pathnames and use NULs as output field terminators.
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index d207da9101a5..4395aa935438 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -324,7 +324,7 @@ superproject's "origin/main", but tracks the submodule's "origin/main".
multiple times, in which case the last key becomes the primary
key. The keys supported are the same as those in `git
for-each-ref`. Sort order defaults to the value configured for the
- `branch.sort` variable if exists, or to sorting based on the
+ `branch.sort` variable if it exists, or to sorting based on the
full refname (including `refs/...` prefix). This lists
detached HEAD (if present) first, then local branches and
finally remote-tracking branches. See linkgit:git-config[1].
diff --git a/Documentation/git-range-diff.txt b/Documentation/git-range-diff.txt
index 0b393715d707..6c728dbe44b2 100644
--- a/Documentation/git-range-diff.txt
+++ b/Documentation/git-range-diff.txt
@@ -166,7 +166,7 @@ A typical output of `git range-diff` would look like this:
In this example, there are 3 old and 3 new commits, where the developer
removed the 3rd, added a new one before the first two, and modified the
-commit message of the 2nd commit as well its diff.
+commit message of the 2nd commit as well as its diff.
When the output goes to a terminal, it is color-coded by default, just
like regular `git diff`'s output. In addition, the first line (adding a
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 11228956cd5e..9aeabde26200 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -96,9 +96,9 @@ foo.bar= ...`) sets `foo.bar` to the empty string which `git config
to avoid ambiguity with `<name>` containing one.
+
This is useful for cases where you want to pass transitory
-configuration options to git, but are doing so on OS's where
-other processes might be able to read your cmdline
-(e.g. `/proc/self/cmdline`), but not your environ
+configuration options to git, but are doing so on operating systems
+where other processes might be able to read your command line
+(e.g. `/proc/self/cmdline`), but not your environment
(e.g. `/proc/self/environ`). That behavior is the default on
Linux, but may not be on your system.
+
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 6deb89a29677..8c1793c14880 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -1151,8 +1151,8 @@ will be stored via placeholder `%P`.
^^^^^^^^^^^^^^^^^^^^^^
This attribute controls the length of conflict markers left in
-the work tree file during a conflicted merge. Only setting to
-the value to a positive integer has any meaningful effect.
+the work tree file during a conflicted merge. Only a positive
+integer has a meaningful effect.
For example, this line in `.gitattributes` can be used to tell the merge
machinery to leave much longer (instead of the usual 7-character-long)
diff --git a/Documentation/giteveryday.txt b/Documentation/giteveryday.txt
index faba2ef0881c..f74a33fb35b9 100644
--- a/Documentation/giteveryday.txt
+++ b/Documentation/giteveryday.txt
@@ -229,7 +229,7 @@ without a formal "merging". Or longhand +
git am -3 -k`
An alternate participant submission mechanism is using the
-`git request-pull` or pull-request mechanisms (e.g as used on
+`git request-pull` or pull-request mechanisms (e.g. as used on
GitHub (www.github.com) to notify your upstream of your
contribution.
diff --git a/contrib/README b/contrib/README
index 05f291c1f1d3..21d3d0e7dee4 100644
--- a/contrib/README
+++ b/contrib/README
@@ -23,7 +23,7 @@ This is the same way as how I have been treating gitk, and to a
lesser degree various foreign SCM interfaces, so you know the
drill.
-I expect that things that start their life in the contrib/ area
+I expect things that start their life in the contrib/ area
to graduate out of contrib/ once they mature, either by becoming
projects on their own, or moving to the toplevel directory. On
the other hand, I expect I'll be proposing removal of disused
@@ -31,7 +31,7 @@ and inactive ones from time to time.
If you have new things to add to this area, please first propose
it on the git mailing list, and after a list discussion proves
-there are some general interests (it does not have to be a
+there is general interest (it does not have to be a
list-wide consensus for a tool targeted to a relatively narrow
audience -- for example I do not work with projects whose
upstream is svn, so I have no use for git-svn myself, but it is
diff --git a/fsmonitor--daemon.h b/fsmonitor--daemon.h
index 70d776c54f6d..673f80d2aad0 100644
--- a/fsmonitor--daemon.h
+++ b/fsmonitor--daemon.h
@@ -99,7 +99,7 @@ struct fsmonitor_daemon_state {
* to only mean an external GITDIR referenced by a ".git" file.
*
* The platform FS event backends will receive watch-specific
- * relative paths (except for those OS's that always emit absolute
+ * relative paths (except for those OSes that always emit absolute
* paths). We use the following enum and routines to classify each
* path so that we know how to handle it. There is a slight asymmetry
* here because ".git/" is inside the working directory and the
diff --git a/strbuf.h b/strbuf.h
index fd43c46433a4..e959caca876a 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -12,9 +12,9 @@
struct string_list;
/**
- * strbuf's are meant to be used with all the usual C string and memory
+ * strbufs are meant to be used with all the usual C string and memory
* APIs. Given that the length of the buffer is known, it's often better to
- * use the mem* functions than a str* one (memchr vs. strchr e.g.).
+ * use the mem* functions than a str* one (e.g., memchr vs. strchr).
* Though, one has to be careful about the fact that str* functions often
* stop on NULs and that strbufs may have embedded NULs.
*
@@ -24,7 +24,7 @@ struct string_list;
* strbufs have some invariants that are very important to keep in mind:
*
* - The `buf` member is never NULL, so it can be used in any usual C
- * string operations safely. strbuf's _have_ to be initialized either by
+ * string operations safely. strbufs _have_ to be initialized either by
* `strbuf_init()` or by `= STRBUF_INIT` before the invariants, though.
*
* Do *not* assume anything on what `buf` really is (e.g. if it is
@@ -37,7 +37,7 @@ struct string_list;
*
* - The `buf` member is a byte array that has at least `len + 1` bytes
* allocated. The extra byte is used to store a `'\0'`, allowing the
- * `buf` member to be a valid C-string. Every strbuf function ensure this
+ * `buf` member to be a valid C-string. All strbuf functions ensure this
* invariant is preserved.
*
* NOTE: It is OK to "play" with the buffer directly if you work it this
diff --git a/t/README b/t/README
index 61080859899b..2ef89785f831 100644
--- a/t/README
+++ b/t/README
@@ -262,8 +262,8 @@ The argument for --run, <test-selector>, is a list of description
substrings or globs or individual test numbers or ranges with an
optional negation prefix (of '!') that define what tests in a test
suite to include (or exclude, if negated) in the run. A range is two
-numbers separated with a dash and matches a range of tests with both
-ends been included. You may omit the first or the second number to
+numbers separated with a dash and specifies an inclusive range of tests
+to run. You may omit the first or the second number to
mean "from the first test" or "up to the very last test" respectively.
The argument to --run is split on commas into separate strings,
@@ -274,10 +274,10 @@ text that you want to match includes a comma, use the glob character
on all tests that match either the glob *rebase* or the glob
*merge?cherry-pick*.
-If --run starts with an unprefixed number or range the initial
-set of tests to run is empty. If the first item starts with '!'
+If --run starts with an unprefixed number or range, the initial
+set of tests to run is empty. If the first item starts with '!',
all the tests are added to the initial set. After initial set is
-determined every test number or range is added or excluded from
+determined, every test number or range is added or excluded from
the set one by one, from left to right.
For example, to run only tests up to a specific test (21), one
@@ -579,11 +579,11 @@ This test harness library does the following things:
Recommended style
-----------------
-Here are some recommented styles when writing test case.
- - Keep test title the same line with test helper function itself.
+ - Keep the test_expect_* function call and test title on
+ the same line.
- Take test_expect_success helper for example, write it like:
+ For example, with test_expect_success, write it like:
test_expect_success 'test title' '
... test body ...
@@ -595,10 +595,9 @@ Here are some recommented styles when writing test case.
'test title' \
'... test body ...'
+ - End the line with an opening single quote.
- - End the line with a single quote.
-
- - Indent the body of here-document, and use "<<-" instead of "<<"
+ - Indent here-document bodies, and use "<<-" instead of "<<"
to strip leading TABs used for indentation:
test_expect_success 'test something' '
@@ -624,7 +623,7 @@ Here are some recommented styles when writing test case.
'
- Quote or escape the EOF delimiter that begins a here-document if
- there is no parameter and other expansion in it, to signal readers
+ there is no parameter or other expansion in it, to signal readers
that they can skim it more casually:
cmd <<-\EOF
@@ -638,7 +637,7 @@ Do's & don'ts
Here are a few examples of things you probably should and shouldn't do
when writing tests.
-Here are the "do's:"
+The "do's:"
- Put all code inside test_expect_success and other assertions.
@@ -1237,8 +1236,8 @@ and it knows that the object ID of an empty tree is a certain
because the things the very basic core test tries to achieve is
to serve as a basis for people who are changing the Git internals
drastically. For these people, after making certain changes,
-not seeing failures from the basic test _is_ a failure. And
-such drastic changes to the core Git that even changes these
+not seeing failures from the basic test _is_ a failure. Any
+Git core changes so drastic that they change even these
otherwise supposedly stable object IDs should be accompanied by
an update to t0000-basic.sh.
@@ -1248,7 +1247,7 @@ knowledge of the core Git internals. If all the test scripts
hardcoded the object IDs like t0000-basic.sh does, that defeats
the purpose of t0000-basic.sh, which is to isolate that level of
validation in one place. Your test also ends up needing
-updating when such a change to the internal happens, so do _not_
+an update whenever the internals change, so do _not_
do it and leave the low level of validation to t0000-basic.sh.
Test coverage
base-commit: d0e8084c65cbf949038ae4cc344ac2c2efd77415
--
2.42.0
^ permalink raw reply related
* [PATCH v2 3/5] git-jump: admit to passing merge mode args to ls-files
From: Štěpán Němec @ 2023-10-05 9:00 UTC (permalink / raw)
To: git
In-Reply-To: <20231005090055.3097783-1-stepnem@smrk.net>
There's even an example of such usage in the README.
Fixes: 67ba13e5a4b2 ("git-jump: pass "merge" arguments to ls-files")
Signed-off-by: Štěpán Němec <stepnem@smrk.net>
---
contrib/git-jump/git-jump | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/git-jump/git-jump b/contrib/git-jump/git-jump
index 40c4b0d11107..47e0c557e63f 100755
--- a/contrib/git-jump/git-jump
+++ b/contrib/git-jump/git-jump
@@ -9,7 +9,7 @@ The <mode> parameter is one of:
diff: elements are diff hunks. Arguments are given to diff.
-merge: elements are merge conflicts. Arguments are ignored.
+merge: elements are merge conflicts. Arguments are given to ls-files -u.
grep: elements are grep hits. Arguments are given to git grep or, if
configured, to the command in `jump.grepCmd`.
--
2.42.0
^ permalink raw reply related
* Re: [PATCH v2 3/3] builtin/repack.c: implement support for `--max-cruft-size`
From: Patrick Steinhardt @ 2023-10-05 12:08 UTC (permalink / raw)
To: Taylor Blau; +Cc: git, Jeff King, Junio C Hamano, Eric Sunshine
In-Reply-To: <e7beb2060dad648ec5c3fa8984e432ee243ae012.1696293862.git.me@ttaylorr.com>
[-- Attachment #1: Type: text/plain, Size: 4113 bytes --]
On Mon, Oct 02, 2023 at 08:44:32PM -0400, Taylor Blau wrote:
[snip]
> diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
> index 90806fd26a..fa0541b416 100644
> --- a/Documentation/git-gc.txt
> +++ b/Documentation/git-gc.txt
> @@ -59,6 +59,13 @@ be performed as well.
> cruft pack instead of storing them as loose objects. `--cruft`
> is on by default.
>
> +--max-cruft-size=<n>::
> + When packing unreachable objects into a cruft pack, limit the
> + size of new cruft packs to be at most `<n>`. Overrides any
We should probably mention the unit here, which is bytes.
[snip]
> @@ -806,6 +846,72 @@ static void remove_redundant_bitmaps(struct string_list *include,
> strbuf_release(&path);
> }
>
> +static int existing_cruft_pack_cmp(const void *va, const void *vb)
> +{
> + struct packed_git *a = *(struct packed_git **)va;
> + struct packed_git *b = *(struct packed_git **)vb;
> +
> + if (a->pack_size < b->pack_size)
> + return -1;
> + if (a->pack_size > b->pack_size)
> + return 1;
> + return 0;
> +}
> +
> +static void collapse_small_cruft_packs(FILE *in, size_t max_size,
> + struct existing_packs *existing)
> +{
> + struct packed_git **existing_cruft, *p;
> + struct strbuf buf = STRBUF_INIT;
> + size_t total_size = 0;
> + size_t existing_cruft_nr = 0;
> + size_t i;
> +
> + ALLOC_ARRAY(existing_cruft, existing->cruft_packs.nr);
> +
> + for (p = get_all_packs(the_repository); p; p = p->next) {
> + if (!(p->is_cruft && p->pack_local))
> + continue;
> +
> + strbuf_reset(&buf);
> + strbuf_addstr(&buf, pack_basename(p));
> + strbuf_strip_suffix(&buf, ".pack");
> +
> + if (!string_list_has_string(&existing->cruft_packs, buf.buf))
> + continue;
> +
> + if (existing_cruft_nr >= existing->cruft_packs.nr)
> + BUG("too many cruft packs (found %"PRIuMAX", but knew "
> + "of %"PRIuMAX")",
> + (uintmax_t)existing_cruft_nr + 1,
> + (uintmax_t)existing->cruft_packs.nr);
> + existing_cruft[existing_cruft_nr++] = p;
> + }
> +
> + QSORT(existing_cruft, existing_cruft_nr, existing_cruft_pack_cmp);
> +
> + for (i = 0; i < existing_cruft_nr; i++) {
> + size_t proposed;
> +
> + p = existing_cruft[i];
> + proposed = st_add(total_size, p->pack_size);
> +
> + if (proposed <= max_size) {
> + total_size = proposed;
> + fprintf(in, "-%s\n", pack_basename(p));
> + } else {
> + retain_cruft_pack(existing, p);
> + fprintf(in, "%s\n", pack_basename(p));
> + }
> + }
> +
> + for (i = 0; i < existing->non_kept_packs.nr; i++)
> + fprintf(in, "-%s.pack\n",
> + existing->non_kept_packs.items[i].string);
As far as I can see, the non-kept packs are passed to
git-pack-objects(1) both in the cases where we do collapse small cruft
packs and where we don't. Is there any particular reason why we handle
those in both code paths separately instead of merging that logic? Is
the ordering of packfiles important here?
> + strbuf_release(&buf);
> +}
> +
> static int write_cruft_pack(const struct pack_objects_args *args,
> const char *destination,
> const char *pack_prefix,
> @@ -853,10 +959,14 @@ static int write_cruft_pack(const struct pack_objects_args *args,
> in = xfdopen(cmd.in, "w");
> for_each_string_list_item(item, names)
> fprintf(in, "%s-%s.pack\n", pack_prefix, item->string);
> - for_each_string_list_item(item, &existing->non_kept_packs)
> - fprintf(in, "-%s.pack\n", item->string);
> - for_each_string_list_item(item, &existing->cruft_packs)
> - fprintf(in, "-%s.pack\n", item->string);
> + if (args->max_pack_size && !cruft_expiration) {
> + collapse_small_cruft_packs(in, args->max_pack_size, existing);
> + } else {
> + for_each_string_list_item(item, &existing->non_kept_packs)
> + fprintf(in, "-%s.pack\n", item->string);
> + for_each_string_list_item(item, &existing->cruft_packs)
> + fprintf(in, "-%s.pack\n", item->string);
> + }
> for_each_string_list_item(item, &existing->kept_packs)
> fprintf(in, "%s.pack\n", item->string);
> fclose(in);
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] t4014: replace "test -f" with "test_path_is_file"
From: Vinayak Dev @ 2023-10-05 7:11 UTC (permalink / raw)
To: git; +Cc: Vinayak Dev
From: Vinayak Dev <vinayakdev.sci@gmail.com>
Many tests in the codebase use test -[e|f|d].. commands
to check for various conditions. However, the test command
upon failure simply exits with a non-zero exit code(usually 1).
Therefore, replace instances of "test -f" from t/t4014-format-patch.sh
with the function test_path_is_file() defined in t/test-lib-functions.sh
that exits with a debugging-friendly diagnostic message upon failure.
Signed-off-by: Vinayak Dev <vinayakdev.sci@gmail.com>
---
t/t4014-format-patch.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 0a4ab36c3a..5f7d0836d6 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -763,7 +763,7 @@ test_expect_success 'format-patch from a subdirectory (1)' '
false
;;
esac &&
- test -f "$filename"
+ test_path_is_file "$filename"
'
test_expect_success 'format-patch from a subdirectory (2)' '
@@ -782,7 +782,7 @@ test_expect_success 'format-patch from a subdirectory (2)' '
;;
esac &&
basename=$(expr "$filename" : ".*/\(.*\)") &&
- test -f "sub/$basename"
+ test_path_is_file "sub/$basename"
'
test_expect_success 'format-patch from a subdirectory (3)' '
@@ -794,7 +794,7 @@ test_expect_success 'format-patch from a subdirectory (3)' '
git format-patch -1 -o "$TRASH_DIRECTORY"
) &&
basename=$(expr "$filename" : ".*/\(.*\)") &&
- test -f "$basename"
+ test_path_is_file "$basename"
'
test_expect_success 'format-patch --in-reply-to' '
base-commit: d0e8084c65cbf949038ae4cc344ac2c2efd77415
--
2.41.0
^ permalink raw reply related
* Re: [PATCH] doc/cat-file: clarify description regarding various command forms
From: Štěpán Němec @ 2023-10-05 11:20 UTC (permalink / raw)
To: Jeff King; +Cc: git, avarab
In-Reply-To: <20231003200659.GC1562@coredump.intra.peff.net>
On Tue, 3 Oct 2023 16:06:59 -0400
Jeff King wrote:
>> DESCRIPTION
>> -----------
>> -In its first form, the command provides the content or the type of an object in
>> +This command can operate in two modes, depending on whether an option from
>> +the `--batch` family is specified.
>> +
>> +In non-batch mode, the command provides the content or the type of an object in
>> the repository. The type is required unless `-t` or `-p` is used to find the
>> object type, or `-s` is used to find the object size, or `--textconv` or
>> `--filters` is used (which imply type "blob").
>
> The existing text here is already a bit vague, considering the number of
> operations it covers (like "-e", for example, which is not showing "the
> content or the type" at all). But that is not new in your patch, and it
> is maybe even OK to be a bit vague here, and let the OPTIONS section
> cover the specifics.
So how about we just butcher the DESCRIPTION completely; after all, the
information it gives is not quite correct (other than what you already
mentioned, e.g., -e is omitted in the "type not required" part; one is
left to wonder what <format> refers to: you have to go read the OPTIONS
and BATCH OUTPUT sections anyway), and the correct parts only duplicate
information given in the following sections, providing opportunities to
become out of date when the command and its documentation evolve:
Changes (if we agree this is the way to go, I'll also update the --help
output):
synopsis:
- move the (--textconv | --filters) form before --batch, closer
to the other non-batch forms
- cosmetics: swap -t and -s, --filters and --textconv (sort
alphabetically)
description:
- reformulate, omit vague/imprecise information better
provided in the detailed options list
SYNOPSIS
git cat-file <type> <object>
git cat-file (-e | -p) <object>
git cat-file (-s | -t) [--allow-unknown-type] <object>
git cat-file (--filters | --textconv)
[<rev>:<path|tree-ish> | --path=<path|tree-ish> <rev>]
git cat-file (--batch | --batch-check | --batch-command) [--batch-all-objects]
[--buffer] [--follow-symlinks] [--unordered]
[--filters | --textconv] [-Z]
DESCRIPTION
This command can operate in two modes, depending on whether an
option from the --batch family is specified.
In non-batch mode, the command provides information on an object
named on the command line.
In batch mode, arguments are read from standard input.
[That's all for a summary, read the following sections for details.]
>> -In the second form, a list of objects (separated by linefeeds) is provided on
>> +In batch mode, a list of objects (separated by linefeeds) is provided on
>> stdin, and the SHA-1, type, and size of each object is printed on stdout. The
>> output format can be overridden using the optional `<format>` argument. If
>> either `--textconv` or `--filters` was specified, the input is expected to
>
> I think this got a bit inaccurate with "--batch-command", which is a
> whole different mode itself compared to --batch and --batch-check. I
> don't think your patch is really making anything worse, but arguably
> there are three "major modes" here.
This is not obvious to me (the "three major modes" part). AIUI it's
still mainly a batch (read from stdin) vs. non-batch (args on command
line) dichotomy. The details differ (just args vs. command + args), but
so does e.g. -e differ in providing information via exit code rather
than stdout.
(But please note I'm not trying to pose as an expert here: this all
started with me coming to git-cat-file(1) to _learn_ about cat-file
and finding the description more than a little confusing.)
--
Štěpán
^ permalink raw reply
* [PATCH v2 2/5] doc/diff-options: improve wording of the log.diffMerges mention
From: Štěpán Němec @ 2023-10-05 9:00 UTC (permalink / raw)
To: git
In-Reply-To: <20231005090055.3097783-1-stepnem@smrk.net>
Fix the grammar ("which default value is") and reword to match other
similar descriptions (say "configuration variable" instead of
"parameter", link to git-config(1)).
Signed-off-by: Štěpán Němec <stepnem@smrk.net>
---
Documentation/diff-options.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index ee256ec077be..48a5012748dd 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -53,9 +53,9 @@ ifdef::git-log[]
-m:::
This option makes diff output for merge commits to be shown in
the default format. `-m` will produce the output only if `-p`
- is given as well. The default format could be changed using
- `log.diffMerges` configuration parameter, which default value
- is `separate`.
+ is given as well. The default format can be specified using
+ the configuration variable `log.diffMerges` (see
+ linkgit:git-config[1]). It defaults to `separate`.
+
--diff-merges=first-parent:::
--diff-merges=1:::
--
2.42.0
^ permalink raw reply related
* Re: [PATCH v2] builtin/repack.c: avoid making cruft packs preferred
From: Patrick Steinhardt @ 2023-10-05 11:14 UTC (permalink / raw)
To: Taylor Blau; +Cc: git, Jeff King, Junio C Hamano
In-Reply-To: <035393935108d02aaf8927189b05102f4f74f340.1696370003.git.me@ttaylorr.com>
[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]
On Tue, Oct 03, 2023 at 05:54:19PM -0400, Taylor Blau wrote:
[snip]
> @@ -801,6 +814,38 @@ static int write_midx_included_packs(struct string_list *include,
> if (preferred)
> strvec_pushf(&cmd.args, "--preferred-pack=%s",
> pack_basename(preferred));
> + else if (names->nr) {
> + /* The largest pack was repacked, meaning that either
> + * one or two packs exist depending on whether the
> + * repository has a cruft pack or not.
Nit: this comment will grow stale soonish once your patch series lands
that introduces a maximum packfile size for cruft packs as there can be
arbitrarily many cruft packs from thereon.
> + * Select the non-cruft one as preferred to encourage
> + * pack-reuse among packs containing reachable objects
> + * over unreachable ones.
> + *
> + * (Note we could write multiple packs here if
> + * `--max-pack-size` was given, but any one of them
> + * will suffice, so pick the first one.)
> + */
Well, okay, you kind of acknowledge this here.
The rest of this patch series looks good to me and makes sense. I don't
really think that this comment here is worth a reroll.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2023, #01; Mon, 2)
From: Junio C Hamano @ 2023-10-05 10:25 UTC (permalink / raw)
To: Sergey Organov; +Cc: git
In-Reply-To: <871qeay6tz.fsf@osv.gnss.ru>
Sergey Organov <sorganov@gmail.com> writes:
> Just for better understanding: does it mean that *any* addition of
> one-letter option is prohibited from any existing Git command? Cause it
> definitely sounds this way.
No, we just prefer to think twice before giving short-and-sweet
single letter option to a feature that is not proven useful, and
during the discussion it has become rather clear that the proposed
combination of options goes against helping normal Git users by
forcing them to read an aggregated and redundant patch for a merge
when they already see patches for individual commits on the side
branch that was merged.
>> If I have to pick a candidate for "get me diff" that is the most
>> useful among those currently are available, it is "give patches to
>> all single-parent commit, and show tricky conflict resolution part
>> only for merge commits".
>
> I'm afraid you need to pick a candidate that will be natural for '-d',
> not just most useful output for your workflows, whatever it happens to
> be.
Literal match to word "diff" does not necessarily mean it is useful,
and short-and-sweet single-letter option name is primarily about
letting users reach useful features with minimum typing [*1*], so you
cannot avoid "most useful" being a large part of the equation.
I am wondering if we can have a generalized "personal command option
alias" mechanism implemented. Then you can give '-[a-z]'[*2*] to
whatever combination you like without affecting others by only
futzing with your $HOME/.gitconfig file.
[Footnote]
*1* ...or if we are mimicking options of an existing external
commmand, we need to match them, but in this case it does not
apply.
*2* If we were to do this for real, it may make sense to carve out
option namespace so that end-user aliases cannot overlap with
official set of options. For example, if you can never get a
string that matches "^-![a-z]$" recognised as an official
command line option by our parsers, then '-!' followed by a
single letter would be a good candidate for our "personal
command option alias" to work with, and '-!d' might be
something you want to use your personal option alias, without
having to worry about a later version of Git using the option
officially for something else.
Another thing that need to be considered when designing such a
"command option alias" feature is how to express the set of
commands an alias applies to, as some underlying commands may
share the same set of options. For example, having to say
optionAlias.bisect.1 = --first-parent
optionAlias.blame.1 = --first-parent
optionAlias.log.1 = --first-parent
is a bit too cumbersome to allow me to say "git bisect -!1",
"git blame -!1", and "git log -!1". But I am not offhand sure
if a much simpler
optionAlias.1 = --first-parent
is sufficient. "git commit -!1" would expand into "git commit
--first-parent" and would give you an error with the usage
message, which may not be too bad. I dunno.
^ permalink raw reply
* Re: [PATCH v2 2/3] builtin/repack.c: parse `--max-pack-size` with OPT_MAGNITUDE
From: Patrick Steinhardt @ 2023-10-05 11:31 UTC (permalink / raw)
To: Taylor Blau; +Cc: git, Jeff King, Junio C Hamano, Eric Sunshine
In-Reply-To: <9ec999882d790aa770aba8c0916b9260661af9be.1696293862.git.me@ttaylorr.com>
[-- Attachment #1: Type: text/plain, Size: 2434 bytes --]
On Mon, Oct 02, 2023 at 08:44:29PM -0400, Taylor Blau wrote:
> The repack builtin takes a `--max-pack-size` command-line argument which
> it uses to feed into any of the pack-objects children that it may spawn
> when generating a new pack.
>
> This option is parsed with OPT_STRING, meaning that we'll accept
> anything as input, punting on more fine-grained validation until we get
> down into pack-objects.
>
> This is fine, but it's wasteful to spend an entire sub-process just to
> figure out that one of its option is bogus. Instead, parse the value of
> `--max-pack-size` with OPT_MAGNITUDE in 'git repack', and then pass the
> knonw-good result down to pack-objects.
Tiny nit: s/knonw/known.
Other than that this patch looks good to me.
Patrick
> Suggested-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Taylor Blau <me@ttaylorr.com>
> ---
> builtin/repack.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/builtin/repack.c b/builtin/repack.c
> index 529e13120d..8a5bbb9cba 100644
> --- a/builtin/repack.c
> +++ b/builtin/repack.c
> @@ -51,7 +51,7 @@ struct pack_objects_args {
> const char *window_memory;
> const char *depth;
> const char *threads;
> - const char *max_pack_size;
> + unsigned long max_pack_size;
> int no_reuse_delta;
> int no_reuse_object;
> int quiet;
> @@ -242,7 +242,7 @@ static void prepare_pack_objects(struct child_process *cmd,
> if (args->threads)
> strvec_pushf(&cmd->args, "--threads=%s", args->threads);
> if (args->max_pack_size)
> - strvec_pushf(&cmd->args, "--max-pack-size=%s", args->max_pack_size);
> + strvec_pushf(&cmd->args, "--max-pack-size=%lu", args->max_pack_size);
> if (args->no_reuse_delta)
> strvec_pushf(&cmd->args, "--no-reuse-delta");
> if (args->no_reuse_object)
> @@ -946,7 +946,7 @@ int cmd_repack(int argc, const char **argv, const char *prefix)
> N_("limits the maximum delta depth")),
> OPT_STRING(0, "threads", &po_args.threads, N_("n"),
> N_("limits the maximum number of threads")),
> - OPT_STRING(0, "max-pack-size", &po_args.max_pack_size, N_("bytes"),
> + OPT_MAGNITUDE(0, "max-pack-size", &po_args.max_pack_size,
> N_("maximum size of each packfile")),
> OPT_BOOL(0, "pack-kept-objects", &pack_kept_objects,
> N_("repack objects in packs marked with .keep")),
> --
> 2.42.0.310.g9604b54f73.dirty
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v2 4/5] doc/gitk: s/sticked/stuck/
From: Štěpán Němec @ 2023-10-05 9:00 UTC (permalink / raw)
To: git
In-Reply-To: <20231005090055.3097783-1-stepnem@smrk.net>
The terminology was changed in b0d12fc9b23a (Use the word 'stuck'
instead of 'sticked').
Signed-off-by: Štěpán Němec <stepnem@smrk.net>
---
Documentation/gitk.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index d50e9ed10e04..c2213bb77b38 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -26,7 +26,7 @@ changes each commit introduces are shown. Finally, it supports some
gitk-specific options.
gitk generally only understands options with arguments in the
-'sticked' form (see linkgit:gitcli[7]) due to limitations in the
+'stuck' form (see linkgit:gitcli[7]) due to limitations in the
command-line parser.
rev-list options and arguments
--
2.42.0
^ permalink raw reply related
* [PATCH] merge-ort: initialize repo in index state
From: John Cai via GitGitGadget @ 2023-10-05 15:22 UTC (permalink / raw)
To: git; +Cc: John Cai, John Cai
From: John Cai <johncai86@gmail.com>
initialize_attr_index() does not initialize the repo member of
attr_index. Starting in 44451a2e5e (attr: teach "--attr-source=<tree>"
global option to "git", 2023-05-06), this became a problem because
istate->repo gets passed down the call chain starting in
git_check_attr(). This gets passed all the way down to
replace_refs_enabled(), which segfaults when accessing r->gitdir.
Fix this by initializing the repository in the index state.
Signed-off-by: John Cai <johncai86@gmail.com>
Helped-by: Christian Couder <christian.couder@gmail.com>
---
merge-ort: initialize repo in index state
initialize_attr_index() does not initialize the repo member of
attr_index. Starting in 44451a2e5e (attr: teach "--attr-source=" global
option to "git", 2023-05-06), this became a problem because istate->repo
gets passed down the call chain starting in git_check_attr(). This gets
passed all the way down to replace_refs_enabled(), which segfaults when
accessing r->gitdir.
Fix this by initializing the repository in the index state.
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1583%2Fjohn-cai%2Fjc%2Fpopulate-repo-when-init-attr-index-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1583/john-cai/jc/populate-repo-when-init-attr-index-v1
Pull-Request: https://github.com/git/git/pull/1583
merge-ort.c | 1 +
t/t4300-merge-tree.sh | 20 ++++++++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/merge-ort.c b/merge-ort.c
index 7857ce9fbd1..172dc7d497d 100644
--- a/merge-ort.c
+++ b/merge-ort.c
@@ -1902,6 +1902,7 @@ static void initialize_attr_index(struct merge_options *opt)
struct index_state *attr_index = &opt->priv->attr_index;
struct cache_entry *ce;
+ attr_index->repo = the_repository;
attr_index->initialized = 1;
if (!opt->renormalize)
diff --git a/t/t4300-merge-tree.sh b/t/t4300-merge-tree.sh
index 57c4f26e461..254453fff9c 100755
--- a/t/t4300-merge-tree.sh
+++ b/t/t4300-merge-tree.sh
@@ -86,6 +86,26 @@ EXPECTED
test_cmp expected actual
'
+test_expect_success '3-way merge with --attr-source' '
+ test_when_finished rm -rf 3-way &&
+ git init 3-way &&
+ (
+ cd 3-way &&
+ test_commit initial file1 foo &&
+ base=$(git rev-parse HEAD) &&
+ git checkout -b brancha &&
+ echo bar>>file1 &&
+ git commit -am "adding bar" &&
+ source=$(git rev-parse HEAD) &&
+ echo baz>>file1 &&
+ git commit -am "adding baz" &&
+ merge=$(git rev-parse HEAD) &&
+ test_must_fail git --attr-source=HEAD merge-tree -z --write-tree \
+ --merge-base "$base" --end-of-options "$source" "$merge" >out &&
+ grep "Merge conflict in file1" out
+ )
+'
+
test_expect_success 'file change A, B (same)' '
git reset --hard initial &&
test_commit "change-a-b-same-A" "initial-file" "AAA" &&
base-commit: 493f4622739e9b64f24b465b21aa85870dd9dc09
--
gitgitgadget
^ permalink raw reply related
* [PATCH] t4014: replace "test -f" with "test_path_is_file"
From: Vinayak Dev @ 2023-10-05 8:17 UTC (permalink / raw)
To: gitster; +Cc: git, Vinayak Dev
From: Vinayak Dev <vinayakdev.sci@gmail.com>
Many tests in the codebase use test -[e|f|d].. commands
to check for various conditions. However, the test command
upon failure simply exits with a non-zero exit code(usually 1).
Therefore, replace instances of "test -f" from t/t4014-format-patch.sh
with the function test_path_is_file() defined in t/test-lib-functions.sh
that exits with a debugging-friendly diagnostic message upon failure.
Signed-off-by: Vinayak Dev <vinayakdev.sci@gmail.com>
---
t/t4014-format-patch.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 0a4ab36c3a..5f7d0836d6 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -763,7 +763,7 @@ test_expect_success 'format-patch from a subdirectory (1)' '
false
;;
esac &&
- test -f "$filename"
+ test_path_is_file "$filename"
'
test_expect_success 'format-patch from a subdirectory (2)' '
@@ -782,7 +782,7 @@ test_expect_success 'format-patch from a subdirectory (2)' '
;;
esac &&
basename=$(expr "$filename" : ".*/\(.*\)") &&
- test -f "sub/$basename"
+ test_path_is_file "sub/$basename"
'
test_expect_success 'format-patch from a subdirectory (3)' '
@@ -794,7 +794,7 @@ test_expect_success 'format-patch from a subdirectory (3)' '
git format-patch -1 -o "$TRASH_DIRECTORY"
) &&
basename=$(expr "$filename" : ".*/\(.*\)") &&
- test -f "$basename"
+ test_path_is_file "$basename"
'
test_expect_success 'format-patch --in-reply-to' '
base-commit: d0e8084c65cbf949038ae4cc344ac2c2efd77415
--
2.42.0
^ permalink raw reply related
* Wording "fetch" to change to "pull" or "merge" ti suggest the proper action to take when pull fails?
From: MDW @ 2023-10-05 14:31 UTC (permalink / raw)
To: git
Hello
I noticed that the working upon a rejected pull request is "fetch
first".
However, AFAIK fetching will not help with the pull.
So I suggest to change that wording.
Example:
```bash
$ git push
To ssh://git.exemple.com/user/repo.git
! [rejected] main -> main (fetch first)
error: failed to push some refs to 'ssh://git.exemple.com/user/repo.git'
```
Kind regards
Mario
--
GDPR: Personal data is provided only for this communication.
I refuse unsollicited subscriptions to mailing lists
and I refuse commercial use of this personal data.
^ permalink raw reply
* js/ci-coverity, was Re: What's cooking in git.git (Oct 2023, #02; Wed, 4)
From: Jeff King @ 2023-10-05 17:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <xmqqpm1ulzoh.fsf@gitster.g>
On Wed, Oct 04, 2023 at 04:45:34PM -0700, Junio C Hamano wrote:
> * js/ci-coverity (2023-09-25) 7 commits
> - SQUASH???
> - coverity: detect and report when the token or project is incorrect
> - coverity: allow running on macOS
> - coverity: support building on Windows
> - coverity: allow overriding the Coverity project
> - coverity: cache the Coverity Build Tool
> - ci: add a GitHub workflow to submit Coverity scans
>
> GitHub CI workflow has learned to trigger Coverity check.
>
> Looking good.
> source: <pull.1588.v2.git.1695642662.gitgitgadget@gmail.com>
I think that has been sitting at "Looking good" for a few iterations.
IMHO it is ready to progress, with the SQUASH applied on the final
patch.
-Peff
^ 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