git - Mirror of https://git.kernel.org/pub/scm/git/git.git/

about summary refs log tree commit diff stats

diff options

Diffstat (limited to 'builtin/commit-tree.c')

0 files changed, 0 insertions, 0 deletions

in the past, and some people and scripts rely on this behavior. Also, a line starting with space followed by a '#' cannot have any meaning other than being a comment, hence it doesn't harm to accept them as comments. Largely based on patch by: Junio C Hamano <gitster@pobox.com> [jc: updated test with quickfix from Torsten Bögershausen] Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-10-05gc: demonstrate failure with stale remote HEADJohannes Schindelin1-0/+13 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-10-05sha1_file: consolidate code to close a pack's file descriptorJohannes Schindelin1-20/+18 There was a lot of repeated code to close the file descriptor of a given pack. Let's just refactor this code into a single function. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-10-05t5700: demonstrate a Windows file locking issue with `git clone --dissociate`Johannes Schindelin1-0/+21 On Windows, dissociating from a reference can fail very easily due to pack files that are still in use when they want to be removed. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-10-02merge: grammofix in please-commit-before-merge messageAlex Henrie2-2/+2 Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-10-02rebase-i: explicitly accept tab as separator in commandsMatthieu Moy1-2/+2 The git-rebase-todo is parsed several times with different parsers. In principle, the user input is normalized by transform_todo_ids and further parsing can be stricter. In case the user wrote pick deadbeef<TAB>commit message the parser of transform_todo_ids was considering the sha1 to be "deadbeef<TAB>commit", and was leaving the tab in the transformed sheet. In practice, this went unnoticed since the actual command interpretation was done later in do_next which did accept the tab as a separator. Make it explicit in the code of transform_todo_ids that tabs are accepted. This way, code that mimicks it will also accept tabs as separator. A similar construct appears in skip_unnecessary_picks, but this one comes after transform_todo_ids, hence reads the normalized format, so it needs not be changed. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-10-02status: don't say 'HEAD detached at HEAD'Matthieu Moy2-1/+7 After using "git checkout --detach", the reflog is left with an entry like checkout: moving from ... to HEAD This message is parsed to generate the 'HEAD detached at' message in 'git branch' and 'git status', which leads to the not-so-useful message 'HEAD detached at HEAD'. Instead, when parsing such reflog entry, resolve HEAD to the corresponding commit in the reflog, so that the message becomes 'HEAD detached at $sha1'. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-10-02t3203: test 'detached at' after checkout --detachMatthieu Moy1-0/+13 This currently fails: the output is 'HEAD detached at HEAD'. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-30am: configure gpg at startupRenee Margaret McConahy1-1/+12 The new builtin am ignores the user.signingkey variable: gpg is being called with the committer details as the key ID, which may not be correct. git_gpg_config is responsible for handling that variable and is expected to be called on initialization by any modules that use gpg. Signed-off-by: Renee Margaret McConahy <nepella@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-30git-send-email.perl: Fixed sending of many/huge changes/patchesStefan Agner1-1/+5 Sometimes sending huge patches/commits fail with [Net::SMTP::SSL] Connection closed at /usr/lib/git-core/git-send-email line 1320. Running the command with --smtp-debug=1 yields to Net::SMTP::SSL: Net::Cmd::datasend(): unexpected EOF on command channel: at /usr/lib/git-core/git-send-email line 1320. [Net::SMTP::SSL] Connection closed at /usr/lib/git-core/git-send-email line 1320. Stefan described it in his mail like this: It seems to me that there is a size limit, after cutting down the patch to ~16K, sending started to work. I cut it twice, once by removing lines from the head and once from the bottom, in both cases at the size of around 16K I could send the patch. See also original report: http://permalink.gmane.org/gmane.comp.version-control.git/274569 Reported-by: Juston Li <juston.h.li@gmail.com> Tested-by: Markos Chandras <hwoarang@gentoo.org> Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-30l10n: ru.po: update Russian translationDimitriy Ryazantcev1-1583/+1967 Signed-off-by: Dimitriy Ryazantcev <dimitriy.ryazantcev@gmail.com> 2015-09-28Git 2.6.1v2.6.1Junio C Hamano4-3/+22 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-28Git 2.5.4v2.5.4Junio C Hamano4-3/+22 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-28Git 2.4.10v2.4.10Junio C Hamano4-3/+22 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-28Git 2.3.10v2.3.10Junio C Hamano4-3/+22 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-28merge-file: enforce MAX_XDIFF_SIZE on incoming filesJeff King1-1/+2 The previous commit enforces MAX_XDIFF_SIZE at the interfaces to xdiff: xdi_diff (which calls xdl_diff) and ll_xdl_merge (which calls xdl_merge). But we have another direct call to xdl_merge in merge-file.c. If it were written today, this probably would just use the ll_merge machinery. But it predates that code, and uses slightly different options to xdl_merge (e.g., ZEALOUS_ALNUM). We could try to abstract out an xdi_merge to match the existing xdi_diff, but even that is difficult. Rather than simply report error, we try to treat large files as binary, and that distinction would happen outside of xdi_merge. The simplest fix is to just replicate the MAX_XDIFF_SIZE check in merge-file.c. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-28xdiff: reject files larger than ~1GBJeff King3-1/+14 The xdiff code is not prepared to handle extremely large files. It uses "int" in many places, which can overflow if we have a very large number of lines or even bytes in our input files. This can cause us to produce incorrect diffs, with no indication that the output is wrong. Or worse, we may even underallocate a buffer whose size is the result of an overflowing addition. We're much better off to tell the user that we cannot diff or merge such a large file. This patch covers both cases, but in slightly different ways: 1. For merging, we notice the large file and cleanly fall back to a binary merge (which is effectively "we cannot merge this"). 2. For diffing, we make the binary/text distinction much earlier, and in many different places. For this case, we'll use the xdi_diff as our choke point, and reject any diff there before it hits the xdiff code. This means in most cases we'll die() immediately after. That's not ideal, but in practice we shouldn't generally hit this code path unless the user is trying to do something tricky. We already consider files larger than core.bigfilethreshold to be binary, so this code would only kick in when that is circumvented (either by bumping that value, or by using a .gitattribute to mark a file as diffable). In other words, we can avoid being "nice" here, because there is already nice code that tries to do the right thing. We are adding the suspenders to the nice code's belt, so notice when it has been worked around (both to protect the user from malicious inputs, and because it is better to die() than generate bogus output). The maximum size was chosen after experimenting with feeding large files to the xdiff code. It's just under a gigabyte, which leaves room for two obvious cases: - a diff3 merge conflict result on files of maximum size X could be 3*X plus the size of the markers, which would still be only about 3G, which fits in a 32-bit int. - some of the diff code allocates arrays of one int per record. Even if each file consists only of blank lines, then a file smaller than 1G will have fewer than 1G records, and therefore the int array will fit in 4G. Since the limit is arbitrary anyway, I chose to go under a gigabyte, to leave a safety margin (e.g., we would not want to overflow by allocating "(records + 1) * sizeof(int)" or similar. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-28react to errors in xdi_diffJeff King7-24/+41 When we call into xdiff to perform a diff, we generally lose the return code completely. Typically by ignoring the return of our xdi_diff wrapper, but sometimes we even propagate that return value up and then ignore it later. This can lead to us silently producing incorrect diffs (e.g., "git log" might produce no output at all, not even a diff header, for a content-level diff). In practice this does not happen very often, because the typical reason for xdiff to report failure is that it malloc() failed (it uses straight malloc, and not our xmalloc wrapper). But it could also happen when xdiff triggers one our callbacks, which returns an error (e.g., outf() in builtin/rerere.c tries to report a write failure in this way). And the next patch also plans to add more failure modes. Let's notice an error return from xdiff and react appropriately. In most of the diff.c code, we can simply die(), which matches the surrounding code (e.g., that is what we do if we fail to load a file for diffing in the first place). This is not that elegant, but we are probably better off dying to let the user know there was a problem, rather than simply generating bogus output. We could also just die() directly in xdi_diff, but the callers typically have a bit more context, and can provide a better message (and if we do later decide to pass errors up, we're one step closer to doing so). There is one interesting case, which is in diff_grep(). Here if we cannot generate the diff, there is nothing to match, and we silently return "no hits". This is actually what the existing code does already, but we make it a little more explicit. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-28Git 2.6v2.6.0Junio C Hamano2-1/+6 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-28ls-remote.txt: delete unsupported optionNguyễn Thái Ngọc Duy2-3/+2 -u <exec> has never been supported, but it was mentioned since 0a2bb55 (git ls-remote: make usage string match manpage - 2008-11-11). Nobody has complained about it for seven years, it's probably safe to say nobody cares. So let's remove "-u" in documents instead of adding code to support it. While at there, fix --upload-pack syntax too. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-28setup: fix "inside work tree" detection on case-insensitive filesystemsJohannes Schindelin1-1/+10 Git has a config variable to indicate that it is operating on a file system that is case-insensitive: core.ignoreCase. But the `dir_inside_of()` function did not respect that. As a result, if Git's idea of the current working directory disagreed in its upper/lower case with the `GIT_WORK_TREE` variable (e.g. `C:\test` vs `c:\test`) the user would be greeted by the error message fatal: git-am cannot be used without a working tree. when trying to run a rebase. This fixes https://github.com/git-for-windows/git/issues/402 (reported by Daniel Harding). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-28clone: better error when --reference is a linked checkoutNguyễn Thái Ngọc Duy1-1/+6 Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-28clone: allow --local from a linked checkoutNguyễn Thái Ngọc Duy2-2/+9 Noticed-by: Bjørnar Snoksrud <snoksrud@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-28enter_repo: allow .git files in strict modeNguyễn Thái Ngọc Duy2-2/+17 Strict mode is about not guessing where .git is. If the user points to a .git file, we know exactly where the target .git dir will be. This makes it possible to serve .git files as repository on the server side. This may be needed even in local clone case because transport.c code uses upload-pack for fetching remote refs. But right now the clone/transport code goes with non-strict. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-28enter_repo: avoid duplicating logic, use is_git_directory() insteadNguyễn Thái Ngọc Duy2-2/+15 It matters for linked checkouts where 'refs' directory won't be available in $GIT_DIR. is_git_directory() knows about $GIT_COMMON_DIR and can handle this case. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-28t0002: add test for enter_repo(), non-strict modeNguyễn Thái Ngọc Duy1-0/+18 Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-25http: limit redirection depthBlake Burkhart3-0/+8 By default, libcurl will follow circular http redirects forever. Let's put a cap on this so that somebody who can trigger an automated fetch of an arbitrary repository (e.g., for CI) cannot convince git to loop infinitely. The value chosen is 20, which is the same default that Firefox uses. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-25http: limit redirection to protocol-whitelistBlake Burkhart4-5/+27 Previously, libcurl would follow redirection to any protocol it was compiled for support with. This is desirable to allow redirection from HTTP to HTTPS. However, it would even successfully allow redirection from HTTP to SFTP, a protocol that git does not otherwise support at all. Furthermore git's new protocol-whitelisting could be bypassed by following a redirect within the remote helper, as it was only enforced at transport selection time. This patch limits redirects within libcurl to HTTP, HTTPS, FTP and FTPS. If there is a protocol-whitelist present, this list is limited to those also allowed by the whitelist. As redirection happens from within libcurl, it is impossible for an HTTP redirect to a protocol implemented within another remote helper. When the curl version git was compiled with is too old to support restrictions on protocol redirection, we warn the user if GIT_ALLOW_PROTOCOL restrictions were requested. This is a little inaccurate, as even without that variable in the environment, we would still restrict SFTP, etc, and we do not warn in that case. But anything else means we would literally warn every time git accesses an http remote. This commit includes a test, but it is not as robust as we would hope. It redirects an http request to ftp, and checks that curl complained about the protocol, which means that we are relying on curl's specific error message to know what happened. Ideally we would redirect to a working ftp server and confirm that we can clone without protocol restrictions, and not with them. But we do not have a portable way of providing an ftp server, nor any other protocol that curl supports (https is the closest, but we would have to deal with certificates). [jk: added test and version warning] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-25transport: refactor protocol whitelist codeJeff King2-10/+43 The current callers only want to die when their transport is prohibited. But future callers want to query the mechanism without dying. Let's break out a few query functions, and also save the results in a static list so we don't have to re-parse for each query. Based-on-a-patch-by: Blake Burkhart <bburky@bburky.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-25Documentation: fix section header mark-upJohn Keeping2-2/+2 Asciidoctor is stricter than AsciiDoc when deciding if underlining is a section title or the start of preformatted text. Make the length of the underlining match the text to ensure that it renders correctly in all implementations. Signed-off-by: John Keeping <john@keeping.me.uk> [jc: squashed in git-bisect one noticed by Michael J Gruber] Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-25t/perf: make runner work even if Git is not installedStephan Beyer1-0/+1 aggregate.perl did not work when Git.pm is not installed to a directory contained in the default Perl library path list or PERLLIB. This commit prepends the Perl library path of the current Git source tree to enable this. Note that this commit adds a hard-coded relative path use lib '../../perl/blib/lib'; instead of the flexible environment-based variant use lib (split(/:/, $ENV{GITPERLLIB})); which is used in tests written in Perl. The hard-coded variant is used because the whole performance test framework does it that way (and GITPERLLIB is not set there). Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-25connect: fix typo in result string of prot_name()Tobias Klauser1-1/+1 Replace 'unkown' with 'unknown'. Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-25t5561: get rid of racy appending to logfileStephan Beyer3-23/+1 The definition of log_div() appended information to the web server's logfile to make the test more readable. However, log_div() was called right after a request is served (which is done by git-http-backend); the web server waits for the git-http-backend process to exit before it writes to the log file. When the duration between serving a request and exiting was long, the log_div() output was written before the last request's log, and the test failed. (This duration could become especially long for PROFILE=GEN builds.) To get rid of this behavior, we should not change the logfile at all. This commit removes log_div() and its calls. The additional information is kept in the test (for readability reasons) but filtered out before comparing it to the actual logfile. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-23fsck: exit with non-zero when problems are foundJunio C Hamano2-5/+35 After finding some problems (e.g. a ref refs/heads/X points at an object that is not a commit) and issuing an error message, the program failed to signal the fact that it found an error by a non-zero exit status. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-23submodule: allow only certain protocols for submodule fetchesJeff King2-0/+52 Some protocols (like git-remote-ext) can execute arbitrary code found in the URL. The URLs that submodules use may come from arbitrary sources (e.g., .gitmodules files in a remote repository). Let's restrict submodules to fetching from a known-good subset of protocols. Note that we apply this restriction to all submodule commands, whether the URL comes from .gitmodules or not. This is more restrictive than we need to be; for example, in the tests we run: git submodule add ext::... which should be trusted, as the URL comes directly from the command line provided by the user. But doing it this way is simpler, and makes it much less likely that we would miss a case. And since such protocols should be an exception (especially because nobody who clones from them will be able to update the submodules!), it's not likely to inconvenience anyone in practice. Reported-by: Blake Burkhart <bburky@bburky.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-23transport: add a protocol-whitelist environment variableJeff King11-1/+254 If we are cloning an untrusted remote repository into a sandbox, we may also want to fetch remote submodules in order to get the complete view as intended by the other side. However, that opens us up to attacks where a malicious user gets us to clone something they would not otherwise have access to (this is not necessarily a problem by itself, but we may then act on the cloned contents in a way that exposes them to the attacker). Ideally such a setup would sandbox git entirely away from high-value items, but this is not always practical or easy to set up (e.g., OS network controls may block multiple protocols, and we would want to enable some but not others). We can help this case by providing a way to restrict particular protocols. We use a whitelist in the environment. This is more annoying to set up than a blacklist, but defaults to safety if the set of protocols git supports grows). If no whitelist is specified, we continue to default to allowing all protocols (this is an "unsafe" default, but since the minority of users will want this sandboxing effect, it is the only sensible one). A note on the tests: ideally these would all be in a single test file, but the git-daemon and httpd test infrastructure is an all-or-nothing proposition rather than a test-by-test prerequisite. By putting them all together, we would be unable to test the file-local code on machines without apache. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-22notes: correct documentation of DWIMery for notes referencesJacob Keller3-3/+12 expand_notes_ref is used by --ref from git-notes(1) and --notes from the git log to find the full refname of a notes reference. Previously the documentation of these options was not clear about what sorts of expansions would be performed. Fix the documentation to clearly and accurately describe the behavior of the expansions. Add a test for this expansion when using git notes get-ref in order to prevent future patches from changing this behavior. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-09-22git-p4: handle "Translation of file content failed"Lars Schneider2-12/+17 A P4 repository can get into a state where it contains a file with type UTF-16 that does not contain a valid UTF-16 BOM. If git-p4 attempts to retrieve the file then the process crashes with a "Translation of file content failed" error. More info here: http://answers.perforce.com/articles/KB/3117 Fix this by detecting this error and retrieving the file as binary instead. The result in Git is the same. Known issue: This works only if git-p4 is executed in verbose mode. In normal mode no exceptions are thrown and git-p4 just exits. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>


context:
space:
mode: