summaryrefslogtreecommitdiff
path: root/t/t5516-fetch-push.sh
AgeCommit message (Collapse)AuthorFilesLines
2008-05-05Fix tests breaking when checkout path contains shell metacharactersLibravatar Bryan Donlan1-3/+3
This fixes the remainder of the issues where the test script itself is at fault for failing when the git checkout path contains whitespace or other shell metacharacters. The majority of git svn tests used the idiom test_expect_success "title" "test script using $svnrepo" These were changed to have the test script in single-quotes: test_expect_success "title" 'test script using "$svnrepo"' which unfortunately makes the patch appear larger than it really is. One consequence of this change is that in the verbose test output the value of $svnrepo (and in some cases other variables, too) is no longer expanded, i.e. previously we saw * expecting success: test script using /path/to/git/t/trash/svnrepo but now it is: * expecting success: test script using "$svnrepo" Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-24push: allow unqualified dest refspecs to DWIMLibravatar Jeff King1-0/+40
Previously, a push like: git push remote src:dst would go through the following steps: 1. check for an unambiguous 'dst' on the remote; if it exists, then push to that ref 2. otherwise, check if 'dst' begins with 'refs/'; if it does, create a new ref 3. otherwise, complain because we don't know where in the refs hierarchy to put 'dst' However, in some cases, we can guess about the ref type of 'dst' based on the ref type of 'src'. Specifically, before complaining we now check: 2.5. if 'src' resolves to a ref starting with refs/heads or refs/tags, then prepend that to 'dst' So now this creates a new branch on the remote, whereas it previously failed with an error message: git push master:newbranch Note that, by design, we limit this DWIM behavior only to source refs which resolve exactly (including symrefs which resolve to existing refs). We still complain on a partial destination refspec if the source is a raw sha1, or a ref expression such as 'master~10'. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-24Merge branch 'maint-1.5.4' into maintLibravatar Junio C Hamano1-13/+1
* maint-1.5.4: t5516: remove ambiguity test (1) Linked glossary from cvs-migration page write-tree: properly detect failure to write tree objects
2008-04-23t5516: remove ambiguity test (1)Libravatar Jeff King1-13/+1
This test tried to push into a remote with ambiguous refs in remotes/$x/master and remotes/$y/master. However, the remote never actually tells us about the refs/remotes hierarchy, so we don't even see this ambiguity. The test happened to pass because we were simply looking for failure, and the test fails for another reason: the dst refspec does not exist and does not begin with refs/, making it invalid. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-12Fix config key miscount in url.*.insteadOfLibravatar Daniel Barkalow1-4/+4
Also tighten test to require it to be correct. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-27Merge branch 'db/push-single-with-HEAD'Libravatar Junio C Hamano1-0/+43
* db/push-single-with-HEAD: Resolve value supplied for no-colon push refspecs
2008-02-24Add support for url aliases in config filesLibravatar Daniel Barkalow1-0/+31
This allows users with different preferences for access methods to the same remote repositories to rewrite each other's URLs by pattern matching across a large set of similiarly set up repositories to each get the desired access. For example, if you don't have a kernel.org account, you might want settings like: [url "git://git.kernel.org/pub/"] insteadOf = master.kernel.org:/pub Then, if you give git a URL like: master.kernel.org:/pub/scm/linux/kernel/git/linville/wireless-2.6.git it will act like you gave it: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git and you can cut-and-paste pull requests in email without fixing them by hand, for example. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-20Resolve value supplied for no-colon push refspecsLibravatar Daniel Barkalow1-0/+43
When pushing a refspec like "HEAD", we used to treat it as "HEAD:HEAD", which didn't work without rewriting. Instead, we should resolve the ref. If it's a symref, further require it to point to a branch, to avoid doing anything especially unexpected. Also remove the rewriting previously added in builtin-push. Since the code for "HEAD" uses the regular refspec parsing, it automatically handles "+HEAD" without anything special. [jc: added a further test to make sure that "remote.*.push = HEAD" works] Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-04Merge branch 'sp/refspec-match'Libravatar Junio C Hamano1-1/+28
* sp/refspec-match: refactor fetch's ref matching to use refname_match() push: use same rules as git-rev-parse to resolve refspecs add refname_match() push: support pushing HEAD to real branch name
2007-11-30receive-pack: allow deletion of corrupt refsLibravatar Johannes Schindelin1-3/+42
Occasionally, in some setups (*cough* forks on repo.or.cz *cough*) some refs go stale, e.g. when the forkee rebased and lost some objects needed by the fork. The quick & dirty way to deal with those refs is to delete them and push them again. However, git-push first would first fetch the current commit name for the ref, would receive a null sha1 since the ref does not point to a valid object, then tell receive-pack that it should delete the ref with this commit name. delete_ref() would be subsequently be called, and check that resolve_ref() (which does _not_ check for validity of the object) returns the same commit name. Which would fail. The proper fix is to avoid corrupting repositories, but in the meantime this is a good fix in any case. Incidentally, some instances of "cd .." in the test cases were fixed, so that subsequent test cases run in t/trash/ irrespective of the outcome of the previous test cases. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-28Revert "t5516: test update of local refs on push"Libravatar Jeff King1-28/+0
This reverts commit 09fba7a59d38d1cafaf33eadaf1d409c4113b30c. These tests are superseded by the ones in t5404 (added in 6fa92bf3 and 8736a848), which are more extensive and better organized. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-18push: use same rules as git-rev-parse to resolve refspecsLibravatar Steffen Prohaska1-1/+11
This commit changes the rules for resolving refspecs to match the rules for resolving refs in rev-parse. git-rev-parse uses clear rules to resolve a short ref to its full name, which are well documented. The rules for resolving refspecs documented in git-send-pack were less strict and harder to understand. This commit replaces them by the rules of git-rev-parse. The unified rules are easier to understand and better resolve ambiguous cases. You can now push from a repository containing several branches ending on the same short name. Note, this may break existing setups. For example, "master" will no longer resolve to "origin/master" even when there is no other "master" elsewhere. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-18push: support pushing HEAD to real branch nameLibravatar Steffen Prohaska1-0/+17
This teaches "push <remote> HEAD" to resolve HEAD on the local side to its real branch name, e.g. master, and then act as if the real branch name was specified. So we have a shorthand for pushing the current branch. Besides HEAD, no other symbolic ref is resolved. Thanks to Daniel Barkalow <barkalow@iabervon.org> for suggesting this implementation, which is much simpler than the implementation proposed before. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-18t5516: test update of local refs on pushLibravatar Jeff King1-0/+28
The first test (updating local refs) should succeed without the prior commit, but the second one (not updating on error) used to fail before the prior commit was written. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-15Add a --dry-run option to git-push.Libravatar Brian Ewins1-0/+10
The default behaviour of git-push is potentially confusing for new users, since it will push changes that are not on the current branch. Publishing patches that were still cooking on a development branch is hard to undo. It would also be nice to be able to verify the expansion of refspecs if you've edited them, so that you know what branches matched on the server. Adding a --dry-run flag allows the user to experiment safely and learn how to use git-push properly. Originally suggested by Steffen Prohaska. Signed-off-by: Brian Ewins <brian.ewins@gmail.com> Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-07-04Fix t5516 to create test repo without hooksLibravatar Alex Riesen1-1/+2
Otherwise the hooks will be executed on cygwin and the test will fail because of the contributed hooks. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-01Fix t5516-fetch for systems where `wc -l` outputs whitespace.Libravatar Brian Gernhardt1-2/+2
When wc outputs whitespace, the test "$(command | wc -l)" = 1 is broken because " 1" != "1". Let the shell eat the whitespace by using test 1 = $(command | wc -l) instead. Signed-off-by: Brian Gernhardt <benji@silverinsanity.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-09remote.c: "git-push frotz" should update what matches at the source.Libravatar Junio C Hamano1-0/+52
Earlier, when the local repository has a branch "frotz" and the remote repository has a tag "frotz" (but not branch "frotz"), "git-push frotz" mistakenly updated the tag at the remote side. This was because the partial refname matching code was applied independently on both source and destination side. With this fix, when a colon-less refspec is given to git-push, we first match it with the refs in the source repository, and update the matching ref in the destination repository. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-09remote.c: fix "git push" weak match disambiguationLibravatar Junio C Hamano1-0/+112
When "git push A:B" is given, and A (or B) is not a full refname that begins with refs/, we require an unambiguous match with an existing ref. For this purpose, a match with a local branch or a tag (i.e. refs/heads/A and refs/tags/A) is called a "strong match", and any other match is called a "weak match". A partial refname is unambiguous when there is only one strong match with any number of weak matches, or when there is only one weak match and no other match. However, as reported by Sparse with Ramsay Jones recently, count_refspec_match() function had a bug where a variable in an inner block masked a different variable of the same name, which caused the weak matches to be ignored. This fixes it, and adds tests for the fix. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-08Test wildcard push/fetchLibravatar Junio C Hamano1-0/+82
Signed-off-by: Junio C Hamano <gitster@pobox.com>