1. 12 Nov, 2018 2 commits
  2. 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
      followed.
      
      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>
      73ba5d78
  3. 07 Sep, 2018 1 commit
  4. 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>
      e8b2dc2c
  5. 14 Mar, 2018 1 commit
  6. 24 Jan, 2018 1 commit
  7. 27 Dec, 2017 1 commit
  8. 31 Oct, 2017 1 commit
    • Jameson Miller's avatar
      status: add option to show ignored files differently · eec0f7f2
      Jameson Miller authored
      Teach the status command more flexibility in how ignored files are
      reported. Currently, the reporting of ignored files and untracked
      files are linked. You cannot control how ignored files are reported
      independently of how untracked files are reported (i.e. `all` vs
      `normal`). This makes it impossible to show untracked files with the
      `all` option, but show ignored files with the `normal` option.
      
      This work 1) adds the ability to control the reporting of ignored
      files independently of untracked files and 2) introduces the concept
      of status reporting ignored paths that explicitly match an ignored
      pattern. There are 2 benefits to these changes: 1) if a consumer needs
      all untracked files but not all ignored files, there is a performance
      benefit to not scanning all contents of an ignored directory and 2)
      returning ignored files that explicitly match a path allow a consumer
      to make more informed decisions about when a status result might be
      stale.
      
      This commit implements --ignored=matching with --untracked-files=all.
      The following commit will implement --ignored=matching with
      --untracked=files=normal.
      
      As an example of where this flexibility could be useful is that our
      application (Visual Studio) runs the status command and presents the
      output. It shows all untracked files individually (e.g. using the
      '--untracked-files==all' option), and would like to know about which
      paths are ignored. It uses information about ignored paths to make
      decisions about when the status result might have changed.
      Additionally, many projects place build output into directories inside
      a repository's working directory (e.g. in "bin/" and "obj/"
      directories). Normal usage is to explicitly ignore these 2 directory
      names in the .gitignore file (rather than or in addition to the *.obj
      pattern).If an application could know that these directories are
      explicitly ignored, it could infer that all contents are ignored as
      well and make better informed decisions about files in these
      directories. It could infer that any changes under these paths would
      not affect the output of status. Additionally, there can be a
      significant performance benefit by avoiding scanning through ignored
      directories.
      
      When status is set to report matching ignored files, it has the
      following behavior. Ignored files and directories that explicitly
      match an exclude pattern are reported. If an ignored directory matches
      an exclude pattern, then the path of the directory is returned. If a
      directory does not match an exclude pattern, but all of its contents
      are ignored, then the contained files are reported instead of the
      directory.
      Signed-off-by: default avatarJameson Miller <jamill@microsoft.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      eec0f7f2
  9. 22 Jun, 2017 1 commit
    • Kaartic Sivaraam's avatar
      status: contextually notify user about an initial commit · 4ddb1354
      Kaartic Sivaraam authored
      The existing message, "Initial commit", makes sense for the commit template
      notifying users that it's their initial commit, but is confusing when
      merely checking the status of a fresh repository (or orphan branch)
      without having any commits yet.
      
      Change the output of "status" to say "No commits yet" when "git
      status" is run on a fresh repo (or orphan branch), while retaining the
      current "Initial commit" message displayed in the template that's
      displayed in the editor when the initial commit is being authored.
      
      Correspondingly change the output of "short status" to "No commits yet
      on " when "git status -sb" is run on a fresh repo (or orphan branch).
      
      A few alternatives considered were,
      
       * Waiting for initial commit
       * Your current branch does not have any commits
       * Current branch waiting for initial commit
      
      The most succint one among the alternatives was chosen.
      
      [with help on tests from Ævar]
      Helped-by: default avatarJunio C Hamano <gitster@pobox.com>
      Signed-off-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: default avatarKaartic Sivaraam <kaarticsivaraam91196@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      4ddb1354
  10. 19 Jun, 2017 1 commit
  11. 18 May, 2017 1 commit
    • Brian Malehorn's avatar
      interpret-trailers: honor the cut line · d76650b8
      Brian Malehorn authored
      If a commit message is edited with the "verbose" option, the buffer
      will have a cut line and diff after the log message, like so:
      
          my subject
      
          # ------------------------ >8 ------------------------
          # Do not touch the line above.
          # Everything below will be removed.
          diff --git a/foo.txt b/foo.txt
          index 5716ca5..7601807 100644
          --- a/foo.txt
          +++ b/foo.txt
          @@ -1 +1 @@
          -bar
          +baz
      
      "git interpret-trailers" is unaware of the cut line, and assumes the
      trailer block would be at the end of the whole thing.  This can easily
      be seen with:
      
           $ GIT_EDITOR='git interpret-trailers --in-place --trailer Acked-by:me' \
             git commit --amend -v
      
      Teach "git interpret-trailers" to notice the cut-line and ignore the
      remainder of the input when looking for a place to add new trailer
      block.  This makes it consistent with how "git commit -v -s" inserts a
      new Signed-off-by: line.
      
      This can be done by the same logic as the existing helper function,
      wt_status_truncate_message_at_cut_line(), uses, but it wants the caller
      to pass a strbuf to it.  Because the function ignore_non_trailer() used
      by the command takes a <pointer, length> pair, not a strbuf, steal the
      logic from wt_status_truncate_message_at_cut_line() to create a new
      wt_status_locate_end() helper function that takes <pointer, length>
      pair, and make ignore_non_trailer() call it to help "interpret-trailers".
      
      Since there is only one caller of wt_status_truncate_message_at_cut_line()
      in cmd_commit(), rewrite it to call wt_status_locate_end() helper instead
      and remove the old helper that no longer has any caller.
      Signed-off-by: Brian Malehorn's avatarBrian Malehorn <bmalehorn@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      d76650b8
  12. 27 Mar, 2017 1 commit
  13. 07 Oct, 2016 3 commits
  14. 11 Aug, 2016 2 commits
  15. 05 Aug, 2016 2 commits
  16. 22 Apr, 2016 3 commits
  17. 21 Aug, 2015 1 commit
  18. 06 Mar, 2015 1 commit
  19. 26 Mar, 2014 1 commit
  20. 18 Feb, 2014 1 commit
  21. 05 Dec, 2013 1 commit
    • Jens Lehmann's avatar
      commit -v: strip diffs and submodule shortlogs from the commit message · 1a72cfd7
      Jens Lehmann authored
      When using the '-v' option of "git commit" the diff added to the commit
      message temporarily for editing is stripped off after the user exited the
      editor by searching for "\ndiff --git " and truncating the commmit message
      there if it is found.
      
      But this approach has two problems:
      
      - when the commit message itself contains a line starting with
        "diff --git" it will be truncated there prematurely; and
      
      - when the "diff.submodule" setting is set to "log", the diff may
        start with "Submodule <hash1>..<hash2>", which will be left in
        the commit message while it shouldn't.
      
      Fix that by introducing a special scissor separator line starting with the
      comment character ('#' or the core.commentChar config if set) followed by
      two lines describing what it is for. The scissor line - which will not be
      translated - is used to reliably detect the start of the diff so it can be
      chopped off from the commit message, no matter what the user enters there.
      
      Turn a known test failure fixed by this change into a successful test;
      also add one for a diff starting with a submodule log and another one for
      proper handling of the comment char.
      Reported-by: default avatarAri Pollak <ari@debian.org>
      Signed-off-by: default avatarJens Lehmann <Jens.Lehmann@web.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      1a72cfd7
  22. 11 Oct, 2013 1 commit
  23. 12 Sep, 2013 1 commit
  24. 06 Sep, 2013 1 commit
    • Matthieu Moy's avatar
      status: disable display of '#' comment prefix by default · 2556b996
      Matthieu Moy authored
      Historically, "git status" needed to prefix each output line with '#' so
      that the output could be added as comment to the commit message. This
      prefix comment has no real purpose when "git status" is ran from the
      command-line, and this may distract users from the real content.
      
      Disable this prefix comment by default, and make it re-activable for
      users needing backward compatibility with status.displayCommentPrefix.
      
      Obviously, "git commit" ignores status.displayCommentPrefix and keeps the
      comment unconditionnaly when writing to COMMIT_EDITMSG (but not when
      writing to stdout for an error message or with --dry-run).
      Signed-off-by: default avatarMatthieu Moy <Matthieu.Moy@imag.fr>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      2556b996
  25. 15 Jul, 2013 1 commit
  26. 10 Jul, 2013 1 commit
  27. 02 Apr, 2013 2 commits
  28. 17 Mar, 2013 4 commits
  29. 05 Feb, 2013 1 commit
    • Duy Nguyen's avatar
      status: show the branch name if possible in in-progress info · 0722c805
      Duy Nguyen authored
      The typical use-case is starting a rebase, do something else, come
      back the day after, run "git status" or make a new commit and wonder
      what in the world's going on. Which branch is being rebased is
      probably the most useful tidbit to help, but the target may help
      too.
      
      Ideally, I would have loved to see "rebasing master on
      origin/master", but the target ref name is not stored during rebase,
      so this patch writes "rebasing master on a78c8c98b" as a
      half-measure to remind future users of that potential improvement.
      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>
      0722c805