gitk patch collection pull request

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.

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

Johannes Sixt <j.sixt@viscovery.net> wrote:

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

Shawn O. Pearce schrieb:

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

Johannes Sixt <j.sixt@viscovery.net> wrote:

Picked. Its now in spearce/gitk.

Shawn O. Pearce writes:

OK, but ...

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.

Paul Mackerras <paulus@samba.org> wrote:

...

Done.  I also added this one from Michele:

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

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

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.

Jonathan del Strother writes:

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.

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

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.

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

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.

On Sat, Oct 20, 2007 at 14:00:20 +0100, Jonathan del Strother wrote:

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

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

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

Michele Ballabio writes:

introduces

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.

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

On Saturday 20 October 2007, Paul Mackerras 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

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

On Sat, Oct 20, 2007 at 18:02:47 +0200, Michele Ballabio wrote:

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.

Michele Ballabio writes:

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.

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

Hi,

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

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

On Fri, 19 Oct 2007, Shawn O. Pearce wrote:

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

Linus Torvalds writes:

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.

On Sat, 20 Oct 2007, Paul Mackerras wrote:

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

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

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

Linus Torvalds writes:

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

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.

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

Paul.

On Tue, 23 Oct 2007, Paul Mackerras wrote:

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

Linus Torvalds writes:

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.

On Wed, 24 Oct 2007, Paul Mackerras wrote:

Just the comment.

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

Linus Torvalds writes:

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.