1. 28 Nov, 2012 1 commit
    • Jeff King's avatar
      fsck: warn about '.' and '..' in trees · 5d34a435
      Jeff King authored
      A tree with meta-paths like '.' or '..' does not work well
      with git; the index will refuse to load it or check it out
      to the filesystem (and even if we did not have that safety,
      it would look like we were overwriting an untracked
      directory). For the same reason, it is difficult to create
      such a tree with regular git.
      Let's warn about these dubious entries during fsck, just in
      case somebody has created a bogus tree (and this also lets
      us prevent them from propagating when transfer.fsckObjects
      is set).
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  2. 29 Jul, 2012 1 commit
    • Jeff King's avatar
      fsck: detect null sha1 in tree entries · c479d14a
      Jeff King authored
      Short of somebody happening to beat the 1 in 2^160 odds of
      actually generating content that hashes to the null sha1, we
      should never see this value in a tree entry. So let's have
      fsck warn if it it seen.
      As in the previous commit, we test both blob and submodule
      entries to future-proof the test suite against the
      implementation depending on connectivity to notice the
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  3. 30 Apr, 2012 1 commit
  4. 11 Aug, 2011 1 commit
    • Dmitry Ivankov's avatar
      fsck: improve committer/author check · 53f53cff
      Dmitry Ivankov authored
      fsck allows a name with > character in it like "name> <email>". Also for
      "name email>" fsck says "missing space before email".
      More precisely, it seeks for a first '<', checks that ' ' preceeds it.
      Then seeks to '<' or '>' and checks that it is the '>'. Missing space is
      reported if either '<' is not found or it's not preceeded with ' '.
      Change it to following. Seek to '<' or '>', check that it is '<' and is
      preceeded with ' '. Seek to '<' or '>' and check that it is '>'. So now
      "name> <email>" is rejected as "bad name". More strict name check is the
      only change in what is accepted.
      Report 'missing space' only if '<' is found and is not preceeded with a
      Signed-off-by: default avatarDmitry Ivankov <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  5. 26 May, 2011 1 commit
  6. 26 Feb, 2011 1 commit
  7. 28 May, 2010 1 commit
    • Jonathan Nieder's avatar
      fsck: fix bogus commit header check · 0adc6a3d
      Jonathan Nieder authored
      daae1922 (fsck: check ident lines in commit objects, 2010-04-24)
      taught fsck to expect commit objects to have the form
        tree <object name>
        author <valid ident string>
        committer <valid ident string>
        log message
      The check is overly strict: for example, it errors out with the
      message “expected blank line” for perfectly valid commits with an
      "encoding ISO-8859-1" line.
      Later it might make sense to teach fsck about the rest of the header
      and warn about unrecognized header lines, but for simplicity, let’s
      accept arbitrary trailing lines for now.
      Reported-by: tuncer's avatarTuncer Ayaz <[email protected]>
      Signed-off-by: default avatarJonathan Nieder <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  8. 01 May, 2010 1 commit
  9. 06 Jul, 2009 1 commit
  10. 08 Mar, 2009 1 commit
  11. 11 Nov, 2008 1 commit
  12. 12 Oct, 2008 1 commit
  13. 05 Mar, 2008 1 commit
    • Junio C Hamano's avatar
      fsck.c: fix bogus "empty tree" check · 79b1138e
      Junio C Hamano authored
      ba002f3b (builtin-fsck: move common object checking code to fsck.c) did
      more than what it claimed to.  Most notably, it wrongly made an empty tree
      object an error by pretending to only move code from fsck_tree() in
      builtin-fsck.c to fsck_tree() in fsck.c, but in fact adding a bogus check
      to barf on an empty tree.
      An empty tree object is _unusual_.  Recent porcelains try reasonably hard
      not to let the user create a commit that contains such a tree.  Perhaps
      warning about them in git-fsck may have some merit.
      Being unusual and being errorneous are two quite different things.  This
      is especially true now we seem to use the same fsck_$object() code in
      places other than git-fsck itself.  For example, receive-pack should not
      reject unusual objects, even if it would be a good idea to tighten it to
      reject incorrect ones.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  14. 26 Feb, 2008 3 commits
  15. 29 Jan, 2007 2 commits
  16. 22 Jan, 2007 1 commit
    • Linus Torvalds's avatar
      fsck-objects: refactor checking for connectivity · 18af29f2
      Linus Torvalds authored
      This separates the connectivity check into separate codepaths,
      one for reachable objects and the other for unreachable ones,
      while adding a lot of comments to explain what is going on.
      When checking an unreachable object, unlike a reachable one, we
      do not have to complain if it does not exist (we used to
      complain about a missing blob even when the only thing that
      references it is a tree that is dangling).  Also we do not have
      to check and complain about objects that are referenced by an
      unreachable object.
      This makes the messages from fsck-objects a lot less noisy and
      more useful.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  17. 11 Jan, 2007 1 commit
    • Linus Torvalds's avatar
      Better error messages for corrupt databases · 9130ac1e
      Linus Torvalds authored
      This fixes another problem that Andy's case showed: git-fsck-objects
      reports nonsensical results for corrupt objects.
      There were actually two independent and confusing problems:
       - when we had a zero-sized file and used map_sha1_file, mmap() would
         return EINVAL, and git-fsck-objects would report that as an insane and
         confusing error. I don't know when this was introduced, it might have
         been there forever.
       - when "parse_object()" returned NULL, fsck would say "object not found",
         which can be very confusing, since obviously the object might "exist",
         it's just unparseable because it's totally corrupt.
      So this just makes "xmmap()" return NULL for a zero-sized object (which is
      a valid thing pointer, exactly the same way "malloc()" can return NULL for
      a zero-sized allocation). That fixes the first problem (but we could have
      fixed it in the caller too - I don't personally much care whichever way it
      goes, but maybe somebody should check that the NO_MMAP case does
      something sane in this case too?).
      And the second problem is solved by just making the error message slightly
      clearer - the failure to parse an object may be because it's missing or
      corrupt, not necessarily because it's not "found".
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  18. 09 Jan, 2007 1 commit
    • Johannes Schindelin's avatar
      Sanitize for_each_reflog_ent() · 883d60fa
      Johannes Schindelin authored
      It used to ignore the return value of the helper function; now, it
      expects it to return 0, and stops iteration upon non-zero return
      values; this value is then passed on as the return value of
      Further, it makes no sense to force the parsing upon the helper
      functions; for_each_reflog_ent() now calls the helper function with
      old and new sha1, the email, the timestamp & timezone, and the message.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  19. 21 Dec, 2006 1 commit
  20. 20 Dec, 2006 1 commit
    • Junio C Hamano's avatar
      simplify inclusion of system header files. · 85023577
      Junio C Hamano authored
      This is a mechanical clean-up of the way *.c files include
      system header files.
       (1) sources under compat/, platform sha-1 implementations, and
           xdelta code are exempt from the following rules;
       (2) the first #include must be "git-compat-util.h" or one of
           our own header file that includes it first (e.g. config.h,
           builtin.h, pkt-line.h);
       (3) system headers that are included in "git-compat-util.h"
           need not be included in individual C source files.
       (4) "git-compat-util.h" does not have to include subsystem
           specific header files (e.g. expat.h).
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  21. 21 Sep, 2006 2 commits
    • Junio C Hamano's avatar
      Tell between packed, unpacked and symbolic refs. · 8da19775
      Junio C Hamano authored
      This adds a "int *flag" parameter to resolve_ref() and makes
      for_each_ref() family to call callback function with an extra
      "int flag" parameter.  They are used to give two bits of
      information (REF_ISSYMREF and REF_ISPACKED) about the ref.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Junio C Hamano's avatar
      Add callback data to for_each_ref() family. · cb5d709f
      Junio C Hamano authored
      This is a long overdue fix to the API for for_each_ref() family
      of functions.  It allows the callers to specify a callback data
      pointer, so that the caller does not have to use static
      variables to communicate with the callback funciton.
      The updated for_each_ref() family takes a function of type
      	int (*fn)(const char *, const unsigned char *, void *)
      and a void pointer as parameters, and calls the function with
      the name of the ref and its SHA-1 with the caller-supplied void
      pointer as parameters.
      The commit updates two callers, builtin-name-rev.c and
      builtin-pack-refs.c as an example.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  22. 18 Sep, 2006 1 commit
  23. 02 Sep, 2006 1 commit
    • Shawn Pearce's avatar
      Replace uses of strdup with xstrdup. · 9befac47
      Shawn Pearce authored
      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: default avatarShawn O. Pearce <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  24. 29 Aug, 2006 1 commit
    • Linus Torvalds's avatar
      git-fsck-objects: lacking default references should not be fatal · 071fa89e
      Linus Torvalds authored
      The comment added says it all: if we have lost all references in a git
      archive, git-fsck-objects should still work, so instead of dying it should
      just notify the user about that condition.
      This change was triggered by me just doing a "git-init-db" and then
      populating that empty git archive with a pack/index file to look at it.
      Having git-fsck-objects not work just because I didn't have any references
      handy was rather irritating, since part of the reason for running
      git-fsck-objects in the first place was to _find_ the missing references.
      However, "--unreachable" really doesn't make sense in that situation, and
      we want to turn it off to protect anybody who uses the old "git prune"
      shell-script (rather than the modern built-in). The old pruning script
      used to remove all objects that were reported as unreachable, and without
      any refs, that obviously means everything - not worth it.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  25. 23 Aug, 2006 1 commit
    • Shawn Pearce's avatar
      Convert memcpy(a,b,20) to hashcpy(a,b). · e702496e
      Shawn Pearce authored
      This abstracts away the size of the hash values when copying them
      from memory location to memory location, much as the introduction
      of hashcmp abstracted away hash value comparsion.
      A few call sites were using char* rather than unsigned char* so
      I added the cast rather than open hashcpy to be void*.  This is a
      reasonable tradeoff as most call sites already use unsigned char*
      and the existing hashcmp is also declared to be unsigned char*.
      [jc: Splitted the patch to "master" part, to be followed by a
       patch for merge-recursive.c which is not in "master" yet.
       Fixed the cast in the latter hunk to combine-diff.c which was
       wrong in the original.
       Also converted ones left-over in combine-diff.c, diff-lib.c and
       upload-pack.c ]
      Signed-off-by: default avatarShawn O. Pearce <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  26. 16 Aug, 2006 1 commit
  27. 15 Aug, 2006 2 commits
  28. 13 Jul, 2006 1 commit
  29. 30 Jun, 2006 1 commit
    • Linus Torvalds's avatar
      Abstract out accesses to object hash array · fc046a75
      Linus Torvalds authored
      There are a few special places where some programs accessed the object
      hash array directly, which bothered me because I wanted to play with some
      simple re-organizations.
      So this patch makes the object hash array data structures all entirely
      local to object.c, and the few users who wanted to look at it now get to
      use a function to query how many object index entries there can be, and to
      actually access the array.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  30. 18 Jun, 2006 2 commits
    • Linus Torvalds's avatar
      Remove "refs" field from "struct object" · 3e4339e6
      Linus Torvalds authored
      This shrinks "struct object" to the absolutely minimal size possible.
      It now contains /only/ the object flags and the SHA1 hash name of the
      The "refs" field, which is really needed only for fsck, is maintained in
      a separate hashed lookup-table, allowing all normal users to totally
      ignore it.
      This helps memory usage, although not as much as I hoped: it looks like
      the allocation overhead of malloc (and the alignment constraints in
      particular) means that while the structure size shrinks, the actual
      allocation overhead mostly does not.
      [ That said: memory usage is actually down, but not as much as it should
        be: I suspect just one of the object types actually ended up shrinking
        its effective allocation size.
        To get to the next level, we probably need specialized allocators that
        don't pad the allocation more than necessary. ]
      The separation makes for some code cleanup, though, and makes the ref
      tracking that fsck wants a clearly separate thing.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Linus Torvalds's avatar
      Shrink "struct object" a bit · 885a86ab
      Linus Torvalds authored
      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
      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: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  31. 30 May, 2006 4 commits