mirrors/git
0
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-24 02:17:02 +08:00
Code Issues Packages Projects Releases Wiki Activity
f1c985da05
git/branch.c

372 lines
9.2 KiB
C
Raw Normal View History

branch: use skip_prefix() in install_branch_config() The install_branch_config() function reimplemented the skip_prefix() function inline. Reported-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Brian Gesiak <modocache@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-28 14:43:33 +08:00
#include "git-compat-util.h"
Move create_branch into a library file You can also create branches, in exactly the same way, with checkout -b. This introduces branch.{c,h} library files for doing porcelain-level operations on branches (such as creating them with their appropriate default configuration). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-08 00:40:08 +08:00
#include "cache.h"
#include "branch.h"
#include "refs.h"
#include "remote.h"
#include "commit.h"
worktree: add top-level worktree.c worktree.c contains functions to work with and get information from worktrees. This introduction moves functions related to worktrees from branch.c into worktree.c Signed-off-by: Michael Rappazzo <rappazzo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-02 19:55:31 +08:00
#include "worktree.h"
Move create_branch into a library file You can also create branches, in exactly the same way, with checkout -b. This introduces branch.{c,h} library files for doing porcelain-level operations on branches (such as creating them with their appropriate default configuration). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-08 00:40:08 +08:00
struct tracking {
struct refspec spec;
char *src;
const char *remote;
int matches;
};
static int find_tracked_branch(struct remote *remote, void *priv)
{
struct tracking *tracking = priv;
if (!remote_find_tracking(remote, &tracking->spec)) {
if (++tracking->matches == 1) {
tracking->src = tracking->spec.src;
tracking->remote = remote->name;
} else {
free(tracking->spec.src);
if (tracking->src) {
free(tracking->src);
tracking->src = NULL;
}
}
tracking->spec.src = NULL;
}
return 0;
}
Make git-clone respect branch.autosetuprebase When git-clone creates an initial branch it was not checking the branch.autosetuprebase configuration option (which may exist in ~/.gitconfig). Refactor the code used by "git branch" to create a new branch, and use it instead of the insufficiently duplicated code in builtin-clone. Changes are partly, and the test is mostly, based on the previous work by Pat Notz. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-04 14:29:55 +08:00
static int should_setup_rebase(const char *origin)
Allow tracking branches to set up rebase by default. Change cd67e4d4 introduced a new configuration parameter that told pull to automatically perform a rebase instead of a merge. This change provides a configuration option to enable this feature automatically when creating a new branch. If the variable branch.autosetuprebase applies for a branch that's being created, that branch will have branch.<name>.rebase set to true. Signed-off-by: Dustin Sallings <dustin@spy.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-11 06:36:29 +08:00
{
switch (autorebase) {
case AUTOREBASE_NEVER:
return 0;
case AUTOREBASE_LOCAL:
Make git-clone respect branch.autosetuprebase When git-clone creates an initial branch it was not checking the branch.autosetuprebase configuration option (which may exist in ~/.gitconfig). Refactor the code used by "git branch" to create a new branch, and use it instead of the insufficiently duplicated code in builtin-clone. Changes are partly, and the test is mostly, based on the previous work by Pat Notz. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-04 14:29:55 +08:00
return origin == NULL;
Allow tracking branches to set up rebase by default. Change cd67e4d4 introduced a new configuration parameter that told pull to automatically perform a rebase instead of a merge. This change provides a configuration option to enable this feature automatically when creating a new branch. If the variable branch.autosetuprebase applies for a branch that's being created, that branch will have branch.<name>.rebase set to true. Signed-off-by: Dustin Sallings <dustin@spy.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-11 06:36:29 +08:00
case AUTOREBASE_REMOTE:
Make git-clone respect branch.autosetuprebase When git-clone creates an initial branch it was not checking the branch.autosetuprebase configuration option (which may exist in ~/.gitconfig). Refactor the code used by "git branch" to create a new branch, and use it instead of the insufficiently duplicated code in builtin-clone. Changes are partly, and the test is mostly, based on the previous work by Pat Notz. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-04 14:29:55 +08:00
return origin != NULL;
Allow tracking branches to set up rebase by default. Change cd67e4d4 introduced a new configuration parameter that told pull to automatically perform a rebase instead of a merge. This change provides a configuration option to enable this feature automatically when creating a new branch. If the variable branch.autosetuprebase applies for a branch that's being created, that branch will have branch.<name>.rebase set to true. Signed-off-by: Dustin Sallings <dustin@spy.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-11 06:36:29 +08:00
case AUTOREBASE_ALWAYS:
return 1;
}
return 0;
}
branch: report errors in tracking branch setup When setting up a new tracking branch fails due to issues with the configuration file we do not report any errors to the user and pretend setting the tracking branch succeeded. Setting up the tracking branch is handled by the `install_branch_config` function. We do not want to simply die there as the function is not only invoked when explicitly setting upstream information with `git branch --set-upstream-to=`, but also by `git push --set-upstream` and `git clone`. While it is reasonable to die in the explict first case, we would lose information in the latter two cases, so we only print the error message but continue the program as usual. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22 19:23:23 +08:00
static const char tracking_advice[] =
N_("\n"
"After fixing the error cause you may try to fix up\n"
"the remote tracking information by invoking\n"
"\"git branch --set-upstream-to=%s%s%s\".");
int install_branch_config(int flag, const char *local, const char *origin, const char *remote)
Make git-clone respect branch.autosetuprebase When git-clone creates an initial branch it was not checking the branch.autosetuprebase configuration option (which may exist in ~/.gitconfig). Refactor the code used by "git branch" to create a new branch, and use it instead of the insufficiently duplicated code in builtin-clone. Changes are partly, and the test is mostly, based on the previous work by Pat Notz. Signed-off-by: Junio C Hamano <gitster@pobox.com>
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;
Make git-clone respect branch.autosetuprebase When git-clone creates an initial branch it was not checking the branch.autosetuprebase configuration option (which may exist in ~/.gitconfig). Refactor the code used by "git branch" to create a new branch, and use it instead of the insufficiently duplicated code in builtin-clone. Changes are partly, and the test is mostly, based on the previous work by Pat Notz. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-04 14:29:55 +08:00
struct strbuf key = STRBUF_INIT;
int rebasing = should_setup_rebase(origin);
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
if (skip_prefix(remote, "refs/heads/", &shortname)
branch: warn and refuse to set a branch as a tracking branch of itself. Previous patch allows commands like "git branch --set-upstream foo foo", which doesn't make much sense. Warn the user and don't change the configuration in this case. Don't die to let the caller finish its job in such case. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-19 04:44:12 +08:00
&& !strcmp(local, shortname)
&& !origin) {
i18n: branch: mark strings for translation Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Reviewed-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-16 11:37:50 +08:00
warning(_("Not setting branch %s as its own upstream."),
branch: warn and refuse to set a branch as a tracking branch of itself. Previous patch allows commands like "git branch --set-upstream foo foo", which doesn't make much sense. Warn the user and don't change the configuration in this case. Don't die to let the caller finish its job in such case. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-19 04:44:12 +08:00
local);
branch: report errors in tracking branch setup When setting up a new tracking branch fails due to issues with the configuration file we do not report any errors to the user and pretend setting the tracking branch succeeded. Setting up the tracking branch is handled by the `install_branch_config` function. We do not want to simply die there as the function is not only invoked when explicitly setting upstream information with `git branch --set-upstream-to=`, but also by `git push --set-upstream` and `git clone`. While it is reasonable to die in the explict first case, we would lose information in the latter two cases, so we only print the error message but continue the program as usual. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22 19:23:23 +08:00
return 0;
branch: warn and refuse to set a branch as a tracking branch of itself. Previous patch allows commands like "git branch --set-upstream foo foo", which doesn't make much sense. Warn the user and don't change the configuration in this case. Don't die to let the caller finish its job in such case. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-19 04:44:12 +08:00
}
Make git-clone respect branch.autosetuprebase When git-clone creates an initial branch it was not checking the branch.autosetuprebase configuration option (which may exist in ~/.gitconfig). Refactor the code used by "git branch" to create a new branch, and use it instead of the insufficiently duplicated code in builtin-clone. Changes are partly, and the test is mostly, based on the previous work by Pat Notz. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-04 14:29:55 +08:00
strbuf_addf(&key, "branch.%s.remote", local);
config: rename git_config_set to git_config_set_gently The desired default behavior for `git_config_set` is to die whenever an error occurs. Dying is the default for a lot of internal functions when failures occur and is in this case the right thing to do for most callers as otherwise we might run into inconsistent repositories without noticing. As some code may rely on the actual return values for `git_config_set` we still require the ability to invoke these functions without aborting. Rename the existing `git_config_set` functions to `git_config_set_gently` to keep them available for those callers. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22 19:23:35 +08:00
if (git_config_set_gently(key.buf, origin ? origin : ".") < 0)
branch: report errors in tracking branch setup When setting up a new tracking branch fails due to issues with the configuration file we do not report any errors to the user and pretend setting the tracking branch succeeded. Setting up the tracking branch is handled by the `install_branch_config` function. We do not want to simply die there as the function is not only invoked when explicitly setting upstream information with `git branch --set-upstream-to=`, but also by `git push --set-upstream` and `git clone`. While it is reasonable to die in the explict first case, we would lose information in the latter two cases, so we only print the error message but continue the program as usual. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22 19:23:23 +08:00
goto out_err;
Make git-clone respect branch.autosetuprebase When git-clone creates an initial branch it was not checking the branch.autosetuprebase configuration option (which may exist in ~/.gitconfig). Refactor the code used by "git branch" to create a new branch, and use it instead of the insufficiently duplicated code in builtin-clone. Changes are partly, and the test is mostly, based on the previous work by Pat Notz. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-04 14:29:55 +08:00
strbuf_reset(&key);
strbuf_addf(&key, "branch.%s.merge", local);
config: rename git_config_set to git_config_set_gently The desired default behavior for `git_config_set` is to die whenever an error occurs. Dying is the default for a lot of internal functions when failures occur and is in this case the right thing to do for most callers as otherwise we might run into inconsistent repositories without noticing. As some code may rely on the actual return values for `git_config_set` we still require the ability to invoke these functions without aborting. Rename the existing `git_config_set` functions to `git_config_set_gently` to keep them available for those callers. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22 19:23:35 +08:00
if (git_config_set_gently(key.buf, remote) < 0)
branch: report errors in tracking branch setup When setting up a new tracking branch fails due to issues with the configuration file we do not report any errors to the user and pretend setting the tracking branch succeeded. Setting up the tracking branch is handled by the `install_branch_config` function. We do not want to simply die there as the function is not only invoked when explicitly setting upstream information with `git branch --set-upstream-to=`, but also by `git push --set-upstream` and `git clone`. While it is reasonable to die in the explict first case, we would lose information in the latter two cases, so we only print the error message but continue the program as usual. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22 19:23:23 +08:00
goto out_err;
Make git-clone respect branch.autosetuprebase When git-clone creates an initial branch it was not checking the branch.autosetuprebase configuration option (which may exist in ~/.gitconfig). Refactor the code used by "git branch" to create a new branch, and use it instead of the insufficiently duplicated code in builtin-clone. Changes are partly, and the test is mostly, based on the previous work by Pat Notz. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-04 14:29:55 +08:00
if (rebasing) {
strbuf_reset(&key);
strbuf_addf(&key, "branch.%s.rebase", local);
config: rename git_config_set to git_config_set_gently The desired default behavior for `git_config_set` is to die whenever an error occurs. Dying is the default for a lot of internal functions when failures occur and is in this case the right thing to do for most callers as otherwise we might run into inconsistent repositories without noticing. As some code may rely on the actual return values for `git_config_set` we still require the ability to invoke these functions without aborting. Rename the existing `git_config_set` functions to `git_config_set_gently` to keep them available for those callers. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22 19:23:35 +08:00
if (git_config_set_gently(key.buf, "true") < 0)
branch: report errors in tracking branch setup When setting up a new tracking branch fails due to issues with the configuration file we do not report any errors to the user and pretend setting the tracking branch succeeded. Setting up the tracking branch is handled by the `install_branch_config` function. We do not want to simply die there as the function is not only invoked when explicitly setting upstream information with `git branch --set-upstream-to=`, but also by `git push --set-upstream` and `git clone`. While it is reasonable to die in the explict first case, we would lose information in the latter two cases, so we only print the error message but continue the program as usual. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22 19:23:23 +08:00
goto out_err;
Make git-clone respect branch.autosetuprebase When git-clone creates an initial branch it was not checking the branch.autosetuprebase configuration option (which may exist in ~/.gitconfig). Refactor the code used by "git branch" to create a new branch, and use it instead of the insufficiently duplicated code in builtin-clone. Changes are partly, and the test is mostly, based on the previous work by Pat Notz. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-04 14:29:55 +08:00
}
Remove i18n legos in notifying new branch tracking setup Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-07 20:05:10 +08:00
strbuf_release(&key);
Make git-clone respect branch.autosetuprebase When git-clone creates an initial branch it was not checking the branch.autosetuprebase configuration option (which may exist in ~/.gitconfig). Refactor the code used by "git branch" to create a new branch, and use it instead of the insufficiently duplicated code in builtin-clone. Changes are partly, and the test is mostly, based on the previous work by Pat Notz. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-04 14:29:55 +08:00
Improve "git branch --tracking" output An earlier patch always spelled the full name of the ref that we track (e.g. "refs/heads/frotz" instead of just "frotz" when we mean the branch whose name is "frotz"). Worse yet, because we now use the true name of the ref at the original repository when talk about a tracking branch that copies from a remote, such a full name alone still does not give enough information. This reorganizes the verbose codepath to: - differentiate "refs/heads/something" and everything else; we say that the branch tracks "branch <something>" if it begins with "refs/heads/", and otherwise the branch tracks "ref refs/<someother>/<something>"; - report the name of the remote when we talk about a tracking branch, by saying "branch frotz from origin"; - not say "by merging" at the end; it is the default and is not worth reporting. Signed-off-by: Junio C Hamano <junio@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-10 16:20:42 +08:00
if (flag & BRANCH_CONFIG_VERBOSE) {
Merge branch 'an/branch-config-message' * an/branch-config-message: branch.c: install_branch_config: simplify if chain
2014-04-01 07:31:19 +08:00
if (shortname) {
branch.c: install_branch_config: simplify if chain Simplify if chain in install_branch_config(). Signed-off-by: Adam <Adam@sigterm.info> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-10 13:32:01 +08:00
if (origin)
printf_ln(rebasing ?
_("Branch %s set up to track remote branch %s from %s by rebasing.") :
_("Branch %s set up to track remote branch %s from %s."),
local, shortname, origin);
else
printf_ln(rebasing ?
_("Branch %s set up to track local branch %s by rebasing.") :
_("Branch %s set up to track local branch %s."),
local, shortname);
} else {
if (origin)
printf_ln(rebasing ?
_("Branch %s set up to track remote ref %s by rebasing.") :
_("Branch %s set up to track remote ref %s."),
local, remote);
else
printf_ln(rebasing ?
_("Branch %s set up to track local ref %s by rebasing.") :
_("Branch %s set up to track local ref %s."),
local, remote);
}
Improve "git branch --tracking" output An earlier patch always spelled the full name of the ref that we track (e.g. "refs/heads/frotz" instead of just "frotz" when we mean the branch whose name is "frotz"). Worse yet, because we now use the true name of the ref at the original repository when talk about a tracking branch that copies from a remote, such a full name alone still does not give enough information. This reorganizes the verbose codepath to: - differentiate "refs/heads/something" and everything else; we say that the branch tracks "branch <something>" if it begins with "refs/heads/", and otherwise the branch tracks "ref refs/<someother>/<something>"; - report the name of the remote when we talk about a tracking branch, by saying "branch frotz from origin"; - not say "by merging" at the end; it is the default and is not worth reporting. Signed-off-by: Junio C Hamano <junio@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-10 16:20:42 +08:00
}
branch: report errors in tracking branch setup When setting up a new tracking branch fails due to issues with the configuration file we do not report any errors to the user and pretend setting the tracking branch succeeded. Setting up the tracking branch is handled by the `install_branch_config` function. We do not want to simply die there as the function is not only invoked when explicitly setting upstream information with `git branch --set-upstream-to=`, but also by `git push --set-upstream` and `git clone`. While it is reasonable to die in the explict first case, we would lose information in the latter two cases, so we only print the error message but continue the program as usual. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22 19:23:23 +08:00
return 0;
out_err:
strbuf_release(&key);
error(_("Unable to write upstream branch configuration"));
advise(_(tracking_advice),
origin ? origin : "",
origin ? "/" : "",
shortname ? shortname : remote);
return -1;
Make git-clone respect branch.autosetuprebase When git-clone creates an initial branch it was not checking the branch.autosetuprebase configuration option (which may exist in ~/.gitconfig). Refactor the code used by "git branch" to create a new branch, and use it instead of the insufficiently duplicated code in builtin-clone. Changes are partly, and the test is mostly, based on the previous work by Pat Notz. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-04 14:29:55 +08:00
}
Move create_branch into a library file You can also create branches, in exactly the same way, with checkout -b. This introduces branch.{c,h} library files for doing porcelain-level operations on branches (such as creating them with their appropriate default configuration). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-08 00:40:08 +08:00
/*
* This is called when new_ref is branched off of orig_ref, and tries
* to infer the settings for branch.<new_ref>.{remote,merge} from the
* config.
*/
branch: report errors in tracking branch setup When setting up a new tracking branch fails due to issues with the configuration file we do not report any errors to the user and pretend setting the tracking branch succeeded. Setting up the tracking branch is handled by the `install_branch_config` function. We do not want to simply die there as the function is not only invoked when explicitly setting upstream information with `git branch --set-upstream-to=`, but also by `git push --set-upstream` and `git clone`. While it is reasonable to die in the explict first case, we would lose information in the latter two cases, so we only print the error message but continue the program as usual. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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)
Move create_branch into a library file You can also create branches, in exactly the same way, with checkout -b. This introduces branch.{c,h} library files for doing porcelain-level operations on branches (such as creating them with their appropriate default configuration). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-08 00:40:08 +08:00
{
struct tracking tracking;
checkout: suppress tracking message with "-q" Like the "switched to..." message (which is already suppressed by "-q"), this message is purely informational. Let's silence it if the user asked us to be quiet. This patch is slightly more than a one-liner, because we have to teach create_branch to propagate the flag all the way down to install_branch_config. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-27 07:51:01 +08:00
int config_flags = quiet ? 0 : BRANCH_CONFIG_VERBOSE;
Move create_branch into a library file You can also create branches, in exactly the same way, with checkout -b. This introduces branch.{c,h} library files for doing porcelain-level operations on branches (such as creating them with their appropriate default configuration). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-08 00:40:08 +08:00
memset(&tracking, 0, sizeof(tracking));
tracking.spec.dst = (char *)orig_ref;
branch: optionally setup branch.*.merge from upstream local branches "git branch" and "git checkout -b" now honor --track option even when the upstream branch is local. Previously --track was silently ignored when forking from a local branch. Also the command did not error out when --track was explicitly asked for but the forked point specified was not an existing branch (i.e. when there is no way to set up the tracking configuration), but now it correctly does. The configuration setting branch.autosetupmerge can now be set to "always", which is equivalent to using --track from the command line. Setting branch.autosetupmerge to "true" will retain the former behavior of only setting up branch.*.merge for remote upstream branches. Includes test cases for the new functionality. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-20 00:24:37 +08:00
if (for_each_remote(find_tracked_branch, &tracking))
branch: report errors in tracking branch setup When setting up a new tracking branch fails due to issues with the configuration file we do not report any errors to the user and pretend setting the tracking branch succeeded. Setting up the tracking branch is handled by the `install_branch_config` function. We do not want to simply die there as the function is not only invoked when explicitly setting upstream information with `git branch --set-upstream-to=`, but also by `git push --set-upstream` and `git clone`. While it is reasonable to die in the explict first case, we would lose information in the latter two cases, so we only print the error message but continue the program as usual. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22 19:23:23 +08:00
return;
Move create_branch into a library file You can also create branches, in exactly the same way, with checkout -b. This introduces branch.{c,h} library files for doing porcelain-level operations on branches (such as creating them with their appropriate default configuration). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-08 00:40:08 +08:00
branch: optionally setup branch.*.merge from upstream local branches "git branch" and "git checkout -b" now honor --track option even when the upstream branch is local. Previously --track was silently ignored when forking from a local branch. Also the command did not error out when --track was explicitly asked for but the forked point specified was not an existing branch (i.e. when there is no way to set up the tracking configuration), but now it correctly does. The configuration setting branch.autosetupmerge can now be set to "always", which is equivalent to using --track from the command line. Setting branch.autosetupmerge to "true" will retain the former behavior of only setting up branch.*.merge for remote upstream branches. Includes test cases for the new functionality. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-20 00:24:37 +08:00
if (!tracking.matches)
switch (track) {
case BRANCH_TRACK_ALWAYS:
case BRANCH_TRACK_EXPLICIT:
Add branch --set-upstream Add --set-upstream option to branch that works like --track, except that when branch exists already, its upstream info is changed without changing the ref value. Based-on-patch-from: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-19 04:44:11 +08:00
case BRANCH_TRACK_OVERRIDE:
branch: optionally setup branch.*.merge from upstream local branches "git branch" and "git checkout -b" now honor --track option even when the upstream branch is local. Previously --track was silently ignored when forking from a local branch. Also the command did not error out when --track was explicitly asked for but the forked point specified was not an existing branch (i.e. when there is no way to set up the tracking configuration), but now it correctly does. The configuration setting branch.autosetupmerge can now be set to "always", which is equivalent to using --track from the command line. Setting branch.autosetupmerge to "true" will retain the former behavior of only setting up branch.*.merge for remote upstream branches. Includes test cases for the new functionality. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-20 00:24:37 +08:00
break;
default:
branch: report errors in tracking branch setup When setting up a new tracking branch fails due to issues with the configuration file we do not report any errors to the user and pretend setting the tracking branch succeeded. Setting up the tracking branch is handled by the `install_branch_config` function. We do not want to simply die there as the function is not only invoked when explicitly setting upstream information with `git branch --set-upstream-to=`, but also by `git push --set-upstream` and `git clone`. While it is reasonable to die in the explict first case, we would lose information in the latter two cases, so we only print the error message but continue the program as usual. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22 19:23:23 +08:00
return;
branch: optionally setup branch.*.merge from upstream local branches "git branch" and "git checkout -b" now honor --track option even when the upstream branch is local. Previously --track was silently ignored when forking from a local branch. Also the command did not error out when --track was explicitly asked for but the forked point specified was not an existing branch (i.e. when there is no way to set up the tracking configuration), but now it correctly does. The configuration setting branch.autosetupmerge can now be set to "always", which is equivalent to using --track from the command line. Setting branch.autosetupmerge to "true" will retain the former behavior of only setting up branch.*.merge for remote upstream branches. Includes test cases for the new functionality. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-20 00:24:37 +08:00
}
Move create_branch into a library file You can also create branches, in exactly the same way, with checkout -b. This introduces branch.{c,h} library files for doing porcelain-level operations on branches (such as creating them with their appropriate default configuration). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-08 00:40:08 +08:00
if (tracking.matches > 1)
branch: report errors in tracking branch setup When setting up a new tracking branch fails due to issues with the configuration file we do not report any errors to the user and pretend setting the tracking branch succeeded. Setting up the tracking branch is handled by the `install_branch_config` function. We do not want to simply die there as the function is not only invoked when explicitly setting upstream information with `git branch --set-upstream-to=`, but also by `git push --set-upstream` and `git clone`. While it is reasonable to die in the explict first case, we would lose information in the latter two cases, so we only print the error message but continue the program as usual. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22 19:23:23 +08:00
die(_("Not tracking: ambiguous information for ref %s"),
orig_ref);
Move create_branch into a library file You can also create branches, in exactly the same way, with checkout -b. This introduces branch.{c,h} library files for doing porcelain-level operations on branches (such as creating them with their appropriate default configuration). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-08 00:40:08 +08:00
branch: report errors in tracking branch setup When setting up a new tracking branch fails due to issues with the configuration file we do not report any errors to the user and pretend setting the tracking branch succeeded. Setting up the tracking branch is handled by the `install_branch_config` function. We do not want to simply die there as the function is not only invoked when explicitly setting upstream information with `git branch --set-upstream-to=`, but also by `git push --set-upstream` and `git clone`. While it is reasonable to die in the explict first case, we would lose information in the latter two cases, so we only print the error message but continue the program as usual. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22 19:23:23 +08:00
if (install_branch_config(config_flags, new_ref, tracking.remote,
tracking.src ? tracking.src : orig_ref) < 0)
exit(-1);
Move create_branch into a library file You can also create branches, in exactly the same way, with checkout -b. This introduces branch.{c,h} library files for doing porcelain-level operations on branches (such as creating them with their appropriate default configuration). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-08 00:40:08 +08:00
Make git-clone respect branch.autosetuprebase When git-clone creates an initial branch it was not checking the branch.autosetuprebase configuration option (which may exist in ~/.gitconfig). Refactor the code used by "git branch" to create a new branch, and use it instead of the insufficiently duplicated code in builtin-clone. Changes are partly, and the test is mostly, based on the previous work by Pat Notz. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-04 14:29:55 +08:00
free(tracking.src);
Move create_branch into a library file You can also create branches, in exactly the same way, with checkout -b. This introduces branch.{c,h} library files for doing porcelain-level operations on branches (such as creating them with their appropriate default configuration). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-08 00:40:08 +08:00
}
branch: add read_branch_desc() helper function This will be used by various callers that make use of the branch description throughout the system, so that if we need to update the implementation the callers do not have to be modified. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-22 11:19:38 +08:00
int read_branch_desc(struct strbuf *buf, const char *branch_name)
{
branch.c: replace `git_config()` with `git_config_get_string() Use `git_config_get_string()` instead of `git_config()` to take advantage of the config-set API which provides a cleaner control flow. While we are at it, return -1 if we find no value for the queried variable. Original code returned 0 for all cases, which was checked by `add_branch_desc()` in fmt-merge-msg.c resulting in addition of a spurious newline to the `out` strbuf. Now, the newline addition is skipped as -1 is returned to the caller if no value is found. Signed-off-by: Tanay Abhra <tanayabh@gmail.com> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-08 01:56:42 +08:00
char *v = NULL;
branch: add read_branch_desc() helper function This will be used by various callers that make use of the branch description throughout the system, so that if we need to update the implementation the callers do not have to be modified. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-22 11:19:38 +08:00
struct strbuf name = STRBUF_INIT;
strbuf_addf(&name, "branch.%s.description", branch_name);
branch.c: replace `git_config()` with `git_config_get_string() Use `git_config_get_string()` instead of `git_config()` to take advantage of the config-set API which provides a cleaner control flow. While we are at it, return -1 if we find no value for the queried variable. Original code returned 0 for all cases, which was checked by `add_branch_desc()` in fmt-merge-msg.c resulting in addition of a spurious newline to the `out` strbuf. Now, the newline addition is skipped as -1 is returned to the caller if no value is found. Signed-off-by: Tanay Abhra <tanayabh@gmail.com> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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);
branch: add read_branch_desc() helper function This will be used by various callers that make use of the branch description throughout the system, so that if we need to update the implementation the callers do not have to be modified. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-22 11:19:38 +08:00
strbuf_release(&name);
return 0;
}
branch --set-upstream: regression fix The "git branch" command, while not in listing mode, calls create_branch() even when the target branch already exists, and it does so even when it is not interested in updating the value of the branch (i.e. the name of the commit object that sits at the tip of the existing branch). This happens when the command is run with "--set-upstream" option. The earlier safety-measure to prevent "git branch -f $branch $commit" from updating the currently checked out branch did not take it into account, and we no longer can update the tracking information of the current branch. Minimally fix this regression by telling the validation code if it is called to really update the value of a potentially existing branch, or if the caller merely is interested in updating auxiliary aspects of a branch. Reported-and-Tested-by: Jay Soffian Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-17 07:28:38 +08:00
int validate_new_branchname(const char *name, struct strbuf *ref,
int force, int attr_only)
Prevent force-updating of the current branch "git branch -M <foo> <current-branch>" allows updating the current branch which HEAD points, without the necessary house-keeping that git reset normally does to make this operation sensible. It also leaves the reflog in a confusing state (you would be warned when trying to read it). "git checkout -B <current branch> <foo>" is also partly vulnerable to this bug; due to inconsistent pre-flight checks it would perform half of its task and then abort just before rewriting the branch. Again this manifested itself as the index file getting out-of-sync with HEAD. "git branch -f" already guarded against this problem, and aborts with a fatal error. Update "git branch -M", "git checkout -B" and "git branch -f" to share the same check before allowing a branch to be created. These prevent you from updating the current branch. We considered suggesting the use of "git reset" in the failure message but concluded that it was not possible to discern what the user was actually trying to do. Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-21 05:49:48 +08:00
{
if (strbuf_check_branch_ref(ref, name))
i18n: branch: mark strings for translation Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Reviewed-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-16 11:37:50 +08:00
die(_("'%s' is not a valid branch name."), name);
Prevent force-updating of the current branch "git branch -M <foo> <current-branch>" allows updating the current branch which HEAD points, without the necessary house-keeping that git reset normally does to make this operation sensible. It also leaves the reflog in a confusing state (you would be warned when trying to read it). "git checkout -B <current branch> <foo>" is also partly vulnerable to this bug; due to inconsistent pre-flight checks it would perform half of its task and then abort just before rewriting the branch. Again this manifested itself as the index file getting out-of-sync with HEAD. "git branch -f" already guarded against this problem, and aborts with a fatal error. Update "git branch -M", "git checkout -B" and "git branch -f" to share the same check before allowing a branch to be created. These prevent you from updating the current branch. We considered suggesting the use of "git reset" in the failure message but concluded that it was not possible to discern what the user was actually trying to do. Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-21 05:49:48 +08:00
if (!ref_exists(ref->buf))
return 0;
branch --set-upstream: regression fix The "git branch" command, while not in listing mode, calls create_branch() even when the target branch already exists, and it does so even when it is not interested in updating the value of the branch (i.e. the name of the commit object that sits at the tip of the existing branch). This happens when the command is run with "--set-upstream" option. The earlier safety-measure to prevent "git branch -f $branch $commit" from updating the currently checked out branch did not take it into account, and we no longer can update the tracking information of the current branch. Minimally fix this regression by telling the validation code if it is called to really update the value of a potentially existing branch, or if the caller merely is interested in updating auxiliary aspects of a branch. Reported-and-Tested-by: Jay Soffian Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-17 07:28:38 +08:00
else if (!force && !attr_only)
i18n: branch: mark strings for translation Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Reviewed-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-16 11:37:50 +08:00
die(_("A branch named '%s' already exists."), ref->buf + strlen("refs/heads/"));
Prevent force-updating of the current branch "git branch -M <foo> <current-branch>" allows updating the current branch which HEAD points, without the necessary house-keeping that git reset normally does to make this operation sensible. It also leaves the reflog in a confusing state (you would be warned when trying to read it). "git checkout -B <current branch> <foo>" is also partly vulnerable to this bug; due to inconsistent pre-flight checks it would perform half of its task and then abort just before rewriting the branch. Again this manifested itself as the index file getting out-of-sync with HEAD. "git branch -f" already guarded against this problem, and aborts with a fatal error. Update "git branch -M", "git checkout -B" and "git branch -f" to share the same check before allowing a branch to be created. These prevent you from updating the current branch. We considered suggesting the use of "git reset" in the failure message but concluded that it was not possible to discern what the user was actually trying to do. Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-21 05:49:48 +08:00
branch --set-upstream: regression fix The "git branch" command, while not in listing mode, calls create_branch() even when the target branch already exists, and it does so even when it is not interested in updating the value of the branch (i.e. the name of the commit object that sits at the tip of the existing branch). This happens when the command is run with "--set-upstream" option. The earlier safety-measure to prevent "git branch -f $branch $commit" from updating the currently checked out branch did not take it into account, and we no longer can update the tracking information of the current branch. Minimally fix this regression by telling the validation code if it is called to really update the value of a potentially existing branch, or if the caller merely is interested in updating auxiliary aspects of a branch. Reported-and-Tested-by: Jay Soffian Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-17 07:28:38 +08:00
if (!attr_only) {
const char *head;
unsigned char sha1[20];
Prevent force-updating of the current branch "git branch -M <foo> <current-branch>" allows updating the current branch which HEAD points, without the necessary house-keeping that git reset normally does to make this operation sensible. It also leaves the reflog in a confusing state (you would be warned when trying to read it). "git checkout -B <current branch> <foo>" is also partly vulnerable to this bug; due to inconsistent pre-flight checks it would perform half of its task and then abort just before rewriting the branch. Again this manifested itself as the index file getting out-of-sync with HEAD. "git branch -f" already guarded against this problem, and aborts with a fatal error. Update "git branch -M", "git checkout -B" and "git branch -f" to share the same check before allowing a branch to be created. These prevent you from updating the current branch. We considered suggesting the use of "git reset" in the failure message but concluded that it was not possible to discern what the user was actually trying to do. Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-21 05:49:48 +08:00
refs.c: change resolve_ref_unsafe reading argument to be a flags field resolve_ref_unsafe takes a boolean argument for reading (a nonexistent ref resolves successfully for writing but not for reading). Change this to be a flags field instead, and pass the new constant RESOLVE_REF_READING when we want this behaviour. While at it, swap two of the arguments in the function to put output arguments at the end. As a nice side effect, this ensures that we can catch callers that were unaware of the new API so they can be audited. Give the wrapper functions resolve_refdup and read_ref_full the same treatment for consistency. Signed-off-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-16 03:59:36 +08:00
head = resolve_ref_unsafe("HEAD", 0, sha1, NULL);
branch --set-upstream: regression fix The "git branch" command, while not in listing mode, calls create_branch() even when the target branch already exists, and it does so even when it is not interested in updating the value of the branch (i.e. the name of the commit object that sits at the tip of the existing branch). This happens when the command is run with "--set-upstream" option. The earlier safety-measure to prevent "git branch -f $branch $commit" from updating the currently checked out branch did not take it into account, and we no longer can update the tracking information of the current branch. Minimally fix this regression by telling the validation code if it is called to really update the value of a potentially existing branch, or if the caller merely is interested in updating auxiliary aspects of a branch. Reported-and-Tested-by: Jay Soffian Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-17 07:28:38 +08:00
if (!is_bare_repository() && head && !strcmp(head, ref->buf))
i18n: branch: mark strings for translation Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Reviewed-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-16 11:37:50 +08:00
die(_("Cannot force update the current branch."));
branch --set-upstream: regression fix The "git branch" command, while not in listing mode, calls create_branch() even when the target branch already exists, and it does so even when it is not interested in updating the value of the branch (i.e. the name of the commit object that sits at the tip of the existing branch). This happens when the command is run with "--set-upstream" option. The earlier safety-measure to prevent "git branch -f $branch $commit" from updating the currently checked out branch did not take it into account, and we no longer can update the tracking information of the current branch. Minimally fix this regression by telling the validation code if it is called to really update the value of a potentially existing branch, or if the caller merely is interested in updating auxiliary aspects of a branch. Reported-and-Tested-by: Jay Soffian Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-17 07:28:38 +08:00
}
Prevent force-updating of the current branch "git branch -M <foo> <current-branch>" allows updating the current branch which HEAD points, without the necessary house-keeping that git reset normally does to make this operation sensible. It also leaves the reflog in a confusing state (you would be warned when trying to read it). "git checkout -B <current branch> <foo>" is also partly vulnerable to this bug; due to inconsistent pre-flight checks it would perform half of its task and then abort just before rewriting the branch. Again this manifested itself as the index file getting out-of-sync with HEAD. "git branch -f" already guarded against this problem, and aborts with a fatal error. Update "git branch -M", "git checkout -B" and "git branch -f" to share the same check before allowing a branch to be created. These prevent you from updating the current branch. We considered suggesting the use of "git reset" in the failure message but concluded that it was not possible to discern what the user was actually trying to do. Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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;
struct refspec query;
memset(&query, 0, sizeof(struct refspec));
query.dst = tracking_branch;
branch.c: Relax unnecessary requirement on upstream's remote ref name When creating an upstream relationship, we use the configured remotes and their refspecs to determine the upstream configuration settings branch.<name>.remote and branch.<name>.merge. However, if the matching refspec does not have refs/heads/<something> on the remote side, we end up rejecting the match, and failing the upstream configuration. It could be argued that when we set up an branch's upstream, we want that upstream to also be a proper branch in the remote repo. Although this is typically the common case, there are cases (as demonstrated by the previous patch in this series) where this requirement prevents a useful upstream relationship from being formed. Furthermore: - We have fundamentally no say in how the remote repo have organized its branches. The remote repo may put branches (or branch-like constructs that are insteresting for downstreams to track) outside refs/heads/*. - The user may intentionally want to track a non-branch from a remote repo, by using a branch and configured upstream in the local repo. Relaxing the checking to only require a matching remote/refspec allows the testcase introduced in the previous patch to succeed, and has no negative effect on the rest of the test suite. This patch fixes a behavior (arguably a regression) first introduced in 41c21f2 (branch.c: Validate tracking branches with refspecs instead of refs/remotes/*) on 2013-04-21 (released in >= v1.8.3.2). Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09 04:58:15 +08:00
return !remote_find_tracking(remote, &query);
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);
}
branch: factor out "upstream is not a branch" error messages This message is duplicated, and is quite long. Let's factor it out, which avoids the repetition and the long lines. It will also make future patches easier as we tweak the message. While we're at it, let's also mark it for translation. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-03 03:03:55 +08:00
static const char upstream_not_branch[] =
branch: mention start_name in set-upstream error messages If we refuse a branch operation because the tracking start_name the user gave us is bogus, we just print something like: fatal: Cannot setup tracking information; start point is not a branch If we mention the actual name we tried to use, that may help the user figure out why it didn't work (e.g., if they gave us the arguments in the wrong order). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-03 03:04:51 +08:00
N_("Cannot setup tracking information; starting point '%s' is not a branch.");
branch: improve error message for missing --set-upstream-to ref If we are trying to set the upstream config for a branch, the create_branch function will check both that the name resolves as a ref, and that it is either a local or remote-tracking branch. However, before we do so we run get_sha1 on it to find out whether it resolves at all (since the create_branch function is also used to create actual branches, it wants to know where to start the new branch). This means that if you feed a ref that does not exist to "branch --set-upstream-to", rather than getting a helpful message about tracking, you only get "not a valid object name". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-03 03:04:27 +08:00
static const char upstream_missing[] =
branch: give advice when tracking start-point is missing If the user requests to --set-upstream-to a branch that does not exist, then either: 1. It was a typo. 2. They thought the branch should exist. In case (1), there is not much we can do beyond showing the name we tried to use. For case (2), though, we can help to guide them through common workflows. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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.");
branch: factor out "upstream is not a branch" error messages This message is duplicated, and is quite long. Let's factor it out, which avoids the repetition and the long lines. It will also make future patches easier as we tweak the message. While we're at it, let's also mark it for translation. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-03 03:03:55 +08:00
create_branch: drop unused "head" parameter This function used to have the caller pass in the current value of HEAD, in order to make sure we didn't clobber HEAD. In 55c4a6730, that logic moved to validate_new_branchname(), which just resolves HEAD itself. The parameter to create_branch is now unused. Since we have to update and re-wrap the docstring describing the parameters anyway, let's take this opportunity to break it out into a list, which makes it easier to find the parameters. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-05 00:30:12 +08:00
void create_branch(const char *name, const char *start_name,
Allow checkout -B <current-branch> to update the current branch When on master, "git checkout -B master <commit>" is a more natural way to say "git reset --keep <commit>", which was originally invented for the exact purpose of moving to the named commit while keeping the local changes around. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-26 16:54:55 +08:00
int force, int reflog, int clobber_head,
checkout: suppress tracking message with "-q" Like the "switched to..." message (which is already suppressed by "-q"), this message is purely informational. Let's silence it if the user asked us to be quiet. This patch is slightly more than a one-liner, because we have to teach create_branch to propagate the flag all the way down to install_branch_config. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-27 07:51:01 +08:00
int quiet, enum branch_track track)
Move create_branch into a library file You can also create branches, in exactly the same way, with checkout -b. This introduces branch.{c,h} library files for doing porcelain-level operations on branches (such as creating them with their appropriate default configuration). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-08 00:40:08 +08:00
{
struct commit *commit;
unsigned char sha1[20];
create_branch: move msg setup closer to point of use In create_branch() we write the reflog msg into a buffer in the main function, but then use it only inside a conditional. If you carefully follow the logic, you can confirm that we never use the buffer uninitialized nor write when it would not be used. But we can make this a lot more obvious by simply moving the write step inside the conditional. Signed-off-by: Jeff King <peff@peff.net>
2017-03-29 03:46:36 +08:00
char *real_ref;
Teach the "@{-1} syntax to "git branch" This teaches the new "@{-1} syntax to refer to the previous branch to "git branch". After looking at somebody's faulty patch series on a topic branch too long, if you decide it is not worth merging, you can just say: $ git checkout master $ git branch -D @{-1} to get rid of it without having to type the name of the topic you now hate so much for wasting a lot of your time. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-14 15:08:05 +08:00
struct strbuf ref = STRBUF_INIT;
Move create_branch into a library file You can also create branches, in exactly the same way, with checkout -b. This introduces branch.{c,h} library files for doing porcelain-level operations on branches (such as creating them with their appropriate default configuration). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-08 00:40:08 +08:00
int forcing = 0;
Add branch --set-upstream Add --set-upstream option to branch that works like --track, except that when branch exists already, its upstream info is changed without changing the ref value. Based-on-patch-from: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-19 04:44:11 +08:00
int dont_change_ref = 0;
int explicit_tracking = 0;
if (track == BRANCH_TRACK_EXPLICIT || track == BRANCH_TRACK_OVERRIDE)
explicit_tracking = 1;
Move create_branch into a library file You can also create branches, in exactly the same way, with checkout -b. This introduces branch.{c,h} library files for doing porcelain-level operations on branches (such as creating them with their appropriate default configuration). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-08 00:40:08 +08:00
branch --set-upstream: regression fix The "git branch" command, while not in listing mode, calls create_branch() even when the target branch already exists, and it does so even when it is not interested in updating the value of the branch (i.e. the name of the commit object that sits at the tip of the existing branch). This happens when the command is run with "--set-upstream" option. The earlier safety-measure to prevent "git branch -f $branch $commit" from updating the currently checked out branch did not take it into account, and we no longer can update the tracking information of the current branch. Minimally fix this regression by telling the validation code if it is called to really update the value of a potentially existing branch, or if the caller merely is interested in updating auxiliary aspects of a branch. Reported-and-Tested-by: Jay Soffian Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-17 07:28:38 +08:00
if (validate_new_branchname(name, &ref, force,
Allow checkout -B <current-branch> to update the current branch When on master, "git checkout -B master <commit>" is a more natural way to say "git reset --keep <commit>", which was originally invented for the exact purpose of moving to the named commit while keeping the local changes around. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-26 16:54:55 +08:00
track == BRANCH_TRACK_OVERRIDE ||
clobber_head)) {
Prevent force-updating of the current branch "git branch -M <foo> <current-branch>" allows updating the current branch which HEAD points, without the necessary house-keeping that git reset normally does to make this operation sensible. It also leaves the reflog in a confusing state (you would be warned when trying to read it). "git checkout -B <current branch> <foo>" is also partly vulnerable to this bug; due to inconsistent pre-flight checks it would perform half of its task and then abort just before rewriting the branch. Again this manifested itself as the index file getting out-of-sync with HEAD. "git branch -f" already guarded against this problem, and aborts with a fatal error. Update "git branch -M", "git checkout -B" and "git branch -f" to share the same check before allowing a branch to be created. These prevent you from updating the current branch. We considered suggesting the use of "git reset" in the failure message but concluded that it was not possible to discern what the user was actually trying to do. Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-21 05:49:48 +08:00
if (!force)
Add branch --set-upstream Add --set-upstream option to branch that works like --track, except that when branch exists already, its upstream info is changed without changing the ref value. Based-on-patch-from: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-19 04:44:11 +08:00
dont_change_ref = 1;
Prevent force-updating of the current branch "git branch -M <foo> <current-branch>" allows updating the current branch which HEAD points, without the necessary house-keeping that git reset normally does to make this operation sensible. It also leaves the reflog in a confusing state (you would be warned when trying to read it). "git checkout -B <current branch> <foo>" is also partly vulnerable to this bug; due to inconsistent pre-flight checks it would perform half of its task and then abort just before rewriting the branch. Again this manifested itself as the index file getting out-of-sync with HEAD. "git branch -f" already guarded against this problem, and aborts with a fatal error. Update "git branch -M", "git checkout -B" and "git branch -f" to share the same check before allowing a branch to be created. These prevent you from updating the current branch. We considered suggesting the use of "git reset" in the failure message but concluded that it was not possible to discern what the user was actually trying to do. Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-21 05:49:48 +08:00
else
forcing = 1;
Move create_branch into a library file You can also create branches, in exactly the same way, with checkout -b. This introduces branch.{c,h} library files for doing porcelain-level operations on branches (such as creating them with their appropriate default configuration). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-08 00:40:08 +08:00
}
real_ref = NULL;
branch: improve error message for missing --set-upstream-to ref If we are trying to set the upstream config for a branch, the create_branch function will check both that the name resolves as a ref, and that it is either a local or remote-tracking branch. However, before we do so we run get_sha1 on it to find out whether it resolves at all (since the create_branch function is also used to create actual branches, it wants to know where to start the new branch). This means that if you feed a ref that does not exist to "branch --set-upstream-to", rather than getting a helpful message about tracking, you only get "not a valid object name". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-03 03:04:27 +08:00
if (get_sha1(start_name, sha1)) {
branch: give advice when tracking start-point is missing If the user requests to --set-upstream-to a branch that does not exist, then either: 1. It was a typo. 2. They thought the branch should exist. In case (1), there is not much we can do beyond showing the name we tried to use. For case (2), though, we can help to guide them through common workflows. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-03 03:05:12 +08:00
if (explicit_tracking) {
if (advice_set_upstream_failure) {
error(_(upstream_missing), start_name);
advise(_(upstream_advice));
exit(1);
}
branch: mention start_name in set-upstream error messages If we refuse a branch operation because the tracking start_name the user gave us is bogus, we just print something like: fatal: Cannot setup tracking information; start point is not a branch If we mention the actual name we tried to use, that may help the user figure out why it didn't work (e.g., if they gave us the arguments in the wrong order). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-03 03:04:51 +08:00
die(_(upstream_missing), start_name);
branch: give advice when tracking start-point is missing If the user requests to --set-upstream-to a branch that does not exist, then either: 1. It was a typo. 2. They thought the branch should exist. In case (1), there is not much we can do beyond showing the name we tried to use. For case (2), though, we can help to guide them through common workflows. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-03 03:05:12 +08:00
}
i18n: branch: mark strings for translation Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Reviewed-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-16 11:37:50 +08:00
die(_("Not a valid object name: '%s'."), start_name);
branch: improve error message for missing --set-upstream-to ref If we are trying to set the upstream config for a branch, the create_branch function will check both that the name resolves as a ref, and that it is either a local or remote-tracking branch. However, before we do so we run get_sha1 on it to find out whether it resolves at all (since the create_branch function is also used to create actual branches, it wants to know where to start the new branch). This means that if you feed a ref that does not exist to "branch --set-upstream-to", rather than getting a helpful message about tracking, you only get "not a valid object name". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-03 03:04:27 +08:00
}
Move create_branch into a library file You can also create branches, in exactly the same way, with checkout -b. This introduces branch.{c,h} library files for doing porcelain-level operations on branches (such as creating them with their appropriate default configuration). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-08 00:40:08 +08:00
switch (dwim_ref(start_name, strlen(start_name), sha1, &real_ref)) {
case 0:
/* Not branching from any existing branch */
Add branch --set-upstream Add --set-upstream option to branch that works like --track, except that when branch exists already, its upstream info is changed without changing the ref value. Based-on-patch-from: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-19 04:44:11 +08:00
if (explicit_tracking)
branch: mention start_name in set-upstream error messages If we refuse a branch operation because the tracking start_name the user gave us is bogus, we just print something like: fatal: Cannot setup tracking information; start point is not a branch If we mention the actual name we tried to use, that may help the user figure out why it didn't work (e.g., if they gave us the arguments in the wrong order). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-03 03:04:51 +08:00
die(_(upstream_not_branch), start_name);
Move create_branch into a library file You can also create branches, in exactly the same way, with checkout -b. This introduces branch.{c,h} library files for doing porcelain-level operations on branches (such as creating them with their appropriate default configuration). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-08 00:40:08 +08:00
break;
case 1:
branch/checkout --track: Ensure that upstream branch is indeed a branch When creating a new branch using the --track option, we must make sure that we don't try to set an upstream that does not make sense to follow (using 'git pull') or update (using 'git push'). The current code checks against using HEAD as upstream (since tracking a symref doesn't make sense). However, tracking a tag doesn't make sense either. Indeed, tracking _any_ ref that is not a (local or remote) branch doesn't make sense, and should be disallowed. This patch achieves this by checking that the ref we're trying to --track resides within refs/heads/* or refs/remotes/*. This new check replaces the previous check against HEAD. A couple of testcases are also added, verifying that we cannot create branches with tags as upstreams. Finally, some selftests relying on using a non-branch as an upstream have been reworked or removed: - t6040: Reverse the meaning of two tests that depend on the ability to use (lightweight and annotated) tags as upstreams. These two tests were originally added in commits 1be570f and 57ffc5f, and this patch reverts the intention of those two commits. - t7201: Remove part of a test (introduced in 9188ed8) relying on a non-branch as upstream. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-17 07:12:20 +08:00
/* Unique completion -- good, only if it is a real branch */
replace {pre,suf}fixcmp() with {starts,ends}_with() Leaving only the function definitions and declarations so that any new topic in flight can still make use of the old functions, replace existing uses of the prefixcmp() and suffixcmp() with new API functions. The change can be recreated by mechanically applying this: $ git grep -l -e prefixcmp -e suffixcmp -- \*.c | grep -v strbuf\\.c | xargs perl -pi -e ' s|!prefixcmp\(|starts_with\(|g; s|prefixcmp\(|!starts_with\(|g; s|!suffixcmp\(|ends_with\(|g; s|suffixcmp\(|!ends_with\(|g; ' on the result of preparatory changes in this series. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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)) {
branch/checkout --track: Ensure that upstream branch is indeed a branch When creating a new branch using the --track option, we must make sure that we don't try to set an upstream that does not make sense to follow (using 'git pull') or update (using 'git push'). The current code checks against using HEAD as upstream (since tracking a symref doesn't make sense). However, tracking a tag doesn't make sense either. Indeed, tracking _any_ ref that is not a (local or remote) branch doesn't make sense, and should be disallowed. This patch achieves this by checking that the ref we're trying to --track resides within refs/heads/* or refs/remotes/*. This new check replaces the previous check against HEAD. A couple of testcases are also added, verifying that we cannot create branches with tags as upstreams. Finally, some selftests relying on using a non-branch as an upstream have been reworked or removed: - t6040: Reverse the meaning of two tests that depend on the ability to use (lightweight and annotated) tags as upstreams. These two tests were originally added in commits 1be570f and 57ffc5f, and this patch reverts the intention of those two commits. - t7201: Remove part of a test (introduced in 9188ed8) relying on a non-branch as upstream. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-17 07:12:20 +08:00
if (explicit_tracking)
branch: mention start_name in set-upstream error messages If we refuse a branch operation because the tracking start_name the user gave us is bogus, we just print something like: fatal: Cannot setup tracking information; start point is not a branch If we mention the actual name we tried to use, that may help the user figure out why it didn't work (e.g., if they gave us the arguments in the wrong order). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-03 03:04:51 +08:00
die(_(upstream_not_branch), start_name);
branch/checkout --track: Ensure that upstream branch is indeed a branch When creating a new branch using the --track option, we must make sure that we don't try to set an upstream that does not make sense to follow (using 'git pull') or update (using 'git push'). The current code checks against using HEAD as upstream (since tracking a symref doesn't make sense). However, tracking a tag doesn't make sense either. Indeed, tracking _any_ ref that is not a (local or remote) branch doesn't make sense, and should be disallowed. This patch achieves this by checking that the ref we're trying to --track resides within refs/heads/* or refs/remotes/*. This new check replaces the previous check against HEAD. A couple of testcases are also added, verifying that we cannot create branches with tags as upstreams. Finally, some selftests relying on using a non-branch as an upstream have been reworked or removed: - t6040: Reverse the meaning of two tests that depend on the ability to use (lightweight and annotated) tags as upstreams. These two tests were originally added in commits 1be570f and 57ffc5f, and this patch reverts the intention of those two commits. - t7201: Remove part of a test (introduced in 9188ed8) relying on a non-branch as upstream. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-17 07:12:20 +08:00
else
real_ref = NULL;
}
Move create_branch into a library file You can also create branches, in exactly the same way, with checkout -b. This introduces branch.{c,h} library files for doing porcelain-level operations on branches (such as creating them with their appropriate default configuration). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-08 00:40:08 +08:00
break;
default:
i18n: branch: mark strings for translation Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Reviewed-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-16 11:37:50 +08:00
die(_("Ambiguous object name: '%s'."), start_name);
Move create_branch into a library file You can also create branches, in exactly the same way, with checkout -b. This introduces branch.{c,h} library files for doing porcelain-level operations on branches (such as creating them with their appropriate default configuration). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-08 00:40:08 +08:00
break;
}
if ((commit = lookup_commit_reference(sha1)) == NULL)
i18n: branch: mark strings for translation Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Reviewed-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-16 11:37:50 +08:00
die(_("Not a valid branch point: '%s'."), start_name);
Remove get_object_hash. Convert all instances of get_object_hash to use an appropriate reference to the hash member of the oid member of struct object. This provides no functional change, as it is essentially a macro substitution. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Jeff King <peff@peff.net>
2015-11-10 10:22:29 +08:00
hashcpy(sha1, commit->object.oid.hash);
Move create_branch into a library file You can also create branches, in exactly the same way, with checkout -b. This introduces branch.{c,h} library files for doing porcelain-level operations on branches (such as creating them with their appropriate default configuration). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-08 00:40:08 +08:00
branch.c: use ref transaction for all ref updates Change create_branch to use a ref transaction when creating the new branch. This also fixes a race condition in the old code where two concurrent create_branch could race since the lock_any_ref_for_update/write_ref_sha1 did not protect against the ref already existing. I.e. one thread could end up overwriting a branch even if the forcing flag is false. Signed-off-by: Ronnie Sahlberg <sahlberg@google.com> Reviewed-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-17 07:21:53 +08:00
if (reflog)
refs: add option core.logAllRefUpdates = always When core.logallrefupdates is true, we only create a new reflog for refs that are under certain well-known hierarchies. The reason is that we know that some hierarchies (like refs/tags) are not meant to change, and that unknown hierarchies might not want reflogs at all (e.g., a hypothetical refs/foo might be meant to change often and drop old history immediately). However, sometimes it is useful to override this decision and simply log for all refs, because the safety and audit trail is more important than the performance implications of keeping the log around. This patch introduces a new "always" mode for the core.logallrefupdates option which will log updates to everything under refs/, regardless where in the hierarchy it is (we still will not log things like ORIG_HEAD and FETCH_HEAD, which are known to be transient). Based-on-patch-by: Jeff King <peff@peff.net> Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-27 18:09:47 +08:00
log_all_ref_updates = LOG_REFS_NORMAL;
branch.c: use ref transaction for all ref updates Change create_branch to use a ref transaction when creating the new branch. This also fixes a race condition in the old code where two concurrent create_branch could race since the lock_any_ref_for_update/write_ref_sha1 did not protect against the ref already existing. I.e. one thread could end up overwriting a branch even if the forcing flag is false. Signed-off-by: Ronnie Sahlberg <sahlberg@google.com> Reviewed-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-17 07:21:53 +08:00
if (!dont_change_ref) {
struct ref_transaction *transaction;
struct strbuf err = STRBUF_INIT;
create_branch: use xstrfmt for reflog message We generate a reflog message that contains some fixed text plus a branch name, and use a buffer of size PATH_MAX + 20. This mostly works if you assume that refnames are shorter than PATH_MAX, but: 1. That's not necessarily true. PATH_MAX is not always the filesystem's limit. 2. The "20" is not sufficiently large for the fixed text anyway. Let's just switch to a heap buffer so we don't have to even care. Signed-off-by: Jeff King <peff@peff.net>
2017-03-29 03:46:40 +08:00
char *msg;
create_branch: move msg setup closer to point of use In create_branch() we write the reflog msg into a buffer in the main function, but then use it only inside a conditional. If you carefully follow the logic, you can confirm that we never use the buffer uninitialized nor write when it would not be used. But we can make this a lot more obvious by simply moving the write step inside the conditional. Signed-off-by: Jeff King <peff@peff.net>
2017-03-29 03:46:36 +08:00
if (forcing)
create_branch: use xstrfmt for reflog message We generate a reflog message that contains some fixed text plus a branch name, and use a buffer of size PATH_MAX + 20. This mostly works if you assume that refnames are shorter than PATH_MAX, but: 1. That's not necessarily true. PATH_MAX is not always the filesystem's limit. 2. The "20" is not sufficiently large for the fixed text anyway. Let's just switch to a heap buffer so we don't have to even care. Signed-off-by: Jeff King <peff@peff.net>
2017-03-29 03:46:40 +08:00
msg = xstrfmt("branch: Reset to %s", start_name);
create_branch: move msg setup closer to point of use In create_branch() we write the reflog msg into a buffer in the main function, but then use it only inside a conditional. If you carefully follow the logic, you can confirm that we never use the buffer uninitialized nor write when it would not be used. But we can make this a lot more obvious by simply moving the write step inside the conditional. Signed-off-by: Jeff King <peff@peff.net>
2017-03-29 03:46:36 +08:00
else
create_branch: use xstrfmt for reflog message We generate a reflog message that contains some fixed text plus a branch name, and use a buffer of size PATH_MAX + 20. This mostly works if you assume that refnames are shorter than PATH_MAX, but: 1. That's not necessarily true. PATH_MAX is not always the filesystem's limit. 2. The "20" is not sufficiently large for the fixed text anyway. Let's just switch to a heap buffer so we don't have to even care. Signed-off-by: Jeff King <peff@peff.net>
2017-03-29 03:46:40 +08:00
msg = xstrfmt("branch: Created from %s", start_name);
branch.c: use ref transaction for all ref updates Change create_branch to use a ref transaction when creating the new branch. This also fixes a race condition in the old code where two concurrent create_branch could race since the lock_any_ref_for_update/write_ref_sha1 did not protect against the ref already existing. I.e. one thread could end up overwriting a branch even if the forcing flag is false. Signed-off-by: Ronnie Sahlberg <sahlberg@google.com> Reviewed-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-17 07:21:53 +08:00
transaction = ref_transaction_begin(&err);
if (!transaction ||
ref_transaction_update(): remove "have_old" parameter Instead, verify the reference's old value if and only if old_sha1 is non-NULL. ref_transaction_delete() will get the same treatment in a moment. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-18 01:00:15 +08:00
ref_transaction_update(transaction, ref.buf,
sha1, forcing ? NULL : null_sha1,
0, msg, &err) ||
refs.c: pass the ref log message to _create/delete/update instead of _commit Change the ref transaction API so that we pass the reflog message to the create/delete/update functions instead of to ref_transaction_commit. This allows different reflog messages for each ref update in a multi-ref transaction. Signed-off-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-01 03:22:42 +08:00
ref_transaction_commit(transaction, &err))
branch.c: use ref transaction for all ref updates Change create_branch to use a ref transaction when creating the new branch. This also fixes a race condition in the old code where two concurrent create_branch could race since the lock_any_ref_for_update/write_ref_sha1 did not protect against the ref already existing. I.e. one thread could end up overwriting a branch even if the forcing flag is false. Signed-off-by: Ronnie Sahlberg <sahlberg@google.com> Reviewed-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-17 07:21:53 +08:00
die("%s", err.buf);
ref_transaction_free(transaction);
strbuf_release(&err);
create_branch: use xstrfmt for reflog message We generate a reflog message that contains some fixed text plus a branch name, and use a buffer of size PATH_MAX + 20. This mostly works if you assume that refnames are shorter than PATH_MAX, but: 1. That's not necessarily true. PATH_MAX is not always the filesystem's limit. 2. The "20" is not sufficiently large for the fixed text anyway. Let's just switch to a heap buffer so we don't have to even care. Signed-off-by: Jeff King <peff@peff.net>
2017-03-29 03:46:40 +08:00
free(msg);
branch.c: use ref transaction for all ref updates Change create_branch to use a ref transaction when creating the new branch. This also fixes a race condition in the old code where two concurrent create_branch could race since the lock_any_ref_for_update/write_ref_sha1 did not protect against the ref already existing. I.e. one thread could end up overwriting a branch even if the forcing flag is false. Signed-off-by: Ronnie Sahlberg <sahlberg@google.com> Reviewed-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-17 07:21:53 +08:00
}
Move create_branch into a library file You can also create branches, in exactly the same way, with checkout -b. This introduces branch.{c,h} library files for doing porcelain-level operations on branches (such as creating them with their appropriate default configuration). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-08 00:40:08 +08:00
if (real_ref && track)
branch: trivial style fix Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-31 05:56:46 +08:00
setup_tracking(ref.buf + 11, real_ref, track, quiet);
Move create_branch into a library file You can also create branches, in exactly the same way, with checkout -b. This introduces branch.{c,h} library files for doing porcelain-level operations on branches (such as creating them with their appropriate default configuration). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-08 00:40:08 +08:00
Teach the "@{-1} syntax to "git branch" This teaches the new "@{-1} syntax to refer to the previous branch to "git branch". After looking at somebody's faulty patch series on a topic branch too long, if you decide it is not worth merging, you can just say: $ git checkout master $ git branch -D @{-1} to get rid of it without having to type the name of the topic you now hate so much for wasting a lot of your time. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-14 15:08:05 +08:00
strbuf_release(&ref);
branch: optionally setup branch.*.merge from upstream local branches "git branch" and "git checkout -b" now honor --track option even when the upstream branch is local. Previously --track was silently ignored when forking from a local branch. Also the command did not error out when --track was explicitly asked for but the forked point specified was not an existing branch (i.e. when there is no way to set up the tracking configuration), but now it correctly does. The configuration setting branch.autosetupmerge can now be set to "always", which is equivalent to using --track from the command line. Setting branch.autosetupmerge to "true" will retain the former behavior of only setting up branch.*.merge for remote upstream branches. Includes test cases for the new functionality. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-20 00:24:37 +08:00
free(real_ref);
Move create_branch into a library file You can also create branches, in exactly the same way, with checkout -b. This introduces branch.{c,h} library files for doing porcelain-level operations on branches (such as creating them with their appropriate default configuration). Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-08 00:40:08 +08:00
}
Move code to clean up after a branch change to branch.c Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-08 00:40:16 +08:00
void remove_branch_state(void)
{
memoize common git-path "constant" files One of the most common uses of git_path() is to pass a constant, like git_path("MERGE_MSG"). This has two drawbacks: 1. The return value is a static buffer, and the lifetime is dependent on other calls to git_path, etc. 2. There's no compile-time checking of the pathname. This is OK for a one-off (after all, we have to spell it correctly at least once), but many of these constant strings appear throughout the code. This patch introduces a series of functions to "memoize" these strings, which are essentially globals for the lifetime of the program. We compute the value once, take ownership of the buffer, and return the cached value for subsequent calls. cache.h provides a helper macro for defining these functions as one-liners, and defines a few common ones for global use. Using a macro is a little bit gross, but it does nicely document the purpose of the functions. If we need to touch them all later (e.g., because we learned how to change the git_dir variable at runtime, and need to invalidate all of the stored values), it will be much easier to have the complete list. Note that the shared-global functions have separate, manual declarations. We could do something clever with the macros (e.g., expand it to a declaration in some places, and a declaration _and_ a definition in path.c). But there aren't that many, and it's probably better to stay away from too-magical macros. Likewise, if we abandon the C preprocessor in favor of generating these with a script, we could get much fancier. E.g., normalizing "FOO/BAR-BAZ" into "git_path_foo_bar_baz". But the small amount of saved typing is probably not worth the resulting confusion to readers who want to grep for the function's definition. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10 17:38:57 +08:00
unlink(git_path_cherry_pick_head());
unlink(git_path_revert_head());
unlink(git_path_merge_head());
unlink(git_path_merge_rr());
unlink(git_path_merge_msg());
unlink(git_path_merge_mode());
unlink(git_path_squash_msg());
Move code to clean up after a branch change to branch.c Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-08 00:40:16 +08:00
}
branch: publish die_if_checked_out() git-worktree currently conflates new branch creation, setting of HEAD in the new wortkree, and worktree population into a single sub-invocation of git-checkout. However, these operations will eventually be separated, and git-worktree itself will need to be able to detect if the branch is already checked out elsewhere, rather than relying upon git-branch to make this determination, so publish die_if_checked_out(). Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-18 07:00:04 +08:00
worktree.c: check whether branch is rebased in another worktree This function find_shared_symref() is used in a couple places: 1) in builtin/branch.c: it's used to detect if a branch is checked out elsewhere and refuse to delete the branch. 2) in builtin/notes.c: it's used to detect if a note is being merged in another worktree 3) in branch.c, the function die_if_checked_out() is actually used by "git checkout" and "git worktree add" to see if a branch is already checked out elsewhere and refuse the operation. In cases 1 and 3, if a rebase is ongoing, "HEAD" will be in detached mode, find_shared_symref() fails to detect it and declares "no branch is checked out here", which is not really what we want. This patch tightens the test. If the given symref is "HEAD", we try to detect if rebase is ongoing. If so return the branch being rebased. This makes checkout and branch delete operations safer because you can't checkout a branch being rebased in another place, or delete it. Special case for checkout. If the current branch is being rebased, git-rebase.sh may use "git checkout" to abort and return back to the original branch. The updated test in find_shared_symref() will prevent that and "git rebase --abort" will fail as a result. find_shared_symref() and die_if_checked_out() have to learn a new option ignore_current_worktree to loosen the test a bit. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-22 21:01:33 +08:00
void die_if_checked_out(const char *branch, int ignore_current_worktree)
worktrees: add find_shared_symref Add a new function, find_shared_symref, which contains the heart of die_if_checked_out, but works for any symref, not just HEAD. Refactor die_if_checked_out to use the same infrastructure as find_shared_symref. Soon, we will use find_shared_symref to protect notes merges in worktrees. Signed-off-by: David Turner <dturner@twopensource.com> Reviewed-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-11 01:52:44 +08:00
{
worktree.c: make find_shared_symref() return struct worktree * This gives the caller more information and they can answer things like, "is it the main worktree" or "is it the current worktree". The latter question is needed for the "checkout a rebase branch" case later. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-22 21:01:27 +08:00
const struct worktree *wt;
worktrees: add find_shared_symref Add a new function, find_shared_symref, which contains the heart of die_if_checked_out, but works for any symref, not just HEAD. Refactor die_if_checked_out to use the same infrastructure as find_shared_symref. Soon, we will use find_shared_symref to protect notes merges in worktrees. Signed-off-by: David Turner <dturner@twopensource.com> Reviewed-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-11 01:52:44 +08:00
worktree.c: make find_shared_symref() return struct worktree * This gives the caller more information and they can answer things like, "is it the main worktree" or "is it the current worktree". The latter question is needed for the "checkout a rebase branch" case later. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-22 21:01:27 +08:00
wt = find_shared_symref("HEAD", branch);
worktree.c: check whether branch is rebased in another worktree This function find_shared_symref() is used in a couple places: 1) in builtin/branch.c: it's used to detect if a branch is checked out elsewhere and refuse to delete the branch. 2) in builtin/notes.c: it's used to detect if a note is being merged in another worktree 3) in branch.c, the function die_if_checked_out() is actually used by "git checkout" and "git worktree add" to see if a branch is already checked out elsewhere and refuse the operation. In cases 1 and 3, if a rebase is ongoing, "HEAD" will be in detached mode, find_shared_symref() fails to detect it and declares "no branch is checked out here", which is not really what we want. This patch tightens the test. If the given symref is "HEAD", we try to detect if rebase is ongoing. If so return the branch being rebased. This makes checkout and branch delete operations safer because you can't checkout a branch being rebased in another place, or delete it. Special case for checkout. If the current branch is being rebased, git-rebase.sh may use "git checkout" to abort and return back to the original branch. The updated test in find_shared_symref() will prevent that and "git rebase --abort" will fail as a result. find_shared_symref() and die_if_checked_out() have to learn a new option ignore_current_worktree to loosen the test a bit. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-22 21:01:33 +08:00
if (!wt || (ignore_current_worktree && wt->is_current))
worktree.c: make find_shared_symref() return struct worktree * This gives the caller more information and they can answer things like, "is it the main worktree" or "is it the current worktree". The latter question is needed for the "checkout a rebase branch" case later. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-22 21:01:27 +08:00
return;
skip_prefix(branch, "refs/heads/", &branch);
die(_("'%s' is already checked out at '%s'"),
branch, wt->path);
branch: publish die_if_checked_out() git-worktree currently conflates new branch creation, setting of HEAD in the new wortkree, and worktree population into a single sub-invocation of git-checkout. However, these operations will eventually be separated, and git-worktree itself will need to be able to detect if the branch is already checked out elsewhere, rather than relying upon git-branch to make this determination, so publish die_if_checked_out(). Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-18 07:00:04 +08:00
}
branch -m: update all per-worktree HEADs When renaming a branch, currently only the HEAD of current working tree is updated, but it must update HEADs of all working trees which point at the old branch. This is the current behavior, /path/to/wt's HEAD is not updated: % git worktree list /path/to 2c3c5f2 [master] /path/to/wt 2c3c5f2 [oldname] % git branch -m master master2 % git worktree list /path/to 2c3c5f2 [master2] /path/to/wt 2c3c5f2 [oldname] % git branch -m oldname newname % git worktree list /path/to 2c3c5f2 [master2] /path/to/wt 0000000 [oldname] This patch fixes this issue by updating all relevant worktree HEADs when renaming a branch. Signed-off-by: Kazuki Yamaguchi <k@rhe.jp> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-27 22:37:14 +08:00
branch: record creation of renamed branch in HEAD's log Renaming the current branch adds an event to the current branch's log and to HEAD's log. However, the logged entries differ. The entry in the branch's log represents the entire renaming operation (the old and new hash are identical), whereas the entry in HEAD's log represents the deletion only (the new sha1 is null). Extend replace_each_worktree_head_symref(), whose only caller is branch_rename(), to take a reflog message argument. This allows the creation of the new ref to be recorded in HEAD's log. As a result, the renaming event is represented by two entries (a deletion and a creation entry) in HEAD's log. It's a bit unfortunate that the branch's log and HEAD's log now represent the renaming event in different ways. Given that the renaming operation is not atomic, the two-entry form is a more accurate representation of the operation and is more useful for debugging purposes if a failure occurs between the deletion and creation events. It would make sense to move the branch's log to the two-entry form, but this would involve changes to how the rename is carried out and to how the update flags and reflogs are processed for deletions, so it may not be worth the effort. Based-on-patch-by: Jeff King <peff@peff.net> Signed-off-by: Kyle Meyer <kyle@kyleam.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-21 09:10:35 +08:00
int replace_each_worktree_head_symref(const char *oldref, const char *newref,
const char *logmsg)
branch -m: update all per-worktree HEADs When renaming a branch, currently only the HEAD of current working tree is updated, but it must update HEADs of all working trees which point at the old branch. This is the current behavior, /path/to/wt's HEAD is not updated: % git worktree list /path/to 2c3c5f2 [master] /path/to/wt 2c3c5f2 [oldname] % git branch -m master master2 % git worktree list /path/to 2c3c5f2 [master2] /path/to/wt 2c3c5f2 [oldname] % git branch -m oldname newname % git worktree list /path/to 2c3c5f2 [master2] /path/to/wt 0000000 [oldname] This patch fixes this issue by updating all relevant worktree HEADs when renaming a branch. Signed-off-by: Kazuki Yamaguchi <k@rhe.jp> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-27 22:37:14 +08:00
{
int ret = 0;
worktree.c: get_worktrees() takes a new flag argument This is another no-op patch, in preparation for get_worktrees() to do optional things, like sorting. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-28 17:36:55 +08:00
struct worktree **worktrees = get_worktrees(0);
branch -m: update all per-worktree HEADs When renaming a branch, currently only the HEAD of current working tree is updated, but it must update HEADs of all working trees which point at the old branch. This is the current behavior, /path/to/wt's HEAD is not updated: % git worktree list /path/to 2c3c5f2 [master] /path/to/wt 2c3c5f2 [oldname] % git branch -m master master2 % git worktree list /path/to 2c3c5f2 [master2] /path/to/wt 2c3c5f2 [oldname] % git branch -m oldname newname % git worktree list /path/to 2c3c5f2 [master2] /path/to/wt 0000000 [oldname] This patch fixes this issue by updating all relevant worktree HEADs when renaming a branch. Signed-off-by: Kazuki Yamaguchi <k@rhe.jp> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-27 22:37:14 +08:00
int i;
for (i = 0; worktrees[i]; i++) {
if (worktrees[i]->is_detached)
continue;
if (strcmp(oldref, worktrees[i]->head_ref))
continue;
worktree.c: store "id" instead of "git_dir" We can reconstruct git_dir from id quite easily. It's a bit hackier to do the reverse. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-22 21:01:26 +08:00
if (set_worktree_head_symref(get_worktree_git_dir(worktrees[i]),
branch: record creation of renamed branch in HEAD's log Renaming the current branch adds an event to the current branch's log and to HEAD's log. However, the logged entries differ. The entry in the branch's log represents the entire renaming operation (the old and new hash are identical), whereas the entry in HEAD's log represents the deletion only (the new sha1 is null). Extend replace_each_worktree_head_symref(), whose only caller is branch_rename(), to take a reflog message argument. This allows the creation of the new ref to be recorded in HEAD's log. As a result, the renaming event is represented by two entries (a deletion and a creation entry) in HEAD's log. It's a bit unfortunate that the branch's log and HEAD's log now represent the renaming event in different ways. Given that the renaming operation is not atomic, the two-entry form is a more accurate representation of the operation and is more useful for debugging purposes if a failure occurs between the deletion and creation events. It would make sense to move the branch's log to the two-entry form, but this would involve changes to how the rename is carried out and to how the update flags and reflogs are processed for deletions, so it may not be worth the effort. Based-on-patch-by: Jeff King <peff@peff.net> Signed-off-by: Kyle Meyer <kyle@kyleam.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-21 09:10:35 +08:00
newref, logmsg)) {
branch -m: update all per-worktree HEADs When renaming a branch, currently only the HEAD of current working tree is updated, but it must update HEADs of all working trees which point at the old branch. This is the current behavior, /path/to/wt's HEAD is not updated: % git worktree list /path/to 2c3c5f2 [master] /path/to/wt 2c3c5f2 [oldname] % git branch -m master master2 % git worktree list /path/to 2c3c5f2 [master2] /path/to/wt 2c3c5f2 [oldname] % git branch -m oldname newname % git worktree list /path/to 2c3c5f2 [master2] /path/to/wt 0000000 [oldname] This patch fixes this issue by updating all relevant worktree HEADs when renaming a branch. Signed-off-by: Kazuki Yamaguchi <k@rhe.jp> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-27 22:37:14 +08:00
ret = -1;
error(_("HEAD of working tree %s is not updated"),
worktrees[i]->path);
}
}
free_worktrees(worktrees);
return ret;
}
Reference in New Issue Copy Permalink