This project is mirrored from https://github.com/git/git. Updated .
  1. 13 Jun, 2014 2 commits
  2. 24 Feb, 2014 1 commit
  3. 18 Nov, 2013 1 commit
    • Karsten Blees's avatar
      read-cache.c: fix memory leaks caused by removed cache entries · 5699d17e
      Karsten Blees authored
      When cache_entry structs are removed from index_state.cache, they are not
      properly freed. Freeing those entries wasn't possible before because we
      couldn't remove them from index_state.name_hash.
      
      Now that we _do_ remove the entries from name_hash, we can also free them.
      Add 'free(cache_entry)' to all call sites of name-hash.c::remove_name_hash
      in read-cache.c (we could free() directly in remove_name_hash(), but
      name-hash.c isn't concerned with cache_entry allocation at all).
      
      Accessing a cache_entry after removing it from the index is now no longer
      allowed, as the memory has been freed. The following functions need minor
      fixes (typically by copying ce->name before use):
       - builtin/rm.c::cmd_rm
       - builtin/update-index.c::do_reupdate
       - read-cache.c::read_index_unmerged
       - resolve-undo.c::unmerge_index_entry_at
      Signed-off-by: default avatarKarsten Blees <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      5699d17e
  4. 15 Jul, 2013 1 commit
  5. 09 Jul, 2013 1 commit
    • Duy Nguyen's avatar
      Convert "struct cache_entry *" to "const ..." wherever possible · 9c5e6c80
      Duy Nguyen authored
      I attempted to make index_state->cache[] a "const struct cache_entry **"
      to find out how existing entries in index are modified and where. The
      question I have is what do we do if we really need to keep track of on-disk
      changes in the index. The result is
      
       - diff-lib.c: setting CE_UPTODATE
      
       - name-hash.c: setting CE_HASHED
      
       - preload-index.c, read-cache.c, unpack-trees.c and
         builtin/update-index: obvious
      
       - entry.c: write_entry() may refresh the checked out entry via
         fill_stat_cache_info(). This causes "non-const struct cache_entry
         *" in builtin/apply.c, builtin/checkout-index.c and
         builtin/checkout.c
      
       - builtin/ls-files.c: --with-tree changes stagemask and may set
         CE_UPDATE
      
      Of these, write_entry() and its call sites are probably most
      interesting because it modifies on-disk info. But this is stat info
      and can be retrieved via refresh, at least for porcelain
      commands. Other just uses ce_flags for local purposes.
      
      So, keeping track of "dirty" entries is just a matter of setting a
      flag in index modification functions exposed by read-cache.c. Except
      unpack-trees, the rest of the code base does not do anything funny
      behind read-cache's back.
      
      The actual patch is less valueable than the summary above. But if
      anyone wants to re-identify the above sites. Applying this patch, then
      this:
      
          diff --git a/cache.h b/cache.h
          index 430d021..1692891 100644
          --- a/cache.h
          +++ b/cache.h
          @@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode)
           #define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1)
      
           struct index_state {
          -	struct cache_entry **cache;
          +	const struct cache_entry **cache;
           	unsigned int version;
           	unsigned int cache_nr, cache_alloc, cache_changed;
           	struct string_list *resolve_undo;
      
      will help quickly identify them without bogus warnings.
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      9c5e6c80
  6. 27 Mar, 2013 1 commit
    • Duy Nguyen's avatar
      checkout: avoid unnecessary match_pathspec calls · e721c154
      Duy Nguyen authored
      In checkout_paths() we do this
      
       - for all updated items, call match_pathspec
       - for all items, call match_pathspec (inside unmerge_cache)
       - for all items, call match_pathspec (for showing "path .. is unmerged)
       - for updated items, call match_pathspec and update paths
      
      That's a lot of duplicate match_pathspec(s) and the function is not
      exactly cheap to be called so many times, especially on large indexes.
      This patch makes it call match_pathspec once per updated index entry,
      save the result in ce_flags and reuse the results in the following
      loops.
      
      The changes in 0a1283bc (checkout $tree $path: do not clobber local
      changes in $path not in $tree - 2011-09-30) limit the affected paths
      to ones we read from $tree. We do not do anything to other modified
      entries in this case, so the "for all items" above could be modified
      to "for all updated items". But..
      
      The command's behavior now is modified slightly: unmerged entries that
      match $path, but not updated by $tree, are now NOT touched.  Although
      this should be considered a bug fix, not a regression. A new test is
      added for this change.
      
      And while at there, free ps_matched after use.
      
      The following command is tested on webkit, 215k entries. The pattern
      is chosen mainly to make match_pathspec sweat:
      
      git checkout -- "*[a-zA-Z]*[a-zA-Z]*[a-zA-Z]*"
      
              before      after
      real    0m3.493s    0m2.737s
      user    0m2.239s    0m1.586s
      sys     0m1.252s    0m1.151s
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      e721c154
  7. 05 Jul, 2010 1 commit
  8. 27 Jun, 2010 3 commits
  9. 02 Feb, 2010 1 commit
  10. 26 Dec, 2009 2 commits
    • Junio C Hamano's avatar
      resolve-undo: "checkout -m path" uses resolve-undo information · 4421a823
      Junio C Hamano authored
      Once you resolved conflicts by "git add path", you cannot recreate the
      conflicted state with "git checkout -m path", because you lost information
      from higher stages in the index when you resolved them.
      
      Since we record the necessary information in the resolve-undo index
      extension these days, we can reproduce the unmerged state in the index and
      check it out.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      4421a823
    • Junio C Hamano's avatar
      resolve-undo: record resolved conflicts in a new index extension section · cfc5789a
      Junio C Hamano authored
      When resolving a conflict using "git add" to create a stage #0 entry, or
      "git rm" to remove entries at higher stages, remove_index_entry_at()
      function is eventually called to remove unmerged (i.e. higher stage)
      entries from the index.  Introduce a "resolve_undo_info" structure and
      keep track of the removed cache entries, and save it in a new index
      extension section in the index_state.
      
      Operations like "read-tree -m", "merge", "checkout [-m] <branch>" and
      "reset" are signs that recorded information in the index is no longer
      necessary.  The data is removed from the index extension when operations
      start; they may leave conflicted entries in the index, and later user
      actions like "git add" will record their conflicted states afresh.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      cfc5789a