summaryrefslogtreecommitdiff
path: root/t/t2024-checkout-dwim.sh
AgeCommit message (Collapse)AuthorFilesLines
2014-10-14checkout: report upstream correctly even with loosely defined branch.*.mergeLibravatar Junio C Hamano1-0/+18
When checking out a branch that is set to build on top of another branch (often, a remote-tracking branch), "git checkout" reports how your work relates to the other branch, e.g. Your branch is behind 'origin/master', and can be fast-forwarded. Back when this feature was introduced, this was only done for branches that build on remote-tracking branches, but 5e6e2b48 (Make local branches behave like remote branches when --tracked, 2009-04-01) added support to give the same report for branches that build on other local branches (i.e. branches whose branch.*.remote variables are set to '.'). Unlike the support for the branches building on remote-tracking branches, however, this did not take into account the fact that branch.*.merge configuration is allowed to record a shortened branch name. When branch.*.merge is set to 'master' (not 'refs/heads/master'), i.e. "my branch builds on the local 'master' branch", this caused "git checkout" to report: Your branch is based on 'master', but the upstream is gone. The upstream is our repository and is definitely not gone, so this output is nonsense. The fix is fairly obvious; just like the branch name is DWIMed when "git pull" merges from the 'master' branch without complaint on such a branch, the name of the branch the current branch builds upon needs to be DWIMed the same way. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30Merge branch 'mm/checkout-auto-track-fix'Libravatar Junio C Hamano1-0/+21
"git checkout topic", when there is not yet a local "topic" branch but there is a unique remote-tracking branch for a remote "topic" branch, pretended as if "git checkout -t -b topic remote/$r/topic" (for that unique remote $r) was run. This hack however was not implemented for "git checkout topic --". * mm/checkout-auto-track-fix: checkout: proper error message on 'git checkout foo bar --' checkout: allow dwim for branch creation for "git checkout $branch --"
2013-10-18checkout: allow dwim for branch creation for "git checkout $branch --"Libravatar Matthieu Moy1-0/+21
The "--" notation disambiguates files and branches, but as a side-effect of the previous implementation, also disabled the branch auto-creation when $branch does not exist. A possible scenario is then: git checkout $branch => fails if $branch is both a ref and a file, and suggests -- git checkout $branch -- => refuses to create the $branch This patch allows the second form to create $branch, and since the -- is provided, it does not look for file named $branch. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09t2024: Fix &&-chaining and a couple of typosLibravatar Johan Herland1-3/+3
Improved-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21branch.c: Validate tracking branches with refspecs instead of refs/remotes/*Libravatar Johan Herland1-1/+1
The current code for validating tracking branches (e.g. the argument to the -t/--track option) hardcodes refs/heads/* and refs/remotes/* as the potential locations for tracking branches. This works with the refspecs created by "git clone" or "git remote add", but is suboptimal in other cases: - If "refs/remotes/foo/bar" exists without any association to a remote (i.e. there is no remote named "foo", or no remote with a refspec that matches "refs/remotes/foo/bar"), then it is impossible to set up a valid upstream config that tracks it. Currently, the code defaults to using "refs/remotes/foo/bar" from repo "." as the upstream, which works, but is probably not what the user had in mind when running "git branch baz --track foo/bar". - If the user has tweaked the fetch refspec for a remote to put its remote-tracking branches outside of refs/remotes/*, e.g. by running git config remote.foo.fetch "+refs/heads/*:refs/foo_stuff/*" then the current code will refuse to use its remote-tracking branches as --track arguments, since they do not match refs/remotes/*. This patch removes the "refs/remotes/*" requirement for upstream branches, and replaces it with explicit checking of the refspecs for each remote to determine whether a given --track argument is a valid remote-tracking branch. This solves both of the above problems, since the matching refspec guarantees that there is a both a remote name and a remote branch name that can be used for the upstream config. However, this means that refs located within refs/remotes/* without a corresponding remote/refspec will no longer be usable as upstreams. The few existing tests which depended on this behavioral quirk has already been fixed in the preceding patches. This patch fixes the last remaining test failure in t2024-checkout-dwim. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21checkout: Use remote refspecs when DWIMming tracking branchesLibravatar Johan Herland1-3/+3
The DWIM mode of checkout allows you to run "git checkout foo" when there is no existing local ref or path called "foo", and there is exactly _one_ remote with a remote-tracking branch called "foo". Git will automatically create a new local branch called "foo" using the remote-tracking "foo" as its starting point and configured upstream. For example, consider the following unconventional (but perfectly valid) remote setup: [remote "origin"] fetch = refs/heads/*:refs/remotes/origin/* [remote "frotz"] fetch = refs/heads/*:refs/remotes/frotz/nitfol/* Case 1: Assume both "origin" and "frotz" have remote-tracking branches called "foo", at "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo" respectively. In this case "git checkout foo" should fail, because there is more than one remote with a "foo" branch. Case 2: Assume only "frotz" have a remote-tracking branch called "foo". In this case "git checkout foo" should succeed, and create a local branch "foo" from "refs/remotes/frotz/nitfol/foo", using remote branch "foo" from "frotz" as its upstream. The current code hardcodes the assumption that all remote-tracking branches must match the "refs/remotes/$remote/*" pattern (which is true for remotes with "conventional" refspecs, but not true for the "frotz" remote above). When running "git checkout foo", the current code looks for exactly one ref matching "refs/remotes/*/foo", hence in the above example, it fails to find "refs/remotes/frotz/nitfol/foo", which causes it to fail both case #1 and #2. The better way to handle the above example is to actually study the fetch refspecs to deduce the candidate remote-tracking branches for "foo"; i.e. assume "foo" is a remote branch being fetched, and then map "refs/heads/foo" through the refspecs in order to get the corresponding remote-tracking branches "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo". Finally we check which of these happens to exist in the local repo, and if there is exactly one, we have an unambiguous match for "git checkout foo", and may proceed. This fixes most of the failing tests introduced in the previous patch. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21t2024: Show failure to use refspec when DWIMming remote branch namesLibravatar Johan Herland1-1/+69
When using "git checkout foo" to DWIM the creation of local "foo" from some existing upstream "foo", we assume conventional refspecs as created by "git clone" or "git remote add", and fail to work correctly if the current refspecs do not follow the conventional "refs/remotes/$remote/*" pattern. Improved-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'Libravatar Johan Herland1-0/+99
The DWIM mode of checkout allows you to run "git checkout foo" when there is no existing local ref or path called "foo", and there is exactly one remote with a remote-tracking branch called "foo". Git will then automatically create a new local branch called "foo" using the remote-tracking "foo" as its starting point and configured upstream. Improved-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>