summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2012-08-29Merge branch 'hv/submodule-path-unmatch'Libravatar Junio C Hamano1-4/+22
* hv/submodule-path-unmatch: Let submodule command exit with error status if path does not exist
2012-08-29Merge branch 'mz/empty-rebase-test'Libravatar Junio C Hamano1-1/+17
* mz/empty-rebase-test: add tests for 'git rebase --keep-empty'
2012-08-27Merge branch 'js/grep-patterntype-config'Libravatar Junio C Hamano1-0/+181
"grep" learned to use a non-standard pattern type by default if a configuration variable tells it to. * js/grep-patterntype-config: grep: add a grep.patternType configuration setting
2012-08-27Merge branch 'bc/receive-pack-stdout-protection'Libravatar Junio C Hamano1-0/+35
When "git push" triggered the automatic gc on the receiving end, a message from "git prune" that said it was removing cruft leaked to the standard output, breaking the communication protocol. * bc/receive-pack-stdout-protection: receive-pack: do not leak output from auto-gc to standard output t/t5400: demonstrate breakage caused by informational message from prune
2012-08-27Merge branch 'ab/diff-write-incomplete-line'Libravatar Junio C Hamano1-0/+30
The output from "git diff -B" for a file that ends with an incomplete line did not put "\ No newline..." on a line of its own. * ab/diff-write-incomplete-line: Fix '\ No newline...' annotation in rewrite diffs
2012-08-27Merge branch 'jc/maint-t7406-rev-parse-max-count-huh'Libravatar Junio C Hamano1-8/+8
Test clean-up, with no behaviour change. * jc/maint-t7406-rev-parse-max-count-huh: t7406: fix misleading "rev-parse --max-count=1 HEAD"
2012-08-27Merge branch 'jk/maint-null-in-trees'Libravatar Junio C Hamano3-0/+128
We do not want a link to 0{40} object stored anywhere in our objects. * jk/maint-null-in-trees: fsck: detect null sha1 in tree entries do not write null sha1s to on-disk index diff: do not use null sha1 as a sentinel value
2012-08-27Merge branch 'mm/push-default-switch-warning'Libravatar Junio C Hamano1-1/+4
In the next major release, we will switch "git push [$there]" that does not say what to push from the traditional "matching" to the updated "simple" semantics, that pushes the current branch to the branch with the same name only when the current branch is set to integrate with that remote branch (all other cases will error out). * mm/push-default-switch-warning: push: start warning upcoming default change for push.default
2012-08-22Merge branch 'tr/maint-send-email-2047'Libravatar Junio C Hamano1-0/+13
"git send-email" did not unquote encoded words that appear on the header correctly, and lost "_" from strings. * tr/maint-send-email-2047: send-email: improve RFC2047 quote parsing
2012-08-22Merge branch 'mk/test-seq'Libravatar Junio C Hamano3-2/+23
Add a compatibility/utility function to the test framework. * mk/test-seq: tests: Introduce test_seq
2012-08-22Merge branch 'jc/test-prereq'Libravatar Junio C Hamano6-205/+233
Teaches the test framework to probe rarely used prerequistes lazily, and make use of it for detecting SYMLINKS, CASE_INSENSITIVE_FS and NKD/NKC MacOS x gotcha. * jc/test-prereq: t3910: use the UTF8_NFD_TO_NFC test prereq test-lib: provide UTF8 behaviour as a prerequisite t0050: use the SYMLINKS test prereq t0050: use the CASE_INSENSITIVE_FS test prereq test-lib: provide case insensitivity as a prerequisite test: allow prerequisite to be evaluated lazily test: rename $satisfied to $satisfied_prereq
2012-08-22Merge branch 'ms/git-svn-1.7'Libravatar Junio C Hamano6-3/+118
A series by Michael Schwern via Eric to update git-svn to revamp the way URLs are internally passed around, to make it work with SVN 1.7. * ms/git-svn-1.7: git-svn: remove ad-hoc canonicalizations git-svn: canonicalize newly-minted URLs git-svn: introduce add_path_to_url function git-svn: canonicalize earlier git-svn: replace URL escapes with canonicalization git-svn: attempt to mimic SVN 1.7 URL canonicalization t9107: fix typo t9118: workaround inconsistency between SVN versions Git::SVN{,::Ra}: canonicalize earlier git-svn: path canonicalization uses SVN API Git::SVN::Utils: remove irrelevant comment git-svn: add join_paths() to safely concatenate paths git-svn: factor out _collapse_dotdot function git-svn: use SVN 1.7 to canonicalize when possible git-svn: move canonicalization to Git::SVN::Utils use Git::SVN{,::RA}->url accessor globally use Git::SVN->path accessor globally Git::SVN::Ra: use accessor for URLs Git::SVN: use accessor for URLs internally Git::SVN: use accessors internally for path
2012-08-22t3910: use the UTF8_NFD_TO_NFC test prereqLibravatar Michael J Gruber1-146/+135
Besides reusing the new test prerequisite, this fixes also the issue that the current output is not TAP compliant and produces the output "no reason given" [for skipping]. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-14Let submodule command exit with error status if path does not existLibravatar Heiko Voigt1-4/+22
Various subcommands of the "git submodule" command exited with 0 status even though the path given by the user did not exist. The reason behind that was that they all pipe the output of module_list into the while loop which then does the action on the paths specified by the commandline. Since the exit code of the command on the upstream side of the pipe is ignored by the shell, the status code of "ls-files --error-unmatch" nor "module_list" was not propagated. In case ls-files returns with an error code, we write a special string that is not possible in non error situations, and no other output, so that the downstream can detect the error and die with an error code. The error message that there is an unmatched pathspec comes through stderr directly from ls-files. So the user still gets a hint whats going on. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-10git svn: reset invalidates the memoized mergeinfo cachesLibravatar Peter Baumann1-0/+78
Since v1.7.0-rc2~11 (git-svn: persistent memoization, 2010-01-30), git-svn has maintained some private per-repository caches in .git/svn/.caches to avoid refetching and recalculating some mergeinfo-related information with every 'git svn fetch'. This memoization can cause problems, e.g consider the following case: SVN repo: ... - a - b - c - m <- trunk \ / d - e <- branch1 The Git import of the above repo is at commit 'a' and doesn't know about the branch1. In case of an 'git svn rebase', only the trunk of the SVN repo is imported. During the creation of the git commit 'm', git svn uses the svn:mergeinfo property and tries to find the corresponding git commit 'e' to create 'm' with 'c' and 'e' as parents. But git svn rebase only imports the current branch so commit 'e' is not imported. Therefore git svn fails to create commit 'm' as a merge commit, because one of its parents is not known to git. The imported history looks like this: ... - a - b - c - m <- trunk A later 'git svn fetch' to import all branches can't rewrite the commit 'm' to add 'e' as a parent and to make it a real git merge commit, because it was already imported. That's why the imported history misses the merge and looks like this: ... - a - b - c - m <- trunk \ d - e <- branch1 Right now the only known workaround for importing 'm' as a merge is to force reimporting 'm' again from SVN, e.g. via $ git svn reset --revision $(git find-rev $c) $ git svn fetch Sadly, this is where the behavior has regressed: git svn reset doesn't invalidate the old mergeinfo cache, which is no longer valid for the reimport, which leads to 'm' beeing imprted with only 'c' as parent. As solution to this problem, this commit invalidates the mergeinfo cache to force correct recalculation of the parents. During development of this patch, several ways for invalidating the cache where considered. One of them is to use Memoize::flush_cache, which will call the CLEAR method on the underlying Memoize persistency implementation. Sadly, neither Memoize::Storable nor the newer Memoize::YAML module introduced in 68f532f4ba888 could optionally be used implement the CLEAR method, so this is not an option. Reseting the internal hash used to store the memoized values has the same problem, because it calls the non-existing CLEAR method of the underlying persistency layer, too. Considering this and taking into account the different implementations of the memoization modules, where Memoize::Storable is not in our control, implementing the missing CLEAR method is not an option, at least not if Memoize::Storable is still used. Therefore the easiest solution to clear the cache is to delete the files on disk in 'git svn reset'. Normally, deleting the files behind the back of the memoization module would be problematic, because the in-memory representation would still exist and contain wrong data. Fortunately, the memoization is active in memory only for a small portion of the code. Invalidating the cache by deleting the files on disk if it isn't active should be safe. Signed-off-by: Peter Baumann <waste.manager@gmx.de> Signed-off-by: Steven Walter <stevenrwalter@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-08-10git svn: handle errors and concurrent commits in dcommitLibravatar Robert Luberda1-0/+216
dcommit didn't handle errors returned by SVN and coped very poorly with concurrent commits that appear in SVN repository while dcommit was running. In both cases it left git repository in inconsistent state: index (which was reset with `git reset --mixed' after a successful commit to SVN) no longer matched the checkouted tree, when the following commit failed or needed to be rebased. See http://bugs.debian.org/676904 for examples. This patch fixes the issues by: - introducing error handler for dcommit. The handler will try to rebase or reset working tree before returning error to the end user. dcommit_rebase function was extracted out of cmd_dcommit to ensure consistency between cmd_dcommit and the error handler. - calling `git reset --mixed' only once after all patches are successfully committed to SVN. This ensures index is not touched for most of the time of dcommit run. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-08-09add tests for 'git rebase --keep-empty'Libravatar Martin von Zweigbergk1-1/+17
Add test cases for 'git rebase --keep-empty' with and without an "empty" commit already in upstream. The empty commit that is about to be rebased should be kept in both cases. Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-06receive-pack: do not leak output from auto-gc to standard outputLibravatar Junio C Hamano1-1/+1
The standard output channel of receive-pack is a structured protocol channel, and subprocesses must never be allowed to leak anything into it by writing to their standard output. Use RUN_COMMAND_STDOUT_TO_STDERR option to run_command_v_opt() just like we do when running hooks to prevent output from "gc" leaking to the standard output. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-06t/t5400: demonstrate breakage caused by informational message from pruneLibravatar Brandon Casey1-0/+35
When receive-pack triggers 'git gc --auto' and 'git prune' is called to remove a stale temporary object, 'git prune' prints an informational message to stdout about the file that it will remove. Since this message is written to stdout, it is sent back over the transport channel to the git client which tries to interpret it as part of the pack protocol and then promptly terminates with a complaint about a protocol error. Introduce a test which exercises the auto-gc functionality of receive-pack and demonstrates this breakage. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-05Fix '\ No newline...' annotation in rewrite diffsLibravatar Adam Butcher1-0/+30
When a file that ends with an incomplete line is expressed as a complete rewrite with the -B option, git diff incorrectly appends the incomplete line indicator "\ No newline at end of file" after such a line, rather than writing it on a line of its own (the output codepath for normal output without -B does not have this problem). Add a LF after the incomplete line before writing the "\ No newline ..." out to fix this. Add a couple of tests to confirm that the indicator comment is generated on its own line in both plain diff and rewrite mode. Signed-off-by: Adam Butcher <dev.lists@jessamine.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-04tests: Introduce test_seqLibravatar Michał Kiedrowicz3-2/+23
Jeff King wrote: The seq command is GNU-ism, and is missing at least in older BSD releases and their derivatives, not to mention antique commercial Unixes. We already purged it in b3431bc (Don't use seq in tests, not everyone has it, 2007-05-02), but a few new instances have crept in. They went unnoticed because they are in scripts that are not run by default. Replace them with test_seq that is implemented with a Perl snippet (proposed by Jeff). This is better than inlining this snippet everywhere it's needed because it's easier to read and it's easier to change the implementation (e.g. to C) if we ever decide to remove Perl from the test suite. Note that test_seq is not a complete replacement for seq(1). It just has what we need now, in addition that it makes it possible for us to do something like "test_seq a m" if we wanted to in the future. There are also many places that do `for i in 1 2 3 ...` but I'm not sure if it's worth converting them to test_seq. That would introduce running more processes of Perl. Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-03grep: add a grep.patternType configuration settingLibravatar J Smith1-0/+181
The grep.extendedRegexp configuration setting enables the -E flag on grep by default but there are no equivalents for the -G, -F and -P flags. Rather than adding an additional setting for grep.fooRegexp for current and future pattern matching options, add a grep.patternType setting that can accept appropriate values for modifying the default grep pattern matching behavior. The current values are "basic", "extended", "fixed", "perl" and "default" for setting -G, -E, -F, -P and the default behavior respectively. When grep.patternType is set to a value other than "default", the grep.extendedRegexp setting is ignored. The value of "default" restores the current default behavior, including the grep.extendedRegexp behavior. Signed-off-by: J Smith <dark.panda@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-02git-svn: introduce add_path_to_url functionLibravatar Michael G. Schwern1-0/+27
Remove the ad-hoc versions. This is mostly to normalize the process and ensure the URLs produced don't have double slashes or anything. Also provides a place to fix the corner case where a file path contains a percent sign. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-08-02git-svn: attempt to mimic SVN 1.7 URL canonicalizationLibravatar Michael G. Schwern2-1/+29
Previously, our URL canonicalization didn't do much of anything. Now it actually escapes and collapses slashes. This is mostly a cut & paste of escape_url from git-svn. This is closer to how SVN 1.7's canonicalization behaves. Doing it with 1.6 lets us chase down some problems caused by more effective canonicalization without having to deal with all the other 1.7 issues on top of that. * Remote URLs have to be canonicalized otherwise Git::SVN->find_existing_remote will think they're different. * The SVN remote is now written to the git config canonicalized. That should be ok. Adjust a test to account for that. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-08-02t9107: fix typoLibravatar Michael G. Schwern1-1/+1
Test to check that the migration got rid of the old style git-svn directory. It wasn't failing, just throwing a message to STDERR. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-08-02t9118: workaround inconsistency between SVN versionsLibravatar Michael G. Schwern1-1/+6
SVN 1.7 will truncate "not-a%40{0}" to just "not-a". Rather than guess what SVN is going to do for each version, make the test use the branch name that was actually created. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-08-02git-svn: add join_paths() to safely concatenate pathsLibravatar Michael G. Schwern1-0/+32
Otherwise you might wind up with things like... my $path1 = undef; my $path2 = 'foo'; my $path = $path1 . '/' . $path2; creating '/foo'. Or this... my $path1 = 'foo/'; my $path2 = 'bar'; my $path = $path1 . '/' . $path2; creating 'foo//bar'. Could have used File::Spec, but I'm shying away from it due to SVN 1.7's pickiness about paths. Felt it would be better to have our own we can control completely. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-08-02git-svn: factor out _collapse_dotdot functionLibravatar Michael G. Schwern1-0/+23
The SVN API functions will not accept ../foo but their canonicalization functions will not collapse it. So we'll have to do it ourselves. _collapse_dotdot() works better than the existing regex did. This will be used shortly when canonicalize_path() starts using the SVN API. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-07-31send-email: improve RFC2047 quote parsingLibravatar Thomas Rast1-0/+13
The RFC2047 unquoting, used to parse email addresses in From and Cc headers, is broken in several ways: * It erroneously substitutes ' ' for '_' in *the whole* header, even outside the quoted field. [Noticed by Christoph.] * It is too liberal in its matching, and happily matches the start of one quoted chunk against the end of another, or even just something that looks like such an end. [Noticed by Junio.] * It fundamentally cannot cope with encodings that are not a superset of ASCII, nor several (incompatible) encodings in the same header. This patch fixes the first two by doing a more careful decoding of the outer quoting (e.g. "=AB" to represent an octet whose value is 0xAB). Fixing the fundamental issues is left for a future, more intrusive, patch. Noticed-by: Christoph Miebach <christoph.miebach@web.de> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-31Merge branch 'jx/i18n-1.7.11'Libravatar Junio C Hamano6-19/+26
Add i18n support for scripted Porcelains, and mark strings in merge(-recursive), am, and rebase for i18n. * jx/i18n-1.7.11: i18n: merge-recursive: mark strings for translation Remove dead code which contains bad gettext block i18n: am: mark more strings for translation rebase: remove obsolete and unused LONG_USAGE which breaks xgettext i18n: Rewrite gettext messages start with dash i18n: rebase: mark messages for translation i18n: New keywords for xgettext extraction from sh
2012-07-30Merge branch 'kk/maint-commit-tree' into maintLibravatar Junio C Hamano1-0/+17
"git commit-tree" learned a more natural "-p <parent> <tree>" order of arguments long time ago, but recently forgot it by mistake. * kk/maint-commit-tree: Revert "git-commit-tree(1): update synopsis" commit-tree: resurrect command line parsing updates
2012-07-30Merge branch 'jv/maint-no-ext-diff' into maintLibravatar Junio C Hamano1-0/+59
"git diff --no-ext-diff" did not output anything for a typechange filepair when GIT_EXTERNAL_DIFF is in effect. * jv/maint-no-ext-diff: diff: test precedence of external diff drivers diff: correctly disable external_diff with --no-ext-diff
2012-07-30Merge branch 'jl/maint-1.7.10-recurse-submodules-with-symlink' into maintLibravatar Junio C Hamano1-0/+13
When "git submodule add" clones a submodule repository, it can get confused where to store the resulting submodule repository in the superproject's .git/ directory when there is a symbolic link in the path to the current directory. * jl/maint-1.7.10-recurse-submodules-with-symlink: submodules: don't stumble over symbolic links when cloning recursively
2012-07-30Merge branch 'jc/maint-filter-branch-epoch-date' into maintLibravatar Junio C Hamano2-3/+13
In 1.7.9 era, we taught "git rebase" about the raw timestamp format but we did not teach the same trick to "filter-branch", which rolled a similar logic on its own. * jc/maint-filter-branch-epoch-date: t7003: add test to filter a branch with a commit at epoch date.c: Fix off by one error in object-header date parsing filter-branch: do not forget the '@' prefix to force git-timestamp
2012-07-30Merge branch 'rj/maint-grep-remove-redundant-test'Libravatar Junio C Hamano1-11/+0
"git grep" stopped spawning an external "grep" long time ago, but a duplicated test to check internal and external "grep" was left behind. * rj/maint-grep-remove-redundant-test: t7810-*.sh: Remove redundant test
2012-07-30Merge branch 'dg/submodule-in-dismembered-working-tree'Libravatar Junio C Hamano1-6/+23
Finishing touches to the new test script. * dg/submodule-in-dismembered-working-tree: t7409: make sure submodule is initialized and updated in more detail
2012-07-30t7409: make sure submodule is initialized and updated in more detailLibravatar Daniel Graña1-6/+23
The earlier test did not even make sure that the correct commit is checked out in the submodule directory. Inspect the result in a bit more detail. Signed-off-by: Daniel Graña <dangra@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-30t7406: fix misleading "rev-parse --max-count=1 HEAD"Libravatar Junio C Hamano1-8/+8
The test happened to use "rev-parse --max-count=1 HEAD" consistently to prepare the expected output and the actual output, so the comparison between them gave us a correct success/failure because both output had irrelevant "--max-count=1" in it. But that is not an excuse to keep it broken. Replace it a more meaningful construct "rev-parse --verify HEAD". Noticed by Daniel Graña while working on his submodule tests. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-29t7810-*.sh: Remove redundant testLibravatar Ramsay Jones1-11/+0
Since commit bbc09c22 ("grep: rip out support for external grep", 12-01-2010), test number 60 ("grep -C1 hunk mark between files") is essentially the same as test number 59. Test 59 was intended to verify the behaviour of git-grep resulting from multiple invocations of an external grep. As part of the test, it creates and adds 1024 files to the index, which is now wasted effort. Remove test 59, since it is now redundant. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-29t1100-*.sh: Fix an intermittent test failureLibravatar Ramsay Jones1-0/+1
In particular, the final test ('flags and then non flags') fails intermittently, depending on how much time elapsed between the invocations of "git commit-tree" when creating the commits which later have their commit id's compared. For example, if the commits for childid-3 and childid-4 are created 1 or more seconds apart, then the commits, which would otherwise be identical, will have different commit id's. In order to make the test reproducible, we remove the variability by setting the author and committer times to a well defined state. We accomplish this with a single call to 'test_tick' at the start of the test. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-29t: add missing executable bit to t7409Libravatar Jeff King1-0/+0
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-29fsck: detect null sha1 in tree entriesLibravatar Jeff King1-0/+26
Short of somebody happening to beat the 1 in 2^160 odds of actually generating content that hashes to the null sha1, we should never see this value in a tree entry. So let's have fsck warn if it it seen. As in the previous commit, we test both blob and submodule entries to future-proof the test suite against the implementation depending on connectivity to notice the error. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-29do not write null sha1s to on-disk indexLibravatar Jeff King1-0/+19
We should never need to write the null sha1 into an index entry (short of the 1 in 2^160 chance that somebody actually has content that hashes to it). If we attempt to do so, it is much more likely that it is a bug, since we use the null sha1 as a sentinel value to mean "not valid". The presence of null sha1s in the index (which can come from, among other things, "update-index --cacheinfo", or by reading a corrupted tree) can cause problems for later readers, because they cannot distinguish the literal null sha1 from its use a sentinel value. For example, "git diff-files" on such an entry would make it appear as if it is stat-dirty, and until recently, the diff code assumed such an entry meant that we should be diffing a working tree file rather than a blob. Ideally, we would stop such entries from entering even our in-core index. However, we do sometimes legitimately add entries with null sha1s in order to represent these sentinel situations; simply forbidding them in add_index_entry breaks a lot of the existing code. However, we can at least make sure that our in-core sentinel representation never makes it to disk. To be thorough, we will test an attempt to add both a blob and a submodule entry. In the former case, we might run into problems anyway because we will be missing the blob object. But in the latter case, we do not enforce connectivity across gitlink entries, making this our only point of enforcement. The current implementation does not care which type of entry we are seeing, but testing both cases helps future-proof the test suite in case that changes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-29diff: do not use null sha1 as a sentinel valueLibravatar Jeff King1-0/+83
The diff code represents paths using the diff_filespec struct. This struct has a sha1 to represent the sha1 of the content at that path, as well as a sha1_valid member which indicates whether its sha1 field is actually useful. If sha1_valid is not true, then the filespec represents a working tree file (e.g., for the no-index case, or for when the index is not up-to-date). The diff_filespec is only used internally, though. At the interfaces to the diff subsystem, callers feed the sha1 directly, and we create a diff_filespec from it. It's at that point that we look at the sha1 and decide whether it is valid or not; callers may pass the null sha1 as a sentinel value to indicate that it is not. We should not typically see the null sha1 coming from any other source (e.g., in the index itself, or from a tree). However, a corrupt tree might have a null sha1, which would cause "diff --patch" to accidentally diff the working tree version of a file instead of treating it as a blob. This patch extends the edges of the diff interface to accept a "sha1_valid" flag whenever we accept a sha1, and to use that flag when creating a filespec. In some cases, this means passing the flag through several layers, making the code change larger than would be desirable. One alternative would be to simply die() upon seeing corrupted trees with null sha1s. However, this fix more directly addresses the problem (while bogus sha1s in a tree are probably a bad thing, it is really the sentinel confusion sending us down the wrong code path that is what makes it devastating). And it means that git is more capable of examining and debugging these corrupted trees. For example, you can still "diff --raw" such a tree to find out when the bogus entry was introduced; you just cannot do a "--patch" diff (just as you could not with any other corrupted tree, as we do not have any content to diff). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-27Merge branch 'extract-remaining' of git://git.bogomips.org/git-svnLibravatar Junio C Hamano1-2/+7
* 'extract-remaining' of git://git.bogomips.org/git-svn: Extract Git::SVN::GlobSpec from git-svn. Move Git::IndexInfo into its own file. Load all the modules in one place and before running code. Extract Git::SVN::Migration from git-svn. Prepare Git::SVN::Migration for extraction from git-svn. Extract Git::SVN::Log from git-svn. Prepare Git::SVN::Log for extraction from git-svn.
2012-07-27Merge git://git.bogomips.org/git-svnLibravatar Junio C Hamano3-0/+54
* git://git.bogomips.org/git-svn: Move initialization of Git::SVN variables into Git::SVN. Extract Git::SVN from git-svn into its own .pm file. Prepare Git::SVN for extraction into its own file. Extract some utilities from git-svn to allow extracting Git::SVN. perl: detect new files in MakeMaker builds The Makefile.PL will now find .pm files itself. Don't lose Error.pm if $@ gets clobbered. Quiet warning if Makefile.PL is run with -w and no --localedir
2012-07-27Merge branch 'jk/autoident-test'Libravatar Junio C Hamano1-33/+42
Fix test breakages by a builder who does not have a valid user name in his /etc/password entry. * jk/autoident-test: t7502: test early quit from commit with bad ident t7502: handle systems where auto-identity is broken t7502: drop confusing test_might_fail call t7502: narrow checks for author/committer name in template t7502: properly quote GIT_EDITOR t7502: clean up fake_editor tests
2012-07-27Merge branch 'dg/submodule-in-dismembered-working-tree'Libravatar Junio C Hamano1-0/+61
In a superproject that has repository outside of its working tree, "git submodule add" failed to clone a new submodule, as GIT_DIR and GIT_WORK_TREE environment variables necessary to work in such a superproject interfered with access to the submodule repository. * dg/submodule-in-dismembered-working-tree: git-submodule: work with GIT_DIR/GIT_WORK_TREE
2012-07-27Extract Git::SVN::GlobSpec from git-svn.Libravatar Michael G. Schwern1-1/+2
Straight cut & paste. That's the last class. * Make Git::SVN load it on its own, its the only thing that needs it. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-07-27Move Git::IndexInfo into its own file.Libravatar Michael G. Schwern1-1/+2
Straight cut & paste. Didn't require any fixing. Signed-off-by: Eric Wong <normalperson@yhbt.net>