summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2013-06-03Merge branch 'kb/status-ignored-optim-2'Libravatar Junio C Hamano1-0/+18
Fix 1.8.3 regressions in the .gitignore path exclusion logic. * kb/status-ignored-optim-2: dir.c: fix ignore processing within not-ignored directories
2013-06-03test: fix post rewrite hook reportLibravatar Felipe Contreras1-2/+2
First expected, then actual. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Acked-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-02Merge branch 'tr/line-log'Libravatar Junio C Hamano17-0/+1646
* tr/line-log: git-log(1): remove --full-line-diff description line-log: fix documentation formatting log -L: improve comments in process_all_files() log -L: store the path instead of a diff_filespec log -L: test merge of parallel modify/rename t4211: pass -M to 'git log -M -L...' test log -L: fix overlapping input ranges log -L: check range set invariants when we look it up Speed up log -L... -M log -L: :pattern:file syntax to find by funcname Implement line-history search (git log -L) Export rewrite_parents() for 'log -L' Refactor parse_loc
2013-06-02Merge branch 'mc/describe-first-parent'Libravatar Junio C Hamano1-0/+3
* mc/describe-first-parent: describe: Add --first-parent option
2013-06-02Merge branch 'rs/tar-tests'Libravatar Junio C Hamano3-78/+92
* rs/tar-tests: t5000: test long filenames t5000: simplify tar-tree tests t5000: use check_tar for prefix test t5000: factor out check_tar t5000, t5003: create directories for extracted files lazily t5000: integrate export-subst tests into regular tests
2013-06-02Merge branch 'jc/strbuf-branchname-fix'Libravatar Junio C Hamano1-2/+13
"git merge @{-1}~22" was rewritten to "git merge frotz@{1}~22" incorrectly when your previous branch was "frotz" (it should be rewritten to "git merge frotz~22" instead). * jc/strbuf-branchname-fix: strbuf_branchname(): do not double-expand @{-1}~22
2013-06-02Merge branch 'jk/fetch-always-update-tracking'Libravatar Junio C Hamano1-4/+30
"git fetch origin master" unlike "git fetch origin" or "git fetch" did not update "refs/remotes/origin/master"; this was an early design decision to keep the update of remote tracking branches predictable, but in practice it turns out that people find it more convenient to opportunisticly update them whenever we have a chance, and we have been updating them when we run "git push" which already breaks the original "predictability" anyway. Now such a fetch does update refs/remotes/origin/master. * jk/fetch-always-update-tracking: fetch: don't try to update unfetched tracking refs fetch: opportunistically update tracking refs refactor "ref->merge" flag fetch/pull doc: untangle meaning of bare <ref> t5510: start tracking-ref tests from a known state
2013-06-02Merge branch 'mk/combine-diff-context-horizon-fix'Libravatar Junio C Hamano1-0/+48
"git diff -c -p" was not showing a deleted line from a hunk when another hunk immediately begins where the earlier one ends. * mk/combine-diff-context-horizon-fix: combine-diff.c: Fix output when changes are exactly 3 lines apart
2013-06-02Merge branch 'kb/ancestry-path-threedots'Libravatar Junio C Hamano1-1/+20
"git log --ancestry-path A...B" did not work as expected, as it did not pay attention to the fact that the merge base between A and B was the bottom of the range being specified. * kb/ancestry-path-threedots: revision.c: treat A...B merge bases as if manually specified t6019: demonstrate --ancestry-path A...B breakage
2013-06-02Merge branch 'jc/t5551-posix-sed-bre'Libravatar Junio C Hamano1-2/+6
POSIX fix for a test script. * jc/t5551-posix-sed-bre: t5551: do not use unportable sed '\+'
2013-06-02Merge branch 'nd/clone-local-with-colon'Libravatar Junio C Hamano1-0/+5
"git clone foo/bar:baz" cannot be a request to clone from a remote over git-over-ssh specified in the scp style. Detect this case and clone from a local repository at "foo/bar:baz". * nd/clone-local-with-colon: clone: allow cloning local paths with colons in them
2013-06-02Merge branch 'rs/empty-archive'Libravatar Junio C Hamano2-0/+15
Fixes tests added in 1.8.2 era that are broken on BSDs. * rs/empty-archive: t5004: resurrect original empty tar archive test t5004: avoid using tar for checking emptiness of archive
2013-06-02Merge branch 'fc/completion'Libravatar Junio C Hamano1-0/+77
* fc/completion: completion: remove __git_index_file_list_filter() completion: add space after completed filename completion: add hack to enable file mode in bash < 4 completion: refactor __git_complete_index_file() completion: refactor diff_index wrappers completion: use __gitcompadd for __gitcomp_file completion; remove unuseful comments completion: document tilde expansion failure in tests completion: add file completion tests
2013-06-02dir.c: fix ignore processing within not-ignored directoriesLibravatar Karsten Blees1-0/+18
As of 95c6f271 "dir.c: unify is_excluded and is_path_excluded APIs", the is_excluded API no longer recurses into directories that match an ignore pattern, and returns the directory's ignored state for all contained paths. This is OK for normal ignore patterns, i.e. ignoring a directory affects the entire contents recursively. Unfortunately, this also "works" for negated ignore patterns ('!dir'), i.e. the entire contents is "not-ignored" recursively, regardless of ignore patterns that match the contents directly. In prep_exclude, skip recursing into a directory only if it is really ignored (i.e. the ignore pattern is not negated). Signed-off-by: Karsten Blees <blees@dcon.de> Tested-by: Øystein Walle <oystwa@gmail.com> Reviewed-by: Duy Nguyen <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-29Merge branch 'jk/test-output'Libravatar Junio C Hamano3-7/+18
When TEST_OUTPUT_DIRECTORY setting is used, it was handled somewhat inconsistently between the test framework and t/Makefile, and logic to summarize the results looked at a wrong place. * jk/test-output: t/Makefile: don't define TEST_RESULTS_DIRECTORY recursively test output: respect $TEST_OUTPUT_DIRECTORY t/Makefile: fix result handling with TEST_OUTPUT_DIRECTORY
2013-05-29Merge branch 'mh/packed-refs-various'Libravatar Junio C Hamano2-0/+42
Update reading and updating packed-refs file, correcting corner case bugs. * mh/packed-refs-various: (33 commits) refs: handle the main ref_cache specially refs: change do_for_each_*() functions to take ref_cache arguments pack_one_ref(): do some cheap tests before a more expensive one pack_one_ref(): use write_packed_entry() to do the writing pack_one_ref(): use function peel_entry() refs: inline function do_not_prune() pack_refs(): change to use do_for_each_entry() refs: use same lock_file object for both ref-packing functions pack_one_ref(): rename "path" parameter to "refname" pack-refs: merge code from pack-refs.{c,h} into refs.{c,h} pack-refs: rename handle_one_ref() to pack_one_ref() refs: extract a function write_packed_entry() repack_without_ref(): write peeled refs in the rewritten file t3211: demonstrate loss of peeled refs if a packed ref is deleted refs: change how packed refs are deleted search_ref_dir(): return an index rather than a pointer repack_without_ref(): silence errors for dangling packed refs t3210: test for spurious error messages for dangling packed refs refs: change the internal reference-iteration API refs: extract a function peel_entry() ...
2013-05-29Merge branch 'as/check-ignore'Libravatar Junio C Hamano1-52/+110
Enhance "check-ignore" (1.8.2 update) to work more like "check-attr" over bidi-pipes. * as/check-ignore: t0008: use named pipe (FIFO) to test check-ignore streaming Documentation: add caveats about I/O buffering for check-{attr,ignore} check-ignore: allow incremental streaming of queries via --stdin check-ignore: move setup into cmd_check_ignore() check-ignore: add -n / --non-matching option t0008: remove duplicated test fixture data
2013-05-29Merge branch 'jh/checkout-auto-tracking'Libravatar Junio C Hamano4-5/+173
Update "git checkout foo" that DWIMs the intended "upstream" and turns it into "git checkout -t -b foo remotes/origin/foo" to correctly take existing remote definitions into account. The remote "origin" may be what uniquely map its own branch to remotes/some/where/foo but that some/where may not be "origin". * jh/checkout-auto-tracking: glossary: Update and rephrase the definition of a remote-tracking branch branch.c: Validate tracking branches with refspecs instead of refs/remotes/* t9114.2: Don't use --track option against "svn-remote"-tracking branches t7201.24: Add refspec to keep --track working t3200.39: tracking setup should fail if there is no matching refspec. checkout: Use remote refspecs when DWIMming tracking branches t2024: Show failure to use refspec when DWIMming remote branch names t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'
2013-05-29Merge branch 'mh/fetch-into-shallow'Libravatar Junio C Hamano1-0/+14
"git fetch" into a shallow repository from a repository that does not know about the shallow boundary commits (e.g. a different fork from the repository the current shallow repository was cloned from) did not work correctly. * mh/fetch-into-shallow: t5500: add test for fetching with an unknown 'shallow' upload-pack: ignore 'shallow' lines with unknown obj-ids
2013-05-29Merge branch 'js/transport-helper-error-reporting-fix'Libravatar Junio C Hamano1-5/+0
Finishing touches to fc/transport-helper-error-reporting topic. * js/transport-helper-error-reporting-fix: git-remote-testgit: build it to run under $SHELL_PATH git-remote-testgit: further remove some bashisms git-remote-testgit: avoid process substitution
2013-05-29Merge branch 'fc/transport-helper-error-reporting'Libravatar Junio C Hamano1-20/+55
Update transport helper to report errors and maintain ref hierarchy used to keep track of remote helper state better. * fc/transport-helper-error-reporting: transport-helper: fix remote helper namespace regression test: remote-helper: add missing and t5801: "VAR=VAL shell_func args" is forbidden transport-helper: update remote helper namespace transport-helper: trivial code shuffle transport-helper: warn when refspec is not used transport-helper: clarify pushing without refspecs transport-helper: update refspec documentation transport-helper: clarify *:* refspec transport-helper: improve push messages transport-helper: mention helper name when it dies transport-helper: report errors properly
2013-05-28fetch: don't try to update unfetched tracking refsLibravatar John Keeping1-0/+16
Since commit f269048 (fetch: opportunistically update tracking refs, 2013-05-11) we update tracking refs opportunistically when fetching remote branches. However, if there is a configured non-pattern refspec that does not match any of the refspecs given on the command line then a fatal error occurs. Fix this by setting the "missing_ok" flag when calling get_fetch_map. Test-added-by: Jeff King <peff@peff.net> Signed-off-by: John Keeping <john@keeping.me.uk> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-20t5000: test long filenamesLibravatar René Scharfe2-0/+46
Add a file with a long name to the test archive in order to check entries with pax extended headers. Also add a check for tar versions that doen't understand this format. Those versions should extract the headers as a regular files. Add code to check_tar() to interpret the path header if present, so that our tests work even with those tar versions. It's important to use the fallback code only if needed to still be able to detect git archive errorously creating pax headers as regular file entries (with a suitable tar version, of course). The archive used to check for pax header support in tar was generated using GNU tar 1.26 and its option --format=pax. Tested successfully on NetBSD 6.1, which has a tar version lacking pax header support. Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-20t5000: simplify tar-tree testsLibravatar René Scharfe1-23/+8
Just compare the archives created by git tar-tree with the ones created using git archive with the equivalent options, whose contents are checked already, instead of extracting them again. Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-20t5000: use check_tar for prefix testLibravatar René Scharfe1-12/+12
Perform the full range of checks against all archived files instead of looking only at the file type of a few of them. Also add a test of a git archive with a prefix ending in with a slash, i.e. adding a full directory level. Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-20t5000: factor out check_tarLibravatar René Scharfe1-13/+22
Create a helper function that extracts a tar archive and checks its contents, modelled after check_zip in t5003. Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-20t5000, t5003: create directories for extracted files lazilyLibravatar René Scharfe2-4/+4
Create the directories b and c just before they are needed instead of up front. For t5003 it turns out we don't need them at all. For t5000 it makes the coming modifications easier. Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-20t5000: integrate export-subst tests into regular testsLibravatar René Scharfe1-32/+6
Instead of creating extra archives for testing substitutions, set the attribute export-subst and overwrite the marked file with the expected (expanded) content right between committing and archiving. Thus placeholder expansion based on the committed content is performed with each archive creation and the comparison with the contents of directory a yields the correct result. We can then remove the special tests for export-subst. Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-20git-svn: introduce --parents parameter for commands branch and tagLibravatar Tobias Schulte1-0/+48
This parameter is equivalent to the parameter --parents on svn cp commands and is useful for non-standard repository layouts. Signed-off-by: Tobias Schulte <tobias.schulte@gliderpilot.de> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-05-20describe: Add --first-parent optionLibravatar Mike Crowe1-0/+3
Only consider the first parent commit when walking the commit history. This is useful if you only wish to match tags on your branch after a merge. Signed-off-by: Mike Crowe <mac@mcrowe.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-17difftool: fix dir-diff when file does not exist in working treeLibravatar John Keeping1-0/+7
Commit 02c5631 (difftool --dir-diff: symlink all files matching the working tree, 2013-03-14) does not handle the case where a file that is being compared does not exist in the working tree. Fix this by checking for existence explicitly before running git-hash-object. Reported-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-16strbuf_branchname(): do not double-expand @{-1}~22Libravatar Junio C Hamano1-2/+13
If you were on 'frotz' branch before you checked out your current branch, "git merge @{-1}~22" means the same as "git merge frotz~22". The strbuf_branchname() function, when interpret_branch_name() gives up resolving "@{-1}~22" fully, returns "frotz" and tells the caller that it only resolved "@{-1}" part of the input, mistakes this as a total failure, and appends the whole thing to the result, yielding "frotz@{-1}~22", which does not make any sense. Inspect the return value from interpret_branch_name() a bit more carefully. When it errored out without consuming anything, we will get -1 and we should return the whole thing. Otherwise, we should append the remainder (i.e. "~22" in the earlier example) to the partially resolved name (i.e. "frotz"). The test suite adds enough number of checkout to make @{-12} in the last test in t0100 that tried to check "we haven't flipped branches that many times" error case succeed; raise the number to a hundred. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-16revision.c: treat A...B merge bases as if manually specifiedLibravatar Kevin Bracey1-1/+1
The documentation assures users that "A...B" is defined as "A B --not $(git merge-base --all A B)". This wasn't in fact quite true, because the calculated merge bases were not sent to add_rev_cmdline(). The main effect of this was that although git rev-list --ancestry-path A B --not $(git merge-base --all A B) worked, the simpler form git rev-list --ancestry-path A...B failed with a "no bottom commits" error. Other potential users of bottom commits could also be affected by this problem, if they examine revs->cmdline_info; I came across the issue in my proposed history traversal refinements series. So ensure that the calculated merge bases are sent to add_rev_cmdline(), flagged with new 'whence' enum value REV_CMD_MERGE_BASE. Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-15combine-diff.c: Fix output when changes are exactly 3 lines apartLibravatar Matthijs Kooijman1-0/+48
When a deletion is followed by exactly 3 (or whatever the number of context lines) unchanged lines, followed by another change, the combined diff output would hide the first deletion, resulting in a malformed diff. This happened because the 3 lines before each change are painted interesting, but also marked as no_pre_delete to prevent showing deletes that were previously marked as uninteresting. This behaviour was introduced in c86fbe53 (diff -c/--cc: do not include uninteresting deletion before leading context). However, as a side effect, this could also mark deletes that were already interesting as no_pre_delete. This would happen only if the delete was exactly 3 lines away from the next change, since lines farther away would not be touched by the "paint three lines before the change" code and lines closer would be painted by the "merge two adjacent hunks" code instead, which does not set the no_pre_delete flag. This commit fixes this problem by only setting the no_pre_delete flag for changes that were previously uninteresting. Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-13t6019: demonstrate --ancestry-path A...B breakageLibravatar Kevin Bracey1-1/+20
Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-12t5551: do not use unportable sed '\+'Libravatar Junio C Hamano1-2/+6
The set-up step to prepare a repository with 50000 tags used a non-porable '\+' to match one-or-more. The error was not caught because the next test that uses that repository did not even bother to check if these expected tags were actually cloned to the resulting repository. Fix the sed construct to use BRE and update the "clone" test that wanted to test cloning from such a repository with many refs to check the resulting repository. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-12fetch: opportunistically update tracking refsLibravatar Jeff King1-4/+4
When we run a regular "git fetch" without arguments, we update the tracking refs according to the configured refspec. However, when we run "git fetch origin master" (or "git pull origin master"), we do not look at the configured refspecs at all, and just update FETCH_HEAD. We miss an opportunity to update "refs/remotes/origin/master" (or whatever the user has configured). Some users find this confusing, because they would want to do further comparisons against the old state of the remote master, like: $ git pull origin master $ git log HEAD...origin/master In the currnet code, they are comparing against whatever commit happened to be in origin/master from the last time they did a complete "git fetch". This patch will update a ref from the RHS of a configured refspec whenever we happen to be fetching its LHS. That makes the case above work. The downside is that any users who really care about whether and when their tracking branches are updated may be surprised. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-12t5510: start tracking-ref tests from a known stateLibravatar Jeff King1-0/+10
We have three sequential tests for for whether tracking refs are updated by various fetches and pulls; the first two should not update the ref, and the third should. Each test depends on the state left by the test before. This is fragile (a failing early test will confuse later tests), and means we cannot add more "should update" tests after the third one. Let's instead save the initial state before these tests, and then reset to a known state before running each test. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-11Merge git://git.bogomips.org/git-svnLibravatar Junio C Hamano2-1/+149
* git://git.bogomips.org/git-svn: git-svn: added an --include-path flag Git::SVN::*: add missing "NAME" section to perldoc git-svn: avoid self-referencing mergeinfo
2013-05-10transport-helper: fix remote helper namespace regressionLibravatar Felipe Contreras1-0/+14
Commit 664059f (transport-helper: update remote helper namespace) updates the namespace when the push succeeds or not; we should do it only when it succeeded. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-10test: remote-helper: add missing andLibravatar Felipe Contreras1-1/+1
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-09Sync with v1.8.2.3Libravatar Junio C Hamano1-4/+3
* maint: Git 1.8.2.3 t5004: avoid using tar for checking emptiness of archive t5004: ignore pax global header file mergetools/kdiff3: do not use --auto when diffing transport-helper: trivial style cleanup
2013-05-09t5004: avoid using tar for checking emptiness of archiveLibravatar René Scharfe1-3/+2
Test 2 of t5004 checks if a supposedly empty tar archive really contains no files. 24676f02 (t5004: fix issue with empty archive test and bsdtar) removed our commit hash to make it work with bsdtar, but the test still fails on NetBSD and OpenBSD, which use their own tar that considers a tar file containing only NULs as broken. Here's what the different archivers do when asked to create a tar file without entries: $ uname -v NetBSD 6.0.1 (GENERIC) $ gtar --version | head -1 tar (GNU tar) 1.26 $ bsdtar --version bsdtar 2.8.4 - libarchive 2.8.4 $ : >zero.tar $ perl -e 'print "\0" x 10240' >tenk.tar $ sha1 zero.tar tenk.tar SHA1 (zero.tar) = da39a3ee5e6b4b0d3255bfef95601890afd80709 SHA1 (tenk.tar) = 34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c $ : | tar cf - -T - | sha1 da39a3ee5e6b4b0d3255bfef95601890afd80709 $ : | gtar cf - -T - | sha1 34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c $ : | bsdtar cf - -T - | sha1 34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c So NetBSD's native tar creates an empty file, while GNU tar and bsdtar both give us 10KB of NULs -- just like git archive with an empty tree. Now let's see how the archivers handle these two kinds of empty tar files: $ tar tf zero.tar; echo $? tar: Unexpected EOF on archive file 1 $ gtar tf zero.tar; echo $? gtar: This does not look like a tar archive gtar: Exiting with failure status due to previous errors 2 $ bsdtar tf zero.tar; echo $? 0 $ tar tf tenk.tar; echo $? tar: Cannot identify format. Searching... tar: End of archive volume 1 reached tar: Sorry, unable to determine archive format. 1 $ gtar tf tenk.tar; echo $? 0 $ bsdtar tf tenk.tar; echo $? 0 NetBSD's tar complains about both, bsdtar happily accepts any of them and GNU tar doesn't like zero-length archive files. So the safest course of action is to stay with our block-of-NULs format which is compatible with GNU tar and bsdtar, as we can't make NetBSD's native tar happy anyway. We can simplify our test, however, by taking tar out of the picture. Instead of extracting the archive and checking for the non-presence of files, check if the file has a size of 10KB and contains only NULs. This makes t5004 pass on NetBSD and OpenBSD. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-09t5004: resurrect original empty tar archive testLibravatar René Scharfe2-0/+14
Add a test to verify the emptiness of an archive by extracting its contents. Don't run this test if the version of tar doesn't support archives containing only a comment header, though. The existing check 'tar archive of empty tree is empty' used to work like that (minus the tar capability check) but was changed to depend on the exact representation of empty tar files created by git archive instead of on the behaviour of tar in order to avoid issues with different tar versions. The different approaches test different things: The existing one is for empty trees, for which we know the exact expected output and thus we can simply check it without extracting; the new one is for commits with empty trees, whose archives include stamps and so the more "natural" check by extraction is a better fit because it focuses on the interesting aspect, namely the absence of any archive entries. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-09t5004: avoid using tar for checking emptiness of archiveLibravatar René Scharfe1-3/+2
Test 2 of t5004 checks if a supposedly empty tar archive really contains no files. 24676f02 (t5004: fix issue with empty archive test and bsdtar) removed our commit hash to make it work with bsdtar, but the test still fails on NetBSD and OpenBSD, which use their own tar that considers a tar file containing only NULs as broken. Here's what the different archivers do when asked to create a tar file without entries: $ uname -v NetBSD 6.0.1 (GENERIC) $ gtar --version | head -1 tar (GNU tar) 1.26 $ bsdtar --version bsdtar 2.8.4 - libarchive 2.8.4 $ : >zero.tar $ perl -e 'print "\0" x 10240' >tenk.tar $ sha1 zero.tar tenk.tar SHA1 (zero.tar) = da39a3ee5e6b4b0d3255bfef95601890afd80709 SHA1 (tenk.tar) = 34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c $ : | tar cf - -T - | sha1 da39a3ee5e6b4b0d3255bfef95601890afd80709 $ : | gtar cf - -T - | sha1 34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c $ : | bsdtar cf - -T - | sha1 34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c So NetBSD's native tar creates an empty file, while GNU tar and bsdtar both give us 10KB of NULs -- just like git archive with an empty tree. Now let's see how the archivers handle these two kinds of empty tar files: $ tar tf zero.tar; echo $? tar: Unexpected EOF on archive file 1 $ gtar tf zero.tar; echo $? gtar: This does not look like a tar archive gtar: Exiting with failure status due to previous errors 2 $ bsdtar tf zero.tar; echo $? 0 $ tar tf tenk.tar; echo $? tar: Cannot identify format. Searching... tar: End of archive volume 1 reached tar: Sorry, unable to determine archive format. $ gtar tf tenk.tar; echo $? 0 $ bsdtar tf tenk.tar; echo $? 0 NetBSD's tar complains about both, bsdtar happily accepts any of them and GNU tar doesn't like zero-length archive files. So the safest course of action is to stay with our block-of-NULs format which is compatible with GNU tar and bsdtar, as we can't make NetBSD's native tar happy anyway. We can simplify our test, however, by taking tar out of the picture. Instead of extracting the archive and checking for the non-presence of files, check if the file has a size of 10KB and contains only NULs. This makes t5004 pass on NetBSD and OpenBSD. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-09t5004: ignore pax global header fileLibravatar René Scharfe1-1/+1
Versions of tar that don't know pax headers -- like the ones in NetBSD 6 and OpenBSD 5.2 -- extract them as regular files. Explicitly ignore the file created for our global header when checking the list of extracted files, as this is normal and harmless fall-back behaviour. This fixes test 3 of t5004 on these platforms. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-09git-svn: added an --include-path flagLibravatar Paul Walmsley1-0/+149
The SVN::Fetcher module is now able to filter for inclusion as well as exclusion (as used by --ignore-path). Also added tests, documentation changes and git completion script. If you have an SVN repository with many top level directories and you only want a git-svn clone of some of them then using --ignore-path is difficult as it requires a very long regexp. In this case it's much easier to filter for inclusion. [ew: remove trailing whitespace] Signed-off-by: Paul Walmsley <pjwhams@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-05-09git-svn: avoid self-referencing mergeinfoLibravatar Michael Contreras1-1/+0
When svn.pushmergeinfo is set, the target branch is included in the mergeinfo if it was previously merged into one of the source branches. SVN does not do this. Remove merge target branch path from resulting mergeinfo when svn.pushmergeinfo is set to better match the behavior of SVN. Update the svn-mergeinfo-push test. [ew: 80 columns] Signed-off-by: Michael Contreras <michael@inetric.com> Reported-by: Avishay Lavie <avishay.lavie@gmail.com> Acked-by: Eric Wong <normalperson@yhbt.net>
2013-05-07clone: allow cloning local paths with colons in themLibravatar Nguyễn Thái Ngọc Duy1-0/+5
Usually "foo:bar" is interpreted as an ssh url. This patch allows to clone from such paths by putting at least one slash before the colon (i.e. /path/to/foo:bar or just ./foo:bar). file://foo:bar should also work, but local optimizations are off in that case, which may be unwanted. While at there, warn the users about --local being ignored in this case. Reported-by: William Giokas <1007380@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-06Merge branch 'jk/merge-tree-added-identically'Libravatar Junio C Hamano1-0/+51
* jk/merge-tree-added-identically: merge-tree: handle directory/empty conflict correctly