1. 16 May, 2018 1 commit
    • Stefan Beller's avatar
      object-store: move object access functions to object-store.h · cbd53a21
      Stefan Beller authored
      This should make these functions easier to find and cache.h less
      overwhelming to read.
      
      In particular, this moves:
      - read_object_file
      - oid_object_info
      - write_object_file
      
      As a result, most of the codebase needs to #include object-store.h.
      In this patch the #include is only added to files that would fail to
      compile otherwise.  It would be better to #include wherever
      identifiers from the header are used.  That can happen later
      when we have better tooling for it.
      Signed-off-by: Stefan Beller's avatarStefan Beller <sbeller@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      cbd53a21
  2. 11 Apr, 2018 1 commit
  3. 14 Mar, 2018 1 commit
    • brian m. carlson's avatar
      sha1_file: convert read_sha1_file to struct object_id · b4f5aca4
      brian m. carlson authored
      Convert read_sha1_file to take a pointer to struct object_id and rename
      it read_object_file.  Do the same for read_sha1_file_extended.
      
      Convert one use in grep.c to use the new function without any other code
      change, since the pointer being passed is a void pointer that is already
      initialized with a pointer to struct object_id.  Update the declaration
      and definitions of the modified functions, and apply the following
      semantic patch to convert the remaining callers:
      
      @@
      expression E1, E2, E3;
      @@
      - read_sha1_file(E1.hash, E2, E3)
      + read_object_file(&E1, E2, E3)
      
      @@
      expression E1, E2, E3;
      @@
      - read_sha1_file(E1->hash, E2, E3)
      + read_object_file(E1, E2, E3)
      
      @@
      expression E1, E2, E3, E4;
      @@
      - read_sha1_file_extended(E1.hash, E2, E3, E4)
      + read_object_file_extended(&E1, E2, E3, E4)
      
      @@
      expression E1, E2, E3, E4;
      @@
      - read_sha1_file_extended(E1->hash, E2, E3, E4)
      + read_object_file_extended(E1, E2, E3, E4)
      Signed-off-by: brian m. carlson's avatarbrian m. carlson <sandals@crustytoothpaste.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      b4f5aca4
  4. 16 Oct, 2017 1 commit
  5. 16 Jun, 2017 1 commit
  6. 02 Jun, 2017 3 commits
  7. 26 May, 2017 1 commit
    • Duy Nguyen's avatar
      use xfopen() in more places · 23a9e071
      Duy Nguyen authored
      xfopen()
      
       - provides error details
       - explains error on reading, or writing, or whatever operation
       - has l10n support
       - prints file name in the error
      
      Some of these are missing in the places that are replaced with xfopen(),
      which is a clear win. In some other places, it's just less code (not as
      clearly a win as the previous case but still is).
      
      The only slight regresssion is in remote-testsvn, where we don't report
      the file class (marks files) in the error messages anymore. But since
      this is a _test_ svn remote transport, I'm not too concerned.
      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>
      23a9e071
  8. 01 Jul, 2016 2 commits
    • Jeff King's avatar
      common-main: call git_extract_argv0_path() · 650c4492
      Jeff King authored
      Every program which links against libgit.a must call this
      function, or risk hitting an assert() in system_path() that
      checks whether we have configured argv0_path (though only
      when RUNTIME_PREFIX is defined, so essentially only on
      Windows).
      
      Looking at the diff, you can see that putting it into the
      common main() saves us having to do it individually in each
      of the external commands. But what you can't see are the
      cases where we _should_ have been doing so, but weren't
      (e.g., git-credential-store, and all of the t/helper test
      programs).
      
      This has been an accident-waiting-to-happen for a long time,
      but wasn't triggered until recently because it involves one
      of those programs actually calling system_path(). That
      happened with git-credential-store in v2.8.0 with ae5f6776
      (lazily load core.sharedrepository, 2016-03-11). The
      program:
      
        - takes a lock file, which...
      
        - opens a tempfile, which...
      
        - calls adjust_shared_perm to fix permissions, which...
      
        - lazy-loads the config (as of ae5f6776), which...
      
        - calls system_path() to find the location of
          /etc/gitconfig
      
      On systems with RUNTIME_PREFIX, this means credential-store
      reliably hits that assert() and cannot be used.
      
      We never noticed in the test suite, because we set
      GIT_CONFIG_NOSYSTEM there, which skips the system_path()
      lookup entirely.  But if we were to tweak git_config() to
      find /etc/gitconfig even when we aren't going to open it,
      then the test suite shows multiple failures (for
      credential-store, and for some other test helpers). I didn't
      include that tweak here because it's way too specific to
      this particular call to be worth carrying around what is
      essentially dead code.
      
      The implementation is fairly straightforward, with one
      exception: there is exactly one caller (git.c) that actually
      cares about the result of the function, and not the
      side-effect of setting up argv0_path. We can accommodate
      that by simply replacing the value of argv[0] in the array
      we hand down to cmd_main().
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      650c4492
    • Jeff King's avatar
      add an extra level of indirection to main() · 3f2e2297
      Jeff King authored
      There are certain startup tasks that we expect every git
      process to do. In some cases this is just to improve the
      quality of the program (e.g., setting up gettext()). In
      others it is a requirement for using certain functions in
      libgit.a (e.g., system_path() expects that you have called
      git_extract_argv0_path()).
      
      Most commands are builtins and are covered by the git.c
      version of main(). However, there are still a few external
      commands that use their own main(). Each of these has to
      remember to include the correct startup sequence, and we are
      not always consistent.
      
      Rather than just fix the inconsistencies, let's make this
      harder to get wrong by providing a common main() that can
      run this standard startup.
      
      We basically have two options to do this:
      
       - the compat/mingw.h file already does something like this by
         adding a #define that replaces the definition of main with a
         wrapper that calls mingw_startup().
      
         The upside is that the code in each program doesn't need
         to be changed at all; it's rewritten on the fly by the
         preprocessor.
      
         The downside is that it may make debugging of the startup
         sequence a bit more confusing, as the preprocessor is
         quietly inserting new code.
      
       - the builtin functions are all of the form cmd_foo(),
         and git.c's main() calls them.
      
         This is much more explicit, which may make things more
         obvious to somebody reading the code. It's also more
         flexible (because of course we have to figure out _which_
         cmd_foo() to call).
      
         The downside is that each of the builtins must define
         cmd_foo(), instead of just main().
      
      This patch chooses the latter option, preferring the more
      explicit approach, even though it is more invasive. We
      introduce a new file common-main.c, with the "real" main. It
      expects to call cmd_main() from whatever other objects it is
      linked against.
      
      We link common-main.o against anything that links against
      libgit.a, since we know that such programs will need to do
      this setup. Note that common-main.o can't actually go inside
      libgit.a, as the linker would not pick up its main()
      function automatically (it has no callers).
      
      The rest of the patch is just adjusting all of the various
      external programs (mostly in t/helper) to use cmd_main().
      I've provided a global declaration for cmd_main(), which
      means that all of the programs also need to match its
      signature. In particular, many functions need to switch to
      "const char **" instead of "char **" for argv. This effect
      ripples out to a few other variables and functions, as well.
      
      This makes the patch even more invasive, but the end result
      is much better. We should be treating argv strings as const
      anyway, and now all programs conform to the same signature
      (which also matches the way builtins are defined).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      3f2e2297
  9. 15 Jan, 2016 1 commit
    • Junio C Hamano's avatar
      strbuf: introduce strbuf_getline_{lf,nul}() · 8f309aeb
      Junio C Hamano authored
      The strbuf_getline() interface allows a byte other than LF or NUL as
      the line terminator, but this is only because I wrote these
      codepaths anticipating that there might be a value other than NUL
      and LF that could be useful when I introduced line_termination long
      time ago.  No useful caller that uses other value has emerged.
      
      By now, it is clear that the interface is overly broad without a
      good reason.  Many codepaths have hardcoded preference to read
      either LF terminated or NUL terminated records from their input, and
      then call strbuf_getline() with LF or NUL as the third parameter.
      
      This step introduces two thin wrappers around strbuf_getline(),
      namely, strbuf_getline_lf() and strbuf_getline_nul(), and
      mechanically rewrites these call sites to call either one of
      them.  The changes contained in this patch are:
      
       * introduction of these two functions in strbuf.[ch]
      
       * mechanical conversion of all callers to strbuf_getline() with
         either '\n' or '\0' as the third parameter to instead call the
         respective thin wrapper.
      
      After this step, output from "git grep 'strbuf_getline('" would
      become a lot smaller.  An interim goal of this series is to make
      this an empty set, so that we can have strbuf_getline_crlf() take
      over the shorter name strbuf_getline().
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      8f309aeb
  10. 22 Jun, 2015 1 commit
  11. 20 Aug, 2014 1 commit
  12. 18 Jul, 2014 1 commit
  13. 10 Mar, 2014 1 commit
  14. 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
  15. 28 Apr, 2013 1 commit
    • Ramsay Jones's avatar
      sparse: Fix mingw_main() argument number/type errors · 84d32bf7
      Ramsay Jones authored
      Sparse issues 68 errors (two errors for each main() function) such
      as the following:
      
            SP git.c
        git.c:510:5: error: too many arguments for function mingw_main
        git.c:510:5: error: symbol 'mingw_main' redeclared with different type \
          (originally declared at git.c:510) - different argument counts
      
      The errors are caused by the 'main' macro used by the MinGW build
      to provide a replacement main() function. The original main function
      is effectively renamed to 'mingw_main' and is called from the new
      main function. The replacement main is used to execute certain actions
      common to all git programs on MinGW (e.g. ensure the standard I/O
      streams are in binary mode).
      
      In order to suppress the errors, we change the macro to include the
      parameters in the declaration of the mingw_main function.
      
      Unfortunately, this change provokes both sparse and gcc to complain
      about 9 calls to mingw_main(), such as the following:
      
            CC git.o
        git.c: In function 'main':
        git.c:510: warning: passing argument 2 of 'mingw_main' from \
          incompatible pointer type
        git.c:510: note: expected 'const char **' but argument is of \
          type 'char **'
      
      In order to suppress these warnings, since both of the main
      functions need to be declared with the same prototype, we
      change the declaration of the 9 main functions, thus:
      
          int main(int argc, char **argv)
      Signed-off-by: default avatarRamsay Jones <ramsay@ramsay1.demon.co.uk>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      84d32bf7
  16. 15 Dec, 2012 1 commit
    • Jeff King's avatar
      remote-testsvn: fix unitialized variable · bfae342c
      Jeff King authored
      In remote-test-svn, there is a parse_rev_note function to
      parse lines of the form "Revision-number" from notes. If it
      finds such a line and parses it, it returns 0, copying the
      value into a "struct rev_note". If it finds an entry that is
      garbled or out of range, it returns -1 to signal an error.
      
      However, if it does not find any "Revision-number" line at
      all, it returns success but does not put anything into the
      rev_note. So upon a successful return, the rev_note may or
      may not be initialized, and the caller has no way of
      knowing.
      
      gcc does not usually catch the use of the unitialized
      variable because the conditional assignment happens in a
      separate function from the point of use. However, when
      compiling with -O3, gcc will inline parse_rev_note and
      notice the problem.
      
      We can fix it by returning "-1" when no note is found (so on
      a zero return, we always found a valid value).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      bfae342c
  17. 07 Oct, 2012 5 commits