* Re: rebase invoking pre-commit
From: Junio C Hamano @ 2023-12-26 16:33 UTC (permalink / raw)
To: Phillip Wood; +Cc: Sean Allred, Git List
In-Reply-To: <bf1ce173-50d7-405f-88c1-7edb7ec5a55a@gmail.com>
Phillip Wood <phillip.wood123@gmail.com> writes:
> On 21/12/2023 20:58, Sean Allred wrote:
>> Is there a current reason why pre-commit shouldn't be invoked during
>> rebase, or is this just waiting for a reviewable patch?
>
> The reason that we don't run the pre-commit hook is that the commit
> being rebased may have been created with "git commit --no-verify" and
> so running the pre-commit hook would stop it from being rebased - see
> e637122ef2 (rebase -m: do not trigger pre-commit verification,
> 2008-03-16).
Very true. And back then we didn't have "rebase -x" mechanism but
these days, anybody who is interested in running a command between
each step can use it to run any validation script, not the one with
fixed name called "hooks", so I'd place this to fairly low priority.
Thanks.
^ permalink raw reply
* [PATCH] fast-import: use mem_pool_calloc()
From: René Scharfe @ 2023-12-26 8:17 UTC (permalink / raw)
To: Git List
Use mem_pool_calloc() to get a zeroed buffer instead of zeroing it
ourselves. This makes the code clearer and less repetitive.
Signed-off-by: René Scharfe <l.s.r@web.de>
---
builtin/fast-import.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/builtin/fast-import.c b/builtin/fast-import.c
index 444f41cf8c..92eda20683 100644
--- a/builtin/fast-import.c
+++ b/builtin/fast-import.c
@@ -2809,8 +2809,7 @@ static void parse_new_tag(const char *arg)
enum object_type type;
const char *v;
- t = mem_pool_alloc(&fi_mem_pool, sizeof(struct tag));
- memset(t, 0, sizeof(struct tag));
+ t = mem_pool_calloc(&fi_mem_pool, 1, sizeof(struct tag));
t->name = mem_pool_strdup(&fi_mem_pool, arg);
if (last_tag)
last_tag->next_tag = t;
--
2.43.0
^ permalink raw reply related
* subtree split after deleting and re-running git-subtree add, fails with "fatal: cache for XXX already exists!"
From: Eli Schwartz @ 2023-12-26 0:58 UTC (permalink / raw)
To: git
Originally reported in https://github.com/eli-schwartz/aurpublish/issues/30
Given a subtree that gets messed up, some users might naturally
gravitate towards deleting the subtree, and recreating it again via
`git subtree add`. This can result in a difficult to solve situation.
Any attempt to split it seems to produce failure.
Reproducer:
git init testme && cd testme
mkdir foo
touch foo/bar
git add foo/bar
git commit -m ...
split_commit=$(git subtree split -P foo --rejoin)
# Added dir 'foo'
echo "${split_commit}"
# 42517e4b9fe310a64be2a777ef08c91bd582b385
git rm -r foo
git commit -m deleted
git subtree add --prefix foo "${split_commit}"
# Added dir 'foo'
git subtree split -P foo --rejoin
# fatal: cache for 42517e4b9fe310a64be2a777ef08c91bd582b385 already exists!
The interesting thing here is that in git.git commit
d2f0f819547de35ffc923fc963f806f1656eb2ca:
"subtree: more consistent error propagation"
the git-subtree program got a bit of a facelift w.r.t. proper error
checking.
In particular, in find_existing_splits, `cache_set $sub $sub` will fail
here. But before that commit, the die did not propagate. It turns out
that actually ignoring this was "fine" and resulted in successfully
splitting (while also printing a "warning": back then, the word "fatal"
did not appear anywhere in the message; now it does).
As a quick hack, this seems to restore things:
```
@@ -499,7 +505,7 @@ find_existing_splits () {
then
debug " Prior: $main -> $sub"
cache_set $main $sub
- cache_set $sub $sub
+ (cache_set $sub $sub) || true
try_remove_previous "$main"
try_remove_previous "$sub"
fi
```
So:
$ PATH=/home/eschwartz/git/git/contrib/subtree/:$PATH git subtree.sh
split -P foo
fatal: cache for 5f662c163282b3657604c789ae639a98c211d5a7 already exists!
5f662c163282b3657604c789ae639a98c211d5a7
$ echo $?
0
```
Thoughts on fixing this properly? I haven't looked at the implementation
before so maybe there's a better algorithm for handling this. I suppose
I could submit a patch that adds a `_cache_set` for cases where you want
to allow duplicates, and use it here.
--
Eli Schwartz
^ permalink raw reply
* [PATCH 2/2] doc: enforce placeholders in documentation
From: Jean-Noël Avila via GitGitGadget @ 2023-12-25 21:21 UTC (permalink / raw)
To: git; +Cc: Jean-Noël Avila, Jean-Noël Avila
In-Reply-To: <pull.1626.git.1703539287.gitgitgadget@gmail.com>
From: =?UTF-8?q?Jean-No=C3=ABl=20Avila?= <jn.avila@free.fr>
Any string that is not meant to be used verbatim in the documentation
should be marked as a placeholder.
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
---
Documentation/diff-options.txt | 2 +-
Documentation/git-config.txt | 8 ++++----
Documentation/git-daemon.txt | 4 ++--
Documentation/git-difftool.txt | 2 +-
Documentation/git.txt | 2 +-
5 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 53ec3c9a347..aaaff0d46f0 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -299,7 +299,7 @@ and accumulating child directory counts in the parent directories:
Synonym for --dirstat=cumulative
--dirstat-by-file[=<param1,param2>...]::
- Synonym for --dirstat=files,param1,param2...
+ Synonym for --dirstat=files,<param1>,<param2>...
--summary::
Output a condensed summary of extended header information
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index b1caac887ae..dff39093b5e 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -103,11 +103,11 @@ OPTIONS
names are not.
--get-urlmatch <name> <URL>::
- When given a two-part name section.key, the value for
- section.<URL>.key whose <URL> part matches the best to the
+ When given a two-part <name> as <section>.<key>, the value for
+ <section>.<URL>.<key> whose <URL> part matches the best to the
given URL is returned (if no such key exists, the value for
- section.key is used as a fallback). When given just the
- section as name, do so for all the keys in the section and
+ <section>.<key> is used as a fallback). When given just the
+ <section> as name, do so for all the keys in the section and
list them. Returns error code 1 if no value is found.
--global::
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index 6ab792228a1..ede7b935d64 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -141,8 +141,8 @@ otherwise `stderr`.
specified with no parameter, a request to
git://host/{tilde}alice/foo is taken as a request to access
'foo' repository in the home directory of user `alice`.
- If `--user-path=path` is specified, the same request is
- taken as a request to access `path/foo` repository in
+ If `--user-path=<path>` is specified, the same request is
+ taken as a request to access `<path>/foo` repository in
the home directory of user `alice`.
--verbose::
diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
index 50cb080085e..c05f97aca96 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -90,7 +90,7 @@ instead. `--no-symlinks` is the default on Windows.
--extcmd=<command>::
Specify a custom command for viewing diffs.
'git-difftool' ignores the configured defaults and runs
- `$command $LOCAL $REMOTE` when this option is specified.
+ `<command> $LOCAL $REMOTE` when this option is specified.
Additionally, `$BASE` is set in the environment.
-g::
diff --git a/Documentation/git.txt b/Documentation/git.txt
index d51473a3274..8d565142024 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -202,7 +202,7 @@ If you just want to run git as if it was started in `<path>` then use
Do not perform optional operations that require locks. This is
equivalent to setting the `GIT_OPTIONAL_LOCKS` to `0`.
---list-cmds=group[,group...]::
+--list-cmds=<group>[,<group>...]::
List commands by group. This is an internal/experimental
option and may change or be removed in the future. Supported
groups are: builtins, parseopt (builtin commands that use
--
gitgitgadget
^ permalink raw reply related
* [PATCH 1/2] doc: enforce dashes in placeholders
From: Jean-Noël Avila via GitGitGadget @ 2023-12-25 21:21 UTC (permalink / raw)
To: git; +Cc: Jean-Noël Avila, Jean-Noël Avila
In-Reply-To: <pull.1626.git.1703539287.gitgitgadget@gmail.com>
From: =?UTF-8?q?Jean-No=C3=ABl=20Avila?= <jn.avila@free.fr>
The CodingGuidelines documents stipulates that multi-word placeholders
are to be separated by dashes, not underscores nor spaces.
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
---
Documentation/git-blame.txt | 2 +-
Documentation/git-bugreport.txt | 4 ++--
Documentation/git-commit-graph.txt | 2 +-
Documentation/git-cvsserver.txt | 4 ++--
Documentation/git-daemon.txt | 6 +++---
Documentation/git-diagnose.txt | 2 +-
Documentation/git-fast-import.txt | 4 ++--
Documentation/git-fetch.txt | 4 ++--
Documentation/git-filter-branch.txt | 6 +++---
Documentation/git-format-patch.txt | 20 ++++++++++----------
Documentation/git-mv.txt | 2 +-
Documentation/git-notes.txt | 2 +-
Documentation/git-replace.txt | 6 +++---
Documentation/git-revert.txt | 4 ++--
Documentation/git-send-email.txt | 2 +-
Documentation/git-status.txt | 4 ++--
Documentation/git-submodule.txt | 4 ++--
Documentation/git-svn.txt | 18 +++++++++---------
Documentation/git-tag.txt | 2 +-
Documentation/git.txt | 2 +-
Documentation/gitdiffcore.txt | 8 ++++----
Documentation/gitformat-index.txt | 4 ++--
Documentation/githooks.txt | 8 ++++----
Documentation/gitk.txt | 4 ++--
Documentation/gitprotocol-capabilities.txt | 2 +-
Documentation/gitprotocol-http.txt | 14 +++++++-------
Documentation/gitprotocol-v2.txt | 8 ++++----
Documentation/gitsubmodules.txt | 4 ++--
Documentation/gitweb.conf.txt | 10 +++++-----
Documentation/gitweb.txt | 2 +-
Documentation/trace2-target-values.txt | 2 +-
Documentation/urls.txt | 8 ++++----
Documentation/user-manual.txt | 4 ++--
builtin/commit-graph.c | 2 +-
34 files changed, 90 insertions(+), 90 deletions(-)
diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
index 5720d04ffe4..b1d7fb539d0 100644
--- a/Documentation/git-blame.txt
+++ b/Documentation/git-blame.txt
@@ -210,7 +210,7 @@ annotated.
. Each blame entry always starts with a line of:
- <40-byte hex sha1> <sourceline> <resultline> <num_lines>
+ <40-byte-hex-sha1> <sourceline> <resultline> <num-lines>
+
Line numbers count from 1.
diff --git a/Documentation/git-bugreport.txt b/Documentation/git-bugreport.txt
index 392d9eb6aec..ca626f7fc68 100644
--- a/Documentation/git-bugreport.txt
+++ b/Documentation/git-bugreport.txt
@@ -52,7 +52,7 @@ OPTIONS
-s <format>::
--suffix <format>::
Specify an alternate suffix for the bugreport name, to create a file
- named 'git-bugreport-<formatted suffix>'. This should take the form of a
+ named 'git-bugreport-<formatted-suffix>'. This should take the form of a
strftime(3) format string; the current local time will be used.
--no-diagnose::
@@ -60,7 +60,7 @@ OPTIONS
Create a zip archive of supplemental information about the user's
machine, Git client, and repository state. The archive is written to the
same output directory as the bug report and is named
- 'git-diagnostics-<formatted suffix>'.
+ 'git-diagnostics-<formatted-suffix>'.
+
Without `mode` specified, the diagnostic archive will contain the default set of
statistics reported by `git diagnose`. An optional `mode` value may be specified
diff --git a/Documentation/git-commit-graph.txt b/Documentation/git-commit-graph.txt
index c8dbceba014..903b16830ea 100644
--- a/Documentation/git-commit-graph.txt
+++ b/Documentation/git-commit-graph.txt
@@ -13,7 +13,7 @@ SYNOPSIS
'git commit-graph write' [--object-dir <dir>] [--append]
[--split[=<strategy>]] [--reachable | --stdin-packs | --stdin-commits]
[--changed-paths] [--[no-]max-new-filters <n>] [--[no-]progress]
- <split options>
+ <split-options>
DESCRIPTION
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index cf4a5a283ec..4c475efeab9 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -197,7 +197,7 @@ allowing access over SSH.
5. Clients should now be able to check out the project. Use the CVS 'module'
name to indicate what Git 'head' you want to check out. This also sets the
name of your newly checked-out directory, unless you tell it otherwise with
- `-d <dir_name>`. For example, this checks out 'master' branch to the
+ `-d <dir-name>`. For example, this checks out 'master' branch to the
`project-master` directory:
+
------
@@ -224,7 +224,7 @@ the database to work reliably (otherwise you need to make sure
that the database is up to date any time 'git-cvsserver' is executed).
By default it uses SQLite databases in the Git directory, named
-`gitcvs.<module_name>.sqlite`. Note that the SQLite backend creates
+`gitcvs.<module-name>.sqlite`. Note that the SQLite backend creates
temporary files in the same directory as the database file on
write so it might not be enough to grant the users using
'git-cvsserver' write access to the database file without granting
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index e064f91c9e3..6ab792228a1 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -18,7 +18,7 @@ SYNOPSIS
[--allow-override=<service>] [--forbid-override=<service>]
[--access-hook=<path>] [--[no-]informative-errors]
[--inetd |
- [--listen=<host_or_ipaddr>] [--port=<n>]
+ [--listen=<host-or-ipaddr>] [--port=<n>]
[--user=<user> [--group=<group>]]]
[--log-destination=(stderr|syslog|none)]
[<directory>...]
@@ -86,10 +86,10 @@ OPTIONS
Incompatible with --detach, --port, --listen, --user and --group
options.
---listen=<host_or_ipaddr>::
+--listen=<host-or-ipaddr>::
Listen on a specific IP address or hostname. IP addresses can
be either an IPv4 address or an IPv6 address if supported. If IPv6
- is not supported, then --listen=hostname is also not supported and
+ is not supported, then --listen=<hostname> is also not supported and
--listen must be given an IPv4 address.
Can be given more than once.
Incompatible with `--inetd` option.
diff --git a/Documentation/git-diagnose.txt b/Documentation/git-diagnose.txt
index 3ec8cc7ad72..0711959e6f6 100644
--- a/Documentation/git-diagnose.txt
+++ b/Documentation/git-diagnose.txt
@@ -45,7 +45,7 @@ OPTIONS
-s <format>::
--suffix <format>::
Specify an alternate suffix for the diagnostics archive name, to create
- a file named 'git-diagnostics-<formatted suffix>'. This should take the
+ a file named 'git-diagnostics-<formatted-suffix>'. This should take the
form of a strftime(3) format string; the current local time will be
used.
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index bd7b1e0a2ea..b2607366b91 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -745,11 +745,11 @@ paths for a commit are encouraged to do so.
`notemodify`
^^^^^^^^^^^^
-Included in a `commit` `<notes_ref>` command to add a new note
+Included in a `commit` `<notes-ref>` command to add a new note
annotating a `<commit-ish>` or change this annotation contents.
Internally it is similar to filemodify 100644 on `<commit-ish>`
path (maybe split into subdirectories). It's not advised to
-use any other commands to write to the `<notes_ref>` tree except
+use any other commands to write to the `<notes-ref>` tree except
`filedeleteall` to delete all existing notes in this tree.
This command has two different means of specifying the content
of the note.
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index f123139c581..50900a50dab 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -186,8 +186,8 @@ origin:
------------------------------------------------
$ git fetch origin --prune --prune-tags
$ git fetch origin --prune 'refs/tags/*:refs/tags/*'
-$ git fetch <url of origin> --prune --prune-tags
-$ git fetch <url of origin> --prune 'refs/tags/*:refs/tags/*'
+$ git fetch <url-of-origin> --prune --prune-tags
+$ git fetch <url-of-origin> --prune 'refs/tags/*:refs/tags/*'
------------------------------------------------
OUTPUT
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index 62e482a95e2..5a4f853785d 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -14,7 +14,7 @@ SYNOPSIS
[--msg-filter <command>] [--commit-filter <command>]
[--tag-name-filter <command>] [--prune-empty]
[--original <namespace>] [-d <directory>] [-f | --force]
- [--state-branch <branch>] [--] [<rev-list options>...]
+ [--state-branch <branch>] [--] [<rev-list-options>...]
WARNING
-------
@@ -32,7 +32,7 @@ listed there as reasonably possible.
DESCRIPTION
-----------
Lets you rewrite Git revision history by rewriting the branches mentioned
-in the <rev-list options>, applying custom filters on each revision.
+in the <rev-list-options>, applying custom filters on each revision.
Those filters can modify each tree (e.g. removing a file or running
a perl rewrite on all files) or information about each commit.
Otherwise, all information (including original commit times or merge
@@ -624,7 +624,7 @@ with:
real backup; it dereferences tags first.)
** Running git-filter-branch with either --tags or --all in your
- <rev-list options>. In order to retain annotated tags as
+ <rev-list-options>. In order to retain annotated tags as
annotated, you must use --tag-name-filter (and must not have
restored from refs/original/ in a previously botched rewrite).
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index aaafce24be2..7eb873b2c75 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -17,10 +17,10 @@ SYNOPSIS
[--signature-file=<file>]
[-n | --numbered | -N | --no-numbered]
[--start-number <n>] [--numbered-files]
- [--in-reply-to=<message id>] [--suffix=.<sfx>]
+ [--in-reply-to=<message-id>] [--suffix=.<sfx>]
[--ignore-if-in-upstream] [--always]
[--cover-from-description=<mode>]
- [--rfc] [--subject-prefix=<subject prefix>]
+ [--rfc] [--subject-prefix=<subject-prefix>]
[(--reroll-count|-v) <n>]
[--to=<email>] [--cc=<email>]
[--[no-]cover-letter] [--quiet]
@@ -30,8 +30,8 @@ SYNOPSIS
[--range-diff=<previous> [--creation-factor=<percent>]]
[--filename-max-length=<n>]
[--progress]
- [<common diff options>]
- [ <since> | <revision range> ]
+ [<common-diff-options>]
+ [ <since> | <revision-range> ]
DESCRIPTION
-----------
@@ -64,7 +64,7 @@ There are two ways to specify which commits to operate on.
to the tip of the current branch that are not in the history
that leads to the <since> to be output.
-2. Generic <revision range> expression (see "SPECIFYING
+2. Generic <revision-range> expression (see "SPECIFYING
REVISIONS" section in linkgit:gitrevisions[7]) means the
commits in the specified range.
@@ -179,9 +179,9 @@ Beware that the default for 'git send-email' is to thread emails
itself. If you want `git format-patch` to take care of threading, you
will want to ensure that threading is disabled for `git send-email`.
---in-reply-to=<message id>::
+--in-reply-to=<message-id>::
Make the first mail (or all the mails with `--no-thread`) appear as a
- reply to the given <message id>, which avoids breaking threads to
+ reply to the given <message-id>, which avoids breaking threads to
provide a new patch series.
--ignore-if-in-upstream::
@@ -219,9 +219,9 @@ populated with placeholder text.
Use the contents of <file> instead of the branch's description
for generating the cover letter.
---subject-prefix=<subject prefix>::
+--subject-prefix=<subject-prefix>::
Instead of the standard '[PATCH]' prefix in the subject
- line, instead use '[<subject prefix>]'. This can be used
+ line, instead use '[<subject-prefix>]'. This can be used
to name a patch series, and can be combined with the
`--numbered` option.
+
@@ -403,7 +403,7 @@ you can use `--suffix=-patch` to get `0001-description-of-my-change-patch`.
`format.useAutoBase` configuration.
--root::
- Treat the revision argument as a <revision range>, even if it
+ Treat the revision argument as a <revision-range>, even if it
is just a single commit (that would normally be treated as a
<since>). Note that root commits included in the specified
range are always formatted as creation patches, independently
diff --git a/Documentation/git-mv.txt b/Documentation/git-mv.txt
index 7f991a33802..dc1bf615341 100644
--- a/Documentation/git-mv.txt
+++ b/Documentation/git-mv.txt
@@ -16,7 +16,7 @@ DESCRIPTION
Move or rename a file, directory, or symlink.
git mv [-v] [-f] [-n] [-k] <source> <destination>
- git mv [-v] [-f] [-n] [-k] <source> ... <destination directory>
+ git mv [-v] [-f] [-n] [-k] <source> ... <destination-directory>
In the first form, it renames <source>, which must exist and be either
a file, symlink or directory, to <destination>.
diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt
index f8310e56a85..c9221a68cce 100644
--- a/Documentation/git-notes.txt
+++ b/Documentation/git-notes.txt
@@ -56,7 +56,7 @@ SUBCOMMANDS
list::
List the notes object for a given object. If no object is
given, show a list of all note objects and the objects they
- annotate (in the format "<note object> <annotated object>").
+ annotate (in the format "<note-object> <annotated-object>").
This is the default subcommand if no subcommand is given.
add::
diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
index 4f257126e33..0a65460adbd 100644
--- a/Documentation/git-replace.txt
+++ b/Documentation/git-replace.txt
@@ -114,11 +114,11 @@ FORMATS
The following formats are available:
* 'short':
- <replaced sha1>
+ <replaced-sha1>
* 'medium':
- <replaced sha1> -> <replacement sha1>
+ <replaced-sha1> -> <replacement-sha1>
* 'long':
- <replaced sha1> (<replaced type>) -> <replacement sha1> (<replacement type>)
+ <replaced-sha1> (<replaced-type>) -> <replacement-sha1> (<replacement-type>)
CREATING REPLACEMENT OBJECTS
----------------------------
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
index cbe0208834d..568925db533 100644
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -116,7 +116,7 @@ include::rerere-options.txt[]
--reference::
Instead of starting the body of the log message with "This
- reverts <full object name of the commit being reverted>.",
+ reverts <full-object-name-of-the-commit-being-reverted>.",
refer to the commit using "--pretty=reference" format
(cf. linkgit:git-log[1]). The `revert.reference`
configuration variable can be used to enable this option by
@@ -149,7 +149,7 @@ While git creates a basic commit message automatically, it is
_strongly_ recommended to explain why the original commit is being
reverted.
In addition, repeatedly reverting reverts will result in increasingly
-unwieldy subject lines, for example 'Reapply "Reapply "<original subject>""'.
+unwieldy subject lines, for example 'Reapply "Reapply "<original-subject>""'.
Please consider rewording these to be shorter and more unique.
CONFIGURATION
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 465011bad50..c1b39acaab4 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git send-email' [<options>] <file|directory>...
-'git send-email' [<options>] <format-patch options>
+'git send-email' [<options>] <format-patch-options>
'git send-email' --dump-aliases
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 10fecc51a75..4dbb88373bc 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -309,7 +309,7 @@ Line Notes
------------------------------------------------------------
# branch.oid <commit> | (initial) Current commit.
# branch.head <branch> | (detached) Current branch.
-# branch.upstream <upstream_branch> If upstream is set.
+# branch.upstream <upstream-branch> If upstream is set.
# branch.ab +<ahead> -<behind> If upstream is set and
the commit is present.
------------------------------------------------------------
@@ -502,7 +502,7 @@ results, so it could be faster on subsequent runs.
usually worth the additional size.
* `core.untrackedCache=true` and `core.fsmonitor=true` or
- `core.fsmonitor=<hook_command_pathname>` (see
+ `core.fsmonitor=<hook-command-pathname>` (see
linkgit:git-update-index[1]): enable both the untracked cache
and FSMonitor features and only search directories that have
been modified since the previous `git status` command. This
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 695730609aa..ca0347a37b5 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -136,7 +136,7 @@ If you really want to remove a submodule from the repository and commit
that use linkgit:git-rm[1] instead. See linkgit:gitsubmodules[7] for removal
options.
-update [--init] [--remote] [-N|--no-fetch] [--[no-]recommend-shallow] [-f|--force] [--checkout|--rebase|--merge] [--reference <repository>] [--depth <depth>] [--recursive] [--jobs <n>] [--[no-]single-branch] [--filter <filter spec>] [--] [<path>...]::
+update [--init] [--remote] [-N|--no-fetch] [--[no-]recommend-shallow] [-f|--force] [--checkout|--rebase|--merge] [--reference <repository>] [--depth <depth>] [--recursive] [--jobs <n>] [--[no-]single-branch] [--filter <filter-spec>] [--] [<path>...]::
+
--
Update the registered submodules to match what the superproject
@@ -185,7 +185,7 @@ submodule with the `--init` option.
If `--recursive` is specified, this command will recurse into the
registered submodules, and update any nested submodules within.
-If `--filter <filter spec>` is specified, the given partial clone filter will be
+If `--filter <filter-spec>` is specified, the given partial clone filter will be
applied to the submodule. See linkgit:git-rev-list[1] for details on filter
specifications.
--
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 4e92308e85d..43c68c2ec44 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -37,12 +37,12 @@ COMMANDS
argument. Normally this command initializes the current
directory.
--T<trunk_subdir>;;
---trunk=<trunk_subdir>;;
--t<tags_subdir>;;
---tags=<tags_subdir>;;
--b<branches_subdir>;;
---branches=<branches_subdir>;;
+-T<trunk-subdir>;;
+--trunk=<trunk-subdir>;;
+-t<tags-subdir>;;
+--tags=<tags-subdir>;;
+-b<branches-subdir>;;
+--branches=<branches-subdir>;;
-s;;
--stdlayout;;
These are optional command-line options for init. Each of
@@ -726,9 +726,9 @@ ADVANCED OPTIONS
when tracking a single URL. The 'log' and 'dcommit' commands
no longer require this switch as an argument.
--R<remote name>::
---svn-remote <remote name>::
- Specify the [svn-remote "<remote name>"] section to use,
+-R<remote-name>::
+--svn-remote <remote-name>::
+ Specify the [svn-remote "<remote-name>"] section to use,
this allows SVN multiple repositories to be tracked.
Default: "svn"
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index d42efb31127..5fe519c31ec 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -224,7 +224,7 @@ it in the repository configuration as follows:
-------------------------------------
[user]
- signingKey = <gpg-key_id>
+ signingKey = <gpg-key-id>
-------------------------------------
`pager.tag` is only respected when listing tags, i.e., when `-l` is
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 2535a30194f..d51473a3274 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -838,7 +838,7 @@ of the SID and an optional counter (to avoid filename
collisions).
+
In addition, if the variable is set to
-`af_unix:[<socket_type>:]<absolute-pathname>`, Git will try
+`af_unix:[<socket-type>:]<absolute-pathname>`, Git will try
to open the path as a Unix Domain Socket. The socket type
can be either `stream` or `dgram`.
+
diff --git a/Documentation/gitdiffcore.txt b/Documentation/gitdiffcore.txt
index 3cda2e07c24..642c51227b5 100644
--- a/Documentation/gitdiffcore.txt
+++ b/Documentation/gitdiffcore.txt
@@ -245,20 +245,20 @@ diffcore-pickaxe: For Detecting Addition/Deletion of Specified String
This transformation limits the set of filepairs to those that change
specified strings between the preimage and the postimage in a certain
-way. -S<block of text> and -G<regular expression> options are used to
+way. -S<block-of-text> and -G<regular-expression> options are used to
specify different ways these strings are sought.
-"-S<block of text>" detects filepairs whose preimage and postimage
+"-S<block-of-text>" detects filepairs whose preimage and postimage
have different number of occurrences of the specified block of text.
By definition, it will not detect in-file moves. Also, when a
changeset moves a file wholesale without affecting the interesting
string, diffcore-rename kicks in as usual, and `-S` omits the filepair
(since the number of occurrences of that string didn't change in that
rename-detected filepair). When used with `--pickaxe-regex`, treat
-the <block of text> as an extended POSIX regular expression to match,
+the <block-of-text> as an extended POSIX regular expression to match,
instead of a literal string.
-"-G<regular expression>" (mnemonic: grep) detects filepairs whose
+"-G<regular-expression>" (mnemonic: grep) detects filepairs whose
textual diff has an added or a deleted line that matches the given
regular expression. This means that it will detect in-file (or what
rename-detection considers the same file) moves, which is noise. The
diff --git a/Documentation/gitformat-index.txt b/Documentation/gitformat-index.txt
index 0773e5c3800..145cace1fe9 100644
--- a/Documentation/gitformat-index.txt
+++ b/Documentation/gitformat-index.txt
@@ -386,8 +386,8 @@ The remaining data of each directory block is grouped by type:
long, "REUC" extension that is M-bytes long, followed by "EOIE",
then the hash would be:
- Hash("TREE" + <binary representation of N> +
- "REUC" + <binary representation of M>)
+ Hash("TREE" + <binary-representation-of-N> +
+ "REUC" + <binary-representation-of-M>)
== Index Entry Offset Table
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 883982e7a05..37f91d5b50c 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -243,7 +243,7 @@ named remote is not being used both values will be the same.
Information about what is to be pushed is provided on the hook's standard
input with lines of the form:
- <local ref> SP <local object name> SP <remote ref> SP <remote object name> LF
+ <local-ref> SP <local-object-name> SP <remote-ref> SP <remote-object-name> LF
For instance, if the command +git push origin master:foreign+ were run the
hook would receive a line like the following:
@@ -251,9 +251,9 @@ hook would receive a line like the following:
refs/heads/master 67890 refs/heads/foreign 12345
although the full object name would be supplied. If the foreign ref does not
-yet exist the `<remote object name>` will be the all-zeroes object name. If a
-ref is to be deleted, the `<local ref>` will be supplied as `(delete)` and the
-`<local object name>` will be the all-zeroes object name. If the local commit
+yet exist the `<remote-object-name>` will be the all-zeroes object name. If a
+ref is to be deleted, the `<local-ref>` will be supplied as `(delete)` and the
+`<local-object-name>` will be the all-zeroes object name. If the local commit
was specified by something other than a name which could be expanded (such as
`HEAD~`, or an object name) it will be supplied as it was originally given.
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index c2213bb77b3..35b39960296 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -8,7 +8,7 @@ gitk - The Git repository browser
SYNOPSIS
--------
[verse]
-'gitk' [<options>] [<revision range>] [--] [<path>...]
+'gitk' [<options>] [<revision-range>] [--] [<path>...]
DESCRIPTION
-----------
@@ -124,7 +124,7 @@ gitk-specific options
range to show. The command is expected to print on its
standard output a list of additional revisions to be shown,
one per line. Use this instead of explicitly specifying a
- '<revision range>' if the set of commits to show may vary
+ '<revision-range>' if the set of commits to show may vary
between refreshes.
--select-commit=<ref>::
diff --git a/Documentation/gitprotocol-capabilities.txt b/Documentation/gitprotocol-capabilities.txt
index d6c6effc215..2cf7735be47 100644
--- a/Documentation/gitprotocol-capabilities.txt
+++ b/Documentation/gitprotocol-capabilities.txt
@@ -378,7 +378,7 @@ fetch-pack may send "filter" commands to request a partial clone
or partial fetch and request that the server omit various objects
from the packfile.
-session-id=<session id>
+session-id=<session-id>
-----------------------
The server may advertise a session ID that can be used to identify this process
diff --git a/Documentation/gitprotocol-http.txt b/Documentation/gitprotocol-http.txt
index 21b73b7a1f5..d834c745f71 100644
--- a/Documentation/gitprotocol-http.txt
+++ b/Documentation/gitprotocol-http.txt
@@ -391,14 +391,14 @@ C: Start a queue, `c_pending`, ordered by commit time (popping newest
C: Send one `$GIT_URL/git-upload-pack` request:
- C: 0032want <want #1>...............................
- C: 0032want <want #2>...............................
+ C: 0032want <want-#1>...............................
+ C: 0032want <want-#2>...............................
....
- C: 0032have <common #1>.............................
- C: 0032have <common #2>.............................
+ C: 0032have <common-#1>.............................
+ C: 0032have <common-#2>.............................
....
- C: 0032have <have #1>...............................
- C: 0032have <have #2>...............................
+ C: 0032have <have-#1>...............................
+ C: 0032have <have-#2>...............................
....
C: 0000
@@ -512,7 +512,7 @@ Within the command portion of the request body clients SHOULD send
the id obtained through ref discovery as old_id.
update_request = command_list
- "PACK" <binary data>
+ "PACK" <binary-data>
command_list = PKT-LINE(command NUL cap_list LF)
*(command_pkt)
diff --git a/Documentation/gitprotocol-v2.txt b/Documentation/gitprotocol-v2.txt
index 8c1e7c61eac..0b800abd567 100644
--- a/Documentation/gitprotocol-v2.txt
+++ b/Documentation/gitprotocol-v2.txt
@@ -199,7 +199,7 @@ which can be used to limit the refs sent from the server.
Additional features not supported in the base command will be advertised
as the value of the command in the capability advertisement in the form
-of a space separated list of features: "<command>=<feature 1> <feature 2>"
+of a space separated list of features: "<command>=<feature-1> <feature-2>"
ls-refs takes in the following arguments:
@@ -245,7 +245,7 @@ addition of future extensions.
Additional features not supported in the base command will be advertised
as the value of the command in the capability advertisement in the form
-of a space separated list of features: "<command>=<feature 1> <feature 2>"
+of a space separated list of features: "<command>=<feature-1> <feature-2>"
A `fetch` request can take the following arguments:
@@ -363,7 +363,7 @@ can be included in the client's request as well as the potential
addition of the 'packfile-uris' section in the server's response as
explained below.
- packfile-uris <comma-separated list of protocols>
+ packfile-uris <comma-separated-list-of-protocols>
Indicates to the server that the client is willing to receive
URIs of any of the given protocols in place of objects in the
sent packfile. Before performing the connectivity check, the
@@ -534,7 +534,7 @@ with objects using hash algorithm X. If not specified, the server is assumed to
only handle SHA-1. If the client would like to use a hash algorithm other than
SHA-1, it should specify its object-format string.
-session-id=<session id>
+session-id=<session-id>
~~~~~~~~~~~~~~~~~~~~~~~
The server may advertise a session ID that can be used to identify this process
diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
index 8400d591da0..f7b5a25a0ca 100644
--- a/Documentation/gitsubmodules.txt
+++ b/Documentation/gitsubmodules.txt
@@ -151,7 +151,7 @@ the superproject's `$GIT_DIR/config` file, so the superproject's history
is not affected. This can be undone using `git submodule init`.
* Deleted submodule: A submodule can be deleted by running
-`git rm <submodule path> && git commit`. This can be undone
+`git rm <submodule-path> && git commit`. This can be undone
using `git revert`.
+
The deletion removes the superproject's tracking data, which are
@@ -229,7 +229,7 @@ Workflow for a third party library
git submodule add <URL> <path>
# Occasionally update the submodule to a new version:
- git -C <path> checkout <new version>
+ git -C <path> checkout <new-version>
git add <path>
git commit -m "update submodule to new version"
diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt
index b078fef6f5c..39c959cbe7d 100644
--- a/Documentation/gitweb.conf.txt
+++ b/Documentation/gitweb.conf.txt
@@ -343,7 +343,7 @@ $home_link_str::
Label for the "home link" at the top of all pages, leading to `$home_link`
(usually the main gitweb page, which contains the projects list). It is
used as the first component of gitweb's "breadcrumb trail":
- `<home link> / <project> / <action>`. Can be set at build time using
+ `<home-link> / <project> / <action>`. Can be set at build time using
the `GITWEB_HOME_LINK_STR` variable. By default it is set to "projects",
as this link leads to the list of projects. Another popular choice is to
set it to the name of site. Note that it is treated as raw HTML so it
@@ -604,9 +604,9 @@ Many gitweb features can be enabled (or disabled) and configured using the
Each `%feature` hash element is a hash reference and has the following
structure:
----------------------------------------------------------------------
-"<feature_name>" => {
- "sub" => <feature-sub (subroutine)>,
- "override" => <allow-override (boolean)>,
+"<feature-name>" => {
+ "sub" => <feature-sub-(subroutine)>,
+ "override" => <allow-override-(boolean)>,
"default" => [ <options>... ]
},
----------------------------------------------------------------------
@@ -614,7 +614,7 @@ Some features cannot be overridden per project. For those
features the structure of appropriate `%feature` hash element has a simpler
form:
----------------------------------------------------------------------
-"<feature_name>" => {
+"<feature-name>" => {
"override" => 0,
"default" => [ <options>... ]
},
diff --git a/Documentation/gitweb.txt b/Documentation/gitweb.txt
index 1030e9667ea..7b2f2ea6fc1 100644
--- a/Documentation/gitweb.txt
+++ b/Documentation/gitweb.txt
@@ -305,7 +305,7 @@ pathnames. In most general form such path_info (component) based gitweb URL
looks like this:
-----------------------------------------------------------------------
-.../gitweb.cgi/<repo>/<action>/<revision_from>:/<path_from>..<revision_to>:/<path_to>?<arguments>
+.../gitweb.cgi/<repo>/<action>/<revision-from>:/<path-from>..<revision-to>:/<path-to>?<arguments>
-----------------------------------------------------------------------
diff --git a/Documentation/trace2-target-values.txt b/Documentation/trace2-target-values.txt
index 3985b6d3c29..06f19533134 100644
--- a/Documentation/trace2-target-values.txt
+++ b/Documentation/trace2-target-values.txt
@@ -5,7 +5,7 @@
* `<absolute-pathname>` - Writes to the file in append mode. If the target
already exists and is a directory, the traces will be written to files (one
per process) underneath the given directory.
-* `af_unix:[<socket_type>:]<absolute-pathname>` - Write to a
+* `af_unix:[<socket-type>:]<absolute-pathname>` - Write to a
Unix DomainSocket (on platforms that support them). Socket
type can be either `stream` or `dgram`; if omitted Git will
try both.
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 4e79c1589ec..ce671f812d4 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -73,8 +73,8 @@ use will be rewritten into URLs that work), you can create a
configuration section of the form:
------------
- [url "<actual url base>"]
- insteadOf = <other url base>
+ [url "<actual-url-base>"]
+ insteadOf = <other-url-base>
------------
For example, with this:
@@ -92,8 +92,8 @@ If you want to rewrite URLs for push only, you can create a
configuration section of the form:
------------
- [url "<actual url base>"]
- pushInsteadOf = <other url base>
+ [url "<actual-url-base>"]
+ pushInsteadOf = <other-url-base>
------------
For example, with this:
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index d8dbe6b56d4..163e8fe77aa 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -4100,8 +4100,8 @@ independently of the contents or the type of the object: all objects can
be validated by verifying that (a) their hashes match the content of the
file and (b) the object successfully inflates to a stream of bytes that
forms a sequence of
-`<ascii type without space> + <space> + <ascii decimal size> +
-<byte\0> + <binary object data>`.
+`<ascii-type-without-space> + <space> + <ascii-decimal-size> +
+<byte\0> + <binary-object-data>`.
The structured objects can further have their structure and
connectivity to other objects verified. This is generally done with
diff --git a/builtin/commit-graph.c b/builtin/commit-graph.c
index 45d035af600..597927bc56e 100644
--- a/builtin/commit-graph.c
+++ b/builtin/commit-graph.c
@@ -22,7 +22,7 @@
N_("git commit-graph write [--object-dir <dir>] [--append]\n" \
" [--split[=<strategy>]] [--reachable | --stdin-packs | --stdin-commits]\n" \
" [--changed-paths] [--[no-]max-new-filters <n>] [--[no-]progress]\n" \
- " <split options>")
+ " <split-options>")
static const char * builtin_commit_graph_verify_usage[] = {
BUILTIN_COMMIT_GRAPH_VERIFY_USAGE,
--
gitgitgadget
^ permalink raw reply related
* [PATCH 0/2] Fix doc placeholders
From: Jean-Noël Avila via GitGitGadget @ 2023-12-25 21:21 UTC (permalink / raw)
To: git; +Cc: Jean-Noël Avila
While setting up a check of (the absence of) translations of commands,
options and environment variable in the manpages in the manpage translation
project, some false positives appeared.
Here is a series that enforces the formatting rules for placeholders in
documentation and help.
Jean-Noël Avila (2):
doc: enforce dashes in placeholders
doc: enforce placeholders in documentation
Documentation/diff-options.txt | 2 +-
Documentation/git-blame.txt | 2 +-
Documentation/git-bugreport.txt | 4 ++--
Documentation/git-commit-graph.txt | 2 +-
Documentation/git-config.txt | 8 ++++----
Documentation/git-cvsserver.txt | 4 ++--
Documentation/git-daemon.txt | 10 +++++-----
Documentation/git-diagnose.txt | 2 +-
Documentation/git-difftool.txt | 2 +-
Documentation/git-fast-import.txt | 4 ++--
Documentation/git-fetch.txt | 4 ++--
Documentation/git-filter-branch.txt | 6 +++---
Documentation/git-format-patch.txt | 20 ++++++++++----------
Documentation/git-mv.txt | 2 +-
Documentation/git-notes.txt | 2 +-
Documentation/git-replace.txt | 6 +++---
Documentation/git-revert.txt | 4 ++--
Documentation/git-send-email.txt | 2 +-
Documentation/git-status.txt | 4 ++--
Documentation/git-submodule.txt | 4 ++--
Documentation/git-svn.txt | 18 +++++++++---------
Documentation/git-tag.txt | 2 +-
Documentation/git.txt | 4 ++--
Documentation/gitdiffcore.txt | 8 ++++----
Documentation/gitformat-index.txt | 4 ++--
Documentation/githooks.txt | 8 ++++----
Documentation/gitk.txt | 4 ++--
Documentation/gitprotocol-capabilities.txt | 2 +-
Documentation/gitprotocol-http.txt | 14 +++++++-------
Documentation/gitprotocol-v2.txt | 8 ++++----
Documentation/gitsubmodules.txt | 4 ++--
Documentation/gitweb.conf.txt | 10 +++++-----
Documentation/gitweb.txt | 2 +-
Documentation/trace2-target-values.txt | 2 +-
Documentation/urls.txt | 8 ++++----
Documentation/user-manual.txt | 4 ++--
builtin/commit-graph.c | 2 +-
37 files changed, 99 insertions(+), 99 deletions(-)
base-commit: 564d0252ca632e0264ed670534a51d18a689ef5d
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1626%2Fjnavila%2Ffix_doc_placeholders-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1626/jnavila/fix_doc_placeholders-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1626
--
gitgitgadget
^ permalink raw reply
* [Question] Can Git Diff with block context
From: ZheNing Hu @ 2023-12-25 3:46 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano, Christian Couder
Hi,
In our code review process on our coding platform, when displaying the
diff of a file, we add a parameter called include_extra_info_lines,
which is used to expand the display of code lines related to code
comments (I'm not sure if this feature was ported from GitLab).
However, in terms of implementation, this feature is achieved on the
server side by a very cumbersome method, which stitches together the
normal diff and the diff of the code comment block before rendering
it. I would like to know if git diff natively supports a similar
capability, where I can specify the first and last lines of the blocks
of the file that I need, and then diff will load these blocks
together.
--
ZheNing Hu
^ permalink raw reply
* [FEATURE REQUEST] New method of commits range selection
From: Andry @ 2023-12-25 1:08 UTC (permalink / raw)
To: Git
Hello Git,
I've described the details in the GitHub discussion: https://github.com/orgs/community/discussions/56342#discussioncomment-7882789
But because the problem is related to the Git commands like `git log`: https://git-scm.com/docs/git-log
Then I think it have to requested from the Git developers.
---
Even more reliable variant is to reverse the second end point search direction in the commit range.
Instead of search from the top to the bottom of a tree beginning a branch tip, there is another way to search from the bottom to the top beginning a commit or a tag. This is better because there is no need to exclude anything else, because the search path is an intersection of both search directions in any potential tree if both ends exists.
Examples:
Search from the top to the bottom:
range: `d3^...dev`, where `...dev` - includes and searches back, `d3^...` - excludes first parent and searches back
```
Example #1 Example #2
m1 -o- master m1 -o- master
| |
| o- d1 dev | o- d1 dev
m2 -o | m2 -o |
|\ | o- tags/t1 |\ | o- tags/t1
| \ | / | \ | /
m3 -o \|/ m3 -o \|/
| o- d2 | o- d2
| /| | /|
| / | | / |
|/ | |/ |
m4 -o | m4 -o |
| o- d3 |\ |
| / | \ |
| / | \|
|/ | o- d3
m5 -o | /
| /
|/
m5 -o
```
Selection result:
Example `#1`: `d1, d2, m4, d3`
https://github.com/andry81-tests/commits-range-selection-test-1/compare/d3^...dev
Example `#2`: `d1, d2, m4, d3`
https://github.com/andry81-tests/commits-range-selection-test-2/compare/d3^...dev
To exclude the master commits, there is need to add more exclusions: `{d3^,m4}..dev`
This will give invalid selection for the second example, because `d3` would be excluded from `m4`, because we need to include *at least* all `dev` commits.
Instead of add more exclusion, we can just reverse the second end point search direction: `--intersect d3..dev`, where `..dev` - includes and searches back, `d3..` - includes and searches forward.
Selection result:
Example `#1`: `d1, d2, d3`
Example `#2`: `d1, d2, m4, d3`
This does not require to actually search from the `d3` up, because only requires to collect all merge commits down from the `dev` which might has path to the `d3`.
It does not exclude all the master branch commits, but gives a cleaner result without additional excludes.
^ permalink raw reply
* [PATCH] mem-pool: simplify alignment calculation
From: René Scharfe @ 2023-12-24 17:02 UTC (permalink / raw)
To: Git List
Use DIV_ROUND_UP in mem_pool_alloc() to round the allocation length to
the next multiple of GIT_MAX_ALIGNMENT instead of twiddling bits
explicitly. This is shorter and clearer, to the point that we no longer
need the comment that explains what's being calculated.
Signed-off-by: René Scharfe <l.s.r@web.de>
---
Latest Clang emits the same x64 instructions for both versions; GCC only
emits the supposedly optimal output for the patched version:
https://godbolt.org/z/jPscnPqna
mem-pool.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/mem-pool.c b/mem-pool.c
index 2b25521e2d..2078c22b09 100644
--- a/mem-pool.c
+++ b/mem-pool.c
@@ -89,9 +89,7 @@ void *mem_pool_alloc(struct mem_pool *pool, size_t len)
struct mp_block *p = NULL;
void *r;
- /* round up to a 'GIT_MAX_ALIGNMENT' alignment */
- if (len & (GIT_MAX_ALIGNMENT - 1))
- len += GIT_MAX_ALIGNMENT - (len & (GIT_MAX_ALIGNMENT - 1));
+ len = DIV_ROUND_UP(len, GIT_MAX_ALIGNMENT) * GIT_MAX_ALIGNMENT;
if (pool->mp_block &&
pool->mp_block->end - pool->mp_block->next_free >= len)
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3] Teach git apply to respect core.fileMode settings
From: Johannes Schindelin @ 2023-12-24 13:42 UTC (permalink / raw)
To: Chandra Pratap via GitGitGadget
Cc: git, Torsten Bögershausen, Chandra Pratap, Chandra Pratap
In-Reply-To: <pull.1620.v3.git.1703066893657.gitgitgadget@gmail.com>
Hi,
On Wed, 20 Dec 2023, Chandra Pratap via GitGitGadget wrote:
> diff --git a/apply.c b/apply.c
> index 3d69fec836d..58f26c40413 100644
> --- a/apply.c
> +++ b/apply.c
> @@ -3778,8 +3778,12 @@ static int check_preimage(struct apply_state *state,
> return error_errno("%s", old_name);
> }
>
> - if (!state->cached && !previous)
> - st_mode = ce_mode_from_stat(*ce, st->st_mode);
> + if (!state->cached && !previous) {
> + if (!trust_executable_bit)
> + st_mode = *ce ? (*ce)->ce_mode : patch->old_mode;
> + else
> + st_mode = ce_mode_from_stat(*ce, st->st_mode);
> + }
I noticed a CI breakage in t2106.3 in `seen` that seems to be caused by
this, and I can make it go away with this patch:
-- snip --
From 5c2a709b629d396528dabe2f92bf3d4deb5bbdb2 Mon Sep 17 00:00:00 2001
From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sun, 24 Dec 2023 14:01:49 +0100
Subject: [PATCH] fixup! Teach git apply to respect core.fileMode settings
As pointed out e.g. by t2016.3(git checkout -p), if the patch is to be
applied in reverse (`git apply -R`), then the `old_mode` is actually 0,
and we must use `new_mode` instead.
While at it, add some defensive code to ignore `ce_mode` should it be 0.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
apply.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/apply.c b/apply.c
index 58f26c404136..5ad06ef2f843 100644
--- a/apply.c
+++ b/apply.c
@@ -3780,7 +3780,9 @@ static int check_preimage(struct apply_state *state,
if (!state->cached && !previous) {
if (!trust_executable_bit)
- st_mode = *ce ? (*ce)->ce_mode : patch->old_mode;
+ st_mode = *ce && (*ce)->ce_mode ? (*ce)->ce_mode :
+ (state->apply_in_reverse ?
+ patch->new_mode : patch->old_mode);
else
st_mode = ce_mode_from_stat(*ce, st->st_mode);
}
-- snap --
I guess you can slap on that `Reviewed-by:` footer again, after all... ;-)
Ciao,
Johannes
^ permalink raw reply related
* Re: [PATCH] t1006: add tests for %(objectsize:disk)
From: René Scharfe @ 2023-12-24 9:30 UTC (permalink / raw)
To: Jeff King; +Cc: git, Ondrej Pohorelsky, brian m . carlson, Junio C Hamano
In-Reply-To: <20231223101853.GC2016274@coredump.intra.peff.net>
Am 23.12.23 um 11:18 schrieb Jeff King:
> On Fri, Dec 22, 2023 at 12:13:10AM +0100, René Scharfe wrote:
>
>>>> Should we deduplicate here, like cat-file does (i.e. use "sort -u")?
>>>> Having the same object in multiple places for whatever reason would not
>>>> be a cause for reporting an error in this test, I would think.
>>>
>>> No, for the reasons I said in the commit message: if an object exists in
>>> multiple places the test is already potentially invalid, as Git does not
>>> promise which version it will use. So it might work racily, or it might
>>> work for now but be fragile. By not de-duplicating, we make sure the
>>> test's assumption holds.
>>
>> Oh, skipped that paragraph. Still I don't see how a duplicate object
>> would necessarily invalidate t1006. The comment for the test "cat-file
>> --batch-all-objects shows all objects" a few lines above indicates that
>> it's picky about the provenance of objects, but it uses a separate
>> repository. I can't infer the same requirement for the root repo, but
>> we already established that I can't read.
>
> The cat-file documentation explicitly calls this situation out:
>
> Note also that multiple copies of an object may be present in the
> object database; in this case, it is undefined which copy’s size or
> delta base will be reported.
>
> So if t1006 were to grow such a duplicate object, what will happen? If
> we de-dup in the new test, then we might end up mentioning the same copy
> (and the test passes), or we might not (and the test fails). But much
> worse, the results might be racy (depending on how cat-file happens to
> decide which one to use). By no de-duping, then the test will reliably
> fail and the author can decide how to handle it then.
>
> IOW it is about failing immediately and predictably rather than letting
> a future change to sneak a race or other accident-waiting-to-happen into
> t1006.
>
>> Anyway, if someone finds a use for git repack without -d or
>> git unpack-objects or whatever else causes duplicates in the root
>> repository of t1006 then they can try to reverse your ban with concrete
>> arguments.
>
> In the real world, the most common way to get a duplicate is to fetch or
> push into a repository, such that:
>
> 1. There are enough objects to retain the pack (100 by default)
>
> 2. There's a thin delta in the on-the-wire pack (i.e., a delta against
> a base that the sender knows the receiver has, but which isn't
> itself sent).
>
> Then "index-pack --fix-thin" will complete the on-disk pack by storing a
> copy of the base object in it. And now we have it in two packs (and if
> it's a delta or loose in the original, the size will be different).
I think I get it now. The size possibly being different is crucial.
cat-file deduplicates based on object ID alone. sort -u in t1006 would
deduplicate based on object ID and size, meaning that it would only
remove duplicates of the same size. Emulating the deduplication of
cat-file is also possible, but would introduce the race you mentioned.
However, even removing only same-size duplicates is unreliable because
there is no guarantee that the same object has the same size in
different packs. Adding a new object that is a better delta base would
change the size.
So, deduplicating based on object ID and size is sound for any
particular run, but sizes are not stable and thus we need to know if
the tests do something that adds duplicates of any size.
René
^ permalink raw reply
* Re: [PATCH v2] t1006: add tests for %(objectsize:disk)
From: René Scharfe @ 2023-12-24 9:30 UTC (permalink / raw)
To: Jeff King; +Cc: git, Ondrej Pohorelsky, brian m . carlson, Junio C Hamano
In-Reply-To: <20231223100905.GB2016274@coredump.intra.peff.net>
Am 23.12.23 um 11:09 schrieb Jeff King:
>
> ---
> t/t1006-cat-file.sh | 36 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/t/t1006-cat-file.sh b/t/t1006-cat-file.sh
> index 271c5e4fd3..e0c6482797 100755
> --- a/t/t1006-cat-file.sh
> +++ b/t/t1006-cat-file.sh
> @@ -1100,6 +1100,42 @@ test_expect_success 'cat-file --batch="batman" with --batch-all-objects will wor
> cmp expect actual
> '
>
> +test_expect_success 'cat-file %(objectsize:disk) with --batch-all-objects' '
> + # our state has both loose and packed objects,
> + # so find both for our expected output
> + {
> + find .git/objects/?? -type f |
> + awk -F/ "{ print \$0, \$3\$4 }" |
> + while read path oid
> + do
> + size=$(test_file_size "$path") &&
> + echo "$oid $size" ||
> + return 1
> + done &&
> + rawsz=$(test_oid rawsz) &&
> + find .git/objects/pack -name "*.idx" |
> + while read idx
> + do
> + git show-index <"$idx" >idx.raw &&
> + sort -nr <idx.raw >idx.sorted &&
> + packsz=$(test_file_size "${idx%.idx}.pack") &&
> + end=$((packsz - rawsz)) &&
> + while read start oid rest
> + do
> + size=$((end - start)) &&
> + end=$start &&
> + echo "$oid $size" ||
> + return 1
> + done <idx.sorted ||
> + return 1
> + done
> + } >expect.raw &&
> + sort <expect.raw >expect &&
> + git cat-file --batch-all-objects \
> + --batch-check="%(objectname) %(objectsize:disk)" >actual &&
> + test_cmp expect actual
> +'
> +
> test_expect_success 'set up replacement object' '
> orig=$(git rev-parse HEAD) &&
> git cat-file commit $orig >orig &&
Looks good to me.
René
^ permalink raw reply
* Re: [PATCH] mem-pool: fix big allocations
From: René Scharfe @ 2023-12-24 9:30 UTC (permalink / raw)
To: Elijah Newren; +Cc: Git List, Jameson Miller
In-Reply-To: <CABPp-BFiK9A6426d7CFeMZvaBcvmShaY9O0krtCe7jeV9wW7nQ@mail.gmail.com>
Am 24.12.23 um 04:11 schrieb Elijah Newren:
> On Thu, Dec 21, 2023 at 3:13 PM René Scharfe <l.s.r@web.de> wrote:
>>
>> Add a basic unit test to demonstate the issue by using mem_pool_calloc()
>
> demonstrate (missing 'r')?
Yes. I didn't intend to mention any demons or states, let alone a
demon state. *facepalm*
> Nice catch; looks good to me. Out of curiosity, how'd you find the issue?
I was working on using a memory pool for name-rev. I played with
different values for block_alloc, not fully sure why anymore -- either
for checking the performance impact or testing robustness.
René
^ permalink raw reply
* Re: [PATCH] sparse-checkout: be consistent with end of options markers
From: Jeff King @ 2023-12-24 8:32 UTC (permalink / raw)
To: Elijah Newren via GitGitGadget; +Cc: git, Randall S. Becker, Elijah Newren
In-Reply-To: <pull.1625.git.git.1703379611749.gitgitgadget@gmail.com>
On Sun, Dec 24, 2023 at 01:00:11AM +0000, Elijah Newren via GitGitGadget wrote:
> Remove the erroneous PARSE_OPT_KEEP_UNKNOWN_OPT flag now to fix this
> bug. Note that this does mean that anyone who might have been using
> [...]
Thanks for wrapping this up in patch form. It looks good to me,
including the reasoning. You didn't add any tests, but I find it rather
unlikely that we'd later regress here.
-Peff
^ permalink raw reply
* Re: [PATCH 1/3] sparse-checkout: take care of "--end-of-options" in set/add/check-rules
From: Elijah Newren @ 2023-12-24 7:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Josh Steadmon
In-Reply-To: <20231221065925.3234048-2-gitster@pobox.com>
On Wed, Dec 20, 2023 at 11:00 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> 93851746 (parse-options: decouple "--end-of-options" and "--",
> 2023-12-06) updated the world order to make callers of parse-options
> that set PARSE_OPT_KEEP_UNKNOWN_OPT responsible for deciding what to
> do with "--end-of-options" they may see after parse_options() returns.
>
> This unfortunately broke "sparse-checkout set/add", and from this
> invocation,
>
> "git sparse-checkout [add|set] --[no-]cone --end-of-options pattern..."
>
> we now see "--end-of-options" listed in .git/info/sparse-checkout as if
> it is one of the path patterns.
>
> A breakage that results from the same cause exists in the check-rules
> subcommand, but check-rules has a few other problems that need to be
> corrected before it can fully work with --end-of-options safely,
> which will be addressed later.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> builtin/sparse-checkout.c | 3 +++
> parse-options.c | 8 ++++++++
> parse-options.h | 2 ++
> t/t1090-sparse-checkout-scope.sh | 8 ++++++++
> t/t1091-sparse-checkout-builtin.sh | 2 +-
> 5 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/builtin/sparse-checkout.c b/builtin/sparse-checkout.c
> index 5c8ffb1f75..8f55127202 100644
> --- a/builtin/sparse-checkout.c
> +++ b/builtin/sparse-checkout.c
> @@ -779,6 +779,7 @@ static int sparse_checkout_add(int argc, const char **argv, const char *prefix)
> builtin_sparse_checkout_add_options,
> builtin_sparse_checkout_add_usage,
> PARSE_OPT_KEEP_UNKNOWN_OPT);
> + parse_opt_skip_end_of_options(&argc, &argv);
>
> sanitize_paths(argc, argv, prefix, add_opts.skip_checks);
>
> @@ -826,6 +827,7 @@ static int sparse_checkout_set(int argc, const char **argv, const char *prefix)
> builtin_sparse_checkout_set_options,
> builtin_sparse_checkout_set_usage,
> PARSE_OPT_KEEP_UNKNOWN_OPT);
> + parse_opt_skip_end_of_options(&argc, &argv);
>
> if (update_modes(&set_opts.cone_mode, &set_opts.sparse_index))
> return 1;
> @@ -998,6 +1000,7 @@ static int sparse_checkout_check_rules(int argc, const char **argv, const char *
> builtin_sparse_checkout_check_rules_options,
> builtin_sparse_checkout_check_rules_usage,
> PARSE_OPT_KEEP_UNKNOWN_OPT);
> + parse_opt_skip_end_of_options(&argc, &argv);
>
> if (check_rules_opts.rules_file && check_rules_opts.cone_mode < 0)
> check_rules_opts.cone_mode = 1;
> diff --git a/parse-options.c b/parse-options.c
> index d50962062e..fe265bbf68 100644
> --- a/parse-options.c
> +++ b/parse-options.c
> @@ -1321,3 +1321,11 @@ void die_for_incompatible_opt4(int opt1, const char *opt1_name,
> break;
> }
> }
> +
> +void parse_opt_skip_end_of_options(int *argc, const char ***argv)
> +{
> + if (*argc && !strcmp(**argv, "--end-of-options")) {
> + (*argc)--;
> + (*argv)++;
> + }
> +}
> diff --git a/parse-options.h b/parse-options.h
> index bd62e20268..0d3354d4a8 100644
> --- a/parse-options.h
> +++ b/parse-options.h
> @@ -498,6 +498,8 @@ int parse_opt_passthru_argv(const struct option *, const char *, int);
> /* value is enum branch_track* */
> int parse_opt_tracking_mode(const struct option *, const char *, int);
>
> +void parse_opt_skip_end_of_options(int *argc, const char ***argv);
> +
> #define OPT__VERBOSE(var, h) OPT_COUNTUP('v', "verbose", (var), (h))
> #define OPT__QUIET(var, h) OPT_COUNTUP('q', "quiet", (var), (h))
> #define OPT__VERBOSITY(var) { \
> diff --git a/t/t1090-sparse-checkout-scope.sh b/t/t1090-sparse-checkout-scope.sh
> index 3a14218b24..5b96716235 100755
> --- a/t/t1090-sparse-checkout-scope.sh
> +++ b/t/t1090-sparse-checkout-scope.sh
> @@ -57,6 +57,14 @@ test_expect_success 'return to full checkout of main' '
> test_expect_success 'skip-worktree on files outside sparse patterns' '
> git sparse-checkout disable &&
> git sparse-checkout set --no-cone "a*" &&
> + cat .git/info/sparse-checkout >wo-eoo &&
> +
> + git sparse-checkout disable &&
> + git sparse-checkout set --no-cone --end-of-options "a*" &&
> + cat .git/info/sparse-checkout >w-eoo &&
> +
> + test_cmp wo-eoo w-eoo &&
> +
> git checkout-index --all --ignore-skip-worktree-bits &&
>
> git ls-files -t >output &&
> diff --git a/t/t1091-sparse-checkout-builtin.sh b/t/t1091-sparse-checkout-builtin.sh
> index f67611da28..e33a6ed1b4 100755
> --- a/t/t1091-sparse-checkout-builtin.sh
> +++ b/t/t1091-sparse-checkout-builtin.sh
> @@ -334,7 +334,7 @@ test_expect_success 'cone mode: set with nested folders' '
>
> test_expect_success 'cone mode: add independent path' '
> git -C repo sparse-checkout set deep/deeper1 &&
> - git -C repo sparse-checkout add folder1 &&
> + git -C repo sparse-checkout add --end-of-options folder1 &&
> cat >expect <<-\EOF &&
> /*
> !/*/
> --
> 2.43.0-174-g055bb6e996
I've got a counter-proposal for this patch at
https://lore.kernel.org/git/pull.1625.git.git.1703379611749.gitgitgadget@gmail.com/,
based on further thread discussion over at
https://lore.kernel.org/git/CABPp-BF9XZeESHdxdcZ91Vsn5tKqQ6_3tC11e7t9vTFp=uufbg@mail.gmail.com/.
^ permalink raw reply
* Re: [PATCH 2/3] sparse-checkout: use default patterns for 'set' only !stdin
From: Elijah Newren @ 2023-12-24 7:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20231221065925.3234048-3-gitster@pobox.com>
On Wed, Dec 20, 2023 at 10:59 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> "git sparse-checkout set ---no-cone" uses default patterns when none
> is given from the command line, but it should do so ONLY when
> --stdin is not being used. Right now, add_patterns_from_input()
> called when reading from the standard input is sloppy and does not
> check if there are extra command line parameters that the command
> will silently ignore, but that will change soon and not setting this
> unnecessary and unused default patterns start to matter when it gets
> fixed.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> * This came from f2e3a218 (sparse-checkout: enable `set` to
> initialize sparse-checkout mode, 2021-12-14) by Elijah.
>
> builtin/sparse-checkout.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/sparse-checkout.c b/builtin/sparse-checkout.c
> index 8f55127202..04ae81fce8 100644
> --- a/builtin/sparse-checkout.c
> +++ b/builtin/sparse-checkout.c
> @@ -837,7 +837,7 @@ static int sparse_checkout_set(int argc, const char **argv, const char *prefix)
> * non-cone mode, if nothing is specified, manually select just the
> * top-level directory (much as 'init' would do).
> */
> - if (!core_sparse_checkout_cone && argc == 0) {
> + if (!core_sparse_checkout_cone && !set_opts.use_stdin && argc == 0) {
> argv = default_patterns;
> argc = default_patterns_nr;
> } else {
> --
> 2.43.0-174-g055bb6e996
Thanks for catching this; the fix looks good to me.
^ permalink raw reply
* Re: Git Rename Detection Bug
From: Elijah Newren @ 2023-12-24 7:46 UTC (permalink / raw)
To: Philip Oakley; +Cc: Jeremy Pridmore, git@vger.kernel.org, Paul Baumgartner
In-Reply-To: <990ab7d5-e29a-4766-b112-c8908a7ed196@iee.email>
Hi Philip,
Sorry for the late reply; I somehow missed this earlier.
On Wed, Nov 15, 2023 at 8:51 AM Philip Oakley <philipoakley@iee.email> wrote:
>
> Hi Elijah,
>
> On 11/11/2023 05:46, Elijah Newren wrote:
> > * filename similarity is extraordinarily expensive compared to exact
> > renames, and if not carefully handled, can sometimes rival the cost of
> > file content similarity computations given our spanhash
> > representations.
>
> I've not heard of spanhash representation before. Any references or
> further reading?
You can find more in diffcore-delta.c, especially the big comment near
the top of the file. But here's a short explanation of spanhashes:
* Split files into chunks delimited either by LF or 64 bytes,
whichever comes first.
* Hash every chunk into an integer between 0 and 107926
* Keep a character count for each of those integers as well (thus if
a line has N characters, but appears twice in the file, the associated
count for that integer will be 2N).
* A "spanhash" is the combination of the integer that a chunk (or
span) hashes to, plus the count associated with it.
* The list/array of spanhashes for a file (i.e. the list/array of
integers and character counts) is used to compare one file to another.
Now, why do I claim that comparison of filenames can rival cost of
file content similarity? Well, in a monorepo of interest, the median
sized file is named something close to
"modules/client-resources/src/main/resources/buttons/smallTriangleBlackRight.png"
and is 2875 bytes. As a png, all its chunks are probably the full 64
characters, which works out to about 45 chunks (assuming the 64-byte
chunks are different from each other). The filename is 79 characters.
So, for this case, 45 pairs of integers vs 79 characters. So, the
comparison cost is roughly the same order of magnitude.
(Yes, creating the spanhashes is a heavy overhead; however, we only
initialize it once and then do N comparisons of each spanhash to the
other spanhashes. And we'd be doing N comparisons of each filename to
other filenames, so the overhead of creating the spanhashes can be
overlooked if your merge has enough files modified on both sides of
history.)
Yes, this particular repository is a case I randomly picked that you
can argue is special. But rather than look at the particular example,
I think it's interesting to check how the spanhash size vs. filename
size scale with repository size. From my experience: (1) I don't
think the median-sized file varies all that much between small and big
repositories; every time I check a repo the median size seems to be
order of a few thousand bytes, regardless of whether the repository
I'm looking at is tiny or huge, (2) while small repositories often
have much shorter filenames, big repositories often will have
filenames even longer than my example; length of filename tends to
grow with repository size from deep directory nestings. So, between
these two facts, I'd expect the filename comparison costs to grow
relative to file content comparison costs, when considering only
median-sized files being modified. And since it's common to have
merges or rebases or diffs where only approximately-median-sized files
are involved, I think this is relevant to look at. Finally, since I
already had an example that showed the cost likely roughly comparable
for a random repository of interest, and it's not even all that big a
repository compared to many out there, I think the combination
motivates pretty well my claim that filename similarity costs _could_
rival file content similarity costs if one wasn't careful.
I don't have a rigorous proof here. And, in fact, I ended up doing
this rough back-of-the-envelope analysis _after_ implementing some
filename similarity comparison ideas and seeing performance degrade
badly, and wondering why it made such a difference. I don't know if I
ever got exact numbers, but I certainly didn't record them. This
rough analysis, though, was what made me realize that I needed to be
careful with any such added filename comparisons, though, and is why
I'm leery of adding more.
^ permalink raw reply
* Re: [PATCH] mem-pool: fix big allocations
From: Elijah Newren @ 2023-12-24 3:11 UTC (permalink / raw)
To: René Scharfe; +Cc: Git List, Jameson Miller
In-Reply-To: <fa89d269-1a23-4ed6-bebc-30c0b629f444@web.de>
On Thu, Dec 21, 2023 at 3:13 PM René Scharfe <l.s.r@web.de> wrote:
>
> Memory pool allocations that require a new block and would fill at
> least half of it are handled specially. Before 158dfeff3d (mem-pool:
> add life cycle management functions, 2018-07-02) they used to be
> allocated outside of the pool. This patch made mem_pool_alloc() create
> a bespoke block instead, to allow releasing it when the pool gets
> discarded.
>
> Unfortunately mem_pool_alloc() returns a pointer to the start of such a
> bespoke block, i.e. to the struct mp_block at its top. When the caller
> writes to it, the management information gets corrupted. This affects
> mem_pool_discard() and -- if there are no other blocks in the pool --
> also mem_pool_alloc().
>
> Return the payload pointer of bespoke blocks, just like for smaller
> allocations, to protect the management struct.
>
> Also update next_free to mark the block as full. This is only strictly
> necessary for the first allocated block, because subsequent ones are
> inserted after the current block and never considered for further
> allocations, but it's easier to just do it in all cases.
>
> Add a basic unit test to demonstate the issue by using mem_pool_calloc()
demonstrate (missing 'r')?
> with a tiny block size, which forces the creation of a bespoke block.
> Without the mem_pool_alloc() fix it reports zeroed pointers:
>
> ok 1 - mem_pool_calloc returns 100 zeroed bytes with big block
> # check "((pool->mp_block->next_free) != (((void*)0))) == 1" failed at t/unit-tests/t-mem-pool.c:22
> # left: 0
> # right: 1
> # check "((pool->mp_block->end) != (((void*)0))) == 1" failed at t/unit-tests/t-mem-pool.c:23
> # left: 0
> # right: 1
> not ok 2 - mem_pool_calloc returns 100 zeroed bytes with tiny block
> 1..2
>
> Signed-off-by: René Scharfe <l.s.r@web.de>
> ---
> Makefile | 1 +
> mem-pool.c | 6 +++---
> t/unit-tests/t-mem-pool.c | 34 ++++++++++++++++++++++++++++++++++
> 3 files changed, 38 insertions(+), 3 deletions(-)
> create mode 100644 t/unit-tests/t-mem-pool.c
>
> diff --git a/Makefile b/Makefile
> index 88ba7a3c51..15990ff312 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1340,6 +1340,7 @@ THIRD_PARTY_SOURCES += sha1collisiondetection/%
> THIRD_PARTY_SOURCES += sha1dc/%
>
> UNIT_TEST_PROGRAMS += t-basic
> +UNIT_TEST_PROGRAMS += t-mem-pool
> UNIT_TEST_PROGRAMS += t-strbuf
> UNIT_TEST_PROGS = $(patsubst %,$(UNIT_TEST_BIN)/%$X,$(UNIT_TEST_PROGRAMS))
> UNIT_TEST_OBJS = $(patsubst %,$(UNIT_TEST_DIR)/%.o,$(UNIT_TEST_PROGRAMS))
> diff --git a/mem-pool.c b/mem-pool.c
> index c34846d176..e8d976c3ee 100644
> --- a/mem-pool.c
> +++ b/mem-pool.c
> @@ -99,9 +99,9 @@ void *mem_pool_alloc(struct mem_pool *pool, size_t len)
>
> if (!p) {
> if (len >= (pool->block_alloc / 2))
> - return mem_pool_alloc_block(pool, len, pool->mp_block);
> -
> - p = mem_pool_alloc_block(pool, pool->block_alloc, NULL);
> + p = mem_pool_alloc_block(pool, len, pool->mp_block);
> + else
> + p = mem_pool_alloc_block(pool, pool->block_alloc, NULL);
> }
>
> r = p->next_free;
> diff --git a/t/unit-tests/t-mem-pool.c b/t/unit-tests/t-mem-pool.c
> new file mode 100644
> index 0000000000..2295779b0b
> --- /dev/null
> +++ b/t/unit-tests/t-mem-pool.c
> @@ -0,0 +1,34 @@
> +#include "test-lib.h"
> +#include "mem-pool.h"
> +
> +#define check_ptr(a, op, b) check_int(((a) op (b)), ==, 1)
> +
> +static void setup_static(void (*f)(struct mem_pool *), size_t block_alloc)
> +{
> + struct mem_pool pool = { .block_alloc = block_alloc };
> + f(&pool);
> + mem_pool_discard(&pool, 0);
> +}
> +
> +static void t_calloc_100(struct mem_pool *pool)
> +{
> + size_t size = 100;
> + char *buffer = mem_pool_calloc(pool, 1, size);
> + for (size_t i = 0; i < size; i++)
> + check_int(buffer[i], ==, 0);
> + if (!check_ptr(pool->mp_block, !=, NULL))
> + return;
> + check_ptr(pool->mp_block->next_free, <=, pool->mp_block->end);
> + check_ptr(pool->mp_block->next_free, !=, NULL);
> + check_ptr(pool->mp_block->end, !=, NULL);
> +}
> +
> +int cmd_main(int argc, const char **argv)
> +{
> + TEST(setup_static(t_calloc_100, 1024 * 1024),
> + "mem_pool_calloc returns 100 zeroed bytes with big block");
> + TEST(setup_static(t_calloc_100, 1),
> + "mem_pool_calloc returns 100 zeroed bytes with tiny block");
> +
> + return test_done();
> +}
> --
> 2.43.0
Nice catch; looks good to me. Out of curiosity, how'd you find the issue?
^ permalink raw reply
* Re: [PATCH/RFC] sparse-checkout: take care of "--end-of-options" in set/add
From: Elijah Newren @ 2023-12-24 1:02 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Josh Steadmon, git
In-Reply-To: <CABPp-BF9XZeESHdxdcZ91Vsn5tKqQ6_3tC11e7t9vTFp=uufbg@mail.gmail.com>
On Sat, Dec 23, 2023 at 2:45 PM Elijah Newren <newren@gmail.com> wrote:
>
> Hi,
>
> On Sat, Dec 23, 2023 at 2:02 AM Jeff King <peff@peff.net> wrote:
> >
> > On Thu, Dec 21, 2023 at 02:04:56PM -0800, Junio C Hamano wrote:
> >
> > > Jeff King <peff@peff.net> writes:
> > >
> > > > Right, that is the "gotcha" I mentioned in my other email. Though that
> > > > is the way it has behaved historically, my argument is that users are
> > > > unreasonable to expect it to work:
> > > >
> > > > 1. It is not consistent with the rest of Git commands.
> > > >
> > > > 2. It is inconsistent with respect to existing options (and is an
> > > > accident waiting to happen when new options are added).
> > > >
> > > > So I'd consider it a bug-fix.
> > >
> > > So the counter-proposal here is just to drop KEEP_UNKNOWN_OPT and
> > > deliberately break them^W^W^Wrealign their expectations?
> >
> > Yes. :) But keep in mind we are un-breaking other people, like those who
> > typo:
> >
> > git sparse-checkout --sikp-checks
> >
> > and don't see an error (instead, we make a garbage entry in the sparse
> > checkout file).
>
> I think you mean
> git sparse-checkout set --sikp-checks
> or
> git sparse-checkout add --sikp-checks
> (i.e. with either 'set' or 'add' in there)
>
> Neither of these are currently an error, but I agree both definitely
> ought to be. (Without the 'set' or 'add', you currently do get an
> error, as we'd expect.)
>
> > > I do not have much stake in sparse-checkout, so I am fine with that
> > > direction. But I suspect other folks on the list would have users
> > > of their own who would rather loudly complain to them if we broke
> > > them ;-)
> >
> > Likewise, I have never used sparse-checkout myself, and I don't care
> > _that_ much. My interest is mostly in having various Git commands behave
> > consistently. This whole discussion started because the centralized
> > --end-of-options fix interacted badly with this unusual behavior.
>
> Well, I care quite a bit about sparse-checkout, and I would rather see
> Peff's proposed fix, even if some users might have to tweak their
> commands a little.
And I wrote it up as a patch over at
https://lore.kernel.org/git/pull.1625.git.git.1703379611749.gitgitgadget@gmail.com/
^ permalink raw reply
* [PATCH] sparse-checkout: be consistent with end of options markers
From: Elijah Newren via GitGitGadget @ 2023-12-24 1:00 UTC (permalink / raw)
To: git; +Cc: Randall S. Becker, Jeff King, Elijah Newren, Elijah Newren
From: Elijah Newren <newren@gmail.com>
93851746 (parse-options: decouple "--end-of-options" and "--",
2023-12-06) updated the world order to make callers of parse-options
that set PARSE_OPT_KEEP_UNKNOWN_OPT responsible for deciding what to
do with "--end-of-options" they may see after parse_options() returns.
This made a previous bug in sparse-checkout more visible; namely,
that
git sparse-checkout [add|set] --[no-]cone --end-of-options ...
would simply treat "--end-of-options" as one of the paths to include in
the sparse-checkout. But this was already problematic before; namely,
git sparse-checkout [add|set| --[no-]cone --sikp-checks ...
would not give an error on the mis-typed "--skip-checks" but instead
simply treat "--sikp-checks" as a path or pattern to include in the
sparse-checkout, which is highly unfriendly.
This behavior begain when the command was converted to parse-options in
7bffca95ea (sparse-checkout: add '--stdin' option to set subcommand,
2019-11-21). Back then it was just called KEEP_UNKNOWN. Later it was
renamed to KEEP_UNKNOWN_OPT in 99d86d60e5 (parse-options:
PARSE_OPT_KEEP_UNKNOWN only applies to --options, 2022-08-19) to clarify
that it was only about dashed options; we always keep non-option
arguments. Looking at that original patch, both Peff and I think that
the author was simply confused about the mis-named option, and really
just wanted to keep the non-option arguments. We never should have used
the flag all along (and the other cases were cargo-culted within the
file).
Remove the erroneous PARSE_OPT_KEEP_UNKNOWN_OPT flag now to fix this
bug. Note that this does mean that anyone who might have been using
git sparse-checkout [add|set] [--[no-]cone] --foo --bar
to request paths or patterns '--foo' and '--bar' will now have to use
git sparse-checkout [add|set] [--[no-]cone] -- --foo --bar
That makes sparse-checkout more consistent with other git commands,
provides users much friendlier error messages and behavior, and is
consistent with the all-capps warning in git-sparse-checkout.txt that
this command "is experimental...its behavior...will likely change". :-)
Signed-off-by: Elijah Newren <newren@gmail.com>
---
[RFC] sparse-checkout: be consistent with end of options markers
Follow-up to thread over at
https://lore.kernel.org/git/CABPp-BF9XZeESHdxdcZ91Vsn5tKqQ6_3tC11e7t9vTFp=uufbg@mail.gmail.com/
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1625%2Fgitgitgadget%2Fsparse-checkout-end-of-options-consistency-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1625/gitgitgadget/sparse-checkout-end-of-options-consistency-v1
Pull-Request: https://github.com/git/git/pull/1625
builtin/sparse-checkout.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/builtin/sparse-checkout.c b/builtin/sparse-checkout.c
index 5c8ffb1f759..0e68e9b0b0d 100644
--- a/builtin/sparse-checkout.c
+++ b/builtin/sparse-checkout.c
@@ -777,8 +777,7 @@ static int sparse_checkout_add(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, prefix,
builtin_sparse_checkout_add_options,
- builtin_sparse_checkout_add_usage,
- PARSE_OPT_KEEP_UNKNOWN_OPT);
+ builtin_sparse_checkout_add_usage, 0);
sanitize_paths(argc, argv, prefix, add_opts.skip_checks);
@@ -824,8 +823,7 @@ static int sparse_checkout_set(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, prefix,
builtin_sparse_checkout_set_options,
- builtin_sparse_checkout_set_usage,
- PARSE_OPT_KEEP_UNKNOWN_OPT);
+ builtin_sparse_checkout_set_usage, 0);
if (update_modes(&set_opts.cone_mode, &set_opts.sparse_index))
return 1;
@@ -996,8 +994,7 @@ static int sparse_checkout_check_rules(int argc, const char **argv, const char *
argc = parse_options(argc, argv, prefix,
builtin_sparse_checkout_check_rules_options,
- builtin_sparse_checkout_check_rules_usage,
- PARSE_OPT_KEEP_UNKNOWN_OPT);
+ builtin_sparse_checkout_check_rules_usage, 0);
if (check_rules_opts.rules_file && check_rules_opts.cone_mode < 0)
check_rules_opts.cone_mode = 1;
base-commit: 055bb6e9969085777b7fab83e3fee0017654f134
--
gitgitgadget
^ permalink raw reply related
* Re: [PATCH/RFC] sparse-checkout: take care of "--end-of-options" in set/add
From: Elijah Newren @ 2023-12-23 22:45 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Josh Steadmon, git
In-Reply-To: <20231223100229.GA2016274@coredump.intra.peff.net>
Hi,
On Sat, Dec 23, 2023 at 2:02 AM Jeff King <peff@peff.net> wrote:
>
> On Thu, Dec 21, 2023 at 02:04:56PM -0800, Junio C Hamano wrote:
>
> > Jeff King <peff@peff.net> writes:
> >
> > > Right, that is the "gotcha" I mentioned in my other email. Though that
> > > is the way it has behaved historically, my argument is that users are
> > > unreasonable to expect it to work:
> > >
> > > 1. It is not consistent with the rest of Git commands.
> > >
> > > 2. It is inconsistent with respect to existing options (and is an
> > > accident waiting to happen when new options are added).
> > >
> > > So I'd consider it a bug-fix.
> >
> > So the counter-proposal here is just to drop KEEP_UNKNOWN_OPT and
> > deliberately break them^W^W^Wrealign their expectations?
>
> Yes. :) But keep in mind we are un-breaking other people, like those who
> typo:
>
> git sparse-checkout --sikp-checks
>
> and don't see an error (instead, we make a garbage entry in the sparse
> checkout file).
I think you mean
git sparse-checkout set --sikp-checks
or
git sparse-checkout add --sikp-checks
(i.e. with either 'set' or 'add' in there)
Neither of these are currently an error, but I agree both definitely
ought to be. (Without the 'set' or 'add', you currently do get an
error, as we'd expect.)
> > I do not have much stake in sparse-checkout, so I am fine with that
> > direction. But I suspect other folks on the list would have users
> > of their own who would rather loudly complain to them if we broke
> > them ;-)
>
> Likewise, I have never used sparse-checkout myself, and I don't care
> _that_ much. My interest is mostly in having various Git commands behave
> consistently. This whole discussion started because the centralized
> --end-of-options fix interacted badly with this unusual behavior.
Well, I care quite a bit about sparse-checkout, and I would rather see
Peff's proposed fix, even if some users might have to tweak their
commands a little.
Of course, I'm not the only sparse-checkout user representative, but
Randall commented elsewhere in this thread that he used
sparse-checkout quite a bit, and he feels that "without the --,
--sikp-checks should result in an error." In other words, he is
basically agreeing that taking Peff's fix seems more important than
strict backward compatibility here. (His wording may not sound like
that at first glance, probably because of the 'set'/'add' omission in
the example command, but I think what he said actually amounts to
agreeing with this change.)
Finally, git-sparse-checkout(1) does say "THIS COMMAND IS
EXPERIMENTAL. ITS BEHAVIOR...WILL LIKELY CHANGE". I apologize for
being pulled from my intent to work on [*], which I think would allow
us to finally drop this warning (I'll still get back to it, one way or
another...), but I think this is a good case where we should take
advantage of the existing warning and simply fix the command.
Anyway, just my $0.02,
Elijah
[*] https://lore.kernel.org/git/pull.1367.v4.git.1667714666810.gitgitgadget@gmail.com/
^ permalink raw reply
* Re: rebase invoking pre-commit
From: Elijah Newren @ 2023-12-23 21:37 UTC (permalink / raw)
To: Sean Allred; +Cc: Git List
In-Reply-To: <m0sf3vi86g.fsf@epic96565.epic.com>
On Thu, Dec 21, 2023 at 12:59 PM Sean Allred <allred.sean@gmail.com> wrote:
>
> Is there a current reason why pre-commit shouldn't be invoked during
> rebase, or is this just waiting for a reviewable patch?
>
> This was brought up before at [1] in 2015, but that thread so old at
> this point that it seemed prudent to double-check before investing time
> in a developing and testing a patch.
>
> [1]: https://lore.kernel.org/git/1m55i3m.1fum4zo1fpnhncM%25lists@haller-berlin.de/
I'm very opinionated here. I'm just one person, so definitely take
this with a grain of salt, but in my view...
Personally, I think implementing any per-commit hook in rebase by
default is a mistake. It enforces a
must-be-in-a-worktree-and-the-worktree-must-be-updated-with-every-replayed-commit
mindset, which I find highly problematic[2], even if that's "what we
always used to do". Because of that, I would prefer to see this at
most be a command line flag. However, we've already got a command
line flag that while not identical, is essentially equivalent: "--exec
$MY_SCRIPT" (it's not the same because it's a post-commit check, but
you get notification of any problematic commits, and an immediate stop
of the rebase for you to fix up the problematic commit; fixing up the
commit shouldn't be problematic since you are, after all, already
rebasing).
I see Phillip already responded and suggested not running the
pre-commit hook with every commit, but only upon the first commit
after a "git rebase --continue". That seems far more reasonable to me
than running on every commit...though even that worries me in regards
to what assumptions that entails about what is present in the working
tree. (For example, what about folks with large repositories, so
large that a branch switch or full checkout is extremely costly, and
which could benefit from resolving conflicts in a separate
sparse-checkout worktree, potentially much more sparse than their main
checkout? And what if people like that really fast rebase resolution
(namely, done in a separate very sparse checkout which also has the
advantage of not polluting your current working tree) so much that
they use it on smaller repositories as well? Can I not even
experiment with this idea because of the historical
per-commit-at-least-as-full-as-main-worktree-checkout assumptions
we've baked into rebase?)
While at it, I should also mention that I'm not a fan of the broken
pre-rebase hook; its design ties us to doing a single branch at a
time. Maybe that hook is not quite as bad, though, since we already
broke that hook and no one seemed to care (in particular, when
--update-refs was implemented). But if no one seems to care about
broken hooks, I think the proper answer is to either get rid of the
hook or fix it.
Anyway, as I mentioned, I'm quite opinionated here. To the point that
I deemed git-rebase in its current form to possibly be unfixable
(after first putting a lot of work into improving it over the past
years) and eventually introduced a new "git-replay" command which I
hope to make into a competent replacement for it. Given that I do
have another command to do my experiments, others on the list may
think it's fine to send rebase further down this route, but I was
hoping to avoid further drift so that there might be some way of
re-implementing rebase on top of my "git-replay" ideas/design.
Just my $0.02,
Elijah
[2] https://lore.kernel.org/git/20231124111044.3426007-1-christian.couder@gmail.com/
^ permalink raw reply
* [PATCH v2 12/12] treewide: remove unnecessary includes in source files
From: Elijah Newren via GitGitGadget @ 2023-12-23 17:15 UTC (permalink / raw)
To: git; +Cc: Elijah Newren, Elijah Newren, Elijah Newren
In-Reply-To: <pull.1617.v2.git.1703351700.gitgitgadget@gmail.com>
From: Elijah Newren <newren@gmail.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
---
builtin/archive.c | 1 -
builtin/commit-graph.c | 1 -
builtin/fsck.c | 1 -
builtin/fsmonitor--daemon.c | 2 --
builtin/grep.c | 1 -
builtin/mktag.c | 1 -
builtin/rev-list.c | 1 -
builtin/send-pack.c | 1 -
commit-graph.c | 1 -
compat/simple-ipc/ipc-shared.c | 3 ---
compat/simple-ipc/ipc-unix-socket.c | 1 -
fsmonitor-ipc.c | 1 -
http.c | 1 -
line-log.c | 1 -
merge-ort.c | 1 -
notes-utils.c | 1 -
ref-filter.c | 1 -
remote-curl.c | 1 -
repo-settings.c | 1 -
t/helper/test-repository.c | 1 -
trace2/tr2_ctr.c | 1 -
trace2/tr2_tmr.c | 1 -
22 files changed, 25 deletions(-)
diff --git a/builtin/archive.c b/builtin/archive.c
index 90761fdfee0..15ee1ec7bb7 100644
--- a/builtin/archive.c
+++ b/builtin/archive.c
@@ -9,7 +9,6 @@
#include "parse-options.h"
#include "pkt-line.h"
#include "repository.h"
-#include "sideband.h"
static void create_output_file(const char *output_file)
{
diff --git a/builtin/commit-graph.c b/builtin/commit-graph.c
index 81a28c6fcdd..666ad574a46 100644
--- a/builtin/commit-graph.c
+++ b/builtin/commit-graph.c
@@ -4,7 +4,6 @@
#include "environment.h"
#include "gettext.h"
#include "hex.h"
-#include "lockfile.h"
#include "parse-options.h"
#include "repository.h"
#include "commit-graph.h"
diff --git a/builtin/fsck.c b/builtin/fsck.c
index 9317b7b841d..a7cf94f67ed 100644
--- a/builtin/fsck.c
+++ b/builtin/fsck.c
@@ -10,7 +10,6 @@
#include "refs.h"
#include "pack.h"
#include "cache-tree.h"
-#include "tree-walk.h"
#include "fsck.h"
#include "parse-options.h"
#include "progress.h"
diff --git a/builtin/fsmonitor--daemon.c b/builtin/fsmonitor--daemon.c
index 9f80b9eaff5..1593713f4cb 100644
--- a/builtin/fsmonitor--daemon.c
+++ b/builtin/fsmonitor--daemon.c
@@ -7,7 +7,6 @@
#include "parse-options.h"
#include "fsmonitor-ll.h"
#include "fsmonitor-ipc.h"
-#include "fsmonitor-path-utils.h"
#include "fsmonitor-settings.h"
#include "compat/fsmonitor/fsm-health.h"
#include "compat/fsmonitor/fsm-listen.h"
@@ -15,7 +14,6 @@
#include "repository.h"
#include "simple-ipc.h"
#include "khash.h"
-#include "pkt-line.h"
#include "run-command.h"
#include "trace.h"
#include "trace2.h"
diff --git a/builtin/grep.c b/builtin/grep.c
index f076cc705b4..c8e33f97755 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -14,7 +14,6 @@
#include "parse-options.h"
#include "string-list.h"
#include "run-command.h"
-#include "userdiff.h"
#include "grep.h"
#include "quote.h"
#include "dir.h"
diff --git a/builtin/mktag.c b/builtin/mktag.c
index d8e0b5afc07..4767f1a97e6 100644
--- a/builtin/mktag.c
+++ b/builtin/mktag.c
@@ -3,7 +3,6 @@
#include "hex.h"
#include "parse-options.h"
#include "strbuf.h"
-#include "tag.h"
#include "replace-object.h"
#include "object-file.h"
#include "object-store-ll.h"
diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index 460ba7cbaa7..b3f47838580 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -12,7 +12,6 @@
#include "object-name.h"
#include "object-file.h"
#include "object-store-ll.h"
-#include "pack.h"
#include "pack-bitmap.h"
#include "log-tree.h"
#include "graph.h"
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index 395f2e490d4..0b839f583a0 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -2,7 +2,6 @@
#include "config.h"
#include "hex.h"
#include "pkt-line.h"
-#include "sideband.h"
#include "run-command.h"
#include "remote.h"
#include "connect.h"
diff --git a/commit-graph.c b/commit-graph.c
index e7212400da3..15980cf9492 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -4,7 +4,6 @@
#include "gettext.h"
#include "hex.h"
#include "lockfile.h"
-#include "pack.h"
#include "packfile.h"
#include "commit.h"
#include "object.h"
diff --git a/compat/simple-ipc/ipc-shared.c b/compat/simple-ipc/ipc-shared.c
index e5e1dda8ccd..cb176d966f2 100644
--- a/compat/simple-ipc/ipc-shared.c
+++ b/compat/simple-ipc/ipc-shared.c
@@ -1,8 +1,5 @@
#include "git-compat-util.h"
#include "simple-ipc.h"
-#include "strbuf.h"
-#include "pkt-line.h"
-#include "thread-utils.h"
#ifndef SUPPORTS_SIMPLE_IPC
/*
diff --git a/compat/simple-ipc/ipc-unix-socket.c b/compat/simple-ipc/ipc-unix-socket.c
index b2f4f22ce44..9b3f2cdf8c9 100644
--- a/compat/simple-ipc/ipc-unix-socket.c
+++ b/compat/simple-ipc/ipc-unix-socket.c
@@ -2,7 +2,6 @@
#include "gettext.h"
#include "simple-ipc.h"
#include "strbuf.h"
-#include "pkt-line.h"
#include "thread-utils.h"
#include "trace2.h"
#include "unix-socket.h"
diff --git a/fsmonitor-ipc.c b/fsmonitor-ipc.c
index 153918cf768..45471b5b741 100644
--- a/fsmonitor-ipc.c
+++ b/fsmonitor-ipc.c
@@ -1,5 +1,4 @@
#include "git-compat-util.h"
-#include "fsmonitor-ll.h"
#include "gettext.h"
#include "simple-ipc.h"
#include "fsmonitor-ipc.h"
diff --git a/http.c b/http.c
index a64005ceb80..3565c4ec611 100644
--- a/http.c
+++ b/http.c
@@ -4,7 +4,6 @@
#include "http.h"
#include "config.h"
#include "pack.h"
-#include "sideband.h"
#include "run-command.h"
#include "url.h"
#include "urlmatch.h"
diff --git a/line-log.c b/line-log.c
index c276ccec549..8ff6ccb7724 100644
--- a/line-log.c
+++ b/line-log.c
@@ -12,7 +12,6 @@
#include "xdiff-interface.h"
#include "strbuf.h"
#include "log-tree.h"
-#include "userdiff.h"
#include "line-log.h"
#include "setup.h"
#include "strvec.h"
diff --git a/merge-ort.c b/merge-ort.c
index 2a0be468505..77ba7f3020c 100644
--- a/merge-ort.c
+++ b/merge-ort.c
@@ -41,7 +41,6 @@
#include "revision.h"
#include "sparse-index.h"
#include "strmap.h"
-#include "submodule.h"
#include "trace2.h"
#include "tree.h"
#include "unpack-trees.h"
diff --git a/notes-utils.c b/notes-utils.c
index 97c031c26ec..08e5dbc6073 100644
--- a/notes-utils.c
+++ b/notes-utils.c
@@ -5,7 +5,6 @@
#include "gettext.h"
#include "refs.h"
#include "notes-utils.h"
-#include "repository.h"
#include "strbuf.h"
void create_notes_commit(struct repository *r,
diff --git a/ref-filter.c b/ref-filter.c
index 96959a3762c..01b90e325c2 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -29,7 +29,6 @@
#include "commit-reach.h"
#include "worktree.h"
#include "hashmap.h"
-#include "strvec.h"
static struct ref_msg {
const char *gone;
diff --git a/remote-curl.c b/remote-curl.c
index 55eefa70f97..7f81bf3fafc 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -11,7 +11,6 @@
#include "run-command.h"
#include "pkt-line.h"
#include "string-list.h"
-#include "sideband.h"
#include "strvec.h"
#include "credential.h"
#include "oid-array.h"
diff --git a/repo-settings.c b/repo-settings.c
index 525f69c0c77..30cd4787627 100644
--- a/repo-settings.c
+++ b/repo-settings.c
@@ -2,7 +2,6 @@
#include "config.h"
#include "repository.h"
#include "midx.h"
-#include "compat/fsmonitor/fsm-listen.h"
static void repo_cfg_bool(struct repository *r, const char *key, int *dest,
int def)
diff --git a/t/helper/test-repository.c b/t/helper/test-repository.c
index c925655c648..0c7c5aa4dd7 100644
--- a/t/helper/test-repository.c
+++ b/t/helper/test-repository.c
@@ -3,7 +3,6 @@
#include "commit.h"
#include "environment.h"
#include "hex.h"
-#include "object-store-ll.h"
#include "object.h"
#include "repository.h"
#include "setup.h"
diff --git a/trace2/tr2_ctr.c b/trace2/tr2_ctr.c
index 87cf9034fba..d3a33715c14 100644
--- a/trace2/tr2_ctr.c
+++ b/trace2/tr2_ctr.c
@@ -1,5 +1,4 @@
#include "git-compat-util.h"
-#include "thread-utils.h"
#include "trace2/tr2_tgt.h"
#include "trace2/tr2_tls.h"
#include "trace2/tr2_ctr.h"
diff --git a/trace2/tr2_tmr.c b/trace2/tr2_tmr.c
index 31d0e4d1bd1..51f564b07a4 100644
--- a/trace2/tr2_tmr.c
+++ b/trace2/tr2_tmr.c
@@ -1,5 +1,4 @@
#include "git-compat-util.h"
-#include "thread-utils.h"
#include "trace2/tr2_tgt.h"
#include "trace2/tr2_tls.h"
#include "trace2/tr2_tmr.h"
--
gitgitgadget
^ permalink raw reply related
* [PATCH v2 11/12] treewide: add direct includes currently only pulled in transitively
From: Elijah Newren via GitGitGadget @ 2023-12-23 17:14 UTC (permalink / raw)
To: git; +Cc: Elijah Newren, Elijah Newren, Elijah Newren
In-Reply-To: <pull.1617.v2.git.1703351700.gitgitgadget@gmail.com>
From: Elijah Newren <newren@gmail.com>
The next commit will remove a bunch of unnecessary includes, but to do
so, we need some of the lower level direct includes that files rely on
to be explicitly specified.
Signed-off-by: Elijah Newren <newren@gmail.com>
---
builtin/commit-graph.c | 1 +
builtin/for-each-ref.c | 1 +
builtin/fsmonitor--daemon.c | 1 +
commit-graph.c | 1 +
4 files changed, 4 insertions(+)
diff --git a/builtin/commit-graph.c b/builtin/commit-graph.c
index c5684342ecf..81a28c6fcdd 100644
--- a/builtin/commit-graph.c
+++ b/builtin/commit-graph.c
@@ -11,6 +11,7 @@
#include "object-store-ll.h"
#include "progress.h"
#include "replace-object.h"
+#include "strbuf.h"
#include "tag.h"
#include "trace2.h"
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 6235d72f9d3..b5bc700d13c 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -1,4 +1,5 @@
#include "builtin.h"
+#include "commit.h"
#include "config.h"
#include "gettext.h"
#include "object.h"
diff --git a/builtin/fsmonitor--daemon.c b/builtin/fsmonitor--daemon.c
index 7260604534f..9f80b9eaff5 100644
--- a/builtin/fsmonitor--daemon.c
+++ b/builtin/fsmonitor--daemon.c
@@ -12,6 +12,7 @@
#include "compat/fsmonitor/fsm-health.h"
#include "compat/fsmonitor/fsm-listen.h"
#include "fsmonitor--daemon.h"
+#include "repository.h"
#include "simple-ipc.h"
#include "khash.h"
#include "pkt-line.h"
diff --git a/commit-graph.c b/commit-graph.c
index 5bfee53e87b..e7212400da3 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -1,5 +1,6 @@
#include "git-compat-util.h"
#include "config.h"
+#include "csum-file.h"
#include "gettext.h"
#include "hex.h"
#include "lockfile.h"
--
gitgitgadget
^ permalink raw reply related
* [PATCH v2 10/12] trace2/tr2_tls.h: remove unnecessary include
From: Elijah Newren via GitGitGadget @ 2023-12-23 17:14 UTC (permalink / raw)
To: git; +Cc: Elijah Newren, Elijah Newren, Elijah Newren
In-Reply-To: <pull.1617.v2.git.1703351700.gitgitgadget@gmail.com>
From: Elijah Newren <newren@gmail.com>
The unnecessary include in the header transitively pulled in some
other headers actually needed by source files, though. Have those
source files explicitly include the headers they need.
Signed-off-by: Elijah Newren <newren@gmail.com>
---
trace2/tr2_tgt_normal.c | 1 +
trace2/tr2_tls.c | 1 +
trace2/tr2_tls.h | 1 -
3 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/trace2/tr2_tgt_normal.c b/trace2/tr2_tgt_normal.c
index 38d5ebddf65..baef48aa698 100644
--- a/trace2/tr2_tgt_normal.c
+++ b/trace2/tr2_tgt_normal.c
@@ -2,6 +2,7 @@
#include "config.h"
#include "repository.h"
#include "run-command.h"
+#include "strbuf.h"
#include "quote.h"
#include "version.h"
#include "trace2/tr2_dst.h"
diff --git a/trace2/tr2_tls.c b/trace2/tr2_tls.c
index 601c9e5036f..4f75392952b 100644
--- a/trace2/tr2_tls.c
+++ b/trace2/tr2_tls.c
@@ -1,4 +1,5 @@
#include "git-compat-util.h"
+#include "strbuf.h"
#include "thread-utils.h"
#include "trace.h"
#include "trace2/tr2_tls.h"
diff --git a/trace2/tr2_tls.h b/trace2/tr2_tls.h
index f9049805d4d..3dfe6557fc4 100644
--- a/trace2/tr2_tls.h
+++ b/trace2/tr2_tls.h
@@ -1,7 +1,6 @@
#ifndef TR2_TLS_H
#define TR2_TLS_H
-#include "strbuf.h"
#include "trace2/tr2_ctr.h"
#include "trace2/tr2_tmr.h"
--
gitgitgadget
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox