2019-01-24 08:29:12 +00:00
|
|
|
#define USE_THE_INDEX_COMPATIBILITY_MACROS
|
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"
|
2017-06-14 18:07:36 +00:00
|
|
|
#include "config.h"
|
2017-11-26 19:43:51 +00:00
|
|
|
#include "checkout.h"
|
2014-10-01 10:28:42 +00:00
|
|
|
#include "lockfile.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"
|
|
|
|
#include "refs.h"
|
2018-05-15 23:42:15 +00:00
|
|
|
#include "object-store.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 "commit.h"
|
|
|
|
#include "tree.h"
|
|
|
|
#include "tree-walk.h"
|
2009-04-20 10:58:18 +00:00
|
|
|
#include "cache-tree.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 "unpack-trees.h"
|
|
|
|
#include "dir.h"
|
|
|
|
#include "run-command.h"
|
|
|
|
#include "merge-recursive.h"
|
|
|
|
#include "branch.h"
|
|
|
|
#include "diff.h"
|
|
|
|
#include "revision.h"
|
2008-02-17 01:17:09 +00:00
|
|
|
#include "remote.h"
|
2008-08-30 14:52:24 +00:00
|
|
|
#include "blob.h"
|
|
|
|
#include "xdiff-interface.h"
|
|
|
|
#include "ll-merge.h"
|
2009-12-25 08:30:51 +00:00
|
|
|
#include "resolve-undo.h"
|
2015-08-18 00:21:59 +00:00
|
|
|
#include "submodule-config.h"
|
2010-08-25 10:34:57 +00:00
|
|
|
#include "submodule.h"
|
checkout: add advice for ambiguous "checkout <branch>"
As the "checkout" documentation describes:
If <branch> is not found but there does exist a tracking branch in
exactly one remote (call it <remote>) with a matching name, treat
as equivalent to [...] <remote>/<branch.
This is a really useful feature. The problem is that when you add
another remote (e.g. a fork), git won't find a unique branch name
anymore, and will instead print this unhelpful message:
$ git checkout master
error: pathspec 'master' did not match any file(s) known to git
Now it will, on my git.git checkout, print:
$ ./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>
Note that the "error: pathspec[...]" message is still printed. This is
because whatever else checkout may have tried earlier, its final
fallback is to try to resolve the argument as a path. E.g. in this
case:
$ ./git --exec-path=$PWD checkout master pu
error: pathspec 'master' did not match any file(s) known to git.
error: pathspec 'pu' did not match any file(s) known to git.
There we don't print the "hint:" implicitly due to earlier logic
around the DWIM fallback. That fallback is only used if it looks like
we have one argument that might be a branch.
I can't think of an intrinsic reason for why we couldn't in some
future change skip printing the "error: pathspec[...]" error. However,
to do so we'd need to pass something down to checkout_paths() to make
it suppress printing an error on its own, and for us to be confident
that we're not silencing cases where those errors are meaningful.
I don't think that's worth it since determining whether that's the
case could easily change due to future changes in the checkout logic.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:48 +00:00
|
|
|
#include "advice.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
|
|
|
|
2018-08-16 18:27:11 +00:00
|
|
|
static int checkout_optimize_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
|
|
|
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,
|
|
|
|
};
|
|
|
|
|
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;
|
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;
|
2018-08-16 18:27:11 +00:00
|
|
|
/*
|
|
|
|
* If new checkout options are added, skip_merge_working_tree
|
|
|
|
* should be updated accordingly.
|
|
|
|
*/
|
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;
|
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;
|
2012-08-29 13:55:23 +00:00
|
|
|
struct tree *source_tree;
|
2008-08-30 14:46:55 +00:00
|
|
|
};
|
|
|
|
|
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)
|
|
|
|
{
|
2014-03-18 10:00:53 +00:00
|
|
|
return run_hook_le(NULL, "post-checkout",
|
2018-02-14 18:59:31 +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,
|
2008-07-14 19:22:12 +00:00
|
|
|
const char *pathname, unsigned mode, int stage, void *context)
|
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.
|
|
|
|
*/
|
|
|
|
pos = cache_name_pos(ce->name, ce->ce_namelen);
|
|
|
|
if (pos >= 0) {
|
|
|
|
struct cache_entry *old = active_cache[pos];
|
|
|
|
if (ce->ce_mode == old->ce_mode &&
|
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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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_cache_entry(ce, ADD_CACHE_OK_TO_ADD | ADD_CACHE_OK_TO_REPLACE);
|
|
|
|
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
|
|
|
{
|
2018-11-18 16:47:56 +00:00
|
|
|
read_tree_recursive(the_repository, tree, "", 0, 0,
|
|
|
|
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
|
|
|
{
|
|
|
|
while (++pos < active_nr &&
|
|
|
|
!strcmp(active_cache[pos]->name, ce->name))
|
|
|
|
; /* 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
|
|
|
{
|
|
|
|
while (pos < active_nr &&
|
|
|
|
!strcmp(active_cache[pos]->name, ce->name)) {
|
|
|
|
if (ce_stage(active_cache[pos]) == stage)
|
|
|
|
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;
|
|
|
|
|
|
|
|
while (pos < active_nr) {
|
|
|
|
ce = active_cache[pos];
|
|
|
|
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
|
|
|
{
|
|
|
|
while (pos < active_nr &&
|
|
|
|
!strcmp(active_cache[pos]->name, ce->name)) {
|
|
|
|
if (ce_stage(active_cache[pos]) == stage)
|
2018-11-13 18:28:00 +00:00
|
|
|
return checkout_entry(active_cache[pos], state,
|
|
|
|
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) {
|
|
|
|
unlink_entry(ce);
|
|
|
|
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
|
|
|
|
2018-11-13 18:28:00 +00:00
|
|
|
static int checkout_merged(int pos, const struct checkout *state, int *nr_checkouts)
|
2008-08-30 14:52:24 +00:00
|
|
|
{
|
|
|
|
struct cache_entry *ce = active_cache[pos];
|
|
|
|
const char *path = ce->name;
|
|
|
|
mmfile_t ancestor, ours, theirs;
|
|
|
|
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;
|
2008-08-30 14:52:24 +00:00
|
|
|
|
2011-12-05 18:58:23 +00:00
|
|
|
memset(threeway, 0, sizeof(threeway));
|
|
|
|
while (pos < active_nr) {
|
|
|
|
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++;
|
|
|
|
ce = active_cache[pos];
|
|
|
|
}
|
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
|
|
|
|
2010-08-05 11:24:58 +00:00
|
|
|
/*
|
|
|
|
* NEEDSWORK: re-create conflicts from merges with
|
|
|
|
* merge.renormalize set, too
|
|
|
|
*/
|
2010-03-21 00:40:19 +00:00
|
|
|
status = ll_merge(&result_buf, path, &ancestor, "base",
|
2018-09-21 15:57:27 +00:00
|
|
|
&ours, "ours", &theirs, "theirs",
|
|
|
|
state->istate, NULL);
|
2008-08-30 14:52:24 +00:00
|
|
|
free(ancestor.ptr);
|
|
|
|
free(ours.ptr);
|
|
|
|
free(theirs.ptr);
|
|
|
|
if (status < 0 || !result_buf.ptr) {
|
|
|
|
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
|
|
|
*/
|
2018-01-28 00:13:19 +00:00
|
|
|
if (write_object_file(result_buf.ptr, result_buf.size, blob_type, &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);
|
2018-07-02 19:49:31 +00:00
|
|
|
ce = make_transient_cache_entry(mode, &oid, path, 2);
|
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);
|
2018-07-02 19:49:31 +00:00
|
|
|
discard_cache_entry(ce);
|
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
|
|
|
|
* need ps_matched and read_tree_recursive (and
|
|
|
|
* 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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-08-30 12:45:50 +00:00
|
|
|
static int checkout_paths(const struct checkout_opts *opts,
|
|
|
|
const char *revision)
|
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;
|
2016-09-22 16:11:33 +00:00
|
|
|
struct checkout state = CHECKOUT_INIT;
|
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 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-02-06 02:51:15 +00:00
|
|
|
int nr_checkouts = 0, nr_unmerged = 0;
|
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");
|
|
|
|
|
|
|
|
if (opts->force && opts->patch_mode)
|
|
|
|
die(_("'%s' cannot be used with updating paths"), "-f");
|
|
|
|
|
|
|
|
if (opts->force_detach)
|
|
|
|
die(_("'%s' cannot be used with updating paths"), "--detach");
|
|
|
|
|
|
|
|
if (opts->merge && opts->patch_mode)
|
|
|
|
die(_("'%s' cannot be used with %s"), "--merge", "--patch");
|
|
|
|
|
|
|
|
if (opts->force && opts->merge)
|
|
|
|
die(_("'%s' cannot be used with %s"), "-f", "-m");
|
|
|
|
|
|
|
|
if (opts->new_branch)
|
|
|
|
die(_("Cannot update paths and switch to branch '%s' at the same time."),
|
|
|
|
opts->new_branch);
|
|
|
|
|
|
|
|
if (opts->patch_mode)
|
|
|
|
return run_add_interactive(revision, "--patch=checkout",
|
2013-07-14 08:35:50 +00:00
|
|
|
&opts->pathspec);
|
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);
|
2013-07-14 08:35:49 +00:00
|
|
|
if (read_cache_preload(&opts->pathspec) < 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);
|
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.
|
|
|
|
*/
|
2018-12-20 13:48:18 +00:00
|
|
|
for (pos = 0; pos < active_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)
|
|
|
|
mark_ce_for_checkout_overlay(active_cache[pos],
|
|
|
|
ps_matched,
|
|
|
|
opts);
|
|
|
|
else
|
|
|
|
mark_ce_for_checkout_no_overlay(active_cache[pos],
|
|
|
|
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);
|
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
|
|
|
|
2009-12-25 19:57:11 +00:00
|
|
|
/* "checkout -m path" to recreate conflicted state */
|
|
|
|
if (opts->merge)
|
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
|
|
|
unmerge_marked_index(&the_index);
|
2009-12-25 19:57:11 +00:00
|
|
|
|
2008-08-29 20:40:36 +00:00
|
|
|
/* Any unmerged paths? */
|
|
|
|
for (pos = 0; pos < active_nr; pos++) {
|
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
|
|
|
const struct cache_entry *ce = active_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;
|
2008-08-30 14:46:55 +00:00
|
|
|
if (opts->force) {
|
2011-02-22 23:41:39 +00:00
|
|
|
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 */
|
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
|
|
|
state.force = 1;
|
|
|
|
state.refresh_cache = 1;
|
2014-06-13 12:19:34 +00:00
|
|
|
state.istate = &the_index;
|
2017-06-30 20:41:28 +00:00
|
|
|
|
|
|
|
enable_delayed_checkout(&state);
|
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
|
|
|
for (pos = 0; pos < active_nr; pos++) {
|
|
|
|
struct cache_entry *ce = active_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)) {
|
2018-11-13 18:28:00 +00:00
|
|
|
errs |= checkout_entry(ce, &state,
|
|
|
|
NULL, &nr_checkouts);
|
2008-08-29 20:40:36 +00:00
|
|
|
continue;
|
|
|
|
}
|
2013-08-03 11:51:21 +00:00
|
|
|
if (opts->writeout_stage)
|
2018-11-13 18:28:00 +00:00
|
|
|
errs |= checkout_stage(opts->writeout_stage,
|
|
|
|
ce, pos,
|
2019-03-07 00:59:51 +00:00
|
|
|
&state,
|
|
|
|
&nr_checkouts, opts->overlay_mode);
|
2013-08-03 11:51:21 +00:00
|
|
|
else if (opts->merge)
|
2018-11-13 18:28:00 +00:00
|
|
|
errs |= checkout_merged(pos, &state,
|
2019-02-06 02:51:15 +00:00
|
|
|
&nr_unmerged);
|
2008-08-29 20:40:36 +00:00
|
|
|
pos = skip_same_name(ce, pos) - 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: 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
|
|
|
remove_marked_cache_entries(&the_index, 1);
|
|
|
|
remove_scheduled_dirs();
|
2018-11-13 18:28:00 +00:00
|
|
|
errs |= finish_delayed_checkout(&state, &nr_checkouts);
|
|
|
|
|
|
|
|
if (opts->count_checkout_paths) {
|
2019-02-06 02:51:15 +00:00
|
|
|
if (nr_unmerged)
|
|
|
|
fprintf_ln(stderr, Q_("Recreated %d merge conflict",
|
|
|
|
"Recreated %d merge conflicts",
|
|
|
|
nr_unmerged),
|
|
|
|
nr_unmerged);
|
2018-11-13 18:28:00 +00:00
|
|
|
if (opts->source_tree)
|
2019-02-06 02:51:14 +00:00
|
|
|
fprintf_ln(stderr, Q_("Updated %d path from %s",
|
|
|
|
"Updated %d paths from %s",
|
2018-11-13 18:28:00 +00:00
|
|
|
nr_checkouts),
|
|
|
|
nr_checkouts,
|
|
|
|
find_unique_abbrev(&opts->source_tree->object.oid,
|
|
|
|
DEFAULT_ABBREV));
|
2019-02-06 02:51:15 +00:00
|
|
|
else if (!nr_unmerged || nr_checkouts)
|
2019-02-06 02:51:14 +00:00
|
|
|
fprintf_ln(stderr, Q_("Updated %d path from the index",
|
|
|
|
"Updated %d paths from the index",
|
2018-11-13 18:28:00 +00:00
|
|
|
nr_checkouts),
|
|
|
|
nr_checkouts);
|
|
|
|
}
|
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-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"));
|
2008-02-28 21:52:44 +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;
|
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);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
2013-10-24 08:54:53 +00:00
|
|
|
if (!parse_commit(commit))
|
|
|
|
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,
|
2018-03-12 02:27:30 +00:00
|
|
|
find_unique_abbrev(&commit->object.oid, DEFAULT_ABBREV), sb.buf);
|
2017-12-06 00:20:42 +00:00
|
|
|
} else {
|
|
|
|
fprintf(stderr, "%s %s %s\n", msg,
|
2018-03-12 02:27:30 +00:00
|
|
|
find_unique_abbrev(&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,
|
|
|
|
int worktree, 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
|
|
|
{
|
|
|
|
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;
|
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.reset = 1;
|
|
|
|
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;
|
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
|
|
|
parse_tree(tree);
|
|
|
|
init_tree_desc(&tree_desc, 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
|
|
|
}
|
|
|
|
|
|
|
|
struct branch_info {
|
|
|
|
const char *name; /* The short name used */
|
|
|
|
const char *path; /* The full name of a real branch */
|
|
|
|
struct commit *commit; /* The named commit */
|
2014-11-30 08:24:49 +00:00
|
|
|
/*
|
|
|
|
* if not null the branch is detached because it's already
|
|
|
|
* checked out in this checkout
|
|
|
|
*/
|
|
|
|
char *checkout;
|
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
|
|
|
|
2017-03-02 08:23:18 +00:00
|
|
|
strbuf_branchname(&buf, branch->name, INTERPRET_BRANCH_LOCAL);
|
2009-03-21 20:17:30 +00:00
|
|
|
if (strcmp(buf.buf, branch->name))
|
2009-01-17 16:09:53 +00:00
|
|
|
branch->name = xstrdup(buf.buf);
|
2009-03-21 20:17:30 +00:00
|
|
|
strbuf_splice(&buf, 0, 0, "refs/heads/", 11);
|
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);
|
|
|
|
}
|
|
|
|
|
2018-08-16 18:27:11 +00:00
|
|
|
/*
|
|
|
|
* Skip merging the trees, updating the index and working directory if and
|
|
|
|
* only if we are creating a new branch via "git checkout -b <new_branch>."
|
|
|
|
*/
|
|
|
|
static int skip_merge_working_tree(const struct checkout_opts *opts,
|
|
|
|
const struct branch_info *old_branch_info,
|
|
|
|
const struct branch_info *new_branch_info)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Do the merge if sparse checkout is on and the user has not opted in
|
|
|
|
* to the optimized behavior
|
|
|
|
*/
|
|
|
|
if (core_apply_sparse_checkout && !checkout_optimize_new_branch)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We must do the merge if we are actually moving to a new commit.
|
|
|
|
*/
|
|
|
|
if (!old_branch_info->commit || !new_branch_info->commit ||
|
2018-10-02 21:19:21 +00:00
|
|
|
!oideq(&old_branch_info->commit->object.oid,
|
|
|
|
&new_branch_info->commit->object.oid))
|
2018-08-16 18:27:11 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* opts->patch_mode cannot be used with switching branches so is
|
|
|
|
* not tested here
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* opts->quiet only impacts output so doesn't require a merge
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Honor the explicit request for a three-way merge or to throw away
|
|
|
|
* local changes
|
|
|
|
*/
|
|
|
|
if (opts->merge || opts->force)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* --detach is documented as "updating the index and the files in the
|
|
|
|
* working tree" but this optimization skips those steps so fall through
|
|
|
|
* to the regular code path.
|
|
|
|
*/
|
|
|
|
if (opts->force_detach)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* opts->writeout_stage cannot be used with switching branches so is
|
|
|
|
* not tested here
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Honor the explicit ignore requests
|
|
|
|
*/
|
|
|
|
if (!opts->overwrite_ignore || opts->ignore_skipworktree ||
|
|
|
|
opts->ignore_other_worktrees)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* opts->show_progress only impacts output so doesn't require a merge
|
|
|
|
*/
|
|
|
|
|
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
|
|
|
/*
|
|
|
|
* opts->overlay_mode cannot be used with switching branches so is
|
|
|
|
* not tested here
|
|
|
|
*/
|
|
|
|
|
2018-08-16 18:27:11 +00:00
|
|
|
/*
|
|
|
|
* If we aren't creating a new branch any changes or updates will
|
|
|
|
* happen in the existing branch. Since that could only be updating
|
|
|
|
* the index and working directory, we don't want to skip those steps
|
|
|
|
* or we've defeated any purpose in running the command.
|
|
|
|
*/
|
|
|
|
if (!opts->new_branch)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* new_branch_force is defined to "create/reset and checkout a branch"
|
|
|
|
* so needs to go through the merge to do the reset
|
|
|
|
*/
|
|
|
|
if (opts->new_branch_force)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* A new orphaned branch requrires the index and the working tree to be
|
|
|
|
* adjusted to <start_point>
|
|
|
|
*/
|
|
|
|
if (opts->new_orphan_branch)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Remaining variables are not checkout options but used to track state
|
|
|
|
*/
|
|
|
|
|
2019-01-23 20:02:01 +00:00
|
|
|
/*
|
|
|
|
* Do the merge if this is the initial checkout. We cannot use
|
|
|
|
* is_cache_unborn() here because the index hasn't been loaded yet
|
|
|
|
* so cache_nr and timestamp.sec are always zero.
|
|
|
|
*/
|
|
|
|
if (!file_exists(get_index_file()))
|
|
|
|
return 0;
|
|
|
|
|
2018-08-16 18:27:11 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
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;
|
2008-12-06 01:54:10 +00:00
|
|
|
|
2017-10-05 20:32:04 +00:00
|
|
|
hold_locked_index(&lock_file, LOCK_DIE_ON_ERROR);
|
2009-05-09 22:11:17 +00:00
|
|
|
if (read_cache_preload(NULL) < 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
|
|
|
|
2009-12-25 08:30:51 +00:00
|
|
|
resolve_undo_clear();
|
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->force) {
|
2018-04-06 19:09:38 +00:00
|
|
|
ret = reset_tree(get_commit_tree(new_branch_info->commit),
|
|
|
|
opts, 1, 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
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
} else {
|
|
|
|
struct tree_desc trees[2];
|
|
|
|
struct tree *tree;
|
|
|
|
struct unpack_trees_options topts;
|
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(&topts, 0, sizeof(topts));
|
|
|
|
topts.head_idx = -1;
|
2008-03-07 02:12:28 +00:00
|
|
|
topts.src_index = &the_index;
|
|
|
|
topts.dst_index = &the_index;
|
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
|
|
|
|
2010-09-02 11:57:34 +00:00
|
|
|
setup_unpack_trees_porcelain(&topts, "checkout");
|
2008-05-17 19:03:49 +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
|
|
|
refresh_cache(REFRESH_QUIET);
|
|
|
|
|
|
|
|
if (unmerged_cache()) {
|
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: Fix "initial checkout" detection
Earlier commit 5521883 (checkout: do not lose staged removal, 2008-09-07)
tightened the rule to prevent switching branches from losing local
changes, so that staged removal of paths can be protected, while
attempting to keep a loophole to still allow a special case of switching
out of an un-checked-out state.
However, the loophole was made a bit too tight, and did not allow
switching from one branch (in an un-checked-out state) to check out
another branch.
The change to builtin-checkout.c in this commit loosens it to allow this,
by not insisting the original commit and the new commit to be the same.
It also introduces a new function, is_index_unborn (and an associated
macro, is_cache_unborn), to check if the repository is truly in an
un-checked-out state more reliably, by making sure that $GIT_INDEX_FILE
did not exist when populating the in-core index structure. A few places
the earlier commit 5521883 added the check for the initial checkout
condition are updated to use this function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-12 19:52:35 +00:00
|
|
|
topts.initial_checkout = is_cache_unborn();
|
2008-02-23 23:45:19 +00:00
|
|
|
topts.update = 1;
|
|
|
|
topts.merge = 1;
|
2019-03-22 09:31:36 +00:00
|
|
|
topts.quiet = opts->merge && old_branch_info->commit;
|
2015-11-01 21:19:05 +00:00
|
|
|
topts.verbose_update = opts->show_progress;
|
2008-02-23 23:45:19 +00:00
|
|
|
topts.fn = twoway_merge;
|
2011-11-27 10:15:33 +00:00
|
|
|
if (opts->overwrite_ignore) {
|
|
|
|
topts.dir = xcalloc(1, sizeof(*topts.dir));
|
|
|
|
topts.dir->flags |= DIR_SHOW_IGNORED;
|
|
|
|
setup_standard_excludes(topts.dir);
|
|
|
|
}
|
2018-02-14 18:59:31 +00:00
|
|
|
tree = parse_tree_indirect(old_branch_info->commit ?
|
|
|
|
&old_branch_info->commit->object.oid :
|
2017-11-12 21:28:54 +00:00
|
|
|
the_hash_algo->empty_tree);
|
2008-02-23 23:45:19 +00:00
|
|
|
init_tree_desc(&trees[0], tree->buffer, tree->size);
|
2018-02-14 18:59:31 +00:00
|
|
|
tree = parse_tree_indirect(&new_branch_info->commit->object.oid);
|
2008-02-23 23:45:19 +00:00
|
|
|
init_tree_desc(&trees[1], tree->buffer, tree->size);
|
|
|
|
|
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 *result;
|
|
|
|
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;
|
|
|
|
|
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;
|
2019-03-22 09:31:38 +00:00
|
|
|
old_tree = get_commit_tree(old_branch_info->commit);
|
|
|
|
|
|
|
|
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
|
|
|
|
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
|
|
|
if (repo_index_has_changes(the_repository,
|
|
|
|
get_commit_tree(old_branch_info->commit),
|
|
|
|
&sb))
|
|
|
|
warning(_("staged changes in the following files may be lost: %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.
|
|
|
|
*/
|
|
|
|
|
2016-09-14 21:07:47 +00:00
|
|
|
add_files_to_cache(NULL, NULL, 0);
|
2010-08-05 11:32:41 +00:00
|
|
|
/*
|
|
|
|
* NEEDSWORK: carrying over local changes
|
|
|
|
* when branches have different end-of-line
|
|
|
|
* normalization (or clean+smudge rules) is
|
|
|
|
* a pain; plumb in an option to set
|
|
|
|
* o.renormalize?
|
|
|
|
*/
|
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;
|
|
|
|
work = write_tree_from_memory(&o);
|
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-04-06 19:09:38 +00:00
|
|
|
ret = reset_tree(get_commit_tree(new_branch_info->commit),
|
|
|
|
opts, 1,
|
2012-08-29 13:55:22 +00:00
|
|
|
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
|
|
|
if (ret)
|
|
|
|
return ret;
|
2018-02-14 18:59:31 +00:00
|
|
|
o.ancestor = old_branch_info->name;
|
|
|
|
o.branch1 = new_branch_info->name;
|
2008-08-25 14:25:57 +00:00
|
|
|
o.branch2 = "local";
|
2018-04-06 19:09:38 +00:00
|
|
|
ret = merge_trees(&o,
|
|
|
|
get_commit_tree(new_branch_info->commit),
|
|
|
|
work,
|
2019-03-22 09:31:38 +00:00
|
|
|
old_tree,
|
2018-04-06 19:09:38 +00:00
|
|
|
&result);
|
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);
|
2018-04-06 19:09:38 +00:00
|
|
|
ret = reset_tree(get_commit_tree(new_branch_info->commit),
|
|
|
|
opts, 0,
|
2012-08-29 13:55:22 +00:00
|
|
|
writeout_error);
|
2016-08-01 11:44:53 +00:00
|
|
|
strbuf_release(&o.obuf);
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-07-06 04:06:56 +00:00
|
|
|
if (!active_cache_tree)
|
|
|
|
active_cache_tree = cache_tree();
|
|
|
|
|
|
|
|
if (!cache_tree_fully_valid(active_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
|
|
|
|
2008-09-25 08:35:38 +00:00
|
|
|
if (!opts->force && !opts->quiet)
|
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
|
|
|
|
2018-01-09 18:50:18 +00:00
|
|
|
if (!format_tracking_info(branch, &sb, AHEAD_BEHIND_FULL))
|
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
|
|
|
|
2015-07-21 21:04:52 +00:00
|
|
|
ret = safe_create_reflog(refname, 1, &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,
|
2011-11-26 08:54:55 +00:00
|
|
|
opts->track);
|
2018-02-14 18:59:31 +00:00
|
|
|
new_branch_info->name = opts->new_branch;
|
|
|
|
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
|
|
|
|
strbuf_insert(&msg, 0, reflog_msg, strlen(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 &&
|
2016-08-15 18:40:21 +00:00
|
|
|
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
|
|
|
}
|
2018-11-10 05:49:00 +00:00
|
|
|
remove_branch_state(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
|
|
|
strbuf_release(&msg);
|
2011-02-08 10:32:49 +00:00
|
|
|
if (!opts->quiet &&
|
2018-02-14 18:59:31 +00:00
|
|
|
(new_branch_info->path || (!opts->force_detach && !strcmp(new_branch_info->name, "HEAD"))))
|
|
|
|
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,
|
2011-10-01 15:51:39 +00:00
|
|
|
int flags, 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, ' ');
|
2013-10-24 08:54:53 +00:00
|
|
|
if (!parse_commit(commit))
|
|
|
|
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
|
|
|
|
|
|
|
if (advice_detached_head)
|
|
|
|
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),
|
2018-03-12 02:27:30 +00:00
|
|
|
find_unique_abbrev(&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);
|
2018-02-14 18:59:31 +00:00
|
|
|
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. */
|
2017-12-25 17:47:04 +00:00
|
|
|
clear_commit_marks_all(ALL_REV_FLAGS);
|
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;
|
2018-02-14 18:59:31 +00:00
|
|
|
struct branch_info old_branch_info;
|
2011-12-13 14:17:48 +00:00
|
|
|
void *path_to_free;
|
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-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));
|
|
|
|
old_branch_info.path = path_to_free = resolve_refdup("HEAD", 0, &rev, &flag);
|
|
|
|
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))
|
2018-02-14 18:59:31 +00:00
|
|
|
old_branch_info.path = 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
|
|
|
|
2018-02-14 18:59:31 +00:00
|
|
|
if (old_branch_info.path)
|
|
|
|
skip_prefix(old_branch_info.path, "refs/heads/", &old_branch_info.name);
|
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 (!new_branch_info->name) {
|
|
|
|
new_branch_info->name = "HEAD";
|
|
|
|
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);
|
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-08-16 18:27:11 +00:00
|
|
|
/* optimize the "checkout -b <new_branch> path */
|
|
|
|
if (skip_merge_working_tree(opts, &old_branch_info, new_branch_info)) {
|
|
|
|
if (!checkout_optimize_new_branch && !opts->quiet) {
|
|
|
|
if (read_cache_preload(NULL) < 0)
|
|
|
|
return error(_("index file corrupt"));
|
|
|
|
show_local_changes(&new_branch_info->commit->object, &opts->diff_options);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
ret = merge_working_tree(opts, &old_branch_info, new_branch_info, &writeout_error);
|
|
|
|
if (ret) {
|
|
|
|
free(path_to_free);
|
|
|
|
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);
|
2011-12-13 14:17:48 +00:00
|
|
|
free(path_to_free);
|
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
|
|
|
}
|
|
|
|
|
2008-08-30 14:52:24 +00:00
|
|
|
static int git_checkout_config(const char *var, const char *value, void *cb)
|
|
|
|
{
|
2018-08-16 18:27:11 +00:00
|
|
|
if (!strcmp(var, "checkout.optimizenewbranch")) {
|
|
|
|
checkout_optimize_new_branch = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-08-25 10:34:57 +00:00
|
|
|
if (!strcmp(var, "diff.ignoresubmodules")) {
|
|
|
|
struct checkout_opts *opts = cb;
|
|
|
|
handle_ignore_submodules_arg(&opts->diff_options, 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
|
|
|
|
2010-08-25 10:34:57 +00:00
|
|
|
return git_xmerge_config(var, value, NULL);
|
2008-08-30 14:52:24 +00:00
|
|
|
}
|
|
|
|
|
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,
|
2018-06-05 14:40:46 +00:00
|
|
|
struct object_id *rev,
|
|
|
|
int *dwim_remotes_matched)
|
2011-02-08 10:29:09 +00:00
|
|
|
{
|
2015-01-03 09:41:25 +00:00
|
|
|
struct tree **source_tree = &opts->source_tree;
|
|
|
|
const char **new_branch = &opts->new_branch;
|
2011-02-08 10:29:09 +00:00
|
|
|
int argcount = 0;
|
2016-09-05 20:08:00 +00:00
|
|
|
struct object_id branch_rev;
|
2011-02-08 10:29:09 +00:00
|
|
|
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
|
2014-03-31 22:11:46 +00:00
|
|
|
* or <something> is not a path, no -t or -b was given, and
|
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;
|
|
|
|
|
|
|
|
arg = argv[0];
|
2013-10-18 09:25:58 +00:00
|
|
|
dash_dash_pos = -1;
|
|
|
|
for (i = 0; i < argc; i++) {
|
|
|
|
if (!strcmp(argv[i], "--")) {
|
|
|
|
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}";
|
|
|
|
|
2016-09-05 20:08:07 +00:00
|
|
|
if (get_oid_mb(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
|
|
|
/*
|
|
|
|
* Accept "git checkout foo" and "git checkout foo --"
|
|
|
|
* as candidates for dwim.
|
|
|
|
*/
|
|
|
|
if (!(argc == 1 && !has_dash_dash) &&
|
|
|
|
!(argc == 2 && has_dash_dash))
|
|
|
|
recover_with_dwim = 0;
|
|
|
|
|
|
|
|
if (recover_with_dwim) {
|
2018-06-05 14:40:46 +00:00
|
|
|
const char *remote = unique_tracking_name(arg, rev,
|
|
|
|
dwim_remotes_matched);
|
2013-10-18 09:25:57 +00:00
|
|
|
if (remote) {
|
2018-11-13 17:52:26 +00:00
|
|
|
if (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);
|
2013-10-18 09:25:57 +00:00
|
|
|
*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--;
|
|
|
|
|
2018-02-14 18:59:31 +00:00
|
|
|
new_branch_info->name = arg;
|
|
|
|
setup_branch_path(new_branch_info);
|
2011-02-08 10:29:09 +00:00
|
|
|
|
2018-02-14 18:59:31 +00:00
|
|
|
if (!check_refname_format(new_branch_info->path, 0) &&
|
|
|
|
!read_ref(new_branch_info->path, &branch_rev))
|
2016-09-05 20:08:00 +00:00
|
|
|
oidcpy(rev, &branch_rev);
|
2011-02-08 10:29:09 +00:00
|
|
|
else
|
2018-02-14 18:59:31 +00:00
|
|
|
new_branch_info->path = NULL; /* not an existing branch */
|
2011-02-08 10:29:09 +00:00
|
|
|
|
2018-06-29 01:21:57 +00:00
|
|
|
new_branch_info->commit = lookup_commit_reference_gently(the_repository, rev, 1);
|
2018-02-14 18:59:31 +00:00
|
|
|
if (!new_branch_info->commit) {
|
2011-02-08 10:29:09 +00:00
|
|
|
/* not a commit */
|
2017-05-06 22:10:37 +00:00
|
|
|
*source_tree = parse_tree_indirect(rev);
|
2011-02-08 10:29:09 +00:00
|
|
|
} else {
|
2018-02-14 18:59:31 +00:00
|
|
|
parse_commit_or_die(new_branch_info->commit);
|
2018-04-06 19:09:38 +00:00
|
|
|
*source_tree = get_commit_tree(new_branch_info->commit);
|
2011-02-08 10:29:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!*source_tree) /* case (1): want a tree */
|
2011-04-02 00:55:55 +00:00
|
|
|
die(_("reference is not a tree: %s"), arg);
|
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);
|
2011-02-08 10:29:09 +00:00
|
|
|
} else {
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
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");
|
|
|
|
|
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)
|
|
|
|
die(_("'%s' cannot be used with switching branches"),
|
|
|
|
"--no-overlay");
|
|
|
|
|
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");
|
|
|
|
|
|
|
|
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");
|
|
|
|
} 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
|
|
|
|
2018-02-14 18:59:31 +00:00
|
|
|
if (new_branch_info->path && !opts->force_detach && !opts->new_branch &&
|
2015-07-17 22:59:56 +00:00
|
|
|
!opts->ignore_other_worktrees) {
|
2015-06-12 10:49:24 +00:00
|
|
|
int flag;
|
2017-10-01 07:29:03 +00:00
|
|
|
char *head_ref = resolve_refdup("HEAD", 0, NULL, &flag);
|
2015-06-12 10:49:24 +00:00
|
|
|
if (head_ref &&
|
2018-02-14 18:59:31 +00:00
|
|
|
(!(flag & REF_ISSYMREF) || strcmp(head_ref, new_branch_info->path)))
|
|
|
|
die_if_checked_out(new_branch_info->path, 1);
|
2015-06-12 10:49:24 +00:00
|
|
|
free(head_ref);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
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 cmd_checkout(int argc, const char **argv, const char *prefix)
|
|
|
|
{
|
|
|
|
struct checkout_opts opts;
|
2018-02-14 18:59:31 +00:00
|
|
|
struct branch_info new_branch_info;
|
2008-09-01 02:32:40 +00:00
|
|
|
char *conflict_style = NULL;
|
2018-11-13 17:52:26 +00:00
|
|
|
int dwim_new_local_branch, no_dwim_new_local_branch = 0;
|
2018-06-05 14:40:46 +00:00
|
|
|
int dwim_remotes_matched = 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
|
|
|
struct option options[] = {
|
2012-08-20 12:31:59 +00:00
|
|
|
OPT__QUIET(&opts.quiet, N_("suppress progress reporting")),
|
|
|
|
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")),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL('l', NULL, &opts.new_branch_log, N_("create reflog for new branch")),
|
2016-06-17 20:21:20 +00:00
|
|
|
OPT_BOOL(0, "detach", &opts.force_detach, N_("detach HEAD at named commit")),
|
2012-08-20 12:31:59 +00:00
|
|
|
OPT_SET_INT('t', "track", &opts.track, N_("set upstream info for new branch"),
|
2008-02-19 16:24:37 +00:00
|
|
|
BRANCH_TRACK_EXPLICIT),
|
2014-03-23 22:58:12 +00:00
|
|
|
OPT_STRING(0, "orphan", &opts.new_orphan_branch, N_("new-branch"), N_("new unparented branch")),
|
2018-05-27 08:38:27 +00:00
|
|
|
OPT_SET_INT_F('2', "ours", &opts.writeout_stage,
|
|
|
|
N_("checkout our version for unmerged files"),
|
|
|
|
2, PARSE_OPT_NONEG),
|
|
|
|
OPT_SET_INT_F('3', "theirs", &opts.writeout_stage,
|
|
|
|
N_("checkout their version for unmerged files"),
|
|
|
|
3, PARSE_OPT_NONEG),
|
2018-02-09 11:01:48 +00:00
|
|
|
OPT__FORCE(&opts.force, N_("force checkout (throw away local modifications)"),
|
|
|
|
PARSE_OPT_NOCOMPLETE),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL('m', "merge", &opts.merge, N_("perform a 3-way merge with the new branch")),
|
2018-02-09 11:01:48 +00:00
|
|
|
OPT_BOOL_F(0, "overwrite-ignore", &opts.overwrite_ignore,
|
|
|
|
N_("update ignored files (default)"),
|
|
|
|
PARSE_OPT_NOCOMPLETE),
|
2012-08-20 12:31:59 +00:00
|
|
|
OPT_STRING(0, "conflict", &conflict_style, N_("style"),
|
|
|
|
N_("conflict style (merge or diff3)")),
|
2013-08-03 11:51:19 +00:00
|
|
|
OPT_BOOL('p', "patch", &opts.patch_mode, N_("select hunks interactively")),
|
2013-04-12 23:12:08 +00:00
|
|
|
OPT_BOOL(0, "ignore-skip-worktree-bits", &opts.ignore_skipworktree,
|
|
|
|
N_("do not limit pathspecs to sparse entries only")),
|
2018-11-13 17:52:26 +00:00
|
|
|
OPT_BOOL(0, "no-guess", &no_dwim_new_local_branch,
|
|
|
|
N_("do not second guess 'git checkout <no-such-branch>'")),
|
2015-01-03 09:41:26 +00:00
|
|
|
OPT_BOOL(0, "ignore-other-worktrees", &opts.ignore_other_worktrees,
|
|
|
|
N_("do not check if another worktree is holding the given ref")),
|
2017-05-26 19:10:10 +00:00
|
|
|
{ OPTION_CALLBACK, 0, "recurse-submodules", NULL,
|
2017-03-14 21:46:41 +00:00
|
|
|
"checkout", "control recursive updating of submodules",
|
2017-05-26 19:10:12 +00:00
|
|
|
PARSE_OPT_OPTARG, option_parse_recurse_submodules_worktree_updater },
|
2015-11-01 21:19:05 +00:00
|
|
|
OPT_BOOL(0, "progress", &opts.show_progress, N_("force progress reporting")),
|
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
|
|
|
OPT_BOOL(0, "overlay", &opts.overlay_mode, N_("use overlay mode (default)")),
|
2008-02-18 10:20:20 +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
|
|
|
};
|
|
|
|
|
|
|
|
memset(&opts, 0, sizeof(opts));
|
2018-02-14 18:59:31 +00:00
|
|
|
memset(&new_branch_info, 0, sizeof(new_branch_info));
|
2011-11-27 10:15:33 +00:00
|
|
|
opts.overwrite_ignore = 1;
|
2012-08-29 13:55:23 +00:00
|
|
|
opts.prefix = prefix;
|
2015-11-01 21:19:05 +00:00
|
|
|
opts.show_progress = -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
|
|
|
opts.overlay_mode = -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
|
|
|
|
2010-08-25 10:34:57 +00:00
|
|
|
git_config(git_checkout_config, &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
|
|
|
|
2008-08-21 17:23:20 +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
|
|
|
|
2009-05-23 18:53:12 +00:00
|
|
|
argc = parse_options(argc, argv, prefix, options, checkout_usage,
|
2008-07-23 10:15:32 +00:00
|
|
|
PARSE_OPT_KEEP_DASHDASH);
|
2008-07-23 10:15:33 +00:00
|
|
|
|
2018-11-13 17:52:26 +00:00
|
|
|
dwim_new_local_branch = !no_dwim_new_local_branch;
|
2015-11-01 21:19:05 +00:00
|
|
|
if (opts.show_progress < 0) {
|
|
|
|
if (opts.quiet)
|
|
|
|
opts.show_progress = 0;
|
|
|
|
else
|
|
|
|
opts.show_progress = isatty(2);
|
|
|
|
}
|
|
|
|
|
2012-08-30 12:45:50 +00:00
|
|
|
if (conflict_style) {
|
|
|
|
opts.merge = 1; /* implied */
|
|
|
|
git_xmerge_config("merge.conflictstyle", conflict_style, NULL);
|
|
|
|
}
|
2010-06-23 19:29:00 +00:00
|
|
|
|
2012-08-30 12:45:50 +00:00
|
|
|
if ((!!opts.new_branch + !!opts.new_branch_force + !!opts.new_orphan_branch) > 1)
|
|
|
|
die(_("-b, -B and --orphan are mutually exclusive"));
|
2010-06-23 19:29:00 +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
|
|
|
if (opts.overlay_mode == 1 && opts.patch_mode)
|
|
|
|
die(_("-p and --overlay are mutually exclusive"));
|
|
|
|
|
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
|
|
|
|
* -b/-B/--orphan is being used.
|
|
|
|
*/
|
2010-06-23 19:29:00 +00:00
|
|
|
if (opts.new_branch_force)
|
|
|
|
opts.new_branch = opts.new_branch_force;
|
|
|
|
|
2012-08-30 12:45:50 +00:00
|
|
|
if (opts.new_orphan_branch)
|
|
|
|
opts.new_branch = opts.new_orphan_branch;
|
2011-02-08 10:32:49 +00:00
|
|
|
|
2012-08-30 12:45:50 +00:00
|
|
|
/* --track without -b/-B/--orphan should DWIM */
|
|
|
|
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])
|
2018-07-21 07:49:19 +00:00
|
|
|
die(_("missing branch name; try -b"));
|
2008-08-21 17:23:20 +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
|
|
|
*/
|
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) {
|
2016-09-05 20:08:00 +00:00
|
|
|
struct object_id rev;
|
2011-02-08 10:29:09 +00:00
|
|
|
int dwim_ok =
|
2012-08-29 13:55:23 +00:00
|
|
|
!opts.patch_mode &&
|
2011-02-08 10:29:09 +00:00
|
|
|
dwim_new_local_branch &&
|
|
|
|
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,
|
2018-06-05 14:40:46 +00:00
|
|
|
&new_branch_info, &opts, &rev,
|
|
|
|
&dwim_remotes_matched);
|
2011-02-08 10:29:09 +00:00
|
|
|
argv += n;
|
|
|
|
argc -= n;
|
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) {
|
2013-07-14 08:35:50 +00:00
|
|
|
parse_pathspec(&opts.pathspec, 0,
|
|
|
|
opts.patch_mode ? PATHSPEC_PREFIX_ORIGIN : 0,
|
|
|
|
prefix, argv);
|
2008-02-28 16:30:47 +00:00
|
|
|
|
2013-07-14 08:35:41 +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.
|
|
|
|
*/
|
|
|
|
if (opts.new_branch && argc == 1)
|
2017-05-11 12:06:32 +00:00
|
|
|
die(_("'%s' is not a commit and a branch '%s' cannot be created from it"),
|
|
|
|
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
|
|
|
|
2011-02-08 10:32:49 +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]);
|
2011-02-08 10:32:49 +00:00
|
|
|
|
2008-08-30 14:52:24 +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."));
|
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-09-21 18:36:06 +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
|
|
|
|
2017-10-13 04:45:40 +00:00
|
|
|
if (opts.new_branch_force)
|
|
|
|
opts.branch_exists = validate_branchname(opts.new_branch, &buf);
|
|
|
|
else
|
|
|
|
opts.branch_exists =
|
|
|
|
validate_new_branchname(opts.new_branch, &buf, 0);
|
2008-09-21 18:36:06 +00:00
|
|
|
strbuf_release(&buf);
|
|
|
|
}
|
|
|
|
|
2017-10-01 17:42:08 +00:00
|
|
|
UNLEAK(opts);
|
2018-06-05 14:40:47 +00:00
|
|
|
if (opts.patch_mode || opts.pathspec.nr) {
|
|
|
|
int ret = checkout_paths(&opts, new_branch_info.name);
|
checkout: add advice for ambiguous "checkout <branch>"
As the "checkout" documentation describes:
If <branch> is not found but there does exist a tracking branch in
exactly one remote (call it <remote>) with a matching name, treat
as equivalent to [...] <remote>/<branch.
This is a really useful feature. The problem is that when you add
another remote (e.g. a fork), git won't find a unique branch name
anymore, and will instead print this unhelpful message:
$ git checkout master
error: pathspec 'master' did not match any file(s) known to git
Now it will, on my git.git checkout, print:
$ ./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>
Note that the "error: pathspec[...]" message is still printed. This is
because whatever else checkout may have tried earlier, its final
fallback is to try to resolve the argument as a path. E.g. in this
case:
$ ./git --exec-path=$PWD checkout master pu
error: pathspec 'master' did not match any file(s) known to git.
error: pathspec 'pu' did not match any file(s) known to git.
There we don't print the "hint:" implicitly due to earlier logic
around the DWIM fallback. That fallback is only used if it looks like
we have one argument that might be a branch.
I can't think of an intrinsic reason for why we couldn't in some
future change skip printing the "error: pathspec[...]" error. However,
to do so we'd need to pass something down to checkout_paths() to make
it suppress printing an error on its own, and for us to be confident
that we're not silencing cases where those errors are meaningful.
I don't think that's worth it since determining whether that's the
case could easily change due to future changes in the checkout logic.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:48 +00:00
|
|
|
if (ret && dwim_remotes_matched > 1 &&
|
|
|
|
advice_checkout_ambiguous_remote_branch_name)
|
|
|
|
advise(_("'%s' matched more than one remote tracking branch.\n"
|
|
|
|
"We found %d remotes with a reference that matched. So we fell back\n"
|
|
|
|
"on trying to resolve the argument as a path, but failed there too!\n"
|
|
|
|
"\n"
|
|
|
|
"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"
|
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
|
|
|
" 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."),
|
checkout: add advice for ambiguous "checkout <branch>"
As the "checkout" documentation describes:
If <branch> is not found but there does exist a tracking branch in
exactly one remote (call it <remote>) with a matching name, treat
as equivalent to [...] <remote>/<branch.
This is a really useful feature. The problem is that when you add
another remote (e.g. a fork), git won't find a unique branch name
anymore, and will instead print this unhelpful message:
$ git checkout master
error: pathspec 'master' did not match any file(s) known to git
Now it will, on my git.git checkout, print:
$ ./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>
Note that the "error: pathspec[...]" message is still printed. This is
because whatever else checkout may have tried earlier, its final
fallback is to try to resolve the argument as a path. E.g. in this
case:
$ ./git --exec-path=$PWD checkout master pu
error: pathspec 'master' did not match any file(s) known to git.
error: pathspec 'pu' did not match any file(s) known to git.
There we don't print the "hint:" implicitly due to earlier logic
around the DWIM fallback. That fallback is only used if it looks like
we have one argument that might be a branch.
I can't think of an intrinsic reason for why we couldn't in some
future change skip printing the "error: pathspec[...]" error. However,
to do so we'd need to pass something down to checkout_paths() to make
it suppress printing an error on its own, and for us to be confident
that we're not silencing cases where those errors are meaningful.
I don't think that's worth it since determining whether that's the
case could easily change due to future changes in the checkout logic.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-05 14:40:48 +00:00
|
|
|
argv[0],
|
|
|
|
dwim_remotes_matched);
|
2018-06-05 14:40:47 +00:00
|
|
|
return ret;
|
|
|
|
} else {
|
2018-02-14 18:59:31 +00:00
|
|
|
return checkout_branch(&opts, &new_branch_info);
|
2018-06-05 14:40:47 +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
|
|
|
}
|