1. 22 Mar, 2019 1 commit
  2. 20 Mar, 2019 1 commit
  3. 20 Feb, 2019 1 commit
  4. 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>
  5. 24 Jan, 2019 1 commit
  6. 14 Jan, 2019 3 commits
  7. 12 Jan, 2019 1 commit
    • Jeff King's avatar
      commit: copy saved getenv() result · 406bab38
      Jeff King authored
      We save the result of $GIT_INDEX_FILE so that we can restore it after
      setting it to a new value and running add--interactive. However, the
      pointer returned by getenv() is not guaranteed to be valid after calling
      setenv(). This _usually_ works fine, but can fail if libc needs to
      reallocate the environment block during the setenv().
      Let's just duplicate the string, so we know that it remains valid.
      In the long run it may be more robust to teach interactive_add() to take
      a set of environment variables to pass along to run-command when it
      execs add--interactive. And then we would not have to do this
      save/restore dance at all. But this is an easy fix in the meantime.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  8. 12 Nov, 2018 3 commits
  9. 06 Nov, 2018 3 commits
    • Jeff King's avatar
      assert NOARG/NONEG behavior of parse-options callbacks · 517fe807
      Jeff King authored
      When we define a parse-options callback, the flags we put in the option
      struct must match what the callback expects. For example, a callback
      which does not handle the "unset" parameter should only be used with
      PARSE_OPT_NONEG. But since the callback and the option struct are not
      defined next to each other, it's easy to get this wrong (as earlier
      patches in this series show).
      Fortunately, the compiler can help us here: compiling with
      -Wunused-parameters can show us which callbacks ignore their "unset"
      parameters (and likewise, ones that ignore "arg" expect to be triggered
      with PARSE_OPT_NOARG).
      But after we've inspected a callback and determined that all of its
      callers use the right flags, what do we do next? We'd like to silence
      the compiler warning, but do so in a way that will catch any wrong calls
      in the future.
      We can do that by actually checking those variables and asserting that
      they match our expectations. Because this is such a common pattern,
      we'll introduce some helper macros. The resulting messages aren't
      as descriptive as we could make them, but the file/line information from
      BUG() is enough to identify the problem (and anyway, the point is that
      these should never be seen).
      Each of the annotated callbacks in this patch triggers
      -Wunused-parameters, and was manually inspected to make sure all callers
      use the correct options (so none of these BUGs should be triggerable).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      status: mark --find-renames option with NONEG · d6627fb8
      Jeff King authored
      If you run "git status --no-find-renames", it will behave the same as
      "--find-renames", because we ignore the "unset" parameter (we see a NULL
      "arg", but since the score argument is optional, we just think that the
      user did not provide a score).
      We already have a separate "--no-renames" to disable renames, so there's
      not much point in supporting "--no-find-renames". Let's just flag it as
      an error.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Ben Peart's avatar
      refresh_index: remove unnecessary calls to preload_index() · 6c5b7f55
      Ben Peart authored
      With refresh_index() learning to utilize preload_index() to speed up its
      operation there is no longer any benefit to having the caller preload the
      index first. Remove those unneeded calls by calling read_index() instead of
      the preload variant.
      There is no measurable performance impact of this patch - the 2nd call to
      preload_index() bails out quickly but there is no reason to call it twice.
      Signed-off-by: default avatarBen Peart <benpeart@microsoft.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  10. 04 Oct, 2018 1 commit
    • Stephen P. Smith's avatar
      roll wt_status_state into wt_status and populate in the collect phase · 73ba5d78
      Stephen P. Smith authored
      Status variables were initialized in the collect phase and some
      variables were later freed in the print functions.
      A "struct wt_status" used to be sufficient for the output phase to
      work.  It was designed to be filled in the collect phase and consumed
      in the output phase, but over time some fields were added and output
      phase started filling the fields.
      A "struct wt_status_state" that was used in other codepaths turned out
      to be useful in the "git status" output.  This is not tied to "struct
      wt_status", so filling in the collect phase was not consistently
      Move the status state structure variables into the status state
      structure and populate them in the collect functions.
      Create a new function to free the buffers that were being freed in the
      print function.  Call this new function in commit.c where both the
      collect and print functions were being called.
      Based on a patch suggestion by Junio C Hamano. [1]
      [1] https://public-inbox.org/git/xmqqr2i5ueg4.fsf@gitster-ct.c.googlers.com/Signed-off-by: default avatarStephen P. Smith <ischis2@cox.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  11. 27 Sep, 2018 1 commit
    • Elijah Newren's avatar
      commit: fix erroneous BUG, 'multiple renames on the same target? how?' · 3e73cc62
      Elijah Newren authored
      builtin/commit.c:prepare_to_commit() can call run_status() twice if
      using the editor, including status, and the user attempts to record a
      non-merge empty commit without explicit --allow-empty.  If there is also
      a rename involved as well (due to using 'git add -N'), then a BUG in
      wt-status.c is triggered:
        BUG: wt-status.c:476: multiple renames on the same target? how?
      The reason we hit this bug is that both run_status() calls use the same
      struct wt_status * (named s), and s->change is not freed between runs.
      Changes are inserted into s with string_list_insert, which usually means
      that the second run just recomputes all the same results and overwrites
      what was computed the first time.  However, ever since commit
      176ea747 ("wt-status.c: handle worktree renames", 2017-12-27),
      wt-status started checking for renames and copies but also added a
      preventative check that d->rename_status wasn't already set and output a
      BUG message if it was.  The problem isn't that there are multiple rename
      targets to a single path as the error implies, the problem is that 's'
      is not freed/cleared between the two run_status() calls.
      Ever since commit dc6b1d92 ("wt-status: use settings from
      git_diff_ui_config", 2018-05-04), which stopped hardcoding
      DIFF_DETECT_RENAME and allowed users to ask for copy detection, this bug
      has also been triggerable with a copy instead of a rename.
      Fix the bug by clearing s->change.  A better change might be to clean up
      all of s between the two run_status() calls.  A good first step towards
      such a goal might be writing a function to free the necessary fields in
      the wt_status * struct; a cursory glance at the code suggests all of its
      allocated data is probably leaked.  However, doing all that cleanup is a
      bigger task for someone else interested to tackle; just fix the bug for
      Reported-by: Andrea Stacchiotti's avatarAndrea Stacchiotti <andreastacchiotti@gmail.com>
      Signed-off-by: Elijah Newren's avatarElijah Newren <newren@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  12. 21 Sep, 2018 2 commits
  13. 17 Sep, 2018 1 commit
    • Duy Nguyen's avatar
      status: show progress bar if refreshing the index takes too long · ae9af122
      Duy Nguyen authored
      Refreshing the index is usually very fast, but it can still take a
      long time sometimes. Cold cache is one. Or copying a repo to a new
      place (*). It's good to show something to let the user know "git
      status" is not hanging, it's just busy doing something.
      (*) In this case, all stat info in the index becomes invalid and git
          falls back to rehashing all file content to see if there's any
          difference between updating stat info in the index. This is quite
          expensive. Even with a repo as small as git.git, it takes 3
      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>
  14. 07 Sep, 2018 1 commit
  15. 29 Aug, 2018 1 commit
    • Derrick Stolee's avatar
      commit-graph: define GIT_TEST_COMMIT_GRAPH · 859fdc0c
      Derrick Stolee authored
      The commit-graph feature is tested in isolation by
      t5318-commit-graph.sh and t6600-test-reach.sh, but there are many
      more interesting scenarios involving commit walks. Many of these
      scenarios are covered by the existing test suite, but we need to
      maintain coverage when the optional commit-graph structure is not
      To allow running the full test suite with the commit-graph present,
      add a new test environment variable, GIT_TEST_COMMIT_GRAPH. Similar
      to GIT_TEST_SPLIT_INDEX, this variable makes every Git command try
      to load the commit-graph when parsing commits, and writes the
      commit-graph file after every 'git commit' command.
      There are a few tests that rely on commits not existing in
      pack-files to trigger important events, so manually set
      GIT_TEST_COMMIT_GRAPH to false for the necessary commands.
      There is one test in t6024-recursive-merge.sh that relies on the
      merge-base algorithm picking one of two ambiguous merge-bases, and
      the commit-graph feature changes which merge-base is picked.
      Helped-by: Eric Sunshine's avatarEric Sunshine <sunshine@sunshineco.com>
      Signed-off-by: Derrick Stolee's avatarDerrick Stolee <dstolee@microsoft.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  16. 13 Aug, 2018 1 commit
  17. 23 Jul, 2018 1 commit
    • Duy Nguyen's avatar
      Update messages in preparation for i18n · 1a07e59c
      Duy Nguyen authored
      Many messages will be marked for translation in the following
      commits. This commit updates some of them to be more consistent and
      reduce diff noise in those commits. Changes are
      - keep the first letter of die(), error() and warning() in lowercase
      - no full stop in die(), error() or warning() if it's single sentence
      - indentation
      - some messages are turned to BUG(), or prefixed with "BUG:" and will
        not be marked for i18n
      - some messages are improved to give more information
      - some messages are broken down by sentence to be i18n friendly
        (on the same token, combine multiple warning() into one big string)
      - the trailing \n is converted to printf_ln if possible, or deleted
        if not redundant
      - errno_errno() is used instead of explicit strerror()
      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>
  18. 20 Jul, 2018 1 commit
  19. 29 May, 2018 2 commits
  20. 17 May, 2018 1 commit
  21. 13 May, 2018 1 commit
    • Ben Peart's avatar
      add status config and command line options for rename detection · e8b2dc2c
      Ben Peart authored
      After performing a merge that has conflicts git status will, by default,
      attempt to detect renames which causes many objects to be examined.  In a
      virtualized repo, those objects do not exist locally so the rename logic
      triggers them to be fetched from the server. This results in the status call
      taking hours to complete on very large repos vs seconds with this patch.
      Add a new config status.renames setting to enable turning off rename
      detection during status and commit.  This setting will default to the value
      of diff.renames.
      Add a new config status.renamelimit setting to to enable bounding the time
      spent finding out inexact renames during status and commit.  This setting
      will default to the value of diff.renamelimit.
      Add --no-renames command line option to status that enables overriding the
      config setting from the command line. Add --find-renames[=<n>] command line
      option to status that enables detecting renames and optionally setting the
      similarity index.
      Reviewed-by: Elijah Newren's avatarElijah Newren <newren@gmail.com>
      Original-Patch-by: default avatarAlejandro Pauly <alpauly@microsoft.com>
      Signed-off-by: default avatarBen Peart <Ben.Peart@microsoft.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  22. 06 May, 2018 2 commits
    • 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>
    • Eckhard S. Maaß's avatar
      wt-status: use settings from git_diff_ui_config · dc6b1d92
      Eckhard S. Maaß authored
      If you do something like
          - git add .
          - git status
          - git commit
          - git show (or git diff HEAD)
      one would expect to have analogous output from git status and git show
      (or similar diff-related programs). This is generally not the case, as
      git status has hard coded values for diff related options.
      With this commit the hard coded settings are dropped from the status
      command in favour for values provided by git_diff_ui_config.
      What follows are some remarks on the concrete options which were hard
      coded in git status:
      Since the very beginning of git status in a3e870f2 ("Add "commit"
      helper script", 2005-05-30), git status always used rename detection,
      whereas with commands like show and log one had to activate it with a
      command line option. After 5404c116 ("diff: activate diff.renames by
      default", 2016-02-25) the default behaves the same by coincidence, but
      changing diff.renames to other values can break the consistency between
      git status and other commands again. With this commit one control the
      same default behaviour with diff.renames.
      Similarly one has the option diff.renamelimit to adjust this limit for
      all commands but git status. With this commit git status will also honor
      Unlike the other two options this cannot be configured by a
      configuration option yet. This commit will also change the default
      behaviour to not use break rewrites. But as rename detection is most
      likely on, this is dangerous to be activated anyway as one can see
          https://public-inbox.org/git/xmqqegqaahnh.fsf@gitster.dls.corp.google.com/Signed-off-by: default avatarEckhard S. Maaß <eckhard.s.maass@gmail.com>
      Reviewed-by: Elijah Newren's avatarElijah Newren <newren@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  23. 05 Apr, 2018 1 commit
    • Brandon Williams's avatar
      commit: allow partial commits with relative paths · 86238e07
      Brandon Williams authored
      Commit 8894d535 (commit: allow partial commits with relative paths,
      2011-07-30) ensured that partial commits were allowed when a user
      supplies a relative pathspec but then this was regressed in 5879f568
      (remove prefix argument from pathspec_prefix, 2011-09-04) when the
      prefix argument to 'pathspec_prefix' removed and the 'list_paths'
      function wasn't properly adjusted to cope with the change, resulting in
      over-eager pruning of the tree that is overlayed on the index.
      This fixes the regression and adds a regression test so this can be
      prevented in the future.
      Signed-off-by: default avatarBrandon Williams <bmwill@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  24. 01 Mar, 2018 2 commits
    • Martin Ågren's avatar
      write_locked_index(): add flag to avoid writing unchanged index · 61000814
      Martin Ågren authored
      We have several callers like
      	if (active_cache_changed && write_locked_index(...))
      where the final rollback is needed because "!active_cache_changed"
      shortcuts the if-expression. There are also a few variants of this,
      including some if-else constructs that make it more clear when the
      explicit rollback is really needed.
      Teach `write_locked_index()` to take a new flag SKIP_IF_UNCHANGED and
      simplify the callers. Leave the most complicated of the callers (in
      builtin/update-index.c) unchanged. Rewriting it to use this new flag
      would end up duplicating logic.
      We could have made the new flag behave the other way round
      ("FORCE_WRITE"), but that could break existing users behind their backs.
      Let's take the more conservative approach. We can still migrate existing
      callers to use our new flag. Later we might even be able to flip the
      default, possibly without entirely ignoring the risk to in-flight or
      out-of-tree topics.
      Suggested-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarMartin Ågren <martin.agren@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Ævar Arnfjörð Bjarmason's avatar
      commit: run git gc --auto just before the post-commit hook · 095c741e
      Ævar Arnfjörð Bjarmason authored
      Change the behavior of git-commit back to what it was back in
      d4bb43ee ("Invoke "git gc --auto" from commit, merge, am and
      rebase.", 2007-09-05) when it was git-commit.sh.
      Shortly afterwards in f5bbc322 ("Port git commit to C.", 2007-11-08)
      when it was ported to C, the "git gc --auto" invocation went away.
      Since that unintended regression, git gc --auto only ran for git-am,
      git-merge, git-fetch, and git-receive-pack.  It was possible to
      write a script that would "git commit" a lot of data locally, and gc
      would never run.
      One such repository that was locally committing generated zone file
      changes had grown to a size of ~60GB before a daily cronjob was added
      to "git gc", bringing it down to less than 1GB. This will make such
      cases work without intervention.
      I think fixing such pathological cases where the repository will grow
      forever is a worthwhile trade-off for spending a couple of
      milliseconds calling "git gc --auto" (in the common cases where it
      doesn't do anything).
      Signed-off-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  25. 30 Jan, 2018 1 commit
  26. 24 Jan, 2018 2 commits
  27. 27 Dec, 2017 1 commit
  28. 22 Dec, 2017 1 commit
    • Ævar Arnfjörð Bjarmason's avatar
      commit: add support for --fixup <commit> -m"<extra message>" · 30884c9a
      Ævar Arnfjörð Bjarmason authored
      Add support for supplying the -m option with --fixup. Doing so has
      errored out ever since --fixup was introduced. Before this, the only
      way to amend the fixup message while committing was to use --edit and
      amend it in the editor.
      The use-case for this feature is one of:
       * Leaving a quick note to self when creating a --fixup commit when
         it's not self-evident why the commit should be squashed without a
         note into another one.
       * (Ab)using the --fixup feature to "fix up" commits that have already
         been pushed to a branch that doesn't allow non-fast-forwards,
         i.e. just noting "this should have been part of that other commit",
         and if the history ever got rewritten in the future the two should
         be combined.
         In such a case you might want to leave a small message,
         e.g. "forgot this part, which broke XYZ".
      With this, --fixup <commit> -m"More" -m"Details" will result in a
      commit message like:
          !fixup <subject of <commit>>
      The reason the test being added here seems to squash "More" at the end
      of the subject line of the commit being fixed up is because the test
      code is using "%s%b" so the body immediately follows the subject, it's
      not a bug in this code, and other tests t7500-commit.sh do the same
      When the --fixup option was initially added the "Option -m cannot be
      combined" error was expanded from -c, -C and -F to also include
      Those options could also support combining with -m, but given what
      they do I can't think of a good use-case for doing that, so I have not
      made the more invasive change of splitting up the logic in commit.c to
      first act on those, and then on -m options.
      1. d71b8ba7 ("commit: --fixup option for use with rebase
         --autosquash", 2010-11-02)
      Helped-by: Eric Sunshine's avatarEric Sunshine <sunshine@sunshineco.com>
      Signed-off-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  29. 24 Nov, 2017 1 commit
    • Phillip Wood's avatar
      commit: move print_commit_summary() to libgit · e47c6caf
      Phillip Wood authored
      Move print_commit_summary() from builtin/commit.c to sequencer.c so it
      can be shared with other commands. The function is modified by
      changing the last argument to a flag so callers can specify whether
      they want to show the author date in addition to specifying if this is
      an initial commit.
      If the sequencer dies in print_commit_summary() (which can only happen
      when cherry-picking or reverting) then neither the todo list nor the
      abort safety file are updated to reflect the commit that was just
      made. print_commit_summary() can die if:
       - The commit that was just created cannot be found or parsed.
       - HEAD cannot be resolved either because some other process is
         updating it (which is bad news in the middle of a cherry-pick) or
         because it is corrupt.
       - log_tree_commit() cannot read some objects.
      In all those cases dying will leave the sequencer in a sane state for
      aborting; 'git cherry-pick --abort' will rewind HEAD to the last
      successful commit before there was a problem with HEAD or the object
      database. If the user somehow fixes the problem and runs 'git
      cherry-pick --continue' then the sequencer will try and pick the same
      commit again which may or may not be what the user wants depending on
      what caused print_commit_summary() to die. If print_commit_summary()
      returned an error instead then update_abort_safety_file() would try to
      resolve HEAD which may or may not be successful. If it is successful
      then running 'git rebase --abort' would not rewind HEAD to the last
      successful commit which is not what we want.
      Signed-off-by: Phillip Wood's avatarPhillip Wood <phillip.wood@dunelm.org.uk>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>