1. 21 Jul, 2014 1 commit
  2. 10 Jul, 2014 1 commit
  3. 24 Feb, 2014 1 commit
  4. 06 Dec, 2013 2 commits
  5. 05 Dec, 2013 1 commit
    • Christian Couder's avatar
      replace {pre,suf}fixcmp() with {starts,ends}_with() · 59556548
      Christian Couder authored
      Leaving only the function definitions and declarations so that any
      new topic in flight can still make use of the old functions, replace
      existing uses of the prefixcmp() and suffixcmp() with new API
      The change can be recreated by mechanically applying this:
          $ git grep -l -e prefixcmp -e suffixcmp -- \*.c |
            grep -v strbuf\\.c |
            xargs perl -pi -e '
      on the result of preparatory changes in this series.
      Signed-off-by: Christian Couder's avatarChristian Couder <chriscool@tuxfamily.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  6. 12 Nov, 2013 1 commit
  7. 28 Oct, 2013 1 commit
    • Duy Nguyen's avatar
      pathspec: stop --*-pathspecs impact on internal parse_pathspec() uses · 4a2d5ae2
      Duy Nguyen authored
      Normally parse_pathspec() is used on command line arguments where it
      can do fancy thing like parsing magic on each argument or adding magic
      for all pathspecs based on --*-pathspecs options.
      There's another use of parse_pathspec(), where pathspec is needed, but
      the input is known to be pure paths. In this case we usually don't
      want --*-pathspecs to interfere. And we definitely do not want to
      parse magic in these paths, regardless of --literal-pathspecs.
      Add new flag PATHSPEC_LITERAL_PATH for this purpose. When it's set,
      --*-pathspecs are ignored, no magic is parsed. And if the caller
      allows PATHSPEC_LITERAL (i.e. the next calls can take literal magic),
      then PATHSPEC_LITERAL will be set.
      This fixes cases where git chokes when GIT_*_PATHSPECS are set because
      parse_pathspec() indicates it won't take any magic. But
      GIT_*_PATHSPECS add them anyway. These are
         export GIT_LITERAL_PATHSPECS=1
         git blame -- something
         git log --follow something
         git log --merge
      "git ls-files --with-tree=path" (aka parse_pathspec() in
      overlay_tree_on_cache()) is safe because the input is empty, and
      producing one pathspec due to PATHSPEC_PREFER_CWD does not take any
      magic into account.
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Acked-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  8. 05 Sep, 2013 1 commit
    • Duy Nguyen's avatar
      pathspec: catch prepending :(prefix) on pathspec with short magic · bc341c8b
      Duy Nguyen authored
      :(prefix) is in the long form. Suppose people pass :!foo with '!'
      being the short form of magic 'bar', the code will happily turn it to
      :(prefix..)!foo, which makes '!' part of the path and no longer a magic.
      The correct form must be ':(prefix..,bar)foo', but as so far we
      haven't had any magic in short form yet (*), the code to convert from
      short form to long one will be inactive anyway. Let's postpone it
      until a real short form magic appears.
      (*) The short form magic '/' is a special case and won't be caught by
      this die(), which is correct. When '/' magic is detected, prefixlen is
      set back to 0 and the whole "if (prefixlen..)" block is skipped.
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  9. 15 Jul, 2013 22 commits
  10. 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/ls-files.c: --with-tree changes stagemask and may set
      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
          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 <pclouds@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  11. 06 Jan, 2013 4 commits