summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2015-03-28Merge branch 'tg/test-index-v4' into maintLibravatar Junio C Hamano1-3/+12
A test fix. * tg/test-index-v4: t1700: make test pass with index-v4
2015-03-28Merge branch 'ct/prompt-untracked-fix' into maintLibravatar Junio C Hamano1-0/+11
The prompt script (in contrib/) did not show the untracked sign when working in a subdirectory without any untracked files. * ct/prompt-untracked-fix: git prompt: use toplevel to find untracked files
2015-03-28Merge branch 'jk/fetch-pack' into maintLibravatar Junio C Hamano1-3/+10
"git fetch" that fetches a commit using the allow-tip-sha1-in-want extension could have failed to fetch all the requested refs. * jk/fetch-pack: fetch-pack: remove dead assignment to ref->new_sha1 fetch_refs_via_pack: free extra copy of refs filter_ref: make a copy of extra "sought" entries filter_ref: avoid overwriting ref->old_sha1 with garbage
2015-03-28Merge branch 'jk/prune-with-corrupt-refs' into maintLibravatar Junio C Hamano1-0/+114
"git prune" used to largely ignore broken refs when deciding which objects are still being used, which could spread an existing small damage and make it a larger one. * jk/prune-with-corrupt-refs: refs.c: drop curate_packed_refs repack: turn on "ref paranoia" when doing a destructive repack prune: turn on ref_paranoia flag refs: introduce a "ref paranoia" flag t5312: test object deletion code paths in a corrupted repository
2015-03-27Merge branch 'jk/smart-http-hide-refs' into maintLibravatar Junio C Hamano1-0/+11
The transfer.hiderefs support did not quite work for smart-http transport. * jk/smart-http-hide-refs: upload-pack: do not check NULL return of lookup_unknown_object upload-pack: fix transfer.hiderefs over smart-http
2015-03-23Merge branch 'sg/completion-remote' into maintLibravatar Junio C Hamano1-0/+19
Code simplification. * sg/completion-remote: completion: simplify __git_remotes() completion: add a test for __git_remotes() helper function
2015-03-23Merge branch 'jc/decorate-leaky-separator-color' into maintLibravatar Junio C Hamano1-8/+8
"git log --decorate" did not reset colors correctly around the branch names. * jc/decorate-leaky-separator-color: log --decorate: do not leak "commit" color into the next item Documentation/config.txt: simplify boolean description in the syntax section Documentation/config.txt: describe 'color' value type in the "Values" section Documentation/config.txt: have a separate "Values" section Documentation/config.txt: describe the structure first and then meaning Documentation/config.txt: explain multi-valued variables once Documentation/config.txt: avoid unnecessary negation
2015-03-23Merge branch 'kn/git-cd-to-empty' into maintLibravatar Junio C Hamano1-0/+10
"git -C '' subcmd" refused to work in the current directory, unlike "cd ''" which silently behaves as a no-op. * kn/git-cd-to-empty: git: treat "git -C '<path>'" as a no-op when <path> is empty
2015-03-23Merge branch 'mg/verify-commit' into maintLibravatar Junio C Hamano1-2/+2
Workarounds for certain build of GPG that triggered false breakage in a test. * mg/verify-commit: t7510: do not fail when gpg warns about insecure memory
2015-03-23Merge branch 'es/rebase-i-count-todo' into maintLibravatar Junio C Hamano1-0/+9
"git rebase -i" recently started to include the number of commits in the insn sheet to be processed, but on a platform that prepends leading whitespaces to "wc -l" output, the numbers are shown with extra whitespaces that aren't necessary. * es/rebase-i-count-todo: rebase-interactive: re-word "item count" comment rebase-interactive: suppress whitespace preceding item count
2015-03-23Merge branch 'tb/connect-ipv6-parse-fix' into maintLibravatar Junio C Hamano2-36/+74
We did not parse username followed by literal IPv6 address in SSH transport URLs, e.g. ssh://user@[2001:db8::1]:22/repo.git correctly. * tb/connect-ipv6-parse-fix: t5500: show user name and host in diag-url t5601: add more test cases for IPV6 connect.c: allow ssh://user@[2001:db8::1]/repo.git
2015-03-20refs.c: drop curate_packed_refsLibravatar Jeff King1-1/+1
When we delete a ref, we have to rewrite the entire packed-refs file. We take this opportunity to "curate" the packed-refs file and drop any entries that are crufty or broken. Dropping broken entries (e.g., with bogus names, or ones that point to missing objects) is actively a bad idea, as it means that we lose any notion that the data was there in the first place. Aside from the general hackiness that we might lose any information about ref "foo" while deleting an unrelated ref "bar", this may seriously hamper any attempts by the user at recovering from the corruption in "foo". They will lose the sha1 and name of "foo"; the exact pointer may still be useful even if they recover missing objects from a different copy of the repository. But worse, once the ref is gone, there is no trace of the corruption. A follow-up "git prune" may delete objects, even though it would otherwise bail when seeing corruption. We could just drop the "broken" bits from curate_packed_refs, and continue to drop the "crufty" bits: refs whose loose counterpart exists in the filesystem. This is not wrong to do, and it does have the advantage that we may write out a slightly smaller packed-refs file. But it has two disadvantages: 1. It is a potential source of races or mistakes with respect to these refs that are otherwise unrelated to the operation. To my knowledge, there aren't any active problems in this area, but it seems like an unnecessary risk. 2. We have to spend time looking up the matching loose refs for every item in the packed-refs file. If you have a large number of packed refs that do not change, that outweighs the benefit from writing out a smaller packed-refs file (it doesn't get smaller, and you do a bunch of directory traversal to find that out). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20repack: turn on "ref paranoia" when doing a destructive repackLibravatar Jeff King1-1/+1
If we are repacking with "-ad", we will drop any unreachable objects. Likewise, using "-Ad --unpack-unreachable=<time>" will drop any old, unreachable objects. In these cases, we want to make sure the reachability we compute with "--all" is complete. We can do this by passing GIT_REF_PARANOIA=1 in the environment to pack-objects. Note that "-Ad" is safe already, because it only loosens unreachable objects. It is up to "git prune" to avoid deleting them. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20prune: turn on ref_paranoia flagLibravatar Jeff King1-2/+2
Prune should know about broken objects at the tips of refs, so that we can feed them to our traversal rather than ignoring them. It's better for us to abort the operation on the broken object than it is to start deleting objects with an incomplete view of the reachability namespace. Note that for missing objects, aborting is the best we can do. For a badly-named ref, we technically could use its sha1 as a reachability tip. However, the iteration code just feeds us a null sha1, so there would be a reasonable amount of code involved to pass down our wishes. It's not really worth trying to do better, because this is a case that should happen extremely rarely, and the message we provide: fatal: unable to parse object: refs/heads/bogus:name is probably enough to point the user in the right direction. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t5312: test object deletion code paths in a corrupted repositoryLibravatar Jeff King1-0/+114
When we are doing a destructive operation like "git prune", we want to be extra careful that the set of reachable tips we compute is valid. If there is any corruption or oddity, we are better off aborting the operation and letting the user figure things out rather than plowing ahead and possibly deleting some data that cannot be recovered. The tests here include: 1. Pruning objects mentioned only be refs with invalid names. This used to abort prior to d0f810f (refs.c: allow listing and deleting badly named refs, 2014-09-03), but since then we silently ignore the tip. Likewise, we test repacking that can drop objects (either "-ad", which drops anything unreachable, or "-Ad --unpack-unreachable=<time>", which tries to optimize out a loose object write that would be directly pruned). 2. Pruning objects when some refs point to missing objects. We don't know whether any dangling objects would have been reachable from the missing objects. We are better to keep them around, as they are better than nothing for helping the user recover history. 3. Packed refs that point to missing objects can sometimes be dropped. By itself, this is more of an annoyance (you do not have the object anyway; even if you can recover it from elsewhere, all you are losing is a placeholder for your state at the time of corruption). But coupled with (2), if we drop the ref and then go on to prune, we may lose unrecoverable objects. Note that we use test_might_fail for some of the operations. In some cases, it would be appropriate to abort the operation, and in others, it might be acceptable to continue but taking the information into account. The tests don't care either way, and check only for data loss. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t1700: make test pass with index-v4Libravatar Thomas Gummerer1-3/+12
The different index versions have different sha-1 checksums. Those checksums are checked in t1700, which makes it fail when the test suite is run with TEST_GIT_INDEX_VERSION=4. Fix it. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-19filter_ref: make a copy of extra "sought" entriesLibravatar Jeff King1-3/+10
If the server supports allow_tip_sha1_in_want, we add any unmatched raw-sha1 entries in our "sought" list of refs to the list of refs we will ask the other side for. We do so by inserting the original "struct ref" directly into our list, rather than making a copy. This has several problems. The most minor problem is that one cannot ever free the resulting list; it contains structs that are copies of the remote refs (made earlier by fetch_pack) along with sought refs that are referenced elsewhere. But more importantly that we set the ref->next pointer to NULL, chopping off the remainder of any existing list that the ref was a part of. We get the set of "sought" refs in an array rather than a linked list, but that array is often in turn generated from a list. The test modification in t5516 demonstrates this. Rather than fetching just an exact sha1, we fetch that sha1 plus another ref: - we build a linked list of refs to fetch when do_fetch calls get_ref_map; the exact sha1 is first, followed by the named ref ("refs/heads/extra" in this case). - we pass that linked list to transport_fetch_ref, which squashes it into an array of pointers - that array goes to fetch_pack, which calls filter_ref. There we generate the want list from a mix of what the remote side has advertised, and the "sought" entry for the exact sha1. We set the sought entry's "next" pointer to NULL. - after we return from transport_fetch_refs, we then try to update the refs by following the linked list. But our list is now truncated, and we do not update refs/heads/extra at all. We can fix this by making a copy of the ref. There's nothing that fetch_pack does to it that must be reflected in the original "sought" list (and indeed, if that were the case we would have a serious bug, because it is only exact-sha1 entries which are treated this way). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-15git prompt: use toplevel to find untracked filesLibravatar Cody A Taylor1-0/+11
The __git_ps1() prompt function would not show an untracked state when all the untracked files are outside the current working directory. Signed-off-by: Cody A Taylor <codemister99@yahoo.com> Helped-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-13Merge branch 'ak/t5516-typofix' into maintLibravatar Junio C Hamano1-1/+1
* ak/t5516-typofix: t5516: correct misspelled pushInsteadOf
2015-03-13Merge branch 'jc/diff-test-updates' into maintLibravatar Junio C Hamano11-175/+550
Test clean-up. * jc/diff-test-updates: test_ln_s_add: refresh stat info of fake symbolic links t4008: modernise style t/diff-lib: check exact object names in compare_diff_raw tests: do not borrow from COPYING and README from the real source t4010: correct expected object names t9300: correct expected object names t4008: correct stale comments
2015-03-13Merge branch 'jk/diffcore-rename-duplicate' into maintLibravatar Junio C Hamano1-0/+79
A corrupt input to "git diff -M" can cause us to segfault. * jk/diffcore-rename-duplicate: diffcore-rename: avoid processing duplicate destinations diffcore-rename: split locate_rename_dst into two functions
2015-03-13Merge branch 'mk/diff-shortstat-dirstat-fix' into maintLibravatar Junio C Hamano1-0/+14
"git diff --shortstat --dirstat=changes" showed a dirstat based on lines that was never asked by the end user in addition to the dirstat that the user asked for. * mk/diff-shortstat-dirstat-fix: diff --shortstat --dirstat: remove duplicate output
2015-03-13Merge branch 'jc/apply-beyond-symlink' into maintLibravatar Junio C Hamano2-0/+247
"git apply" was not very careful about reading from, removing, updating and creating paths outside the working tree (under --index/--cached) or the current directory (when used as a replacement for GNU patch). * jc/apply-beyond-symlink: apply: do not touch a file beyond a symbolic link apply: do not read from beyond a symbolic link apply: do not read from the filesystem under --index apply: reject input that touches outside the working area
2015-03-13Merge branch 'jk/daemon-interpolate' into maintLibravatar Junio C Hamano1-0/+27
The "interpolated-path" option of "git daemon" inserted any string client declared on the "host=" capability request without checking. Sanitize and limit %H and %CH to a saner and a valid DNS name. * jk/daemon-interpolate: daemon: sanitize incoming virtual hostname t5570: test git-daemon's --interpolated-path option git_connect: let user override virtual-host we send to daemon
2015-03-12upload-pack: fix transfer.hiderefs over smart-httpLibravatar Jeff King1-0/+11
When upload-pack advertises the refs (either for a normal, non-stateless request, or for the initial contact in a stateless one), we call for_each_ref with the send_ref function as its callback. send_ref, in turn, calls mark_our_ref, which checks whether the ref is hidden, and sets OUR_REF or HIDDEN_REF on the object as appropriate. If it is hidden, mark_our_ref also returns "1" to signal send_ref that the ref should not be advertised. If we are not advertising refs, (i.e., the follow-up invocation by an http client to send its "want" lines), we use mark_our_ref directly as a callback to for_each_ref. Its marking does the right thing, but when it then returns "1" to for_each_ref, the latter interprets this as an error and stops iterating. As a result, we skip marking all of the refs that come lexicographically after it. Any "want" lines from the client asking for those objects will fail, as they were not properly marked with OUR_REF. To solve this, we introduce a wrapper callback around mark_our_ref which always returns 0 (even if the ref is hidden, we want to keep iterating). We also tweak the signature of mark_our_ref to exclude unnecessary parameters that were present only to conform to the callback interface. This should make it less likely for somebody to accidentally use it as a callback in the future. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-10t7510: do not fail when gpg warns about insecure memoryLibravatar Kyle J. McKay1-2/+2
Depending on how gpg was built, it may issue the following message to stderr when run: Warning: using insecure memory! When the test is collecting gpg output it is therefore not enough to just match on a "gpg: " prefix it must also match on a "Warning: " prefix wherever it needs to match lines that have been produced by gpg. Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Acked-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-06git: treat "git -C '<path>'" as a no-op when <path> is emptyLibravatar Karthik Nayak1-0/+10
'git -C ""' unhelpfully dies with error "Cannot change to ''", whereas the shell treats `cd ""' as a no-op. Taking the shell's behavior as a precedent, teach git to treat `-C ""' as a no-op, as well. Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-06Merge branch 'km/send-email-getopt-long-workarounds' into maintLibravatar Junio C Hamano1-5/+5
Even though we officially haven't dropped Perl 5.8 support, the Getopt::Long package that came with it does not support "--no-" prefix to negate a boolean option; manually add support to help people with older Getopt::Long package. * km/send-email-getopt-long-workarounds: git-send-email.perl: support no- prefix with older GetOptions
2015-03-06completion: add a test for __git_remotes() helper functionLibravatar SZEDER Gábor1-0/+19
The test checks that both remotes under '$GIT_DIR/remotes' and remotes in the config file are listed. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-06rebase-interactive: suppress whitespace preceding item countLibravatar Eric Sunshine1-0/+9
97f05f43 (Show number of TODO items for interactive rebase, 2014-12-10) taught rebase-interactive to compute an item count with 'wc -l' and display it in the instruction list comments: # Rebase 46640c6..5568fd5 onto 46640c6 (4 TODO item(s)) On Mac OS X, however, it renders as: # Rebase 46640c6..5568fd5 onto 46640c6 ( 4 TODO item(s)) since 'wc -l' indents its output with leading spaces. Fix this. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-05Merge branch 'ab/merge-file-prefix' into maintLibravatar Junio C Hamano1-1/+2
"git merge-file" did not work correctly in a subdirectory. * ab/merge-file-prefix: merge-file: correctly open files when in a subdir
2015-03-05Merge branch 'ps/submodule-sanitize-path-upon-add' into maintLibravatar Junio C Hamano1-0/+17
"git submodule add" failed to squash "path/to/././submodule" to "path/to/submodule". * ps/submodule-sanitize-path-upon-add: git-submodule.sh: fix '/././' path normalization
2015-03-05Merge branch 'jk/prune-mtime' into maintLibravatar Junio C Hamano1-0/+8
In v2.2.0, we broke "git prune" that runs in a repository that borrows from an alternate object store. * jk/prune-mtime: sha1_file: fix iterating loose alternate objects for_each_loose_file_in_objdir: take an optional strbuf path
2015-03-05Merge branch 'ch/new-gpg-drops-rfc-1991' into maintLibravatar Junio C Hamano2-0/+58
Older GnuPG implementations may not correctly import the keyring material we prepare for the tests to use. * ch/new-gpg-drops-rfc-1991: t/lib-gpg: sanity-check that we can actually sign t/lib-gpg: include separate public keys in keyring.gpg
2015-03-05Merge branch 'jk/config-no-ungetc-eof' into maintLibravatar Junio C Hamano1-0/+9
Reading configuration from a blob object, when it ends with a lone CR, use to confuse the configuration parser. * jk/config-no-ungetc-eof: config_buf_ungetc: warn when pushing back a random character config: do not ungetc EOF
2015-03-05Merge branch 'mh/deref-symref-over-helper-transport' into maintLibravatar Junio C Hamano1-0/+24
"git fetch" over a remote-helper that cannot respond to "list" command could not fetch from a symbolic reference e.g. HEAD. * mh/deref-symref-over-helper-transport: transport-helper: do not request symbolic refs to remote helpers
2015-03-05Merge branch 'ks/rebase-i-abbrev' into maintLibravatar Junio C Hamano1-0/+7
The insn sheet "git rebase -i" creates did not fully honor core.abbrev settings. * ks/rebase-i-abbrev: rebase -i: use full object name internally throughout the script
2015-03-05Merge branch 'jk/sanity' into maintLibravatar Junio C Hamano4-9/+42
The tests that wanted to see that file becomes unreadable after running "chmod a-r file", and the tests that wanted to make sure it is not run as root, we used "can we write into the / directory?" as a cheap substitute, but on some platforms that is not a good heuristics. The tests and their prerequisites have been updated to check what they really require. * jk/sanity: test-lib.sh: set prerequisite SANITY by testing what we really need tests: correct misuses of POSIXPERM t/lib-httpd: switch SANITY check for NOT_ROOT
2015-03-04log --decorate: do not leak "commit" color into the next itemLibravatar Junio C Hamano1-8/+8
In "git log --decorate", you would see the commit header like this: commit ... (HEAD, jc/decorate-leaky-separator-color) where "commit ... (" is painted in color.diff.commit, "HEAD" in color.decorate.head, ", " in color.diff.commit, the branch name in color.decorate.branch and then closing ")" in color.diff.commit. If you wanted to paint the HEAD and local branch name in the same color as the body text (perhaps because cyan and green are too faint on a black-on-white terminal to be readable), you would not want to have to say [color "decorate"] head = black branch = black because that you would not be able to reuse same configuration on a white-on-black terminal. You would naively expect [color "decorate"] head = normal branch = normal to work, but unfortunately it does not. It paints the string "HEAD" and the branch name in the same color as the opening parenthesis or comma between the decoration elements. This is because the code forgets to reset the color after printing the "prefix" in its own color. It theoretically is possible that some people were expecting and relying on that the attribute set as the "diff.commit" color, which is used to draw these opening parenthesis and inter-item comma, is inherited by the drawing of branch names, but it is not how the coloring works everywhere else. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-03t5516: correct misspelled pushInsteadOfLibravatar Anders Kaseorg1-1/+1
A future breakage to "git push" to make it incorrectly pay attention to pushInsteadOf when it should not will be left uncaught without this change. Signed-off-by: Anders Kaseorg <andersk@mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-02diff --shortstat --dirstat: remove duplicate outputLibravatar Mårten Kongstad1-0/+14
When --shortstat is used in conjunction with --dirstat=changes, git diff will output the dirstat information twice: first as calculated by the 'lines' algorithm, then as calculated by the 'changes' algorithm: $ git diff --dirstat=changes,10 --shortstat v2.2.0..v2.2.1 23 files changed, 453 insertions(+), 54 deletions(-) 33.5% Documentation/RelNotes/ 26.2% t/ 46.6% Documentation/RelNotes/ 16.6% t/ The same duplication happens for --shortstat together with --dirstat=files, but not for --shortstat together with --dirstat=lines. Limit output to only include one dirstat part, calculated as specified by the --dirstat parameter. Also, add test for this. Signed-off-by: Mårten Kongstad <marten.kongstad@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-27diffcore-rename: avoid processing duplicate destinationsLibravatar Jeff King1-0/+79
The rename code cannot handle an input where we have duplicate destinations (i.e., more than one diff_filepair in the queue with the same string in its pair->two->path). We end up allocating only one slot in the rename_dst mapping. If we fill in the diff_filepair for that slot, when we re-queue the results, we may queue that filepair multiple times. When the diff is finally flushed, the filepair is processed and free()d multiple times, leading to heap corruption. This situation should only happen when a tree diff sees duplicates in one of the trees (see the added test for a detailed example). Rather than handle it, the sanest thing is just to turn off rename detection altogether for the diff. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-24Merge branch 'jc/apply-ws-fix-expands' into maintLibravatar Junio C Hamano1-0/+121
"git apply --whitespace=fix" used to under-allocate the memory when the fix resulted in a longer text than the original patch. * jc/apply-ws-fix-expands: apply: count the size of postimage correctly apply: make update_pre_post_images() sanity check the given postlen apply.c: typofix
2015-02-24Merge branch 'jk/dumb-http-idx-fetch-fix' into maintLibravatar Junio C Hamano1-0/+18
A broken pack .idx file in the receiving repository prevented the dumb http transport from fetching a good copy of it from the other side. * jk/dumb-http-idx-fetch-fix: dumb-http: do not pass NULL path to parse_pack_index
2015-02-24Merge branch 'dk/format-patch-ignore-diff-submodule' into maintLibravatar Junio C Hamano1-0/+72
Setting diff.submodule to 'log' made "git format-patch" produce broken patches. * dk/format-patch-ignore-diff-submodule: format-patch: ignore diff.submodule setting t4255: test am submodule with diff.submodule
2015-02-23test_ln_s_add: refresh stat info of fake symbolic linksLibravatar Johannes Sixt1-1/+3
We have a helper function test_ln_s_add that inserts a symbolic link into the index even if the file system does not support symbolic links. There is a small flaw in the emulation path: the added entry does not pick up stat information of the fake symbolic link from the file system, as a consequence, the index is not exactly the same as for the "regular" path (where symbolic links are available). To fix this, just call git update-index again. This flaw was revealed by the earlier change that tightened compare_diff_raw(), because a test case in t4008 depends on the correctly updated index. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-22t5500: show user name and host in diag-urlLibravatar Torsten Bögershausen1-18/+33
The URL for ssh may have include a username before the hostname, like ssh://user@host/repo. When literal IPV6 addresses are used together with a username, the substring "user@[::1]" must be converted into "user@::1". Make that conversion visible for the user, and write userandhost in the diagnostics Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-22t5601: add more test cases for IPV6Libravatar Torsten Bögershausen1-17/+40
Test the parsing of literall IPV6 addresses more systematically: - with and without brackets (e.g. ::1 [::1]) - with brackets and port number: (e.g. [::1]:22) - with username (e.g. user@::1) - with username and brackets: Because user@[::1] was not supported on older Git version, [user@::1] had to be used as a workaround. Test that user@::1 user@[::1] and [user@::1] all do the same. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-22connect.c: allow ssh://user@[2001:db8::1]/repo.gitLibravatar Torsten Bögershausen1-1/+1
The ssh:// syntax was added in 2386d658 (Add first cut at "git protocol" connect logic., 2005-07-13), it accepted ssh://user@2001:db8::1/repo.git, which is now legacy. Over the years the parser was improved to support [] and port numbers, but the combination of ssh://user@[2001:db8::1]:222/repo.git did never work. The only only way to use a user name, a literall IPV6 address and a port number was ssh://[user@2001:db8::1]:222/repo.git (Thanks to Christian Taube <lists@hcf.yourweb.de> for reporting this long standing issue) New users would use ssh://user@[2001:db8::1]:222/repo.git, so change the parser to handle it correctly. Support the old legacy URLs as well, to be backwards compatible, and avoid regressions for users which upgrade an existing installation to a later Git version. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-17daemon: sanitize incoming virtual hostnameLibravatar Jeff King1-0/+11
We use the daemon_avoid_alias function to make sure that the pathname the user gives us is sane. However, after applying that check, we might then interpolate the path using a string given by the server admin, but which may contain more untrusted data from the client. We should be sure to sanitize this data, as well. We cannot use daemon_avoid_alias here, as it is more strict than we need in requiring a leading '/'. At the same time, we can be much more strict here. We are interpreting a hostname, which should not contain slashes or excessive runs of dots, as those things are not allowed in DNS names. Note that in addition to cleansing the hostname field, we must check the "canonical hostname" (%CH) as well as the port (%P), which we take as a raw string. For the canonical hostname, this comes from an actual DNS lookup on the accessed IP, which makes it a much less likely vector for problems. But it does not hurt to sanitize it in the same way. Unfortunately we cannot test this case easily, as it would involve a custom hostname lookup. We do not need to check %IP, as it comes straight from inet_ntop, so must have a sane form. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>