1. 30 8月, 2011 2 次提交
  2. 17 8月, 2011 1 次提交
    • J
      am: refresh the index at start and --resolved · 2a6f08ac
      Jeff King 提交于
      If a file is unchanged but stat-dirty, we may erroneously
      fail to apply patches, thinking that they conflict with a
      dirty working tree.
      
      This patch adds a call to "update-index --refresh". It comes
      as late as possible, so that we don't bother with it for
      thinks like "git rebase --abort", or when mbox-splitting
      fails. However, it does come before we actually start
      applying patches, meaning we will only call it once when we
      start applying patches (or any time we return to "am" after
      having resolved conflicts), and not once per patch.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      2a6f08ac
  3. 12 8月, 2011 1 次提交
    • D
      am: ignore leading whitespace before patch · 0e8341f2
      David Barr 提交于
      Some web-based email clients prepend whitespace to raw message
      transcripts to workaround content-sniffing in some browsers.  Adjust
      the patch format detection logic to ignore leading whitespace.
      
      So now you can apply patches from GMail with "git am" in three steps:
      
       1. choose "show original"
       2. tell the browser to "save as" (for example by pressing Ctrl+S)
       3. run "git am" on the saved file
      
      This fixes a regression introduced by v1.6.4-rc0~15^2~2 (git-am
      foreign patch support: autodetect some patch formats, 2009-05-27).
      GMail support was first introduced to "git am" by v1.5.4-rc0~274^2
      (Make mailsplit and mailinfo strip whitespace from the start of the
      input, 2007-11-01).
      Signed-off-by: NDavid Barr <davidbarr@google.com>
      Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      0e8341f2
  4. 09 8月, 2011 1 次提交
  5. 04 8月, 2011 1 次提交
  6. 22 5月, 2011 12 次提交
  7. 23 12月, 2010 1 次提交
  8. 22 12月, 2010 1 次提交
    • J
      am --abort: keep unrelated commits since the last failure and warn · 7b3b7e37
      Junio C Hamano 提交于
      After making commits (either by pulling or doing their own work) after a
      failed "am", the user will be reminded by next "am" invocation that there
      was a failed "am" that the user needs to decide to resolve or to get rid
      of the old "am" attempt.  The "am --abort" option was meant to help the
      latter.  However, it rewinded the HEAD back to the beginning of the failed
      "am" attempt, discarding commits made (perhaps by mistake) since.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      7b3b7e37
  9. 14 10月, 2010 1 次提交
  10. 09 10月, 2010 1 次提交
  11. 04 10月, 2010 1 次提交
  12. 17 6月, 2010 1 次提交
    • J
      am: use get_author_ident_from_commit instead of mailinfo when rebasing · 43c23251
      Jay Soffian 提交于
      In certain situations, commit authorship can consist of an invalid
      e-mail address. For example, this is the case when working with git svn
      repos where the author email has had the svn repo UUID appended such as:
      
       author@example.com <author@example.com@deadbeef-dead-beef-dead-beefdeadbeef>
      
      Given such an address, mailinfo extracts the authorship incorrectly as
      it assumes a valid domain. However, when rebasing the original
      authorship should be preserved irrespective of its validity as an email
      address.
      
      Using get_author_ident_from_commit instead of mailinfo when rebasing
      preserves the original authorship.
      Signed-off-by: NJay Soffian <jaysoffian@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      43c23251
  13. 03 6月, 2010 3 次提交
  14. 01 6月, 2010 1 次提交
    • J
      git-am: suggest what to do with superfluous patches · 05bdcfe5
      Jan Krüger 提交于
      Particularly in the context of rebase, conflicts frequently occur
      because the change in the patch to be applied was made obsolete by new
      upstream commits. In this case, solving the conflict effectively means
      skipping the patch. However, it's not always readily apparent that the
      patch needs to be skipped, and when people solve the conflict and try
      git rebase --continue, they get confronted with a message of
      
        No changes - did you forget to use 'git add'?
      
      That's not very helpful if you did actually stage your changes and they
      happen to turn the patch into a no-op. This extends the message to point
      out what's going on.
      Signed-off-by: NJan Krüger <jk@jk.gs>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      05bdcfe5
  15. 15 4月, 2010 1 次提交
    • J
      am -3: recover the diagnostic messages for corrupt patches · 0ba17dd0
      Junio C Hamano 提交于
      "git am -3" first tries to apply the patch without any extra trick, and
      applies it to a synthesized tree for 3-way merge after the first attempt
      fails.  "git apply" exits with status 1 for a patch that is well-formed
      but is not applicable (and it dies on other errors with non-zereo, non-1
      status) and has an optimization to fall back to the 3-way merge only in
      the case.
      
      An earlier patch 3ddd1703 (am: suppress apply errors when using 3-way,
      2009-06-16) squelched diagnostic messages from the first attempt, not to
      be shown to the end user.  This worked reasonably well if the reason the
      first application failed was because the patch was made against a wrong
      version.
      
      When the patch is corrupt (e.g. line-wrapped or leading whitespaces got
      dropped), however, because the second patch application is not even
      attempted, the error message from the first application is never shown
      and is forever lost.  This message is necessary to locate where the patch
      is corrupt and fix it up.
      
      We could fix this issue by reverting 3dd170, or keeping the error message
      to somewhere and showing it, but because this is an error codepath, the
      easiest is to disable the optimization.  The second patch application is
      attempted even when the input is corrupt, and it will notice, diagnose,
      and stop with an error message.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      0ba17dd0
  16. 13 3月, 2010 2 次提交
  17. 01 3月, 2010 2 次提交
  18. 24 2月, 2010 1 次提交
  19. 15 2月, 2010 1 次提交
    • J
      am: Fix launching of pager · f6dff119
      Jonathan Nieder 提交于
      The pagination functionality in git am has some problems:
      
       - It does not check if stdout is a tty, so it always paginates.
      
       - If $GIT_PAGER uses any environment variables, they are being
         ignored, since it does not run $GIT_PAGER through eval.
      
       - If $GIT_PAGER is set to the empty string, instead of passing
         output through to stdout, it tries to run $dotest/patch.
      
      Fix them.  While at it, move the definition of git_pager() to
      git-sh-setup so authors of other commands are not tempted to
      reimplement it with the same mistakes.
      Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      f6dff119
  20. 12 2月, 2010 1 次提交
  21. 26 1月, 2010 1 次提交
  22. 04 12月, 2009 1 次提交
  23. 28 11月, 2009 1 次提交
    • J
      Remove dead code from "git am" · c970a6fd
      Junio C Hamano 提交于
      Ever since the initial implementation, "git am" had kept a dead code that
      never triggered due to a typo in the variable name.  Worse yet, the code,
      if it weren't for the typo, would have attempted to add "[PATCH] " at the
      beginning of the Subject: header when "git am" is run with its "-k"
      option.  However, because "git am -k" tells mailinfo to keep such prefix
      when parsing the input, the "[PATCH] " added by this dead code would have
      really been unnecessary duplicate.
      
      Embarrassing is that we kept _maintaining_ the codepath without anybody
      noticing for four years.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c970a6fd
  24. 24 11月, 2009 1 次提交
    • J
      Protect scripted Porcelains from GREP_OPTIONS insanity · e1622bfc
      Junio C Hamano 提交于
      If the user has exported the GREP_OPTIONS environment variable, the output
      from "grep" and "egrep" in scripted Porcelains may be different from what
      they expect.  For example, we may want to count number of matching lines,
      by "grep" piped to "wc -l", and GREP_OPTIONS=-C3 will break such use.
      
      The approach taken by this change to address this issue is to protect only
      our own use of grep/egrep.  Because we do not unset it at the beginning of
      our scripts, hook scripts run from the scripted Porcelains are exposed to
      the same insanity this environment variable causes when grep/egrep is used
      to implement logic (e.g. "grep | wc -l"), and it is entirely up to the
      hook scripts to protect themselves.
      
      On the other hand, applypatch-msg hook may want to show offending words in
      the proposed commit log message using grep to the end user, and the user
      might want to set GREP_OPTIONS=--color to paint the match more visibly.
      The approach to protect only our own use without unsetting the environment
      variable globally will allow this use case.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      e1622bfc