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 1/8] gitk: fix file highlight when run in subdirectory
Date: Sun, 10 Apr 2011 11:54:10 +1000	[thread overview]
Message-ID: <20110410015410.GA25368@brick.ozlabs.ibm.com> (raw)
In-Reply-To: <1301969659-19703-2-git-send-email-martin.von.zweigbergk@gmail.com>

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

> The "highlight this only" and "highlight this too" commands in gitk
> add the path relative to $GIT_WORK_TREE to the "Find" input box. When
> the search (using git-diff-tree) is run, the paths are used
> unmodified, except for some shell escaping. Since the search is run
> from gitk's working directory, no commits matching the paths will be
> found if gitk was started in a subdirectory.
> 
> Make the paths passed to git-diff-tree relative to gitk's working
> directory instead of being relative to $GIT_WORK_TREE. If, however,
> gitk is run outside of the working directory (e.g. with $GIT_WORK_TREE
> set), we still need to use the path relative to $GIT_WORK_TREE.
> 
> Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
> ---
> 
> This could also have been fixed by cd-ing to the work tree
> directory. That would also make the "Local changes checked in to index
> but not committed" and "Local uncommitted changes, not checked in to
> index" show up properly when running with GIT_WORK_TREE defined.
> 
> I wasn't sure if other parts of gitk depend on the working directory,
> or if there are plans to make something depend on it, so I thought
> changing it only for the specific case of file highlighting would be
> safer. What do you think?

I have to admit I wasn't aware of GIT_WORK_TREE before I saw your
patches.  The patches look OK, but I wonder how many of the problems
would go away if gitk were simply to set GIT_WORK_TREE in the
environment for the programs it runs, if it is not already set.
Something like this (untested):

 # check that we can find a .git directory somewhere...
 if {[catch {set gitdir [gitdir]}]} {
     show_error {} . [mc "Cannot find a git repository here."]
     exit 1
 }
 if {![file isdirectory $gitdir]} {
     show_error {} . [mc "Cannot find the git directory \"%s\"." $gitdir]
     exit 1
 }
+if {![info exists env(GIT_WORK_TREE)]} {
+    set worktree [file dirname $gitdir]
+    if {$worktree ne "."} {
+	set env(GIT_WORK_TREE) $worktree
+    }
+}

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 [this message]
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
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=20110410015410.GA25368@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.