2022-11-19 13:07:38 +00:00
|
|
|
#define USE_THE_INDEX_VARIABLE
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
#include "builtin.h"
|
2019-03-29 10:39:00 +00:00
|
|
|
#include "advice.h"
|
|
|
|
#include "branch.h"
|
|
|
|
#include "cache-tree.h"
|
2017-11-26 19:43:51 +00:00
|
|
|
#include "checkout.h"
|
2019-03-29 10:39:00 +00:00
|
|
|
#include "commit.h"
|
|
|
|
#include "config.h"
|
|
|
|
#include "diff.h"
|
|
|
|
#include "dir.h"
|
2023-03-21 06:26:03 +00:00
|
|
|
#include "environment.h"
|
2023-03-21 06:25:54 +00:00
|
|
|
#include "gettext.h"
|
2023-02-24 00:09:27 +00:00
|
|
|
#include "hex.h"
|
2021-12-22 03:59:35 +00:00
|
|
|
#include "hook.h"
|
merge-ll: rename from ll-merge
A long term (but rather minor) pet-peeve of mine was the name
ll-merge.[ch]. I thought it made it harder to realize what stuff was
related to merging when I was working on the merge machinery and trying
to improve it.
Further, back in d1cbe1e6d8a ("hash-ll.h: split out of hash.h to remove
dependency on repository.h", 2023-04-22), we have split the portions of
hash.h that do not depend upon repository.h into a "hash-ll.h" (due to
the recommendation to use "ll" for "low-level" in its name[1], but which
I used as a suffix precisely because of my distaste for "ll-merge").
When we discussed adding additional "*-ll.h" files, a request was made
that we use "ll" consistently as either a prefix or a suffix. Since it
is already in use as both a prefix and a suffix, the only way to do so
is to rename some files.
Besides my distaste for the ll-merge.[ch] name, let me also note that
the files
ll-fsmonitor.h, ll-hash.h, ll-merge.h, ll-object-store.h, ll-read-cache.h
would have essentially nothing to do with each other and make no sense
to group. But giving them the common "ll-" prefix would group them. Using
"-ll" as a suffix thus seems just much more logical to me. Rename
ll-merge.[ch] to merge-ll.[ch] to achieve this consistency, and to
ensure we get a more logical grouping of files.
[1] https://lore.kernel.org/git/kl6lsfcu1g8w.fsf@chooglen-macbookpro.roam.corp.google.com/
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-16 06:34:04 +00:00
|
|
|
#include "merge-ll.h"
|
2014-10-01 10:28:42 +00:00
|
|
|
#include "lockfile.h"
|
2023-04-11 07:41:47 +00:00
|
|
|
#include "mem-pool.h"
|
2019-03-29 10:39:00 +00:00
|
|
|
#include "merge-recursive.h"
|
2023-04-11 07:41:49 +00:00
|
|
|
#include "object-name.h"
|
2023-05-16 06:34:06 +00:00
|
|
|
#include "object-store-ll.h"
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
#include "parse-options.h"
|
2023-05-16 06:33:59 +00:00
|
|
|
#include "path.h"
|
2023-05-16 06:33:52 +00:00
|
|
|
#include "preload-index.h"
|
2023-05-16 06:33:56 +00:00
|
|
|
#include "read-cache.h"
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
#include "refs.h"
|
2019-03-29 10:39:00 +00:00
|
|
|
#include "remote.h"
|
|
|
|
#include "resolve-undo.h"
|
|
|
|
#include "revision.h"
|
2023-03-21 06:26:05 +00:00
|
|
|
#include "setup.h"
|
2019-03-29 10:39:00 +00:00
|
|
|
#include "submodule.h"
|
2023-04-22 20:17:09 +00:00
|
|
|
#include "symlinks.h"
|
2023-04-11 03:00:38 +00:00
|
|
|
#include "trace2.h"
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
#include "tree.h"
|
|
|
|
#include "tree-walk.h"
|
|
|
|
#include "unpack-trees.h"
|
2019-03-29 10:39:15 +00:00
|
|
|
#include "wt-status.h"
|
2008-08-30 14:52:24 +00:00
|
|
|
#include "xdiff-interface.h"
|
2021-03-23 14:19:32 +00:00
|
|
|
#include "entry.h"
|
2021-05-04 16:27:29 +00:00
|
|
|
#include "parallel-checkout.h"
|
2023-02-06 22:58:57 +00:00
|
|
|
#include "add-interactive.h"
|
2018-08-16 18:27:11 +00:00
|
|
|
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
static const char * const checkout_usage[] = {
|
2015-01-13 07:44:47 +00:00
|
|
|
N_("git checkout [<options>] <branch>"),
|
|
|
|
N_("git checkout [<options>] [<branch>] -- <file>..."),
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
2019-03-29 10:39:05 +00:00
|
|
|
static const char * const switch_branch_usage[] = {
|
|
|
|
N_("git switch [<options>] [<branch>]"),
|
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
2019-04-25 09:45:45 +00:00
|
|
|
static const char * const restore_usage[] = {
|
2019-04-25 09:45:46 +00:00
|
|
|
N_("git restore [<options>] [--source=<branch>] <file>..."),
|
2019-04-25 09:45:45 +00:00
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
2008-08-30 14:46:55 +00:00
|
|
|
struct checkout_opts {
|
2012-08-29 13:55:23 +00:00
|
|
|
int patch_mode;
|
2008-08-30 14:46:55 +00:00
|
|
|
int quiet;
|
|
|
|
int merge;
|
|
|
|
int force;
|
2011-02-08 10:32:49 +00:00
|
|
|
int force_detach;
|
2019-03-29 10:39:11 +00:00
|
|
|
int implicit_detach;
|
2008-08-30 14:48:18 +00:00
|
|
|
int writeout_stage;
|
2011-11-27 10:15:33 +00:00
|
|
|
int overwrite_ignore;
|
2013-04-12 23:12:08 +00:00
|
|
|
int ignore_skipworktree;
|
2015-01-03 09:41:26 +00:00
|
|
|
int ignore_other_worktrees;
|
2015-11-01 21:19:05 +00:00
|
|
|
int show_progress;
|
2018-11-13 18:28:00 +00:00
|
|
|
int count_checkout_paths;
|
checkout: introduce --{,no-}overlay option
Currently 'git checkout' is defined as an overlay operation, which
means that if in 'git checkout <tree-ish> -- [<pathspec>]' we have an
entry in the index that matches <pathspec>, but that doesn't exist in
<tree-ish>, that entry will not be removed from the index or the
working tree.
Introduce a new --{,no-}overlay option, which allows using 'git
checkout' in non-overlay mode, thus removing files from the working
tree if they do not exist in <tree-ish> but match <pathspec>.
Note that 'git checkout -p <tree-ish> -- [<pathspec>]' already works
this way, so no changes are needed for the patch mode. We disallow
'git checkout --overlay -p' to avoid confusing users who would expect
to be able to force overlay mode in 'git checkout -p' this way.
Untracked files are not affected by this change, so 'git checkout
--no-overlay HEAD -- untracked' will not remove untracked from the
working tree. This is so e.g. 'git checkout --no-overlay HEAD -- dir/'
doesn't delete all untracked files in dir/, but rather just resets the
state of files that are known to git.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-08 21:52:24 +00:00
|
|
|
int overlay_mode;
|
2019-03-29 10:39:13 +00:00
|
|
|
int dwim_new_local_branch;
|
2019-03-29 10:39:07 +00:00
|
|
|
int discard_changes;
|
2019-04-25 09:45:46 +00:00
|
|
|
int accept_ref;
|
2019-03-29 10:39:09 +00:00
|
|
|
int accept_pathspec;
|
2019-03-29 10:39:10 +00:00
|
|
|
int switch_branch_doing_nothing_is_ok;
|
2019-03-29 10:39:14 +00:00
|
|
|
int only_merge_on_switching_branches;
|
2019-03-29 10:39:15 +00:00
|
|
|
int can_switch_when_in_progress;
|
2019-03-29 10:39:16 +00:00
|
|
|
int orphan_from_empty_tree;
|
2019-04-25 09:45:47 +00:00
|
|
|
int empty_pathspec_ok;
|
2019-04-25 09:45:50 +00:00
|
|
|
int checkout_index;
|
|
|
|
int checkout_worktree;
|
2019-04-25 09:45:53 +00:00
|
|
|
const char *ignore_unmerged_opt;
|
|
|
|
int ignore_unmerged;
|
2019-12-03 14:02:18 +00:00
|
|
|
int pathspec_file_nul;
|
parse-options: consistently allocate memory in fix_filename()
When handling OPT_FILENAME(), we have to stick the "prefix" (if any) in
front of the filename to make up for the fact that Git has chdir()'d to
the top of the repository. We can do this with prefix_filename(), but
there are a few special cases we handle ourselves.
Unfortunately the memory allocation is inconsistent here; if we do make
it to prefix_filename(), we'll allocate a string which the caller must
free to avoid a leak. But if we hit our special cases, we'll return the
string as-is, and a caller which tries to free it will crash. So there's
no way to win.
Let's consistently allocate, so that callers can do the right thing.
There are now three cases to care about in the function (and hence a
three-armed if/else):
1. we got a NULL input (and should leave it as NULL, though arguably
this is the sign of a bug; let's keep the status quo for now and we
can pick at that scab later)
2. we hit a special case that means we leave the name intact; we
should duplicate the string. This includes our special "-"
matching. Prior to this patch, it also included empty prefixes and
absolute filenames. But we can observe that prefix_filename()
already handles these, so we don't need to detect them.
3. everything else goes to prefix_filename()
I've dropped the "const" from the "char **file" parameter to indicate
that we're allocating, though in practice it's not really important.
This is all being shuffled through a void pointer via opt->value before
it hits code which ever looks at the string. And it's even a bit weird,
because we are really taking _in_ a const string and using the same
out-parameter for a non-const string. A better function signature would
be:
static char *fix_filename(const char *prefix, const char *file);
but that would mean the caller dereferences the double-pointer (and the
NULL check is currently handled inside this function). So I took the
path of least-change here.
Note that we have to fix several callers in this commit, too, or we'll
break the leak-checking tests. These are "new" leaks in the sense that
they are now triggered by the test suite, but these spots have always
been leaky when Git is run in a subdirectory of the repository. I fixed
all of the cases that trigger with GIT_TEST_PASSING_SANITIZE_LEAK. There
may be others in scripts that have other leaks, but we can fix them
later along with those other leaks (and again, you _couldn't_ fix them
before this patch, so this is the necessary first step).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-04 10:31:22 +00:00
|
|
|
char *pathspec_from_file;
|
2008-08-30 14:46:55 +00:00
|
|
|
|
|
|
|
const char *new_branch;
|
2010-06-23 19:29:00 +00:00
|
|
|
const char *new_branch_force;
|
2010-03-21 15:34:38 +00:00
|
|
|
const char *new_orphan_branch;
|
2008-08-30 14:46:55 +00:00
|
|
|
int new_branch_log;
|
|
|
|
enum branch_track track;
|
2010-08-25 10:34:57 +00:00
|
|
|
struct diff_options diff_options;
|
2024-03-14 17:05:06 +00:00
|
|
|
int conflict_style;
|
2012-08-29 13:55:23 +00:00
|
|
|
|
|
|
|
int branch_exists;
|
|
|
|
const char *prefix;
|
2013-07-14 08:35:41 +00:00
|
|
|
struct pathspec pathspec;
|
2019-04-25 09:45:46 +00:00
|
|
|
const char *from_treeish;
|
2012-08-29 13:55:23 +00:00
|
|
|
struct tree *source_tree;
|
2008-08-30 14:46:55 +00:00
|
|
|
};
|
|
|
|
|
2024-03-14 17:05:07 +00:00
|
|
|
#define CHECKOUT_OPTS_INIT { .conflict_style = -1, .merge = -1 }
|
2024-03-14 17:05:06 +00:00
|
|
|
|
2020-03-10 18:20:39 +00:00
|
|
|
struct branch_info {
|
2021-11-16 18:27:38 +00:00
|
|
|
char *name; /* The short name used */
|
|
|
|
char *path; /* The full name of a real branch */
|
2020-03-10 18:20:39 +00:00
|
|
|
struct commit *commit; /* The named commit */
|
2020-03-16 18:05:03 +00:00
|
|
|
char *refname; /* The full name of the ref being checked out. */
|
|
|
|
struct object_id oid; /* The object ID of the commit being checked out. */
|
2020-03-10 18:20:39 +00:00
|
|
|
/*
|
|
|
|
* if not null the branch is detached because it's already
|
|
|
|
* checked out in this checkout
|
|
|
|
*/
|
|
|
|
char *checkout;
|
|
|
|
};
|
|
|
|
|
2021-11-16 18:27:38 +00:00
|
|
|
static void branch_info_release(struct branch_info *info)
|
|
|
|
{
|
|
|
|
free(info->name);
|
|
|
|
free(info->path);
|
|
|
|
free(info->refname);
|
|
|
|
free(info->checkout);
|
|
|
|
}
|
|
|
|
|
2018-02-14 18:59:31 +00:00
|
|
|
static int post_checkout_hook(struct commit *old_commit, struct commit *new_commit,
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
int changed)
|
|
|
|
{
|
2021-12-22 03:59:35 +00:00
|
|
|
return run_hooks_l("post-checkout",
|
2021-04-26 01:02:56 +00:00
|
|
|
oid_to_hex(old_commit ? &old_commit->object.oid : null_oid()),
|
|
|
|
oid_to_hex(new_commit ? &new_commit->object.oid : null_oid()),
|
2014-03-18 10:00:53 +00:00
|
|
|
changed ? "1" : "0", NULL);
|
2018-02-14 18:59:31 +00:00
|
|
|
/* "new_commit" can be NULL when checking out from the index before
|
2009-01-16 19:09:58 +00:00
|
|
|
a commit exists. */
|
2009-01-16 19:09:59 +00:00
|
|
|
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
}
|
|
|
|
|
2018-03-12 02:27:26 +00:00
|
|
|
static int update_some(const struct object_id *oid, struct strbuf *base,
|
2022-08-25 17:09:48 +00:00
|
|
|
const char *pathname, unsigned mode, void *context UNUSED)
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
{
|
|
|
|
int len;
|
|
|
|
struct cache_entry *ce;
|
2014-11-13 18:30:34 +00:00
|
|
|
int pos;
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
|
|
|
|
if (S_ISDIR(mode))
|
|
|
|
return READ_TREE_RECURSIVE;
|
|
|
|
|
2014-11-30 09:05:00 +00:00
|
|
|
len = base->len + strlen(pathname);
|
2018-07-02 19:49:31 +00:00
|
|
|
ce = make_empty_cache_entry(&the_index, len);
|
2018-03-12 02:27:26 +00:00
|
|
|
oidcpy(&ce->oid, oid);
|
2014-11-30 09:05:00 +00:00
|
|
|
memcpy(ce->name, base->buf, base->len);
|
|
|
|
memcpy(ce->name + base->len, pathname, len - base->len);
|
2012-07-11 09:22:37 +00:00
|
|
|
ce->ce_flags = create_ce_flags(0) | CE_UPDATE;
|
|
|
|
ce->ce_namelen = len;
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
ce->ce_mode = create_ce_mode(mode);
|
2014-11-13 18:30:34 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If the entry is the same as the current index, we can leave the old
|
|
|
|
* entry in place. Whether it is UPTODATE or not, checkout_entry will
|
|
|
|
* do the right thing.
|
|
|
|
*/
|
2022-11-19 13:07:38 +00:00
|
|
|
pos = index_name_pos(&the_index, ce->name, ce->ce_namelen);
|
2014-11-13 18:30:34 +00:00
|
|
|
if (pos >= 0) {
|
2022-11-19 13:07:34 +00:00
|
|
|
struct cache_entry *old = the_index.cache[pos];
|
2014-11-13 18:30:34 +00:00
|
|
|
if (ce->ce_mode == old->ce_mode &&
|
checkout.c: unstage empty deleted ita files
It is possible to delete a committed file from the index and then add it
as intent-to-add. After `git checkout HEAD <pathspec>`, the file should
be identical in the index and HEAD. The command already works correctly
if the file has contents in HEAD. This patch provides the desired
behavior even when the file is empty in HEAD.
`git checkout HEAD <pathspec>` calls tree.c:read_tree_1(), with fn
pointing to checkout.c:update_some(). update_some() creates a new cache
entry but discards it when its mode and oid match those of the old
entry. A cache entry for an ita file and a cache entry for an empty file
have the same oid. Therefore, an empty deleted ita file previously
passed both of these checks, and the new entry was discarded, so the
file remained unchanged in the index. After this fix, if the file is
marked as ita in the cache, then we avoid discarding the new entry and
add the new entry to the cache instead.
This change should not affect newly added ita files. For those, inside
tree.c:read_tree_1(), tree_entry_interesting() returns
entry_not_interesting, so fn is never called.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Varun Naik <vcnaik94@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-02 16:28:52 +00:00
|
|
|
!ce_intent_to_add(old) &&
|
convert "oidcmp() == 0" to oideq()
Using the more restrictive oideq() should, in the long run,
give the compiler more opportunities to optimize these
callsites. For now, this conversion should be a complete
noop with respect to the generated code.
The result is also perhaps a little more readable, as it
avoids the "zero is equal" idiom. Since it's so prevalent in
C, I think seasoned programmers tend not to even notice it
anymore, but it can sometimes make for awkward double
negations (e.g., we can drop a few !!oidcmp() instances
here).
This patch was generated almost entirely by the included
coccinelle patch. This mechanical conversion should be
completely safe, because we check explicitly for cases where
oidcmp() is compared to 0, which is what oideq() is doing
under the hood. Note that we don't have to catch "!oidcmp()"
separately; coccinelle's standard isomorphisms make sure the
two are treated equivalently.
I say "almost" because I did hand-edit the coccinelle output
to fix up a few style violations (it mostly keeps the
original formatting, but sometimes unwraps long lines).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-28 21:22:40 +00:00
|
|
|
oideq(&ce->oid, &old->oid)) {
|
2014-11-13 18:30:34 +00:00
|
|
|
old->ce_flags |= CE_UPDATE;
|
2018-07-02 19:49:31 +00:00
|
|
|
discard_cache_entry(ce);
|
2014-11-13 18:30:34 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-11-19 13:07:33 +00:00
|
|
|
add_index_entry(&the_index, ce,
|
|
|
|
ADD_CACHE_OK_TO_ADD | ADD_CACHE_OK_TO_REPLACE);
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-07-14 08:35:52 +00:00
|
|
|
static int read_tree_some(struct tree *tree, const struct pathspec *pathspec)
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
{
|
2021-03-20 22:37:51 +00:00
|
|
|
read_tree(the_repository, tree,
|
|
|
|
pathspec, update_some, NULL);
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
|
|
|
|
/* update the index with the given tree's info
|
|
|
|
* for all args, expanding wildcards, and exit
|
|
|
|
* with any non-zero return code.
|
|
|
|
*/
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
Convert "struct cache_entry *" to "const ..." wherever possible
I attempted to make index_state->cache[] a "const struct cache_entry **"
to find out how existing entries in index are modified and where. The
question I have is what do we do if we really need to keep track of on-disk
changes in the index. The result is
- diff-lib.c: setting CE_UPTODATE
- name-hash.c: setting CE_HASHED
- preload-index.c, read-cache.c, unpack-trees.c and
builtin/update-index: obvious
- entry.c: write_entry() may refresh the checked out entry via
fill_stat_cache_info(). This causes "non-const struct cache_entry
*" in builtin/apply.c, builtin/checkout-index.c and
builtin/checkout.c
- builtin/ls-files.c: --with-tree changes stagemask and may set
CE_UPDATE
Of these, write_entry() and its call sites are probably most
interesting because it modifies on-disk info. But this is stat info
and can be retrieved via refresh, at least for porcelain
commands. Other just uses ce_flags for local purposes.
So, keeping track of "dirty" entries is just a matter of setting a
flag in index modification functions exposed by read-cache.c. Except
unpack-trees, the rest of the code base does not do anything funny
behind read-cache's back.
The actual patch is less valueable than the summary above. But if
anyone wants to re-identify the above sites. Applying this patch, then
this:
diff --git a/cache.h b/cache.h
index 430d021..1692891 100644
--- a/cache.h
+++ b/cache.h
@@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode)
#define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1)
struct index_state {
- struct cache_entry **cache;
+ const struct cache_entry **cache;
unsigned int version;
unsigned int cache_nr, cache_alloc, cache_changed;
struct string_list *resolve_undo;
will help quickly identify them without bogus warnings.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-09 15:29:00 +00:00
|
|
|
static int skip_same_name(const struct cache_entry *ce, int pos)
|
2008-08-29 20:40:36 +00:00
|
|
|
{
|
2022-11-19 13:07:34 +00:00
|
|
|
while (++pos < the_index.cache_nr &&
|
|
|
|
!strcmp(the_index.cache[pos]->name, ce->name))
|
2008-08-29 20:40:36 +00:00
|
|
|
; /* skip */
|
|
|
|
return pos;
|
|
|
|
}
|
|
|
|
|
checkout: introduce --{,no-}overlay option
Currently 'git checkout' is defined as an overlay operation, which
means that if in 'git checkout <tree-ish> -- [<pathspec>]' we have an
entry in the index that matches <pathspec>, but that doesn't exist in
<tree-ish>, that entry will not be removed from the index or the
working tree.
Introduce a new --{,no-}overlay option, which allows using 'git
checkout' in non-overlay mode, thus removing files from the working
tree if they do not exist in <tree-ish> but match <pathspec>.
Note that 'git checkout -p <tree-ish> -- [<pathspec>]' already works
this way, so no changes are needed for the patch mode. We disallow
'git checkout --overlay -p' to avoid confusing users who would expect
to be able to force overlay mode in 'git checkout -p' this way.
Untracked files are not affected by this change, so 'git checkout
--no-overlay HEAD -- untracked' will not remove untracked from the
working tree. This is so e.g. 'git checkout --no-overlay HEAD -- dir/'
doesn't delete all untracked files in dir/, but rather just resets the
state of files that are known to git.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-08 21:52:24 +00:00
|
|
|
static int check_stage(int stage, const struct cache_entry *ce, int pos,
|
|
|
|
int overlay_mode)
|
2008-08-30 14:48:18 +00:00
|
|
|
{
|
2022-11-19 13:07:34 +00:00
|
|
|
while (pos < the_index.cache_nr &&
|
|
|
|
!strcmp(the_index.cache[pos]->name, ce->name)) {
|
|
|
|
if (ce_stage(the_index.cache[pos]) == stage)
|
2008-08-30 14:48:18 +00:00
|
|
|
return 0;
|
|
|
|
pos++;
|
|
|
|
}
|
checkout: introduce --{,no-}overlay option
Currently 'git checkout' is defined as an overlay operation, which
means that if in 'git checkout <tree-ish> -- [<pathspec>]' we have an
entry in the index that matches <pathspec>, but that doesn't exist in
<tree-ish>, that entry will not be removed from the index or the
working tree.
Introduce a new --{,no-}overlay option, which allows using 'git
checkout' in non-overlay mode, thus removing files from the working
tree if they do not exist in <tree-ish> but match <pathspec>.
Note that 'git checkout -p <tree-ish> -- [<pathspec>]' already works
this way, so no changes are needed for the patch mode. We disallow
'git checkout --overlay -p' to avoid confusing users who would expect
to be able to force overlay mode in 'git checkout -p' this way.
Untracked files are not affected by this change, so 'git checkout
--no-overlay HEAD -- untracked' will not remove untracked from the
working tree. This is so e.g. 'git checkout --no-overlay HEAD -- dir/'
doesn't delete all untracked files in dir/, but rather just resets the
state of files that are known to git.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-08 21:52:24 +00:00
|
|
|
if (!overlay_mode)
|
|
|
|
return 0;
|
2011-02-22 23:41:40 +00:00
|
|
|
if (stage == 2)
|
|
|
|
return error(_("path '%s' does not have our version"), ce->name);
|
|
|
|
else
|
|
|
|
return error(_("path '%s' does not have their version"), ce->name);
|
2008-08-30 14:48:18 +00:00
|
|
|
}
|
|
|
|
|
Convert "struct cache_entry *" to "const ..." wherever possible
I attempted to make index_state->cache[] a "const struct cache_entry **"
to find out how existing entries in index are modified and where. The
question I have is what do we do if we really need to keep track of on-disk
changes in the index. The result is
- diff-lib.c: setting CE_UPTODATE
- name-hash.c: setting CE_HASHED
- preload-index.c, read-cache.c, unpack-trees.c and
builtin/update-index: obvious
- entry.c: write_entry() may refresh the checked out entry via
fill_stat_cache_info(). This causes "non-const struct cache_entry
*" in builtin/apply.c, builtin/checkout-index.c and
builtin/checkout.c
- builtin/ls-files.c: --with-tree changes stagemask and may set
CE_UPDATE
Of these, write_entry() and its call sites are probably most
interesting because it modifies on-disk info. But this is stat info
and can be retrieved via refresh, at least for porcelain
commands. Other just uses ce_flags for local purposes.
So, keeping track of "dirty" entries is just a matter of setting a
flag in index modification functions exposed by read-cache.c. Except
unpack-trees, the rest of the code base does not do anything funny
behind read-cache's back.
The actual patch is less valueable than the summary above. But if
anyone wants to re-identify the above sites. Applying this patch, then
this:
diff --git a/cache.h b/cache.h
index 430d021..1692891 100644
--- a/cache.h
+++ b/cache.h
@@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode)
#define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1)
struct index_state {
- struct cache_entry **cache;
+ const struct cache_entry **cache;
unsigned int version;
unsigned int cache_nr, cache_alloc, cache_changed;
struct string_list *resolve_undo;
will help quickly identify them without bogus warnings.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-09 15:29:00 +00:00
|
|
|
static int check_stages(unsigned stages, const struct cache_entry *ce, int pos)
|
2008-08-30 14:52:24 +00:00
|
|
|
{
|
2011-12-05 18:58:23 +00:00
|
|
|
unsigned seen = 0;
|
|
|
|
const char *name = ce->name;
|
|
|
|
|
2022-11-19 13:07:34 +00:00
|
|
|
while (pos < the_index.cache_nr) {
|
|
|
|
ce = the_index.cache[pos];
|
2011-12-05 18:58:23 +00:00
|
|
|
if (strcmp(name, ce->name))
|
|
|
|
break;
|
|
|
|
seen |= (1 << ce_stage(ce));
|
|
|
|
pos++;
|
|
|
|
}
|
|
|
|
if ((stages & seen) != stages)
|
|
|
|
return error(_("path '%s' does not have all necessary versions"),
|
|
|
|
name);
|
2008-08-30 14:52:24 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-09-13 17:11:52 +00:00
|
|
|
static int checkout_stage(int stage, const struct cache_entry *ce, int pos,
|
2019-03-07 00:59:51 +00:00
|
|
|
const struct checkout *state, int *nr_checkouts,
|
|
|
|
int overlay_mode)
|
2008-08-30 14:48:18 +00:00
|
|
|
{
|
2022-11-19 13:07:34 +00:00
|
|
|
while (pos < the_index.cache_nr &&
|
|
|
|
!strcmp(the_index.cache[pos]->name, ce->name)) {
|
|
|
|
if (ce_stage(the_index.cache[pos]) == stage)
|
|
|
|
return checkout_entry(the_index.cache[pos], state,
|
2018-11-13 18:28:00 +00:00
|
|
|
NULL, nr_checkouts);
|
2008-08-30 14:48:18 +00:00
|
|
|
pos++;
|
|
|
|
}
|
checkout: introduce --{,no-}overlay option
Currently 'git checkout' is defined as an overlay operation, which
means that if in 'git checkout <tree-ish> -- [<pathspec>]' we have an
entry in the index that matches <pathspec>, but that doesn't exist in
<tree-ish>, that entry will not be removed from the index or the
working tree.
Introduce a new --{,no-}overlay option, which allows using 'git
checkout' in non-overlay mode, thus removing files from the working
tree if they do not exist in <tree-ish> but match <pathspec>.
Note that 'git checkout -p <tree-ish> -- [<pathspec>]' already works
this way, so no changes are needed for the patch mode. We disallow
'git checkout --overlay -p' to avoid confusing users who would expect
to be able to force overlay mode in 'git checkout -p' this way.
Untracked files are not affected by this change, so 'git checkout
--no-overlay HEAD -- untracked' will not remove untracked from the
working tree. This is so e.g. 'git checkout --no-overlay HEAD -- dir/'
doesn't delete all untracked files in dir/, but rather just resets the
state of files that are known to git.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-08 21:52:24 +00:00
|
|
|
if (!overlay_mode) {
|
read-tree: add "--super-prefix" option, eliminate global
The "--super-prefix" option to "git" was initially added in [1] for
use with "ls-files"[2], and shortly thereafter "submodule--helper"[3]
and "grep"[4]. It wasn't until [5] that "read-tree" made use of it.
At the time [5] made sense, but since then we've made "ls-files"
recurse in-process in [6], "grep" in [7], and finally
"submodule--helper" in the preceding commits.
Let's also remove it from "read-tree", which allows us to remove the
option to "git" itself.
We can do this because the only remaining user of it is the submodule
API, which will now invoke "read-tree" with its new "--super-prefix"
option. It will only do so when the "submodule_move_head()" function
is called.
That "submodule_move_head()" function was then only invoked by
"read-tree" itself, but now rather than setting an environment
variable to pass "--super-prefix" between cmd_read_tree() we:
- Set a new "super_prefix" in "struct unpack_trees_options". The
"super_prefixed()" function in "unpack-trees.c" added in [5] will now
use this, rather than get_super_prefix() looking up the environment
variable we set earlier in the same process.
- Add the same field to the "struct checkout", which is only needed to
ferry the "super_prefix" in the "struct unpack_trees_options" all the
way down to the "entry.c" callers of "submodule_move_head()".
Those calls which used the super prefix all originated in
"cmd_read_tree()". The only other caller is the "unlink_entry()"
caller in "builtin/checkout.c", which now passes a "NULL".
1. 74866d75793 (git: make super-prefix option, 2016-10-07)
2. e77aa336f11 (ls-files: optionally recurse into submodules, 2016-10-07)
3. 89c86265576 (submodule helper: support super prefix, 2016-12-08)
4. 0281e487fd9 (grep: optionally recurse into submodules, 2016-12-16)
5. 3d415425c7b (unpack-trees: support super-prefix option, 2017-01-17)
6. 188dce131fa (ls-files: use repository object, 2017-06-22)
7. f9ee2fcdfa0 (grep: recurse in-process using 'struct repository', 2017-08-02)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-12-20 12:39:56 +00:00
|
|
|
unlink_entry(ce, NULL);
|
checkout: introduce --{,no-}overlay option
Currently 'git checkout' is defined as an overlay operation, which
means that if in 'git checkout <tree-ish> -- [<pathspec>]' we have an
entry in the index that matches <pathspec>, but that doesn't exist in
<tree-ish>, that entry will not be removed from the index or the
working tree.
Introduce a new --{,no-}overlay option, which allows using 'git
checkout' in non-overlay mode, thus removing files from the working
tree if they do not exist in <tree-ish> but match <pathspec>.
Note that 'git checkout -p <tree-ish> -- [<pathspec>]' already works
this way, so no changes are needed for the patch mode. We disallow
'git checkout --overlay -p' to avoid confusing users who would expect
to be able to force overlay mode in 'git checkout -p' this way.
Untracked files are not affected by this change, so 'git checkout
--no-overlay HEAD -- untracked' will not remove untracked from the
working tree. This is so e.g. 'git checkout --no-overlay HEAD -- dir/'
doesn't delete all untracked files in dir/, but rather just resets the
state of files that are known to git.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-08 21:52:24 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2011-02-22 23:41:40 +00:00
|
|
|
if (stage == 2)
|
|
|
|
return error(_("path '%s' does not have our version"), ce->name);
|
|
|
|
else
|
|
|
|
return error(_("path '%s' does not have their version"), ce->name);
|
2008-08-30 14:48:18 +00:00
|
|
|
}
|
2008-08-29 20:40:36 +00:00
|
|
|
|
2021-05-04 16:27:29 +00:00
|
|
|
static int checkout_merged(int pos, const struct checkout *state,
|
2024-03-14 17:05:06 +00:00
|
|
|
int *nr_checkouts, struct mem_pool *ce_mem_pool,
|
|
|
|
int conflict_style)
|
2008-08-30 14:52:24 +00:00
|
|
|
{
|
2022-11-19 13:07:34 +00:00
|
|
|
struct cache_entry *ce = the_index.cache[pos];
|
2008-08-30 14:52:24 +00:00
|
|
|
const char *path = ce->name;
|
|
|
|
mmfile_t ancestor, ours, theirs;
|
2022-02-02 02:37:30 +00:00
|
|
|
enum ll_merge_result merge_status;
|
2008-08-30 14:52:24 +00:00
|
|
|
int status;
|
2016-09-05 20:08:00 +00:00
|
|
|
struct object_id oid;
|
2008-08-30 14:52:24 +00:00
|
|
|
mmbuffer_t result_buf;
|
2016-09-05 20:08:00 +00:00
|
|
|
struct object_id threeway[3];
|
2011-12-15 18:10:11 +00:00
|
|
|
unsigned mode = 0;
|
2024-03-14 17:05:04 +00:00
|
|
|
struct ll_merge_options ll_opts = LL_MERGE_OPTIONS_INIT;
|
2020-08-03 18:41:20 +00:00
|
|
|
int renormalize = 0;
|
2008-08-30 14:52:24 +00:00
|
|
|
|
2011-12-05 18:58:23 +00:00
|
|
|
memset(threeway, 0, sizeof(threeway));
|
2022-11-19 13:07:34 +00:00
|
|
|
while (pos < the_index.cache_nr) {
|
2011-12-05 18:58:23 +00:00
|
|
|
int stage;
|
|
|
|
stage = ce_stage(ce);
|
|
|
|
if (!stage || strcmp(path, ce->name))
|
|
|
|
break;
|
2016-09-05 20:08:00 +00:00
|
|
|
oidcpy(&threeway[stage - 1], &ce->oid);
|
2011-12-05 18:58:23 +00:00
|
|
|
if (stage == 2)
|
|
|
|
mode = create_ce_mode(ce->ce_mode);
|
|
|
|
pos++;
|
2022-11-19 13:07:34 +00:00
|
|
|
ce = the_index.cache[pos];
|
2011-12-05 18:58:23 +00:00
|
|
|
}
|
2016-09-05 20:08:00 +00:00
|
|
|
if (is_null_oid(&threeway[1]) || is_null_oid(&threeway[2]))
|
2011-12-05 18:58:23 +00:00
|
|
|
return error(_("path '%s' does not have necessary versions"), path);
|
2008-08-30 14:52:24 +00:00
|
|
|
|
2016-09-05 20:08:02 +00:00
|
|
|
read_mmblob(&ancestor, &threeway[0]);
|
|
|
|
read_mmblob(&ours, &threeway[1]);
|
|
|
|
read_mmblob(&theirs, &threeway[2]);
|
2008-08-30 14:52:24 +00:00
|
|
|
|
2020-08-03 18:41:20 +00:00
|
|
|
git_config_get_bool("merge.renormalize", &renormalize);
|
|
|
|
ll_opts.renormalize = renormalize;
|
2024-03-14 17:05:06 +00:00
|
|
|
ll_opts.conflict_style = conflict_style;
|
2022-02-02 02:37:30 +00:00
|
|
|
merge_status = ll_merge(&result_buf, path, &ancestor, "base",
|
|
|
|
&ours, "ours", &theirs, "theirs",
|
|
|
|
state->istate, &ll_opts);
|
2008-08-30 14:52:24 +00:00
|
|
|
free(ancestor.ptr);
|
|
|
|
free(ours.ptr);
|
|
|
|
free(theirs.ptr);
|
2022-02-02 02:37:30 +00:00
|
|
|
if (merge_status == LL_MERGE_BINARY_CONFLICT)
|
|
|
|
warning("Cannot merge binary files: %s (%s vs. %s)",
|
|
|
|
path, "ours", "theirs");
|
|
|
|
if (merge_status < 0 || !result_buf.ptr) {
|
2008-08-30 14:52:24 +00:00
|
|
|
free(result_buf.ptr);
|
2011-02-22 23:41:39 +00:00
|
|
|
return error(_("path '%s': cannot merge"), path);
|
2008-08-30 14:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* NEEDSWORK:
|
|
|
|
* There is absolutely no reason to write this as a blob object
|
2017-05-04 13:56:40 +00:00
|
|
|
* and create a phony cache entry. This hack is primarily to get
|
|
|
|
* to the write_entry() machinery that massages the contents to
|
|
|
|
* work-tree format and writes out which only allows it for a
|
|
|
|
* cache entry. The code in write_entry() needs to be refactored
|
|
|
|
* to allow us to feed a <buffer, size, mode> instead of a cache
|
|
|
|
* entry. Such a refactoring would help merge_recursive as well
|
|
|
|
* (it also writes the merge result to the object database even
|
|
|
|
* when it may contain conflicts).
|
2008-08-30 14:52:24 +00:00
|
|
|
*/
|
2022-02-04 23:48:26 +00:00
|
|
|
if (write_object_file(result_buf.ptr, result_buf.size, OBJ_BLOB, &oid))
|
2011-02-22 23:41:39 +00:00
|
|
|
die(_("Unable to add merge result for '%s'"), path);
|
2017-05-08 04:21:06 +00:00
|
|
|
free(result_buf.ptr);
|
2021-05-04 16:27:29 +00:00
|
|
|
ce = make_transient_cache_entry(mode, &oid, path, 2, ce_mem_pool);
|
2008-10-05 02:14:40 +00:00
|
|
|
if (!ce)
|
2011-02-22 23:41:39 +00:00
|
|
|
die(_("make_cache_entry failed for path '%s'"), path);
|
2018-11-13 18:28:00 +00:00
|
|
|
status = checkout_entry(ce, state, NULL, nr_checkouts);
|
2008-08-30 14:52:24 +00:00
|
|
|
return status;
|
|
|
|
}
|
2008-08-29 20:40:36 +00:00
|
|
|
|
checkout: introduce --{,no-}overlay option
Currently 'git checkout' is defined as an overlay operation, which
means that if in 'git checkout <tree-ish> -- [<pathspec>]' we have an
entry in the index that matches <pathspec>, but that doesn't exist in
<tree-ish>, that entry will not be removed from the index or the
working tree.
Introduce a new --{,no-}overlay option, which allows using 'git
checkout' in non-overlay mode, thus removing files from the working
tree if they do not exist in <tree-ish> but match <pathspec>.
Note that 'git checkout -p <tree-ish> -- [<pathspec>]' already works
this way, so no changes are needed for the patch mode. We disallow
'git checkout --overlay -p' to avoid confusing users who would expect
to be able to force overlay mode in 'git checkout -p' this way.
Untracked files are not affected by this change, so 'git checkout
--no-overlay HEAD -- untracked' will not remove untracked from the
working tree. This is so e.g. 'git checkout --no-overlay HEAD -- dir/'
doesn't delete all untracked files in dir/, but rather just resets the
state of files that are known to git.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-08 21:52:24 +00:00
|
|
|
static void mark_ce_for_checkout_overlay(struct cache_entry *ce,
|
|
|
|
char *ps_matched,
|
|
|
|
const struct checkout_opts *opts)
|
2018-12-20 13:48:18 +00:00
|
|
|
{
|
|
|
|
ce->ce_flags &= ~CE_MATCHED;
|
|
|
|
if (!opts->ignore_skipworktree && ce_skip_worktree(ce))
|
|
|
|
return;
|
|
|
|
if (opts->source_tree && !(ce->ce_flags & CE_UPDATE))
|
|
|
|
/*
|
|
|
|
* "git checkout tree-ish -- path", but this entry
|
|
|
|
* is in the original index but is not in tree-ish
|
|
|
|
* or does not match the pathspec; it will not be
|
|
|
|
* checked out to the working tree. We will not do
|
|
|
|
* anything to this entry at all.
|
|
|
|
*/
|
|
|
|
return;
|
|
|
|
/*
|
|
|
|
* Either this entry came from the tree-ish we are
|
|
|
|
* checking the paths out of, or we are checking out
|
|
|
|
* of the index.
|
|
|
|
*
|
|
|
|
* If it comes from the tree-ish, we already know it
|
|
|
|
* matches the pathspec and could just stamp
|
|
|
|
* CE_MATCHED to it from update_some(). But we still
|
2021-03-20 22:37:51 +00:00
|
|
|
* need ps_matched and read_tree (and
|
2018-12-20 13:48:18 +00:00
|
|
|
* eventually tree_entry_interesting) cannot fill
|
|
|
|
* ps_matched yet. Once it can, we can avoid calling
|
|
|
|
* match_pathspec() for _all_ entries when
|
|
|
|
* opts->source_tree != NULL.
|
|
|
|
*/
|
|
|
|
if (ce_path_match(&the_index, ce, &opts->pathspec, ps_matched))
|
|
|
|
ce->ce_flags |= CE_MATCHED;
|
|
|
|
}
|
|
|
|
|
checkout: introduce --{,no-}overlay option
Currently 'git checkout' is defined as an overlay operation, which
means that if in 'git checkout <tree-ish> -- [<pathspec>]' we have an
entry in the index that matches <pathspec>, but that doesn't exist in
<tree-ish>, that entry will not be removed from the index or the
working tree.
Introduce a new --{,no-}overlay option, which allows using 'git
checkout' in non-overlay mode, thus removing files from the working
tree if they do not exist in <tree-ish> but match <pathspec>.
Note that 'git checkout -p <tree-ish> -- [<pathspec>]' already works
this way, so no changes are needed for the patch mode. We disallow
'git checkout --overlay -p' to avoid confusing users who would expect
to be able to force overlay mode in 'git checkout -p' this way.
Untracked files are not affected by this change, so 'git checkout
--no-overlay HEAD -- untracked' will not remove untracked from the
working tree. This is so e.g. 'git checkout --no-overlay HEAD -- dir/'
doesn't delete all untracked files in dir/, but rather just resets the
state of files that are known to git.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-08 21:52:24 +00:00
|
|
|
static void mark_ce_for_checkout_no_overlay(struct cache_entry *ce,
|
|
|
|
char *ps_matched,
|
|
|
|
const struct checkout_opts *opts)
|
|
|
|
{
|
|
|
|
ce->ce_flags &= ~CE_MATCHED;
|
|
|
|
if (!opts->ignore_skipworktree && ce_skip_worktree(ce))
|
|
|
|
return;
|
|
|
|
if (ce_path_match(&the_index, ce, &opts->pathspec, ps_matched)) {
|
|
|
|
ce->ce_flags |= CE_MATCHED;
|
|
|
|
if (opts->source_tree && !(ce->ce_flags & CE_UPDATE))
|
|
|
|
/*
|
|
|
|
* In overlay mode, but the path is not in
|
|
|
|
* tree-ish, which means we should remove it
|
|
|
|
* from the index and the working tree.
|
|
|
|
*/
|
|
|
|
ce->ce_flags |= CE_REMOVE | CE_WT_REMOVE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-03-10 18:20:39 +00:00
|
|
|
static int checkout_worktree(const struct checkout_opts *opts,
|
|
|
|
const struct branch_info *info)
|
2019-04-25 09:45:49 +00:00
|
|
|
{
|
|
|
|
struct checkout state = CHECKOUT_INIT;
|
|
|
|
int nr_checkouts = 0, nr_unmerged = 0;
|
|
|
|
int errs = 0;
|
|
|
|
int pos;
|
2021-05-04 16:27:29 +00:00
|
|
|
int pc_workers, pc_threshold;
|
|
|
|
struct mem_pool ce_mem_pool;
|
2019-04-25 09:45:49 +00:00
|
|
|
|
|
|
|
state.force = 1;
|
|
|
|
state.refresh_cache = 1;
|
|
|
|
state.istate = &the_index;
|
|
|
|
|
2021-05-04 16:27:29 +00:00
|
|
|
mem_pool_init(&ce_mem_pool, 0);
|
|
|
|
get_parallel_checkout_configs(&pc_workers, &pc_threshold);
|
2020-03-16 18:05:03 +00:00
|
|
|
init_checkout_metadata(&state.meta, info->refname,
|
|
|
|
info->commit ? &info->commit->object.oid : &info->oid,
|
|
|
|
NULL);
|
|
|
|
|
2019-04-25 09:45:49 +00:00
|
|
|
enable_delayed_checkout(&state);
|
2021-04-01 01:49:44 +00:00
|
|
|
|
2021-05-04 16:27:29 +00:00
|
|
|
if (pc_workers > 1)
|
|
|
|
init_parallel_checkout();
|
|
|
|
|
2022-11-19 13:07:34 +00:00
|
|
|
for (pos = 0; pos < the_index.cache_nr; pos++) {
|
|
|
|
struct cache_entry *ce = the_index.cache[pos];
|
2019-04-25 09:45:49 +00:00
|
|
|
if (ce->ce_flags & CE_MATCHED) {
|
|
|
|
if (!ce_stage(ce)) {
|
|
|
|
errs |= checkout_entry(ce, &state,
|
|
|
|
NULL, &nr_checkouts);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (opts->writeout_stage)
|
|
|
|
errs |= checkout_stage(opts->writeout_stage,
|
|
|
|
ce, pos,
|
|
|
|
&state,
|
|
|
|
&nr_checkouts, opts->overlay_mode);
|
|
|
|
else if (opts->merge)
|
|
|
|
errs |= checkout_merged(pos, &state,
|
2021-05-04 16:27:29 +00:00
|
|
|
&nr_unmerged,
|
2024-03-14 17:05:06 +00:00
|
|
|
&ce_mem_pool,
|
|
|
|
opts->conflict_style);
|
2019-04-25 09:45:49 +00:00
|
|
|
pos = skip_same_name(ce, pos) - 1;
|
|
|
|
}
|
|
|
|
}
|
2021-05-04 16:27:29 +00:00
|
|
|
if (pc_workers > 1)
|
|
|
|
errs |= run_parallel_checkout(&state, pc_workers, pc_threshold,
|
|
|
|
NULL, NULL);
|
|
|
|
mem_pool_discard(&ce_mem_pool, should_validate_cache_entries());
|
2019-04-25 09:45:49 +00:00
|
|
|
remove_marked_cache_entries(&the_index, 1);
|
|
|
|
remove_scheduled_dirs();
|
2022-07-14 11:49:12 +00:00
|
|
|
errs |= finish_delayed_checkout(&state, opts->show_progress);
|
2019-04-25 09:45:49 +00:00
|
|
|
|
|
|
|
if (opts->count_checkout_paths) {
|
|
|
|
if (nr_unmerged)
|
|
|
|
fprintf_ln(stderr, Q_("Recreated %d merge conflict",
|
|
|
|
"Recreated %d merge conflicts",
|
|
|
|
nr_unmerged),
|
|
|
|
nr_unmerged);
|
|
|
|
if (opts->source_tree)
|
|
|
|
fprintf_ln(stderr, Q_("Updated %d path from %s",
|
|
|
|
"Updated %d paths from %s",
|
|
|
|
nr_checkouts),
|
|
|
|
nr_checkouts,
|
2023-03-28 13:58:46 +00:00
|
|
|
repo_find_unique_abbrev(the_repository, &opts->source_tree->object.oid,
|
|
|
|
DEFAULT_ABBREV));
|
2019-04-25 09:45:49 +00:00
|
|
|
else if (!nr_unmerged || nr_checkouts)
|
|
|
|
fprintf_ln(stderr, Q_("Updated %d path from the index",
|
|
|
|
"Updated %d paths from the index",
|
|
|
|
nr_checkouts),
|
|
|
|
nr_checkouts);
|
|
|
|
}
|
|
|
|
|
|
|
|
return errs;
|
|
|
|
}
|
|
|
|
|
2012-08-30 12:45:50 +00:00
|
|
|
static int checkout_paths(const struct checkout_opts *opts,
|
2020-03-10 18:20:39 +00:00
|
|
|
const struct branch_info *new_branch_info)
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
{
|
|
|
|
int pos;
|
|
|
|
static char *ps_matched;
|
2016-09-05 20:08:00 +00:00
|
|
|
struct object_id rev;
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
struct commit *head;
|
2008-05-28 21:48:57 +00:00
|
|
|
int errs = 0;
|
2017-10-05 20:32:04 +00:00
|
|
|
struct lock_file lock_file = LOCK_INIT;
|
2019-04-25 09:45:50 +00:00
|
|
|
int checkout_index;
|
2012-08-30 12:45:50 +00:00
|
|
|
|
2019-02-22 22:25:08 +00:00
|
|
|
trace2_cmd_mode(opts->patch_mode ? "patch" : "path");
|
|
|
|
|
2012-08-30 12:45:50 +00:00
|
|
|
if (opts->track != BRANCH_TRACK_UNSPECIFIED)
|
|
|
|
die(_("'%s' cannot be used with updating paths"), "--track");
|
|
|
|
|
|
|
|
if (opts->new_branch_log)
|
|
|
|
die(_("'%s' cannot be used with updating paths"), "-l");
|
|
|
|
|
2019-04-25 09:45:53 +00:00
|
|
|
if (opts->ignore_unmerged && opts->patch_mode)
|
|
|
|
die(_("'%s' cannot be used with updating paths"),
|
|
|
|
opts->ignore_unmerged_opt);
|
2012-08-30 12:45:50 +00:00
|
|
|
|
|
|
|
if (opts->force_detach)
|
|
|
|
die(_("'%s' cannot be used with updating paths"), "--detach");
|
|
|
|
|
|
|
|
if (opts->merge && opts->patch_mode)
|
2022-01-05 20:02:16 +00:00
|
|
|
die(_("options '%s' and '%s' cannot be used together"), "--merge", "--patch");
|
2012-08-30 12:45:50 +00:00
|
|
|
|
2019-04-25 09:45:53 +00:00
|
|
|
if (opts->ignore_unmerged && opts->merge)
|
2022-01-05 20:02:16 +00:00
|
|
|
die(_("options '%s' and '%s' cannot be used together"),
|
2019-04-25 09:45:53 +00:00
|
|
|
opts->ignore_unmerged_opt, "-m");
|
2012-08-30 12:45:50 +00:00
|
|
|
|
|
|
|
if (opts->new_branch)
|
|
|
|
die(_("Cannot update paths and switch to branch '%s' at the same time."),
|
|
|
|
opts->new_branch);
|
|
|
|
|
2019-04-25 09:45:50 +00:00
|
|
|
if (!opts->checkout_worktree && !opts->checkout_index)
|
|
|
|
die(_("neither '%s' or '%s' is specified"),
|
|
|
|
"--staged", "--worktree");
|
|
|
|
|
|
|
|
if (!opts->checkout_worktree && !opts->from_treeish)
|
|
|
|
die(_("'%s' must be used when '%s' is not specified"),
|
|
|
|
"--worktree", "--source");
|
|
|
|
|
2023-02-26 18:43:54 +00:00
|
|
|
/*
|
|
|
|
* Reject --staged option to the restore command when combined with
|
|
|
|
* merge-related options. Use the accept_ref flag to distinguish it
|
|
|
|
* from the checkout command, which does not accept --staged anyway.
|
|
|
|
*
|
|
|
|
* `restore --ours|--theirs --worktree --staged` could mean resolving
|
|
|
|
* conflicted paths to one side in both the worktree and the index,
|
|
|
|
* but does not currently.
|
|
|
|
*
|
|
|
|
* `restore --merge|--conflict=<style>` already recreates conflicts
|
|
|
|
* in both the worktree and the index, so adding --staged would be
|
|
|
|
* meaningless.
|
|
|
|
*/
|
|
|
|
if (!opts->accept_ref && opts->checkout_index) {
|
|
|
|
if (opts->writeout_stage)
|
|
|
|
die(_("'%s' or '%s' cannot be used with %s"),
|
|
|
|
"--ours", "--theirs", "--staged");
|
|
|
|
|
|
|
|
if (opts->merge)
|
|
|
|
die(_("'%s' or '%s' cannot be used with %s"),
|
|
|
|
"--merge", "--conflict", "--staged");
|
|
|
|
}
|
2019-04-25 09:45:51 +00:00
|
|
|
|
2023-07-31 22:44:07 +00:00
|
|
|
/*
|
|
|
|
* recreating unmerged index entries and writing out data from
|
|
|
|
* unmerged index entries would make no sense when checking out
|
|
|
|
* of a tree-ish.
|
|
|
|
*/
|
|
|
|
if ((opts->merge || opts->writeout_stage) && opts->source_tree)
|
|
|
|
die(_("'%s', '%s', or '%s' cannot be used when checking out of a tree"),
|
|
|
|
"--merge", "--ours", "--theirs");
|
|
|
|
|
2019-04-25 09:45:50 +00:00
|
|
|
if (opts->patch_mode) {
|
2023-02-06 22:58:57 +00:00
|
|
|
enum add_p_mode patch_mode;
|
2020-10-07 07:56:15 +00:00
|
|
|
const char *rev = new_branch_info->name;
|
|
|
|
char rev_oid[GIT_MAX_HEXSZ + 1];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Since rev can be in the form of `<a>...<b>` (which is not
|
|
|
|
* recognized by diff-index), we will always replace the name
|
|
|
|
* with the hex of the commit (whether it's in `...` form or
|
|
|
|
* not) for the run_add_interactive() machinery to work
|
|
|
|
* properly. However, there is special logic for the HEAD case
|
2020-12-19 14:55:59 +00:00
|
|
|
* so we mustn't replace that. Also, when we were given a
|
|
|
|
* tree-object, new_branch_info->commit would be NULL, but we
|
|
|
|
* do not have to do any replacement, either.
|
2020-10-07 07:56:15 +00:00
|
|
|
*/
|
2020-12-19 14:55:59 +00:00
|
|
|
if (rev && new_branch_info->commit && strcmp(rev, "HEAD"))
|
2020-10-07 07:56:15 +00:00
|
|
|
rev = oid_to_hex_r(rev_oid, &new_branch_info->commit->object.oid);
|
2019-04-25 09:45:50 +00:00
|
|
|
|
|
|
|
if (opts->checkout_index && opts->checkout_worktree)
|
2023-02-06 22:58:57 +00:00
|
|
|
patch_mode = ADD_P_CHECKOUT;
|
2019-04-25 09:45:50 +00:00
|
|
|
else if (opts->checkout_index && !opts->checkout_worktree)
|
2023-02-06 22:58:57 +00:00
|
|
|
patch_mode = ADD_P_RESET;
|
2019-04-25 09:45:54 +00:00
|
|
|
else if (!opts->checkout_index && opts->checkout_worktree)
|
2023-02-06 22:58:57 +00:00
|
|
|
patch_mode = ADD_P_WORKTREE;
|
2019-04-25 09:45:50 +00:00
|
|
|
else
|
2019-04-25 09:45:54 +00:00
|
|
|
BUG("either flag must have been set, worktree=%d, index=%d",
|
|
|
|
opts->checkout_worktree, opts->checkout_index);
|
2023-02-06 22:58:57 +00:00
|
|
|
return !!run_add_p(the_repository, patch_mode, rev,
|
|
|
|
&opts->pathspec);
|
2019-04-25 09:45:50 +00:00
|
|
|
}
|
2012-08-30 12:45:50 +00:00
|
|
|
|
2019-01-12 02:13:25 +00:00
|
|
|
repo_hold_locked_index(the_repository, &lock_file, LOCK_DIE_ON_ERROR);
|
2022-11-19 13:07:38 +00:00
|
|
|
if (repo_read_index_preload(the_repository, &opts->pathspec, 0) < 0)
|
2016-06-17 20:21:20 +00:00
|
|
|
return error(_("index file corrupt"));
|
2008-02-28 21:52:44 +00:00
|
|
|
|
2012-08-29 13:55:23 +00:00
|
|
|
if (opts->source_tree)
|
2013-07-14 08:35:52 +00:00
|
|
|
read_tree_some(opts->source_tree, &opts->pathspec);
|
2023-07-31 22:44:09 +00:00
|
|
|
if (opts->merge)
|
|
|
|
unmerge_index(&the_index, &opts->pathspec, CE_MATCHED);
|
2008-02-28 21:52:44 +00:00
|
|
|
|
2015-08-20 16:57:32 +00:00
|
|
|
ps_matched = xcalloc(opts->pathspec.nr, 1);
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
|
checkout: avoid unnecessary match_pathspec calls
In checkout_paths() we do this
- for all updated items, call match_pathspec
- for all items, call match_pathspec (inside unmerge_cache)
- for all items, call match_pathspec (for showing "path .. is unmerged)
- for updated items, call match_pathspec and update paths
That's a lot of duplicate match_pathspec(s) and the function is not
exactly cheap to be called so many times, especially on large indexes.
This patch makes it call match_pathspec once per updated index entry,
save the result in ce_flags and reuse the results in the following
loops.
The changes in 0a1283b (checkout $tree $path: do not clobber local
changes in $path not in $tree - 2011-09-30) limit the affected paths
to ones we read from $tree. We do not do anything to other modified
entries in this case, so the "for all items" above could be modified
to "for all updated items". But..
The command's behavior now is modified slightly: unmerged entries that
match $path, but not updated by $tree, are now NOT touched. Although
this should be considered a bug fix, not a regression. A new test is
added for this change.
And while at there, free ps_matched after use.
The following command is tested on webkit, 215k entries. The pattern
is chosen mainly to make match_pathspec sweat:
git checkout -- "*[a-zA-Z]*[a-zA-Z]*[a-zA-Z]*"
before after
real 0m3.493s 0m2.737s
user 0m2.239s 0m1.586s
sys 0m1.252s 0m1.151s
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-27 05:58:21 +00:00
|
|
|
/*
|
|
|
|
* Make sure all pathspecs participated in locating the paths
|
|
|
|
* to be checked out.
|
|
|
|
*/
|
2022-11-19 13:07:34 +00:00
|
|
|
for (pos = 0; pos < the_index.cache_nr; pos++)
|
checkout: introduce --{,no-}overlay option
Currently 'git checkout' is defined as an overlay operation, which
means that if in 'git checkout <tree-ish> -- [<pathspec>]' we have an
entry in the index that matches <pathspec>, but that doesn't exist in
<tree-ish>, that entry will not be removed from the index or the
working tree.
Introduce a new --{,no-}overlay option, which allows using 'git
checkout' in non-overlay mode, thus removing files from the working
tree if they do not exist in <tree-ish> but match <pathspec>.
Note that 'git checkout -p <tree-ish> -- [<pathspec>]' already works
this way, so no changes are needed for the patch mode. We disallow
'git checkout --overlay -p' to avoid confusing users who would expect
to be able to force overlay mode in 'git checkout -p' this way.
Untracked files are not affected by this change, so 'git checkout
--no-overlay HEAD -- untracked' will not remove untracked from the
working tree. This is so e.g. 'git checkout --no-overlay HEAD -- dir/'
doesn't delete all untracked files in dir/, but rather just resets the
state of files that are known to git.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-08 21:52:24 +00:00
|
|
|
if (opts->overlay_mode)
|
2022-11-19 13:07:34 +00:00
|
|
|
mark_ce_for_checkout_overlay(the_index.cache[pos],
|
checkout: introduce --{,no-}overlay option
Currently 'git checkout' is defined as an overlay operation, which
means that if in 'git checkout <tree-ish> -- [<pathspec>]' we have an
entry in the index that matches <pathspec>, but that doesn't exist in
<tree-ish>, that entry will not be removed from the index or the
working tree.
Introduce a new --{,no-}overlay option, which allows using 'git
checkout' in non-overlay mode, thus removing files from the working
tree if they do not exist in <tree-ish> but match <pathspec>.
Note that 'git checkout -p <tree-ish> -- [<pathspec>]' already works
this way, so no changes are needed for the patch mode. We disallow
'git checkout --overlay -p' to avoid confusing users who would expect
to be able to force overlay mode in 'git checkout -p' this way.
Untracked files are not affected by this change, so 'git checkout
--no-overlay HEAD -- untracked' will not remove untracked from the
working tree. This is so e.g. 'git checkout --no-overlay HEAD -- dir/'
doesn't delete all untracked files in dir/, but rather just resets the
state of files that are known to git.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-08 21:52:24 +00:00
|
|
|
ps_matched,
|
|
|
|
opts);
|
|
|
|
else
|
2022-11-19 13:07:34 +00:00
|
|
|
mark_ce_for_checkout_no_overlay(the_index.cache[pos],
|
checkout: introduce --{,no-}overlay option
Currently 'git checkout' is defined as an overlay operation, which
means that if in 'git checkout <tree-ish> -- [<pathspec>]' we have an
entry in the index that matches <pathspec>, but that doesn't exist in
<tree-ish>, that entry will not be removed from the index or the
working tree.
Introduce a new --{,no-}overlay option, which allows using 'git
checkout' in non-overlay mode, thus removing files from the working
tree if they do not exist in <tree-ish> but match <pathspec>.
Note that 'git checkout -p <tree-ish> -- [<pathspec>]' already works
this way, so no changes are needed for the patch mode. We disallow
'git checkout --overlay -p' to avoid confusing users who would expect
to be able to force overlay mode in 'git checkout -p' this way.
Untracked files are not affected by this change, so 'git checkout
--no-overlay HEAD -- untracked' will not remove untracked from the
working tree. This is so e.g. 'git checkout --no-overlay HEAD -- dir/'
doesn't delete all untracked files in dir/, but rather just resets the
state of files that are known to git.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-08 21:52:24 +00:00
|
|
|
ps_matched,
|
|
|
|
opts);
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
|
2019-03-20 08:15:48 +00:00
|
|
|
if (report_path_error(ps_matched, &opts->pathspec)) {
|
checkout: avoid unnecessary match_pathspec calls
In checkout_paths() we do this
- for all updated items, call match_pathspec
- for all items, call match_pathspec (inside unmerge_cache)
- for all items, call match_pathspec (for showing "path .. is unmerged)
- for updated items, call match_pathspec and update paths
That's a lot of duplicate match_pathspec(s) and the function is not
exactly cheap to be called so many times, especially on large indexes.
This patch makes it call match_pathspec once per updated index entry,
save the result in ce_flags and reuse the results in the following
loops.
The changes in 0a1283b (checkout $tree $path: do not clobber local
changes in $path not in $tree - 2011-09-30) limit the affected paths
to ones we read from $tree. We do not do anything to other modified
entries in this case, so the "for all items" above could be modified
to "for all updated items". But..
The command's behavior now is modified slightly: unmerged entries that
match $path, but not updated by $tree, are now NOT touched. Although
this should be considered a bug fix, not a regression. A new test is
added for this change.
And while at there, free ps_matched after use.
The following command is tested on webkit, 215k entries. The pattern
is chosen mainly to make match_pathspec sweat:
git checkout -- "*[a-zA-Z]*[a-zA-Z]*[a-zA-Z]*"
before after
real 0m3.493s 0m2.737s
user 0m2.239s 0m1.586s
sys 0m1.252s 0m1.151s
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-27 05:58:21 +00:00
|
|
|
free(ps_matched);
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
return 1;
|
checkout: avoid unnecessary match_pathspec calls
In checkout_paths() we do this
- for all updated items, call match_pathspec
- for all items, call match_pathspec (inside unmerge_cache)
- for all items, call match_pathspec (for showing "path .. is unmerged)
- for updated items, call match_pathspec and update paths
That's a lot of duplicate match_pathspec(s) and the function is not
exactly cheap to be called so many times, especially on large indexes.
This patch makes it call match_pathspec once per updated index entry,
save the result in ce_flags and reuse the results in the following
loops.
The changes in 0a1283b (checkout $tree $path: do not clobber local
changes in $path not in $tree - 2011-09-30) limit the affected paths
to ones we read from $tree. We do not do anything to other modified
entries in this case, so the "for all items" above could be modified
to "for all updated items". But..
The command's behavior now is modified slightly: unmerged entries that
match $path, but not updated by $tree, are now NOT touched. Although
this should be considered a bug fix, not a regression. A new test is
added for this change.
And while at there, free ps_matched after use.
The following command is tested on webkit, 215k entries. The pattern
is chosen mainly to make match_pathspec sweat:
git checkout -- "*[a-zA-Z]*[a-zA-Z]*[a-zA-Z]*"
before after
real 0m3.493s 0m2.737s
user 0m2.239s 0m1.586s
sys 0m1.252s 0m1.151s
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-27 05:58:21 +00:00
|
|
|
}
|
|
|
|
free(ps_matched);
|
2009-12-25 19:57:11 +00:00
|
|
|
|
2008-08-29 20:40:36 +00:00
|
|
|
/* Any unmerged paths? */
|
2022-11-19 13:07:34 +00:00
|
|
|
for (pos = 0; pos < the_index.cache_nr; pos++) {
|
|
|
|
const struct cache_entry *ce = the_index.cache[pos];
|
checkout: avoid unnecessary match_pathspec calls
In checkout_paths() we do this
- for all updated items, call match_pathspec
- for all items, call match_pathspec (inside unmerge_cache)
- for all items, call match_pathspec (for showing "path .. is unmerged)
- for updated items, call match_pathspec and update paths
That's a lot of duplicate match_pathspec(s) and the function is not
exactly cheap to be called so many times, especially on large indexes.
This patch makes it call match_pathspec once per updated index entry,
save the result in ce_flags and reuse the results in the following
loops.
The changes in 0a1283b (checkout $tree $path: do not clobber local
changes in $path not in $tree - 2011-09-30) limit the affected paths
to ones we read from $tree. We do not do anything to other modified
entries in this case, so the "for all items" above could be modified
to "for all updated items". But..
The command's behavior now is modified slightly: unmerged entries that
match $path, but not updated by $tree, are now NOT touched. Although
this should be considered a bug fix, not a regression. A new test is
added for this change.
And while at there, free ps_matched after use.
The following command is tested on webkit, 215k entries. The pattern
is chosen mainly to make match_pathspec sweat:
git checkout -- "*[a-zA-Z]*[a-zA-Z]*[a-zA-Z]*"
before after
real 0m3.493s 0m2.737s
user 0m2.239s 0m1.586s
sys 0m1.252s 0m1.151s
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-27 05:58:21 +00:00
|
|
|
if (ce->ce_flags & CE_MATCHED) {
|
2008-08-29 20:40:36 +00:00
|
|
|
if (!ce_stage(ce))
|
|
|
|
continue;
|
2019-04-25 09:45:53 +00:00
|
|
|
if (opts->ignore_unmerged) {
|
|
|
|
if (!opts->quiet)
|
|
|
|
warning(_("path '%s' is unmerged"), ce->name);
|
2013-08-03 11:51:21 +00:00
|
|
|
} else if (opts->writeout_stage) {
|
checkout: introduce --{,no-}overlay option
Currently 'git checkout' is defined as an overlay operation, which
means that if in 'git checkout <tree-ish> -- [<pathspec>]' we have an
entry in the index that matches <pathspec>, but that doesn't exist in
<tree-ish>, that entry will not be removed from the index or the
working tree.
Introduce a new --{,no-}overlay option, which allows using 'git
checkout' in non-overlay mode, thus removing files from the working
tree if they do not exist in <tree-ish> but match <pathspec>.
Note that 'git checkout -p <tree-ish> -- [<pathspec>]' already works
this way, so no changes are needed for the patch mode. We disallow
'git checkout --overlay -p' to avoid confusing users who would expect
to be able to force overlay mode in 'git checkout -p' this way.
Untracked files are not affected by this change, so 'git checkout
--no-overlay HEAD -- untracked' will not remove untracked from the
working tree. This is so e.g. 'git checkout --no-overlay HEAD -- dir/'
doesn't delete all untracked files in dir/, but rather just resets the
state of files that are known to git.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-08 21:52:24 +00:00
|
|
|
errs |= check_stage(opts->writeout_stage, ce, pos, opts->overlay_mode);
|
2008-08-30 14:52:24 +00:00
|
|
|
} else if (opts->merge) {
|
2011-12-05 18:58:23 +00:00
|
|
|
errs |= check_stages((1<<2) | (1<<3), ce, pos);
|
2008-08-30 14:46:55 +00:00
|
|
|
} else {
|
|
|
|
errs = 1;
|
2011-02-22 23:41:39 +00:00
|
|
|
error(_("path '%s' is unmerged"), ce->name);
|
2008-08-30 14:46:55 +00:00
|
|
|
}
|
2008-08-29 20:40:36 +00:00
|
|
|
pos = skip_same_name(ce, pos) - 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (errs)
|
|
|
|
return 1;
|
|
|
|
|
2008-05-28 21:48:57 +00:00
|
|
|
/* Now we are committed to check them out */
|
2019-04-25 09:45:50 +00:00
|
|
|
if (opts->checkout_worktree)
|
2020-03-10 18:20:39 +00:00
|
|
|
errs |= checkout_worktree(opts, new_branch_info);
|
restore: invalidate cache-tree when removing entries with --staged
When "git restore --staged <path>" removes a path that's in the index,
it marks the entry with CE_REMOVE, but we don't do anything to
invalidate the cache-tree. In the non-staged case, we end up in
checkout_worktree(), which calls remove_marked_cache_entries(). That
actually drops the entries from the index, as well as invalidating the
cache-tree and untracked-cache.
But with --staged, we never call checkout_worktree(), and the CE_REMOVE
entries remain. Interestingly, they are dropped when we write out the
index, but that means the resulting index is inconsistent: its
cache-tree will not match the actual entries, and running "git commit"
immediately after will create the wrong tree.
We can solve this by calling remove_marked_cache_entries() ourselves
before writing out the index. Note that we can't just hoist it out of
checkout_worktree(); that function needs to iterate over the CE_REMOVE
entries (to drop their matching worktree files) before removing them.
One curiosity about the test: without this patch, it actually triggers a
BUG() when running git-restore:
BUG: cache-tree.c:810: new1 with flags 0x4420000 should not be in cache-tree
But in the original problem report, which used a similar recipe,
git-restore actually creates the bogus index (and the commit is created
with the wrong tree). I'm not sure why the test here behaves differently
than my out-of-suite reproduction, but what's here should catch either
symptom (and the fix corrects both cases).
Reported-by: Torsten Krah <krah.tm@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-08 11:43:44 +00:00
|
|
|
else
|
|
|
|
remove_marked_cache_entries(&the_index, 1);
|
2017-06-30 20:41:28 +00:00
|
|
|
|
2019-04-25 09:45:50 +00:00
|
|
|
/*
|
|
|
|
* Allow updating the index when checking out from the index.
|
|
|
|
* This is to save new stat info.
|
|
|
|
*/
|
|
|
|
if (opts->checkout_worktree && !opts->checkout_index && !opts->source_tree)
|
|
|
|
checkout_index = 1;
|
|
|
|
else
|
|
|
|
checkout_index = opts->checkout_index;
|
2018-11-13 18:28:00 +00:00
|
|
|
|
2019-04-25 09:45:50 +00:00
|
|
|
if (checkout_index) {
|
|
|
|
if (write_locked_index(&the_index, &lock_file, COMMIT_LOCK))
|
|
|
|
die(_("unable to write new index file"));
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* NEEDSWORK: if --worktree is not specified, we
|
|
|
|
* should save stat info of checked out files in the
|
|
|
|
* index to avoid the next (potentially costly)
|
|
|
|
* refresh. But it's a bit tricker to do...
|
|
|
|
*/
|
|
|
|
rollback_lock_file(&lock_file);
|
2018-11-13 18:28:00 +00:00
|
|
|
}
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
|
2017-10-15 22:06:56 +00:00
|
|
|
read_ref_full("HEAD", 0, &rev, NULL);
|
2018-06-29 01:21:57 +00:00
|
|
|
head = lookup_commit_reference_gently(the_repository, &rev, 1);
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
|
2008-05-28 21:48:57 +00:00
|
|
|
errs |= post_checkout_hook(head, head, 0);
|
|
|
|
return errs;
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
}
|
|
|
|
|
2012-08-29 13:55:22 +00:00
|
|
|
static void show_local_changes(struct object *head,
|
|
|
|
const struct diff_options *opts)
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
{
|
|
|
|
struct rev_info rev;
|
|
|
|
/* I think we want full paths, even if we're in a subdirectory. */
|
2018-09-21 15:57:38 +00:00
|
|
|
repo_init_revisions(the_repository, &rev, NULL);
|
2010-08-25 10:34:57 +00:00
|
|
|
rev.diffopt.flags = opts->flags;
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
rev.diffopt.output_format |= DIFF_FORMAT_NAME_STATUS;
|
2022-08-08 19:07:49 +00:00
|
|
|
rev.diffopt.flags.recursive = 1;
|
2012-08-03 12:16:24 +00:00
|
|
|
diff_setup_done(&rev.diffopt);
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
add_pending_object(&rev, head, NULL);
|
|
|
|
run_diff_index(&rev, 0);
|
revision.[ch]: provide and start using a release_revisions()
The users of the revision.[ch] API's "struct rev_info" are a major
source of memory leaks in the test suite under SANITIZE=leak, which in
turn adds a lot of noise when trying to mark up tests with
"TEST_PASSES_SANITIZE_LEAK=true".
The users of that API are largely one-shot, e.g. "git rev-list" or
"git log", or the "git checkout" and "git stash" being modified here
For these callers freeing the memory is arguably a waste of time, but
in many cases they've actually been trying to free the memory, and
just doing that in a buggy manner.
Let's provide a release_revisions() function for these users, and
start migrating them over per the plan outlined in [1]. Right now this
only handles the "pending" member of the struct, but more will be
added in subsequent commits.
Even though we only clear the "pending" member now, let's not leave a
trap in code like the pre-image of index_differs_from(), where we'd
start doing the wrong thing as soon as the release_revisions() learned
to clear its "diffopt". I.e. we need to call release_revisions() after
we've inspected any state in "struct rev_info".
This leaves in place e.g. clear_pathspec(&rev.prune_data) in
stash_working_tree() in builtin/stash.c, subsequent commits will teach
release_revisions() to free "prune_data" and other members that in
some cases are individually cleared by users of "struct rev_info" by
reaching into its members. Those subsequent commits will remove the
relevant calls to e.g. clear_pathspec().
We avoid amending code in index_differs_from() in diff-lib.c as well
as wt_status_collect_changes_index(), has_unstaged_changes() and
has_uncommitted_changes() in wt-status.c in a way that assumes that we
are already clearing the "diffopt" member. That will be handled in a
subsequent commit.
1. https://lore.kernel.org/git/87a6k8daeu.fsf@evledraar.gmail.com/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-13 20:01:35 +00:00
|
|
|
release_revisions(&rev);
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
}
|
|
|
|
|
2011-02-22 22:43:22 +00:00
|
|
|
static void describe_detached_head(const char *msg, struct commit *commit)
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
{
|
2008-10-09 19:12:12 +00:00
|
|
|
struct strbuf sb = STRBUF_INIT;
|
2017-12-06 00:20:42 +00:00
|
|
|
|
2023-03-28 13:58:48 +00:00
|
|
|
if (!repo_parse_commit(the_repository, commit))
|
2013-10-24 08:54:53 +00:00
|
|
|
pp_commit_easy(CMIT_FMT_ONELINE, commit, &sb);
|
2017-12-06 00:20:42 +00:00
|
|
|
if (print_sha1_ellipsis()) {
|
|
|
|
fprintf(stderr, "%s %s... %s\n", msg,
|
2023-03-28 13:58:46 +00:00
|
|
|
repo_find_unique_abbrev(the_repository, &commit->object.oid, DEFAULT_ABBREV),
|
|
|
|
sb.buf);
|
2017-12-06 00:20:42 +00:00
|
|
|
} else {
|
|
|
|
fprintf(stderr, "%s %s %s\n", msg,
|
2023-03-28 13:58:46 +00:00
|
|
|
repo_find_unique_abbrev(the_repository, &commit->object.oid, DEFAULT_ABBREV),
|
|
|
|
sb.buf);
|
2017-12-06 00:20:42 +00:00
|
|
|
}
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
strbuf_release(&sb);
|
|
|
|
}
|
|
|
|
|
2012-08-29 13:55:22 +00:00
|
|
|
static int reset_tree(struct tree *tree, const struct checkout_opts *o,
|
2020-03-16 18:05:04 +00:00
|
|
|
int worktree, int *writeout_error,
|
|
|
|
struct branch_info *info)
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
{
|
|
|
|
struct unpack_trees_options opts;
|
|
|
|
struct tree_desc tree_desc;
|
2008-03-06 20:26:14 +00:00
|
|
|
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
memset(&opts, 0, sizeof(opts));
|
|
|
|
opts.head_idx = -1;
|
2008-05-28 21:59:40 +00:00
|
|
|
opts.update = worktree;
|
|
|
|
opts.skip_unmerged = !worktree;
|
2021-09-27 16:33:44 +00:00
|
|
|
opts.reset = o->force ? UNPACK_RESET_OVERWRITE_UNTRACKED :
|
|
|
|
UNPACK_RESET_PROTECT_UNTRACKED;
|
|
|
|
opts.preserve_ignored = (!o->force && !o->overwrite_ignore);
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
opts.merge = 1;
|
|
|
|
opts.fn = oneway_merge;
|
2015-11-01 21:19:05 +00:00
|
|
|
opts.verbose_update = o->show_progress;
|
2008-03-07 02:12:28 +00:00
|
|
|
opts.src_index = &the_index;
|
|
|
|
opts.dst_index = &the_index;
|
2020-03-16 18:05:04 +00:00
|
|
|
init_checkout_metadata(&opts.meta, info->refname,
|
2021-04-26 01:02:56 +00:00
|
|
|
info->commit ? &info->commit->object.oid : null_oid(),
|
2020-03-16 18:05:04 +00:00
|
|
|
NULL);
|
2024-02-23 08:34:23 +00:00
|
|
|
if (parse_tree(tree) < 0)
|
|
|
|
return 128;
|
2023-10-02 02:40:28 +00:00
|
|
|
init_tree_desc(&tree_desc, &tree->object.oid, tree->buffer, tree->size);
|
2008-05-28 22:26:59 +00:00
|
|
|
switch (unpack_trees(1, &tree_desc, &opts)) {
|
|
|
|
case -2:
|
2012-08-29 13:55:22 +00:00
|
|
|
*writeout_error = 1;
|
2008-05-28 22:26:59 +00:00
|
|
|
/*
|
|
|
|
* We return 0 nevertheless, as the index is all right
|
|
|
|
* and more importantly we have made best efforts to
|
|
|
|
* update paths in the work tree, and we cannot revert
|
|
|
|
* them.
|
|
|
|
*/
|
consistently use "fallthrough" comments in switches
Gcc 7 adds -Wimplicit-fallthrough, which can warn when a
switch case falls through to the next case. The general idea
is that the compiler can't tell if this was intentional or
not, so you should annotate any intentional fall-throughs as
such, leaving it to complain about any unannotated ones.
There's a GNU __attribute__ which can be used for
annotation, but of course we'd have to #ifdef it away on
non-gcc compilers. Gcc will also recognize
specially-formatted comments, which matches our current
practice. Let's extend that practice to all of the
unannotated sites (which I did look over and verify that
they were behaving as intended).
Ideally in each case we'd actually give some reasons in the
comment about why we're falling through, or what we're
falling through to. And gcc does support that with
-Wimplicit-fallthrough=2, which relaxes the comment pattern
matching to anything that contains "fallthrough" (or a
variety of spelling variants). However, this isn't the
default for -Wimplicit-fallthrough, nor for -Wextra. In the
name of simplicity, it's probably better for us to support
the default level, which requires "fallthrough" to be the
only thing in the comment (modulo some window dressing like
"else" and some punctuation; see the gcc manual for the
complete set of patterns).
This patch suppresses all warnings due to
-Wimplicit-fallthrough. We might eventually want to add that
to the DEVELOPER Makefile knob, but we should probably wait
until gcc 7 is more widely adopted (since earlier versions
will complain about the unknown warning type).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-21 06:25:41 +00:00
|
|
|
/* fallthrough */
|
2008-05-28 22:26:59 +00:00
|
|
|
case 0:
|
|
|
|
return 0;
|
|
|
|
default:
|
2008-05-28 21:54:02 +00:00
|
|
|
return 128;
|
2008-05-28 22:26:59 +00:00
|
|
|
}
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void setup_branch_path(struct branch_info *branch)
|
|
|
|
{
|
2008-10-09 19:12:12 +00:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2009-01-17 16:09:53 +00:00
|
|
|
|
2020-03-16 18:05:03 +00:00
|
|
|
/*
|
|
|
|
* If this is a ref, resolve it; otherwise, look up the OID for our
|
|
|
|
* expression. Failure here is okay.
|
|
|
|
*/
|
2023-03-28 13:58:54 +00:00
|
|
|
if (!repo_dwim_ref(the_repository, branch->name, strlen(branch->name),
|
|
|
|
&branch->oid, &branch->refname, 0))
|
2020-03-16 18:05:03 +00:00
|
|
|
repo_get_oid_committish(the_repository, branch->name, &branch->oid);
|
|
|
|
|
2017-03-02 08:23:18 +00:00
|
|
|
strbuf_branchname(&buf, branch->name, INTERPRET_BRANCH_LOCAL);
|
2021-11-16 18:27:38 +00:00
|
|
|
if (strcmp(buf.buf, branch->name)) {
|
|
|
|
free(branch->name);
|
2009-01-17 16:09:53 +00:00
|
|
|
branch->name = xstrdup(buf.buf);
|
2021-11-16 18:27:38 +00:00
|
|
|
}
|
2009-03-21 20:17:30 +00:00
|
|
|
strbuf_splice(&buf, 0, 0, "refs/heads/", 11);
|
2021-11-16 18:27:38 +00:00
|
|
|
free(branch->path);
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
branch->path = strbuf_detach(&buf, NULL);
|
|
|
|
}
|
|
|
|
|
checkout: avoid "struct unpack_trees_options" leak
In 1c41d2805e4 (unpack_trees_options: free messages when done,
2018-05-21) we started calling clear_unpack_trees_porcelain() on this
codepath, but missed this error path.
We could call clear_unpack_trees_porcelain() just before we error()
and return when unmerged_cache() fails, but the more correct fix is to
not have the unmerged_cache() check happen in the middle of our
"topts" setup.
Before 23cbf11b5c0 (merge-recursive: porcelain messages for checkout,
2010-08-11) we would not malloc() to setup our "topts", which is when
this started to leak on the error path.
Before that this code wasn't conflating the setup of "topts" and the
unmerged_cache() call in any meaningful way. The initial version in
782c2d65c24 (Build in checkout, 2008-02-07) just does a "memset" of
it, and initializes a single struct member.
Then in 8ccba008ee3 (unpack-trees: allow Porcelain to give different
error messages, 2008-05-17) we added the initialization of the error
message, which as noted above finally started leaking in 23cbf11b5c0.
Let's fix the memory leak, and avoid future issues by initializing the
"topts" with a helper function. There are no functional changes here.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-01 10:42:57 +00:00
|
|
|
static void init_topts(struct unpack_trees_options *topts, int merge,
|
|
|
|
int show_progress, int overwrite_ignore,
|
|
|
|
struct commit *old_commit)
|
|
|
|
{
|
|
|
|
memset(topts, 0, sizeof(*topts));
|
|
|
|
topts->head_idx = -1;
|
|
|
|
topts->src_index = &the_index;
|
|
|
|
topts->dst_index = &the_index;
|
|
|
|
|
|
|
|
setup_unpack_trees_porcelain(topts, "checkout");
|
|
|
|
|
2022-11-19 13:07:30 +00:00
|
|
|
topts->initial_checkout = is_index_unborn(&the_index);
|
checkout: avoid "struct unpack_trees_options" leak
In 1c41d2805e4 (unpack_trees_options: free messages when done,
2018-05-21) we started calling clear_unpack_trees_porcelain() on this
codepath, but missed this error path.
We could call clear_unpack_trees_porcelain() just before we error()
and return when unmerged_cache() fails, but the more correct fix is to
not have the unmerged_cache() check happen in the middle of our
"topts" setup.
Before 23cbf11b5c0 (merge-recursive: porcelain messages for checkout,
2010-08-11) we would not malloc() to setup our "topts", which is when
this started to leak on the error path.
Before that this code wasn't conflating the setup of "topts" and the
unmerged_cache() call in any meaningful way. The initial version in
782c2d65c24 (Build in checkout, 2008-02-07) just does a "memset" of
it, and initializes a single struct member.
Then in 8ccba008ee3 (unpack-trees: allow Porcelain to give different
error messages, 2008-05-17) we added the initialization of the error
message, which as noted above finally started leaking in 23cbf11b5c0.
Let's fix the memory leak, and avoid future issues by initializing the
"topts" with a helper function. There are no functional changes here.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-01 10:42:57 +00:00
|
|
|
topts->update = 1;
|
|
|
|
topts->merge = 1;
|
|
|
|
topts->quiet = merge && old_commit;
|
|
|
|
topts->verbose_update = show_progress;
|
|
|
|
topts->fn = twoway_merge;
|
|
|
|
topts->preserve_ignored = !overwrite_ignore;
|
|
|
|
}
|
|
|
|
|
2012-08-29 13:55:22 +00:00
|
|
|
static int merge_working_tree(const struct checkout_opts *opts,
|
2018-02-14 18:59:31 +00:00
|
|
|
struct branch_info *old_branch_info,
|
|
|
|
struct branch_info *new_branch_info,
|
2012-08-29 13:55:22 +00:00
|
|
|
int *writeout_error)
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
{
|
|
|
|
int ret;
|
2017-10-05 20:32:04 +00:00
|
|
|
struct lock_file lock_file = LOCK_INIT;
|
2019-03-29 10:39:16 +00:00
|
|
|
struct tree *new_tree;
|
2008-12-06 01:54:10 +00:00
|
|
|
|
2022-11-19 13:07:38 +00:00
|
|
|
repo_hold_locked_index(the_repository, &lock_file, LOCK_DIE_ON_ERROR);
|
|
|
|
if (repo_read_index_preload(the_repository, NULL, 0) < 0)
|
2016-06-17 20:21:20 +00:00
|
|
|
return error(_("index file corrupt"));
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
|
2022-11-19 13:07:33 +00:00
|
|
|
resolve_undo_clear_index(&the_index);
|
2019-03-29 10:39:16 +00:00
|
|
|
if (opts->new_orphan_branch && opts->orphan_from_empty_tree) {
|
|
|
|
if (new_branch_info->commit)
|
|
|
|
BUG("'switch --orphan' should never accept a commit as starting point");
|
|
|
|
new_tree = parse_tree_indirect(the_hash_algo->empty_tree);
|
2024-02-23 08:34:23 +00:00
|
|
|
if (!new_tree)
|
|
|
|
BUG("unable to read empty tree");
|
|
|
|
} else {
|
2023-03-28 13:58:48 +00:00
|
|
|
new_tree = repo_get_commit_tree(the_repository,
|
|
|
|
new_branch_info->commit);
|
2024-02-23 08:34:23 +00:00
|
|
|
if (!new_tree)
|
|
|
|
return error(_("unable to read tree (%s)"),
|
|
|
|
oid_to_hex(&new_branch_info->commit->object.oid));
|
|
|
|
}
|
2019-03-29 10:39:07 +00:00
|
|
|
if (opts->discard_changes) {
|
2020-03-16 18:05:04 +00:00
|
|
|
ret = reset_tree(new_tree, opts, 1, writeout_error, new_branch_info);
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
} else {
|
|
|
|
struct tree_desc trees[2];
|
|
|
|
struct tree *tree;
|
|
|
|
struct unpack_trees_options topts;
|
2022-03-02 00:36:13 +00:00
|
|
|
const struct object_id *old_commit_oid;
|
2008-03-06 20:26:14 +00:00
|
|
|
|
2022-11-19 13:07:38 +00:00
|
|
|
refresh_index(&the_index, REFRESH_QUIET, NULL, NULL, NULL);
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
|
2022-11-19 13:07:30 +00:00
|
|
|
if (unmerged_index(&the_index)) {
|
2011-02-22 23:41:39 +00:00
|
|
|
error(_("you need to resolve your current index first"));
|
2008-02-23 23:45:19 +00:00
|
|
|
return 1;
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
}
|
2008-02-23 23:45:19 +00:00
|
|
|
|
|
|
|
/* 2-way merge to the new branch */
|
checkout: avoid "struct unpack_trees_options" leak
In 1c41d2805e4 (unpack_trees_options: free messages when done,
2018-05-21) we started calling clear_unpack_trees_porcelain() on this
codepath, but missed this error path.
We could call clear_unpack_trees_porcelain() just before we error()
and return when unmerged_cache() fails, but the more correct fix is to
not have the unmerged_cache() check happen in the middle of our
"topts" setup.
Before 23cbf11b5c0 (merge-recursive: porcelain messages for checkout,
2010-08-11) we would not malloc() to setup our "topts", which is when
this started to leak on the error path.
Before that this code wasn't conflating the setup of "topts" and the
unmerged_cache() call in any meaningful way. The initial version in
782c2d65c24 (Build in checkout, 2008-02-07) just does a "memset" of
it, and initializes a single struct member.
Then in 8ccba008ee3 (unpack-trees: allow Porcelain to give different
error messages, 2008-05-17) we added the initialization of the error
message, which as noted above finally started leaking in 23cbf11b5c0.
Let's fix the memory leak, and avoid future issues by initializing the
"topts" with a helper function. There are no functional changes here.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-01 10:42:57 +00:00
|
|
|
init_topts(&topts, opts->merge, opts->show_progress,
|
|
|
|
opts->overwrite_ignore, old_branch_info->commit);
|
2020-03-16 18:05:04 +00:00
|
|
|
init_checkout_metadata(&topts.meta, new_branch_info->refname,
|
|
|
|
new_branch_info->commit ?
|
|
|
|
&new_branch_info->commit->object.oid :
|
|
|
|
&new_branch_info->oid, NULL);
|
2022-03-02 00:36:13 +00:00
|
|
|
|
|
|
|
old_commit_oid = old_branch_info->commit ?
|
|
|
|
&old_branch_info->commit->object.oid :
|
|
|
|
the_hash_algo->empty_tree;
|
|
|
|
tree = parse_tree_indirect(old_commit_oid);
|
|
|
|
if (!tree)
|
|
|
|
die(_("unable to parse commit %s"),
|
|
|
|
oid_to_hex(old_commit_oid));
|
|
|
|
|
2023-10-02 02:40:28 +00:00
|
|
|
init_tree_desc(&trees[0], &tree->object.oid,
|
|
|
|
tree->buffer, tree->size);
|
2024-02-23 08:34:23 +00:00
|
|
|
if (parse_tree(new_tree) < 0)
|
|
|
|
exit(128);
|
2019-03-29 10:39:16 +00:00
|
|
|
tree = new_tree;
|
2023-10-02 02:40:28 +00:00
|
|
|
init_tree_desc(&trees[1], &tree->object.oid,
|
|
|
|
tree->buffer, tree->size);
|
2008-02-23 23:45:19 +00:00
|
|
|
|
2008-05-28 22:26:59 +00:00
|
|
|
ret = unpack_trees(2, trees, &topts);
|
2018-05-21 14:54:28 +00:00
|
|
|
clear_unpack_trees_porcelain(&topts);
|
2009-05-12 16:41:28 +00:00
|
|
|
if (ret == -1) {
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
/*
|
|
|
|
* Unpack couldn't do a trivial merge; either
|
|
|
|
* give up or do a real merge, depending on
|
|
|
|
* whether the merge flag was used.
|
|
|
|
*/
|
|
|
|
struct tree *work;
|
2019-03-22 09:31:38 +00:00
|
|
|
struct tree *old_tree;
|
2008-08-25 14:25:57 +00:00
|
|
|
struct merge_options o;
|
checkout.txt: note about losing staged changes with --merge
If you have staged changes in path A and perform 'checkout
--merge' (which could result in conflicts in a totally unrelated path
B), changes in A will be gone. Which is unexpected. We are supposed
to keep all changes, or kick and scream otherwise.
This is the result of how --merge is implemented, from the very first
day in 1be0659efc (checkout: merge local modifications while switching
branches., 2006-01-12):
1. a merge is done, unmerged entries are collected
2. a hard switch to a new branch is done, then unmerged entries added
back
There is no trivial fix for this. Going with 3-way merge one file at a
time loses rename detection. Going with 3-way merge by trees requires
teaching the algorithm to pick up staged changes. And even if we detect
staged changes with --merge and abort for safety, an option to continue
--merge is very weird. Such an option would keep worktree changes, but
drop staged changes.
Because the problem has been with us since the introduction of --merge
and everybody has been pretty happy (except Phillip, who found this
problem), I'll just take a note here to acknowledge it and wait for
merge wizards to come in and work their magic. There may be a way
forward [1].
[1] CABPp-BFoL_U=bzON4SEMaQSKU2TKwnOgNqjt5MUaOejTKGUJxw@mail.gmail.com
Reported-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-19 09:39:10 +00:00
|
|
|
struct strbuf sb = STRBUF_INIT;
|
2019-08-15 21:40:31 +00:00
|
|
|
struct strbuf old_commit_shortname = STRBUF_INIT;
|
checkout.txt: note about losing staged changes with --merge
If you have staged changes in path A and perform 'checkout
--merge' (which could result in conflicts in a totally unrelated path
B), changes in A will be gone. Which is unexpected. We are supposed
to keep all changes, or kick and scream otherwise.
This is the result of how --merge is implemented, from the very first
day in 1be0659efc (checkout: merge local modifications while switching
branches., 2006-01-12):
1. a merge is done, unmerged entries are collected
2. a hard switch to a new branch is done, then unmerged entries added
back
There is no trivial fix for this. Going with 3-way merge one file at a
time loses rename detection. Going with 3-way merge by trees requires
teaching the algorithm to pick up staged changes. And even if we detect
staged changes with --merge and abort for safety, an option to continue
--merge is very weird. Such an option would keep worktree changes, but
drop staged changes.
Because the problem has been with us since the introduction of --merge
and everybody has been pretty happy (except Phillip, who found this
problem), I'll just take a note here to acknowledge it and wait for
merge wizards to come in and work their magic. There may be a way
forward [1].
[1] CABPp-BFoL_U=bzON4SEMaQSKU2TKwnOgNqjt5MUaOejTKGUJxw@mail.gmail.com
Reported-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-19 09:39:10 +00:00
|
|
|
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
if (!opts->merge)
|
|
|
|
return 1;
|
2010-01-07 07:51:47 +00:00
|
|
|
|
|
|
|
/*
|
2018-02-14 18:59:31 +00:00
|
|
|
* Without old_branch_info->commit, the below is the same as
|
2010-01-07 07:51:47 +00:00
|
|
|
* the two-tree unpack we already tried and failed.
|
|
|
|
*/
|
2018-02-14 18:59:31 +00:00
|
|
|
if (!old_branch_info->commit)
|
2010-01-07 07:51:47 +00:00
|
|
|
return 1;
|
2023-03-28 13:58:48 +00:00
|
|
|
old_tree = repo_get_commit_tree(the_repository,
|
|
|
|
old_branch_info->commit);
|
2019-03-22 09:31:38 +00:00
|
|
|
|
|
|
|
if (repo_index_has_changes(the_repository, old_tree, &sb))
|
|
|
|
die(_("cannot continue with staged changes in "
|
|
|
|
"the following files:\n%s"), sb.buf);
|
|
|
|
strbuf_release(&sb);
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
|
|
|
|
/* Do more real merge */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We update the index fully, then write the
|
|
|
|
* tree from the index, then merge the new
|
|
|
|
* branch with the current tree, with the old
|
|
|
|
* branch as the base. Then we reset the index
|
|
|
|
* (but not the working tree) to the new
|
|
|
|
* branch, leaving the working tree as the
|
|
|
|
* merged version, but skipping unmerged
|
|
|
|
* entries in the index.
|
|
|
|
*/
|
|
|
|
|
2024-04-03 18:14:48 +00:00
|
|
|
add_files_to_cache(the_repository, NULL, NULL, NULL, 0,
|
|
|
|
0);
|
2019-01-12 02:13:29 +00:00
|
|
|
init_merge_options(&o, the_repository);
|
2008-08-25 14:25:57 +00:00
|
|
|
o.verbosity = 0;
|
2019-08-17 18:41:32 +00:00
|
|
|
work = write_in_core_index_as_tree(the_repository);
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
|
2019-03-29 10:39:16 +00:00
|
|
|
ret = reset_tree(new_tree,
|
2018-04-06 19:09:38 +00:00
|
|
|
opts, 1,
|
2020-03-16 18:05:04 +00:00
|
|
|
writeout_error, new_branch_info);
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2018-02-14 18:59:31 +00:00
|
|
|
o.ancestor = old_branch_info->name;
|
2022-05-02 16:50:37 +00:00
|
|
|
if (!old_branch_info->name) {
|
2019-08-15 21:40:31 +00:00
|
|
|
strbuf_add_unique_abbrev(&old_commit_shortname,
|
|
|
|
&old_branch_info->commit->object.oid,
|
|
|
|
DEFAULT_ABBREV);
|
|
|
|
o.ancestor = old_commit_shortname.buf;
|
|
|
|
}
|
2018-02-14 18:59:31 +00:00
|
|
|
o.branch1 = new_branch_info->name;
|
2008-08-25 14:25:57 +00:00
|
|
|
o.branch2 = "local";
|
2024-03-14 17:05:06 +00:00
|
|
|
o.conflict_style = opts->conflict_style;
|
2018-04-06 19:09:38 +00:00
|
|
|
ret = merge_trees(&o,
|
2019-03-29 10:39:16 +00:00
|
|
|
new_tree,
|
2018-04-06 19:09:38 +00:00
|
|
|
work,
|
2019-08-17 18:41:30 +00:00
|
|
|
old_tree);
|
prepare the builtins for a libified merge_recursive()
Previously, callers of merge_trees() or merge_recursive() expected that
code to die() with an error message. This used to be okay because we
called those commands from scripts, and had a chance to print out a
message in case the command failed fatally (read: with exit code 128).
As scripting incurs its own set of problems (portability, speed,
idiosyncrasies of different shells, limited data structures leading to
inefficient code), we are converting more and more of these scripts into
builtins, using library functions directly.
We already tried to use merge_recursive() directly in the builtin
git-am, for example. Unfortunately, we had to roll it back temporarily
because some of the code in merge-recursive.c still deemed it okay to
call die(), when the builtin am code really wanted to print out a useful
advice after the merge failed fatally. In the next commits, we want to
fix that.
The code touched by this commit expected merge_trees() to die() with
some useful message when there is an error condition, but merge_trees()
is going to be improved by converting all die() calls to return error()
instead (i.e. return value -1 after printing out the message as before),
so that the caller can react more flexibly.
This is a step to prepare for the version of merge_trees() that no
longer dies, even if we just imitate the previous behavior by calling
exit(128): this is what callers of e.g. `git merge` have come to expect.
Note that the callers of the sequencer (revert and cherry-pick) already
fail fast even for the return value -1; The only difference is that they
now get a chance to say "<command> failed".
A caller of merge_trees() might want handle error messages themselves
(or even suppress them). As this patch is already complex enough, we
leave that change for a later patch.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-26 16:06:02 +00:00
|
|
|
if (ret < 0)
|
|
|
|
exit(128);
|
2019-03-29 10:39:16 +00:00
|
|
|
ret = reset_tree(new_tree,
|
2018-04-06 19:09:38 +00:00
|
|
|
opts, 0,
|
2020-03-16 18:05:04 +00:00
|
|
|
writeout_error, new_branch_info);
|
2016-08-01 11:44:53 +00:00
|
|
|
strbuf_release(&o.obuf);
|
2019-08-15 21:40:31 +00:00
|
|
|
strbuf_release(&old_commit_shortname);
|
2008-05-28 21:54:02 +00:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-11-19 13:07:34 +00:00
|
|
|
if (!cache_tree_fully_valid(the_index.cache_tree))
|
2014-09-11 17:33:32 +00:00
|
|
|
cache_tree_update(&the_index, WRITE_TREE_SILENT | WRITE_TREE_REPAIR);
|
2014-07-06 04:06:56 +00:00
|
|
|
|
2017-10-05 20:32:04 +00:00
|
|
|
if (write_locked_index(&the_index, &lock_file, COMMIT_LOCK))
|
2011-02-22 23:41:39 +00:00
|
|
|
die(_("unable to write new index file"));
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
|
2019-03-29 10:39:16 +00:00
|
|
|
if (!opts->discard_changes && !opts->quiet && new_branch_info->commit)
|
2018-02-14 18:59:31 +00:00
|
|
|
show_local_changes(&new_branch_info->commit->object, &opts->diff_options);
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-02-14 18:59:31 +00:00
|
|
|
static void report_tracking(struct branch_info *new_branch_info)
|
2008-02-17 01:17:09 +00:00
|
|
|
{
|
2008-07-02 07:51:18 +00:00
|
|
|
struct strbuf sb = STRBUF_INIT;
|
2018-02-14 18:59:31 +00:00
|
|
|
struct branch *branch = branch_get(new_branch_info->name);
|
2008-02-17 01:17:09 +00:00
|
|
|
|
2023-07-13 04:41:13 +00:00
|
|
|
if (!format_tracking_info(branch, &sb, AHEAD_BEHIND_FULL, 1))
|
2008-02-17 01:17:09 +00:00
|
|
|
return;
|
2008-07-02 07:51:18 +00:00
|
|
|
fputs(sb.buf, stdout);
|
|
|
|
strbuf_release(&sb);
|
2008-02-20 23:05:23 +00:00
|
|
|
}
|
2008-02-17 01:17:09 +00:00
|
|
|
|
2012-08-29 13:55:22 +00:00
|
|
|
static void update_refs_for_switch(const struct checkout_opts *opts,
|
2018-02-14 18:59:31 +00:00
|
|
|
struct branch_info *old_branch_info,
|
|
|
|
struct branch_info *new_branch_info)
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
{
|
2008-10-09 19:12:12 +00:00
|
|
|
struct strbuf msg = STRBUF_INIT;
|
2013-06-16 08:45:16 +00:00
|
|
|
const char *old_desc, *reflog_msg;
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
if (opts->new_branch) {
|
2010-05-22 00:28:37 +00:00
|
|
|
if (opts->new_orphan_branch) {
|
2017-01-27 10:09:47 +00:00
|
|
|
char *refname;
|
|
|
|
|
|
|
|
refname = mkpathdup("refs/heads/%s", opts->new_orphan_branch);
|
|
|
|
if (opts->new_branch_log &&
|
|
|
|
!should_autocreate_reflog(refname)) {
|
2014-11-30 08:24:28 +00:00
|
|
|
int ret;
|
2015-07-21 21:04:50 +00:00
|
|
|
struct strbuf err = STRBUF_INIT;
|
2010-05-22 00:28:37 +00:00
|
|
|
|
2021-11-22 14:19:08 +00:00
|
|
|
ret = safe_create_reflog(refname, &err);
|
2014-11-30 08:24:28 +00:00
|
|
|
if (ret) {
|
2015-07-21 21:04:50 +00:00
|
|
|
fprintf(stderr, _("Can not do reflog for '%s': %s\n"),
|
|
|
|
opts->new_orphan_branch, err.buf);
|
|
|
|
strbuf_release(&err);
|
2017-01-27 10:09:47 +00:00
|
|
|
free(refname);
|
2010-05-22 00:28:37 +00:00
|
|
|
return;
|
|
|
|
}
|
2015-07-21 21:04:52 +00:00
|
|
|
strbuf_release(&err);
|
2010-05-22 00:28:37 +00:00
|
|
|
}
|
2017-01-27 10:09:47 +00:00
|
|
|
free(refname);
|
2010-05-22 00:28:37 +00:00
|
|
|
}
|
|
|
|
else
|
2018-11-10 05:49:00 +00:00
|
|
|
create_branch(the_repository,
|
|
|
|
opts->new_branch, new_branch_info->name,
|
2010-06-23 19:29:00 +00:00
|
|
|
opts->new_branch_force ? 1 : 0,
|
2011-11-26 08:54:55 +00:00
|
|
|
opts->new_branch_force ? 1 : 0,
|
2017-11-18 17:26:46 +00:00
|
|
|
opts->new_branch_log,
|
2012-03-26 23:51:01 +00:00
|
|
|
opts->quiet,
|
2022-01-29 00:04:43 +00:00
|
|
|
opts->track,
|
|
|
|
0);
|
2021-11-16 18:27:38 +00:00
|
|
|
free(new_branch_info->name);
|
|
|
|
free(new_branch_info->refname);
|
|
|
|
new_branch_info->name = xstrdup(opts->new_branch);
|
2018-02-14 18:59:31 +00:00
|
|
|
setup_branch_path(new_branch_info);
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
}
|
|
|
|
|
2018-02-14 18:59:31 +00:00
|
|
|
old_desc = old_branch_info->name;
|
|
|
|
if (!old_desc && old_branch_info->commit)
|
|
|
|
old_desc = oid_to_hex(&old_branch_info->commit->object.oid);
|
2013-06-16 08:45:16 +00:00
|
|
|
|
|
|
|
reflog_msg = getenv("GIT_REFLOG_ACTION");
|
|
|
|
if (!reflog_msg)
|
|
|
|
strbuf_addf(&msg, "checkout: moving from %s to %s",
|
2018-02-14 18:59:31 +00:00
|
|
|
old_desc ? old_desc : "(invalid)", new_branch_info->name);
|
2013-06-16 08:45:16 +00:00
|
|
|
else
|
2020-02-09 13:44:23 +00:00
|
|
|
strbuf_insertstr(&msg, 0, reflog_msg);
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
|
2018-02-14 18:59:31 +00:00
|
|
|
if (!strcmp(new_branch_info->name, "HEAD") && !new_branch_info->path && !opts->force_detach) {
|
2011-02-08 10:34:34 +00:00
|
|
|
/* Nothing to do. */
|
2018-02-14 18:59:31 +00:00
|
|
|
} else if (opts->force_detach || !new_branch_info->path) { /* No longer on any branch. */
|
|
|
|
update_ref(msg.buf, "HEAD", &new_branch_info->commit->object.oid, NULL,
|
2017-11-05 08:42:06 +00:00
|
|
|
REF_NO_DEREF, UPDATE_REFS_DIE_ON_ERR);
|
2011-02-08 10:34:34 +00:00
|
|
|
if (!opts->quiet) {
|
2018-02-14 18:59:31 +00:00
|
|
|
if (old_branch_info->path &&
|
2021-08-23 10:44:00 +00:00
|
|
|
advice_enabled(ADVICE_DETACHED_HEAD) && !opts->force_detach)
|
2018-02-14 18:59:31 +00:00
|
|
|
detach_advice(new_branch_info->name);
|
|
|
|
describe_detached_head(_("HEAD is now at"), new_branch_info->commit);
|
2011-02-08 10:34:34 +00:00
|
|
|
}
|
2018-02-14 18:59:31 +00:00
|
|
|
} else if (new_branch_info->path) { /* Switch branches. */
|
|
|
|
if (create_symref("HEAD", new_branch_info->path, msg.buf) < 0)
|
2016-02-27 06:41:54 +00:00
|
|
|
die(_("unable to update HEAD"));
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
if (!opts->quiet) {
|
2018-02-14 18:59:31 +00:00
|
|
|
if (old_branch_info->path && !strcmp(new_branch_info->path, old_branch_info->path)) {
|
2011-11-26 08:54:55 +00:00
|
|
|
if (opts->new_branch_force)
|
|
|
|
fprintf(stderr, _("Reset branch '%s'\n"),
|
2018-02-14 18:59:31 +00:00
|
|
|
new_branch_info->name);
|
2011-11-26 08:54:55 +00:00
|
|
|
else
|
|
|
|
fprintf(stderr, _("Already on '%s'\n"),
|
2018-02-14 18:59:31 +00:00
|
|
|
new_branch_info->name);
|
2011-02-22 23:41:43 +00:00
|
|
|
} else if (opts->new_branch) {
|
|
|
|
if (opts->branch_exists)
|
2018-02-14 18:59:31 +00:00
|
|
|
fprintf(stderr, _("Switched to and reset branch '%s'\n"), new_branch_info->name);
|
2011-02-22 23:41:43 +00:00
|
|
|
else
|
2018-02-14 18:59:31 +00:00
|
|
|
fprintf(stderr, _("Switched to a new branch '%s'\n"), new_branch_info->name);
|
2011-02-22 23:41:43 +00:00
|
|
|
} else {
|
2011-02-22 23:41:39 +00:00
|
|
|
fprintf(stderr, _("Switched to branch '%s'\n"),
|
2018-02-14 18:59:31 +00:00
|
|
|
new_branch_info->name);
|
2011-02-22 23:41:43 +00:00
|
|
|
}
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
}
|
2018-02-14 18:59:31 +00:00
|
|
|
if (old_branch_info->path && old_branch_info->name) {
|
|
|
|
if (!ref_exists(old_branch_info->path) && reflog_exists(old_branch_info->path))
|
|
|
|
delete_reflog(old_branch_info->path);
|
2010-05-22 00:28:37 +00:00
|
|
|
}
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
}
|
2019-03-29 10:38:59 +00:00
|
|
|
remove_branch_state(the_repository, !opts->quiet);
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
strbuf_release(&msg);
|
2011-02-08 10:32:49 +00:00
|
|
|
if (!opts->quiet &&
|
checkout: omit "tracking" information on a detached HEAD
By definition, a detached HEAD state is tentative and there is no
configured "upstream" that it always wants to integrate with. But
if you detach from a branch that is behind its upstream, e.g.,
$ git checkout -t -b main origin/main
$ git checkout main
$ git reset --hard HEAD^
$ git checkout --detach main
you'd see "you are behind your upstream origin/main". This does not
happen when you replace the last step in the above with any of these
$ git checkout HEAD^0
$ git checkout --detach HEAD
$ git checkout --detach origin/main
Before 32669671 (checkout: introduce --detach synonym for "git
checkout foo^{commit}", 2011-02-08) introduced the "--detach"
option, the rule to decide if we show the tracking information
used to be:
If --quiet is not given, and if the given branch name is a real
local branch (i.e. the one we can compute the file path under
.git/, like 'refs/heads/master' or "HEAD" which stand for the
name of the current branch", then give the tracking information.
to exclude things like "git checkout master^0" (which was the
official way to detach HEAD at the commit before that commit) and
"git checkout origin/master^0" from showing tracking information,
but still do show the tracking information for the current branch
for "git checkout HEAD". The introduction of an explicit option
"--detach" broke this subtley. The new rule should have been
If --quiet is given, do not bother with tracking info.
If --detach is given, do not bother with tracking info.
Otherwise, if we know that the branch name given is a real local
branch, or if we were given "HEAD" and "HEAD" is not detached,
then attempt to show the tracking info.
but it allowed "git checkout --detach master" to also show the
tracking info by mistake. Let's tighten the rule to fix this.
Reported-by: mirth hickford <mirth.hickford@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-30 21:37:14 +00:00
|
|
|
!opts->force_detach &&
|
|
|
|
(new_branch_info->path || !strcmp(new_branch_info->name, "HEAD")))
|
2018-02-14 18:59:31 +00:00
|
|
|
report_tracking(new_branch_info);
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
}
|
|
|
|
|
2011-10-01 15:51:39 +00:00
|
|
|
static int add_pending_uninteresting_ref(const char *refname,
|
2015-05-25 18:38:33 +00:00
|
|
|
const struct object_id *oid,
|
2022-08-25 17:09:48 +00:00
|
|
|
int flags UNUSED, void *cb_data)
|
2011-02-19 00:04:47 +00:00
|
|
|
{
|
2017-05-06 22:10:26 +00:00
|
|
|
add_pending_oid(cb_data, refname, oid, UNINTERESTING);
|
2011-03-20 09:09:18 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2011-02-19 00:04:47 +00:00
|
|
|
|
|
|
|
static void describe_one_orphan(struct strbuf *sb, struct commit *commit)
|
|
|
|
{
|
2011-03-20 09:19:01 +00:00
|
|
|
strbuf_addstr(sb, " ");
|
strbuf: convert strbuf_add_unique_abbrev to use struct object_id
Convert the declaration and definition of strbuf_add_unique_abbrev to
make it take a pointer to struct object_id. Predeclare the struct in
strbuf.h, as cache.h includes strbuf.h before it declares the struct,
and otherwise the struct declaration would have the wrong scope.
Apply the following semantic patch, along with the standard object_id
transforms, to adjust the callers:
@@
expression E1, E2, E3;
@@
- strbuf_add_unique_abbrev(E1, E2.hash, E3);
+ strbuf_add_unique_abbrev(E1, &E2, E3);
@@
expression E1, E2, E3;
@@
- strbuf_add_unique_abbrev(E1, E2->hash, E3);
+ strbuf_add_unique_abbrev(E1, E2, E3);
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-12 02:27:28 +00:00
|
|
|
strbuf_add_unique_abbrev(sb, &commit->object.oid, DEFAULT_ABBREV);
|
2011-03-20 09:19:01 +00:00
|
|
|
strbuf_addch(sb, ' ');
|
2023-03-28 13:58:48 +00:00
|
|
|
if (!repo_parse_commit(the_repository, commit))
|
2013-10-24 08:54:53 +00:00
|
|
|
pp_commit_easy(CMIT_FMT_ONELINE, commit, sb);
|
2011-02-19 00:04:47 +00:00
|
|
|
strbuf_addch(sb, '\n');
|
|
|
|
}
|
|
|
|
|
|
|
|
#define ORPHAN_CUTOFF 4
|
|
|
|
static void suggest_reattach(struct commit *commit, struct rev_info *revs)
|
|
|
|
{
|
|
|
|
struct commit *c, *last = NULL;
|
|
|
|
struct strbuf sb = STRBUF_INIT;
|
|
|
|
int lost = 0;
|
|
|
|
while ((c = get_revision(revs)) != NULL) {
|
|
|
|
if (lost < ORPHAN_CUTOFF)
|
|
|
|
describe_one_orphan(&sb, c);
|
|
|
|
last = c;
|
|
|
|
lost++;
|
|
|
|
}
|
|
|
|
if (ORPHAN_CUTOFF < lost) {
|
|
|
|
int more = lost - ORPHAN_CUTOFF;
|
|
|
|
if (more == 1)
|
|
|
|
describe_one_orphan(&sb, last);
|
|
|
|
else
|
2011-04-10 19:34:08 +00:00
|
|
|
strbuf_addf(&sb, _(" ... and %d more.\n"), more);
|
2011-02-19 00:04:47 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
fprintf(stderr,
|
2011-04-10 19:34:08 +00:00
|
|
|
Q_(
|
|
|
|
/* The singular version */
|
|
|
|
"Warning: you are leaving %d commit behind, "
|
|
|
|
"not connected to\n"
|
|
|
|
"any of your branches:\n\n"
|
2011-06-30 00:03:10 +00:00
|
|
|
"%s\n",
|
2011-04-10 19:34:08 +00:00
|
|
|
/* The plural version */
|
|
|
|
"Warning: you are leaving %d commits behind, "
|
2011-02-19 00:04:47 +00:00
|
|
|
"not connected to\n"
|
|
|
|
"any of your branches:\n\n"
|
2011-05-24 17:08:29 +00:00
|
|
|
"%s\n",
|
2011-04-10 19:34:08 +00:00
|
|
|
/* Give ngettext() the count */
|
|
|
|
lost),
|
|
|
|
lost,
|
2011-05-24 17:08:29 +00:00
|
|
|
sb.buf);
|
2011-02-19 00:04:47 +00:00
|
|
|
strbuf_release(&sb);
|
2011-05-24 17:08:29 +00:00
|
|
|
|
2021-08-23 10:44:00 +00:00
|
|
|
if (advice_enabled(ADVICE_DETACHED_HEAD))
|
2011-05-24 17:08:29 +00:00
|
|
|
fprintf(stderr,
|
2015-04-01 17:38:00 +00:00
|
|
|
Q_(
|
|
|
|
/* The singular version */
|
|
|
|
"If you want to keep it by creating a new branch, "
|
|
|
|
"this may be a good time\nto do so with:\n\n"
|
|
|
|
" git branch <new-branch-name> %s\n\n",
|
|
|
|
/* The plural version */
|
2011-05-24 17:08:29 +00:00
|
|
|
"If you want to keep them by creating a new branch, "
|
|
|
|
"this may be a good time\nto do so with:\n\n"
|
2015-04-01 17:38:00 +00:00
|
|
|
" git branch <new-branch-name> %s\n\n",
|
|
|
|
/* Give ngettext() the count */
|
|
|
|
lost),
|
2023-03-28 13:58:46 +00:00
|
|
|
repo_find_unique_abbrev(the_repository, &commit->object.oid, DEFAULT_ABBREV));
|
2011-02-19 00:04:47 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We are about to leave commit that was at the tip of a detached
|
|
|
|
* HEAD. If it is not reachable from any ref, this is the last chance
|
|
|
|
* for the user to do so without resorting to reflog.
|
|
|
|
*/
|
2018-02-14 18:59:31 +00:00
|
|
|
static void orphaned_commit_warning(struct commit *old_commit, struct commit *new_commit)
|
2011-02-19 00:04:47 +00:00
|
|
|
{
|
|
|
|
struct rev_info revs;
|
2018-02-14 18:59:31 +00:00
|
|
|
struct object *object = &old_commit->object;
|
2011-02-19 00:04:47 +00:00
|
|
|
|
2018-09-21 15:57:38 +00:00
|
|
|
repo_init_revisions(the_repository, &revs, NULL);
|
2011-10-01 15:51:39 +00:00
|
|
|
setup_revisions(0, NULL, &revs, NULL);
|
|
|
|
|
|
|
|
object->flags &= ~UNINTERESTING;
|
2015-11-10 02:22:28 +00:00
|
|
|
add_pending_object(&revs, object, oid_to_hex(&object->oid));
|
2011-10-01 15:51:39 +00:00
|
|
|
|
2015-05-25 18:38:33 +00:00
|
|
|
for_each_ref(add_pending_uninteresting_ref, &revs);
|
2019-03-29 10:39:16 +00:00
|
|
|
if (new_commit)
|
|
|
|
add_pending_oid(&revs, "HEAD",
|
|
|
|
&new_commit->object.oid,
|
|
|
|
UNINTERESTING);
|
2011-10-01 15:51:39 +00:00
|
|
|
|
2011-02-19 00:04:47 +00:00
|
|
|
if (prepare_revision_walk(&revs))
|
2011-04-02 00:55:55 +00:00
|
|
|
die(_("internal error in revision walk"));
|
2018-02-14 18:59:31 +00:00
|
|
|
if (!(old_commit->object.flags & UNINTERESTING))
|
|
|
|
suggest_reattach(old_commit, &revs);
|
2011-02-19 00:04:47 +00:00
|
|
|
else
|
2018-02-14 18:59:31 +00:00
|
|
|
describe_detached_head(_("Previous HEAD position was"), old_commit);
|
2011-03-20 09:09:18 +00:00
|
|
|
|
2017-09-22 23:34:51 +00:00
|
|
|
/* Clean up objects used, as they will be reused. */
|
2020-10-31 12:46:08 +00:00
|
|
|
repo_clear_commit_marks(the_repository, ALL_REV_FLAGS);
|
2022-04-13 20:01:36 +00:00
|
|
|
release_revisions(&revs);
|
2011-02-19 00:04:47 +00:00
|
|
|
}
|
|
|
|
|
2012-08-29 13:55:23 +00:00
|
|
|
static int switch_branches(const struct checkout_opts *opts,
|
2018-02-14 18:59:31 +00:00
|
|
|
struct branch_info *new_branch_info)
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
{
|
|
|
|
int ret = 0;
|
2021-11-16 18:27:38 +00:00
|
|
|
struct branch_info old_branch_info = { 0 };
|
2016-09-05 20:08:00 +00:00
|
|
|
struct object_id rev;
|
2012-08-29 13:55:22 +00:00
|
|
|
int flag, writeout_error = 0;
|
2019-03-29 10:39:14 +00:00
|
|
|
int do_merge = 1;
|
2019-02-22 22:25:08 +00:00
|
|
|
|
|
|
|
trace2_cmd_mode("branch");
|
|
|
|
|
2018-02-14 18:59:31 +00:00
|
|
|
memset(&old_branch_info, 0, sizeof(old_branch_info));
|
2021-11-16 18:27:38 +00:00
|
|
|
old_branch_info.path = resolve_refdup("HEAD", 0, &rev, &flag);
|
2018-02-14 18:59:31 +00:00
|
|
|
if (old_branch_info.path)
|
2018-06-29 01:21:57 +00:00
|
|
|
old_branch_info.commit = lookup_commit_reference_gently(the_repository, &rev, 1);
|
2011-12-13 14:17:48 +00:00
|
|
|
if (!(flag & REF_ISSYMREF))
|
2021-11-16 18:27:38 +00:00
|
|
|
FREE_AND_NULL(old_branch_info.path);
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
|
2021-11-16 18:27:38 +00:00
|
|
|
if (old_branch_info.path) {
|
|
|
|
const char *const prefix = "refs/heads/";
|
|
|
|
const char *p;
|
|
|
|
if (skip_prefix(old_branch_info.path, prefix, &p))
|
|
|
|
old_branch_info.name = xstrdup(p);
|
|
|
|
}
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
|
2019-03-29 10:39:16 +00:00
|
|
|
if (opts->new_orphan_branch && opts->orphan_from_empty_tree) {
|
|
|
|
if (new_branch_info->name)
|
|
|
|
BUG("'switch --orphan' should never accept a commit as starting point");
|
|
|
|
new_branch_info->commit = NULL;
|
2021-11-16 18:27:38 +00:00
|
|
|
new_branch_info->name = xstrdup("(empty)");
|
2019-03-29 10:39:16 +00:00
|
|
|
do_merge = 1;
|
|
|
|
}
|
|
|
|
|
2018-02-14 18:59:31 +00:00
|
|
|
if (!new_branch_info->name) {
|
2021-11-16 18:27:38 +00:00
|
|
|
new_branch_info->name = xstrdup("HEAD");
|
2018-02-14 18:59:31 +00:00
|
|
|
new_branch_info->commit = old_branch_info.commit;
|
|
|
|
if (!new_branch_info->commit)
|
2011-02-22 23:41:39 +00:00
|
|
|
die(_("You are on a branch yet to be born"));
|
2018-02-14 18:59:31 +00:00
|
|
|
parse_commit_or_die(new_branch_info->commit);
|
2019-03-29 10:39:14 +00:00
|
|
|
|
|
|
|
if (opts->only_merge_on_switching_branches)
|
|
|
|
do_merge = 0;
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
}
|
|
|
|
|
2019-03-29 10:39:14 +00:00
|
|
|
if (do_merge) {
|
2018-08-16 18:27:11 +00:00
|
|
|
ret = merge_working_tree(opts, &old_branch_info, new_branch_info, &writeout_error);
|
|
|
|
if (ret) {
|
2021-11-16 18:27:38 +00:00
|
|
|
branch_info_release(&old_branch_info);
|
2018-08-16 18:27:11 +00:00
|
|
|
return ret;
|
|
|
|
}
|
2011-12-13 14:17:48 +00:00
|
|
|
}
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
|
2018-02-14 18:59:31 +00:00
|
|
|
if (!opts->quiet && !old_branch_info.path && old_branch_info.commit && new_branch_info->commit != old_branch_info.commit)
|
|
|
|
orphaned_commit_warning(old_branch_info.commit, new_branch_info->commit);
|
2009-05-16 17:54:45 +00:00
|
|
|
|
2018-02-14 18:59:31 +00:00
|
|
|
update_refs_for_switch(opts, &old_branch_info, new_branch_info);
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
|
2018-02-14 18:59:31 +00:00
|
|
|
ret = post_checkout_hook(old_branch_info.commit, new_branch_info->commit, 1);
|
2021-11-16 18:27:38 +00:00
|
|
|
branch_info_release(&old_branch_info);
|
|
|
|
|
2012-08-29 13:55:22 +00:00
|
|
|
return ret || writeout_error;
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
}
|
|
|
|
|
config: add ctx arg to config_fn_t
Add a new "const struct config_context *ctx" arg to config_fn_t to hold
additional information about the config iteration operation.
config_context has a "struct key_value_info kvi" member that holds
metadata about the config source being read (e.g. what kind of config
source it is, the filename, etc). In this series, we're only interested
in .kvi, so we could have just used "struct key_value_info" as an arg,
but config_context makes it possible to add/adjust members in the future
without changing the config_fn_t signature. We could also consider other
ways of organizing the args (e.g. moving the config name and value into
config_context or key_value_info), but in my experiments, the
incremental benefit doesn't justify the added complexity (e.g. a
config_fn_t will sometimes invoke another config_fn_t but with a
different config value).
In subsequent commits, the .kvi member will replace the global "struct
config_reader" in config.c, making config iteration a global-free
operation. It requires much more work for the machinery to provide
meaningful values of .kvi, so for now, merely change the signature and
call sites, pass NULL as a placeholder value, and don't rely on the arg
in any meaningful way.
Most of the changes are performed by
contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every
config_fn_t:
- Modifies the signature to accept "const struct config_context *ctx"
- Passes "ctx" to any inner config_fn_t, if needed
- Adds UNUSED attributes to "ctx", if needed
Most config_fn_t instances are easily identified by seeing if they are
called by the various config functions. Most of the remaining ones are
manually named in the .cocci patch. Manual cleanups are still needed,
but the majority of it is trivial; it's either adjusting config_fn_t
that the .cocci patch didn't catch, or adding forward declarations of
"struct config_context ctx" to make the signatures make sense.
The non-trivial changes are in cases where we are invoking a config_fn_t
outside of config machinery, and we now need to decide what value of
"ctx" to pass. These cases are:
- trace2/tr2_cfg.c:tr2_cfg_set_fl()
This is indirectly called by git_config_set() so that the trace2
machinery can notice the new config values and update its settings
using the tr2 config parsing function, i.e. tr2_cfg_cb().
- builtin/checkout.c:checkout_main()
This calls git_xmerge_config() as a shorthand for parsing a CLI arg.
This might be worth refactoring away in the future, since
git_xmerge_config() can call git_default_config(), which can do much
more than just parsing.
Handle them by creating a KVI_INIT macro that initializes "struct
key_value_info" to a reasonable default, and use that to construct the
"ctx" arg.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:22 +00:00
|
|
|
static int git_checkout_config(const char *var, const char *value,
|
|
|
|
const struct config_context *ctx, void *cb)
|
2008-08-30 14:52:24 +00:00
|
|
|
{
|
2020-10-08 05:48:15 +00:00
|
|
|
struct checkout_opts *opts = cb;
|
|
|
|
|
2010-08-25 10:34:57 +00:00
|
|
|
if (!strcmp(var, "diff.ignoresubmodules")) {
|
2023-12-07 07:11:14 +00:00
|
|
|
if (!value)
|
|
|
|
return config_error_nonbool(var);
|
2010-08-25 10:34:57 +00:00
|
|
|
handle_ignore_submodules_arg(&opts->diff_options, value);
|
|
|
|
return 0;
|
|
|
|
}
|
2020-10-08 05:48:15 +00:00
|
|
|
if (!strcmp(var, "checkout.guess")) {
|
|
|
|
opts->dwim_new_local_branch = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
2010-08-28 14:50:07 +00:00
|
|
|
|
2013-11-30 20:55:40 +00:00
|
|
|
if (starts_with(var, "submodule."))
|
2017-08-03 18:19:53 +00:00
|
|
|
return git_default_submodule_config(var, value, NULL);
|
2010-08-28 14:50:07 +00:00
|
|
|
|
config: add ctx arg to config_fn_t
Add a new "const struct config_context *ctx" arg to config_fn_t to hold
additional information about the config iteration operation.
config_context has a "struct key_value_info kvi" member that holds
metadata about the config source being read (e.g. what kind of config
source it is, the filename, etc). In this series, we're only interested
in .kvi, so we could have just used "struct key_value_info" as an arg,
but config_context makes it possible to add/adjust members in the future
without changing the config_fn_t signature. We could also consider other
ways of organizing the args (e.g. moving the config name and value into
config_context or key_value_info), but in my experiments, the
incremental benefit doesn't justify the added complexity (e.g. a
config_fn_t will sometimes invoke another config_fn_t but with a
different config value).
In subsequent commits, the .kvi member will replace the global "struct
config_reader" in config.c, making config iteration a global-free
operation. It requires much more work for the machinery to provide
meaningful values of .kvi, so for now, merely change the signature and
call sites, pass NULL as a placeholder value, and don't rely on the arg
in any meaningful way.
Most of the changes are performed by
contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every
config_fn_t:
- Modifies the signature to accept "const struct config_context *ctx"
- Passes "ctx" to any inner config_fn_t, if needed
- Adds UNUSED attributes to "ctx", if needed
Most config_fn_t instances are easily identified by seeing if they are
called by the various config functions. Most of the remaining ones are
manually named in the .cocci patch. Manual cleanups are still needed,
but the majority of it is trivial; it's either adjusting config_fn_t
that the .cocci patch didn't catch, or adding forward declarations of
"struct config_context ctx" to make the signatures make sense.
The non-trivial changes are in cases where we are invoking a config_fn_t
outside of config machinery, and we now need to decide what value of
"ctx" to pass. These cases are:
- trace2/tr2_cfg.c:tr2_cfg_set_fl()
This is indirectly called by git_config_set() so that the trace2
machinery can notice the new config values and update its settings
using the tr2 config parsing function, i.e. tr2_cfg_cb().
- builtin/checkout.c:checkout_main()
This calls git_xmerge_config() as a shorthand for parsing a CLI arg.
This might be worth refactoring away in the future, since
git_xmerge_config() can call git_default_config(), which can do much
more than just parsing.
Handle them by creating a KVI_INIT macro that initializes "struct
key_value_info" to a reasonable default, and use that to construct the
"ctx" arg.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:22 +00:00
|
|
|
return git_xmerge_config(var, value, ctx, NULL);
|
2008-08-30 14:52:24 +00:00
|
|
|
}
|
|
|
|
|
2019-03-29 10:39:01 +00:00
|
|
|
static void setup_new_branch_info_and_source_tree(
|
|
|
|
struct branch_info *new_branch_info,
|
|
|
|
struct checkout_opts *opts,
|
|
|
|
struct object_id *rev,
|
|
|
|
const char *arg)
|
|
|
|
{
|
|
|
|
struct tree **source_tree = &opts->source_tree;
|
|
|
|
struct object_id branch_rev;
|
|
|
|
|
add-patch: classify '@' as a synonym for 'HEAD'
Currently, (restore, checkout, reset) commands correctly take '@' as a
synonym for 'HEAD'. However, in patch mode different prompts/messages
are given on command line due to patch mode machinery not considering
'@' to be a synonym for 'HEAD' due to literal string comparison with
the word 'HEAD', and therefore assigning patch_mode_($command)_nothead
and triggering reverse mode (-R in diff-index). The NEEDSWORK comment
suggested comparing commit objects to get around this. However, doing
so would also take a non-checked out branch pointing to the same commit
as HEAD, as HEAD. This would cause confusion to the user.
Therefore, after parsing '@', replace it with 'HEAD' as reasonably
early as possible. This also solves another problem of disparity
between 'git checkout HEAD' and 'git checkout @' (latter detaches at
the HEAD commit and the former does not).
Trade-offs:
- Some of the errors would show the revision argument as 'HEAD' when
given '@'. This should be fine, as most users who probably use '@'
would be aware that it is a shortcut for 'HEAD' and most probably
used to use 'HEAD'. There is also relevant documentation in
'gitrevisions' manpage about '@' being the shortcut for 'HEAD'. Also,
the simplicity of the solution far outweighs this cost.
- Consider '@' as a shortcut for 'HEAD' even if 'refs/heads/@' exists
at a different commit. Naming a branch '@' is an obvious foot-gun and
many existing commands already take '@' for 'HEAD' even if
'refs/heads/@' exists at a different commit or does not exist at all
(e.g. 'git log @', 'git push origin @' etc.). Therefore this is an
existing assumption and should not be a problem.
Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Phillip Wood <phillip.wood123@gmail.com>
Signed-off-by: Ghanshyam Thakkar <shyamthakkar001@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-02-13 00:05:29 +00:00
|
|
|
/* treat '@' as a shortcut for 'HEAD' */
|
|
|
|
new_branch_info->name = !strcmp(arg, "@") ? xstrdup("HEAD") :
|
|
|
|
xstrdup(arg);
|
2019-03-29 10:39:01 +00:00
|
|
|
setup_branch_path(new_branch_info);
|
|
|
|
|
|
|
|
if (!check_refname_format(new_branch_info->path, 0) &&
|
|
|
|
!read_ref(new_branch_info->path, &branch_rev))
|
|
|
|
oidcpy(rev, &branch_rev);
|
2021-11-16 18:27:38 +00:00
|
|
|
else
|
|
|
|
/* not an existing branch */
|
|
|
|
FREE_AND_NULL(new_branch_info->path);
|
2019-03-29 10:39:01 +00:00
|
|
|
|
|
|
|
new_branch_info->commit = lookup_commit_reference_gently(the_repository, rev, 1);
|
|
|
|
if (!new_branch_info->commit) {
|
|
|
|
/* not a commit */
|
|
|
|
*source_tree = parse_tree_indirect(rev);
|
2024-02-23 08:34:23 +00:00
|
|
|
if (!*source_tree)
|
|
|
|
die(_("unable to read tree (%s)"), oid_to_hex(rev));
|
2019-03-29 10:39:01 +00:00
|
|
|
} else {
|
|
|
|
parse_commit_or_die(new_branch_info->commit);
|
2023-03-28 13:58:48 +00:00
|
|
|
*source_tree = repo_get_commit_tree(the_repository,
|
|
|
|
new_branch_info->commit);
|
2024-02-23 08:34:23 +00:00
|
|
|
if (!*source_tree)
|
|
|
|
die(_("unable to read tree (%s)"),
|
|
|
|
oid_to_hex(&new_branch_info->commit->object.oid));
|
2019-03-29 10:39:01 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-12-30 18:38:12 +00:00
|
|
|
static const char *parse_remote_branch(const char *arg,
|
|
|
|
struct object_id *rev,
|
checkout: don't revert file on ambiguous tracking branches
For easier understanding, here are the existing good scenarios:
1) Have *no* file 'foo', *no* local branch 'foo' and a *single*
remote branch 'foo'
2) `git checkout foo` will create local branch foo, see [1]
and
1) Have *a* file 'foo', *no* local branch 'foo' and a *single*
remote branch 'foo'
2) `git checkout foo` will complain, see [3]
This patch prevents the following scenario:
1) Have *a* file 'foo', *no* local branch 'foo' and *multiple*
remote branches 'foo'
2) `git checkout foo` will successfully... revert contents of
file `foo`!
That is, adding another remote suddenly changes behavior significantly,
which is a surprise at best and could go unnoticed by user at worst.
Please see [3] which gives some real world complaints.
To my understanding, fix in [3] overlooked the case of multiple remotes,
and the whole behavior of falling back to reverting file was never
intended:
[1] introduces the unexpected behavior. Before, there was fallback
from not-a-ref to pathspec. This is reasonable fallback. After, there
is another fallback from ambiguous-remote to pathspec. I understand
that it was a copy&paste oversight.
[2] noticed the unexpected behavior but chose to semi-document it
instead of forbidding, because the goal of the patch series was
focused on something else.
[3] adds `die()` when there is ambiguity between branch and file. The
case of multiple tracking branches is seemingly overlooked.
The new behavior: if there is no local branch and multiple remote
candidates, just die() and don't try reverting file whether it
exists (prevents surprise) or not (improves error message).
[1] Commit 70c9ac2f ("DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"" 2009-10-18)
https://public-inbox.org/git/7vaazpxha4.fsf_-_@alter.siamese.dyndns.org/
[2] Commit ad8d5104 ("checkout: add advice for ambiguous "checkout <branch>"", 2018-06-05)
https://public-inbox.org/git/20180502105452.17583-1-avarab@gmail.com/
[3] Commit be4908f1 ("checkout: disambiguate dwim tracking branches and local files", 2018-11-13)
https://public-inbox.org/git/20181110120707.25846-1-pclouds@gmail.com/
Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-30 18:38:13 +00:00
|
|
|
int could_be_checkout_paths)
|
2019-12-30 18:38:12 +00:00
|
|
|
{
|
checkout: don't revert file on ambiguous tracking branches
For easier understanding, here are the existing good scenarios:
1) Have *no* file 'foo', *no* local branch 'foo' and a *single*
remote branch 'foo'
2) `git checkout foo` will create local branch foo, see [1]
and
1) Have *a* file 'foo', *no* local branch 'foo' and a *single*
remote branch 'foo'
2) `git checkout foo` will complain, see [3]
This patch prevents the following scenario:
1) Have *a* file 'foo', *no* local branch 'foo' and *multiple*
remote branches 'foo'
2) `git checkout foo` will successfully... revert contents of
file `foo`!
That is, adding another remote suddenly changes behavior significantly,
which is a surprise at best and could go unnoticed by user at worst.
Please see [3] which gives some real world complaints.
To my understanding, fix in [3] overlooked the case of multiple remotes,
and the whole behavior of falling back to reverting file was never
intended:
[1] introduces the unexpected behavior. Before, there was fallback
from not-a-ref to pathspec. This is reasonable fallback. After, there
is another fallback from ambiguous-remote to pathspec. I understand
that it was a copy&paste oversight.
[2] noticed the unexpected behavior but chose to semi-document it
instead of forbidding, because the goal of the patch series was
focused on something else.
[3] adds `die()` when there is ambiguity between branch and file. The
case of multiple tracking branches is seemingly overlooked.
The new behavior: if there is no local branch and multiple remote
candidates, just die() and don't try reverting file whether it
exists (prevents surprise) or not (improves error message).
[1] Commit 70c9ac2f ("DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"" 2009-10-18)
https://public-inbox.org/git/7vaazpxha4.fsf_-_@alter.siamese.dyndns.org/
[2] Commit ad8d5104 ("checkout: add advice for ambiguous "checkout <branch>"", 2018-06-05)
https://public-inbox.org/git/20180502105452.17583-1-avarab@gmail.com/
[3] Commit be4908f1 ("checkout: disambiguate dwim tracking branches and local files", 2018-11-13)
https://public-inbox.org/git/20181110120707.25846-1-pclouds@gmail.com/
Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-30 18:38:13 +00:00
|
|
|
int num_matches = 0;
|
|
|
|
const char *remote = unique_tracking_name(arg, rev, &num_matches);
|
2019-12-30 18:38:12 +00:00
|
|
|
|
|
|
|
if (remote && could_be_checkout_paths) {
|
|
|
|
die(_("'%s' could be both a local file and a tracking branch.\n"
|
|
|
|
"Please use -- (and optionally --no-guess) to disambiguate"),
|
|
|
|
arg);
|
|
|
|
}
|
|
|
|
|
checkout: don't revert file on ambiguous tracking branches
For easier understanding, here are the existing good scenarios:
1) Have *no* file 'foo', *no* local branch 'foo' and a *single*
remote branch 'foo'
2) `git checkout foo` will create local branch foo, see [1]
and
1) Have *a* file 'foo', *no* local branch 'foo' and a *single*
remote branch 'foo'
2) `git checkout foo` will complain, see [3]
This patch prevents the following scenario:
1) Have *a* file 'foo', *no* local branch 'foo' and *multiple*
remote branches 'foo'
2) `git checkout foo` will successfully... revert contents of
file `foo`!
That is, adding another remote suddenly changes behavior significantly,
which is a surprise at best and could go unnoticed by user at worst.
Please see [3] which gives some real world complaints.
To my understanding, fix in [3] overlooked the case of multiple remotes,
and the whole behavior of falling back to reverting file was never
intended:
[1] introduces the unexpected behavior. Before, there was fallback
from not-a-ref to pathspec. This is reasonable fallback. After, there
is another fallback from ambiguous-remote to pathspec. I understand
that it was a copy&paste oversight.
[2] noticed the unexpected behavior but chose to semi-document it
instead of forbidding, because the goal of the patch series was
focused on something else.
[3] adds `die()` when there is ambiguity between branch and file. The
case of multiple tracking branches is seemingly overlooked.
The new behavior: if there is no local branch and multiple remote
candidates, just die() and don't try reverting file whether it
exists (prevents surprise) or not (improves error message).
[1] Commit 70c9ac2f ("DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"" 2009-10-18)
https://public-inbox.org/git/7vaazpxha4.fsf_-_@alter.siamese.dyndns.org/
[2] Commit ad8d5104 ("checkout: add advice for ambiguous "checkout <branch>"", 2018-06-05)
https://public-inbox.org/git/20180502105452.17583-1-avarab@gmail.com/
[3] Commit be4908f1 ("checkout: disambiguate dwim tracking branches and local files", 2018-11-13)
https://public-inbox.org/git/20181110120707.25846-1-pclouds@gmail.com/
Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-30 18:38:13 +00:00
|
|
|
if (!remote && num_matches > 1) {
|
2021-08-23 10:44:00 +00:00
|
|
|
if (advice_enabled(ADVICE_CHECKOUT_AMBIGUOUS_REMOTE_BRANCH_NAME)) {
|
checkout: don't revert file on ambiguous tracking branches
For easier understanding, here are the existing good scenarios:
1) Have *no* file 'foo', *no* local branch 'foo' and a *single*
remote branch 'foo'
2) `git checkout foo` will create local branch foo, see [1]
and
1) Have *a* file 'foo', *no* local branch 'foo' and a *single*
remote branch 'foo'
2) `git checkout foo` will complain, see [3]
This patch prevents the following scenario:
1) Have *a* file 'foo', *no* local branch 'foo' and *multiple*
remote branches 'foo'
2) `git checkout foo` will successfully... revert contents of
file `foo`!
That is, adding another remote suddenly changes behavior significantly,
which is a surprise at best and could go unnoticed by user at worst.
Please see [3] which gives some real world complaints.
To my understanding, fix in [3] overlooked the case of multiple remotes,
and the whole behavior of falling back to reverting file was never
intended:
[1] introduces the unexpected behavior. Before, there was fallback
from not-a-ref to pathspec. This is reasonable fallback. After, there
is another fallback from ambiguous-remote to pathspec. I understand
that it was a copy&paste oversight.
[2] noticed the unexpected behavior but chose to semi-document it
instead of forbidding, because the goal of the patch series was
focused on something else.
[3] adds `die()` when there is ambiguity between branch and file. The
case of multiple tracking branches is seemingly overlooked.
The new behavior: if there is no local branch and multiple remote
candidates, just die() and don't try reverting file whether it
exists (prevents surprise) or not (improves error message).
[1] Commit 70c9ac2f ("DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"" 2009-10-18)
https://public-inbox.org/git/7vaazpxha4.fsf_-_@alter.siamese.dyndns.org/
[2] Commit ad8d5104 ("checkout: add advice for ambiguous "checkout <branch>"", 2018-06-05)
https://public-inbox.org/git/20180502105452.17583-1-avarab@gmail.com/
[3] Commit be4908f1 ("checkout: disambiguate dwim tracking branches and local files", 2018-11-13)
https://public-inbox.org/git/20181110120707.25846-1-pclouds@gmail.com/
Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-30 18:38:13 +00:00
|
|
|
advise(_("If you meant to check out a remote tracking branch on, e.g. 'origin',\n"
|
|
|
|
"you can do so by fully qualifying the name with the --track option:\n"
|
|
|
|
"\n"
|
|
|
|
" git checkout --track origin/<name>\n"
|
|
|
|
"\n"
|
|
|
|
"If you'd like to always have checkouts of an ambiguous <name> prefer\n"
|
|
|
|
"one remote, e.g. the 'origin' remote, consider setting\n"
|
|
|
|
"checkout.defaultRemote=origin in your config."));
|
|
|
|
}
|
|
|
|
|
|
|
|
die(_("'%s' matched multiple (%d) remote tracking branches"),
|
|
|
|
arg, num_matches);
|
|
|
|
}
|
|
|
|
|
2019-12-30 18:38:12 +00:00
|
|
|
return remote;
|
|
|
|
}
|
|
|
|
|
2011-02-08 10:29:09 +00:00
|
|
|
static int parse_branchname_arg(int argc, const char **argv,
|
|
|
|
int dwim_new_local_branch_ok,
|
2018-02-14 18:59:31 +00:00
|
|
|
struct branch_info *new_branch_info,
|
2015-01-03 09:41:25 +00:00
|
|
|
struct checkout_opts *opts,
|
checkout: don't revert file on ambiguous tracking branches
For easier understanding, here are the existing good scenarios:
1) Have *no* file 'foo', *no* local branch 'foo' and a *single*
remote branch 'foo'
2) `git checkout foo` will create local branch foo, see [1]
and
1) Have *a* file 'foo', *no* local branch 'foo' and a *single*
remote branch 'foo'
2) `git checkout foo` will complain, see [3]
This patch prevents the following scenario:
1) Have *a* file 'foo', *no* local branch 'foo' and *multiple*
remote branches 'foo'
2) `git checkout foo` will successfully... revert contents of
file `foo`!
That is, adding another remote suddenly changes behavior significantly,
which is a surprise at best and could go unnoticed by user at worst.
Please see [3] which gives some real world complaints.
To my understanding, fix in [3] overlooked the case of multiple remotes,
and the whole behavior of falling back to reverting file was never
intended:
[1] introduces the unexpected behavior. Before, there was fallback
from not-a-ref to pathspec. This is reasonable fallback. After, there
is another fallback from ambiguous-remote to pathspec. I understand
that it was a copy&paste oversight.
[2] noticed the unexpected behavior but chose to semi-document it
instead of forbidding, because the goal of the patch series was
focused on something else.
[3] adds `die()` when there is ambiguity between branch and file. The
case of multiple tracking branches is seemingly overlooked.
The new behavior: if there is no local branch and multiple remote
candidates, just die() and don't try reverting file whether it
exists (prevents surprise) or not (improves error message).
[1] Commit 70c9ac2f ("DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"" 2009-10-18)
https://public-inbox.org/git/7vaazpxha4.fsf_-_@alter.siamese.dyndns.org/
[2] Commit ad8d5104 ("checkout: add advice for ambiguous "checkout <branch>"", 2018-06-05)
https://public-inbox.org/git/20180502105452.17583-1-avarab@gmail.com/
[3] Commit be4908f1 ("checkout: disambiguate dwim tracking branches and local files", 2018-11-13)
https://public-inbox.org/git/20181110120707.25846-1-pclouds@gmail.com/
Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-30 18:38:13 +00:00
|
|
|
struct object_id *rev)
|
2011-02-08 10:29:09 +00:00
|
|
|
{
|
2015-01-03 09:41:25 +00:00
|
|
|
const char **new_branch = &opts->new_branch;
|
2011-02-08 10:29:09 +00:00
|
|
|
int argcount = 0;
|
|
|
|
const char *arg;
|
2013-10-18 09:25:58 +00:00
|
|
|
int dash_dash_pos;
|
|
|
|
int has_dash_dash = 0;
|
|
|
|
int i;
|
2011-02-08 10:29:09 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* case 1: git checkout <ref> -- [<paths>]
|
|
|
|
*
|
|
|
|
* <ref> must be a valid tree, everything after the '--' must be
|
|
|
|
* a path.
|
|
|
|
*
|
|
|
|
* case 2: git checkout -- [<paths>]
|
|
|
|
*
|
|
|
|
* everything after the '--' must be paths.
|
|
|
|
*
|
2013-10-18 09:25:57 +00:00
|
|
|
* case 3: git checkout <something> [--]
|
2011-02-08 10:29:09 +00:00
|
|
|
*
|
2013-10-18 09:25:57 +00:00
|
|
|
* (a) If <something> is a commit, that is to
|
|
|
|
* switch to the branch or detach HEAD at it. As a special case,
|
|
|
|
* if <something> is A...B (missing A or B means HEAD but you can
|
|
|
|
* omit at most one side), and if there is a unique merge base
|
|
|
|
* between A and B, A...B names that merge base.
|
2011-02-08 10:29:09 +00:00
|
|
|
*
|
2013-10-18 09:25:57 +00:00
|
|
|
* (b) If <something> is _not_ a commit, either "--" is present
|
2023-01-07 13:56:55 +00:00
|
|
|
* or <something> is not a path, no -t or -b was given,
|
2013-10-18 09:25:57 +00:00
|
|
|
* and there is a tracking branch whose name is <something>
|
checkout & worktree: introduce checkout.defaultRemote
Introduce a checkout.defaultRemote setting which can be used to
designate a remote to prefer (via checkout.defaultRemote=origin) when
running e.g. "git checkout master" to mean origin/master, even though
there's other remotes that have the "master" branch.
I want this because it's very handy to use this workflow to checkout a
repository and create a topic branch, then get back to a "master" as
retrieved from upstream:
(
cd /tmp &&
rm -rf tbdiff &&
git clone git@github.com:trast/tbdiff.git &&
cd tbdiff &&
git branch -m topic &&
git checkout master
)
That will output:
Branch 'master' set up to track remote branch 'master' from 'origin'.
Switched to a new branch 'master'
But as soon as a new remote is added (e.g. just to inspect something
from someone else) the DWIMery goes away:
(
cd /tmp &&
rm -rf tbdiff &&
git clone git@github.com:trast/tbdiff.git &&
cd tbdiff &&
git branch -m topic &&
git remote add avar git@github.com:avar/tbdiff.git &&
git fetch avar &&
git checkout master
)
Will output (without the advice output added earlier in this series):
error: pathspec 'master' did not match any file(s) known to git.
The new checkout.defaultRemote config allows me to say that whenever
that ambiguity comes up I'd like to prefer "origin", and it'll still
work as though the only remote I had was "origin".
Also adjust the advice.checkoutAmbiguousRemoteBranchName message to
mention this new config setting to the user, the full output on my
git.git is now (the last paragraph is new):
$ ./git --exec-path=$PWD checkout master
error: pathspec 'master' did not match any file(s) known to git.
hint: 'master' matched more than one remote tracking branch.
hint: We found 26 remotes with a reference that matched. So we fell back
hint: on trying to resolve the argument as a path, but failed there too!
hint:
hint: If you meant to check out a remote tracking branch on, e.g. 'origin',
hint: you can do so by fully qualifying the name with the --track option:
hint:
hint: git checkout --track origin/<name>
hint:
hint: If you'd like to always have checkouts of an ambiguous <name> prefer
hint: one remote, e.g. the 'origin' remote, consider setting
hint: checkout.defaultRemote=origin in your config.
I considered splitting this into checkout.defaultRemote and
worktree.defaultRemote, but it's probably less confusing to break our
own rules that anything shared between config should live in core.*
than have two config settings, and I couldn't come up with a short
name under core.* that made sense (core.defaultRemoteForCheckout?).
See also 70c9ac2f19 ("DWIM "git checkout frotz" to "git checkout -b
frotz origin/frotz"", 2009-10-18) which introduced this DWIM feature
to begin with, and 4e85333197 ("worktree: make add <path> <branch>
dwim", 2017-11-26) which added it to git-worktree.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:49 +00:00
|
|
|
* in one and only one remote (or if the branch exists on the
|
|
|
|
* remote named in checkout.defaultRemote), then this is a
|
|
|
|
* short-hand to fork local <something> from that
|
|
|
|
* remote-tracking branch.
|
2011-02-08 10:29:09 +00:00
|
|
|
*
|
2013-10-18 09:25:57 +00:00
|
|
|
* (c) Otherwise, if "--" is present, treat it like case (1).
|
|
|
|
*
|
|
|
|
* (d) Otherwise :
|
|
|
|
* - if it's a reference, treat it like case (1)
|
|
|
|
* - else if it's a path, treat it like case (2)
|
|
|
|
* - else: fail.
|
|
|
|
*
|
|
|
|
* case 4: git checkout <something> <paths>
|
|
|
|
*
|
|
|
|
* The first argument must not be ambiguous.
|
2011-02-08 10:29:09 +00:00
|
|
|
* - If it's *only* a reference, treat it like case (1).
|
|
|
|
* - If it's only a path, treat it like case (2).
|
|
|
|
* - else: fail.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
if (!argc)
|
|
|
|
return 0;
|
|
|
|
|
2019-03-29 10:39:09 +00:00
|
|
|
if (!opts->accept_pathspec) {
|
|
|
|
if (argc > 1)
|
|
|
|
die(_("only one reference expected"));
|
|
|
|
has_dash_dash = 1; /* helps disambiguate */
|
|
|
|
}
|
|
|
|
|
2011-02-08 10:29:09 +00:00
|
|
|
arg = argv[0];
|
2013-10-18 09:25:58 +00:00
|
|
|
dash_dash_pos = -1;
|
|
|
|
for (i = 0; i < argc; i++) {
|
2019-03-29 10:39:09 +00:00
|
|
|
if (opts->accept_pathspec && !strcmp(argv[i], "--")) {
|
2013-10-18 09:25:58 +00:00
|
|
|
dash_dash_pos = i;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (dash_dash_pos == 0)
|
|
|
|
return 1; /* case (2) */
|
|
|
|
else if (dash_dash_pos == 1)
|
|
|
|
has_dash_dash = 1; /* case (3) or (1) */
|
|
|
|
else if (dash_dash_pos >= 2)
|
|
|
|
die(_("only one reference expected, %d given."), dash_dash_pos);
|
2018-11-13 18:28:00 +00:00
|
|
|
opts->count_checkout_paths = !opts->quiet && !has_dash_dash;
|
2011-02-08 10:29:09 +00:00
|
|
|
|
|
|
|
if (!strcmp(arg, "-"))
|
|
|
|
arg = "@{-1}";
|
|
|
|
|
2023-03-28 13:58:46 +00:00
|
|
|
if (repo_get_oid_mb(the_repository, arg, rev)) {
|
2013-10-18 09:25:57 +00:00
|
|
|
/*
|
|
|
|
* Either case (3) or (4), with <something> not being
|
|
|
|
* a commit, or an attempt to use case (1) with an
|
|
|
|
* invalid ref.
|
|
|
|
*
|
|
|
|
* It's likely an error, but we need to find out if
|
|
|
|
* we should auto-create the branch, case (3).(b).
|
|
|
|
*/
|
|
|
|
int recover_with_dwim = dwim_new_local_branch_ok;
|
|
|
|
|
2018-11-13 17:52:26 +00:00
|
|
|
int could_be_checkout_paths = !has_dash_dash &&
|
|
|
|
check_filename(opts->prefix, arg);
|
|
|
|
|
|
|
|
if (!has_dash_dash && !no_wildcard(arg))
|
2013-10-18 09:25:57 +00:00
|
|
|
recover_with_dwim = 0;
|
2018-11-13 17:52:26 +00:00
|
|
|
|
2013-10-18 09:25:57 +00:00
|
|
|
/*
|
2019-03-29 10:39:09 +00:00
|
|
|
* Accept "git checkout foo", "git checkout foo --"
|
|
|
|
* and "git switch foo" as candidates for dwim.
|
2013-10-18 09:25:57 +00:00
|
|
|
*/
|
|
|
|
if (!(argc == 1 && !has_dash_dash) &&
|
2019-03-29 10:39:09 +00:00
|
|
|
!(argc == 2 && has_dash_dash) &&
|
|
|
|
opts->accept_pathspec)
|
2013-10-18 09:25:57 +00:00
|
|
|
recover_with_dwim = 0;
|
|
|
|
|
|
|
|
if (recover_with_dwim) {
|
2019-12-30 18:38:12 +00:00
|
|
|
const char *remote = parse_remote_branch(arg, rev,
|
checkout: don't revert file on ambiguous tracking branches
For easier understanding, here are the existing good scenarios:
1) Have *no* file 'foo', *no* local branch 'foo' and a *single*
remote branch 'foo'
2) `git checkout foo` will create local branch foo, see [1]
and
1) Have *a* file 'foo', *no* local branch 'foo' and a *single*
remote branch 'foo'
2) `git checkout foo` will complain, see [3]
This patch prevents the following scenario:
1) Have *a* file 'foo', *no* local branch 'foo' and *multiple*
remote branches 'foo'
2) `git checkout foo` will successfully... revert contents of
file `foo`!
That is, adding another remote suddenly changes behavior significantly,
which is a surprise at best and could go unnoticed by user at worst.
Please see [3] which gives some real world complaints.
To my understanding, fix in [3] overlooked the case of multiple remotes,
and the whole behavior of falling back to reverting file was never
intended:
[1] introduces the unexpected behavior. Before, there was fallback
from not-a-ref to pathspec. This is reasonable fallback. After, there
is another fallback from ambiguous-remote to pathspec. I understand
that it was a copy&paste oversight.
[2] noticed the unexpected behavior but chose to semi-document it
instead of forbidding, because the goal of the patch series was
focused on something else.
[3] adds `die()` when there is ambiguity between branch and file. The
case of multiple tracking branches is seemingly overlooked.
The new behavior: if there is no local branch and multiple remote
candidates, just die() and don't try reverting file whether it
exists (prevents surprise) or not (improves error message).
[1] Commit 70c9ac2f ("DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"" 2009-10-18)
https://public-inbox.org/git/7vaazpxha4.fsf_-_@alter.siamese.dyndns.org/
[2] Commit ad8d5104 ("checkout: add advice for ambiguous "checkout <branch>"", 2018-06-05)
https://public-inbox.org/git/20180502105452.17583-1-avarab@gmail.com/
[3] Commit be4908f1 ("checkout: disambiguate dwim tracking branches and local files", 2018-11-13)
https://public-inbox.org/git/20181110120707.25846-1-pclouds@gmail.com/
Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-30 18:38:13 +00:00
|
|
|
could_be_checkout_paths);
|
2013-10-18 09:25:57 +00:00
|
|
|
if (remote) {
|
|
|
|
*new_branch = arg;
|
|
|
|
arg = remote;
|
|
|
|
/* DWIMmed to create local branch, case (3).(b) */
|
|
|
|
} else {
|
|
|
|
recover_with_dwim = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!recover_with_dwim) {
|
|
|
|
if (has_dash_dash)
|
|
|
|
die(_("invalid reference: %s"), arg);
|
2011-02-08 10:29:09 +00:00
|
|
|
return argcount;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* we can't end up being in (2) anymore, eat the argument */
|
|
|
|
argcount++;
|
|
|
|
argv++;
|
|
|
|
argc--;
|
|
|
|
|
2019-03-29 10:39:01 +00:00
|
|
|
setup_new_branch_info_and_source_tree(new_branch_info, opts, rev, arg);
|
2011-02-08 10:29:09 +00:00
|
|
|
|
2019-03-29 10:39:01 +00:00
|
|
|
if (!opts->source_tree) /* case (1): want a tree */
|
2011-04-02 00:55:55 +00:00
|
|
|
die(_("reference is not a tree: %s"), arg);
|
2019-03-29 10:39:01 +00:00
|
|
|
|
2016-09-07 11:19:39 +00:00
|
|
|
if (!has_dash_dash) { /* case (3).(d) -> (1) */
|
2011-02-08 10:29:09 +00:00
|
|
|
/*
|
|
|
|
* Do not complain the most common case
|
|
|
|
* git checkout branch
|
|
|
|
* even if there happen to be a file called 'branch';
|
|
|
|
* it would be extremely annoying.
|
|
|
|
*/
|
|
|
|
if (argc)
|
2016-09-07 11:19:41 +00:00
|
|
|
verify_non_filename(opts->prefix, arg);
|
2019-03-29 10:39:09 +00:00
|
|
|
} else if (opts->accept_pathspec) {
|
2011-02-08 10:29:09 +00:00
|
|
|
argcount++;
|
|
|
|
argv++;
|
|
|
|
argc--;
|
|
|
|
}
|
|
|
|
|
|
|
|
return argcount;
|
|
|
|
}
|
|
|
|
|
2012-08-29 13:55:22 +00:00
|
|
|
static int switch_unborn_to_new_branch(const struct checkout_opts *opts)
|
2012-01-30 20:10:08 +00:00
|
|
|
{
|
|
|
|
int status;
|
|
|
|
struct strbuf branch_ref = STRBUF_INIT;
|
|
|
|
|
2019-02-22 22:25:08 +00:00
|
|
|
trace2_cmd_mode("unborn");
|
|
|
|
|
2012-06-26 15:06:42 +00:00
|
|
|
if (!opts->new_branch)
|
|
|
|
die(_("You are on a branch yet to be born"));
|
2012-01-30 20:10:08 +00:00
|
|
|
strbuf_addf(&branch_ref, "refs/heads/%s", opts->new_branch);
|
|
|
|
status = create_symref("HEAD", branch_ref.buf, "checkout -b");
|
|
|
|
strbuf_release(&branch_ref);
|
2012-11-15 17:12:33 +00:00
|
|
|
if (!opts->quiet)
|
|
|
|
fprintf(stderr, _("Switched to a new branch '%s'\n"),
|
|
|
|
opts->new_branch);
|
2012-01-30 20:10:08 +00:00
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2019-03-29 10:39:11 +00:00
|
|
|
static void die_expecting_a_branch(const struct branch_info *branch_info)
|
|
|
|
{
|
|
|
|
struct object_id oid;
|
|
|
|
char *to_free;
|
2022-02-26 06:12:13 +00:00
|
|
|
int code;
|
2019-03-29 10:39:11 +00:00
|
|
|
|
2023-03-28 13:58:54 +00:00
|
|
|
if (repo_dwim_ref(the_repository, branch_info->name,
|
|
|
|
strlen(branch_info->name), &oid, &to_free, 0) == 1) {
|
2019-03-29 10:39:11 +00:00
|
|
|
const char *ref = to_free;
|
|
|
|
|
|
|
|
if (skip_prefix(ref, "refs/tags/", &ref))
|
2022-02-26 06:12:13 +00:00
|
|
|
code = die_message(_("a branch is expected, got tag '%s'"), ref);
|
|
|
|
else if (skip_prefix(ref, "refs/remotes/", &ref))
|
|
|
|
code = die_message(_("a branch is expected, got remote branch '%s'"), ref);
|
|
|
|
else
|
|
|
|
code = die_message(_("a branch is expected, got '%s'"), ref);
|
2019-03-29 10:39:11 +00:00
|
|
|
}
|
2022-02-26 06:12:13 +00:00
|
|
|
else if (branch_info->commit)
|
|
|
|
code = die_message(_("a branch is expected, got commit '%s'"), branch_info->name);
|
|
|
|
else
|
|
|
|
/*
|
|
|
|
* This case should never happen because we already die() on
|
|
|
|
* non-commit, but just in case.
|
|
|
|
*/
|
|
|
|
code = die_message(_("a branch is expected, got '%s'"), branch_info->name);
|
|
|
|
|
|
|
|
if (advice_enabled(ADVICE_SUGGEST_DETACHING_HEAD))
|
|
|
|
advise(_("If you want to detach HEAD at the commit, try again with the --detach option."));
|
|
|
|
|
|
|
|
exit(code);
|
2019-03-29 10:39:11 +00:00
|
|
|
}
|
|
|
|
|
2019-03-29 10:39:15 +00:00
|
|
|
static void die_if_some_operation_in_progress(void)
|
|
|
|
{
|
|
|
|
struct wt_status_state state;
|
|
|
|
|
|
|
|
memset(&state, 0, sizeof(state));
|
|
|
|
wt_status_get_state(the_repository, &state, 0);
|
|
|
|
|
|
|
|
if (state.merge_in_progress)
|
|
|
|
die(_("cannot switch branch while merging\n"
|
|
|
|
"Consider \"git merge --quit\" "
|
|
|
|
"or \"git worktree add\"."));
|
|
|
|
if (state.am_in_progress)
|
|
|
|
die(_("cannot switch branch in the middle of an am session\n"
|
|
|
|
"Consider \"git am --quit\" "
|
|
|
|
"or \"git worktree add\"."));
|
|
|
|
if (state.rebase_interactive_in_progress || state.rebase_in_progress)
|
|
|
|
die(_("cannot switch branch while rebasing\n"
|
|
|
|
"Consider \"git rebase --quit\" "
|
|
|
|
"or \"git worktree add\"."));
|
|
|
|
if (state.cherry_pick_in_progress)
|
|
|
|
die(_("cannot switch branch while cherry-picking\n"
|
|
|
|
"Consider \"git cherry-pick --quit\" "
|
|
|
|
"or \"git worktree add\"."));
|
|
|
|
if (state.revert_in_progress)
|
|
|
|
die(_("cannot switch branch while reverting\n"
|
|
|
|
"Consider \"git revert --quit\" "
|
|
|
|
"or \"git worktree add\"."));
|
|
|
|
if (state.bisect_in_progress)
|
switch: allow to switch in the middle of bisect
In c45f0f525d (switch: reject if some operation is in progress,
2019-03-29), a check is added to prevent switching when some operation
is in progress. The reason is it's often not safe to do so.
This is true for merge, am, rebase, cherry-pick and revert, but not so
much for bisect because bisecting is basically jumping/switching between
a bunch of commits to pin point the first bad one. git-bisect suggests
the next commit to test, but it's not wrong for the user to test a
different commit because git-bisect cannot have the knowledge to know
better.
For this reason, allow to switch when bisecting (*). I considered if we
should still prevent switching by default and allow it with
--ignore-in-progress. But I don't think the prevention really adds
anything much.
If the user switches away by mistake, since we print the previous HEAD
value, even if they don't know about the "-" shortcut, switching back is
still possible.
The warning will be printed on every switch while bisect is still
ongoing, not the first time you switch away from bisect's suggested
commit, so it could become a bit annoying.
(*) of course when it's safe to do so, i.e. no loss of local changes and
stuff.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20 09:55:21 +00:00
|
|
|
warning(_("you are switching branch while bisecting"));
|
built-ins & libs & helpers: add/move destructors, fix leaks
Fix various leaks in built-ins, libraries and a test helper here we
were missing a call to strbuf_release(), string_list_clear() etc, or
were calling them after a potential "return".
Comments on individual changes:
- builtin/checkout.c: Fix a memory leak that was introduced in [1]. A
sibling leak introduced in [2] was recently fixed in [3]. As with [3]
we should be using the wt_status_state_free_buffers() API introduced
in [4].
- builtin/repack.c: Fix a leak that's been here since this use of
"strbuf_release()" was added in a1bbc6c0176 (repack: rewrite the shell
script in C, 2013-09-15). We don't use the variable for anything
except this loop, so we can instead free it right afterwards.
- builtin/rev-parse: Fix a leak that's been here since this code was
added in 21d47835386 (Add a parseopt mode to git-rev-parse to bring
parse-options to shell scripts., 2007-11-04).
- builtin/stash.c: Fix a couple of leaks that have been here since
this code was added in d4788af875c (stash: convert create to builtin,
2019-02-25), we strbuf_release()'d only some of the "struct strbuf" we
allocated earlier in the function, let's release all of them.
- ref-filter.c: Fix a leak in 482c1191869 (gpg-interface: improve
interface for parsing tags, 2021-02-11), we don't use the "payload"
variable that we ask parse_signature() to populate for us, so let's
free it.
- t/helper/test-fake-ssh.c: Fix a leak that's been here since this
code was added in 3064d5a38c7 (mingw: fix t5601-clone.sh,
2016-01-27). Let's free the "struct strbuf" as soon as we don't need
it anymore.
1. c45f0f525de (switch: reject if some operation is in progress,
2019-03-29)
2. 2708ce62d21 (branch: sort detached HEAD based on a flag,
2021-01-07)
3. abcac2e19fa (ref-filter.c: fix a leak in get_head_description,
2022-09-25)
4. 962dd7ebc3e (wt-status: introduce wt_status_state_free_buffers(),
2020-09-27).
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-11-08 18:17:42 +00:00
|
|
|
|
|
|
|
wt_status_state_free_buffers(&state);
|
2019-03-29 10:39:15 +00:00
|
|
|
}
|
|
|
|
|
2023-11-23 05:11:41 +00:00
|
|
|
/*
|
|
|
|
* die if attempting to checkout an existing branch that is in use
|
|
|
|
* in another worktree, unless ignore-other-wortrees option is given.
|
|
|
|
* The check is bypassed when the branch is already the current one,
|
|
|
|
* as it will not make things any worse.
|
|
|
|
*/
|
|
|
|
static void die_if_switching_to_a_branch_in_use(struct checkout_opts *opts,
|
|
|
|
const char *full_ref)
|
|
|
|
{
|
|
|
|
int flags;
|
|
|
|
char *head_ref;
|
|
|
|
|
|
|
|
if (opts->ignore_other_worktrees)
|
|
|
|
return;
|
|
|
|
head_ref = resolve_refdup("HEAD", 0, NULL, &flags);
|
|
|
|
if (head_ref && (!(flags & REF_ISSYMREF) || strcmp(head_ref, full_ref)))
|
|
|
|
die_if_checked_out(full_ref, 1);
|
|
|
|
free(head_ref);
|
|
|
|
}
|
|
|
|
|
2012-08-30 12:45:50 +00:00
|
|
|
static int checkout_branch(struct checkout_opts *opts,
|
2018-02-14 18:59:31 +00:00
|
|
|
struct branch_info *new_branch_info)
|
2012-08-30 12:45:50 +00:00
|
|
|
{
|
2013-07-14 08:35:41 +00:00
|
|
|
if (opts->pathspec.nr)
|
2012-08-30 12:45:50 +00:00
|
|
|
die(_("paths cannot be used with switching branches"));
|
|
|
|
|
|
|
|
if (opts->patch_mode)
|
|
|
|
die(_("'%s' cannot be used with switching branches"),
|
|
|
|
"--patch");
|
|
|
|
|
2019-04-25 09:45:48 +00:00
|
|
|
if (opts->overlay_mode != -1)
|
checkout: introduce --{,no-}overlay option
Currently 'git checkout' is defined as an overlay operation, which
means that if in 'git checkout <tree-ish> -- [<pathspec>]' we have an
entry in the index that matches <pathspec>, but that doesn't exist in
<tree-ish>, that entry will not be removed from the index or the
working tree.
Introduce a new --{,no-}overlay option, which allows using 'git
checkout' in non-overlay mode, thus removing files from the working
tree if they do not exist in <tree-ish> but match <pathspec>.
Note that 'git checkout -p <tree-ish> -- [<pathspec>]' already works
this way, so no changes are needed for the patch mode. We disallow
'git checkout --overlay -p' to avoid confusing users who would expect
to be able to force overlay mode in 'git checkout -p' this way.
Untracked files are not affected by this change, so 'git checkout
--no-overlay HEAD -- untracked' will not remove untracked from the
working tree. This is so e.g. 'git checkout --no-overlay HEAD -- dir/'
doesn't delete all untracked files in dir/, but rather just resets the
state of files that are known to git.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-08 21:52:24 +00:00
|
|
|
die(_("'%s' cannot be used with switching branches"),
|
2019-04-25 09:45:48 +00:00
|
|
|
"--[no]-overlay");
|
checkout: introduce --{,no-}overlay option
Currently 'git checkout' is defined as an overlay operation, which
means that if in 'git checkout <tree-ish> -- [<pathspec>]' we have an
entry in the index that matches <pathspec>, but that doesn't exist in
<tree-ish>, that entry will not be removed from the index or the
working tree.
Introduce a new --{,no-}overlay option, which allows using 'git
checkout' in non-overlay mode, thus removing files from the working
tree if they do not exist in <tree-ish> but match <pathspec>.
Note that 'git checkout -p <tree-ish> -- [<pathspec>]' already works
this way, so no changes are needed for the patch mode. We disallow
'git checkout --overlay -p' to avoid confusing users who would expect
to be able to force overlay mode in 'git checkout -p' this way.
Untracked files are not affected by this change, so 'git checkout
--no-overlay HEAD -- untracked' will not remove untracked from the
working tree. This is so e.g. 'git checkout --no-overlay HEAD -- dir/'
doesn't delete all untracked files in dir/, but rather just resets the
state of files that are known to git.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-08 21:52:24 +00:00
|
|
|
|
2012-08-30 12:45:50 +00:00
|
|
|
if (opts->writeout_stage)
|
|
|
|
die(_("'%s' cannot be used with switching branches"),
|
|
|
|
"--ours/--theirs");
|
|
|
|
|
|
|
|
if (opts->force && opts->merge)
|
|
|
|
die(_("'%s' cannot be used with '%s'"), "-f", "-m");
|
|
|
|
|
2019-03-29 10:39:07 +00:00
|
|
|
if (opts->discard_changes && opts->merge)
|
|
|
|
die(_("'%s' cannot be used with '%s'"), "--discard-changes", "--merge");
|
|
|
|
|
2012-08-30 12:45:50 +00:00
|
|
|
if (opts->force_detach && opts->new_branch)
|
|
|
|
die(_("'%s' cannot be used with '%s'"),
|
|
|
|
"--detach", "-b/-B/--orphan");
|
|
|
|
|
|
|
|
if (opts->new_orphan_branch) {
|
|
|
|
if (opts->track != BRANCH_TRACK_UNSPECIFIED)
|
|
|
|
die(_("'%s' cannot be used with '%s'"), "--orphan", "-t");
|
2019-03-29 10:39:16 +00:00
|
|
|
if (opts->orphan_from_empty_tree && new_branch_info->name)
|
|
|
|
die(_("'%s' cannot take <start-point>"), "--orphan");
|
2012-08-30 12:45:50 +00:00
|
|
|
} else if (opts->force_detach) {
|
|
|
|
if (opts->track != BRANCH_TRACK_UNSPECIFIED)
|
|
|
|
die(_("'%s' cannot be used with '%s'"), "--detach", "-t");
|
|
|
|
} else if (opts->track == BRANCH_TRACK_UNSPECIFIED)
|
|
|
|
opts->track = git_branch_track;
|
|
|
|
|
2018-02-14 18:59:31 +00:00
|
|
|
if (new_branch_info->name && !new_branch_info->commit)
|
2012-08-30 12:45:50 +00:00
|
|
|
die(_("Cannot switch branch to a non-commit '%s'"),
|
2018-02-14 18:59:31 +00:00
|
|
|
new_branch_info->name);
|
2012-08-30 12:45:50 +00:00
|
|
|
|
2019-03-29 10:39:10 +00:00
|
|
|
if (!opts->switch_branch_doing_nothing_is_ok &&
|
|
|
|
!new_branch_info->name &&
|
|
|
|
!opts->new_branch &&
|
|
|
|
!opts->force_detach)
|
|
|
|
die(_("missing branch or commit argument"));
|
|
|
|
|
2019-03-29 10:39:11 +00:00
|
|
|
if (!opts->implicit_detach &&
|
|
|
|
!opts->force_detach &&
|
|
|
|
!opts->new_branch &&
|
|
|
|
!opts->new_branch_force &&
|
|
|
|
new_branch_info->name &&
|
|
|
|
!new_branch_info->path)
|
|
|
|
die_expecting_a_branch(new_branch_info);
|
|
|
|
|
2019-03-29 10:39:15 +00:00
|
|
|
if (!opts->can_switch_when_in_progress)
|
|
|
|
die_if_some_operation_in_progress();
|
|
|
|
|
2023-11-23 05:11:41 +00:00
|
|
|
/* "git checkout <branch>" */
|
|
|
|
if (new_branch_info->path && !opts->force_detach && !opts->new_branch)
|
|
|
|
die_if_switching_to_a_branch_in_use(opts, new_branch_info->path);
|
2015-06-12 10:49:24 +00:00
|
|
|
|
2023-11-23 06:00:31 +00:00
|
|
|
/* "git checkout -B <branch>" */
|
|
|
|
if (opts->new_branch_force) {
|
|
|
|
char *full_ref = xstrfmt("refs/heads/%s", opts->new_branch);
|
|
|
|
die_if_switching_to_a_branch_in_use(opts, full_ref);
|
|
|
|
free(full_ref);
|
2015-06-12 10:49:24 +00:00
|
|
|
}
|
|
|
|
|
2018-02-14 18:59:31 +00:00
|
|
|
if (!new_branch_info->commit && opts->new_branch) {
|
2016-09-05 20:08:00 +00:00
|
|
|
struct object_id rev;
|
2012-08-30 12:45:50 +00:00
|
|
|
int flag;
|
|
|
|
|
2017-10-15 22:06:56 +00:00
|
|
|
if (!read_ref_full("HEAD", 0, &rev, &flag) &&
|
2016-09-05 20:08:00 +00:00
|
|
|
(flag & REF_ISSYMREF) && is_null_oid(&rev))
|
2012-08-30 12:45:50 +00:00
|
|
|
return switch_unborn_to_new_branch(opts);
|
|
|
|
}
|
2018-02-14 18:59:31 +00:00
|
|
|
return switch_branches(opts, new_branch_info);
|
2012-08-30 12:45:50 +00:00
|
|
|
}
|
|
|
|
|
2024-03-14 17:05:06 +00:00
|
|
|
static int parse_opt_conflict(const struct option *o, const char *arg, int unset)
|
|
|
|
{
|
|
|
|
struct checkout_opts *opts = o->value;
|
|
|
|
|
|
|
|
if (unset) {
|
|
|
|
opts->conflict_style = -1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
opts->conflict_style = parse_conflict_style_name(arg);
|
|
|
|
if (opts->conflict_style < 0)
|
|
|
|
return error(_("unknown conflict style '%s'"), arg);
|
2024-03-14 17:05:07 +00:00
|
|
|
/* --conflict overrides a previous --no-merge */
|
|
|
|
if (!opts->merge)
|
|
|
|
opts->merge = -1;
|
2024-03-14 17:05:06 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-29 10:39:04 +00:00
|
|
|
static struct option *add_common_options(struct checkout_opts *opts,
|
|
|
|
struct option *prevopts)
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
{
|
|
|
|
struct option options[] = {
|
2019-03-29 10:39:02 +00:00
|
|
|
OPT__QUIET(&opts->quiet, N_("suppress progress reporting")),
|
Use OPT_CALLBACK and OPT_CALLBACK_F
In the codebase, there are many options which use OPTION_CALLBACK in a
plain ol' struct definition. However, we have the OPT_CALLBACK and
OPT_CALLBACK_F macros which are meant to abstract these plain struct
definitions away. These macros are useful as they semantically signal to
developers that these are just normal callback option with nothing fancy
happening.
Replace plain struct definitions of OPTION_CALLBACK with OPT_CALLBACK or
OPT_CALLBACK_F where applicable. The heavy lifting was done using the
following (disgusting) shell script:
#!/bin/sh
do_replacement () {
tr '\n' '\r' |
sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\s*0,\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK(\1,\2,\3,\4,\5,\6)/g' |
sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK_F(\1,\2,\3,\4,\5,\6,\7)/g' |
tr '\r' '\n'
}
for f in $(git ls-files \*.c)
do
do_replacement <"$f" >"$f.tmp"
mv "$f.tmp" "$f"
done
The result was manually inspected and then reformatted to match the
style of the surrounding code. Finally, using
`git grep OPTION_CALLBACK \*.c`, leftover results which were not handled
by the script were manually transformed.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-28 08:36:28 +00:00
|
|
|
OPT_CALLBACK_F(0, "recurse-submodules", NULL,
|
2019-03-29 10:39:04 +00:00
|
|
|
"checkout", "control recursive updating of submodules",
|
Use OPT_CALLBACK and OPT_CALLBACK_F
In the codebase, there are many options which use OPTION_CALLBACK in a
plain ol' struct definition. However, we have the OPT_CALLBACK and
OPT_CALLBACK_F macros which are meant to abstract these plain struct
definitions away. These macros are useful as they semantically signal to
developers that these are just normal callback option with nothing fancy
happening.
Replace plain struct definitions of OPTION_CALLBACK with OPT_CALLBACK or
OPT_CALLBACK_F where applicable. The heavy lifting was done using the
following (disgusting) shell script:
#!/bin/sh
do_replacement () {
tr '\n' '\r' |
sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\s*0,\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK(\1,\2,\3,\4,\5,\6)/g' |
sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK_F(\1,\2,\3,\4,\5,\6,\7)/g' |
tr '\r' '\n'
}
for f in $(git ls-files \*.c)
do
do_replacement <"$f" >"$f.tmp"
mv "$f.tmp" "$f"
done
The result was manually inspected and then reformatted to match the
style of the surrounding code. Finally, using
`git grep OPTION_CALLBACK \*.c`, leftover results which were not handled
by the script were manually transformed.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-28 08:36:28 +00:00
|
|
|
PARSE_OPT_OPTARG, option_parse_recurse_submodules_worktree_updater),
|
2019-03-29 10:39:04 +00:00
|
|
|
OPT_BOOL(0, "progress", &opts->show_progress, N_("force progress reporting")),
|
|
|
|
OPT_BOOL('m', "merge", &opts->merge, N_("perform a 3-way merge with the new branch")),
|
2024-03-14 17:05:06 +00:00
|
|
|
OPT_CALLBACK(0, "conflict", opts, N_("style"),
|
|
|
|
N_("conflict style (merge, diff3, or zdiff3)"),
|
|
|
|
parse_opt_conflict),
|
2019-03-29 10:39:04 +00:00
|
|
|
OPT_END()
|
|
|
|
};
|
|
|
|
struct option *newopts = parse_options_concat(prevopts, options);
|
|
|
|
free(prevopts);
|
|
|
|
return newopts;
|
|
|
|
}
|
|
|
|
|
2019-03-29 10:39:06 +00:00
|
|
|
static struct option *add_common_switch_branch_options(
|
|
|
|
struct checkout_opts *opts, struct option *prevopts)
|
2019-03-29 10:39:04 +00:00
|
|
|
{
|
|
|
|
struct option options[] = {
|
2019-03-29 10:39:12 +00:00
|
|
|
OPT_BOOL('d', "detach", &opts->force_detach, N_("detach HEAD at named commit")),
|
2022-01-20 12:35:54 +00:00
|
|
|
OPT_CALLBACK_F('t', "track", &opts->track, "(direct|inherit)",
|
2022-01-18 20:49:46 +00:00
|
|
|
N_("set branch tracking configuration"),
|
|
|
|
PARSE_OPT_OPTARG,
|
branch: add flags and config to inherit tracking
It can be helpful when creating a new branch to use the existing
tracking configuration from the branch point. However, there is
currently not a method to automatically do so.
Teach git-{branch,checkout,switch} an "inherit" argument to the
"--track" option. When this is set, creating a new branch will cause the
tracking configuration to default to the configuration of the branch
point, if set.
For example, if branch "main" tracks "origin/main", and we run
`git checkout --track=inherit -b feature main`, then branch "feature"
will track "origin/main". Thus, `git status` will show us how far
ahead/behind we are from origin, and `git pull` will pull from origin.
This is particularly useful when creating branches across many
submodules, such as with `git submodule foreach ...` (or if running with
a patch such as [1], which we use at $job), as it avoids having to
manually set tracking info for each submodule.
Since we've added an argument to "--track", also add "--track=direct" as
another way to explicitly get the original "--track" behavior ("--track"
without an argument still works as well).
Finally, teach branch.autoSetupMerge a new "inherit" option. When this
is set, "--track=inherit" becomes the default behavior.
[1]: https://lore.kernel.org/git/20180927221603.148025-1-sbeller@google.com/
Signed-off-by: Josh Steadmon <steadmon@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-21 03:30:23 +00:00
|
|
|
parse_opt_tracking_mode),
|
2019-04-25 09:45:53 +00:00
|
|
|
OPT__FORCE(&opts->force, N_("force checkout (throw away local modifications)"),
|
|
|
|
PARSE_OPT_NOCOMPLETE),
|
2023-11-24 03:10:42 +00:00
|
|
|
OPT_STRING(0, "orphan", &opts->new_orphan_branch, N_("new-branch"), N_("new unborn branch")),
|
2019-03-29 10:39:04 +00:00
|
|
|
OPT_BOOL_F(0, "overwrite-ignore", &opts->overwrite_ignore,
|
|
|
|
N_("update ignored files (default)"),
|
|
|
|
PARSE_OPT_NOCOMPLETE),
|
|
|
|
OPT_BOOL(0, "ignore-other-worktrees", &opts->ignore_other_worktrees,
|
|
|
|
N_("do not check if another worktree is holding the given ref")),
|
|
|
|
OPT_END()
|
|
|
|
};
|
|
|
|
struct option *newopts = parse_options_concat(prevopts, options);
|
|
|
|
free(prevopts);
|
|
|
|
return newopts;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct option *add_checkout_path_options(struct checkout_opts *opts,
|
|
|
|
struct option *prevopts)
|
|
|
|
{
|
|
|
|
struct option options[] = {
|
2019-03-29 10:39:02 +00:00
|
|
|
OPT_SET_INT_F('2', "ours", &opts->writeout_stage,
|
2018-05-27 08:38:27 +00:00
|
|
|
N_("checkout our version for unmerged files"),
|
|
|
|
2, PARSE_OPT_NONEG),
|
2019-03-29 10:39:02 +00:00
|
|
|
OPT_SET_INT_F('3', "theirs", &opts->writeout_stage,
|
2018-05-27 08:38:27 +00:00
|
|
|
N_("checkout their version for unmerged files"),
|
|
|
|
3, PARSE_OPT_NONEG),
|
2019-03-29 10:39:02 +00:00
|
|
|
OPT_BOOL('p', "patch", &opts->patch_mode, N_("select hunks interactively")),
|
|
|
|
OPT_BOOL(0, "ignore-skip-worktree-bits", &opts->ignore_skipworktree,
|
2013-04-12 23:12:08 +00:00
|
|
|
N_("do not limit pathspecs to sparse entries only")),
|
2019-12-03 14:02:18 +00:00
|
|
|
OPT_PATHSPEC_FROM_FILE(&opts->pathspec_from_file),
|
|
|
|
OPT_PATHSPEC_FILE_NUL(&opts->pathspec_file_nul),
|
2019-03-29 10:39:04 +00:00
|
|
|
OPT_END()
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
};
|
2019-03-29 10:39:04 +00:00
|
|
|
struct option *newopts = parse_options_concat(prevopts, options);
|
|
|
|
free(prevopts);
|
|
|
|
return newopts;
|
|
|
|
}
|
|
|
|
|
2020-04-30 11:54:57 +00:00
|
|
|
/* create-branch option (either b or c) */
|
|
|
|
static char cb_option = 'b';
|
|
|
|
|
2019-03-29 10:39:05 +00:00
|
|
|
static int checkout_main(int argc, const char **argv, const char *prefix,
|
|
|
|
struct checkout_opts *opts, struct option *options,
|
checkout: plug some leaks in git-restore
In git-restore we need to free the pathspec and pathspec_from_file
values from the struct checkout_opts.
A simple fix could be to free them in cmd_restore, after the call to
checkout_main returns, like we are doing [1][2] in the sibling function
cmd_checkout.
However, we can do even better.
We have git-switch and git-restore, both of them spin-offs[3][4] of
git-checkout. All three are implemented as thin wrappers around
checkout_main. Considering this, it makes a lot of sense to do the
cleanup closer to checkout_main.
Move the cleanups, including the new_branch_info variable, to
checkout_main.
As a consequence, mark: t2070, t2071, t2072 and t6418 as leak-free.
[1] 9081a421a6 (checkout: fix "branch info" memory leaks, 2021-11-16)
[2] 7ce4088ab7 (parse-options: consistently allocate memory in
fix_filename(), 2023-03-04)
[3] d787d311db (checkout: split part of it to new command 'switch',
2019-03-29)
[4] 46e91b663b (checkout: split part of it to new command 'restore',
2019-04-25)
Signed-off-by: Rubén Justo <rjusto@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-14 18:08:58 +00:00
|
|
|
const char * const usagestr[])
|
2019-03-29 10:39:04 +00:00
|
|
|
{
|
2019-04-25 09:45:46 +00:00
|
|
|
int parseopt_flags = 0;
|
checkout: plug some leaks in git-restore
In git-restore we need to free the pathspec and pathspec_from_file
values from the struct checkout_opts.
A simple fix could be to free them in cmd_restore, after the call to
checkout_main returns, like we are doing [1][2] in the sibling function
cmd_checkout.
However, we can do even better.
We have git-switch and git-restore, both of them spin-offs[3][4] of
git-checkout. All three are implemented as thin wrappers around
checkout_main. Considering this, it makes a lot of sense to do the
cleanup closer to checkout_main.
Move the cleanups, including the new_branch_info variable, to
checkout_main.
As a consequence, mark: t2070, t2071, t2072 and t6418 as leak-free.
[1] 9081a421a6 (checkout: fix "branch info" memory leaks, 2021-11-16)
[2] 7ce4088ab7 (parse-options: consistently allocate memory in
fix_filename(), 2023-03-04)
[3] d787d311db (checkout: split part of it to new command 'switch',
2019-03-29)
[4] 46e91b663b (checkout: split part of it to new command 'restore',
2019-04-25)
Signed-off-by: Rubén Justo <rjusto@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-14 18:08:58 +00:00
|
|
|
struct branch_info new_branch_info = { 0 };
|
|
|
|
int ret;
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
|
2019-03-29 10:39:02 +00:00
|
|
|
opts->overwrite_ignore = 1;
|
|
|
|
opts->prefix = prefix;
|
|
|
|
opts->show_progress = -1;
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
|
2019-03-29 10:39:02 +00:00
|
|
|
git_config(git_checkout_config, opts);
|
checkout/fetch/pull/pack-objects: allow `-h` outside a repository
When we taught these commands about the sparse index, we did not account
for the fact that the `cmd_*()` functions _can_ be called without a
gitdir, namely when `-h` is passed to show the usage.
A plausible approach to address this is to move the
`prepare_repo_settings()` calls right after the `parse_options()` calls:
The latter will never return when it handles `-h`, and therefore it is
safe to assume that we have a `gitdir` at that point, as long as the
built-in is marked with the `RUN_SETUP` flag.
However, it is unfortunately not that simple. In `cmd_pack_objects()`,
for example, the repo settings need to be fully populated so that the
command-line options `--sparse`/`--no-sparse` can override them, not the
other way round.
Therefore, we choose to imitate the strategy taken in `cmd_diff()`,
where we simply do not bother to prepare and initialize the repo
settings unless we have a `gitdir`.
This fixes https://github.com/git-for-windows/git/issues/3688
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-08 11:21:53 +00:00
|
|
|
if (the_repository->gitdir) {
|
|
|
|
prepare_repo_settings(the_repository);
|
|
|
|
the_repository->settings.command_requires_full_index = 0;
|
|
|
|
}
|
2021-06-29 02:13:06 +00:00
|
|
|
|
2019-03-29 10:39:02 +00:00
|
|
|
opts->track = BRANCH_TRACK_UNSPECIFIED;
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
|
2019-04-25 09:45:46 +00:00
|
|
|
if (!opts->accept_pathspec && !opts->accept_ref)
|
|
|
|
BUG("make up your mind, you need to take _something_");
|
|
|
|
if (opts->accept_pathspec && opts->accept_ref)
|
|
|
|
parseopt_flags = PARSE_OPT_KEEP_DASHDASH;
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
|
2019-04-25 09:45:46 +00:00
|
|
|
argc = parse_options(argc, argv, prefix, options,
|
|
|
|
usagestr, parseopt_flags);
|
2008-07-23 10:15:33 +00:00
|
|
|
|
2019-03-29 10:39:02 +00:00
|
|
|
if (opts->show_progress < 0) {
|
|
|
|
if (opts->quiet)
|
|
|
|
opts->show_progress = 0;
|
2015-11-01 21:19:05 +00:00
|
|
|
else
|
2019-03-29 10:39:02 +00:00
|
|
|
opts->show_progress = isatty(2);
|
2015-11-01 21:19:05 +00:00
|
|
|
}
|
|
|
|
|
2024-03-14 17:05:07 +00:00
|
|
|
/* --conflicts implies --merge */
|
|
|
|
if (opts->merge == -1)
|
|
|
|
opts->merge = opts->conflict_style >= 0;
|
2024-03-14 17:05:06 +00:00
|
|
|
|
2019-04-25 09:45:53 +00:00
|
|
|
if (opts->force) {
|
2019-03-29 10:39:07 +00:00
|
|
|
opts->discard_changes = 1;
|
2019-04-25 09:45:53 +00:00
|
|
|
opts->ignore_unmerged_opt = "--force";
|
|
|
|
opts->ignore_unmerged = 1;
|
2012-08-30 12:45:50 +00:00
|
|
|
}
|
2010-06-23 19:29:00 +00:00
|
|
|
|
2019-03-29 10:39:02 +00:00
|
|
|
if ((!!opts->new_branch + !!opts->new_branch_force + !!opts->new_orphan_branch) > 1)
|
2022-01-05 20:02:24 +00:00
|
|
|
die(_("options '-%c', '-%c', and '%s' cannot be used together"),
|
|
|
|
cb_option, toupper(cb_option), "--orphan");
|
2010-06-23 19:29:00 +00:00
|
|
|
|
2019-03-29 10:39:02 +00:00
|
|
|
if (opts->overlay_mode == 1 && opts->patch_mode)
|
2022-01-05 20:02:14 +00:00
|
|
|
die(_("options '%s' and '%s' cannot be used together"), "-p", "--overlay");
|
checkout: introduce --{,no-}overlay option
Currently 'git checkout' is defined as an overlay operation, which
means that if in 'git checkout <tree-ish> -- [<pathspec>]' we have an
entry in the index that matches <pathspec>, but that doesn't exist in
<tree-ish>, that entry will not be removed from the index or the
working tree.
Introduce a new --{,no-}overlay option, which allows using 'git
checkout' in non-overlay mode, thus removing files from the working
tree if they do not exist in <tree-ish> but match <pathspec>.
Note that 'git checkout -p <tree-ish> -- [<pathspec>]' already works
this way, so no changes are needed for the patch mode. We disallow
'git checkout --overlay -p' to avoid confusing users who would expect
to be able to force overlay mode in 'git checkout -p' this way.
Untracked files are not affected by this change, so 'git checkout
--no-overlay HEAD -- untracked' will not remove untracked from the
working tree. This is so e.g. 'git checkout --no-overlay HEAD -- dir/'
doesn't delete all untracked files in dir/, but rather just resets the
state of files that are known to git.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-08 21:52:24 +00:00
|
|
|
|
2019-04-25 09:45:50 +00:00
|
|
|
if (opts->checkout_index >= 0 || opts->checkout_worktree >= 0) {
|
|
|
|
if (opts->checkout_index < 0)
|
|
|
|
opts->checkout_index = 0;
|
|
|
|
if (opts->checkout_worktree < 0)
|
|
|
|
opts->checkout_worktree = 0;
|
|
|
|
} else {
|
|
|
|
if (opts->checkout_index < 0)
|
|
|
|
opts->checkout_index = -opts->checkout_index - 1;
|
|
|
|
if (opts->checkout_worktree < 0)
|
|
|
|
opts->checkout_worktree = -opts->checkout_worktree - 1;
|
|
|
|
}
|
|
|
|
if (opts->checkout_index < 0 || opts->checkout_worktree < 0)
|
|
|
|
BUG("these flags should be non-negative by now");
|
2019-04-25 09:45:52 +00:00
|
|
|
/*
|
2020-05-05 07:17:16 +00:00
|
|
|
* convenient shortcut: "git restore --staged [--worktree]" equals
|
|
|
|
* "git restore --staged [--worktree] --source HEAD"
|
2019-04-25 09:45:52 +00:00
|
|
|
*/
|
2020-05-05 07:17:16 +00:00
|
|
|
if (!opts->from_treeish && opts->checkout_index)
|
2019-04-25 09:45:52 +00:00
|
|
|
opts->from_treeish = "HEAD";
|
2019-04-25 09:45:50 +00:00
|
|
|
|
2012-08-30 12:45:50 +00:00
|
|
|
/*
|
|
|
|
* From here on, new_branch will contain the branch to be checked out,
|
|
|
|
* and new_branch_force and new_orphan_branch will tell us which one of
|
2020-04-30 11:54:57 +00:00
|
|
|
* -b/-B/-c/-C/--orphan is being used.
|
2012-08-30 12:45:50 +00:00
|
|
|
*/
|
2019-03-29 10:39:02 +00:00
|
|
|
if (opts->new_branch_force)
|
|
|
|
opts->new_branch = opts->new_branch_force;
|
2010-06-23 19:29:00 +00:00
|
|
|
|
2019-03-29 10:39:02 +00:00
|
|
|
if (opts->new_orphan_branch)
|
|
|
|
opts->new_branch = opts->new_orphan_branch;
|
2011-02-08 10:32:49 +00:00
|
|
|
|
2020-04-30 11:54:57 +00:00
|
|
|
/* --track without -c/-C/-b/-B/--orphan should DWIM */
|
2019-03-29 10:39:02 +00:00
|
|
|
if (opts->track != BRANCH_TRACK_UNSPECIFIED && !opts->new_branch) {
|
2008-08-21 17:23:20 +00:00
|
|
|
const char *argv0 = argv[0];
|
|
|
|
if (!argc || !strcmp(argv0, "--"))
|
2018-07-21 07:49:19 +00:00
|
|
|
die(_("--track needs a branch name"));
|
2014-10-04 18:54:50 +00:00
|
|
|
skip_prefix(argv0, "refs/", &argv0);
|
|
|
|
skip_prefix(argv0, "remotes/", &argv0);
|
2008-08-21 17:23:20 +00:00
|
|
|
argv0 = strchr(argv0, '/');
|
|
|
|
if (!argv0 || !argv0[1])
|
2020-04-30 11:54:57 +00:00
|
|
|
die(_("missing branch name; try -%c"), cb_option);
|
2019-03-29 10:39:02 +00:00
|
|
|
opts->new_branch = argv0 + 1;
|
2008-08-09 14:00:12 +00:00
|
|
|
}
|
|
|
|
|
2008-07-23 10:15:33 +00:00
|
|
|
/*
|
2011-02-08 10:29:09 +00:00
|
|
|
* Extract branch name from command line arguments, so
|
|
|
|
* all that is left is pathspecs.
|
2008-07-23 10:15:33 +00:00
|
|
|
*
|
2011-02-08 10:29:09 +00:00
|
|
|
* Handle
|
2009-10-18 07:13:47 +00:00
|
|
|
*
|
2011-02-08 10:29:09 +00:00
|
|
|
* 1) git checkout <tree> -- [<paths>]
|
|
|
|
* 2) git checkout -- [<paths>]
|
|
|
|
* 3) git checkout <something> [<paths>]
|
2008-07-23 10:15:33 +00:00
|
|
|
*
|
2011-02-08 10:29:09 +00:00
|
|
|
* including "last branch" syntax and DWIM-ery for names of
|
|
|
|
* remote branches, erroring out for invalid or ambiguous cases.
|
2008-07-23 10:15:33 +00:00
|
|
|
*/
|
2019-04-25 09:45:46 +00:00
|
|
|
if (argc && opts->accept_ref) {
|
2016-09-05 20:08:00 +00:00
|
|
|
struct object_id rev;
|
2011-02-08 10:29:09 +00:00
|
|
|
int dwim_ok =
|
2019-03-29 10:39:02 +00:00
|
|
|
!opts->patch_mode &&
|
2019-03-29 10:39:13 +00:00
|
|
|
opts->dwim_new_local_branch &&
|
2019-03-29 10:39:02 +00:00
|
|
|
opts->track == BRANCH_TRACK_UNSPECIFIED &&
|
|
|
|
!opts->new_branch;
|
2011-02-08 10:34:34 +00:00
|
|
|
int n = parse_branchname_arg(argc, argv, dwim_ok,
|
checkout: plug some leaks in git-restore
In git-restore we need to free the pathspec and pathspec_from_file
values from the struct checkout_opts.
A simple fix could be to free them in cmd_restore, after the call to
checkout_main returns, like we are doing [1][2] in the sibling function
cmd_checkout.
However, we can do even better.
We have git-switch and git-restore, both of them spin-offs[3][4] of
git-checkout. All three are implemented as thin wrappers around
checkout_main. Considering this, it makes a lot of sense to do the
cleanup closer to checkout_main.
Move the cleanups, including the new_branch_info variable, to
checkout_main.
As a consequence, mark: t2070, t2071, t2072 and t6418 as leak-free.
[1] 9081a421a6 (checkout: fix "branch info" memory leaks, 2021-11-16)
[2] 7ce4088ab7 (parse-options: consistently allocate memory in
fix_filename(), 2023-03-04)
[3] d787d311db (checkout: split part of it to new command 'switch',
2019-03-29)
[4] 46e91b663b (checkout: split part of it to new command 'restore',
2019-04-25)
Signed-off-by: Rubén Justo <rjusto@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-14 18:08:58 +00:00
|
|
|
&new_branch_info, opts, &rev);
|
2011-02-08 10:29:09 +00:00
|
|
|
argv += n;
|
|
|
|
argc -= n;
|
2019-04-25 09:45:46 +00:00
|
|
|
} else if (!opts->accept_ref && opts->from_treeish) {
|
|
|
|
struct object_id rev;
|
|
|
|
|
2023-03-28 13:58:46 +00:00
|
|
|
if (repo_get_oid_mb(the_repository, opts->from_treeish, &rev))
|
2019-04-25 09:45:46 +00:00
|
|
|
die(_("could not resolve %s"), opts->from_treeish);
|
|
|
|
|
checkout: plug some leaks in git-restore
In git-restore we need to free the pathspec and pathspec_from_file
values from the struct checkout_opts.
A simple fix could be to free them in cmd_restore, after the call to
checkout_main returns, like we are doing [1][2] in the sibling function
cmd_checkout.
However, we can do even better.
We have git-switch and git-restore, both of them spin-offs[3][4] of
git-checkout. All three are implemented as thin wrappers around
checkout_main. Considering this, it makes a lot of sense to do the
cleanup closer to checkout_main.
Move the cleanups, including the new_branch_info variable, to
checkout_main.
As a consequence, mark: t2070, t2071, t2072 and t6418 as leak-free.
[1] 9081a421a6 (checkout: fix "branch info" memory leaks, 2021-11-16)
[2] 7ce4088ab7 (parse-options: consistently allocate memory in
fix_filename(), 2023-03-04)
[3] d787d311db (checkout: split part of it to new command 'switch',
2019-03-29)
[4] 46e91b663b (checkout: split part of it to new command 'restore',
2019-04-25)
Signed-off-by: Rubén Justo <rjusto@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-14 18:08:58 +00:00
|
|
|
setup_new_branch_info_and_source_tree(&new_branch_info,
|
2019-04-25 09:45:46 +00:00
|
|
|
opts, &rev,
|
|
|
|
opts->from_treeish);
|
|
|
|
|
|
|
|
if (!opts->source_tree)
|
|
|
|
die(_("reference is not a tree: %s"), opts->from_treeish);
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (argc) {
|
2019-03-29 10:39:02 +00:00
|
|
|
parse_pathspec(&opts->pathspec, 0,
|
|
|
|
opts->patch_mode ? PATHSPEC_PREFIX_ORIGIN : 0,
|
2013-07-14 08:35:50 +00:00
|
|
|
prefix, argv);
|
2008-02-28 16:30:47 +00:00
|
|
|
|
2019-03-29 10:39:02 +00:00
|
|
|
if (!opts->pathspec.nr)
|
2011-02-22 23:41:39 +00:00
|
|
|
die(_("invalid path specification"));
|
2008-02-28 16:30:47 +00:00
|
|
|
|
2012-08-30 12:45:50 +00:00
|
|
|
/*
|
|
|
|
* Try to give more helpful suggestion.
|
|
|
|
* new_branch && argc > 1 will be caught later.
|
|
|
|
*/
|
checkout: plug some leaks in git-restore
In git-restore we need to free the pathspec and pathspec_from_file
values from the struct checkout_opts.
A simple fix could be to free them in cmd_restore, after the call to
checkout_main returns, like we are doing [1][2] in the sibling function
cmd_checkout.
However, we can do even better.
We have git-switch and git-restore, both of them spin-offs[3][4] of
git-checkout. All three are implemented as thin wrappers around
checkout_main. Considering this, it makes a lot of sense to do the
cleanup closer to checkout_main.
Move the cleanups, including the new_branch_info variable, to
checkout_main.
As a consequence, mark: t2070, t2071, t2072 and t6418 as leak-free.
[1] 9081a421a6 (checkout: fix "branch info" memory leaks, 2021-11-16)
[2] 7ce4088ab7 (parse-options: consistently allocate memory in
fix_filename(), 2023-03-04)
[3] d787d311db (checkout: split part of it to new command 'switch',
2019-03-29)
[4] 46e91b663b (checkout: split part of it to new command 'restore',
2019-04-25)
Signed-off-by: Rubén Justo <rjusto@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-14 18:08:58 +00:00
|
|
|
if (opts->new_branch && argc == 1 && !new_branch_info.commit)
|
2017-05-11 12:06:32 +00:00
|
|
|
die(_("'%s' is not a commit and a branch '%s' cannot be created from it"),
|
2019-03-29 10:39:02 +00:00
|
|
|
argv[0], opts->new_branch);
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
|
2019-03-29 10:39:02 +00:00
|
|
|
if (opts->force_detach)
|
2012-08-30 12:45:50 +00:00
|
|
|
die(_("git checkout: --detach does not take a path argument '%s'"),
|
|
|
|
argv[0]);
|
2019-12-03 14:02:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (opts->pathspec_from_file) {
|
|
|
|
if (opts->pathspec.nr)
|
2022-01-05 20:02:24 +00:00
|
|
|
die(_("'%s' and pathspec arguments cannot be used together"), "--pathspec-from-file");
|
2019-12-03 14:02:18 +00:00
|
|
|
|
|
|
|
if (opts->force_detach)
|
2022-01-05 20:02:16 +00:00
|
|
|
die(_("options '%s' and '%s' cannot be used together"), "--pathspec-from-file", "--detach");
|
2011-02-08 10:32:49 +00:00
|
|
|
|
2019-12-03 14:02:18 +00:00
|
|
|
if (opts->patch_mode)
|
2022-01-05 20:02:16 +00:00
|
|
|
die(_("options '%s' and '%s' cannot be used together"), "--pathspec-from-file", "--patch");
|
2019-12-03 14:02:18 +00:00
|
|
|
|
|
|
|
parse_pathspec_file(&opts->pathspec, 0,
|
|
|
|
0,
|
|
|
|
prefix, opts->pathspec_from_file, opts->pathspec_file_nul);
|
|
|
|
} else if (opts->pathspec_file_nul) {
|
2022-01-05 20:02:19 +00:00
|
|
|
die(_("the option '%s' requires '%s'"), "--pathspec-file-nul", "--pathspec-from-file");
|
2019-12-03 14:02:18 +00:00
|
|
|
}
|
|
|
|
|
2020-08-22 08:57:59 +00:00
|
|
|
opts->pathspec.recursive = 1;
|
|
|
|
|
2019-12-03 14:02:18 +00:00
|
|
|
if (opts->pathspec.nr) {
|
2019-03-29 10:39:02 +00:00
|
|
|
if (1 < !!opts->writeout_stage + !!opts->force + !!opts->merge)
|
2012-08-30 12:45:50 +00:00
|
|
|
die(_("git checkout: --ours/--theirs, --force and --merge are incompatible when\n"
|
|
|
|
"checking out of the index."));
|
2019-12-03 14:02:18 +00:00
|
|
|
} else {
|
|
|
|
if (opts->accept_pathspec && !opts->empty_pathspec_ok &&
|
|
|
|
!opts->patch_mode) /* patch mode is special */
|
|
|
|
die(_("you must specify path(s) to restore"));
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
}
|
|
|
|
|
2019-03-29 10:39:02 +00:00
|
|
|
if (opts->new_branch) {
|
2008-10-09 19:12:12 +00:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2011-08-20 21:49:48 +00:00
|
|
|
|
2019-03-29 10:39:02 +00:00
|
|
|
if (opts->new_branch_force)
|
|
|
|
opts->branch_exists = validate_branchname(opts->new_branch, &buf);
|
2017-10-13 04:45:40 +00:00
|
|
|
else
|
2019-03-29 10:39:02 +00:00
|
|
|
opts->branch_exists =
|
|
|
|
validate_new_branchname(opts->new_branch, &buf, 0);
|
2008-09-21 18:36:06 +00:00
|
|
|
strbuf_release(&buf);
|
|
|
|
}
|
|
|
|
|
checkout: don't revert file on ambiguous tracking branches
For easier understanding, here are the existing good scenarios:
1) Have *no* file 'foo', *no* local branch 'foo' and a *single*
remote branch 'foo'
2) `git checkout foo` will create local branch foo, see [1]
and
1) Have *a* file 'foo', *no* local branch 'foo' and a *single*
remote branch 'foo'
2) `git checkout foo` will complain, see [3]
This patch prevents the following scenario:
1) Have *a* file 'foo', *no* local branch 'foo' and *multiple*
remote branches 'foo'
2) `git checkout foo` will successfully... revert contents of
file `foo`!
That is, adding another remote suddenly changes behavior significantly,
which is a surprise at best and could go unnoticed by user at worst.
Please see [3] which gives some real world complaints.
To my understanding, fix in [3] overlooked the case of multiple remotes,
and the whole behavior of falling back to reverting file was never
intended:
[1] introduces the unexpected behavior. Before, there was fallback
from not-a-ref to pathspec. This is reasonable fallback. After, there
is another fallback from ambiguous-remote to pathspec. I understand
that it was a copy&paste oversight.
[2] noticed the unexpected behavior but chose to semi-document it
instead of forbidding, because the goal of the patch series was
focused on something else.
[3] adds `die()` when there is ambiguity between branch and file. The
case of multiple tracking branches is seemingly overlooked.
The new behavior: if there is no local branch and multiple remote
candidates, just die() and don't try reverting file whether it
exists (prevents surprise) or not (improves error message).
[1] Commit 70c9ac2f ("DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"" 2009-10-18)
https://public-inbox.org/git/7vaazpxha4.fsf_-_@alter.siamese.dyndns.org/
[2] Commit ad8d5104 ("checkout: add advice for ambiguous "checkout <branch>"", 2018-06-05)
https://public-inbox.org/git/20180502105452.17583-1-avarab@gmail.com/
[3] Commit be4908f1 ("checkout: disambiguate dwim tracking branches and local files", 2018-11-13)
https://public-inbox.org/git/20181110120707.25846-1-pclouds@gmail.com/
Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-30 18:38:13 +00:00
|
|
|
if (opts->patch_mode || opts->pathspec.nr)
|
checkout: plug some leaks in git-restore
In git-restore we need to free the pathspec and pathspec_from_file
values from the struct checkout_opts.
A simple fix could be to free them in cmd_restore, after the call to
checkout_main returns, like we are doing [1][2] in the sibling function
cmd_checkout.
However, we can do even better.
We have git-switch and git-restore, both of them spin-offs[3][4] of
git-checkout. All three are implemented as thin wrappers around
checkout_main. Considering this, it makes a lot of sense to do the
cleanup closer to checkout_main.
Move the cleanups, including the new_branch_info variable, to
checkout_main.
As a consequence, mark: t2070, t2071, t2072 and t6418 as leak-free.
[1] 9081a421a6 (checkout: fix "branch info" memory leaks, 2021-11-16)
[2] 7ce4088ab7 (parse-options: consistently allocate memory in
fix_filename(), 2023-03-04)
[3] d787d311db (checkout: split part of it to new command 'switch',
2019-03-29)
[4] 46e91b663b (checkout: split part of it to new command 'restore',
2019-04-25)
Signed-off-by: Rubén Justo <rjusto@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-14 18:08:58 +00:00
|
|
|
ret = checkout_paths(opts, &new_branch_info);
|
checkout: don't revert file on ambiguous tracking branches
For easier understanding, here are the existing good scenarios:
1) Have *no* file 'foo', *no* local branch 'foo' and a *single*
remote branch 'foo'
2) `git checkout foo` will create local branch foo, see [1]
and
1) Have *a* file 'foo', *no* local branch 'foo' and a *single*
remote branch 'foo'
2) `git checkout foo` will complain, see [3]
This patch prevents the following scenario:
1) Have *a* file 'foo', *no* local branch 'foo' and *multiple*
remote branches 'foo'
2) `git checkout foo` will successfully... revert contents of
file `foo`!
That is, adding another remote suddenly changes behavior significantly,
which is a surprise at best and could go unnoticed by user at worst.
Please see [3] which gives some real world complaints.
To my understanding, fix in [3] overlooked the case of multiple remotes,
and the whole behavior of falling back to reverting file was never
intended:
[1] introduces the unexpected behavior. Before, there was fallback
from not-a-ref to pathspec. This is reasonable fallback. After, there
is another fallback from ambiguous-remote to pathspec. I understand
that it was a copy&paste oversight.
[2] noticed the unexpected behavior but chose to semi-document it
instead of forbidding, because the goal of the patch series was
focused on something else.
[3] adds `die()` when there is ambiguity between branch and file. The
case of multiple tracking branches is seemingly overlooked.
The new behavior: if there is no local branch and multiple remote
candidates, just die() and don't try reverting file whether it
exists (prevents surprise) or not (improves error message).
[1] Commit 70c9ac2f ("DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"" 2009-10-18)
https://public-inbox.org/git/7vaazpxha4.fsf_-_@alter.siamese.dyndns.org/
[2] Commit ad8d5104 ("checkout: add advice for ambiguous "checkout <branch>"", 2018-06-05)
https://public-inbox.org/git/20180502105452.17583-1-avarab@gmail.com/
[3] Commit be4908f1 ("checkout: disambiguate dwim tracking branches and local files", 2018-11-13)
https://public-inbox.org/git/20181110120707.25846-1-pclouds@gmail.com/
Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-30 18:38:13 +00:00
|
|
|
else
|
checkout: plug some leaks in git-restore
In git-restore we need to free the pathspec and pathspec_from_file
values from the struct checkout_opts.
A simple fix could be to free them in cmd_restore, after the call to
checkout_main returns, like we are doing [1][2] in the sibling function
cmd_checkout.
However, we can do even better.
We have git-switch and git-restore, both of them spin-offs[3][4] of
git-checkout. All three are implemented as thin wrappers around
checkout_main. Considering this, it makes a lot of sense to do the
cleanup closer to checkout_main.
Move the cleanups, including the new_branch_info variable, to
checkout_main.
As a consequence, mark: t2070, t2071, t2072 and t6418 as leak-free.
[1] 9081a421a6 (checkout: fix "branch info" memory leaks, 2021-11-16)
[2] 7ce4088ab7 (parse-options: consistently allocate memory in
fix_filename(), 2023-03-04)
[3] d787d311db (checkout: split part of it to new command 'switch',
2019-03-29)
[4] 46e91b663b (checkout: split part of it to new command 'restore',
2019-04-25)
Signed-off-by: Rubén Justo <rjusto@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-14 18:08:58 +00:00
|
|
|
ret = checkout_branch(opts, &new_branch_info);
|
|
|
|
|
|
|
|
branch_info_release(&new_branch_info);
|
|
|
|
clear_pathspec(&opts->pathspec);
|
|
|
|
free(opts->pathspec_from_file);
|
|
|
|
free(options);
|
|
|
|
|
|
|
|
return ret;
|
Build in checkout
The only differences in behavior should be:
- git checkout -m with non-trivial merging won't print out
merge-recursive messages (see the change in t7201-co.sh)
- git checkout -- paths... will give a sensible error message if
HEAD is invalid as a commit.
- some intermediate states which were written to disk in the shell
version (in particular, index states) are only kept in memory in
this version, and therefore these can no longer be revealed by
later write operations becoming impossible.
- when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
rr-cache/MERGE_RR, like reset always has.
I'm not 100% sure I got the merge recursive setup exactly right; the
base for a non-trivial merge in the shell code doesn't seem
theoretically justified to me, but I tried to match it anyway, and the
tests all pass this way.
Other than these items, the results should be identical to the shell
version, so far as I can tell.
[jc: squashed lock-file fix from Dscho in]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-07 16:40:23 +00:00
|
|
|
}
|
2019-03-29 10:39:05 +00:00
|
|
|
|
|
|
|
int cmd_checkout(int argc, const char **argv, const char *prefix)
|
|
|
|
{
|
2024-03-14 17:05:06 +00:00
|
|
|
struct checkout_opts opts = CHECKOUT_OPTS_INIT;
|
2019-03-29 10:39:06 +00:00
|
|
|
struct option *options;
|
|
|
|
struct option checkout_options[] = {
|
|
|
|
OPT_STRING('b', NULL, &opts.new_branch, N_("branch"),
|
|
|
|
N_("create and checkout a new branch")),
|
|
|
|
OPT_STRING('B', NULL, &opts.new_branch_force, N_("branch"),
|
|
|
|
N_("create/reset and checkout a branch")),
|
2019-03-29 10:39:08 +00:00
|
|
|
OPT_BOOL('l', NULL, &opts.new_branch_log, N_("create reflog for new branch")),
|
2019-03-29 10:39:13 +00:00
|
|
|
OPT_BOOL(0, "guess", &opts.dwim_new_local_branch,
|
|
|
|
N_("second guess 'git checkout <no-such-branch>' (default)")),
|
2019-04-25 09:45:48 +00:00
|
|
|
OPT_BOOL(0, "overlay", &opts.overlay_mode, N_("use overlay mode (default)")),
|
2019-03-29 10:39:06 +00:00
|
|
|
OPT_END()
|
|
|
|
};
|
2019-03-29 10:39:05 +00:00
|
|
|
|
2019-03-29 10:39:13 +00:00
|
|
|
opts.dwim_new_local_branch = 1;
|
2019-03-29 10:39:10 +00:00
|
|
|
opts.switch_branch_doing_nothing_is_ok = 1;
|
2019-03-29 10:39:14 +00:00
|
|
|
opts.only_merge_on_switching_branches = 0;
|
2019-04-25 09:45:46 +00:00
|
|
|
opts.accept_ref = 1;
|
2019-03-29 10:39:09 +00:00
|
|
|
opts.accept_pathspec = 1;
|
2019-03-29 10:39:11 +00:00
|
|
|
opts.implicit_detach = 1;
|
2019-03-29 10:39:15 +00:00
|
|
|
opts.can_switch_when_in_progress = 1;
|
2019-03-29 10:39:16 +00:00
|
|
|
opts.orphan_from_empty_tree = 0;
|
2019-04-25 09:45:47 +00:00
|
|
|
opts.empty_pathspec_ok = 1;
|
2019-04-25 09:45:48 +00:00
|
|
|
opts.overlay_mode = -1;
|
2019-04-25 09:45:50 +00:00
|
|
|
opts.checkout_index = -2; /* default on */
|
|
|
|
opts.checkout_worktree = -2; /* default on */
|
2019-03-29 10:39:05 +00:00
|
|
|
|
2019-08-29 17:01:32 +00:00
|
|
|
if (argc == 3 && !strcmp(argv[1], "-b")) {
|
|
|
|
/*
|
|
|
|
* User ran 'git checkout -b <branch>' and expects
|
|
|
|
* the same behavior as 'git switch -c <branch>'.
|
|
|
|
*/
|
|
|
|
opts.switch_branch_doing_nothing_is_ok = 0;
|
|
|
|
opts.only_merge_on_switching_branches = 1;
|
|
|
|
}
|
|
|
|
|
2019-03-29 10:39:06 +00:00
|
|
|
options = parse_options_dup(checkout_options);
|
2019-03-29 10:39:05 +00:00
|
|
|
options = add_common_options(&opts, options);
|
2019-03-29 10:39:06 +00:00
|
|
|
options = add_common_switch_branch_options(&opts, options);
|
2019-03-29 10:39:05 +00:00
|
|
|
options = add_checkout_path_options(&opts, options);
|
|
|
|
|
checkout: plug some leaks in git-restore
In git-restore we need to free the pathspec and pathspec_from_file
values from the struct checkout_opts.
A simple fix could be to free them in cmd_restore, after the call to
checkout_main returns, like we are doing [1][2] in the sibling function
cmd_checkout.
However, we can do even better.
We have git-switch and git-restore, both of them spin-offs[3][4] of
git-checkout. All three are implemented as thin wrappers around
checkout_main. Considering this, it makes a lot of sense to do the
cleanup closer to checkout_main.
Move the cleanups, including the new_branch_info variable, to
checkout_main.
As a consequence, mark: t2070, t2071, t2072 and t6418 as leak-free.
[1] 9081a421a6 (checkout: fix "branch info" memory leaks, 2021-11-16)
[2] 7ce4088ab7 (parse-options: consistently allocate memory in
fix_filename(), 2023-03-04)
[3] d787d311db (checkout: split part of it to new command 'switch',
2019-03-29)
[4] 46e91b663b (checkout: split part of it to new command 'restore',
2019-04-25)
Signed-off-by: Rubén Justo <rjusto@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-14 18:08:58 +00:00
|
|
|
return checkout_main(argc, argv, prefix, &opts, options,
|
|
|
|
checkout_usage);
|
2019-03-29 10:39:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
int cmd_switch(int argc, const char **argv, const char *prefix)
|
|
|
|
{
|
2024-03-14 17:05:06 +00:00
|
|
|
struct checkout_opts opts = CHECKOUT_OPTS_INIT;
|
2019-03-29 10:39:05 +00:00
|
|
|
struct option *options = NULL;
|
2019-03-29 10:39:06 +00:00
|
|
|
struct option switch_options[] = {
|
|
|
|
OPT_STRING('c', "create", &opts.new_branch, N_("branch"),
|
|
|
|
N_("create and switch to a new branch")),
|
|
|
|
OPT_STRING('C', "force-create", &opts.new_branch_force, N_("branch"),
|
|
|
|
N_("create/reset and switch to a branch")),
|
2019-03-29 10:39:13 +00:00
|
|
|
OPT_BOOL(0, "guess", &opts.dwim_new_local_branch,
|
|
|
|
N_("second guess 'git switch <no-such-branch>'")),
|
2019-03-29 10:39:07 +00:00
|
|
|
OPT_BOOL(0, "discard-changes", &opts.discard_changes,
|
|
|
|
N_("throw away local modifications")),
|
2019-03-29 10:39:06 +00:00
|
|
|
OPT_END()
|
|
|
|
};
|
2019-03-29 10:39:05 +00:00
|
|
|
|
2019-03-29 10:39:13 +00:00
|
|
|
opts.dwim_new_local_branch = 1;
|
2019-04-25 09:45:46 +00:00
|
|
|
opts.accept_ref = 1;
|
2019-03-29 10:39:09 +00:00
|
|
|
opts.accept_pathspec = 0;
|
2019-03-29 10:39:10 +00:00
|
|
|
opts.switch_branch_doing_nothing_is_ok = 0;
|
2019-03-29 10:39:14 +00:00
|
|
|
opts.only_merge_on_switching_branches = 1;
|
2019-03-29 10:39:11 +00:00
|
|
|
opts.implicit_detach = 0;
|
2019-03-29 10:39:15 +00:00
|
|
|
opts.can_switch_when_in_progress = 0;
|
2019-03-29 10:39:16 +00:00
|
|
|
opts.orphan_from_empty_tree = 1;
|
2019-04-25 09:45:48 +00:00
|
|
|
opts.overlay_mode = -1;
|
2019-03-29 10:39:05 +00:00
|
|
|
|
2019-03-29 10:39:06 +00:00
|
|
|
options = parse_options_dup(switch_options);
|
2019-03-29 10:39:05 +00:00
|
|
|
options = add_common_options(&opts, options);
|
2019-03-29 10:39:06 +00:00
|
|
|
options = add_common_switch_branch_options(&opts, options);
|
2019-03-29 10:39:05 +00:00
|
|
|
|
2020-04-30 11:54:57 +00:00
|
|
|
cb_option = 'c';
|
|
|
|
|
checkout: plug some leaks in git-restore
In git-restore we need to free the pathspec and pathspec_from_file
values from the struct checkout_opts.
A simple fix could be to free them in cmd_restore, after the call to
checkout_main returns, like we are doing [1][2] in the sibling function
cmd_checkout.
However, we can do even better.
We have git-switch and git-restore, both of them spin-offs[3][4] of
git-checkout. All three are implemented as thin wrappers around
checkout_main. Considering this, it makes a lot of sense to do the
cleanup closer to checkout_main.
Move the cleanups, including the new_branch_info variable, to
checkout_main.
As a consequence, mark: t2070, t2071, t2072 and t6418 as leak-free.
[1] 9081a421a6 (checkout: fix "branch info" memory leaks, 2021-11-16)
[2] 7ce4088ab7 (parse-options: consistently allocate memory in
fix_filename(), 2023-03-04)
[3] d787d311db (checkout: split part of it to new command 'switch',
2019-03-29)
[4] 46e91b663b (checkout: split part of it to new command 'restore',
2019-04-25)
Signed-off-by: Rubén Justo <rjusto@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-14 18:08:58 +00:00
|
|
|
return checkout_main(argc, argv, prefix, &opts, options,
|
|
|
|
switch_branch_usage);
|
2019-03-29 10:39:05 +00:00
|
|
|
}
|
2019-04-25 09:45:45 +00:00
|
|
|
|
|
|
|
int cmd_restore(int argc, const char **argv, const char *prefix)
|
|
|
|
{
|
2024-03-14 17:05:06 +00:00
|
|
|
struct checkout_opts opts = CHECKOUT_OPTS_INIT;
|
2019-04-25 09:45:46 +00:00
|
|
|
struct option *options;
|
|
|
|
struct option restore_options[] = {
|
|
|
|
OPT_STRING('s', "source", &opts.from_treeish, "<tree-ish>",
|
2019-08-06 17:19:52 +00:00
|
|
|
N_("which tree-ish to checkout from")),
|
2019-04-25 09:45:50 +00:00
|
|
|
OPT_BOOL('S', "staged", &opts.checkout_index,
|
|
|
|
N_("restore the index")),
|
|
|
|
OPT_BOOL('W', "worktree", &opts.checkout_worktree,
|
|
|
|
N_("restore the working tree (default)")),
|
2019-04-25 09:45:53 +00:00
|
|
|
OPT_BOOL(0, "ignore-unmerged", &opts.ignore_unmerged,
|
|
|
|
N_("ignore unmerged entries")),
|
2019-04-25 09:45:48 +00:00
|
|
|
OPT_BOOL(0, "overlay", &opts.overlay_mode, N_("use overlay mode")),
|
2019-04-25 09:45:46 +00:00
|
|
|
OPT_END()
|
|
|
|
};
|
2019-04-25 09:45:45 +00:00
|
|
|
|
2019-04-25 09:45:46 +00:00
|
|
|
opts.accept_ref = 0;
|
2019-04-25 09:45:45 +00:00
|
|
|
opts.accept_pathspec = 1;
|
2019-04-25 09:45:47 +00:00
|
|
|
opts.empty_pathspec_ok = 0;
|
2019-04-25 09:45:48 +00:00
|
|
|
opts.overlay_mode = 0;
|
2019-04-25 09:45:50 +00:00
|
|
|
opts.checkout_index = -1; /* default off */
|
|
|
|
opts.checkout_worktree = -2; /* default on */
|
2019-04-25 09:45:53 +00:00
|
|
|
opts.ignore_unmerged_opt = "--ignore-unmerged";
|
2019-04-25 09:45:45 +00:00
|
|
|
|
2019-04-25 09:45:46 +00:00
|
|
|
options = parse_options_dup(restore_options);
|
2019-04-25 09:45:45 +00:00
|
|
|
options = add_common_options(&opts, options);
|
|
|
|
options = add_checkout_path_options(&opts, options);
|
|
|
|
|
checkout: plug some leaks in git-restore
In git-restore we need to free the pathspec and pathspec_from_file
values from the struct checkout_opts.
A simple fix could be to free them in cmd_restore, after the call to
checkout_main returns, like we are doing [1][2] in the sibling function
cmd_checkout.
However, we can do even better.
We have git-switch and git-restore, both of them spin-offs[3][4] of
git-checkout. All three are implemented as thin wrappers around
checkout_main. Considering this, it makes a lot of sense to do the
cleanup closer to checkout_main.
Move the cleanups, including the new_branch_info variable, to
checkout_main.
As a consequence, mark: t2070, t2071, t2072 and t6418 as leak-free.
[1] 9081a421a6 (checkout: fix "branch info" memory leaks, 2021-11-16)
[2] 7ce4088ab7 (parse-options: consistently allocate memory in
fix_filename(), 2023-03-04)
[3] d787d311db (checkout: split part of it to new command 'switch',
2019-03-29)
[4] 46e91b663b (checkout: split part of it to new command 'restore',
2019-04-25)
Signed-off-by: Rubén Justo <rjusto@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-14 18:08:58 +00:00
|
|
|
return checkout_main(argc, argv, prefix, &opts, options,
|
|
|
|
restore_usage);
|
2019-04-25 09:45:45 +00:00
|
|
|
}
|