Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 14 7月, 2015 1 次提交
    • J
      Merge branch 'jc/fsck-retire-require-eoh' · acf71895
      由 Junio C Hamano 提交于 
      A fix to a minor regression to "git fsck" in v2.2 era that started
complaining about a body-less tag object when it lacks a separator
empty line after its header to separate it with a non-existent body.

* jc/fsck-retire-require-eoh:
  fsck: it is OK for a tag and a commit to lack the body
      acf71895
  3. 11 7月, 2015 12 次提交
  5. 10 7月, 2015 2 次提交
  7. 09 7月, 2015 2 次提交
    • J
      check_and_freshen_file: fix reversed success-check · 3096b2ec
      由 Jeff King 提交于 
      When we want to write out a loose object file, we have
always first made sure we don't already have the object
somewhere. Since 33d4221c (write_sha1_file: freshen existing
objects, 2014-10-15), we also update the timestamp on the
file, so that a simultaneous prune knows somebody is
likely to reference it soon.

If our utime() call fails, we treat this the same as not
having the object in the first place; the safe thing to do
is write out another copy. However, the loose-object check
accidentally inverts the utime() check; it returns failure
_only_ when the utime() call actually succeeded. Thus it was
failing to protect us there, and in the normal case where
utime() succeeds, it caused us to pointlessly write out and
link the object.

This passed our freshening tests, because writing out the
new object is certainly _one_ way of updating its utime. So
the normal case was inefficient, but not wrong.

While we're here, let's also drop a comment in front of the
check_and_freshen functions, making a note of their return
type (since it is not our usual "0 for success, -1 for
error").
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      3096b2ec
    • C
      rebase: return non-zero error code if format-patch fails · 60d708b2
      由 Clemens Buchacher 提交于 
      Since e481af06 (rebase: Handle cases where format-patch fails) we
notice if format-patch fails and return immediately from
git-rebase--am. We save the return value with ret=$?, but then we
return $?, which is usually zero in this case.

Fix this by returning $ret instead.

Cc: Andrew Wong <andrew.kw.w@gmail.com>
Signed-off-by: NClemens Buchacher <clemens.buchacher@intel.com>
Helped-by: NJorge Nunes <jorge.nunes@intel.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      60d708b2
  9. 07 7月, 2015 3 次提交
  11. 05 7月, 2015 1 次提交
    • J
      index-pack: fix allocation of sorted_by_pos array · 781d9306
      由 Junio C Hamano 提交于 
      When c6458e60 (index-pack: kill union delta_base to save memory,
2015-04-18) attempted to reduce the memory footprint of index-pack,
one of the key thing it did was to keep track of ref-deltas and
ofs-deltas separately.

In fix_unresolved_deltas(), however it forgot that it now wants to
look only at ref deltas in one place.  The code allocated an array
for nr_unresolved, which is sum of number of ref- and ofs-deltas
minus nr_resolved, which may be larger or smaller than the number
ref-deltas.  Depending on nr_resolved, this was either under or over
allocating.

Also, the old code before this change had to use 'i' and 'n' because
some of the things we see in the (old) deltas[] array we scanned
with 'i' would not make it into the sorted_by_pos[] array in the old
world order, but now because you have only ref delta in a separate
ref_deltas[] array, they increment lock&step.  We no longer need
separate variables.  And most importantly, we shouldn't pass the
nr_unresolved parameter, as this number does not play a role in the
working of this helper function.
Helped-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      781d9306
  13. 02 7月, 2015 8 次提交
  15. 29 6月, 2015 2 次提交
    • J
      Sync with maint · 912bd497
      由 Junio C Hamano 提交于 
      * maint:
      912bd497
    • J
      fsck: it is OK for a tag and a commit to lack the body · 84d18c0b
      由 Junio C Hamano 提交于 
      When fsck validates a commit or a tag, it scans each line in the
header of the object using helper functions such as "start_with()",
etc. that work on a NUL terminated buffer, but before a1e920a0
(index-pack: terminate object buffers with NUL, 2014-12-08), the
validation functions were fed the object data in a piece of memory
that is not necessarily terminated with a NUL.

We added a helper function require_end_of_header() to be called at
the beginning of these validation functions to insist that the
object data contains an empty line before its end.  The theory is
that the validating functions will notice and stop when it hits an
empty line as a normal end of header (or a required header line that
is missing) without scanning past the end of potentially not
NUL-terminated buffer.

But the theory forgot that in the older days, Git itself happily
created objects with only the header lines without a body. This
caused Git 2.2 and later to issue an unnecessary warning in some
existing repositories.

With a1e920a0, we do not need to require an empty line (or the body)
in these objects to safely parse and validate them.  Drop the
offending "must have an empty line" check from this helper function,
while keeping the other check to make sure that there is no NUL in
the header part of the object, and adjust the name of the helper to
what it does accordingly.
Noticed-by: NWolfgang Denk <wd@denx.de>
Helped-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      84d18c0b
  17. 27 6月, 2015 1 次提交
  19. 26 6月, 2015 8 次提交