1. 08 3月, 2014 1 次提交
    • J
      show_ident_date: fix tz range check · 3f419d45
      Jeff King 提交于
      Commit 1dca155f (log: handle integer overflow in
      timestamps, 2014-02-24) tried to catch integer overflow
      coming from strtol() on the timezone field by comparing against
      LONG_MIN/LONG_MAX. However, the intermediate "tz" variable
      is an "int", which means it can never be LONG_MAX on LP64
      systems; we would truncate the output from strtol before the
      comparison.
      
      Clang's -Wtautological-constant-out-of-range-compare notices
      this and rightly complains.
      
      Let's instead store the result of strtol in a long, and then
      compare it against INT_MIN/INT_MAX. This will catch overflow
      from strtol, and also overflow when we pass the result as an
      int to show_date.
      Reported-by: NEric Sunshine <sunshine@sunshineco.com>
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      3f419d45
  2. 25 2月, 2014 5 次提交
    • J
      log: do not segfault on gmtime errors · 2b15846d
      Jeff King 提交于
      Many code paths assume that show_date and show_ident_date
      cannot return NULL. For the most part, we handle missing or
      corrupt timestamps by showing the epoch time t=0.
      
      However, we might still return NULL if gmtime rejects the
      time_t we feed it, resulting in a segfault. Let's catch this
      case and just format t=0.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      2b15846d
    • J
      log: handle integer overflow in timestamps · 1dca155f
      Jeff King 提交于
      If an ident line has a ridiculous date value like (2^64)+1,
      we currently just pass ULONG_MAX along to the date code,
      which can produce nonsensical dates.
      
      On systems with a signed long time_t (e.g., 64-bit glibc
      systems), this actually doesn't end up too bad. The
      ULONG_MAX is converted to -1, we apply the timezone field to
      that, and the result ends up somewhere between Dec 31, 1969
      and Jan 1, 1970.
      
      However, there is still a few good reasons to detect the
      overflow explicitly:
      
        1. On systems where "unsigned long" is smaller than
           time_t, we get a nonsensical date in the future.
      
        2. Even where it would produce "Dec 31, 1969", it's easier
           to recognize "midnight Jan 1" as a consistent sentinel
           value for "we could not parse this".
      
        3.  Values which do not overflow strtoul but do overflow a
            signed time_t produce nonsensical values in the past.
            For example, on a 64-bit system with a signed long
            time_t, a timestamp of 18446744073000000000 produces a
            date in 1947.
      
      We also recognize overflow in the timezone field, which
      could produce nonsensical results. In this case we show the
      parsed date, but in UTC.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      1dca155f
    • J
      date: check date overflow against time_t · 7ca36d93
      Jeff King 提交于
      When we check whether a timestamp has overflowed, we check
      only against ULONG_MAX, meaning that strtoul has overflowed.
      However, we also feed these timestamps to system functions
      like gmtime, which expect a time_t. On many systems, time_t
      is actually smaller than "unsigned long" (e.g., because it
      is signed), and we would overflow when using these
      functions.  We don't know the actual size or signedness of
      time_t, but we can easily check for truncation with a simple
      assignment.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      7ca36d93
    • J
      fsck: report integer overflow in author timestamps · d4b8de04
      Jeff King 提交于
      When we check commit objects, we complain if commit->date is
      ULONG_MAX, which is an indication that we saw integer
      overflow when parsing it. However, we do not do any check at
      all for author lines, which also contain a timestamp.
      
      Let's actually check the timestamps on each ident line
      with strtoul. This catches both author and committer lines,
      and we can get rid of the now-redundant commit->date check.
      
      Note that like the existing check, we compare only against
      ULONG_MAX. Now that we are calling strtoul at the site of
      the check, we could be slightly more careful and also check
      that errno is set to ERANGE. However, this will make further
      refactoring in future patches a little harder, and it
      doesn't really matter in practice.
      
      For 32-bit systems, one would have to create a commit at the
      exact wrong second in 2038. But by the time we get close to
      that, all systems will hopefully have moved to 64-bit (and
      if they haven't, they have a real problem one second later).
      
      For 64-bit systems, by the time we get close to ULONG_MAX,
      all systems will hopefully have been consumed in the fiery
      wrath of our expanding Sun.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      d4b8de04
    • J
      t4212: test bogus timestamps with git-log · 7d9a2819
      Jeff King 提交于
      When t4212 was originally added by 9dbe7c3d (pretty: handle
      broken commit headers gracefully, 2013-04-17), it tested our
      handling of commits with broken ident lines in which the
      timestamps could not be parsed. It does so using a bogus line
      like "Name <email>-<> 1234 -0000", because that simulates an
      error that was seen in the wild.
      
      Later, 03818a4a (split_ident: parse timestamp from end of
      line, 2013-10-14) made our parser smart enough to actually
      find the timestamp on such a line, and t4212 was adjusted to
      match. While it's nice that we handle this real-world case,
      this meant that we were not actually testing the
      bogus-timestamp case anymore.
      
      This patch adds a test with a totally incomprehensible
      timestamp to make sure we are testing the code path.
      
      Note that the behavior is slightly different between regular log
      output and "--format=%ad". In the former case, we produce a
      sentinel value and in the latter, we produce an empty
      string. While at first this seems unnecessarily
      inconsistent, it matches the original behavior given by
      9dbe7c3d.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      7d9a2819
  3. 06 9月, 2013 1 次提交
  4. 31 8月, 2013 1 次提交
  5. 04 7月, 2013 2 次提交
  6. 12 6月, 2013 2 次提交
  7. 29 5月, 2013 1 次提交
  8. 10 5月, 2013 6 次提交
    • J
      Git 1.8.2.3 · 92758dd2
      Junio C Hamano 提交于
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      92758dd2
    • J
      Merge branch 'tr/copy-revisions-from-stdin' into maint · 07e03d46
      Junio C Hamano 提交于
      * tr/copy-revisions-from-stdin:
        read_revisions_from_stdin: make copies for handle_revision_arg
      07e03d46
    • R
      t5004: avoid using tar for checking emptiness of archive · ea2d20d4
      René Scharfe 提交于
      Test 2 of t5004 checks if a supposedly empty tar archive really
      contains no files.  24676f02 (t5004: fix issue with empty archive test
      and bsdtar) removed our commit hash to make it work with bsdtar, but
      the test still fails on NetBSD and OpenBSD, which use their own tar
      that considers a tar file containing only NULs as broken.
      
      Here's what the different archivers do when asked to create a tar
      file without entries:
      
      	$ uname -v
      	NetBSD 6.0.1 (GENERIC)
      	$ gtar --version | head -1
      	tar (GNU tar) 1.26
      	$ bsdtar --version
      	bsdtar 2.8.4 - libarchive 2.8.4
      
      	$ : >zero.tar
      	$ perl -e 'print "\0" x 10240' >tenk.tar
      	$ sha1 zero.tar tenk.tar
      	SHA1 (zero.tar) = da39a3ee5e6b4b0d3255bfef95601890afd80709
      	SHA1 (tenk.tar) = 34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c
      
      	$ : | tar cf - -T - | sha1
      	da39a3ee5e6b4b0d3255bfef95601890afd80709
      	$ : | gtar cf - -T - | sha1
      	34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c
      	$ : | bsdtar cf - -T - | sha1
      	34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c
      
      So NetBSD's native tar creates an empty file, while GNU tar and bsdtar
      both give us 10KB of NULs -- just like git archive with an empty tree.
      Now let's see how the archivers handle these two kinds of empty tar
      files:
      
      	$ tar tf zero.tar; echo $?
      	tar: Unexpected EOF on archive file
      	1
      	$ gtar tf zero.tar; echo $?
      	gtar: This does not look like a tar archive
      	gtar: Exiting with failure status due to previous errors
      	2
      	$ bsdtar tf zero.tar; echo $?
      	0
      
      	$ tar tf tenk.tar; echo $?
      	tar: Cannot identify format. Searching...
      	tar: End of archive volume 1 reached
      	tar: Sorry, unable to determine archive format.
      	1
      	$ gtar tf tenk.tar; echo $?
      	0
      	$ bsdtar tf tenk.tar; echo $?
      	0
      
      NetBSD's tar complains about both, bsdtar happily accepts any of them
      and GNU tar doesn't like zero-length archive files.  So the safest
      course of action is to stay with our block-of-NULs format which is
      compatible with GNU tar and bsdtar, as we can't make NetBSD's native
      tar happy anyway.
      
      We can simplify our test, however, by taking tar out of the picture.
      Instead of extracting the archive and checking for the non-presence of
      files, check if the file has a size of 10KB and contains only NULs.
      This makes t5004 pass on NetBSD and OpenBSD.
      Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ea2d20d4
    • R
      t5004: ignore pax global header file · abdb9b2e
      René Scharfe 提交于
      Versions of tar that don't know pax headers -- like the ones in NetBSD 6
      and OpenBSD 5.2 -- extract them as regular files.  Explicitly ignore the
      file created for our global header when checking the list of extracted
      files, as this is normal and harmless fall-back behaviour.  This fixes
      test 3 of t5004 on these platforms.
      Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      abdb9b2e
    • D
      mergetools/kdiff3: do not use --auto when diffing · e2161bc3
      David Aguilar 提交于
      The `kdiff3 --auto` help message is, "No GUI if all conflicts are auto-
      solvable."  This flag was carried over from the original mergetool
      commands.  diff_cmd() is for two-way comparisons only so remove the
      superfluous flag.
      Signed-off-by: NDavid Aguilar <davvid@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      e2161bc3
    • F
      b120ef3e
  9. 04 5月, 2013 3 次提交
  10. 03 5月, 2013 1 次提交
  11. 30 4月, 2013 3 次提交
    • J
      Merge branch 'fc/zsh-completion' into maint · 8301b976
      Junio C Hamano 提交于
      * fc/zsh-completion:
        complete: zsh: use zsh completion for the main cmd
        complete: zsh: trivial simplification
      8301b976
    • F
      complete: zsh: use zsh completion for the main cmd · 4911589b
      Felipe Contreras 提交于
      So that we can have a nice zsh completion output:
      
      % git <tab>
      add       -- add file contents to the index
      bisect    -- find by binary search the change that introduced a bug
      branch    -- list, create, or delete branches
      checkout  -- checkout a branch or paths to the working tree
      clone     -- clone a repository into a new directory
      commit    -- record changes to the repository
      diff      -- show changes between commits, commit and working tree, etc
      fetch     -- download objects and refs from another repository
      grep      -- print lines matching a pattern
      init      -- create an empty Git repository or reinitialize an existing one
      log       -- show commit logs
      merge     -- join two or more development histories together
      mv        -- move or rename a file, a directory, or a symlink
      pull      -- fetch from and merge with another repository or a local branch
      push      -- update remote refs along with associated objects
      rebase    -- forward-port local commits to the updated upstream head
      reset     -- reset current HEAD to the specified state
      rm        -- remove files from the working tree and from the index
      show      -- show various types of objects
      status    -- show the working tree status
      tag       -- create, list, delete or verify a tag object signed with GPG
      
      And other niceties, like 'git --git-dir=<tab>' showing only directories.
      
      For the rest, the bash completion stuff is still used.
      
      Also, add my copyright, since this more than a thin wrapper.
      Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      4911589b
    • F
      complete: zsh: trivial simplification · 1ca6d4bc
      Felipe Contreras 提交于
      There should be no functional changes.
      
      The only reason I wrapped this code around a sub-function is because zsh
      did the same in it's bashcompinit script in order to declare the special
      variable 'words' as hidden, but only in this context.
      
      There's no need for that any more since we access __git_main directly,
      so 'words' is not modified, so there's no need for the sub-function.
      
      In zsh mode the array indexes are different though.
      Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      1ca6d4bc
  12. 29 4月, 2013 5 次提交
  13. 27 4月, 2013 9 次提交