1. 03 Nov, 2006 1 commit
    • Nicolas Pitre's avatar
      improve fetch-pack's handling of kept packs · da093d37
      Nicolas Pitre authored
      Since functions in fetch-clone.c were only used from fetch-pack.c,
      its content has been merged with fetch-pack.c.  This allows for better
      coupling of features with much simpler implementations.
      
      One new thing is that the (abscence of) --thin also enforce it on
      index-pack now, such that index-pack will abort if a thin pack was
      _not_ asked for.
      
      The -k or --keep, when provided twice, now causes the fetched pack
      to be left as a kept pack just like receive-pack currently does.
      Eventually this will be used to close a race against concurrent
      repacking.
      Signed-off-by: default avatarNicolas Pitre <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      da093d37
  2. 27 Oct, 2006 1 commit
    • Nicolas Pitre's avatar
      enhance clone and fetch -k experience · d9c20ba1
      Nicolas Pitre authored
      Now that index-pack can be streamed with a pack, it is probably a good
      idea to use it directly instead of creating a temporary file and running
      index-pack afterwards.  This way index-pack can abort early whenever a
      corruption is encountered even if the pack has not been fully
      downloaded, it can display a progress percentage as it knows how much to
      expects, and it is a bit faster since the pack indexing is partially
      done as data is received. Using fetch -k doesn't need to disable thin
      pack generation on the remote end either.
      Signed-off-by: default avatarNicolas Pitre <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <jun[email protected]>
      d9c20ba1
  3. 27 Sep, 2006 1 commit
  4. 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]>
      8da19775
    • 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]>
      cb5d709f
  5. 13 Sep, 2006 1 commit
  6. 10 Sep, 2006 1 commit
  7. 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]>
      e702496e
  8. 16 Aug, 2006 1 commit
  9. 13 Jul, 2006 1 commit
  10. 21 Jun, 2006 1 commit
  11. 18 Jun, 2006 1 commit
    • 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
      discarded.
      
      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]>
      885a86ab
  12. 25 May, 2006 1 commit
    • Junio C Hamano's avatar
      fetch-pack: give up after getting too many "ack continue" · f061e5fd
      Junio C Hamano authored
      If your repository have more roots than the remote repository
      you ask an object for, the remote upload-pack keeps responding
      "ack continue" until it fills up its received-have buffer
      (currently 256 entries).  Usually this is not a problem because
      the requester stops traversing the ancestry chain from the commit
      it gets "ack continue" for, but this mechanism does not work as
      a roadblock when it traverses down the path to the root the
      other side does not have.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      f061e5fd
  13. 22 May, 2006 1 commit
  14. 20 Mar, 2006 1 commit
    • Junio C Hamano's avatar
      revamp git-clone. · dfeff66e
      Junio C Hamano authored
      This does two things.
      
       * A new flag --reference can be used to name a local repository
         that is to be used as an alternate.  This is in response to
         an inquiry by James Cloos in the message on the list
         <[email protected]>.
      
       * A new flag --use-separate-remote stops contaminating local
         branch namespace by upstream branch names.  The upstream
         branch heads are copied in .git/refs/remotes/ instead of
         .git/refs/heads/ and .git/remotes/origin file is set up to
         reflect this as well.  It requires to have fetch/pull update
         to understand .git/refs/remotes by Eric Wong to further
         update the repository cloned this way.
      
      For the former change, git-fetch-pack is taught a new flag --all
      to fetch from all the remote heads.  Nobody uses the git-clone-pack
      with this change, so we could deprecate the command, but removal
      of the command will be left to a separate round.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      dfeff66e
  15. 26 Feb, 2006 1 commit
  16. 20 Feb, 2006 1 commit
  17. 11 Feb, 2006 1 commit
    • Linus Torvalds's avatar
      Make "git clone" less of a deathly quiet experience · 5ee2ad65
      Linus Torvalds authored
      It used to be that "git-unpack-objects" would give nice percentages, but
      now that we don't unpack the initial clone pack any more, it doesn't. And
      I'd love to do that nice percentage view in the pack objects downloader
      too, but the thing doesn't even read the pack header, much less know how
      much it's going to get, so I was lazy and didn't.
      
      Instead, it at least prints out how much data it's gotten, and what the
      packing speed is. Which makes the user realize that it's actually doing
      something useful instead of sitting there silently (and if the recipient
      knows how large the final result is, he can at least make a guess about
      when it migt be done).
      
      So with this patch, I get something like this on my DSL line:
      
      	[[email protected] ~]$ time git clone master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6 clone-test
      	Packing 188543 objects
      	  48.398MB  (154 kB/s)
      
      where even the speed approximation seems to be roughtly correct (even
      though my algorithm is a truly stupid one, and only really gives "speed in
      the last half second or so").
      
      Anyway, _something_ like this is definitely needed. It could certainly be
      better (if it showed the same kind of thing that git-unpack-objects did,
      that would be much nicer, but would require parsing the object stream as
      it comes in). But this is  big step forward, I think.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      5ee2ad65
  18. 20 Jan, 2006 1 commit
  19. 18 Dec, 2005 2 commits
  20. 29 Nov, 2005 1 commit
  21. 06 Nov, 2005 1 commit
    • Junio C Hamano's avatar
      git-fetch: fail if specified refspec does not match remote. · 9e5d2b40
      Junio C Hamano authored
      'git-fetch remote no-such-ref' succeeded without fetching any
      ref from the remote.  Detect such case and report an error.
      
      Note that this makes 'git-fetch remote master master' to fail,
      because the remote branch 'master' matches the first refspec,
      and the second refspec is left unmatched, which is detected by
      the error checking logic.  This is somewhat unintuitive, but
      giving the same refspec more than once to git-fetch is useless
      in any case so it should not be much of a problem.  I'd accept a
      patch to change this if somebody cares enough, though.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      9e5d2b40
  22. 03 Nov, 2005 1 commit
  23. 29 Oct, 2005 3 commits
  24. 25 Oct, 2005 1 commit
  25. 24 Oct, 2005 2 commits
  26. 20 Oct, 2005 2 commits
  27. 19 Oct, 2005 5 commits
    • Johannes Schindelin's avatar
      [PATCH] Do not send "want" lines for complete objects · 0a8944dd
      Johannes Schindelin authored
      It was all good and well to check if all remote refs are complete (local
      refs or descendants thereof), but we can just as easily use the same
      information to avoid sending "want" lines just for the complete objects in
      the case that not all remote refs are complete (or their names differ).
      
      Also, git-fetch-pack does not have to ask for descendants of remote refs
      which are complete (for now, git-rev-list is told to ignore only the first
      parent). That change also eliminates a code path where a popen()ed handle
      was not pclose()ed.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      0a8944dd
    • Junio C Hamano's avatar
      Do not ask for objects known to be complete. · 49bb805e
      Junio C Hamano authored
      On top of optimization by Linus not to ask refs that already match, we
      can walk our refs and not issue "want" for things that are known to be
      reachable from them.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      49bb805e
    • Junio C Hamano's avatar
      Do not ask for objects known to be complete. · acfcb8df
      Junio C Hamano authored
      On top of optimization by Linus not to ask refs that already match, we
      can walk our refs and not issue "want" for things that are known to be
      reachable from them.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      acfcb8df
    • Linus Torvalds's avatar
      git-fetch-pack: avoid unnecessary zero packing · 844ac7f8
      Linus Torvalds authored
      If everything is up-to-date locally, we don't need to even ask for a
      pack-file from the remote, or try to unpack it.
      
      This is especially important for tags - since the pack-file common commit
      logic is based purely on the commit history, it will never be able to find
      a common tag, and will thus always end up re-fetching them.
      
      Especially notably, if the tag points to a non-commit (eg a tagged tree),
      the pack-file would be unnecessarily big, just because it cannot any most
      recent common point between commits for pruning.
      
      Short-circuiting the case where we already have that reference means that
      we avoid a lot of these in the common case.
      
      NOTE! This only matches remote ref names against the same local name,
      which works well for tags, but is not as generic as it could be. If we
      ever need to, we could match against _any_ local ref (if we have it, we
      have it), but this "match against same name" is simpler and more
      efficient, and covers the common case.
      
      Renaming of refs is common for branch heads, but since those are always
      commits, the pack-file generation can optimize that case.
      
      In some cases we might still end up fetching pack-files unnecessarily, but
      this at least avoids the re-fetching of tags over and over if you use a
      regular
      
      	git fetch --tags ...
      
      which was the main reason behind the change.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      844ac7f8
    • Junio C Hamano's avatar
      Do not ask for objects known to be complete. · ea5a65a5
      Junio C Hamano authored
      On top of optimization by Linus not to ask refs that already match, we
      can walk our refs and not issue "want" for things that are known to be
      reachable from them.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      ea5a65a5
  28. 18 Oct, 2005 1 commit
    • Linus Torvalds's avatar
      git-fetch-pack: avoid unnecessary zero packing · 2759cbc7
      Linus Torvalds authored
      If everything is up-to-date locally, we don't need to even ask for a
      pack-file from the remote, or try to unpack it.
      
      This is especially important for tags - since the pack-file common commit
      logic is based purely on the commit history, it will never be able to find
      a common tag, and will thus always end up re-fetching them.
      
      Especially notably, if the tag points to a non-commit (eg a tagged tree),
      the pack-file would be unnecessarily big, just because it cannot any most
      recent common point between commits for pruning.
      
      Short-circuiting the case where we already have that reference means that
      we avoid a lot of these in the common case.
      
      NOTE! This only matches remote ref names against the same local name,
      which works well for tags, but is not as generic as it could be. If we
      ever need to, we could match against _any_ local ref (if we have it, we
      have it), but this "match against same name" is simpler and more
      efficient, and covers the common case.
      
      Renaming of refs is common for branch heads, but since those are always
      commits, the pack-file generation can optimize that case.
      
      In some cases we might still end up fetching pack-files unnecessarily, but
      this at least avoids the re-fetching of tags over and over if you use a
      regular
      
      	git fetch --tags ...
      
      which was the main reason behind the change.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      2759cbc7
  29. 16 Oct, 2005 1 commit
  30. 15 Oct, 2005 1 commit