aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/git-switch.txt
AgeCommit message (Collapse)AuthorFilesLines
2024-01-02Merge branch 'jc/orphan-unborn'Junio C Hamano1-1/+1
Doc updates to clarify what an "unborn branch" means. * jc/orphan-unborn: orphan/unborn: fix use of 'orphan' in end-user facing messages orphan/unborn: add to the glossary and use them consistently
2023-12-13checkout: forbid "-B <branch>" from touching a branch used elsewhereJunio C Hamano1-2/+7
"git checkout -B <branch> [<start-point>]", being a "forced" version of "-b", switches to the <branch>, after optionally resetting its tip to the <start-point>, even if the <branch> is in use in another worktree, which is somewhat unexpected. Protect the <branch> using the same logic that forbids "git checkout <branch>" from touching a branch that is in use elsewhere. This is a breaking change that may deserve backward compatibliity warning in the Release Notes. The "--ignore-other-worktrees" option can be used as an escape hatch if the finger memory of existing users depend on the current behaviour of "-B". Reported-by: Willem Verstraeten <willem.verstraeten@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-11-24orphan/unborn: add to the glossary and use them consistentlyJunio C Hamano1-1/+1
To orphan is a verb that denotes the act of getting on an unborn branch, and a few references to "orphan branch" in our documentation are misuses of the word. They caused end-user confusion, which was made even worse because we did not have the term defined in the glossary document. Add entries for "unborn" branch and "orphan" operation to the glossary, and adjust existing documentation accordingly. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-09-07docs: add CONFIGURATION sections that fuzzy map to built-insÆvar Arnfjörð Bjarmason1-0/+7
Add a CONFIGURATION section to the documentation of various built-ins, for those cases where the relevant config/NAME.txt doesn't map only to one git-NAME.txt. In particular: * config/blame.txt: used by git-{blame,annotate}.txt. Since the git-annotate(1) documentation refers to git-blame(1) don't add a "CONFIGURATION" section to git-annotate(1), only to git-blame(1). * config/checkout.txt: maps to both git-checkout.txt and git-switch.txt (but nothing else). * config/init.txt: should be included in git-init(1) and git-clone(1). * config/column.txt: We should ideally mention the relevant subset of this in git-{branch,clean,status,tag}.txt, but let's punt on it for now. We will when we eventually split these sort of files into e.g. config/column.txt and config/column/{branch,clean,status,tag}.txt, with the former including the latter set. Things that are being left out, and why: * config/{remote,remotes,credential}.txt: Configuration that affects how we talk to remote repositories is harder to untangle. We'll need to include some of this in git-{fetch,remote,push,ls-remote}.txt etc., but some of those only use a small subset of these options. Let's leave this for now. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Reviewed-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-10Merge branch 'js/branch-track-inherit'Junio C Hamano1-1/+1
"git -c branch.autosetupmerge=inherit branch new old" makes "new" to have the same upstream as the "old" branch, instead of marking "old" itself as its upstream. * js/branch-track-inherit: config: require lowercase for branch.*.autosetupmerge branch: add flags and config to inherit tracking branch: accept multiple upstream branches for tracking
2021-12-20branch: add flags and config to inherit trackingJosh Steadmon1-1/+1
It can be helpful when creating a new branch to use the existing tracking configuration from the branch point. However, there is currently not a method to automatically do so. Teach git-{branch,checkout,switch} an "inherit" argument to the "--track" option. When this is set, creating a new branch will cause the tracking configuration to default to the configuration of the branch point, if set. For example, if branch "main" tracks "origin/main", and we run `git checkout --track=inherit -b feature main`, then branch "feature" will track "origin/main". Thus, `git status` will show us how far ahead/behind we are from origin, and `git pull` will pull from origin. This is particularly useful when creating branches across many submodules, such as with `git submodule foreach ...` (or if running with a patch such as [1], which we use at $job), as it avoids having to manually set tracking info for each submodule. Since we've added an argument to "--track", also add "--track=direct" as another way to explicitly get the original "--track" behavior ("--track" without an argument still works as well). Finally, teach branch.autoSetupMerge a new "inherit" option. When this is set, "--track=inherit" becomes the default behavior. [1]: https://lore.kernel.org/git/20180927221603.148025-1-sbeller@google.com/ Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-01update documentation for new zdiff3 conflictStyleElijah Newren1-2/+1
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-08checkout: learn to respect checkout.guessDenton Liu1-0/+3
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-04-06doc: --recurse-submodules mostly applies to active submodulesDamien Robert1-1/+1
The documentation refers to "initialized" or "populated" submodules, to explain which submodules are affected by '--recurse-submodules', but the real terminology here is 'active' submodules. Update the documentation accordingly. Some terminology: - Active is defined in gitsubmodules(7), it only involves the configuration variables 'submodule.active', 'submodule.<name>.active' and 'submodule.<name>.url'. The function submodule.c::is_submodule_active checks that a submodule is active. - Populated means that the submodule's working tree is present (and the gitfile correctly points to the submodule repository), i.e. either the superproject was cloned with ` --recurse-submodules`, or the user ran `git submodule update --init`, or `git submodule init [<path>]` and `git submodule update [<path>]` separately which populated the submodule working tree. This does not involve the 3 configuration variables above. - Initialized (at least in the context of the man pages involved in this patch) means both "populated" and "active" as defined above, i.e. what `git submodule update --init` does. The --recurse-submodules option mostly affects active submodules. An exception is `git fetch` where the option affects populated submodules. As a consequence, in `git pull --recurse-submodules` the fetch affects populated submodules, but the resulting working tree update only affects active submodules. In the documentation of `git-pull`, let's distinguish between the fetching part which affects populated submodules, and the updating of worktrees, which only affects active submodules. Signed-off-by: Damien Robert <damien.olivier.robert+git@gmail.com> Helped-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-06doc: document --recurse-submodules for reset and restoreDamien Robert1-1/+1
Also unify the formulation about --no-recurse-submodules for checkout and switch, which we reuse for restore. And correct the formulation about submodules' HEAD in read-tree, which we reuse in reset. Signed-off-by: Damien Robert <damien.olivier.robert+git@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-07Declare both git-switch and git-restore experimentalNguyễn Thái Ngọc Duy1-0/+2
These two commands are basically redesigned git-checkout. We will not have that many opportunities to redo (because we run out of verbs, and that would also increase maintenance cost). To play it safe, let's declare the two commands experimental in one or two releases. If there is a serious flaw in the UI, we could still fix it. If everything goes well and nobody complains loudly, we can remove the experimental status by reverting this patch. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-02checkout: split part of it to new command 'switch'Nguyễn Thái Ngọc Duy1-0/+271
"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 <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>