1. 03 4月, 2010 3 次提交
  2. 23 2月, 2010 1 次提交
    • L
      Move 'builtin-*' into a 'builtin/' subdirectory · 81b50f3c
      Linus Torvalds 提交于
      This shrinks the top-level directory a bit, and makes it much more
      pleasant to use auto-completion on the thing. Instead of
      
      	[torvalds@nehalem git]$ em buil<tab>
      	Display all 180 possibilities? (y or n)
      	[torvalds@nehalem git]$ em builtin-sh
      	builtin-shortlog.c     builtin-show-branch.c  builtin-show-ref.c
      	builtin-shortlog.o     builtin-show-branch.o  builtin-show-ref.o
      	[torvalds@nehalem git]$ em builtin-shor<tab>
      	builtin-shortlog.c  builtin-shortlog.o
      	[torvalds@nehalem git]$ em builtin-shortlog.c
      
      you get
      
      	[torvalds@nehalem git]$ em buil<tab>		[type]
      	builtin/   builtin.h
      	[torvalds@nehalem git]$ em builtin		[auto-completes to]
      	[torvalds@nehalem git]$ em builtin/sh<tab>	[type]
      	shortlog.c     shortlog.o     show-branch.c  show-branch.o  show-ref.c     show-ref.o
      	[torvalds@nehalem git]$ em builtin/sho		[auto-completes to]
      	[torvalds@nehalem git]$ em builtin/shor<tab>	[type]
      	shortlog.c  shortlog.o
      	[torvalds@nehalem git]$ em builtin/shortlog.c
      
      which doesn't seem all that different, but not having that annoying
      break in "Display all 180 possibilities?" is quite a relief.
      
      NOTE! If you do this in a clean tree (no object files etc), or using an
      editor that has auto-completion rules that ignores '*.o' files, you
      won't see that annoying 'Display all 180 possibilities?' message - it
      will just show the choices instead.  I think bash has some cut-off
      around 100 choices or something.
      
      So the reason I see this is that I'm using an odd editory, and thus
      don't have the rules to cut down on auto-completion.  But you can
      simulate that by using 'ls' instead, or something similar.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      81b50f3c
  3. 18 2月, 2010 1 次提交
  4. 20 1月, 2010 1 次提交
    • J
      status: don't require the repository to be writable · ab685451
      Junio C Hamano 提交于
      We need to update the index before hooks run when actually making a
      commit, but we shouldn't have to write the index when running "status".
      If we can, then we have already spent cycles to refresh the index and
      it is a waste not to write it out, but it is not a disaster if we cannot
      write it out.  The main reason the user is running "git status" is to get
      the "status", and refreshing the index is a mere side effect that we can
      do without.
      
      Discovery and initial attempted fix by Dscho.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ab685451
  5. 18 1月, 2010 2 次提交
  6. 17 1月, 2010 1 次提交
  7. 16 1月, 2010 1 次提交
  8. 15 1月, 2010 2 次提交
    • J
      commit: allow suppression of implicit identity advice · b706fcfe
      Jeff King 提交于
      We now nag the user with a giant warning when their identity
      was pulled from the username, hostname, and gecos
      information, in case it is not correct. Most users will
      suppress this by simply setting up their information
      correctly.
      
      However, there may be some users who consciously want to use
      that information, because having the value change from host
      to host contains useful information. These users can now set
      advice.implicitidentity to false to suppress the message.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      b706fcfe
    • J
      commit: show interesting ident information in summary · 49ff9a7a
      Jeff King 提交于
      There are a few cases of user identity information that we consider
      interesting:
      
        (1) When the author and committer identities do not match.
      
        (2) When the committer identity was picked automatically from the
            username, hostname and GECOS information.
      
      In these cases, we already show the information in the commit
      message template. However, users do not always see that template
      because they might use "-m" or "-F". With this patch, we show these
      interesting cases after the commit, along with the subject and
      change summary. The new output looks like:
      
        $ git commit \
            -m "federalist papers" \
            --author='Publius <alexander@hamilton.com>'
        [master 3d226a7] federalist papers
         Author: Publius <alexander@hamilton.com>
         1 files changed, 1 insertions(+), 0 deletions(-)
      
      for case (1), and:
      
        $ git config --global --unset user.name
        $ git config --global --unset user.email
        $ git commit -m foo
        [master 7c2a927] foo
         Committer: Jeff King <peff@c-71-185-130-222.hsd1.va.comcast.net>
        Your name and email address were configured automatically based
        on your username and hostname. Please check that they are accurate.
        You can suppress this message by setting them explicitly:
      
            git config --global user.name Your Name
            git config --global user.email you@example.com
      
        If the identity used for this commit is wrong, you can fix it with:
      
            git commit --amend --author='Your Name <you@example.com>'
      
         1 files changed, 1 insertions(+), 0 deletions(-)
      
      for case (2).
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      49ff9a7a
  9. 13 1月, 2010 2 次提交
    • J
      commit: support commit.status, --status, and --no-status · bed575e4
      James P. Howard, II 提交于
      A new configuration variable commit.status, and new command line
      options --status, and --no-status control whether or not the git
      status information is included in the commit message template
      when using an editor to prepare the commit message.  It does not
      affect the effects of a user's commit.template settings.
      Signed-off-by: NJames P. Howard, II <jh@jameshoward.us>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      bed575e4
    • M
      Be more user-friendly when refusing to do something because of conflict. · d38a30df
      Matthieu Moy 提交于
      Various commands refuse to run in the presence of conflicts (commit,
      merge, pull, cherry-pick/revert). They all used to provide rough, and
      inconsistant error messages.
      
      A new variable advice.resolveconflict is introduced, and allows more
      verbose messages, pointing the user to the appropriate solution.
      
      For commit, the error message used to look like this:
      
      $ git commit
      foo.txt: needs merge
      foo.txt: unmerged (c34a92682e0394bc0d6f4d4a67a8e2d32395c169)
      foo.txt: unmerged (3afcd75de8de0bb5076942fcb17446be50451030)
      foo.txt: unmerged (c9785d77b76dfe4fb038bf927ee518f6ae45ede4)
      error: Error building trees
      
      The "need merge" line is given by refresh_cache. We add the IN_PORCELAIN
      option to make the output more consistant with the other porcelain
      commands, and catch the error in return, to stop with a clean error
      message. The next lines were displayed by a call to cache_tree_update(),
      which is not reached anymore if we noticed the conflict.
      
      The new output looks like:
      
      U       foo.txt
      fatal: 'commit' is not possible because you have unmerged files.
      Please, fix them up in the work tree, and then use 'git add/rm <file>' as
      appropriate to mark resolution and make a commit, or use 'git commit -a'.
      
      Pull is slightly modified to abort immediately if $GIT_DIR/MERGE_HEAD
      exists instead of waiting for merge to complain.
      
      The behavior of merge and the test-case are slightly modified to reflect
      the usual flow: start with conflicts, fix them, and afterwards get rid of
      MERGE_HEAD, with different error messages at each stage.
      Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      d38a30df
  10. 11 1月, 2010 1 次提交
    • J
      ident.c: check explicit identity for name and email separately · 91c38a21
      Junio C Hamano 提交于
      bb1ae3f6 (commit: Show committer if automatic, 2008-05-04) added a logic to
      check both name and email were given explicitly by the end user, but it
      assumed that fmt_ident() is never called before git_default_user_config()
      is called, which was fragile.  The former calls setup_ident() and fills
      the "default" name and email, so the check in the config parser would have
      mistakenly said both are given even if only user.name was provided.
      
      Make the logic more robust by keeping track of name and email separately.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      Acked-by: NSanti Béjar <santi@agolina.net>
      91c38a21
  11. 30 12月, 2009 1 次提交
    • G
      commit: --cleanup is a message option · e97ca7f4
      Greg Price 提交于
      In the usage message for "git commit", the --cleanup option appeared
      at the end, as one of the "contents options":
      
      usage: git commit [options] [--] <filepattern>...
      ...
      Commit message options
      ...
      Commit contents options
      ...
          --allow-empty         ok to record an empty change
          --cleanup <default>   how to strip spaces and #comments from message
      
      This is confusing, in part because it makes it ambiguous whether
      --allow-empty, just above, refers to an empty diff or an empty message.
      
      Move --cleanup into the 'message options' group.  Also add a pair of
      comments to prevent similar oversights in the future.
      Signed-off-by: NGreg Price <price@ksplice.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      e97ca7f4
  12. 17 12月, 2009 1 次提交
    • J
      ignore unknown color configuration · 8b8e8624
      Jeff King 提交于
      When parsing the config file, if there is a value that is
      syntactically correct but unused, we generally ignore it.
      This lets non-core porcelains store arbitrary information in
      the config file, and it means that configuration files can
      be shared between new and old versions of git (the old
      versions might simply ignore certain configuration).
      
      The one exception to this is color configuration; if we
      encounter a color.{diff,branch,status}.$slot variable, we
      die if it is not one of the recognized slots (presumably as
      a safety valve for user misconfiguration). This behavior
      has existed since 801235c5 (diff --color: use
      $GIT_DIR/config, 2006-06-24), but hasn't yet caused a
      problem. No porcelain has wanted to store extra colors, and
      we once a color area (like color.diff) has been introduced,
      we've never changed the set of color slots.
      
      However, that changed recently with the addition of
      color.diff.func. Now a user with color.diff.func in their
      config can no longer freely switch between v1.6.6 and older
      versions; the old versions will complain about the existence
      of the variable.
      
      This patch loosens the check to match the rest of
      git-config; unknown color slots are simply ignored. This
      doesn't fix this particular problem, as the older version
      (without this patch) is the problem, but it at least
      prevents it from happening again in the future.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      8b8e8624
  13. 15 12月, 2009 1 次提交
  14. 12 12月, 2009 2 次提交
    • J
      status/commit: do not suggest "reset HEAD <path>" while merging · 3c588453
      Junio C Hamano 提交于
      Suggesting "'reset HEAD <path>' to unstage" is dead wrong if we are about
      to record a merge commit.  For either an unmerged path (i.e. with
      unresolved conflicts), or an updated path, it would result in discarding
      what the other branch did.
      
      Note that we do not do anything special in a case where we are amending a
      merge.  The user is making an evil merge starting from an already
      committed merge, and running "reset HEAD <path>" is the right way to get
      rid of the local edit that has been added to the index.
      
      Once "reset --unresolve <path>" becomes available, we might want to
      suggest it for a merged path that has unresolve information, but until
      then, just remove the incorrect advice.
      
      We might also want to suggest "checkout --conflict <path>" to revert the
      file in the work tree to the state of failed automerge for an unmerged
      path, but we never did that, and this commit does not change that.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      3c588453
    • J
      commit/status: check $GIT_DIR/MERGE_HEAD only once · 30988301
      Junio C Hamano 提交于
      The code checked for the MERGE_HEAD file to see if we were about
      to commit a merge twice in the codepath; also one of them used a
      variable merge_head_sha1[] which was set but was never used.
      
      Just check it once, but do so also in "git status", too, as
      we will be using this for status generation in the next patch.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      30988301
  15. 07 12月, 2009 2 次提交
    • J
      status: reduce duplicated setup code · 8661768f
      Jeff King 提交于
      We have three output formats: short, porcelain, and long.
      The short and long formats respect user-config, and the
      porcelain one does not. This led to us repeating
      config-related setup code for the short and long formats.
      
      Since the last commit, color config is explicitly cleared
      when showing the porcelain format. Let's do the same with
      relative-path configuration, which enables us to hoist the
      duplicated code from the switch statement in cmd_status.
      
      As a bonus, this fixes "commit --dry-run --porcelain", which
      was unconditionally setting up that configuration, anyway.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      8661768f
    • J
      status: disable color for porcelain format · 4a7cc2fd
      Jeff King 提交于
      The porcelain format is identical to the shortstatus format,
      except that it should not respect any user configuration,
      including color.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      4a7cc2fd
  16. 06 12月, 2009 2 次提交
  17. 04 12月, 2009 2 次提交
  18. 27 11月, 2009 1 次提交
  19. 18 11月, 2009 1 次提交
  20. 07 11月, 2009 1 次提交
    • J
      builtin-commit.c: fix logic to omit empty line before existing footers · e5138436
      Junio C Hamano 提交于
      "commit -s" used to add an empty line before adding S-o-b line only when
      the last line of the existing log message is not another S-o-b line, but
      c1e01b0c (commit: More generous accepting of RFC-2822 footer lines.,
      2009-10-28) introduced logic to omit this empty line when the message ends
      with a run of "footer" lines, to cover S-o-b's friends, e.g. Acked-by.
      
      However, the logic was overzealous and missed one corner case.  A message
      that consists of a single line that begins with Token + colon, it can be
      mistaken as a S-o-b's friend.  We do want an empty line in such a case.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      e5138436
  21. 05 11月, 2009 1 次提交
    • E
      commit -c/-C/--amend: reset timestamp and authorship to committer with --reset-author · c51f6cee
      Erick Mattos 提交于
      When we use -c, -C, or --amend, we are trying one of two things: using the
      source as a template or modifying a commit with corrections.
      
      When these options are used, the authorship and timestamp recorded in the
      newly created commit are always taken from the original commit.  This is
      inconvenient when we just want to borrow the commit log message or when
      our change to the code is so significant that we should take over the
      authorship (with the blame for bugs we introduce, of course).
      
      The new --reset-author option is meant to solve this need by regenerating
      the timestamp and setting the committer as the new author.
      Signed-off-by: NErick Mattos <erick.mattos@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c51f6cee
  22. 29 10月, 2009 1 次提交
    • D
      commit: More generous accepting of RFC-2822 footer lines. · c1e01b0c
      David Brown 提交于
      'git commit -s' will insert a blank line before the Signed-off-by
      line at the end of the message, unless this last line is a
      Signed-off-by line itself.  Common use has other trailing lines
      at the ends of commit text, in the style of RFC2822 headers.
      
      Be more generous in considering lines to be part of this footer.
      If the last paragraph of the commit message reasonably resembles
      RFC-2822 formatted lines, don't insert that blank line.
      
      The new Signed-off-by line is still only suppressed when the
      author's existing Signed-off-by is the last line of the message.
      Signed-off-by: NDavid Brown <davidb@quicinc.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c1e01b0c
  23. 20 10月, 2009 1 次提交
    • T
      Refactor pretty_print_commit arguments into a struct · dd2e794a
      Thomas Rast 提交于
      pretty_print_commit() has a bunch of rarely-used arguments, and
      introducing more of them requires yet another update of all the call
      sites.  Refactor most of them into a struct to make future extensions
      easier.
      
      The ones that stay "plain" arguments were chosen on the grounds that
      all callers put real arguments there, whereas some callers have 0/NULL
      for all arguments that were factored into the struct.
      
      We declare the struct 'const' to ensure none of the callers are bitten
      by the changed (no longer call-by-value) semantics.
      Signed-off-by: NThomas Rast <trast@student.ethz.ch>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      dd2e794a
  24. 06 9月, 2009 5 次提交
  25. 24 8月, 2009 1 次提交
  26. 23 8月, 2009 2 次提交
    • J
      git status: not "commit --dry-run" anymore · 9e4b7ab6
      Junio C Hamano 提交于
      This removes tentative "git stat" and make it take over "git status".
      
      There are some tests that expect "git status" to exit with non-zero status
      when there is something staged.  Some tests expect "git status path..." to
      show the status for a partial commit.
      
      For these, replace "git status" with "git commit --dry-run".  For the
      ones that do not attempt a dry-run of a partial commit that check the
      output from the command, check the output from "git status" as well, as
      they should be identical.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      9e4b7ab6
    • J
      git stat -s: short status output · 173e6c88
      Junio C Hamano 提交于
      Give -s(hort) option to "git stat" that shows the status of paths in a
      more concise way.
      
          XY PATH1 -> PATH2
      
      format to be more machine readable than output from "git status", which is
      about previewing of "git commit" with the same arguments.
      
      PATH1 is the path in the HEAD, and " -> PATH2" part is shown only when
      PATH1 corresponds to a different path in the index/worktree.
      
      For unmerged entries, X shows the status of stage #2 (i.e. ours) and Y
      shows the status of stage #3 (i.e. theirs).  For entries that do not have
      conflicts, X shows the status of the index, and Y shows the status of the
      work tree.  For untracked paths, XY are "??".
      
          X          Y     Meaning
          -------------------------------------------------
                    [MD]   not updated
          M        [ MD]   updated in index
          A        [ MD]   added to index
          D        [ MD]   deleted from index
          R        [ MD]   renamed in index
          C        [ MD]   copied in index
          [MARC]           index and work tree matches
          [ MARC]     M    work tree changed since index
          [ MARC]     D    deleted in work tree
      
          D           D    unmerged, both deleted
          A           U    unmerged, added by us
          U           D    unmerged, deleted by them
          U           A    unmerged, added by them
          D           U    unmerged, deleted by us
          A           A    unmerged, both added
          U           U    unmerged, both modified
      
          ?           ?    untracked
      
      When given -z option, the records are terminated by NUL characters for
      better machine readability.  Because the traditional long format is
      designed for human consumption, NUL termination does not make sense.
      For this reason, -z option implies -s (short output).
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      173e6c88