1. 16 8月, 2010 1 次提交
  2. 09 4月, 2010 1 次提交
    • J
      log.decorate: only ignore it under "log --pretty=raw" · 4f62c2bc
      Junio C Hamano 提交于
      Unlike notes that are often multi-line and disrupting to be placed in many
      output formats, a decoration is designed to be a small token that can be
      tacked after an existing line of the output where a commit object name sits.
      Disabling log.decorate for something like "log --oneline" would defeat the
      purpose of the configuration.
      
      We _might_ want to change it further in the future to force scripts that
      do not want to be broken by random end user configurations to explicitly
      say "log --no-decorate", but that would be an incompatible change that
      needs the usual multi-release-cycle deprecation process.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      4f62c2bc
  3. 07 4月, 2010 1 次提交
    • J
      log --pretty/--oneline: ignore log.decorate · 635530a2
      Junio C Hamano 提交于
      Many scripts, most notably gitk, rely on output from the log family of
      command not to be molested by random user configuration.  This is
      especially true when --pretty=raw is given.
      
      Just like we disable notes output unless the command line explicitly
      asks for --show-notes, disable the decoration code unless --decorate is
      given explicitly from the command line and --pretty or --oneline is
      given.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      635530a2
  4. 18 2月, 2010 1 次提交
    • J
      log.decorate: usability fixes · 8a3d203b
      Junio C Hamano 提交于
      The configuration is meant to suppliment --decorate command line option
      that can be used as a boolean to turn the feature on, so it is natural
      to expect
      
      	[log]
      		decorate
      		decorate = yes
      
      to work.  The original commit would segfault with the first one, and
      would not understand the second one.
      
      Once a user has this configuration in ~/.gitconfig, there needs to be a
      way to override it from the command line.  Add --no-decorate option to
      log family and also allow --decorate=no to mean the same thing.  Since
      we allow setting log.decorate to 'true', the command line also should
      accept --decorate=yes and behave accordingly.
      
      New tests in t4202 are designed to exercise the interaction between the
      configuration variable and the command line option that overrides it.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      8a3d203b
  5. 27 1月, 2010 1 次提交
  6. 23 11月, 2009 1 次提交
  7. 10 8月, 2009 1 次提交
    • J
      merge: fix incorrect merge message for ambiguous tag/branch · 751c5974
      Jeff King 提交于
      If we have both a tag and a branch named "foo", then calling
      "git merge foo" will warn about the ambiguous ref, but merge
      the tag.
      
      When generating the commit message, though, we simply
      checked whether "refs/heads/foo" existed, and if it did,
      assumed it was a branch. This led to the statement "Merge
      branch 'foo'" in the commit message, which is quite wrong.
      
      Instead, we should use dwim_ref to find the actual ref used,
      and describe it appropriately.
      
      In addition to the test in t7608, we must also tweak the
      expected output of t4202, which was accidentally triggering
      this bug.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      751c5974
  8. 19 7月, 2009 1 次提交
  9. 27 4月, 2009 1 次提交
  10. 23 4月, 2009 3 次提交
  11. 25 2月, 2009 1 次提交
  12. 20 2月, 2009 1 次提交
  13. 24 1月, 2009 1 次提交
  14. 25 8月, 2008 1 次提交
    • J
      Fix "git log -i --grep" · 0843acfd
      Jeff King 提交于
      This has been broken in v1.6.0 due to the reorganization of
      the revision option parsing code. The "-i" is completely
      ignored, but works fine in "git log --grep -i".
      
      What happens is that the code for "-i" looks for
      revs->grep_filter; if it is NULL, we do nothing, since there
      are no grep filters. But that is obviously not correct,
      since we want it to influence the later --grep option. Doing
      it the other way around works, since "-i" just impacts the
      existing grep_filter option.
      
      Instead, we now always initialize the grep_filter member and
      just fill in options and patterns as we get them. This means
      that we can no longer check grep_filter for NULL, but
      instead must check the pattern list to see if we have any
      actual patterns.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      0843acfd
  15. 02 8月, 2008 1 次提交
  16. 24 7月, 2008 1 次提交
  17. 27 12月, 2007 1 次提交