gitk patch collection pull request

gitk patch collection pull request

[Shawn O. Pearce]

The following changes since commit 719c2b9d926bf2be4879015e3620d27d32f007b6:
  Paul Mackerras (1):
        gitk: Fix bug causing undefined variable error when cherry-picking

are available in the git repository at:

  git://repo.or.cz:/git/spearce.git gitk

Jonathan del Strother (2):
      gitk: Added support for OS X mouse wheel
      Fixing gitk indentation

Sam Vilain (1):
      gitk: disable colours when calling git log

 gitk |   16 +++++++++++-----
 1 files changed, 11 insertions(+), 5 deletions(-)


I'm carrying these in my pu branch but would like to move them up
into master.  My gitk branch is actually forked off your own gitk
repository and doesn't contain the git.git history so you should
be able to do a direct pull.

-- 
Shawn.

[PATCH resend again] gitk: Do not pick up file names of "copy from" lines

[Johannes Sixt]

From: Johannes Sixt <johannes.sixt@telecom.at>

A file copy would be detected only if the original file was modified in the
same commit. This implies that there will be a patch listed under the
original file name, and we would expect that clicking the original file
name in the file list warps the patch window to that file's patch. (If the
original file was not modified, the copy would not be detected in the first
place, the copied file would be listed as "new file", and this whole matter
would not apply.)

However, if the name of the copy is sorted after the original file's patch,
then the logic introduced by commit d1cb298b0b (which picks up the link
information from the "copy from" line) would overwrite the link
information that is already present for the original file name, which was
parsed earlier. Hence, this patch reverts part of said commit.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
  Shawn O. Pearce schrieb:
  > I'm carrying these in my pu branch but would like to move them up
  > into master.

  Would you mind putting this one into your queue, too? I haven't seen it
  appear in Paul's repo.

  -- Hannes

  gitk |    3 +--
  1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/gitk b/gitk
index b3ca704..1306382 100755
--- a/gitk
+++ b/gitk
@@ -5216,8 +5216,7 @@ proc getblobdiffline {bdf ids} {
  	    set diffinhdr 0

  	} elseif {$diffinhdr} {
-	    if {![string compare -length 12 "rename from " $line] ||
-		![string compare -length 10 "copy from " $line]} {
+	    if {![string compare -length 12 "rename from " $line]} {
  		set fname [string range $line [expr 6 + [string first " from " $line] ] end]
  		if {[string index $fname 0] eq "\""} {
  		    set fname [lindex $fname 0]
-- 
1.5.3.722.gccbb1

Re: [PATCH resend again] gitk: Do not pick up file names of "copy from" lines

[Shawn O. Pearce]

Johannes Sixt <j.sixt@viscovery.net> wrote:
>  Would you mind putting this one into your queue, too? I haven't seen it
>  appear in Paul's repo.

I think it is already in Paul's repo:

  Applying gitk: Do not pick up file names of "copy from" lines
  error: patch failed: gitk:5216
  error: gitk: patch does not apply
  fatal: sha1 information is lacking or useless (gitk).
  Repository lacks necessary blobs to fall back on 3-way merge.
  Cannot fall back to three-way merge.
  Patch failed at 0001.
  When you have resolved this problem run "git-am -3 --resolved".
  If you would prefer to skip this patch, instead run "git-am -3 --skip".
 
> diff --git a/gitk b/gitk
> index b3ca704..1306382 100755
> --- a/gitk
> +++ b/gitk
> @@ -5216,8 +5216,7 @@ proc getblobdiffline {bdf ids} {
>  	    set diffinhdr 0
> 
>  	} elseif {$diffinhdr} {
> -	    if {![string compare -length 12 "rename from " $line] ||
> -		![string compare -length 10 "copy from " $line]} {
> +	    if {![string compare -length 12 "rename from " $line]} {
>  		set fname [string range $line [expr 6 + [string first " from 
>  		" $line] ] end]
>  		if {[string index $fname 0] eq "\""} {
>  		    set fname [lindex $fname 0]

-- 
Shawn.

Re: [PATCH resend again] gitk: Do not pick up file names of "copy from" lines

[Johannes Sixt]

Shawn O. Pearce schrieb:
> Johannes Sixt <j.sixt@viscovery.net> wrote:
>>  Would you mind putting this one into your queue, too? I haven't seen it
>>  appear in Paul's repo.
> 
> I think it is already in Paul's repo:

No, it's not. I checked both Paul's master and dev, and also your own
gitk branch. Would you mind cherry-picking from the tip of

git://repo.or.cz/git/mingw.git mob

Thanks,
-- Hannes

Re: [PATCH resend again] gitk: Do not pick up file names of "copy from" lines

[Shawn O. Pearce]

Johannes Sixt <j.sixt@viscovery.net> wrote:
> Shawn O. Pearce schrieb:
> >I think it is already in Paul's repo:
> 
> No, it's not. I checked both Paul's master and dev, and also your own
> gitk branch. Would you mind cherry-picking from the tip of
> 
> git://repo.or.cz/git/mingw.git mob

Picked. Its now in spearce/gitk.

-- 
Shawn.

Re: gitk patch collection pull request

[Paul Mackerras]

Shawn O. Pearce writes:

> The following changes since commit 719c2b9d926bf2be4879015e3620d27d32f007b6:
>   Paul Mackerras (1):
>         gitk: Fix bug causing undefined variable error when cherry-picking
> 
> are available in the git repository at:
> 
>   git://repo.or.cz:/git/spearce.git gitk

OK, but ...

> Jonathan del Strother (2):
>       gitk: Added support for OS X mouse wheel
>       Fixing gitk indentation

This one is bogus.  Firstly, it doesn't have "gitk:" at the start of
the headline (and "Fixing" should be "Fix").  Secondly, the actual
change itself is bogus.  It changes an initial tab to 8 spaces on each
of 4 lines.  I like it the way it is - and if he wanted to change it,
he should have changed it throughout the file, not just on 4 lines.
So that change is rejected.

The other changes are OK.  If you could re-do your tree without
0d6df4de (and possible change "Added" to "Add" in e1b5683c while
you're at it), I'll do the pull.

Paul.

Re: gitk patch collection pull request

[Shawn O. Pearce]

Paul Mackerras <paulus@samba.org> wrote:
> Shawn O. Pearce writes:
> > The following changes since commit 719c2b9d926bf2be4879015e3620d27d32f007b6:
> >   Paul Mackerras (1):
> >         gitk: Fix bug causing undefined variable error when cherry-picking
> > 
> > are available in the git repository at:
> > 
> >   git://repo.or.cz:/git/spearce.git gitk
...
> > Jonathan del Strother (2):
> >       gitk: Added support for OS X mouse wheel
> >       Fixing gitk indentation
> 
> This one is bogus.  Firstly, it doesn't have "gitk:" at the start of
> the headline (and "Fixing" should be "Fix").  Secondly, the actual
> change itself is bogus.  It changes an initial tab to 8 spaces on each
> of 4 lines.  I like it the way it is - and if he wanted to change it,
> he should have changed it throughout the file, not just on 4 lines.
> So that change is rejected.
> 
> The other changes are OK.  If you could re-do your tree without
> 0d6df4de (and possible change "Added" to "Add" in e1b5683c while
> you're at it), I'll do the pull.

Done.  I also added this one from Michele:

  From: Michele Ballabio <barra_cuda@katamail.com>
  Subject: [PATCH-resent] gitk: fix in procedure drawcommits

-- 
Shawn.

Re: gitk patch collection pull request

[Jonathan del Strother]

On 19 Oct 2007, at 12:05, Paul Mackerras wrote:

> Shawn O. Pearce writes:
>
>> The following changes since commit  
>> 719c2b9d926bf2be4879015e3620d27d32f007b6:
>>  Paul Mackerras (1):
>>        gitk: Fix bug causing undefined variable error when cherry- 
>> picking
>>
>> are available in the git repository at:
>>
>>  git://repo.or.cz:/git/spearce.git gitk
>
> OK, but ...
>
>> Jonathan del Strother (2):
>>      gitk: Added support for OS X mouse wheel
>>      Fixing gitk indentation
>
> This one is bogus.  Firstly, it doesn't have "gitk:" at the start of
> the headline (and "Fixing" should be "Fix").  Secondly, the actual
> change itself is bogus.  It changes an initial tab to 8 spaces on each
> of 4 lines.  I like it the way it is - and if he wanted to change it,
> he should have changed it throughout the file, not just on 4 lines.
> So that change is rejected.

In my defense, most of that file is space indented, and the places  
that are tab indented are generally totally broken unless you have an  
8 char tab width. It seems to have the whole 'tabs for code  
indentation, with space for alignment' rule back-to-front.  I can't  
follow the logic of that, so didn't feel comfortable changing the  
whole file.  I probably shouldn't have submitted the second patch - I  
initially fixed the weird indentation in my first patch, just so my if- 
block didn't look totally weird, but then was told that ought to be 2  
separate patches.

Re: gitk patch collection pull request

[Paul Mackerras]

Jonathan del Strother writes:

> In my defense, most of that file is space indented, and the places  

Only the lines that are indented 1 level start with spaces.  Any line
that is indented 2 or more levels should start with a tab.

> that are tab indented are generally totally broken unless you have an  
> 8 char tab width.

So set your tabs to 8 spaces when looking at it. :)

> It seems to have the whole 'tabs for code  
> indentation, with space for alignment' rule back-to-front.

I don't recall signing up to that rule. :)  I use 4-column indentation
and 8-column tabs, and my editor (emacs) handles it all automatically
for me.

Paul.

Re: gitk patch collection pull request

[Jonathan del Strother]

On 20 Oct 2007, at 12:46, Paul Mackerras wrote:

> Jonathan del Strother writes:
>
>> In my defense, most of that file is space indented, and the places
>
> Only the lines that are indented 1 level start with spaces.  Any line
> that is indented 2 or more levels should start with a tab.

>> It seems to have the whole 'tabs for code
>> indentation, with space for alignment' rule back-to-front.
>
> I don't recall signing up to that rule. :)  I use 4-column indentation
> and 8-column tabs, and my editor (emacs) handles it all automatically
> for me.


Ugh...  I don't usually get involved in tab/space wars, but I'm  
curious... why on earth would you choose this style?
With space indentation you can make sure that everyone sees the  
indentation as it was intended.  With tab indentation, you save space,  
add semantic meaning, and let people control how wide they want their  
indents to appear.  This approach seems to take the worst parts of  
each and combine them.  What's the benefit?

I appreciate I'm not going to convert you - this is an honest question.

Re: gitk patch collection pull request

[Jan Hudec]

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

On Sat, Oct 20, 2007 at 14:00:20 +0100, Jonathan del Strother wrote:
>
> On 20 Oct 2007, at 12:46, Paul Mackerras wrote:
>
>> Jonathan del Strother writes:
>>
>>> In my defense, most of that file is space indented, and the places
>>
>> Only the lines that are indented 1 level start with spaces.  Any line
>> that is indented 2 or more levels should start with a tab.
>
>>> It seems to have the whole 'tabs for code
>>> indentation, with space for alignment' rule back-to-front.
>>
>> I don't recall signing up to that rule. :)  I use 4-column indentation
>> and 8-column tabs, and my editor (emacs) handles it all automatically
>> for me.
>
>
> Ugh...  I don't usually get involved in tab/space wars, but I'm curious... 
> why on earth would you choose this style?

Because that's default behaviour of both emacs and vi when you set
indentation different from tabstop. Actually most of GNU software, whether it
uses the GNU standard indent of 2, or more, uses tabs for any indents
over 8. Probably even most unix software uses this.

Actually, even if the indent is 8, function arguments are often aligned under
the open parenthesis and a tabs + spaces combination is normally used for
that as well (because, again, that's what most editors will by default do!).

> With space indentation you can make sure that everyone sees the indentation 
> as it was intended.  With tab indentation, you save space, add semantic 
> meaning, and let people control how wide they want their indents to appear. 
>  This approach seems to take the worst parts of each and combine them.  
> What's the benefit?

Tab stops are every 8 characters. No more, no less. Ever. This makes the text
with whatever formating you want the shortest.

> I appreciate I'm not going to convert you - this is an honest question.
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[PATCH-resent] gitk: fix in procedure drawcommits

[Michele Ballabio]

This patch indroduces a check before unsetting an array element.

Without this, gitk may complain with

	can't unset "prevlines(...)": no such element in array

when scrolling happens.

Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---

There's an error that seems to occur in gitk only on
mutt's imported repo, but I don't know why. This is
hopefully the right fix.

An example of this error:

can't unset "prevlines(a3b4383d69e0754346578c85ba8ff7c05bd88705)": no such element in array
can't unset "prevlines(a3b4383d69e0754346578c85ba8ff7c05bd88705)": no such element in array
    while executing
"unset prevlines($lid)"
    (procedure "drawcommits" line 39)
    invoked from within
"drawcommits $row $endrow"
    (procedure "drawfrac" line 10)
    invoked from within
"drawfrac $f0 $f1"
    (procedure "scrollcanv" line 3)
    invoked from within
"scrollcanv .tf.histframe.csb 0.00672513 0.0087015"

 gitk |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/gitk b/gitk
index 300fdce..527b716 100755
--- a/gitk
+++ b/gitk
@@ -3697,7 +3697,9 @@ proc drawcommits {row {endrow {}}} {
 
 	if {[info exists lineends($r)]} {
 	    foreach lid $lineends($r) {
-		unset prevlines($lid)
+		if {[info exists prevlines($lid)]} {
+		    unset prevlines($lid)
+		}
 	    }
 	}
 	set rowids [lindex $rowidlist $r]
-- 
1.5.3

Re: [PATCH-resent] gitk: fix in procedure drawcommits

[Paul Mackerras]

Michele Ballabio writes:

> This patch indroduces a check before unsetting an array element.

introduces

> There's an error that seems to occur in gitk only on
> mutt's imported repo, but I don't know why. This is
> hopefully the right fix.

Well no.  I'd rather understand why this is happening, in case the
error indicates that I'm not handling a corner case correctly.  Can
you make a copy of the repo that triggers the bug available to me?

Paul.

Re: [PATCH-resent] gitk: fix in procedure drawcommits

[Michele Ballabio]

[Rocco Rutte added on CC:, since he wrote the hg-fast-export scripts]

On Saturday 20 October 2007, Paul Mackerras wrote:
> Well no.  I'd rather understand why this is happening, in case the 
> error indicates that I'm not handling a corner case correctly.  Can
> you make a copy of the repo that triggers the bug available to me?

IIRC, I just cloned mutt's hg repo:

  hg clone http://dev.mutt.org/hg/mutt

then imported it in git with the scripts at

  http://repo.or.cz/w/fast-export.git

with

  hg-fast-export.sh -r ../mutt


After that, I've done the usual maintenance repack.

Then, running gitk and keeping pressed pgdown triggers that

	"Error: can't unset..."

window.

Uh-oh. I think I just found the issue. That's probably a bug
somewhere in the import (either fast-export or fast-import or
the original repo, I don't know), so I'm not sure if gitk
should be patched, but since the resulting repo seems correct
as far as git is concerned (i.e. git fsck --full --strict
doesn't complain), I guess something should be done.

Here is the culprit (or so I think). One of the guilty commits is:

	commit a3b4383d69e0754346578c85ba8ff7c05bd88705
	tree 1bf99cd22abe97c59f8c0b7ad6b8244f0854b8af
	parent 6d919fccf603aba995035fa0fb507aa2bd3bf0ae
	parent 6d919fccf603aba995035fa0fb507aa2bd3bf0ae
	author Brendan Cully <brendan@kublai.com> 1179646159 -0700
	committer Brendan Cully <brendan@kublai.com> 1179646159 -0700
	
	    Forget SMTP password if authentication fails.
	    Thanks to Gregory Shapiro for the initial patch (I've moved the reset
	    from smtp_auth_sasl up to smtp_auth, and used the account API
	    instead of twiddling account bits by hand). Closes #2872.

This commit (and many others) has two parents, but the two parents
have the same hash. So gitk tries to unset the same variable twice,
hence the error. At this point, the fix for gitk should be either to
check if the parents have the same hash when reading the commit or
avoiding to unset two times the same variable.

This explanation makes sense to me, now the problem is: have I messed
up the import myself, the scripts/commands used are to blame, or is
it entirely the original repo's fault?

Since I've redone the import and the error remains, I guess
that's not my fault :)

Re: [PATCH-resent] gitk: fix in procedure drawcommits

[Jan Hudec]

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

On Sat, Oct 20, 2007 at 18:02:47 +0200, Michele Ballabio wrote:
> IIRC, I just cloned mutt's hg repo:
>   hg clone http://dev.mutt.org/hg/mutt
> then imported it in git with the scripts at
>   http://repo.or.cz/w/fast-export.git
> with
>   hg-fast-export.sh -r ../mutt
> [...]
> 
> Here is the culprit (or so I think). One of the guilty commits is:
> 
> 	commit a3b4383d69e0754346578c85ba8ff7c05bd88705
> 	tree 1bf99cd22abe97c59f8c0b7ad6b8244f0854b8af
> 	parent 6d919fccf603aba995035fa0fb507aa2bd3bf0ae
> 	parent 6d919fccf603aba995035fa0fb507aa2bd3bf0ae
> 	author Brendan Cully <brendan@kublai.com> 1179646159 -0700
> 	committer Brendan Cully <brendan@kublai.com> 1179646159 -0700
> 	
> 	    Forget SMTP password if authentication fails.
> 	    Thanks to Gregory Shapiro for the initial patch (I've moved the reset
> 	    from smtp_auth_sasl up to smtp_auth, and used the account API
> 	    instead of twiddling account bits by hand). Closes #2872.

Judging from the symptoms, I would suspect hg-fast-export. Either mercurial
sometimes stores two same hashes instead of the hash and 0 (in which case
hg-fast-import should probably be ready to deal with it), or hg-fast-import
does something wrong when it sees the 0 parent.

> This commit (and many others) has two parents, but the two parents
> have the same hash. So gitk tries to unset the same variable twice,
> hence the error. At this point, the fix for gitk should be either to
> check if the parents have the same hash when reading the commit or
> avoiding to unset two times the same variable.
> 
> This explanation makes sense to me, now the problem is: have I messed
> up the import myself, the scripts/commands used are to blame, or is
> it entirely the original repo's fault?
> 
> Since I've redone the import and the error remains, I guess
> that's not my fault :)

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH-resent] gitk: fix in procedure drawcommits

[Paul Mackerras]

Michele Ballabio writes:

> This commit (and many others) has two parents, but the two parents
> have the same hash. So gitk tries to unset the same variable twice,
> hence the error. At this point, the fix for gitk should be either to
> check if the parents have the same hash when reading the commit or
> avoiding to unset two times the same variable.

Actually, there is a commit like that in the kernel tree, and with
this clue, I have managed to reproduce the problem on the kernel tree
with the command

	gitk v2.6.12-rc2..13e652800d1644dfedcd0d59ac95ef0beb7f3165

I have just pushed out a fix to my gitk.git tree.

Paul.

Re: [PATCH-resent] gitk: fix in procedure drawcommits

[Rocco Rutte]

[ No need to Cc: me as I'm on the git list, too ]

Hi,

* Michele Ballabio [07-10-20 18:02:47 +0200] wrote:

>Uh-oh. I think I just found the issue. That's probably a bug
>somewhere in the import (either fast-export or fast-import or
>the original repo, I don't know), so I'm not sure if gitk
>should be patched, but since the resulting repo seems correct
>as far as git is concerned (i.e. git fsck --full --strict
>doesn't complain), I guess something should be done.

>Here is the culprit (or so I think). One of the guilty commits is:

>	commit a3b4383d69e0754346578c85ba8ff7c05bd88705
>	tree 1bf99cd22abe97c59f8c0b7ad6b8244f0854b8af
>	parent 6d919fccf603aba995035fa0fb507aa2bd3bf0ae
>	parent 6d919fccf603aba995035fa0fb507aa2bd3bf0ae
>	author Brendan Cully <brendan@kublai.com> 1179646159 -0700
>	committer Brendan Cully <brendan@kublai.com> 1179646159 -0700

>	    Forget SMTP password if authentication fails.
>	    Thanks to Gregory Shapiro for the initial patch (I've moved the reset
>	    from smtp_auth_sasl up to smtp_auth, and used the account API
>	    instead of twiddling account bits by hand). Closes #2872.

Oh. Yes, this is a bug in the python scripts that get merges quite 
wrong. I didn't notice that earlier as git doesn't complain and the 
contents of the repo turns out as identical.

I'll push fixes (e.g. packed refs support) to the fast-export repo in 
Monday. With these changes, the mutt repo as well hg-crew (which has far 
more merges than the mutt repo) seem to work correctly (no identical 
parents and identical contents).

Thanks for tracking it down.

Still I think fast-import could warn or error out if its gets such 
content which doesn't really make sense...

Rocco

Re: gitk patch collection pull request

[Linus Torvalds]

On Fri, 19 Oct 2007, Shawn O. Pearce wrote:
>
> The following changes since commit 719c2b9d926bf2be4879015e3620d27d32f007b6:
>   Paul Mackerras (1):
>         gitk: Fix bug causing undefined variable error when cherry-picking

The biggest problem I have with gitk is that it is almost totally useless 
for when you have a file limit.

I do "gitk --merge" (which has an implicit file limit of the list 
of unmerged files) or just "gitk ORIG_HEAD.. Makefile" and the *history* 
of gitk looks fine.

But the diffs are crap and useless, because they contain all the stuff I 
did *not* want, and hides all the relevant information.

So then I might use the nice gitk history window to see the commits, but I 
will fall back on "git log -p --merge" and "git log -p ORIG_HEAD.. Makefile"
for the real work. 

I had that happen unusually many times lately, since we had a fair number 
of (mostly trivial) conflicts during this merge window. And it's sad. Gitk 
is so good in so many other ways, and then it is so *totally* useless when 
it comes to something as fundamental as just looking at the history of a 
few files.

			Linus

Re: gitk patch collection pull request

[Paul Mackerras]

Linus Torvalds writes:

> The biggest problem I have with gitk is that it is almost totally useless 
> for when you have a file limit.
> 
> I do "gitk --merge" (which has an implicit file limit of the list 
> of unmerged files) or just "gitk ORIG_HEAD.. Makefile" and the *history* 
> of gitk looks fine.
> 
> But the diffs are crap and useless, because they contain all the stuff I 
> did *not* want, and hides all the relevant information.

Do you mean that when you have a file limit, the diff window should
just show the diffs for those files, not any other files the commit
might have modified?  That would be easy enough to implement in gitk.

Paul.

Re: gitk patch collection pull request

[Linus Torvalds]

On Sat, 20 Oct 2007, Paul Mackerras wrote:
> 
> Do you mean that when you have a file limit, the diff window should
> just show the diffs for those files, not any other files the commit
> might have modified?

Yes. The same way "git log -p" works by default.

With perhaps a checkbox to toggle the "--full-diff" behaviour.

> That would be easy enough to implement in gitk.

Well, the "--merged" case is slightly trickier, since git will figure out 
the pathnames on its own (it limits pathnames to the intersection of the 
names you give one the command line *and* the list of unmerged files, ie 
the "filter" becomes "git ls-files -u [pathspec]".

But goodie. I look forward to it ;)

		Linus

Re: gitk patch collection pull request

[Paul Mackerras]

Linus Torvalds writes:

> On Sat, 20 Oct 2007, Paul Mackerras wrote:
> > 
> > Do you mean that when you have a file limit, the diff window should
> > just show the diffs for those files, not any other files the commit
> > might have modified?
> 
> Yes. The same way "git log -p" works by default.
> 
> With perhaps a checkbox to toggle the "--full-diff" behaviour.

OK, done.  The checkbox is in the Edit/Preferences window.  It's
called "Limit diffs to listed paths" and it's on by default.

> > That would be easy enough to implement in gitk.
> 
> Well, the "--merged" case is slightly trickier, since git will figure out 
> the pathnames on its own (it limits pathnames to the intersection of the 
> names you give one the command line *and* the list of unmerged files, ie 
> the "filter" becomes "git ls-files -u [pathspec]".

If you use the --merge flag, gitk will do a git ls-files -u at
startup, and use the result as the list of paths (after intersecting
it with the paths on the command line, if you specify paths there).

I pondered whether I needed to re-do the git ls-files -u when you
update the view with File->Update.  I decided not to for now, but it
would be possible to add it.

> But goodie. I look forward to it ;)

I just pushed it out to my gitk.git repo (master branch).  Enjoy. :)

Paul.

Re: gitk patch collection pull request

[Linus Torvalds]

On Tue, 23 Oct 2007, Paul Mackerras wrote:
> 
> OK, done.  The checkbox is in the Edit/Preferences window.  It's
> called "Limit diffs to listed paths" and it's on by default.

Ok, the diff looks fine, but now the "list of files" pane on the right is 
empty. 

Even when you limit the diff output, you often have lots of files. At 
least I do, because I often limit by subdirectory. So I'd still like to 
see the file list on the right, so that I can jump to a particular part of 
the diff.

(It would also be nice if it showed the *size* of the changes a'la 
diffstat or something, but that's another and independent issue).

		Linus

Re: gitk patch collection pull request

[Paul Mackerras]

Linus Torvalds writes:

> Ok, the diff looks fine, but now the "list of files" pane on the right is 
> empty. 

Really?  It looks OK here - that is, it lists the names of the files
whose diffs are shown on the left, i.e. the files modified by the
commit that are within the path limit.

Is it completely empty, or does it have just the "Comments" entry at
the top?

Can you give me an example of a gitk command line that shows the
problem on the kernel tree?

Paul.

Re: gitk patch collection pull request

[Linus Torvalds]

On Wed, 24 Oct 2007, Paul Mackerras wrote:
> 
> Is it completely empty, or does it have just the "Comments" entry at
> the top?

Just the comment.

> Can you give me an example of a gitk command line that shows the
> problem on the kernel tree?

Happened for just a random directory I tested. According to my bash 
history, it seems to have been

	gitk v2.6.23.. drivers/char/

which is pretty basic..

		Linus

Re: gitk patch collection pull request

[Paul Mackerras]

Linus Torvalds writes:

> Happened for just a random directory I tested. According to my bash 
> history, it seems to have been
> 
> 	gitk v2.6.23.. drivers/char/

Ahhhh...  It's the slash on the end that does it (it works properly
without the slash).  I just pushed out a fix for that (and a couple of
other bugs I just found).

Paul.