Re: [PATCH] Document git-runstatus
- From
Junio C Hamano <junkio@cox.net>
- Date
- Nov 18, 2006, 18:49 UTC
- Message-ID
- <7vfycgegk6.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <BAYC1-PASMTP06C814AB518D7544770C01AEEF0@CEZ.ICE>
Sean <seanlkml@sympatico.ca> writes:
Show 8 quoted lines
> On Sat, 18 Nov 2006 16:04:43 +0100 > Rene Scharfe <rene.scharfe@lsrfire.ath.cx> 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).