summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-01-28config.txt: clarify that add.ignore-errors is deprecatedLibravatar Junio C Hamano1-5/+4
The old text gave an impression that even in a new repository using old form might be safer. Only Git from pre 1.7.0 days choke on the correctly named variable, which is ancient by today's standard. We have no intention to remove the support for deprecated ones, but let's make sure that we do not give room for confused questions such as "why does core.sparse-checkout not work, when add.ignore-errors does?" Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-07Merge branch 'maint-2.0' into maint-2.1Libravatar Junio C Hamano2-12/+35
* 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 Hamano2-12/+35
* 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 Hamano2-12/+35
* 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 Hamano2-12/+35
* 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 King2-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>
2014-12-17Git 2.1.4Libravatar Junio C Hamano4-3/+38
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-17Sync with v2.0.5Libravatar Junio C Hamano18-41/+370
* 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-17Git 2.0.5Libravatar Junio C Hamano4-3/+38
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-17Sync with v1.9.5Libravatar Junio C Hamano17-40/+334
* 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-17Git 1.9.5Libravatar Junio C Hamano4-3/+38
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-17Sync with v1.8.5.6Libravatar Junio C Hamano16-39/+297
* 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-17Git 1.8.5.6Libravatar Junio C Hamano4-3/+38
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-17Merge branch 'dotgit-case-maint-1.8.5' into maint-1.8.5Libravatar Junio C Hamano14-38/+261
* 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 Schindelin2-3/+9
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 Schindelin7-0/+34
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-17path: add is_ntfs_dotgit() helperLibravatar Johannes Schindelin2-0/+34
We do not allow paths with a ".git" component to be added to the index, as that would mean repository contents could overwrite our repository files. However, asking "is this path the same as .git" is not as simple as strcmp() on some filesystems. On NTFS (and FAT32), there exist so-called "short names" for backwards-compatibility: 8.3 compliant names that refer to the same files as their long names. As ".git" is not an 8.3 compliant name, a short name is generated automatically, typically "git~1". Depending on the Windows version, any combination of trailing spaces and periods are ignored, too, so that both "git~1." and ".git." still refer to the Git directory. The reason is that 8.3 stores file names shorter than 8 characters with trailing spaces. So literally, it does not matter for the short name whether it is padded with spaces or whether it is shorter than 8 characters, it is considered to be the exact same. The period is the separator between file name and file extension, and again, an empty extension consists just of spaces in 8.3 format. So technically, we would need only take care of the equivalent of this regex: (\.git {0,4}|git~1 {0,3})\. {0,3} However, there are indications that at least some Windows versions might be more lenient and accept arbitrary combinations of trailing spaces and periods and strip them out. So we're playing it real safe here. Besides, there can be little doubt about the intention behind using file names matching even the more lenient pattern specified above, therefore we should be fine with disallowing such patterns. Extra care is taken to catch names such as '.\\.git\\booh' because the backslash is marked as a directory separator only on Windows, and we want to use this new helper function also in fsck on other platforms. A big thank you goes to Ed Thomson and an unnamed Microsoft engineer for the detailed analysis performed to come up with the corresponding fixes for libgit2. This commit adds a function to detect whether a given file name can refer to the Git directory by mistake. 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 King2-4/+7
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 King8-5/+45
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-17utf8: add is_hfs_dotgit() helperLibravatar Jeff King2-0/+72
We do not allow paths with a ".git" component to be added to the index, as that would mean repository contents could overwrite our repository files. However, asking "is this path the same as .git" is not as simple as strcmp() on some filesystems. HFS+'s case-folding does more than just fold uppercase into lowercase (which we already handle with strcasecmp). It may also skip past certain "ignored" Unicode code points, so that (for example) ".gi\u200ct" is mapped ot ".git". The full list of folds can be found in the tables at: https://www.opensource.apple.com/source/xnu/xnu-1504.15.3/bsd/hfs/hfscommon/Unicode/UCStringCompareData.h Implementing a full "is this path the same as that path" comparison would require us importing the whole set of tables. However, what we want to do is much simpler: we only care about checking ".git". We know that 'G' is the only thing that folds to 'g', and so on, so we really only need to deal with the set of ignored code points, which is much smaller. 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 King2-1/+2
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 King2-2/+4
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-17unpack-trees: propagate errors adding entries to the indexLibravatar Jeff King1-4/+6
When unpack_trees tries to write an entry to the index, add_index_entry may report an error to stderr, but we ignore its return value. This leads to us returning a successful exit code for an operation that partially failed. Let's make sure to propagate this code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-12Merge branch 'nd/gitignore-trailing-whitespace' into maintLibravatar Junio C Hamano1-1/+1
* nd/gitignore-trailing-whitespace: gitignore.txt: fix spelling of "backslash"
2014-11-11Merge branch 'rs/clean-menu-item-defn' into maintLibravatar Junio C Hamano1-1/+1
* rs/clean-menu-item-defn: clean: use f(void) instead of f() to declare a pointer to a function without arguments
2014-11-10Documentation/config.txt: fix minor typoLibravatar Thomas Quinot1-1/+1
Add a missing article at the beginning of a sentence, and rephrase slightly. Signed-off-by: Thomas Quinot <thomas@quinot.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-10config.txt: fix typoLibravatar Nicolas Dermine1-1/+1
Signed-off-by: Nicolas Dermine <nicolas.dermine@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-06docs/credential-store: s/--store/--file/Libravatar Jeff King1-1/+1
The option name "--store" was used early in development, but never even made it into an applied patch, let alone a released version of git. I forgot to update the matching documentation at the time, though. Noticed-by: Jesse Hopkins <jesse.hopkins@lmco.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-04gitignore.txt: fix spelling of "backslash"Libravatar Ben North1-1/+1
Signed-off-by: Ben North <ben@redfrontdoor.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-29Git 2.1.3Libravatar Junio C Hamano4-3/+30
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-29Merge branch 'jk/pack-objects-no-bitmap-when-splitting' into maintLibravatar Junio C Hamano2-0/+10
* jk/pack-objects-no-bitmap-when-splitting: pack-objects: turn off bitmaps when we split packs
2014-10-29Merge branch 'da/mergetool-meld' into maintLibravatar Junio C Hamano2-2/+16
* da/mergetool-meld: mergetools/meld: make usage of `--output` configurable and more robust
2014-10-29Merge branch 'rm/gitweb-start-form' into maintLibravatar Junio C Hamano1-2/+2
* rm/gitweb-start-form: gitweb: use start_form, not startform that was removed in CGI.pm 4.04
2014-10-29Merge branch 'bc/asciidoc-pretty-formats-fix' into maintLibravatar Junio C Hamano1-1/+1
* bc/asciidoc-pretty-formats-fix: Documentation: fix misrender of pretty-formats in Asciidoctor
2014-10-29Merge branch 'rs/daemon-fixes' into maintLibravatar Junio C Hamano1-18/+15
* rs/daemon-fixes: daemon: remove write-only variable maxfd daemon: fix error message after bind() daemon: handle gethostbyname() error
2014-10-19pack-objects: turn off bitmaps when we split packsLibravatar Jeff King2-0/+10
If a pack.packSizeLimit is set, we may split the pack data across multiple packfiles. This means we cannot generate .bitmap files, as they require that all of the reachable objects are in the same pack. We check that condition when we are generating the list of objects to pack (and disable bitmaps if we are not packing everything), but we forgot to update it when we notice that we needed to split (which doesn't happen until the actual write phase). The resulting bitmaps are quite bogus (they mention entries that do not exist in the pack!) and can cause a fetch or push to send insufficient objects. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-16gitweb: use start_form, not startform that was removed in CGI.pm 4.04Libravatar Roland Mas1-2/+2
CGI.pm 4.04 removed the startform method, which had previously been deprecated in favour of start_form. Changes file for CGI.pm says: 4.04 2014-09-04 [ REMOVED / DEPRECATIONS ] - startform and endform methods removed (previously deprecated, you should be using the start_form and end_form methods) Signed-off-by: Roland Mas <lolando@debian.org> Reviewed-by: Jakub Narębski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-16mergetools/meld: make usage of `--output` configurable and more robustLibravatar David Aguilar2-2/+16
Older versions of meld listed --output in `meld --help`. Newer versions only mention `meld [OPTIONS...]`. Improve the checks to catch these newer versions. Add a `mergetool.meld.hasOutput` configuration to allow overriding the heuristic. Reported-by: Andrey Novoseltsev <novoselt@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-08Documentation: fix misrender of pretty-formats in AsciidoctorLibravatar brian m. carlson1-1/+1
Neither the AsciiDoc nor the Asciidoctor documentation specify whether the same number of delimiter characters must be used to end a block as to begin it, although both sets of documentation show exactly matching pairs. AsciiDoc allows mismatches, but AsciiDoctor apparently does not. Adjust the pretty formats documentation to use matching pairs to prevent a misrendering where the remainder of the document was rendered as a listing block. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-07Merge branch 'maint-2.0' into maintLibravatar Junio C Hamano1-1/+1
* maint-2.0: git-tag.txt: Add a missing hyphen to `-s`
2014-10-07Merge branch 'maint-1.9' into maint-2.0Libravatar Junio C Hamano1-1/+1
* maint-1.9: git-tag.txt: Add a missing hyphen to `-s`
2014-10-07Merge branch 'maint-1.8.5' into maint-1.9Libravatar Junio C Hamano1-1/+1
* maint-1.8.5: git-tag.txt: Add a missing hyphen to `-s`
2014-10-07Merge branch 'jk/mbox-from-line' into maintLibravatar Junio C Hamano6-1/+66
Some MUAs mangled a line in a message that begins with "From " to ">From " when writing to a mailbox file and feeding such an input to "git am" used to lose such a line. * jk/mbox-from-line: mailinfo: work around -Wstring-plus-int warning mailinfo: make ">From" in-body header check more robust
2014-10-07git-tag.txt: Add a missing hyphen to `-s`Libravatar Wieland Hoffmann1-1/+1
Signed-off-by: Wieland Hoffmann <themineo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-01daemon: remove write-only variable maxfdLibravatar René Scharfe1-4/+0
It became unused when 6573faff (NO_IPV6 support for git daemon) replaced select() with poll(). Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-01daemon: fix error message after bind()Libravatar René Scharfe1-1/+1
Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-01daemon: handle gethostbyname() errorLibravatar René Scharfe1-13/+14
If the user-supplied hostname can't be found then we should not use it. We already avoid doing that in the non-NO_IPV6 case by checking if the return value of getaddrinfo() is zero (success). Do the same in the NO_IPV6 case and make sure the return value of gethostbyname() isn't NULL before dereferencing this pointer. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-29Git 2.1.2Libravatar Junio C Hamano4-3/+24
Signed-off-by: Junio C Hamano <gitster@pobox.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-24 07:35:02 +0000