1. 23 Mar, 2012 1 commit
  2. 20 Mar, 2012 3 commits
  3. 06 Mar, 2012 2 commits
  4. 27 Feb, 2012 4 commits
  5. 26 Feb, 2012 1 commit
  6. 06 Feb, 2012 4 commits
  7. 22 Jan, 2012 1 commit
    • Kirill Smelkov's avatar
      t/Makefile: Use $(sort ...) explicitly where needed · aae5239b
      Kirill Smelkov authored
      Starting from GNU Make 3.82 $(wildcard ...) no longer sorts the result
      (from NEWS):
      
          * WARNING: Backward-incompatibility!
            Wildcards were not documented as returning sorted values, but the results
            have been sorted up until this release..  If your makefiles require sorted
            results from wildcard expansions, use the $(sort ...)  function to request
            it explicitly.
      
          http://repo.or.cz/w/make.git/commitdiff/2a59dc32aaf0681dec569f32a9d7ab88a379d34f
      
      I usually watch test progress visually, and if tests are sorted, even
      with make -j4 they go more or less incrementally by their t number. On
      the other side, without sorting, tests are executed in seemingly random
      order even for -j1. Let's please maintain sane tests order for perceived
      prettyness.
      
      Another note is that in GNU Make sort also works as uniq, so after sort
      being removed, we might expect e.g. $(wildcard *.sh a.*) to produce
      duplicates for e.g. "a.sh". From this point of view, adding sort could
      be seen as hardening t/Makefile from accidentally introduced dups.
      
      It turned out that prevous releases of GNU Make did not perform full
      sort in $(wildcard), only sorting results for each pattern, that's why
      explicit sort-as-uniq is relevant even for older makes.
      Signed-off-by: Kirill Smelkov's avatarKirill Smelkov <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      aae5239b
  8. 18 Jan, 2012 4 commits
  9. 13 Jan, 2012 6 commits
    • Junio C Hamano's avatar
      Update draft release notes to 1.7.8.4 · ab8a7808
      Junio C Hamano authored
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      ab8a7808
    • Junio C Hamano's avatar
      Merge branch 'maint-1.7.7' into maint · 5a6a9394
      Junio C Hamano authored
      * maint-1.7.7:
        Update draft release notes to 1.7.7.6
        Update draft release notes to 1.7.6.6
        thin-pack: try harder to use preferred base objects as base
      5a6a9394
    • Junio C Hamano's avatar
      Update draft release notes to 1.7.7.6 · 8f83acf7
      Junio C Hamano authored
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      8f83acf7
    • Junio C Hamano's avatar
      Merge branch 'maint-1.7.6' into maint-1.7.7 · 901c907d
      Junio C Hamano authored
      * maint-1.7.6:
        Update draft release notes to 1.7.6.6
        thin-pack: try harder to use preferred base objects as base
      901c907d
    • Junio C Hamano's avatar
      Update draft release notes to 1.7.6.6 · 04f6785a
      Junio C Hamano authored
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      04f6785a
    • Jeff King's avatar
      thin-pack: try harder to use preferred base objects as base · 15f07e06
      Jeff King authored
      When creating a pack using objects that reside in existing packs, we try
      to avoid recomputing futile delta between an object (trg) and a candidate
      for its base object (src) if they are stored in the same packfile, and trg
      is not recorded as a delta already. This heuristics makes sense because it
      is likely that we tried to express trg as a delta based on src but it did
      not produce a good delta when we created the existing pack.
      
      As the pack heuristics prefer producing delta to remove data, and Linus's
      law dictates that the size of a file grows over time, we tend to record
      the newest version of the file as inflated, and older ones as delta
      against it.
      
      When creating a thin-pack to transfer recent history, it is likely that we
      will try to send an object that is recorded in full, as it is newer.  But
      the heuristics to avoid recomputing futile delta effectively forbids us
      from attempting to express such an object as a delta based on another
      object. Sending an object in full is often more expensive than sending a
      suboptimal delta based on other objects, and it is even more so if we
      could use an object we know the receiving end already has (i.e. preferred
      base object) as the delta base.
      
      Tweak the recomputation avoidance logic, so that we do not punt on
      computing delta against a preferred base object.
      
      The effect of this change can be seen on two simulated upload-pack
      workloads. The first is based on 44 reflog entries from my git.git
      origin/master reflog, and represents the packs that kernel.org sent me git
      updates for the past month or two. The second workload represents much
      larger fetches, going from git's v1.0.0 tag to v1.1.0, then v1.1.0 to
      v1.2.0, and so on.
      
      The table below shows the average generated pack size and the average CPU
      time consumed for each dataset, both before and after the patch:
      
                        dataset
                  | reflog | tags
      ---------------------------------
           before | 53358  | 2750977
      size  after | 32398  | 2668479
           change |   -39% |      -3%
      ---------------------------------
           before |  0.18  | 1.12
      CPU   after |  0.18  | 1.15
           change |    +0% |      +3%
      
      This patch makes a much bigger difference for packs with a shorter slice
      of history (since its effect is seen at the boundaries of the pack) though
      it has some benefit even for larger packs.
      Signed-off-by: default avatarJeff King <[email protected]>
      Acked-by: Nicolas Pitre's avatarNicolas Pitre <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      15f07e06
  10. 12 Jan, 2012 3 commits
  11. 11 Jan, 2012 1 commit
  12. 10 Jan, 2012 10 commits