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
|
|
|
|
|
|
2014-02-28 14:43:33 +08:00
|
|
|
#include "git-compat-util.h"
|
2023-04-11 11:00:39 +08:00
|
|
|
#include "advice.h"
|
2017-06-15 02:07:36 +08:00
|
|
|
#include "config.h"
|
2008-02-08 00:40:08 +08:00
|
|
|
#include "branch.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-04-11 15:41:49 +08:00
|
|
|
#include "object-name.h"
|
2023-05-16 14:33:59 +08:00
|
|
|
#include "path.h"
|
2008-02-08 00:40:08 +08:00
|
|
|
#include "refs.h"
|
2018-05-17 06:57:48 +08:00
|
|
|
#include "refspec.h"
|
2008-02-08 00:40:08 +08:00
|
|
|
#include "remote.h"
|
2023-04-23 04:17:20 +08:00
|
|
|
#include "repository.h"
|
2019-04-16 18:18:41 +08:00
|
|
|
#include "sequencer.h"
|
2008-02-08 00:40:08 +08:00
|
|
|
#include "commit.h"
|
2015-10-02 19:55:31 +08:00
|
|
|
#include "worktree.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 "submodule-config.h"
|
|
|
|
|
#include "run-command.h"
|
2022-06-15 03:27:29 +08:00
|
|
|
#include "strmap.h"
|
2008-02-08 00:40:08 +08:00
|
|
|
|
|
|
|
|
struct tracking {
|
2018-05-17 06:57:49 +08:00
|
|
|
struct refspec_item spec;
|
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 11:30:23 +08:00
|
|
|
struct string_list *srcs;
|
2008-02-08 00:40:08 +08:00
|
|
|
const char *remote;
|
|
|
|
|
int matches;
|
|
|
|
|
};
|
|
|
|
|
|
2022-04-01 14:05:13 +08:00
|
|
|
struct find_tracked_branch_cb {
|
|
|
|
|
struct tracking *tracking;
|
|
|
|
|
struct string_list ambiguous_remotes;
|
|
|
|
|
};
|
|
|
|
|
|
2008-02-08 00:40:08 +08:00
|
|
|
static int find_tracked_branch(struct remote *remote, void *priv)
|
|
|
|
|
{
|
2022-04-01 14:05:13 +08:00
|
|
|
struct find_tracked_branch_cb *ftb = priv;
|
|
|
|
|
struct tracking *tracking = ftb->tracking;
|
2008-02-08 00:40:08 +08:00
|
|
|
|
|
|
|
|
if (!remote_find_tracking(remote, &tracking->spec)) {
|
2022-04-01 14:05:13 +08:00
|
|
|
switch (++tracking->matches) {
|
|
|
|
|
case 1:
|
branch: fix a leak in setup_tracking
The commit d3115660b4 (branch: add flags and config to inherit tracking,
2021-12-20) replaced in "struct tracking", the member "char *src" by a
new "struct string_list *srcs".
This caused a modification in find_tracked_branch(). The string
returned by remote_find_tracking(), previously assigned to "src", is now
added to the string_list "srcs".
That string_list is initialized with STRING_LIST_INIT_DUP, which means
that what is added is not the given string, but a duplicate. Therefore,
the string returned by remote_find_tracking() is leaked.
The leak can be reviewed with:
$ git branch foo
$ git remote add local .
$ git fetch local
$ git branch --track bar local/foo
Direct leak of 24 byte(s) in 1 object(s) allocated from:
... in xrealloc wrapper.c
... in strbuf_grow strbuf.c
... in strbuf_add strbuf.c
... in match_name_with_pattern remote.c
... in query_refspecs remote.c
... in remote_find_tracking remote.c
... in find_tracked_branch branch.c
... in for_each_remote remote.c
... in setup_tracking branch.c
... in create_branch branch.c
... in cmd_branch builtin/branch.c
... in run_builtin git.c
Let's fix the leak, using the "_nodup" API to add to the string_list.
This way, the string itself will be added instead of being strdup()'d.
And when the string_list is cleared, the string will be freed.
Signed-off-by: Rubén Justo <rjusto@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-12 02:50:36 +08:00
|
|
|
string_list_append_nodup(tracking->srcs, tracking->spec.src);
|
2008-02-08 00:40:08 +08:00
|
|
|
tracking->remote = remote->name;
|
2022-04-01 14:05:13 +08:00
|
|
|
break;
|
|
|
|
|
case 2:
|
|
|
|
|
/* there are at least two remotes; backfill the first one */
|
|
|
|
|
string_list_append(&ftb->ambiguous_remotes, tracking->remote);
|
|
|
|
|
/* fall through */
|
|
|
|
|
default:
|
|
|
|
|
string_list_append(&ftb->ambiguous_remotes, remote->name);
|
2008-02-08 00:40:08 +08:00
|
|
|
free(tracking->spec.src);
|
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 11:30:23 +08:00
|
|
|
string_list_clear(tracking->srcs, 0);
|
2022-04-01 14:05:13 +08:00
|
|
|
break;
|
2008-02-08 00:40:08 +08:00
|
|
|
}
|
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 17:56:44 +08:00
|
|
|
/* remote_find_tracking() searches by src if present */
|
2008-02-08 00:40:08 +08:00
|
|
|
tracking->spec.src = NULL;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2009-03-04 14:29:55 +08:00
|
|
|
static int should_setup_rebase(const char *origin)
|
2008-05-11 06:36:29 +08:00
|
|
|
{
|
|
|
|
|
switch (autorebase) {
|
|
|
|
|
case AUTOREBASE_NEVER:
|
|
|
|
|
return 0;
|
|
|
|
|
case AUTOREBASE_LOCAL:
|
2009-03-04 14:29:55 +08:00
|
|
|
return origin == NULL;
|
2008-05-11 06:36:29 +08:00
|
|
|
case AUTOREBASE_REMOTE:
|
2009-03-04 14:29:55 +08:00
|
|
|
return origin != NULL;
|
2008-05-11 06:36:29 +08:00
|
|
|
case AUTOREBASE_ALWAYS:
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2021-12-21 11:30:22 +08:00
|
|
|
/**
|
|
|
|
|
* Install upstream tracking configuration for a branch; specifically, add
|
|
|
|
|
* `branch.<name>.remote` and `branch.<name>.merge` entries.
|
|
|
|
|
*
|
|
|
|
|
* `flag` contains integer flags for options; currently only
|
|
|
|
|
* BRANCH_CONFIG_VERBOSE is checked.
|
|
|
|
|
*
|
|
|
|
|
* `local` is the name of the branch whose configuration we're installing.
|
|
|
|
|
*
|
|
|
|
|
* `origin` is the name of the remote owning the upstream branches. NULL means
|
|
|
|
|
* the upstream branches are local to this repo.
|
|
|
|
|
*
|
|
|
|
|
* `remotes` is a list of refs that are upstream of local
|
|
|
|
|
*/
|
|
|
|
|
static int install_branch_config_multiple_remotes(int flag, const char *local,
|
|
|
|
|
const char *origin, struct string_list *remotes)
|
2009-03-04 14:29:55 +08:00
|
|
|
{
|
refactor skip_prefix to return a boolean
The skip_prefix() function returns a pointer to the content
past the prefix, or NULL if the prefix was not found. While
this is nice and simple, in practice it makes it hard to use
for two reasons:
1. When you want to conditionally skip or keep the string
as-is, you have to introduce a temporary variable.
For example:
tmp = skip_prefix(buf, "foo");
if (tmp)
buf = tmp;
2. It is verbose to check the outcome in a conditional, as
you need extra parentheses to silence compiler
warnings. For example:
if ((cp = skip_prefix(buf, "foo"))
/* do something with cp */
Both of these make it harder to use for long if-chains, and
we tend to use starts_with() instead. However, the first line
of "do something" is often to then skip forward in buf past
the prefix, either using a magic constant or with an extra
strlen(3) (which is generally computed at compile time, but
means we are repeating ourselves).
This patch refactors skip_prefix() to return a simple boolean,
and to provide the pointer value as an out-parameter. If the
prefix is not found, the out-parameter is untouched. This
lets you write:
if (skip_prefix(arg, "foo ", &arg))
do_foo(arg);
else if (skip_prefix(arg, "bar ", &arg))
do_bar(arg);
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-19 03:44:19 +08:00
|
|
|
const char *shortname = NULL;
|
2009-03-04 14:29:55 +08:00
|
|
|
struct strbuf key = STRBUF_INIT;
|
2021-12-21 11:30:22 +08:00
|
|
|
struct string_list_item *item;
|
2009-03-04 14:29:55 +08:00
|
|
|
int rebasing = should_setup_rebase(origin);
|
|
|
|
|
|
2021-12-21 11:30:22 +08:00
|
|
|
if (!remotes->nr)
|
|
|
|
|
BUG("must provide at least one remote for branch config");
|
|
|
|
|
if (rebasing && remotes->nr > 1)
|
|
|
|
|
die(_("cannot inherit upstream tracking configuration of "
|
|
|
|
|
"multiple refs when rebasing is requested"));
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If the new branch is trying to track itself, something has gone
|
|
|
|
|
* wrong. Warn the user and don't proceed any further.
|
|
|
|
|
*/
|
|
|
|
|
if (!origin)
|
|
|
|
|
for_each_string_list_item(item, remotes)
|
|
|
|
|
if (skip_prefix(item->string, "refs/heads/", &shortname)
|
|
|
|
|
&& !strcmp(local, shortname)) {
|
2022-01-11 03:52:54 +08:00
|
|
|
warning(_("not setting branch '%s' as its own upstream"),
|
2021-12-21 11:30:22 +08:00
|
|
|
local);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2010-01-19 04:44:12 +08:00
|
|
|
|
2009-03-04 14:29:55 +08:00
|
|
|
strbuf_addf(&key, "branch.%s.remote", local);
|
2016-02-22 19:23:35 +08:00
|
|
|
if (git_config_set_gently(key.buf, origin ? origin : ".") < 0)
|
2016-02-22 19:23:23 +08:00
|
|
|
goto out_err;
|
2009-03-04 14:29:55 +08:00
|
|
|
|
|
|
|
|
strbuf_reset(&key);
|
|
|
|
|
strbuf_addf(&key, "branch.%s.merge", local);
|
2021-12-21 11:30:22 +08:00
|
|
|
/*
|
|
|
|
|
* We want to overwrite any existing config with all the branches in
|
|
|
|
|
* "remotes". Override any existing config, then write our branches. If
|
|
|
|
|
* more than one is provided, use CONFIG_REGEX_NONE to preserve what
|
|
|
|
|
* we've written so far.
|
|
|
|
|
*/
|
|
|
|
|
if (git_config_set_gently(key.buf, NULL) < 0)
|
2016-02-22 19:23:23 +08:00
|
|
|
goto out_err;
|
2021-12-21 11:30:22 +08:00
|
|
|
for_each_string_list_item(item, remotes)
|
|
|
|
|
if (git_config_set_multivar_gently(key.buf, item->string, CONFIG_REGEX_NONE, 0) < 0)
|
|
|
|
|
goto out_err;
|
2009-03-04 14:29:55 +08:00
|
|
|
|
|
|
|
|
if (rebasing) {
|
|
|
|
|
strbuf_reset(&key);
|
|
|
|
|
strbuf_addf(&key, "branch.%s.rebase", local);
|
2016-02-22 19:23:35 +08:00
|
|
|
if (git_config_set_gently(key.buf, "true") < 0)
|
2016-02-22 19:23:23 +08:00
|
|
|
goto out_err;
|
2009-03-04 14:29:55 +08:00
|
|
|
}
|
2012-06-07 20:05:10 +08:00
|
|
|
strbuf_release(&key);
|
2009-03-04 14:29:55 +08:00
|
|
|
|
2009-03-10 16:20:42 +08:00
|
|
|
if (flag & BRANCH_CONFIG_VERBOSE) {
|
2021-12-21 11:30:22 +08:00
|
|
|
struct strbuf tmp_ref_name = STRBUF_INIT;
|
|
|
|
|
struct string_list friendly_ref_names = STRING_LIST_INIT_DUP;
|
|
|
|
|
|
|
|
|
|
for_each_string_list_item(item, remotes) {
|
|
|
|
|
shortname = item->string;
|
|
|
|
|
skip_prefix(shortname, "refs/heads/", &shortname);
|
|
|
|
|
if (origin) {
|
|
|
|
|
strbuf_addf(&tmp_ref_name, "%s/%s",
|
|
|
|
|
origin, shortname);
|
|
|
|
|
string_list_append_nodup(
|
|
|
|
|
&friendly_ref_names,
|
|
|
|
|
strbuf_detach(&tmp_ref_name, NULL));
|
|
|
|
|
} else {
|
|
|
|
|
string_list_append(
|
|
|
|
|
&friendly_ref_names, shortname);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (remotes->nr == 1) {
|
|
|
|
|
/*
|
|
|
|
|
* Rebasing is only allowed in the case of a single
|
|
|
|
|
* upstream branch.
|
|
|
|
|
*/
|
|
|
|
|
printf_ln(rebasing ?
|
|
|
|
|
_("branch '%s' set up to track '%s' by rebasing.") :
|
|
|
|
|
_("branch '%s' set up to track '%s'."),
|
|
|
|
|
local, friendly_ref_names.items[0].string);
|
2014-03-10 13:32:01 +08:00
|
|
|
} else {
|
2021-12-21 11:30:22 +08:00
|
|
|
printf_ln(_("branch '%s' set up to track:"), local);
|
|
|
|
|
for_each_string_list_item(item, &friendly_ref_names)
|
|
|
|
|
printf_ln(" %s", item->string);
|
2014-03-10 13:32:01 +08:00
|
|
|
}
|
2021-12-21 11:30:22 +08:00
|
|
|
|
|
|
|
|
string_list_clear(&friendly_ref_names, 0);
|
2009-03-10 16:20:42 +08:00
|
|
|
}
|
2016-02-22 19:23:23 +08:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
out_err:
|
|
|
|
|
strbuf_release(&key);
|
2021-12-02 06:15:42 +08:00
|
|
|
error(_("unable to write upstream branch configuration"));
|
2016-02-22 19:23:23 +08:00
|
|
|
|
2021-12-21 11:30:22 +08:00
|
|
|
advise(_("\nAfter fixing the error cause you may try to fix up\n"
|
|
|
|
|
"the remote tracking information by invoking:"));
|
|
|
|
|
if (remotes->nr == 1)
|
|
|
|
|
advise(" git branch --set-upstream-to=%s%s%s",
|
|
|
|
|
origin ? origin : "",
|
|
|
|
|
origin ? "/" : "",
|
|
|
|
|
remotes->items[0].string);
|
|
|
|
|
else {
|
|
|
|
|
advise(" git config --add branch.\"%s\".remote %s",
|
|
|
|
|
local, origin ? origin : ".");
|
|
|
|
|
for_each_string_list_item(item, remotes)
|
|
|
|
|
advise(" git config --add branch.\"%s\".merge %s",
|
|
|
|
|
local, item->string);
|
|
|
|
|
}
|
2016-02-22 19:23:23 +08:00
|
|
|
|
|
|
|
|
return -1;
|
2009-03-04 14:29:55 +08:00
|
|
|
}
|
|
|
|
|
|
2021-12-21 11:30:22 +08:00
|
|
|
int install_branch_config(int flag, const char *local, const char *origin,
|
|
|
|
|
const char *remote)
|
|
|
|
|
{
|
|
|
|
|
int ret;
|
|
|
|
|
struct string_list remotes = STRING_LIST_INIT_DUP;
|
|
|
|
|
|
|
|
|
|
string_list_append(&remotes, remote);
|
|
|
|
|
ret = install_branch_config_multiple_remotes(flag, local, origin, &remotes);
|
|
|
|
|
string_list_clear(&remotes, 0);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
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 11:30:23 +08:00
|
|
|
static int inherit_tracking(struct tracking *tracking, const char *orig_ref)
|
|
|
|
|
{
|
|
|
|
|
const char *bare_ref;
|
|
|
|
|
struct branch *branch;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
bare_ref = orig_ref;
|
|
|
|
|
skip_prefix(orig_ref, "refs/heads/", &bare_ref);
|
|
|
|
|
|
|
|
|
|
branch = branch_get(bare_ref);
|
|
|
|
|
if (!branch->remote_name) {
|
|
|
|
|
warning(_("asked to inherit tracking from '%s', but no remote is set"),
|
|
|
|
|
bare_ref);
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (branch->merge_nr < 1 || !branch->merge_name || !branch->merge_name[0]) {
|
|
|
|
|
warning(_("asked to inherit tracking from '%s', but no merge configuration is set"),
|
|
|
|
|
bare_ref);
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
2023-06-12 02:50:16 +08:00
|
|
|
tracking->remote = branch->remote_name;
|
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 11:30:23 +08:00
|
|
|
for (i = 0; i < branch->merge_nr; i++)
|
|
|
|
|
string_list_append(tracking->srcs, branch->merge_name[i]);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2008-02-08 00:40:08 +08:00
|
|
|
/*
|
2022-01-29 08:04:41 +08:00
|
|
|
* Used internally to set the branch.<new_ref>.{remote,merge} config
|
|
|
|
|
* settings so that branch 'new_ref' tracks 'orig_ref'. Unlike
|
|
|
|
|
* dwim_and_setup_tracking(), this does not do DWIM, i.e. "origin/main"
|
|
|
|
|
* will not be expanded to "refs/remotes/origin/main", so it is not safe
|
|
|
|
|
* for 'orig_ref' to be raw user input.
|
2008-02-08 00:40:08 +08:00
|
|
|
*/
|
2016-02-22 19:23:23 +08:00
|
|
|
static void setup_tracking(const char *new_ref, const char *orig_ref,
|
|
|
|
|
enum branch_track track, int quiet)
|
2008-02-08 00:40:08 +08:00
|
|
|
{
|
|
|
|
|
struct tracking tracking;
|
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 11:30:23 +08:00
|
|
|
struct string_list tracking_srcs = STRING_LIST_INIT_DUP;
|
2012-03-27 07:51:01 +08:00
|
|
|
int config_flags = quiet ? 0 : BRANCH_CONFIG_VERBOSE;
|
2022-04-01 14:05:13 +08:00
|
|
|
struct find_tracked_branch_cb ftb_cb = {
|
|
|
|
|
.tracking = &tracking,
|
|
|
|
|
.ambiguous_remotes = STRING_LIST_INIT_DUP,
|
|
|
|
|
};
|
2008-02-08 00:40:08 +08:00
|
|
|
|
2022-03-30 04:01:16 +08:00
|
|
|
if (!track)
|
|
|
|
|
BUG("asked to set up tracking, but tracking is disallowed");
|
|
|
|
|
|
2008-02-08 00:40:08 +08:00
|
|
|
memset(&tracking, 0, sizeof(tracking));
|
|
|
|
|
tracking.spec.dst = (char *)orig_ref;
|
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 11:30:23 +08:00
|
|
|
tracking.srcs = &tracking_srcs;
|
|
|
|
|
if (track != BRANCH_TRACK_INHERIT)
|
2022-04-01 14:05:13 +08:00
|
|
|
for_each_remote(find_tracked_branch, &ftb_cb);
|
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 11:30:23 +08:00
|
|
|
else if (inherit_tracking(&tracking, orig_ref))
|
2022-01-29 08:04:46 +08:00
|
|
|
goto cleanup;
|
2008-02-08 00:40:08 +08:00
|
|
|
|
2008-02-20 00:24:37 +08:00
|
|
|
if (!tracking.matches)
|
|
|
|
|
switch (track) {
|
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 17:56:44 +08:00
|
|
|
/* If ref is not remote, still use local */
|
2008-02-20 00:24:37 +08:00
|
|
|
case BRANCH_TRACK_ALWAYS:
|
|
|
|
|
case BRANCH_TRACK_EXPLICIT:
|
2010-01-19 04:44:11 +08:00
|
|
|
case BRANCH_TRACK_OVERRIDE:
|
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 17:56:44 +08:00
|
|
|
/* Remote matches not evaluated */
|
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 11:30:23 +08:00
|
|
|
case BRANCH_TRACK_INHERIT:
|
2008-02-20 00:24:37 +08:00
|
|
|
break;
|
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 17:56:44 +08:00
|
|
|
/* Otherwise, if no remote don't track */
|
2008-02-20 00:24:37 +08:00
|
|
|
default:
|
2022-01-29 08:04:46 +08:00
|
|
|
goto cleanup;
|
2008-02-20 00:24:37 +08:00
|
|
|
}
|
|
|
|
|
|
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 17:56:44 +08:00
|
|
|
/*
|
|
|
|
|
* This check does not apply to BRANCH_TRACK_INHERIT;
|
|
|
|
|
* that supports multiple entries in tracking_srcs but
|
|
|
|
|
* leaves tracking.matches at 0.
|
|
|
|
|
*/
|
2022-04-01 14:05:13 +08:00
|
|
|
if (tracking.matches > 1) {
|
|
|
|
|
int status = die_message(_("not tracking: ambiguous information for ref '%s'"),
|
|
|
|
|
orig_ref);
|
|
|
|
|
if (advice_enabled(ADVICE_AMBIGUOUS_FETCH_REFSPEC)) {
|
|
|
|
|
struct strbuf remotes_advice = STRBUF_INIT;
|
|
|
|
|
struct string_list_item *item;
|
|
|
|
|
|
|
|
|
|
for_each_string_list_item(item, &ftb_cb.ambiguous_remotes)
|
|
|
|
|
/*
|
|
|
|
|
* TRANSLATORS: This is a line listing a remote with duplicate
|
|
|
|
|
* refspecs in the advice message below. For RTL languages you'll
|
|
|
|
|
* probably want to swap the "%s" and leading " " space around.
|
|
|
|
|
*/
|
|
|
|
|
strbuf_addf(&remotes_advice, _(" %s\n"), item->string);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* TRANSLATORS: The second argument is a \n-delimited list of
|
|
|
|
|
* duplicate refspecs, composed above.
|
|
|
|
|
*/
|
|
|
|
|
advise(_("There are multiple remotes whose fetch refspecs map to the remote\n"
|
|
|
|
|
"tracking ref '%s':\n"
|
|
|
|
|
"%s"
|
|
|
|
|
"\n"
|
|
|
|
|
"This is typically a configuration error.\n"
|
|
|
|
|
"\n"
|
|
|
|
|
"To support setting up tracking branches, ensure that\n"
|
|
|
|
|
"different remotes' fetch refspecs map into different\n"
|
|
|
|
|
"tracking namespaces."), orig_ref,
|
|
|
|
|
remotes_advice.buf);
|
|
|
|
|
strbuf_release(&remotes_advice);
|
|
|
|
|
}
|
|
|
|
|
exit(status);
|
|
|
|
|
}
|
2008-02-08 00:40:08 +08:00
|
|
|
|
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 17:56:44 +08:00
|
|
|
if (track == BRANCH_TRACK_SIMPLE) {
|
|
|
|
|
/*
|
|
|
|
|
* Only track if remote branch name matches.
|
|
|
|
|
* Reaching into items[0].string is safe because
|
|
|
|
|
* we know there is at least one and not more than
|
|
|
|
|
* one entry (because only BRANCH_TRACK_INHERIT can
|
|
|
|
|
* produce more than one entry).
|
|
|
|
|
*/
|
|
|
|
|
const char *tracked_branch;
|
|
|
|
|
if (!skip_prefix(tracking.srcs->items[0].string,
|
|
|
|
|
"refs/heads/", &tracked_branch) ||
|
|
|
|
|
strcmp(tracked_branch, new_ref))
|
2023-06-17 14:41:08 +08:00
|
|
|
goto cleanup;
|
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 17:56:44 +08:00
|
|
|
}
|
|
|
|
|
|
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 11:30:23 +08:00
|
|
|
if (tracking.srcs->nr < 1)
|
|
|
|
|
string_list_append(tracking.srcs, orig_ref);
|
|
|
|
|
if (install_branch_config_multiple_remotes(config_flags, new_ref,
|
|
|
|
|
tracking.remote, tracking.srcs) < 0)
|
2022-03-30 04:01:19 +08:00
|
|
|
exit(1);
|
2008-02-08 00:40:08 +08:00
|
|
|
|
2022-01-29 08:04:46 +08:00
|
|
|
cleanup:
|
|
|
|
|
string_list_clear(&tracking_srcs, 0);
|
2022-04-01 14:05:13 +08:00
|
|
|
string_list_clear(&ftb_cb.ambiguous_remotes, 0);
|
2008-02-08 00:40:08 +08:00
|
|
|
}
|
|
|
|
|
|
2011-09-22 11:19:38 +08:00
|
|
|
int read_branch_desc(struct strbuf *buf, const char *branch_name)
|
|
|
|
|
{
|
2014-08-08 01:56:42 +08:00
|
|
|
char *v = NULL;
|
2011-09-22 11:19:38 +08:00
|
|
|
struct strbuf name = STRBUF_INIT;
|
|
|
|
|
strbuf_addf(&name, "branch.%s.description", branch_name);
|
2014-08-08 01:56:42 +08:00
|
|
|
if (git_config_get_string(name.buf, &v)) {
|
|
|
|
|
strbuf_release(&name);
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
strbuf_addstr(buf, v);
|
|
|
|
|
free(v);
|
2011-09-22 11:19:38 +08:00
|
|
|
strbuf_release(&name);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2017-10-13 12:45:40 +08: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.
|
|
|
|
|
*/
|
|
|
|
|
int validate_branchname(const char *name, struct strbuf *ref)
|
2011-08-21 05:49:48 +08:00
|
|
|
{
|
2024-03-06 04:29:43 +08:00
|
|
|
if (strbuf_check_branch_ref(ref, name)) {
|
|
|
|
|
int code = die_message(_("'%s' is not a valid branch name"), name);
|
|
|
|
|
advise_if_enabled(ADVICE_REF_SYNTAX,
|
|
|
|
|
_("See `man git check-ref-format`"));
|
|
|
|
|
exit(code);
|
|
|
|
|
}
|
2011-08-21 05:49:48 +08:00
|
|
|
|
2024-05-07 15:11:53 +08:00
|
|
|
return refs_ref_exists(get_main_ref_store(the_repository), ref->buf);
|
2017-10-13 12:45:40 +08:00
|
|
|
}
|
2011-08-21 05:49:48 +08:00
|
|
|
|
2022-06-15 03:27:29 +08:00
|
|
|
static int initialized_checked_out_branches;
|
|
|
|
|
static struct strmap current_checked_out_branches = STRMAP_INIT;
|
|
|
|
|
|
|
|
|
|
static void prepare_checked_out_branches(void)
|
|
|
|
|
{
|
|
|
|
|
int i = 0;
|
|
|
|
|
struct worktree **worktrees;
|
|
|
|
|
|
|
|
|
|
if (initialized_checked_out_branches)
|
|
|
|
|
return;
|
|
|
|
|
initialized_checked_out_branches = 1;
|
|
|
|
|
|
|
|
|
|
worktrees = get_worktrees();
|
|
|
|
|
|
|
|
|
|
while (worktrees[i]) {
|
2022-06-15 03:27:33 +08:00
|
|
|
char *old;
|
2022-06-15 03:27:30 +08:00
|
|
|
struct wt_status_state state = { 0 };
|
2022-06-15 03:27:29 +08:00
|
|
|
struct worktree *wt = worktrees[i++];
|
2022-07-20 02:33:35 +08:00
|
|
|
struct string_list update_refs = STRING_LIST_INIT_DUP;
|
2022-06-15 03:27:29 +08:00
|
|
|
|
|
|
|
|
if (wt->is_bare)
|
|
|
|
|
continue;
|
|
|
|
|
|
2022-06-15 03:27:33 +08:00
|
|
|
if (wt->head_ref) {
|
|
|
|
|
old = strmap_put(¤t_checked_out_branches,
|
|
|
|
|
wt->head_ref,
|
|
|
|
|
xstrdup(wt->path));
|
|
|
|
|
free(old);
|
|
|
|
|
}
|
2022-06-15 03:27:30 +08:00
|
|
|
|
|
|
|
|
if (wt_status_check_rebase(wt, &state) &&
|
|
|
|
|
(state.rebase_in_progress || state.rebase_interactive_in_progress) &&
|
|
|
|
|
state.branch) {
|
|
|
|
|
struct strbuf ref = STRBUF_INIT;
|
|
|
|
|
strbuf_addf(&ref, "refs/heads/%s", state.branch);
|
2022-06-15 03:27:33 +08:00
|
|
|
old = strmap_put(¤t_checked_out_branches,
|
|
|
|
|
ref.buf,
|
|
|
|
|
xstrdup(wt->path));
|
|
|
|
|
free(old);
|
2022-06-15 03:27:30 +08:00
|
|
|
strbuf_release(&ref);
|
|
|
|
|
}
|
|
|
|
|
wt_status_state_free_buffers(&state);
|
|
|
|
|
|
|
|
|
|
if (wt_status_check_bisect(wt, &state) &&
|
status: fix branch shown when not only bisecting
In 83c750acde (wt-status.*: better advice for git status added,
2012-06-05), git-status received new informative messages to describe
the ongoing work in a worktree.
These messages were enhanced in 0722c805d6 (status: show the branch name
if possible in in-progress info, 2013-02-03), to show, if possible, the
branch where the operation was initiated.
Since then, we show incorrect information when several operations are in
progress and one of them is bisect:
$ git checkout -b foo
$ GIT_SEQUENCE_EDITOR='echo break >' git rebase -i HEAD~
$ git checkout -b bar
$ git bisect start
$ git status
...
You are currently editing a commit while rebasing branch 'bar' on '...'.
You are currently bisecting, started from branch 'bar'.
...
Note that we erroneously say "while rebasing branch 'bar'" when we
should be referring to "foo".
This must have gone unnoticed for so long because it must be unusual to
start a bisection while another operation is in progress. And even less
usual to involve different branches.
It caught my attention reviewing a leak introduced in 8b87cfd000
(wt-status: move strbuf into read_and_strip_branch(), 2013-03-16).
A simple change to deal with this situation can be to record in struct
wt_status_state, the branch where the bisect starts separately from the
branch related to other operations.
Let's do it and so we'll be able to display correct information and
we'll avoid the leak as well.
Signed-off-by: Rubén Justo <rjusto@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-10 04:12:47 +08:00
|
|
|
state.bisecting_from) {
|
2022-06-15 03:27:30 +08:00
|
|
|
struct strbuf ref = STRBUF_INIT;
|
status: fix branch shown when not only bisecting
In 83c750acde (wt-status.*: better advice for git status added,
2012-06-05), git-status received new informative messages to describe
the ongoing work in a worktree.
These messages were enhanced in 0722c805d6 (status: show the branch name
if possible in in-progress info, 2013-02-03), to show, if possible, the
branch where the operation was initiated.
Since then, we show incorrect information when several operations are in
progress and one of them is bisect:
$ git checkout -b foo
$ GIT_SEQUENCE_EDITOR='echo break >' git rebase -i HEAD~
$ git checkout -b bar
$ git bisect start
$ git status
...
You are currently editing a commit while rebasing branch 'bar' on '...'.
You are currently bisecting, started from branch 'bar'.
...
Note that we erroneously say "while rebasing branch 'bar'" when we
should be referring to "foo".
This must have gone unnoticed for so long because it must be unusual to
start a bisection while another operation is in progress. And even less
usual to involve different branches.
It caught my attention reviewing a leak introduced in 8b87cfd000
(wt-status: move strbuf into read_and_strip_branch(), 2013-03-16).
A simple change to deal with this situation can be to record in struct
wt_status_state, the branch where the bisect starts separately from the
branch related to other operations.
Let's do it and so we'll be able to display correct information and
we'll avoid the leak as well.
Signed-off-by: Rubén Justo <rjusto@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-10 04:12:47 +08:00
|
|
|
strbuf_addf(&ref, "refs/heads/%s", state.bisecting_from);
|
2022-06-15 03:27:33 +08:00
|
|
|
old = strmap_put(¤t_checked_out_branches,
|
|
|
|
|
ref.buf,
|
|
|
|
|
xstrdup(wt->path));
|
|
|
|
|
free(old);
|
2022-06-15 03:27:30 +08:00
|
|
|
strbuf_release(&ref);
|
|
|
|
|
}
|
|
|
|
|
wt_status_state_free_buffers(&state);
|
2022-07-20 02:33:35 +08:00
|
|
|
|
|
|
|
|
if (!sequencer_get_update_refs_state(get_worktree_git_dir(wt),
|
|
|
|
|
&update_refs)) {
|
|
|
|
|
struct string_list_item *item;
|
|
|
|
|
for_each_string_list_item(item, &update_refs) {
|
|
|
|
|
old = strmap_put(¤t_checked_out_branches,
|
|
|
|
|
item->string,
|
|
|
|
|
xstrdup(wt->path));
|
|
|
|
|
free(old);
|
|
|
|
|
}
|
|
|
|
|
string_list_clear(&update_refs, 1);
|
|
|
|
|
}
|
2022-06-15 03:27:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
free_worktrees(worktrees);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const char *branch_checked_out(const char *refname)
|
|
|
|
|
{
|
|
|
|
|
prepare_checked_out_branches();
|
|
|
|
|
return strmap_get(¤t_checked_out_branches, refname);
|
|
|
|
|
}
|
|
|
|
|
|
2017-10-13 12:45:40 +08: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.
|
|
|
|
|
*/
|
|
|
|
|
int validate_new_branchname(const char *name, struct strbuf *ref, int force)
|
|
|
|
|
{
|
2022-06-15 03:27:30 +08:00
|
|
|
const char *path;
|
2017-10-13 12:45:40 +08:00
|
|
|
if (!validate_branchname(name, ref))
|
2011-08-21 05:49:48 +08:00
|
|
|
return 0;
|
|
|
|
|
|
2017-10-13 11:57:02 +08:00
|
|
|
if (!force)
|
2021-12-02 06:15:42 +08:00
|
|
|
die(_("a branch named '%s' already exists"),
|
2017-10-13 11:57:02 +08:00
|
|
|
ref->buf + strlen("refs/heads/"));
|
|
|
|
|
|
2022-06-15 03:27:30 +08:00
|
|
|
if ((path = branch_checked_out(ref->buf)))
|
2022-01-11 20:36:27 +08:00
|
|
|
die(_("cannot force update the branch '%s' "
|
branch: update the message to refuse touching a branch in-use
The "git branch -f" command can refuse to force-update a branch that
is used by another worktree. The original rationale for this
behaviour was that updating a branch that is checked out in another
worktree, without making a matching change to the index and the
working tree files in that worktree, will lead to a very confused
user. "git diff HEAD" will no longer give a useful patch, because
HEAD is a commit unrelated to what the index and the working tree in
the worktree were based on, for example.
These days, the same mechanism also protects branches that are being
rebased or bisected, and the same machanism is expected to be the
right place to add more checks, when we decide to protect branches
undergoing other kinds of operations. We however forgot to rethink
the messaging, which originally said that we are refusing to touch
the branch because it is "checked out" elsewhere, when d2ba271a
(branch: check for bisects and rebases, 2022-06-14) started to
protect branches that are being rebased or bisected.
The spirit of the check has always been that we do not want to
disrupt the use of the same branch in other worktrees. Let's reword
the message slightly to say that the branch is "used by" another
worktree, instead of "checked out".
We could teach the branch.c:prepare_checked_out_branches() function
to remember why it decided that a particular branch needs protecting
(i.e. was it because it was checked out? being bisected? something
else?) in addition to which worktree the branch was in use, and use
that in the error message to say "you cannot force update this
branch because it is being bisected in the worktree X", etc., but it
is dubious that such extra complexity is worth it. The message
already tells which directory the worktree in question is, and it
should be just a "chdir" away for the user to find out what state it
is in, if the user felt curious enough. So let's not go there yet.
Helped-by: Josh Sref <jsoref@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-07-22 05:53:12 +08:00
|
|
|
"used by worktree at '%s'"),
|
2022-06-15 03:27:30 +08:00
|
|
|
ref->buf + strlen("refs/heads/"), path);
|
2011-08-21 05:49:48 +08:00
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
branch.c: Validate tracking branches with refspecs instead of refs/remotes/*
The current code for validating tracking branches (e.g. the argument to
the -t/--track option) hardcodes refs/heads/* and refs/remotes/* as the
potential locations for tracking branches. This works with the refspecs
created by "git clone" or "git remote add", but is suboptimal in other
cases:
- If "refs/remotes/foo/bar" exists without any association to a remote
(i.e. there is no remote named "foo", or no remote with a refspec
that matches "refs/remotes/foo/bar"), then it is impossible to set up
a valid upstream config that tracks it. Currently, the code defaults
to using "refs/remotes/foo/bar" from repo "." as the upstream, which
works, but is probably not what the user had in mind when running
"git branch baz --track foo/bar".
- If the user has tweaked the fetch refspec for a remote to put its
remote-tracking branches outside of refs/remotes/*, e.g. by running
git config remote.foo.fetch "+refs/heads/*:refs/foo_stuff/*"
then the current code will refuse to use its remote-tracking branches
as --track arguments, since they do not match refs/remotes/*.
This patch removes the "refs/remotes/*" requirement for upstream branches,
and replaces it with explicit checking of the refspecs for each remote to
determine whether a given --track argument is a valid remote-tracking
branch. This solves both of the above problems, since the matching refspec
guarantees that there is a both a remote name and a remote branch name
that can be used for the upstream config.
However, this means that refs located within refs/remotes/* without a
corresponding remote/refspec will no longer be usable as upstreams.
The few existing tests which depended on this behavioral quirk has
already been fixed in the preceding patches.
This patch fixes the last remaining test failure in t2024-checkout-dwim.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-22 05:52:05 +08:00
|
|
|
static int check_tracking_branch(struct remote *remote, void *cb_data)
|
|
|
|
|
{
|
|
|
|
|
char *tracking_branch = cb_data;
|
2018-05-17 06:57:49 +08:00
|
|
|
struct refspec_item query;
|
2023-06-12 02:50:27 +08:00
|
|
|
int res;
|
2018-05-17 06:57:49 +08:00
|
|
|
memset(&query, 0, sizeof(struct refspec_item));
|
branch.c: Validate tracking branches with refspecs instead of refs/remotes/*
The current code for validating tracking branches (e.g. the argument to
the -t/--track option) hardcodes refs/heads/* and refs/remotes/* as the
potential locations for tracking branches. This works with the refspecs
created by "git clone" or "git remote add", but is suboptimal in other
cases:
- If "refs/remotes/foo/bar" exists without any association to a remote
(i.e. there is no remote named "foo", or no remote with a refspec
that matches "refs/remotes/foo/bar"), then it is impossible to set up
a valid upstream config that tracks it. Currently, the code defaults
to using "refs/remotes/foo/bar" from repo "." as the upstream, which
works, but is probably not what the user had in mind when running
"git branch baz --track foo/bar".
- If the user has tweaked the fetch refspec for a remote to put its
remote-tracking branches outside of refs/remotes/*, e.g. by running
git config remote.foo.fetch "+refs/heads/*:refs/foo_stuff/*"
then the current code will refuse to use its remote-tracking branches
as --track arguments, since they do not match refs/remotes/*.
This patch removes the "refs/remotes/*" requirement for upstream branches,
and replaces it with explicit checking of the refspecs for each remote to
determine whether a given --track argument is a valid remote-tracking
branch. This solves both of the above problems, since the matching refspec
guarantees that there is a both a remote name and a remote branch name
that can be used for the upstream config.
However, this means that refs located within refs/remotes/* without a
corresponding remote/refspec will no longer be usable as upstreams.
The few existing tests which depended on this behavioral quirk has
already been fixed in the preceding patches.
This patch fixes the last remaining test failure in t2024-checkout-dwim.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-22 05:52:05 +08:00
|
|
|
query.dst = tracking_branch;
|
2023-06-12 02:50:27 +08:00
|
|
|
res = !remote_find_tracking(remote, &query);
|
|
|
|
|
free(query.src);
|
|
|
|
|
return res;
|
branch.c: Validate tracking branches with refspecs instead of refs/remotes/*
The current code for validating tracking branches (e.g. the argument to
the -t/--track option) hardcodes refs/heads/* and refs/remotes/* as the
potential locations for tracking branches. This works with the refspecs
created by "git clone" or "git remote add", but is suboptimal in other
cases:
- If "refs/remotes/foo/bar" exists without any association to a remote
(i.e. there is no remote named "foo", or no remote with a refspec
that matches "refs/remotes/foo/bar"), then it is impossible to set up
a valid upstream config that tracks it. Currently, the code defaults
to using "refs/remotes/foo/bar" from repo "." as the upstream, which
works, but is probably not what the user had in mind when running
"git branch baz --track foo/bar".
- If the user has tweaked the fetch refspec for a remote to put its
remote-tracking branches outside of refs/remotes/*, e.g. by running
git config remote.foo.fetch "+refs/heads/*:refs/foo_stuff/*"
then the current code will refuse to use its remote-tracking branches
as --track arguments, since they do not match refs/remotes/*.
This patch removes the "refs/remotes/*" requirement for upstream branches,
and replaces it with explicit checking of the refspecs for each remote to
determine whether a given --track argument is a valid remote-tracking
branch. This solves both of the above problems, since the matching refspec
guarantees that there is a both a remote name and a remote branch name
that can be used for the upstream config.
However, this means that refs located within refs/remotes/* without a
corresponding remote/refspec will no longer be usable as upstreams.
The few existing tests which depended on this behavioral quirk has
already been fixed in the preceding patches.
This patch fixes the last remaining test failure in t2024-checkout-dwim.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-22 05:52:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int validate_remote_tracking_branch(char *ref)
|
|
|
|
|
{
|
|
|
|
|
return !for_each_remote(check_tracking_branch, ref);
|
|
|
|
|
}
|
|
|
|
|
|
2013-04-03 03:03:55 +08:00
|
|
|
static const char upstream_not_branch[] =
|
2021-12-02 06:15:42 +08:00
|
|
|
N_("cannot set up tracking information; starting point '%s' is not a branch");
|
2013-04-03 03:04:27 +08:00
|
|
|
static const char upstream_missing[] =
|
2013-04-03 03:05:12 +08:00
|
|
|
N_("the requested upstream branch '%s' does not exist");
|
|
|
|
|
static const char upstream_advice[] =
|
|
|
|
|
N_("\n"
|
|
|
|
|
"If you are planning on basing your work on an upstream\n"
|
|
|
|
|
"branch that already exists at the remote, you may need to\n"
|
|
|
|
|
"run \"git fetch\" to retrieve it.\n"
|
|
|
|
|
"\n"
|
|
|
|
|
"If you are planning to push out a new local branch that\n"
|
|
|
|
|
"will track its remote counterpart, you may want to use\n"
|
|
|
|
|
"\"git push -u\" to set the upstream config as you push.");
|
2013-04-03 03:03:55 +08:00
|
|
|
|
2022-01-29 08:04:41 +08:00
|
|
|
/**
|
|
|
|
|
* DWIMs a user-provided ref to determine the starting point for a
|
|
|
|
|
* branch and validates it, where:
|
|
|
|
|
*
|
|
|
|
|
* - r is the repository to validate the branch for
|
|
|
|
|
*
|
|
|
|
|
* - start_name is the ref that we would like to test. This is
|
|
|
|
|
* expanded with DWIM and assigned to out_real_ref.
|
|
|
|
|
*
|
|
|
|
|
* - track is the tracking mode of the new branch. If tracking is
|
|
|
|
|
* explicitly requested, start_name must be a branch (because
|
|
|
|
|
* otherwise start_name cannot be tracked)
|
|
|
|
|
*
|
|
|
|
|
* - out_oid is an out parameter containing the object_id of start_name
|
|
|
|
|
*
|
|
|
|
|
* - out_real_ref is an out parameter containing the full, 'real' form
|
|
|
|
|
* of start_name e.g. refs/heads/main instead of main
|
|
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
static void dwim_branch_start(struct repository *r, const char *start_name,
|
|
|
|
|
enum branch_track track, char **out_real_ref,
|
|
|
|
|
struct object_id *out_oid)
|
2008-02-08 00:40:08 +08:00
|
|
|
{
|
|
|
|
|
struct commit *commit;
|
2017-05-01 10:29:00 +08:00
|
|
|
struct object_id oid;
|
2017-03-29 03:46:36 +08:00
|
|
|
char *real_ref;
|
2010-01-19 04:44:11 +08:00
|
|
|
int explicit_tracking = 0;
|
|
|
|
|
|
|
|
|
|
if (track == BRANCH_TRACK_EXPLICIT || track == BRANCH_TRACK_OVERRIDE)
|
|
|
|
|
explicit_tracking = 1;
|
2008-02-08 00:40:08 +08:00
|
|
|
|
|
|
|
|
real_ref = NULL;
|
libs: use "struct repository *" argument, not "the_repository"
As can easily be seen from grepping in our sources, we had these uses
of "the_repository" in various library code in cases where the
function in question was already getting a "struct repository *"
argument. Let's use that argument instead.
Out of these changes only the changes to "cache-tree.c",
"commit-reach.c", "shallow.c" and "upload-pack.c" would have cleanly
applied before the migration away from the "repo_*()" wrapper macros
in the preceding commits.
The rest aren't new, as we'd previously implicitly refer to
"the_repository", but it's now more obvious that we were doing the
wrong thing all along, and should have used the parameter instead.
The change to change "get_index_format_default(the_repository)" in
"read-cache.c" to use the "r" variable instead should arguably have
been part of [1], or in the subsequent cleanup in [2]. Let's do it
here, as can be seen from the initial code in [3] it's not important
that we use "the_repository" there, but would prefer to always use the
current repository.
This change excludes the "the_repository" use in "upload-pack.c"'s
upload_pack_advertise(), as the in-flight [4] makes that change.
1. ee1f0c242ef (read-cache: add index.skipHash config option,
2023-01-06)
2. 6269f8eaad0 (treewide: always have a valid "index_state.repo"
member, 2023-01-17)
3. 7211b9e7534 (repo-settings: consolidate some config settings,
2019-08-13)
4. <Y/hbUsGPVNAxTdmS@coredump.intra.peff.net>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-28 21:58:58 +08:00
|
|
|
if (repo_get_oid_mb(r, start_name, &oid)) {
|
2013-04-03 03:05:12 +08:00
|
|
|
if (explicit_tracking) {
|
2022-04-01 06:41:18 +08:00
|
|
|
int code = die_message(_(upstream_missing), start_name);
|
|
|
|
|
advise_if_enabled(ADVICE_SET_UPSTREAM_FAILURE,
|
|
|
|
|
_(upstream_advice));
|
|
|
|
|
exit(code);
|
2013-04-03 03:05:12 +08:00
|
|
|
}
|
2021-12-02 06:15:42 +08:00
|
|
|
die(_("not a valid object name: '%s'"), start_name);
|
2013-04-03 03:04:27 +08:00
|
|
|
}
|
2008-02-08 00:40:08 +08:00
|
|
|
|
libs: use "struct repository *" argument, not "the_repository"
As can easily be seen from grepping in our sources, we had these uses
of "the_repository" in various library code in cases where the
function in question was already getting a "struct repository *"
argument. Let's use that argument instead.
Out of these changes only the changes to "cache-tree.c",
"commit-reach.c", "shallow.c" and "upload-pack.c" would have cleanly
applied before the migration away from the "repo_*()" wrapper macros
in the preceding commits.
The rest aren't new, as we'd previously implicitly refer to
"the_repository", but it's now more obvious that we were doing the
wrong thing all along, and should have used the parameter instead.
The change to change "get_index_format_default(the_repository)" in
"read-cache.c" to use the "r" variable instead should arguably have
been part of [1], or in the subsequent cleanup in [2]. Let's do it
here, as can be seen from the initial code in [3] it's not important
that we use "the_repository" there, but would prefer to always use the
current repository.
This change excludes the "the_repository" use in "upload-pack.c"'s
upload_pack_advertise(), as the in-flight [4] makes that change.
1. ee1f0c242ef (read-cache: add index.skipHash config option,
2023-01-06)
2. 6269f8eaad0 (treewide: always have a valid "index_state.repo"
member, 2023-01-17)
3. 7211b9e7534 (repo-settings: consolidate some config settings,
2019-08-13)
4. <Y/hbUsGPVNAxTdmS@coredump.intra.peff.net>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-28 21:58:58 +08:00
|
|
|
switch (repo_dwim_ref(r, start_name, strlen(start_name), &oid,
|
|
|
|
|
&real_ref, 0)) {
|
2008-02-08 00:40:08 +08:00
|
|
|
case 0:
|
|
|
|
|
/* Not branching from any existing branch */
|
2010-01-19 04:44:11 +08:00
|
|
|
if (explicit_tracking)
|
2013-04-03 03:04:51 +08:00
|
|
|
die(_(upstream_not_branch), start_name);
|
2008-02-08 00:40:08 +08:00
|
|
|
break;
|
|
|
|
|
case 1:
|
2011-02-17 07:12:20 +08:00
|
|
|
/* Unique completion -- good, only if it is a real branch */
|
2013-12-01 04:55:40 +08:00
|
|
|
if (!starts_with(real_ref, "refs/heads/") &&
|
branch.c: Validate tracking branches with refspecs instead of refs/remotes/*
The current code for validating tracking branches (e.g. the argument to
the -t/--track option) hardcodes refs/heads/* and refs/remotes/* as the
potential locations for tracking branches. This works with the refspecs
created by "git clone" or "git remote add", but is suboptimal in other
cases:
- If "refs/remotes/foo/bar" exists without any association to a remote
(i.e. there is no remote named "foo", or no remote with a refspec
that matches "refs/remotes/foo/bar"), then it is impossible to set up
a valid upstream config that tracks it. Currently, the code defaults
to using "refs/remotes/foo/bar" from repo "." as the upstream, which
works, but is probably not what the user had in mind when running
"git branch baz --track foo/bar".
- If the user has tweaked the fetch refspec for a remote to put its
remote-tracking branches outside of refs/remotes/*, e.g. by running
git config remote.foo.fetch "+refs/heads/*:refs/foo_stuff/*"
then the current code will refuse to use its remote-tracking branches
as --track arguments, since they do not match refs/remotes/*.
This patch removes the "refs/remotes/*" requirement for upstream branches,
and replaces it with explicit checking of the refspecs for each remote to
determine whether a given --track argument is a valid remote-tracking
branch. This solves both of the above problems, since the matching refspec
guarantees that there is a both a remote name and a remote branch name
that can be used for the upstream config.
However, this means that refs located within refs/remotes/* without a
corresponding remote/refspec will no longer be usable as upstreams.
The few existing tests which depended on this behavioral quirk has
already been fixed in the preceding patches.
This patch fixes the last remaining test failure in t2024-checkout-dwim.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-22 05:52:05 +08:00
|
|
|
validate_remote_tracking_branch(real_ref)) {
|
2011-02-17 07:12:20 +08:00
|
|
|
if (explicit_tracking)
|
2013-04-03 03:04:51 +08:00
|
|
|
die(_(upstream_not_branch), start_name);
|
2011-02-17 07:12:20 +08:00
|
|
|
else
|
2021-04-25 22:16:12 +08:00
|
|
|
FREE_AND_NULL(real_ref);
|
2011-02-17 07:12:20 +08:00
|
|
|
}
|
2008-02-08 00:40:08 +08:00
|
|
|
break;
|
|
|
|
|
default:
|
2021-12-02 06:15:42 +08:00
|
|
|
die(_("ambiguous object name: '%s'"), start_name);
|
2008-02-08 00:40:08 +08:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
2022-05-03 00:50:37 +08:00
|
|
|
if (!(commit = lookup_commit_reference(r, &oid)))
|
2021-12-02 06:15:42 +08:00
|
|
|
die(_("not a valid branch point: '%s'"), start_name);
|
2022-01-29 08:04:41 +08:00
|
|
|
if (out_real_ref) {
|
|
|
|
|
*out_real_ref = real_ref;
|
|
|
|
|
real_ref = NULL;
|
|
|
|
|
}
|
|
|
|
|
if (out_oid)
|
|
|
|
|
oidcpy(out_oid, &commit->object.oid);
|
|
|
|
|
|
|
|
|
|
FREE_AND_NULL(real_ref);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void create_branch(struct repository *r,
|
|
|
|
|
const char *name, const char *start_name,
|
|
|
|
|
int force, int clobber_head_ok, int reflog,
|
2022-01-29 08:04:43 +08:00
|
|
|
int quiet, enum branch_track track, int dry_run)
|
2022-01-29 08:04:41 +08:00
|
|
|
{
|
|
|
|
|
struct object_id oid;
|
|
|
|
|
char *real_ref;
|
|
|
|
|
struct strbuf ref = STRBUF_INIT;
|
|
|
|
|
int forcing = 0;
|
2022-01-29 08:04:42 +08:00
|
|
|
struct ref_transaction *transaction;
|
|
|
|
|
struct strbuf err = STRBUF_INIT;
|
2024-09-12 19:30:10 +08:00
|
|
|
int flags = 0;
|
2022-01-29 08:04:42 +08:00
|
|
|
char *msg;
|
|
|
|
|
|
|
|
|
|
if (track == BRANCH_TRACK_OVERRIDE)
|
|
|
|
|
BUG("'track' cannot be BRANCH_TRACK_OVERRIDE. Did you mean to call dwim_and_setup_tracking()?");
|
|
|
|
|
if (clobber_head_ok && !force)
|
|
|
|
|
BUG("'clobber_head_ok' can only be used with 'force'");
|
|
|
|
|
|
|
|
|
|
if (clobber_head_ok ?
|
|
|
|
|
validate_branchname(name, &ref) :
|
|
|
|
|
validate_new_branchname(name, &ref, force)) {
|
|
|
|
|
forcing = 1;
|
2022-01-29 08:04:41 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
dwim_branch_start(r, start_name, track, &real_ref, &oid);
|
2022-01-29 08:04:43 +08:00
|
|
|
if (dry_run)
|
|
|
|
|
goto cleanup;
|
2008-02-08 00:40:08 +08:00
|
|
|
|
2014-04-17 07:21:53 +08:00
|
|
|
if (reflog)
|
2024-09-12 19:30:10 +08:00
|
|
|
flags |= REF_FORCE_CREATE_REFLOG;
|
2014-04-17 07:21:53 +08:00
|
|
|
|
2022-01-29 08:04:42 +08:00
|
|
|
if (forcing)
|
|
|
|
|
msg = xstrfmt("branch: Reset to %s", start_name);
|
|
|
|
|
else
|
|
|
|
|
msg = xstrfmt("branch: Created from %s", start_name);
|
2024-05-07 15:11:53 +08:00
|
|
|
transaction = ref_store_transaction_begin(get_main_ref_store(the_repository),
|
|
|
|
|
&err);
|
2022-01-29 08:04:42 +08:00
|
|
|
if (!transaction ||
|
|
|
|
|
ref_transaction_update(transaction, ref.buf,
|
|
|
|
|
&oid, forcing ? NULL : null_oid(),
|
2024-09-12 19:30:10 +08:00
|
|
|
NULL, NULL, flags, msg, &err) ||
|
2022-01-29 08:04:42 +08:00
|
|
|
ref_transaction_commit(transaction, &err))
|
|
|
|
|
die("%s", err.buf);
|
|
|
|
|
ref_transaction_free(transaction);
|
|
|
|
|
strbuf_release(&err);
|
|
|
|
|
free(msg);
|
2014-04-17 07:21:53 +08:00
|
|
|
|
2008-02-08 00:40:08 +08:00
|
|
|
if (real_ref && track)
|
2013-08-31 05:56:46 +08:00
|
|
|
setup_tracking(ref.buf + 11, real_ref, track, quiet);
|
2008-02-08 00:40:08 +08:00
|
|
|
|
2022-01-29 08:04:43 +08:00
|
|
|
cleanup:
|
2009-02-14 15:08:05 +08:00
|
|
|
strbuf_release(&ref);
|
2008-02-20 00:24:37 +08:00
|
|
|
free(real_ref);
|
2008-02-08 00:40:08 +08:00
|
|
|
}
|
2008-02-08 00:40:16 +08:00
|
|
|
|
2022-01-29 08:04:41 +08:00
|
|
|
void dwim_and_setup_tracking(struct repository *r, const char *new_ref,
|
|
|
|
|
const char *orig_ref, enum branch_track track,
|
|
|
|
|
int quiet)
|
|
|
|
|
{
|
2023-06-12 02:49:43 +08:00
|
|
|
char *real_orig_ref = NULL;
|
2022-01-29 08:04:41 +08:00
|
|
|
dwim_branch_start(r, orig_ref, track, &real_orig_ref, NULL);
|
|
|
|
|
setup_tracking(new_ref, real_orig_ref, track, quiet);
|
2023-06-12 02:49:43 +08:00
|
|
|
free(real_orig_ref);
|
2022-01-29 08:04:41 +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
|
|
|
/**
|
|
|
|
|
* Creates a branch in a submodule by calling
|
|
|
|
|
* create_branches_recursively() in a child process. The child process
|
|
|
|
|
* is necessary because install_branch_config_multiple_remotes() (which
|
|
|
|
|
* is called by setup_tracking()) does not support writing configs to
|
|
|
|
|
* submodules.
|
|
|
|
|
*/
|
|
|
|
|
static int submodule_create_branch(struct repository *r,
|
|
|
|
|
const struct submodule *submodule,
|
|
|
|
|
const char *name, const char *start_oid,
|
|
|
|
|
const char *tracking_name, int force,
|
|
|
|
|
int reflog, int quiet,
|
|
|
|
|
enum branch_track track, int dry_run)
|
|
|
|
|
{
|
|
|
|
|
int ret = 0;
|
|
|
|
|
struct child_process child = CHILD_PROCESS_INIT;
|
|
|
|
|
struct strbuf child_err = STRBUF_INIT;
|
|
|
|
|
struct strbuf out_buf = STRBUF_INIT;
|
|
|
|
|
char *out_prefix = xstrfmt("submodule '%s': ", submodule->name);
|
|
|
|
|
child.git_cmd = 1;
|
|
|
|
|
child.err = -1;
|
|
|
|
|
child.stdout_to_stderr = 1;
|
|
|
|
|
|
2022-06-02 17:09:50 +08:00
|
|
|
prepare_other_repo_env(&child.env, r->gitdir);
|
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
|
|
|
/*
|
|
|
|
|
* submodule_create_branch() is indirectly invoked by "git
|
|
|
|
|
* branch", but we cannot invoke "git branch" in the child
|
|
|
|
|
* process. "git branch" accepts a branch name and start point,
|
|
|
|
|
* where the start point is assumed to provide both the OID
|
|
|
|
|
* (start_oid) and the branch to use for tracking
|
|
|
|
|
* (tracking_name). But when recursing through submodules,
|
|
|
|
|
* start_oid and tracking name need to be specified separately
|
|
|
|
|
* (see create_branches_recursively()).
|
|
|
|
|
*/
|
|
|
|
|
strvec_pushl(&child.args, "submodule--helper", "create-branch", NULL);
|
|
|
|
|
if (dry_run)
|
|
|
|
|
strvec_push(&child.args, "--dry-run");
|
|
|
|
|
if (force)
|
|
|
|
|
strvec_push(&child.args, "--force");
|
|
|
|
|
if (quiet)
|
|
|
|
|
strvec_push(&child.args, "--quiet");
|
|
|
|
|
if (reflog)
|
|
|
|
|
strvec_push(&child.args, "--create-reflog");
|
2022-03-30 04:01:16 +08:00
|
|
|
|
|
|
|
|
switch (track) {
|
|
|
|
|
case BRANCH_TRACK_NEVER:
|
|
|
|
|
strvec_push(&child.args, "--no-track");
|
|
|
|
|
break;
|
|
|
|
|
case BRANCH_TRACK_ALWAYS:
|
|
|
|
|
case BRANCH_TRACK_EXPLICIT:
|
|
|
|
|
strvec_push(&child.args, "--track=direct");
|
|
|
|
|
break;
|
|
|
|
|
case BRANCH_TRACK_OVERRIDE:
|
|
|
|
|
BUG("BRANCH_TRACK_OVERRIDE cannot be used when creating a branch.");
|
|
|
|
|
break;
|
|
|
|
|
case BRANCH_TRACK_INHERIT:
|
|
|
|
|
strvec_push(&child.args, "--track=inherit");
|
|
|
|
|
break;
|
|
|
|
|
case BRANCH_TRACK_UNSPECIFIED:
|
2022-04-01 06:41:17 +08:00
|
|
|
/* Default for "git checkout". Do not pass --track. */
|
2022-03-30 04:01:16 +08:00
|
|
|
case BRANCH_TRACK_REMOTE:
|
2022-04-01 06:41:17 +08:00
|
|
|
/* Default for "git branch". Do not pass --track. */
|
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 17:56:44 +08:00
|
|
|
case BRANCH_TRACK_SIMPLE:
|
|
|
|
|
/* Config-driven only. Do not pass --track. */
|
2022-03-30 04:01:16 +08:00
|
|
|
break;
|
|
|
|
|
}
|
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
|
|
|
|
|
|
|
|
strvec_pushl(&child.args, name, start_oid, tracking_name, NULL);
|
|
|
|
|
|
|
|
|
|
if ((ret = start_command(&child)))
|
|
|
|
|
return ret;
|
|
|
|
|
ret = finish_command(&child);
|
|
|
|
|
strbuf_read(&child_err, child.err, 0);
|
|
|
|
|
strbuf_add_lines(&out_buf, out_prefix, child_err.buf, child_err.len);
|
|
|
|
|
|
|
|
|
|
if (ret)
|
|
|
|
|
fprintf(stderr, "%s", out_buf.buf);
|
|
|
|
|
else
|
|
|
|
|
printf("%s", out_buf.buf);
|
|
|
|
|
|
|
|
|
|
strbuf_release(&child_err);
|
|
|
|
|
strbuf_release(&out_buf);
|
2024-09-30 17:13:27 +08:00
|
|
|
free(out_prefix);
|
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
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void create_branches_recursively(struct repository *r, const char *name,
|
2024-04-08 05:21:08 +08: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 08:04:45 +08:00
|
|
|
const char *tracking_name, int force,
|
|
|
|
|
int reflog, int quiet, enum branch_track track,
|
|
|
|
|
int dry_run)
|
|
|
|
|
{
|
|
|
|
|
int i = 0;
|
|
|
|
|
char *branch_point = NULL;
|
|
|
|
|
struct object_id super_oid;
|
|
|
|
|
struct submodule_entry_list submodule_entry_list;
|
|
|
|
|
|
2024-04-08 05:21:08 +08:00
|
|
|
/* Perform dwim on start_committish to get super_oid and branch_point. */
|
|
|
|
|
dwim_branch_start(r, start_committish, BRANCH_TRACK_NEVER,
|
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
|
|
|
&branch_point, &super_oid);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If we were not given an explicit name to track, then assume we are at
|
|
|
|
|
* the top level and, just like the non-recursive case, the tracking
|
|
|
|
|
* name is the branch point.
|
|
|
|
|
*/
|
|
|
|
|
if (!tracking_name)
|
|
|
|
|
tracking_name = branch_point;
|
|
|
|
|
|
|
|
|
|
submodules_of_tree(r, &super_oid, &submodule_entry_list);
|
|
|
|
|
/*
|
|
|
|
|
* Before creating any branches, first check that the branch can
|
|
|
|
|
* be created in every submodule.
|
|
|
|
|
*/
|
|
|
|
|
for (i = 0; i < submodule_entry_list.entry_nr; i++) {
|
2022-05-03 01:18:22 +08:00
|
|
|
if (!submodule_entry_list.entries[i].repo) {
|
2022-03-30 04:01:17 +08:00
|
|
|
int code = die_message(
|
|
|
|
|
_("submodule '%s': unable to find submodule"),
|
|
|
|
|
submodule_entry_list.entries[i].submodule->name);
|
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 (advice_enabled(ADVICE_SUBMODULES_NOT_UPDATED))
|
2023-01-17 01:41:48 +08:00
|
|
|
advise(_("You may try updating the submodules using 'git checkout --no-recurse-submodules %s && git submodule update --init'"),
|
2024-04-08 05:21:08 +08:00
|
|
|
start_committish);
|
2022-03-30 04:01:17 +08:00
|
|
|
exit(code);
|
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 (submodule_create_branch(
|
|
|
|
|
submodule_entry_list.entries[i].repo,
|
|
|
|
|
submodule_entry_list.entries[i].submodule, name,
|
|
|
|
|
oid_to_hex(&submodule_entry_list.entries[i]
|
|
|
|
|
.name_entry->oid),
|
|
|
|
|
tracking_name, force, reflog, quiet, track, 1))
|
|
|
|
|
die(_("submodule '%s': cannot create branch '%s'"),
|
|
|
|
|
submodule_entry_list.entries[i].submodule->name,
|
|
|
|
|
name);
|
|
|
|
|
}
|
|
|
|
|
|
2024-04-08 05:21:08 +08:00
|
|
|
create_branch(r, name, start_committish, force, 0, reflog, quiet,
|
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
|
|
|
BRANCH_TRACK_NEVER, dry_run);
|
|
|
|
|
if (dry_run)
|
2024-09-30 17:13:27 +08:00
|
|
|
goto 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
|
|
|
/*
|
|
|
|
|
* NEEDSWORK If tracking was set up in the superproject but not the
|
|
|
|
|
* submodule, users might expect "git branch --recurse-submodules" to
|
|
|
|
|
* fail or give a warning, but this is not yet implemented because it is
|
|
|
|
|
* tedious to determine whether or not tracking was set up in the
|
|
|
|
|
* superproject.
|
|
|
|
|
*/
|
2022-03-30 04:01:16 +08:00
|
|
|
if (track)
|
|
|
|
|
setup_tracking(name, tracking_name, track, quiet);
|
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
|
|
|
|
|
|
|
|
for (i = 0; i < submodule_entry_list.entry_nr; i++) {
|
|
|
|
|
if (submodule_create_branch(
|
|
|
|
|
submodule_entry_list.entries[i].repo,
|
|
|
|
|
submodule_entry_list.entries[i].submodule, name,
|
|
|
|
|
oid_to_hex(&submodule_entry_list.entries[i]
|
|
|
|
|
.name_entry->oid),
|
|
|
|
|
tracking_name, force, reflog, quiet, track, 0))
|
|
|
|
|
die(_("submodule '%s': cannot create branch '%s'"),
|
|
|
|
|
submodule_entry_list.entries[i].submodule->name,
|
|
|
|
|
name);
|
|
|
|
|
}
|
2024-09-30 17:13:27 +08:00
|
|
|
|
|
|
|
|
out:
|
|
|
|
|
submodule_entry_list_release(&submodule_entry_list);
|
|
|
|
|
free(branch_point);
|
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
|
|
|
}
|
|
|
|
|
|
2019-05-09 18:10:27 +08:00
|
|
|
void remove_merge_branch_state(struct repository *r)
|
2008-02-08 00:40:16 +08:00
|
|
|
{
|
2018-11-10 13:49:00 +08:00
|
|
|
unlink(git_path_merge_head(r));
|
|
|
|
|
unlink(git_path_merge_rr(r));
|
|
|
|
|
unlink(git_path_merge_msg(r));
|
|
|
|
|
unlink(git_path_merge_mode(r));
|
2024-01-19 18:40:09 +08:00
|
|
|
refs_delete_ref(get_main_ref_store(r), "", "AUTO_MERGE",
|
|
|
|
|
NULL, REF_NO_DEREF);
|
2024-01-19 18:40:19 +08:00
|
|
|
save_autostash_ref(r, "MERGE_AUTOSTASH");
|
2019-05-09 18:10:27 +08:00
|
|
|
}
|
|
|
|
|
|
2019-07-10 06:25:44 +08:00
|
|
|
void remove_branch_state(struct repository *r, int verbose)
|
2019-05-09 18:10:27 +08:00
|
|
|
{
|
2019-07-10 06:25:44 +08:00
|
|
|
sequencer_post_commit_cleanup(r, verbose);
|
2018-11-10 13:49:00 +08:00
|
|
|
unlink(git_path_squash_msg(r));
|
2019-05-09 18:10:27 +08:00
|
|
|
remove_merge_branch_state(r);
|
2008-02-08 00:40:16 +08:00
|
|
|
}
|
2015-07-18 07:00:04 +08:00
|
|
|
|
2016-04-22 21:01:33 +08:00
|
|
|
void die_if_checked_out(const char *branch, int ignore_current_worktree)
|
2015-08-11 01:52:44 +08:00
|
|
|
{
|
2021-12-02 06:15:43 +08:00
|
|
|
struct worktree **worktrees = get_worktrees();
|
2015-08-11 01:52:44 +08:00
|
|
|
|
2023-02-25 22:22:02 +08:00
|
|
|
for (int i = 0; worktrees[i]; i++) {
|
|
|
|
|
if (worktrees[i]->is_current && ignore_current_worktree)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
if (is_shared_symref(worktrees[i], "HEAD", branch)) {
|
|
|
|
|
skip_prefix(branch, "refs/heads/", &branch);
|
2023-08-08 04:42:40 +08:00
|
|
|
die(_("'%s' is already used by worktree at '%s'"),
|
2023-02-25 22:22:02 +08:00
|
|
|
branch, worktrees[i]->path);
|
|
|
|
|
}
|
2021-12-02 06:15:43 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
free_worktrees(worktrees);
|
2015-07-18 07:00:04 +08:00
|
|
|
}
|
