Re: [PATCH 8/8] gitk: show modified files with separate work tree
- From
Paul Mackerras <paulus@samba.org>
- Date
- Apr 10, 2011, 02:03 UTC
- 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.
Show 5 quoted lines
> 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.