summaryrefslogtreecommitdiff
path: root/t/t3200-branch.sh
AgeCommit message (Collapse)AuthorFilesLines
2012-02-05branch --edit-description: protect against mistyped branch nameLibravatar Junio C Hamano1-4/+37
It is very easy to mistype the branch name when editing its description, e.g. $ git checkout -b my-topic master : work work work : now we are at a good point to switch working something else $ git checkout master : ah, let's write it down before we forget what we were doing $ git branch --edit-description my-tpoic The command does not notice that branch 'my-tpoic' does not exist. It is not lost (it becomes description of an unborn my-tpoic branch), but is not very useful. So detect such a case and error out to reduce the grief factor from this common mistake. This incidentally also errors out --edit-description when the HEAD points at an unborn branch (immediately after "init", or "checkout --orphan"), because at that point, you do not even have any commit that is part of your history and there is no point in describing how this particular branch is different from the branch it forked off of, which is the useful bit of information the branch description is designed to capture. We may want to special case the unborn case later, but that is outside the scope of this patch to prevent more common mistakes before 1.7.9 series gains too much widespread use. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-19Merge branch 'rr/test-chaining'Libravatar Junio C Hamano1-2/+2
* rr/test-chaining: t3401: use test_commit in setup t3401: modernize style t3040 (subprojects-basic): fix '&&' chaining, modernize style t1510 (worktree): fix '&&' chaining t3030 (merge-recursive): use test_expect_code test: fix '&&' chaining t3200 (branch): fix '&&' chaining
2011-12-08t3200 (branch): fix '&&' chainingLibravatar Ramkumar Ramachandra1-2/+2
Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Fix these breaks. The 'git branch --help' in the test may fail if git manual pages are not installed, but the point of the test is to make sure it does not create a bogus branch "--help", so run it under 'test_might_fail'. Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-28branch: allow a no-op "branch -M <current-branch> HEAD"Libravatar Jonathan Nieder1-0/+16
Overwriting the current branch with a different commit is forbidden, as it will make the status recorded in the index and the working tree out of sync with respect to the HEAD. There however is no reason to forbid it if the current branch is renamed to itself, which admittedly is something only an insane user would do, but is handy for scripts. Test script is by Conrad Irwin. Reported-by: Soeren Sonnenburg <sonne@debian.org> Reported-by: Josh Chia (谢任中) Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-02t3200: add test case for 'branch -m'Libravatar Stefan Naewe1-0/+5
Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-05Merge branch 'mg/branch-list'Libravatar Junio C Hamano1-16/+48
* mg/branch-list: t3200: clean up checks for file existence branch: -v does not automatically imply --list branch: allow pattern arguments branch: introduce --list option git-branch: introduce missing long forms for the options git-tag: introduce long forms for the options t6040: test branch -vv Conflicts: Documentation/git-tag.txt t/t3200-branch.sh
2011-09-16branch --set-upstream: regression fixLibravatar Junio C Hamano1-0/+13
The "git branch" command, while not in listing mode, calls create_branch() even when the target branch already exists, and it does so even when it is not interested in updating the value of the branch (i.e. the name of the commit object that sits at the tip of the existing branch). This happens when the command is run with "--set-upstream" option. The earlier safety-measure to prevent "git branch -f $branch $commit" from updating the currently checked out branch did not take it into account, and we no longer can update the tracking information of the current branch. Minimally fix this regression by telling the validation code if it is called to really update the value of a potentially existing branch, or if the caller merely is interested in updating auxiliary aspects of a branch. Reported-and-Tested-by: Jay Soffian Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-13t3200: clean up checks for file existenceLibravatar Jeff King1-25/+25
This patch uses test_path_is_file and test_path_is_missing instead of "test -f / ! test -f" checks. The former are more verbose in case of failure and more precise (e.g., is_missing will check that the entry is actually missing, not just not a regular file). As a bonus, this also fixes a few buggy tests that used "test foo" instead of "test -f foo", and consequently always reported success. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-28branch: introduce --list optionLibravatar Michael J Gruber1-0/+32
Currently, there is no way to invoke the list mode explicitly, without giving -v to force verbose output. Introduce a --list option which invokes the list mode. This will be beneficial for invoking list mode with pattern matching, which otherwise would be interpreted as branch creation. Along with --list, test also combinations of existing options. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-22Prevent force-updating of the current branchLibravatar Conrad Irwin1-0/+12
"git branch -M <foo> <current-branch>" allows updating the current branch which HEAD points, without the necessary house-keeping that git reset normally does to make this operation sensible. It also leaves the reflog in a confusing state (you would be warned when trying to read it). "git checkout -B <current branch> <foo>" is also partly vulnerable to this bug; due to inconsistent pre-flight checks it would perform half of its task and then abort just before rewriting the branch. Again this manifested itself as the index file getting out-of-sync with HEAD. "git branch -f" already guarded against this problem, and aborts with a fatal error. Update "git branch -M", "git checkout -B" and "git branch -f" to share the same check before allowing a branch to be created. These prevent you from updating the current branch. We considered suggesting the use of "git reset" in the failure message but concluded that it was not possible to discern what the user was actually trying to do. Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-06Merge branch 'jc/fix-diff-files-unmerged'Libravatar Junio C Hamano1-2/+2
* jc/fix-diff-files-unmerged: diff-files: show unmerged entries correctly diff: remove often unused parameters from diff_unmerge() diff.c: return filepair from diff_unmerge() test: use $_z40 from test-lib
2011-04-23test: use $_z40 from test-libLibravatar Junio C Hamano1-2/+2
There is no need to duplicate the definition of $_z40 and $_x40 that test-lib.sh supplies the test scripts. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-13i18n: use test_i18ngrep in t2020, t2204, t3030, and t3200Libravatar Junio C Hamano1-2/+4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-01Merge branch 'ab/i18n-st'Libravatar Junio C Hamano1-1/+1
* ab/i18n-st: (69 commits) i18n: git-shortlog basic messages i18n: git-revert split up "could not revert/apply" message i18n: git-revert literal "me" messages i18n: git-revert "Your local changes" message i18n: git-revert basic messages i18n: git-notes GIT_NOTES_REWRITE_MODE error message i18n: git-notes basic commands i18n: git-gc "Auto packing the repository" message i18n: git-gc basic messages i18n: git-describe basic messages i18n: git-clean clean.requireForce messages i18n: git-clean basic messages i18n: git-bundle basic messages i18n: git-archive basic messages i18n: git-status "renamed: " message i18n: git-status "Initial commit" message i18n: git-status "Changes to be committed" message i18n: git-status shortstatus messages i18n: git-status "nothing to commit" messages i18n: git-status basic messages ... Conflicts: builtin/branch.c builtin/checkout.c builtin/clone.c builtin/commit.c builtin/grep.c builtin/merge.c builtin/push.c builtin/revert.c t/t3507-cherry-pick-conflict.sh t/t7607-merge-overwrite.sh
2011-03-15Merge branch 'jh/maint-do-not-track-non-branches'Libravatar Junio C Hamano1-0/+14
* jh/maint-do-not-track-non-branches: branch/checkout --track: Ensure that upstream branch is indeed a branch
2011-03-09i18n: git-branch "Deleted branch [...]" messageLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Gettextize the "Deleted %sbranch %s (was %s).\n" messages. test in t3200-branch.sh explicitly checked for this message. Change it to skip under GETTEXT_POISON=YesPlease. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-16branch/checkout --track: Ensure that upstream branch is indeed a branchLibravatar Johan Herland1-0/+14
When creating a new branch using the --track option, we must make sure that we don't try to set an upstream that does not make sense to follow (using 'git pull') or update (using 'git push'). The current code checks against using HEAD as upstream (since tracking a symref doesn't make sense). However, tracking a tag doesn't make sense either. Indeed, tracking _any_ ref that is not a (local or remote) branch doesn't make sense, and should be disallowed. This patch achieves this by checking that the ref we're trying to --track resides within refs/heads/* or refs/remotes/*. This new check replaces the previous check against HEAD. A couple of testcases are also added, verifying that we cannot create branches with tags as upstreams. Finally, some selftests relying on using a non-branch as an upstream have been reworked or removed: - t6040: Reverse the meaning of two tests that depend on the ability to use (lightweight and annotated) tags as upstreams. These two tests were originally added in commits 1be570f and 57ffc5f, and this patch reverts the intention of those two commits. - t7201: Remove part of a test (introduced in 9188ed8) relying on a non-branch as upstream. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-22branch -h: show usage even in an invalid repositoryLibravatar Nguyễn Thái Ngọc Duy1-0/+11
There is no need for "git branch -h" to try to access a repository. In the spirit of v1.6.6-rc0~34^2~3 (Let 'git <command> -h' show usage without a git dir, 2009-11-09). This brings git one step closer to passing the following (automatically verifiable) test: Before any repository access (aside from git_config()), a function from the setup_git_directory_* family has been run and thus one step closer to being able to use an automatic repository access checker. [jn: simplified; new commit message, test] Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-21tests: correct "does reflog exist?" testsLibravatar Junio C Hamano1-10/+3
These two tests weren't about how "git reflog show <branch>" exits when there is no reflog, but were about "checkout" and "branch" create or not create reflog when creating a new <branch>. Update the tests to check what we are interested in, using "git rev-parse --verify". Also lose tests based on "test -f .git/logs/refs/heads/<branch>" from nearby, to avoid exposing this particular implementation detail unnecessarily. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-21t/: work around one-shot variable assignment with test_must_failLibravatar Brandon Casey1-1/+5
See e2007832552ccea9befed9003580c494f09e666e Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-21Merge branch 'gv/portable'Libravatar Junio C Hamano1-2/+2
* gv/portable: test-lib: use DIFF definition from GIT-BUILD-OPTIONS build: propagate $DIFF to scripts Makefile: Tru64 portability fix Makefile: HP-UX 10.20 portability fixes Makefile: HPUX11 portability fixes Makefile: SunOS 5.6 portability fix inline declaration does not work on AIX Allow disabling "inline" Some platforms lack socklen_t type Make NO_{INET_NTOP,INET_PTON} configured independently Makefile: some platforms do not have hstrerror anywhere git-compat-util.h: some platforms with mmap() lack MAP_FAILED definition test_cmp: do not use "diff -u" on platforms that lack one fixup: do not unconditionally disable "diff -u" tests: use "test_cmp", not "diff", when verifying the result Do not use "diff" found on PATH while building and installing enums: omit trailing comma for portability Makefile: -lpthread may still be necessary when libc has only pthread stubs Rewrite dynamic structure initializations to runtime assignment Makefile: pass CPPFLAGS through to fllow customization Conflicts: Makefile wt-status.h
2010-06-03t3200: test -l with core.logAllRefUpdates optionsLibravatar Erick Mattos1-0/+24
By default reflogs are always created for new local branches by "checkout -b". But by setting core.logAllRefUpdates to false this will not be true anymore. In that case you only create the reflogs when you use -l switch with "checkout -b". Added missing tests to check expected behaviors. Signed-off-by: Erick Mattos <erick.mattos@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-31tests: use "test_cmp", not "diff", when verifying the resultLibravatar Gary V. Vaughan1-2/+2
In tests, call test_cmp rather than raw diff where possible (i.e. if the output does not go to a pipe), to allow the use of, say, 'cmp' when the default 'diff -u' is not compatible with a vendor diff. When that is not possible, use $DIFF, as set in GIT-BUILD-OPTIONS. Signed-off-by: Gary V. Vaughan <gary@thewrittenword.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-30branch -d: base the "already-merged" safety on the branch it merges withLibravatar Junio C Hamano1-0/+26
When a branch is marked to merge with another ref (e.g. local 'next' that merges from and pushes back to origin's 'next', with 'branch.next.merge' set to 'refs/heads/next'), it makes little sense to base the "branch -d" safety, whose purpose is not to lose commits that are not merged to other branches, on the current branch. It is much more sensible to check if it is merged with the other branch it merges with. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-26Merge branch 'bc/maint-1.6.1-branch-deleted-was'Libravatar Junio C Hamano1-1/+1
* bc/maint-1.6.1-branch-deleted-was: git-branch: display "was sha1" on branch deletion rather than just "sha1" Conflicts: builtin-branch.c
2009-03-22Use prerequisite tags to skip tests that depend on symbolic linksLibravatar Johannes Sixt1-1/+1
Many tests depend on that symbolic links work. This introduces a check that sets the prerequisite tag SYMLINKS if the file system supports symbolic links. Since so many tests have to check for this prerequisite, we do the check in test-lib.sh, so that we don't need to repeat the test in many scripts. To check for 'ln -s' failures, you can use a FAT partition on Linux: $ mkdosfs -C git-on-fat 1000000 $ sudo mount -o loop,uid=j6t,gid=users,shortname=winnt git-on-fat /mnt Clone git to /mnt and $ GIT_SKIP_TESTS='t0001.1[34] t0010 t1301 t403[34] t4129.[47] t5701.7 t7701.3 t9100 t9101.26 t9119 t9124.[67] t9200.10 t9600.6' \ make test (These additionally skipped tests depend on POSIX permissions that FAT on Linux does not provide.) Signed-off-by: Johannes Sixt <j6t@kdbg.org>
2009-03-21git-branch: display "was sha1" on branch deletion rather than just "sha1"Libravatar Brandon Casey1-1/+1
Make it more pleasant to read about a branch deletion by adding "was". Jeff King suggested this, and I ignored it. He was right. Update t3200 test again to match the change in output. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-12git-branch: display sha1 on branch deletionLibravatar Brandon Casey1-1/+2
Make it easier to recover from a mistaken branch deletion by displaying the sha1 of the branch's tip commit. Update t3200 test to match the change in output. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-30git branch -m: forbid renaming of a symrefLibravatar Miklos Vajna1-4/+4
There may be cases where one would really want to rename the symbolic ref without changing its value, but "git branch -m" is not such a use-case. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-26Fix git branch -m for symrefs.Libravatar Miklos Vajna1-0/+9
This had two problems with symrefs. First, it copied the actual sha1 instead of the "pointer", second it failed to remove the old ref after a successful rename. Given that till now delete_ref() always dereferenced symrefs, a new parameters has been introduced to delete_ref() to allow deleting refs without a dereference. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-03tests: use "git xyzzy" form (t0000 - t3599)Libravatar Nanako Shiraishi1-29/+29
Converts tests between t0050-t3903. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-23t3200,t7201: replace '!' with test_must_failLibravatar Brandon Casey1-1/+1
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-13t/: Use "test_must_fail git" instead of "! git"Libravatar Stephan Beyer1-4/+4
This patch changes every occurrence of "! git" -- with the meaning that a git call has to gracefully fail -- into "test_must_fail git". This is useful to - make sure the test does not fail because of a signal, e.g. SIGSEGV, and - advertise the use of "test_must_fail" for new tests. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>