1. 12 Sep, 2018 1 commit
  2. 05 Sep, 2018 1 commit
    • Jeff King's avatar
      reopen_tempfile(): truncate opened file · 6c003d6f
      Jeff King authored
      We provide a reopen_tempfile() function, which is in turn
      used by reopen_lockfile().  The idea is that a caller may
      want to rewrite the tempfile without letting go of the lock.
      And that's what our one caller does: after running
      add--interactive, "commit -p" will update the cache-tree
      extension of the index and write out the result, all while
      holding the lock.
      
      However, because we open the file with only the O_WRONLY
      flag, the existing index content is left in place, and we
      overwrite it starting at position 0. If the new index after
      updating the cache-tree is smaller than the original, those
      final bytes are not overwritten and remain in the file. This
      results in a corrupt index, since those cruft bytes are
      interpreted as part of the trailing hash (or even as an
      extension, if there are enough bytes).
      
      This bug actually pre-dates reopen_tempfile(); the original
      code from 9c4d6c02 (cache-tree: Write updated cache-tree
      after commit, 2014-07-13) has the same bug, and those lines
      were eventually refactored into the tempfile module. Nobody
      noticed until now for two reasons:
      
       - the bug can only be triggered in interactive mode
         ("commit -p" or "commit -i")
      
       - the size of the index must shrink after updating the
         cache-tree, which implies a non-trivial deletion. Notice
         that the included test actually has to create a 2-deep
         hierarchy. A single level is not enough to actually cause
         shrinkage.
      
      The fix is to truncate the file before writing out the
      second index. We can do that at the caller by using
      ftruncate(). But we shouldn't have to do that. There is no
      other place in Git where we want to open a file and
      overwrite bytes, making reopen_tempfile() a confusing and
      error-prone interface. Let's pass O_TRUNC there, which gives
      callers the same state they had after initially opening the
      file or lock.
      
      It's possible that we could later add a caller that wants
      something else (e.g., to open with O_APPEND). But this is
      the only caller we've had in the history of the codebase.
      Let's punt on doing anything more clever until another one
      comes along.
      Reported-by: Luc Van Oostenryck's avatarLuc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      6c003d6f
  3. 21 Aug, 2018 1 commit
    • Gábor Szeder's avatar
      tests: use 'test_must_be_empty' instead of '! test -s' · ec10b018
      Gábor Szeder authored
      Using 'test_must_be_empty' is preferable to '! test -s', because it
      gives a helpful error message if the given file is unexpectedly not
      empty, while the latter remains completely silent.  Furthermore, it
      also catches cases when the given file unexpectedly does not exist at
      all.
      
      This patch was basically created by:
      
        sed -i -e 's/! test -s/test_must_be_empty/' t[0-9]*.sh
      
      with the following notable exceptions:
      
        - The '! test -s' check in '.gitmodules ignore=dirty suppresses
          submodules with untracked content' in 't7508-status.sh' is left
          as-is, because it's bogus and, therefore, it's subject of a
          dedicated patch.
      
        - The '! test -s' checks in 't9131-git-svn-empty-symlink.sh' and
          't9135-git-svn-moved-branch-empty-file.sh' are immediately
          preceeded by a 'test -f' to ensure that the files exist in the
          first place.  'test_must_be_empty' ensures that as well, so those
          'test -f' commands are removed as well.
      Signed-off-by: Gábor Szeder's avatarSZEDER Gábor <szeder.dev@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      ec10b018
  4. 03 Jul, 2018 1 commit
  5. 14 May, 2018 1 commit
  6. 27 Mar, 2018 3 commits
  7. 31 Aug, 2015 1 commit
    • David Turner's avatar
      commit: don't rewrite shared index unnecessarily · 475a3445
      David Turner authored
      Remove a cache invalidation which would cause the shared index to be
      rewritten on as-is commits.
      
      When the cache-tree has changed, we need to update it.  But we don't
      necessarily need to update the shared index.  So setting
      active_cache_changed to SOMETHING_CHANGED is unnecessary.  Instead, we
      let update_main_cache_tree just update the CACHE_TREE_CHANGED bit.
      
      In order to test this, make test-dump-split-index not segfault on
      missing replace_bitmap/delete_bitmap.  This new codepath is not called
      now that the test passes, but is necessary to avoid a segfault when the
      new test is run with the old builtin/commit.c code.
      Signed-off-by: default avatarDavid Turner <dturner@twopensource.com>
      Acked-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      475a3445
  8. 28 Jul, 2015 1 commit
  9. 23 Dec, 2014 1 commit
    • Ben Walton's avatar
      t0090: tweak awk statement for Solaris /usr/xpg4/bin/awk · d69360c6
      Ben Walton authored
      The awk statements previously used in this test weren't compatible
      with the native versions of awk on Solaris:
      
          echo "dir" | /bin/awk -v c=0 '$1 {++c} END {print c}'
          awk: syntax error near line 1
          awk: bailing out near line 1
      
          echo "dir" | /usr/xpg4/bin/awk -v c=0 '$1 {++c} END {print c}'
          0
      
      Even though we do not cater to tools in /usr/bin on Solaris that
      have and are overridden by corresponding ones in /usr/xpg?/bin,
      in this case, even the XPG version does not work correctly.
      
      With GNU awk for comparison:
      
          echo "dir" | /opt/csw/gnu/awk -v c=0 '$1 {++c} END {print c}'
          1
      
      which is what this test expects (and is in line with POSIX; non-empty
      string is true and an empty string is false).
      
      Work this issue around by using $1 != "" to state more explicitly
      that we are skipping empty lines.
      Helped-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarBen Walton <bdwalton@gmail.com>
      Reviewed-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      d69360c6
  10. 18 Nov, 2014 1 commit
  11. 30 Sep, 2014 1 commit
  12. 03 Sep, 2014 1 commit
    • Junio C Hamano's avatar
      cache-tree: do not try to use an invalidated subtree info to build a tree · 4ed115e9
      Junio C Hamano authored
      We punt from repairing the cache-tree during a branch switching if
      it involves having to create a new tree object that does not yet
      exist in the object store.  "mkdir dir && >dir/file && git add dir"
      followed by "git checkout" is one example, when a tree that records
      the state of such "dir/" is not in the object store.
      
      However, after discovering that we do not have a tree object that
      records the state of "dir/", the caller failed to remember the fact
      that it noticed the cache-tree entry it received for "dir/" is
      invalidated, it already knows it should not be populating the level
      that has "dir/" as its immediate subdirectory, and it is not an
      error at all for the sublevel cache-tree entry gave it a bogus
      object name it shouldn't even look at.
      
      This led the caller to detect and report a non-existent error.  The
      end result was the same and we avoided stuffing a non-existent tree
      to the cache-tree, but we shouldn't have issued an alarming error
      message to the user.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      4ed115e9
  13. 14 Jul, 2014 1 commit
  14. 11 Jul, 2014 1 commit
  15. 07 Jul, 2014 1 commit
  16. 20 Dec, 2011 1 commit
  17. 06 Dec, 2011 3 commits
    • Thomas Rast's avatar
      reset: update cache-tree data when appropriate · 6c52ec8a
      Thomas Rast authored
      In the case of --mixed and --hard, we throw away the old index and
      rebuild everything from the tree argument (or HEAD).  So we have an
      opportunity here to fill in the cache-tree data, just as read-tree
      did.
      Signed-off-by: default avatarThomas Rast <trast@student.ethz.ch>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      6c52ec8a
    • Thomas Rast's avatar
      commit: write cache-tree data when writing index anyway · 11c8a74a
      Thomas Rast authored
      In prepare_index(), we refresh the index, and then write it to disk if
      this changed the index data.  After running hooks we re-read the index
      and compute the root tree sha1 with the cache-tree machinery.
      
      This gives us a mostly free opportunity to write up-to-date cache-tree
      data: we can compute it in prepare_index() immediately before writing
      the index to disk.
      
      If we do this, we were going to write the index anyway, and the later
      cache-tree update has no further work to do.  If we don't do it, we
      don't do any extra work, though we still don't have have cache-tree
      data after the commit.
      
      The only case that suffers badly is when the pre-commit hook changes
      many trees in the index.  I'm writing this off as highly unusual.
      Signed-off-by: default avatarThomas Rast <trast@student.ethz.ch>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      11c8a74a
    • Thomas Rast's avatar
      Test the current state of the cache-tree optimization · 4eb0346f
      Thomas Rast authored
      The cache-tree optimization originally helped speed up write-tree
      operation.  However, many commands no longer properly maintain -- or
      use an opportunity to cheaply generate -- the cache-tree data.  In
      particular, this affects commit, checkout and reset.  The notable
      examples that *do* write cache-tree data are read-tree and write-tree.
      
      This sadly means most people no longer benefit from the optimization,
      as they would not normally use the plumbing commands.
      
      Document the current state of affairs in a test file, in preparation
      for improvements in the area.
      Signed-off-by: default avatarThomas Rast <trast@student.ethz.ch>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      4eb0346f