This project is mirrored from https://github.com/git/git.git. Pull mirroring updated .
  1. 17 Jul, 2017 1 commit
  2. 12 Oct, 2016 1 commit
  3. 09 May, 2016 1 commit
  4. 07 Mar, 2016 1 commit
    • Jeff King's avatar
      mailmap: do not resolve blobs in a non-repository · 5735dc5a
      Jeff King authored
      The mailmap code may be triggered outside of a repository by
      git-shortlog. There is no point in looking up a name like
      "HEAD:.mailmap" there; without a repository, we have no
      refs.
      
      This is unlikely to matter much in practice for the current
      code, as we would simply fail to find the ref. But as the
      refs code learns about new backends, this is more important;
      without a repository, we do not even know which backend to
      look at.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      5735dc5a
  5. 25 Sep, 2015 1 commit
    • Jeff King's avatar
      mailmap: replace strcpy with xstrdup · c978610d
      Jeff King authored
      We want to make a copy of a string without any leading
      whitespace. To do so, we allocate a buffer large enough to
      hold the original, skip past the whitespace, then copy that.
      It's much simpler to just allocate after we've skipped, in
      which case we can just copy the remainder of the string,
      leaving no question of whether "len" is large enough.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      c978610d
  6. 04 Dec, 2014 1 commit
  7. 12 Sep, 2013 1 commit
  8. 28 Aug, 2013 1 commit
    • Jeff King's avatar
      mailmap: handle mailmap blobs without trailing newlines · f972a165
      Jeff King authored
      The read_mailmap_buf function reads each line of the mailmap
      using strchrnul, like:
      
          const char *end = strchrnul(buf, '\n');
          unsigned long linelen = end - buf + 1;
      
      But that's off-by-one when we actually hit the NUL byte; our
      line does not have a terminator, and so is only "end - buf"
      bytes long. As a result, when we subtract the linelen from
      the total len, we end up with (unsigned long)-1 bytes left
      in the buffer, and we start reading random junk from memory.
      
      We could fix it with:
      
          unsigned long linelen = end - buf + !!*end;
      
      but let's take a step back for a moment. It's questionable
      in the first place for a function that takes a buffer and
      length to be using strchrnul. But it works because we only
      have one caller (and are only likely to ever have this one),
      which is handing us data from read_sha1_file. Which means
      that it's always NUL-terminated.
      
      Instead of tightening the assumptions to make the
      buffer/length pair work for a caller that doesn't actually
      exist, let's let loosen the assumptions to what the real
      caller has: a modifiable, NUL-terminated string.
      
      This makes the code simpler and shorter (because we don't
      have to correlate strchrnul with the length calculation),
      correct (because the code with the off-by-one just goes
      away), and more efficient (we can drop the extra allocation
      we needed to create NUL-terminated strings for each line,
      and just terminate in place).
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      f972a165
  9. 20 Aug, 2013 1 commit
  10. 15 Jul, 2013 7 commits
  11. 10 Jan, 2013 2 commits
    • Antoine Pelisse's avatar
      mailmap: simplify map_user() interface · ea02ffa3
      Antoine Pelisse authored
      Simplify map_user(), mostly to avoid copies of string buffers. It
      also simplifies caller functions.
      
      map_user() directly receive pointers and length from the commit buffer
      as mail and name. If mapping of the user and mail can be done, the
      pointer is updated to a new location. Lengths are also updated if
      necessary.
      
      The caller of map_user() can then copy the new email and name if
      necessary.
      Signed-off-by: Antoine Pelisse's avatarAntoine Pelisse <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      ea02ffa3
    • Junio C Hamano's avatar
      mailmap: remove email copy and length limitation · 388c7f8a
      Junio C Hamano authored
      In map_user(), we have email pointer that points at the beginning of
      an e-mail address, but the buffer is not terminated with a NUL after
      the e-mail address.  It typically has ">" after the address, and it
      could have even more if it comes from author/committer line in a
      commit object.  Or it may not have ">" after it.
      
      We used to copy the e-mail address proper into a temporary buffer
      before asking the string-list API to find the e-mail address in the
      mailmap, because string_list_lookup() function only takes a NUL
      terminated full string.
      
      Introduce a helper function lookup_prefix that takes the email
      pointer and the length, and finds a matching entry in the string
      list used for the mailmap, by doing the following:
      
       - First ask string_list_find_insert_index() where in its sorted
         list the e-mail address we have (including the possible trailing
         junk ">...") would be inserted.
      
       - It could find an exact match (e.g. we had a clean e-mail address
         without any trailing junk).  We can return the item in that case.
      
       - Or it could return the index of an item that sorts after the
         e-mail address we have.
      
       - If we did not find an exact match against a clean e-mail address,
         then the record we are looking for in the mailmap has to exist
         before the index returned by the function (i.e. "email>junk"
         always sorts later than "email").  Iterate, starting from that
         index, down the map->items[] array until we find the exact record
         we are looking for, or we see a record with a key that definitely
         sorts earlier than the e-mail we are looking for (i.e. when we
         are looking for "email" in "email>junk", a record in the mailmap
         that begins with "emaik" strictly sorts before "email", if such a
         key existed in the mailmap).
      
      This, together with the earlier enhancement to support
      case-insensitive sorting, allow us to remove an extra copy of email
      buffer to downcase it.
      
      A part of this is based on Antoine Pelisse's previous work.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      388c7f8a
  12. 13 Dec, 2012 1 commit
    • Jeff King's avatar
      mailmap: default mailmap.blob in bare repositories · 8c473cec
      Jeff King authored
      The motivation for mailmap.blob is to let users of bare
      repositories use the mailmap feature, as they would not have
      a checkout containing the .mailmap file. We can make it even
      easier for them by just looking in HEAD:.mailmap by default.
      
      We can't know for sure that this is where they would keep a
      mailmap, of course, but it is the best guess (and it matches
      the non-bare behavior, which reads from HEAD:.mailmap in the
      working tree). If it's missing, git will silently ignore the
      setting.
      
      We do not do the same magic in the non-bare case, because:
      
        1. In the common case, HEAD:.mailmap will be the same as
           the .mailmap in the working tree, which is a no-op.
      
        2. In the uncommon case, the user has modified .mailmap
           but not yet committed it, and would expect the working
           tree version to take precedence.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      8c473cec
  13. 12 Dec, 2012 3 commits
    • Jeff King's avatar
      mailmap: clean up read_mailmap error handling · 938a60d6
      Jeff King authored
      The error handling for the read_mailmap function is odd. It
      returns 1 on error, rather than -1. And it treats a
      non-existent mailmap as an error, even though there is no
      reason that one needs to exist. Unless some other mailmap
      source loads successfully, in which case the original error
      is completely masked.
      
      This does not cause any bugs, however, because no caller
      bothers to check the return value, anyway. Let's make this a
      little more robust to real errors and less surprising for
      future callers that do check the error code:
      
        1. Return -1 on errors.
      
        2. Treat a missing entry (e.g., no mailmap.file given),
           ENOENT, or a non-existent blob (for mailmap.blob) as
           "no error".
      
        3. Complain loudly when a real error (e.g., a transient
           I/O error, no permission to open the mailmap file,
           missing or corrupted blob object, etc) occurs.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      938a60d6
    • Jeff King's avatar
      mailmap: support reading mailmap from blobs · 08610900
      Jeff King authored
      In a bare repository, there isn't a simple way to respect an
      in-tree mailmap without extracting it to a temporary file.
      This patch provides a config variable, similar to
      mailmap.file, which reads the mailmap from a blob in the
      repository.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      08610900
    • Jeff King's avatar
      mailmap: refactor mailmap parsing for non-file sources · 7c8ce308
      Jeff King authored
      The read_single_mailmap function opens a mailmap file and
      parses each line. In preparation for having non-file
      mailmaps, let's pull out the line-parsing logic into its own
      function (read_mailmap_line), and rename the file-parsing
      function to match (read_mailmap_file).
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      7c8ce308
  14. 28 Oct, 2012 1 commit
  15. 06 Feb, 2012 1 commit
    • Junio C Hamano's avatar
      mailmap: always return a plain mail address from map_user() · f026358e
      Junio C Hamano authored
      The callers of map_user() give email and name to it, and expect to get the
      up-to-date email and/or name to be used in their output. The function
      rewrites the given buffers in place. To optimize the majority of cases,
      the function returns 0 when it did not do anything, and it returns 1 when
      the caller should use the updated contents.
      
      The 'email' input to the function is terminated by '>' or a NUL (whichever
      comes first) for historical reasons, but when a rewrite happens, the value
      is replaced with the mailbox inside the <> pair.  However, it failed to
      meet this expectation when it only rewrote the name part without rewriting
      the email part, and the email in the input was terminated by '>'.
      
      This causes an extra '>' to appear in the output of "blame -e", because the
      caller does send in '>'-terminated email, and when the function returned 1
      to tell it that rewriting happened, it appends '>' that is necessary when
      the email part was rewritten.
      
      The patch looks bigger than it actually is, because this change makes a
      variable that points at the end of the email part in the input 'p' live
      much longer than it used to, deserving a more descriptive name.
      
      Noticed and diagnosed by Felipe Contreras and Jeff King.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      f026358e
  16. 17 Nov, 2011 1 commit
  17. 14 Oct, 2010 1 commit
    • Jim Meyering's avatar
      mailmap: fix use of freed memory · d8d2eb7d
      Jim Meyering authored
      On an x86_64 system (F13-based), I ran these commands in an empty directory:
      
          git init
          printf '%s\n' \
            '<[email protected]> <[email protected]>' \
            'John <[email protected]>' > .mailmap
          git shortlog < /dev/null
      
      Here's the result:
      
          (reading log message from standard input)
          *** glibc detected *** git: free(): invalid pointer: 0x0000000000f53730 ***
          ======= Backtrace: =========
          /lib64/libc.so.6[0x31ba875676]
          git[0x48c2a5]
          git[0x4b9858]
          ...
          zsh: abort (core dumped)  git shortlog
      
      What happened?
      
      Some .mailmap entry is of the <email1> <email2> form,
      while a subsequent one looks like "User Name <Email2>,
      and the two email addresses on the right are not identical
      but are "equal" when using a case-insensitive comparator.
      
      Then, when add_mapping is processing the latter line, new_email is NULL
      and we free me->email, yet do not replace it with a new strdup'd string.
      Thus, when later we attempt to use the buffer behind that ->email pointer,
      we reference freed memory.
      
      The solution is to free ->email and ->name only if we're about to replace them.
      
      [jc: squashed in the tests from Jonathan]
      Signed-off-by: default avatarJim Meyering <[email protected]>
      Signed-off-by: default avatarJonathan Nieder <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      d8d2eb7d
  18. 27 Jun, 2010 3 commits
  19. 12 Jan, 2010 1 commit
  20. 21 Jun, 2009 1 commit
    • Linus Torvalds's avatar
      Fix various sparse warnings in the git source code · 2af202be
      Linus Torvalds authored
      There are a few remaining ones, but this fixes the trivial ones. It boils
      down to two main issues that sparse complains about:
      
       - warning: Using plain integer as NULL pointer
      
         Sparse doesn't like you using '0' instead of 'NULL'. For various good
         reasons, not the least of which is just the visual confusion. A NULL
         pointer is not an integer, and that whole "0 works as NULL" is a
         historical accident and not very pretty.
      
         A few of these remain: zlib is a total mess, and Z_NULL is just a 0.
         I didn't touch those.
      
       - warning: symbol 'xyz' was not declared. Should it be static?
      
         Sparse wants to see declarations for any functions you export. A lack
         of a declaration tends to mean that you should either add one, or you
         should mark the function 'static' to show that it's in file scope.
      
         A few of these remain: I only did the ones that should obviously just
         be made static.
      
      That 'wt_status_submodule_summary' one is debatable. It has a few related
      flags (like 'wt_status_use_color') which _are_ declared, and are used by
      builtin-commit.c. So maybe we'd like to export it at some point, but it's
      not declared now, and not used outside of that file, so 'static' it is in
      this patch.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      2af202be
  21. 01 Apr, 2009 2 commits
  22. 08 Feb, 2009 2 commits
  23. 22 Jul, 2008 1 commit
    • Johannes Schindelin's avatar
      Rename path_list to string_list · c455c87c
      Johannes Schindelin authored
      The name path_list was correct for the first usage of that data structure,
      but it really is a general-purpose string list.
      
      $ perl -i -pe 's/path-list/string-list/g' $(git grep -l path-list)
      $ perl -i -pe 's/path_list/string_list/g' $(git grep -l path_list)
      $ git mv path-list.h string-list.h
      $ git mv path-list.c string-list.c
      $ perl -i -pe 's/has_path/has_string/g' $(git grep -l has_path)
      $ perl -i -pe 's/path/string/g' string-list.[ch]
      $ git mv Documentation/technical/api-path-list.txt \
      	Documentation/technical/api-string-list.txt
      $ perl -i -pe 's/strdup_paths/strdup_strings/g' $(git grep -l strdup_paths)
      
      ... and then fix all users of string-list to access the member "string"
      instead of "path".
      
      Documentation/technical/api-string-list.txt needed some rewrapping, too.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      c455c87c
  24. 08 Dec, 2007 1 commit
  25. 07 Jun, 2007 1 commit
    • Junio C Hamano's avatar
      War on whitespace · a6080a0a
      Junio C Hamano authored
      This uses "git-apply --whitespace=strip" to fix whitespace errors that have
      crept in to our source files over time.  There are a few files that need
      to have trailing whitespaces (most notably, test vectors).  The results
      still passes the test, and build result in Documentation/ area is unchanged.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      a6080a0a
  26. 30 Apr, 2007 2 commits