1. 29 1月, 2007 1 次提交
  2. 28 1月, 2007 1 次提交
    • J
      Don't force everybody to call setup_ident(). · 01754769
      Junio C Hamano 提交于
      Back when only handful commands that created commit and tag were
      the only users of committer identity information, it made sense
      to explicitly call setup_ident() to pre-fill the default value
      from the gecos information.  But it is much simpler for programs
      to make the call automatic when get_ident() is called these days,
      since many more programs want to use the information when updating
      the reflog.
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      01754769
  3. 10 1月, 2007 1 次提交
    • S
      Don't die in git-http-fetch when fetching packs. · 1c23d794
      Shawn O. Pearce 提交于
      My sp/mmap changes to pack-check.c modified the function such that
      it expects packed_git.pack_size to be populated with the total
      bytecount of the packfile by the caller.
      
      But that isn't the case for packs obtained by git-http-fetch as
      pack_size was not initialized before being accessed.  This caused
      verify_pack to think it had 2^32-21 bytes available when the
      downloaded pack perhaps was only 305 bytes in length.  The use_pack
      function then later dies with "offset beyond end of packfile"
      when computing the overall file checksum.
      Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      1c23d794
  4. 09 1月, 2007 2 次提交
  5. 09 10月, 2006 1 次提交
    • J
      Add WEBDAV timeout to http-fetch. · adc446fe
      Junio C Hamano 提交于
      Sean <seanlkml@sympatico.ca> writes:
      
      > On Sat, 07 Oct 2006 21:52:02 -0700
      > Junio C Hamano <junkio@cox.net> wrote:
      >
      >> Using DAV, if it works with the server, has the advantage of not
      >> having to keep objects/info/packs up-to-date from repository
      >> owner's point of view.  But the repository owner ends up keeping
      >> up-to-date as a side effect of keeping info/refs up-to-date
      >> anyway (as I do not see a code to read that information over
      >> DAV), so there is no point doing this over DAV in practice.
      >>
      >> Perhaps we should remove call to remote_ls() from
      >> fetch_indices() unconditionally, not just protected with
      >> NO_EXPAT and be done with it?
      >
      > That makes a lot of sense.  A server really has to always provide
      > a objects/info/packs anyway, just to be fetchable today by clients
      > that are compiled with NO_EXPAT.
      
      And even for an isolated group where everybody knows that
      everybody else runs DAV-enabled clients, they need info/refs
      prepared for ls-remote and git-fetch script, which means you
      will run update-server-info to keep objects/info/packs up to
      date.
      
      Nick, do you see holes in my logic?
      
      -- >8 --
      http-fetch.c: drop remote_ls()
      
      While doing remote_ls() over DAV potentially allows the server
      side not to keep objects/info/pack up-to-date, misconfigured or
      buggy servers can silently ignore or not to respond to DAV
      requests and makes the client hang.
      
      The server side (unfortunately) needs to run git-update-server-info
      even if remote_ls() removes the need to keep objects/info/pack file
      up-to-date, because the caller of git-http-fetch (git-fetch) and other
      clients that interact with the repository (e.g. git-ls-remote) need to
      read from info/refs file (there is no code to make that unnecessary by
      using DAV yet).
      
      Perhaps the right solution in the longer-term is to make info/refs
      also unnecessary by using DAV, and we would want to resurrect the
      code this patch removes when we do so, but let's drop remote_ls()
      implementation for now.  It is causing problems without really
      helping anything yet.
      
      git will keep it for us until we need it next time.
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      adc446fe
  6. 17 9月, 2006 2 次提交
  7. 13 9月, 2006 2 次提交
    • J
      http-fetch: fix alternates handling. · 883653ba
      Junio C Hamano 提交于
      Fetch over http from a repository that uses alternates to borrow
      from neighbouring repositories were quite broken, apparently for
      some time now.
      
      We parse input and count bytes to allocate the new buffer, and
      when we copy into that buffer we know exactly how many bytes we
      want to copy from where.  Using strlcpy for it was simply
      stupid, and the code forgot to take it into account that strlcpy
      terminated the string with NUL.
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      883653ba
    • J
      http-fetch: fix alternates handling. · 5df1e0d0
      Junio C Hamano 提交于
      Fetch over http from a repository that uses alternates to borrow
      from neighbouring repositories were quite broken, apparently for
      some time now.
      
      We parse input and count bytes to allocate the new buffer, and
      when we copy into that buffer we know exactly how many bytes we
      want to copy from where.  Using strlcpy for it was simply
      stupid, and the code forgot to take it into account that strlcpy
      terminated the string with NUL.
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      5df1e0d0
  8. 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
  9. 28 8月, 2006 1 次提交
  10. 24 8月, 2006 1 次提交
    • S
      Convert memcpy(a,b,20) to hashcpy(a,b). · e702496e
      Shawn Pearce 提交于
      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: NShawn O. Pearce <spearce@spearce.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      e702496e
  11. 18 8月, 2006 1 次提交
  12. 16 8月, 2006 1 次提交
  13. 12 8月, 2006 1 次提交
    • R
      drop length argument of has_extension · 5bb1cda5
      Rene Scharfe 提交于
      As Fredrik points out the current interface of has_extension() is
      potentially confusing.  Its parameters include both a nul-terminated
      string and a length-limited string.
      
      This patch drops the length argument, requiring two nul-terminated
      strings; all callsites are updated.  I checked that all of them indeed
      provide nul-terminated strings.  Filenames need to be nul-terminated
      anyway if they are to be passed to open() etc.  The performance penalty
      of the additional strlen() is negligible compared to the system calls
      which inevitably surround has_extension() calls.
      
      Additionally, change has_extension() to use size_t inside instead of
      int, as that is the exact type strlen() returns and memcmp() expects.
      Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      5bb1cda5
  14. 11 8月, 2006 1 次提交
  15. 06 8月, 2006 1 次提交
  16. 28 7月, 2006 4 次提交
  17. 10 7月, 2006 1 次提交
  18. 25 6月, 2006 1 次提交
  19. 20 6月, 2006 1 次提交
  20. 19 6月, 2006 1 次提交
  21. 17 6月, 2006 1 次提交
  22. 07 6月, 2006 1 次提交
  23. 23 5月, 2006 1 次提交
  24. 20 5月, 2006 1 次提交
  25. 12 4月, 2006 1 次提交
  26. 05 4月, 2006 1 次提交
  27. 21 3月, 2006 1 次提交
    • J
      http-fetch: nicer warning for a server with unreliable 404 status · bb528079
      Junio C Hamano 提交于
      When a repository otherwise properly prepared is served by a
      dumb HTTP server that sends "No such page" output with 200
      status for human consumption to a request for a page that does
      not exist, the users will get an alarming "File X corrupt" error
      message.  Hint that they might be dealing with such a server at
      the end and suggest running fsck-objects to check if the result
      is OK (the pack-fallback code does the right thing in this case
      so unless a loose object file was actually corrupt the result
      should check OK).
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      bb528079
  28. 16 3月, 2006 1 次提交
  29. 23 2月, 2006 1 次提交
  30. 07 2月, 2006 1 次提交
  31. 06 2月, 2006 3 次提交
  32. 03 2月, 2006 1 次提交