* Re: bug - Inconsistency of git status and branch, ./git/branches and ./git/HEAD
From: Chris Torek @ 2023-09-30 11:32 UTC (permalink / raw)
To: Irina Gulina; +Cc: git, Tomas Tomecek
In-Reply-To: <CAPx1GvcjvctrQ-w1MekBs7S+R_7=KhCLUQ915-JAnxEq=BE3iQ@mail.gmail.com>
I should note a slight correction here:
On Sat, Sep 30, 2023 at 4:28 AM Chris Torek <chris.torek@gmail.com> wrote:
> A new, empty repository cannot have any branches, because a branch
> is defined as "the latest commit that is on the branch" (this definition is
> unsatisfyingly circular, but that too is what it is).
This is just one of multiple definitions of "branch" in Git. A branch is also
a *set* of commits, and/or a *name*. The fact that the word "branch" has
so many meanings in Git makes it almost meaningless: it's like being at
a party where everyone is named Chris. Yet somehow we humans still
manage to extract meaning from a sentence like "Hey Chris, Chris said
to tell you that Chris can't get Chris's car started, so Chris and Chris
won't be here."
Chris
^ permalink raw reply
* Re: bug - Inconsistency of git status and branch, ./git/branches and ./git/HEAD
From: Chris Torek @ 2023-09-30 11:28 UTC (permalink / raw)
To: Irina Gulina; +Cc: git, Tomas Tomecek
In-Reply-To: <CAAcHogVu+jrLdtEZi+Jx9d9gM5BvUF_nRVKEc4BsWCxCanL9Uw@mail.gmail.com>
On Sat, Sep 30, 2023 at 4:06 AM Irina Gulina <igulina@redhat.com> wrote:
> ... So the question is why 'git
> status' says "On branch master", but 'git branches' don't?
Although this seems weird, it is in fact normal.
This situation in Git -- where you are on a branch that does not exist --
is called an "orphan branch" or an "unborn branch" (which term is used
depends on which bit of documentation you read).
The unborn / orphan current branch becomes "born" (begins to exist)
once you make a commit while on it. If you move to a different branch,
the unborn branch never comes into existence.
A new, empty repository cannot have any branches, because a branch
is defined as "the latest commit that is on the branch" (this definition is
unsatisfyingly circular, but that too is what it is). With no commits in the
repository, no branches can exist. Yet you must be "on" some branch.
Hence the existence of unborn branches, which are born when you
make a new commit. That first commit creates the first branch name
as well as the first commit.
Creating a new commit while on an unborn branch causes the new
commit to have no parent commit. This, too, is normal and natural
in a new empty repository, but it holds true for the situation in which
you create a new unborn / orphan branch using `git checkout --orphan`
or `git switch --orphan` while in a non-empty repository. You don't
normally want to do this, but it's sometimes useful for some special
oddball cases.
Chris
^ permalink raw reply
* Re: bug - Inconsistency of git status and branch, ./git/branches and ./git/HEAD
From: Irina Gulina @ 2023-09-30 7:03 UTC (permalink / raw)
To: git; +Cc: Tomas Tomecek
In-Reply-To: <CAAcHogVu+jrLdtEZi+Jx9d9gM5BvUF_nRVKEc4BsWCxCanL9Uw@mail.gmail.com>
apologies for a typo: all paths written with ./git, meant to be .git
On Sat, Sep 30, 2023 at 8:51 AM Irina Gulina <igulina@redhat.com> wrote:
>
> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
>
> What did you do before the bug happened? (Steps to reproduce your issue)
> 1. create an empty directory in CLI: mkdir test_repo
> 2. convert it to a git directory: cd test_repo & git init
> 3. 'git status' will say you are "On branch master"
> 4. 'git branch', 'git branch --all', or 'git branch --list' - nothing
> will say the master branch exists. And per man pages definition the
> branch command displays existing branches. So the question is why 'git
> status' says "On branch master", but 'git branches' don't?
> 5. check on 'ls -la ./git/branches' - it's empty
> 6. check on 'ls -la ./git/refs/heads' - it's empty
> 7. check on 'cat ./git/HEAD' - it shows 'ref: refs/heads/master' -
> why? if we didn't create any commit, and no branch exists?
>
> What did you expect to happen? (Expected behavior)
> git status should not say "On branch master", cat ./git/HEAD should be
> empty. Or the master branch should be created in ./git/branches and
> the 'git branch' command should display it.
>
> What happened instead? (Actual behavior)
> Inconsistency between 'git status', 'git branch', ./git/branches and ./git/HEAD
>
> What's different between what you expected and what actually happened?
>
> Anything else you want to add:
>
> Please review the rest of the bug report below.
> You can delete any lines you don't wish to share.
>
>
> [System Info]
> git version:
> git version 2.41.0
> cpu: x86_64
> no commit associated with this build
> sizeof-long: 8
> sizeof-size_t: 8
> shell-path: /bin/sh
> uname: Linux 6.4.12-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Aug 23
> 17:46:49 UTC 2023 x86_64
> compiler info: gnuc: 13.1
> libc info: glibc: 2.37
> $SHELL (typically, interactive shell): /bin/bash
>
>
> [Enabled Hooks]
^ permalink raw reply
* bug - Inconsistency of git status and branch, ./git/branches and ./git/HEAD
From: Irina Gulina @ 2023-09-30 6:51 UTC (permalink / raw)
To: git; +Cc: Tomas Tomecek
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
1. create an empty directory in CLI: mkdir test_repo
2. convert it to a git directory: cd test_repo & git init
3. 'git status' will say you are "On branch master"
4. 'git branch', 'git branch --all', or 'git branch --list' - nothing
will say the master branch exists. And per man pages definition the
branch command displays existing branches. So the question is why 'git
status' says "On branch master", but 'git branches' don't?
5. check on 'ls -la ./git/branches' - it's empty
6. check on 'ls -la ./git/refs/heads' - it's empty
7. check on 'cat ./git/HEAD' - it shows 'ref: refs/heads/master' -
why? if we didn't create any commit, and no branch exists?
What did you expect to happen? (Expected behavior)
git status should not say "On branch master", cat ./git/HEAD should be
empty. Or the master branch should be created in ./git/branches and
the 'git branch' command should display it.
What happened instead? (Actual behavior)
Inconsistency between 'git status', 'git branch', ./git/branches and ./git/HEAD
What's different between what you expected and what actually happened?
Anything else you want to add:
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
[System Info]
git version:
git version 2.41.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 6.4.12-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Aug 23
17:46:49 UTC 2023 x86_64
compiler info: gnuc: 13.1
libc info: glibc: 2.37
$SHELL (typically, interactive shell): /bin/bash
[Enabled Hooks]
^ permalink raw reply
* Re: git grep performance regression on macOS
From: Junio C Hamano @ 2023-09-30 5:45 UTC (permalink / raw)
To: Benjamin Hiller; +Cc: git
In-Reply-To: <CAPWWTaDE5559vA1qa0zhBid_ep9ht+PxPSDS5YC7Dk0NN8sp9A@mail.gmail.com>
Benjamin Hiller <benhiller@gmail.com> writes:
> git grep seems to have gotten much slower as of git 2.39 on macOS for
> complex extended regexes.
> I confirmed that the performance regression was first introduced in
> 2.39. Additionally, I saw that reverting the change to Makefile from
> https://github.com/git/git/commit/1819ad327b7a1f19540a819813b70a0e8a7f798f
> fixed the performance regression and the git grep command went back to
> taking <1 second. That seems to indicate that switching from Git's
> regex library to the native macOS regex library caused this
> performance regression, but I haven't investigated beyond that to see
> why the native macOS regex library is so much slower.
Yeah, that does sound a plausible explanation.
The regexp code in compat/ is meant as a fallback implementation for
platforms whose regexp library lack certain features we take
advantage of, but it has a limitation that it is not unicode aware.
In the olden days, regexp library on macOS lacked REG_STARTEND
feature, which forced us to use NO_REGEX (hence the fallback
implementation we ship that is not unicode aware). The commit you
cite makes us use the macOS native regexp library, as somebody on
the platform got annoyed enough by the lack of unicode awareness of
the fallback implementation, and also noticed that REG_STARTEND is
supported by the macOS native regexp library these days.
The change in 2.39 was unfortunately about correctness. It would
have been nicer if macOS native implementation were faster, but use
of fallback implementation would be favoring "performance" (which
produces incorrect results "faster" when run with multi-byte
strings) over correctness, so it is not likely that a straight
reverting of the commit is a good idea.
^ permalink raw reply
* git grep performance regression on macOS
From: Benjamin Hiller @ 2023-09-29 23:56 UTC (permalink / raw)
To: git
What did you do before the bug happened? (Steps to reproduce your issue)
git grep seems to have gotten much slower as of git 2.39 on macOS for
complex extended regexes.
We noticed this because git secrets --scan was running much more
slowly for some people on our team, and eventually realized that it
was due to them using a newer version of git. git secrets runs a git
grep command with an extended regex (this is a somewhat simplified
version of the command, but still shows the performance issue):
git grep -E "(A3T[A-Z0-9]|AKIA|AGPA|AIDA|AROA|AIPA|ANPA|ANVA|ASIA)[A-Z0-9]{16}|(\"|')?(AWS|aws|Aws)?_?(SECRET|secret|Secret)?_?(ACCESS|access|Access)?_?(KEY|key|Key)(\"|')?\s*(:|=>|=)\s*(\"|')?[A-Za-z0-9/\+=]{40}(\"|')?|(\"|')?(AWS|aws|Aws)?_?(ACCOUNT|account|Account)_?(ID|id|Id)?(\"|')?\s*(:|=>|=)\s*(\"|')?[0-9]{4}\-?[0-9]{4}\-?[0-9]{4}(\"|')?"
What did you expect to happen? (Expected behavior)
With git 2.38, that command took under half a second to run on a large repo.
Using the git (https://github.com/git/git) repo as an example, it took
0.2s on my laptop.
What happened instead? (Actual behavior)
After 2.39, it now takes over 40 seconds on my laptop with the git repo!
What's different between what you expected and what actually happened?
The command runs much more slowly, though it still does return the
correct result.
Anything else you want to add:
I confirmed that the performance regression was first introduced in
2.39. Additionally, I saw that reverting the change to Makefile from
https://github.com/git/git/commit/1819ad327b7a1f19540a819813b70a0e8a7f798f
fixed the performance regression and the git grep command went back to
taking <1 second. That seems to indicate that switching from Git's
regex library to the native macOS regex library caused this
performance regression, but I haven't investigated beyond that to see
why the native macOS regex library is so much slower.
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
[System Info]
git version:
git version 2.42.0
cpu: arm64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 22.4.0 Darwin Kernel Version 22.4.0: Mon Mar 6 21:00:41
PST 2023; root:xnu-8796.101.5~3/RELEASE_ARM64_T8103 arm64
compiler info: clang: 14.0.3 (clang-1403.0.22.14.1)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh
[Enabled Hooks]
post-checkout
post-merge
pre-commit
pre-push
^ permalink raw reply
* Re: [PATCH v4 3/4] config: correct bad boolean env value error message
From: Junio C Hamano @ 2023-09-29 23:03 UTC (permalink / raw)
To: Jonathan Tan; +Cc: git, Calvin Wan, phillip.wood123
In-Reply-To: <e4c20a81f93e2a4e2ad65920920ead690b162e25.1696021277.git.jonathantanmy@google.com>
Jonathan Tan <jonathantanmy@google.com> writes:
> From: Calvin Wan <calvinwan@google.com>
>
> An incorrectly defined boolean environment value would result in the
> following error message:
>
> bad boolean config value '%s' for '%s'
>
> This is a misnomer since environment value != config value. Instead of
> calling git_config_bool() to parse the environment value, mimic the
> functionality inside of git_config_bool() but with the correct error
> message.
>
> Signed-off-by: Calvin Wan <calvinwan@google.com>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> config.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
Makes sense.
I briefly wondered if there are ways to share more code, but this
seems to be the best we can do. The duplication is not too bad to
begin with anyway.
Looking good. Will queue.
> diff --git a/config.c b/config.c
> index 3846a37be9..7dde0aaa02 100644
> --- a/config.c
> +++ b/config.c
> @@ -2133,7 +2133,14 @@ void git_global_config(char **user_out, char **xdg_out)
> int git_env_bool(const char *k, int def)
> {
> const char *v = getenv(k);
> - return v ? git_config_bool(k, v) : def;
> + int val;
> + if (!v)
> + return def;
> + val = git_parse_maybe_bool(v);
> + if (val < 0)
> + die(_("bad boolean environment value '%s' for '%s'"),
> + v, k);
> + return val;
> }
>
> /*
^ permalink raw reply
* [PATCH v4 4/4] parse: separate out parsing functions from config.h
From: Jonathan Tan @ 2023-09-29 21:20 UTC (permalink / raw)
To: git; +Cc: Calvin Wan, phillip.wood123, Junio C Hamano, Jonathan Tan
In-Reply-To: <cover.1696021277.git.jonathantanmy@google.com>
From: Calvin Wan <calvinwan@google.com>
The files config.{h,c} contain functions that have to do with parsing,
but not config.
In order to further reduce all-in-one headers, separate out functions in
config.c that do not operate on config into its own file, parse.h,
and update the include directives in the .c files that need only such
functions accordingly.
Signed-off-by: Calvin Wan <calvinwan@google.com>
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
---
Makefile | 1 +
attr.c | 2 +-
config.c | 180 +-----------------------------------
config.h | 14 +--
pack-objects.c | 2 +-
pack-revindex.c | 2 +-
parse-options.c | 3 +-
parse.c | 182 +++++++++++++++++++++++++++++++++++++
parse.h | 20 ++++
pathspec.c | 2 +-
preload-index.c | 2 +-
progress.c | 2 +-
prompt.c | 2 +-
rebase.c | 2 +-
t/helper/test-env-helper.c | 2 +-
unpack-trees.c | 2 +-
wrapper.c | 2 +-
write-or-die.c | 2 +-
18 files changed, 219 insertions(+), 205 deletions(-)
create mode 100644 parse.c
create mode 100644 parse.h
diff --git a/Makefile b/Makefile
index 861e643708..9226c719a0 100644
--- a/Makefile
+++ b/Makefile
@@ -1091,6 +1091,7 @@ LIB_OBJS += pack-write.o
LIB_OBJS += packfile.o
LIB_OBJS += pager.o
LIB_OBJS += parallel-checkout.o
+LIB_OBJS += parse.o
LIB_OBJS += parse-options-cb.o
LIB_OBJS += parse-options.o
LIB_OBJS += patch-delta.o
diff --git a/attr.c b/attr.c
index 71c84fbcf8..3c0b4fb3d9 100644
--- a/attr.c
+++ b/attr.c
@@ -7,7 +7,7 @@
*/
#include "git-compat-util.h"
-#include "config.h"
+#include "parse.h"
#include "environment.h"
#include "exec-cmd.h"
#include "attr.h"
diff --git a/config.c b/config.c
index 7dde0aaa02..c7bc21a25d 100644
--- a/config.c
+++ b/config.c
@@ -11,6 +11,7 @@
#include "date.h"
#include "branch.h"
#include "config.h"
+#include "parse.h"
#include "convert.h"
#include "environment.h"
#include "gettext.h"
@@ -1165,129 +1166,6 @@ static int git_parse_source(struct config_source *cs, config_fn_t fn,
return error_return;
}
-static uintmax_t get_unit_factor(const char *end)
-{
- if (!*end)
- return 1;
- else if (!strcasecmp(end, "k"))
- return 1024;
- else if (!strcasecmp(end, "m"))
- return 1024 * 1024;
- else if (!strcasecmp(end, "g"))
- return 1024 * 1024 * 1024;
- return 0;
-}
-
-static int git_parse_signed(const char *value, intmax_t *ret, intmax_t max)
-{
- if (value && *value) {
- char *end;
- intmax_t val;
- intmax_t factor;
-
- if (max < 0)
- BUG("max must be a positive integer");
-
- errno = 0;
- val = strtoimax(value, &end, 0);
- if (errno == ERANGE)
- return 0;
- if (end == value) {
- errno = EINVAL;
- return 0;
- }
- factor = get_unit_factor(end);
- if (!factor) {
- errno = EINVAL;
- return 0;
- }
- if ((val < 0 && -max / factor > val) ||
- (val > 0 && max / factor < val)) {
- errno = ERANGE;
- return 0;
- }
- val *= factor;
- *ret = val;
- return 1;
- }
- errno = EINVAL;
- return 0;
-}
-
-static int git_parse_unsigned(const char *value, uintmax_t *ret, uintmax_t max)
-{
- if (value && *value) {
- char *end;
- uintmax_t val;
- uintmax_t factor;
-
- /* negative values would be accepted by strtoumax */
- if (strchr(value, '-')) {
- errno = EINVAL;
- return 0;
- }
- errno = 0;
- val = strtoumax(value, &end, 0);
- if (errno == ERANGE)
- return 0;
- if (end == value) {
- errno = EINVAL;
- return 0;
- }
- factor = get_unit_factor(end);
- if (!factor) {
- errno = EINVAL;
- return 0;
- }
- if (unsigned_mult_overflows(factor, val) ||
- factor * val > max) {
- errno = ERANGE;
- return 0;
- }
- val *= factor;
- *ret = val;
- return 1;
- }
- errno = EINVAL;
- return 0;
-}
-
-int git_parse_int(const char *value, int *ret)
-{
- intmax_t tmp;
- if (!git_parse_signed(value, &tmp, maximum_signed_value_of_type(int)))
- return 0;
- *ret = tmp;
- return 1;
-}
-
-static int git_parse_int64(const char *value, int64_t *ret)
-{
- intmax_t tmp;
- if (!git_parse_signed(value, &tmp, maximum_signed_value_of_type(int64_t)))
- return 0;
- *ret = tmp;
- return 1;
-}
-
-int git_parse_ulong(const char *value, unsigned long *ret)
-{
- uintmax_t tmp;
- if (!git_parse_unsigned(value, &tmp, maximum_unsigned_value_of_type(long)))
- return 0;
- *ret = tmp;
- return 1;
-}
-
-int git_parse_ssize_t(const char *value, ssize_t *ret)
-{
- intmax_t tmp;
- if (!git_parse_signed(value, &tmp, maximum_signed_value_of_type(ssize_t)))
- return 0;
- *ret = tmp;
- return 1;
-}
-
NORETURN
static void die_bad_number(const char *name, const char *value,
const struct key_value_info *kvi)
@@ -1363,23 +1241,6 @@ ssize_t git_config_ssize_t(const char *name, const char *value,
return ret;
}
-static int git_parse_maybe_bool_text(const char *value)
-{
- if (!value)
- return 1;
- if (!*value)
- return 0;
- if (!strcasecmp(value, "true")
- || !strcasecmp(value, "yes")
- || !strcasecmp(value, "on"))
- return 1;
- if (!strcasecmp(value, "false")
- || !strcasecmp(value, "no")
- || !strcasecmp(value, "off"))
- return 0;
- return -1;
-}
-
static const struct fsync_component_name {
const char *name;
enum fsync_component component_bits;
@@ -1454,16 +1315,6 @@ static enum fsync_component parse_fsync_components(const char *var, const char *
return (current & ~negative) | positive;
}
-int git_parse_maybe_bool(const char *value)
-{
- int v = git_parse_maybe_bool_text(value);
- if (0 <= v)
- return v;
- if (git_parse_int(value, &v))
- return !!v;
- return -1;
-}
-
int git_config_bool_or_int(const char *name, const char *value,
const struct key_value_info *kvi, int *is_bool)
{
@@ -2126,35 +1977,6 @@ void git_global_config(char **user_out, char **xdg_out)
*xdg_out = xdg_config;
}
-/*
- * Parse environment variable 'k' as a boolean (in various
- * possible spellings); if missing, use the default value 'def'.
- */
-int git_env_bool(const char *k, int def)
-{
- const char *v = getenv(k);
- int val;
- if (!v)
- return def;
- val = git_parse_maybe_bool(v);
- if (val < 0)
- die(_("bad boolean environment value '%s' for '%s'"),
- v, k);
- return val;
-}
-
-/*
- * Parse environment variable 'k' as ulong with possibly a unit
- * suffix; if missing, use the default value 'val'.
- */
-unsigned long git_env_ulong(const char *k, unsigned long val)
-{
- const char *v = getenv(k);
- if (v && !git_parse_ulong(v, &val))
- die(_("failed to parse %s"), k);
- return val;
-}
-
int git_config_system(void)
{
return !git_env_bool("GIT_CONFIG_NOSYSTEM", 0);
diff --git a/config.h b/config.h
index 6332d74904..14f881ecfa 100644
--- a/config.h
+++ b/config.h
@@ -4,7 +4,7 @@
#include "hashmap.h"
#include "string-list.h"
#include "repository.h"
-
+#include "parse.h"
/**
* The config API gives callers a way to access Git configuration files
@@ -243,16 +243,6 @@ int config_with_options(config_fn_t fn, void *,
* The following helper functions aid in parsing string values
*/
-int git_parse_ssize_t(const char *, ssize_t *);
-int git_parse_ulong(const char *, unsigned long *);
-int git_parse_int(const char *value, int *ret);
-
-/**
- * Same as `git_config_bool`, except that it returns -1 on error rather
- * than dying.
- */
-int git_parse_maybe_bool(const char *);
-
/**
* Parse the string to an integer, including unit factors. Dies on error;
* otherwise, returns the parsed result.
@@ -385,8 +375,6 @@ int git_config_rename_section(const char *, const char *);
int git_config_rename_section_in_file(const char *, const char *, const char *);
int git_config_copy_section(const char *, const char *);
int git_config_copy_section_in_file(const char *, const char *, const char *);
-int git_env_bool(const char *, int);
-unsigned long git_env_ulong(const char *, unsigned long);
int git_config_system(void);
int config_error_nonbool(const char *);
#if defined(__GNUC__)
diff --git a/pack-objects.c b/pack-objects.c
index 1b8052bece..f403ca6986 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -3,7 +3,7 @@
#include "pack.h"
#include "pack-objects.h"
#include "packfile.h"
-#include "config.h"
+#include "parse.h"
static uint32_t locate_object_entry_hash(struct packing_data *pdata,
const struct object_id *oid,
diff --git a/pack-revindex.c b/pack-revindex.c
index 7fffcad912..a01a2a4640 100644
--- a/pack-revindex.c
+++ b/pack-revindex.c
@@ -6,7 +6,7 @@
#include "packfile.h"
#include "strbuf.h"
#include "trace2.h"
-#include "config.h"
+#include "parse.h"
#include "midx.h"
#include "csum-file.h"
diff --git a/parse-options.c b/parse-options.c
index e8e076c3a6..093eaf2db8 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -1,11 +1,12 @@
#include "git-compat-util.h"
#include "parse-options.h"
#include "abspath.h"
-#include "config.h"
+#include "parse.h"
#include "commit.h"
#include "color.h"
#include "gettext.h"
#include "strbuf.h"
+#include "string-list.h"
#include "utf8.h"
static int disallow_abbreviated_options;
diff --git a/parse.c b/parse.c
new file mode 100644
index 0000000000..42d691a0fb
--- /dev/null
+++ b/parse.c
@@ -0,0 +1,182 @@
+#include "git-compat-util.h"
+#include "gettext.h"
+#include "parse.h"
+
+static uintmax_t get_unit_factor(const char *end)
+{
+ if (!*end)
+ return 1;
+ else if (!strcasecmp(end, "k"))
+ return 1024;
+ else if (!strcasecmp(end, "m"))
+ return 1024 * 1024;
+ else if (!strcasecmp(end, "g"))
+ return 1024 * 1024 * 1024;
+ return 0;
+}
+
+int git_parse_signed(const char *value, intmax_t *ret, intmax_t max)
+{
+ if (value && *value) {
+ char *end;
+ intmax_t val;
+ intmax_t factor;
+
+ if (max < 0)
+ BUG("max must be a positive integer");
+
+ errno = 0;
+ val = strtoimax(value, &end, 0);
+ if (errno == ERANGE)
+ return 0;
+ if (end == value) {
+ errno = EINVAL;
+ return 0;
+ }
+ factor = get_unit_factor(end);
+ if (!factor) {
+ errno = EINVAL;
+ return 0;
+ }
+ if ((val < 0 && -max / factor > val) ||
+ (val > 0 && max / factor < val)) {
+ errno = ERANGE;
+ return 0;
+ }
+ val *= factor;
+ *ret = val;
+ return 1;
+ }
+ errno = EINVAL;
+ return 0;
+}
+
+static int git_parse_unsigned(const char *value, uintmax_t *ret, uintmax_t max)
+{
+ if (value && *value) {
+ char *end;
+ uintmax_t val;
+ uintmax_t factor;
+
+ /* negative values would be accepted by strtoumax */
+ if (strchr(value, '-')) {
+ errno = EINVAL;
+ return 0;
+ }
+ errno = 0;
+ val = strtoumax(value, &end, 0);
+ if (errno == ERANGE)
+ return 0;
+ if (end == value) {
+ errno = EINVAL;
+ return 0;
+ }
+ factor = get_unit_factor(end);
+ if (!factor) {
+ errno = EINVAL;
+ return 0;
+ }
+ if (unsigned_mult_overflows(factor, val) ||
+ factor * val > max) {
+ errno = ERANGE;
+ return 0;
+ }
+ val *= factor;
+ *ret = val;
+ return 1;
+ }
+ errno = EINVAL;
+ return 0;
+}
+
+int git_parse_int(const char *value, int *ret)
+{
+ intmax_t tmp;
+ if (!git_parse_signed(value, &tmp, maximum_signed_value_of_type(int)))
+ return 0;
+ *ret = tmp;
+ return 1;
+}
+
+int git_parse_int64(const char *value, int64_t *ret)
+{
+ intmax_t tmp;
+ if (!git_parse_signed(value, &tmp, maximum_signed_value_of_type(int64_t)))
+ return 0;
+ *ret = tmp;
+ return 1;
+}
+
+int git_parse_ulong(const char *value, unsigned long *ret)
+{
+ uintmax_t tmp;
+ if (!git_parse_unsigned(value, &tmp, maximum_unsigned_value_of_type(long)))
+ return 0;
+ *ret = tmp;
+ return 1;
+}
+
+int git_parse_ssize_t(const char *value, ssize_t *ret)
+{
+ intmax_t tmp;
+ if (!git_parse_signed(value, &tmp, maximum_signed_value_of_type(ssize_t)))
+ return 0;
+ *ret = tmp;
+ return 1;
+}
+
+int git_parse_maybe_bool_text(const char *value)
+{
+ if (!value)
+ return 1;
+ if (!*value)
+ return 0;
+ if (!strcasecmp(value, "true")
+ || !strcasecmp(value, "yes")
+ || !strcasecmp(value, "on"))
+ return 1;
+ if (!strcasecmp(value, "false")
+ || !strcasecmp(value, "no")
+ || !strcasecmp(value, "off"))
+ return 0;
+ return -1;
+}
+
+int git_parse_maybe_bool(const char *value)
+{
+ int v = git_parse_maybe_bool_text(value);
+ if (0 <= v)
+ return v;
+ if (git_parse_int(value, &v))
+ return !!v;
+ return -1;
+}
+
+/*
+ * Parse environment variable 'k' as a boolean (in various
+ * possible spellings); if missing, use the default value 'def'.
+ */
+int git_env_bool(const char *k, int def)
+{
+ const char *v = getenv(k);
+ int val;
+ if (!v)
+ return def;
+ val = git_parse_maybe_bool(v);
+ if (val < 0)
+ die(_("bad boolean environment value '%s' for '%s'"),
+ v, k);
+ return val;
+}
+
+/*
+ * Parse environment variable 'k' as ulong with possibly a unit
+ * suffix; if missing, use the default value 'val'.
+ */
+unsigned long git_env_ulong(const char *k, unsigned long val)
+{
+ const char *v = getenv(k);
+ if (v && !git_parse_ulong(v, &val))
+ die(_("failed to parse %s"), k);
+ return val;
+}
diff --git a/parse.h b/parse.h
new file mode 100644
index 0000000000..07d2193d69
--- /dev/null
+++ b/parse.h
@@ -0,0 +1,20 @@
+#ifndef PARSE_H
+#define PARSE_H
+
+int git_parse_signed(const char *value, intmax_t *ret, intmax_t max);
+int git_parse_ssize_t(const char *, ssize_t *);
+int git_parse_ulong(const char *, unsigned long *);
+int git_parse_int(const char *value, int *ret);
+int git_parse_int64(const char *value, int64_t *ret);
+
+/**
+ * Same as `git_config_bool`, except that it returns -1 on error rather
+ * than dying.
+ */
+int git_parse_maybe_bool(const char *);
+int git_parse_maybe_bool_text(const char *value);
+
+int git_env_bool(const char *, int);
+unsigned long git_env_ulong(const char *, unsigned long);
+
+#endif /* PARSE_H */
diff --git a/pathspec.c b/pathspec.c
index 3a3a5724c4..7f88f1c02b 100644
--- a/pathspec.c
+++ b/pathspec.c
@@ -1,6 +1,6 @@
#include "git-compat-util.h"
#include "abspath.h"
-#include "config.h"
+#include "parse.h"
#include "dir.h"
#include "environment.h"
#include "gettext.h"
diff --git a/preload-index.c b/preload-index.c
index e44530c80c..63fd35d64b 100644
--- a/preload-index.c
+++ b/preload-index.c
@@ -7,7 +7,7 @@
#include "environment.h"
#include "fsmonitor.h"
#include "gettext.h"
-#include "config.h"
+#include "parse.h"
#include "preload-index.h"
#include "progress.h"
#include "read-cache.h"
diff --git a/progress.c b/progress.c
index f695798aca..c83cb60bf1 100644
--- a/progress.c
+++ b/progress.c
@@ -17,7 +17,7 @@
#include "trace.h"
#include "trace2.h"
#include "utf8.h"
-#include "config.h"
+#include "parse.h"
#define TP_IDX_MAX 8
diff --git a/prompt.c b/prompt.c
index 3baa33f63d..8935fe4dfb 100644
--- a/prompt.c
+++ b/prompt.c
@@ -1,5 +1,5 @@
#include "git-compat-util.h"
-#include "config.h"
+#include "parse.h"
#include "environment.h"
#include "run-command.h"
#include "strbuf.h"
diff --git a/rebase.c b/rebase.c
index 17a570f1ff..69a1822da3 100644
--- a/rebase.c
+++ b/rebase.c
@@ -1,6 +1,6 @@
#include "git-compat-util.h"
#include "rebase.h"
-#include "config.h"
+#include "parse.h"
#include "gettext.h"
/*
diff --git a/t/helper/test-env-helper.c b/t/helper/test-env-helper.c
index 66c88b8ff3..1c486888a4 100644
--- a/t/helper/test-env-helper.c
+++ b/t/helper/test-env-helper.c
@@ -1,5 +1,5 @@
#include "test-tool.h"
-#include "config.h"
+#include "parse.h"
#include "parse-options.h"
static char const * const env__helper_usage[] = {
diff --git a/unpack-trees.c b/unpack-trees.c
index 87517364dc..761562a96e 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -2,7 +2,7 @@
#include "advice.h"
#include "strvec.h"
#include "repository.h"
-#include "config.h"
+#include "parse.h"
#include "dir.h"
#include "environment.h"
#include "gettext.h"
diff --git a/wrapper.c b/wrapper.c
index 453a20ed99..7da15a56da 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -3,7 +3,7 @@
*/
#include "git-compat-util.h"
#include "abspath.h"
-#include "config.h"
+#include "parse.h"
#include "gettext.h"
#include "repository.h"
#include "strbuf.h"
diff --git a/write-or-die.c b/write-or-die.c
index d8355c0c3e..42a2dc73cd 100644
--- a/write-or-die.c
+++ b/write-or-die.c
@@ -1,5 +1,5 @@
#include "git-compat-util.h"
-#include "config.h"
+#include "parse.h"
#include "run-command.h"
#include "write-or-die.h"
--
2.42.0.582.g8ccd20d70d-goog
^ permalink raw reply related
* [PATCH v4 3/4] config: correct bad boolean env value error message
From: Jonathan Tan @ 2023-09-29 21:20 UTC (permalink / raw)
To: git; +Cc: Calvin Wan, phillip.wood123, Junio C Hamano, Jonathan Tan
In-Reply-To: <cover.1696021277.git.jonathantanmy@google.com>
From: Calvin Wan <calvinwan@google.com>
An incorrectly defined boolean environment value would result in the
following error message:
bad boolean config value '%s' for '%s'
This is a misnomer since environment value != config value. Instead of
calling git_config_bool() to parse the environment value, mimic the
functionality inside of git_config_bool() but with the correct error
message.
Signed-off-by: Calvin Wan <calvinwan@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
config.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/config.c b/config.c
index 3846a37be9..7dde0aaa02 100644
--- a/config.c
+++ b/config.c
@@ -2133,7 +2133,14 @@ void git_global_config(char **user_out, char **xdg_out)
int git_env_bool(const char *k, int def)
{
const char *v = getenv(k);
- return v ? git_config_bool(k, v) : def;
+ int val;
+ if (!v)
+ return def;
+ val = git_parse_maybe_bool(v);
+ if (val < 0)
+ die(_("bad boolean environment value '%s' for '%s'"),
+ v, k);
+ return val;
}
/*
--
2.42.0.582.g8ccd20d70d-goog
^ permalink raw reply related
* [PATCH v4 2/4] wrapper: reduce scope of remove_or_warn()
From: Jonathan Tan @ 2023-09-29 21:20 UTC (permalink / raw)
To: git; +Cc: Calvin Wan, phillip.wood123, Junio C Hamano, Jonathan Tan
In-Reply-To: <cover.1696021277.git.jonathantanmy@google.com>
From: Calvin Wan <calvinwan@google.com>
remove_or_warn() is only used by entry.c and apply.c, but it is
currently declared and defined in wrapper.{h,c}, so it has a scope much
greater than it needs. This needlessly large scope also causes wrapper.c
to need to include object.h, when this file is largely unconcerned with
Git objects.
Move remove_or_warn() to entry.{h,c}. The file apply.c still has access
to it, since it already includes entry.h for another reason.
Signed-off-by: Calvin Wan <calvinwan@google.com>
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
---
entry.c | 5 +++++
entry.h | 6 ++++++
wrapper.c | 6 ------
wrapper.h | 5 -----
4 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/entry.c b/entry.c
index 43767f9043..076e97eb89 100644
--- a/entry.c
+++ b/entry.c
@@ -581,3 +581,8 @@ void unlink_entry(const struct cache_entry *ce, const char *super_prefix)
return;
schedule_dir_for_removal(ce->name, ce_namelen(ce));
}
+
+int remove_or_warn(unsigned int mode, const char *file)
+{
+ return S_ISGITLINK(mode) ? rmdir_or_warn(file) : unlink_or_warn(file);
+}
diff --git a/entry.h b/entry.h
index 7329f918a9..ca3ed35bc0 100644
--- a/entry.h
+++ b/entry.h
@@ -62,4 +62,10 @@ int fstat_checkout_output(int fd, const struct checkout *state, struct stat *st)
void update_ce_after_write(const struct checkout *state, struct cache_entry *ce,
struct stat *st);
+/*
+ * Calls the correct function out of {unlink,rmdir}_or_warn based on
+ * the supplied file mode.
+ */
+int remove_or_warn(unsigned int mode, const char *path);
+
#endif /* ENTRY_H */
diff --git a/wrapper.c b/wrapper.c
index 48065c4f53..453a20ed99 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -5,7 +5,6 @@
#include "abspath.h"
#include "config.h"
#include "gettext.h"
-#include "object.h"
#include "repository.h"
#include "strbuf.h"
#include "trace2.h"
@@ -632,11 +631,6 @@ int rmdir_or_warn(const char *file)
return warn_if_unremovable("rmdir", file, rmdir(file));
}
-int remove_or_warn(unsigned int mode, const char *file)
-{
- return S_ISGITLINK(mode) ? rmdir_or_warn(file) : unlink_or_warn(file);
-}
-
static int access_error_is_ok(int err, unsigned flag)
{
return (is_missing_file_error(err) ||
diff --git a/wrapper.h b/wrapper.h
index 79c7321bb3..1b2b047ea0 100644
--- a/wrapper.h
+++ b/wrapper.h
@@ -106,11 +106,6 @@ int unlink_or_msg(const char *file, struct strbuf *err);
* not exist.
*/
int rmdir_or_warn(const char *path);
-/*
- * Calls the correct function out of {unlink,rmdir}_or_warn based on
- * the supplied file mode.
- */
-int remove_or_warn(unsigned int mode, const char *path);
/*
* Call access(2), but warn for any error except "missing file"
--
2.42.0.582.g8ccd20d70d-goog
^ permalink raw reply related
* [PATCH v4 1/4] hex-ll: separate out non-hash-algo functions
From: Jonathan Tan @ 2023-09-29 21:20 UTC (permalink / raw)
To: git; +Cc: Calvin Wan, phillip.wood123, Junio C Hamano, Jonathan Tan
In-Reply-To: <cover.1696021277.git.jonathantanmy@google.com>
From: Calvin Wan <calvinwan@google.com>
In order to further reduce all-in-one headers, separate out functions in
hex.h that do not operate on object hashes into its own file, hex-ll.h,
and update the include directives in the .c files that need only such
functions accordingly.
Signed-off-by: Calvin Wan <calvinwan@google.com>
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
---
Makefile | 1 +
color.c | 2 +-
hex-ll.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
hex-ll.h | 27 +++++++++++++++++++++++++++
hex.c | 47 -----------------------------------------------
hex.h | 24 +-----------------------
mailinfo.c | 2 +-
strbuf.c | 2 +-
url.c | 2 +-
urlmatch.c | 2 +-
10 files changed, 83 insertions(+), 75 deletions(-)
create mode 100644 hex-ll.c
create mode 100644 hex-ll.h
diff --git a/Makefile b/Makefile
index 5776309365..861e643708 100644
--- a/Makefile
+++ b/Makefile
@@ -1040,6 +1040,7 @@ LIB_OBJS += hash-lookup.o
LIB_OBJS += hashmap.o
LIB_OBJS += help.o
LIB_OBJS += hex.o
+LIB_OBJS += hex-ll.o
LIB_OBJS += hook.o
LIB_OBJS += ident.o
LIB_OBJS += json-writer.o
diff --git a/color.c b/color.c
index b24b19566b..f663c06ac4 100644
--- a/color.c
+++ b/color.c
@@ -3,7 +3,7 @@
#include "color.h"
#include "editor.h"
#include "gettext.h"
-#include "hex.h"
+#include "hex-ll.h"
#include "pager.h"
#include "strbuf.h"
diff --git a/hex-ll.c b/hex-ll.c
new file mode 100644
index 0000000000..4d7ece1de5
--- /dev/null
+++ b/hex-ll.c
@@ -0,0 +1,49 @@
+#include "git-compat-util.h"
+#include "hex-ll.h"
+
+const signed char hexval_table[256] = {
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 00-07 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 08-0f */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 10-17 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 18-1f */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 20-27 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 28-2f */
+ 0, 1, 2, 3, 4, 5, 6, 7, /* 30-37 */
+ 8, 9, -1, -1, -1, -1, -1, -1, /* 38-3f */
+ -1, 10, 11, 12, 13, 14, 15, -1, /* 40-47 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 48-4f */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 50-57 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 58-5f */
+ -1, 10, 11, 12, 13, 14, 15, -1, /* 60-67 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 68-67 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 70-77 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 78-7f */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 80-87 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 88-8f */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 90-97 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* 98-9f */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* a0-a7 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* a8-af */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* b0-b7 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* b8-bf */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* c0-c7 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* c8-cf */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* d0-d7 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* d8-df */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* e0-e7 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* e8-ef */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* f0-f7 */
+ -1, -1, -1, -1, -1, -1, -1, -1, /* f8-ff */
+};
+
+int hex_to_bytes(unsigned char *binary, const char *hex, size_t len)
+{
+ for (; len; len--, hex += 2) {
+ unsigned int val = (hexval(hex[0]) << 4) | hexval(hex[1]);
+
+ if (val & ~0xff)
+ return -1;
+ *binary++ = val;
+ }
+ return 0;
+}
diff --git a/hex-ll.h b/hex-ll.h
new file mode 100644
index 0000000000..a381fa8556
--- /dev/null
+++ b/hex-ll.h
@@ -0,0 +1,27 @@
+#ifndef HEX_LL_H
+#define HEX_LL_H
+
+extern const signed char hexval_table[256];
+static inline unsigned int hexval(unsigned char c)
+{
+ return hexval_table[c];
+}
+
+/*
+ * Convert two consecutive hexadecimal digits into a char. Return a
+ * negative value on error. Don't run over the end of short strings.
+ */
+static inline int hex2chr(const char *s)
+{
+ unsigned int val = hexval(s[0]);
+ return (val & ~0xf) ? val : (val << 4) | hexval(s[1]);
+}
+
+/*
+ * Read `len` pairs of hexadecimal digits from `hex` and write the
+ * values to `binary` as `len` bytes. Return 0 on success, or -1 if
+ * the input does not consist of hex digits).
+ */
+int hex_to_bytes(unsigned char *binary, const char *hex, size_t len);
+
+#endif
diff --git a/hex.c b/hex.c
index 01f17fe5c9..d42262bdca 100644
--- a/hex.c
+++ b/hex.c
@@ -2,53 +2,6 @@
#include "hash.h"
#include "hex.h"
-const signed char hexval_table[256] = {
- -1, -1, -1, -1, -1, -1, -1, -1, /* 00-07 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 08-0f */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 10-17 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 18-1f */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 20-27 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 28-2f */
- 0, 1, 2, 3, 4, 5, 6, 7, /* 30-37 */
- 8, 9, -1, -1, -1, -1, -1, -1, /* 38-3f */
- -1, 10, 11, 12, 13, 14, 15, -1, /* 40-47 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 48-4f */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 50-57 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 58-5f */
- -1, 10, 11, 12, 13, 14, 15, -1, /* 60-67 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 68-67 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 70-77 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 78-7f */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 80-87 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 88-8f */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 90-97 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 98-9f */
- -1, -1, -1, -1, -1, -1, -1, -1, /* a0-a7 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* a8-af */
- -1, -1, -1, -1, -1, -1, -1, -1, /* b0-b7 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* b8-bf */
- -1, -1, -1, -1, -1, -1, -1, -1, /* c0-c7 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* c8-cf */
- -1, -1, -1, -1, -1, -1, -1, -1, /* d0-d7 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* d8-df */
- -1, -1, -1, -1, -1, -1, -1, -1, /* e0-e7 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* e8-ef */
- -1, -1, -1, -1, -1, -1, -1, -1, /* f0-f7 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* f8-ff */
-};
-
-int hex_to_bytes(unsigned char *binary, const char *hex, size_t len)
-{
- for (; len; len--, hex += 2) {
- unsigned int val = (hexval(hex[0]) << 4) | hexval(hex[1]);
-
- if (val & ~0xff)
- return -1;
- *binary++ = val;
- }
- return 0;
-}
-
static int get_hash_hex_algop(const char *hex, unsigned char *hash,
const struct git_hash_algo *algop)
{
diff --git a/hex.h b/hex.h
index 87abf66602..e0b83f776f 100644
--- a/hex.h
+++ b/hex.h
@@ -2,22 +2,7 @@
#define HEX_H
#include "hash-ll.h"
-
-extern const signed char hexval_table[256];
-static inline unsigned int hexval(unsigned char c)
-{
- return hexval_table[c];
-}
-
-/*
- * Convert two consecutive hexadecimal digits into a char. Return a
- * negative value on error. Don't run over the end of short strings.
- */
-static inline int hex2chr(const char *s)
-{
- unsigned int val = hexval(s[0]);
- return (val & ~0xf) ? val : (val << 4) | hexval(s[1]);
-}
+#include "hex-ll.h"
/*
* Try to read a hash (specified by the_hash_algo) in hexadecimal
@@ -34,13 +19,6 @@ int get_oid_hex(const char *hex, struct object_id *oid);
/* Like get_oid_hex, but for an arbitrary hash algorithm. */
int get_oid_hex_algop(const char *hex, struct object_id *oid, const struct git_hash_algo *algop);
-/*
- * Read `len` pairs of hexadecimal digits from `hex` and write the
- * values to `binary` as `len` bytes. Return 0 on success, or -1 if
- * the input does not consist of hex digits).
- */
-int hex_to_bytes(unsigned char *binary, const char *hex, size_t len);
-
/*
* Convert a binary hash in "unsigned char []" or an object name in
* "struct object_id *" to its hex equivalent. The `_r` variant is reentrant,
diff --git a/mailinfo.c b/mailinfo.c
index 931505363c..a07d2da16d 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -1,7 +1,7 @@
#include "git-compat-util.h"
#include "config.h"
#include "gettext.h"
-#include "hex.h"
+#include "hex-ll.h"
#include "utf8.h"
#include "strbuf.h"
#include "mailinfo.h"
diff --git a/strbuf.c b/strbuf.c
index 4c9ac6dc5e..7827178d8e 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -1,6 +1,6 @@
#include "git-compat-util.h"
#include "gettext.h"
-#include "hex.h"
+#include "hex-ll.h"
#include "strbuf.h"
#include "string-list.h"
#include "utf8.h"
diff --git a/url.c b/url.c
index 2e1a9f6fee..282b12495a 100644
--- a/url.c
+++ b/url.c
@@ -1,5 +1,5 @@
#include "git-compat-util.h"
-#include "hex.h"
+#include "hex-ll.h"
#include "strbuf.h"
#include "url.h"
diff --git a/urlmatch.c b/urlmatch.c
index 1c45f23adf..1d0254abac 100644
--- a/urlmatch.c
+++ b/urlmatch.c
@@ -1,6 +1,6 @@
#include "git-compat-util.h"
#include "gettext.h"
-#include "hex.h"
+#include "hex-ll.h"
#include "strbuf.h"
#include "urlmatch.h"
--
2.42.0.582.g8ccd20d70d-goog
^ permalink raw reply related
* [PATCH v4 0/4] Preliminary patches before git-std-lib
From: Jonathan Tan @ 2023-09-29 21:20 UTC (permalink / raw)
To: git; +Cc: Jonathan Tan, Calvin Wan, phillip.wood123, Junio C Hamano
In-Reply-To: <20230627195251.1973421-1-calvinwan@google.com>
Calvin will be away for a few weeks and I'll be handling the git-std-lib
effort in the meantime. My goals will be:
- Get the preliminary patches in Calvin's patch set (patches 1-4) merged
first.
- Updating patches 5-6 based on reviewer feedback (including my
feedback). I have several aims including reducing or eliminating the
need for the GIT_STD_LIB preprocessor variable, and making stubs a test-
only concern (I think Phillip has some similar ideas [1] but I haven't
looked at their repo on GitHub yet).
[1] https://lore.kernel.org/git/98f3edcf-7f37-45ff-abd2-c0038d4e0589@gmail.com/
This patch set is in service of the first goal. Because the libification
patches are no longer included in this patch set, I have rewritten the
commit messages to justify the patches in terms of code organization.
There are no changes in the code itself. Also, I have retained Calvin's
name as the author.
Putting on my reviewer hat, if I was reviewing hex.h and config.h from
scratch, I would have not thought twice about requesting the changes
in these patches. But since we are not creating them from scratch but
modifying existing files, a question does arise about whether it's
worth the additional noise that someone looking through history needs
to handle. In this case, I think it's worth it - I think the future code
delver would appreciate being able to see the evolution of hex, hash
algo, config, and parse functions as their own files rather than, when
looking at one of them, having to filter out unrelated changes.
Besides that, as Calvin has described in his other emails, these patches
are prerequisites to being able to independently compile and use a
certain subset of the .c files. With patches that solely refactor, there
is sometimes a worry that the benefits are nebulous and that we would
be moving code around for nothing, but I don't think that that applies
here: there is still more work to be done on patches 5 and 6, but what
we have in patches 5 and 6 now shows that the benefits are concrete and
within reach.
Calvin Wan (4):
hex-ll: separate out non-hash-algo functions
wrapper: reduce scope of remove_or_warn()
config: correct bad boolean env value error message
parse: separate out parsing functions from config.h
Makefile | 2 +
attr.c | 2 +-
color.c | 2 +-
config.c | 173 +----------------------------------
config.h | 14 +--
entry.c | 5 +
entry.h | 6 ++
hex-ll.c | 49 ++++++++++
hex-ll.h | 27 ++++++
hex.c | 47 ----------
hex.h | 24 +----
mailinfo.c | 2 +-
pack-objects.c | 2 +-
pack-revindex.c | 2 +-
parse-options.c | 3 +-
parse.c | 182 +++++++++++++++++++++++++++++++++++++
parse.h | 20 ++++
pathspec.c | 2 +-
preload-index.c | 2 +-
progress.c | 2 +-
prompt.c | 2 +-
rebase.c | 2 +-
strbuf.c | 2 +-
t/helper/test-env-helper.c | 2 +-
unpack-trees.c | 2 +-
url.c | 2 +-
urlmatch.c | 2 +-
wrapper.c | 8 +-
wrapper.h | 5 -
write-or-die.c | 2 +-
30 files changed, 313 insertions(+), 284 deletions(-)
create mode 100644 hex-ll.c
create mode 100644 hex-ll.h
create mode 100644 parse.c
create mode 100644 parse.h
Range-diff against v3:
1: fcce01bc19 ! 1: 02ecc00e9c hex-ll: split out functionality from hex
@@ Metadata
Author: Calvin Wan <calvinwan@google.com>
## Commit message ##
- hex-ll: split out functionality from hex
+ hex-ll: separate out non-hash-algo functions
- Separate out hex functionality that doesn't require a hash algo into
- hex-ll.[ch]. Since the hash algo is currently a global that sits in
- repository, this separation removes that dependency for files that only
- need basic hex manipulation functions.
+ In order to further reduce all-in-one headers, separate out functions in
+ hex.h that do not operate on object hashes into its own file, hex-ll.h,
+ and update the include directives in the .c files that need only such
+ functions accordingly.
Signed-off-by: Calvin Wan <calvinwan@google.com>
- Signed-off-by: Junio C Hamano <gitster@pobox.com>
+ Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
## Makefile ##
@@ Makefile: LIB_OBJS += hash-lookup.o
2: 95a369d02b ! 2: c9e7cd7857 wrapper: remove dependency to Git-specific internal file
@@ Metadata
Author: Calvin Wan <calvinwan@google.com>
## Commit message ##
- wrapper: remove dependency to Git-specific internal file
+ wrapper: reduce scope of remove_or_warn()
- In order for wrapper.c to be built independently as part of a smaller
- library, it cannot have dependencies to other Git specific
- internals. remove_or_warn() creates an unnecessary dependency to
- object.h in wrapper.c. Therefore move the function to entry.[ch] which
- performs changes on the worktree based on the Git-specific file modes in
- the index.
+ remove_or_warn() is only used by entry.c and apply.c, but it is
+ currently declared and defined in wrapper.{h,c}, so it has a scope much
+ greater than it needs. This needlessly large scope also causes wrapper.c
+ to need to include object.h, when this file is largely unconcerned with
+ Git objects.
+
+ Move remove_or_warn() to entry.{h,c}. The file apply.c still has access
+ to it, since it already includes entry.h for another reason.
Signed-off-by: Calvin Wan <calvinwan@google.com>
- Signed-off-by: Junio C Hamano <gitster@pobox.com>
+ Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
## entry.c ##
@@ entry.c: void unlink_entry(const struct cache_entry *ce, const char *super_prefix)
3: 5348528865 = 3: e4c20a81f9 config: correct bad boolean env value error message
4: b5a8945c5c ! 4: 5d9f0b3de0 parse: create new library for parsing strings and env values
@@ Metadata
Author: Calvin Wan <calvinwan@google.com>
## Commit message ##
- parse: create new library for parsing strings and env values
+ parse: separate out parsing functions from config.h
- While string and environment value parsing is mainly consumed by
- config.c, there are other files that only need parsing functionality and
- not config functionality. By separating out string and environment value
- parsing from config, those files can instead be dependent on parse,
- which has a much smaller dependency chain than config. This ultimately
- allows us to inclue parse.[ch] in an independent library since it
- doesn't have dependencies to Git-specific internals unlike in
- config.[ch].
+ The files config.{h,c} contain functions that have to do with parsing,
+ but not config.
- Move general string and env parsing functions from config.[ch] to
- parse.[ch].
+ In order to further reduce all-in-one headers, separate out functions in
+ config.c that do not operate on config into its own file, parse.h,
+ and update the include directives in the .c files that need only such
+ functions accordingly.
Signed-off-by: Calvin Wan <calvinwan@google.com>
- Signed-off-by: Junio C Hamano <gitster@pobox.com>
+ Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
## Makefile ##
@@ Makefile: LIB_OBJS += pack-write.o
--
2.42.0.582.g8ccd20d70d-goog
^ permalink raw reply
* [PATCH v3 1/3] subtree: fix split processing with multiple subtrees present
From: Zach FettersMoore via GitGitGadget @ 2023-09-29 20:32 UTC (permalink / raw)
To: git; +Cc: Zach FettersMoore, Zach FettersMoore
In-Reply-To: <pull.1587.v3.git.1696019580.gitgitgadget@gmail.com>
From: Zach FettersMoore <zach.fetters@apollographql.com>
When there are multiple subtrees present in a repository and they are
all using 'git subtree split', the 'split' command can take a
significant (and constantly growing) amount of time to run even when
using the '--rejoin' flag. This is due to the fact that when processing
commits to determine the last known split to start from when looking
for changes, if there has been a split/merge done from another subtree
there will be 2 split commits, one mainline and one subtree, for the
second subtree that are part of the processing. The non-mainline
subtree split commit will cause the processing to always need to search
the entire history of the given subtree as part of its processing even
though those commits are totally irrelevant to the current subtree
split being run.
In the diagram below, 'M' represents the mainline repo branch, 'A'
represents one subtree, and 'B' represents another. M3 and B1 represent
a split commit for subtree B that was created from commit M4. M2 and A1
represent a split commit made from subtree A that was also created
based on changes back to and including M4. M1 represents new changes to
the repo, in this scenario if you try to run a 'git subtree split
--rejoin' for subtree B, commits M1, M2, and A1, will be included in
the processing of changes for the new split commit since the last
split/rejoin for subtree B was at M3. The issue is that by having A1
included in this processing the command ends up needing to processing
every commit down tree A even though none of that is needed or relevant
to the current command and result.
M1
| \ \
M2 | |
| A1 |
M3 | |
| | B1
M4 | |
So this commit makes a change to the processing of commits for the split
command in order to ignore non-mainline commits from other subtrees such
as A1 in the diagram by adding a new function
'should_ignore_subtree_commit' which is called during
'process_split_commit'. This allows the split/rejoin processing to still
function as expected but removes all of the unnecessary processing that
takes place currently which greatly inflates the processing time.
Signed-off-by: Zach FettersMoore <zach.fetters@apollographql.com>
---
contrib/subtree/git-subtree.sh | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index e0c5d3b0de6..e9250dfb019 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -778,12 +778,29 @@ ensure_valid_ref_format () {
die "fatal: '$1' does not look like a ref"
}
+# Usage: check if a commit from another subtree should be ignored from processing for splits
+should_ignore_subtree_commit () {
+ if [ "$(git log -1 --grep="git-subtree-dir:" $1)" ]
+ then
+ if [[ -z "$(git log -1 --grep="git-subtree-mainline:" $1)" && -z "$(git log -1 --grep="git-subtree-dir: $dir$" $1)" ]]
+ then
+ return 0
+ fi
+ fi
+ return 1
+}
+
# Usage: process_split_commit REV PARENTS
process_split_commit () {
assert test $# = 2
local rev="$1"
local parents="$2"
+ if should_ignore_subtree_commit $rev
+ then
+ return
+ fi
+
if test $indent -eq 0
then
revcount=$(($revcount + 1))
--
gitgitgadget
^ permalink raw reply related
* [PATCH v3 3/3] subtree: adding test to validate fix
From: Zach FettersMoore via GitGitGadget @ 2023-09-29 20:33 UTC (permalink / raw)
To: git; +Cc: Zach FettersMoore, Zach FettersMoore
In-Reply-To: <pull.1587.v3.git.1696019580.gitgitgadget@gmail.com>
From: Zach FettersMoore <zach.fetters@apollographql.com>
Adding a test to validate that the proposed fix
solves the issue.
The test accomplishes this by checking the output
of the split command to ensure the output from
the progress of 'process_split_commit' function
that represents the 'extracount' of commits
processed does not increment.
This was tested against the original functionality
to show the test failed, and then with this fix
to show the test passes.
This illustrated that when using multiple subtrees,
A and B, when doing a split on subtree B, the
processing does not traverse the entire history
of subtree A which is unnecessary and would cause
the 'extracount' of processed commits to climb
based on the number of commits in the history of
subtree A.
Signed-off-by: Zach FettersMoore <zach.fetters@apollographql.com>
---
contrib/subtree/t/t7900-subtree.sh | 41 ++++++++++++++++++++++++++++++
1 file changed, 41 insertions(+)
diff --git a/contrib/subtree/t/t7900-subtree.sh b/contrib/subtree/t/t7900-subtree.sh
index 49a21dd7c9c..57c12e9f924 100755
--- a/contrib/subtree/t/t7900-subtree.sh
+++ b/contrib/subtree/t/t7900-subtree.sh
@@ -385,6 +385,47 @@ test_expect_success 'split sub dir/ with --rejoin' '
)
'
+test_expect_success 'split with multiple subtrees' '
+ subtree_test_create_repo "$test_count" &&
+ subtree_test_create_repo "$test_count/subA" &&
+ subtree_test_create_repo "$test_count/subB" &&
+ test_create_commit "$test_count" main1 &&
+ test_create_commit "$test_count/subA" subA1 &&
+ test_create_commit "$test_count/subA" subA2 &&
+ test_create_commit "$test_count/subA" subA3 &&
+ test_create_commit "$test_count/subB" subB1 &&
+ (
+ cd "$test_count" &&
+ git fetch ./subA HEAD &&
+ git subtree add --prefix=subADir FETCH_HEAD
+ ) &&
+ (
+ cd "$test_count" &&
+ git fetch ./subB HEAD &&
+ git subtree add --prefix=subBDir FETCH_HEAD
+ ) &&
+ test_create_commit "$test_count" subADir/main-subA1 &&
+ test_create_commit "$test_count" subBDir/main-subB1 &&
+ (
+ cd "$test_count" &&
+ git subtree split --prefix=subADir --squash --rejoin -m "Sub A Split 1"
+ ) &&
+ (
+ cd "$test_count" &&
+ git subtree split --prefix=subBDir --squash --rejoin -m "Sub B Split 1"
+ ) &&
+ test_create_commit "$test_count" subADir/main-subA2 &&
+ test_create_commit "$test_count" subBDir/main-subB2 &&
+ (
+ cd "$test_count" &&
+ git subtree split --prefix=subADir --squash --rejoin -m "Sub A Split 2"
+ ) &&
+ (
+ cd "$test_count" &&
+ test "$(git subtree split --prefix=subBDir --squash --rejoin -d -m "Sub B Split 1" 2>&1 | grep -w "\[1\]")" = ""
+ )
+'
+
test_expect_success 'split sub dir/ with --rejoin from scratch' '
subtree_test_create_repo "$test_count" &&
test_create_commit "$test_count" main1 &&
--
gitgitgadget
^ permalink raw reply related
* [PATCH v3 2/3] subtree: changing location of commit ignore processing
From: Zach FettersMoore via GitGitGadget @ 2023-09-29 20:32 UTC (permalink / raw)
To: git; +Cc: Zach FettersMoore, Zach FettersMoore
In-Reply-To: <pull.1587.v3.git.1696019580.gitgitgadget@gmail.com>
From: Zach FettersMoore <zach.fetters@apollographql.com>
Based on feedback from original commit:
-Updated the location of check whether a commit should
be ignored during split processing
-Updated code to better fit coding guidelines
Signed-off-by: Zach FettersMoore <zach.fetters@apollographql.com>
---
contrib/subtree/git-subtree.sh | 30 ++++++++++++++++++++----------
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index e9250dfb019..e69991a9d80 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -778,11 +778,13 @@ ensure_valid_ref_format () {
die "fatal: '$1' does not look like a ref"
}
-# Usage: check if a commit from another subtree should be ignored from processing for splits
-should_ignore_subtree_commit () {
- if [ "$(git log -1 --grep="git-subtree-dir:" $1)" ]
+# Usage: check if a commit from another subtree should be
+# ignored from processing for splits
+should_ignore_subtree_split_commit () {
+ if test -n "$(git log -1 --grep="git-subtree-dir:" $1)"
then
- if [[ -z "$(git log -1 --grep="git-subtree-mainline:" $1)" && -z "$(git log -1 --grep="git-subtree-dir: $dir$" $1)" ]]
+ if test -z "$(git log -1 --grep="git-subtree-mainline:" $1)" &&
+ test -z "$(git log -1 --grep="git-subtree-dir: $arg_prefix$" $1)"
then
return 0
fi
@@ -796,11 +798,6 @@ process_split_commit () {
local rev="$1"
local parents="$2"
- if should_ignore_subtree_commit $rev
- then
- return
- fi
-
if test $indent -eq 0
then
revcount=$(($revcount + 1))
@@ -980,7 +977,20 @@ cmd_split () {
eval "$grl" |
while read rev parents
do
- process_split_commit "$rev" "$parents"
+ if should_ignore_subtree_split_commit "$rev"
+ then
+ continue
+ fi
+ parsedParents=''
+ for parent in $parents
+ do
+ should_ignore_subtree_split_commit "$parent"
+ if test $? -eq 1
+ then
+ parsedParents+="$parent "
+ fi
+ done
+ process_split_commit "$rev" "$parsedParents"
done || exit $?
latest_new=$(cache_get latest_new) || exit $?
--
gitgitgadget
^ permalink raw reply related
* [PATCH v3 0/3] subtree: fix split processing with multiple subtrees present
From: Zach FettersMoore via GitGitGadget @ 2023-09-29 20:32 UTC (permalink / raw)
To: git; +Cc: Zach FettersMoore
In-Reply-To: <pull.1587.v2.git.1695399920.gitgitgadget@gmail.com>
When there are multiple subtrees in a repo and git subtree split --rejoin is
being used for the subtrees, the processing of commits for a new split can
take a significant (and constantly growing) amount of time because the split
commits from other subtrees cause the processing to have to scan the entire
history of the other subtree(s). This patch filters out the other subtree
split commits that are unnecessary for the split commit processing.
Zach FettersMoore (3):
subtree: fix split processing with multiple subtrees present
subtree: changing location of commit ignore processing
subtree: adding test to validate fix
contrib/subtree/git-subtree.sh | 29 ++++++++++++++++++++-
contrib/subtree/t/t7900-subtree.sh | 41 ++++++++++++++++++++++++++++++
2 files changed, 69 insertions(+), 1 deletion(-)
base-commit: bda494f4043963b9ec9a1ecd4b19b7d1cd9a0518
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1587%2FBobaFetters%2Fzf%2Fmulti-subtree-processing-v3
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1587/BobaFetters/zf/multi-subtree-processing-v3
Pull-Request: https://github.com/gitgitgadget/git/pull/1587
Range-diff vs v2:
1: 43175154a82 = 1: 43175154a82 subtree: fix split processing with multiple subtrees present
2: d6811daf7cf = 2: d6811daf7cf subtree: changing location of commit ignore processing
-: ----------- > 3: eff8bfcc042 subtree: adding test to validate fix
--
gitgitgadget
^ permalink raw reply
* Re: [PATCH 21/30] repository: Implement extensions.compatObjectFormat
From: Junio C Hamano @ 2023-09-29 18:48 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: git, brian m. carlson, Eric W. Biederman
In-Reply-To: <87bkdkhq4s.fsf@gmail.froward.int.ebiederm.org>
"Eric W. Biederman" <ebiederm@gmail.com> writes:
> Did you have any manual merge conflicts you had to resolve?
> If so it is possible to see the merge result you had?
The only merge-fix I had to apply to make everything compile was
this:
diff --git a/bloom.c b/bloom.c
index ff131893cd..59eb0a0481 100644
--- a/bloom.c
+++ b/bloom.c
@@ -278,7 +278,7 @@ static int has_entries_with_high_bit(struct repository *r, struct tree *t)
struct tree_desc desc;
struct name_entry entry;
- init_tree_desc(&desc, t->buffer, t->size);
+ init_tree_desc(&desc, &t->object.oid, t->buffer, t->size);
while (tree_entry(&desc, &entry)) {
size_t i;
for (i = 0; i < entry.pathlen; i++) {
as one topic changed the function signature while the other topic
added a new callsite.
Everything else was pretty-much auto resolved, I think.
Output from "git show --cc seen" matches my recollection. The above
does appear as an evil merge.
^ permalink raw reply related
* Re: [PATCH 21/30] repository: Implement extensions.compatObjectFormat
From: Eric W. Biederman @ 2023-09-29 16:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, brian m. carlson, Eric W. Biederman
In-Reply-To: <xmqqbkdmjbkp.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> "Eric W. Biederman" <ebiederm@gmail.com> writes:
>>
>>> diff --git a/setup.c b/setup.c
>>> index deb5a33fe9e1..87b40472dbc5 100644
>>> --- a/setup.c
>>> +++ b/setup.c
>>> @@ -598,6 +598,25 @@ static enum extension_result handle_extension(const char *var,
>>> }
>>
>> This line in the pre-context needed fuzzing, but otherwise the
>> series applied cleanly on top of v2.42.0.
>>
>>> Subject: Re: [PATCH 21/30] repository: Implement extensions.compatObjectFormat
>>
>> "Implement" -> "implement" (many other patches share the same
>> problem, none of which I fixed while queueing).
>
>
> The topic when merged near the tip of 'seen' seems to break a few CI
> jobs here and there. The log from the broken run can be seen at
>
> https://github.com/git/git/actions/runs/6331978214
>
> You may have to log-in there before you can view the details.
Did you have any manual merge conflicts you had to resolve?
If so it is possible to see the merge result you had?
There is a static failure in commit.c of oidcpy because it thinks the
array is zero size. That is weird, but once I get a test environment
setup I expect I can figure out what it is talking about.
There in linux-leaks it lists a bunch of test failures, and unless I see
what code is actually failing I am not certain I can figure it out.
Thanks,
Eric
^ permalink raw reply
* Re: Git log bug
From: Junio C Hamano @ 2023-09-29 15:12 UTC (permalink / raw)
To: liangxiong zhu; +Cc: git@vger.kernel.org
In-Reply-To: <LV2PR19MB5767BB3F887CDB46F571656DAFC0A@LV2PR19MB5767.namprd19.prod.outlook.com>
liangxiong zhu <lxzhu@outlook.com> writes:
> git clone $repo_url $repo_name
> cd $repo_name
> mkdir dir01
> mkdir dir02
> touch dir01/file01.txt
> git add .
> git commit -m 'Add file01.txt'
> git push
>
> touch dir02/file02.txt
> git add .
> git commit -m 'Add file02.txt'
> git push
>
> git log -1 -- dir01
>
> What did you expect to happen? (Expected behavior)
> print out commit with message 'Add file01.txt'
>
> What happened instead? (Actual behavior)
> print out commit with message 'Add file02.txt'
Thanks, but it does not reproduce with the above procedure.
Following the above (with $repo_name set to "trash" that is not a
name of any existing directory in the current directory, and
$repo_url set to a local repository that exists but without any
history), I got the "Add file01.txt" from the last step.
I got
No refs in common and none specified; doing nothing.
Perhaps you should specify a branch.
fatal: the remote end hung up unexpectedly
error: failed to push some refs to '/var/tmp/x/./empty.git'
after both of "git push", but becuase "git log" that does not say
where to start cares only about HEAD, in the above reproduction
precipe "git push" should be irrelevant (i.e., if your copy of Git
is broken to exhibit the above reported bug, it should show the same
symptom without these steps to run "git push").
If there are some hooks that modifies the history after your "git
push", it would be a different story, but otherwise I am not sure
how any version of Git would exhibit such a symptom.
Puzzled.
^ permalink raw reply
* Git log bug
From: liangxiong zhu @ 2023-09-29 9:35 UTC (permalink / raw)
To: git@vger.kernel.org
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
git clone $repo_url $repo_name
cd $repo_name
mkdir dir01
mkdir dir02
touch dir01/file01.txt
git add .
git commit -m 'Add file01.txt'
git push
touch dir02/file02.txt
git add .
git commit -m 'Add file02.txt'
git push
git log -1 -- dir01
What did you expect to happen? (Expected behavior)
print out commit with message 'Add file01.txt'
What happened instead? (Actual behavior)
print out commit with message 'Add file02.txt'
What's different between what you expected and what actually happened?
I would like to get the last commit to a specified directory in the repo, But I get the last commit of the whole repo
Anything else you want to add:
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
[System Info]
git version:
git version 2.42.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 5.15.0-1036-azure #43-Ubuntu SMP Wed Mar 29 16:11:05 UTC 2023 x86_64
compiler info: gnuc: 11.4
libc info: glibc: 2.35
$SHELL (typically, interactive shell): <unset>
[Enabled Hooks]
^ permalink raw reply
* Draft of Git Rev News edition 103
From: Christian Couder @ 2023-09-29 9:08 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jakub Narebski, Markus Jansen, Kaartic Sivaraam,
Taylor Blau, Johannes Schindelin,
Ævar Arnfjörð Bjarmason, Ronan Pigott,
Adam Johnson, Bruno Brito, M Hickford
Hi everyone!
A draft of a new Git Rev News edition is available here:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-103.md
Everyone is welcome to contribute in any section either by editing the
above page on GitHub and sending a pull request, or by commenting on
this GitHub issue:
https://github.com/git/git.github.io/issues/660
You can also reply to this email.
In general all kinds of contributions, for example proofreading,
suggestions for articles or links, help on the issues in GitHub,
volunteering for being interviewed and so on, are very much
appreciated.
I tried to Cc everyone who appears in this edition, but maybe I missed
some people, sorry about that.
Jakub, Markus, Kaartic and I plan to publish this edition on
Sunday October 1st.
Thanks,
Christian.
^ permalink raw reply
* What's cooking in git.git (Sep 2023, #09; Thu, 28)
From: Junio C Hamano @ 2023-09-29 1:15 UTC (permalink / raw)
To: git
Here are the topics that have been cooking in my tree. Commits
prefixed with '+' are in 'next' (being in 'next' is a sign that a
topic is stable enough to be used and are candidate to be in a
future release). Commits prefixed with '-' are only in 'seen', and
aren't considered "accepted" at all and may be annotated with an URL
to a message that raises issues but they are no means exhaustive. A
topic without enough support may be discarded after a long period of
no activity (of course they can be resubmit when new interests
arise).
Copies of the source code to Git live in many repositories, and the
following is a list of the ones I push into or their mirrors. Some
repositories have only a subset of branches.
With maint, master, next, seen, todo:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://kernel.googlesource.com/pub/scm/git/git/
https://github.com/git/git/
https://gitlab.com/git-vcs/git/
With all the integration branches and topics broken out:
https://github.com/gitster/git/
Even though the preformatted documentation in HTML and man format
are not sources, they are published in these repositories for
convenience (replace "htmldocs" with "manpages" for the manual
pages):
git://git.kernel.org/pub/scm/git/git-htmldocs.git/
https://github.com/gitster/git-htmldocs.git/
Release tarballs are available at:
https://www.kernel.org/pub/software/scm/git/
--------------------------------------------------
[New Topics]
* bb/unicode-width-table-15 (2023-09-25) 1 commit
(merged to 'next' on 2023-09-28 at bb76f46606)
+ unicode: update the width tables to Unicode 15.1
The display width table for unicode characters has been updated for
Unicode 15.1
Will merge to 'master'.
source: <20230925190704.157731-1-dev+git@drbeat.li>
* eb/limit-bulk-checkin-to-blobs (2023-09-26) 1 commit
- bulk-checkin: only support blobs in index_bulk_checkin
The "streaming" interface used for bulk-checkin codepath has been
narrowed to take only blob objects for now, with no real loss of
functionality.
Will merge to 'next'.
source: <87msx99b9o.fsf_-_@gmail.froward.int.ebiederm.org>
* jk/commit-graph-verify-fix (2023-09-28) 6 commits
(merged to 'next' on 2023-09-28 at e3ed560a2f)
+ commit-graph: report incomplete chains during verification
+ commit-graph: tighten chain size check
+ commit-graph: detect read errors when verifying graph chain
+ t5324: harmonize sha1/sha256 graph chain corruption
+ commit-graph: check mixed generation validation when loading chain file
+ commit-graph: factor out chain opening function
Various fixes to "git commit-graph verify".
Will merge to 'master'.
source: <20230928043746.GB57926@coredump.intra.peff.net>
* js/update-urls-in-doc-and-comment (2023-09-26) 4 commits
- doc: refer to internet archive
- doc: update links for andre-simon.de
- doc: update links to current pages
- doc: switch links to https
Stale URLs have been updated to their current counterparts (or
archive.org) and HTTP links are replaced with working HTTPS links.
Needs eyeballing.
source: <pull.1589.v2.git.1695553041.gitgitgadget@gmail.com>
* la/trailer-cleanups (2023-09-26) 4 commits
- trailer: only use trailer_block_* variables if trailers were found
- trailer: use offsets for trailer_start/trailer_end
- trailer: find the end of the log message
- commit: ignore_non_trailer computes number of bytes to ignore
Code clean-up.
Needs review.
source: <pull.1563.v4.git.1695709372.gitgitgadget@gmail.com>
* eb/hash-transition (2023-09-27) 30 commits
- t1016-compatObjectFormat: Add tests to verify the conversion between objects
- t1006: Test oid compatibility with cat-file
- t1006: Rename sha1 to oid
- test-lib: Compute the compatibility hash so tests may use it
- builtin/ls-tree: Let the oid determine the output algorithm
- object-file: Handle compat objects in check_object_signature
- tree-walk: init_tree_desc take an oid to get the hash algorithm
- builtin/cat-file: Let the oid determine the output algorithm
- rev-parse: Add an --output-object-format parameter
- repository: Implement extensions.compatObjectFormat
- object-file: Update object_info_extended to reencode objects
- object-file-convert: Convert commits that embed signed tags
- object-file-convert: convert commit objects when writing
- object-file-convert: Don't leak when converting tag objects
- object-file-convert: convert tag objects when writing
- object-file-convert: add a function to convert trees between algorithms
- object: Factor out parse_mode out of fast-import and tree-walk into in object.h
- cache: add a function to read an OID of a specific algorithm
- tag: sign both hashes
- commit: Export add_header_signature to support handling signatures on tags
- commit: Convert mergetag before computing the signature of a commit
- commit: write commits for both hashes
- object-file: Add a compat_oid_in parameter to write_object_file_flags
- object-file: Update the loose object map when writing loose objects
- loose: Compatibilty short name support
- loose: add a mapping between SHA-1 and SHA-256 for loose objects
- repository: add a compatibility hash algorithm
- object-names: Support input of oids in any supported hash
- oid-array: Teach oid-array to handle multiple kinds of oids
- object-file-convert: Stubs for converting from one object format to another
Teach a repository to work with both SHA-1 and SHA-256 hash algorithms.
Breaks a few CI jobs when merged to 'seen'.
cf. <xmqqbkdmjbkp.fsf@gitster.g>
source: <87jzsbjt0a.fsf@gmail.froward.int.ebiederm.org>
* xz/commit-title-soft-limit-doc (2023-09-28) 1 commit
(merged to 'next' on 2023-09-28 at 20df852430)
+ doc: correct the 50 characters soft limit
Doc tweak.
Will merge to 'master'.
source: <pull.1580.git.git.1695895155985.gitgitgadget@gmail.com>
--------------------------------------------------
[Stalled]
* tk/cherry-pick-sequence-requires-clean-worktree (2023-06-01) 1 commit
- cherry-pick: refuse cherry-pick sequence if index is dirty
"git cherry-pick A" that replays a single commit stopped before
clobbering local modification, but "git cherry-pick A..B" did not,
which has been corrected.
Expecting a reroll.
cf. <999f12b2-38d6-f446-e763-4985116ad37d@gmail.com>
source: <pull.1535.v2.git.1685264889088.gitgitgadget@gmail.com>
* jc/diff-cached-fsmonitor-fix (2023-09-15) 3 commits
- diff-lib: fix check_removed() when fsmonitor is active
- Merge branch 'jc/fake-lstat' into jc/diff-cached-fsmonitor-fix
- Merge branch 'js/diff-cached-fsmonitor-fix' into jc/diff-cached-fsmonitor-fix
(this branch uses jc/fake-lstat.)
The optimization based on fsmonitor in the "diff --cached"
codepath is resurrected with the "fake-lstat" introduced earlier.
It is unknown if the optimization is worth resurrecting, but in case...
source: <xmqqr0n0h0tw.fsf@gitster.g>
--------------------------------------------------
[Cooking]
* jx/remote-archive-over-smart-http (2023-09-25) 3 commits
- archive: support remote archive from stateless transport
- transport-helper: run do_take_over in connect_helper
- transport-helper: no connection restriction in connect_helper
"git archive --remote=<remote>" learned to talk over the smart
http (aka stateless) transport.
Expecting a reroll.
cf. <CANYiYbFkG+CvrNFBkdNewZs7ADROVsjd051SDQsU0zVq8eBhew@mail.gmail.com>
source: <20230923152201.14741-1-worldhello.net@gmail.com>
* jx/sideband-chomp-newline-fix (2023-09-25) 3 commits
- pkt-line: do not chomp newlines for sideband messages
- pkt-line: memorize sideband fragment in reader
- test-pkt-line: add option parser for unpack-sideband
Sideband demultiplexer fixes.
Needs review.
source: <CANYiYbF+Xmk4rCNLMJe+i_CFafg8=QU5vbXWNUZbOVsDLTe5QQ@mail.gmail.com>
* ks/ref-filter-mailmap (2023-09-25) 3 commits
(merged to 'next' on 2023-09-28 at 0d3fd9959a)
+ ref-filter: add mailmap support
+ t/t6300: introduce test_bad_atom
+ t/t6300: cleanup test_atom
"git for-each-ref" and friends learn to apply mailmap to authorname
and other fields.
Will merge to 'master'.
source: <20230925175050.3498-1-five231003@gmail.com>
* ps/revision-cmdline-stdin-not (2023-09-25) 1 commit
(merged to 'next' on 2023-09-28 at a28201e0dd)
+ revision: make pseudo-opt flags read via stdin behave consistently
"git rev-list --stdin" learned to take non-revisions (like "--not")
recently from the standard input, but the way such a "--not" was
handled was quite confusing, which has been rethought. This is
potentially a change that breaks backward compatibility.
Will merge to 'master'.
source: <6221acd2796853144f8e84081655fbc79fdc6634.1695646898.git.ps@pks.im>
* ty/merge-tree-strategy-options (2023-09-25) 1 commit
- merge-tree: add -X strategy option
"git merge-tree" learned to take strategy backend specific options
via the "-X" option, like "git merge" does.
Will merge to 'next'.
source: <pull.1565.v6.git.1695522222723.gitgitgadget@gmail.com>
* hy/doc-show-is-like-log-not-diff-tree (2023-09-20) 1 commit
(merged to 'next' on 2023-09-22 at 5492c03eae)
+ show doc: redirect user to git log manual instead of git diff-tree
Doc update.
Will merge to 'master'.
source: <20230920132731.1259-1-hanyang.tony@bytedance.com>
* jc/alias-completion (2023-09-20) 1 commit
(merged to 'next' on 2023-09-22 at 1d069e900b)
+ completion: loosen and document the requirement around completing alias
The command line completion script (in contrib/) can be told to
complete aliases by including ": git <cmd> ;" in the alias to tell
it that the alias should be completed similar to how "git <cmd>" is
completed. The parsing code for the alias as been loosened to
allow ';' without an extra space before it.
Will merge to 'master'.
cf. <owlyjzssjro2.fsf@fine.c.googlers.com>
source: <xmqqy1h08zsp.fsf_-_@gitster.g>
* jk/test-pass-ubsan-options-to-http-test (2023-09-21) 1 commit
(merged to 'next' on 2023-09-22 at bbe2f75937)
+ test-lib: set UBSAN_OPTIONS to match ASan
UBSAN options were not propagated through the test framework to git
run via the httpd, unlike ASAN options, which has been corrected.
Will merge to 'master'.
source: <20230921041825.GA2814583@coredump.intra.peff.net>
* ob/am-msgfix (2023-09-21) 1 commit
(merged to 'next' on 2023-09-22 at 7f7589a06a)
+ am: fix error message in parse_opt_show_current_patch()
The parameters to generate an error message have been corrected.
Will merge to 'master'.
source: <20230921110727.789156-1-oswald.buddenhagen@gmx.de>
* js/ci-coverity (2023-09-25) 7 commits
- SQUASH???
- coverity: detect and report when the token or project is incorrect
- coverity: allow running on macOS
- coverity: support building on Windows
- coverity: allow overriding the Coverity project
- coverity: cache the Coverity Build Tool
- ci: add a GitHub workflow to submit Coverity scans
GitHub CI workflow has learned to trigger Coverity check.
Looking good.
source: <pull.1588.v2.git.1695642662.gitgitgadget@gmail.com>
* js/doc-status-with-submodules-mark-up-fix (2023-09-22) 1 commit
(merged to 'next' on 2023-09-25 at 7ed318fc91)
+ Documentation/git-status: add missing line breaks
Docfix.
Will merge to 'master'.
source: <pull.1590.git.1695392082207.gitgitgadget@gmail.com>
* js/config-parse (2023-09-21) 5 commits
- config-parse: split library out of config.[c|h]
- config.c: accept config_parse_options in git_config_from_stdin
- config: report config parse errors using cb
- config: split do_event() into start and flush operations
- config: split out config_parse_options
The parsing routines for the configuration files have been split
into a separate file.
source: <cover.1695330852.git.steadmon@google.com>
* ml/git-gui-exec-path-fix (2023-09-18) 3 commits
(merged to 'next' on 2023-09-19 at 0565b0b14b)
+ Merge git-gui into ml/git-gui-exec-path-fix
+ git-gui - use git-hook, honor core.hooksPath
+ git-gui - re-enable use of hook scripts
Fix recent regression in Git-GUI that fails to run hook scripts at
all.
Will merge to 'master'.
* ds/stat-name-width-configuration (2023-09-18) 1 commit
(merged to 'next' on 2023-09-22 at dbf5bd96e8)
+ diff --stat: add config option to limit filename width
"git diff" learned diff.statNameWidth configuration variable, to
give the default width for the name part in the "--stat" output.
Will merge to 'master'.
source: <87badb12f040d1c66cd9b89074d3de5015a45983.1694446743.git.dsimic@manjaro.org>
* jk/fsmonitor-unused-parameter (2023-09-18) 8 commits
(merged to 'next' on 2023-09-19 at bd06505f9e)
+ run-command: mark unused parameters in start_bg_wait callbacks
+ fsmonitor: mark unused hashmap callback parameters
+ fsmonitor/darwin: mark unused parameters in system callback
+ fsmonitor: mark unused parameters in stub functions
+ fsmonitor/win32: mark unused parameter in fsm_os__incompatible()
+ fsmonitor: mark some maybe-unused parameters
+ fsmonitor/win32: drop unused parameters
+ fsmonitor: prefer repo_git_path() to git_pathdup()
Unused parameters in fsmonitor related code paths have been marked
as such.
Will merge to 'master'.
source: <20230918222908.GA2659096@coredump.intra.peff.net>
* jc/fake-lstat (2023-09-15) 1 commit
- cache: add fake_lstat()
(this branch is used by jc/diff-cached-fsmonitor-fix.)
A new helper to let us pretend that we called lstat() when we know
our cache_entry is up-to-date via fsmonitor.
Needs review.
source: <xmqqcyykig1l.fsf@gitster.g>
* kn/rev-list-ignore-missing-links (2023-09-20) 1 commit
- revision: add `--ignore-missing-links` user option
Surface the .ignore_missing_links bit that stops the revision
traversal from stopping and dying when encountering a missing
object to a new command line option of "git rev-list", so that the
objects that are required but are missing can be enumerated.
Waiting for review response.
source: <20230920104507.21664-1-karthik.188@gmail.com>
* kh/range-diff-notes (2023-09-19) 1 commit
(merged to 'next' on 2023-09-22 at ac04978b4b)
+ range-diff: treat notes like `log`
"git range-diff --notes=foo" compared "log --notes=foo --notes" of
the two ranges, instead of using just the specified notes tree.
Will merge to 'master'.
source: <6e114271a2e7d2323193bd58bb307f60101942ce.1695154855.git.code@khaugsbakk.name>
* rs/parse-options-value-int (2023-09-18) 2 commits
- parse-options: use and require int pointer for OPT_CMDMODE
- parse-options: add int value pointer to struct option
A bit of type safety for the "value" pointer used in the
parse-options API.
Comments?
source: <e6d8a291-03de-cfd3-3813-747fc2cad145@web.de>
* so/diff-merges-d (2023-09-11) 2 commits
- diff-merges: introduce '-d' option
- diff-merges: improve --diff-merges documentation
Teach a new "-d" option that shows the patch against the first
parent for merge commits (which is "--diff-merges=first-parent -p").
Letting a less useful combination of options squat on short-and-sweet "-d" feels dubious.
source: <20230909125446.142715-1-sorganov@gmail.com>
* cc/repack-sift-filtered-objects-to-separate-pack (2023-09-25) 10 commits
- SQUASH??? t0080 is already taken
- gc: add `gc.repackFilterTo` config option
- repack: implement `--filter-to` for storing filtered out objects
- gc: add `gc.repackFilter` config option
- repack: add `--filter=<filter-spec>` option
- pack-bitmap-write: rebuild using new bitmap when remapping
- repack: refactor finding pack prefix
- repack: refactor finishing pack-objects command
- t/helper: add 'find-pack' test-tool
- pack-objects: allow `--filter` without `--stdout`
"git repack" machinery learns to pay attention to the "--filter="
option.
Looking better.
source: <20230925152517.803579-1-christian.couder@gmail.com>
* pw/rebase-sigint (2023-09-07) 1 commit
- rebase -i: ignore signals when forking subprocesses
If the commit log editor or other external programs (spawned via
"exec" insn in the todo list) receive internactive signal during
"git rebase -i", it caused not just the spawned program but the
"Git" process that spawned them, which is often not what the end
user intended. "git" learned to ignore SIGINT and SIGQUIT while
waiting for these subprocesses.
Expecting a reroll.
cf. <12c956ea-330d-4441-937f-7885ab519e26@gmail.com>
source: <pull.1581.git.1694080982621.gitgitgadget@gmail.com>
* cw/git-std-lib (2023-09-11) 7 commits
- SQUASH???
- git-std-lib: add test file to call git-std-lib.a functions
- git-std-lib: introduce git standard library
- parse: create new library for parsing strings and env values
- config: correct bad boolean env value error message
- wrapper: remove dependency to Git-specific internal file
- hex-ll: split out functionality from hex
Another libification effort.
Needs more work.
cf. <xmqqy1hfrk6p.fsf@gitster.g>
cf. <20230915183927.1597414-1-jonathantanmy@google.com>
source: <20230908174134.1026823-1-calvinwan@google.com>
* cc/git-replay (2023-09-07) 15 commits
- replay: stop assuming replayed branches do not diverge
- replay: add --contained to rebase contained branches
- replay: add --advance or 'cherry-pick' mode
- replay: disallow revision specific options and pathspecs
- replay: use standard revision ranges
- replay: make it a minimal server side command
- replay: remove HEAD related sanity check
- replay: remove progress and info output
- replay: add an important FIXME comment about gpg signing
- replay: don't simplify history
- replay: introduce pick_regular_commit()
- replay: die() instead of failing assert()
- replay: start using parse_options API
- replay: introduce new builtin
- t6429: remove switching aspects of fast-rebase
Waiting for review response.
cf. <52277471-4ddd-b2e0-62ca-c2a5b59ae418@gmx.de>
cf. <58daa706-7efb-51dd-9061-202ef650b96a@gmx.de>
cf. <f0e75d47-c277-9fbb-7bcd-53e4e5686f3c@gmx.de>
May want to wait until tb/repack-existing-packs-cleanup stabilizes.
source: <20230907092521.733746-1-christian.couder@gmail.com>
* la/trailer-test-and-doc-updates (2023-09-07) 13 commits
- trailer doc: <token> is a <key> or <keyAlias>, not both
- trailer doc: separator within key suppresses default separator
- trailer doc: emphasize the effect of configuration variables
- trailer --unfold help: prefer "reformat" over "join"
- trailer --parse docs: add explanation for its usefulness
- trailer --only-input: prefer "configuration variables" over "rules"
- trailer --parse help: expose aliased options
- trailer --no-divider help: describe usual "---" meaning
- trailer: trailer location is a place, not an action
- trailer doc: narrow down scope of --where and related flags
- trailer: add tests to check defaulting behavior with --no-* flags
- trailer test description: this tests --where=after, not --where=before
- trailer tests: make test cases self-contained
Test coverage for trailers has been improved.
source: <pull.1564.v3.git.1694125209.gitgitgadget@gmail.com>
* js/doc-unit-tests (2023-08-17) 3 commits
- ci: run unit tests in CI
- unit tests: add TAP unit test framework
- unit tests: Add a project plan document
(this branch is used by js/doc-unit-tests-with-cmake.)
Process to add some form of low-level unit tests has started.
Waiting for review response.
cf. <xmqq350hw6n7.fsf@gitster.g>
source: <cover.1692297001.git.steadmon@google.com>
* js/doc-unit-tests-with-cmake (2023-09-25) 7 commits
- cmake: handle also unit tests
- cmake: use test names instead of full paths
- cmake: fix typo in variable name
- artifacts-tar: when including `.dll` files, don't forget the unit-tests
- unit-tests: do show relative file paths
- unit-tests: do not mistake `.pdb` files for being executable
- cmake: also build unit tests
(this branch uses js/doc-unit-tests.)
Update the base topic to work with CMake builds.
Waiting for the base topic to settle.
source: <pull.1579.v3.git.1695640836.gitgitgadget@gmail.com>
* tb/path-filter-fix (2023-08-30) 15 commits
- bloom: introduce `deinit_bloom_filters()`
- commit-graph: reuse existing Bloom filters where possible
- object.h: fix mis-aligned flag bits table
- commit-graph: drop unnecessary `graph_read_bloom_data_context`
- commit-graph.c: unconditionally load Bloom filters
- t/t4216-log-bloom.sh: harden `test_bloom_filters_not_used()`
- bloom: prepare to discard incompatible Bloom filters
- bloom: annotate filters with hash version
- commit-graph: new filter ver. that fixes murmur3
- repo-settings: introduce commitgraph.changedPathsVersion
- t4216: test changed path filters with high bit paths
- t/helper/test-read-graph: implement `bloom-filters` mode
- bloom.h: make `load_bloom_filter_from_graph()` public
- t/helper/test-read-graph.c: extract `dump_graph_info()`
- gitformat-commit-graph: describe version 2 of BDAT
The Bloom filter used for path limited history traversal was broken
on systems whose "char" is unsigned; update the implementation and
bump the format version to 2.
Still being discussed.
cf. <20230830200218.GA5147@szeder.dev>
cf. <20230901205616.3572722-1-jonathantanmy@google.com>
cf. <20230924195900.GA1156862@szeder.dev>
source: <cover.1693413637.git.jonathantanmy@google.com>
* jc/rerere-cleanup (2023-08-25) 4 commits
- rerere: modernize use of empty strbuf
- rerere: try_merge() should use LL_MERGE_ERROR when it means an error
- rerere: fix comment on handle_file() helper
- rerere: simplify check_one_conflict() helper function
(this branch uses jc/unresolve-removal.)
Code clean-up.
Not ready to be reviewed yet.
source: <20230731224409.4181277-1-gitster@pobox.com>
* jc/unresolve-removal (2023-07-31) 7 commits
(merged to 'next' on 2023-09-25 at 0563c8d8a1)
+ checkout: allow "checkout -m path" to unmerge removed paths
+ checkout/restore: add basic tests for --merge
+ checkout/restore: refuse unmerging paths unless checking out of the index
+ update-index: remove stale fallback code for "--unresolve"
+ update-index: use unmerge_index_entry() to support removal
+ resolve-undo: allow resurrecting conflicted state that resolved to deletion
+ update-index: do not read HEAD and MERGE_HEAD unconditionally
(this branch is used by jc/rerere-cleanup.)
"checkout --merge -- path" and "update-index --unresolve path" did
not resurrect conflicted state that was resolved to remove path,
but now they do.
Will merge to 'master'.
source: <20230731224409.4181277-1-gitster@pobox.com>
* rj/status-bisect-while-rebase (2023-08-01) 1 commit
- status: fix branch shown when not only bisecting
"git status" is taught to show both the branch being bisected and
being rebased when both are in effect at the same time.
Needs review.
cf. <xmqqtttia3vn.fsf@gitster.g>
source: <48745298-f12b-8efb-4e48-90d2c22a8349@gmail.com>
--------------------------------------------------
[Discarded]
* tb/ci-coverity (2023-09-21) 1 commit
. .github/workflows: add coverity action
GitHub CI workflow has learned to trigger Coverity check.
Superseded by the js/ci-coverity topic.
source: <b23951c569660e1891a7fb3ad2c2ea1952897bd7.1695332105.git.me@ttaylorr.com>
^ permalink raw reply
* Re: [PATCH 21/30] repository: Implement extensions.compatObjectFormat
From: Eric Biederman @ 2023-09-29 0:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, brian m. carlson, Eric W. Biederman
In-Reply-To: <xmqqbkdmjbkp.fsf@gitster.g>
On September 28, 2023 3:18:46 PM CDT, Junio C Hamano <gitster@pobox.com> wrote:
>Junio C Hamano <gitster@pobox.com> writes:
>
>> "Eric W. Biederman" <ebiederm@gmail.com> writes:
>>
>>> diff --git a/setup.c b/setup.c
>>> index deb5a33fe9e1..87b40472dbc5 100644
>>> --- a/setup.c
>>> +++ b/setup.c
>>> @@ -598,6 +598,25 @@ static enum extension_result handle_extension(const char *var,
>>> }
>>
>> This line in the pre-context needed fuzzing, but otherwise the
>> series applied cleanly on top of v2.42.0.
>>
>>> Subject: Re: [PATCH 21/30] repository: Implement extensions.compatObjectFormat
>>
>> "Implement" -> "implement" (many other patches share the same
>> problem, none of which I fixed while queueing).
>
>
>The topic when merged near the tip of 'seen' seems to break a few CI
>jobs here and there. The log from the broken run can be seen at
>
> https://github.com/git/git/actions/runs/6331978214
>
>You may have to log-in there before you can view the details.
Thanks.
It might take me a couple of days before I can dig into this, but I will dig in and see if I can understand and fix the build failures.
With any luck it will be something simple like forgetting that {} != {0}.
Eric
^ permalink raw reply
* Re: [PATCH v4 2/4] trailer: find the end of the log message
From: Jonathan Tan @ 2023-09-28 23:16 UTC (permalink / raw)
To: Linus Arver via GitGitGadget
Cc: Jonathan Tan, git, Glen Choo, Christian Couder, Phillip Wood,
Linus Arver
In-Reply-To: <c904caba7e17b6f2784933e9f18634ea66f28537.1695709372.git.gitgitgadget@gmail.com>
"Linus Arver via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Linus Arver <linusa@google.com>
>
> Previously, trailer_info_get() computed the trailer block end position
> by
>
> (1) checking for the opts->no_divider flag and optionally calling
> find_patch_start() to find the "patch start" location (patch_start), and
> (2) calling find_trailer_end() to find the end of the trailer block
> using patch_start as a guide, saving the return value into
> "trailer_end".
>
> The logic in (1) was awkward because the variable "patch_start" is
> misleading if there is no patch in the input. The logic in (2) was
> misleading because it could be the case that no trailers are in the
> input (yet we are setting a "trailer_end" variable before even searching
> for trailers, which happens later in find_trailer_start()). The name
> "find_trailer_end" was misleading because that function did not look for
> any trailer block itself --- instead it just computed the end position
> of the log message in the input where the end of the trailer block (if
> it exists) would be (because trailer blocks must always come after the
> end of the log message).
I might be biased since I wrote the text in question in 022349c3b0
(trailer: avoid unnecessary splitting on lines, 2016-11-02), but the
concept of patch_start and trailer_end being where the patch would start
and where the trailer would end (if they were present) goes back to
2013d8505d (trailer: parse trailers from file or stdin, 2014-10-13). I
don't remember exactly my thoughts in 2016, but today, this makes sense
to me.
As it is, the reader still needs to know that trailer_start is where
the trailer would start if it was present, and then I think it's quite
natural to have trailer_end be where the trailer would end if it was
present.
I believe the code is simpler this way, because trailer absence now no
longer needs to be special-cased when we use these variables (or maybe
they sometimes do, but not as often, since code that writes to the end
of the trailers, for example, can now just write at trailer_end instead
of having to check whether trailers exist). Same comment for patch 4
regarding using the special value 0 if no trailers are found (I think
the existing code makes more sense).
> Combine the logic in (1) and (2) together into find_patch_start() by
> renaming it to find_end_of_log_message(). The end of the log message is
> the starting point which find_trailer_start() needs to start searching
> backward to parse individual trailers (if any).
Having said that, if patch_start is too confusing for whatever reason,
this refactoring makes sense. (Avoid the confusing name by avoiding
needing to name it in the first place.)
> -static size_t find_patch_start(const char *str)
> +static size_t find_end_of_log_message(const char *input, int no_divider)
> {
> + size_t end;
> +
> const char *s;
>
> - for (s = str; *s; s = next_line(s)) {
> + /* Assume the naive end of the input is already what we want. */
> + end = strlen(input);
> +
> + /* Optionally skip over any patch part ("---" line and below). */
> + for (s = input; *s; s = next_line(s)) {
> const char *v;
>
> - if (skip_prefix(s, "---", &v) && isspace(*v))
> - return s - str;
> + if (!no_divider && skip_prefix(s, "---", &v) && isspace(*v)) {
> + end = s - input;
> + break;
> + }
> }
>
> - return s - str;
> + /* Skip over other ignorable bits. */
> + return end - ignored_log_message_bytes(input, end);
> }
This sometimes redundantly calls strlen and sometimes redundantly loops.
I think it's better to do as the code currently does - so, have a big
if/else at the beginning of this function that checks no_divider.
^ permalink raw reply
* [PATCH] MyFirstContribution: add Discord server link
From: Calvin Wan @ 2023-09-28 21:59 UTC (permalink / raw)
To: git; +Cc: Calvin Wan
Link for new contributors to join the Discord server -- a separate pull
request to add the link to the Community page has also been added.
Signed-off-by: Calvin Wan <calvinwan@google.com>
---
Documentation/MyFirstContribution.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt
index 62d11a5cd7..3751131a00 100644
--- a/Documentation/MyFirstContribution.txt
+++ b/Documentation/MyFirstContribution.txt
@@ -59,6 +59,12 @@ respond to you. It's better to ask your questions in the channel so that you
can be answered if you disconnect and so that others can learn from the
conversation.
+==== https://discord.gg/GRFVkzgxRd[Git Community Discord Server]
+
+The Git Community Discord Server also has many knowledgeable and helpful
+people. Additionally, it provides a space to be able to voice chat about
+patches, designs, or anything else Git related.
+
[[getting-started]]
== Getting Started
--
2.42.0.582.g8ccd20d70d-goog
^ 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