1. 02 8月, 2006 1 次提交
  2. 31 7月, 2006 1 次提交
  3. 29 7月, 2006 1 次提交
  4. 27 7月, 2006 2 次提交
  5. 24 7月, 2006 1 次提交
  6. 09 7月, 2006 6 次提交
  7. 08 7月, 2006 1 次提交
  8. 07 7月, 2006 1 次提交
  9. 04 7月, 2006 1 次提交
  10. 03 7月, 2006 3 次提交
  11. 02 7月, 2006 1 次提交
    • E
      Add git-instaweb, instantly browse the working repo with gitweb · a51d37c1
      Eric Wong 提交于
      I got tired of having to configure gitweb for every repository
      I work on.  I sometimes prefer gitweb to standard GUIs like gitk
      or gitview; so this lets me automatically configure gitweb to
      browse my working repository and also opens my browser to it.
      
      Updates from the original patch:
      
      Added Apache/mod_perl2 compatibility if Dennis Stosberg's gitweb
      has been applied, too: <20060621130708.Gcbc6e5c@leonov.stosberg.net>
      
      General cleanups in shell code usage.
      Signed-off-by: NEric Wong <normalperson@yhbt.net>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      a51d37c1
  12. 30 6月, 2006 2 次提交
  13. 29 6月, 2006 1 次提交
    • L
      Improved three-way blob merging code · 0c799383
      Linus Torvalds 提交于
      This fleshes out the code that generates a three-way merge of a set of
      blobs.
      
      It still actually does the three-way merge using an external executable
      (ie just calling "merge"), but the interfaces have been cleaned up a lot
      and are now fully based on the 'mmfile_t' interface, so if libxdiff were
      to ever grow a compatible three-way-merge, it could probably be directly
      plugged in.
      
      It also uses the previous XDL_EMIT_COMMON functionality extension to
      libxdiff to generate a made-up base file for the merge for the case where
      no base file previously existed. This should be equivalent to what we
      currently do in git-merge-one-file.sh:
      
      	diff -u -La/$orig -Lb/$orig $orig $src2 | git-apply --no-add
      
      except it should be much simpler and can be done using the direct libxdiff
      interfaces.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      0c799383
  14. 25 6月, 2006 1 次提交
  15. 24 6月, 2006 1 次提交
  16. 23 6月, 2006 1 次提交
  17. 22 6月, 2006 2 次提交
  18. 21 6月, 2006 1 次提交
  19. 20 6月, 2006 1 次提交
    • L
      Add specialized object allocator · 855419f7
      Linus Torvalds 提交于
      This creates a simple specialized object allocator for basic
      objects.
      
      This avoids wasting space with malloc overhead (metadata and
      extra alignment), since the specialized allocator knows the
      alignment, and that objects, once allocated, are never freed.
      
      It also allows us to track some basic statistics about object
      allocations. For example, for the mozilla import, it shows
      object usage as follows:
      
           blobs:   627629 (14710 kB)
           trees:  1119035 (34969 kB)
         commits:   196423  (8440 kB)
            tags:     1336    (46 kB)
      
      and the simpler allocator shaves off about 2.5% off the memory
      footprint off a "git-rev-list --all --objects", and is a bit
      faster too.
      
      [ Side note: this concludes the series of "save memory in object storage".
        The thing is, there simply isn't much more to be saved on the objects.
      
        Doing "git-rev-list --all --objects" on the mozilla archive has a final
        total RSS of 131498 pages for me: that's about 513MB. Of that, the
        object overhead is now just 56MB, the rest is going somewhere else (put
        another way: the fact that this patch shaves off 2.5% of the total
        memory overhead, considering that objects are now not much more than 10%
        of the total shows how big the wasted space really was: this makes
        object allocations much more memory- and time-efficient).
      
        I haven't looked at where the rest is, but I suspect the bulk of it is
        just the pack-file loading. It may be that we should pack the tree
        objects separately from the blob objects: for git-rev-list --objects, we
        don't actually ever need to even look at the blobs, but since trees and
        blobs are interspersed in the pack-file, we end up not being dense in
        the tree accesses, so we end up looking at more pages than we strictly
        need to.
      
        So with a 535MB pack-file, it's entirely possible - even likely - that
        most of the remaining RSS is just the mmap of the pack-file itself. We
        don't need to map in _all_ of it, but we do end up mapping a fair
        amount. ]
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      855419f7
  20. 19 6月, 2006 8 次提交
  21. 18 6月, 2006 1 次提交
  22. 11 6月, 2006 1 次提交
  23. 08 6月, 2006 1 次提交