Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 29 10月, 2014 1 次提交
  3. 28 10月, 2014 1 次提交
  5. 08 10月, 2014 5 次提交
  7. 30 9月, 2014 8 次提交
  9. 28 9月, 2014 1 次提交
  11. 26 9月, 2014 3 次提交
  13. 23 9月, 2014 1 次提交
  15. 20 9月, 2014 13 次提交
  17. 17 9月, 2014 2 次提交
    • S
      Documentation/git-rebase.txt: <upstream> must be given to specify <branch> · 95c68267
      由 Sergey Organov 提交于 
      Current syntax description makes one wonder if there is any
syntactic way to distinguish between <branch> and <upstream> so that
one can specify <branch> but not <upstream>, but that is not the
case.

Make it explicit that these arguments are positional, i.e. the
earlier ones cannot be omitted if you want to give later ones.
Signed-off-by: NSergey Organov <sorganov@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      95c68267
    • J
      mailinfo: make ">From" in-body header check more robust · 2da1f366
      由 Jeff King 提交于 
      Since commit 81c5cf78 (mailinfo: skip bogus UNIX From line inside
body, 2006-05-21), we have treated lines like ">From" in the body as
headers. This makes "git am" work for people who erroneously paste
the whole output from format-patch:

  From 12345abcd...fedcba543210 Mon Sep 17 00:00:00 2001
  From: them
  Subject: [PATCH] whatever

into their email body (assuming that an mbox writer then quotes
"From" as ">From", as otherwise we would actually mailsplit on the
in-body line).

However, this has false positives if somebody actually has a commit
body that starts with "From "; in this case we erroneously remove
the line entirely from the commit message. We can make this check
more robust by making sure the line actually looks like a real mbox
"From" line.

Inspect the line that begins with ">From " a more carefully to only
skip lines that match the expected pattern (note that the datestamp
part of the format-patch output is designed to be kept constant to
help those who write magic(5) entries).
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      2da1f366
  19. 13 9月, 2014 1 次提交
    • J
      fsck: return non-zero status on missing ref tips · 30d1038d
      由 Jeff King 提交于 
      Fsck tries hard to detect missing objects, and will complain
(and exit non-zero) about any inter-object links that are
missing. However, it will not exit non-zero for any missing
ref tips, meaning that a severely broken repository may
still pass "git fsck && echo ok".

The problem is that we use for_each_ref to iterate over the
ref tips, which hides broken tips. It does at least print an
error from the refs.c code, but fsck does not ever see the
ref and cannot note the problem in its exit code. We can solve
this by using for_each_rawref and noting the error ourselves.

In addition to adding tests for this case, we add tests for
all types of missing-object links (all of which worked, but
which we were not testing).
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      30d1038d
  21. 12 9月, 2014 1 次提交
  23. 11 9月, 2014 1 次提交
  25. 04 9月, 2014 1 次提交
  27. 30 8月, 2014 1 次提交
    • J
      index-pack: fix race condition with duplicate bases · ab791dd1
      由 Jeff King 提交于 
      When we are resolving deltas in an indexed pack, we do it by
first selecting a potential base (either one stored in full
in the pack, or one created by resolving another delta), and
then resolving any deltas that use that base.  When we
resolve a particular delta, we flip its "real_type" field
from OBJ_{REF,OFS}_DELTA to whatever the real type is.

We assume that traversing the objects this way will visit
each delta only once. This is correct for most packs; we
visit the delta only when we process its base, and each
object (and thus each base) appears only once. However, if a
base object appears multiple times in the pack, we will try
to resolve any deltas based on it once for each instance.

We can detect this case by noting that a delta we are about
to resolve has already had its real_type field flipped, and
we already do so with an assert().  However, if multiple
threads are in use, we may race with another thread on
comparing and flipping the field. We need to synchronize the
access.

The right mechanism for doing this is a compare-and-swap (we
atomically "claim" the delta for our own and find out
whether our claim was successful). We can implement this
in C by using a pthread mutex to protect the operation. This
is not the fastest way of doing a compare-and-swap; many
processors provide instructions for this, and gcc and other
compilers provide builtins to access them. However, some
experiments showed that lock contention does not cause a
significant slowdown here. Adding c-a-s support for many
compilers would increase the maintenance burden (and we
would still end up including the pthread version as a
fallback).

Note that we only need to touch the OBJ_REF_DELTA codepath
here. An OBJ_OFS_DELTA object points to its base using an
offset, and therefore has only one base, even if another
copy of that base object appears in the pack (we do still
touch it briefly because the setting of real_type is
factored out of resolve_data).
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ab791dd1