Skip to content
Commits on Aug 27, 2012
  1. @gitster

    Merge branch 'jk/maint-null-in-trees'

    gitster committed Aug 27, 2012
    We do not want a link to 0{40} object stored anywhere in our objects.
    * jk/maint-null-in-trees:
      fsck: detect null sha1 in tree entries
      do not write null sha1s to on-disk index
      diff: do not use null sha1 as a sentinel value
Commits on May 30, 2011
  1. @gitster

    Merge branch 'jm/maint-misc-fix' into maint

    gitster committed May 30, 2011
    * jm/maint-misc-fix:
      read_gitfile_gently: use ssize_t to hold read result
      remove tests of always-false condition
      rerere.c: diagnose a corrupt MERGE_RR when hitting EOF between TAB and '\0'
Commits on Nov 11, 2008
  1. @gitster

    Merge branch 'maint'

    gitster committed Nov 11, 2008
    * maint:
      Fix non-literal format in printf-style calls
      git-submodule: Avoid printing a spurious message.
      git ls-remote: make usage string match manpage
      Makefile: help people who run 'make check' by mistake
Commits on Mar 5, 2008
  1. @gitster

    fsck.c: fix bogus "empty tree" check

    gitster committed Mar 4, 2008
    ba002f3 (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: Junio C Hamano <>
Something went wrong with that request. Please try again.