1. 22 Feb, 2019 1 commit
    • Jeff Hostetler's avatar
      trace2: create new combined trace facility · ee4512ed
      Jeff Hostetler authored
      Create a new unified tracing facility for git.  The eventual intent is to
      replace the current trace_printf* and trace_performance* routines with a
      unified set of git_trace2* routines.
      In addition to the usual printf-style API, trace2 provides higer-level
      event verbs with fixed-fields allowing structured data to be written.
      This makes post-processing and analysis easier for external tools.
      Trace2 defines 3 output targets.  These are set using the environment
      variables "GIT_TR2", "GIT_TR2_PERF", and "GIT_TR2_EVENT".  These may be
      set to "1" or to an absolute pathname (just like the current GIT_TRACE).
      * GIT_TR2 is intended to be a replacement for GIT_TRACE and logs command
        summary data.
      * GIT_TR2_PERF is intended as a replacement for GIT_TRACE_PERFORMANCE.
        It extends the output with columns for the command process, thread,
        repo, absolute and relative elapsed times.  It reports events for
        child process start/stop, thread start/stop, and per-thread function
      * GIT_TR2_EVENT is a new structured format. It writes event data as a
        series of JSON records.
      Calls to trace2 functions log to any of the 3 output targets enabled
      without the need to call different trace_printf* or trace_performance*
      Signed-off-by: 's avatarJeff Hostetler <jeffhost@microsoft.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  2. 12 Feb, 2019 1 commit
  3. 03 Jan, 2019 1 commit
  4. 26 Dec, 2018 1 commit
    • Torsten Bögershausen's avatar
      git clone <url> C:\cygwin\home\USER\repo' is working (again) · 1cadad6f
      Torsten Bögershausen authored
      A regression for cygwin users was introduced with commit 05b458c1,
       "real_path: resolve symlinks by hand".
      In the the commit message we read:
        The current implementation of real_path uses chdir() in order to resolve
          symlinks.  Unfortunately this isn't thread-safe as chdir() affects a
            process as a whole...
      The old (and non-thread-save) OS calls chdir()/pwd() had been
      replaced by a string operation.
      The cygwin layer "knows" that "C:\cygwin" is an absolute path,
      but the new string operation does not.
      "git clone <url> C:\cygwin\home\USER\repo" fails like this:
      fatal: Invalid path '/home/USER/repo/C:\cygwin\home\USER\repo'
      The solution is to implement has_dos_drive_prefix(), skip_dos_drive_prefix()
      is_dir_sep(), offset_1st_component() and convert_slashes() for cygwin
      in the same way as it is done in 'Git for Windows' in compat/mingw.[ch]
      Extract the needed code into compat/win32/path-utils.[ch] and use it
      for cygwin as well.
      Reported-by: Steven Penny's avatarSteven Penny <svnpenn@gmail.com>
      Helped-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: 's avatarTorsten Bögershausen <tboegi@web.de>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  5. 09 Dec, 2018 1 commit
    • Duy Nguyen's avatar
      Indent code with TABs · ec36c42a
      Duy Nguyen authored
      We indent with TABs and sometimes for fine alignment, TABs followed by
      spaces, but never all spaces (unless the indentation is less than 8
      columns). Indenting with spaces slips through in some places. Fix
      Imported code and compat/ are left alone on purpose. The former should
      remain as close as upstream as possible. The latter pretty much has
      separate maintainers, it's up to them to decide.
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  6. 21 Nov, 2018 1 commit
    • Jeff King's avatar
      pack-objects: zero-initialize tree_depth/layer arrays · e159b810
      Jeff King authored
      Commit 108f5303 (pack-objects: move tree_depth into 'struct
      packing_data', 2018-08-16) started maintaining a tree_depth array that
      matches the "objects" array. We extend the array when:
        1. The objects array is extended, in which case we use realloc to
           extend the tree_depth array.
        2. A caller asks to store a tree_depth for object N, and this is the
           first such request; we create the array from scratch and store the
           value for N.
      In the latter case, though, we use regular xmalloc(), and the depth
      values for any objects besides N is undefined. This happens to not
      trigger a bug with the current code, but the reasons are quite subtle:
       - we never ask about the depth for any object with index i < N. This is
         because we store the depth immediately for all trees and blobs. So
         any such "i" must be a non-tree, and therefore we will never need to
         care about its depth (in fact, we really only care about the depth of
       - there are no objects at this point with index i > N, because we
         always fill in the depth for a tree immediately after its object
         entry is created (we may still allocate uninitialized depth entries,
         but they'll be initialized by packlist_alloc() when it initializes
         the entry in the "objects" array).
      So it works, but only by chance. To be defensive, let's zero the array,
      which matches the "unset" values which would be handed out by
      oe_tree_depth() already.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  7. 14 Nov, 2018 1 commit
  8. 31 Oct, 2018 1 commit
  9. 24 Oct, 2018 1 commit
  10. 16 Oct, 2018 1 commit
  11. 04 Oct, 2018 2 commits
    • Johannes Schindelin's avatar
      mingw: bump the minimum Windows version to Vista · 2939a1f7
      Johannes Schindelin authored
      Quite some time ago, a last plea to the XP users out there who want to
      see Windows XP support in Git for Windows, asking them to get engaged
      and help, vanished into the depths of the universe.
      We tried for a long time to play nice with the last remaining XP users
      who somehow manage to build Git from source, but a recent update of
      mingw-w64 ( -> finally dropped
      the last sign of XP support, and Git for Windows' SDK is no longer able
      to build core Git's `master` branch as a consequence. (Git for Windows'
      `master` branch already bumped the minimum Windows version to Vista a
      while ago, so it is fine.)
      It is time to require Windows Vista or later to build Git from source.
      This, incidentally, lets us use quite a few nice new APIs.
      It also means that we no longer need the inet_pton() and inet_ntop()
      emulation, which is nice.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
    • Johannes Schindelin's avatar
      mingw: set _WIN32_WINNT explicitly for Git for Windows · 3571e78a
      Johannes Schindelin authored
      Previously, we only ever declared a target Windows version if compiling
      with Visual C.
      Which meant that we were relying on the MinGW headers to guess which
      Windows version we want to target...
      Let's be explicit about it, in particular because we actually want to
      bump the target Windows version to Vista (which we will do in the next
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  12. 08 Aug, 2018 1 commit
  13. 26 Jul, 2018 1 commit
    • Jeff King's avatar
      automatically ban strcpy() · c8af66ab
      Jeff King authored
      There are a few standard C functions (like strcpy) which are
      easy to misuse. E.g.:
        char path[PATH_MAX];
        strcpy(path, arg);
      may overflow the "path" buffer. Sometimes there's an earlier
      constraint on the size of "arg", but even in such a case
      it's hard to verify that the code is correct. If the size
      really is unbounded, you're better off using a dynamic
      helper like strbuf:
        struct strbuf path = STRBUF_INIT;
        strbuf_addstr(path, arg);
      or if it really is bounded, then use xsnprintf to show your
      expectation (and get a run-time assertion):
        char path[PATH_MAX];
        xsnprintf(path, sizeof(path), "%s", arg);
      which makes further auditing easier.
      We'd usually catch undesirable code like this in a review,
      but there's no automated enforcement. Adding that
      enforcement can help us be more consistent and save effort
      (and a round-trip) during review.
      This patch teaches the compiler to report an error when it
      sees strcpy (and will become a model for banning a few other
      functions). This has a few advantages over a separate
      linting tool:
        1. We know it's run as part of a build cycle, so it's
           hard to ignore. Whereas an external linter is an extra
           step the developer needs to remember to do.
        2. Likewise, it's basically free since the compiler is
           parsing the code anyway.
        3. We know it's robust against false positives (unlike a
           grep-based linter).
      The two big disadvantages are:
        1. We'll only check code that is actually compiled, so it
           may miss code that isn't triggered on your particular
           system. But since presumably people don't add new code
           without compiling it (and if they do, the banned
           function list is the least of their worries), we really
           only care about failing to clean up old code when
           adding new functions to the list. And that's easy
           enough to address with a manual audit when adding a new
           function (which is what I did for the functions here).
        2. If this ends up generating false positives, it's going
           to be harder to disable (as opposed to a separate
           linter, which may have mechanisms for overriding a
           particular case).
           But the intent is to only ban functions which are
           obviously bad, and for which we accept using an
           alternative even when this particular use isn't buggy
           (e.g., the xsnprintf alternative above).
      The implementation here is simple: we'll define a macro for
      the banned function which replaces it with a reference to a
      descriptively named but undeclared identifier.  Replacing it
      with any invalid code would work (since we just want to
      break compilation).  But ideally we'd meet these goals:
       - it should be portable; ideally this would trigger
         everywhere, and does not need to be part of a DEVELOPER=1
         setup (because unlike warnings which may depend on the
         compiler or system, this is a clear indicator of
         something wrong in the code).
       - it should generate a readable error that gives the
         developer a clue what happened
       - it should avoid generating too much other cruft that
         makes it hard to see the actual error
       - it should mention the original callsite in the error
      The output with this patch looks like this (using gcc 7, on
      a checkout with 022d2ac1 reverted, which removed the final
      strcpy from blame.c):
            CC builtin/blame.o
        In file included from ./git-compat-util.h:1246,
                         from ./cache.h:4,
                         from builtin/blame.c:8:
        builtin/blame.c: In function ‘cmd_blame’:
        ./banned.h:11:22: error: ‘sorry_strcpy_is_a_banned_function’ undeclared (first use in this function)
         #define BANNED(func) sorry_##func##_is_a_banned_function
        ./banned.h:14:21: note: in expansion of macro ‘BANNED’
         #define strcpy(x,y) BANNED(strcpy)
        builtin/blame.c:1074:4: note: in expansion of macro ‘strcpy’
            strcpy(repeated_meta_color, GIT_COLOR_CYAN);
        ./banned.h:11:22: note: each undeclared identifier is reported only once for each function it appears in
         #define BANNED(func) sorry_##func##_is_a_banned_function
        ./banned.h:14:21: note: in expansion of macro ‘BANNED’
         #define strcpy(x,y) BANNED(strcpy)
        builtin/blame.c:1074:4: note: in expansion of macro ‘strcpy’
            strcpy(repeated_meta_color, GIT_COLOR_CYAN);
      This prominently shows the phrase "strcpy is a banned
      function", along with the original callsite in blame.c and
      the location of the ban code in banned.h. Which should be
      enough to get even a developer seeing this for the first
      time pointed in the right direction.
      This doesn't match our ideals perfectly, but it's a pretty
      good balance. A few alternatives I tried:
        1. Instead of using an undeclared variable, using an
           undeclared function. This shortens the message, because
           the "each undeclared identifier" message is not needed
           (and as you can see above, it triggers a separate
           mention of each of the expansion points).
           But it doesn't actually stop compilation unless you use
           -Werror=implicit-function-declaration in your CFLAGS.
           This is the case for DEVELOPER=1, but not for a default
           build (on the other hand, we'd eventually produce a
           link error pointing to the correct source line with the
           descriptive name).
        2. The linux kernel uses a similar mechanism in its
           BUILD_BUG_ON_MSG(), where they actually declare the
           function but do so with gcc's error attribute. But
           that's not portable to other compilers (and it also
           runs afoul of our error() macro).
           We could make a gcc-specific technique and fallback on
           other compilers, but it's probably not worth the
           complexity. It also isn't significantly shorter than
           the error message shown above.
        3. We could drop the BANNED() macro, which would shorten
           the number of lines in the error. But curiously,
           removing it (and just expanding strcpy directly to the
           bogus identifier) causes gcc _not_ to report the
           original line of code.
      So this strategy seems to be an acceptable mix of
      information, portability, simplicity, and robustness,
      without _too_ much extra clutter. I also tested it with
      clang, and it looks as good (actually, slightly less
      cluttered than with gcc).
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  14. 22 May, 2018 1 commit
    • Jeff King's avatar
      skip_prefix: add case-insensitive variant · 41a80924
      Jeff King authored
      We have the convenient skip_prefix() helper, but if you want
      to do case-insensitive matching, you're stuck doing it by
      hand. We could add an extra parameter to the function to
      let callers ask for this, but the function is small and
      somewhat performance-critical. Let's just re-implement it
      for the case-insensitive version.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
  15. 10 May, 2018 1 commit
  16. 06 May, 2018 1 commit
  17. 16 Apr, 2018 1 commit
    • Duy Nguyen's avatar
      gc --auto: exclude base pack if not enough mem to "repack -ad" · 9806f5a7
      Duy Nguyen authored
      pack-objects could be a big memory hog especially on large repos,
      everybody knows that. The suggestion to stick a .keep file on the
      giant base pack to avoid this problem is also known for a long time.
      Recent patches add an option to do just this, but it has to be either
      configured or activated manually. This patch lets `git gc --auto`
      activate this mode automatically when it thinks `repack -ad` will use
      a lot of memory and start affecting the system due to swapping or
      flushing OS cache.
      gc --auto decides to do this based on an estimation of pack-objects
      memory usage, which is quite accurate at least for the heap part, and
      whether that fits in half of system memory (the assumption here is for
      desktop environment where there are many other applications running).
      This mechanism only kicks in if gc.bigBasePackThreshold is not configured.
      If it is, it is assumed that the user already knows what they want.
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  18. 09 Mar, 2018 1 commit
  19. 22 Feb, 2018 1 commit
  20. 12 Dec, 2017 1 commit
    • Christian Couder's avatar
      git-compat-util: introduce skip_to_optional_arg() · afaef55e
      Christian Couder authored
      We often accept both a "--key" option and a "--key=<val>" option.
      These options currently are parsed using something like:
      if (!strcmp(arg, "--key")) {
      	/* do something */
      } else if (skip_prefix(arg, "--key=", &arg)) {
      	/* do something with arg */
      which is a bit cumbersome compared to just:
      if (skip_to_optional_arg(arg, "--key", &arg)) {
      	/* do something with arg */
      This also introduces skip_to_optional_arg_default() for the few
      cases where something different should be done when the first
      argument is exactly "--key" than when it is exactly "--key=".
      In general it is better for UI consistency and simplicity if
      "--key" and "--key=" do the same thing though, so that using
      skip_to_optional_arg() should be encouraged compared to
      Note that these functions can be used to parse any "key=value"
      string where "key" is also considered as valid, not just
      command line options.
      Signed-off-by: Christian Couder's avatarChristian Couder <chriscool@tuxfamily.org>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  21. 22 Sep, 2017 1 commit
  22. 20 Sep, 2017 1 commit
    • Jonathan Tan's avatar
      git-compat-util: make UNLEAK less error-prone · 5de3de32
      Jonathan Tan authored
      Commit 0e5bba53 ("add UNLEAK annotation for reducing leak false
      positives", 2017-09-08) introduced an UNLEAK macro to be used as
      "UNLEAK(var);", but its existing definitions leave semicolons that act
      as empty statements, which will lead to syntax errors, e.g.
      	if (condition)
      would be broken with two statements between if (condition) and else.
      Lose the excess semicolon from the end of the macro replacement text.
      Signed-off-by: 's avatarJonathan Tan <jonathantanmy@google.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  23. 08 Sep, 2017 1 commit
    • Jeff King's avatar
      add UNLEAK annotation for reducing leak false positives · 0e5bba53
      Jeff King authored
      It's a common pattern in git commands to allocate some
      memory that should last for the lifetime of the program and
      then not bother to free it, relying on the OS to throw it
      This keeps the code simple, and it's fast (we don't waste
      time traversing structures or calling free at the end of the
      program). But it also triggers warnings from memory-leak
      checkers like valgrind or LSAN. They know that the memory
      was still allocated at program exit, but they don't know
      _when_ the leaked memory stopped being useful. If it was
      early in the program, then it's probably a real and
      important leak. But if it was used right up until program
      exit, it's not an interesting leak and we'd like to suppress
      it so that we can see the real leaks.
      This patch introduces an UNLEAK() macro that lets us do so.
      To understand its design, let's first look at some of the
      Unfortunately the suppression systems offered by
      leak-checking tools don't quite do what we want. A
      leak-checker basically knows two things:
        1. Which blocks were allocated via malloc, and the
           callstack during the allocation.
        2. Which blocks were left un-freed at the end of the
           program (and which are unreachable, but more on that
      Their suppressions work by mentioning the function or
      callstack of a particular allocation, and marking it as OK
      to leak.  So imagine you have code like this:
        int cmd_foo(...)
      	/* this allocates some memory */
      	char *p = some_function();
      	printf("%s", p);
      	return 0;
      You can say "ignore allocations from some_function(),
      they're not leaks". But that's not right. That function may
      be called elsewhere, too, and we would potentially want to
      know about those leaks.
      So you can say "ignore the callstack when main calls
      some_function".  That works, but your annotations are
      brittle. In this case it's only two functions, but you can
      imagine that the actual allocation is much deeper. If any of
      the intermediate code changes, you have to update the
      What we _really_ want to say is that "the value assigned to
      p at the end of the function is not a real leak". But
      leak-checkers can't understand that; they don't know about
      "p" in the first place.
      However, we can do something a little bit tricky if we make
      some assumptions about how leak-checkers work. They
      generally don't just report all un-freed blocks. That would
      report even globals which are still accessible when the
      leak-check is run.  Instead they take some set of memory
      (like BSS) as a root and mark it as "reachable". Then they
      scan the reachable blocks for anything that looks like a
      pointer to a malloc'd block, and consider that block
      reachable. And then they scan those blocks, and so on,
      transitively marking anything reachable from a global as
      "not leaked" (or at least leaked in a different category).
      So we can mark the value of "p" as reachable by putting it
      into a variable with program lifetime. One way to do that is
      to just mark "p" as static. But that actually affects the
      run-time behavior if the function is called twice (you
      aren't likely to call main() twice, but some of our cmd_*()
      functions are called from other commands).
      Instead, we can trick the leak-checker by putting the value
      into _any_ reachable bytes. This patch keeps a global
      linked-list of bytes copied from "unleaked" variables. That
      list is reachable even at program exit, which confers
      recursive reachability on whatever values we unleak.
      In other words, you can do:
        int cmd_foo(...)
      	char *p = some_function();
      	printf("%s", p);
      	return 0;
      to annotate "p" and suppress the leak report.
      But wait, couldn't we just say "free(p)"? In this toy
      example, yes. But UNLEAK()'s byte-copying strategy has
      several advantages over actually freeing the memory:
        1. It's recursive across structures. In many cases our "p"
           is not just a pointer, but a complex struct whose
           fields may have been allocated by a sub-function. And
           in some cases (e.g., dir_struct) we don't even have a
           function which knows how to free all of the struct
           By marking the struct itself as reachable, that confers
           reachability on any pointers it contains (including those
           found in embedded structs, or reachable by walking
           heap blocks recursively.
        2. It works on cases where we're not sure if the value is
           allocated or not. For example:
             char *p = argc > 1 ? argv[1] : some_function();
           It's safe to use UNLEAK(p) here, because it's not
           freeing any memory. In the case that we're pointing to
           argv here, the reachability checker will just ignore
           our bytes.
        3. Likewise, it works even if the variable has _already_
           been freed. We're just copying the pointer bytes. If
           the block has been freed, the leak-checker will skip
           over those bytes as uninteresting.
        4. Because it's not actually freeing memory, you can
           UNLEAK() before we are finished accessing the variable.
           This is helpful in cases like this:
             char *p = some_function();
             return another_function(p);
           Writing this with free() requires:
             int ret;
             char *p = some_function();
             ret = another_function(p);
             return ret;
           But with unleak we can just write:
             char *p = some_function();
             return another_function(p);
      This patch adds the UNLEAK() macro and enables it
      automatically when Git is compiled with SANITIZE=leak.  In
      normal builds it's a noop, so we pay no runtime cost.
      It also adds some UNLEAK() annotations to show off how the
      feature works. On top of other recent leak fixes, these are
      enough to get t0000 and t0001 to pass when compiled with
      Note the case in commit.c which actually converts a
      strbuf_release() into an UNLEAK. This code was already
      non-leaky, but the free didn't do anything useful, since
      we're exiting. Converting it to an annotation means that
      non-leak-checking builds pay no runtime cost. The cost is
      minimal enough that it's probably not worth going on a
      crusade to convert these kinds of frees to UNLEAKS. I did it
      here for consistency with the "sb" leak (though it would
      have been equally correct to go the other way, and turn them
      both into strbuf_release() calls).
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  24. 23 Aug, 2017 1 commit
  25. 17 Jul, 2017 1 commit
    • René Scharfe's avatar
      add MOVE_ARRAY · 57839807
      René Scharfe authored
      Similar to COPY_ARRAY (introduced in 60566cbb), add a safe and
      convenient helper for moving potentially overlapping ranges of array
      entries.  It infers the element size, multiplies automatically and
      safely to get the size in bytes, does a basic type safety check by
      comparing element sizes and unlike memmove(3) it supports NULL
      pointers iff 0 elements are to be moved.
      Also add a semantic patch to demonstrate the helper's intended usage.
      Signed-off-by: 's avatarRene Scharfe <l.s.r@web.de>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  26. 05 Jul, 2017 1 commit
    • Torsten Bögershausen's avatar
      cygwin: allow pushing to UNC paths · 496f2569
      Torsten Bögershausen authored
       cygwin can use an UNC path like //server/share/repo
       $ cd //server/share/dir
       $ mkdir test
       $ cd test
       $ git init --bare
       However, when we try to push from a local Git repository to this repo,
       there is a problem: Git converts the leading "//" into a single "/".
       As cygwin handles an UNC path so well, Git can support them better:
       - Introduce cygwin_offset_1st_component() which keeps the leading "//",
         similar to what Git for Windows does.
       - Move CYGWIN out of the POSIX in the tests for path normalization in t0060
      Signed-off-by: 's avatarTorsten Bögershausen <tboegi@web.de>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  27. 15 Jun, 2017 1 commit
  28. 30 May, 2017 1 commit
    • Junio C Hamano's avatar
      compat-util: is_missing_file_error() · dc5a18b3
      Junio C Hamano authored
      Our code often opens a path to an optional file, to work on its
      contents when we can successfully open it.  We can ignore a failure
      to open if such an optional file does not exist, but we do want to
      report a failure in opening for other reasons (e.g. we got an I/O
      error, or the file is there, but we lack the permission to open).
      The exact errors we need to ignore are ENOENT (obviously) and
      ENOTDIR (less obvious).  Instead of repeating comparison of errno
      with these two constants, introduce a helper function to do so.
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  29. 26 May, 2017 4 commits
  30. 15 May, 2017 2 commits
    • Jeff King's avatar
      usage.c: drop set_error_handle() · e3f43ce7
      Jeff King authored
      The set_error_handle() function was introduced by 3b331e92
      (vreportf: report to arbitrary filehandles, 2015-08-11) so
      that run-command could send post-fork, pre-exec errors to
      the parent's original stderr.
      That use went away in 79319b19 (run-command: eliminate
      calls to error handling functions in child, 2017-04-19),
      which pushes all of the error reporting to the parent.
      This leaves no callers of set_error_handle(). As we're not
      likely to add any new ones, let's drop it.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Acked-by: 's avatarBrandon Williams <bmwill@google.com>
      Reviewed-by: 's avatarRamsay Jones <ramsay@ramsayjones.plus.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      usage.c: add BUG() function · d8193743
      Jeff King authored
      There's a convention in Git's code base to write assertions
        if (...some_bad_thing...)
      	die("BUG: the terrible thing happened");
      with the idea that users should never see a "BUG:" message
      (but if they, it at least gives a clue what happened).  We
      use die() here because it's convenient, but there are a few
        1. Without parsing the messages, it's hard for callers to
           distinguish BUG assertions from regular errors.
           For instance, it would be nice if the test suite could
           check that we don't hit any assertions, but
           test_must_fail will pass BUG deaths as OK.
        2. It would be useful to add more debugging features to
           BUG assertions, like file/line numbers or dumping core.
        3. The die() handler can be replaced, and might not
           actually exit the whole program (e.g., it may just
           pthread_exit()). This is convenient for normal errors,
           but for an assertion failure (which is supposed to
           never happen), we're probably better off taking down
           the whole process as quickly and cleanly as possible.
      We could address these by checking in die() whether the
      error message starts with "BUG", and behaving appropriately.
      But there's little advantage at that point to sharing the
      die() code, and only downsides (e.g., we can't change the
      BUG() interface independently). Moreover, converting all of
      the existing BUG calls reveals that the test suite does
      indeed trigger a few of them.
      Instead, this patch introduces a new BUG() function, which
      prints an error before dying via SIGABRT. This gives us test
      suite checking and core dumps.  The function is actually a
      macro (when supported) so that we can show the file/line
      We can convert die("BUG") invocations to BUG() in further
      patches, dealing with any test fallouts individually.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  31. 27 Apr, 2017 2 commits
    • Johannes Schindelin's avatar
      use uintmax_t for timestamps · 28f4aee3
      Johannes Schindelin authored
      Previously, we used `unsigned long` for timestamps. This was only a good
      choice on Linux, where we know implicitly that `unsigned long` is what is
      used for `time_t`.
      However, we want to use a different data type for timestamps for two
      - there is nothing that says that `unsigned long` should be the same data
        type as `time_t`, and indeed, on 64-bit Windows for example, it is not:
        `unsigned long` is 32-bit but `time_t` is 64-bit.
      - even on 32-bit Linux, where `unsigned long` (and thereby `time_t`) is
        32-bit, we *want* to be able to encode timestamps in Git that are
        currently absurdly far in the future, *even if* the system library is
        not able to format those timestamps into date strings.
      So let's just switch to the maximal integer type available, which should
      be at least 64-bit for all practical purposes these days. It certainly
      cannot be worse than `unsigned long`, so...
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
    • Johannes Schindelin's avatar
      timestamp_t: a new data type for timestamps · dddbad72
      Johannes Schindelin authored
      Git's source code assumes that unsigned long is at least as precise as
      time_t. Which is incorrect, and causes a lot of problems, in particular
      where unsigned long is only 32-bit (notably on Windows, even in 64-bit
      So let's just use a more appropriate data type instead. In preparation
      for this, we introduce the new `timestamp_t` data type.
      By necessity, this is a very, very large patch, as it has to replace all
      timestamps' data type in one go.
      As we will use a data type that is not necessarily identical to `time_t`,
      we need to be very careful to use `time_t` whenever we interact with the
      system functions, and `timestamp_t` everywhere else.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  32. 24 Apr, 2017 2 commits
  33. 21 Apr, 2017 1 commit
    • David Turner (TS)'s avatar
      Increase core.packedGitLimit · be4ca290
      David Turner (TS) authored
      When core.packedGitLimit is exceeded, git will close packs.  If there
      is a repack operation going on in parallel with a fetch, the fetch
      might open a pack, and then be forced to close it due to
      packedGitLimit being hit.  The repack could then delete the pack
      out from under the fetch, causing the fetch to fail.
      Increase core.packedGitLimit's default value to prevent
      On current 64-bit x86_64 machines, 48 bits of address space are
      available.  It appears that 64-bit ARM machines have no standard
      amount of address space (that is, it varies by manufacturer), and IA64
      and POWER machines have the full 64 bits.  So 48 bits is the only
      limit that we can reasonably care about.  We reserve a few bits of the
      48-bit address space for the kernel's use (this is not strictly
      necessary, but it's better to be safe), and use up to the remaining
      45.  No git repository will be anywhere near this large any time soon,
      so this should prevent the failure.
      Helped-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: David Turner (TS)'s avatarDavid Turner <dturner@twosigma.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>