summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2014-03-31Merge branch 'ib/rev-parse-parseopt-argh'Libravatar Junio C Hamano1-1/+12
Teaches the "rev-parse --parseopt" mechanism used by scripted Porcelains to parse command line options and give help text how to supply argv-help (the placeholder string for an option parameter, e.g. "key-id" in "--gpg-sign=<key-id>"). * ib/rev-parse-parseopt-argh: t1502: protect runs of SPs used in the indentation rev-parse --parseopt: option argument name hints
2014-03-28Merge branch 'bp/commit-p-editor'Libravatar Junio C Hamano5-17/+38
When it is not necessary to edit a commit log message (e.g. "git commit -m" is given a message without specifying "-e"), we used to disable the spawning of the editor by overriding GIT_EDITOR, but this means all the uses of the editor, other than to edit the commit log message, are also affected. * bp/commit-p-editor: run-command: mark run_hook_with_custom_index as deprecated merge hook tests: fix and update tests merge: fix GIT_EDITOR override for commit hook commit: fix patch hunk editing with "commit -p -m" test patch hunk editing with "commit -p -m" merge hook tests: use 'test_must_fail' instead of '!' merge hook tests: fix missing '&&' in test
2014-03-28Merge branch 'fr/add-interactive-argv-array'Libravatar Junio C Hamano1-11/+10
* fr/add-interactive-argv-array: add: use struct argv_array in run_add_interactive()
2014-03-28Merge branch 'jk/pack-bitmap-progress'Libravatar Junio C Hamano1-11/+19
The progress output while repacking and transferring objects showed an apparent large silence while writing the objects out of existing packfiles, when the reachability bitmap was in use. * jk/pack-bitmap-progress: pack-objects: show reused packfile objects in "Counting objects" pack-objects: show progress for reused packfiles
2014-03-28Merge branch 'jk/pack-bitmap'Libravatar Junio C Hamano1-1/+11
Instead of dying when asked to (re)pack with the reachability bitmap when a bitmap cannot be built, just (re)pack without producing a bitmap in such a case, with a warning. * jk/pack-bitmap: pack-objects: turn off bitmaps when skipping objects
2014-03-25Merge branch 'nd/index-pack-error-message'Libravatar Junio C Hamano1-2/+2
* nd/index-pack-error-message: index-pack: report error using the correct variable
2014-03-25Merge branch 'nd/commit-editor-cleanup'Libravatar Junio C Hamano1-3/+11
"git commit --cleanup=<mode>" learned a new mode, scissors. * nd/commit-editor-cleanup: commit: add --cleanup=scissors wt-status.c: move cut-line print code out to wt_status_add_cut_line wt-status.c: make cut_line[] const to shrink .data section a bit
2014-03-25Merge branch 'jk/warn-on-object-refname-ambiguity'Libravatar Junio C Hamano1-6/+9
* jk/warn-on-object-refname-ambiguity: rev-list: disable object/refname ambiguity check with --stdin cat-file: restore warn_on_object_refname_ambiguity flag cat-file: fix a minor memory leak in batch_objects cat-file: refactor error handling of batch_objects
2014-03-25Merge branch 'jk/mv-submodules-fix'Libravatar Junio C Hamano1-0/+9
"git mv" that moves a submodule forgot to adjust the array that uses to keep track of which submodules were to be moved to update its configuration. * jk/mv-submodules-fix: mv: prevent mismatched data when ignoring errors. builtin/mv: fix out of bounds write
2014-03-23rev-parse --parseopt: option argument name hintsLibravatar Ilya Bobyr1-1/+12
Built-in commands can specify names for option arguments when usage text is generated for a command. sh based commands should be able to do the same. Option argument name hint is any text that comes after [*=?!] after the argument name up to the first whitespace. Signed-off-by: Ilya Bobyr <ilya.bobyr@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21Merge branch 'nd/upload-pack-shallow'Libravatar Junio C Hamano1-0/+10
Serving objects from a shallow repository needs to write a temporary file to be used, but the serving upload-pack may not have write access to the repository which is meant to be read-only. Instead feed these temporary shallow bounds from the standard input of pack-objects so that we do not have to use a temporary file. * nd/upload-pack-shallow: upload-pack: send shallow info over stdin to pack-objects
2014-03-21Merge branch 'nd/tag-version-sort'Libravatar Junio C Hamano1-5/+66
Allow v1.9.0 sorted before v1.10.0 in "git tag --list" output. * nd/tag-version-sort: tag: support --sort=<spec>
2014-03-21Merge branch 'jk/shallow-update-fix'Libravatar Junio C Hamano1-12/+4
Serving objects from a shallow repository needs to write a new file to hold the temporary shallow boundaries but it was not cleaned when we exit due to die() or a signal. * jk/shallow-update-fix: shallow: verify shallow file after taking lock shallow: automatically clean up shallow tempfiles shallow: use stat_validity to check for up-to-date file
2014-03-18Merge branch 'jc/tag-contains-with'Libravatar Junio C Hamano1-0/+6
* jc/tag-contains-with: tag: grok "--with" as synonym to "--contains"
2014-03-18Merge branch 'jk/repack-pack-keep-objects'Libravatar Junio C Hamano1-1/+12
* jk/repack-pack-keep-objects: repack: add `repack.packKeptObjects` config var
2014-03-18Merge branch 'sh/finish-tmp-packfile'Libravatar Junio C Hamano1-9/+6
* sh/finish-tmp-packfile: finish_tmp_packfile():use strbuf for pathname construction
2014-03-18Merge branch 'dd/use-alloc-grow'Libravatar Junio C Hamano2-10/+4
Replace open-coded reallocation with ALLOC_GROW() macro. * dd/use-alloc-grow: sha1_file.c: use ALLOC_GROW() in pretend_sha1_file() read-cache.c: use ALLOC_GROW() in add_index_entry() builtin/mktree.c: use ALLOC_GROW() in append_to_tree() attr.c: use ALLOC_GROW() in handle_attr_line() dir.c: use ALLOC_GROW() in create_simplify() reflog-walk.c: use ALLOC_GROW() replace_object.c: use ALLOC_GROW() in register_replace_object() patch-ids.c: use ALLOC_GROW() in add_commit() diffcore-rename.c: use ALLOC_GROW() diff.c: use ALLOC_GROW() commit.c: use ALLOC_GROW() in register_commit_graft() cache-tree.c: use ALLOC_GROW() in find_subtree() bundle.c: use ALLOC_GROW() in add_to_ref_list() builtin/pack-objects.c: use ALLOC_GROW() in check_pbase_path()
2014-03-18Merge branch 'jk/clean-d-pathspec'Libravatar Junio C Hamano1-11/+9
"git clean -d pathspec" did not use the given pathspec correctly and ended up cleaning too much. * jk/clean-d-pathspec: clean: simplify dir/not-dir logic clean: respect pathspecs with "-d"
2014-03-18add: use struct argv_array in run_add_interactive()Libravatar Fabian Ruch1-11/+10
run_add_interactive() in builtin/add.c manually computes array bounds and allocates a static args array to build the add--interactive command line, which is error-prone. Use the argv-array helper functions instead. Signed-off-by: Fabian Ruch <bafain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-18merge: fix GIT_EDITOR override for commit hookLibravatar Benoit Pierre1-1/+1
Don't set GIT_EDITOR to ":" when calling prepare-commit-msg hook if the editor is going to be called (e.g. with "merge -e"). Signed-off-by: Benoit Pierre <benoit.pierre@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-18commit: fix patch hunk editing with "commit -p -m"Libravatar Benoit Pierre5-17/+38
Don't change git environment: move the GIT_EDITOR=":" override to the hook command subprocess, like it's already done for GIT_INDEX_FILE. Signed-off-by: Benoit Pierre <benoit.pierre@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-17index-pack: report error using the correct variableLibravatar Junio C Hamano1-2/+2
We feed a string pointer that is potentially NULL to die() when showing the message. Don't. Noticed-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-17pack-objects: turn off bitmaps when skipping objectsLibravatar Jeff King1-1/+11
The pack bitmap format requires that we have a single bit for each object in the pack, and that each object's bitmap represents its complete set of reachable objects. Therefore we have no way to represent the bitmap of an object which references objects outside the pack. We notice this problem while generating the bitmaps, as we try to find the offset of a particular object and realize that we do not have it. In this case we die, and neither the bitmap nor the pack is generated. This is correct, but perhaps a little unfriendly. If you have bitmaps turned on in the config, many repacks will fail which would otherwise succeed. E.g., incremental repacks, repacks with "-l" when you have alternates, ".keep" files. Instead, this patch notices early that we are omitting some objects from the pack and turns off bitmaps (with a warning). Note that this is not strictly correct, as it's possible that the object being omitted is not reachable from any other object in the pack. In practice, this is almost never the case, and there are two advantages to doing it this way: 1. The code is much simpler, as we do not have to cleanly abort the bitmap-generation process midway through. 2. We do not waste time partially generating bitmaps only to find out that some object deep in the history is not being packed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-17pack-objects: show reused packfile objects in "Counting objects"Libravatar Jeff King1-8/+3
When we are sending a pack for push or fetch, we may reuse a chunk of packfile without even parsing it. The progress meter then looks like this: Reusing existing pack: 3440489, done. Counting objects: 3, done. The first line shows that we are reusing a large chunk of objects, and then we further count any objects not included in the reused portion with an actual traversal. These are all implementation details that the user does not need to care about. Instead, we can show the reused objects in the normal "counting..." progress meter (which will simply go much faster than normal), and then continue to add to it as we traverse. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-17pack-objects: show progress for reused packfilesLibravatar Jeff King1-3/+16
When the "--all-progress" option is in effect, pack-objects shows a progress report for the "writing" phase. If the repository has bitmaps and we are reusing a packfile, the user sees no progress update until the whole packfile is sent. Since this is typically the bulk of what is being written, it can look like git hangs during this phase, even though the transfer is proceeding. This generally only happens with "git push" from a repository with bitmaps. We do not use "--all-progress" for fetch (since the result is going to index-pack on the client, which takes care of progress reporting). And for regular repacks to disk, we do not reuse packfiles. We already have the progress meter setup during write_reused_pack; we just need to call display_progress whiel we are writing out the pack. The progress meter is attached to our output descriptor, so it automatically handles the throughput measurements. However, we need to update the object count as we go, since that is what feeds the percentage we show. We aren't actually parsing the packfile as we send it, so we have no idea how many objects we have sent; we only know that at the end of N bytes, we will have sent M objects. So we cheat a little and assume each object is M/N bytes (i.e., the mean of the objects we are sending). While this isn't strictly true, it actually produces a more pleasing progress meter for the user, as it moves smoothly and predictably (and nobody really cares about the object count; they care about the percentage, and the object count is a proxy for that). One alternative would be to actually show two progress meters: one for the reused pack, and one for the rest of the objects. That would more closely reflect the data we have (the first would be measured in bytes, and the second measured in objects). But it would also be more complex and annoying to the user; rather than seeing one progress meter counting up to 100%, they would finish one meter, then start another one at zero. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-17mv: prevent mismatched data when ignoring errors.Libravatar brian m. carlson1-0/+5
We shrink the source and destination arrays, but not the modes or submodule_gitfile arrays, resulting in potentially mismatched data. Shrink all the arrays at the same time to prevent this. Add tests to ensure the problem does not recur. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-14Merge branch 'sh/write-pack-file-warning-message-fix'Libravatar Junio C Hamano1-1/+1
A warning from "git pack-objects" were generated by referring to an incorrect variable when forming the filename that we had trouble with. * sh/write-pack-file-warning-message-fix: write_pack_file: use correct variable in diagnostic
2014-03-14Merge branch 'mh/replace-refs-variable-rename'Libravatar Junio C Hamano6-6/+6
* mh/replace-refs-variable-rename: Document some functions defined in object.c Add docstrings for lookup_replace_object() and do_lookup_replace_object() rename read_replace_refs to check_replace_refs
2014-03-14Merge branch 'nd/i18n-progress'Libravatar Junio C Hamano5-9/+9
Mark the progress indicators from various time-consuming commands for i18n/l10n. * nd/i18n-progress: i18n: mark all progress lines for translation
2014-03-14Merge branch 'jh/note-trees-record-blobs'Libravatar Junio C Hamano1-1/+5
"git notes -C <blob>" should not take an object that is not a blob. * jh/note-trees-record-blobs: notes: disallow reusing non-blob as a note object
2014-03-14Merge branch 'nd/no-more-fnmatch'Libravatar Junio C Hamano10-10/+10
We started using wildmatch() in place of fnmatch(3); complete the process and stop using fnmatch(3). * nd/no-more-fnmatch: actually remove compat fnmatch source code stop using fnmatch (either native or compat) Revert "test-wildmatch: add "perf" command to compare wildmatch and fnmatch" use wildmatch() directly without fnmatch() wrapper
2014-03-14Merge branch 'nd/reset-setup-worktree'Libravatar Junio C Hamano1-3/+4
"git reset" needs to refresh the index when working in a working tree (it can also be used to match the index to the HEAD in an otherwise bare repository), but it failed to set up the working tree properly, causing GIT_WORK_TREE to be ignored. * nd/reset-setup-worktree: reset: optionally setup worktree and refresh index on --mixed
2014-03-14Merge branch 'ks/config-file-stdin'Libravatar Junio C Hamano1-49/+55
"git config" learned to read from the standard input when "-" is given as the value to its "--file" parameter (attempting an operation to update the configuration in the standard input of course is rejected). * ks/config-file-stdin: config: teach "git config --file -" to read from the standard input config: change git_config_with_options() interface builtin/config.c: rename check_blob_write() -> check_write() config: disallow relative include paths from blobs
2014-03-14Merge branch 'jk/janitorial-fixes'Libravatar Junio C Hamano1-1/+2
* jk/janitorial-fixes: open_istream(): do not dereference NULL in the error case builtin/mv: don't use memory after free utf8: use correct type for values in interval table utf8: fix iconv error detection notes-utils: handle boolean notes.rewritemode correctly
2014-03-14Merge branch 'jc/check-attr-honor-working-tree'Libravatar Junio C Hamano1-0/+3
"git check-attr" when (trying to) work on a repository with a working tree did not work well when the working tree was specified via --work-tree (and obviously with --git-dir). The command also works in a bare repository but it reads from the (possibly stale, irrelevant and/or nonexistent) index, which may need to be fixed to read from HEAD, but that is a completely separate issue. As a related tangent to this separate issue, we may want to also fix "check-ignore", which refuses to work in a bare repository, to also operate in a bare one. * jc/check-attr-honor-working-tree: check-attr: move to the top of working tree when in non-bare repository t0003: do not chdir the whole test process
2014-03-13cat-file: restore warn_on_object_refname_ambiguity flagLibravatar Jeff King1-0/+3
Commit 25fba78 turned off the object/refname ambiguity check during "git cat-file --batch" operations. However, this is a global flag, so let's restore it when we are done. This shouldn't make any practical difference, as cat-file exits immediately afterwards, but is good code hygeine and would prevent an unnecessary surprise if somebody starts to call cmd_cat_file later. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-11builtin/mv: fix out of bounds writeLibravatar John Keeping1-0/+4
When commit a88c915 (mv: move submodules using a gitfile, 2013-07-30) added the submodule_gitfile array, it was not added to the block that enlarges the arrays when we are moving a directory so that we do not have to worry about it being a directory when we perform the actual move. After this, the loop continues over the enlarged set of sources. Since we assume that submodule_gitfile has size argc, if any of the items in the source directory are submodules we are guaranteed to write beyond the end of submodule_gitfile. Fix this by realloc'ing submodule_gitfile at the same time as the other arrays. Reported-by: Guillaume Gelin <contact@ramnes.eu> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-11upload-pack: send shallow info over stdin to pack-objectsLibravatar Nguyễn Thái Ngọc Duy1-0/+10
Before cdab485 (upload-pack: delegate rev walking in shallow fetch to pack-objects - 2013-08-16) upload-pack does not write to the source repository. cdab485 starts to write $GIT_DIR/shallow_XXXXXX if it's a shallow fetch, so the source repo must be writable. git:// servers do not need write access to repos and usually don't have it, which means cdab485 breaks shallow clone over git:// Instead of using a temporary file as the media for shallow points, we can send them over stdin to pack-objects as well. Prepend shallow SHA-1 with --shallow so pack-objects knows what is what. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-11clean: simplify dir/not-dir logicLibravatar Jeff King1-9/+6
When we get a list of paths from read_directory, we further prune it to create the final list of items to remove. The code paths for directories and non-directories repeat the same "add to list" code. This patch restructures the code so that we don't repeat ourselves. Also, by following a "if (condition) continue" pattern like the pathspec check above, it makes it more obvious that the conditional is about excluding directories under certain circumstances. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-11clean: respect pathspecs with "-d"Libravatar Jeff King1-2/+3
git-clean uses read_directory to fill in a `struct dir` with potential hits. However, read_directory does not actually check against our pathspec. It uses a simplified version that may turn up false positives. As a result, we need to check that any hits match our pathspec. We do so reliably for non-directories. For directories, if "-d" is not given we check that the pathspec matched exactly (i.e., we are even stricter, and require an explicit "git clean foo" to clean "foo/"). But if "-d" is given, rather than relaxing the exact match to allow a recursive match, we do not check the pathspec at all. This regression was introduced in 113f10f (Make git-clean a builtin, 2007-11-11). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-07Merge branch 'cc/starts-n-ends-with-endgame'Libravatar Junio C Hamano1-1/+1
prefixcmp/suffixcmp are gone.
2014-03-07Merge branch 'gj/push-more-verbose-advice'Libravatar Junio C Hamano1-1/+1
2014-03-07Merge branch 'jc/add-2.0-ignore-removal'Libravatar Junio C Hamano1-57/+12
"git add <pathspec>" is the same as "git add -A <pathspec>" now, i.e. it does not ignore removals from the directory specified.
2014-03-07Merge branch 'jn/add-2.0-u-A-sans-pathspec'Libravatar Junio C Hamano1-106/+9
"git add -u" and "git add -A" without any pathspec is a tree-wide operation now, even when they are run in a subdirectory of the working tree.
2014-03-07Merge branch 'jc/push-2.0-default-to-simple'Libravatar Junio C Hamano1-24/+7
Finally update the "git push" default behaviour to "simple".
2014-03-07tag: grok "--with" as synonym to "--contains"Libravatar Junio C Hamano1-0/+6
Just like "git branch" can be told to list the branches that has the named commit by "git branch --with <commit>", teach the same short-hand to "git tag", so that "git tag --with <commit>" shows the releases with the named commit. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-05Merge branch 'nd/daemonize-gc'Libravatar Junio C Hamano1-5/+18
Allow running "gc --auto" in the background. * nd/daemonize-gc: gc: config option for running --auto in background daemon: move daemonize() to libgit.a
2014-03-03builtin/mktree.c: use ALLOC_GROW() in append_to_tree()Libravatar Dmitry S. Dolzhenko1-4/+1
Helped-by: He Sun <sunheehnus@gmail.com> Signed-off-by: Dmitry S. Dolzhenko <dmitrys.dolzhenko@yandex.ru> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-03builtin/pack-objects.c: use ALLOC_GROW() in check_pbase_path()Libravatar Dmitry S. Dolzhenko1-6/+3
Signed-off-by: Dmitry S. Dolzhenko <dmitrys.dolzhenko@yandex.ru> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-03repack: add `repack.packKeptObjects` config varLibravatar Jeff King1-1/+12
The git-repack command always passes `--honor-pack-keep` to pack-objects. This has traditionally been a good thing, as we do not want to duplicate those objects in a new pack, and we are not going to delete the old pack. However, when bitmaps are in use, it is important for a full repack to include all reachable objects, even if they may be duplicated in a .keep pack. Otherwise, we cannot generate the bitmaps, as the on-disk format requires the set of objects in the pack to be fully closed. Even if the repository does not generally have .keep files, a simultaneous push could cause a race condition in which a .keep file exists at the moment of a repack. The repack may try to include those objects in one of two situations: 1. The pushed .keep pack contains objects that were already in the repository (e.g., blobs due to a revert of an old commit). 2. Receive-pack updates the refs, making the objects reachable, but before it removes the .keep file, the repack runs. In either case, we may prefer to duplicate some objects in the new, full pack, and let the next repack (after the .keep file is cleaned up) take care of removing them. This patch introduces both a command-line and config option to disable the `--honor-pack-keep` option. By default, it is triggered when pack.writeBitmaps (or `--write-bitmap-index` is turned on), but specifying it explicitly can override the behavior (e.g., in cases where you prefer .keep files to bitmaps, but only when they are present). Note that this option just disables the pack-objects behavior. We still leave packs with a .keep in place, as we do not necessarily know that we have duplicated all of their objects. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>