summaryrefslogtreecommitdiff
path: root/builtin/checkout.c
AgeCommit message (Collapse)AuthorFilesLines
2020-11-11Merge branch 'rs/clear-commit-marks-in-repo'Libravatar Junio C Hamano1-1/+1
Code clean-up. * rs/clear-commit-marks-in-repo: bisect: clear flags in passed repository object: allow clear_commit_marks_all to handle any repo
2020-10-31object: allow clear_commit_marks_all to handle any repoLibravatar René Scharfe1-1/+1
Allow callers to specify the repository to use. Rename the function to repo_clear_commit_marks to document its new scope. No functional change intended. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-27Merge branch 'dl/checkout-guess'Libravatar Junio C Hamano1-1/+6
"git checkout" learned to use checkout.guess configuration variable and enable/disable its "--[no-]guess" option accordingly. * dl/checkout-guess: checkout: learn to respect checkout.guess Documentation/config/checkout: replace sq with backticks
2020-10-27Merge branch 'dl/checkout-p-merge-base'Libravatar Junio C Hamano1-1/+14
"git checkout -p A...B [-- <path>]" did not work, even though the same command without "-p" correctly used the merge-base between commits A and B. * dl/checkout-p-merge-base: t2016: add a NEEDSWORK about the PERL prerequisite add-patch: add NEEDSWORK about comparing commits Doc: document "A...B" form for <tree-ish> in checkout and switch builtin/checkout: fix `git checkout -p HEAD...` bug
2020-10-08checkout: learn to respect checkout.guessLibravatar Denton Liu1-1/+6
The current behavior of git checkout/switch is that --guess is currently enabled by default. However, some users may not wish for this to happen automatically. Instead of forcing users to specify --no-guess manually each time, teach these commands the checkout.guess configuration variable that gives users the option to set a default behavior. Teach the completion script to recognize the new config variable and disable DWIM logic if it is set to false. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-07builtin/checkout: fix `git checkout -p HEAD...` bugLibravatar Denton Liu1-1/+14
Running `git checkout -p` with a merge-base rev results in an error: $ git checkout -p HEAD... usage: git diff-index [-m] [--cached] [<common-diff-options>] <tree-ish> [<path>...] common diff options: -z output diff-raw with lines terminated with NUL. -p output patch format. -u synonym for -p. --patch-with-raw output both a patch and the diff-raw format. --stat show diffstat instead of patch. --numstat show numeric diffstat instead of patch. --patch-with-stat output a patch and prepend its diffstat. --name-only show only names of changed files. --name-status show names and status of changed files. --full-index show full object name on index lines. --abbrev=<n> abbreviate object names in diff-tree header and diff-raw. -R swap input file pairs. -B detect complete rewrites. -M detect renames. -C detect copies. --find-copies-harder try unchanged files as candidate for copy detection. -l<n> limit rename attempts up to <n> paths. -O<file> reorder diffs according to the <file>. -S<string> find filepair whose only one side contains the string. --pickaxe-all show all files diff when -S is used and hit is found. -a --text treat all files as text. Cannot close git diff-index --cached --numstat --summary HEAD... -- () at <redacted>/libexec/git-core/git-add--interactive line 183. This happens because checkout passes the literal argument (in the example, `HEAD...`) to diff-index which does not recognise merge-base revs. Fix this by using the hex of the found commit instead of the given name. Note that "HEAD" is handled specially in run_add_interactive() so it's explicitly not changed. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-09Merge branch 'jt/interpret-branch-name-fallback'Libravatar Junio C Hamano1-2/+2
"git status" has trouble showing where it came from by interpreting reflog entries that recordcertain events, e.g. "checkout @{u}", and gives a hard/fatal error. Even though it inherently is impossible to give a correct answer because the reflog entries lose some information (e.g. "@{u}" does not record what branch the user was on hence which branch 'the upstream' needs to be computed, and even if the record were available, the relationship between branches may have changed), at least hide the error to allow "status" show its output. * jt/interpret-branch-name-fallback: wt-status: tolerate dangling marks refs: move dwim_ref() to header file sha1-name: replace unsigned int with option struct
2020-09-02wt-status: tolerate dangling marksLibravatar Jonathan Tan1-2/+2
When a user checks out the upstream branch of HEAD, the upstream branch not being a local branch, and then runs "git status", like this: git clone $URL client cd client git checkout @{u} git status no status is printed, but instead an error message: fatal: HEAD does not point to a branch (This error message when running "git branch" persists even after checking out other things - it only stops after checking out a branch.) This is because "git status" reads the reflog when determining the "HEAD detached" message, and thus attempts to DWIM "@{u}", but that doesn't work because HEAD no longer points to a branch. Therefore, when calculating the status of a worktree, tolerate dangling marks. This is done by adding an additional parameter to dwim_ref() and repo_dwim_ref(). Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-31Merge branch 'rs/checkout-no-overlay-pathspec-fix'Libravatar Junio C Hamano1-0/+2
"git restore/checkout --no-overlay" with wildcarded pathspec mistakenly removed matching paths in subdirectories, which has been corrected. * rs/checkout-no-overlay-pathspec-fix: checkout, restore: make pathspec recursive
2020-08-27Merge branch 'jk/leakfix'Libravatar Junio C Hamano1-1/+3
Code clean-up. * jk/leakfix: submodule--helper: fix leak of core.worktree value config: fix leak in git_config_get_expiry_in_days() config: drop git_config_get_string_const() config: fix leaks from git_config_get_string_const() checkout: fix leak of non-existent branch names submodule--helper: use strbuf_release() to free strbufs clear_pattern_list(): clear embedded hashmaps
2020-08-22checkout, restore: make pathspec recursiveLibravatar René Scharfe1-0/+2
The pathspec given to git checkout and git restore is used with both tree_entry_interesting (via read_tree_recursive) and match_pathspec (via ce_path_match). The latter effectively only supports recursive matching regardless of the value of the pathspec flag "recursive", which is unset here. That causes different match results for pathspecs with wildcards, and can lead checkout and restore in no-overlay mode to remove entries instead of modifying them. Enable recursive matching for both checkout and restore to make matching consistent. Setting the flag in checkout_main() technically also affects git switch, but since that command doesn't accept pathspecs at all this has no actual consequence. Reported-by: Sergii Shkarnikov <sergii.shkarnikov@globallogic.com> Initial-test-by: Sergii Shkarnikov <sergii.shkarnikov@globallogic.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-14checkout: fix leak of non-existent branch namesLibravatar Jeff King1-1/+3
We unconditionally write a branch name into a newly allocated buffer in new_branch_info->path, via setup_branch_path(). We then check to see if the branch exists; if not, we set that field to NULL, leaking the memory. We should take care to free() it when doing so. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-03checkout: support renormalization with checkout -m <paths>Libravatar Elijah Newren1-5/+6
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-03merge: make merge.renormalize work for all uses of merge machineryLibravatar Elijah Newren1-7/+0
The 'merge' command is not the only one that does merges; other commands like checkout -m or rebase do as well. Unfortunately, the only area of the code that checked for the "merge.renormalize" config setting was in builtin/merge.c, meaning it could only affect merges performed by the "merge" command. Move the handling of this config setting to merge_recursive_config() so that other commands can benefit from it as well. Fixes a few tests in t6038. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-08Merge branch 'bc/filter-process'Libravatar Junio C Hamano1-3/+1
Code simplification and test coverage enhancement. * bc/filter-process: t2060: add a test for switch with --orphan and --discard-changes builtin/checkout: simplify metadata initialization
2020-05-24checkout: improve error messages for -b with extra argumentLibravatar René Scharfe1-1/+1
When we try to create a branch "foo" based on "origin/master" and give git commit -b an extra unsupported argument "bar", it confusingly reports: $ git checkout -b foo origin/master bar fatal: 'bar' is not a commit and a branch 'foo' cannot be created from it $ git checkout --track -b foo origin/master bar fatal: 'bar' is not a commit and a branch 'foo' cannot be created from it That's wrong, because it very well understands that "origin/master" is supposed to be the start point for the new branch and not "bar". Check if we got a commit and show more fitting messages in that case instead: $ git checkout -b foo origin/master bar fatal: Cannot update paths and switch to branch 'foo' at the same time. $ git checkout --track -b foo origin/master bar fatal: '--track' cannot be used with updating paths Original-patch-by: Jeff King <peff@peff.net> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-21builtin/checkout: simplify metadata initializationLibravatar brian m. carlson1-3/+1
When we call init_checkout_metadata in reset_tree, we want to pass the object ID of the commit in question so that it can be passed to filters, or if there is no commit, the tree. We anticipated this latter case, which can occur elsewhere in the checkout code, but it cannot occur here. The only case in which we do not have a commit object is when invoking git switch with --orphan. Moreover, we can only hit this code path without a commit object additionally with either --force or --discard-changes. In such a case, there is no point initializing the checkout metadata with a commit or tree because (a) there is no commit, only the empty tree, and (b) we will never use the data, since no files will be smudged when checking out a branch with no files. Pass the all-zeros object ID in this case, since we just need some value which is a valid pointer. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Reviewed-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-08Merge branch 'es/restore-staged-from-head-by-default'Libravatar Junio C Hamano1-3/+3
"git restore --staged --worktree" now defaults to take the contents out of "HEAD", instead of erring out. * es/restore-staged-from-head-by-default: restore: default to HEAD when combining --staged and --worktree
2020-05-08Merge branch 'dl/switch-c-option-in-error-message'Libravatar Junio C Hamano1-4/+10
In error messages that "git switch" mentions its option to create a new branch, "-b/-B" options were shown, where "-c/-C" options should be, which has been corrected. * dl/switch-c-option-in-error-message: switch: fix errors and comments related to -c and -C
2020-05-05restore: default to HEAD when combining --staged and --worktreeLibravatar Eric Sunshine1-3/+3
By default, files are restored from the index for --worktree, and from HEAD for --staged. When --worktree and --staged are combined, --source must be specified to disambiguate the restore source[1], thus making it cumbersome to restore a file in both the worktree and the index. However, HEAD is also a reasonable default for --worktree when combined with --staged, so make it the default anytime --staged is used (whether combined with --worktree or not). [1]: Due to an oversight, the --source requirement, though documented, is not actually enforced. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-30switch: fix errors and comments related to -c and -CLibravatar Denton Liu1-4/+10
In d787d311db (checkout: split part of it to new command 'switch', 2019-03-29), the `git switch` command was created by extracting the common functionality of cmd_checkout() in checkout_main(). However, in b7b5fce270 (switch: better names for -b and -B, 2019-03-29), the branch creation and force creation options for 'switch' were changed to -c and -C, respectively. As a result of this, error messages and comments that previously referred to `-b` and `-B` became invalid for `git switch`. For error messages that refer to `-b` and `-B`, use a format string instead so that `-c` and `-C` can be printed when `git switch` is invoked. Reported-by: Robert Simpson Signed-off-by: Denton Liu <liu.denton@gmail.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-28Use OPT_CALLBACK and OPT_CALLBACK_FLibravatar Denton Liu1-2/+2
In the codebase, there are many options which use OPTION_CALLBACK in a plain ol' struct definition. However, we have the OPT_CALLBACK and OPT_CALLBACK_F macros which are meant to abstract these plain struct definitions away. These macros are useful as they semantically signal to developers that these are just normal callback option with nothing fancy happening. Replace plain struct definitions of OPTION_CALLBACK with OPT_CALLBACK or OPT_CALLBACK_F where applicable. The heavy lifting was done using the following (disgusting) shell script: #!/bin/sh do_replacement () { tr '\n' '\r' | sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\s*0,\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK(\1,\2,\3,\4,\5,\6)/g' | sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK_F(\1,\2,\3,\4,\5,\6,\7)/g' | tr '\r' '\n' } for f in $(git ls-files \*.c) do do_replacement <"$f" >"$f.tmp" mv "$f.tmp" "$f" done The result was manually inspected and then reformatted to match the style of the surrounding code. Finally, using `git grep OPTION_CALLBACK \*.c`, leftover results which were not handled by the script were manually transformed. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-16builtin/checkout: compute checkout metadata for checkoutsLibravatar brian m. carlson1-4/+14
Provide commit metadata for checkout code paths that use unpack_trees and friends. When we're checking out a commit, use the commit information, but don't provide commit information if we're checking out from the index, since there need not be any particular commit associated with the index, and even if there is one, we can't know what it is. Signed-off-by: brian m. carlson <bk2204@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-16convert: provide additional metadata to filtersLibravatar brian m. carlson1-0/+13
Now that we have the codebase wired up to pass any additional metadata to filters, let's collect the additional metadata that we'd like to pass. The two main places we pass this metadata are checkouts and archives. In these two situations, reading HEAD isn't a valid option, since HEAD isn't updated for checkouts until after the working tree is written and archives can accept an arbitrary tree. In other situations, HEAD will usually reflect the refname of the branch in current use. We pass a smaller amount of data in other cases, such as git cat-file, where we can really only logically know about the blob. This commit updates only the parts of the checkout code where we don't use unpack_trees. That function and callers of it will be handled in a future commit. In the archive code, we leak a small amount of memory, since nothing we pass in the archiver argument structure is freed. Signed-off-by: brian m. carlson <bk2204@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-12builtin/checkout: pass branch info down to checkout_worktreeLibravatar brian m. carlson1-16/+17
In the future, we're going to want to use the branch info in checkout_worktree, so let's pass the whole struct branch_info down, not just the revision name. We hoist the definition of struct branch_info so it's in scope. Signed-off-by: brian m. carlson <bk2204@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-17Merge branch 'rs/strbuf-insertstr'Libravatar Junio C Hamano1-1/+1
Code clean-up. * rs/strbuf-insertstr: mailinfo: don't insert header prefix for handle_content_type() strbuf: add and use strbuf_insertstr()
2020-02-10strbuf: add and use strbuf_insertstr()Libravatar René Scharfe1-1/+1
Add a function for inserting a C string into a strbuf. Use it throughout the source to get rid of magic string length constants and explicit strlen() calls. Like strbuf_addstr(), implement it as an inline function to avoid the implicit strlen() calls to cause runtime overhead. Helped-by: Taylor Blau <me@ttaylorr.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-05Merge branch 'am/checkout-file-and-ref-ref-ambiguity'Libravatar Junio C Hamano1-32/+39
"git checkout X" did not correctly fail when X is not a local branch but could name more than one remote-tracking branches (i.e. to be dwimmed as the starting point to create a corresponding local branch), which has been corrected. * am/checkout-file-and-ref-ref-ambiguity: checkout: don't revert file on ambiguous tracking branches parse_branchname_arg(): extract part as new function
2020-01-22Merge branch 'nd/switch-and-restore'Libravatar Junio C Hamano1-0/+2
"git restore --staged" did not correctly update the cache-tree structure, resulting in bogus trees to be written afterwards, which has been corrected. * nd/switch-and-restore: restore: invalidate cache-tree when removing entries with --staged
2020-01-08restore: invalidate cache-tree when removing entries with --stagedLibravatar Jeff King1-0/+2
When "git restore --staged <path>" removes a path that's in the index, it marks the entry with CE_REMOVE, but we don't do anything to invalidate the cache-tree. In the non-staged case, we end up in checkout_worktree(), which calls remove_marked_cache_entries(). That actually drops the entries from the index, as well as invalidating the cache-tree and untracked-cache. But with --staged, we never call checkout_worktree(), and the CE_REMOVE entries remain. Interestingly, they are dropped when we write out the index, but that means the resulting index is inconsistent: its cache-tree will not match the actual entries, and running "git commit" immediately after will create the wrong tree. We can solve this by calling remove_marked_cache_entries() ourselves before writing out the index. Note that we can't just hoist it out of checkout_worktree(); that function needs to iterate over the CE_REMOVE entries (to drop their matching worktree files) before removing them. One curiosity about the test: without this patch, it actually triggers a BUG() when running git-restore: BUG: cache-tree.c:810: new1 with flags 0x4420000 should not be in cache-tree But in the original problem report, which used a similar recipe, git-restore actually creates the bogus index (and the commit is created with the wrong tree). I'm not sure why the test here behaves differently than my out-of-suite reproduction, but what's here should catch either symptom (and the fix corrects both cases). Reported-by: Torsten Krah <krah.tm@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-07checkout: don't revert file on ambiguous tracking branchesLibravatar Alexandr Miloslavskiy1-31/+25
For easier understanding, here are the existing good scenarios: 1) Have *no* file 'foo', *no* local branch 'foo' and a *single* remote branch 'foo' 2) `git checkout foo` will create local branch foo, see [1] and 1) Have *a* file 'foo', *no* local branch 'foo' and a *single* remote branch 'foo' 2) `git checkout foo` will complain, see [3] This patch prevents the following scenario: 1) Have *a* file 'foo', *no* local branch 'foo' and *multiple* remote branches 'foo' 2) `git checkout foo` will successfully... revert contents of file `foo`! That is, adding another remote suddenly changes behavior significantly, which is a surprise at best and could go unnoticed by user at worst. Please see [3] which gives some real world complaints. To my understanding, fix in [3] overlooked the case of multiple remotes, and the whole behavior of falling back to reverting file was never intended: [1] introduces the unexpected behavior. Before, there was fallback from not-a-ref to pathspec. This is reasonable fallback. After, there is another fallback from ambiguous-remote to pathspec. I understand that it was a copy&paste oversight. [2] noticed the unexpected behavior but chose to semi-document it instead of forbidding, because the goal of the patch series was focused on something else. [3] adds `die()` when there is ambiguity between branch and file. The case of multiple tracking branches is seemingly overlooked. The new behavior: if there is no local branch and multiple remote candidates, just die() and don't try reverting file whether it exists (prevents surprise) or not (improves error message). [1] Commit 70c9ac2f ("DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"" 2009-10-18) https://public-inbox.org/git/7vaazpxha4.fsf_-_@alter.siamese.dyndns.org/ [2] Commit ad8d5104 ("checkout: add advice for ambiguous "checkout <branch>"", 2018-06-05) https://public-inbox.org/git/20180502105452.17583-1-avarab@gmail.com/ [3] Commit be4908f1 ("checkout: disambiguate dwim tracking branches and local files", 2018-11-13) https://public-inbox.org/git/20181110120707.25846-1-pclouds@gmail.com/ Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-07parse_branchname_arg(): extract part as new functionLibravatar Alexandr Miloslavskiy1-6/+19
This is done for the next commit to avoid crazy 7x tab code padding. Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-04checkout, restore: support the --pathspec-from-file optionLibravatar Alexandr Miloslavskiy1-4/+27
Decisions taken for simplicity: 1) For now, `--pathspec-from-file` is declared incompatible with `--patch`, even when <file> is not `stdin`. Such use case it not really expected. 2) It is not allowed to pass pathspec in both args and file. `you must specify path(s) to restore` block was moved down to be able to test for `pathspec.nr` instead, because testing for `argc` is no longer correct. `git switch` does not support the new options because it doesn't expect `<pathspec>` arguments. Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15Merge branch 'en/merge-recursive-cleanup'Libravatar Junio C Hamano1-4/+10
The merge-recursive machiery is one of the most complex parts of the system that accumulated cruft over time. This large series cleans up the implementation quite a bit. * en/merge-recursive-cleanup: (26 commits) merge-recursive: fix the fix to the diff3 common ancestor label merge-recursive: fix the diff3 common ancestor label for virtual commits merge-recursive: alphabetize include list merge-recursive: add sanity checks for relevant merge_options merge-recursive: rename MERGE_RECURSIVE_* to MERGE_VARIANT_* merge-recursive: split internal fields into a separate struct merge-recursive: avoid losing output and leaking memory holding that output merge-recursive: comment and reorder the merge_options fields merge-recursive: consolidate unnecessary fields in merge_options merge-recursive: move some definitions around to clean up the header merge-recursive: rename merge_options argument to opt in header merge-recursive: rename 'mrtree' to 'result_tree', for clarity merge-recursive: use common name for ancestors/common/base_list merge-recursive: fix some overly long lines cache-tree: share code between functions writing an index as a tree merge-recursive: don't force external callers to do our logging merge-recursive: remove useless parameter in merge_trees() merge-recursive: exit early if index != head Ensure index matches head before invoking merge machinery, round N merge-recursive: remove another implicit dependency on the_repository ...
2019-09-30Merge branch 'nd/switch-and-restore'Libravatar Junio C Hamano1-0/+9
Resurrect a performance hack. * nd/switch-and-restore: checkout: add simple check for 'git checkout -b'
2019-09-09Merge branch 'en/checkout-mismerge-fix'Libravatar Junio C Hamano1-7/+0
Fix a mismerge that happened in 2.22 timeframe. * en/checkout-mismerge-fix: checkout: remove duplicate code
2019-08-30checkout: add simple check for 'git checkout -b'Libravatar Derrick Stolee1-0/+9
The 'git switch' command was created to separate half of the behavior of 'git checkout'. It specifically has the mode to do nothing with the index and working directory if the user only specifies to create a new branch and change HEAD to that branch. This is also the behavior most users expect from 'git checkout -b', but for historical reasons it also performs an index update by scanning the working directory. This can be slow for even moderately-sized repos. A performance fix for 'git checkout -b' was introduced by fa655d8411 (checkout: optimize "git checkout -b <new_branch>" 2018-08-16). That change includes details about the config setting checkout.optimizeNewBranch when the sparse-checkout feature is required. The way this change detected if this behavior change is safe was through the skip_merge_working_tree() method. This method was complex and needed to be updated as new options were introduced. This behavior was essentially reverted by 65f099b ("switch: no worktree status unless real branch switch happens" 2019-03-29). Instead, two members of the checkout_opts struct were used to distinguish between 'git checkout' and 'git switch': * switch_branch_doing_nothing_is_ok * only_merge_on_switching_branches These settings have opposite values depending on if we start in cmd_checkout or cmd_switch. The message for 64f099b includes "Users of big repos are encouraged to move to switch." Making this change while 'git switch' is still experimental is too aggressive. Create a happy medium between these two options by making 'git checkout -b <branch>' behave just like 'git switch', but only if we read exactly those arguments. This must be done in cmd_checkout to avoid the arguments being consumed by the option parsing logic. This differs from the previous change by fa644d8 in that the config option checkout.optimizeNewBranch remains deleted. This means that 'git checkout -b' will ignore the index merge even if we have a sparse-checkout file. While this is a behavior change for 'git checkout -b', it matches the behavior of 'git switch -c'. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Acked-by: Elijah Newren <newren@gmail.com> Acked-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-22Merge branch 'vn/restore-empty-ita-corner-case-fix'Libravatar Junio C Hamano1-0/+1
"git checkout" and "git restore" to re-populate the index from a tree-ish (typically HEAD) did not work correctly for a path that was removed and then added again with the intent-to-add bit, when the corresponding working tree file was empty. This has been corrected. * vn/restore-empty-ita-corner-case-fix: restore: add test for deleted ita files checkout.c: unstage empty deleted ita files
2019-08-19cache-tree: share code between functions writing an index as a treeLibravatar Elijah Newren1-1/+1
write_tree_from_memory() appeared to be a merge-recursive special that basically duplicated write_index_as_tree(). The two have a different signature, but the bigger difference was just that write_index_as_tree() would always unconditionally read the index off of disk instead of working on the current in-memory index. So: * split out common code into write_index_as_tree_internal() * rename write_tree_from_memory() to write_inmemory_index_as_tree(), make it call write_index_as_tree_internal(), and move it to cache-tree.c Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-19merge-recursive: remove useless parameter in merge_trees()Libravatar Elijah Newren1-3/+1
merge_trees() took a results parameter that would only be written when opt->call_depth was positive, which is never the case now that merge_trees_internal() has been split from merge_trees(). Remove the misleading and unused parameter from merge_trees(). While at it, add some comments explaining how the output of merge_trees() and merge_recursive() differ. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-16checkout: provide better conflict hunk description with detached HEADLibravatar Elijah Newren1-0/+8
When running 'git checkout -m' and using diff3 style conflict markers, we want all the conflict hunks (left-side, "common" or "merge base", and right-side) to have label markers letting the user know where each came from. The "common" hunk label (o.ancestor) came from old_branch_info->name, but that is NULL when HEAD is detached, which resulted in a blank label. Check for that case and provide an abbreviated commit hash instead. (Incidentally, this was the only case in the git codebase where merge_trees() was called with opt->ancestor being NULL. A subsequent commit will prevent similar problems by enforcing that merge_trees() always be called with opt->ancestor != NULL.) Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-16checkout: remove duplicate codeLibravatar Elijah Newren1-7/+0
Both commit a7256debd4b6 ("checkout.txt: note about losing staged changes with --merge", 2019-03-19) from nd/checkout-m-doc-update and commit 6eff409e8a76 ("checkout: prevent losing staged changes with --merge", 2019-03-22) from nd/checkout-m were included in git.git despite the fact that the latter was meant to be v2 of the former. The merge of these two topics resulted in a redundant chunk of code; remove it. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-06l10n: reformat some localized strings for v2.23.0Libravatar Jean-Noël Avila1-1/+1
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-02checkout.c: unstage empty deleted ita filesLibravatar Varun Naik1-0/+1
It is possible to delete a committed file from the index and then add it as intent-to-add. After `git checkout HEAD <pathspec>`, the file should be identical in the index and HEAD. The command already works correctly if the file has contents in HEAD. This patch provides the desired behavior even when the file is empty in HEAD. `git checkout HEAD <pathspec>` calls tree.c:read_tree_1(), with fn pointing to checkout.c:update_some(). update_some() creates a new cache entry but discards it when its mode and oid match those of the old entry. A cache entry for an ita file and a cache entry for an empty file have the same oid. Therefore, an empty deleted ita file previously passed both of these checks, and the new entry was discarded, so the file remained unchanged in the index. After this fix, if the file is marked as ita in the cache, then we avoid discarding the new entry and add the new entry to the cache instead. This change should not affect newly added ita files. For those, inside tree.c:read_tree_1(), tree_entry_interesting() returns entry_not_interesting, so fn is never called. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Varun Naik <vcnaik94@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-09Merge branch 'nd/switch-and-restore'Libravatar Junio C Hamano1-320/+584
Two new commands "git switch" and "git restore" are introduced to split "checking out a branch to work on advancing its history" and "checking out paths out of the index and/or a tree-ish to work on advancing the current history" out of the single "git checkout" command. * nd/switch-and-restore: (46 commits) completion: disable dwim on "git switch -d" switch: allow to switch in the middle of bisect t2027: use test_must_be_empty Declare both git-switch and git-restore experimental help: move git-diff and git-reset to different groups doc: promote "git restore" user-manual.txt: prefer 'merge --abort' over 'reset --hard' completion: support restore t: add tests for restore restore: support --patch restore: replace --force with --ignore-unmerged restore: default to --source=HEAD when only --staged is specified restore: reject invalid combinations with --staged restore: add --worktree and --staged checkout: factor out worktree checkout code restore: disable overlay mode by default restore: make pathspec mandatory restore: take tree-ish from --source option instead checkout: split part of it to new command 'restore' doc: promote "git switch" ...
2019-06-20switch: allow to switch in the middle of bisectLibravatar Nguyễn Thái Ngọc Duy1-3/+1
In c45f0f525d (switch: reject if some operation is in progress, 2019-03-29), a check is added to prevent switching when some operation is in progress. The reason is it's often not safe to do so. This is true for merge, am, rebase, cherry-pick and revert, but not so much for bisect because bisecting is basically jumping/switching between a bunch of commits to pin point the first bad one. git-bisect suggests the next commit to test, but it's not wrong for the user to test a different commit because git-bisect cannot have the knowledge to know better. For this reason, allow to switch when bisecting (*). I considered if we should still prevent switching by default and allow it with --ignore-in-progress. But I don't think the prevention really adds anything much. If the user switches away by mistake, since we print the previous HEAD value, even if they don't know about the "-" shortcut, switching back is still possible. The warning will be printed on every switch while bisect is still ongoing, not the first time you switch away from bisect's suggested commit, so it could become a bit annoying. (*) of course when it's safe to do so, i.e. no loss of local changes and stuff. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-07restore: support --patchLibravatar Nguyễn Thái Ngọc Duy1-2/+4
git-restore is different from git-checkout that it only restores the worktree by default, not both worktree and index. add--interactive needs some update to support this mode. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-07restore: replace --force with --ignore-unmergedLibravatar Nguyễn Thái Ngọc Duy1-9/+20
Use a more specific option name to express its purpose. --force may come back as an alias of --ignore-unmerged and possibly more. But since this is a destructive operation, I don't see why we need to "force" anything more. We already don't hold back. When 'checkout --force' or 'restore --ignore-unmerged' is used, we may also print warnings about unmerged entries being ignore. Since this is not exactly warning (people tell us to do so), more informational, let it be suppressed if --quiet is given. This is a behavior change for git-checkout. PS. The diff looks a bit iffy since --force is moved to add_common_switch_branch_options() (i.e. for switching). But git-checkout is also doing switching and inherits this --force. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-07restore: default to --source=HEAD when only --staged is specifiedLibravatar Nguyễn Thái Ngọc Duy1-0/+6
"git restore --staged" without --source does not make much sense since by default we restore from the index. Instead of copying the index to itself, set the default source to HEAD in this case, yielding behavior that matches "git reset -- <paths>". Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-07restore: reject invalid combinations with --stagedLibravatar Nguyễn Thái Ngọc Duy1-0/+10
git-checkout rejects plenty of invalid option combinations. Since git-checkout is equivalent of either git restore --source --staged --worktree or git restore --worktree that still leaves the new mode 'git restore --index' unprotected. Reject some more invalid option combinations. The other new mode 'restore --source --worktree' does not need anything else. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>