summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2014-02-25request-pull: test updatesLibravatar Junio C Hamano1-8/+8
This illustrates behaviour changes that result from the recent change by Linus. Most show good changes, but there may be some usability regressions: - The command continues to fail when the user forgot to push out before running the command, but the wording of the message has been slightly changed. - The command no longer guesses when asked to request the commit at the HEAD be pulled after pushing it to a branch 'for-upstream', even when that branch points at the correct commit. The user must ask the command with the new "master:for-upstream" syntax. The new behaviour needs to be documented in any case, but we need to agree what the new behaviour should be before doing so first. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-17Merge branch 'nd/shallow-clone'Libravatar Junio C Hamano4-0/+404
Fetching from a shallow-cloned repository used to be forbidden, primarily because the codepaths involved were not carefully vetted and we did not bother supporting such usage. This attempts to allow object transfer out of a shallow-cloned repository in a controlled way (i.e. the receiver become a shallow repository with truncated history). * nd/shallow-clone: (31 commits) t5537: fix incorrect expectation in test case 10 shallow: remove unused code send-pack.c: mark a file-local function static git-clone.txt: remove shallow clone limitations prune: clean .git/shallow after pruning objects clone: use git protocol for cloning shallow repo locally send-pack: support pushing from a shallow clone via http receive-pack: support pushing to a shallow clone via http smart-http: support shallow fetch/clone remote-curl: pass ref SHA-1 to fetch-pack as well send-pack: support pushing to a shallow clone receive-pack: allow pushes that update .git/shallow connected.c: add new variant that runs with --shallow-file add GIT_SHALLOW_FILE to propagate --shallow-file to subprocesses receive/send-pack: support pushing from a shallow clone receive-pack: reorder some code in unpack() fetch: add --update-shallow to accept refs that update .git/shallow upload-pack: make sure deepening preserves shallow roots fetch: support fetching from a shallow repository clone: support remote shallow repository ...
2014-01-13Merge branch 'jk/t5531-prepare-to-default-to-non-matching'Libravatar Junio C Hamano1-0/+1
* jk/t5531-prepare-to-default-to-non-matching: t5531: further "matching" fixups
2014-01-13Merge branch 'sb/diff-orderfile-config'Libravatar Junio C Hamano1-4/+0
Finishing touches to avoid casting unnecessary detail in stone. * sb/diff-orderfile-config: diff test: reading a directory as a file need not error out
2014-01-13Merge branch 'jl/submodule-mv-checkout-caveat'Libravatar Junio C Hamano2-0/+37
With a submodule that was initialized in an old fashioned way without gitlinks, switching branches in the superproject between the one with and without the submodule may leave the submodule working tree with its embedded repository behind, as there may be unexpendable state there. Document and warn users about this. * jl/submodule-mv-checkout-caveat: rm: better document side effects when removing a submodule mv: better document side effects when moving a submodule
2014-01-13Merge branch 'jk/pull-rebase-using-fork-point'Libravatar Junio C Hamano1-2/+10
Finishing touches. * jk/pull-rebase-using-fork-point: rebase: fix fork-point with zero arguments
2014-01-13Merge branch 'ow/stash-with-ifs'Libravatar Junio C Hamano1-0/+12
The implementation of 'git stash $cmd "stash@{...}"' did not quote the stash argument properly and left it split at IFS whitespace. * ow/stash-with-ifs: stash: handle specifying stashes with $IFS
2014-01-13Merge branch 'jn/pager-lv-default-env'Libravatar Junio C Hamano1-0/+12
Just like we give a reasonable default for "less" via the LESS environment variable, specify a reasonable default for "lv" via the "LV" environment variable when spawning the pager. * jn/pager-lv-default-env: pager: set LV=-c alongside LESS=FRSX
2014-01-13t5531: further "matching" fixupsLibravatar Jeff King1-0/+1
Commit 43eb920 switched one of the sub-repository in this test to matching to prepare for a world where the default becomes "simple". However, the main repository needs a similar change. We did not notice any test failure when merged with b2ed944 (push: switch default from "matching" to "simple", 2013-01-04) because t5531.6 is trying to provoke a failure of "git push" due to a submodule check. When combined with b2ed944 the push still fails, but for the wrong reason (because our upstream setup does not exist, not because of the submodule). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-10diff test: reading a directory as a file need not error outLibravatar Jonathan Nieder1-4/+0
There is no guarantee that strbuf_read_file must error out for directories. On some operating systems (e.g., Debian GNU/kFreeBSD wheezy), reading a directory gives its raw content: $ head -c5 < / | cat -A ^AM-|^_^@^L$ As a result, 'git diff -O/' succeeds instead of erroring out on these systems, causing t4056.5 "orderfile is a directory" to fail. On some weird OS it might even make sense to pass a directory to the -O option and this is not a common user mistake that needs catching. Remove the test. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-10Merge branch 'js/lift-parent-count-limit'Libravatar Junio C Hamano2-1/+36
There is no reason to have a hardcoded upper limit of the number of parents for an octopus merge, created via the graft mechanism. * js/lift-parent-count-limit: Remove the line length limit for graft files
2014-01-10Merge branch 'jk/test-framework-updates'Libravatar Junio C Hamano2-14/+7
The basic test used to leave unnecessary trash directories in the t/ directory. * jk/test-framework-updates: t0000: drop "known breakage" test t0000: simplify HARNESS_ACTIVE hack t0000: set TEST_OUTPUT_DIRECTORY for sub-tests
2014-01-10Merge branch 'bm/merge-base-octopus-dedup'Libravatar Junio C Hamano1-0/+39
"git merge-base --octopus" used to leave cleaning up suboptimal result to the caller, but now it does the clean-up itself. * bm/merge-base-octopus-dedup: merge-base --octopus: reduce the result from get_octopus_merge_bases() merge-base: separate "--independent" codepath into its own helper
2014-01-10Merge branch 'jk/http-auth-tests-robustify'Libravatar Junio C Hamano6-17/+26
Using the same username and password during the tests would not catch a potential breakage of sending one when we should be sending the other. * jk/http-auth-tests-robustify: use distinct username/password for http auth tests
2014-01-10Merge branch 'jk/oi-delta-base'Libravatar Junio C Hamano1-0/+34
Teach "cat-file --batch" to show delta-base object name for a packed object that is represented as a delta. * jk/oi-delta-base: cat-file: provide %(deltabase) batch format sha1_object_info_extended: provide delta base sha1s
2014-01-10Merge branch 'nd/add-empty-fix'Libravatar Junio C Hamano1-0/+19
"git add -A" (no other arguments) in a totally empty working tree used to emit an error. * nd/add-empty-fix: add: don't complain when adding empty project root
2014-01-10Merge branch 'tm/fetch-prune'Libravatar Junio C Hamano1-0/+26
Fetching 'frotz' branch with "git fetch", while having 'frotz/nitfol' remote-tracking branch from an earlier fetch, would error out, primarily because the command has not been told to remove anything on our side. In such a case, "git fetch --prune" can be used to remove 'frotz/nitfol' to make room to fetch and store 'frotz' remote-tracking branch. * tm/fetch-prune: fetch --prune: Run prune before fetching fetch --prune: always print header url
2014-01-10Merge branch 'sb/diff-orderfile-config'Libravatar Junio C Hamano1-0/+104
Allow "git diff -O<file>" to be configured with a new configuration variable. * sb/diff-orderfile-config: diff: add diff.orderfile configuration variable diff: let "git diff -O" read orderfile from any file and fail properly t4056: add new tests for "git diff -O"
2014-01-10Merge branch 'bc/log-decoration'Libravatar Junio C Hamano1-0/+15
"git log --decorate" did not handle a tag pointed by another tag nicely. * bc/log-decoration: log: properly handle decorations with chained tags
2014-01-10Merge branch 'cc/replace-object-info'Libravatar Junio C Hamano1-0/+42
read_sha1_file() that is the workhorse to read the contents given an object name honoured object replacements, but there is no corresponding mechanism to sha1_object_info() that is used to obtain the metainfo (e.g. type & size) about the object, leading callers to weird inconsistencies. * cc/replace-object-info: replace info: rename 'full' to 'long' and clarify in-code symbols Documentation/git-replace: describe --format option builtin/replace: unset read_replace_refs t6050: add tests for listing with --format builtin/replace: teach listing using short, medium or full formats sha1_file: perform object replacement in sha1_object_info_extended() t6050: show that git cat-file --batch fails with replace objects sha1_object_info_extended(): add an "unsigned flags" parameter sha1_file.c: add lookup_replace_object_extended() to pass flags replace_object: don't check read_replace_refs twice rename READ_SHA1_FILE_REPLACE flag to LOOKUP_REPLACE_OBJECT
2014-01-10Merge branch 'nd/negative-pathspec'Libravatar Junio C Hamano1-0/+184
Introduce "negative pathspec" magic, to allow "git log -- . ':!dir'" to tell us "I am interested in everything but 'dir' directory". * nd/negative-pathspec: pathspec.c: support adding prefix magic to a pathspec with mnemonic magic Support pathspec magic :(exclude) and its short form :! glossary-content.txt: rephrase magic signature part
2014-01-09rebase: fix fork-point with zero argumentsLibravatar John Keeping1-2/+10
When no arguments are specified, $switch_to is empty so we end up passing the empty string to "git merge-base --fork-point", which causes an error. git-rebase carries on at this point, but in fact we have failed to apply the fork-point operation. It turns out that the test in t3400 that was meant to test this didn't actually need the fork-point behaviour, so enhance it to make sure that the fork-point is applied correctly. The modified test fails without the change to git-rebase.sh in this patch. Reported-by: Andreas Krey <a.krey@gmx.de> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-09t5537: fix incorrect expectation in test case 10Libravatar Nguyễn Thái Ngọc Duy1-1/+2
Commit 48d25ca adds a new commit "7" to the repo that the next test case in commit 1609488 clones from. But the next test case does not expect this commit. For these tests, it's the bottom that's important, not the top. Fix the expected commit list. While at it, fix the default http port number to 5537. Otherwise when t5536 learns to test httpd, running test in parallel may fail. References: 48d25ca fetch: add --update-shallow to accept... - 2013-12-05 1609488 smart-http: support shallow fetch/clone - 2013-12-05 Noticed-by: Jeff King <peff@peff.net> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-07rm: better document side effects when removing a submoduleLibravatar Jens Lehmann1-0/+16
The "Submodules" section of the "git rm" documentation mentions what will happen when a submodule with a gitfile gets removed with newer git. But it doesn't talk about what happens when the user changes between commits before and after the removal, which does not remove the submodule from the work tree like using the rm command did the first time. Explain what happens and what the user has to do manually to fix that in the new BUGS section. Also document this behavior in a new test. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-07mv: better document side effects when moving a submoduleLibravatar Jens Lehmann1-0/+21
The "Submodules" section of the "git mv" documentation mentions what will happen when a submodule with a gitfile gets moved with newer git. But it doesn't talk about what happens when the user changes between commits before and after the move, which does not update the work tree like using the mv command did the first time. Explain what happens and what the user has to do manually to fix that in the new BUGS section. Also document this behavior in a new test. Reported-by: George Papanikolaou <g3orge.app@gmail.com> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-07stash: handle specifying stashes with $IFSLibravatar Øystein Walle1-0/+12
When trying to pop/apply a stash specified with an argument containing IFS whitespace, git-stash will throw an error: $ git stash pop 'stash@{two hours ago}' Too many revisions specified: stash@{two hours ago} This happens because word splitting is used to count non-option arguments. Make use of rev-parse's --sq option to quote the arguments for us to ensure a correct count. Add quotes where necessary. Also add a test that verifies correct behaviour. Helped-by: Thomas Rast <tr@thomasrast.ch> Signed-off-by: Øystein Walle <oystwa@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-07pager: set LV=-c alongside LESS=FRSXLibravatar Jonathan Nieder1-0/+12
On systems with lv configured as the preferred pager (i.e., DEFAULT_PAGER=lv at build time, or PAGER=lv exported in the environment) git commands that use color show control codes instead of color in the pager: $ git diff ^[[1mdiff --git a/.mailfilter b/.mailfilter^[[m ^[[1mindex aa4f0b2..17e113e 100644^[[m ^[[1m--- a/.mailfilter^[[m ^[[1m+++ b/.mailfilter^[[m ^[[36m@@ -1,11 +1,58 @@^[[m "less" avoids this problem because git uses the LESS environment variable to pass the -R option ('output ANSI color escapes in raw form') by default. Use the LV environment variable to pass 'lv' the -c option ('allow ANSI escape sequences for text decoration / color') to fix it for lv, too. Noticed when the default value for color.ui flipped to 'auto' in v1.8.4-rc0~36^2~1 (2013-06-10). Reported-by: Olaf Meeuwissen <olaf.meeuwissen@avasys.jp> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-03fetch --prune: Run prune before fetchingLibravatar Tom Miller1-0/+14
When we have a remote-tracking branch named "frotz/nitfol" from a previous fetch, and the upstream now has a branch named "frotz", fetch would fail to remove "frotz/nitfol" with a "git fetch --prune" from the upstream. git would inform the user to use "git remote prune" to fix the problem. Change the way "fetch --prune" works by moving the pruning operation before the fetching operation. This way, instead of warning the user of a conflict, it autmatically fixes it. Signed-off-by: Tom Miller <jackerran@gmail.com> Tested-by: Thomas Rast <tr@thomasrast.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-03fetch --prune: always print header urlLibravatar Tom Miller1-0/+12
If "fetch --prune" is run with no new refs to fetch, but it has refs to prune. Then, the header url is not printed as it would if there were new refs to fetch. Output before this patch: $ git fetch --prune remote-with-no-new-refs x [deleted] (none) -> origin/world Output after this patch: $ git fetch --prune remote-with-no-new-refs From https://github.com/git/git x [deleted] (none) -> origin/test Signed-off-by: Tom Miller <jackerran@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-02t0000: drop "known breakage" testLibravatar Jeff King1-3/+0
Having a simulated "known breakage" test means that the test suite will always tell us there is a bug to be fixed, even though it is only simulated. The right way to test this is in a sub-test, that can also check that we provide the correct exit status and output. Fortunately, we already have such a test (added much later by 5ebf89e). We could arguably get rid of the simulated success test immediately above, as well, as it is also redundant with the tests added in 5ebf89e. However, it does not have the annoying behavior of the "known breakage" test. It may also be easier to debug if the test suite is truly broken, since it is not a test-within-a-test, as the later tests are. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-02t0000: simplify HARNESS_ACTIVE hackLibravatar Jeff King2-11/+5
Commit 517cd55 set HARNESS_ACTIVE unconditionally in sub-tests, because that value affects the output of "--verbose". t0000 needs stable output from its sub-tests, and we may or may not be running under a TAP harness. That commit made the decision to always set the variable, since it has another useful side effect, which is suppressing writes to t/test-results by the sub-tests (which would just pollute the real results). Since the last commit, though, the sub-tests have their own test-results directories, so this is no longer an issue. We can now update a few comments that are no longer accurate nor necessary. We can also revisit the choice of HARNESS_ACTIVE. Since we must choose one value for stability, it's probably saner to have it off. This means that future patches could test things like the test-results writing, or the "--quiet" option, which is currently ignored when run under a harness. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-02t0000: set TEST_OUTPUT_DIRECTORY for sub-testsLibravatar Jeff King1-0/+2
Running t0000 produces more trash directories than expected and does not clean up after itself: $ ./t0000-basic.sh [...] $ ls -d trash\ directory.* trash directory.failing-cleanup trash directory.mixed-results1 trash directory.mixed-results2 trash directory.partial-pass trash directory.test-verbose trash directory.test-verbose-only-2 These scratch areas for sub-tests should be under the t0000 trash directory, but because TEST_OUTPUT_DIRECTORY defaults to TEST_DIRECTORY, which is exported to help sub-tests find test-lib.sh, the sub-test trash directories are created under the toplevel t/ directory instead. Because some of the sub-tests simulate failures, their trash directories are kept around. Fix it by explicitly setting TEST_OUTPUT_DIRECTORY appropriately for sub-tests. An alternative fix would be to pass the --root parameter that only specifies where to put the trash directories, which would also work. However, using TEST_OUTPUT_DIRECTORY is more futureproof in case tests want to write more output in addition to the test-results/ (which are already suppressed in sub-tests using the HARNESS_ACTIVE setting) and trash directories. This fixes a regression introduced by 38b074d (t/test-lib.sh: fix TRASH_DIRECTORY handling, 2013-04-14). Before that commit, the TEST_OUTPUT_DIRECTORY setting was not respected consistently so most tests did their work in a "trash" subdirectory of the current directory instead of the output dir. Signed-off-by: Jeff King <peff@peff.net> Clarified-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-02use distinct username/password for http auth testsLibravatar Jeff King6-17/+26
The httpd server we set up to test git's http client code knows about a single account, in which both the username and password are "user@host" (the unusual use of the "@" here is to verify that we handle the character correctly when URL escaped). This means that we may miss a certain class of errors in which the username and password are mixed up internally by git. We can make our tests more robust by having distinct values for the username and password. In addition to tweaking the server passwd file and the client URL, we must teach the "askpass" harness to accept multiple values. As a bonus, this makes the setup of some tests more obvious; when we are expecting git to ask only about the password, we can seed the username askpass response with a bogus value. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-30replace info: rename 'full' to 'long' and clarify in-code symbolsLibravatar Christian Couder1-2/+2
Enum names SHORT/MEDIUM/FULL were too broad to be descriptive. And they clashed with built-in symbols on platforms like Windows. Clarify by giving them REPLACE_FORMAT_ prefix. Rename 'full' format in "git replace --format=<name>" to 'long', to match others (i.e. 'short' and 'medium'). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-30merge-base --octopus: reduce the result from get_octopus_merge_bases()Libravatar Junio C Hamano1-0/+39
Scripts that use "merge-base --octopus" could do the reducing themselves, but most of them are expected to want to get the reduced results without having to do any work themselves. Tests are taken from a message by Василий Макаров <einmalfel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> --- We might want to vet the existing callers of the underlying get_octopus_merge_bases() and find out if _all_ of them are doing anything extra (like deduping) because the machinery can return duplicate results. And if that is the case, then we may want to move the dedupling down the callchain instead of having it here.
2013-12-27Remove the line length limit for graft filesLibravatar Johannes Schindelin2-1/+36
Support for grafts predates Git's strbuf, and hence it is understandable that there was a hard-coded line length limit of 1023 characters (which was chosen a bit awkwardly, given that it is *exactly* one byte short of aligning with the 41 bytes occupied by a commit name and the following space or new-line character). While regular commit histories hardly win comprehensibility in general if they merge more than twenty-two branches in one go, it is not Git's business to limit grafts in such a way. In this particular developer's case, the use case that requires substantially longer graft lines to be supported is the visualization of the commits' order implied by their changes: commits are considered to have an implicit relationship iff exchanging them in an interactive rebase would result in merge conflicts. Thusly implied branches tend to be very shallow in general, and the resulting thicket of implied branches is usually very wide; It is actually quite common that *most* of the commits in a topic branch have not even one implied parent, so that a final merge commit has about as many implied parents as there are commits in said branch. [jc: squashed in tests by Jonathan] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-27Merge branch 'jk/name-pack-after-byte-representation'Libravatar Junio C Hamano1-2/+2
Two packfiles that contain the same set of objects have traditionally been named identically, but that made repacking a repository that is already fully packed without any cruft with a different packing parameter cumbersome. Update the convention to name the packfile after the bytestream representation of the data, not after the set of objects in it. * jk/name-pack-after-byte-representation: pack-objects doc: treat output filename as opaque pack-objects: name pack files after trailer hash sha1write: make buffer const-correct
2013-12-27Merge branch 'tg/diff-no-index-refactor'Libravatar Junio C Hamano2-0/+48
"git diff ../else/where/A ../else/where/B" when ../else/where is clearly outside the repository, and "git diff --no-index A B", do not have to look at the index at all, but we used to read the index unconditionally. * tg/diff-no-index-refactor: diff: avoid some nesting diff: add test for --no-index executed outside repo diff: don't read index when --no-index is given diff: move no-index detection to builtin/diff.c
2013-12-27Merge branch 'zk/difftool-counts'Libravatar Junio C Hamano1-0/+13
Show the total number of paths and the number of paths shown so far when "git difftool" prompts to launch an external diff tool, which would give users some sense of progress. * zk/difftool-counts: diff.c: fix some recent whitespace style violations difftool: display the number of files in the diff queue in the prompt
2013-12-27Merge branch 'jk/cat-file-regression-fix'Libravatar Junio C Hamano1-0/+22
"git cat-file --batch=", an admittedly useless command, did not behave very well. * jk/cat-file-regression-fix: cat-file: handle --batch format with missing type/size cat-file: pass expand_data to print_object_or_die
2013-12-27Merge branch 'jk/pull-rebase-using-fork-point'Libravatar Junio C Hamano1-2/+4
* jk/pull-rebase-using-fork-point: rebase: use reflog to find common base with upstream pull: use merge-base --fork-point when appropriate
2013-12-27Merge branch 'jk/rev-parse-double-dashes'Libravatar Junio C Hamano1-0/+24
"git rev-parse <revs> -- <paths>" did not implement the usual disambiguation rules the commands in the "git log" family used in the same way. * jk/rev-parse-double-dashes: rev-parse: be more careful with munging arguments rev-parse: correctly diagnose revision errors before "--"
2013-12-27Merge branch 'jc/push-refmap'Libravatar Junio C Hamano1-0/+75
Make "git push origin master" update the same ref that would be updated by our 'master' when "git push origin" (no refspecs) is run while the 'master' branch is checked out, which makes "git push" more symmetric to "git fetch" and more usable for the triangular workflow. * jc/push-refmap: push: also use "upstream" mapping when pushing a single ref push: use remote.$name.push as a refmap builtin/push.c: use strbuf instead of manual allocation
2013-12-26cat-file: provide %(deltabase) batch formatLibravatar Jeff King1-0/+34
It can be useful for debugging or analysis to see which objects are stored as delta bases on top of others. This information is available by running `git verify-pack`, but that is extremely expensive (and is harder than necessary to parse). Instead, let's make it available as a cat-file query format, which makes it fast and simple to get the bases for a subset of the objects. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-26add: don't complain when adding empty project rootLibravatar Nguyễn Thái Ngọc Duy1-0/+19
This behavior was added in 07d7bed (add: don't complain when adding empty project root - 2009-04-28) then broken by 84b8b5d (remove match_pathspec() in favor of match_pathspec_depth() - 2013-07-14). Reinstate it. Noticed-by: Thomas Ferris Nicolaisen <tfnico@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-20log: properly handle decorations with chained tagsLibravatar brian m. carlson1-0/+15
git log did not correctly handle decorations when a tag object referenced another tag object that was no longer a ref, such as when the second tag was deleted. The commit would not be decorated correctly because parse_object had not been called on the second tag and therefore its tagged field had not been filled in, resulting in none of the tags being associated with the relevant commit. Call parse_object to fill in this field if it is absent so that the chain of tags can be dereferenced and the commit can be properly decorated. Include tests as well to prevent future regressions. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-18diff: add diff.orderfile configuration variableLibravatar Samuel Bronson1-0/+10
diff.orderfile acts as a default for the -O command line option. [sb: split up aw's original patch; rework tests and docs, treat option as pathname] Signed-off-by: Anders Waldenborg <anders@0x63.nu> Signed-off-by: Samuel Bronson <naesten@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-18diff: let "git diff -O" read orderfile from any file and fail properlyLibravatar Samuel Bronson1-0/+26
The -O flag really shouldn't silently fail to do anything when given a path that it can't read from. However, it should be able to read from un-mmappable files, such as: * pipes/fifos * /dev/null: It's a character device (at least on Linux) * ANY empty file: Quoting Linux mmap(2), "SUSv3 specifies that mmap() should fail if length is 0. However, in kernels before 2.6.12, mmap() succeeded in this case: no mapping was created and the call returned addr. Since kernel 2.6.12, mmap() fails with the error EINVAL for this case." We especially want "-O/dev/null" to work, since we will be documenting it as the way to cancel "diff.orderfile" when we add that. (Note: "-O/dev/null" did have the right effect, since the existing error handling essentially worked out to "silently ignore the orderfile". But this was probably more coincidence than anything else.) So, lets toss all of that logic to get the file mmapped and just use strbuf_read_file() instead, which gives us decent error handling practically for free. Signed-off-by: Samuel Bronson <naesten@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-18t4056: add new tests for "git diff -O"Libravatar Samuel Bronson1-0/+68
Adapted from $gmane/236427 by Anders Waldenborg, "diff: Add diff.orderfile configuration variable". Signed-off-by: Anders Waldenborg <anders@0x63.nu> Signed-off-by: Samuel Bronson <naesten@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-17Merge branch 'tb/clone-ssh-with-colon-for-port'Libravatar Junio C Hamano2-21/+198
Be more careful when parsing remote repository URL given in the scp-style host:path notation. * tb/clone-ssh-with-colon-for-port: git_connect(): use common return point connect.c: refactor url parsing git_connect(): refactor the port handling for ssh git fetch: support host:/~repo t5500: add test cases for diag-url git fetch-pack: add --diag-url git_connect: factor out discovery of the protocol and its parts git_connect: remove artificial limit of a remote command t5601: add tests for ssh t5601: remove clear_ssh, refactor setup_ssh_wrapper