2008-02-07 16:40:08 +00:00
|
|
|
#ifndef BRANCH_H
|
|
|
|
#define BRANCH_H
|
|
|
|
|
2018-11-10 05:49:00 +00:00
|
|
|
struct repository;
|
2018-08-15 17:54:05 +00:00
|
|
|
struct strbuf;
|
|
|
|
|
2018-08-15 17:54:07 +00:00
|
|
|
enum branch_track {
|
|
|
|
BRANCH_TRACK_UNSPECIFIED = -1,
|
|
|
|
BRANCH_TRACK_NEVER = 0,
|
|
|
|
BRANCH_TRACK_REMOTE,
|
|
|
|
BRANCH_TRACK_ALWAYS,
|
|
|
|
BRANCH_TRACK_EXPLICIT,
|
branch: add flags and config to inherit tracking
It can be helpful when creating a new branch to use the existing
tracking configuration from the branch point. However, there is
currently not a method to automatically do so.
Teach git-{branch,checkout,switch} an "inherit" argument to the
"--track" option. When this is set, creating a new branch will cause the
tracking configuration to default to the configuration of the branch
point, if set.
For example, if branch "main" tracks "origin/main", and we run
`git checkout --track=inherit -b feature main`, then branch "feature"
will track "origin/main". Thus, `git status` will show us how far
ahead/behind we are from origin, and `git pull` will pull from origin.
This is particularly useful when creating branches across many
submodules, such as with `git submodule foreach ...` (or if running with
a patch such as [1], which we use at $job), as it avoids having to
manually set tracking info for each submodule.
Since we've added an argument to "--track", also add "--track=direct" as
another way to explicitly get the original "--track" behavior ("--track"
without an argument still works as well).
Finally, teach branch.autoSetupMerge a new "inherit" option. When this
is set, "--track=inherit" becomes the default behavior.
[1]: https://lore.kernel.org/git/20180927221603.148025-1-sbeller@google.com/
Signed-off-by: Josh Steadmon <steadmon@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-21 03:30:23 +00:00
|
|
|
BRANCH_TRACK_OVERRIDE,
|
|
|
|
BRANCH_TRACK_INHERIT,
|
branch: new autosetupmerge option 'simple' for matching branches
With the default push.default option, "simple", beginners are
protected from accidentally pushing to the "wrong" branch in
centralized workflows: if the remote tracking branch they would push
to does not have the same name as the local branch, and they try to do
a "default push", they get an error and explanation with options.
There is a particular centralized workflow where this often happens:
a user branches to a new local topic branch from an existing
remote branch, eg with "checkout -b feature1 origin/master". With
the default branch.autosetupmerge configuration (value "true"), git
will automatically add origin/master as the upstream tracking branch.
When the user pushes with a default "git push", with the intention of
pushing their (new) topic branch to the remote, they get an error, and
(amongst other things) a suggestion to run "git push origin HEAD".
If they follow this suggestion the push succeeds, but on subsequent
default pushes they continue to get an error - so eventually they
figure out to add "-u" to change the tracking branch, or they spelunk
the push.default config doc as proposed and set it to "current", or
some GUI tooling does one or the other of these things for them.
When one of their coworkers later works on the same topic branch,
they don't get any of that "weirdness". They just "git checkout
feature1" and everything works exactly as they expect, with the shared
remote branch set up as remote tracking branch, and push and pull
working out of the box.
The "stable state" for this way of working is that local branches have
the same-name remote tracking branch (origin/feature1 in this
example), and multiple people can work on that remote feature branch
at the same time, trusting "git pull" to merge or rebase as required
for them to be able to push their interim changes to that same feature
branch on that same remote.
(merging from the upstream "master" branch, and merging back to it,
are separate more involved processes in this flow).
There is a problem in this flow/way of working, however, which is that
the first user, when they first branched from origin/master, ended up
with the "wrong" remote tracking branch (different from the stable
state). For a while, before they pushed (and maybe longer, if they
don't use -u/--set-upstream), their "git pull" wasn't getting other
users' changes to the feature branch - it was getting any changes from
the remote "master" branch instead (a completely different class of
changes!)
An experienced git user might say "well yeah, that's what it means to
have the remote tracking branch set to origin/master!" - but the
original user above didn't *ask* to have the remote master branch
added as remote tracking branch - that just happened automatically
when they branched their feature branch. They didn't necessarily even
notice or understand the meaning of the "set up to track 'origin/master'"
message when they created the branch - especially if they are using a
GUI.
Looking at how to fix this, you might think "OK, so disable auto setup
of remote tracking - set branch.autosetupmerge to false" - but that
will inconvenience the *second* user in this story - the one who just
wanted to start working on the topic branch. The first and second
users swap roles at different points in time of course - they should
both have a sane configuration that does the right thing in both
situations.
Make this "branches have the same name locally as on the remote"
workflow less painful / more obvious by introducing a new
branch.autosetupmerge option called "simple", to match the same-name
"push.default" option that makes similar assumptions.
This new option automatically sets up tracking in a *subset* of the
current default situations: when the original ref is a remote tracking
branch *and* has the same branch name on the remote (as the new local
branch name).
Update the error displayed when the 'push.default=simple' configuration
rejects a mismatching-upstream-name default push, to offer this new
branch.autosetupmerge option that will prevent this class of error.
With this new configuration, in the example situation above, the first
user does *not* get origin/master set up as the tracking branch for
the new local branch. If they "git pull" in their new local-only
branch, they get an error explaining there is no upstream branch -
which makes sense and is helpful. If they "git push", they get an
error explaining how to push *and* suggesting they specify
--set-upstream - which is exactly the right thing to do for them.
This new option is likely not appropriate for users intentionally
implementing a "triangular workflow" with a shared upstream tracking
branch, that they "git pull" in and a "private" feature branch that
they push/force-push to just for remote safe-keeping until they are
ready to push up to the shared branch explicitly/separately. Such
users are likely to prefer keeping the current default
merge.autosetupmerge=true behavior, and change their push.default to
"current".
Also extend the existing branch tests with three new cases testing
this option - the obvious matching-name and non-matching-name cases,
and also a non-matching-ref-type case. The matching-name case needs to
temporarily create an independent repo to fetch from, as the general
strategy of using the local repo as the remote in these tests
precludes locally branching with the same name as in the "remote".
Signed-off-by: Tao Klerks <tao@klerks.biz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-29 09:56:44 +00:00
|
|
|
BRANCH_TRACK_SIMPLE,
|
2018-08-15 17:54:07 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
extern enum branch_track git_branch_track;
|
|
|
|
|
2008-02-07 16:40:16 +00:00
|
|
|
/* Functions for acting on the information about branches. */
|
|
|
|
|
2022-01-29 00:04:41 +00:00
|
|
|
/**
|
|
|
|
* Sets branch.<new_ref>.{remote,merge} config settings such that
|
|
|
|
* new_ref tracks orig_ref according to the specified tracking mode.
|
|
|
|
*
|
|
|
|
* - new_ref is the name of the branch that we are setting tracking
|
|
|
|
* for.
|
|
|
|
*
|
|
|
|
* - orig_ref is the name of the ref that is 'upstream' of new_ref.
|
|
|
|
* orig_ref will be expanded with DWIM so that the config settings
|
|
|
|
* are in the correct format e.g. "refs/remotes/origin/main" instead
|
|
|
|
* of "origin/main".
|
|
|
|
*
|
|
|
|
* - track is the tracking mode e.g. BRANCH_TRACK_REMOTE causes
|
|
|
|
* new_ref to track orig_ref directly, whereas BRANCH_TRACK_INHERIT
|
|
|
|
* causes new_ref to track whatever orig_ref tracks.
|
|
|
|
*
|
|
|
|
* - quiet suppresses tracking information.
|
|
|
|
*/
|
|
|
|
void dwim_and_setup_tracking(struct repository *r, const char *new_ref,
|
|
|
|
const char *orig_ref, enum branch_track track,
|
|
|
|
int quiet);
|
|
|
|
|
2008-02-07 16:40:16 +00:00
|
|
|
/*
|
2016-11-04 16:30:12 +00:00
|
|
|
* Creates a new branch, where:
|
|
|
|
*
|
2018-11-10 05:49:00 +00:00
|
|
|
* - r is the repository to add a branch to
|
|
|
|
*
|
2016-11-04 16:30:12 +00:00
|
|
|
* - name is the new branch name
|
|
|
|
*
|
|
|
|
* - start_name is the name of the existing branch that the new branch should
|
|
|
|
* start from
|
|
|
|
*
|
|
|
|
* - force enables overwriting an existing (non-head) branch
|
|
|
|
*
|
2022-01-29 00:04:42 +00:00
|
|
|
* - clobber_head_ok, when enabled with 'force', allows the currently
|
|
|
|
* checked out (head) branch to be overwritten
|
2017-11-18 17:26:45 +00:00
|
|
|
*
|
2016-11-04 16:30:12 +00:00
|
|
|
* - reflog creates a reflog for the branch
|
|
|
|
*
|
2017-11-18 17:26:45 +00:00
|
|
|
* - quiet suppresses tracking information
|
|
|
|
*
|
2016-11-04 16:30:12 +00:00
|
|
|
* - track causes the new branch to be configured to merge the remote branch
|
|
|
|
* that start_name is a tracking branch for (if any).
|
2017-11-18 17:26:46 +00:00
|
|
|
*
|
2022-01-29 00:04:43 +00:00
|
|
|
* - dry_run causes the branch to be validated but not created.
|
|
|
|
*
|
2008-02-07 16:40:16 +00:00
|
|
|
*/
|
2018-11-10 05:49:00 +00:00
|
|
|
void create_branch(struct repository *r,
|
|
|
|
const char *name, const char *start_name,
|
2017-11-18 17:26:46 +00:00
|
|
|
int force, int clobber_head_ok,
|
2022-01-29 00:04:43 +00:00
|
|
|
int reflog, int quiet, enum branch_track track,
|
|
|
|
int dry_run);
|
2008-02-07 16:40:08 +00: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 00:04:45 +00:00
|
|
|
/*
|
|
|
|
* Creates a new branch in a repository and its submodules (and its
|
|
|
|
* submodules, recursively). The parameters are mostly analogous to
|
|
|
|
* those of create_branch() except for start_name, which is represented
|
|
|
|
* by two different parameters:
|
|
|
|
*
|
2024-04-07 21:21:08 +00:00
|
|
|
* - start_committish is the commit-ish, in repository r, that determines
|
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 00:04:45 +00:00
|
|
|
* which commits the branches will point to. The superproject branch
|
2024-04-07 21:21:08 +00:00
|
|
|
* will point to the commit of start_committish and the submodule
|
|
|
|
* branches will point to the gitlink commit oids in start_committish's
|
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 00:04:45 +00:00
|
|
|
* tree.
|
|
|
|
*
|
|
|
|
* - tracking_name is the name of the ref, in repository r, that will be
|
|
|
|
* used to set up tracking information. This value is propagated to
|
|
|
|
* all submodules, which will evaluate the ref using their own ref
|
2024-04-07 21:21:08 +00:00
|
|
|
* stores. If NULL, this defaults to start_committish.
|
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 00:04:45 +00:00
|
|
|
*
|
2024-04-07 21:21:08 +00:00
|
|
|
* When this function is called on the superproject, start_committish
|
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 00:04:45 +00:00
|
|
|
* can be any user-provided ref and tracking_name can be NULL (similar
|
|
|
|
* to create_branches()). But when recursing through submodules,
|
2024-04-07 21:21:08 +00:00
|
|
|
* start_committish is the plain gitlink commit oid. Since the oid cannot
|
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 00:04:45 +00:00
|
|
|
* be used for tracking information, tracking_name is propagated and
|
|
|
|
* used for tracking instead.
|
|
|
|
*/
|
|
|
|
void create_branches_recursively(struct repository *r, const char *name,
|
2024-04-07 21:21:08 +00:00
|
|
|
const char *start_committish,
|
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 00:04:45 +00:00
|
|
|
const char *tracking_name, int force,
|
|
|
|
int reflog, int quiet, enum branch_track track,
|
|
|
|
int dry_run);
|
2022-06-14 19:27:29 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If the branch at 'refname' is currently checked out in a worktree,
|
|
|
|
* then return the path to that worktree.
|
|
|
|
*/
|
|
|
|
const char *branch_checked_out(const char *refname);
|
|
|
|
|
2011-08-20 21:49:48 +00:00
|
|
|
/*
|
2017-10-13 04:45:40 +00:00
|
|
|
* Check if 'name' can be a valid name for a branch; die otherwise.
|
|
|
|
* Return 1 if the named branch already exists; return 0 otherwise.
|
|
|
|
* Fill ref with the full refname for the branch.
|
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
int validate_branchname(const char *name, struct strbuf *ref);
|
2017-10-13 04:45:40 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Check if a branch 'name' can be created as a new branch; die otherwise.
|
|
|
|
* 'force' can be used when it is OK for the named branch already exists.
|
|
|
|
* Return 1 if the named branch already exists; return 0 otherwise.
|
|
|
|
* Fill ref with the full refname for the branch.
|
2011-08-20 21:49:48 +00:00
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
int validate_new_branchname(const char *name, struct strbuf *ref, int force);
|
2011-08-20 21:49:48 +00:00
|
|
|
|
2019-05-09 10:10:27 +00:00
|
|
|
/*
|
|
|
|
* Remove information about the merge state on the current
|
|
|
|
* branch. (E.g., MERGE_HEAD)
|
|
|
|
*/
|
|
|
|
void remove_merge_branch_state(struct repository *r);
|
|
|
|
|
2008-02-07 16:40:16 +00:00
|
|
|
/*
|
|
|
|
* Remove information about the state of working on the current
|
|
|
|
* branch. (E.g., MERGE_HEAD)
|
|
|
|
*/
|
2019-03-29 10:38:59 +00:00
|
|
|
void remove_branch_state(struct repository *r, int verbose);
|
2008-02-07 16:40:16 +00:00
|
|
|
|
2009-03-04 06:29:55 +00:00
|
|
|
/*
|
2010-11-02 15:31:25 +00:00
|
|
|
* Configure local branch "local" as downstream to branch "remote"
|
|
|
|
* from remote "origin". Used by git branch --set-upstream.
|
2016-02-22 11:23:23 +00:00
|
|
|
* Returns 0 on success.
|
2009-03-04 06:29:55 +00:00
|
|
|
*/
|
|
|
|
#define BRANCH_CONFIG_VERBOSE 01
|
2019-04-29 08:28:14 +00:00
|
|
|
int install_branch_config(int flag, const char *local, const char *origin, const char *remote);
|
2009-03-04 06:29:55 +00:00
|
|
|
|
2011-09-22 03:19:38 +00:00
|
|
|
/*
|
|
|
|
* Read branch description
|
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
int read_branch_desc(struct strbuf *, const char *branch_name);
|
2011-09-22 03:19:38 +00:00
|
|
|
|
2015-07-17 23:00:04 +00:00
|
|
|
/*
|
|
|
|
* Check if a branch is checked out in the main worktree or any linked
|
|
|
|
* worktree and die (with a message describing its checkout location) if
|
|
|
|
* it is.
|
|
|
|
*/
|
2019-04-29 08:28:14 +00:00
|
|
|
void die_if_checked_out(const char *branch, int ignore_current_worktree);
|
2015-07-17 23:00:04 +00:00
|
|
|
|
2008-02-07 16:40:08 +00:00
|
|
|
#endif
|