1. 02 9月, 2006 1 次提交
    • S
      Replace uses of strdup with xstrdup. · 9befac47
      Shawn Pearce 提交于
      Like xmalloc and xrealloc xstrdup dies with a useful message if
      the native strdup() implementation returns NULL rather than a
      valid pointer.
      
      I just tried to use xstrdup in new code and found it to be missing.
      However I expected it to be present as xmalloc and xrealloc are
      already commonly used throughout the code.
      
      [jc: removed the part that deals with last_XXX, which I am
       finding more and more dubious these days.]
      Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      9befac47
  2. 28 8月, 2006 1 次提交
  3. 24 8月, 2006 3 次提交
  4. 18 8月, 2006 1 次提交
  5. 16 8月, 2006 1 次提交
  6. 15 8月, 2006 1 次提交
  7. 10 8月, 2006 1 次提交
  8. 05 8月, 2006 1 次提交
  9. 29 7月, 2006 1 次提交
    • L
      Call setup_git_directory() early · db6296a5
      Linus Torvalds 提交于
      Any git command that expects to work in a subdirectory of a project, and
      that reads the git config files (which is just about all of them) needs to
      make sure that it does the "setup_git_directory()" call before it tries to
      read the config file.
      
      This means, among other things, that we need to move the call out of
      "init_revisions()", and into the caller.
      
      This does the mostly trivial conversion to do that.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      db6296a5
  10. 13 7月, 2006 1 次提交
  11. 04 7月, 2006 1 次提交
    • J
      Make zlib compression level configurable, and change default. · 12f6c308
      Joachim B Haga 提交于
      With the change in default, "git add ." on kernel dir is about
      twice as fast as before, with only minimal (0.5%) change in
      object size. The speed difference is even more noticeable
      when committing large files, which is now up to 8 times faster.
      
      The configurability is through setting core.compression = [-1..9]
      which maps to the zlib constants; -1 is the default, 0 is no
      compression, and 1..9 are various speed/size tradeoffs, 9
      being slowest.
      
      Signed-off-by: Joachim B Haga (cjhaga@fys.uio.no)
      Acked-by: NLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      12f6c308
  12. 28 6月, 2006 1 次提交
  13. 25 6月, 2006 1 次提交
  14. 20 6月, 2006 2 次提交
    • F
      Remove all void-pointer arithmetic. · 1d7f171c
      Florian Forster 提交于
      ANSI C99 doesn't allow void-pointer arithmetic. This patch fixes this in
      various ways. Usually the strategy that required the least changes was used.
      Signed-off-by: NFlorian Forster <octo@verplant.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      1d7f171c
    • L
      Add "named object array" concept · 1f1e895f
      Linus Torvalds 提交于
      We've had this notion of a "object_list" for a long time, which eventually
      grew a "name" member because some users (notably git-rev-list) wanted to
      name each object as it is generated.
      
      That object_list is great for some things, but it isn't all that wonderful
      for others, and the "name" member is generally not used by everybody.
      
      This patch splits the users of the object_list array up into two: the
      traditional list users, who want the list-like format, and who don't
      actually use or want the name. And another class of users that really used
      the list as an extensible array, and generally wanted to name the objects.
      
      The patch is fairly straightforward, but it's also biggish. Most of it
      really just cleans things up: switching the revision parsing and listing
      over to the array makes things like the builtin-diff usage much simpler
      (we now see exactly how many members the array has, and we don't get the
      objects reversed from the order they were on the command line).
      
      One of the main reasons for doing this at all is that the malloc overhead
      of the simple object list was actually pretty high, and the array is just
      a lot denser. So this patch brings down memory usage by git-rev-list by
      just under 3% (on top of all the other memory use optimizations) on the
      mozilla archive.
      
      It does add more lines than it removes, and more importantly, it adds a
      whole new infrastructure for maintaining lists of objects, but on the
      other hand, the new dynamic array code is pretty obvious. The change to
      builtin-diff-tree.c shows a fairly good example of why an array interface
      is sometimes more natural, and just much simpler for everybody.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      1f1e895f
  15. 19 6月, 2006 1 次提交
  16. 18 6月, 2006 1 次提交
    • L
      Shrink "struct object" a bit · 885a86ab
      Linus Torvalds 提交于
      This shrinks "struct object" by a small amount, by getting rid of the
      "struct type *" pointer and replacing it with a 3-bit bitfield instead.
      
      In addition, we merge the bitfields and the "flags" field, which
      incidentally should also remove a useless 4-byte padding from the object
      when in 64-bit mode.
      
      Now, our "struct object" is still too damn large, but it's now less
      obviously bloated, and of the remaining fields, only the "util" (which is
      not used by most things) is clearly something that should be eventually
      discarded.
      
      This shrinks the "git-rev-list --all" memory use by about 2.5% on the
      kernel archive (and, perhaps more importantly, on the larger mozilla
      archive). That may not sound like much, but I suspect it's more on a
      64-bit platform.
      
      There are other remaining inefficiencies (the parent lists, for example,
      probably have horrible malloc overhead), but this was pretty obvious.
      
      Most of the patch is just changing the comparison of the "type" pointer
      from one of the constant string pointers to the appropriate new TYPE_xxx
      small integer constant.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      885a86ab
  17. 17 6月, 2006 1 次提交
  18. 07 6月, 2006 2 次提交
  19. 31 5月, 2006 1 次提交
    • L
      tree_entry(): new tree-walking helper function · 4c068a98
      Linus Torvalds 提交于
      This adds a "tree_entry()" function that combines the common operation of
      doing a "tree_entry_extract()" + "update_tree_entry()".
      
      It also has a simplified calling convention, designed for simple loops
      that traverse over a whole tree: the arguments are pointers to the tree
      descriptor and a name_entry structure to fill in, and it returns a boolean
      "true" if there was an entry left to be gotten in the tree.
      
      This allows tree traversal with
      
      	struct tree_desc desc;
      	struct name_entry entry;
      
      	desc.buf = tree->buffer;
      	desc.size = tree->size;
      	while (tree_entry(&desc, &entry) {
      		... use "entry.{path, sha1, mode, pathlen}" ...
      	}
      
      which is not only shorter than writing it out in full, it's hopefully less
      error prone too.
      
      [ It's actually a tad faster too - we don't need to recalculate the entry
        pathlength in both extract and update, but need to do it only once.
        Also, some callers can avoid doing a "strlen()" on the result, since
        it's returned as part of the name_entry structure.
      
        However, by now we're talking just 1% speedup on "git-rev-list --objects
        --all", and we're definitely at the point where tree walking is no
        longer the issue any more. ]
      
      NOTE! Not everybody wants to use this new helper function, since some of
      the tree walkers very much on purpose do the descriptor update separately
      from the entry extraction. So the "extract + update" sequence still
      remains as the core sequence, this is just a simplified interface.
      
      We should probably add a silly two-line inline helper function for
      initializing the descriptor from the "struct tree" too, just to cut down
      on the noise from that common "desc" initializer.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      4c068a98
  20. 30 5月, 2006 2 次提交
  21. 29 5月, 2006 2 次提交
    • L
      Remove "tree->entries" tree-entry list from tree parser · 097dc3d8
      Linus Torvalds 提交于
      This finally removes the tree-entry list from "struct tree", since most of
      the users can just use the tree-walk infrastructure to walk the raw tree
      buffers instead of the tree-entry list.
      
      The tree-entry list is inefficient, and generates tons of small
      allocations for no good reason. The tree-walk infrastructure is generally
      no harder to use than following a linked list, and allows us to do most
      tree parsing in-place.
      
      Some programs still use the old tree-entry lists, and are a bit painful to
      convert without major surgery. For them we have a helper function that
      creates a temporary tree-entry list on demand. We can convert those too
      eventually, but with this they no longer affect any users who don't need
      the explicit lists.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      097dc3d8
    • L
      Make "tree_entry" have a SHA1 instead of a union of object pointers · a755dfe4
      Linus Torvalds 提交于
      This is preparatory work for further cleanups, where we try to make
      tree_entry look more like the more efficient tree-walk descriptor.
      
      Instead of having a union of pointers to blob/tree/objects, this just
      makes "struct tree_entry" have the raw SHA1, and makes all the users use
      that instead (often that implies adding a "lookup_tree(..)" on the sha1,
      but sometimes the user just wanted the SHA1 in the first place, and it
      just avoids an unnecessary indirection).
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      a755dfe4
  22. 17 4月, 2006 1 次提交
  23. 16 4月, 2006 1 次提交
    • J
      Split init_revisions() out of setup_revisions() · 6b9c58f4
      Junio C Hamano 提交于
      Merging all three option parsers related to whatchanged is
      unarguably the right thing, but the fallout was too big to scare
      me away.  Let's try it once again, but once step at time.
      
      This splits out init_revisions() call from setup_revisions(), so
      that the callers can set different defaults to match the
      traditional benaviour.
      
      The rev-list command is still broken in a big way, which is the
      topic of next step.
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      6b9c58f4
  24. 12 4月, 2006 1 次提交
  25. 11 4月, 2006 1 次提交
  26. 09 4月, 2006 1 次提交
    • L
      Make "--parents" logs also be incremental · 3381c790
      Linus Torvalds 提交于
      The parent rewriting feature caused us to create the whole history in one
      go, and then simplify it later, because of how rewrite_parents() had been
      written. However, with a little tweaking, it's perfectly possible to do
      even that one incrementally.
      
      Right now, this doesn't really much matter, because every user of
      "--parents" will probably generally _also_ use "--topo-order", which will
      cause the old non-incremental behaviour anyway. However, I'm hopeful that
      we could make even the topological sort incremental, or at least
      _partially_ so (for example, make it incremental up to the first merge).
      
      In the meantime, this at least moves things in the right direction, and
      removes a strange special case.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      3381c790
  27. 04 4月, 2006 1 次提交
  28. 03 4月, 2006 1 次提交
  29. 22 3月, 2006 1 次提交
  30. 21 3月, 2006 2 次提交
  31. 11 3月, 2006 3 次提交