summaryrefslogtreecommitdiff
path: root/t/t3200-branch.sh
AgeCommit message (Collapse)AuthorFilesLines
2017-07-05reflog-walk: skip over double-null oid due to HEAD renameLibravatar Jeff King1-0/+11
Since 39ee4c6c2f (branch: record creation of renamed branch in HEAD's log, 2017-02-20), a rename on the currently checked out branch will create two entries in the HEAD reflog: one where the branch goes away (switching to the null oid), and one where it comes back (switching away from the null oid). This confuses the reflog-walk code. When walking backwards, it first sees the null oid in the "old" field of the second entry. Thanks to the "root commit" logic added by 71abeb753f (reflog: continue walking the reflog past root commits, 2016-06-03), we keep looking for the next entry by scanning the "new" field from the previous entry. But that field is also null! We need to go just a tiny bit further, and look at its "old" field. But with the current code, we decide the reflog has nothing else to show and just give up. To the user this looks like the reflog was truncated by the rename operation, when in fact those entries are still there. This patch does the absolute minimal fix, which is to look back that one extra level and keep traversing. The resulting behavior may not be the _best_ thing to do in the long run (for example, we show both reflog entries each with the same commit id), but it's a simple way to fix the problem without risking further regressions. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-13t3200: add test for single parameter passed to -m optionLibravatar Sahil Dua1-0/+17
Add a test for the case when only one parameter is passed to '-m' (move/rename) option. For example - if 'git branch -m bbb' is run while checked out on aaa branch, it should rename the currently checked out branch to bbb. There was no test for this particular case with only one parameter for -m option. However, there's one similar test case for -M option. Add test for making sure HEAD points to the bbb (new branch name). Also add a test for making sure the reflog that is moved to 'bbb' retains entries created for the currently checked out branch. Note that since the topmost entry on reflog for bbb will be about branch creation, we compare bbb@{1} (instead of bbb@{0}) with aaa@{0} to make sure the reflog for bbb retains entries from aaa. Signed-off-by: Sahil Dua <sahildua2305@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-05Merge branch 'sd/t3200-typofix' into maintLibravatar Junio C Hamano1-1/+1
Test fix. * sd/t3200-typofix: branch test: fix invalid config key access
2017-05-29branch test: fix invalid config key accessLibravatar Sahil Dua1-1/+1
Fixes the test by changing "branch.s/s/dummy" to "branch.s/s.dummy" which is the right way of accessing config key "branch.s/s.dummy". Purpose of this test is to confirm that this key doesn't exist after the branch "s/s" has been renamed to "s". Earlier it was trying to access invalid config key and hence was getting an error. However, this wasn't caught because we were expecting the command to fail for other reason as mentioned above. Signed-off-by: Sahil Dua <sahildua2305@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-11Merge branch 'ab/ref-filter-no-contains'Libravatar Junio C Hamano1-0/+4
"git tag/branch/for-each-ref" family of commands long allowed to filter the refs by "--contains X" (show only the refs that are descendants of X), "--merged X" (show only the refs that are ancestors of X), "--no-merged X" (show only the refs that are not ancestors of X). One curious omission, "--no-contains X" (show only the refs that are not descendants of X) has been added to them. * ab/ref-filter-no-contains: tag: add tests for --with and --without ref-filter: reflow recently changed branch/tag/for-each-ref docs ref-filter: add --no-contains option to tag/branch/for-each-ref tag: change --point-at to default to HEAD tag: implicitly supply --list given another list-like option tag: change misleading --list <pattern> documentation parse-options: add OPT_NONEG to the "contains" option tag: add more incompatibles mode tests for-each-ref: partly change <object> to <commit> in help tag tests: fix a typo in a test description tag: remove a TODO item from the test suite ref-filter: add test for --contains on a non-commit ref-filter: make combining --merged & --no-merged an error tag doc: reword --[no-]merged to talk about commits, not tips tag doc: split up the --[no-]merged documentation tag doc: move the description of --[no-]merged earlier
2017-03-21ref-filter: make combining --merged & --no-merged an errorLibravatar Ævar Arnfjörð Bjarmason1-0/+4
Change the behavior of specifying --merged & --no-merged to be an error, instead of silently picking the option that was provided last. Subsequent changes of mine add a --no-contains option in addition to the existing --contains. Providing both of those isn't an error, and has actual meaning. Making its cousins have different behavior in this regard would be confusing to the user, especially since we'd be silently disregarding some of their command-line input. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-14Merge branch 'kn/ref-filter-branch-list'Libravatar Junio C Hamano1-0/+25
"git branch --list" takes the "--abbrev" and "--no-abbrev" options to control the output of the object name in its "-v"(erbose) output, but a recent update started ignoring them; this fixes it before the breakage reaches to any released version. * kn/ref-filter-branch-list: branch: honor --abbrev/--no-abbrev in --list mode
2017-03-10branch: honor --abbrev/--no-abbrev in --list modeLibravatar Junio C Hamano1-0/+25
When the "branch --list" command was converted to use the --format facility from the ref-filter API, we forgot to honor the --abbrev setting in the default output format and instead used a hardcoded "7". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-20branch: record creation of renamed branch in HEAD's logLibravatar Kyle Meyer1-2/+3
Renaming the current branch adds an event to the current branch's log and to HEAD's log. However, the logged entries differ. The entry in the branch's log represents the entire renaming operation (the old and new hash are identical), whereas the entry in HEAD's log represents the deletion only (the new sha1 is null). Extend replace_each_worktree_head_symref(), whose only caller is branch_rename(), to take a reflog message argument. This allows the creation of the new ref to be recorded in HEAD's log. As a result, the renaming event is represented by two entries (a deletion and a creation entry) in HEAD's log. It's a bit unfortunate that the branch's log and HEAD's log now represent the renaming event in different ways. Given that the renaming operation is not atomic, the two-entry form is a more accurate representation of the operation and is more useful for debugging purposes if a failure occurs between the deletion and creation events. It would make sense to move the branch's log to the two-entry form, but this would involve changes to how the rename is carried out and to how the update flags and reflogs are processed for deletions, so it may not be worth the effort. Based-on-patch-by: Jeff King <peff@peff.net> Signed-off-by: Kyle Meyer <kyle@kyleam.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-20rename_ref: replace empty message in HEAD's logLibravatar Kyle Meyer1-0/+5
When the current branch is renamed, the deletion of the old ref is recorded in HEAD's log with an empty message. Now that delete_ref() accepts a reflog message, provide a more descriptive message by passing along the log message that is given to rename_ref(). The next step will be to extend HEAD's log to also include the second part of the rename, the creation of the new branch. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Kyle Meyer <kyle@kyleam.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-25Merge branch 'mh/split-under-lock'Libravatar Junio C Hamano1-0/+9
Further preparatory work on the refs API before the pluggable backend series can land. * mh/split-under-lock: (33 commits) lock_ref_sha1_basic(): only handle REF_NODEREF mode commit_ref_update(): remove the flags parameter lock_ref_for_update(): don't resolve symrefs lock_ref_for_update(): don't re-read non-symbolic references refs: resolve symbolic refs first ref_transaction_update(): check refname_is_safe() at a minimum unlock_ref(): move definition higher in the file lock_ref_for_update(): new function add_update(): initialize the whole ref_update verify_refname_available(): adjust constness in declaration refs: don't dereference on rename refs: allow log-only updates delete_branches(): use resolve_refdup() ref_transaction_commit(): correctly report close_ref() failure ref_transaction_create(): disallow recursive pruning refs: make error messages more consistent lock_ref_sha1_basic(): remove unneeded local variable read_raw_ref(): move docstring to header file read_raw_ref(): improve docstring read_raw_ref(): rename symref argument to referent ...
2016-06-17tests: use test_i18n* functions to suppress false positivesLibravatar Vasco Almeida1-3/+3
The test functions test_i18ncmp and test_i18ngrep pretend success if run under GETTEXT_POISON. By using those functions to test output which is correctly marked as translatable, enables one to detect if the strings newly marked for translation are from plumbing output. If they are indeed from plumbing, the test would fail, and the string should be unmarked, since it is not seen by users. Thus, it is productive to not have false positives when running the test under GETTEXT_POISON. This commit replaces normal test functions by their i18n aware variants in use-cases know to be correctly marked for translation, suppressing false positives. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-13refs: don't dereference on renameLibravatar David Turner1-0/+9
When renaming refs, don't dereference either the origin or the destination before renaming. The origin does not need to be dereferenced because it is presently forbidden to rename symbolic refs. Not dereferencing the destination fixes a bug where renaming on top of a broken symref would use the pointed-to ref name for the moved reflog. Add a test for the reflog bug. Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
2016-04-18Merge branch 'ky/branch-m-worktree'Libravatar Junio C Hamano1-1/+22
When "git worktree" feature is in use, "git branch -m" renamed a branch that is checked out in another worktree without adjusting the HEAD symbolic ref for the worktree. * ky/branch-m-worktree: set_worktree_head_symref(): fix error message branch -m: update all per-worktree HEADs refs: add a new function set_worktree_head_symref
2016-04-04branch -m: update all per-worktree HEADsLibravatar Kazuki Yamaguchi1-1/+22
When renaming a branch, currently only the HEAD of current working tree is updated, but it must update HEADs of all working trees which point at the old branch. This is the current behavior, /path/to/wt's HEAD is not updated: % git worktree list /path/to 2c3c5f2 [master] /path/to/wt 2c3c5f2 [oldname] % git branch -m master master2 % git worktree list /path/to 2c3c5f2 [master2] /path/to/wt 2c3c5f2 [oldname] % git branch -m oldname newname % git worktree list /path/to 2c3c5f2 [master2] /path/to/wt 0000000 [oldname] This patch fixes this issue by updating all relevant worktree HEADs when renaming a branch. Signed-off-by: Kazuki Yamaguchi <k@rhe.jp> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-29branch -d: refuse deleting a branch which is currently checked outLibravatar Kazuki Yamaguchi1-0/+6
When a branch is checked out by current working tree, deleting the branch is forbidden. However when the branch is checked out only by other working trees, deleting incorrectly succeeds. Use find_shared_symref() to check if the branch is in use, not just comparing with the current working tree's HEAD. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Kazuki Yamaguchi <k@rhe.jp> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22branch: die on config error when unsetting upstreamLibravatar Patrick Steinhardt1-0/+7
When we try to unset upstream configurations we do not check return codes for the `git_config_set` functions. As those may indicate that we were unable to unset the respective configuration we may exit successfully without any error message while in fact the upstream configuration was not unset. Fix this by dying with an error message when we cannot unset the configuration. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22branch: report errors in tracking branch setupLibravatar Patrick Steinhardt1-1/+8
When setting up a new tracking branch fails due to issues with the configuration file we do not report any errors to the user and pretend setting the tracking branch succeeded. Setting up the tracking branch is handled by the `install_branch_config` function. We do not want to simply die there as the function is not only invoked when explicitly setting upstream information with `git branch --set-upstream-to=`, but also by `git push --set-upstream` and `git clone`. While it is reasonable to die in the explict first case, we would lose information in the latter two cases, so we only print the error message but continue the program as usual. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-28tests: remove some direct access to .git/logsLibravatar David Turner1-6/+6
Alternate refs backends might store reflogs somewhere other than .git/logs. Change most test code that directly accesses .git/logs to instead use git reflog commands. There are still a few tests which need direct access to reflogs: to check reflog permissions, to manually create reflogs from scratch, to save/restore reflogs, to check the format of raw reflog data, and to remove not just reflog contents, but the reflogs themselves. All cases which don't need direct access have been modified. Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-22Merge branch 'mg/branch-d-m-f'Libravatar Junio C Hamano1-0/+14
"git branch -d" (delete) and "git branch -m" (move) learned to honor "-f" (force) flag; unlike many other subcommands, the way to force these have been with separate "-D/-M" options, which was inconsistent. * mg/branch-d-m-f: branch: allow -f with -m and -d t3200-branch: test -M
2014-12-09branch: allow -f with -m and -dLibravatar Michael J Gruber1-0/+5
-f/--force is the standard way to force an action, and is used by branch for the recreation of existing branches, but not for deleting unmerged branches nor for renaming to an existing branch. Make "-m -f" equivalent to "-M" and "-d -f" equivalent to" -D", i.e. allow -f/--force to be used with -m/-d also. For the list modes, "-f" is simply ignored. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-04t3200-branch: test -MLibravatar Michael J Gruber1-0/+9
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-15branch -d: avoid repeated symref resolutionLibravatar Jonathan Nieder1-0/+9
If a repository gets in a broken state with too much symref nesting, it cannot be repaired with "git branch -d": $ git symbolic-ref refs/heads/nonsense refs/heads/nonsense $ git branch -d nonsense error: branch 'nonsense' not found. Worse, "git update-ref --no-deref -d" doesn't work for such repairs either: $ git update-ref -d refs/heads/nonsense error: unable to resolve reference refs/heads/nonsense: Too many levels of symbolic links Fix both by teaching resolve_ref_unsafe a new RESOLVE_REF_NO_RECURSE flag and passing it when appropriate. Callers can still read the value of a symref (for example to print a message about it) with that flag set --- resolve_ref_unsafe will resolve one level of symrefs and stop there. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Reviewed-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-31Merge branch 'dt/tests-with-env-not-subshell'Libravatar Junio C Hamano1-10/+2
* dt/tests-with-env-not-subshell: tests: use "env" to run commands with temporary env-var settings
2014-03-19tests: use "env" to run commands with temporary env-var settingsLibravatar David Tran1-10/+2
Ordinarily, we would say "VAR=VAL command" to execute a tested command with environment variable(s) set only for that command. This however does not work if 'command' is a shell function (most notably 'test_must_fail'); the result of the assignment is retained and affects later commands. To avoid this, we used to assign and export environment variables and run such a test in a subshell, like so: ( VAR=VAL && export VAR && test_must_fail git command to be tested ) But with "env" utility, we should be able to say: test_must_fail env VAR=VAL git command to be tested which is much shorter and easier to read. Signed-off-by: David Tran <unsignedzero@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-06t3200-branch: test setting branch as own upstreamLibravatar Brian Gesiak1-0/+10
No test asserts that "git branch -u refs/heads/my-branch my-branch" avoids leaving nonsense configuration and emits a warning. Add a test that does so. Signed-off-by: Brian Gesiak <modocache@gmail.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-01Merge branch 'js/test-help-format-windows-port-fix'Libravatar Junio C Hamano1-1/+1
* js/test-help-format-windows-port-fix: t3200: do not open a HTML manual page when DEFAULT_MAN_FORMAT is html
2013-10-30t3200: do not open a HTML manual page when DEFAULT_MAN_FORMAT is htmlLibravatar Johannes Sixt1-1/+1
We have the build configuration option DEFAULT_MAN_FORMAT to choose a format different from man pages to be used by 'git help' when no format is requested explicitly. Since 65db0443 (Set the default help format to html for msys builds, 2013-06-04) we use html on Windows by default. There is one test in t3200-branch.sh that invokes a help page. The intent of the redirections applied to the command invocation is to avoid that the man page viewer interferes with the automated test. But when the default format is not "man", this does not have the intended effect, and the HTML manual page is opened during the test run. Request "man" format explicitly to keep the test silent. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-20Merge branch 'jh/checkout-auto-tracking'Libravatar Junio C Hamano1-1/+37
Fix a minor regression in v1.8.3.2 and later that made it impossible to base your local work on anything but a local branch of the upstream repository you are tracking from. * jh/checkout-auto-tracking: t3200: fix failure on case-insensitive filesystems branch.c: Relax unnecessary requirement on upstream's remote ref name t3200: Add test demonstrating minor regression in 41c21f2 Refer to branch.<name>.remote/merge when documenting --track t3200: Minor fix when preparing for tracking failure t2024: Fix &&-chaining and a couple of typos
2013-09-17t3200: fix failure on case-insensitive filesystemsLibravatar Eric Sunshine1-0/+1
62d94a3a (t3200: Add test demonstrating minor regression in 41c21f2; 2013-09-08) introduced a test which creates a directory named 'a', however, on case-insensitive filesystems, this action fails with a "fatal: cannot mkdir a: File exists" error due to a file named 'A' left over from earlier tests. Resolve this problem. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09branch.c: Relax unnecessary requirement on upstream's remote ref nameLibravatar Per Cederqvist1-1/+1
When creating an upstream relationship, we use the configured remotes and their refspecs to determine the upstream configuration settings branch.<name>.remote and branch.<name>.merge. However, if the matching refspec does not have refs/heads/<something> on the remote side, we end up rejecting the match, and failing the upstream configuration. It could be argued that when we set up an branch's upstream, we want that upstream to also be a proper branch in the remote repo. Although this is typically the common case, there are cases (as demonstrated by the previous patch in this series) where this requirement prevents a useful upstream relationship from being formed. Furthermore: - We have fundamentally no say in how the remote repo have organized its branches. The remote repo may put branches (or branch-like constructs that are insteresting for downstreams to track) outside refs/heads/*. - The user may intentionally want to track a non-branch from a remote repo, by using a branch and configured upstream in the local repo. Relaxing the checking to only require a matching remote/refspec allows the testcase introduced in the previous patch to succeed, and has no negative effect on the rest of the test suite. This patch fixes a behavior (arguably a regression) first introduced in 41c21f2 (branch.c: Validate tracking branches with refspecs instead of refs/remotes/*) on 2013-04-21 (released in >= v1.8.3.2). Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09t3200: Add test demonstrating minor regression in 41c21f2Libravatar Johan Herland1-0/+34
In 41c21f2 (branch.c: Validate tracking branches with refspecs instead of refs/remotes/*), we changed the rules for what is considered a valid tracking branch (a.k.a. upstream branch). We now use the configured remotes and their refspecs to determine whether a proposed tracking branch is in fact within the domain of a remote, and we then use that information to deduce the upstream configuration (branch.<name>.remote and branch.<name>.merge). However, with that change, we also check that - in addition to a matching refspec - the result of mapping the tracking branch through that refspec (i.e. the corresponding ref name in the remote repo) happens to start with "refs/heads/". In other words, we require that a tracking branch refers to a _branch_ in the remote repo. Now, consider that you are e.g. setting up an automated building/testing infrastructure for a group of similar "source" repositories. The build/test infrastructure consists of a central scheduler, and a number of build/test "slave" machines that perform the actual build/test work. The scheduler monitors the group of similar repos for changes (e.g. with a periodic "git fetch"), and triggers builds/tests to be run on one or more slaves. Graphically the changes flow between the repos like this: Source #1 -------v ----> Slave #1 / Source #2 -----> Scheduler -----> Slave #2 \ Source #3 -------^ ----> Slave #3 ... ... The scheduler maintains a single Git repo with each of the source repos set up as distinct remotes. The slaves also need access to all the changes from all of the source repos, so they pull from the scheduler repo, but using the following custom refspec: remote.origin.fetch = "+refs/remotes/*:refs/remotes/*" This makes all of the scheduler's remote-tracking branches automatically available as identical remote-tracking branches in each of the slaves. Now, consider what happens if a slave tries to create a local branch with one of the remote-tracking branches as upstream: git branch local_branch --track refs/remotes/source-1/some_branch Git now looks at the configured remotes (in this case there is only "origin", pointing to the scheduler's repo) and sees refs/remotes/source-1/some_branch matching origin's refspec. Mapping through that refspec we find that the corresponding remote ref name is "refs/remotes/source-1/some_branch". However, since this remote ref name does not start with "refs/heads/", we discard it as a suitable upstream, and the whole command fails. This patch adds a testcase demonstrating this failure by creating two source repos ("a" and "b") that are forwarded through a scheduler ("c") to a slave repo ("d"), that then tries create a local branch with an upstream. See the next patch in this series for the exciting conclusion to this story... Reported-by: Per Cederqvist <cederp@opera.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09t3200: Minor fix when preparing for tracking failureLibravatar Johan Herland1-1/+2
We're testing that trying to --track a ref that is not covered by any remote refspec should fail. For that, we want to have refs/remotes/local/master present, but we also want the remote.local.fetch refspec to NOT match refs/remotes/local/master (so that the tracking setup will fail, as intended). However, when doing "git fetch local" to ensure the existence of refs/remotes/local/master, we must not already have changed remote.local.fetch so as to cause refs/remotes/local/master not to be fetched. Therefore, set remote.local.fetch to refs/heads/*:refs/remotes/local/* BEFORE we fetch, and then reset it to refs/heads/s:refs/remotes/local/s AFTER we have fetched (but before we test --track). Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-03t: branch: fix broken && chainsLibravatar Felipe Contreras1-4/+4
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-03t: branch: fix typoLibravatar Felipe Contreras1-1/+1
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-03t: branch: trivial style fixLibravatar Felipe Contreras1-1/+2
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> 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-21t3200.39: tracking setup should fail if there is no matching refspec.Libravatar Johan Herland1-4/+4
We are formalizing a requirement that any remote-tracking branch to be used as an upstream (i.e. as an argument to --track), _must_ "belong" to a configured remote by being matched by the "dst" side of a fetch refspec. This patch encodes the new expected behavior of this test, and marks the test with "test_expect_failure" in anticipation of a following patch to introduce the new behavior. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07Merge branch 'jk/set-upstream-error-cases'Libravatar Junio C Hamano1-0/+12
The handing by "git branch --set-upstream-to" against various forms of errorneous inputs were suboptimal. * jk/set-upstream-error-cases: branch: give advice when tracking start-point is missing branch: mention start_name in set-upstream error messages branch: improve error message for missing --set-upstream-to ref branch: factor out "upstream is not a branch" error messages t3200: test --set-upstream-to with bogus refs
2013-04-03Merge branch 'jm/branch-rename-nothing-error'Libravatar Junio C Hamano1-1/+1
"git branch -m" without any argument noticed an error, but with an incorrect error message. * jm/branch-rename-nothing-error: branch: give better message when no names specified for rename
2013-04-02t3200: test --set-upstream-to with bogus refsLibravatar Jeff King1-0/+12
These tests pass with the current code, but let's make sure we don't accidentally break the behavior in the future. Note that our tests expect failure when we try to set the upstream to or from a missing branch. Technically we are just munging config here, so we do not need the refs to exist. But seeing that they do exist is a good check that the user has not made a typo. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-01Merge branch 'rr/test-3200-style'Libravatar Junio C Hamano1-253/+267
Churns. * rr/test-3200-style: t3200 (branch): modernize style
2013-03-31branch: give better message when no names specified for renameLibravatar Jonathon Mah1-1/+1
Signed-off-by: Jonathon Mah <me@JonathonMah.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-20t3200 (branch): modernize styleLibravatar Ramkumar Ramachandra1-233/+244
Style is inconsistent throughout the file. Make the following changes: 1. Indent everything with tabs. 2. Put the opening quote (') for the test in the same line as test_expect_success, and the closing quote on a line by itself. 3. Do not add extra space between redirection operator and filename, i.e. "cmd >dst", not "cmd > dst". Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-23branch: segfault fixes and validationLibravatar Nguyễn Thái Ngọc Duy1-0/+21
branch_get() can return NULL (so far on detached HEAD only) but some code paths in builtin/branch.c cannot deal with that and cause segfaults. While at there, make sure to bail out when the user gives 2 or more branches with --set-upstream-to or --unset-upstream, where only the first branch is processed and the rest silently dropped. Reported-by: Per Cederqvist <cederp@opera.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-30branch: give a more helpful message on redundant argumentsLibravatar Nguyễn Thái Ngọc Duy1-2/+2
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18branch: show targets of deleted symrefs, not sha1sLibravatar René Scharfe1-3/+2
git branch reports the abbreviated hash of the head commit of a deleted branch to make it easier for a user to undo the operation. For symref branches this doesn't help. Print the symref target instead for them. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18branch: skip commit checks when deleting symref branchesLibravatar René Scharfe1-0/+9
Before a branch is deleted, we check that it points to a valid commit. With -d we also check that the commit is a merged; this check is not done with -D. The reason for that is that commits pointed to by branches should never go missing; if they do then something broke and it's better to stop instead of adding to the mess. And a non-merged commit may contain changes that are worth preserving, so we require the stronger option -D instead of -d to get rid of them. If a branch consists of a symref, these concerns don't apply. Deleting such a branch can't make a commit become unreferenced, so we don't need to check if it is merged, or even if it is actually a valid commit. Skip them in that case. This allows us to delete dangling symref branches. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18branch: delete symref branch, not its targetLibravatar René Scharfe1-0/+11
If a branch that is to be deleted happens to be a symref to another branch, the current code removes the targeted branch instead of the one it was called for. Change this surprising behaviour and delete the symref branch instead. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-10Merge branch 'cn/branch-set-upstream-to'Libravatar Junio C Hamano1-0/+70
"git branch --set-upstream origin/master" is a common mistake to create a local branch 'origin/master' and set it to integrate with the current branch. With a plan to deprecate this option, introduce "git branch (-u|--set-upstream-to) origin/master" that sets the current branch to integrate with 'origin/master' remote tracking branch. * cn/branch-set-upstream-to: branch: deprecate --set-upstream and show help if we detect possible mistaken use branch: add --unset-upstream option branch: introduce --set-upstream-to