Skip to content
Commits on Dec 1, 2014
  1. @pclouds @gitster

    tree.c: update read_tree_recursive callback to pass strbuf as base

    This allows the callback to use 'base' as a temporary buffer to
    quickly assemble full path "without" extra allocation. The callback
    has to restore it afterwards of course.
    
    Helped-by: Eric Sunshine <sunshine@sunshineco.com>
    Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pclouds committed with gitster Nov 30, 2014
Commits on Jul 15, 2013
  1. @pclouds @gitster

    checkout: convert read_tree_some to take struct pathspec

    Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pclouds committed with gitster Jul 14, 2013
Commits on Jul 9, 2013
  1. @pclouds @gitster

    Convert "struct cache_entry *" to "const ..." wherever possible

    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: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pclouds committed with gitster Jul 9, 2013
Commits on Oct 27, 2011
  1. @pclouds @gitster

    tree_entry_interesting(): give meaningful names to return values

    It is a basic code hygiene to avoid magic constants that are unnamed.
    Besides, this helps extending the value later on for "interesting, but
    cannot decide if the entry truely matches yet" (ie. prefix matches)
    
    Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pclouds committed with gitster Oct 24, 2011
  2. @pclouds @gitster

    tree-walk.c: do not leak internal structure in tree_entry_len()

    tree_entry_len() does not simply take two random arguments and return
    a tree length. The two pointers must point to a tree item structure,
    or struct name_entry. Passing random pointers will return incorrect
    value.
    
    Force callers to pass struct name_entry instead of two pointers (with
    hope that they don't manually construct struct name_entry themselves)
    
    Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pclouds committed with gitster Oct 24, 2011
Commits on Mar 25, 2011
  1. @pclouds @gitster

    Convert read_tree{,_recursive} to support struct pathspec

    This patch changes behavior of the two functions. Previously it does
    prefix matching only. Now it can also do wildcard matching.
    
    All callers are updated. Some gain wildcard matching (archive,
    checkout), others reset pathspec_item.has_wildcard to retain old
    behavior (ls-files, ls-tree as they are plumbing).
    
    Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pclouds committed with gitster Mar 25, 2011
  2. @pclouds @gitster

    Reimplement read_tree_recursive() using tree_entry_interesting()

    read_tree_recursive() uses a very similar function, match_tree_entry, to
    tree_entry_interesting() to do its path matching. This patch kills
    match_tree_entry() in favor of tree_entry_interesting().
    
    match_tree_entry(), like older version of tree_entry_interesting(), does
    not support wildcard matching. New read_tree_recursive() retains this
    behavior by forcing all pathspecs literal.
    
    Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    pclouds committed with gitster Mar 25, 2011
Something went wrong with that request. Please try again.