summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2012-01-18diff-index: enable recursive pathspec matching in unpack_treesLibravatar Nguyen Thai Ngoc Duy1-0/+8
The pathspec structure has a few bits of data to drive various operation modes after we unified the pathspec matching logic in various codepaths. For example, max_depth field is there so that "git grep" can limit the output for files found in limited depth of tree traversal. Also in order to show just the surface level differences in "git diff-tree", recursive field stops us from descending into deeper level of the tree structure when it is set to false, and this also affects pathspec matching when we have wildcards in the pathspec. The diff-index has always wanted the recursive behaviour, and wanted to match pathspecs without any depth limit. But we forgot to do so when we updated tree_entry_interesting() logic to unify the pathspec matching logic. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-11Merge branch 'maint-1.7.6' into maint-1.7.7Libravatar Junio C Hamano1-1/+1
* maint-1.7.6: attr: fix leak in free_attr_elem t2203: fix wrong commit command
2012-01-11t2203: fix wrong commit commandLibravatar Nguyễn Thái Ngọc Duy1-1/+1
Add commit message to avoid commit's aborting due to the lack of commit message, not because there are INTENT_TO_ADD entries in index. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-10Merge the attributes fix in from maint-1.6.6 branchLibravatar Junio C Hamano1-0/+10
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-10attr: don't confuse prefixes with leading directoriesLibravatar Jeff King1-0/+10
When we prepare the attribute stack for a lookup on a path, we start with the cached stack from the previous lookup (because it is common to do several lookups in the same directory hierarchy). So the first thing we must do in preparing the stack is to pop any entries that point to directories we are no longer interested in. For example, if our stack contains gitattributes for: foo/bar/baz foo/bar foo but we want to do a lookup in "foo/bar/bleep", then we want to pop the top element, but retain the others. To do this we walk down the stack from the top, popping elements that do not match our lookup directory. However, the test do this simply checked strncmp, meaning we would mistake "foo/bar/baz" as a leading directory of "foo/bar/baz_plus". We must also check that the character after our match is '/', meaning we matched the whole path component. There are two special cases to consider: 1. The top of our attr stack has the empty path. So we must not check for '/', but rather special-case the empty path, which always matches. 2. Typically when matching paths in this way, you would also need to check for a full string match (i.e., the character after is '\0'). We don't need to do so in this case, though, because our path string is actually just the directory component of the path to a file (i.e., we know that it terminates with "/", because the filename comes after that). Helped-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-01Merge branch 'rs/maint-estimate-cache-size' into maintLibravatar Junio C Hamano1-1/+1
* rs/maint-estimate-cache-size: t7511: avoid use of reserved filename on Windows.
2011-11-01Merge branch 'bc/attr-ignore-case' into maintLibravatar Junio C Hamano1-1/+58
* 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: remote.c
2011-11-01Merge branch 'cn/fetch-prune' into maintLibravatar Junio C Hamano1-0/+50
* 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
2011-10-31t7511: avoid use of reserved filename on Windows.Libravatar Pat Thoyts1-1/+1
PRN is a special filename on Windows to send data to the printer. As this is generated during test 3 substitute an alternate prefix to avoid this. Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-27Merge branch 'rs/maint-estimate-cache-size' into maintLibravatar Junio C Hamano1-0/+50
* rs/maint-estimate-cache-size: read-cache.c: fix index memory allocation
2011-10-26Merge branch 'maint-1.7.6' into maintLibravatar Junio C Hamano4-18/+85
* maint-1.7.6: notes_merge_commit(): do not pass temporary buffer to other function gitweb: Fix links to lines in blobs when javascript-actions are enabled mergetool: no longer need to save standard input mergetool: Use args as pathspec to unmerged files t9159-*.sh: skip for mergeinfo test for svn <= 1.4 date.c: Support iso8601 timezone formats 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-26Merge branch 'jm/mergetool-pathspec' into maint-1.7.6Libravatar Junio C Hamano1-18/+40
* jm/mergetool-pathspec: mergetool: no longer need to save standard input mergetool: Use args as pathspec to unmerged files
2011-10-26Merge branch 'mz/remote-rename' into maint-1.7.6Libravatar Junio C Hamano1-0/+31
* 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-26Merge branch 'rj/maint-t9159-svn-rev-notation' into maint-1.7.6Libravatar Junio C Hamano1-0/+8
* rj/maint-t9159-svn-rev-notation: t9159-*.sh: skip for mergeinfo test for svn <= 1.4
2011-10-26Merge branch 'hl/iso8601-more-zone-formats' into maint-1.7.6Libravatar Junio C Hamano1-0/+6
* hl/iso8601-more-zone-formats: date.c: Support iso8601 timezone formats
2011-10-26Merge branch 'maint-1.7.6' into maintLibravatar Junio C Hamano2-0/+6
* maint-1.7.6: make the sample pre-commit hook script reject names with newlines, too git-read-tree.txt: update sparse checkout examples git-read-tree.txt: correct sparse-checkout and skip-worktree description git-read-tree.txt: language and typography fixes unpack-trees: print "Aborting" to stderr Documentation/git-update-index: refer to 'ls-files' Documentation: basic configuration of notes.rewriteRef
2011-10-26Merge branch 'mg/maint-doc-sparse-checkout' into maint-1.7.6Libravatar Junio C Hamano2-0/+6
* mg/maint-doc-sparse-checkout: git-read-tree.txt: correct sparse-checkout and skip-worktree description git-read-tree.txt: language and typography fixes unpack-trees: print "Aborting" to stderr
2011-10-26read-cache.c: fix index memory allocationLibravatar René Scharfe1-0/+50
estimate_cache_size() tries to guess how much memory is needed for the in-memory representation of an index file. It does that by using the file size, the number of entries and the difference of the sizes of the on-disk and in-memory structs -- without having to check the length of the name of each entry, which varies for each entry, but their sums are the same no matter the representation. Except there can be a difference. First of all, the size is really calculated by ce_size and ondisk_ce_size based on offsetof(..., name), not sizeof, which can be different. And entries are padded with 1 to 8 NULs at the end (after the variable name) to make their total length a multiple of eight. So in order to allocate enough memory to hold the index, change the delta calculation to be based on offsetof(..., name) and round up to the next multiple of eight. On a 32-bit Linux, this delta was used before: sizeof(struct cache_entry) == 72 sizeof(struct ondisk_cache_entry) == 64 --- 8 The actual difference for an entry with a filename length of one was, however (find the definitions are in cache.h): offsetof(struct cache_entry, name) == 72 offsetof(struct ondisk_cache_entry, name) == 62 ce_size == (72 + 1 + 8) & ~7 == 80 ondisk_ce_size == (62 + 1 + 8) & ~7 == 64 --- 16 So eight bytes less had been allocated for such entries. The new formula yields the correct delta: (72 - 62 + 7) & ~7 == 16 Reported-by: John Hsing <tsyj2007@gmail.com> Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-21Merge branch 'jm/maint-apply-detects-corrupt-patch-header' into maintLibravatar Junio C Hamano1-0/+43
* jm/maint-apply-detects-corrupt-patch-header: fix "git apply --index ..." not to deref NULL
2011-10-21Merge branch 'jc/checkout-from-tree-keep-local-changes' into maintLibravatar Junio C Hamano1-0/+42
* jc/checkout-from-tree-keep-local-changes: checkout $tree $path: do not clobber local changes in $path not in $tree
2011-10-21Merge branch 'mm/maint-config-explicit-bool-display' into maintLibravatar Junio C Hamano1-0/+6
* mm/maint-config-explicit-bool-display: config: display key_delim for config --bool --get-regexp
2011-10-15fetch: treat --tags like refs/tags/*:refs/tags/* when pruningLibravatar Carlos Martín Nieto1-2/+2
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 Nieto1-2/+2
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 'bk/ancestry-path' into maintLibravatar Junio C Hamano1-0/+38
* bk/ancestry-path: t6019: avoid refname collision on case-insensitive systems revision: do not include sibling history in --ancestry-path output revision: keep track of the end-user input from the command line rev-list: Demonstrate breakage with --ancestry-path --all
2011-10-15Merge branch 'tr/mergetool-valgrind' into maintLibravatar Junio C Hamano1-0/+2
* tr/mergetool-valgrind: Symlink mergetools scriptlets into valgrind wrappers
2011-10-15Merge branch 'mm/rebase-i-exec-edit' into maintLibravatar Junio C Hamano1-0/+14
* mm/rebase-i-exec-edit: rebase -i: notice and warn if "exec $cmd" modifies the index or the working tree rebase -i: clean error message for --continue after failed exec
2011-10-14t1304: fall back to $USER if $LOGNAME is not definedLibravatar René Scharfe1-0/+5
For some reason $LOGNAME is not set anymore for me after an upgrade from Ubuntu 11.04 to 11.10. Use $USER in such a case. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-12fix "git apply --index ..." not to deref NULLLibravatar Jim Meyering1-0/+43
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-11attr.c: respect core.ignorecase when matching attribute patternsLibravatar Brandon Casey1-1/+58
When core.ignorecase is true, the file globs configured in the .gitattributes file should be matched case-insensitively against the paths in the working directory. Let's do so. Plus, add some tests. The last set of tests is performed only on a case-insensitive filesystem. Those tests make sure that git handles the case where the .gitignore file resides in a subdirectory and the user supplies a path that does not match the case in the filesystem. In that case^H^H^H^Hsituation, part of the path supplied by the user is effectively interpreted case-insensitively, and part of it is dependent on the setting of core.ignorecase. git will currently only match the portion of the path below the directory holding the .gitignore file according to the setting of core.ignorecase. This is also partly future-proofing. Currently, git builds the attr stack based on the path supplied by the user, so we don't have to do anything special (like use strcmp_icase) to handle the parts of that path that don't match the filesystem with respect to case. If git instead built the attr stack by scanning the repository, then the paths in the origin field would not necessarily match the paths supplied by the user. If someone makes a change like that in the future, these tests will notice. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-10config: display key_delim for config --bool --get-regexpLibravatar Matthieu Moy1-0/+6
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-07t5510: add tests for fetch --pruneLibravatar Carlos Martín Nieto1-0/+50
The failures will be fixed in later commits. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-30checkout $tree $path: do not clobber local changes in $path not in $treeLibravatar Junio C Hamano1-0/+42
Checking paths out of a tree is (currently) defined to do: - Grab the paths from the named tree that match the given pathspec, and add them to the index; - Check out the contents from the index for paths that match the pathspec to the working tree; and while at it - If the given pathspec did not match anything, suspect a typo from the command line and error out without updating the index nor the working tree. Suppose that the branch you are working on has dir/myfile, and the "other" branch has dir/other but not dir/myfile. Further imagine that you have either modified or removed dir/myfile in your working tree, but you have not run "git add dir/myfile" or "git rm dir/myfile" to tell Git about your local change. Running $ git checkout other dir would add dir/other to the index with the contents taken out of the "other" branch, and check out the paths from the index that match the pathspec "dir", namely, "dir/other" and "dir/myfile", overwriting your local changes to "dir/myfile", even though "other" branch does not even know about that file. Fix it by updating the working tree only with the index entries that was read from the "other" tree. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-26mergetool: Use args as pathspec to unmerged filesLibravatar Jonathon Mah1-18/+40
Mergetool now treats its path arguments as a pathspec (like other git subcommands), restricting action to the given files and directories. Files matching the pathspec are filtered so mergetool only acts on unmerged paths; previously it would assume each path argument was in an unresolved state, and get confused when it couldn't check out their other stages. Running "git mergetool subdir" will prompt to resolve all conflicted blobs under subdir. Signed-off-by: Jonathon Mah <me@JonathonMah.com> Acked-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-23Merge branch 'cb/maint-ls-files-error-report' into maintLibravatar Junio C Hamano1-0/+72
* cb/maint-ls-files-error-report: t3005: do not assume a particular order of stdout and stderr of git-ls-files ls-files: fix pathspec display on error
2011-09-23Merge branch 'jc/maint-clone-alternates' into maintLibravatar Junio C Hamano1-0/+23
* jc/maint-clone-alternates: clone: clone from a repository with relative alternates clone: allow more than one --reference
2011-09-23Merge branch 'nd/maint-clone-gitdir' into maintLibravatar Junio C Hamano1-0/+4
* nd/maint-clone-gitdir: clone: allow to clone from .git file read_gitfile_gently(): rename misnamed function to read_gitfile()
2011-09-23Merge branch 'mh/check-ref-format-print-normalize' into maintLibravatar Junio C Hamano1-0/+9
* mh/check-ref-format-print-normalize: Forbid DEL characters in reference names check-ref-format --print: Normalize refnames that start with slashes
2011-09-23Merge branch 'mg/branch-set-upstream-previous' into maintLibravatar Junio C Hamano1-0/+14
* mg/branch-set-upstream-previous: branch.c: use the parsed branch name
2011-09-21unpack-trees: print "Aborting" to stderrLibravatar Michael J Gruber2-0/+6
display_error_msgs() prints all the errors to stderr already (if any), followed by "Aborting" (if any) to stdout. Make the latter go to stderr instead. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-21t9159-*.sh: skip for mergeinfo test for svn <= 1.4Libravatar Ramsay Jones1-0/+8
t9159 relies on the command-line syntax of svn >= 1.5. Given the declining install base of older svn versions, it is not worth our time to support older svn syntax. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-19Merge branch 'ph/format-patch-no-color'Libravatar Junio C Hamano1-4/+4
* ph/format-patch-no-color: t4014: clean up format.thread config after each test
2011-09-19t4014: clean up format.thread config after each testLibravatar Jeff King1-4/+4
The threading tests turn on format.thread, but never clean up after themselves, meaning that later tests will also have format.thread set. This is more annoying than most leftover config, too, because not only does it impact the results of other tests, but it does so non-deterministically. Threading requires the generation of message-ids, which incorporate the current time, meaning a slow-running test script may generate different results from run to run. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-16Merge branch 'ci/forbid-unwanted-current-branch-update'Libravatar Junio C Hamano1-0/+13
* ci/forbid-unwanted-current-branch-update: branch --set-upstream: regression fix
2011-09-16branch --set-upstream: regression fixLibravatar Junio C Hamano1-0/+13
The "git branch" command, while not in listing mode, calls create_branch() even when the target branch already exists, and it does so even when it is not interested in updating the value of the branch (i.e. the name of the commit object that sits at the tip of the existing branch). This happens when the command is run with "--set-upstream" option. The earlier safety-measure to prevent "git branch -f $branch $commit" from updating the currently checked out branch did not take it into account, and we no longer can update the tracking information of the current branch. Minimally fix this regression by telling the validation code if it is called to really update the value of a potentially existing branch, or if the caller merely is interested in updating auxiliary aspects of a branch. Reported-and-Tested-by: Jay Soffian Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-16Disambiguate duplicate t9160* testsLibravatar Frédéric Heitzmann2-1/+1
1e5814f created t9160-git-svn-mergeinfo-push.sh on 11/9/7 40a1530 created t9160-git-svn-preserve-empty-dirs.sh on 11/7/20 The former test script is renumbered to t9161. Signed-off-by: Frédéric Heitzmann <frederic.heitzmann@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-15t6019: avoid refname collision on case-insensitive systemsLibravatar Thomas Rast1-8/+11
The criss-cross tests kept failing for me because of collisions of 'a' with 'A' etc. Prefix the lowercase refnames with an extra letter to disambiguate. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Acked-by: Brad King <brad.king@kitware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-14Merge branch 'ph/format-patch-no-color'Libravatar Junio C Hamano1-0/+8
* ph/format-patch-no-color: format-patch: ignore ui.color
2011-09-13git-svn: teach git-svn to populate svn:mergeinfoLibravatar Bryan Jacobs2-0/+478
Allow git-svn to populate the svn:mergeinfo property automatically in a narrow range of circumstances. Specifically, when dcommitting a revision with multiple parents, all but (potentially) the first of which have been committed to SVN in the same repository as the target of the dcommit. In this case, the merge info is the union of that given by each of the parents, plus all changes introduced to the first parent by the other parents. In all other cases where a revision to be committed has multiple parents, cause "git svn dcommit" to raise an error rather than completing the commit and potentially losing history information in the upstream SVN repository. This behavior is disabled by default, and can be enabled by setting the svn.pushmergeinfo config option. [ew: minor style changes and manpage merge fix] Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Bryan Jacobs <bjacobs@woti.com>
2011-09-12date.c: Support iso8601 timezone formatsLibravatar Haitao Li1-0/+6
Timezone designators in the following formats are all valid according to ISO8601:2004, section 4.3.2: [+-]hh, [+-]hhmm, [+-]hh:mm but we have ignored the ones with colon so far. Signed-off-by: Haitao Li <lihaitao@gmail.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-12format-patch: ignore ui.colorLibravatar Pang Yan Han1-0/+8
commit c9bfb953 (want_color: automatically fallback to color.ui, 2011-08-17) introduced a regression where format-patch produces colorized patches when color.ui is set to "always". In f3aafa4 (Disable color detection during format-patch, 2006-07-09), git_format_config was taught to intercept diff.color to avoid passing it down to git_log_config and later, git_diff_ui_config. Teach git_format_config to intercept color.ui in the same way. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Pang Yan Han <pangyanhan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>