From: Paul Mackerras <paulus@samba.org>
Date: Sun, 10 Apr 2011 02:03:18 GMT
Subject: Re: [PATCH 8/8] gitk: show modified files with separate work tree
Message-ID: <20110410020318.GB25368@brick.ozlabs.ibm.com>
In-Reply-To: <1301969659-19703-9-git-send-email-martin.von.zweigbergk@gmail.com>

On Mon, Apr 04, 2011 at 10:14:19PM -0400, Martin von Zweigbergk wrote:

> Is the test in proc hasworktree good?

The first parameter to 'if' is evaluated as an expression, so you
don't need the extra exprs.

> Why do git commands that need a work tree not work under .git? Why
> don't they show the same output as if they had been run from the work
> tree? (Btw, the check for valid work tree does not work for aliases,
> so e.g. 'git st', with 'st' as alias for 'status' will show all files
> as deleted.)

Don't know, ask Junio. :)

> How do I simplify the Tcl code to just return the boolean right away?

You can do:

    return [expr {[exec git rev-parse --is-bare-repository] == "false" &&
		  [exec git rev-parse --is-inside-git-dir] == "false"}]

> Why is the hasworktree variable reset in updatecommits? The only reason
> I can think of is when 'core.worktree' is set/changed, but I don't
> think that case worked very well before this series anyway. Should
> gitdir also be recalculated?

I don't know that there's any particularly strong reason to do it in
updatecommits.  It could probably be done once at startup.

Paul.