summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-09-25docs: improve discoverability of exclude pathspecLibravatar Manav Rathi5-2/+24
The ability to exclude paths with a negative pathspec is not mentioned in the man pages for git grep and other commands where it might be useful. Add an example and a pointer to the pathspec glossary entry in the man page for git grep to help the user to discover this ability. Add similar pointers from the git-add and git-status man pages. Additionally, - Add a test for the behaviour when multiple exclusions are present. - Add a test for the ^ alias. - Improve name of existing test. - Improve grammar in glossary description of the exclude pathspec. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Manav Rathi <mnvrth@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-01Git 2.13.5Libravatar Junio C Hamano3-2/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-01Merge tag 'v2.12.4' into maintLibravatar Junio C Hamano13-2/+126
2017-08-01Git 2.13.4Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-31Preparation for 2.13.4 continuesLibravatar Junio C Hamano1-0/+18
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-31Merge branch 'ks/doc-fixes' into maintLibravatar Junio C Hamano2-10/+11
Doc clean-up. * ks/doc-fixes: doc: reformat the paragraph containing the 'cut-line' doc: camelCase the i18n config variables to improve readability
2017-07-31Merge branch 'jk/test-copy-bytes-fix' into maintLibravatar Junio C Hamano1-0/+1
A test fix. * jk/test-copy-bytes-fix: t: handle EOF in test_copy_bytes()
2017-07-31Merge branch 'pw/unquote-path-in-git-pm' into maintLibravatar Junio C Hamano3-43/+61
Code refactoring. * pw/unquote-path-in-git-pm: t9700: add tests for Git::unquote_path() Git::unquote_path(): throw an exception on bad path Git::unquote_path(): handle '\a' add -i: move unquote_path() to Git.pm
2017-07-31Merge branch 'jk/gc-pre-detach-under-hook' into maintLibravatar Junio C Hamano2-0/+25
We run an early part of "git gc" that deals with refs before daemonising (and not under lock) even when running a background auto-gc, which caused multiple gc processes attempting to run the early part at the same time. This is now prevented by running the early part also under the GC lock. * jk/gc-pre-detach-under-hook: gc: run pre-detach operations under lock
2017-07-31Merge branch 'jn/hooks-pre-rebase-sample-fix' into maintLibravatar Junio C Hamano1-3/+3
Code clean-up, that makes us in sync with Debian by one patch. * jn/hooks-pre-rebase-sample-fix: pre-rebase hook: capture documentation in a <<here document
2017-07-31Merge branch 'rs/progress-overall-throughput-at-the-end' into maintLibravatar Junio C Hamano1-2/+6
The progress meter did not give a useful output when we haven't had 0.5 seconds to measure the throughput during the interval. Instead show the overall throughput rate at the end, which is a much more useful number. * rs/progress-overall-throughput-at-the-end: progress: show overall rate in last update
2017-07-31Merge branch 'tb/push-to-cygwin-unc-path' into maintLibravatar Junio C Hamano5-0/+27
On Cygwin, similar to Windows, "git push //server/share/repository" ought to mean a repository on a network share that can be accessed locally, but this did not work correctly due to stripping the double slashes at the beginning. This may need to be heavily tested before it gets unleashed to the wild, as the change is at a fairly low-level code and would affect not just the code to decide if the push destination is local. There may be unexpected fallouts in the path normalization. * tb/push-to-cygwin-unc-path: cygwin: allow pushing to UNC paths
2017-07-31Merge branch 'rs/apply-avoid-over-reading' into maintLibravatar Junio C Hamano1-4/+2
Code cleanup. * rs/apply-avoid-over-reading: apply: use strcmp(3) for comparing strings in gitdiff_verify_name() apply: use starts_with() in gitdiff_verify_name()
2017-07-30Git 2.12.4Libravatar Junio C Hamano3-2/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-30Merge tag 'v2.11.3' into maint-2.12Libravatar Junio C Hamano11-0/+116
Git 2.11.3
2017-07-30Merge branch 'jk/lib-proto-disable-cleanup' into maint-2.12Libravatar Junio C Hamano1-2/+6
2017-07-30Git 2.11.3Libravatar Junio C Hamano3-2/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-30Merge tag 'v2.10.4' into maint-2.11Libravatar Junio C Hamano10-0/+112
Git 2.10.4
2017-07-30Git 2.10.4Libravatar Junio C Hamano3-2/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-30Merge tag 'v2.9.5' into maint-2.10Libravatar Junio C Hamano9-0/+108
Git 2.9.5
2017-07-30Git 2.9.5Libravatar Junio C Hamano3-2/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-30Merge tag 'v2.8.6' into maint-2.9Libravatar Junio C Hamano8-0/+104
Git 2.8.6
2017-07-30Git 2.8.6Libravatar Junio C Hamano3-2/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-30Merge tag 'v2.7.6' into maint-2.8Libravatar Junio C Hamano7-0/+100
Git 2.7.6
2017-07-30Git 2.7.6Libravatar Junio C Hamano3-2/+27
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-28Merge branch 'jk/ssh-funny-url' into maint-2.7Libravatar Junio C Hamano6-0/+75
2017-07-28connect: reject paths that look like command line optionsLibravatar Jeff King3-0/+40
If we get a repo path like "-repo.git", we may try to invoke "git-upload-pack -repo.git". This is going to fail, since upload-pack will interpret it as a set of bogus options. But let's reject this before we even run the sub-program, since we would not want to allow any mischief with repo names that actually are real command-line options. You can still ask for such a path via git-daemon, but there's no security problem there, because git-daemon enters the repo itself and then passes "." on the command line. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-28connect: reject dashed arguments for proxy commandsLibravatar Jeff King2-0/+10
If you have a GIT_PROXY_COMMAND configured, we will run it with the host/port on the command-line. If a URL contains a mischievous host like "--foo", we don't know how the proxy command may handle it. It's likely to break, but it may also do something dangerous and unwanted (technically it could even do something useful, but that seems unlikely). We should err on the side of caution and reject this before we even run the command. The hostname check matches the one we do in a similar circumstance for ssh. The port check is not present for ssh, but there it's not necessary because the syntax is "-p <port>", and there's no ambiguity on the parsing side. It's not clear whether you can actually get a negative port to the proxy here or not. Doing: git fetch git://remote:-1234/repo.git keeps the "-1234" as part of the hostname, with the default port of 9418. But it's a good idea to keep this check close to the point of running the command to make it clear that there's no way to circumvent it (and at worst it serves as a belt-and-suspenders check). Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-28connect: factor out "looks like command line option" checkLibravatar Jeff King3-1/+14
We reject hostnames that start with a dash because they may be confused for command-line options. Let's factor out that notion into a helper function, as we'll use it in more places. And while it's simple now, it's not clear if some systems might need more complex logic to handle all cases. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-28t5813: add test for hostname starting with dashLibravatar Jeff King1-0/+9
Per the explanation in the previous patch, this should be (and is) rejected. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-28connect: reject ssh hostname that begins with a dashLibravatar Junio C Hamano1-0/+3
When commands like "git fetch" talk with ssh://$rest_of_URL/, the code splits $rest_of_URL into components like host, port, etc., and then spawns the underlying "ssh" program by formulating argv[] array that has: - the path to ssh command taken from GIT_SSH_COMMAND, etc. - dashed options like '-batch' (for Tortoise), '-p <port>' as needed. - ssh_host, which is supposed to be the hostname parsed out of $rest_of_URL. - then the command to be run on the other side, e.g. git upload-pack. If the ssh_host ends up getting '-<anything>', the argv[] that is used to spawn the command becomes something like: { "ssh", "-p", "22", "-<anything>", "command", "to", "run", NULL } which obviously is bogus, but depending on the actual value of "<anything>", will make "ssh" parse and use it as an option. Prevent this by forbidding ssh_host that begins with a "-". Noticed-by: Joern Schneeweisz of Recurity Labs Reported-by: Brian at GitLab Signed-off-by: Junio C Hamano <gitster@pobox.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-28t/lib-proto-disable: restore protocol.allow after config testsLibravatar Jeff King1-2/+6
The tests for protocol.allow actually set that variable in the on-disk config, run a series of tests, and then never clean up after themselves. This means that whatever tests we run after have protocol.allow=never, which may influence their results. In most cases we either exit after running these tests, or do another round of test_proto(). In the latter case, this happens to work because: 1. Tests of the GIT_ALLOW_PROTOCOL environment variable override the config. 2. Tests of the specific config "protocol.foo.allow" override the protocol.allow config. 3. The next round of protocol.allow tests start off by setting the config to a known value. However, it's a land-mine waiting to trap somebody adding new tests to one of the t581x test scripts. Let's make sure we clean up after ourselves. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-21fixes from 'master' for 2.13.4Libravatar Junio C Hamano2-1/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-21Merge branch 'ew/fd-cloexec-fix' into maintLibravatar Junio C Hamano1-3/+3
Portability/fallback fix. * ew/fd-cloexec-fix: set FD_CLOEXEC properly when O_CLOEXEC is not supported
2017-07-21Merge branch 'ks/fix-rebase-doc-picture' into maintLibravatar Junio C Hamano1-1/+1
Doc update. * ks/fix-rebase-doc-picture: doc: correct a mistake in an illustration
2017-07-21Merge branch 'js/alias-case-sensitivity' into maintLibravatar Junio C Hamano2-1/+8
A recent update broke an alias that contained an uppercase letter. * js/alias-case-sensitivity: alias: compare alias name *case-insensitively* t1300: demonstrate that CamelCased aliases regressed
2017-07-21Merge branch 'bb/unicode-10.0' into maintLibravatar Junio C Hamano1-13/+29
Update the character width tables. * bb/unicode-10.0: unicode: update the width tables to Unicode 10
2017-07-18doc: reformat the paragraph containing the 'cut-line'Libravatar Kaartic Sivaraam1-5/+6
The paragraph that describes the 'scissors' cleanup mode of 'commit' had the 'cut-line' in the middle of a sentence. This made it possible for the line to get wrapped on smaler windows. This shouldn't be the case as it makes it hard for the user to understand the structure of the cut-line. Reformat the pragraph to make the 'cut-line' stand on a line of it's own thus distinguishing it from the rest of the paragraph. This further prevents it from getting wrapped to some extent. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-17doc: camelCase the i18n config variables to improve readabilityLibravatar Kaartic Sivaraam1-5/+5
The i18n config variable used weren't readable as they were in the crude form of how git stores/uses it's config variables. Improve it's readability by replacing them with camelCased versions of config variables as it doesn't have any impact on it's usage. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-17t: handle EOF in test_copy_bytes()Libravatar Jeff King1-0/+1
The test_copy_bytes() function claims to read up to N bytes, or until it gets EOF. But we never handle EOF in our loop, and a short input will cause perl to go into an infinite loop of read() getting zero bytes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-17set FD_CLOEXEC properly when O_CLOEXEC is not supportedLibravatar Eric Wong1-3/+3
FD_CLOEXEC only applies to the file descriptor, so it needs to be manipuluated via F_GETFD/F_SETFD. F_GETFL/F_SETFL are for file description flags. Verified via strace with o_cloexec set to zero. Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-17alias: compare alias name *case-insensitively*Libravatar Johannes Schindelin2-2/+2
It is totally legitimate to add CamelCased aliases, but due to the way config keys are compared, the case does not matter. Therefore, we must compare the alias name insensitively to the config keys. This fixes a regression introduced by a9bcf6586d1 (alias: use the early config machinery to expand aliases, 2017-06-14). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-17t1300: demonstrate that CamelCased aliases regressedLibravatar Johannes Schindelin1-0/+7
It is totally legitimate to add CamelCased aliases, but due to the way config keys are compared, the case does not matter. Except that now it does: the alias name is expected to be all lower-case. This is a regression introduced by a9bcf6586d1 (alias: use the early config machinery to expand aliases, 2017-06-14). Noticed by Alejandro Pauly, diagnosed by Kevin Willford. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-12Git 2.13.3Libravatar Junio C Hamano2-1/+10
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-12Merge branch 'kn/ref-filter-branch-list' into maintLibravatar Junio C Hamano3-7/+54
The rewrite of "git branch --list" using for-each-ref's internals that happened in v2.13 regressed its handling of color.branch.local; this has been fixed. * kn/ref-filter-branch-list: ref-filter.c: drop return from void function branch: set remote color in ref-filter branch immediately branch: use BRANCH_COLOR_LOCAL in ref-filter format branch: only perform HEAD check for local branches
2017-07-12Merge branch 'ks/typofix-commit-c-comment' into maintLibravatar Junio C Hamano1-1/+1
Typofix. * ks/typofix-commit-c-comment: builtin/commit.c: fix a typo in the comment
2017-07-12Merge branch 'jk/reflog-walk-maint' into maintLibravatar Junio C Hamano3-12/+42
After "git branch --move" of the currently checked out branch, the code to walk the reflog of HEAD via "log -g" and friends incorrectly stopped at the reflog entry that records the renaming of the branch. * jk/reflog-walk-maint: reflog-walk: include all fields when freeing complete_reflogs reflog-walk: don't free reflogs added to cache reflog-walk: duplicate strings in complete_reflogs list reflog-walk: skip over double-null oid due to HEAD rename
2017-07-12gc: run pre-detach operations under lockLibravatar Jeff King2-0/+25
We normally try to avoid having two auto-gc operations run at the same time, because it wastes resources. This was done long ago in 64a99eb47 (gc: reject if another gc is running, unless --force is given, 2013-08-08). When we do a detached auto-gc, we run the ref-related commands _before_ detaching, to avoid confusing lock contention. This was done by 62aad1849 (gc --auto: do not lock refs in the background, 2014-05-25). These two features do not interact well. The pre-detach operations are run before we check the gc.pid lock, meaning that on a busy repository we may run many of them concurrently. Ideally we'd take the lock before spawning any operations, and hold it for the duration of the program. This is tricky, though, with the way the pid-file interacts with the daemonize() process. Other processes will check that the pid recorded in the pid-file still exists. But detaching causes us to fork and continue running under a new pid. So if we take the lock before detaching, the pid-file will have a bogus pid in it. We'd have to go back and update it with the new pid after detaching. We'd also have to play some tricks with the tempfile subsystem to tweak the "owner" field, so that the parent process does not clean it up on exit, but the child process does. Instead, we can do something a bit simpler: take the lock only for the duration of the pre-detach work, then detach, then take it again for the post-detach work. Technically, this means that the post-detach lock could lose to another process doing pre-detach work. But in the long run this works out. That second process would then follow-up by doing post-detach work. Unless it was in turn blocked by a third process doing pre-detach work, and so on. This could in theory go on indefinitely, as the pre-detach work does not repack, and so need_to_gc() will continue to trigger. But in each round we are racing between the pre- and post-detach locks. Eventually, one of the post-detach locks will win the race and complete the full gc. So in the worst case, we may racily repeat the pre-detach work, but we would never do so simultaneously (it would happen via a sequence of serialized race-wins). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-11pre-rebase hook: capture documentation in a <<here documentLibravatar Jonathan Nieder1-3/+3
Without this change, the sample hook does not pass a syntax check (sh -n): $ sh -n hooks--pre-rebase.sample hooks--pre-rebase.sample: line 101: syntax error near unexpected token `(' hooks--pre-rebase.sample: line 101: ` merged into it again (either directly or indirectly).' Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-10Prepare for 2.13.3Libravatar Junio C Hamano2-1/+54