Skip to main content

Browse the archive

https://github.com/git/git
31 May 2024, 23:06:24 UTC
sort by:
Revision Author Date Message Commit Date
5c8213a Junio C Hamano 17 December 2014, 19:18:45 UTC Git 1.8.5.6 Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 December 2014, 19:18:45 UTC
2aa9100 Junio C Hamano 17 December 2014, 19:11:15 UTC Merge branch 'dotgit-case-maint-1.8.5' into maint-1.8.5 * 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 17 December 2014, 19:11:15 UTC
d08c13b Johannes Schindelin 10 December 2014, 21:28:27 UTC fsck: complain about NTFS ".git" aliases in trees 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> 17 December 2014, 19:04:45 UTC
2b4c6ef Johannes Schindelin 16 December 2014, 22:46:59 UTC read-cache: optionally disallow NTFS .git variants 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> 17 December 2014, 19:04:45 UTC
1d1d69b Johannes Schindelin 16 December 2014, 22:31:03 UTC path: add is_ntfs_dotgit() helper 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> 17 December 2014, 19:04:45 UTC
a18fcc9 Jeff King 15 December 2014, 23:21:57 UTC fsck: complain about HFS+ ".git" aliases in trees 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> 17 December 2014, 19:04:45 UTC
a42643a Jeff King 15 December 2014, 23:15:20 UTC read-cache: optionally disallow HFS+ .git variants 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> 17 December 2014, 19:04:44 UTC
6162a1d Jeff King 15 December 2014, 22:56:59 UTC utf8: add is_hfs_dotgit() helper 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> 17 December 2014, 19:04:39 UTC
76e86fc Jeff King 24 November 2014, 18:40:44 UTC fsck: notice .git case-insensitively 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> 17 December 2014, 19:04:39 UTC
450870c Jeff King 24 November 2014, 18:40:11 UTC t1450: refactor ".", "..", and ".git" fsck tests 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> 17 December 2014, 19:04:39 UTC
cc2fc7c Jeff King 24 November 2014, 18:39:12 UTC verify_dotfile(): reject .git case-insensitively 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> 17 December 2014, 19:04:31 UTC
96b50cc Jeff King 24 November 2014, 18:37:56 UTC read-tree: add tests for confusing paths like ".." and ".git" 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> 17 December 2014, 19:00:37 UTC
4616918 Jeff King 24 November 2014, 18:36:51 UTC unpack-trees: propagate errors adding entries to the index 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> 17 December 2014, 18:57:53 UTC
eeff891 Wieland Hoffmann 04 October 2014, 16:27:16 UTC git-tag.txt: Add a missing hyphen to `-s` Signed-off-by: Wieland Hoffmann <themineo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 October 2014, 18:08:06 UTC
e6aaa39 brian m. carlson 21 July 2014, 23:00:35 UTC Documentation: fix missing text for rev-parse --verify The caret (^) is used as a markup symbol in AsciiDoc. Due to the inability of AsciiDoc to parse a line containing an unmatched caret, it omitted the line from the output, resulting in the man page missing the end of a sentence. Escape this caret so that the man page ends up with the complete text. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 July 2014, 17:10:57 UTC
8c2cfa5 René Scharfe 16 July 2014, 08:51:33 UTC annotate: use argv_array Simplify the code and get rid of some magic constants by using argv_array to build the argument list for cmd_blame. Be lazy and let the OS release our allocated memory, as before. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 July 2014, 18:10:11 UTC
45067fc Jeff King 02 July 2014, 18:44:30 UTC t7300: repair filesystem permissions with test_when_finished We create a directory that cannot be removed, confirm that it cannot be removed, and then fix it like: chmod 0 foo && test_must_fail git clean -d -f && chmod 755 foo If the middle step fails but leaves the directory (e.g., the bug is that clean does not notice the failure), this pollutes the test repo with an unremovable directory. Not only does this cause further tests to fail, but it means that "rm -rf" fails on the whole trash directory, and the user has to intervene manually to even re-run the test script. We can bump the "chmod 755" recovery to a test_when_finished block to be sure that it always runs. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 July 2014, 19:51:38 UTC
7827352 Ronnie Sahlberg 02 July 2014, 18:24:05 UTC enums: remove trailing ',' after last item in enum Signed-off-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 July 2014, 19:37:05 UTC
7bbc4e8 Junio C Hamano 13 February 2014, 21:40:47 UTC Git 1.8.5.5 Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 February 2014, 21:41:53 UTC
2cd8616 Junio C Hamano 13 February 2014, 21:38:59 UTC Merge branch 'bm/merge-base-octopus-dedup' into maint "git merge-base --octopus" used to leave cleaning up suboptimal result to the caller, but now it does the clean-up itself. * bm/merge-base-octopus-dedup: merge-base --octopus: reduce the result from get_octopus_merge_bases() merge-base: separate "--independent" codepath into its own helper 13 February 2014, 21:38:59 UTC
5032098 Junio C Hamano 13 February 2014, 21:38:47 UTC Merge branch 'jc/revision-range-unpeel' into maint "git log --left-right A...B" lost the "leftness" of commits reachable from A when A is a tag as a side effect of a recent bugfix. This is a regression in 1.8.4.x series. * jc/revision-range-unpeel: revision: propagate flag bits from tags to pointees revision: mark contents of an uninteresting tree uninteresting 13 February 2014, 21:38:47 UTC
c337684 Junio C Hamano 13 February 2014, 21:38:34 UTC Merge branch 'jk/allow-fetch-onelevel-refname' into maint "git clone" would fail to clone from a repository that has a ref directly under "refs/", e.g. "refs/stash", because different validation paths do different things on such a refname. Loosen the client side's validation to allow such a ref. * jk/allow-fetch-onelevel-refname: fetch-pack: do not filter out one-level refs 13 February 2014, 21:38:34 UTC
21261fa Junio C Hamano 13 February 2014, 21:38:25 UTC Merge branch 'jk/interpret-branch-name-fix' into maint A handful of bugs around interpreting $branch@{upstream} notation and its lookalike, when $branch part has interesting characters, e.g. "@", and ":", have been fixed. * jk/interpret-branch-name-fix: interpret_branch_name: find all possible @-marks interpret_branch_name: avoid @{upstream} past colon interpret_branch_name: always respect "namelen" parameter interpret_branch_name: rename "cp" variable to "at" interpret_branch_name: factor out upstream handling 13 February 2014, 21:38:25 UTC
7c9b668 Junio C Hamano 13 February 2014, 21:38:19 UTC Merge branch 'rk/send-email-ssl-cert' into maint A recent update to "git send-email" broke platforms where /etc/ssl/certs/ directory exists but cannot be used as SSL_ca_path (e.g. Fedora rawhide). * rk/send-email-ssl-cert: send-email: /etc/ssl/certs/ directory may not be usable as ca_path 13 February 2014, 21:38:19 UTC
90791e3 Junio C Hamano 13 February 2014, 21:38:09 UTC Merge branch 'sb/repack-in-c' into maint "git repack --max-pack-size=8g" stopped being parsed correctly when the command was reimplemented in C. * sb/repack-in-c: repack: propagate pack-objects options as strings repack: make parsed string options const-correct repack: fix typo in max-pack-size option 13 February 2014, 21:38:09 UTC
b4e931d Junio C Hamano 13 February 2014, 21:37:53 UTC Merge branch 'as/tree-walk-fix-aggressive-short-cut' into maint The pathspec matching code, while comparing two trees (e.g. "git diff A B -- path1 path2") was too aggressive and failed to match some paths when multiple pathspecs were involved. * as/tree-walk-fix-aggressive-short-cut: tree_entry_interesting: match against all pathspecs 13 February 2014, 21:37:53 UTC
3330a2c Junio C Hamano 05 February 2014, 22:05:31 UTC Git 1.8.5.4 Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 February 2014, 22:13:23 UTC
01a5774 Junio C Hamano 05 February 2014, 22:03:47 UTC Merge branch 'jc/maint-pull-docfix' into maint The documentation to "git pull" hinted there is an "-m" option because it incorrectly shared the documentation with "git merge". * jc/maint-pull-docfix: Documentation: "git pull" does not have the "-m" option Documentation: exclude irrelevant options from "git pull" 05 February 2014, 22:03:47 UTC
a74a682 Junio C Hamano 05 February 2014, 22:03:20 UTC Merge branch 'ow/stash-with-ifs' into maint The implementation of 'git stash $cmd "stash@{...}"' did not quote the stash argument properly and left it split at IFS whitespace. * ow/stash-with-ifs: stash: handle specifying stashes with $IFS 05 February 2014, 22:03:20 UTC
3c86474 Junio C Hamano 05 February 2014, 22:03:01 UTC Merge branch 'js/lift-parent-count-limit' into maint There is no reason to have a hardcoded upper limit of the number of parents for an octopus merge, created via the graft mechanism, but there was. * js/lift-parent-count-limit: Remove the line length limit for graft files 05 February 2014, 22:03:01 UTC
ee5788e Junio C Hamano 05 February 2014, 22:02:44 UTC Merge branch 'nd/add-empty-fix' into maint "git add -A" (no other arguments) in a totally empty working tree used to emit an error. * nd/add-empty-fix: add: don't complain when adding empty project root 05 February 2014, 22:02:44 UTC
d11ade7 Junio C Hamano 05 February 2014, 22:02:05 UTC Merge branch 'bc/log-decoration' into maint "git log --decorate" did not handle a tag pointed by another tag nicely. * bc/log-decoration: log: properly handle decorations with chained tags 05 February 2014, 22:02:05 UTC
2885624 Junio C Hamano 05 February 2014, 22:01:23 UTC Merge branch 'jh/rlimit-nofile-fallback' into maint When we figure out how many file descriptors to allocate for keeping packfiles open, a system with non-working getrlimit() could cause us to die(), but because we make this call only to get a rough estimate of how many is available and we do not even attempt to use up all file descriptors available ourselves, it is nicer to fall back to a reasonable low value rather than dying. * jh/rlimit-nofile-fallback: get_max_fd_limit(): fall back to OPEN_MAX upon getrlimit/sysconf failure 05 February 2014, 22:01:23 UTC
a118bee Junio C Hamano 05 February 2014, 22:01:09 UTC Merge branch 'jl/commit-v-strip-marker' into maint "git commit -v" appends the patch to the log message before editing, and then removes the patch when the editor returned control. However, the patch was not stripped correctly when the first modified path was a submodule. * jl/commit-v-strip-marker: commit -v: strip diffs and submodule shortlogs from the commit message 05 February 2014, 22:01:09 UTC
ac0835f Junio C Hamano 05 February 2014, 22:00:18 UTC Merge branch 'tr/send-email-ssl' into maint SSL-related options were not passed correctly to underlying socket layer in "git send-email". * tr/send-email-ssl: send-email: set SSL options through IO::Socket::SSL::set_client_defaults send-email: --smtp-ssl-cert-path takes an argument send-email: pass Debug to Net::SMTP::SSL::new 05 February 2014, 22:00:18 UTC
1a11195 Junio C Hamano 05 February 2014, 21:59:16 UTC Merge branch 'tb/clone-ssh-with-colon-for-port' into maint Remote repository URL expressed in scp-style host:path notation are parsed more carefully (e.g. "foo/bar:baz" is local, "[::1]:/~user" asks to connect to user's home directory on host at address ::1. * tb/clone-ssh-with-colon-for-port: git_connect(): use common return point connect.c: refactor url parsing git_connect(): refactor the port handling for ssh git fetch: support host:/~repo t5500: add test cases for diag-url git fetch-pack: add --diag-url git_connect: factor out discovery of the protocol and its parts git_connect: remove artificial limit of a remote command t5601: add tests for ssh t5601: remove clear_ssh, refactor setup_ssh_wrapper 05 February 2014, 21:59:16 UTC
bf03d6e Junio C Hamano 05 February 2014, 21:58:51 UTC Merge branch 'nd/transport-positive-depth-only' into maint "git fetch --depth=0" was a no-op, and was silently ignored. Diagnose it as an error. * nd/transport-positive-depth-only: clone,fetch: catch non positive --depth option value 05 February 2014, 21:58:52 UTC
e4ddb05 Andy Spencer 25 January 2014, 22:06:46 UTC tree_entry_interesting: match against all pathspecs The current basedir compare aborts early in order to avoid futile recursive searches. However, a match may still be found by another pathspec. This can cause an error while checking out files from a branch when using multiple pathspecs: $ git checkout master -- 'a/*.txt' 'b/*.txt' error: pathspec 'a/*.txt' did not match any file(s) known to git. Signed-off-by: Andy Spencer <andy753421@gmail.com> Acked-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 January 2014, 17:01:50 UTC
b861e23 Jeff King 23 January 2014, 01:30:13 UTC repack: propagate pack-objects options as strings In the original shell version of git-repack, any options destined for pack-objects were left as strings, and passed as a whole. Since the C rewrite in commit a1bbc6c (repack: rewrite the shell script in C, 2013-09-15), we now parse these values to integers internally, then reformat the integers when passing the option to pack-objects. This has the advantage that we catch format errors earlier (i.e., when repack is invoked, rather than when pack-objects is invoked). It has three disadvantages, though: 1. Our internal data types may not be the right size. In the case of "--window-memory" and "--max-pack-size", these are "unsigned long" in pack-objects, but we can only represent a regular "int". 2. Our parsing routines might not be the same as those of pack-objects. For the two options above, pack-objects understands "100m" to mean "100 megabytes", but repack does not. 3. We have to keep a sentinel value to know whether it is worth passing the option along. In the case of "--window-memory", we currently do not pass it if the value is "0". But that is a meaningful value to pack-objects, where it overrides any configured value. We can fix all of these by simply passing the strings from the user along to pack-objects verbatim. This does not actually fix anything for "--depth" or "--window", but these are converted, too, for consistency. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 January 2014, 18:34:53 UTC
aa8bd51 Jeff King 23 January 2014, 01:28:30 UTC repack: make parsed string options const-correct When we use OPT_STRING to parse an option, we get back a pointer into the argv array, which should be "const char *". The compiler doesn't notice because it gets passed through a "void *" in the option struct. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 January 2014, 18:34:51 UTC
44b96ec Jeff King 23 January 2014, 01:27:52 UTC repack: fix typo in max-pack-size option When we see "--max-pack-size", we accidentally propagated this to pack-objects as "--max_pack_size", which does not work at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 January 2014, 18:34:49 UTC
ac93028 Roman Kagan 27 December 2013, 08:05:15 UTC git-svn: workaround for a bug in svn serf backend Subversion serf backend in versions 1.8.5 and below has a bug(*) that the function creating the descriptor of a file change -- add_file() -- doesn't make a copy of its third argument when storing it on the returned descriptor. As a result, by the time this field is used (in transactions of file copying or renaming) it may well be released, and the memory reused. One of its possible manifestations is the svn assertion triggering on an invalid path, with a message svn_fspath__skip_ancestor: Assertion `svn_fspath__is_canonical(child_fspath)' failed. This patch works around this bug, by storing the value to be passed as the third argument to add_file() in a local variable with the same scope as the file change descriptor, making sure their lifetime is the same. * [ew: fixed in Subversion r1553376 as noted by Jonathan Nieder] Cc: Benjamin Pabst <benjamin.pabst85@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Roman Kagan <rkagan@mail.ru> 17 January 2014, 19:24:30 UTC
01645b7 Ruben Kerkhof 15 January 2014, 17:31:11 UTC send-email: /etc/ssl/certs/ directory may not be usable as ca_path When sending patches on Fedora rawhide with git-1.8.5.2-1.fc21.x86_64 and perl-IO-Socket-SSL-1.962-1.fc21.noarch, with the following [sendemail] smtpencryption = tls smtpserver = smtp.gmail.com smtpuser = ruben@rubenkerkhof.com smtpserverport = 587 git-send-email fails with: STARTTLS failed! SSL connect attempt failed with unknown error error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed at /usr/libexec/git-core/git-send-email line 1236. The current code detects the presence of /etc/ssl/certs directory (it actually is a symlink to another directory, but that does not matter) and uses SSL_ca_path to point at it when initializing the connection with IO::Socket::SSL or Net::SMTP::SSL. However, on the said platform, it seems that this directory is not designed to be used as SSL_ca_path. Using a single file inside that directory (cert.pem, which is a Mozilla CA bundle) with SSL_ca_file does work, and also not specifying any SSL_ca_file/SSL_ca_path (and letting the library use its own default) and asking for peer verification does work. By removing the code that blindly defaults $smtp_ssl_cert_path to "/etc/ssl/certs", we can prevent the codepath that treats any directory specified with that variable as usable for SSL_ca_path from incorrectly triggering. This change could introduce a regression for people on a platform whose certificate directory is /etc/ssl/certs but its IO::Socket:SSL somehow fails to use it as SSL_ca_path without being told. Using /etc/ssl/certs directory as SSL_ca_path by default like the current code does would have been hiding such a broken installation without its user needing to do anything. These users can still work around such a platform bug by setting the configuration variable explicitly to point at /etc/ssl/certs. This change should not negate what 35035bbf (send-email: be explicit with SSL certificate verification, 2013-07-18), which was the original change that introduced the defaulting to /etc/ssl/certs/, attempted to do, which is to make sure we do not communicate over insecure connection by default, triggering warning from the library. Cf. https://bugzilla.redhat.com/show_bug.cgi?id=1043194 Tested-by: Igor Gnatenko <i.gnatenko.brain@gmail.com> Signed-off-by: Ruben Kerkhof <ruben@rubenkerkhof.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 January 2014, 22:34:51 UTC
a743528 Junio C Hamano 15 January 2014, 20:26:13 UTC revision: propagate flag bits from tags to pointees With the previous fix 895c5ba3 (revision: do not peel tags used in range notation, 2013-09-19), handle_revision_arg() that processes command line arguments for the "git log" family of commands no longer directly places the object pointed by the tag in the pending object array when it sees a tag object. We used to place pointee there after copying the flag bits like UNINTERESTING and SYMMETRIC_LEFT. This change meant that any flag that is relevant to later history traversal must now be propagated to the pointed objects (most often these are commits) while starting the traversal, which is partly done by handle_commit() that is called from prepare_revision_walk(). We did propagate UNINTERESTING, but did not do so for others, most notably SYMMETRIC_LEFT. This caused "git log --left-right v1.0..." (where "v1.0" is a tag) to start losing the "leftness" from the commit the tag points at. Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 January 2014, 23:53:51 UTC
2ac5e44 Junio C Hamano 15 January 2014, 23:38:01 UTC revision: mark contents of an uninteresting tree uninteresting "git rev-list --objects ^A^{tree} B^{tree}" ought to mean "I want a list of objects inside B's tree, but please exclude the objects that appear inside A's tree". we see the top-level tree marked as uninteresting (i.e. ^A^{tree} in the above example) and call mark_tree_uninteresting() on it; this unfortunately prevents us from recursing into the tree and marking the objects in the tree as uninteresting. The reason why "git log ^A A" yields an empty set of commits, i.e. we do not have a similar issue for commits, is because we call mark_parents_uninteresting() after seeing an uninteresting commit. The uninteresting-ness of the commit itself does not prevent its parents from being marked as uninteresting. Introduce mark_tree_contents_uninteresting() and structure the code in handle_commit() in such a way that it makes it the responsibility of the callchain leading to this function to mark commits, trees and blobs as uninteresting, and also make it the responsibility of the helpers called from this function to mark objects that are reachable from them. Note that this is a very old bug that probably dates back to the day when "rev-list --objects" was introduced. The line to clear tree->object.parsed at the end of mark_tree_contents_uninteresting() can be removed when this fix is merged to the codebase after 6e454b9a (clear parsed flag when we free tree buffers, 2013-06-05). Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 January 2014, 23:48:58 UTC
9892d5d Jeff King 15 January 2014, 08:40:46 UTC interpret_branch_name: find all possible @-marks When we parse a string like "foo@{upstream}", we look for the first "@"-sign, and check to see if it is an upstream mark. However, since branch names can contain an @, we may also see "@foo@{upstream}". In this case, we check only the first @, and ignore the second. As a result, we do not find the upstream. We can solve this by iterating through all @-marks in the string, and seeing if any is a legitimate upstream or empty-at mark. Another strategy would be to parse from the right-hand side of the string. However, that does not work for the "empty_at" case, which allows "@@{upstream}". We need to find the left-most one in this case (and we then recurse as "HEAD@{upstream}"). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 January 2014, 20:51:14 UTC
3f6eb30 Jeff King 15 January 2014, 08:37:23 UTC interpret_branch_name: avoid @{upstream} past colon get_sha1() cannot currently parse a valid object name like "HEAD:@{upstream}" (assuming that such an oddly named file exists in the HEAD commit). It takes two passes to parse the string: 1. It first considers the whole thing as a ref, which results in looking for the upstream of "HEAD:". 2. It finds the colon, parses "HEAD" as a tree-ish, and then finds the path "@{upstream}" in the tree. For a path that looks like a normal reflog (e.g., "HEAD:@{yesterday}"), the first pass is a no-op. We try to dwim_ref("HEAD:"), that returns zero refs, and we proceed with colon-parsing. For "HEAD:@{upstream}", though, the first pass ends up in interpret_upstream_mark, which tries to find the branch "HEAD:". When it sees that the branch does not exist, it actually dies rather than returning an error to the caller. As a result, we never make it to the second pass. One obvious way of fixing this would be to teach interpret_upstream_mark to simply report "no, this isn't an upstream" in such a case. However, that would make the error-reporting for legitimate upstream cases significantly worse. Something like "bogus@{upstream}" would simply report "unknown revision: bogus@{upstream}", while the current code diagnoses a wide variety of possible misconfigurations (no such branch, branch exists but does not have upstream, etc). However, we can take advantage of the fact that a branch name cannot contain a colon. Therefore even if we find an upstream mark, any prefix with a colon must mean that the upstream mark we found is actually a pathname, and should be disregarded completely. This patch implements that logic. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 January 2014, 20:43:29 UTC
8cd4249 Jeff King 15 January 2014, 08:31:57 UTC interpret_branch_name: always respect "namelen" parameter interpret_branch_name gets passed a "name" buffer to parse, along with a "namelen" parameter representing its length. If "namelen" is zero, we fallback to the NUL-terminated string-length of "name". However, it does not necessarily follow that if we have gotten a non-zero "namelen", it is the NUL-terminated string-length of "name". E.g., when get_sha1() is parsing "foo:bar", we will be asked to operate only on the first three characters. Yet in interpret_branch_name and its helpers, we use string functions like strchr() to operate on "name", looking past the length we were given. This can result in us mis-parsing object names. We should instead be limiting our search to "namelen" bytes. There are three distinct types of object names this patch addresses: - The intrepret_empty_at helper uses strchr to find the next @-expression after our potential empty-at. In an expression like "@:foo@bar", it erroneously thinks that the second "@" is relevant, even if we were asked only to look at the first character. This case is easy to trigger (and we test it in this patch). - When finding the initial @-mark for @{upstream}, we use strchr. This means we might treat "foo:@{upstream}" as the upstream for "foo:", even though we were asked only to look at "foo". We cannot test this one in practice, because it is masked by another bug (which is fixed in the next patch). - The interpret_nth_prior_checkout helper did not receive the name length at all. This turns out not to be a problem in practice, though, because its parsing is so limited: it always starts from the far-left of the string, and will not tolerate a colon (which is currently the only way to get a smaller-than-strlen "namelen"). However, it's still worth fixing to make the code more obviously correct, and to future-proof us against callers with more exotic buffers. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 January 2014, 20:41:03 UTC
f278f40 Jeff King 15 January 2014, 08:27:32 UTC interpret_branch_name: rename "cp" variable to "at" In the original version of this function, "cp" acted as a pointer to many different things. Since the refactoring in the last patch, it only marks the at-sign in the string. Let's use a more descriptive variable name. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 January 2014, 20:38:47 UTC
a39c14a Jeff King 15 January 2014, 08:26:33 UTC interpret_branch_name: factor out upstream handling This function checks a few different @{}-constructs. The early part checks for and dispatches us to helpers for each construct, but the code for handling @{upstream} is inline. Let's factor this out into its own function. This makes interpret_branch_name more readable, and will make it much simpler to further refactor the function in future patches. While we're at it, let's also break apart the refactored code into a few helper functions. These will be useful if we eventually implement similar @{upstream}-like constructs. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 January 2014, 20:38:30 UTC
4c22408 Jeff King 15 January 2014, 10:46:13 UTC fetch-pack: do not filter out one-level refs Currently fetching a one-level ref like "refs/foo" does not work consistently. The outer "git fetch" program filters the list of refs, checking each against check_refname_format. Then it feeds the result to do_fetch_pack to actually negotiate the haves/wants and get the pack. The fetch-pack code does its own filter, and it behaves differently. The fetch-pack filter looks for refs in "refs/", and then feeds everything _after_ the slash (i.e., just "foo") into check_refname_format. But check_refname_format is not designed to look at a partial refname. It complains that the ref has only one component, thinking it is at the root (i.e., alongside "HEAD"), when in reality we just fed it a partial refname. As a result, we omit a ref like "refs/foo" from the pack request, even though "git fetch" then tries to store the resulting ref. If we happen to get the object anyway (e.g., because the ref is contained in another ref we are fetching), then the fetch succeeds. But if it is a unique object, we fail when trying to update "refs/foo". We can fix this by just passing the whole refname into check_refname_format; we know the part we were omitting is "refs/", which is acceptable in a refname. This at least makes the checks consistent with each other. This problem happens most commonly with "refs/stash", which is the only one-level ref in wide use. However, our test does not use "refs/stash", as we may later want to restrict it specifically (not because it is one-level, but because of the semantics of stashes). We may also want to do away with the multiple levels of filtering (which can cause problems when they are out of sync), or even forbid one-level refs entirely. However, those decisions can come later; this fixes the most immediate problem, which is the mismatch between the two. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 January 2014, 20:37:24 UTC
08f19cf Junio C Hamano 14 January 2014, 18:26:21 UTC Documentation: "git pull" does not have the "-m" option Even though "--[no-]edit" can be used with "git pull", the explanation of the interaction between this option and the "-m" option does not make sense within the context of "git pull". Use the conditional inclusion mechanism to remove this part from "git pull" documentation, while keeping it for "git merge". Reported-by: Ivan Zakharyaschev Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 January 2014, 18:47:36 UTC
8be1d04 Junio C Hamano 14 January 2014, 18:47:09 UTC Merge branch 'jc/maint-pull-docfix-for-409b8d82' into jc/maint-pull-docfix * jc/maint-pull-docfix-for-409b8d82: Documentation: exclude irrelevant options from "git pull" 14 January 2014, 18:47:09 UTC
d51a475 Junio C Hamano 14 January 2014, 18:26:21 UTC Documentation: exclude irrelevant options from "git pull" 10eb64f5 (git pull manpage: don't include -n from fetch-options.txt, 2008-01-25) introduced a way to exclude some parts of included source when building git-pull documentation, and later 409b8d82 (Documentation/git-pull: put verbosity options before merge/fetch ones, 2010-02-24) attempted to use the mechanism to exclude some parts of merge-options.txt when used from git-pull.txt. However, the latter did not have an intended effect, because the macro "git-pull" used to decide if the source is included in git-pull documentation were defined a bit too late. Define the macro before it is used to fix this. Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 January 2014, 18:46:17 UTC
4224916 Junio C Hamano 13 January 2014, 19:28:26 UTC Git 1.8.5.3 13 January 2014, 19:28:26 UTC
7fd90e0 Junio C Hamano 13 January 2014, 19:23:07 UTC Merge branch 'nd/daemon-informative-errors-typofix' into maint The "--[no-]informative-errors" options to "git daemon" were parsed a bit too loosely, allowing any other string after these option names. * nd/daemon-informative-errors-typofix: daemon: be strict at parsing parameters --[no-]informative-errors 13 January 2014, 19:23:07 UTC
3b72885 Junio C Hamano 13 January 2014, 19:23:04 UTC Merge branch 'km/gc-eperm' into maint A "gc" process running as a different user should be able to stop a new "gc" process from starting. * km/gc-eperm: gc: notice gc processes run by other users 13 January 2014, 19:23:04 UTC
f5678f1 Junio C Hamano 13 January 2014, 19:23:01 UTC Merge branch 'jk/credential-plug-leak' into maint An earlier "clean-up" introduced an unnecessary memory leak. * jk/credential-plug-leak: Revert "prompt: clean up strbuf usage" 13 January 2014, 19:23:01 UTC
ada6ebb Junio C Hamano 13 January 2014, 19:22:48 UTC Merge branch 'mm/mv-file-to-no-such-dir-with-slash' into maint "git mv A B/", when B does not exist as a directory, should error out, but it didn't. * mm/mv-file-to-no-such-dir-with-slash: mv: let 'git mv file no-such-dir/' error out on Windows, too mv: let 'git mv file no-such-dir/' error out 13 January 2014, 19:22:48 UTC
be941a2 Junio C Hamano 13 January 2014, 19:22:38 UTC Merge branch 'jk/rev-parse-double-dashes' into maint "git rev-parse <revs> -- <paths>" did not implement the usual disambiguation rules the commands in the "git log" family used in the same way. * jk/rev-parse-double-dashes: rev-parse: be more careful with munging arguments rev-parse: correctly diagnose revision errors before "--" 13 January 2014, 19:22:38 UTC
6845e8a Junio C Hamano 13 January 2014, 19:22:21 UTC Merge branch 'jk/cat-file-regression-fix' into maint "git cat-file --batch=", an admittedly useless command, did not behave very well. * jk/cat-file-regression-fix: cat-file: handle --batch format with missing type/size cat-file: pass expand_data to print_object_or_die 13 January 2014, 19:22:21 UTC
ebba6c0 Thomas Ackermann 11 January 2014, 16:28:25 UTC pack-heuristics.txt: mark up the file header properly AsciiDoc wants these header-lines left-aligned. Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 January 2014, 19:18:34 UTC
a893346 Johannes Sixt 08 January 2014, 16:33:44 UTC mv: let 'git mv file no-such-dir/' error out on Windows, too The previous commit c57f628 (mv: let 'git mv file no-such-dir/' error out) relies on that rename("file", "no-such-dir/") fails if the directory does not exist (note the trailing slash). This does not work as expected on Windows: This rename() call does not fail, but renames "file" to "no-such-dir" (not to "no-such-dir/file"). Insert an explicit check for this case to force an error. This changes the error message from $ git mv file no-such-dir/ fatal: renaming 'file' failed: Not a directory to $ git mv file no-such-dir/ fatal: destination directory does not exist, source=file, destination=no-such-dir/ Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 January 2014, 19:28:12 UTC
2a07e43 Øystein Walle 07 January 2014, 08:22:15 UTC stash: handle specifying stashes with $IFS When trying to pop/apply a stash specified with an argument containing IFS whitespace, git-stash will throw an error: $ git stash pop 'stash@{two hours ago}' Too many revisions specified: stash@{two hours ago} This happens because word splitting is used to count non-option arguments. Make use of rev-parse's --sq option to quote the arguments for us to ensure a correct count. Add quotes where necessary. Also add a test that verifies correct behaviour. Helped-by: Thomas Rast <tr@thomasrast.ch> Signed-off-by: Øystein Walle <oystwa@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 January 2014, 18:51:04 UTC
c90d3db Junio C Hamano 06 January 2014, 17:10:09 UTC Merge branch 'maint' of git://github.com/git-l10n/git-po into maint * 'maint' of git://github.com/git-l10n/git-po: l10n: de.po: fix translation of 'prefix' 06 January 2014, 17:10:09 UTC
43fda94 W. Trevor King 03 January 2014, 18:31:22 UTC Documentation/gitmodules: Only 'update' and 'url' are required Descriptions for all the settings fell under the initial "Each submodule section also contains the following required keys:". The example shows sections with just 'path' and 'url' entries, which are indeed required, but we should still make the required/optional distinction explicit to clarify that the rest of them are optional. Signed-off-by: W. Trevor King <wking@tremily.us> Reviewed-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 January 2014, 17:08:18 UTC
cb05536 Ralf Thielow 03 January 2014, 17:05:43 UTC l10n: de.po: fix translation of 'prefix' The word 'prefix' is currently translated as 'Prefix' which is not a German word. It should be translated as 'Präfix'. Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> 03 January 2014, 17:21:38 UTC
ed7eda8 Kyle J. McKay 31 December 2013, 12:07:39 UTC gc: notice gc processes run by other users Since 64a99eb4 git gc refuses to run without the --force option if another gc process on the same repository is already running. However, if the repository is shared and user A runs git gc on the repository and while that gc is still running user B runs git gc on the same repository the gc process run by user A will not be noticed and the gc run by user B will go ahead and run. The problem is that the kill(pid, 0) test fails with an EPERM error since user B is not allowed to signal processes owned by user A (unless user B is root). Update the test to recognize an EPERM error as meaning the process exists and another gc should not be run (unless --force is given). Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 January 2014, 00:15:29 UTC
e1c1a32 Jeff King 02 January 2014, 03:03:30 UTC Revert "prompt: clean up strbuf usage" This reverts commit 31b49d9b653803e7c7fd18b21c8bdd86e3421668. That commit taught do_askpass to hand ownership of our buffer back to the caller rather than simply return a pointer into our internal strbuf. What it failed to notice, though, was that our internal strbuf is static, because we are trying to emulate the getpass() interface. By handing off ownership, we created a memory leak that cannot be solved. Sometimes git_prompt returns a static buffer from getpass() (or our smarter git_terminal_prompt wrapper), and sometimes it returns an allocated string from do_askpass. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 January 2014, 18:21:40 UTC
b9cf14d Ramkumar Ramachandra 30 December 2013, 16:28:55 UTC for-each-ref: remove unused variable No code ever used this symbol since the command was introduced at 9f613ddd (Add git-for-each-ref: helper for language bindings, 2006-09-15). Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 30 December 2013, 20:23:51 UTC
8f29299 Junio C Hamano 30 December 2013, 19:58:54 UTC merge-base --octopus: reduce the result from get_octopus_merge_bases() Scripts that use "merge-base --octopus" could do the reducing themselves, but most of them are expected to want to get the reduced results without having to do any work themselves. Tests are taken from a message by Василий Макаров <einmalfel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> --- We might want to vet the existing callers of the underlying get_octopus_merge_bases() and find out if _all_ of them are doing anything extra (like deduping) because the machinery can return duplicate results. And if that is the case, then we may want to move the dedupling down the callchain instead of having it here. 30 December 2013, 19:58:54 UTC
e2f5df4 Junio C Hamano 30 December 2013, 19:37:49 UTC merge-base: separate "--independent" codepath into its own helper It piggybacks on an unrelated handle_octopus() function only because there are some similarities between the way they need to preprocess their input and output their result. There is nothing similar in the true logic between these two operations. Signed-off-by: Junio C Hamano <gitster@pobox.com> 30 December 2013, 19:37:49 UTC
e228c17 Johannes Schindelin 27 December 2013, 20:49:57 UTC Remove the line length limit for graft files Support for grafts predates Git's strbuf, and hence it is understandable that there was a hard-coded line length limit of 1023 characters (which was chosen a bit awkwardly, given that it is *exactly* one byte short of aligning with the 41 bytes occupied by a commit name and the following space or new-line character). While regular commit histories hardly win comprehensibility in general if they merge more than twenty-two branches in one go, it is not Git's business to limit grafts in such a way. In this particular developer's case, the use case that requires substantially longer graft lines to be supported is the visualization of the commits' order implied by their changes: commits are considered to have an implicit relationship iff exchanging them in an interactive rebase would result in merge conflicts. Thusly implied branches tend to be very shallow in general, and the resulting thicket of implied branches is usually very wide; It is actually quite common that *most* of the commits in a topic branch have not even one implied parent, so that a final merge commit has about as many implied parents as there are commits in said branch. [jc: squashed in tests by Jonathan] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 December 2013, 00:46:25 UTC
64ed07c Nguyễn Thái Ngọc Duy 23 December 2013, 09:02:41 UTC add: don't complain when adding empty project root This behavior was added in 07d7bed (add: don't complain when adding empty project root - 2009-04-28) then broken by 84b8b5d (remove match_pathspec() in favor of match_pathspec_depth() - 2013-07-14). Reinstate it. Noticed-by: Thomas Ferris Nicolaisen <tfnico@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 26 December 2013, 18:46:26 UTC
5e1361c brian m. carlson 17 December 2013, 04:28:21 UTC log: properly handle decorations with chained tags git log did not correctly handle decorations when a tag object referenced another tag object that was no longer a ref, such as when the second tag was deleted. The commit would not be decorated correctly because parse_object had not been called on the second tag and therefore its tagged field had not been filled in, resulting in none of the tags being associated with the relevant commit. Call parse_object to fill in this field if it is absent so that the chain of tags can be dereferenced and the commit can be properly decorated. Include tests as well to prevent future regressions. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 December 2013, 22:37:03 UTC
82246b7 Nguyễn Thái Ngọc Duy 20 December 2013, 10:53:52 UTC daemon: be strict at parsing parameters --[no-]informative-errors Use strcmp() instead of starts_with()/!prefixcmp() to stop accepting --informative-errors-just-a-little Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 December 2013, 22:05:07 UTC
491a8de Junio C Hamano 18 December 2013, 22:59:12 UTC get_max_fd_limit(): fall back to OPEN_MAX upon getrlimit/sysconf failure On broken systems where RLIMIT_NOFILE is visible by the compliers but underlying getrlimit() system call does not behave, we used to simply die() when we are trying to decide how many file descriptors to allocate for keeping packfiles open. Instead, allow the fallback codepath to take over when we get such a failure from getrlimit(). The same issue exists with _SC_OPEN_MAX and sysconf(); restructure the code in a similar way to prepare for a broken sysconf() as well. Noticed-by: Joey Hess <joey@kitenet.net> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 December 2013, 22:59:43 UTC
5512ac5 Junio C Hamano 17 December 2013, 19:42:12 UTC Git 1.8.5.2 Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 December 2013, 19:42:12 UTC
59f3e3f Junio C Hamano 17 December 2013, 19:38:23 UTC Merge branch 'rs/doc-submitting-patches' into maint * rs/doc-submitting-patches: SubmittingPatches: document how to handle multiple patches 17 December 2013, 19:38:23 UTC
5169f5a Junio C Hamano 17 December 2013, 19:37:55 UTC Merge branch 'tr/doc-git-cherry' into maint * tr/doc-git-cherry: Documentation: revamp git-cherry(1) 17 December 2013, 19:37:55 UTC
2126074 Junio C Hamano 17 December 2013, 19:36:54 UTC Merge branch 'nd/glossary-content-pathspec-markup' into maint * nd/glossary-content-pathspec-markup: glossary-content.txt: fix documentation of "**" patterns 17 December 2013, 19:36:54 UTC
c8394bb Junio C Hamano 17 December 2013, 19:36:38 UTC Merge branch 'jj/doc-markup-gitcli' into maint * jj/doc-markup-gitcli: Documentation/gitcli.txt: fix double quotes 17 December 2013, 19:36:38 UTC
5712dcb Junio C Hamano 17 December 2013, 19:36:10 UTC Merge branch 'jj/doc-markup-hints-in-coding-guidelines' into maint * jj/doc-markup-hints-in-coding-guidelines: State correct usage of literal examples in man pages in the coding standards 17 December 2013, 19:36:10 UTC
ace08c2 Junio C Hamano 17 December 2013, 19:35:41 UTC Merge branch 'jj/log-doc' into maint * jj/log-doc: Documentation/git-log.txt: mark-up fix and minor rephasing Documentation/git-log: update "--log-size" description 17 December 2013, 19:35:41 UTC
7be001d Junio C Hamano 17 December 2013, 19:34:41 UTC Merge branch 'jj/rev-list-options-doc' into maint * jj/rev-list-options-doc: Documentation/rev-list-options.txt: fix some grammatical issues and typos Documentation/rev-list-options.txt: fix mark-up 17 December 2013, 19:34:41 UTC
e8fcf70 Junio C Hamano 17 December 2013, 19:34:24 UTC Merge branch 'tb/doc-fetch-pack-url' into maint * tb/doc-fetch-pack-url: git-fetch-pack uses URLs like git-fetch 17 December 2013, 19:34:24 UTC
a4a227a Junio C Hamano 17 December 2013, 19:34:01 UTC Merge branch 'mi/typofixes' into maint * mi/typofixes: contrib: typofixes Documentation/technical/http-protocol.txt: typofixes typofixes: fix misspelt comments 17 December 2013, 19:34:01 UTC
a5d5653 Junio C Hamano 17 December 2013, 19:32:50 UTC Merge branch 'jh/loose-object-dirs-creation-race' into maint Two processes creating loose objects at the same time could have failed unnecessarily when the name of their new objects started with the same byte value, due to a race condition. * jh/loose-object-dirs-creation-race: sha1_file.c:create_tmpfile(): Fix race when creating loose object dirs 17 December 2013, 19:32:50 UTC
4766036 Junio C Hamano 17 December 2013, 19:32:04 UTC Merge branch 'jk/two-way-merge-corner-case-fix' into maint "git am --abort" sometimes complained about not being able to write a tree with an 0{40} object in it. * jk/two-way-merge-corner-case-fix: t1005: add test for "read-tree --reset -u A B" t1005: reindent unpack-trees: fix "read-tree -u --reset A B" with conflicted index 17 December 2013, 19:32:17 UTC
66c24cd Junio C Hamano 17 December 2013, 19:31:18 UTC Merge branch 'sb/sha1-loose-object-info-check-existence' into maint "git cat-file --batch-check=ok" did not check the existence of the named object. * sb/sha1-loose-object-info-check-existence: sha1_loose_object_info(): do not return success on missing object 17 December 2013, 19:31:18 UTC
c8b928d Junio C Hamano 17 December 2013, 19:21:34 UTC Merge branch 'nd/magic-pathspec' into maint "git diff -- ':(icase)makefile'" was unnecessarily rejected at the command line parser. * nd/magic-pathspec: diff: restrict pathspec limitations to diff b/f case only 17 December 2013, 19:21:34 UTC
3e7b066 Michael Haggerty 17 December 2013, 13:43:58 UTC cmd_repack(): remove redundant local variable "nr_packs" Its value is the same as the number of entries in the "names" string_list, so just use "names.nr" in its place. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Acked-by: Stefan Beller <stefanbeller@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 December 2013, 18:54:41 UTC
6554dfa Jeff King 11 December 2013, 23:15:50 UTC cat-file: handle --batch format with missing type/size Commit 98e2092 taught cat-file to stream blobs with --batch, which requires that we look up the object type before loading it into memory. As a result, we now print the object header from information in sha1_object_info, and the actual contents from the read_sha1_file. We double-check that the information we printed in the header matches the content we are about to show. Later, commit 93d2a60 allowed custom header lines for --batch, and commit 5b08640 made type lookups optional. As a result, specifying a header line without the type or size means that we will not look up those items at all. This causes our double-checking to erroneously die with an error; we think the type or size has changed, when in fact it was simply left at "0". For the size, we can fix this by only doing the consistency double-check when we have retrieved the size via sha1_object_info. In the case that we have not retrieved the value, that means we also did not print it, so there is nothing for us to check that we are consistent with. We could do the same for the type. However, besides our consistency check, we also care about the type in deciding whether to stream or not. So instead of handling the case where we do not know the type, this patch instead makes sure that we always trigger a type lookup when we are printing, so that even a format without the type will stream as we would in the normal case. Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 December 2013, 19:31:25 UTC
370c926 Jeff King 11 December 2013, 23:01:42 UTC cat-file: pass expand_data to print_object_or_die We currently individually pass the sha1, type, and size fields calculated by sha1_object_info. However, if we pass the whole struct, the called function can make more intelligent decisions about which fields were actually filled by sha1_object_info. This patch takes that first refactoring step, passing the whole struct, so further patches can make those decisions with less noise in their diffs. There should be no functional change to this patch (aside from a minor typo fix in the error message). As a side effect, we can rename the local variables in the function to "type" and "size", since the names are no longer taken. Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 December 2013, 19:27:21 UTC
a2036d7 Torsten Bögershausen 28 November 2013, 19:50:15 UTC git_connect(): use common return point Use only one return point from git_connect(), doing the free(); return conn; only at one place in the code. There may be a little confusion what the variable "host" is for. At some places it is only the host part, at other places it may include the port number, so change host into hostandport here. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 December 2013, 22:54:48 UTC
c59ab2e Torsten Bögershausen 28 November 2013, 19:50:03 UTC connect.c: refactor url parsing Make the function is_local() in transport.c public, rename it into url_is_local_not_ssh() and use it in both transport.c and connect.c Use a protocol "local" for URLs for the local file system. One note about using file:// under Windows: The (absolute) path on Unix like system typically starts with "/". When the host is empty, it can be omitted, so that a shell scriptlet url=file://$pwd will give a URL like "file:///home/user/repo". Windows does not have the same concept of a root directory located in "/". When parsing the URL allow "file://C:/user/repo" (even if RFC1738 indicates that "file:///C:/user/repo" should be used). Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 December 2013, 22:54:48 UTC
83b0587 Torsten Bögershausen 28 November 2013, 19:49:54 UTC git_connect(): refactor the port handling for ssh Use get_host_and_port() even for ssh. Remove the variable port git_connect(), and simplify parse_connect_url() Use only one return point in git_connect(), doing the free() and return conn. t5601 had 2 corner test cases which now pass. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 December 2013, 22:54:47 UTC
6a59974 Torsten Bögershausen 28 November 2013, 19:49:38 UTC git fetch: support host:/~repo The documentation (in urls.txt) says that "ssh://host:/~repo", "host:/~repo" or "host:~repo" specify the repository "repo" in the home directory at "host". This has not been working for "host:/~repo". Before commit 356bec "Support [address] in URLs", the comparison "url != hostname" could be used to determine if the URL had a scheme or not: "ssh://host/host" != "host". However, after 356bec "[::1]" was converted into "::1", yielding url != hostname as well. To fix this regression, don't use "if (url != hostname)", but look at the separator instead. Rename the variable "c" into "separator" to make it easier to read. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 December 2013, 22:54:47 UTC
854aeb7 Torsten Bögershausen 28 November 2013, 19:49:29 UTC t5500: add test cases for diag-url Add test cases using git fetch-pack --diag-url: - parse out host and path for URLs with a scheme (git:// file:// ssh://) - parse host names embedded by [] correctly - extract the port number, if present - separate URLs like "file" (which are local) from URLs like "host:repo" which should use ssh Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 December 2013, 22:54:47 UTC
5610b7c Torsten Bögershausen 28 November 2013, 19:49:17 UTC git fetch-pack: add --diag-url The main purpose is to trace the URL parser called by git_connect() in connect.c The main features of the parser can be listed as this: - parse out host and path for URLs with a scheme (git:// file:// ssh://) - parse host names embedded by [] correctly - extract the port number, if present - separate URLs like "file" (which are local) from URLs like "host:repo" which should use ssh Add the new parameter "--diag-url" to "git fetch-pack", which prints the value for protocol, host and path to stderr and exits. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 December 2013, 22:54:47 UTC
back to top