From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:43:43
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.
From: Johannes Sixt <hidden> Date: 2016-06-15 22:43:43
From: Johannes Sixt <redacted>
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 <redacted>
---
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(-)
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:43:43
Johannes Sixt [off-list ref] 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".
From: Johannes Sixt <hidden> Date: 2016-06-15 22:43:43
Shawn O. Pearce schrieb:
Johannes Sixt [off-list ref] wrote:
quoted
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
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:43:43
Johannes Sixt [off-list ref] wrote:
Shawn O. Pearce schrieb:
quoted
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
From: Paul Mackerras <hidden> Date: 2016-06-15 22:43:43
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.
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 <redacted>
---
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(-)
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
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:43:43
Paul Mackerras [off-list ref] wrote:
Shawn O. Pearce writes:
quoted
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
...
quoted
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 [off-list ref]
Subject: [PATCH-resent] gitk: fix in procedure drawcommits
--
Shawn.
From: Paul Mackerras <hidden> Date: 2016-06-15 22:43:43
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.
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
From: Paul Mackerras <hidden> Date: 2016-06-15 22:43:43
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.
From: Jonathan del Strother <hidden> Date: 2016-06-15 22:43:43
On 19 Oct 2007, at 12:05, Paul Mackerras wrote:
Shawn O. Pearce writes:
quoted
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 ...
quoted
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.
From: Paul Mackerras <hidden> Date: 2016-06-15 22:43:43
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.
From: Jonathan del Strother <hidden> Date: 2016-06-15 22:43:43
On 20 Oct 2007, at 12:46, Paul Mackerras wrote:
Jonathan del Strother writes:
quoted
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.
quoted
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.
From: Jan Hudec <hidden> Date: 2016-06-15 22:43:43
On Sat, Oct 20, 2007 at 14:00:20 +0100, Jonathan del Strother wrote:
On 20 Oct 2007, at 12:46, Paul Mackerras wrote:
quoted
Jonathan del Strother writes:
quoted
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.
quoted
quoted
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
[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 [off-list ref] 1179646159 -0700
committer Brendan Cully [off-list ref] 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 :)
From: Jan Hudec <hidden> Date: 2016-06-15 22:43:43
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 [off-list ref] 1179646159 -0700
committer Brendan Cully [off-list ref] 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 :)
From: Paul Mackerras <hidden> Date: 2016-06-15 22:43:43
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.
[ 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:
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
From: Paul Mackerras <hidden> Date: 2016-06-15 22:43:44
Linus Torvalds writes:
On Sat, 20 Oct 2007, Paul Mackerras wrote:
quoted
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.
quoted
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.
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
From: Paul Mackerras <hidden> Date: 2016-06-15 22:43:44
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.
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
From: Paul Mackerras <hidden> Date: 2016-06-15 22:43:44
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.