1. 10 5月, 2014 2 次提交
  2. 09 5月, 2014 10 次提交
  3. 08 5月, 2014 3 次提交
  4. 07 5月, 2014 2 次提交
  5. 03 5月, 2014 5 次提交
  6. 01 5月, 2014 2 次提交
    • J
      Merge git://github.com/git-l10n/git-po · 7e76a2f9
      Junio C Hamano 提交于
      * git://github.com/git-l10n/git-po:
        l10n: de.po: improve hint for autocorrected command execution
        l10n: de.po: translate 45 new messages
        l10n: de.po: correct translation of "completed" after resolving deltas
        l10n: zh_CN.po: translate 46 new messages (2229t0f0u)
        l10n: fr translation for v2.0.0rc0 (2228t)
        l10n: Update Swedish translation (2228t0f0u)
        l10n: vi.po (2228t): Update and minor fix
        l10n: git.pot: v2.0.0 round 1 (45 new, 28 removed)
      7e76a2f9
    • J
      Revert the whole "ask curl-config" topic for now · b2feb643
      Junio C Hamano 提交于
      Postpone this a bit during the feature freeze and retry the effort
      in the next cycle.
      b2feb643
  7. 29 4月, 2014 6 次提交
  8. 26 4月, 2014 1 次提交
  9. 25 4月, 2014 4 次提交
    • M
      setup: fix windows path buffer over-stepping · 6127ff63
      Martin Erik Werner 提交于
      Fix a buffer over-stepping issue triggered by providing an absolute path
      that is similar to the work tree path.
      
      abspath_part_inside_repo() may currently increment the path pointer by
      offset_1st_component() + wtlen, which is too much, since
      offset_1st_component() is a subset of wtlen.
      
      For the *nix-style prefix '/', this does (by luck) not cause any issues,
      since offset_1st_component() is 1 and there will always be a '/' or '\0'
      that can "absorb" this.
      
      In the case of DOS-style prefixes though, the offset_1st_component() is
      3 and this can potentially over-step the string buffer. For example if
      
          work_tree = "c:/r"
          path      = "c:/rl"
      
      Then wtlen is 4, and incrementing the path pointer by (3 + 4) would
      end up 2 bytes outside a string buffer of length 6.
      
      Similarly if
      
          work_tree = "c:/r"
          path      = "c:/rl/d/a"
      
      Then (since the loop starts by also incrementing the pointer one step),
      this would mean that the function would miss checking if "c:/rl/d" could
      be the work_tree, arguably this is unlikely though, since it would only
      be possible with symlinks on windows.
      
      Fix this by simply avoiding to increment by offset_1st_component() and
      wtlen at the same time.
      Signed-off-by: NMartin Erik Werner <martinerikwerner@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      6127ff63
    • J
      Merge branch 'jk/pack-bitmap' · 1697bf30
      Junio C Hamano 提交于
      A last minute (and hopefully the last) fix to avoid coredumps due
      to an incorrect pointer arithmetic.
      
      * jk/pack-bitmap:
        ewah_bitmap.c: do not assume size_t and eword_t are the same size
      1697bf30
    • J
      Merge branch 'fc/transport-helper-sync-error-fix' · d508e4a8
      Junio C Hamano 提交于
      Make sure the marks are not written out when the transport helper
      did not finish happily, to avoid leaving a marks file that is out of
      sync with the reality.
      
      * fc/transport-helper-sync-error-fix:
        t5801 (remote-helpers): cleanup environment sets
        transport-helper: fix sync issue on crashes
        transport-helper: trivial cleanup
        transport-helper: propagate recvline() error pushing
        remote-helpers: make recvline return an error
        transport-helper: remove barely used xchgline()
      d508e4a8
    • J
      Merge branch 'db/make-with-curl' · e4255213
      Junio C Hamano 提交于
      Ask curl-config how to link with the curl library, instead of
      having only a limited configurability knobs in the Makefile.
      
      * db/make-with-curl:
        Makefile: allow static linking against libcurl
        Makefile: use curl-config to determine curl flags
      e4255213
  10. 24 4月, 2014 1 次提交
  11. 23 4月, 2014 4 次提交