mirrors/git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-15 05:33:04 +01:00
Code Activity
git/branch.c

312 lines
7.9 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 07:43:33 +01: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-07 17:40:08 +01:00
#include "cache.h"
#include "branch.h"
#include "refs.h"
#include "remote.h"
#include "commit.h"
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 07:29:55 +01: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 00:36:29 +02: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 07:29:55 +01: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 00:36:29 +02: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 07:29:55 +01: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 00:36:29 +02:00
case AUTOREBASE_ALWAYS:
return 1;
}
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 07:29:55 +01:00
void install_branch_config(int flag, const char *local, const char *origin, const char *remote)
{
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-18 21:44:19 +02: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 07:29:55 +01: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-18 21:44:19 +02: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-18 21:44:12 +01: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 05:37:50 +02: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-18 21:44:12 +01:00
local);
return;
}
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 07:29:55 +01:00
strbuf_addf(&key, "branch.%s.remote", local);
git_config_set(key.buf, origin ? origin : ".");
strbuf_reset(&key);
strbuf_addf(&key, "branch.%s.merge", local);
git_config_set(key.buf, remote);
if (rebasing) {
strbuf_reset(&key);
strbuf_addf(&key, "branch.%s.rebase", local);
git_config_set(key.buf, "true");
}
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 14:05:10 +02: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 07:29:55 +01: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 09:20:42 +01: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 01:31:19 +02: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 06:32:01 +01: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 09:20:42 +01: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 07:29:55 +01: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-07 17:40:08 +01: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: 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-19 17:24:37 +01:00
static int setup_tracking(const char *new_ref, const char *orig_ref,
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 01:51:01 +02:00
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-07 17:40:08 +01: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 01:51:01 +02: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-07 17:40:08 +01: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-19 17:24:37 +01:00
if (for_each_remote(find_tracked_branch, &tracking))
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-07 17:40:08 +01:00
return 1;
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-19 17:24:37 +01: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-18 21:44:11 +01: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-19 17:24:37 +01:00
break;
default:
return 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-07 17:40:08 +01:00
if (tracking.matches > 1)
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 05:37:50 +02:00
return error(_("Not tracking: ambiguous information for ref %s"),
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-07 17:40:08 +01:00
orig_ref);
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 01:51:01 +02:00
install_branch_config(config_flags, new_ref, tracking.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 07:29:55 +01:00
tracking.src ? tracking.src : 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-07 17:40:08 +01: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 07:29:55 +01: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-07 17:40:08 +01:00
return 0;
}
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 05:19:38 +02: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-07 19:56:42 +02: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 05:19:38 +02: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-07 19:56:42 +02: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 05:19:38 +02: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 01:28:38 +02: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-20 23:49:48 +02: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 05:37:50 +02: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-20 23:49:48 +02: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 01:28:38 +02: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 05:37:50 +02: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-20 23:49:48 +02: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 01:28:38 +02: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-20 23:49:48 +02:00
Rename resolve_ref() to resolve_ref_unsafe() resolve_ref() may return a pointer to a shared buffer and can be overwritten by the next resolve_ref() calls. Callers need to pay attention, not to keep the pointer when the next call happens. Rename with "_unsafe" suffix to warn developers (or reviewers) before introducing new call sites. This patch is generated using the following command git grep -l 'resolve_ref(' -- '*.[ch]'|xargs sed -i 's/resolve_ref(/resolve_ref_unsafe(/g' Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12 12:20:32 +01:00
head = resolve_ref_unsafe("HEAD", sha1, 0, 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 01:28:38 +02: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 05:37:50 +02: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 01:28:38 +02: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-20 23:49:48 +02: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-21 23:52:05 +02: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-08 22:58:15 +02: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-21 23:52:05 +02: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-02 21:03:55 +02: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-02 21:04:51 +02: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-02 21:04:27 +02: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-02 21:05:12 +02: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-02 21:03:55 +02: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-07 17:40:08 +01:00
void create_branch(const char *head,
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 09:54:55 +01: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 01:51:01 +02: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-07 17:40:08 +01:00
{
struct commit *commit;
unsigned char sha1[20];
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 08:08:05 +01:00
char *real_ref, msg[PATH_MAX + 20];
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-07 17:40:08 +01: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-18 21:44:11 +01: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-07 17:40:08 +01: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 01:28:38 +02: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 09:54:55 +01: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-20 23:49:48 +02: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-18 21:44:11 +01: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-20 23:49:48 +02: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-07 17:40:08 +01: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-02 21:04:27 +02: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-02 21:05:12 +02: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-02 21:04:51 +02: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-02 21:05:12 +02: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 05:37:50 +02: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-02 21:04:27 +02: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-07 17:40:08 +01: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-18 21:44:11 +01: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-02 21:04:51 +02: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-07 17:40:08 +01: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 00:12:20 +01: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-11-30 21:55:40 +01: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-21 23:52:05 +02: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 00:12:20 +01: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-02 21:04:51 +02: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 00:12:20 +01: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-07 17:40:08 +01: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 05:37:50 +02: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-07 17:40:08 +01: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 05:37:50 +02:00
die(_("Not a valid branch point: '%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-07 17:40:08 +01:00
hashcpy(sha1, commit->object.sha1);
if (forcing)
Merge branch 'rc/maint-reflog-msg-for-forced-branch' * rc/maint-reflog-msg-for-forced-branch: branch: say "Reset to" in reflog entries for 'git branch -f' operations Conflicts: builtin-branch.c
2010-04-10 05:42:10 +02:00
snprintf(msg, sizeof msg, "branch: Reset to %s",
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-07 17:40:08 +01:00
start_name);
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-18 21:44:11 +01:00
else if (!dont_change_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-07 17:40:08 +01:00
snprintf(msg, sizeof msg, "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 01:21:53 +02:00
if (reflog)
log_all_ref_updates = 1;
if (!dont_change_ref) {
struct ref_transaction *transaction;
struct strbuf err = STRBUF_INIT;
transaction = ref_transaction_begin(&err);
if (!transaction ||
ref_transaction_update(transaction, ref.buf, sha1,
null_sha1, 0, !forcing, &err) ||
ref_transaction_commit(transaction, msg, &err))
die("%s", err.buf);
ref_transaction_free(transaction);
strbuf_release(&err);
}
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-07 17:40:08 +01: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-30 23:56:46 +02: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-07 17:40:08 +01: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 08:08:05 +01: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-19 17:24:37 +01: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-07 17:40:08 +01:00
}
Move code to clean up after a branch change to branch.c Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-07 17:40:16 +01:00
void remove_branch_state(void)
{
Introduce CHERRY_PICK_HEAD When a cherry-pick conflicts git advises: $ git commit -c <original commit id> to preserve the original commit message and authorship. Instead, let's record the original commit id in CHERRY_PICK_HEAD and advise: $ git commit -c CHERRY_PICK_HEAD A later patch teaches git to handle the '-c CHERRY_PICK_HEAD' part. Note that we record CHERRY_PICK_HEAD even in the case where there are no conflicts so that we may use it to communicate authorship to commit; this will then allow us to remove set_author_ident_env from revert.c. However, we do not record CHERRY_PICK_HEAD when --no-commit is used, as presumably the user intends to further edit the commit and possibly even cherry-pick additional commits on top. Tests and documentation contributed by Jonathan Nieder. Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-20 05:12:27 +01:00
unlink(git_path("CHERRY_PICK_HEAD"));
revert: write REVERT_HEAD pseudoref during conflicted revert When conflicts are encountered while reverting a commit, it can be handy to have the name of that commit easily available. For example, to produce a copy of the patch to refer to while resolving conflicts: $ git revert 2eceb2a8 error: could not revert 2eceb2a8... awesome, buggy feature $ git show -R REVERT_HEAD >the-patch $ edit $(git diff --name-only) Set a REVERT_HEAD pseudoref when "git revert" does not make a commit, for cases like this. This also makes it possible for scripts to distinguish between a revert that encountered conflicts and other sources of an unmerged index. After successfully committing, resetting with "git reset", or moving to another commit with "git checkout" or "git reset", the pseudoref is no longer useful, so remove it. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-22 12:17:36 +01:00
unlink(git_path("REVERT_HEAD"));
Move code to clean up after a branch change to branch.c Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-07 17:40:16 +01:00
unlink(git_path("MERGE_HEAD"));
Move MERGE_RR from .git/rr-cache/ into .git/ If you want to reuse the rerere cache in another repository, and set a symbolic link to it, you do not want to have the two repositories interfer with each other by accessing the _same_ MERGE_RR. For example, if you use contrib/git-new-workdir to set up a second working directory, and you have a conflict in one working directory, but commit in the other working directory first, the wrong "resolution" will be recorded. The easy solution is to move MERGE_RR out of the rr-cache/ directory, which also corresponds with the notion that rr-cache/ contains cached resolutions, not some intermediate temporary states. Noticed by Kalle Olavi Niemitalo. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-12 16:56:19 +02:00
unlink(git_path("MERGE_RR"));
Move code to clean up after a branch change to branch.c Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-07 17:40:16 +01:00
unlink(git_path("MERGE_MSG"));
builtin-commit: use reduce_heads() only when appropriate Since commit 6bb6b034 (builtin-commit: use commit_tree(), 2008-09-10), builtin-commit performs a reduce_heads() unconditionally. However, it's not always needed, and in some cases even harmful. reduce_heads() is not needed for the initial commit or for an "ordinary" commit, because they don't have any or have only one parent, respectively. reduce_heads() must be avoided when 'git commit' is run after a 'git merge --no-ff --no-commit', otherwise it will turn the non-fast-forward merge into fast-forward. For the same reason, reduce_heads() must be avoided when amending such a merge commit. To resolve this issue, 'git merge' will write info about whether fast-forward is allowed or not to $GIT_DIR/MERGE_MODE. Based on this info, 'git commit' will only perform reduce_heads() when it's committing a merge and fast-forward is enabled. Also add test cases to ensure that non-fast-forward merges are committed and amended properly. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-03 14:04:47 +02:00
unlink(git_path("MERGE_MODE"));
Move code to clean up after a branch change to branch.c Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
2008-02-07 17:40:16 +01:00
unlink(git_path("SQUASH_MSG"));
}
Copy permalink