summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Correct fscanf formatting string for I64u valuesjs/misc-fixesWaldek Maleska2015-10-262-1/+5
| | | | | | | | | | This fix is probably purely cosmetic because PRIuMAX is likely identical to SCNuMAX. Nevertheless, when using a function of the scanf() family, the correct interpolation to use is the latter, not the former. Signed-off-by: Waldek Maleska <w.maleska@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Silence GCC's "cast of pointer to integer of a different size" warningJohannes Schindelin2015-10-263-4/+6
| | | | | | | | | | | | When calculating hashes from pointers, it actually makes sense to cut off the most significant bits. In that case, said warning does not make a whole lot of sense. So let's just work around it by casting the pointer first to intptr_t and then casting up/down to the final integral type. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Squelch warning about an integer overflowJohannes Schindelin2015-10-261-1/+1
| | | | | | | We cannot rely on long integers to have more than 32 bits. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Git 2.2.3v2.2.3maint-2.2Junio C Hamano2015-09-044-3/+13
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'jk/long-paths' into maint-2.2Junio C Hamano2015-09-044-24/+27
|\
| * show-branch: use a strbuf for reflog descriptionsJeff King2015-09-041-2/+4
| | | | | | | | | | | | | | | | | | When we show "branch@{0}", we format into a fixed-size buffer using sprintf. This can overflow if you have long branch names. We can fix it by using a temporary strbuf. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * read_info_alternates: handle paths larger than PATH_MAXJeff King2015-09-041-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This function assumes that the relative_base path passed into it is no larger than PATH_MAX, and writes into a fixed-size buffer. However, this path may not have actually come from the filesystem; for example, add_submodule_odb generates a path using a strbuf and passes it in. This is hard to trigger in practice, though, because the long submodule directory would have to exist on disk before we would try to open its info/alternates file. We can easily avoid the bug, though, by simply creating the filename on the heap. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * notes: use a strbuf in add_non_noteJeff King2015-09-041-9/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we are loading a notes tree into our internal hash table, we also collect any files that are clearly non-notes. We format the name of the file into a PATH_MAX buffer, but unlike true notes (which cannot be larger than a fanned-out sha1 hash), these tree entries can be arbitrarily long, overflowing our buffer. We can fix this by switching to a strbuf. It doesn't even cost us an extra allocation, as we can simply hand ownership of the buffer over to the non-note struct. This is of moderate security interest, as you might fetch notes trees from an untrusted remote. However, we do not do so by default, so you would have to manually fetch into the notes namespace. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * verify_absent: allow filenames longer than PATH_MAXJeff King2015-09-041-7/+10
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When unpack-trees wants to know whether a path will overwrite anything in the working tree, we use lstat() to see if there is anything there. But if we are going to write "foo/bar", we can't just lstat("foo/bar"); we need to look for leading prefixes (e.g., "foo"). So we use the lstat cache to find the length of the leading prefix, and copy the filename up to that length into a temporary buffer (since the original name is const, we cannot just stick a NUL in it). The copy we make goes into a PATH_MAX-sized buffer, which will overflow if the prefix is longer than PATH_MAX. How this happens is a little tricky, since in theory PATH_MAX is the biggest path we will have read from the filesystem. But this can happen if: - the compiled-in PATH_MAX does not accurately reflect what the filesystem is capable of - the leading prefix is not _quite_ what is on disk; it contains the next element from the name we are checking. So if we want to write "aaa/bbb/ccc/ddd" and "aaa/bbb" exists, the prefix of interest is "aaa/bbb/ccc". If "aaa/bbb" approaches PATH_MAX, then "ccc" can overflow it. So this can be triggered, but it's hard to do. In particular, you cannot just "git clone" a bogus repo. The verify_absent checks happen before unpack-trees writes anything to the filesystem, so there are never any leading prefixes during the initial checkout, and the bug doesn't trigger. And by definition, these files are larger than PATH_MAX, so writing them will fail, and clone will complain (though it may write a partial path, which will cause a subsequent "git checkout" to hit the bug). We can fix it by creating the temporary path on the heap. The extra malloc overhead is not important, as we are already making at least one stat() call (and probably more for the prefix discovery). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Git 2.2.2v2.2.2Junio C Hamano2015-01-123-2/+33
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'jk/read-packed-refs-without-path-max' into maintJunio C Hamano2015-01-121-21/+25
|\ | | | | | | | | | | | | * jk/read-packed-refs-without-path-max: read_packed_refs: use skip_prefix instead of static array read_packed_refs: pass strbuf to parse_ref_line read_packed_refs: use a strbuf for reading lines
| * read_packed_refs: use skip_prefix instead of static arrayjk/read-packed-refs-without-path-maxJeff King2014-12-101-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | We want to recognize the packed-refs header and skip to the "traits" part of the line. We currently do it by feeding sizeof() a static const array to strncmp. However, it's a bit simpler to just skip_prefix, which expresses the intention more directly, and without remembering to account for the NUL-terminator in each sizeof() call. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * read_packed_refs: pass strbuf to parse_ref_lineJeff King2014-12-101-12/+15
| | | | | | | | | | | | | | | | | | Now that we have a strbuf in read_packed_refs, we can pass it straight to the line parser, which saves us an extra strlen. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * read_packed_refs: use a strbuf for reading linesJeff King2014-12-101-9/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current code uses a fixed PATH_MAX-sized buffer for reading packed-refs lines. This is a reasonable guess, in the sense that git generally cannot work with refs larger than PATH_MAX. However, there are a few cases where it is not great: 1. Some systems may have a low value of PATH_MAX, but can actually handle larger paths in practice. Fixing this code path probably isn't enough to make them work completely with long refs, but it is a step in the right direction. 2. We use fgets, which will happily give us half a line on the first read, and then the rest of the line on the second. This is probably OK in practice, because our refline parser is careful enough to look for the trailing newline on the first line. The second line may look like a peeled line to us, but since "^" is illegal in refnames, it is not likely to come up. Still, it does not hurt to be more careful. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'mg/add-ignore-errors' into maintJunio C Hamano2015-01-122-2/+8
|\ \ | | | | | | | | | | | | * mg/add-ignore-errors: add: ignore only ignored files
| * | add: ignore only ignored filesmg/add-ignore-errorsMichael J Gruber2014-11-212-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "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>
* | | Merge branch 'mh/find-uniq-abbrev' into maintJunio C Hamano2015-01-121-1/+1
|\ \ \ | | | | | | | | | | | | | | | | * mh/find-uniq-abbrev: sha1_name: avoid unnecessary sha1 lookup in find_unique_abbrev
| * | | sha1_name: avoid unnecessary sha1 lookup in find_unique_abbrevmh/find-uniq-abbrevMike Hommey2014-11-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An example where this happens is when doing an ls-tree on a tree that contains a commit link. In that case, find_unique_abbrev is called to get a non-abbreviated hex sha1, but still, a lookup is done as to whether the sha1 is in the repository (which ends up looking for a loose object in .git/objects), while the result of that lookup is not used when returning a non-abbreviated hex sha1. Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'jk/approxidate-avoid-y-d-m-over-future-dates' into maintJunio C Hamano2015-01-122-9/+15
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * | | | approxidate: allow ISO-like dates far in the futurejk/approxidate-avoid-y-d-m-over-future-datesJeff King2014-11-132-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | pass TIME_DATE_NOW to approxidate future-checkJeff King2014-11-131-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The approxidate functions accept an extra "now" parameter to avoid calling time() themselves. We use this in our test suite to make sure we have a consistent time for computing relative dates. However, deep in the bowels of approxidate, we also call time() to check whether possible dates are far in the future. Let's make sure that the "now" override makes it to that spot, too, so we can consistently test that feature. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | Merge branch 'rw/apply-does-not-take-ignore-date' into maintJunio C Hamano2015-01-121-1/+0
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | * rw/apply-does-not-take-ignore-date: git-am.txt: --ignore-date flag is not passed to git-apply
| * | | | | git-am.txt: --ignore-date flag is not passed to git-applyrw/apply-does-not-take-ignore-dateRonald Wampler2014-12-091-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Ronald Wampler <rdwampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | Merge branch 'jk/for-each-reflog-ent-reverse' into maintJunio C Hamano2015-01-122-12/+67
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * | | | | | for_each_reflog_ent_reverse: turn leftover check into assertionjk/for-each-reflog-ent-reverseJeff King2014-12-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our loop should always process all lines, even if we hit the beginning of the file. We have a conditional after the loop ends to double-check that there is nothing left and to process it. But this should never happen, and is a sign of a logic bug in the loop. Let's turn it into a BUG assertion. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | | for_each_reflog_ent_reverse: fix newlines on block boundariesJeff King2014-12-052-11/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | | | | Merge branch 'maint-2.1' into maintJunio C Hamano2015-01-072-12/+35
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * maint-2.1: is_hfs_dotgit: loosen over-eager match of \u{..47}
| * \ \ \ \ \ \ Merge branch 'maint-2.0' into maint-2.1maint-2.1Junio C Hamano2015-01-072-12/+35
| |\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * maint-2.0: is_hfs_dotgit: loosen over-eager match of \u{..47}
| | * \ \ \ \ \ \ Merge branch 'maint-1.9' into maint-2.0maint-2.0Junio C Hamano2015-01-072-12/+35
| | |\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * maint-1.9: is_hfs_dotgit: loosen over-eager match of \u{..47}
| | | * \ \ \ \ \ \ Merge branch 'maint-1.8.5' into maint-1.9maint-1.9Junio C Hamano2015-01-072-12/+35
| | | |\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * maint-1.8.5: is_hfs_dotgit: loosen over-eager match of \u{..47}
| | | | * \ \ \ \ \ \ Merge branch 'jk/dotgit-case-maint-1.8.5' into maint-1.8.5maint-1.8.5Junio C Hamano2015-01-072-12/+35
| | | | |\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * jk/dotgit-case-maint-1.8.5: is_hfs_dotgit: loosen over-eager match of \u{..47}
| | | | | * | | | | | | is_hfs_dotgit: loosen over-eager match of \u{..47}jk/dotgit-case-maint-1.8.5dotgit-case-maint-1.8.5Jeff King2014-12-292-12/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | | | | | | | | | Prepare for 2.2.2Junio C Hamano2014-12-222-1/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | | | | | | | Merge branch 'jk/rebuild-perl-scripts-with-no-perl-seting-change' into maintJunio C Hamano2014-12-221-4/+10
|\ \ \ \ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The build procedure did not bother fixing perl and python scripts when NO_PERL and NO_PYTHON build-time configuration changed. * jk/rebuild-perl-scripts-with-no-perl-seting-change: Makefile: have python scripts depend on NO_PYTHON setting Makefile: simplify by using SCRIPT_{PERL,SH}_GEN macros Makefile: have perl scripts depend on NO_PERL setting
| * | | | | | | | | | | | Makefile: have python scripts depend on NO_PYTHON settingjk/rebuild-perl-scripts-with-no-perl-seting-changeJonathan Nieder2014-11-181-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Like the perl scripts, python scripts need a dependency to ensure they are rebuilt when switching between the "dummy" versions that run without Python and the real thing. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | | | | | | | | Makefile: simplify by using SCRIPT_{PERL,SH}_GEN macrosJonathan Nieder2014-11-181-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SCRIPT_PERL_GEN is defined as $(patsubst %.perl,%,$(SCRIPT_PERL)) for use in targets like build-perl-script used by makefiles in subdirectories that override SCRIPT_PERL (see v1.8.2-rc0~17^2, "git-remote-mediawiki: use toplevel's Makefile", 2013-02-08). The same expression is used in the rules that actually write the generated perl scripts, and since these rules were introduced before SCRIPT_PERL_GEN, they use the longhand instead of that macro. Use the macro to make reading easier. Likewise for SCRIPT_SH_GEN. The Python rules already got the same simplification in v1.8.4-rc0~162^2~8 (2013-05-24). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | | | | | | | | Makefile: have perl scripts depend on NO_PERL settingJeff King2014-11-181-0/+3
| | |_|_|_|_|_|_|_|_|_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If NO_PERL is not set, our perl scripts are built as usual. If it is set, then we build "dummy" versions that tell you git was built without perl support and exit gracefully. However, if you switch to NO_PERL in a directory with existing build artifacts, we do not notice that the files need rebuilt. We see only that they are newer than the "unimplemented.sh" wrapper and assume they are done. So doing: make make NO_PERL=Nope would result in a git-add--interactive script that uses perl (and running the test suite would make use of it). Instead, we should trigger a rebuild of the perl scripts anytime NO_PERL changes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | | | | | | | Merge branch 'jk/no-perl-tests' into maintJunio C Hamano2014-12-223-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
| * | | | | | | | | | | | t960[34]: mark cvsimport tests as requiring perljk/no-perl-testsJeff King2014-11-182-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>
| * | | | | | | | | | | | t0090: mark add-interactive test with PERL prerequisiteJeff King2014-11-181-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>
* | | | | | | | | | | | | Merge branch 'po/everyday-doc' into maintJunio C Hamano2014-12-221-1/+1
|\ \ \ \ \ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "Everyday" document had a broken link. * po/everyday-doc: Documentation: change "gitlink" typo in git-push
| * | | | | | | | | | | | | Documentation: change "gitlink" typo in git-pushpo/everyday-docbrian m. carlson2014-11-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The git-push manual page used "gitlink" in one place instead of "linkgit". Fix this so the link renders correctly. Noticed-by: Dan Allen <dan.j.allen@gmail.com> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | | | | | | | | | Merge branch 'jk/push-simple' into maintJunio C Hamano2014-12-222-6/+34
|\ \ \ \ \ \ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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"
| * | | | | | | | | | | | | | push: truly use "simple" as default, not "upstream"jk/push-simpleJeff King2014-11-302-6/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | | | | | | | | | | | | Merge branch 'mh/config-flip-xbit-back-after-checking' into maintJunio C Hamano2014-12-222-1/+9
|\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "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
| * | | | | | | | | | | | | | | create_default_files(): don't set u+x bit on $GIT_DIR/configmh/config-flip-xbit-back-after-checkingMichael Haggerty2014-11-182-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | | | | | | | | | | | | | Merge branch 'jk/gitweb-with-newer-cgi-multi-param' into maintJunio C Hamano2014-12-221-1/+5
|\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "gitweb" used to depend on a behaviour that was deprecated by recent CGI.pm. * jk/gitweb-with-newer-cgi-multi-param: gitweb: hack around CGI's list-context param() handling
| * | | | | | | | | | | | | | | | gitweb: hack around CGI's list-context param() handlingjk/gitweb-with-newer-cgi-multi-paramJeff King2014-11-181-1/+5
| | |_|_|_|/ / / / / / / / / / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As of CGI.pm's 4.08 release, the behavior to call CGI::param() in a list context is deprecated (because it can be potentially unsafe if called inside a hash constructor). This causes gitweb to issue a warning for some of our code, which in turn causes the tests to fail. Our use is in fact _not_ one of the dangerous cases, as we are intentionally using a list context. The recommended route by 4.08 is to use the new CGI::multi_param() call to make it explicit that we know what we are doing. However, that function is only available in 4.08, which is about a month old; we cannot rely on having it. One option would be to set $CGI::LIST_CONTEXT_WARN globally, which turns off the warning. However, that would eliminate the protection these newer releases are trying to provide. We want to annotate each site as OK using the new function. So instead, let's check whether CGI provides the multi_param() function, and if not, provide an implementation that just wraps param(). That will work on both old and new versions of CGI. Sadly, we cannot just check defined(\&CGI::multi_param), because CGI uses the autoload feature, which claims that all functions are defined. Instead, we just do a version check. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | | | | | | | | | | | Merge branch 'rs/receive-pack-use-labs' into maintJunio C Hamano2014-12-221-1/+1
|\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * rs/receive-pack-use-labs: use labs() for variables of type long instead of abs()
| * | | | | | | | | | | | | | | | use labs() for variables of type long instead of abs()rs/receive-pack-use-labsRené Scharfe2014-11-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using abs() on long values can cause truncation, so use labs() instead. Reported by Clang 3.5 (-Wabsolute-value, enabled by -Wall). Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>