Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 06 3月, 2015 12 次提交
  3. 25 2月, 2015 14 次提交
  5. 19 2月, 2015 1 次提交
  7. 16 2月, 2015 1 次提交
  9. 14 2月, 2015 2 次提交
  11. 13 2月, 2015 1 次提交
  13. 06 2月, 2015 4 次提交
    • J
      Git 2.3 · 9874fca7
      由 Junio C Hamano 提交于 
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      9874fca7
    • J
      config_buf_ungetc: warn when pushing back a random character · 1d0655c1
      由 Jeff King 提交于 
      Our config code simulates a stdio stream around a buffer,
but our fake ungetc() does not behave quite like the real
one. In particular, we only rewind the position by one
character, but do _not_ actually put the character from the
caller into position.

It turns out that this does not matter, because we only ever
push back the character we just read. In other words, such
an assignment would be a noop. But because the function is
called ungetc, and because it takes a character parameter,
it is a mistake waiting to happen.

Actually assigning the character into the buffer would be
ideal, but our pointer is actually a "const" copy of the
buffer. We do not know who the real owner of the buffer is
in this code, and would not want to munge their contents.

Instead, we can simply add an assertion that matches what
the current caller does, and will let us know if new callers
are added that violate the contract.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      1d0655c1
    • J
      decimal_width: avoid integer overflow · d306f3d3
      由 Jeff King 提交于 
      The decimal_width function originally appeared in blame.c as
"lineno_width", and was designed for calculating the
print-width of small-ish integer values (line numbers in
text files). In ec7ff5ba, it was made into a reusable
function, and in dc801e71, we started using it to align
diffstats.

Binary files in a diffstat show byte counts rather than line
numbers, meaning they can be quite large (e.g., consider
adding or removing a 2GB file). decimal_width is not up to
the challenge for two reasons:

  1. It takes the value as an "int", whereas large files may
     easily surpass this. The value may be truncated, in
     which case we will produce an incorrect value.

  2. It counts "up" by repeatedly multiplying another
     integer by 10 until it surpasses the value.  This can
     cause an infinite loop when the value is close to the
     largest representable integer.

     For example, consider using a 32-bit signed integer,
     and a value of 2,140,000,000 (just shy of 2^31-1).
     We will count up and eventually see that 1,000,000,000
     is smaller than our value. The next step would be to
     multiply by 10 and see that 10,000,000,000 is too
     large, ending the loop. But we can't represent that
     value, and we have signed overflow.

     This is technically undefined behavior, but a common
     behavior is to lose the high bits, in which case our
     iterator will certainly be less than the number. So
     we'll keep multiplying, overflow again, and so on.

This patch changes the argument to a uintmax_t (the same
type we use to store the diffstat information for binary
filese), and counts "down" by repeatedly dividing our value
by 10.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      d306f3d3
    • J
      config: do not ungetc EOF · 5e0be134
      由 Jeff King 提交于 
      When we are parsing a config value, if we see a carriage
return, we fgetc the next character to see if it is a
line feed (in which case we silently drop the CR). If it
isn't, we then ungetc the character, and take the literal
CR.

But we never check whether we in fact got a character at
all. If the config file ends in CR, we will get EOF here,
and try to ungetc EOF. This works OK for a real stdio
stream. The ungetc returns an error, and the next fgetc will
then return EOF again.

However, our custom buffer-based stream is not so fortunate.
It happily rewinds the position of the stream by one
character, ignoring the fact that we fed it EOF. The next
fgetc call returns the final CR again, over and over, and we
end up in an infinite loop.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      5e0be134
  15. 05 2月, 2015 1 次提交
  17. 03 2月, 2015 1 次提交
  19. 31 1月, 2015 1 次提交
  21. 30 1月, 2015 2 次提交
    • J
      Documentation/git-remote.txt: stress that set-url is not for triangular · 697f6528
      由 Junio C Hamano 提交于 
      It seems to be a common mistake to try using a single remote
(e.g. 'origin') to fetch from one place (i.e. upstream) while
pushing to another (i.e. your publishing point).

That will never work satisfactorily, and it is easy to understand
why if you think about what refs/remotes/origin/* would mean in such
a world.  It fundamentally cannot reflect the reality.  If it
follows the state of your upstream, it cannot match what you have
published, and vice versa.

It may be that misinformation is spread by some people.  Let's
counter them by adding a few words to our documentation.

 - The description was referring to <oldurl> and <newurl>, but never
   mentioned <name> argument you give from the command line.  By
   mentioning "remote <name>", stress the fact that it is configuring
   a single remote.

 - Add a reminder that explicitly states that this is about a single
   remote, which the triangular workflow is not about.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      697f6528
    • J
      t/lib-gpg: sanity-check that we can actually sign · 1f985d60
      由 Jeff King 提交于 
      Some older versions of gpg (reportedly v1.2.6 from RHEL4) cannot
import the keyrings found in our test suite, and thus cannot even
make a signature.  The previous change works it around, but we
cannot anticipate breakages update to GPG would cause in the future.

Do a test-sign before declaring the GPG prerequisite fulfilled
to future-proof our tests.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      1f985d60