summaryrefslogtreecommitdiff
path: root/t/t3200-branch.sh
AgeCommit message (Collapse)AuthorFilesLines
2008-05-11Allow tracking branches to set up rebase by default.Libravatar Dustin Sallings1-0/+234
Change cd67e4d4 introduced a new configuration parameter that told pull to automatically perform a rebase instead of a merge. This change provides a configuration option to enable this feature automatically when creating a new branch. If the variable branch.autosetuprebase applies for a branch that's being created, that branch will have branch.<name>.rebase set to true. Signed-off-by: Dustin Sallings <dustin@spy.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-18Fix t3200 configLibravatar Daniel Barkalow1-10/+10
"git-config name = value" doesn't do anything most of the time. The test meant "git-config name value", but that leaves the configuration such that later tests will be confused, so move it to the end. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-27Merge branch 'js/branch-track'Libravatar Junio C Hamano1-1/+21
* js/branch-track: doc: documentation update for the branch track changes branch: optionally setup branch.*.merge from upstream local branches Conflicts: Documentation/config.txt Documentation/git-branch.txt Documentation/git-checkout.txt builtin-branch.c cache.h t/t7201-co.sh
2008-02-19branch: optionally setup branch.*.merge from upstream local branchesLibravatar Jay Soffian1-1/+21
"git branch" and "git checkout -b" now honor --track option even when the upstream branch is local. Previously --track was silently ignored when forking from a local branch. Also the command did not error out when --track was explicitly asked for but the forked point specified was not an existing branch (i.e. when there is no way to set up the tracking configuration), but now it correctly does. The configuration setting branch.autosetupmerge can now be set to "always", which is equivalent to using --track from the command line. Setting branch.autosetupmerge to "true" will retain the former behavior of only setting up branch.*.merge for remote upstream branches. Includes test cases for the new functionality. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01Sane use of test_expect_failureLibravatar Junio C Hamano1-17/+19
Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-11branch --track: code cleanup and saner handling of local branchesLibravatar Johannes Schindelin1-10/+11
This patch cleans up some complicated code, and replaces it with a cleaner version, using code from remote.[ch], which got extended a little in the process. This also enables us to fix two cases: The earlier "fix" to setup tracking only when the original ref started with "refs/remotes" is wrong. You are absolutely allowed to use a separate layout for your tracking branches. The correct fix, of course, is to set up tracking information only when there is a matching remote.<nick>.fetch line containing a colon. Another corner case was not handled properly. If two remotes write to the original ref, just warn the user and do not set up tracking. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-08branch.autosetupmerge: allow boolean values, or "all"Libravatar Johannes Schindelin1-0/+9
Junio noticed that switching on autosetupmerge unilaterally started cluttering the config for local branches. That is not the original intention of branch.autosetupmerge, which was meant purely for convenience when branching off of remote branches, but that semantics got lost somewhere. If you still want that "new" behavior, you can switch branch.autosetupmerge to the value "all". Otherwise, it is interpreted as a boolean, which triggers setting up defaults _only_ when branching off of a remote branch, i.e. the originally intended behavior. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-02Rewrite "git-frotz" to "git frotz"Libravatar Junio C Hamano1-81/+81
This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-09git-branch: cleanup config file when deleting branchesLibravatar Gerrit Pape1-0/+9
When deleting branches, remove the sections referring to these branches from the config file. Signed-off-by: Gerrit Pape <pape@smarden.org>
2007-06-06git-branch --track: fix tracking branch computation.Libravatar Junio C Hamano1-4/+12
The original code did not take hierarchical branch names into account at all. Tested-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-04-06t3200-branch.sh: small language nitLibravatar Arjen Laarhoven1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-06Distinguish branches by more than case in tests.Libravatar Brian Gernhardt1-3/+3
The renaming without config test changed a branch from q to Q, which fails on non-case sensitive file systems. Change the test to use q and q2. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-05Fix renaming branch without config fileLibravatar Geert Bosch1-0/+9
Make git_config_rename_section return success if no config file exists. Otherwise, renaming a branch would abort, leaving the repository in an inconsistent state. [jc: test] Signed-off-by: Geert Bosch <bosch@gnat.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-16git-fetch, git-branch: Support local --track via a special remote '.'Libravatar Paolo Bonzini1-0/+6
This patch adds support for a dummy remote '.' to avoid having to declare a fake remote like [remote "local"] url = . fetch = refs/heads/*:refs/heads/* Such a builtin remote simplifies the operation of "git-fetch", which will populate FETCH_HEAD but will not pretend that two repositories are in use, will not create a thin pack, and will not perform any useless remapping of names. The speed improvement is around 20%, and it should improve more if "git-fetch" is converted to a builtin. To this end, git-parse-remote is grown with a new kind of remote, 'builtin'. In git-fetch.sh, we treat the builtin remote specially in that it needs no pack/store operations. In fact, doing git-fetch on a builtin remote will simply populate FETCH_HEAD appropriately. The patch also improves of the --track/--no-track support, extending it so that branch.<name>.remote items referring '.' can be created. Finally, it fixes a typo in git-checkout.sh. Signed-off-by: Paolo Bonzini <bonzini@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-10git-branch, git-checkout: autosetup for remote branch trackingLibravatar Paolo Bonzini1-11/+54
In order to track and build on top of a branch 'topic' you track from your upstream repository, you often would end up doing this sequence: git checkout -b mytopic origin/topic git config --add branch.mytopic.remote origin git config --add branch.mytopic.merge refs/heads/topic This would first fork your own 'mytopic' branch from the 'topic' branch you track from the 'origin' repository; then it would set up two configuration variables so that 'git pull' without parameters does the right thing while you are on your own 'mytopic' branch. This commit adds a --track option to git-branch, so that "git branch --track mytopic origin/topic" performs the latter two actions when creating your 'mytopic' branch. If the configuration variable branch.autosetupmerge is set to true, you do not have to pass the --track option explicitly; further patches in this series allow setting the variable with a "git remote add" option. The configuration variable is off by default, and there is a --no-track option to countermand it even if the variable is set. Signed-off-by: Paolo Bonzini <bonzini@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28[PATCH] Rename git-repo-config to git-config.Libravatar Tom Prince1-3/+3
Signed-off-by: Tom Prince <tom.prince@ualberta.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-08git-checkout: fix branch name output from the commandLibravatar Junio C Hamano1-1/+1
When switching branches with "git checkout", we internally did $arg^0 (aka $arg^{commit}) suffix but there was no need to. The improvement is easily visible in the change to an existing test t/3200-branch.sh in this commit; it was expecting rather ugly message. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-16git-branch: rename config vars branch.<branch>.*, tooLibravatar Johannes Schindelin1-0/+6
When renaming a branch, the corresponding config section should be renamed, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-05rename_ref: use lstat(2) when testing for symlinkLibravatar Lars Hjemli1-0/+7
The current check for symlinked reflogs was based on stat(2), which is utterly embarrassing. Fix it, and add a matching testcase. Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-05git-branch: add options and tests for branch renamingLibravatar Lars Hjemli1-0/+34
Extend git-branch with the following options: git-branch -m|-M [<oldbranch>] newbranch The -M variation is required to force renaming over an exsisting branchname. This also indroduces $GIT_DIR/RENAME_REF which is a "metabranch" used when renaming branches. It will always hold the original sha1 for the latest renamed branch. Additionally, if $GIT_DIR/logs/RENAME_REF exists, all branch rename events are logged there. Finally, some testcases are added to verify the new options. Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-23t3200: git-branch testsuite updateLibravatar Junio C Hamano1-6/+3
The test expected "git branch --help" to exit successfully, but built-ins spawn "man" when given --help, and when the test is run, manpages may not be installed yet and "man" can legally exit non-zero in such a case. Also the new implementation logs "Created from master", instead of "Created from HEAD" in the reflog, which makes a lot more sense, so adjust the test to match that. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-25Remove empty ref directories that prevent creating a ref.Libravatar Christian Couder1-0/+12
This patch also adds test cases from Linus and Junio. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-24Test that git-branch -l works.Libravatar Shawn Pearce1-1/+30
If the user supplies -l to git-branch when creating a new branch then the new branch's log should be created automatically and the branch creation should be logged in that log. Further if a branch is being deleted and it had a log then also verify that the log was deleted. Test git-checkout -b foo -l for creating a new branch foo with a log and checking out that branch. Fixed git-checkout -b foo -l as the branch variable name was incorrect in the script. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-14t3200: branch --help does not die anymore.Libravatar Junio C Hamano1-2/+2
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-14allow git-update-ref create refs with slashes in namesLibravatar Alex Riesen1-0/+8
Make git-update-ref create references with slashes in them. git-branch and git-checkout already support such reference names. git-branch can use git-update-ref to create the references in a more formal manner now. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-08'build' scripts before installing.Libravatar Junio C Hamano1-3/+3
Earlier we renamed git-foo.sh to git-foo while installing, which was mostly done by inertia than anything else. This however made writing tests to use scripts harder. This patch builds the scripts the same way as we build binaries from their sources. As a side effect, you can now specify non-standard paths you have your Perl binary is in when running the make. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-07[PATCH] Do not create bogus branch from flag to git branchLibravatar Amos Waterland1-0/+27
If you run `git branch --help', you will unexpectedly have created a new branch named "--help". This simple patch adds logic and a usage statement to catch this and similar problems, and adds a testcase for it. Signed-off-by: Amos Waterland <apw@rossby.metr.ou.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>