This project is mirrored from https://github.com/git/git. Updated .
  1. 03 Mar, 2014 1 commit
  2. 05 Dec, 2013 1 commit
    • Christian Couder's avatar
      replace {pre,suf}fixcmp() with {starts,ends}_with() · 59556548
      Christian Couder authored
      Leaving only the function definitions and declarations so that any
      new topic in flight can still make use of the old functions, replace
      existing uses of the prefixcmp() and suffixcmp() with new API
      functions.
      
      The change can be recreated by mechanically applying this:
      
          $ git grep -l -e prefixcmp -e suffixcmp -- \*.c |
            grep -v strbuf\\.c |
            xargs perl -pi -e '
              s|!prefixcmp\(|starts_with\(|g;
              s|prefixcmp\(|!starts_with\(|g;
              s|!suffixcmp\(|ends_with\(|g;
              s|suffixcmp\(|!ends_with\(|g;
            '
      
      on the result of preparatory changes in this series.
      Signed-off-by: Christian Couder's avatarChristian Couder <chriscool@tuxfamily.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      59556548
  3. 17 Apr, 2013 2 commits
  4. 29 Mar, 2013 1 commit
    • Junio C Hamano's avatar
      attr.c::path_matches(): special case paths that end with a slash · dc09e9ec
      Junio C Hamano authored
      The function is given a string that ends with a slash to signal that
      the path is a directory to make sure that a pattern that ends with a
      slash (i.e. MUSTBEDIR) can tell directories and non-directories
      apart.  However, the pattern itself (pat->pattern and
      pat->patternlen) that came from such a MUSTBEDIR pattern is
      represented as a string that ends with a slash, but patternlen does
      not count that trailing slash. A MUSTBEDIR pattern "element/" is
      represented as a counted string <"element/", 7> and this must match
      match pathname "element/".
      
      Because match_basename() and match_pathname() want to see pathname
      "element" to match against the pattern <"element/", 7>, reduce the
      length of the path to exclude the trailing slash when calling
      these functions.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      dc09e9ec
  5. 26 Mar, 2013 1 commit
  6. 01 Mar, 2013 1 commit
    • Thomas Rast's avatar
      Make !pattern in .gitattributes non-fatal · 8b1bd024
      Thomas Rast authored
      Before 82dce998 (attr: more matching optimizations from .gitignore,
      2012-10-15), .gitattributes did not have any special treatment of a
      leading '!'.  The docs, however, always said
      
        The rules how the pattern matches paths are the same as in
        `.gitignore` files; see linkgit:gitignore[5].
      
      By those rules, leading '!' means pattern negation.  So 82dce998
      correctly determined that this kind of line makes no sense and should
      be disallowed.
      
      However, users who actually had a rule for files starting with a '!'
      are in a bad position: before 82dce998 '!' matched that literal
      character, so it is conceivable that users have .gitattributes with
      such lines in them.  After 82dce998 the unescaped version was
      disallowed in such a way that git outright refuses to run(!) most
      commands in the presence of such a .gitattributes.  It therefore
      becomes very hard to fix, let alone work with, such repositories.
      
      Let's at least allow the users to fix their repos: change the fatal
      error into a warning.
      
      Reported-by: mathstuf@gmail.com
      Signed-off-by: default avatarThomas Rast <trast@student.ethz.ch>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      8b1bd024
  7. 16 Jan, 2013 1 commit
  8. 15 Jan, 2013 2 commits
    • Duy Nguyen's avatar
      attr: make it build with DEBUG_ATTR again · 712efb1a
      Duy Nguyen authored
      Commit 82dce998 (attr: more matching optimizations from .gitignore -
      2012-10-15) changed match_attr structure but it did not update
      DEBUG_ATTR-specific code. This fixes it.
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      712efb1a
    • Duy Nguyen's avatar
      attr: fix off-by-one directory component length calculation · 711536bd
      Duy Nguyen authored
      94bc671a (Add directory pattern matching to attributes - 2012-12-08)
      uses find_basename() to calculate the length of directory part in
      prepare_attr_stack. This function expects the directory without the
      trailing slash (as "origin" field in match_attr struct is without the
      trailing slash). find_basename() includes the trailing slash and
      confuses push/pop algorithm.
      
      Consider path = "abc/def" and the push down code:
      
      	while (1) {
      		len = strlen(attr_stack->origin);
      		if (dirlen <= len)
      			break;
      		cp = memchr(path + len + 1, '/', dirlen - len - 1);
      		if (!cp)
      			cp = path + dirlen;
      
      dirlen is 4, not 3, without this patch. So when attr_stack->origin is
      "abc", it'll miss the exit condition because 4 <= 3 is wrong. It'll
      then try to push "abc/" down the attr stack (because "cp" would be
      NULL). So we have both "abc" and "abc/" in the stack.
      
      Next time when "abc/ghi" is checked, "abc/" is popped out because of
      the off-by-one dirlen, only to be pushed back in again by the above
      code. This repeats for all files in the same directory. Which means
      at least one failed open syscall per file, or more if .gitattributes
      exists.
      
      This is the perf result with 10 runs on git.git:
      
      Test                                     94bc671a^          94bc671a                   HEAD
      ----------------------------------------------------------------------------------------------------------
      7810.1: grep worktree, cheap regex       0.02(0.01+0.04)   0.05(0.03+0.05) +150.0%   0.02(0.01+0.04) +0.0%
      7810.2: grep worktree, expensive regex   0.25(0.94+0.01)   0.26(0.94+0.02) +4.0%     0.25(0.93+0.02) +0.0%
      7810.3: grep --cached, cheap regex       0.11(0.10+0.00)   0.12(0.10+0.02) +9.1%     0.10(0.10+0.00) -9.1%
      7810.4: grep --cached, expensive regex   0.61(0.60+0.01)   0.62(0.61+0.01) +1.6%     0.61(0.60+0.00) +0.0%
      Reported-by: default avatarRoss Lagerwall <rosslagerwall@gmail.com>
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      711536bd
  9. 28 Dec, 2012 1 commit
  10. 18 Dec, 2012 1 commit
  11. 15 Oct, 2012 1 commit
    • Duy Nguyen's avatar
      attr: more matching optimizations from .gitignore · 82dce998
      Duy Nguyen authored
      .gitattributes and .gitignore share the same pattern syntax but has
      separate matching implementation. Over the years, ignore's
      implementation accumulates more optimizations while attr's stays the
      same.
      
      This patch reuses the core matching functions that are also used by
      excluded_from_list. excluded_from_list and path_matches can't be
      merged due to differences in exclude and attr, for example:
      
      * "!pattern" syntax is forbidden in .gitattributes.  As an attribute
        can be unset (i.e. set to a special value "false") or made back to
        unspecified (i.e. not even set to "false"), "!pattern attr" is unclear
        which one it means.
      
      * we support attaching attributes to directories, but git-core
        internally does not currently make use of attributes on
        directories.
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      82dce998
  12. 05 Oct, 2012 2 commits
  13. 14 Sep, 2012 1 commit
    • Junio C Hamano's avatar
      attr: failure to open a .gitattributes file is OK with ENOTDIR · 8e950dab
      Junio C Hamano authored
      Often we consult an in-tree .gitattributes file that exists per
      directory.  Majority of directories do not usually have such a file,
      and it is perfectly fine if we cannot open it because there is no
      such file, but we do want to know when there is an I/O or permission
      error.  Earlier, we made the codepath warn when we fail to open it
      for reasons other than ENOENT for that reason.
      
      We however sometimes have to attempt to open the .gitattributes file
      from a directory that does not exist in the commit that is currently
      checked out.  "git pack-objects" wants to know if a path is marked
      with "-delta" attributes, and "git archive" wants to know about
      export-ignore and export-subst attributes.  Both commands may and do
      need to ask the attributes system about paths in an arbitrary
      commit.  "git diff", after removing an entire directory, may want to
      know textconv on paths that used to be in that directory.
      
      Make sure we also ignore a failure to open per-directory attributes
      file due to ENOTDIR.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      8e950dab
  14. 09 Sep, 2012 1 commit
  15. 21 Aug, 2012 2 commits
    • Junio C Hamano's avatar
      warn_on_inaccessible(): a helper to warn on inaccessible paths · 55b38a48
      Junio C Hamano authored
      The previous series introduced warnings to multiple places, but it
      could become tiring to see the warning on the same path over and
      over again during a single run of Git.  Making just one function
      responsible for issuing this warning, we could later choose to keep
      track of which paths we issued a warning (it would involve a hash
      table of paths after running them through real_path() or something)
      in order to reduce noise.
      
      Right now we do not know if the noise reduction is necessary, but it
      still would be a good code reduction/sharing anyway.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      55b38a48
    • Jeff King's avatar
      attr: warn on inaccessible attribute files · 11e50b27
      Jeff King authored
      Just like config and gitignore files, we silently ignore
      missing or inaccessible attribute files. An existent but
      inaccessible file is probably a configuration error, so
      let's warn the user.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      11e50b27
  16. 24 Jul, 2012 1 commit
    • Jeff King's avatar
      attr: make sure we have an xdg path before using it · f0c1c15c
      Jeff King authored
      If we don't have a core.attributesfile configured, we fall
      back to checking XDG config, which is usually
      $HOME/.config/git/attributes.
      
      However, if $HOME is unset, then home_config_paths will return
      NULL, and we end up calling fopen(NULL).
      
      Depending on your system, this may or may not cause the
      accompanying test to fail (e.g., on Linux and glibc, the
      address will go straight to open, which will return EFAULT).
      However, valgrind will reliably notice the error.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      f0c1c15c
  17. 25 Jun, 2012 1 commit
  18. 12 Jan, 2012 1 commit
  19. 10 Jan, 2012 4 commits
    • Junio C Hamano's avatar
      c432ef99
    • Junio C Hamano's avatar
      attr.c: make bootstrap_attr_stack() leave early · 909ca7b9
      Junio C Hamano authored
      Thas would de-dent the body of a function that has grown rather large over
      time, making it a bit easier to read.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      909ca7b9
    • Jeff King's avatar
      attr: drop misguided defensive coding · 77f7f822
      Jeff King authored
      In prepare_attr_stack, we pop the old elements of the stack
      (which were left from a previous lookup and may or may not
      be useful to us). Our loop to do so checks that we never
      reach the top of the stack. However, the code immediately
      afterwards will segfault if we did actually reach the top of
      the stack.
      
      Fortunately, this is not an actual bug, since we will never
      pop all of the stack elements (we will always keep the root
      gitattributes, as well as the builtin ones). So the extra
      check in the loop condition simply clutters the code and
      makes the intent less clear. Let's get rid of it.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      77f7f822
    • Jeff King's avatar
      attr: don't confuse prefixes with leading directories · 1afca444
      Jeff King authored
      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: default avatarMichael Haggerty <mhagger@alum.mit.edu>
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      1afca444
  20. 11 Oct, 2011 1 commit
    • Brandon Casey's avatar
      attr.c: respect core.ignorecase when matching attribute patterns · 6eba6210
      Brandon Casey authored
      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: default avatarBrandon Casey <drafnel@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      6eba6210
  21. 06 Oct, 2011 3 commits
    • Junio C Hamano's avatar
      attr: read core.attributesfile from git_default_core_config · 64589a03
      Junio C Hamano authored
      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: default avatarBrandon Casey <drafnel@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      64589a03
    • Brandon Casey's avatar
      cleanup: use internal memory allocation wrapper functions everywhere · 040a6551
      Brandon Casey authored
      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: default avatarBrandon Casey <drafnel@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      040a6551
    • Brandon Casey's avatar
      attr.c: avoid inappropriate access to strbuf "buf" member · 97410b27
      Brandon Casey authored
      This code sequence performs a strcpy into the buf member of a strbuf
      struct.  The strcpy may move the position of the terminating nul of the
      string and effectively change the length of string so that it does not
      match the len member of the strbuf struct.
      
      Currently, this sequence works since the strbuf was given a hint when it
      was initialized to allocate enough space to accomodate the string that will
      be strcpy'ed, but this is an implementation detail of strbufs, not a
      guarantee.
      
      So, lets rework this sequence so that the strbuf is only manipulated by
      strbuf functions, and direct modification of its "buf" member is not
      necessary.
      Signed-off-by: default avatarBrandon Casey <drafnel@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      97410b27
  22. 14 Aug, 2011 7 commits
  23. 04 Aug, 2011 3 commits