1. 07 8月, 2007 4 次提交
  2. 06 8月, 2007 13 次提交
    • A
      Documentation/git-svn: how to clone a git-svn-created repository · 7d4aef40
      Adam Roben 提交于
      These instructions tell you how to create a clone of a repository
      created with git-svn, that can in turn be used with git-svn.
      Signed-off-by: NAdam Roben <aroben@apple.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      7d4aef40
    • J
      Merge branch 'maint' · a6954452
      Junio C Hamano 提交于
      * maint:
        apply: remove directory that becomes empty by renaming the last file away
        setup.c:verify_non_filename(): don't die unnecessarily while disambiguating
      a6954452
    • L
      apply: remove directory that becomes empty by renaming the last file away · 93969438
      Linus Torvalds 提交于
      We attempt to remove directory that becomes empty after removal
      of a file.  We should do the same when we rename an existing
      file away.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      93969438
    • J
      setup.c:verify_non_filename(): don't die unnecessarily while disambiguating · 33a798c8
      Junio C Hamano 提交于
      If you have a working tree _file_ "foo", attempt to refer to a
      branch "foo/bar" without -- to disambiguate, like this:
      
      	$ git log foo/bar
      
      tried to make sure that foo/bar cannot be naming a working tree
      file "foo/bar" (in which case we would say "which one do you
      want?  A rev or a working tree file?  clarify with -- please").
      We run lstat("foo/bar") to check that.  If it does not succeed,
      there is no ambiguity.
      
      That is good.  But we also checked the error status for the
      lstat() and expected it to fail with ENOENT.  In this particular
      case, however, it fails with ENOTDIR.  That should be treated as
      "expected error" as well.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      33a798c8
    • J
      documentation: use the word "index" in the git-commit man page · a76c2acb
      J. Bruce Fields 提交于
      As with git-add, I think previous updates to the git-commit man page did
      indeed help make it more user-friendly.  But I think the banishment of
      the word "index" from the description goes too far; reinstate its use,
      to simplify some of the language slightly and smooth the transition to
      other documentation.
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      a76c2acb
    • J
      Merge branch 'master' of git://linux-nfs.org/~bfields/git · a2c3db8d
      Junio C Hamano 提交于
      * 'master' of git://linux-nfs.org/~bfields/git:
        documentation: use the word "index" in the git-add manual page
        user-manual: mention git-gui
        user-manual: mention git stash
        user-manual: update for new default --track behavior
      a2c3db8d
    • J
      Merge branch 'maint' · db1a4bc1
      J. Bruce Fields 提交于
      db1a4bc1
    • J
      documentation: use the word "index" in the git-add manual page · 5f42ac92
      J. Bruce Fields 提交于
      It was a neat trick to show that you could introduce the git-add manual
      page without using the word "index", and it was certainly an improvement
      over the previous man page (which started out "A simple wrapper for
      git-update-index to add files to the index...").
      
      But it's possible to use the standard terminology without sacrificing
      user-friendliness.  So, rewrite to use the word "index" when
      appropriate.
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      5f42ac92
    • J
      user-manual: mention git-gui · 407c0c87
      J. Bruce Fields 提交于
      The git gui project seems to be still in early stages, but at a point
      where it's worth mentioning as an alternative way of creating commits.
      
      One feature of interest is the ability to manipulate individual diff
      hunks.  However, people have found that feature not to be easily
      discoverable from the user-interface.  Pending some ui improvements, a
      parenthetical hint here may help.
      
      (Thanks to Steffen Prohask and Junio Hamano for suggesting the
      language.)
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      407c0c87
    • J
      user-manual: mention git stash · 7a7cc594
      Junio C Hamano 提交于
      Mention the git-stash command as a way to temporarily set aside work in
      progress.
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      7a7cc594
    • J
      user-manual: update for new default --track behavior · 0eb4f7cd
      J. Bruce Fields 提交于
      Update documentation to reflect the --track default.
      
      That change seems to have happened in the 1.5.3 -rc's, so bump the "for
      version x.y.z or newer" warning as well.
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      0eb4f7cd
    • J
      Fix install-doc-quick target · 00d8c518
      Junio C Hamano 提交于
      The script starts in a subdirectory of the source directory to
      muck with a branch whose structure does not have anything to
      do with the actual work tree.  Go up to the top to make it clear
      that we operate on the whole tree.
      
      It also exported GIT_DIR without any good reason.  Remove it.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      00d8c518
    • J
      unpack-trees.c: assume submodules are clean during check-out · 936492d3
      Junio C Hamano 提交于
      Sven originally raised this issue:
      
          If you have a submodule checked out and you go back (or
          forward) to a revision of the supermodule that contains a
          different revision of the submodule and then switch to
          another revision, it will complain that the submodule is not
          uptodate, because git simply didn't update the submodule in
          the first move.
      
      The current policy is to consider it is perfectly normal that
      checked-out submodule is out-of-sync wrt the supermodule index.
      At least until we introduce a superproject repository
      configuration option that says "in this repository, I do care
      about this submodule and at any time I move around in the
      superproject, recursively check out the submodule to match", it
      is a reasonable policy, as we currently do not recursively
      checkout the submodules at all.  The most extreme case of this
      policy is that the superproject index knows about the submodule
      but the subdirectory does not even have to be checked out.
      
      The function verify_uptodate(), called during the two-way merge
      aka branch switching, is about "make sure the filesystem entity
      that corresponds to this cache entry is up to date, lest we lose
      the local modifications".  As we explicitly allow submodule
      checkout to drift from the supermodule index entry, the check
      should say "Ok, for submodules, not matching is the norm" for
      now.
      
      Later when we have the ability to mark "I care about this
      submodule to be always in sync with the superproject" (thereby
      implementing automatic recursive checkout and perhaps diff,
      among other things), we should check if the submodule in
      question is marked as such and perform the current test.
      Acked-by: NLars Hjemli <hjemli@gmail.com>
      Acked-by: NSven Verdoolaege <skimo@kotnet.org>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      936492d3
  3. 05 8月, 2007 2 次提交
  4. 04 8月, 2007 7 次提交
  5. 03 8月, 2007 5 次提交
  6. 02 8月, 2007 9 次提交