1. 07 Oct, 2016 3 commits
  2. 11 Aug, 2016 2 commits
  3. 05 Aug, 2016 2 commits
  4. 22 Apr, 2016 3 commits
  5. 21 Aug, 2015 1 commit
  6. 06 Mar, 2015 1 commit
  7. 26 Mar, 2014 1 commit
  8. 18 Feb, 2014 1 commit
  9. 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 <[email protected]>
      Signed-off-by: default avatarJens Lehmann <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      1a72cfd7
  10. 11 Oct, 2013 1 commit
  11. 12 Sep, 2013 1 commit
  12. 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 <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      2556b996
  13. 15 Jul, 2013 1 commit
  14. 10 Jul, 2013 1 commit
  15. 02 Apr, 2013 2 commits
  16. 17 Mar, 2013 4 commits
  17. 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 <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      0722c805
  18. 16 Sep, 2012 1 commit
  19. 16 Jul, 2012 1 commit
    • Jeff King's avatar
      status: color in-progress message like other header messages · 3cd9d1b2
      Jeff King authored
      The "status" command recently learned to describe the
      in-progress operation in its long output format (e.g.,
      rebasing, am, etc). This message gets its own slot in the
      color table, even though it is not configurable. As a
      result, if the user has set color.status.header to a
      non-default value, this message will not match (and cannot
      be made to match, as there is no config option).
      
      It is probably more sane to just color it like the rest of
      the text (i.e., just use color.status.header). This would
      not allow users to customize the color of this message
      independently, but they cannot do that with the current code
      anyway, and if somebody wants to build customizable
      colorization later, this patch does not make it much harder
      to do so.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      3cd9d1b2
  20. 14 Jun, 2012 1 commit
  21. 08 May, 2012 3 commits
    • Jeff King's avatar
      status: refactor colopts handling · 4d2292e9
      Jeff King authored
      The current code reads the config and command-line options
      into a separate "colopts" variable, and then copies the
      contents of that variable into the "struct wt_status". We
      can eliminate the extra variable and copy just write
      straight into the wt_status struct.
      
      This simplifies the "status" code a little bit.
      Unfortunately, it makes the "commit" code one line more
      complex; a side effect of the separate variable was that
      "commit" did not copy the colopts variable, so any
      column.status configuration had no effect.
      
      The result still ends up cleaner, though. In the previous
      version, it was unclear whether commit simply forgot to copy
      the colopt variable, or whether it was intentional. Now it
      explicitly turns off column options. Furthermore, if commit
      later learns to respect column.status, this will make the
      end result simpler. I punted on just adding that feature
      now, because it was sufficiently non-obvious that it should
      not go into a refactoring patch.
      Signed-off-by: default avatarJeff King <[email protected]>
      4d2292e9
    • Jeff King's avatar
      status: respect "-b" for porcelain format · d4a6bf1f
      Jeff King authored
      There is no reason not to, as the user has to explicitly ask
      for it, so we are not breaking compatibility by doing so. We
      can do this simply by moving the "show_branch" flag into
      the wt_status struct. As a bonus, this saves us from passing
      it explicitly, simplifying the code.
      Signed-off-by: default avatarJeff King <[email protected]>
      d4a6bf1f
    • Jeff King's avatar
      status: refactor null_termination option · 3207a3a2
      Jeff King authored
      This option is passed separately to the wt_status printing
      functions, whereas every other formatting option is
      contained in the wt_status struct itself. Let's do the same
      here, so we can avoid passing it around through the call
      stack.
      Signed-off-by: default avatarJeff King <[email protected]>
      3207a3a2
  22. 27 Apr, 2012 1 commit
  23. 08 Mar, 2011 2 commits
  24. 22 Feb, 2011 1 commit
    • Jay Soffian's avatar
      Teach commit about CHERRY_PICK_HEAD · 37f7a857
      Jay Soffian authored
      Previously the user was advised to use commit -c CHERRY_PICK_HEAD after
      a conflicting cherry-pick. While this would preserve the original
      commit's authorship, it would sadly discard cherry-pick's carefully
      crafted MERGE_MSG (which contains the list of conflicts as well as the
      original commit-id in the case of cherry-pick -x).
      
      On the other hand, if a bare 'commit' were performed, it would preserve
      the MERGE_MSG while resetting the authorship.
      
      In other words, there was no way to simultaneously take the authorship
      from CHERRY_PICK_HEAD and the commit message from MERGE_MSG.
      
      This change fixes that situation. A bare 'commit' will now take the
      authorship from CHERRY_PICK_HEAD and the commit message from MERGE_MSG.
      If the user wishes to reset authorship, that must now be done explicitly
      via --reset-author.
      
      A side-benefit of passing commit authorship along this way is that we
      can eliminate redundant authorship parsing code from revert.c.
      
      (Also removed an unused include from revert.c)
      Signed-off-by: default avatarJay Soffian <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      37f7a857
  25. 30 Nov, 2010 1 commit
  26. 25 Jun, 2010 1 commit
    • Jens Lehmann's avatar
      Add the option "--ignore-submodules" to "git status" · 46a958b3
      Jens Lehmann authored
      In some use cases it is not desirable that "git status" considers
      submodules that only contain untracked content as dirty. This may happen
      e.g. when the submodule is not under the developers control and not all
      build generated files have been added to .gitignore by the upstream
      developers. Using the "untracked" parameter for the "--ignore-submodules"
      option disables checking for untracked content and lets git diff report
      them as changed only when they have new commits or modified content.
      
      Sometimes it is not wanted to have submodules show up as changed when they
      just contain changes to their work tree (this was the behavior before
      1.7.0). An example for that are scripts which just want to check for
      submodule commits while ignoring any changes to the work tree. Also users
      having large submodules known not to change might want to use this option,
      as the - sometimes substantial - time it takes to scan the submodule work
      tree(s) is saved when using the "dirty" parameter.
      
      And if you want to ignore any changes to submodules, you can now do that
      by using this option without parameters or with "all" (when the config
      option status.submodulesummary is set, using "all" will also suppress the
      output of the submodule summary).
      
      A new function handle_ignore_submodules_arg() is introduced to parse this
      option new to "git status" in a single location, as "git diff" already
      knew it.
      Signed-off-by: default avatarJens Lehmann <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      46a958b3
  27. 03 Jun, 2010 1 commit