1. 08 Dec, 2008 1 commit
    • Jeff King's avatar
      reorder ALLOW_TEXTCONV option setting · 5ec11af6
      Jeff King authored
      Right now for the diff porcelain and the log family, we
      call:
      
        init_revisions();
        setup_revisions();
        DIFF_OPT_SET(ALLOW_TEXTCONV);
      
      However, that means textconv will _always_ be on, instead of
      being a default that can be manipulated with
      setup_revisions. Instead, we want:
      
        init_revisions();
        DIFF_OPT_SET(ALLOW_TEXTCONV);
        setup_revisions();
      
      which is what this patch does.
      
      We'll go ahead and move the callsite in wt-status, also;
      even though the user can't pass any options here, it is a
      cleanup that will help avoid any surprise later if the
      setup_revisions line is changed.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      5ec11af6
  2. 12 Nov, 2008 2 commits
  3. 26 Oct, 2008 2 commits
  4. 17 Oct, 2008 1 commit
    • Jeff King's avatar
      refactor handling of "other" files in ls-files and status · 98fa4738
      Jeff King authored
      When the "git status" display code was originally converted
      to C, we copied the code from ls-files to discover whether a
      pathname returned by read_directory was an "other", or
      untracked, file.
      
      Much later, 5698454e updated the code in ls-files to handle
      some new cases caused by gitlinks.  This left the code in
      wt-status.c broken: it would display submodule directories
      as untracked directories. Nobody noticed until now, however,
      because unless status.showUntrackedFiles was set to "all",
      submodule directories were not actually reported by
      read_directory. So the bug was only triggered in the
      presence of a submodule _and_ this config option.
      
      This patch pulls the ls-files code into a new function,
      cache_name_is_other, and uses it in both places. This should
      leave the ls-files functionality the same and fix the bug
      in status.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      98fa4738
  5. 12 Oct, 2008 1 commit
  6. 07 Sep, 2008 2 commits
  7. 06 Jul, 2008 1 commit
  8. 03 Jul, 2008 1 commit
  9. 09 Jun, 2008 3 commits
  10. 23 May, 2008 1 commit
  11. 14 May, 2008 1 commit
  12. 03 May, 2008 1 commit
    • Jeff King's avatar
      bump rename limit defaults · 50705915
      Jeff King authored
      The current rename limit default of 100 was arbitrarily
      chosen. Testing[1] has shown that on modern hardware, a
      limit of 200 adds about a second of computation time, and a
      limit of 500 adds about 5 seconds of computation time.
      
      This patch bumps the default limit to 200 for viewing diffs,
      and to 500 for performing a merge. The limit for generating
      git-status templates is set independently; we bump it up to
      200 here, as well, to match the diff limit.
      
      [1]: See <[email protected]>
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      50705915
  13. 13 Apr, 2008 1 commit
    • Ping Yin's avatar
      builtin-status: submodule summary support · ac8d5afc
      Ping Yin authored
      This commit teaches 'git commit/status' show a new 'Modified submodules'
      section, which is an output from:
      
        git submodule summary --cached --for-status --summary-limit <limit>
      
      just before the 'Untracked files' section.
      
      The <limit> is given by the config variable status.submodulesummary
      to limit the submodule summary size. status.submodulesummary is a
      bool/int variable with value:
      
        - false or 0 by default to disable the summary, or
        - positive number to limit the summary size, or
        - true or negative number to unlimit the summary size.
      
      Also mention status.submodulesummary in the documentation.
      Signed-off-by: default avatarPing Yin <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      ac8d5afc
  14. 14 Mar, 2008 1 commit
  15. 08 Mar, 2008 1 commit
  16. 18 Feb, 2008 1 commit
  17. 13 Feb, 2008 1 commit
    • Jeff King's avatar
      status: suggest "git rm --cached" to unstage for initial commit · ff58b9aa
      Jeff King authored
      It makes no sense to suggest "git reset HEAD" since we have
      no HEAD commit. This actually used to work but regressed in
      f26a0012.
      
      wt_status_print_cached_header was updated to take the whole
      wt_status struct rather than just the reference field.
      Previously the various code paths were sometimes sending in
      s->reference and sometimes sending in NULL, making the
      decision on whether this was an initial commit before we
      even got to this function. Now we must check the initial
      flag here.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      ff58b9aa
  18. 11 Feb, 2008 1 commit
  19. 21 Jan, 2008 1 commit
    • Linus Torvalds's avatar
      Make run_diff_index() use unpack_trees(), not read_tree() · d1f2d7e8
      Linus Torvalds authored
      A plain "git commit" would still run lstat() a lot more than necessary,
      because wt_status_print() would cause the index to be repeatedly flushed
      and re-read by wt_read_cache(), and that would cause the CE_UPTODATE bit
      to be lost, resulting in the files in the index being lstat'ed three
      times each.
      
      The reason why wt-status.c ended up invalidating and re-reading the
      cache multiple times was that it uses "run_diff_index()", which in turn
      uses "read_tree()" to populate the index with *both* the old index and
      the tree we want to compare against.
      
      So this patch re-writes run_diff_index() to not use read_tree(), but
      instead use "unpack_trees()" to diff the index to a tree.  That, in
      turn, means that we don't need to modify the index itself, which then
      means that we don't need to invalidate it and re-read it!
      
      This, together with the lstat() optimizations, means that "git commit"
      on the kernel tree really only needs to lstat() the index entries once.
      That noticeably cuts down on the cached timings.
      
      Best time before:
      
      	[[email protected] linux]$ time git commit > /dev/null
      	real    0m0.399s
      	user    0m0.232s
      	sys     0m0.164s
      
      Best time after:
      
      	[[email protected] linux]$ time git commit > /dev/null
      	real    0m0.254s
      	user    0m0.140s
      	sys     0m0.112s
      
      so it's a noticeable improvement in addition to being a nice conceptual
      cleanup (it's really not that pretty that "run_diff_index()" dirties the
      index!)
      
      Doing an "strace -c" on it also shows that as it cuts the number of
      lstat() calls by two thirds, it goes from being lstat()-limited to being
      limited by getdents() (which is the readdir system call):
      
      Before:
      	% time     seconds  usecs/call     calls    errors syscall
      	------ ----------- ----------- --------- --------- ----------------
      	 60.69    0.000704           0     69230        31 lstat
      	 23.62    0.000274           0      5522           getdents
      	  8.36    0.000097           0      5508      2638 open
      	  2.59    0.000030           0      2869           close
      	  2.50    0.000029           0       274           write
      	  1.47    0.000017           0      2844           fstat
      
      After:
      	% time     seconds  usecs/call     calls    errors syscall
      	------ ----------- ----------- --------- --------- ----------------
      	 45.17    0.000276           0      5522           getdents
      	 26.51    0.000162           0     23112        31 lstat
      	 19.80    0.000121           0      5503      2638 open
      	  4.91    0.000030           0      2864           close
      	  1.48    0.000020           0       274           write
      	  1.34    0.000018           0      2844           fstat
      	...
      
      It passes the test-suite for me, but this is another of one of those
      really core functions, and certainly pretty subtle, so..
      
      NOTE! The Linux lstat() system call is really quite cheap when everything
      is cached, so the fact that this is quite noticeable on Linux is likely to
      mean that it is *much* more noticeable on other operating systems. I bet
      you'll see a much bigger performance improvement from this on Windows in
      particular.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      d1f2d7e8
  20. 13 Dec, 2007 1 commit
    • Junio C Hamano's avatar
      git-commit: squelch needless message during an empty merge · 37d07f8f
      Junio C Hamano authored
      When recording a merge that conflicted and ends up in no changes after
      manual resolution, commit callchain looked like this:
      
      	cmd_commit() ->
                  prepare_log_message() ->
                      run_status() ->
      		    wt_status_print()
      
      This invocation of run_status() is asked to find out if there is a
      committable change, but it unconditionally gave instructions such as
      "use git-add" at the same time.  When in merge, we do allow an empty
      change to be recorded, so after showing this message the code still went
      ahead and made a commit.
      
      This introduces "nowarn" parameter to run_status() to avoid these
      useless messages.  If we are not allowed to create an empty commit, we
      already call run_status() again in the original codepath, and the
      message will be shown from that call anyway.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      37d07f8f
  21. 08 Dec, 2007 2 commits
    • Jeff King's avatar
      add status.relativePaths config variable · 46f721c8
      Jeff King authored
      The output of git-status was recently changed to output relative
      paths. Setting this variable to false restores the old behavior for
      any old-timers that prefer it.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      46f721c8
    • Jeff King's avatar
      wt-status.c:quote_path(): convert empty path to "./" · c3ce3261
      Jeff King authored
      Now that we are correctly removing leading prefixes from files in git
      status, there is a degenerate case: the directory matching the prefix.
      Because we show only the directory name for a directory that contains
      only untracked files, it gets collapsed to an empty string.
      
      Example:
      
        $ git init
        $ mkdir subdir
        $ touch subdir/file
        $ git status
        ...
        # Untracked files:
        #   (use "git add <file>..." to include in what will be committed)
        #
        #       subdir/
      
        So far, so good.
      
        $ cd subdir
        $ git status
        ....
        # Untracked files:
        #   (use "git add <file>..." to include in what will be committed)
        #
        #
      
        Oops, that's a bit confusing.
      
        This patch prints './' to show that there is some output.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      c3ce3261
  22. 06 Dec, 2007 1 commit
    • Junio C Hamano's avatar
      git config --get-colorbool · 0f6f5a40
      Junio C Hamano authored
      This adds an option to help scripts find out color settings from
      the configuration file.
      
          git config --get-colorbool color.diff
      
      inspects color.diff variable, and exits with status 0 (i.e. success) if
      color is to be used.  It exits with status 1 otherwise.
      
      If a script wants "true"/"false" answer to the standard output of the
      command, it can pass an additional boolean parameter to its command
      line, telling if its standard output is a terminal, like this:
      
          git config --get-colorbool color.diff true
      
      When called like this, the command outputs "true" to its standard output
      if color is to be used (i.e. "color.diff" says "always", "auto", or
      "true"), and "false" otherwise.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      0f6f5a40
  23. 03 Dec, 2007 2 commits
  24. 23 Nov, 2007 2 commits
  25. 17 Nov, 2007 1 commit
    • Junio C Hamano's avatar
      core.excludesfile clean-up · dcf0c16e
      Junio C Hamano authored
      There are inconsistencies in the way commands currently handle
      the core.excludesfile configuration variable.  The problem is
      the variable is too new to be noticed by anything other than
      git-add and git-status.
      
       * git-ls-files does not notice any of the "ignore" files by
         default, as it predates the standardized set of ignore files.
         The calling scripts established the convention to use
         .git/info/exclude, .gitignore, and later core.excludesfile.
      
       * git-add and git-status know about it because they call
         add_excludes_from_file() directly with their own notion of
         which standard set of ignore files to use.  This is just a
         stupid duplication of code that need to be updated every time
         the definition of the standard set of ignore files is
         changed.
      
       * git-read-tree takes --exclude-per-directory=<gitignore>,
         not because the flexibility was needed.  Again, this was
         because the option predates the standardization of the ignore
         files.
      
       * git-merge-recursive uses hardcoded per-directory .gitignore
         and nothing else.  git-clean (scripted version) does not
         honor core.* because its call to underlying ls-files does not
         know about it.  git-clean in C (parked in 'pu') doesn't either.
      
      We probably could change git-ls-files to use the standard set
      when no excludes are specified on the command line and ignore
      processing was asked, or something like that, but that will be a
      change in semantics and might break people's scripts in a subtle
      way.  I am somewhat reluctant to make such a change.
      
      On the other hand, I think it makes perfect sense to fix
      git-read-tree, git-merge-recursive and git-clean to follow the
      same rule as other commands.  I do not think of a valid use case
      to give an exclude-per-directory that is nonstandard to
      read-tree command, outside a "negative" test in the t1004 test
      script.
      
      This patch is the first step to untangle this mess.
      
      The next step would be to teach read-tree, merge-recursive and
      clean (in C) to use setup_standard_excludes().
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      dcf0c16e
  26. 14 Nov, 2007 1 commit
    • Junio C Hamano's avatar
      core.excludesfile clean-up · 039bc64e
      Junio C Hamano authored
      There are inconsistencies in the way commands currently handle
      the core.excludesfile configuration variable.  The problem is
      the variable is too new to be noticed by anything other than
      git-add and git-status.
      
       * git-ls-files does not notice any of the "ignore" files by
         default, as it predates the standardized set of ignore files.
         The calling scripts established the convention to use
         .git/info/exclude, .gitignore, and later core.excludesfile.
      
       * git-add and git-status know about it because they call
         add_excludes_from_file() directly with their own notion of
         which standard set of ignore files to use.  This is just a
         stupid duplication of code that need to be updated every time
         the definition of the standard set of ignore files is
         changed.
      
       * git-read-tree takes --exclude-per-directory=<gitignore>,
         not because the flexibility was needed.  Again, this was
         because the option predates the standardization of the ignore
         files.
      
       * git-merge-recursive uses hardcoded per-directory .gitignore
         and nothing else.  git-clean (scripted version) does not
         honor core.* because its call to underlying ls-files does not
         know about it.  git-clean in C (parked in 'pu') doesn't either.
      
      We probably could change git-ls-files to use the standard set
      when no excludes are specified on the command line and ignore
      processing was asked, or something like that, but that will be a
      change in semantics and might break people's scripts in a subtle
      way.  I am somewhat reluctant to make such a change.
      
      On the other hand, I think it makes perfect sense to fix
      git-read-tree, git-merge-recursive and git-clean to follow the
      same rule as other commands.  I do not think of a valid use case
      to give an exclude-per-directory that is nonstandard to
      read-tree command, outside a "negative" test in the t1004 test
      script.
      
      This patch is the first step to untangle this mess.
      
      The next step would be to teach read-tree, merge-recursive and
      clean (in C) to use setup_standard_excludes().
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      039bc64e
  27. 19 Sep, 2007 2 commits
  28. 14 Sep, 2007 1 commit
    • Linus Torvalds's avatar
      Fix the rename detection limit checking · 0024a549
      Linus Torvalds authored
      This adds more proper rename detection limits. Instead of just checking
      the limit against the number of potential rename destinations, we verify
      that the rename matrix (which is what really matters) doesn't grow
      ridiculously large, and we also make sure that we don't overflow when
      doing the matrix size calculation.
      
      This also changes the default limits from unlimited, to a rename matrix
      that is limited to 100 entries on a side. You can raise it with the config
      entry, or by using the "-l<n>" command line flag, but at least the default
      is now a sane number that avoids spending lots of time (and memory) in
      situations that likely don't merit it.
      
      The choice of default value is of course very debatable. Limiting the
      rename matrix to a 100x100 size will mean that even if you have just one
      obvious rename, but you also create (or delete) 10,000 files, the rename
      matrix will be so big that we disable the heuristics. Sounds reasonable to
      me, but let's see if people hit this (and, perhaps more importantly,
      actually *care*) in real life.
      Signed-off-by: default avatarLinus Torvalds <[email protected]on.org>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      0024a549
  29. 08 Jun, 2007 1 commit
  30. 22 May, 2007 1 commit
  31. 01 Apr, 2007 1 commit
    • Linus Torvalds's avatar
      Optimize directory listing with pathspec limiter. · 9fc42d60
      Linus Torvalds authored
      The way things are set up, you can now pass a "pathspec" to the
      "read_directory()" function. If you pass NULL, it acts exactly
      like it used to do (read everything). If you pass a non-NULL
      pointer, it will simplify it into a "these are the prefixes
      without any special characters", and stop any readdir() early if
      the path in question doesn't match any of the prefixes.
      
      NOTE! This does *not* obviate the need for the caller to do the *exact*
      pathspec match later. It's a first-level filter on "read_directory()", but
      it does not do the full pathspec thing. Maybe it should. But in the
      meantime, builtin-add.c really does need to do first
      
      	read_directory(dir, .., pathspec);
      	if (pathspec)
      		prune_directory(dir, pathspec, baselen);
      
      ie the "prune_directory()" part will do the *exact* pathspec pruning,
      while the "read_directory()" will use the pathspec just to do some quick
      high-level pruning of the directories it will recurse into.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      9fc42d60