1. 01 Apr, 2019 1 commit
    • Duy Nguyen's avatar
      config: correct '**' matching in includeIf patterns · 19e7fdaa
      Duy Nguyen authored
      The current wildmatch() call for includeIf's gitdir pattern does not
      pass the WM_PATHNAME flag. Without this flag, '*' is treated _almost_
      the same as '**' (because '*' also matches slashes) with one exception:
      '/**/' can match a single slash. The pattern 'foo/**/bar' matches
      But '/*/', which is essentially what wildmatch engine sees without
      WM_PATHNAME, has to match two slashes (and '*' matches nothing). Which
      means 'foo/*/bar' cannot match 'foo/bar'. It can only match 'foo//bar'.
      The result of this is the current wildmatch() call works most of the
      time until the user depends on '/**/' matching no path component. And
      also '*' matches slashes while it should not, but people probably
      haven't noticed this yet. The fix is straightforward.
      Reported-by: Jason Karns's avatarJason Karns <jason.karns@gmail.com>
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  2. 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: default avatarJeff Hostetler <jeffhost@microsoft.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  3. 04 Feb, 2019 1 commit
    • William Hubbs's avatar
      config: allow giving separate author and committer idents · 39ab4d09
      William Hubbs authored
      The author.email, author.name, committer.email and committer.name
      settings are analogous to the GIT_AUTHOR_* and GIT_COMMITTER_*
      environment variables, but for the git config system. This allows them
      to be set separately for each repository.
      Git supports setting different authorship and committer
      information with environment variables. However, environment variables
      are set in the shell, so if different authorship and committer
      information is needed for different repositories an external tool is
      This adds support to git config for author.email, author.name,
      committer.email and committer.name  settings so this information
      can be set per repository.
      Also, it generalizes the fmt_ident function so it can handle author vs
      committer identification.
      Signed-off-by: default avatarWilliam Hubbs <williamh@gentoo.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  4. 24 Jan, 2019 1 commit
  5. 21 Nov, 2018 1 commit
    • Jonathan Nieder's avatar
      index: make index.threads=true enable ieot and eoie · 2a9dedef
      Jonathan Nieder authored
      If a user explicitly sets
      		threads = true
      to read the index using multiple threads, ensure that index writes
      include the offset table by default to make that possible.  This
      ensures that the user's intent of turning on threading is respected.
      In other words, permit the following configurations:
      - index.threads and index.recordOffsetTable unspecified: do not write
        the offset table yet (to avoid alarming the user with "ignoring IEOT
        extension" messages when an older version of Git accesses the
        repository) but do make use of multiple threads to read the index if
        the supporting offset table is present.
        This can also be requested explicitly by setting index.threads=true,
        0, or >1 and index.recordOffsetTable=false.
      - index.threads=false or 1: do not write the offset table, and do not
        make use of the offset table.
        One can set index.recordOffsetTable=false as well, to be more
      - index.threads=true, 0, or >1 and index.recordOffsetTable unspecified:
        write the offset table and make use of threads at read time.
        This can also be requested by setting index.threads=true, 0, >1, or
        unspecified and index.recordOffsetTable=true.
      Fortunately the complication is temporary: once most Git installations
      have upgraded to a version with support for the IEOT and EOIE
      extensions, we can flip the defaults for index.recordEndOfIndexEntries
      and index.recordOffsetTable to true and eliminate the settings.
      Helped-by: default avatarBen Peart <benpeart@microsoft.com>
      Signed-off-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  6. 16 Nov, 2018 1 commit
  7. 31 Oct, 2018 3 commits
  8. 22 Oct, 2018 1 commit
    • Duy Nguyen's avatar
      worktree: add per-worktree config files · 58b284a2
      Duy Nguyen authored
      A new repo extension is added, worktreeConfig. When it is present:
       - Repository config reading by default includes $GIT_DIR/config _and_
         $GIT_DIR/config.worktree. "config" file remains shared in multiple
         worktree setup.
       - The special treatment for core.bare and core.worktree, to stay
         effective only in main worktree, is gone. These config settings are
         supposed to be in config.worktree.
      This extension is most useful in multiple worktree setup because you
      now have an option to store per-worktree config (which is either
      .git/config.worktree for main worktree, or
      .git/worktrees/xx/config.worktree for linked ones).
      This extension can be used in single worktree mode, even though it's
      pretty much useless (but this can happen after you remove all linked
      worktrees and move back to single worktree).
      "git config" reads from both "config" and "config.worktree" by default
      (i.e. without either --user, --file...) when this extension is
      present. Default writes still go to "config", not "config.worktree". A
      new option --worktree is added for that (*).
      Since a new repo extension is introduced, existing git binaries should
      refuse to access to the repo (both from main and linked worktrees). So
      they will not misread the config file (i.e. skip the config.worktree
      part). They may still accidentally write to the config file anyway if
      they use with "git config --file <path>".
      This design places a bet on the assumption that the majority of config
      variables are shared so it is the default mode. A safer move would be
      default writes go to per-worktree file, so that accidental changes are
      (*) "git config --worktree" points back to "config" file when this
          extension is not present and there is only one worktree so that it
          works in any both single and multiple worktree setups.
      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>
  9. 11 Oct, 2018 1 commit
    • Ben Peart's avatar
      config: add new index.threads config setting · c780b9cf
      Ben Peart authored
      Add support for a new index.threads config setting which will be used to
      control the threading code in do_read_index().  A value of 0 will tell the
      index code to automatically determine the correct number of threads to use.
      A value of 1 will make the code single threaded.  A value greater than 1
      will set the maximum number of threads to use.
      For testing purposes, this setting can be overwritten by setting the
      GIT_TEST_INDEX_THREADS=<n> environment variable to a value greater than 0.
      Signed-off-by: default avatarBen Peart <benpeart@microsoft.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  10. 28 Sep, 2018 1 commit
    • Ben Peart's avatar
      fsmonitor: update GIT_TEST_FSMONITOR support · 4cb54d0a
      Ben Peart authored
      Rename GIT_FSMONITOR_TEST to GIT_TEST_FSMONITOR for consistency with the
      other GIT_TEST_ special setups and properly document its use.
      Add logic in t/test-lib.sh to give a warning when the old variable is set to
      let people know they need to update their environment to use the new
      Remove the outdated instructions on how to run the test suite utilizing
      fsmonitor now that it is properly documented in t/README.
      Signed-off-by: default avatarBen Peart <Ben.Peart@microsoft.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  11. 23 Aug, 2018 1 commit
  12. 15 Aug, 2018 1 commit
  13. 08 Aug, 2018 1 commit
    • Stefan Beller's avatar
      config: fix case sensitive subsection names on writing · 2d84f13d
      Stefan Beller authored
      A user reported a submodule issue regarding a section mix-up,
      but it could be boiled down to the following test case:
        $ git init test  && cd test
        $ git config foo."Bar".key test
        $ git config foo."bar".key test
        $ tail -n 3 .git/config
        [foo "Bar"]
              key = test
              key = test
      Sub sections are case sensitive and we have a test for correctly reading
      them. However we do not have a test for writing out config correctly with
      case sensitive subsection names, which is why this went unnoticed in
      6ae996f2 (git_config_set: make use of the config parser's event
      stream, 2018-04-09)
      Unfortunately we have to make a distinction between old style configuration
      that looks like
              key = test
      and the new quoted style as seen above. The old style is documented as
      case-agnostic, hence we need to keep 'strncasecmp'; although the
      resulting setting for the old style config differs from the configuration.
      That will be fixed in a follow up patch.
      Reported-by: default avatarJP Sugarbroad <jpsugar@google.com>
      Signed-off-by: Stefan Beller's avatarStefan Beller <sbeller@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  14. 23 Jul, 2018 2 commits
  15. 18 Jul, 2018 1 commit
    • Jeff King's avatar
      add core.usereplacerefs config option · da4398d6
      Jeff King authored
      We can already disable replace refs using a command line
      option or environment variable, but those are awkward to
      apply universally. Let's add a config option to do the same
      That raises the question of why one might want to do so
      universally. The answer is that replace refs violate the
      immutability of objects. For instance, if you wanted to
      cache the diff between commit XYZ and its parent, then in
      theory that never changes; the hash XYZ represents the total
      state. But replace refs violate that; pushing up a new ref
      may create a completely new diff.
      The obvious "if it hurts, don't do it" answer is not to
      create replace refs if you're doing this kind of caching.
      But for a site hosting arbitrary repositories, they may want
      to allow users to share replace refs with each other, but
      not actually respect them on the site (because the caching
      is more important than the replace feature).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  16. 17 Jul, 2018 1 commit
    • Jonathan Tan's avatar
      commit-graph: add repo arg to graph readers · dade47c0
      Jonathan Tan authored
      Add a struct repository argument to the functions in commit-graph.h that
      read the commit graph. (This commit does not affect functions that write
      commit graphs.)
      Because the commit graph functions can now read the commit graph of any
      repository, the global variable core_commit_graph has been removed.
      Instead, the config option core.commitGraph is now read on the first
      time in a repository that a commit is attempted to be parsed using its
      commit graph.
      This commit includes a test that exercises the functionality on an
      arbitrary repository that is not the_repository.
      Signed-off-by: default avatarJonathan Tan <jonathantanmy@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  17. 03 Jul, 2018 3 commits
  18. 26 Jun, 2018 1 commit
  19. 11 Jun, 2018 2 commits
  20. 29 May, 2018 1 commit
  21. 21 May, 2018 3 commits
  22. 17 May, 2018 1 commit
  23. 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>
  24. 06 May, 2018 1 commit
    • Johannes Schindelin's avatar
      Replace all die("BUG: ...") calls by BUG() ones · 033abf97
      Johannes Schindelin authored
      In d8193743 (usage.c: add BUG() function, 2017-05-12), a new macro
      was introduced to use for reporting bugs instead of die(). It was then
      subsequently used to convert one single caller in 588a538a
      (setup_git_env: convert die("BUG") to BUG(), 2017-05-12).
      The cover letter of the patch series containing this patch
      (cf 20170513032414.mfrwabt4hovujde2@sigill.intra.peff.net) is not
      terribly clear why only one call site was converted, or what the plan
      is for other, similar calls to die() to report bugs.
      Let's just convert all remaining ones in one fell swoop.
      This trick was performed by this invocation:
      	sed -i 's/die("BUG: /BUG("/g' $(git grep -l 'die("BUG' \*.c)
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  25. 24 Apr, 2018 1 commit
    • Ryan Dammrose's avatar
      push: colorize errors · 960786e7
      Ryan Dammrose authored
      This is an attempt to resolve an issue I experience with people that are
      new to Git -- especially colleagues in a team setting -- where they miss
      that their push to a remote location failed because the failure and
      success both return a block of white text.
      An example is if I push something to a remote repository and then a
      colleague attempts to push to the same remote repository and the push
      fails because it requires them to pull first, but they don't notice
      because a success and failure both return a block of white text. They
      then continue about their business, thinking it has been successfully
      This patch colorizes the errors and hints (in red and yellow,
      respectively) so whenever there is a failure when pushing to a remote
      repository that fails, it is more noticeable.
      [jes: fixed a couple bugs, added the color.{advice,push,transport}
      settings, refactored to use want_color_stderr().]
      Signed-off-by: Ryan Dammrose ryandammrose@gmail.com
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  26. 23 Apr, 2018 1 commit
  27. 16 Apr, 2018 1 commit
  28. 11 Apr, 2018 2 commits
  29. 09 Apr, 2018 3 commits
    • Johannes Schindelin's avatar
      git_config_set: reuse empty sections · c71d8bb3
      Johannes Schindelin authored
      It can happen quite easily that the last setting in a config section is
      removed, and to avoid confusion when there are comments in the config
      about that section, we keep a lone section header, i.e. an empty
      Now that we use the `event_fn` callback, it is easy to add support for
      re-using empty sections, so let's do that.
      Note: t5512-ls-remote requires that this change is applied *after* the
      patch "git config --unset: remove empty sections (in the common case)":
      without that patch, there would be empty `transfer` and `uploadpack`
      sections ready for reuse, but in the *wrong* order (and sconsequently,
      t5512's "overrides work between mixed transfer/upload-pack hideRefs"
      would fail).
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Johannes Schindelin's avatar
      git config --unset: remove empty sections (in the common case) · 22aedfcc
      Johannes Schindelin authored
      The original reasoning for not removing section headers upon removal of
      the last entry went like this: the user could have added comments about
      the section, or about the entries therein, and if there were other
      comments there, we would not know whether we should remove them.
      In particular, a concocted example was presented that looked like this
      (and was added to t1300):
      	# some generic comment on the configuration file itself
      	# a comment specific to this "section" section.
      	# some intervening lines
      	# that should also be dropped
      	key = value
      	# please be careful when you update the above variable
      The ideal thing for `git config --unset section.key` in this case would
      be to leave only the first line behind, because all the other comments
      are now obsolete.
      However, this is unfeasible, short of adding a complete Natural Language
      Processing module to Git, which seems not only a lot of work, but a
      totally unreasonable feature (for little benefit to most users).
      Now, the real kicker about this problem is: most users do not edit their
      config files at all! In their use case, the config looks like this
      		key = value
      ... and it is totally obvious what should happen if the entry is
      removed: the entire section should vanish.
      Let's generalize this observation to this conservative strategy: if we
      are removing the last entry from a section, and there are no comments
      inside that section nor surrounding it, then remove the entire section.
      Otherwise behave as before: leave the now-empty section (including those
      comments, even ones about the now-deleted entry).
      We have to be extra careful to handle the case where more than one entry
      is removed: any subset of them might be the last entries of their
      respective sections (and if there are no comments in or around that
      section, the section should be removed, too).
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Johannes Schindelin's avatar
      git_config_set: make use of the config parser's event stream · 6ae996f2
      Johannes Schindelin authored
      In the recent commit with the title "config: introduce an optional event
      stream while parsing", we introduced an optional callback to keep track
      of the config parser's events "comment", "white-space", "section header"
      and "entry".
      One motivation for this feature was to make use of it in the code that
      edits the config. And this commit makes it so.
      Note: this patch changes the meaning of the `seen` array that records
      whether we saw the config entry that is to be edited: previously, it
      contained the end offset of the found entry. Now, we introduce a new
      array `parsed` that keeps a record of *all* config parser events (with
      begin/end offsets), and the items in the `seen` array now point into the
      `parsed` array.
      There are two reasons why we do it this way:
      1. To keep the implementation simple, the config parser's event stream
         reports the event only after the config callback was called, so we
         would not receive the begin offset otherwise.
      2. In the following patches, we will re-use the `parsed` array to fix two
         long-standing bugs related to empty sections.
      Note that this also makes the code more robust with respect to finding the
      begin offset of the part(s) of the config file to be edited, as we no
      longer back-track to find the beginning of the line.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>