Skip to main content

Browse the archive

swh:1:snp:6df5a50b8107b6bbe1e51d0239d816a7503c536a
sort by:
Revision Author Date Message Commit Date
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
cabc3c1 Johannes Sixt 28 November 2013, 19:49:01 UTC git_connect: factor out discovery of the protocol and its parts git_connect has grown large due to the many different protocols syntaxes that are supported. Move the part of the function that parses the URL to connect to into a separate function for readability. Signed-off-by: Johannes Sixt <j6t@kdbg.org> 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
d98d109 Johannes Sixt 28 November 2013, 19:48:45 UTC git_connect: remove artificial limit of a remote command Since day one, function git_connect() had a limit on the command line of the command that is invoked to make a connection. 7a33bcbe converted the code that constructs the command to strbuf. This would have been the right time to remove the limit, but it did not happen. Remove it now. git_connect() uses start_command() to invoke the command; consequently, the limits of the system still apply, but are diagnosed only at execve() time. But these limits are more lenient than the 1K that git_connect() imposed. Signed-off-by: Johannes Sixt <j6t@kdbg.org> 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
62f162f Jeff King 06 December 2013, 22:07:52 UTC rev-parse: be more careful with munging arguments When rev-parse looks at whether an argument like "foo..bar" or "foobar^@" is a difference or parent-shorthand, it internally munges the arguments so that it can pass the individual rev arguments to get_sha1(). However, we do not consistently un-munge the result. For cases where we do not match (e.g., "doesnotexist..HEAD"), we would then want to try to treat the argument as a filename. try_difference gets() this right, and always unmunges in this case. However, try_parent_shorthand() never unmunges, leading to incorrect error messages, or even incorrect results: $ git rev-parse foobar^@ foobar fatal: ambiguous argument 'foobar': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' $ >foobar $ git rev-parse foobar^@ foobar For cases where we do match, neither function unmunges. This does not currently matter, since we are done with the argument. However, a future patch will do further processing, and this prepares for it. In addition, it's simply a confusing interface for some cases to modify the const argument, and others not to. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 December 2013, 22:39:16 UTC
1418567 Jeff King 06 December 2013, 22:05:48 UTC rev-parse: correctly diagnose revision errors before "--" Rev-parse understands that a "--" may separate revisions and filenames, and that anything after the "--" is taken as-is. However, it does not understand that anything before the token must be a revision (which is the usual rule implemented by the setup_revisions parser). Since rev-parse prefers revisions to files when parsing before the "--", we end up with the correct result (if such an argument is a revision, we parse it as one, and if it is not, it is an error either way). However, we misdiagnose the errors: $ git rev-parse foobar -- >/dev/null fatal: ambiguous argument 'foobar': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' $ >foobar $ git rev-parse foobar -- >/dev/null fatal: bad flag '--' used after filename In both cases, we should know that the real error is that "foobar" is meant to be a revision, but could not be resolved. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 December 2013, 19:01:23 UTC
5594bca Nguyễn Thái Ngọc Duy 05 December 2013, 03:31:11 UTC clone,fetch: catch non positive --depth option value Instead of simply ignoring the value passed to --depth option when it is zero or negative, catch and report it as an error to let people know that they were using the option incorrectly. Original-patch-by: Andrés G. Aragoneses <knocte@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 December 2013, 20:57:10 UTC
1a72cfd Jens Lehmann 05 December 2013, 19:44:14 UTC commit -v: strip diffs and submodule shortlogs from the commit message When using the '-v' option of "git commit" the diff added to the commit message temporarily for editing is stripped off after the user exited the editor by searching for "\ndiff --git " and truncating the commmit message there if it is found. But this approach has two problems: - when the commit message itself contains a line starting with "diff --git" it will be truncated there prematurely; and - when the "diff.submodule" setting is set to "log", the diff may start with "Submodule <hash1>..<hash2>", which will be left in the commit message while it shouldn't. Fix that by introducing a special scissor separator line starting with the comment character ('#' or the core.commentChar config if set) followed by two lines describing what it is for. The scissor line - which will not be translated - is used to reliably detect the start of the diff so it can be chopped off from the commit message, no matter what the user enters there. Turn a known test failure fixed by this change into a successful test; also add one for a diff starting with a submodule log and another one for proper handling of the comment char. Reported-by: Ari Pollak <ari@debian.org> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 December 2013, 22:39:11 UTC
2171f3d Torsten Bögershausen 28 November 2013, 19:48:22 UTC t5601: add tests for ssh Add more tests testing all the combinations: -IPv4 or IPv6 -path starting with "/" or with "/~" -with and without the ssh:// scheme Some tests fail; they need updates in connect.c Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 December 2013, 23:47:50 UTC
710eb3e Torsten Bögershausen 28 November 2013, 19:53:47 UTC t5601: remove clear_ssh, refactor setup_ssh_wrapper Commit 8d3d28f5 added test cases for URLs which should be ssh. Remove the function clear_ssh, use test_when_finished to clean up. Introduce the function setup_ssh_wrapper, which could be factored out together with expect_ssh. Tighten one test and use "foo:bar" instead of "./foo:bar", Helped-by: Jeff King <peff@peff.net> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 December 2013, 23:33:20 UTC
c57f628 Matthieu Moy 03 December 2013, 08:32:04 UTC mv: let 'git mv file no-such-dir/' error out Git used to trim the trailing slash, and make the command equivalent to 'git mv file no-such-dir', which created the file no-such-dir (while the trailing slash explicitly stated that it could only be a directory). This patch skips the trailing slash removal for the destination path. The path with its trailing slash is passed to rename(2), which errors out with the appropriate message: $ git mv file no-such-dir/ fatal: renaming 'file' failed: Not a directory Original-patch-by: Duy Nguyen <pclouds@gmail.com> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 December 2013, 19:49:15 UTC
5508f3e Thomas Rast 01 December 2013, 22:48:43 UTC send-email: set SSL options through IO::Socket::SSL::set_client_defaults When --smtp-encryption=ssl, we use a Net::SMTP::SSL connection, passing its ->new all the options that would otherwise go to Net::SMTP->new (most options) and IO::Socket::SSL->start_SSL (for the SSL options). However, while Net::SMTP::SSL replaces the underlying socket class with an SSL socket, it does nothing to allow passing options to that socket. So the SSL-relevant options are lost. Fortunately there is an escape hatch: we can directly set the options with IO::Socket::SSL::set_client_defaults. They will then persist within the IO::Socket::SSL module. Signed-off-by: Thomas Rast <tr@thomasrast.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 December 2013, 19:45:32 UTC
979e652 Thomas Rast 01 December 2013, 22:48:42 UTC send-email: --smtp-ssl-cert-path takes an argument 35035bb (send-email: be explicit with SSL certificate verification, 2013-07-18) forgot to specify that --smtp-ssl-cert-path takes a string argument. This means that the option could not actually be used as intended. Presumably noone noticed because it's much easier to set it through configs anyway. Add the required "=s". Signed-off-by: Thomas Rast <tr@thomasrast.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 December 2013, 19:45:30 UTC
d4d9653 Thomas Rast 01 December 2013, 22:48:41 UTC send-email: pass Debug to Net::SMTP::SSL::new We forgot to pass the Debug option through to Net::SMTP::SSL->new -- which is the same as Net::SMTP->new. This meant that with security set to SSL, we would never enable debug output. Pass through the flag. Signed-off-by: Thomas Rast <tr@thomasrast.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 December 2013, 19:45:27 UTC
a155a5f Junio C Hamano 03 December 2013, 19:16:56 UTC Git 1.8.5.1 Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 December 2013, 19:16:56 UTC
2951add Nick Townsend 25 November 2013, 23:31:09 UTC ref-iteration doc: add_submodule_odb() returns 0 for success The usage sample of add_submodule_odb() function in the Submodules section expects non-zero return value for success, but the function actually reports success with zero. Helped-by: René Scharfe <l.s.r@web.de> Reviewed-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Nick Townsend <nick.townsend@mac.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 December 2013, 18:40:40 UTC
be38bee Junio C Hamano 02 December 2013, 23:34:44 UTC Sync with 1.8.4.5 02 December 2013, 23:34:44 UTC
2f93541 Junio C Hamano 02 December 2013, 23:33:30 UTC Git 1.8.4.5 Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 December 2013, 23:33:30 UTC
ac1fbbd Junio C Hamano 02 December 2013, 21:31:55 UTC submodule: do not copy unknown update mode from .gitmodules When submodule.$name.update is given as hint from the upstream in the .gitmodules file, we used to blindly copy it to .git/config, unless there already is a value defined for the submodule. However, there is no reason to expect that the update mode hinted by the upstream is available in the version of Git the user is using, and a really custom "!cmd" prepared by an upstream person running on Linux may not even be available to a user on Windows. It is simply irresponsible to copy the setting blindly and to attempt to use it during a later "submodule update" without validating it first. Just show the suggested value to the diagnostic output, and set the value to 'none' in the configuration, if it is not one of the ones that are known to be supported by this version of Git. Helped-by: Jens Lehmann <Jens.Lehmann@web.de> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 December 2013, 21:48:06 UTC
7c801fb Thomas Rast 22 November 2013, 16:29:16 UTC Documentation: revamp git-cherry(1) git-cherry(1)'s "description" section has never really managed to explain to me what the command does. It contains too much explanation of the algorithm instead of simply saying what goals it achieves, and too much terminology that we otherwise do not use (fork-point instead of merge-base). Try a much more concise approach: state what it finds out, why this is neat, and how the output is formatted, in a few short paragraphs. In return, provide much longer examples of how it fits into a "format-patch | am" based workflow, and how it compares to reading the same from git-log. Also carefully avoid using "merge" in a context where it does not mean something that comes from git-merge(1). Instead, say "apply" in an attempt to further link to patch workflow concepts. While there, also omit the language about _which_ upstream branch we treat as the default. I literally just learned that we support having several, so let's not confuse new users here, especially considering that git-config(1) does not document this. Prompted-by: a.huemer@commend.com on #git Signed-off-by: Thomas Rast <tr@thomasrast.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 November 2013, 20:16:49 UTC
back to top