summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2015-01-12Merge branch 'mg/add-ignore-errors' into maintLibravatar Junio C Hamano1-1/+7
* mg/add-ignore-errors: add: ignore only ignored files
2015-01-12Merge branch 'jk/approxidate-avoid-y-d-m-over-future-dates' into maintLibravatar Junio C Hamano1-0/+3
* jk/approxidate-avoid-y-d-m-over-future-dates: approxidate: allow ISO-like dates far in the future pass TIME_DATE_NOW to approxidate future-check
2015-01-12Merge branch 'jk/for-each-reflog-ent-reverse' into maintLibravatar Junio C Hamano1-0/+30
* jk/for-each-reflog-ent-reverse: for_each_reflog_ent_reverse: turn leftover check into assertion for_each_reflog_ent_reverse: fix newlines on block boundaries
2015-01-07Merge branch 'maint-2.1' into maintLibravatar Junio C Hamano1-0/+15
* maint-2.1: is_hfs_dotgit: loosen over-eager match of \u{..47}
2015-01-07Merge branch 'maint-2.0' into maint-2.1Libravatar Junio C Hamano1-0/+15
* maint-2.0: is_hfs_dotgit: loosen over-eager match of \u{..47}
2015-01-07Merge branch 'maint-1.9' into maint-2.0Libravatar Junio C Hamano1-0/+15
* maint-1.9: is_hfs_dotgit: loosen over-eager match of \u{..47}
2015-01-07Merge branch 'maint-1.8.5' into maint-1.9Libravatar Junio C Hamano1-0/+15
* maint-1.8.5: is_hfs_dotgit: loosen over-eager match of \u{..47}
2015-01-07Merge branch 'jk/dotgit-case-maint-1.8.5' into maint-1.8.5Libravatar Junio C Hamano1-0/+15
* jk/dotgit-case-maint-1.8.5: is_hfs_dotgit: loosen over-eager match of \u{..47}
2014-12-29is_hfs_dotgit: loosen over-eager match of \u{..47}Libravatar Jeff King1-0/+15
Our is_hfs_dotgit function relies on the hackily-implemented next_hfs_char to give us the next character that an HFS+ filename comparison would look at. It's hacky because it doesn't implement the full case-folding table of HFS+; it gives us just enough to see if the path matches ".git". At the end of next_hfs_char, we use tolower() to convert our 32-bit code point to lowercase. Our tolower() implementation only takes an 8-bit char, though; it throws away the upper 24 bits. This means we can't have any false negatives for is_hfs_dotgit. We only care about matching 7-bit ASCII characters in ".git", and we will correctly process 'G' or 'g'. However, we _can_ have false positives. Because we throw away the upper bits, code point \u{0147} (for example) will look like 'G' and get downcased to 'g'. It's not known whether a sequence of code points whose truncation ends up as ".git" is meaningful in any language, but it does not hurt to be more accurate here. We can just pass out the full 32-bit code point, and compare it manually to the upper and lowercase characters we care about. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-22Merge branch 'jk/no-perl-tests' into maintLibravatar Junio C Hamano3-4/+4
Some tests that depend on perl lacked PERL prerequisite to protect them, breaking build with NO_PERL configuration. * jk/no-perl-tests: t960[34]: mark cvsimport tests as requiring perl t0090: mark add-interactive test with PERL prerequisite
2014-12-22Merge branch 'jk/push-simple' into maintLibravatar Junio C Hamano1-2/+30
Git 2.0 was supposed to make the "simple" mode for the default of "git push", but it didn't. * jk/push-simple: push: truly use "simple" as default, not "upstream"
2014-12-22Merge branch 'mh/config-flip-xbit-back-after-checking' into maintLibravatar Junio C Hamano1-0/+7
"git init" (hence "git clone") initialized the per-repository configuration file .git/config with x-bit by mistake. * mh/config-flip-xbit-back-after-checking: create_default_files(): don't set u+x bit on $GIT_DIR/config
2014-12-22Merge branch 'jk/colors-fix' into maintLibravatar Junio C Hamano1-0/+8
"git config --get-color" did not parse its command line arguments carefully. * jk/colors-fix: t4026: test "normal" color config: fix parsing of "git config --get-color some.key -1" docs: describe ANSI 256-color mode
2014-12-22Merge branch 'jk/checkout-from-tree' into maintLibravatar Junio C Hamano1-0/+17
"git checkout $treeish $path", when $path in the index and the working tree already matched what is in $treeish at the $path, still overwrote the $path unnecessarily. * jk/checkout-from-tree: checkout $tree: do not throw away unchanged index entries
2014-12-17Sync with v2.1.4Libravatar Junio C Hamano3-31/+102
* maint-2.1: Git 2.1.4 Git 2.0.5 Git 1.9.5 Git 1.8.5.6 fsck: complain about NTFS ".git" aliases in trees read-cache: optionally disallow NTFS .git variants path: add is_ntfs_dotgit() helper fsck: complain about HFS+ ".git" aliases in trees read-cache: optionally disallow HFS+ .git variants utf8: add is_hfs_dotgit() helper fsck: notice .git case-insensitively t1450: refactor ".", "..", and ".git" fsck tests verify_dotfile(): reject .git case-insensitively read-tree: add tests for confusing paths like ".." and ".git" unpack-trees: propagate errors adding entries to the index
2014-12-17Sync with v2.0.5Libravatar Junio C Hamano3-31/+102
* maint-2.0: Git 2.0.5 Git 1.9.5 Git 1.8.5.6 fsck: complain about NTFS ".git" aliases in trees read-cache: optionally disallow NTFS .git variants path: add is_ntfs_dotgit() helper fsck: complain about HFS+ ".git" aliases in trees read-cache: optionally disallow HFS+ .git variants utf8: add is_hfs_dotgit() helper fsck: notice .git case-insensitively t1450: refactor ".", "..", and ".git" fsck tests verify_dotfile(): reject .git case-insensitively read-tree: add tests for confusing paths like ".." and ".git" unpack-trees: propagate errors adding entries to the index
2014-12-17Sync with v1.9.5Libravatar Junio C Hamano3-31/+102
* maint-1.9: Git 1.9.5 Git 1.8.5.6 fsck: complain about NTFS ".git" aliases in trees read-cache: optionally disallow NTFS .git variants path: add is_ntfs_dotgit() helper fsck: complain about HFS+ ".git" aliases in trees read-cache: optionally disallow HFS+ .git variants utf8: add is_hfs_dotgit() helper fsck: notice .git case-insensitively t1450: refactor ".", "..", and ".git" fsck tests verify_dotfile(): reject .git case-insensitively read-tree: add tests for confusing paths like ".." and ".git" unpack-trees: propagate errors adding entries to the index
2014-12-17Sync with v1.8.5.6Libravatar Junio C Hamano3-31/+102
* maint-1.8.5: Git 1.8.5.6 fsck: complain about NTFS ".git" aliases in trees read-cache: optionally disallow NTFS .git variants path: add is_ntfs_dotgit() helper fsck: complain about HFS+ ".git" aliases in trees read-cache: optionally disallow HFS+ .git variants utf8: add is_hfs_dotgit() helper fsck: notice .git case-insensitively t1450: refactor ".", "..", and ".git" fsck tests verify_dotfile(): reject .git case-insensitively read-tree: add tests for confusing paths like ".." and ".git" unpack-trees: propagate errors adding entries to the index
2014-12-17Merge branch 'dotgit-case-maint-1.8.5' into maint-1.8.5Libravatar Junio C Hamano3-31/+102
* dotgit-case-maint-1.8.5: fsck: complain about NTFS ".git" aliases in trees read-cache: optionally disallow NTFS .git variants path: add is_ntfs_dotgit() helper fsck: complain about HFS+ ".git" aliases in trees read-cache: optionally disallow HFS+ .git variants utf8: add is_hfs_dotgit() helper fsck: notice .git case-insensitively t1450: refactor ".", "..", and ".git" fsck tests verify_dotfile(): reject .git case-insensitively read-tree: add tests for confusing paths like ".." and ".git" unpack-trees: propagate errors adding entries to the index
2014-12-17fsck: complain about NTFS ".git" aliases in treesLibravatar Johannes Schindelin1-2/+7
Now that the index can block pathnames that can be mistaken to mean ".git" on NTFS and FAT32, it would be helpful for fsck to notice such problematic paths. This lets servers which use receive.fsckObjects block them before the damage spreads. Note that the fsck check is always on, even for systems without core.protectNTFS set. This is technically more restrictive than we need to be, as a set of users on ext4 could happily use these odd filenames without caring about NTFS. However, on balance, it's helpful for all servers to block these (because the paths can be used for mischief, and servers which bother to fsck would want to stop the spread whether they are on NTFS themselves or not), and hardly anybody will be affected (because the blocked names are variants of .git or git~1, meaning mischief is almost certainly what the tree author had in mind). Ideally these would be controlled by a separate "fsck.protectNTFS" flag. However, it would be much nicer to be able to enable/disable _any_ fsck flag individually, and any scheme we choose should match such a system. Given the likelihood of anybody using such a path in practice, it is not unreasonable to wait until such a system materializes. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-17read-cache: optionally disallow NTFS .git variantsLibravatar Johannes Schindelin1-0/+13
The point of disallowing ".git" in the index is that we would never want to accidentally overwrite files in the repository directory. But this means we need to respect the filesystem's idea of when two paths are equal. The prior commit added a helper to make such a comparison for NTFS and FAT32; let's use it in verify_path(). We make this check optional for two reasons: 1. It restricts the set of allowable filenames, which is unnecessary for people who are not on NTFS nor FAT32. In practice this probably doesn't matter, though, as the restricted names are rather obscure and almost certainly would never come up in practice. 2. It has a minor performance penalty for every path we insert into the index. This patch ties the check to the core.protectNTFS config option. Though this is expected to be most useful on Windows, we allow it to be set everywhere, as NTFS may be mounted on other platforms. The variable does default to on for Windows, though. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-17fsck: complain about HFS+ ".git" aliases in treesLibravatar Jeff King1-3/+5
Now that the index can block pathnames that case-fold to ".git" on HFS+, it would be helpful for fsck to notice such problematic paths. This lets servers which use receive.fsckObjects block them before the damage spreads. Note that the fsck check is always on, even for systems without core.protectHFS set. This is technically more restrictive than we need to be, as a set of users on ext4 could happily use these odd filenames without caring about HFS+. However, on balance, it's helpful for all servers to block these (because the paths can be used for mischief, and servers which bother to fsck would want to stop the spread whether they are on HFS+ themselves or not), and hardly anybody will be affected (because the blocked names are variants of .git with invisible Unicode code-points mixed in, meaning mischief is almost certainly what the tree author had in mind). Ideally these would be controlled by a separate "fsck.protectHFS" flag. However, it would be much nicer to be able to enable/disable _any_ fsck flag individually, and any scheme we choose should match such a system. Given the likelihood of anybody using such a path in practice, it is not unreasonable to wait until such a system materializes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-17read-cache: optionally disallow HFS+ .git variantsLibravatar Jeff King2-5/+25
The point of disallowing ".git" in the index is that we would never want to accidentally overwrite files in the repository directory. But this means we need to respect the filesystem's idea of when two paths are equal. The prior commit added a helper to make such a comparison for HFS+; let's use it in verify_path. We make this check optional for two reasons: 1. It restricts the set of allowable filenames, which is unnecessary for people who are not on HFS+. In practice this probably doesn't matter, though, as the restricted names are rather obscure and almost certainly would never come up in practice. 2. It has a minor performance penalty for every path we insert into the index. This patch ties the check to the core.protectHFS config option. Though this is expected to be most useful on OS X, we allow it to be set everywhere, as HFS+ may be mounted on other platforms. The variable does default to on for OS X, though. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-17fsck: notice .git case-insensitivelyLibravatar Jeff King1-0/+1
We complain about ".git" in a tree because it cannot be loaded into the index or checked out. Since we now also reject ".GIT" case-insensitively, fsck should notice the same, so that errors do not propagate. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-17t1450: refactor ".", "..", and ".git" fsck testsLibravatar Jeff King1-30/+27
We check that fsck notices and complains about confusing paths in trees. However, there are a few shortcomings: 1. We check only for these paths as file entries, not as intermediate paths (so ".git" and not ".git/foo"). 2. We check "." and ".." together, so it is possible that we notice only one and not the other. 3. We repeat a lot of boilerplate. Let's use some loops to be more thorough in our testing, and still end up with shorter code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-17verify_dotfile(): reject .git case-insensitivelyLibravatar Jeff King1-0/+1
We do not allow ".git" to enter into the index as a path component, because checking out the result to the working tree may causes confusion for subsequent git commands. However, on case-insensitive file systems, ".Git" or ".GIT" is the same. We should catch and prevent those, too. Note that technically we could allow this for repos on case-sensitive filesystems. But there's not much point. It's unlikely that anybody cares, and it creates a repository that is unexpectedly non-portable to other systems. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-17read-tree: add tests for confusing paths like ".." and ".git"Libravatar Jeff King1-0/+32
We should prevent nonsense paths from entering the index in the first place, as they can cause confusing results if they are ever checked out into the working tree. We already do so, but we never tested it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-05for_each_reflog_ent_reverse: fix newlines on block boundariesLibravatar Jeff King1-0/+30
When we read a reflog file in reverse, we read whole chunks of BUFSIZ bytes, then loop over the buffer, parsing any lines we find. We find the beginning of each line by looking for the newline from the previous line. If we don't find one, we know that we are either at the beginning of the file, or that we have to read another block. In the latter case, we stuff away what we have into a strbuf, read another block, and continue our parse. But we missed one case here. If we did find a newline, and it is at the beginning of the block, we must also stuff that newline into the strbuf, as it belongs to the block we are about to read. The minimal fix here would be to add this special case to the conditional that checks whether we found a newline. But we can make the flow a little clearer by rearranging a bit: we first handle lines that we are going to show, and then at the end of each loop, stuff away any leftovers if necessary. That lets us fold this special-case in with the more common "we ended in the middle of a line" case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-30push: truly use "simple" as default, not "upstream"Libravatar Jeff King1-2/+30
The plan for the push.default transition had all along been to use the "simple" method rather than "upstream" as a default if the user did not specify their own push.default value. Commit 11037ee (push: switch default from "matching" to "simple", 2013-01-04) tried to implement that by moving PUSH_DEFAULT_UNSPECIFIED in our switch statement to fall-through to the PUSH_DEFAULT_SIMPLE case. When the commit that became 11037ee was originally written, that would have been enough. We would fall through to calling setup_push_upstream() with the "simple" parameter set to 1. However, it was delayed for a while until we were ready to make the transition in Git 2.0. And in the meantime, commit ed2b182 (push: change `simple` to accommodate triangular workflows, 2013-06-19) threw a monkey wrench into the works. That commit drops the "simple" parameter to setup_push_upstream, and instead checks whether the global "push_default" is PUSH_DEFAULT_SIMPLE. This is right when the user has explicitly configured push.default to simple, but wrong when we are a fall-through for the "unspecified" case. We never noticed because our push.default tests do not cover the case of the variable being totally unset; they only check the "simple" behavior itself. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-21add: ignore only ignored filesLibravatar Michael J Gruber1-1/+7
"git add foo bar" adds neither foo nor bar when bar is ignored, but dies to let the user recheck their command invocation. This becomes less helpful when "git add foo.*" is subject to shell expansion and some of the expanded files are ignored. "git add --ignore-errors" is supposed to ignore errors when indexing some files and adds the others. It does ignore errors from actual indexing attempts, but does not ignore the error "file is ignored" as outlined above. This is unexpected. Change "git add foo bar" to add foo when bar is ignored, but issue a warning and return a failure code as before the change. That is, in the case of trying to add ignored files we now act the same way (with or without "--ignore-errors") in which we act for more severe indexing errors when "--ignore-errors" is specified. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-20t4026: test "normal" colorLibravatar Jeff King1-0/+8
If the user specifiers "normal" for a foreground color, this should be a noop (while this may sound useless, it is the only way to specify an unchanged foreground color followed by a specific background color). We also check that color "-1" does the same thing. This is not documented, but has worked forever, so let's make sure we keep supporting it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-19Merge branch 'tb/no-relative-file-url'Libravatar Junio C Hamano1-1/+1
* tb/no-relative-file-url: t5705: the file:// URL should be absolute
2014-11-18Merge branch 'da/difftool'Libravatar Junio C Hamano1-0/+5
Fix-up to a new feature in 'master'. * da/difftool: difftool: honor --trust-exit-code for builtin tools
2014-11-18t960[34]: mark cvsimport tests as requiring perlLibravatar Jeff King2-3/+3
Git-cvsimport is written in perl, which understandably causes the tests to fail if you build with NO_PERL (which will avoid building cvsimport at all). The earlier cvsimport tests in t9600-t9602 are all marked with a PERL prerequisite, but these ones are not. The one in t9603 was likely not noticed because it is an expected failure anyway. The ones in t9604 have been around for a long time, but it is likely that the combination of NO_PERL and having cvsps installed is rare enough that nobody noticed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-18t0090: mark add-interactive test with PERL prerequisiteLibravatar Jeff King1-1/+1
The add-interactive system is built in perl. If you build with NO_PERL, running "git commit --interactive" will exit with an error and the test will fail. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-18create_default_files(): don't set u+x bit on $GIT_DIR/configLibravatar Michael Haggerty1-0/+7
Since time immemorial, the test of whether to set "core.filemode" has been done by trying to toggle the u+x bit on $GIT_DIR/config, which we know always exists, and then testing whether the change "took". I find it somewhat odd to use the config file for this test, but whatever. The test code didn't set the u+x bit back to its original state itself, instead relying on the subsequent call to git_config_set() to re-write the config file with correct permissions. But ever since daa22c6f8d config: preserve config file permissions on edits (2014-05-06) git_config_set() copies the permissions from the old config file to the new one. This is a good change in and of itself, but it invalidates the create_default_files()'s assumption, causing "git init" to leave the executable bit set on $GIT_DIR/config. Reset the permissions on $GIT_DIR/config when we are done with the test in create_default_files(). Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-14difftool: honor --trust-exit-code for builtin toolsLibravatar David Aguilar1-0/+5
run_merge_tool() was not setting $status, which prevented the exit code for builtin tools from being forwarded to the caller. Capture the exit status and add a test to guarantee the behavior. Reported-by: Adria Farres <14farresa@gmail.com> Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-13approxidate: allow ISO-like dates far in the futureLibravatar Jeff King1-0/+3
When we are parsing approxidate strings and we find three numbers separate by one of ":/-.", we guess that it may be a date. We feed the numbers to match_multi_number, which checks whether it makes sense as a date in various orderings (e.g., dd/mm/yy or mm/dd/yy, etc). One of the checks we do is to see whether it is a date more than 10 days in the future. This was added in 38035cf (date parsing: be friendlier to our European friends., 2006-04-05), and lets us guess that if it is currently April 2014, then "10/03/2014" is probably March 10th, not October 3rd. This has a downside, though; if you want to be overly generous with your "--until" date specification, we may wrongly parse "2014-12-01" as "2014-01-12" (because the latter is an in-the-past date). If the year is a future year (i.e., both are future dates), it gets even weirder. Due to the vagaries of approxidate, months _after_ the current date (no matter the year) get flipped, but ones before do not. This patch drops the "in the future" check for dates of this form, letting us treat them always as yyyy-mm-dd, even if they are in the future. This does not affect the normal dd/mm/yyyy versus mm/dd/yyyy lookup, because this code path only kicks in when the first number is greater than 70 (i.e., it must be a year, and cannot be either a date or a month). The one possible casualty is that "yyyy-dd-mm" is less likely to be chosen over "yyyy-mm-dd". That's probably OK, though because: 1. The difference happens only when the date is in the future. Already we prefer yyyy-mm-dd for dates in the past. 2. It's unclear whether anybody even uses yyyy-dd-mm regularly. It does not appear in lists of common date formats in Wikipedia[1,2]. 3. Even if (2) is wrong, it is better to prefer ISO-like dates, as that is consistent with what we use elsewhere in git. [1] http://en.wikipedia.org/wiki/Date_and_time_representation_by_country [2] http://en.wikipedia.org/wiki/Calendar_date Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-13checkout $tree: do not throw away unchanged index entriesLibravatar Jeff King1-0/+17
When we "git checkout $tree", we pull paths from $tree into the index, and then check the resulting entries out to the worktree. Our method for the first step is rather heavy-handed, though; it clobbers the entire existing index entry, even if the content is the same. This means we lose our stat information, leading checkout_entry to later rewrite the entire file with identical content. Instead, let's see if we have the identical entry already in the index, in which case we leave it in place. That lets checkout_entry do the right thing. Our tests cover two interesting cases: 1. We make sure that a file which has no changes is not rewritten. 2. We make sure that we do update a file that is unchanged in the index (versus $tree), but has working tree changes. We keep the old index entry, and checkout_entry is able to realize that our stat information is out of date. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-13t5705: the file:// URL should be absoluteLibravatar Torsten Bögershausen1-1/+1
The test misused a URL "file://." to mean "relative to here", which we no longer accept. In a file:// URL, typically there is no host, and RFC1738 says that file:///<path> should be used. Update t5705 to use a working URL. Reported-by: Michael Blume <blume.mike@gmail.com> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-12Merge branch 'jk/fetch-reflog-df-conflict'Libravatar Junio C Hamano1-18/+18
Fix-up a test for portability. * jk/fetch-reflog-df-conflict: t1410: fix breakage on case-insensitive filesystems
2014-11-10t1410: fix breakage on case-insensitive filesystemsLibravatar Jeff King1-18/+18
Two tests recently added to t1410 create branches "a" and "a/b" to test d/f conflicts on reflogs. Earlier, unrelated tests in that script create the path "A/B" in the working tree. There's no conflict on a case-sensitive filesystem, but on a case-insensitive one, "git log" will complain that "a/b" is both a revision and a working tree path. We could fix this by using a "--" to disambiguate, but we are probably better off using names that are less confusing to make it more clear that they are unrelated to the working tree files. This patch turns "a/b" into "one/two". Reported-by: Michael Blume <blume.mike@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-06Merge branch 'tm/line-log-first-parent'Libravatar Junio C Hamano1-0/+5
"git log --first-parent -L..." used to crash. * tm/line-log-first-parent: line-log: fix crash when --first-parent is used
2014-11-06Merge branch 'jk/fetch-reflog-df-conflict'Libravatar Junio C Hamano2-0/+74
Corner-case bugfixes for "git fetch" around reflog handling. * jk/fetch-reflog-df-conflict: ignore stale directories when checking reflog existence fetch: load all default config at startup
2014-11-04line-log: fix crash when --first-parent is usedLibravatar Tzvetan Mikov1-0/+5
line-log tries to access all parents of a commit, but only the first parent has been loaded if "--first-parent" is specified, resulting in a crash. Limit the number of parents to one if "--first-parent" is specified. Reported-by: Eric N. Vander Weele <ericvw@gmail.com> Signed-off-by: Tzvetan Mikov <tmikov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-04ignore stale directories when checking reflog existenceLibravatar Jeff King1-0/+34
When we update a ref, we have two rules for whether or not we actually update the reflog: 1. If the reflog already exists, we will always append to it. 2. If log_all_ref_updates is set, we will create a new reflog file if necessary. We do the existence check by trying to open the reflog file, either with or without O_CREAT (depending on log_all_ref_updates). If it fails, then we check errno to see what happened. If we were not using O_CREAT and we got ENOENT, the file doesn't exist, and we return success (there isn't a reflog already, and we were not told to make a new one). If we get EISDIR, then there is likely a stale directory that needs to be removed (e.g., there used to be "foo/bar", it was deleted, and the directory "foo" was left. Now we want to create the ref "foo"). If O_CREAT is set, then we catch this case, try to remove the directory, and retry our open. So far so good. But if we get EISDIR and O_CREAT is not set, then we treat this as any other error, which is not right. Like ENOENT, EISDIR is an indication that we do not have a reflog, and we should silently return success (we were not told to create it). Instead, the current code reports this as an error, and we fail to update the ref at all. Note that this is relatively unlikely to happen, as you would have to have had reflogs turned on, and then later turned them off (it could also happen due to a bug in fetch, but that was fixed in the previous commit). However, it's quite easy to fix: we just need to treat EISDIR like ENOENT for the non-O_CREAT case, and silently return (note that this early return means we can also simplify the O_CREAT case). Our new tests cover both cases (O_CREAT and non-O_CREAT). The first one already worked, of course. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-04fetch: load all default config at startupLibravatar Jeff King1-0/+40
When we start the git-fetch program, we call git_config to load all config, but our callback only processes the fetch.prune option; we do not chain to git_default_config at all. This means that we may not load some core configuration which will have an effect. For instance, we do not load core.logAllRefUpdates, which impacts whether or not we create reflogs in a bare repository. Note that I said "may" above. It gets even more exciting. If we have to transfer actual objects as part of the fetch, then we call fetch_pack as part of the same process. That function loads its own config, which does chain to git_default_config, impacting global variables which are used by the rest of fetch. But if the fetch is a pure ref update (e.g., a new ref which is a copy of an old one), we skip fetch_pack entirely. So we get inconsistent results depending on whether or not we have actual objects to transfer or not! Let's just load the core config at the start of fetch, so we know we have it (we may also load it again as part of fetch_pack, but that's OK; it's designed to be idempotent). Our tests check both cases (with and without a pack). We also check similar behavior for push for good measure, but it already works as expected. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-31Merge branch 'rs/grep-color-words'Libravatar Junio C Hamano1-0/+94
Allow painting or not painting (partial) matches in context lines when showing "grep -C<num>" output in color. * rs/grep-color-words: grep: add color.grep.matchcontext and color.grep.matchselected
2014-10-29Merge branch 'jk/pack-objects-no-bitmap-when-splitting' into maintLibravatar Junio C Hamano1-0/+9
* jk/pack-objects-no-bitmap-when-splitting: pack-objects: turn off bitmaps when we split packs
2014-10-29Merge branch 'da/difftool'Libravatar Junio C Hamano1-0/+51
Allow diff tool backend to stop early by exiting with a non-zero status. * da/difftool: difftool: add support for --trust-exit-code difftool--helper: exit when reading a prompt answer fails