Re: 'git status' is not read-only fs friendly

["Marco Costalba" <mcostalba@gmail.com>]

On 2/10/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> Not really. The thing is, git-status does a lot more than what you need.
> And what you need is _only_ what "git diff --name-only HEAD" does already!
>
> It _also_ checks the index, it _also_ only checks the files with different
> stat information, but it does _not_ try to update the index and prepare a
> message to be displayed when committing.
>
> So, what is the big problem about accepting that patching git-status for
> one obscure use is wrong, wrong, wrong, when git-diff already does what is
> needed???
>
Probably I'm doing something wrong, but that's how working dir
detection is currently implemented in qgit:

void Git::getDiffIndex() {

	QString status;
	if (!run("git status", &status)) // git status refreshes the index,
run as first
		return;

	if (!run("git diff-index HEAD", &_wd.diffIndex))
		return;

	// check for files already updated in cache, we will
	// save this information in status third field
	if (!run("git diff-index --cached HEAD", &_wd.diffIndexCached))
		return;

          ...... other stuff .....


The first call to git-status has been there for ages and with the only
goal to refesh the index so to avoid stale data in following 'git
diff-index' calls.

If I have understood correctly you suggest to remove that call because
useless? And rely  'git diff-index' info directly. Of course if there
are no side effects I'will be happy to drop the call, but I'm not sure
it's the safest way to go.

Another option would be to accept a broken working dir detection in
these corner cases. It's a realistic option and probably the best.
Indeed also subsitute 'git status' with 'git runstatus' as long as I
get back _all_ the repo files it seems to me a lesser option, IMHO
it's better failing with empty case than have a big flow of incorrect
data.

Marco