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

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

[Pat Thoyts]

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(-)

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

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

[David Aguilar]

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!

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

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

[Johannes Schindelin]

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.
> >
> > 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

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

[Martin von Zweigbergk]

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.

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

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

[Junio C Hamano]

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.

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

[Pat Thoyts]

[-- Attachment #1: Type: text/plain, Size: 2034 bytes --]

On Dec 15, 2011 8:01 PM, "Martin von Zweigbergk" <
martin.von.zweigbergk@gmail.com> wrote:
>
> 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 about msysgit as I also posted this there.

> 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

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
On Dec 15, 2011 8:01 PM, "Martin von Zweigbergk" <
martin.von.zweigbergk@gmail.com> wrote:

[-- Attachment #2: Type: text/html, Size: 2962 bytes --]

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

[Pat Thoyts]

Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:

[resending as my earlier post got bounced from vger]

>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

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

[Pat Thoyts]

Junio C Hamano <gitster@pobox.com> writes:

>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

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

[Paul Mackerras]

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.

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

[Paul Mackerras]

On Thu, Dec 15, 2011 at 11:50:53AM -0800, Junio C Hamano wrote:
> 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.

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

[Jakub Narebski]

Pat Thoyts <patthoyts@users.sourceforge.net> writes:
> Junio C Hamano <gitster@pobox.com> writes:

>> 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

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

[Junio C Hamano]

Paul Mackerras <paulus@samba.org> writes:

> 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.

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.

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

[Paul Mackerras]

On Tue, Dec 13, 2011 at 04:50:50PM +0000, Pat Thoyts 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>

Thanks, applied.

Paul.