# Re: \[PATCH\] Document git-runstatus

- From: Junio C Hamano \<hidden\>
- Date: 2016-08-11 19:57:53 
- List: git
- Page: https://ratatoskr.run/git/2016/08/7690183
- Thread: https://ratatoskr.run/git/2016/08/7690183/t.md

```text
Sean [ref] writes:

> On Sat, 18 Nov 2006 16:04:43 +0100
> Rene Scharfe [ref] wrote:
>
>> git-status is a wrapper around git-runstatus that takes the same
>> options as git-commit.  It could have been named 'git-commit --dry-run'.
>
> What could be said in the docs as to when the use of one is preferred
> over the other?

You should treat git-runstatus the same way as you would treat
"git-merge-recursive".  It strictly is a helper and you never
use it by itself.

It takes the parts that are too cumbersome to be enhanced in
shell script from the old git-status script, and rewrites it in
C.

"git-status $args" is to give a preview of the commit that would
be made with "git-commit $args" (where $args can be things like
-a, $paths...).  The part that still remain as script in
git-commit and git-status performs the gory details of index
preparation for the next commit, and tells git-runstatus to show
the status of that index and the working tree relative to the
current HEAD.

Most notably, running "git-update-index --refresh" part is still
done in the script part that calls runstatus, so in a
cache-dirty but otherwise clean tree, running git-runstatus and
then git-status (without any parameters) in this order would
show cache dirty paths in the former but not in the latter (nor
after the latter runs once, since it calls --refresh).
 

```