mirrors/git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-14 21:23:03 +01:00
Code Activity
git/t/t3200-branch.sh

228 lines
7.9 KiB
Bash
Raw Normal View History

[PATCH] Do not create bogus branch from flag to git branch 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>
2005-09-08 04:13:26 +02:00
#!/bin/sh
#
# Copyright (c) 2005 Amos Waterland
#
test_description='git branch --foo should not create bogus branch
This test runs git branch --help and checks that the argument is properly
handled. Specifically, that a bogus branch is not created.
'
. ./test-lib.sh
test_expect_success \
t3200-branch.sh: small language nit Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-07 01:48:54 +02:00
'prepare a trivial repository' \
[PATCH] Do not create bogus branch from flag to git branch 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>
2005-09-08 04:13:26 +02:00
'echo Hello > A &&
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
git update-index --add A &&
Test that git-branch -l works. 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>
2006-05-25 05:34:04 +02:00
git-commit -m "Initial commit." &&
branch: optionally setup branch.*.merge from upstream local branches "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-19 17:24:37 +01:00
echo World >> A &&
git update-index --add A &&
git-commit -m "Second commit." &&
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
HEAD=$(git rev-parse --verify HEAD)'
[PATCH] Do not create bogus branch from flag to git branch 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>
2005-09-08 04:13:26 +02:00
Sane use of test_expect_failure 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>
2008-02-01 10:50:53 +01:00
test_expect_success \
'git branch --help should not have created a bogus branch' '
git branch --help </dev/null >/dev/null 2>/dev/null;
! test -f .git/refs/heads/--help
'
[PATCH] Do not create bogus branch from flag to git branch 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>
2005-09-08 04:13:26 +02:00
allow git-update-ref create refs with slashes in names 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-11-14 23:10:59 +01:00
test_expect_success \
'git branch abc should create a branch' \
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
'git branch abc && test -f .git/refs/heads/abc'
allow git-update-ref create refs with slashes in names 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-11-14 23:10:59 +01:00
test_expect_success \
'git branch a/b/c should create a branch' \
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
'git branch a/b/c && test -f .git/refs/heads/a/b/c'
allow git-update-ref create refs with slashes in names 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-11-14 23:10:59 +01:00
Test that git-branch -l works. 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>
2006-05-25 05:34:04 +02:00
cat >expect <<EOF
t3200: git-branch testsuite update 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-10-24 07:48:45 +02:00
0000000000000000000000000000000000000000 $HEAD $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150200 +0000 branch: Created from master
Test that git-branch -l works. 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>
2006-05-25 05:34:04 +02:00
EOF
test_expect_success \
'git branch -l d/e/f should create a branch and a log' \
'GIT_COMMITTER_DATE="2005-05-26 23:30" \
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
git branch -l d/e/f &&
Test that git-branch -l works. 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>
2006-05-25 05:34:04 +02:00
test -f .git/refs/heads/d/e/f &&
test -f .git/logs/refs/heads/d/e/f &&
diff expect .git/logs/refs/heads/d/e/f'
test_expect_success \
'git branch -d d/e/f should delete a branch and a log' \
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
'git branch -d d/e/f &&
Test that git-branch -l works. 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>
2006-05-25 05:34:04 +02:00
test ! -f .git/refs/heads/d/e/f &&
test ! -f .git/logs/refs/heads/d/e/f'
Remove empty ref directories that prevent creating a ref. 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-09-26 07:23:37 +02:00
test_expect_success \
'git branch j/k should work after branch j has been deleted' \
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
'git branch j &&
git branch -d j &&
git branch j/k'
Remove empty ref directories that prevent creating a ref. 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-09-26 07:23:37 +02:00
test_expect_success \
'git branch l should work after branch l/m has been deleted' \
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
'git branch l/m &&
git branch -d l/m &&
git branch l'
Remove empty ref directories that prevent creating a ref. 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-09-26 07:23:37 +02:00
git-branch: add options and tests for branch renaming 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-11-28 15:47:40 +01:00
test_expect_success \
'git branch -m m m/m should work' \
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
'git branch -l m &&
git branch -m m m/m &&
git-branch: add options and tests for branch renaming 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-11-28 15:47:40 +01:00
test -f .git/logs/refs/heads/m/m'
test_expect_success \
'git branch -m n/n n should work' \
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
'git branch -l n/n &&
git branch -m n/n n
git-branch: add options and tests for branch renaming 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-11-28 15:47:40 +01:00
test -f .git/logs/refs/heads/n'
Sane use of test_expect_failure 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>
2008-02-01 10:50:53 +01:00
test_expect_success 'git branch -m o/o o should fail when o/p exists' '
git branch o/o &&
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
git branch o/p &&
Sane use of test_expect_failure 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>
2008-02-01 10:50:53 +01:00
! git branch -m o/o o
'
git-branch: add options and tests for branch renaming 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-11-28 15:47:40 +01:00
Sane use of test_expect_failure 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>
2008-02-01 10:50:53 +01:00
test_expect_success 'git branch -m q r/q should fail when r exists' '
git branch q &&
git branch r &&
! git branch -m q r/q
'
git-branch: add options and tests for branch renaming 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-11-28 15:47:40 +01:00
Fix renaming branch without config file 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-04-05 16:20:55 +02:00
mv .git/config .git/config-saved
Distinguish branches by more than case in tests. 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-06 07:42:04 +02:00
test_expect_success 'git branch -m q q2 without config should succeed' '
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
git branch -m q q2 &&
git branch -m q2 q
Fix renaming branch without config file 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-04-05 16:20:55 +02:00
'
mv .git/config-saved .git/config
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
git config branch.s/s.dummy Hello
git-branch: rename config vars branch.<branch>.*, too 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-16 15:15:02 +01:00
git-branch: add options and tests for branch renaming 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-11-28 15:47:40 +01:00
test_expect_success \
'git branch -m s/s s should work when s/t is deleted' \
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
'git branch -l s/s &&
git-branch: add options and tests for branch renaming 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-11-28 15:47:40 +01:00
test -f .git/logs/refs/heads/s/s &&
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
git branch -l s/t &&
git-branch: add options and tests for branch renaming 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-11-28 15:47:40 +01:00
test -f .git/logs/refs/heads/s/t &&
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
git branch -d s/t &&
git branch -m s/s s &&
git-branch: add options and tests for branch renaming 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-11-28 15:47:40 +01:00
test -f .git/logs/refs/heads/s'
git-branch: rename config vars branch.<branch>.*, too 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-16 15:15:02 +01:00
test_expect_success 'config information was renamed, too' \
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
"test $(git config branch.s.dummy) = Hello &&
! git config branch.s/s/dummy"
git-branch: rename config vars branch.<branch>.*, too 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-16 15:15:02 +01:00
Sane use of test_expect_failure 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>
2008-02-01 10:50:53 +01:00
test_expect_success \
'git branch -m u v should fail when the reflog for u is a symlink' '
git branch -l u &&
rename_ref: use lstat(2) when testing for symlink 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-11-29 21:44:56 +01:00
mv .git/logs/refs/heads/u real-u &&
ln -s real-u .git/logs/refs/heads/u &&
Sane use of test_expect_failure 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>
2008-02-01 10:50:53 +01:00
! git branch -m u v
'
rename_ref: use lstat(2) when testing for symlink 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-11-29 21:44:56 +01:00
git-branch, git-checkout: autosetup for remote branch tracking 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-03-08 10:58:35 +01:00
test_expect_success 'test tracking setup via --track' \
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
'git config remote.local.url . &&
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
(git show-ref -q refs/remotes/local/master || git-fetch local) &&
git branch --track my1 local/master &&
test $(git config branch.my1.remote) = local &&
test $(git config branch.my1.merge) = refs/heads/master'
git-branch, git-checkout: autosetup for remote branch tracking 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-03-08 10:58:35 +01:00
test_expect_success 'test tracking setup (non-wildcard, matching)' \
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
'git config remote.local.url . &&
git config remote.local.fetch refs/heads/master:refs/remotes/local/master &&
(git show-ref -q refs/remotes/local/master || git-fetch local) &&
git branch --track my4 local/master &&
test $(git config branch.my4.remote) = local &&
test $(git config branch.my4.merge) = refs/heads/master'
git-branch, git-checkout: autosetup for remote branch tracking 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-03-08 10:58:35 +01:00
test_expect_success 'test tracking setup (non-wildcard, not matching)' \
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
'git config remote.local.url . &&
git config remote.local.fetch refs/heads/s:refs/remotes/local/s &&
(git show-ref -q refs/remotes/local/master || git-fetch local) &&
git branch --track my5 local/master &&
! test "$(git config branch.my5.remote)" = local &&
! test "$(git config branch.my5.merge)" = refs/heads/master'
git-branch, git-checkout: autosetup for remote branch tracking 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-03-08 10:58:35 +01:00
test_expect_success 'test tracking setup via config' \
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
'git config branch.autosetupmerge true &&
git config remote.local.url . &&
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
(git show-ref -q refs/remotes/local/master || git-fetch local) &&
git branch my3 local/master &&
test $(git config branch.my3.remote) = local &&
test $(git config branch.my3.merge) = refs/heads/master'
git-branch, git-checkout: autosetup for remote branch tracking 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-03-08 10:58:35 +01:00
branch --track: code cleanup and saner handling of local branches 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-10 19:50:44 +02:00
test_expect_success 'avoid ambiguous track' '
branch.autosetupmerge: allow boolean values, or "all" 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-08 14:41:21 +02:00
git config branch.autosetupmerge true &&
branch --track: code cleanup and saner handling of local branches 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-10 19:50:44 +02:00
git config remote.ambi1.url = lalala &&
git config remote.ambi1.fetch = refs/heads/lalala:refs/heads/master &&
git config remote.ambi2.url = lilili &&
git config remote.ambi2.fetch = refs/heads/lilili:refs/heads/master &&
branch.autosetupmerge: allow boolean values, or "all" 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-08 14:41:21 +02:00
git branch all1 master &&
branch --track: code cleanup and saner handling of local branches 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-10 19:50:44 +02:00
test -z "$(git config branch.all1.merge)"
branch.autosetupmerge: allow boolean values, or "all" 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-08 14:41:21 +02:00
'
git-branch, git-checkout: autosetup for remote branch tracking 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-03-08 10:58:35 +01:00
test_expect_success 'test overriding tracking setup via --no-track' \
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
'git config branch.autosetupmerge true &&
git config remote.local.url . &&
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
(git show-ref -q refs/remotes/local/master || git-fetch local) &&
git branch --no-track my2 local/master &&
git config branch.autosetupmerge false &&
! test "$(git config branch.my2.remote)" = local &&
! test "$(git config branch.my2.merge)" = refs/heads/master'
git-branch, git-checkout: autosetup for remote branch tracking 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-03-08 10:58:35 +01:00
branch --track: code cleanup and saner handling of local branches 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-10 19:50:44 +02:00
test_expect_success 'no tracking without .fetch entries' \
branch: optionally setup branch.*.merge from upstream local branches "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-19 17:24:37 +01:00
'git config branch.autosetupmerge true &&
git branch my6 s &&
git config branch.automsetupmerge false &&
branch --track: code cleanup and saner handling of local branches 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-10 19:50:44 +02:00
test -z "$(git config branch.my6.remote)" &&
test -z "$(git config branch.my6.merge)"'
git-fetch, git-branch: Support local --track via a special remote '.' 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-15 09:23:20 +01:00
git-branch --track: fix tracking branch computation. 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-06-06 10:10:14 +02:00
test_expect_success 'test tracking setup via --track but deeper' \
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
'git config remote.local.url . &&
git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
(git show-ref -q refs/remotes/local/o/o || git-fetch local) &&
git branch --track my7 local/o/o &&
test "$(git config branch.my7.remote)" = local &&
test "$(git config branch.my7.merge)" = refs/heads/o/o'
git-branch --track: fix tracking branch computation. 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-06-06 10:10:14 +02:00
git-branch: cleanup config file when deleting branches When deleting branches, remove the sections referring to these branches from the config file. Signed-off-by: Gerrit Pape <pape@smarden.org>
2007-06-09 14:40:35 +02:00
test_expect_success 'test deleting branch deletes branch config' \
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
'git branch -d my7 &&
branch --track: code cleanup and saner handling of local branches 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-10 19:50:44 +02:00
test -z "$(git config branch.my7.remote)" &&
test -z "$(git config branch.my7.merge)"'
git-branch: cleanup config file when deleting branches When deleting branches, remove the sections referring to these branches from the config file. Signed-off-by: Gerrit Pape <pape@smarden.org>
2007-06-09 14:40:35 +02:00
test_expect_success 'test deleting branch without config' \
Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03 07:52:14 +02:00
'git branch my7 s &&
test "$(git branch -d my7 2>&1)" = "Deleted branch my7."'
git-branch: cleanup config file when deleting branches When deleting branches, remove the sections referring to these branches from the config file. Signed-off-by: Gerrit Pape <pape@smarden.org>
2007-06-09 14:40:35 +02:00
branch: optionally setup branch.*.merge from upstream local branches "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-19 17:24:37 +01:00
test_expect_success 'test --track without .fetch entries' \
'git branch --track my8 &&
test "$(git config branch.my8.remote)" &&
test "$(git config branch.my8.merge)"'
test_expect_success \
'branch from non-branch HEAD w/autosetupmerge=always' \
'git config branch.autosetupmerge always &&
git branch my9 HEAD^ &&
git config branch.autosetupmerge false'
test_expect_success \
'branch from non-branch HEAD w/--track causes failure' \
'!(git branch --track my10 HEAD^)'
git-branch, git-checkout: autosetup for remote branch tracking 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-03-08 10:58:35 +01:00
# Keep this test last, as it changes the current branch
cat >expect <<EOF
0000000000000000000000000000000000000000 $HEAD $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150200 +0000 branch: Created from master
EOF
test_expect_success \
'git checkout -b g/h/i -l should create a branch and a log' \
'GIT_COMMITTER_DATE="2005-05-26 23:30" \
git-checkout -b g/h/i -l master &&
test -f .git/refs/heads/g/h/i &&
test -f .git/logs/refs/heads/g/h/i &&
diff expect .git/logs/refs/heads/g/h/i'
[PATCH] Do not create bogus branch from flag to git branch 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>
2005-09-08 04:13:26 +02:00
test_done
Copy permalink