Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Jan 9, 2015
  1. @reubenhwk @gitster

    configure.ac: check for clock_gettime and CLOCK_MONOTONIC

    reubenhwk authored gitster committed
    Set or clear Makefile variables HAVE_CLOCK_GETTIME and
    HAVE_CLOCK_MONOTONIC based upon results of the checks (overriding
    default values from config.mak.uname).
    
    CLOCK_MONOTONIC isn't available on RHEL3, but there are still RHEL3
    systems being used in production.
    
    Signed-off-by: Reuben Hawkins <reubenhwk@gmail.com>
    Reviewed-by: Eric Sunshine <sunshine@sunshineco.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Dec 22, 2014
  1. @gitster

    Merge branch 'rs/use-strbuf-complete-line'

    gitster authored
    * rs/use-strbuf-complete-line:
      use strbuf_complete_line() for adding a newline if needed
Commits on Dec 12, 2014
  1. @gitster

    use strbuf_complete_line() for adding a newline if needed

    René Scharfe authored gitster committed
    Call strbuf_complete_line() instead of open-coding it.  Also remove
    surrounding comments indicating the intent to complete a line since
    this information is already included in the function name.
    
    Signed-off-by: Rene Scharfe <l.s.r@web.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Oct 16, 2014
  1. @gitster

    Merge branch 'bw/trace-no-inline-getnanotime'

    gitster authored
    No file-scope static variables in an inlined function, please.
    
    * bw/trace-no-inline-getnanotime:
      trace.c: do not mark getnanotime() as "inline"
Commits on Sep 29, 2014
  1. @bdwalton @gitster

    trace.c: do not mark getnanotime() as "inline"

    bdwalton authored gitster committed
    Oracle Studio compilers don't allow for static variables in
    functions that are defined to be inline. GNU C does permit this.
    
    Let's reference the C99 standard though, which doesn't allow for
    inline functions to contain modifiable static variables.
    
    Signed-off-by: Ben Walton <bdwalton@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Sep 19, 2014
  1. @gitster

    Merge branch 'kb/perf-trace'

    gitster authored
    Compilation fix for some compilers.
    
    * kb/perf-trace:
      trace: correct trace_strbuf() parameter type for !HAVE_VARIADIC_MACROS
Commits on Sep 8, 2014
  1. @gitster

    trace: correct trace_strbuf() parameter type for !HAVE_VARIADIC_MACROS

    René Scharfe authored gitster committed
    Reported-by: dev <dev@cor0.com>
    Signed-off-by: Rene Scharfe <l.s.r@web.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Sep 2, 2014
  1. @gitster

    Merge branch 'rs/strbuf-getcwd'

    gitster authored
    Reduce the use of fixed sized buffer passed to getcwd() calls
    by introducing xgetcwd() helper.
    
    * rs/strbuf-getcwd:
      use strbuf_add_absolute_path() to add absolute paths
      abspath: convert absolute_path() to strbuf
      use xgetcwd() to set $GIT_DIR
      use xgetcwd() to get the current directory or die
      wrapper: add xgetcwd()
      abspath: convert real_path_internal() to strbuf
      abspath: use strbuf_getcwd() to remember original working directory
      setup: convert setup_git_directory_gently_1 et al. to strbuf
      unix-sockets: use strbuf_getcwd()
      strbuf: add strbuf_getcwd()
Commits on Aug 26, 2014
  1. @gitster

    use xgetcwd() to get the current directory or die

    René Scharfe authored gitster committed
    Convert several calls of getcwd() and die() to use xgetcwd() instead.
    This way we get rid of fixed-size buffers (which can be too small
    depending on the used file system) and gain consistent error messages.
    
    Signed-off-by: Rene Scharfe <l.s.r@web.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Jul 14, 2014
  1. @kblees @gitster

    git: add performance tracing for git's main() function to debug scripts

    kblees authored gitster committed
    Use trace_performance to measure and print execution time and command line
    arguments of the entire main() function. In constrast to the shell's 'time'
    utility, which measures total time of the parent process, this logs all
    involved git commands recursively. This is particularly useful to debug
    performance issues of scripted commands (i.e. which git commands were
    called with which parameters, and how long did they execute).
    
    Due to git's deliberate use of exit(), the implementation uses an atexit
    routine rather than just adding trace_performance_since() at the end of
    main().
    
    Usage example: > GIT_TRACE_PERFORMANCE=~/git-trace.log git stash list
    
    Creates a log file like this:
    23:57:38.638765 trace.c:405 performance: 0.000310107 s: git command: 'git' 'rev-parse' '--git-dir'
    23:57:38.644387 trace.c:405 performance: 0.000261759 s: git command: 'git' 'rev-parse' '--show-toplevel'
    23:57:38.646207 trace.c:405 performance: 0.000304468 s: git command: 'git' 'config' '--get-colorbool' 'color.interactive'
    23:57:38.648491 trace.c:405 performance: 0.000241667 s: git command: 'git' 'config' '--get-color' 'color.interactive.help' 'red bold'
    23:57:38.650465 trace.c:405 performance: 0.000243063 s: git command: 'git' 'config' '--get-color' '' 'reset'
    23:57:38.654850 trace.c:405 performance: 0.025126313 s: git command: 'git' 'stash' 'list'
    
    Signed-off-by: Karsten Blees <blees@dcon.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  2. @kblees @gitster

    trace: add trace_performance facility to debug performance issues

    kblees authored gitster committed
    Add trace_performance and trace_performance_since macros that print a
    duration and an optional printf-formatted text to the file specified in
    environment variable GIT_TRACE_PERFORMANCE.
    
    These macros, in conjunction with getnanotime(), are intended to simplify
    performance measurements from within the application (i.e. profiling via
    manual instrumentation, rather than using an external profiling tool).
    
    Unless enabled via GIT_TRACE_PERFORMANCE, these macros have no noticeable
    impact on performance, so that test code for well known time killers may
    be shipped in release builds. Alternatively, a developer could provide an
    additional performance patch (not meant for master) that allows reviewers
    to reproduce performance tests more easily, e.g. on other platforms or
    using their own repositories.
    
    Usage examples:
    
    Simple use case (measure one code section):
    
      uint64_t start = getnanotime();
      /* code section to measure */
      trace_performance_since(start, "foobar");
    
    Complex use case (measure repetitive code sections):
    
      uint64_t t = 0;
      for (;;) {
        /* ignore */
        t -= getnanotime();
        /* code section to measure */
        t += getnanotime();
        /* ignore */
      }
      trace_performance(t, "frotz");
    
    Signed-off-by: Karsten Blees <blees@dcon.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  3. @kblees @gitster

    trace: add high resolution timer function to debug performance issues

    kblees authored gitster committed
    Add a getnanotime() function that returns nanoseconds since 01/01/1970 as
    unsigned 64-bit integer (i.e. overflows in july 2554). This is easier to
    work with than e.g. struct timeval or struct timespec. Basing the timer on
    the epoch allows using the results with other time-related APIs.
    
    To simplify adaption to different platforms, split the implementation into
    a common getnanotime() and a platform-specific highres_nanos() function.
    
    The common getnanotime() function handles errors, falling back to
    gettimeofday() if highres_nanos() isn't implemented or doesn't work.
    
    getnanotime() is also responsible for normalizing to the epoch. The offset
    to the system clock is calculated only once on initialization, i.e.
    manually setting the system clock has no impact on the timer (except if
    the fallback gettimeofday() is in use). Git processes are typically short
    lived, so we don't need to handle clock drift.
    
    The highres_nanos() function returns monotonically increasing nanoseconds
    relative to some arbitrary point in time (e.g. system boot), or 0 on
    failure. Providing platform-specific implementations should be relatively
    easy, e.g. adapting to clock_gettime() as defined by the POSIX realtime
    extensions is seven lines of code.
    
    This version includes highres_nanos() implementations for:
     * Linux: using clock_gettime(CLOCK_MONOTONIC)
     * Windows: using QueryPerformanceCounter()
    
    Todo:
     * enable clock_gettime() on more platforms
     * add Mac OSX version, e.g. using mach_absolute_time + mach_timebase_info
    
    Signed-off-by: Karsten Blees <blees@dcon.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  4. @kblees @gitster

    trace: add 'file:line' to all trace output

    kblees authored gitster committed
    This is useful to see where trace output came from.
    
    Add 'const char *file, int line' parameters to the printing functions and
    rename them to *_fl.
    
    Add trace_printf* and trace_strbuf macros resolving to the *_fl functions
    and let the preprocessor fill in __FILE__ and __LINE__.
    
    As the trace_printf* functions take a variable number of arguments, this
    requires variadic macros (i.e. '#define foo(...) foo_impl(__VA_ARGS__)'.
    Though part of C99, it is unclear whether older compilers support this.
    Thus keep the old functions and only enable variadic macros for GNUC and
    MSVC 2005+ (_MSC_VER 1400). This has the nice side effect that the old
    C-style declarations serve as documentation how the macros are to be used.
    
    Print 'file:line ' as prefix to each trace line. Align the remaining trace
    output at column 40 to accommodate 18 char file names + 4 digit line
    number (currently there are 30 *.c files of length 18 and just 11 of 19).
    Trace output from longer source files (e.g. builtin/receive-pack.c) will
    not be aligned.
    
    Signed-off-by: Karsten Blees <blees@dcon.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  5. @kblees @gitster

    trace: move code around, in preparation to file:line output

    kblees authored gitster committed
    No functional changes, just move stuff around so that the next patch isn't
    that ugly...
    
    Signed-off-by: Karsten Blees <blees@dcon.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  6. @kblees @gitster

    trace: add current timestamp to all trace output

    kblees authored gitster committed
    This is useful to tell apart trace output of separate test runs.
    
    It can also be used for basic, coarse-grained performance analysis. Note
    that the accuracy is tainted by writing to the trace file, and you have to
    calculate the deltas yourself (which is next to impossible if multiple
    threads or processes are involved).
    
    Signed-off-by: Karsten Blees <blees@dcon.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  7. @kblees @gitster

    trace: disable additional trace output for unit tests

    kblees authored gitster committed
    Some unit-tests use trace output to verify internal state, and unstable
    output such as timestamps and line numbers are not useful there.
    
    Disable additional trace output if GIT_TRACE_BARE is set.
    
    Signed-off-by: Karsten Blees <blees@dcon.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  8. @kblees @gitster

    trace: add infrastructure to augment trace output with additional info

    kblees authored gitster committed
    To be able to add a common prefix or suffix to all trace output (e.g.
    a timestamp or file:line of the caller), factor out common setup and
    cleanup tasks of the trace* functions.
    
    When adding a common prefix, it makes sense that the output of each trace
    call starts on a new line. Add '\n' in case the caller forgot.
    
    Note that this explicitly limits trace output to line-by-line, it is no
    longer possible to trace-print just part of a line. Until now, this was
    just an implicit assumption (trace-printing part of a line worked, but
    messed up the trace file if multiple threads or processes were involved).
    
    Thread-safety / inter-process-safety is also the reason why we need to do
    the prefixing and suffixing in memory rather than issuing multiple write()
    calls. Write_or_whine_pipe() / xwrite() is atomic unless the size exceeds
    MAX_IO_SIZE (8MB, see wrapper.c). In case of trace_strbuf, this costs an
    additional string copy (which should be irrelevant for performance in light
    of actual file IO).
    
    While we're at it, rename trace_strbuf's 'buf' argument, which suggests
    that the function is modifying the buffer. Trace_strbuf() currently is the
    only trace API that can print arbitrary binary data (without barfing on
    '%' or stopping at '\0'), so 'data' seems more appropriate.
    
    Signed-off-by: Karsten Blees <blees@dcon.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  9. @kblees @gitster

    trace: improve trace performance

    kblees authored gitster committed
    The trace API currently rechecks the environment variable and reopens the
    trace file on every API call. This has the ugly side effect that errors
    (e.g. file cannot be opened, or the user specified a relative path) are
    also reported on every call. Performance can be improved by about factor
    three by remembering the environment state and keeping the file open.
    
    Replace the 'const char *key' parameter in the API with a pointer to a
    'struct trace_key' that bundles the environment variable name with
    additional, trace-internal state. Change the call sites of these APIs to
    use a static 'struct trace_key' instead of a string constant.
    
    In trace.c::get_trace_fd(), save and reuse the file descriptor in 'struct
    trace_key'.
    
    Add a 'trace_disable()' API, so that packet_trace() can cleanly disable
    tracing when it encounters packed data (instead of using unsetenv()).
    
    Signed-off-by: Karsten Blees <blees@dcon.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Jun 17, 2014
  1. @kblees @gitster

    trace: remove redundant printf format attribute

    kblees authored gitster committed
    trace_printf_key() is the only non-static function that duplicates the
    printf format attribute in the .c file, remove it for consistency.
    
    Signed-off-by: Karsten Blees <blees@dcon.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  2. @kblees @gitster

    trace: consistently name the format parameter

    kblees authored gitster committed
    The format parameter to trace_printf functions is sometimes abbreviated
    'fmt'. Rename to 'format' everywhere (consistent with POSIX' printf
    specification).
    
    Signed-off-by: Karsten Blees <blees@dcon.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Dec 11, 2013
  1. @pclouds @gitster

    shallow.c: the 8 steps to select new commits for .git/shallow

    pclouds authored gitster committed
    Suppose a fetch or push is requested between two shallow repositories
    (with no history deepening or shortening). A pack that contains
    necessary objects is transferred over together with .git/shallow of
    the sender. The receiver has to determine whether it needs to update
    .git/shallow if new refs needs new shallow comits.
    
    The rule here is avoid updating .git/shallow by default. But we don't
    want to waste the received pack. If the pack contains two refs, one
    needs new shallow commits installed in .git/shallow and one does not,
    we keep the latter and reject/warn about the former.
    
    Even if .git/shallow update is allowed, we only add shallow commits
    strictly necessary for the former ref (remember the sender can send
    more shallow commits than necessary) and pay attention not to
    accidentally cut the receiver history short (no history shortening is
    asked for)
    
    So the steps to figure out what ref need what new shallow commits are:
    
    1. Split the sender shallow commit list into "ours" and "theirs" list
       by has_sha1_file. Those that exist in current repo in "ours", the
       remaining in "theirs".
    
    2. Check the receiver .git/shallow, remove from "ours" the ones that
       also exist in .git/shallow.
    
    3. Fetch the new pack. Either install or unpack it.
    
    4. Do has_sha1_file on "theirs" list again. Drop the ones that fail
       has_sha1_file. Obviously the new pack does not need them.
    
    5. If the pack is kept, remove from "ours" the ones that do not exist
       in the new pack.
    
    6. Walk the new refs to answer the question "what shallow commits,
       both ours and theirs, are required in .git/shallow in order to add
       this ref?". Shallow commits not associated to any refs are removed
       from their respective list.
    
    7. (*) Check reachability (from the current refs) of all remaining
       commits in "ours". Those reachable are removed. We do not want to
       cut any part of our (reachable) history. We only check up
       commits. True reachability test is done by
       check_everything_connected() at the end as usual.
    
    8. Combine the final "ours" and "theirs" and add them all to
       .git/shallow. Install new refs. The case where some hook rejects
       some refs on a push is explained in more detail in the push
       patches.
    
    Of these steps, #6 and #7 are expensive. Both require walking through
    some commits, or in the worst case all commits. And we rather avoid
    them in at least common case, where the transferred pack does not
    contain any shallow commits that the sender advertises. Let's look at
    each scenario:
    
    1) the sender has longer history than the receiver
    
       All shallow commits from the sender will be put into "theirs" list
       at step 1 because none of them exists in current repo. In the
       common case, "theirs" becomes empty at step 4 and exit early.
    
    2) the sender has shorter history than the receiver
    
       All shallow commits from the sender are likely in "ours" list at
       step 1. In the common case, if the new pack is kept, we could empty
       "ours" and exit early at step 5.
    
       If the pack is not kept, we hit the expensive step 6 then exit
       after "ours" is emptied. There'll be only a handful of objects to
       walk in fast-forward case. If it's forced update, we may need to
       walk to the bottom.
    
    3) the sender has same .git/shallow as the receiver
    
       This is similar to case 2 except that "ours" should be emptied at
       step 2 and exit early.
    
    A fetch after "clone --depth=X" is case 1. A fetch after "clone" (from
    a shallow repo) is case 3. Luckily they're cheap for the common case.
    
    A push from "clone --depth=X" falls into case 2, which is expensive.
    Some more work may be done at the sender/client side to avoid more
    work on the server side: if the transferred pack does not contain any
    shallow commits, send-pack should not send any shallow commits to the
    receive-pack, effectively turning it into a normal push and avoid all
    steps.
    
    This patch implements all steps except #3, already handled by
    fetch-pack and receive-pack, #6 and #7, which has their own patch due
    to their size.
    
    (*) in previous versions step 7 was put before step 3. I reorder it so
        that the common case that keeps the pack does not need to walk
        commits at all. In future if we implement faster commit
        reachability check (maybe with the help of pack bitmaps or commit
        cache), step 7 could become cheap and be moved up before 6 again.
    
    Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Jul 10, 2013
  1. @peff @gitster

    add missing "format" function attributes

    peff authored gitster committed
    For most of our functions that take printf-like formats, we
    use gcc's __attribute__((format)) to get compiler warnings
    when the functions are misused. Let's give a few more
    functions the same protection.
    
    In most cases, the annotations do not uncover any actual
    bugs; the only code change needed is that we passed a size_t
    to transfer_debug, which expected an int. Since we expect
    the passed-in value to be a relatively small buffer size
    (and cast a similar value to int directly below), we can
    just cast away the problem.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Sep 16, 2012
  1. @gitster

    trace.c: mark a private file-scope symbol as static

    gitster authored
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Mar 22, 2011
  1. @bebarino @gitster

    Fix sparse warnings

    bebarino authored gitster committed
    Fix warnings from 'make check'.
    
     - These files don't include 'builtin.h' causing sparse to complain that
       cmd_* isn't declared:
    
       builtin/clone.c:364, builtin/fetch-pack.c:797,
       builtin/fmt-merge-msg.c:34, builtin/hash-object.c:78,
       builtin/merge-index.c:69, builtin/merge-recursive.c:22
       builtin/merge-tree.c:341, builtin/mktag.c:156, builtin/notes.c:426
       builtin/notes.c:822, builtin/pack-redundant.c:596,
       builtin/pack-refs.c:10, builtin/patch-id.c:60, builtin/patch-id.c:149,
       builtin/remote.c:1512, builtin/remote-ext.c:240,
       builtin/remote-fd.c:53, builtin/reset.c:236, builtin/send-pack.c:384,
       builtin/unpack-file.c:25, builtin/var.c:75
    
     - These files have symbols which should be marked static since they're
       only file scope:
    
       submodule.c:12, diff.c:631, replace_object.c:92, submodule.c:13,
       submodule.c:14, trace.c:78, transport.c:195, transport-helper.c:79,
       unpack-trees.c:19, url.c:3, url.c:18, url.c:104, url.c:117, url.c:123,
       url.c:129, url.c:136, thread-utils.c:21, thread-utils.c:48
    
     - These files redeclare symbols to be different types:
    
       builtin/index-pack.c:210, parse-options.c:564, parse-options.c:571,
       usage.c:49, usage.c:58, usage.c:63, usage.c:72
    
     - These files use a literal integer 0 when they really should use a NULL
       pointer:
    
       daemon.c:663, fast-import.c:2942, imap-send.c:1072, notes-merge.c:362
    
    While we're in the area, clean up some unused #includes in builtin files
    (mostly exec_cmd.h).
    
    Signed-off-by: Stephen Boyd <bebarino@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Mar 8, 2011
  1. @peff @gitster

    trace: give repo_setup trace its own key

    peff authored gitster committed
    You no longer get this output with GIT_TRACE=1; instead, you
    can do GIT_TRACE_SETUP=1.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  2. @peff @gitster

    trace: add trace_strbuf

    peff authored gitster committed
    If you happen to have a strbuf, it is a little more readable
    and a little more efficient to be able to print it directly
    instead of jamming it through the trace_printf interface.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  3. @peff @gitster

    trace: factor out "do we want to trace" logic

    peff authored gitster committed
    As we add more tracing areas, this will avoid repeated code.
    
    Technically, trace_printf already checks this and will avoid
    printing if the trace key is not set. However, callers may
    want to find out early whether or not tracing is enabled so
    they can avoid doing work in the common non-trace case.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  4. @peff @gitster

    trace: refactor to support multiple env variables

    peff authored gitster committed
    Right now you turn all tracing off and on with GIT_TRACE. To
    support new types of tracing without forcing the user to see
    all of them, we will soon support turning each tracing area
    on with GIT_TRACE_*.
    
    This patch lays the groundwork by providing an interface
    which does not assume GIT_TRACE. However, we still maintain
    the trace_printf interface so that existing callers do not
    need to be refactored.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  5. @peff @gitster

    trace: add trace_vprintf

    peff authored gitster committed
    This is a necessary cleanup to adding new types of trace
    functions.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Feb 26, 2011
  1. @peff @gitster

    strbuf: add strbuf_vaddf

    peff authored gitster committed
    In a variable-args function, the code for writing into a strbuf is
    non-trivial. We ended up cutting and pasting it in several places
    because there was no vprintf-style function for strbufs (which in turn
    was held up by a lack of va_copy).
    
    Now that we have a fallback va_copy, we can add strbuf_vaddf, the
    strbuf equivalent of vsprintf. And we can clean up the cut and paste
    mess.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Improved-by: Christian Couder <christian.couder@gmail.com>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Jan 6, 2011
  1. @drafnel @gitster

    trace.c: ensure NULL is not passed to printf

    drafnel authored gitster committed
    GNU printf, and many others, will print the string "(null)" if a NULL
    pointer is passed as the argument to a "%s" format specifier.  Some
    implementations (like on Solaris) do not detect a NULL pointer and will
    produce a segfault in this case.
    
    So, fix this by ensuring that pointer variables do not contain the value
    NULL.  Assign the string "(null)" to the variables are NULL.
    
    Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Dec 28, 2010
  1. @gitster

    Merge branch 'nd/setup'

    gitster authored
    * nd/setup: (47 commits)
      setup_work_tree: adjust relative $GIT_WORK_TREE after moving cwd
      git.txt: correct where --work-tree path is relative to
      Revert "Documentation: always respect core.worktree if set"
      t0001: test git init when run via an alias
      Remove all logic from get_git_work_tree()
      setup: rework setup_explicit_git_dir()
      setup: clean up setup_discovered_git_dir()
      t1020-subdirectory: test alias expansion in a subdirectory
      setup: clean up setup_bare_git_dir()
      setup: limit get_git_work_tree()'s to explicit setup case only
      Use git_config_early() instead of git_config() during repo setup
      Add git_config_early()
      git-rev-parse.txt: clarify --git-dir
      t1510: setup case #31
      t1510: setup case #30
      t1510: setup case #29
      t1510: setup case #28
      t1510: setup case #27
      t1510: setup case #26
      t1510: setup case #25
      ...
Commits on Dec 21, 2010
  1. @gitster

    set_try_to_free_routine(NULL) means "do nothing special"

    gitster authored
    This way, the next caller that wants to disable our memory reclamation
    machinery does not have to define its own do_nothing() stub.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Dec 17, 2010
  1. @vvavrychuk @gitster

    trace.c: mark file-local function static

    vvavrychuk authored gitster committed
    Signed-off-by: Vasyl' Vavrychuk <vvavrychuk@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Nov 29, 2010
  1. @pclouds @gitster

    builtins: print setup info if repo is found

    pclouds authored gitster committed
    Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Something went wrong with that request. Please try again.