From: Junio C Hamano Date: Sat, 18 Nov 2006 18:49:13 GMT Subject: Re: [PATCH] Document git-runstatus Message-ID: <7vfycgegk6.fsf@assigned-by-dhcp.cox.net> In-Reply-To: Sean writes: > On Sat, 18 Nov 2006 16:04:43 +0100 > Rene Scharfe 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).