1. 20 7月, 2008 1 次提交
  2. 26 6月, 2008 1 次提交
    • J
      clone: create intermediate directories of destination repo · 2beebd22
      Jeff King 提交于
      The shell version used to use "mkdir -p" to create the repo
      path, but the C version just calls "mkdir". Let's replicate
      the old behavior. We have to create the git and worktree
      leading dirs separately; while most of the time, the
      worktree dir contains the git dir (as .git), the user can
      override this using GIT_WORK_TREE.
      
      We can reuse safe_create_leading_directories, but we need to
      make a copy of our const buffer to do so. Since
      merge-recursive uses the same pattern, we can factor this
      out into a global function. This has two other cleanup
      advantages for merge-recursive:
      
        1. mkdir_p wasn't a very good name. "mkdir -p foo/bar" actually
           creates bar, but this function just creates the leading
           directories.
      
        2. mkdir_p took a mode argument, but it was completely
           ignored.
      Acked-by: NDaniel Barkalow <barkalow@iabervon.org>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      2beebd22
  3. 20 6月, 2008 1 次提交
    • L
      Make git_dir a path relative to work_tree in setup_work_tree() · 044bbbcb
      Linus Torvalds 提交于
      Once we find the absolute paths for git_dir and work_tree, we can make
      git_dir a relative path since we know pwd will be work_tree. This should
      save the kernel some time traversing the path to work_tree all the time
      if git_dir is inside work_tree.
      
      Daniel's patch didn't apply for me as-is, so I recreated it with some
      differences, and here are the numbers from ten runs each.
      
      There is some IO for me - probably due to more-or-less random flushing of
      the journal - so the variation is bigger than I'd like, but whatever:
      
      	Before:
      		real    0m8.135s
      		real    0m7.933s
      		real    0m8.080s
      		real    0m7.954s
      		real    0m7.949s
      		real    0m8.112s
      		real    0m7.934s
      		real    0m8.059s
      		real    0m7.979s
      		real    0m8.038s
      
      	After:
      		real    0m7.685s
      		real    0m7.968s
      		real    0m7.703s
      		real    0m7.850s
      		real    0m7.995s
      		real    0m7.817s
      		real    0m7.963s
      		real    0m7.955s
      		real    0m7.848s
      		real    0m7.969s
      
      Now, going by "best of ten" (on the assumption that the longer numbers
      are all due to IO), I'm saying a 7.933s -> 7.685s reduction, and it does
      seem to be outside of the noise (ie the "after" case never broke 8s, while
      the "before" case did so half the time).
      
      So looks like about 3% to me.
      
      Doing it for a slightly smaller test-case (just the "arch" subdirectory)
      gets more stable numbers probably due to not filling the journal with
      metadata updates, so we have:
      
      	Before:
      		real    0m1.633s
      		real    0m1.633s
      		real    0m1.633s
      		real    0m1.632s
      		real    0m1.632s
      		real    0m1.630s
      		real    0m1.634s
      		real    0m1.631s
      		real    0m1.632s
      		real    0m1.632s
      
      	After:
      		real    0m1.610s
      		real    0m1.609s
      		real    0m1.610s
      		real    0m1.608s
      		real    0m1.607s
      		real    0m1.610s
      		real    0m1.609s
      		real    0m1.611s
      		real    0m1.608s
      		real    0m1.611s
      
      where I'ld just take the averages and say 1.632 vs 1.610, which is just
      over 1% peformance improvement.
      
      So it's not in the noise, but it's not as big as I initially thought and
      measured.
      
      (That said, it obviously depends on how deep the working directory path is
      too, and whether it is behind NFS or something else that might need to
      cause more work to look up).
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      044bbbcb
  4. 19 6月, 2008 1 次提交
    • L
      Add config option to enable 'fsync()' of object files · aafe9fba
      Linus Torvalds 提交于
      As explained in the documentation[*] this is totally useless on
      filesystems that do ordered/journalled data writes, but it can be a
      useful safety feature on filesystems like HFS+ that only journal the
      metadata, not the actual file contents.
      
      It defaults to off, although we could presumably in theory some day
      auto-enable it on a per-filesystem basis.
      
      [*] Yes, I updated the docs for the thing.  Hell really _has_ frozen
          over, and the four horsemen are probably just beyond the horizon.
          EVERYBODY PANIC!
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      aafe9fba
  5. 17 6月, 2008 1 次提交
  6. 14 6月, 2008 1 次提交
  7. 07 6月, 2008 1 次提交
  8. 01 6月, 2008 1 次提交
  9. 22 5月, 2008 1 次提交
  10. 16 5月, 2008 1 次提交
  11. 15 5月, 2008 1 次提交
  12. 14 5月, 2008 1 次提交
  13. 13 5月, 2008 2 次提交
  14. 12 5月, 2008 1 次提交
  15. 11 5月, 2008 2 次提交
    • L
      Optimize symlink/directory detection · c40641b7
      Linus Torvalds 提交于
      This is the base for making symlink detection in the middle fo a pathname
      saner and (much) more efficient.
      
      Under various loads, we want to verify that the full path leading up to a
      filename is a real directory tree, and that when we successfully do an
      'lstat()' on a filename, we don't get a false positive due to a symlink in
      the middle of the path that git should have seen as a symlink, not as a
      normal path component.
      
      The 'has_symlink_leading_path()' function already did this, and cached
      a single level of symlink information, but didn't cache the _lack_ of a
      symlink, so the normal behaviour was actually the wrong way around, and we
      ended up doing an 'lstat()' on each path component to check that it was a
      real directory.
      
      This caches the last detected full directory and symlink entries, and
      speeds up especially deep directory structures a lot by avoiding to
      lstat() all the directories leading up to each entry in the index.
      
      [ This can - and should - probably be extended upon so that we eventually
        never do a bare 'lstat()' on any path entries at *all* when checking the
        index, but always check the full path carefully. Right now we do not
        generally check the whole path for all our normal quick index
        revalidation.
      
        We should also make sure that we're careful about all the invalidation,
        ie when we remove a link and replace it by a directory we should
        invalidate the symlink cache if it matches (and vice versa for the
        directory cache).
      
        But regardless, the basic function needs to be sane to do that. The old
        'has_symlink_leading_path()' was not capable enough - or indeed the code
        readable enough - to really do that sanely. So I'm pushing this as not
        just an optimization, but as a base for further work. ]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c40641b7
    • L
      Avoid some unnecessary lstat() calls · d177cab0
      Linus Torvalds 提交于
      The commit sequence used to do
      
      	if (file_exists(p->path))
      		add_file_to_cache(p->path, 0);
      
      where both "file_exists()" and "add_file_to_cache()" needed to do a
      lstat() on the path to do their work.
      
      This cuts down 'lstat()' calls for the partial commit case by two
      for each path we know about (because we do this twice per path).
      
      Just move the lstat() to the caller instead (that's all that
      "file_exists()" really does), and pass the stat information down to the
      add_to_cache() function.
      
      This essentially makes 'add_to_index()' the core function that adds a path
      to the index, getting the index pointer, the pathname and the stat
      information as arguments. There are then shorthand helper functions that
      use this core function:
      
       - 'add_to_cache()' is just 'add_to_index()' with the default index
      
       - 'add_file_to_cache/index()' is the same, but does the lstat() call
         itself, so you can pass just the pathname if you don't already have the
         stat information available.
      
      So old users of the 'add_file_to_xyzzy()' are essentially left unchanged,
      and this just exposes the more generic helper function that can take
      existing stat information into account.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      d177cab0
  16. 07 5月, 2008 1 次提交
  17. 05 5月, 2008 4 次提交
  18. 30 4月, 2008 1 次提交
  19. 27 4月, 2008 1 次提交
  20. 17 4月, 2008 1 次提交
    • H
      Make core.sharedRepository more generic · 06cbe855
      Heikki Orsila 提交于
      git init --shared=0xxx, where '0xxx' is an octal number, will create
      a repository with file modes set to '0xxx'. Users with a safe umask
      value (0077) can use this option to force file modes. For example,
      '0640' is a group-readable but not group-writable regardless of
      user's umask value. Values compatible with old Git versions are written
      as they were before, for compatibility reasons. That is, "1" for
      "group" and "2" for "everybody".
      
      "git config core.sharedRepository 0xxx" is also handled.
      Signed-off-by: NHeikki Orsila <heikki.orsila@iki.fi>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      06cbe855
  21. 13 4月, 2008 1 次提交
  22. 09 4月, 2008 6 次提交
  23. 09 3月, 2008 2 次提交
  24. 26 2月, 2008 2 次提交
  25. 25 2月, 2008 1 次提交
  26. 24 2月, 2008 1 次提交
  27. 23 2月, 2008 2 次提交