global: introduce `USE_THE_REPOSITORY_VARIABLE` macro
Use of the `the_repository` variable is deprecated nowadays, and we
slowly but steadily convert the codebase to not use it anymore. Instead,
callers should be passing down the repository to work on via parameters.
It is hard though to prove that a given code unit does not use this
variable anymore. The most trivial case, merely demonstrating that there
is no direct use of `the_repository`, is already a bit of a pain during
code reviews as the reviewer needs to manually verify claims made by the
patch author. The bigger problem though is that we have many interfaces
that implicitly rely on `the_repository`.
Introduce a new `USE_THE_REPOSITORY_VARIABLE` macro that allows code
units to opt into usage of `the_repository`. The intent of this macro is
to demonstrate that a certain code unit does not use this variable
anymore, and to keep it from new dependencies on it in future changes,
be it explicit or implicit
For now, the macro only guards `the_repository` itself as well as
`the_hash_algo`. There are many more known interfaces where we have an
implicit dependency on `the_repository`, but those are not guarded at
the current point in time. Over time though, we should start to add
guards as required (or even better, just remove them).
Define the macro as required in our code units. As expected, most of our
code still relies on the global variable. Nearly all of our builtins
rely on the variable as there is no way yet to pass `the_repository` to
their entry point. For now, declare the macro in "biultin.h" to keep the
required changes at least a little bit more contained.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-14 14:50:23 +08:00
|
|
|
#define USE_THE_REPOSITORY_VARIABLE
|
|
|
|
|
2023-04-11 15:41:56 +08:00
|
|
|
#include "git-compat-util.h"
|
2018-10-26 00:18:12 +08:00
|
|
|
#include "dir.h"
|
2023-03-21 14:26:03 +08:00
|
|
|
#include "environment.h"
|
2023-03-21 14:25:54 +08:00
|
|
|
#include "gettext.h"
|
2023-02-24 08:09:27 +08:00
|
|
|
#include "hex.h"
|
2023-05-16 14:33:59 +08:00
|
|
|
#include "path.h"
|
2017-06-23 02:43:44 +08:00
|
|
|
#include "repository.h"
|
2017-06-15 02:07:36 +08:00
|
|
|
#include "config.h"
|
2015-08-18 08:21:57 +08:00
|
|
|
#include "submodule-config.h"
|
|
|
|
#include "submodule.h"
|
|
|
|
#include "strbuf.h"
|
2023-04-11 15:41:49 +08:00
|
|
|
#include "object-name.h"
|
2023-05-16 14:34:06 +08:00
|
|
|
#include "object-store-ll.h"
|
2017-06-24 03:13:00 +08:00
|
|
|
#include "parse-options.h"
|
2023-04-23 04:17:27 +08:00
|
|
|
#include "thread-utils.h"
|
branch: add --recurse-submodules option for branch creation
To improve the submodules UX, we would like to teach Git to handle
branches in submodules. Start this process by teaching "git branch" the
--recurse-submodules option so that "git branch --recurse-submodules
topic" will create the `topic` branch in the superproject and its
submodules.
Although this commit does not introduce breaking changes, it does not
work well with existing --recurse-submodules commands because "git
branch --recurse-submodules" writes to the submodule ref store, but most
commands only consider the superproject gitlink and ignore the submodule
ref store. For example, "git checkout --recurse-submodules" will check
out the commits in the superproject gitlinks (and put the submodules in
detached HEAD) instead of checking out the submodule branches.
Because of this, this commit introduces a new configuration value,
`submodule.propagateBranches`. The plan is for Git commands to
prioritize submodule ref store information over superproject gitlinks if
this value is true. Because "git branch --recurse-submodules" writes to
submodule ref stores, for the sake of clarity, it will not function
unless this configuration value is set.
This commit also includes changes that support working with submodules
from a superproject commit because "branch --recurse-submodules" (and
future commands) need to read .gitmodules and gitlinks from the
superproject commit, but submodules are typically read from the
filesystem's .gitmodules and the index's gitlinks. These changes are:
* add a submodules_of_tree() helper that gives the relevant
information of an in-tree submodule (e.g. path and oid) and
initializes the repository
* add is_tree_submodule_active() by adding a treeish_name parameter to
is_submodule_active()
* add the "submoduleNotUpdated" advice to advise users to update the
submodules in their trees
Incidentally, fix an incorrect usage string that combined the 'list'
usage of git branch (-l) with the 'create' usage; this string has been
incorrect since its inception, a8dfd5eac4 (Make builtin-branch.c use
parse_options., 2007-10-07).
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Glen Choo <chooglen@google.com>
Reviewed-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-29 08:04:45 +08:00
|
|
|
#include "tree-walk.h"
|
2024-01-18 09:55:15 +08:00
|
|
|
#include "url.h"
|
2024-01-18 09:55:18 +08:00
|
|
|
#include "urlmatch.h"
|
2015-08-18 08:21:57 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* submodule cache lookup structure
|
|
|
|
* There is one shared set of 'struct submodule' entries which can be
|
2018-02-14 08:09:31 +08:00
|
|
|
* looked up by their sha1 blob id of the .gitmodules file and either
|
2015-08-18 08:21:57 +08:00
|
|
|
* using path or name as key.
|
|
|
|
* for_path stores submodule entries with path as key
|
|
|
|
* for_name stores submodule entries with name as key
|
|
|
|
*/
|
|
|
|
struct submodule_cache {
|
|
|
|
struct hashmap for_path;
|
|
|
|
struct hashmap for_name;
|
2017-06-23 02:43:44 +08:00
|
|
|
unsigned initialized:1;
|
2017-08-04 02:19:58 +08:00
|
|
|
unsigned gitmodules_read:1;
|
2015-08-18 08:21:57 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* thin wrapper struct needed to insert 'struct submodule' entries to
|
|
|
|
* the hashmap
|
|
|
|
*/
|
|
|
|
struct submodule_entry {
|
|
|
|
struct hashmap_entry ent;
|
|
|
|
struct submodule *config;
|
|
|
|
};
|
|
|
|
|
|
|
|
enum lookup_type {
|
|
|
|
lookup_name,
|
|
|
|
lookup_path
|
|
|
|
};
|
|
|
|
|
2022-08-26 01:09:48 +08:00
|
|
|
static int config_path_cmp(const void *cmp_data UNUSED,
|
2019-10-07 07:30:37 +08:00
|
|
|
const struct hashmap_entry *eptr,
|
|
|
|
const struct hashmap_entry *entry_or_key,
|
2022-08-26 01:09:48 +08:00
|
|
|
const void *keydata UNUSED)
|
2015-08-18 08:21:57 +08:00
|
|
|
{
|
2019-10-07 07:30:37 +08:00
|
|
|
const struct submodule_entry *a, *b;
|
|
|
|
|
|
|
|
a = container_of(eptr, const struct submodule_entry, ent);
|
|
|
|
b = container_of(entry_or_key, const struct submodule_entry, ent);
|
2017-07-01 08:28:36 +08:00
|
|
|
|
2015-08-18 08:21:57 +08:00
|
|
|
return strcmp(a->config->path, b->config->path) ||
|
2018-08-29 05:22:48 +08:00
|
|
|
!oideq(&a->config->gitmodules_oid, &b->config->gitmodules_oid);
|
2015-08-18 08:21:57 +08:00
|
|
|
}
|
|
|
|
|
2022-08-26 01:09:48 +08:00
|
|
|
static int config_name_cmp(const void *cmp_data UNUSED,
|
2019-10-07 07:30:37 +08:00
|
|
|
const struct hashmap_entry *eptr,
|
|
|
|
const struct hashmap_entry *entry_or_key,
|
2022-08-26 01:09:48 +08:00
|
|
|
const void *keydata UNUSED)
|
2015-08-18 08:21:57 +08:00
|
|
|
{
|
2019-10-07 07:30:37 +08:00
|
|
|
const struct submodule_entry *a, *b;
|
|
|
|
|
|
|
|
a = container_of(eptr, const struct submodule_entry, ent);
|
|
|
|
b = container_of(entry_or_key, const struct submodule_entry, ent);
|
2017-07-01 08:28:36 +08:00
|
|
|
|
2015-08-18 08:21:57 +08:00
|
|
|
return strcmp(a->config->name, b->config->name) ||
|
2018-08-29 05:22:48 +08:00
|
|
|
!oideq(&a->config->gitmodules_oid, &b->config->gitmodules_oid);
|
2015-08-18 08:21:57 +08:00
|
|
|
}
|
|
|
|
|
2017-06-23 02:43:44 +08:00
|
|
|
static struct submodule_cache *submodule_cache_alloc(void)
|
|
|
|
{
|
|
|
|
return xcalloc(1, sizeof(struct submodule_cache));
|
|
|
|
}
|
|
|
|
|
|
|
|
static void submodule_cache_init(struct submodule_cache *cache)
|
2015-08-18 08:21:57 +08:00
|
|
|
{
|
2017-07-01 08:28:36 +08:00
|
|
|
hashmap_init(&cache->for_path, config_path_cmp, NULL, 0);
|
|
|
|
hashmap_init(&cache->for_name, config_name_cmp, NULL, 0);
|
2017-06-23 02:43:44 +08:00
|
|
|
cache->initialized = 1;
|
2015-08-18 08:21:57 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void free_one_config(struct submodule_entry *entry)
|
|
|
|
{
|
|
|
|
free((void *) entry->config->path);
|
|
|
|
free((void *) entry->config->name);
|
2016-07-29 08:44:07 +08:00
|
|
|
free((void *) entry->config->branch);
|
2024-05-27 19:46:59 +08:00
|
|
|
free((void *) entry->config->url);
|
|
|
|
free((void *) entry->config->ignore);
|
2024-09-26 19:46:08 +08:00
|
|
|
submodule_update_strategy_release(&entry->config->update_strategy);
|
2015-08-18 08:21:57 +08:00
|
|
|
free(entry->config);
|
|
|
|
}
|
|
|
|
|
2017-06-23 02:43:44 +08:00
|
|
|
static void submodule_cache_clear(struct submodule_cache *cache)
|
2015-08-18 08:21:57 +08:00
|
|
|
{
|
|
|
|
struct hashmap_iter iter;
|
|
|
|
struct submodule_entry *entry;
|
|
|
|
|
2017-06-23 02:43:44 +08:00
|
|
|
if (!cache->initialized)
|
|
|
|
return;
|
|
|
|
|
2015-08-18 08:21:57 +08:00
|
|
|
/*
|
|
|
|
* We iterate over the name hash here to be symmetric with the
|
|
|
|
* allocation of struct submodule entries. Each is allocated by
|
2018-02-14 08:09:31 +08:00
|
|
|
* their .gitmodules blob sha1 and submodule name.
|
2015-08-18 08:21:57 +08:00
|
|
|
*/
|
2019-10-07 07:30:38 +08:00
|
|
|
hashmap_for_each_entry(&cache->for_name, &iter, entry,
|
2019-10-07 07:30:41 +08:00
|
|
|
ent /* member name */)
|
2015-08-18 08:21:57 +08:00
|
|
|
free_one_config(entry);
|
|
|
|
|
2020-11-03 02:55:05 +08:00
|
|
|
hashmap_clear_and_free(&cache->for_path, struct submodule_entry, ent);
|
|
|
|
hashmap_clear_and_free(&cache->for_name, struct submodule_entry, ent);
|
2017-06-23 02:43:44 +08:00
|
|
|
cache->initialized = 0;
|
2017-08-04 02:19:58 +08:00
|
|
|
cache->gitmodules_read = 0;
|
2017-06-23 02:43:44 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void submodule_cache_free(struct submodule_cache *cache)
|
|
|
|
{
|
|
|
|
submodule_cache_clear(cache);
|
|
|
|
free(cache);
|
2015-08-18 08:21:57 +08:00
|
|
|
}
|
|
|
|
|
2018-05-02 08:25:42 +08:00
|
|
|
static unsigned int hash_oid_string(const struct object_id *oid,
|
|
|
|
const char *string)
|
2015-08-18 08:21:57 +08:00
|
|
|
{
|
2018-05-02 08:25:42 +08:00
|
|
|
return memhash(oid->hash, the_hash_algo->rawsz) + strhash(string);
|
2015-08-18 08:21:57 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void cache_put_path(struct submodule_cache *cache,
|
|
|
|
struct submodule *submodule)
|
|
|
|
{
|
2018-05-02 08:25:42 +08:00
|
|
|
unsigned int hash = hash_oid_string(&submodule->gitmodules_oid,
|
|
|
|
submodule->path);
|
2015-08-18 08:21:57 +08:00
|
|
|
struct submodule_entry *e = xmalloc(sizeof(*e));
|
2019-10-07 07:30:27 +08:00
|
|
|
hashmap_entry_init(&e->ent, hash);
|
2015-08-18 08:21:57 +08:00
|
|
|
e->config = submodule;
|
2019-10-07 07:30:32 +08:00
|
|
|
hashmap_put(&cache->for_path, &e->ent);
|
2015-08-18 08:21:57 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void cache_remove_path(struct submodule_cache *cache,
|
|
|
|
struct submodule *submodule)
|
|
|
|
{
|
2018-05-02 08:25:42 +08:00
|
|
|
unsigned int hash = hash_oid_string(&submodule->gitmodules_oid,
|
|
|
|
submodule->path);
|
2015-08-18 08:21:57 +08:00
|
|
|
struct submodule_entry e;
|
|
|
|
struct submodule_entry *removed;
|
2019-10-07 07:30:27 +08:00
|
|
|
hashmap_entry_init(&e.ent, hash);
|
2015-08-18 08:21:57 +08:00
|
|
|
e.config = submodule;
|
2019-10-07 07:30:42 +08:00
|
|
|
removed = hashmap_remove_entry(&cache->for_path, &e, ent, NULL);
|
2015-08-18 08:21:57 +08:00
|
|
|
free(removed);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void cache_add(struct submodule_cache *cache,
|
|
|
|
struct submodule *submodule)
|
|
|
|
{
|
2018-05-02 08:25:42 +08:00
|
|
|
unsigned int hash = hash_oid_string(&submodule->gitmodules_oid,
|
|
|
|
submodule->name);
|
2015-08-18 08:21:57 +08:00
|
|
|
struct submodule_entry *e = xmalloc(sizeof(*e));
|
2019-10-07 07:30:27 +08:00
|
|
|
hashmap_entry_init(&e->ent, hash);
|
2015-08-18 08:21:57 +08:00
|
|
|
e->config = submodule;
|
2019-10-07 07:30:29 +08:00
|
|
|
hashmap_add(&cache->for_name, &e->ent);
|
2015-08-18 08:21:57 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static const struct submodule *cache_lookup_path(struct submodule_cache *cache,
|
2018-05-02 08:25:42 +08:00
|
|
|
const struct object_id *gitmodules_oid, const char *path)
|
2015-08-18 08:21:57 +08:00
|
|
|
{
|
|
|
|
struct submodule_entry *entry;
|
2018-05-02 08:25:42 +08:00
|
|
|
unsigned int hash = hash_oid_string(gitmodules_oid, path);
|
2015-08-18 08:21:57 +08:00
|
|
|
struct submodule_entry key;
|
|
|
|
struct submodule key_config;
|
|
|
|
|
2018-05-02 08:25:42 +08:00
|
|
|
oidcpy(&key_config.gitmodules_oid, gitmodules_oid);
|
2015-08-18 08:21:57 +08:00
|
|
|
key_config.path = path;
|
|
|
|
|
2019-10-07 07:30:27 +08:00
|
|
|
hashmap_entry_init(&key.ent, hash);
|
2015-08-18 08:21:57 +08:00
|
|
|
key.config = &key_config;
|
|
|
|
|
2019-10-07 07:30:42 +08:00
|
|
|
entry = hashmap_get_entry(&cache->for_path, &key, ent, NULL);
|
2015-08-18 08:21:57 +08:00
|
|
|
if (entry)
|
|
|
|
return entry->config;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct submodule *cache_lookup_name(struct submodule_cache *cache,
|
2018-05-02 08:25:42 +08:00
|
|
|
const struct object_id *gitmodules_oid, const char *name)
|
2015-08-18 08:21:57 +08:00
|
|
|
{
|
|
|
|
struct submodule_entry *entry;
|
2018-05-02 08:25:42 +08:00
|
|
|
unsigned int hash = hash_oid_string(gitmodules_oid, name);
|
2015-08-18 08:21:57 +08:00
|
|
|
struct submodule_entry key;
|
|
|
|
struct submodule key_config;
|
|
|
|
|
2018-05-02 08:25:42 +08:00
|
|
|
oidcpy(&key_config.gitmodules_oid, gitmodules_oid);
|
2015-08-18 08:21:57 +08:00
|
|
|
key_config.name = name;
|
|
|
|
|
2019-10-07 07:30:27 +08:00
|
|
|
hashmap_entry_init(&key.ent, hash);
|
2015-08-18 08:21:57 +08:00
|
|
|
key.config = &key_config;
|
|
|
|
|
2019-10-07 07:30:42 +08:00
|
|
|
entry = hashmap_get_entry(&cache->for_name, &key, ent, NULL);
|
2015-08-18 08:21:57 +08:00
|
|
|
if (entry)
|
|
|
|
return entry->config;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
submodule-config: verify submodule names as paths
Submodule "names" come from the untrusted .gitmodules file,
but we blindly append them to $GIT_DIR/modules to create our
on-disk repo paths. This means you can do bad things by
putting "../" into the name (among other things).
Let's sanity-check these names to avoid building a path that
can be exploited. There are two main decisions:
1. What should the allowed syntax be?
It's tempting to reuse verify_path(), since submodule
names typically come from in-repo paths. But there are
two reasons not to:
a. It's technically more strict than what we need, as
we really care only about breaking out of the
$GIT_DIR/modules/ hierarchy. E.g., having a
submodule named "foo/.git" isn't actually
dangerous, and it's possible that somebody has
manually given such a funny name.
b. Since we'll eventually use this checking logic in
fsck to prevent downstream repositories, it should
be consistent across platforms. Because
verify_path() relies on is_dir_sep(), it wouldn't
block "foo\..\bar" on a non-Windows machine.
2. Where should we enforce it? These days most of the
.gitmodules reads go through submodule-config.c, so
I've put it there in the reading step. That should
cover all of the C code.
We also construct the name for "git submodule add"
inside the git-submodule.sh script. This is probably
not a big deal for security since the name is coming
from the user anyway, but it would be polite to remind
them if the name they pick is invalid (and we need to
expose the name-checker to the shell anyway for our
test scripts).
This patch issues a warning when reading .gitmodules
and just ignores the related config entry completely.
This will generally end up producing a sensible error,
as it works the same as a .gitmodules file which is
missing a submodule entry (so "submodule update" will
barf, but "git clone --recurse-submodules" will print
an error but not abort the clone.
There is one minor oddity, which is that we print the
warning once per malformed config key (since that's how
the config subsystem gives us the entries). So in the
new test, for example, the user would see three
warnings. That's OK, since the intent is that this case
should never come up outside of malicious repositories
(and then it might even benefit the user to see the
message multiple times).
Credit for finding this vulnerability and the proof of
concept from which the test script was adapted goes to
Etienne Stalmans.
Signed-off-by: Jeff King <peff@peff.net>
2018-04-30 15:25:25 +08:00
|
|
|
int check_submodule_name(const char *name)
|
|
|
|
{
|
|
|
|
/* Disallow empty names */
|
|
|
|
if (!*name)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
/*
|
2022-05-17 04:10:59 +08:00
|
|
|
* Look for '..' as a path component. Check is_xplatform_dir_sep() as
|
submodule-config: verify submodule names as paths
Submodule "names" come from the untrusted .gitmodules file,
but we blindly append them to $GIT_DIR/modules to create our
on-disk repo paths. This means you can do bad things by
putting "../" into the name (among other things).
Let's sanity-check these names to avoid building a path that
can be exploited. There are two main decisions:
1. What should the allowed syntax be?
It's tempting to reuse verify_path(), since submodule
names typically come from in-repo paths. But there are
two reasons not to:
a. It's technically more strict than what we need, as
we really care only about breaking out of the
$GIT_DIR/modules/ hierarchy. E.g., having a
submodule named "foo/.git" isn't actually
dangerous, and it's possible that somebody has
manually given such a funny name.
b. Since we'll eventually use this checking logic in
fsck to prevent downstream repositories, it should
be consistent across platforms. Because
verify_path() relies on is_dir_sep(), it wouldn't
block "foo\..\bar" on a non-Windows machine.
2. Where should we enforce it? These days most of the
.gitmodules reads go through submodule-config.c, so
I've put it there in the reading step. That should
cover all of the C code.
We also construct the name for "git submodule add"
inside the git-submodule.sh script. This is probably
not a big deal for security since the name is coming
from the user anyway, but it would be polite to remind
them if the name they pick is invalid (and we need to
expose the name-checker to the shell anyway for our
test scripts).
This patch issues a warning when reading .gitmodules
and just ignores the related config entry completely.
This will generally end up producing a sensible error,
as it works the same as a .gitmodules file which is
missing a submodule entry (so "submodule update" will
barf, but "git clone --recurse-submodules" will print
an error but not abort the clone.
There is one minor oddity, which is that we print the
warning once per malformed config key (since that's how
the config subsystem gives us the entries). So in the
new test, for example, the user would see three
warnings. That's OK, since the intent is that this case
should never come up outside of malicious repositories
(and then it might even benefit the user to see the
message multiple times).
Credit for finding this vulnerability and the proof of
concept from which the test script was adapted goes to
Etienne Stalmans.
Signed-off-by: Jeff King <peff@peff.net>
2018-04-30 15:25:25 +08:00
|
|
|
* separators rather than is_dir_sep(), because we want the name rules
|
|
|
|
* to be consistent across platforms.
|
|
|
|
*/
|
|
|
|
goto in_component; /* always start inside component */
|
|
|
|
while (*name) {
|
|
|
|
char c = *name++;
|
2022-05-17 04:10:59 +08:00
|
|
|
if (is_xplatform_dir_sep(c)) {
|
submodule-config: verify submodule names as paths
Submodule "names" come from the untrusted .gitmodules file,
but we blindly append them to $GIT_DIR/modules to create our
on-disk repo paths. This means you can do bad things by
putting "../" into the name (among other things).
Let's sanity-check these names to avoid building a path that
can be exploited. There are two main decisions:
1. What should the allowed syntax be?
It's tempting to reuse verify_path(), since submodule
names typically come from in-repo paths. But there are
two reasons not to:
a. It's technically more strict than what we need, as
we really care only about breaking out of the
$GIT_DIR/modules/ hierarchy. E.g., having a
submodule named "foo/.git" isn't actually
dangerous, and it's possible that somebody has
manually given such a funny name.
b. Since we'll eventually use this checking logic in
fsck to prevent downstream repositories, it should
be consistent across platforms. Because
verify_path() relies on is_dir_sep(), it wouldn't
block "foo\..\bar" on a non-Windows machine.
2. Where should we enforce it? These days most of the
.gitmodules reads go through submodule-config.c, so
I've put it there in the reading step. That should
cover all of the C code.
We also construct the name for "git submodule add"
inside the git-submodule.sh script. This is probably
not a big deal for security since the name is coming
from the user anyway, but it would be polite to remind
them if the name they pick is invalid (and we need to
expose the name-checker to the shell anyway for our
test scripts).
This patch issues a warning when reading .gitmodules
and just ignores the related config entry completely.
This will generally end up producing a sensible error,
as it works the same as a .gitmodules file which is
missing a submodule entry (so "submodule update" will
barf, but "git clone --recurse-submodules" will print
an error but not abort the clone.
There is one minor oddity, which is that we print the
warning once per malformed config key (since that's how
the config subsystem gives us the entries). So in the
new test, for example, the user would see three
warnings. That's OK, since the intent is that this case
should never come up outside of malicious repositories
(and then it might even benefit the user to see the
message multiple times).
Credit for finding this vulnerability and the proof of
concept from which the test script was adapted goes to
Etienne Stalmans.
Signed-off-by: Jeff King <peff@peff.net>
2018-04-30 15:25:25 +08:00
|
|
|
in_component:
|
|
|
|
if (name[0] == '.' && name[1] == '.' &&
|
2022-05-17 04:10:59 +08:00
|
|
|
(!name[2] || is_xplatform_dir_sep(name[2])))
|
submodule-config: verify submodule names as paths
Submodule "names" come from the untrusted .gitmodules file,
but we blindly append them to $GIT_DIR/modules to create our
on-disk repo paths. This means you can do bad things by
putting "../" into the name (among other things).
Let's sanity-check these names to avoid building a path that
can be exploited. There are two main decisions:
1. What should the allowed syntax be?
It's tempting to reuse verify_path(), since submodule
names typically come from in-repo paths. But there are
two reasons not to:
a. It's technically more strict than what we need, as
we really care only about breaking out of the
$GIT_DIR/modules/ hierarchy. E.g., having a
submodule named "foo/.git" isn't actually
dangerous, and it's possible that somebody has
manually given such a funny name.
b. Since we'll eventually use this checking logic in
fsck to prevent downstream repositories, it should
be consistent across platforms. Because
verify_path() relies on is_dir_sep(), it wouldn't
block "foo\..\bar" on a non-Windows machine.
2. Where should we enforce it? These days most of the
.gitmodules reads go through submodule-config.c, so
I've put it there in the reading step. That should
cover all of the C code.
We also construct the name for "git submodule add"
inside the git-submodule.sh script. This is probably
not a big deal for security since the name is coming
from the user anyway, but it would be polite to remind
them if the name they pick is invalid (and we need to
expose the name-checker to the shell anyway for our
test scripts).
This patch issues a warning when reading .gitmodules
and just ignores the related config entry completely.
This will generally end up producing a sensible error,
as it works the same as a .gitmodules file which is
missing a submodule entry (so "submodule update" will
barf, but "git clone --recurse-submodules" will print
an error but not abort the clone.
There is one minor oddity, which is that we print the
warning once per malformed config key (since that's how
the config subsystem gives us the entries). So in the
new test, for example, the user would see three
warnings. That's OK, since the intent is that this case
should never come up outside of malicious repositories
(and then it might even benefit the user to see the
message multiple times).
Credit for finding this vulnerability and the proof of
concept from which the test script was adapted goes to
Etienne Stalmans.
Signed-off-by: Jeff King <peff@peff.net>
2018-04-30 15:25:25 +08:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2024-01-18 09:55:15 +08:00
|
|
|
static int starts_with_dot_slash(const char *const path)
|
|
|
|
{
|
|
|
|
return path_match_flags(path, PATH_MATCH_STARTS_WITH_DOT_SLASH |
|
|
|
|
PATH_MATCH_XPLATFORM);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int starts_with_dot_dot_slash(const char *const path)
|
|
|
|
{
|
|
|
|
return path_match_flags(path, PATH_MATCH_STARTS_WITH_DOT_DOT_SLASH |
|
|
|
|
PATH_MATCH_XPLATFORM);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int submodule_url_is_relative(const char *url)
|
|
|
|
{
|
|
|
|
return starts_with_dot_slash(url) || starts_with_dot_dot_slash(url);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Count directory components that a relative submodule URL should chop
|
|
|
|
* from the remote_url it is to be resolved against.
|
|
|
|
*
|
|
|
|
* In other words, this counts "../" components at the start of a
|
|
|
|
* submodule URL.
|
|
|
|
*
|
|
|
|
* Returns the number of directory components to chop and writes a
|
|
|
|
* pointer to the next character of url after all leading "./" and
|
|
|
|
* "../" components to out.
|
|
|
|
*/
|
|
|
|
static int count_leading_dotdots(const char *url, const char **out)
|
|
|
|
{
|
|
|
|
int result = 0;
|
|
|
|
while (1) {
|
|
|
|
if (starts_with_dot_dot_slash(url)) {
|
|
|
|
result++;
|
|
|
|
url += strlen("../");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (starts_with_dot_slash(url)) {
|
|
|
|
url += strlen("./");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
*out = url;
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* Check whether a transport is implemented by git-remote-curl.
|
|
|
|
*
|
|
|
|
* If it is, returns 1 and writes the URL that would be passed to
|
|
|
|
* git-remote-curl to the "out" parameter.
|
|
|
|
*
|
|
|
|
* Otherwise, returns 0 and leaves "out" untouched.
|
|
|
|
*
|
|
|
|
* Examples:
|
|
|
|
* http::https://example.com/repo.git -> 1, https://example.com/repo.git
|
|
|
|
* https://example.com/repo.git -> 1, https://example.com/repo.git
|
|
|
|
* git://example.com/repo.git -> 0
|
|
|
|
*
|
|
|
|
* This is for use in checking for previously exploitable bugs that
|
|
|
|
* required a submodule URL to be passed to git-remote-curl.
|
|
|
|
*/
|
|
|
|
static int url_to_curl_url(const char *url, const char **out)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We don't need to check for case-aliases, "http.exe", and so
|
|
|
|
* on because in the default configuration, is_transport_allowed
|
|
|
|
* prevents URLs with those schemes from being cloned
|
|
|
|
* automatically.
|
|
|
|
*/
|
|
|
|
if (skip_prefix(url, "http::", out) ||
|
|
|
|
skip_prefix(url, "https::", out) ||
|
|
|
|
skip_prefix(url, "ftp::", out) ||
|
|
|
|
skip_prefix(url, "ftps::", out))
|
|
|
|
return 1;
|
|
|
|
if (starts_with(url, "http://") ||
|
|
|
|
starts_with(url, "https://") ||
|
|
|
|
starts_with(url, "ftp://") ||
|
|
|
|
starts_with(url, "ftps://")) {
|
|
|
|
*out = url;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int check_submodule_url(const char *url)
|
|
|
|
{
|
|
|
|
const char *curl_url;
|
|
|
|
|
|
|
|
if (looks_like_command_line_option(url))
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
if (submodule_url_is_relative(url) || starts_with(url, "git://")) {
|
|
|
|
char *decoded;
|
|
|
|
const char *next;
|
|
|
|
int has_nl;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This could be appended to an http URL and url-decoded;
|
|
|
|
* check for malicious characters.
|
|
|
|
*/
|
|
|
|
decoded = url_decode(url);
|
|
|
|
has_nl = !!strchr(decoded, '\n');
|
|
|
|
|
|
|
|
free(decoded);
|
|
|
|
if (has_nl)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* URLs which escape their root via "../" can overwrite
|
|
|
|
* the host field and previous components, resolving to
|
|
|
|
* URLs like https::example.com/submodule.git and
|
|
|
|
* https:///example.com/submodule.git that were
|
|
|
|
* susceptible to CVE-2020-11008.
|
|
|
|
*/
|
|
|
|
if (count_leading_dotdots(url, &next) > 0 &&
|
|
|
|
(*next == ':' || *next == '/'))
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
else if (url_to_curl_url(url, &curl_url)) {
|
|
|
|
int ret = 0;
|
2024-01-18 09:55:18 +08:00
|
|
|
char *normalized = url_normalize(curl_url, NULL);
|
|
|
|
if (normalized) {
|
|
|
|
char *decoded = url_decode(normalized);
|
|
|
|
if (strchr(decoded, '\n'))
|
|
|
|
ret = -1;
|
|
|
|
free(normalized);
|
|
|
|
free(decoded);
|
|
|
|
} else {
|
2024-01-18 09:55:15 +08:00
|
|
|
ret = -1;
|
2024-01-18 09:55:18 +08:00
|
|
|
}
|
|
|
|
|
2024-01-18 09:55:15 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-08-18 08:21:57 +08:00
|
|
|
static int name_and_item_from_var(const char *var, struct strbuf *name,
|
|
|
|
struct strbuf *item)
|
|
|
|
{
|
|
|
|
const char *subsection, *key;
|
2020-04-11 03:44:28 +08:00
|
|
|
size_t subsection_len;
|
|
|
|
int parse;
|
2015-08-18 08:21:57 +08:00
|
|
|
parse = parse_config_key(var, "submodule", &subsection,
|
|
|
|
&subsection_len, &key);
|
|
|
|
if (parse < 0 || !subsection)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
strbuf_add(name, subsection, subsection_len);
|
submodule-config: verify submodule names as paths
Submodule "names" come from the untrusted .gitmodules file,
but we blindly append them to $GIT_DIR/modules to create our
on-disk repo paths. This means you can do bad things by
putting "../" into the name (among other things).
Let's sanity-check these names to avoid building a path that
can be exploited. There are two main decisions:
1. What should the allowed syntax be?
It's tempting to reuse verify_path(), since submodule
names typically come from in-repo paths. But there are
two reasons not to:
a. It's technically more strict than what we need, as
we really care only about breaking out of the
$GIT_DIR/modules/ hierarchy. E.g., having a
submodule named "foo/.git" isn't actually
dangerous, and it's possible that somebody has
manually given such a funny name.
b. Since we'll eventually use this checking logic in
fsck to prevent downstream repositories, it should
be consistent across platforms. Because
verify_path() relies on is_dir_sep(), it wouldn't
block "foo\..\bar" on a non-Windows machine.
2. Where should we enforce it? These days most of the
.gitmodules reads go through submodule-config.c, so
I've put it there in the reading step. That should
cover all of the C code.
We also construct the name for "git submodule add"
inside the git-submodule.sh script. This is probably
not a big deal for security since the name is coming
from the user anyway, but it would be polite to remind
them if the name they pick is invalid (and we need to
expose the name-checker to the shell anyway for our
test scripts).
This patch issues a warning when reading .gitmodules
and just ignores the related config entry completely.
This will generally end up producing a sensible error,
as it works the same as a .gitmodules file which is
missing a submodule entry (so "submodule update" will
barf, but "git clone --recurse-submodules" will print
an error but not abort the clone.
There is one minor oddity, which is that we print the
warning once per malformed config key (since that's how
the config subsystem gives us the entries). So in the
new test, for example, the user would see three
warnings. That's OK, since the intent is that this case
should never come up outside of malicious repositories
(and then it might even benefit the user to see the
message multiple times).
Credit for finding this vulnerability and the proof of
concept from which the test script was adapted goes to
Etienne Stalmans.
Signed-off-by: Jeff King <peff@peff.net>
2018-04-30 15:25:25 +08:00
|
|
|
if (check_submodule_name(name->buf) < 0) {
|
|
|
|
warning(_("ignoring suspicious submodule name: %s"), name->buf);
|
|
|
|
strbuf_release(name);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-08-18 08:21:57 +08:00
|
|
|
strbuf_addstr(item, key);
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct submodule *lookup_or_create_by_name(struct submodule_cache *cache,
|
2018-05-02 08:25:42 +08:00
|
|
|
const struct object_id *gitmodules_oid, const char *name)
|
2015-08-18 08:21:57 +08:00
|
|
|
{
|
|
|
|
struct submodule *submodule;
|
|
|
|
struct strbuf name_buf = STRBUF_INIT;
|
|
|
|
|
2018-05-02 08:25:42 +08:00
|
|
|
submodule = cache_lookup_name(cache, gitmodules_oid, name);
|
2015-08-18 08:21:57 +08:00
|
|
|
if (submodule)
|
|
|
|
return submodule;
|
|
|
|
|
|
|
|
submodule = xmalloc(sizeof(*submodule));
|
|
|
|
|
|
|
|
strbuf_addstr(&name_buf, name);
|
|
|
|
submodule->name = strbuf_detach(&name_buf, NULL);
|
|
|
|
|
|
|
|
submodule->path = NULL;
|
|
|
|
submodule->url = NULL;
|
2016-03-01 10:07:11 +08:00
|
|
|
submodule->update_strategy.type = SM_UPDATE_UNSPECIFIED;
|
|
|
|
submodule->update_strategy.command = NULL;
|
2015-08-18 08:21:57 +08:00
|
|
|
submodule->fetch_recurse = RECURSE_SUBMODULES_NONE;
|
|
|
|
submodule->ignore = NULL;
|
2016-07-29 08:44:07 +08:00
|
|
|
submodule->branch = NULL;
|
2016-05-27 05:59:42 +08:00
|
|
|
submodule->recommend_shallow = -1;
|
2015-08-18 08:21:57 +08:00
|
|
|
|
2018-05-02 08:25:42 +08:00
|
|
|
oidcpy(&submodule->gitmodules_oid, gitmodules_oid);
|
2015-08-18 08:21:57 +08:00
|
|
|
|
|
|
|
cache_add(cache, submodule);
|
|
|
|
|
|
|
|
return submodule;
|
|
|
|
}
|
|
|
|
|
2015-08-18 08:22:00 +08:00
|
|
|
static int parse_fetch_recurse(const char *opt, const char *arg,
|
|
|
|
int die_on_error)
|
|
|
|
{
|
2017-08-08 02:20:49 +08:00
|
|
|
switch (git_parse_maybe_bool(arg)) {
|
2015-08-18 08:22:00 +08:00
|
|
|
case 1:
|
|
|
|
return RECURSE_SUBMODULES_ON;
|
|
|
|
case 0:
|
|
|
|
return RECURSE_SUBMODULES_OFF;
|
|
|
|
default:
|
|
|
|
if (!strcmp(arg, "on-demand"))
|
|
|
|
return RECURSE_SUBMODULES_ON_DEMAND;
|
2019-02-16 19:24:41 +08:00
|
|
|
/*
|
|
|
|
* Please update $__git_fetch_recurse_submodules in
|
|
|
|
* git-completion.bash when you add new options.
|
|
|
|
*/
|
2015-08-18 08:22:00 +08:00
|
|
|
if (die_on_error)
|
|
|
|
die("bad %s argument: %s", opt, arg);
|
|
|
|
else
|
|
|
|
return RECURSE_SUBMODULES_ERROR;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
config: pass kvi to die_bad_number()
Plumb "struct key_value_info" through all code paths that end in
die_bad_number(), which lets us remove the helper functions that read
analogous values from "struct config_reader". As a result, nothing reads
config_reader.config_kvi any more, so remove that too.
In config.c, this requires changing the signature of
git_configset_get_value() to 'return' "kvi" in an out parameter so that
git_configset_get_<type>() can pass it to git_config_<type>(). Only
numeric types will use "kvi", so for non-numeric types (e.g.
git_configset_get_string()), pass NULL to indicate that the out
parameter isn't needed.
Outside of config.c, config callbacks now need to pass "ctx->kvi" to any
of the git_config_<type>() functions that parse a config string into a
number type. Included is a .cocci patch to make that refactor.
The only exceptional case is builtin/config.c, where git_config_<type>()
is called outside of a config callback (namely, on user-provided input),
so config source information has never been available. In this case,
die_bad_number() defaults to a generic, but perfectly descriptive
message. Let's provide a safe, non-NULL for "kvi" anyway, but make sure
not to change the message.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-29 03:26:27 +08:00
|
|
|
int parse_submodule_fetchjobs(const char *var, const char *value,
|
|
|
|
const struct key_value_info *kvi)
|
2017-08-03 03:49:18 +08:00
|
|
|
{
|
config: pass kvi to die_bad_number()
Plumb "struct key_value_info" through all code paths that end in
die_bad_number(), which lets us remove the helper functions that read
analogous values from "struct config_reader". As a result, nothing reads
config_reader.config_kvi any more, so remove that too.
In config.c, this requires changing the signature of
git_configset_get_value() to 'return' "kvi" in an out parameter so that
git_configset_get_<type>() can pass it to git_config_<type>(). Only
numeric types will use "kvi", so for non-numeric types (e.g.
git_configset_get_string()), pass NULL to indicate that the out
parameter isn't needed.
Outside of config.c, config callbacks now need to pass "ctx->kvi" to any
of the git_config_<type>() functions that parse a config string into a
number type. Included is a .cocci patch to make that refactor.
The only exceptional case is builtin/config.c, where git_config_<type>()
is called outside of a config callback (namely, on user-provided input),
so config source information has never been available. In this case,
die_bad_number() defaults to a generic, but perfectly descriptive
message. Let's provide a safe, non-NULL for "kvi" anyway, but make sure
not to change the message.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-29 03:26:27 +08:00
|
|
|
int fetchjobs = git_config_int(var, value, kvi);
|
2017-08-03 03:49:18 +08:00
|
|
|
if (fetchjobs < 0)
|
2022-06-17 18:03:09 +08:00
|
|
|
die(_("negative values not allowed for submodule.fetchJobs"));
|
2022-10-13 05:02:24 +08:00
|
|
|
if (!fetchjobs)
|
|
|
|
fetchjobs = online_cpus();
|
2017-08-03 03:49:18 +08:00
|
|
|
return fetchjobs;
|
|
|
|
}
|
|
|
|
|
2015-08-18 08:22:00 +08:00
|
|
|
int parse_fetch_recurse_submodules_arg(const char *opt, const char *arg)
|
|
|
|
{
|
|
|
|
return parse_fetch_recurse(opt, arg, 1);
|
|
|
|
}
|
|
|
|
|
2017-06-24 03:13:00 +08:00
|
|
|
int option_fetch_parse_recurse_submodules(const struct option *opt,
|
|
|
|
const char *arg, int unset)
|
|
|
|
{
|
|
|
|
int *v;
|
|
|
|
|
|
|
|
if (!opt->value)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
v = opt->value;
|
|
|
|
|
|
|
|
if (unset) {
|
|
|
|
*v = RECURSE_SUBMODULES_OFF;
|
|
|
|
} else {
|
|
|
|
if (arg)
|
|
|
|
*v = parse_fetch_recurse_submodules_arg(opt->long_name, arg);
|
|
|
|
else
|
|
|
|
*v = RECURSE_SUBMODULES_ON;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-03-15 05:46:32 +08:00
|
|
|
static int parse_update_recurse(const char *opt, const char *arg,
|
|
|
|
int die_on_error)
|
|
|
|
{
|
2017-08-23 01:29:03 +08:00
|
|
|
switch (git_parse_maybe_bool(arg)) {
|
2017-03-15 05:46:32 +08:00
|
|
|
case 1:
|
|
|
|
return RECURSE_SUBMODULES_ON;
|
|
|
|
case 0:
|
|
|
|
return RECURSE_SUBMODULES_OFF;
|
|
|
|
default:
|
|
|
|
if (die_on_error)
|
|
|
|
die("bad %s argument: %s", opt, arg);
|
|
|
|
return RECURSE_SUBMODULES_ERROR;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
int parse_update_recurse_submodules_arg(const char *opt, const char *arg)
|
|
|
|
{
|
|
|
|
return parse_update_recurse(opt, arg, 1);
|
|
|
|
}
|
|
|
|
|
2015-11-17 19:05:56 +08:00
|
|
|
static int parse_push_recurse(const char *opt, const char *arg,
|
|
|
|
int die_on_error)
|
|
|
|
{
|
2017-08-08 02:20:49 +08:00
|
|
|
switch (git_parse_maybe_bool(arg)) {
|
2015-11-17 19:05:56 +08:00
|
|
|
case 1:
|
|
|
|
/* There's no simple "on" value when pushing */
|
|
|
|
if (die_on_error)
|
|
|
|
die("bad %s argument: %s", opt, arg);
|
|
|
|
else
|
|
|
|
return RECURSE_SUBMODULES_ERROR;
|
|
|
|
case 0:
|
|
|
|
return RECURSE_SUBMODULES_OFF;
|
|
|
|
default:
|
|
|
|
if (!strcmp(arg, "on-demand"))
|
|
|
|
return RECURSE_SUBMODULES_ON_DEMAND;
|
|
|
|
else if (!strcmp(arg, "check"))
|
|
|
|
return RECURSE_SUBMODULES_CHECK;
|
2016-12-20 02:25:32 +08:00
|
|
|
else if (!strcmp(arg, "only"))
|
|
|
|
return RECURSE_SUBMODULES_ONLY;
|
2019-02-16 19:24:41 +08:00
|
|
|
/*
|
|
|
|
* Please update $__git_push_recurse_submodules in
|
|
|
|
* git-completion.bash when you add new modes.
|
|
|
|
*/
|
2015-11-17 19:05:56 +08:00
|
|
|
else if (die_on_error)
|
|
|
|
die("bad %s argument: %s", opt, arg);
|
|
|
|
else
|
|
|
|
return RECURSE_SUBMODULES_ERROR;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
int parse_push_recurse_submodules_arg(const char *opt, const char *arg)
|
|
|
|
{
|
|
|
|
return parse_push_recurse(opt, arg, 1);
|
|
|
|
}
|
|
|
|
|
2018-05-02 08:25:42 +08:00
|
|
|
static void warn_multiple_config(const struct object_id *treeish_name,
|
2015-08-18 08:21:57 +08:00
|
|
|
const char *name, const char *option)
|
|
|
|
{
|
|
|
|
const char *commit_string = "WORKTREE";
|
2016-11-23 04:14:37 +08:00
|
|
|
if (treeish_name)
|
2018-05-02 08:25:42 +08:00
|
|
|
commit_string = oid_to_hex(treeish_name);
|
2015-08-18 08:21:57 +08:00
|
|
|
warning("%s:.gitmodules, multiple configurations found for "
|
|
|
|
"'submodule.%s.%s'. Skipping second one!",
|
|
|
|
commit_string, name, option);
|
|
|
|
}
|
|
|
|
|
submodule-config: ban submodule urls that start with dash
The previous commit taught the submodule code to invoke our
"git clone $url $path" with a "--" separator so that we
aren't confused by urls or paths that start with dashes.
However, that's just one code path. It's not clear if there
are others, and it would be an easy mistake to add one in
the future. Moreover, even with the fix in the previous
commit, it's quite hard to actually do anything useful with
such an entry. Any url starting with a dash must fall into
one of three categories:
- it's meant as a file url, like "-path". But then any
clone is not going to have the matching path, since it's
by definition relative inside the newly created clone. If
you spell it as "./-path", the submodule code sees the
"/" and translates this to an absolute path, so it at
least works (assuming the receiver has the same
filesystem layout as you). But that trick does not apply
for a bare "-path".
- it's meant as an ssh url, like "-host:path". But this
already doesn't work, as we explicitly disallow ssh
hostnames that begin with a dash (to avoid option
injection against ssh).
- it's a remote-helper scheme, like "-scheme::data". This
_could_ work if the receiver bends over backwards and
creates a funny-named helper like "git-remote--scheme".
But normally there would not be any helper that matches.
Since such a url does not work today and is not likely to do
anything useful in the future, let's simply disallow them
entirely. That protects the existing "git clone" path (in a
belt-and-suspenders way), along with any others that might
exist.
Our tests cover two cases:
1. A file url with "./" continues to work, showing that
there's an escape hatch for people with truly silly
repo names.
2. A url starting with "-" is rejected.
Note that we expect case (2) to fail, but it would have done
so even without this commit, for the reasons given above.
So instead of just expecting failure, let's also check for
the magic word "ignoring" on stderr. That lets us know that
we failed for the right reason.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-24 16:36:30 +08:00
|
|
|
static void warn_command_line_option(const char *var, const char *value)
|
|
|
|
{
|
|
|
|
warning(_("ignoring '%s' which may be interpreted as"
|
|
|
|
" a command-line option: %s"), var, value);
|
|
|
|
}
|
|
|
|
|
2015-08-18 08:21:57 +08:00
|
|
|
struct parse_config_parameter {
|
|
|
|
struct submodule_cache *cache;
|
2018-05-02 08:25:42 +08:00
|
|
|
const struct object_id *treeish_name;
|
|
|
|
const struct object_id *gitmodules_oid;
|
2015-08-18 08:21:57 +08:00
|
|
|
int overwrite;
|
|
|
|
};
|
|
|
|
|
submodule: reject submodule.update = !command in .gitmodules
Since ac1fbbda2013 (submodule: do not copy unknown update mode from
.gitmodules, 2013-12-02), Git has been careful to avoid copying
[submodule "foo"]
update = !run an arbitrary scary command
from .gitmodules to a repository's local config, copying in the
setting 'update = none' instead. The gitmodules(5) manpage documents
the intention:
The !command form is intentionally ignored here for security
reasons
Unfortunately, starting with v2.20.0-rc0 (which integrated ee69b2a9
(submodule--helper: introduce new update-module-mode helper,
2018-08-13, first released in v2.20.0-rc0)), there are scenarios where
we *don't* ignore it: if the config store contains no
submodule.foo.update setting, the submodule-config API falls back to
reading .gitmodules and the repository-supplied !command gets run
after all.
This was part of a general change over time in submodule support to
read more directly from .gitmodules, since unlike .git/config it
allows a project to change values between branches and over time
(while still allowing .git/config to override things). But it was
never intended to apply to this kind of dangerous configuration.
The behavior change was not advertised in ee69b2a9's commit message
and was missed in review.
Let's take the opportunity to make the protection more robust, even in
Git versions that are technically not affected: instead of quietly
converting 'update = !command' to 'update = none', noisily treat it as
an error. Allowing the setting but treating it as meaning something
else was just confusing; users are better served by seeing the error
sooner. Forbidding the construct makes the semantics simpler and
means we can check for it in fsck (in a separate patch).
As a result, the submodule-config API cannot read this value from
.gitmodules under any circumstance, and we can declare with confidence
For security reasons, the '!command' form is not accepted
here.
Reported-by: Joern Schneeweisz <jschneeweisz@gitlab.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
2019-12-05 17:28:28 +08:00
|
|
|
/*
|
|
|
|
* Parse a config item from .gitmodules.
|
|
|
|
*
|
|
|
|
* This does not handle submodule-related configuration from the main
|
|
|
|
* config store (.git/config, etc). Callers are responsible for
|
|
|
|
* checking for overrides in the main config store when appropriate.
|
|
|
|
*/
|
config: add ctx arg to config_fn_t
Add a new "const struct config_context *ctx" arg to config_fn_t to hold
additional information about the config iteration operation.
config_context has a "struct key_value_info kvi" member that holds
metadata about the config source being read (e.g. what kind of config
source it is, the filename, etc). In this series, we're only interested
in .kvi, so we could have just used "struct key_value_info" as an arg,
but config_context makes it possible to add/adjust members in the future
without changing the config_fn_t signature. We could also consider other
ways of organizing the args (e.g. moving the config name and value into
config_context or key_value_info), but in my experiments, the
incremental benefit doesn't justify the added complexity (e.g. a
config_fn_t will sometimes invoke another config_fn_t but with a
different config value).
In subsequent commits, the .kvi member will replace the global "struct
config_reader" in config.c, making config iteration a global-free
operation. It requires much more work for the machinery to provide
meaningful values of .kvi, so for now, merely change the signature and
call sites, pass NULL as a placeholder value, and don't rely on the arg
in any meaningful way.
Most of the changes are performed by
contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every
config_fn_t:
- Modifies the signature to accept "const struct config_context *ctx"
- Passes "ctx" to any inner config_fn_t, if needed
- Adds UNUSED attributes to "ctx", if needed
Most config_fn_t instances are easily identified by seeing if they are
called by the various config functions. Most of the remaining ones are
manually named in the .cocci patch. Manual cleanups are still needed,
but the majority of it is trivial; it's either adjusting config_fn_t
that the .cocci patch didn't catch, or adding forward declarations of
"struct config_context ctx" to make the signatures make sense.
The non-trivial changes are in cases where we are invoking a config_fn_t
outside of config machinery, and we now need to decide what value of
"ctx" to pass. These cases are:
- trace2/tr2_cfg.c:tr2_cfg_set_fl()
This is indirectly called by git_config_set() so that the trace2
machinery can notice the new config values and update its settings
using the tr2 config parsing function, i.e. tr2_cfg_cb().
- builtin/checkout.c:checkout_main()
This calls git_xmerge_config() as a shorthand for parsing a CLI arg.
This might be worth refactoring away in the future, since
git_xmerge_config() can call git_default_config(), which can do much
more than just parsing.
Handle them by creating a KVI_INIT macro that initializes "struct
key_value_info" to a reasonable default, and use that to construct the
"ctx" arg.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-29 03:26:22 +08:00
|
|
|
static int parse_config(const char *var, const char *value,
|
|
|
|
const struct config_context *ctx UNUSED, void *data)
|
2015-08-18 08:21:57 +08:00
|
|
|
{
|
|
|
|
struct parse_config_parameter *me = data;
|
|
|
|
struct submodule *submodule;
|
|
|
|
struct strbuf name = STRBUF_INIT, item = STRBUF_INIT;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
/* this also ensures that we only parse submodule entries */
|
|
|
|
if (!name_and_item_from_var(var, &name, &item))
|
|
|
|
return 0;
|
|
|
|
|
2015-10-13 01:58:58 +08:00
|
|
|
submodule = lookup_or_create_by_name(me->cache,
|
2018-05-02 08:25:42 +08:00
|
|
|
me->gitmodules_oid,
|
2015-10-13 01:58:58 +08:00
|
|
|
name.buf);
|
2015-08-18 08:21:57 +08:00
|
|
|
|
|
|
|
if (!strcmp(item.buf, "path")) {
|
2015-10-13 01:58:58 +08:00
|
|
|
if (!value)
|
2015-08-18 08:21:57 +08:00
|
|
|
ret = config_error_nonbool(var);
|
submodule-config: ban submodule paths that start with a dash
We recently banned submodule urls that look like
command-line options. This is the matching change to ban
leading-dash paths.
As with the urls, this should not break any use cases that
currently work. Even with our "--" separator passed to
git-clone, git-submodule.sh gets confused. Without the code
portion of this patch, the clone of "-sub" added in t7417
would yield results like:
/path/to/git-submodule: 410: cd: Illegal option -s
/path/to/git-submodule: 417: cd: Illegal option -s
/path/to/git-submodule: 410: cd: Illegal option -s
/path/to/git-submodule: 417: cd: Illegal option -s
Fetched in submodule path '-sub', but it did not contain b56243f8f4eb91b2f1f8109452e659f14dd3fbe4. Direct fetching of that commit failed.
Moreover, naively adding such a submodule doesn't work:
$ git submodule add $url -sub
The following path is ignored by one of your .gitignore files:
-sub
even though there is no such ignore pattern (the test script
hacks around this with a well-placed "git mv").
Unlike leading-dash urls, though, it's possible that such a
path _could_ be useful if we eventually made it work. So
this commit should be seen not as recommending a particular
policy, but rather temporarily closing off a broken and
possibly dangerous code-path. We may revisit this decision
later.
There are two minor differences to the tests in t7416 (that
covered urls):
1. We don't have a "./-sub" escape hatch to make this
work, since the submodule code expects to be able to
match canonical index names to the path field (so you
are free to add submodule config with that path, but we
would never actually use it, since an index entry would
never start with "./").
2. After this patch, cloning actually succeeds. Since we
ignore the submodule.*.path value, we fail to find a
config stanza for our submodule at all, and simply
treat it as inactive. We still check for the "ignoring"
message.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-24 16:39:55 +08:00
|
|
|
else if (looks_like_command_line_option(value))
|
|
|
|
warn_command_line_option(var, value);
|
2016-03-01 10:07:12 +08:00
|
|
|
else if (!me->overwrite && submodule->path)
|
2016-11-23 04:14:37 +08:00
|
|
|
warn_multiple_config(me->treeish_name, submodule->name,
|
2015-08-18 08:21:57 +08:00
|
|
|
"path");
|
2015-10-13 01:58:58 +08:00
|
|
|
else {
|
|
|
|
if (submodule->path)
|
|
|
|
cache_remove_path(me->cache, submodule);
|
|
|
|
free((void *) submodule->path);
|
|
|
|
submodule->path = xstrdup(value);
|
|
|
|
cache_put_path(me->cache, submodule);
|
2015-08-18 08:21:57 +08:00
|
|
|
}
|
|
|
|
} else if (!strcmp(item.buf, "fetchrecursesubmodules")) {
|
2015-08-18 08:22:00 +08:00
|
|
|
/* when parsing worktree configurations we can die early */
|
2018-05-02 08:25:42 +08:00
|
|
|
int die_on_error = is_null_oid(me->gitmodules_oid);
|
2015-08-18 08:21:57 +08:00
|
|
|
if (!me->overwrite &&
|
2015-10-13 01:58:58 +08:00
|
|
|
submodule->fetch_recurse != RECURSE_SUBMODULES_NONE)
|
2016-11-23 04:14:37 +08:00
|
|
|
warn_multiple_config(me->treeish_name, submodule->name,
|
2015-08-18 08:21:57 +08:00
|
|
|
"fetchrecursesubmodules");
|
2015-10-13 01:58:58 +08:00
|
|
|
else
|
|
|
|
submodule->fetch_recurse = parse_fetch_recurse(
|
|
|
|
var, value,
|
2015-08-18 08:22:00 +08:00
|
|
|
die_on_error);
|
2015-08-18 08:21:57 +08:00
|
|
|
} else if (!strcmp(item.buf, "ignore")) {
|
2015-10-13 01:58:58 +08:00
|
|
|
if (!value)
|
|
|
|
ret = config_error_nonbool(var);
|
2016-03-01 10:07:12 +08:00
|
|
|
else if (!me->overwrite && submodule->ignore)
|
2016-11-23 04:14:37 +08:00
|
|
|
warn_multiple_config(me->treeish_name, submodule->name,
|
2015-08-18 08:21:57 +08:00
|
|
|
"ignore");
|
2015-10-13 01:58:58 +08:00
|
|
|
else if (strcmp(value, "untracked") &&
|
|
|
|
strcmp(value, "dirty") &&
|
|
|
|
strcmp(value, "all") &&
|
|
|
|
strcmp(value, "none"))
|
2015-08-18 08:21:57 +08:00
|
|
|
warning("Invalid parameter '%s' for config option "
|
2017-03-15 06:14:40 +08:00
|
|
|
"'submodule.%s.ignore'", value, name.buf);
|
2015-10-13 01:58:58 +08:00
|
|
|
else {
|
|
|
|
free((void *) submodule->ignore);
|
|
|
|
submodule->ignore = xstrdup(value);
|
2015-08-18 08:21:57 +08:00
|
|
|
}
|
|
|
|
} else if (!strcmp(item.buf, "url")) {
|
|
|
|
if (!value) {
|
|
|
|
ret = config_error_nonbool(var);
|
submodule-config: ban submodule urls that start with dash
The previous commit taught the submodule code to invoke our
"git clone $url $path" with a "--" separator so that we
aren't confused by urls or paths that start with dashes.
However, that's just one code path. It's not clear if there
are others, and it would be an easy mistake to add one in
the future. Moreover, even with the fix in the previous
commit, it's quite hard to actually do anything useful with
such an entry. Any url starting with a dash must fall into
one of three categories:
- it's meant as a file url, like "-path". But then any
clone is not going to have the matching path, since it's
by definition relative inside the newly created clone. If
you spell it as "./-path", the submodule code sees the
"/" and translates this to an absolute path, so it at
least works (assuming the receiver has the same
filesystem layout as you). But that trick does not apply
for a bare "-path".
- it's meant as an ssh url, like "-host:path". But this
already doesn't work, as we explicitly disallow ssh
hostnames that begin with a dash (to avoid option
injection against ssh).
- it's a remote-helper scheme, like "-scheme::data". This
_could_ work if the receiver bends over backwards and
creates a funny-named helper like "git-remote--scheme".
But normally there would not be any helper that matches.
Since such a url does not work today and is not likely to do
anything useful in the future, let's simply disallow them
entirely. That protects the existing "git clone" path (in a
belt-and-suspenders way), along with any others that might
exist.
Our tests cover two cases:
1. A file url with "./" continues to work, showing that
there's an escape hatch for people with truly silly
repo names.
2. A url starting with "-" is rejected.
Note that we expect case (2) to fail, but it would have done
so even without this commit, for the reasons given above.
So instead of just expecting failure, let's also check for
the magic word "ignoring" on stderr. That lets us know that
we failed for the right reason.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-24 16:36:30 +08:00
|
|
|
} else if (looks_like_command_line_option(value)) {
|
|
|
|
warn_command_line_option(var, value);
|
2016-03-01 10:07:12 +08:00
|
|
|
} else if (!me->overwrite && submodule->url) {
|
2016-11-23 04:14:37 +08:00
|
|
|
warn_multiple_config(me->treeish_name, submodule->name,
|
2015-08-18 08:21:57 +08:00
|
|
|
"url");
|
2015-10-13 01:58:58 +08:00
|
|
|
} else {
|
|
|
|
free((void *) submodule->url);
|
|
|
|
submodule->url = xstrdup(value);
|
2015-08-18 08:21:57 +08:00
|
|
|
}
|
2016-03-01 10:07:11 +08:00
|
|
|
} else if (!strcmp(item.buf, "update")) {
|
|
|
|
if (!value)
|
|
|
|
ret = config_error_nonbool(var);
|
|
|
|
else if (!me->overwrite &&
|
|
|
|
submodule->update_strategy.type != SM_UPDATE_UNSPECIFIED)
|
2016-11-23 04:14:37 +08:00
|
|
|
warn_multiple_config(me->treeish_name, submodule->name,
|
2016-03-01 10:07:11 +08:00
|
|
|
"update");
|
|
|
|
else if (parse_submodule_update_strategy(value,
|
submodule: reject submodule.update = !command in .gitmodules
Since ac1fbbda2013 (submodule: do not copy unknown update mode from
.gitmodules, 2013-12-02), Git has been careful to avoid copying
[submodule "foo"]
update = !run an arbitrary scary command
from .gitmodules to a repository's local config, copying in the
setting 'update = none' instead. The gitmodules(5) manpage documents
the intention:
The !command form is intentionally ignored here for security
reasons
Unfortunately, starting with v2.20.0-rc0 (which integrated ee69b2a9
(submodule--helper: introduce new update-module-mode helper,
2018-08-13, first released in v2.20.0-rc0)), there are scenarios where
we *don't* ignore it: if the config store contains no
submodule.foo.update setting, the submodule-config API falls back to
reading .gitmodules and the repository-supplied !command gets run
after all.
This was part of a general change over time in submodule support to
read more directly from .gitmodules, since unlike .git/config it
allows a project to change values between branches and over time
(while still allowing .git/config to override things). But it was
never intended to apply to this kind of dangerous configuration.
The behavior change was not advertised in ee69b2a9's commit message
and was missed in review.
Let's take the opportunity to make the protection more robust, even in
Git versions that are technically not affected: instead of quietly
converting 'update = !command' to 'update = none', noisily treat it as
an error. Allowing the setting but treating it as meaning something
else was just confusing; users are better served by seeing the error
sooner. Forbidding the construct makes the semantics simpler and
means we can check for it in fsck (in a separate patch).
As a result, the submodule-config API cannot read this value from
.gitmodules under any circumstance, and we can declare with confidence
For security reasons, the '!command' form is not accepted
here.
Reported-by: Joern Schneeweisz <jschneeweisz@gitlab.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
2019-12-05 17:28:28 +08:00
|
|
|
&submodule->update_strategy) < 0 ||
|
|
|
|
submodule->update_strategy.type == SM_UPDATE_COMMAND)
|
2022-02-01 06:07:47 +08:00
|
|
|
die(_("invalid value for '%s'"), var);
|
2016-05-27 05:59:42 +08:00
|
|
|
} else if (!strcmp(item.buf, "shallow")) {
|
|
|
|
if (!me->overwrite && submodule->recommend_shallow != -1)
|
2016-11-23 04:14:37 +08:00
|
|
|
warn_multiple_config(me->treeish_name, submodule->name,
|
2016-05-27 05:59:42 +08:00
|
|
|
"shallow");
|
2016-07-29 08:44:07 +08:00
|
|
|
else
|
2016-05-27 05:59:42 +08:00
|
|
|
submodule->recommend_shallow =
|
|
|
|
git_config_bool(var, value);
|
2016-07-29 08:44:07 +08:00
|
|
|
} else if (!strcmp(item.buf, "branch")) {
|
2023-12-07 15:11:29 +08:00
|
|
|
if (!value)
|
|
|
|
ret = config_error_nonbool(var);
|
|
|
|
else if (!me->overwrite && submodule->branch)
|
2016-11-23 04:14:37 +08:00
|
|
|
warn_multiple_config(me->treeish_name, submodule->name,
|
2016-07-29 08:44:07 +08:00
|
|
|
"branch");
|
|
|
|
else {
|
|
|
|
free((void *)submodule->branch);
|
|
|
|
submodule->branch = xstrdup(value);
|
2016-05-27 05:59:42 +08:00
|
|
|
}
|
2015-08-18 08:21:57 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
strbuf_release(&name);
|
|
|
|
strbuf_release(&item);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2017-08-04 02:19:57 +08:00
|
|
|
static int gitmodule_oid_from_commit(const struct object_id *treeish_name,
|
|
|
|
struct object_id *gitmodules_oid,
|
|
|
|
struct strbuf *rev)
|
2015-08-18 08:21:57 +08:00
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
2017-07-14 07:49:20 +08:00
|
|
|
if (is_null_oid(treeish_name)) {
|
2024-06-14 14:49:54 +08:00
|
|
|
oidclr(gitmodules_oid, the_repository->hash_algo);
|
2015-08-18 08:21:57 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2017-07-14 07:49:20 +08:00
|
|
|
strbuf_addf(rev, "%s:.gitmodules", oid_to_hex(treeish_name));
|
2023-03-28 21:58:46 +08:00
|
|
|
if (repo_get_oid(the_repository, rev->buf, gitmodules_oid) >= 0)
|
2015-08-18 08:21:57 +08:00
|
|
|
ret = 1;
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* This does a lookup of a submodule configuration by name or by path
|
|
|
|
* (key) with on-demand reading of the appropriate .gitmodules from
|
|
|
|
* revisions.
|
|
|
|
*/
|
|
|
|
static const struct submodule *config_from(struct submodule_cache *cache,
|
2017-07-14 07:49:20 +08:00
|
|
|
const struct object_id *treeish_name, const char *key,
|
2015-08-18 08:21:57 +08:00
|
|
|
enum lookup_type lookup_type)
|
|
|
|
{
|
|
|
|
struct strbuf rev = STRBUF_INIT;
|
|
|
|
unsigned long config_size;
|
2016-07-28 20:49:47 +08:00
|
|
|
char *config = NULL;
|
2017-07-14 07:49:20 +08:00
|
|
|
struct object_id oid;
|
2015-08-18 08:21:57 +08:00
|
|
|
enum object_type type;
|
|
|
|
const struct submodule *submodule = NULL;
|
|
|
|
struct parse_config_parameter parameter;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If any parameter except the cache is a NULL pointer just
|
|
|
|
* return the first submodule. Can be used to check whether
|
|
|
|
* there are any submodules parsed.
|
|
|
|
*/
|
2016-11-23 04:14:37 +08:00
|
|
|
if (!treeish_name || !key) {
|
2015-08-18 08:21:57 +08:00
|
|
|
struct hashmap_iter iter;
|
|
|
|
struct submodule_entry *entry;
|
|
|
|
|
2019-10-07 07:30:38 +08:00
|
|
|
entry = hashmap_iter_first_entry(&cache->for_name, &iter,
|
|
|
|
struct submodule_entry,
|
|
|
|
ent /* member name */);
|
2015-08-18 08:21:57 +08:00
|
|
|
if (!entry)
|
|
|
|
return NULL;
|
|
|
|
return entry->config;
|
|
|
|
}
|
|
|
|
|
2017-07-14 07:49:20 +08:00
|
|
|
if (!gitmodule_oid_from_commit(treeish_name, &oid, &rev))
|
2016-07-28 20:49:47 +08:00
|
|
|
goto out;
|
2015-08-18 08:21:57 +08:00
|
|
|
|
|
|
|
switch (lookup_type) {
|
|
|
|
case lookup_name:
|
2018-05-02 08:25:42 +08:00
|
|
|
submodule = cache_lookup_name(cache, &oid, key);
|
2015-08-18 08:21:57 +08:00
|
|
|
break;
|
|
|
|
case lookup_path:
|
2018-05-02 08:25:42 +08:00
|
|
|
submodule = cache_lookup_path(cache, &oid, key);
|
2015-08-18 08:21:57 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (submodule)
|
2016-07-28 20:49:47 +08:00
|
|
|
goto out;
|
2015-08-18 08:21:57 +08:00
|
|
|
|
2023-03-28 21:58:50 +08:00
|
|
|
config = repo_read_object_file(the_repository, &oid, &type,
|
|
|
|
&config_size);
|
2016-07-28 20:49:47 +08:00
|
|
|
if (!config || type != OBJ_BLOB)
|
|
|
|
goto out;
|
2015-08-18 08:21:57 +08:00
|
|
|
|
|
|
|
/* fill the submodule config into the cache */
|
|
|
|
parameter.cache = cache;
|
2018-05-02 08:25:42 +08:00
|
|
|
parameter.treeish_name = treeish_name;
|
|
|
|
parameter.gitmodules_oid = &oid;
|
2015-08-18 08:21:57 +08:00
|
|
|
parameter.overwrite = 0;
|
i18n: config: unfold error messages marked for translation
Introduced in 473166b ("config: add 'origin_type' to config_source
struct", 2016-02-19), Git can inform the user about the origin of a
config error, but the implementation does not allow translators to
translate the keywords 'file', 'blob, 'standard input', and
'submodule-blob'. Moreover, for the second message, a reason for the
error is appended to the message, not allowing translators to translate
that reason either.
Unfold the message into several templates for each known origin_type.
That would result in better translation at the expense of code
verbosity.
Add enum config_oringin_type to ease management of the various
configuration origin types (blob, file, etc). Previously origin type
was considered from command line if cf->origin_type == NULL, i.e.,
uninitialized. Now we set origin_type to CONFIG_ORIGIN_CMDLINE in
git_config_from_parameters() and configset_add_value().
For error message in git_parse_source(), use xstrfmt() function to
prepare the message string, instead of doing something like it's done
for die_bad_number(), because intelligibility and code conciseness are
improved for that instance.
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-28 21:14:03 +08:00
|
|
|
git_config_from_mem(parse_config, CONFIG_ORIGIN_SUBMODULE_BLOB, rev.buf,
|
2023-06-29 03:26:24 +08:00
|
|
|
config, config_size, ¶meter, CONFIG_SCOPE_UNKNOWN, NULL);
|
2016-07-28 20:49:11 +08:00
|
|
|
strbuf_release(&rev);
|
2015-08-18 08:21:57 +08:00
|
|
|
free(config);
|
|
|
|
|
|
|
|
switch (lookup_type) {
|
|
|
|
case lookup_name:
|
2018-05-02 08:25:42 +08:00
|
|
|
return cache_lookup_name(cache, &oid, key);
|
2015-08-18 08:21:57 +08:00
|
|
|
case lookup_path:
|
2018-05-02 08:25:42 +08:00
|
|
|
return cache_lookup_path(cache, &oid, key);
|
2015-08-18 08:21:57 +08:00
|
|
|
default:
|
|
|
|
return NULL;
|
|
|
|
}
|
2016-07-28 20:49:47 +08:00
|
|
|
|
|
|
|
out:
|
|
|
|
strbuf_release(&rev);
|
|
|
|
free(config);
|
|
|
|
return submodule;
|
2015-08-18 08:21:57 +08:00
|
|
|
}
|
|
|
|
|
2017-06-23 02:43:44 +08:00
|
|
|
static void submodule_cache_check_init(struct repository *repo)
|
2015-08-18 08:21:57 +08:00
|
|
|
{
|
2017-06-23 02:43:44 +08:00
|
|
|
if (repo->submodule_cache && repo->submodule_cache->initialized)
|
2015-08-18 08:21:57 +08:00
|
|
|
return;
|
|
|
|
|
2017-06-23 02:43:44 +08:00
|
|
|
if (!repo->submodule_cache)
|
|
|
|
repo->submodule_cache = submodule_cache_alloc();
|
|
|
|
|
|
|
|
submodule_cache_init(repo->submodule_cache);
|
2015-08-18 08:21:57 +08:00
|
|
|
}
|
|
|
|
|
2018-06-26 18:47:10 +08:00
|
|
|
/*
|
|
|
|
* Note: This function is private for a reason, the '.gitmodules' file should
|
2019-12-15 23:12:24 +08:00
|
|
|
* not be used as a mechanism to retrieve arbitrary configuration stored in
|
2018-06-26 18:47:10 +08:00
|
|
|
* the repository.
|
|
|
|
*
|
|
|
|
* Runs the provided config function on the '.gitmodules' file found in the
|
|
|
|
* working directory.
|
|
|
|
*/
|
|
|
|
static void config_from_gitmodules(config_fn_t fn, struct repository *repo, void *data)
|
|
|
|
{
|
|
|
|
if (repo->worktree) {
|
2020-02-10 08:30:58 +08:00
|
|
|
struct git_config_source config_source = {
|
|
|
|
0, .scope = CONFIG_SCOPE_SUBMODULE
|
|
|
|
};
|
2018-10-26 00:18:12 +08:00
|
|
|
const struct config_options opts = { 0 };
|
|
|
|
struct object_id oid;
|
|
|
|
char *file;
|
2019-04-16 17:33:38 +08:00
|
|
|
char *oidstr = NULL;
|
2018-10-26 00:18:12 +08:00
|
|
|
|
|
|
|
file = repo_worktree_path(repo, GITMODULES_FILE);
|
|
|
|
if (file_exists(file)) {
|
|
|
|
config_source.file = file;
|
2019-04-16 17:33:38 +08:00
|
|
|
} else if (repo_get_oid(repo, GITMODULES_INDEX, &oid) >= 0 ||
|
|
|
|
repo_get_oid(repo, GITMODULES_HEAD, &oid) >= 0) {
|
|
|
|
config_source.blob = oidstr = xstrdup(oid_to_hex(&oid));
|
|
|
|
if (repo != the_repository)
|
2021-08-17 05:09:57 +08:00
|
|
|
add_submodule_odb_by_path(repo->objects->odb->path);
|
2018-10-26 00:18:12 +08:00
|
|
|
} else {
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
config: pass 'repo' directly to 'config_with_options()'
Add a 'struct repository' argument to 'config_with_options()' and remove the
'repo' field from 'struct git_config_source'.
A 'struct repository' instance was originally added to the config source in
e3e8bf046e9 (submodule-config: pass repo upon blob config read, 2021-08-16)
to improve how submodule blob config content was accessed. At the time, this
was the only use for a 'repository' instance, so it was naturally added only
where it was needed: to 'struct git_config_source'. However, in upcoming
patches, 'config_with_options()' will need the repository instance to access
extension information (regardless of whether a 'config_source' exists). To
make the 'struct repository' instance more easily accessible, move it into
the function's arguments.
Update all callers of 'config_with_options()' to pass the appropriate 'repo'
value:
* in 'builtin/config.c', use 'the_repository'
* in 'submodule--config.c', use the 'repo' arg in 'config_from_gitmodules()'
* in 'read_[very_]early_config()' & 'read_protected_config()', set 'repo' to
NULL (repository instances aren't available there)
* in 'populate_remote_urls()', use the repo instance that has been added to
the 'struct config_include_data'
* in 'repo_read_config()', use the given 'repo' arg
Finally, note that this patch eliminates the fallback to 'the_repository'
that previously existed for the 'config_source' repo instance if it was
NULL. The fallback is no longer necessary, as the 'repo' is set explicitly
in all cases where it is needed.
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-26 09:32:59 +08:00
|
|
|
config_with_options(fn, data, &config_source, repo, &opts);
|
2018-10-26 00:18:12 +08:00
|
|
|
|
|
|
|
out:
|
2019-04-16 17:33:38 +08:00
|
|
|
free(oidstr);
|
2018-06-26 18:47:10 +08:00
|
|
|
free(file);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
config: add ctx arg to config_fn_t
Add a new "const struct config_context *ctx" arg to config_fn_t to hold
additional information about the config iteration operation.
config_context has a "struct key_value_info kvi" member that holds
metadata about the config source being read (e.g. what kind of config
source it is, the filename, etc). In this series, we're only interested
in .kvi, so we could have just used "struct key_value_info" as an arg,
but config_context makes it possible to add/adjust members in the future
without changing the config_fn_t signature. We could also consider other
ways of organizing the args (e.g. moving the config name and value into
config_context or key_value_info), but in my experiments, the
incremental benefit doesn't justify the added complexity (e.g. a
config_fn_t will sometimes invoke another config_fn_t but with a
different config value).
In subsequent commits, the .kvi member will replace the global "struct
config_reader" in config.c, making config iteration a global-free
operation. It requires much more work for the machinery to provide
meaningful values of .kvi, so for now, merely change the signature and
call sites, pass NULL as a placeholder value, and don't rely on the arg
in any meaningful way.
Most of the changes are performed by
contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every
config_fn_t:
- Modifies the signature to accept "const struct config_context *ctx"
- Passes "ctx" to any inner config_fn_t, if needed
- Adds UNUSED attributes to "ctx", if needed
Most config_fn_t instances are easily identified by seeing if they are
called by the various config functions. Most of the remaining ones are
manually named in the .cocci patch. Manual cleanups are still needed,
but the majority of it is trivial; it's either adjusting config_fn_t
that the .cocci patch didn't catch, or adding forward declarations of
"struct config_context ctx" to make the signatures make sense.
The non-trivial changes are in cases where we are invoking a config_fn_t
outside of config machinery, and we now need to decide what value of
"ctx" to pass. These cases are:
- trace2/tr2_cfg.c:tr2_cfg_set_fl()
This is indirectly called by git_config_set() so that the trace2
machinery can notice the new config values and update its settings
using the tr2 config parsing function, i.e. tr2_cfg_cb().
- builtin/checkout.c:checkout_main()
This calls git_xmerge_config() as a shorthand for parsing a CLI arg.
This might be worth refactoring away in the future, since
git_xmerge_config() can call git_default_config(), which can do much
more than just parsing.
Handle them by creating a KVI_INIT macro that initializes "struct
key_value_info" to a reasonable default, and use that to construct the
"ctx" arg.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-29 03:26:22 +08:00
|
|
|
static int gitmodules_cb(const char *var, const char *value,
|
|
|
|
const struct config_context *ctx, void *data)
|
2015-08-18 08:21:59 +08:00
|
|
|
{
|
2017-08-04 02:19:57 +08:00
|
|
|
struct repository *repo = data;
|
2015-08-18 08:21:59 +08:00
|
|
|
struct parse_config_parameter parameter;
|
2017-06-23 02:43:44 +08:00
|
|
|
|
|
|
|
parameter.cache = repo->submodule_cache;
|
2016-11-23 04:14:37 +08:00
|
|
|
parameter.treeish_name = NULL;
|
2021-04-26 09:02:56 +08:00
|
|
|
parameter.gitmodules_oid = null_oid();
|
2015-08-18 08:21:59 +08:00
|
|
|
parameter.overwrite = 1;
|
|
|
|
|
config: add ctx arg to config_fn_t
Add a new "const struct config_context *ctx" arg to config_fn_t to hold
additional information about the config iteration operation.
config_context has a "struct key_value_info kvi" member that holds
metadata about the config source being read (e.g. what kind of config
source it is, the filename, etc). In this series, we're only interested
in .kvi, so we could have just used "struct key_value_info" as an arg,
but config_context makes it possible to add/adjust members in the future
without changing the config_fn_t signature. We could also consider other
ways of organizing the args (e.g. moving the config name and value into
config_context or key_value_info), but in my experiments, the
incremental benefit doesn't justify the added complexity (e.g. a
config_fn_t will sometimes invoke another config_fn_t but with a
different config value).
In subsequent commits, the .kvi member will replace the global "struct
config_reader" in config.c, making config iteration a global-free
operation. It requires much more work for the machinery to provide
meaningful values of .kvi, so for now, merely change the signature and
call sites, pass NULL as a placeholder value, and don't rely on the arg
in any meaningful way.
Most of the changes are performed by
contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every
config_fn_t:
- Modifies the signature to accept "const struct config_context *ctx"
- Passes "ctx" to any inner config_fn_t, if needed
- Adds UNUSED attributes to "ctx", if needed
Most config_fn_t instances are easily identified by seeing if they are
called by the various config functions. Most of the remaining ones are
manually named in the .cocci patch. Manual cleanups are still needed,
but the majority of it is trivial; it's either adjusting config_fn_t
that the .cocci patch didn't catch, or adding forward declarations of
"struct config_context ctx" to make the signatures make sense.
The non-trivial changes are in cases where we are invoking a config_fn_t
outside of config machinery, and we now need to decide what value of
"ctx" to pass. These cases are:
- trace2/tr2_cfg.c:tr2_cfg_set_fl()
This is indirectly called by git_config_set() so that the trace2
machinery can notice the new config values and update its settings
using the tr2 config parsing function, i.e. tr2_cfg_cb().
- builtin/checkout.c:checkout_main()
This calls git_xmerge_config() as a shorthand for parsing a CLI arg.
This might be worth refactoring away in the future, since
git_xmerge_config() can call git_default_config(), which can do much
more than just parsing.
Handle them by creating a KVI_INIT macro that initializes "struct
key_value_info" to a reasonable default, and use that to construct the
"ctx" arg.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-29 03:26:22 +08:00
|
|
|
return parse_config(var, value, ctx, ¶meter);
|
2015-08-18 08:21:59 +08:00
|
|
|
}
|
|
|
|
|
2020-01-16 10:39:55 +08:00
|
|
|
void repo_read_gitmodules(struct repository *repo, int skip_if_read)
|
2017-06-23 02:43:44 +08:00
|
|
|
{
|
2017-08-04 02:19:58 +08:00
|
|
|
submodule_cache_check_init(repo);
|
|
|
|
|
2020-01-16 10:39:55 +08:00
|
|
|
if (repo->submodule_cache->gitmodules_read && skip_if_read)
|
|
|
|
return;
|
|
|
|
|
2018-06-26 18:47:10 +08:00
|
|
|
if (repo_read_index(repo) < 0)
|
|
|
|
return;
|
2017-08-04 02:19:57 +08:00
|
|
|
|
2018-06-26 18:47:10 +08:00
|
|
|
if (!is_gitmodules_unmerged(repo->index))
|
|
|
|
config_from_gitmodules(gitmodules_cb, repo, repo);
|
2017-08-04 02:19:58 +08:00
|
|
|
|
|
|
|
repo->submodule_cache->gitmodules_read = 1;
|
2017-08-04 02:19:57 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void gitmodules_config_oid(const struct object_id *commit_oid)
|
|
|
|
{
|
|
|
|
struct strbuf rev = STRBUF_INIT;
|
|
|
|
struct object_id oid;
|
|
|
|
|
2017-08-04 02:19:58 +08:00
|
|
|
submodule_cache_check_init(the_repository);
|
|
|
|
|
2017-08-04 02:19:57 +08:00
|
|
|
if (gitmodule_oid_from_commit(commit_oid, &oid, &rev)) {
|
|
|
|
git_config_from_blob_oid(gitmodules_cb, rev.buf,
|
2023-06-29 03:26:24 +08:00
|
|
|
the_repository, &oid, the_repository,
|
|
|
|
CONFIG_SCOPE_UNKNOWN);
|
2017-08-04 02:19:57 +08:00
|
|
|
}
|
|
|
|
strbuf_release(&rev);
|
2017-08-04 02:19:58 +08:00
|
|
|
|
|
|
|
the_repository->submodule_cache->gitmodules_read = 1;
|
|
|
|
}
|
|
|
|
|
2018-03-29 06:35:29 +08:00
|
|
|
const struct submodule *submodule_from_name(struct repository *r,
|
|
|
|
const struct object_id *treeish_name,
|
2015-08-18 08:21:57 +08:00
|
|
|
const char *name)
|
|
|
|
{
|
2020-01-16 10:39:55 +08:00
|
|
|
repo_read_gitmodules(r, 1);
|
2018-03-29 06:35:29 +08:00
|
|
|
return config_from(r->submodule_cache, treeish_name, name, lookup_name);
|
2015-08-18 08:21:57 +08:00
|
|
|
}
|
|
|
|
|
2018-03-29 06:35:29 +08:00
|
|
|
const struct submodule *submodule_from_path(struct repository *r,
|
|
|
|
const struct object_id *treeish_name,
|
2015-08-18 08:21:57 +08:00
|
|
|
const char *path)
|
|
|
|
{
|
2020-01-16 10:39:55 +08:00
|
|
|
repo_read_gitmodules(r, 1);
|
2018-03-29 06:35:29 +08:00
|
|
|
return config_from(r->submodule_cache, treeish_name, path, lookup_path);
|
2017-06-23 02:43:44 +08:00
|
|
|
}
|
|
|
|
|
branch: add --recurse-submodules option for branch creation
To improve the submodules UX, we would like to teach Git to handle
branches in submodules. Start this process by teaching "git branch" the
--recurse-submodules option so that "git branch --recurse-submodules
topic" will create the `topic` branch in the superproject and its
submodules.
Although this commit does not introduce breaking changes, it does not
work well with existing --recurse-submodules commands because "git
branch --recurse-submodules" writes to the submodule ref store, but most
commands only consider the superproject gitlink and ignore the submodule
ref store. For example, "git checkout --recurse-submodules" will check
out the commits in the superproject gitlinks (and put the submodules in
detached HEAD) instead of checking out the submodule branches.
Because of this, this commit introduces a new configuration value,
`submodule.propagateBranches`. The plan is for Git commands to
prioritize submodule ref store information over superproject gitlinks if
this value is true. Because "git branch --recurse-submodules" writes to
submodule ref stores, for the sake of clarity, it will not function
unless this configuration value is set.
This commit also includes changes that support working with submodules
from a superproject commit because "branch --recurse-submodules" (and
future commands) need to read .gitmodules and gitlinks from the
superproject commit, but submodules are typically read from the
filesystem's .gitmodules and the index's gitlinks. These changes are:
* add a submodules_of_tree() helper that gives the relevant
information of an in-tree submodule (e.g. path and oid) and
initializes the repository
* add is_tree_submodule_active() by adding a treeish_name parameter to
is_submodule_active()
* add the "submoduleNotUpdated" advice to advise users to update the
submodules in their trees
Incidentally, fix an incorrect usage string that combined the 'list'
usage of git branch (-l) with the 'create' usage; this string has been
incorrect since its inception, a8dfd5eac4 (Make builtin-branch.c use
parse_options., 2007-10-07).
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Glen Choo <chooglen@google.com>
Reviewed-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-29 08:04:45 +08:00
|
|
|
/**
|
|
|
|
* Used internally by submodules_of_tree(). Recurses into 'treeish_name'
|
|
|
|
* and appends submodule entries to 'out'. The submodule_cache expects
|
|
|
|
* a root-level treeish_name and paths, so keep track of these values
|
|
|
|
* with 'root_tree' and 'prefix'.
|
|
|
|
*/
|
|
|
|
static void traverse_tree_submodules(struct repository *r,
|
|
|
|
const struct object_id *root_tree,
|
|
|
|
char *prefix,
|
|
|
|
const struct object_id *treeish_name,
|
|
|
|
struct submodule_entry_list *out)
|
|
|
|
{
|
|
|
|
struct tree_desc tree;
|
|
|
|
struct submodule_tree_entry *st_entry;
|
2024-08-14 14:52:12 +08:00
|
|
|
struct name_entry name_entry;
|
branch: add --recurse-submodules option for branch creation
To improve the submodules UX, we would like to teach Git to handle
branches in submodules. Start this process by teaching "git branch" the
--recurse-submodules option so that "git branch --recurse-submodules
topic" will create the `topic` branch in the superproject and its
submodules.
Although this commit does not introduce breaking changes, it does not
work well with existing --recurse-submodules commands because "git
branch --recurse-submodules" writes to the submodule ref store, but most
commands only consider the superproject gitlink and ignore the submodule
ref store. For example, "git checkout --recurse-submodules" will check
out the commits in the superproject gitlinks (and put the submodules in
detached HEAD) instead of checking out the submodule branches.
Because of this, this commit introduces a new configuration value,
`submodule.propagateBranches`. The plan is for Git commands to
prioritize submodule ref store information over superproject gitlinks if
this value is true. Because "git branch --recurse-submodules" writes to
submodule ref stores, for the sake of clarity, it will not function
unless this configuration value is set.
This commit also includes changes that support working with submodules
from a superproject commit because "branch --recurse-submodules" (and
future commands) need to read .gitmodules and gitlinks from the
superproject commit, but submodules are typically read from the
filesystem's .gitmodules and the index's gitlinks. These changes are:
* add a submodules_of_tree() helper that gives the relevant
information of an in-tree submodule (e.g. path and oid) and
initializes the repository
* add is_tree_submodule_active() by adding a treeish_name parameter to
is_submodule_active()
* add the "submoduleNotUpdated" advice to advise users to update the
submodules in their trees
Incidentally, fix an incorrect usage string that combined the 'list'
usage of git branch (-l) with the 'create' usage; this string has been
incorrect since its inception, a8dfd5eac4 (Make builtin-branch.c use
parse_options., 2007-10-07).
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Glen Choo <chooglen@google.com>
Reviewed-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-29 08:04:45 +08:00
|
|
|
char *tree_path = NULL;
|
2024-09-30 17:13:27 +08:00
|
|
|
char *tree_buf;
|
branch: add --recurse-submodules option for branch creation
To improve the submodules UX, we would like to teach Git to handle
branches in submodules. Start this process by teaching "git branch" the
--recurse-submodules option so that "git branch --recurse-submodules
topic" will create the `topic` branch in the superproject and its
submodules.
Although this commit does not introduce breaking changes, it does not
work well with existing --recurse-submodules commands because "git
branch --recurse-submodules" writes to the submodule ref store, but most
commands only consider the superproject gitlink and ignore the submodule
ref store. For example, "git checkout --recurse-submodules" will check
out the commits in the superproject gitlinks (and put the submodules in
detached HEAD) instead of checking out the submodule branches.
Because of this, this commit introduces a new configuration value,
`submodule.propagateBranches`. The plan is for Git commands to
prioritize submodule ref store information over superproject gitlinks if
this value is true. Because "git branch --recurse-submodules" writes to
submodule ref stores, for the sake of clarity, it will not function
unless this configuration value is set.
This commit also includes changes that support working with submodules
from a superproject commit because "branch --recurse-submodules" (and
future commands) need to read .gitmodules and gitlinks from the
superproject commit, but submodules are typically read from the
filesystem's .gitmodules and the index's gitlinks. These changes are:
* add a submodules_of_tree() helper that gives the relevant
information of an in-tree submodule (e.g. path and oid) and
initializes the repository
* add is_tree_submodule_active() by adding a treeish_name parameter to
is_submodule_active()
* add the "submoduleNotUpdated" advice to advise users to update the
submodules in their trees
Incidentally, fix an incorrect usage string that combined the 'list'
usage of git branch (-l) with the 'create' usage; this string has been
incorrect since its inception, a8dfd5eac4 (Make builtin-branch.c use
parse_options., 2007-10-07).
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Glen Choo <chooglen@google.com>
Reviewed-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-29 08:04:45 +08:00
|
|
|
|
2024-09-30 17:13:27 +08:00
|
|
|
tree_buf = fill_tree_descriptor(r, &tree, treeish_name);
|
2024-08-14 14:52:12 +08:00
|
|
|
while (tree_entry(&tree, &name_entry)) {
|
branch: add --recurse-submodules option for branch creation
To improve the submodules UX, we would like to teach Git to handle
branches in submodules. Start this process by teaching "git branch" the
--recurse-submodules option so that "git branch --recurse-submodules
topic" will create the `topic` branch in the superproject and its
submodules.
Although this commit does not introduce breaking changes, it does not
work well with existing --recurse-submodules commands because "git
branch --recurse-submodules" writes to the submodule ref store, but most
commands only consider the superproject gitlink and ignore the submodule
ref store. For example, "git checkout --recurse-submodules" will check
out the commits in the superproject gitlinks (and put the submodules in
detached HEAD) instead of checking out the submodule branches.
Because of this, this commit introduces a new configuration value,
`submodule.propagateBranches`. The plan is for Git commands to
prioritize submodule ref store information over superproject gitlinks if
this value is true. Because "git branch --recurse-submodules" writes to
submodule ref stores, for the sake of clarity, it will not function
unless this configuration value is set.
This commit also includes changes that support working with submodules
from a superproject commit because "branch --recurse-submodules" (and
future commands) need to read .gitmodules and gitlinks from the
superproject commit, but submodules are typically read from the
filesystem's .gitmodules and the index's gitlinks. These changes are:
* add a submodules_of_tree() helper that gives the relevant
information of an in-tree submodule (e.g. path and oid) and
initializes the repository
* add is_tree_submodule_active() by adding a treeish_name parameter to
is_submodule_active()
* add the "submoduleNotUpdated" advice to advise users to update the
submodules in their trees
Incidentally, fix an incorrect usage string that combined the 'list'
usage of git branch (-l) with the 'create' usage; this string has been
incorrect since its inception, a8dfd5eac4 (Make builtin-branch.c use
parse_options., 2007-10-07).
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Glen Choo <chooglen@google.com>
Reviewed-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-29 08:04:45 +08:00
|
|
|
if (prefix)
|
|
|
|
tree_path =
|
2024-08-14 14:52:12 +08:00
|
|
|
mkpathdup("%s/%s", prefix, name_entry.path);
|
branch: add --recurse-submodules option for branch creation
To improve the submodules UX, we would like to teach Git to handle
branches in submodules. Start this process by teaching "git branch" the
--recurse-submodules option so that "git branch --recurse-submodules
topic" will create the `topic` branch in the superproject and its
submodules.
Although this commit does not introduce breaking changes, it does not
work well with existing --recurse-submodules commands because "git
branch --recurse-submodules" writes to the submodule ref store, but most
commands only consider the superproject gitlink and ignore the submodule
ref store. For example, "git checkout --recurse-submodules" will check
out the commits in the superproject gitlinks (and put the submodules in
detached HEAD) instead of checking out the submodule branches.
Because of this, this commit introduces a new configuration value,
`submodule.propagateBranches`. The plan is for Git commands to
prioritize submodule ref store information over superproject gitlinks if
this value is true. Because "git branch --recurse-submodules" writes to
submodule ref stores, for the sake of clarity, it will not function
unless this configuration value is set.
This commit also includes changes that support working with submodules
from a superproject commit because "branch --recurse-submodules" (and
future commands) need to read .gitmodules and gitlinks from the
superproject commit, but submodules are typically read from the
filesystem's .gitmodules and the index's gitlinks. These changes are:
* add a submodules_of_tree() helper that gives the relevant
information of an in-tree submodule (e.g. path and oid) and
initializes the repository
* add is_tree_submodule_active() by adding a treeish_name parameter to
is_submodule_active()
* add the "submoduleNotUpdated" advice to advise users to update the
submodules in their trees
Incidentally, fix an incorrect usage string that combined the 'list'
usage of git branch (-l) with the 'create' usage; this string has been
incorrect since its inception, a8dfd5eac4 (Make builtin-branch.c use
parse_options., 2007-10-07).
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Glen Choo <chooglen@google.com>
Reviewed-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-29 08:04:45 +08:00
|
|
|
else
|
2024-08-14 14:52:12 +08:00
|
|
|
tree_path = xstrdup(name_entry.path);
|
branch: add --recurse-submodules option for branch creation
To improve the submodules UX, we would like to teach Git to handle
branches in submodules. Start this process by teaching "git branch" the
--recurse-submodules option so that "git branch --recurse-submodules
topic" will create the `topic` branch in the superproject and its
submodules.
Although this commit does not introduce breaking changes, it does not
work well with existing --recurse-submodules commands because "git
branch --recurse-submodules" writes to the submodule ref store, but most
commands only consider the superproject gitlink and ignore the submodule
ref store. For example, "git checkout --recurse-submodules" will check
out the commits in the superproject gitlinks (and put the submodules in
detached HEAD) instead of checking out the submodule branches.
Because of this, this commit introduces a new configuration value,
`submodule.propagateBranches`. The plan is for Git commands to
prioritize submodule ref store information over superproject gitlinks if
this value is true. Because "git branch --recurse-submodules" writes to
submodule ref stores, for the sake of clarity, it will not function
unless this configuration value is set.
This commit also includes changes that support working with submodules
from a superproject commit because "branch --recurse-submodules" (and
future commands) need to read .gitmodules and gitlinks from the
superproject commit, but submodules are typically read from the
filesystem's .gitmodules and the index's gitlinks. These changes are:
* add a submodules_of_tree() helper that gives the relevant
information of an in-tree submodule (e.g. path and oid) and
initializes the repository
* add is_tree_submodule_active() by adding a treeish_name parameter to
is_submodule_active()
* add the "submoduleNotUpdated" advice to advise users to update the
submodules in their trees
Incidentally, fix an incorrect usage string that combined the 'list'
usage of git branch (-l) with the 'create' usage; this string has been
incorrect since its inception, a8dfd5eac4 (Make builtin-branch.c use
parse_options., 2007-10-07).
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Glen Choo <chooglen@google.com>
Reviewed-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-29 08:04:45 +08:00
|
|
|
|
2024-08-14 14:52:12 +08:00
|
|
|
if (S_ISGITLINK(name_entry.mode) &&
|
branch: add --recurse-submodules option for branch creation
To improve the submodules UX, we would like to teach Git to handle
branches in submodules. Start this process by teaching "git branch" the
--recurse-submodules option so that "git branch --recurse-submodules
topic" will create the `topic` branch in the superproject and its
submodules.
Although this commit does not introduce breaking changes, it does not
work well with existing --recurse-submodules commands because "git
branch --recurse-submodules" writes to the submodule ref store, but most
commands only consider the superproject gitlink and ignore the submodule
ref store. For example, "git checkout --recurse-submodules" will check
out the commits in the superproject gitlinks (and put the submodules in
detached HEAD) instead of checking out the submodule branches.
Because of this, this commit introduces a new configuration value,
`submodule.propagateBranches`. The plan is for Git commands to
prioritize submodule ref store information over superproject gitlinks if
this value is true. Because "git branch --recurse-submodules" writes to
submodule ref stores, for the sake of clarity, it will not function
unless this configuration value is set.
This commit also includes changes that support working with submodules
from a superproject commit because "branch --recurse-submodules" (and
future commands) need to read .gitmodules and gitlinks from the
superproject commit, but submodules are typically read from the
filesystem's .gitmodules and the index's gitlinks. These changes are:
* add a submodules_of_tree() helper that gives the relevant
information of an in-tree submodule (e.g. path and oid) and
initializes the repository
* add is_tree_submodule_active() by adding a treeish_name parameter to
is_submodule_active()
* add the "submoduleNotUpdated" advice to advise users to update the
submodules in their trees
Incidentally, fix an incorrect usage string that combined the 'list'
usage of git branch (-l) with the 'create' usage; this string has been
incorrect since its inception, a8dfd5eac4 (Make builtin-branch.c use
parse_options., 2007-10-07).
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Glen Choo <chooglen@google.com>
Reviewed-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-29 08:04:45 +08:00
|
|
|
is_tree_submodule_active(r, root_tree, tree_path)) {
|
2022-06-16 07:35:39 +08:00
|
|
|
ALLOC_GROW(out->entries, out->entry_nr + 1,
|
|
|
|
out->entry_alloc);
|
|
|
|
st_entry = &out->entries[out->entry_nr++];
|
|
|
|
|
branch: add --recurse-submodules option for branch creation
To improve the submodules UX, we would like to teach Git to handle
branches in submodules. Start this process by teaching "git branch" the
--recurse-submodules option so that "git branch --recurse-submodules
topic" will create the `topic` branch in the superproject and its
submodules.
Although this commit does not introduce breaking changes, it does not
work well with existing --recurse-submodules commands because "git
branch --recurse-submodules" writes to the submodule ref store, but most
commands only consider the superproject gitlink and ignore the submodule
ref store. For example, "git checkout --recurse-submodules" will check
out the commits in the superproject gitlinks (and put the submodules in
detached HEAD) instead of checking out the submodule branches.
Because of this, this commit introduces a new configuration value,
`submodule.propagateBranches`. The plan is for Git commands to
prioritize submodule ref store information over superproject gitlinks if
this value is true. Because "git branch --recurse-submodules" writes to
submodule ref stores, for the sake of clarity, it will not function
unless this configuration value is set.
This commit also includes changes that support working with submodules
from a superproject commit because "branch --recurse-submodules" (and
future commands) need to read .gitmodules and gitlinks from the
superproject commit, but submodules are typically read from the
filesystem's .gitmodules and the index's gitlinks. These changes are:
* add a submodules_of_tree() helper that gives the relevant
information of an in-tree submodule (e.g. path and oid) and
initializes the repository
* add is_tree_submodule_active() by adding a treeish_name parameter to
is_submodule_active()
* add the "submoduleNotUpdated" advice to advise users to update the
submodules in their trees
Incidentally, fix an incorrect usage string that combined the 'list'
usage of git branch (-l) with the 'create' usage; this string has been
incorrect since its inception, a8dfd5eac4 (Make builtin-branch.c use
parse_options., 2007-10-07).
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Glen Choo <chooglen@google.com>
Reviewed-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-29 08:04:45 +08:00
|
|
|
st_entry->name_entry = xmalloc(sizeof(*st_entry->name_entry));
|
2024-08-14 14:52:12 +08:00
|
|
|
*st_entry->name_entry = name_entry;
|
branch: add --recurse-submodules option for branch creation
To improve the submodules UX, we would like to teach Git to handle
branches in submodules. Start this process by teaching "git branch" the
--recurse-submodules option so that "git branch --recurse-submodules
topic" will create the `topic` branch in the superproject and its
submodules.
Although this commit does not introduce breaking changes, it does not
work well with existing --recurse-submodules commands because "git
branch --recurse-submodules" writes to the submodule ref store, but most
commands only consider the superproject gitlink and ignore the submodule
ref store. For example, "git checkout --recurse-submodules" will check
out the commits in the superproject gitlinks (and put the submodules in
detached HEAD) instead of checking out the submodule branches.
Because of this, this commit introduces a new configuration value,
`submodule.propagateBranches`. The plan is for Git commands to
prioritize submodule ref store information over superproject gitlinks if
this value is true. Because "git branch --recurse-submodules" writes to
submodule ref stores, for the sake of clarity, it will not function
unless this configuration value is set.
This commit also includes changes that support working with submodules
from a superproject commit because "branch --recurse-submodules" (and
future commands) need to read .gitmodules and gitlinks from the
superproject commit, but submodules are typically read from the
filesystem's .gitmodules and the index's gitlinks. These changes are:
* add a submodules_of_tree() helper that gives the relevant
information of an in-tree submodule (e.g. path and oid) and
initializes the repository
* add is_tree_submodule_active() by adding a treeish_name parameter to
is_submodule_active()
* add the "submoduleNotUpdated" advice to advise users to update the
submodules in their trees
Incidentally, fix an incorrect usage string that combined the 'list'
usage of git branch (-l) with the 'create' usage; this string has been
incorrect since its inception, a8dfd5eac4 (Make builtin-branch.c use
parse_options., 2007-10-07).
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Glen Choo <chooglen@google.com>
Reviewed-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-29 08:04:45 +08:00
|
|
|
st_entry->submodule =
|
|
|
|
submodule_from_path(r, root_tree, tree_path);
|
|
|
|
st_entry->repo = xmalloc(sizeof(*st_entry->repo));
|
|
|
|
if (repo_submodule_init(st_entry->repo, r, tree_path,
|
|
|
|
root_tree))
|
|
|
|
FREE_AND_NULL(st_entry->repo);
|
|
|
|
|
2024-08-14 14:52:12 +08:00
|
|
|
} else if (S_ISDIR(name_entry.mode))
|
branch: add --recurse-submodules option for branch creation
To improve the submodules UX, we would like to teach Git to handle
branches in submodules. Start this process by teaching "git branch" the
--recurse-submodules option so that "git branch --recurse-submodules
topic" will create the `topic` branch in the superproject and its
submodules.
Although this commit does not introduce breaking changes, it does not
work well with existing --recurse-submodules commands because "git
branch --recurse-submodules" writes to the submodule ref store, but most
commands only consider the superproject gitlink and ignore the submodule
ref store. For example, "git checkout --recurse-submodules" will check
out the commits in the superproject gitlinks (and put the submodules in
detached HEAD) instead of checking out the submodule branches.
Because of this, this commit introduces a new configuration value,
`submodule.propagateBranches`. The plan is for Git commands to
prioritize submodule ref store information over superproject gitlinks if
this value is true. Because "git branch --recurse-submodules" writes to
submodule ref stores, for the sake of clarity, it will not function
unless this configuration value is set.
This commit also includes changes that support working with submodules
from a superproject commit because "branch --recurse-submodules" (and
future commands) need to read .gitmodules and gitlinks from the
superproject commit, but submodules are typically read from the
filesystem's .gitmodules and the index's gitlinks. These changes are:
* add a submodules_of_tree() helper that gives the relevant
information of an in-tree submodule (e.g. path and oid) and
initializes the repository
* add is_tree_submodule_active() by adding a treeish_name parameter to
is_submodule_active()
* add the "submoduleNotUpdated" advice to advise users to update the
submodules in their trees
Incidentally, fix an incorrect usage string that combined the 'list'
usage of git branch (-l) with the 'create' usage; this string has been
incorrect since its inception, a8dfd5eac4 (Make builtin-branch.c use
parse_options., 2007-10-07).
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Glen Choo <chooglen@google.com>
Reviewed-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-29 08:04:45 +08:00
|
|
|
traverse_tree_submodules(r, root_tree, tree_path,
|
2024-08-14 14:52:12 +08:00
|
|
|
&name_entry.oid, out);
|
branch: add --recurse-submodules option for branch creation
To improve the submodules UX, we would like to teach Git to handle
branches in submodules. Start this process by teaching "git branch" the
--recurse-submodules option so that "git branch --recurse-submodules
topic" will create the `topic` branch in the superproject and its
submodules.
Although this commit does not introduce breaking changes, it does not
work well with existing --recurse-submodules commands because "git
branch --recurse-submodules" writes to the submodule ref store, but most
commands only consider the superproject gitlink and ignore the submodule
ref store. For example, "git checkout --recurse-submodules" will check
out the commits in the superproject gitlinks (and put the submodules in
detached HEAD) instead of checking out the submodule branches.
Because of this, this commit introduces a new configuration value,
`submodule.propagateBranches`. The plan is for Git commands to
prioritize submodule ref store information over superproject gitlinks if
this value is true. Because "git branch --recurse-submodules" writes to
submodule ref stores, for the sake of clarity, it will not function
unless this configuration value is set.
This commit also includes changes that support working with submodules
from a superproject commit because "branch --recurse-submodules" (and
future commands) need to read .gitmodules and gitlinks from the
superproject commit, but submodules are typically read from the
filesystem's .gitmodules and the index's gitlinks. These changes are:
* add a submodules_of_tree() helper that gives the relevant
information of an in-tree submodule (e.g. path and oid) and
initializes the repository
* add is_tree_submodule_active() by adding a treeish_name parameter to
is_submodule_active()
* add the "submoduleNotUpdated" advice to advise users to update the
submodules in their trees
Incidentally, fix an incorrect usage string that combined the 'list'
usage of git branch (-l) with the 'create' usage; this string has been
incorrect since its inception, a8dfd5eac4 (Make builtin-branch.c use
parse_options., 2007-10-07).
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Glen Choo <chooglen@google.com>
Reviewed-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-29 08:04:45 +08:00
|
|
|
free(tree_path);
|
|
|
|
}
|
2024-09-30 17:13:27 +08:00
|
|
|
|
|
|
|
free(tree_buf);
|
branch: add --recurse-submodules option for branch creation
To improve the submodules UX, we would like to teach Git to handle
branches in submodules. Start this process by teaching "git branch" the
--recurse-submodules option so that "git branch --recurse-submodules
topic" will create the `topic` branch in the superproject and its
submodules.
Although this commit does not introduce breaking changes, it does not
work well with existing --recurse-submodules commands because "git
branch --recurse-submodules" writes to the submodule ref store, but most
commands only consider the superproject gitlink and ignore the submodule
ref store. For example, "git checkout --recurse-submodules" will check
out the commits in the superproject gitlinks (and put the submodules in
detached HEAD) instead of checking out the submodule branches.
Because of this, this commit introduces a new configuration value,
`submodule.propagateBranches`. The plan is for Git commands to
prioritize submodule ref store information over superproject gitlinks if
this value is true. Because "git branch --recurse-submodules" writes to
submodule ref stores, for the sake of clarity, it will not function
unless this configuration value is set.
This commit also includes changes that support working with submodules
from a superproject commit because "branch --recurse-submodules" (and
future commands) need to read .gitmodules and gitlinks from the
superproject commit, but submodules are typically read from the
filesystem's .gitmodules and the index's gitlinks. These changes are:
* add a submodules_of_tree() helper that gives the relevant
information of an in-tree submodule (e.g. path and oid) and
initializes the repository
* add is_tree_submodule_active() by adding a treeish_name parameter to
is_submodule_active()
* add the "submoduleNotUpdated" advice to advise users to update the
submodules in their trees
Incidentally, fix an incorrect usage string that combined the 'list'
usage of git branch (-l) with the 'create' usage; this string has been
incorrect since its inception, a8dfd5eac4 (Make builtin-branch.c use
parse_options., 2007-10-07).
Helped-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Glen Choo <chooglen@google.com>
Reviewed-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-29 08:04:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void submodules_of_tree(struct repository *r,
|
|
|
|
const struct object_id *treeish_name,
|
|
|
|
struct submodule_entry_list *out)
|
|
|
|
{
|
|
|
|
CALLOC_ARRAY(out->entries, 0);
|
|
|
|
out->entry_nr = 0;
|
|
|
|
out->entry_alloc = 0;
|
|
|
|
|
|
|
|
traverse_tree_submodules(r, treeish_name, NULL, treeish_name, out);
|
|
|
|
}
|
|
|
|
|
2024-09-30 17:13:27 +08:00
|
|
|
void submodule_entry_list_release(struct submodule_entry_list *list)
|
|
|
|
{
|
|
|
|
for (size_t i = 0; i < list->entry_nr; i++) {
|
|
|
|
free(list->entries[i].name_entry);
|
|
|
|
repo_clear(list->entries[i].repo);
|
|
|
|
free(list->entries[i].repo);
|
|
|
|
}
|
|
|
|
free(list->entries);
|
|
|
|
}
|
|
|
|
|
2018-03-29 06:35:28 +08:00
|
|
|
void submodule_free(struct repository *r)
|
2017-06-23 02:43:44 +08:00
|
|
|
{
|
2018-03-29 06:35:28 +08:00
|
|
|
if (r->submodule_cache)
|
|
|
|
submodule_cache_clear(r->submodule_cache);
|
2015-08-18 08:21:57 +08:00
|
|
|
}
|
2018-06-26 18:47:05 +08:00
|
|
|
|
config: add ctx arg to config_fn_t
Add a new "const struct config_context *ctx" arg to config_fn_t to hold
additional information about the config iteration operation.
config_context has a "struct key_value_info kvi" member that holds
metadata about the config source being read (e.g. what kind of config
source it is, the filename, etc). In this series, we're only interested
in .kvi, so we could have just used "struct key_value_info" as an arg,
but config_context makes it possible to add/adjust members in the future
without changing the config_fn_t signature. We could also consider other
ways of organizing the args (e.g. moving the config name and value into
config_context or key_value_info), but in my experiments, the
incremental benefit doesn't justify the added complexity (e.g. a
config_fn_t will sometimes invoke another config_fn_t but with a
different config value).
In subsequent commits, the .kvi member will replace the global "struct
config_reader" in config.c, making config iteration a global-free
operation. It requires much more work for the machinery to provide
meaningful values of .kvi, so for now, merely change the signature and
call sites, pass NULL as a placeholder value, and don't rely on the arg
in any meaningful way.
Most of the changes are performed by
contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every
config_fn_t:
- Modifies the signature to accept "const struct config_context *ctx"
- Passes "ctx" to any inner config_fn_t, if needed
- Adds UNUSED attributes to "ctx", if needed
Most config_fn_t instances are easily identified by seeing if they are
called by the various config functions. Most of the remaining ones are
manually named in the .cocci patch. Manual cleanups are still needed,
but the majority of it is trivial; it's either adjusting config_fn_t
that the .cocci patch didn't catch, or adding forward declarations of
"struct config_context ctx" to make the signatures make sense.
The non-trivial changes are in cases where we are invoking a config_fn_t
outside of config machinery, and we now need to decide what value of
"ctx" to pass. These cases are:
- trace2/tr2_cfg.c:tr2_cfg_set_fl()
This is indirectly called by git_config_set() so that the trace2
machinery can notice the new config values and update its settings
using the tr2 config parsing function, i.e. tr2_cfg_cb().
- builtin/checkout.c:checkout_main()
This calls git_xmerge_config() as a shorthand for parsing a CLI arg.
This might be worth refactoring away in the future, since
git_xmerge_config() can call git_default_config(), which can do much
more than just parsing.
Handle them by creating a KVI_INIT macro that initializes "struct
key_value_info" to a reasonable default, and use that to construct the
"ctx" arg.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-29 03:26:22 +08:00
|
|
|
static int config_print_callback(const char *var, const char *value,
|
|
|
|
const struct config_context *ctx UNUSED,
|
|
|
|
void *cb_data)
|
2018-10-05 21:05:52 +08:00
|
|
|
{
|
|
|
|
char *wanted_key = cb_data;
|
|
|
|
|
|
|
|
if (!strcmp(wanted_key, var))
|
|
|
|
printf("%s\n", value);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int print_config_from_gitmodules(struct repository *repo, const char *key)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
char *store_key;
|
|
|
|
|
|
|
|
ret = git_config_parse_key(key, &store_key, NULL);
|
|
|
|
if (ret < 0)
|
|
|
|
return CONFIG_INVALID_KEY;
|
|
|
|
|
|
|
|
config_from_gitmodules(config_print_callback, repo, store_key);
|
|
|
|
|
|
|
|
free(store_key);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-10-05 21:05:53 +08:00
|
|
|
int config_set_in_gitmodules_file_gently(const char *key, const char *value)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2024-03-13 05:47:00 +08:00
|
|
|
ret = git_config_set_in_file_gently(GITMODULES_FILE, key, NULL, value);
|
2018-10-05 21:05:53 +08:00
|
|
|
if (ret < 0)
|
|
|
|
/* Maybe the user already did that, don't error out here */
|
|
|
|
warning(_("Could not update .gitmodules entry %s"), key);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2018-06-26 18:47:06 +08:00
|
|
|
struct fetch_config {
|
|
|
|
int *max_children;
|
|
|
|
int *recurse_submodules;
|
|
|
|
};
|
|
|
|
|
config: add ctx arg to config_fn_t
Add a new "const struct config_context *ctx" arg to config_fn_t to hold
additional information about the config iteration operation.
config_context has a "struct key_value_info kvi" member that holds
metadata about the config source being read (e.g. what kind of config
source it is, the filename, etc). In this series, we're only interested
in .kvi, so we could have just used "struct key_value_info" as an arg,
but config_context makes it possible to add/adjust members in the future
without changing the config_fn_t signature. We could also consider other
ways of organizing the args (e.g. moving the config name and value into
config_context or key_value_info), but in my experiments, the
incremental benefit doesn't justify the added complexity (e.g. a
config_fn_t will sometimes invoke another config_fn_t but with a
different config value).
In subsequent commits, the .kvi member will replace the global "struct
config_reader" in config.c, making config iteration a global-free
operation. It requires much more work for the machinery to provide
meaningful values of .kvi, so for now, merely change the signature and
call sites, pass NULL as a placeholder value, and don't rely on the arg
in any meaningful way.
Most of the changes are performed by
contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every
config_fn_t:
- Modifies the signature to accept "const struct config_context *ctx"
- Passes "ctx" to any inner config_fn_t, if needed
- Adds UNUSED attributes to "ctx", if needed
Most config_fn_t instances are easily identified by seeing if they are
called by the various config functions. Most of the remaining ones are
manually named in the .cocci patch. Manual cleanups are still needed,
but the majority of it is trivial; it's either adjusting config_fn_t
that the .cocci patch didn't catch, or adding forward declarations of
"struct config_context ctx" to make the signatures make sense.
The non-trivial changes are in cases where we are invoking a config_fn_t
outside of config machinery, and we now need to decide what value of
"ctx" to pass. These cases are:
- trace2/tr2_cfg.c:tr2_cfg_set_fl()
This is indirectly called by git_config_set() so that the trace2
machinery can notice the new config values and update its settings
using the tr2 config parsing function, i.e. tr2_cfg_cb().
- builtin/checkout.c:checkout_main()
This calls git_xmerge_config() as a shorthand for parsing a CLI arg.
This might be worth refactoring away in the future, since
git_xmerge_config() can call git_default_config(), which can do much
more than just parsing.
Handle them by creating a KVI_INIT macro that initializes "struct
key_value_info" to a reasonable default, and use that to construct the
"ctx" arg.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-29 03:26:22 +08:00
|
|
|
static int gitmodules_fetch_config(const char *var, const char *value,
|
config: pass kvi to die_bad_number()
Plumb "struct key_value_info" through all code paths that end in
die_bad_number(), which lets us remove the helper functions that read
analogous values from "struct config_reader". As a result, nothing reads
config_reader.config_kvi any more, so remove that too.
In config.c, this requires changing the signature of
git_configset_get_value() to 'return' "kvi" in an out parameter so that
git_configset_get_<type>() can pass it to git_config_<type>(). Only
numeric types will use "kvi", so for non-numeric types (e.g.
git_configset_get_string()), pass NULL to indicate that the out
parameter isn't needed.
Outside of config.c, config callbacks now need to pass "ctx->kvi" to any
of the git_config_<type>() functions that parse a config string into a
number type. Included is a .cocci patch to make that refactor.
The only exceptional case is builtin/config.c, where git_config_<type>()
is called outside of a config callback (namely, on user-provided input),
so config source information has never been available. In this case,
die_bad_number() defaults to a generic, but perfectly descriptive
message. Let's provide a safe, non-NULL for "kvi" anyway, but make sure
not to change the message.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-29 03:26:27 +08:00
|
|
|
const struct config_context *ctx,
|
config: add ctx arg to config_fn_t
Add a new "const struct config_context *ctx" arg to config_fn_t to hold
additional information about the config iteration operation.
config_context has a "struct key_value_info kvi" member that holds
metadata about the config source being read (e.g. what kind of config
source it is, the filename, etc). In this series, we're only interested
in .kvi, so we could have just used "struct key_value_info" as an arg,
but config_context makes it possible to add/adjust members in the future
without changing the config_fn_t signature. We could also consider other
ways of organizing the args (e.g. moving the config name and value into
config_context or key_value_info), but in my experiments, the
incremental benefit doesn't justify the added complexity (e.g. a
config_fn_t will sometimes invoke another config_fn_t but with a
different config value).
In subsequent commits, the .kvi member will replace the global "struct
config_reader" in config.c, making config iteration a global-free
operation. It requires much more work for the machinery to provide
meaningful values of .kvi, so for now, merely change the signature and
call sites, pass NULL as a placeholder value, and don't rely on the arg
in any meaningful way.
Most of the changes are performed by
contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every
config_fn_t:
- Modifies the signature to accept "const struct config_context *ctx"
- Passes "ctx" to any inner config_fn_t, if needed
- Adds UNUSED attributes to "ctx", if needed
Most config_fn_t instances are easily identified by seeing if they are
called by the various config functions. Most of the remaining ones are
manually named in the .cocci patch. Manual cleanups are still needed,
but the majority of it is trivial; it's either adjusting config_fn_t
that the .cocci patch didn't catch, or adding forward declarations of
"struct config_context ctx" to make the signatures make sense.
The non-trivial changes are in cases where we are invoking a config_fn_t
outside of config machinery, and we now need to decide what value of
"ctx" to pass. These cases are:
- trace2/tr2_cfg.c:tr2_cfg_set_fl()
This is indirectly called by git_config_set() so that the trace2
machinery can notice the new config values and update its settings
using the tr2 config parsing function, i.e. tr2_cfg_cb().
- builtin/checkout.c:checkout_main()
This calls git_xmerge_config() as a shorthand for parsing a CLI arg.
This might be worth refactoring away in the future, since
git_xmerge_config() can call git_default_config(), which can do much
more than just parsing.
Handle them by creating a KVI_INIT macro that initializes "struct
key_value_info" to a reasonable default, and use that to construct the
"ctx" arg.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-29 03:26:22 +08:00
|
|
|
void *cb)
|
2018-06-26 18:47:06 +08:00
|
|
|
{
|
|
|
|
struct fetch_config *config = cb;
|
|
|
|
if (!strcmp(var, "submodule.fetchjobs")) {
|
fetch: avoid reading submodule config until needed
In "fetch", there are two parameters submodule_fetch_jobs_config and
recurse_submodules that can be set in a variety of ways: through
.gitmodules, through .git/config, and through the command line.
Currently "fetch" handles this by first reading .gitmodules, then
reading .git/config (allowing it to overwrite existing values), then
reading the command line (allowing it to overwrite existing values).
Notice that we can avoid reading .gitmodules if .git/config and/or the
command line already provides us with what we need. In addition, if
recurse_submodules is found to be "no", we do not need the value of
submodule_fetch_jobs_config.
Avoiding reading .gitmodules is especially important when we use "git
fetch" to perform lazy fetches in a partial clone because the
.gitmodules file itself might need to be lazy fetched (and otherwise
causing an infinite loop).
In light of all this, avoid reading .gitmodules until necessary. When
reading it, we may only need one of the two parameters it provides, so
teach fetch_config_from_gitmodules() to support NULL arguments. With
this patch, users (including Git itself when invoking "git fetch" to
lazy-fetch) will be able to guarantee avoiding reading .gitmodules by
passing --recurse-submodules=no.
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-18 12:01:33 +08:00
|
|
|
if (config->max_children)
|
|
|
|
*(config->max_children) =
|
config: pass kvi to die_bad_number()
Plumb "struct key_value_info" through all code paths that end in
die_bad_number(), which lets us remove the helper functions that read
analogous values from "struct config_reader". As a result, nothing reads
config_reader.config_kvi any more, so remove that too.
In config.c, this requires changing the signature of
git_configset_get_value() to 'return' "kvi" in an out parameter so that
git_configset_get_<type>() can pass it to git_config_<type>(). Only
numeric types will use "kvi", so for non-numeric types (e.g.
git_configset_get_string()), pass NULL to indicate that the out
parameter isn't needed.
Outside of config.c, config callbacks now need to pass "ctx->kvi" to any
of the git_config_<type>() functions that parse a config string into a
number type. Included is a .cocci patch to make that refactor.
The only exceptional case is builtin/config.c, where git_config_<type>()
is called outside of a config callback (namely, on user-provided input),
so config source information has never been available. In this case,
die_bad_number() defaults to a generic, but perfectly descriptive
message. Let's provide a safe, non-NULL for "kvi" anyway, but make sure
not to change the message.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-29 03:26:27 +08:00
|
|
|
parse_submodule_fetchjobs(var, value, ctx->kvi);
|
2018-06-26 18:47:06 +08:00
|
|
|
return 0;
|
|
|
|
} else if (!strcmp(var, "fetch.recursesubmodules")) {
|
fetch: avoid reading submodule config until needed
In "fetch", there are two parameters submodule_fetch_jobs_config and
recurse_submodules that can be set in a variety of ways: through
.gitmodules, through .git/config, and through the command line.
Currently "fetch" handles this by first reading .gitmodules, then
reading .git/config (allowing it to overwrite existing values), then
reading the command line (allowing it to overwrite existing values).
Notice that we can avoid reading .gitmodules if .git/config and/or the
command line already provides us with what we need. In addition, if
recurse_submodules is found to be "no", we do not need the value of
submodule_fetch_jobs_config.
Avoiding reading .gitmodules is especially important when we use "git
fetch" to perform lazy fetches in a partial clone because the
.gitmodules file itself might need to be lazy fetched (and otherwise
causing an infinite loop).
In light of all this, avoid reading .gitmodules until necessary. When
reading it, we may only need one of the two parameters it provides, so
teach fetch_config_from_gitmodules() to support NULL arguments. With
this patch, users (including Git itself when invoking "git fetch" to
lazy-fetch) will be able to guarantee avoiding reading .gitmodules by
passing --recurse-submodules=no.
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-18 12:01:33 +08:00
|
|
|
if (config->recurse_submodules)
|
|
|
|
*(config->recurse_submodules) =
|
|
|
|
parse_fetch_recurse_submodules_arg(var, value);
|
2018-06-26 18:47:06 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
void fetch_config_from_gitmodules(int *max_children, int *recurse_submodules)
|
|
|
|
{
|
|
|
|
struct fetch_config config = {
|
|
|
|
.max_children = max_children,
|
|
|
|
.recurse_submodules = recurse_submodules
|
|
|
|
};
|
2018-06-26 18:47:09 +08:00
|
|
|
config_from_gitmodules(gitmodules_fetch_config, the_repository, &config);
|
2018-06-26 18:47:06 +08:00
|
|
|
}
|
2018-06-26 18:47:07 +08:00
|
|
|
|
|
|
|
static int gitmodules_update_clone_config(const char *var, const char *value,
|
config: pass kvi to die_bad_number()
Plumb "struct key_value_info" through all code paths that end in
die_bad_number(), which lets us remove the helper functions that read
analogous values from "struct config_reader". As a result, nothing reads
config_reader.config_kvi any more, so remove that too.
In config.c, this requires changing the signature of
git_configset_get_value() to 'return' "kvi" in an out parameter so that
git_configset_get_<type>() can pass it to git_config_<type>(). Only
numeric types will use "kvi", so for non-numeric types (e.g.
git_configset_get_string()), pass NULL to indicate that the out
parameter isn't needed.
Outside of config.c, config callbacks now need to pass "ctx->kvi" to any
of the git_config_<type>() functions that parse a config string into a
number type. Included is a .cocci patch to make that refactor.
The only exceptional case is builtin/config.c, where git_config_<type>()
is called outside of a config callback (namely, on user-provided input),
so config source information has never been available. In this case,
die_bad_number() defaults to a generic, but perfectly descriptive
message. Let's provide a safe, non-NULL for "kvi" anyway, but make sure
not to change the message.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-29 03:26:27 +08:00
|
|
|
const struct config_context *ctx,
|
2018-06-26 18:47:07 +08:00
|
|
|
void *cb)
|
|
|
|
{
|
|
|
|
int *max_jobs = cb;
|
|
|
|
if (!strcmp(var, "submodule.fetchjobs"))
|
config: pass kvi to die_bad_number()
Plumb "struct key_value_info" through all code paths that end in
die_bad_number(), which lets us remove the helper functions that read
analogous values from "struct config_reader". As a result, nothing reads
config_reader.config_kvi any more, so remove that too.
In config.c, this requires changing the signature of
git_configset_get_value() to 'return' "kvi" in an out parameter so that
git_configset_get_<type>() can pass it to git_config_<type>(). Only
numeric types will use "kvi", so for non-numeric types (e.g.
git_configset_get_string()), pass NULL to indicate that the out
parameter isn't needed.
Outside of config.c, config callbacks now need to pass "ctx->kvi" to any
of the git_config_<type>() functions that parse a config string into a
number type. Included is a .cocci patch to make that refactor.
The only exceptional case is builtin/config.c, where git_config_<type>()
is called outside of a config callback (namely, on user-provided input),
so config source information has never been available. In this case,
die_bad_number() defaults to a generic, but perfectly descriptive
message. Let's provide a safe, non-NULL for "kvi" anyway, but make sure
not to change the message.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-29 03:26:27 +08:00
|
|
|
*max_jobs = parse_submodule_fetchjobs(var, value, ctx->kvi);
|
2018-06-26 18:47:07 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
void update_clone_config_from_gitmodules(int *max_jobs)
|
|
|
|
{
|
2018-06-26 18:47:09 +08:00
|
|
|
config_from_gitmodules(gitmodules_update_clone_config, the_repository, &max_jobs);
|
2018-06-26 18:47:07 +08:00
|
|
|
}
|