summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2011-10-26Merge branch 'cn/fetch-prune'Libravatar Junio C Hamano2-6/+30
* cn/fetch-prune: fetch: treat --tags like refs/tags/*:refs/tags/* when pruning fetch: honor the user-provided refspecs when pruning refs remote: separate out the remote_find_tracking logic into query_refspecs t5510: add tests for fetch --prune fetch: free all the additional refspecs Conflicts: remote.c
2011-10-21Merge branch 'jc/match-refs-clarify'Libravatar Junio C Hamano2-4/+4
* jc/match-refs-clarify: rename "match_refs()" to "match_push_refs()" send-pack: typofix error message
2011-10-21Merge branch 'jk/maint-pack-objects-compete-with-delete'Libravatar Junio C Hamano1-0/+4
* jk/maint-pack-objects-compete-with-delete: downgrade "packfile cannot be accessed" errors to warnings pack-objects: protect against disappearing packs
2011-10-19Merge branch 'js/merge-edit-option'Libravatar Junio C Hamano1-39/+70
* js/merge-edit-option: Teach merge the '[-e|--edit]' option Conflicts: builtin/merge.c
2011-10-19Merge branch 'js/no-cherry-pick-head-after-punted'Libravatar Junio C Hamano1-7/+16
* js/no-cherry-pick-head-after-punted: cherry-pick: do not give irrelevant advice when cherry-pick punted revert.c: defer writing CHERRY_PICK_HEAD till it is safe to do so
2011-10-19Merge branch 'jm/maint-apply-detects-corrupt-patch-header'Libravatar Junio C Hamano1-0/+3
* jm/maint-apply-detects-corrupt-patch-header: fix "git apply --index ..." not to deref NULL
2011-10-17Merge branch 'bc/attr-ignore-case'Libravatar Junio C Hamano2-1/+7
* bc/attr-ignore-case: attr.c: respect core.ignorecase when matching attribute patterns attr: read core.attributesfile from git_default_core_config builtin/mv.c: plug miniscule memory leak cleanup: use internal memory allocation wrapper functions everywhere attr.c: avoid inappropriate access to strbuf "buf" member Conflicts: transport-helper.c
2011-10-17Merge branch 'mm/maint-config-explicit-bool-display'Libravatar Junio C Hamano1-7/+13
* mm/maint-config-explicit-bool-display: config: display key_delim for config --bool --get-regexp
2011-10-17Merge branch 'tc/fetch-leak'Libravatar Junio C Hamano1-4/+9
* tc/fetch-leak: fetch: plug two leaks on error exit in store_updated_refs Conflicts: builtin/fetch.c
2011-10-17Merge branch 'ph/push-to-delete-nothing'Libravatar Junio C Hamano1-8/+18
* ph/push-to-delete-nothing: receive-pack: don't pass non-existent refs to post-{receive,update} hooks Conflicts: builtin/receive-pack.c
2011-10-17Merge branch 'jc/checkout-from-tree-keep-local-changes'Libravatar Junio C Hamano1-1/+5
* jc/checkout-from-tree-keep-local-changes: checkout $tree $path: do not clobber local changes in $path not in $tree
2011-10-15fetch: treat --tags like refs/tags/*:refs/tags/* when pruningLibravatar Carlos Martín Nieto1-2/+21
If --tags is specified, add that refspec to the list given to prune_refs so it knows to treat it as a filter on what refs to should consider for prunning. This way git fetch --prune --tags origin only prunes tags and doesn't delete the branch refs. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-15fetch: honor the user-provided refspecs when pruning refsLibravatar Carlos Martín Nieto2-5/+10
If the user gave us refspecs on the command line, we should use those when deciding whether to prune a ref instead of relying on the refspecs in the config. Previously, running git fetch --prune origin refs/heads/master:refs/remotes/origin/master would delete every other ref under the origin namespace because we were using the refspec to filter the available refs but using the configured refspec to figure out if a ref had been deleted on the remote. This is clearly the wrong thing to do. Change prune_refs and get_stale_heads to simply accept a list of references and a list of refspecs. The caller of either function needs to decide what refspecs should be used to decide whether a ref is stale. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-15Merge branch 'jc/grep-untracked-exclude'Libravatar Junio C Hamano1-1/+1
* jc/grep-untracked-exclude: grep: fix the error message that mentions --exclude
2011-10-15Merge branch 'jc/maint-grep-untracked-exclude' into jc/grep-untracked-excludeLibravatar Junio C Hamano1-1/+1
* jc/maint-grep-untracked-exclude: grep: fix the error message that mentions --exclude Conflicts: builtin/grep.c
2011-10-14downgrade "packfile cannot be accessed" errors to warningsLibravatar Jeff King1-1/+1
These can happen if another process simultaneously prunes a pack. But that is not usually an error condition, because a properly-running prune should have repacked the object into a new pack. So we will notice that the pack has disappeared unexpectedly, print a message, try other packs (possibly after re-scanning the list of packs), and find it in the new pack. Acked-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-14pack-objects: protect against disappearing packsLibravatar Jeff King1-0/+4
It's possible that while pack-objects is running, a simultaneously running prune process might delete a pack that we are interested in. Because we load the pack indices early on, we know that the pack contains our item, but by the time we try to open and map it, it is gone. Since c715f78, we already protect against this in the normal object access code path, but pack-objects accesses the packs at a lower level. In the normal access path, we call find_pack_entry, which will call find_pack_entry_one on each pack index, which does the actual lookup. If it gets a hit, we will actually open and verify the validity of the matching packfile (using c715f78's is_pack_valid). If we can't open it, we'll issue a warning and pretend that we didn't find it, causing us to go on to the next pack (or on to loose objects). Furthermore, we will cache the descriptor to the opened packfile. Which means that later, when we actually try to access the object, we are likely to still have that packfile opened, and won't care if it has been unlinked from the filesystem. Notice the "likely" above. If there is another pack access in the interim, and we run out of descriptors, we could close the pack. And then a later attempt to access the closed pack could fail (we'll try to re-open it, of course, but it may have been deleted). In practice, this doesn't happen because we tend to look up items and then access them immediately. Pack-objects does not follow this code path. Instead, it accesses the packs at a much lower level, using find_pack_entry_one directly. This means we skip the is_pack_valid check, and may end up with the name of a packfile, but no open descriptor. We can add the same is_pack_valid check here. Unfortunately, the access patterns of pack-objects are not quite as nice for keeping lookup and object access together. We look up each object as we find out about it, and the only later when writing the packfile do we necessarily access it. Which means that the opened packfile may be closed in the interim. In practice, however, adding this check still has value, for three reasons. 1. If you have a reasonable number of packs and/or a reasonable file descriptor limit, you can keep all of your packs open simultaneously. If this is the case, then the race is impossible to trigger. 2. Even if you can't keep all packs open at once, you may end up keeping the deleted one open (i.e., you may get lucky). 3. The race window is shortened. You may notice early that the pack is gone, and not try to access it. Triggering the problem without this check means deleting the pack any time after we read the list of index files, but before we access the looked-up objects. Triggering it with this check means deleting the pack means deleting the pack after we do a lookup (and successfully access the packfile), but before we access the object. Which is a smaller window. Acked-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-13Merge branch 'il/archive-err-signal'Libravatar Junio C Hamano1-0/+2
* il/archive-err-signal: Support ERR in remote archive like in fetch/push
2011-10-13Merge branch 'jc/grep-untracked-exclude'Libravatar Junio C Hamano1-7/+17
* jc/grep-untracked-exclude: grep: teach --untracked and --exclude-standard options
2011-10-13Merge branch 'rs/pending'Libravatar Junio C Hamano1-28/+18
* rs/pending: commit: factor out clear_commit_marks_for_object_array checkout: use leak_pending flag bundle: use leak_pending flag bisect: use leak_pending flag revision: add leak_pending flag checkout: use add_pending_{object,sha1} in orphan check revision: factor out add_pending_sha1 checkout: check for "Previous HEAD" notice in t2020 Conflicts: builtin/checkout.c revision.c
2011-10-13Merge branch 'jc/apply-blank-at-eof-fix'Libravatar Junio C Hamano1-2/+9
* jc/apply-blank-at-eof-fix: apply --whitespace=error: correctly report new blank lines at end
2011-10-13Merge branch 'nd/maint-autofix-tag-in-head'Libravatar Junio C Hamano3-59/+66
* nd/maint-autofix-tag-in-head: Accept tags in HEAD or MERGE_HEAD merge: remove global variable head[] merge: use return value of resolve_ref() to determine if HEAD is invalid merge: keep stash[] a local variable Conflicts: builtin/merge.c
2011-10-13Merge branch 'bw/grep-no-index-no-exclude'Libravatar Junio C Hamano1-3/+3
* bw/grep-no-index-no-exclude: grep --no-index: don't use git standard exclusions grep: do not use --index in the short usage output
2011-10-12Teach merge the '[-e|--edit]' optionLibravatar Jay Soffian1-39/+70
Implemented internally instead of as "git merge --no-commit && git commit" so that "merge --edit" is otherwise consistent (hooks, etc) with "merge". Note: the edit message does not include the status information that one gets with "commit --status" and it is cleaned up after editing like one gets with "commit --cleanup=default". A later patch could add the status information if desired. Note: previously we were not calling stripspace() after running the prepare-commit-msg hook. Now we are, stripping comments and leading/trailing whitespace lines if --edit is given, otherwise only stripping leading/trailing whitespace lines if not given --edit. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-12Merge branch 'jc/parse-options-boolean'Libravatar Junio C Hamano2-10/+3
* jc/parse-options-boolean: apply: use OPT_NOOP_NOARG revert: use OPT_NOOP_NOARG parseopt: add OPT_NOOP_NOARG archive.c: use OPT_BOOL() parse-options: deprecate OPT_BOOLEAN Conflicts: builtin/revert.c
2011-10-12Merge branch 'rs/name-rev-usage'Libravatar Junio C Hamano1-1/+3
* rs/name-rev-usage: name-rev: split usage string
2011-10-12fix "git apply --index ..." not to deref NULLLibravatar Jim Meyering1-0/+3
I noticed this when "git am CORRUPTED" unexpectedly failed with an odd diagnostic, and even removed one of the files it was supposed to have patched. Reproduce with any valid old/new patch from which you have removed the "+++ b/FILE" line. You'll see a diagnostic like this fatal: unable to write file '(null)' mode 100644: Bad address and you'll find that FILE has been removed. The above is on glibc-based systems. On other systems, rather than getting "null", you may provoke a segfault as git tries to dereference the NULL file name. Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-10Merge branch 'mh/check-ref-format-3'Libravatar Junio C Hamano7-29/+46
* mh/check-ref-format-3: (23 commits) add_ref(): verify that the refname is formatted correctly resolve_ref(): expand documentation resolve_ref(): also treat a too-long SHA1 as invalid resolve_ref(): emit warnings for improperly-formatted references resolve_ref(): verify that the input refname has the right format remote: avoid passing NULL to read_ref() remote: use xstrdup() instead of strdup() resolve_ref(): do not follow incorrectly-formatted symbolic refs resolve_ref(): extract a function get_packed_ref() resolve_ref(): turn buffer into a proper string as soon as possible resolve_ref(): only follow a symlink that contains a valid, normalized refname resolve_ref(): use prefixcmp() resolve_ref(): explicitly fail if a symlink is not readable Change check_refname_format() to reject unnormalized refnames Inline function refname_format_print() Make collapse_slashes() allocate memory for its result Do not allow ".lock" at the end of any refname component Refactor check_refname_format() Change check_ref_format() to take a flags argument Change bad_ref_char() to return a boolean value ...
2011-10-10Merge branch 'mz/remote-rename'Libravatar Junio C Hamano1-7/+21
* mz/remote-rename: remote: only update remote-tracking branch if updating refspec remote rename: warn when refspec was not updated remote: "rename o foo" should not rename ref "origin/bar" remote: write correct fetch spec when renaming remote 'remote'
2011-10-10Merge branch 'cb/common-prefix-unification'Libravatar Junio C Hamano2-3/+4
* cb/common-prefix-unification: rename pathspec_prefix() to common_prefix() and move to dir.[ch] consolidate pathspec_prefix and common_prefix remove prefix argument from pathspec_prefix
2011-10-10Merge branch 'fg/submodule-git-file-git-dir'Libravatar Junio C Hamano1-0/+8
* fg/submodule-git-file-git-dir: Move git-dir for submodules rev-parse: add option --resolve-git-dir <path> Conflicts: cache.h git-submodule.sh
2011-10-10config: display key_delim for config --bool --get-regexpLibravatar Matthieu Moy1-7/+13
The previous logic in show_config was to print the delimiter when the value was set, but Boolean variables have an implicit value "true" when they appear with no value in the config file. As a result, we got: git_Config --get-regexp '.*\.Boolean' #1. Ok: example.boolean git_Config --bool --get-regexp '.*\.Boolean' #2. NO: example.booleantrue Fix this by defering the display of the separator until after the value to display has been computed. Reported-by: Brian Foster <brian.foster@maxim-ic.com> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-09Fix some "variable might be used uninitialized" warningsLibravatar Ramsay Jones1-1/+1
In particular, gcc complains as follows: CC tree-walk.o tree-walk.c: In function `traverse_trees': tree-walk.c:347: warning: 'e' might be used uninitialized in this \ function CC builtin/revert.o builtin/revert.c: In function `verify_opt_mutually_compatible': builtin/revert.c:113: warning: 'opt2' might be used uninitialized in \ this function Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-07fetch: plug two leaks on error exit in store_updated_refsLibravatar Tay Ray Chuan1-4/+9
Close FETCH_HEAD and release the string url even if we have to leave the function store_updated_refs() early. Reported-by: Chris Wilson <cwilson@vigilantsw.com> Helped-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-07fetch: free all the additional refspecsLibravatar Carlos Martín Nieto1-1/+1
Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-06Merge branch 'js/maint-no-cherry-pick-head-after-punted' into ↵Libravatar Junio C Hamano1-7/+16
js/no-cherry-pick-head-after-punted * js/maint-no-cherry-pick-head-after-punted: cherry-pick: do not give irrelevant advice when cherry-pick punted revert.c: defer writing CHERRY_PICK_HEAD till it is safe to do so Conflicts: builtin/revert.c
2011-10-06cherry-pick: do not give irrelevant advice when cherry-pick puntedLibravatar Jay Soffian1-5/+7
If a cherry-pick did not even start because the working tree had local changes that would overlap with the operation, we shouldn't be advising the users to resolve conflicts nor to conclude it with "git commit". Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-06revert.c: defer writing CHERRY_PICK_HEAD till it is safe to do soLibravatar Jay Soffian1-2/+9
do_pick_commit() writes out CHERRY_PICK_HEAD before invoking merge (either via do_recursive_merge() or try_merge_command()) on the assumption that if the merge fails it is due to conflict. However, if the tree is dirty, the merge may not even start, aborting before do_pick_commit() can remove CHERRY_PICK_HEAD. Instead, defer writing CHERRY_PICK_HEAD till after merge has returned. At this point we know the merge has either succeeded or failed due to conflict. In either case, we want CHERRY_PICK_HEAD to be written so that it may be picked up by the subsequent invocation of commit. Note that do_recursive_merge() aborts if the merge cannot start, while try_merge_command() returns a non-zero value other than 1. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-06attr: read core.attributesfile from git_default_core_configLibravatar Junio C Hamano1-0/+2
This code calls git_config from a helper function to parse the config entry it is interested in. Calling git_config in this way may cause a problem if the helper function can be called after a previous call to git_config by another function since the second call to git_config may reset some variable to the value in the config file which was previously overridden. The above is not a problem in this case since the function passed to git_config only parses one config entry and the variable it sets is not assigned outside of the parsing function. But a programmer who desires all of the standard config options to be parsed may be tempted to modify git_attr_config() so that it falls back to git_default_config() and then it _would_ be vulnerable to the above described behavior. So, move the call to git_config up into the top-level cmd_* function and move the responsibility for parsing core.attributesfile into the main config file parser. Which is only the logical thing to do ;-) Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-06builtin/mv.c: plug miniscule memory leakLibravatar Brandon Casey1-1/+5
The "it" string would not be free'ed if base_name was non-NULL. Let's free it. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-06cleanup: use internal memory allocation wrapper functions everywhereLibravatar Brandon Casey1-1/+1
The "x"-prefixed versions of strdup, malloc, etc. will check whether the allocation was successful and terminate the process otherwise. A few uses of malloc were left alone since they already implemented a graceful path of failure or were in a quasi external library like xdiff. Additionally, the call to malloc in compat/win32/syslog.c was not modified since the syslog() implemented there is a die handler and a call to the x-wrappers within a die handler could result in recursion should memory allocation fail. This will have to be addressed separately. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-05Change check_refname_format() to reject unnormalized refnamesLibravatar Michael Haggerty1-8/+7
Since much of the infrastructure does not work correctly with unnormalized refnames, change check_refname_format() to reject them. Similarly, change "git check-ref-format" to reject unnormalized refnames by default. But add an option --normalize, which causes "git check-ref-format" to normalize the refname before checking its format, and print the normalized refname. This is exactly the behavior of the old --print option, which is retained but deprecated. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-05Inline function refname_format_print()Libravatar Michael Haggerty1-9/+7
Soon we will make printing independent of collapsing. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-05Make collapse_slashes() allocate memory for its resultLibravatar Michael Haggerty1-9/+10
This will make upcoming changes a tiny bit easier. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-05Change check_ref_format() to take a flags argumentLibravatar Michael Haggerty7-27/+8
Change check_ref_format() to take a flags argument that indicates what is acceptable in the reference name (analogous to "git check-ref-format"'s "--allow-onelevel" and "--refspec-pattern"). This is more convenient for callers and also fixes a failure in the test suite (and likely elsewhere in the code) by enabling "onelevel" and "refspec-pattern" to be allowed independently of each other. Also rename check_ref_format() to check_refname_format() to make it obvious that it deals with refnames rather than references themselves. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-05git check-ref-format: add options --allow-onelevel and --refspec-patternLibravatar Michael Haggerty1-9/+47
Also add tests of the new options. (Actually, one big reason to add the new options is to make it easy to test check_ref_format(), though the options should also be useful to other scripts.) Interpret the result of check_ref_format() based on which types of refnames are allowed. However, because check_ref_format() can only return a single value, one test case is still broken. Specifically, the case "git check-ref-format --onelevel '*'" incorrectly succeeds because check_ref_format() returns CHECK_REF_FORMAT_ONELEVEL for this refname even though the refname is also CHECK_REF_FORMAT_WILDCARD. The type of check that leads to this failure is used elsewhere in "real" code and could lead to bugs; it will be fixed over the next few commits. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-05Merge branch 'js/check-attr-cached'Libravatar Junio C Hamano1-0/+5
* js/check-attr-cached: t0003: remove extra whitespaces Teach '--cached' option to check-attr
2011-10-05Merge branch 'jc/ls-remote-short-help'Libravatar Junio C Hamano1-0/+3
* jc/ls-remote-short-help: ls-remote: a lone "-h" is asking for help
2011-10-05Merge branch 'jk/argv-array'Libravatar Junio C Hamano1-19/+8
* jk/argv-array: run_hook: use argv_array API checkout: use argv_array API bisect: use argv_array API quote: provide sq_dequote_to_argv_array refactor argv_array into generic code quote.h: fix bogus comment add sha1_array API docs
2011-10-05Merge branch 'mg/branch-list'Libravatar Junio C Hamano2-19/+42
* mg/branch-list: t3200: clean up checks for file existence branch: -v does not automatically imply --list branch: allow pattern arguments branch: introduce --list option git-branch: introduce missing long forms for the options git-tag: introduce long forms for the options t6040: test branch -vv Conflicts: Documentation/git-tag.txt t/t3200-branch.sh