Skip to content

G
git

李少辉-开发者 / git
与 Fork 源项目一致

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 22 9月, 2018 10 次提交
  3. 18 9月, 2018 1 次提交
  5. 11 9月, 2018 4 次提交
    • J
      Git 2.19 · 1d4361b0
      由 Junio C Hamano 提交于 
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      1d4361b0
    • J
      Merge tag 'l10n-2.19.0-rnd2' of git://github.com/git-l10n/git-po · 46d9a284
      由 Junio C Hamano 提交于 
      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
    • J
      Merge branch 'jn/submodule-core-worktree-revert' · f38a45b9
      由 Junio C Hamano 提交于 
      * jn/submodule-core-worktree-revert:
  Revert "Merge branch 'sb/submodule-core-worktree'"
      f38a45b9
    • J
      Merge branch 'mk/http-backend-content-length' · fe468eff
      由 Junio C Hamano 提交于 
      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
  7. 09 9月, 2018 3 次提交
  9. 08 9月, 2018 2 次提交
    • J
      Revert "Merge branch 'sb/submodule-core-worktree'" · f178c13f
      由 Jonathan Nieder 提交于 
      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: NAllan Sandfeld Jensen <allan.jensen@qt.io>
Helped-by: NStefan Beller <sbeller@google.com>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      f178c13f
    • M
      http-backend: allow empty CONTENT_LENGTH · 574c513e
      由 Max Kirillov 提交于 
      According to RFC3875, empty environment variable is equivalent to unset,
and for CONTENT_LENGTH it should mean zero body to read.

However, unset CONTENT_LENGTH is also used for chunked encoding to indicate
reading until EOF. At least, the test "large fetch-pack requests can be split
across POSTs" from t5551 starts faliing, if unset or empty CONTENT_LENGTH is
treated as zero length body. So keep the existing behavior as much as possible.

Add a test for the case.
Reported-By: NJelmer Vernooij <jelmer@jelmer.uk>
Signed-off-by: NMax Kirillov <max@max630.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      574c513e
  11. 07 9月, 2018 1 次提交
  13. 06 9月, 2018 5 次提交
  15. 05 9月, 2018 8 次提交
    • P
      l10n: sv.po: Update Swedish translation (3958t0f0u) · bc25f7ae
      由 Peter Krefting 提交于 
      Signed-off-by: NPeter Krefting <peter@softwolves.pp.se>
      bc25f7ae
    • J
      Git 2.19-rc2 · c05048d4
      由 Junio C Hamano 提交于 
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c05048d4
    • J
      Merge branch 'es/chain-lint-more' · e9983f89
      由 Junio C Hamano 提交于 
      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
    • J
      Merge branch 'ab/portable-more' · 28d294a5
      由 Junio C Hamano 提交于 
      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
    • J
      Merge branch 'es/freebsd-iconv-portability' · b571c25e
      由 Junio C Hamano 提交于 
      Build fix.

* es/freebsd-iconv-portability:
  config.mak.uname: resolve FreeBSD iconv-related compilation warning
      b571c25e
    • J
      Merge branch 'ds/commit-graph-lockfile-fix' · 0a866db5
      由 Junio C Hamano 提交于 
      "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
    • J
      Merge branch 'en/directory-renames-nothanks' · ca676b9b
      由 Junio C Hamano 提交于 
      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
    • J
      Merge branch 'pw/rebase-i-author-script-fix' · 064e0b2d
      由 Junio C Hamano 提交于 
      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
  17. 04 9月, 2018 2 次提交
  19. 01 9月, 2018 1 次提交
  21. 31 8月, 2018 1 次提交
    • D
      commit: don't use generation numbers if not needed · 091f4cf3
      由 Derrick Stolee 提交于 
      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: NDerrick Stolee <dstolee@microsoft.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      091f4cf3
  23. 30 8月, 2018 2 次提交
    • E
      am: avoid directory rename detection when calling recursive merge machinery · 6aba117d
      由 Elijah Newren 提交于 
      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: NElijah Newren <newren@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      6aba117d
    • E
      merge-recursive: add ability to turn off directory rename detection · 5fdddd9b
      由 Elijah Newren 提交于 
      Signed-off-by: NElijah Newren <newren@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      5fdddd9b