1. 06 2月, 2010 1 次提交
  2. 05 2月, 2010 5 次提交
  3. 04 2月, 2010 5 次提交
    • N
      make --max-pack-size argument to 'git pack-object' count in bytes · 07cf0f24
      Nicolas Pitre 提交于
      The value passed to --max-pack-size used to count in MiB which was
      inconsistent with the corresponding configuration variable as well as
      other command arguments which are defined to count in bytes with an
      optional unit suffix.  This brings --max-pack-size in line with the
      rest of Git.
      
      Also, in order not to cause havoc with people used to the previous
      megabyte scale, and because this is a sane thing to do anyway, a
      minimum size of 1 MiB is enforced to avoid an explosion of pack files.
      
      Adjust and extend test suite accordingly.
      Signed-off-by: NNicolas Pitre <nico@fluxnic.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      07cf0f24
    • N
      pack-objects: fix pack generation when using pack_size_limit · a2430dde
      Nicolas Pitre 提交于
      Current handling of pack_size_limit is quite suboptimal.  Let's consider
      a list of objects to pack which contain alternatively big and small
      objects (which pretty matches reality when big blobs are interlaced
      with tree objects).  Currently, the code simply close the pack and opens
      a new one when the next object in line breaks the size limit.
      
      The current code may degenerate into:
      
        - small tree object => store into pack #1
        - big blob object busting the pack size limit => store into pack #2
        - small blob but pack #2 is over the limit already => pack #3
        - big blob busting the size limit => pack #4
        - small tree but pack #4 is over the limit => pack #5
        - big blob => pack #6
        - small tree => pack #7
        - ... and so on.
      
      The reality is that the content of packs 1, 3, 5 and 7 could well be
      stored more efficiently (and delta compressed) together in pack #1 if
      the big blobs were not forcing an immediate transition to a new pack.
      
      Incidentally this can be fixed pretty easily by simply skipping over
      those objects that are too big to fit in the current pack while trying
      the whole list of unwritten objects, and then that list considered from
      the beginning again when a new pack is opened.  This creates much fewer
      smallish pack files and help making more predictable test cases for the
      test suite.
      
      This change made one of the self sanity checks useless so it is removed
      as well. That check was rather redundant already anyway.
      Signed-off-by: NNicolas Pitre <nico@fluxnic.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      a2430dde
    • N
      fix multiple issues with t5300 · 2fca19fb
      Nicolas Pitre 提交于
      First of all, trying to run 'git verify-pack' on packs  produced by
      the tests using pack.packSizeLimit always failed.  After lots of digging
      and head scratching, it turns out that the preceeding test simulating
      a SHA1 collision did leave the repository quite confused, impacting
      subsequent tests.
      
      So let's move that destructive test last, and add tests to run
      verify-pack on the output from those packSizeLimit tests to catch such
      goofage.
      
      Finally, group those packSizeLimit tests together.
      Signed-off-by: NNicolas Pitre <nico@fluxnic.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      2fca19fb
    • J
      gitweb: Simplify (and fix) chop_str · 57017b3e
      John 'Warthog9' Hawley 提交于
      The chop_str subroutine is meant to be used on strings (such as commit
      description / title) *before* HTML escaping, which means before
      applying esc_html or equivalent.
      
      Therefore get rid of the failed attempt to always remove full HTML
      entities (like e.g. &amp; or &nbsp;).  It is not necessary (HTML
      entities gets added later), and it can cause chop_str to chop a string
      incorrectly.
      
      Specifically:
      
           API & protocol: support option to force written data immediately to disk
      
      from http://git.kernel.org/?p=daemon/distsrv/chunkd.git;a=commit;h=3b02f749df2cb1288f345a689d85e7061f507e54
      
      The short version of the title gets chopped to
      
           API ...
      
      where it should be
      
           API & protocol: support option to force written data...
      Noticed-by: NJohn 'Warthog9' Hawley <warthog9@kernel.org>
      Signed-off-by: NJohn 'Warthog9' Hawley <warthog9@kernel.org>
      Signed-off-by: NJakub Narebski <jnareb@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      57017b3e
    • R
      grep: simplify assignment of ->fixed · 79286102
      René Scharfe 提交于
      After 885d211e, the value of the ->fixed pattern option only depends on
      the grep option of the same name.  Regex flags don't matter any more,
      because fixed mode and regex mode are strictly separated.  Thus we can
      simply copy the value from struct grep_opt to struct grep_pat, as we do
      already for ->word_regexp and ->ignore_case.
      Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      79286102
  4. 03 2月, 2010 5 次提交
  5. 02 2月, 2010 7 次提交
  6. 01 2月, 2010 7 次提交
  7. 31 1月, 2010 10 次提交