path: root/builtin/checkout.c
AgeCommit message (Collapse)Author
2020-02-17Merge branch 'rs/strbuf-insertstr'Junio C Hamano
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()René Scharfe
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 <> Helped-by: Eric Sunshine <> Signed-off-by: René Scharfe <> Signed-off-by: Junio C Hamano <>
2020-02-05Merge branch 'am/checkout-file-and-ref-ref-ambiguity'Junio C Hamano
"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'Junio C Hamano
"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 --stagedJeff King
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 <> Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2020-01-07checkout: don't revert file on ambiguous tracking branchesAlexandr Miloslavskiy
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) [2] Commit ad8d5104 ("checkout: add advice for ambiguous "checkout <branch>"", 2018-06-05) [3] Commit be4908f1 ("checkout: disambiguate dwim tracking branches and local files", 2018-11-13) Signed-off-by: Alexandr Miloslavskiy <> Signed-off-by: Junio C Hamano <>
2020-01-07parse_branchname_arg(): extract part as new functionAlexandr Miloslavskiy
This is done for the next commit to avoid crazy 7x tab code padding. Signed-off-by: Alexandr Miloslavskiy <> Signed-off-by: Junio C Hamano <>
2019-12-04checkout, restore: support the --pathspec-from-file optionAlexandr Miloslavskiy
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 `` 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 <> Signed-off-by: Junio C Hamano <>
2019-10-15Merge branch 'en/merge-recursive-cleanup'Junio C Hamano
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'Junio C Hamano
Resurrect a performance hack. * nd/switch-and-restore: checkout: add simple check for 'git checkout -b'
2019-09-09Merge branch 'en/checkout-mismerge-fix'Junio C Hamano
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'Derrick Stolee
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 <> Acked-by: Elijah Newren <> Acked-by: Taylor Blau <> Signed-off-by: Junio C Hamano <>
2019-08-22Merge branch 'vn/restore-empty-ita-corner-case-fix'Junio C Hamano
"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 treeElijah Newren
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 <> Signed-off-by: Junio C Hamano <>
2019-08-19merge-recursive: remove useless parameter in merge_trees()Elijah Newren
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 <> Signed-off-by: Junio C Hamano <>
2019-08-16checkout: provide better conflict hunk description with detached HEADElijah Newren
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 <> Signed-off-by: Junio C Hamano <>
2019-08-16checkout: remove duplicate codeElijah Newren
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 <> Signed-off-by: Junio C Hamano <>
2019-08-06l10n: reformat some localized strings for v2.23.0Jean-Noël Avila
Signed-off-by: Jean-Noël Avila <> Signed-off-by: Junio C Hamano <>
2019-08-02checkout.c: unstage empty deleted ita filesVarun Naik
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 <> Signed-off-by: Varun Naik <> Signed-off-by: Junio C Hamano <>
2019-07-09Merge branch 'nd/switch-and-restore'Junio C Hamano
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 bisectNguyễn Thái Ngọc Duy
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 <> Signed-off-by: Junio C Hamano <>
2019-05-07restore: support --patchNguyễn Thái Ngọc Duy
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 <> Signed-off-by: Junio C Hamano <>
2019-05-07restore: replace --force with --ignore-unmergedNguyễn Thái Ngọc Duy
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 <> Signed-off-by: Junio C Hamano <>
2019-05-07restore: default to --source=HEAD when only --staged is specifiedNguyễn Thái Ngọc Duy
"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 <> Signed-off-by: Junio C Hamano <>
2019-05-07restore: reject invalid combinations with --stagedNguyễn Thái Ngọc Duy
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 <> Signed-off-by: Junio C Hamano <>
2019-05-07restore: add --worktree and --stagedNguyễn Thái Ngọc Duy
'git checkout <tree-ish> <pathspec>' updates both index and worktree. But updating the index when you want to restore worktree files is non-intuitive. The index contains the data ready for the next commit, and there's no indication that the user will want to commit the restored versions. 'git restore' therefore by default only touches worktree. The user has the option to update either the index with git restore --staged --source=<tree> <path> (1) or update both with git restore --staged --worktree --source=<tree> <path> (2) PS. Orignally I wanted to make worktree update default and form (1) would add index update while also updating the worktree, and the user would need to do "--staged --no-worktree" to update index only. But it looks really confusing that "--staged" option alone updates both. So now form (2) is used for both, which reads much more obvious. PPS. Yes form (1) overlaps with "git reset <rev> <path>". I don't know if we can ever turn "git reset" back to "_always_ reset HEAD and optionally do something else". Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-05-07checkout: factor out worktree checkout codeNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-05-07restore: disable overlay mode by defaultNguyễn Thái Ngọc Duy
Overlay mode is considered confusing when the command is about restoring files on worktree. Disable it by default. The user can still turn it on, or use 'git checkout' which still has overlay mode on by default. While at it, make the check in checkout_branch() stricter. Neither --overlay or --no-overlay should be accepted in branch switching mode. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-05-07restore: make pathspec mandatoryNguyễn Thái Ngọc Duy
"git restore" without arguments does not make much sense when it's about restoring files (what files now?). We could default to either git restore . or git restore :/ Neither is intuitive. Make the user always give pathspec, force the user to think the scope of restore they want because this is a destructive operation. "git restore -p" without pathspec is an exception to this because it really is a separate mode. It will be treated as running patch mode on the whole worktree. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-05-07restore: take tree-ish from --source option insteadNguyễn Thái Ngọc Duy
This is another departure from 'git checkout' syntax, which uses -- to separate ref and pathspec. The observation is restore (or "git checkout -- <pathspec>") is most often used to restore some files from the index. If this is correct, we can simplify it by taking away the ref, so that we can write git restore some-file without worrying about some-file being a ref and whether we need to do git restore -- some-file for safety. If the source of the restore comes from a tree, it will be in the form of an option with value, e.g. git restore --source=this-tree some-file This is of course longer to type than using "--". But hopefully it will not be used as often, and it is clearly easier to understand. dwim_new_local_branch is no longer set (or unset) in cmd_restore_files() because it's irrelevant because we don't really care about dwim-ing. With accept_ref being unset, dwim can't happen. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-05-07checkout: split part of it to new command 'restore'Nguyễn Thái Ngọc Duy
Previously the switching branch business of 'git checkout' becomes a new command 'switch'. This adds the restore command for the checking out paths path. Similar to git-switch, a new man page is added to describe what the command will become. The implementation will be updated shortly to match the man page. A couple main differences from 'git checkout <paths>': - 'restore' by default will only update worktree. This matters more when --source is specified ('checkout <tree> <paths>' updates both worktree and index). - 'restore --staged' can be used to restore the index. This command overlaps with 'git reset <paths>'. - both worktree and index could also be restored at the same time (from a tree) when both --staged and --worktree are specified. This overlaps with 'git checkout <tree> <paths>' - default source for restoring worktree and index is the index and HEAD respectively. A different (tree) source could be specified as with --source (*). - when both index and worktree are restored, --source must be specified since the default source for these two individual targets are different (**) - --no-overlay is enabled by default, if an entry is missing in the source, restoring means deleting the entry (*) I originally went with --from instead of --source. I still think --from is a better name. The short option -f however is already taken by force. And I do think short option is good to have, e.g. to write -s@ or -s@^ instead of --source=HEAD. (**) If you sit down and think about it, moving worktree's source from the index to HEAD makes sense, but nobody is really thinking it through when they type the commands. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-04-25Merge branch 'nd/checkout-m'Junio C Hamano
"git checkout -m <other>" was about carrying the differences between HEAD and the working-tree files forward while checking out another branch, and ignored the differences between HEAD and the index. The command has been taught to abort when the index and the HEAD are different. * nd/checkout-m: checkout: prevent losing staged changes with --merge read-tree: add --quiet unpack-trees: rename "gently" flag to "quiet" unpack-trees: keep gently check inside add_rejected_path
2019-04-25Merge branch 'jk/unused-params-even-more'Junio C Hamano
Code cleanup. * jk/unused-params-even-more: parse_opt_ref_sorting: always use with NONEG flag pretty: drop unused strbuf from parse_padding_placeholder() pretty: drop unused "type" parameter in needs_rfc2047_encoding() parse-options: drop unused ctx parameter from show_gitcomp() fetch_pack(): drop unused parameters report_path_error(): drop unused prefix parameter unpack-trees: drop unused error_type parameters unpack-trees: drop name_entry from traverse_by_cache_tree() test-date: drop unused "now" parameter from parse_dates() update-index: drop unused prefix_length parameter from do_reupdate() log: drop unused "len" from show_tagger() log: drop unused rev_info from early output revision: drop some unused "revs" parameters
2019-04-16Merge branch 'nd/checkout-m-doc-update'Junio C Hamano
Doc about the above. * nd/checkout-m-doc-update: checkout.txt: note about losing staged changes with --merge
2019-04-02switch: make --orphan switch to an empty treeNguyễn Thái Ngọc Duy
Switching and creating branches always involves knowing the <start-point> to begin the new branch from. Sometimes, people want to create a new branch that does not have any commits yet; --orphan is a flag to allow that. --orphan overrides the default of HEAD for <start-point> instead causing us to start from an empty history with all tracked files removed from the index and working tree. The use of --orphan is incompatible with specifying a <start-point>. A note on the implementation. An alternative is just create a dummy commit in-core with empty tree and switch to it. But there's a chance the commit's SHA-1 may end up somewhere permanent like reflog. It's best to make sure "commit" pointer is NULL to avoid it. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-04-02switch: reject if some operation is in progressNguyễn Thái Ngọc Duy
Unless you know what you're doing, switching to another branch to do something then switching back could be confusing. Worse, you may even forget that you're in the middle of something. By the time you realize, you may have done a ton of work and it gets harder to go back. A new option --ignore-in-progress was considered but dropped because it was not exactly clear what should happen. Sometimes you can switch away and get back safely and resume the operation. Sometimes not. And the git-checkout behavior is automatically clear merge/revert/cherry-pick, which makes it a bit even more confusing [1]. We may revisit and add this option in the future. But for now play it safe and not allow it (you can't even skip this check with --force). The user is suggested to cancel the operation by themselves (and hopefully they do consider the consequences, not blindly type the command), or to create a separate worktree instead of switching. The third option is the good old "git checkout", but it's not mentioned. [1] Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-04-02switch: no worktree status unless real branch switch happensNguyễn Thái Ngọc Duy
When we switch from one branch to another, it makes sense to show a summary of local changes since there could be conflicts, or some files left modified.... When switch is used solely for creating a new branch (and "switch" to the same commit) or detaching, we don't really need to show anything. "git checkout" does it anyway for historical reasons. But we can start with a clean slate with switch and don't have to. This essentially reverts fa655d8411 (checkout: optimize "git checkout -b <new_branch>" - 2018-08-16) and make it default for switch, but also for -B and --detach. Users of big repos are encouraged to move to switch. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-04-02switch: implicit dwim, use --no-guess to disable itNguyễn Thái Ngọc Duy
This is already the default in git-checkout. The real change in here is just minor cleanup. The main excuse is to explain why dwim is kept default. Contrary to detach mode that is easy to get into and confusing to get back out. Automatically creating a tracking branch often does not kick in as often (you would need a branch of the same name on a remote). And since the branch creation is reported clearly, the user should be able to undo/delete it if it's unwanted. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-04-02switch: add short option for --detachNguyễn Thái Ngọc Duy
"git checkout" automatically detaches branches and --detach is not that useful (--no-detach is more likely). But for "switch", you may want to use it more often once you're used to detached HEAD. This of course adds -d to git-checkout but it does not harm (yet?) to do it. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-04-02switch: only allow explicit detached HEADNguyễn Thái Ngọc Duy
"git checkout <commit>" will checkout the commit in question and detach HEAD from the current branch. It is naturally a right thing to do once you get git references. But detached HEAD is a scary concept to new users because we show a lot of warnings and stuff, and it could be hard to get out of (until you know better). To keep switch a bit more friendly to new users, we only allow entering detached HEAD mode when --detach is given. "git switch" must take a branch (unless you create a new branch, then of course switch can take any commit-ish) Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-04-02switch: reject "do nothing" caseNguyễn Thái Ngọc Duy
"git checkout" can be executed without any arguments. What it does is not exactly great: it switches from HEAD to HEAD and shows worktree modification as a side effect. Make switch reject this case. Just use "git status" if you want that side effect. For switch, you have to either - really switch a branch - (explicitly) detach from the current branch - create a new branch Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-04-02switch: stop accepting pathspecNguyễn Thái Ngọc Duy
This command is about switching branch (or creating a new one) and should not accept pathspec. This helps simplify ambiguation handling. The other two ("git checkout" and "git restore") of course do accept pathspec as before. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-04-02switch: remove -lNguyễn Thái Ngọc Duy
This option is ancient. Nowadays reflog is enabled by default and automatically created for new branches. Keep it in git-checkout only. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-04-02switch: add --discard-changesNguyễn Thái Ngọc Duy
--discard-changes is a better name than --force for this option since it's what really happens. --force is turned to an alias for --discard-changes. But it's meant to be an alias for potentially more force options in the future. Side note. It's not obvious from the patch but --discard-changes also affects submodules if --recurse-submodules is used. The knob to force updating submodules is hidden behind unpack-trees.c Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-04-02switch: better names for -b and -BNguyễn Thái Ngọc Duy
The shortcut of these options do not make much sense when used with switch. And their descriptions are also tied to checkout. Move -b/-B to cmd_checkout() and new -c/-C with the same functionality in cmd_switch_branch() Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-04-02checkout: split part of it to new command 'switch'Nguyễn Thái Ngọc Duy
"git checkout" doing too many things is a source of confusion for many users (and it even bites old timers sometimes). To remedy that, the command will be split into two new ones: switch and restore. The good old "git checkout" command is still here and will be until all (or most of users) are sick of it. See the new man page for the final design of switch. The actual implementation though is still pretty much the same as "git checkout" and not completely aligned with the man page. Following patches will adjust their behavior to match the man page. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-04-02checkout: split options[] array in three piecesNguyễn Thái Ngọc Duy
This is a preparation step for introducing new commands that do parts of what checkout does. There will be two new commands, one is about switching branches, detaching HEAD... one about checking out paths. These share the a subset of command line options. The rest of command line options are separate. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-04-02checkout: move 'confict_style' and 'dwim_..' to checkout_optsNguyễn Thái Ngọc Duy
These local variables are referenced by struct option[]. This struct will soon be broken down, moved away and we can't rely on local variables anymore. Move these two to struct checkout_opts in preparation for that. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-04-02checkout: make "opts" in cmd_checkout() a pointerNguyễn Thái Ngọc Duy
"opts" will soon be moved out of cmd_checkout(). To keep changes in that patch smaller, convert "opts" to a pointer and keep the real thing behind "real_opts". Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-04-02checkout: factor out some code in parse_branchname_arg()Nguyễn Thái Ngọc Duy
This is in preparation for the new command restore, which also needs to parse opts->source_tree but does not need all the disambiguation logic. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>