summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2011-11-01name-hash.c: always initialize dir_next pointerLibravatar Johannes Sixt1-1/+1
Test t2021-checkout-overwrite.sh reveals a segfault in 'git add' on a case-insensitive file system when git is compiled with XMALLOC_POISON defined. The reason is that 2548183b (fix phantom untracked files when core.ignorecase is set) added a new member dir_next to struct cache_entry, but forgot to initialize it in all cases. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-07fix phantom untracked files when core.ignorecase is setLibravatar Jeff King2-7/+9
When core.ignorecase is turned on and there are stale index entries, "git commit" can sometimes report directories as untracked, even though they contain tracked files. You can see an example of this with: # make a case-insensitive repo git init repo && cd repo && git config core.ignorecase true && # with some tracked files in a subdir mkdir subdir && > subdir/one && > subdir/two && git add . && git commit -m base && # now make the index entries stale touch subdir/* && # and then ask commit to update those entries and show # us the status template git commit -a which will report "subdir/" as untracked, even though it clearly contains two tracked files. What is happening in the commit program is this: 1. We load the index, and for each entry, insert it into the index's name_hash. In addition, if ignorecase is turned on, we make an entry in the name_hash for the directory (e.g., "contrib/"), which uses the following code from 5102c61's hash_index_entry_directories: hash = hash_name(ce->name, ptr - ce->name); if (!lookup_hash(hash, &istate->name_hash)) { pos = insert_hash(hash, &istate->name_hash); if (pos) { ce->next = *pos; *pos = ce; } } Note that we only add the directory entry if there is not already an entry. 2. We run add_files_to_cache, which gets updated information for each cache entry. It helpfully inserts this information into the cache, which calls replace_index_entry. This in turn calls remove_name_hash() on the old entry, and add_name_hash() on the new one. But remove_name_hash doesn't actually remove from the hash, it only marks it as "no longer interesting" (from cache.h): /* * We don't actually *remove* it, we can just mark it invalid so that * we won't find it in lookups. * * Not only would we have to search the lists (simple enough), but * we'd also have to rehash other hash buckets in case this makes the * hash bucket empty (common). So it's much better to just mark * it. */ static inline void remove_name_hash(struct cache_entry *ce) { ce->ce_flags |= CE_UNHASHED; } This is OK in the specific-file case, since the entries in the hash form a linked list, and we can just skip the "not here anymore" entries during lookup. But for the directory hash entry, we will _not_ write a new entry, because there is already one there: the old one that is actually no longer interesting! 3. While traversing the directories, we end up in the directory_exists_in_index_icase function to see if a directory is interesting. This in turn checks index_name_exists, which will look up the directory in the index's name_hash. We see the old, deleted record, and assume there is nothing interesting. The directory gets marked as untracked, even though there are index entries in it. The problem is in the code I showed above: hash = hash_name(ce->name, ptr - ce->name); if (!lookup_hash(hash, &istate->name_hash)) { pos = insert_hash(hash, &istate->name_hash); if (pos) { ce->next = *pos; *pos = ce; } } Having a single cache entry that represents the directory is not enough; that entry may go away if the index is changed. It may be tempting to say that the problem is in our removal method; if we removed the entry entirely instead of simply marking it as "not here anymore", then we would know we need to insert a new entry. But that only covers this particular case of remove-replace. In the more general case, consider something like this: 1. We add "foo/bar" and "foo/baz" to the index. Each gets their own entry in name_hash, plus we make a "foo/" entry that points to "foo/bar". 2. We remove the "foo/bar" entry from the index, and from the name_hash. 3. We ask if "foo/" exists, and see no entry, even though "foo/baz" exists. So we need that directory entry to have the list of _all_ cache entries that indicate that the directory is tracked. So that implies making a linked list as we do for other entries, like: hash = hash_name(ce->name, ptr - ce->name); pos = insert_hash(hash, &istate->name_hash); if (pos) { ce->next = *pos; *pos = ce; } But that's not right either. In fact, it shows a second bug in the current code, which is that the "ce->next" pointer is supposed to be linking entries for a specific filename entry, but here we are overwriting it for the directory entry. So the same cache entry ends up in two linked lists, but they share the same "next" pointer. As it turns out, this second bug can't be triggered in the current code. The "if (pos)" conditional is totally dead code; pos will only be non-NULL if there was an existing hash entry, and we already checked that there wasn't one through our call to lookup_hash. But fixing the first bug means taking out that call to lookup_hash, which is going to activate the buggy dead code, and we'll end up splicing the two linked lists together. So we need to have a separate next pointer for the list in the directory bucket, and we need to traverse that list in index_name_exists when we are looking up a directory. This bloats "struct cache_entry" by a few bytes. Which is annoying, because it's only necessary when core.ignorecase is enabled. There's not an easy way around it, short of separating out the "next" pointers from cache_entry entirely (i.e., having a separate "cache_entry_list" struct that gets stored in the name_hash). In practice, it probably doesn't matter; we have thousands of cache entries, compared to the millions of objects (where adding 4 bytes to the struct actually does impact performance). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-26Git 1.7.6Libravatar Junio C Hamano3-8/+7
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-26Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: completion: replace core.abbrevguard to core.abbrev
2011-06-24Merge branch 'maint-1.7.4' into maintLibravatar Junio C Hamano1-1/+1
* maint-1.7.4: completion: replace core.abbrevguard to core.abbrev
2011-06-24completion: replace core.abbrevguard to core.abbrevLibravatar Namhyung Kim1-1/+1
The core.abbrevguard config variable had removed and now core.abbrev has been used instead. Teach it. Signed-off-by: Namhyung Kim <namhyung@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-22Git 1.7.6-rc3Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-22Merge branch 'maint'Libravatar Junio C Hamano1-4/+8
* maint: Documentation: git diff --check respects core.whitespace
2011-06-22Documentation: git diff --check respects core.whitespaceLibravatar Christof Krüger1-4/+8
Fix documentation on "git diff --check" by adopting the description from "git apply --whitespace". Signed-off-by: Christof Krüger <git@christof-krueger.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-21Merge branch 'maint'Libravatar Junio C Hamano1-0/+2
* maint: gitweb: 'pickaxe' and 'grep' features requires 'search' to be enabled
2011-06-21gitweb: 'pickaxe' and 'grep' features requires 'search' to be enabledLibravatar Jakub Narebski1-0/+2
Both 'pickaxe' (searching changes) and 'grep' (searching files) require basic 'search' feature to be enabled to work. Enabling e.g. only 'pickaxe' won't work. Add a comment about this. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-20Merge branch 'mk/grep-pcre'Libravatar Junio C Hamano1-3/+3
* mk/grep-pcre: t7810: avoid unportable use of "echo"
2011-06-20t7810: avoid unportable use of "echo"Libravatar Junio C Hamano1-3/+3
Michael J Gruber noticed that under /bin/dash this test failed (as is expected -- \n in the string can be interpreted by the command), while it passed with bash. We probably could work it around by using backquote in front of it, but it is safer and more readable to avoid "echo" altogether in a case like this. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-20plug a few coverity-spotted leaksLibravatar Jim Meyering4-5/+12
Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-19Merge branch 'di/no-no-existant'Libravatar Junio C Hamano7-14/+14
* di/no-no-existant: Fix typo: existant->existent
2011-06-19Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: builtin/gc.c: add missing newline in message
2011-06-19builtin/gc.c: add missing newline in messageLibravatar Andreas Schwab1-1/+1
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-17tests: link shell libraries into valgrind directoryLibravatar Jeff King1-2/+7
When we run tests under valgrind, we symlink anything executable that starts with git-* or test-* into a special valgrind bin directory, and then make that our GIT_EXEC_PATH. However, shell libraries like git-sh-setup do not have the executable bit marked, and did not get symlinked. This means that any test looking for shell libraries in our exec-path would fail to find them, even though that is a fine thing to do when testing against a regular git build (or in a git install, for that matter). t2300 demonstrated this problem. The fix is to symlink these shell libraries directly into the valgrind directory. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-17t/Makefile: pass test opts to valgrind target properlyLibravatar Jeff King1-1/+1
The valgrind target just reinvokes make with GIT_TEST_OPTS set to "--valgrind". However, it does this using an environment variable, which means GIT_TEST_OPTS in your config.mak would override it, and "make valgrind" would simply run the test suite without valgrind on. Instead, we should pass GIT_TEST_OPTS on the command-line, overriding what's in config.mak, and take care to append to whatever the user has there already. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-17Merge branch 'ab/i18n-scripts-basic'Libravatar Junio C Hamano1-1/+0
* ab/i18n-scripts-basic: sh-i18n--envsubst.c: do not #include getopt.h
2011-06-17sh-i18n--envsubst.c: do not #include getopt.hLibravatar Brandon Casey1-1/+0
The getopt.h header file is not used. It's inclusion is left over from the original version of this source. Additionally, getopt.h does not exist on all platforms (SunOS 5.7) and will cause a compilation failure. So, let's remove it. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-16Fix typo: existant->existentLibravatar Dmitry Ivankov7-14/+14
refs.c had a error message "Trying to write ref with nonexistant object". And no tests relied on the wrong spelling. Also typo was present in some test scripts internals, these tests still pass. Signed-off-by: Dmitry Ivankov <divanorama@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-16Git 1.7.6-rc2Libravatar Junio C Hamano2-2/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-09gitweb: do not misparse nonnumeric content tag files that contain a digitLibravatar Jonathan Nieder2-1/+9
v1.7.6-rc0~27^2~4 (gitweb: Change the way "content tags" ('ctags') are handled, 2011-04-29) tried to make gitweb's tag cloud feature more intuitive for webmasters by checking whether the ctags/<label> under a project's .git dir contains a number (representing the strength of association to <label>) before treating it as one. With that change, after putting '$feature{'ctags'}{'default'} = [1];' in your $GITWEB_CONFIG, you could do echo Linux >.git/ctags/linux and gitweb would treat that as a request to tag the current repository with the Linux tag, instead of the previous behavior of writing an error page embedded in the projects list that triggers error messages from Chromium and Firefox about malformed XML. Unfortunately the pattern (\d+) used to match numbers is too loose, and the "XML declaration allowed only at the start of the document" error can still be experienced if you write "Linux-2.6" in place of "Linux" in the example above. Fix it by tightening the pattern to ^\d+$. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-08Git 1.7.6-rc1Libravatar Junio C Hamano2-3/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-08Merge branch 'maint'Libravatar Junio C Hamano1-2/+4
* maint: fetch: do not leak a refspec
2011-06-08fetch: do not leak a refspecLibravatar Jim Meyering1-2/+4
Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-07Merge branch 'jc/magic-pathspec'Libravatar Junio C Hamano1-6/+6
* jc/magic-pathspec: t3703: skip more tests using colons in file names on Windows
2011-06-07t3703: skip more tests using colons in file names on WindowsLibravatar Alex Riesen1-6/+6
Use the same test and prerequisite as introduced in similar fix in 650af7ae8bdf92bd92df2. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-06Merge branch 'jn/mime-type-with-params'Libravatar Junio C Hamano1-1/+1
* jn/mime-type-with-params: gitweb: Fix usability of $prevent_xss
2011-06-06Merge branch 'jn/gitweb-docs'Libravatar Junio C Hamano2-131/+135
* jn/gitweb-docs: gitweb: Move "Requirements" up in gitweb/INSTALL gitweb: Describe CSSMIN and JSMIN in gitweb/INSTALL gitweb: Move information about installation from README to INSTALL
2011-06-06Merge branch 'jk/diff-not-so-quick'Libravatar Junio C Hamano5-5/+16
* jk/diff-not-so-quick: diff: futureproof "stop feeding the backend early" logic diff_tree: disable QUICK optimization with diff filter Conflicts: diff.c
2011-06-06Merge branch 'bc/maint-status-z-to-use-porcelain'Libravatar Junio C Hamano2-3/+11
* bc/maint-status-z-to-use-porcelain: builtin/commit.c: set status_format _after_ option parsing t7508: demonstrate status's failure to use --porcelain format with -z Conflicts: builtin/commit.c
2011-06-05gitweb: Fix usability of $prevent_xssLibravatar Jakub Narebski1-1/+1
With XSS prevention on (enabled using $prevent_xss), blobs ('blob_plain') of all types except a few known safe ones are served with "Content-Disposition: attachment". However the check was too strict; it didn't take into account optional parameter attributes, media-type = type "/" subtype *( ";" parameter ) as described in RFC 2616 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.17 http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7 This fixes that, and it for example treats following as safe MIME media type: text/plain; charset=utf-8 Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-03gitweb: Move "Requirements" up in gitweb/INSTALLLibravatar Jakub Narebski1-15/+15
This way you can examine prerequisites at first glance, before detailed instructions on installing gitweb. Straightforward text movement. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-02gitweb: Describe CSSMIN and JSMIN in gitweb/INSTALLLibravatar Jakub Narebski1-6/+13
The build-time configuration variables JSMIN and CSSMIN were mentioned only in Makefile; add their description to gitweb/INSTALL. This required moving description of GITWEB_JS up, near GITWEB_CSS and just introduced CSMIN and JSMIN. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-02gitweb: Move information about installation from README to INSTALLLibravatar Jakub Narebski2-116/+113
Almost straightformard moving of "How to configure gitweb for your local system" section from gitweb/README to gitweb/INSTALL, as it is about build time configuration. Updated references to it. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-01Sync with 1.7.5.4Libravatar Junio C Hamano2-1/+5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-01Git 1.7.5.4Libravatar Junio C Hamano3-2/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-01Merge branch 'jk/maint-config-alias-fix' into maintLibravatar Junio C Hamano4-48/+30
* jk/maint-config-alias-fix: handle_options(): do not miscount how many arguments were used config: always parse GIT_CONFIG_PARAMETERS during git_config git_config: don't peek at global config_parameters config: make environment parsing routines static
2011-06-01Merge branch 'jc/fmt-req-fix' into maintLibravatar Junio C Hamano1-1/+1
* jc/fmt-req-fix: userformat_find_requirements(): find requirement for the correct format
2011-06-01Merge branch 'jk/maint-docs' into maintLibravatar Junio C Hamano4-15/+35
* jk/maint-docs: docs: fix some antique example output docs: make sure literal "->" isn't converted to arrow docs: update status --porcelain format docs: minor grammar fixes to git-status
2011-06-01Merge branch 'jn/doc-remote-helpers' into maintLibravatar Junio C Hamano1-3/+3
* jn/doc-remote-helpers: Documentation: do not misinterpret refspecs as bold text
2011-06-01Merge branch 'kk/maint-prefix-in-config-mak' into maintLibravatar Junio C Hamano1-0/+1
* kk/maint-prefix-in-config-mak: config.mak.in: allow "configure --sysconfdir=/else/where"
2011-06-01diffcore-rename.c: avoid set-but-not-used warningLibravatar Jim Meyering1-2/+1
Since 9d8a5a5 (diffcore-rename: refactor "too many candidates" logic, 2011-01-06), diffcore_rename() initializes num_src but does not use it anymore. "-Wunused-but-set-variable" in gcc-4.6 complains about this. Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-31Update draft release notes to 1.7.6Libravatar Junio C Hamano1-10/+13
I think we are almost there for the feature freeze. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-31Merge branch 'jk/format-patch-am'Libravatar Junio C Hamano13-92/+174
* jk/format-patch-am: format-patch: preserve subject newlines with -k clean up calling conventions for pretty.c functions pretty: add pp_commit_easy function for simple callers mailinfo: always clean up rfc822 header folding t: test subject handling in format-patch / am pipeline Conflicts: builtin/branch.c builtin/log.c commit.h
2011-05-31Merge branch 'jn/doc-remote-helpers'Libravatar Junio C Hamano1-3/+3
* jn/doc-remote-helpers: Documentation: do not misinterpret refspecs as bold text
2011-05-31Merge branch 'jk/format-patch-empty-prefix'Libravatar Junio C Hamano2-1/+20
* jk/format-patch-empty-prefix: format-patch: make zero-length subject prefixes prettier
2011-05-31Merge branch 'ab/i18n-envsubst-doc-fix'Libravatar Junio C Hamano1-0/+10
* ab/i18n-envsubst-doc-fix: git-sh-i18n--envsubst: add SYNOPSIS section to the documentation