summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2010-04-19receive-pack: detect aliased updates which can occur with symrefsLibravatar Jay Soffian1-0/+49
When pushing to a remote repo the sending side filters out aliased updates (e.g., foo:baz bar:baz). However, it is not possible for the sender to know if two refs are aliased on the receiving side via symrefs. Here is one such scenario: $ git init origin $ (cd origin && touch file && git add file && git commit -a -m intial) $ git clone --bare origin origin.git $ rm -rf origin $ git clone origin.git client $ git clone --mirror client backup.git && $ (cd backup.git && git remote set-head origin --auto) $ (cd client && git remote add --mirror backup ../backup.git && echo change1 > file && git commit -a -m change1 && git push origin && git push backup ) The push to backup fails with: Counting objects: 5, done. Writing objects: 100% (3/3), 244 bytes, done. Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. error: Ref refs/remotes/origin/master is at ef3... but expected 262... remote: error: failed to lock refs/remotes/origin/master To ../backup.git 262cd57..ef307ff master -> master 262cd57..ef307ff origin/HEAD -> origin/HEAD ! [remote rejected] origin/master -> origin/master (failed to lock) error: failed to push some refs to '../backup.git' The reason is that refs/remotes/origin/HEAD is a symref to refs/remotes/origin/master, but it is not possible for the sending side to unambiguously know this. This commit fixes the issue by having receive-pack ignore any update to a symref whose target is being identically updated. If a symref and its target are being updated inconsistently, then the update for both fails with an error message ("refusing inconsistent update...") to help diagnose the situation. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-09Merge branch 'ef/maint-empty-commit-log' into maintLibravatar Junio C Hamano1-0/+9
* ef/maint-empty-commit-log: rev-list: fix --pretty=oneline with empty message
2010-04-09Merge branch 'jc/conflict-marker-size' into maintLibravatar Junio C Hamano1-1/+22
* jc/conflict-marker-size: diff --check: honor conflict-marker-size attribute
2010-03-31Merge branch 'jc/maint-refs-dangling' into maintLibravatar Junio C Hamano1-3/+3
* jc/maint-refs-dangling: refs: ref entry with NULL sha1 is can be a dangling symref
2010-03-29format-patch: Squelch 'fatal: Not a range." errorLibravatar Kevin Ballard1-0/+4
Don't output an error on `git format-patch --ignore-if-in-upstream HEAD`. This matches the behavior of `git format-patch HEAD`. Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-28Merge branch 'cp/add-u-pathspec' into maintLibravatar Junio C Hamano2-0/+10
* cp/add-u-pathspec: test for add with non-existent pathspec git add -u: die on unmatched pathspec
2010-03-28t9350: fix careless use of "cd"Libravatar Junio C Hamano1-33/+38
Upon failure of any of these tests (or when a test that is marked as expecting a failure is fixed), we will end up running later tests in random places. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-28difftool: Fix '--gui' when diff.guitool is unconfiguredLibravatar David Aguilar1-0/+9
When diff.guitool is unconfigured and "--gui" is specified git-difftool dies with the following error message: config diff.guitool: command returned error: 1 Catch the error so that the "--gui" flag is a no-op when diff.guitool is unconfigured. Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-24diff --check: honor conflict-marker-size attributeLibravatar Junio C Hamano1-1/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-24Merge branch 'jc/color-attrs' into maintLibravatar Junio C Hamano1-4/+11
* jc/color-attrs: color: allow multiple attributes
2010-03-24Merge branch 'jk/maint-add-ignored-dir' into maintLibravatar Junio C Hamano2-2/+85
* jk/maint-add-ignored-dir: tests for "git add ignored-dir/file" without -f dir: fix COLLECT_IGNORED on excluded prefixes t0050: mark non-working test as such
2010-03-24Merge branch 'bg/apply-fix-blank-at-eof' into maintLibravatar Junio C Hamano3-0/+305
* bg/apply-fix-blank-at-eof: t3417: Add test cases for "rebase --whitespace=fix" t4124: Add additional tests of --whitespace=fix apply: Allow blank context lines to match beyond EOF apply: Remove the quick rejection test apply: Don't unnecessarily update line lengths in the preimage
2010-03-21rev-list: fix --pretty=oneline with empty messageLibravatar Erik Faye-Lund1-0/+9
55246aa (Dont use "<unknown>" for placeholders and suppress printing of empty user formats) introduced a check to prevent empty user-formats from being printed. This test didn't take empty commit messages into account, and prevented the line-termination from being output. This lead to multiple commits on a single line. Correct it by guarding the check with a check for user-format. A similar correction for the --graph code-path has been included. Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-15refs: ref entry with NULL sha1 is can be a dangling symrefLibravatar Junio C Hamano1-3/+3
Brandon Casey noticed that t5505 had accidentally broken its && chain, hiding inconsistency between the code that writes the warning to the standard output and the test that expects to see the warning on the standard error, which was introduced by f8948e2 (remote prune: warn dangling symrefs, 2009-02-08). It turns out that the issue is deeper than that. After f8948e2, a symref that is dangling is marked with a NULL sha1, and the idea of using NULL sha1 to mean a deleted ref was scrapped, but somehow a follow-up eafb452 (do_one_ref(): null_sha1 check is not about broken ref, 2009-07-22) incorrectly reorganized do_one_ref(), still thinking NULL sha1 is never used in the code. Fix this by: - adopt Brandon's fix to t5505 test; - introduce REF_BROKEN flag to mark a ref that fails to resolve (dangling symref); - move the check for broken ref back inside the "if we are skipping dangling refs" code block. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-13tests for "git add ignored-dir/file" without -fLibravatar Junio C Hamano1-0/+79
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-13t0050: mark non-working test as suchLibravatar Junio C Hamano1-2/+6
The test is to prepare an empty file "camelcase" in the index, remove and replace it with another file "CamelCase" with "1" as its contents in the working tree, and add it to the index, in a repository configured to be case insensitive. However, the test actually checked ls-files knows about a pathname that matches "camelcase" case insensitively. It didn't check if the added contents actually was the updated one. Mark the test as non-working. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-13don't use default revision if a rev was specifiedLibravatar Dave Olszewski1-0/+9
If a revision is specified, it happens not to have any commits, don't use the default revision. By doing so, surprising and undesired behavior can happen, such as showing the reflog for HEAD when a branch was specified. [jc: squashed a test from René] Signed-off-by: Dave Olszewski <cxreg@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-13t/Makefile: remove test artifacts upon "make clean"Libravatar Junio C Hamano1-0/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-13blame: fix indent of line numbersLibravatar René Scharfe1-1/+19
Correct the calculation of the number of digits for line counts of the form 10^n-1 (9, 99, ...) in lineno_width(). This makes blame stop printing an extra space before the line numbers of files with that many total lines. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-11t9400: Use test_cmp when appropriateLibravatar Junio C Hamano1-12/+12
Consistently using test_cmp would make debugging test scripts far easier, as output from them run under "-v" option becomes readable. Besides, some platforms' "diff" implementations lack "-q" option. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-08Merge branch 'as/maint-expire' into maintLibravatar Junio C Hamano2-0/+73
* as/maint-expire: reflog: honor gc.reflogexpire=never prune: honor --expire=never
2010-03-08Merge branch 'jc/fetch-param' into maintLibravatar Junio C Hamano1-26/+59
* jc/fetch-param: fetch --all/--multiple: keep all the fetched branch information builtin-fetch --all/--multi: propagate options correctly t5521: fix and modernize
2010-03-08Merge branch 'jk/maint-add--interactive-delete' into maintLibravatar Junio C Hamano1-0/+8
* jk/maint-add--interactive-delete: add-interactive: fix bogus diff header line ordering
2010-03-08Merge branch 'mm/mkstemps-mode-for-packfiles' into maintLibravatar Junio C Hamano1-0/+67
* mm/mkstemps-mode-for-packfiles: Use git_mkstemp_mode instead of plain mkstemp to create object files git_mkstemps_mode: don't set errno to EINVAL on exit. Use git_mkstemp_mode and xmkstemp_mode in odb_mkstemp, not chmod later. git_mkstemp_mode, xmkstemp_mode: variants of gitmkstemps with mode argument. Move gitmkstemps to path.c Add a testcase for ACL with restrictive umask.
2010-03-08Merge branch 'jc/maint-fix-mailinfo-strip' into maintLibravatar Junio C Hamano1-1/+1
* jc/maint-fix-mailinfo-strip: mailinfo: do not strip leading spaces even for a header line
2010-03-08Merge branch 'jc/grep-author-all-match-implicit' into maintLibravatar Junio C Hamano1-1/+9
* jc/grep-author-all-match-implicit: "log --author=me --grep=it" should find intersection, not union
2010-03-08Merge branch 'jc/checkout-detached' into maintLibravatar Junio C Hamano1-10/+22
* jc/checkout-detached: Reword "detached HEAD" notification
2010-03-07color: allow multiple attributesLibravatar Junio C Hamano1-4/+11
In configuration files (and "git config --color" command line), we supported one and only one attribute after foreground and background color. Accept combinations of attributes, e.g. [diff.color] old = red reverse bold Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-07unset GREP_OPTIONS in test-lib.shLibravatar Bert Wesarg1-0/+2
I used to set GREP_OPTIONS to exclude *.orig and *.rej files. But with this the test t4252-am-options.sh fails because it calls grep with a .rej file: grep "@@ -1,3 +1,3 @@" file-2.rej Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-06t3417: Add test cases for "rebase --whitespace=fix"Libravatar Björn Gustavsson1-0/+126
The command "git rebase --whitespace=fix HEAD~<N>" is supposed to only clean up trailing whitespace, and the expectation is that it cannot fail. Unfortunately, if one commit adds a blank line at the end of a file and a subsequent commit adds more non-blank lines after the blank line, "git apply" (used indirectly by "git rebase") will fail to apply the patch of the second commit. Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-06t4124: Add additional tests of --whitespace=fixLibravatar Björn Gustavsson1-0/+170
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-06apply: Remove the quick rejection testLibravatar Björn Gustavsson1-0/+9
In the next commit, we will make it possible for blank context lines to match beyond the end of the file. That means that a hunk with a preimage that has more lines than present in the file may be possible to successfully apply. Therefore, we must remove the quick rejection test in find_pos(). find_pos() will already work correctly without the quick rejection test, but that might not be obvious. Therefore, comment the test for handling out-of-range line numbers in find_pos() and cast the "line" variable to the same (unsigned) type as img->nr. What are performance implications of removing the quick rejection test? It can only help "git apply" to reject a patch faster. For example, if I have a file with one million lines and a patch that removes slightly more than 50 percent of the lines and try to apply that patch twice, the second attempt will fail slightly faster with the test than without (based on actual measurements). However, there is the pathological case of a patch with many more context lines than the default three, and applying that patch using "git apply -C1". Without the rejection test, the running time will be roughly proportional to the number of context lines times the size of the file. That could be handled by writing a more complicated rejection test (it would have to count the number of blanks at the end of the preimage), but I don't find that worth doing until there is a real-world use case that would benfit from it. It would be possible to keep the quick rejection test if --whitespace=fix is not given, but I don't like that from a testing point of view. Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-06t7406: Fix submodule init config testsLibravatar Stephen Boyd1-8/+16
These tests have been broken since they were introduced in commits ca2cedb (git-submodule: add support for --rebase., 2009-04-24) and 42b4917 (git-submodule: add support for --merge., 2009-06-03). 'git submodule init' expects the submodules to exist in the index. In this case, the submodules don't exist and therefore looking for the submodules will always fail. To make matters worse, git submodule fails visibly to the user by saying: error: pathspec 'rebasing' did not match any file(s) known to git. Did you forget to 'git add'? but doesn't return an error code. This allows the test to fail silently. Fix it by adding the submodules first. Cc: Johan Herland <johan@herland.net> Cc: Peter Hutterer <peter.hutterer@who-t.net> Cc: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-04Merge branch 'jn/maint-fix-pager' into maintLibravatar Junio C Hamano2-0/+234
* jn/maint-fix-pager: tests: Fix race condition in t7006-pager t7006-pager: if stdout is not a terminal, make a new one tests: Add tests for automatic use of pager am: Fix launching of pager git svn: Fix launching of pager git.1: Clarify the behavior of the --paginate option Make 'git var GIT_PAGER' always print the configured pager Fix 'git var' usage synopsis
2010-03-04Merge branch 'ld/maint-diff-quiet-w' into maintLibravatar Junio C Hamano1-0/+15
* ld/maint-diff-quiet-w: git-diff: add a test for git diff --quiet -w git diff --quiet -w: check and report the status
2010-03-04Merge branch 'cc/maint-bisect-paths' into maintLibravatar Junio C Hamano1-0/+5
* cc/maint-bisect-paths: bisect: error out when passing bad path parameters
2010-03-02Merge branch 'sp/maint-push-sideband' into maintLibravatar Junio C Hamano1-42/+42
* sp/maint-push-sideband: receive-pack: Send internal errors over side-band #2 t5401: Use a bare repository for the remote peer receive-pack: Send hook output over side band #2 receive-pack: Wrap status reports inside side-band-64k receive-pack: Refactor how capabilities are shown to the client send-pack: demultiplex a sideband stream with status data run-command: support custom fd-set in async run-command: Allow stderr to be a caller supplied pipe Conflicts: builtin-receive-pack.c run-command.c t/t5401-update-hooks.sh
2010-03-02Merge branch 'jc/maint-fix-test-perm' into maintLibravatar Junio C Hamano2-0/+4
* jc/maint-fix-test-perm: lib-patch-mode.sh: Fix permission t6000lib: Fix permission
2010-03-02gitweb: Fix project-specific feature override behaviorLibravatar Jakub Narebski1-5/+13
This commit fixes a bug in processing project-specific override in a situation when there is no project, e.g. for the projects list page. When 'snapshot' feature had project specific config override enabled by putting $feature{'snapshot'}{'override'} = 1; (or equivalent) in $GITWEB_CONFIG, and when viewing toplevel gitweb page, which means the projects list page (to be more exact this happens for any project-less action), gitweb would put the following Perl warnings in error log: gitweb.cgi: Use of uninitialized value $git_dir in concatenation (.) or string at gitweb.cgi line 2065. fatal: error processing config file(s) gitweb.cgi: Use of uninitialized value $git_dir in concatenation (.) or string at gitweb.cgi line 2221. gitweb.cgi: Use of uninitialized value $git_dir in concatenation (.) or string at gitweb.cgi line 2218. The problem is in the following fragment of code: # path to the current git repository our $git_dir; $git_dir = "$projectroot/$project" if $project; # list of supported snapshot formats our @snapshot_fmts = gitweb_get_feature('snapshot'); @snapshot_fmts = filter_snapshot_fmts(@snapshot_fmts); For the toplevel gitweb page, which is the list of projects, $project is not defined, therefore neither is $git_dir. gitweb_get_feature() subroutine calls git_get_project_config() if project specific override is turned on... but we don't have project here. Those errors mentioned above occur in the following fragment of code in git_get_project_config(): # get config if (!defined $config_file || $config_file ne "$git_dir/config") { %config = git_parse_project_config('gitweb'); $config_file = "$git_dir/config"; } git_parse_project_config() calls git_cmd() which has '--git-dir='.$git_dir There are (at least) three possible solutions: 1. Harden gitweb_get_feature() so that it doesn't call git_get_project_config() if $project (and therefore $git_dir) is not defined; there is no project for project specific config. 2. Harden git_get_project_config() like you did in your fix, returning early if $git_dir is not defined. 3. Harden git_cmd() so that it doesn't add "--git-dir=$git_dir" if $git_dir is not defined, and change git_get_project_config() so that it doesn't even try to access $git_dir if it is not defined. This commit implements both 1.) and 2.), i.e. gitweb_get_feature() doesn't call project-specific override if $git_dir is not defined (if there is no project), and git_get_project_config() returns early if $git_dir is not defined. Add a test for this bug to t/t9500-gitweb-standalone-no-errors.sh test. Reported-by: Eli Barzilay <eli@barzilay.org> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-01bisect: error out when passing bad path parametersLibravatar Christian Couder1-0/+5
As reported by Mark Lodato, "git bisect", when it was started with path parameters that match no commit was kind of working without taking account of path parameters and was reporting something like: Bisecting: -1 revisions left to test after this (roughly 0 steps) It is more correct and safer to just error out in this case, before displaying the revisions left, so this patch does just that. Note that this bug is very old, it exists at least since v1.5.5. And it is possible to detect that case earlier in the bisect algorithm, but it is not clear that it would be an improvement to error out earlier, on the contrary it may change the behavior of "git rev-list --bisect-all" for example, which is currently correct. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-28reflog: honor gc.reflogexpire=neverLibravatar Adam Simpkins1-0/+41
Previously, if gc.reflogexpire or gc.reflogexpire were set to "never" or "false", the builtin default values were used instead. Signed-off-by: Adam Simpkins <simpkins@facebook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-28prune: honor --expire=neverLibravatar Adam Simpkins1-0/+32
Previously, prune treated an expiration time of 0 to mean that no expire argument was supplied, and everything should be pruned. As a result, "prune --expire=never" would prune all unreachable objects, regardless of their timestamp. prune can be called with --expire=never automatically by gc, when the gc.pruneExpire configuration is set to "never". Signed-off-by: Adam Simpkins <simpkins@facebook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-25Merge branch 'maint-1.6.6' into maintLibravatar Junio C Hamano1-0/+1
* maint-1.6.6: t3301-notes: insert a shbang line in ./fake_editor.sh
2010-02-25t3301-notes: insert a shbang line in ./fake_editor.shLibravatar Johannes Sixt1-0/+1
This is required on Windows because git-notes is now a built-in rather than a shell script. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-24fetch --all/--multiple: keep all the fetched branch informationLibravatar Junio C Hamano1-0/+18
Since "git fetch" learned "--all" and "--multiple" options, it has become tempting for users to say "git pull --all". Even though it may fetch from remotes that do not need to be fetched from for merging with the current branch, it is handy. "git fetch" however clears the list of fetched branches every time it contacts a different remote. Unless the current branch is configured to merge with a branch from a remote that happens to be the last in the list of remotes that are contacted, "git pull" that fetches from multiple remotes will not be able to find the branch it should be merging with. Make "fetch" clear FETCH_HEAD (unless --append is given) and then append the list of branches fetched to it (even when --append is not given). That way, "pull" will be able to find the data for the branch being merged in FETCH_HEAD no matter where the remote appears in the list of remotes to be contacted by "git fetch". Reported-by: Michael Lukashov Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-24builtin-fetch --all/--multi: propagate options correctlyLibravatar Junio C Hamano1-0/+21
When running a subfetch, the code propagated some options but not others. Propagate --force, --update-head-ok and --keep options as well. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-24t5521: fix and modernizeLibravatar Junio C Hamano1-26/+20
All of these tests were bogus, as they created new directory and tried to run "git pull" without even running "git init" in there. They were mucking with the repository in $TEST_DIRECTORY. While fixing it, modernize the style not to chdir around outside of subshell. Otherwise a failed test will take us to an unexpected directory and we need to chdir back to the test directory in each test, which is ugly and error prone. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-22add-interactive: fix bogus diff header line orderingLibravatar Jeff King1-0/+8
When we look at a patch for adding hunks interactively, we first split it into a header and a list of hunks. Some of the header lines, such as mode changes and deletion, however, become their own selectable hunks. Later when we reassemble the patch, we simply concatenate the header and the selected hunks. This leads to patches like this: diff --git a/file b/file index d95f3ad..0000000 --- a/file +++ /dev/null deleted file mode 100644 @@ -1 +0,0 @@ -content Notice how the deletion comes _after_ the ---/+++ lines, when it should come before. In many cases, we can get away with this as git-apply accepts the slightly bogus input. However, in the specific case of a deletion line that is being applied via "apply -R", this malformed patch triggers an assert in git-apply. This comes up when discarding a deletion via "git checkout -p". Rather than try to make git-apply accept our odd input, let's just reassemble the patch in the correct order. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-22Use git_mkstemp_mode instead of plain mkstemp to create object filesLibravatar Matthieu Moy1-1/+1
We used to unnecessarily give the read permission to group and others, regardless of the umask, which isn't serious because the objects are still protected by their containing directory, but isn't necessary either. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-22Use git_mkstemp_mode and xmkstemp_mode in odb_mkstemp, not chmod later.Libravatar Matthieu Moy1-1/+1
We used to create 0600 files, and then use chmod to set the group and other permission bits to the umask. This usually has the same effect as a normal file creation with a umask. But in the presence of ACLs, the group permission plays the role of the ACL mask: the "g" bits of newly created files are chosen according to default ACL mask of the directory, not according to the umask, and doing a chmod() on these "g" bits affect the ACL's mask instead of actual group permission. In other words, creating files with 0600 and then doing a chmod to the umask creates files which are unreadable by users allowed in the default ACL. To create the files without breaking ACLs, we let the umask do it's job at the file's creation time, and get rid of the later chmod. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>