summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2014-11-19Merge branch 'tb/no-relative-file-url'Libravatar Junio C Hamano1-1/+1
* tb/no-relative-file-url: t5705: the file:// URL should be absolute
2014-11-18Merge branch 'da/difftool'Libravatar Junio C Hamano1-0/+5
Fix-up to a new feature in 'master'. * da/difftool: difftool: honor --trust-exit-code for builtin tools
2014-11-14difftool: honor --trust-exit-code for builtin toolsLibravatar David Aguilar1-0/+5
run_merge_tool() was not setting $status, which prevented the exit code for builtin tools from being forwarded to the caller. Capture the exit status and add a test to guarantee the behavior. Reported-by: Adria Farres <14farresa@gmail.com> Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-13t5705: the file:// URL should be absoluteLibravatar Torsten Bögershausen1-1/+1
The test misused a URL "file://." to mean "relative to here", which we no longer accept. In a file:// URL, typically there is no host, and RFC1738 says that file:///<path> should be used. Update t5705 to use a working URL. Reported-by: Michael Blume <blume.mike@gmail.com> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-12Merge branch 'jk/fetch-reflog-df-conflict'Libravatar Junio C Hamano1-18/+18
Fix-up a test for portability. * jk/fetch-reflog-df-conflict: t1410: fix breakage on case-insensitive filesystems
2014-11-10t1410: fix breakage on case-insensitive filesystemsLibravatar Jeff King1-18/+18
Two tests recently added to t1410 create branches "a" and "a/b" to test d/f conflicts on reflogs. Earlier, unrelated tests in that script create the path "A/B" in the working tree. There's no conflict on a case-sensitive filesystem, but on a case-insensitive one, "git log" will complain that "a/b" is both a revision and a working tree path. We could fix this by using a "--" to disambiguate, but we are probably better off using names that are less confusing to make it more clear that they are unrelated to the working tree files. This patch turns "a/b" into "one/two". Reported-by: Michael Blume <blume.mike@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-06Merge branch 'tm/line-log-first-parent'Libravatar Junio C Hamano1-0/+5
"git log --first-parent -L..." used to crash. * tm/line-log-first-parent: line-log: fix crash when --first-parent is used
2014-11-06Merge branch 'jk/fetch-reflog-df-conflict'Libravatar Junio C Hamano2-0/+74
Corner-case bugfixes for "git fetch" around reflog handling. * jk/fetch-reflog-df-conflict: ignore stale directories when checking reflog existence fetch: load all default config at startup
2014-11-04line-log: fix crash when --first-parent is usedLibravatar Tzvetan Mikov1-0/+5
line-log tries to access all parents of a commit, but only the first parent has been loaded if "--first-parent" is specified, resulting in a crash. Limit the number of parents to one if "--first-parent" is specified. Reported-by: Eric N. Vander Weele <ericvw@gmail.com> Signed-off-by: Tzvetan Mikov <tmikov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-04ignore stale directories when checking reflog existenceLibravatar Jeff King1-0/+34
When we update a ref, we have two rules for whether or not we actually update the reflog: 1. If the reflog already exists, we will always append to it. 2. If log_all_ref_updates is set, we will create a new reflog file if necessary. We do the existence check by trying to open the reflog file, either with or without O_CREAT (depending on log_all_ref_updates). If it fails, then we check errno to see what happened. If we were not using O_CREAT and we got ENOENT, the file doesn't exist, and we return success (there isn't a reflog already, and we were not told to make a new one). If we get EISDIR, then there is likely a stale directory that needs to be removed (e.g., there used to be "foo/bar", it was deleted, and the directory "foo" was left. Now we want to create the ref "foo"). If O_CREAT is set, then we catch this case, try to remove the directory, and retry our open. So far so good. But if we get EISDIR and O_CREAT is not set, then we treat this as any other error, which is not right. Like ENOENT, EISDIR is an indication that we do not have a reflog, and we should silently return success (we were not told to create it). Instead, the current code reports this as an error, and we fail to update the ref at all. Note that this is relatively unlikely to happen, as you would have to have had reflogs turned on, and then later turned them off (it could also happen due to a bug in fetch, but that was fixed in the previous commit). However, it's quite easy to fix: we just need to treat EISDIR like ENOENT for the non-O_CREAT case, and silently return (note that this early return means we can also simplify the O_CREAT case). Our new tests cover both cases (O_CREAT and non-O_CREAT). The first one already worked, of course. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-04fetch: load all default config at startupLibravatar Jeff King1-0/+40
When we start the git-fetch program, we call git_config to load all config, but our callback only processes the fetch.prune option; we do not chain to git_default_config at all. This means that we may not load some core configuration which will have an effect. For instance, we do not load core.logAllRefUpdates, which impacts whether or not we create reflogs in a bare repository. Note that I said "may" above. It gets even more exciting. If we have to transfer actual objects as part of the fetch, then we call fetch_pack as part of the same process. That function loads its own config, which does chain to git_default_config, impacting global variables which are used by the rest of fetch. But if the fetch is a pure ref update (e.g., a new ref which is a copy of an old one), we skip fetch_pack entirely. So we get inconsistent results depending on whether or not we have actual objects to transfer or not! Let's just load the core config at the start of fetch, so we know we have it (we may also load it again as part of fetch_pack, but that's OK; it's designed to be idempotent). Our tests check both cases (with and without a pack). We also check similar behavior for push for good measure, but it already works as expected. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-31Merge branch 'rs/grep-color-words'Libravatar Junio C Hamano1-0/+94
Allow painting or not painting (partial) matches in context lines when showing "grep -C<num>" output in color. * rs/grep-color-words: grep: add color.grep.matchcontext and color.grep.matchselected
2014-10-29Merge branch 'jk/pack-objects-no-bitmap-when-splitting' into maintLibravatar Junio C Hamano1-0/+9
* jk/pack-objects-no-bitmap-when-splitting: pack-objects: turn off bitmaps when we split packs
2014-10-29Merge branch 'da/difftool'Libravatar Junio C Hamano1-0/+51
Allow diff tool backend to stop early by exiting with a non-zero status. * da/difftool: difftool: add support for --trust-exit-code difftool--helper: exit when reading a prompt answer fails
2014-10-29Merge branch 'mg/lib-gpg-ro-safety'Libravatar Junio C Hamano1-0/+1
In a tarball extract whose files are all read-only, running GPG tests would have failed due to unwritable files. * mg/lib-gpg-ro-safety: t/lib-gpg: make gpghome files writable
2014-10-29Merge branch 'jk/prune-mtime'Libravatar Junio C Hamano4-0/+181
Tighten the logic to decide that an unreachable cruft is sufficiently old by covering corner cases such as an ancient object becoming reachable and then going unreachable again, in which case its retention period should be prolonged. * jk/prune-mtime: (28 commits) drop add_object_array_with_mode revision: remove definition of unused 'add_object' function pack-objects: double-check options before discarding objects repack: pack objects mentioned by the index pack-objects: use argv_array reachable: use revision machinery's --indexed-objects code rev-list: add --indexed-objects option rev-list: document --reflog option t5516: test pushing a tag of an otherwise unreferenced blob traverse_commit_list: support pending blobs/trees with paths make add_object_array_with_context interface more sane write_sha1_file: freshen existing objects pack-objects: match prune logic for discarding objects pack-objects: refactor unpack-unreachable expiration check prune: keep objects reachable from recent objects sha1_file: add for_each iterators for loose and packed objects count-objects: use for_each_loose_file_in_objdir count-objects: do not use xsize_t when counting object size prune-packed: use for_each_loose_file_in_objdir reachable: mark index blobs as SEEN ...
2014-10-28difftool: add support for --trust-exit-codeLibravatar David Aguilar1-0/+43
Teach difftool to exit when a diff tool returns a non-zero exit code when either --trust-exit-code is specified or difftool.trustExitCode is true. Forward exit codes from invoked diff tools to the caller when --trust-exit-code is used. Suggested-by: Adri Farr <14farresa@gmail.com> Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-28grep: add color.grep.matchcontext and color.grep.matchselectedLibravatar René Scharfe1-0/+94
The config option color.grep.match can be used to specify the highlighting color for matching strings. Add the options matchContext and matchSelected to allow different colors to be specified for matching strings in the context vs. in selected lines. This is similar to the ms and mc specifiers in GNU grep's environment variable GREP_COLORS. Tests are from Zoltan Klinger's earlier attempt to solve the same issue in a different way. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-27t/lib-gpg: make gpghome files writableLibravatar Michael J Gruber1-0/+1
t/lib-gpg.sh copies the test environment's gpg home to the trash directory and makes sure the directoty is writable. Make sure the copied files are writable, too. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-27difftool--helper: exit when reading a prompt answer failsLibravatar Johannes Sixt1-0/+8
An attempt to quit difftool by hitting Ctrl-D (EOF) at its prompt does not quit it, but is treated as if 'yes' was answered to the prompt and all following prompts, which is contrary to the user's intent. Fix the error check. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-24Merge branch 'jc/push-cert'Libravatar Junio C Hamano1-0/+44
* jc/push-cert: push: heed user.signingkey for signed pushes
2014-10-24Merge branch 'wk/t1304-wo-USER'Libravatar Junio C Hamano1-1/+1
* wk/t1304-wo-USER: t1304: Set LOGNAME even if USER is unset or null
2014-10-24Merge branch 'jk/pack-objects-no-bitmap-when-splitting'Libravatar Junio C Hamano1-0/+9
Splitting pack-objects output into multiple packs is incompatible with the use of reachability bitmap. * jk/pack-objects-no-bitmap-when-splitting: pack-objects: turn off bitmaps when we split packs
2014-10-24push: heed user.signingkey for signed pushesLibravatar Michael J Gruber1-0/+44
push --signed promises to take user.signingkey as the signing key but fails to read the config. Make it do so. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-21Merge branch 'da/mergetool-temporary-directory'Libravatar Junio C Hamano1-0/+23
Allow a temporary directory specified to be used while running "git mergetool" backend. * da/mergetool-temporary-directory: t7610-mergetool: add test cases for mergetool.writeToTemp mergetool: add an option for writing to a temporary directory
2014-10-21Merge branch 'da/mergetool-tool-help'Libravatar Junio C Hamano1-6/+6
Allow "git mergetool --help" to run outside a Git repository. * da/mergetool-tool-help: difftool: don't assume that default sh is sane mergetool: don't require a work tree for --tool-help git-sh-setup: move GIT_DIR initialization into a function mergetool: use more conservative temporary filenames test-lib-functions: adjust style to match CodingGuidelines t7610-mergetool: prefer test_config over git config
2014-10-21Merge branch 'da/mergetool-tests'Libravatar Junio C Hamano2-471/+469
The clean-up of this test script was long overdue and is a very welcome change. * da/mergetool-tests: test-lib-functions: adjust style to match CodingGuidelines t7610-mergetool: use test_config to isolate tests t7610-mergetool: add missing && and remove commented-out code t7610-mergetool: use tabs instead of a mix of tabs and spaces
2014-10-21Merge branch 'rs/ref-transaction'Libravatar Junio C Hamano6-71/+322
The API to update refs have been restructured to allow introducing a true transactional updates later. We would even allow storing refs in backends other than the traditional filesystem-based one. * rs/ref-transaction: (25 commits) ref_transaction_commit: bail out on failure to remove a ref lockfile: remove unable_to_lock_error refs.c: do not permit err == NULL remote rm/prune: print a message when writing packed-refs fails for-each-ref: skip and warn about broken ref names refs.c: allow listing and deleting badly named refs test: put tests for handling of bad ref names in one place packed-ref cache: forbid dot-components in refnames branch -d: simplify by using RESOLVE_REF_READING branch -d: avoid repeated symref resolution reflog test: test interaction with detached HEAD refs.c: change resolve_ref_unsafe reading argument to be a flags field refs.c: make write_ref_sha1 static fetch.c: change s_update_ref to use a ref transaction refs.c: ref_transaction_commit: distinguish name conflicts from other errors refs.c: pass a list of names to skip to is_refname_available refs.c: call lock_ref_sha1_basic directly from commit refs.c: refuse to lock badly named refs in lock_ref_sha1_basic rename_ref: don't ask read_ref_full where the ref came from refs.c: pass the ref log message to _create/delete/update instead of _commit ...
2014-10-20Merge branch 'cc/interpret-trailers'Libravatar Junio C Hamano1-0/+863
A new filter to programatically edit the tail end of the commit log messages. * cc/interpret-trailers: Documentation: add documentation for 'git interpret-trailers' trailer: add tests for commands in config file trailer: execute command from 'trailer.<name>.command' trailer: add tests for "git interpret-trailers" trailer: add interpret-trailers command trailer: put all the processing together and print trailer: parse trailers from file or stdin trailer: process command line trailer arguments trailer: read and process config information trailer: process trailers from input message and arguments trailer: add data structures and basic functions
2014-10-20Merge branch 'ta/config-set'Libravatar Junio C Hamano1-2/+2
* ta/config-set: t1308: fix broken here document in test script
2014-10-20Merge branch 'jk/test-shell-trace'Libravatar Junio C Hamano4-35/+84
Test scripts were taught to notice "-x" option to show shell trace, as if the tests were run under "sh -x". * jk/test-shell-trace: test-lib.sh: support -x option for shell-tracing t5304: use helper to report failure of "test foo = bar" t5304: use test_path_is_* instead of "test -f"
2014-10-20Revert "archive: honor tar.umask even for pax headers"Libravatar Junio C Hamano1-5/+0
This reverts commit 10f343ea814f5c18a0913997904ee11cd9b7da24, whose output is no longer bit-for-bit equivalent from the older versions of Git, which the infrastructure to (pretend to) upload tarballs kernel.org uses depends on.
2014-10-19t1304: Set LOGNAME even if USER is unset or nullLibravatar W. Trevor King1-1/+1
Avoid: # ./t1304-default-acl.sh ok 1 - checking for a working acl setup ok 2 - Setup test repo not ok 3 - Objects creation does not break ACLs with restrictive umask # # # SHA1 for empty blob # check_perms_and_acl .git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391 # not ok 4 - git gc does not break ACLs with restrictive umask # # git gc && # check_perms_and_acl .git/objects/pack/*.pack # # failed 2 among 4 test(s) 1..4 on systems where USER isn't set. It's usually set by the login process, but it isn't set when launching some Docker images. For example: $ docker run --rm debian env HOME=/ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin HOSTNAME=b2dfdfe797ed 'id -u -n' has been in POSIX from Issue 2 through 2013 [1], so I don't expect compatibility issues. [1]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/id.html Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-19pack-objects: turn off bitmaps when we split packsLibravatar Jeff King1-0/+9
If a pack.packSizeLimit is set, we may split the pack data across multiple packfiles. This means we cannot generate .bitmap files, as they require that all of the reachable objects are in the same pack. We check that condition when we are generating the list of objects to pack (and disable bitmaps if we are not packing everything), but we forgot to update it when we notice that we needed to split (which doesn't happen until the actual write phase). The resulting bitmaps are quite bogus (they mention entries that do not exist in the pack!) and can cause a fetch or push to send insufficient objects. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-19repack: pack objects mentioned by the indexLibravatar Jeff King1-0/+13
When we pack all objects, we use only the objects reachable from references and reflogs. This misses any objects which are reachable from the index, but not yet referenced. By itself this isn't a big deal; the objects can remain loose until they are actually used in a commit. However, it does create a problem when we drop packed but unreachable objects. We try to optimize out the writing of objects that we will immediately prune, which means we must follow the same rules as prune in determining what is reachable. And prune uses the index for this purpose. This is rather uncommon in practice, as objects in the index would not usually have been packed in the first place. But it could happen in a sequence like: 1. You make a commit on a branch that references blob X. 2. You repack, moving X into the pack. 3. You delete the branch (and its reflog), so that X is unreferenced. 4. You "git add" blob X so that it is now referenced only by the index. 5. You repack again with git-gc. The pack-objects we invoke will see that X is neither referenced nor recent and not bother loosening it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-19rev-list: add --indexed-objects optionLibravatar Jeff King1-0/+23
There is currently no easy way to ask the revision traversal machinery to include objects reachable from the index (e.g., blobs and trees that have not yet been committed). This patch adds an option to do so. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-19t5516: test pushing a tag of an otherwise unreferenced blobLibravatar Jeff King1-0/+13
It's not unreasonable to have a tag that points to a blob that is not part of the normal history. We do this in git.git to distribute gpg keys. However, we never explicitly checked in our test suite that this actually works (i.e., that pack-objects actually sends the blob because of the tag mentioning it). It does in fact work fine, but a recent patch under discussion broke this, and the test suite didn't notice. Let's make the test suite more complete. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-16t7610-mergetool: add test cases for mergetool.writeToTempLibravatar David Aguilar1-0/+23
Add tests to ensure that filenames start with "./" when mergetool.writeToTemp is false and do not start with "./" when mergetool.writeToTemp is true. Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-16test-lib-functions: adjust style to match CodingGuidelinesLibravatar David Aguilar1-12/+18
Prefer "test" over "[ ]" for conditionals. Prefer "$()" over backticks for command substitutions. Avoid control structures on a single line with semicolons. Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-16t7610-mergetool: use test_config to isolate testsLibravatar David Aguilar1-5/+3
Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-16write_sha1_file: freshen existing objectsLibravatar Jeff King1-0/+27
When we try to write a loose object file, we first check whether that object already exists. If so, we skip the write as an optimization. However, this can interfere with prune's strategy of using mtimes to mark files in progress. For example, if a branch contains a particular tree object and is deleted, that tree object may become unreachable, and have an old mtime. If a new operation then tries to write the same tree, this ends up as a noop; we notice we already have the object and do nothing. A prune running simultaneously with this operation will see the object as old, and may delete it. We can solve this by "freshening" objects that we avoid writing by updating their mtime. The algorithm for doing so is essentially the same as that of has_sha1_file. Therefore we provide a new (static) interface "check_and_freshen", which finds and optionally freshens the object. It's trivial to implement freshening and simple checking by tweaking a single parameter. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-16pack-objects: match prune logic for discarding objectsLibravatar Jeff King1-38/+55
A recent commit taught git-prune to keep non-recent objects that are reachable from recent ones. However, pack-objects, when loosening unreachable objects, tries to optimize out the write in the case that the object will be immediately pruned. It now gets this wrong, since its rule does not reflect the new prune code (and this can be seen by running t6501 with a strategically placed repack). Let's teach pack-objects similar logic. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-16prune: keep objects reachable from recent objectsLibravatar Jeff King1-0/+88
Our current strategy with prune is that an object falls into one of three categories: 1. Reachable (from ref tips, reflogs, index, etc). 2. Not reachable, but recent (based on the --expire time). 3. Not reachable and not recent. We keep objects from (1) and (2), but prune objects in (3). The point of (2) is that these objects may be part of an in-progress operation that has not yet updated any refs. However, it is not always the case that objects for an in-progress operation will have a recent mtime. For example, the object database may have an old copy of a blob (from an abandoned operation, a branch that was deleted, etc). If we create a new tree that points to it, a simultaneous prune will leave our tree, but delete the blob. Referencing that tree with a commit will then work (we check that the tree is in the object database, but not that all of its referred objects are), as will mentioning the commit in a ref. But the resulting repo is corrupt; we are missing the blob reachable from a ref. One way to solve this is to be more thorough when referencing a sha1: make sure that not only do we have that sha1, but that we have objects it refers to, and so forth recursively. The problem is that this is very expensive. Creating a parent link would require traversing the entire object graph! Instead, this patch pushes the extra work onto prune, which runs less frequently (and has to look at the whole object graph anyway). It creates a new category of objects: objects which are not recent, but which are reachable from a recent object. We do not prune these objects, just like the reachable and recent ones. This lets us avoid the recursive check above, because if we have an object, even if it is unreachable, we should have its referent. We can make a simple inductive argument that with this patch, this property holds (that there are no objects with missing referents in the repository): 0. When we have no objects, we have nothing to refer or be referred to, so the property holds. 1. If we add objects to the repository, their direct referents must generally exist (e.g., if you create a tree, the blobs it references must exist; if you create a commit to point at the tree, the tree must exist). This is already the case before this patch. And it is not 100% foolproof (you can make bogus objects using `git hash-object`, for example), but it should be the case for normal usage. Therefore for any sequence of object additions, the property will continue to hold. 2. If we remove objects from the repository, then we will not remove a child object (like a blob) if an object that refers to it is being kept. That is the part implemented by this patch. Note, however, that our reachability check and the actual pruning are not atomic. So it _is_ still possible to violate the property (e.g., an object becomes referenced just as we are deleting it). This patch is shooting for eliminating problems where the mtimes of dependent objects differ by hours or days, and one is dropped without the other. It does nothing to help with short races. Naively, the simplest way to implement this would be to add all recent objects as tips to the reachability traversal. However, this does not perform well. In a recently-packed repository, all reachable objects will also be recent, and therefore we have to look at each object twice. This patch instead performs the reachability traversal, then follows up with a second traversal for recent objects, skipping any that have already been marked. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-15test-lib-functions: adjust style to match CodingGuidelinesLibravatar David Aguilar1-12/+18
Prefer "test" over "[ ]" for conditionals. Prefer "$()" over backticks for command substitutions. Avoid control structures on a single line with semicolons. Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-15t7610-mergetool: prefer test_config over git configLibravatar David Aguilar1-11/+9
Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-15t7610-mergetool: add missing && and remove commented-out codeLibravatar David Aguilar1-8/+2
Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-15t7610-mergetool: use tabs instead of a mix of tabs and spacesLibravatar David Aguilar1-459/+459
Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-15refs.c: allow listing and deleting badly named refsLibravatar Ronnie Sahlberg1-1/+124
We currently do not handle badly named refs well: $ cp .git/refs/heads/master .git/refs/heads/master.....@\*@\\. $ git branch fatal: Reference has invalid format: 'refs/heads/master.....@*@\.' $ git branch -D master.....@\*@\\. error: branch 'master.....@*@\.' not found. Users cannot recover from a badly named ref without manually finding and deleting the loose ref file or appropriate line in packed-refs. Making that easier will make it easier to tweak the ref naming rules in the future, for example to forbid shell metacharacters like '`' and '"', without putting people in a state that is hard to get out of. So allow "branch --list" to show these refs and allow "branch -d/-D" and "update-ref -d" to delete them. Other commands (for example to rename refs) will continue to not handle these refs but can be changed in later patches. Details: In resolving functions, refuse to resolve refs that don't pass the git-check-ref-format(1) check unless the new RESOLVE_REF_ALLOW_BAD_NAME flag is passed. Even with RESOLVE_REF_ALLOW_BAD_NAME, refuse to resolve refs that escape the refs/ directory and do not match the pattern [A-Z_]* (think "HEAD" and "MERGE_HEAD"). In locking functions, refuse to act on badly named refs unless they are being deleted and either are in the refs/ directory or match [A-Z_]*. Just like other invalid refs, flag resolved, badly named refs with the REF_ISBROKEN flag, treat them as resolving to null_sha1, and skip them in all iteration functions except for for_each_rawref. Flag badly named refs (but not symrefs pointing to badly named refs) with a REF_BAD_NAME flag to make it easier for future callers to notice and handle them specially. For example, in a later patch for-each-ref will use this flag to detect refs whose names can confuse callers parsing for-each-ref output. In the transaction API, refuse to create or update badly named refs, but allow deleting them (unless they try to escape refs/ and don't match [A-Z_]*). Signed-off-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-15test: put tests for handling of bad ref names in one placeLibravatar Ronnie Sahlberg3-74/+84
There's no straightforward way to grep for all tests dealing with invalid refs. Put them in a single test script so it is easy to see what functionality has not been exercised with bad ref names yet. Signed-off-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-15branch -d: avoid repeated symref resolutionLibravatar Jonathan Nieder2-0/+43
If a repository gets in a broken state with too much symref nesting, it cannot be repaired with "git branch -d": $ git symbolic-ref refs/heads/nonsense refs/heads/nonsense $ git branch -d nonsense error: branch 'nonsense' not found. Worse, "git update-ref --no-deref -d" doesn't work for such repairs either: $ git update-ref -d refs/heads/nonsense error: unable to resolve reference refs/heads/nonsense: Too many levels of symbolic links Fix both by teaching resolve_ref_unsafe a new RESOLVE_REF_NO_RECURSE flag and passing it when appropriate. Callers can still read the value of a symref (for example to print a message about it) with that flag set --- resolve_ref_unsafe will resolve one level of symrefs and stop there. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Reviewed-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>