2009-10-19 16:38:32 +04:00
|
|
|
#ifndef SUBMODULE_H
|
|
|
|
#define SUBMODULE_H
|
|
|
|
|
argv-array: rename to strvec
The name "argv-array" isn't very good, because it describes what the
data type can be used for (program argument arrays), not what it
actually is (a dynamically-growing string array that maintains a
NULL-terminator invariant). This leads to people being hesitant to use
it for other cases where it would actually be a good fit. The existing
name is also clunky to use. It's overly long, and the name often leads
to saying things like "argv.argv" (i.e., the field names overlap with
variable names, since they're describing the use, not the type). Let's
give it a more neutral name.
I settled on "strvec" because "vector" is the name for a dynamic array
type in many programming languages. "strarray" would work, too, but it's
longer and a bit more awkward to say (and don't we all say these things
in our mind as we type them?).
A more extreme direction would be a generic data structure which stores
a NULL-terminated of _any_ type. That would be easy to do with void
pointers, but we'd lose some type safety for the existing cases. Plus it
raises questions about memory allocation and ownership. So I limited
myself here to changing names only, and not semantics. If we do find a
use for that more generic data type, we could perhaps implement it at a
lower level and then provide type-safe wrappers around it for strings.
But that can come later.
This patch does the minimum to convert the struct and function names in
the header and implementation, leaving a few things for follow-on
patches:
- files retain their original names for now
- struct field names are retained for now
- there's a preprocessor compat layer that lets most users remain the
same for now. The exception is headers which made a manual forward
declaration of the struct. I've converted them (and their dependent
function declarations) here.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28 23:23:25 +03:00
|
|
|
struct strvec;
|
2018-08-15 20:54:05 +03:00
|
|
|
struct cache_entry;
|
|
|
|
struct diff_options;
|
|
|
|
struct index_state;
|
|
|
|
struct object_id;
|
2017-03-31 04:40:00 +03:00
|
|
|
struct oid_array;
|
2018-08-15 20:54:05 +03:00
|
|
|
struct pathspec;
|
2017-04-05 20:47:19 +03:00
|
|
|
struct remote;
|
2018-08-15 20:54:05 +03:00
|
|
|
struct repository;
|
|
|
|
struct string_list;
|
|
|
|
struct strbuf;
|
2010-06-25 18:56:47 +04:00
|
|
|
|
2011-03-07 01:10:46 +03:00
|
|
|
enum {
|
2016-12-19 21:25:32 +03:00
|
|
|
RECURSE_SUBMODULES_ONLY = -5,
|
2015-11-17 14:05:56 +03:00
|
|
|
RECURSE_SUBMODULES_CHECK = -4,
|
2015-08-18 03:22:00 +03:00
|
|
|
RECURSE_SUBMODULES_ERROR = -3,
|
2015-08-18 03:21:57 +03:00
|
|
|
RECURSE_SUBMODULES_NONE = -2,
|
2011-03-07 01:10:46 +03:00
|
|
|
RECURSE_SUBMODULES_ON_DEMAND = -1,
|
|
|
|
RECURSE_SUBMODULES_OFF = 0,
|
|
|
|
RECURSE_SUBMODULES_DEFAULT = 1,
|
|
|
|
RECURSE_SUBMODULES_ON = 2
|
|
|
|
};
|
|
|
|
|
2016-03-01 05:07:11 +03:00
|
|
|
enum submodule_update_type {
|
|
|
|
SM_UPDATE_UNSPECIFIED = 0,
|
|
|
|
SM_UPDATE_CHECKOUT,
|
|
|
|
SM_UPDATE_REBASE,
|
|
|
|
SM_UPDATE_MERGE,
|
|
|
|
SM_UPDATE_NONE,
|
|
|
|
SM_UPDATE_COMMAND
|
|
|
|
};
|
|
|
|
|
|
|
|
struct submodule_update_strategy {
|
|
|
|
enum submodule_update_type type;
|
|
|
|
const char *command;
|
|
|
|
};
|
2016-03-01 05:07:13 +03:00
|
|
|
#define SUBMODULE_UPDATE_STRATEGY_INIT {SM_UPDATE_UNSPECIFIED, NULL}
|
2016-03-01 05:07:11 +03:00
|
|
|
|
2018-06-30 12:20:31 +03:00
|
|
|
int is_gitmodules_unmerged(const struct index_state *istate);
|
2018-10-05 16:05:59 +03:00
|
|
|
int is_writing_gitmodules_ok(void);
|
2018-06-30 12:20:31 +03:00
|
|
|
int is_staging_gitmodules_ok(struct index_state *istate);
|
|
|
|
int update_path_in_gitmodules(const char *oldpath, const char *newpath);
|
|
|
|
int remove_path_from_gitmodules(const char *path);
|
|
|
|
void stage_updated_gitmodules(struct index_state *istate);
|
|
|
|
void set_diffopt_flags_from_submodule_config(struct diff_options *,
|
|
|
|
const char *path);
|
|
|
|
int git_default_submodule_config(const char *var, const char *value, void *cb);
|
2017-05-26 22:10:12 +03:00
|
|
|
|
|
|
|
struct option;
|
|
|
|
int option_parse_recurse_submodules_worktree_updater(const struct option *opt,
|
|
|
|
const char *arg, int unset);
|
2018-06-30 12:20:31 +03:00
|
|
|
int is_submodule_active(struct repository *repo, const char *path);
|
2017-03-15 00:46:31 +03:00
|
|
|
/*
|
|
|
|
* Determine if a submodule has been populated at a given 'path' by checking if
|
|
|
|
* the <path>/.git resolves to a valid git repository.
|
|
|
|
* If return_error_code is NULL, die on error.
|
|
|
|
* Otherwise the return error code is the same as of resolve_gitdir_gently.
|
|
|
|
*/
|
2018-06-30 12:20:31 +03:00
|
|
|
int is_submodule_populated_gently(const char *path, int *return_error_code);
|
|
|
|
void die_in_unpopulated_submodule(const struct index_state *istate,
|
|
|
|
const char *prefix);
|
|
|
|
void die_path_inside_submodule(const struct index_state *istate,
|
|
|
|
const struct pathspec *ps);
|
|
|
|
enum submodule_update_type parse_submodule_update_type(const char *value);
|
|
|
|
int parse_submodule_update_strategy(const char *value,
|
|
|
|
struct submodule_update_strategy *dst);
|
|
|
|
const char *submodule_strategy_to_string(const struct submodule_update_strategy *s);
|
|
|
|
void handle_ignore_submodules_arg(struct diff_options *, const char *);
|
2020-08-12 22:44:02 +03:00
|
|
|
void show_submodule_diff_summary(struct diff_options *o, const char *path,
|
2018-06-30 12:20:31 +03:00
|
|
|
struct object_id *one, struct object_id *two,
|
|
|
|
unsigned dirty_submodule);
|
|
|
|
void show_submodule_inline_diff(struct diff_options *o, const char *path,
|
|
|
|
struct object_id *one, struct object_id *two,
|
|
|
|
unsigned dirty_submodule);
|
2017-03-15 00:46:34 +03:00
|
|
|
/* Check if we want to update any submodule.*/
|
2018-06-30 12:20:31 +03:00
|
|
|
int should_update_submodules(void);
|
2017-03-15 00:46:34 +03:00
|
|
|
/*
|
|
|
|
* Returns the submodule struct if the given ce entry is a submodule
|
|
|
|
* and it should be updated. Returns NULL otherwise.
|
|
|
|
*/
|
2018-06-30 12:20:31 +03:00
|
|
|
const struct submodule *submodule_from_ce(const struct cache_entry *ce);
|
|
|
|
void check_for_new_submodule_commits(struct object_id *oid);
|
|
|
|
int fetch_populated_submodules(struct repository *r,
|
argv-array: rename to strvec
The name "argv-array" isn't very good, because it describes what the
data type can be used for (program argument arrays), not what it
actually is (a dynamically-growing string array that maintains a
NULL-terminator invariant). This leads to people being hesitant to use
it for other cases where it would actually be a good fit. The existing
name is also clunky to use. It's overly long, and the name often leads
to saying things like "argv.argv" (i.e., the field names overlap with
variable names, since they're describing the use, not the type). Let's
give it a more neutral name.
I settled on "strvec" because "vector" is the name for a dynamic array
type in many programming languages. "strarray" would work, too, but it's
longer and a bit more awkward to say (and don't we all say these things
in our mind as we type them?).
A more extreme direction would be a generic data structure which stores
a NULL-terminated of _any_ type. That would be easy to do with void
pointers, but we'd lose some type safety for the existing cases. Plus it
raises questions about memory allocation and ownership. So I limited
myself here to changing names only, and not semantics. If we do find a
use for that more generic data type, we could perhaps implement it at a
lower level and then provide type-safe wrappers around it for strings.
But that can come later.
This patch does the minimum to convert the struct and function names in
the header and implementation, leaving a few things for follow-on
patches:
- files retain their original names for now
- struct field names are retained for now
- there's a preprocessor compat layer that lets most users remain the
same for now. The exception is headers which made a manual forward
declaration of the struct. I've converted them (and their dependent
function declarations) here.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28 23:23:25 +03:00
|
|
|
const struct strvec *options,
|
2018-06-30 12:20:31 +03:00
|
|
|
const char *prefix,
|
|
|
|
int command_line_option,
|
|
|
|
int default_option,
|
|
|
|
int quiet, int max_parallel_jobs);
|
|
|
|
unsigned is_submodule_modified(const char *path, int ignore_untracked);
|
|
|
|
int submodule_uses_gitfile(const char *path);
|
2016-12-21 02:20:11 +03:00
|
|
|
|
|
|
|
#define SUBMODULE_REMOVAL_DIE_ON_ERROR (1<<0)
|
|
|
|
#define SUBMODULE_REMOVAL_IGNORE_UNTRACKED (1<<1)
|
|
|
|
#define SUBMODULE_REMOVAL_IGNORE_IGNORED_UNTRACKED (1<<2)
|
2018-06-30 12:20:31 +03:00
|
|
|
int bad_to_remove_submodule(const char *path, unsigned flags);
|
2018-05-15 23:00:28 +03:00
|
|
|
|
|
|
|
int add_submodule_odb(const char *path);
|
pull: optionally rebase submodules (remote submodule changes only)
Teach pull to optionally update submodules when '--recurse-submodules'
is provided. This will teach pull to run 'submodule update --rebase'
when the '--recurse-submodules' and '--rebase' flags are given under
specific circumstances.
On a rebase workflow:
=====================
1. Both sides change the submodule
------------------------------
Let's assume the following history in a submodule:
H---I---J---K---L local branch
\
M---N---O---P remote branch
and the following in the superproject (recorded submodule in parens):
A(H)---B(I)---F(K)---G(L) local branch
\
C(N)---D(N)---E(P) remote branch
In an ideal world this would rebase the submodule and rewrite
the submodule pointers that the superproject points at such that
the superproject looks like
A(H)---B(I) F(K')---G(L') rebased branch
\ /
C(N)---D(N)---E(P) remote branch
and the submodule as:
J---K---L (old dangeling tip)
/
H---I J'---K'---L' rebased branch
\ /
M---N---O---P remote branch
And if a conflict arises in the submodule the superproject rebase
would stop at that commit at which the submodule conflict occurs.
Currently a "pull --rebase" in the superproject produces
a merge conflict as the submodule pointer changes are
conflicting and cannot be resolved.
2. Local submodule changes only
-----------------------
Assuming histories as above, except that the remote branch
would not contain submodule changes, then a result as
A(H)---B(I) F(K)---G(L) rebased branch
\ /
C(I)---D(I)---E(I) remote branch
is desire-able. This is what currently happens in rebase.
If the recursive flag is given, the ideal git would
produce a superproject as:
A(H)---B(I) F(K')---G(L') rebased branch (incl. sub rebase!)
\ /
C(I)---D(I)---E(I) remote branch
and the submodule as:
J---K---L (old dangeling tip)
/
H---I J'---K'---L' locally rebased branch
\ /
M---N---O---P advanced branch
This patch doesn't address this issue, however
a test is added that this fails up front.
3. Remote submodule changes only
----------------------
Assuming histories as in (1) except that the local superproject branch
would not have touched the submodule the rebase already works out in the
superproject with no conflicts:
A(H)---B(I) F(P)---G(P) rebased branch (no sub changes)
\ /
C(N)---D(N)---E(P) remote branch
The recurse flag as presented in this patch would additionally
update the submodule as:
H---I J'---K'---L' rebased branch
\ /
M---N---O---P remote branch
As neither J, K, L nor J', K', L' are referred to from the superproject,
no rewriting of the superproject commits is required.
Conclusion for 'pull --rebase --recursive'
-----------------------------------------
If there are no local superproject changes it is sufficient to call
"submodule update --rebase" as this produces the desired results. In case
of conflicts, the behavior is the same as in 'submodule update --recursive'
which is assumed to be sane.
This patch implements (3) only.
On a merge workflow:
====================
We'll start off with the same underlying DAG as in (1) in the rebase
workflow. So in an ideal world a 'pull --merge --recursive' would
produce this:
H---I---J---K---L----X
\ /
M---N---O---P
with X as the new merge-commit in the submodule and the superproject
as:
A(H)---B(I)---F(K)---G(L)---Y(X)
\ /
C(N)---D(N)---E(P)
However modifying the submodules on the fly is not supported in git-merge
such that Y(X) is not easy to produce in a single patch. In fact git-merge
doesn't know about submodules at all.
However when at least one side does not contain commits touching the
submodule at all, then we do not need to perform the merge for the
submodule but a fast-forward can be done via checking out either L or P
in the submodule. This strategy is implemented in 68d03e4a6e (Implement
automatic fast-forward merge for submodules, 2010-07-07) already, so
to align with the rebase behavior we need to also update the worktree
of the submodule.
Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-23 22:13:02 +03:00
|
|
|
|
2018-05-24 23:47:29 +03:00
|
|
|
/*
|
|
|
|
* Checks if there are submodule changes in a..b. If a is the null OID,
|
|
|
|
* checks b and all its ancestors instead.
|
|
|
|
*/
|
2018-10-19 20:34:43 +03:00
|
|
|
int submodule_touches_in_range(struct repository *r,
|
2018-09-21 18:57:35 +03:00
|
|
|
struct object_id *a,
|
2018-06-30 12:20:31 +03:00
|
|
|
struct object_id *b);
|
2018-10-19 20:34:43 +03:00
|
|
|
int find_unpushed_submodules(struct repository *r,
|
2018-09-21 18:57:35 +03:00
|
|
|
struct oid_array *commits,
|
2018-06-30 12:20:31 +03:00
|
|
|
const char *remotes_name,
|
|
|
|
struct string_list *needs_pushing);
|
2018-05-17 01:58:23 +03:00
|
|
|
struct refspec;
|
2018-10-19 20:34:43 +03:00
|
|
|
int push_unpushed_submodules(struct repository *r,
|
2018-09-21 18:57:35 +03:00
|
|
|
struct oid_array *commits,
|
2018-06-30 12:20:31 +03:00
|
|
|
const struct remote *remote,
|
|
|
|
const struct refspec *rs,
|
|
|
|
const struct string_list *push_options,
|
|
|
|
int dry_run);
|
2017-03-26 05:42:30 +03:00
|
|
|
/*
|
|
|
|
* Given a submodule path (as in the index), return the repository
|
|
|
|
* path of that submodule in 'buf'. Return -1 on error or when the
|
|
|
|
* submodule is not initialized.
|
|
|
|
*/
|
|
|
|
int submodule_to_gitdir(struct strbuf *buf, const char *submodule);
|
2009-10-19 16:38:32 +04:00
|
|
|
|
2019-10-02 00:27:18 +03:00
|
|
|
/*
|
|
|
|
* Make sure that no submodule's git dir is nested in a sibling submodule's.
|
|
|
|
*/
|
|
|
|
int validate_submodule_git_dir(char *git_dir, const char *submodule_name);
|
|
|
|
|
2017-03-15 00:46:37 +03:00
|
|
|
#define SUBMODULE_MOVE_HEAD_DRY_RUN (1<<0)
|
|
|
|
#define SUBMODULE_MOVE_HEAD_FORCE (1<<1)
|
2018-06-30 12:20:31 +03:00
|
|
|
int submodule_move_head(const char *path,
|
|
|
|
const char *old,
|
|
|
|
const char *new_head,
|
|
|
|
unsigned flags);
|
2017-03-15 00:46:37 +03:00
|
|
|
|
submodule: unset core.worktree if no working tree is present
When a submodules work tree is removed, we should unset its core.worktree
setting as the worktree is no longer present. This is not just in line
with the conceptual view of submodules, but it fixes an inconvenience
for looking at submodules that are not checked out:
git clone --recurse-submodules git://github.com/git/git && cd git &&
git checkout --recurse-submodules v2.13.0
git -C .git/modules/sha1collisiondetection log
fatal: cannot chdir to '../../../sha1collisiondetection': \
No such file or directory
With this patch applied, the final call to git log works instead of dying
in its setup, as the checkout will unset the core.worktree setting such
that following log will be run in a bare repository.
This patch covers all commands that are in the unpack machinery, i.e.
checkout, read-tree, reset. A follow up patch will address
"git submodule deinit", which will also make use of the new function
submodule_unset_core_worktree(), which is why we expose it in this patch.
This patch was authored as 4fa4f90ccd (submodule: unset core.worktree if
no working tree is present, 2018-06-12), which was reverted as part of
f178c13fda (Revert "Merge branch 'sb/submodule-core-worktree'",
2018-09-07). The revert was needed as the nearby commit e98317508c
(submodule: ensure core.worktree is set after update, 2018-06-18) is
faulty and at the time of 7e25437d35 (Merge branch
'sb/submodule-core-worktree', 2018-07-18) we could not revert the faulty
commit only, as they were depending on each other: If core.worktree is
unset, we have to have ways to ensure that it is set again once
the working tree reappears again.
Now that 4d6d6ef1fc (Merge branch 'sb/submodule-update-in-c', 2018-09-17),
specifically 74d4731da1 (submodule--helper: replace
connect-gitdir-workingtree by ensure-core-worktree, 2018-08-13) is
present, we already check and ensure core.worktree is set when
populating a new work tree, such that we can re-introduce the commits
that unset core.worktree when removing the worktree.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-15 02:59:43 +03:00
|
|
|
void submodule_unset_core_worktree(const struct submodule *sub);
|
|
|
|
|
2016-04-28 16:38:20 +03:00
|
|
|
/*
|
|
|
|
* Prepare the "env_array" parameter of a "struct child_process" for executing
|
2017-09-21 15:43:37 +03:00
|
|
|
* a submodule by clearing any repo-specific environment variables, but
|
submodule: stop sanitizing config options
The point of having a whitelist of command-line config
options to pass to submodules was two-fold:
1. It prevented obvious nonsense like using core.worktree
for multiple repos.
2. It could prevent surprise when the user did not mean
for the options to leak to the submodules (e.g.,
http.sslverify=false).
For case 1, the answer is mostly "if it hurts, don't do
that". For case 2, we can note that any such example has a
matching inverted surprise (e.g., a user who meant
http.sslverify=true to apply everywhere, but it didn't).
So this whitelist is probably not giving us any benefit, and
is already creating a hassle as people propose things to put
on it. Let's just drop it entirely.
Note that we still need to keep a special code path for
"prepare the submodule environment", because we still have
to take care to pass through $GIT_CONFIG_PARAMETERS (and
block the rest of the repo-specific environment variables).
We can do this easily from within the submodule shell
script, which lets us drop the submodule--helper option
entirely (and it's OK to do so because as a "--" program, it
is entirely a private implementation detail).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-05 04:22:19 +03:00
|
|
|
* retaining any config in the environment.
|
2016-04-28 16:38:20 +03:00
|
|
|
*/
|
argv-array: rename to strvec
The name "argv-array" isn't very good, because it describes what the
data type can be used for (program argument arrays), not what it
actually is (a dynamically-growing string array that maintains a
NULL-terminator invariant). This leads to people being hesitant to use
it for other cases where it would actually be a good fit. The existing
name is also clunky to use. It's overly long, and the name often leads
to saying things like "argv.argv" (i.e., the field names overlap with
variable names, since they're describing the use, not the type). Let's
give it a more neutral name.
I settled on "strvec" because "vector" is the name for a dynamic array
type in many programming languages. "strarray" would work, too, but it's
longer and a bit more awkward to say (and don't we all say these things
in our mind as we type them?).
A more extreme direction would be a generic data structure which stores
a NULL-terminated of _any_ type. That would be easy to do with void
pointers, but we'd lose some type safety for the existing cases. Plus it
raises questions about memory allocation and ownership. So I limited
myself here to changing names only, and not semantics. If we do find a
use for that more generic data type, we could perhaps implement it at a
lower level and then provide type-safe wrappers around it for strings.
But that can come later.
This patch does the minimum to convert the struct and function names in
the header and implementation, leaving a few things for follow-on
patches:
- files retain their original names for now
- struct field names are retained for now
- there's a preprocessor compat layer that lets most users remain the
same for now. The exception is headers which made a manual forward
declaration of the struct. I've converted them (and their dependent
function declarations) here.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28 23:23:25 +03:00
|
|
|
void prepare_submodule_repo_env(struct strvec *out);
|
2016-04-28 16:38:20 +03:00
|
|
|
|
2016-12-12 22:04:35 +03:00
|
|
|
#define ABSORB_GITDIR_RECURSE_SUBMODULES (1<<0)
|
2019-05-10 00:27:31 +03:00
|
|
|
void absorb_git_dir_into_superproject(const char *path,
|
2018-06-30 12:20:31 +03:00
|
|
|
unsigned flags);
|
2017-03-09 02:07:42 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Return the absolute path of the working tree of the superproject, which this
|
|
|
|
* project is a submodule of. If this repository is not a submodule of
|
2020-03-10 16:11:24 +03:00
|
|
|
* another repository, return 0.
|
2017-03-09 02:07:42 +03:00
|
|
|
*/
|
2020-03-10 16:11:24 +03:00
|
|
|
int get_superproject_working_tree(struct strbuf *buf);
|
2017-03-09 02:07:42 +03:00
|
|
|
|
2009-10-19 16:38:32 +04:00
|
|
|
#endif
|