summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2013-10-28refs: remove unused function invalidate_ref_cacheLibravatar Stefan Beller2-15/+0
The function 'invalidate_ref_cache' was introduced in 79c7ca5 (2011-10-17, invalidate_ref_cache(): rename function from invalidate_cached_refs()) by a rename and elevated to be publicly usable in 8be8bde (2011-10-17, invalidate_ref_cache(): expose this function in the refs API) However it is not used anymore, as 8bf90dc (2011-10-17, write_ref_sha1(): only invalidate the loose ref cache) and (much) later 506a760 (2013-04-22, refs: change how packed refs are deleted) removed any calls to this function. So it seems as if we don't need that function any more, good bye! Signed-off-by: Stefan Beller <stefanbeller@googlemail.com> Acked-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23Almost 1.8.4.2 ;-)Libravatar Junio C Hamano1-0/+13
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-23Merge branch 'jc/ls-files-killed-optim' into maintLibravatar Junio C Hamano4-17/+67
"git ls-files -k" needs to crawl only the part of the working tree that may overlap the paths in the index to find killed files, but shared code with the logic to find all the untracked files, which made it unnecessarily inefficient. * jc/ls-files-killed-optim: dir.c::test_one_path(): work around directory_exists_in_index_icase() breakage t3010: update to demonstrate "ls-files -k" optimization pitfalls ls-files -k: a directory only can be killed if the index has a non-directory dir.c: use the cache_* macro to access the current index
2013-10-23Merge branch 'jh/checkout-auto-tracking' into maintLibravatar Junio C Hamano4-8/+45
"git branch --track" had a minor regression in v1.8.3.2 and later that made it impossible to base your local work on anything but a local branch of the upstream repository you are tracking from. * jh/checkout-auto-tracking: t3200: fix failure on case-insensitive filesystems branch.c: Relax unnecessary requirement on upstream's remote ref name t3200: Add test demonstrating minor regression in 41c21f2 Refer to branch.<name>.remote/merge when documenting --track t3200: Minor fix when preparing for tracking failure t2024: Fix &&-chaining and a couple of typos
2013-10-23Merge branch 'nd/fetch-into-shallow' into maintLibravatar Junio C Hamano12-160/+152
When there is no sufficient overlap between old and new history during a "git fetch" into a shallow repository, objects that the sending side knows the receiving end has were unnecessarily sent. * nd/fetch-into-shallow: Add testcase for needless objects during a shallow fetch list-objects: mark more commits as edges in mark_edges_uninteresting list-objects: reduce one argument in mark_edges_uninteresting upload-pack: delegate rev walking in shallow fetch to pack-objects shallow: add setup_temporary_shallow() shallow: only add shallow graft points to new shallow file move setup_alternate_shallow and write_shallow_commits to shallow.c
2013-10-18git-merge: document the -S optionLibravatar Nicolas Vigier1-1/+5
The option to gpg sign a merge commit is available but was not documented. Use wording from the git-commit(1) manpage. Signed-off-by: Nicolas Vigier <boklm@mars-attacks.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-17Start preparing for 1.8.4.2Libravatar Junio C Hamano2-1/+51
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-17Merge branch 'jk/upload-pack-keepalive' into maintLibravatar Junio C Hamano2-1/+35
* jk/upload-pack-keepalive: upload-pack: bump keepalive default to 5 seconds upload-pack: send keepalive packets during pack computation
2013-10-17Merge branch 'bc/http-backend-allow-405' into maintLibravatar Junio C Hamano1-2/+4
* bc/http-backend-allow-405: http-backend: provide Allow header for 405
2013-10-17Merge branch 'jc/cvsserver-perm-bit-fix' into maintLibravatar Junio C Hamano1-1/+1
* jc/cvsserver-perm-bit-fix: cvsserver: pick up the right mode bits
2013-10-17Merge branch 'js/add-i-mingw' into maintLibravatar Junio C Hamano1-1/+1
* js/add-i-mingw: add--interactive: fix external command invocation on Windows
2013-10-17Merge branch 'nd/git-dir-pointing-at-gitfile' into maintLibravatar Junio C Hamano2-5/+8
* nd/git-dir-pointing-at-gitfile: Make setup_git_env() resolve .git file when $GIT_DIR is not specified
2013-10-17Merge branch 'jk/has-sha1-file-retry-packed' into maintLibravatar Junio C Hamano1-1/+4
* jk/has-sha1-file-retry-packed: has_sha1_file: re-check pack directory before giving up
2013-10-17Merge branch 'ap/commit-author-mailmap' into maintLibravatar Junio C Hamano2-1/+18
* ap/commit-author-mailmap: commit: search author pattern against mailmap
2013-10-17Merge branch 'es/rebase-i-no-abbrev' into maintLibravatar Junio C Hamano2-2/+117
* es/rebase-i-no-abbrev: rebase -i: fix short SHA-1 collision t3404: rebase -i: demonstrate short SHA-1 collision t3404: make tests more self-contained Conflicts: t/t3404-rebase-interactive.sh
2013-10-17Merge branch 'rt/rebase-p-no-merge-summary' into maintLibravatar Junio C Hamano2-1/+25
* rt/rebase-p-no-merge-summary: rebase --preserve-merges: ignore "merge.log" config
2013-10-17Merge branch 'es/rebase-i-respect-core-commentchar' into maintLibravatar Junio C Hamano1-1/+1
* es/rebase-i-respect-core-commentchar: rebase -i: fix cases ignoring core.commentchar
2013-10-17t4254: modernize testsLibravatar SZEDER Gábor1-21/+15
- Don't start tests with 'test $? = 0' to catch preparation done outside the test_expect_success block. - Move writing the bogus patch and the expected output into the appropriate test_expect_success blocks. - Use the test_must_fail helper instead of manually checking for non-zero exit code. - Use the debug-friendly test_path_is_file helper instead of 'test -f'. - No space after '>'. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-15git-prune-packed.txt: fix reference to GIT_OBJECT_DIRECTORYLibravatar Steffen Prohaska1-1/+1
git-prune-packed operates on GIT_OBJECT_DIRECTORY, not GIT_OBJECT_DIR. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-14clone --branch: refuse to clone if upstream repo is emptyLibravatar Ralf Thielow2-1/+11
Since 920b691 (clone: refuse to clone if --branch points to bogus ref) we refuse to clone with option "-b" if the specified branch does not exist in the (non-empty) upstream. If the upstream repository is empty, the branch doesn't exist, either. So refuse the clone too. Reported-by: Robert Mitwicki <robert.mitwicki@opensoftware.pl> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Acked-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2013-09-26Git 1.8.4.1Libravatar Jonathan Nieder3-15/+37
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2013-09-26Merge branch 'mm/rebase-continue-freebsd-WB' into maintLibravatar Jonathan Nieder1-1/+10
* mm/rebase-continue-freebsd-WB: rebase: fix run_specific_rebase's use of "return" on FreeBSD
2013-09-26Merge branch 'km/svn-1.8-serf-only' into maintLibravatar Jonathan Nieder2-3/+34
* km/svn-1.8-serf-only: Git.pm: revert _temp_cache use of temp_is_locked git-svn: allow git-svn fetching to work using serf Git.pm: add new temp_is_locked function
2013-09-26Merge branch 'js/xread-in-full' into maintLibravatar Jonathan Nieder1-1/+1
* js/xread-in-full: stream_to_pack: xread does not guarantee to read all requested bytes
2013-09-26Merge branch 'bc/send-email-ssl-die-message-fix' into maintLibravatar Jonathan Nieder1-1/+1
* bc/send-email-ssl-die-message-fix: send-email: don't call methods on undefined values
2013-09-24git-remote-mediawiki: bugfix for pages w/ >500 revisionsLibravatar Benoit Person2-2/+35
Mediawiki introduces a new API for queries w/ more than 500 results in version 1.21. That change triggered an infinite loop while cloning a mediawiki with such a page. The latest API renamed and moved the "continuing" information in the response, necessary to build the next query. The code failed to retrieve that information but still detected that it was in a "continuing query". As a result, it launched the same query over and over again. If a "continuing" information is detected in the response (old or new), the next query is updated accordingly. If not, we quit assuming it's not a continuing query. Reported-by: Benjamin Cathey Signed-off-by: Benoit Person <benoit.person@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2013-09-18Start preparing for 1.8.4.1Libravatar Junio C Hamano2-1/+51
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-18Merge branch 'bc/completion-for-bash-3.0' into maintLibravatar Junio C Hamano3-3/+7
Some people still use rather old versions of bash, which cannot grok some constructs like 'printf -v varname' the prompt and completion code started to use recently. * bc/completion-for-bash-3.0: contrib/git-prompt.sh: handle missing 'printf -v' more gracefully t9902-completion.sh: old Bash still does not support array+=('') notation git-completion.bash: use correct Bash/Zsh array length syntax
2013-09-18Merge branch 'mm/no-shell-escape-in-die-message' into maintLibravatar Junio C Hamano2-1/+14
Fixes a minor bug in "git rebase -i" (there could be others, as the root cause is pretty generic) where the code feeds a random, data dependeant string to 'echo' and expects it to come out literally. * mm/no-shell-escape-in-die-message: die_with_status: use "printf '%s\n'", not "echo"
2013-09-18Merge branch 'jl/some-submodule-config-are-not-boolean' into maintLibravatar Junio C Hamano2-0/+16
* jl/some-submodule-config-are-not-boolean: avoid segfault on submodule.*.path set to an empty "true"
2013-09-18Merge branch 'tr/log-full-diff-keep-true-parents' into maintLibravatar Junio C Hamano8-3/+134
Output from "git log --full-diff -- <pathspec>" looked strange, because comparison was done with the previous ancestor that touched the specified <pathspec>, causing the patches for paths outside the pathspec to show more than the single commit has changed. * tr/log-full-diff-keep-true-parents: log: use true parents for diff when walking reflogs log: use true parents for diff even when rewriting
2013-09-18Merge branch 'jc/transport-do-not-use-connect-twice-in-fetch' into maintLibravatar Junio C Hamano4-31/+134
The auto-tag-following code in "git fetch" tries to reuse the same transport twice when the serving end does not cooperate and does not give tags that point to commits that are asked for as part of the primary transfer. Unfortunately, Git-aware transport helper interface is not designed to be used more than once, hence this does not work over smart-http transfer. * jc/transport-do-not-use-connect-twice-in-fetch: builtin/fetch.c: Fix a sparse warning fetch: work around "transport-take-over" hack fetch: refactor code that fetches leftover tags fetch: refactor code that prepares a transport fetch: rename file-scope global "transport" to "gtransport" t5802: add test for connect helper
2013-09-18Merge branch 'sp/clip-read-write-to-8mb' into maintLibravatar Junio C Hamano6-27/+26
Send a large request to read(2)/write(2) as a smaller but still reasonably large chunks, which would improve the latency when the operation needs to be killed and incidentally works around broken 64-bit systems that cannot take a 2GB write or read in one go. * sp/clip-read-write-to-8mb: Revert "compat/clipped-write.c: large write(2) fails on Mac OS X/XNU" xread, xwrite: limit size of IO to 8MB
2013-09-18Merge branch 'jk/mailmap-incomplete-line' into maintLibravatar Junio C Hamano2-13/+24
* jk/mailmap-incomplete-line: mailmap: handle mailmap blobs without trailing newlines
2013-09-17t3200: fix failure on case-insensitive filesystemsLibravatar Eric Sunshine1-0/+1
62d94a3a (t3200: Add test demonstrating minor regression in 41c21f2; 2013-09-08) introduced a test which creates a directory named 'a', however, on case-insensitive filesystems, this action fails with a "fatal: cannot mkdir a: File exists" error due to a file named 'A' left over from earlier tests. Resolve this problem. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-17t7406-submodule-update: add missing &&Libravatar Tay Ray Chuan1-1/+1
322bb6e (2011 Aug 11) introduced a new subshell at the end of a test case but omitted a '&&' to join the two; fix this. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-12http-backend: provide Allow header for 405Libravatar Brian M. Carlson1-2/+4
The HTTP 1.1 standard requires an Allow header for 405 Method Not Allowed: The response MUST include an Allow header containing a list of valid methods for the requested resource. So provide such a header when we return a 405 to the user agent. Signed-off-by: Brian M. Carlson <sandals@crustytoothpaste.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-11Merge branch 'maint' of git://github.com/git-l10n/git-po into maintLibravatar Junio C Hamano1-11/+11
* 'maint' of git://github.com/git-l10n/git-po: l10n: de.po: use "das Tag" instead of "der Tag"
2013-09-11cvsserver: pick up the right mode bitsLibravatar Junio C Hamano1-1/+1
When determining the file mode from either ls-tree or diff-tree output, we used to grab these octal mode string (typically 100644 or 100755) and then did $git_perms .= "r" if ( $mode & 4 ); $git_perms .= "w" if ( $mode & 2 ); $git_perms .= "x" if ( $mode & 1 ); which was already wrong, as (100644 & 4) is very different from oct("100644") & 4. An earlier refactoring 2c3af7e7 (cvsserver: factor out git-log parsing logic, 2012-10-13) further changed it to pick the third octal digit (10*0*644 or 10*0*755) from the left and then do the above conversion, which does not make sense, either. Let's use the third digit from the last of the octal mode string to make sure we get the executable and read bits right. Signed-off-by: Junio C Hamano <gitster@pobox.com> Tested-by: Michael Cronenworth <mike@cchtml.com>
2013-09-10send-email: don't call methods on undefined valuesLibravatar Brian M. Carlson1-1/+1
If SSL verification is enabled in git send-email, we could attempt to call a method on an undefined value if the verification failed, since $smtp would end up being undef. Look up the error string in a way that will produce a helpful error message and not cause further errors. Signed-off-by: Brian M. Carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09upload-pack: bump keepalive default to 5 secondsLibravatar Jeff King2-2/+2
There is no reason not to turn on keepalives by default. They take very little bandwidth, and significantly less than the progress reporting they are replacing. And in the case that progress reporting is on, we should never need to send a keepalive anyway, as we will constantly be showing progress and resetting the keepalive timer. We do not necessarily know what the client's idea of a reasonable timeout is, so let's keep this on the low side of 5 seconds. That is high enough that we will always prefer our normal 1-second progress reports to sending a keepalive packet, but low enough that no sane client should consider the connection hung. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09upload-pack: send keepalive packets during pack computationLibravatar Jeff King2-1/+35
When upload-pack has started pack-objects, there may be a quiet period while pack-objects prepares the pack (i.e., counting objects and delta compression). Normally we would see (and send to the client) progress information, but if "--quiet" is in effect, pack-objects will produce nothing at all until the pack data is ready. On a large repository, this can take tens of seconds (or even minutes if the system is loaded or the repository is badly packed). Clients or intermediate proxies can sometimes give up in this situation, assuming that the server or connection has hung. This patch introduces a "keepalive" option; if upload-pack sees no data from pack-objects for a certain number of seconds, it will send an empty sideband data packet to let the other side know that we are still working on it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09branch.c: Relax unnecessary requirement on upstream's remote ref nameLibravatar Per Cederqvist2-3/+2
When creating an upstream relationship, we use the configured remotes and their refspecs to determine the upstream configuration settings branch.<name>.remote and branch.<name>.merge. However, if the matching refspec does not have refs/heads/<something> on the remote side, we end up rejecting the match, and failing the upstream configuration. It could be argued that when we set up an branch's upstream, we want that upstream to also be a proper branch in the remote repo. Although this is typically the common case, there are cases (as demonstrated by the previous patch in this series) where this requirement prevents a useful upstream relationship from being formed. Furthermore: - We have fundamentally no say in how the remote repo have organized its branches. The remote repo may put branches (or branch-like constructs that are insteresting for downstreams to track) outside refs/heads/*. - The user may intentionally want to track a non-branch from a remote repo, by using a branch and configured upstream in the local repo. Relaxing the checking to only require a matching remote/refspec allows the testcase introduced in the previous patch to succeed, and has no negative effect on the rest of the test suite. This patch fixes a behavior (arguably a regression) first introduced in 41c21f2 (branch.c: Validate tracking branches with refspecs instead of refs/remotes/*) on 2013-04-21 (released in >= v1.8.3.2). Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09t3200: Add test demonstrating minor regression in 41c21f2Libravatar Johan Herland1-0/+34
In 41c21f2 (branch.c: Validate tracking branches with refspecs instead of refs/remotes/*), we changed the rules for what is considered a valid tracking branch (a.k.a. upstream branch). We now use the configured remotes and their refspecs to determine whether a proposed tracking branch is in fact within the domain of a remote, and we then use that information to deduce the upstream configuration (branch.<name>.remote and branch.<name>.merge). However, with that change, we also check that - in addition to a matching refspec - the result of mapping the tracking branch through that refspec (i.e. the corresponding ref name in the remote repo) happens to start with "refs/heads/". In other words, we require that a tracking branch refers to a _branch_ in the remote repo. Now, consider that you are e.g. setting up an automated building/testing infrastructure for a group of similar "source" repositories. The build/test infrastructure consists of a central scheduler, and a number of build/test "slave" machines that perform the actual build/test work. The scheduler monitors the group of similar repos for changes (e.g. with a periodic "git fetch"), and triggers builds/tests to be run on one or more slaves. Graphically the changes flow between the repos like this: Source #1 -------v ----> Slave #1 / Source #2 -----> Scheduler -----> Slave #2 \ Source #3 -------^ ----> Slave #3 ... ... The scheduler maintains a single Git repo with each of the source repos set up as distinct remotes. The slaves also need access to all the changes from all of the source repos, so they pull from the scheduler repo, but using the following custom refspec: remote.origin.fetch = "+refs/remotes/*:refs/remotes/*" This makes all of the scheduler's remote-tracking branches automatically available as identical remote-tracking branches in each of the slaves. Now, consider what happens if a slave tries to create a local branch with one of the remote-tracking branches as upstream: git branch local_branch --track refs/remotes/source-1/some_branch Git now looks at the configured remotes (in this case there is only "origin", pointing to the scheduler's repo) and sees refs/remotes/source-1/some_branch matching origin's refspec. Mapping through that refspec we find that the corresponding remote ref name is "refs/remotes/source-1/some_branch". However, since this remote ref name does not start with "refs/heads/", we discard it as a suitable upstream, and the whole command fails. This patch adds a testcase demonstrating this failure by creating two source repos ("a" and "b") that are forwarded through a scheduler ("c") to a slave repo ("d"), that then tries create a local branch with an upstream. See the next patch in this series for the exciting conclusion to this story... Reported-by: Per Cederqvist <cederp@opera.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09Refer to branch.<name>.remote/merge when documenting --trackLibravatar Johan Herland1-2/+4
Make it easier for readers to find the actual config variables that implement the "upstream" relationship. Suggested-by: Per Cederqvist <cederp@opera.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09t3200: Minor fix when preparing for tracking failureLibravatar Johan Herland1-1/+2
We're testing that trying to --track a ref that is not covered by any remote refspec should fail. For that, we want to have refs/remotes/local/master present, but we also want the remote.local.fetch refspec to NOT match refs/remotes/local/master (so that the tracking setup will fail, as intended). However, when doing "git fetch local" to ensure the existence of refs/remotes/local/master, we must not already have changed remote.local.fetch so as to cause refs/remotes/local/master not to be fetched. Therefore, set remote.local.fetch to refs/heads/*:refs/remotes/local/* BEFORE we fetch, and then reset it to refs/heads/s:refs/remotes/local/s AFTER we have fetched (but before we test --track). Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09t2024: Fix &&-chaining and a couple of typosLibravatar Johan Herland1-3/+3
Improved-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09rebase: fix run_specific_rebase's use of "return" on FreeBSDLibravatar Matthieu Moy1-1/+10
Since a1549e10, git-rebase--am.sh uses the shell's "return" statement, to mean "return from the current file inclusion", which is POSIXly correct, but badly interpreted on FreeBSD, which returns from the current function, hence skips the finish_rebase statement that follows the file inclusion. Make the use of "return" portable by using the file inclusion as the last statement of a function. Reported-by: Christoph Mallon <christoph.mallon@gmx.de> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-08l10n: de.po: use "das Tag" instead of "der Tag"Libravatar Ralf Thielow1-11/+11
Use "das Tag" to avoid confusion with the German word "Tag" (day). Reported-by: Dirk Heinrichs <dirk.heinrichs@altum.de> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
2013-09-05Merge branch 'nd/fetch-pack-shallow-fix' into maintLibravatar Junio C Hamano2-1/+19
The recent "short-cut clone connectivity check" topic broke a shallow repository when a fetch operation tries to auto-follow tags. * nd/fetch-pack-shallow-fix: fetch-pack: do not remove .git/shallow file when --depth is not specified