- 07 5月, 2019 2 次提交
-
-
由 Nguyễ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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 4月, 2019 18 次提交
-
-
由 Nguyễ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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễ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] CACsJy8Axa5WsLSjiscjnxVK6jQHkfs-gH959=YtUvQkWriAk5w@mail.gmail.com Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễ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 fa655d84 (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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễ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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễ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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễ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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễ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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễ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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễ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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễ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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễ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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễ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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễ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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễ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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
The include list becomes very long and frankly a bit unorganized. With the exception of builtin.h, cache.h or git-compat-util.h which have to come first, keep the rest sorted. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
After a successful switch, if a merge, cherry-pick or revert is ongoing, it is canceled. This behavior has been with us from the very early beginning, soon after git-merge was created but never actually documented [1]. It may be a good idea to be transparent and tell the user if some operation is canceled. I consider this a better way of telling the user than just adding a sentence or two in git-checkout.txt, which will be mostly ignored anyway. PS. Originally I wanted to print more details like warning: cancelling an in-progress merge from <SHA-1> which may allow some level of undo if the user wants to. But that seems a lot more work. Perhaps it can be improved later if people still want that. [1] ... and I will try not to argue whether it is a sensible behavior. There is some more discussion here if people are interested: CACsJy8Axa5WsLSjiscjnxVK6jQHkfs-gH959=YtUvQkWriAk5w@mail.gmail.com Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 2月, 2019 1 次提交
-
-
由 Jeff Hostetler 提交于
Signed-off-by: NJeff Hostetler <jeffhost@microsoft.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 2月, 2019 2 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
Since 0f086e6d (checkout: print something when checking out paths - 2018-11-13), this command reports how many paths have been updated from what source (either from a tree, or from the index). I forget that there's a third source: when -m is used, the merge conflict is re-created (granted, also from the index, but it's not a straight copy from the index). Count and report unmerged paths separately. There's a bit more update to avoid reporting: Recreated X merge conflicts Updated 0 paths from the index The second line is unnecessary. Though if there's no conflict recreation, we still report Updated 0 paths from the index to make it clear we're not really doing anything. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
Commit 0f086e6d [1] counts the number of files updated by "git checkout -- <paths>" command and prints it. Later on 536ec183 [2] adds the ability to remove files in "git checkout -- <paths>". This is still an update on worktree and should be reported to the user. To prepare for such an update since that commit is on track to 'master' now, the messages are rephrased to avoid "checked out" which does not imply file deletion. [1] 0f086e6d (checkout: print something when checking out paths - 2018-11-13) [2] 536ec183 (entry: support CE_WT_REMOVE flag in checkout_entry - 2018-12-20) Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 05 2月, 2019 1 次提交
-
-
由 Thomas Gummerer 提交于
This reverts 1495ff7d ("checkout: introduce checkout.overlayMode config", 2019-01-08) and thus removes the checkout.overlayMode config option. The option was originally introduced to give users the option to make the new no-overlay behaviour the default. However users may be using 'git checkout' in scripts, even though it is porcelain. Users setting the option to false may actually end up accidentally breaking scripts. With the introduction of a new subcommand that will make the behaviour the default, the config option will not be needed anymore anyway. Revert the commit and remove the config option, so we don't risk breaking scripts. Suggested-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NThomas Gummerer <t.gummerer@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 1月, 2019 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
By default, index compat macros are off from now on, because they could hide the_index dependency. Only those in builtin can use it. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 1月, 2019 1 次提交
-
-
由 Ben Peart 提交于
When doing a 'checkout -b' do a full checkout including updating the working tree when doing the initial checkout. As the new test involves an filesystem access, do it later in the sequence to give chance to other cheaper tests to leave early. This fixes the regression in behavior caused by fa655d84 (checkout: optimize "git checkout -b <new_branch>", 2018-08-16). Signed-off-by: NBen Peart <benpeart@microsoft.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 1月, 2019 2 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 1月, 2019 2 次提交
-
-
由 Thomas Gummerer 提交于
In the previous patch we introduced a new no-overlay mode for git checkout. Some users (such as the author of this commit) may want to have this mode turned on by default as it matches their mental model more closely. Make that possible by introducing a new config option to that extend. Signed-off-by: NThomas Gummerer <t.gummerer@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Thomas Gummerer 提交于
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: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NThomas Gummerer <t.gummerer@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 03 1月, 2019 2 次提交
-
-
由 Thomas Gummerer 提交于
Factor out the code that marks a cache entry as matched for checkout into a separate function. We are going to introduce a new mode in 'git checkout' in a subsequent commit, that is going to have a slightly different logic. This would make this code unnecessarily complex. Moving that complexity into separate functions will make the code in the subsequent step easier to follow. Signed-off-by: NThomas Gummerer <t.gummerer@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Thomas Gummerer 提交于
The key point for the if statement is that read_tree_some did not update the entry, because either it doesn't exist in tree-ish or doesn't match the pathspec. Clarify that. Suggested-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NThomas Gummerer <t.gummerer@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 11月, 2018 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
These functions call tree_entry_interesting() which will soon require a 'struct index_state *' to be passed in. Instead of just changing the function signature to take an index, update to take a repo instead because these functions do need object database access. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 11月, 2018 2 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
One of the problems with "git checkout" is that it does so many different things and could confuse people specially when we fail to handle ambiguation correctly. One way to help with that is tell the user what sort of operation is actually carried out. When switching branches, we always print something unless --quiet, either - "HEAD is now at ..." - "Reset branch ..." - "Already on ..." - "Switched to and reset ..." - "Switched to a new branch ..." - "Switched to branch ..." Checking out paths however is silent. Print something so that if we got the user intention wrong, they won't waste too much time to find that out. For the remaining cases of checkout we now print either - "Checked out ... paths out of the index" - "Checked out ... paths out of <abbrev hash>" Since the purpose of printing this is to help disambiguate. Only do it when "--" is missing. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
When checkout dwim is added in [1], it is restricted to only dwim when certain conditions are met and fall back to default checkout behavior otherwise. It turns out falling back could be confusing. One of the conditions to turn git checkout frotz to git checkout -b frotz origin/frotz is that frotz must not exist as a file. But when the user comes to expect "git checkout frotz" to create the branch "frotz" and there happens to be a file named "frotz", git's silently reverting "frotz" file content is not helping. This is reported in Git mailing list [2] and even used as an example of "Git is bad" elsewhere [3]. We normally try to do the right thing, but when there are multiple "right things" to do, it's best to leave it to the user to decide. Check this case, ask the user to to disambiguate: - "git checkout -- foo" will check out path "foo" - "git checkout foo --" will dwim and create branch "foo" [4] For users who do not want dwim, use --no-guess. It's useless in this particular case because "git checkout --no-guess foo --" will just fail. But it could be used by scripts. [1] 70c9ac2f (DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz" - 2009-10-18) [2] https://public-inbox.org/git/CACsJy8B2TVr1g+k+eSQ=pBEO3WN4_LtgLo9gpur8X7Z9GOFL_A@mail.gmail.com/ [3] https://news.ycombinator.com/item?id=18230655 [4] a047fafc (checkout: allow dwim for branch creation for "git checkout $branch --" - 2013-10-18) Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 11月, 2018 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 10月, 2018 1 次提交
-
-
由 Jeff King 提交于
We added faster equality-comparison functions for hashes in 14438c44 (introduce hasheq() and oideq(), 2018-08-28). A few topics were in-flight at the time, and can now be converted. This covers all spots found by "make coccicheck" in master (the coccicheck results were tweaked by hand for style). Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 9月, 2018 2 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 30 8月, 2018 1 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-