sort by:
Revision Author Date Message Commit Date
70cce99 git-fetch-pack uses URLs like git-fetch "git fetch-pack" allows [<host>:]<directory> to point out the source repository. Use the term <repository>, which is already used in "git fetch" or "git pull" to describe URLs supported by Git. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 11 November 2013, 20:18:05 UTC
d7d2c87 Git 1.8.4.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 November 2013, 20:06:19 UTC
cdc0c0f Merge branch 'jn/test-prereq-perl-doc' into maint The interaction between use of Perl in our test suite and NO_PERL has been clarified a bit. * jn/test-prereq-perl-doc: t/README: tests can use perl even with NO_PERL 08 November 2013, 20:01:58 UTC
4bc3d3f Merge branch 'ap/remote-hg-unquote-cquote' into maint A fast-import stream expresses a pathname with funny characters by quoting them in C style; remote-hg remote helper (in contrib/) forgot to unquote such a path. * ap/remote-hg-unquote-cquote: remote-hg: unquote C-style paths when exporting 08 November 2013, 20:01:14 UTC
9196a2f Merge branch 'jc/upload-pack-send-symref' into maint One long-standing flaw in the pack transfer protocol used by "git clone" was that there was no way to tell the other end which branch "HEAD" points at, and the receiving end needed to guess. A new capability has been defined in the pack protocol to convey this information so that cloning from a repository with more than one branches pointing at the same commit where the HEAD is at now reliably sets the initial branch in the resulting repository. * jc/upload-pack-send-symref: t5570: Update for clone-progress-to-stderr branch t5570: Update for symref capability clone: test the new HEAD detection logic connect: annotate refs with their symref information in get_remote_head() connect.c: make parse_feature_value() static upload-pack: send non-HEAD symbolic refs upload-pack: send symbolic ref information as capability upload-pack.c: do not pass confusing cb_data to mark_our_ref() t5505: fix "set-head --auto with ambiguous HEAD" test 08 November 2013, 19:38:00 UTC
e5becd0 Merge branch 'jk/http-auth-redirects' into maint We did not handle cases where http transport gets redirected during the authorization request (e.g. from http:// to https://). * jk/http-auth-redirects: http.c: Spell the null pointer as NULL remote-curl: rewrite base url from info/refs redirects remote-curl: store url as a strbuf remote-curl: make refs_url a strbuf http: update base URLs when we see redirects http: provide effective url to callers http: hoist credential request out of handle_curl_result http: refactor options to http_get_* http_request: factor out curlinfo_strbuf http_get_file: style fixes 08 November 2013, 19:37:26 UTC
486b65a Start preparing for 1.8.4.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 November 2013, 22:39:47 UTC
8edf8c0 Merge branch 'sc/doc-howto-dumb-http' into maint An ancient How-To on serving Git repositories on an HTTP server lacked a warning that it has been mostly superseded with more modern way. * sc/doc-howto-dumb-http: doc/howto: warn about (dumb)http server document being too old 07 November 2013, 22:37:39 UTC
5022b58 Merge branch 'vd/doc-unpack-objects' into maint The synopsis section of "git unpack-objects" documentation has been clarified a bit. * vd/doc-unpack-objects: Documentation: "pack-file" is not literal in unpack-objects Documentation: restore a space in unpack-objects usage 07 November 2013, 22:37:36 UTC
4ccf2f5 Merge branch 'jk/subtree-install-fix' into maint We did not generate HTML version of documentation to "git subtree" in contrib/. * jk/subtree-install-fix: subtree: add makefile target for html docs 07 November 2013, 22:37:17 UTC
46992b5 Merge branch 'hn/log-graph-color-octopus' into maint Coloring around octopus merges in "log --graph" output was screwy. * hn/log-graph-color-octopus: graph: fix coloring around octopus merges 07 November 2013, 22:37:11 UTC
07c55c0 Merge branch 'mm/checkout-auto-track-fix' into maint "git checkout topic", when there is not yet a local "topic" branch but there is a unique remote-tracking branch for a remote "topic" branch, pretended as if "git checkout -t -b topic remote/$r/topic" (for that unique remote $r) was run. This hack however was not implemented for "git checkout topic --". * mm/checkout-auto-track-fix: checkout: proper error message on 'git checkout foo bar --' checkout: allow dwim for branch creation for "git checkout $branch --" 07 November 2013, 22:36:59 UTC
9ad3f74 Merge branch 'sg/prompt-svn-remote-fix' into maint Bash prompting code to deal with an SVN remote as an upstream were coded in a way not supported by older Bash versions (3.x). * sg/prompt-svn-remote-fix: bash prompt: don't use '+=' operator in show upstream code path 07 November 2013, 22:36:45 UTC
0ceb753 Merge branch 'jk/split-broken-ident' into maint The fall-back parsing of commit objects with broken author or committer lines were less robust than ideal in picking up the timestamps. * jk/split-broken-ident: split_ident: parse timestamp from end of line 07 November 2013, 22:34:51 UTC
0faff47 Merge branch 'jc/revision-range-unpeel' into maint "git rev-list --objects ^v1.0^ v1.0" gave v1.0 tag itself in the output, but "git rev-list --objects v1.0^..v1.0" did not. * jc/revision-range-unpeel: revision: do not peel tags used in range notation 07 November 2013, 22:34:14 UTC
8447dc8 gitignore.txt: fix documentation of "**" patterns "**" means bold in ASCIIDOC, so we need to escape it. Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 November 2013, 18:49:52 UTC
61e2e22 Documentation: "pack-file" is not literal in unpack-objects Make it clear that "pack-file" is not to be spelled as is in the unpack-objects usage. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 November 2013, 16:13:35 UTC
7242498 Documentation: restore a space in unpack-objects usage The commit 87b7b84 removed a space in the unpack-objects usage, which makes the synopsis a bit confusing. This patch simply restores it. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 31 October 2013, 22:11:28 UTC
95c62fb subtree: add makefile target for html docs The Makefile currently builds the roff manpage, but not the html form. As some people may prefer the latter, let's make it an option to build that, too. We also wire it into "make doc" so that it is built by default. This patch does not build or install it as part of "install-doc"; that would require extra infrastructure to handle installing the html as we do in git's regular Documentation/ tree. That can come later if somebody is interested. Tested-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 30 October 2013, 17:47:37 UTC
d619cfc t5570: Update for clone-progress-to-stderr branch git clone now reports its progress to standard error, which throws off t5570. Using test_i18ngrep instead of test_cmp allows the test to be more flexible by only looking for the expected error and ignoring any other output from the program. Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 30 October 2013, 17:39:42 UTC
6d52bc3 doc/howto: warn about (dumb)http server document being too old Describe when it is still applicable, and tell people where to go for most normal cases. Signed-off-by: Sitaram Chamarty <sitaram@atc.tcs.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 October 2013, 20:24:56 UTC
f8fc0ee t/README: tests can use perl even with NO_PERL The git build system supports a NO_PERL switch to avoid installing perl bindings or other features (like "git add --patch") that rely on perl on runtime, but even with NO_PERL it has not been possible for a long time to run tests without perl. Helpers such as nul_to_q () { "$PERL_PATH" -pe 'y/\000/Q/' } use perl as a better tr or sed and are regularly used in tests without worrying to add a PERL prerequisite. Perl is portable enough that it seems fine to keep relying on it for this kind of thing in tests (and more readable than the alternative of trying to find POSIXy equivalents). Update the test documentation to clarify this. Reported-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 October 2013, 19:32:18 UTC
dcb11cc Git 1.8.4.2 Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 October 2013, 17:21:29 UTC
df1ef91 Merge branch 'jk/clone-progress-to-stderr' into maint "git clone" gave some progress messages to the standard output, not to the standard error, and did not allow suppressing them with the "--no-progress" option. * jk/clone-progress-to-stderr: clone: always set transport options clone: treat "checking connectivity" like other progress clone: send diagnostic messages to stderr 28 October 2013, 17:19:24 UTC
da212ea Merge branch 'jk/format-patch-from' into maint "format-patch --from=<whom>" forgot to omit unnecessary in-body from line, i.e. when <whom> is the same as the real author. * jk/format-patch-from: format-patch: print in-body "From" only when needed 28 October 2013, 17:18:43 UTC
77bc430 Merge branch 'jk/shortlog-tolerate-broken-commit' into maint "git shortlog" used to choke and die when there is a malformed commit (e.g. missing authors); it now simply ignore such a commit and keeps going. * jk/shortlog-tolerate-broken-commit: shortlog: ignore commits with missing authors 28 October 2013, 17:17:31 UTC
b28325d Merge branch 'jk/diff-algo' into maint "git merge-recursive" did not parse its "--diff-algorithm=" command line option correctly. * jk/diff-algo: merge-recursive: fix parsing of "diff-algorithm" option 28 October 2013, 17:16:11 UTC
3fa3666 test-lib: fix typo in comment Point test writers to the test_expect_* functions properly. Signed-off-by: Torstein Hegge <hegge@resisty.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 October 2013, 16:18:25 UTC
3fc0dca sha1_file: move comment about return value where it belongs Commit 5b0864070 (sha1_object_info_extended: make type calculation optional, Jul 12 2013) changed the return value of the sha1_object_info_extended function to 0/-1 for success/error. Previously this function returned the object type for success or -1 for error. But unfortunately the above commit forgot to change or move the comment above this function that says "returns enum object_type or negative". To fix this inconsistency, let's move the comment above the sha1_object_info function where it is still true. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 October 2013, 16:07:01 UTC
70900ed http.c: Spell the null pointer as NULL Commit 1bbcc224 ("http: refactor options to http_get_*", 28-09-2013) changed the type of final 'options' argument of the http_get_file() function from an int to an 'struct http_get_options' pointer. However, it neglected to update the (single) call site. Since this call was passing '0' to that argument, it was (correctly) being interpreted as a null pointer. Change to argument to NULL. Noticed by sparse. ("Using plain integer as NULL pointer") Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Acked-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 October 2013, 21:42:26 UTC
ca46280 Almost 1.8.4.2 ;-) Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 October 2013, 20:34:39 UTC
e03a501 Merge branch 'jc/ls-files-killed-optim' into maint "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 23 October 2013, 20:33:08 UTC
74051fa Merge branch 'jh/checkout-auto-tracking' into maint "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 23 October 2013, 20:32:50 UTC
6ba0d95 Merge branch 'nd/fetch-into-shallow' into maint 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 23 October 2013, 20:32:17 UTC
1136265 remote-hg: unquote C-style paths when exporting git-fast-import documentation says that paths can be C-style quoted. Unfortunately, the current remote-hg helper doesn't unquote quoted path and pass them as-is to Mercurial when the commit is created. This results in the following situation: - clone a mercurial repository with git - add a file with space in a directory: `>dir/foo\ bar` - commit that new file, and push the change to mercurial - the mercurial repository now has a new directory named '"dir', which contains a file named 'foo bar"' Use Python str.decode('string-escape') to unquote the string if it starts and ends with ". It has been tested with quotes, spaces, and utf-8 encoded file-names. Signed-off-by: Antoine Pelisse <apelisse@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 October 2013, 16:45:53 UTC
360a326 t5570: Update for clone-progress-to-stderr branch git clone now reports its progress to standard error, which throws off t5570. Using test_i18ngrep instead of test_cmp allows the test to be more flexible by only looking for the expected error and ignoring any other output from the program. Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 October 2013, 18:38:53 UTC
c4125fc Merge branch 'jk/clone-progress-to-stderr' into jc/upload-pack-send-symref * jk/clone-progress-to-stderr: clone: always set transport options clone: treat "checking connectivity" like other progress clone: send diagnostic messages to stderr 22 October 2013, 18:38:42 UTC
2ecb573 t5570: Update for symref capability git-daemon now uses the symref capability to send the correct HEAD reference, so the test for that in t5570 now passes. Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 October 2013, 18:34:23 UTC
bca3969 checkout: proper error message on 'git checkout foo bar --' The previous code was detecting the presence of "--" by looking only at argument 1. As a result, "git checkout foo bar --" was interpreted as an ambiguous file/revision list, and errored out with: error: pathspec 'foo' did not match any file(s) known to git. error: pathspec 'bar' did not match any file(s) known to git. error: pathspec '--' did not match any file(s) known to git. This patch fixes it by walking through the argument list to find the "--", and now complains about the number of references given. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 October 2013, 19:57:16 UTC
a047faf checkout: allow dwim for branch creation for "git checkout $branch --" The "--" notation disambiguates files and branches, but as a side-effect of the previous implementation, also disabled the branch auto-creation when $branch does not exist. A possible scenario is then: git checkout $branch => fails if $branch is both a ref and a file, and suggests -- git checkout $branch -- => refuses to create the $branch This patch allows the second form to create $branch, and since the -- is provided, it does not look for file named $branch. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 October 2013, 19:56:06 UTC
339c17b graph: fix coloring around octopus merges When drawing the graph of an octopus merge, we draw a horizontal line from parents 3 and above into the asterisk representing the commit. The sections of this line should be colored to match the graph lines coming in from above. However, if the commit is not in the left-most column we do not take into account the columns to the left of the commit when calculating these colors. Fix this by adding the appropriate offset to the column index used for calculating the color. Signed-off-by: Hemmo Nieminen <hemmo.nieminen@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 October 2013, 19:48:48 UTC
5f737ac git-merge: document the -S option 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> 18 October 2013, 19:47:33 UTC
92ab409 Start preparing for 1.8.4.2 Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 October 2013, 22:50:45 UTC
9432c6a Merge branch 'jk/upload-pack-keepalive' into maint * jk/upload-pack-keepalive: upload-pack: bump keepalive default to 5 seconds upload-pack: send keepalive packets during pack computation 17 October 2013, 22:46:01 UTC
968792e Merge branch 'bc/http-backend-allow-405' into maint * bc/http-backend-allow-405: http-backend: provide Allow header for 405 17 October 2013, 22:46:00 UTC
da39d5e Merge branch 'jc/cvsserver-perm-bit-fix' into maint * jc/cvsserver-perm-bit-fix: cvsserver: pick up the right mode bits 17 October 2013, 22:45:58 UTC
fa0963d Merge branch 'js/add-i-mingw' into maint * js/add-i-mingw: add--interactive: fix external command invocation on Windows 17 October 2013, 22:45:56 UTC
f8aeacf Merge branch 'nd/git-dir-pointing-at-gitfile' into maint * nd/git-dir-pointing-at-gitfile: Make setup_git_env() resolve .git file when $GIT_DIR is not specified 17 October 2013, 22:45:55 UTC
7d9dd6d Merge branch 'jk/has-sha1-file-retry-packed' into maint * jk/has-sha1-file-retry-packed: has_sha1_file: re-check pack directory before giving up 17 October 2013, 22:45:54 UTC
87b24a4 Merge branch 'ap/commit-author-mailmap' into maint * ap/commit-author-mailmap: commit: search author pattern against mailmap 17 October 2013, 22:45:52 UTC
f8a3fd2 Merge branch 'es/rebase-i-no-abbrev' into maint * 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 17 October 2013, 22:45:50 UTC
9a3a02b Merge branch 'rt/rebase-p-no-merge-summary' into maint * rt/rebase-p-no-merge-summary: rebase --preserve-merges: ignore "merge.log" config 17 October 2013, 22:45:45 UTC
6f89c27 Merge branch 'es/rebase-i-respect-core-commentchar' into maint * es/rebase-i-respect-core-commentchar: rebase -i: fix cases ignoring core.commentchar 17 October 2013, 22:45:24 UTC
ddeaf7e t4254: modernize tests - 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> 17 October 2013, 22:05:53 UTC
895c5ba revision: do not peel tags used in range notation A range notation "A..B" means exactly the same thing as what "^A B" means, i.e. the set of commits that are reachable from B but not from A. But the internal representation after the revision parser parsed these two notations are subtly different. - "rev-list ^A B" leaves A and B in the revs->pending.objects[] array, with the former marked as UNINTERESTING and the revision traversal machinery propagates the mark to underlying commit objects A^0 and B^0. - "rev-list A..B" peels tags and leaves A^0 (marked as UNINTERESTING) and B^0 in revs->pending.objects[] array before the traversal machinery kicks in. This difference usually does not matter, but starts to matter when the --objects option is used. For example, we see this: $ git rev-list --objects v1.8.4^1..v1.8.4 | grep $(git rev-parse v1.8.4) $ git rev-list --objects v1.8.4 ^v1.8.4^1 | grep $(git rev-parse v1.8.4) 04f013dc38d7512eadb915eba22efc414f18b869 v1.8.4 With the former invocation, the revision traversal machinery never hears about the tag v1.8.4 (it only sees the result of peeling it, i.e. the commit v1.8.4^0), and the tag itself does not appear in the output. The latter does send the tag object itself to the output. Make the range notation keep the unpeeled objects and feed them to the traversal machinery to fix this inconsistency. Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 October 2013, 23:17:09 UTC
3991e91 git-prune-packed.txt: fix reference to GIT_OBJECT_DIRECTORY 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> 15 October 2013, 23:01:22 UTC
52ec889 bash prompt: don't use '+=' operator in show upstream code path The '+=' operator is not supported by old Bash versions (3.0) we still care about. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 October 2013, 21:20:37 UTC
03818a4 split_ident: parse timestamp from end of line Split_ident currently parses left to right. Given this input: Your Name <email@example.com> 123456789 -0500\n We assume the name starts the line and runs until the first "<". That starts the email address, which runs until the first ">". Everything after that is assumed to be the timestamp. This works fine in the normal case, but is easily broken by corrupted ident lines that contain an extra ">". Some examples seen in the wild are: 1. Name <email>-<> 123456789 -0500\n 2. Name <email> <Name<email>> 123456789 -0500\n 3. Name1 <email1>, Name2 <email2> 123456789 -0500\n Currently each of these produces some email address (which is not necessarily the one the user intended) and end up with a NULL date (which is generally interpreted as the epoch by "git log" and friends). But in each case we could get the correct timestamp simply by parsing from the right-hand side, looking backwards for the final ">", and then reading the timestamp from there. In general, it's a losing battle to try to automatically guess what the user meant with their broken crud. But this particular workaround is probably worth doing. One, it's dirt simple, and can't impact non-broken cases. Two, it doesn't catch a single breakage we've seen, but rather a large class of errors (i.e., any breakage inside the email angle brackets may affect the email, but won't spill over into the timestamp parsing). And three, the timestamp is arguably more valuable to get right, because it can affect correctness (e.g., in --until cutoffs). This patch implements the right-to-left scheme described above. We adjust the tests in t4212, which generate a commit with such a broken ident, and now gets the timestamp right. We also add a test that fsck continues to detect the breakage. For reference, here are pointers to the breakages seen (as numbered above): [1] http://article.gmane.org/gmane.comp.version-control.git/221441 [2] http://article.gmane.org/gmane.comp.version-control.git/222362 [3] http://perl5.git.perl.org/perl.git/commit/13b79730adea97e660de84bbe67f9d7cbe344302 Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 October 2013, 17:41:49 UTC
050ef36 remote-curl: rewrite base url from info/refs redirects For efficiency and security reasons, an earlier commit in this series taught http_get_* to re-write the base url based on redirections we saw while making a specific request. This commit wires that option into the info/refs request, meaning that a redirect from http://example.com/foo.git/info/refs to https://example.com/bar.git/info/refs will behave as if "https://example.com/bar.git" had been provided to git in the first place. The tests bear some explanation. We introduce two new hierearchies into the httpd test config: 1. Requests to /smart-redir-limited will work only for the initial info/refs request, but not any subsequent requests. As a result, we can confirm whether the client is re-rooting its requests after the initial contact, since otherwise it will fail (it will ask for "repo.git/git-upload-pack", which is not redirected). 2. Requests to smart-redir-auth will redirect, and require auth after the redirection. Since we are using the redirected base for further requests, we also update the credential struct, in order not to mislead the user (or credential helpers) about which credential is needed. We can therefore check the GIT_ASKPASS prompts to make sure we are prompting for the new location. Because we have neither multiple servers nor https support in our test setup, we can only redirect between paths, meaning we need to turn on credential.useHttpPath to see the difference. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> 15 October 2013, 00:01:34 UTC
b227bbc remote-curl: store url as a strbuf We use a strbuf to generate the string containing the remote URL, but then detach it to a bare pointer. This makes it harder to later manipulate the URL, as we have forgotten the length (and the allocation semantics are not as clear). Let's instead keep the strbuf around. As a bonus, this eliminates a confusing double-use of the "buf" strbuf in main(). Prior to this, it was used both for constructing the url, and for reading commands from stdin. The downside is that we have to update each call site to refer to "url.buf" rather than just "url" when they want the C string. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> 15 October 2013, 00:01:15 UTC
c65d569 remote-curl: make refs_url a strbuf In the discover_refs function, we use a strbuf named "buffer" for multiple purposes. First we build the info/refs URL in it, and then detach that to a bare pointer. Then, we use the same strbuf to store the result of fetching the refs. Let's instead keep a separate refs_url strbuf. This is less confusing, as the "buffer" strbuf is now used for only one thing. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> 14 October 2013, 23:57:04 UTC
c93c92f http: update base URLs when we see redirects If a caller asks the http_get_* functions to go to a particular URL and we end up elsewhere due to a redirect, the effective_url field can tell us where we went. It would be nice to remember this redirect and short-cut further requests for two reasons: 1. It's more efficient. Otherwise we spend an extra http round-trip to the server for each subsequent request, just to get redirected. 2. If we end up with an http 401 and are going to ask for credentials, it is to feed them to the redirect target. If the redirect is an http->https upgrade, this means our credentials may be provided on the http leg, just to end up redirected to https. And if the redirect crosses server boundaries, then curl will drop the credentials entirely as it follows the redirect. However, it, it is not enough to simply record the effective URL we saw and use that for subsequent requests. We were originally fed a "base" url like: http://example.com/foo.git and we want to figure out what the new base is, even though the URLs we see may be: original: http://example.com/foo.git/info/refs effective: http://example.com/bar.git/info/refs Subsequent requests will not be for "info/refs", but for other paths relative to the base. We must ask the caller to pass in the original base, and we must pass the redirected base back to the caller (so that it can generate more URLs from it). Furthermore, we need to feed the new base to the credential code, so that requests to credential helpers (or to the user) match the URL we will be requesting. This patch teaches http_request_reauth to do this munging. Since it is the caller who cares about making more URLs, it seems at first glance that callers could simply check effective_url themselves and handle it. However, since we need to update the credential struct before the second re-auth request, we have to do it inside http_request_reauth. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> 14 October 2013, 23:56:47 UTC
7886896 http: provide effective url to callers When we ask curl to access a URL, it may follow one or more redirects to reach the final location. We have no idea this has happened, as curl takes care of the details and simply returns the final content to us. The final URL that we ended up with can be accessed via CURLINFO_EFFECTIVE_URL. Let's make that optionally available to callers of http_get_*, so that they can make further decisions based on the redirection. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> 14 October 2013, 23:55:23 UTC
2501aff http: hoist credential request out of handle_curl_result When we are handling a curl response code in http_request or in the remote-curl RPC code, we use the handle_curl_result helper to translate curl's response into an easy-to-use code. When we see an HTTP 401, we do one of two things: 1. If we already had a filled-in credential, we mark it as rejected, and then return HTTP_NOAUTH to indicate to the caller that we failed. 2. If we didn't, then we ask for a new credential and tell the caller HTTP_REAUTH to indicate that they may want to try again. Rejecting in the first case makes sense; it is the natural result of the request we just made. However, prompting for more credentials in the second step does not always make sense. We do not know for sure that the caller is going to make a second request, and nor are we sure that it will be to the same URL. Logically, the prompt belongs not to the request we just finished, but to the request we are (maybe) about to make. In practice, it is very hard to trigger any bad behavior. Currently, if we make a second request, it will always be to the same URL (even in the face of redirects, because curl handles the redirects internally). And we almost always retry on HTTP_REAUTH these days. The one exception is if we are streaming a large RPC request to the server (e.g., a pushed packfile), in which case we cannot restart. It's extremely unlikely to see a 401 response at this stage, though, as we would typically have seen it when we sent a probe request, before streaming the data. This patch drops the automatic prompt out of case 2, and instead requires the caller to do it. This is a few extra lines of code, and the bug it fixes is unlikely to come up in practice. But it is conceptually cleaner, and paves the way for better handling of credentials across redirects. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> 14 October 2013, 23:55:13 UTC
a3552ab clone --branch: refuse to clone if upstream repo is empty 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> 14 October 2013, 19:26:15 UTC
1bbcc22 http: refactor options to http_get_* Over time, the http_get_strbuf function has grown several optional parameters. We now have a bitfield with multiple boolean options, as well as an optional strbuf for returning the content-type of the response. And a future patch in this series is going to add another strbuf option. Treating these as separate arguments has a few downsides: 1. Most call sites need to add extra NULLs and 0s for the options they aren't interested in. 2. The http_get_* functions are actually wrappers around 2 layers of low-level implementation functions. We have to pass these options through individually. 3. The http_get_strbuf wrapper learned these options, but nobody bothered to do so for http_get_file, even though it is backed by the same function that does understand the options. Let's consolidate the options into a single struct. For the common case of the default options, we'll allow callers to simply pass a NULL for the options struct. The resulting code is often a few lines longer, but it ends up being easier to read (and to change as we add new options, since we do not need to update each call site). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> 01 October 2013, 00:21:59 UTC
132b70a http_request: factor out curlinfo_strbuf When we retrieve the content-type of an http response, curl gives us a pointer to internal storage, which we then copy into a strbuf. Let's factor out the get-and-copy routine, which can be used for getting other curl info. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> 30 September 2013, 20:04:45 UTC
3d1fb76 http_get_file: style fixes Besides being ugly, the extra parentheses are idiomatic for suppressing compiler warnings when we are assigning within a conditional. We aren't doing that here, and they just confuse the reader. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> 30 September 2013, 20:04:31 UTC
02a110a Git 1.8.4.1 Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> 26 September 2013, 22:01:41 UTC
6562928 merge-recursive: fix parsing of "diff-algorithm" option The "diff-algorithm" option to the recursive merge strategy takes the name of the algorithm as an option, but it uses strcmp on the option string to check if it starts with "diff-algorithm=", meaning that this options cannot actually be used. Fix this by switching to prefixcmp. At the same time, clarify the following line by using strlen instead of a hard-coded length, which also makes it consistent with nearby code. Reported-by: Luke Noel-Storr <luke.noel-storr@integrate.co.uk> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> 26 September 2013, 20:52:16 UTC
437ce60 Merge branch 'mm/rebase-continue-freebsd-WB' into maint * mm/rebase-continue-freebsd-WB: rebase: fix run_specific_rebase's use of "return" on FreeBSD 26 September 2013, 19:41:14 UTC
76deaab Merge branch 'km/svn-1.8-serf-only' into maint * 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 26 September 2013, 19:34:23 UTC
be5e850 Merge branch 'js/xread-in-full' into maint * js/xread-in-full: stream_to_pack: xread does not guarantee to read all requested bytes 26 September 2013, 19:30:44 UTC
31d757d Merge branch 'bc/send-email-ssl-die-message-fix' into maint * bc/send-email-ssl-die-message-fix: send-email: don't call methods on undefined values 26 September 2013, 19:27:29 UTC
1d905f7 git-remote-mediawiki: bugfix for pages w/ >500 revisions 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> 24 September 2013, 19:42:21 UTC
662cc30 format-patch: print in-body "From" only when needed Commit a908047 taught format-patch the "--from" option, which places the author ident into an in-body from header, and uses the committer ident in the rfc822 from header. The documentation claims that it will omit the in-body header when it is the same as the rfc822 header, but the code never implemented that behavior. This patch completes the feature by comparing the two idents and doing nothing when they are the same (this is the same as simply omitting the in-body header, as the two are by definition indistinguishable in this case). This makes it reasonable to turn on "--from" all the time (if it matches your particular workflow), rather than only using it when exporting other people's patches. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 September 2013, 18:09:51 UTC
cd4f09e shortlog: ignore commits with missing authors Most of git's traversals are robust against minor breakages in commit data. For example, "git log" will still output an entry for a commit that has a broken encoding or missing author, and will not abort the whole operation. Shortlog, on the other hand, will die as soon as it sees a commit without an author, meaning that a repository with a broken commit cannot get any shortlog output at all. Let's downgrade this fatal error to a warning, and continue the operation. We simply ignore the commit and do not count it in the total (since we do not have any author under which to file it). Alternatively, we could output some kind of "<empty>" record to collect these bogus commits. It is probably not worth it, though; we have already warned to stderr, so the user is aware that such bogosities exist, and any placeholder we came up with would either be syntactically invalid, or would potentially conflict with real data. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 September 2013, 21:41:19 UTC
643f918 clone: always set transport options A clone will always create a transport struct, whether we are cloning locally or using an actual protocol. In the local case, we only use the transport to get the list of refs, and then transfer the objects out-of-band. However, there are many options that we do not bother setting up in the local case. For the most part, these are noops, because they only affect the object-fetching stage (e.g., the --depth option). However, some options do have a visible impact. For example, giving the path to upload-pack via "-u" does not currently work for a local clone, even though we need upload-pack to get the ref list. We can just drop the conditional entirely and set these options for both local and non-local clones. Rather than keep track of which options impact the object versus the ref fetching stage, we can simply let the noops be noops (and the cost of setting the options in the first place is not high). The one exception is that we also check that the transport provides both a "get_refs_list" and a "fetch" method. We will now be checking the former for both cases (which is good, since a transport that cannot fetch refs would not work for a local clone), and we tweak the conditional to check for a "fetch" only when we are non-local. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 September 2013, 21:36:40 UTC
2856cbf clone: treat "checking connectivity" like other progress When stderr does not point to a tty, we typically suppress "we are now in this phase" progress reporting (e.g., we ask the server not to send us "counting objects" and the like). The new "checking connectivity" message is in the same vein, and should be suppressed. Since clone relies on the transport code to make the decision, we can simply sneak a peek at the "progress" field of the transport struct. That properly takes into account both the verbosity and progress options we were given, as well as the result of isatty(). Note that we do not set up that progress flag for a local clone, as we do not fetch using the transport at all. That's acceptable here, though, because we also do not perform a connectivity check in that case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 September 2013, 20:34:46 UTC
68b939b clone: send diagnostic messages to stderr Putting messages like "Cloning into.." and "done" on stdout is un-Unix and uselessly clutters the stdout channel. Send them to stderr. We have to tweak two tests to accommodate this: 1. t5601 checks for doubled output due to forking, and doesn't actually care where the output goes; adjust it to check stderr. 2. t5702 is trying to test whether progress output was sent to stderr, but naively does so by checking whether stderr produced any output. Instead, have it look for "%", a token found in progress output but not elsewhere (and which lets us avoid hard-coding the progress text in the test). This should not regress any scripts that try to parse the current output, as the output is already internationalized and therefore unstable. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 September 2013, 20:34:12 UTC
a0d3f10 Start preparing for 1.8.4.1 Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 September 2013, 19:08:09 UTC
ebb9d19 Merge branch 'bc/completion-for-bash-3.0' into maint 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 18 September 2013, 19:00:11 UTC
b25b9d5 Merge branch 'mm/no-shell-escape-in-die-message' into maint 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" 18 September 2013, 18:59:51 UTC
dd42145 Merge branch 'jl/some-submodule-config-are-not-boolean' into maint * jl/some-submodule-config-are-not-boolean: avoid segfault on submodule.*.path set to an empty "true" 18 September 2013, 18:59:35 UTC
6930cd1 Merge branch 'tr/log-full-diff-keep-true-parents' into maint 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 18 September 2013, 18:59:05 UTC
1e93c28 Merge branch 'jc/transport-do-not-use-connect-twice-in-fetch' into maint 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 18 September 2013, 18:58:18 UTC
4b510c3 Merge branch 'sp/clip-read-write-to-8mb' into maint 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 18 September 2013, 18:57:58 UTC
19230ab Merge branch 'jk/mailmap-incomplete-line' into maint * jk/mailmap-incomplete-line: mailmap: handle mailmap blobs without trailing newlines 18 September 2013, 18:57:33 UTC
8b27722 clone: test the new HEAD detection logic Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 September 2013, 04:58:59 UTC
a45b5f0 connect: annotate refs with their symref information in get_remote_head() By doing this, clients of upload-pack can now reliably tell what ref a symbolic ref points at; the updated test in t5505 used to expect failure due to the ambiguity and made sure we give diagnostics, but we no longer need to be so pessimistic. Make sure we correctly learn which branch HEAD points at from the other side instead. Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 September 2013, 04:58:46 UTC
5d54cff connect.c: make parse_feature_value() static Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 September 2013, 04:52:06 UTC
5e7dcad upload-pack: send non-HEAD symbolic refs With the same mechanism as used to tell where "HEAD" points at to the other end, we can tell the target of other symbolic refs as well. Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 September 2013, 04:51:58 UTC
7171d8c upload-pack: send symbolic ref information as capability One long-standing flaw in the pack transfer protocol was that there was no way to tell the other end which branch "HEAD" points at. With a capability "symref=HEAD:refs/heads/master", let the sender to tell the receiver what symbolic ref points at what ref. This capability can be repeated more than once to represent symbolic refs other than HEAD, such as "refs/remotes/origin/HEAD"). Add an infrastructure to collect symbolic refs, format them as extra capabilities and put it on the wire. For now, just send information on the "HEAD" and nothing else. Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 September 2013, 04:50:26 UTC
a4d695d upload-pack.c: do not pass confusing cb_data to mark_our_ref() The callee does not use cb_data, and the caller is an intermediate function in a callchain that later wants to use the cb_data for its own use. Clarify the code by breaking the dataflow explicitly by not passing cb_data down to mark_our_ref(). Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 September 2013, 04:50:02 UTC
a4dfee0 t5505: fix "set-head --auto with ambiguous HEAD" test When two or more branches point at the same commit and HEAD is pointing at one of them, without the symref extension, there is no way to remotely tell which one of these branches HEAD points at. The test in question attempts to make sure that this situation is diagnosed and results in a failure. However, even if there _were_ a way to reliably tell which branch the HEAD points at, "set-head --auto" would fail if there is no remote tracking branch. Make sure that this test does not fail for that "wrong" reason. Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 September 2013, 04:45:34 UTC
b0f49ff t3200: fix failure on case-insensitive filesystems 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> 17 September 2013, 17:18:13 UTC
d5b99f3 t7406-submodule-update: add missing && 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> 17 September 2013, 16:44:29 UTC
9247be0 http-backend: provide Allow header for 405 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> 12 September 2013, 15:44:44 UTC
c26c472 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: use "das Tag" instead of "der Tag" 12 September 2013, 04:12:02 UTC
1b48d56 cvsserver: pick up the right mode bits 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> 11 September 2013, 16:32:30 UTC
back to top