1. 30 6月, 2018 2 次提交
  2. 16 5月, 2018 1 次提交
  3. 14 7月, 2017 1 次提交
  4. 08 5月, 2017 1 次提交
  5. 27 4月, 2017 1 次提交
    • J
      timestamp_t: a new data type for timestamps · dddbad72
      Johannes Schindelin 提交于
      Git's source code assumes that unsigned long is at least as precise as
      time_t. Which is incorrect, and causes a lot of problems, in particular
      where unsigned long is only 32-bit (notably on Windows, even in 64-bit
      versions).
      
      So let's just use a more appropriate data type instead. In preparation
      for this, we introduce the new `timestamp_t` data type.
      
      By necessity, this is a very, very large patch, as it has to replace all
      timestamps' data type in one go.
      
      As we will use a data type that is not necessarily identical to `time_t`,
      we need to be very careful to use `time_t` whenever we interact with the
      system functions, and `timestamp_t` everywhere else.
      Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      dddbad72
  6. 23 4月, 2016 1 次提交
  7. 16 9月, 2014 1 次提交
    • J
      gpg-interface: move parse_signature() to where it should be · d7c67668
      Junio C Hamano 提交于
      Our signed-tag objects set the standard format used by Git to store
      GPG-signed payload (i.e. the payload followed by its detached
      signature) [*1*], and it made sense to have a helper to find the
      boundary between the payload and its signature in tag.c back then.
      
      Newer code added later to parse other kinds of objects that learned
      to use the same format to store GPG-signed payload (e.g. signed
      commits), however, kept using the helper from the same location.
      
      Move it to gpg-interface; the helper is no longer about signed tag,
      but it is how our code and data interact with GPG.
      
      [Reference]
      *1* http://thread.gmane.org/gmane.linux.kernel/297998/focus=1383Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      d7c67668
  8. 07 1月, 2012 1 次提交
    • J
      upload-pack: avoid parsing tag destinations · 90108a24
      Jeff King 提交于
      When upload-pack advertises refs, it dereferences any tags
      it sees, and shows the resulting sha1 to the client. It does
      this by calling deref_tag. That function must load and parse
      each tag object to find the sha1 of the tagged object.
      However, it also ends up parsing the tagged object itself,
      which is not strictly necessary for upload-pack's use.
      
      Each tag produces two object loads (assuming it is not a
      recursive tag), when it could get away with only a single
      one. Dropping the second load halves the effort we spend.
      
      The downside is that we are no longer verifying the
      resulting object by loading it. In particular:
      
        1. We never cross-check the "type" field given in the tag
           object with the type of the pointed-to object.  If the
           tag says it points to a tag but doesn't, then we will
           keep peeling and realize the error.  If the tag says it
           points to a non-tag but actually points to a tag, we
           will stop peeling and just advertise the pointed-to
           tag.
      
        2. If we are missing the pointed-to object, we will not
           realize (because we never even look it up in the object
           db).
      
      However, both of these are errors in the object database,
      and both will be detected if a client actually requests the
      broken objects in question. So we are simply pushing the
      verification away from the advertising stage, and down to
      the actual fetching stage.
      
      On my test repo with 120K refs, this drops the time to
      advertise the refs from ~3.2s to ~2.0s.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      90108a24
  9. 08 2月, 2011 1 次提交
  10. 11 11月, 2010 1 次提交
  11. 13 4月, 2010 2 次提交
  12. 03 11月, 2005 1 次提交
    • J
      Be careful when dereferencing tags. · 9534f40b
      Junio C Hamano 提交于
      One caller of deref_tag() was not careful enough to make sure
      what deref_tag() returned was not NULL (i.e. we found a tag
      object that points at an object we do not have).  Fix it, and
      warn about refs that point at such an incomplete tag where
      needed.
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      9534f40b
  13. 05 8月, 2005 1 次提交
    • J
      Fix send-pack for non-commitish tags. · 37fde874
      Junio C Hamano 提交于
      Again I left the v2.6.11-tree tag behind.  My bad.
      
      This commit makes sure that we do not barf when pushing a ref
      that is a non-commitish tag.  You can update a remote ref under
      the following conditions:
      
       * You can always use --force.
       * Creating a brand new ref is OK.
       * If the remote ref is exactly the same as what you are
         pushing, it is OK (nothing is pushed).
       * You can replace a commitish with another commitish which is a
         descendant of it, if you can verify the ancestry between them;
         this and the above means you have to have what you are replacing.
       * Otherwise you cannot update; you need to use --force.
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      37fde874
  14. 09 6月, 2005 1 次提交
  15. 07 5月, 2005 1 次提交
    • N
      [PATCH] don't load and decompress objects twice with parse_object() · bd2c39f5
      Nicolas Pitre 提交于
      It turns out that parse_object() is loading and decompressing given
      object to free it just before calling the specific object parsing
      function which does mmap and decompress the same object again. This
      patch introduces the ability to parse specific objects directly from a
      memory buffer.
      
      Without this patch, running git-fsck-cache on the kernel repositorytake:
      
      	real    0m13.006s
      	user    0m11.421s
      	sys     0m1.218s
      
      With this patch applied:
      
      	real    0m8.060s
      	user    0m7.071s
      	sys     0m0.710s
      
      The performance increase is significant, and this is kind of a
      prerequisite for sane delta object support with fsck.
      Signed-off-by: NNicolas Pitre <nico@cam.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      bd2c39f5
  16. 28 4月, 2005 2 次提交