threads / patch / 29150

patchgitk: fix the display of files when filtered by path

Subject: [PATCH] gitk: fix the display of files when filtered by path

## tl;dr

12 messages between Dec 13, 2011 and Mar 18, 2012. Diffs are folded; open one to read it.

replies: 11people: 7as markdown or json

Pat Thoyts· Dec 13, 2011, 16:50 UTC · lore

Launching 'gitk -- .' or 'gitk -- ..\t' restricts the display to files under the given directory but the file list is left empty. This is because the path_filter function fails to match the filenames which are relative to the working tree to the filter which is filessytem relative. This solves the problem by making both names fully qualified filesystem paths before performing the comparison.

Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
---
 gitk-git/gitk |   38 +++++++++++++++++++++++++++-----------
 1 files changed, 27 insertions(+), 11 deletions(-)
Show changes to gitk-git/gitk +27 −11
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 2a92e20..b728345 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -18,6 +18,26 @@ proc gitdir {} {
     }
 }
 
+proc gitworktree {} {
+    variable _gitworktree
+    if {[info exists _gitworktree]} {
+	return $_gitworktree
+    }
+    # v1.7.0 introduced --show-toplevel to return the canonical work-tree
+    if {[catch {set _gitworktree [exec git rev-parse --show-toplevel]}]} {
+        # try to set work tree from environment, core.worktree or use
+        # cdup to obtain a relative path to the top of the worktree. If
+        # run from the top, the ./ prefix ensures normalize expands pwd.
+        if {[catch { set _gitworktree $env(GIT_WORK_TREE) }]} {
+	    catch {set _gitworktree [exec git config --get core.worktree]}
+	    if {$_gitworktree eq ""} {
+		set _gitworktree [file normalize ./[exec git rev-parse --show-cdup]]
+	    }
+        }
+    }
+    return $_gitworktree
+}
+
 # A simple scheduler for compute-intensive stuff.
 # The aim is to make sure that event handlers for GUI actions can
 # run at least every 50-100 ms.  Unfortunately fileevent handlers are
@@ -7376,19 +7396,15 @@ proc startdiff {ids} {
     }
 }
 
+# If the filename (name) is under any of the passed filter paths
+# then return true to include the file in the listing.
 proc path_filter {filter name} {
+    set worktree [gitworktree]
     foreach p $filter {
-	set l [string length $p]
-	if {[string index $p end] eq "/"} {
-	    if {[string compare -length $l $p $name] == 0} {
-		return 1
-	    }
-	} else {
-	    if {[string compare -length $l $p $name] == 0 &&
-		([string length $name] == $l ||
-		 [string index $name $l] eq "/")} {
-		return 1
-	    }
+	set fq_p [file normalize $p]
+	set fq_n [file normalize [file join $worktree $name]]
+	if {[string match [file normalize $fq_p]* $fq_n]} {
+	    return 1
 	}
     }
     return 0
-- 
1.7.8.msysgit.0
David Aguilar· Dec 15, 2011, 04:18 UTC · re: Pat Thoyts · lore

Re: [msysGit] [PATCH] gitk: fix the display of files when filtered by path

On Tue, Dec 13, 2011 at 8:50 AM, Pat Thoyts <patthoyts@users.sourceforge.net> wrote:

Show 8 quoted lines
> Launching 'gitk -- .' or 'gitk -- ..\t' restricts the display to files
> under the given directory but the file list is left empty. This is because
> the path_filter function fails to match the filenames which are relative
> to the working tree to the filter which is filessytem relative.
> This solves the problem by making both names fully qualified filesystem
> paths before performing the comparison.
>
> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Wonderful!

I've run into this problem a number of times (as have some co-workers) but I never bothered to report it since I felt guilty for never having worked up a patch.

I tested this and it worked.
FWIW,
Tested-by: David Aguilar <davvid@gmail.com>
Thank you Pat!
-- 
            David
Johannes Schindelin· Dec 15, 2011, 09:24 UTC · re: David Aguilar · lore

Re: [msysGit] [PATCH] gitk: fix the display of files when filtered by path

Hi,
On Wed, 14 Dec 2011, David Aguilar wrote:
Show 12 quoted lines
> On Tue, Dec 13, 2011 at 8:50 AM, Pat Thoyts
> <patthoyts@users.sourceforge.net> wrote:
> > Launching 'gitk -- .' or 'gitk -- ..\t' restricts the display to files
> > under the given directory but the file list is left empty. This is because
> > the path_filter function fails to match the filenames which are relative
> > to the working tree to the filter which is filessytem relative.
> > This solves the problem by making both names fully qualified filesystem
> > paths before performing the comparison.
> >
> > Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
> 
> Wonderful!
Thanks for reminding me that I did not yet apply and push. Did so now.

Thanks, Pat, for fixing this bug! Dscho

Martin von Zweigbergk· Dec 15, 2011, 19:42 UTC · re: Johannes Schindelin · lore

Re: [msysGit] [PATCH] gitk: fix the display of files when filtered by path

Hi,

On Thu, Dec 15, 2011 at 1:24 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 12 quoted lines
> Hi,
>
> On Wed, 14 Dec 2011, David Aguilar wrote:
>
>> On Tue, Dec 13, 2011 at 8:50 AM, Pat Thoyts
>> <patthoyts@users.sourceforge.net> wrote:
>> > Launching 'gitk -- .' or 'gitk -- ..\t' restricts the display to files
>> > under the given directory but the file list is left empty. This is because
>> > the path_filter function fails to match the filenames which are relative
>> > to the working tree to the filter which is filessytem relative.
>> > This solves the problem by making both names fully qualified filesystem
>> > paths before performing the comparison.

How is this related to my patches from April? See http://thread.gmane.org/gmane.comp.version-control.git/170853. It's clearly not the same problem, but will the patches conflict? Will some of mine be unnecessary?

> Thanks for reminding me that I did not yet apply and push. Did so now.

What do you mean by this? Push to where? git://git.kernel.org/pub/scm/gitk/gitk.git is still down.

Paul and Junio, the patches I sent in April are still not in git.git, are they? Can we use another repo until the kernel.org one is up? More than eight months to get a patch (or eight) merged is way too long, IMO.

Martin
Junio C Hamano· Dec 15, 2011, 19:50 UTC · re: Martin von Zweigbergk · lore

Re: [msysGit] [PATCH] gitk: fix the display of files when filtered by path

Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
> Paul and Junio, the patches I sent in April are still not in git.git,
> are they? Can we use another repo until the kernel.org one is up? More
> than eight months to get a patch (or eight) merged is way too long,
> IMO.
I tend to agree.

I have this slight suspicion that Paul would appreciate if somebody who cares about gitk who is capable and willing steps forward and takes over the maintainership of gitk, as he is busy in his other projects.

Pat Thoyts· Dec 15, 2011, 22:06 UTC · re: Junio C Hamano · lore

Re: [msysGit] [PATCH] gitk: fix the display of files when filtered by path

Junio C Hamano <gitster@pobox.com> writes:
Show 12 quoted lines
>Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
>
>> Paul and Junio, the patches I sent in April are still not in git.git,
>> are they? Can we use another repo until the kernel.org one is up? More
>> than eight months to get a patch (or eight) merged is way too long,
>> IMO.
>
>I tend to agree.
>
>I have this slight suspicion that Paul would appreciate if somebody who
>cares about gitk who is capable and willing steps forward and takes over
>the maintainership of gitk, as he is busy in his other projects.
I can do this one along with git-gui if this is the case.
-- 
Pat Thoyts                            http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97  10 CE 11 E6 04 E0 B9 DD
Jakub Narebski· Dec 16, 2011, 22:27 UTC · re: Pat Thoyts · lore

Re: [msysGit] [PATCH] gitk: fix the display of files when filtered by path

Pat Thoyts <patthoyts@users.sourceforge.net> writes:
> Junio C Hamano <gitster@pobox.com> writes:
Show 5 quoted lines
>> I have this slight suspicion that Paul would appreciate if somebody who
>> cares about gitk who is capable and willing steps forward and takes over
>> the maintainership of gitk, as he is busy in his other projects.
> 
> I can do this one along with git-gui if this is the case.

I wonder if having common maintainer for both gitk and git-gui would lead to first, splitting gitk into smaller files like git-gui was, and second sharing common Tcl/Tk bindings / wrappers between gitk and git-gui...

-- 
Jakub Narębski
Paul Mackerras· Dec 15, 2011, 23:01 UTC · re: Junio C Hamano · lore

Re: [msysGit] [PATCH] gitk: fix the display of files when filtered by path

On Thu, Dec 15, 2011 at 11:50:53AM -0800, Junio C Hamano wrote:
Show 12 quoted lines
> Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
> 
> > Paul and Junio, the patches I sent in April are still not in git.git,
> > are they? Can we use another repo until the kernel.org one is up? More
> > than eight months to get a patch (or eight) merged is way too long,
> > IMO.
> 
> I tend to agree.
> 
> I have this slight suspicion that Paul would appreciate if somebody who
> cares about gitk who is capable and willing steps forward and takes over
> the maintainership of gitk, as he is busy in his other projects.
Indeed.  For now I have put up a repository on ozlabs.org:
git://ozlabs.org/~paulus/gitk.git

but if someone wants to take on the gitk maintainership, please let me know.

Paul.
Pat Thoyts· Dec 15, 2011, 21:33 UTC · re: Martin von Zweigbergk · lore

Re: [msysGit] [PATCH] gitk: fix the display of files when filtered by path

Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
[resending as my earlier post got bounced from vger]
Show 27 quoted lines
>Hi,
>
>On Thu, Dec 15, 2011 at 1:24 AM, Johannes Schindelin
><Johannes.Schindelin@gmx.de> wrote:
>> Hi,
>>
>> On Wed, 14 Dec 2011, David Aguilar wrote:
>>
>>> On Tue, Dec 13, 2011 at 8:50 AM, Pat Thoyts
>>> <patthoyts@users.sourceforge.net> wrote:
>>> > Launching 'gitk -- .' or 'gitk -- ..\t' restricts the display to files
>>> > under the given directory but the file list is left empty. This is because
>>> > the path_filter function fails to match the filenames which are relative
>>> > to the working tree to the filter which is filessytem relative.
>>> > This solves the problem by making both names fully qualified filesystem
>>> > paths before performing the comparison.
>
>How is this related to my patches from April? See
>http://thread.gmane.org/gmane.comp.version-control.git/170853. It's
>clearly not the same problem, but will the patches conflict? Will some
>of mine be unnecessary?
>
>> Thanks for reminding me that I did not yet apply and push. Did so now.
>
>What do you mean by this? Push to where?
>git://git.kernel.org/pub/scm/gitk/gitk.git is still down.
>
This is for msysGit.
>Paul and Junio, the patches I sent in April are still not in git.git,
>are they? Can we use another repo until the kernel.org one is up? More
>than eight months to get a patch (or eight) merged is way too long,
>IMO.

I'm not sure how this might relate to your patches. I've got a version merged on top of the last version of the gitk report that I have which includes those and it seems fine. As stated I did this work against git-core as the gitk repository continues to be unavailable. However as I have a pretty current snapshot I have pushed this to github to provide some visibility of things I know are not present within git-core. See http://github.com/patthoyts/gitk.git

-- 
Pat Thoyts                            http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97  10 CE 11 E6 04 E0 B9 DD
Paul Mackerras· Dec 15, 2011, 22:59 UTC · re: Martin von Zweigbergk · lore

Re: [msysGit] [PATCH] gitk: fix the display of files when filtered by path

On Thu, Dec 15, 2011 at 11:42:38AM -0800, Martin von Zweigbergk wrote:
> git://git.kernel.org/pub/scm/gitk/gitk.git is still down.

I have just created a repository on ozlabs.org for gitk, since I don't have kernel.org access at this point. The repository is:

git://ozlabs.org/~paulus/gitk.git
> Paul and Junio, the patches I sent in April are still not in git.git,
> are they? Can we use another repo until the kernel.org one is up? More
> than eight months to get a patch (or eight) merged is way too long,
> IMO.

Your patches are in the master branch. I applied them back in July but then kernel.org went down.

Paul.
Junio C Hamano· Dec 17, 2011, 06:31 UTC · re: Paul Mackerras · lore

Re: [msysGit] [PATCH] gitk: fix the display of files when filtered by path

Paul Mackerras <paulus@samba.org> writes:
Show 11 quoted lines
> On Thu, Dec 15, 2011 at 11:42:38AM -0800, Martin von Zweigbergk wrote:
>
>> git://git.kernel.org/pub/scm/gitk/gitk.git is still down.
>
> I have just created a repository on ozlabs.org for gitk, since I don't
> have kernel.org access at this point.  The repository is:
>
> git://ozlabs.org/~paulus/gitk.git
> ...
> Your patches are in the master branch.  I applied them back in July
> but then kernel.org went down.
Thanks.

All pulled and resulted in one liner update to the draft Release Notes for the next release.

Show changes to Documentation/RelNotes/1.7.9.txt +2 −0
diff --git a/Documentation/RelNotes/1.7.9.txt b/Documentation/RelNotes/1.7.9.txt
index cd3c256..f476667 100644
--- a/Documentation/RelNotes/1.7.9.txt
+++ b/Documentation/RelNotes/1.7.9.txt
@@ -4,6 +4,8 @@ Git v1.7.9 Release Notes (draft)
 Updates since v1.7.8
 --------------------
 
+ * Accumulated gitk updates since early this year.
+
  * git-gui updated to 0.16.0.
 
  * git-p4 (in contrib/) updates.
Paul Mackerras· Mar 18, 2012, 23:11 UTC · re: Pat Thoyts · lore

Re: [PATCH] gitk: fix the display of files when filtered by path

On Tue, Dec 13, 2011 at 04:50:50PM +0000, Pat Thoyts wrote:
Show 8 quoted lines
> Launching 'gitk -- .' or 'gitk -- ..\t' restricts the display to files
> under the given directory but the file list is left empty. This is because
> the path_filter function fails to match the filenames which are relative
> to the working tree to the filter which is filessytem relative.
> This solves the problem by making both names fully qualified filesystem
> paths before performing the comparison.
> 
> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Thanks, applied.
Paul.

← back to recent threads