From: Paul Mackerras <hidden> Date: 2016-06-15 22:42:03
I have reworked the way gitk displays merges. Previously it would
display all the diffs between the child and each parent. That
displayed a lot of unnecessary stuff; for example, for the famous
octopus (pentapus?) merge, each diff was shown 4 times. It also shows
diffs when the merge is perfectly straightforward, i.e. when any given
file has been modified in at most one of the parents, and the child's
version is the same as the parent's.
Now gitk will only list a file as having a difference in a merge if
one or more of the parents has a version of the file that is different
both from the child and from the common ancestor of the parents (if a
common ancestor exists). If there is no common ancestor, then a file
is listed if it is different in the child from all of the parents.
I now also display the diffs for a file in one unified difference
listing. Lines are color-coded according to which parent they come
from, and are in bold with a + at the start of the line if they ended
up in the merge result (the child), or in normal font with a - at the
start of the line if they didn't. In the usual case of two parents,
lines from the first parent are in red and lines from the second
parent are in blue. Lines in the result that don't correspond to
either parent are in bold black.
Linus, could you do a pull from the usual place to pick this up?
(rsync://rsync.kernel.org/pub/scm/gitk/gitk.git). I also included a
patch from Junio.
Paul.
On Fri, 29 Jul 2005 20:51:40 -0500 Paul Mackerras wrote:
I have reworked the way gitk displays merges.
I have found a reproducible bug in gitk which seems to be in that new
code for merges. Run
gitk f4b3a4c30b5ea3a5de2a2597a3c53266017d02ba
on the git or cogito repository (that commit is from 2005-07-05), then
click the topmost commit ("Merge with Linus' current tree"), then click
it again - you get an error popup with this trace:
can't read "filelines(f13bbe7f56e49a11f6bfc3b73a463c741f969c9c,0,137)": no such element in array
can't read "filelines(f13bbe7f56e49a11f6bfc3b73a463c741f969c9c,0,137)": no such element in array
while executing
"$ctext insert end "-$filelines($p,$f,$ol)\n" m$pnum"
(procedure "processgroup" line 143)
invoked from within
"processgroup"
(procedure "processhunks" line 47)
invoked from within
"processhunks"
(procedure "getmergediffline" line 81)
invoked from within
"getmergediffline file10 {f4b3a4c30b5ea3a5de2a2597a3c53266017d02ba f13bbe7f56e49a11f6bfc3b73a463c741f969c9c} f4b3a4c30b5ea3a5de2a2597a3c53266017d02ba"
Another badness which appears with the same repository: run
gitk f13bbe7f56e49a11f6bfc3b73a463c741f969c9c
then repeated clicks on the topmost commit result in a different diff
shown (no error popups, however).
Also if I quickly move between commits, sometimes I get error popups
like:
can't unset "treepending": no such variable
while executing
"unset treepending"
(procedure "gettreediffline" line 9)
invoked from within
"gettreediffline file30 {429a9358763dfb98cd063e40dc49cbc049e2a268 154d3d2dd2656c23ea04e9d1c6dd4e576a7af6de}"
This error does not happen again if the same commit is selected.
All this happens both with current cogito
(134b78a167b5f77725cd8435849de7298b6de477) and git
(9e44f8980b8f41fbeea0a68035865e5778e4dc7d).
Ok, goodie. It works fine in my environment, with most merges showing up
as not interesting. But a merge like
3e0777b8fa96f7073ed5d13d3bc1d573b766bef9
shows an example of where there was actually both real content merges, and
some real clashes.
However, most of the content merges were trivial, and they often hide the
real clashes. For example, if you click on that merge, a _lot_ of it looks
like it might be clashes, even though most of it was auto-merged. This is
not really a problem, but I get the feeling that it could be improved
somehow - maybe a button that hides the parts that don't have clashes?
In the usual case of two parents, lines from the first parent are in red
and lines from the second parent are in blue. Lines in the result that
don't correspond to either parent are in bold black.
To get the alternate output, maybe something like:
- run "merge" on the original/parent1/parent2 (the same way the
git-merge-one-file-script does)
- anything that merged fine is in black (regardless of which parent it
came from), and then mark the merge rejects are in red/blue depending
on parent?
I don't know how doable that would be.
Linus
[ Also Kay Sievers, because the clickability thing sounds like a
potentially good thing for webgit too.. ]
For 2.6.13 we've been reverting some stuff lately, to make sure we get a
stable release. That's fine, and when I revert something I try to mention
the commit ID of the thing I revert in the message. Apparently others do
too, as indicated by a patch I just got from Petr Vandovec. So we've got
for example:
889371f61fd5bb914d0331268f12432590cf7e85:
Author: Linus Torvalds [off-list ref] 2005-07-30 13:41:56
Committer: Linus Torvalds [off-list ref] 2005-07-30 13:41:56
Revert "yenta free_irq on suspend"
ACPI is wrong. Devices should not release their IRQ's on suspend and
re-aquire them on resume. ACPI should just re-init the IRQ controller
instead of breaking most drivers very subtly.
Breakage reported by Hugh Dickins [off-list ref]
Undo: d8c4b4195c7d664baf296818bf756775149232d3
Signed-off-by: Linus Torvalds [off-list ref]
and
403fe5ae57c831968c3dbbaba291ae825a1c5aaa:
Author: Petr Vandrovec [off-list ref] 2005-08-05 06:50:07
Committer: Linus Torvalds [off-list ref] 2005-08-05 06:57:44
[PATCH] rtc: msleep() cannot be used from interrupt
Since the beginning of July my Opteron box was randomly crashing and
being rebooted by hardware watchdog. Today it finally did it in front
of me, and this patch will hopefully fix it.
The problem is that at the end of June (the 28th, to be exact: commit
47f176fdaf8924bc83fddcf9658f2fd3ef60d573, "[PATCH] Using msleep()
instead of HZ") rtc_get_rtc_time ...
and when I use gitk, it would be just too damn cool for words if I could
easily follow the SHA1's mentioned in the commit message.
I can just cut-and-paste the SHA1, and I've verified that it works fine.
However, as you'v enoticed, I'm of the whiny kind, and I thought it could
be easier. So I'm whining again.
<whine>Mommy, mommy, can you make my life easier</whine>
So I noticed that I really would like two things:
- "clickable" SHA1's in commit messages would be really really cool if
something like that is even possible with tcl/tk.
Now, if you can highlight them when showing the message, that would be
extra cool, but even without any highlighing, the thing actually
_almost_ works fine already: you can double-click the SHA1, and it will
select it. You then have to move the mouse to the "goto" window, and
paste in the SHA1 there. And this is where it would be good if this
sequence could be simplified a bit.
Even if it's something as simple as accepting the SHA1 paste into the
same window (not having to go to the "goto" window: just double-click
on the SHA1, and then right-click to "paste it back").
- I'd like to have a "back button". Not just for the above kind of thing,
but in general too: when searching for something, it would just be very
nice if gitk just kept a list of the <n> last commits that have
been selected, and there was a web-browser-like button that went
back/forward in history.
But especially when looking at a revert, I just want to first go to the
thing we revert, see what's going on there (get the "historical
perspective" - commit log for why the original was done etc), and then
I'd want to go back (and possibly forth and back again ;). And while
the revert mentioned the thing it reverted (so I could cut-and-paste),
the thing it reverted obviously does _not_ mention the thing that
reverted it, so now I have to manually just scroll back.
This same thing happens for a failed search (I search for xyz, and it
actually finds it, and I realize that that was the wrong search, but
now I'm two months back..)
<whine>Mommy, mommy, pleeeease</whine>
Linus
On Fri, Aug 05, 2005 at 07:37:41AM -0700, Linus Torvalds wrote:
For 2.6.13 we've been reverting some stuff lately, to make sure we get a
stable release. That's fine, and when I revert something I try to mention
the commit ID of the thing I revert in the message. Apparently others do
too, as indicated by a patch I just got from Petr Vandovec. So we've got
for example:
[snipped]
The following code worked for me on a toy commit. I'm not sure the regular
expression in linkcommits is right if the SHA1 is followed by a colon or a comma,
as I noticed it was in your examples. If it doesn, then removing the [[:<:]]
and [[:>:]] will probably fix it.
Things that look like SHA1s are highlighted even if they don't actually exist.
There is probably a "more right" place to do the '$ctext tag bind Commit' commands
but I didn't find it right away.
diff --git a/gitk b/gitk--- a/gitk+++ b/gitk
@@ -1753,6 +1753,11 @@ proc selectline {l} { $ctext conf -state disabled set commentend [$ctext index "end - 1c"]+ linkcommits $ctext 0.0 $commentend+ $ctext tag configure Commit -underline yes -foreground blue+ $ctext tag bind Commit <Enter> { %W configure -cursor hand2 }+ $ctext tag bind Commit <Leave> { %W configure -cursor {} }+ $ctext tag bind Commit <Button-1><ButtonRelease-1> { linkclick %W %x %y } $cflist delete 0 end $cflist insert end "Comments" if {$nparents($id) == 1} {
@@ -1762,6 +1767,30 @@ proc selectline {l} { } }+proc linkclick {w x y} {+ set index [$w index @$x,$y]+ set tags [$w tag names $index]+ foreach c $tags {+ if {![string match {C_*} $c]} { continue; }+ global sha1string+ set sha1string [string range $c 2 end]+ gotocommit+ }+}++proc linkcommits {w start end} {+ while {1} {+ set pos [$w search -regexp {[[:<:]][0-9a-fA-F]{40}[[:>:]]} $start $end]+ if {$pos == {}} {break}++ set commit [$w get $pos "$pos+40c"]++ $w tag add Commit $pos "$pos+40c"+ $w tag add C_$commit $pos "$pos+40c"+ set start [$w index "$pos+40c"]+ }+}+ proc selnextline {dir} { global selectedline if {![info exists selectedline]} return
From: Kay Sievers <hidden> Date: 2016-06-15 22:42:03
On Fri, Aug 05, 2005 at 07:37:41AM -0700, Linus Torvalds wrote:
[ Also Kay Sievers, because the clickability thing sounds like a
potentially good thing for webgit too.. ]
...
For 2.6.13 we've been reverting some stuff lately, to make sure we get a
stable release. That's fine, and when I revert something I try to mention
the commit ID of the thing I revert in the message. Apparently others do
too, as indicated by a patch I just got from Petr Vandovec. So we've got
for example:
Undo: d8c4b4195c7d664baf296818bf756775149232d3
Signed-off-by: Linus Torvalds [off-list ref]
...
and when I use gitk, it would be just too damn cool for words if I could
easily follow the SHA1's mentioned in the commit message.
From: Paul Mackerras <hidden> Date: 2016-06-15 22:42:03
Linus Torvalds writes:
- "clickable" SHA1's in commit messages would be really really cool if
something like that is even possible with tcl/tk.
Done, and it was even pretty easy. It took only about a dozen lines.
- I'd like to have a "back button". Not just for the above kind of thing,
but in general too: when searching for something, it would just be very
nice if gitk just kept a list of the <n> last commits that have
been selected, and there was a web-browser-like button that went
back/forward in history.
Good idea. Also done. :) It's on master.kernel.org now in my gitk.git
directory. Hopefully Junio will pull it into git soon. The current
version also squishes the graph horizontally if it gets too wide
(i.e. more than half the width of the top-left pane).
Paul.
Goodie. Although when I looked at it first, it wasn't obvious - the link
is same font, same color as the rest. Maybe make them stand out a _bit_
more?
But yes, works well. Thanks,
Linus
- "clickable" SHA1's in commit messages would be really really cool if
something like that is even possible with tcl/tk.
Done, and it was even pretty easy. It took only about a dozen lines.
Looks good also. I assume the mouse can't change when it hovers?
Good idea. Also done. :) It's on master.kernel.org now in my gitk.git
directory. Hopefully Junio will pull it into git soon. The current
version also squishes the graph horizontally if it gets too wide
(i.e. more than half the width of the top-left pane).
Yeah, that looks weird when the lines start turning soft ans squiggly.
Linus
On Sat, Aug 06, 2005 at 09:20:16AM -0700, Linus Torvalds wrote:
Looks good also. I assume the mouse can't change when it hovers?
In gitk? This is be possible. My patch[1] does it. The way it's done stinks a
little bit, though. <Enter> and <Leave> are bound on a tag common to all the
"hyperlinks", and change the -cursor of the whole widget---either to hand2 or
the empty string.
+ $ctext tag bind Commit <Enter> { %W configure -cursor hand2 }
+ $ctext tag bind Commit <Leave> { %W configure -cursor {} }
My patch also underlines links, as requested in a different message in this thread.
+ $ctext tag configure Commit -underline yes -foreground blue
Jeff
[1] http://www.gelato.unsw.edu.au/archives/git/0508/7253.html
This makes the cursor change when you hover over a SHA1 link with the new
"hypertext" gitk commit ID linking feature.
All credit goes to Jeff Epler [off-list ref] and bugs are mine.
I don't actually know any tcl/tk, I'm just acting as a random monkey that
looks at what others do and mix it up.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
----
diff --git a/gitk b/gitk--- a/gitk+++ b/gitk
@@ -1802,10 +1802,13 @@ proc selectline {l isnew} { set linkid [string range $comment $s $e] if {![info exists idline($linkid)]} continue incr e- $ctext tag conf link$i -foreground blue -underline 1+ $ctext tag add link "$commentstart + $s c" "$commentstart + $e c" $ctext tag add link$i "$commentstart + $s c" "$commentstart + $e c" $ctext tag bind link$i <1> [list selectline $idline($linkid) 1] }+ $ctext tag conf link -foreground blue -underline 1+ $ctext tag bind link <Enter> { %W configure -cursor hand2 }+ $ctext tag bind link <Leave> { %W configure -cursor {} } $ctext tag delete Comments $ctext tag remove found 1.0 end
From: Paul Mackerras <hidden> Date: 2016-06-15 22:42:03
Linus Torvalds writes:
This makes the cursor change when you hover over a SHA1 link with the new
"hypertext" gitk commit ID linking feature.
I committed something based on this but with extra stuff to make the
cursor changes work with the change from the normal cursor to the
watch cursor and back.
Paul.