1. 21 Sep, 2018 5 commits
  2. 17 Sep, 2018 1 commit
  3. 10 Sep, 2018 4 commits
    • Junio C Hamano's avatar
      Git 2.19 · 1d4361b0
      Junio C Hamano authored
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      1d4361b0
    • Junio C Hamano's avatar
      Merge tag 'l10n-2.19.0-rnd2' of git://github.com/git-l10n/git-po · 46d9a284
      Junio C Hamano authored
      l10n for Git 2.19.0 round 2
      
      * tag 'l10n-2.19.0-rnd2' of git://github.com/git-l10n/git-po:
        l10n: zh_CN: for git v2.19.0 l10n round 1 to 2
        l10n: bg.po: Updated Bulgarian translation (3958t)
        l10n: vi.po(3958t): updated Vietnamese translation v2.19.0 round 2
        l10n: es.po v2.19.0 round 2
        l10n: fr.po v2.19.0 rnd 2
        l10n: fr.po v2.19.0 rnd 1
        l10n: fr: fix a message seen in git bisect
        l10n: sv.po: Update Swedish translation (3958t0f0u)
        l10n: git.pot: v2.19.0 round 2 (3 new, 5 removed)
        l10n: ru.po: update Russian translation
        l10n: git.pot: v2.19.0 round 1 (382 new, 30 removed)
        l10n: de.po: translate 108 new messages
        l10n: zh_CN: review for git 2.18.0
        l10n: sv.po: Update Swedish translation(3608t0f0u)
      46d9a284
    • Junio C Hamano's avatar
      Merge branch 'jn/submodule-core-worktree-revert' · f38a45b9
      Junio C Hamano authored
      * jn/submodule-core-worktree-revert:
        Revert "Merge branch 'sb/submodule-core-worktree'"
      f38a45b9
    • Junio C Hamano's avatar
      Merge branch 'mk/http-backend-content-length' · fe468eff
      Junio C Hamano authored
      The earlier attempt barfed when given a CONTENT_LENGTH that is
      set to an empty string.  RFC 3875 is fairly clear that in this
      case we should not read any message body, but we've been reading
      through to the EOF in previous versions (which did not even pay
      attention to the environment variable), so keep that behaviour for
      now in this late update.
      
      * mk/http-backend-content-length:
        http-backend: allow empty CONTENT_LENGTH
      fe468eff
  4. 09 Sep, 2018 3 commits
  5. 08 Sep, 2018 1 commit
    • Jonathan Nieder's avatar
      Revert "Merge branch 'sb/submodule-core-worktree'" · f178c13f
      Jonathan Nieder authored
      This reverts commit 7e25437d, reversing
      changes made to 00624d60.
      
      v2.19.0-rc0~165^2~1 (submodule: ensure core.worktree is set after
      update, 2018-06-18) assumes an "absorbed" submodule layout, where the
      submodule's Git directory is in the superproject's .git/modules/
      directory and .git in the submodule worktree is a .git file pointing
      there.  In particular, it uses $GIT_DIR/modules/$name to find the
      submodule to find out whether it already has core.worktree set, and it
      uses connect_work_tree_and_git_dir if not, resulting in
      
      	fatal: could not open sub/.git for writing
      
      The context behind that patch: v2.19.0-rc0~165^2~2 (submodule: unset
      core.worktree if no working tree is present, 2018-06-12) unsets
      core.worktree when running commands like "git checkout
      --recurse-submodules" to switch to a branch without the submodule.  If
      a user then uses "git checkout --no-recurse-submodules" to switch back
      to a branch with the submodule and runs "git submodule update", this
      patch is needed to ensure that commands using the submodule directly
      are aware of the path to the worktree.
      
      It is late in the release cycle, so revert the whole 3-patch series.
      We can try again later for 2.20.
      Reported-by: default avatarAllan Sandfeld Jensen <allan.jensen@qt.io>
      Helped-by: Stefan Beller's avatarStefan Beller <sbeller@google.com>
      Signed-off-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      f178c13f
  6. 07 Sep, 2018 2 commits
  7. 06 Sep, 2018 2 commits
  8. 05 Sep, 2018 3 commits
  9. 04 Sep, 2018 10 commits
    • Peter Krefting's avatar
    • Junio C Hamano's avatar
      Git 2.19-rc2 · c05048d4
      Junio C Hamano authored
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      c05048d4
    • Junio C Hamano's avatar
      Merge branch 'es/chain-lint-more' · e9983f89
      Junio C Hamano authored
      The test linter code has learned that the end of here-doc mark
      "EOF" can be quoted in a double-quote pair, not just in a
      single-quote pair.
      
      * es/chain-lint-more:
        chainlint: match "quoted" here-doc tags
      e9983f89
    • Junio C Hamano's avatar
      Merge branch 'ab/portable-more' · 28d294a5
      Junio C Hamano authored
      Portability fix.
      
      * ab/portable-more:
        tests: fix non-portable iconv invocation
        tests: fix non-portable "${var:-"str"}" construct
        tests: fix and add lint for non-portable grep --file
        tests: fix version-specific portability issue in Perl JSON
        tests: use shorter labels in chainlint.sed for AIX sed
        tests: fix comment syntax in chainlint.sed for AIX sed
        tests: fix and add lint for non-portable seq
        tests: fix and add lint for non-portable head -c N
      28d294a5
    • Junio C Hamano's avatar
      Merge branch 'es/freebsd-iconv-portability' · b571c25e
      Junio C Hamano authored
      Build fix.
      
      * es/freebsd-iconv-portability:
        config.mak.uname: resolve FreeBSD iconv-related compilation warning
      b571c25e
    • Junio C Hamano's avatar
      Merge branch 'ds/commit-graph-lockfile-fix' · 0a866db5
      Junio C Hamano authored
      "git merge-base" in 2.19-rc1 has performance regression when the
      (experimental) commit-graph feature is in use, which has been
      mitigated.
      
      * ds/commit-graph-lockfile-fix:
        commit: don't use generation numbers if not needed
      0a866db5
    • Junio C Hamano's avatar
      Merge branch 'en/directory-renames-nothanks' · ca676b9b
      Junio C Hamano authored
      Recent addition of "directory rename" heuristics to the
      merge-recursive backend makes the command susceptible to false
      positives and false negatives.  In the context of "git am -3",
      which does not know about surrounding unmodified paths and thus
      cannot inform the merge machinery about the full trees involved,
      this risk is particularly severe.  As such, the heuristic is
      disabled for "git am -3" to keep the machinery "more stupid but
      predictable".
      
      * en/directory-renames-nothanks:
        am: avoid directory rename detection when calling recursive merge machinery
        merge-recursive: add ability to turn off directory rename detection
        t3401: add another directory rename testcase for rebase and am
      ca676b9b
    • Junio C Hamano's avatar
      Merge branch 'pw/rebase-i-author-script-fix' · 064e0b2d
      Junio C Hamano authored
      Recent "git rebase -i" update started to write bogusly formatted
      author-script, with a matching broken reading code.  These are
      fixed.
      
      * pw/rebase-i-author-script-fix:
        sequencer: fix quoting in write_author_script
        sequencer: handle errors from read_author_ident()
      064e0b2d
    • Jiang Xin's avatar
      l10n: git.pot: v2.19.0 round 2 (3 new, 5 removed) · 98ac7815
      Jiang Xin authored
      Generate po/git.pot from v2.19.0-rc1 for git v2.19.0 l10n round 2.
      Signed-off-by: Jiang Xin's avatarJiang Xin <worldhello.net@gmail.com>
      98ac7815
    • Jiang Xin's avatar
      Merge branch 'master' of git://github.com/git-l10n/git-po · fb996aad
      Jiang Xin authored
      * 'master' of git://github.com/git-l10n/git-po:
        l10n: ru.po: update Russian translation
        l10n: git.pot: v2.19.0 round 1 (382 new, 30 removed)
        l10n: de.po: translate 108 new messages
        l10n: zh_CN: review for git 2.18.0
        l10n: sv.po: Update Swedish translation(3608t0f0u)
      fb996aad
  10. 31 Aug, 2018 1 commit
  11. 30 Aug, 2018 4 commits
    • Derrick Stolee's avatar
      commit: don't use generation numbers if not needed · 091f4cf3
      Derrick Stolee authored
      In 3afc679b "commit: use generations in paint_down_to_common()",
      the queue in paint_down_to_common() was changed to use a priority
      order based on generation number before commit date. This served
      two purposes:
      
       1. When generation numbers are present, the walk guarantees
          correct topological relationships, regardless of clock skew in
          commit dates.
      
       2. It enables short-circuiting the walk when the min_generation
          parameter is added in d7c1ec3e "commit: add short-circuit to
          paint_down_to_common()". This short-circuit helps commands
          like 'git branch --contains' from needing to walk to a merge
          base when we know the result is false.
      
      The commit message for 3afc679b includes the following sentence:
      
          This change does not affect the number of commits that are
          walked during the execution of paint_down_to_common(), only
          the order that those commits are inspected.
      
      This statement is incorrect. Because it changes the order in which
      the commits are inspected, it changes the order they are added to
      the queue, and hence can change the number of loops before the
      queue_has_nonstale() method returns true.
      
      This change makes a concrete difference depending on the topology
      of the commit graph. For instance, computing the merge-base between
      consecutive versions of the Linux kernel has no effect for versions
      after v4.9, but 'git merge-base v4.8 v4.9' presents a performance
      regression:
      
          v2.18.0: 0.122s
      v2.19.0-rc1: 0.547s
             HEAD: 0.127s
      
      To determine that this was simply an ordering issue, I inserted
      a counter within the while loop of paint_down_to_common() and
      found that the loop runs 167,468 times in v2.18.0 and 635,579
      times in v2.19.0-rc1.
      
      The topology of this case can be described in a simplified way
      here:
      
        v4.9
         |  \
         |   \
        v4.8  \
         | \   \
         |  \   |
        ...  A  B
         |  /  /
         | /  /
         |/__/
         C
      
      Here, the "..." means "a very long line of commits". By generation
      number, A and B have generation one more than C. However, A and B
      have commit date higher than most of the commits reachable from
      v4.8. When the walk reaches v4.8, we realize that it has PARENT1
      and PARENT2 flags, so everything it can reach is marked as STALE,
      including A. B has only the PARENT1 flag, so is not STALE.
      
      When paint_down_to_common() is run using
      compare_commits_by_commit_date, A and B are removed from the queue
      early and C is inserted into the queue. At this point, C and the
      rest of the queue entries are marked as STALE. The loop then
      terminates.
      
      When paint_down_to_common() is run using
      compare_commits_by_gen_then_commit_date, B is removed from the
      queue only after the many commits reachable from v4.8 are explored.
      This causes the loop to run longer. The reason for this regression
      is simple: the queue order is intended to not explore a commit
      until everything that _could_ reach that commit is explored. From
      the information gathered by the original ordering, we have no
      guarantee that there is not a commit D reachable from v4.8 that
      can also reach B. We gained absolute correctness in exchange for
      a performance regression.
      
      The performance regression is probably the worse option, since
      these incorrect results in paint_down_to_common() are rare. The
      topology required for the performance regression are less rare,
      but still require multiple merge commits where the parents differ
      greatly in generation number. In our example above, the commit A
      is as important as the commit B to demonstrate the problem, since
      otherwise the commit C will sit in the queue as non-stale just as
      long in both orders.
      
      The solution provided uses the min_generation parameter to decide
      if we should use generation numbers in our ordering. When
      min_generation is equal to zero, it means that the caller has no
      known cutoff for the walk, so we should rely on our commit-date
      heuristic as before; this is the case with merge_bases_many().
      When min_generation is non-zero, then the caller knows a valuable
      cutoff for the short-circuit mechanism; this is the case with
      remove_redundant() and in_merge_bases_many().
      Signed-off-by: Derrick Stolee's avatarDerrick Stolee <dstolee@microsoft.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      091f4cf3
    • Elijah Newren's avatar
      am: avoid directory rename detection when calling recursive merge machinery · 6aba117d
      Elijah Newren authored
      Let's say you have the following three trees, where Base is from one commit
      behind either master or branch:
      
         Base  : bar_v1, foo/{file1, file2, file3}
         branch: bar_v2, foo/{file1, file2},       goo/file3
         master: bar_v3, foo/{file1, file2, file3}
      
      Using git-am (or am-based rebase) to apply the changes from branch onto
      master results in the following tree:
      
         Result: bar_merged, goo/{file1, file2, file3}
      
      This is not what users want; they did not rename foo/ -> goo/, they only
      renamed one file within that directory.  The reason this happens is am
      constructs fake trees (via build_fake_ancestor()) of the following form:
      
         Base_bfa  : bar_v1, foo/file3
         branch_bfa: bar_v2, goo/file3
      
      Combining these two trees with master's tree:
      
         master: bar_v3, foo/{file1, file2, file3},
      
      You can see that merge_recursive_generic() would see branch_bfa as renaming
      foo/ -> goo/, and master as just adding both foo/file1 and foo/file2.  As
      such, it ends up with goo/{file1, file2, file3}
      
      The core problem is that am does not have access to the original trees; it
      can only construct trees using the blobs involved in the patch.  As such,
      it is not safe to perform directory rename detection within am -3.
      Signed-off-by: Elijah Newren's avatarElijah Newren <newren@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      6aba117d
    • Elijah Newren's avatar
    • Elijah Newren's avatar
      t3401: add another directory rename testcase for rebase and am · e7588c96
      Elijah Newren authored
      Similar to commit 16346883 ("t3401: add directory rename testcases for
      rebase and am", 2018-06-27), add another testcase for directory rename
      detection.  This new testcase differs in that it showcases a situation
      where no directory rename was performed, but which some backends
      incorrectly detect.
      
      As with the other testcase, run this in conjunction with each of the
      types of rebases:
        git-rebase--interactive
        git-rebase--am
        git-rebase--merge
      and also use the same testcase for
        git am --3way
      Reported-by: corristo's avatarNikolay Kasyanov <corrmage@gmail.com>
      Signed-off-by: Elijah Newren's avatarElijah Newren <newren@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      e7588c96
  12. 29 Aug, 2018 3 commits
  13. 28 Aug, 2018 1 commit