1. 10 4月, 2018 3 次提交
    • J
      Merge branch 'ab/pcre-v2' · cac53513
      Junio C Hamano 提交于
      Git can be built to use either v1 or v2 of the PCRE library, and so
      far, the build-time configuration USE_LIBPCRE=YesPlease instructed
      the build procedure to use v1, but now it means v2.  USE_LIBPCRE1
      and USE_LIBPCRE2 can be used to explicitly choose which version to
      use, as before.
      
      * ab/pcre-v2:
        Makefile: make USE_LIBPCRE=YesPlease mean v2, not v1
        configure: detect redundant --with-libpcre & --with-libpcre1
        configure: fix a regression in PCRE v1 detection
      cac53513
    • J
      Merge branch 'ti/fetch-everything-local-optim' · 5d806b74
      Junio C Hamano 提交于
      A "git fetch" from a repository with insane number of refs into a
      repository that is already up-to-date still wasted too many cycles
      making many lstat(2) calls to see if these objects at the tips
      exist as loose objects locally.  These lstat(2) calls are optimized
      away by enumerating all loose objects beforehand.
      
      It is unknown if the new strategy negatively affects existing use
      cases, fetching into a repository with many loose objects from a
      repository with small number of refs.
      
      * ti/fetch-everything-local-optim:
        fetch-pack.c: use oidset to check existence of loose object
      5d806b74
    • J
      Merge branch 'en/rename-directory-detection' · e4bb62fa
      Junio C Hamano 提交于
      Rename detection logic in "diff" family that is used in "merge" has
      learned to guess when all of x/a, x/b and x/c have moved to z/a,
      z/b and z/c, it is likely that x/d added in the meantime would also
      want to move to z/d by taking the hint that the entire directory
      'x' moved to 'z'.  A bug causing dirty files involved in a rename
      to be overwritten during merge has also been fixed as part of this
      work.
      
      * en/rename-directory-detection: (29 commits)
        merge-recursive: ensure we write updates for directory-renamed file
        merge-recursive: avoid spurious rename/rename conflict from dir renames
        directory rename detection: new testcases showcasing a pair of bugs
        merge-recursive: fix remaining directory rename + dirty overwrite cases
        merge-recursive: fix overwriting dirty files involved in renames
        merge-recursive: avoid clobbering untracked files with directory renames
        merge-recursive: apply necessary modifications for directory renames
        merge-recursive: when comparing files, don't include trees
        merge-recursive: check for file level conflicts then get new name
        merge-recursive: add computation of collisions due to dir rename & merging
        merge-recursive: check for directory level conflicts
        merge-recursive: add get_directory_renames()
        merge-recursive: make a helper function for cleanup for handle_renames
        merge-recursive: split out code for determining diff_filepairs
        merge-recursive: make !o->detect_rename codepath more obvious
        merge-recursive: fix leaks of allocated renames and diff_filepairs
        merge-recursive: introduce new functions to handle rename logic
        merge-recursive: move the get_renames() function
        directory rename detection: tests for handling overwriting dirty files
        directory rename detection: tests for handling overwriting untracked files
        ...
      e4bb62fa
  2. 03 4月, 2018 3 次提交
    • J
      Git 2.17 · 468165c1
      Junio C Hamano 提交于
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      468165c1
    • J
      Merge tag 'l10n-2.17.0-rnd1' of git://github.com/git-l10n/git-po · 1614dd0f
      Junio C Hamano 提交于
      l10n for Git 2.17.0 round 1
      
      * tag 'l10n-2.17.0-rnd1' of git://github.com/git-l10n/git-po:
        l10n: de.po: translate 132 new messages
        l10n: zh_CN: review for git v2.17.0 l10n round 1
        l10n: zh_CN: for git v2.17.0 l10n round 1
        l10n: ko.po: Update Korean translation
        l10n: fr.po: v2.17.0 no fuzzy
        l10n: sv.po: Update Swedish translation (3376t0f0u)
        l10n: Update Catalan translation
        l10n: fr.po v2.17.0 round 1
        l10n: vi.po(3376t): Updated Vietnamese translation for v2.17
        l10n: bg.po: Updated Bulgarian translation (3376t)
        l10n: es.po: Update Spanish translation 2.17.0
        l10n: git.pot: v2.17.0 round 1 (132 new, 44 removed)
        l10n: es.po: fixes to Spanish translation
      1614dd0f
    • J
      Merge branch 'pw/add-p-single' · 5f944176
      Junio C Hamano 提交于
      Hotfix.
      
      * pw/add-p-single:
        add -p: fix 2.17.0-rc* regression due to moved code
      5f944176
  3. 01 4月, 2018 1 次提交
    • Æ
      add -p: fix 2.17.0-rc* regression due to moved code · fd2fb4aa
      Ævar Arnfjörð Bjarmason 提交于
      Fix a regression in 88f6ffc1 ("add -p: only bind search key if
      there's more than one hunk", 2018-02-13) which is present in
      2.17.0-rc*, but not 2.16.0.
      
      In Perl, regex variables like $1 always refer to the last regex
      match. When the aforementioned change added a new regex match between
      the old match and the corresponding code that was expecting $1, the $1
      variable would always be undef, since the newly inserted regex match
      doesn't have any captures.
      
      As a result the "/" feature to search for a string in a hunk by regex
      completely broke, on git.git:
      
          $ perl -pi -e 's/Git/Tig/g' README.md
          $ ./git --exec-path=$PWD add -p
          [..]
          Stage this hunk [y,n,q,a,d,j,J,g,/,s,e,?]? s
          Split into 4 hunks.
          [...]
          Stage this hunk [y,n,q,a,d,j,J,g,/,s,e,?]? /Many
          Use of uninitialized value $1 in string eq at /home/avar/g/git/git-add--interactive line 1568, <STDIN> line 1.
          search for regex? Many
      
      I.e. the initial "/regex" command wouldn't work, and would always emit
      a warning and ask again for a regex, now it works as intended again.
      Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      fd2fb4aa
  4. 31 3月, 2018 1 次提交
  5. 30 3月, 2018 2 次提交
    • J
      Merge branch 'jh/partial-clone' · c2a499e6
      Junio C Hamano 提交于
      Hotfix.
      
      * jh/partial-clone:
        upload-pack: disable object filtering when disabled by config
        unpack-trees: release oid_array after use in check_updates()
      c2a499e6
    • J
      upload-pack: disable object filtering when disabled by config · c7620bd0
      Jonathan Nieder 提交于
      When upload-pack gained partial clone support (v2.17.0-rc0~132^2~12,
      2017-12-08), it was guarded by the uploadpack.allowFilter config item
      to allow server operators to control when they start supporting it.
      
      That config item didn't go far enough, though: it controls whether the
      'filter' capability is advertised, but if a (custom) client ignores
      the capability advertisement and passes a filter specification anyway,
      the server would handle that despite allowFilter being false.
      
      This is particularly significant if a security bug is discovered in
      this new experimental partial clone code.  Installations without
      uploadpack.allowFilter ought not to be affected since they don't
      intend to support partial clone, but they would be swept up into being
      vulnerable.
      
      Simplify and limit the attack surface by making uploadpack.allowFilter
      disable the feature, not just the advertisement of it.
      Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c7620bd0
  6. 29 3月, 2018 6 次提交
  7. 28 3月, 2018 3 次提交
  8. 26 3月, 2018 1 次提交
  9. 25 3月, 2018 1 次提交
  10. 24 3月, 2018 2 次提交
  11. 23 3月, 2018 17 次提交