summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2013-09-09t2024: Fix &&-chaining and a couple of typosLibravatar Johan Herland1-3/+3
Improved-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21glossary: Update and rephrase the definition of a remote-tracking branchLibravatar Johan Herland1-6/+7
The definition of a remote-tracking branch in the glossary have been out-of-date for a while (by e.g. referring to "Pull:" from old-style $GIT_DIR/remotes files). Also, the preceding patches have formalized that a remote-tracking branch must match a configured refspec in order to be usable as an upstream. This patch rewrites the paragraph on remote-tracking branches accordingly. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21branch.c: Validate tracking branches with refspecs instead of refs/remotes/*Libravatar Johan Herland3-3/+18
The current code for validating tracking branches (e.g. the argument to the -t/--track option) hardcodes refs/heads/* and refs/remotes/* as the potential locations for tracking branches. This works with the refspecs created by "git clone" or "git remote add", but is suboptimal in other cases: - If "refs/remotes/foo/bar" exists without any association to a remote (i.e. there is no remote named "foo", or no remote with a refspec that matches "refs/remotes/foo/bar"), then it is impossible to set up a valid upstream config that tracks it. Currently, the code defaults to using "refs/remotes/foo/bar" from repo "." as the upstream, which works, but is probably not what the user had in mind when running "git branch baz --track foo/bar". - If the user has tweaked the fetch refspec for a remote to put its remote-tracking branches outside of refs/remotes/*, e.g. by running git config remote.foo.fetch "+refs/heads/*:refs/foo_stuff/*" then the current code will refuse to use its remote-tracking branches as --track arguments, since they do not match refs/remotes/*. This patch removes the "refs/remotes/*" requirement for upstream branches, and replaces it with explicit checking of the refspecs for each remote to determine whether a given --track argument is a valid remote-tracking branch. This solves both of the above problems, since the matching refspec guarantees that there is a both a remote name and a remote branch name that can be used for the upstream config. However, this means that refs located within refs/remotes/* without a corresponding remote/refspec will no longer be usable as upstreams. The few existing tests which depended on this behavioral quirk has already been fixed in the preceding patches. This patch fixes the last remaining test failure in t2024-checkout-dwim. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21t9114.2: Don't use --track option against "svn-remote"-tracking branchesLibravatar Johan Herland1-1/+1
We are formalizing a requirement that any remote-tracking branch to be used as an upstream (i.e. as an argument to --track), _must_ "belong" to a configured remote by being matched by the "dst" side of a fetch refspec. This test uses --track against a "remotes/trunk" ref which does not belong to any configured (git) remotes, but is instead created by "git svn fetch" operating on an svn-remote. It does not make sense to use an svn-remote as an upstream for a local branch, as a regular "git pull" from (or "git push" to) it would obviously fail (instead you would need to use "git svn" to communicate with this remote). Furthermore, the usage of --track in this case is unnecessary, since the upstreaming config that would be created is never used. Simply removing --track fixes the issue without changing the expected behavior of the test. Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21t7201.24: Add refspec to keep --track workingLibravatar Johan Herland1-0/+1
We are formalizing a requirement that any remote-tracking branch to be used as an upstream (i.e. as an argument to --track), _must_ "belong" to a configured remote by being matched by the "dst" side of a fetch refspec. Without this patch, this test would start failing when the new behavior is introduced. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21t3200.39: tracking setup should fail if there is no matching refspec.Libravatar Johan Herland1-4/+4
We are formalizing a requirement that any remote-tracking branch to be used as an upstream (i.e. as an argument to --track), _must_ "belong" to a configured remote by being matched by the "dst" side of a fetch refspec. This patch encodes the new expected behavior of this test, and marks the test with "test_expect_failure" in anticipation of a following patch to introduce the new behavior. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21checkout: Use remote refspecs when DWIMming tracking branchesLibravatar Johan Herland3-26/+28
The DWIM mode of checkout allows you to run "git checkout foo" when there is no existing local ref or path called "foo", and there is exactly _one_ remote with a remote-tracking branch called "foo". Git will automatically create a new local branch called "foo" using the remote-tracking "foo" as its starting point and configured upstream. For example, consider the following unconventional (but perfectly valid) remote setup: [remote "origin"] fetch = refs/heads/*:refs/remotes/origin/* [remote "frotz"] fetch = refs/heads/*:refs/remotes/frotz/nitfol/* Case 1: Assume both "origin" and "frotz" have remote-tracking branches called "foo", at "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo" respectively. In this case "git checkout foo" should fail, because there is more than one remote with a "foo" branch. Case 2: Assume only "frotz" have a remote-tracking branch called "foo". In this case "git checkout foo" should succeed, and create a local branch "foo" from "refs/remotes/frotz/nitfol/foo", using remote branch "foo" from "frotz" as its upstream. The current code hardcodes the assumption that all remote-tracking branches must match the "refs/remotes/$remote/*" pattern (which is true for remotes with "conventional" refspecs, but not true for the "frotz" remote above). When running "git checkout foo", the current code looks for exactly one ref matching "refs/remotes/*/foo", hence in the above example, it fails to find "refs/remotes/frotz/nitfol/foo", which causes it to fail both case #1 and #2. The better way to handle the above example is to actually study the fetch refspecs to deduce the candidate remote-tracking branches for "foo"; i.e. assume "foo" is a remote branch being fetched, and then map "refs/heads/foo" through the refspecs in order to get the corresponding remote-tracking branches "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo". Finally we check which of these happens to exist in the local repo, and if there is exactly one, we have an unambiguous match for "git checkout foo", and may proceed. This fixes most of the failing tests introduced in the previous patch. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21t2024: Show failure to use refspec when DWIMming remote branch namesLibravatar Johan Herland1-1/+69
When using "git checkout foo" to DWIM the creation of local "foo" from some existing upstream "foo", we assume conventional refspecs as created by "git clone" or "git remote add", and fail to work correctly if the current refspecs do not follow the conventional "refs/remotes/$remote/*" pattern. Improved-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'Libravatar Johan Herland1-0/+99
The DWIM mode of checkout allows you to run "git checkout foo" when there is no existing local ref or path called "foo", and there is exactly one remote with a remote-tracking branch called "foo". Git will then automatically create a new local branch called "foo" using the remote-tracking "foo" as its starting point and configured upstream. Improved-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-19Update draft release notes to 1.8.3Libravatar Junio C Hamano1-1/+27
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-19Merge branch 'jk/a-thread-only-dies-once'Libravatar Junio C Hamano3-6/+26
A regression fix for the logic to detect die() handler triggering itself recursively. * jk/a-thread-only-dies-once: run-command: use thread-aware die_is_recursing routine usage: allow pluggable die-recursion checks
2013-04-19Merge branch 'rt/commentchar-fmt-merge-msg'Libravatar Junio C Hamano1-3/+3
A test fix for recent update. * rt/commentchar-fmt-merge-msg: t6200: avoid path mangling issue on Windows
2013-04-19Merge branch 'mv/sequencer-pick-error-diag'Libravatar Junio C Hamano2-0/+24
"git cherry-pick $blob $tree" is diagnosed as a nonsense. * mv/sequencer-pick-error-diag: cherry-pick: make sure all input objects are commits
2013-04-19Merge branch 'tr/copy-revisions-from-stdin'Libravatar Junio C Hamano1-1/+2
A fix to a long-standing issue in the command line parser for revisions, which was triggered by mv/sequence-pick-error-diag topic. * tr/copy-revisions-from-stdin: read_revisions_from_stdin: make copies for handle_revision_arg
2013-04-19Merge branch 'jn/add-2.0-u-A-sans-pathspec' (early part)Libravatar Junio C Hamano2-40/+95
In Git 2.0, "git add -u" and "git add -A" without any pathspec will update the index for all paths, including those outside the current directory, making it more consistent with "commit -a". To help the migration pain, a warning is issued when the differences between the current behaviour and the upcoming behaviour matters, i.e. when the user has local changes outside the current directory. * 'jn/add-2.0-u-A-sans-pathspec' (early part): add -A: only show pathless 'add -A' warning when changes exist outside cwd add -u: only show pathless 'add -u' warning when changes exist outside cwd add: make warn_pathless_add() a no-op after first call add: add a blank line at the end of pathless 'add [-u|-A]' warning add: make pathless 'add [-u|-A]' warning a file-global function
2013-04-19Merge branch 'ap/strbuf-humanize'Libravatar Junio C Hamano6-40/+86
Teach "--human-readable" aka "-H" option to "git count-objects" to show various large numbers in Ki/Mi/GiB scaled as necessary. * ap/strbuf-humanize: count-objects: add -H option to humanize sizes strbuf: create strbuf_humanise_bytes() to show byte sizes
2013-04-19Merge branch 'fc/branch-upstream-color'Libravatar Junio C Hamano2-9/+30
Add more colors to "git branch -vv" output. * fc/branch-upstream-color: branch: colour upstream branches
2013-04-19Merge branch 'mv/ssl-ftp-curl'Libravatar Junio C Hamano3-0/+27
Does anybody really use commit walkers over (s)ftp? * mv/ssl-ftp-curl: Support FTP-over-SSL/TLS for regular FTP
2013-04-18Update draft release notes to 1.8.3Libravatar Junio C Hamano1-1/+25
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-18Merge branch 'maint'Libravatar Junio C Hamano1-1/+2
* maint: remote-hg: fix commit messages
2013-04-18Merge branch 'jk/test-trash'Libravatar Junio C Hamano1-9/+9
Fix longstanding issues with the test harness when used with --root=<there> option. * jk/test-trash: t/test-lib.sh: drop "$test" variable t/test-lib.sh: fix TRASH_DIRECTORY handling
2013-04-18Merge branch 'th/t9903-symlinked-workdir'Libravatar Junio C Hamano1-5/+5
* th/t9903-symlinked-workdir: t9903: Don't fail when run from path accessed through symlink
2013-04-18Merge branch 'jk/merge-tree-added-identically'Libravatar Junio C Hamano2-23/+13
The resolution of some corner cases by "git merge-tree" were inconsistent between top-of-the-tree and in a subdirectory. * jk/merge-tree-added-identically: merge-tree: don't print entries that match "local"
2013-04-18Merge branch 'jk/http-dumb-namespaces'Libravatar Junio C Hamano3-4/+63
Allow smart-capable HTTP servers to be restricted via the GIT_NAMESPACE mechanism when talking with commit-walker clients (they already do so when talking with smart HTTP clients). * jk/http-dumb-namespaces: http-backend: respect GIT_NAMESPACE with dumb clients
2013-04-18Merge branch 'rs/empty-archive'Libravatar Junio C Hamano1-1/+1
Implementations of "tar" of BSD descend have found to have trouble with reading an otherwise empty tar archive with pax headers and causes an unnecessary test failure. * rs/empty-archive: t5004: fix issue with empty archive test and bsdtar
2013-04-18Merge branch 'fc/send-email-annotate'Libravatar Junio C Hamano7-90/+136
Allows format-patch --cover-letter to be configurable; the most notable is the "auto" mode to create cover-letter only for multi patch series. * fc/send-email-annotate: rebase-am: explicitly disable cover-letter format-patch: trivial cleanups format-patch: add format.coverLetter configuration variable log: update to OPT_BOOL format-patch: refactor branch name calculation format-patch: improve head calculation for cover-letter send-email: make annotate configurable
2013-04-18Merge branch 'jc/push-2.0-default-to-simple' (early part)Libravatar Junio C Hamano12-16/+24
Adjust our tests for upcoming migration of the default value for the "push.default" configuration variable to "simple" from "mixed". * 'jc/push-2.0-default-to-simple' (early part): t5570: do not assume the "matching" push is the default t5551: do not assume the "matching" push is the default t5550: do not assume the "matching" push is the default t9401: do not assume the "matching" push is the default t9400: do not assume the "matching" push is the default t7406: do not assume the "matching" push is the default t5531: do not assume the "matching" push is the default t5519: do not assume the "matching" push is the default t5517: do not assume the "matching" push is the default t5516: do not assume the "matching" push is the default t5505: do not assume the "matching" push is the default t5404: do not assume the "matching" push is the default
2013-04-18Merge branch 'jk/daemon-user-doc'Libravatar Junio C Hamano1-0/+7
Document where the configuration is read by the git-daemon when its --user option is used. * jk/daemon-user-doc: doc: clarify that "git daemon --user=<user>" option does not export HOME=~user
2013-04-18Merge branch 'fc/completion'Libravatar Junio C Hamano2-47/+96
In addition to a user visible change to offer more options to cherry-pick, generally cleans up and simplifies the code. * fc/completion: completion: small optimization completion: inline __gitcomp_1 to its sole callsite completion: get rid of compgen completion: add __gitcomp_nl tests completion: add new __gitcompadd helper completion: get rid of empty COMPREPLY assignments completion: trivial test improvement completion: add more cherry-pick options
2013-04-18Merge branch 'kb/co-orphan-suggestion-short-sha1'Libravatar Junio C Hamano1-1/+1
Update the informational message when "git checkout" leaves the detached head state. * kb/co-orphan-suggestion-short-sha1: checkout: abbreviate hash in suggest_reattach
2013-04-18Merge branch 'jc/detached-head-doc'Libravatar Junio C Hamano1-3/+16
* jc/detached-head-doc: glossary: extend "detached HEAD" description
2013-04-18Merge branch 'tr/packed-object-info-wo-recursion'Libravatar Junio C Hamano1-145/+266
Attempts to reduce the stack footprint of sha1_object_info() and unpack_entry() codepaths. * tr/packed-object-info-wo-recursion: sha1_file: remove recursion in unpack_entry Refactor parts of in_delta_base_cache/cache_or_unpack_entry sha1_file: remove recursion in packed_object_info
2013-04-18Merge branch 'jk/http-error-messages'Libravatar Junio C Hamano1-1/+1
A regression fix for the recently graduated topic. * jk/http-error-messages: http: set curl FAILONERROR each time we select a handle
2013-04-18t6200: avoid path mangling issue on WindowsLibravatar Johannes Sixt1-3/+3
MSYS bash interprets the slash in the argument core.commentchar="/" as root directory and mangles it into a Windows style path. Use a different core.commentchar to dodge the issue. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-17remote-hg: fix commit messagesLibravatar Felipe Contreras1-1/+2
git fast-import expects an extra newline after the commit message data, but we are adding it only on hg-git compat mode, which is why the bidirectionality tests pass. We should add it unconditionally. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-16Merge branch 'maint'Libravatar Junio C Hamano1-0/+4
* maint: help.c: add a compatibility comment to cmd_version()
2013-04-16run-command: use thread-aware die_is_recursing routineLibravatar Jeff King1-0/+11
If we die from an async thread, we do not actually exit the program, but just kill the thread. This confuses the static counter in usage.c's default die_is_recursing function; it updates the counter once for the thread death, and then when the main program calls die() itself, it erroneously thinks we are recursing. The end result is that we print "recursion detected in die handler" instead of the real error in such a case (the easiest way to trigger this is having a remote connection hang up while running a sideband demultiplexer). This patch solves it by using a per-thread counter when the async_die function is installed; we detect recursion in each thread (including the main one), but they do not step on each other's toes. Other threaded code does not need to worry about this, as they do not install specialized die handlers; they just let a die() from a sub-thread take down the whole program. Since we are overriding the default recursion-check function, there is an interesting corner case that is not a problem, but bears some explanation. Imagine the main thread calls die(), and then in the die_routine starts an async call. We will switch to using thread-local storage, which starts at 0, for the main thread's counter, even though the original counter was actually at 1. That's OK, though, for two reasons: 1. It would miss only the first level of recursion, and would still find recursive failures inside the async helper. 2. We do not currently and are not likely to start doing anything as heavyweight as starting an async routine from within a die routine or helper function. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-16usage: allow pluggable die-recursion checksLibravatar Jeff King2-6/+15
When any git code calls die or die_errno, we use a counter to detect recursion into the die functions from any of the helper functions. However, such a simple counter is not good enough for threaded programs, which may call die from a sub-thread, killing only the sub-thread (but incrementing the counter for everyone). Rather than try to deal with threads ourselves here, let's just allow callers to plug in their own recursion-detection function. This is similar to how we handle the die routine (the caller plugs in a die routine which may kill only the sub-thread). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-16help.c: add a compatibility comment to cmd_version()Libravatar David Aguilar1-0/+4
External projects have been known to parse the output of "git version". Help prevent future authors from changing its format by adding a comment to its implementation. Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-16convert: The native line-ending is \r\n on MinGWLibravatar Jonathan Nieder1-0/+1
If you try this: 1. Install Git for Windows (from the msysgit project) 2. Put [core] autocrlf = false eol = native in your .gitconfig. 3. Clone a project with *.txt text in its .gitattributes. Then with current git, any text files checked out have LF line endings, instead of the expected CRLF. Cc: Johannes Schindelin <johannes.schindelin@gmx.de> Cc: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-16read_revisions_from_stdin: make copies for handle_revision_argLibravatar Thomas Rast1-1/+2
read_revisions_from_stdin() has passed pointers to its read buffer down to handle_revision_arg() since its inception way back in 42cabc3 (Teach rev-list an option to read revs from the standard input., 2006-09-05). Even back then, this was a bug: through add_pending_object, the argument was recorded in the object_array's 'name' field. Fix it by making a copy whenever read_revisions_from_stdin() passes an argument down the callchain. The other caller runs handle_revision_arg() on argv[], where it would be redundant to make a copy. Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-16http: set curl FAILONERROR each time we select a handleLibravatar Jeff King1-1/+1
Because we reuse curl handles for multiple requests, the setup of a handle happens in two stages: stable, global setup and per-request setup. The lifecycle of a handle is something like: 1. get_curl_handle; do basic global setup that will last through the whole program (e.g., setting the user agent, ssl options, etc) 2. get_active_slot; set up a per-request baseline (e.g., clearing the read/write functions, making it a GET request, etc) 3. perform the request with curl_*_perform functions 4. goto step 2 to perform another request Breaking it down this way means we can avoid doing global setup from step (1) repeatedly, but we still finish step (2) with a predictable baseline setup that callers can rely on. Until commit 6d052d7 (http: add HTTP_KEEP_ERROR option, 2013-04-05), setting curl's FAILONERROR option was a global setup; we never changed it. However, 6d052d7 introduced an option where some requests might turn off FAILONERROR. Later requests using the same handle would have the option unexpectedly turned off, which meant they would not notice http failures at all. This could easily be seen in the test-suite for the "half-auth" cases of t5541 and t5551. The initial requests turned off FAILONERROR, which meant it was erroneously off for the rpc POST. That worked fine for a successful request, but meant that we failed to react properly to the HTTP 401 (instead, we treated whatever the server handed us as a successful message body). The solution is simple: now that FAILONERROR is a per-request setting, we move it to get_active_slot to make sure it is reset for each request. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-15remote-bzr: fix prefix of tagsLibravatar Felipe Contreras1-3/+6
In the current transport-helper code, refs without namespaced refspecs don't work correctly, so let's always use them. Some people reported issues with 'git clone --mirror', and this fixes them, as well as possibly others. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-15Update draft release notes to 1.8.3Libravatar Junio C Hamano1-0/+25
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-15Merge branch 'jk/diff-graph-submodule-summary'Libravatar Junio C Hamano3-4/+11
Make "git diff --graph" work better with submodule log output. * jk/diff-graph-submodule-summary: submodule: print graph output next to submodule log
2013-04-15Merge branch 'jk/diff-algo-finishing-touches'Libravatar Junio C Hamano2-2/+9
"git diff --diff-algorithm algo" is also understood as "git diff --diff-algorithm=algo". * jk/diff-algo-finishing-touches: diff: allow unstuck arguments with --diff-algorithm git-merge(1): document diff-algorithm option to merge-recursive
2013-04-15Merge branch 'rt/commentchar-fmt-merge-msg'Libravatar Junio C Hamano2-7/+29
The new core.commentchar configuration was not applied to a few places. * rt/commentchar-fmt-merge-msg: fmt-merge-msg: use core.commentchar in tag signatures completely fmt-merge-msg: respect core.commentchar in people credits
2013-04-15Merge branch 'lf/bundle-with-tip-wo-message'Libravatar Junio C Hamano2-1/+11
"git bundle" did not like a bundle created using a commit without any message as its one of the prerequistes. * lf/bundle-with-tip-wo-message: bundle: Accept prerequisites without commit messages
2013-04-15Merge branch 'jk/show-branch-strbuf'Libravatar Junio C Hamano1-9/+8
"git show-branch" was not prepared to show a very long run of ancestor operators e.g. foobar^2~2^2^2^2...^2~4 correctly. * jk/show-branch-strbuf: show-branch: use strbuf instead of static buffer
2013-04-15Merge branch 'jk/http-error-messages'Libravatar Junio C Hamano4-23/+76
Improve error reporting from the http transfer clients. * jk/http-error-messages: http: drop http_error function remote-curl: die directly with http error messages http: re-word http error message http: simplify http_error helper function remote-curl: consistently report repo url for http errors remote-curl: always show friendlier 404 message remote-curl: let servers override http 404 advice remote-curl: show server content on http errors http: add HTTP_KEEP_ERROR option