All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Mackerras <paulus@samba.org>
To: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH 8/8] gitk: show modified files with separate work tree
Date: Sun, 10 Apr 2011 12:03:18 +1000	[thread overview]
Message-ID: <20110410020318.GB25368@brick.ozlabs.ibm.com> (raw)
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.

  reply	other threads:[~2011-04-10  2:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-05  2:14 [PATCH 0/8] make gitk work better in non-top-level directory Martin von Zweigbergk
2011-04-05  2:14 ` [PATCH 1/8] gitk: fix file highlight when run in subdirectory Martin von Zweigbergk
2011-04-10  1:54   ` Paul Mackerras
2011-04-10 18:03     ` Martin von Zweigbergk
2011-04-05  2:14 ` [PATCH 2/8] gitk: fix "show origin of this line" with separate work tree Martin von Zweigbergk
2011-04-05  2:14 ` [PATCH 3/8] gitk: fix "blame parent commit" " Martin von Zweigbergk
2011-04-05  2:14 ` [PATCH 4/8] gitk: fix "External diff" " Martin von Zweigbergk
2011-04-05  2:14 ` [PATCH 5/8] gitk: put temporary directory inside .git Martin von Zweigbergk
2011-04-05  2:14 ` [PATCH 6/8] gitk: run 'git rev-parse --git-dir' only once Martin von Zweigbergk
2011-04-05  2:14 ` [PATCH 7/8] gitk: simplify calculation of gitdir Martin von Zweigbergk
2011-04-05  2:14 ` [PATCH 8/8] gitk: show modified files with separate work tree Martin von Zweigbergk
2011-04-10  2:03   ` Paul Mackerras [this message]
2011-04-11 19:15     ` Junio C Hamano
2011-05-24  2:44   ` [PATCH v2 " Martin von Zweigbergk
2011-04-05 18:48 ` [PATCH 0/8] make gitk work better in non-top-level directory Peter Baumann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110410020318.GB25368@brick.ozlabs.ibm.com \
    --to=paulus@samba.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=martin.von.zweigbergk@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.